From mikael.vidstedt at oracle.com Fri Nov 1 12:42:01 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 01 Nov 2013 12:42:01 -0700 Subject: RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION In-Reply-To: <06335212-81F2-459C-A17E-566E19D5C3E6@oracle.com> References: <5272E315.5080201@oracle.com> <06335212-81F2-459C-A17E-566E19D5C3E6@oracle.com> Message-ID: <52740409.5020007@oracle.com> It was indeed a fun one! Vladimir/Chris/Igor - thanks for the reviews! Cheers, Mikael On 2013-10-31 17:49, Igor Veresov wrote: > That was a fun one! Looks good. > > igor > > On Oct 31, 2013, at 4:09 PM, Mikael Vidstedt wrote: > >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8026775 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8026775/webrev.01/webrev/ >> >> Exec summary: >> >> The stack banging code in the UncommonTrapBlob is not pre-touching all the stack shadow pages as it should. The result is that under some circumstances it may leave unmapped "holes" on the stack, and when a compiled method later touches a stack page on the other side of the hole Windows will raise an exception because it requires all stack pages to be touched/mapped in order. >> >> >> Details: >> >> The code in MacroAssembler::bang_stack_size() is supposed to generate code which touches enough stack pages to make room for the interpreter frame for the deoptimized method and then touch an additional StackShadowPages pages. However, the code fails to do this because: >> >> a) it touches the same page twice (the last page touched in the first loop is the exact same address touched the first time in the second loop), and >> b) it doesn't loop all the way up to *and including* StackShadowPages (the "-1" is incorrect, and so is the less than) >> >> The corresponding code in AbstractInterpreterGenerator::bang_stack_shadow_pages() touches all pages from 1 page below sp all the way down to StackShadowPages below sp *inclusive*. The UncommonTrapBlob is supposed to mimic that exact same behavior. >> >> Cheers, >> Mikael >> From john.coomes at oracle.com Fri Nov 1 14:26:02 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 21:26:02 +0000 Subject: hg: hsx/hotspot-comp: 61 new changesets Message-ID: <20131101212607.0C03F62901@hg.openjdk.java.net> Changeset: 187a759c08ba Author: alanb Date: 2013-10-02 04:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/rev/7c0e2fd8be4d Merge Changeset: 3ece65f23ed2 Author: lana Date: 2013-10-11 00:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/3ece65f23ed2 Merge Changeset: 7dea0ce25bdc Author: pbhat Date: 2013-05-30 16:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/rev/4a4c9e7bc6c9 Merge Changeset: 63d794ade242 Author: pbhat Date: 2013-08-02 09:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/63d794ade242 Merge Changeset: a5485b9a2d14 Author: pbhat Date: 2013-08-09 14:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/a5485b9a2d14 Merge Changeset: 028ac95111b9 Author: pbhat Date: 2013-08-16 14:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/028ac95111b9 Merge Changeset: 4b686cbc32c7 Author: pbhat Date: 2013-08-23 09:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/rev/c8066e5d7a7b Merge Changeset: 00ae95ca1755 Author: pbhat Date: 2013-10-03 09:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/00ae95ca1755 Merge Changeset: 7deff16cf438 Author: jqzuo Date: 2013-10-14 18:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/rev/4d23143c676a Merge Changeset: fd3b32cc4b6e Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/fd3b32cc4b6e Merge Changeset: 3f9873789d44 Author: mduigou Date: 2013-10-11 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/rev/d35943431696 Merge Changeset: af87dabb4263 Author: msheppar Date: 2013-06-14 15:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/rev/ce8c63017f11 Merge Changeset: 28be3d174c92 Author: chegar Date: 2013-10-15 13:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/28be3d174c92 Merge Changeset: af81988013b5 Author: erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/rev/35c14ec3e12f Merge Changeset: 22c6f0b7e2b5 Author: dcubed Date: 2013-10-15 08:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/22c6f0b7e2b5 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! 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: ac09e62d5e6b Author: amurillo Date: 2013-10-19 08:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/rev/9d5284dfc00d Merge Changeset: 5b4f14990dd1 Author: ihse Date: 2013-10-18 10:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/rev/65c1752b4c38 Merge Changeset: 17d195bd56fc Author: erikj Date: 2013-10-18 11:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/rev/e27dda53d4f5 Merge Changeset: 1a853fac18ff Author: erikj Date: 2013-10-21 11:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/rev/2cc1a52d37ef Merge Changeset: 6f19b2440412 Author: ihse Date: 2013-10-23 13:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/rev/4f2011496393 Merge Changeset: b65d48f6938a Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/b65d48f6938a Added tag jdk8-b114 for changeset 4f2011496393 ! .hgtags From john.coomes at oracle.com Fri Nov 1 14:26:12 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 21:26:12 +0000 Subject: hg: hsx/hotspot-comp/corba: 24 new changesets Message-ID: <20131101212627.0241562902@hg.openjdk.java.net> Changeset: 66fc1a749867 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/corba/rev/43cec76d1d62 Merge Changeset: 54aa9b7d743d Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/corba/rev/ab6eae733bce Merge Changeset: e5ea72df9806 Author: chegar Date: 2013-07-22 13:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/e5ea72df9806 Merge Changeset: be4fdc568d73 Author: mchung Date: 2013-07-22 19:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/corba/rev/b0aeb77f0292 Merge Changeset: a72f506e3058 Author: chegar Date: 2013-08-02 09:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/a72f506e3058 Merge Changeset: 0717fc6f2960 Author: chegar Date: 2013-08-09 14:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/0717fc6f2960 Merge Changeset: 6b5db99e194c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/corba/rev/2caa37dfd7cd Merge Changeset: a5788ab042dc Author: chegar Date: 2013-08-30 09:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/a5788ab042dc Merge Changeset: 118a211bb3ba Author: chegar Date: 2013-09-06 09:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/118a211bb3ba Merge Changeset: cc52d582df09 Author: chegar Date: 2013-09-14 19:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/cc52d582df09 Merge Changeset: 396854c032bb Author: chegar Date: 2013-10-03 19:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/396854c032bb Merge Changeset: 47513cdce4ed Author: chegar Date: 2013-10-13 22:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/47513cdce4ed Merge Changeset: 438c54c148a6 Author: erikj Date: 2013-10-16 13:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/corba/rev/d425685e0b74 Added tag jdk8-b114 for changeset 0bbccf77c23e ! .hgtags From john.coomes at oracle.com Fri Nov 1 14:26:40 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 21:26:40 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 38 new changesets Message-ID: <20131101212801.CDDAA62903@hg.openjdk.java.net> Changeset: 84a2b2ee6fc6 Author: aefimov Date: 2013-10-01 17:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/jaxp/rev/1c074a0c2b97 Merge Changeset: d69f4ac43d64 Author: lana Date: 2013-10-08 14:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/d69f4ac43d64 Merge Changeset: cdc3577cba0b Author: lana Date: 2013-10-11 00:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/cdc3577cba0b Merge Changeset: acae2e8a46df Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxp/rev/c1f9158fbb9c Merge Changeset: e85dd07c0eea Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jaxp/rev/2107c9baa457 Merge Changeset: cff4e3bf530a Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/cff4e3bf530a Merge Changeset: 46ccc5fbc523 Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/46ccc5fbc523 Merge Changeset: de8c803d4958 Author: aefimov Date: 2013-10-13 13:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxp/rev/4712979714d1 Merge Changeset: 91ae0f2045bc Author: lana Date: 2013-10-14 09:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/91ae0f2045bc Merge Changeset: eb169222d3f2 Author: joehw Date: 2013-10-14 22:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/jaxp/rev/4b0b2b5c4cc8 Merge Changeset: 40b8abe19642 Author: chegar Date: 2013-07-29 14:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/jaxp/rev/ecbddaa85462 Merge Changeset: c5e80c1fa32f Author: chegar Date: 2013-08-09 14:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxp/rev/f952c33ebfdb Merge Changeset: ce16a5aa1507 Author: joehw Date: 2013-08-20 09:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxp/rev/cc3b64366048 Merge Changeset: 2b77e12ff69d Author: chegar Date: 2013-10-11 19:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxp/rev/6f220761f643 Merge Changeset: 0c3f951630fe Author: joehw Date: 2013-10-17 11:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jaxp/rev/31c82bc71ae3 Merge Changeset: 2f1e1e2c2242 Author: lana Date: 2013-10-17 17:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/2f1e1e2c2242 Merge Changeset: 0046d2278204 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jaxp/rev/d3b6da1b3e25 Added tag jdk8-b114 for changeset 1b1e12117fe2 ! .hgtags From john.coomes at oracle.com Fri Nov 1 14:28:13 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 21:28:13 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 27 new changesets Message-ID: <20131101212911.71CDF62904@hg.openjdk.java.net> Changeset: b0610cd08440 Author: mkos Date: 2013-10-04 16:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jaxws/rev/1d6c13d3b8de Merge Changeset: 7c0a7937f6ef Author: lana Date: 2013-10-11 00:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/7c0a7937f6ef Merge Changeset: 602fdd7bb765 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxws/rev/dbdd5c762509 Merge Changeset: 9ca9735d9966 Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxws/rev/da77e343f458 Merge Changeset: 66a12ce67d3a Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/66a12ce67d3a Merge Changeset: 328b8b96773b Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/328b8b96773b Merge Changeset: 43240b8b995b Author: mkos Date: 2013-08-01 16:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxws/rev/358f32260d1f Merge Changeset: 5212665bea32 Author: chegar Date: 2013-08-09 14:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/5212665bea32 Merge Changeset: d9704ab517d5 Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/d9704ab517d5 Merge Changeset: fca8869ccfd0 Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/fca8869ccfd0 Merge Changeset: a6e2adde013e Author: chegar Date: 2013-08-30 10:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/a6e2adde013e Merge Changeset: f6376ba97cea Author: chegar Date: 2013-09-06 09:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/f6376ba97cea Merge Changeset: d3a65e8912c9 Author: chegar Date: 2013-09-14 20:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/d3a65e8912c9 Merge Changeset: da8141b6e344 Author: chegar Date: 2013-10-03 19:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/da8141b6e344 Merge Changeset: 2dc8ae7eb53b Author: chegar Date: 2013-10-11 19:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/2dc8ae7eb53b Merge Changeset: 01facfebe17b Author: chegar Date: 2013-10-15 13:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/01facfebe17b Merge Changeset: be7d1f874b96 Author: lana Date: 2013-10-17 16:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/be7d1f874b96 Merge Changeset: 17f1b13cd401 Author: simonis Date: 2013-10-21 15:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxws/rev/f20820d1582f Merge Changeset: 9261f342aa73 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jaxws/rev/e126d8eca69b Added tag jdk8-b114 for changeset 9ad289610fc6 ! .hgtags From john.coomes at oracle.com Fri Nov 1 16:00:33 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 23:00:33 +0000 Subject: hg: hsx/hotspot-comp/langtools: 76 new changesets Message-ID: <20131101230419.55EFA62909@hg.openjdk.java.net> Changeset: 16194509e483 Author: vromero Date: 2013-09-27 10:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/34223fc58c1a Merge Changeset: 84161510f257 Author: emc Date: 2013-09-28 13:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/954dd199d6ff Merge Changeset: 8f54b4231c28 Author: cl Date: 2013-10-17 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/8f293c710369 Merge Changeset: bf33f4f81b40 Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/langtools/rev/f329c374da4b Merge Changeset: b024fe427d24 Author: jjg Date: 2013-10-14 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/0d75d3b96477 Merge Changeset: 2d1a54d213c2 Author: chegar Date: 2013-08-09 14:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2d1a54d213c2 Merge Changeset: 84b6d75ff2c9 Author: chegar Date: 2013-08-15 21:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/84b6d75ff2c9 Merge Changeset: a540e2a926cf Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a540e2a926cf Merge Changeset: a8f0c3583a86 Author: chegar Date: 2013-08-30 10:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/langtools/rev/a6901af8a2e4 Merge Changeset: 2c13a5da6854 Author: chegar Date: 2013-10-03 19:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/langtools/rev/90c9ae4bc756 Merge Changeset: dd073728085d Author: chegar Date: 2013-10-15 21:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/dd073728085d Merge Changeset: 19e8eebfbe52 Author: jlahoda Date: 2013-10-15 22:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/bca97b47f0a2 Merge Changeset: 127c2e74d2cf Author: tbell Date: 2013-10-22 16:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/langtools/rev/54150586ba78 Merge Changeset: 850d2602ae98 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/langtools/rev/fea486d30d41 Added tag jdk8-b114 for changeset 850d2602ae98 ! .hgtags From john.coomes at oracle.com Fri Nov 1 16:04:29 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 23:04:29 +0000 Subject: hg: hsx/hotspot-comp/nashorn: 51 new changesets Message-ID: <20131101230518.1669F6290A@hg.openjdk.java.net> Changeset: 982dd6e1bf4f Author: lana Date: 2013-09-27 18:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/982dd6e1bf4f Merge Changeset: 2016a6b9e1f3 Author: hannesw Date: 2013-09-27 16:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/nashorn/rev/ad5f9ce2a95b Merge Changeset: 787e36fdf69a Author: jlaskey Date: 2013-09-30 12:06 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/787e36fdf69a Merge Changeset: 7272ec90f2c6 Author: sundar Date: 2013-09-30 21:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/nashorn/rev/6a4fdb3bb4e3 Merge Changeset: 103590fc1e0a Author: cl Date: 2013-10-17 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/nashorn/rev/f6263ae511c2 Merge Changeset: 34f7a699cdef Author: sundar Date: 2013-10-10 14:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/nashorn/rev/56be5161f0d2 Merge Changeset: 1c154cee43d9 Author: hannesw Date: 2013-10-11 10:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/nashorn/rev/b35d175207f6 Merge Changeset: 1b0a71a9920a Author: lana Date: 2013-10-11 23:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/1b0a71a9920a Merge Changeset: 6cb4f20d971f Author: jlaskey Date: 2013-10-11 14:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/nashorn/rev/9a13e95cc40f Merge Changeset: 1899da5c71d3 Author: hannesw Date: 2013-10-16 10:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/nashorn/rev/adc5639fc4b9 Merge Changeset: 676cd7bf5e09 Author: lana Date: 2013-10-17 16:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/676cd7bf5e09 Merge Changeset: 79f7b79bf97b Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/nashorn/rev/f109bb255b80 Added tag jdk8-b114 for changeset 79f7b79bf97b ! .hgtags From alejandro.murillo at oracle.com Fri Nov 1 19:34:41 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 02 Nov 2013 02:34:41 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 24 new changesets Message-ID: <20131102023533.365F662920@hg.openjdk.java.net> Changeset: e006d2e25bc7 Author: dholmes Date: 2013-10-24 20:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/hotspot/rev/913a35723a0a Merge Changeset: 7fd913010dbb Author: katleman Date: 2013-10-29 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fd913010dbb Merge Changeset: ddc3758f68db Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ddc3758f68db Added tag jdk8-b114 for changeset 7fd913010dbb ! .hgtags Changeset: e64f1fe9756b Author: farvidsson Date: 2013-10-24 10:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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/hotspot-comp/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/hotspot-comp/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/hotspot-comp/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/hotspot-comp/hotspot/rev/634715d59d9e Merge Changeset: 209aa13ab8c0 Author: coleenp Date: 2013-10-25 15:19 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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/hotspot-comp/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/hotspot-comp/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/hotspot-comp/hotspot/rev/85730a185147 Merge Changeset: 292050e5d5ea Author: dholmes Date: 2013-10-24 00:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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/hotspot-comp/hotspot/rev/066778844ed9 Merge Changeset: f2f9139ccde9 Author: jprovino Date: 2013-10-30 16:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f2f9139ccde9 Merge Changeset: a007575ea726 Author: vladidan Date: 2013-10-30 16:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a007575ea726 Merge Changeset: 3b3133d93fb6 Author: brutisso Date: 2013-10-28 13:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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/hotspot-comp/hotspot/rev/6d965678f21e Merge Changeset: 2dcd0bd2920d Author: iveresov Date: 2013-10-31 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2dcd0bd2920d Merge Changeset: 0836a3c28c6a Author: iveresov Date: 2013-10-31 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0836a3c28c6a Merge Changeset: 3b32d287da89 Author: amurillo Date: 2013-11-01 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/hotspot/rev/5b84039ca739 8027580: new hotspot build - hs25-b58 Reviewed-by: jcoomes ! make/hotspot_version From igor.veresov at oracle.com Mon Nov 4 00:59:23 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 4 Nov 2013 00:59:23 -0800 Subject: RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled Message-ID: G1 barriers use logical operators (xor) on T_OBJECT mixed with T_LONG or T_INT. The current implementation of logical operations on x86 in C1 doesn't allow for long operands to be on stack. There is a special code in the register allocator that forces long arguments in registers on x86. However T_OBJECT can be spilled just fine, and in that case the xor emission will fail. The shortest fix is to force the allocator to keep operands of type T_OBJECT in registers when doing logical operations (as we do with T_LONG already) on 64bit x86. Webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.0/ Thanks! igor From igor.ignatyev at oracle.com Mon Nov 4 01:04:49 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 04 Nov 2013 13:04:49 +0400 Subject: RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled In-Reply-To: References: Message-ID: <52776331.7080509@oracle.com> Hi Igor, What testing did you do? - Igor On 11/04/2013 12:59 PM, Igor Veresov wrote: > G1 barriers use logical operators (xor) on T_OBJECT mixed with T_LONG or T_INT. The current implementation of logical operations on x86 in C1 doesn't allow for long operands to be on stack. There is a special code in the register allocator that forces long arguments in registers on x86. However T_OBJECT can be spilled just fine, and in that case the xor emission will fail. > > The shortest fix is to force the allocator to keep operands of type T_OBJECT in registers when doing logical operations (as we do with T_LONG already) on 64bit x86. > > Webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.0/ > > Thanks! > igor > From igor.veresov at oracle.com Mon Nov 4 01:14:13 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 4 Nov 2013 01:14:13 -0800 Subject: RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled In-Reply-To: <52776331.7080509@oracle.com> References: <52776331.7080509@oracle.com> Message-ID: <2378F3C3-11BA-46AA-924C-A8321EEECB8E@oracle.com> I ran Weblogic+Medrec from UTE. igor On Nov 4, 2013, at 1:04 AM, Igor Ignatyev wrote: > Hi Igor, > What testing did you do? > > - Igor > > On 11/04/2013 12:59 PM, Igor Veresov wrote: >> G1 barriers use logical operators (xor) on T_OBJECT mixed with T_LONG or T_INT. The current implementation of logical operations on x86 in C1 doesn't allow for long operands to be on stack. There is a special code in the register allocator that forces long arguments in registers on x86. However T_OBJECT can be spilled just fine, and in that case the xor emission will fail. >> >> The shortest fix is to force the allocator to keep operands of type T_OBJECT in registers when doing logical operations (as we do with T_LONG already) on 64bit x86. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.0/ >> >> Thanks! >> igor >> From rickard.backman at oracle.com Mon Nov 4 01:52:37 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Mon, 4 Nov 2013 10:52:37 +0100 Subject: RFR(XS): 8027622: java.time.Instant.create failing since hs25-b56 Message-ID: <20131104095208.GC6910@rbackman> Hi, can I please have some reviews for this change? If we have a control edge set on Cmp nodes we mess up in matching. The MathExact nodes forced all nodes (except Phi) to have a control edge to the overflow check. This change excludes Cmp nodes as well. Webrev: http://cr.openjdk.java.net/~rbackman/8027622/ Bug: https://bugs.openjdk.java.net/browse/JDK-8027622 Thanks /R From igor.veresov at oracle.com Mon Nov 4 01:55:12 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 4 Nov 2013 01:55:12 -0800 Subject: RFR(M): 8017065 C2 allows safepoint checks to leak into G1 pre-barriers Message-ID: <626D2A7A-2B06-425B-9EDC-901E7370C3F8@oracle.com> As an unfortunate result of Safepoint not producing memory, raw loads must be treated specially. In particular the control edge of such a load bears not only the obvious control dependency information but a part of the memory state dependency as well. As a result of that we should be very conservative about changing control of such nodes. The following change, extends the existing special treatment of raw pointer loads to all raw loads (which we have a bunch of in G1 barriers) and restricts the movement of raw loads dependent on range check in RCE. Also I?ve added a verification pass to check consistency of the G1 pre-barriers, which should make easier to catch such things in the future. Webrev: http://cr.openjdk.java.net/~iveresov/8017065/webrev.0 Testing: eyeballing graphs, CTW, Weblogic+Medrec From vladimir.kozlov at oracle.com Mon Nov 4 08:47:20 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Nov 2013 08:47:20 -0800 Subject: RFR(XS): 8027622: java.time.Instant.create failing since hs25-b56 In-Reply-To: <20131104095208.GC6910@rbackman> References: <20131104095208.GC6910@rbackman> Message-ID: <5277CF98.7000804@oracle.com> Good. Vladimir On 11/4/13 1:52 AM, Rickard B?ckman wrote: > Hi, > > can I please have some reviews for this change? > If we have a control edge set on Cmp nodes we mess up in matching. The > MathExact nodes forced all nodes (except Phi) to have a control edge to > the overflow check. This change excludes Cmp nodes as well. > > Webrev: http://cr.openjdk.java.net/~rbackman/8027622/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8027622 > > Thanks > /R > From vladimir.kozlov at oracle.com Mon Nov 4 08:52:06 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Nov 2013 08:52:06 -0800 Subject: RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled In-Reply-To: References: Message-ID: <5277D0B6.9060502@oracle.com> Can you move && inside macro to avoid NOT_LP64()?: LP64_ONLY(&& (opr_type != T_OBJECT)) Thanks, Vladimir On 11/4/13 12:59 AM, Igor Veresov wrote: > G1 barriers use logical operators (xor) on T_OBJECT mixed with T_LONG or T_INT. The current implementation of logical operations on x86 in C1 doesn't allow for long operands to be on stack. There is a special code in the register allocator that forces long arguments in registers on x86. However T_OBJECT can be spilled just fine, and in that case the xor emission will fail. > > The shortest fix is to force the allocator to keep operands of type T_OBJECT in registers when doing logical operations (as we do with T_LONG already) on 64bit x86. > > Webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.0/ > > Thanks! > igor > From vladimir.kozlov at oracle.com Mon Nov 4 09:02:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Nov 2013 09:02:32 -0800 Subject: RFR(M): 8017065 C2 allows safepoint checks to leak into G1 pre-barriers In-Reply-To: <626D2A7A-2B06-425B-9EDC-901E7370C3F8@oracle.com> References: <626D2A7A-2B06-425B-9EDC-901E7370C3F8@oracle.com> Message-ID: <5277D328.6090307@oracle.com> in verification code start with i = 1 since in(0) points to Region itself: + if (x->is_Region()) { + for (uint i = 0; i < x->req(); i++) { Also look for and skip NULL and C->top() popping node: x = worklist.pop(); Otherwise seems fine. Thanks, Vladimir On 11/4/13 1:55 AM, Igor Veresov wrote: > As an unfortunate result of Safepoint not producing memory, raw loads must be treated specially. In particular the control edge of such a load bears not only the obvious control dependency information but a part of the memory state dependency as well. As a result of that we should be very conservative about changing control of such nodes. > > The following change, extends the existing special treatment of raw pointer loads to all raw loads (which we have a bunch of in G1 barriers) and restricts the movement of raw loads dependent on range check in RCE. Also I?ve added a verification pass to check consistency of the G1 pre-barriers, which should make easier to catch such things in the future. > > Webrev: http://cr.openjdk.java.net/~iveresov/8017065/webrev.0 > > Testing: eyeballing graphs, CTW, Weblogic+Medrec > From ysr1729 at gmail.com Mon Nov 4 09:17:39 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 4 Nov 2013 09:17:39 -0800 Subject: Flag in JDK 7uXX to allow visibility into code cache usage? Message-ID: We recently had a situation when code cache flushing, when the code cache was nearly full, caused a large drop in performance. It would be nice if there were a product flag (also in 7uXX) by which one could get a read of the code cache size on a periodic basis. It might be great, for instance, if this value were printed, say at each GC. I understand that there is an Mbean that can be read to determine this value, but I was looking for something like a JVM flag that allows this to be printed to a log file on a periodic basis, say at each GC (or even eacn major gc cycle). In 7uXX at least there seem to be far too few means to track the usage of the code cache. thanks for anything that can be done in this area, wrt visibility (in 7uXX :-) -- ramki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131104/76fe5980/attachment-0001.html From igor.veresov at oracle.com Mon Nov 4 10:57:56 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 4 Nov 2013 10:57:56 -0800 Subject: RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled In-Reply-To: <5277D0B6.9060502@oracle.com> References: <5277D0B6.9060502@oracle.com> Message-ID: <4371304B-CD02-4FF0-88D7-A52E93FD3BA7@oracle.com> Sure. IgorI also insists I add a regression test. The updated webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.1/ igor On Nov 4, 2013, at 8:52 AM, Vladimir Kozlov wrote: > Can you move && inside macro to avoid NOT_LP64()?: > > LP64_ONLY(&& (opr_type != T_OBJECT)) > > Thanks, > Vladimir > > On 11/4/13 12:59 AM, Igor Veresov wrote: >> G1 barriers use logical operators (xor) on T_OBJECT mixed with T_LONG or T_INT. The current implementation of logical operations on x86 in C1 doesn't allow for long operands to be on stack. There is a special code in the register allocator that forces long arguments in registers on x86. However T_OBJECT can be spilled just fine, and in that case the xor emission will fail. >> >> The shortest fix is to force the allocator to keep operands of type T_OBJECT in registers when doing logical operations (as we do with T_LONG already) on 64bit x86. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.0/ >> >> Thanks! >> igor >> From vladimir.kozlov at oracle.com Mon Nov 4 11:14:26 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Nov 2013 11:14:26 -0800 Subject: RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled In-Reply-To: <4371304B-CD02-4FF0-88D7-A52E93FD3BA7@oracle.com> References: <5277D0B6.9060502@oracle.com> <4371304B-CD02-4FF0-88D7-A52E93FD3BA7@oracle.com> Message-ID: <5277F212.70102@oracle.com> Fix is good but you need to rename test and test's directory. Vladimir On 11/4/13 10:57 AM, Igor Veresov wrote: > Sure. IgorI also insists I add a regression test. > > The updated webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.1/ > > igor > > > On Nov 4, 2013, at 8:52 AM, Vladimir Kozlov wrote: > >> Can you move && inside macro to avoid NOT_LP64()?: >> >> LP64_ONLY(&& (opr_type != T_OBJECT)) >> >> Thanks, >> Vladimir >> >> On 11/4/13 12:59 AM, Igor Veresov wrote: >>> G1 barriers use logical operators (xor) on T_OBJECT mixed with T_LONG or T_INT. The current implementation of logical operations on x86 in C1 doesn't allow for long operands to be on stack. There is a special code in the register allocator that forces long arguments in registers on x86. However T_OBJECT can be spilled just fine, and in that case the xor emission will fail. >>> >>> The shortest fix is to force the allocator to keep operands of type T_OBJECT in registers when doing logical operations (as we do with T_LONG already) on 64bit x86. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.0/ >>> >>> Thanks! >>> igor >>> > From igor.veresov at oracle.com Mon Nov 4 11:49:33 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 4 Nov 2013 11:49:33 -0800 Subject: RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled In-Reply-To: <5277F212.70102@oracle.com> References: <5277D0B6.9060502@oracle.com> <4371304B-CD02-4FF0-88D7-A52E93FD3BA7@oracle.com> <5277F212.70102@oracle.com> Message-ID: Something like this? http://cr.openjdk.java.net/~iveresov/8027751/webrev.2/ igor On Nov 4, 2013, at 11:14 AM, Vladimir Kozlov wrote: > Fix is good but you need to rename test and test's directory. > > Vladimir > > On 11/4/13 10:57 AM, Igor Veresov wrote: >> Sure. IgorI also insists I add a regression test. >> >> The updated webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.1/ >> >> igor >> >> >> On Nov 4, 2013, at 8:52 AM, Vladimir Kozlov wrote: >> >>> Can you move && inside macro to avoid NOT_LP64()?: >>> >>> LP64_ONLY(&& (opr_type != T_OBJECT)) >>> >>> Thanks, >>> Vladimir >>> >>> On 11/4/13 12:59 AM, Igor Veresov wrote: >>>> G1 barriers use logical operators (xor) on T_OBJECT mixed with T_LONG or T_INT. The current implementation of logical operations on x86 in C1 doesn't allow for long operands to be on stack. There is a special code in the register allocator that forces long arguments in registers on x86. However T_OBJECT can be spilled just fine, and in that case the xor emission will fail. >>>> >>>> The shortest fix is to force the allocator to keep operands of type T_OBJECT in registers when doing logical operations (as we do with T_LONG already) on 64bit x86. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.0/ >>>> >>>> Thanks! >>>> igor >>>> >> From vladimir.kozlov at oracle.com Mon Nov 4 11:58:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Nov 2013 11:58:29 -0800 Subject: RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled In-Reply-To: References: <5277D0B6.9060502@oracle.com> <4371304B-CD02-4FF0-88D7-A52E93FD3BA7@oracle.com> <5277F212.70102@oracle.com> Message-ID: <5277FC65.10800@oracle.com> On 11/4/13 11:49 AM, Igor Veresov wrote: > Something like this? > http://cr.openjdk.java.net/~iveresov/8027751/webrev.2/ Yes, it is good. Vladimir > > igor > > On Nov 4, 2013, at 11:14 AM, Vladimir Kozlov wrote: > >> Fix is good but you need to rename test and test's directory. >> >> Vladimir >> >> On 11/4/13 10:57 AM, Igor Veresov wrote: >>> Sure. IgorI also insists I add a regression test. >>> >>> The updated webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.1/ >>> >>> igor >>> >>> >>> On Nov 4, 2013, at 8:52 AM, Vladimir Kozlov wrote: >>> >>>> Can you move && inside macro to avoid NOT_LP64()?: >>>> >>>> LP64_ONLY(&& (opr_type != T_OBJECT)) >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/4/13 12:59 AM, Igor Veresov wrote: >>>>> G1 barriers use logical operators (xor) on T_OBJECT mixed with T_LONG or T_INT. The current implementation of logical operations on x86 in C1 doesn't allow for long operands to be on stack. There is a special code in the register allocator that forces long arguments in registers on x86. However T_OBJECT can be spilled just fine, and in that case the xor emission will fail. >>>>> >>>>> The shortest fix is to force the allocator to keep operands of type T_OBJECT in registers when doing logical operations (as we do with T_LONG already) on 64bit x86. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.0/ >>>>> >>>>> Thanks! >>>>> igor >>>>> >>> > From john.r.rose at oracle.com Mon Nov 4 11:58:42 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 4 Nov 2013 11:58:42 -0800 Subject: RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION In-Reply-To: <5272E315.5080201@oracle.com> References: <5272E315.5080201@oracle.com> Message-ID: + // Skip the first one because that was already touched in the above + // loop - the post decrement of temp means it's now a page below the + // last touch The comments should say 'tmp' not 'temp'. Also, the phrases 'first one' and 'it's now a page below' are hard to understand, and (to me) slightly misleading. Suggest: + // At this point, (tmp-0) is the last address touched, so don't touch it again. + // (It was touched as (tmp-pagesize) but then tmp was post-decremented.) + // Skip this address by starting at i=1, and touch a few more pages below. + // N.B. It is important to touch all the down to and including i=StackShadowPages. ? John From igor.veresov at oracle.com Mon Nov 4 13:09:17 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 4 Nov 2013 13:09:17 -0800 Subject: RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled In-Reply-To: <5277FC65.10800@oracle.com> References: <5277D0B6.9060502@oracle.com> <4371304B-CD02-4FF0-88D7-A52E93FD3BA7@oracle.com> <5277F212.70102@oracle.com> <5277FC65.10800@oracle.com> Message-ID: Thanks, Vladimir! igor On Nov 4, 2013, at 11:58 AM, Vladimir Kozlov wrote: > On 11/4/13 11:49 AM, Igor Veresov wrote: >> Something like this? >> http://cr.openjdk.java.net/~iveresov/8027751/webrev.2/ > > Yes, it is good. > > Vladimir > >> >> igor >> >> On Nov 4, 2013, at 11:14 AM, Vladimir Kozlov wrote: >> >>> Fix is good but you need to rename test and test's directory. >>> >>> Vladimir >>> >>> On 11/4/13 10:57 AM, Igor Veresov wrote: >>>> Sure. IgorI also insists I add a regression test. >>>> >>>> The updated webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.1/ >>>> >>>> igor >>>> >>>> >>>> On Nov 4, 2013, at 8:52 AM, Vladimir Kozlov wrote: >>>> >>>>> Can you move && inside macro to avoid NOT_LP64()?: >>>>> >>>>> LP64_ONLY(&& (opr_type != T_OBJECT)) >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/4/13 12:59 AM, Igor Veresov wrote: >>>>>> G1 barriers use logical operators (xor) on T_OBJECT mixed with T_LONG or T_INT. The current implementation of logical operations on x86 in C1 doesn't allow for long operands to be on stack. There is a special code in the register allocator that forces long arguments in registers on x86. However T_OBJECT can be spilled just fine, and in that case the xor emission will fail. >>>>>> >>>>>> The shortest fix is to force the allocator to keep operands of type T_OBJECT in registers when doing logical operations (as we do with T_LONG already) on 64bit x86. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.0/ >>>>>> >>>>>> Thanks! >>>>>> igor >>>>>> >>>> >> From kirk at kodewerk.com Mon Nov 4 13:25:01 2013 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 4 Nov 2013 22:25:01 +0100 Subject: Flag in JDK 7uXX to allow visibility into code cache usage? In-Reply-To: References: Message-ID: <8197E5D5-ACB3-461A-9E80-9004177909C1@kodewerk.com> Hi Ramki, My little VisualVM plugin MemoryPoolViewer was motivated by a need to see the occupancy and size of the code cache. I think it would be helpful if the compilation threads reported on pool maintenance as the GC threads do. Regards, Kirk On 2013-11-04, at 6:17 PM, Srinivas Ramakrishna wrote: > > We recently had a situation when code cache flushing, when the code cache was nearly full, caused a large drop > in performance. It would be nice if there were a product flag (also in 7uXX) by which one could get > a read of the code cache size on a periodic basis. It might be great, for instance, if this value were > printed, say at each GC. > > I understand that there is an Mbean that can be read to determine this value, but I was looking for > something like a JVM flag that allows this to be printed to a log file on a periodic basis, say at each GC (or even eacn > major gc cycle). In 7uXX at least there seem to be far too few means to track the usage of the code > cache. > > thanks for anything that can be done in this area, wrt visibility (in 7uXX :-) > -- ramki From ysr1729 at gmail.com Mon Nov 4 14:19:22 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 4 Nov 2013 14:19:22 -0800 Subject: Flag in JDK 7uXX to allow visibility into code cache usage? In-Reply-To: <8197E5D5-ACB3-461A-9E80-9004177909C1@kodewerk.com> References: <8197E5D5-ACB3-461A-9E80-9004177909C1@kodewerk.com> Message-ID: In 8, I see that there is a product flag called "PrintCodeCacheOnCompilation" which reports the occupancy etc. each time a method is compiled. (Perhaps that's a bit too much/frequent, I don't know.) There's also a develop flag "PrintMethodFlushing" that (in 8) reports this at the end of an nmethod sweep cycle. (Would be great if this were printed in product mode, not just develop.) It would be great if the latter were also reported in product mode and the reporting back-ported to 7uXX. -- ramki On Mon, Nov 4, 2013 at 1:25 PM, Kirk Pepperdine wrote: > Hi Ramki, > > My little VisualVM plugin MemoryPoolViewer was motivated by a need to see > the occupancy and size of the code cache. I think it would be helpful if > the compilation threads reported on pool maintenance as the GC threads do. > > Regards, > Kirk > > On 2013-11-04, at 6:17 PM, Srinivas Ramakrishna wrote: > > > > > We recently had a situation when code cache flushing, when the code > cache was nearly full, caused a large drop > > in performance. It would be nice if there were a product flag (also in > 7uXX) by which one could get > > a read of the code cache size on a periodic basis. It might be great, > for instance, if this value were > > printed, say at each GC. > > > > I understand that there is an Mbean that can be read to determine this > value, but I was looking for > > something like a JVM flag that allows this to be printed to a log file > on a periodic basis, say at each GC (or even eacn > > major gc cycle). In 7uXX at least there seem to be far too few means to > track the usage of the code > > cache. > > > > thanks for anything that can be done in this area, wrt visibility (in > 7uXX :-) > > -- ramki > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131104/07f9aa61/attachment.html From roland.westrelin at oracle.com Mon Nov 4 15:25:54 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Mon, 04 Nov 2013 23:25:54 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I Message-ID: <20131104232556.E87D262A31@hg.openjdk.java.net> Changeset: 208ebea980f8 Author: roland Date: 2013-11-04 21:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From igor.veresov at oracle.com Mon Nov 4 16:53:02 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 4 Nov 2013 16:53:02 -0800 Subject: RFR(XS): 8027622: java.time.Instant.create failing since hs25-b56 In-Reply-To: <20131104095208.GC6910@rbackman> References: <20131104095208.GC6910@rbackman> Message-ID: <8080C56A-A001-4195-8A3E-8A93A58425DF@oracle.com> Seems alright. igor On Nov 4, 2013, at 1:52 AM, Rickard B?ckman wrote: > Hi, > > can I please have some reviews for this change? > If we have a control edge set on Cmp nodes we mess up in matching. The > MathExact nodes forced all nodes (except Phi) to have a control edge to > the overflow check. This change excludes Cmp nodes as well. > > Webrev: http://cr.openjdk.java.net/~rbackman/8027622/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8027622 > > Thanks > /R From igor.veresov at oracle.com Mon Nov 4 18:18:36 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 4 Nov 2013 18:18:36 -0800 Subject: RFR(M): 8017065 C2 allows safepoint checks to leak into G1 pre-barriers In-Reply-To: <5277D328.6090307@oracle.com> References: <626D2A7A-2B06-425B-9EDC-901E7370C3F8@oracle.com> <5277D328.6090307@oracle.com> Message-ID: <8E6E90E0-841D-4016-9921-FA73177C7D9B@oracle.com> Thanks for the review! All fixed + I?ve removed the CProj->NeverBranchNode skip for the load in the verification routine. It shouldn?t be necessary. Reran CTW with G1. Updated webrev: http://cr.openjdk.java.net/~iveresov/8017065/webrev.1/ igor On Nov 4, 2013, at 9:02 AM, Vladimir Kozlov wrote: > in verification code start with i = 1 since in(0) points to Region itself: > > + if (x->is_Region()) { > + for (uint i = 0; i < x->req(); i++) { > > Also look for and skip NULL and C->top() popping node: x = worklist.pop(); > > Otherwise seems fine. > > Thanks, > Vladimir > > On 11/4/13 1:55 AM, Igor Veresov wrote: >> As an unfortunate result of Safepoint not producing memory, raw loads must be treated specially. In particular the control edge of such a load bears not only the obvious control dependency information but a part of the memory state dependency as well. As a result of that we should be very conservative about changing control of such nodes. >> >> The following change, extends the existing special treatment of raw pointer loads to all raw loads (which we have a bunch of in G1 barriers) and restricts the movement of raw loads dependent on range check in RCE. Also I?ve added a verification pass to check consistency of the G1 pre-barriers, which should make easier to catch such things in the future. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8017065/webrev.0 >> >> Testing: eyeballing graphs, CTW, Weblogic+Medrec >> From vladimir.kozlov at oracle.com Mon Nov 4 18:22:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Nov 2013 18:22:01 -0800 Subject: RFR(M): 8017065 C2 allows safepoint checks to leak into G1 pre-barriers In-Reply-To: <8E6E90E0-841D-4016-9921-FA73177C7D9B@oracle.com> References: <626D2A7A-2B06-425B-9EDC-901E7370C3F8@oracle.com> <5277D328.6090307@oracle.com> <8E6E90E0-841D-4016-9921-FA73177C7D9B@oracle.com> Message-ID: <52785649.4040008@oracle.com> Good. Thanks, Vladimir On 11/4/13 6:18 PM, Igor Veresov wrote: > Thanks for the review! > All fixed + I?ve removed the CProj->NeverBranchNode skip for the load in the verification routine. It shouldn?t be necessary. Reran CTW with G1. > > Updated webrev: http://cr.openjdk.java.net/~iveresov/8017065/webrev.1/ > > igor > > On Nov 4, 2013, at 9:02 AM, Vladimir Kozlov wrote: > >> in verification code start with i = 1 since in(0) points to Region itself: >> >> + if (x->is_Region()) { >> + for (uint i = 0; i < x->req(); i++) { >> >> Also look for and skip NULL and C->top() popping node: x = worklist.pop(); >> >> Otherwise seems fine. >> >> Thanks, >> Vladimir >> >> On 11/4/13 1:55 AM, Igor Veresov wrote: >>> As an unfortunate result of Safepoint not producing memory, raw loads must be treated specially. In particular the control edge of such a load bears not only the obvious control dependency information but a part of the memory state dependency as well. As a result of that we should be very conservative about changing control of such nodes. >>> >>> The following change, extends the existing special treatment of raw pointer loads to all raw loads (which we have a bunch of in G1 barriers) and restricts the movement of raw loads dependent on range check in RCE. Also I?ve added a verification pass to check consistency of the G1 pre-barriers, which should make easier to catch such things in the future. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8017065/webrev.0 >>> >>> Testing: eyeballing graphs, CTW, Weblogic+Medrec >>> > From igor.veresov at oracle.com Mon Nov 4 20:00:11 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 4 Nov 2013 20:00:11 -0800 Subject: RFR(M): 8017065 C2 allows safepoint checks to leak into G1 pre-barriers In-Reply-To: <52785649.4040008@oracle.com> References: <626D2A7A-2B06-425B-9EDC-901E7370C3F8@oracle.com> <5277D328.6090307@oracle.com> <8E6E90E0-841D-4016-9921-FA73177C7D9B@oracle.com> <52785649.4040008@oracle.com> Message-ID: <7D49E4B8-6462-4390-82A3-332E0EB2D68E@oracle.com> Thanks! igor On Nov 4, 2013, at 6:22 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 11/4/13 6:18 PM, Igor Veresov wrote: >> Thanks for the review! >> All fixed + I?ve removed the CProj->NeverBranchNode skip for the load in the verification routine. It shouldn?t be necessary. Reran CTW with G1. >> >> Updated webrev: http://cr.openjdk.java.net/~iveresov/8017065/webrev.1/ >> >> igor >> >> On Nov 4, 2013, at 9:02 AM, Vladimir Kozlov wrote: >> >>> in verification code start with i = 1 since in(0) points to Region itself: >>> >>> + if (x->is_Region()) { >>> + for (uint i = 0; i < x->req(); i++) { >>> >>> Also look for and skip NULL and C->top() popping node: x = worklist.pop(); >>> >>> Otherwise seems fine. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/4/13 1:55 AM, Igor Veresov wrote: >>>> As an unfortunate result of Safepoint not producing memory, raw loads must be treated specially. In particular the control edge of such a load bears not only the obvious control dependency information but a part of the memory state dependency as well. As a result of that we should be very conservative about changing control of such nodes. >>>> >>>> The following change, extends the existing special treatment of raw pointer loads to all raw loads (which we have a bunch of in G1 barriers) and restricts the movement of raw loads dependent on range check in RCE. Also I?ve added a verification pass to check consistency of the G1 pre-barriers, which should make easier to catch such things in the future. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8017065/webrev.0 >>>> >>>> Testing: eyeballing graphs, CTW, Weblogic+Medrec >>>> >> From rickard.backman at oracle.com Mon Nov 4 23:27:28 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 5 Nov 2013 08:27:28 +0100 Subject: RFR(XS): 8027622: java.time.Instant.create failing since hs25-b56 In-Reply-To: <5277CF98.7000804@oracle.com> References: <20131104095208.GC6910@rbackman> <5277CF98.7000804@oracle.com> Message-ID: <20131105072728.GA3283@rbackman> Vladimir, thank you for the review. /R On 11/04, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 11/4/13 1:52 AM, Rickard B?ckman wrote: > >Hi, > > > >can I please have some reviews for this change? > >If we have a control edge set on Cmp nodes we mess up in matching. The > >MathExact nodes forced all nodes (except Phi) to have a control edge to > >the overflow check. This change excludes Cmp nodes as well. > > > >Webrev: http://cr.openjdk.java.net/~rbackman/8027622/ > >Bug: https://bugs.openjdk.java.net/browse/JDK-8027622 > > > >Thanks > >/R > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131105/b7e4f223/attachment.bin From rickard.backman at oracle.com Mon Nov 4 23:27:52 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 5 Nov 2013 08:27:52 +0100 Subject: RFR(XS): 8027622: java.time.Instant.create failing since hs25-b56 In-Reply-To: <8080C56A-A001-4195-8A3E-8A93A58425DF@oracle.com> References: <20131104095208.GC6910@rbackman> <8080C56A-A001-4195-8A3E-8A93A58425DF@oracle.com> Message-ID: <20131105072752.GB3283@rbackman> Igor, thank you for the review. /R On 11/04, Igor Veresov wrote: > Seems alright. > > igor > > On Nov 4, 2013, at 1:52 AM, Rickard B?ckman wrote: > > > Hi, > > > > can I please have some reviews for this change? > > If we have a control edge set on Cmp nodes we mess up in matching. The > > MathExact nodes forced all nodes (except Phi) to have a control edge to > > the overflow check. This change excludes Cmp nodes as well. > > > > Webrev: http://cr.openjdk.java.net/~rbackman/8027622/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8027622 > > > > Thanks > > /R > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131105/47a6f13c/attachment.bin From roland.westrelin at oracle.com Tue Nov 5 00:37:25 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 5 Nov 2013 09:37:25 +0100 Subject: RFR(M): 8017065 C2 allows safepoint checks to leak into G1 pre-barriers In-Reply-To: <8E6E90E0-841D-4016-9921-FA73177C7D9B@oracle.com> References: <626D2A7A-2B06-425B-9EDC-901E7370C3F8@oracle.com> <5277D328.6090307@oracle.com> <8E6E90E0-841D-4016-9921-FA73177C7D9B@oracle.com> Message-ID: <00EC1948-AA46-4EF4-8B40-255DE3FF5861@oracle.com> > Updated webrev: http://cr.openjdk.java.net/~iveresov/8017065/webrev.1/ Looks good to me. Roland. From roland.westrelin at oracle.com Tue Nov 5 00:38:49 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 5 Nov 2013 09:38:49 +0100 Subject: RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled In-Reply-To: References: <5277D0B6.9060502@oracle.com> <4371304B-CD02-4FF0-88D7-A52E93FD3BA7@oracle.com> <5277F212.70102@oracle.com> Message-ID: <31E523C5-4CFE-421E-B465-01679F016A4C@oracle.com> > http://cr.openjdk.java.net/~iveresov/8027751/webrev.2/ That looks good. A comment in c1_LinearScan.cpp would be nice. Roland. From igor.veresov at oracle.com Tue Nov 5 00:41:29 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Nov 2013 00:41:29 -0800 Subject: RFR(M): 8017065 C2 allows safepoint checks to leak into G1 pre-barriers In-Reply-To: <00EC1948-AA46-4EF4-8B40-255DE3FF5861@oracle.com> References: <626D2A7A-2B06-425B-9EDC-901E7370C3F8@oracle.com> <5277D328.6090307@oracle.com> <8E6E90E0-841D-4016-9921-FA73177C7D9B@oracle.com> <00EC1948-AA46-4EF4-8B40-255DE3FF5861@oracle.com> Message-ID: Thanks, Roland! igor On Nov 5, 2013, at 12:37 AM, Roland Westrelin wrote: >> Updated webrev: http://cr.openjdk.java.net/~iveresov/8017065/webrev.1/ > > Looks good to me. > > Roland. From igor.veresov at oracle.com Tue Nov 5 00:42:07 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Nov 2013 00:42:07 -0800 Subject: RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled In-Reply-To: <31E523C5-4CFE-421E-B465-01679F016A4C@oracle.com> References: <5277D0B6.9060502@oracle.com> <4371304B-CD02-4FF0-88D7-A52E93FD3BA7@oracle.com> <5277F212.70102@oracle.com> <31E523C5-4CFE-421E-B465-01679F016A4C@oracle.com> Message-ID: <5BB22E97-D87D-4049-B32B-48D82B3B6DEF@oracle.com> Thanks! I?ll make sure to put a comment. igor On Nov 5, 2013, at 12:38 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~iveresov/8027751/webrev.2/ > > That looks good. A comment in c1_LinearScan.cpp would be nice. > > Roland. From roland.westrelin at oracle.com Tue Nov 5 01:05:24 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 5 Nov 2013 10:05:24 +0100 Subject: RFR (XS): 8027632: assert(xtype->klass_is_exact()) failed: Should be exact at graphKit.cpp Message-ID: <0370B75F-6EA1-4315-830B-01FD9B2D52C8@oracle.com> http://cr.openjdk.java.net/~roland/8027632/webrev.00/ When doing profile collection for receiver type at an invokevirtual/invokeinterface, c1 uses the holder of a method as the known class if a single type is known to be possible. For default methods, the holder of the method may be an interface and the profile collection is wrong. The bug triggered an assert in type speculation but it?s actually unrelated to type speculation. Roland. From igor.veresov at oracle.com Tue Nov 5 01:14:05 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Nov 2013 01:14:05 -0800 Subject: RFR (XS): 8027632: assert(xtype->klass_is_exact()) failed: Should be exact at graphKit.cpp In-Reply-To: <0370B75F-6EA1-4315-830B-01FD9B2D52C8@oracle.com> References: <0370B75F-6EA1-4315-830B-01FD9B2D52C8@oracle.com> Message-ID: Good catch! Looks fine. igor On Nov 5, 2013, at 1:05 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8027632/webrev.00/ > > When doing profile collection for receiver type at an invokevirtual/invokeinterface, c1 uses the holder of a method as the known class if a single type is known to be possible. For default methods, the holder of the method may be an interface and the profile collection is wrong. > > The bug triggered an assert in type speculation but it?s actually unrelated to type speculation. > > Roland. From roland.westrelin at oracle.com Tue Nov 5 01:48:22 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 5 Nov 2013 10:48:22 +0100 Subject: RFR (XS): 8027632: assert(xtype->klass_is_exact()) failed: Should be exact at graphKit.cpp In-Reply-To: References: <0370B75F-6EA1-4315-830B-01FD9B2D52C8@oracle.com> Message-ID: Thanks for the review, Igor. Roland. From rickard.backman at oracle.com Tue Nov 5 02:27:05 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Tue, 05 Nov 2013 10:27:05 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8027622: java.time.Instant.create failing since hs25-b56 Message-ID: <20131105102708.6CACB62A5B@hg.openjdk.java.net> Changeset: e428d5e768e3 Author: rbackman Date: 2013-11-04 10:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From vladimir.x.ivanov at oracle.com Tue Nov 5 03:39:22 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 05 Nov 2013 15:39:22 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie Message-ID: <5278D8EA.3030104@oracle.com> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ There's a race between compiler thread during method registration and sweeper: sweeper can invalidate a nmethod which hasn't been installed yet. Consider the following scenario: ciEnv::register_method: - new nmethod(...) sweeper: - invalidates newly allocated nmethod and patches VEP to call handle_wrong_method - tries to unlink it, but method()->from_compiled_entry() != verified_entry_point() since nmethod hasn't been installed yet ciEnv::register_method: - installs already invalidated nmethod Calling corresponding Java method will lead to infinite loop: VEP of the compiled method calls handle_wrong_method and call site resolution returns the very same compiled method. The fix is to grab a lock after nmethod is allocated in the code cache and check that it hasn't been already invalidated by the sweeper before proceeding. Sweeper already synchronizes on a nmethod before invalidating it. Testing: failing test w/ diagnostic output. Thanks! Best regards, Vladimir Ivanov From igor.veresov at oracle.com Tue Nov 5 04:32:27 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 05 Nov 2013 12:32:27 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 3 new changesets Message-ID: <20131105123250.691AB62A62@hg.openjdk.java.net> Changeset: a905d33ce13a Author: iveresov Date: 2013-11-05 00:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/hotspot/rev/613e6a6fc328 Merge ! src/share/vm/opto/compile.cpp From roland.westrelin at oracle.com Tue Nov 5 04:47:36 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 5 Nov 2013 13:47:36 +0100 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <5278D8EA.3030104@oracle.com> References: <5278D8EA.3030104@oracle.com> Message-ID: <4AD63546-A4A2-47E9-8EFE-8583386E6F2D@oracle.com> Hi Vladimir, > http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ > > There's a race between compiler thread during method registration and sweeper: sweeper can invalidate a nmethod which hasn't been installed yet. > > Consider the following scenario: > ciEnv::register_method: > - new nmethod(...) > > sweeper: > - invalidates newly allocated nmethod and patches VEP to call handle_wrong_method > - tries to unlink it, but method()->from_compiled_entry() != verified_entry_point() since nmethod hasn't been installed yet > > ciEnv::register_method: > - installs already invalidated nmethod > > Calling corresponding Java method will lead to infinite loop: VEP of the compiled method calls handle_wrong_method and call site resolution returns the very same compiled method. Does that mean StressNonEntrant is broken? > The fix is to grab a lock after nmethod is allocated in the code cache and check that it hasn't been already invalidated by the sweeper before proceeding. Sweeper already synchronizes on a nmethod before invalidating it. Would another fix be to have the sweeper check that the method was made ready to execute before it attempts to make it not entrant? i.e. nmethod->method()->code() == nmethod Roland. From albert.noll at oracle.com Tue Nov 5 05:11:14 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 05 Nov 2013 14:11:14 +0100 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <4AD63546-A4A2-47E9-8EFE-8583386E6F2D@oracle.com> References: <5278D8EA.3030104@oracle.com> <4AD63546-A4A2-47E9-8EFE-8583386E6F2D@oracle.com> Message-ID: <5278EE72.3000401@oracle.com> Hi Vladimir, I have a question: the sweeper calls make_not_entrant() on a nmethod only after the nmethod has been in the code cache for at least 10 occurrences of a safepoint (time_since_reset in sweeper.ccp). Couldn't it also be that we mistakenly call the function make_not_entrant() from somewhere else and that this is the root cause of the error? Best, Albert On 11/05/2013 01:47 PM, Roland Westrelin wrote: > Hi Vladimir, > >> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >> >> There's a race between compiler thread during method registration and sweeper: sweeper can invalidate a nmethod which hasn't been installed yet. >> >> Consider the following scenario: >> ciEnv::register_method: >> - new nmethod(...) >> >> sweeper: >> - invalidates newly allocated nmethod and patches VEP to call handle_wrong_method >> - tries to unlink it, but method()->from_compiled_entry() != verified_entry_point() since nmethod hasn't been installed yet >> >> ciEnv::register_method: >> - installs already invalidated nmethod >> >> Calling corresponding Java method will lead to infinite loop: VEP of the compiled method calls handle_wrong_method and call site resolution returns the very same compiled method. > Does that mean StressNonEntrant is broken? > >> The fix is to grab a lock after nmethod is allocated in the code cache and check that it hasn't been already invalidated by the sweeper before proceeding. Sweeper already synchronizes on a nmethod before invalidating it. > Would another fix be to have the sweeper check that the method was made ready to execute before it attempts to make it not entrant? > > i.e. nmethod->method()->code() == nmethod > > Roland. From albert.noll at oracle.com Tue Nov 5 06:44:41 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 05 Nov 2013 15:44:41 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 Message-ID: <52790459.7050607@oracle.com> Hi, could I get reviews for this small patch? bug: https://bugs.openjdk.java.net/browse/JDK-8027593 webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ Problem: The implementation of the sweeper (8020151) causes a performance regression for small code cache sizes. There are two issues that cause this regression: 1) NmethodSweepFraction is only adjusted according to the ReservedCodecacheSize if TieredCompilation is enabled. As a result, NmethodSweepFraction remains 16 (if TieredCompilation is not used). This is way too large for small code cache sizes (e.g., <5m). 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a result, mark_active_nmethods() did not set _invocations and _current, which results in not invoking the sweeper (calling sweep_code_cache()) at all. When TieredCompilation is enabled this was not an issue, since NmethodSweeper::notify() (which sets _request_mark_phase) is called much more frequently. Solution: 1) Move setting of NmethodSweepFraction so that it is always executed. Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), and reset_nmetod_marking(). I think that these checks are not needed since 8020151, since we do stack scanning of active nmethods irrespective of the value of what need_marking_phase() returns. Since the patch removes need_marking_phase() printing out the warning (line 327 in sweeper.cpp) is incorrect, i.e., we continue to invoke the sweeper. I removed the warning and the associated code. Also, I think that we can either remove -XX:MethodFlushing or -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant and can be removed. I am not quite sure if we should do that now so it is not included in the patch. Testing bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a performance evaluation. Many thanks for looking at the patch. Best, Albert From albert.noll at oracle.com Tue Nov 5 06:51:21 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 05 Nov 2013 15:51:21 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <52790459.7050607@oracle.com> References: <52790459.7050607@oracle.com> Message-ID: <527905E9.7080306@oracle.com> I forgot to thank Vladimir Kozlov and Chris Plummer for their help in bringing up and analyzing the problem. Best, Albert On 11/05/2013 03:44 PM, Albert Noll wrote: > Hi, > > could I get reviews for this small patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8027593 > webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ > > Problem: The implementation of the sweeper (8020151) causes a > performance regression for small code cache sizes. There are two > issues that cause this regression: > 1) NmethodSweepFraction is only adjusted according to the > ReservedCodecacheSize if TieredCompilation is enabled. As a result, > NmethodSweepFraction remains 16 (if TieredCompilation is not used). > This is way too large for small code cache sizes (e.g., <5m). > 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a > result, mark_active_nmethods() did not set _invocations and _current, > which results in not invoking the sweeper (calling sweep_code_cache()) > at all. When TieredCompilation is enabled this was not an issue, since > NmethodSweeper::notify() (which sets _request_mark_phase) is called > much more frequently. > > Solution: 1) Move setting of NmethodSweepFraction so that it is always > executed. > Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), > and reset_nmetod_marking(). > I think that these checks are not needed since > 8020151, since we do stack scanning of > active nmethods irrespective of the value of what > need_marking_phase() returns. Since > the patch removes need_marking_phase() printing out > the warning (line 327 in > sweeper.cpp) is incorrect, i.e., we continue to > invoke the sweeper. I removed the warning > and the associated code. > > > Also, I think that we can either remove -XX:MethodFlushing or > -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant and > can be removed. I am not quite sure if we should do that now so it is > not included in the patch. > > Testing > bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a > performance evaluation. > > Many thanks for looking at the patch. > Best, > Albert From vladimir.x.ivanov at oracle.com Tue Nov 5 07:40:32 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 05 Nov 2013 19:40:32 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <4AD63546-A4A2-47E9-8EFE-8583386E6F2D@oracle.com> References: <5278D8EA.3030104@oracle.com> <4AD63546-A4A2-47E9-8EFE-8583386E6F2D@oracle.com> Message-ID: <52791170.7010205@oracle.com> >> >> Calling corresponding Java method will lead to infinite loop: VEP of the compiled method calls handle_wrong_method and call site resolution returns the very same compiled method. > > Does that mean StressNonEntrant is broken? Good point. Yes, StressNonEntrant is also broken. >> The fix is to grab a lock after nmethod is allocated in the code cache and check that it hasn't been already invalidated by the sweeper before proceeding. Sweeper already synchronizes on a nmethod before invalidating it. > > Would another fix be to have the sweeper check that the method was made ready to execute before it attempts to make it not entrant? > > i.e. nmethod->method()->code() == nmethod I don't see any reason why it shouldn't work as well. But it means that marking method as non-entrant is not reliable - doesn't necessarily perform state transition. I don't think we want that. Best regards, Vladimir Ivanov From roland.westrelin at oracle.com Tue Nov 5 07:43:37 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 5 Nov 2013 16:43:37 +0100 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <52791170.7010205@oracle.com> References: <5278D8EA.3030104@oracle.com> <4AD63546-A4A2-47E9-8EFE-8583386E6F2D@oracle.com> <52791170.7010205@oracle.com> Message-ID: >> Does that mean StressNonEntrant is broken? > Good point. Yes, StressNonEntrant is also broken. Should we do something about it? remove it? >> Would another fix be to have the sweeper check that the method was made ready to execute before it attempts to make it not entrant? >> >> i.e. nmethod->method()->code() == nmethod > I don't see any reason why it shouldn't work as well. But it means that marking method as non-entrant is not reliable - doesn't necessarily perform state transition. I don't think we want that. I meant change NMethodSweeper::process_nmethod(): if (!nm->is_locked_by_vm() && !nm->is_osr_method() && !nm->is_native_method() && nm->method()->code() == nm) { Roland. From vladimir.kozlov at oracle.com Tue Nov 5 08:44:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Nov 2013 08:44:08 -0800 Subject: RFR (XS): 8027632: assert(xtype->klass_is_exact()) failed: Should be exact at graphKit.cpp In-Reply-To: <0370B75F-6EA1-4315-830B-01FD9B2D52C8@oracle.com> References: <0370B75F-6EA1-4315-830B-01FD9B2D52C8@oracle.com> Message-ID: <52792058.8080301@oracle.com> Looks good. Thanks, Vladimir On 11/5/13 1:05 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8027632/webrev.00/ > > When doing profile collection for receiver type at an invokevirtual/invokeinterface, c1 uses the holder of a method as the known class if a single type is known to be possible. For default methods, the holder of the method may be an interface and the profile collection is wrong. > > The bug triggered an assert in type speculation but it?s actually unrelated to type speculation. > > Roland. > From roland.westrelin at oracle.com Tue Nov 5 09:16:32 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 5 Nov 2013 18:16:32 +0100 Subject: RFR (XS): 8027632: assert(xtype->klass_is_exact()) failed: Should be exact at graphKit.cpp In-Reply-To: <52792058.8080301@oracle.com> References: <0370B75F-6EA1-4315-830B-01FD9B2D52C8@oracle.com> <52792058.8080301@oracle.com> Message-ID: Thanks for the review, Vladimir. Roland. On Nov 5, 2013, at 5:44 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 11/5/13 1:05 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8027632/webrev.00/ >> >> When doing profile collection for receiver type at an invokevirtual/invokeinterface, c1 uses the holder of a method as the known class if a single type is known to be possible. For default methods, the holder of the method may be an interface and the profile collection is wrong. >> >> The bug triggered an assert in type speculation but it?s actually unrelated to type speculation. >> >> Roland. >> From vladimir.kozlov at oracle.com Tue Nov 5 10:09:19 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Nov 2013 10:09:19 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <52790459.7050607@oracle.com> References: <52790459.7050607@oracle.com> Message-ID: <5279344F.2060600@oracle.com> On 11/5/13 6:44 AM, Albert Noll wrote: > Hi, > > could I get reviews for this small patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8027593 > webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ > > Problem: The implementation of the sweeper (8020151) causes a performance regression for small code cache sizes. There > are two issues that cause this regression: > 1) NmethodSweepFraction is only adjusted according to the ReservedCodecacheSize if TieredCompilation is enabled. As a > result, NmethodSweepFraction remains 16 (if TieredCompilation is not used). This is way too large for small code cache > sizes (e.g., <5m). > 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a result, mark_active_nmethods() did not set > _invocations and _current, which results in not invoking the sweeper (calling sweep_code_cache()) at all. When > TieredCompilation is enabled this was not an issue, since NmethodSweeper::notify() (which sets _request_mark_phase) is > called much more frequently. > > Solution: 1) Move setting of NmethodSweepFraction so that it is always executed. Good. > Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), and reset_nmetod_marking(). > I think that these checks are not needed since 8020151, since we do stack scanning of > active nmethods irrespective of the value of what need_marking_phase() returns. Since > the patch removes need_marking_phase() printing out the warning (line 327 in > sweeper.cpp) is incorrect, i.e., we continue to invoke the sweeper. I removed the warning > and the associated code. Don't put mark_active_nmethods() under !UseCodeCacheFlushing condition. We always want to reclaim space in codecache. To do nmethod marking at each safepoint is fine (we have to do it to make sure we did not miss live nmethods). But with your changes each safepoint triggers sweep. Do we really need sweep so frequently? Why to sweep if there were no nmethods state change and there is enough space in CodeCache. So I am not sure about removing _request_mark_phase, init it with 'true' is okay. The warning was useless so it is okay to remove it and corresponding code. > > > Also, I think that we can either remove -XX:MethodFlushing or -XX:UseCodeCacheFlushing. Since 8020151, one of them is > redundant and can be removed. I am not quite sure if we should do that now so it is not included in the patch. It is for separate change. MethodFlushing is obsolete because we can not run VM without codecache sweeping because we loose performance since we go into Interpreter after codecache filled. Did you tried to run with it OFF? I think it is good candidate to go. The problem with UseCodeCacheFlushing is it becomes famous so you can't remove it easily. But don't replace MethodFlushing with it. I think code which currently guarded by MethodFlushing should be executed unconditionally. In arguments.cpp there is table for obsolete flags: static ObsoleteFlag obsolete_jvm_flags[] = { jdk8 is major release so we can change flags. Add MethodFlushing there to remove it in jdk9: { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, Thanks, Vladimir > > Testing > bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a performance evaluation. > > Many thanks for looking at the patch. > Best, > Albert From vladimir.x.ivanov at oracle.com Tue Nov 5 10:57:24 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 05 Nov 2013 22:57:24 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <5278EE72.3000401@oracle.com> References: <5278D8EA.3030104@oracle.com> <4AD63546-A4A2-47E9-8EFE-8583386E6F2D@oracle.com> <5278EE72.3000401@oracle.com> Message-ID: <52793F94.3020203@oracle.com> Albert, Roland, I take my words back about sweeper. The method is invalidated during class redefinition because it is dependent on redefined class (CodeCache::make_marked_nmethods_not_entrant()). Best regards, Vladimir Ivanov On 11/5/13 5:11 PM, Albert Noll wrote: > Hi Vladimir, > > I have a question: the sweeper calls make_not_entrant() on a nmethod > only after the nmethod > has been in the code cache for at least 10 occurrences of a safepoint > (time_since_reset in sweeper.ccp). > > Couldn't it also be that we mistakenly call the function > make_not_entrant() from somewhere else and that this is the root cause > of the error? > > > Best, > Albert > > On 11/05/2013 01:47 PM, Roland Westrelin wrote: >> Hi Vladimir, >> >>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>> >>> There's a race between compiler thread during method registration and >>> sweeper: sweeper can invalidate a nmethod which hasn't been installed >>> yet. >>> >>> Consider the following scenario: >>> ciEnv::register_method: >>> - new nmethod(...) >>> >>> sweeper: >>> - invalidates newly allocated nmethod and patches VEP to call >>> handle_wrong_method >>> - tries to unlink it, but method()->from_compiled_entry() != >>> verified_entry_point() since nmethod hasn't been installed yet >>> >>> ciEnv::register_method: >>> - installs already invalidated nmethod >>> >>> Calling corresponding Java method will lead to infinite loop: VEP of >>> the compiled method calls handle_wrong_method and call site >>> resolution returns the very same compiled method. >> Does that mean StressNonEntrant is broken? >> >>> The fix is to grab a lock after nmethod is allocated in the code >>> cache and check that it hasn't been already invalidated by the >>> sweeper before proceeding. Sweeper already synchronizes on a nmethod >>> before invalidating it. >> Would another fix be to have the sweeper check that the method was >> made ready to execute before it attempts to make it not entrant? >> >> i.e. nmethod->method()->code() == nmethod >> >> Roland. > From vladimir.x.ivanov at oracle.com Tue Nov 5 11:00:13 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 05 Nov 2013 23:00:13 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: References: <5278D8EA.3030104@oracle.com> <4AD63546-A4A2-47E9-8EFE-8583386E6F2D@oracle.com> <52791170.7010205@oracle.com> Message-ID: <5279403D.6010703@oracle.com> >>> Does that mean StressNonEntrant is broken? >> Good point. Yes, StressNonEntrant is also broken. > > Should we do something about it? remove it? Yes. I'll remove it as part of this change. Thanks for catching that. > >>> Would another fix be to have the sweeper check that the method was made ready to execute before it attempts to make it not entrant? >>> >>> i.e. nmethod->method()->code() == nmethod >> I don't see any reason why it shouldn't work as well. But it means that marking method as non-entrant is not reliable - doesn't necessarily perform state transition. I don't think we want that. > > I meant change NMethodSweeper::process_nmethod(): > > if (!nm->is_locked_by_vm() && !nm->is_osr_method() && !nm->is_native_method() && nm->method()->code() == nm) { I was wrong about sweeper - invalidation comes as a result of class redefinition. So, if we want to filter out not-yet-registered nmethods, it should be done in nmethod::make_not_entrant_or_zombie. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Tue Nov 5 11:10:12 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 05 Nov 2013 23:10:12 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <5278D8EA.3030104@oracle.com> References: <5278D8EA.3030104@oracle.com> Message-ID: <52794294.9070105@oracle.com> Updated fix: http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ Removed broken StressNonEntrant code. Updated comments. Best regards, Vladimir Ivanov On 11/5/13 3:39 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ > > There's a race between compiler thread during method registration and > sweeper: sweeper can invalidate a nmethod which hasn't been installed yet. > > Consider the following scenario: > ciEnv::register_method: > - new nmethod(...) > > sweeper: > - invalidates newly allocated nmethod and patches VEP to call > handle_wrong_method > - tries to unlink it, but method()->from_compiled_entry() != > verified_entry_point() since nmethod hasn't been installed yet > > ciEnv::register_method: > - installs already invalidated nmethod > > Calling corresponding Java method will lead to infinite loop: VEP of the > compiled method calls handle_wrong_method and call site resolution > returns the very same compiled method. > > The fix is to grab a lock after nmethod is allocated in the code cache > and check that it hasn't been already invalidated by the sweeper before > proceeding. Sweeper already synchronizes on a nmethod before > invalidating it. > > Testing: failing test w/ diagnostic output. > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Tue Nov 5 11:25:56 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Nov 2013 11:25:56 -0800 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <52794294.9070105@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> Message-ID: <52794644.6040307@oracle.com> Should be http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ What about this place: src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { Vladimir On 11/5/13 11:10 AM, Vladimir Ivanov wrote: > Updated fix: > http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ > > Removed broken StressNonEntrant code. > Updated comments. > > Best regards, > Vladimir Ivanov > > On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >> >> There's a race between compiler thread during method registration and >> sweeper: sweeper can invalidate a nmethod which hasn't been installed >> yet. >> >> Consider the following scenario: >> ciEnv::register_method: >> - new nmethod(...) >> >> sweeper: >> - invalidates newly allocated nmethod and patches VEP to call >> handle_wrong_method >> - tries to unlink it, but method()->from_compiled_entry() != >> verified_entry_point() since nmethod hasn't been installed yet >> >> ciEnv::register_method: >> - installs already invalidated nmethod >> >> Calling corresponding Java method will lead to infinite loop: VEP of the >> compiled method calls handle_wrong_method and call site resolution >> returns the very same compiled method. >> >> The fix is to grab a lock after nmethod is allocated in the code cache >> and check that it hasn't been already invalidated by the sweeper before >> proceeding. Sweeper already synchronizes on a nmethod before >> invalidating it. >> >> Testing: failing test w/ diagnostic output. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From mikael.vidstedt at oracle.com Tue Nov 5 11:51:50 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 05 Nov 2013 11:51:50 -0800 Subject: RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION In-Reply-To: References: <5272E315.5080201@oracle.com> Message-ID: <52794C56.50304@oracle.com> John - that is a very good suggestion indeed, I took the liberty to copy your exact wording. All, I also added the closest I have gotten to a reproducer. Unfortunately it is not completely reliable, in that it does not always reproduce the bug, but I got it to the point where from empirical results it tickles the bug some 80% of the cases (at least on my machine). Please review the updated comments and the added test! Thanks, Mikael On 2013-11-04 11:58, John Rose wrote: > + // Skip the first one because that was already touched in the above > + // loop - the post decrement of temp means it's now a page below the > + // last touch > > The comments should say 'tmp' not 'temp'. Also, the phrases 'first one' and 'it's now a page below' are hard to understand, and (to me) slightly misleading. > > Suggest: > + // At this point, (tmp-0) is the last address touched, so don't touch it again. > + // (It was touched as (tmp-pagesize) but then tmp was post-decremented.) > + // Skip this address by starting at i=1, and touch a few more pages below. > + // N.B. It is important to touch all the down to and including i=StackShadowPages. > > ? John From mikael.vidstedt at oracle.com Tue Nov 5 12:01:50 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 05 Nov 2013 12:01:50 -0800 Subject: RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION In-Reply-To: <52794C56.50304@oracle.com> References: <5272E315.5080201@oracle.com> <52794C56.50304@oracle.com> Message-ID: <52794EAE.8020700@oracle.com> Then there's the small matter of actually pasting in the link: http://cr.openjdk.java.net/~mikael/webrevs/8026775/webrev.02/webrev/ Cheers, Mikael On 2013-11-05 11:51, Mikael Vidstedt wrote: > > John - that is a very good suggestion indeed, I took the liberty to > copy your exact wording. > > > All, > > I also added the closest I have gotten to a reproducer. Unfortunately > it is not completely reliable, in that it does not always reproduce > the bug, but I got it to the point where from empirical results it > tickles the bug some 80% of the cases (at least on my machine). > > Please review the updated comments and the added test! > > Thanks, > Mikael > > On 2013-11-04 11:58, John Rose wrote: >> + // Skip the first one because that was already touched in the above >> + // loop - the post decrement of temp means it's now a page below the >> + // last touch >> >> The comments should say 'tmp' not 'temp'. Also, the phrases 'first >> one' and 'it's now a page below' are hard to understand, and (to me) >> slightly misleading. >> >> Suggest: >> + // At this point, (tmp-0) is the last address touched, so don't >> touch it again. >> + // (It was touched as (tmp-pagesize) but then tmp was >> post-decremented.) >> + // Skip this address by starting at i=1, and touch a few more >> pages below. >> + // N.B. It is important to touch all the down to and including >> i=StackShadowPages. >> >> ? John > From vladimir.kozlov at oracle.com Tue Nov 5 12:10:55 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Nov 2013 12:10:55 -0800 Subject: RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION In-Reply-To: <52794EAE.8020700@oracle.com> References: <5272E315.5080201@oracle.com> <52794C56.50304@oracle.com> <52794EAE.8020700@oracle.com> Message-ID: <527950CF.1050607@oracle.com> Looks good. Thanks, Vladimir On 11/5/13 12:01 PM, Mikael Vidstedt wrote: > > Then there's the small matter of actually pasting in the link: > > http://cr.openjdk.java.net/~mikael/webrevs/8026775/webrev.02/webrev/ > > Cheers, > Mikael > > On 2013-11-05 11:51, Mikael Vidstedt wrote: >> >> John - that is a very good suggestion indeed, I took the liberty to >> copy your exact wording. >> >> >> All, >> >> I also added the closest I have gotten to a reproducer. Unfortunately >> it is not completely reliable, in that it does not always reproduce >> the bug, but I got it to the point where from empirical results it >> tickles the bug some 80% of the cases (at least on my machine). >> >> Please review the updated comments and the added test! >> >> Thanks, >> Mikael >> >> On 2013-11-04 11:58, John Rose wrote: >>> + // Skip the first one because that was already touched in the above >>> + // loop - the post decrement of temp means it's now a page below the >>> + // last touch >>> >>> The comments should say 'tmp' not 'temp'. Also, the phrases 'first >>> one' and 'it's now a page below' are hard to understand, and (to me) >>> slightly misleading. >>> >>> Suggest: >>> + // At this point, (tmp-0) is the last address touched, so don't >>> touch it again. >>> + // (It was touched as (tmp-pagesize) but then tmp was >>> post-decremented.) >>> + // Skip this address by starting at i=1, and touch a few more >>> pages below. >>> + // N.B. It is important to touch all the down to and including >>> i=StackShadowPages. >>> >>> ? John >> > From vladimir.x.ivanov at oracle.com Tue Nov 5 12:42:19 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 06 Nov 2013 00:42:19 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <52794644.6040307@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> Message-ID: <5279582B.2080208@oracle.com> Thanks! Missed that one. Fixed. http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 Best regards, Vladimir Ivanov On 11/5/13 11:25 PM, Vladimir Kozlov wrote: > Should be > > http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ > > What about this place: > > src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { > > Vladimir > > On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >> Updated fix: >> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >> >> Removed broken StressNonEntrant code. >> Updated comments. >> >> Best regards, >> Vladimir Ivanov >> >> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>> >>> There's a race between compiler thread during method registration and >>> sweeper: sweeper can invalidate a nmethod which hasn't been installed >>> yet. >>> >>> Consider the following scenario: >>> ciEnv::register_method: >>> - new nmethod(...) >>> >>> sweeper: >>> - invalidates newly allocated nmethod and patches VEP to call >>> handle_wrong_method >>> - tries to unlink it, but method()->from_compiled_entry() != >>> verified_entry_point() since nmethod hasn't been installed yet >>> >>> ciEnv::register_method: >>> - installs already invalidated nmethod >>> >>> Calling corresponding Java method will lead to infinite loop: VEP of the >>> compiled method calls handle_wrong_method and call site resolution >>> returns the very same compiled method. >>> >>> The fix is to grab a lock after nmethod is allocated in the code cache >>> and check that it hasn't been already invalidated by the sweeper before >>> proceeding. Sweeper already synchronizes on a nmethod before >>> invalidating it. >>> >>> Testing: failing test w/ diagnostic output. >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov From vladimir.kozlov at oracle.com Tue Nov 5 13:11:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Nov 2013 13:11:35 -0800 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <5279582B.2080208@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> Message-ID: <52795F07.5050306@oracle.com> Note nmethodLocker is not lock: void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { if (nm == NULL) return; Atomic::inc(&nm->_lock_count); guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie method"); } The guard is nm->is_locked_by_vm() but neither make_not_entrant_or_zombie () or register_method() use it. So how nmethodLocker helps here? Vladimir On 11/5/13 12:42 PM, Vladimir Ivanov wrote: > Thanks! Missed that one. Fixed. > > http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 > > Best regards, > Vladimir Ivanov > > On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >> Should be >> >> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >> >> What about this place: >> >> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { >> >> Vladimir >> >> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>> Updated fix: >>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>> >>> Removed broken StressNonEntrant code. >>> Updated comments. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>> >>>> There's a race between compiler thread during method registration and >>>> sweeper: sweeper can invalidate a nmethod which hasn't been installed >>>> yet. >>>> >>>> Consider the following scenario: >>>> ciEnv::register_method: >>>> - new nmethod(...) >>>> >>>> sweeper: >>>> - invalidates newly allocated nmethod and patches VEP to call >>>> handle_wrong_method >>>> - tries to unlink it, but method()->from_compiled_entry() != >>>> verified_entry_point() since nmethod hasn't been installed yet >>>> >>>> ciEnv::register_method: >>>> - installs already invalidated nmethod >>>> >>>> Calling corresponding Java method will lead to infinite loop: VEP of >>>> the >>>> compiled method calls handle_wrong_method and call site resolution >>>> returns the very same compiled method. >>>> >>>> The fix is to grab a lock after nmethod is allocated in the code cache >>>> and check that it hasn't been already invalidated by the sweeper before >>>> proceeding. Sweeper already synchronizes on a nmethod before >>>> invalidating it. >>>> >>>> Testing: failing test w/ diagnostic output. >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Tue Nov 5 13:52:46 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 06 Nov 2013 01:52:46 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <52795F07.5050306@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> Message-ID: <527968AE.8030107@oracle.com> Ouch, I was misled by it's name. So, I just lowered the likelihood of the failure then. make_not_entrant_or_zombie holds Patching_lock when it patches & unlinks a nmethod. Do you see any problems with using it to guard method installation (method->set_code(method, nm)) in register_method() as well? Best regards, Vladimir Ivanov On 11/6/13 1:11 AM, Vladimir Kozlov wrote: > Note nmethodLocker is not lock: > > void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { > if (nm == NULL) return; > Atomic::inc(&nm->_lock_count); > guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie method"); > } > > The guard is nm->is_locked_by_vm() but neither > make_not_entrant_or_zombie () or register_method() use it. > > So how nmethodLocker helps here? > > Vladimir > > On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >> Thanks! Missed that one. Fixed. >> >> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >> >> Best regards, >> Vladimir Ivanov >> >> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>> Should be >>> >>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>> >>> What about this place: >>> >>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { >>> >>> Vladimir >>> >>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>> Updated fix: >>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>> >>>> Removed broken StressNonEntrant code. >>>> Updated comments. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>> >>>>> There's a race between compiler thread during method registration and >>>>> sweeper: sweeper can invalidate a nmethod which hasn't been installed >>>>> yet. >>>>> >>>>> Consider the following scenario: >>>>> ciEnv::register_method: >>>>> - new nmethod(...) >>>>> >>>>> sweeper: >>>>> - invalidates newly allocated nmethod and patches VEP to call >>>>> handle_wrong_method >>>>> - tries to unlink it, but method()->from_compiled_entry() != >>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>> >>>>> ciEnv::register_method: >>>>> - installs already invalidated nmethod >>>>> >>>>> Calling corresponding Java method will lead to infinite loop: VEP of >>>>> the >>>>> compiled method calls handle_wrong_method and call site resolution >>>>> returns the very same compiled method. >>>>> >>>>> The fix is to grab a lock after nmethod is allocated in the code cache >>>>> and check that it hasn't been already invalidated by the sweeper >>>>> before >>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>> invalidating it. >>>>> >>>>> Testing: failing test w/ diagnostic output. >>>>> >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov From vladimir.kozlov at oracle.com Tue Nov 5 14:36:43 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Nov 2013 14:36:43 -0800 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527968AE.8030107@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> Message-ID: <527972FB.4050706@oracle.com> You need to be careful to avoid deadlock since there is call: 1035 old->make_not_entrant(); Any way there is comment in register_method(): 936 // Prevent SystemDictionary::add_to_hierarchy from running 937 // and invalidating our dependencies until we install this method. 938 MutexLocker ml(Compile_lock); So how it happens that the method is invalidated by dependencies? Thanks, Vladimir On 11/5/13 1:52 PM, Vladimir Ivanov wrote: > Ouch, I was misled by it's name. So, I just lowered the likelihood of > the failure then. > > make_not_entrant_or_zombie holds Patching_lock when it patches & unlinks > a nmethod. > > Do you see any problems with using it to guard method installation > (method->set_code(method, nm)) in register_method() as well? > > Best regards, > Vladimir Ivanov > > On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >> Note nmethodLocker is not lock: >> >> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >> if (nm == NULL) return; >> Atomic::inc(&nm->_lock_count); >> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >> method"); >> } >> >> The guard is nm->is_locked_by_vm() but neither >> make_not_entrant_or_zombie () or register_method() use it. >> >> So how nmethodLocker helps here? >> >> Vladimir >> >> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>> Thanks! Missed that one. Fixed. >>> >>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>> Should be >>>> >>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>> >>>> What about this place: >>>> >>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { >>>> >>>> Vladimir >>>> >>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>> Updated fix: >>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>> >>>>> Removed broken StressNonEntrant code. >>>>> Updated comments. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>> >>>>>> There's a race between compiler thread during method registration and >>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been installed >>>>>> yet. >>>>>> >>>>>> Consider the following scenario: >>>>>> ciEnv::register_method: >>>>>> - new nmethod(...) >>>>>> >>>>>> sweeper: >>>>>> - invalidates newly allocated nmethod and patches VEP to call >>>>>> handle_wrong_method >>>>>> - tries to unlink it, but method()->from_compiled_entry() != >>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>> >>>>>> ciEnv::register_method: >>>>>> - installs already invalidated nmethod >>>>>> >>>>>> Calling corresponding Java method will lead to infinite loop: VEP of >>>>>> the >>>>>> compiled method calls handle_wrong_method and call site resolution >>>>>> returns the very same compiled method. >>>>>> >>>>>> The fix is to grab a lock after nmethod is allocated in the code >>>>>> cache >>>>>> and check that it hasn't been already invalidated by the sweeper >>>>>> before >>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>> invalidating it. >>>>>> >>>>>> Testing: failing test w/ diagnostic output. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov From igor.veresov at oracle.com Tue Nov 5 15:11:08 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Nov 2013 15:11:08 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <5279344F.2060600@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> Message-ID: <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> Looks good. It?s not related to the change, but could you please consider adding some printing under PrintMethodFlushing && Verbose for the case when the method is made not entrant and include hotness and threshold values? igor On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov wrote: > On 11/5/13 6:44 AM, Albert Noll wrote: >> Hi, >> >> could I get reviews for this small patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >> >> Problem: The implementation of the sweeper (8020151) causes a performance regression for small code cache sizes. There >> are two issues that cause this regression: >> 1) NmethodSweepFraction is only adjusted according to the ReservedCodecacheSize if TieredCompilation is enabled. As a >> result, NmethodSweepFraction remains 16 (if TieredCompilation is not used). This is way too large for small code cache >> sizes (e.g., <5m). >> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a result, mark_active_nmethods() did not set >> _invocations and _current, which results in not invoking the sweeper (calling sweep_code_cache()) at all. When >> TieredCompilation is enabled this was not an issue, since NmethodSweeper::notify() (which sets _request_mark_phase) is >> called much more frequently. >> >> Solution: 1) Move setting of NmethodSweepFraction so that it is always executed. > > Good. > >> Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), and reset_nmetod_marking(). >> I think that these checks are not needed since 8020151, since we do stack scanning of >> active nmethods irrespective of the value of what need_marking_phase() returns. Since >> the patch removes need_marking_phase() printing out the warning (line 327 in >> sweeper.cpp) is incorrect, i.e., we continue to invoke the sweeper. I removed the warning >> and the associated code. > > Don't put mark_active_nmethods() under !UseCodeCacheFlushing condition. We always want to reclaim space in codecache. > > To do nmethod marking at each safepoint is fine (we have to do it to make sure we did not miss live nmethods). But with your changes each safepoint triggers sweep. Do we really need sweep so frequently? Why to sweep if there were no nmethods state change and there is enough space in CodeCache. So I am not sure about removing _request_mark_phase, init it with 'true' is okay. > > The warning was useless so it is okay to remove it and corresponding code. > >> >> >> Also, I think that we can either remove -XX:MethodFlushing or -XX:UseCodeCacheFlushing. Since 8020151, one of them is >> redundant and can be removed. I am not quite sure if we should do that now so it is not included in the patch. > > It is for separate change. > > MethodFlushing is obsolete because we can not run VM without codecache sweeping because we loose performance since we go into Interpreter after codecache filled. Did you tried to run with it OFF? I think it is good candidate to go. > > The problem with UseCodeCacheFlushing is it becomes famous so you can't remove it easily. But don't replace MethodFlushing with it. I think code which currently guarded by MethodFlushing should be executed unconditionally. > > In arguments.cpp there is table for obsolete flags: > static ObsoleteFlag obsolete_jvm_flags[] = { > > jdk8 is major release so we can change flags. Add MethodFlushing there to remove it in jdk9: > { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, > > Thanks, > Vladimir > >> >> Testing >> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a performance evaluation. >> >> Many thanks for looking at the patch. >> Best, >> Albert From john.r.rose at oracle.com Tue Nov 5 17:52:34 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 5 Nov 2013 17:52:34 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> Message-ID: <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> Good idea. -- John (on my iPhone) On Nov 5, 2013, at 3:11 PM, Igor Veresov wrote: > Looks good. It?s not related to the change, but could you please consider adding some printing under PrintMethodFlushing && Verbose for the case when the method is made not entrant and include hotness and threshold values? > > igor > > On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov wrote: > >> On 11/5/13 6:44 AM, Albert Noll wrote: >>> Hi, >>> >>> could I get reviews for this small patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>> >>> Problem: The implementation of the sweeper (8020151) causes a performance regression for small code cache sizes. There >>> are two issues that cause this regression: >>> 1) NmethodSweepFraction is only adjusted according to the ReservedCodecacheSize if TieredCompilation is enabled. As a >>> result, NmethodSweepFraction remains 16 (if TieredCompilation is not used). This is way too large for small code cache >>> sizes (e.g., <5m). >>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a result, mark_active_nmethods() did not set >>> _invocations and _current, which results in not invoking the sweeper (calling sweep_code_cache()) at all. When >>> TieredCompilation is enabled this was not an issue, since NmethodSweeper::notify() (which sets _request_mark_phase) is >>> called much more frequently. >>> >>> Solution: 1) Move setting of NmethodSweepFraction so that it is always executed. >> >> Good. >> >>> Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), and reset_nmetod_marking(). >>> I think that these checks are not needed since 8020151, since we do stack scanning of >>> active nmethods irrespective of the value of what need_marking_phase() returns. Since >>> the patch removes need_marking_phase() printing out the warning (line 327 in >>> sweeper.cpp) is incorrect, i.e., we continue to invoke the sweeper. I removed the warning >>> and the associated code. >> >> Don't put mark_active_nmethods() under !UseCodeCacheFlushing condition. We always want to reclaim space in codecache. >> >> To do nmethod marking at each safepoint is fine (we have to do it to make sure we did not miss live nmethods). But with your changes each safepoint triggers sweep. Do we really need sweep so frequently? Why to sweep if there were no nmethods state change and there is enough space in CodeCache. So I am not sure about removing _request_mark_phase, init it with 'true' is okay. >> >> The warning was useless so it is okay to remove it and corresponding code. >> >>> >>> >>> Also, I think that we can either remove -XX:MethodFlushing or -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>> redundant and can be removed. I am not quite sure if we should do that now so it is not included in the patch. >> >> It is for separate change. >> >> MethodFlushing is obsolete because we can not run VM without codecache sweeping because we loose performance since we go into Interpreter after codecache filled. Did you tried to run with it OFF? I think it is good candidate to go. >> >> The problem with UseCodeCacheFlushing is it becomes famous so you can't remove it easily. But don't replace MethodFlushing with it. I think code which currently guarded by MethodFlushing should be executed unconditionally. >> >> In arguments.cpp there is table for obsolete flags: >> static ObsoleteFlag obsolete_jvm_flags[] = { >> >> jdk8 is major release so we can change flags. Add MethodFlushing there to remove it in jdk9: >> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >> >> Thanks, >> Vladimir >> >>> >>> Testing >>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a performance evaluation. >>> >>> Many thanks for looking at the patch. >>> Best, >>> Albert > From chris.plummer at oracle.com Tue Nov 5 17:59:29 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 05 Nov 2013 17:59:29 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <52790459.7050607@oracle.com> References: <52790459.7050607@oracle.com> Message-ID: <5279A281.1050600@oracle.com> Hi Albert, I applied your patch and got some new numbers. Performance is now even better than it was with b110. See the chart I added to the bug. Nice work! Chris On 11/5/13 6:44 AM, Albert Noll wrote: > Hi, > > could I get reviews for this small patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8027593 > webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ > > Problem: The implementation of the sweeper (8020151) causes a > performance regression for small code cache sizes. There are two > issues that cause this regression: > 1) NmethodSweepFraction is only adjusted according to the > ReservedCodecacheSize if TieredCompilation is enabled. As a result, > NmethodSweepFraction remains 16 (if TieredCompilation is not used). > This is way too large for small code cache sizes (e.g., <5m). > 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a > result, mark_active_nmethods() did not set _invocations and _current, > which results in not invoking the sweeper (calling sweep_code_cache()) > at all. When TieredCompilation is enabled this was not an issue, since > NmethodSweeper::notify() (which sets _request_mark_phase) is called > much more frequently. > > Solution: 1) Move setting of NmethodSweepFraction so that it is always > executed. > Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), > and reset_nmetod_marking(). > I think that these checks are not needed since > 8020151, since we do stack scanning of > active nmethods irrespective of the value of what > need_marking_phase() returns. Since > the patch removes need_marking_phase() printing out > the warning (line 327 in > sweeper.cpp) is incorrect, i.e., we continue to > invoke the sweeper. I removed the warning > and the associated code. > > > Also, I think that we can either remove -XX:MethodFlushing or > -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant and > can be removed. I am not quite sure if we should do that now so it is > not included in the patch. > > Testing > bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a > performance evaluation. > > Many thanks for looking at the patch. > Best, > Albert From chris.plummer at oracle.com Tue Nov 5 18:18:00 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 05 Nov 2013 18:18:00 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <5279A281.1050600@oracle.com> References: <52790459.7050607@oracle.com> <5279A281.1050600@oracle.com> Message-ID: <5279A6D8.9070503@oracle.com> BTW, one thing I forgot to mention is I now see a lot of messages for the codecache filling up. For example: Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has been disabled. Java HotSpot(TM) Client VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= CodeCache: size=2700Kb used=2196Kb max_used=2196Kb free=503Kb With b111, I was only seeing one message. I suspect with b111, once this message appeared compilation was never re-enabled so the message never appeared again. In that case seeing in many times now is actually a good indicator. However, it appears even when not using -XX:+PrintCodeCache, and I can see this output being a distraction for programs whose normal operation may involve constraining the codecache and having it constantly filling up. Perhaps this message should be off by default, or possibly only appear once. cheers, Chris On 11/5/13 5:59 PM, Chris Plummer wrote: > Hi Albert, > > I applied your patch and got some new numbers. Performance is now even > better than it was with b110. See the chart I added to the bug. > > Nice work! > > Chris > > On 11/5/13 6:44 AM, Albert Noll wrote: >> Hi, >> >> could I get reviews for this small patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >> >> Problem: The implementation of the sweeper (8020151) causes a >> performance regression for small code cache sizes. There are two >> issues that cause this regression: >> 1) NmethodSweepFraction is only adjusted according to the >> ReservedCodecacheSize if TieredCompilation is enabled. As a result, >> NmethodSweepFraction remains 16 (if TieredCompilation is not used). >> This is way too large for small code cache sizes (e.g., <5m). >> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >> result, mark_active_nmethods() did not set _invocations and _current, >> which results in not invoking the sweeper (calling >> sweep_code_cache()) at all. When TieredCompilation is enabled this >> was not an issue, since NmethodSweeper::notify() (which sets >> _request_mark_phase) is called much more frequently. >> >> Solution: 1) Move setting of NmethodSweepFraction so that it is >> always executed. >> Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), >> and reset_nmetod_marking(). >> I think that these checks are not needed since >> 8020151, since we do stack scanning of >> active nmethods irrespective of the value of what >> need_marking_phase() returns. Since >> the patch removes need_marking_phase() printing >> out the warning (line 327 in >> sweeper.cpp) is incorrect, i.e., we continue to >> invoke the sweeper. I removed the warning >> and the associated code. >> >> >> Also, I think that we can either remove -XX:MethodFlushing or >> -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant and >> can be removed. I am not quite sure if we should do that now so it is >> not included in the patch. >> >> Testing >> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >> performance evaluation. >> >> Many thanks for looking at the patch. >> Best, >> Albert > From roland.westrelin at oracle.com Wed Nov 6 08:53:10 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 6 Nov 2013 17:53:10 +0100 Subject: RFR(S): 8027631: "unexpected profiling mismatch" error with new type profiling Message-ID: <97427AA4-EC00-417F-ABCC-EC7F6658775C@oracle.com> http://cr.openjdk.java.net/~roland/8027631/webrev.00/ The c1 profile collection code relies on the signature of the callee to figure out whether there?s a single possible class for an argument (to then not emit code that deal with conflicting profiles). The problem is that at a method handle invoke, a single call site can call different methods with different signature. So using the callee signature is not correct even though it can still be useful because it provides information about the types of arguments/return value. This change uses the signature from the call site to decide whether a single class is possible and the signature of the callee to improve the type of the arguments/return value more. The test case revealed another problem with profiling: profiling of arguments at a method handle call should skip over the first argument if the call is to a static method from a virtual method handle method because it?s not an argument at the call. Roland. From roland.westrelin at oracle.com Wed Nov 6 09:11:27 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 6 Nov 2013 18:11:27 +0100 Subject: RFR(S): 8027572: assert(r != 0) failed: invalid Message-ID: <0E9B433E-363C-4B24-8EEA-1A937FFE3F51@oracle.com> http://cr.openjdk.java.net/~roland/8027572/webrev.00/ During profile collection, the first time a type is seen it is recorded in the profile. If a different class is seen later on, the profile code sets the unknown bit but doesn?t clear the recorded type so the code expects that if the unknown bit is set then a type is recorded. When c1 collects the profiles, if some class is already recorded and it knowns the type will differ, it only emits code to set the unknown bit. If the class that is already recorded is unloaded, then the profile is cleared but the c1 code is not changed and so may set the unknown bit in a cleared profile. I changed the code so that a class is no longer expected in the profile if the unknown bit is set. When a class recorded in a profile is unloaded the previous code would reset the profile not preserving the null and unknown bit. That doesn?t really make sense so I changed that. Also, there was a bug with parameters for which class unloading wouldn?t be propagated to the profiles and we could end up with an invalid class pointer in the profile. Roland. From vladimir.x.ivanov at oracle.com Wed Nov 6 06:57:44 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 06 Nov 2013 18:57:44 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527972FB.4050706@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> Message-ID: <527A58E8.9050405@oracle.com> Very good point, Vladimir! I should have looked for the bug in a different place :-) The problem is triggered by class redefinition and it can be performed under Compile_lock or during safepoint. So, in ciEnv::register_method it's not enough to grab Compile_lock. In addition, we need to ensure that there are no safepoints possible during method installation to guarantee no dependency is invalidated. There's one place in nmethod verification code (see MutexLocker ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where safepoint is possible and it causes the failure. The bug is present only in non-product builds since nmethod verification is absent in product bits. Previous fix also works, but I decided to go another route and forbid safepoints at all while holding Compile_lock. Updated webrev (will appear once cr.ojn is up): http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ Best regards, Vladimir Ivanov On 11/6/13 2:36 AM, Vladimir Kozlov wrote: > You need to be careful to avoid deadlock since there is call: > > 1035 old->make_not_entrant(); > > Any way there is comment in register_method(): > > 936 // Prevent SystemDictionary::add_to_hierarchy from running > 937 // and invalidating our dependencies until we install this > method. > 938 MutexLocker ml(Compile_lock); > > So how it happens that the method is invalidated by dependencies? > > Thanks, > Vladimir > > On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >> Ouch, I was misled by it's name. So, I just lowered the likelihood of >> the failure then. >> >> make_not_entrant_or_zombie holds Patching_lock when it patches & unlinks >> a nmethod. >> >> Do you see any problems with using it to guard method installation >> (method->set_code(method, nm)) in register_method() as well? >> >> Best regards, >> Vladimir Ivanov >> >> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>> Note nmethodLocker is not lock: >>> >>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>> if (nm == NULL) return; >>> Atomic::inc(&nm->_lock_count); >>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>> method"); >>> } >>> >>> The guard is nm->is_locked_by_vm() but neither >>> make_not_entrant_or_zombie () or register_method() use it. >>> >>> So how nmethodLocker helps here? >>> >>> Vladimir >>> >>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>> Thanks! Missed that one. Fixed. >>>> >>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>> Should be >>>>> >>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>> >>>>> What about this place: >>>>> >>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { >>>>> >>>>> Vladimir >>>>> >>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>> Updated fix: >>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>> >>>>>> Removed broken StressNonEntrant code. >>>>>> Updated comments. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>> >>>>>>> There's a race between compiler thread during method registration >>>>>>> and >>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>> installed >>>>>>> yet. >>>>>>> >>>>>>> Consider the following scenario: >>>>>>> ciEnv::register_method: >>>>>>> - new nmethod(...) >>>>>>> >>>>>>> sweeper: >>>>>>> - invalidates newly allocated nmethod and patches VEP to call >>>>>>> handle_wrong_method >>>>>>> - tries to unlink it, but method()->from_compiled_entry() != >>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>> >>>>>>> ciEnv::register_method: >>>>>>> - installs already invalidated nmethod >>>>>>> >>>>>>> Calling corresponding Java method will lead to infinite loop: VEP of >>>>>>> the >>>>>>> compiled method calls handle_wrong_method and call site resolution >>>>>>> returns the very same compiled method. >>>>>>> >>>>>>> The fix is to grab a lock after nmethod is allocated in the code >>>>>>> cache >>>>>>> and check that it hasn't been already invalidated by the sweeper >>>>>>> before >>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>> invalidating it. >>>>>>> >>>>>>> Testing: failing test w/ diagnostic output. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov From vladimir.kozlov at oracle.com Wed Nov 6 11:05:47 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Nov 2013 11:05:47 -0800 Subject: RFR(S): 8027631: "unexpected profiling mismatch" error with new type profiling In-Reply-To: <97427AA4-EC00-417F-ABCC-EC7F6658775C@oracle.com> References: <97427AA4-EC00-417F-ABCC-EC7F6658775C@oracle.com> Message-ID: <527A930B.8080804@oracle.com> Changes looks fine. Add -XX:+IgnoreUnrecognizedVMOptions to test's flags since Client VM may not recognise tiered flags. Thanks, Vladimir On 11/6/13 8:53 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8027631/webrev.00/ > > The c1 profile collection code relies on the signature of the callee to figure out whether there?s a single possible class for an argument (to then not emit code that deal with conflicting profiles). The problem is that at a method handle invoke, a single call site can call different methods with different signature. So using the callee signature is not correct even though it can still be useful because it provides information about the types of arguments/return value. This change uses the signature from the call site to decide whether a single class is possible and the signature of the callee to improve the type of the arguments/return value more. The test case revealed another problem with profiling: profiling of arguments at a method handle call should skip over the first argument if the call is to a static method from a virtual method handle method because it?s not an argument at the call. > > Roland. > From vladimir.kozlov at oracle.com Wed Nov 6 11:10:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Nov 2013 11:10:01 -0800 Subject: RFR(S): 8027572: assert(r != 0) failed: invalid In-Reply-To: <0E9B433E-363C-4B24-8EEA-1A937FFE3F51@oracle.com> References: <0E9B433E-363C-4B24-8EEA-1A937FFE3F51@oracle.com> Message-ID: <527A9409.6080008@oracle.com> Good. Thanks, Vladimir On 11/6/13 9:11 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8027572/webrev.00/ > > During profile collection, the first time a type is seen it is recorded in the profile. If a different class is seen later on, the profile code sets the unknown bit but doesn?t clear the recorded type so the code expects that if the unknown bit is set then a type is recorded. When c1 collects the profiles, if some class is already recorded and it knowns the type will differ, it only emits code to set the unknown bit. If the class that is already recorded is unloaded, then the profile is cleared but the c1 code is not changed and so may set the unknown bit in a cleared profile. > > I changed the code so that a class is no longer expected in the profile if the unknown bit is set. When a class recorded in a profile is unloaded the previous code would reset the profile not preserving the null and unknown bit. That doesn?t really make sense so I changed that. Also, there was a bug with parameters for which class unloading wouldn?t be propagated to the profiles and we could end up with an invalid class pointer in the profile. > > Roland. > From vladimir.kozlov at oracle.com Wed Nov 6 13:46:44 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 06 Nov 2013 21:46:44 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION Message-ID: <20131106214647.0A8E3623DB@hg.openjdk.java.net> Changeset: be525e91f65b Author: mikael Date: 2013-11-06 06:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From vladimir.kozlov at oracle.com Wed Nov 6 14:52:24 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Nov 2013 14:52:24 -0800 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527A58E8.9050405@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> Message-ID: <527AC828.9000509@oracle.com> Vladimir, Thank you for finding the real cause. I think you need the comment before nm->verify() in new_nmethod() explaining why we should avoid safepoint as you explained here. I am not comfortable about passing new allow_safepoints parameter through all verify calls because it is the only one case. We still have not installed nmethod at this point. There should be some check (nmethod's flags/state) which we can use to skip CompiledIC_lock. I thought about the need to verify scopes in verify_interrupt_point() in all cases. But the verification code in ScopeDesc::verify() is commented. What? In general it is good to call it anyway. And you don't need IC to get the end_of_call() - I think we can inline what CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). This code calls CompiledIC_at() because it does IC verification which we can skip in our case. Thanks, Vladimir On 11/6/13 6:57 AM, Vladimir Ivanov wrote: > Very good point, Vladimir! > > I should have looked for the bug in a different place :-) > > The problem is triggered by class redefinition and it can be performed > under Compile_lock or during safepoint. So, in ciEnv::register_method > it's not enough to grab Compile_lock. In addition, we need to ensure > that there are no safepoints possible during method installation to > guarantee no dependency is invalidated. > > There's one place in nmethod verification code (see MutexLocker > ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where > safepoint is possible and it causes the failure. > > The bug is present only in non-product builds since nmethod verification > is absent in product bits. > > Previous fix also works, but I decided to go another route and forbid > safepoints at all while holding Compile_lock. > > Updated webrev (will appear once cr.ojn is up): > http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ > > Best regards, > Vladimir Ivanov > > On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >> You need to be careful to avoid deadlock since there is call: >> >> 1035 old->make_not_entrant(); >> >> Any way there is comment in register_method(): >> >> 936 // Prevent SystemDictionary::add_to_hierarchy from running >> 937 // and invalidating our dependencies until we install this >> method. >> 938 MutexLocker ml(Compile_lock); >> >> So how it happens that the method is invalidated by dependencies? >> >> Thanks, >> Vladimir >> >> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>> Ouch, I was misled by it's name. So, I just lowered the likelihood of >>> the failure then. >>> >>> make_not_entrant_or_zombie holds Patching_lock when it patches & unlinks >>> a nmethod. >>> >>> Do you see any problems with using it to guard method installation >>> (method->set_code(method, nm)) in register_method() as well? >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>> Note nmethodLocker is not lock: >>>> >>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>> if (nm == NULL) return; >>>> Atomic::inc(&nm->_lock_count); >>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>> method"); >>>> } >>>> >>>> The guard is nm->is_locked_by_vm() but neither >>>> make_not_entrant_or_zombie () or register_method() use it. >>>> >>>> So how nmethodLocker helps here? >>>> >>>> Vladimir >>>> >>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>> Thanks! Missed that one. Fixed. >>>>> >>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>> Should be >>>>>> >>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>> >>>>>> What about this place: >>>>>> >>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>> Updated fix: >>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>> >>>>>>> Removed broken StressNonEntrant code. >>>>>>> Updated comments. >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>> >>>>>>>> There's a race between compiler thread during method registration >>>>>>>> and >>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>> installed >>>>>>>> yet. >>>>>>>> >>>>>>>> Consider the following scenario: >>>>>>>> ciEnv::register_method: >>>>>>>> - new nmethod(...) >>>>>>>> >>>>>>>> sweeper: >>>>>>>> - invalidates newly allocated nmethod and patches VEP to call >>>>>>>> handle_wrong_method >>>>>>>> - tries to unlink it, but method()->from_compiled_entry() != >>>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>>> >>>>>>>> ciEnv::register_method: >>>>>>>> - installs already invalidated nmethod >>>>>>>> >>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>> VEP of >>>>>>>> the >>>>>>>> compiled method calls handle_wrong_method and call site resolution >>>>>>>> returns the very same compiled method. >>>>>>>> >>>>>>>> The fix is to grab a lock after nmethod is allocated in the code >>>>>>>> cache >>>>>>>> and check that it hasn't been already invalidated by the sweeper >>>>>>>> before >>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>> invalidating it. >>>>>>>> >>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov From igor.veresov at oracle.com Wed Nov 6 16:10:06 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 6 Nov 2013 16:10:06 -0800 Subject: RFR(S): 8027631: "unexpected profiling mismatch" error with new type profiling In-Reply-To: <97427AA4-EC00-417F-ABCC-EC7F6658775C@oracle.com> References: <97427AA4-EC00-417F-ABCC-EC7F6658775C@oracle.com> Message-ID: <2B563388-4D9B-446E-AADC-52C83E2B58A2@oracle.com> Looks good. igor On Nov 6, 2013, at 8:53 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8027631/webrev.00/ > > The c1 profile collection code relies on the signature of the callee to figure out whether there?s a single possible class for an argument (to then not emit code that deal with conflicting profiles). The problem is that at a method handle invoke, a single call site can call different methods with different signature. So using the callee signature is not correct even though it can still be useful because it provides information about the types of arguments/return value. This change uses the signature from the call site to decide whether a single class is possible and the signature of the callee to improve the type of the arguments/return value more. The test case revealed another problem with profiling: profiling of arguments at a method handle call should skip over the first argument if the call is to a static method from a virtual method handle method because it?s not an argument at the call. > > Roland. From igor.veresov at oracle.com Wed Nov 6 16:16:56 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 6 Nov 2013 16:16:56 -0800 Subject: RFR(S): 8027572: assert(r != 0) failed: invalid In-Reply-To: <0E9B433E-363C-4B24-8EEA-1A937FFE3F51@oracle.com> References: <0E9B433E-363C-4B24-8EEA-1A937FFE3F51@oracle.com> Message-ID: <3183BC83-BBA0-4015-8691-74EDF06F9860@oracle.com> Looks good. igor On Nov 6, 2013, at 9:11 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8027572/webrev.00/ > > During profile collection, the first time a type is seen it is recorded in the profile. If a different class is seen later on, the profile code sets the unknown bit but doesn?t clear the recorded type so the code expects that if the unknown bit is set then a type is recorded. When c1 collects the profiles, if some class is already recorded and it knowns the type will differ, it only emits code to set the unknown bit. If the class that is already recorded is unloaded, then the profile is cleared but the c1 code is not changed and so may set the unknown bit in a cleared profile. > > I changed the code so that a class is no longer expected in the profile if the unknown bit is set. When a class recorded in a profile is unloaded the previous code would reset the profile not preserving the null and unknown bit. That doesn?t really make sense so I changed that. Also, there was a bug with parameters for which class unloading wouldn?t be propagated to the profiles and we could end up with an invalid class pointer in the profile. > > Roland. From roland.westrelin at oracle.com Thu Nov 7 01:11:01 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 7 Nov 2013 10:11:01 +0100 Subject: RFR(S): 8027572: assert(r != 0) failed: invalid In-Reply-To: <3183BC83-BBA0-4015-8691-74EDF06F9860@oracle.com> References: <0E9B433E-363C-4B24-8EEA-1A937FFE3F51@oracle.com> <3183BC83-BBA0-4015-8691-74EDF06F9860@oracle.com> Message-ID: <910638F9-DF6C-42DD-991C-4ACEAD94AF48@oracle.com> Thanks Igor & Vladimir for the reviews. Roland. From roland.westrelin at oracle.com Thu Nov 7 01:39:51 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 7 Nov 2013 10:39:51 +0100 Subject: RFR(S): 8027631: "unexpected profiling mismatch" error with new type profiling In-Reply-To: <527A930B.8080804@oracle.com> References: <97427AA4-EC00-417F-ABCC-EC7F6658775C@oracle.com> <527A930B.8080804@oracle.com> Message-ID: <0108D02C-E148-4C53-86C7-401671B090DC@oracle.com> > Changes looks fine. Thanks for the review, Vladimir. > Add -XX:+IgnoreUnrecognizedVMOptions to test's flags since Client VM may not recognise tiered flags. All of the flags are defined in globals.hpp and exist for a client VM so it runs fine. Do you think I should add -XX:+IgnoreUnrecognizedVMOptions anyway? Roland. From roland.westrelin at oracle.com Thu Nov 7 01:40:08 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 7 Nov 2013 10:40:08 +0100 Subject: RFR(S): 8027631: "unexpected profiling mismatch" error with new type profiling In-Reply-To: <2B563388-4D9B-446E-AADC-52C83E2B58A2@oracle.com> References: <97427AA4-EC00-417F-ABCC-EC7F6658775C@oracle.com> <2B563388-4D9B-446E-AADC-52C83E2B58A2@oracle.com> Message-ID: <68DC558E-CA44-4FEB-95DA-49B83BA1BFE6@oracle.com> > Looks good. Thanks for the review, Igor. Roland. From albert.noll at oracle.com Thu Nov 7 03:20:00 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 07 Nov 2013 12:20:00 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> Message-ID: <527B7760.6040805@oracle.com> Vladimir, Igor, John, thanks for looking at the patch. Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ Please see comments inline. On 11/06/2013 02:52 AM, John Rose wrote: > Good idea. > > -- John (on my iPhone) > > On Nov 5, 2013, at 3:11 PM, Igor Veresov wrote: > >> Looks good. It?s not related to the change, but could you please consider adding some printing under PrintMethodFlushing && Verbose for the case when the method is made not entrant and include hotness and threshold values? >> >> igor I also agree. I added the print. >> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov wrote: >> >>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>> Hi, >>>> >>>> could I get reviews for this small patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>> >>>> Problem: The implementation of the sweeper (8020151) causes a performance regression for small code cache sizes. There >>>> are two issues that cause this regression: >>>> 1) NmethodSweepFraction is only adjusted according to the ReservedCodecacheSize if TieredCompilation is enabled. As a >>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is not used). This is way too large for small code cache >>>> sizes (e.g., <5m). >>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a result, mark_active_nmethods() did not set >>>> _invocations and _current, which results in not invoking the sweeper (calling sweep_code_cache()) at all. When >>>> TieredCompilation is enabled this was not an issue, since NmethodSweeper::notify() (which sets _request_mark_phase) is >>>> called much more frequently. >>>> >>>> Solution: 1) Move setting of NmethodSweepFraction so that it is always executed. >>> Good. >>> The place where I moved the adaption of NmethodSweepFraction is not good, since the the code cache size is adapted later for tiered. The current version should be fine. >>>> Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), and reset_nmetod_marking(). >>>> I think that these checks are not needed since 8020151, since we do stack scanning of >>>> active nmethods irrespective of the value of what need_marking_phase() returns. Since >>>> the patch removes need_marking_phase() printing out the warning (line 327 in >>>> sweeper.cpp) is incorrect, i.e., we continue to invoke the sweeper. I removed the warning >>>> and the associated code. >>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing condition. We always want to reclaim space in codecache. Done. >>> To do nmethod marking at each safepoint is fine (we have to do it to make sure we did not miss live nmethods). But with your changes each safepoint triggers sweep. Do we really need sweep so frequently? Why to sweep if there were no nmethods state change and there is enough space in CodeCache. So I am not sure about removing _request_mark_phase, init it with 'true' is okay. I agree. The current patch contains a more sophisticated logic to determine when we call the sweeper. The bottom line is that we do not invoke the sweeper only if: (1) The code cache is getting full and/or (2) There are sufficient state changes in the last sweep. The patch contains a detailed description + examples of the logic. I tested the patch with small code cache sizes (specjvm98 + <4m code cache), medium-sized code cache (128m + nashorn + octane), and large code cache (240m + nashorn + octane). The measurements indicate that with the current logic in place, we can reduce the number of sweeps by 50% for medium code cache sizes without increasing the maximum used code cache size. The difference is more or less not significant. Please let me know what you think about it. The main disadvantage I see with this change is that it makes reasoning about the sweeper harder than it was before. >>> The warning was useless so it is okay to remove it and corresponding code. >>> >>>> >>>> Also, I think that we can either remove -XX:MethodFlushing or -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>> redundant and can be removed. I am not quite sure if we should do that now so it is not included in the patch. >>> It is for separate change. >>> >>> MethodFlushing is obsolete because we can not run VM without codecache sweeping because we loose performance since we go into Interpreter after codecache filled. Did you tried to run with it OFF? I think it is good candidate to go. >>> >>> The problem with UseCodeCacheFlushing is it becomes famous so you can't remove it easily. But don't replace MethodFlushing with it. I think code which currently guarded by MethodFlushing should be executed unconditionally. >>> >>> In arguments.cpp there is table for obsolete flags: >>> static ObsoleteFlag obsolete_jvm_flags[] = { >>> >>> jdk8 is major release so we can change flags. Add MethodFlushing there to remove it in jdk9: >>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>> >>> Thanks, >>> Vladimir I'll file a new bug to remove the flag. I guess this change will most likely only make it into 8uXX. >>>> Testing >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a performance evaluation. >>>> >>>> Many thanks for looking at the patch. >>>> Best, >>>> Albert From albert.noll at oracle.com Thu Nov 7 03:24:01 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 07 Nov 2013 12:24:01 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <5279A6D8.9070503@oracle.com> References: <52790459.7050607@oracle.com> <5279A281.1050600@oracle.com> <5279A6D8.9070503@oracle.com> Message-ID: <527B7851.7000005@oracle.com> Hi Chris, On 11/06/2013 03:18 AM, Chris Plummer wrote: > BTW, one thing I forgot to mention is I now see a lot of messages for > the codecache filling up. For example: > > Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has > been disabled. > Java HotSpot(TM) Client VM warning: Try increasing the code cache size > using -XX:ReservedCodeCacheSize= > CodeCache: size=2700Kb used=2196Kb max_used=2196Kb free=503Kb > > With b111, I was only seeing one message. I suspect with b111, once > this message appeared compilation was never re-enabled so the message > never appeared again. In that case seeing in many times now is > actually a good indicator. However, it appears even when not using > -XX:+PrintCodeCache, and I can see this output being a distraction for > programs whose normal operation may involve constraining the codecache > and having it constantly filling up. Perhaps this message should be > off by default, or possibly only appear once. > You are right. The previous version just never re-enabled compilation. I also agree that the output is distracting. There are multiple ways to solve this issue. I would go for a product -XX flag which allows to turn this warning on/off. Would that be ok or do you have a different solution in mind? Best, Albert > cheers, > > Chris > > On 11/5/13 5:59 PM, Chris Plummer wrote: >> Hi Albert, >> >> I applied your patch and got some new numbers. Performance is now >> even better than it was with b110. See the chart I added to the bug. >> >> Nice work! >> >> Chris >> >> On 11/5/13 6:44 AM, Albert Noll wrote: >>> Hi, >>> >>> could I get reviews for this small patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>> >>> Problem: The implementation of the sweeper (8020151) causes a >>> performance regression for small code cache sizes. There are two >>> issues that cause this regression: >>> 1) NmethodSweepFraction is only adjusted according to the >>> ReservedCodecacheSize if TieredCompilation is enabled. As a result, >>> NmethodSweepFraction remains 16 (if TieredCompilation is not used). >>> This is way too large for small code cache sizes (e.g., <5m). >>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>> result, mark_active_nmethods() did not set _invocations and >>> _current, which results in not invoking the sweeper (calling >>> sweep_code_cache()) at all. When TieredCompilation is enabled this >>> was not an issue, since NmethodSweeper::notify() (which sets >>> _request_mark_phase) is called much more frequently. >>> >>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>> always executed. >>> Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), >>> and reset_nmetod_marking(). >>> I think that these checks are not needed since >>> 8020151, since we do stack scanning of >>> active nmethods irrespective of the value of what >>> need_marking_phase() returns. Since >>> the patch removes need_marking_phase() printing >>> out the warning (line 327 in >>> sweeper.cpp) is incorrect, i.e., we continue to >>> invoke the sweeper. I removed the warning >>> and the associated code. >>> >>> >>> Also, I think that we can either remove -XX:MethodFlushing or >>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant >>> and can be removed. I am not quite sure if we should do that now so >>> it is not included in the patch. >>> >>> Testing >>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>> performance evaluation. >>> >>> Many thanks for looking at the patch. >>> Best, >>> Albert >> > From albert.noll at oracle.com Thu Nov 7 03:27:03 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 07 Nov 2013 12:27:03 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527B7760.6040805@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> Message-ID: <527B7907.4040102@oracle.com> The previous mail contains an error. See inline. Albert On 11/07/2013 12:20 PM, Albert Noll wrote: > Vladimir, Igor, John, thanks for looking at the patch. > Here is the updated webrev: > > http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ > > Please see comments inline. > > > On 11/06/2013 02:52 AM, John Rose wrote: >> Good idea. >> >> -- John (on my iPhone) >> >> On Nov 5, 2013, at 3:11 PM, Igor Veresov >> wrote: >> >>> Looks good. It?s not related to the change, but could you please >>> consider adding some printing under PrintMethodFlushing && Verbose >>> for the case when the method is made not entrant and include hotness >>> and threshold values? >>> >>> igor > I also agree. I added the print. >>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>> wrote: >>> >>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>> Hi, >>>>> >>>>> could I get reviews for this small patch? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>> >>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>> performance regression for small code cache sizes. There >>>>> are two issues that cause this regression: >>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>> not used). This is way too large for small code cache >>>>> sizes (e.g., <5m). >>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>> result, mark_active_nmethods() did not set >>>>> _invocations and _current, which results in not invoking the >>>>> sweeper (calling sweep_code_cache()) at all. When >>>>> TieredCompilation is enabled this was not an issue, since >>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>> called much more frequently. >>>>> >>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>> always executed. >>>> Good. >>>> > The place where I moved the adaption of NmethodSweepFraction is not > good, since the > the code cache size is adapted later for tiered. The current version > should be fine. >>>>> Solution: 2) Remove need_marking_phase(), >>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>> I think that these checks are not needed since >>>>> 8020151, since we do stack scanning of >>>>> active nmethods irrespective of the value of >>>>> what need_marking_phase() returns. Since >>>>> the patch removes need_marking_phase() printing >>>>> out the warning (line 327 in >>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>> invoke the sweeper. I removed the warning >>>>> and the associated code. >>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>> condition. We always want to reclaim space in codecache. > Done. >>>> To do nmethod marking at each safepoint is fine (we have to do it >>>> to make sure we did not miss live nmethods). But with your changes >>>> each safepoint triggers sweep. Do we really need sweep so >>>> frequently? Why to sweep if there were no nmethods state change and >>>> there is enough space in CodeCache. So I am not sure about removing >>>> _request_mark_phase, init it with 'true' is okay. > I agree. The current patch contains a more sophisticated logic to > determine when we call the > sweeper. The bottom line is that we do not invoke the sweeper only if: !!!!We DO INVOKE the sweeper only if: > (1) The code cache is getting full and/or > (2) There are sufficient state changes in the last sweep. !!!!!(3) We have not been sweeping for 'some time' > > The patch contains a detailed description + examples of the logic. I > tested the patch > with small code cache sizes (specjvm98 + <4m code cache), medium-sized > code cache > (128m + nashorn + octane), and large code cache (240m + nashorn + > octane). The measurements > indicate that with the current logic in place, we can reduce the > number of sweeps by 50% for > medium code cache sizes without increasing the maximum used code cache > size. The difference > is more or less not significant. > > Please let me know what you think about it. The main disadvantage I > see with this change is that > it makes reasoning about the sweeper harder than it was before. > > > > >>>> The warning was useless so it is okay to remove it and >>>> corresponding code. >>>> >>>>> >>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>> redundant and can be removed. I am not quite sure if we should do >>>>> that now so it is not included in the patch. >>>> It is for separate change. >>>> >>>> MethodFlushing is obsolete because we can not run VM without >>>> codecache sweeping because we loose performance since we go into >>>> Interpreter after codecache filled. Did you tried to run with it >>>> OFF? I think it is good candidate to go. >>>> >>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>> think code which currently guarded by MethodFlushing should be >>>> executed unconditionally. >>>> >>>> In arguments.cpp there is table for obsolete flags: >>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>> >>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>> there to remove it in jdk9: >>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>> >>>> Thanks, >>>> Vladimir > I'll file a new bug to remove the flag. I guess this change will most > likely only make it into 8uXX. >>>>> Testing >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>> performance evaluation. >>>>> >>>>> Many thanks for looking at the patch. >>>>> Best, >>>>> Albert > From vladimir.x.ivanov at oracle.com Thu Nov 7 06:50:01 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 07 Nov 2013 18:50:01 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527AC828.9000509@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> Message-ID: <527BA899.2040708@oracle.com> Vladimir, thank you for the feedback. What do you think about the following version? http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ Best regards, Vladimir Ivanov On 11/7/13 2:52 AM, Vladimir Kozlov wrote: > Vladimir, > > Thank you for finding the real cause. > > I think you need the comment before nm->verify() in new_nmethod() > explaining why we should avoid safepoint as you explained here. > > I am not comfortable about passing new allow_safepoints parameter > through all verify calls because it is the only one case. We still have > not installed nmethod at this point. There should be some check > (nmethod's flags/state) which we can use to skip CompiledIC_lock. > > I thought about the need to verify scopes in verify_interrupt_point() in > all cases. But the verification code in ScopeDesc::verify() is > commented. What? In general it is good to call it anyway. And you don't > need IC to get the end_of_call() - I think we can inline what > CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). > > This code calls CompiledIC_at() because it does IC verification which we > can skip in our case. > > Thanks, > Vladimir > > On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >> Very good point, Vladimir! >> >> I should have looked for the bug in a different place :-) >> >> The problem is triggered by class redefinition and it can be performed >> under Compile_lock or during safepoint. So, in ciEnv::register_method >> it's not enough to grab Compile_lock. In addition, we need to ensure >> that there are no safepoints possible during method installation to >> guarantee no dependency is invalidated. >> >> There's one place in nmethod verification code (see MutexLocker >> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where >> safepoint is possible and it causes the failure. >> >> The bug is present only in non-product builds since nmethod verification >> is absent in product bits. >> >> Previous fix also works, but I decided to go another route and forbid >> safepoints at all while holding Compile_lock. >> >> Updated webrev (will appear once cr.ojn is up): >> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >> >> Best regards, >> Vladimir Ivanov >> >> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>> You need to be careful to avoid deadlock since there is call: >>> >>> 1035 old->make_not_entrant(); >>> >>> Any way there is comment in register_method(): >>> >>> 936 // Prevent SystemDictionary::add_to_hierarchy from running >>> 937 // and invalidating our dependencies until we install this >>> method. >>> 938 MutexLocker ml(Compile_lock); >>> >>> So how it happens that the method is invalidated by dependencies? >>> >>> Thanks, >>> Vladimir >>> >>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>> Ouch, I was misled by it's name. So, I just lowered the likelihood of >>>> the failure then. >>>> >>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>> unlinks >>>> a nmethod. >>>> >>>> Do you see any problems with using it to guard method installation >>>> (method->set_code(method, nm)) in register_method() as well? >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>> Note nmethodLocker is not lock: >>>>> >>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>> if (nm == NULL) return; >>>>> Atomic::inc(&nm->_lock_count); >>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>>> method"); >>>>> } >>>>> >>>>> The guard is nm->is_locked_by_vm() but neither >>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>> >>>>> So how nmethodLocker helps here? >>>>> >>>>> Vladimir >>>>> >>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>> Thanks! Missed that one. Fixed. >>>>>> >>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>> Should be >>>>>>> >>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>> >>>>>>> What about this place: >>>>>>> >>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>> Updated fix: >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>> >>>>>>>> Removed broken StressNonEntrant code. >>>>>>>> Updated comments. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>> >>>>>>>>> There's a race between compiler thread during method registration >>>>>>>>> and >>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>> installed >>>>>>>>> yet. >>>>>>>>> >>>>>>>>> Consider the following scenario: >>>>>>>>> ciEnv::register_method: >>>>>>>>> - new nmethod(...) >>>>>>>>> >>>>>>>>> sweeper: >>>>>>>>> - invalidates newly allocated nmethod and patches VEP to call >>>>>>>>> handle_wrong_method >>>>>>>>> - tries to unlink it, but method()->from_compiled_entry() != >>>>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>>>> >>>>>>>>> ciEnv::register_method: >>>>>>>>> - installs already invalidated nmethod >>>>>>>>> >>>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>>> VEP of >>>>>>>>> the >>>>>>>>> compiled method calls handle_wrong_method and call site resolution >>>>>>>>> returns the very same compiled method. >>>>>>>>> >>>>>>>>> The fix is to grab a lock after nmethod is allocated in the code >>>>>>>>> cache >>>>>>>>> and check that it hasn't been already invalidated by the sweeper >>>>>>>>> before >>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>> invalidating it. >>>>>>>>> >>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov From albert.noll at oracle.com Thu Nov 7 07:32:13 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 07 Nov 2013 16:32:13 +0100 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527BA899.2040708@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> Message-ID: <527BB27D.2030806@oracle.com> Hi Vladimir, I have a question concerning the following lines: *+ // Verify IC only when nmethod installation is finished.* *+ bool is_installed = !(_state == alive && method()->code() != this);* *+ if (is_installed) * Wouldn't it be also sufficient to check if a method is installed with the following lines? bool is_installed = method()->code() == this; Best, Albert On 11/07/2013 03:50 PM, Vladimir Ivanov wrote: > Vladimir, thank you for the feedback. > > What do you think about the following version? > http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ > > Best regards, > Vladimir Ivanov > > On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >> Vladimir, >> >> Thank you for finding the real cause. >> >> I think you need the comment before nm->verify() in new_nmethod() >> explaining why we should avoid safepoint as you explained here. >> >> I am not comfortable about passing new allow_safepoints parameter >> through all verify calls because it is the only one case. We still have >> not installed nmethod at this point. There should be some check >> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >> >> I thought about the need to verify scopes in verify_interrupt_point() in >> all cases. But the verification code in ScopeDesc::verify() is >> commented. What? In general it is good to call it anyway. And you don't >> need IC to get the end_of_call() - I think we can inline what >> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >> >> This code calls CompiledIC_at() because it does IC verification which we >> can skip in our case. >> >> Thanks, >> Vladimir >> >> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>> Very good point, Vladimir! >>> >>> I should have looked for the bug in a different place :-) >>> >>> The problem is triggered by class redefinition and it can be performed >>> under Compile_lock or during safepoint. So, in ciEnv::register_method >>> it's not enough to grab Compile_lock. In addition, we need to ensure >>> that there are no safepoints possible during method installation to >>> guarantee no dependency is invalidated. >>> >>> There's one place in nmethod verification code (see MutexLocker >>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where >>> safepoint is possible and it causes the failure. >>> >>> The bug is present only in non-product builds since nmethod >>> verification >>> is absent in product bits. >>> >>> Previous fix also works, but I decided to go another route and forbid >>> safepoints at all while holding Compile_lock. >>> >>> Updated webrev (will appear once cr.ojn is up): >>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>> You need to be careful to avoid deadlock since there is call: >>>> >>>> 1035 old->make_not_entrant(); >>>> >>>> Any way there is comment in register_method(): >>>> >>>> 936 // Prevent SystemDictionary::add_to_hierarchy from running >>>> 937 // and invalidating our dependencies until we install this >>>> method. >>>> 938 MutexLocker ml(Compile_lock); >>>> >>>> So how it happens that the method is invalidated by dependencies? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>> Ouch, I was misled by it's name. So, I just lowered the likelihood of >>>>> the failure then. >>>>> >>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>> unlinks >>>>> a nmethod. >>>>> >>>>> Do you see any problems with using it to guard method installation >>>>> (method->set_code(method, nm)) in register_method() as well? >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>> Note nmethodLocker is not lock: >>>>>> >>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>> if (nm == NULL) return; >>>>>> Atomic::inc(&nm->_lock_count); >>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>>>> method"); >>>>>> } >>>>>> >>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>> >>>>>> So how nmethodLocker helps here? >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>> Thanks! Missed that one. Fixed. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>> Should be >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>> >>>>>>>> What about this place: >>>>>>>> >>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>> Updated fix: >>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>> >>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>> Updated comments. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>> >>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>> registration >>>>>>>>>> and >>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>> installed >>>>>>>>>> yet. >>>>>>>>>> >>>>>>>>>> Consider the following scenario: >>>>>>>>>> ciEnv::register_method: >>>>>>>>>> - new nmethod(...) >>>>>>>>>> >>>>>>>>>> sweeper: >>>>>>>>>> - invalidates newly allocated nmethod and patches VEP to >>>>>>>>>> call >>>>>>>>>> handle_wrong_method >>>>>>>>>> - tries to unlink it, but >>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>>>>> >>>>>>>>>> ciEnv::register_method: >>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>> >>>>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>>>> VEP of >>>>>>>>>> the >>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>> resolution >>>>>>>>>> returns the very same compiled method. >>>>>>>>>> >>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the code >>>>>>>>>> cache >>>>>>>>>> and check that it hasn't been already invalidated by the sweeper >>>>>>>>>> before >>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>> invalidating it. >>>>>>>>>> >>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131107/536a7484/attachment-0001.html From vladimir.x.ivanov at oracle.com Thu Nov 7 07:50:37 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 07 Nov 2013 19:50:37 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527BB27D.2030806@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> <527BB27D.2030806@oracle.com> Message-ID: <527BB6CD.40004@oracle.com> Albert, I want to exclude only the case when a newly allocated method hasn't been installed yet. If (_state == alive) is missing, IC verification for non-entrant methods is skipped as well. Best regards, Vladimir Ivanov On 11/7/13 7:32 PM, Albert Noll wrote: > Hi Vladimir, > > I have a question concerning the following lines: > > *+ // Verify IC only when nmethod installation is finished.* > *+ bool is_installed = !(_state == alive && method()->code() != this);* > *+ if (is_installed) > > > * > > Wouldn't it be also sufficient to check if a method is installed with > the following lines? > > bool is_installed = method()->code() == this; > > > Best, > Albert > > > On 11/07/2013 03:50 PM, Vladimir Ivanov wrote: >> Vladimir, thank you for the feedback. >> >> What do you think about the following version? >> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ >> >> Best regards, >> Vladimir Ivanov >> >> On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >>> Vladimir, >>> >>> Thank you for finding the real cause. >>> >>> I think you need the comment before nm->verify() in new_nmethod() >>> explaining why we should avoid safepoint as you explained here. >>> >>> I am not comfortable about passing new allow_safepoints parameter >>> through all verify calls because it is the only one case. We still have >>> not installed nmethod at this point. There should be some check >>> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >>> >>> I thought about the need to verify scopes in verify_interrupt_point() in >>> all cases. But the verification code in ScopeDesc::verify() is >>> commented. What? In general it is good to call it anyway. And you don't >>> need IC to get the end_of_call() - I think we can inline what >>> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >>> >>> This code calls CompiledIC_at() because it does IC verification which we >>> can skip in our case. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>>> Very good point, Vladimir! >>>> >>>> I should have looked for the bug in a different place :-) >>>> >>>> The problem is triggered by class redefinition and it can be performed >>>> under Compile_lock or during safepoint. So, in ciEnv::register_method >>>> it's not enough to grab Compile_lock. In addition, we need to ensure >>>> that there are no safepoints possible during method installation to >>>> guarantee no dependency is invalidated. >>>> >>>> There's one place in nmethod verification code (see MutexLocker >>>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where >>>> safepoint is possible and it causes the failure. >>>> >>>> The bug is present only in non-product builds since nmethod >>>> verification >>>> is absent in product bits. >>>> >>>> Previous fix also works, but I decided to go another route and forbid >>>> safepoints at all while holding Compile_lock. >>>> >>>> Updated webrev (will appear once cr.ojn is up): >>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>>> You need to be careful to avoid deadlock since there is call: >>>>> >>>>> 1035 old->make_not_entrant(); >>>>> >>>>> Any way there is comment in register_method(): >>>>> >>>>> 936 // Prevent SystemDictionary::add_to_hierarchy from running >>>>> 937 // and invalidating our dependencies until we install this >>>>> method. >>>>> 938 MutexLocker ml(Compile_lock); >>>>> >>>>> So how it happens that the method is invalidated by dependencies? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>>> Ouch, I was misled by it's name. So, I just lowered the likelihood of >>>>>> the failure then. >>>>>> >>>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>>> unlinks >>>>>> a nmethod. >>>>>> >>>>>> Do you see any problems with using it to guard method installation >>>>>> (method->set_code(method, nm)) in register_method() as well? >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>>> Note nmethodLocker is not lock: >>>>>>> >>>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>>> if (nm == NULL) return; >>>>>>> Atomic::inc(&nm->_lock_count); >>>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>>>>> method"); >>>>>>> } >>>>>>> >>>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>>> >>>>>>> So how nmethodLocker helps here? >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>>> Thanks! Missed that one. Fixed. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>>> Should be >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>>> >>>>>>>>> What about this place: >>>>>>>>> >>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>>> Updated fix: >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>> >>>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>>> Updated comments. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>>> registration >>>>>>>>>>> and >>>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>>> installed >>>>>>>>>>> yet. >>>>>>>>>>> >>>>>>>>>>> Consider the following scenario: >>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>> - new nmethod(...) >>>>>>>>>>> >>>>>>>>>>> sweeper: >>>>>>>>>>> - invalidates newly allocated nmethod and patches VEP to >>>>>>>>>>> call >>>>>>>>>>> handle_wrong_method >>>>>>>>>>> - tries to unlink it, but >>>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>>>>>> >>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>>> >>>>>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>>>>> VEP of >>>>>>>>>>> the >>>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>>> resolution >>>>>>>>>>> returns the very same compiled method. >>>>>>>>>>> >>>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the code >>>>>>>>>>> cache >>>>>>>>>>> and check that it hasn't been already invalidated by the sweeper >>>>>>>>>>> before >>>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>>> invalidating it. >>>>>>>>>>> >>>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Vladimir Ivanov > From albert.noll at oracle.com Thu Nov 7 08:12:15 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 07 Nov 2013 17:12:15 +0100 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527BB6CD.40004@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> <527BB27D.2030806@oracle.com> <527BB6CD.40004@oracle.com> Message-ID: <527BBBDF.9090307@oracle.com> Hi Vladimir, thanks for the explanation. So it is equivalent to the following statement: bool is_installed = method->code() == this || // method is in state alive and installed !method->is_in_use() // method is installed and in state: 'not-entrant', 'zombie', or, 'unloaded' Here are some thoughs that came to my mind when I was working with the sweeper... It is confusing that nm->is_in_use() returns true although the method has not yet been installed. A cleaner solution (but I assume it is not time time to do that in RDP2) would probably be to introduce a new state 'created', to which a nmethod is initialized when it is created. The nmethod would change the state to 'in_use' when it is installed. Best, Albert On 11/07/2013 04:50 PM, Vladimir Ivanov wrote: > Albert, > > I want to exclude only the case when a newly allocated method hasn't > been installed yet. If (_state == alive) is missing, IC verification > for non-entrant methods is skipped as well. > > Best regards, > Vladimir Ivanov > > On 11/7/13 7:32 PM, Albert Noll wrote: >> Hi Vladimir, >> >> I have a question concerning the following lines: >> >> *+ // Verify IC only when nmethod installation is finished.* >> *+ bool is_installed = !(_state == alive && method()->code() != >> this);* >> *+ if (is_installed) >> >> >> * >> >> Wouldn't it be also sufficient to check if a method is installed with >> the following lines? >> >> bool is_installed = method()->code() == this; >> >> >> Best, >> Albert >> >> >> On 11/07/2013 03:50 PM, Vladimir Ivanov wrote: >>> Vladimir, thank you for the feedback. >>> >>> What do you think about the following version? >>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >>>> Vladimir, >>>> >>>> Thank you for finding the real cause. >>>> >>>> I think you need the comment before nm->verify() in new_nmethod() >>>> explaining why we should avoid safepoint as you explained here. >>>> >>>> I am not comfortable about passing new allow_safepoints parameter >>>> through all verify calls because it is the only one case. We still >>>> have >>>> not installed nmethod at this point. There should be some check >>>> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >>>> >>>> I thought about the need to verify scopes in >>>> verify_interrupt_point() in >>>> all cases. But the verification code in ScopeDesc::verify() is >>>> commented. What? In general it is good to call it anyway. And you >>>> don't >>>> need IC to get the end_of_call() - I think we can inline what >>>> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >>>> >>>> This code calls CompiledIC_at() because it does IC verification >>>> which we >>>> can skip in our case. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>>>> Very good point, Vladimir! >>>>> >>>>> I should have looked for the bug in a different place :-) >>>>> >>>>> The problem is triggered by class redefinition and it can be >>>>> performed >>>>> under Compile_lock or during safepoint. So, in ciEnv::register_method >>>>> it's not enough to grab Compile_lock. In addition, we need to ensure >>>>> that there are no safepoints possible during method installation to >>>>> guarantee no dependency is invalidated. >>>>> >>>>> There's one place in nmethod verification code (see MutexLocker >>>>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where >>>>> safepoint is possible and it causes the failure. >>>>> >>>>> The bug is present only in non-product builds since nmethod >>>>> verification >>>>> is absent in product bits. >>>>> >>>>> Previous fix also works, but I decided to go another route and forbid >>>>> safepoints at all while holding Compile_lock. >>>>> >>>>> Updated webrev (will appear once cr.ojn is up): >>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>>>> You need to be careful to avoid deadlock since there is call: >>>>>> >>>>>> 1035 old->make_not_entrant(); >>>>>> >>>>>> Any way there is comment in register_method(): >>>>>> >>>>>> 936 // Prevent SystemDictionary::add_to_hierarchy from running >>>>>> 937 // and invalidating our dependencies until we install this >>>>>> method. >>>>>> 938 MutexLocker ml(Compile_lock); >>>>>> >>>>>> So how it happens that the method is invalidated by dependencies? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>>>> Ouch, I was misled by it's name. So, I just lowered the >>>>>>> likelihood of >>>>>>> the failure then. >>>>>>> >>>>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>>>> unlinks >>>>>>> a nmethod. >>>>>>> >>>>>>> Do you see any problems with using it to guard method installation >>>>>>> (method->set_code(method, nm)) in register_method() as well? >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>>>> Note nmethodLocker is not lock: >>>>>>>> >>>>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>>>> if (nm == NULL) return; >>>>>>>> Atomic::inc(&nm->_lock_count); >>>>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>>>>>> method"); >>>>>>>> } >>>>>>>> >>>>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>>>> >>>>>>>> So how nmethodLocker helps here? >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>>>> Thanks! Missed that one. Fixed. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>>>> Should be >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>>>> >>>>>>>>>> What about this place: >>>>>>>>>> >>>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if >>>>>>>>>> (StressNonEntrant) { >>>>>>>>>> >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>>>> Updated fix: >>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>>>> Updated comments. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>> >>>>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>>>> registration >>>>>>>>>>>> and >>>>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>>>> installed >>>>>>>>>>>> yet. >>>>>>>>>>>> >>>>>>>>>>>> Consider the following scenario: >>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>> - new nmethod(...) >>>>>>>>>>>> >>>>>>>>>>>> sweeper: >>>>>>>>>>>> - invalidates newly allocated nmethod and patches VEP to >>>>>>>>>>>> call >>>>>>>>>>>> handle_wrong_method >>>>>>>>>>>> - tries to unlink it, but >>>>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>>>>>>> >>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>>>> >>>>>>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>>>>>> VEP of >>>>>>>>>>>> the >>>>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>>>> resolution >>>>>>>>>>>> returns the very same compiled method. >>>>>>>>>>>> >>>>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the >>>>>>>>>>>> code >>>>>>>>>>>> cache >>>>>>>>>>>> and check that it hasn't been already invalidated by the >>>>>>>>>>>> sweeper >>>>>>>>>>>> before >>>>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>>>> invalidating it. >>>>>>>>>>>> >>>>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Vladimir Ivanov >> From vladimir.x.ivanov at oracle.com Thu Nov 7 09:04:25 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 7 Nov 2013 09:04:25 -0800 (PST) Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527BBBDF.9090307@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> <527BB27D.2030806@oracle.com> <527BB6CD.40004@oracle.com> <527BBBDF.9090307@oracle.com> Message-ID: <527BC819.4070208@oracle.com> Albert, > > thanks for the explanation. So it is equivalent to the following statement: > > bool is_installed = method->code() == this || // method is in state > alive and installed > !method->is_in_use() // method is > installed and in state: 'not-entrant', 'zombie', or, 'unloaded' > Yes, it's equivalent. And it's much more readable :-) Thanks for suggestion. I integrated your version. > > Here are some thoughs that came to my mind when I was working with the > sweeper... > > It is confusing that nm->is_in_use() returns true although the method > has not yet been installed. > A cleaner solution (but I assume it is not time time to do that in RDP2) > would probably be to introduce > a new state 'created', to which a nmethod is initialized when it is > created. The nmethod would change > the state to 'in_use' when it is installed. > Agree. I miss 'created' nmethod state and considered adding it, but refrained. I created RFE [1] to track that. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8028001 > Best, > Albert > > On 11/07/2013 04:50 PM, Vladimir Ivanov wrote: >> Albert, >> >> I want to exclude only the case when a newly allocated method hasn't >> been installed yet. If (_state == alive) is missing, IC verification >> for non-entrant methods is skipped as well. >> >> Best regards, >> Vladimir Ivanov >> >> On 11/7/13 7:32 PM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> I have a question concerning the following lines: >>> >>> *+ // Verify IC only when nmethod installation is finished.* >>> *+ bool is_installed = !(_state == alive && method()->code() != >>> this);* >>> *+ if (is_installed) >>> >>> >>> * >>> >>> Wouldn't it be also sufficient to check if a method is installed with >>> the following lines? >>> >>> bool is_installed = method()->code() == this; >>> >>> >>> Best, >>> Albert >>> >>> >>> On 11/07/2013 03:50 PM, Vladimir Ivanov wrote: >>>> Vladimir, thank you for the feedback. >>>> >>>> What do you think about the following version? >>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >>>>> Vladimir, >>>>> >>>>> Thank you for finding the real cause. >>>>> >>>>> I think you need the comment before nm->verify() in new_nmethod() >>>>> explaining why we should avoid safepoint as you explained here. >>>>> >>>>> I am not comfortable about passing new allow_safepoints parameter >>>>> through all verify calls because it is the only one case. We still >>>>> have >>>>> not installed nmethod at this point. There should be some check >>>>> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >>>>> >>>>> I thought about the need to verify scopes in >>>>> verify_interrupt_point() in >>>>> all cases. But the verification code in ScopeDesc::verify() is >>>>> commented. What? In general it is good to call it anyway. And you >>>>> don't >>>>> need IC to get the end_of_call() - I think we can inline what >>>>> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >>>>> >>>>> This code calls CompiledIC_at() because it does IC verification >>>>> which we >>>>> can skip in our case. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>>>>> Very good point, Vladimir! >>>>>> >>>>>> I should have looked for the bug in a different place :-) >>>>>> >>>>>> The problem is triggered by class redefinition and it can be >>>>>> performed >>>>>> under Compile_lock or during safepoint. So, in ciEnv::register_method >>>>>> it's not enough to grab Compile_lock. In addition, we need to ensure >>>>>> that there are no safepoints possible during method installation to >>>>>> guarantee no dependency is invalidated. >>>>>> >>>>>> There's one place in nmethod verification code (see MutexLocker >>>>>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where >>>>>> safepoint is possible and it causes the failure. >>>>>> >>>>>> The bug is present only in non-product builds since nmethod >>>>>> verification >>>>>> is absent in product bits. >>>>>> >>>>>> Previous fix also works, but I decided to go another route and forbid >>>>>> safepoints at all while holding Compile_lock. >>>>>> >>>>>> Updated webrev (will appear once cr.ojn is up): >>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>>>>> You need to be careful to avoid deadlock since there is call: >>>>>>> >>>>>>> 1035 old->make_not_entrant(); >>>>>>> >>>>>>> Any way there is comment in register_method(): >>>>>>> >>>>>>> 936 // Prevent SystemDictionary::add_to_hierarchy from running >>>>>>> 937 // and invalidating our dependencies until we install this >>>>>>> method. >>>>>>> 938 MutexLocker ml(Compile_lock); >>>>>>> >>>>>>> So how it happens that the method is invalidated by dependencies? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>>>>> Ouch, I was misled by it's name. So, I just lowered the >>>>>>>> likelihood of >>>>>>>> the failure then. >>>>>>>> >>>>>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>>>>> unlinks >>>>>>>> a nmethod. >>>>>>>> >>>>>>>> Do you see any problems with using it to guard method installation >>>>>>>> (method->set_code(method, nm)) in register_method() as well? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>>>>> Note nmethodLocker is not lock: >>>>>>>>> >>>>>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>>>>> if (nm == NULL) return; >>>>>>>>> Atomic::inc(&nm->_lock_count); >>>>>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>>>>>>> method"); >>>>>>>>> } >>>>>>>>> >>>>>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>>>>> >>>>>>>>> So how nmethodLocker helps here? >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>>>>> Thanks! Missed that one. Fixed. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>>>>> Should be >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> What about this place: >>>>>>>>>>> >>>>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if >>>>>>>>>>> (StressNonEntrant) { >>>>>>>>>>> >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>>>>> Updated fix: >>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>>>>> Updated comments. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>>> >>>>>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>>>>> registration >>>>>>>>>>>>> and >>>>>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>>>>> installed >>>>>>>>>>>>> yet. >>>>>>>>>>>>> >>>>>>>>>>>>> Consider the following scenario: >>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>> - new nmethod(...) >>>>>>>>>>>>> >>>>>>>>>>>>> sweeper: >>>>>>>>>>>>> - invalidates newly allocated nmethod and patches VEP to >>>>>>>>>>>>> call >>>>>>>>>>>>> handle_wrong_method >>>>>>>>>>>>> - tries to unlink it, but >>>>>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>>>>>>>> >>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>>>>> >>>>>>>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>>>>>>> VEP of >>>>>>>>>>>>> the >>>>>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>>>>> resolution >>>>>>>>>>>>> returns the very same compiled method. >>>>>>>>>>>>> >>>>>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the >>>>>>>>>>>>> code >>>>>>>>>>>>> cache >>>>>>>>>>>>> and check that it hasn't been already invalidated by the >>>>>>>>>>>>> sweeper >>>>>>>>>>>>> before >>>>>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>>>>> invalidating it. >>>>>>>>>>>>> >>>>>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Vladimir Ivanov >>> > From vladimir.kozlov at oracle.com Thu Nov 7 10:00:59 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Nov 2013 10:00:59 -0800 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527BA899.2040708@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> Message-ID: <527BD55B.7000702@oracle.com> It is better. About next 2 lines. Where you get method? The method() is used to get pointer to java Method. And is_in_use() is nmethod's method. In comments you need to say nmethod (and not method): + bool is_installed = method->code() == this || // method is in state 'alive' and installed + !method->is_in_use(); // method is installed and in state: 'not-entrant', 'zombie', or, 'unloaded' Second comment too big, you can simple say: // or nmethod is not in 'alive' state. Thanks, Vladimir On 11/7/13 6:50 AM, Vladimir Ivanov wrote: > Vladimir, thank you for the feedback. > > What do you think about the following version? > http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ > > Best regards, > Vladimir Ivanov > > On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >> Vladimir, >> >> Thank you for finding the real cause. >> >> I think you need the comment before nm->verify() in new_nmethod() >> explaining why we should avoid safepoint as you explained here. >> >> I am not comfortable about passing new allow_safepoints parameter >> through all verify calls because it is the only one case. We still have >> not installed nmethod at this point. There should be some check >> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >> >> I thought about the need to verify scopes in verify_interrupt_point() in >> all cases. But the verification code in ScopeDesc::verify() is >> commented. What? In general it is good to call it anyway. And you don't >> need IC to get the end_of_call() - I think we can inline what >> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >> >> This code calls CompiledIC_at() because it does IC verification which we >> can skip in our case. >> >> Thanks, >> Vladimir >> >> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>> Very good point, Vladimir! >>> >>> I should have looked for the bug in a different place :-) >>> >>> The problem is triggered by class redefinition and it can be performed >>> under Compile_lock or during safepoint. So, in ciEnv::register_method >>> it's not enough to grab Compile_lock. In addition, we need to ensure >>> that there are no safepoints possible during method installation to >>> guarantee no dependency is invalidated. >>> >>> There's one place in nmethod verification code (see MutexLocker >>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where >>> safepoint is possible and it causes the failure. >>> >>> The bug is present only in non-product builds since nmethod verification >>> is absent in product bits. >>> >>> Previous fix also works, but I decided to go another route and forbid >>> safepoints at all while holding Compile_lock. >>> >>> Updated webrev (will appear once cr.ojn is up): >>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>> You need to be careful to avoid deadlock since there is call: >>>> >>>> 1035 old->make_not_entrant(); >>>> >>>> Any way there is comment in register_method(): >>>> >>>> 936 // Prevent SystemDictionary::add_to_hierarchy from running >>>> 937 // and invalidating our dependencies until we install this >>>> method. >>>> 938 MutexLocker ml(Compile_lock); >>>> >>>> So how it happens that the method is invalidated by dependencies? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>> Ouch, I was misled by it's name. So, I just lowered the likelihood of >>>>> the failure then. >>>>> >>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>> unlinks >>>>> a nmethod. >>>>> >>>>> Do you see any problems with using it to guard method installation >>>>> (method->set_code(method, nm)) in register_method() as well? >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>> Note nmethodLocker is not lock: >>>>>> >>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>> if (nm == NULL) return; >>>>>> Atomic::inc(&nm->_lock_count); >>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>>>> method"); >>>>>> } >>>>>> >>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>> >>>>>> So how nmethodLocker helps here? >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>> Thanks! Missed that one. Fixed. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>> Should be >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>> >>>>>>>> What about this place: >>>>>>>> >>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>> Updated fix: >>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>> >>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>> Updated comments. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>> >>>>>>>>>> There's a race between compiler thread during method registration >>>>>>>>>> and >>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>> installed >>>>>>>>>> yet. >>>>>>>>>> >>>>>>>>>> Consider the following scenario: >>>>>>>>>> ciEnv::register_method: >>>>>>>>>> - new nmethod(...) >>>>>>>>>> >>>>>>>>>> sweeper: >>>>>>>>>> - invalidates newly allocated nmethod and patches VEP to call >>>>>>>>>> handle_wrong_method >>>>>>>>>> - tries to unlink it, but method()->from_compiled_entry() != >>>>>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>>>>> >>>>>>>>>> ciEnv::register_method: >>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>> >>>>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>>>> VEP of >>>>>>>>>> the >>>>>>>>>> compiled method calls handle_wrong_method and call site resolution >>>>>>>>>> returns the very same compiled method. >>>>>>>>>> >>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the code >>>>>>>>>> cache >>>>>>>>>> and check that it hasn't been already invalidated by the sweeper >>>>>>>>>> before >>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>> invalidating it. >>>>>>>>>> >>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov From vladimir.kozlov at oracle.com Thu Nov 7 10:04:00 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Nov 2013 10:04:00 -0800 Subject: RFR(S): 8027631: "unexpected profiling mismatch" error with new type profiling In-Reply-To: <0108D02C-E148-4C53-86C7-401671B090DC@oracle.com> References: <97427AA4-EC00-417F-ABCC-EC7F6658775C@oracle.com> <527A930B.8080804@oracle.com> <0108D02C-E148-4C53-86C7-401671B090DC@oracle.com> Message-ID: <527BD610.1060001@oracle.com> On 11/7/13 1:39 AM, Roland Westrelin wrote: >> Changes looks fine. > > Thanks for the review, Vladimir. > >> Add -XX:+IgnoreUnrecognizedVMOptions to test's flags since Client VM may not recognise tiered flags. > > All of the flags are defined in globals.hpp and exist for a client VM so it runs fine. Do you think I should add -XX:+IgnoreUnrecognizedVMOptions anyway? No need if you can run the test with your flags with Client VM (32-bit). Vladimir > > Roland. > From chris.plummer at oracle.com Thu Nov 7 10:12:42 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 07 Nov 2013 10:12:42 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527B7851.7000005@oracle.com> References: <52790459.7050607@oracle.com> <5279A281.1050600@oracle.com> <5279A6D8.9070503@oracle.com> <527B7851.7000005@oracle.com> Message-ID: <527BD81A.2040501@oracle.com> On 11/7/13 3:24 AM, Albert Noll wrote: > Hi Chris, > > On 11/06/2013 03:18 AM, Chris Plummer wrote: >> BTW, one thing I forgot to mention is I now see a lot of messages for >> the codecache filling up. For example: >> >> Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has >> been disabled. >> Java HotSpot(TM) Client VM warning: Try increasing the code cache >> size using -XX:ReservedCodeCacheSize= >> CodeCache: size=2700Kb used=2196Kb max_used=2196Kb free=503Kb >> >> With b111, I was only seeing one message. I suspect with b111, once >> this message appeared compilation was never re-enabled so the message >> never appeared again. In that case seeing in many times now is >> actually a good indicator. However, it appears even when not using >> -XX:+PrintCodeCache, and I can see this output being a distraction >> for programs whose normal operation may involve constraining the >> codecache and having it constantly filling up. Perhaps this message >> should be off by default, or possibly only appear once. >> > You are right. The previous version just never re-enabled compilation. > I also agree that the > output is distracting. There are multiple ways to solve this issue. I > would go for a product -XX flag > which allows to turn this warning on/off. Would that be ok or do you > have a different solution in mind? I think a product flag would be fine. You might want to make it default to off when ReservedCodeCacheSize is set lower than the default, and have it on otherwise. cheers, Chris > > Best, > Albert > >> cheers, >> >> Chris >> >> On 11/5/13 5:59 PM, Chris Plummer wrote: >>> Hi Albert, >>> >>> I applied your patch and got some new numbers. Performance is now >>> even better than it was with b110. See the chart I added to the bug. >>> >>> Nice work! >>> >>> Chris >>> >>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>> Hi, >>>> >>>> could I get reviews for this small patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>> >>>> Problem: The implementation of the sweeper (8020151) causes a >>>> performance regression for small code cache sizes. There are two >>>> issues that cause this regression: >>>> 1) NmethodSweepFraction is only adjusted according to the >>>> ReservedCodecacheSize if TieredCompilation is enabled. As a result, >>>> NmethodSweepFraction remains 16 (if TieredCompilation is not used). >>>> This is way too large for small code cache sizes (e.g., <5m). >>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>> result, mark_active_nmethods() did not set _invocations and >>>> _current, which results in not invoking the sweeper (calling >>>> sweep_code_cache()) at all. When TieredCompilation is enabled this >>>> was not an issue, since NmethodSweeper::notify() (which sets >>>> _request_mark_phase) is called much more frequently. >>>> >>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>> always executed. >>>> Solution: 2) Remove need_marking_phase(), >>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>> I think that these checks are not needed since >>>> 8020151, since we do stack scanning of >>>> active nmethods irrespective of the value of >>>> what need_marking_phase() returns. Since >>>> the patch removes need_marking_phase() printing >>>> out the warning (line 327 in >>>> sweeper.cpp) is incorrect, i.e., we continue to >>>> invoke the sweeper. I removed the warning >>>> and the associated code. >>>> >>>> >>>> Also, I think that we can either remove -XX:MethodFlushing or >>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant >>>> and can be removed. I am not quite sure if we should do that now so >>>> it is not included in the patch. >>>> >>>> Testing >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>> performance evaluation. >>>> >>>> Many thanks for looking at the patch. >>>> Best, >>>> Albert >>> >> > From vladimir.x.ivanov at oracle.com Thu Nov 7 10:35:28 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 07 Nov 2013 22:35:28 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527BD55B.7000702@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> <527BD55B.7000702@oracle.com> Message-ID: <527BDD70.2030809@oracle.com> Sorry, blindly copy-pasted the code. Thanks for catching that. Fixed (same link, hit refresh). Best regards, Vladimir Ivanov On 11/7/13 10:00 PM, Vladimir Kozlov wrote: > It is better. > > About next 2 lines. Where you get method? The method() is used to get > pointer to java Method. And is_in_use() is nmethod's method. In comments > you need to say nmethod (and not method): > > + bool is_installed = method->code() == this || // method is in state > 'alive' and installed > + !method->is_in_use(); // method is installed > and in state: 'not-entrant', 'zombie', or, 'unloaded' > > Second comment too big, you can simple say: // or nmethod is not in > 'alive' state. > > Thanks, > Vladimir > > On 11/7/13 6:50 AM, Vladimir Ivanov wrote: >> Vladimir, thank you for the feedback. >> >> What do you think about the following version? >> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ >> >> Best regards, >> Vladimir Ivanov >> >> On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >>> Vladimir, >>> >>> Thank you for finding the real cause. >>> >>> I think you need the comment before nm->verify() in new_nmethod() >>> explaining why we should avoid safepoint as you explained here. >>> >>> I am not comfortable about passing new allow_safepoints parameter >>> through all verify calls because it is the only one case. We still have >>> not installed nmethod at this point. There should be some check >>> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >>> >>> I thought about the need to verify scopes in verify_interrupt_point() in >>> all cases. But the verification code in ScopeDesc::verify() is >>> commented. What? In general it is good to call it anyway. And you don't >>> need IC to get the end_of_call() - I think we can inline what >>> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >>> >>> This code calls CompiledIC_at() because it does IC verification which we >>> can skip in our case. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>>> Very good point, Vladimir! >>>> >>>> I should have looked for the bug in a different place :-) >>>> >>>> The problem is triggered by class redefinition and it can be performed >>>> under Compile_lock or during safepoint. So, in ciEnv::register_method >>>> it's not enough to grab Compile_lock. In addition, we need to ensure >>>> that there are no safepoints possible during method installation to >>>> guarantee no dependency is invalidated. >>>> >>>> There's one place in nmethod verification code (see MutexLocker >>>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where >>>> safepoint is possible and it causes the failure. >>>> >>>> The bug is present only in non-product builds since nmethod >>>> verification >>>> is absent in product bits. >>>> >>>> Previous fix also works, but I decided to go another route and forbid >>>> safepoints at all while holding Compile_lock. >>>> >>>> Updated webrev (will appear once cr.ojn is up): >>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>>> You need to be careful to avoid deadlock since there is call: >>>>> >>>>> 1035 old->make_not_entrant(); >>>>> >>>>> Any way there is comment in register_method(): >>>>> >>>>> 936 // Prevent SystemDictionary::add_to_hierarchy from running >>>>> 937 // and invalidating our dependencies until we install this >>>>> method. >>>>> 938 MutexLocker ml(Compile_lock); >>>>> >>>>> So how it happens that the method is invalidated by dependencies? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>>> Ouch, I was misled by it's name. So, I just lowered the likelihood of >>>>>> the failure then. >>>>>> >>>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>>> unlinks >>>>>> a nmethod. >>>>>> >>>>>> Do you see any problems with using it to guard method installation >>>>>> (method->set_code(method, nm)) in register_method() as well? >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>>> Note nmethodLocker is not lock: >>>>>>> >>>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>>> if (nm == NULL) return; >>>>>>> Atomic::inc(&nm->_lock_count); >>>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>>>>> method"); >>>>>>> } >>>>>>> >>>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>>> >>>>>>> So how nmethodLocker helps here? >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>>> Thanks! Missed that one. Fixed. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>>> Should be >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>>> >>>>>>>>> What about this place: >>>>>>>>> >>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if (StressNonEntrant) { >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>>> Updated fix: >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>> >>>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>>> Updated comments. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>>> registration >>>>>>>>>>> and >>>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>>> installed >>>>>>>>>>> yet. >>>>>>>>>>> >>>>>>>>>>> Consider the following scenario: >>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>> - new nmethod(...) >>>>>>>>>>> >>>>>>>>>>> sweeper: >>>>>>>>>>> - invalidates newly allocated nmethod and patches VEP to >>>>>>>>>>> call >>>>>>>>>>> handle_wrong_method >>>>>>>>>>> - tries to unlink it, but >>>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>>>>>> >>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>>> >>>>>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>>>>> VEP of >>>>>>>>>>> the >>>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>>> resolution >>>>>>>>>>> returns the very same compiled method. >>>>>>>>>>> >>>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the code >>>>>>>>>>> cache >>>>>>>>>>> and check that it hasn't been already invalidated by the sweeper >>>>>>>>>>> before >>>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>>> invalidating it. >>>>>>>>>>> >>>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Vladimir Ivanov From albert.noll at oracle.com Thu Nov 7 10:46:01 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 07 Nov 2013 19:46:01 +0100 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527BDD70.2030809@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> <527BD55B.7000702@oracle.com> <527BDD70.2030809@oracle.com> Message-ID: <527BDFE9.3060605@oracle.com> Sorry my bad, I just typed the code into the email; I did not try to compile (or run) it. Albert On 11/07/2013 07:35 PM, Vladimir Ivanov wrote: > Sorry, blindly copy-pasted the code. > Thanks for catching that. > Fixed (same link, hit refresh). > > Best regards, > Vladimir Ivanov > > On 11/7/13 10:00 PM, Vladimir Kozlov wrote: >> It is better. >> >> About next 2 lines. Where you get method? The method() is used to get >> pointer to java Method. And is_in_use() is nmethod's method. In comments >> you need to say nmethod (and not method): >> >> + bool is_installed = method->code() == this || // method is in state >> 'alive' and installed >> + !method->is_in_use(); // method is installed >> and in state: 'not-entrant', 'zombie', or, 'unloaded' >> >> Second comment too big, you can simple say: // or nmethod is not in >> 'alive' state. >> >> Thanks, >> Vladimir >> >> On 11/7/13 6:50 AM, Vladimir Ivanov wrote: >>> Vladimir, thank you for the feedback. >>> >>> What do you think about the following version? >>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >>>> Vladimir, >>>> >>>> Thank you for finding the real cause. >>>> >>>> I think you need the comment before nm->verify() in new_nmethod() >>>> explaining why we should avoid safepoint as you explained here. >>>> >>>> I am not comfortable about passing new allow_safepoints parameter >>>> through all verify calls because it is the only one case. We still >>>> have >>>> not installed nmethod at this point. There should be some check >>>> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >>>> >>>> I thought about the need to verify scopes in >>>> verify_interrupt_point() in >>>> all cases. But the verification code in ScopeDesc::verify() is >>>> commented. What? In general it is good to call it anyway. And you >>>> don't >>>> need IC to get the end_of_call() - I think we can inline what >>>> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >>>> >>>> This code calls CompiledIC_at() because it does IC verification >>>> which we >>>> can skip in our case. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>>>> Very good point, Vladimir! >>>>> >>>>> I should have looked for the bug in a different place :-) >>>>> >>>>> The problem is triggered by class redefinition and it can be >>>>> performed >>>>> under Compile_lock or during safepoint. So, in ciEnv::register_method >>>>> it's not enough to grab Compile_lock. In addition, we need to ensure >>>>> that there are no safepoints possible during method installation to >>>>> guarantee no dependency is invalidated. >>>>> >>>>> There's one place in nmethod verification code (see MutexLocker >>>>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where >>>>> safepoint is possible and it causes the failure. >>>>> >>>>> The bug is present only in non-product builds since nmethod >>>>> verification >>>>> is absent in product bits. >>>>> >>>>> Previous fix also works, but I decided to go another route and forbid >>>>> safepoints at all while holding Compile_lock. >>>>> >>>>> Updated webrev (will appear once cr.ojn is up): >>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>>>> You need to be careful to avoid deadlock since there is call: >>>>>> >>>>>> 1035 old->make_not_entrant(); >>>>>> >>>>>> Any way there is comment in register_method(): >>>>>> >>>>>> 936 // Prevent SystemDictionary::add_to_hierarchy from running >>>>>> 937 // and invalidating our dependencies until we install this >>>>>> method. >>>>>> 938 MutexLocker ml(Compile_lock); >>>>>> >>>>>> So how it happens that the method is invalidated by dependencies? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>>>> Ouch, I was misled by it's name. So, I just lowered the >>>>>>> likelihood of >>>>>>> the failure then. >>>>>>> >>>>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>>>> unlinks >>>>>>> a nmethod. >>>>>>> >>>>>>> Do you see any problems with using it to guard method installation >>>>>>> (method->set_code(method, nm)) in register_method() as well? >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>>>> Note nmethodLocker is not lock: >>>>>>>> >>>>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>>>> if (nm == NULL) return; >>>>>>>> Atomic::inc(&nm->_lock_count); >>>>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>>>>>> method"); >>>>>>>> } >>>>>>>> >>>>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>>>> >>>>>>>> So how nmethodLocker helps here? >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>>>> Thanks! Missed that one. Fixed. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>>>> Should be >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>>>> >>>>>>>>>> What about this place: >>>>>>>>>> >>>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if >>>>>>>>>> (StressNonEntrant) { >>>>>>>>>> >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>>>> Updated fix: >>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>>>> Updated comments. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>> >>>>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>>>> registration >>>>>>>>>>>> and >>>>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>>>> installed >>>>>>>>>>>> yet. >>>>>>>>>>>> >>>>>>>>>>>> Consider the following scenario: >>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>> - new nmethod(...) >>>>>>>>>>>> >>>>>>>>>>>> sweeper: >>>>>>>>>>>> - invalidates newly allocated nmethod and patches VEP to >>>>>>>>>>>> call >>>>>>>>>>>> handle_wrong_method >>>>>>>>>>>> - tries to unlink it, but >>>>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>>>>>>> >>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>>>> >>>>>>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>>>>>> VEP of >>>>>>>>>>>> the >>>>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>>>> resolution >>>>>>>>>>>> returns the very same compiled method. >>>>>>>>>>>> >>>>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the >>>>>>>>>>>> code >>>>>>>>>>>> cache >>>>>>>>>>>> and check that it hasn't been already invalidated by the >>>>>>>>>>>> sweeper >>>>>>>>>>>> before >>>>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>>>> invalidating it. >>>>>>>>>>>> >>>>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Vladimir Ivanov From igor.veresov at oracle.com Thu Nov 7 11:04:54 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 7 Nov 2013 11:04:54 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527B7851.7000005@oracle.com> References: <52790459.7050607@oracle.com> <5279A281.1050600@oracle.com> <5279A6D8.9070503@oracle.com> <527B7851.7000005@oracle.com> Message-ID: I?d vote to put it under PrintCodeCache. And make the messages not warnings, but just ?compiler disabled/enabled?. What do you think? igor On Nov 7, 2013, at 3:24 AM, Albert Noll wrote: > Hi Chris, > > On 11/06/2013 03:18 AM, Chris Plummer wrote: >> BTW, one thing I forgot to mention is I now see a lot of messages for the codecache filling up. For example: >> >> Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has been disabled. >> Java HotSpot(TM) Client VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= >> CodeCache: size=2700Kb used=2196Kb max_used=2196Kb free=503Kb >> >> With b111, I was only seeing one message. I suspect with b111, once this message appeared compilation was never re-enabled so the message never appeared again. In that case seeing in many times now is actually a good indicator. However, it appears even when not using -XX:+PrintCodeCache, and I can see this output being a distraction for programs whose normal operation may involve constraining the codecache and having it constantly filling up. Perhaps this message should be off by default, or possibly only appear once. >> > You are right. The previous version just never re-enabled compilation. I also agree that the > output is distracting. There are multiple ways to solve this issue. I would go for a product -XX flag > which allows to turn this warning on/off. Would that be ok or do you have a different solution in mind? > > Best, > Albert > >> cheers, >> >> Chris >> >> On 11/5/13 5:59 PM, Chris Plummer wrote: >>> Hi Albert, >>> >>> I applied your patch and got some new numbers. Performance is now even better than it was with b110. See the chart I added to the bug. >>> >>> Nice work! >>> >>> Chris >>> >>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>> Hi, >>>> >>>> could I get reviews for this small patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>> >>>> Problem: The implementation of the sweeper (8020151) causes a performance regression for small code cache sizes. There are two issues that cause this regression: >>>> 1) NmethodSweepFraction is only adjusted according to the ReservedCodecacheSize if TieredCompilation is enabled. As a result, NmethodSweepFraction remains 16 (if TieredCompilation is not used). This is way too large for small code cache sizes (e.g., <5m). >>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a result, mark_active_nmethods() did not set _invocations and _current, which results in not invoking the sweeper (calling sweep_code_cache()) at all. When TieredCompilation is enabled this was not an issue, since NmethodSweeper::notify() (which sets _request_mark_phase) is called much more frequently. >>>> >>>> Solution: 1) Move setting of NmethodSweepFraction so that it is always executed. >>>> Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), and reset_nmetod_marking(). >>>> I think that these checks are not needed since 8020151, since we do stack scanning of >>>> active nmethods irrespective of the value of what need_marking_phase() returns. Since >>>> the patch removes need_marking_phase() printing out the warning (line 327 in >>>> sweeper.cpp) is incorrect, i.e., we continue to invoke the sweeper. I removed the warning >>>> and the associated code. >>>> >>>> >>>> Also, I think that we can either remove -XX:MethodFlushing or -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant and can be removed. I am not quite sure if we should do that now so it is not included in the patch. >>>> >>>> Testing >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a performance evaluation. >>>> >>>> Many thanks for looking at the patch. >>>> Best, >>>> Albert >>> >> > From vladimir.kozlov at oracle.com Thu Nov 7 11:26:42 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Nov 2013 11:26:42 -0800 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527BDD70.2030809@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> <527BD55B.7000702@oracle.com> <527BDD70.2030809@oracle.com> Message-ID: <527BE972.40507@oracle.com> No, should be method() and 'this' and add parenthesis: + bool is_installed = (method()->code() == this) // nmethod is in state 'alive' and installed + || !this->is_in_use(); // nmethod is installed, but not in 'alive' state Vladimir K On 11/7/13 10:35 AM, Vladimir Ivanov wrote: > Sorry, blindly copy-pasted the code. > Thanks for catching that. > Fixed (same link, hit refresh). > > Best regards, > Vladimir Ivanov > > On 11/7/13 10:00 PM, Vladimir Kozlov wrote: >> It is better. >> >> About next 2 lines. Where you get method? The method() is used to get >> pointer to java Method. And is_in_use() is nmethod's method. In comments >> you need to say nmethod (and not method): >> >> + bool is_installed = method->code() == this || // method is in state >> 'alive' and installed >> + !method->is_in_use(); // method is installed >> and in state: 'not-entrant', 'zombie', or, 'unloaded' >> >> Second comment too big, you can simple say: // or nmethod is not in >> 'alive' state. >> >> Thanks, >> Vladimir >> >> On 11/7/13 6:50 AM, Vladimir Ivanov wrote: >>> Vladimir, thank you for the feedback. >>> >>> What do you think about the following version? >>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >>>> Vladimir, >>>> >>>> Thank you for finding the real cause. >>>> >>>> I think you need the comment before nm->verify() in new_nmethod() >>>> explaining why we should avoid safepoint as you explained here. >>>> >>>> I am not comfortable about passing new allow_safepoints parameter >>>> through all verify calls because it is the only one case. We still have >>>> not installed nmethod at this point. There should be some check >>>> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >>>> >>>> I thought about the need to verify scopes in >>>> verify_interrupt_point() in >>>> all cases. But the verification code in ScopeDesc::verify() is >>>> commented. What? In general it is good to call it anyway. And you don't >>>> need IC to get the end_of_call() - I think we can inline what >>>> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >>>> >>>> This code calls CompiledIC_at() because it does IC verification >>>> which we >>>> can skip in our case. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>>>> Very good point, Vladimir! >>>>> >>>>> I should have looked for the bug in a different place :-) >>>>> >>>>> The problem is triggered by class redefinition and it can be performed >>>>> under Compile_lock or during safepoint. So, in ciEnv::register_method >>>>> it's not enough to grab Compile_lock. In addition, we need to ensure >>>>> that there are no safepoints possible during method installation to >>>>> guarantee no dependency is invalidated. >>>>> >>>>> There's one place in nmethod verification code (see MutexLocker >>>>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where >>>>> safepoint is possible and it causes the failure. >>>>> >>>>> The bug is present only in non-product builds since nmethod >>>>> verification >>>>> is absent in product bits. >>>>> >>>>> Previous fix also works, but I decided to go another route and forbid >>>>> safepoints at all while holding Compile_lock. >>>>> >>>>> Updated webrev (will appear once cr.ojn is up): >>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>>>> You need to be careful to avoid deadlock since there is call: >>>>>> >>>>>> 1035 old->make_not_entrant(); >>>>>> >>>>>> Any way there is comment in register_method(): >>>>>> >>>>>> 936 // Prevent SystemDictionary::add_to_hierarchy from running >>>>>> 937 // and invalidating our dependencies until we install this >>>>>> method. >>>>>> 938 MutexLocker ml(Compile_lock); >>>>>> >>>>>> So how it happens that the method is invalidated by dependencies? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>>>> Ouch, I was misled by it's name. So, I just lowered the >>>>>>> likelihood of >>>>>>> the failure then. >>>>>>> >>>>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>>>> unlinks >>>>>>> a nmethod. >>>>>>> >>>>>>> Do you see any problems with using it to guard method installation >>>>>>> (method->set_code(method, nm)) in register_method() as well? >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>>>> Note nmethodLocker is not lock: >>>>>>>> >>>>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>>>> if (nm == NULL) return; >>>>>>>> Atomic::inc(&nm->_lock_count); >>>>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>>>>>> method"); >>>>>>>> } >>>>>>>> >>>>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>>>> >>>>>>>> So how nmethodLocker helps here? >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>>>> Thanks! Missed that one. Fixed. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>>>> Should be >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>>>> >>>>>>>>>> What about this place: >>>>>>>>>> >>>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if >>>>>>>>>> (StressNonEntrant) { >>>>>>>>>> >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>>>> Updated fix: >>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>>>> Updated comments. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>> >>>>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>>>> registration >>>>>>>>>>>> and >>>>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>>>> installed >>>>>>>>>>>> yet. >>>>>>>>>>>> >>>>>>>>>>>> Consider the following scenario: >>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>> - new nmethod(...) >>>>>>>>>>>> >>>>>>>>>>>> sweeper: >>>>>>>>>>>> - invalidates newly allocated nmethod and patches VEP to >>>>>>>>>>>> call >>>>>>>>>>>> handle_wrong_method >>>>>>>>>>>> - tries to unlink it, but >>>>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>>>>>>> >>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>>>> >>>>>>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>>>>>> VEP of >>>>>>>>>>>> the >>>>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>>>> resolution >>>>>>>>>>>> returns the very same compiled method. >>>>>>>>>>>> >>>>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the >>>>>>>>>>>> code >>>>>>>>>>>> cache >>>>>>>>>>>> and check that it hasn't been already invalidated by the >>>>>>>>>>>> sweeper >>>>>>>>>>>> before >>>>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>>>> invalidating it. >>>>>>>>>>>> >>>>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Vladimir Ivanov From john.coomes at oracle.com Thu Nov 7 11:39:58 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 19:39:58 +0000 Subject: hg: hsx/hotspot-comp/corba: 5 new changesets Message-ID: <20131107194005.63E9D6242B@hg.openjdk.java.net> Changeset: 52ad44f9a3ec Author: alanb Date: 2013-10-22 11:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/corba/rev/219e616a6a4f Merge Changeset: 8d07115924b7 Author: lana Date: 2013-10-31 16:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/8d07115924b7 Merge Changeset: 5fdc44652089 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/5fdc44652089 Added tag jdk8-b115 for changeset 8d07115924b7 ! .hgtags From john.coomes at oracle.com Thu Nov 7 11:40:11 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 19:40:11 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 6 new changesets Message-ID: <20131107194034.EA0FC6242C@hg.openjdk.java.net> Changeset: 390e94b9a852 Author: joehw Date: 2013-10-24 13:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxp/rev/96562bf197f2 Merge Changeset: 1af33ab1bc58 Author: joehw Date: 2013-10-29 14:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jaxp/rev/f610fd46463e Merge Changeset: e757eb9aee3d Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/e757eb9aee3d Added tag jdk8-b115 for changeset f610fd46463e ! .hgtags From john.coomes at oracle.com Thu Nov 7 11:40:40 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 19:40:40 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b115 for changeset e126d8eca69b Message-ID: <20131107194048.EE0B76242D@hg.openjdk.java.net> Changeset: 587560c222a2 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/587560c222a2 Added tag jdk8-b115 for changeset e126d8eca69b ! .hgtags From john.coomes at oracle.com Thu Nov 7 11:39:50 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 19:39:50 +0000 Subject: hg: hsx/hotspot-comp: 30 new changesets Message-ID: <20131107193952.D2FD46242A@hg.openjdk.java.net> Changeset: 3dc55f0c1b6f Author: jlaskey Date: 2013-01-28 16:29 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/rev/b938d5ee29c3 Merge Changeset: fe5a388bf8fe Author: jlaskey Date: 2013-03-26 09:13 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/rev/6316aefcf716 Merge Changeset: dd81e9b5fb38 Author: jlaskey Date: 2013-04-22 13:59 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/dd81e9b5fb38 Merge Changeset: 431d16ddfcd9 Author: jlaskey Date: 2013-04-29 21:37 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/431d16ddfcd9 Merge Changeset: 1fca390200c1 Author: jlaskey Date: 2013-05-14 09:04 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/rev/67b5cbe55744 Merge Changeset: de886178f8e6 Author: jlaskey Date: 2013-06-05 13:08 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/rev/763ada2a1d8c Merge Changeset: 40e892e2a4f2 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/40e892e2a4f2 Added tag jdk8-b115 for changeset 763ada2a1d8c ! .hgtags From vladimir.x.ivanov at oracle.com Thu Nov 7 12:04:36 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 08 Nov 2013 00:04:36 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527BE972.40507@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> <527BD55B.7000702@oracle.com> <527BDD70.2030809@oracle.com> <527BE972.40507@oracle.com> Message-ID: <527BF254.9080307@oracle.com> Oops, sorry about that... Fixed. This time I built it and ran the test to be 100% sure :-) Best regards, Vladimir Ivanov On 11/7/13 11:26 PM, Vladimir Kozlov wrote: > No, should be method() and 'this' and add parenthesis: > > + bool is_installed = (method()->code() == this) // nmethod is in > state 'alive' and installed > + || !this->is_in_use(); // nmethod is > installed, but not in 'alive' state > > Vladimir K > > On 11/7/13 10:35 AM, Vladimir Ivanov wrote: >> Sorry, blindly copy-pasted the code. >> Thanks for catching that. >> Fixed (same link, hit refresh). >> >> Best regards, >> Vladimir Ivanov >> >> On 11/7/13 10:00 PM, Vladimir Kozlov wrote: >>> It is better. >>> >>> About next 2 lines. Where you get method? The method() is used to get >>> pointer to java Method. And is_in_use() is nmethod's method. In comments >>> you need to say nmethod (and not method): >>> >>> + bool is_installed = method->code() == this || // method is in state >>> 'alive' and installed >>> + !method->is_in_use(); // method is installed >>> and in state: 'not-entrant', 'zombie', or, 'unloaded' >>> >>> Second comment too big, you can simple say: // or nmethod is not in >>> 'alive' state. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/7/13 6:50 AM, Vladimir Ivanov wrote: >>>> Vladimir, thank you for the feedback. >>>> >>>> What do you think about the following version? >>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >>>>> Vladimir, >>>>> >>>>> Thank you for finding the real cause. >>>>> >>>>> I think you need the comment before nm->verify() in new_nmethod() >>>>> explaining why we should avoid safepoint as you explained here. >>>>> >>>>> I am not comfortable about passing new allow_safepoints parameter >>>>> through all verify calls because it is the only one case. We still >>>>> have >>>>> not installed nmethod at this point. There should be some check >>>>> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >>>>> >>>>> I thought about the need to verify scopes in >>>>> verify_interrupt_point() in >>>>> all cases. But the verification code in ScopeDesc::verify() is >>>>> commented. What? In general it is good to call it anyway. And you >>>>> don't >>>>> need IC to get the end_of_call() - I think we can inline what >>>>> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >>>>> >>>>> This code calls CompiledIC_at() because it does IC verification >>>>> which we >>>>> can skip in our case. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>>>>> Very good point, Vladimir! >>>>>> >>>>>> I should have looked for the bug in a different place :-) >>>>>> >>>>>> The problem is triggered by class redefinition and it can be >>>>>> performed >>>>>> under Compile_lock or during safepoint. So, in ciEnv::register_method >>>>>> it's not enough to grab Compile_lock. In addition, we need to ensure >>>>>> that there are no safepoints possible during method installation to >>>>>> guarantee no dependency is invalidated. >>>>>> >>>>>> There's one place in nmethod verification code (see MutexLocker >>>>>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) where >>>>>> safepoint is possible and it causes the failure. >>>>>> >>>>>> The bug is present only in non-product builds since nmethod >>>>>> verification >>>>>> is absent in product bits. >>>>>> >>>>>> Previous fix also works, but I decided to go another route and forbid >>>>>> safepoints at all while holding Compile_lock. >>>>>> >>>>>> Updated webrev (will appear once cr.ojn is up): >>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>>>>> You need to be careful to avoid deadlock since there is call: >>>>>>> >>>>>>> 1035 old->make_not_entrant(); >>>>>>> >>>>>>> Any way there is comment in register_method(): >>>>>>> >>>>>>> 936 // Prevent SystemDictionary::add_to_hierarchy from running >>>>>>> 937 // and invalidating our dependencies until we install this >>>>>>> method. >>>>>>> 938 MutexLocker ml(Compile_lock); >>>>>>> >>>>>>> So how it happens that the method is invalidated by dependencies? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>>>>> Ouch, I was misled by it's name. So, I just lowered the >>>>>>>> likelihood of >>>>>>>> the failure then. >>>>>>>> >>>>>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>>>>> unlinks >>>>>>>> a nmethod. >>>>>>>> >>>>>>>> Do you see any problems with using it to guard method installation >>>>>>>> (method->set_code(method, nm)) in register_method() as well? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>>>>> Note nmethodLocker is not lock: >>>>>>>>> >>>>>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>>>>> if (nm == NULL) return; >>>>>>>>> Atomic::inc(&nm->_lock_count); >>>>>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>>>>>>> method"); >>>>>>>>> } >>>>>>>>> >>>>>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>>>>> >>>>>>>>> So how nmethodLocker helps here? >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>>>>> Thanks! Missed that one. Fixed. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>>>>> Should be >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> What about this place: >>>>>>>>>>> >>>>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if >>>>>>>>>>> (StressNonEntrant) { >>>>>>>>>>> >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>>>>> Updated fix: >>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>>>>> Updated comments. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>>> >>>>>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>>>>> registration >>>>>>>>>>>>> and >>>>>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>>>>> installed >>>>>>>>>>>>> yet. >>>>>>>>>>>>> >>>>>>>>>>>>> Consider the following scenario: >>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>> - new nmethod(...) >>>>>>>>>>>>> >>>>>>>>>>>>> sweeper: >>>>>>>>>>>>> - invalidates newly allocated nmethod and patches VEP to >>>>>>>>>>>>> call >>>>>>>>>>>>> handle_wrong_method >>>>>>>>>>>>> - tries to unlink it, but >>>>>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>>>>> verified_entry_point() since nmethod hasn't been installed yet >>>>>>>>>>>>> >>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>>>>> >>>>>>>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>>>>>>> VEP of >>>>>>>>>>>>> the >>>>>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>>>>> resolution >>>>>>>>>>>>> returns the very same compiled method. >>>>>>>>>>>>> >>>>>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the >>>>>>>>>>>>> code >>>>>>>>>>>>> cache >>>>>>>>>>>>> and check that it hasn't been already invalidated by the >>>>>>>>>>>>> sweeper >>>>>>>>>>>>> before >>>>>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>>>>> invalidating it. >>>>>>>>>>>>> >>>>>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Vladimir Ivanov From vladimir.kozlov at oracle.com Thu Nov 7 11:39:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 7 Nov 2013 11:39:40 -0800 (PST) Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: References: <52790459.7050607@oracle.com> <5279A281.1050600@oracle.com> <5279A6D8.9070503@oracle.com> <527B7851.7000005@oracle.com> Message-ID: <527BEC7C.7030502@oracle.com> On 11/7/13 11:04 AM, Igor Veresov wrote: > I?d vote to put it under PrintCodeCache. And make the messages not warnings, but just ?compiler disabled/enabled?. What do you think? Unfortunately there could be customer's tools which look for this message. So changing it, at least now for jdk8, is not good. With small codecache we will expect this message showing up. But with big codecache it should not happen. I think we should keep it as warning but throttle it when small codecache is used as Chris suggested. May be put it under combined check: if (PrintCodeCache || ReservedCodeCacheSize > X) Do we have a state now when we definitely will not compile any more? Or we always making progress? I think it will be difficult to find when it should be printed only once. Thanks, Vladimir > > igor > > On Nov 7, 2013, at 3:24 AM, Albert Noll wrote: > >> Hi Chris, >> >> On 11/06/2013 03:18 AM, Chris Plummer wrote: >>> BTW, one thing I forgot to mention is I now see a lot of messages for the codecache filling up. For example: >>> >>> Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has been disabled. >>> Java HotSpot(TM) Client VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= >>> CodeCache: size=2700Kb used=2196Kb max_used=2196Kb free=503Kb >>> >>> With b111, I was only seeing one message. I suspect with b111, once this message appeared compilation was never re-enabled so the message never appeared again. In that case seeing in many times now is actually a good indicator. However, it appears even when not using -XX:+PrintCodeCache, and I can see this output being a distraction for programs whose normal operation may involve constraining the codecache and having it constantly filling up. Perhaps this message should be off by default, or possibly only appear once. >>> >> You are right. The previous version just never re-enabled compilation. I also agree that the >> output is distracting. There are multiple ways to solve this issue. I would go for a product -XX flag >> which allows to turn this warning on/off. Would that be ok or do you have a different solution in mind? >> >> Best, >> Albert >> >>> cheers, >>> >>> Chris >>> >>> On 11/5/13 5:59 PM, Chris Plummer wrote: >>>> Hi Albert, >>>> >>>> I applied your patch and got some new numbers. Performance is now even better than it was with b110. See the chart I added to the bug. >>>> >>>> Nice work! >>>> >>>> Chris >>>> >>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>> Hi, >>>>> >>>>> could I get reviews for this small patch? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>> >>>>> Problem: The implementation of the sweeper (8020151) causes a performance regression for small code cache sizes. There are two issues that cause this regression: >>>>> 1) NmethodSweepFraction is only adjusted according to the ReservedCodecacheSize if TieredCompilation is enabled. As a result, NmethodSweepFraction remains 16 (if TieredCompilation is not used). This is way too large for small code cache sizes (e.g., <5m). >>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a result, mark_active_nmethods() did not set _invocations and _current, which results in not invoking the sweeper (calling sweep_code_cache()) at all. When TieredCompilation is enabled this was not an issue, since NmethodSweeper::notify() (which sets _request_mark_phase) is called much more frequently. >>>>> >>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is always executed. >>>>> Solution: 2) Remove need_marking_phase(), request_nmethod_marking(), and reset_nmetod_marking(). >>>>> I think that these checks are not needed since 8020151, since we do stack scanning of >>>>> active nmethods irrespective of the value of what need_marking_phase() returns. Since >>>>> the patch removes need_marking_phase() printing out the warning (line 327 in >>>>> sweeper.cpp) is incorrect, i.e., we continue to invoke the sweeper. I removed the warning >>>>> and the associated code. >>>>> >>>>> >>>>> Also, I think that we can either remove -XX:MethodFlushing or -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant and can be removed. I am not quite sure if we should do that now so it is not included in the patch. >>>>> >>>>> Testing >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a performance evaluation. >>>>> >>>>> Many thanks for looking at the patch. >>>>> Best, >>>>> Albert >>>> >>> >> > From vladimir.kozlov at oracle.com Thu Nov 7 12:24:15 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Nov 2013 12:24:15 -0800 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527BF254.9080307@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> <527BD55B.7000702@oracle.com> <527BDD70.2030809@oracle.com> <527BE972.40507@oracle.com> <527BF254.9080307@oracle.com> Message-ID: <527BF6EF.5000703@oracle.com> Good. Vladimir On 11/7/13 12:04 PM, Vladimir Ivanov wrote: > Oops, sorry about that... Fixed. > > This time I built it and ran the test to be 100% sure :-) > > Best regards, > Vladimir Ivanov > > On 11/7/13 11:26 PM, Vladimir Kozlov wrote: >> No, should be method() and 'this' and add parenthesis: >> >> + bool is_installed = (method()->code() == this) // nmethod is in >> state 'alive' and installed >> + || !this->is_in_use(); // nmethod is >> installed, but not in 'alive' state >> >> Vladimir K >> >> On 11/7/13 10:35 AM, Vladimir Ivanov wrote: >>> Sorry, blindly copy-pasted the code. >>> Thanks for catching that. >>> Fixed (same link, hit refresh). >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/7/13 10:00 PM, Vladimir Kozlov wrote: >>>> It is better. >>>> >>>> About next 2 lines. Where you get method? The method() is used to get >>>> pointer to java Method. And is_in_use() is nmethod's method. In >>>> comments >>>> you need to say nmethod (and not method): >>>> >>>> + bool is_installed = method->code() == this || // method is in state >>>> 'alive' and installed >>>> + !method->is_in_use(); // method is >>>> installed >>>> and in state: 'not-entrant', 'zombie', or, 'unloaded' >>>> >>>> Second comment too big, you can simple say: // or nmethod is not in >>>> 'alive' state. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/7/13 6:50 AM, Vladimir Ivanov wrote: >>>>> Vladimir, thank you for the feedback. >>>>> >>>>> What do you think about the following version? >>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >>>>>> Vladimir, >>>>>> >>>>>> Thank you for finding the real cause. >>>>>> >>>>>> I think you need the comment before nm->verify() in new_nmethod() >>>>>> explaining why we should avoid safepoint as you explained here. >>>>>> >>>>>> I am not comfortable about passing new allow_safepoints parameter >>>>>> through all verify calls because it is the only one case. We still >>>>>> have >>>>>> not installed nmethod at this point. There should be some check >>>>>> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >>>>>> >>>>>> I thought about the need to verify scopes in >>>>>> verify_interrupt_point() in >>>>>> all cases. But the verification code in ScopeDesc::verify() is >>>>>> commented. What? In general it is good to call it anyway. And you >>>>>> don't >>>>>> need IC to get the end_of_call() - I think we can inline what >>>>>> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >>>>>> >>>>>> This code calls CompiledIC_at() because it does IC verification >>>>>> which we >>>>>> can skip in our case. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>>>>>> Very good point, Vladimir! >>>>>>> >>>>>>> I should have looked for the bug in a different place :-) >>>>>>> >>>>>>> The problem is triggered by class redefinition and it can be >>>>>>> performed >>>>>>> under Compile_lock or during safepoint. So, in >>>>>>> ciEnv::register_method >>>>>>> it's not enough to grab Compile_lock. In addition, we need to ensure >>>>>>> that there are no safepoints possible during method installation to >>>>>>> guarantee no dependency is invalidated. >>>>>>> >>>>>>> There's one place in nmethod verification code (see MutexLocker >>>>>>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) >>>>>>> where >>>>>>> safepoint is possible and it causes the failure. >>>>>>> >>>>>>> The bug is present only in non-product builds since nmethod >>>>>>> verification >>>>>>> is absent in product bits. >>>>>>> >>>>>>> Previous fix also works, but I decided to go another route and >>>>>>> forbid >>>>>>> safepoints at all while holding Compile_lock. >>>>>>> >>>>>>> Updated webrev (will appear once cr.ojn is up): >>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>>>>>> You need to be careful to avoid deadlock since there is call: >>>>>>>> >>>>>>>> 1035 old->make_not_entrant(); >>>>>>>> >>>>>>>> Any way there is comment in register_method(): >>>>>>>> >>>>>>>> 936 // Prevent SystemDictionary::add_to_hierarchy from >>>>>>>> running >>>>>>>> 937 // and invalidating our dependencies until we install >>>>>>>> this >>>>>>>> method. >>>>>>>> 938 MutexLocker ml(Compile_lock); >>>>>>>> >>>>>>>> So how it happens that the method is invalidated by dependencies? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>>>>>> Ouch, I was misled by it's name. So, I just lowered the >>>>>>>>> likelihood of >>>>>>>>> the failure then. >>>>>>>>> >>>>>>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>>>>>> unlinks >>>>>>>>> a nmethod. >>>>>>>>> >>>>>>>>> Do you see any problems with using it to guard method installation >>>>>>>>> (method->set_code(method, nm)) in register_method() as well? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>>>>>> Note nmethodLocker is not lock: >>>>>>>>>> >>>>>>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>>>>>> if (nm == NULL) return; >>>>>>>>>> Atomic::inc(&nm->_lock_count); >>>>>>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a zombie >>>>>>>>>> method"); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>>>>>> >>>>>>>>>> So how nmethodLocker helps here? >>>>>>>>>> >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>>>>>> Thanks! Missed that one. Fixed. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>> >>>>>>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>>>>>> Should be >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> What about this place: >>>>>>>>>>>> >>>>>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if >>>>>>>>>>>> (StressNonEntrant) { >>>>>>>>>>>> >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>>>>>> Updated fix: >>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>>>>>> Updated comments. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>>>>>> registration >>>>>>>>>>>>>> and >>>>>>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>>>>>> installed >>>>>>>>>>>>>> yet. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Consider the following scenario: >>>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>>> - new nmethod(...) >>>>>>>>>>>>>> >>>>>>>>>>>>>> sweeper: >>>>>>>>>>>>>> - invalidates newly allocated nmethod and patches VEP to >>>>>>>>>>>>>> call >>>>>>>>>>>>>> handle_wrong_method >>>>>>>>>>>>>> - tries to unlink it, but >>>>>>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>>>>>> verified_entry_point() since nmethod hasn't been installed >>>>>>>>>>>>>> yet >>>>>>>>>>>>>> >>>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>>>>>> >>>>>>>>>>>>>> Calling corresponding Java method will lead to infinite loop: >>>>>>>>>>>>>> VEP of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>>>>>> resolution >>>>>>>>>>>>>> returns the very same compiled method. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the >>>>>>>>>>>>>> code >>>>>>>>>>>>>> cache >>>>>>>>>>>>>> and check that it hasn't been already invalidated by the >>>>>>>>>>>>>> sweeper >>>>>>>>>>>>>> before >>>>>>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>>>>>> invalidating it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Vladimir Ivanov From john.coomes at oracle.com Thu Nov 7 12:45:07 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 20:45:07 +0000 Subject: hg: hsx/hotspot-comp/nashorn: 29 new changesets Message-ID: <20131107204539.06EDF62433@hg.openjdk.java.net> Changeset: b01a10c7c7c2 Author: attila Date: 2013-10-17 12:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/nashorn/rev/b5b4c98b072b Merge Changeset: d8aa87d292eb Author: hannesw Date: 2013-10-18 22:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/nashorn/rev/612886fe324d Merge Changeset: f22742d5daa3 Author: kshefov Date: 2013-10-21 13:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/nashorn/rev/d04028e6b624 Merge Changeset: 0ecbc0188b64 Author: attila Date: 2013-10-22 16:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/nashorn/rev/734f71f8a2c3 Merge Changeset: 5df55690fd5b Author: sundar Date: 2013-10-23 17:30 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/nashorn/rev/767e85d2a1b3 Merge Changeset: 7985ec3782b5 Author: hannesw Date: 2013-10-25 10:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/nashorn/rev/406f2b672937 Merge Changeset: adab2c628923 Author: jlaskey Date: 2013-10-29 14:22 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/nashorn/rev/5ce78473d6c3 Merge Changeset: f0d3ac2474ee Author: lana Date: 2013-10-31 16:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/nashorn/rev/0fb1a427fbf6 Added tag jdk8-b115 for changeset f0d3ac2474ee ! .hgtags From john.coomes at oracle.com Thu Nov 7 12:43:10 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 20:43:10 +0000 Subject: hg: hsx/hotspot-comp/langtools: 32 new changesets Message-ID: <20131107204455.5603562432@hg.openjdk.java.net> Changeset: 7af634b1fc5b Author: darcy Date: 2013-10-17 19:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/41d3ffca22ff Merge Changeset: b05db8c815e8 Author: jlahoda Date: 2013-10-23 07:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/44e3ba40e00c Merge Changeset: aa91bc6e8480 Author: mchung Date: 2013-10-30 08:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/3c040b04af05 Added tag jdk8-b115 for changeset 6b4d6205366c ! .hgtags From vladimir.x.ivanov at oracle.com Thu Nov 7 13:24:18 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 08 Nov 2013 01:24:18 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527BF6EF.5000703@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> <527BD55B.7000702@oracle.com> <527BDD70.2030809@oracle.com> <527BE972.40507@oracle.com> <527BF254.9080307@oracle.com> <527BF6EF.5000703@oracle.com> Message-ID: <527C0502.7050903@oracle.com> Thank you, Vladimir. I need 1 more Reviewer to look at it. Any volunteers? :-) Best regards, Vladimir Ivanov On 11/8/13 12:24 AM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 11/7/13 12:04 PM, Vladimir Ivanov wrote: >> Oops, sorry about that... Fixed. >> >> This time I built it and ran the test to be 100% sure :-) >> >> Best regards, >> Vladimir Ivanov >> >> On 11/7/13 11:26 PM, Vladimir Kozlov wrote: >>> No, should be method() and 'this' and add parenthesis: >>> >>> + bool is_installed = (method()->code() == this) // nmethod is in >>> state 'alive' and installed >>> + || !this->is_in_use(); // nmethod is >>> installed, but not in 'alive' state >>> >>> Vladimir K >>> >>> On 11/7/13 10:35 AM, Vladimir Ivanov wrote: >>>> Sorry, blindly copy-pasted the code. >>>> Thanks for catching that. >>>> Fixed (same link, hit refresh). >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/7/13 10:00 PM, Vladimir Kozlov wrote: >>>>> It is better. >>>>> >>>>> About next 2 lines. Where you get method? The method() is used to get >>>>> pointer to java Method. And is_in_use() is nmethod's method. In >>>>> comments >>>>> you need to say nmethod (and not method): >>>>> >>>>> + bool is_installed = method->code() == this || // method is in >>>>> state >>>>> 'alive' and installed >>>>> + !method->is_in_use(); // method is >>>>> installed >>>>> and in state: 'not-entrant', 'zombie', or, 'unloaded' >>>>> >>>>> Second comment too big, you can simple say: // or nmethod is not in >>>>> 'alive' state. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/7/13 6:50 AM, Vladimir Ivanov wrote: >>>>>> Vladimir, thank you for the feedback. >>>>>> >>>>>> What do you think about the following version? >>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> Thank you for finding the real cause. >>>>>>> >>>>>>> I think you need the comment before nm->verify() in new_nmethod() >>>>>>> explaining why we should avoid safepoint as you explained here. >>>>>>> >>>>>>> I am not comfortable about passing new allow_safepoints parameter >>>>>>> through all verify calls because it is the only one case. We still >>>>>>> have >>>>>>> not installed nmethod at this point. There should be some check >>>>>>> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >>>>>>> >>>>>>> I thought about the need to verify scopes in >>>>>>> verify_interrupt_point() in >>>>>>> all cases. But the verification code in ScopeDesc::verify() is >>>>>>> commented. What? In general it is good to call it anyway. And you >>>>>>> don't >>>>>>> need IC to get the end_of_call() - I think we can inline what >>>>>>> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >>>>>>> >>>>>>> This code calls CompiledIC_at() because it does IC verification >>>>>>> which we >>>>>>> can skip in our case. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>>>>>>> Very good point, Vladimir! >>>>>>>> >>>>>>>> I should have looked for the bug in a different place :-) >>>>>>>> >>>>>>>> The problem is triggered by class redefinition and it can be >>>>>>>> performed >>>>>>>> under Compile_lock or during safepoint. So, in >>>>>>>> ciEnv::register_method >>>>>>>> it's not enough to grab Compile_lock. In addition, we need to >>>>>>>> ensure >>>>>>>> that there are no safepoints possible during method installation to >>>>>>>> guarantee no dependency is invalidated. >>>>>>>> >>>>>>>> There's one place in nmethod verification code (see MutexLocker >>>>>>>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) >>>>>>>> where >>>>>>>> safepoint is possible and it causes the failure. >>>>>>>> >>>>>>>> The bug is present only in non-product builds since nmethod >>>>>>>> verification >>>>>>>> is absent in product bits. >>>>>>>> >>>>>>>> Previous fix also works, but I decided to go another route and >>>>>>>> forbid >>>>>>>> safepoints at all while holding Compile_lock. >>>>>>>> >>>>>>>> Updated webrev (will appear once cr.ojn is up): >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>>>>>>> You need to be careful to avoid deadlock since there is call: >>>>>>>>> >>>>>>>>> 1035 old->make_not_entrant(); >>>>>>>>> >>>>>>>>> Any way there is comment in register_method(): >>>>>>>>> >>>>>>>>> 936 // Prevent SystemDictionary::add_to_hierarchy from >>>>>>>>> running >>>>>>>>> 937 // and invalidating our dependencies until we install >>>>>>>>> this >>>>>>>>> method. >>>>>>>>> 938 MutexLocker ml(Compile_lock); >>>>>>>>> >>>>>>>>> So how it happens that the method is invalidated by dependencies? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>>>>>>> Ouch, I was misled by it's name. So, I just lowered the >>>>>>>>>> likelihood of >>>>>>>>>> the failure then. >>>>>>>>>> >>>>>>>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>>>>>>> unlinks >>>>>>>>>> a nmethod. >>>>>>>>>> >>>>>>>>>> Do you see any problems with using it to guard method >>>>>>>>>> installation >>>>>>>>>> (method->set_code(method, nm)) in register_method() as well? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>>>>>>> Note nmethodLocker is not lock: >>>>>>>>>>> >>>>>>>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>>>>>>> if (nm == NULL) return; >>>>>>>>>>> Atomic::inc(&nm->_lock_count); >>>>>>>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a >>>>>>>>>>> zombie >>>>>>>>>>> method"); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>>>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>>>>>>> >>>>>>>>>>> So how nmethodLocker helps here? >>>>>>>>>>> >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>>>>>>> Thanks! Missed that one. Fixed. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>>> >>>>>>>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>> Should be >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> What about this place: >>>>>>>>>>>>> >>>>>>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if >>>>>>>>>>>>> (StressNonEntrant) { >>>>>>>>>>>>> >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>>>>>>> Updated fix: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>>>>>>> Updated comments. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>>>>>>> installed >>>>>>>>>>>>>>> yet. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Consider the following scenario: >>>>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>>>> - new nmethod(...) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> sweeper: >>>>>>>>>>>>>>> - invalidates newly allocated nmethod and patches >>>>>>>>>>>>>>> VEP to >>>>>>>>>>>>>>> call >>>>>>>>>>>>>>> handle_wrong_method >>>>>>>>>>>>>>> - tries to unlink it, but >>>>>>>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>>>>>>> verified_entry_point() since nmethod hasn't been installed >>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Calling corresponding Java method will lead to infinite >>>>>>>>>>>>>>> loop: >>>>>>>>>>>>>>> VEP of >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>>>>>>> resolution >>>>>>>>>>>>>>> returns the very same compiled method. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the >>>>>>>>>>>>>>> code >>>>>>>>>>>>>>> cache >>>>>>>>>>>>>>> and check that it hasn't been already invalidated by the >>>>>>>>>>>>>>> sweeper >>>>>>>>>>>>>>> before >>>>>>>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>>>>>>> invalidating it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Vladimir Ivanov From vladimir.kozlov at oracle.com Thu Nov 7 13:36:46 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Nov 2013 13:36:46 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527B7907.4040102@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> Message-ID: <527C07EE.3040804@oracle.com> Nice work, Albert One concern is transition "alive -> not_entrant" is counted only when the nmethod needs to be flushed because you removed in notify() in nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from other places. I think _bytes_changed should be updated by NMethodSweeper::notify() so don't remove it from nmethod.cpp. _bytes_changed should be reset when we finished sweep instead of before each sweep. Can you keep comments in code which initialize static variables (first changes in sweeper.cpp)? Please narrow your main comment, chars 90 chars per line. What is the second place? (initialization should not be count): + // of the two places where should_sweep can be set to true. You need to clear state in the comment conditions when we sweep. Like you did in the replay: (1) The code cache is getting full (2) There are sufficient state changes in the last sweep. (3) We have not been sweeping for 'some time' Split into 2 lines: + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - time_since_last_sweep - CodeCache::reverse_free_ratio(); In the print format do not use %p, use PTR_FORMAT for 'nm'. Thanks, Vladimir On 11/7/13 3:27 AM, Albert Noll wrote: > The previous mail contains an error. See inline. > > Albert > > > On 11/07/2013 12:20 PM, Albert Noll wrote: >> Vladimir, Igor, John, thanks for looking at the patch. >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >> >> Please see comments inline. >> >> >> On 11/06/2013 02:52 AM, John Rose wrote: >>> Good idea. >>> >>> -- John (on my iPhone) >>> >>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>> wrote: >>> >>>> Looks good. It?s not related to the change, but could you please >>>> consider adding some printing under PrintMethodFlushing && Verbose >>>> for the case when the method is made not entrant and include hotness >>>> and threshold values? >>>> >>>> igor >> I also agree. I added the print. >>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>> wrote: >>>> >>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>> Hi, >>>>>> >>>>>> could I get reviews for this small patch? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>> >>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>> performance regression for small code cache sizes. There >>>>>> are two issues that cause this regression: >>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>> not used). This is way too large for small code cache >>>>>> sizes (e.g., <5m). >>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>> result, mark_active_nmethods() did not set >>>>>> _invocations and _current, which results in not invoking the >>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>> TieredCompilation is enabled this was not an issue, since >>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>> called much more frequently. >>>>>> >>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>> always executed. >>>>> Good. >>>>> >> The place where I moved the adaption of NmethodSweepFraction is not >> good, since the >> the code cache size is adapted later for tiered. The current version >> should be fine. >>>>>> Solution: 2) Remove need_marking_phase(), >>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>> I think that these checks are not needed since >>>>>> 8020151, since we do stack scanning of >>>>>> active nmethods irrespective of the value of >>>>>> what need_marking_phase() returns. Since >>>>>> the patch removes need_marking_phase() printing >>>>>> out the warning (line 327 in >>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>> invoke the sweeper. I removed the warning >>>>>> and the associated code. >>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>> condition. We always want to reclaim space in codecache. >> Done. >>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>> to make sure we did not miss live nmethods). But with your changes >>>>> each safepoint triggers sweep. Do we really need sweep so >>>>> frequently? Why to sweep if there were no nmethods state change and >>>>> there is enough space in CodeCache. So I am not sure about removing >>>>> _request_mark_phase, init it with 'true' is okay. >> I agree. The current patch contains a more sophisticated logic to >> determine when we call the >> sweeper. The bottom line is that we do not invoke the sweeper only if: > > !!!!We DO INVOKE the sweeper only if: >> (1) The code cache is getting full and/or >> (2) There are sufficient state changes in the last sweep. > !!!!!(3) We have not been sweeping for 'some time' >> >> The patch contains a detailed description + examples of the logic. I >> tested the patch >> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >> code cache >> (128m + nashorn + octane), and large code cache (240m + nashorn + >> octane). The measurements >> indicate that with the current logic in place, we can reduce the >> number of sweeps by 50% for >> medium code cache sizes without increasing the maximum used code cache >> size. The difference >> is more or less not significant. >> >> Please let me know what you think about it. The main disadvantage I >> see with this change is that >> it makes reasoning about the sweeper harder than it was before. >> >> >> >> >>>>> The warning was useless so it is okay to remove it and >>>>> corresponding code. >>>>> >>>>>> >>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>> that now so it is not included in the patch. >>>>> It is for separate change. >>>>> >>>>> MethodFlushing is obsolete because we can not run VM without >>>>> codecache sweeping because we loose performance since we go into >>>>> Interpreter after codecache filled. Did you tried to run with it >>>>> OFF? I think it is good candidate to go. >>>>> >>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>> think code which currently guarded by MethodFlushing should be >>>>> executed unconditionally. >>>>> >>>>> In arguments.cpp there is table for obsolete flags: >>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>> >>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>> there to remove it in jdk9: >>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>> >>>>> Thanks, >>>>> Vladimir >> I'll file a new bug to remove the flag. I guess this change will most >> likely only make it into 8uXX. >>>>>> Testing >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>> performance evaluation. >>>>>> >>>>>> Many thanks for looking at the patch. >>>>>> Best, >>>>>> Albert >> > From albert.noll at oracle.com Thu Nov 7 13:37:11 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 07 Nov 2013 22:37:11 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527BEC7C.7030502@oracle.com> References: <52790459.7050607@oracle.com> <5279A281.1050600@oracle.com> <5279A6D8.9070503@oracle.com> <527B7851.7000005@oracle.com> <527BEC7C.7030502@oracle.com> Message-ID: <527C0807.1020802@oracle.com> Hi, On 11/07/2013 08:39 PM, Vladimir Kozlov wrote: > On 11/7/13 11:04 AM, Igor Veresov wrote: >> I?d vote to put it under PrintCodeCache. And make the messages not >> warnings, but just ?compiler disabled/enabled?. What do you think? > > Unfortunately there could be customer's tools which look for this > message. So changing it, at least now for jdk8, is not good. With > small codecache we will expect this message showing up. But with big > codecache it should not happen. I think we should keep it as warning > but throttle it when small codecache is used as Chris suggested. > > May be put it under combined check: > > if (PrintCodeCache || ReservedCodeCacheSize > X) > > Do we have a state now when we definitely will not compile any more? > Or we always making progress? I think it will be difficult to find > when it should be printed only once. > With the current version (when sweeper is enabled) we should not reach a state (unless the entire code cache is filled with OSR-methods or native methods) where we disable compilation and never enable it. As soon as we free memory from the code cache, we re-enable compilation. The message will be printed very frequently, if the code cache is significantly smaller than the application demands. We could solve the 'problem' also by adding code that prints the warning only if compilation is disabled for a certain time. The current patch (webrev.01) defines a virtual time for the sweeper (we increment time counter by one every time we call mark_active_nmethods), which we could use. Best, Albert > Thanks, > Vladimir > >> >> igor >> >> On Nov 7, 2013, at 3:24 AM, Albert Noll wrote: >> >>> Hi Chris, >>> >>> On 11/06/2013 03:18 AM, Chris Plummer wrote: >>>> BTW, one thing I forgot to mention is I now see a lot of messages >>>> for the codecache filling up. For example: >>>> >>>> Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has >>>> been disabled. >>>> Java HotSpot(TM) Client VM warning: Try increasing the code cache >>>> size using -XX:ReservedCodeCacheSize= >>>> CodeCache: size=2700Kb used=2196Kb max_used=2196Kb free=503Kb >>>> >>>> With b111, I was only seeing one message. I suspect with b111, once >>>> this message appeared compilation was never re-enabled so the >>>> message never appeared again. In that case seeing in many times now >>>> is actually a good indicator. However, it appears even when not >>>> using -XX:+PrintCodeCache, and I can see this output being a >>>> distraction for programs whose normal operation may involve >>>> constraining the codecache and having it constantly filling up. >>>> Perhaps this message should be off by default, or possibly only >>>> appear once. >>>> >>> You are right. The previous version just never re-enabled >>> compilation. I also agree that the >>> output is distracting. There are multiple ways to solve this issue. >>> I would go for a product -XX flag >>> which allows to turn this warning on/off. Would that be ok or do you >>> have a different solution in mind? >>> >>> Best, >>> Albert >>> >>>> cheers, >>>> >>>> Chris >>>> >>>> On 11/5/13 5:59 PM, Chris Plummer wrote: >>>>> Hi Albert, >>>>> >>>>> I applied your patch and got some new numbers. Performance is now >>>>> even better than it was with b110. See the chart I added to the bug. >>>>> >>>>> Nice work! >>>>> >>>>> Chris >>>>> >>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>> Hi, >>>>>> >>>>>> could I get reviews for this small patch? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>> >>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>> performance regression for small code cache sizes. There are two >>>>>> issues that cause this regression: >>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>> not used). This is way too large for small code cache sizes >>>>>> (e.g., <5m). >>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As >>>>>> a result, mark_active_nmethods() did not set _invocations and >>>>>> _current, which results in not invoking the sweeper (calling >>>>>> sweep_code_cache()) at all. When TieredCompilation is enabled >>>>>> this was not an issue, since NmethodSweeper::notify() (which sets >>>>>> _request_mark_phase) is called much more frequently. >>>>>> >>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>> always executed. >>>>>> Solution: 2) Remove need_marking_phase(), >>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>> I think that these checks are not needed since >>>>>> 8020151, since we do stack scanning of >>>>>> active nmethods irrespective of the value of >>>>>> what need_marking_phase() returns. Since >>>>>> the patch removes need_marking_phase() >>>>>> printing out the warning (line 327 in >>>>>> sweeper.cpp) is incorrect, i.e., we continue >>>>>> to invoke the sweeper. I removed the warning >>>>>> and the associated code. >>>>>> >>>>>> >>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant >>>>>> and can be removed. I am not quite sure if we should do that now >>>>>> so it is not included in the patch. >>>>>> >>>>>> Testing >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows >>>>>> a performance evaluation. >>>>>> >>>>>> Many thanks for looking at the patch. >>>>>> Best, >>>>>> Albert >>>>> >>>> >>> >> From vladimir.kozlov at oracle.com Thu Nov 7 13:48:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Nov 2013 13:48:40 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527C0807.1020802@oracle.com> References: <52790459.7050607@oracle.com> <5279A281.1050600@oracle.com> <5279A6D8.9070503@oracle.com> <527B7851.7000005@oracle.com> <527BEC7C.7030502@oracle.com> <527C0807.1020802@oracle.com> Message-ID: <527C0AB8.20606@oracle.com> On 11/7/13 1:37 PM, Albert Noll wrote: > Hi, > > > On 11/07/2013 08:39 PM, Vladimir Kozlov wrote: >> On 11/7/13 11:04 AM, Igor Veresov wrote: >>> I?d vote to put it under PrintCodeCache. And make the messages not >>> warnings, but just ?compiler disabled/enabled?. What do you think? >> >> Unfortunately there could be customer's tools which look for this >> message. So changing it, at least now for jdk8, is not good. With >> small codecache we will expect this message showing up. But with big >> codecache it should not happen. I think we should keep it as warning >> but throttle it when small codecache is used as Chris suggested. >> >> May be put it under combined check: >> >> if (PrintCodeCache || ReservedCodeCacheSize > X) >> >> Do we have a state now when we definitely will not compile any more? >> Or we always making progress? I think it will be difficult to find >> when it should be printed only once. >> > With the current version (when sweeper is enabled) we should not reach a > state (unless the entire code cache is filled with OSR-methods or native > methods) where we disable compilation and never enable it. > As soon as we free memory from the code cache, we re-enable compilation. > The message will be printed very frequently, if the code cache is > significantly smaller than the application demands. > > We could solve the 'problem' also by adding code that prints the warning > only if compilation is > disabled for a certain time. The current patch (webrev.01) defines a > virtual time for the sweeper (we increment time counter by one every > time we call mark_active_nmethods), which we could use. Or only print 10th (or whatever) message, first one must print. Thanks, Vladimir > > Best, > Albert >> Thanks, >> Vladimir >> >>> >>> igor >>> >>> On Nov 7, 2013, at 3:24 AM, Albert Noll wrote: >>> >>>> Hi Chris, >>>> >>>> On 11/06/2013 03:18 AM, Chris Plummer wrote: >>>>> BTW, one thing I forgot to mention is I now see a lot of messages >>>>> for the codecache filling up. For example: >>>>> >>>>> Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has >>>>> been disabled. >>>>> Java HotSpot(TM) Client VM warning: Try increasing the code cache >>>>> size using -XX:ReservedCodeCacheSize= >>>>> CodeCache: size=2700Kb used=2196Kb max_used=2196Kb free=503Kb >>>>> >>>>> With b111, I was only seeing one message. I suspect with b111, once >>>>> this message appeared compilation was never re-enabled so the >>>>> message never appeared again. In that case seeing in many times now >>>>> is actually a good indicator. However, it appears even when not >>>>> using -XX:+PrintCodeCache, and I can see this output being a >>>>> distraction for programs whose normal operation may involve >>>>> constraining the codecache and having it constantly filling up. >>>>> Perhaps this message should be off by default, or possibly only >>>>> appear once. >>>>> >>>> You are right. The previous version just never re-enabled >>>> compilation. I also agree that the >>>> output is distracting. There are multiple ways to solve this issue. >>>> I would go for a product -XX flag >>>> which allows to turn this warning on/off. Would that be ok or do you >>>> have a different solution in mind? >>>> >>>> Best, >>>> Albert >>>> >>>>> cheers, >>>>> >>>>> Chris >>>>> >>>>> On 11/5/13 5:59 PM, Chris Plummer wrote: >>>>>> Hi Albert, >>>>>> >>>>>> I applied your patch and got some new numbers. Performance is now >>>>>> even better than it was with b110. See the chart I added to the bug. >>>>>> >>>>>> Nice work! >>>>>> >>>>>> Chris >>>>>> >>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>> Hi, >>>>>>> >>>>>>> could I get reviews for this small patch? >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>> >>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>> performance regression for small code cache sizes. There are two >>>>>>> issues that cause this regression: >>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>> not used). This is way too large for small code cache sizes >>>>>>> (e.g., <5m). >>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As >>>>>>> a result, mark_active_nmethods() did not set _invocations and >>>>>>> _current, which results in not invoking the sweeper (calling >>>>>>> sweep_code_cache()) at all. When TieredCompilation is enabled >>>>>>> this was not an issue, since NmethodSweeper::notify() (which sets >>>>>>> _request_mark_phase) is called much more frequently. >>>>>>> >>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>> always executed. >>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>> I think that these checks are not needed since >>>>>>> 8020151, since we do stack scanning of >>>>>>> active nmethods irrespective of the value of >>>>>>> what need_marking_phase() returns. Since >>>>>>> the patch removes need_marking_phase() >>>>>>> printing out the warning (line 327 in >>>>>>> sweeper.cpp) is incorrect, i.e., we continue >>>>>>> to invoke the sweeper. I removed the warning >>>>>>> and the associated code. >>>>>>> >>>>>>> >>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant >>>>>>> and can be removed. I am not quite sure if we should do that now >>>>>>> so it is not included in the patch. >>>>>>> >>>>>>> Testing >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows >>>>>>> a performance evaluation. >>>>>>> >>>>>>> Many thanks for looking at the patch. >>>>>>> Best, >>>>>>> Albert >>>>>> >>>>> >>>> >>> > From vladimir.kozlov at oracle.com Thu Nov 7 14:04:18 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Nov 2013 14:04:18 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527C07EE.3040804@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> Message-ID: <527C0E62.8070201@oracle.com> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: > Nice work, Albert > > One concern is transition "alive -> not_entrant" is counted only when > the nmethod needs to be flushed because you removed in notify() in > nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from > other places. > I think _bytes_changed should be updated by NMethodSweeper::notify() so > don't remove it from nmethod.cpp. _bytes_changed should be reset when we > finished sweep instead of before each sweep. May be reset in both places actually. One to check that there were updates between sweeps and an other during sweep (as you do currently). Thanks, Vladimir > > Can you keep comments in code which initialize static variables (first > changes in sweeper.cpp)? > > Please narrow your main comment, chars 90 chars per line. > > What is the second place? (initialization should not be count): > > + // of the two places where should_sweep can be set to true. > > You need to clear state in the comment conditions when we sweep. Like > you did in the replay: > > (1) The code cache is getting full > (2) There are sufficient state changes in the last sweep. > (3) We have not been sweeping for 'some time' > > Split into 2 lines: > > + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - > time_since_last_sweep - CodeCache::reverse_free_ratio(); > > In the print format do not use %p, use PTR_FORMAT for 'nm'. > > Thanks, > Vladimir > > On 11/7/13 3:27 AM, Albert Noll wrote: >> The previous mail contains an error. See inline. >> >> Albert >> >> >> On 11/07/2013 12:20 PM, Albert Noll wrote: >>> Vladimir, Igor, John, thanks for looking at the patch. >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>> >>> Please see comments inline. >>> >>> >>> On 11/06/2013 02:52 AM, John Rose wrote: >>>> Good idea. >>>> >>>> -- John (on my iPhone) >>>> >>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>> wrote: >>>> >>>>> Looks good. It?s not related to the change, but could you please >>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>> for the case when the method is made not entrant and include hotness >>>>> and threshold values? >>>>> >>>>> igor >>> I also agree. I added the print. >>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>> wrote: >>>>> >>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>> Hi, >>>>>>> >>>>>>> could I get reviews for this small patch? >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>> >>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>> performance regression for small code cache sizes. There >>>>>>> are two issues that cause this regression: >>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>> not used). This is way too large for small code cache >>>>>>> sizes (e.g., <5m). >>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>>> result, mark_active_nmethods() did not set >>>>>>> _invocations and _current, which results in not invoking the >>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>> called much more frequently. >>>>>>> >>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>> always executed. >>>>>> Good. >>>>>> >>> The place where I moved the adaption of NmethodSweepFraction is not >>> good, since the >>> the code cache size is adapted later for tiered. The current version >>> should be fine. >>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>> I think that these checks are not needed since >>>>>>> 8020151, since we do stack scanning of >>>>>>> active nmethods irrespective of the value of >>>>>>> what need_marking_phase() returns. Since >>>>>>> the patch removes need_marking_phase() printing >>>>>>> out the warning (line 327 in >>>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>>> invoke the sweeper. I removed the warning >>>>>>> and the associated code. >>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>> condition. We always want to reclaim space in codecache. >>> Done. >>>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>>> to make sure we did not miss live nmethods). But with your changes >>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>> frequently? Why to sweep if there were no nmethods state change and >>>>>> there is enough space in CodeCache. So I am not sure about removing >>>>>> _request_mark_phase, init it with 'true' is okay. >>> I agree. The current patch contains a more sophisticated logic to >>> determine when we call the >>> sweeper. The bottom line is that we do not invoke the sweeper only if: >> >> !!!!We DO INVOKE the sweeper only if: >>> (1) The code cache is getting full and/or >>> (2) There are sufficient state changes in the last sweep. >> !!!!!(3) We have not been sweeping for 'some time' >>> >>> The patch contains a detailed description + examples of the logic. I >>> tested the patch >>> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >>> code cache >>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>> octane). The measurements >>> indicate that with the current logic in place, we can reduce the >>> number of sweeps by 50% for >>> medium code cache sizes without increasing the maximum used code cache >>> size. The difference >>> is more or less not significant. >>> >>> Please let me know what you think about it. The main disadvantage I >>> see with this change is that >>> it makes reasoning about the sweeper harder than it was before. >>> >>> >>> >>> >>>>>> The warning was useless so it is okay to remove it and >>>>>> corresponding code. >>>>>> >>>>>>> >>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>>> that now so it is not included in the patch. >>>>>> It is for separate change. >>>>>> >>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>> codecache sweeping because we loose performance since we go into >>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>> OFF? I think it is good candidate to go. >>>>>> >>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>>> think code which currently guarded by MethodFlushing should be >>>>>> executed unconditionally. >>>>>> >>>>>> In arguments.cpp there is table for obsolete flags: >>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>> >>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>> there to remove it in jdk9: >>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>> I'll file a new bug to remove the flag. I guess this change will most >>> likely only make it into 8uXX. >>>>>>> Testing >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>>> performance evaluation. >>>>>>> >>>>>>> Many thanks for looking at the patch. >>>>>>> Best, >>>>>>> Albert >>> >> From igor.veresov at oracle.com Thu Nov 7 18:27:10 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 7 Nov 2013 18:27:10 -0800 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <527C0502.7050903@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> <527BD55B.7000702@oracle.com> <527BDD70.2030809@oracle.com> <527BE972.40507@oracle.com> <527BF254.9080307@oracle.com> <527BF6EF.5000703@oracle.com> <527C0502.7050903@oracle.com> Message-ID: <8A558A6A-442A-41F6-A9C6-9C54551BDBB4@oracle.com> Yup, looks good. igor On Nov 7, 2013, at 1:24 PM, Vladimir Ivanov wrote: > Thank you, Vladimir. > > I need 1 more Reviewer to look at it. Any volunteers? :-) > > Best regards, > Vladimir Ivanov > > On 11/8/13 12:24 AM, Vladimir Kozlov wrote: >> Good. >> >> Vladimir >> >> On 11/7/13 12:04 PM, Vladimir Ivanov wrote: >>> Oops, sorry about that... Fixed. >>> >>> This time I built it and ran the test to be 100% sure :-) >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/7/13 11:26 PM, Vladimir Kozlov wrote: >>>> No, should be method() and 'this' and add parenthesis: >>>> >>>> + bool is_installed = (method()->code() == this) // nmethod is in >>>> state 'alive' and installed >>>> + || !this->is_in_use(); // nmethod is >>>> installed, but not in 'alive' state >>>> >>>> Vladimir K >>>> >>>> On 11/7/13 10:35 AM, Vladimir Ivanov wrote: >>>>> Sorry, blindly copy-pasted the code. >>>>> Thanks for catching that. >>>>> Fixed (same link, hit refresh). >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/7/13 10:00 PM, Vladimir Kozlov wrote: >>>>>> It is better. >>>>>> >>>>>> About next 2 lines. Where you get method? The method() is used to get >>>>>> pointer to java Method. And is_in_use() is nmethod's method. In >>>>>> comments >>>>>> you need to say nmethod (and not method): >>>>>> >>>>>> + bool is_installed = method->code() == this || // method is in >>>>>> state >>>>>> 'alive' and installed >>>>>> + !method->is_in_use(); // method is >>>>>> installed >>>>>> and in state: 'not-entrant', 'zombie', or, 'unloaded' >>>>>> >>>>>> Second comment too big, you can simple say: // or nmethod is not in >>>>>> 'alive' state. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/7/13 6:50 AM, Vladimir Ivanov wrote: >>>>>>> Vladimir, thank you for the feedback. >>>>>>> >>>>>>> What do you think about the following version? >>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >>>>>>>> Vladimir, >>>>>>>> >>>>>>>> Thank you for finding the real cause. >>>>>>>> >>>>>>>> I think you need the comment before nm->verify() in new_nmethod() >>>>>>>> explaining why we should avoid safepoint as you explained here. >>>>>>>> >>>>>>>> I am not comfortable about passing new allow_safepoints parameter >>>>>>>> through all verify calls because it is the only one case. We still >>>>>>>> have >>>>>>>> not installed nmethod at this point. There should be some check >>>>>>>> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >>>>>>>> >>>>>>>> I thought about the need to verify scopes in >>>>>>>> verify_interrupt_point() in >>>>>>>> all cases. But the verification code in ScopeDesc::verify() is >>>>>>>> commented. What? In general it is good to call it anyway. And you >>>>>>>> don't >>>>>>>> need IC to get the end_of_call() - I think we can inline what >>>>>>>> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >>>>>>>> >>>>>>>> This code calls CompiledIC_at() because it does IC verification >>>>>>>> which we >>>>>>>> can skip in our case. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>>>>>>>> Very good point, Vladimir! >>>>>>>>> >>>>>>>>> I should have looked for the bug in a different place :-) >>>>>>>>> >>>>>>>>> The problem is triggered by class redefinition and it can be >>>>>>>>> performed >>>>>>>>> under Compile_lock or during safepoint. So, in >>>>>>>>> ciEnv::register_method >>>>>>>>> it's not enough to grab Compile_lock. In addition, we need to >>>>>>>>> ensure >>>>>>>>> that there are no safepoints possible during method installation to >>>>>>>>> guarantee no dependency is invalidated. >>>>>>>>> >>>>>>>>> There's one place in nmethod verification code (see MutexLocker >>>>>>>>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) >>>>>>>>> where >>>>>>>>> safepoint is possible and it causes the failure. >>>>>>>>> >>>>>>>>> The bug is present only in non-product builds since nmethod >>>>>>>>> verification >>>>>>>>> is absent in product bits. >>>>>>>>> >>>>>>>>> Previous fix also works, but I decided to go another route and >>>>>>>>> forbid >>>>>>>>> safepoints at all while holding Compile_lock. >>>>>>>>> >>>>>>>>> Updated webrev (will appear once cr.ojn is up): >>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>>>>>>>> You need to be careful to avoid deadlock since there is call: >>>>>>>>>> >>>>>>>>>> 1035 old->make_not_entrant(); >>>>>>>>>> >>>>>>>>>> Any way there is comment in register_method(): >>>>>>>>>> >>>>>>>>>> 936 // Prevent SystemDictionary::add_to_hierarchy from >>>>>>>>>> running >>>>>>>>>> 937 // and invalidating our dependencies until we install >>>>>>>>>> this >>>>>>>>>> method. >>>>>>>>>> 938 MutexLocker ml(Compile_lock); >>>>>>>>>> >>>>>>>>>> So how it happens that the method is invalidated by dependencies? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>>>>>>>> Ouch, I was misled by it's name. So, I just lowered the >>>>>>>>>>> likelihood of >>>>>>>>>>> the failure then. >>>>>>>>>>> >>>>>>>>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>>>>>>>> unlinks >>>>>>>>>>> a nmethod. >>>>>>>>>>> >>>>>>>>>>> Do you see any problems with using it to guard method >>>>>>>>>>> installation >>>>>>>>>>> (method->set_code(method, nm)) in register_method() as well? >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>> >>>>>>>>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>>>>>>>> Note nmethodLocker is not lock: >>>>>>>>>>>> >>>>>>>>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>>>>>>>> if (nm == NULL) return; >>>>>>>>>>>> Atomic::inc(&nm->_lock_count); >>>>>>>>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a >>>>>>>>>>>> zombie >>>>>>>>>>>> method"); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>>>>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>>>>>>>> >>>>>>>>>>>> So how nmethodLocker helps here? >>>>>>>>>>>> >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>>>>>>>> Thanks! Missed that one. Fixed. >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>>> Should be >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> What about this place: >>>>>>>>>>>>>> >>>>>>>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if >>>>>>>>>>>>>> (StressNonEntrant) { >>>>>>>>>>>>>> >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>>>>>>>> Updated fix: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>>>>>>>> Updated comments. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>>>>>>>> installed >>>>>>>>>>>>>>>> yet. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Consider the following scenario: >>>>>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>>>>> - new nmethod(...) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> sweeper: >>>>>>>>>>>>>>>> - invalidates newly allocated nmethod and patches >>>>>>>>>>>>>>>> VEP to >>>>>>>>>>>>>>>> call >>>>>>>>>>>>>>>> handle_wrong_method >>>>>>>>>>>>>>>> - tries to unlink it, but >>>>>>>>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>>>>>>>> verified_entry_point() since nmethod hasn't been installed >>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Calling corresponding Java method will lead to infinite >>>>>>>>>>>>>>>> loop: >>>>>>>>>>>>>>>> VEP of >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>>>>>>>> resolution >>>>>>>>>>>>>>>> returns the very same compiled method. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the >>>>>>>>>>>>>>>> code >>>>>>>>>>>>>>>> cache >>>>>>>>>>>>>>>> and check that it hasn't been already invalidated by the >>>>>>>>>>>>>>>> sweeper >>>>>>>>>>>>>>>> before >>>>>>>>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>>>>>>>> invalidating it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Nov 8 00:52:22 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 08 Nov 2013 12:52:22 +0400 Subject: RFR (XS): 8023037 : Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie In-Reply-To: <8A558A6A-442A-41F6-A9C6-9C54551BDBB4@oracle.com> References: <5278D8EA.3030104@oracle.com> <52794294.9070105@oracle.com> <52794644.6040307@oracle.com> <5279582B.2080208@oracle.com> <52795F07.5050306@oracle.com> <527968AE.8030107@oracle.com> <527972FB.4050706@oracle.com> <527A58E8.9050405@oracle.com> <527AC828.9000509@oracle.com> <527BA899.2040708@oracle.com> <527BD55B.7000702@oracle.com> <527BDD70.2030809@oracle.com> <527BE972.40507@oracle.com> <527BF254.9080307@oracle.com> <527BF6EF.5000703@oracle.com> <527C0502.7050903@oracle.com> <8A558A6A-442A-41F6-A9C6-9C54551BDBB4@oracle.com> Message-ID: <527CA646.4050802@oracle.com> Thank you, Igor. Best regards, Vladimir Ivanov On 11/8/13 6:27 AM, Igor Veresov wrote: > Yup, looks good. > > igor > > On Nov 7, 2013, at 1:24 PM, Vladimir Ivanov wrote: > >> Thank you, Vladimir. >> >> I need 1 more Reviewer to look at it. Any volunteers? :-) >> >> Best regards, >> Vladimir Ivanov >> >> On 11/8/13 12:24 AM, Vladimir Kozlov wrote: >>> Good. >>> >>> Vladimir >>> >>> On 11/7/13 12:04 PM, Vladimir Ivanov wrote: >>>> Oops, sorry about that... Fixed. >>>> >>>> This time I built it and ran the test to be 100% sure :-) >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/7/13 11:26 PM, Vladimir Kozlov wrote: >>>>> No, should be method() and 'this' and add parenthesis: >>>>> >>>>> + bool is_installed = (method()->code() == this) // nmethod is in >>>>> state 'alive' and installed >>>>> + || !this->is_in_use(); // nmethod is >>>>> installed, but not in 'alive' state >>>>> >>>>> Vladimir K >>>>> >>>>> On 11/7/13 10:35 AM, Vladimir Ivanov wrote: >>>>>> Sorry, blindly copy-pasted the code. >>>>>> Thanks for catching that. >>>>>> Fixed (same link, hit refresh). >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 11/7/13 10:00 PM, Vladimir Kozlov wrote: >>>>>>> It is better. >>>>>>> >>>>>>> About next 2 lines. Where you get method? The method() is used to get >>>>>>> pointer to java Method. And is_in_use() is nmethod's method. In >>>>>>> comments >>>>>>> you need to say nmethod (and not method): >>>>>>> >>>>>>> + bool is_installed = method->code() == this || // method is in >>>>>>> state >>>>>>> 'alive' and installed >>>>>>> + !method->is_in_use(); // method is >>>>>>> installed >>>>>>> and in state: 'not-entrant', 'zombie', or, 'unloaded' >>>>>>> >>>>>>> Second comment too big, you can simple say: // or nmethod is not in >>>>>>> 'alive' state. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/7/13 6:50 AM, Vladimir Ivanov wrote: >>>>>>>> Vladimir, thank you for the feedback. >>>>>>>> >>>>>>>> What do you think about the following version? >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.03/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> On 11/7/13 2:52 AM, Vladimir Kozlov wrote: >>>>>>>>> Vladimir, >>>>>>>>> >>>>>>>>> Thank you for finding the real cause. >>>>>>>>> >>>>>>>>> I think you need the comment before nm->verify() in new_nmethod() >>>>>>>>> explaining why we should avoid safepoint as you explained here. >>>>>>>>> >>>>>>>>> I am not comfortable about passing new allow_safepoints parameter >>>>>>>>> through all verify calls because it is the only one case. We still >>>>>>>>> have >>>>>>>>> not installed nmethod at this point. There should be some check >>>>>>>>> (nmethod's flags/state) which we can use to skip CompiledIC_lock. >>>>>>>>> >>>>>>>>> I thought about the need to verify scopes in >>>>>>>>> verify_interrupt_point() in >>>>>>>>> all cases. But the verification code in ScopeDesc::verify() is >>>>>>>>> commented. What? In general it is good to call it anyway. And you >>>>>>>>> don't >>>>>>>>> need IC to get the end_of_call() - I think we can inline what >>>>>>>>> CompiledIC_at() does: nativeCall_at(call_site)->end_of_call(). >>>>>>>>> >>>>>>>>> This code calls CompiledIC_at() because it does IC verification >>>>>>>>> which we >>>>>>>>> can skip in our case. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 11/6/13 6:57 AM, Vladimir Ivanov wrote: >>>>>>>>>> Very good point, Vladimir! >>>>>>>>>> >>>>>>>>>> I should have looked for the bug in a different place :-) >>>>>>>>>> >>>>>>>>>> The problem is triggered by class redefinition and it can be >>>>>>>>>> performed >>>>>>>>>> under Compile_lock or during safepoint. So, in >>>>>>>>>> ciEnv::register_method >>>>>>>>>> it's not enough to grab Compile_lock. In addition, we need to >>>>>>>>>> ensure >>>>>>>>>> that there are no safepoints possible during method installation to >>>>>>>>>> guarantee no dependency is invalidated. >>>>>>>>>> >>>>>>>>>> There's one place in nmethod verification code (see MutexLocker >>>>>>>>>> ml_verify (CompiledIC_lock) in nmethod::verify_interrupt_point) >>>>>>>>>> where >>>>>>>>>> safepoint is possible and it causes the failure. >>>>>>>>>> >>>>>>>>>> The bug is present only in non-product builds since nmethod >>>>>>>>>> verification >>>>>>>>>> is absent in product bits. >>>>>>>>>> >>>>>>>>>> Previous fix also works, but I decided to go another route and >>>>>>>>>> forbid >>>>>>>>>> safepoints at all while holding Compile_lock. >>>>>>>>>> >>>>>>>>>> Updated webrev (will appear once cr.ojn is up): >>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.02/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> On 11/6/13 2:36 AM, Vladimir Kozlov wrote: >>>>>>>>>>> You need to be careful to avoid deadlock since there is call: >>>>>>>>>>> >>>>>>>>>>> 1035 old->make_not_entrant(); >>>>>>>>>>> >>>>>>>>>>> Any way there is comment in register_method(): >>>>>>>>>>> >>>>>>>>>>> 936 // Prevent SystemDictionary::add_to_hierarchy from >>>>>>>>>>> running >>>>>>>>>>> 937 // and invalidating our dependencies until we install >>>>>>>>>>> this >>>>>>>>>>> method. >>>>>>>>>>> 938 MutexLocker ml(Compile_lock); >>>>>>>>>>> >>>>>>>>>>> So how it happens that the method is invalidated by dependencies? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 11/5/13 1:52 PM, Vladimir Ivanov wrote: >>>>>>>>>>>> Ouch, I was misled by it's name. So, I just lowered the >>>>>>>>>>>> likelihood of >>>>>>>>>>>> the failure then. >>>>>>>>>>>> >>>>>>>>>>>> make_not_entrant_or_zombie holds Patching_lock when it patches & >>>>>>>>>>>> unlinks >>>>>>>>>>>> a nmethod. >>>>>>>>>>>> >>>>>>>>>>>> Do you see any problems with using it to guard method >>>>>>>>>>>> installation >>>>>>>>>>>> (method->set_code(method, nm)) in register_method() as well? >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>>> >>>>>>>>>>>> On 11/6/13 1:11 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>> Note nmethodLocker is not lock: >>>>>>>>>>>>> >>>>>>>>>>>>> void nmethodLocker::lock_nmethod(nmethod* nm, bool zombie_ok) { >>>>>>>>>>>>> if (nm == NULL) return; >>>>>>>>>>>>> Atomic::inc(&nm->_lock_count); >>>>>>>>>>>>> guarantee(zombie_ok || !nm->is_zombie(), "cannot lock a >>>>>>>>>>>>> zombie >>>>>>>>>>>>> method"); >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> The guard is nm->is_locked_by_vm() but neither >>>>>>>>>>>>> make_not_entrant_or_zombie () or register_method() use it. >>>>>>>>>>>>> >>>>>>>>>>>>> So how nmethodLocker helps here? >>>>>>>>>>>>> >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/5/13 12:42 PM, Vladimir Ivanov wrote: >>>>>>>>>>>>>> Thanks! Missed that one. Fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/5/13 11:25 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>>>> Should be >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.01/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What about this place: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp: if >>>>>>>>>>>>>>> (StressNonEntrant) { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/5/13 11:10 AM, Vladimir Ivanov wrote: >>>>>>>>>>>>>>>> Updated fix: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Removed broken StressNonEntrant code. >>>>>>>>>>>>>>>> Updated comments. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> Vladimir Ivanov >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/5/13 3:39 PM, Vladimir Ivanov wrote: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023037/webrev.00/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There's a race between compiler thread during method >>>>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> sweeper: sweeper can invalidate a nmethod which hasn't been >>>>>>>>>>>>>>>>> installed >>>>>>>>>>>>>>>>> yet. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Consider the following scenario: >>>>>>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>>>>>> - new nmethod(...) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> sweeper: >>>>>>>>>>>>>>>>> - invalidates newly allocated nmethod and patches >>>>>>>>>>>>>>>>> VEP to >>>>>>>>>>>>>>>>> call >>>>>>>>>>>>>>>>> handle_wrong_method >>>>>>>>>>>>>>>>> - tries to unlink it, but >>>>>>>>>>>>>>>>> method()->from_compiled_entry() != >>>>>>>>>>>>>>>>> verified_entry_point() since nmethod hasn't been installed >>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ciEnv::register_method: >>>>>>>>>>>>>>>>> - installs already invalidated nmethod >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Calling corresponding Java method will lead to infinite >>>>>>>>>>>>>>>>> loop: >>>>>>>>>>>>>>>>> VEP of >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> compiled method calls handle_wrong_method and call site >>>>>>>>>>>>>>>>> resolution >>>>>>>>>>>>>>>>> returns the very same compiled method. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The fix is to grab a lock after nmethod is allocated in the >>>>>>>>>>>>>>>>> code >>>>>>>>>>>>>>>>> cache >>>>>>>>>>>>>>>>> and check that it hasn't been already invalidated by the >>>>>>>>>>>>>>>>> sweeper >>>>>>>>>>>>>>>>> before >>>>>>>>>>>>>>>>> proceeding. Sweeper already synchronizes on a nmethod before >>>>>>>>>>>>>>>>> invalidating it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Testing: failing test w/ diagnostic output. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> Vladimir Ivanov > From ysr1729 at gmail.com Fri Nov 8 00:59:37 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 8 Nov 2013 00:59:37 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 Message-ID: Some of this is slightly off-topic, but here goes ... I haven't looked at the code or the patch/webrev, but I would definitely vote for a "Print" flag for CodeCache state, analogous to PrintGCDetails for Java heap space state, which will periodically (say at each GC for lack of a better metronomic signal) print the size and occupancy of the code cache. I have separately made that request to this list in an earlier email this week, and would like to reiterate that request. In general, what is the advice for pre-jdk8 (i.e. 7uXX vintage) of JVM's wrt the setting of UseCodeCacheFlushing? Does having a suitably large code cache ensure that any of the myriad issues that seem to have been logged in JDK jira/bugzilla will not affect us, or is it generally recommended that we both increase the size of the code cache to a suitably safe value as well as switch off UseCodeCacheFlushing? Finally, does anyone on this list know where one might find the hotspot sources for various jdk7uXX releases? I am interested in looking at many of them. Given the rapid changes in code cache flushing and related code in the last few months, I'd like to understand, from looking at the code and exercising it, as to what kinds of performance bugs we might be open to in this area in a specific 7uXX release. (Unless someone on this list already has a crisp description of that.) I'll verify my findings with folks on this list and share my findings once I have looked through specific 7uXX releases. It is only in the last week or two that I became aware of these performance issues, and would like to make sure we are protecting ourselves sufficiently against it given a specific 7uXX release. thanks, and sorry again for hijacking the webrev discussion for this.... -- ramki On Thu, Nov 7, 2013 at 1:48 PM, Vladimir Kozlov wrote: > On 11/7/13 1:37 PM, Albert Noll wrote: > >> Hi, >> >> >> On 11/07/2013 08:39 PM, Vladimir Kozlov wrote: >> >>> On 11/7/13 11:04 AM, Igor Veresov wrote: >>> >>>> I?d vote to put it under PrintCodeCache. And make the messages not >>>> warnings, but just ?compiler disabled/enabled?. What do you think? >>>> >>> >>> Unfortunately there could be customer's tools which look for this >>> message. So changing it, at least now for jdk8, is not good. With >>> small codecache we will expect this message showing up. But with big >>> codecache it should not happen. I think we should keep it as warning >>> but throttle it when small codecache is used as Chris suggested. >>> >>> May be put it under combined check: >>> >>> if (PrintCodeCache || ReservedCodeCacheSize > X) >>> >>> Do we have a state now when we definitely will not compile any more? >>> Or we always making progress? I think it will be difficult to find >>> when it should be printed only once. >>> >>> With the current version (when sweeper is enabled) we should not reach a >> state (unless the entire code cache is filled with OSR-methods or native >> methods) where we disable compilation and never enable it. >> As soon as we free memory from the code cache, we re-enable compilation. >> The message will be printed very frequently, if the code cache is >> significantly smaller than the application demands. >> >> We could solve the 'problem' also by adding code that prints the warning >> only if compilation is >> disabled for a certain time. The current patch (webrev.01) defines a >> virtual time for the sweeper (we increment time counter by one every >> time we call mark_active_nmethods), which we could use. >> > > Or only print 10th (or whatever) message, first one must print. > > Thanks, > Vladimir > > > >> Best, >> Albert >> >>> Thanks, >>> Vladimir >>> >>> >>>> igor >>>> >>>> On Nov 7, 2013, at 3:24 AM, Albert Noll wrote: >>>> >>>> Hi Chris, >>>>> >>>>> On 11/06/2013 03:18 AM, Chris Plummer wrote: >>>>> >>>>>> BTW, one thing I forgot to mention is I now see a lot of messages >>>>>> for the codecache filling up. For example: >>>>>> >>>>>> Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has >>>>>> been disabled. >>>>>> Java HotSpot(TM) Client VM warning: Try increasing the code cache >>>>>> size using -XX:ReservedCodeCacheSize= >>>>>> CodeCache: size=2700Kb used=2196Kb max_used=2196Kb free=503Kb >>>>>> >>>>>> With b111, I was only seeing one message. I suspect with b111, once >>>>>> this message appeared compilation was never re-enabled so the >>>>>> message never appeared again. In that case seeing in many times now >>>>>> is actually a good indicator. However, it appears even when not >>>>>> using -XX:+PrintCodeCache, and I can see this output being a >>>>>> distraction for programs whose normal operation may involve >>>>>> constraining the codecache and having it constantly filling up. >>>>>> Perhaps this message should be off by default, or possibly only >>>>>> appear once. >>>>>> >>>>>> You are right. The previous version just never re-enabled >>>>> compilation. I also agree that the >>>>> output is distracting. There are multiple ways to solve this issue. >>>>> I would go for a product -XX flag >>>>> which allows to turn this warning on/off. Would that be ok or do you >>>>> have a different solution in mind? >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> cheers, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 11/5/13 5:59 PM, Chris Plummer wrote: >>>>>> >>>>>>> Hi Albert, >>>>>>> >>>>>>> I applied your patch and got some new numbers. Performance is now >>>>>>> even better than it was with b110. See the chart I added to the bug. >>>>>>> >>>>>>> Nice work! >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> could I get reviews for this small patch? >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>> >>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>> performance regression for small code cache sizes. There are two >>>>>>>> issues that cause this regression: >>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>> not used). This is way too large for small code cache sizes >>>>>>>> (e.g., <5m). >>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As >>>>>>>> a result, mark_active_nmethods() did not set _invocations and >>>>>>>> _current, which results in not invoking the sweeper (calling >>>>>>>> sweep_code_cache()) at all. When TieredCompilation is enabled >>>>>>>> this was not an issue, since NmethodSweeper::notify() (which sets >>>>>>>> _request_mark_phase) is called much more frequently. >>>>>>>> >>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>> always executed. >>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>> I think that these checks are not needed since >>>>>>>> 8020151, since we do stack scanning of >>>>>>>> active nmethods irrespective of the value of >>>>>>>> what need_marking_phase() returns. Since >>>>>>>> the patch removes need_marking_phase() >>>>>>>> printing out the warning (line 327 in >>>>>>>> sweeper.cpp) is incorrect, i.e., we continue >>>>>>>> to invoke the sweeper. I removed the warning >>>>>>>> and the associated code. >>>>>>>> >>>>>>>> >>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant >>>>>>>> and can be removed. I am not quite sure if we should do that now >>>>>>>> so it is not included in the patch. >>>>>>>> >>>>>>>> Testing >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows >>>>>>>> a performance evaluation. >>>>>>>> >>>>>>>> Many thanks for looking at the patch. >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131108/ac09b12a/attachment-0001.html From albert.noll at oracle.com Fri Nov 8 03:06:21 2013 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 08 Nov 2013 12:06:21 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: References: Message-ID: <527CC5AD.8080504@oracle.com> Hi Ramki, I have done the most recent changes to the code cache, so I might help in answering your questions. Please see comments inline. On 11/08/2013 09:59 AM, Srinivas Ramakrishna wrote: > Some of this is slightly off-topic, but here goes ... > > I haven't looked at the code or the patch/webrev, but I would > definitely vote for a "Print" flag for CodeCache state, analogous to > PrintGCDetails for > Java heap space state, which will periodically (say at each GC for > lack of a better metronomic signal) print the size and occupancy of > the code cache. > The flag -XX:+PrintCodeCacheOnCompilation prints the status of the code cache every time memory is allocated from the code cache. > I have separately made that request to this list in an earlier email > this week, and would like to reiterate that request. > > In general, what is the advice for pre-jdk8 (i.e. 7uXX vintage) of > JVM's wrt the setting of UseCodeCacheFlushing? > Does having a suitably large code cache ensure that any of the myriad > issues that seem to have been logged in > JDK jira/bugzilla will not affect us, or is it generally recommended > that we both increase the size of the code > cache to a suitably safe value as well as switch off UseCodeCacheFlushing? > In general, we recommend to use code cache flushing. The reason is that if you do not use it and you run out of code cache, the VM is not able to compile hot methods bytecode to machine code anymore. I.e., all methods that have not been compiled will run in interpreted mode. If your application runs out of code cache and you incur a performance regression due to that, we recommend to increase the code cache size (-XX:ReservedCodeCacheSize=). > Finally, does anyone on this list know where one might find the > hotspot sources for various jdk7uXX releases? I am interested > in looking at many of them. Given the rapid changes in code cache > flushing and related code in the last few months, I'd like to > understand, from looking at the code and exercising it, as to what > kinds of performance bugs we might be open to in this area > in a specific 7uXX release. (Unless someone on this list already has a > crisp description of that.) I'll verify my findings > with folks on this list and share my findings once I have looked > through specific 7uXX releases. > You should be able to get the sources from http://openjdk.java.net/ > It is only in the last week or two that I became aware of these > performance issues, and would like to make sure we > are protecting ourselves sufficiently against it given a specific 7uXX > release. > With the release of Java 8, these issues should be fixed. > thanks, and sorry again for hijacking the webrev discussion for this.... > -- ramki > Best, Albert > > > On Thu, Nov 7, 2013 at 1:48 PM, Vladimir Kozlov > > wrote: > > On 11/7/13 1:37 PM, Albert Noll wrote: > > Hi, > > > On 11/07/2013 08:39 PM, Vladimir Kozlov wrote: > > On 11/7/13 11:04 AM, Igor Veresov wrote: > > I?d vote to put it under PrintCodeCache. And make the > messages not > warnings, but just ?compiler disabled/enabled?. What > do you think? > > > Unfortunately there could be customer's tools which look > for this > message. So changing it, at least now for jdk8, is not > good. With > small codecache we will expect this message showing up. > But with big > codecache it should not happen. I think we should keep it > as warning > but throttle it when small codecache is used as Chris > suggested. > > May be put it under combined check: > > if (PrintCodeCache || ReservedCodeCacheSize > X) > > Do we have a state now when we definitely will not compile > any more? > Or we always making progress? I think it will be difficult > to find > when it should be printed only once. > > With the current version (when sweeper is enabled) we should > not reach a > state (unless the entire code cache is filled with OSR-methods > or native > methods) where we disable compilation and never enable it. > As soon as we free memory from the code cache, we re-enable > compilation. > The message will be printed very frequently, if the code cache is > significantly smaller than the application demands. > > We could solve the 'problem' also by adding code that prints > the warning > only if compilation is > disabled for a certain time. The current patch (webrev.01) > defines a > virtual time for the sweeper (we increment time counter by one > every > time we call mark_active_nmethods), which we could use. > > > Or only print 10th (or whatever) message, first one must print. > > Thanks, > Vladimir > > > > Best, > Albert > > Thanks, > Vladimir > > > igor > > On Nov 7, 2013, at 3:24 AM, Albert Noll > > wrote: > > Hi Chris, > > On 11/06/2013 03:18 AM, Chris Plummer wrote: > > BTW, one thing I forgot to mention is I now > see a lot of messages > for the codecache filling up. For example: > > Java HotSpot(TM) Client VM warning: CodeCache > is full. Compiler has > been disabled. > Java HotSpot(TM) Client VM warning: Try > increasing the code cache > size using -XX:ReservedCodeCacheSize= > CodeCache: size=2700Kb used=2196Kb > max_used=2196Kb free=503Kb > > With b111, I was only seeing one message. I > suspect with b111, once > this message appeared compilation was never > re-enabled so the > message never appeared again. In that case > seeing in many times now > is actually a good indicator. However, it > appears even when not > using -XX:+PrintCodeCache, and I can see this > output being a > distraction for programs whose normal > operation may involve > constraining the codecache and having it > constantly filling up. > Perhaps this message should be off by default, > or possibly only > appear once. > > You are right. The previous version just never > re-enabled > compilation. I also agree that the > output is distracting. There are multiple ways to > solve this issue. > I would go for a product -XX flag > which allows to turn this warning on/off. Would > that be ok or do you > have a different solution in mind? > > Best, > Albert > > cheers, > > Chris > > On 11/5/13 5:59 PM, Chris Plummer wrote: > > Hi Albert, > > I applied your patch and got some new > numbers. Performance is now > even better than it was with b110. See the > chart I added to the bug. > > Nice work! > > Chris > > On 11/5/13 6:44 AM, Albert Noll wrote: > > Hi, > > could I get reviews for this small patch? > > bug: > https://bugs.openjdk.java.net/browse/JDK-8027593 > webrev: > http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ > > > Problem: The implementation of the > sweeper (8020151) causes a > performance regression for small code > cache sizes. There are two > issues that cause this regression: > 1) NmethodSweepFraction is only > adjusted according to the > ReservedCodecacheSize if > TieredCompilation is enabled. As a > result, NmethodSweepFraction remains > 16 (if TieredCompilation is > not used). This is way too large for > small code cache sizes > (e.g., <5m). > 2) _request_mark_phase (sweeper.cpp) > is initialized to false. As > a result, mark_active_nmethods() did > not set _invocations and > _current, which results in not > invoking the sweeper (calling > sweep_code_cache()) at all. When > TieredCompilation is enabled > this was not an issue, since > NmethodSweeper::notify() (which sets > _request_mark_phase) is called much > more frequently. > > Solution: 1) Move setting of > NmethodSweepFraction so that it is > always executed. > Solution: 2) Remove need_marking_phase(), > request_nmethod_marking(), and > reset_nmetod_marking(). > I think that these > checks are not needed since > 8020151, since we do stack scanning of > active nmethods > irrespective of the value of > what need_marking_phase() returns. Since > the patch removes > need_marking_phase() > printing out the warning (line 327 in > sweeper.cpp) is > incorrect, i.e., we continue > to invoke the sweeper. I removed the > warning > and the associated > code. > > > Also, I think that we can either > remove -XX:MethodFlushing or > -XX:UseCodeCacheFlushing. Since > 8020151, one of them is redundant > and can be removed. I am not quite > sure if we should do that now > so it is not included in the patch. > > Testing > bug: > https://bugs.openjdk.java.net/browse/JDK-8027593 > also shows > a performance evaluation. > > Many thanks for looking at the patch. > Best, > Albert > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131108/136c186b/attachment-0001.html From vladimir.x.ivanov at oracle.com Fri Nov 8 03:34:12 2013 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Fri, 08 Nov 2013 11:34:12 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8023037: Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie Message-ID: <20131108113419.DC1CA6246E@hg.openjdk.java.net> Changeset: e2509677809c Author: vlivanov Date: 2013-11-08 01:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From albert.noll at oracle.com Fri Nov 8 07:32:13 2013 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 08 Nov 2013 16:32:13 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527C0E62.8070201@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> Message-ID: <527D03FD.2010104@oracle.com> Hi Vladimir, thanks for looking at the patch. I hope that this version addresses all issues that you brought up. Here is a high-level overview of the changes since the last version: * We keep track of code cache state changes that also happen outside the sweeper. I re-installed notify, which is now called report_state_change() and is doing the job. report_state_change() checks if enough state has changed and enables the sweeper (it sets _should_sweep) to true. We reset _bytes_changed only once we have finished a while sweep cycle. That seems to make sense to me. * I added code that prints out every 10th warning that the compiler has been disabled. I also added a warning that compilation has been enabled again. I think if we print a message that compilation has been disabled, we should also print a message (maybe not a warning) that was enabled again. Here is the new webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ Best, Albert On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: > On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >> Nice work, Albert >> >> One concern is transition "alive -> not_entrant" is counted only when >> the nmethod needs to be flushed because you removed in notify() in >> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from >> other places. >> I think _bytes_changed should be updated by NMethodSweeper::notify() so >> don't remove it from nmethod.cpp. _bytes_changed should be reset when we >> finished sweep instead of before each sweep. > > May be reset in both places actually. One to check that there were > updates between sweeps and an other during sweep (as you do currently). > > Thanks, > Vladimir > >> >> Can you keep comments in code which initialize static variables (first >> changes in sweeper.cpp)? >> >> Please narrow your main comment, chars 90 chars per line. >> >> What is the second place? (initialization should not be count): >> >> + // of the two places where should_sweep can be set to true. >> >> You need to clear state in the comment conditions when we sweep. Like >> you did in the replay: >> >> (1) The code cache is getting full >> (2) There are sufficient state changes in the last sweep. >> (3) We have not been sweeping for 'some time' >> >> Split into 2 lines: >> >> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - >> time_since_last_sweep - CodeCache::reverse_free_ratio(); >> >> In the print format do not use %p, use PTR_FORMAT for 'nm'. >> >> Thanks, >> Vladimir >> >> On 11/7/13 3:27 AM, Albert Noll wrote: >>> The previous mail contains an error. See inline. >>> >>> Albert >>> >>> >>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>> Vladimir, Igor, John, thanks for looking at the patch. >>>> Here is the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>> >>>> Please see comments inline. >>>> >>>> >>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>> Good idea. >>>>> >>>>> -- John (on my iPhone) >>>>> >>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>> wrote: >>>>> >>>>>> Looks good. It?s not related to the change, but could you please >>>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>>> for the case when the method is made not entrant and include hotness >>>>>> and threshold values? >>>>>> >>>>>> igor >>>> I also agree. I added the print. >>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>> wrote: >>>>>> >>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> could I get reviews for this small patch? >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>> >>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>> performance regression for small code cache sizes. There >>>>>>>> are two issues that cause this regression: >>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>> not used). This is way too large for small code cache >>>>>>>> sizes (e.g., <5m). >>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>>>> result, mark_active_nmethods() did not set >>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>> called much more frequently. >>>>>>>> >>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>> always executed. >>>>>>> Good. >>>>>>> >>>> The place where I moved the adaption of NmethodSweepFraction is not >>>> good, since the >>>> the code cache size is adapted later for tiered. The current version >>>> should be fine. >>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>> I think that these checks are not needed since >>>>>>>> 8020151, since we do stack scanning of >>>>>>>> active nmethods irrespective of the value of >>>>>>>> what need_marking_phase() returns. Since >>>>>>>> the patch removes need_marking_phase() printing >>>>>>>> out the warning (line 327 in >>>>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>>>> invoke the sweeper. I removed the warning >>>>>>>> and the associated code. >>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>> condition. We always want to reclaim space in codecache. >>>> Done. >>>>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>>>> to make sure we did not miss live nmethods). But with your changes >>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>> frequently? Why to sweep if there were no nmethods state change and >>>>>>> there is enough space in CodeCache. So I am not sure about removing >>>>>>> _request_mark_phase, init it with 'true' is okay. >>>> I agree. The current patch contains a more sophisticated logic to >>>> determine when we call the >>>> sweeper. The bottom line is that we do not invoke the sweeper only if: >>> >>> !!!!We DO INVOKE the sweeper only if: >>>> (1) The code cache is getting full and/or >>>> (2) There are sufficient state changes in the last sweep. >>> !!!!!(3) We have not been sweeping for 'some time' >>>> >>>> The patch contains a detailed description + examples of the logic. I >>>> tested the patch >>>> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >>>> code cache >>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>> octane). The measurements >>>> indicate that with the current logic in place, we can reduce the >>>> number of sweeps by 50% for >>>> medium code cache sizes without increasing the maximum used code cache >>>> size. The difference >>>> is more or less not significant. >>>> >>>> Please let me know what you think about it. The main disadvantage I >>>> see with this change is that >>>> it makes reasoning about the sweeper harder than it was before. >>>> >>>> >>>> >>>> >>>>>>> The warning was useless so it is okay to remove it and >>>>>>> corresponding code. >>>>>>> >>>>>>>> >>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>>>> that now so it is not included in the patch. >>>>>>> It is for separate change. >>>>>>> >>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>> codecache sweeping because we loose performance since we go into >>>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>>> OFF? I think it is good candidate to go. >>>>>>> >>>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>> executed unconditionally. >>>>>>> >>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>> >>>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>>> there to remove it in jdk9: >>>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>> I'll file a new bug to remove the flag. I guess this change will most >>>> likely only make it into 8uXX. >>>>>>>> Testing >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>>>> performance evaluation. >>>>>>>> >>>>>>>> Many thanks for looking at the patch. >>>>>>>> Best, >>>>>>>> Albert >>>> >>> From ysr1729 at gmail.com Fri Nov 8 09:12:48 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 8 Nov 2013 09:12:48 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527CC5AD.8080504@oracle.com> References: <527CC5AD.8080504@oracle.com> Message-ID: Thank you Albert, I appreciate it. I have one follow-up question below:- (Note that my comments are modulo the fact that I have not played with jdk 8 at all (althouygh i do have access to the source code for hotspot trun, so i can just look at the code -- still this area is relatively unfamiliar to me in the low-level details and now, following recent rewrites and fixes, also in the high level structure) On Fri, Nov 8, 2013 at 3:06 AM, Albert Noll wrote: > Hi Ramki, > > I have done the most recent changes to the code cache, so I might help in > answering your questions. > Please see comments inline. > > > > On 11/08/2013 09:59 AM, Srinivas Ramakrishna wrote: > > Some of this is slightly off-topic, but here goes ... > > I haven't looked at the code or the patch/webrev, but I would definitely > vote for a "Print" flag for CodeCache state, analogous to PrintGCDetails for > Java heap space state, which will periodically (say at each GC for lack of > a better metronomic signal) print the size and occupancy of the code cache. > > The flag -XX:+PrintCodeCacheOnCompilation prints the status of the > code cache every time memory is allocated from the code cache. > This is fine, but my concern is that this is at too fine a level of granularity, at least in the initial phase or in a phase change when lots of methods are typically compiled. Why not also have a somewhat asynchronous style of logging at some long period of granularity the size of the code cache. My guess (without looking at the code) is that the occupancy and size can be determined at very low cost. (Hence the suggestion of a gc as a possible place to log such information.) > I have separately made that request to this list in an earlier email > this week, and would like to reiterate that request. > > In general, what is the advice for pre-jdk8 (i.e. 7uXX vintage) of JVM's > wrt the setting of UseCodeCacheFlushing? > Does having a suitably large code cache ensure that any of the myriad > issues that seem to have been logged in > JDK jira/bugzilla will not affect us, or is it generally recommended that > we both increase the size of the code > cache to a suitably safe value as well as switch off UseCodeCacheFlushing? > > In general, we recommend to use code cache flushing. The reason is > that if you do not use it and > you run out of code cache, the VM is not able to compile hot methods > bytecode to machine code > anymore. I.e., all methods that have not been compiled will run in > interpreted mode. If your application > runs out of code cache and you incur a performance regression due to that, > we recommend to > increase the code cache size (-XX:ReservedCodeCacheSize=). > Great; thanks for that advice. We have increased the reserved as well as initial code cache size. Not having looked at the code, one concern was that having a low initial size might (again without looking at the code) cause a flush cycle which might extract a performance penalty, before the cache is expanded (as it works its way to the max). One other concern was whether a sufficiently high occupancy of the code cache will cause the flush code to kick in and extract a performance drop. The strategy while we are unsure about this state of affairs has been to try and altogether avoid code cache flushing from kicking in by using a sufficiently large code cache size. If the code cache occupancy stabilizes over a period of time, this might seem to be a reasonable strategy until we are able to move to jdk 8 where these issues are hopefully all fixed. > > Finally, does anyone on this list know where one might find the hotspot > sources for various jdk7uXX releases? I am interested > in looking at many of them. Given the rapid changes in code cache flushing > and related code in the last few months, I'd like to > understand, from looking at the code and exercising it, as to what kinds > of performance bugs we might be open to in this area > in a specific 7uXX release. (Unless someone on this list already has a > crisp description of that.) I'll verify my findings > with folks on this list and share my findings once I have looked through > specific 7uXX releases. > > You should be able to get the sources from http://openjdk.java.net/ > > > I was looking for pointers to the exact URL for the hsx 7uxx release repos, but Jon has pointed me there (thanks!). > > It is only in the last week or two that I became aware of these > performance issues, and would like to make sure we > are protecting ourselves sufficiently against it given a specific 7uXX > release. > > With the release of Java 8, these issues should be fixed. > Is there any chance that some of the more critical fixes might get backported to a future 7uXX release? If not, would it be worthwhile for someone from the community (and i am happy to volunteer) to become involved in backporting them to a specific 7uXX release? I am happy to help with that, if there's any chance that it would be entertained. If such a backport is already on the cards, so much the better, and we can wait for that to happen. thanks Albert, all! -- ramki > > thanks, and sorry again for hijacking the webrev discussion for this.... > -- ramki > > > Best, > Albert > > > > On Thu, Nov 7, 2013 at 1:48 PM, Vladimir Kozlov < > vladimir.kozlov at oracle.com> wrote: > >> On 11/7/13 1:37 PM, Albert Noll wrote: >> >>> Hi, >>> >>> >>> On 11/07/2013 08:39 PM, Vladimir Kozlov wrote: >>> >>>> On 11/7/13 11:04 AM, Igor Veresov wrote: >>>> >>>>> I?d vote to put it under PrintCodeCache. And make the messages not >>>>> warnings, but just ?compiler disabled/enabled?. What do you think? >>>>> >>>> >>>> Unfortunately there could be customer's tools which look for this >>>> message. So changing it, at least now for jdk8, is not good. With >>>> small codecache we will expect this message showing up. But with big >>>> codecache it should not happen. I think we should keep it as warning >>>> but throttle it when small codecache is used as Chris suggested. >>>> >>>> May be put it under combined check: >>>> >>>> if (PrintCodeCache || ReservedCodeCacheSize > X) >>>> >>>> Do we have a state now when we definitely will not compile any more? >>>> Or we always making progress? I think it will be difficult to find >>>> when it should be printed only once. >>>> >>>> With the current version (when sweeper is enabled) we should not reach >>> a >>> state (unless the entire code cache is filled with OSR-methods or native >>> methods) where we disable compilation and never enable it. >>> As soon as we free memory from the code cache, we re-enable compilation. >>> The message will be printed very frequently, if the code cache is >>> significantly smaller than the application demands. >>> >>> We could solve the 'problem' also by adding code that prints the warning >>> only if compilation is >>> disabled for a certain time. The current patch (webrev.01) defines a >>> virtual time for the sweeper (we increment time counter by one every >>> time we call mark_active_nmethods), which we could use. >>> >> >> Or only print 10th (or whatever) message, first one must print. >> >> Thanks, >> Vladimir >> >> >> >>> Best, >>> Albert >>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>>> igor >>>>> >>>>> On Nov 7, 2013, at 3:24 AM, Albert Noll >>>>> wrote: >>>>> >>>>> Hi Chris, >>>>>> >>>>>> On 11/06/2013 03:18 AM, Chris Plummer wrote: >>>>>> >>>>>>> BTW, one thing I forgot to mention is I now see a lot of messages >>>>>>> for the codecache filling up. For example: >>>>>>> >>>>>>> Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has >>>>>>> been disabled. >>>>>>> Java HotSpot(TM) Client VM warning: Try increasing the code cache >>>>>>> size using -XX:ReservedCodeCacheSize= >>>>>>> CodeCache: size=2700Kb used=2196Kb max_used=2196Kb free=503Kb >>>>>>> >>>>>>> With b111, I was only seeing one message. I suspect with b111, once >>>>>>> this message appeared compilation was never re-enabled so the >>>>>>> message never appeared again. In that case seeing in many times now >>>>>>> is actually a good indicator. However, it appears even when not >>>>>>> using -XX:+PrintCodeCache, and I can see this output being a >>>>>>> distraction for programs whose normal operation may involve >>>>>>> constraining the codecache and having it constantly filling up. >>>>>>> Perhaps this message should be off by default, or possibly only >>>>>>> appear once. >>>>>>> >>>>>>> You are right. The previous version just never re-enabled >>>>>> compilation. I also agree that the >>>>>> output is distracting. There are multiple ways to solve this issue. >>>>>> I would go for a product -XX flag >>>>>> which allows to turn this warning on/off. Would that be ok or do you >>>>>> have a different solution in mind? >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> cheers, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 11/5/13 5:59 PM, Chris Plummer wrote: >>>>>>> >>>>>>>> Hi Albert, >>>>>>>> >>>>>>>> I applied your patch and got some new numbers. Performance is now >>>>>>>> even better than it was with b110. See the chart I added to the bug. >>>>>>>> >>>>>>>> Nice work! >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I get reviews for this small patch? >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>> >>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>> performance regression for small code cache sizes. There are two >>>>>>>>> issues that cause this regression: >>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>>> not used). This is way too large for small code cache sizes >>>>>>>>> (e.g., <5m). >>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As >>>>>>>>> a result, mark_active_nmethods() did not set _invocations and >>>>>>>>> _current, which results in not invoking the sweeper (calling >>>>>>>>> sweep_code_cache()) at all. When TieredCompilation is enabled >>>>>>>>> this was not an issue, since NmethodSweeper::notify() (which sets >>>>>>>>> _request_mark_phase) is called much more frequently. >>>>>>>>> >>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>>> always executed. >>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>> I think that these checks are not needed since >>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>> active nmethods irrespective of the value of >>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>> the patch removes need_marking_phase() >>>>>>>>> printing out the warning (line 327 in >>>>>>>>> sweeper.cpp) is incorrect, i.e., we continue >>>>>>>>> to invoke the sweeper. I removed the warning >>>>>>>>> and the associated code. >>>>>>>>> >>>>>>>>> >>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant >>>>>>>>> and can be removed. I am not quite sure if we should do that now >>>>>>>>> so it is not included in the patch. >>>>>>>>> >>>>>>>>> Testing >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows >>>>>>>>> a performance evaluation. >>>>>>>>> >>>>>>>>> Many thanks for looking at the patch. >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131108/abd93c86/attachment-0001.html From vladimir.kozlov at oracle.com Fri Nov 8 09:38:38 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Nov 2013 09:38:38 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527D03FD.2010104@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> Message-ID: <527D219E.1010101@oracle.com> This is really good. Thanks, Vladimir On 11/8/13 7:32 AM, Albert Noll wrote: > Hi Vladimir, > > thanks for looking at the patch. I hope that this version addresses all issues that > you brought up. Here is a high-level overview of the changes since the last version: > > * We keep track of code cache state changes that also happen outside the sweeper. > I re-installed notify, which is now called report_state_change() and is doing the job. > report_state_change() checks if enough state has changed and enables the sweeper > (it sets _should_sweep) to true. We reset _bytes_changed only once we have finished > a while sweep cycle. That seems to make sense to me. > > * I added code that prints out every 10th warning that the compiler has been disabled. > I also added a warning that compilation has been enabled again. I think if we print a message > that compilation has been disabled, we should also print a message (maybe not a warning) > that was enabled again. > > Here is the new webrev: > http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ > > Best, > Albert > > On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>> Nice work, Albert >>> >>> One concern is transition "alive -> not_entrant" is counted only when >>> the nmethod needs to be flushed because you removed in notify() in >>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from >>> other places. >>> I think _bytes_changed should be updated by NMethodSweeper::notify() so >>> don't remove it from nmethod.cpp. _bytes_changed should be reset when we >>> finished sweep instead of before each sweep. >> >> May be reset in both places actually. One to check that there were updates between sweeps and an other during sweep >> (as you do currently). >> >> Thanks, >> Vladimir >> >>> >>> Can you keep comments in code which initialize static variables (first >>> changes in sweeper.cpp)? >>> >>> Please narrow your main comment, chars 90 chars per line. >>> >>> What is the second place? (initialization should not be count): >>> >>> + // of the two places where should_sweep can be set to true. >>> >>> You need to clear state in the comment conditions when we sweep. Like >>> you did in the replay: >>> >>> (1) The code cache is getting full >>> (2) There are sufficient state changes in the last sweep. >>> (3) We have not been sweeping for 'some time' >>> >>> Split into 2 lines: >>> >>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - >>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>> >>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>> The previous mail contains an error. See inline. >>>> >>>> Albert >>>> >>>> >>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>> Here is the updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>> >>>>> Please see comments inline. >>>>> >>>>> >>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>> Good idea. >>>>>> >>>>>> -- John (on my iPhone) >>>>>> >>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>> wrote: >>>>>> >>>>>>> Looks good. It?s not related to the change, but could you please >>>>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>>>> for the case when the method is made not entrant and include hotness >>>>>>> and threshold values? >>>>>>> >>>>>>> igor >>>>> I also agree. I added the print. >>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>> wrote: >>>>>>> >>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I get reviews for this small patch? >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>> >>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>> are two issues that cause this regression: >>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>>> not used). This is way too large for small code cache >>>>>>>>> sizes (e.g., <5m). >>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>> called much more frequently. >>>>>>>>> >>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>>> always executed. >>>>>>>> Good. >>>>>>>> >>>>> The place where I moved the adaption of NmethodSweepFraction is not >>>>> good, since the >>>>> the code cache size is adapted later for tiered. The current version >>>>> should be fine. >>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>> I think that these checks are not needed since >>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>> active nmethods irrespective of the value of >>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>> the patch removes need_marking_phase() printing >>>>>>>>> out the warning (line 327 in >>>>>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>> and the associated code. >>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>> condition. We always want to reclaim space in codecache. >>>>> Done. >>>>>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>>>>> to make sure we did not miss live nmethods). But with your changes >>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>> frequently? Why to sweep if there were no nmethods state change and >>>>>>>> there is enough space in CodeCache. So I am not sure about removing >>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>> I agree. The current patch contains a more sophisticated logic to >>>>> determine when we call the >>>>> sweeper. The bottom line is that we do not invoke the sweeper only if: >>>> >>>> !!!!We DO INVOKE the sweeper only if: >>>>> (1) The code cache is getting full and/or >>>>> (2) There are sufficient state changes in the last sweep. >>>> !!!!!(3) We have not been sweeping for 'some time' >>>>> >>>>> The patch contains a detailed description + examples of the logic. I >>>>> tested the patch >>>>> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >>>>> code cache >>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>> octane). The measurements >>>>> indicate that with the current logic in place, we can reduce the >>>>> number of sweeps by 50% for >>>>> medium code cache sizes without increasing the maximum used code cache >>>>> size. The difference >>>>> is more or less not significant. >>>>> >>>>> Please let me know what you think about it. The main disadvantage I >>>>> see with this change is that >>>>> it makes reasoning about the sweeper harder than it was before. >>>>> >>>>> >>>>> >>>>> >>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>> corresponding code. >>>>>>>> >>>>>>>>> >>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>>>>> that now so it is not included in the patch. >>>>>>>> It is for separate change. >>>>>>>> >>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>> codecache sweeping because we loose performance since we go into >>>>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>>>> OFF? I think it is good candidate to go. >>>>>>>> >>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>> executed unconditionally. >>>>>>>> >>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>> >>>>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>>>> there to remove it in jdk9: >>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>> I'll file a new bug to remove the flag. I guess this change will most >>>>> likely only make it into 8uXX. >>>>>>>>> Testing >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>>>>> performance evaluation. >>>>>>>>> >>>>>>>>> Many thanks for looking at the patch. >>>>>>>>> Best, >>>>>>>>> Albert >>>>> >>>> > From vladimir.kozlov at oracle.com Fri Nov 8 10:08:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Nov 2013 10:08:57 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: References: <527CC5AD.8080504@oracle.com> Message-ID: <527D28B9.2060208@oracle.com> Hi, Ramki I doubt we will backport to 7uXX CodeCache work we did in jdk8. We start working on jdk9 soon and jdk7u is moved to sustaining state. Unless our main 'customer' ask us to do that but I did not hear complains from them. For 7u the only solution is increase reserved CodeCache and use UseCodeCacheFlushing (which is ON by default since 7u40). You may also have to increase CodeCacheFlushingMinimumFreeSpace (1500K default). We saw cases when there was no space left for compiler's temp buffers so we can't compile but left space was a little > 1500K so flushing was not triggered. There are other product flushing flags which you can play with. Note, flushing is triggered when no space left in whole reserved space. It is not triggered when you used up initial space. We will work on logging in jdk9 and 8u. Regards, Vladimir On 11/8/13 9:12 AM, Srinivas Ramakrishna wrote: > Thank you Albert, I appreciate it. I have one follow-up question below:- > (Note that my comments are modulo the fact that I have not played with > jdk 8 at all (althouygh i do have access to the source code for hotspot trun, so i can just look at the code -- > still this area is relatively unfamiliar to me in the low-level details and now, following recent rewrites and fixes, > also in the high level structure) > > > On Fri, Nov 8, 2013 at 3:06 AM, Albert Noll > wrote: > > Hi Ramki, > > I have done the most recent changes to the code cache, so I might help in answering your questions. > Please see comments inline. > > > > > On 11/08/2013 09:59 AM, Srinivas Ramakrishna wrote: >> Some of this is slightly off-topic, but here goes ... >> >> I haven't looked at the code or the patch/webrev, but I would definitely vote for a "Print" flag for CodeCache >> state, analogous to PrintGCDetails for >> Java heap space state, which will periodically (say at each GC for lack of a better metronomic signal) print the >> size and occupancy of the code cache. >> > The flag -XX:+PrintCodeCacheOnCompilation prints the status of the code cache every time memory is allocated from > the code cache. > > > This is fine, but my concern is that this is at too fine a level of granularity, at least in the initial phase or in a > phase change when > lots of methods are typically compiled. Why not also have a somewhat asynchronous style of logging at some long period > of granularity > the size of the code cache. My guess (without looking at the code) is that the occupancy and size can be determined at > very low > cost. (Hence the suggestion of a gc as a possible place to log such information.) > > >> I have separately made that request to this list in an earlier email this week, and would like to reiterate that >> request. >> >> In general, what is the advice for pre-jdk8 (i.e. 7uXX vintage) of JVM's wrt the setting of UseCodeCacheFlushing? >> Does having a suitably large code cache ensure that any of the myriad issues that seem to have been logged in >> JDK jira/bugzilla will not affect us, or is it generally recommended that we both increase the size of the code >> cache to a suitably safe value as well as switch off UseCodeCacheFlushing? >> > In general, we recommend to use code cache flushing. The reason is that if you do not use it and > you run out of code cache, the VM is not able to compile hot methods bytecode to machine code > anymore. I.e., all methods that have not been compiled will run in interpreted mode. If your application > runs out of code cache and you incur a performance regression due to that, we recommend to > increase the code cache size (-XX:ReservedCodeCacheSize=). > > > Great; thanks for that advice. We have increased the reserved as well as initial code cache size. Not having looked at the > code, one concern was that having a low initial size might (again without looking at the code) cause a flush cycle which > might > extract a performance penalty, before the cache is expanded (as it works its way to the max). > > One other concern was whether a sufficiently high occupancy of the code cache will cause the flush code to kick in > and extract a performance drop. The strategy while we are unsure about this state of affairs has been to try and > altogether avoid code cache flushing from kicking in by using a sufficiently large code cache size. > > If the code cache occupancy stabilizes over a period of time, this might seem to be a reasonable strategy until > we are able to move to jdk 8 where these issues are hopefully all fixed. > > >> Finally, does anyone on this list know where one might find the hotspot sources for various jdk7uXX releases? I am >> interested >> in looking at many of them. Given the rapid changes in code cache flushing and related code in the last few >> months, I'd like to >> understand, from looking at the code and exercising it, as to what kinds of performance bugs we might be open to >> in this area >> in a specific 7uXX release. (Unless someone on this list already has a crisp description of that.) I'll verify my >> findings >> with folks on this list and share my findings once I have looked through specific 7uXX releases. >> > You should be able to get the sources from http://openjdk.java.net/ > > > > I was looking for pointers to the exact URL for the hsx 7uxx release repos, but Jon has pointed me there (thanks!). > > >> It is only in the last week or two that I became aware of these performance issues, and would like to make sure we >> are protecting ourselves sufficiently against it given a specific 7uXX release. >> > With the release of Java 8, these issues should be fixed. > > > > Is there any chance that some of the more critical fixes might get backported to a future 7uXX release? > If not, would it be worthwhile for someone from the community (and i am happy to volunteer) to become involved in > backporting > them to a specific 7uXX release? I am happy to help with that, if there's any chance that it would be entertained. > If such a backport is already on the cards, so much the better, and we can wait for that to happen. > > thanks Albert, all! > -- ramki > > >> thanks, and sorry again for hijacking the webrev discussion for this.... >> -- ramki >> > Best, > Albert > >> >> >> On Thu, Nov 7, 2013 at 1:48 PM, Vladimir Kozlov > >> wrote: >> >> On 11/7/13 1:37 PM, Albert Noll wrote: >> >> Hi, >> >> >> On 11/07/2013 08:39 PM, Vladimir Kozlov wrote: >> >> On 11/7/13 11:04 AM, Igor Veresov wrote: >> >> I?d vote to put it under PrintCodeCache. And make the messages not >> warnings, but just ?compiler disabled/enabled?. What do you think? >> >> >> Unfortunately there could be customer's tools which look for this >> message. So changing it, at least now for jdk8, is not good. With >> small codecache we will expect this message showing up. But with big >> codecache it should not happen. I think we should keep it as warning >> but throttle it when small codecache is used as Chris suggested. >> >> May be put it under combined check: >> >> if (PrintCodeCache || ReservedCodeCacheSize > X) >> >> Do we have a state now when we definitely will not compile any more? >> Or we always making progress? I think it will be difficult to find >> when it should be printed only once. >> >> With the current version (when sweeper is enabled) we should not reach a >> state (unless the entire code cache is filled with OSR-methods or native >> methods) where we disable compilation and never enable it. >> As soon as we free memory from the code cache, we re-enable compilation. >> The message will be printed very frequently, if the code cache is >> significantly smaller than the application demands. >> >> We could solve the 'problem' also by adding code that prints the warning >> only if compilation is >> disabled for a certain time. The current patch (webrev.01) defines a >> virtual time for the sweeper (we increment time counter by one every >> time we call mark_active_nmethods), which we could use. >> >> >> Or only print 10th (or whatever) message, first one must print. >> >> Thanks, >> Vladimir >> >> >> >> Best, >> Albert >> >> Thanks, >> Vladimir >> >> >> igor >> >> On Nov 7, 2013, at 3:24 AM, Albert Noll > >> wrote: >> >> Hi Chris, >> >> On 11/06/2013 03:18 AM, Chris Plummer wrote: >> >> BTW, one thing I forgot to mention is I now see a lot of messages >> for the codecache filling up. For example: >> >> Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has >> been disabled. >> Java HotSpot(TM) Client VM warning: Try increasing the code cache >> size using -XX:ReservedCodeCacheSize= >> CodeCache: size=2700Kb used=2196Kb max_used=2196Kb free=503Kb >> >> With b111, I was only seeing one message. I suspect with b111, once >> this message appeared compilation was never re-enabled so the >> message never appeared again. In that case seeing in many times now >> is actually a good indicator. However, it appears even when not >> using -XX:+PrintCodeCache, and I can see this output being a >> distraction for programs whose normal operation may involve >> constraining the codecache and having it constantly filling up. >> Perhaps this message should be off by default, or possibly only >> appear once. >> >> You are right. The previous version just never re-enabled >> compilation. I also agree that the >> output is distracting. There are multiple ways to solve this issue. >> I would go for a product -XX flag >> which allows to turn this warning on/off. Would that be ok or do you >> have a different solution in mind? >> >> Best, >> Albert >> >> cheers, >> >> Chris >> >> On 11/5/13 5:59 PM, Chris Plummer wrote: >> >> Hi Albert, >> >> I applied your patch and got some new numbers. Performance is now >> even better than it was with b110. See the chart I added to the bug. >> >> Nice work! >> >> Chris >> >> On 11/5/13 6:44 AM, Albert Noll wrote: >> >> Hi, >> >> could I get reviews for this small patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >> >> >> Problem: The implementation of the sweeper (8020151) causes a >> performance regression for small code cache sizes. There are two >> issues that cause this regression: >> 1) NmethodSweepFraction is only adjusted according to the >> ReservedCodecacheSize if TieredCompilation is enabled. As a >> result, NmethodSweepFraction remains 16 (if TieredCompilation is >> not used). This is way too large for small code cache sizes >> (e.g., <5m). >> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As >> a result, mark_active_nmethods() did not set _invocations and >> _current, which results in not invoking the sweeper (calling >> sweep_code_cache()) at all. When TieredCompilation is enabled >> this was not an issue, since NmethodSweeper::notify() (which sets >> _request_mark_phase) is called much more frequently. >> >> Solution: 1) Move setting of NmethodSweepFraction so that it is >> always executed. >> Solution: 2) Remove need_marking_phase(), >> request_nmethod_marking(), and reset_nmetod_marking(). >> I think that these checks are not needed since >> 8020151, since we do stack scanning of >> active nmethods irrespective of the value of >> what need_marking_phase() returns. Since >> the patch removes need_marking_phase() >> printing out the warning (line 327 in >> sweeper.cpp) is incorrect, i.e., we continue >> to invoke the sweeper. I removed the warning >> and the associated code. >> >> >> Also, I think that we can either remove -XX:MethodFlushing or >> -XX:UseCodeCacheFlushing. Since 8020151, one of them is redundant >> and can be removed. I am not quite sure if we should do that now >> so it is not included in the patch. >> >> Testing >> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows >> a performance evaluation. >> >> Many thanks for looking at the patch. >> Best, >> Albert >> >> >> >> >> >> >> > > From albert.noll at oracle.com Fri Nov 8 11:04:56 2013 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 08 Nov 2013 20:04:56 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527D219E.1010101@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <527D219E.1010101@oracle.com> Message-ID: <527D35D8.5060202@oracle.com> Thank you, Vladimir. Best, Albert On 11/08/2013 06:38 PM, Vladimir Kozlov wrote: > This is really good. > > Thanks, > Vladimir > > On 11/8/13 7:32 AM, Albert Noll wrote: >> Hi Vladimir, >> >> thanks for looking at the patch. I hope that this version addresses >> all issues that >> you brought up. Here is a high-level overview of the changes since >> the last version: >> >> * We keep track of code cache state changes that also happen outside >> the sweeper. >> I re-installed notify, which is now called report_state_change() >> and is doing the job. >> report_state_change() checks if enough state has changed and >> enables the sweeper >> (it sets _should_sweep) to true. We reset _bytes_changed only >> once we have finished >> a while sweep cycle. That seems to make sense to me. >> >> * I added code that prints out every 10th warning that the compiler >> has been disabled. >> I also added a warning that compilation has been enabled again. I >> think if we print a message >> that compilation has been disabled, we should also print a >> message (maybe not a warning) >> that was enabled again. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >> >> Best, >> Albert >> >> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>> Nice work, Albert >>>> >>>> One concern is transition "alive -> not_entrant" is counted only when >>>> the nmethod needs to be flushed because you removed in notify() in >>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called >>>> from >>>> other places. >>>> I think _bytes_changed should be updated by >>>> NMethodSweeper::notify() so >>>> don't remove it from nmethod.cpp. _bytes_changed should be reset >>>> when we >>>> finished sweep instead of before each sweep. >>> >>> May be reset in both places actually. One to check that there were >>> updates between sweeps and an other during sweep >>> (as you do currently). >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Can you keep comments in code which initialize static variables (first >>>> changes in sweeper.cpp)? >>>> >>>> Please narrow your main comment, chars 90 chars per line. >>>> >>>> What is the second place? (initialization should not be count): >>>> >>>> + // of the two places where should_sweep can be set to true. >>>> >>>> You need to clear state in the comment conditions when we sweep. Like >>>> you did in the replay: >>>> >>>> (1) The code cache is getting full >>>> (2) There are sufficient state changes in the last sweep. >>>> (3) We have not been sweeping for 'some time' >>>> >>>> Split into 2 lines: >>>> >>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - >>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>> >>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>> The previous mail contains an error. See inline. >>>>> >>>>> Albert >>>>> >>>>> >>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>> Here is the updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>> >>>>>> Please see comments inline. >>>>>> >>>>>> >>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>> Good idea. >>>>>>> >>>>>>> -- John (on my iPhone) >>>>>>> >>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>> wrote: >>>>>>> >>>>>>>> Looks good. It?s not related to the change, but could you please >>>>>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>>>>> for the case when the method is made not entrant and include >>>>>>>> hotness >>>>>>>> and threshold values? >>>>>>>> >>>>>>>> igor >>>>>> I also agree. I added the print. >>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>> >>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>> are two issues that cause this regression: >>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. >>>>>>>>>> As a >>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>> called much more frequently. >>>>>>>>>> >>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>>>> always executed. >>>>>>>>> Good. >>>>>>>>> >>>>>> The place where I moved the adaption of NmethodSweepFraction is not >>>>>> good, since the >>>>>> the code cache size is adapted later for tiered. The current version >>>>>> should be fine. >>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>> I think that these checks are not needed >>>>>>>>>> since >>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>> active nmethods irrespective of the value of >>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>> the patch removes need_marking_phase() >>>>>>>>>> printing >>>>>>>>>> out the warning (line 327 in >>>>>>>>>> sweeper.cpp) is incorrect, i.e., we >>>>>>>>>> continue to >>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>> and the associated code. >>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>> Done. >>>>>>>>> To do nmethod marking at each safepoint is fine (we have to >>>>>>>>> do it >>>>>>>>> to make sure we did not miss live nmethods). But with your >>>>>>>>> changes >>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>> frequently? Why to sweep if there were no nmethods state >>>>>>>>> change and >>>>>>>>> there is enough space in CodeCache. So I am not sure about >>>>>>>>> removing >>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>> determine when we call the >>>>>> sweeper. The bottom line is that we do not invoke the sweeper >>>>>> only if: >>>>> >>>>> !!!!We DO INVOKE the sweeper only if: >>>>>> (1) The code cache is getting full and/or >>>>>> (2) There are sufficient state changes in the last sweep. >>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>> >>>>>> The patch contains a detailed description + examples of the logic. I >>>>>> tested the patch >>>>>> with small code cache sizes (specjvm98 + <4m code cache), >>>>>> medium-sized >>>>>> code cache >>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>> octane). The measurements >>>>>> indicate that with the current logic in place, we can reduce the >>>>>> number of sweeps by 50% for >>>>>> medium code cache sizes without increasing the maximum used code >>>>>> cache >>>>>> size. The difference >>>>>> is more or less not significant. >>>>>> >>>>>> Please let me know what you think about it. The main disadvantage I >>>>>> see with this change is that >>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>> corresponding code. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>> redundant and can be removed. I am not quite sure if we >>>>>>>>>> should do >>>>>>>>>> that now so it is not included in the patch. >>>>>>>>> It is for separate change. >>>>>>>>> >>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>> codecache sweeping because we loose performance since we go into >>>>>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>> >>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>>>>> can't remove it easily. But don't replace MethodFlushing with >>>>>>>>> it. I >>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>> executed unconditionally. >>>>>>>>> >>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>> >>>>>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>>>>> there to remove it in jdk9: >>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>> I'll file a new bug to remove the flag. I guess this change will >>>>>> most >>>>>> likely only make it into 8uXX. >>>>>>>>>> Testing >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also >>>>>>>>>> shows a >>>>>>>>>> performance evaluation. >>>>>>>>>> >>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>> >>>>> >> From ysr1729 at gmail.com Fri Nov 8 12:59:37 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 8 Nov 2013 12:59:37 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527D28B9.2060208@oracle.com> References: <527CC5AD.8080504@oracle.com> <527D28B9.2060208@oracle.com> Message-ID: Thanks Vladimir (and Albert) for all of the details. This is immensely helpful to me for working around this issue in 7uxx. -- ramki On Fri, Nov 8, 2013 at 10:08 AM, Vladimir Kozlov wrote: > Hi, Ramki > > I doubt we will backport to 7uXX CodeCache work we did in jdk8. We start > working on jdk9 soon and jdk7u is moved to sustaining state. Unless our > main 'customer' ask us to do that but I did not hear complains from them. > > For 7u the only solution is increase reserved CodeCache and use > UseCodeCacheFlushing (which is ON by default since 7u40). You may also have > to increase CodeCacheFlushingMinimumFreeSpace (1500K default). We saw > cases when there was no space left for compiler's temp buffers so we can't > compile but left space was a little > 1500K so flushing was not triggered. > There are other product flushing flags which you can play with. > > Note, flushing is triggered when no space left in whole reserved space. It > is not triggered when you used up initial space. > > We will work on logging in jdk9 and 8u. > > Regards, > Vladimir > > > On 11/8/13 9:12 AM, Srinivas Ramakrishna wrote: > >> Thank you Albert, I appreciate it. I have one follow-up question below:- >> (Note that my comments are modulo the fact that I have not played with >> jdk 8 at all (althouygh i do have access to the source code for hotspot >> trun, so i can just look at the code -- >> still this area is relatively unfamiliar to me in the low-level details >> and now, following recent rewrites and fixes, >> also in the high level structure) >> >> >> On Fri, Nov 8, 2013 at 3:06 AM, Albert Noll > albert.noll at oracle.com>> wrote: >> >> Hi Ramki, >> >> I have done the most recent changes to the code cache, so I might >> help in answering your questions. >> Please see comments inline. >> >> >> >> >> On 11/08/2013 09:59 AM, Srinivas Ramakrishna wrote: >> >>> Some of this is slightly off-topic, but here goes ... >>> >>> I haven't looked at the code or the patch/webrev, but I would >>> definitely vote for a "Print" flag for CodeCache >>> state, analogous to PrintGCDetails for >>> Java heap space state, which will periodically (say at each GC for >>> lack of a better metronomic signal) print the >>> size and occupancy of the code cache. >>> >>> The flag -XX:+PrintCodeCacheOnCompilation prints the status of the >> code cache every time memory is allocated from >> the code cache. >> >> >> This is fine, but my concern is that this is at too fine a level of >> granularity, at least in the initial phase or in a >> phase change when >> lots of methods are typically compiled. Why not also have a somewhat >> asynchronous style of logging at some long period >> of granularity >> the size of the code cache. My guess (without looking at the code) is >> that the occupancy and size can be determined at >> very low >> cost. (Hence the suggestion of a gc as a possible place to log such >> information.) >> >> >> I have separately made that request to this list in an earlier email >>> this week, and would like to reiterate that >>> request. >>> >>> In general, what is the advice for pre-jdk8 (i.e. 7uXX vintage) of >>> JVM's wrt the setting of UseCodeCacheFlushing? >>> Does having a suitably large code cache ensure that any of the >>> myriad issues that seem to have been logged in >>> JDK jira/bugzilla will not affect us, or is it generally recommended >>> that we both increase the size of the code >>> cache to a suitably safe value as well as switch off >>> UseCodeCacheFlushing? >>> >>> In general, we recommend to use code cache flushing. The reason is >> that if you do not use it and >> you run out of code cache, the VM is not able to compile hot methods >> bytecode to machine code >> anymore. I.e., all methods that have not been compiled will run in >> interpreted mode. If your application >> runs out of code cache and you incur a performance regression due to >> that, we recommend to >> increase the code cache size (-XX:ReservedCodeCacheSize=). >> >> >> Great; thanks for that advice. We have increased the reserved as well as >> initial code cache size. Not having looked at the >> code, one concern was that having a low initial size might (again without >> looking at the code) cause a flush cycle which >> might >> extract a performance penalty, before the cache is expanded (as it works >> its way to the max). >> >> One other concern was whether a sufficiently high occupancy of the code >> cache will cause the flush code to kick in >> and extract a performance drop. The strategy while we are unsure about >> this state of affairs has been to try and >> altogether avoid code cache flushing from kicking in by using a >> sufficiently large code cache size. >> >> If the code cache occupancy stabilizes over a period of time, this might >> seem to be a reasonable strategy until >> we are able to move to jdk 8 where these issues are hopefully all fixed. >> >> >> Finally, does anyone on this list know where one might find the >>> hotspot sources for various jdk7uXX releases? I am >>> interested >>> in looking at many of them. Given the rapid changes in code cache >>> flushing and related code in the last few >>> months, I'd like to >>> understand, from looking at the code and exercising it, as to what >>> kinds of performance bugs we might be open to >>> in this area >>> in a specific 7uXX release. (Unless someone on this list already has >>> a crisp description of that.) I'll verify my >>> findings >>> with folks on this list and share my findings once I have looked >>> through specific 7uXX releases. >>> >>> You should be able to get the sources from http://openjdk.java.net/ >> >> >> >> I was looking for pointers to the exact URL for the hsx 7uxx release >> repos, but Jon has pointed me there (thanks!). >> >> >> It is only in the last week or two that I became aware of these >>> performance issues, and would like to make sure we >>> are protecting ourselves sufficiently against it given a specific >>> 7uXX release. >>> >>> With the release of Java 8, these issues should be fixed. >> >> >> >> Is there any chance that some of the more critical fixes might get >> backported to a future 7uXX release? >> If not, would it be worthwhile for someone from the community (and i am >> happy to volunteer) to become involved in >> backporting >> them to a specific 7uXX release? I am happy to help with that, if there's >> any chance that it would be entertained. >> If such a backport is already on the cards, so much the better, and we >> can wait for that to happen. >> >> thanks Albert, all! >> -- ramki >> >> >> thanks, and sorry again for hijacking the webrev discussion for >>> this.... >>> -- ramki >>> >>> Best, >> Albert >> >> >>> >>> On Thu, Nov 7, 2013 at 1:48 PM, Vladimir Kozlov < >>> vladimir.kozlov at oracle.com > >>> >>> wrote: >>> >>> On 11/7/13 1:37 PM, Albert Noll wrote: >>> >>> Hi, >>> >>> >>> On 11/07/2013 08:39 PM, Vladimir Kozlov wrote: >>> >>> On 11/7/13 11:04 AM, Igor Veresov wrote: >>> >>> I?d vote to put it under PrintCodeCache. And make >>> the messages not >>> warnings, but just ?compiler disabled/enabled?. What >>> do you think? >>> >>> >>> Unfortunately there could be customer's tools which look >>> for this >>> message. So changing it, at least now for jdk8, is not >>> good. With >>> small codecache we will expect this message showing up. >>> But with big >>> codecache it should not happen. I think we should keep >>> it as warning >>> but throttle it when small codecache is used as Chris >>> suggested. >>> >>> May be put it under combined check: >>> >>> if (PrintCodeCache || ReservedCodeCacheSize > X) >>> >>> Do we have a state now when we definitely will not >>> compile any more? >>> Or we always making progress? I think it will be >>> difficult to find >>> when it should be printed only once. >>> >>> With the current version (when sweeper is enabled) we should >>> not reach a >>> state (unless the entire code cache is filled with >>> OSR-methods or native >>> methods) where we disable compilation and never enable it. >>> As soon as we free memory from the code cache, we re-enable >>> compilation. >>> The message will be printed very frequently, if the code >>> cache is >>> significantly smaller than the application demands. >>> >>> We could solve the 'problem' also by adding code that prints >>> the warning >>> only if compilation is >>> disabled for a certain time. The current patch (webrev.01) >>> defines a >>> virtual time for the sweeper (we increment time counter by >>> one every >>> time we call mark_active_nmethods), which we could use. >>> >>> >>> Or only print 10th (or whatever) message, first one must print. >>> >>> Thanks, >>> Vladimir >>> >>> >>> >>> Best, >>> Albert >>> >>> Thanks, >>> Vladimir >>> >>> >>> igor >>> >>> On Nov 7, 2013, at 3:24 AM, Albert Noll < >>> albert.noll at oracle.com > >>> >>> wrote: >>> >>> Hi Chris, >>> >>> On 11/06/2013 03:18 AM, Chris Plummer wrote: >>> >>> BTW, one thing I forgot to mention is I now >>> see a lot of messages >>> for the codecache filling up. For example: >>> >>> Java HotSpot(TM) Client VM warning: >>> CodeCache is full. Compiler has >>> been disabled. >>> Java HotSpot(TM) Client VM warning: Try >>> increasing the code cache >>> size using -XX:ReservedCodeCacheSize= >>> CodeCache: size=2700Kb used=2196Kb >>> max_used=2196Kb free=503Kb >>> >>> With b111, I was only seeing one message. I >>> suspect with b111, once >>> this message appeared compilation was never >>> re-enabled so the >>> message never appeared again. In that case >>> seeing in many times now >>> is actually a good indicator. However, it >>> appears even when not >>> using -XX:+PrintCodeCache, and I can see >>> this output being a >>> distraction for programs whose normal >>> operation may involve >>> constraining the codecache and having it >>> constantly filling up. >>> Perhaps this message should be off by >>> default, or possibly only >>> appear once. >>> >>> You are right. The previous version just never >>> re-enabled >>> compilation. I also agree that the >>> output is distracting. There are multiple ways >>> to solve this issue. >>> I would go for a product -XX flag >>> which allows to turn this warning on/off. Would >>> that be ok or do you >>> have a different solution in mind? >>> >>> Best, >>> Albert >>> >>> cheers, >>> >>> Chris >>> >>> On 11/5/13 5:59 PM, Chris Plummer wrote: >>> >>> Hi Albert, >>> >>> I applied your patch and got some new >>> numbers. Performance is now >>> even better than it was with b110. See >>> the chart I added to the bug. >>> >>> Nice work! >>> >>> Chris >>> >>> On 11/5/13 6:44 AM, Albert Noll wrote: >>> >>> Hi, >>> >>> could I get reviews for this small >>> patch? >>> >>> bug: https://bugs.openjdk.java.net/ >>> browse/JDK-8027593 >>> webrev: http://cr.openjdk.java.net/~ >>> anoll/8027593/webrev.00/ >>> >> 7Eanoll/8027593/webrev.00/> >>> >>> >>> Problem: The implementation of the >>> sweeper (8020151) causes a >>> performance regression for small >>> code cache sizes. There are two >>> issues that cause this regression: >>> 1) NmethodSweepFraction is only >>> adjusted according to the >>> ReservedCodecacheSize if >>> TieredCompilation is enabled. As a >>> result, NmethodSweepFraction remains >>> 16 (if TieredCompilation is >>> not used). This is way too large for >>> small code cache sizes >>> (e.g., <5m). >>> 2) _request_mark_phase (sweeper.cpp) >>> is initialized to false. As >>> a result, mark_active_nmethods() did >>> not set _invocations and >>> _current, which results in not >>> invoking the sweeper (calling >>> sweep_code_cache()) at all. When >>> TieredCompilation is enabled >>> this was not an issue, since >>> NmethodSweeper::notify() (which sets >>> _request_mark_phase) is called much >>> more frequently. >>> >>> Solution: 1) Move setting of >>> NmethodSweepFraction so that it is >>> always executed. >>> Solution: 2) Remove >>> need_marking_phase(), >>> request_nmethod_marking(), and >>> reset_nmetod_marking(). >>> I think that >>> these checks are not needed since >>> 8020151, since we do stack scanning >>> of >>> active nmethods >>> irrespective of the value of >>> what need_marking_phase() returns. >>> Since >>> the patch removes >>> need_marking_phase() >>> printing out the warning (line 327 in >>> sweeper.cpp) is >>> incorrect, i.e., we continue >>> to invoke the sweeper. I removed the >>> warning >>> and the >>> associated code. >>> >>> >>> Also, I think that we can either >>> remove -XX:MethodFlushing or >>> -XX:UseCodeCacheFlushing. Since >>> 8020151, one of them is redundant >>> and can be removed. I am not quite >>> sure if we should do that now >>> so it is not included in the patch. >>> >>> Testing >>> bug: https://bugs.openjdk.java.net/ >>> browse/JDK-8027593 also shows >>> a performance evaluation. >>> >>> Many thanks for looking at the patch. >>> Best, >>> Albert >>> >>> >>> >>> >>> >>> >>> >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131108/8d58eaae/attachment-0001.html From igor.veresov at oracle.com Fri Nov 8 14:44:51 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 8 Nov 2013 14:44:51 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527D03FD.2010104@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> Message-ID: <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> Hi Albert, I talked with Vladimir and we have a suggestion about the warning. How about we print it only the first time by default and every time if PrintCodeCache is set? The fact that it is printed even once should suggest the user that the code cache size is something that needs attention, and that the VM is already operating with the constraint code cache space. Thanks! igor On Nov 8, 2013, at 7:32 AM, Albert Noll wrote: > Hi Vladimir, > > thanks for looking at the patch. I hope that this version addresses all issues that > you brought up. Here is a high-level overview of the changes since the last version: > > * We keep track of code cache state changes that also happen outside the sweeper. > I re-installed notify, which is now called report_state_change() and is doing the job. > report_state_change() checks if enough state has changed and enables the sweeper > (it sets _should_sweep) to true. We reset _bytes_changed only once we have finished > a while sweep cycle. That seems to make sense to me. > > * I added code that prints out every 10th warning that the compiler has been disabled. > I also added a warning that compilation has been enabled again. I think if we print a message > that compilation has been disabled, we should also print a message (maybe not a warning) > that was enabled again. > > Here is the new webrev: > http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ > > Best, > Albert > > On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>> Nice work, Albert >>> >>> One concern is transition "alive -> not_entrant" is counted only when >>> the nmethod needs to be flushed because you removed in notify() in >>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from >>> other places. >>> I think _bytes_changed should be updated by NMethodSweeper::notify() so >>> don't remove it from nmethod.cpp. _bytes_changed should be reset when we >>> finished sweep instead of before each sweep. >> >> May be reset in both places actually. One to check that there were updates between sweeps and an other during sweep (as you do currently). >> >> Thanks, >> Vladimir >> >>> >>> Can you keep comments in code which initialize static variables (first >>> changes in sweeper.cpp)? >>> >>> Please narrow your main comment, chars 90 chars per line. >>> >>> What is the second place? (initialization should not be count): >>> >>> + // of the two places where should_sweep can be set to true. >>> >>> You need to clear state in the comment conditions when we sweep. Like >>> you did in the replay: >>> >>> (1) The code cache is getting full >>> (2) There are sufficient state changes in the last sweep. >>> (3) We have not been sweeping for 'some time' >>> >>> Split into 2 lines: >>> >>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - >>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>> >>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>> The previous mail contains an error. See inline. >>>> >>>> Albert >>>> >>>> >>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>> Here is the updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>> >>>>> Please see comments inline. >>>>> >>>>> >>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>> Good idea. >>>>>> >>>>>> -- John (on my iPhone) >>>>>> >>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>> wrote: >>>>>> >>>>>>> Looks good. It?s not related to the change, but could you please >>>>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>>>> for the case when the method is made not entrant and include hotness >>>>>>> and threshold values? >>>>>>> >>>>>>> igor >>>>> I also agree. I added the print. >>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>> wrote: >>>>>>> >>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I get reviews for this small patch? >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>> >>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>> are two issues that cause this regression: >>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>>> not used). This is way too large for small code cache >>>>>>>>> sizes (e.g., <5m). >>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>> called much more frequently. >>>>>>>>> >>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>>> always executed. >>>>>>>> Good. >>>>>>>> >>>>> The place where I moved the adaption of NmethodSweepFraction is not >>>>> good, since the >>>>> the code cache size is adapted later for tiered. The current version >>>>> should be fine. >>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>> I think that these checks are not needed since >>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>> active nmethods irrespective of the value of >>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>> the patch removes need_marking_phase() printing >>>>>>>>> out the warning (line 327 in >>>>>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>> and the associated code. >>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>> condition. We always want to reclaim space in codecache. >>>>> Done. >>>>>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>>>>> to make sure we did not miss live nmethods). But with your changes >>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>> frequently? Why to sweep if there were no nmethods state change and >>>>>>>> there is enough space in CodeCache. So I am not sure about removing >>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>> I agree. The current patch contains a more sophisticated logic to >>>>> determine when we call the >>>>> sweeper. The bottom line is that we do not invoke the sweeper only if: >>>> >>>> !!!!We DO INVOKE the sweeper only if: >>>>> (1) The code cache is getting full and/or >>>>> (2) There are sufficient state changes in the last sweep. >>>> !!!!!(3) We have not been sweeping for 'some time' >>>>> >>>>> The patch contains a detailed description + examples of the logic. I >>>>> tested the patch >>>>> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >>>>> code cache >>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>> octane). The measurements >>>>> indicate that with the current logic in place, we can reduce the >>>>> number of sweeps by 50% for >>>>> medium code cache sizes without increasing the maximum used code cache >>>>> size. The difference >>>>> is more or less not significant. >>>>> >>>>> Please let me know what you think about it. The main disadvantage I >>>>> see with this change is that >>>>> it makes reasoning about the sweeper harder than it was before. >>>>> >>>>> >>>>> >>>>> >>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>> corresponding code. >>>>>>>> >>>>>>>>> >>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>>>>> that now so it is not included in the patch. >>>>>>>> It is for separate change. >>>>>>>> >>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>> codecache sweeping because we loose performance since we go into >>>>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>>>> OFF? I think it is good candidate to go. >>>>>>>> >>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>> executed unconditionally. >>>>>>>> >>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>> >>>>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>>>> there to remove it in jdk9: >>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>> I'll file a new bug to remove the flag. I guess this change will most >>>>> likely only make it into 8uXX. >>>>>>>>> Testing >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>>>>> performance evaluation. >>>>>>>>> >>>>>>>>> Many thanks for looking at the patch. >>>>>>>>> Best, >>>>>>>>> Albert >>>>> >>>> > From vitalyd at gmail.com Fri Nov 8 16:08:11 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 8 Nov 2013 19:08:11 -0500 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <527D03FD.2010104@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> Message-ID: Hi Albert, Small and possibly useless suggestion, but, if you decide to keep printing warning message every X sweeps, maybe use a power of 2 interval rather than 10 (e.g. 16 is just as good probably)? That saves the possibly expensive % operation and can be turned into an & instead (I.e. counter & (INTERVAL - 1) == 0). Maybe overkill, so ignore this :). Thanks Sent from my phone On Nov 8, 2013 10:33 AM, "Albert Noll" wrote: > Hi Vladimir, > > thanks for looking at the patch. I hope that this version addresses all > issues that > you brought up. Here is a high-level overview of the changes since the > last version: > > * We keep track of code cache state changes that also happen outside the > sweeper. > I re-installed notify, which is now called report_state_change() and is > doing the job. > report_state_change() checks if enough state has changed and enables > the sweeper > (it sets _should_sweep) to true. We reset _bytes_changed only once we > have finished > a while sweep cycle. That seems to make sense to me. > > * I added code that prints out every 10th warning that the compiler has > been disabled. > I also added a warning that compilation has been enabled again. I think > if we print a message > that compilation has been disabled, we should also print a message > (maybe not a warning) > that was enabled again. > > Here is the new webrev: > http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ > > Best, > Albert > > On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: > >> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >> >>> Nice work, Albert >>> >>> One concern is transition "alive -> not_entrant" is counted only when >>> the nmethod needs to be flushed because you removed in notify() in >>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from >>> other places. >>> I think _bytes_changed should be updated by NMethodSweeper::notify() so >>> don't remove it from nmethod.cpp. _bytes_changed should be reset when we >>> finished sweep instead of before each sweep. >>> >> >> May be reset in both places actually. One to check that there were >> updates between sweeps and an other during sweep (as you do currently). >> >> Thanks, >> Vladimir >> >> >>> Can you keep comments in code which initialize static variables (first >>> changes in sweeper.cpp)? >>> >>> Please narrow your main comment, chars 90 chars per line. >>> >>> What is the second place? (initialization should not be count): >>> >>> + // of the two places where should_sweep can be set to true. >>> >>> You need to clear state in the comment conditions when we sweep. Like >>> you did in the replay: >>> >>> (1) The code cache is getting full >>> (2) There are sufficient state changes in the last sweep. >>> (3) We have not been sweeping for 'some time' >>> >>> Split into 2 lines: >>> >>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - >>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>> >>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/7/13 3:27 AM, Albert Noll wrote: >>> >>>> The previous mail contains an error. See inline. >>>> >>>> Albert >>>> >>>> >>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>> >>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>> Here is the updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>> >>>>> Please see comments inline. >>>>> >>>>> >>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>> >>>>>> Good idea. >>>>>> >>>>>> -- John (on my iPhone) >>>>>> >>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>> wrote: >>>>>> >>>>>> Looks good. It?s not related to the change, but could you please >>>>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>>>> for the case when the method is made not entrant and include hotness >>>>>>> and threshold values? >>>>>>> >>>>>>> igor >>>>>>> >>>>>> I also agree. I added the print. >>>>> >>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>> wrote: >>>>>>> >>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I get reviews for this small patch? >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>> >>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>> are two issues that cause this regression: >>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>>> not used). This is way too large for small code cache >>>>>>>>> sizes (e.g., <5m). >>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>> called much more frequently. >>>>>>>>> >>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>>> always executed. >>>>>>>>> >>>>>>>> Good. >>>>>>>> >>>>>>>> The place where I moved the adaption of NmethodSweepFraction is not >>>>> good, since the >>>>> the code cache size is adapted later for tiered. The current version >>>>> should be fine. >>>>> >>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>> I think that these checks are not needed since >>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>> active nmethods irrespective of the value of >>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>> the patch removes need_marking_phase() printing >>>>>>>>> out the warning (line 327 in >>>>>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>> and the associated code. >>>>>>>>> >>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>> condition. We always want to reclaim space in codecache. >>>>>>>> >>>>>>> Done. >>>>> >>>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>>>>> to make sure we did not miss live nmethods). But with your changes >>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>> frequently? Why to sweep if there were no nmethods state change and >>>>>>>> there is enough space in CodeCache. So I am not sure about removing >>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>>> >>>>>>> I agree. The current patch contains a more sophisticated logic to >>>>> determine when we call the >>>>> sweeper. The bottom line is that we do not invoke the sweeper only if: >>>>> >>>> >>>> !!!!We DO INVOKE the sweeper only if: >>>> >>>>> (1) The code cache is getting full and/or >>>>> (2) There are sufficient state changes in the last sweep. >>>>> >>>> !!!!!(3) We have not been sweeping for 'some time' >>>> >>>>> >>>>> The patch contains a detailed description + examples of the logic. I >>>>> tested the patch >>>>> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >>>>> code cache >>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>> octane). The measurements >>>>> indicate that with the current logic in place, we can reduce the >>>>> number of sweeps by 50% for >>>>> medium code cache sizes without increasing the maximum used code cache >>>>> size. The difference >>>>> is more or less not significant. >>>>> >>>>> Please let me know what you think about it. The main disadvantage I >>>>> see with this change is that >>>>> it makes reasoning about the sweeper harder than it was before. >>>>> >>>>> >>>>> >>>>> >>>>> The warning was useless so it is okay to remove it and >>>>>>>> corresponding code. >>>>>>>> >>>>>>>> >>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>>>>> that now so it is not included in the patch. >>>>>>>>> >>>>>>>> It is for separate change. >>>>>>>> >>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>> codecache sweeping because we loose performance since we go into >>>>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>>>> OFF? I think it is good candidate to go. >>>>>>>> >>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>> executed unconditionally. >>>>>>>> >>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>> >>>>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>>>> there to remove it in jdk9: >>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>> I'll file a new bug to remove the flag. I guess this change will most >>>>> likely only make it into 8uXX. >>>>> >>>>>> Testing >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>>>>> performance evaluation. >>>>>>>>> >>>>>>>>> Many thanks for looking at the patch. >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>> >>>>>>>> >>>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131108/16ed04f2/attachment-0001.html From david.r.chase at oracle.com Fri Nov 8 18:46:55 2013 From: david.r.chase at oracle.com (david.r.chase at oracle.com) Date: Sat, 09 Nov 2013 02:46:55 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 10 new changesets Message-ID: <20131109024715.626246249E@hg.openjdk.java.net> Changeset: ea79ab313e98 Author: mgerdin Date: 2013-10-30 15:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/hotspot/rev/4fe7815b04f5 Merge Changeset: c8fc12209830 Author: coleenp Date: 2013-10-31 14:11 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/hotspot/rev/f8b56489e455 Merge Changeset: 04df110c8655 Author: mgronlun Date: 2013-11-02 20:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/04df110c8655 Merge Changeset: 53662b2f1d68 Author: drchase Date: 2013-11-07 10:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/53662b2f1d68 Merge Changeset: 83c8f6f4ab09 Author: drchase Date: 2013-11-08 14:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/83c8f6f4ab09 Merge From vladimir.kozlov at oracle.com Sat Nov 9 11:20:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 09 Nov 2013 11:20:57 -0800 Subject: RFR (XS): 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get In-Reply-To: <525D80C3.5020604@oracle.com> References: <525D80C3.5020604@oracle.com> Message-ID: <527E8B19.3090303@oracle.com> http://cr.openjdk.java.net/~kvn/8024830/webrev/ https://bugs.openjdk.java.net/browse/JDK-8024830 C2 Register Allocator can use input argument's stack slots for spills but until RA we don't know what offset and alignment these slots have. The minimum provided alignment is 8 bytes (for Double and long values). For wide vectors it is not enough. When vector is spilled there (as in this bug) it may stomp over values on caller's stack which follow argument's slots. Exclude enough (vector's size - 1) last input argument's stack slots from vector's spilling masks to avoid it. The fix is the same for jdk7u and jdk8. Tested lucene tests, JPRT, jtreg, ctw. Thanks, Vladimir From igor.veresov at oracle.com Sat Nov 9 16:33:01 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Sat, 9 Nov 2013 16:33:01 -0800 Subject: RFR (XS): 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get In-Reply-To: <527E8B19.3090303@oracle.com> References: <525D80C3.5020604@oracle.com> <527E8B19.3090303@oracle.com> Message-ID: <74DE736D-8E22-455B-8158-AE783B650B64@oracle.com> Woot! Looks good. A typo: 510 // RA guarantee such alignment ... igor On Nov 9, 2013, at 11:20 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8024830/webrev/ > > https://bugs.openjdk.java.net/browse/JDK-8024830 > > C2 Register Allocator can use input argument's stack slots for spills but until RA we don't know what offset and alignment these slots have. The minimum provided alignment is 8 bytes (for Double and long values). For wide vectors it is not enough. When vector is spilled there (as in this bug) it may stomp over values on caller's stack which follow argument's slots. > > Exclude enough (vector's size - 1) last input argument's stack slots from vector's spilling masks to avoid it. > > The fix is the same for jdk7u and jdk8. > > Tested lucene tests, JPRT, jtreg, ctw. > > Thanks, > Vladimir > > > > > > > > > > > > > > > > > > > > > > > > > > > From vladimir.kozlov at oracle.com Sat Nov 9 17:05:37 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 09 Nov 2013 17:05:37 -0800 Subject: RFR (XS): 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get In-Reply-To: <74DE736D-8E22-455B-8158-AE783B650B64@oracle.com> References: <525D80C3.5020604@oracle.com> <527E8B19.3090303@oracle.com> <74DE736D-8E22-455B-8158-AE783B650B64@oracle.com> Message-ID: <527EDBE1.5040505@oracle.com> Thank you, Igor I will fix the comment. Vladimir On 11/9/13 4:33 PM, Igor Veresov wrote: > Woot! Looks good. > > A typo: > > 510 // RA guarantee such alignment ... > > igor > > On Nov 9, 2013, at 11:20 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8024830/webrev/ >> >> https://bugs.openjdk.java.net/browse/JDK-8024830 >> >> C2 Register Allocator can use input argument's stack slots for spills but until RA we don't know what offset and alignment these slots have. The minimum provided alignment is 8 bytes (for Double and long values). For wide vectors it is not enough. When vector is spilled there (as in this bug) it may stomp over values on caller's stack which follow argument's slots. >> >> Exclude enough (vector's size - 1) last input argument's stack slots from vector's spilling masks to avoid it. >> >> The fix is the same for jdk7u and jdk8. >> >> Tested lucene tests, JPRT, jtreg, ctw. >> >> Thanks, >> Vladimir >> >> >> > From dawid.weiss at gmail.com Sun Nov 10 08:54:17 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Sun, 10 Nov 2013 17:54:17 +0100 Subject: RFR (XS): 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get In-Reply-To: <527EDBE1.5040505@oracle.com> References: <525D80C3.5020604@oracle.com> <527E8B19.3090303@oracle.com> <74DE736D-8E22-455B-8158-AE783B650B64@oracle.com> <527EDBE1.5040505@oracle.com> Message-ID: I confirm that this patch fixes the problem encountered in LUCENE-5212. I've tested svn rev. 1523179 (trunk) against jdk8-b114 with and without Vladimir's patch. Without the patch the test sequence ends about 50% of the time in a sigsegv. With the patch all executions ended without any errors. I have no idea how you tracked this down, Vladimir, but I enthusiastically share your "Huraaa!" [1] :) Dawid [1] https://bugs.openjdk.java.net/browse/JDK-8024830?focusedCommentId=13426080#comment-13426080 On Sun, Nov 10, 2013 at 2:05 AM, Vladimir Kozlov wrote: > Thank you, Igor > > I will fix the comment. > > Vladimir > > > On 11/9/13 4:33 PM, Igor Veresov wrote: >> >> Woot! Looks good. >> >> A typo: >> >> 510 // RA guarantee such alignment ... >> >> igor >> >> On Nov 9, 2013, at 11:20 AM, Vladimir Kozlov >> wrote: >> >>> http://cr.openjdk.java.net/~kvn/8024830/webrev/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8024830 >>> >>> C2 Register Allocator can use input argument's stack slots for spills but >>> until RA we don't know what offset and alignment these slots have. The >>> minimum provided alignment is 8 bytes (for Double and long values). For wide >>> vectors it is not enough. When vector is spilled there (as in this bug) it >>> may stomp over values on caller's stack which follow argument's slots. >>> >>> Exclude enough (vector's size - 1) last input argument's stack slots from >>> vector's spilling masks to avoid it. >>> >>> The fix is the same for jdk7u and jdk8. >>> >>> Tested lucene tests, JPRT, jtreg, ctw. >>> >>> Thanks, >>> Vladimir >>> >>> >>> >> > From vladimir.kozlov at oracle.com Sun Nov 10 11:14:21 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 10 Nov 2013 11:14:21 -0800 Subject: RFR (XS): 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get In-Reply-To: References: <525D80C3.5020604@oracle.com> <527E8B19.3090303@oracle.com> <74DE736D-8E22-455B-8158-AE783B650B64@oracle.com> <527EDBE1.5040505@oracle.com> Message-ID: <527FDB0D.20200@oracle.com> Thank you, Dawid, for confirmation and for your help with running lucene tests. Regards, Vladimir On 11/10/13 8:54 AM, Dawid Weiss wrote: > I confirm that this patch fixes the problem encountered in > LUCENE-5212. I've tested svn rev. 1523179 (trunk) against jdk8-b114 > with and without Vladimir's patch. Without the patch the test sequence > ends about 50% of the time in a sigsegv. With the patch all executions > ended without any errors. > > I have no idea how you tracked this down, Vladimir, but I > enthusiastically share your "Huraaa!" [1] :) > > Dawid > > [1] https://bugs.openjdk.java.net/browse/JDK-8024830?focusedCommentId=13426080#comment-13426080 > > On Sun, Nov 10, 2013 at 2:05 AM, Vladimir Kozlov > wrote: >> Thank you, Igor >> >> I will fix the comment. >> >> Vladimir >> >> >> On 11/9/13 4:33 PM, Igor Veresov wrote: >>> >>> Woot! Looks good. >>> >>> A typo: >>> >>> 510 // RA guarantee such alignment ... >>> >>> igor >>> >>> On Nov 9, 2013, at 11:20 AM, Vladimir Kozlov >>> wrote: >>> >>>> http://cr.openjdk.java.net/~kvn/8024830/webrev/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8024830 >>>> >>>> C2 Register Allocator can use input argument's stack slots for spills but >>>> until RA we don't know what offset and alignment these slots have. The >>>> minimum provided alignment is 8 bytes (for Double and long values). For wide >>>> vectors it is not enough. When vector is spilled there (as in this bug) it >>>> may stomp over values on caller's stack which follow argument's slots. >>>> >>>> Exclude enough (vector's size - 1) last input argument's stack slots from >>>> vector's spilling masks to avoid it. >>>> >>>> The fix is the same for jdk7u and jdk8. >>>> >>>> Tested lucene tests, JPRT, jtreg, ctw. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> >>> >> From albert.noll at oracle.com Sun Nov 10 23:38:36 2013 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 11 Nov 2013 08:38:36 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> Message-ID: <5280897C.7000107@oracle.com> Hi Igor, thanks for looking into this. My only concern with printing the warning under -XX:+PrintCodeCache is that we change existing behavior of PrintCodeCache. If this is not an issue, I am fine with it. I think that the cleanest solution is to introduce a new product flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default that value to true. I would set the default value to true, since the code cache is not expected to become full with default code cache sizes. If the code cache becomes full nevertheless or the user sets a small code cache size we could print a warning like this: > Compiler was disabled because there is insufficient contiguous free space in the code cache. > Free space: 2k requested size: 4k > Try to increase code cache with -XX:ReservedCodeCacheSize= or try to increase code cache > sweeper activity with -XX:NmethodSweepActivity= (default value is 10). > Disable this warning with: -XX:-PrintFullCodeCacheWarnings I would not print all the information that we print right now, because I think it is too detailed. E.g., I am not sure if it is helpful to print the bounds if the code cache. Also, I think we should substract CodeCacheMinimumFreeSpace from unallocated_capacity. It is confusing that we run out of code cache (and disable compilation) although there is still 500k left. Please let me know what you think. Best, Albert On 11/08/2013 11:44 PM, Igor Veresov wrote: > Hi Albert, > > I talked with Vladimir and we have a suggestion about the warning. How about we print it only the first time by default and every time if PrintCodeCache is set? The fact that it is printed even once should suggest the user that the code cache size is something that needs attention, and that the VM is already operating with the constraint code cache space. > > Thanks! > igor > > On Nov 8, 2013, at 7:32 AM, Albert Noll wrote: > >> Hi Vladimir, >> >> thanks for looking at the patch. I hope that this version addresses all issues that >> you brought up. Here is a high-level overview of the changes since the last version: >> >> * We keep track of code cache state changes that also happen outside the sweeper. >> I re-installed notify, which is now called report_state_change() and is doing the job. >> report_state_change() checks if enough state has changed and enables the sweeper >> (it sets _should_sweep) to true. We reset _bytes_changed only once we have finished >> a while sweep cycle. That seems to make sense to me. >> >> * I added code that prints out every 10th warning that the compiler has been disabled. >> I also added a warning that compilation has been enabled again. I think if we print a message >> that compilation has been disabled, we should also print a message (maybe not a warning) >> that was enabled again. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >> >> Best, >> Albert >> >> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>> Nice work, Albert >>>> >>>> One concern is transition "alive -> not_entrant" is counted only when >>>> the nmethod needs to be flushed because you removed in notify() in >>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from >>>> other places. >>>> I think _bytes_changed should be updated by NMethodSweeper::notify() so >>>> don't remove it from nmethod.cpp. _bytes_changed should be reset when we >>>> finished sweep instead of before each sweep. >>> May be reset in both places actually. One to check that there were updates between sweeps and an other during sweep (as you do currently). >>> >>> Thanks, >>> Vladimir >>> >>>> Can you keep comments in code which initialize static variables (first >>>> changes in sweeper.cpp)? >>>> >>>> Please narrow your main comment, chars 90 chars per line. >>>> >>>> What is the second place? (initialization should not be count): >>>> >>>> + // of the two places where should_sweep can be set to true. >>>> >>>> You need to clear state in the comment conditions when we sweep. Like >>>> you did in the replay: >>>> >>>> (1) The code cache is getting full >>>> (2) There are sufficient state changes in the last sweep. >>>> (3) We have not been sweeping for 'some time' >>>> >>>> Split into 2 lines: >>>> >>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - >>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>> >>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>> The previous mail contains an error. See inline. >>>>> >>>>> Albert >>>>> >>>>> >>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>> Here is the updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>> >>>>>> Please see comments inline. >>>>>> >>>>>> >>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>> Good idea. >>>>>>> >>>>>>> -- John (on my iPhone) >>>>>>> >>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>> wrote: >>>>>>> >>>>>>>> Looks good. It?s not related to the change, but could you please >>>>>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>>>>> for the case when the method is made not entrant and include hotness >>>>>>>> and threshold values? >>>>>>>> >>>>>>>> igor >>>>>> I also agree. I added the print. >>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>> >>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>> are two issues that cause this regression: >>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>> called much more frequently. >>>>>>>>>> >>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>>>> always executed. >>>>>>>>> Good. >>>>>>>>> >>>>>> The place where I moved the adaption of NmethodSweepFraction is not >>>>>> good, since the >>>>>> the code cache size is adapted later for tiered. The current version >>>>>> should be fine. >>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>> I think that these checks are not needed since >>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>> active nmethods irrespective of the value of >>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>> the patch removes need_marking_phase() printing >>>>>>>>>> out the warning (line 327 in >>>>>>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>> and the associated code. >>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>> Done. >>>>>>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>>>>>> to make sure we did not miss live nmethods). But with your changes >>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>> frequently? Why to sweep if there were no nmethods state change and >>>>>>>>> there is enough space in CodeCache. So I am not sure about removing >>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>> determine when we call the >>>>>> sweeper. The bottom line is that we do not invoke the sweeper only if: >>>>> !!!!We DO INVOKE the sweeper only if: >>>>>> (1) The code cache is getting full and/or >>>>>> (2) There are sufficient state changes in the last sweep. >>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>> The patch contains a detailed description + examples of the logic. I >>>>>> tested the patch >>>>>> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >>>>>> code cache >>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>> octane). The measurements >>>>>> indicate that with the current logic in place, we can reduce the >>>>>> number of sweeps by 50% for >>>>>> medium code cache sizes without increasing the maximum used code cache >>>>>> size. The difference >>>>>> is more or less not significant. >>>>>> >>>>>> Please let me know what you think about it. The main disadvantage I >>>>>> see with this change is that >>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>> corresponding code. >>>>>>>>> >>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>>>>>> that now so it is not included in the patch. >>>>>>>>> It is for separate change. >>>>>>>>> >>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>> codecache sweeping because we loose performance since we go into >>>>>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>> >>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>> executed unconditionally. >>>>>>>>> >>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>> >>>>>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>>>>> there to remove it in jdk9: >>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>> I'll file a new bug to remove the flag. I guess this change will most >>>>>> likely only make it into 8uXX. >>>>>>>>>> Testing >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>>>>>> performance evaluation. >>>>>>>>>> >>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>> Best, >>>>>>>>>> Albert From igor.veresov at oracle.com Mon Nov 11 00:39:08 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 11 Nov 2013 00:39:08 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <5280897C.7000107@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> <5280897C.7000107@oracle.com> Message-ID: <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> On Nov 10, 2013, at 11:38 PM, Albert Noll wrote: > Hi Igor, > > thanks for looking into this. My only concern with printing the warning under -XX:+PrintCodeCache is > that we change existing behavior of PrintCodeCache. If this is not an issue, I am fine with it. > > I think that the cleanest solution is to introduce a new product flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default that value to true. I would set the default value to true, > since the code cache is not expected to become full with default code cache sizes. If the code cache > becomes full nevertheless or the user sets a small code cache size we could print a warning like this: > > > Compiler was disabled because there is insufficient contiguous free space in the code cache. > > Free space: 2k requested size: 4k > > Try to increase code cache with -XX:ReservedCodeCacheSize= or try to increase code cache > > sweeper activity with -XX:NmethodSweepActivity= (default value is 10). > > Disable this warning with: -XX:-PrintFullCodeCacheWarnings > Hi Albert, Thanks for giving it a thought. My only concern with the previous solution was printing the warning repeatedly every 10th time. I think one time is enough to convey the message: "bump the size or you?re loosing on performance?. Printing the warning repeatedly doesn?t really provide any useful information because there is not much context. It becomes useful when the user sees all the state transitions: when the compilers were disabled and why, how much methods were flushed and, as a result, how much space was freed, when the compilers where re-enabled, what sweeping activity was there, etc. May be this can be printed under PrintMethodFlushing without Verbose? It would be also nice to have timestamps. People doing performance analysis will really appreciate that. See PrintGCDetails and PrintGCTimeStamps. May be there should be an option to disable with warning altogether (so that it?s not printed even the first time) for cases when the code cache size is constrained on purpose. Most of this is probably for another change. TL;DR: may be print the warning once. > I would not print all the information that we print right now, because I think it is too detailed. > E.g., I am not sure if it is helpful to print the bounds if the code cache. Also, I think we should > substract CodeCacheMinimumFreeSpace from unallocated_capacity. It is confusing that we > run out of code cache (and disable compilation) although there is still 500k left. I agree, it is confusing. igor > > Please let me know what you think. > > Best, > Albert > > > On 11/08/2013 11:44 PM, Igor Veresov wrote: >> Hi Albert, >> >> I talked with Vladimir and we have a suggestion about the warning. How about we print it only the first time by default and every time if PrintCodeCache is set? The fact that it is printed even once should suggest the user that the code cache size is something that needs attention, and that the VM is already operating with the constraint code cache space. >> >> Thanks! >> igor >> >> On Nov 8, 2013, at 7:32 AM, Albert Noll wrote: >> >>> Hi Vladimir, >>> >>> thanks for looking at the patch. I hope that this version addresses all issues that >>> you brought up. Here is a high-level overview of the changes since the last version: >>> >>> * We keep track of code cache state changes that also happen outside the sweeper. >>> I re-installed notify, which is now called report_state_change() and is doing the job. >>> report_state_change() checks if enough state has changed and enables the sweeper >>> (it sets _should_sweep) to true. We reset _bytes_changed only once we have finished >>> a while sweep cycle. That seems to make sense to me. >>> >>> * I added code that prints out every 10th warning that the compiler has been disabled. >>> I also added a warning that compilation has been enabled again. I think if we print a message >>> that compilation has been disabled, we should also print a message (maybe not a warning) >>> that was enabled again. >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >>> >>> Best, >>> Albert >>> >>> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>>> Nice work, Albert >>>>> >>>>> One concern is transition "alive -> not_entrant" is counted only when >>>>> the nmethod needs to be flushed because you removed in notify() in >>>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from >>>>> other places. >>>>> I think _bytes_changed should be updated by NMethodSweeper::notify() so >>>>> don't remove it from nmethod.cpp. _bytes_changed should be reset when we >>>>> finished sweep instead of before each sweep. >>>> May be reset in both places actually. One to check that there were updates between sweeps and an other during sweep (as you do currently). >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> Can you keep comments in code which initialize static variables (first >>>>> changes in sweeper.cpp)? >>>>> >>>>> Please narrow your main comment, chars 90 chars per line. >>>>> >>>>> What is the second place? (initialization should not be count): >>>>> >>>>> + // of the two places where should_sweep can be set to true. >>>>> >>>>> You need to clear state in the comment conditions when we sweep. Like >>>>> you did in the replay: >>>>> >>>>> (1) The code cache is getting full >>>>> (2) There are sufficient state changes in the last sweep. >>>>> (3) We have not been sweeping for 'some time' >>>>> >>>>> Split into 2 lines: >>>>> >>>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - >>>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>>> >>>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>>> The previous mail contains an error. See inline. >>>>>> >>>>>> Albert >>>>>> >>>>>> >>>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>>> Here is the updated webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>>> >>>>>>> Please see comments inline. >>>>>>> >>>>>>> >>>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>>> Good idea. >>>>>>>> >>>>>>>> -- John (on my iPhone) >>>>>>>> >>>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Looks good. It?s not related to the change, but could you please >>>>>>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>>>>>> for the case when the method is made not entrant and include hotness >>>>>>>>> and threshold values? >>>>>>>>> >>>>>>>>> igor >>>>>>> I also agree. I added the print. >>>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>>> are two issues that cause this regression: >>>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>>> called much more frequently. >>>>>>>>>>> >>>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>>>>> always executed. >>>>>>>>>> Good. >>>>>>>>>> >>>>>>> The place where I moved the adaption of NmethodSweepFraction is not >>>>>>> good, since the >>>>>>> the code cache size is adapted later for tiered. The current version >>>>>>> should be fine. >>>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>>> I think that these checks are not needed since >>>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>>> active nmethods irrespective of the value of >>>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>>> the patch removes need_marking_phase() printing >>>>>>>>>>> out the warning (line 327 in >>>>>>>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>>> and the associated code. >>>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>>> Done. >>>>>>>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>>>>>>> to make sure we did not miss live nmethods). But with your changes >>>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>>> frequently? Why to sweep if there were no nmethods state change and >>>>>>>>>> there is enough space in CodeCache. So I am not sure about removing >>>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>>> determine when we call the >>>>>>> sweeper. The bottom line is that we do not invoke the sweeper only if: >>>>>> !!!!We DO INVOKE the sweeper only if: >>>>>>> (1) The code cache is getting full and/or >>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>>> The patch contains a detailed description + examples of the logic. I >>>>>>> tested the patch >>>>>>> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >>>>>>> code cache >>>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>>> octane). The measurements >>>>>>> indicate that with the current logic in place, we can reduce the >>>>>>> number of sweeps by 50% for >>>>>>> medium code cache sizes without increasing the maximum used code cache >>>>>>> size. The difference >>>>>>> is more or less not significant. >>>>>>> >>>>>>> Please let me know what you think about it. The main disadvantage I >>>>>>> see with this change is that >>>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>>> corresponding code. >>>>>>>>>> >>>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>>>>>>> that now so it is not included in the patch. >>>>>>>>>> It is for separate change. >>>>>>>>>> >>>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>>> codecache sweeping because we loose performance since we go into >>>>>>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>>> >>>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>>>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>>> executed unconditionally. >>>>>>>>>> >>>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>>> >>>>>>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>>>>>> there to remove it in jdk9: >>>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>> I'll file a new bug to remove the flag. I guess this change will most >>>>>>> likely only make it into 8uXX. >>>>>>>>>>> Testing >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>>>>>>> performance evaluation. >>>>>>>>>>> >>>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>>> Best, >>>>>>>>>>> Albert > From albert.noll at oracle.com Mon Nov 11 08:00:52 2013 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 11 Nov 2013 17:00:52 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> <5280897C.7000107@oracle.com> <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> Message-ID: <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> Hi Igor, Thanks for your input. I agree with you. Let me summarize what is being printed, just to make sure I get it right: Default behavior: Print warning once -XX:+PrintMethodFlushing: Print details (as listend above) with time stamps. Add option to remove all output. Is that correct? Best, Albert Von meinem iPhone gesendet > Am 11.11.2013 um 09:39 schrieb Igor Veresov : > > >> On Nov 10, 2013, at 11:38 PM, Albert Noll wrote: >> >> Hi Igor, >> >> thanks for looking into this. My only concern with printing the warning under -XX:+PrintCodeCache is >> that we change existing behavior of PrintCodeCache. If this is not an issue, I am fine with it. >> >> I think that the cleanest solution is to introduce a new product flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default that value to true. I would set the default value to true, >> since the code cache is not expected to become full with default code cache sizes. If the code cache >> becomes full nevertheless or the user sets a small code cache size we could print a warning like this: >> >>> Compiler was disabled because there is insufficient contiguous free space in the code cache. >>> Free space: 2k requested size: 4k >>> Try to increase code cache with -XX:ReservedCodeCacheSize= or try to increase code cache >>> sweeper activity with -XX:NmethodSweepActivity= (default value is 10). >>> Disable this warning with: -XX:-PrintFullCodeCacheWarnings > > Hi Albert, > > Thanks for giving it a thought. My only concern with the previous solution was printing the warning repeatedly every 10th time. I think one time is enough to convey the message: "bump the size or you?re loosing on performance?. Printing the warning repeatedly doesn?t really provide any useful information because there is not much context. It becomes useful when the user sees all the state transitions: when the compilers were disabled and why, how much methods were flushed and, as a result, how much space was freed, when the compilers where re-enabled, what sweeping activity was there, etc. May be this can be printed under PrintMethodFlushing without Verbose? It would be also nice to have timestamps. People doing performance analysis will really appreciate that. See PrintGCDetails and PrintGCTimeStamps. May be there should be an option to disable with warning altogether (so that it?s not printed even the first time) for cases when the code cache size is constrained on purpose. Most of this is probably for another change. > > TL;DR: may be print the warning once. > >> I would not print all the information that we print right now, because I think it is too detailed. >> E.g., I am not sure if it is helpful to print the bounds if the code cache. Also, I think we should >> substract CodeCacheMinimumFreeSpace from unallocated_capacity. It is confusing that we >> run out of code cache (and disable compilation) although there is still 500k left. > > I agree, it is confusing. > > igor > >> >> Please let me know what you think. >> >> Best, >> Albert >> >> >>> On 11/08/2013 11:44 PM, Igor Veresov wrote: >>> Hi Albert, >>> >>> I talked with Vladimir and we have a suggestion about the warning. How about we print it only the first time by default and every time if PrintCodeCache is set? The fact that it is printed even once should suggest the user that the code cache size is something that needs attention, and that the VM is already operating with the constraint code cache space. >>> >>> Thanks! >>> igor >>> >>>> On Nov 8, 2013, at 7:32 AM, Albert Noll wrote: >>>> >>>> Hi Vladimir, >>>> >>>> thanks for looking at the patch. I hope that this version addresses all issues that >>>> you brought up. Here is a high-level overview of the changes since the last version: >>>> >>>> * We keep track of code cache state changes that also happen outside the sweeper. >>>> I re-installed notify, which is now called report_state_change() and is doing the job. >>>> report_state_change() checks if enough state has changed and enables the sweeper >>>> (it sets _should_sweep) to true. We reset _bytes_changed only once we have finished >>>> a while sweep cycle. That seems to make sense to me. >>>> >>>> * I added code that prints out every 10th warning that the compiler has been disabled. >>>> I also added a warning that compilation has been enabled again. I think if we print a message >>>> that compilation has been disabled, we should also print a message (maybe not a warning) >>>> that was enabled again. >>>> >>>> Here is the new webrev: >>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >>>> >>>> Best, >>>> Albert >>>> >>>>> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>>>>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>>>> Nice work, Albert >>>>>> >>>>>> One concern is transition "alive -> not_entrant" is counted only when >>>>>> the nmethod needs to be flushed because you removed in notify() in >>>>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from >>>>>> other places. >>>>>> I think _bytes_changed should be updated by NMethodSweeper::notify() so >>>>>> don't remove it from nmethod.cpp. _bytes_changed should be reset when we >>>>>> finished sweep instead of before each sweep. >>>>> May be reset in both places actually. One to check that there were updates between sweeps and an other during sweep (as you do currently). >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> Can you keep comments in code which initialize static variables (first >>>>>> changes in sweeper.cpp)? >>>>>> >>>>>> Please narrow your main comment, chars 90 chars per line. >>>>>> >>>>>> What is the second place? (initialization should not be count): >>>>>> >>>>>> + // of the two places where should_sweep can be set to true. >>>>>> >>>>>> You need to clear state in the comment conditions when we sweep. Like >>>>>> you did in the replay: >>>>>> >>>>>> (1) The code cache is getting full >>>>>> (2) There are sufficient state changes in the last sweep. >>>>>> (3) We have not been sweeping for 'some time' >>>>>> >>>>>> Split into 2 lines: >>>>>> >>>>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - >>>>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>>>> >>>>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>>>> The previous mail contains an error. See inline. >>>>>>> >>>>>>> Albert >>>>>>> >>>>>>> >>>>>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>>>> Here is the updated webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>>>> >>>>>>>> Please see comments inline. >>>>>>>> >>>>>>>> >>>>>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>>>> Good idea. >>>>>>>>> >>>>>>>>> -- John (on my iPhone) >>>>>>>>> >>>>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Looks good. It?s not related to the change, but could you please >>>>>>>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>>>>>>> for the case when the method is made not entrant and include hotness >>>>>>>>>> and threshold values? >>>>>>>>>> >>>>>>>>>> igor >>>>>>>> I also agree. I added the print. >>>>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>>>> are two issues that cause this regression: >>>>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>>>> called much more frequently. >>>>>>>>>>>> >>>>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>>>>>> always executed. >>>>>>>>>>> Good. >>>>>>>> The place where I moved the adaption of NmethodSweepFraction is not >>>>>>>> good, since the >>>>>>>> the code cache size is adapted later for tiered. The current version >>>>>>>> should be fine. >>>>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>>>> I think that these checks are not needed since >>>>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>>>> active nmethods irrespective of the value of >>>>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>>>> the patch removes need_marking_phase() printing >>>>>>>>>>>> out the warning (line 327 in >>>>>>>>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>>>> and the associated code. >>>>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>>>> Done. >>>>>>>>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>>>>>>>> to make sure we did not miss live nmethods). But with your changes >>>>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>>>> frequently? Why to sweep if there were no nmethods state change and >>>>>>>>>>> there is enough space in CodeCache. So I am not sure about removing >>>>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>>>> determine when we call the >>>>>>>> sweeper. The bottom line is that we do not invoke the sweeper only if: >>>>>>> !!!!We DO INVOKE the sweeper only if: >>>>>>>> (1) The code cache is getting full and/or >>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>>>> The patch contains a detailed description + examples of the logic. I >>>>>>>> tested the patch >>>>>>>> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >>>>>>>> code cache >>>>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>>>> octane). The measurements >>>>>>>> indicate that with the current logic in place, we can reduce the >>>>>>>> number of sweeps by 50% for >>>>>>>> medium code cache sizes without increasing the maximum used code cache >>>>>>>> size. The difference >>>>>>>> is more or less not significant. >>>>>>>> >>>>>>>> Please let me know what you think about it. The main disadvantage I >>>>>>>> see with this change is that >>>>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>>>> corresponding code. >>>>>>>>>>> >>>>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>>>>>>>> that now so it is not included in the patch. >>>>>>>>>>> It is for separate change. >>>>>>>>>>> >>>>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>>>> codecache sweeping because we loose performance since we go into >>>>>>>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>>>> >>>>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>>>>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>>>> executed unconditionally. >>>>>>>>>>> >>>>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>>>> >>>>>>>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>>>>>>> there to remove it in jdk9: >>>>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>> I'll file a new bug to remove the flag. I guess this change will most >>>>>>>> likely only make it into 8uXX. >>>>>>>>>>>> Testing >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>>>>>>>> performance evaluation. >>>>>>>>>>>> >>>>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>>>> Best, >>>>>>>>>>>> Albert > From igor.veresov at oracle.com Mon Nov 11 10:36:23 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 11 Nov 2013 10:36:23 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> <5280897C.7000107@oracle.com> <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> Message-ID: On Nov 11, 2013, at 8:00 AM, Albert Noll wrote: > Hi Igor, > > Thanks for your input. I agree with you. Let me summarize what is being printed, just to make sure I get it right: > > Default behavior: Print warning once > > -XX:+PrintMethodFlushing: Print details (as listend above) with time stamps. > > Add option to remove all output. > > Is that correct? Yup, sounds correct. Thanks! igor > > Best, > Albert > > Von meinem iPhone gesendet > >> Am 11.11.2013 um 09:39 schrieb Igor Veresov : >> >> >>> On Nov 10, 2013, at 11:38 PM, Albert Noll wrote: >>> >>> Hi Igor, >>> >>> thanks for looking into this. My only concern with printing the warning under -XX:+PrintCodeCache is >>> that we change existing behavior of PrintCodeCache. If this is not an issue, I am fine with it. >>> >>> I think that the cleanest solution is to introduce a new product flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default that value to true. I would set the default value to true, >>> since the code cache is not expected to become full with default code cache sizes. If the code cache >>> becomes full nevertheless or the user sets a small code cache size we could print a warning like this: >>> >>>> Compiler was disabled because there is insufficient contiguous free space in the code cache. >>>> Free space: 2k requested size: 4k >>>> Try to increase code cache with -XX:ReservedCodeCacheSize= or try to increase code cache >>>> sweeper activity with -XX:NmethodSweepActivity= (default value is 10). >>>> Disable this warning with: -XX:-PrintFullCodeCacheWarnings >> >> Hi Albert, >> >> Thanks for giving it a thought. My only concern with the previous solution was printing the warning repeatedly every 10th time. I think one time is enough to convey the message: "bump the size or you?re loosing on performance?. Printing the warning repeatedly doesn?t really provide any useful information because there is not much context. It becomes useful when the user sees all the state transitions: when the compilers were disabled and why, how much methods were flushed and, as a result, how much space was freed, when the compilers where re-enabled, what sweeping activity was there, etc. May be this can be printed under PrintMethodFlushing without Verbose? It would be also nice to have timestamps. People doing performance analysis will really appreciate that. See PrintGCDetails and PrintGCTimeStamps. May be there should be an option to disable with warning altogether (so that it?s not printed even the first time) for cases when the code cache size is constrained on purpose. Most of this is probably for another change. >> >> TL;DR: may be print the warning once. >> >>> I would not print all the information that we print right now, because I think it is too detailed. >>> E.g., I am not sure if it is helpful to print the bounds if the code cache. Also, I think we should >>> substract CodeCacheMinimumFreeSpace from unallocated_capacity. It is confusing that we >>> run out of code cache (and disable compilation) although there is still 500k left. >> >> I agree, it is confusing. >> >> igor >> >>> >>> Please let me know what you think. >>> >>> Best, >>> Albert >>> >>> >>>> On 11/08/2013 11:44 PM, Igor Veresov wrote: >>>> Hi Albert, >>>> >>>> I talked with Vladimir and we have a suggestion about the warning. How about we print it only the first time by default and every time if PrintCodeCache is set? The fact that it is printed even once should suggest the user that the code cache size is something that needs attention, and that the VM is already operating with the constraint code cache space. >>>> >>>> Thanks! >>>> igor >>>> >>>>> On Nov 8, 2013, at 7:32 AM, Albert Noll wrote: >>>>> >>>>> Hi Vladimir, >>>>> >>>>> thanks for looking at the patch. I hope that this version addresses all issues that >>>>> you brought up. Here is a high-level overview of the changes since the last version: >>>>> >>>>> * We keep track of code cache state changes that also happen outside the sweeper. >>>>> I re-installed notify, which is now called report_state_change() and is doing the job. >>>>> report_state_change() checks if enough state has changed and enables the sweeper >>>>> (it sets _should_sweep) to true. We reset _bytes_changed only once we have finished >>>>> a while sweep cycle. That seems to make sense to me. >>>>> >>>>> * I added code that prints out every 10th warning that the compiler has been disabled. >>>>> I also added a warning that compilation has been enabled again. I think if we print a message >>>>> that compilation has been disabled, we should also print a message (maybe not a warning) >>>>> that was enabled again. >>>>> >>>>> Here is the new webrev: >>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>>> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>>>>>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>>>>> Nice work, Albert >>>>>>> >>>>>>> One concern is transition "alive -> not_entrant" is counted only when >>>>>>> the nmethod needs to be flushed because you removed in notify() in >>>>>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from >>>>>>> other places. >>>>>>> I think _bytes_changed should be updated by NMethodSweeper::notify() so >>>>>>> don't remove it from nmethod.cpp. _bytes_changed should be reset when we >>>>>>> finished sweep instead of before each sweep. >>>>>> May be reset in both places actually. One to check that there were updates between sweeps and an other during sweep (as you do currently). >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> Can you keep comments in code which initialize static variables (first >>>>>>> changes in sweeper.cpp)? >>>>>>> >>>>>>> Please narrow your main comment, chars 90 chars per line. >>>>>>> >>>>>>> What is the second place? (initialization should not be count): >>>>>>> >>>>>>> + // of the two places where should_sweep can be set to true. >>>>>>> >>>>>>> You need to clear state in the comment conditions when we sweep. Like >>>>>>> you did in the replay: >>>>>>> >>>>>>> (1) The code cache is getting full >>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>> (3) We have not been sweeping for 'some time' >>>>>>> >>>>>>> Split into 2 lines: >>>>>>> >>>>>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - >>>>>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>>>>> >>>>>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>>>>> The previous mail contains an error. See inline. >>>>>>>> >>>>>>>> Albert >>>>>>>> >>>>>>>> >>>>>>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>>>>> Here is the updated webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>>>>> >>>>>>>>> Please see comments inline. >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>>>>> Good idea. >>>>>>>>>> >>>>>>>>>> -- John (on my iPhone) >>>>>>>>>> >>>>>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Looks good. It?s not related to the change, but could you please >>>>>>>>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>>>>>>>> for the case when the method is made not entrant and include hotness >>>>>>>>>>> and threshold values? >>>>>>>>>>> >>>>>>>>>>> igor >>>>>>>>> I also agree. I added the print. >>>>>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>>>>> are two issues that cause this regression: >>>>>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>>>>> called much more frequently. >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>>>>>>> always executed. >>>>>>>>>>>> Good. >>>>>>>>> The place where I moved the adaption of NmethodSweepFraction is not >>>>>>>>> good, since the >>>>>>>>> the code cache size is adapted later for tiered. The current version >>>>>>>>> should be fine. >>>>>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>>>>> I think that these checks are not needed since >>>>>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>>>>> active nmethods irrespective of the value of >>>>>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>>>>> the patch removes need_marking_phase() printing >>>>>>>>>>>>> out the warning (line 327 in >>>>>>>>>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>>>>> and the associated code. >>>>>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>>>>> Done. >>>>>>>>>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>>>>>>>>> to make sure we did not miss live nmethods). But with your changes >>>>>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>>>>> frequently? Why to sweep if there were no nmethods state change and >>>>>>>>>>>> there is enough space in CodeCache. So I am not sure about removing >>>>>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>>>>> determine when we call the >>>>>>>>> sweeper. The bottom line is that we do not invoke the sweeper only if: >>>>>>>> !!!!We DO INVOKE the sweeper only if: >>>>>>>>> (1) The code cache is getting full and/or >>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>>>>> The patch contains a detailed description + examples of the logic. I >>>>>>>>> tested the patch >>>>>>>>> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >>>>>>>>> code cache >>>>>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>>>>> octane). The measurements >>>>>>>>> indicate that with the current logic in place, we can reduce the >>>>>>>>> number of sweeps by 50% for >>>>>>>>> medium code cache sizes without increasing the maximum used code cache >>>>>>>>> size. The difference >>>>>>>>> is more or less not significant. >>>>>>>>> >>>>>>>>> Please let me know what you think about it. The main disadvantage I >>>>>>>>> see with this change is that >>>>>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>>>>> corresponding code. >>>>>>>>>>>> >>>>>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>>>>>>>>> that now so it is not included in the patch. >>>>>>>>>>>> It is for separate change. >>>>>>>>>>>> >>>>>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>>>>> codecache sweeping because we loose performance since we go into >>>>>>>>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>>>>> >>>>>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>>>>>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>>>>> executed unconditionally. >>>>>>>>>>>> >>>>>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>>>>> >>>>>>>>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>>>>>>>> there to remove it in jdk9: >>>>>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>> I'll file a new bug to remove the flag. I guess this change will most >>>>>>>>> likely only make it into 8uXX. >>>>>>>>>>>>> Testing >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>>>>>>>>> performance evaluation. >>>>>>>>>>>>> >>>>>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>>>>> Best, >>>>>>>>>>>>> Albert >> From chris.plummer at oracle.com Mon Nov 11 11:10:08 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 11 Nov 2013 11:10:08 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> <5280897C.7000107@oracle.com> <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> Message-ID: <52812B90.8060609@oracle.com> For users that that set ReservedCodeCacheSize to something lower than the default, you probably want the single warning message off by default, and otherwise want it on by default. Chris On 11/11/13 8:00 AM, Albert Noll wrote: > Hi Igor, > > Thanks for your input. I agree with you. Let me summarize what is being printed, just to make sure I get it right: > > Default behavior: Print warning once > > -XX:+PrintMethodFlushing: Print details (as listend above) with time stamps. > > Add option to remove all output. > > Is that correct? > > Best, > Albert > > Von meinem iPhone gesendet > >> Am 11.11.2013 um 09:39 schrieb Igor Veresov : >> >> >>> On Nov 10, 2013, at 11:38 PM, Albert Noll wrote: >>> >>> Hi Igor, >>> >>> thanks for looking into this. My only concern with printing the warning under -XX:+PrintCodeCache is >>> that we change existing behavior of PrintCodeCache. If this is not an issue, I am fine with it. >>> >>> I think that the cleanest solution is to introduce a new product flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default that value to true. I would set the default value to true, >>> since the code cache is not expected to become full with default code cache sizes. If the code cache >>> becomes full nevertheless or the user sets a small code cache size we could print a warning like this: >>> >>>> Compiler was disabled because there is insufficient contiguous free space in the code cache. >>>> Free space: 2k requested size: 4k >>>> Try to increase code cache with -XX:ReservedCodeCacheSize= or try to increase code cache >>>> sweeper activity with -XX:NmethodSweepActivity= (default value is 10). >>>> Disable this warning with: -XX:-PrintFullCodeCacheWarnings >> Hi Albert, >> >> Thanks for giving it a thought. My only concern with the previous solution was printing the warning repeatedly every 10th time. I think one time is enough to convey the message: "bump the size or you?re loosing on performance?. Printing the warning repeatedly doesn?t really provide any useful information because there is not much context. It becomes useful when the user sees all the state transitions: when the compilers were disabled and why, how much methods were flushed and, as a result, how much space was freed, when the compilers where re-enabled, what sweeping activity was there, etc. May be this can be printed under PrintMethodFlushing without Verbose? It would be also nice to have timestamps. People doing performance analysis will really appreciate that. See PrintGCDetails and PrintGCTimeStamps. May be there should be an option to disable with warning altogether (so that it?s not printed even the first time) for cases when the code cache size is constrained on purpose. Most of this is probably for another change. >> >> TL;DR: may be print the warning once. >> >>> I would not print all the information that we print right now, because I think it is too detailed. >>> E.g., I am not sure if it is helpful to print the bounds if the code cache. Also, I think we should >>> substract CodeCacheMinimumFreeSpace from unallocated_capacity. It is confusing that we >>> run out of code cache (and disable compilation) although there is still 500k left. >> I agree, it is confusing. >> >> igor >> >>> Please let me know what you think. >>> >>> Best, >>> Albert >>> >>> >>>> On 11/08/2013 11:44 PM, Igor Veresov wrote: >>>> Hi Albert, >>>> >>>> I talked with Vladimir and we have a suggestion about the warning. How about we print it only the first time by default and every time if PrintCodeCache is set? The fact that it is printed even once should suggest the user that the code cache size is something that needs attention, and that the VM is already operating with the constraint code cache space. >>>> >>>> Thanks! >>>> igor >>>> >>>>> On Nov 8, 2013, at 7:32 AM, Albert Noll wrote: >>>>> >>>>> Hi Vladimir, >>>>> >>>>> thanks for looking at the patch. I hope that this version addresses all issues that >>>>> you brought up. Here is a high-level overview of the changes since the last version: >>>>> >>>>> * We keep track of code cache state changes that also happen outside the sweeper. >>>>> I re-installed notify, which is now called report_state_change() and is doing the job. >>>>> report_state_change() checks if enough state has changed and enables the sweeper >>>>> (it sets _should_sweep) to true. We reset _bytes_changed only once we have finished >>>>> a while sweep cycle. That seems to make sense to me. >>>>> >>>>> * I added code that prints out every 10th warning that the compiler has been disabled. >>>>> I also added a warning that compilation has been enabled again. I think if we print a message >>>>> that compilation has been disabled, we should also print a message (maybe not a warning) >>>>> that was enabled again. >>>>> >>>>> Here is the new webrev: >>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>>> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>>>>>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>>>>> Nice work, Albert >>>>>>> >>>>>>> One concern is transition "alive -> not_entrant" is counted only when >>>>>>> the nmethod needs to be flushed because you removed in notify() in >>>>>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from >>>>>>> other places. >>>>>>> I think _bytes_changed should be updated by NMethodSweeper::notify() so >>>>>>> don't remove it from nmethod.cpp. _bytes_changed should be reset when we >>>>>>> finished sweep instead of before each sweep. >>>>>> May be reset in both places actually. One to check that there were updates between sweeps and an other during sweep (as you do currently). >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> Can you keep comments in code which initialize static variables (first >>>>>>> changes in sweeper.cpp)? >>>>>>> >>>>>>> Please narrow your main comment, chars 90 chars per line. >>>>>>> >>>>>>> What is the second place? (initialization should not be count): >>>>>>> >>>>>>> + // of the two places where should_sweep can be set to true. >>>>>>> >>>>>>> You need to clear state in the comment conditions when we sweep. Like >>>>>>> you did in the replay: >>>>>>> >>>>>>> (1) The code cache is getting full >>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>> (3) We have not been sweeping for 'some time' >>>>>>> >>>>>>> Split into 2 lines: >>>>>>> >>>>>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - >>>>>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>>>>> >>>>>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>>>>> The previous mail contains an error. See inline. >>>>>>>> >>>>>>>> Albert >>>>>>>> >>>>>>>> >>>>>>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>>>>> Here is the updated webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>>>>> >>>>>>>>> Please see comments inline. >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>>>>> Good idea. >>>>>>>>>> >>>>>>>>>> -- John (on my iPhone) >>>>>>>>>> >>>>>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Looks good. It?s not related to the change, but could you please >>>>>>>>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>>>>>>>> for the case when the method is made not entrant and include hotness >>>>>>>>>>> and threshold values? >>>>>>>>>>> >>>>>>>>>>> igor >>>>>>>>> I also agree. I added the print. >>>>>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>>>>> are two issues that cause this regression: >>>>>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>>>>> called much more frequently. >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>>>>>>> always executed. >>>>>>>>>>>> Good. >>>>>>>>> The place where I moved the adaption of NmethodSweepFraction is not >>>>>>>>> good, since the >>>>>>>>> the code cache size is adapted later for tiered. The current version >>>>>>>>> should be fine. >>>>>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>>>>> I think that these checks are not needed since >>>>>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>>>>> active nmethods irrespective of the value of >>>>>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>>>>> the patch removes need_marking_phase() printing >>>>>>>>>>>>> out the warning (line 327 in >>>>>>>>>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>>>>> and the associated code. >>>>>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>>>>> Done. >>>>>>>>>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>>>>>>>>> to make sure we did not miss live nmethods). But with your changes >>>>>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>>>>> frequently? Why to sweep if there were no nmethods state change and >>>>>>>>>>>> there is enough space in CodeCache. So I am not sure about removing >>>>>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>>>>> determine when we call the >>>>>>>>> sweeper. The bottom line is that we do not invoke the sweeper only if: >>>>>>>> !!!!We DO INVOKE the sweeper only if: >>>>>>>>> (1) The code cache is getting full and/or >>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>>>>> The patch contains a detailed description + examples of the logic. I >>>>>>>>> tested the patch >>>>>>>>> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >>>>>>>>> code cache >>>>>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>>>>> octane). The measurements >>>>>>>>> indicate that with the current logic in place, we can reduce the >>>>>>>>> number of sweeps by 50% for >>>>>>>>> medium code cache sizes without increasing the maximum used code cache >>>>>>>>> size. The difference >>>>>>>>> is more or less not significant. >>>>>>>>> >>>>>>>>> Please let me know what you think about it. The main disadvantage I >>>>>>>>> see with this change is that >>>>>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>>>>> corresponding code. >>>>>>>>>>>> >>>>>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>>>>>>>>> that now so it is not included in the patch. >>>>>>>>>>>> It is for separate change. >>>>>>>>>>>> >>>>>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>>>>> codecache sweeping because we loose performance since we go into >>>>>>>>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>>>>> >>>>>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>>>>>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>>>>> executed unconditionally. >>>>>>>>>>>> >>>>>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>>>>> >>>>>>>>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>>>>>>>> there to remove it in jdk9: >>>>>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>> I'll file a new bug to remove the flag. I guess this change will most >>>>>>>>> likely only make it into 8uXX. >>>>>>>>>>>>> Testing >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>>>>>>>>> performance evaluation. >>>>>>>>>>>>> >>>>>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>>>>> Best, >>>>>>>>>>>>> Albert From vladimir.kozlov at oracle.com Mon Nov 11 11:18:05 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Nov 2013 11:18:05 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> <5280897C.7000107@oracle.com> <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> Message-ID: <52812D6D.3060305@oracle.com> Albert, Igor Don't do timestamps and PrintMethodFlushing changes now. File RFE. They are not related to the fix. For this fix do only minimum what was suggested before and you already almost have needed code: Default behavior: print warning once (with codecache_print() as in your current code) With -XX:+PrintCodeCache: print all warnings and your new compilation re-enabled string message. May be it should not be warnings for these sequential output. I am fine to print these messages with PrintCodeCache since it is codecache state change. And it is not obvious from the name PrintMethodFlushing flag that it controls codecache info. Lets discuss it later for jdk9 and 8u what output and flags we will use to trace CodeCache behavior. We have a lot of flags so we need to be conservative with adding new one. Do not add messages like next: + warning("(Printing one such message for every 10th event)"); Thanks, Vladimir On 11/11/13 8:00 AM, Albert Noll wrote: > Hi Igor, > > Thanks for your input. I agree with you. Let me summarize what is being printed, just to make sure I get it right: > > Default behavior: Print warning once > > -XX:+PrintMethodFlushing: Print details (as listend above) with time stamps. > > Add option to remove all output. > > Is that correct? > > Best, > Albert > > Von meinem iPhone gesendet > >> Am 11.11.2013 um 09:39 schrieb Igor Veresov : >> >> >>> On Nov 10, 2013, at 11:38 PM, Albert Noll wrote: >>> >>> Hi Igor, >>> >>> thanks for looking into this. My only concern with printing the warning under -XX:+PrintCodeCache is >>> that we change existing behavior of PrintCodeCache. If this is not an issue, I am fine with it. >>> >>> I think that the cleanest solution is to introduce a new product flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default that value to true. I would set the default value to true, >>> since the code cache is not expected to become full with default code cache sizes. If the code cache >>> becomes full nevertheless or the user sets a small code cache size we could print a warning like this: >>> >>>> Compiler was disabled because there is insufficient contiguous free space in the code cache. >>>> Free space: 2k requested size: 4k >>>> Try to increase code cache with -XX:ReservedCodeCacheSize= or try to increase code cache >>>> sweeper activity with -XX:NmethodSweepActivity= (default value is 10). >>>> Disable this warning with: -XX:-PrintFullCodeCacheWarnings >> >> Hi Albert, >> >> Thanks for giving it a thought. My only concern with the previous solution was printing the warning repeatedly every 10th time. I think one time is enough to convey the message: "bump the size or you?re loosing on performance?. Printing the warning repeatedly doesn?t really provide any useful information because there is not much context. It becomes useful when the user sees all the state transitions: when the compilers were disabled and why, how much methods were flushed and, as a result, how much space was freed, when the compilers where re-enabled, what sweeping activity was there, etc. May be this can be printed under PrintMethodFlushing without Verbose? It would be also nice to have timestamps. People doing performance analysis will really appreciate that. See PrintGCDetails and PrintGCTimeStamps. May be there should be an option to disable with warning altogether (so that it?s not printed even the first time) for cases when the code cache size is constrained! on purpos e. Most of this is probably for another change. >> >> TL;DR: may be print the warning once. >> >>> I would not print all the information that we print right now, because I think it is too detailed. >>> E.g., I am not sure if it is helpful to print the bounds if the code cache. Also, I think we should >>> substract CodeCacheMinimumFreeSpace from unallocated_capacity. It is confusing that we >>> run out of code cache (and disable compilation) although there is still 500k left. >> >> I agree, it is confusing. >> >> igor >> >>> >>> Please let me know what you think. >>> >>> Best, >>> Albert >>> >>> >>>> On 11/08/2013 11:44 PM, Igor Veresov wrote: >>>> Hi Albert, >>>> >>>> I talked with Vladimir and we have a suggestion about the warning. How about we print it only the first time by default and every time if PrintCodeCache is set? The fact that it is printed even once should suggest the user that the code cache size is something that needs attention, and that the VM is already operating with the constraint code cache space. >>>> >>>> Thanks! >>>> igor >>>> >>>>> On Nov 8, 2013, at 7:32 AM, Albert Noll wrote: >>>>> >>>>> Hi Vladimir, >>>>> >>>>> thanks for looking at the patch. I hope that this version addresses all issues that >>>>> you brought up. Here is a high-level overview of the changes since the last version: >>>>> >>>>> * We keep track of code cache state changes that also happen outside the sweeper. >>>>> I re-installed notify, which is now called report_state_change() and is doing the job. >>>>> report_state_change() checks if enough state has changed and enables the sweeper >>>>> (it sets _should_sweep) to true. We reset _bytes_changed only once we have finished >>>>> a while sweep cycle. That seems to make sense to me. >>>>> >>>>> * I added code that prints out every 10th warning that the compiler has been disabled. >>>>> I also added a warning that compilation has been enabled again. I think if we print a message >>>>> that compilation has been disabled, we should also print a message (maybe not a warning) >>>>> that was enabled again. >>>>> >>>>> Here is the new webrev: >>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>>> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>>>>>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>>>>> Nice work, Albert >>>>>>> >>>>>>> One concern is transition "alive -> not_entrant" is counted only when >>>>>>> the nmethod needs to be flushed because you removed in notify() in >>>>>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is called from >>>>>>> other places. >>>>>>> I think _bytes_changed should be updated by NMethodSweeper::notify() so >>>>>>> don't remove it from nmethod.cpp. _bytes_changed should be reset when we >>>>>>> finished sweep instead of before each sweep. >>>>>> May be reset in both places actually. One to check that there were updates between sweeps and an other during sweep (as you do currently). >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> Can you keep comments in code which initialize static variables (first >>>>>>> changes in sweeper.cpp)? >>>>>>> >>>>>>> Please narrow your main comment, chars 90 chars per line. >>>>>>> >>>>>>> What is the second place? (initialization should not be count): >>>>>>> >>>>>>> + // of the two places where should_sweep can be set to true. >>>>>>> >>>>>>> You need to clear state in the comment conditions when we sweep. Like >>>>>>> you did in the replay: >>>>>>> >>>>>>> (1) The code cache is getting full >>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>> (3) We have not been sweeping for 'some time' >>>>>>> >>>>>>> Split into 2 lines: >>>>>>> >>>>>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - >>>>>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>>>>> >>>>>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>>>>> The previous mail contains an error. See inline. >>>>>>>> >>>>>>>> Albert >>>>>>>> >>>>>>>> >>>>>>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>>>>> Here is the updated webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>>>>> >>>>>>>>> Please see comments inline. >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>>>>> Good idea. >>>>>>>>>> >>>>>>>>>> -- John (on my iPhone) >>>>>>>>>> >>>>>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Looks good. It?s not related to the change, but could you please >>>>>>>>>>> consider adding some printing under PrintMethodFlushing && Verbose >>>>>>>>>>> for the case when the method is made not entrant and include hotness >>>>>>>>>>> and threshold values? >>>>>>>>>>> >>>>>>>>>>> igor >>>>>>>>> I also agree. I added the print. >>>>>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>>>>> are two issues that cause this regression: >>>>>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>>>>> result, NmethodSweepFraction remains 16 (if TieredCompilation is >>>>>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to false. As a >>>>>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>>>>> called much more frequently. >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that it is >>>>>>>>>>>>> always executed. >>>>>>>>>>>> Good. >>>>>>>>> The place where I moved the adaption of NmethodSweepFraction is not >>>>>>>>> good, since the >>>>>>>>> the code cache size is adapted later for tiered. The current version >>>>>>>>> should be fine. >>>>>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>>>>> I think that these checks are not needed since >>>>>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>>>>> active nmethods irrespective of the value of >>>>>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>>>>> the patch removes need_marking_phase() printing >>>>>>>>>>>>> out the warning (line 327 in >>>>>>>>>>>>> sweeper.cpp) is incorrect, i.e., we continue to >>>>>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>>>>> and the associated code. >>>>>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>>>>> Done. >>>>>>>>>>>> To do nmethod marking at each safepoint is fine (we have to do it >>>>>>>>>>>> to make sure we did not miss live nmethods). But with your changes >>>>>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>>>>> frequently? Why to sweep if there were no nmethods state change and >>>>>>>>>>>> there is enough space in CodeCache. So I am not sure about removing >>>>>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>>>>> determine when we call the >>>>>>>>> sweeper. The bottom line is that we do not invoke the sweeper only if: >>>>>>>> !!!!We DO INVOKE the sweeper only if: >>>>>>>>> (1) The code cache is getting full and/or >>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>>>>> The patch contains a detailed description + examples of the logic. I >>>>>>>>> tested the patch >>>>>>>>> with small code cache sizes (specjvm98 + <4m code cache), medium-sized >>>>>>>>> code cache >>>>>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>>>>> octane). The measurements >>>>>>>>> indicate that with the current logic in place, we can reduce the >>>>>>>>> number of sweeps by 50% for >>>>>>>>> medium code cache sizes without increasing the maximum used code cache >>>>>>>>> size. The difference >>>>>>>>> is more or less not significant. >>>>>>>>> >>>>>>>>> Please let me know what you think about it. The main disadvantage I >>>>>>>>> see with this change is that >>>>>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>>>>> corresponding code. >>>>>>>>>>>> >>>>>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>>>>> redundant and can be removed. I am not quite sure if we should do >>>>>>>>>>>>> that now so it is not included in the patch. >>>>>>>>>>>> It is for separate change. >>>>>>>>>>>> >>>>>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>>>>> codecache sweeping because we loose performance since we go into >>>>>>>>>>>> Interpreter after codecache filled. Did you tried to run with it >>>>>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>>>>> >>>>>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous so you >>>>>>>>>>>> can't remove it easily. But don't replace MethodFlushing with it. I >>>>>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>>>>> executed unconditionally. >>>>>>>>>>>> >>>>>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>>>>> >>>>>>>>>>>> jdk8 is major release so we can change flags. Add MethodFlushing >>>>>>>>>>>> there to remove it in jdk9: >>>>>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), JDK_Version::jdk(9) }, >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>> I'll file a new bug to remove the flag. I guess this change will most >>>>>>>>> likely only make it into 8uXX. >>>>>>>>>>>>> Testing >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also shows a >>>>>>>>>>>>> performance evaluation. >>>>>>>>>>>>> >>>>>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>>>>> Best, >>>>>>>>>>>>> Albert >> From vladimir.kozlov at oracle.com Mon Nov 11 14:29:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Nov 2013 14:29:08 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <72B4D395-49FA-4354-A9DD-1D6FFA408D93@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> <5280897C.7000107@oracle.com> <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> <52812B90.8060609@oracle.com> <52813EF8.3060202@oracle.com> <72B4D395-49FA-4354-A9DD-1D6FFA408D93@oracle.com> Message-ID: <52815A34.1030004@oracle.com> Albert, I talked to Igor about this. And there is workaround for Chris's problem (-XX:-PrintWarnings). For this fix we need only print the warning once and that is it. Do NOT put it under flag (for repetitive printing). Remove new "Compiler has been enabled." message from your changes, we will have something when we will do CodeCache tracing later. Leave message as it is. Thanks, Vladimir On 11/11/13 1:00 PM, Albert Noll wrote: > Hi, > > maybe there is no solution that fits all needs. > > The problem is somehow related to MaxNodeLimit. If we exceed the limit, the method is not compiled and we might therefore loose performance. In fact, I experienced that once during my PhD (it was a really large method that was generated by some tool) and I was wondering why Hotspot was so slow on that particular benchmark. > > So I think that having a warning (or some sort of messsge to the user) is important. Maybe - to keep it as simple as possible - we should print the message once. Maybe we should not even say that compilation is disabled, we just say that there might be a performance drop. It is true that compilation is disabled; but it is re-enabled shortly thereafter. > > What do you think about this? > > Albert > > > Von meinem iPhone gesendet > >> Am 11.11.2013 um 21:32 schrieb Vladimir Kozlov : >> >> Chris, >> >> I understand your situation. But there could be a customer who set ReservedCodeCacheSize 5 years ago (before Tiered Compilation). If we disable warning based on the command line flag he will be not notified that he out of space. >> >> How critical to not have the warning for embedded? >> >> ARRGGHH. It would be very very nice if 4 of sit together and talk about this. We need to make decision today so that Albert can push the fix. >> >> I am struggling myself about what the solution should be. >> >> On one hand with UseCodeCacheFlushing the warning is not important (and could be incorrect since we may continue compile). On other hand we need to notify user that he may be loosing performance because of small codecache. >> >> The solution could be, as Albert suggested, new product flag -XX:-PrintFullCodeCacheWarnings. But it is additional flag and we have tons of them already. >> >> Thanks, >> Vladimir >> >>> On 11/11/13 11:10 AM, Chris Plummer wrote: >>> For users that that set ReservedCodeCacheSize to something lower than >>> the default, you probably want the single warning message off by >>> default, and otherwise want it on by default. >>> >>> Chris >>> >>>> On 11/11/13 8:00 AM, Albert Noll wrote: >>>> Hi Igor, >>>> >>>> Thanks for your input. I agree with you. Let me summarize what is >>>> being printed, just to make sure I get it right: >>>> >>>> Default behavior: Print warning once >>>> >>>> -XX:+PrintMethodFlushing: Print details (as listend above) with time >>>> stamps. >>>> >>>> Add option to remove all output. >>>> >>>> Is that correct? >>>> >>>> Best, >>>> Albert >>>> >>>> Von meinem iPhone gesendet >>>> >>>>> Am 11.11.2013 um 09:39 schrieb Igor Veresov : >>>>> >>>>> >>>>>> On Nov 10, 2013, at 11:38 PM, Albert Noll >>>>>> wrote: >>>>>> >>>>>> Hi Igor, >>>>>> >>>>>> thanks for looking into this. My only concern with printing the >>>>>> warning under -XX:+PrintCodeCache is >>>>>> that we change existing behavior of PrintCodeCache. If this is not >>>>>> an issue, I am fine with it. >>>>>> >>>>>> I think that the cleanest solution is to introduce a new product >>>>>> flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default that value >>>>>> to true. I would set the default value to true, >>>>>> since the code cache is not expected to become full with default >>>>>> code cache sizes. If the code cache >>>>>> becomes full nevertheless or the user sets a small code cache size >>>>>> we could print a warning like this: >>>>>> >>>>>>> Compiler was disabled because there is insufficient contiguous free >>>>>>> space in the code cache. >>>>>>> Free space: 2k requested size: 4k >>>>>>> Try to increase code cache with -XX:ReservedCodeCacheSize= or try >>>>>>> to increase code cache >>>>>>> sweeper activity with -XX:NmethodSweepActivity= (default value is 10). >>>>>>> Disable this warning with: -XX:-PrintFullCodeCacheWarnings >>>>> Hi Albert, >>>>> >>>>> Thanks for giving it a thought. My only concern with the previous >>>>> solution was printing the warning repeatedly every 10th time. I think >>>>> one time is enough to convey the message: "bump the size or you?re >>>>> loosing on performance?. Printing the warning repeatedly doesn?t >>>>> really provide any useful information because there is not much >>>>> context. It becomes useful when the user sees all the state >>>>> transitions: when the compilers were disabled and why, how much >>>>> methods were flushed and, as a result, how much space was freed, when >>>>> the compilers where re-enabled, what sweeping activity was there, >>>>> etc. May be this can be printed under PrintMethodFlushing without >>>>> Verbose? It would be also nice to have timestamps. People doing >>>>> performance analysis will really appreciate that. See PrintGCDetails >>>>> and PrintGCTimeStamps. May be there should be an option to disable >>>>> with warning altogether (so that it?s not printed even the first >>>>> time) for cases when the code cache size is constrained on purpose. >>>>> Most of this is probably for another change. >>>>> >>>>> TL;DR: may be print the warning once. >>>>> >>>>>> I would not print all the information that we print right now, >>>>>> because I think it is too detailed. >>>>>> E.g., I am not sure if it is helpful to print the bounds if the code >>>>>> cache. Also, I think we should >>>>>> substract CodeCacheMinimumFreeSpace from unallocated_capacity. It is >>>>>> confusing that we >>>>>> run out of code cache (and disable compilation) although there is >>>>>> still 500k left. >>>>> I agree, it is confusing. >>>>> >>>>> igor >>>>> >>>>>> Please let me know what you think. >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> >>>>>>> On 11/08/2013 11:44 PM, Igor Veresov wrote: >>>>>>> Hi Albert, >>>>>>> >>>>>>> I talked with Vladimir and we have a suggestion about the warning. >>>>>>> How about we print it only the first time by default and every time >>>>>>> if PrintCodeCache is set? The fact that it is printed even once >>>>>>> should suggest the user that the code cache size is something that >>>>>>> needs attention, and that the VM is already operating with the >>>>>>> constraint code cache space. >>>>>>> >>>>>>> Thanks! >>>>>>> igor >>>>>>> >>>>>>>> On Nov 8, 2013, at 7:32 AM, Albert Noll >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> thanks for looking at the patch. I hope that this version >>>>>>>> addresses all issues that >>>>>>>> you brought up. Here is a high-level overview of the changes since >>>>>>>> the last version: >>>>>>>> >>>>>>>> * We keep track of code cache state changes that also happen >>>>>>>> outside the sweeper. >>>>>>>> I re-installed notify, which is now called report_state_change() >>>>>>>> and is doing the job. >>>>>>>> report_state_change() checks if enough state has changed and >>>>>>>> enables the sweeper >>>>>>>> (it sets _should_sweep) to true. We reset _bytes_changed only >>>>>>>> once we have finished >>>>>>>> a while sweep cycle. That seems to make sense to me. >>>>>>>> >>>>>>>> * I added code that prints out every 10th warning that the >>>>>>>> compiler has been disabled. >>>>>>>> I also added a warning that compilation has been enabled again. >>>>>>>> I think if we print a message >>>>>>>> that compilation has been disabled, we should also print a >>>>>>>> message (maybe not a warning) >>>>>>>> that was enabled again. >>>>>>>> >>>>>>>> Here is the new webrev: >>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>>>> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>>>>>>>>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>>>>>>>> Nice work, Albert >>>>>>>>>> >>>>>>>>>> One concern is transition "alive -> not_entrant" is counted only >>>>>>>>>> when >>>>>>>>>> the nmethod needs to be flushed because you removed in notify() in >>>>>>>>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is >>>>>>>>>> called from >>>>>>>>>> other places. >>>>>>>>>> I think _bytes_changed should be updated by >>>>>>>>>> NMethodSweeper::notify() so >>>>>>>>>> don't remove it from nmethod.cpp. _bytes_changed should be reset >>>>>>>>>> when we >>>>>>>>>> finished sweep instead of before each sweep. >>>>>>>>> May be reset in both places actually. One to check that there >>>>>>>>> were updates between sweeps and an other during sweep (as you do >>>>>>>>> currently). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> Can you keep comments in code which initialize static variables >>>>>>>>>> (first >>>>>>>>>> changes in sweeper.cpp)? >>>>>>>>>> >>>>>>>>>> Please narrow your main comment, chars 90 chars per line. >>>>>>>>>> >>>>>>>>>> What is the second place? (initialization should not be count): >>>>>>>>>> >>>>>>>>>> + // of the two places where should_sweep can be set to true. >>>>>>>>>> >>>>>>>>>> You need to clear state in the comment conditions when we sweep. >>>>>>>>>> Like >>>>>>>>>> you did in the replay: >>>>>>>>>> >>>>>>>>>> (1) The code cache is getting full >>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>> (3) We have not been sweeping for 'some time' >>>>>>>>>> >>>>>>>>>> Split into 2 lines: >>>>>>>>>> >>>>>>>>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * >>>>>>>>>> M)) - >>>>>>>>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>>>>>>>> >>>>>>>>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>>>>>>>> The previous mail contains an error. See inline. >>>>>>>>>>> >>>>>>>>>>> Albert >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>>>>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> Please see comments inline. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>>>>>>>> Good idea. >>>>>>>>>>>>> >>>>>>>>>>>>> -- John (on my iPhone) >>>>>>>>>>>>> >>>>>>>>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Looks good. It?s not related to the change, but could you >>>>>>>>>>>>>> please >>>>>>>>>>>>>> consider adding some printing under PrintMethodFlushing && >>>>>>>>>>>>>> Verbose >>>>>>>>>>>>>> for the case when the method is made not entrant and include >>>>>>>>>>>>>> hotness >>>>>>>>>>>>>> and threshold values? >>>>>>>>>>>>>> >>>>>>>>>>>>>> igor >>>>>>>>>>>> I also agree. I added the print. >>>>>>>>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>>>>>>>> are two issues that cause this regression: >>>>>>>>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>>>>>>>> result, NmethodSweepFraction remains 16 (if >>>>>>>>>>>>>>>> TieredCompilation is >>>>>>>>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to >>>>>>>>>>>>>>>> false. As a >>>>>>>>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>>>>>>>> called much more frequently. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that >>>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>>> always executed. >>>>>>>>>>>>>>> Good. >>>>>>>>>>>> The place where I moved the adaption of NmethodSweepFraction >>>>>>>>>>>> is not >>>>>>>>>>>> good, since the >>>>>>>>>>>> the code cache size is adapted later for tiered. The current >>>>>>>>>>>> version >>>>>>>>>>>> should be fine. >>>>>>>>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>>>>>>>> I think that these checks are not needed >>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>>>>>>>> active nmethods irrespective of the >>>>>>>>>>>>>>>> value of >>>>>>>>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>>>>>>>> the patch removes need_marking_phase() >>>>>>>>>>>>>>>> printing >>>>>>>>>>>>>>>> out the warning (line 327 in >>>>>>>>>>>>>>>> sweeper.cpp) is incorrect, i.e., we >>>>>>>>>>>>>>>> continue to >>>>>>>>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>>>>>>>> and the associated code. >>>>>>>>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>>>>>>>> Done. >>>>>>>>>>>>>>> To do nmethod marking at each safepoint is fine (we have >>>>>>>>>>>>>>> to do it >>>>>>>>>>>>>>> to make sure we did not miss live nmethods). But with your >>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>>>>>>>> frequently? Why to sweep if there were no nmethods state >>>>>>>>>>>>>>> change and >>>>>>>>>>>>>>> there is enough space in CodeCache. So I am not sure about >>>>>>>>>>>>>>> removing >>>>>>>>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>>>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>>>>>>>> determine when we call the >>>>>>>>>>>> sweeper. The bottom line is that we do not invoke the sweeper >>>>>>>>>>>> only if: >>>>>>>>>>> !!!!We DO INVOKE the sweeper only if: >>>>>>>>>>>> (1) The code cache is getting full and/or >>>>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>>>>>>>> The patch contains a detailed description + examples of the >>>>>>>>>>>> logic. I >>>>>>>>>>>> tested the patch >>>>>>>>>>>> with small code cache sizes (specjvm98 + <4m code cache), >>>>>>>>>>>> medium-sized >>>>>>>>>>>> code cache >>>>>>>>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>>>>>>>> octane). The measurements >>>>>>>>>>>> indicate that with the current logic in place, we can reduce the >>>>>>>>>>>> number of sweeps by 50% for >>>>>>>>>>>> medium code cache sizes without increasing the maximum used >>>>>>>>>>>> code cache >>>>>>>>>>>> size. The difference >>>>>>>>>>>> is more or less not significant. >>>>>>>>>>>> >>>>>>>>>>>> Please let me know what you think about it. The main >>>>>>>>>>>> disadvantage I >>>>>>>>>>>> see with this change is that >>>>>>>>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>>>>>>>> corresponding code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>>>>>>>> redundant and can be removed. I am not quite sure if we >>>>>>>>>>>>>>>> should do >>>>>>>>>>>>>>>> that now so it is not included in the patch. >>>>>>>>>>>>>>> It is for separate change. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>>>>>>>> codecache sweeping because we loose performance since we go >>>>>>>>>>>>>>> into >>>>>>>>>>>>>>> Interpreter after codecache filled. Did you tried to run >>>>>>>>>>>>>>> with it >>>>>>>>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous >>>>>>>>>>>>>>> so you >>>>>>>>>>>>>>> can't remove it easily. But don't replace MethodFlushing >>>>>>>>>>>>>>> with it. I >>>>>>>>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>>>>>>>> executed unconditionally. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> jdk8 is major release so we can change flags. Add >>>>>>>>>>>>>>> MethodFlushing >>>>>>>>>>>>>>> there to remove it in jdk9: >>>>>>>>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), >>>>>>>>>>>>>>> JDK_Version::jdk(9) }, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>> I'll file a new bug to remove the flag. I guess this change >>>>>>>>>>>> will most >>>>>>>>>>>> likely only make it into 8uXX. >>>>>>>>>>>>>>>> Testing >>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also >>>>>>>>>>>>>>>> shows a >>>>>>>>>>>>>>>> performance evaluation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>> Albert >>> >>> From vladimir.kozlov at oracle.com Mon Nov 11 14:40:33 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 11 Nov 2013 22:40:33 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get Message-ID: <20131111224040.6AD406250F@hg.openjdk.java.net> Changeset: 1dcea64e9f00 Author: kvn Date: 2013-11-11 11:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From uschindler at apache.org Mon Nov 11 14:49:29 2013 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 11 Nov 2013 23:49:29 +0100 Subject: RFR (XS): 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get In-Reply-To: <527FDB0D.20200@oracle.com> References: <525D80C3.5020604@oracle.com> <527E8B19.3090303@oracle.com> <74DE736D-8E22-455B-8158-AE783B650B64@oracle.com> <527EDBE1.5040505@oracle.com> <527FDB0D.20200@oracle.com> Message-ID: <036a01cedf30$48187630$d8496290$@apache.org> Thanks you, Vladimir, for your hard work! Impressive :-=) We are happy to run the 24/7 tests with a new developer preview of Java 7 or Java 8 that fixes this bug, once it is out! Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Chair / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot- > compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Sunday, November 10, 2013 8:14 PM > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (XS): 8024830: SEGV in > org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get > > Thank you, Dawid, for confirmation and for your help with running lucene > tests. > > Regards, > Vladimir > > On 11/10/13 8:54 AM, Dawid Weiss wrote: > > I confirm that this patch fixes the problem encountered in > > LUCENE-5212. I've tested svn rev. 1523179 (trunk) against jdk8-b114 > > with and without Vladimir's patch. Without the patch the test sequence > > ends about 50% of the time in a sigsegv. With the patch all executions > > ended without any errors. > > > > I have no idea how you tracked this down, Vladimir, but I > > enthusiastically share your "Huraaa!" [1] :) > > > > Dawid > > > > [1] > > https://bugs.openjdk.java.net/browse/JDK- > 8024830?focusedCommentId=1342 > > 6080#comment-13426080 > > > > On Sun, Nov 10, 2013 at 2:05 AM, Vladimir Kozlov > > wrote: > >> Thank you, Igor > >> > >> I will fix the comment. > >> > >> Vladimir > >> > >> > >> On 11/9/13 4:33 PM, Igor Veresov wrote: > >>> > >>> Woot! Looks good. > >>> > >>> A typo: > >>> > >>> 510 // RA guarantee such alignment ... > >>> > >>> igor > >>> > >>> On Nov 9, 2013, at 11:20 AM, Vladimir Kozlov > >>> > >>> wrote: > >>> > >>>> http://cr.openjdk.java.net/~kvn/8024830/webrev/ > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8024830 > >>>> > >>>> C2 Register Allocator can use input argument's stack slots for > >>>> spills but until RA we don't know what offset and alignment these > >>>> slots have. The minimum provided alignment is 8 bytes (for Double > >>>> and long values). For wide vectors it is not enough. When vector is > >>>> spilled there (as in this bug) it may stomp over values on caller's stack > which follow argument's slots. > >>>> > >>>> Exclude enough (vector's size - 1) last input argument's stack > >>>> slots from vector's spilling masks to avoid it. > >>>> > >>>> The fix is the same for jdk7u and jdk8. > >>>> > >>>> Tested lucene tests, JPRT, jtreg, ctw. > >>>> > >>>> Thanks, > >>>> Vladimir > >>>> > >>>> > >>>> > >>> > >> From albert.noll at oracle.com Mon Nov 11 21:54:39 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 12 Nov 2013 06:54:39 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <52815A34.1030004@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> <5280897C.7000107@oracle.com> <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> <52812B90.8060609@oracle.com> <52813EF8.3060202@oracle.com> <72B4D395-49FA-4354-A9DD-1D6FFA408D93@oracle.com> <52815A34.1030004@oracle.com> Message-ID: <705C3B37-78E4-4A29-82FB-F6FEA4219482@oracle.com> Hi, thanks again for your thoughts. I will do the change as soon as I am in the office. Igor, can I count you as a reviewer? Best, Albert Von meinem iPhone gesendet > Am 11.11.2013 um 23:29 schrieb Vladimir Kozlov : > > Albert, > > I talked to Igor about this. > And there is workaround for Chris's problem (-XX:-PrintWarnings). > > For this fix we need only print the warning once and that is it. > Do NOT put it under flag (for repetitive printing). > Remove new "Compiler has been enabled." message from your changes, we will have something when we will do CodeCache tracing later. > > Leave message as it is. > > Thanks, > Vladimir > >> On 11/11/13 1:00 PM, Albert Noll wrote: >> Hi, >> >> maybe there is no solution that fits all needs. >> >> The problem is somehow related to MaxNodeLimit. If we exceed the limit, the method is not compiled and we might therefore loose performance. In fact, I experienced that once during my PhD (it was a really large method that was generated by some tool) and I was wondering why Hotspot was so slow on that particular benchmark. >> >> So I think that having a warning (or some sort of messsge to the user) is important. Maybe - to keep it as simple as possible - we should print the message once. Maybe we should not even say that compilation is disabled, we just say that there might be a performance drop. It is true that compilation is disabled; but it is re-enabled shortly thereafter. >> >> What do you think about this? >> >> Albert >> >> >> Von meinem iPhone gesendet >> >>> Am 11.11.2013 um 21:32 schrieb Vladimir Kozlov : >>> >>> Chris, >>> >>> I understand your situation. But there could be a customer who set ReservedCodeCacheSize 5 years ago (before Tiered Compilation). If we disable warning based on the command line flag he will be not notified that he out of space. >>> >>> How critical to not have the warning for embedded? >>> >>> ARRGGHH. It would be very very nice if 4 of sit together and talk about this. We need to make decision today so that Albert can push the fix. >>> >>> I am struggling myself about what the solution should be. >>> >>> On one hand with UseCodeCacheFlushing the warning is not important (and could be incorrect since we may continue compile). On other hand we need to notify user that he may be loosing performance because of small codecache. >>> >>> The solution could be, as Albert suggested, new product flag -XX:-PrintFullCodeCacheWarnings. But it is additional flag and we have tons of them already. >>> >>> Thanks, >>> Vladimir >>> >>>> On 11/11/13 11:10 AM, Chris Plummer wrote: >>>> For users that that set ReservedCodeCacheSize to something lower than >>>> the default, you probably want the single warning message off by >>>> default, and otherwise want it on by default. >>>> >>>> Chris >>>> >>>>> On 11/11/13 8:00 AM, Albert Noll wrote: >>>>> Hi Igor, >>>>> >>>>> Thanks for your input. I agree with you. Let me summarize what is >>>>> being printed, just to make sure I get it right: >>>>> >>>>> Default behavior: Print warning once >>>>> >>>>> -XX:+PrintMethodFlushing: Print details (as listend above) with time >>>>> stamps. >>>>> >>>>> Add option to remove all output. >>>>> >>>>> Is that correct? >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> Von meinem iPhone gesendet >>>>> >>>>>> Am 11.11.2013 um 09:39 schrieb Igor Veresov : >>>>>> >>>>>> >>>>>>> On Nov 10, 2013, at 11:38 PM, Albert Noll >>>>>>> wrote: >>>>>>> >>>>>>> Hi Igor, >>>>>>> >>>>>>> thanks for looking into this. My only concern with printing the >>>>>>> warning under -XX:+PrintCodeCache is >>>>>>> that we change existing behavior of PrintCodeCache. If this is not >>>>>>> an issue, I am fine with it. >>>>>>> >>>>>>> I think that the cleanest solution is to introduce a new product >>>>>>> flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default that value >>>>>>> to true. I would set the default value to true, >>>>>>> since the code cache is not expected to become full with default >>>>>>> code cache sizes. If the code cache >>>>>>> becomes full nevertheless or the user sets a small code cache size >>>>>>> we could print a warning like this: >>>>>>> >>>>>>>> Compiler was disabled because there is insufficient contiguous free >>>>>>>> space in the code cache. >>>>>>>> Free space: 2k requested size: 4k >>>>>>>> Try to increase code cache with -XX:ReservedCodeCacheSize= or try >>>>>>>> to increase code cache >>>>>>>> sweeper activity with -XX:NmethodSweepActivity= (default value is 10). >>>>>>>> Disable this warning with: -XX:-PrintFullCodeCacheWarnings >>>>>> Hi Albert, >>>>>> >>>>>> Thanks for giving it a thought. My only concern with the previous >>>>>> solution was printing the warning repeatedly every 10th time. I think >>>>>> one time is enough to convey the message: "bump the size or you?re >>>>>> loosing on performance?. Printing the warning repeatedly doesn?t >>>>>> really provide any useful information because there is not much >>>>>> context. It becomes useful when the user sees all the state >>>>>> transitions: when the compilers were disabled and why, how much >>>>>> methods were flushed and, as a result, how much space was freed, when >>>>>> the compilers where re-enabled, what sweeping activity was there, >>>>>> etc. May be this can be printed under PrintMethodFlushing without >>>>>> Verbose? It would be also nice to have timestamps. People doing >>>>>> performance analysis will really appreciate that. See PrintGCDetails >>>>>> and PrintGCTimeStamps. May be there should be an option to disable >>>>>> with warning altogether (so that it?s not printed even the first >>>>>> time) for cases when the code cache size is constrained on purpose. >>>>>> Most of this is probably for another change. >>>>>> >>>>>> TL;DR: may be print the warning once. >>>>>> >>>>>>> I would not print all the information that we print right now, >>>>>>> because I think it is too detailed. >>>>>>> E.g., I am not sure if it is helpful to print the bounds if the code >>>>>>> cache. Also, I think we should >>>>>>> substract CodeCacheMinimumFreeSpace from unallocated_capacity. It is >>>>>>> confusing that we >>>>>>> run out of code cache (and disable compilation) although there is >>>>>>> still 500k left. >>>>>> I agree, it is confusing. >>>>>> >>>>>> igor >>>>>> >>>>>>> Please let me know what you think. >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> >>>>>>>> On 11/08/2013 11:44 PM, Igor Veresov wrote: >>>>>>>> Hi Albert, >>>>>>>> >>>>>>>> I talked with Vladimir and we have a suggestion about the warning. >>>>>>>> How about we print it only the first time by default and every time >>>>>>>> if PrintCodeCache is set? The fact that it is printed even once >>>>>>>> should suggest the user that the code cache size is something that >>>>>>>> needs attention, and that the VM is already operating with the >>>>>>>> constraint code cache space. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> igor >>>>>>>> >>>>>>>>> On Nov 8, 2013, at 7:32 AM, Albert Noll >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> thanks for looking at the patch. I hope that this version >>>>>>>>> addresses all issues that >>>>>>>>> you brought up. Here is a high-level overview of the changes since >>>>>>>>> the last version: >>>>>>>>> >>>>>>>>> * We keep track of code cache state changes that also happen >>>>>>>>> outside the sweeper. >>>>>>>>> I re-installed notify, which is now called report_state_change() >>>>>>>>> and is doing the job. >>>>>>>>> report_state_change() checks if enough state has changed and >>>>>>>>> enables the sweeper >>>>>>>>> (it sets _should_sweep) to true. We reset _bytes_changed only >>>>>>>>> once we have finished >>>>>>>>> a while sweep cycle. That seems to make sense to me. >>>>>>>>> >>>>>>>>> * I added code that prints out every 10th warning that the >>>>>>>>> compiler has been disabled. >>>>>>>>> I also added a warning that compilation has been enabled again. >>>>>>>>> I think if we print a message >>>>>>>>> that compilation has been disabled, we should also print a >>>>>>>>> message (maybe not a warning) >>>>>>>>> that was enabled again. >>>>>>>>> >>>>>>>>> Here is the new webrev: >>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>>>> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>>>>>>>>>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>>>>>>>>> Nice work, Albert >>>>>>>>>>> >>>>>>>>>>> One concern is transition "alive -> not_entrant" is counted only >>>>>>>>>>> when >>>>>>>>>>> the nmethod needs to be flushed because you removed in notify() in >>>>>>>>>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is >>>>>>>>>>> called from >>>>>>>>>>> other places. >>>>>>>>>>> I think _bytes_changed should be updated by >>>>>>>>>>> NMethodSweeper::notify() so >>>>>>>>>>> don't remove it from nmethod.cpp. _bytes_changed should be reset >>>>>>>>>>> when we >>>>>>>>>>> finished sweep instead of before each sweep. >>>>>>>>>> May be reset in both places actually. One to check that there >>>>>>>>>> were updates between sweeps and an other during sweep (as you do >>>>>>>>>> currently). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> Can you keep comments in code which initialize static variables >>>>>>>>>>> (first >>>>>>>>>>> changes in sweeper.cpp)? >>>>>>>>>>> >>>>>>>>>>> Please narrow your main comment, chars 90 chars per line. >>>>>>>>>>> >>>>>>>>>>> What is the second place? (initialization should not be count): >>>>>>>>>>> >>>>>>>>>>> + // of the two places where should_sweep can be set to true. >>>>>>>>>>> >>>>>>>>>>> You need to clear state in the comment conditions when we sweep. >>>>>>>>>>> Like >>>>>>>>>>> you did in the replay: >>>>>>>>>>> >>>>>>>>>>> (1) The code cache is getting full >>>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>>> (3) We have not been sweeping for 'some time' >>>>>>>>>>> >>>>>>>>>>> Split into 2 lines: >>>>>>>>>>> >>>>>>>>>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * >>>>>>>>>>> M)) - >>>>>>>>>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>>>>>>>>> >>>>>>>>>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>>>>>>>>> The previous mail contains an error. See inline. >>>>>>>>>>>> >>>>>>>>>>>> Albert >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>>>>>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> Please see comments inline. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>>>>>>>>> Good idea. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- John (on my iPhone) >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Looks good. It?s not related to the change, but could you >>>>>>>>>>>>>>> please >>>>>>>>>>>>>>> consider adding some printing under PrintMethodFlushing && >>>>>>>>>>>>>>> Verbose >>>>>>>>>>>>>>> for the case when the method is made not entrant and include >>>>>>>>>>>>>>> hotness >>>>>>>>>>>>>>> and threshold values? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> igor >>>>>>>>>>>>> I also agree. I added the print. >>>>>>>>>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>>>>>>>>> are two issues that cause this regression: >>>>>>>>>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>>>>>>>>> result, NmethodSweepFraction remains 16 (if >>>>>>>>>>>>>>>>> TieredCompilation is >>>>>>>>>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to >>>>>>>>>>>>>>>>> false. As a >>>>>>>>>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>>>>>>>>> called much more frequently. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that >>>>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>>>> always executed. >>>>>>>>>>>>>>>> Good. >>>>>>>>>>>>> The place where I moved the adaption of NmethodSweepFraction >>>>>>>>>>>>> is not >>>>>>>>>>>>> good, since the >>>>>>>>>>>>> the code cache size is adapted later for tiered. The current >>>>>>>>>>>>> version >>>>>>>>>>>>> should be fine. >>>>>>>>>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>>>>>>>>> I think that these checks are not needed >>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>>>>>>>>> active nmethods irrespective of the >>>>>>>>>>>>>>>>> value of >>>>>>>>>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>>>>>>>>> the patch removes need_marking_phase() >>>>>>>>>>>>>>>>> printing >>>>>>>>>>>>>>>>> out the warning (line 327 in >>>>>>>>>>>>>>>>> sweeper.cpp) is incorrect, i.e., we >>>>>>>>>>>>>>>>> continue to >>>>>>>>>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>>>>>>>>> and the associated code. >>>>>>>>>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>>>>>>>>> Done. >>>>>>>>>>>>>>>> To do nmethod marking at each safepoint is fine (we have >>>>>>>>>>>>>>>> to do it >>>>>>>>>>>>>>>> to make sure we did not miss live nmethods). But with your >>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>>>>>>>>> frequently? Why to sweep if there were no nmethods state >>>>>>>>>>>>>>>> change and >>>>>>>>>>>>>>>> there is enough space in CodeCache. So I am not sure about >>>>>>>>>>>>>>>> removing >>>>>>>>>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>>>>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>>>>>>>>> determine when we call the >>>>>>>>>>>>> sweeper. The bottom line is that we do not invoke the sweeper >>>>>>>>>>>>> only if: >>>>>>>>>>>> !!!!We DO INVOKE the sweeper only if: >>>>>>>>>>>>> (1) The code cache is getting full and/or >>>>>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>>>>>>>>> The patch contains a detailed description + examples of the >>>>>>>>>>>>> logic. I >>>>>>>>>>>>> tested the patch >>>>>>>>>>>>> with small code cache sizes (specjvm98 + <4m code cache), >>>>>>>>>>>>> medium-sized >>>>>>>>>>>>> code cache >>>>>>>>>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>>>>>>>>> octane). The measurements >>>>>>>>>>>>> indicate that with the current logic in place, we can reduce the >>>>>>>>>>>>> number of sweeps by 50% for >>>>>>>>>>>>> medium code cache sizes without increasing the maximum used >>>>>>>>>>>>> code cache >>>>>>>>>>>>> size. The difference >>>>>>>>>>>>> is more or less not significant. >>>>>>>>>>>>> >>>>>>>>>>>>> Please let me know what you think about it. The main >>>>>>>>>>>>> disadvantage I >>>>>>>>>>>>> see with this change is that >>>>>>>>>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>>>>>>>>> corresponding code. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>>>>>>>>> redundant and can be removed. I am not quite sure if we >>>>>>>>>>>>>>>>> should do >>>>>>>>>>>>>>>>> that now so it is not included in the patch. >>>>>>>>>>>>>>>> It is for separate change. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>>>>>>>>> codecache sweeping because we loose performance since we go >>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>> Interpreter after codecache filled. Did you tried to run >>>>>>>>>>>>>>>> with it >>>>>>>>>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous >>>>>>>>>>>>>>>> so you >>>>>>>>>>>>>>>> can't remove it easily. But don't replace MethodFlushing >>>>>>>>>>>>>>>> with it. I >>>>>>>>>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>>>>>>>>> executed unconditionally. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> jdk8 is major release so we can change flags. Add >>>>>>>>>>>>>>>> MethodFlushing >>>>>>>>>>>>>>>> there to remove it in jdk9: >>>>>>>>>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), >>>>>>>>>>>>>>>> JDK_Version::jdk(9) }, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> I'll file a new bug to remove the flag. I guess this change >>>>>>>>>>>>> will most >>>>>>>>>>>>> likely only make it into 8uXX. >>>>>>>>>>>>>>>>> Testing >>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also >>>>>>>>>>>>>>>>> shows a >>>>>>>>>>>>>>>>> performance evaluation. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>>> Albert >>>> >>>> From albert.noll at oracle.com Mon Nov 11 23:23:36 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 12 Nov 2013 08:23:36 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <705C3B37-78E4-4A29-82FB-F6FEA4219482@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> <5280897C.7000107@oracle.com> <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> <52812B90.8060609@oracle.com> <52813EF8.3060202@oracle.com> <72B4D395-49FA-4354-A9DD-1D6FFA408D93@oracle.com> <52815A34.1030004@oracle.com> <705C3B37-78E4-4A29-82FB-F6FEA4219482@oracle.com> Message-ID: <5281D778.9050303@oracle.com> Hi, here is the updated webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.03/ The warning is now only printed once. I'll file an RFE to do proper logging of full code cache behavior. Best, Albert On 11/12/2013 06:54 AM, Albert Noll wrote: > Hi, > > thanks again for your thoughts. I will do the change as soon as I am in the office. > > Igor, can I count you as a reviewer? > > Best, > Albert > > Von meinem iPhone gesendet > >> Am 11.11.2013 um 23:29 schrieb Vladimir Kozlov : >> >> Albert, >> >> I talked to Igor about this. >> And there is workaround for Chris's problem (-XX:-PrintWarnings). >> >> For this fix we need only print the warning once and that is it. >> Do NOT put it under flag (for repetitive printing). >> Remove new "Compiler has been enabled." message from your changes, we will have something when we will do CodeCache tracing later. >> >> Leave message as it is. >> >> Thanks, >> Vladimir >> >>> On 11/11/13 1:00 PM, Albert Noll wrote: >>> Hi, >>> >>> maybe there is no solution that fits all needs. >>> >>> The problem is somehow related to MaxNodeLimit. If we exceed the limit, the method is not compiled and we might therefore loose performance. In fact, I experienced that once during my PhD (it was a really large method that was generated by some tool) and I was wondering why Hotspot was so slow on that particular benchmark. >>> >>> So I think that having a warning (or some sort of messsge to the user) is important. Maybe - to keep it as simple as possible - we should print the message once. Maybe we should not even say that compilation is disabled, we just say that there might be a performance drop. It is true that compilation is disabled; but it is re-enabled shortly thereafter. >>> >>> What do you think about this? >>> >>> Albert >>> >>> >>> Von meinem iPhone gesendet >>> >>>> Am 11.11.2013 um 21:32 schrieb Vladimir Kozlov : >>>> >>>> Chris, >>>> >>>> I understand your situation. But there could be a customer who set ReservedCodeCacheSize 5 years ago (before Tiered Compilation). If we disable warning based on the command line flag he will be not notified that he out of space. >>>> >>>> How critical to not have the warning for embedded? >>>> >>>> ARRGGHH. It would be very very nice if 4 of sit together and talk about this. We need to make decision today so that Albert can push the fix. >>>> >>>> I am struggling myself about what the solution should be. >>>> >>>> On one hand with UseCodeCacheFlushing the warning is not important (and could be incorrect since we may continue compile). On other hand we need to notify user that he may be loosing performance because of small codecache. >>>> >>>> The solution could be, as Albert suggested, new product flag -XX:-PrintFullCodeCacheWarnings. But it is additional flag and we have tons of them already. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> On 11/11/13 11:10 AM, Chris Plummer wrote: >>>>> For users that that set ReservedCodeCacheSize to something lower than >>>>> the default, you probably want the single warning message off by >>>>> default, and otherwise want it on by default. >>>>> >>>>> Chris >>>>> >>>>>> On 11/11/13 8:00 AM, Albert Noll wrote: >>>>>> Hi Igor, >>>>>> >>>>>> Thanks for your input. I agree with you. Let me summarize what is >>>>>> being printed, just to make sure I get it right: >>>>>> >>>>>> Default behavior: Print warning once >>>>>> >>>>>> -XX:+PrintMethodFlushing: Print details (as listend above) with time >>>>>> stamps. >>>>>> >>>>>> Add option to remove all output. >>>>>> >>>>>> Is that correct? >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> Von meinem iPhone gesendet >>>>>> >>>>>>> Am 11.11.2013 um 09:39 schrieb Igor Veresov : >>>>>>> >>>>>>> >>>>>>>> On Nov 10, 2013, at 11:38 PM, Albert Noll >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Igor, >>>>>>>> >>>>>>>> thanks for looking into this. My only concern with printing the >>>>>>>> warning under -XX:+PrintCodeCache is >>>>>>>> that we change existing behavior of PrintCodeCache. If this is not >>>>>>>> an issue, I am fine with it. >>>>>>>> >>>>>>>> I think that the cleanest solution is to introduce a new product >>>>>>>> flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default that value >>>>>>>> to true. I would set the default value to true, >>>>>>>> since the code cache is not expected to become full with default >>>>>>>> code cache sizes. If the code cache >>>>>>>> becomes full nevertheless or the user sets a small code cache size >>>>>>>> we could print a warning like this: >>>>>>>> >>>>>>>>> Compiler was disabled because there is insufficient contiguous free >>>>>>>>> space in the code cache. >>>>>>>>> Free space: 2k requested size: 4k >>>>>>>>> Try to increase code cache with -XX:ReservedCodeCacheSize= or try >>>>>>>>> to increase code cache >>>>>>>>> sweeper activity with -XX:NmethodSweepActivity= (default value is 10). >>>>>>>>> Disable this warning with: -XX:-PrintFullCodeCacheWarnings >>>>>>> Hi Albert, >>>>>>> >>>>>>> Thanks for giving it a thought. My only concern with the previous >>>>>>> solution was printing the warning repeatedly every 10th time. I think >>>>>>> one time is enough to convey the message: "bump the size or you?re >>>>>>> loosing on performance?. Printing the warning repeatedly doesn?t >>>>>>> really provide any useful information because there is not much >>>>>>> context. It becomes useful when the user sees all the state >>>>>>> transitions: when the compilers were disabled and why, how much >>>>>>> methods were flushed and, as a result, how much space was freed, when >>>>>>> the compilers where re-enabled, what sweeping activity was there, >>>>>>> etc. May be this can be printed under PrintMethodFlushing without >>>>>>> Verbose? It would be also nice to have timestamps. People doing >>>>>>> performance analysis will really appreciate that. See PrintGCDetails >>>>>>> and PrintGCTimeStamps. May be there should be an option to disable >>>>>>> with warning altogether (so that it?s not printed even the first >>>>>>> time) for cases when the code cache size is constrained on purpose. >>>>>>> Most of this is probably for another change. >>>>>>> >>>>>>> TL;DR: may be print the warning once. >>>>>>> >>>>>>>> I would not print all the information that we print right now, >>>>>>>> because I think it is too detailed. >>>>>>>> E.g., I am not sure if it is helpful to print the bounds if the code >>>>>>>> cache. Also, I think we should >>>>>>>> substract CodeCacheMinimumFreeSpace from unallocated_capacity. It is >>>>>>>> confusing that we >>>>>>>> run out of code cache (and disable compilation) although there is >>>>>>>> still 500k left. >>>>>>> I agree, it is confusing. >>>>>>> >>>>>>> igor >>>>>>> >>>>>>>> Please let me know what you think. >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> >>>>>>>>> On 11/08/2013 11:44 PM, Igor Veresov wrote: >>>>>>>>> Hi Albert, >>>>>>>>> >>>>>>>>> I talked with Vladimir and we have a suggestion about the warning. >>>>>>>>> How about we print it only the first time by default and every time >>>>>>>>> if PrintCodeCache is set? The fact that it is printed even once >>>>>>>>> should suggest the user that the code cache size is something that >>>>>>>>> needs attention, and that the VM is already operating with the >>>>>>>>> constraint code cache space. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> igor >>>>>>>>> >>>>>>>>>> On Nov 8, 2013, at 7:32 AM, Albert Noll >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> thanks for looking at the patch. I hope that this version >>>>>>>>>> addresses all issues that >>>>>>>>>> you brought up. Here is a high-level overview of the changes since >>>>>>>>>> the last version: >>>>>>>>>> >>>>>>>>>> * We keep track of code cache state changes that also happen >>>>>>>>>> outside the sweeper. >>>>>>>>>> I re-installed notify, which is now called report_state_change() >>>>>>>>>> and is doing the job. >>>>>>>>>> report_state_change() checks if enough state has changed and >>>>>>>>>> enables the sweeper >>>>>>>>>> (it sets _should_sweep) to true. We reset _bytes_changed only >>>>>>>>>> once we have finished >>>>>>>>>> a while sweep cycle. That seems to make sense to me. >>>>>>>>>> >>>>>>>>>> * I added code that prints out every 10th warning that the >>>>>>>>>> compiler has been disabled. >>>>>>>>>> I also added a warning that compilation has been enabled again. >>>>>>>>>> I think if we print a message >>>>>>>>>> that compilation has been disabled, we should also print a >>>>>>>>>> message (maybe not a warning) >>>>>>>>>> that was enabled again. >>>>>>>>>> >>>>>>>>>> Here is the new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>>>>>> >>>>>>>>>>>> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>>>>>>>>>>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>>>>>>>>>> Nice work, Albert >>>>>>>>>>>> >>>>>>>>>>>> One concern is transition "alive -> not_entrant" is counted only >>>>>>>>>>>> when >>>>>>>>>>>> the nmethod needs to be flushed because you removed in notify() in >>>>>>>>>>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is >>>>>>>>>>>> called from >>>>>>>>>>>> other places. >>>>>>>>>>>> I think _bytes_changed should be updated by >>>>>>>>>>>> NMethodSweeper::notify() so >>>>>>>>>>>> don't remove it from nmethod.cpp. _bytes_changed should be reset >>>>>>>>>>>> when we >>>>>>>>>>>> finished sweep instead of before each sweep. >>>>>>>>>>> May be reset in both places actually. One to check that there >>>>>>>>>>> were updates between sweeps and an other during sweep (as you do >>>>>>>>>>> currently). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>>> Can you keep comments in code which initialize static variables >>>>>>>>>>>> (first >>>>>>>>>>>> changes in sweeper.cpp)? >>>>>>>>>>>> >>>>>>>>>>>> Please narrow your main comment, chars 90 chars per line. >>>>>>>>>>>> >>>>>>>>>>>> What is the second place? (initialization should not be count): >>>>>>>>>>>> >>>>>>>>>>>> + // of the two places where should_sweep can be set to true. >>>>>>>>>>>> >>>>>>>>>>>> You need to clear state in the comment conditions when we sweep. >>>>>>>>>>>> Like >>>>>>>>>>>> you did in the replay: >>>>>>>>>>>> >>>>>>>>>>>> (1) The code cache is getting full >>>>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>>>> (3) We have not been sweeping for 'some time' >>>>>>>>>>>> >>>>>>>>>>>> Split into 2 lines: >>>>>>>>>>>> >>>>>>>>>>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * >>>>>>>>>>>> M)) - >>>>>>>>>>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>>>>>>>>>> >>>>>>>>>>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>>>>>>>>>> The previous mail contains an error. See inline. >>>>>>>>>>>>> >>>>>>>>>>>>> Albert >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>>>>>>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please see comments inline. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>>>>>>>>>> Good idea. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- John (on my iPhone) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Looks good. It?s not related to the change, but could you >>>>>>>>>>>>>>>> please >>>>>>>>>>>>>>>> consider adding some printing under PrintMethodFlushing && >>>>>>>>>>>>>>>> Verbose >>>>>>>>>>>>>>>> for the case when the method is made not entrant and include >>>>>>>>>>>>>>>> hotness >>>>>>>>>>>>>>>> and threshold values? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> igor >>>>>>>>>>>>>> I also agree. I added the print. >>>>>>>>>>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>>>>>>>>>> are two issues that cause this regression: >>>>>>>>>>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>>>>>>>>>> result, NmethodSweepFraction remains 16 (if >>>>>>>>>>>>>>>>>> TieredCompilation is >>>>>>>>>>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to >>>>>>>>>>>>>>>>>> false. As a >>>>>>>>>>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>>>>>>>>>> called much more frequently. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that >>>>>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>>>>> always executed. >>>>>>>>>>>>>>>>> Good. >>>>>>>>>>>>>> The place where I moved the adaption of NmethodSweepFraction >>>>>>>>>>>>>> is not >>>>>>>>>>>>>> good, since the >>>>>>>>>>>>>> the code cache size is adapted later for tiered. The current >>>>>>>>>>>>>> version >>>>>>>>>>>>>> should be fine. >>>>>>>>>>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>>>>>>>>>> I think that these checks are not needed >>>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>>>>>>>>>> active nmethods irrespective of the >>>>>>>>>>>>>>>>>> value of >>>>>>>>>>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>>>>>>>>>> the patch removes need_marking_phase() >>>>>>>>>>>>>>>>>> printing >>>>>>>>>>>>>>>>>> out the warning (line 327 in >>>>>>>>>>>>>>>>>> sweeper.cpp) is incorrect, i.e., we >>>>>>>>>>>>>>>>>> continue to >>>>>>>>>>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>>>>>>>>>> and the associated code. >>>>>>>>>>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>>>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>>>> To do nmethod marking at each safepoint is fine (we have >>>>>>>>>>>>>>>>> to do it >>>>>>>>>>>>>>>>> to make sure we did not miss live nmethods). But with your >>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>>>>>>>>>> frequently? Why to sweep if there were no nmethods state >>>>>>>>>>>>>>>>> change and >>>>>>>>>>>>>>>>> there is enough space in CodeCache. So I am not sure about >>>>>>>>>>>>>>>>> removing >>>>>>>>>>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>>>>>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>>>>>>>>>> determine when we call the >>>>>>>>>>>>>> sweeper. The bottom line is that we do not invoke the sweeper >>>>>>>>>>>>>> only if: >>>>>>>>>>>>> !!!!We DO INVOKE the sweeper only if: >>>>>>>>>>>>>> (1) The code cache is getting full and/or >>>>>>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>>>>>>>>>> The patch contains a detailed description + examples of the >>>>>>>>>>>>>> logic. I >>>>>>>>>>>>>> tested the patch >>>>>>>>>>>>>> with small code cache sizes (specjvm98 + <4m code cache), >>>>>>>>>>>>>> medium-sized >>>>>>>>>>>>>> code cache >>>>>>>>>>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>>>>>>>>>> octane). The measurements >>>>>>>>>>>>>> indicate that with the current logic in place, we can reduce the >>>>>>>>>>>>>> number of sweeps by 50% for >>>>>>>>>>>>>> medium code cache sizes without increasing the maximum used >>>>>>>>>>>>>> code cache >>>>>>>>>>>>>> size. The difference >>>>>>>>>>>>>> is more or less not significant. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please let me know what you think about it. The main >>>>>>>>>>>>>> disadvantage I >>>>>>>>>>>>>> see with this change is that >>>>>>>>>>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>>>>>>>>>> corresponding code. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>>>>>>>>>> redundant and can be removed. I am not quite sure if we >>>>>>>>>>>>>>>>>> should do >>>>>>>>>>>>>>>>>> that now so it is not included in the patch. >>>>>>>>>>>>>>>>> It is for separate change. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>>>>>>>>>> codecache sweeping because we loose performance since we go >>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>> Interpreter after codecache filled. Did you tried to run >>>>>>>>>>>>>>>>> with it >>>>>>>>>>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous >>>>>>>>>>>>>>>>> so you >>>>>>>>>>>>>>>>> can't remove it easily. But don't replace MethodFlushing >>>>>>>>>>>>>>>>> with it. I >>>>>>>>>>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>>>>>>>>>> executed unconditionally. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>>>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> jdk8 is major release so we can change flags. Add >>>>>>>>>>>>>>>>> MethodFlushing >>>>>>>>>>>>>>>>> there to remove it in jdk9: >>>>>>>>>>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), >>>>>>>>>>>>>>>>> JDK_Version::jdk(9) }, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> I'll file a new bug to remove the flag. I guess this change >>>>>>>>>>>>>> will most >>>>>>>>>>>>>> likely only make it into 8uXX. >>>>>>>>>>>>>>>>>> Testing >>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also >>>>>>>>>>>>>>>>>> shows a >>>>>>>>>>>>>>>>>> performance evaluation. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>>>> Albert >>>>> From igor.veresov at oracle.com Mon Nov 11 23:27:08 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 11 Nov 2013 23:27:08 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <705C3B37-78E4-4A29-82FB-F6FEA4219482@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> <5280897C.7000107@oracle.com> <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> <52812B90.8060609@oracle.com> <52813EF8.3060202@oracle.com> <72B4D395-49FA-4354-A9DD-1D6FFA408D93@oracle.com> <52815A34.1030004@oracle.com> <705C3B37-78E4-4A29-82FB-F6FEA4219482@oracle.com> Message-ID: <218A09A9-555C-4A0F-8790-961CBD8BC219@oracle.com> On Nov 11, 2013, at 9:54 PM, Albert Noll wrote: > Hi, > > thanks again for your thoughts. I will do the change as soon as I am in the office. > > Igor, can I count you as a reviewer? Yes, sure. igor > > Best, > Albert > > Von meinem iPhone gesendet > >> Am 11.11.2013 um 23:29 schrieb Vladimir Kozlov : >> >> Albert, >> >> I talked to Igor about this. >> And there is workaround for Chris's problem (-XX:-PrintWarnings). >> >> For this fix we need only print the warning once and that is it. >> Do NOT put it under flag (for repetitive printing). >> Remove new "Compiler has been enabled." message from your changes, we will have something when we will do CodeCache tracing later. >> >> Leave message as it is. >> >> Thanks, >> Vladimir >> >>> On 11/11/13 1:00 PM, Albert Noll wrote: >>> Hi, >>> >>> maybe there is no solution that fits all needs. >>> >>> The problem is somehow related to MaxNodeLimit. If we exceed the limit, the method is not compiled and we might therefore loose performance. In fact, I experienced that once during my PhD (it was a really large method that was generated by some tool) and I was wondering why Hotspot was so slow on that particular benchmark. >>> >>> So I think that having a warning (or some sort of messsge to the user) is important. Maybe - to keep it as simple as possible - we should print the message once. Maybe we should not even say that compilation is disabled, we just say that there might be a performance drop. It is true that compilation is disabled; but it is re-enabled shortly thereafter. >>> >>> What do you think about this? >>> >>> Albert >>> >>> >>> Von meinem iPhone gesendet >>> >>>> Am 11.11.2013 um 21:32 schrieb Vladimir Kozlov : >>>> >>>> Chris, >>>> >>>> I understand your situation. But there could be a customer who set ReservedCodeCacheSize 5 years ago (before Tiered Compilation). If we disable warning based on the command line flag he will be not notified that he out of space. >>>> >>>> How critical to not have the warning for embedded? >>>> >>>> ARRGGHH. It would be very very nice if 4 of sit together and talk about this. We need to make decision today so that Albert can push the fix. >>>> >>>> I am struggling myself about what the solution should be. >>>> >>>> On one hand with UseCodeCacheFlushing the warning is not important (and could be incorrect since we may continue compile). On other hand we need to notify user that he may be loosing performance because of small codecache. >>>> >>>> The solution could be, as Albert suggested, new product flag -XX:-PrintFullCodeCacheWarnings. But it is additional flag and we have tons of them already. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> On 11/11/13 11:10 AM, Chris Plummer wrote: >>>>> For users that that set ReservedCodeCacheSize to something lower than >>>>> the default, you probably want the single warning message off by >>>>> default, and otherwise want it on by default. >>>>> >>>>> Chris >>>>> >>>>>> On 11/11/13 8:00 AM, Albert Noll wrote: >>>>>> Hi Igor, >>>>>> >>>>>> Thanks for your input. I agree with you. Let me summarize what is >>>>>> being printed, just to make sure I get it right: >>>>>> >>>>>> Default behavior: Print warning once >>>>>> >>>>>> -XX:+PrintMethodFlushing: Print details (as listend above) with time >>>>>> stamps. >>>>>> >>>>>> Add option to remove all output. >>>>>> >>>>>> Is that correct? >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> Von meinem iPhone gesendet >>>>>> >>>>>>> Am 11.11.2013 um 09:39 schrieb Igor Veresov : >>>>>>> >>>>>>> >>>>>>>> On Nov 10, 2013, at 11:38 PM, Albert Noll >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Igor, >>>>>>>> >>>>>>>> thanks for looking into this. My only concern with printing the >>>>>>>> warning under -XX:+PrintCodeCache is >>>>>>>> that we change existing behavior of PrintCodeCache. If this is not >>>>>>>> an issue, I am fine with it. >>>>>>>> >>>>>>>> I think that the cleanest solution is to introduce a new product >>>>>>>> flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default that value >>>>>>>> to true. I would set the default value to true, >>>>>>>> since the code cache is not expected to become full with default >>>>>>>> code cache sizes. If the code cache >>>>>>>> becomes full nevertheless or the user sets a small code cache size >>>>>>>> we could print a warning like this: >>>>>>>> >>>>>>>>> Compiler was disabled because there is insufficient contiguous free >>>>>>>>> space in the code cache. >>>>>>>>> Free space: 2k requested size: 4k >>>>>>>>> Try to increase code cache with -XX:ReservedCodeCacheSize= or try >>>>>>>>> to increase code cache >>>>>>>>> sweeper activity with -XX:NmethodSweepActivity= (default value is 10). >>>>>>>>> Disable this warning with: -XX:-PrintFullCodeCacheWarnings >>>>>>> Hi Albert, >>>>>>> >>>>>>> Thanks for giving it a thought. My only concern with the previous >>>>>>> solution was printing the warning repeatedly every 10th time. I think >>>>>>> one time is enough to convey the message: "bump the size or you?re >>>>>>> loosing on performance?. Printing the warning repeatedly doesn?t >>>>>>> really provide any useful information because there is not much >>>>>>> context. It becomes useful when the user sees all the state >>>>>>> transitions: when the compilers were disabled and why, how much >>>>>>> methods were flushed and, as a result, how much space was freed, when >>>>>>> the compilers where re-enabled, what sweeping activity was there, >>>>>>> etc. May be this can be printed under PrintMethodFlushing without >>>>>>> Verbose? It would be also nice to have timestamps. People doing >>>>>>> performance analysis will really appreciate that. See PrintGCDetails >>>>>>> and PrintGCTimeStamps. May be there should be an option to disable >>>>>>> with warning altogether (so that it?s not printed even the first >>>>>>> time) for cases when the code cache size is constrained on purpose. >>>>>>> Most of this is probably for another change. >>>>>>> >>>>>>> TL;DR: may be print the warning once. >>>>>>> >>>>>>>> I would not print all the information that we print right now, >>>>>>>> because I think it is too detailed. >>>>>>>> E.g., I am not sure if it is helpful to print the bounds if the code >>>>>>>> cache. Also, I think we should >>>>>>>> substract CodeCacheMinimumFreeSpace from unallocated_capacity. It is >>>>>>>> confusing that we >>>>>>>> run out of code cache (and disable compilation) although there is >>>>>>>> still 500k left. >>>>>>> I agree, it is confusing. >>>>>>> >>>>>>> igor >>>>>>> >>>>>>>> Please let me know what you think. >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> >>>>>>>>> On 11/08/2013 11:44 PM, Igor Veresov wrote: >>>>>>>>> Hi Albert, >>>>>>>>> >>>>>>>>> I talked with Vladimir and we have a suggestion about the warning. >>>>>>>>> How about we print it only the first time by default and every time >>>>>>>>> if PrintCodeCache is set? The fact that it is printed even once >>>>>>>>> should suggest the user that the code cache size is something that >>>>>>>>> needs attention, and that the VM is already operating with the >>>>>>>>> constraint code cache space. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> igor >>>>>>>>> >>>>>>>>>> On Nov 8, 2013, at 7:32 AM, Albert Noll >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> thanks for looking at the patch. I hope that this version >>>>>>>>>> addresses all issues that >>>>>>>>>> you brought up. Here is a high-level overview of the changes since >>>>>>>>>> the last version: >>>>>>>>>> >>>>>>>>>> * We keep track of code cache state changes that also happen >>>>>>>>>> outside the sweeper. >>>>>>>>>> I re-installed notify, which is now called report_state_change() >>>>>>>>>> and is doing the job. >>>>>>>>>> report_state_change() checks if enough state has changed and >>>>>>>>>> enables the sweeper >>>>>>>>>> (it sets _should_sweep) to true. We reset _bytes_changed only >>>>>>>>>> once we have finished >>>>>>>>>> a while sweep cycle. That seems to make sense to me. >>>>>>>>>> >>>>>>>>>> * I added code that prints out every 10th warning that the >>>>>>>>>> compiler has been disabled. >>>>>>>>>> I also added a warning that compilation has been enabled again. >>>>>>>>>> I think if we print a message >>>>>>>>>> that compilation has been disabled, we should also print a >>>>>>>>>> message (maybe not a warning) >>>>>>>>>> that was enabled again. >>>>>>>>>> >>>>>>>>>> Here is the new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>>>>>> >>>>>>>>>>>> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>>>>>>>>>>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>>>>>>>>>> Nice work, Albert >>>>>>>>>>>> >>>>>>>>>>>> One concern is transition "alive -> not_entrant" is counted only >>>>>>>>>>>> when >>>>>>>>>>>> the nmethod needs to be flushed because you removed in notify() in >>>>>>>>>>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is >>>>>>>>>>>> called from >>>>>>>>>>>> other places. >>>>>>>>>>>> I think _bytes_changed should be updated by >>>>>>>>>>>> NMethodSweeper::notify() so >>>>>>>>>>>> don't remove it from nmethod.cpp. _bytes_changed should be reset >>>>>>>>>>>> when we >>>>>>>>>>>> finished sweep instead of before each sweep. >>>>>>>>>>> May be reset in both places actually. One to check that there >>>>>>>>>>> were updates between sweeps and an other during sweep (as you do >>>>>>>>>>> currently). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>>> Can you keep comments in code which initialize static variables >>>>>>>>>>>> (first >>>>>>>>>>>> changes in sweeper.cpp)? >>>>>>>>>>>> >>>>>>>>>>>> Please narrow your main comment, chars 90 chars per line. >>>>>>>>>>>> >>>>>>>>>>>> What is the second place? (initialization should not be count): >>>>>>>>>>>> >>>>>>>>>>>> + // of the two places where should_sweep can be set to true. >>>>>>>>>>>> >>>>>>>>>>>> You need to clear state in the comment conditions when we sweep. >>>>>>>>>>>> Like >>>>>>>>>>>> you did in the replay: >>>>>>>>>>>> >>>>>>>>>>>> (1) The code cache is getting full >>>>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>>>> (3) We have not been sweeping for 'some time' >>>>>>>>>>>> >>>>>>>>>>>> Split into 2 lines: >>>>>>>>>>>> >>>>>>>>>>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * >>>>>>>>>>>> M)) - >>>>>>>>>>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>>>>>>>>>> >>>>>>>>>>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>>>>>>>>>> The previous mail contains an error. See inline. >>>>>>>>>>>>> >>>>>>>>>>>>> Albert >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>>>>>>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please see comments inline. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>>>>>>>>>> Good idea. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- John (on my iPhone) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Looks good. It?s not related to the change, but could you >>>>>>>>>>>>>>>> please >>>>>>>>>>>>>>>> consider adding some printing under PrintMethodFlushing && >>>>>>>>>>>>>>>> Verbose >>>>>>>>>>>>>>>> for the case when the method is made not entrant and include >>>>>>>>>>>>>>>> hotness >>>>>>>>>>>>>>>> and threshold values? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> igor >>>>>>>>>>>>>> I also agree. I added the print. >>>>>>>>>>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>>>>>>>>>> are two issues that cause this regression: >>>>>>>>>>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>>>>>>>>>> result, NmethodSweepFraction remains 16 (if >>>>>>>>>>>>>>>>>> TieredCompilation is >>>>>>>>>>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to >>>>>>>>>>>>>>>>>> false. As a >>>>>>>>>>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>>>>>>>>>> called much more frequently. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that >>>>>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>>>>> always executed. >>>>>>>>>>>>>>>>> Good. >>>>>>>>>>>>>> The place where I moved the adaption of NmethodSweepFraction >>>>>>>>>>>>>> is not >>>>>>>>>>>>>> good, since the >>>>>>>>>>>>>> the code cache size is adapted later for tiered. The current >>>>>>>>>>>>>> version >>>>>>>>>>>>>> should be fine. >>>>>>>>>>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>>>>>>>>>> I think that these checks are not needed >>>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>>>>>>>>>> active nmethods irrespective of the >>>>>>>>>>>>>>>>>> value of >>>>>>>>>>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>>>>>>>>>> the patch removes need_marking_phase() >>>>>>>>>>>>>>>>>> printing >>>>>>>>>>>>>>>>>> out the warning (line 327 in >>>>>>>>>>>>>>>>>> sweeper.cpp) is incorrect, i.e., we >>>>>>>>>>>>>>>>>> continue to >>>>>>>>>>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>>>>>>>>>> and the associated code. >>>>>>>>>>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>>>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>>>> To do nmethod marking at each safepoint is fine (we have >>>>>>>>>>>>>>>>> to do it >>>>>>>>>>>>>>>>> to make sure we did not miss live nmethods). But with your >>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>>>>>>>>>> frequently? Why to sweep if there were no nmethods state >>>>>>>>>>>>>>>>> change and >>>>>>>>>>>>>>>>> there is enough space in CodeCache. So I am not sure about >>>>>>>>>>>>>>>>> removing >>>>>>>>>>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>>>>>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>>>>>>>>>> determine when we call the >>>>>>>>>>>>>> sweeper. The bottom line is that we do not invoke the sweeper >>>>>>>>>>>>>> only if: >>>>>>>>>>>>> !!!!We DO INVOKE the sweeper only if: >>>>>>>>>>>>>> (1) The code cache is getting full and/or >>>>>>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>>>>>>>>>> The patch contains a detailed description + examples of the >>>>>>>>>>>>>> logic. I >>>>>>>>>>>>>> tested the patch >>>>>>>>>>>>>> with small code cache sizes (specjvm98 + <4m code cache), >>>>>>>>>>>>>> medium-sized >>>>>>>>>>>>>> code cache >>>>>>>>>>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>>>>>>>>>> octane). The measurements >>>>>>>>>>>>>> indicate that with the current logic in place, we can reduce the >>>>>>>>>>>>>> number of sweeps by 50% for >>>>>>>>>>>>>> medium code cache sizes without increasing the maximum used >>>>>>>>>>>>>> code cache >>>>>>>>>>>>>> size. The difference >>>>>>>>>>>>>> is more or less not significant. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please let me know what you think about it. The main >>>>>>>>>>>>>> disadvantage I >>>>>>>>>>>>>> see with this change is that >>>>>>>>>>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>>>>>>>>>> corresponding code. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>>>>>>>>>> redundant and can be removed. I am not quite sure if we >>>>>>>>>>>>>>>>>> should do >>>>>>>>>>>>>>>>>> that now so it is not included in the patch. >>>>>>>>>>>>>>>>> It is for separate change. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>>>>>>>>>> codecache sweeping because we loose performance since we go >>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>> Interpreter after codecache filled. Did you tried to run >>>>>>>>>>>>>>>>> with it >>>>>>>>>>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous >>>>>>>>>>>>>>>>> so you >>>>>>>>>>>>>>>>> can't remove it easily. But don't replace MethodFlushing >>>>>>>>>>>>>>>>> with it. I >>>>>>>>>>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>>>>>>>>>> executed unconditionally. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>>>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> jdk8 is major release so we can change flags. Add >>>>>>>>>>>>>>>>> MethodFlushing >>>>>>>>>>>>>>>>> there to remove it in jdk9: >>>>>>>>>>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), >>>>>>>>>>>>>>>>> JDK_Version::jdk(9) }, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> I'll file a new bug to remove the flag. I guess this change >>>>>>>>>>>>>> will most >>>>>>>>>>>>>> likely only make it into 8uXX. >>>>>>>>>>>>>>>>>> Testing >>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also >>>>>>>>>>>>>>>>>> shows a >>>>>>>>>>>>>>>>>> performance evaluation. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>>>> Albert >>>>> >>>>> From vladimir.kozlov at oracle.com Mon Nov 11 23:38:24 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Nov 2013 23:38:24 -0800 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <5281D778.9050303@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> <5280897C.7000107@oracle.com> <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> <52812B90.8060609@oracle.com> <52813EF8.3060202@oracle.com> <72B4D395-49FA-4354-A9DD-1D6FFA408D93@oracle.com> <52815A34.1030004@oracle.com> <705C3B37-78E4-4A29-82FB-F6FEA4219482@oracle.com> <5281D778.9050303@oracle.com> Message-ID: <5281DAF0.2010707@oracle.com> Looks good. Thanks, Vladimir On 11/11/13 11:23 PM, Albert Noll wrote: > Hi, > > here is the updated webrev: > http://cr.openjdk.java.net/~anoll/8027593/webrev.03/ > > The warning is now only printed once. > > I'll file an RFE to do proper logging of full code cache behavior. > > Best, > Albert > > > On 11/12/2013 06:54 AM, Albert Noll wrote: >> Hi, >> >> thanks again for your thoughts. I will do the change as soon as I am in the office. >> >> Igor, can I count you as a reviewer? >> >> Best, >> Albert >> >> Von meinem iPhone gesendet >> >>> Am 11.11.2013 um 23:29 schrieb Vladimir Kozlov : >>> >>> Albert, >>> >>> I talked to Igor about this. >>> And there is workaround for Chris's problem (-XX:-PrintWarnings). >>> >>> For this fix we need only print the warning once and that is it. >>> Do NOT put it under flag (for repetitive printing). >>> Remove new "Compiler has been enabled." message from your changes, we will have something when we will do CodeCache >>> tracing later. >>> >>> Leave message as it is. >>> >>> Thanks, >>> Vladimir >>> >>>> On 11/11/13 1:00 PM, Albert Noll wrote: >>>> Hi, >>>> >>>> maybe there is no solution that fits all needs. >>>> >>>> The problem is somehow related to MaxNodeLimit. If we exceed the limit, the method is not compiled and we might >>>> therefore loose performance. In fact, I experienced that once during my PhD (it was a really large method that was >>>> generated by some tool) and I was wondering why Hotspot was so slow on that particular benchmark. >>>> >>>> So I think that having a warning (or some sort of messsge to the user) is important. Maybe - to keep it as simple as >>>> possible - we should print the message once. Maybe we should not even say that compilation is disabled, we just say >>>> that there might be a performance drop. It is true that compilation is disabled; but it is re-enabled shortly >>>> thereafter. >>>> >>>> What do you think about this? >>>> >>>> Albert >>>> >>>> >>>> Von meinem iPhone gesendet >>>> >>>>> Am 11.11.2013 um 21:32 schrieb Vladimir Kozlov : >>>>> >>>>> Chris, >>>>> >>>>> I understand your situation. But there could be a customer who set ReservedCodeCacheSize 5 years ago (before Tiered >>>>> Compilation). If we disable warning based on the command line flag he will be not notified that he out of space. >>>>> >>>>> How critical to not have the warning for embedded? >>>>> >>>>> ARRGGHH. It would be very very nice if 4 of sit together and talk about this. We need to make decision today so >>>>> that Albert can push the fix. >>>>> >>>>> I am struggling myself about what the solution should be. >>>>> >>>>> On one hand with UseCodeCacheFlushing the warning is not important (and could be incorrect since we may continue >>>>> compile). On other hand we need to notify user that he may be loosing performance because of small codecache. >>>>> >>>>> The solution could be, as Albert suggested, new product flag -XX:-PrintFullCodeCacheWarnings. But it is additional >>>>> flag and we have tons of them already. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> On 11/11/13 11:10 AM, Chris Plummer wrote: >>>>>> For users that that set ReservedCodeCacheSize to something lower than >>>>>> the default, you probably want the single warning message off by >>>>>> default, and otherwise want it on by default. >>>>>> >>>>>> Chris >>>>>> >>>>>>> On 11/11/13 8:00 AM, Albert Noll wrote: >>>>>>> Hi Igor, >>>>>>> >>>>>>> Thanks for your input. I agree with you. Let me summarize what is >>>>>>> being printed, just to make sure I get it right: >>>>>>> >>>>>>> Default behavior: Print warning once >>>>>>> >>>>>>> -XX:+PrintMethodFlushing: Print details (as listend above) with time >>>>>>> stamps. >>>>>>> >>>>>>> Add option to remove all output. >>>>>>> >>>>>>> Is that correct? >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> Von meinem iPhone gesendet >>>>>>> >>>>>>>> Am 11.11.2013 um 09:39 schrieb Igor Veresov : >>>>>>>> >>>>>>>> >>>>>>>>> On Nov 10, 2013, at 11:38 PM, Albert Noll >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Igor, >>>>>>>>> >>>>>>>>> thanks for looking into this. My only concern with printing the >>>>>>>>> warning under -XX:+PrintCodeCache is >>>>>>>>> that we change existing behavior of PrintCodeCache. If this is not >>>>>>>>> an issue, I am fine with it. >>>>>>>>> >>>>>>>>> I think that the cleanest solution is to introduce a new product >>>>>>>>> flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default that value >>>>>>>>> to true. I would set the default value to true, >>>>>>>>> since the code cache is not expected to become full with default >>>>>>>>> code cache sizes. If the code cache >>>>>>>>> becomes full nevertheless or the user sets a small code cache size >>>>>>>>> we could print a warning like this: >>>>>>>>> >>>>>>>>>> Compiler was disabled because there is insufficient contiguous free >>>>>>>>>> space in the code cache. >>>>>>>>>> Free space: 2k requested size: 4k >>>>>>>>>> Try to increase code cache with -XX:ReservedCodeCacheSize= or try >>>>>>>>>> to increase code cache >>>>>>>>>> sweeper activity with -XX:NmethodSweepActivity= (default value is 10). >>>>>>>>>> Disable this warning with: -XX:-PrintFullCodeCacheWarnings >>>>>>>> Hi Albert, >>>>>>>> >>>>>>>> Thanks for giving it a thought. My only concern with the previous >>>>>>>> solution was printing the warning repeatedly every 10th time. I think >>>>>>>> one time is enough to convey the message: "bump the size or you?re >>>>>>>> loosing on performance?. Printing the warning repeatedly doesn?t >>>>>>>> really provide any useful information because there is not much >>>>>>>> context. It becomes useful when the user sees all the state >>>>>>>> transitions: when the compilers were disabled and why, how much >>>>>>>> methods were flushed and, as a result, how much space was freed, when >>>>>>>> the compilers where re-enabled, what sweeping activity was there, >>>>>>>> etc. May be this can be printed under PrintMethodFlushing without >>>>>>>> Verbose? It would be also nice to have timestamps. People doing >>>>>>>> performance analysis will really appreciate that. See PrintGCDetails >>>>>>>> and PrintGCTimeStamps. May be there should be an option to disable >>>>>>>> with warning altogether (so that it?s not printed even the first >>>>>>>> time) for cases when the code cache size is constrained on purpose. >>>>>>>> Most of this is probably for another change. >>>>>>>> >>>>>>>> TL;DR: may be print the warning once. >>>>>>>> >>>>>>>>> I would not print all the information that we print right now, >>>>>>>>> because I think it is too detailed. >>>>>>>>> E.g., I am not sure if it is helpful to print the bounds if the code >>>>>>>>> cache. Also, I think we should >>>>>>>>> substract CodeCacheMinimumFreeSpace from unallocated_capacity. It is >>>>>>>>> confusing that we >>>>>>>>> run out of code cache (and disable compilation) although there is >>>>>>>>> still 500k left. >>>>>>>> I agree, it is confusing. >>>>>>>> >>>>>>>> igor >>>>>>>> >>>>>>>>> Please let me know what you think. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 11/08/2013 11:44 PM, Igor Veresov wrote: >>>>>>>>>> Hi Albert, >>>>>>>>>> >>>>>>>>>> I talked with Vladimir and we have a suggestion about the warning. >>>>>>>>>> How about we print it only the first time by default and every time >>>>>>>>>> if PrintCodeCache is set? The fact that it is printed even once >>>>>>>>>> should suggest the user that the code cache size is something that >>>>>>>>>> needs attention, and that the VM is already operating with the >>>>>>>>>> constraint code cache space. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> igor >>>>>>>>>> >>>>>>>>>>> On Nov 8, 2013, at 7:32 AM, Albert Noll >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Vladimir, >>>>>>>>>>> >>>>>>>>>>> thanks for looking at the patch. I hope that this version >>>>>>>>>>> addresses all issues that >>>>>>>>>>> you brought up. Here is a high-level overview of the changes since >>>>>>>>>>> the last version: >>>>>>>>>>> >>>>>>>>>>> * We keep track of code cache state changes that also happen >>>>>>>>>>> outside the sweeper. >>>>>>>>>>> I re-installed notify, which is now called report_state_change() >>>>>>>>>>> and is doing the job. >>>>>>>>>>> report_state_change() checks if enough state has changed and >>>>>>>>>>> enables the sweeper >>>>>>>>>>> (it sets _should_sweep) to true. We reset _bytes_changed only >>>>>>>>>>> once we have finished >>>>>>>>>>> a while sweep cycle. That seems to make sense to me. >>>>>>>>>>> >>>>>>>>>>> * I added code that prints out every 10th warning that the >>>>>>>>>>> compiler has been disabled. >>>>>>>>>>> I also added a warning that compilation has been enabled again. >>>>>>>>>>> I think if we print a message >>>>>>>>>>> that compilation has been disabled, we should also print a >>>>>>>>>>> message (maybe not a warning) >>>>>>>>>>> that was enabled again. >>>>>>>>>>> >>>>>>>>>>> Here is the new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Albert >>>>>>>>>>> >>>>>>>>>>>>> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>> Nice work, Albert >>>>>>>>>>>>> >>>>>>>>>>>>> One concern is transition "alive -> not_entrant" is counted only >>>>>>>>>>>>> when >>>>>>>>>>>>> the nmethod needs to be flushed because you removed in notify() in >>>>>>>>>>>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is >>>>>>>>>>>>> called from >>>>>>>>>>>>> other places. >>>>>>>>>>>>> I think _bytes_changed should be updated by >>>>>>>>>>>>> NMethodSweeper::notify() so >>>>>>>>>>>>> don't remove it from nmethod.cpp. _bytes_changed should be reset >>>>>>>>>>>>> when we >>>>>>>>>>>>> finished sweep instead of before each sweep. >>>>>>>>>>>> May be reset in both places actually. One to check that there >>>>>>>>>>>> were updates between sweeps and an other during sweep (as you do >>>>>>>>>>>> currently). >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>>> Can you keep comments in code which initialize static variables >>>>>>>>>>>>> (first >>>>>>>>>>>>> changes in sweeper.cpp)? >>>>>>>>>>>>> >>>>>>>>>>>>> Please narrow your main comment, chars 90 chars per line. >>>>>>>>>>>>> >>>>>>>>>>>>> What is the second place? (initialization should not be count): >>>>>>>>>>>>> >>>>>>>>>>>>> + // of the two places where should_sweep can be set to true. >>>>>>>>>>>>> >>>>>>>>>>>>> You need to clear state in the comment conditions when we sweep. >>>>>>>>>>>>> Like >>>>>>>>>>>>> you did in the replay: >>>>>>>>>>>>> >>>>>>>>>>>>> (1) The code cache is getting full >>>>>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>>>>> (3) We have not been sweeping for 'some time' >>>>>>>>>>>>> >>>>>>>>>>>>> Split into 2 lines: >>>>>>>>>>>>> >>>>>>>>>>>>> + int wait_until_next_sweep = (ReservedCodeCacheSize / (16 * >>>>>>>>>>>>> M)) - >>>>>>>>>>>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>>>>>>>>>>> >>>>>>>>>>>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>>>>>>>>>>> The previous mail contains an error. See inline. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Albert >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>>>>>>>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please see comments inline. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>>>>>>>>>>> Good idea. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- John (on my iPhone) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Looks good. It?s not related to the change, but could you >>>>>>>>>>>>>>>>> please >>>>>>>>>>>>>>>>> consider adding some printing under PrintMethodFlushing && >>>>>>>>>>>>>>>>> Verbose >>>>>>>>>>>>>>>>> for the case when the method is made not entrant and include >>>>>>>>>>>>>>>>> hotness >>>>>>>>>>>>>>>>> and threshold values? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> igor >>>>>>>>>>>>>>> I also agree. I added the print. >>>>>>>>>>>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Problem: The implementation of the sweeper (8020151) causes a >>>>>>>>>>>>>>>>>>> performance regression for small code cache sizes. There >>>>>>>>>>>>>>>>>>> are two issues that cause this regression: >>>>>>>>>>>>>>>>>>> 1) NmethodSweepFraction is only adjusted according to the >>>>>>>>>>>>>>>>>>> ReservedCodecacheSize if TieredCompilation is enabled. As a >>>>>>>>>>>>>>>>>>> result, NmethodSweepFraction remains 16 (if >>>>>>>>>>>>>>>>>>> TieredCompilation is >>>>>>>>>>>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>>>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>>>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to >>>>>>>>>>>>>>>>>>> false. As a >>>>>>>>>>>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>>>>>>>>>>> _invocations and _current, which results in not invoking the >>>>>>>>>>>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>>>>>>>>>>> TieredCompilation is enabled this was not an issue, since >>>>>>>>>>>>>>>>>>> NmethodSweeper::notify() (which sets _request_mark_phase) is >>>>>>>>>>>>>>>>>>> called much more frequently. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction so that >>>>>>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>>>>>> always executed. >>>>>>>>>>>>>>>>>> Good. >>>>>>>>>>>>>>> The place where I moved the adaption of NmethodSweepFraction >>>>>>>>>>>>>>> is not >>>>>>>>>>>>>>> good, since the >>>>>>>>>>>>>>> the code cache size is adapted later for tiered. The current >>>>>>>>>>>>>>> version >>>>>>>>>>>>>>> should be fine. >>>>>>>>>>>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>>>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>>>>>>>>>>> I think that these checks are not needed >>>>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>>>>>>>>>>> active nmethods irrespective of the >>>>>>>>>>>>>>>>>>> value of >>>>>>>>>>>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>>>>>>>>>>> the patch removes need_marking_phase() >>>>>>>>>>>>>>>>>>> printing >>>>>>>>>>>>>>>>>>> out the warning (line 327 in >>>>>>>>>>>>>>>>>>> sweeper.cpp) is incorrect, i.e., we >>>>>>>>>>>>>>>>>>> continue to >>>>>>>>>>>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>>>>>>>>>>> and the associated code. >>>>>>>>>>>>>>>>>> Don't put mark_active_nmethods() under !UseCodeCacheFlushing >>>>>>>>>>>>>>>>>> condition. We always want to reclaim space in codecache. >>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>>>>> To do nmethod marking at each safepoint is fine (we have >>>>>>>>>>>>>>>>>> to do it >>>>>>>>>>>>>>>>>> to make sure we did not miss live nmethods). But with your >>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>> each safepoint triggers sweep. Do we really need sweep so >>>>>>>>>>>>>>>>>> frequently? Why to sweep if there were no nmethods state >>>>>>>>>>>>>>>>>> change and >>>>>>>>>>>>>>>>>> there is enough space in CodeCache. So I am not sure about >>>>>>>>>>>>>>>>>> removing >>>>>>>>>>>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>>>>>>>>>> I agree. The current patch contains a more sophisticated logic to >>>>>>>>>>>>>>> determine when we call the >>>>>>>>>>>>>>> sweeper. The bottom line is that we do not invoke the sweeper >>>>>>>>>>>>>>> only if: >>>>>>>>>>>>>> !!!!We DO INVOKE the sweeper only if: >>>>>>>>>>>>>>> (1) The code cache is getting full and/or >>>>>>>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>>>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>>>>>>>>>>> The patch contains a detailed description + examples of the >>>>>>>>>>>>>>> logic. I >>>>>>>>>>>>>>> tested the patch >>>>>>>>>>>>>>> with small code cache sizes (specjvm98 + <4m code cache), >>>>>>>>>>>>>>> medium-sized >>>>>>>>>>>>>>> code cache >>>>>>>>>>>>>>> (128m + nashorn + octane), and large code cache (240m + nashorn + >>>>>>>>>>>>>>> octane). The measurements >>>>>>>>>>>>>>> indicate that with the current logic in place, we can reduce the >>>>>>>>>>>>>>> number of sweeps by 50% for >>>>>>>>>>>>>>> medium code cache sizes without increasing the maximum used >>>>>>>>>>>>>>> code cache >>>>>>>>>>>>>>> size. The difference >>>>>>>>>>>>>>> is more or less not significant. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please let me know what you think about it. The main >>>>>>>>>>>>>>> disadvantage I >>>>>>>>>>>>>>> see with this change is that >>>>>>>>>>>>>>> it makes reasoning about the sweeper harder than it was before. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>>>>>>>>>>> corresponding code. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also, I think that we can either remove -XX:MethodFlushing or >>>>>>>>>>>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of them is >>>>>>>>>>>>>>>>>>> redundant and can be removed. I am not quite sure if we >>>>>>>>>>>>>>>>>>> should do >>>>>>>>>>>>>>>>>>> that now so it is not included in the patch. >>>>>>>>>>>>>>>>>> It is for separate change. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> MethodFlushing is obsolete because we can not run VM without >>>>>>>>>>>>>>>>>> codecache sweeping because we loose performance since we go >>>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>>> Interpreter after codecache filled. Did you tried to run >>>>>>>>>>>>>>>>>> with it >>>>>>>>>>>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The problem with UseCodeCacheFlushing is it becomes famous >>>>>>>>>>>>>>>>>> so you >>>>>>>>>>>>>>>>>> can't remove it easily. But don't replace MethodFlushing >>>>>>>>>>>>>>>>>> with it. I >>>>>>>>>>>>>>>>>> think code which currently guarded by MethodFlushing should be >>>>>>>>>>>>>>>>>> executed unconditionally. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>>>>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> jdk8 is major release so we can change flags. Add >>>>>>>>>>>>>>>>>> MethodFlushing >>>>>>>>>>>>>>>>>> there to remove it in jdk9: >>>>>>>>>>>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), >>>>>>>>>>>>>>>>>> JDK_Version::jdk(9) }, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>> I'll file a new bug to remove the flag. I guess this change >>>>>>>>>>>>>>> will most >>>>>>>>>>>>>>> likely only make it into 8uXX. >>>>>>>>>>>>>>>>>>> Testing >>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 also >>>>>>>>>>>>>>>>>>> shows a >>>>>>>>>>>>>>>>>>> performance evaluation. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>>>>> Albert >>>>>> > From albert.noll at oracle.com Mon Nov 11 23:45:52 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 12 Nov 2013 08:45:52 +0100 Subject: RFR(S): 8027593: performance drop with constrained codecache starting with hs25 b111 In-Reply-To: <5281DAF0.2010707@oracle.com> References: <52790459.7050607@oracle.com> <5279344F.2060600@oracle.com> <22A37955-1C1F-407F-9DB3-71B0CFB322BE@oracle.com> <293FF75E-CE03-4948-AAC8-B92B8DECCA78@oracle.com> <527B7760.6040805@oracle.com> <527B7907.4040102@oracle.com> <527C07EE.3040804@oracle.com> <527C0E62.8070201@oracle.com> <527D03FD.2010104@oracle.com> <0EE5D4E8-954A-4385-8FC1-899071B5A8EE@oracle.com> <5280897C.7000107@oracle.com> <2F4248BD-4761-4AC7-A5C3-9BFF63963087@oracle.com> <1490FFA4-ADD7-4F8C-BFCC-EA8DCE1F0200@oracle.com> <52812B90.8060609@oracle.com> <52813EF8.3060202@oracle.com> <72B4D395-49FA-4354-A9DD-1D6FFA408D93@oracle.com> <52815A34.1030004@oracle.com> <705C3B37-78E4-4A29-82FB-F6FEA4219482@oracle.com> <5281D778.9050303@oracle.com> <5281DAF0.2010707@oracle.com> Message-ID: <5281DCB0.9030808@oracle.com> Vladimir, Igor, thanks for reviewing this. Best, Albert On 11/12/2013 08:38 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 11/11/13 11:23 PM, Albert Noll wrote: >> Hi, >> >> here is the updated webrev: >> http://cr.openjdk.java.net/~anoll/8027593/webrev.03/ >> >> The warning is now only printed once. >> >> I'll file an RFE to do proper logging of full code cache behavior. >> >> Best, >> Albert >> >> >> On 11/12/2013 06:54 AM, Albert Noll wrote: >>> Hi, >>> >>> thanks again for your thoughts. I will do the change as soon as I am >>> in the office. >>> >>> Igor, can I count you as a reviewer? >>> >>> Best, >>> Albert >>> >>> Von meinem iPhone gesendet >>> >>>> Am 11.11.2013 um 23:29 schrieb Vladimir Kozlov >>>> : >>>> >>>> Albert, >>>> >>>> I talked to Igor about this. >>>> And there is workaround for Chris's problem (-XX:-PrintWarnings). >>>> >>>> For this fix we need only print the warning once and that is it. >>>> Do NOT put it under flag (for repetitive printing). >>>> Remove new "Compiler has been enabled." message from your changes, >>>> we will have something when we will do CodeCache >>>> tracing later. >>>> >>>> Leave message as it is. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> On 11/11/13 1:00 PM, Albert Noll wrote: >>>>> Hi, >>>>> >>>>> maybe there is no solution that fits all needs. >>>>> >>>>> The problem is somehow related to MaxNodeLimit. If we exceed the >>>>> limit, the method is not compiled and we might >>>>> therefore loose performance. In fact, I experienced that once >>>>> during my PhD (it was a really large method that was >>>>> generated by some tool) and I was wondering why Hotspot was so >>>>> slow on that particular benchmark. >>>>> >>>>> So I think that having a warning (or some sort of messsge to the >>>>> user) is important. Maybe - to keep it as simple as >>>>> possible - we should print the message once. Maybe we should not >>>>> even say that compilation is disabled, we just say >>>>> that there might be a performance drop. It is true that >>>>> compilation is disabled; but it is re-enabled shortly >>>>> thereafter. >>>>> >>>>> What do you think about this? >>>>> >>>>> Albert >>>>> >>>>> >>>>> Von meinem iPhone gesendet >>>>> >>>>>> Am 11.11.2013 um 21:32 schrieb Vladimir Kozlov >>>>>> : >>>>>> >>>>>> Chris, >>>>>> >>>>>> I understand your situation. But there could be a customer who >>>>>> set ReservedCodeCacheSize 5 years ago (before Tiered >>>>>> Compilation). If we disable warning based on the command line >>>>>> flag he will be not notified that he out of space. >>>>>> >>>>>> How critical to not have the warning for embedded? >>>>>> >>>>>> ARRGGHH. It would be very very nice if 4 of sit together and talk >>>>>> about this. We need to make decision today so >>>>>> that Albert can push the fix. >>>>>> >>>>>> I am struggling myself about what the solution should be. >>>>>> >>>>>> On one hand with UseCodeCacheFlushing the warning is not >>>>>> important (and could be incorrect since we may continue >>>>>> compile). On other hand we need to notify user that he may be >>>>>> loosing performance because of small codecache. >>>>>> >>>>>> The solution could be, as Albert suggested, new product flag >>>>>> -XX:-PrintFullCodeCacheWarnings. But it is additional >>>>>> flag and we have tons of them already. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> On 11/11/13 11:10 AM, Chris Plummer wrote: >>>>>>> For users that that set ReservedCodeCacheSize to something lower >>>>>>> than >>>>>>> the default, you probably want the single warning message off by >>>>>>> default, and otherwise want it on by default. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>>> On 11/11/13 8:00 AM, Albert Noll wrote: >>>>>>>> Hi Igor, >>>>>>>> >>>>>>>> Thanks for your input. I agree with you. Let me summarize what is >>>>>>>> being printed, just to make sure I get it right: >>>>>>>> >>>>>>>> Default behavior: Print warning once >>>>>>>> >>>>>>>> -XX:+PrintMethodFlushing: Print details (as listend above) with >>>>>>>> time >>>>>>>> stamps. >>>>>>>> >>>>>>>> Add option to remove all output. >>>>>>>> >>>>>>>> Is that correct? >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> Von meinem iPhone gesendet >>>>>>>> >>>>>>>>> Am 11.11.2013 um 09:39 schrieb Igor Veresov >>>>>>>>> : >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Nov 10, 2013, at 11:38 PM, Albert Noll >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Igor, >>>>>>>>>> >>>>>>>>>> thanks for looking into this. My only concern with printing the >>>>>>>>>> warning under -XX:+PrintCodeCache is >>>>>>>>>> that we change existing behavior of PrintCodeCache. If this >>>>>>>>>> is not >>>>>>>>>> an issue, I am fine with it. >>>>>>>>>> >>>>>>>>>> I think that the cleanest solution is to introduce a new product >>>>>>>>>> flag, (e.g., -XX:+PrintFullCodeCacheWarnings) and default >>>>>>>>>> that value >>>>>>>>>> to true. I would set the default value to true, >>>>>>>>>> since the code cache is not expected to become full with default >>>>>>>>>> code cache sizes. If the code cache >>>>>>>>>> becomes full nevertheless or the user sets a small code cache >>>>>>>>>> size >>>>>>>>>> we could print a warning like this: >>>>>>>>>> >>>>>>>>>>> Compiler was disabled because there is insufficient >>>>>>>>>>> contiguous free >>>>>>>>>>> space in the code cache. >>>>>>>>>>> Free space: 2k requested size: 4k >>>>>>>>>>> Try to increase code cache with -XX:ReservedCodeCacheSize= >>>>>>>>>>> or try >>>>>>>>>>> to increase code cache >>>>>>>>>>> sweeper activity with -XX:NmethodSweepActivity= (default >>>>>>>>>>> value is 10). >>>>>>>>>>> Disable this warning with: -XX:-PrintFullCodeCacheWarnings >>>>>>>>> Hi Albert, >>>>>>>>> >>>>>>>>> Thanks for giving it a thought. My only concern with the previous >>>>>>>>> solution was printing the warning repeatedly every 10th time. >>>>>>>>> I think >>>>>>>>> one time is enough to convey the message: "bump the size or >>>>>>>>> you?re >>>>>>>>> loosing on performance?. Printing the warning repeatedly doesn?t >>>>>>>>> really provide any useful information because there is not much >>>>>>>>> context. It becomes useful when the user sees all the state >>>>>>>>> transitions: when the compilers were disabled and why, how much >>>>>>>>> methods were flushed and, as a result, how much space was >>>>>>>>> freed, when >>>>>>>>> the compilers where re-enabled, what sweeping activity was there, >>>>>>>>> etc. May be this can be printed under PrintMethodFlushing without >>>>>>>>> Verbose? It would be also nice to have timestamps. People doing >>>>>>>>> performance analysis will really appreciate that. See >>>>>>>>> PrintGCDetails >>>>>>>>> and PrintGCTimeStamps. May be there should be an option to >>>>>>>>> disable >>>>>>>>> with warning altogether (so that it?s not printed even the first >>>>>>>>> time) for cases when the code cache size is constrained on >>>>>>>>> purpose. >>>>>>>>> Most of this is probably for another change. >>>>>>>>> >>>>>>>>> TL;DR: may be print the warning once. >>>>>>>>> >>>>>>>>>> I would not print all the information that we print right now, >>>>>>>>>> because I think it is too detailed. >>>>>>>>>> E.g., I am not sure if it is helpful to print the bounds if >>>>>>>>>> the code >>>>>>>>>> cache. Also, I think we should >>>>>>>>>> substract CodeCacheMinimumFreeSpace from >>>>>>>>>> unallocated_capacity. It is >>>>>>>>>> confusing that we >>>>>>>>>> run out of code cache (and disable compilation) although >>>>>>>>>> there is >>>>>>>>>> still 500k left. >>>>>>>>> I agree, it is confusing. >>>>>>>>> >>>>>>>>> igor >>>>>>>>> >>>>>>>>>> Please let me know what you think. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 11/08/2013 11:44 PM, Igor Veresov wrote: >>>>>>>>>>> Hi Albert, >>>>>>>>>>> >>>>>>>>>>> I talked with Vladimir and we have a suggestion about the >>>>>>>>>>> warning. >>>>>>>>>>> How about we print it only the first time by default and >>>>>>>>>>> every time >>>>>>>>>>> if PrintCodeCache is set? The fact that it is printed even once >>>>>>>>>>> should suggest the user that the code cache size is >>>>>>>>>>> something that >>>>>>>>>>> needs attention, and that the VM is already operating with the >>>>>>>>>>> constraint code cache space. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> igor >>>>>>>>>>> >>>>>>>>>>>> On Nov 8, 2013, at 7:32 AM, Albert Noll >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Vladimir, >>>>>>>>>>>> >>>>>>>>>>>> thanks for looking at the patch. I hope that this version >>>>>>>>>>>> addresses all issues that >>>>>>>>>>>> you brought up. Here is a high-level overview of the >>>>>>>>>>>> changes since >>>>>>>>>>>> the last version: >>>>>>>>>>>> >>>>>>>>>>>> * We keep track of code cache state changes that also happen >>>>>>>>>>>> outside the sweeper. >>>>>>>>>>>> I re-installed notify, which is now called >>>>>>>>>>>> report_state_change() >>>>>>>>>>>> and is doing the job. >>>>>>>>>>>> report_state_change() checks if enough state has changed and >>>>>>>>>>>> enables the sweeper >>>>>>>>>>>> (it sets _should_sweep) to true. We reset _bytes_changed >>>>>>>>>>>> only >>>>>>>>>>>> once we have finished >>>>>>>>>>>> a while sweep cycle. That seems to make sense to me. >>>>>>>>>>>> >>>>>>>>>>>> * I added code that prints out every 10th warning that the >>>>>>>>>>>> compiler has been disabled. >>>>>>>>>>>> I also added a warning that compilation has been enabled >>>>>>>>>>>> again. >>>>>>>>>>>> I think if we print a message >>>>>>>>>>>> that compilation has been disabled, we should also print a >>>>>>>>>>>> message (maybe not a warning) >>>>>>>>>>>> that was enabled again. >>>>>>>>>>>> >>>>>>>>>>>> Here is the new webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.02/ >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> Albert >>>>>>>>>>>> >>>>>>>>>>>>>> On 11/07/2013 11:04 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>>> On 11/7/13 1:36 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>>> Nice work, Albert >>>>>>>>>>>>>> >>>>>>>>>>>>>> One concern is transition "alive -> not_entrant" is >>>>>>>>>>>>>> counted only >>>>>>>>>>>>>> when >>>>>>>>>>>>>> the nmethod needs to be flushed because you removed in >>>>>>>>>>>>>> notify() in >>>>>>>>>>>>>> nmethod::make_not_entrant_or_zombie(). Also make_zombie() is >>>>>>>>>>>>>> called from >>>>>>>>>>>>>> other places. >>>>>>>>>>>>>> I think _bytes_changed should be updated by >>>>>>>>>>>>>> NMethodSweeper::notify() so >>>>>>>>>>>>>> don't remove it from nmethod.cpp. _bytes_changed should >>>>>>>>>>>>>> be reset >>>>>>>>>>>>>> when we >>>>>>>>>>>>>> finished sweep instead of before each sweep. >>>>>>>>>>>>> May be reset in both places actually. One to check that there >>>>>>>>>>>>> were updates between sweeps and an other during sweep (as >>>>>>>>>>>>> you do >>>>>>>>>>>>> currently). >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>>> Can you keep comments in code which initialize static >>>>>>>>>>>>>> variables >>>>>>>>>>>>>> (first >>>>>>>>>>>>>> changes in sweeper.cpp)? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please narrow your main comment, chars 90 chars per line. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What is the second place? (initialization should not be >>>>>>>>>>>>>> count): >>>>>>>>>>>>>> >>>>>>>>>>>>>> + // of the two places where should_sweep can be set to >>>>>>>>>>>>>> true. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You need to clear state in the comment conditions when we >>>>>>>>>>>>>> sweep. >>>>>>>>>>>>>> Like >>>>>>>>>>>>>> you did in the replay: >>>>>>>>>>>>>> >>>>>>>>>>>>>> (1) The code cache is getting full >>>>>>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>>>>>> (3) We have not been sweeping for 'some time' >>>>>>>>>>>>>> >>>>>>>>>>>>>> Split into 2 lines: >>>>>>>>>>>>>> >>>>>>>>>>>>>> + int wait_until_next_sweep = (ReservedCodeCacheSize >>>>>>>>>>>>>> / (16 * >>>>>>>>>>>>>> M)) - >>>>>>>>>>>>>> time_since_last_sweep - CodeCache::reverse_free_ratio(); >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the print format do not use %p, use PTR_FORMAT for 'nm'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/7/13 3:27 AM, Albert Noll wrote: >>>>>>>>>>>>>>> The previous mail contains an error. See inline. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Albert >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/07/2013 12:20 PM, Albert Noll wrote: >>>>>>>>>>>>>>>> Vladimir, Igor, John, thanks for looking at the patch. >>>>>>>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.01/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please see comments inline. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 11/06/2013 02:52 AM, John Rose wrote: >>>>>>>>>>>>>>>>> Good idea. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- John (on my iPhone) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Nov 5, 2013, at 3:11 PM, Igor Veresov >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Looks good. It?s not related to the change, but could >>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>> please >>>>>>>>>>>>>>>>>> consider adding some printing under >>>>>>>>>>>>>>>>>> PrintMethodFlushing && >>>>>>>>>>>>>>>>>> Verbose >>>>>>>>>>>>>>>>>> for the case when the method is made not entrant and >>>>>>>>>>>>>>>>>> include >>>>>>>>>>>>>>>>>> hotness >>>>>>>>>>>>>>>>>> and threshold values? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> igor >>>>>>>>>>>>>>>> I also agree. I added the print. >>>>>>>>>>>>>>>>>> On Nov 5, 2013, at 10:09 AM, Vladimir Kozlov >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 11/5/13 6:44 AM, Albert Noll wrote: >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027593 >>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8027593/webrev.00/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Problem: The implementation of the sweeper >>>>>>>>>>>>>>>>>>>> (8020151) causes a >>>>>>>>>>>>>>>>>>>> performance regression for small code cache sizes. >>>>>>>>>>>>>>>>>>>> There >>>>>>>>>>>>>>>>>>>> are two issues that cause this regression: >>>>>>>>>>>>>>>>>>>> 1) NmethodSweepFraction is only adjusted according >>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>> ReservedCodecacheSize if TieredCompilation is >>>>>>>>>>>>>>>>>>>> enabled. As a >>>>>>>>>>>>>>>>>>>> result, NmethodSweepFraction remains 16 (if >>>>>>>>>>>>>>>>>>>> TieredCompilation is >>>>>>>>>>>>>>>>>>>> not used). This is way too large for small code cache >>>>>>>>>>>>>>>>>>>> sizes (e.g., <5m). >>>>>>>>>>>>>>>>>>>> 2) _request_mark_phase (sweeper.cpp) is initialized to >>>>>>>>>>>>>>>>>>>> false. As a >>>>>>>>>>>>>>>>>>>> result, mark_active_nmethods() did not set >>>>>>>>>>>>>>>>>>>> _invocations and _current, which results in not >>>>>>>>>>>>>>>>>>>> invoking the >>>>>>>>>>>>>>>>>>>> sweeper (calling sweep_code_cache()) at all. When >>>>>>>>>>>>>>>>>>>> TieredCompilation is enabled this was not an issue, >>>>>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>>>> NmethodSweeper::notify() (which sets >>>>>>>>>>>>>>>>>>>> _request_mark_phase) is >>>>>>>>>>>>>>>>>>>> called much more frequently. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Solution: 1) Move setting of NmethodSweepFraction >>>>>>>>>>>>>>>>>>>> so that >>>>>>>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>>>>>>> always executed. >>>>>>>>>>>>>>>>>>> Good. >>>>>>>>>>>>>>>> The place where I moved the adaption of >>>>>>>>>>>>>>>> NmethodSweepFraction >>>>>>>>>>>>>>>> is not >>>>>>>>>>>>>>>> good, since the >>>>>>>>>>>>>>>> the code cache size is adapted later for tiered. The >>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>> version >>>>>>>>>>>>>>>> should be fine. >>>>>>>>>>>>>>>>>>>> Solution: 2) Remove need_marking_phase(), >>>>>>>>>>>>>>>>>>>> request_nmethod_marking(), and reset_nmetod_marking(). >>>>>>>>>>>>>>>>>>>> I think that these checks are not >>>>>>>>>>>>>>>>>>>> needed >>>>>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>>>> 8020151, since we do stack scanning of >>>>>>>>>>>>>>>>>>>> active nmethods irrespective of the >>>>>>>>>>>>>>>>>>>> value of >>>>>>>>>>>>>>>>>>>> what need_marking_phase() returns. Since >>>>>>>>>>>>>>>>>>>> the patch removes >>>>>>>>>>>>>>>>>>>> need_marking_phase() >>>>>>>>>>>>>>>>>>>> printing >>>>>>>>>>>>>>>>>>>> out the warning (line 327 in >>>>>>>>>>>>>>>>>>>> sweeper.cpp) is incorrect, i.e., we >>>>>>>>>>>>>>>>>>>> continue to >>>>>>>>>>>>>>>>>>>> invoke the sweeper. I removed the warning >>>>>>>>>>>>>>>>>>>> and the associated code. >>>>>>>>>>>>>>>>>>> Don't put mark_active_nmethods() under >>>>>>>>>>>>>>>>>>> !UseCodeCacheFlushing >>>>>>>>>>>>>>>>>>> condition. We always want to reclaim space in >>>>>>>>>>>>>>>>>>> codecache. >>>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>>>>>> To do nmethod marking at each safepoint is fine (we >>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>> to do it >>>>>>>>>>>>>>>>>>> to make sure we did not miss live nmethods). But >>>>>>>>>>>>>>>>>>> with your >>>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>>> each safepoint triggers sweep. Do we really need >>>>>>>>>>>>>>>>>>> sweep so >>>>>>>>>>>>>>>>>>> frequently? Why to sweep if there were no nmethods >>>>>>>>>>>>>>>>>>> state >>>>>>>>>>>>>>>>>>> change and >>>>>>>>>>>>>>>>>>> there is enough space in CodeCache. So I am not sure >>>>>>>>>>>>>>>>>>> about >>>>>>>>>>>>>>>>>>> removing >>>>>>>>>>>>>>>>>>> _request_mark_phase, init it with 'true' is okay. >>>>>>>>>>>>>>>> I agree. The current patch contains a more >>>>>>>>>>>>>>>> sophisticated logic to >>>>>>>>>>>>>>>> determine when we call the >>>>>>>>>>>>>>>> sweeper. The bottom line is that we do not invoke the >>>>>>>>>>>>>>>> sweeper >>>>>>>>>>>>>>>> only if: >>>>>>>>>>>>>>> !!!!We DO INVOKE the sweeper only if: >>>>>>>>>>>>>>>> (1) The code cache is getting full and/or >>>>>>>>>>>>>>>> (2) There are sufficient state changes in the last sweep. >>>>>>>>>>>>>>> !!!!!(3) We have not been sweeping for 'some time' >>>>>>>>>>>>>>>> The patch contains a detailed description + examples of >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> logic. I >>>>>>>>>>>>>>>> tested the patch >>>>>>>>>>>>>>>> with small code cache sizes (specjvm98 + <4m code cache), >>>>>>>>>>>>>>>> medium-sized >>>>>>>>>>>>>>>> code cache >>>>>>>>>>>>>>>> (128m + nashorn + octane), and large code cache (240m + >>>>>>>>>>>>>>>> nashorn + >>>>>>>>>>>>>>>> octane). The measurements >>>>>>>>>>>>>>>> indicate that with the current logic in place, we can >>>>>>>>>>>>>>>> reduce the >>>>>>>>>>>>>>>> number of sweeps by 50% for >>>>>>>>>>>>>>>> medium code cache sizes without increasing the maximum >>>>>>>>>>>>>>>> used >>>>>>>>>>>>>>>> code cache >>>>>>>>>>>>>>>> size. The difference >>>>>>>>>>>>>>>> is more or less not significant. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please let me know what you think about it. The main >>>>>>>>>>>>>>>> disadvantage I >>>>>>>>>>>>>>>> see with this change is that >>>>>>>>>>>>>>>> it makes reasoning about the sweeper harder than it was >>>>>>>>>>>>>>>> before. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The warning was useless so it is okay to remove it and >>>>>>>>>>>>>>>>>>> corresponding code. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Also, I think that we can either remove >>>>>>>>>>>>>>>>>>>> -XX:MethodFlushing or >>>>>>>>>>>>>>>>>>>> -XX:UseCodeCacheFlushing. Since 8020151, one of >>>>>>>>>>>>>>>>>>>> them is >>>>>>>>>>>>>>>>>>>> redundant and can be removed. I am not quite sure >>>>>>>>>>>>>>>>>>>> if we >>>>>>>>>>>>>>>>>>>> should do >>>>>>>>>>>>>>>>>>>> that now so it is not included in the patch. >>>>>>>>>>>>>>>>>>> It is for separate change. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> MethodFlushing is obsolete because we can not run VM >>>>>>>>>>>>>>>>>>> without >>>>>>>>>>>>>>>>>>> codecache sweeping because we loose performance >>>>>>>>>>>>>>>>>>> since we go >>>>>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>>>>> Interpreter after codecache filled. Did you tried to >>>>>>>>>>>>>>>>>>> run >>>>>>>>>>>>>>>>>>> with it >>>>>>>>>>>>>>>>>>> OFF? I think it is good candidate to go. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The problem with UseCodeCacheFlushing is it becomes >>>>>>>>>>>>>>>>>>> famous >>>>>>>>>>>>>>>>>>> so you >>>>>>>>>>>>>>>>>>> can't remove it easily. But don't replace >>>>>>>>>>>>>>>>>>> MethodFlushing >>>>>>>>>>>>>>>>>>> with it. I >>>>>>>>>>>>>>>>>>> think code which currently guarded by MethodFlushing >>>>>>>>>>>>>>>>>>> should be >>>>>>>>>>>>>>>>>>> executed unconditionally. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In arguments.cpp there is table for obsolete flags: >>>>>>>>>>>>>>>>>>> static ObsoleteFlag obsolete_jvm_flags[] = { >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> jdk8 is major release so we can change flags. Add >>>>>>>>>>>>>>>>>>> MethodFlushing >>>>>>>>>>>>>>>>>>> there to remove it in jdk9: >>>>>>>>>>>>>>>>>>> { "MethodFlushing", JDK_Version::jdk(8), >>>>>>>>>>>>>>>>>>> JDK_Version::jdk(9) }, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>>> I'll file a new bug to remove the flag. I guess this >>>>>>>>>>>>>>>> change >>>>>>>>>>>>>>>> will most >>>>>>>>>>>>>>>> likely only make it into 8uXX. >>>>>>>>>>>>>>>>>>>> Testing >>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8027593 also >>>>>>>>>>>>>>>>>>>> shows a >>>>>>>>>>>>>>>>>>>> performance evaluation. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Many thanks for looking at the patch. >>>>>>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>>>>>> Albert >>>>>>> >> From igor.veresov at oracle.com Tue Nov 12 02:44:38 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 12 Nov 2013 10:44:38 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8027593: performance drop with constrained codecache starting with hs25 b111 Message-ID: <20131112104440.8464B62532@hg.openjdk.java.net> Changeset: 78da3894b86f Author: anoll Date: 2013-11-12 09:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From rickard.backman at oracle.com Tue Nov 12 05:30:08 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 12 Nov 2013 14:30:08 +0100 Subject: RFR(XS): 8028198: SIGSEGV in PhaseIdealLoop::build_loop_late_post Message-ID: <20131112132224.GE28348@rbackman> Hi, can I have this change reviewed please? In some cases the optimizer decided to split a MathExact node through a Phi creating an invalid pattern where there is a Phi between the MathExact and its projections. The fix is to not allow split_thru_phi for MathExact nodes. Webrev: http://cr.openjdk.java.net/~rbackman/8028198/ Bug: https://bugs.openjdk.java.net/browse/JDK-8028198 Thanks /R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131112/5727c795/attachment.bin From rickard.backman at oracle.com Tue Nov 12 06:23:45 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 12 Nov 2013 15:23:45 +0100 Subject: RFR(XS): 8028207: assert(_outcnt==1) failed: not unique in compile.cpp Message-ID: <20131112142345.GG28348@rbackman> Hi, can I have this small change reviewed please? When having two MathExactNodes with identical input, where one doesn't dominate the other we get a problem where the BoolNode controlling the overflow gets multiple IfNodes. In final_graph_reshaping we want to set the control edge of each node that uses the result of the MathExactNode to the non-throwing branch of that If. If there is more than one there is no way of saying which use requires which If. Webrev: http://cr.openjdk.java.net/~rbackman/8028207/ Bug: https://bugs.openjdk.java.net/browse/JDK-8028207 Thanks /R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131112/b79c45b3/attachment.bin From roland.westrelin at oracle.com Tue Nov 12 08:00:17 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Tue, 12 Nov 2013 16:00:17 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8027632: assert(xtype->klass_is_exact()) failed: Should be exact at graphKit.cpp Message-ID: <20131112160024.C4DCB62542@hg.openjdk.java.net> Changeset: 144b23411b51 Author: roland Date: 2013-11-12 13:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From vladimir.kozlov at oracle.com Tue Nov 12 09:56:45 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Nov 2013 09:56:45 -0800 Subject: RFR(XS): 8028198: SIGSEGV in PhaseIdealLoop::build_loop_late_post In-Reply-To: <20131112132224.GE28348@rbackman> References: <20131112132224.GE28348@rbackman> Message-ID: <52826BDD.7030305@oracle.com> Good. Vladimir On 11/12/13 5:30 AM, Rickard B?ckman wrote: > Hi, > > can I have this change reviewed please? > In some cases the optimizer decided to split a MathExact node through a > Phi creating an invalid pattern where there is a Phi between the > MathExact and its projections. The fix is to not allow split_thru_phi > for MathExact nodes. > > Webrev: http://cr.openjdk.java.net/~rbackman/8028198/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8028198 > > Thanks > /R > From vladimir.kozlov at oracle.com Tue Nov 12 09:59:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Nov 2013 09:59:29 -0800 Subject: RFR(XS): 8028207: assert(_outcnt==1) failed: not unique in compile.cpp In-Reply-To: <20131112142345.GG28348@rbackman> References: <20131112142345.GG28348@rbackman> Message-ID: <52826C81.3040305@oracle.com> Good. Vladimir On 11/12/13 6:23 AM, Rickard B?ckman wrote: > Hi, > > can I have this small change reviewed please? > When having two MathExactNodes with identical input, where one doesn't > dominate the other we get a problem where the BoolNode controlling the > overflow gets multiple IfNodes. > In final_graph_reshaping we want to set the control edge of each node > that uses the result of the MathExactNode to the non-throwing branch of > that If. If there is more than one there is no way of saying which use > requires which If. > > Webrev: http://cr.openjdk.java.net/~rbackman/8028207/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8028207 > > Thanks > /R > From roland.westrelin at oracle.com Tue Nov 12 13:52:51 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 12 Nov 2013 22:52:51 +0100 Subject: RFR(S): 8027572: assert(r != 0) failed: invalid In-Reply-To: <910638F9-DF6C-42DD-991C-4ACEAD94AF48@oracle.com> References: <0E9B433E-363C-4B24-8EEA-1A937FFE3F51@oracle.com> <3183BC83-BBA0-4015-8691-74EDF06F9860@oracle.com> <910638F9-DF6C-42DD-991C-4ACEAD94AF48@oracle.com> Message-ID: <13E3C20C-92B6-4CBE-83E1-AEA8FBAF8AD2@oracle.com> Same fix but with a test case: http://cr.openjdk.java.net/~roland/8027572/webrev.01/ Roland. From vladimir.kozlov at oracle.com Tue Nov 12 14:00:03 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Nov 2013 14:00:03 -0800 Subject: RFR(S): 8027572: assert(r != 0) failed: invalid In-Reply-To: <13E3C20C-92B6-4CBE-83E1-AEA8FBAF8AD2@oracle.com> References: <0E9B433E-363C-4B24-8EEA-1A937FFE3F51@oracle.com> <3183BC83-BBA0-4015-8691-74EDF06F9860@oracle.com> <910638F9-DF6C-42DD-991C-4ACEAD94AF48@oracle.com> <13E3C20C-92B6-4CBE-83E1-AEA8FBAF8AD2@oracle.com> Message-ID: <5282A4E3.8080500@oracle.com> Can you put next code in methodData.cpp on one line? No need re-review: + return k != NULL && + k->is_loader_alive(is_alive_cl); Otherwise good. Thanks, Vladimir On 11/12/13 1:52 PM, Roland Westrelin wrote: > Same fix but with a test case: > > http://cr.openjdk.java.net/~roland/8027572/webrev.01/ > > Roland. > From roland.westrelin at oracle.com Tue Nov 12 14:03:57 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 12 Nov 2013 23:03:57 +0100 Subject: RFR(S): 8027572: assert(r != 0) failed: invalid In-Reply-To: <5282A4E3.8080500@oracle.com> References: <0E9B433E-363C-4B24-8EEA-1A937FFE3F51@oracle.com> <3183BC83-BBA0-4015-8691-74EDF06F9860@oracle.com> <910638F9-DF6C-42DD-991C-4ACEAD94AF48@oracle.com> <13E3C20C-92B6-4CBE-83E1-AEA8FBAF8AD2@oracle.com> <5282A4E3.8080500@oracle.com> Message-ID: > Can you put next code in methodData.cpp on one line? No need re-review: > > + return k != NULL && > + k->is_loader_alive(is_alive_cl); Sure. Thanks for the review. Roland. From igor.veresov at oracle.com Tue Nov 12 14:07:47 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 12 Nov 2013 14:07:47 -0800 Subject: RFR(S): 8027572: assert(r != 0) failed: invalid In-Reply-To: <13E3C20C-92B6-4CBE-83E1-AEA8FBAF8AD2@oracle.com> References: <0E9B433E-363C-4B24-8EEA-1A937FFE3F51@oracle.com> <3183BC83-BBA0-4015-8691-74EDF06F9860@oracle.com> <910638F9-DF6C-42DD-991C-4ACEAD94AF48@oracle.com> <13E3C20C-92B6-4CBE-83E1-AEA8FBAF8AD2@oracle.com> Message-ID: <13BB28D9-8F53-49DA-9796-E08AAAE03A67@oracle.com> Ok On Nov 12, 2013, at 1:52 PM, Roland Westrelin wrote: > Same fix but with a test case: > > http://cr.openjdk.java.net/~roland/8027572/webrev.01/ > > Roland. From roland.westrelin at oracle.com Tue Nov 12 14:15:22 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 12 Nov 2013 23:15:22 +0100 Subject: RFR(S): 8027572: assert(r != 0) failed: invalid In-Reply-To: <13BB28D9-8F53-49DA-9796-E08AAAE03A67@oracle.com> References: <0E9B433E-363C-4B24-8EEA-1A937FFE3F51@oracle.com> <3183BC83-BBA0-4015-8691-74EDF06F9860@oracle.com> <910638F9-DF6C-42DD-991C-4ACEAD94AF48@oracle.com> <13E3C20C-92B6-4CBE-83E1-AEA8FBAF8AD2@oracle.com> <13BB28D9-8F53-49DA-9796-E08AAAE03A67@oracle.com> Message-ID: > Ok Thanks. Roland. From igor.veresov at oracle.com Tue Nov 12 15:16:49 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 12 Nov 2013 15:16:49 -0800 Subject: RFR(XS): 8028207: assert(_outcnt==1) failed: not unique in compile.cpp In-Reply-To: <20131112142345.GG28348@rbackman> References: <20131112142345.GG28348@rbackman> Message-ID: Looks good. May be later we can match this pattern with a conditional setting of a bool, an then branching on it in multiple places? igor On Nov 12, 2013, at 6:23 AM, Rickard B?ckman wrote: > Hi, > > can I have this small change reviewed please? > When having two MathExactNodes with identical input, where one doesn't > dominate the other we get a problem where the BoolNode controlling the > overflow gets multiple IfNodes. > In final_graph_reshaping we want to set the control edge of each node > that uses the result of the MathExactNode to the non-throwing branch of > that If. If there is more than one there is no way of saying which use > requires which If. > > Webrev: http://cr.openjdk.java.net/~rbackman/8028207/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8028207 > > Thanks > /R From igor.veresov at oracle.com Tue Nov 12 15:19:15 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 12 Nov 2013 15:19:15 -0800 Subject: RFR(XS): 8028198: SIGSEGV in PhaseIdealLoop::build_loop_late_post In-Reply-To: <20131112132224.GE28348@rbackman> References: <20131112132224.GE28348@rbackman> Message-ID: Looks good. igor On Nov 12, 2013, at 5:30 AM, Rickard B?ckman wrote: > Hi, > > can I have this change reviewed please? > In some cases the optimizer decided to split a MathExact node through a > Phi creating an invalid pattern where there is a Phi between the > MathExact and its projections. The fix is to not allow split_thru_phi > for MathExact nodes. > > Webrev: http://cr.openjdk.java.net/~rbackman/8028198/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8028198 > > Thanks > /R From rickard.backman at oracle.com Tue Nov 12 22:10:04 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 13 Nov 2013 07:10:04 +0100 Subject: RFR(XS): 8028207: assert(_outcnt==1) failed: not unique in compile.cpp In-Reply-To: References: <20131112142345.GG28348@rbackman> Message-ID: <20131113061004.GH28348@rbackman> Thank you Igor. /R On 11/12, Igor Veresov wrote: > Looks good. > > May be later we can match this pattern with a conditional setting of a bool, an then branching on it in multiple places? > > igor > > On Nov 12, 2013, at 6:23 AM, Rickard B?ckman wrote: > > > Hi, > > > > can I have this small change reviewed please? > > When having two MathExactNodes with identical input, where one doesn't > > dominate the other we get a problem where the BoolNode controlling the > > overflow gets multiple IfNodes. > > In final_graph_reshaping we want to set the control edge of each node > > that uses the result of the MathExactNode to the non-throwing branch of > > that If. If there is more than one there is no way of saying which use > > requires which If. > > > > Webrev: http://cr.openjdk.java.net/~rbackman/8028207/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028207 > > > > Thanks > > /R > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131113/558fca83/attachment.bin From rickard.backman at oracle.com Tue Nov 12 22:10:33 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 13 Nov 2013 07:10:33 +0100 Subject: RFR(XS): 8028207: assert(_outcnt==1) failed: not unique in compile.cpp In-Reply-To: <52826C81.3040305@oracle.com> References: <20131112142345.GG28348@rbackman> <52826C81.3040305@oracle.com> Message-ID: <20131113061033.GI28348@rbackman> Thanks Vladimir. /R On 11/12, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 11/12/13 6:23 AM, Rickard B?ckman wrote: > >Hi, > > > >can I have this small change reviewed please? > >When having two MathExactNodes with identical input, where one doesn't > >dominate the other we get a problem where the BoolNode controlling the > >overflow gets multiple IfNodes. > >In final_graph_reshaping we want to set the control edge of each node > >that uses the result of the MathExactNode to the non-throwing branch of > >that If. If there is more than one there is no way of saying which use > >requires which If. > > > >Webrev: http://cr.openjdk.java.net/~rbackman/8028207/ > >Bug: https://bugs.openjdk.java.net/browse/JDK-8028207 > > > >Thanks > >/R > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131113/00c58093/attachment-0001.bin From rickard.backman at oracle.com Tue Nov 12 22:10:58 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 13 Nov 2013 07:10:58 +0100 Subject: RFR(XS): 8028198: SIGSEGV in PhaseIdealLoop::build_loop_late_post In-Reply-To: <52826BDD.7030305@oracle.com> References: <20131112132224.GE28348@rbackman> <52826BDD.7030305@oracle.com> Message-ID: <20131113061058.GJ28348@rbackman> Thanks Vladimir. /R On 11/12, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 11/12/13 5:30 AM, Rickard B?ckman wrote: > >Hi, > > > >can I have this change reviewed please? > >In some cases the optimizer decided to split a MathExact node through a > >Phi creating an invalid pattern where there is a Phi between the > >MathExact and its projections. The fix is to not allow split_thru_phi > >for MathExact nodes. > > > >Webrev: http://cr.openjdk.java.net/~rbackman/8028198/ > >Bug: https://bugs.openjdk.java.net/browse/JDK-8028198 > > > >Thanks > >/R > > /R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131113/2dee5437/attachment.bin From rickard.backman at oracle.com Tue Nov 12 22:11:14 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 13 Nov 2013 07:11:14 +0100 Subject: RFR(XS): 8028198: SIGSEGV in PhaseIdealLoop::build_loop_late_post In-Reply-To: References: <20131112132224.GE28348@rbackman> Message-ID: <20131113061114.GK28348@rbackman> Thanks Igor. /R On 11/12, Igor Veresov wrote: > Looks good. > > igor > > On Nov 12, 2013, at 5:30 AM, Rickard B?ckman wrote: > > > Hi, > > > > can I have this change reviewed please? > > In some cases the optimizer decided to split a MathExact node through a > > Phi creating an invalid pattern where there is a Phi between the > > MathExact and its projections. The fix is to not allow split_thru_phi > > for MathExact nodes. > > > > Webrev: http://cr.openjdk.java.net/~rbackman/8028198/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028198 > > > > Thanks > > /R > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131113/aa483fc1/attachment.bin From rickard.backman at oracle.com Wed Nov 13 01:47:47 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Wed, 13 Nov 2013 09:47:47 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131113094752.1E7096256A@hg.openjdk.java.net> Changeset: f675976a61e7 Author: rbackman Date: 2013-11-12 13:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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 From roland.westrelin at oracle.com Wed Nov 13 03:48:20 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Wed, 13 Nov 2013 11:48:20 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131113114826.BBD2A6256D@hg.openjdk.java.net> Changeset: e6ba215af802 Author: roland Date: 2013-11-13 09:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/hotspot/rev/924c32982a12 Merge From vladimir.x.ivanov at oracle.com Wed Nov 13 06:22:59 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 13 Nov 2013 18:22:59 +0400 Subject: RFR (XS): 8028159: C2: compiler stack overflow during inlining of @ForceInline methods Message-ID: <52838B43.1030207@oracle.com> http://cr.openjdk.java.net/~vlivanov/8028159/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8028159 12 lines changed: 7 ins; 3 del; 2 mod There's a corner case when C2 inliner fails to delay inlining of @ForceInline method (e.g. nested MethodHandle::asType(MethodType) calls produce such pattern): @ForceInline m1 -> MH::invokeBasic -> @FI m2 -> MH::invokeBasic -> @FI m3 -> ... Having method handle chain deep enough, it's possible to overflow compiler thread stack and crash VM. The fix is to limit maximum inlining depth for @ForceInline method. By default, MaxForceInlineLimit (==100) is much larger than MaxInlineLevel(=9) for ordinary methods. Having it set to 100: - no crash observed - no inline bailouts due to MaxForceInlineLevel reached on octane benchmarks John wrote the following: "In stress tests, method handles can be arbitrarily deep. In typical use cases they are not; they are adapted a fixed number of times before being installed in a call site. It may be that some of these extreme cases can be solved by simply bailing out of the compile and continuing to interpret. A quick solution would be to have ForceInline fail after a larger stack depth than normal. Since part of the problem is the ForceInline directive, we need to ask whether they are all necessary. If we are adjusting heuristics by ForceInline, some of them can be removed, if we can detect the pattern from inside C2." Testing: failing test case, octane. PS: I tried another approach and experimented with late inlining (delay residual call chain inlining). Though I succeeded to delay inlining of MH::invokeBasic, I hit the same problem there. Unless re-delay is supported during late inlining, it's as easy to overflow compiler stack as when inlining during parsing phase. Changing late inlining logic is too much, IMO, for JDK8 at this phase. Thanks! Best regards, Vladimir Ivanov From roland.westrelin at oracle.com Wed Nov 13 06:37:03 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 13 Nov 2013 15:37:03 +0100 Subject: RFR (XS): 8028159: C2: compiler stack overflow during inlining of @ForceInline methods In-Reply-To: <52838B43.1030207@oracle.com> References: <52838B43.1030207@oracle.com> Message-ID: <95BFB22E-626C-415C-A9F1-CA8C947DA503@oracle.com> > http://cr.openjdk.java.net/~vlivanov/8028159/webrev.00/ That looks good to me. Roland. From roland.westrelin at oracle.com Wed Nov 13 07:06:19 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Wed, 13 Nov 2013 15:06:19 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8027572: assert(r != 0) failed: invalid Message-ID: <20131113150621.B2C1262574@hg.openjdk.java.net> Changeset: 6e1826d5c23e Author: roland Date: 2013-11-13 13:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From vladimir.x.ivanov at oracle.com Wed Nov 13 09:57:22 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 13 Nov 2013 21:57:22 +0400 Subject: RFR (XS): 8028159: C2: compiler stack overflow during inlining of @ForceInline methods In-Reply-To: <95BFB22E-626C-415C-A9F1-CA8C947DA503@oracle.com> References: <52838B43.1030207@oracle.com> <95BFB22E-626C-415C-A9F1-CA8C947DA503@oracle.com> Message-ID: <5283BD82.7080406@oracle.com> Thank you, Roland. Best regards, Vladimir Ivanov On 11/13/13 6:37 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~vlivanov/8028159/webrev.00/ > > That looks good to me. > > Roland. > From vladimir.kozlov at oracle.com Wed Nov 13 10:09:10 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Nov 2013 10:09:10 -0800 Subject: RFR (XS): 8028159: C2: compiler stack overflow during inlining of @ForceInline methods In-Reply-To: <52838B43.1030207@oracle.com> References: <52838B43.1030207@oracle.com> Message-ID: <5283C046.3090806@oracle.com> Make the flag product as other inline limitation flags. Thanks, Vladimir K On 11/13/13 6:22 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8028159/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8028159 > 12 lines changed: 7 ins; 3 del; 2 mod > > There's a corner case when C2 inliner fails to delay inlining of @ForceInline method (e.g. nested > MethodHandle::asType(MethodType) calls produce such pattern): > @ForceInline m1 -> MH::invokeBasic -> @FI m2 -> MH::invokeBasic -> @FI m3 -> ... > > Having method handle chain deep enough, it's possible to overflow compiler thread stack and crash VM. > > The fix is to limit maximum inlining depth for @ForceInline method. By default, MaxForceInlineLimit (==100) is much > larger than MaxInlineLevel(=9) for ordinary methods. > > Having it set to 100: > - no crash observed > - no inline bailouts due to MaxForceInlineLevel reached on octane benchmarks > > John wrote the following: > "In stress tests, method handles can be arbitrarily deep. In typical use cases they are not; they are adapted a fixed > number of times before being installed in a call site. It may be that some of these extreme cases can be solved by > simply bailing out of the compile and continuing to interpret. > > A quick solution would be to have ForceInline fail after a larger stack depth than normal. > > Since part of the problem is the ForceInline directive, we need to ask whether they are all necessary. If we are > adjusting heuristics by ForceInline, some of them can be removed, if we can detect the pattern from inside C2." > > Testing: failing test case, octane. > > PS: I tried another approach and experimented with late inlining (delay residual call chain inlining). Though I > succeeded to delay inlining of MH::invokeBasic, I hit the same problem there. Unless re-delay is supported during late > inlining, it's as easy to overflow compiler stack as when inlining during parsing phase. Changing late inlining logic is > too much, IMO, for JDK8 at this phase. > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Tue Nov 12 22:17:43 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 13 Nov 2013 10:17:43 +0400 Subject: RFR (XS): 8028159: C2: compiler stack overflow during inlining of @ForceInline methods In-Reply-To: <5283C046.3090806@oracle.com> References: <52838B43.1030207@oracle.com> <5283C046.3090806@oracle.com> Message-ID: <52831987.1000208@oracle.com> Are you sure? Last time we decided to make it develop (corresponding letter attached). Best regards, Vladimir Ivanov On 11/13/13 10:09 PM, Vladimir Kozlov wrote: > Make the flag product as other inline limitation flags. > > Thanks, > Vladimir K > > On 11/13/13 6:22 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8028159/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8028159 >> 12 lines changed: 7 ins; 3 del; 2 mod >> >> There's a corner case when C2 inliner fails to delay inlining of >> @ForceInline method (e.g. nested >> MethodHandle::asType(MethodType) calls produce such pattern): >> @ForceInline m1 -> MH::invokeBasic -> @FI m2 -> MH::invokeBasic -> >> @FI m3 -> ... >> >> Having method handle chain deep enough, it's possible to overflow >> compiler thread stack and crash VM. >> >> The fix is to limit maximum inlining depth for @ForceInline method. By >> default, MaxForceInlineLimit (==100) is much >> larger than MaxInlineLevel(=9) for ordinary methods. >> >> Having it set to 100: >> - no crash observed >> - no inline bailouts due to MaxForceInlineLevel reached on octane >> benchmarks >> >> John wrote the following: >> "In stress tests, method handles can be arbitrarily deep. In typical >> use cases they are not; they are adapted a fixed >> number of times before being installed in a call site. It may be that >> some of these extreme cases can be solved by >> simply bailing out of the compile and continuing to interpret. >> >> A quick solution would be to have ForceInline fail after a larger >> stack depth than normal. >> >> Since part of the problem is the ForceInline directive, we need to ask >> whether they are all necessary. If we are >> adjusting heuristics by ForceInline, some of them can be removed, if >> we can detect the pattern from inside C2." >> >> Testing: failing test case, octane. >> >> PS: I tried another approach and experimented with late inlining >> (delay residual call chain inlining). Though I >> succeeded to delay inlining of MH::invokeBasic, I hit the same problem >> there. Unless re-delay is supported during late >> inlining, it's as easy to overflow compiler stack as when inlining >> during parsing phase. Changing late inlining logic is >> too much, IMO, for JDK8 at this phase. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov -------------- next part -------------- An embedded message was scrubbed... From: Christian Thalinger Subject: Re: RFR (XS): 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow Date: Mon, 14 Oct 2013 14:12:17 -0700 Size: 4866 Url: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131113/bdcbd853/AttachedMessage.nws From vladimir.kozlov at oracle.com Wed Nov 13 11:36:09 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Nov 2013 11:36:09 -0800 Subject: RFR (XS): 8028159: C2: compiler stack overflow during inlining of @ForceInline methods In-Reply-To: <52831987.1000208@oracle.com> References: <52838B43.1030207@oracle.com> <5283C046.3090806@oracle.com> <52831987.1000208@oracle.com> Message-ID: <5283D4A9.3000308@oracle.com> Sorry, I forgot about that. Then your code is fine. thanks, Vladimir On 11/12/13 10:17 PM, Vladimir Ivanov wrote: > Are you sure? Last time we decided to make it develop (corresponding > letter attached). > > Best regards, > Vladimir Ivanov > > On 11/13/13 10:09 PM, Vladimir Kozlov wrote: >> Make the flag product as other inline limitation flags. >> >> Thanks, >> Vladimir K >> >> On 11/13/13 6:22 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8028159/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8028159 >>> 12 lines changed: 7 ins; 3 del; 2 mod >>> >>> There's a corner case when C2 inliner fails to delay inlining of >>> @ForceInline method (e.g. nested >>> MethodHandle::asType(MethodType) calls produce such pattern): >>> @ForceInline m1 -> MH::invokeBasic -> @FI m2 -> MH::invokeBasic -> >>> @FI m3 -> ... >>> >>> Having method handle chain deep enough, it's possible to overflow >>> compiler thread stack and crash VM. >>> >>> The fix is to limit maximum inlining depth for @ForceInline method. By >>> default, MaxForceInlineLimit (==100) is much >>> larger than MaxInlineLevel(=9) for ordinary methods. >>> >>> Having it set to 100: >>> - no crash observed >>> - no inline bailouts due to MaxForceInlineLevel reached on octane >>> benchmarks >>> >>> John wrote the following: >>> "In stress tests, method handles can be arbitrarily deep. In typical >>> use cases they are not; they are adapted a fixed >>> number of times before being installed in a call site. It may be that >>> some of these extreme cases can be solved by >>> simply bailing out of the compile and continuing to interpret. >>> >>> A quick solution would be to have ForceInline fail after a larger >>> stack depth than normal. >>> >>> Since part of the problem is the ForceInline directive, we need to ask >>> whether they are all necessary. If we are >>> adjusting heuristics by ForceInline, some of them can be removed, if >>> we can detect the pattern from inside C2." >>> >>> Testing: failing test case, octane. >>> >>> PS: I tried another approach and experimented with late inlining >>> (delay residual call chain inlining). Though I >>> succeeded to delay inlining of MH::invokeBasic, I hit the same problem >>> there. Unless re-delay is supported during late >>> inlining, it's as easy to overflow compiler stack as when inlining >>> during parsing phase. Changing late inlining logic is >>> too much, IMO, for JDK8 at this phase. >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Nov 13 12:03:47 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 14 Nov 2013 00:03:47 +0400 Subject: RFR (XS): 8028159: C2: compiler stack overflow during inlining of @ForceInline methods In-Reply-To: <5283D4A9.3000308@oracle.com> References: <52838B43.1030207@oracle.com> <5283C046.3090806@oracle.com> <52831987.1000208@oracle.com> <5283D4A9.3000308@oracle.com> Message-ID: <5283DB23.7090400@oracle.com> Thank you, Vladimir. Best regards, Vladimir Ivanov On 11/13/13 11:36 PM, Vladimir Kozlov wrote: > Sorry, I forgot about that. Then your code is fine. > > thanks, > Vladimir > > On 11/12/13 10:17 PM, Vladimir Ivanov wrote: >> Are you sure? Last time we decided to make it develop (corresponding >> letter attached). >> >> Best regards, >> Vladimir Ivanov >> >> On 11/13/13 10:09 PM, Vladimir Kozlov wrote: >>> Make the flag product as other inline limitation flags. >>> >>> Thanks, >>> Vladimir K >>> >>> On 11/13/13 6:22 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8028159/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8028159 >>>> 12 lines changed: 7 ins; 3 del; 2 mod >>>> >>>> There's a corner case when C2 inliner fails to delay inlining of >>>> @ForceInline method (e.g. nested >>>> MethodHandle::asType(MethodType) calls produce such pattern): >>>> @ForceInline m1 -> MH::invokeBasic -> @FI m2 -> MH::invokeBasic -> >>>> @FI m3 -> ... >>>> >>>> Having method handle chain deep enough, it's possible to overflow >>>> compiler thread stack and crash VM. >>>> >>>> The fix is to limit maximum inlining depth for @ForceInline method. By >>>> default, MaxForceInlineLimit (==100) is much >>>> larger than MaxInlineLevel(=9) for ordinary methods. >>>> >>>> Having it set to 100: >>>> - no crash observed >>>> - no inline bailouts due to MaxForceInlineLevel reached on octane >>>> benchmarks >>>> >>>> John wrote the following: >>>> "In stress tests, method handles can be arbitrarily deep. In typical >>>> use cases they are not; they are adapted a fixed >>>> number of times before being installed in a call site. It may be that >>>> some of these extreme cases can be solved by >>>> simply bailing out of the compile and continuing to interpret. >>>> >>>> A quick solution would be to have ForceInline fail after a larger >>>> stack depth than normal. >>>> >>>> Since part of the problem is the ForceInline directive, we need to ask >>>> whether they are all necessary. If we are >>>> adjusting heuristics by ForceInline, some of them can be removed, if >>>> we can detect the pattern from inside C2." >>>> >>>> Testing: failing test case, octane. >>>> >>>> PS: I tried another approach and experimented with late inlining >>>> (delay residual call chain inlining). Though I >>>> succeeded to delay inlining of MH::invokeBasic, I hit the same problem >>>> there. Unless re-delay is supported during late >>>> inlining, it's as easy to overflow compiler stack as when inlining >>>> during parsing phase. Changing late inlining logic is >>>> too much, IMO, for JDK8 at this phase. >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov From albert.noll at oracle.com Thu Nov 14 01:36:48 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 14 Nov 2013 10:36:48 +0100 Subject: RFR(XS): 8028306: nsk stress tests, CodeCache fills, then safepoint asserts Message-ID: <528499B0.6060202@oracle.com> Hi, could I have reviews for this small patch? webrev: http://cr.openjdk.java.net/~anoll/8028306/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8028306 problem: 1) ciEnv::register_method() calls CodeCache::handle_full_code_cache() in a block where no safepoints are allowed. However, handle_full_code_cache can reach a safepoint since it uses locks. 2) I added a check in 'possibly_sweep()' that ensures that only compiler threads can sweep the code cache. It can happen that normal Java threads can call 'possibly_sweep()' via 'handle_full_code_cache()'. solution: 1) move call to 'handle_full_code_cache()' outside the block where no safepoints are allowed 2) see above testing: failing test case passes. Many thanks in advance, Albert From vladimir.x.ivanov at oracle.com Thu Nov 14 02:36:09 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 14 Nov 2013 14:36:09 +0400 Subject: RFR(XS): 8028306: nsk stress tests, CodeCache fills, then safepoint asserts In-Reply-To: <528499B0.6060202@oracle.com> References: <528499B0.6060202@oracle.com> Message-ID: <5284A799.3090301@oracle.com> Albert, Thanks for fixing that. Missed that case when added No_Safepoint_Verifier. ciEnv.cpp: looks good. sweeper.cpp: is it possible NMethodSweeper::possibly_sweep is called in non-compiler thread? Why don't you turn the check into assert? Best regards, Vladimir Ivanov On 11/14/13 1:36 PM, Albert Noll wrote: > Hi, > > could I have reviews for this small patch? > > webrev: http://cr.openjdk.java.net/~anoll/8028306/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8028306 > > problem: 1) ciEnv::register_method() calls > CodeCache::handle_full_code_cache() in a > block where no safepoints are allowed. However, > handle_full_code_cache > can reach a safepoint since it uses locks. > 2) I added a check in 'possibly_sweep()' that ensures > that only compiler threads > can sweep the code cache. It can happen that normal > Java threads can call > 'possibly_sweep()' via 'handle_full_code_cache()'. > solution: 1) move call to 'handle_full_code_cache()' outside the block > where no safepoints > are allowed > 2) see above > > testing: failing test case passes. > > > Many thanks in advance, > Albert > > > From albert.noll at oracle.com Thu Nov 14 02:58:27 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 14 Nov 2013 11:58:27 +0100 Subject: RFR(XS): 8028306: nsk stress tests, CodeCache fills, then safepoint asserts In-Reply-To: <5284A799.3090301@oracle.com> References: <528499B0.6060202@oracle.com> <5284A799.3090301@oracle.com> Message-ID: <5284ACD3.1000306@oracle.com> Hi Vladimir, thanks for your feedback. Yes, it is possible that a non-compiler thread calls 'possibly_sweep()'. E.g., 'create_native_wrapper()' can be called by a non-compiler thread ('sharedRuntime.cpp') and calls 'handle_full_code_cache()' which in turn 'calls possibly_sweep()'. I added the check, since I encountered a failing assert (example above) that checks that only compiler threads call the sweeper. I think it is fine to have the check in there since we only possibly sweep. Best, Albert On 11/14/2013 11:36 AM, Vladimir Ivanov wrote: > Albert, > > Thanks for fixing that. Missed that case when added > No_Safepoint_Verifier. > > ciEnv.cpp: looks good. > sweeper.cpp: is it possible NMethodSweeper::possibly_sweep is called > in non-compiler thread? Why don't you turn the check into assert? > > Best regards, > Vladimir Ivanov > > On 11/14/13 1:36 PM, Albert Noll wrote: >> Hi, >> >> could I have reviews for this small patch? >> >> webrev: http://cr.openjdk.java.net/~anoll/8028306/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8028306 >> >> problem: 1) ciEnv::register_method() calls >> CodeCache::handle_full_code_cache() in a >> block where no safepoints are allowed. However, >> handle_full_code_cache >> can reach a safepoint since it uses locks. >> 2) I added a check in 'possibly_sweep()' that ensures >> that only compiler threads >> can sweep the code cache. It can happen that normal >> Java threads can call >> 'possibly_sweep()' via 'handle_full_code_cache()'. >> solution: 1) move call to 'handle_full_code_cache()' outside the block >> where no safepoints >> are allowed >> 2) see above >> >> testing: failing test case passes. >> >> >> Many thanks in advance, >> Albert >> >> >> From vladimir.x.ivanov at oracle.com Thu Nov 14 04:59:10 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 14 Nov 2013 16:59:10 +0400 Subject: RFR(XS): 8028306: nsk stress tests, CodeCache fills, then safepoint asserts In-Reply-To: <5284ACD3.1000306@oracle.com> References: <528499B0.6060202@oracle.com> <5284A799.3090301@oracle.com> <5284ACD3.1000306@oracle.com> Message-ID: <5284C91E.90902@oracle.com> Thanks for clarifications. Look good to me (not a Reviewer). Best regards, Vladimir Ivanov On 11/14/13 2:58 PM, Albert Noll wrote: > Hi Vladimir, > > thanks for your feedback. Yes, it is possible that a non-compiler thread > calls > 'possibly_sweep()'. E.g., 'create_native_wrapper()' can be called by a > non-compiler > thread ('sharedRuntime.cpp') and calls 'handle_full_code_cache()' which > in turn > 'calls possibly_sweep()'. > > I added the check, since I encountered a failing assert (example above) > that checks > that only compiler threads call the sweeper. I think it is fine to have > the check in there > since we only possibly sweep. > > Best, > Albert > > On 11/14/2013 11:36 AM, Vladimir Ivanov wrote: >> Albert, >> >> Thanks for fixing that. Missed that case when added >> No_Safepoint_Verifier. >> >> ciEnv.cpp: looks good. >> sweeper.cpp: is it possible NMethodSweeper::possibly_sweep is called >> in non-compiler thread? Why don't you turn the check into assert? >> >> Best regards, >> Vladimir Ivanov >> >> On 11/14/13 1:36 PM, Albert Noll wrote: >>> Hi, >>> >>> could I have reviews for this small patch? >>> >>> webrev: http://cr.openjdk.java.net/~anoll/8028306/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8028306 >>> >>> problem: 1) ciEnv::register_method() calls >>> CodeCache::handle_full_code_cache() in a >>> block where no safepoints are allowed. However, >>> handle_full_code_cache >>> can reach a safepoint since it uses locks. >>> 2) I added a check in 'possibly_sweep()' that ensures >>> that only compiler threads >>> can sweep the code cache. It can happen that normal >>> Java threads can call >>> 'possibly_sweep()' via 'handle_full_code_cache()'. >>> solution: 1) move call to 'handle_full_code_cache()' outside the block >>> where no safepoints >>> are allowed >>> 2) see above >>> >>> testing: failing test case passes. >>> >>> >>> Many thanks in advance, >>> Albert >>> >>> >>> > From igor.veresov at oracle.com Thu Nov 14 07:37:48 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 14 Nov 2013 07:37:48 -0800 Subject: RFR(XS): 8028306: nsk stress tests, CodeCache fills, then safepoint asserts In-Reply-To: <528499B0.6060202@oracle.com> References: <528499B0.6060202@oracle.com> Message-ID: <40648053-A2D3-4898-8C70-EC8B00FAEAD6@oracle.com> Looks good. igor On Nov 14, 2013, at 1:36 AM, Albert Noll wrote: > Hi, > > could I have reviews for this small patch? > > webrev: http://cr.openjdk.java.net/~anoll/8028306/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8028306 > > problem: 1) ciEnv::register_method() calls CodeCache::handle_full_code_cache() in a > block where no safepoints are allowed. However, handle_full_code_cache > can reach a safepoint since it uses locks. > 2) I added a check in 'possibly_sweep()' that ensures that only compiler threads > can sweep the code cache. It can happen that normal Java threads can call > 'possibly_sweep()' via 'handle_full_code_cache()'. > solution: 1) move call to 'handle_full_code_cache()' outside the block where no safepoints > are allowed > 2) see above > > testing: failing test case passes. > > > Many thanks in advance, > Albert > > > From vladimir.kozlov at oracle.com Thu Nov 14 09:31:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Nov 2013 09:31:32 -0800 Subject: RFR(XS): 8028306: nsk stress tests, CodeCache fills, then safepoint asserts In-Reply-To: <5284ACD3.1000306@oracle.com> References: <528499B0.6060202@oracle.com> <5284A799.3090301@oracle.com> <5284ACD3.1000306@oracle.com> Message-ID: <528508F4.8060505@oracle.com> Changes are good. Thanks, Vladimir K On 11/14/13 2:58 AM, Albert Noll wrote: > Hi Vladimir, > > thanks for your feedback. Yes, it is possible that a non-compiler thread calls > 'possibly_sweep()'. E.g., 'create_native_wrapper()' can be called by a non-compiler > thread ('sharedRuntime.cpp') and calls 'handle_full_code_cache()' which in turn > 'calls possibly_sweep()'. > > I added the check, since I encountered a failing assert (example above) that checks > that only compiler threads call the sweeper. I think it is fine to have the check in there > since we only possibly sweep. > > Best, > Albert > > On 11/14/2013 11:36 AM, Vladimir Ivanov wrote: >> Albert, >> >> Thanks for fixing that. Missed that case when added No_Safepoint_Verifier. >> >> ciEnv.cpp: looks good. >> sweeper.cpp: is it possible NMethodSweeper::possibly_sweep is called in non-compiler thread? Why don't you turn the >> check into assert? >> >> Best regards, >> Vladimir Ivanov >> >> On 11/14/13 1:36 PM, Albert Noll wrote: >>> Hi, >>> >>> could I have reviews for this small patch? >>> >>> webrev: http://cr.openjdk.java.net/~anoll/8028306/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8028306 >>> >>> problem: 1) ciEnv::register_method() calls >>> CodeCache::handle_full_code_cache() in a >>> block where no safepoints are allowed. However, >>> handle_full_code_cache >>> can reach a safepoint since it uses locks. >>> 2) I added a check in 'possibly_sweep()' that ensures >>> that only compiler threads >>> can sweep the code cache. It can happen that normal >>> Java threads can call >>> 'possibly_sweep()' via 'handle_full_code_cache()'. >>> solution: 1) move call to 'handle_full_code_cache()' outside the block >>> where no safepoints >>> are allowed >>> 2) see above >>> >>> testing: failing test case passes. >>> >>> >>> Many thanks in advance, >>> Albert >>> >>> >>> > From albert.noll at oracle.com Thu Nov 14 10:33:32 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 14 Nov 2013 19:33:32 +0100 Subject: RFR(XS): 8028306: nsk stress tests, CodeCache fills, then safepoint asserts In-Reply-To: <528508F4.8060505@oracle.com> References: <528499B0.6060202@oracle.com> <5284A799.3090301@oracle.com> <5284ACD3.1000306@oracle.com> <528508F4.8060505@oracle.com> Message-ID: <5285177C.6050805@oracle.com> Igor, Vladimir, thanks for the reviews. Best, Albert On 11/14/2013 06:31 PM, Vladimir Kozlov wrote: > Changes are good. > > Thanks, > Vladimir K > > On 11/14/13 2:58 AM, Albert Noll wrote: >> Hi Vladimir, >> >> thanks for your feedback. Yes, it is possible that a non-compiler >> thread calls >> 'possibly_sweep()'. E.g., 'create_native_wrapper()' can be called by >> a non-compiler >> thread ('sharedRuntime.cpp') and calls 'handle_full_code_cache()' >> which in turn >> 'calls possibly_sweep()'. >> >> I added the check, since I encountered a failing assert (example >> above) that checks >> that only compiler threads call the sweeper. I think it is fine to >> have the check in there >> since we only possibly sweep. >> >> Best, >> Albert >> >> On 11/14/2013 11:36 AM, Vladimir Ivanov wrote: >>> Albert, >>> >>> Thanks for fixing that. Missed that case when added >>> No_Safepoint_Verifier. >>> >>> ciEnv.cpp: looks good. >>> sweeper.cpp: is it possible NMethodSweeper::possibly_sweep is called >>> in non-compiler thread? Why don't you turn the >>> check into assert? >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/14/13 1:36 PM, Albert Noll wrote: >>>> Hi, >>>> >>>> could I have reviews for this small patch? >>>> >>>> webrev: http://cr.openjdk.java.net/~anoll/8028306/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8028306 >>>> >>>> problem: 1) ciEnv::register_method() calls >>>> CodeCache::handle_full_code_cache() in a >>>> block where no safepoints are allowed. However, >>>> handle_full_code_cache >>>> can reach a safepoint since it uses locks. >>>> 2) I added a check in 'possibly_sweep()' that ensures >>>> that only compiler threads >>>> can sweep the code cache. It can happen that >>>> normal >>>> Java threads can call >>>> 'possibly_sweep()' via >>>> 'handle_full_code_cache()'. >>>> solution: 1) move call to 'handle_full_code_cache()' outside the >>>> block >>>> where no safepoints >>>> are allowed >>>> 2) see above >>>> >>>> testing: failing test case passes. >>>> >>>> >>>> Many thanks in advance, >>>> Albert >>>> >>>> >>>> >> From john.coomes at oracle.com Thu Nov 14 10:41:46 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:41:46 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b116 for changeset e757eb9aee3d Message-ID: <20131114184156.B1940625D3@hg.openjdk.java.net> Changeset: c1d234d4f164 Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/c1d234d4f164 Added tag jdk8-b116 for changeset e757eb9aee3d ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:41:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:41:38 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b116 for changeset 5fdc44652089 Message-ID: <20131114184142.3AC8C625D2@hg.openjdk.java.net> Changeset: 7299367c8aa4 Author: cl Date: 2013-11-14 09:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/7299367c8aa4 Added tag jdk8-b116 for changeset 5fdc44652089 ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:41:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:41:34 +0000 Subject: hg: hsx/hotspot-comp: 3 new changesets Message-ID: <20131114184135.03667625D1@hg.openjdk.java.net> Changeset: c1029b02ca87 Author: ihse Date: 2013-11-08 09:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/rev/cbfe5da942c6 Merge Changeset: a4afb0a8d55e Author: cl Date: 2013-11-14 09:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/a4afb0a8d55e Added tag jdk8-b116 for changeset cbfe5da942c6 ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:42:01 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:42:01 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b116 for changeset 587560c222a2 Message-ID: <20131114184209.14E74625D4@hg.openjdk.java.net> Changeset: fe56ba456fd3 Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/fe56ba456fd3 Added tag jdk8-b116 for changeset 587560c222a2 ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:42:20 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:42:20 +0000 Subject: hg: hsx/hotspot-comp/jdk: 5 new changesets Message-ID: <20131114184427.DC383625D5@hg.openjdk.java.net> Changeset: bdcba4854576 Author: erikj Date: 2013-11-07 10:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/jdk/rev/0dc0067f3b8e Merge Changeset: 483148bf625e Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/483148bf625e Added tag jdk8-b116 for changeset 0dc0067f3b8e ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:46:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:46:32 +0000 Subject: hg: hsx/hotspot-comp/nashorn: Added tag jdk8-b116 for changeset 0fb1a427fbf6 Message-ID: <20131114184637.3B2BB625D8@hg.openjdk.java.net> Changeset: 774c63629870 Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/774c63629870 Added tag jdk8-b116 for changeset 0fb1a427fbf6 ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:45:51 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:45:51 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b116 for changeset 3c040b04af05 Message-ID: <20131114184609.3028D625D6@hg.openjdk.java.net> Changeset: 64d119680f0a Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/64d119680f0a Added tag jdk8-b116 for changeset 3c040b04af05 ! .hgtags From vladimir.x.ivanov at oracle.com Thu Nov 14 12:44:09 2013 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Thu, 14 Nov 2013 20:44:09 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8028159: C2: compiler stack overflow during inlining of @ForceInline methods Message-ID: <20131114204417.7E252625F7@hg.openjdk.java.net> Changeset: e74074c34312 Author: vlivanov Date: 2013-11-14 09:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From shrinivas.joshi at oracle.com Thu Nov 14 18:34:16 2013 From: shrinivas.joshi at oracle.com (Shrinivas Joshi) Date: Thu, 14 Nov 2013 18:34:16 -0800 Subject: RFR(L): 8002074: Support for AES on SPARC Message-ID: <52858828.2090105@oracle.com> Hi, Can I please request reviews for the following change? Target JDK release for this change would be the next update of JDK 8 / JDK 9. Thanks, -Shrinivas RFE: https://bugs.openjdk.java.net/browse/JDK-8002074 Webrev: http://cr.openjdk.java.net/~kvn/8002074/webrev.02/ Summary: This change adds intrinsics/stub routines support for single-block and multi-block (as used by Cipher Block Chaining mode) AES encryption and decryption operations on the SPARC platform. These intrinsics are available only when the application is configured to use SunJCE crypto provider. These stubs make use of efficient hardware AES instructions and thus offer significant performance improvements over JITed code. AES intrinsics are enabled by default on SPARC platforms that support AES instructions. They can be explicitly enabled or disabled on the command-line using UseAES and UseAESIntrinsics JVM flags. Summary of source code changes: * src/cpu/sparc/vm/assembler_sparc.hpp - Adds support for all 3-operand and 4-operand SPARC AES instructions. Also adds support for floating-point XOR (FXORs/FXORd) instructions. FXOR instructions are used in the AES stub routines * src/cpu/sparc/vm/stubGenerator_sparc.cpp - Defines stubs for single-block and multi-block AES encryption and decryption routines supporting all key sizes (128-bit, 192-bit and 256-bit). - Current SPARC AES decryption instructions are not compatible with SunJCE expanded decryption key format. Thus decryption stubs read the original key (passed as an input parameter) and perform decryption key expansion using hardware instructions. - Multi-block decryption stub can perform decryption for 2 * 16-byte blocks at a time. - Encryption stubs use SunJCE expanded encryption key as their is no incompatibility issue between SPARC AES encryption instructions and SunJCE expanded encryption keys. * src/cpu/sparc/vm/sparc.ad, src/cpu/x86/vm/x86.ad and src/share/vm/opto/matcher.hpp - The additional original key array reference parameter is required only on the SPARC platform. This code guards it from being passed to the x86 AES stub routines. * src/cpu/sparc/vm/vm_version_sparc.cpp, src/cpu/sparc/vm/vm_version_sparc.hpp and src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp - Detect AES capabilities of the underlying CPU. - Enable UseAES and UseAESIntrinsics flags if the underlying CPU supports AES instructions and neither of them is explicitly disabled on the command-line. Generate warning message if either of these flags are enabled on the command-line whereas the underlying CPU does not support AES instructions. * src/share/vm/classfile/vmSymbols.hpp - Fix for "8012900: CICO ignores AAD in GCM mode" changes return type of com.sun.crypto.provider.CipherBlockChaining.encrypt() and com.sun.crypto.provider.CipherBlockChaining.decrypt() from void to int. Method signature in intrinsics definition had to be changed accordingly. * src/share/vm/opto/library_call.cpp - Adds a new method to read 'lastKey' field of com.sun.crypto.provider.AESCrypt class which holds the original key. - Passes additional input parameter, original key array reference, to the AES stubs only on the SPARC platform. - Addresses change in return value from 'void' to 'int' in case of multi-block CBC stubs. * src/share/vm/opto/runtime.cpp - Reads the additional input parameter (original key reference) only on SPARC platform. - Addresses change in return value from 'void' to 'int' in case of multi-block CBC stubs. * hotspot/test/compiler/7184394/TestAESMain.java - This test case was contributed as part of the x86 AES intrinsics work by Tom Deneau @AMD. Fixed incorrect nano-second to milli-second conversion code. Added warm-up phase since this test case can also be used for performance testing. Testing: jtreg, ctw, nsk and JPRT From vitalyd at gmail.com Thu Nov 14 20:15:38 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 14 Nov 2013 23:15:38 -0500 Subject: RFR(L): 8002074: Support for AES on SPARC In-Reply-To: <52858828.2090105@oracle.com> References: <52858828.2090105@oracle.com> Message-ID: Hi Shrinivas, In vm_version_sparc.cpp line 253 you added aes printing but the string format is missing a new corresponding %s? Also, is the 512 buf size still sufficient if all features are present? I didn't attempt to count :). Sent from my phone On Nov 14, 2013 9:36 PM, "Shrinivas Joshi" wrote: > Hi, > > Can I please request reviews for the following change? Target JDK release > for this change would be the next update of JDK 8 / JDK 9. > > Thanks, > -Shrinivas > > RFE: https://bugs.openjdk.java.net/browse/JDK-8002074 > Webrev: http://cr.openjdk.java.net/~kvn/8002074/webrev.02/ > > Summary: This change adds intrinsics/stub routines support for > single-block and multi-block (as used by Cipher Block Chaining mode) AES > encryption and decryption operations on the SPARC platform. These > intrinsics are available only when the application is configured to use > SunJCE crypto provider. These stubs make use of efficient hardware AES > instructions and thus offer significant performance improvements over JITed > code. AES intrinsics are enabled by default on SPARC platforms that support > AES instructions. They can be explicitly enabled or disabled on the > command-line using UseAES and UseAESIntrinsics JVM flags. > > Summary of source code changes: > * src/cpu/sparc/vm/assembler_sparc.hpp > - Adds support for all 3-operand and 4-operand SPARC AES > instructions. Also adds support for floating-point XOR (FXORs/FXORd) > instructions. FXOR instructions are used in the AES stub routines > * src/cpu/sparc/vm/stubGenerator_sparc.cpp > - Defines stubs for single-block and multi-block AES encryption and > decryption routines supporting all key sizes (128-bit, 192-bit and 256-bit). > - Current SPARC AES decryption instructions are not compatible with > SunJCE expanded decryption key format. Thus decryption stubs read the > original key (passed as an input parameter) and perform decryption key > expansion using hardware instructions. > - Multi-block decryption stub can perform decryption for 2 * 16-byte > blocks at a time. > - Encryption stubs use SunJCE expanded encryption key as their is no > incompatibility issue between SPARC AES encryption instructions and SunJCE > expanded encryption keys. > * src/cpu/sparc/vm/sparc.ad, src/cpu/x86/vm/x86.ad and > src/share/vm/opto/matcher.hpp > - The additional original key array reference parameter is required > only on the SPARC platform. This code guards it from being passed to the > x86 AES stub routines. > * src/cpu/sparc/vm/vm_version_sparc.cpp, src/cpu/sparc/vm/vm_version_sparc.hpp > and src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp > - Detect AES capabilities of the underlying CPU. > - Enable UseAES and UseAESIntrinsics flags if the underlying CPU > supports AES instructions and neither of them is explicitly disabled on the > command-line. Generate warning message if either of these flags are enabled > on the command-line whereas the underlying CPU does not support AES > instructions. > * src/share/vm/classfile/vmSymbols.hpp > - Fix for "8012900: CICO ignores AAD in GCM mode" changes return > type of com.sun.crypto.provider.CipherBlockChaining.encrypt() and > com.sun.crypto.provider.CipherBlockChaining.decrypt() from void to int. > Method signature in intrinsics definition had to be changed accordingly. > * src/share/vm/opto/library_call.cpp > - Adds a new method to read 'lastKey' field of > com.sun.crypto.provider.AESCrypt class which holds the original key. > - Passes additional input parameter, original key array reference, > to the AES stubs only on the SPARC platform. > - Addresses change in return value from 'void' to 'int' in case of > multi-block CBC stubs. > * src/share/vm/opto/runtime.cpp > - Reads the additional input parameter (original key reference) only > on SPARC platform. > - Addresses change in return value from 'void' to 'int' in case of > multi-block CBC stubs. > * hotspot/test/compiler/7184394/TestAESMain.java > - This test case was contributed as part of the x86 AES intrinsics > work by Tom Deneau @AMD. Fixed incorrect nano-second to milli-second > conversion code. Added warm-up phase since this test case can also be used > for performance testing. > > Testing: jtreg, ctw, nsk and JPRT > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131114/35d90c48/attachment.html From roland.westrelin at oracle.com Fri Nov 15 03:46:44 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 15 Nov 2013 12:46:44 +0100 Subject: RFR(S): 8028308: nsk regression, assert(obj->is_oop()) failed: not an oop Message-ID: <593E8155-0DCF-4D79-A153-35B0ACDC1E99@oracle.com> http://cr.openjdk.java.net/~roland/8028308/webrev.00/ When the stack bang in the deopt blob results in an exception being thrown, rbp must contain the value to be restored on return to the caller so that it is properly set when the exception is propagated to the caller. It is not the case right now. The test case is not the most robust one because it needs the compiler to generate code that keeps an object in rbp across the call to m1 in m3. The failure reproduces at least on 32bit. Roland. From vladimir.kozlov at oracle.com Fri Nov 15 10:02:59 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Nov 2013 10:02:59 -0800 Subject: RFR(S): 8028308: nsk regression, assert(obj->is_oop()) failed: not an oop In-Reply-To: <593E8155-0DCF-4D79-A153-35B0ACDC1E99@oracle.com> References: <593E8155-0DCF-4D79-A153-35B0ACDC1E99@oracle.com> Message-ID: <528661D3.80303@oracle.com> Roland, It looks good. Can you use one line for next as in other places?: + __ movptr(rbp, + Address(rdi, + Deoptimization::UnrollBlock::initial_info_offset_in_bytes())); Thanks, Vladimir On 11/15/13 3:46 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8028308/webrev.00/ > > When the stack bang in the deopt blob results in an exception being thrown, rbp must contain the value to be restored on return to the caller so that it is properly set when the exception is propagated to the caller. It is not the case right now. > > The test case is not the most robust one because it needs the compiler to generate code that keeps an object in rbp across the call to m1 in m3. The failure reproduces at least on 32bit. > > Roland. > From shrinivas.joshi at oracle.com Fri Nov 15 11:47:09 2013 From: shrinivas.joshi at oracle.com (Shrinivas Joshi) Date: Fri, 15 Nov 2013 11:47:09 -0800 Subject: RFR(L): 8002074: Support for AES on SPARC In-Reply-To: References: <52858828.2090105@oracle.com> Message-ID: <52867A3D.6070809@oracle.com> Hi Vitaly, Thanks for looking into this. I did miss adding string format. I will address that. Also, I should add a check for UseVIS > 0 while setting UseAES and UseAESIntrinsics flags since AES stubs use FXOR instructions which are VIS 1 extension instructions. -Shrinivas On 11/14/2013 8:15 PM, Vitaly Davidovich wrote: > > Hi Shrinivas, > > In vm_version_sparc.cpp line 253 you added aes printing but the string > format is missing a new corresponding %s? Also, is the 512 buf size > still sufficient if all features are present? I didn't attempt to > count :). > > Sent from my phone > > On Nov 14, 2013 9:36 PM, "Shrinivas Joshi" > wrote: > > Hi, > > Can I please request reviews for the following change? Target JDK > release for this change would be the next update of JDK 8 / JDK 9. > > Thanks, > -Shrinivas > > RFE: https://bugs.openjdk.java.net/browse/JDK-8002074 > Webrev: http://cr.openjdk.java.net/~kvn/8002074/webrev.02/ > > > Summary: This change adds intrinsics/stub routines support for > single-block and multi-block (as used by Cipher Block Chaining > mode) AES encryption and decryption operations on the SPARC > platform. These intrinsics are available only when the application > is configured to use SunJCE crypto provider. These stubs make use > of efficient hardware AES instructions and thus offer significant > performance improvements over JITed code. AES intrinsics are > enabled by default on SPARC platforms that support AES > instructions. They can be explicitly enabled or disabled on the > command-line using UseAES and UseAESIntrinsics JVM flags. > > Summary of source code changes: > * src/cpu/sparc/vm/assembler_sparc.hpp > - Adds support for all 3-operand and 4-operand SPARC AES > instructions. Also adds support for floating-point XOR > (FXORs/FXORd) instructions. FXOR instructions are used in the AES > stub routines > * src/cpu/sparc/vm/stubGenerator_sparc.cpp > - Defines stubs for single-block and multi-block AES > encryption and decryption routines supporting all key sizes > (128-bit, 192-bit and 256-bit). > - Current SPARC AES decryption instructions are not > compatible with SunJCE expanded decryption key format. Thus > decryption stubs read the original key (passed as an input > parameter) and perform decryption key expansion using hardware > instructions. > - Multi-block decryption stub can perform decryption for 2 * > 16-byte blocks at a time. > - Encryption stubs use SunJCE expanded encryption key as > their is no incompatibility issue between SPARC AES encryption > instructions and SunJCE expanded encryption keys. > * src/cpu/sparc/vm/sparc.ad , > src/cpu/x86/vm/x86.ad and > src/share/vm/opto/matcher.hpp > - The additional original key array reference parameter is > required only on the SPARC platform. This code guards it from > being passed to the x86 AES stub routines. > * src/cpu/sparc/vm/vm_version_sparc.cpp, > src/cpu/sparc/vm/vm_version_sparc.hpp and > src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp > - Detect AES capabilities of the underlying CPU. > - Enable UseAES and UseAESIntrinsics flags if the underlying > CPU supports AES instructions and neither of them is explicitly > disabled on the command-line. Generate warning message if either > of these flags are enabled on the command-line whereas the > underlying CPU does not support AES instructions. > * src/share/vm/classfile/vmSymbols.hpp > - Fix for "8012900: CICO ignores AAD in GCM mode" changes > return type of > com.sun.crypto.provider.CipherBlockChaining.encrypt() and > com.sun.crypto.provider.CipherBlockChaining.decrypt() from void to > int. Method signature in intrinsics definition had to be changed > accordingly. > * src/share/vm/opto/library_call.cpp > - Adds a new method to read 'lastKey' field of > com.sun.crypto.provider.AESCrypt class which holds the original key. > - Passes additional input parameter, original key array > reference, to the AES stubs only on the SPARC platform. > - Addresses change in return value from 'void' to 'int' in > case of multi-block CBC stubs. > * src/share/vm/opto/runtime.cpp > - Reads the additional input parameter (original key > reference) only on SPARC platform. > - Addresses change in return value from 'void' to 'int' in > case of multi-block CBC stubs. > * hotspot/test/compiler/7184394/TestAESMain.java > - This test case was contributed as part of the x86 AES > intrinsics work by Tom Deneau @AMD. Fixed incorrect nano-second to > milli-second conversion code. Added warm-up phase since this test > case can also be used for performance testing. > > Testing: jtreg, ctw, nsk and JPRT > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131115/3a028201/attachment-0001.html From vladimir.kozlov at oracle.com Fri Nov 15 12:22:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Nov 2013 12:22:13 -0800 Subject: RFR(L): 8002074: Support for AES on SPARC In-Reply-To: <52858828.2090105@oracle.com> References: <52858828.2090105@oracle.com> Message-ID: <52868275.2020207@oracle.com> Shrinivas, I suggested before to use loops to generated less code lines in stubs. For example, next: + // load expanded key + __ ldf(FloatRegisterImpl::D, key, 0, F0); + __ ldf(FloatRegisterImpl::D, key, 8, F2); + ... + __ ldf(FloatRegisterImpl::D, key, 152, F38); could be replaced with // load expanded key for (int i = 0; i < 40; i += 2) { __ ldf(FloatRegisterImpl::D, key, i*4, as_FloatRegister(i)); } Next: + __ aes_eround01(F4, F54, F56, F58); //round 1 + __ aes_eround23(F6, F54, F56, F60); + __ aes_eround01(F8, F58, F60, F54); //round 2 + __ aes_eround23(F10, F58, F60, F56); ... + __ aes_eround01(F36, F54, F56, F58); //round 9 + __ aes_eround23(F38, F54, F56, F60); could be: for (int i = 4; i < 36; i += 8) { __ aes_eround01(as_FloatRegister(i ), F54, F56, F58); //round 1 __ aes_eround23(as_FloatRegister(i+2), F54, F56, F60); __ aes_eround01(as_FloatRegister(i+4), F58, F60, F54); //round 2 __ aes_eround23(as_FloatRegister(i+6), F58, F60, F56); } __ aes_eround01(F36, F54, F56, F58); //round 9 __ aes_eround23(F38, F54, F56, F60); And other places where there is repetitive pattern. Thanks, Vladimir On 11/14/13 6:34 PM, Shrinivas Joshi wrote: > Hi, > > Can I please request reviews for the following change? Target JDK > release for this change would be the next update of JDK 8 / JDK 9. > > Thanks, > -Shrinivas > > RFE: https://bugs.openjdk.java.net/browse/JDK-8002074 > Webrev: http://cr.openjdk.java.net/~kvn/8002074/webrev.02/ > > Summary: This change adds intrinsics/stub routines support for > single-block and multi-block (as used by Cipher Block Chaining mode) AES > encryption and decryption operations on the SPARC platform. These > intrinsics are available only when the application is configured to use > SunJCE crypto provider. These stubs make use of efficient hardware AES > instructions and thus offer significant performance improvements over > JITed code. AES intrinsics are enabled by default on SPARC platforms > that support AES instructions. They can be explicitly enabled or > disabled on the command-line using UseAES and UseAESIntrinsics JVM flags. > > Summary of source code changes: > * src/cpu/sparc/vm/assembler_sparc.hpp > - Adds support for all 3-operand and 4-operand SPARC AES > instructions. Also adds support for floating-point XOR (FXORs/FXORd) > instructions. FXOR instructions are used in the AES stub routines > * src/cpu/sparc/vm/stubGenerator_sparc.cpp > - Defines stubs for single-block and multi-block AES encryption > and decryption routines supporting all key sizes (128-bit, 192-bit and > 256-bit). > - Current SPARC AES decryption instructions are not compatible > with SunJCE expanded decryption key format. Thus decryption stubs read > the original key (passed as an input parameter) and perform decryption > key expansion using hardware instructions. > - Multi-block decryption stub can perform decryption for 2 * > 16-byte blocks at a time. > - Encryption stubs use SunJCE expanded encryption key as their is > no incompatibility issue between SPARC AES encryption instructions and > SunJCE expanded encryption keys. > * src/cpu/sparc/vm/sparc.ad, src/cpu/x86/vm/x86.ad and > src/share/vm/opto/matcher.hpp > - The additional original key array reference parameter is > required only on the SPARC platform. This code guards it from being > passed to the x86 AES stub routines. > * src/cpu/sparc/vm/vm_version_sparc.cpp, > src/cpu/sparc/vm/vm_version_sparc.hpp and > src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp > - Detect AES capabilities of the underlying CPU. > - Enable UseAES and UseAESIntrinsics flags if the underlying CPU > supports AES instructions and neither of them is explicitly disabled on > the command-line. Generate warning message if either of these flags are > enabled on the command-line whereas the underlying CPU does not support > AES instructions. > * src/share/vm/classfile/vmSymbols.hpp > - Fix for "8012900: CICO ignores AAD in GCM mode" changes return > type of com.sun.crypto.provider.CipherBlockChaining.encrypt() and > com.sun.crypto.provider.CipherBlockChaining.decrypt() from void to int. > Method signature in intrinsics definition had to be changed accordingly. > * src/share/vm/opto/library_call.cpp > - Adds a new method to read 'lastKey' field of > com.sun.crypto.provider.AESCrypt class which holds the original key. > - Passes additional input parameter, original key array > reference, to the AES stubs only on the SPARC platform. > - Addresses change in return value from 'void' to 'int' in case > of multi-block CBC stubs. > * src/share/vm/opto/runtime.cpp > - Reads the additional input parameter (original key reference) > only on SPARC platform. > - Addresses change in return value from 'void' to 'int' in case > of multi-block CBC stubs. > * hotspot/test/compiler/7184394/TestAESMain.java > - This test case was contributed as part of the x86 AES > intrinsics work by Tom Deneau @AMD. Fixed incorrect nano-second to > milli-second conversion code. Added warm-up phase since this test case > can also be used for performance testing. > > Testing: jtreg, ctw, nsk and JPRT From shrinivas.joshi at oracle.com Fri Nov 15 12:30:58 2013 From: shrinivas.joshi at oracle.com (Shrinivas Joshi) Date: Fri, 15 Nov 2013 12:30:58 -0800 Subject: RFR(L): 8002074: Support for AES on SPARC In-Reply-To: <52868275.2020207@oracle.com> References: <52858828.2090105@oracle.com> <52868275.2020207@oracle.com> Message-ID: <52868482.6070803@oracle.com> Hi Vladimir, Thanks for the feedback. I will make these changes and update the webrev. -Shrinivas On 11/15/2013 12:22 PM, Vladimir Kozlov wrote: > Shrinivas, > > I suggested before to use loops to generated less code lines in stubs. > For example, next: > > + // load expanded key > + __ ldf(FloatRegisterImpl::D, key, 0, F0); > + __ ldf(FloatRegisterImpl::D, key, 8, F2); > + ... > + __ ldf(FloatRegisterImpl::D, key, 152, F38); > > could be replaced with > > // load expanded key > for (int i = 0; i < 40; i += 2) { > __ ldf(FloatRegisterImpl::D, key, i*4, as_FloatRegister(i)); > } > > Next: > > + __ aes_eround01(F4, F54, F56, F58); //round 1 > + __ aes_eround23(F6, F54, F56, F60); > + __ aes_eround01(F8, F58, F60, F54); //round 2 > + __ aes_eround23(F10, F58, F60, F56); > ... > + __ aes_eround01(F36, F54, F56, F58); //round 9 > + __ aes_eround23(F38, F54, F56, F60); > > could be: > > for (int i = 4; i < 36; i += 8) { > __ aes_eround01(as_FloatRegister(i ), F54, F56, F58); //round 1 > __ aes_eround23(as_FloatRegister(i+2), F54, F56, F60); > __ aes_eround01(as_FloatRegister(i+4), F58, F60, F54); //round 2 > __ aes_eround23(as_FloatRegister(i+6), F58, F60, F56); > } > __ aes_eround01(F36, F54, F56, F58); //round 9 > __ aes_eround23(F38, F54, F56, F60); > > > And other places where there is repetitive pattern. > > Thanks, > Vladimir > > On 11/14/13 6:34 PM, Shrinivas Joshi wrote: >> Hi, >> >> Can I please request reviews for the following change? Target JDK >> release for this change would be the next update of JDK 8 / JDK 9. >> >> Thanks, >> -Shrinivas >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8002074 >> Webrev: http://cr.openjdk.java.net/~kvn/8002074/webrev.02/ >> >> Summary: This change adds intrinsics/stub routines support for >> single-block and multi-block (as used by Cipher Block Chaining mode) AES >> encryption and decryption operations on the SPARC platform. These >> intrinsics are available only when the application is configured to use >> SunJCE crypto provider. These stubs make use of efficient hardware AES >> instructions and thus offer significant performance improvements over >> JITed code. AES intrinsics are enabled by default on SPARC platforms >> that support AES instructions. They can be explicitly enabled or >> disabled on the command-line using UseAES and UseAESIntrinsics JVM >> flags. >> >> Summary of source code changes: >> * src/cpu/sparc/vm/assembler_sparc.hpp >> - Adds support for all 3-operand and 4-operand SPARC AES >> instructions. Also adds support for floating-point XOR (FXORs/FXORd) >> instructions. FXOR instructions are used in the AES stub routines >> * src/cpu/sparc/vm/stubGenerator_sparc.cpp >> - Defines stubs for single-block and multi-block AES encryption >> and decryption routines supporting all key sizes (128-bit, 192-bit and >> 256-bit). >> - Current SPARC AES decryption instructions are not compatible >> with SunJCE expanded decryption key format. Thus decryption stubs read >> the original key (passed as an input parameter) and perform decryption >> key expansion using hardware instructions. >> - Multi-block decryption stub can perform decryption for 2 * >> 16-byte blocks at a time. >> - Encryption stubs use SunJCE expanded encryption key as their is >> no incompatibility issue between SPARC AES encryption instructions and >> SunJCE expanded encryption keys. >> * src/cpu/sparc/vm/sparc.ad, src/cpu/x86/vm/x86.ad and >> src/share/vm/opto/matcher.hpp >> - The additional original key array reference parameter is >> required only on the SPARC platform. This code guards it from being >> passed to the x86 AES stub routines. >> * src/cpu/sparc/vm/vm_version_sparc.cpp, >> src/cpu/sparc/vm/vm_version_sparc.hpp and >> src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp >> - Detect AES capabilities of the underlying CPU. >> - Enable UseAES and UseAESIntrinsics flags if the underlying CPU >> supports AES instructions and neither of them is explicitly disabled on >> the command-line. Generate warning message if either of these flags are >> enabled on the command-line whereas the underlying CPU does not support >> AES instructions. >> * src/share/vm/classfile/vmSymbols.hpp >> - Fix for "8012900: CICO ignores AAD in GCM mode" changes return >> type of com.sun.crypto.provider.CipherBlockChaining.encrypt() and >> com.sun.crypto.provider.CipherBlockChaining.decrypt() from void to int. >> Method signature in intrinsics definition had to be changed accordingly. >> * src/share/vm/opto/library_call.cpp >> - Adds a new method to read 'lastKey' field of >> com.sun.crypto.provider.AESCrypt class which holds the original key. >> - Passes additional input parameter, original key array >> reference, to the AES stubs only on the SPARC platform. >> - Addresses change in return value from 'void' to 'int' in case >> of multi-block CBC stubs. >> * src/share/vm/opto/runtime.cpp >> - Reads the additional input parameter (original key reference) >> only on SPARC platform. >> - Addresses change in return value from 'void' to 'int' in case >> of multi-block CBC stubs. >> * hotspot/test/compiler/7184394/TestAESMain.java >> - This test case was contributed as part of the x86 AES >> intrinsics work by Tom Deneau @AMD. Fixed incorrect nano-second to >> milli-second conversion code. Added warm-up phase since this test case >> can also be used for performance testing. >> >> Testing: jtreg, ctw, nsk and JPRT > > From alejandro.murillo at oracle.com Fri Nov 15 13:13:59 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 15 Nov 2013 21:13:59 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 33 new changesets Message-ID: <20131115211506.3DD8F62629@hg.openjdk.java.net> Changeset: e39b138b2518 Author: acorn Date: 2013-10-19 18:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/hotspot/rev/205834867346 Merge Changeset: 9ebaac78a8a0 Author: amurillo Date: 2013-11-05 14:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9ebaac78a8a0 Merge Changeset: 842b6ce4dfb4 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/hotspot/rev/e510dfdec6dd Merge Changeset: 52b076e6ffae Author: amurillo Date: 2013-11-08 07:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/52b076e6ffae Added tag hs25-b58 for changeset e510dfdec6dd ! .hgtags Changeset: aec3226be72d Author: cl Date: 2013-11-14 09:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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/hotspot-comp/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/hotspot-comp/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-comp/hotspot/rev/19f8a5d7600b Merge Changeset: fce21ac5968d Author: acorn Date: 2013-11-13 07:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/hotspot/rev/bde526e3667e Merge Changeset: 11b116661830 Author: mgerdin Date: 2013-11-11 16:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/hotspot/rev/755c423791ab Merge ! src/share/vm/prims/whitebox.cpp Changeset: df0df745224c Author: drchase Date: 2013-11-14 15:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/df0df745224c Merge Changeset: 6f206b5d258f Author: drchase Date: 2013-11-14 13:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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/hotspot-comp/hotspot/rev/c78d517c7ea4 Merge Changeset: f573d00213b7 Author: amurillo Date: 2013-11-15 07:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/hotspot/rev/854a42db7069 8028444: new hotspot build - hs25-b60 Reviewed-by: jcoomes ! make/hotspot_version From igor.veresov at oracle.com Fri Nov 15 15:40:16 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 15 Nov 2013 15:40:16 -0800 Subject: RFR(S): 8028308: nsk regression, assert(obj->is_oop()) failed: not an oop In-Reply-To: <593E8155-0DCF-4D79-A153-35B0ACDC1E99@oracle.com> References: <593E8155-0DCF-4D79-A153-35B0ACDC1E99@oracle.com> Message-ID: <2A560A95-4F33-4483-B929-63BA94FC2BBE@oracle.com> Looks good. igor On Nov 15, 2013, at 3:46 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8028308/webrev.00/ > > When the stack bang in the deopt blob results in an exception being thrown, rbp must contain the value to be restored on return to the caller so that it is properly set when the exception is propagated to the caller. It is not the case right now. > > The test case is not the most robust one because it needs the compiler to generate code that keeps an object in rbp across the call to m1 in m3. The failure reproduces at least on 32bit. > > Roland. From morris.meyer at sun.com Mon Nov 18 11:42:35 2013 From: morris.meyer at sun.com (Morris Meyer) Date: Mon, 18 Nov 2013 14:42:35 -0500 Subject: RFR(S) 8028319 - ConflictingDefaultsTest.testReabstract spins when running with -mode invoke and -Xcomp Message-ID: <528A6DAB.5070804@sun.com> Could I get a review for this bug? This issue with the defmethod test stems from the invalidation of an abstract method invocation from invokehandle. This comment for the _abstract_method_handler (now changed) pointed out the issue. // Create a special handler for abstract methods. Abstract methods // are never compiled so an i2c entry is somewhat meaningless, but // fill it in with something appropriate just in case. Pass handle // wrong method for the c2i transitions. Many thanks to Vladimir Ivanov and John Rose in helping to track this one down. Vladimir has tested this through JPRT as well as VM testbase + HS/JDK regression in Aurora over the weekend. --morris WEBREV - http://cr.openjdk.java.net/~morris/8028319 JBS - https://bugs.openjdk.java.net/browse/JDK-8023500 duplicate 8028319 - added here for background JBS - https://bugs.openjdk.java.net/browse/JDK-8028319 From morris.meyer at oracle.com Mon Nov 18 11:54:29 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Mon, 18 Nov 2013 14:54:29 -0500 Subject: RFR(S) 8028319: ConflictingDefaultsTest.testReabstract spins when running with -mode invoke and -Xcomp Message-ID: <528A7075.1060106@oracle.com> Folks, Could I get a review for this issue? The issue was that the invalidation of an abstract method invocation (invokehandle in this case) was using handle_wrong_method - which was looping. This comment (now changed) in sharedRuntime helped lead us to the problem. comment for _abstract_method_handler: // Create a special handler for abstract methods. Abstract methods // are never compiled so an i2c entry is somewhat meaningless, but // fill it in with something appropriate just in case. Pass handle // wrong method for the c2i transitions. Thanks to Vladimir Ivanov and John Rose for their help in tracking this one down. --morris JBS - https://bugs.openjdk.java.net/browse/JDK-8028319 WEBREV - http://cr.openjdk.java.net/~morris/8028319 From vladimir.kozlov at oracle.com Mon Nov 18 12:04:22 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Nov 2013 12:04:22 -0800 Subject: RFR(S) 8028319: ConflictingDefaultsTest.testReabstract spins when running with -mode invoke and -Xcomp In-Reply-To: <528A7075.1060106@oracle.com> References: <528A7075.1060106@oracle.com> Message-ID: <528A72C6.5010906@oracle.com> Looks good. Vladimir On 11/18/13 11:54 AM, Morris Meyer wrote: > Folks, > > Could I get a review for this issue? > > The issue was that the invalidation of an abstract method invocation > (invokehandle in this case) was using handle_wrong_method - which was > looping. > > This comment (now changed) in sharedRuntime helped lead us to the problem. > > comment for _abstract_method_handler: > // Create a special handler for abstract methods. Abstract methods > // are never compiled so an i2c entry is somewhat meaningless, but > // fill it in with something appropriate just in case. Pass handle > // wrong method for the c2i transitions. > > Thanks to Vladimir Ivanov and John Rose for their help in tracking this > one down. > > --morris > > JBS - https://bugs.openjdk.java.net/browse/JDK-8028319 > WEBREV - http://cr.openjdk.java.net/~morris/8028319 From david.r.chase at oracle.com Mon Nov 18 12:26:46 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 18 Nov 2013 15:26:46 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: NPE instead of IAE when calling a method Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8016839 Webrev(s): http://cr.openjdk.java.net/~drchase/8016839/webrev-hotspot.00/ http://cr.openjdk.java.net/~drchase/8016839/webrev-jdk.00/ 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 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 and Intel (ARM and PPC are coming, as soon as I can convince JPRT to create the necessary binaries). Testing: final tests TBD, I have been hand-testing (jtreg, defmeth) with no problems. Test case: The test is an enhanced version of the old test for AME-not-NPE. It covers several additional cases of inaccessibility (protected, packaged-protected in a different package) and also includes options to write out the ASM-generated classes to jar files for offline inspection and modification (we might want to put that somewhere that it's easy to reuse, if we like it). I write jar files to deal with the two problems of not knowing much about the platform file system, and because the same class name is used several times in the tests. The "write" mode writes out the files, the "read" mode use those same files instead of the program-supplied bytes. From roland.westrelin at oracle.com Mon Nov 18 12:29:20 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 18 Nov 2013 21:29:20 +0100 Subject: 8028536: Test cases to cover type system fixes pushed with 8024070 Message-ID: <6D020AB7-199E-47AD-98BF-C7A046D790C7@oracle.com> The changeset for type speculation includes some fixes to the type system. Test cases that exercise each of the fixes were missing. Here they are. http://cr.openjdk.java.net/~roland/8028536/webrev.00/ Roland. From roland.westrelin at oracle.com Mon Nov 18 12:40:28 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 18 Nov 2013 21:40:28 +0100 Subject: RFR(XS): 8027571: fatal error: meet not symmetric Message-ID: Similarly to what is done for instances, meet of exact classes in upper lattice or constant should fall down to NotNull. http://cr.openjdk.java.net/~roland/8027571/webrev.00/ Roland. From roland.westrelin at oracle.com Mon Nov 18 12:51:57 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 18 Nov 2013 21:51:57 +0100 Subject: RFR(XS): 8028064: tiered may collect wrong receiver type at virtual call Message-ID: <73A3C467-9BCE-4E7F-849C-B28616497B7D@oracle.com> When there?s a unique possible callee method, tiered optimizes profile collection by using the callee?s holder as unique possible class. That?s incorrect. For instance, with this class hierarchy: class A { void m() {} } class B extends A { } and this java code: B b b.m(); the callee?s holder is A but profiling should record B. The class itself should be tested as being final or leaf. http://cr.openjdk.java.net/~roland/8028064/webrev.00/ Roland. From roland.westrelin at oracle.com Mon Nov 18 13:15:49 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 18 Nov 2013 22:15:49 +0100 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed Message-ID: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): const Type *t_not_null = t->join(TypePtr::NOTNULL, true); The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: higher_equal() meet() join() filter() so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). http://cr.openjdk.java.net/~roland/8027422/webrev.00/ Roland. From vladimir.kozlov at oracle.com Mon Nov 18 14:20:17 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Nov 2013 14:20:17 -0800 Subject: 8028536: Test cases to cover type system fixes pushed with 8024070 In-Reply-To: <6D020AB7-199E-47AD-98BF-C7A046D790C7@oracle.com> References: <6D020AB7-199E-47AD-98BF-C7A046D790C7@oracle.com> Message-ID: <528A92A1.70307@oracle.com> Looks good. Vladimir On 11/18/13 12:29 PM, Roland Westrelin wrote: > The changeset for type speculation includes some fixes to the type system. Test cases that exercise each of the fixes were missing. Here they are. > > http://cr.openjdk.java.net/~roland/8028536/webrev.00/ > > Roland. > From igor.veresov at oracle.com Mon Nov 18 14:24:56 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 18 Nov 2013 14:24:56 -0800 Subject: RFR(S) 8028319: ConflictingDefaultsTest.testReabstract spins when running with -mode invoke and -Xcomp In-Reply-To: <528A7075.1060106@oracle.com> References: <528A7075.1060106@oracle.com> Message-ID: <5B24B3A0-D72C-42B2-A9D6-29E5729FD495@oracle.com> Looks fine igor On Nov 18, 2013, at 11:54 AM, Morris Meyer wrote: > Folks, > > Could I get a review for this issue? > > The issue was that the invalidation of an abstract method invocation (invokehandle in this case) was using handle_wrong_method - which was looping. > > This comment (now changed) in sharedRuntime helped lead us to the problem. > > comment for _abstract_method_handler: > // Create a special handler for abstract methods. Abstract methods > // are never compiled so an i2c entry is somewhat meaningless, but > // fill it in with something appropriate just in case. Pass handle > // wrong method for the c2i transitions. > > Thanks to Vladimir Ivanov and John Rose for their help in tracking this one down. > > --morris > > JBS - https://bugs.openjdk.java.net/browse/JDK-8028319 > WEBREV - http://cr.openjdk.java.net/~morris/8028319 From morris.meyer at oracle.com Mon Nov 18 15:07:01 2013 From: morris.meyer at oracle.com (morris.meyer at oracle.com) Date: Mon, 18 Nov 2013 23:07:01 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8028319: ConflictingDefaultsTest.testReabstract spins when running with -mode invoke and -Xcomp Message-ID: <20131118230715.BBF9B62683@hg.openjdk.java.net> Changeset: 570aaefce624 Author: morris Date: 2013-11-18 12:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From vladimir.kozlov at oracle.com Mon Nov 18 15:27:19 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Nov 2013 15:27:19 -0800 Subject: RFR(XS): 8027571: fatal error: meet not symmetric In-Reply-To: References: Message-ID: <528AA257.2070606@oracle.com> Roland, What code you are referencing: "what is done for instances"? What about case TopPTR meet Constant which produce Constant? Can you, please, also fix comment's indent? And remove space in few cases: 'tap ->'. Thanks, Vladimir On 11/18/13 12:40 PM, Roland Westrelin wrote: > Similarly to what is done for instances, meet of exact classes in upper lattice or constant should fall down to NotNull. > > http://cr.openjdk.java.net/~roland/8027571/webrev.00/ > > Roland. > From vladimir.kozlov at oracle.com Mon Nov 18 15:38:25 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Nov 2013 15:38:25 -0800 Subject: RFR(XS): 8028064: tiered may collect wrong receiver type at virtual call In-Reply-To: <73A3C467-9BCE-4E7F-849C-B28616497B7D@oracle.com> References: <73A3C467-9BCE-4E7F-849C-B28616497B7D@oracle.com> Message-ID: <528AA4F1.6010202@oracle.com> Looks good. Vladimir On 11/18/13 12:51 PM, Roland Westrelin wrote: > When there?s a unique possible callee method, tiered optimizes profile collection by using the callee?s holder as unique possible class. That?s incorrect. For instance, with this class hierarchy: > class A { > void m() {} > } > > class B extends A { > } > > and this java code: > B b > b.m(); > > the callee?s holder is A but profiling should record B. The class itself should be tested as being final or leaf. > > http://cr.openjdk.java.net/~roland/8028064/webrev.00/ > > Roland. > From igor.veresov at oracle.com Mon Nov 18 16:01:55 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 18 Nov 2013 16:01:55 -0800 Subject: RFR(XS): 8028064: tiered may collect wrong receiver type at virtual call In-Reply-To: <73A3C467-9BCE-4E7F-849C-B28616497B7D@oracle.com> References: <73A3C467-9BCE-4E7F-849C-B28616497B7D@oracle.com> Message-ID: <2901119A-B82E-4C45-A299-A16812DAB6AC@oracle.com> Looks ok. Thanks for noticing this. igor On Nov 18, 2013, at 12:51 PM, Roland Westrelin wrote: > When there?s a unique possible callee method, tiered optimizes profile collection by using the callee?s holder as unique possible class. That?s incorrect. For instance, with this class hierarchy: > class A { > void m() {} > } > > class B extends A { > } > > and this java code: > B b > b.m(); > > the callee?s holder is A but profiling should record B. The class itself should be tested as being final or leaf. > > http://cr.openjdk.java.net/~roland/8028064/webrev.00/ > > Roland. From vladimir.kozlov at oracle.com Mon Nov 18 16:34:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Nov 2013 16:34:40 -0800 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> Message-ID: <528AB220.4080309@oracle.com> Next 2 places in type.cpp pass 'true' to meet() unconditionally: 1929 return TypeAry::make(_elem->meet(a->_elem, true), 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? Could you make printing code with 'this_t' aligned again in Type::meet()? thanks, Vladimir On 11/18/13 1:15 PM, Roland Westrelin wrote: > The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): > const Type *t_not_null = t->join(TypePtr::NOTNULL, true); > The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. > In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: > higher_equal() > meet() > join() > filter() > so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. > > I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). > I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). > > http://cr.openjdk.java.net/~roland/8027422/webrev.00/ > > Roland. > From albert.noll at oracle.com Tue Nov 19 00:37:27 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 19 Nov 2013 09:37:27 +0100 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline Message-ID: <528B2347.7010902@oracle.com> Hi all, could I get reviews for this small patch? bug: https://bugs.openjdk.java.net/browse/JDK-8028109 webrev: http://cr.openjdk.java.net/~anoll/8028109/webrev.00/ Problem: 'byte_map_base' in 'cardTableModRefBS.cpp' can have a value that points into the code cache. The x86 stub generator uses 'ExternalAddress' for byte_map_base, which results in creating a relocation entry for 'byte_map_address'. If byte_map_base - by accident - points into the code section of, e.g., a buffer blob, the assert in relocInfo.cpp (line 831 fails) Solution: Change 'ExternalAddress' to 'AddressLiteral' that generates no relocation information for byte_map_base. Other platforms also AddressLiteral without relocation information. Testing: failing test, jprt x86 Many thanks to Roland who helped me in understanding this bug! Best, Albert From roland.westrelin at oracle.com Tue Nov 19 01:00:19 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Nov 2013 10:00:19 +0100 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: <528B2347.7010902@oracle.com> References: <528B2347.7010902@oracle.com> Message-ID: <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> > Solution: Change 'ExternalAddress' to 'AddressLiteral' that generates no relocation information for > byte_map_base. Other platforms also AddressLiteral without relocation information. As mentioned in the thread here: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005151.html in this message: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005161.html not using ExternalAddress disables rip relative addressing. This said, I?m not sure what a clean fix for this would be. Roland. From albert.noll at oracle.com Tue Nov 19 07:59:44 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 19 Nov 2013 16:59:44 +0100 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> References: <528B2347.7010902@oracle.com> <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> Message-ID: <528B8AF0.5050506@oracle.com> Hi Roland, thanks for pointing this out. Here is a patch that executes the assert only if the address we are checking is not byte_map_base. This might not be the most elegant solution, but at least it seems to work. Here is the new webrev: http://cr.openjdk.java.net/~anoll/8028109/webrev.01/ Best, Albert On 11/19/2013 10:00 AM, Roland Westrelin wrote: >> Solution: Change 'ExternalAddress' to 'AddressLiteral' that generates no relocation information for >> byte_map_base. Other platforms also AddressLiteral without relocation information. > As mentioned in the thread here: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005151.html > in this message: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005161.html > > not using ExternalAddress disables rip relative addressing. > This said, I?m not sure what a clean fix for this would be. > > Roland. From roland.westrelin at oracle.com Tue Nov 19 09:07:07 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Nov 2013 18:07:07 +0100 Subject: RFR(S): 8028308: nsk regression, assert(obj->is_oop()) failed: not an oop In-Reply-To: <528661D3.80303@oracle.com> References: <593E8155-0DCF-4D79-A153-35B0ACDC1E99@oracle.com> <528661D3.80303@oracle.com> Message-ID: <556D9B11-183E-46B6-BB92-27DFE417C146@oracle.com> Thanks for the review. > It looks good. Can you use one line for next as in other places?: > > + __ movptr(rbp, > + Address(rdi, > + Deoptimization::UnrollBlock::initial_info_offset_in_bytes())); > I will. Do you want me to also fix the other similar lines in generate_uncommon_trap_blob // Load address of array of frame pcs into rcx (address*) __ movptr(rcx, Address(rdi, Deoptimization::UnrollBlock::frame_pcs_offset_in_bytes())); // Trash the return pc __ addptr(rsp, wordSize); // Load address of array of frame sizes into rsi (intptr_t*) __ movptr(rsi, Address(rdi, Deoptimization::UnrollBlock:: frame_sizes_offset_in_bytes())); // Counter __ movl(rdx, Address(rdi, Deoptimization::UnrollBlock:: number_of_frames_offset_in_bytes())); // (int) Roland. > Thanks, > Vladimir > > On 11/15/13 3:46 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8028308/webrev.00/ >> >> When the stack bang in the deopt blob results in an exception being thrown, rbp must contain the value to be restored on return to the caller so that it is properly set when the exception is propagated to the caller. It is not the case right now. >> >> The test case is not the most robust one because it needs the compiler to generate code that keeps an object in rbp across the call to m1 in m3. The failure reproduces at least on 32bit. >> >> Roland. >> From roland.westrelin at oracle.com Tue Nov 19 09:07:36 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Nov 2013 18:07:36 +0100 Subject: RFR(S): 8028308: nsk regression, assert(obj->is_oop()) failed: not an oop In-Reply-To: <2A560A95-4F33-4483-B929-63BA94FC2BBE@oracle.com> References: <593E8155-0DCF-4D79-A153-35B0ACDC1E99@oracle.com> <2A560A95-4F33-4483-B929-63BA94FC2BBE@oracle.com> Message-ID: Thanks for the review, Igor. Roland. On Nov 16, 2013, at 12:40 AM, Igor Veresov wrote: > Looks good. > > igor > > On Nov 15, 2013, at 3:46 AM, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~roland/8028308/webrev.00/ >> >> When the stack bang in the deopt blob results in an exception being thrown, rbp must contain the value to be restored on return to the caller so that it is properly set when the exception is propagated to the caller. It is not the case right now. >> >> The test case is not the most robust one because it needs the compiler to generate code that keeps an object in rbp across the call to m1 in m3. The failure reproduces at least on 32bit. >> >> Roland. > From roland.westrelin at oracle.com Tue Nov 19 09:08:05 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Nov 2013 18:08:05 +0100 Subject: 8028536: Test cases to cover type system fixes pushed with 8024070 In-Reply-To: <528A92A1.70307@oracle.com> References: <6D020AB7-199E-47AD-98BF-C7A046D790C7@oracle.com> <528A92A1.70307@oracle.com> Message-ID: <164C0048-23FE-4E3D-9EFF-D5E44B32C977@oracle.com> Thanks for the review, Vladimir. Roland. On Nov 18, 2013, at 11:20 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 11/18/13 12:29 PM, Roland Westrelin wrote: >> The changeset for type speculation includes some fixes to the type system. Test cases that exercise each of the fixes were missing. Here they are. >> >> http://cr.openjdk.java.net/~roland/8028536/webrev.00/ >> >> Roland. >> From roland.westrelin at oracle.com Tue Nov 19 09:13:36 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Nov 2013 18:13:36 +0100 Subject: RFR(XS): 8028064: tiered may collect wrong receiver type at virtual call In-Reply-To: <528AA4F1.6010202@oracle.com> References: <73A3C467-9BCE-4E7F-849C-B28616497B7D@oracle.com> <528AA4F1.6010202@oracle.com> Message-ID: Thanks for the review, Vladimir. Roland. > Looks good. > > Vladimir > > On 11/18/13 12:51 PM, Roland Westrelin wrote: >> When there?s a unique possible callee method, tiered optimizes profile collection by using the callee?s holder as unique possible class. That?s incorrect. For instance, with this class hierarchy: >> class A { >> void m() {} >> } >> >> class B extends A { >> } >> >> and this java code: >> B b >> b.m(); >> >> the callee?s holder is A but profiling should record B. The class itself should be tested as being final or leaf. >> >> http://cr.openjdk.java.net/~roland/8028064/webrev.00/ >> >> Roland. >> From roland.westrelin at oracle.com Tue Nov 19 09:13:53 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Nov 2013 18:13:53 +0100 Subject: RFR(XS): 8028064: tiered may collect wrong receiver type at virtual call In-Reply-To: <2901119A-B82E-4C45-A299-A16812DAB6AC@oracle.com> References: <73A3C467-9BCE-4E7F-849C-B28616497B7D@oracle.com> <2901119A-B82E-4C45-A299-A16812DAB6AC@oracle.com> Message-ID: <6D2DB29E-604F-4615-B8B9-84FCD008D0C1@oracle.com> Thanks for the review, Igor. Roland. > Looks ok. Thanks for noticing this. > > igor > > On Nov 18, 2013, at 12:51 PM, Roland Westrelin wrote: > >> When there?s a unique possible callee method, tiered optimizes profile collection by using the callee?s holder as unique possible class. That?s incorrect. For instance, with this class hierarchy: >> class A { >> void m() {} >> } >> >> class B extends A { >> } >> >> and this java code: >> B b >> b.m(); >> >> the callee?s holder is A but profiling should record B. The class itself should be tested as being final or leaf. >> >> http://cr.openjdk.java.net/~roland/8028064/webrev.00/ >> >> Roland. > From roland.westrelin at oracle.com Tue Nov 19 09:24:48 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Nov 2013 18:24:48 +0100 Subject: RFR(XS): 8027571: fatal error: meet not symmetric In-Reply-To: <528AA257.2070606@oracle.com> References: <528AA257.2070606@oracle.com> Message-ID: <3CDD3E39-E0B2-4304-95E0-0308EAA2FF2D@oracle.com> Hi Vladimir, Thanks for reviewing this. > What code you are referencing: "what is done for instances?? I?m referencing to this: 3464 // Since klasses are different, we require a LCA in the Java 3465 // class hierarchy - which means we have to fall to at least NotNull. 3466 if( ptr == TopPTR || ptr == AnyNull || ptr == Constant ) 3467 ptr = NotNull; > What about case TopPTR meet Constant which produce Constant? For instances, that case goes down to NotNull in some cases. > Can you, please, also fix comment's indent? And remove space in few cases: 'tap ->?. Sure. Roland. > > Thanks, > Vladimir > > On 11/18/13 12:40 PM, Roland Westrelin wrote: >> Similarly to what is done for instances, meet of exact classes in upper lattice or constant should fall down to NotNull. >> >> http://cr.openjdk.java.net/~roland/8027571/webrev.00/ >> >> Roland. >> From vladimir.kozlov at oracle.com Tue Nov 19 11:36:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Nov 2013 11:36:40 -0800 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: <528B8AF0.5050506@oracle.com> References: <528B2347.7010902@oracle.com> <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> <528B8AF0.5050506@oracle.com> Message-ID: <528BBDC8.9010804@oracle.com> Last version is not good because it may hide bug when wrong address matches byte_map_base value. Original Tom's fix also hides problems. MacroAssembler::g1_write_barrier_post() and store_check_part_2() are used only in interpreter. It does not make sense to optimize it. Note, x86 has limited throughput for address calculations. And one instruction is only generated if this address is 32-bit which may be not true then you have to move it into register too. Anyway, we can go case by case and avoid ExternalAddress in 64-bit VM because code allows us to do that: In both cases in c1_Runtime1_x86.cpp and in MacroAssembler::g1_write_barrier_post() there is separate lea() instruction for LP64 which could be replaced with mov to load constant. MacroAssembler::store_check_part_2() is different case which we may prefer to use in other cases. Note, as_Address(ArrayAddress adr) generates lea() instruction again. Which means code for 32-bit VM in c1_Runtime1_x86.cpp generates 2 lea instructions and not one: __ leal(card_addr, __ as_Address(ArrayAddress(cardtable, index))); What I am saying is lets use mov instruction to load byte_map_base instead of usiong ExternalAddress because we don't need relocation for it and because in reality (with all past fixes) we will generate the same number of instructions. Regards, Vladimir On 11/19/13 7:59 AM, Albert Noll wrote: > Hi Roland, > > thanks for pointing this out. Here is a patch that executes the assert > only if > the address we are checking is not byte_map_base. This might not be the > most > elegant solution, but at least it seems to work. > > Here is the new webrev: > http://cr.openjdk.java.net/~anoll/8028109/webrev.01/ > > Best, > Albert > > > On 11/19/2013 10:00 AM, Roland Westrelin wrote: >>> Solution: Change 'ExternalAddress' to 'AddressLiteral' that generates >>> no relocation information for >>> byte_map_base. Other platforms also AddressLiteral >>> without relocation information. >> As mentioned in the thread here: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005151.html >> >> in this message: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005161.html >> >> >> not using ExternalAddress disables rip relative addressing. >> This said, I?m not sure what a clean fix for this would be. >> >> Roland. > From roland.westrelin at oracle.com Tue Nov 19 11:45:19 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Nov 2013 20:45:19 +0100 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <528AB220.4080309@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> Message-ID: <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> Thanks for reviewing this, Vladimir. On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: > Next 2 places in type.cpp pass 'true' to meet() unconditionally: > > 1929 return TypeAry::make(_elem->meet(a->_elem, true), > > 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); > > Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? You?re right. It probably should. So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? > Could you make printing code with 'this_t' aligned again in Type::meet()? Sure. Roland. > > thanks, > Vladimir > > On 11/18/13 1:15 PM, Roland Westrelin wrote: >> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >> higher_equal() >> meet() >> join() >> filter() >> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >> >> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >> >> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >> >> Roland. >> From vladimir.kozlov at oracle.com Tue Nov 19 11:49:19 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Nov 2013 11:49:19 -0800 Subject: RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed In-Reply-To: <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> References: <6091B2DE-F7F3-4BB0-A087-3C83687C30F3@oracle.com> <528AB220.4080309@oracle.com> <9F6A4515-7B80-4733-B686-D8962FA977F7@oracle.com> Message-ID: <528BC0BF.8070803@oracle.com> On 11/19/13 11:45 AM, Roland Westrelin wrote: > Thanks for reviewing this, Vladimir. > > On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov wrote: > >> Next 2 places in type.cpp pass 'true' to meet() unconditionally: >> >> 1929 return TypeAry::make(_elem->meet(a->_elem, true), >> >> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary(); >> >> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type? > > You?re right. It probably should. > So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don?t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right? Right, passing 'true' will work in all cases then. Thanks, Vladimir > >> Could you make printing code with 'this_t' aligned again in Type::meet()? > > Sure. > > Roland. > >> >> thanks, >> Vladimir >> >> On 11/18/13 1:15 PM, Roland Westrelin wrote: >>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null(): >>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true); >>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric. >>> In many places where we mix a TypePtr with a TypeOopPtr we actually don?t care about the speculative part. I changed the following operations on Type: >>> higher_equal() >>> meet() >>> join() >>> filter() >>> so that by default they don?t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it. >>> >>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn?t drop the speculative part of the type during Compile::remove_speculative_types(). >>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL). >>> >>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/ >>> >>> Roland. >>> > From igor.veresov at oracle.com Tue Nov 19 11:57:26 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 19 Nov 2013 11:57:26 -0800 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: <528BBDC8.9010804@oracle.com> References: <528B2347.7010902@oracle.com> <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> <528B8AF0.5050506@oracle.com> <528BBDC8.9010804@oracle.com> Message-ID: Except we will need some relocation info for it if we plan to do snapshotting. igor On Nov 19, 2013, at 11:36 AM, Vladimir Kozlov wrote: > Last version is not good because it may hide bug when wrong address matches byte_map_base value. Original Tom's fix also hides problems. > > MacroAssembler::g1_write_barrier_post() and store_check_part_2() are used only in interpreter. It does not make sense to optimize it. Note, x86 has limited throughput for address calculations. And one instruction is only generated if this address is 32-bit which may be not true then you have to move it into register too. > > Anyway, we can go case by case and avoid ExternalAddress in 64-bit VM because code allows us to do that: > > In both cases in c1_Runtime1_x86.cpp and in MacroAssembler::g1_write_barrier_post() there is separate lea() instruction for LP64 which could be replaced with mov to load constant. > > MacroAssembler::store_check_part_2() is different case which we may prefer to use in other cases. Note, as_Address(ArrayAddress adr) generates lea() instruction again. Which means code for 32-bit VM in c1_Runtime1_x86.cpp generates 2 lea instructions and not one: > > __ leal(card_addr, __ as_Address(ArrayAddress(cardtable, index))); > > What I am saying is lets use mov instruction to load byte_map_base instead of usiong ExternalAddress because we don't need relocation for it and because in reality (with all past fixes) we will generate the same number of instructions. > > Regards, > Vladimir > > On 11/19/13 7:59 AM, Albert Noll wrote: >> Hi Roland, >> >> thanks for pointing this out. Here is a patch that executes the assert >> only if >> the address we are checking is not byte_map_base. This might not be the >> most >> elegant solution, but at least it seems to work. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~anoll/8028109/webrev.01/ >> >> Best, >> Albert >> >> >> On 11/19/2013 10:00 AM, Roland Westrelin wrote: >>>> Solution: Change 'ExternalAddress' to 'AddressLiteral' that generates >>>> no relocation information for >>>> byte_map_base. Other platforms also AddressLiteral >>>> without relocation information. >>> As mentioned in the thread here: >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005151.html >>> >>> in this message: >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005161.html >>> >>> >>> not using ExternalAddress disables rip relative addressing. >>> This said, I?m not sure what a clean fix for this would be. >>> >>> Roland. >> From vladimir.kozlov at oracle.com Tue Nov 19 12:08:34 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Nov 2013 12:08:34 -0800 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: References: <528B2347.7010902@oracle.com> <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> <528B8AF0.5050506@oracle.com> <528BBDC8.9010804@oracle.com> Message-ID: <528BC542.6090108@oracle.com> On 11/19/13 11:57 AM, Igor Veresov wrote: > Except we will need some relocation info for it if we plan to do snapshotting. True, but after Tom's fix it does not have a relocation in all cases already: http://cr.openjdk.java.net/~never/6777083/src/cpu/x86/vm/assembler_x86.hpp.udiff.html And I think, there are places where we don't use ExternalAddress so we may need to solve serialization differently later. Thanks, Vladimir > > igor > > On Nov 19, 2013, at 11:36 AM, Vladimir Kozlov wrote: > >> Last version is not good because it may hide bug when wrong address matches byte_map_base value. Original Tom's fix also hides problems. >> >> MacroAssembler::g1_write_barrier_post() and store_check_part_2() are used only in interpreter. It does not make sense to optimize it. Note, x86 has limited throughput for address calculations. And one instruction is only generated if this address is 32-bit which may be not true then you have to move it into register too. >> >> Anyway, we can go case by case and avoid ExternalAddress in 64-bit VM because code allows us to do that: >> >> In both cases in c1_Runtime1_x86.cpp and in MacroAssembler::g1_write_barrier_post() there is separate lea() instruction for LP64 which could be replaced with mov to load constant. >> >> MacroAssembler::store_check_part_2() is different case which we may prefer to use in other cases. Note, as_Address(ArrayAddress adr) generates lea() instruction again. Which means code for 32-bit VM in c1_Runtime1_x86.cpp generates 2 lea instructions and not one: >> >> __ leal(card_addr, __ as_Address(ArrayAddress(cardtable, index))); >> >> What I am saying is lets use mov instruction to load byte_map_base instead of using ExternalAddress because we don't need relocation for it and because in reality (with all past fixes) we will generate the same number of instructions. >> >> Regards, >> Vladimir >> >> On 11/19/13 7:59 AM, Albert Noll wrote: >>> Hi Roland, >>> >>> thanks for pointing this out. Here is a patch that executes the assert >>> only if >>> the address we are checking is not byte_map_base. This might not be the >>> most >>> elegant solution, but at least it seems to work. >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~anoll/8028109/webrev.01/ >>> >>> Best, >>> Albert >>> >>> >>> On 11/19/2013 10:00 AM, Roland Westrelin wrote: >>>>> Solution: Change 'ExternalAddress' to 'AddressLiteral' that generates >>>>> no relocation information for >>>>> byte_map_base. Other platforms also AddressLiteral >>>>> without relocation information. >>>> As mentioned in the thread here: >>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005151.html >>>> >>>> in this message: >>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005161.html >>>> >>>> >>>> not using ExternalAddress disables rip relative addressing. >>>> This said, I?m not sure what a clean fix for this would be. >>>> >>>> Roland. >>> > From vladimir.kozlov at oracle.com Tue Nov 19 12:15:44 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Nov 2013 12:15:44 -0800 Subject: RFR(XS): 8027571: fatal error: meet not symmetric In-Reply-To: <3CDD3E39-E0B2-4304-95E0-0308EAA2FF2D@oracle.com> References: <528AA257.2070606@oracle.com> <3CDD3E39-E0B2-4304-95E0-0308EAA2FF2D@oracle.com> Message-ID: <528BC6F0.6070003@oracle.com> Thank you, Roland The fix is good. Vladimir On 11/19/13 9:24 AM, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for reviewing this. > >> What code you are referencing: "what is done for instances?? > > I?m referencing to this: > > 3464 // Since klasses are different, we require a LCA in the Java > 3465 // class hierarchy - which means we have to fall to at least NotNull. > 3466 if( ptr == TopPTR || ptr == AnyNull || ptr == Constant ) > 3467 ptr = NotNull; > >> What about case TopPTR meet Constant which produce Constant? > > For instances, that case goes down to NotNull in some cases. > >> Can you, please, also fix comment's indent? And remove space in few cases: 'tap ->?. > > Sure. > > Roland. > >> >> Thanks, >> Vladimir >> >> On 11/18/13 12:40 PM, Roland Westrelin wrote: >>> Similarly to what is done for instances, meet of exact classes in upper lattice or constant should fall down to NotNull. >>> >>> http://cr.openjdk.java.net/~roland/8027571/webrev.00/ >>> >>> Roland. >>> > From vladimir.kozlov at oracle.com Tue Nov 19 12:28:03 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Nov 2013 12:28:03 -0800 Subject: RFR(S): 8028308: nsk regression, assert(obj->is_oop()) failed: not an oop In-Reply-To: <556D9B11-183E-46B6-BB92-27DFE417C146@oracle.com> References: <593E8155-0DCF-4D79-A153-35B0ACDC1E99@oracle.com> <528661D3.80303@oracle.com> <556D9B11-183E-46B6-BB92-27DFE417C146@oracle.com> Message-ID: <528BC9D3.4050705@oracle.com> On 11/19/13 9:07 AM, Roland Westrelin wrote: > Thanks for the review. > >> It looks good. Can you use one line for next as in other places?: >> >> + __ movptr(rbp, >> + Address(rdi, >> + Deoptimization::UnrollBlock::initial_info_offset_in_bytes())); >> > > I will. Do you want me to also fix the other similar lines in generate_uncommon_trap_blob Yes, please. thanks, Vladimir > // Load address of array of frame pcs into rcx (address*) > __ movptr(rcx, > Address(rdi, > Deoptimization::UnrollBlock::frame_pcs_offset_in_bytes())); > > // Trash the return pc > __ addptr(rsp, wordSize); > > // Load address of array of frame sizes into rsi (intptr_t*) > __ movptr(rsi, Address(rdi, > Deoptimization::UnrollBlock:: > frame_sizes_offset_in_bytes())); > > // Counter > __ movl(rdx, Address(rdi, > Deoptimization::UnrollBlock:: > number_of_frames_offset_in_bytes())); // (int) > > Roland. > >> Thanks, >> Vladimir >> >> On 11/15/13 3:46 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8028308/webrev.00/ >>> >>> When the stack bang in the deopt blob results in an exception being thrown, rbp must contain the value to be restored on return to the caller so that it is properly set when the exception is propagated to the caller. It is not the case right now. >>> >>> The test case is not the most robust one because it needs the compiler to generate code that keeps an object in rbp across the call to m1 in m3. The failure reproduces at least on 32bit. >>> >>> Roland. >>> > From igor.veresov at oracle.com Tue Nov 19 12:31:59 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 19 Nov 2013 12:31:59 -0800 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: <528BC542.6090108@oracle.com> References: <528B2347.7010902@oracle.com> <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> <528B8AF0.5050506@oracle.com> <528BBDC8.9010804@oracle.com> <528BC542.6090108@oracle.com> Message-ID: <7F9638CF-DA59-44E3-B4B8-0BE317ADC98F@oracle.com> Indeed, I agree, a move would be more straightforward. Later on we?ll need a special type of relocation added for the cardtable pointer anyway, because it has very unique rules to compute it depending on both location of the heap and the cardtable array. It is certainly not an ExternalAddress. igor On Nov 19, 2013, at 12:08 PM, Vladimir Kozlov wrote: > On 11/19/13 11:57 AM, Igor Veresov wrote: >> Except we will need some relocation info for it if we plan to do snapshotting. > > True, but after Tom's fix it does not have a relocation in all cases already: > > http://cr.openjdk.java.net/~never/6777083/src/cpu/x86/vm/assembler_x86.hpp.udiff.html > > And I think, there are places where we don't use ExternalAddress so we may need to solve serialization differently later. > > Thanks, > Vladimir > >> >> igor >> >> On Nov 19, 2013, at 11:36 AM, Vladimir Kozlov wrote: >> >>> Last version is not good because it may hide bug when wrong address matches byte_map_base value. Original Tom's fix also hides problems. >>> >>> MacroAssembler::g1_write_barrier_post() and store_check_part_2() are used only in interpreter. It does not make sense to optimize it. Note, x86 has limited throughput for address calculations. And one instruction is only generated if this address is 32-bit which may be not true then you have to move it into register too. >>> >>> Anyway, we can go case by case and avoid ExternalAddress in 64-bit VM because code allows us to do that: >>> >>> In both cases in c1_Runtime1_x86.cpp and in MacroAssembler::g1_write_barrier_post() there is separate lea() instruction for LP64 which could be replaced with mov to load constant. >>> >>> MacroAssembler::store_check_part_2() is different case which we may prefer to use in other cases. Note, as_Address(ArrayAddress adr) generates lea() instruction again. Which means code for 32-bit VM in c1_Runtime1_x86.cpp generates 2 lea instructions and not one: >>> >>> __ leal(card_addr, __ as_Address(ArrayAddress(cardtable, index))); >>> >>> What I am saying is lets use mov instruction to load byte_map_base instead of using ExternalAddress because we don't need relocation for it and because in reality (with all past fixes) we will generate the same number of instructions. >>> >>> Regards, >>> Vladimir >>> >>> On 11/19/13 7:59 AM, Albert Noll wrote: >>>> Hi Roland, >>>> >>>> thanks for pointing this out. Here is a patch that executes the assert >>>> only if >>>> the address we are checking is not byte_map_base. This might not be the >>>> most >>>> elegant solution, but at least it seems to work. >>>> >>>> Here is the new webrev: >>>> http://cr.openjdk.java.net/~anoll/8028109/webrev.01/ >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 11/19/2013 10:00 AM, Roland Westrelin wrote: >>>>>> Solution: Change 'ExternalAddress' to 'AddressLiteral' that generates >>>>>> no relocation information for >>>>>> byte_map_base. Other platforms also AddressLiteral >>>>>> without relocation information. >>>>> As mentioned in the thread here: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005151.html >>>>> >>>>> in this message: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005161.html >>>>> >>>>> >>>>> not using ExternalAddress disables rip relative addressing. >>>>> This said, I?m not sure what a clean fix for this would be. >>>>> >>>>> Roland. From roland.westrelin at oracle.com Wed Nov 20 02:42:16 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Wed, 20 Nov 2013 10:42:16 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8028306: nsk stress tests, CodeCache fills, then safepoint asserts Message-ID: <20131120104222.A48E5626F5@hg.openjdk.java.net> Changeset: 938e1e64e28f Author: anoll Date: 2013-11-14 19:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From roland.westrelin at oracle.com Wed Nov 20 06:04:43 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Wed, 20 Nov 2013 14:04:43 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8028308: nsk regression, assert(obj->is_oop()) failed: not an oop Message-ID: <20131120140447.82AA0626FE@hg.openjdk.java.net> Changeset: fca8f4799229 Author: roland Date: 2013-11-20 12:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 shrinivas.joshi at oracle.com Wed Nov 20 11:00:32 2013 From: shrinivas.joshi at oracle.com (Shrinivas Joshi) Date: Wed, 20 Nov 2013 11:00:32 -0800 Subject: RFR(L): 8002074: Support for AES on SPARC In-Reply-To: <52868482.6070803@oracle.com> References: <52858828.2090105@oracle.com> <52868275.2020207@oracle.com> <52868482.6070803@oracle.com> Message-ID: <528D06D0.30308@oracle.com> Hi Vladimir, Vitaly, Thanks again for reviewing this change. Please find updated webrev at http://cr.openjdk.java.net/~kvn/8002074/webrev.03/ which incorporates the changes that you suggested. -Shrinivas On 11/15/2013 12:30 PM, Shrinivas Joshi wrote: > Hi Vladimir, > > Thanks for the feedback. I will make these changes and update the webrev. > > -Shrinivas > > On 11/15/2013 12:22 PM, Vladimir Kozlov wrote: >> Shrinivas, >> >> I suggested before to use loops to generated less code lines in >> stubs. For example, next: >> >> + // load expanded key >> + __ ldf(FloatRegisterImpl::D, key, 0, F0); >> + __ ldf(FloatRegisterImpl::D, key, 8, F2); >> + ... >> + __ ldf(FloatRegisterImpl::D, key, 152, F38); >> >> could be replaced with >> >> // load expanded key >> for (int i = 0; i < 40; i += 2) { >> __ ldf(FloatRegisterImpl::D, key, i*4, as_FloatRegister(i)); >> } >> >> Next: >> >> + __ aes_eround01(F4, F54, F56, F58); //round 1 >> + __ aes_eround23(F6, F54, F56, F60); >> + __ aes_eround01(F8, F58, F60, F54); //round 2 >> + __ aes_eround23(F10, F58, F60, F56); >> ... >> + __ aes_eround01(F36, F54, F56, F58); //round 9 >> + __ aes_eround23(F38, F54, F56, F60); >> >> could be: >> >> for (int i = 4; i < 36; i += 8) { >> __ aes_eround01(as_FloatRegister(i ), F54, F56, F58); //round 1 >> __ aes_eround23(as_FloatRegister(i+2), F54, F56, F60); >> __ aes_eround01(as_FloatRegister(i+4), F58, F60, F54); //round 2 >> __ aes_eround23(as_FloatRegister(i+6), F58, F60, F56); >> } >> __ aes_eround01(F36, F54, F56, F58); //round 9 >> __ aes_eround23(F38, F54, F56, F60); >> >> >> And other places where there is repetitive pattern. >> >> Thanks, >> Vladimir >> >> On 11/14/13 6:34 PM, Shrinivas Joshi wrote: >>> Hi, >>> >>> Can I please request reviews for the following change? Target JDK >>> release for this change would be the next update of JDK 8 / JDK 9. >>> >>> Thanks, >>> -Shrinivas >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8002074 >>> Webrev: http://cr.openjdk.java.net/~kvn/8002074/webrev.02/ >>> >>> Summary: This change adds intrinsics/stub routines support for >>> single-block and multi-block (as used by Cipher Block Chaining mode) >>> AES >>> encryption and decryption operations on the SPARC platform. These >>> intrinsics are available only when the application is configured to use >>> SunJCE crypto provider. These stubs make use of efficient hardware AES >>> instructions and thus offer significant performance improvements over >>> JITed code. AES intrinsics are enabled by default on SPARC platforms >>> that support AES instructions. They can be explicitly enabled or >>> disabled on the command-line using UseAES and UseAESIntrinsics JVM >>> flags. >>> >>> Summary of source code changes: >>> * src/cpu/sparc/vm/assembler_sparc.hpp >>> - Adds support for all 3-operand and 4-operand SPARC AES >>> instructions. Also adds support for floating-point XOR (FXORs/FXORd) >>> instructions. FXOR instructions are used in the AES stub routines >>> * src/cpu/sparc/vm/stubGenerator_sparc.cpp >>> - Defines stubs for single-block and multi-block AES encryption >>> and decryption routines supporting all key sizes (128-bit, 192-bit and >>> 256-bit). >>> - Current SPARC AES decryption instructions are not compatible >>> with SunJCE expanded decryption key format. Thus decryption stubs read >>> the original key (passed as an input parameter) and perform decryption >>> key expansion using hardware instructions. >>> - Multi-block decryption stub can perform decryption for 2 * >>> 16-byte blocks at a time. >>> - Encryption stubs use SunJCE expanded encryption key as >>> their is >>> no incompatibility issue between SPARC AES encryption instructions and >>> SunJCE expanded encryption keys. >>> * src/cpu/sparc/vm/sparc.ad, src/cpu/x86/vm/x86.ad and >>> src/share/vm/opto/matcher.hpp >>> - The additional original key array reference parameter is >>> required only on the SPARC platform. This code guards it from being >>> passed to the x86 AES stub routines. >>> * src/cpu/sparc/vm/vm_version_sparc.cpp, >>> src/cpu/sparc/vm/vm_version_sparc.hpp and >>> src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp >>> - Detect AES capabilities of the underlying CPU. >>> - Enable UseAES and UseAESIntrinsics flags if the underlying CPU >>> supports AES instructions and neither of them is explicitly disabled on >>> the command-line. Generate warning message if either of these flags are >>> enabled on the command-line whereas the underlying CPU does not support >>> AES instructions. >>> * src/share/vm/classfile/vmSymbols.hpp >>> - Fix for "8012900: CICO ignores AAD in GCM mode" changes return >>> type of com.sun.crypto.provider.CipherBlockChaining.encrypt() and >>> com.sun.crypto.provider.CipherBlockChaining.decrypt() from void to int. >>> Method signature in intrinsics definition had to be changed >>> accordingly. >>> * src/share/vm/opto/library_call.cpp >>> - Adds a new method to read 'lastKey' field of >>> com.sun.crypto.provider.AESCrypt class which holds the original key. >>> - Passes additional input parameter, original key array >>> reference, to the AES stubs only on the SPARC platform. >>> - Addresses change in return value from 'void' to 'int' in case >>> of multi-block CBC stubs. >>> * src/share/vm/opto/runtime.cpp >>> - Reads the additional input parameter (original key reference) >>> only on SPARC platform. >>> - Addresses change in return value from 'void' to 'int' in case >>> of multi-block CBC stubs. >>> * hotspot/test/compiler/7184394/TestAESMain.java >>> - This test case was contributed as part of the x86 AES >>> intrinsics work by Tom Deneau @AMD. Fixed incorrect nano-second to >>> milli-second conversion code. Added warm-up phase since this test case >>> can also be used for performance testing. >>> >>> Testing: jtreg, ctw, nsk and JPRT >> >> > > > From vladimir.kozlov at oracle.com Wed Nov 20 11:16:20 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Nov 2013 11:16:20 -0800 Subject: RFR(L): 8002074: Support for AES on SPARC In-Reply-To: <528D06D0.30308@oracle.com> References: <52858828.2090105@oracle.com> <52868275.2020207@oracle.com> <52868482.6070803@oracle.com> <528D06D0.30308@oracle.com> Message-ID: <528D0A84.50405@oracle.com> This looks good. Thanks, Vladimir On 11/20/13 11:00 AM, Shrinivas Joshi wrote: > Hi Vladimir, Vitaly, > > Thanks again for reviewing this change. Please find updated webrev at > http://cr.openjdk.java.net/~kvn/8002074/webrev.03/ which incorporates > the changes that you suggested. > > -Shrinivas > > On 11/15/2013 12:30 PM, Shrinivas Joshi wrote: >> Hi Vladimir, >> >> Thanks for the feedback. I will make these changes and update the webrev. >> >> -Shrinivas >> >> On 11/15/2013 12:22 PM, Vladimir Kozlov wrote: >>> Shrinivas, >>> >>> I suggested before to use loops to generated less code lines in >>> stubs. For example, next: >>> >>> + // load expanded key >>> + __ ldf(FloatRegisterImpl::D, key, 0, F0); >>> + __ ldf(FloatRegisterImpl::D, key, 8, F2); >>> + ... >>> + __ ldf(FloatRegisterImpl::D, key, 152, F38); >>> >>> could be replaced with >>> >>> // load expanded key >>> for (int i = 0; i < 40; i += 2) { >>> __ ldf(FloatRegisterImpl::D, key, i*4, as_FloatRegister(i)); >>> } >>> >>> Next: >>> >>> + __ aes_eround01(F4, F54, F56, F58); //round 1 >>> + __ aes_eround23(F6, F54, F56, F60); >>> + __ aes_eround01(F8, F58, F60, F54); //round 2 >>> + __ aes_eround23(F10, F58, F60, F56); >>> ... >>> + __ aes_eround01(F36, F54, F56, F58); //round 9 >>> + __ aes_eround23(F38, F54, F56, F60); >>> >>> could be: >>> >>> for (int i = 4; i < 36; i += 8) { >>> __ aes_eround01(as_FloatRegister(i ), F54, F56, F58); //round 1 >>> __ aes_eround23(as_FloatRegister(i+2), F54, F56, F60); >>> __ aes_eround01(as_FloatRegister(i+4), F58, F60, F54); //round 2 >>> __ aes_eround23(as_FloatRegister(i+6), F58, F60, F56); >>> } >>> __ aes_eround01(F36, F54, F56, F58); //round 9 >>> __ aes_eround23(F38, F54, F56, F60); >>> >>> >>> And other places where there is repetitive pattern. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/14/13 6:34 PM, Shrinivas Joshi wrote: >>>> Hi, >>>> >>>> Can I please request reviews for the following change? Target JDK >>>> release for this change would be the next update of JDK 8 / JDK 9. >>>> >>>> Thanks, >>>> -Shrinivas >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8002074 >>>> Webrev: http://cr.openjdk.java.net/~kvn/8002074/webrev.02/ >>>> >>>> Summary: This change adds intrinsics/stub routines support for >>>> single-block and multi-block (as used by Cipher Block Chaining mode) >>>> AES >>>> encryption and decryption operations on the SPARC platform. These >>>> intrinsics are available only when the application is configured to use >>>> SunJCE crypto provider. These stubs make use of efficient hardware AES >>>> instructions and thus offer significant performance improvements over >>>> JITed code. AES intrinsics are enabled by default on SPARC platforms >>>> that support AES instructions. They can be explicitly enabled or >>>> disabled on the command-line using UseAES and UseAESIntrinsics JVM >>>> flags. >>>> >>>> Summary of source code changes: >>>> * src/cpu/sparc/vm/assembler_sparc.hpp >>>> - Adds support for all 3-operand and 4-operand SPARC AES >>>> instructions. Also adds support for floating-point XOR (FXORs/FXORd) >>>> instructions. FXOR instructions are used in the AES stub routines >>>> * src/cpu/sparc/vm/stubGenerator_sparc.cpp >>>> - Defines stubs for single-block and multi-block AES encryption >>>> and decryption routines supporting all key sizes (128-bit, 192-bit and >>>> 256-bit). >>>> - Current SPARC AES decryption instructions are not compatible >>>> with SunJCE expanded decryption key format. Thus decryption stubs read >>>> the original key (passed as an input parameter) and perform decryption >>>> key expansion using hardware instructions. >>>> - Multi-block decryption stub can perform decryption for 2 * >>>> 16-byte blocks at a time. >>>> - Encryption stubs use SunJCE expanded encryption key as >>>> their is >>>> no incompatibility issue between SPARC AES encryption instructions and >>>> SunJCE expanded encryption keys. >>>> * src/cpu/sparc/vm/sparc.ad, src/cpu/x86/vm/x86.ad and >>>> src/share/vm/opto/matcher.hpp >>>> - The additional original key array reference parameter is >>>> required only on the SPARC platform. This code guards it from being >>>> passed to the x86 AES stub routines. >>>> * src/cpu/sparc/vm/vm_version_sparc.cpp, >>>> src/cpu/sparc/vm/vm_version_sparc.hpp and >>>> src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp >>>> - Detect AES capabilities of the underlying CPU. >>>> - Enable UseAES and UseAESIntrinsics flags if the underlying CPU >>>> supports AES instructions and neither of them is explicitly disabled on >>>> the command-line. Generate warning message if either of these flags are >>>> enabled on the command-line whereas the underlying CPU does not support >>>> AES instructions. >>>> * src/share/vm/classfile/vmSymbols.hpp >>>> - Fix for "8012900: CICO ignores AAD in GCM mode" changes return >>>> type of com.sun.crypto.provider.CipherBlockChaining.encrypt() and >>>> com.sun.crypto.provider.CipherBlockChaining.decrypt() from void to int. >>>> Method signature in intrinsics definition had to be changed >>>> accordingly. >>>> * src/share/vm/opto/library_call.cpp >>>> - Adds a new method to read 'lastKey' field of >>>> com.sun.crypto.provider.AESCrypt class which holds the original key. >>>> - Passes additional input parameter, original key array >>>> reference, to the AES stubs only on the SPARC platform. >>>> - Addresses change in return value from 'void' to 'int' in case >>>> of multi-block CBC stubs. >>>> * src/share/vm/opto/runtime.cpp >>>> - Reads the additional input parameter (original key reference) >>>> only on SPARC platform. >>>> - Addresses change in return value from 'void' to 'int' in case >>>> of multi-block CBC stubs. >>>> * hotspot/test/compiler/7184394/TestAESMain.java >>>> - This test case was contributed as part of the x86 AES >>>> intrinsics work by Tom Deneau @AMD. Fixed incorrect nano-second to >>>> milli-second conversion code. Added warm-up phase since this test case >>>> can also be used for performance testing. >>>> >>>> Testing: jtreg, ctw, nsk and JPRT >>> >>> >> >> >> > From vladimir.kozlov at oracle.com Thu Nov 21 10:31:26 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Nov 2013 10:31:26 -0800 Subject: Possible bug in nmethod reloc verification/scanning in G1 In-Reply-To: <1385042096.2853.168.camel@cirrus> References: <1385042096.2853.168.camel@cirrus> Message-ID: <528E517E.3020704@oracle.com> CC to compiler because it is about compiled nmethods and their state change. So it is interesting for us. Note, usually such methods are inlinied (accessor methods) and big methods have stack bang code at the beginning. Here is criteria used to generate stack bang: bool Compile::need_stack_bang(int frame_size_in_bytes) const { // Determine if we need to generate a stack overflow check. // Do it if the method is not a stub function and // has java calls or has frame size > vm_page_size/8. return (UseStackBanging && stub_function() == NULL && (has_java_calls() || frame_size_in_bytes > os::vm_page_size()>>3)); } In your case stack bang is not generated that is why you have embedded oop at the beginning of the code. We can mark such nmethods so it will be easier to see such nmethod when we need unregister them. And thank you for catching both problems. Thanks, Vladimir On 11/21/13 5:54 AM, Thomas Schatzl wrote: > Hi, > > On Thu, 2013-11-21 at 14:42 +0100, Christos Kotselidis wrote: >> On 11/21/13 2:34 PM, "Thomas Schatzl" wrote: >> >>> Hi, >>> >>> On Thu, 2013-11-21 at 12:40 +0100, Christos Kotselidis wrote: >>>> Hi, >>>> >>>> I came across the following scenario, I already discussed with Thomas >>>> Schatzl, that I would like to share with you. >>>> There is a method: >>>> >>>> private static final HotSpotGraalRuntime instance = new >>>> HotSpotGraalRuntime(); >>>> >>>> public static HotSpotGraalRuntime runtime() { >>>> return instance; >>>> } >>> >>>> The instance field is a constant oop in the code and the method is >>>> installed. >>>> At some stage there is a GC with post verification >>>> (including G1VerifyHeapRegionCodeRoots) that passes. >>>> Before the next GC cycle and during the mutation cycle, another method >>>> is being installed which causes the eviction of our method. >>>> Consequently our method is being made not_entrant and it is being >>>> patched with a jmp instruction at its verified entry point >>>> (nmethod.cpp::make_not_entrant_or_zombie). The patching causes the oop >>>> to be overwritten by the jmp instruction. Furthermore, that oop was >>>> the only oop that was responsible for attaching this method to its >>>> correspondent HeapRegion. >>>> >>>> The next GC cycle (Pre-verification) comes and the HeapRegionCodeRoot >>>> verification starts (nmethod.cpp::oops_do). There is a logic there >>>> (which I also believe it may be buggy as I will explain later) that >>>> checks whether the method is not_entrant. If the method is not_entrant >>>> then the logic correctly assumes that the method has been already been >>>> patched and therefore starts scanning the relocs of the method in +5 >>>> bytes (for x86)/+4 bytes (for SPARC) (as the comment states). This >>>> results in not scanning the single oop that was attaching this >>>> specific method to its heap region. The verification then correctly >>>> asserts by saying that "there is a method attached to this specific >>>> heap region with no oops pointing into it". >>> >>> Thanks for finding this - I already filed a bug for that >>> (https://bugs.openjdk.java.net/browse/JDK-8028736). Please check if it >>> matches your investigation. >>>> >>>> Concerning the second bug in the method::oops_do logic, here is the >>>> code for manipulating the reloc starting address after a method has >>>> been patched: >>> >>>> // If the method is not entrant or zombie then a JMP is plastered over >>>> // the >>>> // first few bytes. If an oop in the old code was there, that oop >>>> // should not get GC'd. Skip the first few bytes of oops on >>>> // not-entrant methods. >>>> address low_boundary = verified_entry_point(); >>>> if (is_not_entrant()) { >>>> low_boundary += NativeJump::instruction_size; >>>> // %%% Note: On SPARC we patch only a 4-byte trap, not a full >>>> NativeJump. >>>> // (See comment above.) >>>> } >>>> >>>> The code above accounts only for the "is not entrant" scenario and not >>>> with the "is zombie" scenario. >>> >>> nmethod::do_oops will not be called for zombie methods in the default >>> case, so it does not matter. I.e. the default overload of >>> oops_do(Closure* cl, bool zombie) is oops_do(cl, false); >> >> When unregistering a method we call the oops_do allowing zombie methods >> (G1CollectedHeap::unregister_nmethod). That was causing a problem in my >> case and after adding "|| is_zombie()", it got fixed. > > I think you are right, we will need to fix that too as the oop map is > not changed after overwriting the oop in the first few bytes. > > Thomas > > From john.coomes at oracle.com Thu Nov 21 11:02:11 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 19:02:11 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b117 for changeset a4afb0a8d55e Message-ID: <20131121190212.06A1D62759@hg.openjdk.java.net> Changeset: 0a6db1aac998 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/0a6db1aac998 Added tag jdk8-b117 for changeset a4afb0a8d55e ! .hgtags From john.coomes at oracle.com Thu Nov 21 11:02:18 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 19:02:18 +0000 Subject: hg: hsx/hotspot-comp/corba: 4 new changesets Message-ID: <20131121190223.1C5E16275A@hg.openjdk.java.net> Changeset: b99535e22efe Author: mchung Date: 2013-11-07 20:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/corba/rev/4796555c4dc8 Merge Changeset: e53d1ee4d2ae Author: lana Date: 2013-11-14 23:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/e53d1ee4d2ae Merge Changeset: d6820a414f18 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/d6820a414f18 Added tag jdk8-b117 for changeset e53d1ee4d2ae ! .hgtags From john.coomes at oracle.com Thu Nov 21 11:02:30 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 19:02:30 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b117 for changeset c1d234d4f164 Message-ID: <20131121190239.CBAD86275B@hg.openjdk.java.net> Changeset: e4e5069250e7 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/e4e5069250e7 Added tag jdk8-b117 for changeset c1d234d4f164 ! .hgtags From john.coomes at oracle.com Thu Nov 21 11:02:48 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 19:02:48 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b117 for changeset fe56ba456fd3 Message-ID: <20131121190255.553276275C@hg.openjdk.java.net> Changeset: 76a598cf50c4 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/76a598cf50c4 Added tag jdk8-b117 for changeset fe56ba456fd3 ! .hgtags From john.coomes at oracle.com Thu Nov 21 11:05:49 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 19:05:49 +0000 Subject: hg: hsx/hotspot-comp/jdk: 90 new changesets Message-ID: <20131121192525.6C5C162760@hg.openjdk.java.net> Changeset: f2ae86dba4bc Author: prr Date: 2013-11-13 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jdk/rev/b691a6abf9e0 Merge Changeset: 30766f910509 Author: malenkov Date: 2013-11-01 21:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/ca0db77f6d6b Merge Changeset: c35f6df5bce9 Author: sla Date: 2013-11-01 10:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/f893901ba29c Merge Changeset: 40d0ccd00f87 Author: xuelei Date: 2013-11-14 16:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jdk/rev/8bc258c021a3 Added tag jdk8-b117 for changeset fc4ac66aa657 ! .hgtags From john.coomes at oracle.com Thu Nov 21 11:28:47 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 19:28:47 +0000 Subject: hg: hsx/hotspot-comp/langtools: 18 new changesets Message-ID: <20131121192951.3373D62761@hg.openjdk.java.net> Changeset: cc80c03c41e4 Author: vromero Date: 2013-11-01 19:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/21294feaf311 Merge Changeset: 6e0f31d61e56 Author: jlahoda Date: 2013-11-09 15:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/4fd6a7ff8c06 Added tag jdk8-b117 for changeset 19de039a03a6 ! .hgtags From john.coomes at oracle.com Thu Nov 21 11:30:03 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 19:30:03 +0000 Subject: hg: hsx/hotspot-comp/nashorn: 13 new changesets Message-ID: <20131121193018.2E61262762@hg.openjdk.java.net> Changeset: ae5f2130c3b9 Author: sundar Date: 2013-11-01 19:54 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/nashorn/rev/144861e24260 Merge Changeset: dcedc753fd09 Author: sundar Date: 2013-11-04 18:52 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/nashorn/rev/b0d4ef6fb2db Merge Changeset: bda654c6d59c Author: kshefov Date: 2013-11-05 13:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/nashorn/rev/3b794f364c77 Merge Changeset: d091499d67fc Author: lana Date: 2013-11-08 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/d091499d67fc Merge Changeset: e65a98146b94 Author: attila Date: 2013-11-11 14:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/nashorn/rev/2f0f8d1d0753 Merge Changeset: 1db3d4e4d189 Author: lana Date: 2013-11-15 07:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/1db3d4e4d189 Merge Changeset: 8d014b039b44 Author: cl Date: 2013-11-21 09:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/8d014b039b44 Added tag jdk8-b117 for changeset 1db3d4e4d189 ! .hgtags From igor.veresov at oracle.com Thu Nov 21 16:35:57 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 21 Nov 2013 16:35:57 -0800 Subject: Possible bug in nmethod reloc verification/scanning in G1 In-Reply-To: References: Message-ID: <9983CCF3-3DE6-4D2F-935C-8F80E7B8CE06@oracle.com> Christos, This must be a Graal-emitted method that fails. C1 & C2 take special care to emit enough bytes in the prologue to make space for the jump instruction of the patch. Graal should do the same. The method in the example: static final Object someobject = new Integer(0xdeadbabe); final static Object getSomeObject() { return someobject; } Looks like this with C2: 0x000000011185d440: sub $0x18,%rsp 0x000000011185d447: mov %rbp,0x10(%rsp) ;*synchronization entry ; - X::getSomeObject at -1 (line 6) 0x000000011185d44c: movabs $0x74006b240,%rax ; {oop(a 'java/lang/Integer' = -559039810)} 0x000000011185d456: add $0x10,%rsp 0x000000011185d45a: pop %rbp 0x000000011185d45b: test %eax,-0x246a461(%rip) # 0x000000010f3f3000 ; {poll_return} 0x000000011185d461: retq Notice a long version of the sub instruction allocating the frame, that's on purpose, to make sure that jump will fit. See MacroAssembler::verified_entry() in macroAssembler_x86.cpp. C1, respectively generates either a stack bang (always!): 0x0000000110fa5e20: mov %eax,-0x16000(%rsp) 0x0000000110fa5e27: push %rbp 0x0000000110fa5e28: sub $0x30,%rsp ;*getstatic someobject ; - X::getSomeObject at 0 (line 6) ;; block B0 [0, 3] 0x0000000110fa5e2c: movabs $0x74006b428,%rax ; {oop(a 'java/lang/Integer' = -559039810)} 0x0000000110fa5e36: add $0x30,%rsp 0x0000000110fa5e3a: pop %rbp 0x0000000110fa5e3b: test %eax,-0x262fd41(%rip) # 0x000000010e976100 ; {poll_return} 0x0000000110fa5e41: retq Or if you turn stack bangs off it puts a 5-byte nop (to accommodate for the jump): 0x00000001080a1f20: nopl 0x0(%rax,%rax,1) 0x00000001080a1f25: push %rbp 0x00000001080a1f26: sub $0x30,%rsp ;*getstatic someobject ; - X::getSomeObject at 0 (line 6) ;; block B0 [0, 3] 0x00000001080a1f2a: movabs $0x74006b428,%rax ; {oop(a 'java/lang/Integer' = -559039810)} 0x00000001080a1f34: add $0x30,%rsp 0x00000001080a1f38: pop %rbp 0x00000001080a1f39: test %eax,-0x24dde3f(%rip) # 0x0000000105bc4100 ; {poll_return} 0x00000001080a1f3f: retq igor On Nov 21, 2013, at 12:46 PM, Christos Kotselidis wrote: > Thanks for the info. Yes, I cc'ed initially the compiler team but I guess > the original email is pending for verification. > > Regards > > Christos > > On 11/21/13 7:31 PM, "Vladimir Kozlov" wrote: > >> CC to compiler because it is about compiled nmethods and their state >> change. So it is interesting for us. >> >> Note, usually such methods are inlinied (accessor methods) and big >> methods have stack bang code at the beginning. Here is criteria used to >> generate stack bang: >> >> bool Compile::need_stack_bang(int frame_size_in_bytes) const { >> // Determine if we need to generate a stack overflow check. >> // Do it if the method is not a stub function and >> // has java calls or has frame size > vm_page_size/8. >> return (UseStackBanging && stub_function() == NULL && >> (has_java_calls() || frame_size_in_bytes > >> os::vm_page_size()>>3)); >> } >> >> In your case stack bang is not generated that is why you have embedded >> oop at the beginning of the code. >> We can mark such nmethods so it will be easier to see such nmethod when >> we need unregister them. >> >> And thank you for catching both problems. >> >> Thanks, >> Vladimir >> >> On 11/21/13 5:54 AM, Thomas Schatzl wrote: >>> Hi, >>> >>> On Thu, 2013-11-21 at 14:42 +0100, Christos Kotselidis wrote: >>>> On 11/21/13 2:34 PM, "Thomas Schatzl" >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Thu, 2013-11-21 at 12:40 +0100, Christos Kotselidis wrote: >>>>>> Hi, >>>>>> >>>>>> I came across the following scenario, I already discussed with Thomas >>>>>> Schatzl, that I would like to share with you. >>>>>> There is a method: >>>>>> >>>>>> private static final HotSpotGraalRuntime instance = new >>>>>> HotSpotGraalRuntime(); >>>>>> >>>>>> public static HotSpotGraalRuntime runtime() { >>>>>> return instance; >>>>>> } >>>>> >>>>>> The instance field is a constant oop in the code and the method is >>>>>> installed. >>>>>> At some stage there is a GC with post verification >>>>>> (including G1VerifyHeapRegionCodeRoots) that passes. >>>>>> Before the next GC cycle and during the mutation cycle, another >>>>>> method >>>>>> is being installed which causes the eviction of our method. >>>>>> Consequently our method is being made not_entrant and it is being >>>>>> patched with a jmp instruction at its verified entry point >>>>>> (nmethod.cpp::make_not_entrant_or_zombie). The patching causes the >>>>>> oop >>>>>> to be overwritten by the jmp instruction. Furthermore, that oop was >>>>>> the only oop that was responsible for attaching this method to its >>>>>> correspondent HeapRegion. >>>>>> >>>>>> The next GC cycle (Pre-verification) comes and the HeapRegionCodeRoot >>>>>> verification starts (nmethod.cpp::oops_do). There is a logic there >>>>>> (which I also believe it may be buggy as I will explain later) that >>>>>> checks whether the method is not_entrant. If the method is >>>>>> not_entrant >>>>>> then the logic correctly assumes that the method has been already >>>>>> been >>>>>> patched and therefore starts scanning the relocs of the method in +5 >>>>>> bytes (for x86)/+4 bytes (for SPARC) (as the comment states). This >>>>>> results in not scanning the single oop that was attaching this >>>>>> specific method to its heap region. The verification then correctly >>>>>> asserts by saying that "there is a method attached to this specific >>>>>> heap region with no oops pointing into it". >>>>> >>>>> Thanks for finding this - I already filed a bug for that >>>>> (https://bugs.openjdk.java.net/browse/JDK-8028736). Please check if it >>>>> matches your investigation. >>>>>> >>>>>> Concerning the second bug in the method::oops_do logic, here is the >>>>>> code for manipulating the reloc starting address after a method has >>>>>> been patched: >>>>> >>>>>> // If the method is not entrant or zombie then a JMP is plastered >>>>>> over >>>>>> // the >>>>>> // first few bytes. If an oop in the old code was there, that oop >>>>>> // should not get GC'd. Skip the first few bytes of oops on >>>>>> // not-entrant methods. >>>>>> address low_boundary = verified_entry_point(); >>>>>> if (is_not_entrant()) { >>>>>> low_boundary += NativeJump::instruction_size; >>>>>> // %%% Note: On SPARC we patch only a 4-byte trap, not a full >>>>>> NativeJump. >>>>>> // (See comment above.) >>>>>> } >>>>>> >>>>>> The code above accounts only for the "is not entrant" scenario and >>>>>> not >>>>>> with the "is zombie" scenario. >>>>> >>>>> nmethod::do_oops will not be called for zombie methods in the default >>>>> case, so it does not matter. I.e. the default overload of >>>>> oops_do(Closure* cl, bool zombie) is oops_do(cl, false); >>>> >>>> When unregistering a method we call the oops_do allowing zombie methods >>>> (G1CollectedHeap::unregister_nmethod). That was causing a problem in my >>>> case and after adding "|| is_zombie()", it got fixed. >>> >>> I think you are right, we will need to fix that too as the oop map is >>> not changed after overwriting the oop in the first few bytes. >>> >>> Thomas >>> >>> > > From christos.kotselidis at oracle.com Thu Nov 21 16:45:35 2013 From: christos.kotselidis at oracle.com (Christos Kotselidis) Date: Fri, 22 Nov 2013 01:45:35 +0100 Subject: Possible bug in nmethod reloc verification/scanning in G1 In-Reply-To: <9983CCF3-3DE6-4D2F-935C-8F80E7B8CE06@oracle.com> Message-ID: Hi Igor, Correct, this is a Graal emitted method which I am pretty sure we do not guarantee the 5 byte invariant for the patching? Thanks for the info. Christos On 11/22/13 1:35 AM, "Igor Veresov" wrote: >Christos, > >This must be a Graal-emitted method that fails. C1 & C2 take special care >to emit enough bytes in the prologue to make space for the jump >instruction of the patch. Graal should do the same. > >The method in the example: > >static final Object someobject = new Integer(0xdeadbabe); > final static Object getSomeObject() { > return someobject; > } > >Looks like this with C2: > 0x000000011185d440: sub $0x18,%rsp > 0x000000011185d447: mov %rbp,0x10(%rsp) ;*synchronization entry > ; - X::getSomeObject at -1 >(line 6) > > 0x000000011185d44c: movabs $0x74006b240,%rax ; {oop(a >'java/lang/Integer' = -559039810)} > 0x000000011185d456: add $0x10,%rsp > 0x000000011185d45a: pop %rbp > 0x000000011185d45b: test %eax,-0x246a461(%rip) # 0x000000010f3f3000 > ; {poll_return} > 0x000000011185d461: retq > >Notice a long version of the sub instruction allocating the frame, that's >on purpose, to make sure that jump will fit. See >MacroAssembler::verified_entry() in macroAssembler_x86.cpp. > >C1, respectively generates either a stack bang (always!): > 0x0000000110fa5e20: mov %eax,-0x16000(%rsp) > 0x0000000110fa5e27: push %rbp > 0x0000000110fa5e28: sub $0x30,%rsp ;*getstatic someobject > ; - X::getSomeObject at 0 >(line 6) > > ;; block B0 [0, 3] > > 0x0000000110fa5e2c: movabs $0x74006b428,%rax ; {oop(a >'java/lang/Integer' = -559039810)} > 0x0000000110fa5e36: add $0x30,%rsp > 0x0000000110fa5e3a: pop %rbp > 0x0000000110fa5e3b: test %eax,-0x262fd41(%rip) # 0x000000010e976100 > ; {poll_return} > 0x0000000110fa5e41: retq > >Or if you turn stack bangs off it puts a 5-byte nop (to accommodate for >the jump): > > 0x00000001080a1f20: nopl 0x0(%rax,%rax,1) > 0x00000001080a1f25: push %rbp > 0x00000001080a1f26: sub $0x30,%rsp ;*getstatic someobject > ; - X::getSomeObject at 0 >(line 6) > > ;; block B0 [0, 3] > > 0x00000001080a1f2a: movabs $0x74006b428,%rax ; {oop(a >'java/lang/Integer' = -559039810)} > 0x00000001080a1f34: add $0x30,%rsp > 0x00000001080a1f38: pop %rbp > 0x00000001080a1f39: test %eax,-0x24dde3f(%rip) # 0x0000000105bc4100 > ; {poll_return} > 0x00000001080a1f3f: retq > > >igor > >On Nov 21, 2013, at 12:46 PM, Christos Kotselidis > wrote: > >> Thanks for the info. Yes, I cc'ed initially the compiler team but I >>guess >> the original email is pending for verification. >> >> Regards >> >> Christos >> >> On 11/21/13 7:31 PM, "Vladimir Kozlov" >>wrote: >> >>> CC to compiler because it is about compiled nmethods and their state >>> change. So it is interesting for us. >>> >>> Note, usually such methods are inlinied (accessor methods) and big >>> methods have stack bang code at the beginning. Here is criteria used to >>> generate stack bang: >>> >>> bool Compile::need_stack_bang(int frame_size_in_bytes) const { >>> // Determine if we need to generate a stack overflow check. >>> // Do it if the method is not a stub function and >>> // has java calls or has frame size > vm_page_size/8. >>> return (UseStackBanging && stub_function() == NULL && >>> (has_java_calls() || frame_size_in_bytes > >>> os::vm_page_size()>>3)); >>> } >>> >>> In your case stack bang is not generated that is why you have embedded >>> oop at the beginning of the code. >>> We can mark such nmethods so it will be easier to see such nmethod when >>> we need unregister them. >>> >>> And thank you for catching both problems. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/21/13 5:54 AM, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> On Thu, 2013-11-21 at 14:42 +0100, Christos Kotselidis wrote: >>>>> On 11/21/13 2:34 PM, "Thomas Schatzl" >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On Thu, 2013-11-21 at 12:40 +0100, Christos Kotselidis wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I came across the following scenario, I already discussed with >>>>>>>Thomas >>>>>>> Schatzl, that I would like to share with you. >>>>>>> There is a method: >>>>>>> >>>>>>> private static final HotSpotGraalRuntime instance = new >>>>>>> HotSpotGraalRuntime(); >>>>>>> >>>>>>> public static HotSpotGraalRuntime runtime() { >>>>>>> return instance; >>>>>>> } >>>>>> >>>>>>> The instance field is a constant oop in the code and the method is >>>>>>> installed. >>>>>>> At some stage there is a GC with post verification >>>>>>> (including G1VerifyHeapRegionCodeRoots) that passes. >>>>>>> Before the next GC cycle and during the mutation cycle, another >>>>>>> method >>>>>>> is being installed which causes the eviction of our method. >>>>>>> Consequently our method is being made not_entrant and it is being >>>>>>> patched with a jmp instruction at its verified entry point >>>>>>> (nmethod.cpp::make_not_entrant_or_zombie). The patching causes the >>>>>>> oop >>>>>>> to be overwritten by the jmp instruction. Furthermore, that oop was >>>>>>> the only oop that was responsible for attaching this method to its >>>>>>> correspondent HeapRegion. >>>>>>> >>>>>>> The next GC cycle (Pre-verification) comes and the >>>>>>>HeapRegionCodeRoot >>>>>>> verification starts (nmethod.cpp::oops_do). There is a logic there >>>>>>> (which I also believe it may be buggy as I will explain later) that >>>>>>> checks whether the method is not_entrant. If the method is >>>>>>> not_entrant >>>>>>> then the logic correctly assumes that the method has been already >>>>>>> been >>>>>>> patched and therefore starts scanning the relocs of the method in >>>>>>>+5 >>>>>>> bytes (for x86)/+4 bytes (for SPARC) (as the comment states). This >>>>>>> results in not scanning the single oop that was attaching this >>>>>>> specific method to its heap region. The verification then correctly >>>>>>> asserts by saying that "there is a method attached to this specific >>>>>>> heap region with no oops pointing into it". >>>>>> >>>>>> Thanks for finding this - I already filed a bug for that >>>>>> (https://bugs.openjdk.java.net/browse/JDK-8028736). Please check if >>>>>>it >>>>>> matches your investigation. >>>>>>> >>>>>>> Concerning the second bug in the method::oops_do logic, here is the >>>>>>> code for manipulating the reloc starting address after a method has >>>>>>> been patched: >>>>>> >>>>>>> // If the method is not entrant or zombie then a JMP is plastered >>>>>>> over >>>>>>> // the >>>>>>> // first few bytes. If an oop in the old code was there, that oop >>>>>>> // should not get GC'd. Skip the first few bytes of oops on >>>>>>> // not-entrant methods. >>>>>>> address low_boundary = verified_entry_point(); >>>>>>> if (is_not_entrant()) { >>>>>>> low_boundary += NativeJump::instruction_size; >>>>>>> // %%% Note: On SPARC we patch only a 4-byte trap, not a full >>>>>>> NativeJump. >>>>>>> // (See comment above.) >>>>>>> } >>>>>>> >>>>>>> The code above accounts only for the "is not entrant" scenario and >>>>>>> not >>>>>>> with the "is zombie" scenario. >>>>>> >>>>>> nmethod::do_oops will not be called for zombie methods in the >>>>>>default >>>>>> case, so it does not matter. I.e. the default overload of >>>>>> oops_do(Closure* cl, bool zombie) is oops_do(cl, false); >>>>> >>>>> When unregistering a method we call the oops_do allowing zombie >>>>>methods >>>>> (G1CollectedHeap::unregister_nmethod). That was causing a problem in >>>>>my >>>>> case and after adding "|| is_zombie()", it got fixed. >>>> >>>> I think you are right, we will need to fix that too as the oop map is >>>> not changed after overwriting the oop in the first few bytes. >>>> >>>> Thomas >>>> >>>> >> >> > From rickard.backman at oracle.com Fri Nov 22 05:31:04 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 22 Nov 2013 14:31:04 +0100 Subject: RFR(XS): 8028997: mathexact intrinsics are unstabl Message-ID: <20131122133104.GB19422@rbackman> Hi all, can I have a couple of reviews for this small change? It basically sets the default value of UseMathExactIntrinsics to false and moves it to be an experimental vm option. Webrev: http://cr.openjdk.java.net/~rbackman/8028997/ Bug: https://bugs.openjdk.java.net/browse/JDK-8028997 Thanks /R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131122/e0358f48/attachment.bin From leonid.mesnik at oracle.com Fri Nov 22 05:40:11 2013 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 22 Nov 2013 17:40:11 +0400 Subject: RFR(XS): 8028997: mathexact intrinsics are unstabl In-Reply-To: <20131122133104.GB19422@rbackman> References: <20131122133104.GB19422@rbackman> Message-ID: <528F5EBB.6080101@oracle.com> Rickard Does it make a sense to update corresponding tests by switching UseMathExactIntrinsics on explicitly? Leonid On 11/22/2013 05:31 PM, Rickard B?ckman wrote: > Hi all, > > can I have a couple of reviews for this small change? > It basically sets the default value of UseMathExactIntrinsics to false > and moves it to be an experimental vm option. > > Webrev: http://cr.openjdk.java.net/~rbackman/8028997/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8028997 > > Thanks > /R -- Leonid Mesnik JVM SQE From rickard.backman at oracle.com Fri Nov 22 06:30:03 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 22 Nov 2013 15:30:03 +0100 Subject: RFR(XS): 8028624: [TESTBUG] compiler/intrinsics/mathexact/DecExactLTest executes DecExactITest Message-ID: <20131122143003.GD19422@rbackman> Hi all, can I please have this small change reviewed? The tags in the test are wrong, it should say DecExactLTest where it said DecExactITest. Webrev: http://cr.openjdk.java.net/~rbackman/8028624/ Bug: https://bugs.openjdk.java.net/browse/JDK-8028624 Thanks /R -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131122/49d21860/attachment-0001.bin From vladimir.kozlov at oracle.com Fri Nov 22 09:02:21 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Nov 2013 09:02:21 -0800 Subject: RFR(XS): 8028997: mathexact intrinsics are unstabl In-Reply-To: <528F5EBB.6080101@oracle.com> References: <20131122133104.GB19422@rbackman> <528F5EBB.6080101@oracle.com> Message-ID: <528F8E1D.9070606@oracle.com> On 11/22/13 5:40 AM, Leonid Mesnik wrote: > Rickard > > Does it make a sense to update corresponding tests by switching UseMathExactIntrinsics on explicitly? Yes, it should be done in these changes. Thanks, Vladimir > > Leonid > On 11/22/2013 05:31 PM, Rickard B?ckman wrote: >> Hi all, >> >> can I have a couple of reviews for this small change? >> It basically sets the default value of UseMathExactIntrinsics to false >> and moves it to be an experimental vm option. >> >> Webrev: http://cr.openjdk.java.net/~rbackman/8028997/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8028997 >> >> Thanks >> /R > > From vladimir.kozlov at oracle.com Fri Nov 22 09:03:19 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Nov 2013 09:03:19 -0800 Subject: RFR(XS): 8028624: [TESTBUG] compiler/intrinsics/mathexact/DecExactLTest executes DecExactITest In-Reply-To: <20131122143003.GD19422@rbackman> References: <20131122143003.GD19422@rbackman> Message-ID: <528F8E57.4000303@oracle.com> Okay. Thanks, Vladimir On 11/22/13 6:30 AM, Rickard B?ckman wrote: > Hi all, > > can I please have this small change reviewed? > The tags in the test are wrong, it should say DecExactLTest where it > said DecExactITest. > > Webrev: http://cr.openjdk.java.net/~rbackman/8028624/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8028624 > > Thanks > /R > From christian.thalinger at oracle.com Fri Nov 22 09:51:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Nov 2013 09:51:02 -0800 Subject: RFR(XS): 8028624: [TESTBUG] compiler/intrinsics/mathexact/DecExactLTest executes DecExactITest In-Reply-To: <20131122143003.GD19422@rbackman> References: <20131122143003.GD19422@rbackman> Message-ID: <1E67325C-3969-4765-AA6B-6E6EB3045108@oracle.com> If you?re running your test with no arguments and in the same vm you can also omit the @run line: + * @run main DecExactLTest It might have helped you finding the bug in the first place. On Nov 22, 2013, at 6:30 AM, Rickard B?ckman wrote: > Hi all, > > can I please have this small change reviewed? > The tags in the test are wrong, it should say DecExactLTest where it > said DecExactITest. > > Webrev: http://cr.openjdk.java.net/~rbackman/8028624/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8028624 > > Thanks > /R From vladimir.kozlov at oracle.com Fri Nov 22 10:23:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Nov 2013 10:23:40 -0800 Subject: RFR(XS): 8028624: [TESTBUG] compiler/intrinsics/mathexact/DecExactLTest executes DecExactITest In-Reply-To: <1E67325C-3969-4765-AA6B-6E6EB3045108@oracle.com> References: <20131122143003.GD19422@rbackman> <1E67325C-3969-4765-AA6B-6E6EB3045108@oracle.com> Message-ID: <528FA12C.5040303@oracle.com> We need @run because we have to add UseMathExactIntrinsics to all these tests after we disable flag by default. Rickard, I forgot to tell that when you add UseMathExactIntrinsics flag you need to all next flags since it is only C2 flag: -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockExperimentalVMOptions -XX:+UseMathExactIntrinsics Thanks, Vladimir On 11/22/13 9:51 AM, Christian Thalinger wrote: > If you?re running your test with no arguments and in the same vm you can also omit the @run line: > > + * @run main DecExactLTest > > It might have helped you finding the bug in the first place. > > On Nov 22, 2013, at 6:30 AM, Rickard B?ckman wrote: > >> Hi all, >> >> can I please have this small change reviewed? >> The tags in the test are wrong, it should say DecExactLTest where it >> said DecExactITest. >> >> Webrev: http://cr.openjdk.java.net/~rbackman/8028624/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8028624 >> >> Thanks >> /R > From alejandro.murillo at oracle.com Fri Nov 22 19:47:31 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 23 Nov 2013 03:47:31 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 13 new changesets Message-ID: <20131123034758.8D15E627D0@hg.openjdk.java.net> Changeset: 55be5aac78e2 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/55be5aac78e2 Added tag jdk8-b117 for changeset f573d00213b7 ! .hgtags Changeset: cdf20166ec45 Author: minqi Date: 2013-11-13 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/hotspot/rev/3edddbff4865 Merge Changeset: b03f33670080 Author: sla Date: 2013-11-14 19:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/hotspot/rev/aa933e6b061d Merge Changeset: abad3b2d905d Author: amurillo Date: 2013-11-22 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/abad3b2d905d Merge Changeset: c9f439732b18 Author: amurillo Date: 2013-11-22 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/hotspot/rev/e51d73189692 8028815: new hotspot build - hs25-b61 Reviewed-by: jcoomes ! make/hotspot_version From rickard.backman at oracle.com Mon Nov 25 00:54:52 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Mon, 25 Nov 2013 09:54:52 +0100 Subject: RFR(XS): 8028997: mathexact intrinsics are unstabl In-Reply-To: <528F8E1D.9070606@oracle.com> References: <20131122133104.GB19422@rbackman> <528F5EBB.6080101@oracle.com> <528F8E1D.9070606@oracle.com> Message-ID: <20131125085452.GA29591@rbackman> Updated with flags for tests. Webrev: http://cr.openjdk.java.net/~rbackman/8028997.1/ Thanks /R On 11/22, Vladimir Kozlov wrote: > On 11/22/13 5:40 AM, Leonid Mesnik wrote: > >Rickard > > > >Does it make a sense to update corresponding tests by switching UseMathExactIntrinsics on explicitly? > > Yes, it should be done in these changes. > > Thanks, > Vladimir > > > > >Leonid > >On 11/22/2013 05:31 PM, Rickard B?ckman wrote: > >>Hi all, > >> > >>can I have a couple of reviews for this small change? > >>It basically sets the default value of UseMathExactIntrinsics to false > >>and moves it to be an experimental vm option. > >> > >>Webrev: http://cr.openjdk.java.net/~rbackman/8028997/ > >>Bug: https://bugs.openjdk.java.net/browse/JDK-8028997 > >> > >>Thanks > >>/R > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131125/06834d0f/attachment.bin From igor.ignatyev at oracle.com Mon Nov 25 02:05:03 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 25 Nov 2013 14:05:03 +0400 Subject: RFR(XS): 8028997: mathexact intrinsics are unstabl In-Reply-To: <20131125085452.GA29591@rbackman> References: <20131122133104.GB19422@rbackman> <528F5EBB.6080101@oracle.com> <528F8E1D.9070606@oracle.com> <20131125085452.GA29591@rbackman> Message-ID: <529320CF.7000709@oracle.com> Rickard, You should also add -XX:+IgnoreUnrecognizedVMOptions, because UseMathExactIntrinsics is a c2_only flag. On 11/25/2013 12:54 PM, Rickard B?ckman wrote: > Updated with flags for tests. > > Webrev: http://cr.openjdk.java.net/~rbackman/8028997.1/ > > Thanks > /R > > On 11/22, Vladimir Kozlov wrote: >> On 11/22/13 5:40 AM, Leonid Mesnik wrote: >>> Rickard >>> >>> Does it make a sense to update corresponding tests by switching UseMathExactIntrinsics on explicitly? >> >> Yes, it should be done in these changes. >> >> Thanks, >> Vladimir >> >>> >>> Leonid >>> On 11/22/2013 05:31 PM, Rickard B?ckman wrote: >>>> Hi all, >>>> >>>> can I have a couple of reviews for this small change? >>>> It basically sets the default value of UseMathExactIntrinsics to false >>>> and moves it to be an experimental vm option. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rbackman/8028997/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028997 >>>> >>>> Thanks >>>> /R >>> >>> From albert.noll at oracle.com Mon Nov 25 05:27:46 2013 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 25 Nov 2013 14:27:46 +0100 Subject: RFR(XXS): 8029091: Bug in calculation of code cache sweeping interval Message-ID: <52935052.9050704@oracle.com> Hi all, could I have reviews for this small patch? Bug: _ _https://bugs.openjdk.java.net/browse/JDK-8029091 Webrev: http://cr.openjdk.java.net/~anoll/8029091/webrev.00/ Problem: The calculation of 'wait_until_next_sweep' in 'NMethodSweeper::possibly_sweep() {}' has a signed to unsigned conversion bug. The calculation is currently done as follows: double wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - time_since_last_sweep - CodeCache::reverse_free_ratio(); Since the type of 'ReservedCodeCacheSize' (uintx) has a higher rank than 'time_since_last_sleep' (int) and 'time_since_last_sweep' can be larger than ' (ReservedCodeCacheSize / (16 * M))' there is an underflow. Consequently, 'wait_until_next_sweep' is assigned a wrong value, which disables the intended periodic code cache sweeps. Solution: Use only signed types for the calculation of 'wait_until_next_sweep'. Furthermore, an assert checks that 'wait_until_next_sweep' is never larger than ' (ReservedCodeCacheSize / (16 * M))', which is the maximum time between two sweeps. Many thanks in advance, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131125/23ddcfb1/attachment.html From vladimir.kozlov at oracle.com Mon Nov 25 09:33:16 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Nov 2013 09:33:16 -0800 Subject: RFR(XXS): 8029091: Bug in calculation of code cache sweeping interval In-Reply-To: <52935052.9050704@oracle.com> References: <52935052.9050704@oracle.com> Message-ID: <529389DC.2040403@oracle.com> Albert, What if you use double type for calculations?: + const double max_wait_time = (double)ReservedCodeCacheSize / (16 * M); Thanks, Vladimir On 11/25/13 5:27 AM, Albert Noll wrote: > Hi all, > > could I have reviews for this small patch? > > Bug: _ > _https://bugs.openjdk.java.net/browse/JDK-8029091 > > Webrev: > http://cr.openjdk.java.net/~anoll/8029091/webrev.00/ > > Problem: > The calculation of 'wait_until_next_sweep' in 'NMethodSweeper::possibly_sweep() {}' has a signed > to unsigned conversion bug. The calculation is currently done as follows: > > double wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - time_since_last_sweep - > CodeCache::reverse_free_ratio(); > > Since the type of 'ReservedCodeCacheSize' (uintx) has a higher rank than 'time_since_last_sleep' (int) and > 'time_since_last_sweep' can be larger than ' (ReservedCodeCacheSize / (16 * M))' there is an underflow. Consequently, > 'wait_until_next_sweep' is assigned a wrong value, which disables the intended periodic code cache sweeps. > > Solution: > Use only signed types for the calculation of 'wait_until_next_sweep'. Furthermore, an assert checks that > 'wait_until_next_sweep' is never larger than ' (ReservedCodeCacheSize / (16 * M))', which is the > maximum time between two sweeps. > > > Many thanks in advance, > Albert From vladimir.kozlov at oracle.com Mon Nov 25 09:47:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Nov 2013 09:47:31 -0800 Subject: RFR(XXS): 8029091: Bug in calculation of code cache sweeping interval In-Reply-To: <529389DC.2040403@oracle.com> References: <52935052.9050704@oracle.com> <529389DC.2040403@oracle.com> Message-ID: <52938D33.6030405@oracle.com> On other hand ReservedCodeCacheSize can't be big since there is 2Gb limit. So it is small int value. That in mind the fix is good. Thanks, Vladimir On 11/25/13 9:33 AM, Vladimir Kozlov wrote: > Albert, > > What if you use double type for calculations?: > > + const double max_wait_time = (double)ReservedCodeCacheSize / (16 * M); > > Thanks, > Vladimir > > On 11/25/13 5:27 AM, Albert Noll wrote: >> Hi all, >> >> could I have reviews for this small patch? >> >> Bug: _ >> _https://bugs.openjdk.java.net/browse/JDK-8029091 >> >> Webrev: >> http://cr.openjdk.java.net/~anoll/8029091/webrev.00/ >> >> Problem: >> The calculation of 'wait_until_next_sweep' in 'NMethodSweeper::possibly_sweep() {}' has a signed >> to unsigned conversion bug. The calculation is currently done as follows: >> >> double wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - time_since_last_sweep - >> CodeCache::reverse_free_ratio(); >> >> Since the type of 'ReservedCodeCacheSize' (uintx) has a higher rank than 'time_since_last_sleep' (int) and >> 'time_since_last_sweep' can be larger than ' (ReservedCodeCacheSize / (16 * M))' there is an underflow. Consequently, >> 'wait_until_next_sweep' is assigned a wrong value, which disables the intended periodic code cache sweeps. >> >> Solution: >> Use only signed types for the calculation of 'wait_until_next_sweep'. Furthermore, an assert checks that >> 'wait_until_next_sweep' is never larger than ' (ReservedCodeCacheSize / (16 * M))', which is the >> maximum time between two sweeps. >> >> >> Many thanks in advance, >> Albert From vladimir.kozlov at oracle.com Mon Nov 25 09:49:00 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Nov 2013 09:49:00 -0800 Subject: RFR(XS): 8028997: mathexact intrinsics are unstabl In-Reply-To: <529320CF.7000709@oracle.com> References: <20131122133104.GB19422@rbackman> <528F5EBB.6080101@oracle.com> <528F8E1D.9070606@oracle.com> <20131125085452.GA29591@rbackman> <529320CF.7000709@oracle.com> Message-ID: <52938D8C.2060501@oracle.com> On 11/25/13 2:05 AM, Igor Ignatyev wrote: > Rickard, > > You should also add -XX:+IgnoreUnrecognizedVMOptions, because UseMathExactIntrinsics is a c2_only flag. Yes. Thanks, Vladimir > > On 11/25/2013 12:54 PM, Rickard B?ckman wrote: >> Updated with flags for tests. >> >> Webrev: http://cr.openjdk.java.net/~rbackman/8028997.1/ >> >> Thanks >> /R >> >> On 11/22, Vladimir Kozlov wrote: >>> On 11/22/13 5:40 AM, Leonid Mesnik wrote: >>>> Rickard >>>> >>>> Does it make a sense to update corresponding tests by switching UseMathExactIntrinsics on explicitly? >>> >>> Yes, it should be done in these changes. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Leonid >>>> On 11/22/2013 05:31 PM, Rickard B?ckman wrote: >>>>> Hi all, >>>>> >>>>> can I have a couple of reviews for this small change? >>>>> It basically sets the default value of UseMathExactIntrinsics to false >>>>> and moves it to be an experimental vm option. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8028997/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028997 >>>>> >>>>> Thanks >>>>> /R >>>> >>>> From vladimir.kozlov at oracle.com Mon Nov 25 09:58:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Nov 2013 09:58:40 -0800 Subject: RFR(XXS): 8029091: Bug in calculation of code cache sweeping interval In-Reply-To: <52938D33.6030405@oracle.com> References: <52935052.9050704@oracle.com> <529389DC.2040403@oracle.com> <52938D33.6030405@oracle.com> Message-ID: <52938FD0.4070703@oracle.com> Sorry, it is Monday morning. CodeCache::reverse_free_ratio() returns double. Then why calculation is not done in doubles in original code? Can you just swap time_since_last_sweep and CodeCache::reverse_free_ratio() if it is order dependent? Thanks, Vladimir On 11/25/13 9:47 AM, Vladimir Kozlov wrote: > On other hand ReservedCodeCacheSize can't be big since there is 2Gb limit. So it is small int value. > That in mind the fix is good. > > Thanks, > Vladimir > > On 11/25/13 9:33 AM, Vladimir Kozlov wrote: >> Albert, >> >> What if you use double type for calculations?: >> >> + const double max_wait_time = (double)ReservedCodeCacheSize / (16 * M); >> >> Thanks, >> Vladimir >> >> On 11/25/13 5:27 AM, Albert Noll wrote: >>> Hi all, >>> >>> could I have reviews for this small patch? >>> >>> Bug: _ >>> _https://bugs.openjdk.java.net/browse/JDK-8029091 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~anoll/8029091/webrev.00/ >>> >>> Problem: >>> The calculation of 'wait_until_next_sweep' in 'NMethodSweeper::possibly_sweep() {}' has a signed >>> to unsigned conversion bug. The calculation is currently done as follows: >>> >>> double wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - time_since_last_sweep - >>> CodeCache::reverse_free_ratio(); >>> >>> Since the type of 'ReservedCodeCacheSize' (uintx) has a higher rank than 'time_since_last_sleep' (int) and >>> 'time_since_last_sweep' can be larger than ' (ReservedCodeCacheSize / (16 * M))' there is an underflow. Consequently, >>> 'wait_until_next_sweep' is assigned a wrong value, which disables the intended periodic code cache sweeps. >>> >>> Solution: >>> Use only signed types for the calculation of 'wait_until_next_sweep'. Furthermore, an assert checks that >>> 'wait_until_next_sweep' is never larger than ' (ReservedCodeCacheSize / (16 * M))', which is the >>> maximum time between two sweeps. >>> >>> >>> Many thanks in advance, >>> Albert From albert.noll at oracle.com Mon Nov 25 11:27:30 2013 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 25 Nov 2013 20:27:30 +0100 Subject: RFR(XXS): 8029091: Bug in calculation of code cache sweeping interval In-Reply-To: <52938FD0.4070703@oracle.com> References: <52935052.9050704@oracle.com> <529389DC.2040403@oracle.com> <52938D33.6030405@oracle.com> <52938FD0.4070703@oracle.com> Message-ID: <63E3F219-3365-4694-822A-8F075DE2C181@oracle.com> Hi Vladimir, Thanks for looking at this. The current patch casts the unsigned value (ReservedCodeCacheSize) to a signed value. That should be fine, since the result will always be small enough to fit into an int. This seems clearer to me than depending on ordering and implicit type casts. Best, Albert Von meinem iPhone gesendet > Am 25.11.2013 um 18:58 schrieb Vladimir Kozlov : > > Sorry, it is Monday morning. > > CodeCache::reverse_free_ratio() returns double. Then why calculation is not done in doubles in original code? > Can you just swap time_since_last_sweep and CodeCache::reverse_free_ratio() if it is order dependent? > > Thanks, > Vladimir > >> On 11/25/13 9:47 AM, Vladimir Kozlov wrote: >> On other hand ReservedCodeCacheSize can't be big since there is 2Gb limit. So it is small int value. >> That in mind the fix is good. >> >> Thanks, >> Vladimir >> >>> On 11/25/13 9:33 AM, Vladimir Kozlov wrote: >>> Albert, >>> >>> What if you use double type for calculations?: >>> >>> + const double max_wait_time = (double)ReservedCodeCacheSize / (16 * M); >>> >>> Thanks, >>> Vladimir >>> >>>> On 11/25/13 5:27 AM, Albert Noll wrote: >>>> Hi all, >>>> >>>> could I have reviews for this small patch? >>>> >>>> Bug: _ >>>> _https://bugs.openjdk.java.net/browse/JDK-8029091 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~anoll/8029091/webrev.00/ >>>> >>>> Problem: >>>> The calculation of 'wait_until_next_sweep' in 'NMethodSweeper::possibly_sweep() {}' has a signed >>>> to unsigned conversion bug. The calculation is currently done as follows: >>>> >>>> double wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - time_since_last_sweep - >>>> CodeCache::reverse_free_ratio(); >>>> >>>> Since the type of 'ReservedCodeCacheSize' (uintx) has a higher rank than 'time_since_last_sleep' (int) and >>>> 'time_since_last_sweep' can be larger than ' (ReservedCodeCacheSize / (16 * M))' there is an underflow. Consequently, >>>> 'wait_until_next_sweep' is assigned a wrong value, which disables the intended periodic code cache sweeps. >>>> >>>> Solution: >>>> Use only signed types for the calculation of 'wait_until_next_sweep'. Furthermore, an assert checks that >>>> 'wait_until_next_sweep' is never larger than ' (ReservedCodeCacheSize / (16 * M))', which is the >>>> maximum time between two sweeps. >>>> >>>> >>>> Many thanks in advance, >>>> Albert From vladimir.kozlov at oracle.com Mon Nov 25 11:53:04 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Nov 2013 11:53:04 -0800 Subject: RFR(XXS): 8029091: Bug in calculation of code cache sweeping interval In-Reply-To: <63E3F219-3365-4694-822A-8F075DE2C181@oracle.com> References: <52935052.9050704@oracle.com> <529389DC.2040403@oracle.com> <52938D33.6030405@oracle.com> <52938FD0.4070703@oracle.com> <63E3F219-3365-4694-822A-8F075DE2C181@oracle.com> Message-ID: <5293AAA0.1040706@oracle.com> On 11/25/13 11:27 AM, Albert Noll wrote: > Hi Vladimir, > > Thanks for looking at this. The current patch casts the unsigned value (ReservedCodeCacheSize) to a signed value. That should be fine, since the result will always be small enough to fit into an int. Yes, it is true. > > This seems clearer to me than depending on ordering and implicit type casts. Okay. Thanks, Vladimir > > Best, > Albert > > Von meinem iPhone gesendet > >> Am 25.11.2013 um 18:58 schrieb Vladimir Kozlov : >> >> Sorry, it is Monday morning. >> >> CodeCache::reverse_free_ratio() returns double. Then why calculation is not done in doubles in original code? >> Can you just swap time_since_last_sweep and CodeCache::reverse_free_ratio() if it is order dependent? >> >> Thanks, >> Vladimir >> >>> On 11/25/13 9:47 AM, Vladimir Kozlov wrote: >>> On other hand ReservedCodeCacheSize can't be big since there is 2Gb limit. So it is small int value. >>> That in mind the fix is good. >>> >>> Thanks, >>> Vladimir >>> >>>> On 11/25/13 9:33 AM, Vladimir Kozlov wrote: >>>> Albert, >>>> >>>> What if you use double type for calculations?: >>>> >>>> + const double max_wait_time = (double)ReservedCodeCacheSize / (16 * M); >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> On 11/25/13 5:27 AM, Albert Noll wrote: >>>>> Hi all, >>>>> >>>>> could I have reviews for this small patch? >>>>> >>>>> Bug: _ >>>>> _https://bugs.openjdk.java.net/browse/JDK-8029091 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~anoll/8029091/webrev.00/ >>>>> >>>>> Problem: >>>>> The calculation of 'wait_until_next_sweep' in 'NMethodSweeper::possibly_sweep() {}' has a signed >>>>> to unsigned conversion bug. The calculation is currently done as follows: >>>>> >>>>> double wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - time_since_last_sweep - >>>>> CodeCache::reverse_free_ratio(); >>>>> >>>>> Since the type of 'ReservedCodeCacheSize' (uintx) has a higher rank than 'time_since_last_sleep' (int) and >>>>> 'time_since_last_sweep' can be larger than ' (ReservedCodeCacheSize / (16 * M))' there is an underflow. Consequently, >>>>> 'wait_until_next_sweep' is assigned a wrong value, which disables the intended periodic code cache sweeps. >>>>> >>>>> Solution: >>>>> Use only signed types for the calculation of 'wait_until_next_sweep'. Furthermore, an assert checks that >>>>> 'wait_until_next_sweep' is never larger than ' (ReservedCodeCacheSize / (16 * M))', which is the >>>>> maximum time between two sweeps. >>>>> >>>>> >>>>> Many thanks in advance, >>>>> Albert From albert.noll at oracle.com Mon Nov 25 12:20:26 2013 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 25 Nov 2013 21:20:26 +0100 Subject: RFR(XXS): 8029091: Bug in calculation of code cache sweeping interval In-Reply-To: <5293AAA0.1040706@oracle.com> References: <52935052.9050704@oracle.com> <529389DC.2040403@oracle.com> <52938D33.6030405@oracle.com> <52938FD0.4070703@oracle.com> <63E3F219-3365-4694-822A-8F075DE2C181@oracle.com> <5293AAA0.1040706@oracle.com> Message-ID: Thanks for the review Vladimir. Best, Albert Von meinem iPhone gesendet > Am 25.11.2013 um 20:53 schrieb Vladimir Kozlov : > >> On 11/25/13 11:27 AM, Albert Noll wrote: >> Hi Vladimir, >> >> Thanks for looking at this. The current patch casts the unsigned value (ReservedCodeCacheSize) to a signed value. That should be fine, since the result will always be small enough to fit into an int. > > Yes, it is true. > >> >> This seems clearer to me than depending on ordering and implicit type casts. > > Okay. > > Thanks, > Vladimir > >> >> Best, >> Albert >> >> Von meinem iPhone gesendet >> >>> Am 25.11.2013 um 18:58 schrieb Vladimir Kozlov : >>> >>> Sorry, it is Monday morning. >>> >>> CodeCache::reverse_free_ratio() returns double. Then why calculation is not done in doubles in original code? >>> Can you just swap time_since_last_sweep and CodeCache::reverse_free_ratio() if it is order dependent? >>> >>> Thanks, >>> Vladimir >>> >>>> On 11/25/13 9:47 AM, Vladimir Kozlov wrote: >>>> On other hand ReservedCodeCacheSize can't be big since there is 2Gb limit. So it is small int value. >>>> That in mind the fix is good. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> On 11/25/13 9:33 AM, Vladimir Kozlov wrote: >>>>> Albert, >>>>> >>>>> What if you use double type for calculations?: >>>>> >>>>> + const double max_wait_time = (double)ReservedCodeCacheSize / (16 * M); >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> On 11/25/13 5:27 AM, Albert Noll wrote: >>>>>> Hi all, >>>>>> >>>>>> could I have reviews for this small patch? >>>>>> >>>>>> Bug: _ >>>>>> _https://bugs.openjdk.java.net/browse/JDK-8029091 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~anoll/8029091/webrev.00/ >>>>>> >>>>>> Problem: >>>>>> The calculation of 'wait_until_next_sweep' in 'NMethodSweeper::possibly_sweep() {}' has a signed >>>>>> to unsigned conversion bug. The calculation is currently done as follows: >>>>>> >>>>>> double wait_until_next_sweep = (ReservedCodeCacheSize / (16 * M)) - time_since_last_sweep - >>>>>> CodeCache::reverse_free_ratio(); >>>>>> >>>>>> Since the type of 'ReservedCodeCacheSize' (uintx) has a higher rank than 'time_since_last_sleep' (int) and >>>>>> 'time_since_last_sweep' can be larger than ' (ReservedCodeCacheSize / (16 * M))' there is an underflow. Consequently, >>>>>> 'wait_until_next_sweep' is assigned a wrong value, which disables the intended periodic code cache sweeps. >>>>>> >>>>>> Solution: >>>>>> Use only signed types for the calculation of 'wait_until_next_sweep'. Furthermore, an assert checks that >>>>>> 'wait_until_next_sweep' is never larger than ' (ReservedCodeCacheSize / (16 * M))', which is the >>>>>> maximum time between two sweeps. >>>>>> >>>>>> >>>>>> Many thanks in advance, >>>>>> Albert From roland.westrelin at oracle.com Tue Nov 26 02:17:34 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 26 Nov 2013 11:17:34 +0100 Subject: RFR(XXS): 8029091: Bug in calculation of code cache sweeping interval In-Reply-To: <52935052.9050704@oracle.com> References: <52935052.9050704@oracle.com> Message-ID: <87haaz79hd.fsf@oracle.com> Hi Albert, > http://cr.openjdk.java.net/~anoll/8029091/webrev.00/ The change looks good to me but I think the comment should state more clearly why we load ReservedCodeCacheSize in a signed integer. Roland. From albert.noll at oracle.com Tue Nov 26 04:28:04 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 26 Nov 2013 13:28:04 +0100 Subject: RFR(XXS): 8029091: Bug in calculation of code cache sweeping interval In-Reply-To: <87haaz79hd.fsf@oracle.com> References: <52935052.9050704@oracle.com> <87haaz79hd.fsf@oracle.com> Message-ID: <529493D4.8020406@oracle.com> Hi Roland, thanks for the review. What do you think about this comment? http://cr.openjdk.java.net/~anoll/8029091/webrev.01/ Best, Albert On 11/26/2013 11:17 AM, Roland Westrelin wrote: > Hi Albert, > >> http://cr.openjdk.java.net/~anoll/8029091/webrev.00/ > The change looks good to me but I think the comment should state more > clearly why we load ReservedCodeCacheSize in a signed integer. > > Roland. From roland.westrelin at oracle.com Tue Nov 26 04:38:32 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 26 Nov 2013 13:38:32 +0100 Subject: RFR(XXS): 8029091: Bug in calculation of code cache sweeping interval In-Reply-To: <529493D4.8020406@oracle.com> References: <52935052.9050704@oracle.com> <87haaz79hd.fsf@oracle.com> <529493D4.8020406@oracle.com> Message-ID: <9BD160C4-07B0-4A93-BFFB-68939CEA4A1A@oracle.com> > thanks for the review. What do you think about this comment? > http://cr.openjdk.java.net/~anoll/8029091/webrev.01/ That looks good to me. Thanks for improving the comment. Roland. From albert.noll at oracle.com Tue Nov 26 04:43:15 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 26 Nov 2013 13:43:15 +0100 Subject: RFR(XXS): 8029091: Bug in calculation of code cache sweeping interval In-Reply-To: <9BD160C4-07B0-4A93-BFFB-68939CEA4A1A@oracle.com> References: <52935052.9050704@oracle.com> <87haaz79hd.fsf@oracle.com> <529493D4.8020406@oracle.com> <9BD160C4-07B0-4A93-BFFB-68939CEA4A1A@oracle.com> Message-ID: <52949763.9040400@oracle.com> Thanks for looking at it again. Best, Albert On 11/26/2013 01:38 PM, Roland Westrelin wrote: >> thanks for the review. What do you think about this comment? >> http://cr.openjdk.java.net/~anoll/8029091/webrev.01/ > That looks good to me. Thanks for improving the comment. > > Roland. From trent.tong at gmail.com Tue Nov 26 07:29:55 2013 From: trent.tong at gmail.com (Xin Tong) Date: Tue, 26 Nov 2013 07:29:55 -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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131126/975a7e69/attachment.html From igor.veresov at oracle.com Tue Nov 26 14:18:38 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 26 Nov 2013 14:18:38 -0800 Subject: reclaim code cache In-Reply-To: References: Message-ID: <7A1BEAA8-3881-4551-BE43-7D9C45DC1469@oracle.com> Yes, of course it does. igor On Nov 26, 2013, at 7:29 AM, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131126/54f3d392/attachment.html From david.r.chase at oracle.com Tue Nov 26 17:33:28 2013 From: david.r.chase at oracle.com (david.r.chase at oracle.com) Date: Wed, 27 Nov 2013 01:33:28 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8016839: JSR292: AME instead of IAE when calling a method Message-ID: <20131127013330.9157462896@hg.openjdk.java.net> Changeset: 9d15b81d5d1b Author: drchase Date: 2013-11-26 18:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From markus.gronlund at oracle.com Wed Nov 27 01:47:09 2013 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 27 Nov 2013 01:47:09 -0800 (PST) Subject: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40 Message-ID: <3ee2cce7-8c32-448f-b1c0-252df5996516@default> Greetings, Kindly asking for reviews for the following change: Bug: https://bugs.openjdk.java.net/browse/JDK-8028412 Webrev: http://cr.openjdk.java.net/~mgronlun/8028412/webrev01/ Description: AsynchGetCallTrace() uses platform specific code for stack frame traversals. On x86, there currently exist a defensive construct that practically disallows stack traversal over entry_frame code stubs, such as StubRoutine(1) frames: src/cpu/x86/vm/frame_x86.cpp b/src/cpu/x86/vm/frame_x86.cpp: bool frame::safe_for_sender(JavaThread* thread) { . if (!Interpreter::contains(_pc) && _cb->frame_size() <= 0) { //assert(0, "Invalid frame_size"); return false; } . Since entry frames (such as StubRoutine(1)) have a frame size of 0, the code returns prematurely. Fix is to move this frame size check post handling of is_entry_frame(), where the code_stubs are processed. Testing completed: Sun Studio Profiler reproducer testcase SpecJBB2005 Kitchensink Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131127/0399508b/attachment.html From serguei.spitsyn at oracle.com Wed Nov 27 02:30:32 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Nov 2013 02:30:32 -0800 Subject: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40 In-Reply-To: <3ee2cce7-8c32-448f-b1c0-252df5996516@default> References: <3ee2cce7-8c32-448f-b1c0-252df5996516@default> Message-ID: <5295C9C8.5080107@oracle.com> Hi Markus, The fix looks Ok. It'd be helpful if Oleg and the Solaris Studio guys could confirm this fix works fine for them. I've added Oleg and Nik to the CC-list. They might request a link to the Solaris or Linux binaries. Thanks, Serguei On 11/27/13 1:47 AM, Markus Gronlund wrote: > > Greetings, > > Kindly asking for reviews for the following change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028412 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8028412/webrev01/ > > > Description: > > AsynchGetCallTrace() uses platform specific code for stack frame > traversals. > > On x86, there currently exist a defensive construct that practically > disallows stack traversal over entry_frame code stubs, such as > StubRoutine(1) frames: > > src/cpu/x86/vm/frame_x86.cpp b/src/cpu/x86/vm/frame_x86.cpp: > > bool frame::safe_for_sender(JavaThread* thread) { > > ... > > if (!Interpreter::contains(_pc) && _cb->frame_size() <= 0) { > //assert(0, "Invalid frame_size"); > > return false; > } > > ... > > Since entry frames (such as StubRoutine(1)) have a frame size of 0, > the code returns prematurely. > > Fix is to move this frame size check post handling of > is_entry_frame(), where the code_stubs are processed. > > Testing completed: > > Sun Studio Profiler reproducer testcase > > SpecJBB2005 > > Kitchensink > > Thanks > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131127/4cda0aa6/attachment.html From markus.gronlund at oracle.com Wed Nov 27 02:32:25 2013 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 27 Nov 2013 02:32:25 -0800 (PST) Subject: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40 In-Reply-To: <5295C9C8.5080107@oracle.com> References: <3ee2cce7-8c32-448f-b1c0-252df5996516@default> <5295C9C8.5080107@oracle.com> Message-ID: <25d24144-d3a9-4f5a-8a11-bbd5e4ed708c@default> Hi Sergei, I have already worked with Nik on this issue and got his confirmation on the fix. Thanks Markus From: Serguei Spitsyn Sent: den 27 november 2013 11:31 To: Markus Gronlund; hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; serviceability-dev Cc: Oleg Mazurov; Nikolay Molchanov Subject: Re: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40 Hi Markus, The fix looks Ok. It'd be helpful if Oleg and the Solaris Studio guys could confirm this fix works fine for them. I've added Oleg and Nik to the CC-list. They might request a link to the Solaris or Linux binaries. Thanks, Serguei On 11/27/13 1:47 AM, Markus Gronlund wrote: Greetings, Kindly asking for reviews for the following change: Bug: https://bugs.openjdk.java.net/browse/JDK-8028412 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8028412/webrev01/"http://cr.openjdk.java.net/~mgronlun/8028412/webrev01/ Description: AsynchGetCallTrace() uses platform specific code for stack frame traversals. On x86, there currently exist a defensive construct that practically disallows stack traversal over entry_frame code stubs, such as StubRoutine(1) frames: src/cpu/x86/vm/frame_x86.cpp b/src/cpu/x86/vm/frame_x86.cpp: bool frame::safe_for_sender(JavaThread* thread) { . if (!Interpreter::contains(_pc) && _cb->frame_size() <= 0) { //assert(0, "Invalid frame_size"); return false; } . Since entry frames (such as StubRoutine(1)) have a frame size of 0, the code returns prematurely. Fix is to move this frame size check post handling of is_entry_frame(), where the code_stubs are processed. Testing completed: Sun Studio Profiler reproducer testcase SpecJBB2005 Kitchensink Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131127/0280cdff/attachment-0001.html From serguei.spitsyn at oracle.com Wed Nov 27 02:34:14 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Nov 2013 02:34:14 -0800 Subject: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40 In-Reply-To: <25d24144-d3a9-4f5a-8a11-bbd5e4ed708c@default> References: <3ee2cce7-8c32-448f-b1c0-252df5996516@default> <5295C9C8.5080107@oracle.com> <25d24144-d3a9-4f5a-8a11-bbd5e4ed708c@default> Message-ID: <5295CAA6.5080208@oracle.com> On 11/27/13 2:32 AM, Markus Gronlund wrote: > > Hi Sergei, > > I have already worked with Nik on this issue and got his confirmation > on the fix. > Cool! Thanks, Serguei > Thanks > > Markus > > *From:*Serguei Spitsyn > *Sent:* den 27 november 2013 11:31 > *To:* Markus Gronlund; hotspot-compiler-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net; serviceability-dev > *Cc:* Oleg Mazurov; Nikolay Molchanov > *Subject:* Re: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 > in JDK7u40 > > Hi Markus, > > The fix looks Ok. > > It'd be helpful if Oleg and the Solaris Studio guys could confirm this > fix works fine for them. > I've added Oleg and Nik to the CC-list. > They might request a link to the Solaris or Linux binaries. > > Thanks, > Serguei > > > On 11/27/13 1:47 AM, Markus Gronlund wrote: > > Greetings, > > Kindly asking for reviews for the following change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028412 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8028412/webrev01/ > > > Description: > > AsynchGetCallTrace() uses platform specific code for stack frame > traversals. > > On x86, there currently exist a defensive construct that > practically disallows stack traversal over entry_frame code stubs, > such as StubRoutine(1) frames: > > src/cpu/x86/vm/frame_x86.cpp b/src/cpu/x86/vm/frame_x86.cpp: > > bool frame::safe_for_sender(JavaThread* thread) { > > ... > > if (!Interpreter::contains(_pc) && _cb->frame_size() <= 0) { > //assert(0, "Invalid frame_size"); > > return false; > } > > ... > > Since entry frames (such as StubRoutine(1)) have a frame size of > 0, the code returns prematurely. > > Fix is to move this frame size check post handling of > is_entry_frame(), where the code_stubs are processed. > > Testing completed: > > Sun Studio Profiler reproducer testcase > > SpecJBB2005 > > Kitchensink > > Thanks > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131127/6c6c986f/attachment.html From albert.noll at oracle.com Wed Nov 27 08:26:46 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 27 Nov 2013 17:26:46 +0100 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: <7F9638CF-DA59-44E3-B4B8-0BE317ADC98F@oracle.com> References: <528B2347.7010902@oracle.com> <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> <528B8AF0.5050506@oracle.com> <528BBDC8.9010804@oracle.com> <528BC542.6090108@oracle.com> <7F9638CF-DA59-44E3-B4B8-0BE317ADC98F@oracle.com> Message-ID: <52961D46.8040201@oracle.com> Igor, Vladimir, thanks for the reviews. Here is a version that uses 'mov' for 32-bit and 64-bit to load 'byte_map_base'. http://cr.openjdk.java.net/~anoll/8028109/webrev.02/ Best, Albert On 11/19/2013 09:31 PM, Igor Veresov wrote: > Indeed, I agree, a move would be more straightforward. > Later on we?ll need a special type of relocation added for the cardtable pointer anyway, because it has very unique rules to compute it depending on both location of the heap and the cardtable array. It is certainly not an ExternalAddress. > > igor > > On Nov 19, 2013, at 12:08 PM, Vladimir Kozlov wrote: > >> On 11/19/13 11:57 AM, Igor Veresov wrote: >>> Except we will need some relocation info for it if we plan to do snapshotting. >> True, but after Tom's fix it does not have a relocation in all cases already: >> >> http://cr.openjdk.java.net/~never/6777083/src/cpu/x86/vm/assembler_x86.hpp.udiff.html >> >> And I think, there are places where we don't use ExternalAddress so we may need to solve serialization differently later. >> >> Thanks, >> Vladimir >> >>> igor >>> >>> On Nov 19, 2013, at 11:36 AM, Vladimir Kozlov wrote: >>> >>>> Last version is not good because it may hide bug when wrong address matches byte_map_base value. Original Tom's fix also hides problems. >>>> >>>> MacroAssembler::g1_write_barrier_post() and store_check_part_2() are used only in interpreter. It does not make sense to optimize it. Note, x86 has limited throughput for address calculations. And one instruction is only generated if this address is 32-bit which may be not true then you have to move it into register too. >>>> >>>> Anyway, we can go case by case and avoid ExternalAddress in 64-bit VM because code allows us to do that: >>>> >>>> In both cases in c1_Runtime1_x86.cpp and in MacroAssembler::g1_write_barrier_post() there is separate lea() instruction for LP64 which could be replaced with mov to load constant. >>>> >>>> MacroAssembler::store_check_part_2() is different case which we may prefer to use in other cases. Note, as_Address(ArrayAddress adr) generates lea() instruction again. Which means code for 32-bit VM in c1_Runtime1_x86.cpp generates 2 lea instructions and not one: >>>> >>>> __ leal(card_addr, __ as_Address(ArrayAddress(cardtable, index))); >>>> >>>> What I am saying is lets use mov instruction to load byte_map_base instead of using ExternalAddress because we don't need relocation for it and because in reality (with all past fixes) we will generate the same number of instructions. >>>> >>>> Regards, >>>> Vladimir >>>> >>>> On 11/19/13 7:59 AM, Albert Noll wrote: >>>>> Hi Roland, >>>>> >>>>> thanks for pointing this out. Here is a patch that executes the assert >>>>> only if >>>>> the address we are checking is not byte_map_base. This might not be the >>>>> most >>>>> elegant solution, but at least it seems to work. >>>>> >>>>> Here is the new webrev: >>>>> http://cr.openjdk.java.net/~anoll/8028109/webrev.01/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 11/19/2013 10:00 AM, Roland Westrelin wrote: >>>>>>> Solution: Change 'ExternalAddress' to 'AddressLiteral' that generates >>>>>>> no relocation information for >>>>>>> byte_map_base. Other platforms also AddressLiteral >>>>>>> without relocation information. >>>>>> As mentioned in the thread here: >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005151.html >>>>>> >>>>>> in this message: >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005161.html >>>>>> >>>>>> >>>>>> not using ExternalAddress disables rip relative addressing. >>>>>> This said, I?m not sure what a clean fix for this would be. >>>>>> >>>>>> Roland. From vladimir.kozlov at oracle.com Wed Nov 27 10:03:50 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Nov 2013 10:03:50 -0800 Subject: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40 In-Reply-To: <3ee2cce7-8c32-448f-b1c0-252df5996516@default> References: <3ee2cce7-8c32-448f-b1c0-252df5996516@default> Message-ID: <52963406.1050200@oracle.com> Hi, Markus I think the bug report should link to 8005849 which introduced this additional check and regression. Is it possible to prepare a jtreg test which will use AsynchGetCallTrace and catch such situations in a future? The fix itself looks good. Thanks, Vladimir On 11/27/13 1:47 AM, Markus Gronlund wrote: > Greetings, > > Kindly asking for reviews for the following change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028412 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8028412/webrev01/ > > Description: > > AsynchGetCallTrace() uses platform specific code for stack frame traversals. > > On x86, there currently exist a defensive construct that practically > disallows stack traversal over entry_frame code stubs, such as > StubRoutine(1) frames: > > src/cpu/x86/vm/frame_x86.cpp b/src/cpu/x86/vm/frame_x86.cpp: > > bool frame::safe_for_sender(JavaThread* thread) { > > ? > > if (!Interpreter::contains(_pc) && _cb->frame_size() <= 0) { > //assert(0, "Invalid frame_size"); > > return false; > } > > ? > > Since entry frames (such as StubRoutine(1)) have a frame size of 0, the > code returns prematurely. > > Fix is to move this frame size check post handling of is_entry_frame(), > where the code_stubs are processed. > > Testing completed: > > Sun Studio Profiler reproducer testcase > > SpecJBB2005 > > Kitchensink > > Thanks > Markus > From vladimir.kozlov at oracle.com Wed Nov 27 10:23:17 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Nov 2013 10:23:17 -0800 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: <52961D46.8040201@oracle.com> References: <528B2347.7010902@oracle.com> <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> <528B8AF0.5050506@oracle.com> <528BBDC8.9010804@oracle.com> <528BC542.6090108@oracle.com> <7F9638CF-DA59-44E3-B4B8-0BE317ADC98F@oracle.com> <52961D46.8040201@oracle.com> Message-ID: <52963895.4050004@oracle.com> Thank you, Albert, for additional comments. Fix looks good. Thanks, Vladimir On 11/27/13 8:26 AM, Albert Noll wrote: > Igor, Vladimir, thanks for the reviews. > > Here is a version that uses 'mov' for 32-bit and 64-bit to load > 'byte_map_base'. > > http://cr.openjdk.java.net/~anoll/8028109/webrev.02/ > > Best, > Albert > > On 11/19/2013 09:31 PM, Igor Veresov wrote: >> Indeed, I agree, a move would be more straightforward. >> Later on we?ll need a special type of relocation added for the >> cardtable pointer anyway, because it has very unique rules to compute >> it depending on both location of the heap and the cardtable array. It >> is certainly not an ExternalAddress. >> >> igor >> >> On Nov 19, 2013, at 12:08 PM, Vladimir Kozlov >> wrote: >> >>> On 11/19/13 11:57 AM, Igor Veresov wrote: >>>> Except we will need some relocation info for it if we plan to do >>>> snapshotting. >>> True, but after Tom's fix it does not have a relocation in all cases >>> already: >>> >>> http://cr.openjdk.java.net/~never/6777083/src/cpu/x86/vm/assembler_x86.hpp.udiff.html >>> >>> >>> And I think, there are places where we don't use ExternalAddress so >>> we may need to solve serialization differently later. >>> >>> Thanks, >>> Vladimir >>> >>>> igor >>>> >>>> On Nov 19, 2013, at 11:36 AM, Vladimir Kozlov >>>> wrote: >>>> >>>>> Last version is not good because it may hide bug when wrong address >>>>> matches byte_map_base value. Original Tom's fix also hides problems. >>>>> >>>>> MacroAssembler::g1_write_barrier_post() and store_check_part_2() >>>>> are used only in interpreter. It does not make sense to optimize >>>>> it. Note, x86 has limited throughput for address calculations. And >>>>> one instruction is only generated if this address is 32-bit which >>>>> may be not true then you have to move it into register too. >>>>> >>>>> Anyway, we can go case by case and avoid ExternalAddress in 64-bit >>>>> VM because code allows us to do that: >>>>> >>>>> In both cases in c1_Runtime1_x86.cpp and in >>>>> MacroAssembler::g1_write_barrier_post() there is separate lea() >>>>> instruction for LP64 which could be replaced with mov to load >>>>> constant. >>>>> >>>>> MacroAssembler::store_check_part_2() is different case which we may >>>>> prefer to use in other cases. Note, as_Address(ArrayAddress adr) >>>>> generates lea() instruction again. Which means code for 32-bit VM >>>>> in c1_Runtime1_x86.cpp generates 2 lea instructions and not one: >>>>> >>>>> __ leal(card_addr, __ as_Address(ArrayAddress(cardtable, index))); >>>>> >>>>> What I am saying is lets use mov instruction to load byte_map_base >>>>> instead of using ExternalAddress because we don't need relocation >>>>> for it and because in reality (with all past fixes) we will >>>>> generate the same number of instructions. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 11/19/13 7:59 AM, Albert Noll wrote: >>>>>> Hi Roland, >>>>>> >>>>>> thanks for pointing this out. Here is a patch that executes the >>>>>> assert >>>>>> only if >>>>>> the address we are checking is not byte_map_base. This might not >>>>>> be the >>>>>> most >>>>>> elegant solution, but at least it seems to work. >>>>>> >>>>>> Here is the new webrev: >>>>>> http://cr.openjdk.java.net/~anoll/8028109/webrev.01/ >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> >>>>>> On 11/19/2013 10:00 AM, Roland Westrelin wrote: >>>>>>>> Solution: Change 'ExternalAddress' to 'AddressLiteral' that >>>>>>>> generates >>>>>>>> no relocation information for >>>>>>>> byte_map_base. Other platforms also AddressLiteral >>>>>>>> without relocation information. >>>>>>> As mentioned in the thread here: >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005151.html >>>>>>> >>>>>>> >>>>>>> in this message: >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005161.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> not using ExternalAddress disables rip relative addressing. >>>>>>> This said, I?m not sure what a clean fix for this would be. >>>>>>> >>>>>>> Roland. > From albert.noll at oracle.com Wed Nov 27 11:09:44 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 27 Nov 2013 20:09:44 +0100 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: <52963895.4050004@oracle.com> References: <528B2347.7010902@oracle.com> <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> <528B8AF0.5050506@oracle.com> <528BBDC8.9010804@oracle.com> <528BC542.6090108@oracle.com> <7F9638CF-DA59-44E3-B4B8-0BE317ADC98F@oracle.com> <52961D46.8040201@oracle.com> <52963895.4050004@oracle.com> Message-ID: <664C71F6-CA28-4B4E-BA73-0785BF7EFA62@oracle.com> Thank you for the review, Vladimir. I also want to thank Roland who give me early feedback for this version. Best, Albert Von meinem iPhone gesendet > Am 27.11.2013 um 19:23 schrieb Vladimir Kozlov : > > Thank you, Albert, for additional comments. > > Fix looks good. > > Thanks, > Vladimir > >> On 11/27/13 8:26 AM, Albert Noll wrote: >> Igor, Vladimir, thanks for the reviews. >> >> Here is a version that uses 'mov' for 32-bit and 64-bit to load >> 'byte_map_base'. >> >> http://cr.openjdk.java.net/~anoll/8028109/webrev.02/ >> >> Best, >> Albert >> >>> On 11/19/2013 09:31 PM, Igor Veresov wrote: >>> Indeed, I agree, a move would be more straightforward. >>> Later on we?ll need a special type of relocation added for the >>> cardtable pointer anyway, because it has very unique rules to compute >>> it depending on both location of the heap and the cardtable array. It >>> is certainly not an ExternalAddress. >>> >>> igor >>> >>> On Nov 19, 2013, at 12:08 PM, Vladimir Kozlov >>> wrote: >>> >>>>> On 11/19/13 11:57 AM, Igor Veresov wrote: >>>>> Except we will need some relocation info for it if we plan to do >>>>> snapshotting. >>>> True, but after Tom's fix it does not have a relocation in all cases >>>> already: >>>> >>>> http://cr.openjdk.java.net/~never/6777083/src/cpu/x86/vm/assembler_x86.hpp.udiff.html >>>> >>>> >>>> And I think, there are places where we don't use ExternalAddress so >>>> we may need to solve serialization differently later. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> igor >>>>> >>>>> On Nov 19, 2013, at 11:36 AM, Vladimir Kozlov >>>>> wrote: >>>>> >>>>>> Last version is not good because it may hide bug when wrong address >>>>>> matches byte_map_base value. Original Tom's fix also hides problems. >>>>>> >>>>>> MacroAssembler::g1_write_barrier_post() and store_check_part_2() >>>>>> are used only in interpreter. It does not make sense to optimize >>>>>> it. Note, x86 has limited throughput for address calculations. And >>>>>> one instruction is only generated if this address is 32-bit which >>>>>> may be not true then you have to move it into register too. >>>>>> >>>>>> Anyway, we can go case by case and avoid ExternalAddress in 64-bit >>>>>> VM because code allows us to do that: >>>>>> >>>>>> In both cases in c1_Runtime1_x86.cpp and in >>>>>> MacroAssembler::g1_write_barrier_post() there is separate lea() >>>>>> instruction for LP64 which could be replaced with mov to load >>>>>> constant. >>>>>> >>>>>> MacroAssembler::store_check_part_2() is different case which we may >>>>>> prefer to use in other cases. Note, as_Address(ArrayAddress adr) >>>>>> generates lea() instruction again. Which means code for 32-bit VM >>>>>> in c1_Runtime1_x86.cpp generates 2 lea instructions and not one: >>>>>> >>>>>> __ leal(card_addr, __ as_Address(ArrayAddress(cardtable, index))); >>>>>> >>>>>> What I am saying is lets use mov instruction to load byte_map_base >>>>>> instead of using ExternalAddress because we don't need relocation >>>>>> for it and because in reality (with all past fixes) we will >>>>>> generate the same number of instructions. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>>> On 11/19/13 7:59 AM, Albert Noll wrote: >>>>>>> Hi Roland, >>>>>>> >>>>>>> thanks for pointing this out. Here is a patch that executes the >>>>>>> assert >>>>>>> only if >>>>>>> the address we are checking is not byte_map_base. This might not >>>>>>> be the >>>>>>> most >>>>>>> elegant solution, but at least it seems to work. >>>>>>> >>>>>>> Here is the new webrev: >>>>>>> http://cr.openjdk.java.net/~anoll/8028109/webrev.01/ >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> >>>>>>> On 11/19/2013 10:00 AM, Roland Westrelin wrote: >>>>>>>>> Solution: Change 'ExternalAddress' to 'AddressLiteral' that >>>>>>>>> generates >>>>>>>>> no relocation information for >>>>>>>>> byte_map_base. Other platforms also AddressLiteral >>>>>>>>> without relocation information. >>>>>>>> As mentioned in the thread here: >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005151.html >>>>>>>> >>>>>>>> >>>>>>>> in this message: >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005161.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> not using ExternalAddress disables rip relative addressing. >>>>>>>> This said, I?m not sure what a clean fix for this would be. >>>>>>>> >>>>>>>> Roland. >> From roland.westrelin at oracle.com Wed Nov 27 11:22:00 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 27 Nov 2013 20:22:00 +0100 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: <52961D46.8040201@oracle.com> References: <528B2347.7010902@oracle.com> <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> <528B8AF0.5050506@oracle.com> <528BBDC8.9010804@oracle.com> <528BC542.6090108@oracle.com> <7F9638CF-DA59-44E3-B4B8-0BE317ADC98F@oracle.com> <52961D46.8040201@oracle.com> Message-ID: <28260B7C-0240-4599-9D92-18AFB23C8D4A@oracle.com> > http://cr.openjdk.java.net/~anoll/8028109/webrev.02/ That looks good to me but I think you should drop the bug number from the comments. People interested can dig the bug number from the mercurial history. Roland. From albert.noll at oracle.com Wed Nov 27 13:47:45 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 27 Nov 2013 22:47:45 +0100 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: <28260B7C-0240-4599-9D92-18AFB23C8D4A@oracle.com> References: <528B2347.7010902@oracle.com> <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> <528B8AF0.5050506@oracle.com> <528BBDC8.9010804@oracle.com> <528BC542.6090108@oracle.com> <7F9638CF-DA59-44E3-B4B8-0BE317ADC98F@oracle.com> <52961D46.8040201@oracle.com> <28260B7C-0240-4599-9D92-18AFB23C8D4A@oracle.com> Message-ID: <52966881.7090506@oracle.com> Hi Roland, thanks for the review. I removed the bug id from the comments. Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8028109/webrev.03 Best, Albert On 11/27/2013 08:22 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~anoll/8028109/webrev.02/ > That looks good to me but I think you should drop the bug number from the comments. People interested can dig the bug number from the mercurial history. > > Roland. From roland.westrelin at oracle.com Wed Nov 27 13:50:34 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 27 Nov 2013 22:50:34 +0100 Subject: RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline In-Reply-To: <52966881.7090506@oracle.com> References: <528B2347.7010902@oracle.com> <92EE9CB6-0653-4531-9EE1-71F74EC9442B@oracle.com> <528B8AF0.5050506@oracle.com> <528BBDC8.9010804@oracle.com> <528BC542.6090108@oracle.com> <7F9638CF-DA59-44E3-B4B8-0BE317ADC98F@oracle.com> <52961D46.8040201@oracle.com> <28260B7C-0240-4599-9D92-18AFB23C8D4A@oracle.com> <52966881.7090506@oracle.com> Message-ID: <1C821774-124E-4875-9801-285862596082@oracle.com> > thanks for the review. I removed the bug id from the comments. Thanks. That looks good. Roland. From vladimir.kozlov at oracle.com Wed Nov 27 17:51:28 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Nov 2013 17:51:28 -0800 Subject: Preliminary review for 8028107: Kitchensink crashed with EAV Message-ID: <5296A1A0.2010908@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8028107 It is very rare case. Last time it was 1 year ago: https://bugs.openjdk.java.net/browse/JDK-7199505 nmethod unloading (nmethod::make_unloaded()) happens only during safepoint when it contains pointers (embedded or in oop map, relocation info) to dead java objects (see nmethod::can_unload()). It can only happens when a nmethod is NOT on call stack. GCs have path over nmethods on stack and they are treated as strong roots. Igor and I looked on GC code and verified it. I instrumented nmethod::make_unloaded() to see if we may unloading nmethods on stack and ran kitchensink for few day. No failures. The only place left is compiled inline caches. We DO clean up them at the end of safepoint if unloading happens: if (is_in_use()) { // Transitioning directly from live to unloaded -- so // we need to force a cache clean-up; remember this // for later on. CodeCache::set_needs_cache_clean(true); } But there is only place where we may create new compiledIC after safepoint when we are resolving call from compiled code: SharedRuntime::resolve_sub_helper(). In this method we record nmethod in local var: CompiledICInfo virtual_call_info; CompiledIC::compute_monomorphic_entry(callee_method, h_klass, is_optimized, static_bound, virtual_call_info, CHECK_(methodHandle())); then we take a lock (which is safepoint): // grab lock, check for deoptimization and potentially patch caller { MutexLocker ml_patch(CompiledIC_lock); and then create compiledIC based on info in CompiledICInfo: CompiledIC* inline_cache = CompiledIC_before(caller_nm, caller_frame.pc()); if (inline_cache->is_clean()) { inline_cache->set_to_monomorphic(virtual_call_info); } at this point nmethod could be unloaded already during above lock/safepoint. But call site is patched and will be used to call this nmethod. Note, we can't compute entry point under the same lock because: // Compute entry points. This might require generation of C2I converter // frames, so we cannot be holding any locks here. Furthermore, the // computation of the entry points is independent of patching the call. Please, comment or find any flaws in my logic. The bug is impossible to reproduce. I am suggesting next fix. src/share/vm/runtime/sharedRuntime.cpp @@ -1258,12 +1258,14 @@ // Now that we are ready to patch if the Method* was redefined then // don't update call site and let the caller retry. - - if (!callee_method->is_old()) { + // Don't update call site if nmethod was unloaded during safepoint + // which may happened during locking above. + if (!callee_method->is_old() && (callee_method->code() == callee_nm)) { #ifdef ASSERT // We must not try to patch to jump to an already unloaded method. if (dest_entry_point != 0) { - assert(CodeCache::find_blob(dest_entry_point) != NULL, + CodeBlob* cb = CodeCache::find_blob(dest_entry_point); + assert((cb != NULL) && cb->is_nmethod() && ((nmethod*)cb)->is_in_use(), "should not unload nmethod while locked"); } #endif Thanks, Vladimir From vladimir.kozlov at oracle.com Wed Nov 27 18:49:14 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Nov 2013 18:49:14 -0800 Subject: Preliminary review for 8028107: Kitchensink crashed with EAV In-Reply-To: <5296A1A0.2010908@oracle.com> References: <5296A1A0.2010908@oracle.com> Message-ID: <5296AF2A.8090806@oracle.com> Additional note. The code does "lock" nmethod (which is actually the field nm:_lock_count increment): nmethod* callee_nm = callee_method->code(); nmethodLocker nl_callee(callee_nm); but unloading code does not check it (is_locked_by_vm()) because it is too late anyway. John Rose suggested to modify nmethodLocker to put related metadata (method, klass) or JavaMirror into thread's handles area (or other reachable from GC place) so that such nmethods will be reachable during GC and be strong roots. It will prevent GC modify nmethod state when a java thread works with nmethod. Thanks, Vladimir On 11/27/13 5:51 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8028107 > > It is very rare case. Last time it was 1 year ago: > > https://bugs.openjdk.java.net/browse/JDK-7199505 > > nmethod unloading (nmethod::make_unloaded()) happens only during safepoint when it contains pointers (embedded or in oop > map, relocation info) to dead java objects (see nmethod::can_unload()). > > It can only happens when a nmethod is NOT on call stack. GCs have path over nmethods on stack and they are treated as > strong roots. Igor and I looked on GC code and verified it. > > I instrumented nmethod::make_unloaded() to see if we may unloading nmethods on stack and ran kitchensink for few day. No > failures. > > The only place left is compiled inline caches. We DO clean up them at the end of safepoint if unloading happens: > > if (is_in_use()) { > // Transitioning directly from live to unloaded -- so > // we need to force a cache clean-up; remember this > // for later on. > CodeCache::set_needs_cache_clean(true); > } > > But there is only place where we may create new compiledIC after safepoint when we are resolving call from compiled > code: SharedRuntime::resolve_sub_helper(). > > In this method we record nmethod in local var: > > CompiledICInfo virtual_call_info; > > CompiledIC::compute_monomorphic_entry(callee_method, h_klass, > is_optimized, static_bound, virtual_call_info, > CHECK_(methodHandle())); > > then we take a lock (which is safepoint): > > // grab lock, check for deoptimization and potentially patch caller > { > MutexLocker ml_patch(CompiledIC_lock); > > and then create compiledIC based on info in CompiledICInfo: > > CompiledIC* inline_cache = CompiledIC_before(caller_nm, caller_frame.pc()); > if (inline_cache->is_clean()) { > inline_cache->set_to_monomorphic(virtual_call_info); > } > > at this point nmethod could be unloaded already during above lock/safepoint. But call site is patched and will be used > to call this nmethod. > > Note, we can't compute entry point under the same lock because: > > // Compute entry points. This might require generation of C2I converter > // frames, so we cannot be holding any locks here. Furthermore, the > // computation of the entry points is independent of patching the call. > > > Please, comment or find any flaws in my logic. The bug is impossible to reproduce. > > I am suggesting next fix. > > src/share/vm/runtime/sharedRuntime.cpp > @@ -1258,12 +1258,14 @@ > > // Now that we are ready to patch if the Method* was redefined then > // don't update call site and let the caller retry. > - > - if (!callee_method->is_old()) { > + // Don't update call site if nmethod was unloaded during safepoint > + // which may happened during locking above. > + if (!callee_method->is_old() && (callee_method->code() == callee_nm)) { > #ifdef ASSERT > // We must not try to patch to jump to an already unloaded method. > if (dest_entry_point != 0) { > - assert(CodeCache::find_blob(dest_entry_point) != NULL, > + CodeBlob* cb = CodeCache::find_blob(dest_entry_point); > + assert((cb != NULL) && cb->is_nmethod() && ((nmethod*)cb)->is_in_use(), > "should not unload nmethod while locked"); > } > #endif > > > Thanks, > Vladimir From rickard.backman at oracle.com Thu Nov 28 00:58:35 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Thu, 28 Nov 2013 09:58:35 +0100 Subject: RFR(XS): 8028997: mathexact intrinsics are unstabl In-Reply-To: <52938D8C.2060501@oracle.com> References: <20131122133104.GB19422@rbackman> <528F5EBB.6080101@oracle.com> <528F8E1D.9070606@oracle.com> <20131125085452.GA29591@rbackman> <529320CF.7000709@oracle.com> <52938D8C.2060501@oracle.com> Message-ID: <20131128085835.GF29591@rbackman> Updated again: http://cr.openjdk.java.net/~rbackman/8028997.2/ Thanks /R On 11/25, Vladimir Kozlov wrote: > On 11/25/13 2:05 AM, Igor Ignatyev wrote: > >Rickard, > > > >You should also add -XX:+IgnoreUnrecognizedVMOptions, because UseMathExactIntrinsics is a c2_only flag. > > Yes. > > Thanks, > Vladimir > > > > >On 11/25/2013 12:54 PM, Rickard B?ckman wrote: > >>Updated with flags for tests. > >> > >>Webrev: http://cr.openjdk.java.net/~rbackman/8028997.1/ > >> > >>Thanks > >>/R > >> > >>On 11/22, Vladimir Kozlov wrote: > >>>On 11/22/13 5:40 AM, Leonid Mesnik wrote: > >>>>Rickard > >>>> > >>>>Does it make a sense to update corresponding tests by switching UseMathExactIntrinsics on explicitly? > >>> > >>>Yes, it should be done in these changes. > >>> > >>>Thanks, > >>>Vladimir > >>> > >>>> > >>>>Leonid > >>>>On 11/22/2013 05:31 PM, Rickard B?ckman wrote: > >>>>>Hi all, > >>>>> > >>>>>can I have a couple of reviews for this small change? > >>>>>It basically sets the default value of UseMathExactIntrinsics to false > >>>>>and moves it to be an experimental vm option. > >>>>> > >>>>>Webrev: http://cr.openjdk.java.net/~rbackman/8028997/ > >>>>>Bug: https://bugs.openjdk.java.net/browse/JDK-8028997 > >>>>> > >>>>>Thanks > >>>>>/R > >>>> > >>>> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131128/ce57cec7/attachment.bin From mikael.gerdin at oracle.com Thu Nov 28 01:39:32 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 28 Nov 2013 10:39:32 +0100 Subject: Preliminary review for 8028107: Kitchensink crashed with EAV In-Reply-To: <5296AF2A.8090806@oracle.com> References: <5296A1A0.2010908@oracle.com> <5296AF2A.8090806@oracle.com> Message-ID: <14914221.uuAyT6pDiS@mgerdin03> Vladimir, On Wednesday 27 November 2013 18.49.14 Vladimir Kozlov wrote: > Additional note. The code does "lock" nmethod (which is actually the field > nm:_lock_count increment): > > nmethod* callee_nm = callee_method->code(); > nmethodLocker nl_callee(callee_nm); > > but unloading code does not check it (is_locked_by_vm()) because it is too > late anyway. > > John Rose suggested to modify nmethodLocker to put related metadata (method, > klass) or JavaMirror into thread's handles area (or other reachable from GC > place) so that such nmethods will be reachable during GC and be strong > roots. It will prevent GC modify nmethod state when a java thread works > with nmethod. I read through your original explanation below and from a GC perspective your explanation seems plausible. I don't really know how compiledICs work, but it is possible that an nmethod can be unloaded at a safepoint if any of the objects it references are not live. I've had problems with this when working on class unloading for G1 previously. I don't think it would be enough to create handles for the nmethod's metadata since the GC does not actually follow any pointers to find nmethods. As far as I understand from the sources nmethod unloading is _forced_ if any java object which is embedded in an nmethod is dead. If you want to make sure that the nmethod is not unloaded then you would need to register your nmethod to a global list and change all the gc code to call oops_do on the nmethods on this list with the correct closures, basically some sort of nmethod handle stack. I'd prefer to avoid this approach since it will add more complexity to GC root scanning and would further complicate class unloading for G1. I would also like to add that since this nmethod is the only referent of the java object that caused the unloading it is highly likely that it will be unloaded at the next full gc unless it's on a thread stack. Keeping the nmethod alive here seems to only delay the inevitable. /Mikael > > Thanks, > Vladimir > > On 11/27/13 5:51 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8028107 > > > > It is very rare case. Last time it was 1 year ago: > > > > https://bugs.openjdk.java.net/browse/JDK-7199505 > > > > nmethod unloading (nmethod::make_unloaded()) happens only during safepoint > > when it contains pointers (embedded or in oop map, relocation info) to > > dead java objects (see nmethod::can_unload()). > > > > It can only happens when a nmethod is NOT on call stack. GCs have path > > over nmethods on stack and they are treated as strong roots. Igor and I > > looked on GC code and verified it. > > > > I instrumented nmethod::make_unloaded() to see if we may unloading > > nmethods on stack and ran kitchensink for few day. No failures. > > > > The only place left is compiled inline caches. We DO clean up them at the end of safepoint if unloading happens: > > if (is_in_use()) { > > > > // Transitioning directly from live to unloaded -- so > > // we need to force a cache clean-up; remember this > > // for later on. > > CodeCache::set_needs_cache_clean(true); > > > > } > > > > But there is only place where we may create new compiledIC after safepoint > > when we are resolving call from compiled code: > > SharedRuntime::resolve_sub_helper(). > > > > In this method we record nmethod in local var: > > CompiledICInfo virtual_call_info; > > > > CompiledIC::compute_monomorphic_entry(callee_method, h_klass, > > > > is_optimized, static_bound, virtual_call_info, > > CHECK_(methodHandle())); > > > > then we take a lock (which is safepoint): > > // grab lock, check for deoptimization and potentially patch caller > > { > > > > MutexLocker ml_patch(CompiledIC_lock); > > > > and then create compiledIC based on info in CompiledICInfo: > > CompiledIC* inline_cache = CompiledIC_before(caller_nm, > > caller_frame.pc()); > > if (inline_cache->is_clean()) { > > > > inline_cache->set_to_monomorphic(virtual_call_info); > > > > } > > > > at this point nmethod could be unloaded already during above > > lock/safepoint. But call site is patched and will be used to call this > > nmethod. > > > > Note, we can't compute entry point under the same lock because: > > // Compute entry points. This might require generation of C2I converter > > // frames, so we cannot be holding any locks here. Furthermore, the > > // computation of the entry points is independent of patching the call. > > > > Please, comment or find any flaws in my logic. The bug is impossible to > > reproduce. > > > > I am suggesting next fix. > > > > src/share/vm/runtime/sharedRuntime.cpp > > @@ -1258,12 +1258,14 @@ > > > > // Now that we are ready to patch if the Method* was redefined then > > // don't update call site and let the caller retry. > > > > - > > - if (!callee_method->is_old()) { > > + // Don't update call site if nmethod was unloaded during safepoint > > + // which may happened during locking above. > > + if (!callee_method->is_old() && (callee_method->code() == callee_nm)) > > {> > > #ifdef ASSERT > > > > // We must not try to patch to jump to an already unloaded method. > > if (dest_entry_point != 0) { > > > > - assert(CodeCache::find_blob(dest_entry_point) != NULL, > > + CodeBlob* cb = CodeCache::find_blob(dest_entry_point); > > + assert((cb != NULL) && cb->is_nmethod() && > > ((nmethod*)cb)->is_in_use(),> > > "should not unload nmethod while locked"); > > > > } > > > > #endif > > > > Thanks, > > Vladimir From markus.gronlund at oracle.com Thu Nov 28 02:42:53 2013 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 28 Nov 2013 02:42:53 -0800 (PST) Subject: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40 In-Reply-To: <52963406.1050200@oracle.com> References: <3ee2cce7-8c32-448f-b1c0-252df5996516@default> <52963406.1050200@oracle.com> Message-ID: Hi Vladimir, Thanks for taking a look. I have updated the bug with a link to 8005849, thanks. "Is it possible to prepare a jtreg test which will use AsynchGetCallTrace and catch such situations in a future?" I agree that having a way to check for regression here would be ideal. I also realize that creating reliable regression tests for this part of the code is a non-trivial undertaking. For example, the code showing this particular regression needs to be a call tree with intertwined Java/JNI/native code. For one, a regression test for AsyncGetCallTrace needs, besides logic for AsyncGetCallTrace thread suspension itself, also involve a target using native code, and this means compiling native code etc etc.... I will create a separate bug/enhancement to track investigation efforts as to what kind of regression tests can be done here (maybe the native parts can be done in the VM itself and then using RegisterNatives() to hook up a test case...hmm...) Thanks again for reviewing /Markus -----Original Message----- From: Vladimir Kozlov Sent: den 27 november 2013 19:04 To: Markus Gronlund; hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; serviceability-dev Subject: Re: RFR(S): 8028412 - AsyncGetCallTrace() is broken on x86 in JDK7u40 Hi, Markus I think the bug report should link to 8005849 which introduced this additional check and regression. Is it possible to prepare a jtreg test which will use AsynchGetCallTrace and catch such situations in a future? The fix itself looks good. Thanks, Vladimir On 11/27/13 1:47 AM, Markus Gronlund wrote: > Greetings, > > Kindly asking for reviews for the following change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028412 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8028412/webrev01/ > > Description: > > AsynchGetCallTrace() uses platform specific code for stack frame traversals. > > On x86, there currently exist a defensive construct that practically > disallows stack traversal over entry_frame code stubs, such as > StubRoutine(1) frames: > > src/cpu/x86/vm/frame_x86.cpp b/src/cpu/x86/vm/frame_x86.cpp: > > bool frame::safe_for_sender(JavaThread* thread) { > > . > > if (!Interpreter::contains(_pc) && _cb->frame_size() <= 0) { > //assert(0, "Invalid frame_size"); > > return false; > } > > . > > Since entry frames (such as StubRoutine(1)) have a frame size of 0, > the code returns prematurely. > > Fix is to move this frame size check post handling of is_entry_frame(), > where the code_stubs are processed. > > Testing completed: > > Sun Studio Profiler reproducer testcase > > SpecJBB2005 > > Kitchensink > > Thanks > Markus > From vladimir.kozlov at oracle.com Thu Nov 28 09:26:21 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Nov 2013 09:26:21 -0800 Subject: RFR(XS): 8028997: mathexact intrinsics are unstabl In-Reply-To: <20131128085835.GF29591@rbackman> References: <20131122133104.GB19422@rbackman> <528F5EBB.6080101@oracle.com> <528F8E1D.9070606@oracle.com> <20131125085452.GA29591@rbackman> <529320CF.7000709@oracle.com> <52938D8C.2060501@oracle.com> <20131128085835.GF29591@rbackman> Message-ID: <52977CBD.1000605@oracle.com> Good. Thanks, Vladimir On 11/28/13 12:58 AM, Rickard B?ckman wrote: > Updated again: http://cr.openjdk.java.net/~rbackman/8028997.2/ > > Thanks > /R > > On 11/25, Vladimir Kozlov wrote: >> On 11/25/13 2:05 AM, Igor Ignatyev wrote: >>> Rickard, >>> >>> You should also add -XX:+IgnoreUnrecognizedVMOptions, because UseMathExactIntrinsics is a c2_only flag. >> >> Yes. >> >> Thanks, >> Vladimir >> >>> >>> On 11/25/2013 12:54 PM, Rickard B?ckman wrote: >>>> Updated with flags for tests. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rbackman/8028997.1/ >>>> >>>> Thanks >>>> /R >>>> >>>> On 11/22, Vladimir Kozlov wrote: >>>>> On 11/22/13 5:40 AM, Leonid Mesnik wrote: >>>>>> Rickard >>>>>> >>>>>> Does it make a sense to update corresponding tests by switching UseMathExactIntrinsics on explicitly? >>>>> >>>>> Yes, it should be done in these changes. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Leonid >>>>>> On 11/22/2013 05:31 PM, Rickard B?ckman wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> can I have a couple of reviews for this small change? >>>>>>> It basically sets the default value of UseMathExactIntrinsics to false >>>>>>> and moves it to be an experimental vm option. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8028997/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028997 >>>>>>> >>>>>>> Thanks >>>>>>> /R >>>>>> >>>>>> From john.coomes at oracle.com Thu Nov 28 10:47:03 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:47:03 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b118 for changeset 76a598cf50c4 Message-ID: <20131128184708.BAA9C62908@hg.openjdk.java.net> Changeset: 7ac7d1afd966 Author: cl Date: 2013-11-28 08:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/7ac7d1afd966 Added tag jdk8-b118 for changeset 76a598cf50c4 ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:46:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:46:38 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b118 for changeset d6820a414f18 Message-ID: <20131128184640.93A3762906@hg.openjdk.java.net> Changeset: 5029f982dfae Author: cl Date: 2013-11-28 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/5029f982dfae Added tag jdk8-b118 for changeset d6820a414f18 ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:46:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:46:32 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b118 for changeset 0a6db1aac998 Message-ID: <20131128184632.BAACE62905@hg.openjdk.java.net> Changeset: 06d512d44c31 Author: cl Date: 2013-11-28 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/06d512d44c31 Added tag jdk8-b118 for changeset 0a6db1aac998 ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:46:47 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:46:47 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b118 for changeset e4e5069250e7 Message-ID: <20131128184654.45A1C62907@hg.openjdk.java.net> Changeset: 6b37ae056340 Author: cl Date: 2013-11-28 08:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/6b37ae056340 Added tag jdk8-b118 for changeset e4e5069250e7 ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:47:24 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:47:24 +0000 Subject: hg: hsx/hotspot-comp/jdk: 4 new changesets Message-ID: <20131128184900.27CA262909@hg.openjdk.java.net> Changeset: 6c1f5c7baab0 Author: ksrini Date: 2013-11-21 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jdk/rev/28ca338366ff Merge Changeset: a1c49f8881ae Author: cl Date: 2013-11-28 08:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a1c49f8881ae Added tag jdk8-b118 for changeset 28ca338366ff ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:50:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:50:34 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b118 for changeset 4fd6a7ff8c06 Message-ID: <20131128185047.779576290A@hg.openjdk.java.net> Changeset: 1f6ffcd56363 Author: cl Date: 2013-11-28 08:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1f6ffcd56363 Added tag jdk8-b118 for changeset 4fd6a7ff8c06 ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:51:07 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:51:07 +0000 Subject: hg: hsx/hotspot-comp/nashorn: Added tag jdk8-b118 for changeset 8d014b039b44 Message-ID: <20131128185111.138936290B@hg.openjdk.java.net> Changeset: b55a011cf8ae Author: cl Date: 2013-11-28 08:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/b55a011cf8ae Added tag jdk8-b118 for changeset 8d014b039b44 ! .hgtags From vladimir.kozlov at oracle.com Thu Nov 28 14:55:56 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Nov 2013 14:55:56 -0800 Subject: Preliminary review for 8028107: Kitchensink crashed with EAV In-Reply-To: <14914221.uuAyT6pDiS@mgerdin03> References: <5296A1A0.2010908@oracle.com> <5296AF2A.8090806@oracle.com> <14914221.uuAyT6pDiS@mgerdin03> Message-ID: <5297C9FC.6060405@oracle.com> Thank you, Mikael It simplifies my work. I will concentrate on safely bailout from situation when nmethod is unloaded. We need to call c2i adapter instead which should be present at that time. Regards, Vladimir On 11/28/13 1:39 AM, Mikael Gerdin wrote: > Vladimir, > > On Wednesday 27 November 2013 18.49.14 Vladimir Kozlov wrote: >> Additional note. The code does "lock" nmethod (which is actually the field >> nm:_lock_count increment): >> >> nmethod* callee_nm = callee_method->code(); >> nmethodLocker nl_callee(callee_nm); >> >> but unloading code does not check it (is_locked_by_vm()) because it is too >> late anyway. >> >> John Rose suggested to modify nmethodLocker to put related metadata (method, >> klass) or JavaMirror into thread's handles area (or other reachable from GC >> place) so that such nmethods will be reachable during GC and be strong >> roots. It will prevent GC modify nmethod state when a java thread works >> with nmethod. > > I read through your original explanation below and from a GC perspective your > explanation seems plausible. I don't really know how compiledICs work, but it > is possible that an nmethod can be unloaded at a safepoint if any of the > objects it references are not live. I've had problems with this when working > on class unloading for G1 previously. > > I don't think it would be enough to create handles for the nmethod's metadata > since the GC does not actually follow any pointers to find nmethods. > As far as I understand from the sources nmethod unloading is _forced_ if any > java object which is embedded in an nmethod is dead. > If you want to make sure that the nmethod is not unloaded then you would need > to register your nmethod to a global list and change all the gc code to call > oops_do on the nmethods on this list with the correct closures, basically some > sort of nmethod handle stack. I'd prefer to avoid this approach since it will > add more complexity to GC root scanning and would further complicate class > unloading for G1. > > I would also like to add that since this nmethod is the only referent of the > java object that caused the unloading it is highly likely that it will be > unloaded at the next full gc unless it's on a thread stack. Keeping the > nmethod alive here seems to only delay the inevitable. > > /Mikael > >> >> Thanks, >> Vladimir >> >> On 11/27/13 5:51 PM, Vladimir Kozlov wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8028107 >>> >>> It is very rare case. Last time it was 1 year ago: >>> >>> https://bugs.openjdk.java.net/browse/JDK-7199505 >>> >>> nmethod unloading (nmethod::make_unloaded()) happens only during safepoint >>> when it contains pointers (embedded or in oop map, relocation info) to >>> dead java objects (see nmethod::can_unload()). >>> >>> It can only happens when a nmethod is NOT on call stack. GCs have path >>> over nmethods on stack and they are treated as strong roots. Igor and I >>> looked on GC code and verified it. >>> >>> I instrumented nmethod::make_unloaded() to see if we may unloading >>> nmethods on stack and ran kitchensink for few day. No failures. >>> >>> The only place left is compiled inline caches. We DO clean up them at the > end of safepoint if unloading happens: >>> if (is_in_use()) { >>> >>> // Transitioning directly from live to unloaded -- so >>> // we need to force a cache clean-up; remember this >>> // for later on. >>> CodeCache::set_needs_cache_clean(true); >>> >>> } >>> >>> But there is only place where we may create new compiledIC after safepoint >>> when we are resolving call from compiled code: >>> SharedRuntime::resolve_sub_helper(). >>> >>> In this method we record nmethod in local var: >>> CompiledICInfo virtual_call_info; >>> >>> CompiledIC::compute_monomorphic_entry(callee_method, h_klass, >>> >>> is_optimized, static_bound, virtual_call_info, >>> CHECK_(methodHandle())); >>> >>> then we take a lock (which is safepoint): >>> // grab lock, check for deoptimization and potentially patch caller >>> { >>> >>> MutexLocker ml_patch(CompiledIC_lock); >>> >>> and then create compiledIC based on info in CompiledICInfo: >>> CompiledIC* inline_cache = CompiledIC_before(caller_nm, >>> caller_frame.pc()); >>> if (inline_cache->is_clean()) { >>> >>> inline_cache->set_to_monomorphic(virtual_call_info); >>> >>> } >>> >>> at this point nmethod could be unloaded already during above >>> lock/safepoint. But call site is patched and will be used to call this >>> nmethod. >>> >>> Note, we can't compute entry point under the same lock because: >>> // Compute entry points. This might require generation of C2I converter >>> // frames, so we cannot be holding any locks here. Furthermore, the >>> // computation of the entry points is independent of patching the call. >>> >>> Please, comment or find any flaws in my logic. The bug is impossible to >>> reproduce. >>> >>> I am suggesting next fix. >>> >>> src/share/vm/runtime/sharedRuntime.cpp >>> @@ -1258,12 +1258,14 @@ >>> >>> // Now that we are ready to patch if the Method* was redefined then >>> // don't update call site and let the caller retry. >>> >>> - >>> - if (!callee_method->is_old()) { >>> + // Don't update call site if nmethod was unloaded during safepoint >>> + // which may happened during locking above. >>> + if (!callee_method->is_old() && (callee_method->code() == callee_nm)) >>> {> >>> #ifdef ASSERT >>> >>> // We must not try to patch to jump to an already unloaded method. >>> if (dest_entry_point != 0) { >>> >>> - assert(CodeCache::find_blob(dest_entry_point) != NULL, >>> + CodeBlob* cb = CodeCache::find_blob(dest_entry_point); >>> + assert((cb != NULL) && cb->is_nmethod() && >>> ((nmethod*)cb)->is_in_use(),> >>> "should not unload nmethod while locked"); >>> >>> } >>> >>> #endif >>> >>> Thanks, >>> Vladimir > From igor.veresov at oracle.com Thu Nov 28 17:45:29 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 28 Nov 2013 17:45:29 -0800 Subject: Preliminary review for 8028107: Kitchensink crashed with EAV In-Reply-To: <5296A1A0.2010908@oracle.com> References: <5296A1A0.2010908@oracle.com> Message-ID: Cool! Wow, that?s a very nice find. I wonder if that the only place this happens? igor On Nov 27, 2013, at 5:51 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8028107 > > It is very rare case. Last time it was 1 year ago: > > https://bugs.openjdk.java.net/browse/JDK-7199505 > > nmethod unloading (nmethod::make_unloaded()) happens only during safepoint when it contains pointers (embedded or in oop map, relocation info) to dead java objects (see nmethod::can_unload()). > > It can only happens when a nmethod is NOT on call stack. GCs have path over nmethods on stack and they are treated as strong roots. Igor and I looked on GC code and verified it. > > I instrumented nmethod::make_unloaded() to see if we may unloading nmethods on stack and ran kitchensink for few day. No failures. > > The only place left is compiled inline caches. We DO clean up them at the end of safepoint if unloading happens: > > if (is_in_use()) { > // Transitioning directly from live to unloaded -- so > // we need to force a cache clean-up; remember this > // for later on. > CodeCache::set_needs_cache_clean(true); > } > > But there is only place where we may create new compiledIC after safepoint when we are resolving call from compiled code: SharedRuntime::resolve_sub_helper(). > > In this method we record nmethod in local var: > > CompiledICInfo virtual_call_info; > > CompiledIC::compute_monomorphic_entry(callee_method, h_klass, > is_optimized, static_bound, virtual_call_info, > CHECK_(methodHandle())); > > then we take a lock (which is safepoint): > > // grab lock, check for deoptimization and potentially patch caller > { > MutexLocker ml_patch(CompiledIC_lock); > > and then create compiledIC based on info in CompiledICInfo: > > CompiledIC* inline_cache = CompiledIC_before(caller_nm, caller_frame.pc()); > if (inline_cache->is_clean()) { > inline_cache->set_to_monomorphic(virtual_call_info); > } > > at this point nmethod could be unloaded already during above lock/safepoint. But call site is patched and will be used to call this nmethod. > > Note, we can't compute entry point under the same lock because: > > // Compute entry points. This might require generation of C2I converter > // frames, so we cannot be holding any locks here. Furthermore, the > // computation of the entry points is independent of patching the call. > > > Please, comment or find any flaws in my logic. The bug is impossible to reproduce. > > I am suggesting next fix. > > src/share/vm/runtime/sharedRuntime.cpp > @@ -1258,12 +1258,14 @@ > > // Now that we are ready to patch if the Method* was redefined then > // don't update call site and let the caller retry. > - > - if (!callee_method->is_old()) { > + // Don't update call site if nmethod was unloaded during safepoint > + // which may happened during locking above. > + if (!callee_method->is_old() && (callee_method->code() == callee_nm)) { > #ifdef ASSERT > // We must not try to patch to jump to an already unloaded method. > if (dest_entry_point != 0) { > - assert(CodeCache::find_blob(dest_entry_point) != NULL, > + CodeBlob* cb = CodeCache::find_blob(dest_entry_point); > + assert((cb != NULL) && cb->is_nmethod() && ((nmethod*)cb)->is_in_use(), > "should not unload nmethod while locked"); > } > #endif > > > Thanks, > Vladimir From rickard.backman at oracle.com Fri Nov 29 06:21:38 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 29 Nov 2013 15:21:38 +0100 Subject: RFR(XS): 8028997: mathexact intrinsics are unstabl In-Reply-To: <52977CBD.1000605@oracle.com> References: <20131122133104.GB19422@rbackman> <528F5EBB.6080101@oracle.com> <528F8E1D.9070606@oracle.com> <20131125085452.GA29591@rbackman> <529320CF.7000709@oracle.com> <52938D8C.2060501@oracle.com> <20131128085835.GF29591@rbackman> <52977CBD.1000605@oracle.com> Message-ID: <20131129142138.GG29591@rbackman> Vladimir, thanks. Still need one more Reviewer. Thanks /R On 11/28, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 11/28/13 12:58 AM, Rickard B?ckman wrote: > >Updated again: http://cr.openjdk.java.net/~rbackman/8028997.2/ > > > >Thanks > >/R > > > >On 11/25, Vladimir Kozlov wrote: > >>On 11/25/13 2:05 AM, Igor Ignatyev wrote: > >>>Rickard, > >>> > >>>You should also add -XX:+IgnoreUnrecognizedVMOptions, because UseMathExactIntrinsics is a c2_only flag. > >> > >>Yes. > >> > >>Thanks, > >>Vladimir > >> > >>> > >>>On 11/25/2013 12:54 PM, Rickard B?ckman wrote: > >>>>Updated with flags for tests. > >>>> > >>>>Webrev: http://cr.openjdk.java.net/~rbackman/8028997.1/ > >>>> > >>>>Thanks > >>>>/R > >>>> > >>>>On 11/22, Vladimir Kozlov wrote: > >>>>>On 11/22/13 5:40 AM, Leonid Mesnik wrote: > >>>>>>Rickard > >>>>>> > >>>>>>Does it make a sense to update corresponding tests by switching UseMathExactIntrinsics on explicitly? > >>>>> > >>>>>Yes, it should be done in these changes. > >>>>> > >>>>>Thanks, > >>>>>Vladimir > >>>>> > >>>>>> > >>>>>>Leonid > >>>>>>On 11/22/2013 05:31 PM, Rickard B?ckman wrote: > >>>>>>>Hi all, > >>>>>>> > >>>>>>>can I have a couple of reviews for this small change? > >>>>>>>It basically sets the default value of UseMathExactIntrinsics to false > >>>>>>>and moves it to be an experimental vm option. > >>>>>>> > >>>>>>>Webrev: http://cr.openjdk.java.net/~rbackman/8028997/ > >>>>>>>Bug: https://bugs.openjdk.java.net/browse/JDK-8028997 > >>>>>>> > >>>>>>>Thanks > >>>>>>>/R > >>>>>> > >>>>>> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131129/5a26435b/attachment.bin From rickard.backman at oracle.com Fri Nov 29 06:22:50 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 29 Nov 2013 15:22:50 +0100 Subject: RFR(XS): 8028624: [TESTBUG] compiler/intrinsics/mathexact/DecExactLTest executes DecExactITest In-Reply-To: <1E67325C-3969-4765-AA6B-6E6EB3045108@oracle.com> References: <20131122143003.GD19422@rbackman> <1E67325C-3969-4765-AA6B-6E6EB3045108@oracle.com> Message-ID: <20131129142250.GH29591@rbackman> Christian, yes that would have avoided the problem. Now we'll need to add some flags so it isn't going away. I guess you are ok with the change? Thanks /R On 11/22, Christian Thalinger wrote: > If you?re running your test with no arguments and in the same vm you can also omit the @run line: > > + * @run main DecExactLTest > > It might have helped you finding the bug in the first place. > > On Nov 22, 2013, at 6:30 AM, Rickard B?ckman wrote: > > > Hi all, > > > > can I please have this small change reviewed? > > The tags in the test are wrong, it should say DecExactLTest where it > > said DecExactITest. > > > > Webrev: http://cr.openjdk.java.net/~rbackman/8028624/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028624 > > > > Thanks > > /R > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131129/38af9520/attachment.bin From alejandro.murillo at oracle.com Fri Nov 29 16:24:45 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 30 Nov 2013 00:24:45 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 10 new changesets Message-ID: <20131130002509.E297462944@hg.openjdk.java.net> Changeset: e6dfcdf37ef2 Author: cl Date: 2013-11-28 08:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e6dfcdf37ef2 Added tag jdk8-b118 for changeset c9f439732b18 ! .hgtags Changeset: 19146c82b6fc Author: hseigel Date: 2013-11-21 14:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/hotspot/rev/260ac69dc096 Merge Changeset: 86e6d691f2e1 Author: mgronlun Date: 2013-11-23 12:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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: 2315fab779ca Author: drchase Date: 2013-11-29 11:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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/hotspot-comp/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-comp/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-comp/hotspot/rev/b6b9a5d4cda0 8029367: new hotspot build - hs25-b62 Reviewed-by: jcoomes ! make/hotspot_version From igor.veresov at oracle.com Fri Nov 29 17:07:23 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 29 Nov 2013 17:07:23 -0800 Subject: RFR(XS): 8028997: mathexact intrinsics are unstabl In-Reply-To: <20131129142138.GG29591@rbackman> References: <20131122133104.GB19422@rbackman> <528F5EBB.6080101@oracle.com> <528F8E1D.9070606@oracle.com> <20131125085452.GA29591@rbackman> <529320CF.7000709@oracle.com> <52938D8C.2060501@oracle.com> <20131128085835.GF29591@rbackman> <52977CBD.1000605@oracle.com> <20131129142138.GG29591@rbackman> Message-ID: <97303475-3C0F-4564-BFCB-B120DF4FEF0D@oracle.com> Looks good. igor On Nov 29, 2013, at 6:21 AM, Rickard B?ckman wrote: > Vladimir, thanks. > > Still need one more Reviewer. > > Thanks > /R > > On 11/28, Vladimir Kozlov wrote: >> Good. >> >> Thanks, >> Vladimir >> >> On 11/28/13 12:58 AM, Rickard B?ckman wrote: >>> Updated again: http://cr.openjdk.java.net/~rbackman/8028997.2/ >>> >>> Thanks >>> /R >>> >>> On 11/25, Vladimir Kozlov wrote: >>>> On 11/25/13 2:05 AM, Igor Ignatyev wrote: >>>>> Rickard, >>>>> >>>>> You should also add -XX:+IgnoreUnrecognizedVMOptions, because UseMathExactIntrinsics is a c2_only flag. >>>> >>>> Yes. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> On 11/25/2013 12:54 PM, Rickard B?ckman wrote: >>>>>> Updated with flags for tests. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8028997.1/ >>>>>> >>>>>> Thanks >>>>>> /R >>>>>> >>>>>> On 11/22, Vladimir Kozlov wrote: >>>>>>> On 11/22/13 5:40 AM, Leonid Mesnik wrote: >>>>>>>> Rickard >>>>>>>> >>>>>>>> Does it make a sense to update corresponding tests by switching UseMathExactIntrinsics on explicitly? >>>>>>> >>>>>>> Yes, it should be done in these changes. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Leonid >>>>>>>> On 11/22/2013 05:31 PM, Rickard B?ckman wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> can I have a couple of reviews for this small change? >>>>>>>>> It basically sets the default value of UseMathExactIntrinsics to false >>>>>>>>> and moves it to be an experimental vm option. >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8028997/ >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028997 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> /R >>>>>>>> >>>>>>>> From john.coomes at oracle.com Fri Nov 1 15:47:25 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 22:47:25 -0000 Subject: hg: hsx/hotspot-comp/jdk: 309 new changesets Message-ID: <20131101224529.4AABD62908@hg.openjdk.java.net> Changeset: 8a041011b6e6 Author: jgodinez Date: 2013-09-27 13:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/727b60f9c09c Merge Changeset: e4e151f6ae50 Author: yan Date: 2013-09-27 12:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/0b535e920dd5 Merge Changeset: 15955d335cd0 Author: jfranck Date: 2013-09-30 11:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/98d98ec01f07 Merge Changeset: 9c60860b1812 Author: ihse Date: 2013-10-10 15:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/1863a7e3a1c9 Merge Changeset: 1a067bc31098 Author: lana Date: 2013-10-10 21:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1a067bc31098 Merge Changeset: 4ad76262bac8 Author: mullan Date: 2013-10-11 08:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/94493b5800bb Merge Changeset: 9632de07d963 Author: alanb Date: 2013-10-11 20:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/3a5c987ff3a0 Merge Changeset: dd0deeb04933 Author: michaelm Date: 2013-10-14 22:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/eb29deb3c1db Merge Changeset: 0a06ec55aacd Author: bae Date: 2013-07-01 15:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/3062c96e79e0 Merge Changeset: e1497f102a8a Author: malenkov Date: 2013-07-16 21:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/0a51ccf778b3 Merge Changeset: 3725e8a70ae9 Author: mchung Date: 2013-07-22 19:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/446bc20447a1 Merge Changeset: e537b7f5f39b Author: naoto Date: 2013-08-01 14:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jdk/rev/44a063555ccd Merge Changeset: 17e1675e3d1e Author: serb Date: 2013-08-04 02:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/ad35b4b6ce8e Merge Changeset: 29f73bc50bd4 Author: chegar Date: 2013-08-30 09:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jdk/rev/22ea25e71b4c Merge Changeset: 240072825ada Author: chegar Date: 2013-10-03 19:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/78ffa90c77b2 Merge Changeset: 3676f04e6553 Author: bpb Date: 2013-10-15 16:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/e078fd8a78f6 Merge Changeset: d8eec0e3a023 Author: robm Date: 2013-10-16 15:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/85a73ad28c53 Merge Changeset: 456a9b199208 Author: rriggs Date: 2013-10-17 13:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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: 01b81253f2d5 Author: dcubed Date: 2013-10-15 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/01b81253f2d5 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/common/Defs-macosx.gmk ! make/common/Defs.gmk ! make/java/redist/Makefile ! makefiles/Import.gmk ! makefiles/Tools.gmk Changeset: 969e8c6c26cc Author: amurillo Date: 2013-10-19 08:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/jdk/rev/1e99d539088d Merge Changeset: 7ec4ddc36ad6 Author: erikj Date: 2013-10-17 16:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jdk/rev/11e90e4167d4 Merge Changeset: 3a6ac3484b05 Author: cl Date: 2013-10-21 23:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/1628a137edca Merge Changeset: f26a0c8071bd Author: erikj Date: 2013-10-29 15:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jdk/rev/62982664dc72 Added tag jdk8-b114 for changeset f26a0c8071bd ! .hgtags From john.coomes at oracle.com Thu Nov 7 16:03:16 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Nov 2013 00:03:16 -0000 Subject: hg: hsx/hotspot-comp/jdk: 212 new changesets Message-ID: <20131107203732.4CB6E62430@hg.openjdk.java.net> Changeset: 180c05796c45 Author: bae Date: 2013-10-10 18:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/3371047f56f3 Merge Changeset: 2e59014ef38f Author: alexsch Date: 2013-10-09 13:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/93f4f012deaf Merge Changeset: 8d1d5a5aeb41 Author: robm Date: 2013-10-18 16:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/f443d9b863cf Merge Changeset: d0882a1deeb5 Author: juh Date: 2013-10-22 03:49 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d0882a1deeb5 Merge Changeset: 04ba97b7c2f9 Author: jfranck Date: 2013-10-22 10:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/d5c2b125ed0f Merge Changeset: cd60848c87b2 Author: rriggs Date: 2013-10-22 15:11 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cd60848c87b2 Merge Changeset: 4bb758a77fd7 Author: rriggs Date: 2013-10-22 17:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/jdk/rev/f2ddffb4b165 Merge Changeset: 9fbf35589211 Author: smarks Date: 2013-10-22 14:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/e7639b856256 Merge Changeset: ecba02f6be31 Author: sla Date: 2013-10-29 08:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/efbbcd5848cf Merge Changeset: 39ce82dad57d Author: jlaskey Date: 2013-04-09 08:36 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/39ce82dad57d Merge Changeset: ff9683b6854c Author: jlaskey Date: 2013-04-15 08:27 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jdk/rev/1cdf20da340b Merge Changeset: 72fa581a83a4 Author: jlaskey Date: 2013-04-22 14:00 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/72fa581a83a4 Merge Changeset: ead9944bbb3b Author: jlaskey Date: 2013-04-29 21:37 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ead9944bbb3b Merge Changeset: 5bde43b1e463 Author: jlaskey Date: 2013-05-14 09:04 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5bde43b1e463 Merge Changeset: efd620f8963f Author: jlaskey Date: 2013-05-23 09:48 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jdk/rev/193652dff077 Merge Changeset: 733713d7517c Author: jlaskey Date: 2013-06-05 13:10 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/4071c853edff Merge Changeset: bede752d1e3c Author: mfang Date: 2013-10-29 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/a389b4f5723f Added tag jdk8-b115 for changeset f82b730c798b ! .hgtags From christos.kotselidis at oracle.com Wed Nov 20 09:55:44 2013 From: christos.kotselidis at oracle.com (Christos Kotselidis) Date: Wed, 20 Nov 2013 18:55:44 +0100 Subject: Possible bug in nmethod reloc verification and G1 Message-ID: Hi, I came across the following scenario, I already discussed with Thomas Schatzl, that I would like to share with you. There is a method: private static final HotSpotGraalRuntime instance = new HotSpotGraalRuntime(); public static HotSpotGraalRuntime runtime() { return instance; } The instance field is a constant oop in the code and the method is installed. At some stage there is a GC with post verification (including G1VerifyHeapRegionCodeRoots) that passes. Before the next GC cycle and during the mutation cycle, another method is being installed which causes the eviction of our method. Consequently our method is being made not_entrant and it is being patched with a jmp instruction at its verified entry point (method.cpp::make_not_entrant_or_zombie). The patching causes the oop to be overwritten by the jmp instruction. Furthemore, that oop was the only oop that was responsible for attaching this method to its correspondent HeapRegion. The next GC cycle (Pre-verification) comes and the HeapRegionCodeRoot verification starts (method.cpp::oops_do). There is a logic there (which I also believe it may be buggy as I will explain later) that checks whether the method is not_entrant. If the method is not_entrant then the logic correctly assumes that the method has been already been patched and therefore starts scanning the relocs of the method in +5 bytes (for x86)/+4 bytes (for SPARC) (as the comment states). This results in not scanning the single oop that was attaching this specific method to its heap region. The verification then correctly asserts by saying that "there is a method attached to this specific heap region with no oops pointing into it". Concerning the second bug in the method::oops_do logic, here is the code for manipulating the reloc starting address after a method has been patched: // If the method is not entrant or zombie then a JMP is plastered over the // first few bytes. If an oop in the old code was there, that oop // should not get GC'd. Skip the first few bytes of oops on // not-entrant methods. address low_boundary = verified_entry_point(); if (is_not_entrant()) { low_boundary += NativeJump::instruction_size; // %%% Note: On SPARC we patch only a 4-byte trap, not a full NativeJump. // (See comment above.) } The code above accounts only for the "is not entrant" scenario and not with the "is zombie" scenario. I hope I got the story right?what do you think? Thank you in advance Regards Christos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131120/eb5d2302/attachment.html From christos.kotselidis at oracle.com Thu Nov 21 12:46:15 2013 From: christos.kotselidis at oracle.com (Christos Kotselidis) Date: Thu, 21 Nov 2013 21:46:15 +0100 Subject: Possible bug in nmethod reloc verification/scanning in G1 In-Reply-To: <528E517E.3020704@oracle.com> Message-ID: Thanks for the info. Yes, I cc'ed initially the compiler team but I guess the original email is pending for verification. Regards Christos On 11/21/13 7:31 PM, "Vladimir Kozlov" wrote: >CC to compiler because it is about compiled nmethods and their state >change. So it is interesting for us. > >Note, usually such methods are inlinied (accessor methods) and big >methods have stack bang code at the beginning. Here is criteria used to >generate stack bang: > >bool Compile::need_stack_bang(int frame_size_in_bytes) const { > // Determine if we need to generate a stack overflow check. > // Do it if the method is not a stub function and > // has java calls or has frame size > vm_page_size/8. > return (UseStackBanging && stub_function() == NULL && > (has_java_calls() || frame_size_in_bytes > >os::vm_page_size()>>3)); >} > >In your case stack bang is not generated that is why you have embedded >oop at the beginning of the code. >We can mark such nmethods so it will be easier to see such nmethod when >we need unregister them. > >And thank you for catching both problems. > >Thanks, >Vladimir > >On 11/21/13 5:54 AM, Thomas Schatzl wrote: >> Hi, >> >> On Thu, 2013-11-21 at 14:42 +0100, Christos Kotselidis wrote: >>> On 11/21/13 2:34 PM, "Thomas Schatzl" >>>wrote: >>> >>>> Hi, >>>> >>>> On Thu, 2013-11-21 at 12:40 +0100, Christos Kotselidis wrote: >>>>> Hi, >>>>> >>>>> I came across the following scenario, I already discussed with Thomas >>>>> Schatzl, that I would like to share with you. >>>>> There is a method: >>>>> >>>>> private static final HotSpotGraalRuntime instance = new >>>>> HotSpotGraalRuntime(); >>>>> >>>>> public static HotSpotGraalRuntime runtime() { >>>>> return instance; >>>>> } >>>> >>>>> The instance field is a constant oop in the code and the method is >>>>> installed. >>>>> At some stage there is a GC with post verification >>>>> (including G1VerifyHeapRegionCodeRoots) that passes. >>>>> Before the next GC cycle and during the mutation cycle, another >>>>>method >>>>> is being installed which causes the eviction of our method. >>>>> Consequently our method is being made not_entrant and it is being >>>>> patched with a jmp instruction at its verified entry point >>>>> (nmethod.cpp::make_not_entrant_or_zombie). The patching causes the >>>>>oop >>>>> to be overwritten by the jmp instruction. Furthermore, that oop was >>>>> the only oop that was responsible for attaching this method to its >>>>> correspondent HeapRegion. >>>>> >>>>> The next GC cycle (Pre-verification) comes and the HeapRegionCodeRoot >>>>> verification starts (nmethod.cpp::oops_do). There is a logic there >>>>> (which I also believe it may be buggy as I will explain later) that >>>>> checks whether the method is not_entrant. If the method is >>>>>not_entrant >>>>> then the logic correctly assumes that the method has been already >>>>>been >>>>> patched and therefore starts scanning the relocs of the method in +5 >>>>> bytes (for x86)/+4 bytes (for SPARC) (as the comment states). This >>>>> results in not scanning the single oop that was attaching this >>>>> specific method to its heap region. The verification then correctly >>>>> asserts by saying that "there is a method attached to this specific >>>>> heap region with no oops pointing into it". >>>> >>>> Thanks for finding this - I already filed a bug for that >>>> (https://bugs.openjdk.java.net/browse/JDK-8028736). Please check if it >>>> matches your investigation. >>>>> >>>>> Concerning the second bug in the method::oops_do logic, here is the >>>>> code for manipulating the reloc starting address after a method has >>>>> been patched: >>>> >>>>> // If the method is not entrant or zombie then a JMP is plastered >>>>>over >>>>> // the >>>>> // first few bytes. If an oop in the old code was there, that oop >>>>> // should not get GC'd. Skip the first few bytes of oops on >>>>> // not-entrant methods. >>>>> address low_boundary = verified_entry_point(); >>>>> if (is_not_entrant()) { >>>>> low_boundary += NativeJump::instruction_size; >>>>> // %%% Note: On SPARC we patch only a 4-byte trap, not a full >>>>> NativeJump. >>>>> // (See comment above.) >>>>> } >>>>> >>>>> The code above accounts only for the "is not entrant" scenario and >>>>>not >>>>> with the "is zombie" scenario. >>>> >>>> nmethod::do_oops will not be called for zombie methods in the default >>>> case, so it does not matter. I.e. the default overload of >>>> oops_do(Closure* cl, bool zombie) is oops_do(cl, false); >>> >>> When unregistering a method we call the oops_do allowing zombie methods >>> (G1CollectedHeap::unregister_nmethod). That was causing a problem in my >>> case and after adding "|| is_zombie()", it got fixed. >> >> I think you are right, we will need to fix that too as the oop map is >> not changed after overwriting the oop in the first few bytes. >> >> Thomas >> >>