From roland.westrelin at oracle.com Wed Jan 2 01:39:55 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 2 Jan 2013 10:39:55 +0100 Subject: Request for reviews (S): 8005522: use fast-string instructions on x86 for zeroing In-Reply-To: <50DBC70C.2050502@oracle.com> References: <50CCF501.7060409@oracle.com> <50DBC70C.2050502@oracle.com> Message-ID: > http://cr.openjdk.java.net/~kvn/8005522/webrev/ > > 8005522: use fast-string instructions on x86 for zeroing In x86_32.ad/x86_64.ad the rep_stos() format is no longer in sync with the code that is emitted. Otherwise, it looks good. Roland. From roland.westrelin at oracle.com Wed Jan 2 03:09:42 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 2 Jan 2013 12:09:42 +0100 Subject: Request for reviews (S): 8005544: Use 256bit YMM registers in arraycopy stubs on x86 In-Reply-To: <50DCCCAD.3050604@oracle.com> References: <50DCCCAD.3050604@oracle.com> Message-ID: <6A99F436-2880-42DA-A2EA-DD5A441FB6AD@oracle.com> > http://cr.openjdk.java.net/~kvn/8005544/webrev/ > > New x86 processors with AVX2 have wide memory bus and improved memory operations with YMM registers. Use them to copy data in arraycopy stubs. It looks good to me. Roland. From vladimir.kozlov at oracle.com Wed Jan 2 10:06:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Jan 2013 10:06:13 -0800 Subject: Request for reviews (S): 8005544: Use 256bit YMM registers in arraycopy stubs on x86 In-Reply-To: <6A99F436-2880-42DA-A2EA-DD5A441FB6AD@oracle.com> References: <50DCCCAD.3050604@oracle.com> <6A99F436-2880-42DA-A2EA-DD5A441FB6AD@oracle.com> Message-ID: <50E47715.1090800@oracle.com> Thank you, Roland Vladimir On 1/2/13 3:09 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/8005544/webrev/ >> >> New x86 processors with AVX2 have wide memory bus and improved memory operations with YMM registers. Use them to copy data in arraycopy stubs. > > It looks good to me. > > Roland. > From vladimir.kozlov at oracle.com Wed Jan 2 10:28:21 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Jan 2013 10:28:21 -0800 Subject: Request for reviews (S): 8005522: use fast-string instructions on x86 for zeroing In-Reply-To: References: <50CCF501.7060409@oracle.com> <50DBC70C.2050502@oracle.com> Message-ID: <50E47C45.7030006@oracle.com> Thank you, Roland I added separate mach nodes for fast stosb in .ad files to fox formats: http://cr.openjdk.java.net/~kvn/8005522/webrev.01/ Thanks, Vladimir On 1/2/13 1:39 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/8005522/webrev/ >> >> 8005522: use fast-string instructions on x86 for zeroing > > > In x86_32.ad/x86_64.ad the rep_stos() format is no longer in sync with the code that is emitted. > Otherwise, it looks good. > > Roland. > From christian.thalinger at oracle.com Wed Jan 2 12:05:54 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Jan 2013 12:05:54 -0800 Subject: RFR (S) 8003251: ARM: move MacroAssembler into separate file In-Reply-To: <50DE4241.7030601@oracle.com> References: <50DDBB78.4090102@oracle.com> <50DE4241.7030601@oracle.com> Message-ID: <9ECCD24F-BF97-42B6-9B7D-41F4C7BB0906@oracle.com> Yes, looks good. -- Chris On Dec 28, 2012, at 5:07 PM, Vladimir Kozlov wrote: > Looks good. I created webrev on open server: > > http://cr.openjdk.java.net/~kvn/8003251/webrev/ > > Thanks, > Vladimir > > On 12/28/12 7:32 AM, Morris Meyer wrote: > > Folks, > > > > Could I get a review of this refactoring requested by Christian > > Thalinger? Per the workflow I've done a JPRT run. > > > > Thanks in advance, > > > > --mm > > > > WEBREV - > > http://javaweb.us.oracle.com/~mameyer/webrevs/01/JDK-8003251-hotspot > From christian.thalinger at oracle.com Wed Jan 2 16:50:11 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Jan 2013 16:50:11 -0800 Subject: Request for reviews (S): 8005544: Use 256bit YMM registers in arraycopy stubs on x86 In-Reply-To: <50DCF2AD.50701@oracle.com> References: <50DCCCAD.3050604@oracle.com> <50DCF2AD.50701@oracle.com> Message-ID: <4E1732EB-2356-4128-81D0-391B1D96E037@oracle.com> On Dec 27, 2012, at 5:15 PM, Vladimir Kozlov wrote: > On 12/27/12 2:33 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8005544/webrev/ src/cpu/x86/vm/stubGenerator_x86_32.cpp: + __ vmovdqu(xmm0,Address(from, 0)); + __ vmovdqu(xmm1,Address(from, 32)); There is a space missing after the ",". src/cpu/x86/vm/stubGenerator_x86_64.cpp: In that file there are a couple as well. Otherwise this looks good. -- Chris >> >> New x86 processors with AVX2 have wide memory bus and improved memory >> operations with YMM registers. Use them to copy data in arraycopy stubs. > > Also use them in array_fill code. > >> >> Most changes in stubGenerator_x86_64.cpp are renaming of copy_32_bytes >> to copy_bytes since now the code copies 64 or 32 bytes per iteration. >> >> Ran compiler regression tests with 64- and 32-bit VM. >> >> Thanks, >> Vladimir >> From christian.thalinger at oracle.com Wed Jan 2 16:56:23 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Jan 2013 16:56:23 -0800 Subject: Request for reviews (S): 8005522: use fast-string instructions on x86 for zeroing In-Reply-To: <50E47C45.7030006@oracle.com> References: <50CCF501.7060409@oracle.com> <50DBC70C.2050502@oracle.com> <50E47C45.7030006@oracle.com> Message-ID: <9FFEC1E0-6BC8-4FAF-A155-029A6F5FA011@oracle.com> On Jan 2, 2013, at 10:28 AM, Vladimir Kozlov wrote: > Thank you, Roland > > I added separate mach nodes for fast stosb in .ad files to fox formats: > > http://cr.openjdk.java.net/~kvn/8005522/webrev.01/ + void rep_setbyte(); Can we name it rep_stosb? That's closer to the actual instruction. -- Chris > > Thanks, > Vladimir > > On 1/2/13 1:39 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~kvn/8005522/webrev/ >>> >>> 8005522: use fast-string instructions on x86 for zeroing >> >> >> In x86_32.ad/x86_64.ad the rep_stos() format is no longer in sync with the code that is emitted. >> Otherwise, it looks good. >> >> Roland. >> From vladimir.kozlov at oracle.com Wed Jan 2 16:54:39 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Jan 2013 16:54:39 -0800 Subject: Request for reviews (S): 8005544: Use 256bit YMM registers in arraycopy stubs on x86 In-Reply-To: <4E1732EB-2356-4128-81D0-391B1D96E037@oracle.com> References: <50DCCCAD.3050604@oracle.com> <50DCF2AD.50701@oracle.com> <4E1732EB-2356-4128-81D0-391B1D96E037@oracle.com> Message-ID: <50E4D6CF.9090702@oracle.com> On 1/2/13 4:50 PM, Christian Thalinger wrote: > > On Dec 27, 2012, at 5:15 PM, Vladimir Kozlov wrote: > >> On 12/27/12 2:33 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/8005544/webrev/ > > src/cpu/x86/vm/stubGenerator_x86_32.cpp: > > + __ vmovdqu(xmm0,Address(from, 0)); > + __ vmovdqu(xmm1,Address(from, 32)); > > There is a space missing after the ",". Fixed. Thanks, Vladimir > > src/cpu/x86/vm/stubGenerator_x86_64.cpp: > > In that file there are a couple as well. > > Otherwise this looks good. > > -- Chris > >>> >>> New x86 processors with AVX2 have wide memory bus and improved memory >>> operations with YMM registers. Use them to copy data in arraycopy stubs. >> >> Also use them in array_fill code. >> >>> >>> Most changes in stubGenerator_x86_64.cpp are renaming of copy_32_bytes >>> to copy_bytes since now the code copies 64 or 32 bytes per iteration. >>> >>> Ran compiler regression tests with 64- and 32-bit VM. >>> >>> Thanks, >>> Vladimir >>> > From vladimir.kozlov at oracle.com Wed Jan 2 17:22:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Jan 2013 17:22:32 -0800 Subject: Request for reviews (S): 8005522: use fast-string instructions on x86 for zeroing In-Reply-To: <9FFEC1E0-6BC8-4FAF-A155-029A6F5FA011@oracle.com> References: <50CCF501.7060409@oracle.com> <50DBC70C.2050502@oracle.com> <50E47C45.7030006@oracle.com> <9FFEC1E0-6BC8-4FAF-A155-029A6F5FA011@oracle.com> Message-ID: <50E4DD58.7080103@oracle.com> On 1/2/13 4:56 PM, Christian Thalinger wrote: > > On Jan 2, 2013, at 10:28 AM, Vladimir Kozlov wrote: > >> Thank you, Roland >> >> I added separate mach nodes for fast stosb in .ad files to fox formats: >> >> http://cr.openjdk.java.net/~kvn/8005522/webrev.01/ > > + void rep_setbyte(); > > Can we name it rep_stosb? That's closer to the actual instruction. For that I also need to rename rep_set() to rep_stos(): http://cr.openjdk.java.net/~kvn/8005522/webrev.02 Thanks, Vladimir > > -- Chris > >> >> Thanks, >> Vladimir >> >> On 1/2/13 1:39 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~kvn/8005522/webrev/ >>>> >>>> 8005522: use fast-string instructions on x86 for zeroing >>> >>> >>> In x86_32.ad/x86_64.ad the rep_stos() format is no longer in sync with the code that is emitted. >>> Otherwise, it looks good. >>> >>> Roland. >>> > From roland.westrelin at oracle.com Thu Jan 3 01:53:13 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 3 Jan 2013 10:53:13 +0100 Subject: Request for reviews (S): 8005522: use fast-string instructions on x86 for zeroing In-Reply-To: <50E4DD58.7080103@oracle.com> References: <50CCF501.7060409@oracle.com> <50DBC70C.2050502@oracle.com> <50E47C45.7030006@oracle.com> <9FFEC1E0-6BC8-4FAF-A155-029A6F5FA011@oracle.com> <50E4DD58.7080103@oracle.com> Message-ID: <6041D545-C21E-4F6A-941E-8AF773AFF701@oracle.com> > For that I also need to rename rep_set() to rep_stos(): > > http://cr.openjdk.java.net/~kvn/8005522/webrev.02 It looks good to me. Roland. From christian.thalinger at oracle.com Thu Jan 3 11:12:50 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Jan 2013 11:12:50 -0800 Subject: Request for reviews (S): 8005522: use fast-string instructions on x86 for zeroing In-Reply-To: <50E4DD58.7080103@oracle.com> References: <50CCF501.7060409@oracle.com> <50DBC70C.2050502@oracle.com> <50E47C45.7030006@oracle.com> <9FFEC1E0-6BC8-4FAF-A155-029A6F5FA011@oracle.com> <50E4DD58.7080103@oracle.com> Message-ID: <1DDB857C-B0DF-4F3D-BA36-4CD13CB1C468@oracle.com> On Jan 2, 2013, at 5:22 PM, Vladimir Kozlov wrote: > On 1/2/13 4:56 PM, Christian Thalinger wrote: >> >> On Jan 2, 2013, at 10:28 AM, Vladimir Kozlov wrote: >> >>> Thank you, Roland >>> >>> I added separate mach nodes for fast stosb in .ad files to fox formats: >>> >>> http://cr.openjdk.java.net/~kvn/8005522/webrev.01/ >> >> + void rep_setbyte(); >> >> Can we name it rep_stosb? That's closer to the actual instruction. > > For that I also need to rename rep_set() to rep_stos(): > > http://cr.openjdk.java.net/~kvn/8005522/webrev.02 Much better. Thanks. -- Chris > > Thanks, > Vladimir > >> >> -- Chris >> >>> >>> Thanks, >>> Vladimir >>> >>> On 1/2/13 1:39 AM, Roland Westrelin wrote: >>>>> http://cr.openjdk.java.net/~kvn/8005522/webrev/ >>>>> >>>>> 8005522: use fast-string instructions on x86 for zeroing >>>> >>>> >>>> In x86_32.ad/x86_64.ad the rep_stos() format is no longer in sync with the code that is emitted. >>>> Otherwise, it looks good. >>>> >>>> Roland. >>>> >> From vladimir.kozlov at oracle.com Thu Jan 3 11:37:42 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Jan 2013 11:37:42 -0800 Subject: Request for reviews (S): 8005522: use fast-string instructions on x86 for zeroing In-Reply-To: <1DDB857C-B0DF-4F3D-BA36-4CD13CB1C468@oracle.com> References: <50CCF501.7060409@oracle.com> <50DBC70C.2050502@oracle.com> <50E47C45.7030006@oracle.com> <9FFEC1E0-6BC8-4FAF-A155-029A6F5FA011@oracle.com> <50E4DD58.7080103@oracle.com> <1DDB857C-B0DF-4F3D-BA36-4CD13CB1C468@oracle.com> Message-ID: <50E5DE06.7040603@oracle.com> Thank you, Christian Vladimir On 1/3/13 11:12 AM, Christian Thalinger wrote: > > On Jan 2, 2013, at 5:22 PM, Vladimir Kozlov wrote: > >> On 1/2/13 4:56 PM, Christian Thalinger wrote: >>> >>> On Jan 2, 2013, at 10:28 AM, Vladimir Kozlov wrote: >>> >>>> Thank you, Roland >>>> >>>> I added separate mach nodes for fast stosb in .ad files to fox formats: >>>> >>>> http://cr.openjdk.java.net/~kvn/8005522/webrev.01/ >>> >>> + void rep_setbyte(); >>> >>> Can we name it rep_stosb? That's closer to the actual instruction. >> >> For that I also need to rename rep_set() to rep_stos(): >> >> http://cr.openjdk.java.net/~kvn/8005522/webrev.02 > > Much better. Thanks. > > -- Chris > >> >> Thanks, >> Vladimir >> >>> >>> -- Chris >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/2/13 1:39 AM, Roland Westrelin wrote: >>>>>> http://cr.openjdk.java.net/~kvn/8005522/webrev/ >>>>>> >>>>>> 8005522: use fast-string instructions on x86 for zeroing >>>>> >>>>> >>>>> In x86_32.ad/x86_64.ad the rep_stos() format is no longer in sync with the code that is emitted. >>>>> Otherwise, it looks good. >>>>> >>>>> Roland. >>>>> >>> > From headius at headius.com Thu Jan 3 12:24:45 2013 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 3 Jan 2013 14:24:45 -0600 Subject: Virtual dispatch bug in 292 impl In-Reply-To: References: <62ECFA9C-7CBC-444B-8038-357F19C00289@oracle.com> Message-ID: Sorry I lost track of this thread going into the holidays...I talked to Christian a moment ago but I reply here for the record... Christian Thalinger wrote: >> I filed: >> >> https://jbs.oracle.com/bugs/browse/JDK-8005418 >> >> But it seems to be C2, not C1: Does look that way in your output. I'll leave it in your hands. I will say I am almost positive that when I ran with tier=1 it failed, and -tiered worked ok, but I don't have the output in front of me. > What's the name of the [] implementation of ENV? Is it StringOnlyRubyHash.op_aref? Yes, that's the one. The handle points at the superclass impl, RubyHash.op_aref, and that's the one that gets hit instead of the override. > Could this be the compile that goes wrong? > > 12903 956 java.lang.invoke.LambdaForm$MH/847376::convert (52 bytes) > @ 15 java.lang.invoke.LambdaForm$BMH/23638730::reinvoke (26 bytes) inline (hot) > @ 12 java.lang.invoke.BoundMethodHandle$Species_LL::reinvokerTarget (8 bytes) inline (hot) > @ 22 java.lang.invoke.LambdaForm$DMH/20340225::invokeStatic_LL_L (15 bytes) inline (hot) > @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) inline (hot) > @ 11 sun.invoke.util.ValueConversions::castReference (6 bytes) inline (hot) > @ 2 java.lang.Class::cast (27 bytes) inline (hot) > @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) > @ 33 java.lang.Class::cast (27 bytes) inline (hot) > @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) > @ 43 java.lang.Class::cast (27 bytes) inline (hot) > @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) > @ 48 java.lang.invoke.LambdaForm$DMH/32367447::invokeVirtual_LLL_L (18 bytes) inline (hot) > @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) inline (hot) > @ 14 org.jruby.RubyHash::op_aref (23 bytes) inline (hot) This looks like what I saw while debugging, yes. Not sure if this exact output is right because there's not much context, but I did see the call that *should* have been going to StringOnlyRubyHash.op_aref going to RubyHash.op_aref. There aren't many such cases in JRuby...most overrides are accompanied by an override in the Ruby class structures, so the child class has its own handle pointing at the override. That's probably why we don't see it in more places. I have not retested with any of the recent work on partial inlining, etc. Since it looks like you're able to reproduce it ok, I'll leave it in your hands. Let me know what else I can do. - Charlie From vladimir.kozlov at oracle.com Thu Jan 3 17:05:02 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 04 Jan 2013 01:05:02 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8005522: use fast-string instructions on x86 for zeroing Message-ID: <20130104010505.098FF4751B@hg.openjdk.java.net> Changeset: 00af3a3a8df4 Author: kvn Date: 2013-01-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/00af3a3a8df4 8005522: use fast-string instructions on x86 for zeroing Summary: use 'rep stosb' instead of 'rep stosq' when fast-string operations are available. Reviewed-by: twisti, roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/memnode.cpp From vladimir.kozlov at oracle.com Thu Jan 3 19:44:23 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 04 Jan 2013 03:44:23 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Message-ID: <20130104034427.F009047521@hg.openjdk.java.net> Changeset: e2e6bf86682c Author: kvn Date: 2013-01-03 16:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e2e6bf86682c 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Summary: Use YMM registers in arraycopy and array_fill stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp From john.coomes at oracle.com Thu Jan 3 20:58:36 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 04:58:36 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b71 for changeset f577a39c9fb3 Message-ID: <20130104045841.AAC144752C@hg.openjdk.java.net> Changeset: d9707230294d Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/d9707230294d Added tag jdk8-b71 for changeset f577a39c9fb3 ! .hgtags From john.coomes at oracle.com Thu Jan 3 20:57:59 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 04:57:59 +0000 Subject: hg: hsx/hotspot-comp: 5 new changesets Message-ID: <20130104045759.C7D5A47529@hg.openjdk.java.net> Changeset: 2ed5be3dd506 Author: lana Date: 2012-12-16 22:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/2ed5be3dd506 Merge Changeset: a0779b1e9a4d Author: jjg Date: 2012-12-17 08:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/a0779b1e9a4d 8005090: Include com.sun.source.doctree in Tree API docs Reviewed-by: erikj ! common/makefiles/javadoc/NON_CORE_PKGS.gmk Changeset: 68a81db3ceb1 Author: lana Date: 2012-12-18 17:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/68a81db3ceb1 Merge Changeset: 51ad2a343420 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/51ad2a343420 Merge Changeset: c1be681d80a1 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/c1be681d80a1 Added tag jdk8-b71 for changeset 51ad2a343420 ! .hgtags From john.coomes at oracle.com Thu Jan 3 20:58:04 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 04:58:04 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b71 for changeset 8171d23e914d Message-ID: <20130104045806.7C6444752A@hg.openjdk.java.net> Changeset: cb40427f4714 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/cb40427f4714 Added tag jdk8-b71 for changeset 8171d23e914d ! .hgtags From john.coomes at oracle.com Thu Jan 3 20:58:11 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 04:58:11 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 6 new changesets Message-ID: <20130104045831.A5B304752B@hg.openjdk.java.net> Changeset: b1fdb101c82e Author: joehw Date: 2012-12-14 13:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/b1fdb101c82e 8003260: [findbug] some fields should be package protected Summary: change public or protected mutable static fields to private or package private. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java Changeset: 8a20e948b806 Author: lana Date: 2012-12-16 22:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/8a20e948b806 Merge Changeset: 15b32367b23c Author: joehw Date: 2012-12-18 21:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/15b32367b23c 8003261: static field is public but not final Summary: add final to fVersion field, and make it a non-compile time constant. Reviewed-by: hawtin, lancea, dholmes, chegar ! src/com/sun/org/apache/xerces/internal/impl/Version.java Changeset: d4aea0225e80 Author: joehw Date: 2012-12-27 18:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/d4aea0225e80 8005473: Warnings compiling jaxp Summary: clean up compiling warnings. Reviewed-by: weijun, chegar, forax ! src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java ! src/javax/xml/transform/FactoryFinder.java ! src/javax/xml/validation/SchemaFactoryFinder.java ! src/javax/xml/xpath/XPathFactoryFinder.java Changeset: 499be952a291 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/499be952a291 Merge Changeset: bdf2af722a6b Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/bdf2af722a6b Added tag jdk8-b71 for changeset 499be952a291 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:00:37 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:00:37 +0000 Subject: hg: hsx/hotspot-comp/jdk: 53 new changesets Message-ID: <20130104051104.F29284752D@hg.openjdk.java.net> Changeset: a988c23b8553 Author: jgodinez Date: 2012-12-20 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a988c23b8553 7180359: Assertion in awt_Win32GraphicsDevice.cpp when running specjbb in jprt Reviewed-by: bae, prr ! src/windows/native/sun/windows/awt_Debug.cpp Changeset: 2cf07dbdee64 Author: bae Date: 2012-12-24 14:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2cf07dbdee64 7124245: [lcms] ColorConvertOp to color space CS_GRAY apparently converts orange to 244,244,0 Reviewed-by: prr ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c + test/sun/java2d/cmm/ColorConvertOp/GrayTest.java Changeset: 3c1c0b7abe51 Author: bae Date: 2012-12-24 14:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3c1c0b7abe51 8005402: Need to provide benchmarks for color management Reviewed-by: jgodinez, prr ! src/share/demo/java2d/J2DBench/build.xml ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/CMMTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConvertOpTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/DataConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ProfileTests.java Changeset: 1316d6d0900e Author: lana Date: 2012-12-28 18:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1316d6d0900e Merge Changeset: c25ea633b4de Author: malenkov Date: 2012-12-17 16:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c25ea633b4de 8005065: [findbugs] reference to mutable array in JavaBeans Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/Statement.java + test/java/beans/Introspector/Test8005065.java Changeset: a78cb3c5d434 Author: neugens Date: 2012-12-17 17:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a78cb3c5d434 8005018: X11: focus problems with openjdk 1.7.0 under gnome3 when selected keyboard is not the first in keyboard list Summary: Don't consider extraenous bits when checking button mask, so that grabWindowRef on the window is not confused and released correctly Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java Changeset: 985b523712c8 Author: kshefov Date: 2012-12-18 15:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/985b523712c8 7104594: [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default Reviewed-by: yan, alexsch + test/javax/swing/JFrame/4962534/bug4962534.html + test/javax/swing/JFrame/4962534/bug4962534.java Changeset: 90ad9e922042 Author: lana Date: 2012-12-18 16:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/90ad9e922042 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: 7082a96c02d2 Author: alexp Date: 2012-12-21 19:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7082a96c02d2 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx Reviewed-by: anthony, alexsch ! test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: 14269f504837 Author: dcherepanov Date: 2012-12-27 16:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/14269f504837 8001161: mac: EmbeddedFrame doesn't become active window Reviewed-by: ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: cf2bcb293f0b Author: lana Date: 2012-12-28 18:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cf2bcb293f0b Merge Changeset: 69fd3f3d20c1 Author: alanb Date: 2012-12-15 15:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/69fd3f3d20c1 8004963: URLConnection, downgrade normative reference to ${java.home}/lib/content-types.properties Reviewed-by: chegar ! src/share/classes/java/net/URLConnection.java Changeset: eaaec81aa974 Author: weijun Date: 2012-12-17 12:18 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/eaaec81aa974 7197159: accept different kvno if there no match Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/EncryptionKey.java ! test/sun/security/krb5/auto/DynamicKeytab.java + test/sun/security/krb5/auto/KvnoNA.java ! test/sun/security/krb5/auto/MoreKvno.java Changeset: f959e0cc8766 Author: lana Date: 2012-12-16 22:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f959e0cc8766 Merge ! makefiles/CompileNativeLibraries.gmk - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: a02212de8db6 Author: uta Date: 2012-12-17 14:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a02212de8db6 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem Summary: the tests were refactored to drop AWT dependence where it was possible. Reviewed-by: alanb, mchung ! test/java/io/Serializable/resolveProxyClass/NonPublicInterface.java ! test/java/lang/Throwable/LegacyChainedExceptionSerialization.java ! test/java/lang/management/CompilationMXBean/Basic.java ! test/java/lang/reflect/Generics/Probe.java ! test/java/lang/reflect/Proxy/ClassRestrictions.java ! test/java/util/Collections/EmptyIterator.java ! test/java/util/logging/LoggingDeadlock4.java ! test/sun/tools/jrunscript/common.sh Changeset: e4d88a7352c6 Author: mullan Date: 2012-12-17 08:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e4d88a7352c6 8004234: Downgrade normative references to ${java.home}/lib/security/krb5.conf Reviewed-by: alanb, weijun ! src/share/classes/javax/security/auth/kerberos/package.html Changeset: 4a21f818ebb1 Author: mullan Date: 2012-12-17 08:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4a21f818ebb1 Merge - src/share/classes/sun/awt/TextureSizeConstraining.java - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: bcf79e6f52a0 Author: chegar Date: 2012-12-17 16:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bcf79e6f52a0 8005081: java/util/prefs/PrefsSpi.sh fails on macos-x Reviewed-by: alanb ! test/java/util/prefs/PrefsSpi.sh Changeset: 9f1b516cd9cb Author: jjg Date: 2012-12-17 08:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9f1b516cd9cb 8005090: Include com.sun.source.doctree in Tree API docs Reviewed-by: erikj ! make/docs/NON_CORE_PKGS.gmk Changeset: bac477d67867 Author: jjg Date: 2012-12-17 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bac477d67867 8004832: Add new doclint package Reviewed-by: erikj, ohair ! make/common/Release.gmk ! make/common/internal/Defs-langtools.gmk ! makefiles/CreateJars.gmk Changeset: 0fabdf676395 Author: martin Date: 2012-12-17 18:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0fabdf676395 8004863: Infinite Loop in KeepAliveStream Reviewed-by: chegar ! src/share/classes/sun/net/www/http/KeepAliveStream.java + test/sun/net/www/http/KeepAliveStream/InfiniteLoop.java Changeset: 0a1398021c7c Author: darcy Date: 2012-12-18 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0a1398021c7c 8005042: Add Method.isDefault to core reflection Reviewed-by: alanb, forax, mduigou, jgish, mchung ! src/share/classes/java/lang/reflect/Method.java + test/java/lang/reflect/Method/IsDefaultTest.java Changeset: 6d977f61af5e Author: darcy Date: 2012-12-18 14:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6d977f61af5e 8004699: Add type annotation storage to Constructor, Field and Method Reviewed-by: darcy, dholmes Contributed-by: joel.franck at oracle.com ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java Changeset: e515956879cd Author: lana Date: 2012-12-18 18:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e515956879cd Merge Changeset: c79b26b8efe0 Author: sjiang Date: 2012-12-19 11:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c79b26b8efe0 7158614: JMXStartStopTest.sh failing intermittently Summary: fixed 3 problems here: 1) checked the lock file too eary 2) never got the process id of a java test 3) some shell commands were not supported in some Solaris machines. Reviewed-by: dsamersoff, alanb ! test/ProblemList.txt ! test/sun/management/jmxremote/startstop/JMXStartStopDoSomething.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 3fd3bcc8bd42 Author: joehw Date: 2012-12-19 12:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3fd3bcc8bd42 8004371: (props) Properties.loadFromXML needs small footprint XML parser as fallback when JAXP is not present Reviewed-by: alanb, mchung, psandoz + src/share/classes/jdk/internal/org/xml/sax/Attributes.java + src/share/classes/jdk/internal/org/xml/sax/ContentHandler.java + src/share/classes/jdk/internal/org/xml/sax/DTDHandler.java + src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java + src/share/classes/jdk/internal/org/xml/sax/ErrorHandler.java + src/share/classes/jdk/internal/org/xml/sax/InputSource.java + src/share/classes/jdk/internal/org/xml/sax/Locator.java + src/share/classes/jdk/internal/org/xml/sax/SAXException.java + src/share/classes/jdk/internal/org/xml/sax/SAXNotRecognizedException.java + src/share/classes/jdk/internal/org/xml/sax/SAXNotSupportedException.java + src/share/classes/jdk/internal/org/xml/sax/SAXParseException.java + src/share/classes/jdk/internal/org/xml/sax/XMLReader.java + src/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java + src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java + src/share/classes/jdk/internal/util/xml/SAXParser.java + src/share/classes/jdk/internal/util/xml/XMLStreamException.java + src/share/classes/jdk/internal/util/xml/XMLStreamWriter.java + src/share/classes/jdk/internal/util/xml/impl/Attrs.java + src/share/classes/jdk/internal/util/xml/impl/Input.java + src/share/classes/jdk/internal/util/xml/impl/Pair.java + src/share/classes/jdk/internal/util/xml/impl/Parser.java + src/share/classes/jdk/internal/util/xml/impl/ParserSAX.java + src/share/classes/jdk/internal/util/xml/impl/ReaderUTF16.java + src/share/classes/jdk/internal/util/xml/impl/ReaderUTF8.java + src/share/classes/jdk/internal/util/xml/impl/SAXParserImpl.java + src/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java + src/share/classes/jdk/internal/util/xml/impl/XMLWriter.java Changeset: cf15abdcdf88 Author: alanb Date: 2012-12-19 14:53 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cf15abdcdf88 8005248: (props) Integrate small footprint parser into Properties Reviewed-by: joehw, mchung, psandoz, erikj ! make/jdk/Makefile - make/jdk/asm/Makefile ! src/share/classes/java/util/Properties.java + src/share/classes/jdk/internal/util/xml/BasicXmlPropertiesProvider.java ! test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/invalidxml/BadCase.xml + test/java/util/Properties/invalidxml/BadDocType.xml.excluded + test/java/util/Properties/invalidxml/NoClosingTag.xml + test/java/util/Properties/invalidxml/NoDocType.xml.excluded + test/java/util/Properties/invalidxml/NoRoot.xml + test/java/util/Properties/invalidxml/NotQuoted.xml + test/java/util/Properties/invalidxml/README.txt Changeset: 1f9c19741285 Author: darcy Date: 2012-12-19 11:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1f9c19741285 8005097: Tie isSynthetic javadoc to the JLS Reviewed-by: mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Member.java ! src/share/classes/java/lang/reflect/Method.java Changeset: b600d490dc57 Author: dsamersoff Date: 2012-12-20 16:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b600d490dc57 6783290: MBeanInfo/MBeanFeatureInfo has inconsistent readObject/writeObject Summary: call readObject in all cases Reviewed-by: emcmanus Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanInfo.java Changeset: e43f90d5af11 Author: dsamersoff Date: 2012-12-20 16:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e43f90d5af11 6937053: RMI unmarshalling errors in ClientNotifForwarder cause silent failure Summary: the catch block in the fetchNotifs() method is extended to expect UnmarshalException Reviewed-by: emcmanus Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java Changeset: 3f014bc09297 Author: dsamersoff Date: 2012-12-20 17:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3f014bc09297 7009998: JMX synchronization during connection restart is faulty Summary: add a return statement after the re-connecting has finished and the state is CONNECTED Reviewed-by: sjiang Contributed-by: jaroslav.bachorik at oracle.com ! make/netbeans/jmx/build.properties ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java Changeset: d01a810798e0 Author: dl Date: 2012-12-20 13:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d01a810798e0 8002356: Add ForkJoin common pool and CountedCompleter Reviewed-by: chegar, mduigou ! make/java/java/FILES_java.gmk + src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java Changeset: 31d2f9995d6c Author: chegar Date: 2012-12-20 15:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/31d2f9995d6c 8005306: Redundant cast warning in KeepAliveStream.java Reviewed-by: alanb ! src/share/classes/sun/net/www/http/KeepAliveStream.java Changeset: c1a55ee9618e Author: dsamersoff Date: 2012-12-20 20:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c1a55ee9618e 8005309: Missed tests for 6783290,6937053,7009998 Summary: Missed tests for 6783290,6937053,7009998 Reviewed-by: sjiang, emcmanus Contributed-by: jaroslav.bachorik at oracle.com + test/com/sun/jmx/remote/CCAdminReconnectTest.java + 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.sh + test/javax/management/MBeanInfo/SerializationTest1.java Changeset: edb71a37fcb7 Author: alanb Date: 2012-12-20 20:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/edb71a37fcb7 8001048: JSR-160: Allow IIOP transport to be optional Reviewed-by: dsamersoff, dfuchs, mchung ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/JMXConnectorServerFactory.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/package.html ! test/javax/management/remote/mandatory/connection/AddressableTest.java ! test/javax/management/remote/mandatory/connection/CloseableTest.java ! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java ! test/javax/management/remote/mandatory/connection/IIOPURLTest.java ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java ! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java ! test/javax/management/remote/mandatory/connectorServer/SetMBeanServerForwarder.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/serverError/JMXServerErrorTest.java Changeset: eeda18683ddc Author: alanb Date: 2012-12-20 20:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/eeda18683ddc 8005281: (props) loadFromXML/storeToXML with small parser is not thread safe Reviewed-by: mchung ! src/share/classes/jdk/internal/util/xml/BasicXmlPropertiesProvider.java + test/java/util/Properties/ConcurrentLoadAndStoreXML.java Changeset: 60adb69bf043 Author: smarks Date: 2012-12-20 20:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/60adb69bf043 8005290: remove -showversion from RMI test library subprocess mechanism Reviewed-by: jgish, chegar, dmocek ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java Changeset: 42ee6b6ad373 Author: jbachorik Date: 2012-12-21 09:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/42ee6b6ad373 7146162: javax/management/remote/mandatory/connection/BrokenConnectionTest.java failing intermittently Summary: ClientCommunicatorAdmin should call gotIOException((IOException)e) instead of restart((IOException)e) when detecting a communication error, because the method gotIOException will send a failure notification if necessary. Reviewed-by: emcmanus, sjiang Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java Changeset: 86c10d1484e9 Author: sjiang Date: 2012-12-21 10:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/86c10d1484e9 8005325: The script should use TESTVMOPTS Summary: Put back TESTVMOPTS which was removed by mistake. Reviewed-by: smarks ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: c1227b872a12 Author: joehw Date: 2012-12-21 17:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c1227b872a12 8005280: (props) Improve test coverage for small XML parser Summary: added a few more invalid XML files, international characters to LoadAndStore test, and a behavior compatibility test. Reviewed-by: alanb, lancea + test/java/util/Properties/Compatibility.xml + test/java/util/Properties/CompatibilityTest.java ! test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/invalidxml/BadDocType.xml - test/java/util/Properties/invalidxml/BadDocType.xml.excluded + test/java/util/Properties/invalidxml/DTDRootNotMatch.xml + test/java/util/Properties/invalidxml/IllegalComment.xml + test/java/util/Properties/invalidxml/IllegalEntry.xml + test/java/util/Properties/invalidxml/IllegalEntry1.xml + test/java/util/Properties/invalidxml/IllegalKeyAttribute.xml + test/java/util/Properties/invalidxml/NoDocType.xml - test/java/util/Properties/invalidxml/NoDocType.xml.excluded + test/java/util/Properties/invalidxml/NoNamespaceSupport.xml Changeset: 4d28776d7007 Author: mullan Date: 2012-12-26 10:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4d28776d7007 8005117: Eliminate dependency from ConfigSpiFile to com.sun.security.auth.login.ConfigFile Reviewed-by: alanb, mchung, weijun ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/sun/security/provider/ConfigSpiFile.java Changeset: d9cab18f326a Author: mullan Date: 2012-12-26 10:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d9cab18f326a Merge - make/jdk/asm/Makefile Changeset: 9d984ccd17fc Author: chegar Date: 2012-12-27 21:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9d984ccd17fc 8003981: Support Parallel Array Sorting - JEP 103 Reviewed-by: chegar, forax, dholmes, dl Contributed-by: david.holmes at oracle.com, dl at cs.oswego.edu, chris.hegarty at oracle.com ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Arrays.java + src/share/classes/java/util/ArraysParallelSortHelpers.java + test/java/util/Arrays/ParallelSorting.java Changeset: 4ad38db38fff Author: okutsu Date: 2012-12-28 14:13 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4ad38db38fff 8005471: DateFormat: Time zone info is not localized when adapter is CLDR Reviewed-by: peytoia ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java + test/java/util/TimeZone/CLDRDisplayNamesTest.java Changeset: 1da019e7999a Author: peytoia Date: 2012-12-28 15:07 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1da019e7999a 8005277: Regression in JDK 7 in Bidi implementation Reviewed-by: okutsu ! src/share/classes/sun/text/bidi/BidiBase.java ! test/java/text/Bidi/BidiConformance.java + test/java/text/Bidi/Bug8005277.java Changeset: f3ac419e2bf0 Author: okutsu Date: 2012-12-28 16:39 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f3ac419e2bf0 8005561: typo in Calendar Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java Changeset: 645d774b683a Author: xuelei Date: 2012-12-28 00:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/645d774b683a 7109274: Restrict the use of certificates with RSA keys less than 1024 bits Summary: This restriction is applied via the Java Security property, "jdk.certpath.disabledAlgorithms". This will impact providers that adhere to this security property. Reviewed-by: mullan ! 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/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java ! test/java/security/cert/pkix/policyChanges/TestPolicy.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java + test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: 4472a641b4dc Author: xuelei Date: 2012-12-28 03:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4472a641b4dc 8003265: Need to clone array of input/output parameters Reviewed-by: mullan ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: 46675076f753 Author: sjiang Date: 2012-12-28 16:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/46675076f753 7120365: DiffHBTest.java fails due to ConcurrentModificationException Summary: The problem is from the server notification forwarder, it should use a copy of listener set to do iterate. Reviewed-by: alanb ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! test/ProblemList.txt + test/javax/management/remote/mandatory/notif/ConcurrentModificationTest.java Changeset: 0cfcba56cfa7 Author: jgish Date: 2012-12-28 18:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0cfcba56cfa7 8005594: Fix to 8003265 breaks build Summary: backout changeset 4472a641b4dc Reviewed-by: smarks, wetmore ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: ac5e29b62288 Author: smarks Date: 2012-12-28 17:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ac5e29b62288 Merge Changeset: 2a5af0f766d0 Author: lana Date: 2012-12-28 18:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2a5af0f766d0 Merge - make/jdk/asm/Makefile ! makefiles/CreateJars.gmk ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 32a57e645e01 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/32a57e645e01 Added tag jdk8-b71 for changeset 2a5af0f766d0 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:13:18 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:13:18 +0000 Subject: hg: hsx/hotspot-comp/langtools: 20 new changesets Message-ID: <20130104051412.65C734752E@hg.openjdk.java.net> Changeset: 37a5d7eccb87 Author: vromero Date: 2012-12-14 11:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/37a5d7eccb87 8004976: test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java can fail Reviewed-by: jjg, mcimadamore ! test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java Changeset: de1ec6fc93fe Author: vromero Date: 2012-12-15 13:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/de1ec6fc93fe 8000518: Javac generates duplicate name_and_type constant pool entry for class BinaryOpValueExp.java Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java + test/tools/javac/8000518/DuplicateConstantPoolEntry.java ! test/tools/javac/lambda/TestInvokeDynamic.java Changeset: f72dc656a306 Author: lana Date: 2012-12-16 22:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f72dc656a306 Merge Changeset: 02a18f209ab3 Author: vromero Date: 2012-12-17 14:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/02a18f209ab3 8004814: javadoc should be able to detect default methods Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/javadoc/ClassDoc.java ! src/share/classes/com/sun/javadoc/MethodDoc.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java Changeset: 75ab654b5cd5 Author: jjg Date: 2012-12-17 07:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/75ab654b5cd5 8004832: Add new doclint package Reviewed-by: mcimadamore ! make/build.properties ! 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/TreePath.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/Entity.java + src/share/classes/com/sun/tools/doclint/Env.java + src/share/classes/com/sun/tools/doclint/HtmlTag.java + src/share/classes/com/sun/tools/doclint/Messages.java + src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/share/classes/com/sun/tools/javac/tree/DocPretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/doclint/AccessTest.java + test/tools/doclint/AccessTest.package.out + test/tools/doclint/AccessTest.private.out + test/tools/doclint/AccessTest.protected.out + test/tools/doclint/AccessTest.public.out + test/tools/doclint/AccessibilityTest.java + test/tools/doclint/AccessibilityTest.out + test/tools/doclint/DocLintTester.java + test/tools/doclint/EmptyAuthorTest.java + test/tools/doclint/EmptyAuthorTest.out + test/tools/doclint/EmptyExceptionTest.java + test/tools/doclint/EmptyExceptionTest.out + test/tools/doclint/EmptyParamTest.java + test/tools/doclint/EmptyParamTest.out + test/tools/doclint/EmptyReturnTest.java + test/tools/doclint/EmptyReturnTest.out + test/tools/doclint/EmptySerialDataTest.java + test/tools/doclint/EmptySerialDataTest.out + test/tools/doclint/EmptySerialFieldTest.java + test/tools/doclint/EmptySerialFieldTest.out + test/tools/doclint/EmptySinceTest.java + test/tools/doclint/EmptySinceTest.out + test/tools/doclint/EmptyVersionTest.java + test/tools/doclint/EmptyVersionTest.out + test/tools/doclint/HtmlAttrsTest.java + test/tools/doclint/HtmlAttrsTest.out + test/tools/doclint/HtmlTagsTest.java + test/tools/doclint/HtmlTagsTest.out + test/tools/doclint/MissingCommentTest.java + test/tools/doclint/MissingCommentTest.out + test/tools/doclint/MissingParamsTest.java + test/tools/doclint/MissingParamsTest.out + test/tools/doclint/MissingReturnTest.java + test/tools/doclint/MissingReturnTest.out + test/tools/doclint/MissingThrowsTest.java + test/tools/doclint/MissingThrowsTest.out + test/tools/doclint/OptionTest.java + test/tools/doclint/OverridesTest.java + test/tools/doclint/ReferenceTest.java + test/tools/doclint/ReferenceTest.out + test/tools/doclint/RunTest.java + test/tools/doclint/SyntaxTest.java + test/tools/doclint/SyntaxTest.out + test/tools/doclint/SyntheticTest.java + test/tools/doclint/ValidTest.java + test/tools/doclint/tidy/AnchorAlreadyDefined.java + test/tools/doclint/tidy/AnchorAlreadyDefined.out + test/tools/doclint/tidy/BadEnd.java + test/tools/doclint/tidy/BadEnd.out + test/tools/doclint/tidy/InsertImplicit.java + test/tools/doclint/tidy/InsertImplicit.out + test/tools/doclint/tidy/InvalidEntity.java + test/tools/doclint/tidy/InvalidEntity.out + test/tools/doclint/tidy/InvalidName.java + test/tools/doclint/tidy/InvalidName.out + test/tools/doclint/tidy/InvalidTag.java + test/tools/doclint/tidy/InvalidTag.out + test/tools/doclint/tidy/InvalidURI.java + test/tools/doclint/tidy/InvalidURI.out + test/tools/doclint/tidy/MissingGT.java + test/tools/doclint/tidy/MissingGT.out + test/tools/doclint/tidy/MissingTag.java + test/tools/doclint/tidy/MissingTag.out + test/tools/doclint/tidy/NestedTag.java + test/tools/doclint/tidy/NestedTag.out + test/tools/doclint/tidy/ParaInPre.java + test/tools/doclint/tidy/ParaInPre.out + test/tools/doclint/tidy/README.txt + test/tools/doclint/tidy/RepeatedAttr.java + test/tools/doclint/tidy/RepeatedAttr.out + test/tools/doclint/tidy/TextNotAllowed.java + test/tools/doclint/tidy/TextNotAllowed.out + test/tools/doclint/tidy/TrimmingEmptyTag.java + test/tools/doclint/tidy/TrimmingEmptyTag.out + test/tools/doclint/tidy/UnescapedOrUnknownEntity.java + test/tools/doclint/tidy/UnescapedOrUnknownEntity.out + test/tools/doclint/tidy/util/Main.java + test/tools/doclint/tidy/util/tidy.sh + test/tools/javac/diags/examples/NoContent.java Changeset: f20568328a57 Author: mcimadamore Date: 2012-12-17 16:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f20568328a57 8004099: Bad compiler diagnostic generated when poly expression is passed to non-existent method Summary: Some code paths in resolve do not use methodArguments to correctly format actuals Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/BadMethodCall2.java + test/tools/javac/lambda/BadMethodCall2.out Changeset: 064e372f273d Author: jjg Date: 2012-12-17 10:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/064e372f273d 8004961: rename Plugin.call to Plugin.init Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/plugin/showtype/ShowTypePlugin.java ! test/tools/javac/plugin/showtype/Test.java Changeset: ef537bcc825a Author: mchung Date: 2012-12-17 15:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ef537bcc825a 8005137: Rename DocLint.call to DocLint.init which overrides Plugin.init Reviewed-by: darcy, jjh ! src/share/classes/com/sun/tools/doclint/DocLint.java Changeset: bc74006c2d8d Author: darcy Date: 2012-12-18 00:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/bc74006c2d8d 8005046: Provide checking for a default method in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java + test/tools/javac/processing/model/element/TestExecutableElement.java Changeset: 92fcf299cd09 Author: ohrstrom Date: 2012-12-18 10:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/92fcf299cd09 8004657: Add hooks to javac to enable reporting dependency information. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 250f0acf880c Author: mcimadamore Date: 2012-12-18 22:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/250f0acf880c 8005193: New regression test test/tools/javac/lambda/BadMethodCall2.java fails Summary: Bad golden file in negative test Reviewed-by: jjh ! test/tools/javac/lambda/BadMethodCall2.out Changeset: 573b38691a74 Author: lana Date: 2012-12-18 18:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/573b38691a74 Merge Changeset: 67b01d295cd2 Author: jjg Date: 2012-12-19 11:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/67b01d295cd2 8004833: Integrate doclint support into javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/doclint/DocLintTest.java Changeset: f72c9c5aeaef Author: jfranck Date: 2012-12-16 11:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f72c9c5aeaef 8005098: Provide isSynthesized() information on Attribute.Compound Reviewed-by: jjg ! make/build.properties ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java Changeset: a22f23fb7abf Author: jjg Date: 2012-12-20 17:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a22f23fb7abf 8005307: fix missing @bug tags Reviewed-by: jjh ! test/tools/doclint/AccessTest.java ! test/tools/doclint/AccessTest.package.out ! test/tools/doclint/AccessTest.private.out ! test/tools/doclint/AccessTest.protected.out ! test/tools/doclint/AccessTest.public.out ! test/tools/doclint/AccessibilityTest.java ! test/tools/doclint/AccessibilityTest.out ! test/tools/doclint/EmptyAuthorTest.java ! test/tools/doclint/EmptyAuthorTest.out ! test/tools/doclint/EmptyExceptionTest.java ! test/tools/doclint/EmptyExceptionTest.out ! test/tools/doclint/EmptyParamTest.java ! test/tools/doclint/EmptyParamTest.out ! test/tools/doclint/EmptyReturnTest.java ! test/tools/doclint/EmptyReturnTest.out ! test/tools/doclint/EmptySerialDataTest.java ! test/tools/doclint/EmptySerialDataTest.out ! test/tools/doclint/EmptySerialFieldTest.java ! test/tools/doclint/EmptySerialFieldTest.out ! test/tools/doclint/EmptySinceTest.java ! test/tools/doclint/EmptySinceTest.out ! test/tools/doclint/EmptyVersionTest.java ! test/tools/doclint/EmptyVersionTest.out ! test/tools/doclint/HtmlAttrsTest.java ! test/tools/doclint/HtmlAttrsTest.out ! test/tools/doclint/HtmlTagsTest.java ! test/tools/doclint/HtmlTagsTest.out ! test/tools/doclint/MissingParamsTest.java ! test/tools/doclint/MissingParamsTest.out ! test/tools/doclint/MissingReturnTest.java ! test/tools/doclint/MissingReturnTest.out ! test/tools/doclint/MissingThrowsTest.java ! test/tools/doclint/MissingThrowsTest.out ! test/tools/doclint/OptionTest.java ! test/tools/doclint/OverridesTest.java ! test/tools/doclint/ReferenceTest.java ! test/tools/doclint/ReferenceTest.out ! test/tools/doclint/RunTest.java ! test/tools/doclint/SyntaxTest.java ! test/tools/doclint/SyntaxTest.out ! test/tools/doclint/SyntheticTest.java ! test/tools/doclint/ValidTest.java ! test/tools/doclint/tidy/AnchorAlreadyDefined.java ! test/tools/doclint/tidy/AnchorAlreadyDefined.out ! test/tools/doclint/tidy/BadEnd.java ! test/tools/doclint/tidy/BadEnd.out ! test/tools/doclint/tidy/InsertImplicit.java ! test/tools/doclint/tidy/InsertImplicit.out ! test/tools/doclint/tidy/InvalidEntity.java ! test/tools/doclint/tidy/InvalidEntity.out ! test/tools/doclint/tidy/InvalidName.java ! test/tools/doclint/tidy/InvalidName.out ! test/tools/doclint/tidy/InvalidTag.java ! test/tools/doclint/tidy/InvalidTag.out ! test/tools/doclint/tidy/InvalidURI.java ! test/tools/doclint/tidy/InvalidURI.out ! test/tools/doclint/tidy/MissingGT.java ! test/tools/doclint/tidy/MissingGT.out ! test/tools/doclint/tidy/MissingTag.java ! test/tools/doclint/tidy/MissingTag.out ! test/tools/doclint/tidy/NestedTag.java ! test/tools/doclint/tidy/NestedTag.out ! test/tools/doclint/tidy/ParaInPre.java ! test/tools/doclint/tidy/ParaInPre.out ! test/tools/doclint/tidy/RepeatedAttr.java ! test/tools/doclint/tidy/RepeatedAttr.out ! test/tools/doclint/tidy/TextNotAllowed.java ! test/tools/doclint/tidy/TextNotAllowed.out ! test/tools/doclint/tidy/TrimmingEmptyTag.java ! test/tools/doclint/tidy/TrimmingEmptyTag.out ! test/tools/doclint/tidy/UnescapedOrUnknownEntity.java ! test/tools/doclint/tidy/UnescapedOrUnknownEntity.out Changeset: b52a38d4536c Author: darcy Date: 2012-12-21 08:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b52a38d4536c 8005282: Use @library tag with non-relative path for javac tests Reviewed-by: jjg ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/classreader/T7031108.java ! test/tools/javac/enum/6350057/T6350057.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/file/T7018098.java ! test/tools/javac/multicatch/model/ModelChecker.java ! test/tools/javac/options/T7022337.java ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/6359313/T6359313.java ! test/tools/javac/processing/6365040/T6365040.java ! test/tools/javac/processing/6413690/T6413690.java ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/6430209/T6430209.java ! test/tools/javac/processing/6499119/ClassProcessor.java ! test/tools/javac/processing/6511613/clss41701.java ! test/tools/javac/processing/6512707/T6512707.java ! test/tools/javac/processing/6634138/T6634138.java ! test/tools/javac/processing/6994946/SemanticErrorTest.java ! test/tools/javac/processing/6994946/SyntaxErrorTest.java ! test/tools/javac/processing/T6920317.java ! test/tools/javac/processing/T7196462.java ! test/tools/javac/processing/TestWarnErrorCount.java ! test/tools/javac/processing/environment/TestSourceVersion.java ! test/tools/javac/processing/environment/round/TestContext.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/processing/errors/TestErrorCount.java ! test/tools/javac/processing/errors/TestFatalityOfParseErrors.java ! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/tools/javac/processing/errors/TestParseErrors/TestParseErrors.java ! test/tools/javac/processing/errors/TestReturnCode.java ! test/tools/javac/processing/filer/TestFilerConstraints.java ! test/tools/javac/processing/filer/TestGetResource.java ! test/tools/javac/processing/filer/TestGetResource2.java ! test/tools/javac/processing/filer/TestInvalidRelativeNames.java ! test/tools/javac/processing/filer/TestLastRound.java ! test/tools/javac/processing/filer/TestPackageInfo.java ! test/tools/javac/processing/filer/TestValidRelativeNames.java ! test/tools/javac/processing/messager/6362067/T6362067.java ! test/tools/javac/processing/messager/MessagerBasics.java ! test/tools/javac/processing/model/6194785/T6194785.java ! test/tools/javac/processing/model/6341534/T6341534.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/processing/model/element/TestElement.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingClass.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java ! test/tools/javac/processing/model/element/TestNames.java ! test/tools/javac/processing/model/element/TestPackageElement.java ! test/tools/javac/processing/model/element/TestResourceElement.java ! test/tools/javac/processing/model/element/TestResourceVariable.java ! test/tools/javac/processing/model/element/TestTypeParameter.java ! test/tools/javac/processing/model/element/TypeParamBounds.java ! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java ! test/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/type/TestUnionType.java ! test/tools/javac/processing/model/util/BinaryName.java ! test/tools/javac/processing/model/util/GetTypeElemBadArg.java ! test/tools/javac/processing/model/util/NoSupers.java ! test/tools/javac/processing/model/util/OverridesSpecEx.java ! test/tools/javac/processing/model/util/TypesBadArg.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java ! test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java ! test/tools/javac/processing/model/util/elements/TestGetPackageOf.java ! test/tools/javac/processing/model/util/filter/TestIterables.java ! test/tools/javac/processing/options/testCommandLineClasses/Test.java ! test/tools/javac/processing/options/testPrintProcessorInfo/Test.java ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java ! test/tools/javac/processing/warnings/UseImplicit/TestProcUseImplicitWarning.java ! test/tools/javac/processing/werror/WError1.java ! test/tools/javac/processing/werror/WErrorGen.java ! test/tools/javac/processing/werror/WErrorLast.java ! test/tools/javac/resolve/ResolveHarness.java ! test/tools/javac/util/T6597678.java ! test/tools/javac/util/context/T7021650.java Changeset: 189b26e3818f Author: vromero Date: 2012-12-21 15:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/189b26e3818f 8003512: javac doesn't work with jar files with >64k entries Reviewed-by: jjg, ksrini Contributed-by: martinrb at google.com ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java + test/tools/javac/file/zip/8003512/LoadClassFromJava6CreatedJarTest.java ! test/tools/javac/file/zip/Utils.java Changeset: 690c41cdab55 Author: bpatel Date: 2012-12-25 17:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/690c41cdab55 8004893: the javadoc/doclet needs to be updated to accommodate lambda changes Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodTypes.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java + test/com/sun/javadoc/testLambdaFeature/pkg/A.java + test/com/sun/javadoc/testLambdaFeature/pkg/B.java ! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java Changeset: 467e4d9281bc Author: lana Date: 2012-12-28 18:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/467e4d9281bc Merge ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 6f0986ed9b7e Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6f0986ed9b7e Added tag jdk8-b71 for changeset 467e4d9281bc ! .hgtags From christian.thalinger at oracle.com Mon Jan 7 14:44:23 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 14:44:23 -0800 Subject: 8005816: Shark: fix volatile float field access [Was: Re: RFR: Fix volatile float field access in Shark] In-Reply-To: <1354826881.1747.39.camel@mercury> References: <1354826881.1747.39.camel@mercury> Message-ID: <602E0D4F-5E2D-43CD-B29C-AE35ACF6C79C@oracle.com> 8005816: Shark: fix volatile float field access On Dec 6, 2012, at 12:48 PM, Roman Kennke wrote: > One of the jtreg tests (test/compiler/6796786/Test6796786.java) was > failing with Shark because LLVM could not compile atomic load/store for > float (and double). This change inserts a bitcast to the int type with > same width. > > http://cr.openjdk.java.net/~rkennke/shark-atomic/webrev/ > > Ok to go in? > > Roman > > From christian.thalinger at oracle.com Mon Jan 7 14:49:10 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 14:49:10 -0800 Subject: 8005817: Shark: implement deoptimization support [Was: Re: RFR: Implement deoptimization support in Shark] In-Reply-To: <1354826598.1747.36.camel@mercury> References: <1354826598.1747.36.camel@mercury> Message-ID: <3B01360B-912D-45DE-A66A-E6B8AB3AAEE4@oracle.com> 8005817: Shark: implement deoptimization support On Dec 6, 2012, at 12:43 PM, Roman Kennke wrote: > This change implements support for method deoptimization in Shark, and > thus (re-) enables an optimization for potentially inlining virtual > methods. > > http://cr.openjdk.java.net/~rkennke/shark-deopt/webrev.01/ > > This optimization has been enabled before, a while ago, but has been > disabled because it leads to segmentation faults: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=481 > > I used the testcase in the above bugreport (one of the jtreg tests in > jdk) to verify that the change does indeed deoptimize (and re-compile) > methods correctly. Besides that, no regressions could be found in > hotspot/test/compiler (and a bunch of other tests and programs I've been > running, including SpecJVM, Eclipse, etc). > > Ok to go in? > > Cheers, > Roman > > From christian.thalinger at oracle.com Mon Jan 7 14:50:06 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 14:50:06 -0800 Subject: 8005818: Shark: fix OSR for non-empty incoming stack [Was: Re: RFR: Fix OSR in Shark for non-empty incoming stack] In-Reply-To: <1354825849.1747.28.camel@mercury> References: <1354825849.1747.28.camel@mercury> Message-ID: <2CE5E014-D172-4AEB-A01C-0AE20B4861D8@oracle.com> 8005818: Shark: fix OSR for non-empty incoming stack On Dec 6, 2012, at 12:30 PM, Roman Kennke wrote: > This patch disables on-stack-replacement in Shark when the incoming > stack-depth is > 0. (This caused a segmentation fault when running > SpecJVM.) > > http://cr.openjdk.java.net/~rkennke/shark-osr/webrev.00/ > > I tried to figure out what to do in that case for a while, until I > looked at opto which simply bails out, so I decided to do the same. Is > there anything better that could be done without huge efforts (it seems > to happen very rarely after all)? > > Ok to go in? > > (I have a bunch of patches coming up for Shark, I was undecided if I > should post them as one big or several smaller patches, and then found > that having several unrelated things interleaved in one patch makes it > really difficult to understand what it does.) > > Regards, > Roman > > From christian.thalinger at oracle.com Mon Jan 7 14:51:56 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 14:51:56 -0800 Subject: 8005820: Shark: enable JSR292 support [Re: Enable JSR292 support in Shark] In-Reply-To: <1355169605.1747.117.camel@mercury> References: <1354827728.1747.50.camel@mercury> <1354835310.1747.64.camel@mercury> <1355169605.1747.117.camel@mercury> Message-ID: <4E4C0FAC-0301-4510-A750-BF7A4AEFF49B@oracle.com> 8005820: Shark: enable JSR292 support On Dec 10, 2012, at 12:00 PM, Roman Kennke wrote: > Am Freitag, den 07.12.2012, 16:06 -0800 schrieb John Rose: >> On Dec 6, 2012, at 3:08 PM, Roman Kennke wrote: >> >>> Thanks a lot for your explanations, it's really helpful. I would >>> like to >>> (potentially) contribute to the HSI wiki, if you want to give me >>> access :-) >> >> Good! Is rkennke at gmail.com your Oracle SSO login? If so I'll add you >> to the wiki editors. If not, let me know the login you'll be using >> with the wiki. ? John > > My Oracle login is roman at kennke.org . Thanks for adding me! > > About the patches, do I need to do anything? Should I enter them in > OpenJDK bugzilla or how can I move them forward? > > Roman > > From vladimir.kozlov at oracle.com Mon Jan 7 15:26:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Jan 2013 15:26:52 -0800 Subject: RFR (M): 8005419: Improve intrinsics code performance on x86 by using AVX2 Message-ID: <50EB59BC.4040306@oracle.com> http://cr.openjdk.java.net/~kvn/8005419/webrev/ Use 256bit (AVX2) vpxor,vptest instructions in String.compareTo() and equals() intrinsics. Added jtreg test. Ran compiler regression tests and ctw. Thanks, Vladimir From christian.thalinger at oracle.com Mon Jan 7 16:09:05 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 08 Jan 2013 00:09:05 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8004537: replace AbstractAssembler emit_long with emit_int32 Message-ID: <20130108000912.6B054470D1@hg.openjdk.java.net> Changeset: ffa87474d7a4 Author: twisti Date: 2013-01-07 14:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ffa87474d7a4 8004537: replace AbstractAssembler emit_long with emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.hpp From christian.thalinger at oracle.com Mon Jan 7 16:15:41 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 16:15:41 -0800 Subject: RFR (M): 8005419: Improve intrinsics code performance on x86 by using AVX2 In-Reply-To: <50EB59BC.4040306@oracle.com> References: <50EB59BC.4040306@oracle.com> Message-ID: <3FCE894E-A822-4AF3-B3B5-16C9D0A0F757@oracle.com> On Jan 7, 2013, at 3:26 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8005419/webrev/ > > Use 256bit (AVX2) vpxor,vptest instructions in String.compareTo() and equals() intrinsics. > > Added jtreg test. > > Ran compiler regression tests and ctw. src/cpu/x86/vm/macroAssembler_x86.cpp: One thing I don't like are the upper-case names for labels. I would prefer L_foo as we do in other code. But I see we are already using it in near-by code. Oh well. test/compiler/8005419/Test8005419.java: Is there a reason why we pass in -Xmx64m? Otherwise this looks good. -- Chris > > Thanks, > Vladimir From christian.thalinger at oracle.com Mon Jan 7 16:28:05 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 16:28:05 -0800 Subject: RFR (M): 8005418: JSR 292: virtual dispatch bug in 292 impl Message-ID: <52090273-E391-48DB-BECC-B0DD5A2F33B6@oracle.com> http://cr.openjdk.java.net/~twisti/8005418 8005418: JSR 292: virtual dispatch bug in 292 impl Reviewed-by: The logic in CallGenerator::for_method_handle_inline does not pass call_is_virtual correctly. Currently target->is_abstract() is used as a workaround. The fix is to do the same thing as Parse::do_call is doing. src/share/vm/opto/callGenerator.cpp src/share/vm/opto/compile.hpp src/share/vm/opto/doCall.cpp src/share/vm/opto/parse.hpp src/share/vm/opto/parse1.cpp From headius at headius.com Mon Jan 7 16:42:42 2013 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 7 Jan 2013 18:42:42 -0600 Subject: Virtual dispatch bug in 292 impl In-Reply-To: References: <62ECFA9C-7CBC-444B-8038-357F19C00289@oracle.com> Message-ID: A quick test of the fix Christian gave me seems to indicate that things are working. Yay! Will try running our comprehensive "all" suite this evening. - Charlie On Thu, Jan 3, 2013 at 2:24 PM, Charles Oliver Nutter wrote: > Sorry I lost track of this thread going into the holidays...I talked > to Christian a moment ago but I reply here for the record... > > Christian Thalinger wrote: >>> I filed: >>> >>> https://jbs.oracle.com/bugs/browse/JDK-8005418 >>> >>> But it seems to be C2, not C1: > > Does look that way in your output. I'll leave it in your hands. I will > say I am almost positive that when I ran with tier=1 it failed, and > -tiered worked ok, but I don't have the output in front of me. > >> What's the name of the [] implementation of ENV? Is it StringOnlyRubyHash.op_aref? > > Yes, that's the one. The handle points at the superclass impl, > RubyHash.op_aref, and that's the one that gets hit instead of the > override. > >> Could this be the compile that goes wrong? >> >> 12903 956 java.lang.invoke.LambdaForm$MH/847376::convert (52 bytes) >> @ 15 java.lang.invoke.LambdaForm$BMH/23638730::reinvoke (26 bytes) inline (hot) >> @ 12 java.lang.invoke.BoundMethodHandle$Species_LL::reinvokerTarget (8 bytes) inline (hot) >> @ 22 java.lang.invoke.LambdaForm$DMH/20340225::invokeStatic_LL_L (15 bytes) inline (hot) >> @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) inline (hot) >> @ 11 sun.invoke.util.ValueConversions::castReference (6 bytes) inline (hot) >> @ 2 java.lang.Class::cast (27 bytes) inline (hot) >> @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) >> @ 33 java.lang.Class::cast (27 bytes) inline (hot) >> @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) >> @ 43 java.lang.Class::cast (27 bytes) inline (hot) >> @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) >> @ 48 java.lang.invoke.LambdaForm$DMH/32367447::invokeVirtual_LLL_L (18 bytes) inline (hot) >> @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) inline (hot) >> @ 14 org.jruby.RubyHash::op_aref (23 bytes) inline (hot) > > This looks like what I saw while debugging, yes. Not sure if this > exact output is right because there's not much context, but I did see > the call that *should* have been going to StringOnlyRubyHash.op_aref > going to RubyHash.op_aref. > > There aren't many such cases in JRuby...most overrides are accompanied > by an override in the Ruby class structures, so the child class has > its own handle pointing at the override. That's probably why we don't > see it in more places. > > I have not retested with any of the recent work on partial inlining, > etc. Since it looks like you're able to reproduce it ok, I'll leave it > in your hands. Let me know what else I can do. > > - Charlie From vladimir.kozlov at oracle.com Mon Jan 7 16:46:44 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Jan 2013 16:46:44 -0800 Subject: RFR (M): 8005419: Improve intrinsics code performance on x86 by using AVX2 In-Reply-To: <3FCE894E-A822-4AF3-B3B5-16C9D0A0F757@oracle.com> References: <50EB59BC.4040306@oracle.com> <3FCE894E-A822-4AF3-B3B5-16C9D0A0F757@oracle.com> Message-ID: <50EB6C74.3010402@oracle.com> Thanks, Christian On 1/7/13 4:15 PM, Christian Thalinger wrote: > > On Jan 7, 2013, at 3:26 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8005419/webrev/ >> >> Use 256bit (AVX2) vpxor,vptest instructions in String.compareTo() and equals() intrinsics. >> >> Added jtreg test. >> >> Ran compiler regression tests and ctw. > > src/cpu/x86/vm/macroAssembler_x86.cpp: > > One thing I don't like are the upper-case names for labels. I would prefer L_foo as we do in other code. But I see we are already using it in near-by code. Oh well. I would like to avoid clean up for now. > > test/compiler/8005419/Test8005419.java: > > Is there a reason why we pass in -Xmx64m? The test uses very little memory but by default with 64bit VM it can take Gbytes by default. It will spend more time initializing java heap than running the test. Thanks, Vladimir > > Otherwise this looks good. > > -- Chris > >> >> Thanks, >> Vladimir > From christian.thalinger at oracle.com Mon Jan 7 16:59:38 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 16:59:38 -0800 Subject: Virtual dispatch bug in 292 impl In-Reply-To: References: <62ECFA9C-7CBC-444B-8038-357F19C00289@oracle.com> Message-ID: <5BE8D856-7EEC-4DA7-9324-D149E5E46455@oracle.com> On Jan 7, 2013, at 4:42 PM, Charles Oliver Nutter wrote: > A quick test of the fix Christian gave me seems to indicate that > things are working. Yay! Thanks for verifying. > > Will try running our comprehensive "all" suite this evening. Please also look out for performance regressions. I've found at least one with Nashorn. -- Chris > > - Charlie > > On Thu, Jan 3, 2013 at 2:24 PM, Charles Oliver Nutter > wrote: >> Sorry I lost track of this thread going into the holidays...I talked >> to Christian a moment ago but I reply here for the record... >> >> Christian Thalinger wrote: >>>> I filed: >>>> >>>> https://jbs.oracle.com/bugs/browse/JDK-8005418 >>>> >>>> But it seems to be C2, not C1: >> >> Does look that way in your output. I'll leave it in your hands. I will >> say I am almost positive that when I ran with tier=1 it failed, and >> -tiered worked ok, but I don't have the output in front of me. >> >>> What's the name of the [] implementation of ENV? Is it StringOnlyRubyHash.op_aref? >> >> Yes, that's the one. The handle points at the superclass impl, >> RubyHash.op_aref, and that's the one that gets hit instead of the >> override. >> >>> Could this be the compile that goes wrong? >>> >>> 12903 956 java.lang.invoke.LambdaForm$MH/847376::convert (52 bytes) >>> @ 15 java.lang.invoke.LambdaForm$BMH/23638730::reinvoke (26 bytes) inline (hot) >>> @ 12 java.lang.invoke.BoundMethodHandle$Species_LL::reinvokerTarget (8 bytes) inline (hot) >>> @ 22 java.lang.invoke.LambdaForm$DMH/20340225::invokeStatic_LL_L (15 bytes) inline (hot) >>> @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) inline (hot) >>> @ 11 sun.invoke.util.ValueConversions::castReference (6 bytes) inline (hot) >>> @ 2 java.lang.Class::cast (27 bytes) inline (hot) >>> @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) >>> @ 33 java.lang.Class::cast (27 bytes) inline (hot) >>> @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) >>> @ 43 java.lang.Class::cast (27 bytes) inline (hot) >>> @ 6 java.lang.Class::isInstance (0 bytes) (intrinsic) >>> @ 48 java.lang.invoke.LambdaForm$DMH/32367447::invokeVirtual_LLL_L (18 bytes) inline (hot) >>> @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) inline (hot) >>> @ 14 org.jruby.RubyHash::op_aref (23 bytes) inline (hot) >> >> This looks like what I saw while debugging, yes. Not sure if this >> exact output is right because there's not much context, but I did see >> the call that *should* have been going to StringOnlyRubyHash.op_aref >> going to RubyHash.op_aref. >> >> There aren't many such cases in JRuby...most overrides are accompanied >> by an override in the Ruby class structures, so the child class has >> its own handle pointing at the override. That's probably why we don't >> see it in more places. >> >> I have not retested with any of the recent work on partial inlining, >> etc. Since it looks like you're able to reproduce it ok, I'll leave it >> in your hands. Let me know what else I can do. >> >> - Charlie From christian.thalinger at oracle.com Mon Jan 7 17:07:42 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 17:07:42 -0800 Subject: RFR (M): 8005419: Improve intrinsics code performance on x86 by using AVX2 In-Reply-To: <50EB6C74.3010402@oracle.com> References: <50EB59BC.4040306@oracle.com> <3FCE894E-A822-4AF3-B3B5-16C9D0A0F757@oracle.com> <50EB6C74.3010402@oracle.com> Message-ID: On Jan 7, 2013, at 4:46 PM, Vladimir Kozlov wrote: > Thanks, Christian > > On 1/7/13 4:15 PM, Christian Thalinger wrote: >> >> On Jan 7, 2013, at 3:26 PM, Vladimir Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/8005419/webrev/ >>> >>> Use 256bit (AVX2) vpxor,vptest instructions in String.compareTo() and equals() intrinsics. >>> >>> Added jtreg test. >>> >>> Ran compiler regression tests and ctw. >> >> src/cpu/x86/vm/macroAssembler_x86.cpp: >> >> One thing I don't like are the upper-case names for labels. I would prefer L_foo as we do in other code. But I see we are already using it in near-by code. Oh well. > > I would like to avoid clean up for now. Sure. I was just nit-picking. > >> >> test/compiler/8005419/Test8005419.java: >> >> Is there a reason why we pass in -Xmx64m? > > The test uses very little memory but by default with 64bit VM it can take Gbytes by default. It will spend more time initializing java heap than running the test. You mean ergonomics. Okay. -- Chris > > Thanks, > Vladimir > >> >> Otherwise this looks good. >> >> -- Chris >> >>> >>> Thanks, >>> Vladimir >> From vladimir.kozlov at oracle.com Mon Jan 7 17:48:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Jan 2013 17:48:01 -0800 Subject: RFR (M): 8005418: JSR 292: virtual dispatch bug in 292 impl In-Reply-To: <52090273-E391-48DB-BECC-B0DD5A2F33B6@oracle.com> References: <52090273-E391-48DB-BECC-B0DD5A2F33B6@oracle.com> Message-ID: <50EB7AD1.5060608@oracle.com> Seems fine to me. I wish the code for_method_handle_inline() was in doCall.cpp instead of callGenerator.cpp. Originally for_*() method were used only for corresponding *Generator instance creation. Thanks, Vladimir On 1/7/13 4:28 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8005418 > > 8005418: JSR 292: virtual dispatch bug in 292 impl > Reviewed-by: > > The logic in CallGenerator::for_method_handle_inline does not pass > call_is_virtual correctly. Currently target->is_abstract() is used as > a workaround. > > The fix is to do the same thing as Parse::do_call is doing. > > src/share/vm/opto/callGenerator.cpp > src/share/vm/opto/compile.hpp > src/share/vm/opto/doCall.cpp > src/share/vm/opto/parse.hpp > src/share/vm/opto/parse1.cpp > From christian.thalinger at oracle.com Mon Jan 7 18:37:08 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 18:37:08 -0800 Subject: RFR (M): 8005418: JSR 292: virtual dispatch bug in 292 impl In-Reply-To: <50EB7AD1.5060608@oracle.com> References: <52090273-E391-48DB-BECC-B0DD5A2F33B6@oracle.com> <50EB7AD1.5060608@oracle.com> Message-ID: <6A8C4B83-94CD-4972-9C63-0C4190DFE0F5@oracle.com> On Jan 7, 2013, at 5:48 PM, Vladimir Kozlov wrote: > Seems fine to me. I wish the code for_method_handle_inline() was in doCall.cpp instead of callGenerator.cpp. Originally for_*() method were used only for corresponding *Generator instance creation. Perhaps. At least the method is a member of CallGenerator. I'm always confused when I find Foo::* methods in bar.cpp. Thanks for the review. -- Chris > > Thanks, > Vladimir > > On 1/7/13 4:28 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8005418 >> >> 8005418: JSR 292: virtual dispatch bug in 292 impl >> Reviewed-by: >> >> The logic in CallGenerator::for_method_handle_inline does not pass >> call_is_virtual correctly. Currently target->is_abstract() is used as >> a workaround. >> >> The fix is to do the same thing as Parse::do_call is doing. >> >> src/share/vm/opto/callGenerator.cpp >> src/share/vm/opto/compile.hpp >> src/share/vm/opto/doCall.cpp >> src/share/vm/opto/parse.hpp >> src/share/vm/opto/parse1.cpp >> From forax at univ-mlv.fr Tue Jan 8 00:28:16 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 08 Jan 2013 09:28:16 +0100 Subject: 8005818: Shark: fix OSR for non-empty incoming stack [Was: Re: RFR: Fix OSR in Shark for non-empty incoming stack] In-Reply-To: <2CE5E014-D172-4AEB-A01C-0AE20B4861D8@oracle.com> References: <1354825849.1747.28.camel@mercury> <2CE5E014-D172-4AEB-A01C-0AE20B4861D8@oracle.com> Message-ID: <50EBD8A0.9090909@univ-mlv.fr> On 01/07/2013 11:50 PM, Christian Thalinger wrote: > 8005818: Shark: fix OSR for non-empty incoming stack > > On Dec 6, 2012, at 12:30 PM, Roman Kennke wrote: > >> This patch disables on-stack-replacement in Shark when the incoming >> stack-depth is > 0. (This caused a segmentation fault when running >> SpecJVM.) >> >> http://cr.openjdk.java.net/~rkennke/shark-osr/webrev.00/ >> >> I tried to figure out what to do in that case for a while, until I >> looked at opto which simply bails out, so I decided to do the same. Is >> there anything better that could be done without huge efforts (it seems >> to happen very rarely after all)? I believe it can not append with bytecode generated by javac, but may happen with compilers of languages that consider that that a loop is an expression. >> >> Ok to go in? >> >> (I have a bunch of patches coming up for Shark, I was undecided if I >> should post them as one big or several smaller patches, and then found >> that having several unrelated things interleaved in one patch makes it >> really difficult to understand what it does.) >> >> Regards, >> Roman >> >> cheers, R?mi From vitalyd at gmail.com Tue Jan 8 04:40:12 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 8 Jan 2013 07:40:12 -0500 Subject: RFR (M): 8005419: Improve intrinsics code performance on x86 by using AVX2 In-Reply-To: <50EB59BC.4040306@oracle.com> References: <50EB59BC.4040306@oracle.com> Message-ID: Hi Vladimir, Minor spacing issue in macro assembler_x86.hpp: 5699 int adr_stride = stride < wrote: > http://cr.openjdk.java.net/~**kvn/8005419/webrev/ > > Use 256bit (AVX2) vpxor,vptest instructions in String.compareTo() and > equals() intrinsics. > > Added jtreg test. > > Ran compiler regression tests and ctw. > > Thanks, > Vladimir > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130108/bb4eafa9/attachment.html From vladimir.kozlov at oracle.com Tue Jan 8 08:11:49 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Jan 2013 08:11:49 -0800 Subject: RFR (M): 8005419: Improve intrinsics code performance on x86 by using AVX2 In-Reply-To: References: <50EB59BC.4040306@oracle.com> Message-ID: <50EC4545.1060306@oracle.com> Thanks, Vitaly Vladimir On 1/8/13 4:40 AM, Vitaly Davidovich wrote: > Hi Vladimir, > > Minor spacing issue in macro assembler_x86.hpp: > > 5699 int adr_stride = stride < > Thanks > > Sent from my phone > > On Jan 7, 2013 6:27 PM, "Vladimir Kozlov" > wrote: > > http://cr.openjdk.java.net/~__kvn/8005419/webrev/ > > > Use 256bit (AVX2) vpxor,vptest instructions in String.compareTo() > and equals() intrinsics. > > Added jtreg test. > > Ran compiler regression tests and ctw. > > Thanks, > Vladimir > From vitalyd at gmail.com Tue Jan 8 08:19:32 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 8 Jan 2013 11:19:32 -0500 Subject: RFR (M): 8005419: Improve intrinsics code performance on x86 by using AVX2 In-Reply-To: <50EC4545.1060306@oracle.com> References: <50EB59BC.4040306@oracle.com> <50EC4545.1060306@oracle.com> Message-ID: No problem. I mistakenly said it's in the header but I meant the cpp file of course. Sent from my phone On Jan 8, 2013 11:11 AM, "Vladimir Kozlov" wrote: > Thanks, Vitaly > > Vladimir > > On 1/8/13 4:40 AM, Vitaly Davidovich wrote: > >> Hi Vladimir, >> >> Minor spacing issue in macro assembler_x86.hpp: >> >> 5699 int adr_stride = stride <> >> Thanks >> >> Sent from my phone >> >> On Jan 7, 2013 6:27 PM, "Vladimir Kozlov" > >> >> wrote: >> >> http://cr.openjdk.java.net/~__**kvn/8005419/webrev/ >> >> > >> >> Use 256bit (AVX2) vpxor,vptest instructions in String.compareTo() >> and equals() intrinsics. >> >> Added jtreg test. >> >> Ran compiler regression tests and ctw. >> >> Thanks, >> Vladimir >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130108/128937b2/attachment.html From vladimir.kozlov at oracle.com Tue Jan 8 15:18:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Jan 2013 15:18:13 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 Message-ID: <50ECA935.2030703@oracle.com> http://cr.openjdk.java.net/~kvn/6896617_jdk/webrev Move encoding loop into separate method for which VM will use intrinsic on x86. I want to get agreement on this jdk change before I submit VM part. This gives +1.6% performance improvement on SPECjAppServer2004 on x86. Note, even without intrinsic (on other platforms) JIT will produce better code for this loop. Thanks, Vladimir From vitalyd at gmail.com Tue Jan 8 16:10:13 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 8 Jan 2013 19:10:13 -0500 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50ECA935.2030703@oracle.com> References: <50ECA935.2030703@oracle.com> Message-ID: Hi Vladimir, encodeArray can be made static. Also, what's the purpose of overflow flag? Once you detect overflow can't you simply return the overflow result? What's the key piece that allows jit to generate better code? Is it the encodeArray which is nice, small, and isolated? Thanks Sent from my phone On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" wrote: > http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev > > Move encoding loop into separate method for which VM will use intrinsic on > x86. I want to get agreement on this jdk change before I submit VM part. > > This gives +1.6% performance improvement on SPECjAppServer2004 on x86. > Note, even without intrinsic (on other platforms) JIT will produce better > code for this loop. > > Thanks, > Vladimir > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130108/43ae619f/attachment.html From vladimir.kozlov at oracle.com Tue Jan 8 16:35:17 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Jan 2013 16:35:17 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> Message-ID: <50ECBB45.7090705@oracle.com> On 1/8/13 4:10 PM, Vitaly Davidovich wrote: > Hi Vladimir, > > encodeArray can be made static. > > Also, what's the purpose of overflow flag? Once you detect overflow > can't you simply return the overflow result? No, we can't just exit, we have to encode everything (write to destination byte[] array) up to that limit because it could exit before that. I have to keep original logic intact. > > What's the key piece that allows jit to generate better code? Is it the > encodeArray which is nice, small, and isolated? Correct. Original loop has a lot of checks, calls, several exits ('break' in new loop is fine) which will prevent execution of loop optimizations. Thanks, Vlaidmir > > Thanks > > Sent from my phone > > On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" > wrote: > > http://cr.openjdk.java.net/~__kvn/6896617_jdk/webrev > > > Move encoding loop into separate method for which VM will use > intrinsic on x86. I want to get agreement on this jdk change before > I submit VM part. > > This gives +1.6% performance improvement on SPECjAppServer2004 on x86. > Note, even without intrinsic (on other platforms) JIT will produce > better code for this loop. > > Thanks, > Vladimir > From vitalyd at gmail.com Tue Jan 8 16:40:52 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 8 Jan 2013 19:40:52 -0500 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50ECBB45.7090705@oracle.com> References: <50ECA935.2030703@oracle.com> <50ECBB45.7090705@oracle.com> Message-ID: Got it, thanks. Sent from my phone On Jan 8, 2013 7:35 PM, "Vladimir Kozlov" wrote: > On 1/8/13 4:10 PM, Vitaly Davidovich wrote: > >> Hi Vladimir, >> >> encodeArray can be made static. >> >> Also, what's the purpose of overflow flag? Once you detect overflow >> can't you simply return the overflow result? >> > > No, we can't just exit, we have to encode everything (write to destination > byte[] array) up to that limit because it could exit before that. I have to > keep original logic intact. > > >> What's the key piece that allows jit to generate better code? Is it the >> encodeArray which is nice, small, and isolated? >> > > Correct. Original loop has a lot of checks, calls, several exits ('break' > in new loop is fine) which will prevent execution of loop optimizations. > > Thanks, > Vlaidmir > > >> Thanks >> >> Sent from my phone >> >> On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" > >> >> wrote: >> >> http://cr.openjdk.java.net/~__**kvn/6896617_jdk/webrev >> >> > >> >> Move encoding loop into separate method for which VM will use >> intrinsic on x86. I want to get agreement on this jdk change before >> I submit VM part. >> >> This gives +1.6% performance improvement on SPECjAppServer2004 on x86. >> Note, even without intrinsic (on other platforms) JIT will produce >> better code for this loop. >> >> Thanks, >> Vladimir >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130108/445efa76/attachment.html From vladimir.kozlov at oracle.com Tue Jan 8 17:08:50 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 09 Jan 2013 01:08:50 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8005419: Improve intrinsics code performance on x86 by using AVX2 Message-ID: <20130109010852.415574711F@hg.openjdk.java.net> Changeset: 038dd2875b94 Author: kvn Date: 2013-01-08 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/038dd2875b94 8005419: Improve intrinsics code performance on x86 by using AVX2 Summary: use 256bit vpxor,vptest instructions in String.compareTo() and equals() intrinsics. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp + test/compiler/8005419/Test8005419.java From david.holmes at oracle.com Wed Jan 9 02:55:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Jan 2013 20:55:18 +1000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50D36104.8000701@oracle.com> References: <50D36104.8000701@oracle.com> Message-ID: <50ED4C96.6070205@oracle.com> Aleksey, Not sure where this is now but FYI you needed two CRs for this: one for hotspot and one for the JDK. They have different target versions (hs25 vs 8) and depending on the path you use to integrate could end up in different builds - hence distinct CRs for accurate tracking purposes. I have a concern that the Long versions of these methods may be used directly without there being any check for supports_cx8 David On 21/12/2012 5:03 AM, Aleksey Shipilev wrote: > Hi, > > Sorry for cross-list posting, but this change affects both HS and JDK. > > This simple change is missing from recently committed CR 7023898. While > the VM support is there in Hotspot, no methods are exposed in Unsafe to > actually make use of those intrinsics. This is the webrev fixing that: > http://cr.openjdk.java.net/~shade/8004330/webrev.00/ > > It turns out the getAndSet intrinsics HotSpot are overloaded, which had > deluged both Doug and me in the previous patch. These namings are > inconsistent with other Unsafe intrinsic naming convention, so this > change fixes that as well. > > Testing: > - Built and tested in Linux x86_64 > - java-concurrency-torture [1] atomicity tests are passed for > AtomicIntegerV8 [2] and AtomicLongV8 [3] making use of those intrinsics > on Linux x86_64 > - running the java-concurrency-torture tests "-XX:+PrintInlining | > grep Unsafe" tells all intrinsics have been successfully inlined > - no other testing is expected for this trivial change. > > I would need a sponsor to push this. Thanks for your patience and reviews! > > Contributors: > - dl: original patch, testing > - shade: due diligence, messing with reviews, tests, and rebuilds > > -Aleksey. > > [1] https://github.com/shipilev/java-concurrency-torture/ > [2] > https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java > [3] > https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/longs/AtomicLongV8PairwiseTests.java > From aleksey.shipilev at oracle.com Wed Jan 9 03:04:57 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 15:04:57 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED4C96.6070205@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> Message-ID: <50ED4ED9.60102@oracle.com> Thanks, David. On 01/09/2013 02:55 PM, David Holmes wrote: > Not sure where this is now but FYI you needed two CRs for this: one for > hotspot and one for the JDK. They have different target versions (hs25 > vs 8) and depending on the path you use to integrate could end up in > different builds - hence distinct CRs for accurate tracking purposes. Too late, since these are already committed? I can submit another CR if we need that. > I have a concern that the Long versions of these methods may be used > directly without there being any check for supports_cx8 I actually have the question about this. What is the usual pattern for using AtomicLong.VM_SUPPORTS_LONG_CAS? AtomicLong seems to use Unsafe directly without the checks. AtomicLongFieldUpdater does the checks. Something is fishy about this whole thing. I think this one tries to explain something, but I fail to grasp the intent: /** * Records whether the underlying JVM supports lockless * compareAndSwap for longs. While the Unsafe.compareAndSwapLong * method works in either case, some constructions should be * handled at Java level to avoid locking user-visible locks. */ static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8(); Doug? -Aleksey. From Ulf.Zibis at CoSoCo.de Wed Jan 9 03:08:09 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 09 Jan 2013 12:08:09 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> Message-ID: <50ED4F99.7030202@CoSoCo.de> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: > Hi Vladimir, > > encodeArray can be made static. > > Also, what's the purpose of overflow flag? Once you detect overflow can't > you simply return the overflow result? > > What's the key piece that allows jit to generate better code? Is it the > encodeArray which is nice, small, and isolated? > > Thanks > > Sent from my phone > On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" > wrote: > >> http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev I would code: 153 int i; 154 for (i = 0; i < len; i++) { 155 char c = sa[sp++]; 156 if (c > '\u00FF') 157 break; 158 da[dp++] = (byte)c; 159 } -Ulf From Ulf.Zibis at CoSoCo.de Wed Jan 9 03:58:48 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 09 Jan 2013 12:58:48 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> Message-ID: <50ED5B78.2040309@CoSoCo.de> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: > On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" > wrote: > >> http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev Another tweak: 168 char[] sa = src.array(); 169 int sp = src.arrayOffset() + src.position(); 170 int sr = src.remaining(); 171 int sl = sp + sr; 172 assert (sp <= sl); // superfluous, sr is always >= 0 173 sp = (sp <= sl ? sp : sl); // superfluous " 174 byte[] da = dst.array(); 175 int dp = dst.arrayOffset() + dst.position(); 170 int dr = dst.remaining(); 176 int dl = dp + dr; 177 assert (dp <= dl); // superfluous " 178 dp = (dp <= dl ? dp : dl); // superfluous " 179 boolean overflow = false; 180 if (sr > dr) { 181 sr = dr; 182 overflow = true; 183 } Why you called it "overflowflag", in that way, you could name each variable "myvaluevariable" or "myvaluefield" ;-) -Ulf From aleksey.shipilev at oracle.com Wed Jan 9 04:27:13 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 16:27:13 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED61FA.2060900@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED61FA.2060900@oracle.com> Message-ID: <50ED6221.2020902@oracle.com> On 01/09/2013 04:26 PM, Chris Hegarty wrote: > On 09/01/2013 11:04, Aleksey Shipilev wrote: >> Thanks, David. >> >> On 01/09/2013 02:55 PM, David Holmes wrote: >>> Not sure where this is now but FYI you needed two CRs for this: one for >>> hotspot and one for the JDK. They have different target versions (hs25 >>> vs 8) and depending on the path you use to integrate could end up in >>> different builds - hence distinct CRs for accurate tracking purposes. >> >> Too late, since these are already committed? I can submit another CR if >> we need that. > > Since the changes to vmsymbols.hpp are already in, then I suggest we > simply create a new bug to track the Unsafe.java changes into jdk8. > > I can sponsor this change to you Aleksey. Thanks, Chris. I think this had been already pushed by Vladimir: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cf5b18488d1 -Aleksey. From dl at cs.oswego.edu Wed Jan 9 04:37:19 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 09 Jan 2013 07:37:19 -0500 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED6365.2070003@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED61FA.2060900@oracle.com> <50ED6221.2020902@oracle.com> <50ED6365.2070003@oracle.com> Message-ID: <50ED647F.4070704@cs.oswego.edu> On 01/09/13 07:32, Chris Hegarty wrote: >> Thanks, Chris. I think this had been already pushed by Vladimir: >> http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cf5b18488d1 > > OK, so we got to wait for the next sync up to get these in jdk8/tl. > Maybe you could coordinate to do the tl hotspot sync-up and the lambda hotspot sync-up at the same time? This would avoid the need for example of multiple commits/CRs of our AtomicLong updates. -Doug From vladimir.kozlov at oracle.com Wed Jan 9 08:45:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Jan 2013 08:45:13 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50ED4F99.7030202@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50ED4F99.7030202@CoSoCo.de> Message-ID: <50ED9E99.7090001@oracle.com> Thank you, Ulf Good suggestion. Vladimir On 1/9/13 3:08 AM, Ulf Zibis wrote: > > Am 09.01.2013 01:10, schrieb Vitaly Davidovich: >> Hi Vladimir, >> >> encodeArray can be made static. >> >> Also, what's the purpose of overflow flag? Once you detect overflow can't >> you simply return the overflow result? >> >> What's the key piece that allows jit to generate better code? Is it the >> encodeArray which is nice, small, and isolated? >> >> Thanks >> >> Sent from my phone >> On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" >> wrote: >> >>> http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev >>> > > I would code: > 153 int i; > 154 for (i = 0; i < len; i++) { > 155 char c = sa[sp++]; > 156 if (c > '\u00FF') > 157 break; > 158 da[dp++] = (byte)c; > 159 } > > > -Ulf > From chris.hegarty at oracle.com Wed Jan 9 04:26:34 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Jan 2013 12:26:34 +0000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED4ED9.60102@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> Message-ID: <50ED61FA.2060900@oracle.com> On 09/01/2013 11:04, Aleksey Shipilev wrote: > Thanks, David. > > On 01/09/2013 02:55 PM, David Holmes wrote: >> Not sure where this is now but FYI you needed two CRs for this: one for >> hotspot and one for the JDK. They have different target versions (hs25 >> vs 8) and depending on the path you use to integrate could end up in >> different builds - hence distinct CRs for accurate tracking purposes. > > Too late, since these are already committed? I can submit another CR if > we need that. Since the changes to vmsymbols.hpp are already in, then I suggest we simply create a new bug to track the Unsafe.java changes into jdk8. I can sponsor this change to you Aleksey. -Chris >> I have a concern that the Long versions of these methods may be used >> directly without there being any check for supports_cx8 > > I actually have the question about this. What is the usual pattern for > using AtomicLong.VM_SUPPORTS_LONG_CAS? AtomicLong seems to use Unsafe > directly without the checks. AtomicLongFieldUpdater does the checks. > Something is fishy about this whole thing. > > I think this one tries to explain something, but I fail to grasp the intent: > > /** > * Records whether the underlying JVM supports lockless > * compareAndSwap for longs. While the Unsafe.compareAndSwapLong > * method works in either case, some constructions should be > * handled at Java level to avoid locking user-visible locks. > */ > static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8(); > > Doug? > > -Aleksey. > From chris.hegarty at oracle.com Wed Jan 9 04:32:37 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Jan 2013 12:32:37 +0000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED6221.2020902@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED61FA.2060900@oracle.com> <50ED6221.2020902@oracle.com> Message-ID: <50ED6365.2070003@oracle.com> On 09/01/2013 12:27, Aleksey Shipilev wrote: > On 01/09/2013 04:26 PM, Chris Hegarty wrote: >> On 09/01/2013 11:04, Aleksey Shipilev wrote: >>> Thanks, David. >>> >>> On 01/09/2013 02:55 PM, David Holmes wrote: >>>> Not sure where this is now but FYI you needed two CRs for this: one for >>>> hotspot and one for the JDK. They have different target versions (hs25 >>>> vs 8) and depending on the path you use to integrate could end up in >>>> different builds - hence distinct CRs for accurate tracking purposes. >>> >>> Too late, since these are already committed? I can submit another CR if >>> we need that. >> >> Since the changes to vmsymbols.hpp are already in, then I suggest we >> simply create a new bug to track the Unsafe.java changes into jdk8. >> >> I can sponsor this change to you Aleksey. > > Thanks, Chris. I think this had been already pushed by Vladimir: > http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cf5b18488d1 OK, so we got to wait for the next sync up to get these in jdk8/tl. -Chris. > > -Aleksey. > > > From chris.hegarty at oracle.com Wed Jan 9 06:48:55 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Jan 2013 14:48:55 +0000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED647F.4070704@cs.oswego.edu> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED61FA.2060900@oracle.com> <50ED6221.2020902@oracle.com> <50ED6365.2070003@oracle.com> <50ED647F.4070704@cs.oswego.edu> Message-ID: <50ED8357.6020403@oracle.com> On 09/01/2013 12:37, Doug Lea wrote: > On 01/09/13 07:32, Chris Hegarty wrote: > >>> Thanks, Chris. I think this had been already pushed by Vladimir: >>> http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cf5b18488d1 >> >> OK, so we got to wait for the next sync up to get these in jdk8/tl. >> > > Maybe you could coordinate to do the tl hotspot sync-up and > the lambda hotspot sync-up at the same time? This would avoid the > need for example of multiple commits/CRs of our AtomicLong updates. Oh, jdk8/tl seems to already have sync'ed the unsafe changes. So, we should only need one commit to sync'up the changes from lambda and move to unsafe.addAndGetXXX in jdk8/tl . Then lambda/lambda can sync with jdk8/tl. I can work on this. -Chris. > > -Doug > From vladimir.kozlov at oracle.com Wed Jan 9 10:03:49 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Jan 2013 10:03:49 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50ED5B78.2040309@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50ED5B78.2040309@CoSoCo.de> Message-ID: <50EDB105.5080606@oracle.com> Ulf, Thank you for this suggestion but I would like to keep surrounding code intact. I will rename "overflowflag" to "overflow". It is used to indicate that we should return CoderResult.OVERFLOW result. Thanks, Vladimir On 1/9/13 3:58 AM, Ulf Zibis wrote: > Am 09.01.2013 01:10, schrieb Vitaly Davidovich: >> On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" >> wrote: >> >>> http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev >>> > > Another tweak: > 168 char[] sa = src.array(); > 169 int sp = src.arrayOffset() + src.position(); > 170 int sr = src.remaining(); > 171 int sl = sp + sr; > 172 assert (sp <= sl); // superfluous, sr is always >= 0 > 173 sp = (sp <= sl ? sp : sl); // superfluous " > 174 byte[] da = dst.array(); > 175 int dp = dst.arrayOffset() + dst.position(); > 170 int dr = dst.remaining(); > 176 int dl = dp + dr; > 177 assert (dp <= dl); // superfluous " > 178 dp = (dp <= dl ? dp : dl); // superfluous " > 179 boolean overflow = false; > 180 if (sr > dr) { > 181 sr = dr; > 182 overflow = true; > 183 } > > Why you called it "overflowflag", in that way, you could name each > variable "myvaluevariable" or "myvaluefield" ;-) > > > -Ulf > From chris.hegarty at oracle.com Wed Jan 9 10:37:15 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Jan 2013 18:37:15 +0000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <42CDC876-6474-44C9-948E-518C7229E141@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED61FA.2060900@oracle.com> <50ED6221.2020902@oracle.com> <50ED6365.2070003@oracle.com> <50ED647F.4070704@cs.oswego.edu> <50ED8357.6020403@oracle.com> <42CDC876-6474-44C9-948E-518C7229E141@oracle.com> Message-ID: <50EDB8DB.8090107@oracle.com> On 09/01/2013 18:32, Mike Duigou wrote: > I can work on getting them in to lambda/lambda today as I was already planning to to jdk8/jdk8 -> lambda/lambda sync today. OK, great. I'm going to bring the jdk8/tl AtomicXXX 's up to date with Doug's CVS ( supersedes lambda versions ), and update the appropriate methods to use the new intrinsics. Then lambda/lambda can pull this in. -Chris. > > Mike > > On Jan 9 2013, at 06:48 , Chris Hegarty wrote: > >> On 09/01/2013 12:37, Doug Lea wrote: >>> On 01/09/13 07:32, Chris Hegarty wrote: >>> >>>>> Thanks, Chris. I think this had been already pushed by Vladimir: >>>>> http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cf5b18488d1 >>>> >>>> OK, so we got to wait for the next sync up to get these in jdk8/tl. >>>> >>> >>> Maybe you could coordinate to do the tl hotspot sync-up and >>> the lambda hotspot sync-up at the same time? This would avoid the >>> need for example of multiple commits/CRs of our AtomicLong updates. >> >> Oh, jdk8/tl seems to already have sync'ed the unsafe changes. So, we should only need one commit to sync'up the changes from lambda and move to unsafe.addAndGetXXX in jdk8/tl . Then lambda/lambda can sync with jdk8/tl. I can work on this. >> >> -Chris. >> >>> >>> -Doug >>> > From mike.duigou at oracle.com Wed Jan 9 10:32:55 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 9 Jan 2013 10:32:55 -0800 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED8357.6020403@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED61FA.2060900@oracle.com> <50ED6221.2020902@oracle.com> <50ED6365.2070003@oracle.com> <50ED647F.4070704@cs.oswego.edu> <50ED8357.6020403@oracle.com> Message-ID: <42CDC876-6474-44C9-948E-518C7229E141@oracle.com> I can work on getting them in to lambda/lambda today as I was already planning to to jdk8/jdk8 -> lambda/lambda sync today. Mike On Jan 9 2013, at 06:48 , Chris Hegarty wrote: > On 09/01/2013 12:37, Doug Lea wrote: >> On 01/09/13 07:32, Chris Hegarty wrote: >> >>>> Thanks, Chris. I think this had been already pushed by Vladimir: >>>> http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cf5b18488d1 >>> >>> OK, so we got to wait for the next sync up to get these in jdk8/tl. >>> >> >> Maybe you could coordinate to do the tl hotspot sync-up and >> the lambda hotspot sync-up at the same time? This would avoid the >> need for example of multiple commits/CRs of our AtomicLong updates. > > Oh, jdk8/tl seems to already have sync'ed the unsafe changes. So, we should only need one commit to sync'up the changes from lambda and move to unsafe.addAndGetXXX in jdk8/tl . Then lambda/lambda can sync with jdk8/tl. I can work on this. > > -Chris. > >> >> -Doug >> From christian.thalinger at oracle.com Wed Jan 9 12:17:00 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Jan 2013 12:17:00 -0800 Subject: C2 compilation gives incorrect results In-Reply-To: <50ED5830.8080309@redhat.com> References: <50ED5830.8080309@redhat.com> Message-ID: <30F073D7-E755-4AED-B967-EF0DE1986D6C@oracle.com> [Moving to hotspot-compiler-dev; bcc'ing hotspot-dev.] On Jan 9, 2013, at 3:44 AM, Andrew Haley wrote: > Here's a nice one, reported at bug 2396372. Test case at > https://bugzilla.redhat.com/attachment.cgi?id=605282 > The bug seems to have been in HotSpot for many years. > > The test case runs through many iterations until: > > $ java -XX:+PrintCompilation PolynomialRoot > > !!!!!!!!n=4 test 1431 > !!!!!!!!n=4 test 1432 > 96 37 3 PolynomialRoot::root4 (1560 bytes) made not entrant > 96 112 4 PolynomialRoot::root2 (183 bytes) > 96 45 4 PolynomialRoot::checkValues (360 bytes) made not entrant > Exception in thread "main" 97 56 ! 3 sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (356 bytes) made not entrant > java.lang.RuntimeException: order=4 p[0]=-0.09965134319016089;p[1]=0.0;p[2]=0.30234383793894914;p[3]=-0.18180230156481425;p[4]=0.5206321058295245; > x.r=0.134302716567836 x.i=0.4911858311805498 > res/sabs=-0.03744084182425251 ims/sabs=0.007299470095647275 sabs=3.553068664639566 > res=-0.13302988186347808 ims=0.02593551846531791 n=4 eps=1.0E-6 sabs>1/eps=false f1=true f2=true t=1432 > at PolynomialRoot.checkValues(PolynomialRoot.java:424) > at PolynomialRoot.testRoots(PolynomialRoot.java:491) > at PolynomialRoot.main(PolynomialRoot.java:762) > > mercury:~ $ java -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-aph_2013_01_09_11_31-b00) > OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode) Thanks for reporting this one, Andrew. I filed: 8005956: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block It seems there is a problem in liveness analysis and a product VM produces wrong code. -- Chris > > Andrew. From christian.thalinger at oracle.com Wed Jan 9 12:26:25 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Jan 2013 12:26:25 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50EDB105.5080606@oracle.com> References: <50ECA935.2030703@oracle.com> <50ED5B78.2040309@CoSoCo.de> <50EDB105.5080606@oracle.com> Message-ID: <27C55220-CEAA-46FC-AD9F-2D79621C22D7@oracle.com> Looks good to me. -- Chris On Jan 9, 2013, at 10:03 AM, Vladimir Kozlov wrote: > Ulf, > > Thank you for this suggestion but I would like to keep surrounding code intact. I will rename "overflowflag" to "overflow". It is used to indicate that we should return CoderResult.OVERFLOW result. > > Thanks, > Vladimir > > On 1/9/13 3:58 AM, Ulf Zibis wrote: >> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: >>> On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" >>> wrote: >>> >>>> http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev >>>> >> >> Another tweak: >> 168 char[] sa = src.array(); >> 169 int sp = src.arrayOffset() + src.position(); >> 170 int sr = src.remaining(); >> 171 int sl = sp + sr; >> 172 assert (sp <= sl); // superfluous, sr is always >= 0 >> 173 sp = (sp <= sl ? sp : sl); // superfluous " >> 174 byte[] da = dst.array(); >> 175 int dp = dst.arrayOffset() + dst.position(); >> 170 int dr = dst.remaining(); >> 176 int dl = dp + dr; >> 177 assert (dp <= dl); // superfluous " >> 178 dp = (dp <= dl ? dp : dl); // superfluous " >> 179 boolean overflow = false; >> 180 if (sr > dr) { >> 181 sr = dr; >> 182 overflow = true; >> 183 } >> >> Why you called it "overflowflag", in that way, you could name each >> variable "myvaluevariable" or "myvaluefield" ;-) >> >> >> -Ulf >> From chris.hegarty at oracle.com Wed Jan 9 13:17:12 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Jan 2013 21:17:12 +0000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50D3654F.2030106@oracle.com> References: <50D36104.8000701@oracle.com> <50D3654F.2030106@oracle.com> Message-ID: On 20 Dec 2012, at 19:21, Vladimir Kozlov wrote: > Looks good for me. I will sponsor these changes after we get a review from JDK side. Have I missed something, or are these changes not already in? -Chris > > Thanks, > Vladimir > > On 12/20/12 11:03 AM, Aleksey Shipilev wrote: >> Hi, >> >> Sorry for cross-list posting, but this change affects both HS and JDK. >> >> This simple change is missing from recently committed CR 7023898. While >> the VM support is there in Hotspot, no methods are exposed in Unsafe to >> actually make use of those intrinsics. This is the webrev fixing that: >> http://cr.openjdk.java.net/~shade/8004330/webrev.00/ >> >> It turns out the getAndSet intrinsics HotSpot are overloaded, which had >> deluged both Doug and me in the previous patch. These namings are >> inconsistent with other Unsafe intrinsic naming convention, so this >> change fixes that as well. >> >> Testing: >> - Built and tested in Linux x86_64 >> - java-concurrency-torture [1] atomicity tests are passed for >> AtomicIntegerV8 [2] and AtomicLongV8 [3] making use of those intrinsics >> on Linux x86_64 >> - running the java-concurrency-torture tests "-XX:+PrintInlining | >> grep Unsafe" tells all intrinsics have been successfully inlined >> - no other testing is expected for this trivial change. >> >> I would need a sponsor to push this. Thanks for your patience and reviews! >> >> Contributors: >> - dl: original patch, testing >> - shade: due diligence, messing with reviews, tests, and rebuilds >> >> -Aleksey. >> >> [1] https://github.com/shipilev/java-concurrency-torture/ >> [2] >> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java >> [3] >> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/longs/AtomicLongV8PairwiseTests.java >> From vladimir.kozlov at oracle.com Wed Jan 9 14:40:00 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Jan 2013 14:40:00 -0800 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: References: <50D36104.8000701@oracle.com> <50D3654F.2030106@oracle.com> Message-ID: <50EDF1C0.2020803@oracle.com> On 1/9/13 1:17 PM, Chris Hegarty wrote: > > On 20 Dec 2012, at 19:21, Vladimir Kozlov wrote: > >> Looks good for me. I will sponsor these changes after we get a review from JDK side. > > Have I missed something, or are these changes not already in? It is in promoted build already: % pwd /java/re/jdk/8/latest/ws/jdk % /java/re/jdk/8/latest/binaries/solaris-i586/bin/java -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b71) Java HotSpot(TM) Server VM (build 25.0-b14, mixed mode) % hg log src/share/classes/sun/misc/Unsafe.java changeset: 6261:8cf5b18488d1 user: dl date: Thu Dec 20 12:24:52 2012 -0800 summary: 8004330: Add missing Unsafe entry points for addAndGet() family > > -Chris > >> >> Thanks, >> Vladimir >> >> On 12/20/12 11:03 AM, Aleksey Shipilev wrote: >>> Hi, >>> >>> Sorry for cross-list posting, but this change affects both HS and JDK. >>> >>> This simple change is missing from recently committed CR 7023898. While >>> the VM support is there in Hotspot, no methods are exposed in Unsafe to >>> actually make use of those intrinsics. This is the webrev fixing that: >>> http://cr.openjdk.java.net/~shade/8004330/webrev.00/ >>> >>> It turns out the getAndSet intrinsics HotSpot are overloaded, which had >>> deluged both Doug and me in the previous patch. These namings are >>> inconsistent with other Unsafe intrinsic naming convention, so this >>> change fixes that as well. >>> >>> Testing: >>> - Built and tested in Linux x86_64 >>> - java-concurrency-torture [1] atomicity tests are passed for >>> AtomicIntegerV8 [2] and AtomicLongV8 [3] making use of those intrinsics >>> on Linux x86_64 >>> - running the java-concurrency-torture tests "-XX:+PrintInlining | >>> grep Unsafe" tells all intrinsics have been successfully inlined >>> - no other testing is expected for this trivial change. >>> >>> I would need a sponsor to push this. Thanks for your patience and reviews! >>> >>> Contributors: >>> - dl: original patch, testing >>> - shade: due diligence, messing with reviews, tests, and rebuilds >>> >>> -Aleksey. >>> >>> [1] https://github.com/shipilev/java-concurrency-torture/ >>> [2] >>> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java >>> [3] >>> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/longs/AtomicLongV8PairwiseTests.java >>> From vladimir.kozlov at oracle.com Wed Jan 9 14:44:18 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Jan 2013 14:44:18 -0800 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: References: <50D36104.8000701@oracle.com> <50D3654F.2030106@oracle.com> Message-ID: <50EDF2C2.5090309@oracle.com> (resending to all lists) It is in promoted build jdk8b71 already: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/8cf5b18488d1 Vladimir On 1/9/13 1:17 PM, Chris Hegarty wrote: > > On 20 Dec 2012, at 19:21, Vladimir Kozlov wrote: > >> Looks good for me. I will sponsor these changes after we get a review from JDK side. > > Have I missed something, or are these changes not already in? > > -Chris > >> >> Thanks, >> Vladimir >> >> On 12/20/12 11:03 AM, Aleksey Shipilev wrote: >>> Hi, >>> >>> Sorry for cross-list posting, but this change affects both HS and JDK. >>> >>> This simple change is missing from recently committed CR 7023898. While >>> the VM support is there in Hotspot, no methods are exposed in Unsafe to >>> actually make use of those intrinsics. This is the webrev fixing that: >>> http://cr.openjdk.java.net/~shade/8004330/webrev.00/ >>> >>> It turns out the getAndSet intrinsics HotSpot are overloaded, which had >>> deluged both Doug and me in the previous patch. These namings are >>> inconsistent with other Unsafe intrinsic naming convention, so this >>> change fixes that as well. >>> >>> Testing: >>> - Built and tested in Linux x86_64 >>> - java-concurrency-torture [1] atomicity tests are passed for >>> AtomicIntegerV8 [2] and AtomicLongV8 [3] making use of those intrinsics >>> on Linux x86_64 >>> - running the java-concurrency-torture tests "-XX:+PrintInlining | >>> grep Unsafe" tells all intrinsics have been successfully inlined >>> - no other testing is expected for this trivial change. >>> >>> I would need a sponsor to push this. Thanks for your patience and reviews! >>> >>> Contributors: >>> - dl: original patch, testing >>> - shade: due diligence, messing with reviews, tests, and rebuilds >>> >>> -Aleksey. >>> >>> [1] https://github.com/shipilev/java-concurrency-torture/ >>> [2] >>> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java >>> [3] >>> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/longs/AtomicLongV8PairwiseTests.java >>> From christian.thalinger at oracle.com Wed Jan 9 15:36:18 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Jan 2013 15:36:18 -0800 Subject: RFR (M): 8005418: JSR 292: virtual dispatch bug in 292 impl In-Reply-To: <6A8C4B83-94CD-4972-9C63-0C4190DFE0F5@oracle.com> References: <52090273-E391-48DB-BECC-B0DD5A2F33B6@oracle.com> <50EB7AD1.5060608@oracle.com> <6A8C4B83-94CD-4972-9C63-0C4190DFE0F5@oracle.com> Message-ID: <2D968632-51F7-4F0B-AE49-C2CAA6B6147D@oracle.com> Based on John's verbal comments I did some smaller changes to the out-parameters to emphasize that these are truly out-parameters. The webrev is updated and I'm going to push this. -- Chris On Jan 7, 2013, at 6:37 PM, Christian Thalinger wrote: > > On Jan 7, 2013, at 5:48 PM, Vladimir Kozlov wrote: > >> Seems fine to me. I wish the code for_method_handle_inline() was in doCall.cpp instead of callGenerator.cpp. Originally for_*() method were used only for corresponding *Generator instance creation. > > Perhaps. At least the method is a member of CallGenerator. I'm always confused when I find Foo::* methods in bar.cpp. > > Thanks for the review. > > -- Chris > >> >> Thanks, >> Vladimir >> >> On 1/7/13 4:28 PM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/8005418 >>> >>> 8005418: JSR 292: virtual dispatch bug in 292 impl >>> Reviewed-by: >>> >>> The logic in CallGenerator::for_method_handle_inline does not pass >>> call_is_virtual correctly. Currently target->is_abstract() is used as >>> a workaround. >>> >>> The fix is to do the same thing as Parse::do_call is doing. >>> >>> src/share/vm/opto/callGenerator.cpp >>> src/share/vm/opto/compile.hpp >>> src/share/vm/opto/doCall.cpp >>> src/share/vm/opto/parse.hpp >>> src/share/vm/opto/parse1.cpp >>> > From Ulf.Zibis at CoSoCo.de Wed Jan 9 15:57:02 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 10 Jan 2013 00:57:02 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50EDB105.5080606@oracle.com> References: <50ECA935.2030703@oracle.com> <50ED5B78.2040309@CoSoCo.de> <50EDB105.5080606@oracle.com> Message-ID: <50EE03CE.4040701@CoSoCo.de> Another little simplification: 179 boolean overflow = sr > dr; 180 sr = overflow ? dr : sr; or in your existing logic: 178 int len = sl - sp; 179 boolean overflow = len > (dl - dp); 180 len = overflow ? dl - dp : len; (len is equivalent to sr) -Ulf Am 09.01.2013 19:03, schrieb Vladimir Kozlov: > Ulf, > > Thank you for this suggestion but I would like to keep surrounding code intact. I will rename > "overflowflag" to "overflow". It is used to indicate that we should return CoderResult.OVERFLOW > result. > > Thanks, > Vladimir > > On 1/9/13 3:58 AM, Ulf Zibis wrote: >> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: >>> On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" >>> wrote: >>> >>>> http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev >>>> >>>> >> >> Another tweak: >> 168 char[] sa = src.array(); >> 169 int sp = src.arrayOffset() + src.position(); >> 170 int sr = src.remaining(); >> 171 int sl = sp + sr; >> 172 assert (sp <= sl); // superfluous, sr is always >= 0 >> 173 sp = (sp <= sl ? sp : sl); // superfluous " >> 174 byte[] da = dst.array(); >> 175 int dp = dst.arrayOffset() + dst.position(); >> 170 int dr = dst.remaining(); >> 176 int dl = dp + dr; >> 177 assert (dp <= dl); // superfluous " >> 178 dp = (dp <= dl ? dp : dl); // superfluous " >> 179 boolean overflow = false; >> 180 if (sr > dr) { >> 181 sr = dr; >> 182 overflow = true; >> 183 } >> >> Why you called it "overflowflag", in that way, you could name each >> variable "myvaluevariable" or "myvaluefield" ;-) >> >> >> -Ulf >> > From vladimir.kozlov at oracle.com Wed Jan 9 16:38:04 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Jan 2013 16:38:04 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50EE03CE.4040701@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50ED5B78.2040309@CoSoCo.de> <50EDB105.5080606@oracle.com> <50EE03CE.4040701@CoSoCo.de> Message-ID: <50EE0D6C.40503@oracle.com> From JIT compiler view current code is better since it has only one compare. Your code has two compares: one to calculate "overflow" and an other (depended on first) to calculate "len". Thanks, Vladimir On 1/9/13 3:57 PM, Ulf Zibis wrote: > Another little simplification: > 179 boolean overflow = sr > dr; > 180 sr = overflow ? dr : sr; > or in your existing logic: > 178 int len = sl - sp; > 179 boolean overflow = len > (dl - dp); > 180 len = overflow ? dl - dp : len; > (len is equivalent to sr) > > -Ulf > > Am 09.01.2013 19:03, schrieb Vladimir Kozlov: >> Ulf, >> >> Thank you for this suggestion but I would like to keep surrounding >> code intact. I will rename "overflowflag" to "overflow". It is used to >> indicate that we should return CoderResult.OVERFLOW result. >> >> Thanks, >> Vladimir >> >> On 1/9/13 3:58 AM, Ulf Zibis wrote: >>> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: >>>> On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" >>>> wrote: >>>> >>>>> http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev >>>>> >>>>> >>> >>> Another tweak: >>> 168 char[] sa = src.array(); >>> 169 int sp = src.arrayOffset() + src.position(); >>> 170 int sr = src.remaining(); >>> 171 int sl = sp + sr; >>> 172 assert (sp <= sl); // superfluous, sr is always >= 0 >>> 173 sp = (sp <= sl ? sp : sl); // superfluous " >>> 174 byte[] da = dst.array(); >>> 175 int dp = dst.arrayOffset() + dst.position(); >>> 170 int dr = dst.remaining(); >>> 176 int dl = dp + dr; >>> 177 assert (dp <= dl); // superfluous " >>> 178 dp = (dp <= dl ? dp : dl); // superfluous " >>> 179 boolean overflow = false; >>> 180 if (sr > dr) { >>> 181 sr = dr; >>> 182 overflow = true; >>> 183 } >>> >>> Why you called it "overflowflag", in that way, you could name each >>> variable "myvaluevariable" or "myvaluefield" ;-) >>> >>> >>> -Ulf >>> >> > From vitalyd at gmail.com Wed Jan 9 17:11:03 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 9 Jan 2013 20:11:03 -0500 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50EE0D6C.40503@oracle.com> References: <50ECA935.2030703@oracle.com> <50ED5B78.2040309@CoSoCo.de> <50EDB105.5080606@oracle.com> <50EE03CE.4040701@CoSoCo.de> <50EE0D6C.40503@oracle.com> Message-ID: One could write this as: boolean overflow = false; if (len > (dl - dp)) { overflow = true; len = dl - dp; } One would hope jit can do this automatically and also CSE away the dl - dp bit. :) Sent from my phone On Jan 9, 2013 7:39 PM, "Vladimir Kozlov" wrote: > From JIT compiler view current code is better since it has only one > compare. Your code has two compares: one to calculate "overflow" and an > other (depended on first) to calculate "len". > > Thanks, > Vladimir > > On 1/9/13 3:57 PM, Ulf Zibis wrote: > >> Another little simplification: >> 179 boolean overflow = sr > dr; >> 180 sr = overflow ? dr : sr; >> or in your existing logic: >> 178 int len = sl - sp; >> 179 boolean overflow = len > (dl - dp); >> 180 len = overflow ? dl - dp : len; >> (len is equivalent to sr) >> >> -Ulf >> >> Am 09.01.2013 19:03, schrieb Vladimir Kozlov: >> >>> Ulf, >>> >>> Thank you for this suggestion but I would like to keep surrounding >>> code intact. I will rename "overflowflag" to "overflow". It is used to >>> indicate that we should return CoderResult.OVERFLOW result. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/9/13 3:58 AM, Ulf Zibis wrote: >>> >>>> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: >>>> >>>>> On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" >>>>> wrote: >>>>> >>>>> http://cr.openjdk.java.net/~****kvn/6896617_jdk/webrev >>>>>> >>>>>> > >>>>>> >>>>>> >>>>>> >>>> Another tweak: >>>> 168 char[] sa = src.array(); >>>> 169 int sp = src.arrayOffset() + src.position(); >>>> 170 int sr = src.remaining(); >>>> 171 int sl = sp + sr; >>>> 172 assert (sp <= sl); // superfluous, sr is always >= 0 >>>> 173 sp = (sp <= sl ? sp : sl); // superfluous " >>>> 174 byte[] da = dst.array(); >>>> 175 int dp = dst.arrayOffset() + dst.position(); >>>> 170 int dr = dst.remaining(); >>>> 176 int dl = dp + dr; >>>> 177 assert (dp <= dl); // superfluous " >>>> 178 dp = (dp <= dl ? dp : dl); // superfluous " >>>> 179 boolean overflow = false; >>>> 180 if (sr > dr) { >>>> 181 sr = dr; >>>> 182 overflow = true; >>>> 183 } >>>> >>>> Why you called it "overflowflag", in that way, you could name each >>>> variable "myvaluevariable" or "myvaluefield" ;-) >>>> >>>> >>>> -Ulf >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130109/e3e02687/attachment.html From vladimir.kozlov at oracle.com Wed Jan 9 18:11:39 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Jan 2013 18:11:39 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> <50ED5B78.2040309@CoSoCo.de> <50EDB105.5080606@oracle.com> <50EE03CE.4040701@CoSoCo.de> <50EE0D6C.40503@oracle.com> Message-ID: <50EE235B.2080301@oracle.com> On 1/9/13 5:11 PM, Vitaly Davidovich wrote: > One could write this as: > boolean overflow = false; > if (len > (dl - dp)) > { > overflow = true; > len = dl - dp; > } > > One would hope jit can do this automatically and also CSE away the dl - > dp bit. :) Yes, JIT can convert Ulf's code into above code - SplitIf optimization in C2. But it could be complicated by surrounding code. And generating only one dl-dp is regular optimization which JIT does. Thanks, Vladimir > > Sent from my phone > > On Jan 9, 2013 7:39 PM, "Vladimir Kozlov" > wrote: > > From JIT compiler view current code is better since it has only one > compare. Your code has two compares: one to calculate "overflow" and > an other (depended on first) to calculate "len". > > Thanks, > Vladimir > > On 1/9/13 3:57 PM, Ulf Zibis wrote: > > Another little simplification: > 179 boolean overflow = sr > dr; > 180 sr = overflow ? dr : sr; > or in your existing logic: > 178 int len = sl - sp; > 179 boolean overflow = len > (dl - dp); > 180 len = overflow ? dl - dp : len; > (len is equivalent to sr) > > -Ulf > > Am 09.01.2013 19:03, schrieb Vladimir Kozlov: > > Ulf, > > Thank you for this suggestion but I would like to keep > surrounding > code intact. I will rename "overflowflag" to "overflow". It > is used to > indicate that we should return CoderResult.OVERFLOW result. > > Thanks, > Vladimir > > On 1/9/13 3:58 AM, Ulf Zibis wrote: > > Am 09.01.2013 01:10, schrieb Vitaly Davidovich: > > On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" > > > wrote: > > http://cr.openjdk.java.net/~**__kvn/6896617_jdk/webrev > > > > > > Another tweak: > 168 char[] sa = src.array(); > 169 int sp = src.arrayOffset() + > src.position(); > 170 int sr = src.remaining(); > 171 int sl = sp + sr; > 172 assert (sp <= sl); // superfluous, sr > is always >= 0 > 173 sp = (sp <= sl ? sp : sl); // > superfluous " > 174 byte[] da = dst.array(); > 175 int dp = dst.arrayOffset() + > dst.position(); > 170 int dr = dst.remaining(); > 176 int dl = dp + dr; > 177 assert (dp <= dl); // superfluous " > 178 dp = (dp <= dl ? dp : dl); // > superfluous " > 179 boolean overflow = false; > 180 if (sr > dr) { > 181 sr = dr; > 182 overflow = true; > 183 } > > Why you called it "overflowflag", in that way, you could > name each > variable "myvaluevariable" or "myvaluefield" ;-) > > > -Ulf > > > From christian.thalinger at oracle.com Wed Jan 9 19:16:36 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 10 Jan 2013 03:16:36 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8005418: JSR 292: virtual dispatch bug in 292 impl Message-ID: <20130110031638.A249C47165@hg.openjdk.java.net> Changeset: 5698813d45eb Author: twisti Date: 2013-01-09 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5698813d45eb 8005418: JSR 292: virtual dispatch bug in 292 impl Reviewed-by: jrose, kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp From david.holmes at oracle.com Wed Jan 9 19:24:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Jan 2013 13:24:20 +1000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED4ED9.60102@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> Message-ID: <50EE3464.1070304@oracle.com> On 9/01/2013 9:04 PM, Aleksey Shipilev wrote: > Thanks, David. > > On 01/09/2013 02:55 PM, David Holmes wrote: >> Not sure where this is now but FYI you needed two CRs for this: one for >> hotspot and one for the JDK. They have different target versions (hs25 >> vs 8) and depending on the path you use to integrate could end up in >> different builds - hence distinct CRs for accurate tracking purposes. > > Too late, since these are already committed? I can submit another CR if > we need that. I'll fix it up - it is easier to do than explain. :) As it is, the fact these both went in through hotspot repo at least means they appeared in jdk8/jdk8 at the same time. >> I have a concern that the Long versions of these methods may be used >> directly without there being any check for supports_cx8 > > I actually have the question about this. What is the usual pattern for > using AtomicLong.VM_SUPPORTS_LONG_CAS? AtomicLong seems to use Unsafe > directly without the checks. AtomicLongFieldUpdater does the checks. > Something is fishy about this whole thing. I had forgotten at what levels this operates too. As I think is now clear(er) there is a Java level check (and fallback to locks) for the AtomicLongFieldUpdater based on supports_cx8. Then there are further checks of supports_cx8 in unsafe.cpp. Critically in Unsafe_CompareAndSwapLong. (Still needed on some platforms) Also note that Unsafe_get/setLongVolatile are also gated, unnecessarily, on supports_cx8. We have to have atomic 64-bit read/write for direct Java volatile accesses anyway. There's also an open CR to define supports_atomic_long_ops so that supports_cx8 is only used for the CAS, where it is needed, rather than simple read/write ops. David ----- > > I think this one tries to explain something, but I fail to grasp the intent: > > /** > * Records whether the underlying JVM supports lockless > * compareAndSwap for longs. While the Unsafe.compareAndSwapLong > * method works in either case, some constructions should be > * handled at Java level to avoid locking user-visible locks. > */ > static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8(); > > Doug? > > -Aleksey. > From vitalyd at gmail.com Wed Jan 9 20:00:22 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 9 Jan 2013 23:00:22 -0500 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50EE235B.2080301@oracle.com> References: <50ECA935.2030703@oracle.com> <50ED5B78.2040309@CoSoCo.de> <50EDB105.5080606@oracle.com> <50EE03CE.4040701@CoSoCo.de> <50EE0D6C.40503@oracle.com> <50EE235B.2080301@oracle.com> Message-ID: I was sure CSE was done but didn't know about SplitIf, very cool. Thanks Sent from my phone On Jan 9, 2013 9:11 PM, "Vladimir Kozlov" wrote: > On 1/9/13 5:11 PM, Vitaly Davidovich wrote: > >> One could write this as: >> boolean overflow = false; >> if (len > (dl - dp)) >> { >> overflow = true; >> len = dl - dp; >> } >> >> One would hope jit can do this automatically and also CSE away the dl - >> dp bit. :) >> > > Yes, JIT can convert Ulf's code into above code - SplitIf optimization in > C2. But it could be complicated by surrounding code. > And generating only one dl-dp is regular optimization which JIT does. > > Thanks, > Vladimir > > >> Sent from my phone >> >> On Jan 9, 2013 7:39 PM, "Vladimir Kozlov" > >> >> wrote: >> >> From JIT compiler view current code is better since it has only one >> compare. Your code has two compares: one to calculate "overflow" and >> an other (depended on first) to calculate "len". >> >> Thanks, >> Vladimir >> >> On 1/9/13 3:57 PM, Ulf Zibis wrote: >> >> Another little simplification: >> 179 boolean overflow = sr > dr; >> 180 sr = overflow ? dr : sr; >> or in your existing logic: >> 178 int len = sl - sp; >> 179 boolean overflow = len > (dl - dp); >> 180 len = overflow ? dl - dp : len; >> (len is equivalent to sr) >> >> -Ulf >> >> Am 09.01.2013 19:03, schrieb Vladimir Kozlov: >> >> Ulf, >> >> Thank you for this suggestion but I would like to keep >> surrounding >> code intact. I will rename "overflowflag" to "overflow". It >> is used to >> indicate that we should return CoderResult.OVERFLOW result. >> >> Thanks, >> Vladimir >> >> On 1/9/13 3:58 AM, Ulf Zibis wrote: >> >> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: >> >> On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" >> > >> >> >> wrote: >> >> http://cr.openjdk.java.net/~**** >> __kvn/6896617_jdk/webrev >> > *kvn/6896617_jdk/webrev >> > >> > kvn/6896617_jdk/webrev >> >> >> >> >> >> Another tweak: >> 168 char[] sa = src.array(); >> 169 int sp = src.arrayOffset() + >> src.position(); >> 170 int sr = src.remaining(); >> 171 int sl = sp + sr; >> 172 assert (sp <= sl); // superfluous, sr >> is always >= 0 >> 173 sp = (sp <= sl ? sp : sl); // >> superfluous " >> 174 byte[] da = dst.array(); >> 175 int dp = dst.arrayOffset() + >> dst.position(); >> 170 int dr = dst.remaining(); >> 176 int dl = dp + dr; >> 177 assert (dp <= dl); // superfluous " >> 178 dp = (dp <= dl ? dp : dl); // >> superfluous " >> 179 boolean overflow = false; >> 180 if (sr > dr) { >> 181 sr = dr; >> 182 overflow = true; >> 183 } >> >> Why you called it "overflowflag", in that way, you could >> name each >> variable "myvaluevariable" or "myvaluefield" ;-) >> >> >> -Ulf >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130109/45484180/attachment-0001.html From Ulf.Zibis at CoSoCo.de Thu Jan 10 06:03:50 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 10 Jan 2013 15:03:50 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50EE235B.2080301@oracle.com> References: <50ECA935.2030703@oracle.com> <50ED5B78.2040309@CoSoCo.de> <50EDB105.5080606@oracle.com> <50EE03CE.4040701@CoSoCo.de> <50EE0D6C.40503@oracle.com> <50EE235B.2080301@oracle.com> Message-ID: <50EECA46.7090308@CoSoCo.de> Am 10.01.2013 03:11, schrieb Vladimir Kozlov: > On 1/9/13 5:11 PM, Vitaly Davidovich wrote: >> One could write this as: >> boolean overflow = false; >> if (len > (dl - dp)) >> { >> overflow = true; >> len = dl - dp; >> } >> >> One would hope jit can do this automatically and also CSE away the dl - >> dp bit. :) > > Yes, JIT can convert Ulf's code into above code - SplitIf optimization in C2. Yes, this I was assuming too. But I think, the correct code would be: Alternative (3): boolean overflow; if (len > (dl - dp)) { overflow = true; len = dl - dp; } else overflow = false; This would avoid first assigning overflow = false and later reverting it to overflow = true; ...or is JIT able to optimize this? > But it could be complicated by surrounding code. Could one check this by hsdis ? Anyway I suspect if JIT will optimise this snippet in a reasonable time, because it is only executed once in encodeArrayLoop(), + the compile threshold is high, as method encodeArrayLoop() is long. So maybe we should focus on the best performance in interpreter for the 3 alternatives. My assumption, the following would win, as it avoids to calculate dl - dp 2 times: Alternative (4): int slen = sl - sp; int dlen = dl - dp; boolean overflow; if (slen > dlen) { overflow = true; slen = dlen; } else overflow = false; ... but maybe Alternative (5) is not far from that: int slen = sl - sp; int dlen = dl - dp; boolean overflow = slen > dlen; slen ? overflow = dlen : slen; In case, if JIT comes in effect, both should optimize optimal. Looking at the calculation of slen/dlen: int sp = src.arrayOffset() + src.position(); int sl = src.arrayOffset() + src.limit(); assert (sp <= sl); sp = (sp <= sl ? sp : sl); int slen = sl - sp; My suggestion: int slen = src.remaining(); // should never be negative, so above 2 time (sp <= sl) are superfluous! Additionally calculation of sl could be faster: int sl = sp + src.remaining(); which could be again faster and is equivalent to: int sl = sp + slen; if slen is anyway calculated before. Same for dlen, with on top, that dl is never used later 8-) , so could be completely dropped. About the naming: According to sp, sl, dp, dl I would prefer: sr, dr over (x)len. About overflow: There was a question some posts above, if it is necessary at all. Can one please answer? The question is, if other error results have higher priority over CoderResult.OVERFLOW. -Ulf > And generating only one dl-dp is regular optimization which JIT does. > > Thanks, > Vladimir > >> >> Sent from my phone >> >> On Jan 9, 2013 7:39 PM, "Vladimir Kozlov" > > wrote: >> >> From JIT compiler view current code is better since it has only one >> compare. Your code has two compares: one to calculate "overflow" and >> an other (depended on first) to calculate "len". >> >> Thanks, >> Vladimir >> >> On 1/9/13 3:57 PM, Ulf Zibis wrote: >> >> Another little simplification: >> 179 boolean overflow = sr > dr; >> 180 sr = overflow ? dr : sr; >> or in your existing logic: >> 178 int len = sl - sp; >> 179 boolean overflow = len > (dl - dp); >> 180 len = overflow ? dl - dp : len; >> (len is equivalent to sr) >> >> -Ulf >> >> Am 09.01.2013 19:03, schrieb Vladimir Kozlov: >> >> Ulf, >> >> Thank you for this suggestion but I would like to keep >> surrounding >> code intact. I will rename "overflowflag" to "overflow". It >> is used to >> indicate that we should return CoderResult.OVERFLOW result. >> >> Thanks, >> Vladimir >> >> On 1/9/13 3:58 AM, Ulf Zibis wrote: >> >> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: >> >> On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" >> > > >> wrote: >> >> http://cr.openjdk.java.net/~**__kvn/6896617_jdk/webrev >> > > >> >> >> >> Another tweak: >> 168 char[] sa = src.array(); >> 169 int sp = src.arrayOffset() + >> src.position(); >> 170 int sr = src.remaining(); >> 171 int sl = sp + sr; >> 172 assert (sp <= sl); // superfluous, sr >> is always >= 0 >> 173 sp = (sp <= sl ? sp : sl); // >> superfluous " >> 174 byte[] da = dst.array(); >> 175 int dp = dst.arrayOffset() + >> dst.position(); >> 170 int dr = dst.remaining(); >> 176 int dl = dp + dr; >> 177 assert (dp <= dl); // superfluous " >> 178 dp = (dp <= dl ? dp : dl); // >> superfluous " >> 179 boolean overflow = false; >> 180 if (sr > dr) { >> 181 sr = dr; >> 182 overflow = true; >> 183 } >> >> Why you called it "overflowflag", in that way, you could >> name each >> variable "myvaluevariable" or "myvaluefield" ;-) >> >> >> -Ulf >> >> >> > From morris.meyer at oracle.com Thu Jan 10 06:35:48 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 10 Jan 2013 09:35:48 -0500 Subject: RFR (S) 6518907: cleanup IA64 specific code in Hotspot Message-ID: <50EED1C4.3010900@oracle.com> Gentlefolk, I have taken what I hope to be the final pass at https://jbs.oracle.com/bugs/browse/JDK-6518907 and incorporated the comments of Goetz Lindenmaier of SAP. Per the HotSpot workflow I have submitted this change successfully to JPRT. Vladimir Kozlov still has a concern that has been unaddressed though, and I would like to get resolution on this point if possible. /One thing concern me is code change in os.cpp for Win64: // / / //+ // On Windows AMD64 link() does not work as there's no back link on the stack. // //+ #elif (defined(IA64) || defined(AMD64)) && defined(_WIN32) // / / //Can someone familiar with Windows confirm if the statement in the comment and code change are correct? / Thanks to all for the previous reviews. --mm JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907 WEBREV - http://cr.openjdk.java.net/~morris/6518907 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130110/a58de449/attachment.html From goetz.lindenmaier at sap.com Thu Jan 10 06:46:51 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 10 Jan 2013 15:46:51 +0100 Subject: RFR (S) 6518907: cleanup IA64 specific code in Hotspot In-Reply-To: <50EED1C4.3010900@oracle.com> References: <50EED1C4.3010900@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF7C9E883@DEWDFECCR03.wdf.sap.corp> Hi Morris, just remove the amd case if it's unclear to you. I left it in just in case you find it useful. It probably belongs into a separate change, anyways. Best regards, Goetz. From: Morris Meyer [mailto:morris.meyer at oracle.com] Sent: Donnerstag, 10. Januar 2013 15:36 To: hotspot-compiler-dev at openjdk.java.net; hotspot_compiler_staff_ww_grp at oracle.com; Lindenmaier, Goetz Subject: RFR (S) 6518907: cleanup IA64 specific code in Hotspot Gentlefolk, I have taken what I hope to be the final pass at https://jbs.oracle.com/bugs/browse/JDK-6518907 and incorporated the comments of Goetz Lindenmaier of SAP. Per the HotSpot workflow I have submitted this change successfully to JPRT. Vladimir Kozlov still has a concern that has been unaddressed though, and I would like to get resolution on this point if possible. One thing concern me is code change in os.cpp for Win64: + // On Windows AMD64 link() does not work as there's no back link on the stack. + #elif (defined(IA64) || defined(AMD64)) && defined(_WIN32) Can someone familiar with Windows confirm if the statement in the comment and code change are correct? Thanks to all for the previous reviews. --mm JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907 WEBREV - http://cr.openjdk.java.net/~morris/6518907 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130110/a5417435/attachment.html From morris.meyer at oracle.com Thu Jan 10 06:57:33 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 10 Jan 2013 09:57:33 -0500 Subject: RFR (XS) 8003252: PPC: move MacroAssembler into separate file Message-ID: <50EED6DD.6090909@oracle.com> Folks, Could I get a quick review of this very small change necessary for the refactoring requested by Christian Thalinger for moving the MacroAssembler into separate files? Per the workflow this has been successfully submitted through JPRT. Thanks in advance, --morris JBS - https://jbs.oracle.com/bugs/browse/JDK-8003252 WEBREV - http://cr.openjdk.java.net/~morris/8003252 From david.r.chase at oracle.com Thu Jan 10 07:58:29 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 10 Jan 2013 10:58:29 -0500 Subject: Request for reviews (S) 8005821 : C2: -XX:+PrintIntrinsics is broken Message-ID: Webrev: http://cr.openjdk.java.net/~drchase/8005821/webrev.00/ Bug appeared as part of incremental inlining; a print data structure was not initialized appropriately. Old behavior: -XX:+PrintIntrinsics would crash. New behavior: -XX:+PrintIntrinsics doesn't crash. Changes (all one-liners) (1) modify initialization flag to match new printing behavior (fixes crash) (2) modify dump_inlining method to also match new printing behavior (related behavioral glitch) (3) fixed indenting of line calling dump_inlining. Non-change (because someone will ask): Did NOT fix intending of 150-line block preceding (3). Body of block is aligned with surrounding code, but { and } are undented. These were (historically) added to run some destructors at the right place. David From vladimir.kozlov at oracle.com Thu Jan 10 10:33:19 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Jan 2013 10:33:19 -0800 Subject: Request for reviews (S) 8005821 : C2: -XX:+PrintIntrinsics is broken In-Reply-To: References: Message-ID: <50EF096F.6020402@oracle.com> On 1/10/13 7:58 AM, David Chase wrote: > > Webrev: http://cr.openjdk.java.net/~drchase/8005821/webrev.00/ Changes are good. > > Bug appeared as part of incremental inlining; a print data structure was not initialized appropriately. > > Old behavior: -XX:+PrintIntrinsics would crash. > New behavior: -XX:+PrintIntrinsics doesn't crash. I would reverse this statement or would say it more clear: before fix: -XX:+PrintIntrinsics would crash. after fix: -XX:+PrintIntrinsics doesn't crash. We also add what testing was done. As I understand you ran it in JPRT which is enough for this fix. Thanks, Vladimir > > Changes (all one-liners) > (1) modify initialization flag to match new printing behavior (fixes crash) > (2) modify dump_inlining method to also match new printing behavior (related behavioral glitch) > (3) fixed indenting of line calling dump_inlining. > > Non-change (because someone will ask): > Did NOT fix intending of 150-line block preceding (3). > Body of block is aligned with surrounding code, but { and } are undented. > These were (historically) added to run some destructors at the right place. > > David > From vladimir.kozlov at oracle.com Thu Jan 10 10:37:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Jan 2013 10:37:31 -0800 Subject: RFR (XS) 8003252: PPC: move MacroAssembler into separate file In-Reply-To: <50EED6DD.6090909@oracle.com> References: <50EED6DD.6090909@oracle.com> Message-ID: <50EF0A6B.2020801@oracle.com> Looks good. Thanks, Vladimir PS: please, send webrev only to hotspot-compiler-dev. On 1/10/13 6:57 AM, Morris Meyer wrote: > > Folks, > > Could I get a quick review of this very small change necessary for the > refactoring requested by Christian Thalinger for moving the > MacroAssembler into separate files? Per the workflow this has been > successfully submitted through JPRT. > > Thanks in advance, > > --morris > > JBS - https://jbs.oracle.com/bugs/browse/JDK-8003252 > WEBREV - http://cr.openjdk.java.net/~morris/8003252 From david.r.chase at oracle.com Thu Jan 10 10:53:33 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 10 Jan 2013 13:53:33 -0500 Subject: Request for reviews (S) 8005821 : C2: -XX:+PrintIntrinsics is broken In-Reply-To: <50EF096F.6020402@oracle.com> References: <50EF096F.6020402@oracle.com> Message-ID: On 2013-01-10, at 1:33 PM, Vladimir Kozlov wrote: > > I would reverse this statement or would say it more clear: > > before fix: -XX:+PrintIntrinsics would crash. > after fix: -XX:+PrintIntrinsics doesn't crash. > > We also add what testing was done. As I understand you ran it in JPRT which is enough for this fix. Oops, yes, it ran clean in JPRT. I also verified that the crash is gone. David From christian.thalinger at oracle.com Thu Jan 10 14:59:23 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Jan 2013 14:59:23 -0800 Subject: RFR (XS) 8003252: PPC: move MacroAssembler into separate file In-Reply-To: <50EED6DD.6090909@oracle.com> References: <50EED6DD.6090909@oracle.com> Message-ID: Looks good. -- Chris On Jan 10, 2013, at 6:57 AM, Morris Meyer wrote: > > Folks, > > Could I get a quick review of this very small change necessary for the refactoring requested by Christian Thalinger for moving the MacroAssembler into separate files? Per the workflow this has been successfully submitted through JPRT. > > Thanks in advance, > > --morris > > JBS - https://jbs.oracle.com/bugs/browse/JDK-8003252 > WEBREV - http://cr.openjdk.java.net/~morris/8003252 From christian.thalinger at oracle.com Thu Jan 10 15:07:45 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Jan 2013 15:07:45 -0800 Subject: Request for reviews (S) 8005821 : C2: -XX:+PrintIntrinsics is broken In-Reply-To: References: Message-ID: <77195CC6-A945-463F-A95D-6CC095B43240@oracle.com> On Jan 10, 2013, at 7:58 AM, David Chase wrote: > > Webrev: http://cr.openjdk.java.net/~drchase/8005821/webrev.00/ Can you please verify that +TraceTypeProfile with -PrintInlining works? void trace_type_profile(Compile* C, ciMethod *method, int depth, int bci, ciMethod *prof_method, ciKlass *prof_klass, int site_count, int receiver_count) { if (TraceTypeProfile || PrintInlining NOT_PRODUCT(|| PrintOptoInlining)) { But I think it does. -- Chris > > Bug appeared as part of incremental inlining; a print data structure was not initialized appropriately. > > Old behavior: -XX:+PrintIntrinsics would crash. > New behavior: -XX:+PrintIntrinsics doesn't crash. > > Changes (all one-liners) > (1) modify initialization flag to match new printing behavior (fixes crash) > (2) modify dump_inlining method to also match new printing behavior (related behavioral glitch) > (3) fixed indenting of line calling dump_inlining. > > Non-change (because someone will ask): > Did NOT fix intending of 150-line block preceding (3). > Body of block is aligned with surrounding code, but { and } are undented. > These were (historically) added to run some destructors at the right place. > > David From christian.thalinger at oracle.com Thu Jan 10 16:10:07 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Jan 2013 16:10:07 -0800 Subject: RFR (XXS): 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Message-ID: <1EACFC52-FFC9-4806-A2E3-5DABDE62739F@oracle.com> http://cr.openjdk.java.net/~twisti/8006031/ 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Reviewed-by: Remove "return false;" leftover. src/share/vm/opto/library_call.cpp From vladimir.kozlov at oracle.com Thu Jan 10 16:24:39 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Jan 2013 16:24:39 -0800 Subject: RFR (XXS): 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 In-Reply-To: <1EACFC52-FFC9-4806-A2E3-5DABDE62739F@oracle.com> References: <1EACFC52-FFC9-4806-A2E3-5DABDE62739F@oracle.com> Message-ID: <50EF5BC7.8050701@oracle.com> Good. Thanks, Vladimir On 1/10/13 4:10 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8006031/ > > 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 > Reviewed-by: > > Remove "return false;" leftover. > > src/share/vm/opto/library_call.cpp > From azeem.jiva at oracle.com Thu Jan 10 16:52:28 2013 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Thu, 10 Jan 2013 16:52:28 -0800 Subject: RFR (XXS): 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 In-Reply-To: <1EACFC52-FFC9-4806-A2E3-5DABDE62739F@oracle.com> References: <1EACFC52-FFC9-4806-A2E3-5DABDE62739F@oracle.com> Message-ID: <50EF624C.5040001@oracle.com> Looks good... On 1/10/2013 4:10 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8006031/ > > 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 > Reviewed-by: > > Remove "return false;" leftover. > > src/share/vm/opto/library_call.cpp > -- Azeem Jiva @javawithjiva -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130110/e22379db/attachment.html From christian.thalinger at oracle.com Thu Jan 10 16:57:57 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Jan 2013 16:57:57 -0800 Subject: RFR (XXS): 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 In-Reply-To: <50EF5BC7.8050701@oracle.com> References: <1EACFC52-FFC9-4806-A2E3-5DABDE62739F@oracle.com> <50EF5BC7.8050701@oracle.com> Message-ID: Thank you, Vladimir. -- Chris On Jan 10, 2013, at 4:24 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 1/10/13 4:10 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8006031/ >> >> 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 >> Reviewed-by: >> >> Remove "return false;" leftover. >> >> src/share/vm/opto/library_call.cpp >> From christian.thalinger at oracle.com Thu Jan 10 17:00:08 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Jan 2013 17:00:08 -0800 Subject: 8005820: Shark: enable JSR292 support [Re: Enable JSR292 support in Shark] In-Reply-To: <4E4C0FAC-0301-4510-A750-BF7A4AEFF49B@oracle.com> References: <1354827728.1747.50.camel@mercury> <1354835310.1747.64.camel@mercury> <1355169605.1747.117.camel@mercury> <4E4C0FAC-0301-4510-A750-BF7A4AEFF49B@oracle.com> Message-ID: <38632C13-C2B2-48ED-9DD1-618D84DF958E@oracle.com> I reviewed all four changes and they look good. I'll push them tomorrow. -- Chris On Jan 7, 2013, at 2:51 PM, Christian Thalinger wrote: > 8005820: Shark: enable JSR292 support > > On Dec 10, 2012, at 12:00 PM, Roman Kennke wrote: > >> Am Freitag, den 07.12.2012, 16:06 -0800 schrieb John Rose: >>> On Dec 6, 2012, at 3:08 PM, Roman Kennke wrote: >>> >>>> Thanks a lot for your explanations, it's really helpful. I would >>>> like to >>>> (potentially) contribute to the HSI wiki, if you want to give me >>>> access :-) >>> >>> Good! Is rkennke at gmail.com your Oracle SSO login? If so I'll add you >>> to the wiki editors. If not, let me know the login you'll be using >>> with the wiki. ? John >> >> My Oracle login is roman at kennke.org . Thanks for adding me! >> >> About the patches, do I need to do anything? Should I enter them in >> OpenJDK bugzilla or how can I move them forward? >> >> Roman >> >> > From david.r.chase at oracle.com Thu Jan 10 17:17:47 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 10 Jan 2013 20:17:47 -0500 Subject: Request for reviews (S) 8005821 : C2: -XX:+PrintIntrinsics is broken In-Reply-To: <77195CC6-A945-463F-A95D-6CC095B43240@oracle.com> References: <77195CC6-A945-463F-A95D-6CC095B43240@oracle.com> Message-ID: <0EAE75B6-07C0-43ED-B19B-EBA5D87BE0F9@oracle.com> >> Webrev: http://cr.openjdk.java.net/~drchase/8005821/webrev.00/ > > Can you please verify that +TraceTypeProfile with -PrintInlining works? LD_LIBRARY_PATH=. ./gamma -Xcomp -XX:-TieredCompilation -XX:+TraceTypeProfile -XX:-PrintInlining -classpath ~ Properties it works. From john.coomes at oracle.com Thu Jan 10 20:37:45 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:37:45 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b72 for changeset c1be681d80a1 Message-ID: <20130111043745.4D6FD471C2@hg.openjdk.java.net> Changeset: f03f90a4308d Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/f03f90a4308d Added tag jdk8-b72 for changeset c1be681d80a1 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:37:48 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:37:48 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b72 for changeset cb40427f4714 Message-ID: <20130111043751.65F20471C3@hg.openjdk.java.net> Changeset: 191afde59e7b Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/191afde59e7b Added tag jdk8-b72 for changeset cb40427f4714 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:37:55 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:37:55 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b72 for changeset bdf2af722a6b Message-ID: <20130111043804.BD62B471C4@hg.openjdk.java.net> Changeset: 84946404d1e1 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/84946404d1e1 Added tag jdk8-b72 for changeset bdf2af722a6b ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:38:08 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:38:08 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b72 for changeset d9707230294d Message-ID: <20130111043813.F1FBF471C5@hg.openjdk.java.net> Changeset: c606f644a5d9 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/c606f644a5d9 Added tag jdk8-b72 for changeset d9707230294d ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:38:20 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:38:20 +0000 Subject: hg: hsx/hotspot-comp/jdk: Added tag jdk8-b72 for changeset 32a57e645e01 Message-ID: <20130111043847.8B740471C6@hg.openjdk.java.net> Changeset: c9a914b11436 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c9a914b11436 Added tag jdk8-b72 for changeset 32a57e645e01 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:39:48 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:39:48 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b72 for changeset 6f0986ed9b7e Message-ID: <20130111043954.58FE6471C7@hg.openjdk.java.net> Changeset: 45fed5cfd1c3 Author: katleman Date: 2013-01-10 09:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/45fed5cfd1c3 Added tag jdk8-b72 for changeset 6f0986ed9b7e ! .hgtags From alejandro.murillo at oracle.com Fri Jan 11 05:39:49 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 11 Jan 2013 13:39:49 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 36 new changesets Message-ID: <20130111134109.338D9471E7@hg.openjdk.java.net> Changeset: 79f492f184d0 Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/79f492f184d0 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMetadata.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java ! agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! agent/src/share/native/sadis.c ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/runtime/os_ext.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! test/runtime/7158804/Test7158804.sh Changeset: e94068d4ff52 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e94068d4ff52 Merge ! src/share/vm/classfile/classLoaderData.hpp Changeset: 0847210f8548 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0847210f8548 Added tag jdk8-b70 for changeset e94068d4ff52 ! .hgtags Changeset: d5cb5830f570 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d5cb5830f570 Added tag jdk8-b71 for changeset 0847210f8548 ! .hgtags Changeset: 11619f33cd68 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/11619f33cd68 Added tag jdk8-b72 for changeset d5cb5830f570 ! .hgtags Changeset: e51c9860cf66 Author: jmasa Date: 2012-12-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e51c9860cf66 8005082: NPG: Add specialized Metachunk sizes for reflection and anonymous classloaders Reviewed-by: johnc, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/globals.hpp Changeset: 1de1b145f6bc Author: jmasa Date: 2012-12-26 15:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1de1b145f6bc 8005486: NPG: Incorrect assertion in ChunkManager::list_index() Reviewed-by: coleenp ! src/share/vm/memory/metaspace.cpp Changeset: b735136e0d82 Author: johnc Date: 2013-01-02 11:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b735136e0d82 8004132: SerialGC: ValidateMarkSweep broken when running GCOld Summary: Remove bit-rotten ValidateMarkSweep functionality and flag. Reviewed-by: johnc, jmasa Contributed-by: tamao ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 37f7535e5f18 Author: johnc Date: 2012-12-21 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/37f7535e5f18 8001424: G1: Rename certain G1-specific flags Summary: Rename G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, and G1OldCSetRegionLiveThresholdPercent to G1NewSizePercent, G1MaxNewSizePercent, and G1MixedGCLiveThresholdPercent respectively. The previous names are no longer accepted. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d275c3dc73e6 Author: johnc Date: 2013-01-03 16:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d275c3dc73e6 8004816: G1: Kitchensink failures after marking stack changes Summary: Reset the marking state, including the mark stack overflow flag, in the event of a marking stack overflow during serial reference processing. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: ca0a78017dc7 Author: brutisso Date: 2012-12-30 08:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ca0a78017dc7 8005396: Use ParNew with only one thread instead of DefNew as default for CMS on single CPU machines Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/runtime/arguments.cpp Changeset: e0ab18eafbde Author: brutisso Date: 2013-01-04 11:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e0ab18eafbde 8003820: Deprecate untested and rarely used GC combinations Summary: Log warning messages for DefNew+CMS and ParNew+SerialOld Reviewed-by: ysr, jwilhelm, jcoomes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: c98b676a98b4 Author: brutisso Date: 2013-01-04 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c98b676a98b4 8003822: Deprecate the incremental mode of CMS Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp Changeset: 6e9174173e00 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6e9174173e00 8000325: Change default for CMSClassUnloadingEnabled to true Reviewed-by: stefank, ysr ! src/share/vm/runtime/globals.hpp Changeset: 0b54ffe4c2d3 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0b54ffe4c2d3 8005672: Clean up some changes to GC logging with GCCause's Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 7d42f3b08300 Author: dcubed Date: 2012-12-19 10:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7d42f3b08300 8005044: remove crufty '_g' support from HS runtime code Summary: Phase 2 is removing '_g' support from the Runtime code. Reviewed-by: dcubed, coleenp, hseigel Contributed-by: ron.durbin at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/vm/runtime/arguments.cpp Changeset: 35431a769282 Author: stefank Date: 2012-12-20 10:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/35431a769282 8004823: Add VM support for type annotation reflection Reviewed-by: dholmes, coleenp Contributed-by: joel.franck at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 4daebd4cc1dd Author: minqi Date: 2012-12-24 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4daebd4cc1dd Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/arguments.cpp Changeset: cc6a617fffd2 Author: coleenp Date: 2013-01-02 20:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cc6a617fffd2 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with CompressedOops and KlassPtrs Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive Reviewed-by: twisti, jrose ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.inline.hpp Changeset: 6c3f47d964f3 Author: hseigel Date: 2013-01-07 15:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6c3f47d964f3 8003705: CDS failed on Windows: can not map in the CDS. Summary: Map memory only once to prevent 'already mapped' failures. Reviewed-by: acorn, zgu ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 561148896559 Author: hseigel Date: 2013-01-08 13:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/561148896559 8005076: Creating a CDS archive with one alignment and running another causes a crash. Summary: Save the alignment when writing the CDS and compare it when reading the CDS. Reviewed-by: kvn, coleenp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ade95d680b42 Author: coleenp Date: 2013-01-08 14:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ade95d680b42 8004728: Add hotspot support for parameter reflection Summary: Add hotspot support for parameter reflection Reviewed-by: acorn, jrose, coleenp Contributed-by: eric.mccorkle at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp Changeset: 185a2c979a0e Author: coleenp Date: 2013-01-08 13:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/185a2c979a0e Merge Changeset: ecd24264898b Author: zgu Date: 2013-01-08 14:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ecd24264898b 8005048: NMT: #loaded classes needs to just show the # defined classes Summary: Count number of instance classes so that it matches class metadata size Reviewed-by: coleenp, acorn ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 37a3e8b7a1e9 Author: zgu Date: 2013-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/37a3e8b7a1e9 Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 0c93d4818214 Author: zgu Date: 2013-01-08 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0c93d4818214 Merge Changeset: 1f6d10b4cc0c Author: acorn Date: 2013-01-09 18:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1f6d10b4cc0c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 608b2e8a0063 Author: bpittore Date: 2013-01-03 15:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/608b2e8a0063 8004051: assert(_oprs_len[mode] < maxNumberOfOperands) failed: array overflow Summary: assert is triggered when number of register based arguments passed to a java method exceeds 16. Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.hpp Changeset: 0c8717a92b2d Author: jiangli Date: 2013-01-08 13:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0c8717a92b2d 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. Summary: Use methodHandle. Reviewed-by: coleenp, acorn, twisti, sspitsyn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 18c3c3fa291b Author: dlong Date: 2013-01-09 21:18 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/18c3c3fa291b Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 4c8bf5e55392 Author: brutisso Date: 2013-01-09 09:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4c8bf5e55392 8005489: VM hangs during GC with ParallelGC and ParallelGCThreads=0 Summary: Print an error message and exit the VM if UseParallalGC is combined with ParllelGCThreads==0. Also reviewed by vitalyd at gmail.com. Reviewed-by: stefank, ehelin ! src/share/vm/runtime/arguments.cpp Changeset: b2fef6b220e9 Author: jmasa Date: 2013-01-10 07:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b2fef6b220e9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: f1c06dcee0b5 Author: kvn Date: 2013-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f1c06dcee0b5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 1e129851479e Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1e129851479e Merge Changeset: b5e6bec76f4a Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b5e6bec76f4a Added tag hs25-b15 for changeset 1e129851479e ! .hgtags Changeset: d58b7b43031b Author: amurillo Date: 2013-01-11 02:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d58b7b43031b 8006034: new hotspot build - hs25-b16 Reviewed-by: jcoomes ! make/hotspot_version From mike.duigou at oracle.com Thu Jan 10 15:27:42 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 10 Jan 2013 15:27:42 -0800 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <42CDC876-6474-44C9-948E-518C7229E141@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED61FA.2060900@oracle.com> <50ED6221.2020902@oracle.com> <50ED6365.2070003@oracle.com> <50ED647F.4070704@cs.oswego.edu> <50ED8357.6020403@oracle.com> <42CDC876-6474-44C9-948E-518C7229E141@oracle.com> Message-ID: All that was required was to sync jdk8/jdk8 (b71) -> lambda/lambda. This is now done. Mike On Jan 9 2013, at 10:32 , Mike Duigou wrote: > I can work on getting them in to lambda/lambda today as I was already planning to to jdk8/jdk8 -> lambda/lambda sync today. > > Mike > > On Jan 9 2013, at 06:48 , Chris Hegarty wrote: > >> On 09/01/2013 12:37, Doug Lea wrote: >>> On 01/09/13 07:32, Chris Hegarty wrote: >>> >>>>> Thanks, Chris. I think this had been already pushed by Vladimir: >>>>> http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cf5b18488d1 >>>> >>>> OK, so we got to wait for the next sync up to get these in jdk8/tl. >>>> >>> >>> Maybe you could coordinate to do the tl hotspot sync-up and >>> the lambda hotspot sync-up at the same time? This would avoid the >>> need for example of multiple commits/CRs of our AtomicLong updates. >> >> Oh, jdk8/tl seems to already have sync'ed the unsafe changes. So, we should only need one commit to sync'up the changes from lambda and move to unsafe.addAndGetXXX in jdk8/tl . Then lambda/lambda can sync with jdk8/tl. I can work on this. >> >> -Chris. >> >>> >>> -Doug >>> > From Ulf.Zibis at CoSoCo.de Fri Jan 11 10:19:04 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 11 Jan 2013 19:19:04 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50EFA768.40006@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> Message-ID: <50F05798.30306@CoSoCo.de> Hi Sherman, Am 11.01.2013 06:47, schrieb Xueming Shen: > (1) sp++ at Ln#159 probably can be moved into ln#155? the local sp here should > not change the real "sp" after "break+return". > (2) maybe the "overflowflag" can just be replaced by "CoderResult cr", with init value > of CoderResult.UNDERFLOW;", then "cr = CoderResult.OVERFLOW" at ln#182, and > simply "return cr" at ln#193, without another "if". I've enhanced your suggestions, see more below... Additionally, some part of encodeArrayLoop(...) maybe could be moved into a separate method, to be reused by encode(char[] src, int sp, int len, byte[] dst). Some of the re-engineering could be adapted to the Decoder methods. > I'm surprised we only get 1.6% boost. Maybe it is worth measuring the performance > of some "small" buf/array encoding? I'm a little concerned that the overhead may > slow down the small size buf/array encoding. There is a simple benchmark for String > en/decoding at test/sun/nio/cs/StrCodingBenchmark. I think we should balance 4 cases in rating the performance: a) few loops, small buf/array b) few loops, big buf/array c) many loops, small buf/array d) many loops, big buf/array In a), b) the loop surrounding code will not be JIT-compiled, so should be optimized for interpreter. In c) d) the loop surrounding code *may be* JIT-compiled and consequtively inline the inner loop, should be verified. In b), d) the small inner loop, as demonstrated below, will be JIT-compiled, regardless if moved into separate method. -Ulf 1) Check for (sp >= sl) is superfluous. ====================================== private static int copyISOs( char[] sa, int sp, byte[] da, int dp, int len) { int i = 0; for (; i < len; i++) { char c = sa[sp++]; // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, would be fastest if ((byte)(c >> 8) != 0) // temporary replacement, fast byte-length operation on x86 break; da[dp++] = (byte)c; } return i; } private CoderResult encodeArrayLoop( CharBuffer src, ByteBuffer dst) { char[] sa = src.array(); int soff = src.arrayOffset(); int sp = soff + src.position(); int sr = src.remaining(); int sl = sp + sr; byte[] da = dst.array(); int doff = dst.arrayOffset(); int dp = doff + dst.position(); int dr = dst.remaining(); CoderResult cr; if (dr < sr) { sr = dr; cr = CoderResult.OVERFLOW; } else cr = CoderResult.UNDERFLOW; try { int ret = copyISOs(sa, sp, da, dp, sr); sp = sp + ret; dp = dp + ret; if (ret != sr) { if (sgp.parse(sa[sp], sa, sp, sl) < 0) return sgp.error(); return sgp.unmappableResult(); } return cr; } finally { src.position(sp - soff); dst.position(dp - doff); } } 2) Avoids sp, dp to be recalculated; shorter surrounding code -> best chance to become JIT-compiled. ====================================== // while inlinig, JIT will erase the surrounding int[] p private static boolean copyISOs( char[] sa, byte[] da, final int[] p, int sl) { for (int sp = p[0], dp = p[1]; sp < sl; sp++) { char c = sa[sp]; // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, would be fastest if ((byte)(c >> 8) != 0) // temporary replacement, fast byte-length operation on x86 return false; da[dp++] = (byte)c; } return true; } private CoderResult encodeArrayLoop( CharBuffer src, ByteBuffer dst) { char[] sa = src.array(); int soff = src.arrayOffset(); int sp = soff + src.position(); int sr = src.remaining(); byte[] da = dst.array(); int doff = dst.arrayOffset(); int dp = doff + dst.position(); int dr = dst.remaining(); CoderResult cr; if (dr < sr) { sr = dr; cr = CoderResult.OVERFLOW; } else cr = CoderResult.UNDERFLOW; try { int sl = sp + sr; final int[] p = { sp, dp }; if (!copyISOs(sa, da, p, sl)) { if (sgp.parse(sa[sp], sa, sp, sl) < 0) return sgp.error(); return sgp.unmappableResult(); } return cr; } finally { src.position(sp - soff); dst.position(dp - doff); } } 3) No more needs try...finally block. ====================================== private CoderResult encodeArrayLoop( CharBuffer src, ByteBuffer dst) { char[] sa = src.array(); int soff = src.arrayOffset(); int sp = soff + src.position(); int sr = src.remaining(); byte[] da = dst.array(); int doff = dst.arrayOffset(); int dp = doff + dst.position(); int dr = dst.remaining(); CoderResult cr; if (dr < sr) { sr = dr; cr = CoderResult.OVERFLOW; } else cr = CoderResult.UNDERFLOW; int sl = sp + sr; for (; sp < sl; sp++) { char c = sa[sp]; // if (c & '\uFF00' != 0) { // needs bug 6935994 to be fixed, would be fastest if ((byte)(c >> 8) != 0) { // temporary replacement, fast byte-length operation on x86 cr = null; break; } da[dp++] = (byte)c; } src.position(sp - soff); dst.position(dp - doff); return result(cr, sa, sp, sl); } // if adapted, maybe could also be reused in encodeBufferLoop() private static CoderResult result(CoderResult cr, byte[] sa, int sp, int sl) { return cr != null ? cr : sgp.parse(sa[sp], sa, sp, sl) < 0 ? sgp.error(); : sgp.unmappableResult(); } From christian.thalinger at oracle.com Fri Jan 11 14:05:19 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Jan 2013 14:05:19 -0800 Subject: RFR (XS): 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Message-ID: <5C541108-3EF1-4A1E-BE5D-900DAD5E00B2@oracle.com> http://cr.openjdk.java.net/~twisti/8006109 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Reviewed-by: The problem are unloaded types. Two different ciType instances of the same class type may have different loaders and protection domains depending on the accessing class. The fix is to relax the assert for unloaded types. src/share/vm/opto/doCall.cpp src/share/vm/ci/ciType.cpp src/share/vm/ci/ciType.hpp From christian.thalinger at oracle.com Fri Jan 11 14:10:24 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Jan 2013 14:10:24 -0800 Subject: RFR (XXS): 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 In-Reply-To: <50EF624C.5040001@oracle.com> References: <1EACFC52-FFC9-4806-A2E3-5DABDE62739F@oracle.com> <50EF624C.5040001@oracle.com> Message-ID: On Jan 10, 2013, at 4:52 PM, Azeem Jiva wrote: > Looks good... Thank you, Azeem. Unfortunately you're not an HSX reviewer according to the census: http://openjdk.java.net/census#azeemj -- Chris > > On 1/10/2013 4:10 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8006031/ >> >> >> 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 >> Reviewed-by: >> >> Remove "return false;" leftover. >> >> src/share/vm/opto/library_call.cpp >> >> > > -- > Azeem Jiva > @javawithjiva > From vladimir.kozlov at oracle.com Fri Jan 11 14:14:15 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jan 2013 14:14:15 -0800 Subject: RFR (XS): 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types In-Reply-To: <5C541108-3EF1-4A1E-BE5D-900DAD5E00B2@oracle.com> References: <5C541108-3EF1-4A1E-BE5D-900DAD5E00B2@oracle.com> Message-ID: <50F08EB7.7000100@oracle.com> Looks good, just shift/indent err_msg_res a little to be under "(". Thanks, Vladimir On 1/11/13 2:05 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8006109 > > 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types > Reviewed-by: > > The problem are unloaded types. Two different ciType instances of the > same class type may have different loaders and protection domains > depending on the accessing class. > > The fix is to relax the assert for unloaded types. > > src/share/vm/opto/doCall.cpp > src/share/vm/ci/ciType.cpp > src/share/vm/ci/ciType.hpp > From christian.thalinger at oracle.com Fri Jan 11 14:48:58 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Jan 2013 14:48:58 -0800 Subject: RFR (XS): 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types In-Reply-To: <50F08EB7.7000100@oracle.com> References: <5C541108-3EF1-4A1E-BE5D-900DAD5E00B2@oracle.com> <50F08EB7.7000100@oracle.com> Message-ID: On Jan 11, 2013, at 2:14 PM, Vladimir Kozlov wrote: > Looks good, just shift/indent err_msg_res a little to be under "(". Done. Thanks. -- Chris > > Thanks, > Vladimir > > On 1/11/13 2:05 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8006109 >> >> 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types >> Reviewed-by: >> >> The problem are unloaded types. Two different ciType instances of the >> same class type may have different loaders and protection domains >> depending on the accessing class. >> >> The fix is to relax the assert for unloaded types. >> >> src/share/vm/opto/doCall.cpp >> src/share/vm/ci/ciType.cpp >> src/share/vm/ci/ciType.hpp >> From christian.thalinger at oracle.com Fri Jan 11 14:53:41 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Jan 2013 14:53:41 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F05798.30306@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> Message-ID: <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> On Jan 11, 2013, at 10:19 AM, Ulf Zibis wrote: > Hi Sherman, > > Am 11.01.2013 06:47, schrieb Xueming Shen: >> (1) sp++ at Ln#159 probably can be moved into ln#155? the local sp here should >> not change the real "sp" after "break+return". >> (2) maybe the "overflowflag" can just be replaced by "CoderResult cr", with init value >> of CoderResult.UNDERFLOW;", then "cr = CoderResult.OVERFLOW" at ln#182, and >> simply "return cr" at ln#193, without another "if". > > I've enhanced your suggestions, see more below... > Additionally, some part of encodeArrayLoop(...) maybe could be moved into a separate method, to be reused by encode(char[] src, int sp, int len, byte[] dst). > Some of the re-engineering could be adapted to the Decoder methods. > >> I'm surprised we only get 1.6% boost. Maybe it is worth measuring the performance >> of some "small" buf/array encoding? I'm a little concerned that the overhead may >> slow down the small size buf/array encoding. There is a simple benchmark for String >> en/decoding at test/sun/nio/cs/StrCodingBenchmark. > > I think we should balance 4 cases in rating the performance: > a) few loops, small buf/array > b) few loops, big buf/array > c) many loops, small buf/array > d) many loops, big buf/array > In a), b) the loop surrounding code will not be JIT-compiled, so should be optimized for interpreter. > In c) d) the loop surrounding code *may be* JIT-compiled and consequtively inline the inner loop, should be verified. > In b), d) the small inner loop, as demonstrated below, will be JIT-compiled, regardless if moved into separate method. But you guys noticed that sentence in the initial review request, right? "Move encoding loop into separate method for which VM will use intrinsic on x86." Just wanted to make sure ;-) -- Chris > > -Ulf > > 1) Check for (sp >= sl) is superfluous. > ====================================== > private static int copyISOs( > char[] sa, int sp, byte[] da, int dp, int len) { > int i = 0; > for (; i < len; i++) { > char c = sa[sp++]; > // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, would be fastest > if ((byte)(c >> 8) != 0) // temporary replacement, fast byte-length operation on x86 > break; > da[dp++] = (byte)c; > } > return i; > } > > private CoderResult encodeArrayLoop( > CharBuffer src, ByteBuffer dst) { > char[] sa = src.array(); > int soff = src.arrayOffset(); > int sp = soff + src.position(); > int sr = src.remaining(); > int sl = sp + sr; > byte[] da = dst.array(); > int doff = dst.arrayOffset(); > int dp = doff + dst.position(); > int dr = dst.remaining(); > CoderResult cr; > if (dr < sr) { > sr = dr; > cr = CoderResult.OVERFLOW; > } else > cr = CoderResult.UNDERFLOW; > try { > int ret = copyISOs(sa, sp, da, dp, sr); > sp = sp + ret; > dp = dp + ret; > if (ret != sr) { > if (sgp.parse(sa[sp], sa, sp, sl) < 0) > return sgp.error(); > return sgp.unmappableResult(); > } > return cr; > } finally { > src.position(sp - soff); > dst.position(dp - doff); > } > } > > 2) Avoids sp, dp to be recalculated; shorter surrounding code -> best chance to become JIT-compiled. > ====================================== > // while inlinig, JIT will erase the surrounding int[] p > private static boolean copyISOs( > char[] sa, byte[] da, final int[] p, int sl) { > for (int sp = p[0], dp = p[1]; sp < sl; sp++) { > char c = sa[sp]; > // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, would be fastest > if ((byte)(c >> 8) != 0) // temporary replacement, fast byte-length operation on x86 > return false; > da[dp++] = (byte)c; > } > return true; > } > > private CoderResult encodeArrayLoop( > CharBuffer src, ByteBuffer dst) { > char[] sa = src.array(); > int soff = src.arrayOffset(); > int sp = soff + src.position(); > int sr = src.remaining(); > byte[] da = dst.array(); > int doff = dst.arrayOffset(); > int dp = doff + dst.position(); > int dr = dst.remaining(); > CoderResult cr; > if (dr < sr) { > sr = dr; > cr = CoderResult.OVERFLOW; > } else > cr = CoderResult.UNDERFLOW; > try { > int sl = sp + sr; > final int[] p = { sp, dp }; > if (!copyISOs(sa, da, p, sl)) { > if (sgp.parse(sa[sp], sa, sp, sl) < 0) > return sgp.error(); > return sgp.unmappableResult(); > } > return cr; > } finally { > src.position(sp - soff); > dst.position(dp - doff); > } > } > > 3) No more needs try...finally block. > ====================================== > private CoderResult encodeArrayLoop( > CharBuffer src, ByteBuffer dst) { > char[] sa = src.array(); > int soff = src.arrayOffset(); > int sp = soff + src.position(); > int sr = src.remaining(); > byte[] da = dst.array(); > int doff = dst.arrayOffset(); > int dp = doff + dst.position(); > int dr = dst.remaining(); > CoderResult cr; > if (dr < sr) { > sr = dr; > cr = CoderResult.OVERFLOW; > } else > cr = CoderResult.UNDERFLOW; > int sl = sp + sr; > for (; sp < sl; sp++) { > char c = sa[sp]; > // if (c & '\uFF00' != 0) { // needs bug 6935994 to be fixed, would be fastest > if ((byte)(c >> 8) != 0) { // temporary replacement, fast byte-length operation on x86 > cr = null; > break; > } > da[dp++] = (byte)c; > } > src.position(sp - soff); > dst.position(dp - doff); > return result(cr, sa, sp, sl); > } > > // if adapted, maybe could also be reused in encodeBufferLoop() > private static CoderResult result(CoderResult cr, byte[] sa, int sp, int sl) { > return cr != null ? cr : > sgp.parse(sa[sp], sa, sp, sl) < 0 > ? sgp.error(); > : sgp.unmappableResult(); > } > From vladimir.x.ivanov at oracle.com Fri Jan 11 16:25:13 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 12 Jan 2013 03:25:13 +0300 Subject: RFR (XS): 8006095: C1: SIGSEGV w/ -XX:+LogCompilation Message-ID: <50F0AD69.1010806@oracle.com> http://cr.openjdk.java.net/~vlivanov/8006095/webrev.00 17 lines changed: 10 ins; 3 del; 4 mod The crash occurs when C1 compilation fails and bails out during method inlining attempt. The reason is that _inline_bailout_msg == NULL during an attempt to print failure message in the log. Fixed by avoiding printing inlining message in the compiler log during bailout and adding additional defensive checks in GraphBuilder::print_inlining method. Testing: failing test case. Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Fri Jan 11 15:46:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jan 2013 15:46:57 -0800 Subject: RFR (XS): 8006095: C1: SIGSEGV w/ -XX:+LogCompilation In-Reply-To: <50F0AD69.1010806@oracle.com> References: <50F0AD69.1010806@oracle.com> Message-ID: <50F0A471.1090707@oracle.com> Looks good. Thanks, Vladimir On 1/11/13 4:25 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8006095/webrev.00 > 17 lines changed: 10 ins; 3 del; 4 mod > > The crash occurs when C1 compilation fails and bails out during method > inlining attempt. The reason is that _inline_bailout_msg == NULL during > an attempt to print failure message in the log. > > Fixed by avoiding printing inlining message in the compiler log during > bailout and adding additional defensive checks in > GraphBuilder::print_inlining method. > > Testing: failing test case. > > Best regards, > Vladimir Ivanov From vitalyd at gmail.com Fri Jan 11 16:16:42 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 11 Jan 2013 19:16:42 -0500 Subject: RFR (XS): 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types In-Reply-To: References: <5C541108-3EF1-4A1E-BE5D-900DAD5E00B2@oracle.com> <50F08EB7.7000100@oracle.com> Message-ID: Chris, Do you need a ResourceMark for the new name() call? Thanks Sent from my phone On Jan 11, 2013 5:44 PM, "Christian Thalinger" < christian.thalinger at oracle.com> wrote: > > On Jan 11, 2013, at 2:14 PM, Vladimir Kozlov > wrote: > > > Looks good, just shift/indent err_msg_res a little to be under "(". > > Done. Thanks. -- Chris > > > > > Thanks, > > Vladimir > > > > On 1/11/13 2:05 PM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/8006109 > >> > >> 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: > assert(rtype == ctype) failed: mismatched return types > >> Reviewed-by: > >> > >> The problem are unloaded types. Two different ciType instances of the > >> same class type may have different loaders and protection domains > >> depending on the accessing class. > >> > >> The fix is to relax the assert for unloaded types. > >> > >> src/share/vm/opto/doCall.cpp > >> src/share/vm/ci/ciType.cpp > >> src/share/vm/ci/ciType.hpp > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130111/d7a68f80/attachment-0001.html From christian.thalinger at oracle.com Fri Jan 11 16:27:33 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 12 Jan 2013 00:27:33 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Message-ID: <20130112002735.688534720F@hg.openjdk.java.net> Changeset: a3f92e6c0274 Author: twisti Date: 2013-01-11 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a3f92e6c0274 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp From christian.thalinger at oracle.com Fri Jan 11 16:40:56 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Jan 2013 16:40:56 -0800 Subject: RFR (XS): 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types In-Reply-To: References: <5C541108-3EF1-4A1E-BE5D-900DAD5E00B2@oracle.com> <50F08EB7.7000100@oracle.com> Message-ID: On Jan 11, 2013, at 4:16 PM, Vitaly Davidovich wrote: > Chris, > > Do you need a ResourceMark for the new name() call? You mean in ciType::print_name_on? Wouldn't hurt. -- Chris > > Thanks > > Sent from my phone > > On Jan 11, 2013 5:44 PM, "Christian Thalinger" wrote: > > On Jan 11, 2013, at 2:14 PM, Vladimir Kozlov wrote: > > > Looks good, just shift/indent err_msg_res a little to be under "(". > > Done. Thanks. -- Chris > > > > > Thanks, > > Vladimir > > > > On 1/11/13 2:05 PM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/8006109 > >> > >> 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types > >> Reviewed-by: > >> > >> The problem are unloaded types. Two different ciType instances of the > >> same class type may have different loaders and protection domains > >> depending on the accessing class. > >> > >> The fix is to relax the assert for unloaded types. > >> > >> src/share/vm/opto/doCall.cpp > >> src/share/vm/ci/ciType.cpp > >> src/share/vm/ci/ciType.hpp > >> > From vitalyd at gmail.com Fri Jan 11 16:38:42 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 11 Jan 2013 19:38:42 -0500 Subject: RFR (XS): 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types In-Reply-To: References: <5C541108-3EF1-4A1E-BE5D-900DAD5E00B2@oracle.com> <50F08EB7.7000100@oracle.com> Message-ID: Yup, there. The char[] allocated in as_C_string() is allocated out of resource area, so thought it'd be a good idea. Sent from my phone On Jan 11, 2013 7:36 PM, "Christian Thalinger" < christian.thalinger at oracle.com> wrote: > > On Jan 11, 2013, at 4:16 PM, Vitaly Davidovich wrote: > > > Chris, > > > > Do you need a ResourceMark for the new name() call? > > You mean in ciType::print_name_on? Wouldn't hurt. > > -- Chris > > > > > Thanks > > > > Sent from my phone > > > > On Jan 11, 2013 5:44 PM, "Christian Thalinger" < > christian.thalinger at oracle.com> wrote: > > > > On Jan 11, 2013, at 2:14 PM, Vladimir Kozlov > wrote: > > > > > Looks good, just shift/indent err_msg_res a little to be under "(". > > > > Done. Thanks. -- Chris > > > > > > > > Thanks, > > > Vladimir > > > > > > On 1/11/13 2:05 PM, Christian Thalinger wrote: > > >> http://cr.openjdk.java.net/~twisti/8006109 > > >> > > >> 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: > assert(rtype == ctype) failed: mismatched return types > > >> Reviewed-by: > > >> > > >> The problem are unloaded types. Two different ciType instances of the > > >> same class type may have different loaders and protection domains > > >> depending on the accessing class. > > >> > > >> The fix is to relax the assert for unloaded types. > > >> > > >> src/share/vm/opto/doCall.cpp > > >> src/share/vm/ci/ciType.cpp > > >> src/share/vm/ci/ciType.hpp > > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130111/f5276b99/attachment.html From christian.thalinger at oracle.com Fri Jan 11 19:28:15 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 12 Jan 2013 03:28:15 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 4 new changesets Message-ID: <20130112032823.0B1A34721C@hg.openjdk.java.net> Changeset: f9bda35f4226 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f9bda35f4226 8005816: Shark: fix volatile float field access Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkBlock.cpp Changeset: c566b81b3323 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c566b81b3323 8005817: Shark: implement deoptimization support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: c095a7f289aa Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c095a7f289aa 8005818: Shark: fix OSR for non-empty incoming stack Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInvariants.hpp Changeset: 606eada1bf86 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/606eada1bf86 8005820: Shark: enable JSR292 support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp From christian.thalinger at oracle.com Fri Jan 11 20:03:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Jan 2013 20:03:02 -0800 Subject: RFR (XXS): 8006127: remove printing code added with 8006031 Message-ID: http://cr.openjdk.java.net/~twisti/8006127 8006127: remove printing code added with 8006031 Reviewed-by: src/share/vm/opto/library_call.cpp From vladimir.kozlov at oracle.com Fri Jan 11 20:00:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jan 2013 20:00:40 -0800 Subject: RFR (XXS): 8006127: remove printing code added with 8006031 In-Reply-To: References: Message-ID: <50F0DFE8.5030901@oracle.com> Good. Vladimir On 1/11/13 8:03 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8006127 > > 8006127: remove printing code added with 8006031 > Reviewed-by: > > src/share/vm/opto/library_call.cpp > From christian.thalinger at oracle.com Fri Jan 11 22:10:32 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 12 Jan 2013 06:10:32 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8006127: remove printing code added with 8006031 Message-ID: <20130112061034.BFDFF47220@hg.openjdk.java.net> Changeset: 6d1f5516534e Author: twisti Date: 2013-01-11 20:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6d1f5516534e 8006127: remove printing code added with 8006031 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp From Ulf.Zibis at CoSoCo.de Sat Jan 12 00:37:33 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 12 Jan 2013 09:37:33 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> Message-ID: <50F120CD.6020207@CoSoCo.de> Am 11.01.2013 23:53, schrieb Christian Thalinger: > But you guys noticed that sentence in the initial review request, right? > > "Move encoding loop into separate method for which VM will use intrinsic on x86." > > Just wanted to make sure ;-) Good question Christian! This is, how it shows up to me: 1) The bug synopsis is unspecific about intrinsc, so ... 2) the mentioned 1st sentence could be one of many solutions. 3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 ==> This bug is not available. 4) What specific operation should be done by the intrinsic, i.e. is there a fixed API for that method ??? 5) Can an intrinsic write back more than 1 value (see my hack via int[] p) ? 6) Vladimir's webrev shows an integer as return type for that method, I've added a variant with boolean return type, and the code from my last approach could be transformed to a method with Object return type. ... so waiting for Vladimir's feedback :-[ (especially on performance/hsdis results) (Can someone push the bug to the public?) -Ulf From vladimir.x.ivanov at oracle.com Mon Jan 14 08:12:56 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Jan 2013 19:12:56 +0300 Subject: RFR (XS): 8006095: C1: SIGSEGV w/ -XX:+LogCompilation In-Reply-To: <50F0A471.1090707@oracle.com> References: <50F0AD69.1010806@oracle.com> <50F0A471.1090707@oracle.com> Message-ID: <50F42E88.3080300@oracle.com> Thank you, Vladimir. Anybody else wants to look at these changes? I need one more review. Best regards, Vladimir Ivanov On 1/12/13 2:46 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 1/11/13 4:25 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8006095/webrev.00 >> 17 lines changed: 10 ins; 3 del; 4 mod >> >> The crash occurs when C1 compilation fails and bails out during method >> inlining attempt. The reason is that _inline_bailout_msg == NULL during >> an attempt to print failure message in the log. >> >> Fixed by avoiding printing inlining message in the compiler log during >> bailout and adding additional defensive checks in >> GraphBuilder::print_inlining method. >> >> Testing: failing test case. >> >> Best regards, >> Vladimir Ivanov From roland.westrelin at oracle.com Mon Jan 14 07:21:52 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 Jan 2013 16:21:52 +0100 Subject: RFR (XS): 8006095: C1: SIGSEGV w/ -XX:+LogCompilation In-Reply-To: <50F0AD69.1010806@oracle.com> References: <50F0AD69.1010806@oracle.com> Message-ID: > http://cr.openjdk.java.net/~vlivanov/8006095/webrev.00 It looks good to me. Roland. From vladimir.x.ivanov at oracle.com Mon Jan 14 09:12:15 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Jan 2013 20:12:15 +0300 Subject: RFR (XS): 8006095: C1: SIGSEGV w/ -XX:+LogCompilation In-Reply-To: References: <50F0AD69.1010806@oracle.com> Message-ID: <50F43C6F.3010101@oracle.com> Thank you, Roland. Best regards, Vladimir Ivanov On 1/14/13 6:21 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~vlivanov/8006095/webrev.00 > > It looks good to me. > > Roland. > From vladimir.x.ivanov at oracle.com Mon Jan 14 13:24:26 2013 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Mon, 14 Jan 2013 21:24:26 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8006095: C1: SIGSEGV w/ -XX:+LogCompilation Message-ID: <20130114212431.2D60847267@hg.openjdk.java.net> Changeset: d92fa52a5d03 Author: vlivanov Date: 2013-01-14 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d92fa52a5d03 8006095: C1: SIGSEGV w/ -XX:+LogCompilation Summary: avoid printing inlining decision when compilation fails Reviewed-by: kvn, roland ! src/share/vm/c1/c1_GraphBuilder.cpp From christian.thalinger at oracle.com Tue Jan 15 14:10:57 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 15 Jan 2013 22:10:57 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Message-ID: <20130115221102.9A5CC472B7@hg.openjdk.java.net> Changeset: f1de9dbc914e Author: twisti Date: 2013-01-15 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f1de9dbc914e 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Reviewed-by: kvn ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/opto/doCall.cpp From vladimir.kozlov at oracle.com Tue Jan 15 14:37:39 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Jan 2013 14:37:39 -0800 Subject: Request for reviews (S) 8005821 : C2: -XX:+PrintIntrinsics is broken In-Reply-To: <77195CC6-A945-463F-A95D-6CC095B43240@oracle.com> References: <77195CC6-A945-463F-A95D-6CC095B43240@oracle.com> Message-ID: <50F5DA33.3050009@oracle.com> C->print_inlining_stream() is called in trace_type_profile() only with PrintInlining, so this code is safe. I am pushing this fix for David. Thanks, Vladimir On 1/10/13 3:07 PM, Christian Thalinger wrote: > > On Jan 10, 2013, at 7:58 AM, David Chase wrote: > >> >> Webrev: http://cr.openjdk.java.net/~drchase/8005821/webrev.00/ > > Can you please verify that +TraceTypeProfile with -PrintInlining works? > > void trace_type_profile(Compile* C, ciMethod *method, int depth, int bci, ciMethod *prof_method, ciKlass *prof_klass, int site_count, int receiver_count) { > if (TraceTypeProfile || PrintInlining NOT_PRODUCT(|| PrintOptoInlining)) { > > But I think it does. > > -- Chris > >> >> Bug appeared as part of incremental inlining; a print data structure was not initialized appropriately. >> >> Old behavior: -XX:+PrintIntrinsics would crash. >> New behavior: -XX:+PrintIntrinsics doesn't crash. >> >> Changes (all one-liners) >> (1) modify initialization flag to match new printing behavior (fixes crash) >> (2) modify dump_inlining method to also match new printing behavior (related behavioral glitch) >> (3) fixed indenting of line calling dump_inlining. >> >> Non-change (because someone will ask): >> Did NOT fix intending of 150-line block preceding (3). >> Body of block is aligned with surrounding code, but { and } are undented. >> These were (historically) added to run some destructors at the right place. >> >> David > From vladimir.kozlov at oracle.com Tue Jan 15 18:45:00 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 16 Jan 2013 02:45:00 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8005821: C2: -XX:+PrintIntrinsics is broken Message-ID: <20130116024505.70F1F472C4@hg.openjdk.java.net> Changeset: 5b8548391bf3 Author: kvn Date: 2013-01-15 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5b8548391bf3 8005821: C2: -XX:+PrintIntrinsics is broken Summary: Check all print inlining flags when processing inlining list. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! src/share/vm/opto/compile.cpp From pavel.punegov at oracle.com Wed Jan 16 04:09:15 2013 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 16 Jan 2013 16:09:15 +0400 Subject: RFR (XS): 8006095: C1: SIGSEGV w/ -XX:+LogCompilation In-Reply-To: <50F0AD69.1010806@oracle.com> References: <50F0AD69.1010806@oracle.com> Message-ID: <11228173.aHJytDvT68@trisuli> Hi, Is there any way to create a regression test from the test case provided in bug? On Saturday 12 January 2013 03:25:13 Vladimir Ivanov wrote: >http://cr.openjdk.java.net/~vlivanov/8006095/webrev.00 >17 lines changed: 10 ins; 3 del; 4 mod > >The crash occurs when C1 compilation fails and bails out during method >inlining attempt. The reason is that _inline_bailout_msg == NULL during >an attempt to print failure message in the log. > >Fixed by avoiding printing inlining message in the compiler log during >bailout and adding additional defensive checks in >GraphBuilder::print_inlining method. > >Testing: failing test case. > >Best regards, >Vladimir Ivanov -- Thanks, Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130116/fda4e48e/attachment.html From vladimir.x.ivanov at oracle.com Wed Jan 16 07:41:51 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 16 Jan 2013 18:41:51 +0300 Subject: RFR (XS): 8006095: C1: SIGSEGV w/ -XX:+LogCompilation In-Reply-To: <11228173.aHJytDvT68@trisuli> References: <50F0AD69.1010806@oracle.com> <11228173.aHJytDvT68@trisuli> Message-ID: <50F6CA3F.8010908@oracle.com> Pavel, I didn't find an easy way to create a reliable one - it should fail in a very precise place to fail the whole compilation during method inlining. Best regards, Vladimir Ivanov On 1/16/13 3:09 PM, Pavel Punegov wrote: > Hi, > > Is there any way to create a regression test from the test case provided > in bug? > > On Saturday 12 January 2013 03:25:13 Vladimir Ivanov wrote: > > >http://cr.openjdk.java.net/~vlivanov/8006095/webrev.00 > > >17 lines changed: 10 ins; 3 del; 4 mod > > > > > >The crash occurs when C1 compilation fails and bails out during method > > >inlining attempt. The reason is that _inline_bailout_msg == NULL during > > >an attempt to print failure message in the log. > > > > > >Fixed by avoiding printing inlining message in the compiler log during > > >bailout and adding additional defensive checks in > > >GraphBuilder::print_inlining method. > > > > > >Testing: failing test case. > > > > > >Best regards, > > >Vladimir Ivanov > > -- > > Thanks, > > Pavel > From david.r.chase at oracle.com Wed Jan 16 08:44:16 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 16 Jan 2013 11:44:16 -0500 Subject: Request for reviews (S): 8006204: please JTREGify test/compiler/7190310/Test7190310.java Message-ID: <39E5E192-A9E0-4062-ACA4-77486D3C926E@oracle.com> http://cr.openjdk.java.net/~drchase/8006204/webrev.00/ pre-fix: Test7190310.java was a manual test because of timing issues -- failure is an infinite loop, but success may require more time than the default timeout (though usually it doesn't). A companion _unsafe test was already annotated correctly (no timeout needed) and already run automatically by jtreg. fix: Add proper jtreg annotations in the preceding comment, including an explicit timeout. post-fix: Both tests (Test7190310.java and Test7190310_unsafe.java) were observed to run in jtreg. Testing: local with jtreg and "jtreg -a" to verify that test is now automatic. JPRT passed. I tried to manually verify that JPRT ran both parts of this specific test, but could not figure out where (or if) this information was kept. From vladimir.kozlov at oracle.com Wed Jan 16 09:26:23 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Jan 2013 09:26:23 -0800 Subject: Request for reviews (S): 8006204: please JTREGify test/compiler/7190310/Test7190310.java In-Reply-To: <39E5E192-A9E0-4062-ACA4-77486D3C926E@oracle.com> References: <39E5E192-A9E0-4062-ACA4-77486D3C926E@oracle.com> Message-ID: <50F6E2BF.1020802@oracle.com> Looks good. Vladimir On 1/16/13 8:44 AM, David Chase wrote: > http://cr.openjdk.java.net/~drchase/8006204/webrev.00/ > > pre-fix: > Test7190310.java was a manual test because of timing issues -- failure is an infinite loop, but success may require more time than the default timeout (though usually it doesn't). > A companion _unsafe test was already annotated correctly (no timeout needed) and already run automatically by jtreg. > > fix: > Add proper jtreg annotations in the preceding comment, including an explicit timeout. > > post-fix: > Both tests (Test7190310.java and Test7190310_unsafe.java) were observed to run in jtreg. > > Testing: > local with jtreg and "jtreg -a" to verify that test is now automatic. > JPRT passed. > I tried to manually verify that JPRT ran both parts of this specific test, but could not figure out where (or if) this information was kept. > From christian.thalinger at oracle.com Wed Jan 16 10:30:09 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Jan 2013 10:30:09 -0800 Subject: Request for reviews (S): 8006204: please JTREGify test/compiler/7190310/Test7190310.java In-Reply-To: <39E5E192-A9E0-4062-ACA4-77486D3C926E@oracle.com> References: <39E5E192-A9E0-4062-ACA4-77486D3C926E@oracle.com> Message-ID: Looks good. -- Chris On Jan 16, 2013, at 8:44 AM, David Chase wrote: > http://cr.openjdk.java.net/~drchase/8006204/webrev.00/ > > pre-fix: > Test7190310.java was a manual test because of timing issues -- failure is an infinite loop, but success may require more time than the default timeout (though usually it doesn't). > A companion _unsafe test was already annotated correctly (no timeout needed) and already run automatically by jtreg. > > fix: > Add proper jtreg annotations in the preceding comment, including an explicit timeout. > > post-fix: > Both tests (Test7190310.java and Test7190310_unsafe.java) were observed to run in jtreg. > > Testing: > local with jtreg and "jtreg -a" to verify that test is now automatic. > JPRT passed. > I tried to manually verify that JPRT ran both parts of this specific test, but could not figure out where (or if) this information was kept. > From david.r.chase at oracle.com Wed Jan 16 12:59:56 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 16 Jan 2013 15:59:56 -0500 Subject: Request for reviews (S): 8006204: please JTREGify test/compiler/7190310/Test7190310.java In-Reply-To: References: <39E5E192-A9E0-4062-ACA4-77486D3C926E@oracle.com> Message-ID: Minor tweak -- the explanatory comment following the jtreg annotations was getting treated as arguments to the invocation of main. No harm today, but not not right either. New webrev: http://cr.openjdk.java.net/~drchase/8006204/webrev.03/ New form of comment (webrev.00 had this all in one comment). 25 /* 26 * @test 27 * @bug 7190310 28 * @summary Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops 29 * @run main/othervm/timeout=600 -Xbatch Test7190310 30 */ 31 32 /* 33 * Note bug exhibits as infinite loop, timeout is helpful. 34 * It should normally finish pretty quickly, but on some especially slow machines 35 * it may not. The companion _unsafe test lacks a timeout, but that is okay. 36 */ I checked that jtreg still behaved properly after this change. David From vladimir.kozlov at oracle.com Wed Jan 16 13:54:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Jan 2013 13:54:29 -0800 Subject: Request for reviews (S): 8006204: please JTREGify test/compiler/7190310/Test7190310.java In-Reply-To: References: <39E5E192-A9E0-4062-ACA4-77486D3C926E@oracle.com> Message-ID: <50F72195.3000704@oracle.com> Good. I will push it. Thanks, Vladimir On 1/16/13 12:59 PM, David Chase wrote: > Minor tweak -- the explanatory comment following the jtreg annotations was getting treated as arguments to the invocation of main. No harm today, but not not right either. > > New webrev: > > http://cr.openjdk.java.net/~drchase/8006204/webrev.03/ > > New form of comment (webrev.00 had this all in one comment). > > 25 /* > 26 * @test > 27 * @bug 7190310 > 28 * @summary Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops > 29 * @run main/othervm/timeout=600 -Xbatch Test7190310 > 30 */ > 31 > 32 /* > 33 * Note bug exhibits as infinite loop, timeout is helpful. > 34 * It should normally finish pretty quickly, but on some especially slow machines > 35 * it may not. The companion _unsafe test lacks a timeout, but that is okay. > 36 */ > > > I checked that jtreg still behaved properly after this change. > > David > From vladimir.kozlov at oracle.com Wed Jan 16 17:38:51 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 17 Jan 2013 01:38:51 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8006204: please JTREGify test/compiler/7190310/Test7190310.java Message-ID: <20130117013855.4AB4C47323@hg.openjdk.java.net> Changeset: bf623b2d5508 Author: kvn Date: 2013-01-16 14:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bf623b2d5508 8006204: please JTREGify test/compiler/7190310/Test7190310.java Summary: Add proper jtreg annotations in the preceding comment, including an explicit timeout. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! test/compiler/7190310/Test7190310.java From vladimir.kozlov at oracle.com Wed Jan 16 20:27:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Jan 2013 20:27:35 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F120CD.6020207@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> Message-ID: <50F77DB7.50806@oracle.com> On 1/12/13 12:37 AM, Ulf Zibis wrote: > Am 11.01.2013 23:53, schrieb Christian Thalinger: >> But you guys noticed that sentence in the initial review request, right? >> >> "Move encoding loop into separate method for which VM will use >> intrinsic on x86." >> >> Just wanted to make sure ;-) > > Good question Christian! > > This is, how it shows up to me: > 1) The bug synopsis is unspecific about intrinsc, so ... > 2) the mentioned 1st sentence could be one of many solutions. > 3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 ==> This bug is > not available. I opened it, should show up in few days. > 4) What specific operation should be done by the intrinsic, i.e. is > there a fixed API for that method ??? When C2 (server JIT compiler in JVM) compiles encode methods it will replace new method encodeArray() (matched by signature) with hand optimized assembler code which uses latest processor instructions. I will send Hotspot changes soon. So it is nothing to do with interpreter or bytecode sequence. > 5) Can an intrinsic write back more than 1 value (see my hack via int[] > p) ? > 6) Vladimir's webrev shows an integer as return type for that method, > I've added a variant with boolean return type, and the code from my last > approach could be transformed to a method with Object return type. Here is latest webrev, I added caching arrayOffset() call results: http://cr.openjdk.java.net/~kvn/6896617_jdk/webrev.01 I tested it with java nio regression/verification tests. I am done with java part and will not accept any more changes except if someone find a bug in it. > > ... so waiting for Vladimir's feedback :-[ > (especially on performance/hsdis results) Performance on x86 tested with next code (whole test will be in Hotspot changes) : ba = CharBuffer.wrap(a); bb = ByteBuffer.wrap(b); long start = System.currentTimeMillis(); for (int i = 0; i < 1000000; i++) { ba.clear(); bb.clear(); enc_res = enc_res && enc.encode(ba, bb, true).isUnderflow(); } long end = System.currentTimeMillis(); 1 - current java code 2 - new encodeArray() with loop but without intrinsic (JIT compiled code) 3 - using assembler intrinsic for encodeArray() on cpu without SSE4.2 4 - using assembler intrinsic on cpu with SSE4.2 5 - using assembler intrinsic on cpu with AVX2 size: 1 time: 40 34 28 28 28 size: 7 time: 47 40 33 33 34 size: 8 time: 51 41 33 28 29 size: 16 time: 58 45 37 29 29 size: 32 time: 72 56 44 30 29 size: 64 time: 103 71 62 32 31 size: 128 time: 160 105 89 36 33 size: 256 time: 284 178 141 42 37 size: 512 time: 514 317 246 61 50 size: 1024 time: 987 599 458 89 68 size: 2048 time: 1930 1150 853 145 114 size: 4096 time: 3820 2283 1645 264 207 Thanks, Vladimir > > (Can someone push the bug to the public?) > > -Ulf From alejandro.murillo at oracle.com Fri Jan 18 10:04:31 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 18 Jan 2013 18:04:31 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 32 new changesets Message-ID: <20130118180543.85805473CF@hg.openjdk.java.net> Changeset: 41ccb2e737fb Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/41ccb2e737fb Added tag jdk8-b73 for changeset 11619f33cd68 ! .hgtags Changeset: 1a3e54283c54 Author: katleman Date: 2013-01-16 20:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1a3e54283c54 Merge ! .hgtags Changeset: adc176e95bf2 Author: acorn Date: 2013-01-09 11:39 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/adc176e95bf2 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests Summary: Fix verifier for new interface access flags Reviewed-by: acorn, kvn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: dd7248d3e151 Author: zgu Date: 2013-01-09 14:46 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dd7248d3e151 7152671: RFE: Windows decoder should add some std dirs to the symbol search path Summary: Added JRE/JDK bin directories to decoder's symbol search path Reviewed-by: dcubed, sla ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp Changeset: 97ee8abd6ab2 Author: zgu Date: 2013-01-09 12:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/97ee8abd6ab2 Merge Changeset: aefb345d3f5e Author: acorn Date: 2013-01-10 17:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aefb345d3f5e 7199207: NPG: Crash in PlaceholderTable::verify after StackOverflow Summary: Reduce scope of placeholder table entries to improve cleanup Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: 91bf7da5c609 Author: mikael Date: 2013-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91bf7da5c609 8004747: Remove last_entry from VM_STRUCT macros Summary: Instead of passing in last_entry to all the VM_ macros just expand it in the main vmStructs.cpp file. Reviewed-by: dholmes, sspitsyn, minqi ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c1c8479222cd Author: dholmes Date: 2013-01-10 21:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c1c8479222cd 8005921: Memory leaks in vmStructs.cpp Reviewed-by: dholmes, mikael, rasbold Contributed-by: Jeremy Manson ! src/share/vm/runtime/vmStructs.cpp Changeset: e0cf9af8978e Author: zgu Date: 2013-01-11 12:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e0cf9af8978e 8005936: PrintNMTStatistics doesn't work for normal JVM exit Summary: Moved NMT shutdown code to JVM exit handler to ensure NMT statistics is printed when PrintNMTStatistics is enabled Reviewed-by: acorn, dholmes, coleenp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 90a92d5bca17 Author: zgu Date: 2013-01-11 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/90a92d5bca17 Merge Changeset: 4a916f2ce331 Author: jwilhelm Date: 2013-01-14 15:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4a916f2ce331 8003985: Support @Contended Annotation - JEP 142 Summary: HotSpot changes to support @Contended annotation. Reviewed-by: coleenp, kvn, jrose Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f9eb431c3efe Author: coleenp Date: 2013-01-14 11:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f9eb431c3efe 8006005: Fix constant pool index validation and alignment trap for method parameter reflection Summary: This patch addresses an alignment trap due to the storage format of method parameters data in constMethod. It also adds code to validate constant pool indexes for method parameters data. Reviewed-by: jrose, dholmes Contributed-by: eric.mccorkle at oracle.com ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/reflection.cpp Changeset: 5b6a231e5a86 Author: coleenp Date: 2013-01-14 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5b6a231e5a86 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: fe1472c87a27 Author: mikael Date: 2013-01-14 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fe1472c87a27 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs Summary: Added assertion to catch problem earlier and removed the unused field Reviewed-by: dholmes, acorn ! src/share/vm/runtime/vmStructs.cpp Changeset: c793367610c1 Author: coleenp Date: 2013-01-15 17:05 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c793367610c1 8005467: CDS size information is incorrect and unfriendly Summary: Changed words to bytes, and added usage percentage information Reviewed-by: coleenp, twisti Contributed-by: ioi.lam at oracle.com ! src/share/vm/memory/metaspaceShared.cpp Changeset: 92d4b5d8dde4 Author: acorn Date: 2013-01-16 18:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/92d4b5d8dde4 Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 337e1dd9d902 Author: jiangli Date: 2013-01-11 16:55 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/337e1dd9d902 8005895: Inefficient InstanceKlass field packing wasts memory. Summary: Pack _misc_has_default_methods into the _misc_flags, move _idnum_allocated_count. Reviewed-by: coleenp, shade ! src/share/vm/oops/instanceKlass.hpp Changeset: 94fa3c4e7643 Author: vladidan Date: 2013-01-14 13:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/94fa3c4e7643 8005639: Move InlineSynchronizedMethods flag from develop to product Summary: Move InlineSynchronizedMethods flag from develop to product Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/c1/c1_globals.hpp Changeset: 9deda4d8e126 Author: vladidan Date: 2013-01-14 13:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9deda4d8e126 8005204: Code Cache Reduction: command line options implementation Summary: Adding more detailed output on CodeCache usage Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 212c5b9c38e7 Author: dlong Date: 2013-01-17 01:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/212c5b9c38e7 Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: eab4f9ed602c Author: kvn Date: 2013-01-17 18:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/eab4f9ed602c Merge ! src/share/vm/compiler/compileBroker.cpp Changeset: 689e1218d7fe Author: brutisso Date: 2013-01-14 09:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/689e1218d7fe 8004018: Remove old initialization flags Reviewed-by: dholmes, stefank Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: a30e7b564541 Author: brutisso Date: 2013-01-14 21:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a30e7b564541 8005972: ParNew should not update the tenuring threshold when promotion failed has occurred Reviewed-by: ysr, johnc, jwilhelm ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp Changeset: ed6154d7d259 Author: stefank Date: 2013-01-15 13:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ed6154d7d259 8005590: java_lang_Class injected field resolved_constructor appears unused Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ff0a7943fd29 Author: stefank Date: 2013-01-15 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ff0a7943fd29 8005994: Method annotations are allocated unnecessarily during class file parsing Summary: Also reviewed by: vitalyd at gmail.com Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvm.cpp Changeset: 4967eb4f67a9 Author: johnc Date: 2013-01-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4967eb4f67a9 8001425: G1: Change the default values for certain G1 specific flags Summary: Changes to default and ergonomic flag values recommended by performance team. Changes were also reviewed by Monica Beckwith . Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2dce7c34c564 Author: stefank Date: 2013-01-17 11:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2dce7c34c564 8006513: Null pointer in DefaultMethods::generate_default_methods when merging annotations Reviewed-by: brutisso, jfranck ! src/share/vm/classfile/defaultMethods.cpp Changeset: 59a58e20dc60 Author: jmasa Date: 2013-01-17 19:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/59a58e20dc60 8006537: Assert when dumping archive with default methods Reviewed-by: coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metadataFactory.hpp Changeset: f422634e5828 Author: brutisso Date: 2013-01-18 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f422634e5828 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 70c89bd6b895 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/70c89bd6b895 Merge Changeset: 2b878edabfc0 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2b878edabfc0 Added tag hs25-b16 for changeset 70c89bd6b895 ! .hgtags Changeset: 46e60405583b Author: amurillo Date: 2013-01-18 05:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/46e60405583b 8006511: new hotspot build - hs25-b17 Reviewed-by: jcoomes ! make/hotspot_version From vladimir.kozlov at oracle.com Fri Jan 18 10:26:05 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jan 2013 10:26:05 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F77DB7.50806@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> Message-ID: <50F993BD.5020607@oracle.com> Here are Hotspot changes with new jtreg test: http://cr.openjdk.java.net/~kvn/6896617/webrev New ideal node EncodeArray was added for the intrinsic. It is main change since it touches all places in C2. Also fixed Assembler::vptest(xmm, adr) encoding (currently it is not used). Tested with jdk regression nio test, compiler jtreg tests, ctw. Thanks, Vladimir On 1/16/13 8:27 PM, Vladimir Kozlov wrote: > On 1/12/13 12:37 AM, Ulf Zibis wrote: >> Am 11.01.2013 23:53, schrieb Christian Thalinger: >>> But you guys noticed that sentence in the initial review request, right? >>> >>> "Move encoding loop into separate method for which VM will use >>> intrinsic on x86." >>> >>> Just wanted to make sure ;-) >> >> Good question Christian! >> >> This is, how it shows up to me: >> 1) The bug synopsis is unspecific about intrinsc, so ... >> 2) the mentioned 1st sentence could be one of many solutions. >> 3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 ==> This bug is >> not available. > > I opened it, should show up in few days. > >> 4) What specific operation should be done by the intrinsic, i.e. is >> there a fixed API for that method ??? > > When C2 (server JIT compiler in JVM) compiles encode methods it will > replace new method encodeArray() (matched by signature) with hand > optimized assembler code which uses latest processor instructions. I > will send Hotspot changes soon. So it is nothing to do with interpreter > or bytecode sequence. > >> 5) Can an intrinsic write back more than 1 value (see my hack via int[] >> p) ? >> 6) Vladimir's webrev shows an integer as return type for that method, >> I've added a variant with boolean return type, and the code from my last >> approach could be transformed to a method with Object return type. > > Here is latest webrev, I added caching arrayOffset() call results: > > http://cr.openjdk.java.net/~kvn/6896617_jdk/webrev.01 > > I tested it with java nio regression/verification tests. I am done with > java part and will not accept any more changes except if someone find a > bug in it. > >> >> ... so waiting for Vladimir's feedback :-[ >> (especially on performance/hsdis results) > > Performance on x86 tested with next code (whole test will be in Hotspot > changes) : > > ba = CharBuffer.wrap(a); > bb = ByteBuffer.wrap(b); > long start = System.currentTimeMillis(); > for (int i = 0; i < 1000000; i++) { > ba.clear(); bb.clear(); > enc_res = enc_res && enc.encode(ba, bb, true).isUnderflow(); > } > long end = System.currentTimeMillis(); > > 1 - current java code > 2 - new encodeArray() with loop but without intrinsic (JIT compiled code) > 3 - using assembler intrinsic for encodeArray() on cpu without SSE4.2 > 4 - using assembler intrinsic on cpu with SSE4.2 > 5 - using assembler intrinsic on cpu with AVX2 > > size: 1 time: 40 34 28 28 28 > size: 7 time: 47 40 33 33 34 > size: 8 time: 51 41 33 28 29 > size: 16 time: 58 45 37 29 29 > size: 32 time: 72 56 44 30 29 > size: 64 time: 103 71 62 32 31 > size: 128 time: 160 105 89 36 33 > size: 256 time: 284 178 141 42 37 > size: 512 time: 514 317 246 61 50 > size: 1024 time: 987 599 458 89 68 > size: 2048 time: 1930 1150 853 145 114 > size: 4096 time: 3820 2283 1645 264 207 > > > Thanks, > Vladimir > >> >> (Can someone push the bug to the public?) >> >> -Ulf From david.r.chase at oracle.com Sat Jan 19 07:05:05 2013 From: david.r.chase at oracle.com (David Chase) Date: Sat, 19 Jan 2013 10:05:05 -0500 Subject: Request for reviews (M) 8005600: compiler/8004741/Test8004741.java fails intermediately Message-ID: <377E9677-1175-47AA-B322-331CE5DA047B@oracle.com> http://cr.openjdk.java.net/~drchase/8006500/webrev.01/ 8004741 tested for the multi-dimensional-array-allocation-lack-exception-handler bug. This is accomplished by allocating a multi-dimensional array in an infinite loop, Thread.stop()ing the looping allocator (asynchronously throws ThreadDeath in victim thread). The old logic used timed waits to coordinate the two threads, and that did not always work; sometimes the ThreadDeath would land in an unexpected place. It also contained 6 seconds of total wait time. Fix: Rewrote most of the test surrounding the victim try-block. New version uses wait-notify to coordinate the two threads. The region of code in which a "pass" could be recorded was reduced. Pass was turned into a count, and the test was made statistical; if more than half of the N runs of the test code record a "pass" then it is judged to be a pass, else it is a fail. The regression failure is a crash, so less than 100% testing is okay. All unexpected behavior (any exception other than ThreadDeath, and unexpected thread state changes) leads to a fail(). The new version contains .5 + .1 * N seconds of explicit wait time (N=12, so 1.7), plus whatever is required for wait-notify thread coordination (ought to be milliseconds in the usual case). The first .5 second might be completely unnecessary; I expect someone will tell me. Testing: Switching back and forth between pre-8004741-fix 7u11 and post-fix, verified that the modified 8004741 would still reliably fail on an unfixed VM. Experimented with different sizes of 2-D allocation; that seemed to matter. Artificially padded the body of test to see that the statistical nature of the test would work -- that the try-block hit rate would go down (it did). JPRT of the new 8004741 on Mac, Solaris, x86 (some problem with running on Linux) - Checked that the x86 failures were all bogus (zip failure post-test; tests all passed) - Checked the logs of all the Mac and Solaris JPRT runs to look for any misses of the try-block; some Solaris runs saw one out of 12 trials miss once (i.e., 11 hits). Note that this is hitting a "smaller target" than the previous version of the test, so these misses don't correspond to failures in the previous version of the test; that was due to timing hiccups. From roland.westrelin at oracle.com Mon Jan 21 02:59:03 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 21 Jan 2013 11:59:03 +0100 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob Message-ID: One of the method has the following structure: for ( .. ) { .. if ( ..) { .. } else { if ( .. ) { if ( .. ) { .. } else { if ( .. ) { .. } else { Math.pow(x, y); } } } else { if ( .. ) { .. } else { Math.pow(x, y); } } .. } Both Math.pow(x,y) have the same inputs and so a single PowDNode is kept and it's scheduled in the else of the outer most if. So the pow computation is executed independently of the other if conditions, more frequently and because the computation is expensive there's a noticeable performance regression. The fix consists in: 1) setting the control input of the expensive nodes (PowDNode, ExpDNode) to prevent IGVN to freely common nodes 2) During the loop optimization pass, consider each expensive node and, when possible, modify the control input to allow optimization by the IGVN while making sure it's not executed more frequently http://cr.openjdk.java.net/~roland/7197327/ To test it, given it's quite rare to have 2 PowDNodes with the same inputs, I applied the same technique to a bunch of other nodes: http://cr.openjdk.java.net/~roland/7197327/webrev.test/ Roland. From roland.westrelin at oracle.com Mon Jan 21 08:49:35 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 21 Jan 2013 17:49:35 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F993BD.5020607@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50F993BD.5020607@oracle.com> Message-ID: > Here are Hotspot changes with new jtreg test: > > http://cr.openjdk.java.net/~kvn/6896617/webrev It looks good to me. Roland. From volker.simonis at gmail.com Mon Jan 21 10:40:03 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 21 Jan 2013 19:40:03 +0100 Subject: RFR(XS): Compiler crash due to out of bounds array access in Parse::do_multianewarray Message-ID: Please review the fix for the following issue and create a BugID/Submit the change if you find it appropriate: http://cr.openjdk.java.net/~simonis/webrevs/do_multianewarray/ The change for "7058510:multinewarray with 6 dimensions uncommon traps in server compiler" replaced the fixed sized, stack allocated array 'length' of length 5 with a dynamically, arena allocated array of size 'ndimensions + 1': Node** length = NEW_RESOURCE_ARRAY(Node*, ndimensions + 1); length[ndimensions] = NULL; // terminating null for make_runtime_call In cases where 'ndimensions' is smaller than 4 (and bigger than 1 because the 1-dimensional case is handled specially) this leads to field accesses beyond the bounds of the 'length' array later on during the call to ' make_runtime_call(..)' which can eventually crash the compiler: c = make_runtime_call(RC_NO_LEAF | RC_NO_IO, OptoRuntime::multianewarray_Type(ndimensions), fun, NULL, TypeRawPtr::BOTTOM, makecon(TypeKlassPtr::make(array_klass)), length[0], length[1], length[2], length[3], length[4]); Notice that these crashes are extremely rare, because usually, there is still some accessible memory beyond the arena allocated 'length' array. We only observed four crashes because of this problem in regular nightly runs of JVM2008 during the last six month. The crashes only happened on Windows although the problem is platform independent. I also couldn't reproduce the problem with a test program which ran for several hours and constantly compiled a method which allocated several two- and three-dimensional arrays so I refrained from writing a regression test for this problem. The fix is trivial: just check the value of 'ndimensions' before accessing the corresponding 'length' slots and use NULL values for the cases where the array slots do not exist. Notice that we only call make_runtime_call if 'ndimensions' is bigger than 1 in which case 'length' already contains three entries (see allocation of the 'length' array above). c = make_runtime_call(RC_NO_LEAF | RC_NO_IO, OptoRuntime::multianewarray_Type(ndimensions), fun, NULL, TypeRawPtr::BOTTOM, makecon(TypeKlassPtr::make(array_klass)), length[0], length[1], length[2], (ndimensions > 2) ? length[3] : NULL, (ndimensions > 3) ? length[4] : NULL); Thank you and best regards, Volker -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130121/b646eb2f/attachment.html From vladimir.kozlov at oracle.com Mon Jan 21 14:02:14 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Jan 2013 14:02:14 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50F993BD.5020607@oracle.com> Message-ID: <50FDBAE6.6040504@oracle.com> Thank you, Roland Vladimir On 1/21/13 8:49 AM, Roland Westrelin wrote: >> Here are Hotspot changes with new jtreg test: >> >> http://cr.openjdk.java.net/~kvn/6896617/webrev > > It looks good to me. > > Roland. > From vladimir.kozlov at oracle.com Mon Jan 21 14:53:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Jan 2013 14:53:08 -0800 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: References: Message-ID: <50FDC6D4.6000703@oracle.com> Roland, What is effect on refworkload? I would also use it for trigonometric and math (sqrt, log) intrinsics (as separate RFE after checking performance effect). I like you factoring of sorting code in sources. Why ciConstantPoolCache::_keys is array of intptr_t and not int type elements? We'r wasting space in 64bit VM and do conversion each time we access elements. In growableArray.hpp call f(value, key) only once. In loopnode.cpp you miss 'return;' in second "if (stop_early)". It is very expensive to do build_loop_* when stop_early is true. Could you check before that if you have Expensive nodes with the same data inputs instead of just number of such nodes? Your list sorting should be cheaper. May be instead of flat list you should create list of pairs which have same data inputs, it will simplify processing code. Anyway, I think new process_expensive_nodes() method is too complex for cases which are very very rare. I think you should narrow cases for this optimization: c1 = get_control(n1); c2 = get_control(n2); if (is_dominator(c1, c2)) { c2 = c1; } else if (is_dominator(c2, c1)) { c1 = c2; } else if (c1->is_Proj() && c1->in(0)->is_If() && is_dominator(c1->in(0), c2)) { c1 = c2 = c1->in(0); } else if (c2->is_Proj() && c2->in(0)->is_If() && is_dominator(c2->in(0), c1)) { c1 = c2 = c2->in(0); } if (n1->in(0) != c1) { n1->set_req(0, c1); } if (n2->in(0) != c2) { n2->set_req(0, c2); } Note, when you skip UNC you don't check min_dom_depth but some data inputs may depend on this UNC. So it may be not safe. Thanks, Vladimir On 1/21/13 2:59 AM, Roland Westrelin wrote: > One of the method has the following structure: > > for ( .. ) { > .. > if ( ..) { > .. > } else { > if ( .. ) { > if ( .. ) { > .. > } else { > if ( .. ) { > .. > } else { > Math.pow(x, y); > } > } > } else { > if ( .. ) { > .. > } else { > Math.pow(x, y); > } > } > .. > } > > Both Math.pow(x,y) have the same inputs and so a single PowDNode is kept and it's scheduled in the else of the outer most if. So the pow computation is executed independently of the other if conditions, more frequently and because the computation is expensive there's a noticeable performance regression. > > The fix consists in: > > 1) setting the control input of the expensive nodes (PowDNode, ExpDNode) to prevent IGVN to freely common nodes > 2) During the loop optimization pass, consider each expensive node and, when possible, modify the control input to allow optimization by the IGVN while making sure it's not executed more frequently > > http://cr.openjdk.java.net/~roland/7197327/ > > To test it, given it's quite rare to have 2 PowDNodes with the same inputs, I applied the same technique to a bunch of other nodes: > > http://cr.openjdk.java.net/~roland/7197327/webrev.test/ > > Roland. > From vladimir.kozlov at oracle.com Mon Jan 21 15:17:28 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Jan 2013 15:17:28 -0800 Subject: Request for reviews (M) 8005600: compiler/8004741/Test8004741.java fails intermediately In-Reply-To: <377E9677-1175-47AA-B322-331CE5DA047B@oracle.com> References: <377E9677-1175-47AA-B322-331CE5DA047B@oracle.com> Message-ID: <50FDCC88.4000701@oracle.com> Thank you, David First, this test tries to exercise paths in runtime code (not in compiled code) which pass exceptions to compiled code. 2 places are: 1. runtime calls from compiled methods (in opto/runtime.cpp). The test call it because variable values (passed as arguments, so it does not matter what values are passed) are used for multidimensional array allocation and flag -XX:+StressCompiledExceptionHandlers to avoid deoptimization of compiled frame which we do normally. 2. during safepoint in JavaThread::send_thread_stop(). The test tries to bring VM into safepoint by allocating big array with small heap. I think this cases should be separated (separate test methods). Also it would be nice to add third case, as you suggested, by injected invalid dimension size. An other thing to improve is to add COMPILED state which set after 11000 iterations in the loop in run(). We test without tiered so threshold is 10000 for C2 (1000 for c1) and we use -Xbatch so the code will wait compilation finish. It would be nice to avoid (passed > N/2) condition to pass test. Is it possible to find why it fails? Thanks, Vladimir On 1/19/13 7:05 AM, David Chase wrote: > > http://cr.openjdk.java.net/~drchase/8006500/webrev.01/ > > 8004741 tested for the multi-dimensional-array-allocation-lack-exception-handler bug. > This is accomplished by allocating a multi-dimensional array in an infinite loop, > Thread.stop()ing the looping allocator (asynchronously throws ThreadDeath in victim thread). > > The old logic used timed waits to coordinate the two threads, and that did not always work; > sometimes the ThreadDeath would land in an unexpected place. > It also contained 6 seconds of total wait time. > > Fix: > > Rewrote most of the test surrounding the victim try-block. > > New version uses wait-notify to coordinate the two threads. > > The region of code in which a "pass" could be recorded was reduced. > > Pass was turned into a count, and the test was made statistical; > if more than half of the N runs of the test code record a "pass" then > it is judged to be a pass, else it is a fail. The regression failure > is a crash, so less than 100% testing is okay. > > All unexpected behavior (any exception other than ThreadDeath, > and unexpected thread state changes) leads to a fail(). > > The new version contains .5 + .1 * N seconds of explicit wait time > (N=12, so 1.7), plus whatever is required for wait-notify thread coordination > (ought to be milliseconds in the usual case). The first .5 second might > be completely unnecessary; I expect someone will tell me. > > Testing: > > Switching back and forth between pre-8004741-fix 7u11 and post-fix, verified that the modified 8004741 would still reliably fail on an unfixed VM. Experimented with different sizes of 2-D allocation; that seemed to matter. > > Artificially padded the body of test to see that the statistical nature of the test would work -- that the try-block hit rate would go down (it did). > > JPRT of the new 8004741 on Mac, Solaris, x86 (some problem with running on Linux) > > - Checked that the x86 failures were all bogus (zip failure post-test; tests all passed) > - Checked the logs of all the Mac and Solaris JPRT runs to look for any misses of the try-block; some Solaris runs saw one out of 12 trials miss once (i.e., 11 hits). Note that this is hitting a "smaller target" than the previous version of the test, so these misses don't correspond to failures in the previous version of the test; that was due to timing hiccups. > > > From Ulf.Zibis at CoSoCo.de Mon Jan 21 15:30:38 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 22 Jan 2013 00:30:38 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F77DB7.50806@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> Message-ID: <50FDCF9E.5040600@CoSoCo.de> Am 17.01.2013 05:27, schrieb Vladimir Kozlov: > On 1/12/13 12:37 AM, Ulf Zibis wrote: >> 3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 ==> This bug is >> not available. > > I opened it, should show up in few days. Thanks! > >> 4) What specific operation should be done by the intrinsic, i.e. is >> there a fixed API for that method ??? > > When C2 (server JIT compiler in JVM) compiles encode methods it will replace new method > encodeArray() (matched by signature) with hand optimized assembler code which uses latest > processor instructions. I will send Hotspot changes soon. So it is nothing to do with interpreter > or bytecode sequence. > >> 5) Can an intrinsic write back more than 1 value (see my hack via int[] >> p) ? >> 6) Vladimir's webrev shows an integer as return type for that method, >> I've added a variant with boolean return type, and the code from my last >> approach could be transformed to a method with Object return type. I wanted to say, there would maybe different results for the surrounding code depending on the API we choose for the intrinsic method call. If the surrounding code is *as short as possible*, there is a better chance, it will be JIT-compiled too after fewer invocations of encodeArrayLoop(). I guess, the fastest would be: // while inlinig, JIT will erase the surrounding int[] p private static CoderResult copyISOs(CoderResult cr, char[] sa, byte[] da, final int[] p, int sl) { for (int sp = p[0], dp = p[1]; sp < sl; sp++) { char c = sa[sp]; // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, would be fastest if ((byte)(c >> 8) != 0) // temporary replacement, fast byte-length operation on x86 return null; da[dp++] = (byte)c; } return cr; } // No more needs try...finally block private CoderResult encodeArrayLoop( CharBuffer src, ByteBuffer dst) { char[] sa = src.array(); int soff = src.arrayOffset(); int sp = soff + src.position(); int sr = src.remaining(); byte[] da = dst.array(); int doff = dst.arrayOffset(); int dp = doff + dst.position(); int dr = dst.remaining(); CoderResult cr; if (dr < sr) { sr = dr; cr = CoderResult.OVERFLOW; } else cr = CoderResult.UNDERFLOW; int sl = sp + sr; final int[] p = { sp, dp }; cr = copyISOs(cr, sa, da, p, sl); src.position(p[0] - soff); dst.position(p[1] - doff); return result(cr, sa, p[0], sl); } // if adapted, maybe could also be reused in encodeBufferLoop() private static CoderResult result(CoderResult cr, byte[] sa, int sp, int sl) { return cr != null ? cr : sgp.parse(sa[sp], sa, sp, sl) < 0 ? sgp.error(); : sgp.unmappableResult(); } >> >> ... so waiting for Vladimir's feedback :-[ >> (especially on performance/hsdis results) > > Performance on x86 tested with next code (whole test will be in Hotspot changes) : > > ba = CharBuffer.wrap(a); > bb = ByteBuffer.wrap(b); > long start = System.currentTimeMillis(); > for (int i = 0; i < 1000000; i++) { > ba.clear(); bb.clear(); > enc_res = enc_res && enc.encode(ba, bb, true).isUnderflow(); > } > long end = System.currentTimeMillis(); 1.) Wouldn't System.nanoTime() give more accurate results? 2.) I want to point out that it is not real world scenario, encoding the same data 1.000.000 times. If same data is used, it is likely, that the data itself becomes cached in the inner CPU cache so should have very fast access times, which would be not the case on real world data. 3.) It would also be interesting to see the results for less than 1.000.000 iterations in considering, the surrounding code would be JIT-compiled or not. Also performance on C1 should be tested. I also worry about the naming of method encodeArray(...). I think, it should reflect the fact, that it only encodes ISO-8859-1 charset characters. Please add a comment on the fact, that method encodeArray(...) is intended to be intrinsified. -Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130122/82c30be5/attachment.html From david.r.chase at oracle.com Mon Jan 21 15:47:09 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 21 Jan 2013 18:47:09 -0500 Subject: Request for reviews (M) 8005600: compiler/8004741/Test8004741.java fails intermediately In-Reply-To: <50FDCC88.4000701@oracle.com> References: <377E9677-1175-47AA-B322-331CE5DA047B@oracle.com> <50FDCC88.4000701@oracle.com> Message-ID: <3EFCDFEE-797B-42E1-A14E-B15513595468@oracle.com> On 2013-01-21, at 6:17 PM, Vladimir Kozlov wrote: > Thank you, David > > First, this test tries to exercise paths in runtime code (not in compiled code) which pass exceptions to compiled code. 2 places are: > > 1. runtime calls from compiled methods (in opto/runtime.cpp). The test call it because variable values (passed as arguments, so it does not matter what values are passed) are used for multidimensional array allocation and flag -XX:+StressCompiledExceptionHandlers to avoid deoptimization of compiled frame which we do normally. > 2. during safepoint in JavaThread::send_thread_stop(). The test tries to bring VM into safepoint by allocating big array with small heap. How do we know whether or not we "hit" both places? Is this a case where varying the allocation size would help? I also found it interesting that I could see failures with small allocation under jdk7u11 -- a 2x2 allocation was adequate. > I think this cases should be separated (separate test methods). Also it would be nice to add third case, as you suggested, by injected invalid dimension size. I tried that; it did not trigger any crash under jdk7u11. Do we try it anyway? > An other thing to improve is to add COMPILED state which set after 11000 iterations in the loop in run(). We test without tiered so threshold is 10000 for C2 (1000 for c1) and we use -Xbatch so the code will wait compilation finish. The state variable is per-thread, tracking that thread's progress. COMPILED ought to be true for all of them after the warm-up loop, and I don't know how to verify that the compiler has run; I could make up a compiled state and set it, but I no way of knowing that the code was in fact compiled when I set the state to COMPILED. > It would be nice to avoid (passed > N/2) condition to pass test. Is it possible to find why it fails? I think that there are other safepoints besides the one at the array allocation; for example, the test() method is called from within an endless loop. That loop might have a safepoint in it; the method entry (before the try-catch is entered) might have a safepoint in it. If ThreadDeath lands on either of those non-allocation safepoints, we haven't really tested for the regression. I don't think there is any easy way to get rid of those other safepoints -- not easier than making the test statistical. In the old test it was not possible to tell if this had happened because the loop itself was with in a try-catch that caught ThreadDeath and set "passed"; however, because it used timing to guess at thread progress, in some cases it apparently missed for other reasons. I decided to tighten up the test case, and deal with the might-miss nature by making it statistical. I experimentally added an array allocation for padding outside the try-catch, and it was easy to miss more than half of the ThreadDeath exceptions. > Thanks, > Vladimir > > On 1/19/13 7:05 AM, David Chase wrote: >> >> http://cr.openjdk.java.net/~drchase/8006500/webrev.01/ >> >> 8004741 tested for the multi-dimensional-array-allocation-lack-exception-handler bug. >> This is accomplished by allocating a multi-dimensional array in an infinite loop, >> Thread.stop()ing the looping allocator (asynchronously throws ThreadDeath in victim thread). >> >> The old logic used timed waits to coordinate the two threads, and that did not always work; >> sometimes the ThreadDeath would land in an unexpected place. >> It also contained 6 seconds of total wait time. >> >> Fix: >> >> Rewrote most of the test surrounding the victim try-block. >> >> New version uses wait-notify to coordinate the two threads. >> >> The region of code in which a "pass" could be recorded was reduced. >> >> Pass was turned into a count, and the test was made statistical; >> if more than half of the N runs of the test code record a "pass" then >> it is judged to be a pass, else it is a fail. The regression failure >> is a crash, so less than 100% testing is okay. >> >> All unexpected behavior (any exception other than ThreadDeath, >> and unexpected thread state changes) leads to a fail(). >> >> The new version contains .5 + .1 * N seconds of explicit wait time >> (N=12, so 1.7), plus whatever is required for wait-notify thread coordination >> (ought to be milliseconds in the usual case). The first .5 second might >> be completely unnecessary; I expect someone will tell me. >> >> Testing: >> >> Switching back and forth between pre-8004741-fix 7u11 and post-fix, verified that the modified 8004741 would still reliably fail on an unfixed VM. Experimented with different sizes of 2-D allocation; that seemed to matter. >> >> Artificially padded the body of test to see that the statistical nature of the test would work -- that the try-block hit rate would go down (it did). >> >> JPRT of the new 8004741 on Mac, Solaris, x86 (some problem with running on Linux) >> >> - Checked that the x86 failures were all bogus (zip failure post-test; tests all passed) >> - Checked the logs of all the Mac and Solaris JPRT runs to look for any misses of the try-block; some Solaris runs saw one out of 12 trials miss once (i.e., 11 hits). Note that this is hitting a "smaller target" than the previous version of the test, so these misses don't correspond to failures in the previous version of the test; that was due to timing hiccups. >> >> >> From vladimir.kozlov at oracle.com Mon Jan 21 18:31:20 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Jan 2013 18:31:20 -0800 Subject: Request for reviews (M) 8005600: compiler/8004741/Test8004741.java fails intermediately In-Reply-To: <3EFCDFEE-797B-42E1-A14E-B15513595468@oracle.com> References: <377E9677-1175-47AA-B322-331CE5DA047B@oracle.com> <50FDCC88.4000701@oracle.com> <3EFCDFEE-797B-42E1-A14E-B15513595468@oracle.com> Message-ID: <50FDF9F8.7080405@oracle.com> On 1/21/13 3:47 PM, David Chase wrote: > > On 2013-01-21, at 6:17 PM, Vladimir Kozlov wrote: > >> Thank you, David >> >> First, this test tries to exercise paths in runtime code (not in compiled code) which pass exceptions to compiled code. 2 places are: >> >> 1. runtime calls from compiled methods (in opto/runtime.cpp). The test call it because variable values (passed as arguments, so it does not matter what values are passed) are used for multidimensional array allocation and flag -XX:+StressCompiledExceptionHandlers to avoid deoptimization of compiled frame which we do normally. > >> 2. during safepoint in JavaThread::send_thread_stop(). The test tries to bring VM into safepoint by allocating big array with small heap. > > How do we know whether or not we "hit" both places? Is this a case where varying the allocation size would help? I also found it interesting that I could see failures with small allocation under jdk7u11 -- a 2x2 allocation was adequate. With current code we can't guaranty it. We can add an other @run command to the test to increase frequency of safepoints: * @run main/othervm -Xmx64m -Xbatch -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -XX:+StressCompiledExceptionHandlers Test8004741 + * @run main/othervm -Xmx64m -Xbatch -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -XX:+StressCompiledExceptionHandlers -XX:+SafepointALot -XX:GuaranteedSafepointInterval=100 Test8004741 The test will be executed 2 times for each set of flags. > >> I think this cases should be separated (separate test methods). Also it would be nice to add third case, as you suggested, by injected invalid dimension size. > > I tried that; it did not trigger any crash under jdk7u11. Do we try it anyway? Yes, it will be test for future compiler source code changes (to avoid breaking exception catching in compiled code). In 7u11, which does not have 8004741 fix, we always deoptimize compiled frame and Interpreter will catch any exception/error. So with 7u11 you are testing Interpreter instead of compiled code. It could be used to verify correctness of the test itself. > >> An other thing to improve is to add COMPILED state which set after 11000 iterations in the loop in run(). We test without tiered so threshold is 10000 for C2 (1000 for c1) and we use -Xbatch so the code will wait compilation finish. > > The state variable is per-thread, tracking that thread's progress. COMPILED ought to be true for all of them after the warm-up loop, and I don't know how to verify that the compiler has run; I could make up a compiled state and set it, but I no way of knowing that the code was in fact compiled when I set the state to COMPILED. Correct, we can't guaranty it but it is more accurate then rely on time. I want main thread wait for COMPILED instead of RUNNING. Actually we can set RUNNING after 11000 iterations then you don't need to change code in main(). > >> It would be nice to avoid (passed > N/2) condition to pass test. Is it possible to find why it fails? > > I think that there are other safepoints besides the one at the array allocation; for example, the test() method is called from within an endless loop. That loop might have a safepoint in it; the method entry (before the try-catch is entered) might have a safepoint in it. If ThreadDeath lands on either of those non-allocation safepoints, we haven't really tested for the regression. I don't think there is any easy way to get rid of those other safepoints -- not easier than making the test statistical. > > In the old test it was not possible to tell if this had happened because the loop itself was with in a try-catch that caught ThreadDeath and set "passed"; however, because it used timing to guess at thread progress, in some cases it apparently missed for other reasons. I decided to tighten up the test case, and deal with the might-miss nature by making it statistical. I experimentally added an array allocation for padding outside the try-catch, and it was easy to miss more than half of the ThreadDeath exceptions. > Yes, you are right. There is also SFP on the return from test() which is outside of try block. And it is impossible to tell difference between missing the catch in test() method because bug in compiled code or because exception happened outside the try block. OK, leave statistical pass. Thanks, Vladimir > > >> Thanks, >> Vladimir >> >> On 1/19/13 7:05 AM, David Chase wrote: >>> >>> http://cr.openjdk.java.net/~drchase/8006500/webrev.01/ >>> >>> 8004741 tested for the multi-dimensional-array-allocation-lack-exception-handler bug. >>> This is accomplished by allocating a multi-dimensional array in an infinite loop, >>> Thread.stop()ing the looping allocator (asynchronously throws ThreadDeath in victim thread). >>> >>> The old logic used timed waits to coordinate the two threads, and that did not always work; >>> sometimes the ThreadDeath would land in an unexpected place. >>> It also contained 6 seconds of total wait time. >>> >>> Fix: >>> >>> Rewrote most of the test surrounding the victim try-block. >>> >>> New version uses wait-notify to coordinate the two threads. >>> >>> The region of code in which a "pass" could be recorded was reduced. >>> >>> Pass was turned into a count, and the test was made statistical; >>> if more than half of the N runs of the test code record a "pass" then >>> it is judged to be a pass, else it is a fail. The regression failure >>> is a crash, so less than 100% testing is okay. >>> >>> All unexpected behavior (any exception other than ThreadDeath, >>> and unexpected thread state changes) leads to a fail(). >>> >>> The new version contains .5 + .1 * N seconds of explicit wait time >>> (N=12, so 1.7), plus whatever is required for wait-notify thread coordination >>> (ought to be milliseconds in the usual case). The first .5 second might >>> be completely unnecessary; I expect someone will tell me. >>> >>> Testing: >>> >>> Switching back and forth between pre-8004741-fix 7u11 and post-fix, verified that the modified 8004741 would still reliably fail on an unfixed VM. Experimented with different sizes of 2-D allocation; that seemed to matter. >>> >>> Artificially padded the body of test to see that the statistical nature of the test would work -- that the try-block hit rate would go down (it did). >>> >>> JPRT of the new 8004741 on Mac, Solaris, x86 (some problem with running on Linux) >>> >>> - Checked that the x86 failures were all bogus (zip failure post-test; tests all passed) >>> - Checked the logs of all the Mac and Solaris JPRT runs to look for any misses of the try-block; some Solaris runs saw one out of 12 trials miss once (i.e., 11 hits). Note that this is hitting a "smaller target" than the previous version of the test, so these misses don't correspond to failures in the previous version of the test; that was due to timing hiccups. >>> >>> >>> > From david.r.chase at oracle.com Mon Jan 21 19:48:26 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 21 Jan 2013 22:48:26 -0500 Subject: Request for reviews (M) 8005600: compiler/8004741/Test8004741.java fails intermediately In-Reply-To: <50FDF9F8.7080405@oracle.com> References: <377E9677-1175-47AA-B322-331CE5DA047B@oracle.com> <50FDCC88.4000701@oracle.com> <3EFCDFEE-797B-42E1-A14E-B15513595468@oracle.com> <50FDF9F8.7080405@oracle.com> Message-ID: <73E90346-6D04-4DC4-B58F-B8BC82862228@oracle.com> On 2013-01-21, at 9:31 PM, Vladimir Kozlov wrote: > > With current code we can't guaranty it. We can add an other @run command to the test to increase frequency of safepoints: > > * @run main/othervm -Xmx64m -Xbatch -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -XX:+StressCompiledExceptionHandlers Test8004741 > + * @run main/othervm -Xmx64m -Xbatch -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -XX:+StressCompiledExceptionHandlers -XX:+SafepointALot -XX:GuaranteedSafepointInterval=100 Test8004741 > > The test will be executed 2 times for each set of flags. Got that change. Note that it only executes once if the first one crashes :-). >>> I think this cases should be separated (separate test methods). Also it would be nice to add third case, as you suggested, by injected invalid dimension size. >> >> I tried that; it did not trigger any crash under jdk7u11. Do we try it anyway? > > Yes, it will be test for future compiler source code changes (to avoid breaking exception catching in compiled code). > > In 7u11, which does not have 8004741 fix, we always deoptimize compiled frame and Interpreter will catch any exception/error. So with 7u11 you are testing Interpreter instead of compiled code. It could be used to verify correctness of the test itself. I'll find a way to work this in. The test was surprisingly delicate; I attempted to refactor it so that I passed the array bounds in to the thread allocation, and the bug quit happening. And are you sure that 7u11 is testing the interpreter? The crash looks like this (from the hotspot log file): --------------- T H R E A D --------------- Current thread (0x00007fc893110000): JavaThread "Thread-2" [_thread_in_vm, id=311300096, stack(0x00000001127e1000,0x00000001128e1000)] Stack: [0x00000001127e1000,0x00000001128e1000], sp=0x00000001128e0040, free space=1020k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x4a1257] V [libjvm.dylib+0x1b0fd7] V [libjvm.dylib+0x40642d] V [libjvm.dylib+0x3fee58] V [libjvm.dylib+0x3fef27] v ~ExceptionBlob v ~StubRoutines::call_stub V [libjvm.dylib+0x286acf] V [libjvm.dylib+0x286fac] V [libjvm.dylib+0x2870e6] V [libjvm.dylib+0x2bd820] V [libjvm.dylib+0x4763cc] V [libjvm.dylib+0x4778b2] V [libjvm.dylib+0x3b393d] C [libsystem_c.dylib+0x14742] _pthread_start+0x147 C [libsystem_c.dylib+0x1181] thread_start+0xd Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v ~ExceptionBlob J Test8004741.test(II)[[I j Test8004741.run()V+24 v ~StubRoutines::call_stub >>> An other thing to improve is to add COMPILED state which set after 11000 iterations in the loop in run(). We test without tiered so threshold is 10000 for C2 (1000 for c1) and we use -Xbatch so the code will wait compilation finish. >> >> The state variable is per-thread, tracking that thread's progress. COMPILED ought to be true for all of them after the warm-up loop, and I don't know how to verify that the compiler has run; I could make up a compiled state and set it, but I no way of knowing that the code was in fact compiled when I set the state to COMPILED. > > Correct, we can't guaranty it but it is more accurate then rely on time. I want main thread wait for COMPILED instead of RUNNING. Actually we can set RUNNING after 11000 iterations then you don't need to change code in main(). This seems like it would only act as documentation (above and beyond the comments already there), but if you think this is a good idea, I'll do it. David From vladimir.kozlov at oracle.com Mon Jan 21 20:51:50 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Jan 2013 20:51:50 -0800 Subject: Request for reviews (M) 8005600: compiler/8004741/Test8004741.java fails intermediately In-Reply-To: <73E90346-6D04-4DC4-B58F-B8BC82862228@oracle.com> References: <377E9677-1175-47AA-B322-331CE5DA047B@oracle.com> <50FDCC88.4000701@oracle.com> <3EFCDFEE-797B-42E1-A14E-B15513595468@oracle.com> <50FDF9F8.7080405@oracle.com> <73E90346-6D04-4DC4-B58F-B8BC82862228@oracle.com> Message-ID: <50FE1AE6.6000506@oracle.com> On 1/21/13 7:48 PM, David Chase wrote: > > On 2013-01-21, at 9:31 PM, Vladimir Kozlov wrote: >> >> With current code we can't guaranty it. We can add an other @run command to the test to increase frequency of safepoints: >> >> * @run main/othervm -Xmx64m -Xbatch -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -XX:+StressCompiledExceptionHandlers Test8004741 >> + * @run main/othervm -Xmx64m -Xbatch -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -XX:+StressCompiledExceptionHandlers -XX:+SafepointALot -XX:GuaranteedSafepointInterval=100 Test8004741 >> >> The test will be executed 2 times for each set of flags. > > Got that change. Note that it only executes once if the first one crashes :-). Which is fine. It needs both tests to pass and one is enough for a failure. > >>>> I think this cases should be separated (separate test methods). Also it would be nice to add third case, as you suggested, by injected invalid dimension size. >>> >>> I tried that; it did not trigger any crash under jdk7u11. Do we try it anyway? >> >> Yes, it will be test for future compiler source code changes (to avoid breaking exception catching in compiled code). >> >> In 7u11, which does not have 8004741 fix, we always deoptimize compiled frame and Interpreter will catch any exception/error. So with 7u11 you are testing Interpreter instead of compiled code. It could be used to verify correctness of the test itself. > > I'll find a way to work this in. The test was surprisingly delicate; I attempted to refactor it so that I passed the array bounds in to the thread allocation, and the bug quit happening. > > And are you sure that 7u11 is testing the interpreter? The crash looks like this (from the hotspot log file): Wow, you may really hit a problem in compiled code! Yes, it looks like 8004741. Try run debug (fastdebug) version of VM, it would be nice to see function names in call stack. > > --------------- T H R E A D --------------- > > Current thread (0x00007fc893110000): JavaThread "Thread-2" [_thread_in_vm, id=311300096, stack(0x00000001127e1000,0x00000001128e1000)] > > Stack: [0x00000001127e1000,0x00000001128e1000], sp=0x00000001128e0040, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.dylib+0x4a1257] > V [libjvm.dylib+0x1b0fd7] > V [libjvm.dylib+0x40642d] > V [libjvm.dylib+0x3fee58] > V [libjvm.dylib+0x3fef27] > v ~ExceptionBlob > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > v ~ExceptionBlob > J Test8004741.test(II)[[I > j Test8004741.run()V+24 > v ~StubRoutines::call_stub > >>>> An other thing to improve is to add COMPILED state which set after 11000 iterations in the loop in run(). We test without tiered so threshold is 10000 for C2 (1000 for c1) and we use -Xbatch so the code will wait compilation finish. >>> >>> The state variable is per-thread, tracking that thread's progress. COMPILED ought to be true for all of them after the warm-up loop, and I don't know how to verify that the compiler has run; I could make up a compiled state and set it, but I no way of knowing that the code was in fact compiled when I set the state to COMPILED. >> >> Correct, we can't guaranty it but it is more accurate then rely on time. I want main thread wait for COMPILED instead of RUNNING. Actually we can set RUNNING after 11000 iterations then you don't need to change code in main(). > > This seems like it would only act as documentation (above and beyond the comments already there), but if you think this is a good idea, I'll do it. Sorry, I forgot that we have warm up loop. Please, ignore my COMPILED suggestion. But move toState(RUNNING) call after print. Thanks, Vladimir > > David > > From roland.westrelin at oracle.com Tue Jan 22 00:39:04 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 Jan 2013 09:39:04 +0100 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: <50FDC6D4.6000703@oracle.com> References: <50FDC6D4.6000703@oracle.com> Message-ID: <5F656E76-0F8B-4981-A386-5C5389BC9823@oracle.com> Hi Vladimir, Thanks for reviewing this. > What is effect on ref workload? I haven't tried yet. > I would also use it for trigonometric and math (sqrt, log) intrinsics (as separate RFE after checking performance effect). Ok. I will file an RFE. > I like you factoring of sorting code in sources. It doesn't look like you like how it's used in the new code so I guess I'll file an RFE for the clean-up if it's no longer related to this change. > Why ciConstantPoolCache::_keys is array of intptr_t and not int type elements? We'r wasting space in 64bit VM and do conversion each time we access elements. I'll file an RFE for this one as well. > In growableArray.hpp call f(value, key) only once. > > In loopnode.cpp you miss 'return;' in second "if (stop_early)". > > It is very expensive to do build_loop_* when stop_early is true. Could you check before that if you have Expensive nodes with the same data inputs instead of just number of such nodes? Your list sorting should be cheaper. May be instead of flat list you should create list of pairs which have same data inputs, it will simplify processing code. I don't understand what pairs you are referring to. There can be more than 2 identical expensive nodes in a method, right? > Anyway, I think new process_expensive_nodes() method is too complex for cases which are very very rare. I think you should narrow cases for this optimization: Are you suggesting I should drop all the process_expensive_nodes() and replace it by the code below that would be applied 2 by 2 to pair of nodes with same data inputs? > c1 = get_control(n1); > c2 = get_control(n2); > > if (is_dominator(c1, c2)) { > c2 = c1; > } else if (is_dominator(c2, c1)) { > c1 = c2; > } else if (c1->is_Proj() && c1->in(0)->is_If() && > is_dominator(c1->in(0), c2)) { > c1 = c2 = c1->in(0); > } else if (c2->is_Proj() && c2->in(0)->is_If() && > is_dominator(c2->in(0), c1)) { > c1 = c2 = c2->in(0); > } > if (n1->in(0) != c1) { > n1->set_req(0, c1); > } > if (n2->in(0) != c2) { > n2->set_req(0, c2); > } My code has 3 steps: 1- Move the node up the dominator tree along paths with same frequency 2- Handle If with same computation in both branches 3- Check for computation that dominates another computation 1- and 2- is done in a loop until no more progress. You code above does 2- and 3-. Are you suggesting 1- can be dropped? Or that there's no need for 1- and 2- as separate steps in a loop? I wrote the code in process_expensive_nodes() so that it optimizes this correctly: static double m1(double a, double b) { double r1 = 0, r2 = 0, r3 = 0; for(int i = 0; i < 10000; i++) { if (a > 0) { if (b > 0) { if (b > a) { r3 = Math.pow(a,b); r2 = Math.exp(r3); } else { r3 = Math.pow(a,b); if (b > a) { m2(); } r2 = Math.exp(r3); } } else { r3 = Math.pow(a,b); r2 = Math.exp(r3); } } else { r3 = Math.pow(a, b); r2 = Math.exp(r3); } } r3 = Math.pow(a, b); r2 = Math.exp(r3); return r1 + r2 + r3; } Roland. From vladimir.kozlov at oracle.com Tue Jan 22 02:54:54 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 02:54:54 -0800 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: <5F656E76-0F8B-4981-A386-5C5389BC9823@oracle.com> References: <50FDC6D4.6000703@oracle.com> <5F656E76-0F8B-4981-A386-5C5389BC9823@oracle.com> Message-ID: <50FE6FFE.4090007@oracle.com> On 1/22/13 12:39 AM, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for reviewing this. > >> What is effect on ref workload? > > I haven't tried yet. > >> I would also use it for trigonometric and math (sqrt, log) intrinsics (as separate RFE after checking performance effect). > > Ok. I will file an RFE. > >> I like you factoring of sorting code in sources. > > It doesn't look like you like how it's used in the new code so I guess I'll file an RFE for the clean-up if it's no longer related to this change. > >> Why ciConstantPoolCache::_keys is array of intptr_t and not int type elements? We'r wasting space in 64bit VM and do conversion each time we access elements. > > I'll file an RFE for this one as well. > >> In growableArray.hpp call f(value, key) only once. >> >> In loopnode.cpp you miss 'return;' in second "if (stop_early)". >> >> It is very expensive to do build_loop_* when stop_early is true. Could you check before that if you have Expensive nodes with the same data inputs instead of just number of such nodes? Your list sorting should be cheaper. May be instead of flat list you should create list of pairs which have same data inputs, it will simplify processing code. > > I don't understand what pairs you are referring to. There can be more than 2 identical expensive nodes in a method, right? All combinations: 1-2,2-3,1-3. Will need additional check in process_expensive_nodes() to do nothing if c1==c2 (got it from processing previous pairs). > >> Anyway, I think new process_expensive_nodes() method is too complex for cases which are very very rare. I think you should narrow cases for this optimization: > > Are you suggesting I should drop all the process_expensive_nodes() and replace it by the code below that would be applied 2 by 2 to pair of nodes with same data inputs? > >> c1 = get_control(n1); >> c2 = get_control(n2); >> >> if (is_dominator(c1, c2)) { >> c2 = c1; >> } else if (is_dominator(c2, c1)) { >> c1 = c2; >> } else if (c1->is_Proj() && c1->in(0)->is_If() && >> is_dominator(c1->in(0), c2)) { >> c1 = c2 = c1->in(0); >> } else if (c2->is_Proj() && c2->in(0)->is_If() && >> is_dominator(c2->in(0), c1)) { >> c1 = c2 = c2->in(0); >> } >> if (n1->in(0) != c1) { >> n1->set_req(0, c1); >> } >> if (n2->in(0) != c2) { >> n2->set_req(0, c2); >> } > > > My code has 3 steps: > > 1- Move the node up the dominator tree along paths with same frequency In my second mail I suggested to do it in build_loop_early() method where you have early_ctrl for data inputs. > 2- Handle If with same computation in both branches > 3- Check for computation that dominates another computation > > 1- and 2- is done in a loop until no more progress. > > You code above does 2- and 3-. Are you suggesting 1- can be dropped? Or that there's no need for 1- and 2- as separate steps in a loop? > > I wrote the code in process_expensive_nodes() so that it optimizes this correctly: Which should collapse to calls only before loop. Right? Thanks, Vladimir > > static double m1(double a, double b) { > double r1 = 0, r2 = 0, r3 = 0; > > for(int i = 0; i < 10000; i++) { > if (a > 0) { > if (b > 0) { > if (b > a) { > r3 = Math.pow(a,b); > r2 = Math.exp(r3); > } else { > r3 = Math.pow(a,b); > if (b > a) { > m2(); > } > r2 = Math.exp(r3); > } > } else { > r3 = Math.pow(a,b); > r2 = Math.exp(r3); > } > } else { > r3 = Math.pow(a, b); > r2 = Math.exp(r3); > } > } > r3 = Math.pow(a, b); > r2 = Math.exp(r3); > return r1 + r2 + r3; > } > > > Roland. > From igor.ignatyev at oracle.com Tue Jan 22 03:18:19 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 22 Jan 2013 15:18:19 +0400 Subject: RFR(XS): JDK-8006410: allocating without ResourceMark when CompileCommand was specified Message-ID: <50FE757B.3070402@oracle.com> Hi, Please review the fix. Bug relates to use of Symbol::as_quoted_ascii(), which allocates new resources, without ResourceMark. Patch adds ResourceMark to all calls. Testing: JPRT webrev: http://cr.openjdk.java.net/~vlivanov/8006410/webrev.00/ JBS: https://jbs.oracle.com/bugs/browse/JDK-8006410 -- Best regards, Igor Ignatyev From roland.westrelin at oracle.com Tue Jan 22 03:44:38 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 Jan 2013 12:44:38 +0100 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: <50FE6FFE.4090007@oracle.com> References: <50FDC6D4.6000703@oracle.com> <5F656E76-0F8B-4981-A386-5C5389BC9823@oracle.com> <50FE6FFE.4090007@oracle.com> Message-ID: > All combinations: 1-2,2-3,1-3. Will need additional check in process_expensive_nodes() to do nothing if c1==c2 (got it from processing previous pairs). I don't understand why it's better than keeping a flat list. The combinations can be easily built from the list once sorted. >> 1- Move the node up the dominator tree along paths with same frequency > > In my second mail I suggested to do it in build_loop_early() method where you have early_ctrl for data inputs. But 2- can bring more opportunities to do 1- again. > >> 2- Handle If with same computation in both branches >> 3- Check for computation that dominates another computation >> >> 1- and 2- is done in a loop until no more progress. >> >> You code above does 2- and 3-. Are you suggesting 1- can be dropped? Or that there's no need for 1- and 2- as separate steps in a loop? >> >> I wrote the code in process_expensive_nodes() so that it optimizes this correctly: > > Which should collapse to calls only before loop. Right? Yes. Roland. From goetz.lindenmaier at sap.com Tue Jan 22 06:14:54 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Jan 2013 15:14:54 +0100 Subject: RFR(M): pass outputStream to more opto debug routines In-Reply-To: <50CA8ACF.1070602@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF73EB5AD@DEWDFECCR03.wdf.sap.corp> <50CA890F.6030006@oracle.com> <50CA8ACF.1070602@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF80B59C0@DEWDFECCR03.wdf.sap.corp> Hi Vladimir, sorry for the late reply. I fixed it, I like it better that way, too. But what about operators as in for (i = 0; i < req(); i++) { should I add spaces around the '=' and '<' ? And what about function calls format_helper( regalloc, st, fld_node, ":", j, &scobjs ); Should I remove the space after the bracket? I fixed all of them in this webrev: http://cr.openjdk.java.net/~goetz/webrevs/8005055/ I also based it on a recent repository. If that's not ok, no problem, I'll remove them, again. Best regards and thanks for the review, Goetz. -----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: Freitag, 14. Dezember 2012 03:11 To: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(M): pass outputStream to more opto debug routines RFE created: 8005055: pass outputStream to more opto debug routines On 12/13/12 6:03 PM, Vladimir Kozlov wrote: > Thank you, Goetz, for doing this. > > Changes are good. One thing I want to ask you is a small codding style > cleanup. We are converting all cases of "if( a )" to "if (a)" in a > methods we touch. And I see you have cases like that. > > Thanks, > Vladimir > > On 12/13/12 2:49 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> We pass the outputStream to much more debug routines than openJDK does, >> >> as we write a lot more information to files e.g., in case of a crash. >> >> I would like to contribute the changes that allow to pass the output >> stream to >> >> node->dump() and everything reachable from there. >> >> This also fixes the usage of output stream in print_register_type() in >> oopMap.cpp and >> >> in MachNullCheckNode::format(), where a single print command still >> used tty. >> >> Further we initialize _node_regs_max_index so that >> node_regs_max_index() == 0 >> >> indicates that registers of a node can be accessed. This is also >> useful in >> >> debug output. >> >> http://cr.openjdk.java.net/~goetz/webrevs/webrev-os_in_nodeDump/ >> >> Best regards, >> >> Goetz. >> From igor.ignatyev at oracle.com Tue Jan 22 07:05:13 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 22 Jan 2013 19:05:13 +0400 Subject: RFR(M): 8005439: no message about inline method if it specified by CompileCommand Message-ID: <50FEAAA9.80707@oracle.com> Hi all, Please review the fix. http://cr.openjdk.java.net/~vlivanov/8005439/webrev.00/ print_inlining is not called if method specified by '-XX:CompileCommand=inline' so it's difficult to understand that the command works or does not work. Testing: JPRT -- Best regards, Igor Ignatyev From vladimir.kozlov at oracle.com Tue Jan 22 08:08:38 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 08:08:38 -0800 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: References: <50FDC6D4.6000703@oracle.com> <5F656E76-0F8B-4981-A386-5C5389BC9823@oracle.com> <50FE6FFE.4090007@oracle.com> Message-ID: <50FEB986.4080401@oracle.com> On 1/22/13 3:44 AM, Roland Westrelin wrote: >> All combinations: 1-2,2-3,1-3. Will need additional check in process_expensive_nodes() to do nothing if c1==c2 (got it from processing previous pairs). > > I don't understand why it's better than keeping a flat list. The combinations can be easily built from the list once sorted. Yes, flat list can be used also. If you prefer it, I would not object. The only thing I really want is to check if you have similar nodes in first stop_early check. Actually, why you don't do this optimization as normal loop opt after splitIf optimization?: if (!C->major_progress() && process_expensive_nodes()) { C->set_major_progress(); } Current implementation will disturb sequence of loop opts invocations. > >>> 1- Move the node up the dominator tree along paths with same frequency >> >> In my second mail I suggested to do it in build_loop_early() method where you have early_ctrl for data inputs. > > But 2- can bring more opportunities to do 1- again. Yes, but loop opts executed several times. Why you want to do everything during one iteration? Vladimir > >> >>> 2- Handle If with same computation in both branches >>> 3- Check for computation that dominates another computation >>> >>> 1- and 2- is done in a loop until no more progress. >>> >>> You code above does 2- and 3-. Are you suggesting 1- can be dropped? Or that there's no need for 1- and 2- as separate steps in a loop? >>> >>> I wrote the code in process_expensive_nodes() so that it optimizes this correctly: >> >> Which should collapse to calls only before loop. Right? > > Yes. > > Roland. > From vladimir.kozlov at oracle.com Tue Jan 22 08:15:53 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 08:15:53 -0800 Subject: RFR(M): pass outputStream to more opto debug routines In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF80B59C0@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF73EB5AD@DEWDFECCR03.wdf.sap.corp> <50CA890F.6030006@oracle.com> <50CA8ACF.1070602@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF80B59C0@DEWDFECCR03.wdf.sap.corp> Message-ID: <50FEBB39.1000309@oracle.com> On 1/22/13 6:14 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > sorry for the late reply. I fixed it, I like it better that way, too. > > But what about operators as in > for (i = 0; i < req(); i++) { > should I add spaces around the '=' and '<' ? Yes, there should be spaces as you showed. > > And what about function calls > format_helper( regalloc, st, fld_node, ":", j, &scobjs ); > Should I remove the space after the bracket? Yes. > > I fixed all of them in this webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8005055/ This looks good. Thank you for cleanup. I will push it today. Thanks, Vladimir > I also based it on a recent repository. > If that's not ok, no problem, I'll remove them, again. > > Best regards and thanks for the review, > Goetz. > > > > -----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: Freitag, 14. Dezember 2012 03:11 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(M): pass outputStream to more opto debug routines > > RFE created: > > 8005055: pass outputStream to more opto debug routines > > On 12/13/12 6:03 PM, Vladimir Kozlov wrote: >> Thank you, Goetz, for doing this. >> >> Changes are good. One thing I want to ask you is a small codding style >> cleanup. We are converting all cases of "if( a )" to "if (a)" in a >> methods we touch. And I see you have cases like that. >> >> Thanks, >> Vladimir >> >> On 12/13/12 2:49 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> We pass the outputStream to much more debug routines than openJDK does, >>> >>> as we write a lot more information to files e.g., in case of a crash. >>> >>> I would like to contribute the changes that allow to pass the output >>> stream to >>> >>> node->dump() and everything reachable from there. >>> >>> This also fixes the usage of output stream in print_register_type() in >>> oopMap.cpp and >>> >>> in MachNullCheckNode::format(), where a single print command still >>> used tty. >>> >>> Further we initialize _node_regs_max_index so that >>> node_regs_max_index() == 0 >>> >>> indicates that registers of a node can be accessed. This is also >>> useful in >>> >>> debug output. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-os_in_nodeDump/ >>> >>> Best regards, >>> >>> Goetz. >>> From roland.westrelin at oracle.com Tue Jan 22 08:21:57 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 Jan 2013 17:21:57 +0100 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: <50FEB986.4080401@oracle.com> References: <50FDC6D4.6000703@oracle.com> <5F656E76-0F8B-4981-A386-5C5389BC9823@oracle.com> <50FE6FFE.4090007@oracle.com> <50FEB986.4080401@oracle.com> Message-ID: <6BAA7ECD-6EE6-4D95-9999-D2F783E37CA1@oracle.com> >> But 2- can bring more opportunities to do 1- again. > > Yes, but loop opts executed several times. Why you want to do everything during one iteration? It can happen without loops, with imbricated ifs. Why would we want to have multiple loop opts passes in that case if we can do everything at once? What is the benefit of doing this in build_loop_early() rather than in process_expensive_nodes? Roland. From vladimir.kozlov at oracle.com Tue Jan 22 09:11:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 09:11:57 -0800 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: <6BAA7ECD-6EE6-4D95-9999-D2F783E37CA1@oracle.com> References: <50FDC6D4.6000703@oracle.com> <5F656E76-0F8B-4981-A386-5C5389BC9823@oracle.com> <50FE6FFE.4090007@oracle.com> <50FEB986.4080401@oracle.com> <6BAA7ECD-6EE6-4D95-9999-D2F783E37CA1@oracle.com> Message-ID: <50FEC85D.70005@oracle.com> On 1/22/13 8:21 AM, Roland Westrelin wrote: >>> But 2- can bring more opportunities to do 1- again. >> >> Yes, but loop opts executed several times. Why you want to do everything during one iteration? > > It can happen without loops, with imbricated ifs. You are right. > Why would we want to have multiple loop opts passes in that case if we can do everything at once? Changing controls of one set of expensive nodes changes the dominators information of whole graph. So, strictly speaking, you can't use this information for following sets of expensive nodes. > What is the benefit of doing this in build_loop_early() rather than in process_expensive_nodes? I think find best control could be viewed as independent optimization from finding common control. And build_loop_early() logically is the best place to do it. It will also help better place nodes during build_loop_later(). Vladimir > > Roland. > From roland.westrelin at oracle.com Tue Jan 22 09:40:01 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 Jan 2013 18:40:01 +0100 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: <50FEC85D.70005@oracle.com> References: <50FDC6D4.6000703@oracle.com> <5F656E76-0F8B-4981-A386-5C5389BC9823@oracle.com> <50FE6FFE.4090007@oracle.com> <50FEB986.4080401@oracle.com> <6BAA7ECD-6EE6-4D95-9999-D2F783E37CA1@oracle.com> <50FEC85D.70005@oracle.com> Message-ID: <7BF9A87C-26E6-4C5A-B421-764AD38A5368@oracle.com> Thanks for taking the time to discuss this. I'll make the changes and send a new webrev. Roland. From vladimir.kozlov at oracle.com Tue Jan 22 11:07:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 11:07:01 -0800 Subject: RFR(XS): JDK-8006410: allocating without ResourceMark when CompileCommand was specified In-Reply-To: <50FE757B.3070402@oracle.com> References: <50FE757B.3070402@oracle.com> Message-ID: <50FEE355.7000903@oracle.com> Looks good. Vladimir On 1/22/13 3:18 AM, Igor Ignatyev wrote: > Hi, > > Please review the fix. > > Bug relates to use of Symbol::as_quoted_ascii(), which allocates new > resources, without ResourceMark. > Patch adds ResourceMark to all calls. > > Testing: JPRT > webrev: http://cr.openjdk.java.net/~vlivanov/8006410/webrev.00/ > JBS: https://jbs.oracle.com/bugs/browse/JDK-8006410 From vladimir.kozlov at oracle.com Tue Jan 22 11:18:09 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 11:18:09 -0800 Subject: RFR(M): 8005439: no message about inline method if it specified by CompileCommand In-Reply-To: <50FEAAA9.80707@oracle.com> References: <50FEAAA9.80707@oracle.com> Message-ID: <50FEE5F1.60802@oracle.com> Your changes in C2 are too intrusive for simple fix. You need separate RFE to print success message. Thanks, Vladimir On 1/22/13 7:05 AM, Igor Ignatyev wrote: > Hi all, > > Please review the fix. > > http://cr.openjdk.java.net/~vlivanov/8005439/webrev.00/ > > print_inlining is not called if method specified by > '-XX:CompileCommand=inline' > so it's difficult to understand that the command works or does not work. > > Testing: JPRT From vladimir.kozlov at oracle.com Tue Jan 22 12:20:42 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 12:20:42 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50FDCF9E.5040600@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> Message-ID: <50FEF49A.6090409@oracle.com> Thank you, Ulf I will rename method to encodeISOArray and add comment that it could be replaced by intrinsic by JVM. The same arrays were use intentionally in test to get performance of code without effect of CPU's cache/memory subsystem. The method encodeArrayLoop() is also compiled because it is invoked > 10000 times. And I don't see an effect on performance of its code change so I will leave it as it is. Thanks, Vladimir On 1/21/13 3:30 PM, Ulf Zibis wrote: > Am 17.01.2013 05:27, schrieb Vladimir Kozlov: >> On 1/12/13 12:37 AM, Ulf Zibis wrote: >>> 3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 ==> This bug is >>> not available. >> >> I opened it, should show up in few days. > > Thanks! > >> >>> 4) What specific operation should be done by the intrinsic, i.e. is >>> there a fixed API for that method ??? >> >> When C2 (server JIT compiler in JVM) compiles encode methods it will >> replace new method encodeArray() (matched by signature) with hand >> optimized assembler code which uses latest processor instructions. I >> will send Hotspot changes soon. So it is nothing to do with >> interpreter or bytecode sequence. >> >>> 5) Can an intrinsic write back more than 1 value (see my hack via int[] >>> p) ? >>> 6) Vladimir's webrev shows an integer as return type for that method, >>> I've added a variant with boolean return type, and the code from my last >>> approach could be transformed to a method with Object return type. > > I wanted to say, there would maybe different results for the surrounding > code depending on the API we choose for the intrinsic method call. If > the surrounding code is *as short as possible*, there is a better > chance, it will be JIT-compiled too after fewer invocations of > encodeArrayLoop(). I guess, the fastest would be: > > // while inlinig, JIT will erase the surrounding int[] p > private static CoderResult copyISOs(CoderResult cr, > char[] sa, byte[] da, final int[] p, int sl) { > for (int sp = p[0], dp = p[1]; sp < sl; sp++) { > char c = sa[sp]; > // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, > would be fastest > if ((byte)(c >> 8) != 0) // temporary replacement, fast > byte-length operation on x86 > return null; > da[dp++] = (byte)c; > } > return cr; > } > > // No more needs try...finally block > private CoderResult encodeArrayLoop( > CharBuffer src, ByteBuffer dst) { > char[] sa = src.array(); > int soff = src.arrayOffset(); > int sp = soff + src.position(); > int sr = src.remaining(); > byte[] da = dst.array(); > int doff = dst.arrayOffset(); > int dp = doff + dst.position(); > int dr = dst.remaining(); > CoderResult cr; > if (dr < sr) { > sr = dr; > cr = CoderResult.OVERFLOW; > } else > cr = CoderResult.UNDERFLOW; > int sl = sp + sr; > final int[] p = { sp, dp }; > cr = copyISOs(cr, sa, da, p, sl); > src.position(p[0] - soff); > dst.position(p[1] - doff); > return result(cr, sa, p[0], sl); > > } > > // if adapted, maybe could also be reused in encodeBufferLoop() > private static CoderResult result(CoderResult cr, byte[] sa, int sp, int > sl) { > return cr != null ? cr : > sgp.parse(sa[sp], sa, sp, sl) < 0 > ? sgp.error(); > : sgp.unmappableResult(); > } > > >>> >>> ... so waiting for Vladimir's feedback :-[ >>> (especially on performance/hsdis results) >> >> Performance on x86 tested with next code (whole test will be in >> Hotspot changes) : >> >> ba = CharBuffer.wrap(a); >> bb = ByteBuffer.wrap(b); >> long start = System.currentTimeMillis(); >> for (int i = 0; i < 1000000; i++) { >> ba.clear(); bb.clear(); >> enc_res = enc_res && enc.encode(ba, bb, true).isUnderflow(); >> } >> long end = System.currentTimeMillis(); > > 1.) Wouldn't System.nanoTime() give more accurate results? > 2.) I want to point out that it is not real world scenario, encoding the > same data 1.000.000 times. If same data is used, it is likely, that the > data itself becomes cached in the inner CPU cache so should have very > fast access times, which would be not the case on real world data. > 3.) It would also be interesting to see the results for less than > 1.000.000 iterations in considering, the surrounding code would be > JIT-compiled or not. Also performance on C1 should be tested. > > I also worry about the naming of method encodeArray(...). I think, it > should reflect the fact, that it only encodes ISO-8859-1 charset characters. > > Please add a comment on the fact, that method encodeArray(...) is > intended to be intrinsified. > > -Ulf > > From Ulf.Zibis at CoSoCo.de Tue Jan 22 15:57:38 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 23 Jan 2013 00:57:38 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50FEF49A.6090409@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> Message-ID: <50FF2772.7080807@CoSoCo.de> Am 22.01.2013 21:20, schrieb Vladimir Kozlov: > Thank you, Ulf > > I will rename method to encodeISOArray and add comment that it could be replaced by intrinsic by JVM. Thanks, that's much better. Thinking about, I would more like encodeArrayToISO or just encodeToISO_8859_1. > The same arrays were use intentionally in test to get performance of code without effect of CPU's > cache/memory subsystem. I worry about, if the overhead of recalculating sp and dp + comparing ret != len + complicated calculation of len will come to effect on short strings, at least on C1 and interpreter. So why not choose the best code for all these cases? > The method encodeArrayLoop() is also compiled because it is invoked > 10000 times. That is what I assumed. But I see 2 corner cases: - Programs with sparse use of ISO-8859-1 encoding will not profit of it, if the compile threshold becomes not reached. Also think about C1. - I worry, that on small strings the performance of the the intrinsic surrounding code would come to some account, even if JIT-compiled, but specially on C1 and interpreter. So would it hurt, to include those cases while tuning? -Ulf From vitalyd at gmail.com Tue Jan 22 16:14:54 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 22 Jan 2013 19:14:54 -0500 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50FF2772.7080807@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> Message-ID: Personally, optimizing for interpreter (or even C1) doesn't seem worth it. If something's truly hot and best perf is desired then use C2 or tiered. If the method isn't hot enough to trigger the C2 threshold, then why bother? You're already behind the 8 ball in terms of performance. Maybe this is heresy though :). Sent from my phone On Jan 22, 2013 6:58 PM, "Ulf Zibis" wrote: > Am 22.01.2013 21:20, schrieb Vladimir Kozlov: > >> Thank you, Ulf >> >> I will rename method to encodeISOArray and add comment that it could be >> replaced by intrinsic by JVM. >> > > Thanks, that's much better. Thinking about, I would more like > encodeArrayToISO or just encodeToISO_8859_1. > > The same arrays were use intentionally in test to get performance of code >> without effect of CPU's cache/memory subsystem. >> > > I worry about, if the overhead of recalculating sp and dp + comparing ret > != len + complicated calculation of len will come to effect on short > strings, at least on C1 and interpreter. So why not choose the best code > for all these cases? > > The method encodeArrayLoop() is also compiled because it is invoked > >> 10000 times. >> > > That is what I assumed. > But I see 2 corner cases: > - Programs with sparse use of ISO-8859-1 encoding will not profit of it, > if the compile threshold becomes not reached. Also think about C1. > - I worry, that on small strings the performance of the the intrinsic > surrounding code would come to some account, even if JIT-compiled, but > specially on C1 and interpreter. > So would it hurt, to include those cases while tuning? > > -Ulf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130122/f817c891/attachment.html From vladimir.kozlov at oracle.com Tue Jan 22 17:15:22 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 23 Jan 2013 01:15:22 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8005055: pass outputStream to more opto debug routines Message-ID: <20130123011524.E8B2F47490@hg.openjdk.java.net> Changeset: a7114d3d712e Author: kvn Date: 2013-01-22 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a7114d3d712e 8005055: pass outputStream to more opto debug routines Summary: pass the output stream to node->dump() and everything reachable from there Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp From david.holmes at oracle.com Tue Jan 22 17:15:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2013 11:15:57 +1000 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> Message-ID: <50FF39CD.6020709@oracle.com> On 23/01/2013 10:14 AM, Vitaly Davidovich wrote: > Personally, optimizing for interpreter (or even C1) doesn't seem worth it. > If something's truly hot and best perf is desired then use C2 or tiered. > If the method isn't hot enough to trigger the C2 threshold, then why > bother? You're already behind the 8 ball in terms of performance. Maybe > this is heresy though :). Not all platforms/products have C2. David > Sent from my phone > On Jan 22, 2013 6:58 PM, "Ulf Zibis" wrote: > >> Am 22.01.2013 21:20, schrieb Vladimir Kozlov: >> >>> Thank you, Ulf >>> >>> I will rename method to encodeISOArray and add comment that it could be >>> replaced by intrinsic by JVM. >>> >> >> Thanks, that's much better. Thinking about, I would more like >> encodeArrayToISO or just encodeToISO_8859_1. >> >> The same arrays were use intentionally in test to get performance of code >>> without effect of CPU's cache/memory subsystem. >>> >> >> I worry about, if the overhead of recalculating sp and dp + comparing ret >> != len + complicated calculation of len will come to effect on short >> strings, at least on C1 and interpreter. So why not choose the best code >> for all these cases? >> >> The method encodeArrayLoop() is also compiled because it is invoked> >>> 10000 times. >>> >> >> That is what I assumed. >> But I see 2 corner cases: >> - Programs with sparse use of ISO-8859-1 encoding will not profit of it, >> if the compile threshold becomes not reached. Also think about C1. >> - I worry, that on small strings the performance of the the intrinsic >> surrounding code would come to some account, even if JIT-compiled, but >> specially on C1 and interpreter. >> So would it hurt, to include those cases while tuning? >> >> -Ulf >> >> From david.r.chase at oracle.com Tue Jan 22 20:00:51 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 22 Jan 2013 23:00:51 -0500 Subject: Request for reviews (M) 8005600: compiler/8004741/Test8004741.java fails intermediately In-Reply-To: <50FE1AE6.6000506@oracle.com> References: <377E9677-1175-47AA-B322-331CE5DA047B@oracle.com> <50FDCC88.4000701@oracle.com> <3EFCDFEE-797B-42E1-A14E-B15513595468@oracle.com> <50FDF9F8.7080405@oracle.com> <73E90346-6D04-4DC4-B58F-B8BC82862228@oracle.com> <50FE1AE6.6000506@oracle.com> Message-ID: <9F6C296F-9BBF-4E94-9E75-47BF40DB18E5@oracle.com> >>> With current code we can't guaranty it. We can add an other @run command to the test to increase frequency of safepoints: done >>>>> I think this cases should be separated (separate test methods). Also it would be nice to add third case, as you suggested, by injected invalid dimension size. done > But move toState(RUNNING) call after print. done New webrev: http://cr.openjdk.java.net/~drchase/8006500/webrev.02/ Retested with JPRT focused on 8004741; failures were all bogus Windows zip failures (actually passed). Checked for continued failure of 7u11 running modified 8007471 (on MacOS). David From vladimir.kozlov at oracle.com Tue Jan 22 22:08:15 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 23 Jan 2013 06:08:15 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 Message-ID: <20130123060819.99DC0474B0@hg.openjdk.java.net> Changeset: b30b3c2a0cf2 Author: kvn Date: 2013-01-22 15:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b30b3c2a0cf2 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 Summary: Use SSE4.2 and AVX2 instructions for encodeArray intrinsic. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6896617/Test6896617.java From kirk at kodewerk.com Tue Jan 22 23:56:18 2013 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 23 Jan 2013 08:56:18 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> Message-ID: <6C37BA75-993A-4367-BC8A-7DA95C91451A@kodewerk.com> On 2013-01-23, at 1:14 AM, Vitaly Davidovich wrote: > Personally, optimizing for interpreter (or even C1) doesn't seem worth it. If something's truly hot and best perf is desired then use C2 or tiered. If the method isn't hot enough to trigger the C2 threshold, then why bother? You're already behind the 8 ball in terms of performance. Maybe this is heresy though :). > > Maybe, maybe not.. what I can say is this is a case of an optimization that doesn't scale down. In cases where scale down was needed I have recommended to customers that they "flash" their system just to push the counter beyond the compile threshold. In those cases naively compiled code was still a lot better than interrupting byte code. I've also turned off decay in a number of applications where loads weren't quite enough to beat the decay behaviour. Yeah I know this is at the risk of filling code cache but code cache occupancy is something that I regularly recommend people monitor for (check my VisualVM memory pool plug-in). In fact, I just tuned an app where I used -Xcomp to estimate how big the code cache needed to be to avoid filling it. Production settings had decay turned off. So, I can't say your wrong and I generally don't like fiddling with these setting but I will if I have to and I've had to in a number of instances where ensuring a compile beat leaving it alone. Regards, Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130123/41076097/attachment.html From igor.ignatyev at oracle.com Wed Jan 23 00:49:25 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 Jan 2013 12:49:25 +0400 Subject: RFR(M): 8005439: no message about inline method if it specified by CompileCommand In-Reply-To: <50FEE5F1.60802@oracle.com> References: <50FEAAA9.80707@oracle.com> <50FEE5F1.60802@oracle.com> Message-ID: <50FFA415.3050202@oracle.com> Hi Vladimir, Do you suggest to leave in the patch only changing of signature of methods (try_to_inline, should_inline, should_not_inline) w/o assign success message to out-parameter 'msg'? Best regards, Igor Ignatyev On 01/22/2013 11:18 PM, Vladimir Kozlov wrote: > Your changes in C2 are too intrusive for simple fix. You need separate > RFE to print success message. > > Thanks, > Vladimir > > On 1/22/13 7:05 AM, Igor Ignatyev wrote: >> Hi all, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~vlivanov/8005439/webrev.00/ >> >> print_inlining is not called if method specified by >> '-XX:CompileCommand=inline' >> so it's difficult to understand that the command works or does not work. >> >> Testing: JPRT From roland.westrelin at oracle.com Wed Jan 23 02:23:03 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 23 Jan 2013 11:23:03 +0100 Subject: RFR(XS): 8005114: VM is crashing in ciKlass*ciObjArrayKlass::element_klass() if metaspaces are full Message-ID: <787012C1-26A0-41C1-9DD7-E99ACF250DA7@oracle.com> The VM runs out of metaspace. As a consequence, in a c1 compilation, ciEnv::_unloaded_ciobjarrayklass is used for an array klass. LoadIndexed::declared_type() tries to find the element_type of this klass. LoadIndexed::declared_type() should test whether the klass is loaded. http://cr.openjdk.java.net/~roland/8005114/webrev.00/ Roland. From goetz.lindenmaier at sap.com Wed Jan 23 05:45:07 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 23 Jan 2013 14:45:07 +0100 Subject: RFR(M): pass outputStream to more opto debug routines In-Reply-To: <50FEBB39.1000309@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF73EB5AD@DEWDFECCR03.wdf.sap.corp> <50CA890F.6030006@oracle.com> <50CA8ACF.1070602@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF80B59C0@DEWDFECCR03.wdf.sap.corp> <50FEBB39.1000309@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF818CDB7@DEWDFECCR03.wdf.sap.corp> Hi Vladimir, That went fast, thanks a lot! Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Dienstag, 22. Januar 2013 17:16 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(M): pass outputStream to more opto debug routines On 1/22/13 6:14 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > sorry for the late reply. I fixed it, I like it better that way, too. > > But what about operators as in > for (i = 0; i < req(); i++) { > should I add spaces around the '=' and '<' ? Yes, there should be spaces as you showed. > > And what about function calls > format_helper( regalloc, st, fld_node, ":", j, &scobjs ); > Should I remove the space after the bracket? Yes. > > I fixed all of them in this webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8005055/ This looks good. Thank you for cleanup. I will push it today. Thanks, Vladimir > I also based it on a recent repository. > If that's not ok, no problem, I'll remove them, again. > > Best regards and thanks for the review, > Goetz. > > > > -----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: Freitag, 14. Dezember 2012 03:11 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(M): pass outputStream to more opto debug routines > > RFE created: > > 8005055: pass outputStream to more opto debug routines > > On 12/13/12 6:03 PM, Vladimir Kozlov wrote: >> Thank you, Goetz, for doing this. >> >> Changes are good. One thing I want to ask you is a small codding style >> cleanup. We are converting all cases of "if( a )" to "if (a)" in a >> methods we touch. And I see you have cases like that. >> >> Thanks, >> Vladimir >> >> On 12/13/12 2:49 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> We pass the outputStream to much more debug routines than openJDK does, >>> >>> as we write a lot more information to files e.g., in case of a crash. >>> >>> I would like to contribute the changes that allow to pass the output >>> stream to >>> >>> node->dump() and everything reachable from there. >>> >>> This also fixes the usage of output stream in print_register_type() in >>> oopMap.cpp and >>> >>> in MachNullCheckNode::format(), where a single print command still >>> used tty. >>> >>> Further we initialize _node_regs_max_index so that >>> node_regs_max_index() == 0 >>> >>> indicates that registers of a node can be accessed. This is also >>> useful in >>> >>> debug output. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-os_in_nodeDump/ >>> >>> Best regards, >>> >>> Goetz. >>> From vladimir.kozlov at oracle.com Wed Jan 23 09:08:16 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2013 09:08:16 -0800 Subject: RFR(XS): 8005114: VM is crashing in ciKlass*ciObjArrayKlass::element_klass() if metaspaces are full In-Reply-To: <787012C1-26A0-41C1-9DD7-E99ACF250DA7@oracle.com> References: <787012C1-26A0-41C1-9DD7-E99ACF250DA7@oracle.com> Message-ID: <51001900.1020500@oracle.com> Good. Vladimir On 1/23/13 2:23 AM, Roland Westrelin wrote: > The VM runs out of metaspace. As a consequence, in a c1 compilation, ciEnv::_unloaded_ciobjarrayklass is used for an array klass. LoadIndexed::declared_type() tries to find the element_type of this klass. LoadIndexed::declared_type() should test whether the klass is loaded. > > http://cr.openjdk.java.net/~roland/8005114/webrev.00/ > > Roland. > From roland.westrelin at oracle.com Wed Jan 23 09:11:12 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 23 Jan 2013 18:11:12 +0100 Subject: RFR(XS): 8005114: VM is crashing in ciKlass*ciObjArrayKlass::element_klass() if metaspaces are full In-Reply-To: <51001900.1020500@oracle.com> References: <787012C1-26A0-41C1-9DD7-E99ACF250DA7@oracle.com> <51001900.1020500@oracle.com> Message-ID: <614D58FC-EC44-4C2E-A51F-2BC14B7503DA@oracle.com> Thanks, Vladimir. Roland. From morris.meyer at oracle.com Wed Jan 23 09:27:28 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Wed, 23 Jan 2013 12:27:28 -0500 Subject: RFR (S) 6518907: cleanup IA64 specific code in Hotspot In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF7C9E883@DEWDFECCR03.wdf.sap.corp> References: <50EED1C4.3010900@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF7C9E883@DEWDFECCR03.wdf.sap.corp> Message-ID: <51001D80.801@oracle.com> Folks, I have updated the webrev to remove the AMD case cited by Vladimir Kozlov's concern and have re-run the JPRT job. Thanks, --mm JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907 WEBREV - http://cr.openjdk.java.net/~morris/6518907 On 1/10/13 9:46 AM, Lindenmaier, Goetz wrote: > > Hi Morris, > > just remove the amd case if it's unclear to you. > > I left it in just in case you find it useful. It probably belongs into > a separate change, anyways. > > Best regards, > > Goetz. > > *From:*Morris Meyer [mailto:morris.meyer at oracle.com] > *Sent:* Donnerstag, 10. Januar 2013 15:36 > *To:* hotspot-compiler-dev at openjdk.java.net; > hotspot_compiler_staff_ww_grp at oracle.com; Lindenmaier, Goetz > *Subject:* RFR (S) 6518907: cleanup IA64 specific code in Hotspot > > Gentlefolk, > > I have taken what I hope to be the final pass at > https://jbs.oracle.com/bugs/browse/JDK-6518907 and incorporated the > comments of Goetz Lindenmaier of SAP. Per the HotSpot workflow I have > submitted this change successfully to JPRT. > > Vladimir Kozlov still has a concern that has been unaddressed though, > and I would like to get resolution on this point if possible. > > /One thing concern me is code change in os.cpp for Win64: > > + // On Windows AMD64 link() does not work as there's no back link > on the stack. > + #elif (defined(IA64) || defined(AMD64)) && defined(_WIN32) > > Can someone familiar with Windows confirm if the statement in the > comment and code change are correct? / > > Thanks to all for the previous reviews. > > --mm > > JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907 > WEBREV - http://cr.openjdk.java.net/~morris/6518907 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130123/4e8f229c/attachment-0001.html From morris.meyer at oracle.com Wed Jan 23 09:40:36 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Wed, 23 Jan 2013 12:40:36 -0500 Subject: RFR (XS) 8003251: ARM: move MacroAssembler into separate file Message-ID: <51002094.1080609@oracle.com> Folks, Could I get a quick review of this very small change necessary for the refactoring requested by Christian Thalinger for moving the MacroAssembler for ARM into separate files? Per the workflow this has been successfully submitted through JPRT. Thanks in advance, --morris JBS - https://jbs.oracle.com/bugs/browse/JDK-8003251 WEBREV - http://cr.openjdk.java.net/~morris/8003251 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130123/5880c10e/attachment.html From vladimir.kozlov at oracle.com Wed Jan 23 10:10:07 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2013 10:10:07 -0800 Subject: Request for reviews (M) 8005600: compiler/8004741/Test8004741.java fails intermediately In-Reply-To: <9F6C296F-9BBF-4E94-9E75-47BF40DB18E5@oracle.com> References: <377E9677-1175-47AA-B322-331CE5DA047B@oracle.com> <50FDCC88.4000701@oracle.com> <3EFCDFEE-797B-42E1-A14E-B15513595468@oracle.com> <50FDF9F8.7080405@oracle.com> <73E90346-6D04-4DC4-B58F-B8BC82862228@oracle.com> <50FE1AE6.6000506@oracle.com> <9F6C296F-9BBF-4E94-9E75-47BF40DB18E5@oracle.com> Message-ID: <5100277F.7080503@oracle.com> One thing: (I think it was discussed before) run() method should rethrow ThreadDeath so it would be processed by VM runtime which will stop thread. Thanks, Vladimir On 1/22/13 8:00 PM, David Chase wrote: > >>>> With current code we can't guaranty it. We can add an other @run command to the test to increase frequency of safepoints: > > done > >>>>>> I think this cases should be separated (separate test methods). Also it would be nice to add third case, as you suggested, by injected invalid dimension size. > > done > >> But move toState(RUNNING) call after print. > > done > > New webrev: > > http://cr.openjdk.java.net/~drchase/8006500/webrev.02/ > > Retested with JPRT focused on 8004741; failures were all bogus Windows zip failures (actually passed). > > Checked for continued failure of 7u11 running modified 8007471 (on MacOS). > > David > From vladimir.kozlov at oracle.com Wed Jan 23 10:15:47 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2013 10:15:47 -0800 Subject: RFR(M): 8005439: no message about inline method if it specified by CompileCommand In-Reply-To: <50FFA415.3050202@oracle.com> References: <50FEAAA9.80707@oracle.com> <50FEE5F1.60802@oracle.com> <50FFA415.3050202@oracle.com> Message-ID: <510028D3.3080409@oracle.com> Igor, I think changing C2 behavior (adding detailed success message to print inlining output) requires separate RFE. As I understand C2 does not have this problem, only C1. For this bug fix I would only do your InlineTree::print_inlining() changes to make consistent LogCompilation and PrintInlining outputs. I also want to keep this fix small so we can backport it into 7 update. Thanks, Vladimir On 1/23/13 12:49 AM, Igor Ignatyev wrote: > Hi Vladimir, > > Do you suggest to leave in the patch only changing of signature of > methods (try_to_inline, should_inline, should_not_inline) w/o assign > success message to out-parameter 'msg'? > > Best regards, > Igor Ignatyev > > On 01/22/2013 11:18 PM, Vladimir Kozlov wrote: >> Your changes in C2 are too intrusive for simple fix. You need separate >> RFE to print success message. >> >> Thanks, >> Vladimir >> >> On 1/22/13 7:05 AM, Igor Ignatyev wrote: >>> Hi all, >>> >>> Please review the fix. >>> >>> http://cr.openjdk.java.net/~vlivanov/8005439/webrev.00/ >>> >>> print_inlining is not called if method specified by >>> '-XX:CompileCommand=inline' >>> so it's difficult to understand that the command works or does not work. >>> >>> Testing: JPRT From david.r.chase at oracle.com Wed Jan 23 10:41:28 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 23 Jan 2013 13:41:28 -0500 Subject: Request for reviews (M) 8005600: compiler/8004741/Test8004741.java fails intermediately In-Reply-To: <5100277F.7080503@oracle.com> References: <377E9677-1175-47AA-B322-331CE5DA047B@oracle.com> <50FDCC88.4000701@oracle.com> <3EFCDFEE-797B-42E1-A14E-B15513595468@oracle.com> <50FDF9F8.7080405@oracle.com> <73E90346-6D04-4DC4-B58F-B8BC82862228@oracle.com> <50FE1AE6.6000506@oracle.com> <9F6C296F-9BBF-4E94-9E75-47BF40DB18E5@oracle.com> <5100277F.7080503@oracle.com> Message-ID: <28F20E20-A6B5-419D-A7D5-E05C0BCDC3CF@oracle.com> On 2013-01-23, at 1:10 PM, Vladimir Kozlov wrote: > One thing: (I think it was discussed before) run() method should rethrow ThreadDeath so it would be processed by VM runtime which will stop thread. The run() method exits naturally, and the thread will stop shortly thereafter. There's no need to rethrow ThreadDeath. David From vladimir.kozlov at oracle.com Wed Jan 23 11:19:22 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2013 11:19:22 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <6C37BA75-993A-4367-BC8A-7DA95C91451A@kodewerk.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> <6C37BA75-993A-4367-BC8A-7DA95C91451A@kodewerk.com> Message-ID: <510037BA.6060403@oracle.com> To close this discussion before I do the push here are performance numbers for C1. Numbers are almost similar (few % worser, note that with C2 it improved) because C1 does not do loop optimizations. size: 1 time: 25 26 size: 7 time: 33 34 size: 8 time: 34 36 size: 16 time: 45 47 size: 32 time: 66 68 size: 64 time: 117 119 size: 128 time: 203 205 size: 256 time: 374 376 size: 512 time: 718 719 size: 1024 time: 1407 1403 size: 2048 time: 2776 2775 size: 4096 time: 5519 5517 Today is the last day when I can do this push before feature freeze. And I did tons of testing with current code (latest webrev) so I am not going to change it just before the push. Thanks, Vladimir On 1/22/13 11:56 PM, Kirk Pepperdine wrote: > > On 2013-01-23, at 1:14 AM, Vitaly Davidovich > wrote: > >> Personally, optimizing for interpreter (or even C1) doesn't seem worth >> it. If something's truly hot and best perf is desired then use C2 or >> tiered. If the method isn't hot enough to trigger the C2 threshold, >> then why bother? You're already behind the 8 ball in terms of >> performance. Maybe this is heresy though :). >> >> > Maybe, maybe not.. what I can say is this is a case of an optimization > that doesn't scale down. In cases where scale down was needed I > have recommended to customers that they "flash" their system just to > push the counter beyond the compile threshold. In those cases naively > compiled code was still a lot better than interrupting byte code. I've > also turned off decay in a number of applications where loads weren't > quite enough to beat the decay behaviour. Yeah I know this is at the > risk of filling code cache but code cache occupancy is something that I > regularly recommend people monitor for (check my VisualVM memory pool > plug-in). In fact, I just tuned an app where I used -Xcomp to estimate > how big the code cache needed to be to avoid filling it. Production > settings had decay turned off. So, I can't say your wrong and I > generally don't like fiddling with these setting but I will if I have to > and I've had to in a number of instances where ensuring a compile beat > leaving it alone. > > Regards, > Kirk > From vladimir.kozlov at oracle.com Wed Jan 23 11:39:20 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2013 11:39:20 -0800 Subject: Request for reviews (M) 8005600: compiler/8004741/Test8004741.java fails intermediately In-Reply-To: <28F20E20-A6B5-419D-A7D5-E05C0BCDC3CF@oracle.com> References: <377E9677-1175-47AA-B322-331CE5DA047B@oracle.com> <50FDCC88.4000701@oracle.com> <3EFCDFEE-797B-42E1-A14E-B15513595468@oracle.com> <50FDF9F8.7080405@oracle.com> <73E90346-6D04-4DC4-B58F-B8BC82862228@oracle.com> <50FE1AE6.6000506@oracle.com> <9F6C296F-9BBF-4E94-9E75-47BF40DB18E5@oracle.com> <5100277F.7080503@oracle.com> <28F20E20-A6B5-419D-A7D5-E05C0BCDC3CF@oracle.com> Message-ID: <51003C68.4000607@oracle.com> OK. Vladimir On 1/23/13 10:41 AM, David Chase wrote: > > On 2013-01-23, at 1:10 PM, Vladimir Kozlov wrote: > >> One thing: (I think it was discussed before) run() method should rethrow ThreadDeath so it would be processed by VM runtime which will stop thread. > > The run() method exits naturally, and the thread will stop shortly thereafter. There's no need to rethrow ThreadDeath. > > David > From vladimir.kozlov at oracle.com Wed Jan 23 14:20:45 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2013 14:20:45 -0800 Subject: Request for review (XS): 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 In-Reply-To: <50ECA935.2030703@oracle.com> References: <50ECA935.2030703@oracle.com> Message-ID: <5100623D.1020707@oracle.com> http://cr.openjdk.java.net/~kvn/8003878/webrev Limit vectors size to 16 bytes on OS X until it fixes restoration of upper 128bit of YMM registers on return from signal handler. I did it for all BSD OSs since I don't have them and I can verify their behavior. Note, in my last experiment I short-cut signal processing in JVM_handle_bsd_signal. Instead of executing safepoint blob I set address of next instruction after safepoint in compiled code and return from signal handle there: if ((sig == SIGSEGV || sig == SIGBUS) && os::is_poll_address((address)info->si_addr)) { stub = SharedRuntime::get_poll_stub(pc); + if (stub != NULL & UseNewCode) { + uc->context_pc += 6; + return true; + } But I still see that upper YMM bits are not restored. Also, I examined saved ucontext data (passed to JVM_handle_bsd_signal) and I see saved upper bits there. Something wrong with return from signal handler. Thanks, Vladimir From christian.thalinger at oracle.com Wed Jan 23 14:57:11 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Jan 2013 14:57:11 -0800 Subject: Request for review (XS): 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 In-Reply-To: <5100623D.1020707@oracle.com> References: <50ECA935.2030703@oracle.com> <5100623D.1020707@oracle.com> Message-ID: <7085E6B0-3D61-41BE-A8D0-D6D7CCED55EF@oracle.com> Looks good. -- Chris On Jan 23, 2013, at 2:20 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8003878/webrev > > Limit vectors size to 16 bytes on OS X until it fixes restoration of upper 128bit of YMM registers on return from signal handler. I did it for all BSD OSs since I don't have them and I can verify their behavior. > > Note, in my last experiment I short-cut signal processing in JVM_handle_bsd_signal. Instead of executing safepoint blob I set address of next instruction after safepoint in compiled code and return from signal handle there: > > if ((sig == SIGSEGV || sig == SIGBUS) && os::is_poll_address((address)info->si_addr)) { > stub = SharedRuntime::get_poll_stub(pc); > + if (stub != NULL & UseNewCode) { > + uc->context_pc += 6; > + return true; > + } > > But I still see that upper YMM bits are not restored. Also, I examined saved ucontext data (passed to JVM_handle_bsd_signal) and I see saved upper bits there. Something wrong with return from signal handler. > > Thanks, > Vladimir > > From vladimir.kozlov at oracle.com Wed Jan 23 14:58:18 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2013 14:58:18 -0800 Subject: Request for review (XS): 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 In-Reply-To: <7085E6B0-3D61-41BE-A8D0-D6D7CCED55EF@oracle.com> References: <50ECA935.2030703@oracle.com> <5100623D.1020707@oracle.com> <7085E6B0-3D61-41BE-A8D0-D6D7CCED55EF@oracle.com> Message-ID: <51006B0A.8040402@oracle.com> Thank you, Christian Vladimir On 1/23/13 2:57 PM, Christian Thalinger wrote: > Looks good. -- Chris > > On Jan 23, 2013, at 2:20 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8003878/webrev >> >> Limit vectors size to 16 bytes on OS X until it fixes restoration of upper 128bit of YMM registers on return from signal handler. I did it for all BSD OSs since I don't have them and I can verify their behavior. >> >> Note, in my last experiment I short-cut signal processing in JVM_handle_bsd_signal. Instead of executing safepoint blob I set address of next instruction after safepoint in compiled code and return from signal handle there: >> >> if ((sig == SIGSEGV || sig == SIGBUS) && os::is_poll_address((address)info->si_addr)) { >> stub = SharedRuntime::get_poll_stub(pc); >> + if (stub != NULL & UseNewCode) { >> + uc->context_pc += 6; >> + return true; >> + } >> >> But I still see that upper YMM bits are not restored. Also, I examined saved ucontext data (passed to JVM_handle_bsd_signal) and I see saved upper bits there. Something wrong with return from signal handler. >> >> Thanks, >> Vladimir >> >> > From vladimir.kozlov at oracle.com Wed Jan 23 15:27:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2013 15:27:32 -0800 Subject: RFR (S) 6518907: cleanup IA64 specific code in Hotspot In-Reply-To: <51001D80.801@oracle.com> References: <50EED1C4.3010900@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF7C9E883@DEWDFECCR03.wdf.sap.corp> <51001D80.801@oracle.com> Message-ID: <510071E4.2010509@oracle.com> This looks good. Thanks, Vladimir On 1/23/13 9:27 AM, Morris Meyer wrote: > Folks, > > I have updated the webrev to remove the AMD case cited by Vladimir > Kozlov's concern and have re-run the JPRT job. > > Thanks, > > --mm > > JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907 > WEBREV - http://cr.openjdk.java.net/~morris/6518907 > > On 1/10/13 9:46 AM, Lindenmaier, Goetz wrote: >> >> Hi Morris, >> >> just remove the amd case if it?s unclear to you. >> >> I left it in just in case you find it useful. It probably belongs into >> a separate change, anyways. >> >> Best regards, >> >> Goetz. >> >> *From:*Morris Meyer [mailto:morris.meyer at oracle.com] >> *Sent:* Donnerstag, 10. Januar 2013 15:36 >> *To:* hotspot-compiler-dev at openjdk.java.net; >> hotspot_compiler_staff_ww_grp at oracle.com; Lindenmaier, Goetz >> *Subject:* RFR (S) 6518907: cleanup IA64 specific code in Hotspot >> >> Gentlefolk, >> >> I have taken what I hope to be the final pass at >> https://jbs.oracle.com/bugs/browse/JDK-6518907 and incorporated the >> comments of Goetz Lindenmaier of SAP. Per the HotSpot workflow I have >> submitted this change successfully to JPRT. >> >> Vladimir Kozlov still has a concern that has been unaddressed though, >> and I would like to get resolution on this point if possible. >> >> /One thing concern me is code change in os.cpp for Win64: >> >> + // On Windows AMD64 link() does not work as there's no back link >> on the stack. >> + #elif (defined(IA64) || defined(AMD64)) && defined(_WIN32) >> >> Can someone familiar with Windows confirm if the statement in the >> comment and code change are correct? / >> >> Thanks to all for the previous reviews. >> >> --mm >> >> JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907 >> WEBREV - http://cr.openjdk.java.net/~morris/6518907 >> >> > From vladimir.kozlov at oracle.com Wed Jan 23 15:35:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2013 15:35:35 -0800 Subject: RFR(XS): Compiler crash due to out of bounds array access in Parse::do_multianewarray In-Reply-To: References: Message-ID: <510073C7.4090803@oracle.com> Thank you, Volker I created 8006807 for this. Thanks, Vladimir On 1/21/13 10:40 AM, Volker Simonis wrote: > Please review the fix for the following issue and create a BugID/Submit > the change if you find it appropriate: > > http://cr.openjdk.java.net/~simonis/webrevs/do_multianewarray/ > > > The change > for "7058510:multinewarray with 6 dimensions uncommon traps in server > compiler " > replaced the fixed sized, stack allocated array '|length|' of length 5 > with a dynamically, arena allocated array of size '|ndimensions + 1|': > > Node** length = NEW_RESOURCE_ARRAY(Node*, ndimensions + 1); > length[ndimensions] = NULL; // terminating null for make_runtime_call > > In cases where '|ndimensions|' is smaller than 4 (and bigger than 1 > because the 1-dimensional case is handled specially) this leads to field > accesses beyond the bounds of the '|length|' array later on during the > call to '|make_runtime_call(..)|' which can eventually crash the compiler: > > c = make_runtime_call(RC_NO_LEAF | RC_NO_IO, > OptoRuntime::multianewarray_Type(ndimensions), > fun, NULL, TypeRawPtr::BOTTOM, > makecon(TypeKlassPtr::make(array_klass)), > length[0], length[1], length[2], > length[3], length[4]); > > Notice that these crashes are extremely rare, because usually, there is > still some accessible memory beyond the arena allocated '|length|' > array. We only observed four crashes because of this problem in regular > nightly runs of JVM2008 during the last six month. The crashes only > happened on Windows although the problem is platform independent. I also > couldn't reproduce the problem with a test program which ran for several > hours and constantly compiled a method which allocated several two- and > three-dimensional arrays so I refrained from writing a regression test > for this problem. > > The fix is trivial: just check the value of '|ndimensions|' before > accessing the corresponding '|length|' slots and use |NULL| values for > the cases where the array slots do not exist. Notice that we only call > |make_runtime_call| if '|ndimensions|' is bigger than 1 in which case > '|length|' already contains three entries (see allocation of the > '|length|' array above). > > c = make_runtime_call(RC_NO_LEAF | RC_NO_IO, > OptoRuntime::multianewarray_Type(ndimensions), > fun, NULL, TypeRawPtr::BOTTOM, > makecon(TypeKlassPtr::make(array_klass)), > length[0], length[1], length[2], > (ndimensions > 2) ? length[3] : NULL, > (ndimensions > 3) ? length[4] : NULL); > > > > > Thank you and best regards, > Volker From dean.long at oracle.com Wed Jan 23 16:16:28 2013 From: dean.long at oracle.com (Dean Long) Date: Wed, 23 Jan 2013 16:16:28 -0800 Subject: RFR (XS) 8003251: ARM: move MacroAssembler into separate file In-Reply-To: <51002094.1080609@oracle.com> References: <51002094.1080609@oracle.com> Message-ID: <51007D5C.5050905@oracle.com> Looks OK. dl On 1/23/2013 9:40 AM, Morris Meyer wrote: > > Folks, > > Could I get a quick review of this very small change necessary for the > refactoring requested by Christian Thalinger for moving the > MacroAssembler for ARM into separate files? Per the workflow this has > been successfully submitted through JPRT. > > Thanks in advance, > > --morris > > JBS - https://jbs.oracle.com/bugs/browse/JDK-8003251 > WEBREV - http://cr.openjdk.java.net/~morris/8003251 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130123/79a2ebf3/attachment.html From vladimir.kozlov at oracle.com Wed Jan 23 21:54:55 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 24 Jan 2013 05:54:55 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 Message-ID: <20130124055500.870FC47508@hg.openjdk.java.net> Changeset: 522c328b8b77 Author: kvn Date: 2013-01-23 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/522c328b8b77 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 Summary: Limit vectors size to 16 bytes on BSD until the problem is fixed Reviewed-by: twisti ! src/cpu/x86/vm/vm_version_x86.cpp From krystal.mo at oracle.com Thu Jan 24 05:27:41 2013 From: krystal.mo at oracle.com (krystal.mo at oracle.com) Date: Thu, 24 Jan 2013 13:27:41 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8006758: LinkResolver assertion (caused by @Contended changes) Message-ID: <20130124132746.998CF47514@hg.openjdk.java.net> Changeset: 22ead76da3f4 Author: kmo Date: 2013-01-24 02:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/22ead76da3f4 8006758: LinkResolver assertion (caused by @Contended changes) Summary: treat anonymous classes as privileged code to restore the special handling for @Compiled during class file parsing Reviewed-by: jrose, coleenp, kvn, dholmes ! src/share/vm/classfile/classFileParser.cpp From yumin.qi at oracle.com Thu Jan 24 17:28:11 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 17:28:11 -0800 Subject: Question of 'contributor' at hg commit Message-ID: <5101DFAB.8000302@oracle.com> When I add yunda.mly at taobao.com in following comment: 8005278: Serviceability Agent: jmap -heap and jstack -m fail Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. Reviewed-by: dholmes, sla, coleenp Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com hg commit will give: > Changeset: 4039:59e8c1010cc1 > Author: minqi > Date: 2013-01-24 17:22 > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com Invalid contributor attribution transaction abort! rollback completed note: commit message saved in .hg/last-message.txt abort: pretxncommit hook failed The same problem happened when I integrated 6830717 (C2 Replay by Tom). It complained like this message so I have to remove tom from the commit comment! Does any one know a workaround this? Thanks Yumin From ysr1729 at gmail.com Thu Jan 24 17:31:50 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 24 Jan 2013 17:31:50 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: <5101DFAB.8000302@oracle.com> References: <5101DFAB.8000302@oracle.com> Message-ID: may be it can't parse two email addresses. Probably expecting a single email address in contributed by line? -- ramki On Thu, Jan 24, 2013 at 5:28 PM, Yumin Qi wrote: > When I add > yunda.mly at taobao.com > in following comment: > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in > vmStructs and in SA we still use old name for that. FreeList now is a > template based class which is not reflect in SA type library. When SA does > calculation of heap for CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail wherever it is > used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > hg commit will give: > > > > Changeset: 4039:59e8c1010cc1 > > Author: minqi > > Date: 2013-01-24 17:22 > > > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary > in vmStructs and in SA we still use old name for that. FreeList now is a > template based class which is not reflect in SA type library. When SA does > calculation of heap for CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail wherever it is > used in SA. > > Reviewed-by: dholmes, sla, coleenp > > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > Invalid contributor attribution > > transaction abort! > rollback completed > note: commit message saved in .hg/last-message.txt > abort: pretxncommit hook failed > > The same problem happened when I integrated 6830717 (C2 Replay by Tom). It > complained like this message so I have to remove tom from the commit > comment! Does any one know a workaround this? > > Thanks > Yumin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130124/bc23fad9/attachment.html From yumin.qi at oracle.com Thu Jan 24 17:44:45 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 17:44:45 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: References: <5101DFAB.8000302@oracle.com> Message-ID: <5101E38D.5000609@oracle.com> removed my email. Still same: [jcheck ce5e03ccbf6b 2013-01-23 16:29:50 -0800] > Changeset: 4039:49f643e94319 > Author: minqi > Date: 2013-01-24 17:43 > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com Invalid contributor attribution transaction abort! rollback completed On 1/24/2013 5:31 PM, Srinivas Ramakrishna wrote: > may be it can't parse two email addresses. Probably expecting a single > email address in contributed by line? > > -- ramki > > On Thu, Jan 24, 2013 at 5:28 PM, Yumin Qi > wrote: > > When I add > yunda.mly at taobao.com > in following comment: > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary in vmStructs and in SA we still use old > name for that. FreeList now is a template based class which is not > reflect in SA type library. When SA does calculation of heap for > CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail > wherever it is used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com > , yumin.qi at oracle.com > > > hg commit will give: > > > > Changeset: 4039:59e8c1010cc1 > > Author: minqi > > Date: 2013-01-24 17:22 > > > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > > Summary: BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary in vmStructs and in SA we still use old > name for that. FreeList now is a template based class which is not > reflect in SA type library. When SA does calculation of heap for > CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail > wherever it is used in SA. > > Reviewed-by: dholmes, sla, coleenp > > Contributed-by: yunda.mly at taobao.com > , yumin.qi at oracle.com > > > Invalid contributor attribution > > transaction abort! > rollback completed > note: commit message saved in .hg/last-message.txt > abort: pretxncommit hook failed > > The same problem happened when I integrated 6830717 (C2 Replay by > Tom). It complained like this message so I have to remove tom from > the commit comment! Does any one know a workaround this? > > Thanks > Yumin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130124/aa5b6057/attachment.html From mark.reinhold at oracle.com Thu Jan 24 17:44:45 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 24 Jan 2013 17:44:45 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: ysr1729@gmail.com; Thu, 24 Jan 2013 17:31:50 PST; Message-ID: <20130125014445.18D4B938@eggemoggin.niobe.net> 2013/1/24 17:31 -0800, ysr1729 at gmail.com: > may be it can't parse two email addresses. Probably expecting a single email > address in contributed by line? It can handle multiple addresses. Try removing the extra space before the first address, i.e., make it: Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com rather than: Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com - Mark From yumin.qi at oracle.com Thu Jan 24 17:51:37 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 17:51:37 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: <20130125014445.18D4B938@eggemoggin.niobe.net> References: <20130125014445.18D4B938@eggemoggin.niobe.net> Message-ID: <5101E529.4000506@oracle.com> Yes, no more than one leading space needed, also, the space between ',' and following email address is a must too. Very confusing. jcheck should ignore extra spaces. Thanks Yumin On 1/24/2013 5:44 PM, mark.reinhold at oracle.com wrote: > 2013/1/24 17:31 -0800, ysr1729 at gmail.com: >> may be it can't parse two email addresses. Probably expecting a single email >> address in contributed by line? > It can handle multiple addresses. Try removing the extra space before > the first address, i.e., make it: > > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > rather than: > > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > - Mark From tao.mao at oracle.com Thu Jan 24 18:26:23 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 24 Jan 2013 18:26:23 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: <5101E529.4000506@oracle.com> References: <20130125014445.18D4B938@eggemoggin.niobe.net> <5101E529.4000506@oracle.com> Message-ID: <5101ED4F.40704@oracle.com> Check out jcheck.py code http://hg.openjdk.java.net/code-tools/jcheck/dist/raw-file/tip/jcheck.py con_check = re.compile("Contributed-by: ((" + addr_pat + ")(, (" + addr_pat + "))*)$") jcheck can take multiple contributors (N >= 1) as long as you comply with the format. It's a good thing to have a format including spacing requirement. But the code probably should provide a more useful error message to correct its users. Tao On 1/24/13 5:51 PM, Yumin Qi wrote: > Yes, no more than one leading space needed, also, the space between > ',' and following email address is a must too. Very confusing. jcheck > should ignore extra spaces. > > Thanks > Yumin > > On 1/24/2013 5:44 PM, mark.reinhold at oracle.com wrote: >> 2013/1/24 17:31 -0800, ysr1729 at gmail.com: >>> may be it can't parse two email addresses. Probably expecting a >>> single email >>> address in contributed by line? >> It can handle multiple addresses. Try removing the extra space before >> the first address, i.e., make it: >> >> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >> >> rather than: >> >> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >> >> - Mark From david.holmes at oracle.com Thu Jan 24 22:07:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2013 16:07:01 +1000 Subject: Question of 'contributor' at hg commit In-Reply-To: <5101ED4F.40704@oracle.com> References: <20130125014445.18D4B938@eggemoggin.niobe.net> <5101E529.4000506@oracle.com> <5101ED4F.40704@oracle.com> Message-ID: <51022105.1010404@oracle.com> Also check out: http://openjdk.java.net/guide/producingChangeset.html#create I prefer the full form: Contributed-by: Ben Bitdiddle David On 25/01/2013 12:26 PM, Tao Mao wrote: > Check out jcheck.py code > http://hg.openjdk.java.net/code-tools/jcheck/dist/raw-file/tip/jcheck.py > > con_check = re.compile("Contributed-by: ((" + addr_pat + ")(, (" + > addr_pat + "))*)$") > > jcheck can take multiple contributors (N >= 1) as long as you comply > with the format. > > It's a good thing to have a format including spacing requirement. But > the code probably should provide a more useful error message to correct > its users. > > Tao > > On 1/24/13 5:51 PM, Yumin Qi wrote: >> Yes, no more than one leading space needed, also, the space between >> ',' and following email address is a must too. Very confusing. jcheck >> should ignore extra spaces. >> >> Thanks >> Yumin >> >> On 1/24/2013 5:44 PM, mark.reinhold at oracle.com wrote: >>> 2013/1/24 17:31 -0800, ysr1729 at gmail.com: >>>> may be it can't parse two email addresses. Probably expecting a >>>> single email >>>> address in contributed by line? >>> It can handle multiple addresses. Try removing the extra space before >>> the first address, i.e., make it: >>> >>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>> >>> rather than: >>> >>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>> >>> - Mark > From igor.ignatyev at oracle.com Fri Jan 25 10:19:58 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 25 Jan 2013 22:19:58 +0400 Subject: RFR(XS): JDK-8006410: allocating without ResourceMark when CompileCommand was specified In-Reply-To: <50FEE355.7000903@oracle.com> References: <50FE757B.3070402@oracle.com> <50FEE355.7000903@oracle.com> Message-ID: <5102CCCE.8030900@oracle.com> Thank you, Vladimir Best regards, Igor Ignatyev On 01/22/2013 11:07 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 1/22/13 3:18 AM, Igor Ignatyev wrote: >> Hi, >> >> Please review the fix. >> >> Bug relates to use of Symbol::as_quoted_ascii(), which allocates new >> resources, without ResourceMark. >> Patch adds ResourceMark to all calls. >> >> Testing: JPRT >> webrev: http://cr.openjdk.java.net/~vlivanov/8006410/webrev.00/ >> JBS: https://jbs.oracle.com/bugs/browse/JDK-8006410 From vladimir.x.ivanov at oracle.com Fri Jan 25 11:55:46 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 25 Jan 2013 22:55:46 +0300 Subject: RFR(XS): JDK-8006410: allocating without ResourceMark when CompileCommand was specified In-Reply-To: <5102CCCE.8030900@oracle.com> References: <50FE757B.3070402@oracle.com> <50FEE355.7000903@oracle.com> <5102CCCE.8030900@oracle.com> Message-ID: <5102E342.8070900@oracle.com> Looks good. I'll sponsor this change. Considering small size of the change, 1 reviewer should be enough. Best regards, Vladimir Ivanov On 1/25/13 9:19 PM, Igor Ignatyev wrote: > Thank you, Vladimir > > Best regards, > Igor Ignatyev > > On 01/22/2013 11:07 PM, Vladimir Kozlov wrote: >> Looks good. >> >> Vladimir >> >> On 1/22/13 3:18 AM, Igor Ignatyev wrote: >>> Hi, >>> >>> Please review the fix. >>> >>> Bug relates to use of Symbol::as_quoted_ascii(), which allocates new >>> resources, without ResourceMark. >>> Patch adds ResourceMark to all calls. >>> >>> Testing: JPRT >>> webrev: http://cr.openjdk.java.net/~vlivanov/8006410/webrev.00/ >>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8006410 From igor.ignatyev at oracle.com Fri Jan 25 13:02:46 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sat, 26 Jan 2013 01:02:46 +0400 Subject: RFR(M): 8005439: no message about inline method if it specified by CompileCommand In-Reply-To: <510028D3.3080409@oracle.com> References: <50FEAAA9.80707@oracle.com> <50FEE5F1.60802@oracle.com> <50FFA415.3050202@oracle.com> <510028D3.3080409@oracle.com> Message-ID: <5102F2F6.8030009@oracle.com> Hi Vladimir, Thanks a lot for feedback. I have updated the patch according to your suggestions. http://cr.openjdk.java.net/~vlivanov/8005439/webrev.01/ Best regards, Igor Ignatyev On 01/23/2013 10:15 PM, Vladimir Kozlov wrote: > Igor, > > I think changing C2 behavior (adding detailed success message to print > inlining output) requires separate RFE. As I understand C2 does not have > this problem, only C1. For this bug fix I would only do your > InlineTree::print_inlining() changes to make consistent LogCompilation > and PrintInlining outputs. > > I also want to keep this fix small so we can backport it into 7 update. > > Thanks, > Vladimir > > On 1/23/13 12:49 AM, Igor Ignatyev wrote: >> Hi Vladimir, >> >> Do you suggest to leave in the patch only changing of signature of >> methods (try_to_inline, should_inline, should_not_inline) w/o assign >> success message to out-parameter 'msg'? >> >> Best regards, >> Igor Ignatyev >> >> On 01/22/2013 11:18 PM, Vladimir Kozlov wrote: >>> Your changes in C2 are too intrusive for simple fix. You need separate >>> RFE to print success message. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/22/13 7:05 AM, Igor Ignatyev wrote: >>>> Hi all, >>>> >>>> Please review the fix. >>>> >>>> http://cr.openjdk.java.net/~vlivanov/8005439/webrev.00/ >>>> >>>> print_inlining is not called if method specified by >>>> '-XX:CompileCommand=inline' >>>> so it's difficult to understand that the command works or does not >>>> work. >>>> >>>> Testing: JPRT From vladimir.kozlov at oracle.com Fri Jan 25 13:55:44 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Jan 2013 13:55:44 -0800 Subject: RFR(M): 8005439: no message about inline method if it specified by CompileCommand In-Reply-To: <5102F2F6.8030009@oracle.com> References: <50FEAAA9.80707@oracle.com> <50FEE5F1.60802@oracle.com> <50FFA415.3050202@oracle.com> <510028D3.3080409@oracle.com> <5102F2F6.8030009@oracle.com> Message-ID: <5102FF60.8050803@oracle.com> Code style: if you continue parameters on next line align them to first parameter: ! void InlineTree::print_inlining(ciMethod* callee_method, int caller_bci, ! const char* msg, bool success) const { ! print_inlining(callee_method, caller_bci, "failed initial checks", ! false /* !success */); and several more. Otherwise it is good. Thank you for reducing changes. Thanks, Vladimir On 1/25/13 1:02 PM, Igor Ignatyev wrote: > Hi Vladimir, > > Thanks a lot for feedback. > I have updated the patch according to your suggestions. > > http://cr.openjdk.java.net/~vlivanov/8005439/webrev.01/ > > Best regards, > Igor Ignatyev > > On 01/23/2013 10:15 PM, Vladimir Kozlov wrote: >> Igor, >> >> I think changing C2 behavior (adding detailed success message to print >> inlining output) requires separate RFE. As I understand C2 does not have >> this problem, only C1. For this bug fix I would only do your >> InlineTree::print_inlining() changes to make consistent LogCompilation >> and PrintInlining outputs. >> >> I also want to keep this fix small so we can backport it into 7 update. >> >> Thanks, >> Vladimir >> >> On 1/23/13 12:49 AM, Igor Ignatyev wrote: >>> Hi Vladimir, >>> >>> Do you suggest to leave in the patch only changing of signature of >>> methods (try_to_inline, should_inline, should_not_inline) w/o assign >>> success message to out-parameter 'msg'? >>> >>> Best regards, >>> Igor Ignatyev >>> >>> On 01/22/2013 11:18 PM, Vladimir Kozlov wrote: >>>> Your changes in C2 are too intrusive for simple fix. You need separate >>>> RFE to print success message. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/22/13 7:05 AM, Igor Ignatyev wrote: >>>>> Hi all, >>>>> >>>>> Please review the fix. >>>>> >>>>> http://cr.openjdk.java.net/~vlivanov/8005439/webrev.00/ >>>>> >>>>> print_inlining is not called if method specified by >>>>> '-XX:CompileCommand=inline' >>>>> so it's difficult to understand that the command works or does not >>>>> work. >>>>> >>>>> Testing: JPRT From alejandro.murillo at oracle.com Fri Jan 25 14:40:10 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 25 Jan 2013 22:40:10 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 21 new changesets Message-ID: <20130125224054.C792647583@hg.openjdk.java.net> Changeset: 89fc17e8d808 Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/89fc17e8d808 Added tag jdk8-b74 for changeset 1a3e54283c54 ! .hgtags Changeset: e94ed1591b42 Author: sla Date: 2013-01-16 16:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e94ed1591b42 8006403: Regression: jstack failed due to the FieldInfo regression in SA Reviewed-by: sla, dholmes Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 557bda927cc2 Author: sla Date: 2013-01-18 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/557bda927cc2 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: 617b18aadb33 Author: sla Date: 2013-01-18 19:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/617b18aadb33 Merge Changeset: 203f64878aab Author: hseigel Date: 2013-01-17 10:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/203f64878aab 7102489: RFE: cleanup jlong typedef on __APPLE__and _LLP64 systems. Summary: Define jlong as long on all LP64 platforms and add JLONG_FORMAT macro. Reviewed-by: dholmes, coleenp, mikael, kvn ! src/cpu/x86/vm/jni_x86.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/java_md.h ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/launcher/java_md.c ! src/os/windows/launcher/java_md.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/tools/launcher/java.c ! src/share/tools/launcher/java.h ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/aprofiler.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.cpp Changeset: b14da2e6f2dc Author: coleenp Date: 2013-01-17 13:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b14da2e6f2dc 7174978: NPG: Fix bactrace builder for class redefinition Summary: Remove Method* from backtrace but save version so redefine classes doesn't give inaccurate line numbers. Removed old Merlin API with duplicate code. Reviewed-by: dholmes, sspitsyn ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: b5f6465019f6 Author: coleenp Date: 2013-01-17 22:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b5f6465019f6 8006548: version wrong in new constantPool code Summary: fix increment problem with saved_version Reviewed-by: dholmes ! src/share/vm/oops/constantPool.hpp Changeset: c07c102cbad7 Author: brutisso Date: 2013-01-21 09:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c07c102cbad7 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Summary: Use HW_MEMSIZE instead of HW_USERMEM to get a 64 bit value of the physical memory on the machine. Also reviewed by vitalyd at gmail.com. Reviewed-by: sla, dholmes, dlong, mikael ! src/os/bsd/vm/os_bsd.cpp Changeset: c73c3f2c5b3b Author: acorn Date: 2013-01-21 16:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c73c3f2c5b3b Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/diagnosticArgument.cpp Changeset: f3184f32ce0b Author: dcubed Date: 2013-01-22 05:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f3184f32ce0b 6444286: Possible naked oop related to biased locking revocation safepoint in jni_exit() Summary: Add missing Handle. Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/synchronizer.cpp Changeset: 22ba8c8ce6a6 Author: dcubed Date: 2013-01-22 05:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/22ba8c8ce6a6 8004902: correctness fixes motivated by contended locking work (6607129) Summary: misc correctness fixes Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: dave.dice at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.inline.hpp Changeset: 5ce621176715 Author: dcubed Date: 2013-01-22 05:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5ce621176715 8004903: VMThread::execute() calls Thread::check_for_valid_safepoint_state() on concurrent VM ops Summary: check_for_valid_safepoint_state() only applies to blocking VM ops Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/vmThread.cpp Changeset: edd23b35b1a5 Author: zgu Date: 2013-01-22 14:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/edd23b35b1a5 6871190: Don't terminate JVM if it is running in a non-interactive session Summary: Don't handle CTRL_LOGOFF_EVENT event when the process is running in a non-interactive session Reviewed-by: ctornqvi, acorn ! src/os/windows/vm/os_windows.cpp Changeset: 2ef7061f13b4 Author: zgu Date: 2013-01-22 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2ef7061f13b4 Merge ! src/os/windows/vm/os_windows.cpp Changeset: 7df93f7c14a5 Author: brutisso Date: 2013-01-16 12:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7df93f7c14a5 8006242: G1: WorkerDataArray::verify() too strict for double calculations Summary: Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp Changeset: bf8c2b2c8cfa Author: mgerdin Date: 2013-01-22 13:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bf8c2b2c8cfa 8004147: test/Makefile jtreg_tests target does not work with cygwin Reviewed-by: ctornqvi, brutisso ! test/Makefile Changeset: d754ef7b9352 Author: jmasa Date: 2013-01-24 06:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d754ef7b9352 Merge Changeset: 274a29bf5682 Author: kmo Date: 2013-01-24 09:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/274a29bf5682 Merge Changeset: b4391649e91e Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b4391649e91e Merge ! .hgtags Changeset: 6778d0b16593 Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6778d0b16593 Added tag hs25-b17 for changeset b4391649e91e ! .hgtags Changeset: 6fbe8a57549d Author: amurillo Date: 2013-01-25 03:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6fbe8a57549d 8006827: new hotspot build - hs25-b18 Reviewed-by: jcoomes ! make/hotspot_version From Ulf.Zibis at CoSoCo.de Fri Jan 25 17:06:28 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 26 Jan 2013 02:06:28 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F993BD.5020607@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50F993BD.5020607@oracle.com> Message-ID: <51032C14.3070904@CoSoCo.de> Am 18.01.2013 19:26, schrieb Vladimir Kozlov: > Here are Hotspot changes with new jtreg test: > > http://cr.openjdk.java.net/~kvn/6896617/webrev Hi Vladimir, now I've tried to understand your hotspot code :-) I tried to do some optimization with less jumps for small strings: jmp(len >= 8) --> L_check_16_chars L_check_1_char: jmp(len = 0) --> L_done L_init_1_mask: init_1_mask(); L_copy_1_char: jmp(*src | mask) --> L_unmappable copy_1_char(len++); jmp(len != 0) --> copy_1_char L_done: return(result) L_check_16_chars: jmp(len >= 16) --> L_check_32_chars L_init_8_masks: init_8_masks(); jmp(*src | mask) --> L_init_1_mask copy_8_chars(len++8); jmp(len != 0) --> L_init_1_mask jmp() --> L_done L_check_32_chars: jmp(len >= 32) --> L_init_32_masks: L_init_16_masks: init_16_masks(); jmp(*src | mask) --> L_init_8_masks copy_16_chars(len++16); jmp(len >= 8) --> L_init_8_masks jmp() --> L_check_1_char L_init_32_masks: init_32_masks(); L_copy_32_chars: jmp(*src | mask) --> L_init_16_masks copy_32_chars(len++32); jmp(len >= 32) --> copy_32_chars jmp() --> L_check_16_chars L_unmappable: result += len; jmp() --> L_done -Ulf From Ulf.Zibis at CoSoCo.de Fri Jan 25 17:38:07 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 26 Jan 2013 02:38:07 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F993BD.5020607@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50F993BD.5020607@oracle.com> Message-ID: <5103337F.2070900@CoSoCo.de> Am 18.01.2013 19:26, schrieb Vladimir Kozlov: > Here are Hotspot changes with new jtreg test: > > http://cr.openjdk.java.net/~kvn/6896617/webrev Hi Vladimir, additionnally instead: 6322 load_unsigned_short(tmp5, Address(src, len, Address::times_2, 0)); 6323 testl(tmp5, 0xff00); // check if Unicode char 6324 jccb(Assembler::notZero, L_copy_1_char_exit); 6325 movb(Address(dst, len, Address::times_1, 0), tmp5); you could do something like: 6322 load_unsigned_byte(tmp5, Address(src, len, Address::times_2, 1)); 6323 jccb(Assembler::notZero, L_copy_1_char_exit); // check if ISO-8859-1 char 6324 movb(Address(dst, len, Address::times_1, 0), Address(src, len, Address::times_2, 0)); There is no need to compare against an additional constant, just check the high-byte for 0. ... and your comment // check if Unicode char is wrong, as it is always a Unicode char, so correct: // check if ISO-8859-1 char Similar for lines 6245, 6269 ! -Ulf From Ulf.Zibis at CoSoCo.de Fri Jan 25 18:51:15 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 26 Jan 2013 03:51:15 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F993BD.5020607@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50F993BD.5020607@oracle.com> Message-ID: <510344A3.4020305@CoSoCo.de> Am 18.01.2013 19:26, schrieb Vladimir Kozlov: > Here are Hotspot changes with new jtreg test: > > http://cr.openjdk.java.net/~kvn/6896617/webrev Hi Vladimir, I'm wondering if there would be a similar intrinsic for the reverse decode case? Also sun.nio.cs.ASCII$Encode.encodeArrayLoop() could profit from PACKUSWB intrinsic. Maybe the mask, here 0xFF80, could be passed by an additional parameter, so the same intrinsic could serve for both. Maybe Base64 coders could be considered too. What about XXX$encodeBufferLoop()? Could there implemented a similar intrinsic? -Ulf From Ulf.Zibis at CoSoCo.de Fri Jan 25 19:08:50 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 26 Jan 2013 04:08:50 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <6C37BA75-993A-4367-BC8A-7DA95C91451A@kodewerk.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> <6C37BA75-993A-4367-BC8A-7DA95C91451A@kodewerk.com> Message-ID: <510348C2.6070605@CoSoCo.de> Am 23.01.2013 08:56, schrieb Kirk Pepperdine: > > On 2013-01-23, at 1:14 AM, Vitaly Davidovich > wrote: > >> Personally, optimizing for interpreter (or even C1) doesn't seem worth it. If something's truly >> hot and best perf is desired then use C2 or tiered. If the method isn't hot enough to trigger >> the C2 threshold, then why bother? You're already behind the 8 ball in terms of performance. >> Maybe this is heresy though :). >> >> > Maybe, maybe not.. what I can say is this is a case of an optimization that doesn't scale down. In > cases where scale down was needed I have recommended to customers that they "flash" their system > just to push the counter beyond the compile threshold. In those cases naively compiled code was > still a lot better than interrupting byte code. I've also turned off decay in a number of > applications where loads weren't quite enough to beat the decay behaviour. Yeah I know this is at > the risk of filling code cache but code cache occupancy is something that I regularly recommend > people monitor for (check my VisualVM memory pool plug-in). In fact, I just tuned an app where I > used -Xcomp to estimate how big the code cache needed to be to avoid filling it. Production > settings had decay turned off. So, I can't say your wrong and I generally don't like fiddling with > these setting but I will if I have to and I've had to in a number of instances where ensuring a > compile beat leaving it alone. This is why I considered to include the surrounding code/API in the optimization thoughts as well for possible better performance for small strings, even on C2 or for less than 10.000 invocations. -Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130126/79c6a724/attachment-0001.html From Ulf.Zibis at CoSoCo.de Fri Jan 25 19:12:38 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 26 Jan 2013 04:12:38 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50FF39CD.6020709@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> <50FF39CD.6020709@oracle.com> Message-ID: <510349A6.1000908@CoSoCo.de> Am 23.01.2013 02:15, schrieb David Holmes: > On 23/01/2013 10:14 AM, Vitaly Davidovich wrote: >> Personally, optimizing for interpreter (or even C1) doesn't seem worth it. >> If something's truly hot and best perf is desired then use C2 or tiered. >> If the method isn't hot enough to trigger the C2 threshold, then why >> bother? You're already behind the 8 ball in terms of performance. Maybe >> this is heresy though :). > > Not all platforms/products have C2. And some people may use C1 intentionally for faster start-up. -Ulf From igor.ignatyev at oracle.com Sat Jan 26 03:01:17 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sat, 26 Jan 2013 15:01:17 +0400 Subject: RFR(M): 8005439: no message about inline method if it specified by CompileCommand In-Reply-To: <5102FF60.8050803@oracle.com> References: <50FEAAA9.80707@oracle.com> <50FEE5F1.60802@oracle.com> <50FFA415.3050202@oracle.com> <510028D3.3080409@oracle.com> <5102F2F6.8030009@oracle.com> <5102FF60.8050803@oracle.com> Message-ID: <5103B77D.1030608@oracle.com> Thank you for review. code style was cleaned up: http://cr.openjdk.java.net/~vlivanov/8005439/webrev.02/ Best regards, Igor Ignatyev On 01/26/2013 01:55 AM, Vladimir Kozlov wrote: > Code style: if you continue parameters on next line align them to first > parameter: > > ! void InlineTree::print_inlining(ciMethod* callee_method, int caller_bci, > ! const char* msg, bool success) const { > > ! print_inlining(callee_method, caller_bci, "failed initial checks", > ! false /* !success */); > > and several more. > > Otherwise it is good. Thank you for reducing changes. > > Thanks, > Vladimir > > On 1/25/13 1:02 PM, Igor Ignatyev wrote: >> Hi Vladimir, >> >> Thanks a lot for feedback. >> I have updated the patch according to your suggestions. >> >> http://cr.openjdk.java.net/~vlivanov/8005439/webrev.01/ >> >> Best regards, >> Igor Ignatyev >> >> On 01/23/2013 10:15 PM, Vladimir Kozlov wrote: >>> Igor, >>> >>> I think changing C2 behavior (adding detailed success message to print >>> inlining output) requires separate RFE. As I understand C2 does not have >>> this problem, only C1. For this bug fix I would only do your >>> InlineTree::print_inlining() changes to make consistent LogCompilation >>> and PrintInlining outputs. >>> >>> I also want to keep this fix small so we can backport it into 7 update. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/23/13 12:49 AM, Igor Ignatyev wrote: >>>> Hi Vladimir, >>>> >>>> Do you suggest to leave in the patch only changing of signature of >>>> methods (try_to_inline, should_inline, should_not_inline) w/o assign >>>> success message to out-parameter 'msg'? >>>> >>>> Best regards, >>>> Igor Ignatyev >>>> >>>> On 01/22/2013 11:18 PM, Vladimir Kozlov wrote: >>>>> Your changes in C2 are too intrusive for simple fix. You need separate >>>>> RFE to print success message. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/22/13 7:05 AM, Igor Ignatyev wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review the fix. >>>>>> >>>>>> http://cr.openjdk.java.net/~vlivanov/8005439/webrev.00/ >>>>>> >>>>>> print_inlining is not called if method specified by >>>>>> '-XX:CompileCommand=inline' >>>>>> so it's difficult to understand that the command works or does not >>>>>> work. >>>>>> >>>>>> Testing: JPRT From vladimir.kozlov at oracle.com Sun Jan 27 14:05:28 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 27 Jan 2013 14:05:28 -0800 Subject: RFR(M): 8005439: no message about inline method if it specified by CompileCommand In-Reply-To: <5103B77D.1030608@oracle.com> References: <50FEAAA9.80707@oracle.com> <50FEE5F1.60802@oracle.com> <50FFA415.3050202@oracle.com> <510028D3.3080409@oracle.com> <5102F2F6.8030009@oracle.com> <5102FF60.8050803@oracle.com> <5103B77D.1030608@oracle.com> Message-ID: <5105A4A8.4020401@oracle.com> It is good. Thanks, Vladimir On 1/26/13 3:01 AM, Igor Ignatyev wrote: > Thank you for review. > > code style was cleaned up: > http://cr.openjdk.java.net/~vlivanov/8005439/webrev.02/ > > Best regards, > Igor Ignatyev > > On 01/26/2013 01:55 AM, Vladimir Kozlov wrote: >> Code style: if you continue parameters on next line align them to first >> parameter: >> >> ! void InlineTree::print_inlining(ciMethod* callee_method, int >> caller_bci, >> ! const char* msg, bool success) const { >> >> ! print_inlining(callee_method, caller_bci, "failed initial checks", >> ! false /* !success */); >> >> and several more. >> >> Otherwise it is good. Thank you for reducing changes. >> >> Thanks, >> Vladimir >> >> On 1/25/13 1:02 PM, Igor Ignatyev wrote: >>> Hi Vladimir, >>> >>> Thanks a lot for feedback. >>> I have updated the patch according to your suggestions. >>> >>> http://cr.openjdk.java.net/~vlivanov/8005439/webrev.01/ >>> >>> Best regards, >>> Igor Ignatyev >>> >>> On 01/23/2013 10:15 PM, Vladimir Kozlov wrote: >>>> Igor, >>>> >>>> I think changing C2 behavior (adding detailed success message to print >>>> inlining output) requires separate RFE. As I understand C2 does not >>>> have >>>> this problem, only C1. For this bug fix I would only do your >>>> InlineTree::print_inlining() changes to make consistent LogCompilation >>>> and PrintInlining outputs. >>>> >>>> I also want to keep this fix small so we can backport it into 7 update. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/23/13 12:49 AM, Igor Ignatyev wrote: >>>>> Hi Vladimir, >>>>> >>>>> Do you suggest to leave in the patch only changing of signature of >>>>> methods (try_to_inline, should_inline, should_not_inline) w/o assign >>>>> success message to out-parameter 'msg'? >>>>> >>>>> Best regards, >>>>> Igor Ignatyev >>>>> >>>>> On 01/22/2013 11:18 PM, Vladimir Kozlov wrote: >>>>>> Your changes in C2 are too intrusive for simple fix. You need >>>>>> separate >>>>>> RFE to print success message. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 1/22/13 7:05 AM, Igor Ignatyev wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review the fix. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~vlivanov/8005439/webrev.00/ >>>>>>> >>>>>>> print_inlining is not called if method specified by >>>>>>> '-XX:CompileCommand=inline' >>>>>>> so it's difficult to understand that the command works or does not >>>>>>> work. >>>>>>> >>>>>>> Testing: JPRT From vladimir.x.ivanov at oracle.com Mon Jan 28 06:26:04 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 28 Jan 2013 17:26:04 +0300 Subject: RFR(M): 8005439: no message about inline method if it specified by CompileCommand In-Reply-To: <5105A4A8.4020401@oracle.com> References: <50FEAAA9.80707@oracle.com> <50FEE5F1.60802@oracle.com> <50FFA415.3050202@oracle.com> <510028D3.3080409@oracle.com> <5102F2F6.8030009@oracle.com> <5102FF60.8050803@oracle.com> <5103B77D.1030608@oracle.com> <5105A4A8.4020401@oracle.com> Message-ID: <51068A7C.4090609@oracle.com> I'll sponsor the fix. Best regards, Vladimir Ivanov On 1/28/13 1:05 AM, Vladimir Kozlov wrote: > It is good. > > Thanks, > Vladimir > > On 1/26/13 3:01 AM, Igor Ignatyev wrote: >> Thank you for review. >> >> code style was cleaned up: >> http://cr.openjdk.java.net/~vlivanov/8005439/webrev.02/ >> >> Best regards, >> Igor Ignatyev >> >> On 01/26/2013 01:55 AM, Vladimir Kozlov wrote: >>> Code style: if you continue parameters on next line align them to first >>> parameter: >>> >>> ! void InlineTree::print_inlining(ciMethod* callee_method, int >>> caller_bci, >>> ! const char* msg, bool success) const { >>> >>> ! print_inlining(callee_method, caller_bci, "failed initial checks", >>> ! false /* !success */); >>> >>> and several more. >>> >>> Otherwise it is good. Thank you for reducing changes. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/25/13 1:02 PM, Igor Ignatyev wrote: >>>> Hi Vladimir, >>>> >>>> Thanks a lot for feedback. >>>> I have updated the patch according to your suggestions. >>>> >>>> http://cr.openjdk.java.net/~vlivanov/8005439/webrev.01/ >>>> >>>> Best regards, >>>> Igor Ignatyev >>>> >>>> On 01/23/2013 10:15 PM, Vladimir Kozlov wrote: >>>>> Igor, >>>>> >>>>> I think changing C2 behavior (adding detailed success message to print >>>>> inlining output) requires separate RFE. As I understand C2 does not >>>>> have >>>>> this problem, only C1. For this bug fix I would only do your >>>>> InlineTree::print_inlining() changes to make consistent LogCompilation >>>>> and PrintInlining outputs. >>>>> >>>>> I also want to keep this fix small so we can backport it into 7 >>>>> update. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/23/13 12:49 AM, Igor Ignatyev wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> Do you suggest to leave in the patch only changing of signature of >>>>>> methods (try_to_inline, should_inline, should_not_inline) w/o assign >>>>>> success message to out-parameter 'msg'? >>>>>> >>>>>> Best regards, >>>>>> Igor Ignatyev >>>>>> >>>>>> On 01/22/2013 11:18 PM, Vladimir Kozlov wrote: >>>>>>> Your changes in C2 are too intrusive for simple fix. You need >>>>>>> separate >>>>>>> RFE to print success message. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 1/22/13 7:05 AM, Igor Ignatyev wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review the fix. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8005439/webrev.00/ >>>>>>>> >>>>>>>> print_inlining is not called if method specified by >>>>>>>> '-XX:CompileCommand=inline' >>>>>>>> so it's difficult to understand that the command works or does not >>>>>>>> work. >>>>>>>> >>>>>>>> Testing: JPRT From igor.ignatyev at oracle.com Mon Jan 28 22:28:12 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 29 Jan 2013 10:28:12 +0400 Subject: RFR(S): JDK-8006613: adding reason to made_not_compilable Message-ID: <51076BFC.2070701@oracle.com> Hi all, Please review the patch. patch extends signature of methods 'Method::set_not_compilable', 'Method::set_not_osr_compilable' and 'Method::print_made_not_compilable' by adding reason webrev: http://cr.openjdk.java.net/~vlivanov/8006613/webrev.00/ JBS: https://jbs.oracle.com/bugs/browse/JDK-8006613 -- Best regards, Igor Ignatyev From nils.eliasson at oracle.com Tue Jan 29 02:56:31 2013 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 29 Jan 2013 11:56:31 +0100 Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist iteration Message-ID: <5107AADF.6010501@oracle.com> Remove continuous free block requirement for code cache flushing and minimum free space. This causes a degenerate behavior when the VM are repeatedly flushing the code cache trying to free up a continuous 1,5M block. Since the freelist is fragmented a significant part of the code cache is kept unallocated. A significant amount of time is spent traversing the freelist holding the code cache lock or waiting for other threads doing the same. I don't see any reason for why a continuous block is required. Code cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is default 1,5M and code cache minimum threshold (CodeCacheMinimumFreeSpace) is 0,5M. Finding such a block on the freelist is often unrealistic, and has not any purpose. The largest nmethods are in the order of 250k, and they are not allocated when code cache is starting to run out. All critical adapters are small and will fit easily in the freelist or in the remaining heap space. http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/ Thanks, Nils Eliasson From roland.westrelin at oracle.com Tue Jan 29 07:48:51 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 29 Jan 2013 16:48:51 +0100 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: <50FDC6D4.6000703@oracle.com> References: <50FDC6D4.6000703@oracle.com> Message-ID: <90BF5755-9BDA-49ED-88ED-392C55A279F1@oracle.com> Here is a new webrev: http://cr.openjdk.java.net/~roland/7197327/webrev.01/ > What is effect on ref workload? I haven't done a refworkload on this latest version but on a previous one, refworkload shown nothing of interests except the improvement on specjvm2008's mpegaudio. I'll redo refworkload before the push. > c1 = get_control(n1); > c2 = get_control(n2); > > if (is_dominator(c1, c2)) { > c2 = c1; > } else if (is_dominator(c2, c1)) { > c1 = c2; The 2 tests below cannot work because they don't guarantee that c2 is in the other If branch or that c2 is not on the other branch but inside an imbricated If: > } else if (c1->is_Proj() && c1->in(0)->is_If() && > is_dominator(c1->in(0), c2)) { > c1 = c2 = c1->in(0); > } else if (c2->is_Proj() && c2->in(0)->is_If() && > is_dominator(c2->in(0), c1)) { > c1 = c2 = c2->in(0); > } > if (n1->in(0) != c1) { > n1->set_req(0, c1); > } > if (n2->in(0) != c2) { > n2->set_req(0, c2); > } Roland. From volker.simonis at gmail.com Tue Jan 29 10:41:50 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 29 Jan 2013 19:41:50 +0100 Subject: RFR (XXS): 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray Message-ID: Please review the fix for the following issue and submit the change if you find it appropriate: http://cr.openjdk.java.net/~simonis/webrevs/8006807/ The change for "7058510:multinewarray with 6 dimensions uncommon traps in server compiler" replaced the fixed sized, stack allocated array 'length' of length 5 with a dynamically, arena allocated array of size 'ndimensions + 1': Node** length = NEW_RESOURCE_ARRAY(Node*, ndimensions + 1); length[ndimensions] = NULL; // terminating null for make_runtime_call In cases where 'ndimensions' is smaller than 4 (and bigger than 1 because the 1-dimensional case is handled specially) this leads to field accesses beyond the bounds of the 'length' array later on during the call to ' make_runtime_call(..)' which can eventually crash the compiler: c = make_runtime_call(RC_NO_LEAF | RC_NO_IO, OptoRuntime::multianewarray_Type(ndimensions), fun, NULL, TypeRawPtr::BOTTOM, makecon(TypeKlassPtr::make(array_klass)), length[0], length[1], length[2], length[3], length[4]); Notice that these crashes are extremely rare, because usually, there is still some accessible memory beyond the arena allocated 'length' array. We only observed four crashes because of this problem in regular nightly runs of JVM2008 during the last six month. The crashes only happened on Windows although the problem is platform independent. I also couldn't reproduce the problem with a test program which ran for several hours and constantly compiled a method which allocated several two- and three-dimensional arrays so I refrained from writing a regression test for this problem. The fix is trivial: just check the value of 'ndimensions' before accessing the corresponding 'length' slots and use NULL values for the cases where the array slots do not exist. Notice that we only call make_runtime_call if 'ndimensions' is bigger than 1 in which case 'length' already contains three entries (see allocation of the 'length' array above). c = make_runtime_call(RC_NO_LEAF | RC_NO_IO, OptoRuntime::multianewarray_Type(ndimensions), fun, NULL, TypeRawPtr::BOTTOM, makecon(TypeKlassPtr::make(array_klass)), length[0], length[1], length[2], (ndimensions > 2) ? length[3] : NULL, (ndimensions > 3) ? length[4] : NULL); Thank you and best regards, Volker -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130129/2e857d06/attachment.html From david.r.chase at oracle.com Tue Jan 29 10:50:15 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 29 Jan 2013 13:50:15 -0500 Subject: RFR (XXS): 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray In-Reply-To: References: Message-ID: <4B410E0C-BE3D-42AB-86EC-B0887499DAB5@oracle.com> On 2013-01-29, at 1:41 PM, Volker Simonis wrote: > Please review the fix for the following issue and submit the change if you find it appropriate: > > http://cr.openjdk.java.net/~simonis/webrevs/8006807/ It's reviewed and appropriate, just waiting on testing resources to free up a little at this end. Thanks much for the report, fix, and (unfortunately necessary) patience. David From vladimir.kozlov at oracle.com Tue Jan 29 11:19:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Jan 2013 11:19:13 -0800 Subject: RFR(S): JDK-8006613: adding reason to made_not_compilable In-Reply-To: <51076BFC.2070701@oracle.com> References: <51076BFC.2070701@oracle.com> Message-ID: <510820B1.6000401@oracle.com> This looks good. Igor, what is a motivation behind all these resent log compilation changes? Thanks, Vladimir On 1/28/13 10:28 PM, Igor Ignatyev wrote: > Hi all, > > Please review the patch. > > patch extends signature of methods 'Method::set_not_compilable', > 'Method::set_not_osr_compilable' and 'Method::print_made_not_compilable' > by adding reason > > webrev: http://cr.openjdk.java.net/~vlivanov/8006613/webrev.00/ > JBS: https://jbs.oracle.com/bugs/browse/JDK-8006613 From vladimir.kozlov at oracle.com Tue Jan 29 11:35:53 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Jan 2013 11:35:53 -0800 Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist iteration In-Reply-To: <5107AADF.6010501@oracle.com> References: <5107AADF.6010501@oracle.com> Message-ID: <51082499.3000905@oracle.com> Nils, You are reversing 7025742 fix. I would prefer to keep track of a largest free block during allocation in CodeCache (by using ordered list or other technique) to avoid scanning the list. Vladimir On 1/29/13 2:56 AM, Nils Eliasson wrote: > Remove continuous free block requirement for code cache flushing and > minimum free space. > > This causes a degenerate behavior when the VM are repeatedly flushing > the code cache trying to free up a continuous 1,5M block. Since the > freelist is fragmented a significant part of the code cache is kept > unallocated. A significant amount of time is spent traversing the > freelist holding the code cache lock or waiting for other threads doing > the same. > > I don't see any reason for why a continuous block is required. Code > cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is default > 1,5M and code cache minimum threshold (CodeCacheMinimumFreeSpace) is > 0,5M. Finding such a block on the freelist is often unrealistic, and has > not any purpose. The largest nmethods are in the order of 250k, and they > are not allocated when code cache is starting to run out. All critical > adapters are small and will fit easily in the freelist or in the > remaining heap space. > > http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/ > > Thanks, > Nils Eliasson From vladimir.kozlov at oracle.com Tue Jan 29 11:56:20 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Jan 2013 11:56:20 -0800 Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist iteration In-Reply-To: <51082499.3000905@oracle.com> References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com> Message-ID: <51082964.2070009@oracle.com> On 1/29/13 11:35 AM, Vladimir Kozlov wrote: > Nils, > > You are reversing 7025742 fix. I would prefer to keep track of a largest > free block during allocation in CodeCache (by using ordered list or > other technique) to avoid scanning the list. And I agree that we should stop flashing if it is not successful after first (or second) iteration. Thanks, Vladimir > > Vladimir > > On 1/29/13 2:56 AM, Nils Eliasson wrote: >> Remove continuous free block requirement for code cache flushing and >> minimum free space. >> >> This causes a degenerate behavior when the VM are repeatedly flushing >> the code cache trying to free up a continuous 1,5M block. Since the >> freelist is fragmented a significant part of the code cache is kept >> unallocated. A significant amount of time is spent traversing the >> freelist holding the code cache lock or waiting for other threads doing >> the same. >> >> I don't see any reason for why a continuous block is required. Code >> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is default >> 1,5M and code cache minimum threshold (CodeCacheMinimumFreeSpace) is >> 0,5M. Finding such a block on the freelist is often unrealistic, and has >> not any purpose. The largest nmethods are in the order of 250k, and they >> are not allocated when code cache is starting to run out. All critical >> adapters are small and will fit easily in the freelist or in the >> remaining heap space. >> >> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/ >> >> Thanks, >> Nils Eliasson From igor.ignatyev at oracle.com Tue Jan 29 12:08:03 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 30 Jan 2013 00:08:03 +0400 Subject: RFR(S): JDK-8006613: adding reason to made_not_compilable In-Reply-To: <510820B1.6000401@oracle.com> References: <51076BFC.2070701@oracle.com> <510820B1.6000401@oracle.com> Message-ID: <51082C23.8010007@oracle.com> Vladimir, thank you for review. > Igor, what is a motivation behind all these resent log compilation changes? When we (VM SQE team) started writing tests for CompileCommand flag, we were faced with problems of recognition its actions in cout/log. Thus, motivation is simple: we need these changes for better testing. Best regards, Igor Ignatyev On 01/29/2013 11:19 PM, Vladimir Kozlov wrote: > This looks good. > > Igor, what is a motivation behind all these resent log compilation changes? > > Thanks, > Vladimir > > On 1/28/13 10:28 PM, Igor Ignatyev wrote: >> Hi all, >> >> Please review the patch. >> >> patch extends signature of methods 'Method::set_not_compilable', >> 'Method::set_not_osr_compilable' and 'Method::print_made_not_compilable' >> by adding reason >> >> webrev: http://cr.openjdk.java.net/~vlivanov/8006613/webrev.00/ >> JBS: https://jbs.oracle.com/bugs/browse/JDK-8006613 From igor.ignatyev at oracle.com Tue Jan 29 12:31:46 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 30 Jan 2013 00:31:46 +0400 Subject: RFR(M): 8006683: Add WhiteBox API to testing of compiler Message-ID: <510831B2.3080307@oracle.com> Hi all, Please review the patch 1. added new functions to WhiteBox: public native void deoptimizeAll(); public native boolean isMethodCompiled(Method method); public native boolean isMethodCompilable(Method method); public native boolean isMethodQueuedForCompilation(Method method); public native int deoptimizeMethod(Method method); public native boolean setDontInlineMethod(Method method, boolean value); public native int getCompileQueuesSize(); 2. added test 'test/compiler/WBApiTest.java' which exercises these functions 3. added result type to macro WB_METHOD_DECLARE webrev: http://cr.openjdk.java.net/~vlivanov/8006683/webrev.00/ -- Best regards, Igor Ignatyev From vladimir.kozlov at oracle.com Tue Jan 29 12:52:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Jan 2013 12:52:52 -0800 Subject: RFR(S): JDK-8006613: adding reason to made_not_compilable In-Reply-To: <51082C23.8010007@oracle.com> References: <51076BFC.2070701@oracle.com> <510820B1.6000401@oracle.com> <51082C23.8010007@oracle.com> Message-ID: <510836A4.7070704@oracle.com> On 1/29/13 12:08 PM, Igor Ignatyev wrote: > Vladimir, thank you for review. > > > Igor, what is a motivation behind all these resent log compilation > changes? > > When we (VM SQE team) started writing tests for CompileCommand flag, we > were faced with problems of recognition its actions in cout/log. Thus, > motivation is simple: we need these changes for better testing. Yes, it makes sense. We need better testing :) Thanks, Vladimir > > Best regards, > Igor Ignatyev > > On 01/29/2013 11:19 PM, Vladimir Kozlov wrote: >> This looks good. >> >> Igor, what is a motivation behind all these resent log compilation >> changes? >> >> Thanks, >> Vladimir >> >> On 1/28/13 10:28 PM, Igor Ignatyev wrote: >>> Hi all, >>> >>> Please review the patch. >>> >>> patch extends signature of methods 'Method::set_not_compilable', >>> 'Method::set_not_osr_compilable' and 'Method::print_made_not_compilable' >>> by adding reason >>> >>> webrev: http://cr.openjdk.java.net/~vlivanov/8006613/webrev.00/ >>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8006613 From vladimir.kozlov at oracle.com Tue Jan 29 15:45:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Jan 2013 15:45:52 -0800 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: <90BF5755-9BDA-49ED-88ED-392C55A279F1@oracle.com> References: <50FDC6D4.6000703@oracle.com> <90BF5755-9BDA-49ED-88ED-392C55A279F1@oracle.com> Message-ID: <51085F30.6040602@oracle.com> Thank you, Roland This looks good. On 1/29/13 7:48 AM, Roland Westrelin wrote: > Here is a new webrev: > > http://cr.openjdk.java.net/~roland/7197327/webrev.01/ compile.cpp: Could you use err_msg_res() to print req() and name of nodes in next assert?: + assert(n1->req() == n2->req(), "can't compare nodes?"); You have several places where you do next check, can you factor it into a method?: (n->outcnt() != 0 && igvn.type(n) != Type::TOP && !n->in(0)->is_top()) Why in _expensive_nodes loops you start from i=1 and use (i-1) index instead of i=0 and (i+1)? Why cleanup_expensive_nodes() is not using cmp_expensive_nodes()? It will reduce time spent in should_optimize_expensive_nodes() later. May be it should call should_optimize_expensive_nodes() and if it returns 'true' do cleanup using cmp_expensive_nodes(). And if it returns 'false' emptying whole list (and set NULL control). + // control input of nodes for which there's a single copy. ^ only We put declarations on separate lines: + int j = 0, identical = 0, i = 1; cleanup_expensive_nodes() and should_optimize_expensive_nodes() should check _expensive_nodes->length() at the beginning. Add assert to add_expensive_node() to make sure it is not memory or cfg nodes. loopnode.cpp: Could you fix codding style (spaces in if() and for()) in PhaseIdealLoop::get_early_ctrl) since you touch it? We need more info if graph is broken. Could you dump_bad_graph() here: + assert(is_dominator(ctl, earliest) || is_dominator(earliest, ctl), "broken graph?"); Initialize next=ctrl otherwise some compilers may complain. Add checks (ctl->in(1) != NULL && ctl->in(1)->in(0) != NULL) for dead loop when ctl->is_Loop(). Also check that loop is not irreducible, otherwise you can't do this optimization. May be do it only for is_CountedLoop() or when there are not irreducible loops in code. Assign to local var ctl->in(0) and check for NULL. Add comment to the next code (what nodes you expect here? Can you add assert() there to verify that this path is executed only for expected nodes) and fix code style: + int nb_ctl_proj = 0; + for( DUIterator_Fast imax, i = ctl->in(0)->fast_outs(imax); i < imax; i++ ) { + Node *p = ctl->in(0)->fast_out(i); + if( p->is_Proj() && p->is_CFG() ) { + nb_ctl_proj++; + if (nb_ctl_proj > 1) { + break; process_expensive_nodes(): I think for the case (parent_c1 == parent_c2) you should also push n1, n2 on _worklist otherwise they may not be processed by IGVN. > >> What is effect on ref workload? > > I haven't done a refworkload on this latest version but on a previous one, refworkload shown nothing of interests except the improvement on specjvm2008's mpegaudio. I'll redo refworkload before the push. OK. > The 2 tests below cannot work because they don't guarantee that c2 is in the other If branch or that c2 is not on the other branch but inside an imbricated If: You are right. Your code is correct but I would simplify it: if (parent_c1->is_Proj() && parent_c1->in(0)->is_If() && parent_c2->is_Proj() && parent_c1->in(0) == parent_c2->in(0)) { Thanks, Vladimir > >> } else if (c1->is_Proj() && c1->in(0)->is_If() && >> is_dominator(c1->in(0), c2)) { >> c1 = c2 = c1->in(0); >> } else if (c2->is_Proj() && c2->in(0)->is_If() && >> is_dominator(c2->in(0), c1)) { >> c1 = c2 = c2->in(0); >> } >> if (n1->in(0) != c1) { >> n1->set_req(0, c1); >> } >> if (n2->in(0) != c2) { >> n2->set_req(0, c2); >> } > > Roland. > From vladimir.kozlov at oracle.com Tue Jan 29 15:54:18 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Jan 2013 15:54:18 -0800 Subject: RFR(M): 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob In-Reply-To: <51085F30.6040602@oracle.com> References: <50FDC6D4.6000703@oracle.com> <90BF5755-9BDA-49ED-88ED-392C55A279F1@oracle.com> <51085F30.6040602@oracle.com> Message-ID: <5108612A.6070300@oracle.com> I forgot to add that we need a new diagnostic C2 flag for these changes (check it in add_expensive_node()) to be able switch it off. Thanks, Vladimir On 1/29/13 3:45 PM, Vladimir Kozlov wrote: > Thank you, Roland > > This looks good. > > On 1/29/13 7:48 AM, Roland Westrelin wrote: >> Here is a new webrev: >> >> http://cr.openjdk.java.net/~roland/7197327/webrev.01/ > > compile.cpp: > > Could you use err_msg_res() to print req() and name of nodes in next > assert?: > > + assert(n1->req() == n2->req(), "can't compare nodes?"); > > You have several places where you do next check, can you factor it into > a method?: > > (n->outcnt() != 0 && igvn.type(n) != Type::TOP && !n->in(0)->is_top()) > > Why in _expensive_nodes loops you start from i=1 and use (i-1) index > instead of i=0 and (i+1)? > > Why cleanup_expensive_nodes() is not using cmp_expensive_nodes()? It > will reduce time spent in should_optimize_expensive_nodes() later. May > be it should call should_optimize_expensive_nodes() and if it returns > 'true' do cleanup using cmp_expensive_nodes(). And if it returns 'false' > emptying whole list (and set NULL control). > > + // control input of nodes for which there's a single copy. > ^ only > > We put declarations on separate lines: > + int j = 0, identical = 0, i = 1; > > cleanup_expensive_nodes() and should_optimize_expensive_nodes() should > check _expensive_nodes->length() at the beginning. > > Add assert to add_expensive_node() to make sure it is not memory or cfg > nodes. > > loopnode.cpp: > > Could you fix codding style (spaces in if() and for()) in > PhaseIdealLoop::get_early_ctrl) since you touch it? > > We need more info if graph is broken. Could you dump_bad_graph() here: > + assert(is_dominator(ctl, earliest) || is_dominator(earliest, ctl), > "broken graph?"); > > Initialize next=ctrl otherwise some compilers may complain. > Add checks (ctl->in(1) != NULL && ctl->in(1)->in(0) != NULL) for dead > loop when ctl->is_Loop(). Also check that loop is not irreducible, > otherwise you can't do this optimization. May be do it only for > is_CountedLoop() or when there are not irreducible loops in code. > > Assign to local var ctl->in(0) and check for NULL. > > Add comment to the next code (what nodes you expect here? Can you add > assert() there to verify that this path is executed only for expected > nodes) and fix code style: > > + int nb_ctl_proj = 0; > + for( DUIterator_Fast imax, i = ctl->in(0)->fast_outs(imax); i < > imax; i++ ) { > + Node *p = ctl->in(0)->fast_out(i); > + if( p->is_Proj() && p->is_CFG() ) { > + nb_ctl_proj++; > + if (nb_ctl_proj > 1) { > + break; > > > process_expensive_nodes(): > > I think for the case (parent_c1 == parent_c2) you should also push n1, > n2 on _worklist otherwise they may not be processed by IGVN. > >> >>> What is effect on ref workload? >> >> I haven't done a refworkload on this latest version but on a previous >> one, refworkload shown nothing of interests except the improvement on >> specjvm2008's mpegaudio. I'll redo refworkload before the push. > > OK. > >> The 2 tests below cannot work because they don't guarantee that c2 is >> in the other If branch or that c2 is not on the other branch but >> inside an imbricated If: > > You are right. Your code is correct but I would simplify it: > > if (parent_c1->is_Proj() && parent_c1->in(0)->is_If() && > parent_c2->is_Proj() && parent_c1->in(0) == parent_c2->in(0)) { > > Thanks, > Vladimir > >> >>> } else if (c1->is_Proj() && c1->in(0)->is_If() && >>> is_dominator(c1->in(0), c2)) { >>> c1 = c2 = c1->in(0); >>> } else if (c2->is_Proj() && c2->in(0)->is_If() && >>> is_dominator(c2->in(0), c1)) { >>> c1 = c2 = c2->in(0); >>> } >>> if (n1->in(0) != c1) { >>> n1->set_req(0, c1); >>> } >>> if (n2->in(0) != c2) { >>> n2->set_req(0, c2); >>> } >> >> Roland. >> From mikael.gerdin at oracle.com Wed Jan 30 01:48:34 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 30 Jan 2013 10:48:34 +0100 Subject: RFR(M): 8006683: Add WhiteBox API to testing of compiler In-Reply-To: <510831B2.3080307@oracle.com> References: <510831B2.3080307@oracle.com> Message-ID: <5108EC72.3090601@oracle.com> Hi Igor, It's really nice to see more uses of the WhiteBox API! This is exactly the kind of use the API is intended for. On 01/29/2013 09:31 PM, Igor Ignatyev wrote: > Hi all, > > Please review the patch > > 1. added new functions to WhiteBox: > public native void deoptimizeAll(); > public native boolean isMethodCompiled(Method method); > public native boolean isMethodCompilable(Method method); > public native boolean isMethodQueuedForCompilation(Method method); > public native int deoptimizeMethod(Method method); > public native boolean setDontInlineMethod(Method method, boolean value); > public native int getCompileQueuesSize(); The changes to WhiteBox.java, parserTests.hpp, whitebox.hpp look good. The actual calls to the compiler code in whitebox.cpp should be reviewed for correctness by the compiler developers but as for the style of the code I think it's a bit "compact" and lines like: + return ((code != NULL && code->is_alive() && !code->is_marked_for_deoptimization()) ? JNI_TRUE : JNI_FALSE); don't improve readability. Also, is it really necessary to have constructs like: return (value ? JNI_TRUE : JNI_FALSE); can you instead write return (jboolean)value; > > 2. added test 'test/compiler/WBApiTest.java' which exercises these > functions I think the test should be renamed to something like CompilerWhiteBoxTest, to make it clearer that it only uses compiler functions. Could you create a whitebox function to ask the VM for the COMPILE_THRESHOLD instead of having it as a constant in the test? Or perhaps even better, create a utility function for tests that can check the value of a VM flag through the HotSpotDiagnosticMXBean? Then you could dynamically check the value of CompileThreshold without needing to add a redundant whitebox function. Other than that the test looks good to me. > > 3. added result type to macro WB_METHOD_DECLARE Good. > > webrev: http://cr.openjdk.java.net/~vlivanov/8006683/webrev.00/ /Mikael From nils.eliasson at oracle.com Wed Jan 30 07:43:40 2013 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 30 Jan 2013 16:43:40 +0100 Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist iteration In-Reply-To: <51082499.3000905@oracle.com> References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com> Message-ID: <51093FAC.6090803@oracle.com> Thanks for the link, interesting background. Even if finding the largest block on the freelist is free, we would still have a misbehavior when the free heap block is less than 1,5M and the flushing begins to create a 1,5M freelist block. Unallocated memory is a good measurement if have some continuous memory in reserve for critical blobs. I am thinking of using the thresholds against unallocated memory, but forbidding nmethods from using the last 0,5M (MinimumFreeSpace) from the heap block. That would prevent the VM from fragmenting the last continuous memory space, and allow the VM to use all of the freelist. Like this: http://cr.openjdk.java.net/~neliasso/8002364/webrev.03 //Nils Vladimir Kozlov skrev 2013-01-29 20:35: > Nils, > > You are reversing 7025742 fix. I would prefer to keep track of a > largest free block during allocation in CodeCache (by using ordered > list or other technique) to avoid scanning the list. > > Vladimir > > On 1/29/13 2:56 AM, Nils Eliasson wrote: >> Remove continuous free block requirement for code cache flushing and >> minimum free space. >> >> This causes a degenerate behavior when the VM are repeatedly flushing >> the code cache trying to free up a continuous 1,5M block. Since the >> freelist is fragmented a significant part of the code cache is kept >> unallocated. A significant amount of time is spent traversing the >> freelist holding the code cache lock or waiting for other threads doing >> the same. >> >> I don't see any reason for why a continuous block is required. Code >> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is default >> 1,5M and code cache minimum threshold (CodeCacheMinimumFreeSpace) is >> 0,5M. Finding such a block on the freelist is often unrealistic, and has >> not any purpose. The largest nmethods are in the order of 250k, and they >> are not allocated when code cache is starting to run out. All critical >> adapters are small and will fit easily in the freelist or in the >> remaining heap space. >> >> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/ >> >> Thanks, >> Nils Eliasson From vladimir.kozlov at oracle.com Wed Jan 30 11:53:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Jan 2013 11:53:13 -0800 Subject: RFR(M): 8006683: Add WhiteBox API to testing of compiler In-Reply-To: <510831B2.3080307@oracle.com> References: <510831B2.3080307@oracle.com> Message-ID: <51097A29.60905@oracle.com> Igor, I agree with Mikael to give different name to test. Calls to get info in VM looks fine to me. Could you also add call to get compilation level code->comp_level() of compiled code? Do we plan to add more WB tests later as separate *.java tests or we keep only one CompilerWhiteBoxTest.java and update it? Thanks, Vladimir On 1/29/13 12:31 PM, Igor Ignatyev wrote: > Hi all, > > Please review the patch > > 1. added new functions to WhiteBox: > public native void deoptimizeAll(); > public native boolean isMethodCompiled(Method method); > public native boolean isMethodCompilable(Method method); > public native boolean isMethodQueuedForCompilation(Method method); > public native int deoptimizeMethod(Method method); > public native boolean setDontInlineMethod(Method method, boolean value); > public native int getCompileQueuesSize(); > > 2. added test 'test/compiler/WBApiTest.java' which exercises these > functions > > 3. added result type to macro WB_METHOD_DECLARE > > webrev: http://cr.openjdk.java.net/~vlivanov/8006683/webrev.00/ From forax at univ-mlv.fr Wed Jan 30 12:11:21 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 30 Jan 2013 21:11:21 +0100 Subject: RFR(M): 8006683: Add WhiteBox API to testing of compiler In-Reply-To: <51097A29.60905@oracle.com> References: <510831B2.3080307@oracle.com> <51097A29.60905@oracle.com> Message-ID: <51097E69.4060404@univ-mlv.fr> On 01/30/2013 08:53 PM, Vladimir Kozlov wrote: > Igor, > > I agree with Mikael to give different name to test. > > Calls to get info in VM looks fine to me. Could you also add call to > get compilation level code->comp_level() of compiled code? > > Do we plan to add more WB tests later as separate *.java tests or we > keep only one CompilerWhiteBoxTest.java and update it? > > Thanks, > Vladimir Hi all, may I suggest to add several more methods that I would like to have when testing runtimes of languages based on the VM. boolean setForceInlineMethod(Method, boolean) which should be equivalent to put @ForceInline on a method. enqueueMethodForCompilation(Method method) enqueue a method even if threshold is not reached (avoid to have a constant in the test that must be updated when the compile threshold of Hotspot will change) void clearMetaDataObject(Method method) be sure that we are in fresh state before calling a method. (maybe deoptimizeMethod has this side effect ?) cheers, R?mi > > On 1/29/13 12:31 PM, Igor Ignatyev wrote: >> Hi all, >> >> Please review the patch >> >> 1. added new functions to WhiteBox: >> public native void deoptimizeAll(); >> public native boolean isMethodCompiled(Method method); >> public native boolean isMethodCompilable(Method method); >> public native boolean isMethodQueuedForCompilation(Method method); >> public native int deoptimizeMethod(Method method); >> public native boolean setDontInlineMethod(Method method, boolean >> value); >> public native int getCompileQueuesSize(); >> >> 2. added test 'test/compiler/WBApiTest.java' which exercises these >> functions >> >> 3. added result type to macro WB_METHOD_DECLARE >> >> webrev: http://cr.openjdk.java.net/~vlivanov/8006683/webrev.00/ From vladimir.kozlov at oracle.com Wed Jan 30 12:16:38 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Jan 2013 12:16:38 -0800 Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist iteration In-Reply-To: <51093FAC.6090803@oracle.com> References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com> <51093FAC.6090803@oracle.com> Message-ID: <51097FA6.3050709@oracle.com> Nils, you sent webrev for other bug fix. Vladimir On 1/30/13 7:43 AM, Nils Eliasson wrote: > Thanks for the link, interesting background. > > Even if finding the largest block on the freelist is free, we would > still have a misbehavior when the free heap block is less than 1,5M and > the flushing begins to create a 1,5M freelist block. > > Unallocated memory is a good measurement if have some continuous memory > in reserve for critical blobs. I am thinking of using the thresholds > against unallocated memory, but forbidding nmethods from using the last > 0,5M (MinimumFreeSpace) from the heap block. That would prevent the VM > from fragmenting the last continuous memory space, and allow the VM to > use all of the freelist. > > Like this: > http://cr.openjdk.java.net/~neliasso/8002364/webrev.03 > > //Nils > > Vladimir Kozlov skrev 2013-01-29 20:35: >> Nils, >> >> You are reversing 7025742 fix. I would prefer to keep track of a >> largest free block during allocation in CodeCache (by using ordered >> list or other technique) to avoid scanning the list. >> >> Vladimir >> >> On 1/29/13 2:56 AM, Nils Eliasson wrote: >>> Remove continuous free block requirement for code cache flushing and >>> minimum free space. >>> >>> This causes a degenerate behavior when the VM are repeatedly flushing >>> the code cache trying to free up a continuous 1,5M block. Since the >>> freelist is fragmented a significant part of the code cache is kept >>> unallocated. A significant amount of time is spent traversing the >>> freelist holding the code cache lock or waiting for other threads doing >>> the same. >>> >>> I don't see any reason for why a continuous block is required. Code >>> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is default >>> 1,5M and code cache minimum threshold (CodeCacheMinimumFreeSpace) is >>> 0,5M. Finding such a block on the freelist is often unrealistic, and has >>> not any purpose. The largest nmethods are in the order of 250k, and they >>> are not allocated when code cache is starting to run out. All critical >>> adapters are small and will fit easily in the freelist or in the >>> remaining heap space. >>> >>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/ >>> >>> Thanks, >>> Nils Eliasson > From igor.ignatyev at oracle.com Wed Jan 30 15:47:44 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 31 Jan 2013 03:47:44 +0400 Subject: RFR(M): 8006683: Add WhiteBox API to testing of compiler In-Reply-To: <5108EC72.3090601@oracle.com> References: <510831B2.3080307@oracle.com> <5108EC72.3090601@oracle.com> Message-ID: <5109B120.8020009@oracle.com> Hi Mikael, > Also, is it really necessary to have constructs like: > return (value ? JNI_TRUE : JNI_FALSE); This construct was added after I had found it in jni.cpp, unsafe.cpp. I will remove it from my patch. And I think that '(jboolean)value' is unnecessary, too. > I think the test should be renamed to something like > CompilerWhiteBoxTest, to make it clearer that it only uses compiler > functions. ok, I will rename it > create a utility function for tests that can > check the value of a VM flag through the HotSpotDiagnosticMXBean I thought about it, but decided that it might unnecessarily complicate test. Best regards, Igor Ignatyev On 01/30/2013 01:48 PM, Mikael Gerdin wrote: > Hi Igor, > > It's really nice to see more uses of the WhiteBox API! > This is exactly the kind of use the API is intended for. > > On 01/29/2013 09:31 PM, Igor Ignatyev wrote: >> Hi all, >> >> Please review the patch >> >> 1. added new functions to WhiteBox: >> public native void deoptimizeAll(); >> public native boolean isMethodCompiled(Method method); >> public native boolean isMethodCompilable(Method method); >> public native boolean isMethodQueuedForCompilation(Method method); >> public native int deoptimizeMethod(Method method); >> public native boolean setDontInlineMethod(Method method, boolean >> value); >> public native int getCompileQueuesSize(); > > The changes to WhiteBox.java, parserTests.hpp, whitebox.hpp look good. > > The actual calls to the compiler code in whitebox.cpp should be reviewed > for correctness by the compiler developers but as for the style of the > code I think it's a bit "compact" and lines like: > > + return ((code != NULL && code->is_alive() && > !code->is_marked_for_deoptimization()) ? JNI_TRUE : JNI_FALSE); > > don't improve readability. > Also, is it really necessary to have constructs like: > return (value ? JNI_TRUE : JNI_FALSE); > can you instead write > return (jboolean)value; > >> >> 2. added test 'test/compiler/WBApiTest.java' which exercises these >> functions > > I think the test should be renamed to something like > CompilerWhiteBoxTest, to make it clearer that it only uses compiler > functions. > Could you create a whitebox function to ask the VM for the > COMPILE_THRESHOLD instead of having it as a constant in the test? > Or perhaps even better, create a utility function for tests that can > check the value of a VM flag through the HotSpotDiagnosticMXBean? > Then you could dynamically check the value of CompileThreshold without > needing to add a redundant whitebox function. > > Other than that the test looks good to me. > >> >> 3. added result type to macro WB_METHOD_DECLARE > > Good. > >> >> webrev: http://cr.openjdk.java.net/~vlivanov/8006683/webrev.00/ > > /Mikael > From igor.ignatyev at oracle.com Wed Jan 30 16:12:05 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 31 Jan 2013 04:12:05 +0400 Subject: RFR(M): 8006683: Add WhiteBox API to testing of compiler In-Reply-To: <51097A29.60905@oracle.com> References: <510831B2.3080307@oracle.com> <51097A29.60905@oracle.com> Message-ID: <5109B6D5.1030908@oracle.com> Vladimir, thank you for your feedback. > Could you also add call to get > compilation level code->comp_level() of compiled code? Add this is not a problem, but then we will need to have a copy of enum 'CompLevel' in java code. Or you suggest to return int? > Do we plan to add more WB tests later as separate *.java tests or we > keep only one CompilerWhiteBoxTest.java and update it? I think it's better to write tests as separates file, because it will allow not care about state of counters after previous tests. During testing of my changes I have found strange behavior of compiler: C1 continues compilation of method even after reaching of recompilation's limit (PerMethodRecompilationCutoff). For C2 (w/o Tiered) all is correct. Is this behavior correct? Or this is a bug? PS Cause of this behavior is calling of 'Method:: set_not_compilable()' with argument 'CompLevel_full_optimization' from 'MethodData::inc_decompile_count()', so for C1 the method is still compilable. Best regards, Igor Ignatyev On 01/30/2013 11:53 PM, Vladimir Kozlov wrote: > Igor, > > I agree with Mikael to give different name to test. > > Calls to get info in VM looks fine to me. Could you also add call to get > compilation level code->comp_level() of compiled code? > > Do we plan to add more WB tests later as separate *.java tests or we > keep only one CompilerWhiteBoxTest.java and update it? > > Thanks, > Vladimir > > On 1/29/13 12:31 PM, Igor Ignatyev wrote: >> Hi all, >> >> Please review the patch >> >> 1. added new functions to WhiteBox: >> public native void deoptimizeAll(); >> public native boolean isMethodCompiled(Method method); >> public native boolean isMethodCompilable(Method method); >> public native boolean isMethodQueuedForCompilation(Method method); >> public native int deoptimizeMethod(Method method); >> public native boolean setDontInlineMethod(Method method, boolean >> value); >> public native int getCompileQueuesSize(); >> >> 2. added test 'test/compiler/WBApiTest.java' which exercises these >> functions >> >> 3. added result type to macro WB_METHOD_DECLARE >> >> webrev: http://cr.openjdk.java.net/~vlivanov/8006683/webrev.00/ From vladimir.kozlov at oracle.com Wed Jan 30 16:28:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Jan 2013 16:28:01 -0800 Subject: RFR(M): 8006683: Add WhiteBox API to testing of compiler In-Reply-To: <5109B6D5.1030908@oracle.com> References: <510831B2.3080307@oracle.com> <51097A29.60905@oracle.com> <5109B6D5.1030908@oracle.com> Message-ID: <5109BA91.5050904@oracle.com> On 1/30/13 4:12 PM, Igor Ignatyev wrote: > Vladimir, thank you for your feedback. > >> Could you also add call to get >> compilation level code->comp_level() of compiled code? > Add this is not a problem, but then we will need to have a copy of enum > 'CompLevel' in java code. Or you suggest to return int? Just int. And may be not for you current test but in one of next to check that we have expected comp_level (could be difficult with tiered). > >> Do we plan to add more WB tests later as separate *.java tests or we >> keep only one CompilerWhiteBoxTest.java and update it? > I think it's better to write tests as separates file, because it will > allow not care about state of counters after previous tests. Could you then create subdir test/compiler/whitebox for this and future WB tests? > > During testing of my changes I have found strange behavior of compiler: > C1 continues compilation of method even after reaching of > recompilation's limit (PerMethodRecompilationCutoff). For C2 (w/o > Tiered) all is correct. > > Is this behavior correct? Or this is a bug? > > PS Cause of this behavior is calling of 'Method:: set_not_compilable()' > with argument 'CompLevel_full_optimization' from > 'MethodData::inc_decompile_count()', so for C1 the method is still > compilable. File bug. Recently we separated method not-compilable state for C1 and C2, and it is side effect (missed this place). Thanks, Vladimir > > Best regards, > Igor Ignatyev > > On 01/30/2013 11:53 PM, Vladimir Kozlov wrote: >> Igor, >> >> I agree with Mikael to give different name to test. >> >> Calls to get info in VM looks fine to me. Could you also add call to get >> compilation level code->comp_level() of compiled code? >> >> Do we plan to add more WB tests later as separate *.java tests or we >> keep only one CompilerWhiteBoxTest.java and update it? >> >> Thanks, >> Vladimir >> >> On 1/29/13 12:31 PM, Igor Ignatyev wrote: >>> Hi all, >>> >>> Please review the patch >>> >>> 1. added new functions to WhiteBox: >>> public native void deoptimizeAll(); >>> public native boolean isMethodCompiled(Method method); >>> public native boolean isMethodCompilable(Method method); >>> public native boolean isMethodQueuedForCompilation(Method method); >>> public native int deoptimizeMethod(Method method); >>> public native boolean setDontInlineMethod(Method method, boolean >>> value); >>> public native int getCompileQueuesSize(); >>> >>> 2. added test 'test/compiler/WBApiTest.java' which exercises these >>> functions >>> >>> 3. added result type to macro WB_METHOD_DECLARE >>> >>> webrev: http://cr.openjdk.java.net/~vlivanov/8006683/webrev.00/ From roland.westrelin at oracle.com Thu Jan 31 02:49:34 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 31 Jan 2013 11:49:34 +0100 Subject: RFR(S): 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them Message-ID: http://cr.openjdk.java.net/~roland/8007144/webrev.00/ Before incremental inlining inlines a new call site, it sanity checks the input state of the call node: if the call is in a part of the graph that is dead, there's no need to proceed with inlining and, the parser doesn't expect a strange input state anyway. One of the check consists in testing the input edges to the call node (that correspond to input arguments to the call) for top. Long/double arguments to a call are in 2 halves, one of which is top so incremental inlining will skip all calls with at least a long or double argument, mistaken them for dead calls. This bug impacts the performance of the box2d test with nashorn. I also fixed some PrintInlining problems. The PrintInlining output would always report a call site candidate for incremental inlining as "inline (hot)" whether the call site was actually inlined or not which would result in duplicate lines most of the time (one "inline (hot)" and one "live nodes > LiveNodeCountInliningCutoff"). For an incremental inlining call site, I also changed the message to: "incremental inline (hot)". With this fixed there are still some inconsistencies with string calls that are most of the time reported as "inline (hot)" even though inlining is incremental. Roland. From igor.ignatyev at oracle.com Thu Jan 31 04:56:55 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 31 Jan 2013 16:56:55 +0400 Subject: RFR(M): 8006683: Add WhiteBox API to testing of compiler In-Reply-To: <51097E69.4060404@univ-mlv.fr> References: <510831B2.3080307@oracle.com> <51097A29.60905@oracle.com> <51097E69.4060404@univ-mlv.fr> Message-ID: <510A6A17.2080608@oracle.com> R?mi Your suggestions sounds good. I'll file separate RFE for it. Best regards, Igor Ignatyev On 01/31/2013 12:11 AM, Remi Forax wrote: > On 01/30/2013 08:53 PM, Vladimir Kozlov wrote: >> Igor, >> >> I agree with Mikael to give different name to test. >> >> Calls to get info in VM looks fine to me. Could you also add call to >> get compilation level code->comp_level() of compiled code? >> >> Do we plan to add more WB tests later as separate *.java tests or we >> keep only one CompilerWhiteBoxTest.java and update it? >> >> Thanks, >> Vladimir > > Hi all, > may I suggest to add several more methods that I would like to have when > testing runtimes of languages based on the VM. > > boolean setForceInlineMethod(Method, boolean) > which should be equivalent to put @ForceInline on a method. > > enqueueMethodForCompilation(Method method) > enqueue a method even if threshold is not reached > (avoid to have a constant in the test that must be updated when the > compile threshold of Hotspot will change) > > void clearMetaDataObject(Method method) > be sure that we are in fresh state before calling a method. > (maybe deoptimizeMethod has this side effect ?) > > cheers, > R?mi > >> >> On 1/29/13 12:31 PM, Igor Ignatyev wrote: >>> Hi all, >>> >>> Please review the patch >>> >>> 1. added new functions to WhiteBox: >>> public native void deoptimizeAll(); >>> public native boolean isMethodCompiled(Method method); >>> public native boolean isMethodCompilable(Method method); >>> public native boolean isMethodQueuedForCompilation(Method method); >>> public native int deoptimizeMethod(Method method); >>> public native boolean setDontInlineMethod(Method method, boolean >>> value); >>> public native int getCompileQueuesSize(); >>> >>> 2. added test 'test/compiler/WBApiTest.java' which exercises these >>> functions >>> >>> 3. added result type to macro WB_METHOD_DECLARE >>> >>> webrev: http://cr.openjdk.java.net/~vlivanov/8006683/webrev.00/ > From vladimir.kozlov at oracle.com Thu Jan 31 08:58:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Jan 2013 08:58:32 -0800 Subject: RFR(S): 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them In-Reply-To: References: Message-ID: <510AA2B8.5050704@oracle.com> Thank you, Roland, fro finding and fixing this. On 1/31/13 2:49 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8007144/webrev.00/ > > Before incremental inlining inlines a new call site, it sanity checks the input state of the call node: if the call is in a part of the graph that is dead, there's no need to proceed with inlining and, the parser doesn't expect a strange input state anyway. One of the check consists in testing the input edges to the call node (that correspond to input arguments to the call) for top. Long/double arguments to a call are in 2 halves, one of which is top so incremental inlining will skip all calls with at least a long or double argument, mistaken them for dead calls. The fix look fine. > > This bug impacts the performance of the box2d test with nashorn. > > I also fixed some PrintInlining problems. The PrintInlining output would always report a call site candidate for incremental inlining as "inline (hot)" whether the call site was actually inlined or not which would result in duplicate lines most of the time (one "inline (hot)" and one "live nodes > LiveNodeCountInliningCutoff"). For an incremental inlining call site, I also changed the message to: "incremental inline (hot)". With this fixed there are still some inconsistencies with string calls that are most of the time reported as "inline (hot)" even though inlining is incremental. Could you do this as separate fix since it is not complete? Adding needs_printing only to LateInlineString create more mess (why only for laterstring and not for incremental inlining?) which is difficult to follow. We need to think more how to clean up printing for late inlining. And I am fine with next change in the fix: - C->print_inlining_insert(this); + if (PrintInlining) { + print_inlining_late("incremental inline (hot)"); + } Thanks, Vladimir > > Roland. > From roland.westrelin at oracle.com Thu Jan 31 09:18:02 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 31 Jan 2013 18:18:02 +0100 Subject: RFR(S): 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them In-Reply-To: <510AA2B8.5050704@oracle.com> References: <510AA2B8.5050704@oracle.com> Message-ID: Hi Vladimir, Thanks for reviewing this. > Could you do this as separate fix since it is not complete? Adding needs_printing only to LateInlineString create more mess (why only for laterstring and not for incremental inlining?) which is difficult to follow. We need to think more how to clean up printing for late inlining. Sure I can do this as a separate change and I'll try to come up with something better. What should PrintInlining do when the string operations are optimized? Should it print anything? > And I am fine with next change in the fix: > > - C->print_inlining_insert(this); > + if (PrintInlining) { > + print_inlining_late("incremental inline (hot)"); > + } What do you mean? That explicitly stating "incremental" in the message is ok with you? Roland. From forax at univ-mlv.fr Thu Jan 31 09:55:46 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 31 Jan 2013 18:55:46 +0100 Subject: RFR(M): 8006683: Add WhiteBox API to testing of compiler In-Reply-To: <510A6A17.2080608@oracle.com> References: <510831B2.3080307@oracle.com> <51097A29.60905@oracle.com> <51097E69.4060404@univ-mlv.fr> <510A6A17.2080608@oracle.com> Message-ID: <510AB022.2050700@univ-mlv.fr> On 01/31/2013 01:56 PM, Igor Ignatyev wrote: > R?mi > > Your suggestions sounds good. > I'll file separate RFE for it. > > Best regards, > Igor Ignatyev thanks Igor. R?mi > > On 01/31/2013 12:11 AM, Remi Forax wrote: >> On 01/30/2013 08:53 PM, Vladimir Kozlov wrote: >>> Igor, >>> >>> I agree with Mikael to give different name to test. >>> >>> Calls to get info in VM looks fine to me. Could you also add call to >>> get compilation level code->comp_level() of compiled code? >>> >>> Do we plan to add more WB tests later as separate *.java tests or we >>> keep only one CompilerWhiteBoxTest.java and update it? >>> >>> Thanks, >>> Vladimir >> >> Hi all, >> may I suggest to add several more methods that I would like to have when >> testing runtimes of languages based on the VM. >> >> boolean setForceInlineMethod(Method, boolean) >> which should be equivalent to put @ForceInline on a method. >> >> enqueueMethodForCompilation(Method method) >> enqueue a method even if threshold is not reached >> (avoid to have a constant in the test that must be updated when the >> compile threshold of Hotspot will change) >> >> void clearMetaDataObject(Method method) >> be sure that we are in fresh state before calling a method. >> (maybe deoptimizeMethod has this side effect ?) >> >> cheers, >> R?mi >> >>> >>> On 1/29/13 12:31 PM, Igor Ignatyev wrote: >>>> Hi all, >>>> >>>> Please review the patch >>>> >>>> 1. added new functions to WhiteBox: >>>> public native void deoptimizeAll(); >>>> public native boolean isMethodCompiled(Method method); >>>> public native boolean isMethodCompilable(Method method); >>>> public native boolean isMethodQueuedForCompilation(Method method); >>>> public native int deoptimizeMethod(Method method); >>>> public native boolean setDontInlineMethod(Method method, boolean >>>> value); >>>> public native int getCompileQueuesSize(); >>>> >>>> 2. added test 'test/compiler/WBApiTest.java' which exercises these >>>> functions >>>> >>>> 3. added result type to macro WB_METHOD_DECLARE >>>> >>>> webrev: http://cr.openjdk.java.net/~vlivanov/8006683/webrev.00/ >> From vladimir.kozlov at oracle.com Thu Jan 31 10:40:17 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Jan 2013 10:40:17 -0800 Subject: RFR(S): 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them In-Reply-To: References: <510AA2B8.5050704@oracle.com> Message-ID: <510ABA91.6000200@oracle.com> On 1/31/13 9:18 AM, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for reviewing this. > >> Could you do this as separate fix since it is not complete? Adding needs_printing only to LateInlineString create more mess (why only for laterstring and not for incremental inlining?) which is difficult to follow. We need to think more how to clean up printing for late inlining. > > Sure I can do this as a separate change and I'll try to come up with something better. Please, also consolidate output to tty and into LogCompilation so they are consistent. > What should PrintInlining do when the string operations are optimized? Should it print anything? Could you tell what currently happens (what PrintInlining output)? We could mark original calls (StingBuilder, append, toSting) as "stringopt inline". > >> And I am fine with next change in the fix: >> >> - C->print_inlining_insert(this); >> + if (PrintInlining) { >> + print_inlining_late("incremental inline (hot)"); >> + } > > What do you mean? That explicitly stating "incremental" in the message is ok with you? Using "incremental". Calling print_inlining_late will produce duplicated output. Right? Thanks, Vladimir > > Roland. > From nils.eliasson at oracle.com Thu Jan 31 10:40:57 2013 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 31 Jan 2013 19:40:57 +0100 Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist iteration In-Reply-To: <51097FA6.3050709@oracle.com> References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com> <51093FAC.6090803@oracle.com> <51097FA6.3050709@oracle.com> Message-ID: <510ABAB9.8020909@oracle.com> http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/ //N Vladimir Kozlov skrev 2013-01-30 21:16: > Nils, you sent webrev for other bug fix. > > Vladimir > > On 1/30/13 7:43 AM, Nils Eliasson wrote: >> Thanks for the link, interesting background. >> >> Even if finding the largest block on the freelist is free, we would >> still have a misbehavior when the free heap block is less than 1,5M and >> the flushing begins to create a 1,5M freelist block. >> >> Unallocated memory is a good measurement if have some continuous memory >> in reserve for critical blobs. I am thinking of using the thresholds >> against unallocated memory, but forbidding nmethods from using the last >> 0,5M (MinimumFreeSpace) from the heap block. That would prevent the VM >> from fragmenting the last continuous memory space, and allow the VM to >> use all of the freelist. >> >> Like this: >> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03 >> >> //Nils >> >> Vladimir Kozlov skrev 2013-01-29 20:35: >>> Nils, >>> >>> You are reversing 7025742 fix. I would prefer to keep track of a >>> largest free block during allocation in CodeCache (by using ordered >>> list or other technique) to avoid scanning the list. >>> >>> Vladimir >>> >>> On 1/29/13 2:56 AM, Nils Eliasson wrote: >>>> Remove continuous free block requirement for code cache flushing and >>>> minimum free space. >>>> >>>> This causes a degenerate behavior when the VM are repeatedly flushing >>>> the code cache trying to free up a continuous 1,5M block. Since the >>>> freelist is fragmented a significant part of the code cache is kept >>>> unallocated. A significant amount of time is spent traversing the >>>> freelist holding the code cache lock or waiting for other threads >>>> doing >>>> the same. >>>> >>>> I don't see any reason for why a continuous block is required. Code >>>> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is >>>> default >>>> 1,5M and code cache minimum threshold (CodeCacheMinimumFreeSpace) is >>>> 0,5M. Finding such a block on the freelist is often unrealistic, >>>> and has >>>> not any purpose. The largest nmethods are in the order of 250k, and >>>> they >>>> are not allocated when code cache is starting to run out. All critical >>>> adapters are small and will fit easily in the freelist or in the >>>> remaining heap space. >>>> >>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/ >>>> >>>> Thanks, >>>> Nils Eliasson >> From vladimir.kozlov at oracle.com Thu Jan 31 12:57:50 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Jan 2013 12:57:50 -0800 Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist iteration In-Reply-To: <510ABAB9.8020909@oracle.com> References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com> <51093FAC.6090803@oracle.com> <51097FA6.3050709@oracle.com> <510ABAB9.8020909@oracle.com> Message-ID: <510ADACE.1030907@oracle.com> New checks in compileBroker.cpp and in needs_flushing() will never be true if you keep the end of CodeCache for adapters ((size(_free_segments)+ CodeCacheMinimumFreeSpace) > CodeCacheMinimumFreeSpace). As result compilation will not be switched off and we will continue compile but will not able to allocate resulting nmethod. unallocated_heap_capacity() code could be simpler instead of duplicating allocated_capacity() code: return unallocated_capacity() - size(_free_segments); And I would also rename it to unused_capacity(). You missed Compile::init_scratch_buffer_blob() which allocates temp buffer on CodeCache. And all places in output.cpp which allocate/resize buffer for emitting instructions. Note, C2 uses 3 buffers: scratch buffer to calculate instruction size, buffer for code generation and final buffer for resulting nmethod into which we copy generated code from second buffer. Based on your approach all of them should not be critical. On 1/31/13 10:40 AM, Nils Eliasson wrote: > http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/ > > //N > > Vladimir Kozlov skrev 2013-01-30 21:16: >> Nils, you sent webrev for other bug fix. >> >> Vladimir >> >> On 1/30/13 7:43 AM, Nils Eliasson wrote: >>> Thanks for the link, interesting background. >>> >>> Even if finding the largest block on the freelist is free, we would >>> still have a misbehavior when the free heap block is less than 1,5M and >>> the flushing begins to create a 1,5M freelist block. >>> >>> Unallocated memory is a good measurement if have some continuous memory >>> in reserve for critical blobs. I am thinking of using the thresholds >>> against unallocated memory, but forbidding nmethods from using the last >>> 0,5M (MinimumFreeSpace) from the heap block. That would prevent the VM >>> from fragmenting the last continuous memory space, and allow the VM to >>> use all of the freelist. >>> >>> Like this: >>> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03 >>> >>> //Nils >>> >>> Vladimir Kozlov skrev 2013-01-29 20:35: >>>> Nils, >>>> >>>> You are reversing 7025742 fix. I would prefer to keep track of a >>>> largest free block during allocation in CodeCache (by using ordered >>>> list or other technique) to avoid scanning the list. >>>> >>>> Vladimir >>>> >>>> On 1/29/13 2:56 AM, Nils Eliasson wrote: >>>>> Remove continuous free block requirement for code cache flushing and >>>>> minimum free space. >>>>> >>>>> This causes a degenerate behavior when the VM are repeatedly flushing >>>>> the code cache trying to free up a continuous 1,5M block. Since the >>>>> freelist is fragmented a significant part of the code cache is kept >>>>> unallocated. A significant amount of time is spent traversing the >>>>> freelist holding the code cache lock or waiting for other threads >>>>> doing >>>>> the same. >>>>> >>>>> I don't see any reason for why a continuous block is required. Code >>>>> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is >>>>> default >>>>> 1,5M and code cache minimum threshold (CodeCacheMinimumFreeSpace) is >>>>> 0,5M. Finding such a block on the freelist is often unrealistic, >>>>> and has >>>>> not any purpose. The largest nmethods are in the order of 250k, and >>>>> they >>>>> are not allocated when code cache is starting to run out. All critical >>>>> adapters are small and will fit easily in the freelist or in the >>>>> remaining heap space. >>>>> >>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/ >>>>> >>>>> Thanks, >>>>> Nils Eliasson >>> >