From tobias.hartmann at oracle.com Mon Feb 1 11:32:56 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 1 Feb 2016 12:32:56 +0100 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: References: <56AB7436.7020302@oracle.com> <56ABC001.6080302@oracle.com> Message-ID: <56AF4268.4080704@oracle.com> Thanks Vladimir and Michael, for the reviews. Michael wrote (off-thread): > Tobias, I might take the restore code a different direction. Would it be ok if I handed you code back which has an offset based approach that makes the direction of restores no longer dependent upon the current stack? I will wait for his changes and then send out a new RFR. Best, Tobias On 29.01.2016 23:28, Berg, Michael C wrote: > Tobias/Vladimir: > > I would change the two asserts to in the 64bit code to make the check clear: > > assert(UseAVX > 0, "up to 512bit vectors are supported with EVEX"); > assert(MaxVectorSize <= 64, "up to 512bit vectors are supported now"); > > As for testing with the patch applied to hotspot on a current jdk(01-29-16): > > Windows sde 32-bit: skx - pass, also ran and passed part of specjvm2008 > Windows 32-bit: hsw - pass, also ran and passed all of specjvm2008 > Windows sde 64-bit: skx - pass, also ran and passed part of specjvm2008 > Windows 64-bit: hsw -pass, also ran and passed all of specjvm2008 : caveat > Linux on skx: 32-bit - pass, also ran and passed all of specjvm2008 > Linux on skx:64-bit - pass, also ran and passed all of specjvm2008 > > We should proceed with checkin in the changelist after the usual testing. > > Note: The above tests were done with the asserts changed on windows only. The 64bit changes are mostly cosmetic. It's the change to the additional_frame_bytes that makes it correct, we used > equivalent constants in the stack adjustment beforehand, they had not been mapped to the movdqu for the non-vector case for a few iterations on the file. Early on I did have that code though. > > Caveat: xml.transform fails with the changelist and without, I checked this against a 12-21-15 built jdk which is 1 month old, so we have a new bug that is causing this app to fail as well (on windows for 64bit) on hsw. > I checked recent jbs traffic, the occurrence does not appear to be tracked at this time. > > -Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, January 29, 2016 11:40 AM > To: hotspot-compiler-dev at openjdk.java.net > Cc: Berg, Michael C > Subject: Re: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit > > Tobias, please verify that 64-bit code works correctly. > About 32-bit code. > > Please verify correctness of next asserts: > > assert(UseAVX > 0, "512bit vectors are supported only with EVEX"); > assert(MaxVectorSize == 64, "only 512bit vectors are supported now"); > > Originally we could have vectors even with only 64bit XMM registers. MaxVectorSize and UseAVX can be set on command line > - what happens in such case? No vectorization? > > May be it is done because we save whole 128bit XMM always. Still MaxVectorSize == 64 condition is strange. > > Thanks, > Vladimir > > On 1/29/16 6:16 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8148490 >> http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ >> >> RegisterSaver::save_live_registers() and RegisterSaver::restore_live_registers() are used by the safepoint handling code to save and restore registers. The following code is emitted to save and restore XMM/YMM registers on 32 bit: >> >> Save: >> ... >> 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) >> 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) >> ... >> 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) >> 0xf34ca176: sub $0x80,%esp >> 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) >> 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) >> ... >> 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) >> ... >> >> Restore: >> ... >> 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 >> 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 >> ... >> 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 >> 0xf34ca241: add $0x80,%esp >> 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 >> 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 >> ... >> 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 >> ... >> >> The stack offsets for the vmovdqu instructions are wrong, causing the XMM registers to contain random values after a safepoint. The problem is that "additional_frame_bytes" is added to the stack offset although the stack pointer is incremented just before: >> >> 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM registers >> >> The regression test fails with "Test failed: array[0] = 1973.0 but should be 10.000" because the vectorized loop returns a wrong result. >> >> I spotted and fixed the following other problems: >> - the vmovdqu instructions should be emitted before restoring YMM and ZMM because they zero the upper part of the XMM registers (i.e. YMM/ZMM) >> - if 'UseAVX > 2' is set/available, we save the ZMM registers as well but we do not increment 'additional_frame_words' accordingly (we need another 8*32 bytes of stack space) >> >> Unfortunately, I don't have access to a CPU with the AVX-512 instruction set to test the "UseAVX > 2" related changes. Michael, could you verify the changes? >> >> The problems were introduced by the fix for JDK-8142980. >> >> Thanks, >> Tobias >> From tobias.hartmann at oracle.com Mon Feb 1 11:34:55 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 1 Feb 2016 12:34:55 +0100 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: <56AF4268.4080704@oracle.com> References: <56AB7436.7020302@oracle.com> <56ABC001.6080302@oracle.com> <56AF4268.4080704@oracle.com> Message-ID: <56AF42DF.7040907@oracle.com> On 01.02.2016 12:32, Tobias Hartmann wrote: > Thanks Vladimir and Michael, for the reviews. > > Michael wrote (off-thread): >> Tobias, I might take the restore code a different direction. Would it be ok if I handed you code back which has an offset based approach that makes the direction of restores no longer dependent upon the current stack? > > I will wait for his changes and then send out a new RFR. I meant to say that I will send out a new webrev, including Michael's changes. Best, Tobias > Best, > Tobias > > On 29.01.2016 23:28, Berg, Michael C wrote: >> Tobias/Vladimir: >> >> I would change the two asserts to in the 64bit code to make the check clear: >> >> assert(UseAVX > 0, "up to 512bit vectors are supported with EVEX"); >> assert(MaxVectorSize <= 64, "up to 512bit vectors are supported now"); >> >> As for testing with the patch applied to hotspot on a current jdk(01-29-16): >> >> Windows sde 32-bit: skx - pass, also ran and passed part of specjvm2008 >> Windows 32-bit: hsw - pass, also ran and passed all of specjvm2008 >> Windows sde 64-bit: skx - pass, also ran and passed part of specjvm2008 >> Windows 64-bit: hsw -pass, also ran and passed all of specjvm2008 : caveat >> Linux on skx: 32-bit - pass, also ran and passed all of specjvm2008 >> Linux on skx:64-bit - pass, also ran and passed all of specjvm2008 >> >> We should proceed with checkin in the changelist after the usual testing. >> >> Note: The above tests were done with the asserts changed on windows only. The 64bit changes are mostly cosmetic. It's the change to the additional_frame_bytes that makes it correct, we used >> equivalent constants in the stack adjustment beforehand, they had not been mapped to the movdqu for the non-vector case for a few iterations on the file. Early on I did have that code though. >> >> Caveat: xml.transform fails with the changelist and without, I checked this against a 12-21-15 built jdk which is 1 month old, so we have a new bug that is causing this app to fail as well (on windows for 64bit) on hsw. >> I checked recent jbs traffic, the occurrence does not appear to be tracked at this time. >> >> -Michael >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Friday, January 29, 2016 11:40 AM >> To: hotspot-compiler-dev at openjdk.java.net >> Cc: Berg, Michael C >> Subject: Re: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit >> >> Tobias, please verify that 64-bit code works correctly. >> About 32-bit code. >> >> Please verify correctness of next asserts: >> >> assert(UseAVX > 0, "512bit vectors are supported only with EVEX"); >> assert(MaxVectorSize == 64, "only 512bit vectors are supported now"); >> >> Originally we could have vectors even with only 64bit XMM registers. MaxVectorSize and UseAVX can be set on command line >> - what happens in such case? No vectorization? >> >> May be it is done because we save whole 128bit XMM always. Still MaxVectorSize == 64 condition is strange. >> >> Thanks, >> Vladimir >> >> On 1/29/16 6:16 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8148490 >>> http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ >>> >>> RegisterSaver::save_live_registers() and RegisterSaver::restore_live_registers() are used by the safepoint handling code to save and restore registers. The following code is emitted to save and restore XMM/YMM registers on 32 bit: >>> >>> Save: >>> ... >>> 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) >>> 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) >>> ... >>> 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) >>> 0xf34ca176: sub $0x80,%esp >>> 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) >>> 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) >>> ... >>> 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) >>> ... >>> >>> Restore: >>> ... >>> 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 >>> 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 >>> ... >>> 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 >>> 0xf34ca241: add $0x80,%esp >>> 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 >>> 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 >>> ... >>> 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 >>> ... >>> >>> The stack offsets for the vmovdqu instructions are wrong, causing the XMM registers to contain random values after a safepoint. The problem is that "additional_frame_bytes" is added to the stack offset although the stack pointer is incremented just before: >>> >>> 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM registers >>> >>> The regression test fails with "Test failed: array[0] = 1973.0 but should be 10.000" because the vectorized loop returns a wrong result. >>> >>> I spotted and fixed the following other problems: >>> - the vmovdqu instructions should be emitted before restoring YMM and ZMM because they zero the upper part of the XMM registers (i.e. YMM/ZMM) >>> - if 'UseAVX > 2' is set/available, we save the ZMM registers as well but we do not increment 'additional_frame_words' accordingly (we need another 8*32 bytes of stack space) >>> >>> Unfortunately, I don't have access to a CPU with the AVX-512 instruction set to test the "UseAVX > 2" related changes. Michael, could you verify the changes? >>> >>> The problems were introduced by the fix for JDK-8142980. >>> >>> Thanks, >>> Tobias >>> From zoltan.majo at oracle.com Mon Feb 1 15:14:13 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 1 Feb 2016 16:14:13 +0100 Subject: [9] RFR (S): 8148753: Compilation fails due to field accesses on array types Message-ID: <56AF7645.4050409@oracle.com> Hi, please review the patch for 8148753. https://bugs.openjdk.java.net/browse/JDK-8148753 Problem: Compiling methods that access fields of array types fails. The problem is that both compilers assume that only fields of instance types (but not field of array types) can be accessed. However, an array can be also seen as an instance type, as every array is a subclass of java.lang.Object. Solution: Treat accesses to fields of array types as accesses to fields of java.lang.Object. By convention, the java.lang.Object does not have any fields. As a result, the generated code will throw a java.lang.NoSuchFieldError exception (the expected behavior in this case). Webrev: http://cr.openjdk.java.net/~zmajo/8148753/webrev.00/ Testing: - JPRT; - all JTREG hotspot/compiler tests on all supported platforms. Thank you and best regards, Zoltan From ivan at azulsystems.com Mon Feb 1 16:21:07 2016 From: ivan at azulsystems.com (Ivan Krylov) Date: Mon, 1 Feb 2016 19:21:07 +0300 Subject: RFR(S): 8147844: new method j.l.Runtime.onSpinWait() and the corresponding x86 hotspot instrinsic In-Reply-To: <50C14C66-4068-4DD7-BD94-96E37F7C9B0A@oracle.com> References: <56A751AE.9090203@azulsystems.com> <45B4730C-CCC2-4523-ACD1-D18B20E5EC5F@oracle.com> <56A8BC9D.8060004@azulsystems.com> <6148E4D7-AF5E-4094-B363-52E0D83452E9@oracle.com> <56AA2AE4.2090803@azulsystems.com> <2538083C-7906-44AA-A074-7DBF5F2D8654@oracle.com> <50C14C66-4068-4DD7-BD94-96E37F7C9B0A@oracle.com> Message-ID: <56AF85F3.3060802@azulsystems.com> I am afraid I am still confused. > As Vladimir suggested, it?s better to check Matcher::match_rule_supported() in c2compiler.cpp in is_intrinsic_supported(). The -XX:DisableIntrinsic flags comes with the built in mechanism of verification, right? The call_generator() calls findIntrinsic with it's lazy initialization and a check against the exclusion list. Seems to work fine with my little test, but I am fine with conforming to whatever is a custom here, I am still new to c2 code. (gdb) p token $1 = 0x7ffff0276680 "_onSpinWait" (gdb) bt #0 DirectiveSet::is_intrinsic_disabled (this=0x7ffff019b2e0, method=...) at /mnt/hgfs/Macbook/Users/ivan/openjdk9_onspinwait/hotspot/src/share/vm/compiler/compilerDirectives.cpp:400 #1 0x00007ffff655f6fd in Compile::make_vm_intrinsic (this=0x7fff923b2ba0, m=0x7fff740336b0, is_virtual=false) at /mnt/hgfs/Macbook/Users/ivan/openjdk9_onspinwait/hotspot/src/share/vm/opto/library_call.cpp:341 #2 0x00007ffff60917d1 in Compile::find_intrinsic (this=0x7fff923b2ba0, m=0x7fff740336b0, is_virtual=false) at /mnt/hgfs/Macbook/Users/ivan/openjdk9_onspinwait/hotspot/src/share/vm/opto/compile.cpp:164 #3 0x00007ffff6206c06 in Compile::call_generator (this=0x7fff923b2ba0, callee=0x7fff740336b0, vtable_index=-4, call_does_dispatch=false, jvms=0x7fff740565e0, allow_inline=true, prof_factor=1, speculative_receiver_type=0x0, allow_intrinsics=true, delayed_forbidden=false) at /mnt/hgfs/Macbook/Users/ivan/openjdk9_onspinwait/hotspot/src/share/vm/opto/doCall.cpp:120 #4 0x00007ffff6208506 in Parse::do_call (this=0x7fff923b1500) at /mnt/hgfs/Macbook/Users/ivan/openjdk9_onspinwait/hotspot/src/share/vm/opto/doCall.cpp:499 #5 0x00007ffff676e305 in Parse::do_one_bytecode (this=0x7fff923b1500) > we don?t support CPUs with SSE < 2 We as openjdk or the commercial jdk? But doesn't matter at the end as the pause instruction is harmless even for prior-to-SSE2 CPUs. >Is there any reason this can?t be moved to generic x86.ad I will adopt this. To Vladimir's points: > Why you check intrinsic in inline_native_Class_query() ? My improper following the code of other intrinsics. Will fix that. > (Various test suggestions) I will adopt those > I think you should consider to implement this for C1 and Interpreter since Tiered Compilation is on by default. I can see C1 benefiting from this but (although never implemented or measured) but how the Interpreter can possibly benefit in any measurable way? Thanks, Ivan On 29/01/2016 04:48, Igor Veresov wrote: >> On Jan 28, 2016, at 12:41 PM, Igor Veresov wrote: >> >> x86.ad: >> f >> It seems that the comment here is off: >> 1714 case Op_OnSpinWait: >> 1715 if (UseSSE < 2) // requires at least SSE4 >> 1716 ret_value = false; >> 1717 break; >> >> Also we don?t support CPUs with SSE < 2, so you don?t have to make these changes to x86.ad. It?s enough that has_match_rule(), that is called by Matcher::match_rule_supported(), will return true for Op_OnSpinWait. >> >> >> x86_64.ad: >> +instruct onspinwait() >> +%{ >> + match(OnSpinWait); >> + ins_cost(200); >> ... >> >> Is there any reason this can?t be moved to generic x86.ad ? It can be easily supported on 32bit as well, right (we do still support 32bit mode on linux)? The encoding is the same for both 32 and 64 bit modes, so that should be trivial. >> >> library_call.cpp: >> >> I think you forgot to actually call Matcher::match_rule_supported(). I think it should be something like: >> >> bool LibraryCallKit::inline_onspinwait() { >> if (Matcher::match_rule_supported(Op_OnSpinWait) { >> insert_mem_bar(Op_OnSpinWait); >> return true; >> } >> return false; >> } >> > As Vladimir suggested, it?s better to check Matcher::match_rule_supported() in c2compiler.cpp in is_intrinsic_supported(). Sorry about the confusion. I stand by the other comments though. > > igor > >> igor >> >>> On Jan 28, 2016, at 6:51 AM, Ivan Krylov wrote: >>> >>> Hi Igor, >>> >>> Following Vladimir's suggestion I eliminated the UseOnSpinWaitIntrinsic flag altogether. I have adopted the Matcher::match_rule_supported() logic - seems to work on intel, but I don't have any non-intel box to test. >>> >>> Anyway, the new webrev: >>> http://cr.openjdk.java.net/~ikrylov/8147844.hs.01/ >>> >>> Igor, Vladimir, thanks, >>> >>> Ivan >>> >>> On 27/01/2016 22:03, Igor Veresov wrote: >>>> Actually, I?d rather use Matcher::match_rule_supported() to test if it?s supported on the platform, rather than fixing all vm_version_*.* to check for the flag validity, that?s tedious (you forgot x86-32 and there?s going to be more platforms to fix for you sponsor). Something like UseOnSpinWaitIntrinsic && Matcher::match_rule_supported(Op_OnSpinWait) to decide whether or not to inline the intrinsic. Also, why are you not turning it on by default? >>>> >>>> igor >>>> >>>>> On Jan 27, 2016, at 4:48 AM, Ivan Krylov wrote: >>>>> >>>>> Looks like there was some good discussion while I was peacefully sleeping. >>>>> I don't have much to add. This patch was somewhat inspired by JEP-171 changes. >>>>> Perhaps,there are other ways to achieve the same semantics. >>>>> >>>>> So, if we can consider this reviewed - I will wait for the actual JEP to become targeted to 9 and then seek a sponsor to do the push. >>>>> >>>>> Thanks, >>>>> >>>>> Ivan >>>>> >>>>> On 27/01/2016 09:12, Igor Veresov wrote: >>>>>> I realize it?s not a big deal. I was just wondering if there was any specific reason control alone is not enough. >>>>>> Anyways, looks ok for the first cut. >>>>>> >>>>>> igor >>>>>> >>>>>>> On Jan 26, 2016, at 9:24 PM, Gil Tene wrote: >>>>>>> >>>>>>> Since a sensical loop that calls onSpinWait() would include at least a volatile load on every iteration (and possibly a volatile store), the new node does not create significant extra move restrictions that are not already there. Modeling this with a memory effect is one simple way to prevent it from being re-ordered out of the loop. There are probably other ways to achieve this, but this one doesn't really have a performance downside? >>>>>>> >>>>>>> ? Gil. >>>>>>> >>>>>>>> On Jan 26, 2016, at 4:44 PM, Igor Veresov wrote: >>>>>>>> >>>>>>>> So, why does the new node have a memory effect? That would seem to prevent any movement of the subsequent loads in your loop, right? If that?s intentional I wonder why is that? >>>>>>>> >>>>>>>> igor >>>>>>>> >>>>>>>>> On Jan 26, 2016, at 2:59 AM, Ivan Krylov wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Some of you may have a seen a few e-mails on the core-libs alias about a proposed ?spin wait hint?. The JEP is forming up nicely at https://bugs.openjdk.java.net/browse/JDK-8147832. There seems to be a consensus on the API side. It is now in a draft state and I hope this JEP will get targeted for java 9 shortly. The upcoming API changes can be seen at the webrev: >>>>>>>>> http://cr.openjdk.java.net/~ikrylov/8147844.jdk.00/ >>>>>>>>> >>>>>>>>> At this time I would like to ask for a review of the hs-comp changes. The plan is push changes into class libraries and hotspot synchronously but that may happen after the JEP gets targeted. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147844 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~ikrylov/8147844.hs.00/ >>>>>>>>> >>>>>>>>> The idea of the fix is pretty simple: hotspot replaces a call to java.lang.Runtime.onSpinWait() with an intrinsic that is effectively a 'pause' instruction on x86. This intrinsic is guarded by the -XX:?UseOnSpinWaitIntrinsic flag. For non-x86 platforms there is a verification code that makes sure the flag is off, VM will just execute at empty method java.lang.Runtime.onSpinWait() ? effectively a no-op. According the [1] the 'pause' instruction is functional since SSE2, but even on CPUs prior to SSE2 the 'pause' instruction is a no-op and hence harmless, there seems to be no need to add guarding code for older generations of Intel CPUs. >>>>>>>>> >>>>>>>>> The proposed patch includes a simple regression test that simply makes sure that method java.lang.Runtime.onSpinWait() gets intrinsified. There are several other producer-consumer-like performance tests ready that the authors of this JEP would be happy to make available under JEP-230 but I am uncertain about the process. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> [1] - https://software.intel.com/en-us/articles/benefitting-power-and-performance-sleep-loops From roland.westrelin at oracle.com Mon Feb 1 17:05:10 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 1 Feb 2016 18:05:10 +0100 Subject: RFR(S): 8147645: get_ctrl_no_update() code is wrong In-Reply-To: <56A92027.2070602@oracle.com> References: <77A6696F-8F4B-4023-AE58-61E2D01A8035@oracle.com> <56A92027.2070602@oracle.com> Message-ID: <73669E03-B560-4B00-9195-C4D03E420AA7@oracle.com> Thanks for the review, Vladimir. Roland. From vladimir.kozlov at oracle.com Mon Feb 1 17:43:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 1 Feb 2016 09:43:20 -0800 Subject: [9] RFR (S): 8148753: Compilation fails due to field accesses on array types In-Reply-To: <56AF7645.4050409@oracle.com> References: <56AF7645.4050409@oracle.com> Message-ID: <56AF9938.1020403@oracle.com> Extend comment: + // handling in ciField::will_link. "and throw a java.lang.NoSuchFieldError exception (the expected behavior in this case)." Give different name to first local 'declared_holder' and after array type check do cast: ciInstanceKlass* declared_holder = holder->as_instance_klass(); then you don't need to change following code. Thanks, Vladimir On 2/1/16 7:14 AM, Zolt?n Maj? wrote: > Hi, > > > please review the patch for 8148753. > > https://bugs.openjdk.java.net/browse/JDK-8148753 > > Problem: Compiling methods that access fields of array types fails. The > problem is that both compilers assume that only fields of instance types > (but not field of array types) can be accessed. However, an array can be > also seen as an instance type, as every array is a subclass of > java.lang.Object. > > Solution: Treat accesses to fields of array types as accesses to fields > of java.lang.Object. By convention, the java.lang.Object does not have > any fields. As a result, the generated code will throw a > java.lang.NoSuchFieldError exception (the expected behavior in this case). > > Webrev: > http://cr.openjdk.java.net/~zmajo/8148753/webrev.00/ > > Testing: > - JPRT; > - all JTREG hotspot/compiler tests on all supported platforms. > > Thank you and best regards, > > > Zoltan > From michael.c.berg at intel.com Mon Feb 1 18:50:29 2016 From: michael.c.berg at intel.com (Berg, Michael C) Date: Mon, 1 Feb 2016 18:50:29 +0000 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: <56AF4268.4080704@oracle.com> References: <56AB7436.7020302@oracle.com> <56ABC001.6080302@oracle.com> <56AF4268.4080704@oracle.com> Message-ID: Tobias, since it works everywhere now, let us proceed. The code is ok in its current form. Thanks, Michael -----Original Message----- From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] Sent: Monday, February 01, 2016 3:33 AM To: Berg, Michael C; Vladimir Kozlov Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit Thanks Vladimir and Michael, for the reviews. Michael wrote (off-thread): > Tobias, I might take the restore code a different direction. Would it be ok if I handed you code back which has an offset based approach that makes the direction of restores no longer dependent upon the current stack? I will wait for his changes and then send out a new RFR. Best, Tobias On 29.01.2016 23:28, Berg, Michael C wrote: > Tobias/Vladimir: > > I would change the two asserts to in the 64bit code to make the check clear: > > assert(UseAVX > 0, "up to 512bit vectors are supported with EVEX"); > assert(MaxVectorSize <= 64, "up to 512bit vectors are supported > now"); > > As for testing with the patch applied to hotspot on a current jdk(01-29-16): > > Windows sde 32-bit: skx - pass, also ran and passed part of > specjvm2008 Windows 32-bit: hsw - pass, also ran and passed all of > specjvm2008 Windows sde 64-bit: skx - pass, also ran and passed part > of specjvm2008 Windows 64-bit: hsw -pass, also ran and passed all of > specjvm2008 : caveat Linux on skx: 32-bit - pass, also ran and passed > all of specjvm2008 Linux on skx:64-bit - pass, also ran and passed all > of specjvm2008 > > We should proceed with checkin in the changelist after the usual testing. > > Note: The above tests were done with the asserts changed on windows > only. The 64bit changes are mostly cosmetic. It's the change to the additional_frame_bytes that makes it correct, we used equivalent constants in the stack adjustment beforehand, they had not been mapped to the movdqu for the non-vector case for a few iterations on the file. Early on I did have that code though. > > Caveat: xml.transform fails with the changelist and without, I checked this against a 12-21-15 built jdk which is 1 month old, so we have a new bug that is causing this app to fail as well (on windows for 64bit) on hsw. > I checked recent jbs traffic, the occurrence does not appear to be tracked at this time. > > -Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, January 29, 2016 11:40 AM > To: hotspot-compiler-dev at openjdk.java.net > Cc: Berg, Michael C > Subject: Re: [9] RFR(S): 8148490: > RegisterSaver::restore_live_registers() fails to restore xmm registers > on 32 bit > > Tobias, please verify that 64-bit code works correctly. > About 32-bit code. > > Please verify correctness of next asserts: > > assert(UseAVX > 0, "512bit vectors are supported only with EVEX"); > assert(MaxVectorSize == 64, "only 512bit vectors are supported > now"); > > Originally we could have vectors even with only 64bit XMM registers. > MaxVectorSize and UseAVX can be set on command line > - what happens in such case? No vectorization? > > May be it is done because we save whole 128bit XMM always. Still MaxVectorSize == 64 condition is strange. > > Thanks, > Vladimir > > On 1/29/16 6:16 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8148490 >> http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ >> >> RegisterSaver::save_live_registers() and RegisterSaver::restore_live_registers() are used by the safepoint handling code to save and restore registers. The following code is emitted to save and restore XMM/YMM registers on 32 bit: >> >> Save: >> ... >> 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) >> 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) >> ... >> 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) >> 0xf34ca176: sub $0x80,%esp >> 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) >> 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) >> ... >> 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) >> ... >> >> Restore: >> ... >> 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 >> 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 >> ... >> 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 >> 0xf34ca241: add $0x80,%esp >> 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 >> 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 >> ... >> 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 >> ... >> >> The stack offsets for the vmovdqu instructions are wrong, causing the XMM registers to contain random values after a safepoint. The problem is that "additional_frame_bytes" is added to the stack offset although the stack pointer is incremented just before: >> >> 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM registers >> >> The regression test fails with "Test failed: array[0] = 1973.0 but should be 10.000" because the vectorized loop returns a wrong result. >> >> I spotted and fixed the following other problems: >> - the vmovdqu instructions should be emitted before restoring YMM and >> ZMM because they zero the upper part of the XMM registers (i.e. >> YMM/ZMM) >> - if 'UseAVX > 2' is set/available, we save the ZMM registers as well >> but we do not increment 'additional_frame_words' accordingly (we need >> another 8*32 bytes of stack space) >> >> Unfortunately, I don't have access to a CPU with the AVX-512 instruction set to test the "UseAVX > 2" related changes. Michael, could you verify the changes? >> >> The problems were introduced by the fix for JDK-8142980. >> >> Thanks, >> Tobias >> From michael.c.berg at intel.com Mon Feb 1 19:25:16 2016 From: michael.c.berg at intel.com (Berg, Michael C) Date: Mon, 1 Feb 2016 19:25:16 +0000 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: <56AC142E.6010309@oracle.com> References: <56AB7436.7020302@oracle.com> <56ABC001.6080302@oracle.com> <56AC142E.6010309@oracle.com> Message-ID: The new jbs entry is logged as: https://bugs.openjdk.java.net/browse/JDK-8148786 (for the xml.transform failure) Regards, Michael -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, January 29, 2016 5:39 PM To: Berg, Michael C; Tobias Hartmann Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit Michael, Thank you for testing changes. Please, file JBS bug for xml.transform problem. Thanks, Vladimir On 1/29/16 2:28 PM, Berg, Michael C wrote: > Tobias/Vladimir: > > I would change the two asserts to in the 64bit code to make the check clear: > > assert(UseAVX > 0, "up to 512bit vectors are supported with EVEX"); > assert(MaxVectorSize <= 64, "up to 512bit vectors are supported > now"); > > As for testing with the patch applied to hotspot on a current jdk(01-29-16): > > Windows sde 32-bit: skx - pass, also ran and passed part of > specjvm2008 Windows 32-bit: hsw - pass, also ran and passed all of > specjvm2008 Windows sde 64-bit: skx - pass, also ran and passed part > of specjvm2008 Windows 64-bit: hsw -pass, also ran and passed all of > specjvm2008 : caveat Linux on skx: 32-bit - pass, also ran and passed > all of specjvm2008 Linux on skx:64-bit - pass, also ran and passed all > of specjvm2008 > > We should proceed with checkin in the changelist after the usual testing. > > Note: The above tests were done with the asserts changed on windows > only. The 64bit changes are mostly cosmetic. It's the change to the additional_frame_bytes that makes it correct, we used equivalent constants in the stack adjustment beforehand, they had not been mapped to the movdqu for the non-vector case for a few iterations on the file. Early on I did have that code though. > > Caveat: xml.transform fails with the changelist and without, I checked this against a 12-21-15 built jdk which is 1 month old, so we have a new bug that is causing this app to fail as well (on windows for 64bit) on hsw. > I checked recent jbs traffic, the occurrence does not appear to be tracked at this time. > > -Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, January 29, 2016 11:40 AM > To: hotspot-compiler-dev at openjdk.java.net > Cc: Berg, Michael C > Subject: Re: [9] RFR(S): 8148490: > RegisterSaver::restore_live_registers() fails to restore xmm registers > on 32 bit > > Tobias, please verify that 64-bit code works correctly. > About 32-bit code. > > Please verify correctness of next asserts: > > assert(UseAVX > 0, "512bit vectors are supported only with EVEX"); > assert(MaxVectorSize == 64, "only 512bit vectors are supported > now"); > > Originally we could have vectors even with only 64bit XMM registers. > MaxVectorSize and UseAVX can be set on command line > - what happens in such case? No vectorization? > > May be it is done because we save whole 128bit XMM always. Still MaxVectorSize == 64 condition is strange. > > Thanks, > Vladimir > > On 1/29/16 6:16 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8148490 >> http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ >> >> RegisterSaver::save_live_registers() and RegisterSaver::restore_live_registers() are used by the safepoint handling code to save and restore registers. The following code is emitted to save and restore XMM/YMM registers on 32 bit: >> >> Save: >> ... >> 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) >> 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) >> ... >> 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) >> 0xf34ca176: sub $0x80,%esp >> 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) >> 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) >> ... >> 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) >> ... >> >> Restore: >> ... >> 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 >> 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 >> ... >> 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 >> 0xf34ca241: add $0x80,%esp >> 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 >> 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 >> ... >> 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 >> ... >> >> The stack offsets for the vmovdqu instructions are wrong, causing the XMM registers to contain random values after a safepoint. The problem is that "additional_frame_bytes" is added to the stack offset although the stack pointer is incremented just before: >> >> 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM registers >> >> The regression test fails with "Test failed: array[0] = 1973.0 but should be 10.000" because the vectorized loop returns a wrong result. >> >> I spotted and fixed the following other problems: >> - the vmovdqu instructions should be emitted before restoring YMM and >> ZMM because they zero the upper part of the XMM registers (i.e. >> YMM/ZMM) >> - if 'UseAVX > 2' is set/available, we save the ZMM registers as well >> but we do not increment 'additional_frame_words' accordingly (we need >> another 8*32 bytes of stack space) >> >> Unfortunately, I don't have access to a CPU with the AVX-512 instruction set to test the "UseAVX > 2" related changes. Michael, could you verify the changes? >> >> The problems were introduced by the fix for JDK-8142980. >> >> Thanks, >> Tobias >> From dean.long at oracle.com Mon Feb 1 19:54:20 2016 From: dean.long at oracle.com (Dean Long) Date: Mon, 1 Feb 2016 11:54:20 -0800 Subject: RFR(XS): 8143897 :Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same In-Reply-To: <56AC47CD.4040700@oracle.com> References: <56AA3ED7.4030407@oracle.com> <56AAE63A.4060905@oracle.com> <56AB0868.2080307@oracle.com> <56ABBB34.80002@oracle.com> <56AC374C.9050800@oracle.com> <56AC47CD.4040700@oracle.com> Message-ID: <56AFB7EC.2070100@oracle.com> On 1/29/2016 9:19 PM, Jamsheed C m wrote: > > > On 1/30/2016 9:38 AM, Jamsheed C m wrote: >> >> Hi Dean, >> >> On 1/30/2016 12:49 AM, Dean Long wrote: >>> On 1/28/2016 10:36 PM, Jamsheed C m wrote: >>>> Hi Dean, >>>> >>>> On 1/29/2016 9:40 AM, Dean Long wrote: >>>>> As you noticed, for this kind of bug the memory is going to >>>>> consistent by the time the core file is written. >>>>> So to help debug this assert it if happens again, could you change >>>>> it to something like: >>>>> >>>>> #ifdef ASSERT >>>>> address computed_address = >>>>> SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, >>>>> force_unwind, true); >>>>> vmassert(handler_address == computed_address, PTR_FORMAT " != >>>>> " PTR_FORMAT, p2i(handler_address), p2i(computed_address)); >>>>> #endif >>>> I got handler_address value in this case. This value was >>>> inconsistent with value in ExceptionCache. >>>> It was having initial value and that was helpful in figuring out >>>> what would have went wrong. >>>> >>> >>> In the bug report, you said all data in the core file was >>> consistent, so I'm just wondering where you saw >>> it inconsistent. Just to confirm what was going wrong, you suspect >>> that _count was being updated before the handler? >> i meant ExceptionCache(heap) and ExecptionHandlerTable(heap) contents >> were consistent at the time core file was written. >> handler_address(local variable) had already captured failing value. >> handler_address(local variable) was inconsistent with >> ExceptionCache(heap) hanlder_address in core file. >> >> there were two failing case. >> 1) Only one entry in exception cache and failing >> >> -here i suspect handler_address in exception cache write code >> got reordered well below count and and even ExceptioCache pointer >> update in nm. >> 2)Two entries in exception cache for an exception and second entry >> causing failure. >> >> - here i suspect handler_address in exception cache write >> code got reordered below count. >> >> These reordering happens in very small window, as this code is >> already lock protected ( and has a mem barrier below). > i have removed the ambiguity in the bug report. > OK thanks. The change looks good to me. dl > Best Regards, > Jamsheed >> >> Best, >> Jamsheed >> >>> >>> dl >>> >>>> I will make this change. >>>> >>>> Best Regards, >>>> Jamsheed >>>>> >>>>> dl >>>>> >>>>> On 1/28/2016 8:16 AM, Jamsheed C m wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the fix made for issue >>>>>> >>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8143897 >>>>>> web rev: http://cr.openjdk.java.net/~thartmann/8143897/webrev.00/ >>>>>> >>>>>> Unit tests: As its hard, none >>>>>> >>>>>> Other tests: jprt. >>>>>> >>>>>> Description of the issue: >>>>>> A valid pc match in exception cache returning an invalid handler >>>>>> makes assert to fail. >>>>>> This happens as ExceptionCache reads are lock free access. >>>>>> >>>>>> As a fix for this i have put a storestore mem barrier before the >>>>>> count is updated. >>>>>> >>>>>> Best Regards, >>>>>> Jamsheed >>>>> >>>> >>> >> > From edward.nevill at gmail.com Mon Feb 1 20:33:57 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 01 Feb 2016 20:33:57 +0000 Subject: RFR: 8148783: aarch64: SEGV running SpecJBB2013 Message-ID: <1454358837.11463.14.camel@mint> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8148783/webrev.0/ JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8148783 The bug is explained in some detail in the JIRA issue. The problem is that the sign is not preserved in the following code from adrp(...) long offset = dest_page - pc_page; offset = (offset & ((1<<20)-1)) << 12; This generally works because the following movk overwrites bits 32..47 However on larger memory systems of 256 Gb it could happen that the PC address was 0x0000ffffXXXXXXXX in which case the falsely positive offset could wrap to 0x00010000XXXXXXXX Bit 48 does not get overwritten by the following movk, hence forming an invalid address. The solution is to use int32_t for offset instead of long, so it gets sign extended correctly when added to the pc(). All the best, Ed. From vladimir.kozlov at oracle.com Mon Feb 1 21:18:40 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 1 Feb 2016 13:18:40 -0800 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: References: <56AB7436.7020302@oracle.com> <56ABC001.6080302@oracle.com> <56AC142E.6010309@oracle.com> Message-ID: <56AFCBB0.5090902@oracle.com> Thank you. Vladimir On 2/1/16 11:25 AM, Berg, Michael C wrote: > The new jbs entry is logged as: > > https://bugs.openjdk.java.net/browse/JDK-8148786 (for the xml.transform failure) > > Regards, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, January 29, 2016 5:39 PM > To: Berg, Michael C; Tobias Hartmann > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit > > Michael, > > Thank you for testing changes. > Please, file JBS bug for xml.transform problem. > > Thanks, > Vladimir > > On 1/29/16 2:28 PM, Berg, Michael C wrote: >> Tobias/Vladimir: >> >> I would change the two asserts to in the 64bit code to make the check clear: >> >> assert(UseAVX > 0, "up to 512bit vectors are supported with EVEX"); >> assert(MaxVectorSize <= 64, "up to 512bit vectors are supported >> now"); >> >> As for testing with the patch applied to hotspot on a current jdk(01-29-16): >> >> Windows sde 32-bit: skx - pass, also ran and passed part of >> specjvm2008 Windows 32-bit: hsw - pass, also ran and passed all of >> specjvm2008 Windows sde 64-bit: skx - pass, also ran and passed part >> of specjvm2008 Windows 64-bit: hsw -pass, also ran and passed all of >> specjvm2008 : caveat Linux on skx: 32-bit - pass, also ran and passed >> all of specjvm2008 Linux on skx:64-bit - pass, also ran and passed all >> of specjvm2008 >> >> We should proceed with checkin in the changelist after the usual testing. >> >> Note: The above tests were done with the asserts changed on windows >> only. The 64bit changes are mostly cosmetic. It's the change to the additional_frame_bytes that makes it correct, we used equivalent constants in the stack adjustment beforehand, they had not been mapped to the movdqu for the non-vector case for a few iterations on the file. Early on I did have that code though. >> >> Caveat: xml.transform fails with the changelist and without, I checked this against a 12-21-15 built jdk which is 1 month old, so we have a new bug that is causing this app to fail as well (on windows for 64bit) on hsw. >> I checked recent jbs traffic, the occurrence does not appear to be tracked at this time. >> >> -Michael >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Friday, January 29, 2016 11:40 AM >> To: hotspot-compiler-dev at openjdk.java.net >> Cc: Berg, Michael C >> Subject: Re: [9] RFR(S): 8148490: >> RegisterSaver::restore_live_registers() fails to restore xmm registers >> on 32 bit >> >> Tobias, please verify that 64-bit code works correctly. >> About 32-bit code. >> >> Please verify correctness of next asserts: >> >> assert(UseAVX > 0, "512bit vectors are supported only with EVEX"); >> assert(MaxVectorSize == 64, "only 512bit vectors are supported >> now"); >> >> Originally we could have vectors even with only 64bit XMM registers. >> MaxVectorSize and UseAVX can be set on command line >> - what happens in such case? No vectorization? >> >> May be it is done because we save whole 128bit XMM always. Still MaxVectorSize == 64 condition is strange. >> >> Thanks, >> Vladimir >> >> On 1/29/16 6:16 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8148490 >>> http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ >>> >>> RegisterSaver::save_live_registers() and RegisterSaver::restore_live_registers() are used by the safepoint handling code to save and restore registers. The following code is emitted to save and restore XMM/YMM registers on 32 bit: >>> >>> Save: >>> ... >>> 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) >>> 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) >>> ... >>> 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) >>> 0xf34ca176: sub $0x80,%esp >>> 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) >>> 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) >>> ... >>> 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) >>> ... >>> >>> Restore: >>> ... >>> 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 >>> 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 >>> ... >>> 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 >>> 0xf34ca241: add $0x80,%esp >>> 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 >>> 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 >>> ... >>> 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 >>> ... >>> >>> The stack offsets for the vmovdqu instructions are wrong, causing the XMM registers to contain random values after a safepoint. The problem is that "additional_frame_bytes" is added to the stack offset although the stack pointer is incremented just before: >>> >>> 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM registers >>> >>> The regression test fails with "Test failed: array[0] = 1973.0 but should be 10.000" because the vectorized loop returns a wrong result. >>> >>> I spotted and fixed the following other problems: >>> - the vmovdqu instructions should be emitted before restoring YMM and >>> ZMM because they zero the upper part of the XMM registers (i.e. >>> YMM/ZMM) >>> - if 'UseAVX > 2' is set/available, we save the ZMM registers as well >>> but we do not increment 'additional_frame_words' accordingly (we need >>> another 8*32 bytes of stack space) >>> >>> Unfortunately, I don't have access to a CPU with the AVX-512 instruction set to test the "UseAVX > 2" related changes. Michael, could you verify the changes? >>> >>> The problems were introduced by the fix for JDK-8142980. >>> >>> Thanks, >>> Tobias >>> From igor.veresov at oracle.com Mon Feb 1 21:45:10 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 1 Feb 2016 13:45:10 -0800 Subject: RFR(S): 8147844: new method j.l.Runtime.onSpinWait() and the corresponding x86 hotspot instrinsic In-Reply-To: <56AF85F3.3060802@azulsystems.com> References: <56A751AE.9090203@azulsystems.com> <45B4730C-CCC2-4523-ACD1-D18B20E5EC5F@oracle.com> <56A8BC9D.8060004@azulsystems.com> <6148E4D7-AF5E-4094-B363-52E0D83452E9@oracle.com> <56AA2AE4.2090803@azulsystems.com> <2538083C-7906-44AA-A074-7DBF5F2D8654@oracle.com> <50C14C66-4068-4DD7-BD94-96E37F7C9B0A@oracle.com> <56AF85F3.3060802@azulsystems.com> Message-ID: > On Feb 1, 2016, at 8:21 AM, Ivan Krylov wrote: > > I am afraid I am still confused. > > > As Vladimir suggested, it?s better to check Matcher::match_rule_supported() in c2compiler.cpp in is_intrinsic_supported(). > > The -XX:DisableIntrinsic flags comes with the built in mechanism of verification, right? > The call_generator() calls findIntrinsic with it's lazy initialization and a check against the exclusion list. Seems to work fine with my little test, but I am fine with conforming to whatever is a custom here, I am still new to c2 code. > > (gdb) p token > $1 = 0x7ffff0276680 "_onSpinWait" > (gdb) bt > #0 DirectiveSet::is_intrinsic_disabled (this=0x7ffff019b2e0, method=...) > at /mnt/hgfs/Macbook/Users/ivan/openjdk9_onspinwait/hotspot/src/share/vm/compiler/compilerDirectives.cpp:400 > #1 0x00007ffff655f6fd in Compile::make_vm_intrinsic (this=0x7fff923b2ba0, m=0x7fff740336b0, is_virtual=false) > at /mnt/hgfs/Macbook/Users/ivan/openjdk9_onspinwait/hotspot/src/share/vm/opto/library_call.cpp:341 > #2 0x00007ffff60917d1 in Compile::find_intrinsic (this=0x7fff923b2ba0, m=0x7fff740336b0, is_virtual=false) > at /mnt/hgfs/Macbook/Users/ivan/openjdk9_onspinwait/hotspot/src/share/vm/opto/compile.cpp:164 > #3 0x00007ffff6206c06 in Compile::call_generator (this=0x7fff923b2ba0, callee=0x7fff740336b0, vtable_index=-4, call_does_dispatch=false, jvms=0x7fff740565e0, > allow_inline=true, prof_factor=1, speculative_receiver_type=0x0, allow_intrinsics=true, delayed_forbidden=false) > at /mnt/hgfs/Macbook/Users/ivan/openjdk9_onspinwait/hotspot/src/share/vm/opto/doCall.cpp:120 > #4 0x00007ffff6208506 in Parse::do_call (this=0x7fff923b1500) at /mnt/hgfs/Macbook/Users/ivan/openjdk9_onspinwait/hotspot/src/share/vm/opto/doCall.cpp:499 > #5 0x00007ffff676e305 in Parse::do_one_bytecode (this=0x7fff923b1500) > > What?s going to happen on other platforms, say on SPARC? What?s stopping you from emitting your SpinWait node there, where it cannot be matched because it doesn?t exist? igor > > we don?t support CPUs with SSE < 2 > We as openjdk or the commercial jdk? But doesn't matter at the end as the pause instruction is harmless even for prior-to-SSE2 CPUs. > > >Is there any reason this can?t be moved to generic x86.ad > I will adopt this. > > To Vladimir's points: > > > Why you check intrinsic in inline_native_Class_query() ? > > My improper following the code of other intrinsics. Will fix that. > > > (Various test suggestions) > > I will adopt those > > > I think you should consider to implement this for C1 and Interpreter since Tiered Compilation is on by default. > > I can see C1 benefiting from this but (although never implemented or measured) but how the Interpreter can possibly benefit in any measurable way? > > Thanks, > > Ivan > > > > > On 29/01/2016 04:48, Igor Veresov wrote: >>> On Jan 28, 2016, at 12:41 PM, Igor Veresov wrote: >>> >>> x86.ad: >>> f >>> It seems that the comment here is off: >>> 1714 case Op_OnSpinWait: >>> 1715 if (UseSSE < 2) // requires at least SSE4 >>> 1716 ret_value = false; >>> 1717 break; >>> >>> Also we don?t support CPUs with SSE < 2, so you don?t have to make these changes to x86.ad. It?s enough that has_match_rule(), that is called by Matcher::match_rule_supported(), will return true for Op_OnSpinWait. >>> >>> >>> x86_64.ad: >>> +instruct onspinwait() >>> +%{ >>> + match(OnSpinWait); >>> + ins_cost(200); >>> ... >>> >>> Is there any reason this can?t be moved to generic x86.ad ? It can be easily supported on 32bit as well, right (we do still support 32bit mode on linux)? The encoding is the same for both 32 and 64 bit modes, so that should be trivial. >>> >>> library_call.cpp: >>> >>> I think you forgot to actually call Matcher::match_rule_supported(). I think it should be something like: >>> >>> bool LibraryCallKit::inline_onspinwait() { >>> if (Matcher::match_rule_supported(Op_OnSpinWait) { >>> insert_mem_bar(Op_OnSpinWait); >>> return true; >>> } >>> return false; >>> } >>> >> As Vladimir suggested, it?s better to check Matcher::match_rule_supported() in c2compiler.cpp in is_intrinsic_supported(). Sorry about the confusion. I stand by the other comments though. >> >> igor >> >>> igor >>> >>>> On Jan 28, 2016, at 6:51 AM, Ivan Krylov wrote: >>>> >>>> Hi Igor, >>>> >>>> Following Vladimir's suggestion I eliminated the UseOnSpinWaitIntrinsic flag altogether. I have adopted the Matcher::match_rule_supported() logic - seems to work on intel, but I don't have any non-intel box to test. >>>> >>>> Anyway, the new webrev: >>>> http://cr.openjdk.java.net/~ikrylov/8147844.hs.01/ >>>> >>>> Igor, Vladimir, thanks, >>>> >>>> Ivan >>>> >>>> On 27/01/2016 22:03, Igor Veresov wrote: >>>>> Actually, I?d rather use Matcher::match_rule_supported() to test if it?s supported on the platform, rather than fixing all vm_version_*.* to check for the flag validity, that?s tedious (you forgot x86-32 and there?s going to be more platforms to fix for you sponsor). Something like UseOnSpinWaitIntrinsic && Matcher::match_rule_supported(Op_OnSpinWait) to decide whether or not to inline the intrinsic. Also, why are you not turning it on by default? >>>>> >>>>> igor >>>>> >>>>>> On Jan 27, 2016, at 4:48 AM, Ivan Krylov wrote: >>>>>> >>>>>> Looks like there was some good discussion while I was peacefully sleeping. >>>>>> I don't have much to add. This patch was somewhat inspired by JEP-171 changes. >>>>>> Perhaps,there are other ways to achieve the same semantics. >>>>>> >>>>>> So, if we can consider this reviewed - I will wait for the actual JEP to become targeted to 9 and then seek a sponsor to do the push. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Ivan >>>>>> >>>>>> On 27/01/2016 09:12, Igor Veresov wrote: >>>>>>> I realize it?s not a big deal. I was just wondering if there was any specific reason control alone is not enough. >>>>>>> Anyways, looks ok for the first cut. >>>>>>> >>>>>>> igor >>>>>>> >>>>>>>> On Jan 26, 2016, at 9:24 PM, Gil Tene wrote: >>>>>>>> >>>>>>>> Since a sensical loop that calls onSpinWait() would include at least a volatile load on every iteration (and possibly a volatile store), the new node does not create significant extra move restrictions that are not already there. Modeling this with a memory effect is one simple way to prevent it from being re-ordered out of the loop. There are probably other ways to achieve this, but this one doesn't really have a performance downside? >>>>>>>> >>>>>>>> ? Gil. >>>>>>>> >>>>>>>>> On Jan 26, 2016, at 4:44 PM, Igor Veresov wrote: >>>>>>>>> >>>>>>>>> So, why does the new node have a memory effect? That would seem to prevent any movement of the subsequent loads in your loop, right? If that?s intentional I wonder why is that? >>>>>>>>> >>>>>>>>> igor >>>>>>>>> >>>>>>>>>> On Jan 26, 2016, at 2:59 AM, Ivan Krylov wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Some of you may have a seen a few e-mails on the core-libs alias about a proposed ?spin wait hint?. The JEP is forming up nicely at https://bugs.openjdk.java.net/browse/JDK-8147832. There seems to be a consensus on the API side. It is now in a draft state and I hope this JEP will get targeted for java 9 shortly. The upcoming API changes can be seen at the webrev: >>>>>>>>>> http://cr.openjdk.java.net/~ikrylov/8147844.jdk.00/ >>>>>>>>>> >>>>>>>>>> At this time I would like to ask for a review of the hs-comp changes. The plan is push changes into class libraries and hotspot synchronously but that may happen after the JEP gets targeted. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147844 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~ikrylov/8147844.hs.00/ >>>>>>>>>> >>>>>>>>>> The idea of the fix is pretty simple: hotspot replaces a call to java.lang.Runtime.onSpinWait() with an intrinsic that is effectively a 'pause' instruction on x86. This intrinsic is guarded by the -XX:?UseOnSpinWaitIntrinsic flag. For non-x86 platforms there is a verification code that makes sure the flag is off, VM will just execute at empty method java.lang.Runtime.onSpinWait() ? effectively a no-op. According the [1] the 'pause' instruction is functional since SSE2, but even on CPUs prior to SSE2 the 'pause' instruction is a no-op and hence harmless, there seems to be no need to add guarding code for older generations of Intel CPUs. >>>>>>>>>> >>>>>>>>>> The proposed patch includes a simple regression test that simply makes sure that method java.lang.Runtime.onSpinWait() gets intrinsified. There are several other producer-consumer-like performance tests ready that the authors of this JEP would be happy to make available under JEP-230 but I am uncertain about the process. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> [1] - https://software.intel.com/en-us/articles/benefitting-power-and-performance-sleep-loops > From uschindler at apache.org Mon Feb 1 23:17:48 2016 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 2 Feb 2016 00:17:48 +0100 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: <56AB7436.7020302@oracle.com> References: <56AB7436.7020302@oracle.com> Message-ID: <000001d15d46$c612cdb0$52386910$@apache.org> Hi Tobias, thanks for taking care about this issue! Since last week we get tons of failures on 32bit JVMs with Apache Lucene (AVX2/Haswell machine). It looks like those were caused by this issue, because the previously tested build 94 worked perfectly (and this one was before this got broken). We are currently confirming with -XX:-UseSuperWord that this was caused by this issue. So we hope for an fixed EA build soon (together with the compact strings fix): jenkins at serv1:~/tools/java/32bit/jdk-9-ea+102/bin$ ./java -XX:+PrintFlagsFinal -version | grep AVX intx UseAVX = 2 {ARCH product} java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+102-2016-01-21-001243.javare.4316.nc) Java HotSpot(TM) Server VM (build 9-ea+102-2016-01-21-001243.javare.4316.nc, mixed mode) Uwe P.S.: This issue was shown on FOSDEM as example for the JDK9 testing we do: https://fosdem.org/2016/schedule/event/bug_hunting_lucene/, page/slide 39 P.P.S.: Maybe add label "apache-lucene-found" to this issue :-) ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Tobias Hartmann > Sent: Friday, January 29, 2016 3:16 PM > To: hotspot-compiler-dev at openjdk.java.net > Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to > restore xmm registers on 32 bit > > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8148490 > http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ > > RegisterSaver::save_live_registers() and > RegisterSaver::restore_live_registers() are used by the safepoint handling > code to save and restore registers. The following code is emitted to save and > restore XMM/YMM registers on 32 bit: > > Save: > ... > 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) > 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) > ... > 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) > 0xf34ca176: sub $0x80,%esp > 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) > 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) > ... > 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) > ... > > Restore: > ... > 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 > 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 > ... > 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 > 0xf34ca241: add $0x80,%esp > 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 > 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 > ... > 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 > ... > > The stack offsets for the vmovdqu instructions are wrong, causing the XMM > registers to contain random values after a safepoint. The problem is that > "additional_frame_bytes" is added to the stack offset although the stack > pointer is incremented just before: > > 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM > registers > > The regression test fails with "Test failed: array[0] = 1973.0 but should be > 10.000" because the vectorized loop returns a wrong result. > > I spotted and fixed the following other problems: > - the vmovdqu instructions should be emitted before restoring YMM and > ZMM because they zero the upper part of the XMM registers (i.e. > YMM/ZMM) > - if 'UseAVX > 2' is set/available, we save the ZMM registers as well but we > do not increment 'additional_frame_words' accordingly (we need another > 8*32 bytes of stack space) > > Unfortunately, I don't have access to a CPU with the AVX-512 instruction set > to test the "UseAVX > 2" related changes. Michael, could you verify the > changes? > > The problems were introduced by the fix for JDK-8142980. > > Thanks, > Tobias From jamsheed.c.m at oracle.com Tue Feb 2 08:19:31 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 2 Feb 2016 13:49:31 +0530 Subject: RFR(XS): 8143897 :Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same In-Reply-To: <56AFB7EC.2070100@oracle.com> References: <56AA3ED7.4030407@oracle.com> <56AAE63A.4060905@oracle.com> <56AB0868.2080307@oracle.com> <56ABBB34.80002@oracle.com> <56AC374C.9050800@oracle.com> <56AC47CD.4040700@oracle.com> <56AFB7EC.2070100@oracle.com> Message-ID: <56B06693.7030507@oracle.com> On 2/2/2016 1:24 AM, Dean Long wrote: > On 1/29/2016 9:19 PM, Jamsheed C m wrote: >> >> >> On 1/30/2016 9:38 AM, Jamsheed C m wrote: >>> >>> Hi Dean, >>> >>> On 1/30/2016 12:49 AM, Dean Long wrote: >>>> On 1/28/2016 10:36 PM, Jamsheed C m wrote: >>>>> Hi Dean, >>>>> >>>>> On 1/29/2016 9:40 AM, Dean Long wrote: >>>>>> As you noticed, for this kind of bug the memory is going to >>>>>> consistent by the time the core file is written. >>>>>> So to help debug this assert it if happens again, could you >>>>>> change it to something like: >>>>>> >>>>>> #ifdef ASSERT >>>>>> address computed_address = >>>>>> SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, >>>>>> force_unwind, true); >>>>>> vmassert(handler_address == computed_address, PTR_FORMAT " != >>>>>> " PTR_FORMAT, p2i(handler_address), p2i(computed_address)); >>>>>> #endif >>>>> I got handler_address value in this case. This value was >>>>> inconsistent with value in ExceptionCache. >>>>> It was having initial value and that was helpful in figuring out >>>>> what would have went wrong. >>>>> >>>> >>>> In the bug report, you said all data in the core file was >>>> consistent, so I'm just wondering where you saw >>>> it inconsistent. Just to confirm what was going wrong, you >>>> suspect that _count was being updated before the handler? >>> i meant ExceptionCache(heap) and ExecptionHandlerTable(heap) >>> contents were consistent at the time core file was written. >>> handler_address(local variable) had already captured failing value. >>> handler_address(local variable) was inconsistent with >>> ExceptionCache(heap) hanlder_address in core file. >>> >>> there were two failing case. >>> 1) Only one entry in exception cache and failing >>> >>> -here i suspect handler_address in exception cache write >>> code got reordered well below count and and even ExceptioCache >>> pointer update in nm. >>> 2)Two entries in exception cache for an exception and second entry >>> causing failure. >>> >>> - here i suspect handler_address in exception cache write >>> code got reordered below count. >>> >>> These reordering happens in very small window, as this code is >>> already lock protected ( and has a mem barrier below). >> i have removed the ambiguity in the bug report. >> > > OK thanks. The change looks good to me. > Thanks Dean. > dl > >> Best Regards, >> Jamsheed >>> >>> Best, >>> Jamsheed >>> >>>> >>>> dl >>>> >>>>> I will make this change. >>>>> >>>>> Best Regards, >>>>> Jamsheed >>>>>> >>>>>> dl >>>>>> >>>>>> On 1/28/2016 8:16 AM, Jamsheed C m wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the fix made for issue >>>>>>> >>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8143897 >>>>>>> web rev: http://cr.openjdk.java.net/~thartmann/8143897/webrev.00/ >>>>>>> >>>>>>> Unit tests: As its hard, none >>>>>>> >>>>>>> Other tests: jprt. >>>>>>> >>>>>>> Description of the issue: >>>>>>> A valid pc match in exception cache returning an invalid handler >>>>>>> makes assert to fail. >>>>>>> This happens as ExceptionCache reads are lock free access. >>>>>>> >>>>>>> As a fix for this i have put a storestore mem barrier before the >>>>>>> count is updated. >>>>>>> >>>>>>> Best Regards, >>>>>>> Jamsheed >>>>>> >>>>> >>>> >>> >> > From tobias.hartmann at oracle.com Tue Feb 2 08:19:24 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 2 Feb 2016 09:19:24 +0100 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: References: <56AB7436.7020302@oracle.com> <56ABC001.6080302@oracle.com> <56AF4268.4080704@oracle.com> Message-ID: <56B0668C.2000405@oracle.com> Hi Michael, On 01.02.2016 19:50, Berg, Michael C wrote: > Tobias, since it works everywhere now, let us proceed. > The code is ok in its current form. Okay, here is the new webrev, including the fixed asserts: http://cr.openjdk.java.net/~thartmann/8148490/webrev.01/ On 29.01.2016 20:39, Vladimir Kozlov wrote: > Originally we could have vectors even with only 64bit XMM registers. MaxVectorSize and UseAVX can be set on command line - what happens in such case? No vectorization? Yes, we hit the assert if MaxVectorSize < 64 is set. This is fixed with above's changes. Thanks, Tobias > > Thanks, > Michael > > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Monday, February 01, 2016 3:33 AM > To: Berg, Michael C; Vladimir Kozlov > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit > > Thanks Vladimir and Michael, for the reviews. > > Michael wrote (off-thread): >> Tobias, I might take the restore code a different direction. Would it be ok if I handed you code back which has an offset based approach that makes the direction of restores no longer dependent upon the current stack? > > I will wait for his changes and then send out a new RFR. > > Best, > Tobias > > On 29.01.2016 23:28, Berg, Michael C wrote: >> Tobias/Vladimir: >> >> I would change the two asserts to in the 64bit code to make the check clear: >> >> assert(UseAVX > 0, "up to 512bit vectors are supported with EVEX"); >> assert(MaxVectorSize <= 64, "up to 512bit vectors are supported >> now"); >> >> As for testing with the patch applied to hotspot on a current jdk(01-29-16): >> >> Windows sde 32-bit: skx - pass, also ran and passed part of >> specjvm2008 Windows 32-bit: hsw - pass, also ran and passed all of >> specjvm2008 Windows sde 64-bit: skx - pass, also ran and passed part >> of specjvm2008 Windows 64-bit: hsw -pass, also ran and passed all of >> specjvm2008 : caveat Linux on skx: 32-bit - pass, also ran and passed >> all of specjvm2008 Linux on skx:64-bit - pass, also ran and passed all >> of specjvm2008 >> >> We should proceed with checkin in the changelist after the usual testing. >> >> Note: The above tests were done with the asserts changed on windows >> only. The 64bit changes are mostly cosmetic. It's the change to the additional_frame_bytes that makes it correct, we used equivalent constants in the stack adjustment beforehand, they had not been mapped to the movdqu for the non-vector case for a few iterations on the file. Early on I did have that code though. >> >> Caveat: xml.transform fails with the changelist and without, I checked this against a 12-21-15 built jdk which is 1 month old, so we have a new bug that is causing this app to fail as well (on windows for 64bit) on hsw. >> I checked recent jbs traffic, the occurrence does not appear to be tracked at this time. >> >> -Michael >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Friday, January 29, 2016 11:40 AM >> To: hotspot-compiler-dev at openjdk.java.net >> Cc: Berg, Michael C >> Subject: Re: [9] RFR(S): 8148490: >> RegisterSaver::restore_live_registers() fails to restore xmm registers >> on 32 bit >> >> Tobias, please verify that 64-bit code works correctly. >> About 32-bit code. >> >> Please verify correctness of next asserts: >> >> assert(UseAVX > 0, "512bit vectors are supported only with EVEX"); >> assert(MaxVectorSize == 64, "only 512bit vectors are supported >> now"); >> >> Originally we could have vectors even with only 64bit XMM registers. >> MaxVectorSize and UseAVX can be set on command line >> - what happens in such case? No vectorization? >> >> May be it is done because we save whole 128bit XMM always. Still MaxVectorSize == 64 condition is strange. >> >> Thanks, >> Vladimir >> >> On 1/29/16 6:16 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8148490 >>> http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ >>> >>> RegisterSaver::save_live_registers() and RegisterSaver::restore_live_registers() are used by the safepoint handling code to save and restore registers. The following code is emitted to save and restore XMM/YMM registers on 32 bit: >>> >>> Save: >>> ... >>> 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) >>> 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) >>> ... >>> 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) >>> 0xf34ca176: sub $0x80,%esp >>> 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) >>> 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) >>> ... >>> 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) >>> ... >>> >>> Restore: >>> ... >>> 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 >>> 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 >>> ... >>> 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 >>> 0xf34ca241: add $0x80,%esp >>> 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 >>> 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 >>> ... >>> 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 >>> ... >>> >>> The stack offsets for the vmovdqu instructions are wrong, causing the XMM registers to contain random values after a safepoint. The problem is that "additional_frame_bytes" is added to the stack offset although the stack pointer is incremented just before: >>> >>> 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM registers >>> >>> The regression test fails with "Test failed: array[0] = 1973.0 but should be 10.000" because the vectorized loop returns a wrong result. >>> >>> I spotted and fixed the following other problems: >>> - the vmovdqu instructions should be emitted before restoring YMM and >>> ZMM because they zero the upper part of the XMM registers (i.e. >>> YMM/ZMM) >>> - if 'UseAVX > 2' is set/available, we save the ZMM registers as well >>> but we do not increment 'additional_frame_words' accordingly (we need >>> another 8*32 bytes of stack space) >>> >>> Unfortunately, I don't have access to a CPU with the AVX-512 instruction set to test the "UseAVX > 2" related changes. Michael, could you verify the changes? >>> >>> The problems were introduced by the fix for JDK-8142980. >>> >>> Thanks, >>> Tobias >>> From tobias.hartmann at oracle.com Tue Feb 2 08:28:41 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 2 Feb 2016 09:28:41 +0100 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: <000001d15d46$c612cdb0$52386910$@apache.org> References: <56AB7436.7020302@oracle.com> <000001d15d46$c612cdb0$52386910$@apache.org> Message-ID: <56B068B9.90600@oracle.com> Hi Uwe, On 02.02.2016 00:17, Uwe Schindler wrote: > Hi Tobias, > > thanks for taking care about this issue! Since last week we get tons of failures on 32bit JVMs with Apache Lucene (AVX2/Haswell machine). It looks like those were caused by this issue, because the previously tested build 94 worked perfectly (and this one was before this got broken). We are currently confirming with -XX:-UseSuperWord that this was caused by this issue. So we hope for an fixed EA build soon (together with the compact strings fix): > > jenkins at serv1:~/tools/java/32bit/jdk-9-ea+102/bin$ ./java -XX:+PrintFlagsFinal -version | grep AVX > intx UseAVX = 2 {ARCH product} > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+102-2016-01-21-001243.javare.4316.nc) > Java HotSpot(TM) Server VM (build 9-ea+102-2016-01-21-001243.javare.4316.nc, mixed mode) Thanks for letting me know! The problem was introduced with JDK-8142980 in b96. The fix for Compact Strings (JDK-8144212) is making its way through the repos. It's currently in the jdk9-dev repo [1] and will we pushed to master soon. > P.S.: This issue was shown on FOSDEM as example for the JDK9 testing we do: https://fosdem.org/2016/schedule/event/bug_hunting_lucene/, page/slide 39 > P.P.S.: Maybe add label "apache-lucene-found" to this issue :-) Sure, done. Best, Tobias [1] http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/bf74058d67ec > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >> bounces at openjdk.java.net] On Behalf Of Tobias Hartmann >> Sent: Friday, January 29, 2016 3:16 PM >> To: hotspot-compiler-dev at openjdk.java.net >> Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to >> restore xmm registers on 32 bit >> >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8148490 >> http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ >> >> RegisterSaver::save_live_registers() and >> RegisterSaver::restore_live_registers() are used by the safepoint handling >> code to save and restore registers. The following code is emitted to save and >> restore XMM/YMM registers on 32 bit: >> >> Save: >> ... >> 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) >> 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) >> ... >> 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) >> 0xf34ca176: sub $0x80,%esp >> 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) >> 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) >> ... >> 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) >> ... >> >> Restore: >> ... >> 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 >> 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 >> ... >> 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 >> 0xf34ca241: add $0x80,%esp >> 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 >> 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 >> ... >> 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 >> ... >> >> The stack offsets for the vmovdqu instructions are wrong, causing the XMM >> registers to contain random values after a safepoint. The problem is that >> "additional_frame_bytes" is added to the stack offset although the stack >> pointer is incremented just before: >> >> 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM >> registers >> >> The regression test fails with "Test failed: array[0] = 1973.0 but should be >> 10.000" because the vectorized loop returns a wrong result. >> >> I spotted and fixed the following other problems: >> - the vmovdqu instructions should be emitted before restoring YMM and >> ZMM because they zero the upper part of the XMM registers (i.e. >> YMM/ZMM) >> - if 'UseAVX > 2' is set/available, we save the ZMM registers as well but we >> do not increment 'additional_frame_words' accordingly (we need another >> 8*32 bytes of stack space) >> >> Unfortunately, I don't have access to a CPU with the AVX-512 instruction set >> to test the "UseAVX > 2" related changes. Michael, could you verify the >> changes? >> >> The problems were introduced by the fix for JDK-8142980. >> >> Thanks, >> Tobias > From mikael.gerdin at oracle.com Tue Feb 2 14:55:38 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 2 Feb 2016 15:55:38 +0100 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <550334AB-0A58-41A7-B00A-974EBA3F8B0B@oracle.com> References: <56AAA808.6090604@oracle.com> <550334AB-0A58-41A7-B00A-974EBA3F8B0B@oracle.com> Message-ID: <56B0C36A.5050605@oracle.com> Hi, On 2016-01-29 15:04, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for looking at this. > >> G1 barrier was added by Mikael Gerdin from GC. He should also look on this change. >> >> https://bugs.openjdk.java.net/browse/JDK-8014555 >> >> Also we have specialized insert_mem_bar_volatile() if we don't want wide memory affect. Why not use it? > > The membar in the change takes the entire memory state as input but only changes raw memory. I don?t think that can be achieved with insert_mem_bar_volatile(). As explained by Mikael, the membar is here to force ordering between the oop store and the card table load. That?s why I think the membar?s inputs and outputs should be set up that way. > >> And we need to keep precedent edge link to oop store in case EA eliminates related allocation. > > I missed that, indeed. Mikael, can you confirm if this is ok (eliminating the barrier if the object being stored to doesn?t escape)? The barrier can only be removed if the object is never allocated. If the object is allocated and the field store is performed then the barrier must be preserved, even if the compiler can prove that no application thread can see the objects, a concurrent gc thread may still see these objects. /Mikael > > Roland. > >> >> Thanks, >> Vladimir >> >> On 1/28/16 4:49 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8087341/webrev.00/ >>> >>> C2 currently doesn?t optimize the field load in the following code: >>> >>> static Object field; >>> >>> static Object m(Object o) { >>> field = o; >>> return field; >>> } >>> >>> It should return o but instead loads the value back from memory. The reason it misses such simple optimization is that the G1 post barrier has a memory barrier with a wide effect on the memory state. C2 doesn?t optimize this either: >>> >>> object.field = other_object; >>> object.field = other_object; >>> >>> Same applies to -XX:+UseConcMarkSweepGC -XX:+UseCondCardMark >>> >>> That memory barrier was added to have a memory barrier instruction and doesn?t have to have a wide memory effect. >>> >>> Roland. >>> > From zoltan.majo at oracle.com Tue Feb 2 15:05:43 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 2 Feb 2016 16:05:43 +0100 Subject: [9] RFR (S): 8148753: Compilation fails due to field accesses on array types In-Reply-To: <56AF9938.1020403@oracle.com> References: <56AF7645.4050409@oracle.com> <56AF9938.1020403@oracle.com> Message-ID: <56B0C5C7.5070903@oracle.com> Hi Vladimir, thank you for the feedback! On 02/01/2016 06:43 PM, Vladimir Kozlov wrote: > Extend comment: > > + // handling in ciField::will_link. > > "and throw a java.lang.NoSuchFieldError exception (the expected > behavior in this case)." > > Give different name to first local 'declared_holder' and after array > type check do cast: > > ciInstanceKlass* declared_holder = holder->as_instance_klass(); > > then you don't need to change following code. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8148753/webrev.01/ Thank you and best regards, Zoltan > > Thanks, > Vladimir > > On 2/1/16 7:14 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the patch for 8148753. >> >> https://bugs.openjdk.java.net/browse/JDK-8148753 >> >> Problem: Compiling methods that access fields of array types fails. The >> problem is that both compilers assume that only fields of instance types >> (but not field of array types) can be accessed. However, an array can be >> also seen as an instance type, as every array is a subclass of >> java.lang.Object. >> >> Solution: Treat accesses to fields of array types as accesses to fields >> of java.lang.Object. By convention, the java.lang.Object does not have >> any fields. As a result, the generated code will throw a >> java.lang.NoSuchFieldError exception (the expected behavior in this >> case). >> >> Webrev: >> http://cr.openjdk.java.net/~zmajo/8148753/webrev.00/ >> >> Testing: >> - JPRT; >> - all JTREG hotspot/compiler tests on all supported platforms. >> >> Thank you and best regards, >> >> >> Zoltan >> From aph at redhat.com Tue Feb 2 15:16:13 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 2 Feb 2016 15:16:13 +0000 Subject: [aarch64-port-dev ] RFR: 8148783: aarch64: SEGV running SpecJBB2013 In-Reply-To: <1454358837.11463.14.camel@mint> References: <1454358837.11463.14.camel@mint> Message-ID: <56B0C83D.900@redhat.com> Hi, On 02/01/2016 08:33 PM, Edward Nevill wrote: > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8148783 > > The bug is explained in some detail in the JIRA issue. > > The problem is that the sign is not preserved in the following code > from adrp(...) > > long offset = dest_page - pc_page; > offset = (offset & ((1<<20)-1)) << 12; > > This generally works because the following movk overwrites bits 32..47 > > However on larger memory systems of 256 Gb it could happen that the > PC address was > > 0x0000ffffXXXXXXXX > > in which case the falsely positive offset could wrap to > > 0x00010000XXXXXXXX > > Bit 48 does not get overwritten by the following movk, hence forming > an invalid address. > > The solution is to use int32_t for offset instead of long, so it > gets sign extended correctly when added to the pc(). I can't accept that patch because the overflowing assignment from long to int32_t is undefined behaviour. It is also very obscure code. Can you test the patch I've appended instead? It tiptoes around the UB and should be OK. Thanks, Andrew. diff --git a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp +++ b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp @@ -3980,6 +3980,14 @@ return inst_mark(); } +int64_t MacroAssembler::truncate_signed_bitfield(int64_t n, int width) { + // Left shifts of a signed integer are UB in Standard C++ but + // well-defined in GNU C++. + n <<= 64 - width; + n >>= 64 - width; + return n; +} + void MacroAssembler::adrp(Register reg1, const Address &dest, unsigned long &byte_offset) { relocInfo::relocType rtype = dest.rspec().reloc()->type(); unsigned long low_page = (unsigned long)CodeCache::low_bound() >> 12; @@ -3999,8 +4007,18 @@ _adrp(reg1, dest.target()); } else { unsigned long pc_page = (unsigned long)pc() >> 12; - long offset = dest_page - pc_page; - offset = (offset & ((1<<20)-1)) << 12; + unsigned long page_offset = dest_page - pc_page; + + // The signed offset (in 4k pages) from PC to dest page. We use a + // reference in order to avoid UB when converting from unsigned to + // signed. + long offset = reinterpret_cast(page_offset); + + // The signed offset (in bytes) from the PC to the destination + // page. We only want the 32 LSBs of the offset because the range + // of ADRP is +-2G, i.e. 32 bits. + offset = truncate_signed_bitfield(offset << 12, 32); + _adrp(reg1, pc()+offset); movk(reg1, (unsigned long)dest.target() >> 32, 32); } diff --git a/src/cpu/aarch64/vm/macroAssembler_aarch64.hpp b/src/cpu/aarch64/vm/macroAssembler_aarch64.hpp --- a/src/cpu/aarch64/vm/macroAssembler_aarch64.hpp +++ b/src/cpu/aarch64/vm/macroAssembler_aarch64.hpp @@ -85,9 +85,10 @@ void call_VM_helper(Register oop_result, address entry_point, int number_of_arguments, bool check_exceptions = true); - // Maximum size of class area in Metaspace when compressed uint64_t use_XOR_for_compressed_class_base; + int64_t truncate_signed_bitfield(int64_t n, int width); + public: MacroAssembler(CodeBuffer* code) : Assembler(code) { use_XOR_for_compressed_class_base From pavel.punegov at oracle.com Tue Feb 2 15:29:50 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Tue, 2 Feb 2016 18:29:50 +0300 Subject: RFR(XXS): 8148509: CompilerControl: check all inlining events Message-ID: <590ABD60-D1D9-40B2-96D5-CE087E596D5E@oracle.com> Hi, please review the following small fix. It changes access for CompilerWhiteBoxTest?s constant BACKEDGE_THRESHOLD. It is required for the closed part of the fix that should use this constant. webrev: http://cr.openjdk.java.net/~ppunegov/8148509/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8148509 ? Thanks, Pavel Punegov -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Tue Feb 2 17:03:43 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 2 Feb 2016 17:03:43 +0000 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <56B0C36A.5050605@oracle.com> References: <56AAA808.6090604@oracle.com> <550334AB-0A58-41A7-B00A-974EBA3F8B0B@oracle.com> <56B0C36A.5050605@oracle.com> Message-ID: <56B0E16F.5050509@redhat.com> On 02/02/2016 02:55 PM, Mikael Gerdin wrote: > The barrier can only be removed if the object is never allocated. > If the object is allocated and the field store is performed then the > barrier must be preserved, even if the compiler can prove that no > application thread can see the objects, a concurrent gc thread may still > see these objects. This reminds me of the discussion at http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020345.html It removes the memory barrier after object creation if the object does not escape. I guess this is not safe, then, because a concurrent GC will see a partially-constructed object: the fields may not have been zeroed and the header may not have been initialized. I'd like your opinion on this. Thanks, Andrew. From vladimir.kozlov at oracle.com Tue Feb 2 17:22:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Feb 2016 09:22:56 -0800 Subject: [9] RFR (S): 8148753: Compilation fails due to field accesses on array types In-Reply-To: <56B0C5C7.5070903@oracle.com> References: <56AF7645.4050409@oracle.com> <56AF9938.1020403@oracle.com> <56B0C5C7.5070903@oracle.com> Message-ID: <56B0E5F0.9000009@oracle.com> Very good. Thanks, Vladimir On 2/2/16 7:05 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > thank you for the feedback! > > On 02/01/2016 06:43 PM, Vladimir Kozlov wrote: >> Extend comment: >> >> + // handling in ciField::will_link. >> >> "and throw a java.lang.NoSuchFieldError exception (the expected behavior in this case)." >> >> Give different name to first local 'declared_holder' and after array type check do cast: >> >> ciInstanceKlass* declared_holder = holder->as_instance_klass(); >> >> then you don't need to change following code. > > Here is the updated webrev: > > http://cr.openjdk.java.net/~zmajo/8148753/webrev.01/ > > Thank you and best regards, > > > Zoltan >> >> Thanks, >> Vladimir >> >> On 2/1/16 7:14 AM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the patch for 8148753. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8148753 >>> >>> Problem: Compiling methods that access fields of array types fails. The >>> problem is that both compilers assume that only fields of instance types >>> (but not field of array types) can be accessed. However, an array can be >>> also seen as an instance type, as every array is a subclass of >>> java.lang.Object. >>> >>> Solution: Treat accesses to fields of array types as accesses to fields >>> of java.lang.Object. By convention, the java.lang.Object does not have >>> any fields. As a result, the generated code will throw a >>> java.lang.NoSuchFieldError exception (the expected behavior in this case). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~zmajo/8148753/webrev.00/ >>> >>> Testing: >>> - JPRT; >>> - all JTREG hotspot/compiler tests on all supported platforms. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > From pavel.punegov at oracle.com Tue Feb 2 17:52:40 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Tue, 2 Feb 2016 20:52:40 +0300 Subject: RFR(XXS): 8148864: Quarantine CompilerControl tests Message-ID: Please review the fix that quarantines tests affected by JDK-8148563 and JDK-8140354 webrev: http://cr.openjdk.java.net/~ppunegov/8148864/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8148864 ? Thanks, Pavel Punegov -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Feb 2 17:59:15 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Feb 2016 09:59:15 -0800 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: <56B0668C.2000405@oracle.com> References: <56AB7436.7020302@oracle.com> <56ABC001.6080302@oracle.com> <56AF4268.4080704@oracle.com> <56B0668C.2000405@oracle.com> Message-ID: <56B0EE73.9000304@oracle.com> Looks good. Thanks, Vladimir On 2/2/16 12:19 AM, Tobias Hartmann wrote: > Hi Michael, > > On 01.02.2016 19:50, Berg, Michael C wrote: >> Tobias, since it works everywhere now, let us proceed. >> The code is ok in its current form. > > Okay, here is the new webrev, including the fixed asserts: > http://cr.openjdk.java.net/~thartmann/8148490/webrev.01/ > > On 29.01.2016 20:39, Vladimir Kozlov wrote: >> Originally we could have vectors even with only 64bit XMM registers. MaxVectorSize and UseAVX can be set on command line - what happens in such case? No vectorization? > > Yes, we hit the assert if MaxVectorSize < 64 is set. This is fixed with above's changes. > > Thanks, > Tobias > >> >> Thanks, >> Michael >> >> -----Original Message----- >> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >> Sent: Monday, February 01, 2016 3:33 AM >> To: Berg, Michael C; Vladimir Kozlov >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit >> >> Thanks Vladimir and Michael, for the reviews. >> >> Michael wrote (off-thread): >>> Tobias, I might take the restore code a different direction. Would it be ok if I handed you code back which has an offset based approach that makes the direction of restores no longer dependent upon the current stack? >> >> I will wait for his changes and then send out a new RFR. >> >> Best, >> Tobias >> >> On 29.01.2016 23:28, Berg, Michael C wrote: >>> Tobias/Vladimir: >>> >>> I would change the two asserts to in the 64bit code to make the check clear: >>> >>> assert(UseAVX > 0, "up to 512bit vectors are supported with EVEX"); >>> assert(MaxVectorSize <= 64, "up to 512bit vectors are supported >>> now"); >>> >>> As for testing with the patch applied to hotspot on a current jdk(01-29-16): >>> >>> Windows sde 32-bit: skx - pass, also ran and passed part of >>> specjvm2008 Windows 32-bit: hsw - pass, also ran and passed all of >>> specjvm2008 Windows sde 64-bit: skx - pass, also ran and passed part >>> of specjvm2008 Windows 64-bit: hsw -pass, also ran and passed all of >>> specjvm2008 : caveat Linux on skx: 32-bit - pass, also ran and passed >>> all of specjvm2008 Linux on skx:64-bit - pass, also ran and passed all >>> of specjvm2008 >>> >>> We should proceed with checkin in the changelist after the usual testing. >>> >>> Note: The above tests were done with the asserts changed on windows >>> only. The 64bit changes are mostly cosmetic. It's the change to the additional_frame_bytes that makes it correct, we used equivalent constants in the stack adjustment beforehand, they had not been mapped to the movdqu for the non-vector case for a few iterations on the file. Early on I did have that code though. >>> >>> Caveat: xml.transform fails with the changelist and without, I checked this against a 12-21-15 built jdk which is 1 month old, so we have a new bug that is causing this app to fail as well (on windows for 64bit) on hsw. >>> I checked recent jbs traffic, the occurrence does not appear to be tracked at this time. >>> >>> -Michael >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Friday, January 29, 2016 11:40 AM >>> To: hotspot-compiler-dev at openjdk.java.net >>> Cc: Berg, Michael C >>> Subject: Re: [9] RFR(S): 8148490: >>> RegisterSaver::restore_live_registers() fails to restore xmm registers >>> on 32 bit >>> >>> Tobias, please verify that 64-bit code works correctly. >>> About 32-bit code. >>> >>> Please verify correctness of next asserts: >>> >>> assert(UseAVX > 0, "512bit vectors are supported only with EVEX"); >>> assert(MaxVectorSize == 64, "only 512bit vectors are supported >>> now"); >>> >>> Originally we could have vectors even with only 64bit XMM registers. >>> MaxVectorSize and UseAVX can be set on command line >>> - what happens in such case? No vectorization? >>> >>> May be it is done because we save whole 128bit XMM always. Still MaxVectorSize == 64 condition is strange. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/29/16 6:16 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch: >>>> https://bugs.openjdk.java.net/browse/JDK-8148490 >>>> http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ >>>> >>>> RegisterSaver::save_live_registers() and RegisterSaver::restore_live_registers() are used by the safepoint handling code to save and restore registers. The following code is emitted to save and restore XMM/YMM registers on 32 bit: >>>> >>>> Save: >>>> ... >>>> 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) >>>> 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) >>>> ... >>>> 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) >>>> 0xf34ca176: sub $0x80,%esp >>>> 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) >>>> 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) >>>> ... >>>> 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) >>>> ... >>>> >>>> Restore: >>>> ... >>>> 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 >>>> 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 >>>> ... >>>> 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 >>>> 0xf34ca241: add $0x80,%esp >>>> 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 >>>> 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 >>>> ... >>>> 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 >>>> ... >>>> >>>> The stack offsets for the vmovdqu instructions are wrong, causing the XMM registers to contain random values after a safepoint. The problem is that "additional_frame_bytes" is added to the stack offset although the stack pointer is incremented just before: >>>> >>>> 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM registers >>>> >>>> The regression test fails with "Test failed: array[0] = 1973.0 but should be 10.000" because the vectorized loop returns a wrong result. >>>> >>>> I spotted and fixed the following other problems: >>>> - the vmovdqu instructions should be emitted before restoring YMM and >>>> ZMM because they zero the upper part of the XMM registers (i.e. >>>> YMM/ZMM) >>>> - if 'UseAVX > 2' is set/available, we save the ZMM registers as well >>>> but we do not increment 'additional_frame_words' accordingly (we need >>>> another 8*32 bytes of stack space) >>>> >>>> Unfortunately, I don't have access to a CPU with the AVX-512 instruction set to test the "UseAVX > 2" related changes. Michael, could you verify the changes? >>>> >>>> The problems were introduced by the fix for JDK-8142980. >>>> >>>> Thanks, >>>> Tobias >>>> From tobias.hartmann at oracle.com Tue Feb 2 18:00:06 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 2 Feb 2016 19:00:06 +0100 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: <56B0EE73.9000304@oracle.com> References: <56AB7436.7020302@oracle.com> <56ABC001.6080302@oracle.com> <56AF4268.4080704@oracle.com> <56B0668C.2000405@oracle.com> <56B0EE73.9000304@oracle.com> Message-ID: <56B0EEA6.9040009@oracle.com> Thanks, Vladimir. Best, Tobias On 02.02.2016 18:59, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 2/2/16 12:19 AM, Tobias Hartmann wrote: >> Hi Michael, >> >> On 01.02.2016 19:50, Berg, Michael C wrote: >>> Tobias, since it works everywhere now, let us proceed. >>> The code is ok in its current form. >> >> Okay, here is the new webrev, including the fixed asserts: >> http://cr.openjdk.java.net/~thartmann/8148490/webrev.01/ >> >> On 29.01.2016 20:39, Vladimir Kozlov wrote: >>> Originally we could have vectors even with only 64bit XMM registers. MaxVectorSize and UseAVX can be set on command line - what happens in such case? No vectorization? >> >> Yes, we hit the assert if MaxVectorSize < 64 is set. This is fixed with above's changes. >> >> Thanks, >> Tobias >> >>> >>> Thanks, >>> Michael >>> >>> -----Original Message----- >>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >>> Sent: Monday, February 01, 2016 3:33 AM >>> To: Berg, Michael C; Vladimir Kozlov >>> Cc: hotspot-compiler-dev at openjdk.java.net >>> Subject: Re: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit >>> >>> Thanks Vladimir and Michael, for the reviews. >>> >>> Michael wrote (off-thread): >>>> Tobias, I might take the restore code a different direction. Would it be ok if I handed you code back which has an offset based approach that makes the direction of restores no longer dependent upon the current stack? >>> >>> I will wait for his changes and then send out a new RFR. >>> >>> Best, >>> Tobias >>> >>> On 29.01.2016 23:28, Berg, Michael C wrote: >>>> Tobias/Vladimir: >>>> >>>> I would change the two asserts to in the 64bit code to make the check clear: >>>> >>>> assert(UseAVX > 0, "up to 512bit vectors are supported with EVEX"); >>>> assert(MaxVectorSize <= 64, "up to 512bit vectors are supported >>>> now"); >>>> >>>> As for testing with the patch applied to hotspot on a current jdk(01-29-16): >>>> >>>> Windows sde 32-bit: skx - pass, also ran and passed part of >>>> specjvm2008 Windows 32-bit: hsw - pass, also ran and passed all of >>>> specjvm2008 Windows sde 64-bit: skx - pass, also ran and passed part >>>> of specjvm2008 Windows 64-bit: hsw -pass, also ran and passed all of >>>> specjvm2008 : caveat Linux on skx: 32-bit - pass, also ran and passed >>>> all of specjvm2008 Linux on skx:64-bit - pass, also ran and passed all >>>> of specjvm2008 >>>> >>>> We should proceed with checkin in the changelist after the usual testing. >>>> >>>> Note: The above tests were done with the asserts changed on windows >>>> only. The 64bit changes are mostly cosmetic. It's the change to the additional_frame_bytes that makes it correct, we used equivalent constants in the stack adjustment beforehand, they had not been mapped to the movdqu for the non-vector case for a few iterations on the file. Early on I did have that code though. >>>> >>>> Caveat: xml.transform fails with the changelist and without, I checked this against a 12-21-15 built jdk which is 1 month old, so we have a new bug that is causing this app to fail as well (on windows for 64bit) on hsw. >>>> I checked recent jbs traffic, the occurrence does not appear to be tracked at this time. >>>> >>>> -Michael >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Friday, January 29, 2016 11:40 AM >>>> To: hotspot-compiler-dev at openjdk.java.net >>>> Cc: Berg, Michael C >>>> Subject: Re: [9] RFR(S): 8148490: >>>> RegisterSaver::restore_live_registers() fails to restore xmm registers >>>> on 32 bit >>>> >>>> Tobias, please verify that 64-bit code works correctly. >>>> About 32-bit code. >>>> >>>> Please verify correctness of next asserts: >>>> >>>> assert(UseAVX > 0, "512bit vectors are supported only with EVEX"); >>>> assert(MaxVectorSize == 64, "only 512bit vectors are supported >>>> now"); >>>> >>>> Originally we could have vectors even with only 64bit XMM registers. >>>> MaxVectorSize and UseAVX can be set on command line >>>> - what happens in such case? No vectorization? >>>> >>>> May be it is done because we save whole 128bit XMM always. Still MaxVectorSize == 64 condition is strange. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/29/16 6:16 AM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch: >>>>> https://bugs.openjdk.java.net/browse/JDK-8148490 >>>>> http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ >>>>> >>>>> RegisterSaver::save_live_registers() and RegisterSaver::restore_live_registers() are used by the safepoint handling code to save and restore registers. The following code is emitted to save and restore XMM/YMM registers on 32 bit: >>>>> >>>>> Save: >>>>> ... >>>>> 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) >>>>> 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) >>>>> ... >>>>> 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) >>>>> 0xf34ca176: sub $0x80,%esp >>>>> 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) >>>>> 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) >>>>> ... >>>>> 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) >>>>> ... >>>>> >>>>> Restore: >>>>> ... >>>>> 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 >>>>> 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 >>>>> ... >>>>> 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 >>>>> 0xf34ca241: add $0x80,%esp >>>>> 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 >>>>> 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 >>>>> ... >>>>> 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 >>>>> ... >>>>> >>>>> The stack offsets for the vmovdqu instructions are wrong, causing the XMM registers to contain random values after a safepoint. The problem is that "additional_frame_bytes" is added to the stack offset although the stack pointer is incremented just before: >>>>> >>>>> 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM registers >>>>> >>>>> The regression test fails with "Test failed: array[0] = 1973.0 but should be 10.000" because the vectorized loop returns a wrong result. >>>>> >>>>> I spotted and fixed the following other problems: >>>>> - the vmovdqu instructions should be emitted before restoring YMM and >>>>> ZMM because they zero the upper part of the XMM registers (i.e. >>>>> YMM/ZMM) >>>>> - if 'UseAVX > 2' is set/available, we save the ZMM registers as well >>>>> but we do not increment 'additional_frame_words' accordingly (we need >>>>> another 8*32 bytes of stack space) >>>>> >>>>> Unfortunately, I don't have access to a CPU with the AVX-512 instruction set to test the "UseAVX > 2" related changes. Michael, could you verify the changes? >>>>> >>>>> The problems were introduced by the fix for JDK-8142980. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> From vladimir.kozlov at oracle.com Tue Feb 2 18:03:55 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Feb 2016 10:03:55 -0800 Subject: RFR(XXS): 8148864: Quarantine CompilerControl tests In-Reply-To: References: Message-ID: <56B0EF8B.3050201@oracle.com> Good. Thanks, Vladimir On 2/2/16 9:52 AM, Pavel Punegov wrote: > Please review the fix that quarantines tests affected by JDK-8148563 > and JDK-8140354 > > webrev: http://cr.openjdk.java.net/~ppunegov/8148864/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8148864 > > ? Thanks, > Pavel Punegov > From vladimir.kozlov at oracle.com Tue Feb 2 18:04:42 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Feb 2016 10:04:42 -0800 Subject: RFR(XXS): 8148509: CompilerControl: check all inlining events In-Reply-To: <590ABD60-D1D9-40B2-96D5-CE087E596D5E@oracle.com> References: <590ABD60-D1D9-40B2-96D5-CE087E596D5E@oracle.com> Message-ID: <56B0EFBA.9010206@oracle.com> Okay. Thanks, Vladimir On 2/2/16 7:29 AM, Pavel Punegov wrote: > Hi, > > please review the following small fix. It changes access for CompilerWhiteBoxTest?s constant BACKEDGE_THRESHOLD. > It is required for the closed part of the fix that should use this constant. > > webrev: http://cr.openjdk.java.net/~ppunegov/8148509/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8148509 > > ? Thanks, > Pavel Punegov > From michael.c.berg at intel.com Tue Feb 2 19:54:49 2016 From: michael.c.berg at intel.com (Berg, Michael C) Date: Tue, 2 Feb 2016 19:54:49 +0000 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: <56B0668C.2000405@oracle.com> References: <56AB7436.7020302@oracle.com> <56ABC001.6080302@oracle.com> <56AF4268.4080704@oracle.com> <56B0668C.2000405@oracle.com> Message-ID: Looks good. -Michael -----Original Message----- From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] Sent: Tuesday, February 02, 2016 12:19 AM To: Berg, Michael C; Vladimir Kozlov Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit Hi Michael, On 01.02.2016 19:50, Berg, Michael C wrote: > Tobias, since it works everywhere now, let us proceed. > The code is ok in its current form. Okay, here is the new webrev, including the fixed asserts: http://cr.openjdk.java.net/~thartmann/8148490/webrev.01/ On 29.01.2016 20:39, Vladimir Kozlov wrote: > Originally we could have vectors even with only 64bit XMM registers. MaxVectorSize and UseAVX can be set on command line - what happens in such case? No vectorization? Yes, we hit the assert if MaxVectorSize < 64 is set. This is fixed with above's changes. Thanks, Tobias > > Thanks, > Michael > > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Monday, February 01, 2016 3:33 AM > To: Berg, Michael C; Vladimir Kozlov > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: [9] RFR(S): 8148490: > RegisterSaver::restore_live_registers() fails to restore xmm registers > on 32 bit > > Thanks Vladimir and Michael, for the reviews. > > Michael wrote (off-thread): >> Tobias, I might take the restore code a different direction. Would it be ok if I handed you code back which has an offset based approach that makes the direction of restores no longer dependent upon the current stack? > > I will wait for his changes and then send out a new RFR. > > Best, > Tobias > > On 29.01.2016 23:28, Berg, Michael C wrote: >> Tobias/Vladimir: >> >> I would change the two asserts to in the 64bit code to make the check clear: >> >> assert(UseAVX > 0, "up to 512bit vectors are supported with EVEX"); >> assert(MaxVectorSize <= 64, "up to 512bit vectors are supported >> now"); >> >> As for testing with the patch applied to hotspot on a current jdk(01-29-16): >> >> Windows sde 32-bit: skx - pass, also ran and passed part of >> specjvm2008 Windows 32-bit: hsw - pass, also ran and passed all of >> specjvm2008 Windows sde 64-bit: skx - pass, also ran and passed part >> of specjvm2008 Windows 64-bit: hsw -pass, also ran and passed all of >> specjvm2008 : caveat Linux on skx: 32-bit - pass, also ran and passed >> all of specjvm2008 Linux on skx:64-bit - pass, also ran and passed >> all of specjvm2008 >> >> We should proceed with checkin in the changelist after the usual testing. >> >> Note: The above tests were done with the asserts changed on windows >> only. The 64bit changes are mostly cosmetic. It's the change to the additional_frame_bytes that makes it correct, we used equivalent constants in the stack adjustment beforehand, they had not been mapped to the movdqu for the non-vector case for a few iterations on the file. Early on I did have that code though. >> >> Caveat: xml.transform fails with the changelist and without, I checked this against a 12-21-15 built jdk which is 1 month old, so we have a new bug that is causing this app to fail as well (on windows for 64bit) on hsw. >> I checked recent jbs traffic, the occurrence does not appear to be tracked at this time. >> >> -Michael >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Friday, January 29, 2016 11:40 AM >> To: hotspot-compiler-dev at openjdk.java.net >> Cc: Berg, Michael C >> Subject: Re: [9] RFR(S): 8148490: >> RegisterSaver::restore_live_registers() fails to restore xmm >> registers on 32 bit >> >> Tobias, please verify that 64-bit code works correctly. >> About 32-bit code. >> >> Please verify correctness of next asserts: >> >> assert(UseAVX > 0, "512bit vectors are supported only with EVEX"); >> assert(MaxVectorSize == 64, "only 512bit vectors are supported >> now"); >> >> Originally we could have vectors even with only 64bit XMM registers. >> MaxVectorSize and UseAVX can be set on command line >> - what happens in such case? No vectorization? >> >> May be it is done because we save whole 128bit XMM always. Still MaxVectorSize == 64 condition is strange. >> >> Thanks, >> Vladimir >> >> On 1/29/16 6:16 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8148490 >>> http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ >>> >>> RegisterSaver::save_live_registers() and RegisterSaver::restore_live_registers() are used by the safepoint handling code to save and restore registers. The following code is emitted to save and restore XMM/YMM registers on 32 bit: >>> >>> Save: >>> ... >>> 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) >>> 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) >>> ... >>> 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) >>> 0xf34ca176: sub $0x80,%esp >>> 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) >>> 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) >>> ... >>> 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) >>> ... >>> >>> Restore: >>> ... >>> 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 >>> 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 >>> ... >>> 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 >>> 0xf34ca241: add $0x80,%esp >>> 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 >>> 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 >>> ... >>> 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 >>> ... >>> >>> The stack offsets for the vmovdqu instructions are wrong, causing the XMM registers to contain random values after a safepoint. The problem is that "additional_frame_bytes" is added to the stack offset although the stack pointer is incremented just before: >>> >>> 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM registers >>> >>> The regression test fails with "Test failed: array[0] = 1973.0 but should be 10.000" because the vectorized loop returns a wrong result. >>> >>> I spotted and fixed the following other problems: >>> - the vmovdqu instructions should be emitted before restoring YMM >>> and ZMM because they zero the upper part of the XMM registers (i.e. >>> YMM/ZMM) >>> - if 'UseAVX > 2' is set/available, we save the ZMM registers as >>> well but we do not increment 'additional_frame_words' accordingly >>> (we need another 8*32 bytes of stack space) >>> >>> Unfortunately, I don't have access to a CPU with the AVX-512 instruction set to test the "UseAVX > 2" related changes. Michael, could you verify the changes? >>> >>> The problems were introduced by the fix for JDK-8142980. >>> >>> Thanks, >>> Tobias >>> From tobias.hartmann at oracle.com Wed Feb 3 08:02:54 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 3 Feb 2016 09:02:54 +0100 Subject: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit In-Reply-To: References: <56AB7436.7020302@oracle.com> <56ABC001.6080302@oracle.com> <56AF4268.4080704@oracle.com> <56B0668C.2000405@oracle.com> Message-ID: <56B1B42E.9040900@oracle.com> Thanks, Michael. Best, Tobias On 02.02.2016 20:54, Berg, Michael C wrote: > Looks good. > > -Michael > > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Tuesday, February 02, 2016 12:19 AM > To: Berg, Michael C; Vladimir Kozlov > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: [9] RFR(S): 8148490: RegisterSaver::restore_live_registers() fails to restore xmm registers on 32 bit > > Hi Michael, > > On 01.02.2016 19:50, Berg, Michael C wrote: >> Tobias, since it works everywhere now, let us proceed. >> The code is ok in its current form. > > Okay, here is the new webrev, including the fixed asserts: > http://cr.openjdk.java.net/~thartmann/8148490/webrev.01/ > > On 29.01.2016 20:39, Vladimir Kozlov wrote: >> Originally we could have vectors even with only 64bit XMM registers. MaxVectorSize and UseAVX can be set on command line - what happens in such case? No vectorization? > > Yes, we hit the assert if MaxVectorSize < 64 is set. This is fixed with above's changes. > > Thanks, > Tobias > >> >> Thanks, >> Michael >> >> -----Original Message----- >> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >> Sent: Monday, February 01, 2016 3:33 AM >> To: Berg, Michael C; Vladimir Kozlov >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: [9] RFR(S): 8148490: >> RegisterSaver::restore_live_registers() fails to restore xmm registers >> on 32 bit >> >> Thanks Vladimir and Michael, for the reviews. >> >> Michael wrote (off-thread): >>> Tobias, I might take the restore code a different direction. Would it be ok if I handed you code back which has an offset based approach that makes the direction of restores no longer dependent upon the current stack? >> >> I will wait for his changes and then send out a new RFR. >> >> Best, >> Tobias >> >> On 29.01.2016 23:28, Berg, Michael C wrote: >>> Tobias/Vladimir: >>> >>> I would change the two asserts to in the 64bit code to make the check clear: >>> >>> assert(UseAVX > 0, "up to 512bit vectors are supported with EVEX"); >>> assert(MaxVectorSize <= 64, "up to 512bit vectors are supported >>> now"); >>> >>> As for testing with the patch applied to hotspot on a current jdk(01-29-16): >>> >>> Windows sde 32-bit: skx - pass, also ran and passed part of >>> specjvm2008 Windows 32-bit: hsw - pass, also ran and passed all of >>> specjvm2008 Windows sde 64-bit: skx - pass, also ran and passed part >>> of specjvm2008 Windows 64-bit: hsw -pass, also ran and passed all of >>> specjvm2008 : caveat Linux on skx: 32-bit - pass, also ran and passed >>> all of specjvm2008 Linux on skx:64-bit - pass, also ran and passed >>> all of specjvm2008 >>> >>> We should proceed with checkin in the changelist after the usual testing. >>> >>> Note: The above tests were done with the asserts changed on windows >>> only. The 64bit changes are mostly cosmetic. It's the change to the additional_frame_bytes that makes it correct, we used equivalent constants in the stack adjustment beforehand, they had not been mapped to the movdqu for the non-vector case for a few iterations on the file. Early on I did have that code though. >>> >>> Caveat: xml.transform fails with the changelist and without, I checked this against a 12-21-15 built jdk which is 1 month old, so we have a new bug that is causing this app to fail as well (on windows for 64bit) on hsw. >>> I checked recent jbs traffic, the occurrence does not appear to be tracked at this time. >>> >>> -Michael >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Friday, January 29, 2016 11:40 AM >>> To: hotspot-compiler-dev at openjdk.java.net >>> Cc: Berg, Michael C >>> Subject: Re: [9] RFR(S): 8148490: >>> RegisterSaver::restore_live_registers() fails to restore xmm >>> registers on 32 bit >>> >>> Tobias, please verify that 64-bit code works correctly. >>> About 32-bit code. >>> >>> Please verify correctness of next asserts: >>> >>> assert(UseAVX > 0, "512bit vectors are supported only with EVEX"); >>> assert(MaxVectorSize == 64, "only 512bit vectors are supported >>> now"); >>> >>> Originally we could have vectors even with only 64bit XMM registers. >>> MaxVectorSize and UseAVX can be set on command line >>> - what happens in such case? No vectorization? >>> >>> May be it is done because we save whole 128bit XMM always. Still MaxVectorSize == 64 condition is strange. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/29/16 6:16 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch: >>>> https://bugs.openjdk.java.net/browse/JDK-8148490 >>>> http://cr.openjdk.java.net/~thartmann/8148490/webrev.00/ >>>> >>>> RegisterSaver::save_live_registers() and RegisterSaver::restore_live_registers() are used by the safepoint handling code to save and restore registers. The following code is emitted to save and restore XMM/YMM registers on 32 bit: >>>> >>>> Save: >>>> ... >>>> 0xf34ca12e: vmovdqu %xmm0,0xb0(%esp) >>>> 0xf34ca137: vmovdqu %xmm1,0xc0(%esp) >>>> ... >>>> 0xf34ca16d: vmovdqu %xmm7,0x120(%esp) >>>> 0xf34ca176: sub $0x80,%esp >>>> 0xf34ca17c: vextractf128 $0x1,%ymm0,(%esp) >>>> 0xf34ca183: vextractf128 $0x1,%ymm1,0x10(%esp) >>>> ... >>>> 0xf34ca1b3: vextractf128 $0x1,%ymm7,0x70(%esp) >>>> ... >>>> >>>> Restore: >>>> ... >>>> 0xf34ca202: vinsertf128 $0x1,(%esp),%ymm0,%ymm0 >>>> 0xf34ca209: vinsertf128 $0x1,0x10(%esp),%ymm1,%ymm1 >>>> ... >>>> 0xf34ca239: vinsertf128 $0x1,0x70(%esp),%ymm7,%ymm7 >>>> 0xf34ca241: add $0x80,%esp >>>> 0xf34ca247: vmovdqu 0x130(%esp),%xmm0 >>>> 0xf34ca250: vmovdqu 0x140(%esp),%xmm1 >>>> ... >>>> 0xf34ca286: vmovdqu 0x1a0(%esp),%xmm7 >>>> ... >>>> >>>> The stack offsets for the vmovdqu instructions are wrong, causing the XMM registers to contain random values after a safepoint. The problem is that "additional_frame_bytes" is added to the stack offset although the stack pointer is incremented just before: >>>> >>>> 283 __ addptr(rsp, additional_frame_bytes); // Save upper half of YMM registers >>>> >>>> The regression test fails with "Test failed: array[0] = 1973.0 but should be 10.000" because the vectorized loop returns a wrong result. >>>> >>>> I spotted and fixed the following other problems: >>>> - the vmovdqu instructions should be emitted before restoring YMM >>>> and ZMM because they zero the upper part of the XMM registers (i.e. >>>> YMM/ZMM) >>>> - if 'UseAVX > 2' is set/available, we save the ZMM registers as >>>> well but we do not increment 'additional_frame_words' accordingly >>>> (we need another 8*32 bytes of stack space) >>>> >>>> Unfortunately, I don't have access to a CPU with the AVX-512 instruction set to test the "UseAVX > 2" related changes. Michael, could you verify the changes? >>>> >>>> The problems were introduced by the fix for JDK-8142980. >>>> >>>> Thanks, >>>> Tobias >>>> From zoltan.majo at oracle.com Wed Feb 3 08:18:22 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 3 Feb 2016 09:18:22 +0100 Subject: [9] RFR (S): 8148753: Compilation fails due to field accesses on array types In-Reply-To: <56B0E5F0.9000009@oracle.com> References: <56AF7645.4050409@oracle.com> <56AF9938.1020403@oracle.com> <56B0C5C7.5070903@oracle.com> <56B0E5F0.9000009@oracle.com> Message-ID: <56B1B7CE.7040406@oracle.com> On 02/02/2016 06:22 PM, Vladimir Kozlov wrote: > Very good. Thank you, Vladimir! Best regards, Zoltan > > Thanks, > Vladimir > > On 2/2/16 7:05 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> thank you for the feedback! >> >> On 02/01/2016 06:43 PM, Vladimir Kozlov wrote: >>> Extend comment: >>> >>> + // handling in ciField::will_link. >>> >>> "and throw a java.lang.NoSuchFieldError exception (the expected >>> behavior in this case)." >>> >>> Give different name to first local 'declared_holder' and after array >>> type check do cast: >>> >>> ciInstanceKlass* declared_holder = holder->as_instance_klass(); >>> >>> then you don't need to change following code. >> >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~zmajo/8148753/webrev.01/ >> >> Thank you and best regards, >> >> >> Zoltan >>> >>> Thanks, >>> Vladimir >>> >>> On 2/1/16 7:14 AM, Zolt?n Maj? wrote: >>>> Hi, >>>> >>>> >>>> please review the patch for 8148753. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8148753 >>>> >>>> Problem: Compiling methods that access fields of array types fails. >>>> The >>>> problem is that both compilers assume that only fields of instance >>>> types >>>> (but not field of array types) can be accessed. However, an array >>>> can be >>>> also seen as an instance type, as every array is a subclass of >>>> java.lang.Object. >>>> >>>> Solution: Treat accesses to fields of array types as accesses to >>>> fields >>>> of java.lang.Object. By convention, the java.lang.Object does not have >>>> any fields. As a result, the generated code will throw a >>>> java.lang.NoSuchFieldError exception (the expected behavior in this >>>> case). >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~zmajo/8148753/webrev.00/ >>>> >>>> Testing: >>>> - JPRT; >>>> - all JTREG hotspot/compiler tests on all supported platforms. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >> From jamsheed.c.m at oracle.com Wed Feb 3 09:56:50 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 3 Feb 2016 15:26:50 +0530 Subject: RFR(XS): 8143897 :Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same In-Reply-To: <56AAB7CA.4000604@oracle.com> References: <56AA3ED7.4030407@oracle.com> <844981E3-4C91-4D52-BBDB-450D055C2599@oracle.com> <56AA7A3F.6040800@oracle.com> <56AAB7CA.4000604@oracle.com> Message-ID: <56B1CEE2.40402@oracle.com> Hi Vladimir, Chris, On 1/29/2016 6:22 AM, Vladimir Kozlov wrote: > On 1/28/16 12:29 PM, Jamsheed C m wrote: >> >> >> On 1/29/2016 12:15 AM, Christian Thalinger wrote: >>> if (count() < cache_size) { >>> set_pc_at(count(),addr); >>> set_handler_at(count(), handler); >>> >>> Shouldn?t we read count() only once into a local variable to rule >>> any odd race bugs down the road? > > +1. As I understand, Chris is suggesting to do it in addition to > storestore barrier. I have made the suggested change. http://cr.openjdk.java.net/~thartmann/8143897/webrev.01/ Best Regards, Jamsheed > > Do we have other similar code? > > Thanks, > Vladimir > >> >> write to cache is mutex lock protected. so this code is safe. >> >> Issue is seen in weak memory order machines. lockless read of >> exception cache values fails as writes in cache get >> reordered. >> >> Best Regards, >> Jamsheed >>> >>>> On Jan 28, 2016, at 5:16 PM, Jamsheed C m >>>> wrote: >>>> >>>> Hi, >>>> >>>> Please review the fix made for issue >>>> >>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8143897 >>>> web rev: http://cr.openjdk.java.net/~thartmann/8143897/webrev.00/ >>>> >>>> Unit tests: As its hard, none >>>> >>>> Other tests: jprt. >>>> >>>> Description of the issue: >>>> A valid pc match in exception cache returning an invalid handler >>>> makes assert to fail. >>>> This happens as ExceptionCache reads are lock free access. >>>> >>>> As a fix for this i have put a storestore mem barrier before the >>>> count is updated. >>>> >>>> Best Regards, >>>> Jamsheed >> From roland.westrelin at oracle.com Wed Feb 3 11:21:13 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Feb 2016 12:21:13 +0100 Subject: RFR(S): 8137049: Code quality: reducing an trivial integer loop does not produce an optimal code Message-ID: <2667A7D5-0F10-4E47-80B4-C34954DD4112@oracle.com> http://cr.openjdk.java.net/~roland/8137049/webrev.00/ In this loop: for (int i = 0; i < ops; ++i) { the loop is guarded by: if (0 < ops) { which is canonicalized by BoolNode::Ideal() ("Move constants to the right of compare's to canonicalize?) and the code in IdealLoopTree::policy_do_remove_empty_loop() doesn?t recognize the guard shape and peels one iteration of the loop. Roland. From tobias.hartmann at oracle.com Wed Feb 3 11:26:18 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 3 Feb 2016 12:26:18 +0100 Subject: [9] RFR(S): 8148751: [TESTBUG] compiler/whitebox/AllocationCodeBlobTest.java fails due to unexpected code cache allocation Message-ID: <56B1E3DA.4030508@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8148751 http://cr.openjdk.java.net/~thartmann/8148751/webrev.00/ The test fails with "free shouldn't increase memory usage" because it doesn't expect the code cache usage to increase after a WhiteBox.freeCodeBlob(). The problem is that although the test disables compilation with "-XX:CompileCommand=compileonly,null::*", resolving of invokedynamic instructions may still trigger creation of method handle intrinsics in the code cache and therefore increase the code cache usage. In this case, the call to Asserts.assertLTE() immediately after the usage measurement triggers compilation: 538 33 n 0 java.lang.invoke.MethodHandle::linkToStatic(JJL)L (native) (static) 539 34 n 0 java.lang.invoke.MethodHandle::invokeBasic(JJ)L (native) 539 35 n 0 java.lang.invoke.MethodHandle::linkToSpecial(LJJL)L (native) (static) The fix is to first do all the measurements and then check the results. Like this, we avoid interference in-between the measurements. Thanks, Tobias From roland.westrelin at oracle.com Wed Feb 3 12:01:57 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Feb 2016 13:01:57 +0100 Subject: RFR(S): 8143542: C2 doesn't eliminate identical checks Message-ID: <87A6AE42-5325-4CE7-9A7F-B0E9EAAE29D8@oracle.com> http://cr.openjdk.java.net/~roland/8143542/webrev.00/ The test case: https://bugs.openjdk.java.net/secure/attachment/55176/RedundantNullCheck.java has two identical tests one after the other: int ret = 0; if (_i != null) { ret += _i.value(); } else { ret += -1; } if (_i != null) { ret += _i.value2(); } else { ret += -1; } They can be merged. I picky backed on the split if code to achieve that. Both inlined calls have a null check and a range check. For them to fold nicely after the ifs are merged, ConstraintCastNode::dominating_cast() needs to more aggressively look for redundant casts. Roland. From aleksey.shipilev at oracle.com Wed Feb 3 12:32:05 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 3 Feb 2016 15:32:05 +0300 Subject: RFR(S): 8137049: Code quality: reducing an trivial integer loop does not produce an optimal code In-Reply-To: <2667A7D5-0F10-4E47-80B4-C34954DD4112@oracle.com> References: <2667A7D5-0F10-4E47-80B4-C34954DD4112@oracle.com> Message-ID: <56B1F345.6070608@oracle.com> On 02/03/2016 02:21 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8137049/webrev.00/ Thanks! The benchmark from the bug works as expected now. I think this micro-optimization garbles the intent: int init_idx = maybe_swapped ? 2 : 1; int limit_idx = 3 - init_idx; This seems cleaner: int init_idx = maybe_swapped ? 2 : 1; int limit_idx = maybe_swapped ? 1 : 2; Cheers, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From roland.westrelin at oracle.com Wed Feb 3 12:36:25 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Feb 2016 13:36:25 +0100 Subject: RFR(S): 8137049: Code quality: reducing an trivial integer loop does not produce an optimal code In-Reply-To: <56B1F345.6070608@oracle.com> References: <2667A7D5-0F10-4E47-80B4-C34954DD4112@oracle.com> <56B1F345.6070608@oracle.com> Message-ID: <34A6B970-2D63-4BE1-B041-6E2601E23BF0@oracle.com> >> http://cr.openjdk.java.net/~roland/8137049/webrev.00/ > > Thanks! The benchmark from the bug works as expected now. Thanks for looking at this. > I think this micro-optimization garbles the intent: > > int init_idx = maybe_swapped ? 2 : 1; > int limit_idx = 3 - init_idx; > > This seems cleaner: > > int init_idx = maybe_swapped ? 2 : 1; > int limit_idx = maybe_swapped ? 1 : 2; You?re probably right about that. I?ll follow your suggestion. Roland. From mikael.gerdin at oracle.com Wed Feb 3 13:42:07 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 3 Feb 2016 14:42:07 +0100 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <56B0E16F.5050509@redhat.com> References: <56AAA808.6090604@oracle.com> <550334AB-0A58-41A7-B00A-974EBA3F8B0B@oracle.com> <56B0C36A.5050605@oracle.com> <56B0E16F.5050509@redhat.com> Message-ID: <56B203AF.6060000@oracle.com> Hi Andrew, On 2016-02-02 18:03, Andrew Haley wrote: > On 02/02/2016 02:55 PM, Mikael Gerdin wrote: >> The barrier can only be removed if the object is never allocated. >> If the object is allocated and the field store is performed then the >> barrier must be preserved, even if the compiler can prove that no >> application thread can see the objects, a concurrent gc thread may still >> see these objects. > > This reminds me of the discussion at http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020345.html I've realized that this is becoming a bit confusing since we are in fact talking about two different uses of the word "barrier". The use I meant in my reply above is the entire "g1 post-barrier". This is further complicated by the fact that the "g1 post-barrier" does contain an instruction sequence which has the intended effect of a "StoreLoad memory barrier". I've had a look at the mail thread (and I did follow it with a cursory look when it was active). > > It removes the memory barrier after object creation if the object does > not escape. I guess this is not safe, then, because a concurrent GC > will see a partially-constructed object: the fields may not have been > zeroed and the header may not have been initialized. > > I'd like your opinion on this. I think that the reasoning in the thread is sound, and it should hold for this case as well. The one question I have is if it is possible for a safepoint to occur between *) in your case between the object initialization and the memory barrier instruction *) in this case between the object allocation and the field store with its g1 post-barrier. If there is no way a safepoint can occur in the middle of these transactions then I believe it should be safe to elide the entire "g1 post-barrier" in this case. But the reason for that is that post barriers can be elided altogether for newly allocated objects. This, however, should already be taken care of by GraphKit::g1_can_remove_post_barrier. So, given that we are emitting the "g1 post-barrier" I would say that it's not safe to remove the "memory barrier" instruction from it. Does that make sense? /Mikael > > Thanks, > > Andrew. > From roland.westrelin at oracle.com Wed Feb 3 14:15:57 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Feb 2016 15:15:57 +0100 Subject: RFR(S): 8147645: get_ctrl_no_update() code is wrong In-Reply-To: <73669E03-B560-4B00-9195-C4D03E420AA7@oracle.com> References: <77A6696F-8F4B-4023-AE58-61E2D01A8035@oracle.com> <56A92027.2070602@oracle.com> <73669E03-B560-4B00-9195-C4D03E420AA7@oracle.com> Message-ID: FTR, I pushed this change with a slightly different test case: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/796b8077f6e6/test/compiler/loopopts/TestArraysFillDeadControl.java The one from the review: http://cr.openjdk.java.net/~roland/8147645/webrev.00/test/compiler/loopopts/TestArraysFillDeadControl.java.html which was straight from the bug report would time out on windows because of the use of the graphics API. Roland. From aph at redhat.com Wed Feb 3 15:10:31 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 3 Feb 2016 15:10:31 +0000 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <56B203AF.6060000@oracle.com> References: <56AAA808.6090604@oracle.com> <550334AB-0A58-41A7-B00A-974EBA3F8B0B@oracle.com> <56B0C36A.5050605@oracle.com> <56B0E16F.5050509@redhat.com> <56B203AF.6060000@oracle.com> Message-ID: <56B21867.9050207@redhat.com> Hi, On 02/03/2016 01:42 PM, Mikael Gerdin wrote: > The one question I have is if it is possible for a safepoint to occur > between > *) in your case between the object initialization and the memory barrier > instruction > *) in this case between the object allocation and the field store with > its g1 post-barrier. > > If there is no way a safepoint can occur in the middle of these > transactions then I believe it should be safe to elide the entire "g1 > post-barrier" in this case. But the reason for that is that post > barriers can be elided altogether for newly allocated objects. > This, however, should already be taken care of by > GraphKit::g1_can_remove_post_barrier. OK. > So, given that we are emitting the "g1 post-barrier" I would say that > it's not safe to remove the "memory barrier" instruction from it. > > Does that make sense? It does, thank you. I shall try to stop worrying. :-) For what it's worth: in the java.util.concurrent list we often use "fence" for memory fence instructions and "barrier" for things like GC write barriers. Andrew. From vladimir.x.ivanov at oracle.com Wed Feb 3 16:49:09 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 3 Feb 2016 19:49:09 +0300 Subject: [9] RFR(S): 8148751: [TESTBUG] compiler/whitebox/AllocationCodeBlobTest.java fails due to unexpected code cache allocation In-Reply-To: <56B1E3DA.4030508@oracle.com> References: <56B1E3DA.4030508@oracle.com> Message-ID: <56B22F85.5040308@oracle.com> Reviewed. Best regards, Vladimir Ivanov On 2/3/16 2:26 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8148751 > http://cr.openjdk.java.net/~thartmann/8148751/webrev.00/ > > The test fails with "free shouldn't increase memory usage" because it doesn't expect the code cache usage to increase after a WhiteBox.freeCodeBlob(). The problem is that although the test disables compilation with "-XX:CompileCommand=compileonly,null::*", resolving of invokedynamic instructions may still trigger creation of method handle intrinsics in the code cache and therefore increase the code cache usage. In this case, the call to Asserts.assertLTE() immediately after the usage measurement triggers compilation: > > 538 33 n 0 java.lang.invoke.MethodHandle::linkToStatic(JJL)L (native) (static) > 539 34 n 0 java.lang.invoke.MethodHandle::invokeBasic(JJ)L (native) > 539 35 n 0 java.lang.invoke.MethodHandle::linkToSpecial(LJJL)L (native) (static) > > The fix is to first do all the measurements and then check the results. Like this, we avoid interference in-between the measurements. > > Thanks, > Tobias > From tobias.hartmann at oracle.com Wed Feb 3 16:50:02 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 3 Feb 2016 17:50:02 +0100 Subject: [9] RFR(S): 8148751: [TESTBUG] compiler/whitebox/AllocationCodeBlobTest.java fails due to unexpected code cache allocation In-Reply-To: <56B22F85.5040308@oracle.com> References: <56B1E3DA.4030508@oracle.com> <56B22F85.5040308@oracle.com> Message-ID: <56B22FBA.3070202@oracle.com> Thanks, Vladimir. Best, Tobias On 03.02.2016 17:49, Vladimir Ivanov wrote: > Reviewed. > > Best regards, > Vladimir Ivanov > > On 2/3/16 2:26 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> https://bugs.openjdk.java.net/browse/JDK-8148751 >> http://cr.openjdk.java.net/~thartmann/8148751/webrev.00/ >> >> The test fails with "free shouldn't increase memory usage" because it doesn't expect the code cache usage to increase after a WhiteBox.freeCodeBlob(). The problem is that although the test disables compilation with "-XX:CompileCommand=compileonly,null::*", resolving of invokedynamic instructions may still trigger creation of method handle intrinsics in the code cache and therefore increase the code cache usage. In this case, the call to Asserts.assertLTE() immediately after the usage measurement triggers compilation: >> >> 538 33 n 0 java.lang.invoke.MethodHandle::linkToStatic(JJL)L (native) (static) >> 539 34 n 0 java.lang.invoke.MethodHandle::invokeBasic(JJ)L (native) >> 539 35 n 0 java.lang.invoke.MethodHandle::linkToSpecial(LJJL)L (native) (static) >> >> The fix is to first do all the measurements and then check the results. Like this, we avoid interference in-between the measurements. >> >> Thanks, >> Tobias >> From aleksey.shipilev at oracle.com Wed Feb 3 16:54:21 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 3 Feb 2016 19:54:21 +0300 Subject: [9] RFR(S): 8148751: [TESTBUG] compiler/whitebox/AllocationCodeBlobTest.java fails due to unexpected code cache allocation In-Reply-To: <56B1E3DA.4030508@oracle.com> References: <56B1E3DA.4030508@oracle.com> Message-ID: <56B230BD.3070001@oracle.com> On 02/03/2016 02:26 PM, Tobias Hartmann wrote: > https://bugs.openjdk.java.net/browse/JDK-8148751 > http://cr.openjdk.java.net/~thartmann/8148751/webrev.00/ +1, thanks for fixing this. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Wed Feb 3 17:10:10 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 3 Feb 2016 18:10:10 +0100 Subject: [9] RFR(S): 8148751: [TESTBUG] compiler/whitebox/AllocationCodeBlobTest.java fails due to unexpected code cache allocation In-Reply-To: <56B230BD.3070001@oracle.com> References: <56B1E3DA.4030508@oracle.com> <56B230BD.3070001@oracle.com> Message-ID: <56B23472.3040103@oracle.com> Thanks, Aleksey. Best, Tobias On 03.02.2016 17:54, Aleksey Shipilev wrote: > On 02/03/2016 02:26 PM, Tobias Hartmann wrote: >> https://bugs.openjdk.java.net/browse/JDK-8148751 >> http://cr.openjdk.java.net/~thartmann/8148751/webrev.00/ > > +1, thanks for fixing this. > > -Aleksey > From vladimir.kozlov at oracle.com Wed Feb 3 17:45:04 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 3 Feb 2016 09:45:04 -0800 Subject: RFR(S): 8137049: Code quality: reducing an trivial integer loop does not produce an optimal code In-Reply-To: <34A6B970-2D63-4BE1-B041-6E2601E23BF0@oracle.com> References: <2667A7D5-0F10-4E47-80B4-C34954DD4112@oracle.com> <56B1F345.6070608@oracle.com> <34A6B970-2D63-4BE1-B041-6E2601E23BF0@oracle.com> Message-ID: <56B23CA0.90007@oracle.com> Good. Thanks, Vladimir On 2/3/16 4:36 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8137049/webrev.00/ >> >> Thanks! The benchmark from the bug works as expected now. > > Thanks for looking at this. > >> I think this micro-optimization garbles the intent: >> >> int init_idx = maybe_swapped ? 2 : 1; >> int limit_idx = 3 - init_idx; >> >> This seems cleaner: >> >> int init_idx = maybe_swapped ? 2 : 1; >> int limit_idx = maybe_swapped ? 1 : 2; > > You?re probably right about that. I?ll follow your suggestion. > > Roland. > From vladimir.kozlov at oracle.com Wed Feb 3 18:00:26 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 3 Feb 2016 10:00:26 -0800 Subject: RFR(S): 8143542: C2 doesn't eliminate identical checks In-Reply-To: <87A6AE42-5325-4CE7-9A7F-B0E9EAAE29D8@oracle.com> References: <87A6AE42-5325-4CE7-9A7F-B0E9EAAE29D8@oracle.com> Message-ID: <56B2403A.2000400@oracle.com> Yes, this looks good. Thanks, Vladimir On 2/3/16 4:01 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8143542/webrev.00/ > > The test case: > > https://bugs.openjdk.java.net/secure/attachment/55176/RedundantNullCheck.java > > has two identical tests one after the other: > > int ret = 0; > if (_i != null) { > ret += _i.value(); > } else { > ret += -1; > } > if (_i != null) { > ret += _i.value2(); > } else { > ret += -1; > } > > They can be merged. I picky backed on the split if code to achieve that. Both inlined calls have a null check and a range check. For them to fold nicely after the ifs are merged, ConstraintCastNode::dominating_cast() needs to more aggressively look for redundant casts. > > Roland. > From vladimir.kozlov at oracle.com Wed Feb 3 18:01:39 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 3 Feb 2016 10:01:39 -0800 Subject: RFR(XS): 8143897 :Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same In-Reply-To: <56B1CEE2.40402@oracle.com> References: <56AA3ED7.4030407@oracle.com> <844981E3-4C91-4D52-BBDB-450D055C2599@oracle.com> <56AA7A3F.6040800@oracle.com> <56AAB7CA.4000604@oracle.com> <56B1CEE2.40402@oracle.com> Message-ID: <56B24083.3060709@oracle.com> Looks good. Thanks, Vladimir On 2/3/16 1:56 AM, Jamsheed C m wrote: > Hi Vladimir, Chris, > > On 1/29/2016 6:22 AM, Vladimir Kozlov wrote: >> On 1/28/16 12:29 PM, Jamsheed C m wrote: >>> >>> >>> On 1/29/2016 12:15 AM, Christian Thalinger wrote: >>>> if (count() < cache_size) { >>>> set_pc_at(count(),addr); >>>> set_handler_at(count(), handler); >>>> >>>> Shouldn?t we read count() only once into a local variable to rule any odd race bugs down the road? >> >> +1. As I understand, Chris is suggesting to do it in addition to storestore barrier. > I have made the suggested change. > http://cr.openjdk.java.net/~thartmann/8143897/webrev.01/ > > Best Regards, > Jamsheed > >> >> Do we have other similar code? >> >> Thanks, >> Vladimir >> >>> >>> write to cache is mutex lock protected. so this code is safe. >>> >>> Issue is seen in weak memory order machines. lockless read of exception cache values fails as writes in cache get >>> reordered. >>> >>> Best Regards, >>> Jamsheed >>>> >>>>> On Jan 28, 2016, at 5:16 PM, Jamsheed C m wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review the fix made for issue >>>>> >>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8143897 >>>>> web rev: http://cr.openjdk.java.net/~thartmann/8143897/webrev.00/ >>>>> >>>>> Unit tests: As its hard, none >>>>> >>>>> Other tests: jprt. >>>>> >>>>> Description of the issue: >>>>> A valid pc match in exception cache returning an invalid handler makes assert to fail. >>>>> This happens as ExceptionCache reads are lock free access. >>>>> >>>>> As a fix for this i have put a storestore mem barrier before the count is updated. >>>>> >>>>> Best Regards, >>>>> Jamsheed >>> > From christian.thalinger at oracle.com Wed Feb 3 19:42:45 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 3 Feb 2016 11:42:45 -0800 Subject: RFR: 8148507: [JVMCI] mitigate deadlocks related to JVMCI compiler under -Xbatch In-Reply-To: References: <845F1D56-3194-49AE-95C1-79545F8C50AC@oracle.com> Message-ID: <3F2DB53D-5308-4745-97F6-7EF35DF99A52@oracle.com> There was some discussion in the bug report but I seems like we are going to integrate this change. > On Jan 31, 2016, at 5:48 AM, Christian Thalinger wrote: > > Looks good. > >> On Jan 29, 2016, at 4:34 PM, Doug Simon wrote: >> >> Please review this small change to further mitigate deadlocks that can be caused by JVMCI when BackgroundCompilation is disabled. >> >> https://bugs.openjdk.java.net/browse/JDK-8148507 >> http://cr.openjdk.java.net/~dnsimon/8148507 >> >> -Doug > From vladimir.kozlov at oracle.com Wed Feb 3 21:30:08 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 3 Feb 2016 13:30:08 -0800 Subject: RFR(XS): 8148747 - [TESTBUG] runtime/Unsafe/AllocateMemory.java fails with OOM during compilation In-Reply-To: <040a01d15ec6$4df08940$e9d19bc0$@oracle.com> References: <3fcc01d15d32$ed7e7250$c87b56f0$@oracle.com> <56AFCD4F.3090205@oracle.com> <040a01d15ec6$4df08940$e9d19bc0$@oracle.com> Message-ID: <56B27160.2020007@oracle.com> On 2/3/16 1:03 PM, Christian Tornqvist wrote: > Hi Vladimir, > >> This means these tests will not be run in Compiler nightlies - we use > -Xcomp. Are you sure you want that? >> On other hand these tests are not designed to use compilers (no loops, no > hot methods). May be you should run them with -Xint then? > > The purpose of this test is to ensure that the unsafe.allocateMemory() > method works correctly, running this with -Xcomp is waste of time and > doesn't give us any additional information. If this means that it's not > running in the compiler repo, then I'm fine with that. > Our tests should as much as possible be run as any normal Java user would > run their programs, that means not specifying -Xint or -Xcomp. This way you only test one component of JVM (runtime). Which is reasonable since it is runtime test. But java users can easily have unsafe.allocateMemory() in a hot code which will be JIT compiled. And if JIT produces an incorrect code then we will fail to catch the problem since we don't have test for it. -Xcomp is simple short cut to invoke and test JIT compilers for tests which are not written to trigger JIT compilation. Thanks, Vladimir > > Thanks, > Christian > > -----Original Message----- > From: hotspot-runtime-dev > [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Vladimir > Kozlov > Sent: Monday, February 1, 2016 4:26 PM > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(XS): 8148747 - [TESTBUG] runtime/Unsafe/AllocateMemory.java > fails with OOM during compilation > > This means these tests will not be run in Compiler nightlies - we use > -Xcomp. Are you sure you want that? > > On other hand these tests are not designed to use compilers (no loops, no > hot methods). May be you should run them with -Xint then? > > Thanks, > Vladimir > > On 2/1/16 12:55 PM, Christian Tornqvist wrote: >> Hi everyone, >> >> >> >> When running with -Xcomp, the compiler consumes more memory than it >> used too. The value for MallocMaxTestWords passed to this test has >> already been increased once and will most likely continue to be a >> problem in the future when running with -Xcomp. >> >> >> >> Running with -Xcomp doesn't add any value to these tests, so the easy >> fix that is also future proof is to not run the tests when the JVM is >> launched with -Xcomp. >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8148747/webrev.00/ >> >> >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8148747 >> >> >> >> Thanks, >> >> Christian >> > From chris.plummer at oracle.com Thu Feb 4 07:20:20 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 3 Feb 2016 23:20:20 -0800 Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1 Message-ID: <56B2FBB4.70407@oracle.com> Hello, Please review the following for removing Method::_method_data when only supporting C1 (or more specifically, when not supporting C2 or JVMCI). This will help reduce dynamic footprint usage for the minimal VM. As part of this fix, ProfileInterperter is forced to false unless C2 or JVMCI is supported. This was mainly done to avoid crashes if it is turned on and Method::_method_data has been excluded, but also because it is not useful except to C2 or JVMCI. Webrev: http://cr.openjdk.java.net/~cjplummer/8147978/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8147978 Test with JPRT -testset hotspot. thanks, Chris From doug.simon at oracle.com Thu Feb 4 08:32:24 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 4 Feb 2016 09:32:24 +0100 Subject: RFR (XS): 8148981: remove ResolvedJavaType.getClassFilePath() Message-ID: <37366705-6BF2-4CD6-B4E3-CA827650B0B7@oracle.com> This method is not used and has a test causing problems for Jake integration (JDK-8148810). https://bugs.openjdk.java.net/browse/JDK-8148981 http://cr.openjdk.java.net/~dnsimon/8148981 -Doug From jamsheed.c.m at oracle.com Thu Feb 4 09:04:53 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 4 Feb 2016 14:34:53 +0530 Subject: RFR(XS): 8143897 :Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same In-Reply-To: <56B24083.3060709@oracle.com> References: <56AA3ED7.4030407@oracle.com> <844981E3-4C91-4D52-BBDB-450D055C2599@oracle.com> <56AA7A3F.6040800@oracle.com> <56AAB7CA.4000604@oracle.com> <56B1CEE2.40402@oracle.com> <56B24083.3060709@oracle.com> Message-ID: <56B31435.7020607@oracle.com> Thanks Vladimir. Best Regards, Jamsheed On 2/3/2016 11:31 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 2/3/16 1:56 AM, Jamsheed C m wrote: >> Hi Vladimir, Chris, >> >> On 1/29/2016 6:22 AM, Vladimir Kozlov wrote: >>> On 1/28/16 12:29 PM, Jamsheed C m wrote: >>>> >>>> >>>> On 1/29/2016 12:15 AM, Christian Thalinger wrote: >>>>> if (count() < cache_size) { >>>>> set_pc_at(count(),addr); >>>>> set_handler_at(count(), handler); >>>>> >>>>> Shouldn?t we read count() only once into a local variable to rule >>>>> any odd race bugs down the road? >>> >>> +1. As I understand, Chris is suggesting to do it in addition to >>> storestore barrier. >> I have made the suggested change. >> http://cr.openjdk.java.net/~thartmann/8143897/webrev.01/ >> >> Best Regards, >> Jamsheed >> >>> >>> Do we have other similar code? >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> write to cache is mutex lock protected. so this code is safe. >>>> >>>> Issue is seen in weak memory order machines. lockless read of >>>> exception cache values fails as writes in cache get >>>> reordered. >>>> >>>> Best Regards, >>>> Jamsheed >>>>> >>>>>> On Jan 28, 2016, at 5:16 PM, Jamsheed C m >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the fix made for issue >>>>>> >>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8143897 >>>>>> web rev: http://cr.openjdk.java.net/~thartmann/8143897/webrev.00/ >>>>>> >>>>>> Unit tests: As its hard, none >>>>>> >>>>>> Other tests: jprt. >>>>>> >>>>>> Description of the issue: >>>>>> A valid pc match in exception cache returning an invalid handler >>>>>> makes assert to fail. >>>>>> This happens as ExceptionCache reads are lock free access. >>>>>> >>>>>> As a fix for this i have put a storestore mem barrier before the >>>>>> count is updated. >>>>>> >>>>>> Best Regards, >>>>>> Jamsheed >>>> >> From doug.simon at oracle.com Thu Feb 4 10:08:11 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 4 Feb 2016 11:08:11 +0100 Subject: RFR: 8149019: remove redundant modifiers Message-ID: <37F3BA0E-6B92-4E0A-A112-D3DA0E1D5149@oracle.com> JVMCI code is checked by Checkstyle and recent Checkstyle releases have introduced better detection of redundant modifiers. To ensure JVMCI continues to benefit from automated code style checking, it makes sense to keep up with Checkstyle and address style issues detected by newer versions. https://bugs.openjdk.java.net/browse/JDK-8149019 http://cr.openjdk.java.net/~dnsimon/8149019 -Doug From roland.schatz at oracle.com Thu Feb 4 10:27:06 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Thu, 4 Feb 2016 11:27:06 +0100 Subject: RFR: 8146608: [JVMCI] DebugInfo Tests on DeoptimizeALot runs fails in assert(_pc == *pc_addr || pc == *pc_addr) frame::patch_pc() /frame_x86.cpp:285 Message-ID: <56B3277A.6060107@oracle.com> Hi, Please review this bugfix. webrev: http://cr.openjdk.java.net/~rschatz/JDK-8146608/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8146608 The original issue disappeared in the meantime, but that was just random. The problem was that the deopt rescue slot was not initialized in the testcase. The crash went away because the "uninitialized" value was changed from -1 to 0. This webrev contains the proper fix for the testcase, a change to the interface to give an error at code installation instead of randomly crashing, and a regression test. Thanks, Roland From roland.schatz at oracle.com Thu Feb 4 11:13:01 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Thu, 4 Feb 2016 12:13:01 +0100 Subject: RFR: 8148741: compiler/jvmci/code/SimpleDebugInfoTest.java fails in 'frame::sender_for_compiled_frame' Message-ID: <56B3323D.7090301@oracle.com> Hi, Please review this bugfix: webrev: http://cr.openjdk.java.net/~rschatz/JDK-8148741/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8148741 This is on top of another open RFR [1]. These are two separate but related bugs. Both fixes are needed for the test to pass. Thanks, Roland [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021103.html From doug.simon at oracle.com Thu Feb 4 11:26:44 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 4 Feb 2016 12:26:44 +0100 Subject: RFR: 8149019: remove redundant modifiers In-Reply-To: <37F3BA0E-6B92-4E0A-A112-D3DA0E1D5149@oracle.com> References: <37F3BA0E-6B92-4E0A-A112-D3DA0E1D5149@oracle.com> Message-ID: I forgot to mention that the webrev for this bug is on top of the RFR for JDK-8148981[1]. -Doug [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021100.html > On 04 Feb 2016, at 11:08, Doug Simon wrote: > > JVMCI code is checked by Checkstyle and recent Checkstyle releases have introduced better detection of redundant modifiers. To ensure JVMCI continues to benefit from automated code style checking, it makes sense to keep up with Checkstyle and address style issues detected by newer versions. > > https://bugs.openjdk.java.net/browse/JDK-8149019 > http://cr.openjdk.java.net/~dnsimon/8149019 > > -Doug From vladimir.x.ivanov at oracle.com Thu Feb 4 15:51:35 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 4 Feb 2016 18:51:35 +0300 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization Message-ID: <56B37387.2040204@oracle.com> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8148994 JDK-8072008 [1] introduced an optimization to bypass linker calls in generated code when target method can't be inlined. Unfortunately, it doesn't work well with MH::invokeBasic(), because it clashes with LambdaForm customization: if a call is not inlined, it is important for performance to update (customize) corresponding LambdaForm on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> _from_compiled_entry traversal on every invocation, while direct call points right to the _from_compiled_entry. So, any LambdaForm updates aren't visible until recompilation. The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm instance is used on every invocation. Also, cleaned up relevant tests a bit. Testing: octane, JPRT. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8072008 "Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls" From vladimir.x.ivanov at oracle.com Thu Feb 4 16:32:33 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 4 Feb 2016 19:32:33 +0300 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <56B37387.2040204@oracle.com> References: <56B37387.2040204@oracle.com> Message-ID: <56B37D21.9070509@oracle.com> FYI I was asked to keep the tests intact until Jigsaw is integrated. Removed test changes from the webrev (updated in place) and filed JDK-8149040 [1] to clean up the tests later. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8149040 On 2/4/16 6:51 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8148994 > > JDK-8072008 [1] introduced an optimization to bypass linker calls in > generated code when target method can't be inlined. > > Unfortunately, it doesn't work well with MH::invokeBasic(), because it > clashes with LambdaForm customization: if a call is not inlined, it is > important for performance to update (customize) corresponding LambdaForm > on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> > _from_compiled_entry traversal on every invocation, while direct call > points right to the _from_compiled_entry. So, any LambdaForm updates > aren't visible until recompilation. > > The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm > instance is used on every invocation. > > Also, cleaned up relevant tests a bit. > > Testing: octane, JPRT. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8072008 > "Emit direct call instead of linkTo* for recursive indy/MH.invoke* > calls" From edward.nevill at gmail.com Thu Feb 4 16:46:07 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 04 Feb 2016 16:46:07 +0000 Subject: [aarch64-port-dev ] RFR: 8148783: aarch64: SEGV running SpecJBB2013 In-Reply-To: <56B0C83D.900@redhat.com> References: <1454358837.11463.14.camel@mint> <56B0C83D.900@redhat.com> Message-ID: <1454604367.22510.28.camel@mylittlepony.linaroharston> On Tue, 2016-02-02 at 15:16 +0000, Andrew Haley wrote: > Hi, > > On 02/01/2016 08:33 PM, Edward Nevill wrote: > > > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8148783 > Can you test the patch I've appended instead? It tiptoes around the UB > and should be OK. Hi, Unfortunately this still fails. I have written a small simulacrum of the problem in C below. The following is the output. ed at arm64:~/tmp/adrp$ ./adrp original_adrp: pc = 0xffff70000000, dest = 0xfffe00000000, offset = 0x90000000, addr = 0x1000000000000 original_adrp: pc = 0xfffffffff000, dest = 0xfffe00000000, offset = 0x1000, addr = 0x1000000000000 new_adrp: pc = 0xffff70000000, dest = 0xfffe00000000, offset = 0xffffffff90000000, addr = 0xffff00000000 new_adrp: pc = 0xfffffffff000, dest = 0xfffe00000000, offset = 0x1000, addr = 0x1000000000000 <<<<< HERE bit 48 set The original generated an invalid address in both cases (where offset is +ve and -ve). The new version generates the correct output when the offset is -ve, however a +ve offset still generates an address with bit 48 set. A second problem is the following code in pd_patch_instruction // movk #imm16<<32 Instruction_aarch64::patch(branch + 4, 20, 5, (uint64_t)target >> 32); offset &= (1<<20)-1; instructions = 2; This is essentially doing the same thing as the original adrp, so even when the original adrp got the instruction correct the subsequent patching broke it again. I have attached a new webrev which fixes both these issues in a much simpler manner. http://cr.openjdk.java.net/~enevill/8148783/webrev.2 The key is to construct the instructions exactly as we are using them. When we use an adrp/movk combination to construct a 48 bit address we are using the adrp to construct the bottom 32 bits (with the bottom 12 bit 0) and the movk to construction bits 32..47 overwriting any values the adrp may have put in bits 32..47 So the instruction sequence is adrp Xn, 0xXXXXAAAAA000 movk Xn, 0xAAAA00000000 Where A represents required bits of the address and XXXX represent don't care bits. The only requirement on the XXXX bits is that they must be reachable using the adrp instruction. The webrev ensures this by using bits 32..47 from the PC and bits 0..31 from the destination address. The fact that we use the XXXX bits from the PC ensures the requirement that the address is reachable and using only the bottom 32 bits of the dest ensures we only get the bits we actually want the adrp instruction to construct and not any extraneous bits in bits 48 etc. The code that does this is unsigned long adrp_target = (target & 0xffffffffUL) | (source & 0xffff00000000UL); and this is also reflected in pd_patch_instruction to calculate the adrp target there. All the best, Ed. --- adrp.c --- #include void original_adrp(unsigned long pc, unsigned long dest) { unsigned long dest_page = dest >> 12; unsigned long pc_page = pc >> 12; long offset = dest_page - pc_page; offset = (offset & ((1<<20)-1)) << 12; printf("original_adrp: pc = 0x%lx, dest = 0x%lx, offset = 0x%lx, addr = 0x%lx\n", pc, dest, offset, pc+offset); } long truncate_signed_bitfield(long n, int width) { // Left shifts of a signed integer are UB in Standard C++ but // well-defined in GNU C++. n <<= 64 - width; n >>= 64 - width; return n; } void new_adrp(unsigned long pc, unsigned long dest) { unsigned long dest_page = dest >> 12; unsigned long pc_page = pc >> 12; unsigned long page_offset = dest_page - pc_page; long offset = page_offset; offset = truncate_signed_bitfield(offset << 12, 32); printf("new_adrp: pc = 0x%lx, dest = 0x%lx, offset = 0x%lx, addr = 0x% lx\n", pc, dest, offset, pc+offset); } int main(void) { original_adrp(0x0000ffff70000000, 0x0000fffe00000000); original_adrp(0x0000fffffffff000, 0x0000fffe00000000); new_adrp(0x0000ffff70000000, 0x0000fffe00000000); new_adrp(0x0000fffffffff000, 0x0000fffe00000000); } --- cut here --- From vladimir.kozlov at oracle.com Thu Feb 4 16:53:38 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 4 Feb 2016 08:53:38 -0800 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <56B37D21.9070509@oracle.com> References: <56B37387.2040204@oracle.com> <56B37D21.9070509@oracle.com> Message-ID: <56B38212.90707@oracle.com> Seems good. It is all mystery for me :) Thanks, Vladimir K On 2/4/16 8:32 AM, Vladimir Ivanov wrote: > FYI I was asked to keep the tests intact until Jigsaw is integrated. > > Removed test changes from the webrev (updated in place) and filed JDK-8149040 [1] to clean up the tests later. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8149040 > > On 2/4/16 6:51 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8148994 >> >> JDK-8072008 [1] introduced an optimization to bypass linker calls in >> generated code when target method can't be inlined. >> >> Unfortunately, it doesn't work well with MH::invokeBasic(), because it >> clashes with LambdaForm customization: if a call is not inlined, it is >> important for performance to update (customize) corresponding LambdaForm >> on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> >> _from_compiled_entry traversal on every invocation, while direct call >> points right to the _from_compiled_entry. So, any LambdaForm updates >> aren't visible until recompilation. >> >> The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm >> instance is used on every invocation. >> >> Also, cleaned up relevant tests a bit. >> >> Testing: octane, JPRT. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8072008 >> "Emit direct call instead of linkTo* for recursive indy/MH.invoke* >> calls" From christian.thalinger at oracle.com Thu Feb 4 16:56:46 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Feb 2016 08:56:46 -0800 Subject: RFR: 8146608: [JVMCI] DebugInfo Tests on DeoptimizeALot runs fails in assert(_pc == *pc_addr || pc == *pc_addr) frame::patch_pc() /frame_x86.cpp:285 In-Reply-To: <56B3277A.6060107@oracle.com> References: <56B3277A.6060107@oracle.com> Message-ID: Looks good. > On Feb 4, 2016, at 2:27 AM, Roland Schatz wrote: > > Hi, > > Please review this bugfix. > > webrev: > http://cr.openjdk.java.net/~rschatz/JDK-8146608/webrev.00/ > issue: > https://bugs.openjdk.java.net/browse/JDK-8146608 > > The original issue disappeared in the meantime, but that was just random. > The problem was that the deopt rescue slot was not initialized in the testcase. The crash went away because the "uninitialized" value was changed from -1 to 0. > > This webrev contains the proper fix for the testcase, a change to the interface to give an error at code installation instead of randomly crashing, and a regression test. > > Thanks, > Roland From aph at redhat.com Thu Feb 4 17:02:05 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Feb 2016 17:02:05 +0000 Subject: [aarch64-port-dev ] RFR: 8148783: aarch64: SEGV running SpecJBB2013 In-Reply-To: <1454604367.22510.28.camel@mylittlepony.linaroharston> References: <1454358837.11463.14.camel@mint> <56B0C83D.900@redhat.com> <1454604367.22510.28.camel@mylittlepony.linaroharston> Message-ID: <56B3840D.9060301@redhat.com> On 02/04/2016 04:46 PM, Edward Nevill wrote: > > The webrev ensures this by using bits 32..47 from the PC and bits > 0..31 from the destination address. The fact that we use the XXXX > bits from the PC ensures the requirement that the address is > reachable and using only the bottom 32 bits of the dest ensures we > only get the bits we actually want the adrp instruction to construct > and not any extraneous bits in bits 48 etc. > > The code that does this is > > unsigned long adrp_target = (target & 0xffffffffUL) | (source & 0xffff00000000UL); > > and this is also reflected in pd_patch_instruction to calculate the adrp target there. Much better, but this still is confusing. Surely you can do unsigned long target = (unsigned long)dest.target(); unsigned long adrp_target = (target & 0xffffffffUL) | ((unsigned long)pc() & 0xffff00000000UL); _adrp(reg1, (address)adrp_target); movk(reg1, target >> 32, 32); } "source" doesn't really mean anything here. OK with that change. Andrew. From vladimir.x.ivanov at oracle.com Thu Feb 4 17:11:42 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 4 Feb 2016 20:11:42 +0300 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <56B38212.90707@oracle.com> References: <56B37387.2040204@oracle.com> <56B37D21.9070509@oracle.com> <56B38212.90707@oracle.com> Message-ID: <56B3864E.80705@oracle.com> Thanks, Vladimir! Best regards, Vladimir Ivanov PS: I can share some bugs with you next time, so you can get hands-on experience in that dark corner of the JVM ;-) Just let me know. On 2/4/16 7:53 PM, Vladimir Kozlov wrote: > Seems good. It is all mystery for me :) > > Thanks, > Vladimir K > > On 2/4/16 8:32 AM, Vladimir Ivanov wrote: >> FYI I was asked to keep the tests intact until Jigsaw is integrated. >> >> Removed test changes from the webrev (updated in place) and filed >> JDK-8149040 [1] to clean up the tests later. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8149040 >> >> On 2/4/16 6:51 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8148994 >>> >>> JDK-8072008 [1] introduced an optimization to bypass linker calls in >>> generated code when target method can't be inlined. >>> >>> Unfortunately, it doesn't work well with MH::invokeBasic(), because it >>> clashes with LambdaForm customization: if a call is not inlined, it is >>> important for performance to update (customize) corresponding LambdaForm >>> on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> >>> _from_compiled_entry traversal on every invocation, while direct call >>> points right to the _from_compiled_entry. So, any LambdaForm updates >>> aren't visible until recompilation. >>> >>> The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm >>> instance is used on every invocation. >>> >>> Also, cleaned up relevant tests a bit. >>> >>> Testing: octane, JPRT. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8072008 >>> "Emit direct call instead of linkTo* for recursive indy/MH.invoke* >>> calls" From forax at univ-mlv.fr Thu Feb 4 17:13:05 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 4 Feb 2016 18:13:05 +0100 (CET) Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <56B37D21.9070509@oracle.com> References: <56B37387.2040204@oracle.com> <56B37D21.9070509@oracle.com> Message-ID: <1377731619.1635149.1454605985996.JavaMail.zimbra@u-pem.fr> Hi Vladimir, Perhaps a stupid question, but why LF customization doesn't trigger a recompilation if invokeBasic is already compiled into a direct call ? regards, R?mi ----- Mail original ----- > De: "Vladimir Ivanov" > ?: "hotspot compiler" > Envoy?: Jeudi 4 F?vrier 2016 17:32:33 > Objet: Re: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization > > FYI I was asked to keep the tests intact until Jigsaw is integrated. > > Removed test changes from the webrev (updated in place) and filed > JDK-8149040 [1] to clean up the tests later. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8149040 > > On 2/4/16 6:51 PM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 > > https://bugs.openjdk.java.net/browse/JDK-8148994 > > > > JDK-8072008 [1] introduced an optimization to bypass linker calls in > > generated code when target method can't be inlined. > > > > Unfortunately, it doesn't work well with MH::invokeBasic(), because it > > clashes with LambdaForm customization: if a call is not inlined, it is > > important for performance to update (customize) corresponding LambdaForm > > on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> > > _from_compiled_entry traversal on every invocation, while direct call > > points right to the _from_compiled_entry. So, any LambdaForm updates > > aren't visible until recompilation. > > > > The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm > > instance is used on every invocation. > > > > Also, cleaned up relevant tests a bit. > > > > Testing: octane, JPRT. > > > > Best regards, > > Vladimir Ivanov > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8072008 > > "Emit direct call instead of linkTo* for recursive indy/MH.invoke* > > calls" > From christian.thalinger at oracle.com Thu Feb 4 17:25:59 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Feb 2016 09:25:59 -0800 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <56B37387.2040204@oracle.com> References: <56B37387.2040204@oracle.com> Message-ID: While you are in there can you remove this line a few lines above: 828 guarantee(!target->is_method_handle_intrinsic(), "should not happen"); // XXX remove I think it?s proven that it doesn?t trigger (I?ve added that guarantee a looooong time ago). > On Feb 4, 2016, at 7:51 AM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8148994 > > JDK-8072008 [1] introduced an optimization to bypass linker calls in generated code when target method can't be inlined. > > Unfortunately, it doesn't work well with MH::invokeBasic(), because it clashes with LambdaForm customization: if a call is not inlined, it is important for performance to update (customize) corresponding LambdaForm on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> _from_compiled_entry traversal on every invocation, while direct call points right to the _from_compiled_entry. So, any LambdaForm updates aren't visible until recompilation. > > The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm instance is used on every invocation. > > Also, cleaned up relevant tests a bit. > > Testing: octane, JPRT. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8072008 > "Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls" From christian.thalinger at oracle.com Thu Feb 4 17:31:07 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Feb 2016 09:31:07 -0800 Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1 In-Reply-To: <56B2FBB4.70407@oracle.com> References: <56B2FBB4.70407@oracle.com> Message-ID: <38A68458-6D67-423D-93F0-95E40AE7E92D@oracle.com> src/share/vm/oops/method.hpp: I?d rather have the #if?s inside the method bodies. > On Feb 3, 2016, at 11:20 PM, Chris Plummer wrote: > > Hello, > > Please review the following for removing Method::_method_data when only supporting C1 (or more specifically, when not supporting C2 or JVMCI). This will help reduce dynamic footprint usage for the minimal VM. > > As part of this fix, ProfileInterperter is forced to false unless C2 or JVMCI is supported. This was mainly done to avoid crashes if it is turned on and Method::_method_data has been excluded, but also because it is not useful except to C2 or JVMCI. > > Webrev: http://cr.openjdk.java.net/~cjplummer/8147978/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8147978 > > Test with JPRT -testset hotspot. > > thanks, > > Chris From christian.thalinger at oracle.com Thu Feb 4 17:44:04 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Feb 2016 09:44:04 -0800 Subject: RFR (XS): 8148981: remove ResolvedJavaType.getClassFilePath() In-Reply-To: <37366705-6BF2-4CD6-B4E3-CA827650B0B7@oracle.com> References: <37366705-6BF2-4CD6-B4E3-CA827650B0B7@oracle.com> Message-ID: Looks good. > On Feb 4, 2016, at 12:32 AM, Doug Simon wrote: > > This method is not used and has a test causing problems for Jake integration (JDK-8148810). > > https://bugs.openjdk.java.net/browse/JDK-8148981 > http://cr.openjdk.java.net/~dnsimon/8148981 > > -Doug From chris.plummer at oracle.com Thu Feb 4 17:45:40 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 4 Feb 2016 09:45:40 -0800 Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1 In-Reply-To: <38A68458-6D67-423D-93F0-95E40AE7E92D@oracle.com> References: <56B2FBB4.70407@oracle.com> <38A68458-6D67-423D-93F0-95E40AE7E92D@oracle.com> Message-ID: <56B38E44.4010502@oracle.com> Ok. I can go either way on this particular example. However, when you start to get a lot of methods using the #ifdefs, it looks cleaner if you have just one #ifdef/#else/#endif for all of them. For example, see #if INCLUDE_NMT in memTracker.hpp. So do we want consistency in our approach to these #ifdefs, or do we want flexibility based on how many #ifdefs we'll end up with? thanks, Chris On 2/4/16 9:31 AM, Christian Thalinger wrote: > src/share/vm/oops/method.hpp: > > I?d rather have the #if?s inside the method bodies. > >> On Feb 3, 2016, at 11:20 PM, Chris Plummer wrote: >> >> Hello, >> >> Please review the following for removing Method::_method_data when only supporting C1 (or more specifically, when not supporting C2 or JVMCI). This will help reduce dynamic footprint usage for the minimal VM. >> >> As part of this fix, ProfileInterperter is forced to false unless C2 or JVMCI is supported. This was mainly done to avoid crashes if it is turned on and Method::_method_data has been excluded, but also because it is not useful except to C2 or JVMCI. >> >> Webrev: http://cr.openjdk.java.net/~cjplummer/8147978/webrev.02/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147978 >> >> Test with JPRT -testset hotspot. >> >> thanks, >> >> Chris From john.r.rose at oracle.com Thu Feb 4 18:52:06 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 4 Feb 2016 10:52:06 -0800 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <56B37387.2040204@oracle.com> References: <56B37387.2040204@oracle.com> Message-ID: <6CCE2F2C-1836-47CC-B13E-4371C2CE61FF@oracle.com> Looks good. Except I don't recall how is_inline interacts, if at all, with customization. It's not clear what is being gated, and which optimizations get let through. Maybe a comment about that would be useful Reviewed. ? John > On Feb 4, 2016, at 7:51 AM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8148994 > > JDK-8072008 [1] introduced an optimization to bypass linker calls in generated code when target method can't be inlined. > > Unfortunately, it doesn't work well with MH::invokeBasic(), because it clashes with LambdaForm customization: if a call is not inlined, it is important for performance to update (customize) corresponding LambdaForm on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> _from_compiled_entry traversal on every invocation, while direct call points right to the _from_compiled_entry. So, any LambdaForm updates aren't visible until recompilation. > > The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm instance is used on every invocation. > > Also, cleaned up relevant tests a bit. > > Testing: octane, JPRT. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8072008 > "Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls" From doug.simon at oracle.com Thu Feb 4 20:36:03 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 4 Feb 2016 21:36:03 +0100 Subject: RFR: 8148507: [JVMCI] mitigate deadlocks related to JVMCI compiler under -Xbatch In-Reply-To: <3F2DB53D-5308-4745-97F6-7EF35DF99A52@oracle.com> References: <845F1D56-3194-49AE-95C1-79545F8C50AC@oracle.com> <3F2DB53D-5308-4745-97F6-7EF35DF99A52@oracle.com> Message-ID: <00D38633-F4E3-47D0-800C-9A45893354E2@oracle.com> I?ve updated the webrev in situ for reasons discussed here: https://bugs.openjdk.java.net/browse/JDK-8148507?focusedCommentId=13896252&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896252 > On 03 Feb 2016, at 20:42, Christian Thalinger wrote: > > There was some discussion in the bug report but I seems like we are going to integrate this change. > >> On Jan 31, 2016, at 5:48 AM, Christian Thalinger wrote: >> >> Looks good. >> >>> On Jan 29, 2016, at 4:34 PM, Doug Simon wrote: >>> >>> Please review this small change to further mitigate deadlocks that can be caused by JVMCI when BackgroundCompilation is disabled. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8148507 >>> http://cr.openjdk.java.net/~dnsimon/8148507 >>> >>> -Doug >> > From david.holmes at oracle.com Fri Feb 5 01:43:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Feb 2016 11:43:54 +1000 Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1 In-Reply-To: <56B2FBB4.70407@oracle.com> References: <56B2FBB4.70407@oracle.com> Message-ID: <56B3FE5A.9010806@oracle.com> Hi Chris, On 4/02/2016 5:20 PM, Chris Plummer wrote: > Hello, > > Please review the following for removing Method::_method_data when only > supporting C1 (or more specifically, when not supporting C2 or JVMCI). Does JVMCI exist with C1 only? The COMPILER2_OR_JVMCI conjunction makes things a bit messy. Can we abstract that behind a single variable, INCLUDE_METHOD_DATA (or some such) to make it cleaner? > This will help reduce dynamic footprint usage for the minimal VM. > > As part of this fix, ProfileInterperter is forced to false unless C2 or > JVMCI is supported. This was mainly done to avoid crashes if it is > turned on and Method::_method_data has been excluded, but also because > it is not useful except to C2 or JVMCI. Are you saying that the information generated by ProfileInterpreter is only used by C2 and JVMCI? If that is case it should really have been a C2 only flag. If ProfileInterpreter is forced to false then shouldn't you also be checking TraceProfileInterpreter and PrintMethodData use as well Thanks, David > Webrev: http://cr.openjdk.java.net/~cjplummer/8147978/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8147978 > > Test with JPRT -testset hotspot. > > thanks, > > Chris From tom.rodriguez at oracle.com Fri Feb 5 01:57:58 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 4 Feb 2016 17:57:58 -0800 Subject: RFR(XS): 8149076: [JVMCI] missing ResourceMark in JVMCIRuntime::initialize_HotSpotJVMCIRuntime Message-ID: <11F9B96C-B82E-4FE3-80BB-47B9910781CF@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8149076 http://cr.openjdk.java.net/~never/8149076/webrev/ There's no explicit ResourceMark in JVMCIRuntime::initialize_HotSpotJVMCIRuntime but generally callers have one that it can use. However calling JVMCI.getRuntime() from a newly created thread will assert because there doesn't happen to be a containing resource mark. It should just have it's own. I also modified to catch this case JVM_GetJVMCIRuntimeTest test to catch this case which required removing the unnecessary use of reflection, since this also introduced a containing ResourceMark that made the problem disappear. Tested with test case. tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Feb 5 02:10:08 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 4 Feb 2016 18:10:08 -0800 Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1 In-Reply-To: <56B3FE5A.9010806@oracle.com> References: <56B2FBB4.70407@oracle.com> <56B3FE5A.9010806@oracle.com> Message-ID: <56B40480.6060703@oracle.com> Hi David, On 2/4/16 5:43 PM, David Holmes wrote: > Hi Chris, > > On 4/02/2016 5:20 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following for removing Method::_method_data when only >> supporting C1 (or more specifically, when not supporting C2 or JVMCI). > > Does JVMCI exist with C1 only? My understanding is it can exists with C2 or on its own, but currently is not included with C1 builds. > The COMPILER2_OR_JVMCI conjunction makes things a bit messy. Can we > abstract that behind a single variable, INCLUDE_METHOD_DATA (or some > such) to make it cleaner? I'll also be using COMPILER2_OR_JVMCI with another change to that removes some MethodCounter fields. So yes, I can add INCLUDE_METHOD_DATA, but then will need another INCLUDE_XXX for the MethodCounter fields I'll be conditionally removing. > >> This will help reduce dynamic footprint usage for the minimal VM. >> >> As part of this fix, ProfileInterperter is forced to false unless C2 or >> JVMCI is supported. This was mainly done to avoid crashes if it is >> turned on and Method::_method_data has been excluded, but also because >> it is not useful except to C2 or JVMCI. > > Are you saying that the information generated by ProfileInterpreter is > only used by C2 and JVMCI? If that is case it should really have been > a C2 only flag. > That is my understanding. Coleen confirmed it for me. I believe she got her info from the compiler team. BTW, we need a mechanism to make these conditionally unsupported flags a constant value when they are not supported. It would help deadstrip code. > If ProfileInterpreter is forced to false then shouldn't you also be > checking TraceProfileInterpreter and PrintMethodData use as well Yes, I can add those. thanks, Chris > > Thanks, > David > >> Webrev: http://cr.openjdk.java.net/~cjplummer/8147978/webrev.02/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8147978 >> >> Test with JPRT -testset hotspot. >> >> thanks, >> >> Chris From david.holmes at oracle.com Fri Feb 5 03:10:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Feb 2016 13:10:19 +1000 Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1 In-Reply-To: <56B40480.6060703@oracle.com> References: <56B2FBB4.70407@oracle.com> <56B3FE5A.9010806@oracle.com> <56B40480.6060703@oracle.com> Message-ID: <56B4129B.3010506@oracle.com> On 5/02/2016 12:10 PM, Chris Plummer wrote: > Hi David, > > On 2/4/16 5:43 PM, David Holmes wrote: >> Hi Chris, >> >> On 4/02/2016 5:20 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following for removing Method::_method_data when only >>> supporting C1 (or more specifically, when not supporting C2 or JVMCI). >> >> Does JVMCI exist with C1 only? > My understanding is it can exists with C2 or on its own, but currently > is not included with C1 builds. Okay. >> The COMPILER2_OR_JVMCI conjunction makes things a bit messy. Can we >> abstract that behind a single variable, INCLUDE_METHOD_DATA (or some >> such) to make it cleaner? > I'll also be using COMPILER2_OR_JVMCI with another change to that > removes some MethodCounter fields. So yes, I can add > INCLUDE_METHOD_DATA, but then will need another INCLUDE_XXX for the > MethodCounter fields I'll be conditionally removing. Okay. It is ugly though :( >> >>> This will help reduce dynamic footprint usage for the minimal VM. >>> >>> As part of this fix, ProfileInterperter is forced to false unless C2 or >>> JVMCI is supported. This was mainly done to avoid crashes if it is >>> turned on and Method::_method_data has been excluded, but also because >>> it is not useful except to C2 or JVMCI. >> >> Are you saying that the information generated by ProfileInterpreter is >> only used by C2 and JVMCI? If that is case it should really have been >> a C2 only flag. >> > That is my understanding. Coleen confirmed it for me. I believe she got > her info from the compiler team. BTW, we need a mechanism to make these > conditionally unsupported flags a constant value when they are not > supported. It would help deadstrip code. Does it work to define it only in c2_globals.hpp and jvmci_globals.hpp, then in the shared globals.hpp define the flag as a constant "false" if not C2 or JVMCI? (I admit the multiple layers of macros makes it hard to see exactly how to make such a declaration.) >> If ProfileInterpreter is forced to false then shouldn't you also be >> checking TraceProfileInterpreter and PrintMethodData use as well > Yes, I can add those. Thinking more on this, forcing ProfileInterpreter off doesn't really change anything, so I don't think you need to validate these flags are also off. Thanks, David > thanks, > > Chris >> >> Thanks, >> David >> >>> Webrev: http://cr.openjdk.java.net/~cjplummer/8147978/webrev.02/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147978 >>> >>> Test with JPRT -testset hotspot. >>> >>> thanks, >>> >>> Chris > From zoltan.majo at oracle.com Fri Feb 5 09:25:23 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 5 Feb 2016 10:25:23 +0100 Subject: [9] RFR (XS): 8148758: Compilation fails with "this call site should not be polymorphic" Message-ID: <56B46A83.3020701@oracle.com> Hi, please review the patch for 8148758. https://bugs.openjdk.java.net/browse/JDK-8148758 Problem: Compilation fails because the C2 compiler encounters inconsistent profiling information. The reason for the failure is that the test changes the OnStackReplacePercentage flag's value at runtime. Several other values are computed based on the value of the OnStackReplacePercentage flag (e.g., InvocationCounter::InterpreterBackwardBranchLimit, MethodCounters::_interpreter_backward_branch_limit). As a result, changing the flag's value at runtime can put the VM into an inconsistent state. Also, the WB API changes the value of the flag without synchronization possibly leaving the flag in an inconsistent state. Solution: The goal of IntxTest.java is to verify that getting/setting flag values through the WB API works properly. The test changes the flags OnStackReplacePercentage and InlineFrequencyCount. Both flags are related only to compilation. Running the test in interpreter-only guarantees that the VM is not put into an inconsistent state (because the flag values are not used by the VM). Webrev: http://cr.openjdk.java.net/~zmajo/8148758/webrev.00/ Testing: - JPRT with failing test; - local testing with the failing test on a linux-x86_64 system. Thank you and best regards, Zoltan From zoltan.majo at oracle.com Fri Feb 5 09:29:13 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 5 Feb 2016 10:29:13 +0100 Subject: [9] RFR (XS): 8148758: Compilation fails with "this call site should not be polymorphic" In-Reply-To: <56B46A83.3020701@oracle.com> References: <56B46A83.3020701@oracle.com> Message-ID: <56B46B69.3020001@oracle.com> P.S.: Forgot to mention: The failing test is currently quarantined in 'hs' (see JDK-8148970). Once we have a fix that is ready to push, I'll produce an updated webrev that also unquarantines the test. From roland.schatz at oracle.com Fri Feb 5 10:45:36 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Fri, 5 Feb 2016 11:45:36 +0100 Subject: RFR(XXS): 8149105: typo in jvmciCodeInstaller.cpp Message-ID: <56B47D50.5070203@oracle.com> Hi, In one of my recent changes, I introduced a typo in an error message. Please review the fix: issue: https://bugs.openjdk.java.net/browse/JDK-8149105 webrev: http://cr.openjdk.java.net/~rschatz/JDK-8149105/webrev.00/ Sorry for the noise. Thanks, Roland From uschindler at apache.org Fri Feb 5 10:56:48 2016 From: uschindler at apache.org (Uwe Schindler) Date: Fri, 5 Feb 2016 11:56:48 +0100 Subject: More SIGSEGV problems with JDK9 EA build 102 Message-ID: <001301d16003$ec21edf0$c465c9d0$@apache.org> Hi Hotspot team, we are testing build 102 of JDK 9 EA builds (without Jigsaw). Previously we were using build 94 without any problems (except the compact strings problem, that we worked around using the "-XX:-CompactStrings" flag). Tobias told me that the problem should be fixed in later EA builds. With build 102 we got multiple SIGSEGVs or test assertions failed in our code (see also the talk about our randomized testing on FOSDEM). One of these issues looks like the https://bugs.openjdk.java.net/browse/JDK-8148490 issue. By applying "-XX:-UseSuperWord" the problems disappeared (we have some classes in Lucene, e.g., CompressingTermVectorsWriter.java, which are very sensitive to vectorization and failures there are almost always AVX optimization problems, so it was quite clear that the issue was AVX). Once this is fixed and part of EA builds, we can reenable super words in testing, for now we leave them disabled. But even with "-XX:-UseSuperWord -XX:-CompactStrings" passed on command line, we still get on every 3rd run a crush / test failure (32 bits more often, but 64 bits also sometimes). The failures are in most cases SIGSEGV at various places inside the JVM or libc. We also get "invalid pointer" on free(). As said before, no problems with build 94, but happens all the time with build 102. Does anybody has some idea what could be the problem? The crushes look like this: 3 SIGSEGVs: [junit4] >>> JVM J2 emitted unexpected output (verbatim) ---- [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGSEGV (0xb) at pc=0x00007fc2be539edc, pid=10944, tid=11054 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+102) (build 9-ea+102-2016-01-21-001533.javare.4316.nc) [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (9-ea+102-2016-01-21-001533.javare.4316.nc, mixed mode, tiered, g1 gc, linux-amd64) [junit4] # Problematic frame: [junit4] # C [libc.so.6+0x7fedc][thread 12464 also had an error] [junit4] # [ timer expired, abort... ] [junit4] <<< JVM J2: EOF ---- [junit4] >>> JVM J2 emitted unexpected output (verbatim) ---- [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGSEGV (0xb) at pc=0xf6ac0445, pid=13204, tid=13307 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+102) (build 9-ea+102-2016-01-21-001243.javare.4316.nc) [junit4] # Java VM: Java HotSpot(TM) Server VM (9-ea+102-2016-01-21-001243.javare.4316.nc, mixed mode, tiered, g1 gc, linux-x86) [junit4] # Problematic frame: [junit4] # V [libjvm.so+0x241445] ChunkPool::allocate(unsigned int, AllocFailStrategy::AllocFailEnum)+0x25 [junit4] # [junit4] # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [junit4] # [junit4] # An error report file with more information is saved as: [junit4] # /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/backward-codecs/test/J2/hs_err_pid13204.log [junit4] [junit4] [error occurred during error reporting , id 0xb] [junit4] [junit4] # [junit4] # If you would like to submit a bug report, please visit: [junit4] # http://bugreport.java.com/bugreport/crash.jsp [junit4] # [junit4] <<< JVM J2: EOF ---- [junit4] >>> JVM J2 emitted unexpected output (verbatim) ---- [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGSEGV (0xb) at pc=0xf7249300, pid=31605, tid=31729 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+102) (build 9-ea+102-2016-01-21-001243.javare.4316.nc) [junit4] # Java VM: Java HotSpot(TM) Server VM (9-ea+102-2016-01-21-001243.javare.4316.nc, mixed mode, tiered, g1 gc, linux-x86) [junit4] # Problematic frame: [junit4] # V [libjvm.so+0x9b3300] Type::cmp(Type const*, Type const*)+0x10 [junit4] # [junit4] # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [junit4] # [junit4] # An error report file with more information is saved as: [junit4] # /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J2/hs_err_pid31605.log [junit4] # [junit4] # Compiler replay data is saved as: [junit4] # /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J2/replay_pid31605.log [junit4] # [junit4] # If you would like to submit a bug report, please visit: [junit4] # http://bugreport.java.com/bugreport/crash.jsp [junit4] # [junit4] <<< JVM J2: EOF ---- "invalid pointer" on free(): [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/test-framework/test/temp/junit4-J0-20160204_124703_166.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) ---- [junit4] *** Error in `/home/jenkins/tools/java/64bit/jdk-9-ea+102/bin/java': free(): invalid pointer: 0x00007f74bd485960 *** [junit4] <<< JVM J0: EOF ---- [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/test-framework/test/temp/junit4-J0-20160203_223446_729.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) ---- [junit4] *** Error in `/home/jenkins/tools/java/64bit/jdk-9-ea+102/bin/java': free(): invalid pointer: 0x00007f53c8b0ece0 *** [junit4] <<< JVM J0: EOF ---- (after that it exited with exit code 134) I don't have the hs_err.pid files for all failures anymore (because they are deleted after 20 Jenkins Job runs), but I can provide them if needed - for the recent ones I clicked on "preserve" on the Jenkins Job (sorry for not doing that earlier!). I just wanted to know if anybody has an idea what could cause this. Today I have seen a patch for this issue: 8149038: SIGSEGV at frame::is_interpreted_frame_valid -> StubRoutines::SafeFetchN (could be related). Kind regards and thanks for the nice FOSDEM meeting last week, Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From vladimir.x.ivanov at oracle.com Fri Feb 5 11:38:56 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 5 Feb 2016 14:38:56 +0300 Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down fastdebug builds' performance In-Reply-To: References: <54F99281.7020101@oracle.com> Message-ID: <56B489D0.3070700@oracle.com> (I'd like to revive the thread. It still affects our testing.) Filipp, Overall, the approach you propose looks good. What I'd like to see is unified binary_search implementation being used. There are already many places where custom implementations are used [1] [2] [3] and I don't want to see one more. Please, factor it out. GrowableArray::find_sorted looks like a good candidate (but it suffers from an overflow). Let me know if you don't have time to work on it. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a34b3268a14f/src/share/vm/oops/instanceKlass.cpp#l1360 [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a34b3268a14f/src/share/vm/utilities/growableArray.hpp#l391 [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a34b3268a14f/src/share/vm/gc/g1/g1CollectorPolicy.cpp#l659 On 3/23/15 1:40 PM, Filipp Zhinkin wrote: > Hi all, > > sorry for a late reply. > > I don't think that it's possible to remove is_sorted assertion from > create_unhandled_lists, because it's crucial condition for a linear > scan allocation algorithm and it's pretty easy to break it incidentally. > Existing assertion could significantly reduce time required to locate > an issue when something will go wrong. > > However, I believe that it could be relaxed to check only that > intervals in _sorted_intervals list are actually ordered and that > _new_intervals_from_allocation list is empty (in sorting methods > we still will be verifying that sorted and unsorted lists contain > same intervals). > > What do you guys think about that? > > Regards, > Filippp. > > > On Fri, Mar 6, 2015 at 9:24 PM, Filipp Zhinkin wrote: >> Hi Aleksey, >> >> thanks for looking at it! >> >> On Fri, Mar 6, 2015 at 2:41 PM, Aleksey Shipilev >> wrote: >>> Hi Filipp, >>> >>> On 06.03.2015 14:33, Filipp Zhinkin wrote: >>>> In certain cases (like -client -Xcomp) C1 compilation is very slow >>>> w/ fastdebug builds. A place where we spent enormous amount of time >>>> is LinearScan::is_sorted method, which simply verifies that a list >>>> that should be sorted is actually sorted and that both sorted and >>>> unsorted lists contains same intervals. >>> >>> Okay, what caller of is_sorted dominates? Maybe instead of optimizing >>> the is_sorted itself, you need to move/relax the assert in some selected >>> places? >> >> Well, the dominating caller is LinearScan::create_unhandled_lists [1]. >> >>> >>> That is to say I am not fond of complicating the non-product code that >>> does verification without a compelling reason to do so; let's first >>> figure out if we "just" do excess asserts. >> >> That's a good point. I'll try to figure a out if an assertion is placed to be >> sure that all methods called in the right sequence and if it's true, then >> it may be better to use less expensive approach. >> >> Thanks, >> Filipp. >> >> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/de7ca28f8b7d/src/share/vm/c1/c1_LinearScan.cpp#l1486 >> >>> >>> Thanks, >>> -Aleksey. >>> From hui.shi at linaro.org Fri Feb 5 12:47:35 2016 From: hui.shi at linaro.org (Hui Shi) Date: Fri, 5 Feb 2016 20:47:35 +0800 Subject: RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code Message-ID: Hi, Would some one help review this changeset? This improves performance for codes like string builder and concat on aarch64. Bug: https://bugs.openjdk.java.net/browse/JDK-8149080 webrev: http://cr.openjdk.java.net/~hshi/8149080/webrev/ Arraycopy without overlapping is faster than overlapped copy. If overlap information is unknown at JIT time, stub code will check if arraycopy src and dest array overlap at runtime, if not overlap, stub will perform faster none-overlap array copy. In current aarch64 implementation, stub code checks only if dest below src, this doesn?t cover cases dest above src but still not overlap case (as X86 did). Fixing is checking both conditions, if (dest-src) is above/equal (copy size), it's not overlap and stub code can jump to none overlapping copy. Another modification is adding StubCodeMark for backward/forward copy longs on aarch64, so code in these sections can get profiled with correct stub name. Regards Hui -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Fri Feb 5 12:58:55 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Feb 2016 12:58:55 +0000 Subject: RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: References: Message-ID: <56B49C8F.5030409@redhat.com> On 02/05/2016 12:47 PM, Hui Shi wrote: > Arraycopy without overlapping is faster than overlapped copy. The only thing which varies is the direction of copying. I'm not aware of anything which makes one direction faster than the other. Measurements, please. Andrew. From edward.nevill at gmail.com Fri Feb 5 14:32:41 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 05 Feb 2016 14:32:41 +0000 Subject: [aarch64-port-dev ] RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: <56B49C8F.5030409@redhat.com> References: <56B49C8F.5030409@redhat.com> Message-ID: <1454682761.26562.19.camel@mint> On Fri, 2016-02-05 at 12:58 +0000, Andrew Haley wrote: > On 02/05/2016 12:47 PM, Hui Shi wrote: > > Arraycopy without overlapping is faster than overlapped copy. > > The only thing which varies is the direction of copying. I'm not > aware of anything which makes one direction faster than the other. > Measurements, please. Copy backwards doesn't prefetch. The difference with and without prefetch can be very significant on some micro-arches. if (direction == copy_forwards && PrefetchCopyIntervalInBytes > 0) __ prfm(Address(s, PrefetchCopyIntervalInBytes), PLDL1KEEP); I have done some experiments with prefetch enabled for backwards copy and it shows almost identical performance to forwards copy. Regards, Ed. From aph at redhat.com Fri Feb 5 14:37:46 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Feb 2016 14:37:46 +0000 Subject: [aarch64-port-dev ] RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: <1454682761.26562.19.camel@mint> References: <56B49C8F.5030409@redhat.com> <1454682761.26562.19.camel@mint> Message-ID: <56B4B3BA.602@redhat.com> On 02/05/2016 02:32 PM, Edward Nevill wrote: > On Fri, 2016-02-05 at 12:58 +0000, Andrew Haley wrote: >> On 02/05/2016 12:47 PM, Hui Shi wrote: >>> Arraycopy without overlapping is faster than overlapped copy. >> >> The only thing which varies is the direction of copying. I'm not >> aware of anything which makes one direction faster than the other. >> Measurements, please. > > Copy backwards doesn't prefetch. The difference with and without > prefetch can be very significant on some micro-arches. > > if (direction == copy_forwards && PrefetchCopyIntervalInBytes > 0) > __ prfm(Address(s, PrefetchCopyIntervalInBytes), PLDL1KEEP); > > I have done some experiments with prefetch enabled for backwards copy > and it shows almost identical performance to forwards copy. OK, so let's do that, then. Andrew. From rahul.v.raghavan at oracle.com Fri Feb 5 14:52:01 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Fri, 5 Feb 2016 06:52:01 -0800 (PST) Subject: RFR(S): 6378256: Performance problem with System.identityHashCode in client compiler Message-ID: Hi, Please review revised patch, notes for JDK-6378256. https://bugs.openjdk.java.net/browse/JDK-6378256 Latest webrev-03: http://cr.openjdk.java.net/~thartmann/6378256/webrev.03/ (For reference old webrev-02: http://cr.openjdk.java.net/~thartmann/6378256/webrev.02/) Thank you Roland for the review comments. >> Also the x86_64 and x86_32 are (mostly?) identical. >> Do we want to create a sharedRuntime_x86.cpp, move the InlineObjectHash code >> in its own function there to avoid duplication? Yes agree to this point. So for the latest revised webrev-03 patch, tried creating new sharedRuntime_x86.cpp and moving shared code related to 6378256 fix in new function. As of now moved only the new function for 6378256 to this common file. I believe maybe more refactoring can be done, moving other unrelated common code between x86_32 and x86_64 if any, as a separate task! Confirmed no issues with jprt testing (-testset hotspot). >> Can you justify the comments again? Please refer the sample results got for manual unit tests for various targets, with and without proposed fix. Following is small unit test, a micro benchmark test case from JDK-6182955 related to JDK-6378256. ----Test Begin------- public class MyEnumTest { static class Zuper { public final int hashCode() { return super.hashCode(); } } static class Identity { public final int hashCode() { return System.identityHashCode(this); } } static long test(Object o) { long time=System.nanoTime(); for(int i=0;i<1000000;i++) o.hashCode(); return System.nanoTime()-time; } public static void main(String[] args) { System.out.println("super "+test(new Zuper())); System.out.println("identity "+test(new Identity())); } } ----Test End----------- Note: Original C1 issue reported - Performance problem with System.identityHashCode compared to Object.hashCode, with client compiler (at least seven times slower) ---Sample unit test results------------------ [01]. x86_32 (tried linux_i586 product build) //// Original behavior without fix // JDK-6378256 issue reproducible mainly with -client, -XX:TieredStopAtLevel=1, 2 With -server super 7971642 identity 6805876 With - client super 5261808 identity 71713073 With -XX:+TieredCompilation super 8781989 identity 8571933 With -XX:TieredStopAtLevel=1 super 6593751 identity 55797683 With -XX:TieredStopAtLevel=2 super 9619376 identity 74430911 With -XX:TieredStopAtLevel=3 super 11972884 identity 63821641 //// unit test results with latest proposed webrev-03 fix //System.identityHashCode results now comparable similar to Object.hashCode for client) With -server super 8615908 identity 6604061 With - client super 6075892 identity 6412164 With -XX:+TieredCompilation super 7261396 identity 7328875 With -XX:TieredStopAtLevel=1 super 7207882 identity 6277642 With -XX:TieredStopAtLevel=2 super 9500328 identity 8843374 With -XX:TieredStopAtLevel=3 super 11616995 identity 9140043 -------------------------------------------- [02]. solaris_sparcv9 //// Original behavior without fix // 64 bit target, so 6378256 issue reproducible with -XX:TieredStopAtLevel=1, 2, 3 With -server super 14013890 identity 10942257 With - client super 14004123 identity 11661086 With -XX:+TieredCompilation super 16058964 identity 12464348 With -XX:TieredStopAtLevel=1 super 15114826 identity 202158637 With -XX:TieredStopAtLevel=2 super 22183247 identity 207758147 With -XX:TieredStopAtLevel=3 super 32577893 identity 256768334 //// unit test results with proposed fix //System.identityHashCode results now comparable similar to Object.hashCode for client, after enabling the existing optimization. With -server super 11898144 identity 18135942 With - client super 12272644 identity 9375612 With -XX:+TieredCompilation super 11636948 identity 9350462 With -XX:TieredStopAtLevel=1 super 13906980 identity 10005384 With -XX:TieredStopAtLevel=2 super 22487806 identity 17352714 With -XX:TieredStopAtLevel=3 super 32788661 identity 29396398 -------------------------------------------- [03]. x86_64 (linux_x64 - product build) //// Original behavior without fix // In this case the C1 optimization, of inline code to check hashCode from object header, was not supported even for object.hashCode. // So found sample test results with -XX:TieredStopAtLevel=1, 2, 3 on higher side With -server super 9609530 identity 12478818 With - client super 9647637 identity 8095867 With -XX:+TieredCompilation super 8644689 identity 9157999 With -XX:TieredStopAtLevel=1 super 30208812 identity 43761942 With -XX:TieredStopAtLevel=2 super 35847408 identity 40643575 With -XX:TieredStopAtLevel=3 super 31086749 identity 33162520 //// unit test results with latest proposed webrev-03 fix // better results with -XX:TieredStopAtLevel=1, 2, 3 With -server super 9430873 identity 6230543 With - client super 9525046 identity 10886286 With -XX:+TieredCompilation super 7275681 identity 8156844 With -XX:TieredStopAtLevel=1 super 8406237 identity 7589478 With -XX:TieredStopAtLevel=2 super 8629649 identity 7419501 With -XX:TieredStopAtLevel=3 super 12555911 identity 10658754 Please send review comments Thank you, Rahul > Date: Thu, 28 Jan 2016 15:22:19 +0100 > From: Roland Westrelin To: hotspot compiler > > > With reference to below email thread, please send review comments for the revised patch for JDK-6378256. > > http://cr.openjdk.java.net/~thartmann/6378256/webrev.02/ > > That looks good. Can you justify the comments again? > > Also the x86_64 and x86_32 are (mostly?) identical. Do we want to create a sharedRuntime_x86.cpp, move the InlineObjectHash code > in its own function there to avoid duplication? > > Roland. > > > -----Original Message----- > > From: Tobias Hartmann > Sent: Monday, January 25, 2016 12:40 PM > To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net > > > > Hi Rahul, > > > > On 22.01.2016 17:11, Rahul Raghavan wrote: > > > > > >> -----Original Message----- > > >> From: Tobias Hartmann > Sent: Monday, January 11, 2016 2:56 PM > To: Rahul Raghavan; hotspot-compiler- > dev at openjdk.java.net > > >> > > >> Hi Rahul, > > >> > > >>> http://cr.openjdk.java.net/~thartmann/6378256/webrev.01/ > > >> > > >> Why don't you use 'markOopDesc::hash_mask_in_place' for the 64 bit version? This should safe some instructions and you also > > don't > > >> need the 'hash' register if you compute everything in 'result'. > > > > > > Thank you for your comments Tobias. > > > > > > I could not get the implementation work with the usage of 'markOopDesc::hash_mask_in_place' in x86_64 (similar to support in > > x86_32). > > > Usage of - __ andptr(result, markOopDesc::hash_mask_in_place); > > > Results in build error - ' overflow in implicit constant conversion' > > > > > > Then understood from 'sharedRuntime_sparc.cpp', 'markOop.hpp' - that the usage of 'hash_mask_in_place' should be avoided > for > > 64-bit because the values are too big! > > > Similar comments in LibraryCallKit::inline_native_hashcode [hotspot/src/share/vm/opto/library_call.cpp] also. > > > Could not find some other way to use hash_mask_in_place here for x86_64? > > > > You are right, I missed that. > > > > > So depending on markOopDesc::hash_mask, markOopDesc::hash_shift value instead (similar to done in sharedRuntime_sparc) > > > Added missing comment regarding above in the revised webrev. > > > > > > Also yes I missed the optimized codegen. > > > Tried revised patch removing usages of extra 'hash', 'mask' registers and computed all in 'result' itself. > > > > > > [sharedRuntime_x86_64.cpp] > > > .................... > > > + Register obj_reg = j_rarg0; > > > + Register result = rax; > > > ........ > > > + // get hash > > > + // Read the header and build a mask to get its hash field. > > > + // Depend on hash_mask being at most 32 bits and avoid the use of hash_mask_in_place > > > + // because it could be larger than 32 bits in a 64-bit vm. See markOop.hpp. > > > + __ shrptr(result, markOopDesc::hash_shift); > > > + __ andptr(result, markOopDesc::hash_mask); > > > + // test if hashCode exists > > > + __ jcc (Assembler::zero, slowCase); > > > + __ ret(0); > > > + __ bind (slowCase); > > > ........ > > > > > > Confirmed no issues with jprt testing (-testset hotspot) and expected results for unit tests. > > > > > > Please send your comments. I can submit revised webrev if all okay. > > > > Looks good. Please send a new webrev. > > > > Best, > > Tobias > > > > > > > >> > > >> Best, > > >> Tobias > > >> > > >> > > >> On 08.01.2016 18:13, Rahul Raghavan wrote: > > >>> Hello, > > >>> > > >>> Please review the following revised patch for JDK-6378256 - > > >>> http://cr.openjdk.java.net/~thartmann/6378256/webrev.01/ > > >>> > > >>> This revised webrev got following changes - > > >>> > > >>> 1) A minor, better optimized code with return 0 at initial stage (instead of continuing to 'slowCase' path), for special/rare null > > >> reference input! > > >>> (as per documentation, test results confirmed it is safe to 'return 0' for null reference input, for System.identityHashCode) > > >>> > > >>> 2) Added similar Object.hashCode, System.identityHashCode optimization support in sharedRuntime_x86_64.cpp. > > >>> > > >>> Confirmed no issues with jprt testing (-testset hotspot) and expected results for unit tests. > > >>> > > >>> Thanks, > > >>> Rahul From nils.eliasson at oracle.com Fri Feb 5 15:22:06 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 5 Feb 2016 16:22:06 +0100 Subject: RFR(S): 8148696: Race loading hsdis may cause SIGSEGV Message-ID: <56B4BE1E.8050206@oracle.com> Hi all, Please review this fix to loading hsdis library. Summary: We have had two crashes on Sparc where two C2 thread simultaneously tries to load the hsdis library. Three of four code paths are locked by the ttyLocker, but the fourth is open to races. Solution: I chose to add another lock (mutex) for this purpose and adapted the code so that library_load code works as intented. - The old can_decode() method was removed and resued as an wrapper for the load_library(). - Fixed a typo Bug: https://bugs.openjdk.java.net/browse/JDK-8148696 Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.01/ Regards, Nils Eliasson From vladimir.x.ivanov at oracle.com Fri Feb 5 15:36:26 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 5 Feb 2016 18:36:26 +0300 Subject: RFR(S): 8148696: Race loading hsdis may cause SIGSEGV In-Reply-To: <56B4BE1E.8050206@oracle.com> References: <56B4BE1E.8050206@oracle.com> Message-ID: <56B4C17A.3080306@oracle.com> Nils, Is the webrev you posted complete? I don't see any LoadDisassembler_lock usages and all the changed paths have ttyLocker. Best regards, Vladimir Ivanov On 2/5/16 6:22 PM, Nils Eliasson wrote: > Hi all, > > Please review this fix to loading hsdis library. > > Summary: > We have had two crashes on Sparc where two C2 thread simultaneously > tries to load the hsdis library. Three of four code paths are locked by > the ttyLocker, but the fourth is open to races. > > Solution: > I chose to add another lock (mutex) for this purpose and adapted the > code so that library_load code works as intented. > - The old can_decode() method was removed and resued as an wrapper for > the load_library(). > - Fixed a typo > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148696 > Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.01/ > > Regards, > Nils Eliasson From christian.thalinger at oracle.com Fri Feb 5 16:27:42 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 5 Feb 2016 08:27:42 -0800 Subject: RFR(XS): 8149076: [JVMCI] missing ResourceMark in JVMCIRuntime::initialize_HotSpotJVMCIRuntime In-Reply-To: <11F9B96C-B82E-4FE3-80BB-47B9910781CF@oracle.com> References: <11F9B96C-B82E-4FE3-80BB-47B9910781CF@oracle.com> Message-ID: Looks good. Igor, could you review the test changes? > On Feb 4, 2016, at 5:57 PM, Tom Rodriguez wrote: > > https://bugs.openjdk.java.net/browse/JDK-8149076 http://cr.openjdk.java.net/~never/8149076/webrev/ > > There's no explicit ResourceMark in JVMCIRuntime::initialize_HotSpotJVMCIRuntime but generally callers have one that it can use. However calling JVMCI.getRuntime() from a newly created thread will assert because there doesn't happen to be a containing resource mark. It should just have it's own. I also modified to catch this case JVM_GetJVMCIRuntimeTest test to catch this case which required removing the unnecessary use of reflection, since this also introduced a containing ResourceMark that made the problem disappear. Tested with test case. > > tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Fri Feb 5 16:29:52 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 5 Feb 2016 19:29:52 +0300 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <6CCE2F2C-1836-47CC-B13E-4371C2CE61FF@oracle.com> References: <56B37387.2040204@oracle.com> <6CCE2F2C-1836-47CC-B13E-4371C2CE61FF@oracle.com> Message-ID: <56B4CE00.3040809@oracle.com> Thanks, John. On 2/4/16 9:52 PM, John Rose wrote: > Looks good. Except I don't recall how is_inline interacts, if at all, with customization. It's not clear what is being gated, and which optimizations get let through. Inlining through MH::invokeBasic doesn't happen when there's @DontInline on the target. It is the case for GWT which has CountingWrapper on both paths. It starts with a reinvoker.dontInline LF and then switches to a reinvoker LF (after 30 invocations). If a compilation happens when reinvoker.dontInline is used, a direct call is generated and even if the branch becomes hot, all the calls goes through reinvoker.dontInline. Update to reinvoker LF isn't visible unless the dispatch goes through MH::invokeBasic linker. I had an impression that I introduced LF customization logic to the non-inlined case in GWT, but I can't find it in the code. So, it seems the regression is caused by repeated checks performed by reinvoker.dontInline LF and not by LF customization missed in generated code. Also, I stumbled upon a quirk in inlining policy: inlining through linkers can't be delayed. It happens when JIT hits some limit on IR size. So, right now inlining can stop in the middle of MH chain and a linker call is generated. But after JDK-8072008 there's no problem with delaying inlining. C2 can decide whether to keep the direct call or inline through it. So, I enabled late inlining for all linkers. (Surprisingly, no significant performance difference on nashorn.) So, I decided to keep invokeBasic linker call replacement for now, but piggypack LF customization on the stuck counting LF. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8148994/webrev.01/hotspot http://cr.openjdk.java.net/~vlivanov/8148994/webrev.01/jdk * enabled late inlining for linkers; * add LF customization check in CountingWrapper::countDown, so when counting is stuck, the target will be customized. Testing: octane, JPRT. I'm working on JDK-8071793 [1] and will reconsider how LF customization on non-inlined branch in GWTs works given there is a more JVM-friendly mechanism to control inlining. With the proposed fix reinvoker.dontInline is never customized (only the target it points to) and serves as a trampoline between GWT & target LF. It would be better to jump right to the customized LF, if non-inlined branch becomes hot. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8071793 "Prune rarely called invokedynamic call sites during inlining" > > Maybe a comment about that would be useful > Reviewed. > > ? John > >> On Feb 4, 2016, at 7:51 AM, Vladimir Ivanov wrote: >> >> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8148994 >> >> JDK-8072008 [1] introduced an optimization to bypass linker calls in generated code when target method can't be inlined. >> >> Unfortunately, it doesn't work well with MH::invokeBasic(), because it clashes with LambdaForm customization: if a call is not inlined, it is important for performance to update (customize) corresponding LambdaForm on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> _from_compiled_entry traversal on every invocation, while direct call points right to the _from_compiled_entry. So, any LambdaForm updates aren't visible until recompilation. >> >> The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm instance is used on every invocation. >> >> Also, cleaned up relevant tests a bit. >> >> Testing: octane, JPRT. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8072008 >> "Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls" From igor.ignatyev at oracle.com Fri Feb 5 16:30:30 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 5 Feb 2016 19:30:30 +0300 Subject: RFR(XS): 8149076: [JVMCI] missing ResourceMark in JVMCIRuntime::initialize_HotSpotJVMCIRuntime In-Reply-To: References: <11F9B96C-B82E-4FE3-80BB-47B9910781CF@oracle.com> Message-ID: <09ACC88F-5927-4585-BBF9-CEC3A188356B@oracle.com> Looks good to me too. Thanks. > On Feb 5, 2016, at 7:27 PM, Christian Thalinger wrote: > > Looks good. Igor, could you review the test changes? > >> On Feb 4, 2016, at 5:57 PM, Tom Rodriguez wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8149076 >> http://cr.openjdk.java.net/~never/8149076/webrev/ >> >> There's no explicit ResourceMark in JVMCIRuntime::initialize_HotSpotJVMCIRuntime but generally callers have one that it can use. However calling JVMCI.getRuntime() from a newly created thread will assert because there doesn't happen to be a containing resource mark. It should just have it's own. I also modified to catch this case JVM_GetJVMCIRuntimeTest test to catch this case which required removing the unnecessary use of reflection, since this also introduced a containing ResourceMark that made the problem disappear. Tested with test case. >> >> tom > From vladimir.x.ivanov at oracle.com Fri Feb 5 16:30:47 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 5 Feb 2016 19:30:47 +0300 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: References: <56B37387.2040204@oracle.com> Message-ID: <56B4CE37.20802@oracle.com> Good catch, Chris. Removed: http://cr.openjdk.java.net/~vlivanov/8148994/webrev.01/ Best regards, Vladimir Ivanov On 2/4/16 8:25 PM, Christian Thalinger wrote: > While you are in there can you remove this line a few lines above: > > 828 guarantee(!target->is_method_handle_intrinsic(), "should not happen"); // XXX remove > > I think it?s proven that it doesn?t trigger (I?ve added that guarantee a looooong time ago). > >> On Feb 4, 2016, at 7:51 AM, Vladimir Ivanov wrote: >> >> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8148994 >> >> JDK-8072008 [1] introduced an optimization to bypass linker calls in generated code when target method can't be inlined. >> >> Unfortunately, it doesn't work well with MH::invokeBasic(), because it clashes with LambdaForm customization: if a call is not inlined, it is important for performance to update (customize) corresponding LambdaForm on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> _from_compiled_entry traversal on every invocation, while direct call points right to the _from_compiled_entry. So, any LambdaForm updates aren't visible until recompilation. >> >> The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm instance is used on every invocation. >> >> Also, cleaned up relevant tests a bit. >> >> Testing: octane, JPRT. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8072008 >> "Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls" > From christian.thalinger at oracle.com Fri Feb 5 16:34:05 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 5 Feb 2016 08:34:05 -0800 Subject: RFR: 8148507: [JVMCI] mitigate deadlocks related to JVMCI compiler under -Xbatch In-Reply-To: <00D38633-F4E3-47D0-800C-9A45893354E2@oracle.com> References: <845F1D56-3194-49AE-95C1-79545F8C50AC@oracle.com> <3F2DB53D-5308-4745-97F6-7EF35DF99A52@oracle.com> <00D38633-F4E3-47D0-800C-9A45893354E2@oracle.com> Message-ID: Looks good to me. David, any comments? > On Feb 4, 2016, at 12:36 PM, Doug Simon wrote: > > I?ve updated the webrev in situ for reasons discussed here: > > https://bugs.openjdk.java.net/browse/JDK-8148507?focusedCommentId=13896252&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896252 > > >> On 03 Feb 2016, at 20:42, Christian Thalinger wrote: >> >> There was some discussion in the bug report but I seems like we are going to integrate this change. >> >>> On Jan 31, 2016, at 5:48 AM, Christian Thalinger wrote: >>> >>> Looks good. >>> >>>> On Jan 29, 2016, at 4:34 PM, Doug Simon wrote: >>>> >>>> Please review this small change to further mitigate deadlocks that can be caused by JVMCI when BackgroundCompilation is disabled. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8148507 >>>> http://cr.openjdk.java.net/~dnsimon/8148507 >>>> >>>> -Doug >>> >> > From vladimir.x.ivanov at oracle.com Fri Feb 5 16:44:06 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 5 Feb 2016 19:44:06 +0300 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <1377731619.1635149.1454605985996.JavaMail.zimbra@u-pem.fr> References: <56B37387.2040204@oracle.com> <56B37D21.9070509@oracle.com> <1377731619.1635149.1454605985996.JavaMail.zimbra@u-pem.fr> Message-ID: <56B4D156.4040002@oracle.com> Remi, Recompilation is usually expensive and if the call site hasn't been warmed up enough to be inlined, it is a clue it will likely never be. Actually, this bug is really a corner case. LF customization matters in cases when there's no inlining possible (e.g., MH::invokeExact() on a receiver which is not a compile-time constant). Instead of jumping between numerous tiny nmethods for every LF in the chain, it allows to generate a single nmethod for the whole chain. There's no need in customization when inlining happens and customization doesn't help inlining as well. In GWT case, uncommon trap is generated for non-taken branch (so causes a recompilation if it is ever taken), but a cold branch (<30 invocations) is compiled into a call. It could be beneficial to recompile the branch if it becomes really hot, but it happens rarely and requires additional profiling. I vaguely remember I experimented with that, but it severely affected warmup and didn't give any peak performance improvements (usually, on the contrarty). Best regards, Vladimir Ivanov On 2/4/16 8:13 PM, Remi Forax wrote: > Hi Vladimir, > Perhaps a stupid question, but why LF customization doesn't trigger a recompilation if invokeBasic is already compiled into a direct call ? > > regards, > R?mi > > ----- Mail original ----- >> De: "Vladimir Ivanov" >> ?: "hotspot compiler" >> Envoy?: Jeudi 4 F?vrier 2016 17:32:33 >> Objet: Re: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization >> >> FYI I was asked to keep the tests intact until Jigsaw is integrated. >> >> Removed test changes from the webrev (updated in place) and filed >> JDK-8149040 [1] to clean up the tests later. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8149040 >> >> On 2/4/16 6:51 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8148994 >>> >>> JDK-8072008 [1] introduced an optimization to bypass linker calls in >>> generated code when target method can't be inlined. >>> >>> Unfortunately, it doesn't work well with MH::invokeBasic(), because it >>> clashes with LambdaForm customization: if a call is not inlined, it is >>> important for performance to update (customize) corresponding LambdaForm >>> on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> >>> _from_compiled_entry traversal on every invocation, while direct call >>> points right to the _from_compiled_entry. So, any LambdaForm updates >>> aren't visible until recompilation. >>> >>> The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm >>> instance is used on every invocation. >>> >>> Also, cleaned up relevant tests a bit. >>> >>> Testing: octane, JPRT. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8072008 >>> "Emit direct call instead of linkTo* for recursive indy/MH.invoke* >>> calls" >> From vladimir.x.ivanov at oracle.com Fri Feb 5 16:54:15 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 5 Feb 2016 19:54:15 +0300 Subject: RFR(S): 8148696: Race loading hsdis may cause SIGSEGV In-Reply-To: <56B4BE1E.8050206@oracle.com> References: <56B4BE1E.8050206@oracle.com> Message-ID: <56B4D3B7.5090302@oracle.com> > Summary: > We have had two crashes on Sparc where two C2 thread simultaneously > tries to load the hsdis library. Three of four code paths are locked by > the ttyLocker, but the fourth is open to races. I'd suggest to either add ttyLocker on the fourth path or try to move it down the call chain to some shared code. (Keep in mind that ttyLocker is reentrant!) > Solution: > I chose to add another lock (mutex) for this purpose and adapted the > code so that library_load code works as intented. Another mutex will not work - tty_lock has the lowest rank (event): def(tty_lock , Mutex , event, true, Monitor::_safepoint_check_never); // allow to lock in VM I experimented with that when fixing 8071374, but decided to guard everything with tty_lock. Best regards, Vladimir Ivanov [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020417.html "The fix is to serialize access to Disassembler on tty_lock. Considering most of the calls to Disassembler::decode are performed under tty_lock (which has the lowest rank), it's too burdensome to introduce a dedicated lock and a new rank to please deadlock detection logic." > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148696 > Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.01/ > > Regards, > Nils Eliasson From christian.thalinger at oracle.com Fri Feb 5 16:55:56 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 5 Feb 2016 08:55:56 -0800 Subject: RFR(XXS): 8149105: typo in jvmciCodeInstaller.cpp In-Reply-To: <56B47D50.5070203@oracle.com> References: <56B47D50.5070203@oracle.com> Message-ID: <4A355C71-8F3F-4BA3-ABA1-B9AC4F0F4B0E@oracle.com> Doh. I noticed the typo but forgot to mention it. Looks good. > On Feb 5, 2016, at 2:45 AM, Roland Schatz wrote: > > Hi, > > In one of my recent changes, I introduced a typo in an error message. > Please review the fix: > > issue: > https://bugs.openjdk.java.net/browse/JDK-8149105 > webrev: > http://cr.openjdk.java.net/~rschatz/JDK-8149105/webrev.00/ > > Sorry for the noise. > > Thanks, > Roland From tom.rodriguez at oracle.com Fri Feb 5 16:59:23 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 5 Feb 2016 08:59:23 -0800 Subject: RFR(XS): 8149076: [JVMCI] missing ResourceMark in JVMCIRuntime::initialize_HotSpotJVMCIRuntime In-Reply-To: <09ACC88F-5927-4585-BBF9-CEC3A188356B@oracle.com> References: <11F9B96C-B82E-4FE3-80BB-47B9910781CF@oracle.com> <09ACC88F-5927-4585-BBF9-CEC3A188356B@oracle.com> Message-ID: Thanks! tom > On Feb 5, 2016, at 8:30 AM, Igor Ignatyev wrote: > > Looks good to me too. > Thanks. >> On Feb 5, 2016, at 7:27 PM, Christian Thalinger wrote: >> >> Looks good. Igor, could you review the test changes? >> >>> On Feb 4, 2016, at 5:57 PM, Tom Rodriguez wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8149076 >>> http://cr.openjdk.java.net/~never/8149076/webrev/ >>> >>> There's no explicit ResourceMark in JVMCIRuntime::initialize_HotSpotJVMCIRuntime but generally callers have one that it can use. However calling JVMCI.getRuntime() from a newly created thread will assert because there doesn't happen to be a containing resource mark. It should just have it's own. I also modified to catch this case JVM_GetJVMCIRuntimeTest test to catch this case which required removing the unnecessary use of reflection, since this also introduced a containing ResourceMark that made the problem disappear. Tested with test case. >>> >>> tom >> > From vladimir.kozlov at oracle.com Fri Feb 5 17:26:52 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 5 Feb 2016 09:26:52 -0800 Subject: [9] RFR (XS): 8148758: Compilation fails with "this call site should not be polymorphic" In-Reply-To: <56B46A83.3020701@oracle.com> References: <56B46A83.3020701@oracle.com> Message-ID: <56B4DB5C.3040402@oracle.com> Good. Thanks, Vladimir On 2/5/16 1:25 AM, Zolt?n Maj? wrote: > Hi, > > > please review the patch for 8148758. > > https://bugs.openjdk.java.net/browse/JDK-8148758 > > > Problem: Compilation fails because the C2 compiler encounters > inconsistent profiling information. > > The reason for the failure is that the test changes the > OnStackReplacePercentage flag's value at runtime. Several other values > are computed based on the value of the OnStackReplacePercentage flag > (e.g., InvocationCounter::InterpreterBackwardBranchLimit, > MethodCounters::_interpreter_backward_branch_limit). > > As a result, changing the flag's value at runtime can put the VM into an > inconsistent state. Also, the WB API changes the value of the flag > without synchronization possibly leaving the flag in an inconsistent state. > > > Solution: The goal of IntxTest.java is to verify that getting/setting > flag values through the WB API works properly. The test changes the > flags OnStackReplacePercentage and InlineFrequencyCount. Both flags are > related only to compilation. Running the test in interpreter-only > guarantees that the VM is not put into an inconsistent state (because > the flag values are not used by the VM). > > Webrev: > http://cr.openjdk.java.net/~zmajo/8148758/webrev.00/ > > Testing: > - JPRT with failing test; > - local testing with the failing test on a linux-x86_64 system. > > Thank you and best regards, > > > Zoltan > From tatiana.pivovarova at oracle.com Fri Feb 5 18:02:08 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 5 Feb 2016 21:02:08 +0300 Subject: [9]RFR(XS): 8149135: [jittester] Makefile copies JitTesterDriver in incorrect directory and always uses default value for number-of-tests and seed Message-ID: <56B4E3A0.8060206@oracle.com> Hello! Please review the following patch for jit-tester. Makefile copies only jtreg/JitTesterDriver.java in instead full path jdk/test/lib/jittester/jtreg/JitTesterDriver.java and don't read 'number-of-tests' and 'seed' parameters from the command line arguments. bug-id: https://bugs.openjdk.java.net/browse/JDK-8149135 webrew: http://cr.openjdk.java.net/~tpivovarova/8149135/webrev.01/index.html Thanks, Tatiana -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Fri Feb 5 18:08:55 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 5 Feb 2016 21:08:55 +0300 Subject: [9]RFR(XS): 8149135: [jittester] Makefile copies JitTesterDriver in incorrect directory and always uses default value for number-of-tests and seed In-Reply-To: <56B4E3A0.8060206@oracle.com> References: <56B4E3A0.8060206@oracle.com> Message-ID: <37030DDC-6EC8-4828-8B15-F07F891496D8@oracle.com> Hi Tatiana, one minor nit : a space before before = is missed at line #38 > 38 APPLICATION_ARGS= otherwise, looks good to me Thanks, Igor > On Feb 5, 2016, at 9:02 PM, Tatiana Pivovarova wrote: > > Hello! > > Please review the following patch for jit-tester. > > Makefile copies only jtreg/JitTesterDriver.java in instead full path jdk/test/lib/jittester/jtreg/JitTesterDriver.java > and don't read 'number-of-tests' and 'seed' parameters from the command line arguments. > > bug-id: https://bugs.openjdk.java.net/browse/JDK-8149135 > webrew: http://cr.openjdk.java.net/~tpivovarova/8149135/webrev.01/index.html > > Thanks, > Tatiana From tatiana.pivovarova at oracle.com Fri Feb 5 18:17:19 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 5 Feb 2016 21:17:19 +0300 Subject: [9]RFR(XS): 8149135: [jittester] Makefile copies JitTesterDriver in incorrect directory and always uses default value for number-of-tests and seed In-Reply-To: <37030DDC-6EC8-4828-8B15-F07F891496D8@oracle.com> References: <56B4E3A0.8060206@oracle.com> <37030DDC-6EC8-4828-8B15-F07F891496D8@oracle.com> Message-ID: <56B4E72F.9030803@oracle.com> Igor, thanks for your review! I changed code accordingly your comment. Here is updated version http://cr.openjdk.java.net/~tpivovarova/8149135/webrev.03 Tatiana On 02/05/2016 09:08 PM, Igor Ignatyev wrote: > Hi Tatiana, > > one minor nit : a space before before = is missed at line #38 >> 38 APPLICATION_ARGS= > otherwise, looks good to me > > Thanks, > Igor > >> On Feb 5, 2016, at 9:02 PM, Tatiana Pivovarova wrote: >> >> Hello! >> >> Please review the following patch for jit-tester. >> >> Makefile copies only jtreg/JitTesterDriver.java in instead full path jdk/test/lib/jittester/jtreg/JitTesterDriver.java >> and don't read 'number-of-tests' and 'seed' parameters from the command line arguments. >> >> bug-id: https://bugs.openjdk.java.net/browse/JDK-8149135 >> webrew: http://cr.openjdk.java.net/~tpivovarova/8149135/webrev.01/index.html >> >> Thanks, >> Tatiana -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Fri Feb 5 19:44:11 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 5 Feb 2016 20:44:11 +0100 (CET) Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <56B4D156.4040002@oracle.com> References: <56B37387.2040204@oracle.com> <56B37D21.9070509@oracle.com> <1377731619.1635149.1454605985996.JavaMail.zimbra@u-pem.fr> <56B4D156.4040002@oracle.com> Message-ID: <1066713420.2214093.1454701451340.JavaMail.zimbra@u-pem.fr> Hi Vladimir, Maybe i should have not talking about trying to recompile the code in case of LF customization :) I'm mostly interested in specific corner cases and i think your patch is harmful for these cases. There are reasons to not inline a call even if it can inlined, by example, if the inlining tree is too deep or if the function is recursive, in those cases, the method handle is constant but the code is not inlined. I may be wrong but for me if your patch is applied, the generated code will not emit a direct call as it should do. R?mi ----- Mail original ----- > De: "Vladimir Ivanov" > ?: "Remi Forax" > Cc: "hotspot compiler" > Envoy?: Vendredi 5 F?vrier 2016 17:44:06 > Objet: Re: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization > > Remi, > > Recompilation is usually expensive and if the call site hasn't been > warmed up enough to be inlined, it is a clue it will likely never be. > > Actually, this bug is really a corner case. LF customization matters in > cases when there's no inlining possible (e.g., MH::invokeExact() on a > receiver which is not a compile-time constant). Instead of jumping > between numerous tiny nmethods for every LF in the chain, it allows to > generate a single nmethod for the whole chain. There's no need in > customization when inlining happens and customization doesn't help > inlining as well. > > In GWT case, uncommon trap is generated for non-taken branch (so causes > a recompilation if it is ever taken), but a cold branch (<30 > invocations) is compiled into a call. It could be beneficial to > recompile the branch if it becomes really hot, but it happens rarely and > requires additional profiling. > > I vaguely remember I experimented with that, but it severely affected > warmup and didn't give any peak performance improvements (usually, on > the contrarty). > > Best regards, > Vladimir Ivanov > > On 2/4/16 8:13 PM, Remi Forax wrote: > > Hi Vladimir, > > Perhaps a stupid question, but why LF customization doesn't trigger a > > recompilation if invokeBasic is already compiled into a direct call ? > > > > regards, > > R?mi > > > > ----- Mail original ----- > >> De: "Vladimir Ivanov" > >> ?: "hotspot compiler" > >> Envoy?: Jeudi 4 F?vrier 2016 17:32:33 > >> Objet: Re: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct > >> call breaks LF customization > >> > >> FYI I was asked to keep the tests intact until Jigsaw is integrated. > >> > >> Removed test changes from the webrev (updated in place) and filed > >> JDK-8149040 [1] to clean up the tests later. > >> > >> Best regards, > >> Vladimir Ivanov > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8149040 > >> > >> On 2/4/16 6:51 PM, Vladimir Ivanov wrote: > >>> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 > >>> https://bugs.openjdk.java.net/browse/JDK-8148994 > >>> > >>> JDK-8072008 [1] introduced an optimization to bypass linker calls in > >>> generated code when target method can't be inlined. > >>> > >>> Unfortunately, it doesn't work well with MH::invokeBasic(), because it > >>> clashes with LambdaForm customization: if a call is not inlined, it is > >>> important for performance to update (customize) corresponding LambdaForm > >>> on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> > >>> _from_compiled_entry traversal on every invocation, while direct call > >>> points right to the _from_compiled_entry. So, any LambdaForm updates > >>> aren't visible until recompilation. > >>> > >>> The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm > >>> instance is used on every invocation. > >>> > >>> Also, cleaned up relevant tests a bit. > >>> > >>> Testing: octane, JPRT. > >>> > >>> Best regards, > >>> Vladimir Ivanov > >>> > >>> [1] https://bugs.openjdk.java.net/browse/JDK-8072008 > >>> "Emit direct call instead of linkTo* for recursive indy/MH.invoke* > >>> calls" > >> > From vladimir.x.ivanov at oracle.com Fri Feb 5 20:11:22 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 5 Feb 2016 23:11:22 +0300 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <1066713420.2214093.1454701451340.JavaMail.zimbra@u-pem.fr> References: <56B37387.2040204@oracle.com> <56B37D21.9070509@oracle.com> <1377731619.1635149.1454605985996.JavaMail.zimbra@u-pem.fr> <56B4D156.4040002@oracle.com> <1066713420.2214093.1454701451340.JavaMail.zimbra@u-pem.fr> Message-ID: <56B501EA.4070202@oracle.com> Remi, > Maybe i should have not talking about trying to recompile the code in case of LF customization :) > > I'm mostly interested in specific corner cases and i think your patch is harmful for these cases. > > There are reasons to not inline a call even if it can inlined, by example, if the inlining tree is too deep or if the function is recursive, > in those cases, the method handle is constant but the code is not inlined. Are you talking about MH::invokeBasic? It can dispatch to LF interpreter or compiled LF. On both flavors there are @ForceInline/@DontInline annotations which guide inlining decisions. There are some limits on inlining LFs, but they are quite large (e.g., inlining depth == 100). The JITs are very aggressive about inlining through MH chains trying to the whole chain in and stop only in pathological cases. > I may be wrong but for me if your patch is applied, the generated code will not emit a direct call as it should do. What cases do you have in mind? Please, share :-) Best regards, Vladimir Ivanov > ----- Mail original ----- >> De: "Vladimir Ivanov" >> ?: "Remi Forax" >> Cc: "hotspot compiler" >> Envoy?: Vendredi 5 F?vrier 2016 17:44:06 >> Objet: Re: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization >> >> Remi, >> >> Recompilation is usually expensive and if the call site hasn't been >> warmed up enough to be inlined, it is a clue it will likely never be. >> >> Actually, this bug is really a corner case. LF customization matters in >> cases when there's no inlining possible (e.g., MH::invokeExact() on a >> receiver which is not a compile-time constant). Instead of jumping >> between numerous tiny nmethods for every LF in the chain, it allows to >> generate a single nmethod for the whole chain. There's no need in >> customization when inlining happens and customization doesn't help >> inlining as well. >> >> In GWT case, uncommon trap is generated for non-taken branch (so causes >> a recompilation if it is ever taken), but a cold branch (<30 >> invocations) is compiled into a call. It could be beneficial to >> recompile the branch if it becomes really hot, but it happens rarely and >> requires additional profiling. >> >> I vaguely remember I experimented with that, but it severely affected >> warmup and didn't give any peak performance improvements (usually, on >> the contrarty). >> >> Best regards, >> Vladimir Ivanov >> >> On 2/4/16 8:13 PM, Remi Forax wrote: >>> Hi Vladimir, >>> Perhaps a stupid question, but why LF customization doesn't trigger a >>> recompilation if invokeBasic is already compiled into a direct call ? >>> >>> regards, >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Vladimir Ivanov" >>>> ?: "hotspot compiler" >>>> Envoy?: Jeudi 4 F?vrier 2016 17:32:33 >>>> Objet: Re: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct >>>> call breaks LF customization >>>> >>>> FYI I was asked to keep the tests intact until Jigsaw is integrated. >>>> >>>> Removed test changes from the webrev (updated in place) and filed >>>> JDK-8149040 [1] to clean up the tests later. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8149040 >>>> >>>> On 2/4/16 6:51 PM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 >>>>> https://bugs.openjdk.java.net/browse/JDK-8148994 >>>>> >>>>> JDK-8072008 [1] introduced an optimization to bypass linker calls in >>>>> generated code when target method can't be inlined. >>>>> >>>>> Unfortunately, it doesn't work well with MH::invokeBasic(), because it >>>>> clashes with LambdaForm customization: if a call is not inlined, it is >>>>> important for performance to update (customize) corresponding LambdaForm >>>>> on-the-fly. MH::invokeBasic() linker does MH -> LF -> Method* -> >>>>> _from_compiled_entry traversal on every invocation, while direct call >>>>> points right to the _from_compiled_entry. So, any LambdaForm updates >>>>> aren't visible until recompilation. >>>>> >>>>> The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm >>>>> instance is used on every invocation. >>>>> >>>>> Also, cleaned up relevant tests a bit. >>>>> >>>>> Testing: octane, JPRT. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8072008 >>>>> "Emit direct call instead of linkTo* for recursive indy/MH.invoke* >>>>> calls" >>>> >> From nils.eliasson at oracle.com Sat Feb 6 07:44:19 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Sat, 6 Feb 2016 08:44:19 +0100 Subject: RFR(S): 8148696: Race loading hsdis may cause SIGSEGV In-Reply-To: <56B4C17A.3080306@oracle.com> References: <56B4BE1E.8050206@oracle.com> <56B4C17A.3080306@oracle.com> Message-ID: <56B5A453.9010300@oracle.com> Hi Vladimir, I am gulity of hasty cut paste. There is a lock disassembler.cpp:181 - just the wrong one. Still correct as long as it makes sure only one thread can execute the library load. //Nils On 2016-02-05 16:36, Vladimir Ivanov wrote: > Nils, > > Is the webrev you posted complete? I don't see any > LoadDisassembler_lock usages and all the changed paths have ttyLocker. > > Best regards, > Vladimir Ivanov > > On 2/5/16 6:22 PM, Nils Eliasson wrote: >> Hi all, >> >> Please review this fix to loading hsdis library. >> >> Summary: >> We have had two crashes on Sparc where two C2 thread simultaneously >> tries to load the hsdis library. Three of four code paths are locked by >> the ttyLocker, but the fourth is open to races. >> >> Solution: >> I chose to add another lock (mutex) for this purpose and adapted the >> code so that library_load code works as intented. >> - The old can_decode() method was removed and resued as an wrapper for >> the load_library(). >> - Fixed a typo >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148696 >> Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.01/ >> >> Regards, >> Nils Eliasson From nils.eliasson at oracle.com Sat Feb 6 07:50:47 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Sat, 6 Feb 2016 08:50:47 +0100 Subject: RFR(S): 8148696: Race loading hsdis may cause SIGSEGV In-Reply-To: <56B4D3B7.5090302@oracle.com> References: <56B4BE1E.8050206@oracle.com> <56B4D3B7.5090302@oracle.com> Message-ID: <56B5A5D7.70200@oracle.com> Hi Vladimir, On 2016-02-05 17:54, Vladimir Ivanov wrote: >> Summary: >> We have had two crashes on Sparc where two C2 thread simultaneously >> tries to load the hsdis library. Three of four code paths are locked by >> the ttyLocker, but the fourth is open to races. > I'd suggest to either add ttyLocker on the fourth path or try to move > it down the call chain to some shared code. (Keep in mind that > ttyLocker is reentrant!) Yes maybe I should just do that. The time in library check and load is probably insignificant compared to the time spent disassembling and printing. > >> Solution: >> I chose to add another lock (mutex) for this purpose and adapted the >> code so that library_load code works as intented. > Another mutex will not work - tty_lock has the lowest rank (event): > def(tty_lock , Mutex , event, true, > Monitor::_safepoint_check_never); // allow to lock in VM In my suggested code the ttylocker is not held while loading the library. The critical section is slightly smaller than before. > > I experimented with that when fixing 8071374, but decided to guard > everything with tty_lock. > > Best regards, > Vladimir Ivanov I'll have a look at the bug and post a new webrev. Thanks! Nils Eliasson > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020417.html > > "The fix is to serialize access to Disassembler on tty_lock. > Considering most of the calls to Disassembler::decode are performed > under tty_lock (which has the lowest rank), it's too burdensome to > introduce a dedicated lock and a new rank to please deadlock detection > logic." > > > >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148696 >> Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.01/ >> >> Regards, >> Nils Eliasson From hui.shi at linaro.org Sat Feb 6 11:52:19 2016 From: hui.shi at linaro.org (Hui Shi) Date: Sat, 6 Feb 2016 19:52:19 +0800 Subject: [aarch64-port-dev ] RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: <56B4B3BA.602@redhat.com> References: <56B49C8F.5030409@redhat.com> <1454682761.26562.19.camel@mint> <56B4B3BA.602@redhat.com> Message-ID: Thanks Andrew and Edward! Code sequence for backward and forward array copy is almost same except prefetch. Performance test is based on http://cr.openjdk.java.net/~hshi/8149080/testcase/StringConcatTest.java run with "java StringConcatTest 5000". I tried disabling prefetch and compare performance between backward and forward array copy (all forward with my patch, force all backward by commenting out branch to nooverlap target and force jshort_disjoint_copy generate conjoint copy), forward array copy is much faster than backward. backward is about 85s and forward copy is about 60s. This test is try to reflect common cases like string builder/buffer append and string concatenation, these are disjoint array copy and forward array copy is better than backward in following two aspects: 1. Forward array copy can prefetch dest address needed in next string append. Most string append/concatenation operations will append chars after early appened char arrays. For example, str = str1 + str2 + str3 1. when append str1 in forward order, result value array(str.value) will be prefetched beyond str1's length with hardware prefetcher 2. when store str2.value into str.value, str.value is already prefetched, less cache miss when copy str2.value into str.value If copy in backward order, after copy str1.value into str.value, it's address before str.value[0] get prefetched, this is not useful for next append. Checking following PMU events on A57 ( http://cr.openjdk.java.net/~hshi/8149080/testcase/backward.perf, http://cr.openjdk.java.net/~hshi/8149080/testcase/forward.perf), forward array copy has more accurate hardware prefetcher result (more issued request is used).Compare with/without prefetch instruction in forward copy, no performance different, hardware prefechter might good enough. 0x167 Level 2 prefetcher request used (or demanded) 0x168 Level 2 prefetcher request issued In forward array copy 94% generated request is useful (r167/r168) In backward array copy 67% issued request is usedful http://cr.openjdk.java.net/~hshi/8149080/testcase/DiscreteCopy.java testing array copy not in append mode, each array copy performs on separate address. Run with "java DiscreteCopy 3000" Forward copy takes 58s and backward array copy takes 70s. Gap is decreased. 2. Backward array copy might cause much more unaligned memory access in string append/concatenation. Current array copy implementation is: 1. peel source array address for 16 bytes alignment (backward will perform peel from source end) copy 8,4,2,1 bytes 2. perform copy_longs 3. tail copy less than 16 bytes, copy 8,4,2,1 bytes In string append/concatenation cases, source string value array is usually 8 bytes or 16 bytes align. Suppose source address is 16 byte align and size is n*16+14;. With forward array copy: n ld/st pair, then store 8 bytes align, then store 4 bytes align, then store 2 bytes align. With backward array copy need peel source end address first (checking copy_memory_small): store 8 bytes unaligned, store 4 bytes unaligned, store 2 bytes aligned, n ld/st pair. Perform unaligned access profiling with perf on DiscreteCopy, massive unaligned access for backward array copy, while not found for forward array copy. http://cr.openjdk.java.net/~hshi/8149080/testcase/AlignedDiscreteCopy.java testing array copy with 16 bytes aligned size, performance is identical for backward and forward array copy, both are about 64s. Perform forward array copy when possible will not make things worse and benefit common cases like string append/concatenation. This is the original logic when generate conjoint array copy, this patch complete this logic by recognize all disjoint array copy. Does this make sense? Regards Hui On 5 February 2016 at 22:37, Andrew Haley wrote: > On 02/05/2016 02:32 PM, Edward Nevill wrote: > > On Fri, 2016-02-05 at 12:58 +0000, Andrew Haley wrote: > >> On 02/05/2016 12:47 PM, Hui Shi wrote: > >>> Arraycopy without overlapping is faster than overlapped copy. > >> > >> The only thing which varies is the direction of copying. I'm not > >> aware of anything which makes one direction faster than the other. > >> Measurements, please. > > > > Copy backwards doesn't prefetch. The difference with and without > > prefetch can be very significant on some micro-arches. > > > > if (direction == copy_forwards && PrefetchCopyIntervalInBytes > 0) > > __ prfm(Address(s, PrefetchCopyIntervalInBytes), PLDL1KEEP); > > > > I have done some experiments with prefetch enabled for backwards copy > > and it shows almost identical performance to forwards copy. > > OK, so let's do that, then. > > Andrew. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hui.shi at linaro.org Sat Feb 6 12:24:03 2016 From: hui.shi at linaro.org (Hui Shi) Date: Sat, 6 Feb 2016 20:24:03 +0800 Subject: RFR(s): AAch64: Adding byte array equal support Message-ID: Hi All, Would someone help review this patch for adding byte array equal support on aarch64? bug: https://bugs.openjdk.java.net/browse/JDK-8149100 webrev: http://cr.openjdk.java.net/~hshi/8149100/webrev/ For http://cr.openjdk.java.net/~hshi/8149100/testcase/ArrayEqual.java, debug build run will failed with ?bad AD file? assertion on aarch64. # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/matcher.cpp:1605 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/shihui/jdk9-hs-comp/hotspot/src/share/vm/opto/matcher.cpp:1605), pid=8501, tid=8746 # assert(false) failed: bad AD file # Debugg shows AryEqNode?s enconding is StrIntrinsicNode::LL, which is not supported on aarch64 now. 1605 assert( false, "bad AD file" ); (gdb) p ((AryEqNode*)n)->encoding() $1 = StrIntrinsicNode::LL (gdb) Fix is adding support for StrIntrinsicNode::LL encoding array equal operation, as Latin String compare might become important in JDK9 with new String. 1. Adding MacroAssembler::byte_arrays_equals to support byte array equals check. 2. Add new array_equalsB rule when AryEq enconding is StrIntrinsicNode::LL. http://cr.openjdk.java.net/~hshi/8149100/testcase/byte_array_equals.asm shows newly generated assembly. Relase build will invoke Array.equals method before this patch, with this patch, significant improvment on ArrayEqual case. time -p openjdk-9-internal.base/bin/java ArrayEqual real 54.98 user 55.13 time -p openjdk-9-internal.byteEquals/bin/java ArrayEqual real 28.59 user 28.62 sys 0.14 Following code sequence can be replaced with tbz (when tst has constant exactly two?s n times value), these code sequence exist in other places(MacroAssembler::char_arrays_equals, interpreter, etc). I would like clean all together in another separate changeset. tst(cnt1, 0b10); br(EQ, TAIL01); Regards Hui -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Sun Feb 7 10:24:39 2016 From: aph at redhat.com (Andrew Haley) Date: Sun, 7 Feb 2016 10:24:39 +0000 Subject: [aarch64-port-dev ] RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: References: <56B49C8F.5030409@redhat.com> <1454682761.26562.19.camel@mint> <56B4B3BA.602@redhat.com> Message-ID: <56B71B67.8080304@redhat.com> On 06/02/16 11:52, Hui Shi wrote: > Code sequence for backward and forward array copy is almost same > except prefetch. Performance test is based on > http://cr.openjdk.java.net/~hshi/8149080/testcase/StringConcatTest.java > run with "java StringConcatTest 5000". I tried disabling prefetch > and compare performance between backward and forward array copy (all > forward with my patch, force all backward by commenting out branch > to nooverlap target and force jshort_disjoint_copy generate conjoint > copy), forward array copy is much faster than backward. backward is > about 85s and forward copy is about 60s. > > This test is try to reflect common cases like string builder/buffer > append and string concatenation, these are disjoint array copy and > forward array copy is better than backward in following two aspects: You're confusing me. String concatenation is a disjoint array copy. Therefore it always copies forwards, does it not? > 1. Forward array copy can prefetch dest address needed in next string > append. So can backwards array copy, surely. > 2. Backward array copy might cause much more unaligned memory access in > string append/concatenation. Okay, I see. That is fixable: we can make sure that there are no more misaligned accesses in either direction. > Perform forward array copy when possible will not make things worse and > benefit common cases like string append/concatenation. This is the original > logic when generate conjoint array copy, this patch complete this logic by > recognize all disjoint array copy. Does this make sense? Yes, but it's a kludge. I'd much rather fix backwards copies so that they were just as fast. If that's not possible then your patch may be acceptable, but I think we should first try to fix backwards copies. We should be able to fix this the *right way*, by using prefetch instructions and making sure copies are aligned where possible. When I did my testing misaligned fetches were quite fast, and it didn't seem worth the effort to fix it. But I'm really mystified by why String concatenation doesn't always use forward copies anyway. Andrew. From aph at redhat.com Sun Feb 7 10:35:10 2016 From: aph at redhat.com (Andrew Haley) Date: Sun, 7 Feb 2016 10:35:10 +0000 Subject: RFR(s): AAch64: Adding byte array equal support In-Reply-To: References: Message-ID: <56B71DDE.2040109@redhat.com> On 06/02/16 12:24, Hui Shi wrote: > Hi All, > > Would someone help review this patch for adding byte array equal support on > aarch64? > > bug: https://bugs.openjdk.java.net/browse/JDK-8149100 > webrev: http://cr.openjdk.java.net/~hshi/8149100/webrev/ Ok, thanks. > Following code sequence can be replaced with tbz (when tst has constant > exactly two?s n times value), these code sequence exist in other > places(MacroAssembler::char_arrays_equals, interpreter, etc). I would like > clean all together in another separate changeset. > tst(cnt1, 0b10); > br(EQ, TAIL01); Right. Andrew. From david.holmes at oracle.com Mon Feb 8 00:24:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Feb 2016 10:24:19 +1000 Subject: RFR: 8148507: [JVMCI] mitigate deadlocks related to JVMCI compiler under -Xbatch In-Reply-To: References: <845F1D56-3194-49AE-95C1-79545F8C50AC@oracle.com> <3F2DB53D-5308-4745-97F6-7EF35DF99A52@oracle.com> <00D38633-F4E3-47D0-800C-9A45893354E2@oracle.com> Message-ID: <56B7E033.9080708@oracle.com> On 6/02/2016 2:34 AM, Christian Thalinger wrote: > Looks good to me. David, any comments? Just two observations: 1. The methods_compiler counter could overflow. That won't affect the progress check but I don't know if it impacts any other code that uses it. 2. wait_for_jvmci_completion can still fail to return for arbitrarily long periods of time if compilation progresses but at a very slow rate. Thanks, David >> On Feb 4, 2016, at 12:36 PM, Doug Simon wrote: >> >> I?ve updated the webrev in situ for reasons discussed here: >> >> https://bugs.openjdk.java.net/browse/JDK-8148507?focusedCommentId=13896252&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896252 >> >> >>> On 03 Feb 2016, at 20:42, Christian Thalinger wrote: >>> >>> There was some discussion in the bug report but I seems like we are going to integrate this change. >>> >>>> On Jan 31, 2016, at 5:48 AM, Christian Thalinger wrote: >>>> >>>> Looks good. >>>> >>>>> On Jan 29, 2016, at 4:34 PM, Doug Simon wrote: >>>>> >>>>> Please review this small change to further mitigate deadlocks that can be caused by JVMCI when BackgroundCompilation is disabled. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8148507 >>>>> http://cr.openjdk.java.net/~dnsimon/8148507 >>>>> >>>>> -Doug >>>> >>> >> > From zoltan.majo at oracle.com Mon Feb 8 07:35:51 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 8 Feb 2016 08:35:51 +0100 Subject: [9] RFR (XS): 8148758: Compilation fails with "this call site should not be polymorphic" In-Reply-To: <56B4DB5C.3040402@oracle.com> References: <56B46A83.3020701@oracle.com> <56B4DB5C.3040402@oracle.com> Message-ID: <56B84557.6030902@oracle.com> Thank you, Vladimir, for the review! Best regards, Zoltan On 02/05/2016 06:26 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 2/5/16 1:25 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the patch for 8148758. >> >> https://bugs.openjdk.java.net/browse/JDK-8148758 >> >> >> Problem: Compilation fails because the C2 compiler encounters >> inconsistent profiling information. >> >> The reason for the failure is that the test changes the >> OnStackReplacePercentage flag's value at runtime. Several other values >> are computed based on the value of the OnStackReplacePercentage flag >> (e.g., InvocationCounter::InterpreterBackwardBranchLimit, >> MethodCounters::_interpreter_backward_branch_limit). >> >> As a result, changing the flag's value at runtime can put the VM into an >> inconsistent state. Also, the WB API changes the value of the flag >> without synchronization possibly leaving the flag in an inconsistent >> state. >> >> >> Solution: The goal of IntxTest.java is to verify that getting/setting >> flag values through the WB API works properly. The test changes the >> flags OnStackReplacePercentage and InlineFrequencyCount. Both flags are >> related only to compilation. Running the test in interpreter-only >> guarantees that the VM is not put into an inconsistent state (because >> the flag values are not used by the VM). >> >> Webrev: >> http://cr.openjdk.java.net/~zmajo/8148758/webrev.00/ >> >> Testing: >> - JPRT with failing test; >> - local testing with the failing test on a linux-x86_64 system. >> >> Thank you and best regards, >> >> >> Zoltan >> From zoltan.majo at oracle.com Mon Feb 8 08:09:47 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 8 Feb 2016 09:09:47 +0100 Subject: [9] RFR (XS): 8148758: Compilation fails with "this call site should not be polymorphic" In-Reply-To: <56B84557.6030902@oracle.com> References: <56B46A83.3020701@oracle.com> <56B4DB5C.3040402@oracle.com> <56B84557.6030902@oracle.com> Message-ID: <56B84D4B.1080508@oracle.com> Hi, as I mentioned earlier, we have to also unquarantine the failing test. So, for the record, here is the changeset I'm pushing: http://cr.openjdk.java.net/~zmajo/8148758/webrev.01/ Best regards, Zoltan On 02/08/2016 08:35 AM, Zolt?n Maj? wrote: > Thank you, Vladimir, for the review! > > Best regards, > > > Zoltan > > On 02/05/2016 06:26 PM, Vladimir Kozlov wrote: >> Good. >> >> Thanks, >> Vladimir >> >> On 2/5/16 1:25 AM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the patch for 8148758. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8148758 >>> >>> >>> Problem: Compilation fails because the C2 compiler encounters >>> inconsistent profiling information. >>> >>> The reason for the failure is that the test changes the >>> OnStackReplacePercentage flag's value at runtime. Several other values >>> are computed based on the value of the OnStackReplacePercentage flag >>> (e.g., InvocationCounter::InterpreterBackwardBranchLimit, >>> MethodCounters::_interpreter_backward_branch_limit). >>> >>> As a result, changing the flag's value at runtime can put the VM >>> into an >>> inconsistent state. Also, the WB API changes the value of the flag >>> without synchronization possibly leaving the flag in an inconsistent >>> state. >>> >>> >>> Solution: The goal of IntxTest.java is to verify that getting/setting >>> flag values through the WB API works properly. The test changes the >>> flags OnStackReplacePercentage and InlineFrequencyCount. Both flags are >>> related only to compilation. Running the test in interpreter-only >>> guarantees that the VM is not put into an inconsistent state (because >>> the flag values are not used by the VM). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~zmajo/8148758/webrev.00/ >>> >>> Testing: >>> - JPRT with failing test; >>> - local testing with the failing test on a linux-x86_64 system. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > From filipp.zhinkin at gmail.com Mon Feb 8 08:22:23 2016 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Mon, 8 Feb 2016 11:22:23 +0300 Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down fastdebug builds' performance In-Reply-To: <56B489D0.3070700@oracle.com> References: <54F99281.7020101@oracle.com> <56B489D0.3070700@oracle.com> Message-ID: Hi Vladimir, thanks for looking at this thread. I'll provide an updated webrev within this week. Regards, Filipp. On Fri, Feb 5, 2016 at 2:38 PM, Vladimir Ivanov wrote: > (I'd like to revive the thread. It still affects our testing.) > > Filipp, > > Overall, the approach you propose looks good. > > What I'd like to see is unified binary_search implementation being used. > > There are already many places where custom implementations are used [1] [2] > [3] and I don't want to see one more. Please, factor it out. > GrowableArray::find_sorted looks like a good candidate (but it suffers from > an overflow). > > Let me know if you don't have time to work on it. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a34b3268a14f/src/share/vm/oops/instanceKlass.cpp#l1360 > > [2] > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a34b3268a14f/src/share/vm/utilities/growableArray.hpp#l391 > > [3] > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a34b3268a14f/src/share/vm/gc/g1/g1CollectorPolicy.cpp#l659 > > > On 3/23/15 1:40 PM, Filipp Zhinkin wrote: >> >> Hi all, >> >> sorry for a late reply. >> >> I don't think that it's possible to remove is_sorted assertion from >> create_unhandled_lists, because it's crucial condition for a linear >> scan allocation algorithm and it's pretty easy to break it incidentally. >> Existing assertion could significantly reduce time required to locate >> an issue when something will go wrong. >> >> However, I believe that it could be relaxed to check only that >> intervals in _sorted_intervals list are actually ordered and that >> _new_intervals_from_allocation list is empty (in sorting methods >> we still will be verifying that sorted and unsorted lists contain >> same intervals). >> >> What do you guys think about that? >> >> Regards, >> Filippp. >> >> >> On Fri, Mar 6, 2015 at 9:24 PM, Filipp Zhinkin >> wrote: >>> >>> Hi Aleksey, >>> >>> thanks for looking at it! >>> >>> On Fri, Mar 6, 2015 at 2:41 PM, Aleksey Shipilev >>> wrote: >>>> >>>> Hi Filipp, >>>> >>>> On 06.03.2015 14:33, Filipp Zhinkin wrote: >>>>> >>>>> In certain cases (like -client -Xcomp) C1 compilation is very slow >>>>> w/ fastdebug builds. A place where we spent enormous amount of time >>>>> is LinearScan::is_sorted method, which simply verifies that a list >>>>> that should be sorted is actually sorted and that both sorted and >>>>> unsorted lists contains same intervals. >>>> >>>> >>>> Okay, what caller of is_sorted dominates? Maybe instead of optimizing >>>> the is_sorted itself, you need to move/relax the assert in some selected >>>> places? >>> >>> >>> Well, the dominating caller is LinearScan::create_unhandled_lists [1]. >>> >>>> >>>> That is to say I am not fond of complicating the non-product code that >>>> does verification without a compelling reason to do so; let's first >>>> figure out if we "just" do excess asserts. >>> >>> >>> That's a good point. I'll try to figure a out if an assertion is placed >>> to be >>> sure that all methods called in the right sequence and if it's true, then >>> it may be better to use less expensive approach. >>> >>> Thanks, >>> Filipp. >>> >>> [1] >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/de7ca28f8b7d/src/share/vm/c1/c1_LinearScan.cpp#l1486 >>> >>>> >>>> Thanks, >>>> -Aleksey. >>>> > From edward.nevill at gmail.com Mon Feb 8 08:39:00 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 08 Feb 2016 08:39:00 +0000 Subject: [aarch64-port-dev ] RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: References: <56B49C8F.5030409@redhat.com> <1454682761.26562.19.camel@mint> <56B4B3BA.602@redhat.com> Message-ID: <1454920740.26562.28.camel@mint> On Sat, 2016-02-06 at 19:52 +0800, Hui Shi wrote: > Code sequence for backward and forward array copy is almost same except prefetch. Performance test is based on http://cr.openjdk.java.net/~hshi/8149080/testcase/StringConcatTest.java run with "java StringConcatTest 5000". I tried disabling prefetch and compare performance between backward and forward array copy (all Hi, How did you disable the prefetch? Did you use -XX:PrefetchCopyIntervalInBytes=0? There is a bug/feature in vm_version_aarch64.cpp where it does FLAG_SET_DEFAULT(PrefetchCopyIntervalInBytes, 256); overwriting any previous value, whereas it should do if (FLAG_IS_DEFAULT(PrefetchCopyIntervalInBytes)) FLAG_SET_DEFAULT(PrefetchCopyIntervalInBytes, 256); > 1. Forward array copy can prefetch dest address needed in next string append. > > Most string append/concatenation operations will append chars after early appened char arrays. > For example, str = str1 + str2 + str3 > 1. when append str1 in forward order, result value array(str.value) will be prefetched beyond str1's length with hardware prefetcher > 2. when store str2.value into str.value, str.value is already prefetched, less cache miss when copy str2.value into str.value > If copy in backward order, after copy str1.value into str.value, it's address before str.value[0] get prefetched, this is not useful for next append. I assume you are talking about automatic hardware prefetching here since the SW implementation does not do any prefetching on the destination? In that case I can see how repeated forward copys may be more efficient for string concatenation. All the best, Ed. From tobias.hartmann at oracle.com Mon Feb 8 10:38:42 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 8 Feb 2016 11:38:42 +0100 Subject: More SIGSEGV problems with JDK9 EA build 102 In-Reply-To: <001301d16003$ec21edf0$c465c9d0$@apache.org> References: <001301d16003$ec21edf0$c465c9d0$@apache.org> Message-ID: <56B87032.6010302@oracle.com> Hi Uwe, thanks for the information. Please see comments inline. On 05.02.2016 11:56, Uwe Schindler wrote: > Hi Hotspot team, > > we are testing build 102 of JDK 9 EA builds (without Jigsaw). Previously we were using build 94 without any problems (except the compact strings problem, that we worked around using the "-XX:-CompactStrings" flag). Tobias told me that the problem should be fixed in later EA builds. > > With build 102 we got multiple SIGSEGVs or test assertions failed in our code (see also the talk about our randomized testing on FOSDEM). One of these issues looks like the https://bugs.openjdk.java.net/browse/JDK-8148490 issue. By applying "-XX:-UseSuperWord" the problems disappeared (we have some classes in Lucene, e.g., CompressingTermVectorsWriter.java, which are very sensitive to vectorization and failures there are almost always AVX optimization problems, so it was quite clear that the issue was AVX). Once this is fixed and part of EA builds, we can reenable super words in testing, for now we leave them disabled. Yes, both JDK-8144212 and JDK-8148490 are fixed and should be included in one of the next EA releases. You can track this by looking at the "Resolved In Build" field. > But even with "-XX:-UseSuperWord -XX:-CompactStrings" passed on command line, we still get on every 3rd run a crush / test failure (32 bits more often, but 64 bits also sometimes). The failures are in most cases SIGSEGV at various places inside the JVM or libc. We also get "invalid pointer" on free(). As said before, no problems with build 94, but happens all the time with build 102. > > Does anybody has some idea what could be the problem? The crushes look like this: > > 3 SIGSEGVs: > [junit4] >>> JVM J2 emitted unexpected output (verbatim) ---- > [junit4] # > [junit4] # A fatal error has been detected by the Java Runtime Environment: > [junit4] # > [junit4] # SIGSEGV (0xb) at pc=0x00007fc2be539edc, pid=10944, tid=11054 > [junit4] # > [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+102) (build 9-ea+102-2016-01-21-001533.javare.4316.nc) > [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (9-ea+102-2016-01-21-001533.javare.4316.nc, mixed mode, tiered, g1 gc, linux-amd64) > [junit4] # Problematic frame: > [junit4] # C [libc.so.6+0x7fedc][thread 12464 also had an error] > [junit4] # [ timer expired, abort... ] > [junit4] <<< JVM J2: EOF ---- Not enough information here. We need a full stack trace or the hs_err file. > [junit4] >>> JVM J2 emitted unexpected output (verbatim) ---- > [junit4] # > [junit4] # A fatal error has been detected by the Java Runtime Environment: > [junit4] # > [junit4] # SIGSEGV (0xb) at pc=0xf6ac0445, pid=13204, tid=13307 > [junit4] # > [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+102) (build 9-ea+102-2016-01-21-001243.javare.4316.nc) > [junit4] # Java VM: Java HotSpot(TM) Server VM (9-ea+102-2016-01-21-001243.javare.4316.nc, mixed mode, tiered, g1 gc, linux-x86) > [junit4] # Problematic frame: > [junit4] # V [libjvm.so+0x241445] ChunkPool::allocate(unsigned int, AllocFailStrategy::AllocFailEnum)+0x25 > [junit4] # > [junit4] # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > [junit4] # > [junit4] # An error report file with more information is saved as: > [junit4] # /home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/backward-codecs/test/J2/hs_err_pid13204.log > [junit4] > [junit4] [error occurred during error reporting , id 0xb] > [junit4] > [junit4] # > [junit4] # If you would like to submit a bug report, please visit: > [junit4] # http://bugreport.java.com/bugreport/crash.jsp > [junit4] # > [junit4] <<< JVM J2: EOF ---- Haven't seen this before. Probably a runtime/gc issue. > [junit4] >>> JVM J2 emitted unexpected output (verbatim) ---- > [junit4] # > [junit4] # A fatal error has been detected by the Java Runtime Environment: > [junit4] # > [junit4] # SIGSEGV (0xb) at pc=0xf7249300, pid=31605, tid=31729 > [junit4] # > [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+102) (build 9-ea+102-2016-01-21-001243.javare.4316.nc) > [junit4] # Java VM: Java HotSpot(TM) Server VM (9-ea+102-2016-01-21-001243.javare.4316.nc, mixed mode, tiered, g1 gc, linux-x86) > [junit4] # Problematic frame: > [junit4] # V [libjvm.so+0x9b3300] Type::cmp(Type const*, Type const*)+0x10 > [junit4] # > [junit4] # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > [junit4] # > [junit4] # An error report file with more information is saved as: > [junit4] # /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J2/hs_err_pid31605.log > [junit4] # > [junit4] # Compiler replay data is saved as: > [junit4] # /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J2/replay_pid31605.log > [junit4] # > [junit4] # If you would like to submit a bug report, please visit: > [junit4] # http://bugreport.java.com/bugreport/crash.jsp > [junit4] # > [junit4] <<< JVM J2: EOF ---- This could be a compiler issue. But again, we need more information. > "invalid pointer" on free(): > > [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/test-framework/test/temp/junit4-J0-20160204_124703_166.syserr > [junit4] >>> JVM J0 emitted unexpected output (verbatim) ---- > [junit4] *** Error in `/home/jenkins/tools/java/64bit/jdk-9-ea+102/bin/java': free(): invalid pointer: 0x00007f74bd485960 *** > [junit4] <<< JVM J0: EOF ---- > > [junit4] JVM J0: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/test-framework/test/temp/junit4-J0-20160203_223446_729.syserr > [junit4] >>> JVM J0 emitted unexpected output (verbatim) ---- > [junit4] *** Error in `/home/jenkins/tools/java/64bit/jdk-9-ea+102/bin/java': free(): invalid pointer: 0x00007f53c8b0ece0 *** > [junit4] <<< JVM J0: EOF ---- > > (after that it exited with exit code 134) > > I don't have the hs_err.pid files for all failures anymore (because they are deleted after 20 Jenkins Job runs), but I can provide them if needed - for the recent ones I clicked on "preserve" on the Jenkins Job (sorry for not doing that earlier!). Yes, please provide the hs_err files if the failures still occur with the latest EA build. Thanks, Tobias > I just wanted to know if anybody has an idea what could cause this. > Today I have seen a patch for this issue: 8149038: SIGSEGV at frame::is_interpreted_frame_valid -> StubRoutines::SafeFetchN (could be related). > > Kind regards and thanks for the nice FOSDEM meeting last week, > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > From hui.shi at linaro.org Mon Feb 8 11:55:34 2016 From: hui.shi at linaro.org (Hui Shi) Date: Mon, 8 Feb 2016 19:55:34 +0800 Subject: [aarch64-port-dev ] RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: <56B71B67.8080304@redhat.com> References: <56B49C8F.5030409@redhat.com> <1454682761.26562.19.camel@mint> <56B4B3BA.602@redhat.com> <56B71B67.8080304@redhat.com> Message-ID: Thanks Andrew! > You're confusing me. String concatenation is a disjoint array copy. > Therefore it always copies forwards, does it not? > Yes, it would be better JIT can recognize this at compile time. Previous performance data is collected on Java8 (so copy is performed in short array copy, while in JDK9 it is byte array copy). I check both JDK8 and JDK9, both invoke Stub::jshort_arraycopy and Stub::jbyte_arraycopy. One reason might be JIT time determination is not important as there is run time check for disjoint array copy. > > 1. Forward array copy can prefetch dest address needed in next string > > append. > > So can backwards array copy, surely. > Could you please give more details about how backward array copy can also utilize hardware prefetcher in multiple string append case? > > > 2. Backward array copy might cause much more unaligned memory access in > > string append/concatenation. > > Okay, I see. That is fixable: we can make sure that there are no > more misaligned accesses in either direction. > > > Perform forward array copy when possible will not make things worse and > > benefit common cases like string append/concatenation. This is the > original > > logic when generate conjoint array copy, this patch complete this logic > by > > recognize all disjoint array copy. Does this make sense? > > Yes, but it's a kludge. I'd much rather fix backwards copies so that > they were just as fast. If that's not possible then your patch may be > acceptable, but I think we should first try to fix backwards copies. > We should be able to fix this the *right way*, by using prefetch > instructions and making sure copies are aligned where possible. When > I did my testing misaligned fetches were quite fast, and it didn't > seem worth the effort to fix it. > > I agree inserting prefetch in backward copy and make backward array copy more faster. For mis-aligned issue in backward array copy, we might copy in 1,2,4,8 order to make it align. > But I'm really mystified by why String concatenation doesn't always > use forward copies anyway. > > Andrew. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hui.shi at linaro.org Mon Feb 8 11:58:15 2016 From: hui.shi at linaro.org (Hui Shi) Date: Mon, 8 Feb 2016 19:58:15 +0800 Subject: [aarch64-port-dev ] RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: <1454920740.26562.28.camel@mint> References: <56B49C8F.5030409@redhat.com> <1454682761.26562.19.camel@mint> <56B4B3BA.602@redhat.com> <1454920740.26562.28.camel@mint> Message-ID: Thanks Edward! > > > How did you disable the prefetch? Did you use > -XX:PrefetchCopyIntervalInBytes=0? I disable prefetch by removing prefetch in stub code and rebuild. > > > > 1. Forward array copy can prefetch dest address needed in next string > append. > > > > Most string append/concatenation operations will append chars after > early appened char arrays. > > For example, str = str1 + str2 + str3 > > 1. when append str1 in forward order, result value array(str.value) > will be prefetched beyond str1's length with hardware prefetcher > > 2. when store str2.value into str.value, str.value is already > prefetched, less cache miss when copy str2.value into str.value > > If copy in backward order, after copy str1.value into str.value, it's > address before str.value[0] get prefetched, this is not useful for next > append. > > I assume you are talking about automatic hardware prefetching here since > the SW implementation does not do any prefetching on the destination? In > that case I can see how repeated forward copys may be more efficient for > string concatenation. > > Yes, its hardware prefecher. perf profiling get the hardware generated perfecher issued and used. and forward hardware prefetcher hit rate is much higher in forward array copy. Regards Hui -------------- next part -------------- An HTML attachment was scrubbed... URL: From hui.shi at linaro.org Mon Feb 8 11:59:40 2016 From: hui.shi at linaro.org (Hui Shi) Date: Mon, 8 Feb 2016 19:59:40 +0800 Subject: RFR(s): AAch64: Adding byte array equal support In-Reply-To: <56B71DDE.2040109@redhat.com> References: <56B71DDE.2040109@redhat.com> Message-ID: Thanks Andrew! Could someone help push this change? Regards Hui On 7 February 2016 at 18:35, Andrew Haley wrote: > On 06/02/16 12:24, Hui Shi wrote: > > Hi All, > > > > Would someone help review this patch for adding byte array equal support > on > > aarch64? > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8149100 > > webrev: http://cr.openjdk.java.net/~hshi/8149100/webrev/ > > Ok, thanks. > > > Following code sequence can be replaced with tbz (when tst has constant > > exactly two?s n times value), these code sequence exist in other > > places(MacroAssembler::char_arrays_equals, interpreter, etc). I would > like > > clean all together in another separate changeset. > > tst(cnt1, 0b10); > > br(EQ, TAIL01); > > Right. > > Andrew. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.eliasson at oracle.com Mon Feb 8 13:24:22 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 8 Feb 2016 14:24:22 +0100 Subject: RFR(S): 8148696: Race loading hsdis may cause SIGSEGV In-Reply-To: <56B5A5D7.70200@oracle.com> References: <56B4BE1E.8050206@oracle.com> <56B4D3B7.5090302@oracle.com> <56B5A5D7.70200@oracle.com> Message-ID: <56B89706.5070209@oracle.com> The link to JDK-8071374 was informative, Thanks! Here is a webrev with just a ttyLocker on the missing path (Disassembler::can_decode) Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.02/ Best regards, Nils Eliasson On 2016-02-06 08:50, Nils Eliasson wrote: > Hi Vladimir, > > On 2016-02-05 17:54, Vladimir Ivanov wrote: >>> Summary: >>> We have had two crashes on Sparc where two C2 thread simultaneously >>> tries to load the hsdis library. Three of four code paths are locked by >>> the ttyLocker, but the fourth is open to races. >> I'd suggest to either add ttyLocker on the fourth path or try to move >> it down the call chain to some shared code. (Keep in mind that >> ttyLocker is reentrant!) > > Yes maybe I should just do that. The time in library check and load is > probably insignificant compared to the time spent disassembling and > printing. > >> >>> Solution: >>> I chose to add another lock (mutex) for this purpose and adapted the >>> code so that library_load code works as intented. >> Another mutex will not work - tty_lock has the lowest rank (event): >> def(tty_lock , Mutex , event, true, >> Monitor::_safepoint_check_never); // allow to lock in VM > > In my suggested code the ttylocker is not held while loading the > library. The critical section is slightly smaller than before. > >> >> I experimented with that when fixing 8071374, but decided to guard >> everything with tty_lock. >> >> Best regards, >> Vladimir Ivanov > > I'll have a look at the bug and post a new webrev. > > Thanks! > Nils Eliasson > >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020417.html >> >> "The fix is to serialize access to Disassembler on tty_lock. >> Considering most of the calls to Disassembler::decode are performed >> under tty_lock (which has the lowest rank), it's too burdensome to >> introduce a dedicated lock and a new rank to please deadlock >> detection logic." >> >> >> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148696 >>> Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.01/ >>> >>> Regards, >>> Nils Eliasson > From vladimir.x.ivanov at oracle.com Mon Feb 8 13:30:08 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 8 Feb 2016 16:30:08 +0300 Subject: RFR(S): 8148696: Race loading hsdis may cause SIGSEGV In-Reply-To: <56B89706.5070209@oracle.com> References: <56B4BE1E.8050206@oracle.com> <56B4D3B7.5090302@oracle.com> <56B5A5D7.70200@oracle.com> <56B89706.5070209@oracle.com> Message-ID: <56B89860.8080601@oracle.com> Looks good. Best regards, Vladimir Ivanov On 2/8/16 4:24 PM, Nils Eliasson wrote: > The link to JDK-8071374 was informative, Thanks! > > Here is a webrev with just a ttyLocker on the missing path > (Disassembler::can_decode) > > Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.02/ > > Best regards, > Nils Eliasson > > On 2016-02-06 08:50, Nils Eliasson wrote: >> Hi Vladimir, >> >> On 2016-02-05 17:54, Vladimir Ivanov wrote: >>>> Summary: >>>> We have had two crashes on Sparc where two C2 thread simultaneously >>>> tries to load the hsdis library. Three of four code paths are locked by >>>> the ttyLocker, but the fourth is open to races. >>> I'd suggest to either add ttyLocker on the fourth path or try to move >>> it down the call chain to some shared code. (Keep in mind that >>> ttyLocker is reentrant!) >> >> Yes maybe I should just do that. The time in library check and load is >> probably insignificant compared to the time spent disassembling and >> printing. >> >>> >>>> Solution: >>>> I chose to add another lock (mutex) for this purpose and adapted the >>>> code so that library_load code works as intented. >>> Another mutex will not work - tty_lock has the lowest rank (event): >>> def(tty_lock , Mutex , event, true, >>> Monitor::_safepoint_check_never); // allow to lock in VM >> >> In my suggested code the ttylocker is not held while loading the >> library. The critical section is slightly smaller than before. >> >>> >>> I experimented with that when fixing 8071374, but decided to guard >>> everything with tty_lock. >>> >>> Best regards, >>> Vladimir Ivanov >> >> I'll have a look at the bug and post a new webrev. >> >> Thanks! >> Nils Eliasson >> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020417.html >>> >>> >>> "The fix is to serialize access to Disassembler on tty_lock. >>> Considering most of the calls to Disassembler::decode are performed >>> under tty_lock (which has the lowest rank), it's too burdensome to >>> introduce a dedicated lock and a new rank to please deadlock >>> detection logic." >>> >>> >>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148696 >>>> Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.01/ >>>> >>>> Regards, >>>> Nils Eliasson >> > From nils.eliasson at oracle.com Mon Feb 8 13:44:46 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 8 Feb 2016 14:44:46 +0100 Subject: RFR(S): 8148696: Race loading hsdis may cause SIGSEGV In-Reply-To: <56B89860.8080601@oracle.com> References: <56B4BE1E.8050206@oracle.com> <56B4D3B7.5090302@oracle.com> <56B5A5D7.70200@oracle.com> <56B89706.5070209@oracle.com> <56B89860.8080601@oracle.com> Message-ID: <56B89BCE.5030203@oracle.com> Thank you Vladimir! Best regards, Nils Eliasson On 2016-02-08 14:30, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 2/8/16 4:24 PM, Nils Eliasson wrote: >> The link to JDK-8071374 was informative, Thanks! >> >> Here is a webrev with just a ttyLocker on the missing path >> (Disassembler::can_decode) >> >> Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.02/ >> >> Best regards, >> Nils Eliasson >> >> On 2016-02-06 08:50, Nils Eliasson wrote: >>> Hi Vladimir, >>> >>> On 2016-02-05 17:54, Vladimir Ivanov wrote: >>>>> Summary: >>>>> We have had two crashes on Sparc where two C2 thread simultaneously >>>>> tries to load the hsdis library. Three of four code paths are >>>>> locked by >>>>> the ttyLocker, but the fourth is open to races. >>>> I'd suggest to either add ttyLocker on the fourth path or try to move >>>> it down the call chain to some shared code. (Keep in mind that >>>> ttyLocker is reentrant!) >>> >>> Yes maybe I should just do that. The time in library check and load is >>> probably insignificant compared to the time spent disassembling and >>> printing. >>> >>>> >>>>> Solution: >>>>> I chose to add another lock (mutex) for this purpose and adapted the >>>>> code so that library_load code works as intented. >>>> Another mutex will not work - tty_lock has the lowest rank (event): >>>> def(tty_lock , Mutex , event, true, >>>> Monitor::_safepoint_check_never); // allow to lock in VM >>> >>> In my suggested code the ttylocker is not held while loading the >>> library. The critical section is slightly smaller than before. >>> >>>> >>>> I experimented with that when fixing 8071374, but decided to guard >>>> everything with tty_lock. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>> >>> I'll have a look at the bug and post a new webrev. >>> >>> Thanks! >>> Nils Eliasson >>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020417.html >>>> >>>> >>>> >>>> "The fix is to serialize access to Disassembler on tty_lock. >>>> Considering most of the calls to Disassembler::decode are performed >>>> under tty_lock (which has the lowest rank), it's too burdensome to >>>> introduce a dedicated lock and a new rank to please deadlock >>>> detection logic." >>>> >>>> >>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148696 >>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8148696/webrev.01/ >>>>> >>>>> Regards, >>>>> Nils Eliasson >>> >> From aph at redhat.com Mon Feb 8 14:32:44 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Feb 2016 14:32:44 +0000 Subject: [aarch64-port-dev ] RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: References: <56B49C8F.5030409@redhat.com> <1454682761.26562.19.camel@mint> <56B4B3BA.602@redhat.com> <56B71B67.8080304@redhat.com> Message-ID: <56B8A70C.6050300@redhat.com> On 08/02/16 11:55, Hui Shi wrote: > Could you please give more details about how backward array copy can also > utilize hardware prefetcher in multiple string append case? I do not understand this question. There is AFAIK no "multiple string append case": string concatenation is done by a single array copy, and multiple concatenations are done as several array copies. Therefore, all we have to do is make sure that char/byte array copies are fast in both directions. And if the problem is prefetching, we know how to do that. Andrew. From edward.nevill at gmail.com Mon Feb 8 14:37:26 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 08 Feb 2016 14:37:26 +0000 Subject: RFR: 8149365: memory copy does not prefetch on backwards copy Message-ID: <1454942246.11423.18.camel@mint> Hi, The following webrev http://cr.openjdk.java.net/~enevill/8149365/webrev.0/ adds support for prefetch on backwards copies (previously prefetch was only done on forwards copies). It also fixes a 'feature' where the command line option -XX:PrefetchCopyIntervalInBytes=N is ignored and the value 256 always used instead. I have benchmarked it using the following test progam http://cr.openjdk.java.net/~enevill/8149365/ArrayCopyTest.java Which allows you to test memory copies of different sizes from a start size to an end size in step units. The test does both backwards and forwards copies. Usage: java ArrayCopyTest I have generated the results obtained before and after the above patch on 4 different partners HW (A,B,C,D) and a summary of the results is available at http://people.linaro.org/~edward.nevill/prefetch/prefetch.pdf For partner A I tested 3 ranges 0-64 bytes in units of 1 0-512 bytes in units of 8 0-4096 bytes in units of 64 The latter 2 clearly show the benefit of prefetching on backwards copies. For partners B, C & D, I only tested 0-4096 bytes in units of 64. I also tested B, C & D with -XX:PrefetchCopyIntervalInBytes=0. On these 3 partners disabling prefetch seemed to have no effect indicating that either prefetch is not implemented, or it implements automatic hardware prefetch. A summary of the results is that it improves performance significantly on partner A and has no effect on partners B,C & D. OK to push? Ed. From aph at redhat.com Mon Feb 8 14:57:23 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Feb 2016 14:57:23 +0000 Subject: [aarch64-port-dev ] RFR: 8149365: memory copy does not prefetch on backwards copy In-Reply-To: <1454942246.11423.18.camel@mint> References: <1454942246.11423.18.camel@mint> Message-ID: <56B8ACD3.3040602@redhat.com> On 08/02/16 14:37, Edward Nevill wrote: > OK to push? OK, thanks. Andrew. From roland.westrelin at oracle.com Mon Feb 8 17:30:20 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 8 Feb 2016 18:30:20 +0100 Subject: RFR(S): 6378256: Performance problem with System.identityHashCode in client compiler In-Reply-To: References: Message-ID: <7B6F2230-90B3-4BF2-8EBA-CF4B58FCE5BB@oracle.com> Hi Rahul, > Please review revised patch, notes for JDK-6378256. > https://bugs.openjdk.java.net/browse/JDK-6378256 > > > Latest webrev-03: http://cr.openjdk.java.net/~thartmann/6378256/webrev.03/ Thanks for making the change. I would say it?s better to add inline_check_hashcode_from_object_header() to sharedRuntime.hpp with #ifdef X86 rather than have the inline declaration. Not sure what others think. >>> Can you justify the comments again? I meant justify as text justification that is right align that comment: 36 // --------------------------------------------------------------------------- 37 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word 38 // instead of doing a full VM transition once it's been computed. 39 // Since hashCode is usually polymorphic at call sites we can't do 40 // this optimization at the call site without a lot of work. and that comment 2019 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word 2020 // instead of doing a full VM transition once it's been computed. 2021 // Since hashCode is usually polymorphic at call sites we can't do 2022 // this optimization at the call site without a lot of work. Sorry for the confusion. The code looks good to me/ Roland. From christian.thalinger at oracle.com Mon Feb 8 21:26:22 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 8 Feb 2016 11:26:22 -1000 Subject: RFR: 8149019: remove redundant modifiers In-Reply-To: References: <37F3BA0E-6B92-4E0A-A112-D3DA0E1D5149@oracle.com> Message-ID: Looks good. > On Feb 4, 2016, at 1:26 AM, Doug Simon wrote: > > I forgot to mention that the webrev for this bug is on top of the RFR for JDK-8148981[1]. > > -Doug > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021100.html > >> On 04 Feb 2016, at 11:08, Doug Simon wrote: >> >> JVMCI code is checked by Checkstyle and recent Checkstyle releases have introduced better detection of redundant modifiers. To ensure JVMCI continues to benefit from automated code style checking, it makes sense to keep up with Checkstyle and address style issues detected by newer versions. >> >> https://bugs.openjdk.java.net/browse/JDK-8149019 >> http://cr.openjdk.java.net/~dnsimon/8149019 >> >> -Doug > From dean.long at oracle.com Mon Feb 8 23:19:20 2016 From: dean.long at oracle.com (Dean Long) Date: Mon, 8 Feb 2016 15:19:20 -0800 Subject: RFR(XS): 8143897 :Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same In-Reply-To: <56B31435.7020607@oracle.com> References: <56AA3ED7.4030407@oracle.com> <844981E3-4C91-4D52-BBDB-450D055C2599@oracle.com> <56AA7A3F.6040800@oracle.com> <56AAB7CA.4000604@oracle.com> <56B1CEE2.40402@oracle.com> <56B24083.3060709@oracle.com> <56B31435.7020607@oracle.com> Message-ID: <56B92278.3000304@oracle.com> Jamsheed, it just occurred to me, why don't we need a LoadLoad barrier when we do the lock-free reads? dl On 2/4/2016 1:04 AM, Jamsheed C m wrote: > Thanks Vladimir. > > Best Regards, > Jamsheed > > On 2/3/2016 11:31 PM, Vladimir Kozlov wrote: >> Looks good. >> >> Thanks, >> Vladimir >> >> On 2/3/16 1:56 AM, Jamsheed C m wrote: >>> Hi Vladimir, Chris, >>> >>> On 1/29/2016 6:22 AM, Vladimir Kozlov wrote: >>>> On 1/28/16 12:29 PM, Jamsheed C m wrote: >>>>> >>>>> >>>>> On 1/29/2016 12:15 AM, Christian Thalinger wrote: >>>>>> if (count() < cache_size) { >>>>>> set_pc_at(count(),addr); >>>>>> set_handler_at(count(), handler); >>>>>> >>>>>> Shouldn?t we read count() only once into a local variable to rule >>>>>> any odd race bugs down the road? >>>> >>>> +1. As I understand, Chris is suggesting to do it in addition to >>>> storestore barrier. >>> I have made the suggested change. >>> http://cr.openjdk.java.net/~thartmann/8143897/webrev.01/ >>> >>> Best Regards, >>> Jamsheed >>> >>>> >>>> Do we have other similar code? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> write to cache is mutex lock protected. so this code is safe. >>>>> >>>>> Issue is seen in weak memory order machines. lockless read of >>>>> exception cache values fails as writes in cache get >>>>> reordered. >>>>> >>>>> Best Regards, >>>>> Jamsheed >>>>>> >>>>>>> On Jan 28, 2016, at 5:16 PM, Jamsheed C m >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Please review the fix made for issue >>>>>>> >>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8143897 >>>>>>> web rev: http://cr.openjdk.java.net/~thartmann/8143897/webrev.00/ >>>>>>> >>>>>>> Unit tests: As its hard, none >>>>>>> >>>>>>> Other tests: jprt. >>>>>>> >>>>>>> Description of the issue: >>>>>>> A valid pc match in exception cache returning an invalid handler >>>>>>> makes assert to fail. >>>>>>> This happens as ExceptionCache reads are lock free access. >>>>>>> >>>>>>> As a fix for this i have put a storestore mem barrier before the >>>>>>> count is updated. >>>>>>> >>>>>>> Best Regards, >>>>>>> Jamsheed >>>>> >>> > From aleksey.shipilev at oracle.com Tue Feb 9 10:51:14 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 9 Feb 2016 13:51:14 +0300 Subject: RFR (XS) 8149356: Leftover from JDK-8141044: UseNewCode usage Message-ID: <56B9C4A2.1020703@oracle.com> Hi, In JDK-8141044 ("C1 should fold (this == null) to false") change, I have accidentally pushed the implementation predicated under UseNewCode flag. Thanks to Vladimir Ivanov for finding this! We need to drop the UseNewCode check: https://bugs.openjdk.java.net/browse/JDK-8149356 Testing: JPRT -testset hotspot, eyeballing the C1 PrintAssembly for original test Cheers, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Tue Feb 9 12:01:21 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 9 Feb 2016 13:01:21 +0100 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException Message-ID: <56B9D511.7050609@oracle.com> Hi, please review the following patch. https://bugs.openjdk.java.net/browse/JDK-8148752 http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/ GraphBuilder::try_method_handle_inline() handles long and double arguments incorrectly when casting them to their actual type. Long/double arguments occupy two slots (see Parse::do_get_xxx() -> push_pair()). Currently, these two slots are treated as two individual arguments, causing incorrect casting of arguments. In this case, an Object argument is casted to String and therefore being used as a String (although it's actually of type 'ResolvedJavaMethod'). We later fail by throwing exceptions in compiled code. For a detailed evaluation see my comments in the bug [1]. We should handle this like C1 does in GraphBuilder::try_method_handle_inline(). Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8148752?focusedCommentId=13896557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896557 From roland.westrelin at oracle.com Tue Feb 9 12:06:05 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 9 Feb 2016 13:06:05 +0100 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56B9D511.7050609@oracle.com> References: <56B9D511.7050609@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/ That looks good to me. Roland. From aleksey.shipilev at oracle.com Tue Feb 9 12:09:22 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 9 Feb 2016 15:09:22 +0300 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56B9D511.7050609@oracle.com> References: <56B9D511.7050609@oracle.com> Message-ID: <56B9D6F2.7030805@oracle.com> On 09.02.2016 15:01, Tobias Hartmann wrote: > https://bugs.openjdk.java.net/browse/JDK-8148752 > http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/ Ugh, the failure makes sense now. The fix looks good. So, this seems to be a very generic issue with inlining any MH with long/double arguments? I think this deserves a regression test. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From jamsheed.c.m at oracle.com Tue Feb 9 12:29:49 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 9 Feb 2016 17:59:49 +0530 Subject: RFR(XS): 8143897 :Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same In-Reply-To: <56B92278.3000304@oracle.com> References: <56AA3ED7.4030407@oracle.com> <844981E3-4C91-4D52-BBDB-450D055C2599@oracle.com> <56AA7A3F.6040800@oracle.com> <56AAB7CA.4000604@oracle.com> <56B1CEE2.40402@oracle.com> <56B24083.3060709@oracle.com> <56B31435.7020607@oracle.com> <56B92278.3000304@oracle.com> Message-ID: <56B9DBBD.7050006@oracle.com> On 2/9/2016 4:49 AM, Dean Long wrote: > Jamsheed, it just occurred to me, why don't we need a LoadLoad barrier > when we do the lock-free reads? There is data dependence in ExceptionCache read code. Best Regards, Jamsheed > > dl > > On 2/4/2016 1:04 AM, Jamsheed C m wrote: >> Thanks Vladimir. >> >> Best Regards, >> Jamsheed >> >> On 2/3/2016 11:31 PM, Vladimir Kozlov wrote: >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 2/3/16 1:56 AM, Jamsheed C m wrote: >>>> Hi Vladimir, Chris, >>>> >>>> On 1/29/2016 6:22 AM, Vladimir Kozlov wrote: >>>>> On 1/28/16 12:29 PM, Jamsheed C m wrote: >>>>>> >>>>>> >>>>>> On 1/29/2016 12:15 AM, Christian Thalinger wrote: >>>>>>> if (count() < cache_size) { >>>>>>> set_pc_at(count(),addr); >>>>>>> set_handler_at(count(), handler); >>>>>>> >>>>>>> Shouldn?t we read count() only once into a local variable to >>>>>>> rule any odd race bugs down the road? >>>>> >>>>> +1. As I understand, Chris is suggesting to do it in addition to >>>>> storestore barrier. >>>> I have made the suggested change. >>>> http://cr.openjdk.java.net/~thartmann/8143897/webrev.01/ >>>> >>>> Best Regards, >>>> Jamsheed >>>> >>>>> >>>>> Do we have other similar code? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> write to cache is mutex lock protected. so this code is safe. >>>>>> >>>>>> Issue is seen in weak memory order machines. lockless read of >>>>>> exception cache values fails as writes in cache get >>>>>> reordered. >>>>>> >>>>>> Best Regards, >>>>>> Jamsheed >>>>>>> >>>>>>>> On Jan 28, 2016, at 5:16 PM, Jamsheed C m >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the fix made for issue >>>>>>>> >>>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8143897 >>>>>>>> web rev: http://cr.openjdk.java.net/~thartmann/8143897/webrev.00/ >>>>>>>> >>>>>>>> Unit tests: As its hard, none >>>>>>>> >>>>>>>> Other tests: jprt. >>>>>>>> >>>>>>>> Description of the issue: >>>>>>>> A valid pc match in exception cache returning an invalid >>>>>>>> handler makes assert to fail. >>>>>>>> This happens as ExceptionCache reads are lock free access. >>>>>>>> >>>>>>>> As a fix for this i have put a storestore mem barrier before >>>>>>>> the count is updated. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Jamsheed >>>>>> >>>> >> > From vladimir.x.ivanov at oracle.com Tue Feb 9 12:56:54 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 9 Feb 2016 15:56:54 +0300 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56B9D511.7050609@oracle.com> References: <56B9D511.7050609@oracle.com> Message-ID: <56B9E216.10702@oracle.com> Looks good. If possible, please, provide a test case. Best regards, Vladimir Ivanov PS: the bug is there from day #0. I am surprised it hasn't been discovered for so long... On 2/9/16 3:01 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > https://bugs.openjdk.java.net/browse/JDK-8148752 > http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/ > > GraphBuilder::try_method_handle_inline() handles long and double arguments incorrectly when casting them to their actual type. Long/double arguments occupy two slots (see Parse::do_get_xxx() -> push_pair()). Currently, these two slots are treated as two individual arguments, causing incorrect casting of arguments. > > In this case, an Object argument is casted to String and therefore being used as a String (although it's actually of type 'ResolvedJavaMethod'). We later fail by throwing exceptions in compiled code. For a detailed evaluation see my comments in the bug [1]. > > We should handle this like C1 does in GraphBuilder::try_method_handle_inline(). > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8148752?focusedCommentId=13896557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896557 > From jamsheed.c.m at oracle.com Tue Feb 9 13:15:14 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 9 Feb 2016 18:45:14 +0530 Subject: RFR(XS): 8149123: [TESTBUG] compiler/loopopts/superword/SumRed* tests running on non-x86 platforms Message-ID: <56B9E662.7070004@oracle.com> Hi, bug link :https://bugs.openjdk.java.net/browse/JDK-8149123 web rev :http://cr.openjdk.java.net/~thartmann/8149123/webrev.00/ Fix Summary: Restricted the execution to supported archs. Unit Tests: jprt verified. Best Regards, Jamsheed From aph at redhat.com Tue Feb 9 13:54:25 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 9 Feb 2016 13:54:25 +0000 Subject: RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: References: Message-ID: <56B9EF91.8000809@redhat.com> On 05/02/16 12:47, Hui Shi wrote: > Would some one help review this changeset? This improves performance for > codes like string builder and concat on aarch64. > Bug: https://bugs.openjdk.java.net/browse/JDK-8149080 > webrev: http://cr.openjdk.java.net/~hshi/8149080/webrev/ After some discussion with Edward Nevill, I am persuaded to accept this patch. While I'm not really happy that the backwards copy is so much slower than forwards, this patch is very low risk. I have checked the boundary conditions of (unsigned long)(d - s) >= (unsigned long)size and I'm convinced it's the correct test in this case. However, the comment // no overlap when (d-s) above_equal (count*size) is wrong. If d < s, unsigned(d-s) is >= (count*size) but the two strings may still overlap. This doesn't affect correctness in this case, because the forwards copy is the right one to use. Having said that, if someone changes nooverlap_target so that it is incorrect when copying overlapping arrays we'll have a problem. Thanks, Andrew, From daniel.daugherty at oracle.com Tue Feb 9 14:00:56 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 9 Feb 2016 07:00:56 -0700 Subject: RFR: JDK-8144957 - Remove PICL warning message In-Reply-To: <4ce66c15-a647-4185-8200-4f67eb97f88d@default> References: <4ce66c15-a647-4185-8200-4f67eb97f88d@default> Message-ID: <56B9F118.2090101@oracle.com> Adding the Compiler team since they added PICL support. Dan On 2/8/16 10:40 PM, Shafi Ahmad wrote: > Hi All, > > > > Please review the trivial change of removing misleading warning message. > > > > Summary: > > Warning message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. > > > > This message is very misleading and confusing to the users. So removing the related code. > > > > Open webrev: http://cr.openjdk.java.net/~aeriksso/8144957/webrev.00/ > > Bug link: https://bugs.openjdk.java.net/browse/JDK-8144957 > > > > Testing: JPRT > > > > Regards, > > Shafi From edward.nevill at gmail.com Tue Feb 9 14:03:02 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 09 Feb 2016 14:03:02 +0000 Subject: [aarch64-port-dev ] RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: <56B9EF91.8000809@redhat.com> References: <56B9EF91.8000809@redhat.com> Message-ID: <1455026582.32182.1.camel@mylittlepony.linaroharston> On Tue, 2016-02-09 at 13:54 +0000, Andrew Haley wrote: > On 05/02/16 12:47, Hui Shi wrote: > > > Would some one help review this changeset? This improves performance for > > codes like string builder and concat on aarch64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149080 > > webrev: http://cr.openjdk.java.net/~hshi/8149080/webrev/ > > However, the comment > > // no overlap when (d-s) above_equal (count*size) Shall I just change the comment to // use fwd copy when (d-s) above_equal (count*size) when I do the push? Regards, Ed. From aph at redhat.com Tue Feb 9 14:03:45 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 9 Feb 2016 14:03:45 +0000 Subject: [aarch64-port-dev ] RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: <1455026582.32182.1.camel@mylittlepony.linaroharston> References: <56B9EF91.8000809@redhat.com> <1455026582.32182.1.camel@mylittlepony.linaroharston> Message-ID: <56B9F1C1.6010605@redhat.com> On 09/02/16 14:03, Edward Nevill wrote: >> However, the comment >> > >> > // no overlap when (d-s) above_equal (count*size) > Shall I just change the comment to > > // use fwd copy when (d-s) above_equal (count*size) > > when I do the push? OK, thanks. Andrew. From tobias.hartmann at oracle.com Tue Feb 9 14:18:48 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 9 Feb 2016 15:18:48 +0100 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56B9E216.10702@oracle.com> References: <56B9D511.7050609@oracle.com> <56B9E216.10702@oracle.com> Message-ID: <56B9F548.6090607@oracle.com> Roland, Aleksey, Vladimir, thanks for the reviews! Here is the regression test: http://cr.openjdk.java.net/~thartmann/8148752/webrev.01/ It fails because Object o is casted to String: Exception in thread "main" java.lang.RuntimeException: Test failed at LongReferenceCastingTest.main(LongReferenceCastingTest.java:68) Caused by: java.lang.NullPointerException at java.lang.StringLatin1.equals(StringLatin1.java:92) at java.lang.String.equals(String.java:1002) at LongReferenceCastingTest.main(LongReferenceCastingTest.java:63) Thanks, Tobias On 09.02.2016 13:56, Vladimir Ivanov wrote: > Looks good. > > If possible, please, provide a test case. > > Best regards, > Vladimir Ivanov > > PS: the bug is there from day #0. I am surprised it hasn't been discovered for so long... > > On 2/9/16 3:01 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> https://bugs.openjdk.java.net/browse/JDK-8148752 >> http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/ >> >> GraphBuilder::try_method_handle_inline() handles long and double arguments incorrectly when casting them to their actual type. Long/double arguments occupy two slots (see Parse::do_get_xxx() -> push_pair()). Currently, these two slots are treated as two individual arguments, causing incorrect casting of arguments. >> >> In this case, an Object argument is casted to String and therefore being used as a String (although it's actually of type 'ResolvedJavaMethod'). We later fail by throwing exceptions in compiled code. For a detailed evaluation see my comments in the bug [1]. >> >> We should handle this like C1 does in GraphBuilder::try_method_handle_inline(). >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8148752?focusedCommentId=13896557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896557 >> From aleksey.shipilev at oracle.com Tue Feb 9 14:40:21 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 9 Feb 2016 17:40:21 +0300 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56B9F548.6090607@oracle.com> References: <56B9D511.7050609@oracle.com> <56B9E216.10702@oracle.com> <56B9F548.6090607@oracle.com> Message-ID: <56B9FA55.3030501@oracle.com> On 09.02.2016 17:18, Tobias Hartmann wrote: > Roland, Aleksey, Vladimir, thanks for the reviews! > > Here is the regression test: > http://cr.openjdk.java.net/~thartmann/8148752/webrev.01/ +1 -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vladimir.x.ivanov at oracle.com Tue Feb 9 14:43:53 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 9 Feb 2016 17:43:53 +0300 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56B9F548.6090607@oracle.com> References: <56B9D511.7050609@oracle.com> <56B9E216.10702@oracle.com> <56B9F548.6090607@oracle.com> Message-ID: <56B9FB29.6030900@oracle.com> Still looks good. Best regards, Vladimir Ivanov On 2/9/16 5:18 PM, Tobias Hartmann wrote: > Roland, Aleksey, Vladimir, thanks for the reviews! > > Here is the regression test: > http://cr.openjdk.java.net/~thartmann/8148752/webrev.01/ > > It fails because Object o is casted to String: > > Exception in thread "main" java.lang.RuntimeException: Test failed > at LongReferenceCastingTest.main(LongReferenceCastingTest.java:68) > Caused by: java.lang.NullPointerException > at java.lang.StringLatin1.equals(StringLatin1.java:92) > at java.lang.String.equals(String.java:1002) > at LongReferenceCastingTest.main(LongReferenceCastingTest.java:63) > > Thanks, > Tobias > > > On 09.02.2016 13:56, Vladimir Ivanov wrote: >> Looks good. >> >> If possible, please, provide a test case. >> >> Best regards, >> Vladimir Ivanov >> >> PS: the bug is there from day #0. I am surprised it hasn't been discovered for so long... >> >> On 2/9/16 3:01 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8148752 >>> http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/ >>> >>> GraphBuilder::try_method_handle_inline() handles long and double arguments incorrectly when casting them to their actual type. Long/double arguments occupy two slots (see Parse::do_get_xxx() -> push_pair()). Currently, these two slots are treated as two individual arguments, causing incorrect casting of arguments. >>> >>> In this case, an Object argument is casted to String and therefore being used as a String (although it's actually of type 'ResolvedJavaMethod'). We later fail by throwing exceptions in compiled code. For a detailed evaluation see my comments in the bug [1]. >>> >>> We should handle this like C1 does in GraphBuilder::try_method_handle_inline(). >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8148752?focusedCommentId=13896557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896557 >>> From tobias.hartmann at oracle.com Tue Feb 9 14:50:46 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 9 Feb 2016 15:50:46 +0100 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56B9FA55.3030501@oracle.com> References: <56B9D511.7050609@oracle.com> <56B9E216.10702@oracle.com> <56B9F548.6090607@oracle.com> <56B9FA55.3030501@oracle.com> Message-ID: <56B9FCC6.9040205@oracle.com> Thanks, Aleksey. Best, Tobias On 09.02.2016 15:40, Aleksey Shipilev wrote: > On 09.02.2016 17:18, Tobias Hartmann wrote: >> Roland, Aleksey, Vladimir, thanks for the reviews! >> >> Here is the regression test: >> http://cr.openjdk.java.net/~thartmann/8148752/webrev.01/ > > +1 > > -Aleksey > > From tobias.hartmann at oracle.com Tue Feb 9 14:50:56 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 9 Feb 2016 15:50:56 +0100 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56B9FB29.6030900@oracle.com> References: <56B9D511.7050609@oracle.com> <56B9E216.10702@oracle.com> <56B9F548.6090607@oracle.com> <56B9FB29.6030900@oracle.com> Message-ID: <56B9FCD0.70001@oracle.com> Thanks, Vladimir. Best, Tobias On 09.02.2016 15:43, Vladimir Ivanov wrote: > Still looks good. > > Best regards, > Vladimir Ivanov > > On 2/9/16 5:18 PM, Tobias Hartmann wrote: >> Roland, Aleksey, Vladimir, thanks for the reviews! >> >> Here is the regression test: >> http://cr.openjdk.java.net/~thartmann/8148752/webrev.01/ >> >> It fails because Object o is casted to String: >> >> Exception in thread "main" java.lang.RuntimeException: Test failed >> at LongReferenceCastingTest.main(LongReferenceCastingTest.java:68) >> Caused by: java.lang.NullPointerException >> at java.lang.StringLatin1.equals(StringLatin1.java:92) >> at java.lang.String.equals(String.java:1002) >> at LongReferenceCastingTest.main(LongReferenceCastingTest.java:63) >> >> Thanks, >> Tobias >> >> >> On 09.02.2016 13:56, Vladimir Ivanov wrote: >>> Looks good. >>> >>> If possible, please, provide a test case. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> PS: the bug is there from day #0. I am surprised it hasn't been discovered for so long... >>> >>> On 2/9/16 3:01 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8148752 >>>> http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/ >>>> >>>> GraphBuilder::try_method_handle_inline() handles long and double arguments incorrectly when casting them to their actual type. Long/double arguments occupy two slots (see Parse::do_get_xxx() -> push_pair()). Currently, these two slots are treated as two individual arguments, causing incorrect casting of arguments. >>>> >>>> In this case, an Object argument is casted to String and therefore being used as a String (although it's actually of type 'ResolvedJavaMethod'). We later fail by throwing exceptions in compiled code. For a detailed evaluation see my comments in the bug [1]. >>>> >>>> We should handle this like C1 does in GraphBuilder::try_method_handle_inline(). >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8148752?focusedCommentId=13896557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896557 >>>> From roland.westrelin at oracle.com Tue Feb 9 15:00:54 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 9 Feb 2016 16:00:54 +0100 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56B9F548.6090607@oracle.com> References: <56B9D511.7050609@oracle.com> <56B9E216.10702@oracle.com> <56B9F548.6090607@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/8148752/webrev.01/ Looks good. Roland. From tobias.hartmann at oracle.com Tue Feb 9 15:02:23 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 9 Feb 2016 16:02:23 +0100 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: References: <56B9D511.7050609@oracle.com> <56B9E216.10702@oracle.com> <56B9F548.6090607@oracle.com> Message-ID: <56B9FF7F.8040401@oracle.com> Thanks, Roland. Best, Tobias On 09.02.2016 16:00, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~thartmann/8148752/webrev.01/ > > Looks good. > > Roland. > From paul.sandoz at oracle.com Tue Feb 9 15:05:28 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 9 Feb 2016 16:05:28 +0100 Subject: RFR 8149469: ByteBuffer API and implementation enhancements for VarHandles Message-ID: <6F457380-0E56-4909-BFBF-B3D6FE45B326@oracle.com> Hi, This patch contains API and internal enhancements to ByteBuffer: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149469-byte-buffer-align-and-unifying-enhancements/webrev/index.html I am CC?ing hotspot-compiler because i want to push to hs-comp to reduce time delays for reviewing/pushing dependent VarHandle patches (which also depends on the Unsafe enhancements currently under review that are also to be pushed to hs-comp). The API enhancements provide support for querying misalignment of an index and unit size, and also slicing a buffer to align for a unit size. Such functionality enables one to set up for aligned access for unit sizes bytes, if supported by the platform. The internal enhancements enable consistent use of fields readOnly and address. For the moment i have only enabled consistent use of address for ByteBuffers. A primary motivation for these enhancements is too support VarHandles access to ByteBuffer contents. The API enhancement enables access to values at known aligned indexes and therefore provides stronger atomicity guarantees and enhanced atomic accesses that follow from that. The internal enhancement allows VarHandle implementations to uniformly access buffers using the Unsafe double addressing mode [*]. I believe these enhancements are also valuable independently of the VarHandles work. Furthermore, the internal enhancements are a stepping stone to potentially consolidating many aspects of heap and direct buffers. Thanks, Paul. [*] For heap buffers Buffer.address == Unsafe.ARRAY_BYTE_BASE_OFFSET + offset; ByteBuffer.hb != null, For direct buffers Buffer.address == ; ByteBuffer.hb == null, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Tue Feb 9 17:09:29 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 9 Feb 2016 09:09:29 -0800 Subject: RFR: JDK-8144957 - Remove PICL warning message In-Reply-To: <56B9F118.2090101@oracle.com> References: <4ce66c15-a647-4185-8200-4f67eb97f88d@default> <56B9F118.2090101@oracle.com> Message-ID: <56BA1D49.2070304@oracle.com> Looks good. I thought it was fixed already. Thanks, Vladimir On 2/9/16 6:00 AM, Daniel D. Daugherty wrote: > Adding the Compiler team since they added PICL support. > > Dan > > > On 2/8/16 10:40 PM, Shafi Ahmad wrote: >> Hi All, >> >> >> Please review the trivial change of removing misleading warning message. >> >> >> Summary: >> >> Warning message: Java HotSpot(TM) Server VM warning: PICL (libpicl.so.1) is missing. Performance will not be optimal. >> >> >> >> This message is very misleading and confusing to the users. So removing the related code. >> >> >> Open webrev: http://cr.openjdk.java.net/~aeriksso/8144957/webrev.00/ >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8144957 >> >> >> Testing: JPRT >> >> >> Regards, >> >> Shafi > From vladimir.kozlov at oracle.com Tue Feb 9 17:18:50 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 9 Feb 2016 09:18:50 -0800 Subject: RFR(XS): 8149123: [TESTBUG] compiler/loopopts/superword/SumRed* tests running on non-x86 platforms In-Reply-To: <56B9E662.7070004@oracle.com> References: <56B9E662.7070004@oracle.com> Message-ID: <56BA1F7A.3080907@oracle.com> Yes, this looks good. Thanks, Vladimir On 2/9/16 5:15 AM, Jamsheed C m wrote: > Hi, > > bug link :https://bugs.openjdk.java.net/browse/JDK-8149123 > web rev :http://cr.openjdk.java.net/~thartmann/8149123/webrev.00/ > Fix Summary: Restricted the execution to supported archs. > Unit Tests: jprt verified. > > Best Regards, > Jamsheed > > > > From christian.thalinger at oracle.com Tue Feb 9 17:23:19 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 9 Feb 2016 07:23:19 -1000 Subject: RFR: 8148741: compiler/jvmci/code/SimpleDebugInfoTest.java fails in 'frame::sender_for_compiled_frame' In-Reply-To: <56B3323D.7090301@oracle.com> References: <56B3323D.7090301@oracle.com> Message-ID: <8FF42105-41C9-47FD-8962-6345561000F3@oracle.com> Looks good. > On Feb 4, 2016, at 1:13 AM, Roland Schatz wrote: > > Hi, > > Please review this bugfix: > > webrev: > http://cr.openjdk.java.net/~rschatz/JDK-8148741/webrev.00/ > issue: > https://bugs.openjdk.java.net/browse/JDK-8148741 > > This is on top of another open RFR [1]. These are two separate but related bugs. Both fixes are needed for the test to pass. > > Thanks, > Roland > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021103.html From vladimir.kozlov at oracle.com Tue Feb 9 18:38:04 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 9 Feb 2016 10:38:04 -0800 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56B9F548.6090607@oracle.com> References: <56B9D511.7050609@oracle.com> <56B9E216.10702@oracle.com> <56B9F548.6090607@oracle.com> Message-ID: <56BA320C.5070608@oracle.com> Looks good. Thanks, Vladimir On 2/9/16 6:18 AM, Tobias Hartmann wrote: > Roland, Aleksey, Vladimir, thanks for the reviews! > > Here is the regression test: > http://cr.openjdk.java.net/~thartmann/8148752/webrev.01/ > > It fails because Object o is casted to String: > > Exception in thread "main" java.lang.RuntimeException: Test failed > at LongReferenceCastingTest.main(LongReferenceCastingTest.java:68) > Caused by: java.lang.NullPointerException > at java.lang.StringLatin1.equals(StringLatin1.java:92) > at java.lang.String.equals(String.java:1002) > at LongReferenceCastingTest.main(LongReferenceCastingTest.java:63) > > Thanks, > Tobias > > > On 09.02.2016 13:56, Vladimir Ivanov wrote: >> Looks good. >> >> If possible, please, provide a test case. >> >> Best regards, >> Vladimir Ivanov >> >> PS: the bug is there from day #0. I am surprised it hasn't been discovered for so long... >> >> On 2/9/16 3:01 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8148752 >>> http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/ >>> >>> GraphBuilder::try_method_handle_inline() handles long and double arguments incorrectly when casting them to their actual type. Long/double arguments occupy two slots (see Parse::do_get_xxx() -> push_pair()). Currently, these two slots are treated as two individual arguments, causing incorrect casting of arguments. >>> >>> In this case, an Object argument is casted to String and therefore being used as a String (although it's actually of type 'ResolvedJavaMethod'). We later fail by throwing exceptions in compiled code. For a detailed evaluation see my comments in the bug [1]. >>> >>> We should handle this like C1 does in GraphBuilder::try_method_handle_inline(). >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8148752?focusedCommentId=13896557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896557 >>> From vladimir.kozlov at oracle.com Tue Feb 9 19:06:50 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 9 Feb 2016 11:06:50 -0800 Subject: RFR (XS) 8149356: Leftover from JDK-8141044: UseNewCode usage In-Reply-To: <56B9C4A2.1020703@oracle.com> References: <56B9C4A2.1020703@oracle.com> Message-ID: <56BA38CA.4010208@oracle.com> Where is webrev? thanks, Vladimir K On 2/9/16 2:51 AM, Aleksey Shipilev wrote: > Hi, > > In JDK-8141044 ("C1 should fold (this == null) to false") change, I have > accidentally pushed the implementation predicated under UseNewCode flag. > Thanks to Vladimir Ivanov for finding this! We need to drop the > UseNewCode check: > https://bugs.openjdk.java.net/browse/JDK-8149356 > > Testing: JPRT -testset hotspot, eyeballing the C1 PrintAssembly for > original test > > Cheers, > -Aleksey > From aleksey.shipilev at oracle.com Tue Feb 9 19:58:59 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 9 Feb 2016 22:58:59 +0300 Subject: RFR (XS) 8149356: Leftover from JDK-8141044: UseNewCode usage In-Reply-To: <56BA38CA.4010208@oracle.com> References: <56B9C4A2.1020703@oracle.com> <56BA38CA.4010208@oracle.com> Message-ID: <56BA4503.8090506@oracle.com> Jeez, that's double embarrassing, here is it: http://cr.openjdk.java.net/~shade/8149356/webrev.01/ -Aleksey On 09.02.2016 22:06, Vladimir Kozlov wrote: > Where is webrev? > > thanks, > Vladimir K > > On 2/9/16 2:51 AM, Aleksey Shipilev wrote: >> Hi, >> >> In JDK-8141044 ("C1 should fold (this == null) to false") change, I have >> accidentally pushed the implementation predicated under UseNewCode flag. >> Thanks to Vladimir Ivanov for finding this! We need to drop the >> UseNewCode check: >> https://bugs.openjdk.java.net/browse/JDK-8149356 >> >> Testing: JPRT -testset hotspot, eyeballing the C1 PrintAssembly for >> original test >> >> Cheers, >> -Aleksey >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From doug.simon at oracle.com Tue Feb 9 20:00:14 2016 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 9 Feb 2016 21:00:14 +0100 Subject: RFR: 8148507: [JVMCI] mitigate deadlocks related to JVMCI compiler under -Xbatch In-Reply-To: <56B7E033.9080708@oracle.com> References: <845F1D56-3194-49AE-95C1-79545F8C50AC@oracle.com> <3F2DB53D-5308-4745-97F6-7EF35DF99A52@oracle.com> <00D38633-F4E3-47D0-800C-9A45893354E2@oracle.com> <56B7E033.9080708@oracle.com> Message-ID: > On 08 Feb 2016, at 01:24, David Holmes wrote: > > On 6/02/2016 2:34 AM, Christian Thalinger wrote: >> Looks good to me. David, any comments? > > Just two observations: > > 1. The methods_compiler counter could overflow. That won't affect the progress check but I don't know if it impacts any other code that uses it. The only other code using this counter is the progress meter that is part of -XX:+BootstrapJVMCI. Overflow will never happen here (and wouldn?t matter if it did). > > 2. wait_for_jvmci_completion can still fail to return for arbitrarily long periods of time if compilation progresses but at a very slow rate. Yes, that?s unfortunately unavoidable. But as mentioned elsewhere, -Xbatch is a "best effort? VM option. Thanks for the review. -Doug >>> On Feb 4, 2016, at 12:36 PM, Doug Simon wrote: >>> >>> I?ve updated the webrev in situ for reasons discussed here: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8148507?focusedCommentId=13896252&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896252 >>> >>> >>>> On 03 Feb 2016, at 20:42, Christian Thalinger wrote: >>>> >>>> There was some discussion in the bug report but I seems like we are going to integrate this change. >>>> >>>>> On Jan 31, 2016, at 5:48 AM, Christian Thalinger wrote: >>>>> >>>>> Looks good. >>>>> >>>>>> On Jan 29, 2016, at 4:34 PM, Doug Simon wrote: >>>>>> >>>>>> Please review this small change to further mitigate deadlocks that can be caused by JVMCI when BackgroundCompilation is disabled. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8148507 >>>>>> http://cr.openjdk.java.net/~dnsimon/8148507 >>>>>> >>>>>> -Doug >>>>> >>>> >>> >> From tom.rodriguez at oracle.com Tue Feb 9 21:30:45 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 9 Feb 2016 13:30:45 -0800 Subject: RFR: 8148507: [JVMCI] mitigate deadlocks related to JVMCI compiler under -Xbatch In-Reply-To: References: <845F1D56-3194-49AE-95C1-79545F8C50AC@oracle.com> <3F2DB53D-5308-4745-97F6-7EF35DF99A52@oracle.com> <00D38633-F4E3-47D0-800C-9A45893354E2@oracle.com> <56B7E033.9080708@oracle.com> Message-ID: <36BB2B9B-3F2C-4E75-A1B5-01C35E3F7958@oracle.com> >> 2. wait_for_jvmci_completion can still fail to return for arbitrarily long periods of time if compilation progresses but at a very slow rate. > > Yes, that?s unfortunately unavoidable. But as mentioned elsewhere, -Xbatch is a "best effort? VM option. I don?t think it can be arbitrarily long. There can only be as many blocking compiles pending as there are running Java threads and the JVMCI compilation policy prioritizes blocking compiles over non-blocking ones so you shouldn?t end up waiting arbitrarily long. Compiles triggered by the JVMCI compiler itself are never blocking so those will always be serviced last in this mode. tom > > Thanks for the review. > > -Doug > >>>> On Feb 4, 2016, at 12:36 PM, Doug Simon wrote: >>>> >>>> I?ve updated the webrev in situ for reasons discussed here: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8148507?focusedCommentId=13896252&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896252 >>>> >>>> >>>>> On 03 Feb 2016, at 20:42, Christian Thalinger wrote: >>>>> >>>>> There was some discussion in the bug report but I seems like we are going to integrate this change. >>>>> >>>>>> On Jan 31, 2016, at 5:48 AM, Christian Thalinger wrote: >>>>>> >>>>>> Looks good. >>>>>> >>>>>>> On Jan 29, 2016, at 4:34 PM, Doug Simon wrote: >>>>>>> >>>>>>> Please review this small change to further mitigate deadlocks that can be caused by JVMCI when BackgroundCompilation is disabled. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8148507 >>>>>>> http://cr.openjdk.java.net/~dnsimon/8148507 >>>>>>> >>>>>>> -Doug >>>>>> >>>>> >>>> >>> > From christian.thalinger at oracle.com Tue Feb 9 21:57:41 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 9 Feb 2016 11:57:41 -1000 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56B9D511.7050609@oracle.com> References: <56B9D511.7050609@oracle.com> Message-ID: <6BE1AA69-C7A5-4CD4-A21D-289DC73D6FE7@oracle.com> Ouch. Gotta hate long/double-slots. Thanks for fixing my bug. > On Feb 9, 2016, at 2:01 AM, Tobias Hartmann wrote: > > Hi, > > please review the following patch. > > https://bugs.openjdk.java.net/browse/JDK-8148752 > http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/ > > GraphBuilder::try_method_handle_inline() handles long and double arguments incorrectly when casting them to their actual type. Long/double arguments occupy two slots (see Parse::do_get_xxx() -> push_pair()). Currently, these two slots are treated as two individual arguments, causing incorrect casting of arguments. > > In this case, an Object argument is casted to String and therefore being used as a String (although it's actually of type 'ResolvedJavaMethod'). We later fail by throwing exceptions in compiled code. For a detailed evaluation see my comments in the bug [1]. > > We should handle this like C1 does in GraphBuilder::try_method_handle_inline(). > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8148752?focusedCommentId=13896557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896557 From christian.thalinger at oracle.com Tue Feb 9 22:00:48 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 9 Feb 2016 12:00:48 -1000 Subject: RFR(XS): 8149123: [TESTBUG] compiler/loopopts/superword/SumRed* tests running on non-x86 platforms In-Reply-To: <56B9E662.7070004@oracle.com> References: <56B9E662.7070004@oracle.com> Message-ID: <9C8E72B2-211D-4830-BE2A-A58A857E7F64@oracle.com> All of these are supported on aarch64 except the last one? test/compiler/loopopts/superword/SumRed_Long.java > On Feb 9, 2016, at 3:15 AM, Jamsheed C m wrote: > > Hi, > > bug link :https://bugs.openjdk.java.net/browse/JDK-8149123 > web rev :http://cr.openjdk.java.net/~thartmann/8149123/webrev.00/ > Fix Summary: Restricted the execution to supported archs. > Unit Tests: jprt verified. > > Best Regards, > Jamsheed > > > > From christian.thalinger at oracle.com Tue Feb 9 22:39:36 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 9 Feb 2016 12:39:36 -1000 Subject: RFR (M): 8149415: [AArch64] implement JVMCI CodeInstaller Message-ID: <24D1E72C-5F70-4073-8EC2-9E291093DC29@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8149415 http://cr.openjdk.java.net/~twisti/8149415/webrev.01/ This is a first cut of the CodeInstaller implementation for AArch64. One missing part is compressed oops support but it?s not a big issue because Graal doesn?t support it yet either. The patch also includes changes to AMD64 and SPARC?s RegisterConfig to use an array for the reserved registers. The code before was too hard to understand. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.c.berg at intel.com Tue Feb 9 23:16:47 2016 From: michael.c.berg at intel.com (Berg, Michael C) Date: Tue, 9 Feb 2016 23:16:47 +0000 Subject: CR for RFR 8149421 Message-ID: Hi Folks, I would like to contribute vectorized post loops. This patch is initially targeted for x86. The design is versatile so as to be portable to other targets as well. This code poses the addition of atomic unrolled drain loops which precede fix-up segments and which are significantly faster than scalar code. The requirement is that the main loop is super unrolled after vectorization. I see up to 54% uplift on micro benchmarks on x86 targets for loops which pass superword vectorization and which meet the above criteria. Also scimark metrics in SpecJvm2008 like lu.small and fft.small show the usage of this design for benefit on x86. Bug-id: https://bugs.openjdk.java.net/browse/JDK-8149421 webrev: http://cr.openjdk.java.net/~mcberg/8149421/webrev.01/ Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From hui.shi at linaro.org Wed Feb 10 00:37:44 2016 From: hui.shi at linaro.org (Hui Shi) Date: Wed, 10 Feb 2016 08:37:44 +0800 Subject: [aarch64-port-dev ] RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code In-Reply-To: <56B9F1C1.6010605@redhat.com> References: <56B9EF91.8000809@redhat.com> <1455026582.32182.1.camel@mylittlepony.linaroharston> <56B9F1C1.6010605@redhat.com> Message-ID: Thanks Andrew and Edward! I will follow up with misaligned issue for 16 byte alignment peeling before copy longs. Regards Hui On 9 February 2016 at 22:03, Andrew Haley wrote: > On 09/02/16 14:03, Edward Nevill wrote: > >> However, the comment > >> > > >> > // no overlap when (d-s) above_equal (count*size) > > Shall I just change the comment to > > > > // use fwd copy when (d-s) above_equal (count*size) > > > > when I do the push? > > OK, thanks. > > Andrew. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Wed Feb 10 06:21:01 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 10 Feb 2016 11:51:01 +0530 Subject: RFR(XS): 8149123: [TESTBUG] compiler/loopopts/superword/SumRed* tests running on non-x86 platforms In-Reply-To: <9C8E72B2-211D-4830-BE2A-A58A857E7F64@oracle.com> References: <56B9E662.7070004@oracle.com> <9C8E72B2-211D-4830-BE2A-A58A857E7F64@oracle.com> Message-ID: <56BAD6CD.3030104@oracle.com> On 2/10/2016 3:30 AM, Christian Thalinger wrote: > All of these are supported on aarch64 except the last one? > > test/compiler/loopopts/superword/SumRed_Long.java Yes Chris, ref: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018638.html Best Regards, Jamsheed > >> On Feb 9, 2016, at 3:15 AM, Jamsheed C m wrote: >> >> Hi, >> >> bug link :https://bugs.openjdk.java.net/browse/JDK-8149123 >> web rev :http://cr.openjdk.java.net/~thartmann/8149123/webrev.00/ >> Fix Summary: Restricted the execution to supported archs. >> Unit Tests: jprt verified. >> >> Best Regards, >> Jamsheed >> >> >> >> From jamsheed.c.m at oracle.com Wed Feb 10 06:23:02 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 10 Feb 2016 11:53:02 +0530 Subject: RFR(XS): 8149123: [TESTBUG] compiler/loopopts/superword/SumRed* tests running on non-x86 platforms In-Reply-To: <56BA1F7A.3080907@oracle.com> References: <56B9E662.7070004@oracle.com> <56BA1F7A.3080907@oracle.com> Message-ID: <56BAD746.7040407@oracle.com> Thanks, Vladimir! Best Regards, Jamsheed On 2/9/2016 10:48 PM, Vladimir Kozlov wrote: > Yes, this looks good. > > Thanks, > Vladimir > > On 2/9/16 5:15 AM, Jamsheed C m wrote: >> Hi, >> >> bug link :https://bugs.openjdk.java.net/browse/JDK-8149123 >> web rev :http://cr.openjdk.java.net/~thartmann/8149123/webrev.00/ >> Fix Summary: Restricted the execution to supported archs. >> Unit Tests: jprt verified. >> >> Best Regards, >> Jamsheed >> >> >> >> From tobias.hartmann at oracle.com Wed Feb 10 06:51:18 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 10 Feb 2016 07:51:18 +0100 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56BA320C.5070608@oracle.com> References: <56B9D511.7050609@oracle.com> <56B9E216.10702@oracle.com> <56B9F548.6090607@oracle.com> <56BA320C.5070608@oracle.com> Message-ID: <56BADDE6.9020303@oracle.com> Thanks, Vladimir. Best, Tobias On 09.02.2016 19:38, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 2/9/16 6:18 AM, Tobias Hartmann wrote: >> Roland, Aleksey, Vladimir, thanks for the reviews! >> >> Here is the regression test: >> http://cr.openjdk.java.net/~thartmann/8148752/webrev.01/ >> >> It fails because Object o is casted to String: >> >> Exception in thread "main" java.lang.RuntimeException: Test failed >> at LongReferenceCastingTest.main(LongReferenceCastingTest.java:68) >> Caused by: java.lang.NullPointerException >> at java.lang.StringLatin1.equals(StringLatin1.java:92) >> at java.lang.String.equals(String.java:1002) >> at LongReferenceCastingTest.main(LongReferenceCastingTest.java:63) >> >> Thanks, >> Tobias >> >> >> On 09.02.2016 13:56, Vladimir Ivanov wrote: >>> Looks good. >>> >>> If possible, please, provide a test case. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> PS: the bug is there from day #0. I am surprised it hasn't been discovered for so long... >>> >>> On 2/9/16 3:01 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8148752 >>>> http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/ >>>> >>>> GraphBuilder::try_method_handle_inline() handles long and double arguments incorrectly when casting them to their actual type. Long/double arguments occupy two slots (see Parse::do_get_xxx() -> push_pair()). Currently, these two slots are treated as two individual arguments, causing incorrect casting of arguments. >>>> >>>> In this case, an Object argument is casted to String and therefore being used as a String (although it's actually of type 'ResolvedJavaMethod'). We later fail by throwing exceptions in compiled code. For a detailed evaluation see my comments in the bug [1]. >>>> >>>> We should handle this like C1 does in GraphBuilder::try_method_handle_inline(). >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8148752?focusedCommentId=13896557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896557 >>>> From tobias.hartmann at oracle.com Wed Feb 10 06:51:58 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 10 Feb 2016 07:51:58 +0100 Subject: [9] RFR(S): 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <6BE1AA69-C7A5-4CD4-A21D-289DC73D6FE7@oracle.com> References: <56B9D511.7050609@oracle.com> <6BE1AA69-C7A5-4CD4-A21D-289DC73D6FE7@oracle.com> Message-ID: <56BADE0E.7040401@oracle.com> Thanks, Chris. Best, Tobias On 09.02.2016 22:57, Christian Thalinger wrote: > Ouch. Gotta hate long/double-slots. Thanks for fixing my bug. > >> On Feb 9, 2016, at 2:01 AM, Tobias Hartmann wrote: >> >> Hi, >> >> please review the following patch. >> >> https://bugs.openjdk.java.net/browse/JDK-8148752 >> http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/ >> >> GraphBuilder::try_method_handle_inline() handles long and double arguments incorrectly when casting them to their actual type. Long/double arguments occupy two slots (see Parse::do_get_xxx() -> push_pair()). Currently, these two slots are treated as two individual arguments, causing incorrect casting of arguments. >> >> In this case, an Object argument is casted to String and therefore being used as a String (although it's actually of type 'ResolvedJavaMethod'). We later fail by throwing exceptions in compiled code. For a detailed evaluation see my comments in the bug [1]. >> >> We should handle this like C1 does in GraphBuilder::try_method_handle_inline(). >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8148752?focusedCommentId=13896557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13896557 > From dean.long at oracle.com Wed Feb 10 07:25:29 2016 From: dean.long at oracle.com (Dean Long) Date: Tue, 9 Feb 2016 23:25:29 -0800 Subject: RFR(XS): 8143897 :Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same In-Reply-To: <56B9DBBD.7050006@oracle.com> References: <56AA3ED7.4030407@oracle.com> <844981E3-4C91-4D52-BBDB-450D055C2599@oracle.com> <56AA7A3F.6040800@oracle.com> <56AAB7CA.4000604@oracle.com> <56B1CEE2.40402@oracle.com> <56B24083.3060709@oracle.com> <56B31435.7020607@oracle.com> <56B92278.3000304@oracle.com> <56B9DBBD.7050006@oracle.com> Message-ID: <56BAE5E9.5090102@oracle.com> OK thanks. dl On 2/9/2016 4:29 AM, Jamsheed C m wrote: > > On 2/9/2016 4:49 AM, Dean Long wrote: >> Jamsheed, it just occurred to me, why don't we need a LoadLoad >> barrier when we do the lock-free reads? > There is data dependence in ExceptionCache read code. > > Best Regards, > Jamsheed >> >> dl >> >> On 2/4/2016 1:04 AM, Jamsheed C m wrote: >>> Thanks Vladimir. >>> >>> Best Regards, >>> Jamsheed >>> >>> On 2/3/2016 11:31 PM, Vladimir Kozlov wrote: >>>> Looks good. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 2/3/16 1:56 AM, Jamsheed C m wrote: >>>>> Hi Vladimir, Chris, >>>>> >>>>> On 1/29/2016 6:22 AM, Vladimir Kozlov wrote: >>>>>> On 1/28/16 12:29 PM, Jamsheed C m wrote: >>>>>>> >>>>>>> >>>>>>> On 1/29/2016 12:15 AM, Christian Thalinger wrote: >>>>>>>> if (count() < cache_size) { >>>>>>>> set_pc_at(count(),addr); >>>>>>>> set_handler_at(count(), handler); >>>>>>>> >>>>>>>> Shouldn?t we read count() only once into a local variable to >>>>>>>> rule any odd race bugs down the road? >>>>>> >>>>>> +1. As I understand, Chris is suggesting to do it in addition to >>>>>> storestore barrier. >>>>> I have made the suggested change. >>>>> http://cr.openjdk.java.net/~thartmann/8143897/webrev.01/ >>>>> >>>>> Best Regards, >>>>> Jamsheed >>>>> >>>>>> >>>>>> Do we have other similar code? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> write to cache is mutex lock protected. so this code is safe. >>>>>>> >>>>>>> Issue is seen in weak memory order machines. lockless read of >>>>>>> exception cache values fails as writes in cache get >>>>>>> reordered. >>>>>>> >>>>>>> Best Regards, >>>>>>> Jamsheed >>>>>>>> >>>>>>>>> On Jan 28, 2016, at 5:16 PM, Jamsheed C m >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review the fix made for issue >>>>>>>>> >>>>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8143897 >>>>>>>>> web rev: http://cr.openjdk.java.net/~thartmann/8143897/webrev.00/ >>>>>>>>> >>>>>>>>> Unit tests: As its hard, none >>>>>>>>> >>>>>>>>> Other tests: jprt. >>>>>>>>> >>>>>>>>> Description of the issue: >>>>>>>>> A valid pc match in exception cache returning an invalid >>>>>>>>> handler makes assert to fail. >>>>>>>>> This happens as ExceptionCache reads are lock free access. >>>>>>>>> >>>>>>>>> As a fix for this i have put a storestore mem barrier before >>>>>>>>> the count is updated. >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Jamsheed >>>>>>> >>>>> >>> >> > From adinn at redhat.com Wed Feb 10 09:24:50 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 10 Feb 2016 09:24:50 +0000 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> Message-ID: <56BB01E2.2090004@redhat.com> Hi Roland, On 29/01/16 13:27, Roland Westrelin wrote: >> I think this looks ok -- not sure until I try it out. However, I /am/ >> fairly sure it is going to cause a problem for the AArch64 code which >> optimizes volatile loads and stores. That's because it change the >> characteristic shape of the subgraph searched for by the predicates >> which decide whether to i) generate loads + membars or ii) plant stlr or >> ladr instructions. >> >> I'll look into this asap. > > Thanks for looking at this. I?ll wait to hear back from you until I move forward with this change. Apologies for the delay in getting back to you on this -- due first to FOSDEM and then falling sick. This patch breaks the AArch64 C2 code to optimize volatile stores for the expected cases: 1) +G1GC 2) +ConcMarkSweepGC + CondCardMark I believe it can be fixed but I have not yet identified the required code changes. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From nils.eliasson at oracle.com Wed Feb 10 09:56:42 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 10 Feb 2016 10:56:42 +0100 Subject: RFR(S): 8138756: Compiler Control: Print directives in hs_err In-Reply-To: <56A27B55.6050502@oracle.com> References: <56A0B237.9090008@oracle.com> <56A0B398.4000408@oracle.com> <56A13176.804@oracle.com> <56A230D7.9060606@oracle.com> <56A27B55.6050502@oracle.com> Message-ID: <56BB095A.2090500@oracle.com> Hi, New webrev including Vladimirs suggestions: http://cr.openjdk.java.net/~neliasso/8138756/webrev.04/ Now it will look like this printing the directive when there are no compile commands for inlining: "--------------- T H R E A D --------------- Current thread (0x00007f53f0468000): JavaThread "C1 CompilerThread10" daemon [_thread_in_native, id=8398, stack(0x00007f52e6163000,0x00007f52e6264000)] Current CompileTask: C1: 228 1 3 java.lang.String::isLatin1 (19 bytes) Compiling with directive: No inline rules in directive. Enable:true Exclude:false BreakAtExecute:false BreakAtCompile:false Log:false PrintAssembly:false *PrintInlining:true PrintNMethods:false ReplayInline:false DumpReplay:false DumpInline:false CompilerDirectivesIgnoreCompileCommands:false DisableIntrinsic: BlockLayoutByFrequency:true PrintOptoAssembly:false PrintIntrinsics:false TraceOptoPipelining:false TraceOptoOutput:false TraceSpilling:false Vectorize:false VectorizeDebug:false CloneMapDebug:false DoReserveCopyInSuperWordDebug:false IGVPrintLevel:0 MaxNodeLimit:80000" And like this when there are: "--------------- T H R E A D --------------- Current thread (0x00007feda4468800): JavaThread "C1 CompilerThread10" daemon [_thread_in_native, id=8314, stack(0x00007fec9a751000,0x00007fec9a852000)] Current CompileTask: C1: 227 1 3 java.lang.String::isLatin1 (19 bytes) Compiling with directive: No inline rules in directive. Following compile commands are in use: inline: b.b, a.a dontinline: c.c exclude: d.d compileonly: *.* Enable:true Exclude:false BreakAtExecute:false BreakAtCompile:false Log:false PrintAssembly:false *PrintInlining:true PrintNMethods:false ReplayInline:false DumpReplay:false DumpInline:false CompilerDirectivesIgnoreCompileCommands:false DisableIntrinsic: BlockLayoutByFrequency:true PrintOptoAssembly:false PrintIntrinsics:false TraceOptoPipelining:false TraceOptoOutput:false TraceSpilling:false Vectorize:false VectorizeDebug:false CloneMapDebug:false DoReserveCopyInSuperWordDebug:false IGVPrintLevel:0 MaxNodeLimit:80000" Regards, Nils On 2016-01-22 19:56, Vladimir Kozlov wrote: > "no inline - compile commands may apply" is confusing to me (and for > others who not familiar with directives). What does it mean? :) > Does it mean no 'inline' directives were used or opposite: -XX:-Inline > flag was specified (or corresponding directive). > > If it is switch off inlining then I think it should be "don't inline". > So what "compile commands may apply" means? > > > I updated the print output to mark all options in the directive that > are > > not default with a '*'. That makes it quicker to see if any special > > Yes, it is better but I still did not get this. I see that command > line has PrintInlining command and it is in the list: > *PrintInlining:true. > But I don't see PrintCompilation on the list but it is specified on > command line. On other hand PrintIntrinsics:false is there. > > > It only prints the directive that is used for the current compile task > > (that caused the crash). (Thats why I put them together in the > hs_err file) > > What do you mean "is used"? > > "Print *which* directive (and options) were in use if compiler crash. > Print *if* directives were used at some point if other crash?" > > Should we replace "in use"/"were used" with "were set"? > > Thanks, > Vladimir > > On 1/22/16 5:38 AM, Nils Eliasson wrote: >> Hi, Vladimir >> >> On 2016-01-21 20:28, Vladimir Kozlov wrote: >>> Passing directives through ciEnv is fine. >>> My question is about output in hs_err file. How those directives were >>> selected in your example? >> >> It only prints the directive that is used for the current compile task >> (that caused the crash). (Thats why I put them together in the hs_err >> file) >> >>> I found it strange to see mixed flags values and oracle commands. >>> "Enable:true Exclude:false" - which these correspond to, for example? >> >> These are all options from the directive - and they are set with >> directives (highest priority), compilecommmand or vmflags (lowest >> priority). >> >>> >>> Should we not print directives/flags which are not set explicitly? >> >> I updated the print output to mark all options in the directive that are >> not default with a '*'. That makes it quicker to see if any special >> options was applied. It will also print if the directive is the >> unmodified default directive. >> >> Webrev: http://cr.openjdk.java.net/~neliasso/8138756/webrev.03/ >> Example output: >> http://cr.openjdk.java.net/~neliasso/8138756/webrev.03/hserr.txt >> >> Regards, >> Nils >> >>> >>> Thanks, >>> Vladimir >>> >>> On 1/21/16 2:31 AM, Nils Eliasson wrote: >>>> This is how it looks: >>>> >>>> [...] >>>> >>>> --------------- T H R E A D --------------- >>>> >>>> Current thread (0x00007f071046a000): JavaThread "C1 >>>> CompilerThread10" daemon [_thread_in_native, id=20033, >>>> stack(0x00007f05d7afb000,0x00007f05d7bfc000)] >>>> >>>> Current CompileTask: >>>> C1: 225 1 3 java.lang.String::isLatin1 (19 bytes) >>>> >>>> Current compiler directive: >>>> inline: - >>>> Enable:true Exclude:false BreakAtExecute:false >>>> BreakAtCompile:false Log:false PrintAssembly:false >>>> PrintInlining:false PrintNMethods:false ReplayInline:false >>>> DumpReplay:false DumpInline:false >>>> CompilerDirectivesIgnoreCompileCommands:false DisableIntrinsic: >>>> BlockLayoutByFrequency:true PrintOptoAssembly:false >>>> PrintIntrinsics:false TraceOptoPipelining:false TraceOptoOutput:false >>>> TraceSpilling:false Vectorize:false VectorizeDebug:false >>>> CloneMapDebug:false DoReserveCopyInSuperWordDebug:false >>>> IGVPrintLevel:0 MaxNodeLimit:80000 >>>> >>>> Stack: [0x00007f05d7afb000,0x00007f05d7bfc000], >>>> sp=0x00007f05d7bfa5d0, free space=1021k >>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>> C=native code) >>>> V [libjvm.so+0x12e7532] VMError::report_and_die(int, char const*, >>>> char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, >>>> char const*, int, unsigned long)+0x182 >>>> V [libjvm.so+0x12e829a] VMError::report_and_die(Thread*, char >>>> const*, int, char const*, char const*, __va_list_tag*)+0x4a >>>> V [libjvm.so+0x908cca] report_vm_error(char const*, int, char >>>> const*, char const*, ...)+0xea >>>> V [libjvm.so+0x88df81] CompileBroker::post_compile(CompilerThread*, >>>> CompileTask*, EventCompilation&, bool, ciEnv*)+0x1b1 >>>> V [libjvm.so+0x88ec5a] >>>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x90a >>>> V [libjvm.so+0x88f960] CompileBroker::compiler_thread_loop()+0x540 >>>> V [libjvm.so+0x1264789] JavaThread::thread_main_inner()+0x1c9 >>>> V [libjvm.so+0x1264ac6] JavaThread::run()+0x2a6 >>>> V [libjvm.so+0x10189aa] java_start(Thread*)+0xca >>>> C [libpthread.so.0+0x8182] start_thread+0xc2 >>>> >>>> [...] >>>> >>>> http://cr.openjdk.java.net/~neliasso/8138756/hserr.txt >>>> >>>> Regards, >>>> Nils >>>> >>>> On 2016-01-21 11:25, Nils Eliasson wrote: >>>>> Hi, >>>>> >>>>> Please review this small change. The diff looks big but most of the >>>>> change is just changing how the directive are >>>>> passed to the compilers. Directives are set in the ciEnv and then >>>>> passed to the compilers. The compilers can then >>>>> choose to add it to any internal compilation object for convenience. >>>>> The hs_err printing routine in vmError.cpp loads >>>>> the directive from the ciEnv. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138756 >>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8138756/webrev.01/ >>>>> >>>>> Regards, >>>>> Nils >>>> >> From konstantin.shefov at oracle.com Wed Feb 10 11:20:01 2016 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 10 Feb 2016 14:20:01 +0300 Subject: [9] RFR 8149472: NPE when executing HotSpotConstantReflectionProvider::constantEquals with null first arg Message-ID: <56BB1CE1.8060301@oracle.com> Hello Please review a bug fix in JVMCI jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider::constantEquals(Constant x, Constant y) method. A NullPointerException is thrown, when one calls this method with the first argument x equal to null. Additional check should be added for null as the first argument. Bug: https://bugs.openjdk.java.net/browse/JDK-8149472 Webrev: http://cr.openjdk.java.net/~kshefov/8149472/webrev.00/ Thanks -Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Wed Feb 10 12:14:57 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 10 Feb 2016 15:14:57 +0300 Subject: RFR (XS) 8149356: Leftover from JDK-8141044: UseNewCode usage In-Reply-To: <56BA4503.8090506@oracle.com> References: <56B9C4A2.1020703@oracle.com> <56BA38CA.4010208@oracle.com> <56BA4503.8090506@oracle.com> Message-ID: <56BB29C1.1090906@oracle.com> Reviewed. Best regards, Vladimir Ivanov On 2/9/16 10:58 PM, Aleksey Shipilev wrote: > Jeez, that's double embarrassing, here is it: > http://cr.openjdk.java.net/~shade/8149356/webrev.01/ > > -Aleksey > > On 09.02.2016 22:06, Vladimir Kozlov wrote: >> Where is webrev? >> >> thanks, >> Vladimir K >> >> On 2/9/16 2:51 AM, Aleksey Shipilev wrote: >>> Hi, >>> >>> In JDK-8141044 ("C1 should fold (this == null) to false") change, I have >>> accidentally pushed the implementation predicated under UseNewCode flag. >>> Thanks to Vladimir Ivanov for finding this! We need to drop the >>> UseNewCode check: >>> https://bugs.openjdk.java.net/browse/JDK-8149356 >>> >>> Testing: JPRT -testset hotspot, eyeballing the C1 PrintAssembly for >>> original test >>> >>> Cheers, >>> -Aleksey >>> > > From rahul.v.raghavan at oracle.com Wed Feb 10 12:40:28 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 10 Feb 2016 04:40:28 -0800 (PST) Subject: RFR (XXS): 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 Message-ID: <27266fb9-dca7-4285-88df-b36f8a650a53@default> Hi, Please review following patch proposal to avoid 'possible uninitialised variable' warnings for internal tests. webrev: http://cr.openjdk.java.net/~thartmann/8145700/webrev.00/ Confirmed no issues with jprt run (-testset hotspot). Thanks, Rahul From tobias.hartmann at oracle.com Wed Feb 10 12:43:31 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 10 Feb 2016 13:43:31 +0100 Subject: RFR (XXS): 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 In-Reply-To: <27266fb9-dca7-4285-88df-b36f8a650a53@default> References: <27266fb9-dca7-4285-88df-b36f8a650a53@default> Message-ID: <56BB3073.9010506@oracle.com> Hi Rahul, looks good to me. Best, Tobias On 10.02.2016 13:40, Rahul Raghavan wrote: > Hi, > > Please review following patch proposal to avoid 'possible uninitialised variable' warnings for internal tests. > > webrev: http://cr.openjdk.java.net/~thartmann/8145700/webrev.00/ > > Confirmed no issues with jprt run (-testset hotspot). > > Thanks, > Rahul > From vladimir.x.ivanov at oracle.com Wed Feb 10 12:43:35 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 10 Feb 2016 15:43:35 +0300 Subject: RFR (XXS): 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 In-Reply-To: <27266fb9-dca7-4285-88df-b36f8a650a53@default> References: <27266fb9-dca7-4285-88df-b36f8a650a53@default> Message-ID: <56BB3077.5040209@oracle.com> Looks good. Best regards, Vladimir Ivanov On 2/10/16 3:40 PM, Rahul Raghavan wrote: > Hi, > > Please review following patch proposal to avoid 'possible uninitialised variable' warnings for internal tests. > > webrev: http://cr.openjdk.java.net/~thartmann/8145700/webrev.00/ > > Confirmed no issues with jprt run (-testset hotspot). > > Thanks, > Rahul > From rahul.v.raghavan at oracle.com Wed Feb 10 12:58:29 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 10 Feb 2016 04:58:29 -0800 (PST) Subject: RFR (XXS): 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 In-Reply-To: <56BB3073.9010506@oracle.com> References: <27266fb9-dca7-4285-88df-b36f8a650a53@default> <56BB3073.9010506@oracle.com> Message-ID: <9a76deeb-859c-4187-87d7-a5a868f42259@default> > -----Original Message----- > From: Tobias Hartmann > Sent: Wednesday, February 10, 2016 6:14 PM > To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net > > Hi Rahul, > > looks good to me. Thank you Tobias. > > Best, > Tobias > > On 10.02.2016 13:40, Rahul Raghavan wrote: > > Hi, > > > > Please review following patch proposal to avoid 'possible uninitialised variable' warnings for internal tests. > > > > webrev: http://cr.openjdk.java.net/~thartmann/8145700/webrev.00/ > > > > Confirmed no issues with jprt run (-testset hotspot). > > > > Thanks, > > Rahul > > From rahul.v.raghavan at oracle.com Wed Feb 10 12:59:16 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 10 Feb 2016 04:59:16 -0800 (PST) Subject: RFR (XXS): 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 In-Reply-To: <56BB3077.5040209@oracle.com> References: <27266fb9-dca7-4285-88df-b36f8a650a53@default> <56BB3077.5040209@oracle.com> Message-ID: > -----Original Message----- > From: Vladimir Ivanov > Sent: Wednesday, February 10, 2016 6:14 PM > To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net > > Looks good. Thank you Vladimir Ivanov. > > Best regards, > Vladimir Ivanov > > On 2/10/16 3:40 PM, Rahul Raghavan wrote: > > Hi, > > > > Please review following patch proposal to avoid 'possible uninitialised variable' warnings for internal tests. > > > > webrev: http://cr.openjdk.java.net/~thartmann/8145700/webrev.00/ > > > > Confirmed no issues with jprt run (-testset hotspot). > > > > Thanks, > > Rahul > > From aph at redhat.com Wed Feb 10 13:05:26 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Feb 2016 13:05:26 +0000 Subject: Use jmh for benchmarks [Was: RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code] In-Reply-To: References: Message-ID: <56BB3596.2070000@redhat.com> It's very important to use JMH for HotSpot benchmarks. Without JMH, it is very hard to tell if you're measuring the right thing. In order to help you get started, I've appended a JMH version of your benchmark. Run it with: build/linux-aarch64-normal-server-release/jdk/bin/java -jar \ jmh-samples/target/microbenchmarks.jar '.*JMHSample_96.*' -wi 5 -i 10 \ -f 0 Andrew. ----------------------------------------------------------------------- package org.openjdk.jmh.samples; import org.openjdk.jmh.annotations.BenchmarkMode; import org.openjdk.jmh.annotations.GenerateMicroBenchmark; import org.openjdk.jmh.annotations.BenchmarkMode; import org.openjdk.jmh.annotations.GenerateMicroBenchmark; import org.openjdk.jmh.annotations.Mode; import org.openjdk.jmh.annotations.OutputTimeUnit; import org.openjdk.jmh.annotations.Scope; import org.openjdk.jmh.annotations.State; import org.openjdk.jmh.runner.Runner; import org.openjdk.jmh.runner.RunnerException; import org.openjdk.jmh.runner.options.Options; import org.openjdk.jmh.runner.options.OptionsBuilder; import java.util.concurrent.TimeUnit; import java.nio.*; import java.util.*; import java.util.concurrent.*; @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.MICROSECONDS) public class JMHSample_96_StringAppend { @State(Scope.Benchmark) public static class BenchmarkState { final String[] strs = { "aoiod", // 5 "adsdefrgda", // 10 "dsadsadadsdsadiomjdas", // 20 "djsadusahdusaufdoaaiffjdkdpjikl", // 30 "dsudhusuhfudhaufhduahfduafhdkaffhdjafjdfa", // 40 "dhsuafydagfydagfdafdajlkejwfjfuhfuafjhdahfldjksl90s", // 50 "dsajufhdaufhdasuifhdasjkfndasjkfgbaduygbiafjioeawjfioiopjsdljl", // 60 "dshaudshauidshauidhsiufhdasjklfdbnasjkvbauyvbdyargfwrheuifgeuijikalkjfds", // 70 "nvfjsvnfusdbvfuyafbduyasfdsjkfhdjkasfhdjksafhdjksfhdjksfhasdjkncxsvnxcm,fdjklfjdkf", // 80 "fdhuafdhasuifhdasuigbdjkbvcjksbdfhduasfhduasifhdasjkfhdasjkfhdjklasfoeurieoiruwiowurieoureik", // 90 "dshfudahfduiashfduiasnvdjkvnuiarheuirheiodfhdjksafhuiheuiafheaskfdhjkasfhdjkashfdjkashfdjkasuipiuk890f", // 100 }; } @GenerateMicroBenchmark public StringBuilder doIt(BenchmarkState state) { StringBuilder strBuf = new StringBuilder(); for (String s : state.strs) { strBuf.append(s); } return strBuf; } public static void main(String[] args) throws RunnerException { Options opt = new OptionsBuilder() .include(".*" + JMHSample_96_StringAppend.class.getSimpleName() + ".*") .warmupIterations(5) .measurementIterations(5) .forks(1) .build(); new Runner(opt).run(); } } From roland.westrelin at oracle.com Wed Feb 10 13:11:35 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 10 Feb 2016 14:11:35 +0100 Subject: RFR(XS): 8149543: range check CastII nodes should not be split through Phi Message-ID: http://cr.openjdk.java.net/~roland/8149543/webrev.00/ Reported by Michael Berg for vectorization optimizations. In cases like this: public static float sumListReduction(float[] a, float[] b, float[] c, float[] d, float total, int process_len) { for(int i = 0; i < process_len; i++) { d[i]= (a[i] * b[i]) + (a[i] * c[i]) + (b[i] * c[i]); } total += d[0]; total += d[process_len-1]; return total; } Range check CastII nodes are split through the loop induction Phi which causes new Phis to be created that are unrelated to the trip Phi and prevent further optimizations: Phi 735 718 43 384 [ 784 384 ] bci = 10 debug_orig = dump_spec = #int:>=1:www #tripcount debug_idx = 17200735 line = 32 type = int: Phi 921 718 43 384 [ 727 ] bci = 16 debug_orig = dump_spec = #int:1..max-1:www debug_idx = 23800921 line = 32 type = int: I propose we simply don?t split range check CastII nodes through Phis. Roland. From roland.westrelin at oracle.com Wed Feb 10 13:14:46 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 10 Feb 2016 14:14:46 +0100 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <56BB01E2.2090004@redhat.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> Message-ID: <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> Hi Andrew, > This patch breaks the AArch64 C2 code to optimize volatile stores for > the expected cases: > > 1) +G1GC > 2) +ConcMarkSweepGC + CondCardMark > > I believe it can be fixed but I have not yet identified the required > code changes. Thanks for the update. I?ll wait to hear back from you before I get this in. Roland. From aph at redhat.com Wed Feb 10 13:18:18 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Feb 2016 13:18:18 +0000 Subject: RFR (M): 8149415: [AArch64] implement JVMCI CodeInstaller In-Reply-To: <24D1E72C-5F70-4073-8EC2-9E291093DC29@oracle.com> References: <24D1E72C-5F70-4073-8EC2-9E291093DC29@oracle.com> Message-ID: <56BB389A.1010909@redhat.com> On 09/02/16 22:39, Christian Thalinger wrote: > This is a first cut of the CodeInstaller implementation for AArch64. One missing part is compressed oops support but it?s not a big issue because Graal doesn?t support it yet either. > > The patch also includes changes to AMD64 and SPARC?s RegisterConfig to use an array for the reserved registers. The code before was too hard to understand. Yeah, that all looks plausible. Thanks, Andrew. From aph at redhat.com Wed Feb 10 15:41:13 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Feb 2016 15:41:13 +0000 Subject: RFR(s): AAch64: Adding byte array equal support In-Reply-To: <56B71DDE.2040109@redhat.com> References: <56B71DDE.2040109@redhat.com> Message-ID: <56BB5A19.60001@redhat.com> On 02/07/2016 10:35 AM, Andrew Haley wrote: > On 06/02/16 12:24, Hui Shi wrote: >> Hi All, >> >> Would someone help review this patch for adding byte array equal support on >> aarch64? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8149100 >> webrev: http://cr.openjdk.java.net/~hshi/8149100/webrev/ > > Ok, thanks. Having said that, I'm unhappy that this code is almost exactly the same as char_arrays_equals, seeming to have a slab of identical code. We've also got char_arrays_equals, which seems to do the same thing as string_equals. Andrew. From vladimir.kozlov at oracle.com Wed Feb 10 17:42:51 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Feb 2016 09:42:51 -0800 Subject: RFR (XXS): 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 In-Reply-To: <27266fb9-dca7-4285-88df-b36f8a650a53@default> References: <27266fb9-dca7-4285-88df-b36f8a650a53@default> Message-ID: <56BB769B.8080105@oracle.com> Looks good. Thanks, Vladimir On 2/10/16 4:40 AM, Rahul Raghavan wrote: > Hi, > > Please review following patch proposal to avoid 'possible uninitialised variable' warnings for internal tests. > > webrev: http://cr.openjdk.java.net/~thartmann/8145700/webrev.00/ > > Confirmed no issues with jprt run (-testset hotspot). > > Thanks, > Rahul > From vladimir.kozlov at oracle.com Wed Feb 10 17:53:29 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Feb 2016 09:53:29 -0800 Subject: RFR(XS): 8149543: range check CastII nodes should not be split through Phi In-Reply-To: References: Message-ID: <56BB7919.1060900@oracle.com> It would be nice if we could narrow this bailout only for loops. I mean when Phi's control is loop's head. If it is an ordinary merge region splitting through it may help to improve performance. What do you think? Could you run some performance tests to effects. If ordinary region cases are rare then you current fix is good enough. Thanks, Vladimir On 2/10/16 5:11 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8149543/webrev.00/ > > Reported by Michael Berg for vectorization optimizations. > In cases like this: > > public static float sumListReduction(float[] a, float[] b, float[] c, float[] d, float total, int process_len) > { > for(int i = 0; i < process_len; i++) > { > d[i]= (a[i] * b[i]) + (a[i] * c[i]) + (b[i] * c[i]); > } > > total += d[0]; > total += d[process_len-1]; > return total; > } > > Range check CastII nodes are split through the loop induction Phi which causes new Phis to be created that are unrelated to the trip Phi and prevent further optimizations: > > Phi 735 718 43 384 [ 784 384 ] bci = 10 debug_orig = dump_spec = #int:>=1:www #tripcount debug_idx = 17200735 line = 32 type = int: > > Phi 921 718 43 384 [ 727 ] bci = 16 debug_orig = dump_spec = #int:1..max-1:www debug_idx = 23800921 line = 32 type = int: > > I propose we simply don?t split range check CastII nodes through Phis. > > Roland. > From vladimir.kozlov at oracle.com Wed Feb 10 18:00:21 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Feb 2016 10:00:21 -0800 Subject: [9] RFR 8149472: NPE when executing HotSpotConstantReflectionProvider::constantEquals with null first arg In-Reply-To: <56BB1CE1.8060301@oracle.com> References: <56BB1CE1.8060301@oracle.com> Message-ID: <56BB7AB5.2080304@oracle.com> Good. I assume that NULL is valid case in this test. Right? Thanks, Vladimir On 2/10/16 3:20 AM, Konstantin Shefov wrote: > Hello > > Please review a bug fix in JVMCI jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider::constantEquals(Constant x, > Constant y) method. > > A NullPointerException is thrown, when one calls this method with the first argument x equal to null. > > Additional check should be added for null as the first argument. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149472 > Webrev: http://cr.openjdk.java.net/~kshefov/8149472/webrev.00/ > > Thanks > -Konstantin > From vladimir.kozlov at oracle.com Wed Feb 10 18:15:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Feb 2016 10:15:35 -0800 Subject: RFR(S): 8138756: Compiler Control: Print directives in hs_err In-Reply-To: <56BB095A.2090500@oracle.com> References: <56A0B237.9090008@oracle.com> <56A0B398.4000408@oracle.com> <56A13176.804@oracle.com> <56A230D7.9060606@oracle.com> <56A27B55.6050502@oracle.com> <56BB095A.2090500@oracle.com> Message-ID: <56BB7E47.4000703@oracle.com> This looks almost good. There is " at the end but there is no first ": MaxNodeLimit:80000" "Compiling with directive:" --> "Compiling with directives:". "No inline rules in directive.", again "directives". Also the list of values is difficult to navigate. To have one per line is definitely overkill but organizing them in some kind of patter would be nice (3 per line with the same indent, for example). It could be hard to do but at least order them alphabetically. I asked before and I again forgot what it means "Enable:true Exclude:false". This means you need to add more info "Enable directives:true"? What is "Exclude" again? DisableIntrinsic: does not have value so it should not be on list. Similar for others when they don't have values. Again what * means in "*PrintInlining:true"? Is it because it is present on command line? Thanks, Vladimir On 2/10/16 1:56 AM, Nils Eliasson wrote: > Hi, > > New webrev including Vladimirs suggestions: > > http://cr.openjdk.java.net/~neliasso/8138756/webrev.04/ > > Now it will look like this printing the directive when there are no compile commands for inlining: > > "--------------- T H R E A D --------------- > > Current thread (0x00007f53f0468000): JavaThread "C1 CompilerThread10" daemon [_thread_in_native, id=8398, > stack(0x00007f52e6163000,0x00007f52e6264000)] > > Current CompileTask: > C1: 228 1 3 java.lang.String::isLatin1 (19 bytes) > > Compiling with directive: > No inline rules in directive. > Enable:true Exclude:false BreakAtExecute:false BreakAtCompile:false Log:false PrintAssembly:false *PrintInlining:true > PrintNMethods:false ReplayInline:false DumpReplay:false DumpInline:false CompilerDirectivesIgnoreCompileCommands:false > DisableIntrinsic: BlockLayoutByFrequency:true PrintOptoAssembly:false PrintIntrinsics:false TraceOptoPipelining:false > TraceOptoOutput:false TraceSpilling:false Vectorize:false VectorizeDebug:false CloneMapDebug:false > DoReserveCopyInSuperWordDebug:false IGVPrintLevel:0 MaxNodeLimit:80000" > > > > And like this when there are: > > > "--------------- T H R E A D --------------- > > Current thread (0x00007feda4468800): JavaThread "C1 CompilerThread10" daemon [_thread_in_native, id=8314, > stack(0x00007fec9a751000,0x00007fec9a852000)] > > Current CompileTask: > C1: 227 1 3 java.lang.String::isLatin1 (19 bytes) > > Compiling with directive: > No inline rules in directive. Following compile commands are in use: > inline: b.b, a.a > dontinline: c.c > exclude: d.d > compileonly: *.* > Enable:true Exclude:false BreakAtExecute:false BreakAtCompile:false Log:false PrintAssembly:false *PrintInlining:true > PrintNMethods:false ReplayInline:false DumpReplay:false DumpInline:false CompilerDirectivesIgnoreCompileCommands:false > DisableIntrinsic: BlockLayoutByFrequency:true PrintOptoAssembly:false PrintIntrinsics:false TraceOptoPipelining:false > TraceOptoOutput:false TraceSpilling:false Vectorize:false VectorizeDebug:false CloneMapDebug:false > DoReserveCopyInSuperWordDebug:false IGVPrintLevel:0 MaxNodeLimit:80000" > > Regards, > Nils > > On 2016-01-22 19:56, Vladimir Kozlov wrote: >> "no inline - compile commands may apply" is confusing to me (and for others who not familiar with directives). What >> does it mean? :) >> Does it mean no 'inline' directives were used or opposite: -XX:-Inline flag was specified (or corresponding directive). >> >> If it is switch off inlining then I think it should be "don't inline". >> So what "compile commands may apply" means? >> >> > I updated the print output to mark all options in the directive that are >> > not default with a '*'. That makes it quicker to see if any special >> >> Yes, it is better but I still did not get this. I see that command line has PrintInlining command and it is in the >> list: *PrintInlining:true. >> But I don't see PrintCompilation on the list but it is specified on command line. On other hand PrintIntrinsics:false >> is there. >> >> > It only prints the directive that is used for the current compile task >> > (that caused the crash). (Thats why I put them together in the hs_err file) >> >> What do you mean "is used"? >> >> "Print *which* directive (and options) were in use if compiler crash. >> Print *if* directives were used at some point if other crash?" >> >> Should we replace "in use"/"were used" with "were set"? >> >> Thanks, >> Vladimir >> >> On 1/22/16 5:38 AM, Nils Eliasson wrote: >>> Hi, Vladimir >>> >>> On 2016-01-21 20:28, Vladimir Kozlov wrote: >>>> Passing directives through ciEnv is fine. >>>> My question is about output in hs_err file. How those directives were >>>> selected in your example? >>> >>> It only prints the directive that is used for the current compile task >>> (that caused the crash). (Thats why I put them together in the hs_err file) >>> >>>> I found it strange to see mixed flags values and oracle commands. >>>> "Enable:true Exclude:false" - which these correspond to, for example? >>> >>> These are all options from the directive - and they are set with >>> directives (highest priority), compilecommmand or vmflags (lowest >>> priority). >>> >>>> >>>> Should we not print directives/flags which are not set explicitly? >>> >>> I updated the print output to mark all options in the directive that are >>> not default with a '*'. That makes it quicker to see if any special >>> options was applied. It will also print if the directive is the >>> unmodified default directive. >>> >>> Webrev: http://cr.openjdk.java.net/~neliasso/8138756/webrev.03/ >>> Example output: >>> http://cr.openjdk.java.net/~neliasso/8138756/webrev.03/hserr.txt >>> >>> Regards, >>> Nils >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/21/16 2:31 AM, Nils Eliasson wrote: >>>>> This is how it looks: >>>>> >>>>> [...] >>>>> >>>>> --------------- T H R E A D --------------- >>>>> >>>>> Current thread (0x00007f071046a000): JavaThread "C1 >>>>> CompilerThread10" daemon [_thread_in_native, id=20033, >>>>> stack(0x00007f05d7afb000,0x00007f05d7bfc000)] >>>>> >>>>> Current CompileTask: >>>>> C1: 225 1 3 java.lang.String::isLatin1 (19 bytes) >>>>> >>>>> Current compiler directive: >>>>> inline: - >>>>> Enable:true Exclude:false BreakAtExecute:false >>>>> BreakAtCompile:false Log:false PrintAssembly:false >>>>> PrintInlining:false PrintNMethods:false ReplayInline:false >>>>> DumpReplay:false DumpInline:false >>>>> CompilerDirectivesIgnoreCompileCommands:false DisableIntrinsic: >>>>> BlockLayoutByFrequency:true PrintOptoAssembly:false >>>>> PrintIntrinsics:false TraceOptoPipelining:false TraceOptoOutput:false >>>>> TraceSpilling:false Vectorize:false VectorizeDebug:false >>>>> CloneMapDebug:false DoReserveCopyInSuperWordDebug:false >>>>> IGVPrintLevel:0 MaxNodeLimit:80000 >>>>> >>>>> Stack: [0x00007f05d7afb000,0x00007f05d7bfc000], >>>>> sp=0x00007f05d7bfa5d0, free space=1021k >>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>> C=native code) >>>>> V [libjvm.so+0x12e7532] VMError::report_and_die(int, char const*, >>>>> char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, >>>>> char const*, int, unsigned long)+0x182 >>>>> V [libjvm.so+0x12e829a] VMError::report_and_die(Thread*, char >>>>> const*, int, char const*, char const*, __va_list_tag*)+0x4a >>>>> V [libjvm.so+0x908cca] report_vm_error(char const*, int, char >>>>> const*, char const*, ...)+0xea >>>>> V [libjvm.so+0x88df81] CompileBroker::post_compile(CompilerThread*, >>>>> CompileTask*, EventCompilation&, bool, ciEnv*)+0x1b1 >>>>> V [libjvm.so+0x88ec5a] >>>>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x90a >>>>> V [libjvm.so+0x88f960] CompileBroker::compiler_thread_loop()+0x540 >>>>> V [libjvm.so+0x1264789] JavaThread::thread_main_inner()+0x1c9 >>>>> V [libjvm.so+0x1264ac6] JavaThread::run()+0x2a6 >>>>> V [libjvm.so+0x10189aa] java_start(Thread*)+0xca >>>>> C [libpthread.so.0+0x8182] start_thread+0xc2 >>>>> >>>>> [...] >>>>> >>>>> http://cr.openjdk.java.net/~neliasso/8138756/hserr.txt >>>>> >>>>> Regards, >>>>> Nils >>>>> >>>>> On 2016-01-21 11:25, Nils Eliasson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this small change. The diff looks big but most of the >>>>>> change is just changing how the directive are >>>>>> passed to the compilers. Directives are set in the ciEnv and then >>>>>> passed to the compilers. The compilers can then >>>>>> choose to add it to any internal compilation object for convenience. >>>>>> The hs_err printing routine in vmError.cpp loads >>>>>> the directive from the ciEnv. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138756 >>>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8138756/webrev.01/ >>>>>> >>>>>> Regards, >>>>>> Nils >>>>> >>> > From michael.c.berg at intel.com Wed Feb 10 18:24:49 2016 From: michael.c.berg at intel.com (Berg, Michael C) Date: Wed, 10 Feb 2016 18:24:49 +0000 Subject: RFR (XXS): 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 In-Reply-To: <27266fb9-dca7-4285-88df-b36f8a650a53@default> References: <27266fb9-dca7-4285-88df-b36f8a650a53@default> Message-ID: Looks good. -Michael -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Rahul Raghavan Sent: Wednesday, February 10, 2016 4:40 AM To: hotspot-compiler-dev at openjdk.java.net Subject: RFR (XXS): 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 Hi, Please review following patch proposal to avoid 'possible uninitialised variable' warnings for internal tests. webrev: http://cr.openjdk.java.net/~thartmann/8145700/webrev.00/ Confirmed no issues with jprt run (-testset hotspot). Thanks, Rahul From michael.c.berg at intel.com Wed Feb 10 18:27:08 2016 From: michael.c.berg at intel.com (Berg, Michael C) Date: Wed, 10 Feb 2016 18:27:08 +0000 Subject: RFR(XS): 8149543: range check CastII nodes should not be split through Phi In-Reply-To: References: Message-ID: Looks good to me. Regards, Michael -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin Sent: Wednesday, February 10, 2016 5:12 AM To: hotspot compiler Subject: RFR(XS): 8149543: range check CastII nodes should not be split through Phi http://cr.openjdk.java.net/~roland/8149543/webrev.00/ Reported by Michael Berg for vectorization optimizations. In cases like this: public static float sumListReduction(float[] a, float[] b, float[] c, float[] d, float total, int process_len) { for(int i = 0; i < process_len; i++) { d[i]= (a[i] * b[i]) + (a[i] * c[i]) + (b[i] * c[i]); } total += d[0]; total += d[process_len-1]; return total; } Range check CastII nodes are split through the loop induction Phi which causes new Phis to be created that are unrelated to the trip Phi and prevent further optimizations: Phi 735 718 43 384 [ 784 384 ] bci = 10 debug_orig = dump_spec = #int:>=1:www #tripcount debug_idx = 17200735 line = 32 type = int: Phi 921 718 43 384 [ 727 ] bci = 16 debug_orig = dump_spec = #int:1..max-1:www debug_idx = 23800921 line = 32 type = int: I propose we simply don?t split range check CastII nodes through Phis. Roland. From vladimir.kozlov at oracle.com Wed Feb 10 18:54:43 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Feb 2016 10:54:43 -0800 Subject: RFR (M): 8149415: [AArch64] implement JVMCI CodeInstaller In-Reply-To: <24D1E72C-5F70-4073-8EC2-9E291093DC29@oracle.com> References: <24D1E72C-5F70-4073-8EC2-9E291093DC29@oracle.com> Message-ID: <56BB8773.30103@oracle.com> Why you need #ifdef _LP64 in jvmciCodeInstaller_aarch64.cpp? It is only 64 bit VM. Otherwise looks good. Thanks, Vladimir On 2/9/16 2:39 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8149415 > http://cr.openjdk.java.net/~twisti/8149415/webrev.01/ > > This is a first cut of the CodeInstaller implementation for AArch64. One missing part is compressed oops support but > it?s not a big issue because Graal doesn?t support it yet either. > > The patch also includes changes to AMD64 and SPARC?s RegisterConfig to use an array for the reserved registers. The > code before was too hard to understand. > From doug.simon at oracle.com Wed Feb 10 19:32:01 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 10 Feb 2016 20:32:01 +0100 Subject: [9] RFR 8149472: NPE when executing HotSpotConstantReflectionProvider::constantEquals with null first arg In-Reply-To: <56BB7AB5.2080304@oracle.com> References: <56BB1CE1.8060301@oracle.com> <56BB7AB5.2080304@oracle.com> Message-ID: <74405C95-64FF-4785-964C-693797945FD0@oracle.com> > On 10 Feb 2016, at 19:00, Vladimir Kozlov wrote: > > Good. I assume that NULL is valid case in this test. Right? Yes, null is ok for either x or y in this method. > > Thanks, > Vladimir > > On 2/10/16 3:20 AM, Konstantin Shefov wrote: >> Hello >> >> Please review a bug fix in JVMCI jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider::constantEquals(Constant x, >> Constant y) method. >> >> A NullPointerException is thrown, when one calls this method with the first argument x equal to null. >> >> Additional check should be added for null as the first argument. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149472 >> Webrev: http://cr.openjdk.java.net/~kshefov/8149472/webrev.00/ >> >> Thanks >> -Konstantin >> From christian.thalinger at oracle.com Wed Feb 10 19:58:19 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 10 Feb 2016 09:58:19 -1000 Subject: RFR (M): 8149415: [AArch64] implement JVMCI CodeInstaller In-Reply-To: <56BB8773.30103@oracle.com> References: <24D1E72C-5F70-4073-8EC2-9E291093DC29@oracle.com> <56BB8773.30103@oracle.com> Message-ID: > On Feb 10, 2016, at 8:54 AM, Vladimir Kozlov wrote: > > Why you need #ifdef _LP64 in jvmciCodeInstaller_aarch64.cpp? It is only 64 bit VM. Haha, yeah, good point. Copy-paste :-) I?ll remove it. > Otherwise looks good. > > Thanks, > Vladimir > > On 2/9/16 2:39 PM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8149415 >> http://cr.openjdk.java.net/~twisti/8149415/webrev.01/ >> >> This is a first cut of the CodeInstaller implementation for AArch64. One missing part is compressed oops support but >> it?s not a big issue because Graal doesn?t support it yet either. >> >> The patch also includes changes to AMD64 and SPARC?s RegisterConfig to use an array for the reserved registers. The >> code before was too hard to understand. >> From christian.thalinger at oracle.com Wed Feb 10 20:02:55 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 10 Feb 2016 10:02:55 -1000 Subject: [9] RFR 8149472: NPE when executing HotSpotConstantReflectionProvider::constantEquals with null first arg In-Reply-To: <56BB1CE1.8060301@oracle.com> References: <56BB1CE1.8060301@oracle.com> Message-ID: + return Objects.equals(x,y); There is a missing space. Are you using an IDE? > On Feb 10, 2016, at 1:20 AM, Konstantin Shefov wrote: > > Hello > > Please review a bug fix in JVMCI jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider::constantEquals(Constant x, Constant y) method. > > A NullPointerException is thrown, when one calls this method with the first argument x equal to null. > > Additional check should be added for null as the first argument. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149472 > Webrev: http://cr.openjdk.java.net/~kshefov/8149472/webrev.00/ > > Thanks > -Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Wed Feb 10 20:34:24 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 10 Feb 2016 10:34:24 -1000 Subject: RFR(XS): 8149123: [TESTBUG] compiler/loopopts/superword/SumRed* tests running on non-x86 platforms In-Reply-To: <56BAD6CD.3030104@oracle.com> References: <56B9E662.7070004@oracle.com> <9C8E72B2-211D-4830-BE2A-A58A857E7F64@oracle.com> <56BAD6CD.3030104@oracle.com> Message-ID: > On Feb 9, 2016, at 8:21 PM, Jamsheed C m wrote: > > > > On 2/10/2016 3:30 AM, Christian Thalinger wrote: >> All of these are supported on aarch64 except the last one? >> >> test/compiler/loopopts/superword/SumRed_Long.java > > Yes Chris, > > ref: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018638.html Who would?ve known :-) > > Best Regards, > Jamsheed >> >>> On Feb 9, 2016, at 3:15 AM, Jamsheed C m wrote: >>> >>> Hi, >>> >>> bug link :https://bugs.openjdk.java.net/browse/JDK-8149123 >>> web rev :http://cr.openjdk.java.net/~thartmann/8149123/webrev.00/ >>> Fix Summary: Restricted the execution to supported archs. >>> Unit Tests: jprt verified. >>> >>> Best Regards, >>> Jamsheed >>> >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Wed Feb 10 20:36:07 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 10 Feb 2016 10:36:07 -1000 Subject: RFR(S): 8138756: Compiler Control: Print directives in hs_err In-Reply-To: <56BB7E47.4000703@oracle.com> References: <56A0B237.9090008@oracle.com> <56A0B398.4000408@oracle.com> <56A13176.804@oracle.com> <56A230D7.9060606@oracle.com> <56A27B55.6050502@oracle.com> <56BB095A.2090500@oracle.com> <56BB7E47.4000703@oracle.com> Message-ID: <80B5A3C8-BE6C-4B3E-80DB-13119FE99075@oracle.com> > On Feb 10, 2016, at 8:15 AM, Vladimir Kozlov wrote: > > This looks almost good. > > There is " at the end but there is no first ": > > MaxNodeLimit:80000" > > "Compiling with directive:" --> "Compiling with directives:". "No inline rules in directive.", again "directives". > > Also the list of values is difficult to navigate. I agree. It?s almost impossible to parse. > To have one per line is definitely overkill but organizing them in some kind of patter would be nice (3 per line with the same indent, for example). It could be hard to do but at least order them alphabetically. > > I asked before and I again forgot what it means "Enable:true Exclude:false". This means you need to add more info "Enable directives:true"? What is "Exclude" again? > > DisableIntrinsic: does not have value so it should not be on list. Similar for others when they don't have values. > > Again what * means in "*PrintInlining:true"? Is it because it is present on command line? > > Thanks, > Vladimir > > On 2/10/16 1:56 AM, Nils Eliasson wrote: >> Hi, >> >> New webrev including Vladimirs suggestions: >> >> http://cr.openjdk.java.net/~neliasso/8138756/webrev.04/ >> >> Now it will look like this printing the directive when there are no compile commands for inlining: >> >> "--------------- T H R E A D --------------- >> >> Current thread (0x00007f53f0468000): JavaThread "C1 CompilerThread10" daemon [_thread_in_native, id=8398, >> stack(0x00007f52e6163000,0x00007f52e6264000)] >> >> Current CompileTask: >> C1: 228 1 3 java.lang.String::isLatin1 (19 bytes) >> >> Compiling with directive: >> No inline rules in directive. >> Enable:true Exclude:false BreakAtExecute:false BreakAtCompile:false Log:false PrintAssembly:false *PrintInlining:true >> PrintNMethods:false ReplayInline:false DumpReplay:false DumpInline:false CompilerDirectivesIgnoreCompileCommands:false >> DisableIntrinsic: BlockLayoutByFrequency:true PrintOptoAssembly:false PrintIntrinsics:false TraceOptoPipelining:false >> TraceOptoOutput:false TraceSpilling:false Vectorize:false VectorizeDebug:false CloneMapDebug:false >> DoReserveCopyInSuperWordDebug:false IGVPrintLevel:0 MaxNodeLimit:80000" >> >> >> >> And like this when there are: >> >> >> "--------------- T H R E A D --------------- >> >> Current thread (0x00007feda4468800): JavaThread "C1 CompilerThread10" daemon [_thread_in_native, id=8314, >> stack(0x00007fec9a751000,0x00007fec9a852000)] >> >> Current CompileTask: >> C1: 227 1 3 java.lang.String::isLatin1 (19 bytes) >> >> Compiling with directive: >> No inline rules in directive. Following compile commands are in use: >> inline: b.b, a.a >> dontinline: c.c >> exclude: d.d >> compileonly: *.* >> Enable:true Exclude:false BreakAtExecute:false BreakAtCompile:false Log:false PrintAssembly:false *PrintInlining:true >> PrintNMethods:false ReplayInline:false DumpReplay:false DumpInline:false CompilerDirectivesIgnoreCompileCommands:false >> DisableIntrinsic: BlockLayoutByFrequency:true PrintOptoAssembly:false PrintIntrinsics:false TraceOptoPipelining:false >> TraceOptoOutput:false TraceSpilling:false Vectorize:false VectorizeDebug:false CloneMapDebug:false >> DoReserveCopyInSuperWordDebug:false IGVPrintLevel:0 MaxNodeLimit:80000" >> >> Regards, >> Nils >> >> On 2016-01-22 19:56, Vladimir Kozlov wrote: >>> "no inline - compile commands may apply" is confusing to me (and for others who not familiar with directives). What >>> does it mean? :) >>> Does it mean no 'inline' directives were used or opposite: -XX:-Inline flag was specified (or corresponding directive). >>> >>> If it is switch off inlining then I think it should be "don't inline". >>> So what "compile commands may apply" means? >>> >>> > I updated the print output to mark all options in the directive that are >>> > not default with a '*'. That makes it quicker to see if any special >>> >>> Yes, it is better but I still did not get this. I see that command line has PrintInlining command and it is in the >>> list: *PrintInlining:true. >>> But I don't see PrintCompilation on the list but it is specified on command line. On other hand PrintIntrinsics:false >>> is there. >>> >>> > It only prints the directive that is used for the current compile task >>> > (that caused the crash). (Thats why I put them together in the hs_err file) >>> >>> What do you mean "is used"? >>> >>> "Print *which* directive (and options) were in use if compiler crash. >>> Print *if* directives were used at some point if other crash?" >>> >>> Should we replace "in use"/"were used" with "were set"? >>> >>> Thanks, >>> Vladimir >>> >>> On 1/22/16 5:38 AM, Nils Eliasson wrote: >>>> Hi, Vladimir >>>> >>>> On 2016-01-21 20:28, Vladimir Kozlov wrote: >>>>> Passing directives through ciEnv is fine. >>>>> My question is about output in hs_err file. How those directives were >>>>> selected in your example? >>>> >>>> It only prints the directive that is used for the current compile task >>>> (that caused the crash). (Thats why I put them together in the hs_err file) >>>> >>>>> I found it strange to see mixed flags values and oracle commands. >>>>> "Enable:true Exclude:false" - which these correspond to, for example? >>>> >>>> These are all options from the directive - and they are set with >>>> directives (highest priority), compilecommmand or vmflags (lowest >>>> priority). >>>> >>>>> >>>>> Should we not print directives/flags which are not set explicitly? >>>> >>>> I updated the print output to mark all options in the directive that are >>>> not default with a '*'. That makes it quicker to see if any special >>>> options was applied. It will also print if the directive is the >>>> unmodified default directive. >>>> >>>> Webrev: http://cr.openjdk.java.net/~neliasso/8138756/webrev.03/ >>>> Example output: >>>> http://cr.openjdk.java.net/~neliasso/8138756/webrev.03/hserr.txt >>>> >>>> Regards, >>>> Nils >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/21/16 2:31 AM, Nils Eliasson wrote: >>>>>> This is how it looks: >>>>>> >>>>>> [...] >>>>>> >>>>>> --------------- T H R E A D --------------- >>>>>> >>>>>> Current thread (0x00007f071046a000): JavaThread "C1 >>>>>> CompilerThread10" daemon [_thread_in_native, id=20033, >>>>>> stack(0x00007f05d7afb000,0x00007f05d7bfc000)] >>>>>> >>>>>> Current CompileTask: >>>>>> C1: 225 1 3 java.lang.String::isLatin1 (19 bytes) >>>>>> >>>>>> Current compiler directive: >>>>>> inline: - >>>>>> Enable:true Exclude:false BreakAtExecute:false >>>>>> BreakAtCompile:false Log:false PrintAssembly:false >>>>>> PrintInlining:false PrintNMethods:false ReplayInline:false >>>>>> DumpReplay:false DumpInline:false >>>>>> CompilerDirectivesIgnoreCompileCommands:false DisableIntrinsic: >>>>>> BlockLayoutByFrequency:true PrintOptoAssembly:false >>>>>> PrintIntrinsics:false TraceOptoPipelining:false TraceOptoOutput:false >>>>>> TraceSpilling:false Vectorize:false VectorizeDebug:false >>>>>> CloneMapDebug:false DoReserveCopyInSuperWordDebug:false >>>>>> IGVPrintLevel:0 MaxNodeLimit:80000 >>>>>> >>>>>> Stack: [0x00007f05d7afb000,0x00007f05d7bfc000], >>>>>> sp=0x00007f05d7bfa5d0, free space=1021k >>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>>> C=native code) >>>>>> V [libjvm.so+0x12e7532] VMError::report_and_die(int, char const*, >>>>>> char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, >>>>>> char const*, int, unsigned long)+0x182 >>>>>> V [libjvm.so+0x12e829a] VMError::report_and_die(Thread*, char >>>>>> const*, int, char const*, char const*, __va_list_tag*)+0x4a >>>>>> V [libjvm.so+0x908cca] report_vm_error(char const*, int, char >>>>>> const*, char const*, ...)+0xea >>>>>> V [libjvm.so+0x88df81] CompileBroker::post_compile(CompilerThread*, >>>>>> CompileTask*, EventCompilation&, bool, ciEnv*)+0x1b1 >>>>>> V [libjvm.so+0x88ec5a] >>>>>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x90a >>>>>> V [libjvm.so+0x88f960] CompileBroker::compiler_thread_loop()+0x540 >>>>>> V [libjvm.so+0x1264789] JavaThread::thread_main_inner()+0x1c9 >>>>>> V [libjvm.so+0x1264ac6] JavaThread::run()+0x2a6 >>>>>> V [libjvm.so+0x10189aa] java_start(Thread*)+0xca >>>>>> C [libpthread.so.0+0x8182] start_thread+0xc2 >>>>>> >>>>>> [...] >>>>>> >>>>>> http://cr.openjdk.java.net/~neliasso/8138756/hserr.txt >>>>>> >>>>>> Regards, >>>>>> Nils >>>>>> >>>>>> On 2016-01-21 11:25, Nils Eliasson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this small change. The diff looks big but most of the >>>>>>> change is just changing how the directive are >>>>>>> passed to the compilers. Directives are set in the ciEnv and then >>>>>>> passed to the compilers. The compilers can then >>>>>>> choose to add it to any internal compilation object for convenience. >>>>>>> The hs_err printing routine in vmError.cpp loads >>>>>>> the directive from the ciEnv. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138756 >>>>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8138756/webrev.01/ >>>>>>> >>>>>>> Regards, >>>>>>> Nils >>>>>> >>>> >> From ivan at azulsystems.com Wed Feb 10 23:47:00 2016 From: ivan at azulsystems.com (Ivan Krylov) Date: Thu, 11 Feb 2016 02:47:00 +0300 Subject: RFR(S): 8147844: new method j.l.Runtime.onSpinWait() and the corresponding x86 hotspot instrinsic In-Reply-To: References: <56A751AE.9090203@azulsystems.com> <45B4730C-CCC2-4523-ACD1-D18B20E5EC5F@oracle.com> <56A8BC9D.8060004@azulsystems.com> <6148E4D7-AF5E-4094-B363-52E0D83452E9@oracle.com> <56AA2AE4.2090803@azulsystems.com> <2538083C-7906-44AA-A074-7DBF5F2D8654@oracle.com> <50C14C66-4068-4DD7-BD94-96E37F7C9B0A@oracle.com> <56AF85F3.3060802@azulsystems.com> Message-ID: <56BBCBF4.2070504@azulsystems.com> I have prepared a new webrev: http://cr.openjdk.java.net/~ikrylov/8147844.hs.02/ Hopefully it addresses the comments that were said before. Per Vladimir's suggestion I added the c1 intrinsic. I could not test non-x86 platforms but hopefully nothing is broken there. Thanks, Ivan From christian.thalinger at oracle.com Thu Feb 11 00:34:17 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 10 Feb 2016 14:34:17 -1000 Subject: RFR (M): 8149415: [AArch64] implement JVMCI CodeInstaller In-Reply-To: References: <24D1E72C-5F70-4073-8EC2-9E291093DC29@oracle.com> <56BB8773.30103@oracle.com> Message-ID: Damn. A last-minute change broke the build: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/diff/b038c3bea5a4/src/cpu/aarch64/vm/jvmciCodeInstaller_aarch64.cpp#l1.61 But since JPRT doesn?t build open AArch64 we didn?t catch it. Maybe we should pass the thread to CodeInstaller::pd_patch_DataSectionReference as well to have the option to throw an exception. I will send a review tomorrow. Sorry for the inconvenience. > On Feb 10, 2016, at 9:58 AM, Christian Thalinger wrote: > > >> On Feb 10, 2016, at 8:54 AM, Vladimir Kozlov wrote: >> >> Why you need #ifdef _LP64 in jvmciCodeInstaller_aarch64.cpp? It is only 64 bit VM. > > Haha, yeah, good point. Copy-paste :-) I?ll remove it. > >> Otherwise looks good. >> >> Thanks, >> Vladimir >> >> On 2/9/16 2:39 PM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8149415 >>> http://cr.openjdk.java.net/~twisti/8149415/webrev.01/ >>> >>> This is a first cut of the CodeInstaller implementation for AArch64. One missing part is compressed oops support but >>> it?s not a big issue because Graal doesn?t support it yet either. >>> >>> The patch also includes changes to AMD64 and SPARC?s RegisterConfig to use an array for the reserved registers. The >>> code before was too hard to understand. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Feb 11 06:04:43 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Feb 2016 22:04:43 -0800 Subject: CR for RFR 8149421 In-Reply-To: References: Message-ID: <56BC247B.7070409@oracle.com> What are the changes in assembler_x86.cpp? You changed no_mask_reg arguments value. Was it bug? Looks like you copy-paste code from insert_pre_post_loops() which is fine. One thing is worry me is that due to ratio of unrolling done before vectorization and vector size you can have several repetitive vector operations. It would be nice if we do unrolling equal vector size then do vectorization to generate one vector instruction, then clone to create vector_post_loop. And then unroll main more. Or you are already doing something like that? Thanks, Vladimir On 2/9/16 3:16 PM, Berg, Michael C wrote: > Hi Folks, > > I would like to contribute vectorized post loops. This patch is initially targeted for x86. The design is versatile so > as to be portable to other targets as well. This code poses the addition of atomic unrolled drain loops which precede > fix-up segments and which are significantly faster than scalar code. The requirement is that the main loop is super > unrolled after vectorization. I see up to 54% uplift on micro benchmarks on x86 targets for loops which pass superword > vectorization and which meet the above criteria. Also scimark metrics in SpecJvm2008 like lu.small and fft.small show > the usage of this design for benefit on x86. > > Bug-id: https://bugs.openjdk.java.net/browse/JDK-8149421 > > > webrev: > > http://cr.openjdk.java.net/~mcberg/8149421/webrev.01/ > > Thanks, > > Michael > From konstantin.shefov at oracle.com Thu Feb 11 06:41:10 2016 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 11 Feb 2016 09:41:10 +0300 Subject: [9] RFR 8149472: NPE when executing HotSpotConstantReflectionProvider::constantEquals with null first arg In-Reply-To: References: <56BB1CE1.8060301@oracle.com> Message-ID: <56BC2D06.7000905@oracle.com> Doug, Christian, Vladimir, thank you for reviewing. Here is a patch with space: http://cr.openjdk.java.net/~kshefov/8149472/webrev.01/ -Konstantin 10.02.2016 23:02, Christian Thalinger ?????: > + return Objects.equals(x,y); > > There is a missing space. Are you using an IDE? > >> On Feb 10, 2016, at 1:20 AM, Konstantin Shefov >> > >> wrote: >> >> Hello >> >> Please review a bug fix in JVMCI >> jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider::constantEquals(Constant >> x, Constant y) method. >> >> A NullPointerException is thrown, when one calls this method with the >> first argument x equal to null. >> >> Additional check should be added for null as the first argument. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149472 >> Webrev: http://cr.openjdk.java.net/~kshefov/8149472/webrev.00/ >> >> Thanks >> -Konstantin >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Thu Feb 11 06:51:33 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 10 Feb 2016 22:51:33 -0800 Subject: RFR(S): 8147844: new method j.l.Runtime.onSpinWait() and the corresponding x86 hotspot instrinsic In-Reply-To: <56BBCBF4.2070504@azulsystems.com> References: <56A751AE.9090203@azulsystems.com> <45B4730C-CCC2-4523-ACD1-D18B20E5EC5F@oracle.com> <56A8BC9D.8060004@azulsystems.com> <6148E4D7-AF5E-4094-B363-52E0D83452E9@oracle.com> <56AA2AE4.2090803@azulsystems.com> <2538083C-7906-44AA-A074-7DBF5F2D8654@oracle.com> <50C14C66-4068-4DD7-BD94-96E37F7C9B0A@oracle.com> <56AF85F3.3060802@azulsystems.com> <56BBCBF4.2070504@azulsystems.com> Message-ID: The C2 part looks good to me. Thanks for making the changes. As for C1? 1. There is already an HIR node to model intrinsics (?Intrinsic?), so unless there is a compelling reason to introduce a new node type I would just use that. That should get rid of many changes to HIR visitors, etc. Follow the existing examples, look for example at how vmIntrinsics::_fullFence works, your case should be the same. 2. It?d be nice to minimize the platform specific changes. There is Compiler::is_intrinsic_supported() method that determines if something should be intensified. Follow the existing examples and add ?static bool supports_spin_wait() { return false; }" to Abstract_VM_Version, overload it to true in the VM_Version for x86, then use it to determine whether to intensify the call. You?ll still need a LIR instruction and the LIR_Assembler::on_spin_wait() method, but you can define it on on x86 only. It?s ok to not define a method if you don?t use it, and you won?t, because the intrinsic will be used only on x86. igor > On Feb 10, 2016, at 3:47 PM, Ivan Krylov wrote: > > I have prepared a new webrev: > http://cr.openjdk.java.net/~ikrylov/8147844.hs.02/ > > Hopefully it addresses the comments that were said before. > Per Vladimir's suggestion I added the c1 intrinsic. > I could not test non-x86 platforms but hopefully nothing is broken there. > > Thanks, > > Ivan From rahul.v.raghavan at oracle.com Thu Feb 11 07:42:01 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 10 Feb 2016 23:42:01 -0800 (PST) Subject: RFR(XXS): 8149488: Incorrect declaration of bitsInByte in regmask.cpp Message-ID: <47822ba0-6ecd-4f69-9eaf-e7afd3402bcf@default> Hi, Please review the patch for JDK- 8149488. Bug: https://bugs.openjdk.java.net/browse/JDK-8149488 Webrev: http://cr.openjdk.java.net/~thartmann/8149488/webrev.00/ Corrected the bitsInByte array size in declaration. Thanks, Rahul From rahul.v.raghavan at oracle.com Thu Feb 11 07:49:05 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 10 Feb 2016 23:49:05 -0800 (PST) Subject: RFR(S): 6378256: Performance problem with System.identityHashCode in client compiler In-Reply-To: <7B6F2230-90B3-4BF2-8EBA-CF4B58FCE5BB@oracle.com> References: <7B6F2230-90B3-4BF2-8EBA-CF4B58FCE5BB@oracle.com> Message-ID: <8cecd05b-37b5-4cc7-b3f1-d8fa7ca027a8@default> Hi, Thank you Roland for the comments and yes agree with your points. Please review revised webrev for JDK-6378256. webrev: http://cr.openjdk.java.net/~thartmann/6378256/webrev.04/ New changes done here are - i. added new inline_check_hashcode_from_object_header() in SharedRuntime class [sharedRuntime.hpp] guarded with 'X86 && COMPILER1' ii. required comment text justification done. Confirmed no issues with jprt testing (-testset hotspot) and unit tests. Thank you, Rahul > -----Original Message----- > From: Roland Westrelin > Sent: Monday, February 08, 2016 11:00 PM > To: Rahul Raghavan > Cc: hotspot-compiler-dev at openjdk.java.net > > Hi Rahul, > > > Please review revised patch, notes for JDK-6378256. > > https://bugs.openjdk.java.net/browse/JDK-6378256 > > > > > > Latest webrev-03: http://cr.openjdk.java.net/~thartmann/6378256/webrev.03/ > > Thanks for making the change. I would say it?s better to add inline_check_hashcode_from_object_header() to sharedRuntime.hpp > with #ifdef X86 rather than have the inline declaration. Not sure what others think. > > >>> Can you justify the comments again? > > I meant justify as text justification that is right align that comment: > > 36 // --------------------------------------------------------------------------- > 37 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word > 38 // instead of doing a full VM transition once it's been computed. > 39 // Since hashCode is usually polymorphic at call sites we can't do > 40 // this optimization at the call site without a lot of work. > > and that comment > > 2019 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word > 2020 // instead of doing a full VM transition once it's been computed. > 2021 // Since hashCode is usually polymorphic at call sites we can't do > 2022 // this optimization at the call site without a lot of work. > > Sorry for the confusion. The code looks good to me/ > > Roland. > > From tobias.hartmann at oracle.com Thu Feb 11 07:53:15 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Feb 2016 08:53:15 +0100 Subject: RFR(XXS): 8149488: Incorrect declaration of bitsInByte in regmask.cpp In-Reply-To: <47822ba0-6ecd-4f69-9eaf-e7afd3402bcf@default> References: <47822ba0-6ecd-4f69-9eaf-e7afd3402bcf@default> Message-ID: <56BC3DEB.1020105@oracle.com> Hi Rahul, looks good to me. Best, Tobias On 11.02.2016 08:42, Rahul Raghavan wrote: > Hi, > > Please review the patch for JDK- 8149488. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149488 > Webrev: http://cr.openjdk.java.net/~thartmann/8149488/webrev.00/ > > Corrected the bitsInByte array size in declaration. > > Thanks, > Rahul > From rahul.v.raghavan at oracle.com Thu Feb 11 07:56:19 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 10 Feb 2016 23:56:19 -0800 (PST) Subject: RFR(XXS): 8149488: Incorrect declaration of bitsInByte in regmask.cpp In-Reply-To: <56BC3DEB.1020105@oracle.com> References: <47822ba0-6ecd-4f69-9eaf-e7afd3402bcf@default> <56BC3DEB.1020105@oracle.com> Message-ID: <4345a01b-5cf6-477a-aec8-3239679a3a38@default> > -----Original Message----- > From: Tobias Hartmann > Sent: Thursday, February 11, 2016 1:23 PM > To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net > > Hi Rahul, > > looks good to me. Thank you Tobias. > > Best, > Tobias > > On 11.02.2016 08:42, Rahul Raghavan wrote: > > Hi, > > > > Please review the patch for JDK- 8149488. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149488 > > Webrev: http://cr.openjdk.java.net/~thartmann/8149488/webrev.00/ > > > > Corrected the bitsInByte array size in declaration. > > > > Thanks, > > Rahul > > From rahul.v.raghavan at oracle.com Thu Feb 11 08:15:53 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 11 Feb 2016 00:15:53 -0800 (PST) Subject: RFR (XXS): 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 In-Reply-To: <56BB769B.8080105@oracle.com> References: <27266fb9-dca7-4285-88df-b36f8a650a53@default> <56BB769B.8080105@oracle.com> Message-ID: <1941e443-4aee-43ed-89e1-8cf68d793a81@default> > -----Original Message----- > From: Vladimir Kozlov > Sent: Wednesday, February 10, 2016 11:13 PM > To: hotspot-compiler-dev at openjdk.java.net > > Looks good. Thank you Vladimir Kozlov. > > Thanks, > Vladimir > > On 2/10/16 4:40 AM, Rahul Raghavan wrote: > > Hi, > > > > Please review following patch proposal to avoid 'possible uninitialised variable' warnings for internal tests. > > > > webrev: http://cr.openjdk.java.net/~thartmann/8145700/webrev.00/ > > > > Confirmed no issues with jprt run (-testset hotspot). > > > > Thanks, > > Rahul > > From rahul.v.raghavan at oracle.com Thu Feb 11 08:16:36 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 11 Feb 2016 00:16:36 -0800 (PST) Subject: RFR (XXS): 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 In-Reply-To: References: <27266fb9-dca7-4285-88df-b36f8a650a53@default> Message-ID: <566ecc0b-c057-4856-8479-cc49355d1477@default> > -----Original Message----- > From: Berg, Michael C [mailto:michael.c.berg at intel.com] > Sent: Wednesday, February 10, 2016 11:55 PM > To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net > > Looks good. Thank you Michael. > > -Michael > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Rahul Raghavan > Sent: Wednesday, February 10, 2016 4:40 AM > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR (XXS): 8145700: Uninitialised variable in macroAssembler_x86.cpp:7038 > > Hi, > > Please review following patch proposal to avoid 'possible uninitialised variable' warnings for internal tests. > > webrev: http://cr.openjdk.java.net/~thartmann/8145700/webrev.00/ > > Confirmed no issues with jprt run (-testset hotspot). > > Thanks, > Rahul From roland.westrelin at oracle.com Thu Feb 11 12:46:10 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 11 Feb 2016 13:46:10 +0100 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> Message-ID: The jvmci push added a binary search method to growableArray so I updated my patch to make use of that method. I also cleaned up the code a bit and fixed an overflow issue in the binary search code: http://cr.openjdk.java.net/~roland/8007986/webrev.02/ Roland. From vladimir.x.ivanov at oracle.com Thu Feb 11 12:48:52 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Feb 2016 15:48:52 +0300 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> Message-ID: <56BC8334.90906@oracle.com> Thumbs up! Reviewed. Best regards, Vladimir Ivanov On 2/11/16 3:46 PM, Roland Westrelin wrote: > The jvmci push added a binary search method to growableArray so I updated my patch to make use of that method. I also cleaned up the code a bit and fixed an overflow issue in the binary search code: > > http://cr.openjdk.java.net/~roland/8007986/webrev.02/ > > Roland. > From vladimir.x.ivanov at oracle.com Thu Feb 11 12:53:48 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Feb 2016 15:53:48 +0300 Subject: RFR(XXS): 8149488: Incorrect declaration of bitsInByte in regmask.cpp In-Reply-To: <47822ba0-6ecd-4f69-9eaf-e7afd3402bcf@default> References: <47822ba0-6ecd-4f69-9eaf-e7afd3402bcf@default> Message-ID: <56BC845C.5070401@oracle.com> Rahul, Can we define a constant instead and use it in both places? Best regards, Vladimir Ivanov On 2/11/16 10:42 AM, Rahul Raghavan wrote: > Hi, > > Please review the patch for JDK- 8149488. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149488 > Webrev: http://cr.openjdk.java.net/~thartmann/8149488/webrev.00/ > > Corrected the bitsInByte array size in declaration. > > Thanks, > Rahul > From vitalyd at gmail.com Thu Feb 11 13:09:19 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 11 Feb 2016 08:09:19 -0500 Subject: RFR(S): 8143542: C2 doesn't eliminate identical checks In-Reply-To: <87A6AE42-5325-4CE7-9A7F-B0E9EAAE29D8@oracle.com> References: <87A6AE42-5325-4CE7-9A7F-B0E9EAAE29D8@oracle.com> Message-ID: Thanks Roland! :) On Wednesday, February 3, 2016, Roland Westrelin < roland.westrelin at oracle.com> wrote: > http://cr.openjdk.java.net/~roland/8143542/webrev.00/ > > The test case: > > > https://bugs.openjdk.java.net/secure/attachment/55176/RedundantNullCheck.java > > has two identical tests one after the other: > > int ret = 0; > if (_i != null) { > ret += _i.value(); > } else { > ret += -1; > } > if (_i != null) { > ret += _i.value2(); > } else { > ret += -1; > } > > They can be merged. I picky backed on the split if code to achieve that. > Both inlined calls have a null check and a range check. For them to fold > nicely after the ifs are merged, ConstraintCastNode::dominating_cast() > needs to more aggressively look for redundant casts. > > Roland. -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Thu Feb 11 13:10:21 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Feb 2016 14:10:21 +0100 Subject: RFR (M): 8149415: [AArch64] implement JVMCI CodeInstaller In-Reply-To: References: <24D1E72C-5F70-4073-8EC2-9E291093DC29@oracle.com> <56BB8773.30103@oracle.com> Message-ID: <56BC883D.5070009@oracle.com> On 11.02.2016 01:34, Christian Thalinger wrote: > Damn. A last-minute change broke the build: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/diff/b038c3bea5a4/src/cpu/aarch64/vm/jvmciCodeInstaller_aarch64.cpp#l1.61 > > But since JPRT doesn?t build open AArch64 we didn?t catch it. Maybe we should pass the thread to CodeInstaller::pd_patch_DataSectionReference as well to have the option to throw an exception. I will send a review tomorrow. Sorry for the inconvenience. Okay, I'll not push this to main then. Best, Tobias > >> On Feb 10, 2016, at 9:58 AM, Christian Thalinger > wrote: >> >> >>> On Feb 10, 2016, at 8:54 AM, Vladimir Kozlov > wrote: >>> >>> Why you need #ifdef _LP64 in jvmciCodeInstaller_aarch64.cpp? It is only 64 bit VM. >> >> Haha, yeah, good point. Copy-paste :-) I?ll remove it. >> >>> Otherwise looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 2/9/16 2:39 PM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8149415 >>>> http://cr.openjdk.java.net/~twisti/8149415/webrev.01/ >>>> >>>> This is a first cut of the CodeInstaller implementation for AArch64. One missing part is compressed oops support but >>>> it?s not a big issue because Graal doesn?t support it yet either. >>>> >>>> The patch also includes changes to AMD64 and SPARC?s RegisterConfig to use an array for the reserved registers. The >>>> code before was too hard to understand. >>>> >> > From jamsheed.c.m at oracle.com Thu Feb 11 13:47:08 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 11 Feb 2016 19:17:08 +0530 Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash Message-ID: <56BC90DC.10004@oracle.com> Hi, Request for review bug url: https://bugs.openjdk.java.net/browse/JDK-8145333 web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ Fix Summary: added jvmci flag consistency check after arg parsing. tests: jprt unit test: command line verification Best Regards, Jamsheed From roland.westrelin at oracle.com Thu Feb 11 14:19:37 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 11 Feb 2016 15:19:37 +0100 Subject: RFR(S): 6378256: Performance problem with System.identityHashCode in client compiler In-Reply-To: <8cecd05b-37b5-4cc7-b3f1-d8fa7ca027a8@default> References: <7B6F2230-90B3-4BF2-8EBA-CF4B58FCE5BB@oracle.com> <8cecd05b-37b5-4cc7-b3f1-d8fa7ca027a8@default> Message-ID: <907A99AD-0BA9-469B-B8E6-D2253F95C068@oracle.com> Hi Rahul, > webrev: http://cr.openjdk.java.net/~thartmann/6378256/webrev.04/ Thanks for the updated webrev. It would be better if he declaration of inline_check_hashcode_from_object_header() is private. When it?s called: SharedRuntime::inline_check_hashcode_from_object_header() SharedRuntime:: is useless: inline_check_hashcode_from_object_header() is sufficient. Roland. > > New changes done here are - > i. added new inline_check_hashcode_from_object_header() in SharedRuntime class [sharedRuntime.hpp] guarded with 'X86 && COMPILER1' > ii. required comment text justification done. > > Confirmed no issues with jprt testing (-testset hotspot) and unit tests. > > Thank you, > Rahul > >> -----Original Message----- >> From: Roland Westrelin > Sent: Monday, February 08, 2016 11:00 PM > To: Rahul Raghavan > Cc: hotspot-compiler-dev at openjdk.java.net >> >> Hi Rahul, >> >>> Please review revised patch, notes for JDK-6378256. >>> https://bugs.openjdk.java.net/browse/JDK-6378256 >>> >>> >>> Latest webrev-03: http://cr.openjdk.java.net/~thartmann/6378256/webrev.03/ >> >> Thanks for making the change. I would say it?s better to add inline_check_hashcode_from_object_header() to sharedRuntime.hpp >> with #ifdef X86 rather than have the inline declaration. Not sure what others think. >> >>>>> Can you justify the comments again? >> >> I meant justify as text justification that is right align that comment: >> >> 36 // --------------------------------------------------------------------------- >> 37 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word >> 38 // instead of doing a full VM transition once it's been computed. >> 39 // Since hashCode is usually polymorphic at call sites we can't do >> 40 // this optimization at the call site without a lot of work. >> >> and that comment >> >> 2019 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word >> 2020 // instead of doing a full VM transition once it's been computed. >> 2021 // Since hashCode is usually polymorphic at call sites we can't do >> 2022 // this optimization at the call site without a lot of work. >> >> Sorry for the confusion. The code looks good to me/ >> >> Roland. >> >> From tobias.hartmann at oracle.com Thu Feb 11 14:29:01 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Feb 2016 15:29:01 +0100 Subject: [9] RFR(XS): 8148564: compiler/intrinsics/string/TestStringIntrinsics2.java times out Message-ID: <56BC9AAD.1020602@oracle.com> Hi, please review the following patch. https://bugs.openjdk.java.net/browse/JDK-8148564 http://cr.openjdk.java.net/~thartmann/8148564/webrev.00/ The test times out with a fastdebug build and -Xcomp after 356 seconds. The profile shows that most time is spent in C1: 40.06% java libjvm.so [.] RangeCheckEliminator::Verification::can_reach(BlockBegin*, BlockBegin*, BlockBeg 20.08% java libjvm.so [.] LinearScan::is_sorted(IntervalArray*) 4.47% java libc-2.19.so [.] memset LinearScan::is_sorted() is known to be very slow (JDK-8067014). It seems that RangeCheckEliminator::Verification::can_reach() also slows down performance significantly. Without these checks the runtime drops down to 126 seconds. The accumulated compiler times also show that most time is spent in C1 (see [1]): C1 Compile Time: 326.983 s C2 Compile Time: 3.241 s A product build is significantly faster, i.e. the slowdown is caused by additional C1 verification code in fastdebug builds: C1 Compile Time: 8.463 s C2 Compile Time: 1.619 s The problem is that the test specifies -XX:MaxInlineSize=100 to trigger inlining of intrinsics. With -Xcomp, this also causes many other methods to be inlined, blowing up the graphs and significantly slowing down compilation. Since the test uses the Whitebox API to trigger compilation, -Xcomp is not required. I verified that -XX:MaxInlineSize=70 is enough to inline all intrinsics and added -Xmixed to the test to avoid compilation of unrelated methods. Thanks, Tobias [1] https://bugs.openjdk.java.net/secure/attachment/57052/CITime.log From roland.westrelin at oracle.com Thu Feb 11 14:41:48 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 11 Feb 2016 15:41:48 +0100 Subject: RFR(S): 8146828: Subsequent arraycopy does not always eliminate array zeroing Message-ID: <86A6E1D0-F2CB-4A36-B6C8-77B12FDEF169@oracle.com> http://cr.openjdk.java.net/~roland/8146828/webrev.00/ The problem is that we add a null check for src when we intrinsify arraycopy. So there's a null check between the allocation and the arraycopy itself and if we hit that null check we deoptimize with a live allocation and that allocation must be zeroed. We usually move the allocation below the predicates and arrange for the predicates in case they fail to resume execution in the interpreter right before the allocation. But in that case one of the predicate fails on a first compilation (subtype check) so we don't attempt it on the second one. In the change, the check for too many traps of type Reason_intrinsic and too many traps of type Reason_null_check are done independently so if we already hit too many Reason_intrinsic traps we still can move the null check above the allocation and eliminate zeroing. Hopefully I didn?t break anything in that very confusing code. Roland. From martin.doerr at sap.com Thu Feb 11 15:11:20 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 11 Feb 2016 15:11:20 +0000 Subject: RFR(L) 8149655: PPC64: Implement CompactString intrinsics Message-ID: Hi, I have created a webrev which adds the following String intrinsics to PPC64: 0 string_compareL 1 string_compareU 2 string_compareLU 3 string_compareUL 4 string_equalsL 5 string_equalsU 6 array_equalsB 7 array_equalsC 8 indexOf_imm1_char_U 9 indexOf_imm1_char_L 10 indexOf_imm1_char_UL 11 indexOf_imm1_U 12 indexOf_imm1_L 13 indexOf_imm1_UL 14 indexOfChar_U 15 indexOf_imm_U 16 indexOf_imm_L 17 indexOf_imm_UL 18 indexOf_U 19 indexOf_L 20 indexOf_UL 21 string_compress 22 string_inflate 23 has_negatives 24 encode_iso_array It also contains some other minor improvements. The webrev is here: http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.00/ Please review. I will also need a sponsor from Oracle because the change touches one java test file (test/compiler/intrinsics/string/TestStringIntrinsics2.java). Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.c.berg at intel.com Thu Feb 11 17:55:12 2016 From: michael.c.berg at intel.com (Berg, Michael C) Date: Thu, 11 Feb 2016 17:55:12 +0000 Subject: CR for RFR 8149421 In-Reply-To: <56BC247B.7070409@oracle.com> References: <56BC247B.7070409@oracle.com> Message-ID: Yes, that is pretty close to it, the unrolled loop, after it initially succeeds as an atomic or unity unroll segment of one vector size is what I replicated to the drain loop, before super unrolling occurs. In fact, it's precisely what we need. I migrated the ss/sd to insns k1 usage for uniformity reasons. You will notice some b and w SIMD components going the other way, that is preparatory, not a bug yet, but could have been if left, to use k0 which has all bits set for masking in the auto code generation path. The only exception is stub code, for which a webrev will soon be made available which has programmable versions of w and b components that do not fit in the auto code generation path, and for which k1 contents are left to the responsibility of the stub writer. The others insns are set to false like movdqu are in preparation for programmable SIMD, which will need to apply programmed masks into fix-up segments. Since programmable SIMD is for int/float, long/double sizes only there will be no conflict. Basically the w and b components do not have enough ISA mapping to complete more than very basic vector expressions, so we confine the usage model by idiom wrt masking and exclude them from programmable SIMD. Regards, Michael -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, February 10, 2016 10:05 PM To: hotspot-compiler-dev at openjdk.java.net Cc: Berg, Michael C Subject: Re: CR for RFR 8149421 What are the changes in assembler_x86.cpp? You changed no_mask_reg arguments value. Was it bug? Looks like you copy-paste code from insert_pre_post_loops() which is fine. One thing is worry me is that due to ratio of unrolling done before vectorization and vector size you can have several repetitive vector operations. It would be nice if we do unrolling equal vector size then do vectorization to generate one vector instruction, then clone to create vector_post_loop. And then unroll main more. Or you are already doing something like that? Thanks, Vladimir On 2/9/16 3:16 PM, Berg, Michael C wrote: > Hi Folks, > > I would like to contribute vectorized post loops. This patch is > initially targeted for x86. The design is versatile so as to be > portable to other targets as well. This code poses the addition of > atomic unrolled drain loops which precede fix-up segments and which > are significantly faster than scalar code. The requirement is that the > main loop is super unrolled after vectorization. I see up to 54% uplift on micro benchmarks on x86 targets for loops which pass superword vectorization and which meet the above criteria. Also scimark metrics in SpecJvm2008 like lu.small and fft.small show the usage of this design for benefit on x86. > > Bug-id: https://bugs.openjdk.java.net/browse/JDK-8149421 > > > webrev: > > http://cr.openjdk.java.net/~mcberg/8149421/webrev.01/ > > Thanks, > > Michael > From christian.thalinger at oracle.com Thu Feb 11 17:56:09 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 11 Feb 2016 07:56:09 -1000 Subject: RFR (S): 8149689: [JVMCI] CodeInstaller::pd_patch_DataSectionReference should be able to throw exceptions Message-ID: <7393710C-778B-4D29-B8D6-EFA5D6AC979E@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8149689 http://cr.openjdk.java.net/~twisti/8149689/webrev.01/ All the other CodeInstaller::pd_patch_* methods can throw exceptions except this one. This fixes the AArch64 issue I introduced with 8149415. From christian.thalinger at oracle.com Thu Feb 11 18:01:16 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 11 Feb 2016 08:01:16 -1000 Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash In-Reply-To: <56BC90DC.10004@oracle.com> References: <56BC90DC.10004@oracle.com> Message-ID: > On Feb 11, 2016, at 3:47 AM, Jamsheed C m wrote: > > Hi, > > Request for review > > bug url: https://bugs.openjdk.java.net/browse/JDK-8145333 > web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ That looks alright but we should remove the constraints from all the JVMCI command line flags because the way we use them is not supported. Also, can you change the error message? Right now it looks like this: $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler EnableJVMCI must be enabled Improperly specified VM option 'UseJVMCICompiler' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. I think with your changes we will only see the first line without mentioning UseJVMCICompiler. Is that correct? > > Fix Summary: added jvmci flag consistency check after arg parsing. > > tests: jprt > unit test: command line verification > > Best Regards, > Jamsheed -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.c.berg at intel.com Thu Feb 11 18:02:06 2016 From: michael.c.berg at intel.com (Berg, Michael C) Date: Thu, 11 Feb 2016 18:02:06 +0000 Subject: FW: RFR(XXS): 8149488: Incorrect declaration of bitsInByte in regmask.cpp References: <47822ba0-6ecd-4f69-9eaf-e7afd3402bcf@default> <56BC845C.5070401@oracle.com> Message-ID: Should we not extend: This does not match the actual definition in share/vm/libadt/vectset.cpp: uint8_t bitsInByte[256] = { // ... to 512 -----Original Message----- From: Berg, Michael C Sent: Thursday, February 11, 2016 9:57 AM To: 'Vladimir Ivanov' Subject: RE: RFR(XXS): 8149488: Incorrect declaration of bitsInByte in regmask.cpp So how do we intend to map a VecZ register without 512 bits? -Michael -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Ivanov Sent: Thursday, February 11, 2016 4:54 AM To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(XXS): 8149488: Incorrect declaration of bitsInByte in regmask.cpp Rahul, Can we define a constant instead and use it in both places? Best regards, Vladimir Ivanov On 2/11/16 10:42 AM, Rahul Raghavan wrote: > Hi, > > Please review the patch for JDK- 8149488. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149488 > Webrev: http://cr.openjdk.java.net/~thartmann/8149488/webrev.00/ > > Corrected the bitsInByte array size in declaration. > > Thanks, > Rahul > From vladimir.kozlov at oracle.com Thu Feb 11 18:08:42 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 10:08:42 -0800 Subject: CR for RFR 8149421 In-Reply-To: References: <56BC247B.7070409@oracle.com> Message-ID: <56BCCE2A.2010206@oracle.com> On 2/11/16 9:55 AM, Berg, Michael C wrote: > Yes, that is pretty close to it, the unrolled loop, after it initially succeeds as an atomic or unity unroll segment of one vector size is what I replicated to the drain loop, before super unrolling occurs. In fact, it's precisely what we need. Will you do more to improve it? > I migrated the ss/sd to insns k1 usage for uniformity reasons. You will notice some b and w SIMD components going the other way, that is preparatory, not a bug yet, but could have been if left, to use k0 which has all bits set for masking in the auto code generation path. The only exception is stub code, for which a webrev will soon be made available which has programmable versions of w and b components that do not fit in the auto code generation path, and for which k1 contents are left to the responsibility of the stub writer. The others insns are set to false like movdqu are in preparation for programmable SIMD, which will need to apply programmed masks into fix-up segments. Since programmable SIMD is for int/float, long/double sizes only there will be no conflict. Basically the w and b components do not have enough ISA mapping to complete more than very basic vector expressions, so we confine the usage model by idiom wrt masking and exclude them from programmable SIMD. Please, add comments about this in InstructionAttr. And add comments to all fields of InstructionAttr - shortly describe them. It will help us in a future to set correct values. I may need to be educated about "programmable SIMD" :) Thanks, Vladimir > > Regards, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, February 10, 2016 10:05 PM > To: hotspot-compiler-dev at openjdk.java.net > Cc: Berg, Michael C > Subject: Re: CR for RFR 8149421 > > What are the changes in assembler_x86.cpp? You changed no_mask_reg arguments value. Was it bug? > > Looks like you copy-paste code from insert_pre_post_loops() which is fine. > One thing is worry me is that due to ratio of unrolling done before vectorization and vector size you can have several repetitive vector operations. It would be nice if we do unrolling equal vector size then do vectorization to generate one vector instruction, then clone to create vector_post_loop. And then unroll main more. > Or you are already doing something like that? > > Thanks, > Vladimir > > On 2/9/16 3:16 PM, Berg, Michael C wrote: >> Hi Folks, >> >> I would like to contribute vectorized post loops. This patch is >> initially targeted for x86. The design is versatile so as to be >> portable to other targets as well. This code poses the addition of >> atomic unrolled drain loops which precede fix-up segments and which >> are significantly faster than scalar code. The requirement is that the >> main loop is super unrolled after vectorization. I see up to 54% uplift on micro benchmarks on x86 targets for loops which pass superword vectorization and which meet the above criteria. Also scimark metrics in SpecJvm2008 like lu.small and fft.small show the usage of this design for benefit on x86. >> >> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8149421 >> >> >> webrev: >> >> http://cr.openjdk.java.net/~mcberg/8149421/webrev.01/ >> >> Thanks, >> >> Michael >> From michael.c.berg at intel.com Thu Feb 11 18:36:25 2016 From: michael.c.berg at intel.com (Berg, Michael C) Date: Thu, 11 Feb 2016 18:36:25 +0000 Subject: CR for RFR 8149421 In-Reply-To: <56BCCE2A.2010206@oracle.com> References: <56BC247B.7070409@oracle.com> <56BCCE2A.2010206@oracle.com> Message-ID: Vladimir, how about this (from x86_assembler.hpp): InstructionAttr( int vector_len, // The length of vector to be applied in encoding - for both AVX and EVEX bool rex_vex_w, // Width of data: if 32-bits or less, false, else if 64-bit or specially defined, true bool legacy_mode, // Details if either this instruction is conditionally encoded to AVX or earlier if true else possibly EVEX bool no_reg_mask, // when true, k0 is used when EVEX encoding is chosen, else k1 is used under the same condition bool uses_vl) // This instruction may have legacy constraints based on vector length for EVEX For documentation? Thanks, Michael -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, February 11, 2016 10:09 AM To: Berg, Michael C; hotspot-compiler-dev at openjdk.java.net Subject: Re: CR for RFR 8149421 On 2/11/16 9:55 AM, Berg, Michael C wrote: > Yes, that is pretty close to it, the unrolled loop, after it initially succeeds as an atomic or unity unroll segment of one vector size is what I replicated to the drain loop, before super unrolling occurs. In fact, it's precisely what we need. Will you do more to improve it? > I migrated the ss/sd to insns k1 usage for uniformity reasons. You will notice some b and w SIMD components going the other way, that is preparatory, not a bug yet, but could have been if left, to use k0 which has all bits set for masking in the auto code generation path. The only exception is stub code, for which a webrev will soon be made available which has programmable versions of w and b components that do not fit in the auto code generation path, and for which k1 contents are left to the responsibility of the stub writer. The others insns are set to false like movdqu are in preparation for programmable SIMD, which will need to apply programmed masks into fix-up segments. Since programmable SIMD is for int/float, long/double sizes only there will be no conflict. Basically the w and b components do not have enough ISA mapping to complete more than very basic vector expressions, so we confine the usage model by idiom wrt masking and exclude them from programmable SIMD. Please, add comments about this in InstructionAttr. And add comments to all fields of InstructionAttr - shortly describe them. It will help us in a future to set correct values. I may need to be educated about "programmable SIMD" :) Thanks, Vladimir > > Regards, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, February 10, 2016 10:05 PM > To: hotspot-compiler-dev at openjdk.java.net > Cc: Berg, Michael C > Subject: Re: CR for RFR 8149421 > > What are the changes in assembler_x86.cpp? You changed no_mask_reg arguments value. Was it bug? > > Looks like you copy-paste code from insert_pre_post_loops() which is fine. > One thing is worry me is that due to ratio of unrolling done before vectorization and vector size you can have several repetitive vector operations. It would be nice if we do unrolling equal vector size then do vectorization to generate one vector instruction, then clone to create vector_post_loop. And then unroll main more. > Or you are already doing something like that? > > Thanks, > Vladimir > > On 2/9/16 3:16 PM, Berg, Michael C wrote: >> Hi Folks, >> >> I would like to contribute vectorized post loops. This patch is >> initially targeted for x86. The design is versatile so as to be >> portable to other targets as well. This code poses the addition of >> atomic unrolled drain loops which precede fix-up segments and which >> are significantly faster than scalar code. The requirement is that >> the main loop is super unrolled after vectorization. I see up to 54% uplift on micro benchmarks on x86 targets for loops which pass superword vectorization and which meet the above criteria. Also scimark metrics in SpecJvm2008 like lu.small and fft.small show the usage of this design for benefit on x86. >> >> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8149421 >> >> >> webrev: >> >> http://cr.openjdk.java.net/~mcberg/8149421/webrev.01/ >> >> Thanks, >> >> Michael >> From jamsheed.c.m at oracle.com Thu Feb 11 18:44:07 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 12 Feb 2016 00:14:07 +0530 Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash In-Reply-To: References: <56BC90DC.10004@oracle.com> Message-ID: <56BCD677.3070501@oracle.com> On 2/11/2016 11:31 PM, Christian Thalinger wrote: > >> On Feb 11, 2016, at 3:47 AM, Jamsheed C m > > wrote: >> >> Hi, >> >> Request for review >> >> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333 >> web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ >> > > That looks alright but we should remove the constraints from all the > JVMCI command line flags because the way we use them is not supported. Ok. > > Also, can you change the error message? Right now it looks like this: > > $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java > -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler > EnableJVMCI must be enabled > Improperly specified VM option 'UseJVMCICompiler' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > I think with your changes we will only see the first line without > mentioning UseJVMCICompiler. Is that correct? Yes, i will add second line to the error message. Best Regards, Jamsheed >> >> Fix Summary: added jvmci flag consistency check after arg parsing. >> >> tests: jprt >> unit test: command line verification >> >> Best Regards, >> Jamsheed > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Feb 11 19:25:31 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 11:25:31 -0800 Subject: CR for RFR 8149421 In-Reply-To: References: <56BC247B.7070409@oracle.com> <56BCCE2A.2010206@oracle.com> Message-ID: <56BCE02B.3070207@oracle.com> yes, this is good Thanks, Vladimir On 2/11/16 10:36 AM, Berg, Michael C wrote: > Vladimir, how about this (from x86_assembler.hpp): > > InstructionAttr( > int vector_len, // The length of vector to be applied in encoding - for both AVX and EVEX > bool rex_vex_w, // Width of data: if 32-bits or less, false, else if 64-bit or specially defined, true > bool legacy_mode, // Details if either this instruction is conditionally encoded to AVX or earlier if true else possibly EVEX > bool no_reg_mask, // when true, k0 is used when EVEX encoding is chosen, else k1 is used under the same condition > bool uses_vl) // This instruction may have legacy constraints based on vector length for EVEX > > For documentation? > > Thanks, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, February 11, 2016 10:09 AM > To: Berg, Michael C; hotspot-compiler-dev at openjdk.java.net > Subject: Re: CR for RFR 8149421 > > On 2/11/16 9:55 AM, Berg, Michael C wrote: >> Yes, that is pretty close to it, the unrolled loop, after it initially succeeds as an atomic or unity unroll segment of one vector size is what I replicated to the drain loop, before super unrolling occurs. In fact, it's precisely what we need. > > Will you do more to improve it? > >> I migrated the ss/sd to insns k1 usage for uniformity reasons. You will notice some b and w SIMD components going the other way, that is preparatory, not a bug yet, but could have been if left, to use k0 which has all bits set for masking in the auto code generation path. The only exception is stub code, for which a webrev will soon be made available which has programmable versions of w and b components that do not fit in the auto code generation path, and for which k1 contents are left to the responsibility of the stub writer. The others insns are set to false like movdqu are in preparation for programmable SIMD, which will need to apply programmed masks into fix-up segments. Since programmable SIMD is for int/float, long/double sizes only there will be no conflict. Basically the w and b components do not have enough ISA mapping to complete more than very basic vector expressions, so we confine the usage model by idiom wrt masking and exclude them from programmable SIM! D. > > Please, add comments about this in InstructionAttr. And add comments to all fields of InstructionAttr - shortly describe them. It will help us in a future to set correct values. > > I may need to be educated about "programmable SIMD" :) > > Thanks, > Vladimir > >> >> Regards, >> Michael >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, February 10, 2016 10:05 PM >> To: hotspot-compiler-dev at openjdk.java.net >> Cc: Berg, Michael C >> Subject: Re: CR for RFR 8149421 >> >> What are the changes in assembler_x86.cpp? You changed no_mask_reg arguments value. Was it bug? >> >> Looks like you copy-paste code from insert_pre_post_loops() which is fine. >> One thing is worry me is that due to ratio of unrolling done before vectorization and vector size you can have several repetitive vector operations. It would be nice if we do unrolling equal vector size then do vectorization to generate one vector instruction, then clone to create vector_post_loop. And then unroll main more. >> Or you are already doing something like that? >> >> Thanks, >> Vladimir >> >> On 2/9/16 3:16 PM, Berg, Michael C wrote: >>> Hi Folks, >>> >>> I would like to contribute vectorized post loops. This patch is >>> initially targeted for x86. The design is versatile so as to be >>> portable to other targets as well. This code poses the addition of >>> atomic unrolled drain loops which precede fix-up segments and which >>> are significantly faster than scalar code. The requirement is that >>> the main loop is super unrolled after vectorization. I see up to 54% uplift on micro benchmarks on x86 targets for loops which pass superword vectorization and which meet the above criteria. Also scimark metrics in SpecJvm2008 like lu.small and fft.small show the usage of this design for benefit on x86. >>> >>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8149421 >>> >>> >>> webrev: >>> >>> http://cr.openjdk.java.net/~mcberg/8149421/webrev.01/ >>> >>> Thanks, >>> >>> Michael >>> From christian.thalinger at oracle.com Thu Feb 11 19:52:24 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 11 Feb 2016 09:52:24 -1000 Subject: [9] RFR 8149472: NPE when executing HotSpotConstantReflectionProvider::constantEquals with null first arg In-Reply-To: <56BC2D06.7000905@oracle.com> References: <56BB1CE1.8060301@oracle.com> <56BC2D06.7000905@oracle.com> Message-ID: <6CDA7749-2B3E-4047-9DCC-6728A2FC04CD@oracle.com> Looks good. The IDE question still stands. If you are using an IDE this shouldn't have happened. > On Feb 10, 2016, at 8:41 PM, Konstantin Shefov wrote: > > Doug, Christian, Vladimir, thank you for reviewing. > > Here is a patch with space: > http://cr.openjdk.java.net/~kshefov/8149472/webrev.01/ > > -Konstantin > > 10.02.2016 23:02, Christian Thalinger ?????: >> + return Objects.equals(x,y); >> >> There is a missing space. Are you using an IDE? >> >>> On Feb 10, 2016, at 1:20 AM, Konstantin Shefov > wrote: >>> >>> Hello >>> >>> Please review a bug fix in JVMCI jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider::constantEquals(Constant x, Constant y) method. >>> >>> A NullPointerException is thrown, when one calls this method with the first argument x equal to null. >>> >>> Additional check should be added for null as the first argument. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149472 >>> Webrev: http://cr.openjdk.java.net/~kshefov/8149472/webrev.00/ >>> >>> Thanks >>> -Konstantin >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Thu Feb 11 20:07:36 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 11 Feb 2016 12:07:36 -0800 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> Message-ID: <4509C310-E616-4B6E-A1A0-7E30070F8CBA@oracle.com> On Feb 11, 2016, at 4:46 AM, Roland Westrelin wrote: > > overflow issue in the binary search The outer parens look wrong on the fix. You want to cast to int *after* dividing by two, I think. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Thu Feb 11 20:12:30 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 11 Feb 2016 10:12:30 -1000 Subject: RFR: 8149695: [JVMCI] add missing Checkstyle configuration file Message-ID: <784697FE-D9D3-4472-B442-D20787B7BB9E@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8149695 http://cr.openjdk.java.net/~twisti/8149695/webrev.01/ We somehow missed adding this file: src/jdk.vm.ci/share/classes/jdk.vm.ci.services/.checkstyle_checks.xml Without that file mx checkstyle doesn't work. From vladimir.kozlov at oracle.com Thu Feb 11 20:41:55 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 12:41:55 -0800 Subject: RFR: 8149695: [JVMCI] add missing Checkstyle configuration file In-Reply-To: <784697FE-D9D3-4472-B442-D20787B7BB9E@oracle.com> References: <784697FE-D9D3-4472-B442-D20787B7BB9E@oracle.com> Message-ID: <56BCF213.5060405@oracle.com> Good. Yes, we need it! Thanks, Vladimir On 2/11/16 12:12 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8149695 > http://cr.openjdk.java.net/~twisti/8149695/webrev.01/ > > We somehow missed adding this file: > > src/jdk.vm.ci/share/classes/jdk.vm.ci.services/.checkstyle_checks.xml > > Without that file mx checkstyle doesn't work. > From vladimir.kozlov at oracle.com Thu Feb 11 20:48:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 12:48:20 -0800 Subject: RFR (S): 8149689: [JVMCI] CodeInstaller::pd_patch_DataSectionReference should be able to throw exceptions In-Reply-To: <7393710C-778B-4D29-B8D6-EFA5D6AC979E@oracle.com> References: <7393710C-778B-4D29-B8D6-EFA5D6AC979E@oracle.com> Message-ID: <56BCF394.8090000@oracle.com> So what is the fix for if this method can't throw exceptions? There is no explanation what is going on and what the problem you have. Thanks, Vladimir On 2/11/16 9:56 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8149689 > http://cr.openjdk.java.net/~twisti/8149689/webrev.01/ > > All the other CodeInstaller::pd_patch_* methods can throw exceptions except this one. This fixes the AArch64 issue I introduced with 8149415. > From vladimir.kozlov at oracle.com Thu Feb 11 20:55:09 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 12:55:09 -0800 Subject: [9] RFR(XS): 8148564: compiler/intrinsics/string/TestStringIntrinsics2.java times out In-Reply-To: <56BC9AAD.1020602@oracle.com> References: <56BC9AAD.1020602@oracle.com> Message-ID: <56BCF52D.8040400@oracle.com> Good. Thanks, Vladimir On 2/11/16 6:29 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > https://bugs.openjdk.java.net/browse/JDK-8148564 > http://cr.openjdk.java.net/~thartmann/8148564/webrev.00/ > > The test times out with a fastdebug build and -Xcomp after 356 seconds. The profile shows that most time is spent in C1: > 40.06% java libjvm.so [.] RangeCheckEliminator::Verification::can_reach(BlockBegin*, BlockBegin*, BlockBeg > 20.08% java libjvm.so [.] LinearScan::is_sorted(IntervalArray*) > 4.47% java libc-2.19.so [.] memset > > LinearScan::is_sorted() is known to be very slow (JDK-8067014). It seems that RangeCheckEliminator::Verification::can_reach() also slows down performance significantly. > Without these checks the runtime drops down to 126 seconds. > > The accumulated compiler times also show that most time is spent in C1 (see [1]): > C1 Compile Time: 326.983 s > C2 Compile Time: 3.241 s > > A product build is significantly faster, i.e. the slowdown is caused by additional C1 verification code in fastdebug builds: > C1 Compile Time: 8.463 s > C2 Compile Time: 1.619 s > > The problem is that the test specifies -XX:MaxInlineSize=100 to trigger inlining of intrinsics. With -Xcomp, this also causes many other methods to be inlined, blowing up the graphs and significantly slowing down compilation. Since the test uses the Whitebox API to trigger compilation, -Xcomp is not required. > > I verified that -XX:MaxInlineSize=70 is enough to inline all intrinsics and added -Xmixed to the test to avoid compilation of unrelated methods. > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/secure/attachment/57052/CITime.log > From christian.thalinger at oracle.com Thu Feb 11 21:00:09 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 11 Feb 2016 11:00:09 -1000 Subject: RFR: 8149695: [JVMCI] add missing Checkstyle configuration file In-Reply-To: <56BCF213.5060405@oracle.com> References: <784697FE-D9D3-4472-B442-D20787B7BB9E@oracle.com> <56BCF213.5060405@oracle.com> Message-ID: Thanks, Vladimir. > On Feb 11, 2016, at 10:41 AM, Vladimir Kozlov wrote: > > Good. Yes, we need it! > > Thanks, > Vladimir > > On 2/11/16 12:12 PM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8149695 >> http://cr.openjdk.java.net/~twisti/8149695/webrev.01/ >> >> We somehow missed adding this file: >> >> src/jdk.vm.ci/share/classes/jdk.vm.ci.services/.checkstyle_checks.xml >> >> Without that file mx checkstyle doesn't work. >> From christian.thalinger at oracle.com Thu Feb 11 21:02:23 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 11 Feb 2016 11:02:23 -1000 Subject: RFR (S): 8149689: [JVMCI] CodeInstaller::pd_patch_DataSectionReference should be able to throw exceptions In-Reply-To: <56BCF394.8090000@oracle.com> References: <7393710C-778B-4D29-B8D6-EFA5D6AC979E@oracle.com> <56BCF394.8090000@oracle.com> Message-ID: > On Feb 11, 2016, at 10:48 AM, Vladimir Kozlov wrote: > > So what is the fix for if this method can't throw exceptions? > There is no explanation what is going on and what the problem you have. Oh, sorry, it?s in the review thread of 8149415. I broke open AArch64 builds because I made it throw an exception: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b038c3bea5a4#l1.61 We should be able to throw exceptions in all these methods because we don?t want JVMCI to bring down the whole VM if something goes wrong during code installation. > > Thanks, > Vladimir > > On 2/11/16 9:56 AM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8149689 >> http://cr.openjdk.java.net/~twisti/8149689/webrev.01/ >> >> All the other CodeInstaller::pd_patch_* methods can throw exceptions except this one. This fixes the AArch64 issue I introduced with 8149415. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Feb 11 21:46:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 13:46:35 -0800 Subject: RFR (S): 8149689: [JVMCI] CodeInstaller::pd_patch_DataSectionReference should be able to throw exceptions In-Reply-To: References: <7393710C-778B-4D29-B8D6-EFA5D6AC979E@oracle.com> <56BCF394.8090000@oracle.com> Message-ID: <56BD013B.2060009@oracle.com> Got it. Good. Thanks, Vladimir On 2/11/16 1:02 PM, Christian Thalinger wrote: > >> On Feb 11, 2016, at 10:48 AM, Vladimir Kozlov >> > wrote: >> >> So what is the fix for if this method can't throw exceptions? >> There is no explanation what is going on and what the problem you have. > > Oh, sorry, it?s in the review thread of 8149415. I broke open AArch64 > builds because I made it throw an exception: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b038c3bea5a4#l1.61 > > We should be able to throw exceptions in all these methods because we > don?t want JVMCI to bring down the whole VM if something goes wrong > during code installation. > >> >> Thanks, >> Vladimir >> >> On 2/11/16 9:56 AM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8149689 >>> http://cr.openjdk.java.net/~twisti/8149689/webrev.01/ >>> >>> All the other CodeInstaller::pd_patch_* methods can throw exceptions >>> except this one. This fixes the AArch64 issue I introduced with 8149415. >>> > From christian.thalinger at oracle.com Thu Feb 11 21:58:48 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 11 Feb 2016 11:58:48 -1000 Subject: RFR (S): 8149689: [JVMCI] CodeInstaller::pd_patch_DataSectionReference should be able to throw exceptions In-Reply-To: <56BD013B.2060009@oracle.com> References: <7393710C-778B-4D29-B8D6-EFA5D6AC979E@oracle.com> <56BCF394.8090000@oracle.com> <56BD013B.2060009@oracle.com> Message-ID: Thanks, Vladimir. > On Feb 11, 2016, at 11:46 AM, Vladimir Kozlov wrote: > > Got it. Good. > > Thanks, > Vladimir > > On 2/11/16 1:02 PM, Christian Thalinger wrote: >> >>> On Feb 11, 2016, at 10:48 AM, Vladimir Kozlov >>> > wrote: >>> >>> So what is the fix for if this method can't throw exceptions? >>> There is no explanation what is going on and what the problem you have. >> >> Oh, sorry, it?s in the review thread of 8149415. I broke open AArch64 >> builds because I made it throw an exception: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/b038c3bea5a4#l1.61 >> >> We should be able to throw exceptions in all these methods because we >> don?t want JVMCI to bring down the whole VM if something goes wrong >> during code installation. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 2/11/16 9:56 AM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8149689 >>>> http://cr.openjdk.java.net/~twisti/8149689/webrev.01/ >>>> >>>> All the other CodeInstaller::pd_patch_* methods can throw exceptions >>>> except this one. This fixes the AArch64 issue I introduced with 8149415. >>>> >> From vladimir.kozlov at oracle.com Thu Feb 11 23:44:24 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 15:44:24 -0800 Subject: RFR(S): 8146828: Subsequent arraycopy does not always eliminate array zeroing In-Reply-To: <86A6E1D0-F2CB-4A36-B6C8-77B12FDEF169@oracle.com> References: <86A6E1D0-F2CB-4A36-B6C8-77B12FDEF169@oracle.com> Message-ID: <56BD1CD8.4090308@oracle.com> Yes, it is complicated code with assumptions not covered by comments. Needs more comments in place where you check too_many_traps to explain why such reasons are checked (this bug description). And it should be mentioned that during expansion of ArrayCopy node subtype and other checks do not generate uncommon traps (right?) so there will be no safepoints between moved allocation and arraycopy. This change allow to move allocation when there were a lot Reason_null_check traps but not Reason_intrinsic. But in such case we generate explicit throw code for null checks (right). The could be catch path which assumes that allocation was finished. Right? Null checks can use Reason_speculate_null_check reason (null_check_oop() call). Why we don't check for it? Next comment is incomplete since you have 2 null checks, for src and dst and both should be optimized out: 4729 // See if the null check above was optimized out (alloc not null) The src check could be optimized if there is dominating check above allocation. Typo: "we can???t emit any guards" thanks, Vladimir On 2/11/16 6:41 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8146828/webrev.00/ > > The problem is that we add a null check for src when we intrinsify arraycopy. So there's a null check between the allocation and the arraycopy itself and if we hit that null check we deoptimize with a live allocation and that allocation must be zeroed. We usually move the allocation below the predicates and arrange for the predicates in case they fail to resume execution in the interpreter right before the allocation. But in that case one of the predicate fails on a first compilation (subtype check) so we don't attempt it on the second one. In the change, the check for too many traps of type Reason_intrinsic and too many traps of type Reason_null_check are done independently so if we already hit too many Reason_intrinsic traps we still can move the null check above the allocation and eliminate zeroing. Hopefully I didn?t break anything in that very confusing code. > > Roland. > From vitalyd at gmail.com Thu Feb 11 23:48:25 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 11 Feb 2016 18:48:25 -0500 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: <4509C310-E616-4B6E-A1A0-7E30070F8CBA@oracle.com> References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> <4509C310-E616-4B6E-A1A0-7E30070F8CBA@oracle.com> Message-ID: Perhaps mid = min + (max - min)/2 is better? On Thursday, February 11, 2016, John Rose wrote: > On Feb 11, 2016, at 4:46 AM, Roland Westrelin > wrote: > > > overflow issue in the binary search > > > The outer parens look wrong on the fix. You want to cast to int *after* > dividing by two, I think. > > ? John > -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan at azulsystems.com Thu Feb 11 23:55:43 2016 From: ivan at azulsystems.com (Ivan Krylov) Date: Fri, 12 Feb 2016 02:55:43 +0300 Subject: RFR(S): 8147844: new method j.l.Runtime.onSpinWait() and the corresponding x86 hotspot instrinsic In-Reply-To: References: <56A751AE.9090203@azulsystems.com> <45B4730C-CCC2-4523-ACD1-D18B20E5EC5F@oracle.com> <56A8BC9D.8060004@azulsystems.com> <6148E4D7-AF5E-4094-B363-52E0D83452E9@oracle.com> <56AA2AE4.2090803@azulsystems.com> <2538083C-7906-44AA-A074-7DBF5F2D8654@oracle.com> <50C14C66-4068-4DD7-BD94-96E37F7C9B0A@oracle.com> <56AF85F3.3060802@azulsystems.com> <56BBCBF4.2070504@azulsystems.com> Message-ID: <56BD1F7F.3020808@azulsystems.com> Hi Igor, Thanks both for your help and your reviews. Here is a new version, tested on mac for c1 and c2: http://cr.openjdk.java.net/~ikrylov/8147844.hs.03 Thanks, Ivan On 11/02/2016 09:51, Igor Veresov wrote: > The C2 part looks good to me. Thanks for making the changes. > > As for C1? > 1. There is already an HIR node to model intrinsics (?Intrinsic?), so unless there is a compelling reason to introduce a new node type I would just use that. That should get rid of many changes to HIR visitors, etc. Follow the existing examples, look for example at how vmIntrinsics::_fullFence works, your case should be the same. > 2. It?d be nice to minimize the platform specific changes. There is Compiler::is_intrinsic_supported() method that determines if something should be intensified. Follow the existing examples and add ?static bool supports_spin_wait() { return false; }" to Abstract_VM_Version, overload it to true in the VM_Version for x86, then use it to determine whether to intensify the call. You?ll still need a LIR instruction and the LIR_Assembler::on_spin_wait() method, but you can define it on on x86 only. It?s ok to not define a method if you don?t use it, and you won?t, because the intrinsic will be used only on x86. > > igor > >> On Feb 10, 2016, at 3:47 PM, Ivan Krylov wrote: >> >> I have prepared a new webrev: >> http://cr.openjdk.java.net/~ikrylov/8147844.hs.02/ >> >> Hopefully it addresses the comments that were said before. >> Per Vladimir's suggestion I added the c1 intrinsic. >> I could not test non-x86 platforms but hopefully nothing is broken there. >> >> Thanks, >> >> Ivan From igor.veresov at oracle.com Fri Feb 12 00:20:35 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 11 Feb 2016 16:20:35 -0800 Subject: RFR(S): 8147844: new method j.l.Runtime.onSpinWait() and the corresponding x86 hotspot instrinsic In-Reply-To: <56BD1F7F.3020808@azulsystems.com> References: <56A751AE.9090203@azulsystems.com> <45B4730C-CCC2-4523-ACD1-D18B20E5EC5F@oracle.com> <56A8BC9D.8060004@azulsystems.com> <6148E4D7-AF5E-4094-B363-52E0D83452E9@oracle.com> <56AA2AE4.2090803@azulsystems.com> <2538083C-7906-44AA-A074-7DBF5F2D8654@oracle.com> <50C14C66-4068-4DD7-BD94-96E37F7C9B0A@oracle.com> <56AF85F3.3060802@azulsystems.com> <56BBCBF4.2070504@azulsystems.com> <56BD1F7F.3020808@azulsystems.com> Message-ID: That looks good to me. igor > On Feb 11, 2016, at 3:55 PM, Ivan Krylov wrote: > > Hi Igor, > > Thanks both for your help and your reviews. > Here is a new version, tested on mac for c1 and c2: > > http://cr.openjdk.java.net/~ikrylov/8147844.hs.03 > > Thanks, > > Ivan > > > On 11/02/2016 09:51, Igor Veresov wrote: >> The C2 part looks good to me. Thanks for making the changes. >> >> As for C1? >> 1. There is already an HIR node to model intrinsics (?Intrinsic?), so unless there is a compelling reason to introduce a new node type I would just use that. That should get rid of many changes to HIR visitors, etc. Follow the existing examples, look for example at how vmIntrinsics::_fullFence works, your case should be the same. >> 2. It?d be nice to minimize the platform specific changes. There is Compiler::is_intrinsic_supported() method that determines if something should be intensified. Follow the existing examples and add ?static bool supports_spin_wait() { return false; }" to Abstract_VM_Version, overload it to true in the VM_Version for x86, then use it to determine whether to intensify the call. You?ll still need a LIR instruction and the LIR_Assembler::on_spin_wait() method, but you can define it on on x86 only. It?s ok to not define a method if you don?t use it, and you won?t, because the intrinsic will be used only on x86. >> >> igor >> >>> On Feb 10, 2016, at 3:47 PM, Ivan Krylov wrote: >>> >>> I have prepared a new webrev: >>> http://cr.openjdk.java.net/~ikrylov/8147844.hs.02/ >>> >>> Hopefully it addresses the comments that were said before. >>> Per Vladimir's suggestion I added the c1 intrinsic. >>> I could not test non-x86 platforms but hopefully nothing is broken there. >>> >>> Thanks, >>> >>> Ivan > From john.r.rose at oracle.com Fri Feb 12 00:24:00 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 11 Feb 2016 16:24:00 -0800 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> <4509C310-E616-4B6E-A1A0-7E30070F8CBA@oracle.com> Message-ID: <4A534829-C3EF-441A-8BD4-4F6BC6401E35@oracle.com> The uint cast version might optimize better which is why I didn't suggest the half-difference idiom. And also this should be a macro or function in globalDefinitions.hpp Life is too short to rediscover correct C expression semantics at every use point. ? John > On Feb 11, 2016, at 3:48 PM, Vitaly Davidovich wrote: > > Perhaps > > mid = min + (max - min)/2 > > is better? > >> On Thursday, February 11, 2016, John Rose wrote: >>> On Feb 11, 2016, at 4:46 AM, Roland Westrelin wrote: >>> >>> overflow issue in the binary search >> >> The outer parens look wrong on the fix. You want to cast to int *after* dividing by two, I think. >> >> ? John > > > -- > Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Fri Feb 12 00:33:33 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 11 Feb 2016 19:33:33 -0500 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: <4A534829-C3EF-441A-8BD4-4F6BC6401E35@oracle.com> References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> <4509C310-E616-4B6E-A1A0-7E30070F8CBA@oracle.com> <4A534829-C3EF-441A-8BD4-4F6BC6401E35@oracle.com> Message-ID: Optimize better how? The concern here would be idiv but gcc seems to strength reduce this code without uint just fine. On Thursday, February 11, 2016, John Rose wrote: > The uint cast version might optimize better which is why I didn't suggest > the half-difference idiom. > > And also this should be a macro or function in globalDefinitions.hpp > > Life is too short to rediscover correct C expression semantics at every > use point. > > ? John > > On Feb 11, 2016, at 3:48 PM, Vitaly Davidovich > wrote: > > Perhaps > > mid = min + (max - min)/2 > > is better? > > On Thursday, February 11, 2016, John Rose > wrote: > >> On Feb 11, 2016, at 4:46 AM, Roland Westrelin < >> roland.westrelin at oracle.com> wrote: >> >> >> overflow issue in the binary search >> >> >> The outer parens look wrong on the fix. You want to cast to int *after* >> dividing by two, I think. >> >> ? John >> > > > -- > Sent from my phone > > -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Feb 12 01:03:11 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Feb 2016 17:03:11 -0800 Subject: RFR(L) 8149655: PPC64: Implement CompactString intrinsics In-Reply-To: References: Message-ID: <56BD2F4F.60007@oracle.com> This needs review from ppc64 experts. Are you sure ADLC supports multilines and comments in effect():? + effect(USE_KILL haycnt, /* better: TDEF haycnt, */ TEMP_DEF result, + TEMP tmp1, TEMP tmp2, TEMP tmp3, TEMP tmp4, TEMP tmp5, KILL cr0, KILL cr1, KILL cr6, KILL ctr); What next repetitive comment means? // TODO: PPC port $archOpcode(ppc64Opcode_compound); Thanks, Vladimir On 2/11/16 7:11 AM, Doerr, Martin wrote: > Hi, > > I have created a webrev which adds the following String intrinsics to PPC64: > > 0 string_compareL > > 1 string_compareU > > 2 string_compareLU > > 3 string_compareUL > > 4 string_equalsL > > 5 string_equalsU > > 6 array_equalsB > > 7 array_equalsC > > 8 indexOf_imm1_char_U > > 9 indexOf_imm1_char_L > > 10 indexOf_imm1_char_UL > > 11 indexOf_imm1_U > > 12 indexOf_imm1_L > > 13 indexOf_imm1_UL > > 14 indexOfChar_U > > 15 indexOf_imm_U > > 16 indexOf_imm_L > > 17 indexOf_imm_UL > > 18 indexOf_U > > 19 indexOf_L > > 20 indexOf_UL > > 21 string_compress > > 22 string_inflate > > 23 has_negatives > > 24 encode_iso_array > > It also contains some other minor improvements. > > The webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.00/ > > Please review. > > I will also need a sponsor from Oracle because the change touches one > java test file (test/compiler/intrinsics/string/TestStringIntrinsics2.java). > > Best regards, > > Martin > From john.r.rose at oracle.com Fri Feb 12 03:18:52 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 11 Feb 2016 19:18:52 -0800 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> <4509C310-E616-4B6E-A1A0-7E30070F8CBA@oracle.com> <4A534829-C3EF-441A-8BD4-4F6BC6401E35@oracle.com> Message-ID: On Feb 11, 2016, at 4:33 PM, Vitaly Davidovich wrote: > > Optimize better how? The concern here would be idiv but gcc seems to strength reduce this code without uint just fine. No, idiv-by-2 is not an issue. My concern is simply instruction count: add/shift vs. sub/shift/add. From vitalyd at gmail.com Fri Feb 12 03:25:38 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 11 Feb 2016 22:25:38 -0500 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> <4509C310-E616-4B6E-A1A0-7E30070F8CBA@oracle.com> <4A534829-C3EF-441A-8BD4-4F6BC6401E35@oracle.com> Message-ID: I'd be more worried about the branch mispredicts and memory loads than a couple of single cycle multi issue instructions :). Anyway, the halfway idiom is known and not subject to issues like the cast precedence you raised or other bug prone variants, and I'd think the extra sub isn't going to be detectable. My $.02 On Thursday, February 11, 2016, John Rose wrote: > On Feb 11, 2016, at 4:33 PM, Vitaly Davidovich > wrote: > > > > Optimize better how? The concern here would be idiv but gcc seems to > strength reduce this code without uint just fine. > > No, idiv-by-2 is not an issue. My concern is simply instruction count: > add/shift vs. sub/shift/add. > > -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Fri Feb 12 07:01:50 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 12 Feb 2016 08:01:50 +0100 Subject: [9] RFR(XS): 8148564: compiler/intrinsics/string/TestStringIntrinsics2.java times out In-Reply-To: <56BCF52D.8040400@oracle.com> References: <56BC9AAD.1020602@oracle.com> <56BCF52D.8040400@oracle.com> Message-ID: <56BD835E.7070801@oracle.com> Thanks, Vladimir. Best, Tobias On 11.02.2016 21:55, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 2/11/16 6:29 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> https://bugs.openjdk.java.net/browse/JDK-8148564 >> http://cr.openjdk.java.net/~thartmann/8148564/webrev.00/ >> >> The test times out with a fastdebug build and -Xcomp after 356 seconds. The profile shows that most time is spent in C1: >> 40.06% java libjvm.so [.] RangeCheckEliminator::Verification::can_reach(BlockBegin*, BlockBegin*, BlockBeg >> 20.08% java libjvm.so [.] LinearScan::is_sorted(IntervalArray*) >> 4.47% java libc-2.19.so [.] memset >> >> LinearScan::is_sorted() is known to be very slow (JDK-8067014). It seems that RangeCheckEliminator::Verification::can_reach() also slows down performance significantly. >> Without these checks the runtime drops down to 126 seconds. >> >> The accumulated compiler times also show that most time is spent in C1 (see [1]): >> C1 Compile Time: 326.983 s >> C2 Compile Time: 3.241 s >> >> A product build is significantly faster, i.e. the slowdown is caused by additional C1 verification code in fastdebug builds: >> C1 Compile Time: 8.463 s >> C2 Compile Time: 1.619 s >> >> The problem is that the test specifies -XX:MaxInlineSize=100 to trigger inlining of intrinsics. With -Xcomp, this also causes many other methods to be inlined, blowing up the graphs and significantly slowing down compilation. Since the test uses the Whitebox API to trigger compilation, -Xcomp is not required. >> >> I verified that -XX:MaxInlineSize=70 is enough to inline all intrinsics and added -Xmixed to the test to avoid compilation of unrelated methods. >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/secure/attachment/57052/CITime.log >> From jamsheed.c.m at oracle.com Fri Feb 12 07:47:05 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 12 Feb 2016 13:17:05 +0530 Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash In-Reply-To: References: <56BC90DC.10004@oracle.com> Message-ID: <56BD8DF9.1070605@oracle.com> Hi Chris, revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/ Best Regards, Jamsheed On 2/11/2016 11:31 PM, Christian Thalinger wrote: > >> On Feb 11, 2016, at 3:47 AM, Jamsheed C m > > wrote: >> >> Hi, >> >> Request for review >> >> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333 >> web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ >> > > That looks alright but we should remove the constraints from all the > JVMCI command line flags because the way we use them is not supported. > > Also, can you change the error message? Right now it looks like this: > > $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java > -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler > EnableJVMCI must be enabled > Improperly specified VM option 'UseJVMCICompiler' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > I think with your changes we will only see the first line without > mentioning UseJVMCICompiler. Is that correct? > >> >> Fix Summary: added jvmci flag consistency check after arg parsing. >> >> tests: jprt >> unit test: command line verification >> >> Best Regards, >> Jamsheed > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Feb 12 09:31:39 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 12 Feb 2016 10:31:39 +0100 Subject: [9] RFR(XS): 8148564: compiler/intrinsics/string/TestStringIntrinsics2.java times out In-Reply-To: <56BC9AAD.1020602@oracle.com> References: <56BC9AAD.1020602@oracle.com> Message-ID: Hi Tobias, thanks for fixing the test. I can confirm that the intrinsics are still inlined with -XX:MaxInlineSize=70. I'm only a little confused why we need -Xmixed. This should be the default anyway. Or do you run jtreg tests by setting -Xcomp explicitly? Thumbs up from me as well, Volker On Thu, Feb 11, 2016 at 3:29 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > https://bugs.openjdk.java.net/browse/JDK-8148564 > http://cr.openjdk.java.net/~thartmann/8148564/webrev.00/ > > The test times out with a fastdebug build and -Xcomp after 356 seconds. The profile shows that most time is spent in C1: > 40.06% java libjvm.so [.] RangeCheckEliminator::Verification::can_reach(BlockBegin*, BlockBegin*, BlockBeg > 20.08% java libjvm.so [.] LinearScan::is_sorted(IntervalArray*) > 4.47% java libc-2.19.so [.] memset > > LinearScan::is_sorted() is known to be very slow (JDK-8067014). It seems that RangeCheckEliminator::Verification::can_reach() also slows down performance significantly. > Without these checks the runtime drops down to 126 seconds. > > The accumulated compiler times also show that most time is spent in C1 (see [1]): > C1 Compile Time: 326.983 s > C2 Compile Time: 3.241 s > > A product build is significantly faster, i.e. the slowdown is caused by additional C1 verification code in fastdebug builds: > C1 Compile Time: 8.463 s > C2 Compile Time: 1.619 s > > The problem is that the test specifies -XX:MaxInlineSize=100 to trigger inlining of intrinsics. With -Xcomp, this also causes many other methods to be inlined, blowing up the graphs and significantly slowing down compilation. Since the test uses the Whitebox API to trigger compilation, -Xcomp is not required. > > I verified that -XX:MaxInlineSize=70 is enough to inline all intrinsics and added -Xmixed to the test to avoid compilation of unrelated methods. > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/secure/attachment/57052/CITime.log > From konstantin.shefov at oracle.com Fri Feb 12 09:45:17 2016 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 12 Feb 2016 12:45:17 +0300 Subject: [9] RFR 8149472: NPE when executing HotSpotConstantReflectionProvider::constantEquals with null first arg In-Reply-To: <6CDA7749-2B3E-4047-9DCC-6728A2FC04CD@oracle.com> References: <56BB1CE1.8060301@oracle.com> <56BC2D06.7000905@oracle.com> <6CDA7749-2B3E-4047-9DCC-6728A2FC04CD@oracle.com> Message-ID: <56BDA9AD.6020707@oracle.com> Christian, Actually, in NetBeans by default one should press Alt+Shift+F to format the code. And I have forgotten to press it when I send the previous review. -Konstantin On 02/11/2016 10:52 PM, Christian Thalinger wrote: > Looks good. The IDE question still stands. If you are using an IDE > this shouldn't have happened. > >> On Feb 10, 2016, at 8:41 PM, Konstantin Shefov >> > >> wrote: >> >> Doug, Christian, Vladimir, thank you for reviewing. >> >> Here is a patch with space: >> http://cr.openjdk.java.net/~kshefov/8149472/webrev.01/ >> >> -Konstantin >> >> 10.02.2016 23:02, Christian Thalinger ?????: >>> + return Objects.equals(x,y); >>> >>> There is a missing space. Are you using an IDE? >>> >>>> On Feb 10, 2016, at 1:20 AM, Konstantin Shefov >>>> >>> > wrote: >>>> >>>> Hello >>>> >>>> Please review a bug fix in JVMCI >>>> jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider::constantEquals(Constant >>>> x, Constant y) method. >>>> >>>> A NullPointerException is thrown, when one calls this method with >>>> the first argument x equal to null. >>>> >>>> Additional check should be added for null as the first argument. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149472 >>>> Webrev: http://cr.openjdk.java.net/~kshefov/8149472/webrev.00/ >>>> >>>> Thanks >>>> -Konstantin >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Fri Feb 12 09:50:04 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 12 Feb 2016 09:50:04 +0000 Subject: RFR(L) 8149655: PPC64: Implement CompactString intrinsics In-Reply-To: <56BD2F4F.60007@oracle.com> References: <56BD2F4F.60007@oracle.com> Message-ID: Hi Vladimir, thanks for taking a look. We are using multi-lines and comments in effects for many years and have never seen any problems. I have also taken a look at the generated files and didn't find any errors. Seems like ADLC works better than one might think :-) The $archOpcode statements are for our Power6 scheduler which we haven't contributed, yet. I guess we will remove these comments later if we decide not to contribute it. Best regards, Martin -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Freitag, 12. Februar 2016 02:03 To: Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(L) 8149655: PPC64: Implement CompactString intrinsics This needs review from ppc64 experts. Are you sure ADLC supports multilines and comments in effect():? + effect(USE_KILL haycnt, /* better: TDEF haycnt, */ TEMP_DEF result, + TEMP tmp1, TEMP tmp2, TEMP tmp3, TEMP tmp4, TEMP tmp5, KILL cr0, KILL cr1, KILL cr6, KILL ctr); What next repetitive comment means? // TODO: PPC port $archOpcode(ppc64Opcode_compound); Thanks, Vladimir On 2/11/16 7:11 AM, Doerr, Martin wrote: > Hi, > > I have created a webrev which adds the following String intrinsics to PPC64: > > 0 string_compareL > > 1 string_compareU > > 2 string_compareLU > > 3 string_compareUL > > 4 string_equalsL > > 5 string_equalsU > > 6 array_equalsB > > 7 array_equalsC > > 8 indexOf_imm1_char_U > > 9 indexOf_imm1_char_L > > 10 indexOf_imm1_char_UL > > 11 indexOf_imm1_U > > 12 indexOf_imm1_L > > 13 indexOf_imm1_UL > > 14 indexOfChar_U > > 15 indexOf_imm_U > > 16 indexOf_imm_L > > 17 indexOf_imm_UL > > 18 indexOf_U > > 19 indexOf_L > > 20 indexOf_UL > > 21 string_compress > > 22 string_inflate > > 23 has_negatives > > 24 encode_iso_array > > It also contains some other minor improvements. > > The webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.00/ > > Please review. > > I will also need a sponsor from Oracle because the change touches one > java test file (test/compiler/intrinsics/string/TestStringIntrinsics2.java). > > Best regards, > > Martin > From roland.westrelin at oracle.com Fri Feb 12 10:40:01 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 12 Feb 2016 11:40:01 +0100 Subject: RFR(S): 8143542: C2 doesn't eliminate identical checks In-Reply-To: <56B2403A.2000400@oracle.com> References: <87A6AE42-5325-4CE7-9A7F-B0E9EAAE29D8@oracle.com> <56B2403A.2000400@oracle.com> Message-ID: Thanks for the review, Vladimir. Roland. From adinn at redhat.com Fri Feb 12 10:42:15 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 12 Feb 2016 10:42:15 +0000 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> Message-ID: <56BDB707.6090409@redhat.com> Hi Roland, A patch for the AArch64 C2 volatile/CAS generation code which deals with the effects of your proposed C2 patch is available as a webrev http://cr.openjdk.java.net/~adinn/8087341-aarch64/webrev.00/ The webrev includes your patch and mine and is based on the latest hs-comp. n.b. I have /not/ created a separate issue for the AArch64 part of this fix. I am not sure whether you want to combine it with your patch or push it as a separate stage. n.b. your patch allowed the AArch64 C2 code to be significantly simplified. That's because it ensures that the Raw memory flows associated with the GC card marks no longer intermingle with the AliasIdxBot and oop flows associated with the volatile store/CAS. This means the job of recognising the signature memory configuration between leading and trailing memory barriers is much easier. Testing: I have verified that this generates correct code for volatile put and CAS on AArch64 in all 5 relevant GC configurations: +UseG1GC +UseConcMarkSweepGC +CondCardMark +UseConcMarkSweepGC -CondCardMark +UseParallelGC +CondCardMark +UseParallelGC -CondCardMark A review from an AArch64 reviewer would be welcome. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From aph at redhat.com Fri Feb 12 10:49:31 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Feb 2016 10:49:31 +0000 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <56BDB707.6090409@redhat.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> <56BDB707.6090409@redhat.com> Message-ID: <56BDB8BB.9040305@redhat.com> On 12/02/16 10:42, Andrew Dinn wrote: > A review from an AArch64 reviewer would be welcome. Crikey. Well, it looks okay, but wow... :-) One question: if those code fails because of a different shape of ideal graph than it expects, all that happens is slightly suboptimal code, right? Andrew. From magnus.ihse.bursie at oracle.com Fri Feb 12 11:03:39 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Feb 2016 12:03:39 +0100 Subject: WE'RE HIRING: Beta testers for the new hotspot build system! Message-ID: <56BDBC0B.8000307@oracle.com> An HTML attachment was scrubbed... URL: From hui.shi at linaro.org Fri Feb 12 11:10:07 2016 From: hui.shi at linaro.org (Hui Shi) Date: Fri, 12 Feb 2016 19:10:07 +0800 Subject: RFR(s): AAch64: Adding byte array equal support In-Reply-To: <56BB5A19.60001@redhat.com> References: <56B71DDE.2040109@redhat.com> <56BB5A19.60001@redhat.com> Message-ID: Hi Andrew, Are you suggesting we should refactoring these similar code to make them share most part? Similar with handling different array copies? Regards Hui On 10 February 2016 at 23:41, Andrew Haley wrote: > On 02/07/2016 10:35 AM, Andrew Haley wrote: > > On 06/02/16 12:24, Hui Shi wrote: > >> Hi All, > >> > >> Would someone help review this patch for adding byte array equal > support on > >> aarch64? > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8149100 > >> webrev: http://cr.openjdk.java.net/~hshi/8149100/webrev/ > > > > Ok, thanks. > > Having said that, I'm unhappy that this code is almost exactly the same > as char_arrays_equals, seeming to have a slab of identical code. We've > also got char_arrays_equals, which seems to do the same thing as > string_equals. > > Andrew. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Fri Feb 12 11:18:16 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 12 Feb 2016 12:18:16 +0100 Subject: [9] RFR(XS): 8148564: compiler/intrinsics/string/TestStringIntrinsics2.java times out In-Reply-To: References: <56BC9AAD.1020602@oracle.com> Message-ID: <56BDBF78.5030305@oracle.com> Hi Volker, On 12.02.2016 10:31, Volker Simonis wrote: > Hi Tobias, > > thanks for fixing the test. I can confirm that the intrinsics are > still inlined with -XX:MaxInlineSize=70. Thanks for verifying. > I'm only a little confused why we need -Xmixed. This should be the > default anyway. Or do you run jtreg tests by setting -Xcomp > explicitly? Yes, our nightly tests run with different (explicit) flag combinations. Adding -Xmixed to the test overrides the -Xcomp flag. Thanks, Tobias > > Thumbs up from me as well, > Volker > > > On Thu, Feb 11, 2016 at 3:29 PM, Tobias Hartmann > wrote: >> Hi, >> >> please review the following patch. >> >> https://bugs.openjdk.java.net/browse/JDK-8148564 >> http://cr.openjdk.java.net/~thartmann/8148564/webrev.00/ >> >> The test times out with a fastdebug build and -Xcomp after 356 seconds. The profile shows that most time is spent in C1: >> 40.06% java libjvm.so [.] RangeCheckEliminator::Verification::can_reach(BlockBegin*, BlockBegin*, BlockBeg >> 20.08% java libjvm.so [.] LinearScan::is_sorted(IntervalArray*) >> 4.47% java libc-2.19.so [.] memset >> >> LinearScan::is_sorted() is known to be very slow (JDK-8067014). It seems that RangeCheckEliminator::Verification::can_reach() also slows down performance significantly. >> Without these checks the runtime drops down to 126 seconds. >> >> The accumulated compiler times also show that most time is spent in C1 (see [1]): >> C1 Compile Time: 326.983 s >> C2 Compile Time: 3.241 s >> >> A product build is significantly faster, i.e. the slowdown is caused by additional C1 verification code in fastdebug builds: >> C1 Compile Time: 8.463 s >> C2 Compile Time: 1.619 s >> >> The problem is that the test specifies -XX:MaxInlineSize=100 to trigger inlining of intrinsics. With -Xcomp, this also causes many other methods to be inlined, blowing up the graphs and significantly slowing down compilation. Since the test uses the Whitebox API to trigger compilation, -Xcomp is not required. >> >> I verified that -XX:MaxInlineSize=70 is enough to inline all intrinsics and added -Xmixed to the test to avoid compilation of unrelated methods. >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/secure/attachment/57052/CITime.log >> From aph at redhat.com Fri Feb 12 11:18:24 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Feb 2016 11:18:24 +0000 Subject: RFR(s): AAch64: Adding byte array equal support In-Reply-To: References: <56B71DDE.2040109@redhat.com> <56BB5A19.60001@redhat.com> Message-ID: <56BDBF80.6020903@redhat.com> On 12/02/16 11:10, Hui Shi wrote: > Are you suggesting we should refactoring these similar code to make them > share most part? Similar with handling different array copies? Yes, absolutely. There are almost no code differences. Code duplication of this kind has what we call a "bad smell". It is not necessarily wrong, and there may be a good reason for it, but it is always suspicious. Andrew. From hui.shi at linaro.org Fri Feb 12 11:21:39 2016 From: hui.shi at linaro.org (Hui Shi) Date: Fri, 12 Feb 2016 19:21:39 +0800 Subject: RFR(s): AAch64: Adding byte array equal support In-Reply-To: <56BDBF80.6020903@redhat.com> References: <56B71DDE.2040109@redhat.com> <56BB5A19.60001@redhat.com> <56BDBF80.6020903@redhat.com> Message-ID: You're right! Checking X86 implementation it use same arrays_equals implementation for all these operations, we can do this for AArch64 too. I'll create a new work item and follow up with this. Regards Hui On 12 February 2016 at 19:18, Andrew Haley wrote: > On 12/02/16 11:10, Hui Shi wrote: > > Are you suggesting we should refactoring these similar code to make > them > > share most part? Similar with handling different array copies? > > Yes, absolutely. There are almost no code differences. > > Code duplication of this kind has what we call a "bad smell". It is > not necessarily wrong, and there may be a good reason for it, but it > is always suspicious. > > Andrew. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at redhat.com Fri Feb 12 11:25:44 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 12 Feb 2016 11:25:44 +0000 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <56BDB8BB.9040305@redhat.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> <56BDB707.6090409@redhat.com> <56BDB8BB.9040305@redhat.com> Message-ID: <56BDC138.8050903@redhat.com> On 12/02/16 10:49, Andrew Haley wrote: > On 12/02/16 10:42, Andrew Dinn wrote: >> A review from an AArch64 reviewer would be welcome. > > Crikey. Well, it looks okay, but wow... :-) well, yes . . . wow! But then again, this is what we had to expect when we decided to rely on matching subgraph shapes in the back end -- a change to the details of how stores are generated in generic code will have implications for the back end. The flip side of this is twofold. Firstly, changes of this sort will always be few and far between. Secondly, Roland's change has simplified something that was over-complex in the first place; this has not only unlatched some generic optimizations that should have just worked but also, by the same token, reduced the complexity of the AArch64 back end code. > One question: if those code fails because of a different shape of > ideal graph than it expects, all that happens is slightly suboptimal > code, right? Not quite. Roland's change without the AArch64 patch triggered an assert during CAS generation when the expected subgraph was not found. Also, the current code is not built to expect whatever barrier Shenandoah might insert. It ought to fall into much the same case as G1 and CMS + CondCardMark (depending upon how the GC barriers are generated). However, a check which folds Shenandoah into the same bucket as those two still needs explicitly wiring in. This patch is probably a better place to start from than the previous version in order to add that case handling. Roland's fix decouples the effects of the GC barrier from the ones associated with oop updates. That means that following this patch any changes in the way the GC barriers are generated are less likely to impact the Aarch64 back end code that is interested in memory barriers associated with oop updates. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From aph at redhat.com Fri Feb 12 11:31:15 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Feb 2016 11:31:15 +0000 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <56BDC138.8050903@redhat.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> <56BDB707.6090409@redhat.com> <56BDB8BB.9040305@redhat.com> <56BDC138.8050903@redhat.com> Message-ID: <56BDC283.40503@redhat.com> On 12/02/16 11:25, Andrew Dinn wrote: > Not quite. Roland's change without the AArch64 patch triggered an assert > during CAS generation when the expected subgraph was not found. Hmm. Can this code not be changed to fail quietly, with no change to the code? That's what optimizations generally do. > Also, the current code is not built to expect whatever barrier > Shenandoah might insert. It ought to fall into much the same case as G1 > and CMS + CondCardMark (depending upon how the GC barriers are > generated). However, a check which folds Shenandoah into the same bucket > as those two still needs explicitly wiring in. Sure. Andrew. From magnus.ihse.bursie at oracle.com Fri Feb 12 11:42:32 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Feb 2016 12:42:32 +0100 Subject: WE'RE HIRING: Beta testers for the new hotspot build system! Message-ID: <3B88FEE2-FEC5-47BA-91C6-C200C6342C8F@oracle.com> ... or, well, more to the truth, we're *not* hiring. At least not in the sense that we'll pay you money. But we do want beta testers anyway! :-) Your reward will be a new build system that will work on the systems and configurations you care about, right out of the box, and a fuzzy warm feeling. A document that describes how to try out the new build system, and that answers many questions that you might have, is here: http://cr.openjdk.java.net/~ihse/docs/new-hotspot-build.html The TL;DR: Clone the project forest. hg clone http://hg.openjdk.java.net/build-infra/jdk9 build-infra-jdk9 cd build-infra-jdk9 && bash get_source.sh [additional closed url] The build infra project is constantly on the move. The safest way to get to a working state is by using a tag, e.g. build-infra-beta-01. bash common/bin/hgforest.sh update -r build-infra-beta-01 Build it. This works just as the with old build. bash configure && make If you have questions or want to report bugs or enhancement requests, please direct them to the build-infra project list build-infra-dev at openjdk.java.net. Note that this is different from the Build Group mailing list build-dev at openjdk.java.net. Before asking questions, please check http://cr.openjdk.java.net/~ihse/docs/new-hotspot-build.html to see if they have been answered there first. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at gmail.com Fri Feb 12 11:47:40 2016 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Fri, 12 Feb 2016 14:47:40 +0300 Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down fastdebug builds' performance In-Reply-To: References: <54F99281.7020101@oracle.com> <56B489D0.3070700@oracle.com> Message-ID: Hi All, here is a new webrev: http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.01/ I've followed Vladimir's suggestion and instead of adding yet another binary search implementation IntervalList and IntervalArray were replaced with GrowableArray that already has find_sorted method. I've hacked VM sources a bit to run CTW with product bits and C1 compilation time on my x86_64 linux laptop slowed down by 0.4% (from 51029 ? 306 ms to 51230 ? 293 ms). Please let me know if it too slow. With fastdebug bits provided patch allow to reduce C1 compilation time twice. Regards, Filipp. On Mon, Feb 8, 2016 at 11:22 AM, Filipp Zhinkin wrote: > Hi Vladimir, > > thanks for looking at this thread. > > I'll provide an updated webrev within this week. > > Regards, > Filipp. > > On Fri, Feb 5, 2016 at 2:38 PM, Vladimir Ivanov > wrote: >> (I'd like to revive the thread. It still affects our testing.) >> >> Filipp, >> >> Overall, the approach you propose looks good. >> >> What I'd like to see is unified binary_search implementation being used. >> >> There are already many places where custom implementations are used [1] [2] >> [3] and I don't want to see one more. Please, factor it out. >> GrowableArray::find_sorted looks like a good candidate (but it suffers from >> an overflow). >> >> Let me know if you don't have time to work on it. >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a34b3268a14f/src/share/vm/oops/instanceKlass.cpp#l1360 >> >> [2] >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a34b3268a14f/src/share/vm/utilities/growableArray.hpp#l391 >> >> [3] >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/a34b3268a14f/src/share/vm/gc/g1/g1CollectorPolicy.cpp#l659 >> >> >> On 3/23/15 1:40 PM, Filipp Zhinkin wrote: >>> >>> Hi all, >>> >>> sorry for a late reply. >>> >>> I don't think that it's possible to remove is_sorted assertion from >>> create_unhandled_lists, because it's crucial condition for a linear >>> scan allocation algorithm and it's pretty easy to break it incidentally. >>> Existing assertion could significantly reduce time required to locate >>> an issue when something will go wrong. >>> >>> However, I believe that it could be relaxed to check only that >>> intervals in _sorted_intervals list are actually ordered and that >>> _new_intervals_from_allocation list is empty (in sorting methods >>> we still will be verifying that sorted and unsorted lists contain >>> same intervals). >>> >>> What do you guys think about that? >>> >>> Regards, >>> Filippp. >>> >>> >>> On Fri, Mar 6, 2015 at 9:24 PM, Filipp Zhinkin >>> wrote: >>>> >>>> Hi Aleksey, >>>> >>>> thanks for looking at it! >>>> >>>> On Fri, Mar 6, 2015 at 2:41 PM, Aleksey Shipilev >>>> wrote: >>>>> >>>>> Hi Filipp, >>>>> >>>>> On 06.03.2015 14:33, Filipp Zhinkin wrote: >>>>>> >>>>>> In certain cases (like -client -Xcomp) C1 compilation is very slow >>>>>> w/ fastdebug builds. A place where we spent enormous amount of time >>>>>> is LinearScan::is_sorted method, which simply verifies that a list >>>>>> that should be sorted is actually sorted and that both sorted and >>>>>> unsorted lists contains same intervals. >>>>> >>>>> >>>>> Okay, what caller of is_sorted dominates? Maybe instead of optimizing >>>>> the is_sorted itself, you need to move/relax the assert in some selected >>>>> places? >>>> >>>> >>>> Well, the dominating caller is LinearScan::create_unhandled_lists [1]. >>>> >>>>> >>>>> That is to say I am not fond of complicating the non-product code that >>>>> does verification without a compelling reason to do so; let's first >>>>> figure out if we "just" do excess asserts. >>>> >>>> >>>> That's a good point. I'll try to figure a out if an assertion is placed >>>> to be >>>> sure that all methods called in the right sequence and if it's true, then >>>> it may be better to use less expensive approach. >>>> >>>> Thanks, >>>> Filipp. >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/de7ca28f8b7d/src/share/vm/c1/c1_LinearScan.cpp#l1486 >>>> >>>>> >>>>> Thanks, >>>>> -Aleksey. >>>>> >> From adinn at redhat.com Fri Feb 12 12:03:36 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 12 Feb 2016 12:03:36 +0000 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <56BDC283.40503@redhat.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> <56BDB707.6090409@redhat.com> <56BDB8BB.9040305@redhat.com> <56BDC138.8050903@redhat.com> <56BDC283.40503@redhat.com> Message-ID: <56BDCA18.60906@redhat.com> On 12/02/16 11:31, Andrew Haley wrote: > On 12/02/16 11:25, Andrew Dinn wrote: >> Not quite. Roland's change without the AArch64 patch triggered an assert >> during CAS generation when the expected subgraph was not found. > > Hmm. Can this code not be changed to fail quietly, with no change > to the code? That's what optimizations generally do. The assert is employed when generating AArch64 code for a CAS because every CAS should *always* be capable of being optimized to use an ldaxr/stlxr pair without the need for a top and tail dmb pair i.e. we don't have a fall back. If we see a CompareAndSwap node in a subgraph that does not have the expected shape then this can only mean that the AArch64 code has gone out of sync with a change in the generic code. The assert is used to find this mismatch during development/testing. By placing as much as possible of this checking code in an ifdef ASSERT region we avoid executing the check in production. An assert is not employed when generating AArch64 code for a StoreX because not all StoreX operations are volatile stores susceptible to optimization. So, in this case if we don't find the relevant subgraph then we just fall back to generating dmbs. The predicates which control dmb generation apply to multiple rules -- those for StoreX, MemBarRelease and MemBarVolatile. The predicates are all supposed to operate consistently so that when one predicate falls back then they all do. However, that's only guaranteed by them knowing exactly which shape to look for and correctly identifying it i.e. by me having coded it correctly (but then that's true of a lot of code:-). It would be nice to be able to cross-validate the actions of these rules applied to some set of StoreN, MemBarRelease, MemBarVolatile and CompareAndSwap nodes. However, I cannot see any way of correlating a rule application to some given node with rule applications to related nodes. Rule applications in a given sequence are not easily associated with an originating volatile put/CAS (even when you know which ones they are as happens during debugging they don't necessarily occur in a fixed order). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From roland.westrelin at oracle.com Fri Feb 12 12:22:35 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 12 Feb 2016 13:22:35 +0100 Subject: RFR(XS): 8149543: range check CastII nodes should not be split through Phi In-Reply-To: <56BB7919.1060900@oracle.com> References: <56BB7919.1060900@oracle.com> Message-ID: <85C8E279-8EB9-434B-9F27-BA7CB1FEBACA@oracle.com> Thanks for looking at this, Vladimir. > It would be nice if we could narrow this bailout only for loops. I mean when Phi's control is loop's head. > If it is an ordinary merge region splitting through it may help to improve performance. What do you think? > Could you run some performance tests to effects. If ordinary region cases are rare then you current fix is good enough. What about this? http://cr.openjdk.java.net/~roland/8149543/webrev.01/ Tobias? performance runs when he added the range check CastII found no regressions so I suppose test runs where I tweak how much split thru phi we do for CastII nodes are unlikely to show anything either. What do you think? Roland. From aleksey.shipilev at oracle.com Fri Feb 12 12:24:55 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 12 Feb 2016 15:24:55 +0300 Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down fastdebug builds' performance In-Reply-To: References: <54F99281.7020101@oracle.com> <56B489D0.3070700@oracle.com> Message-ID: <56BDCF17.30308@oracle.com> Hi Filipp, On 02/12/2016 02:47 PM, Filipp Zhinkin wrote: > here is a new webrev: http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.01/ The webrev seems incomplete: it has only hotspot.patch in it, but no other views? I wonder how many intervals have the same "from", prompting you to wiggle around looking for the exact interval? Can we define "interval_cmp" so that "(interval_cmp(i1, i2) == 0) iff (i1 == i2)", or at least make the false positives less frequent with more extensive interval key (assuming collisions are indeed problematic)? > I've hacked VM sources a bit to run CTW with product bits and C1 > compilation time on my x86_64 linux laptop > slowed down by 0.4% (from 51029 ? 306 ms to 51230 ? 293 ms). Please > let me know if it too slow. I think this is within the error margin, and therefore statistically insignificant. Even if it was significant, 0.4% is okay for compilation time regression in C1. > With fastdebug bits provided patch allow to reduce C1 compilation time twice. This is a very good improvement, but we need to see if that's the end of it, or we can squeeze even more with a few changes. I would suggest running the CTW scenario under Solaris Studio Performance Analyzer (see e.g. http://shipilev.net/blog/2016/arrays-wisdom-ancients/#_meet_solaris_studio_performance_analyzer). Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From roland.westrelin at oracle.com Fri Feb 12 12:36:09 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 12 Feb 2016 13:36:09 +0100 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <56BDB707.6090409@redhat.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> <56BDB707.6090409@redhat.com> Message-ID: <8339FB73-9C21-4513-B07B-5DEBB8583188@oracle.com> Hi Andrew, > A patch for the AArch64 C2 volatile/CAS generation code which deals with > the effects of your proposed C2 patch is available as a webrev > > http://cr.openjdk.java.net/~adinn/8087341-aarch64/webrev.00/ Thanks for putting that together. I didn?t expect that simple change to cause so much trouble. > n.b. I have /not/ created a separate issue for the AArch64 part of this > fix. I am not sure whether you want to combine it with your patch or > push it as a separate stage. I can push everything together and list you as a contributor (in the contributed-by field) if that works for you. Vladimir, can you take another look at this? Your two objections were: > Also we have specialized insert_mem_bar_volatile() if we don't want wide memory affect. Why not use it? The membar in the change takes the entire memory state as input but only changes raw memory. I don?t think that can be achieved with insert_mem_bar_volatile(). As explained by Mikael, the membar is here to force ordering between the oop store and the card table load. That?s why I think the membar?s inputs and outputs should be set up that way. > And we need to keep precedent edge link to oop store in case EA eliminates related allocation. Mikael said it?s not ok to eliminate the memory barrier if we leave the gc barrier. Roland. From konstantin.shefov at oracle.com Fri Feb 12 13:20:30 2016 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 12 Feb 2016 16:20:30 +0300 Subject: [9] RFR 8149740: NPEs when executing some HotSpotConstantReflectionProvider with null args Message-ID: <56BDDC1E.8050406@oracle.com> Hello Please review a bug fix for jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider methods. A NullPointerException is thrown, when one calls some methods of this calss with the argument equal to null. 1) readArrayLength(null); 2) readArrayElement(null, someIndex); 3) boxPrimitive(null); 4) unboxPrimitive(null); According to javadoc of these methods, NPE should not be thrown in such cases. Additional check should be added for null as the first argument. Bug: https://bugs.openjdk.java.net/browse/JDK-8149740 Webrev: http://cr.openjdk.java.net/~kshefov/8149740/webrev.00/ Thanks -Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at redhat.com Fri Feb 12 13:51:40 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 12 Feb 2016 13:51:40 +0000 Subject: [aarch64-port-dev ] RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <8339FB73-9C21-4513-B07B-5DEBB8583188@oracle.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> <56BDB707.6090409@redhat.com> <8339FB73-9C21-4513-B07B-5DEBB8583188@oracle.com> Message-ID: <56BDE36C.4020101@redhat.com> Hi Roland, On 12/02/16 12:36, Roland Westrelin wrote: > Hi Andrew, > >> A patch for the AArch64 C2 volatile/CAS generation code which deals >> with the effects of your proposed C2 patch is available as a >> webrev >> >> http://cr.openjdk.java.net/~adinn/8087341-aarch64/webrev.00/ > > Thanks for putting that together. I didn?t expect that simple change > to cause so much trouble. It was my decision to employ back end rule predicates which poke around in the graph that led to this -- it's not anything to do with your choice. I think your fix is correct and valuable in its own right, yet more so because it has simplified that back end code substantially. >> n.b. I have /not/ created a separate issue for the AArch64 part of >> this fix. I am not sure whether you want to combine it with your >> patch or push it as a separate stage. > > I can push everything together and list you as a contributor (in the > contributed-by field) if that works for you. > Yes please. I think Andrew Haley's responses so far mean that has agreed the AArch64 part of this change. Perhaps he can confirm? > Vladimir, can you take another look at this? Your two objections > were: > >> Also we have specialized insert_mem_bar_volatile() if we don't want >> wide memory affect. Why not use it? > > The membar in the change takes the entire memory state as input but > only changes raw memory. I don?t think that can be achieved with > insert_mem_bar_volatile(). As explained by Mikael, the membar is here > to force ordering between the oop store and the card table load. > That?s why I think the membar?s inputs and outputs should be set up > that way. Not that I am an official reviewer but I agree with you here. >> And we need to keep precedent edge link to oop store in case EA >> eliminates related allocation. > > Mikael said it?s not ok to eliminate the memory barrier if we leave > the gc barrier. Also in agreement with this. For both G1GC and CMS +CondCardMark a StoreLoad barrier is necessary to ensure that the StoreX is visible before the LoadB/StoreCM pair which implement the conditional card mark. For these configurations AArch64 detects any MemBarVolatile associated with the card mark and inserts a dmb ish instruction (StoreLoad implementation) before the ldrb/strb. With CMS -CondCardMark the generic code does not insert a memory barrier. However, for correctness on non-TSO architectures we need a StoreStore barrier between the StoreX and the StoreCM implementing the card mark. That ensures that these writes cannot be observed by GC threads out of order (it might cause the GC to miss the write). This special case is handled on AArch64 by translating StoreCM to include a dmb ishst instruction (StoreStore implementation) before the strb. regards, Andrew Dinn ----------- From paul.sandoz at oracle.com Fri Feb 12 14:01:30 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 12 Feb 2016 15:01:30 +0100 Subject: RFR(S): 8147844: new method j.l.Runtime.onSpinWait() and the corresponding x86 hotspot instrinsic In-Reply-To: <56BD1F7F.3020808@azulsystems.com> References: <56A751AE.9090203@azulsystems.com> <45B4730C-CCC2-4523-ACD1-D18B20E5EC5F@oracle.com> <56A8BC9D.8060004@azulsystems.com> <6148E4D7-AF5E-4094-B363-52E0D83452E9@oracle.com> <56AA2AE4.2090803@azulsystems.com> <2538083C-7906-44AA-A074-7DBF5F2D8654@oracle.com> <50C14C66-4068-4DD7-BD94-96E37F7C9B0A@oracle.com> <56AF85F3.3060802@azulsystems.com> <56BBCBF4.2070504@azulsystems.com> <56BD1F7F.3020808@azulsystems.com> Message-ID: > On 12 Feb 2016, at 00:55, Ivan Krylov wrote: > > Hi Igor, > > Thanks both for your help and your reviews. > Here is a new version, tested on mac for c1 and c2: > > http://cr.openjdk.java.net/~ikrylov/8147844.hs.03 > Now that support C1 is supported should the test be updated with C1 only execution? Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From aph at redhat.com Fri Feb 12 14:07:21 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Feb 2016 14:07:21 +0000 Subject: [aarch64-port-dev ] RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <56BDE36C.4020101@redhat.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> <56BDB707.6090409@redhat.com> <8339FB73-9C21-4513-B07B-5DEBB8583188@oracle.com> <56BDE36C.4020101@redhat.com> Message-ID: <56BDE719.2010703@redhat.com> On 12/02/16 13:51, Andrew Dinn wrote: > Yes please. I think Andrew Haley's responses so far mean that has > agreed the AArch64 part of this change. Perhaps he can confirm? Sure. Andrew. From doug.simon at oracle.com Fri Feb 12 14:10:16 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 12 Feb 2016 15:10:16 +0100 Subject: [9] RFR 8149740: NPEs when executing some HotSpotConstantReflectionProvider with null args In-Reply-To: <56BDDC1E.8050406@oracle.com> References: <56BDDC1E.8050406@oracle.com> Message-ID: <3313ECBE-0775-4113-B563-D7B4B07FF11C@oracle.com> Looks good to me. > On 12 Feb 2016, at 14:20, Konstantin Shefov wrote: > > Hello > > Please review a bug fix for jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider methods. > > A NullPointerException is thrown, when one calls some methods of this calss with the argument equal to null. > > 1) readArrayLength(null); > 2) readArrayElement(null, someIndex); > 3) boxPrimitive(null); > 4) unboxPrimitive(null); > > According to javadoc of these methods, NPE should not be thrown in such cases. > > Additional check should be added for null as the first argument. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149740 > Webrev: http://cr.openjdk.java.net/~kshefov/8149740/webrev.00/ > > Thanks > -Konstantin From roland.westrelin at oracle.com Fri Feb 12 15:23:25 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 12 Feb 2016 16:23:25 +0100 Subject: RFR(S): 8146828: Subsequent arraycopy does not always eliminate array zeroing In-Reply-To: <56BD1CD8.4090308@oracle.com> References: <86A6E1D0-F2CB-4A36-B6C8-77B12FDEF169@oracle.com> <56BD1CD8.4090308@oracle.com> Message-ID: Thanks for taking a look at this, Vladimir. > Yes, it is complicated code with assumptions not covered by comments. > > Needs more comments in place where you check too_many_traps to explain why such reasons are checked (this bug description). Here is a new webrev with more comments: http://cr.openjdk.java.net/~roland/8146828/webrev.01/ > And it should be mentioned that during expansion of ArrayCopy node subtype and other checks do not generate uncommon traps (right?) so there will be no safepoints between moved allocation and arraycopy. > > This change allow to move allocation when there were a lot Reason_null_check traps but not Reason_intrinsic. But in such case we generate explicit throw code for null checks (right). The could be catch path which assumes that allocation was finished. Right? But in that case, the second call to tightly_coupled_allocation(): 4760 alloc = tightly_coupled_allocation(dest, NULL); would return null because something would observe the allocation. > Null checks can use Reason_speculate_null_check reason (null_check_oop() call). Why we don't check for it? I?ve added code to take care of that. > Next comment is incomplete since you have 2 null checks, for src and dst and both should be optimized out: > > 4729 // See if the null check above was optimized out (alloc not null) > > The src check could be optimized if there is dominating check above allocation. > > Typo: "we can???t emit any guards? I fixed that as well. Roland. > > thanks, > Vladimir > > > On 2/11/16 6:41 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8146828/webrev.00/ >> >> The problem is that we add a null check for src when we intrinsify arraycopy. So there's a null check between the allocation and the arraycopy itself and if we hit that null check we deoptimize with a live allocation and that allocation must be zeroed. We usually move the allocation below the predicates and arrange for the predicates in case they fail to resume execution in the interpreter right before the allocation. But in that case one of the predicate fails on a first compilation (subtype check) so we don't attempt it on the second one. In the change, the check for too many traps of type Reason_intrinsic and too many traps of type Reason_null_check are done independently so if we already hit too many Reason_intrinsic traps we still can move the null check above the allocation and eliminate zeroing. Hopefully I didn?t break anything in that very confusing code. >> >> Roland. >> From roland.westrelin at oracle.com Fri Feb 12 15:31:50 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 12 Feb 2016 16:31:50 +0100 Subject: RFR(S): 8007986: GrowableArray should implement binary search In-Reply-To: <4509C310-E616-4B6E-A1A0-7E30070F8CBA@oracle.com> References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com> <740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com> <4509C310-E616-4B6E-A1A0-7E30070F8CBA@oracle.com> Message-ID: Hi John, Thanks for looking at this. >> overflow issue in the binary search > > The outer parens look wrong on the fix. You want to cast to int *after* dividing by two, I think. You?re right obviously. Is it good to go if I add the missing parentheses? int mid = (int)(((uint)max + min) / 2); Roland. From roland.westrelin at oracle.com Fri Feb 12 15:53:17 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 12 Feb 2016 16:53:17 +0100 Subject: RFR(S): 8149745: C2 should optimize long accumulations in a counted loop Message-ID: http://cr.openjdk.java.net/~roland/8149745/webrev.00/ This extends the code that looks for a parallel induction variable to long accumulations so in the following code: public static long testLongAcc() { long acc = 0; for (int i = 0; i < 1000; i++) { acc += 8; } return acc; } the loop is optimized out. What I find puzzling is that code for integer accumulations doesn?t try to estimate the benefit of turning one AddI into a more expensive MulI + AddI. Maybe it?s too unpredictable but in the case of the long accumulations would we want to check that, for instance, the long Phi has no use in the loop? Roland. From filipp.zhinkin at gmail.com Fri Feb 12 16:08:38 2016 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Fri, 12 Feb 2016 19:08:38 +0300 Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down fastdebug builds' performance In-Reply-To: <56BDCF17.30308@oracle.com> References: <54F99281.7020101@oracle.com> <56B489D0.3070700@oracle.com> <56BDCF17.30308@oracle.com> Message-ID: Hi Aleksey, On Fri, Feb 12, 2016 at 3:24 PM, Aleksey Shipilev wrote: > Hi Filipp, > > On 02/12/2016 02:47 PM, Filipp Zhinkin wrote: >> here is a new webrev: http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.01/ > > The webrev seems incomplete: it has only hotspot.patch in it, but no > other views? It seems like only wdiff's are empty for some reason. What else is missed out there? > > I wonder how many intervals have the same "from", prompting you to > wiggle around looking for the exact interval? Well, there should be (relatively) many intervals with "from" == 0 created for physical registers. For virtual registers there could be few intervals that share the same "from" value: it depends on amount of temporary registers required by an operation and amount of outputs it produces. So we may simply scan intervals from beginning if key's from value is 0. > Can we define > "interval_cmp" so that "(interval_cmp(i1, i2) == 0) iff (i1 == i2)", No, unfortunately we can't, because intervals are ordered only by "from" value. > or at least make the false positives less frequent with more extensive > interval key (assuming collisions are indeed problematic)? > Not sure that I've got you. Nevertheless, I'll run CTW and check how many false positives are actually found. > >> I've hacked VM sources a bit to run CTW with product bits and C1 >> compilation time on my x86_64 linux laptop >> slowed down by 0.4% (from 51029 ? 306 ms to 51230 ? 293 ms). Please >> let me know if it too slow. > > I think this is within the error margin, and therefore statistically > insignificant. Even if it was significant, 0.4% is okay for compilation > time regression in C1. > >> With fastdebug bits provided patch allow to reduce C1 compilation time twice. > > This is a very good improvement, but we need to see if that's the end of > it, or we can squeeze even more with a few changes. I would suggest > running the CTW scenario under Solaris Studio Performance Analyzer (see > e.g. > http://shipilev.net/blog/2016/arrays-wisdom-ancients/#_meet_solaris_studio_performance_analyzer). Thank you for the suggestion, I'll check it. Regards, Filipp. > > Thanks, > -Aleksey > > From christian.thalinger at oracle.com Fri Feb 12 16:42:31 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 12 Feb 2016 06:42:31 -1000 Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash In-Reply-To: <56BD8DF9.1070605@oracle.com> References: <56BC90DC.10004@oracle.com> <56BD8DF9.1070605@oracle.com> Message-ID: Well, now you have to manually check all flags that had a constraint directive. That is the annoying part and what I complained about in: https://bugs.openjdk.java.net/browse/JDK-8145357 Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now empty and I think we should remove them. > On Feb 11, 2016, at 9:47 PM, Jamsheed C m wrote: > > Hi Chris, > > revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/ > > Best Regards, > Jamsheed > > On 2/11/2016 11:31 PM, Christian Thalinger wrote: >> >>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote: >>> >>> Hi, >>> >>> Request for review >>> >>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333 >>> web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ >> >> That looks alright but we should remove the constraints from all the JVMCI command line flags because the way we use them is not supported. >> >> Also, can you change the error message? Right now it looks like this: >> >> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler >> EnableJVMCI must be enabled >> Improperly specified VM option 'UseJVMCICompiler' >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> I think with your changes we will only see the first line without mentioning UseJVMCICompiler. Is that correct? >> >>> >>> Fix Summary: added jvmci flag consistency check after arg parsing. >>> >>> tests: jprt >>> unit test: command line verification >>> >>> Best Regards, >>> Jamsheed >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri Feb 12 16:46:05 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 12 Feb 2016 06:46:05 -1000 Subject: [9] RFR 8149472: NPE when executing HotSpotConstantReflectionProvider::constantEquals with null first arg In-Reply-To: <56BDA9AD.6020707@oracle.com> References: <56BB1CE1.8060301@oracle.com> <56BC2D06.7000905@oracle.com> <6CDA7749-2B3E-4047-9DCC-6728A2FC04CD@oracle.com> <56BDA9AD.6020707@oracle.com> Message-ID: <1CE2B5F6-D634-42A4-B6D4-76462D859463@oracle.com> There are no on-save actions as in Eclipse? Too bad. > On Feb 11, 2016, at 11:45 PM, Konstantin Shefov wrote: > > Christian, > > Actually, in NetBeans by default one should press Alt+Shift+F to format the code. And I have forgotten to press it when I send the previous review. > > -Konstantin > > On 02/11/2016 10:52 PM, Christian Thalinger wrote: >> Looks good. The IDE question still stands. If you are using an IDE this shouldn't have happened. >> >>> On Feb 10, 2016, at 8:41 PM, Konstantin Shefov > wrote: >>> >>> Doug, Christian, Vladimir, thank you for reviewing. >>> >>> Here is a patch with space: >>> http://cr.openjdk.java.net/~kshefov/8149472/webrev.01/ >>> >>> -Konstantin >>> >>> 10.02.2016 23:02, Christian Thalinger ?????: >>>> + return Objects.equals(x,y); >>>> >>>> There is a missing space. Are you using an IDE? >>>> >>>>> On Feb 10, 2016, at 1:20 AM, Konstantin Shefov < konstantin.shefov at oracle.com > wrote: >>>>> >>>>> Hello >>>>> >>>>> Please review a bug fix in JVMCI jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider::constantEquals(Constant x, Constant y) method. >>>>> >>>>> A NullPointerException is thrown, when one calls this method with the first argument x equal to null. >>>>> >>>>> Additional check should be added for null as the first argument. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149472 >>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8149472/webrev.00/ >>>>> >>>>> Thanks >>>>> -Konstantin >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri Feb 12 16:49:33 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 12 Feb 2016 06:49:33 -1000 Subject: [9] RFR 8149472: NPE when executing HotSpotConstantReflectionProvider::constantEquals with null first arg In-Reply-To: <1CE2B5F6-D634-42A4-B6D4-76462D859463@oracle.com> References: <56BB1CE1.8060301@oracle.com> <56BC2D06.7000905@oracle.com> <6CDA7749-2B3E-4047-9DCC-6728A2FC04CD@oracle.com> <56BDA9AD.6020707@oracle.com> <1CE2B5F6-D634-42A4-B6D4-76462D859463@oracle.com> Message-ID: I forgot to mention that I pushed a missing file yesterday: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a43579055b3c Now ?mx checkstyle? actually works and would tell you about this: $ mx checkstyle Running Checkstyle on /Users/cthaling/ws/jdk9/hs-comp/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src using /Users/cthaling/ws/jdk9/hs-comp/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.services/.checkstyle_checks.xml... Checkstyle ends with 1 errors. /Users/cthaling/ws/jdk9/hs-comp/hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java:74: ',' is not followed by whitespace. > On Feb 12, 2016, at 6:46 AM, Christian Thalinger wrote: > > There are no on-save actions as in Eclipse? Too bad. > >> On Feb 11, 2016, at 11:45 PM, Konstantin Shefov > wrote: >> >> Christian, >> >> Actually, in NetBeans by default one should press Alt+Shift+F to format the code. And I have forgotten to press it when I send the previous review. >> >> -Konstantin >> >> On 02/11/2016 10:52 PM, Christian Thalinger wrote: >>> Looks good. The IDE question still stands. If you are using an IDE this shouldn't have happened. >>> >>>> On Feb 10, 2016, at 8:41 PM, Konstantin Shefov > wrote: >>>> >>>> Doug, Christian, Vladimir, thank you for reviewing. >>>> >>>> Here is a patch with space: >>>> http://cr.openjdk.java.net/~kshefov/8149472/webrev.01/ >>>> >>>> -Konstantin >>>> >>>> 10.02.2016 23:02, Christian Thalinger ?????: >>>>> + return Objects.equals(x,y); >>>>> >>>>> There is a missing space. Are you using an IDE? >>>>> >>>>>> On Feb 10, 2016, at 1:20 AM, Konstantin Shefov < konstantin.shefov at oracle.com > wrote: >>>>>> >>>>>> Hello >>>>>> >>>>>> Please review a bug fix in JVMCI jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider::constantEquals(Constant x, Constant y) method. >>>>>> >>>>>> A NullPointerException is thrown, when one calls this method with the first argument x equal to null. >>>>>> >>>>>> Additional check should be added for null as the first argument. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149472 >>>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8149472/webrev.00/ >>>>>> >>>>>> Thanks >>>>>> -Konstantin >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Fri Feb 12 17:12:20 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 12 Feb 2016 22:42:20 +0530 Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash In-Reply-To: References: <56BC90DC.10004@oracle.com> <56BD8DF9.1070605@oracle.com> Message-ID: <56BE1274.4020506@oracle.com> Hi Chris, On 2/12/2016 10:12 PM, Christian Thalinger wrote: > Well, now you have to manually check all flags that had a constraint > directive. That is the annoying part and what I complained about in: check against original value, and if not fail ? > > https://bugs.openjdk.java.net/browse/JDK-8145357 > > Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now empty > and I think we should remove them. i kept the file as there can be future use. Ok, i will remove it. Best Regards, Jamsheed > >> On Feb 11, 2016, at 9:47 PM, Jamsheed C m > > wrote: >> >> Hi Chris, >> >> revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/ >> >> Best Regards, >> Jamsheed >> >> On 2/11/2016 11:31 PM, Christian Thalinger wrote: >>> >>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m >>>> wrote: >>>> >>>> Hi, >>>> >>>> Request for review >>>> >>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333 >>>> web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ >>>> >>> >>> That looks alright but we should remove the constraints from all the >>> JVMCI command line flags because the way we use them is not supported. >>> >>> Also, can you change the error message? Right now it looks like this: >>> >>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java >>> -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler >>> EnableJVMCI must be enabled >>> Improperly specified VM option 'UseJVMCICompiler' >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> >>> I think with your changes we will only see the first line without >>> mentioning UseJVMCICompiler. Is that correct? >>> >>>> >>>> Fix Summary: added jvmci flag consistency check after arg parsing. >>>> >>>> tests: jprt >>>> unit test: command line verification >>>> >>>> Best Regards, >>>> Jamsheed >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Fri Feb 12 17:15:38 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 12 Feb 2016 20:15:38 +0300 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <56B4CE00.3040809@oracle.com> References: <56B37387.2040204@oracle.com> <6CCE2F2C-1836-47CC-B13E-4371C2CE61FF@oracle.com> <56B4CE00.3040809@oracle.com> Message-ID: <56BE133A.70508@oracle.com> Any reviews, please? Best regards, Vladimir Ivanov On 2/5/16 7:29 PM, Vladimir Ivanov wrote: > Thanks, John. > > On 2/4/16 9:52 PM, John Rose wrote: >> Looks good. Except I don't recall how is_inline interacts, if at all, >> with customization. It's not clear what is being gated, and which >> optimizations get let through. > Inlining through MH::invokeBasic doesn't happen when there's @DontInline > on the target. It is the case for GWT which has CountingWrapper on both > paths. It starts with a reinvoker.dontInline LF and then switches to a > reinvoker LF (after 30 invocations). If a compilation happens when > reinvoker.dontInline is used, a direct call is generated and even if the > branch becomes hot, all the calls goes through reinvoker.dontInline. > Update to reinvoker LF isn't visible unless the dispatch goes through > MH::invokeBasic linker. > > I had an impression that I introduced LF customization logic to the > non-inlined case in GWT, but I can't find it in the code. So, it seems > the regression is caused by repeated checks performed by > reinvoker.dontInline LF and not by LF customization missed in generated > code. > > Also, I stumbled upon a quirk in inlining policy: inlining through > linkers can't be delayed. It happens when JIT hits some limit on IR > size. So, right now inlining can stop in the middle of MH chain and a > linker call is generated. > > But after JDK-8072008 there's no problem with delaying inlining. C2 can > decide whether to keep the direct call or inline through it. So, I > enabled late inlining for all linkers. (Surprisingly, no significant > performance difference on nashorn.) > > So, I decided to keep invokeBasic linker call replacement for now, but > piggypack LF customization on the stuck counting LF. > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8148994/webrev.01/hotspot > http://cr.openjdk.java.net/~vlivanov/8148994/webrev.01/jdk > > * enabled late inlining for linkers; > * add LF customization check in CountingWrapper::countDown, so when > counting is stuck, the target will be customized. > > Testing: octane, JPRT. > > I'm working on JDK-8071793 [1] and will reconsider how LF customization > on non-inlined branch in GWTs works given there is a more JVM-friendly > mechanism to control inlining. With the proposed fix > reinvoker.dontInline is never customized (only the target it points to) > and serves as a trampoline between GWT & target LF. It would be better > to jump right to the customized LF, if non-inlined branch becomes hot. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8071793 > "Prune rarely called invokedynamic call sites during inlining" >> >> Maybe a comment about that would be useful >> Reviewed. >> >> ? John >> >>> On Feb 4, 2016, at 7:51 AM, Vladimir Ivanov >>> wrote: >>> >>> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8148994 >>> >>> JDK-8072008 [1] introduced an optimization to bypass linker calls in >>> generated code when target method can't be inlined. >>> >>> Unfortunately, it doesn't work well with MH::invokeBasic(), because >>> it clashes with LambdaForm customization: if a call is not inlined, >>> it is important for performance to update (customize) corresponding >>> LambdaForm on-the-fly. MH::invokeBasic() linker does MH -> LF -> >>> Method* -> _from_compiled_entry traversal on every invocation, while >>> direct call points right to the _from_compiled_entry. So, any >>> LambdaForm updates aren't visible until recompilation. >>> >>> The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm >>> instance is used on every invocation. >>> >>> Also, cleaned up relevant tests a bit. >>> >>> Testing: octane, JPRT. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8072008 >>> "Emit direct call instead of linkTo* for recursive >>> indy/MH.invoke* calls" From vladimir.kempik at oracle.com Fri Feb 12 18:29:57 2016 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Fri, 12 Feb 2016 21:29:57 +0300 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic Message-ID: <56BE24A5.2060203@oracle.com> Hello Please review this backport of 8130150 to jdk8u. Implement BigInteger.montgomeryMultiply intrinsic The patch didn't apply cleanly, some changes were needed. Most of them are just to make patch apply, except one. for MACC and MACC2 defines, __asm__ were changed to asm, to make solaris compiler (SS12U1) happy. The patch has two parts, for jdk and hotspot. Testing: jprt, testcase. Bug:https://bugs.openjdk.java.net/browse/JDK-8130150 Webrev: http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.00/ Thanks -Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kempik at oracle.com Fri Feb 12 18:31:22 2016 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Fri, 12 Feb 2016 21:31:22 +0300 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56BE24A5.2060203@oracle.com> References: <56BE24A5.2060203@oracle.com> Message-ID: <56BE24FA.3080100@oracle.com> Webrev for jdk part: http://cr.openjdk.java.net/~vkempik/8130150/webrev_jdk.00/ On 12.02.2016 21:29, Vladimir Kempik wrote: > Hello > > Please review this backport of 8130150 to jdk8u. > > Implement BigInteger.montgomeryMultiply intrinsic > > The patch didn't apply cleanly, some changes were needed. Most of them are just to make patch apply, except one. > for MACC and MACC2 defines, __asm__ were changed to asm, to make solaris compiler (SS12U1) happy. > > The patch has two parts, for jdk and hotspot. > > Testing: jprt, testcase. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8130150 > Webrev:http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.00/ > > Thanks > -Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Feb 12 19:01:42 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Feb 2016 11:01:42 -0800 Subject: RFR(S): 8146828: Subsequent arraycopy does not always eliminate array zeroing In-Reply-To: References: <86A6E1D0-F2CB-4A36-B6C8-77B12FDEF169@oracle.com> <56BD1CD8.4090308@oracle.com> Message-ID: <56BE2C16.9010203@oracle.com> Yes, now it is more clear. Thanks! On 2/12/16 7:23 AM, Roland Westrelin wrote: > Thanks for taking a look at this, Vladimir. > >> Yes, it is complicated code with assumptions not covered by comments. >> >> Needs more comments in place where you check too_many_traps to explain why such reasons are checked (this bug description). > > Here is a new webrev with more comments: > http://cr.openjdk.java.net/~roland/8146828/webrev.01/ Looks good. > >> And it should be mentioned that during expansion of ArrayCopy node subtype and other checks do not generate uncommon traps (right?) so there will be no safepoints between moved allocation and arraycopy. >> >> This change allow to move allocation when there were a lot Reason_null_check traps but not Reason_intrinsic. But in such case we generate explicit throw code for null checks (right). The could be catch path which assumes that allocation was finished. Right? > > But in that case, the second call to tightly_coupled_allocation(): > > 4760 alloc = tightly_coupled_allocation(dest, NULL); > > would return null because something would observe the allocation. Okay, I missed that it also checks users. Thanks, Vladimir > >> Null checks can use Reason_speculate_null_check reason (null_check_oop() call). Why we don't check for it? > > I?ve added code to take care of that. > >> Next comment is incomplete since you have 2 null checks, for src and dst and both should be optimized out: >> >> 4729 // See if the null check above was optimized out (alloc not null) >> >> The src check could be optimized if there is dominating check above allocation. >> >> Typo: "we can???t emit any guards? > > I fixed that as well. > > Roland. > >> >> thanks, >> Vladimir >> >> >> On 2/11/16 6:41 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8146828/webrev.00/ >>> >>> The problem is that we add a null check for src when we intrinsify arraycopy. So there's a null check between the allocation and the arraycopy itself and if we hit that null check we deoptimize with a live allocation and that allocation must be zeroed. We usually move the allocation below the predicates and arrange for the predicates in case they fail to resume execution in the interpreter right before the allocation. But in that case one of the predicate fails on a first compilation (subtype check) so we don't attempt it on the second one. In the change, the check for too many traps of type Reason_intrinsic and too many traps of type Reason_null_check are done independently so if we already hit too many Reason_intrinsic traps we still can move the null check above the allocation and eliminate zeroing. Hopefully I didn?t break anything in that very confusing code. >>> >>> Roland. >>> > From vladimir.kozlov at oracle.com Fri Feb 12 19:18:25 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Feb 2016 11:18:25 -0800 Subject: RFR(S): 8149745: C2 should optimize long accumulations in a counted loop In-Reply-To: References: Message-ID: <56BE3001.2010007@oracle.com> incr2->Opcode() is called several time now but it is virtual method. Can you put it in local variable? Add assert before next line assert(opc == Op_AddI || opc == Op_AddL + BasicType bt = incr2->Opcode() == Op_AddI ? T_INT : T_LONG; May need to add cast (jlong)stride2->get_int() to make all CC happy: jlong stride_con2 = (bt == T_INT) ? stride2->get_int() : stride2->get_long(); You need to add new ConvI2LNode(init2) in case bt == T_LONG: Node* diff = SubNode::make(bt, init2, ratio_init); Otherwise this looks good. Thanks, Vlaidmir On 2/12/16 7:53 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8149745/webrev.00/ > > This extends the code that looks for a parallel induction variable to long accumulations so in the following code: > > public static long testLongAcc() { > long acc = 0; > > for (int i = 0; i < 1000; i++) { > acc += 8; > } > > return acc; > } > > the loop is optimized out. > > What I find puzzling is that code for integer accumulations doesn?t try to estimate the benefit of turning one AddI into a more expensive MulI + AddI. Maybe it?s too unpredictable but in the case of the long accumulations would we want to check that, for instance, the long Phi has no use in the loop? > > Roland. > > From vladimir.kozlov at oracle.com Fri Feb 12 19:20:54 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Feb 2016 11:20:54 -0800 Subject: [8u-dev] Request for approval to backport: 8081778: Use Intel x64 CPU instructions for RSA acceleration In-Reply-To: <56BE29A1.1040207@oracle.com> References: <56BE29A1.1040207@oracle.com> Message-ID: <56BE3096.8010808@oracle.com> 8u changes looks good. Thanks, Vladimir On 2/12/16 10:51 AM, Ivan Gerasimov wrote: > Hello! > > I'm seeking an approval to backport this performance enhancement to jdk8u-dev. > The change applies *almost* cleanly. > The only change I had to make was adding the extra argument to the 'new' operator, which is required in jdk8, but not jdk9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081778 > Jdk9 hotspot change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/578f086f3435 > Jdk9 jdk change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/de309dbe42bf > Jdk9 review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-May/018106.html > > The changes, comparing to jdk9 are in > hotspot/src/share/vm/opto/library_call.cpp at lines #5956 and #5964; > > Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8081778/00/webrev/ > > Patched Jdk was successfully built and tested on all supported platforms. > > Would you please approve this backport? > > Sincerely yours, > Ivan > > > From vladimir.kozlov at oracle.com Fri Feb 12 19:44:18 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Feb 2016 11:44:18 -0800 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <8339FB73-9C21-4513-B07B-5DEBB8583188@oracle.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> <56BDB707.6090409@redhat.com> <8339FB73-9C21-4513-B07B-5DEBB8583188@oracle.com> Message-ID: <56BE3612.4080305@oracle.com> Roland, Can you create new webrev which includes everything (aarch64)? And I am satisfied with your answers to my objections. Thanks, Vladimir On 2/12/16 4:36 AM, Roland Westrelin wrote: > Hi Andrew, > >> A patch for the AArch64 C2 volatile/CAS generation code which deals with >> the effects of your proposed C2 patch is available as a webrev >> >> http://cr.openjdk.java.net/~adinn/8087341-aarch64/webrev.00/ > > Thanks for putting that together. I didn?t expect that simple change to cause so much trouble. > >> n.b. I have /not/ created a separate issue for the AArch64 part of this >> fix. I am not sure whether you want to combine it with your patch or >> push it as a separate stage. > > I can push everything together and list you as a contributor (in the contributed-by field) if that works for you. > > Vladimir, can you take another look at this? Your two objections were: > >> Also we have specialized insert_mem_bar_volatile() if we don't want wide memory affect. Why not use it? > > The membar in the change takes the entire memory state as input but only changes raw memory. I don?t think that can be achieved with insert_mem_bar_volatile(). As explained by Mikael, the membar is here to force ordering between the oop store and the card table load. That?s why I think the membar?s inputs and outputs should be set up that way. > >> And we need to keep precedent edge link to oop store in case EA eliminates related allocation. > > Mikael said it?s not ok to eliminate the memory barrier if we leave the gc barrier. > > Roland. > From vladimir.kozlov at oracle.com Fri Feb 12 20:01:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Feb 2016 12:01:20 -0800 Subject: RFR(XS): 8149543: range check CastII nodes should not be split through Phi In-Reply-To: <85C8E279-8EB9-434B-9F27-BA7CB1FEBACA@oracle.com> References: <56BB7919.1060900@oracle.com> <85C8E279-8EB9-434B-9F27-BA7CB1FEBACA@oracle.com> Message-ID: <56BE3A10.9030402@oracle.com> On 2/12/16 4:22 AM, Roland Westrelin wrote: > Thanks for looking at this, Vladimir. > >> It would be nice if we could narrow this bailout only for loops. I mean when Phi's control is loop's head. >> If it is an ordinary merge region splitting through it may help to improve performance. What do you think? >> Could you run some performance tests to effects. If ordinary region cases are rare then you current fix is good enough. > > What about this? > http://cr.openjdk.java.net/~roland/8149543/webrev.01/ Good. > > Tobias? performance runs when he added the range check CastII found no regressions so I suppose test runs where I tweak how much split thru phi we do for CastII nodes are unlikely to show anything either. What do you think? Okay. Thanks, Vladimir > > Roland. > From christian.thalinger at oracle.com Fri Feb 12 21:54:59 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 12 Feb 2016 11:54:59 -1000 Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash In-Reply-To: <56BE1274.4020506@oracle.com> References: <56BC90DC.10004@oracle.com> <56BD8DF9.1070605@oracle.com> <56BE1274.4020506@oracle.com> Message-ID: <41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com> > On Feb 12, 2016, at 7:12 AM, Jamsheed C m wrote: > > > Hi Chris, > > On 2/12/2016 10:12 PM, Christian Thalinger wrote: >> Well, now you have to manually check all flags that had a constraint directive. That is the annoying part and what I complained about in: > check against original value, and if not fail ? Same check for all flags; they all depend on +EnableJVMCI. >> >> https://bugs.openjdk.java.net/browse/JDK-8145357 >> >> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now empty and I think we should remove them. > i kept the file as there can be future use. Ok, i will remove it. > > Best Regards, > Jamsheed >> >>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m > wrote: >>> >>> Hi Chris, >>> >>> revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/ >>> >>> Best Regards, >>> Jamsheed >>> >>> On 2/11/2016 11:31 PM, Christian Thalinger wrote: >>>> >>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Request for review >>>>> >>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333 >>>>> web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ >>>> >>>> That looks alright but we should remove the constraints from all the JVMCI command line flags because the way we use them is not supported. >>>> >>>> Also, can you change the error message? Right now it looks like this: >>>> >>>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler >>>> EnableJVMCI must be enabled >>>> Improperly specified VM option 'UseJVMCICompiler' >>>> Error: Could not create the Java Virtual Machine. >>>> Error: A fatal exception has occurred. Program will exit. >>>> >>>> I think with your changes we will only see the first line without mentioning UseJVMCICompiler. Is that correct? >>>> >>>>> >>>>> Fix Summary: added jvmci flag consistency check after arg parsing. >>>>> >>>>> tests: jprt >>>>> unit test: command line verification >>>>> >>>>> Best Regards, >>>>> Jamsheed >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.c.berg at intel.com Fri Feb 12 22:11:48 2016 From: michael.c.berg at intel.com (Berg, Michael C) Date: Fri, 12 Feb 2016 22:11:48 +0000 Subject: CR for RFR 8149421 In-Reply-To: <56BCE02B.3070207@oracle.com> References: <56BC247B.7070409@oracle.com> <56BCCE2A.2010206@oracle.com> <56BCE02B.3070207@oracle.com> Message-ID: Vladimir, the change below is now logged on the jbs entry at: http://cr.openjdk.java.net/~mcberg/8149421/webrev.02/ Thanks, Michael -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, February 11, 2016 11:26 AM To: Berg, Michael C; hotspot-compiler-dev at openjdk.java.net Subject: Re: CR for RFR 8149421 yes, this is good Thanks, Vladimir On 2/11/16 10:36 AM, Berg, Michael C wrote: > Vladimir, how about this (from x86_assembler.hpp): > > InstructionAttr( > int vector_len, // The length of vector to be applied in encoding - for both AVX and EVEX > bool rex_vex_w, // Width of data: if 32-bits or less, false, else if 64-bit or specially defined, true > bool legacy_mode, // Details if either this instruction is conditionally encoded to AVX or earlier if true else possibly EVEX > bool no_reg_mask, // when true, k0 is used when EVEX encoding is chosen, else k1 is used under the same condition > bool uses_vl) // This instruction may have legacy constraints based on vector length for EVEX > > For documentation? > > Thanks, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, February 11, 2016 10:09 AM > To: Berg, Michael C; hotspot-compiler-dev at openjdk.java.net > Subject: Re: CR for RFR 8149421 > > On 2/11/16 9:55 AM, Berg, Michael C wrote: >> Yes, that is pretty close to it, the unrolled loop, after it initially succeeds as an atomic or unity unroll segment of one vector size is what I replicated to the drain loop, before super unrolling occurs. In fact, it's precisely what we need. > > Will you do more to improve it? > >> I migrated the ss/sd to insns k1 usage for uniformity reasons. You will notice some b and w SIMD components going the other way, that is preparatory, not a bug yet, but could have been if left, to use k0 which has all bits set for masking in the auto code generation path. The only exception is stub code, for which a webrev will soon be made available which has programmable versions of w and b components that do not fit in the auto code generation path, and for which k1 contents are left to the responsibility of the stub writer. The others insns are set to false like movdqu are in preparation for programmable SIMD, which will need to apply programmed masks into fix-up segments. Since programmable SIMD is for int/float, long/double sizes only there will be no conflict. Basically the w and b components do not have enough ISA mapping to complete more than very basic vector expressions, so we confine the usage model by idiom wrt masking and exclude them from programmable SIM! D. > > Please, add comments about this in InstructionAttr. And add comments to all fields of InstructionAttr - shortly describe them. It will help us in a future to set correct values. > > I may need to be educated about "programmable SIMD" :) > > Thanks, > Vladimir > >> >> Regards, >> Michael >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, February 10, 2016 10:05 PM >> To: hotspot-compiler-dev at openjdk.java.net >> Cc: Berg, Michael C >> Subject: Re: CR for RFR 8149421 >> >> What are the changes in assembler_x86.cpp? You changed no_mask_reg arguments value. Was it bug? >> >> Looks like you copy-paste code from insert_pre_post_loops() which is fine. >> One thing is worry me is that due to ratio of unrolling done before vectorization and vector size you can have several repetitive vector operations. It would be nice if we do unrolling equal vector size then do vectorization to generate one vector instruction, then clone to create vector_post_loop. And then unroll main more. >> Or you are already doing something like that? >> >> Thanks, >> Vladimir >> >> On 2/9/16 3:16 PM, Berg, Michael C wrote: >>> Hi Folks, >>> >>> I would like to contribute vectorized post loops. This patch is >>> initially targeted for x86. The design is versatile so as to be >>> portable to other targets as well. This code poses the addition of >>> atomic unrolled drain loops which precede fix-up segments and which >>> are significantly faster than scalar code. The requirement is that >>> the main loop is super unrolled after vectorization. I see up to 54% uplift on micro benchmarks on x86 targets for loops which pass superword vectorization and which meet the above criteria. Also scimark metrics in SpecJvm2008 like lu.small and fft.small show the usage of this design for benefit on x86. >>> >>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8149421 >>> >>> >>> webrev: >>> >>> http://cr.openjdk.java.net/~mcberg/8149421/webrev.01/ >>> >>> Thanks, >>> >>> Michael >>> From christian.thalinger at oracle.com Fri Feb 12 22:21:15 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 12 Feb 2016 12:21:15 -1000 Subject: [9] RFR 8149740: NPEs when executing some HotSpotConstantReflectionProvider with null args In-Reply-To: <56BDDC1E.8050406@oracle.com> References: <56BDDC1E.8050406@oracle.com> Message-ID: Looks good. > On Feb 12, 2016, at 3:20 AM, Konstantin Shefov wrote: > > Hello > > Please review a bug fix for jdk.vm.ci.hotspot.HotSpotConstantReflectionProvider methods. > > A NullPointerException is thrown, when one calls some methods of this calss with the argument equal to null. > > 1) readArrayLength(null); > 2) readArrayElement(null, someIndex); > 3) boxPrimitive(null); > 4) unboxPrimitive(null); > > According to javadoc of these methods, NPE should not be thrown in such cases. > > Additional check should be added for null as the first argument. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149740 > Webrev: http://cr.openjdk.java.net/~kshefov/8149740/webrev.00/ > > Thanks > -Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Fri Feb 12 23:12:11 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 13 Feb 2016 00:12:11 +0100 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <56BE133A.70508@oracle.com> References: <56B37387.2040204@oracle.com> <6CCE2F2C-1836-47CC-B13E-4371C2CE61FF@oracle.com> <56B4CE00.3040809@oracle.com> <56BE133A.70508@oracle.com> Message-ID: <56BE66CB.4080503@oracle.com> Hi, this seems OK to me, and I've verified that this gets octane performance back to 9-b102 levels across a number of platforms. Thanks! /Claes On 2016-02-12 18:15, Vladimir Ivanov wrote: > Any reviews, please? > > Best regards, > Vladimir Ivanov > > On 2/5/16 7:29 PM, Vladimir Ivanov wrote: >> Thanks, John. >> >> On 2/4/16 9:52 PM, John Rose wrote: >>> Looks good. Except I don't recall how is_inline interacts, if at all, >>> with customization. It's not clear what is being gated, and which >>> optimizations get let through. >> Inlining through MH::invokeBasic doesn't happen when there's @DontInline >> on the target. It is the case for GWT which has CountingWrapper on both >> paths. It starts with a reinvoker.dontInline LF and then switches to a >> reinvoker LF (after 30 invocations). If a compilation happens when >> reinvoker.dontInline is used, a direct call is generated and even if the >> branch becomes hot, all the calls goes through reinvoker.dontInline. >> Update to reinvoker LF isn't visible unless the dispatch goes through >> MH::invokeBasic linker. >> >> I had an impression that I introduced LF customization logic to the >> non-inlined case in GWT, but I can't find it in the code. So, it seems >> the regression is caused by repeated checks performed by >> reinvoker.dontInline LF and not by LF customization missed in generated >> code. >> >> Also, I stumbled upon a quirk in inlining policy: inlining through >> linkers can't be delayed. It happens when JIT hits some limit on IR >> size. So, right now inlining can stop in the middle of MH chain and a >> linker call is generated. >> >> But after JDK-8072008 there's no problem with delaying inlining. C2 can >> decide whether to keep the direct call or inline through it. So, I >> enabled late inlining for all linkers. (Surprisingly, no significant >> performance difference on nashorn.) >> >> So, I decided to keep invokeBasic linker call replacement for now, but >> piggypack LF customization on the stuck counting LF. >> >> Updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.01/hotspot >> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.01/jdk >> >> * enabled late inlining for linkers; >> * add LF customization check in CountingWrapper::countDown, so when >> counting is stuck, the target will be customized. >> >> Testing: octane, JPRT. >> >> I'm working on JDK-8071793 [1] and will reconsider how LF customization >> on non-inlined branch in GWTs works given there is a more JVM-friendly >> mechanism to control inlining. With the proposed fix >> reinvoker.dontInline is never customized (only the target it points to) >> and serves as a trampoline between GWT & target LF. It would be better >> to jump right to the customized LF, if non-inlined branch becomes hot. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8071793 >> "Prune rarely called invokedynamic call sites during inlining" >>> >>> Maybe a comment about that would be useful >>> Reviewed. >>> >>> ? John >>> >>>> On Feb 4, 2016, at 7:51 AM, Vladimir Ivanov >>>> wrote: >>>> >>>> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 >>>> https://bugs.openjdk.java.net/browse/JDK-8148994 >>>> >>>> JDK-8072008 [1] introduced an optimization to bypass linker calls in >>>> generated code when target method can't be inlined. >>>> >>>> Unfortunately, it doesn't work well with MH::invokeBasic(), because >>>> it clashes with LambdaForm customization: if a call is not inlined, >>>> it is important for performance to update (customize) corresponding >>>> LambdaForm on-the-fly. MH::invokeBasic() linker does MH -> LF -> >>>> Method* -> _from_compiled_entry traversal on every invocation, while >>>> direct call points right to the _from_compiled_entry. So, any >>>> LambdaForm updates aren't visible until recompilation. >>>> >>>> The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm >>>> instance is used on every invocation. >>>> >>>> Also, cleaned up relevant tests a bit. >>>> >>>> Testing: octane, JPRT. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8072008 >>>> "Emit direct call instead of linkTo* for recursive >>>> indy/MH.invoke* calls" From vladimir.kozlov at oracle.com Sat Feb 13 00:05:30 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Feb 2016 16:05:30 -0800 Subject: CR for RFR 8149421 In-Reply-To: References: <56BC247B.7070409@oracle.com> <56BCCE2A.2010206@oracle.com> <56BCE02B.3070207@oracle.com> Message-ID: <56BE734A.70403@oracle.com> Looks good. I will sponsor it. Thanks, Vladimir On 2/12/16 2:11 PM, Berg, Michael C wrote: > Vladimir, the change below is now logged on the jbs entry at: > > http://cr.openjdk.java.net/~mcberg/8149421/webrev.02/ > > Thanks, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, February 11, 2016 11:26 AM > To: Berg, Michael C; hotspot-compiler-dev at openjdk.java.net > Subject: Re: CR for RFR 8149421 > > yes, this is good > > Thanks, > Vladimir > > On 2/11/16 10:36 AM, Berg, Michael C wrote: >> Vladimir, how about this (from x86_assembler.hpp): >> >> InstructionAttr( >> int vector_len, // The length of vector to be applied in encoding - for both AVX and EVEX >> bool rex_vex_w, // Width of data: if 32-bits or less, false, else if 64-bit or specially defined, true >> bool legacy_mode, // Details if either this instruction is conditionally encoded to AVX or earlier if true else possibly EVEX >> bool no_reg_mask, // when true, k0 is used when EVEX encoding is chosen, else k1 is used under the same condition >> bool uses_vl) // This instruction may have legacy constraints based on vector length for EVEX >> >> For documentation? >> >> Thanks, >> Michael >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, February 11, 2016 10:09 AM >> To: Berg, Michael C; hotspot-compiler-dev at openjdk.java.net >> Subject: Re: CR for RFR 8149421 >> >> On 2/11/16 9:55 AM, Berg, Michael C wrote: >>> Yes, that is pretty close to it, the unrolled loop, after it initially succeeds as an atomic or unity unroll segment of one vector size is what I replicated to the drain loop, before super unrolling occurs. In fact, it's precisely what we need. >> >> Will you do more to improve it? >> >>> I migrated the ss/sd to insns k1 usage for uniformity reasons. You will notice some b and w SIMD components going the other way, that is preparatory, not a bug yet, but could have been if left, to use k0 which has all bits set for masking in the auto code generation path. The only exception is stub code, for which a webrev will soon be made available which has programmable versions of w and b components that do not fit in the auto code generation path, and for which k1 contents are left to the responsibility of the stub writer. The others insns are set to false like movdqu are in preparation for programmable SIMD, which will need to apply programmed masks into fix-up segments. Since programmable SIMD is for int/float, long/double sizes only there will be no conflict. Basically the w and b components do not have enough ISA mapping to complete more than very basic vector expressions, so we confine the usage model by idiom wrt masking and exclude them from programmable SI! M! > D. >> >> Please, add comments about this in InstructionAttr. And add comments to all fields of InstructionAttr - shortly describe them. It will help us in a future to set correct values. >> >> I may need to be educated about "programmable SIMD" :) >> >> Thanks, >> Vladimir >> >>> >>> Regards, >>> Michael >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Wednesday, February 10, 2016 10:05 PM >>> To: hotspot-compiler-dev at openjdk.java.net >>> Cc: Berg, Michael C >>> Subject: Re: CR for RFR 8149421 >>> >>> What are the changes in assembler_x86.cpp? You changed no_mask_reg arguments value. Was it bug? >>> >>> Looks like you copy-paste code from insert_pre_post_loops() which is fine. >>> One thing is worry me is that due to ratio of unrolling done before vectorization and vector size you can have several repetitive vector operations. It would be nice if we do unrolling equal vector size then do vectorization to generate one vector instruction, then clone to create vector_post_loop. And then unroll main more. >>> Or you are already doing something like that? >>> >>> Thanks, >>> Vladimir >>> >>> On 2/9/16 3:16 PM, Berg, Michael C wrote: >>>> Hi Folks, >>>> >>>> I would like to contribute vectorized post loops. This patch is >>>> initially targeted for x86. The design is versatile so as to be >>>> portable to other targets as well. This code poses the addition of >>>> atomic unrolled drain loops which precede fix-up segments and which >>>> are significantly faster than scalar code. The requirement is that >>>> the main loop is super unrolled after vectorization. I see up to 54% uplift on micro benchmarks on x86 targets for loops which pass superword vectorization and which meet the above criteria. Also scimark metrics in SpecJvm2008 like lu.small and fft.small show the usage of this design for benefit on x86. >>>> >>>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8149421 >>>> >>>> >>>> webrev: >>>> >>>> http://cr.openjdk.java.net/~mcberg/8149421/webrev.01/ >>>> >>>> Thanks, >>>> >>>> Michael >>>> From vladimir.kozlov at oracle.com Sat Feb 13 00:35:18 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Feb 2016 16:35:18 -0800 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56BE24A5.2060203@oracle.com> References: <56BE24A5.2060203@oracle.com> Message-ID: <56BE7A46.5060104@oracle.com> Hotspot changes looks good to me. Thanks, Vladimir On 2/12/16 10:29 AM, Vladimir Kempik wrote: > Hello > > Please review this backport of 8130150 to jdk8u. > > Implement BigInteger.montgomeryMultiply intrinsic > > The patch didn't apply cleanly, some changes were needed. Most of them are just to make patch apply, except one. > for MACC and MACC2 defines, __asm__ were changed to asm, to make solaris compiler (SS12U1) happy. > > The patch has two parts, for jdk and hotspot. > > Testing: jprt, testcase. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8130150 > Webrev:http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.00/ > > Thanks > -Vladimir > From vladimir.kozlov at oracle.com Sat Feb 13 00:37:00 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Feb 2016 16:37:00 -0800 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56BE24FA.3080100@oracle.com> References: <56BE24A5.2060203@oracle.com> <56BE24FA.3080100@oracle.com> Message-ID: <56BE7AAC.3060006@oracle.com> Looks fine but you need to send this to jdk8u-dev at openjdk.java.net to get approval for backport. Vladimir On 2/12/16 10:31 AM, Vladimir Kempik wrote: > Webrev for jdk part: > http://cr.openjdk.java.net/~vkempik/8130150/webrev_jdk.00/ > > > On 12.02.2016 21:29, Vladimir Kempik wrote: >> Hello >> >> Please review this backport of 8130150 to jdk8u. >> >> Implement BigInteger.montgomeryMultiply intrinsic >> >> The patch didn't apply cleanly, some changes were needed. Most of them are just to make patch apply, except one. >> for MACC and MACC2 defines, __asm__ were changed to asm, to make solaris compiler (SS12U1) happy. >> >> The patch has two parts, for jdk and hotspot. >> >> Testing: jprt, testcase. >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8130150 >> Webrev:http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.00/ >> >> Thanks >> -Vladimir > From john.r.rose at oracle.com Sat Feb 13 04:02:53 2016 From: john.r.rose at oracle.com (John Rose) Date: Fri, 12 Feb 2016 20:02:53 -0800 Subject: [9] RFR (S): 8148994: Replacing MH::invokeBasic with a direct call breaks LF customization In-Reply-To: <56BE133A.70508@oracle.com> References: <56B37387.2040204@oracle.com> <6CCE2F2C-1836-47CC-B13E-4371C2CE61FF@oracle.com> <56B4CE00.3040809@oracle.com> <56BE133A.70508@oracle.com> Message-ID: Better! You moved some inlining policy out of the VM and into the JDK runtime. Reviewed. Some loose brainstorming here: We are creating MH nodes that provide hints to the JIT inlining policy. The hint must vary over time as the profile evolves. The CMH does this indirectly via generating a @DontInline LF, with the LF patchable. Another way to do it would be to have a @Stable MH pointer initially null, but which would go non-null when an inlineable MH is determined. Another way would be to use a mutable CS. The handshake might need to include a "push" notification to the JIT that something has changed and recompilation should be attempted. The MCS can do this. Or perhaps the push should happen after some sort of further countdown. ? John > On Feb 12, 2016, at 9:15 AM, Vladimir Ivanov wrote: > > Any reviews, please? > > Best regards, > Vladimir Ivanov > > On 2/5/16 7:29 PM, Vladimir Ivanov wrote: >> Thanks, John. >> >> On 2/4/16 9:52 PM, John Rose wrote: >>> Looks good. Except I don't recall how is_inline interacts, if at all, >>> with customization. It's not clear what is being gated, and which >>> optimizations get let through. >> Inlining through MH::invokeBasic doesn't happen when there's @DontInline >> on the target. It is the case for GWT which has CountingWrapper on both >> paths. It starts with a reinvoker.dontInline LF and then switches to a >> reinvoker LF (after 30 invocations). If a compilation happens when >> reinvoker.dontInline is used, a direct call is generated and even if the >> branch becomes hot, all the calls goes through reinvoker.dontInline. >> Update to reinvoker LF isn't visible unless the dispatch goes through >> MH::invokeBasic linker. >> >> I had an impression that I introduced LF customization logic to the >> non-inlined case in GWT, but I can't find it in the code. So, it seems >> the regression is caused by repeated checks performed by >> reinvoker.dontInline LF and not by LF customization missed in generated >> code. >> >> Also, I stumbled upon a quirk in inlining policy: inlining through >> linkers can't be delayed. It happens when JIT hits some limit on IR >> size. So, right now inlining can stop in the middle of MH chain and a >> linker call is generated. >> >> But after JDK-8072008 there's no problem with delaying inlining. C2 can >> decide whether to keep the direct call or inline through it. So, I >> enabled late inlining for all linkers. (Surprisingly, no significant >> performance difference on nashorn.) >> >> So, I decided to keep invokeBasic linker call replacement for now, but >> piggypack LF customization on the stuck counting LF. >> >> Updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.01/hotspot >> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.01/jdk >> >> * enabled late inlining for linkers; >> * add LF customization check in CountingWrapper::countDown, so when >> counting is stuck, the target will be customized. >> >> Testing: octane, JPRT. >> >> I'm working on JDK-8071793 [1] and will reconsider how LF customization >> on non-inlined branch in GWTs works given there is a more JVM-friendly >> mechanism to control inlining. With the proposed fix >> reinvoker.dontInline is never customized (only the target it points to) >> and serves as a trampoline between GWT & target LF. It would be better >> to jump right to the customized LF, if non-inlined branch becomes hot. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8071793 >> "Prune rarely called invokedynamic call sites during inlining" >>> >>> Maybe a comment about that would be useful >>> Reviewed. >>> >>> ? John >>> >>>> On Feb 4, 2016, at 7:51 AM, Vladimir Ivanov >>>> wrote: >>>> >>>> http://cr.openjdk.java.net/~vlivanov/8148994/webrev.00 >>>> https://bugs.openjdk.java.net/browse/JDK-8148994 >>>> >>>> JDK-8072008 [1] introduced an optimization to bypass linker calls in >>>> generated code when target method can't be inlined. >>>> >>>> Unfortunately, it doesn't work well with MH::invokeBasic(), because >>>> it clashes with LambdaForm customization: if a call is not inlined, >>>> it is important for performance to update (customize) corresponding >>>> LambdaForm on-the-fly. MH::invokeBasic() linker does MH -> LF -> >>>> Method* -> _from_compiled_entry traversal on every invocation, while >>>> direct call points right to the _from_compiled_entry. So, any >>>> LambdaForm updates aren't visible until recompilation. >>>> >>>> The fix is to keep MH::invokeBasic linker, so up-to-date LambdaForm >>>> instance is used on every invocation. >>>> >>>> Also, cleaned up relevant tests a bit. >>>> >>>> Testing: octane, JPRT. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8072008 >>>> "Emit direct call instead of linkTo* for recursive >>>> indy/MH.invoke* calls" From kirk at kodewerk.com Sun Feb 14 18:58:34 2016 From: kirk at kodewerk.com (kirk at kodewerk.com) Date: Sun, 14 Feb 2016 19:58:34 +0100 Subject: WE'RE HIRING: Beta testers for the new hotspot build system! In-Reply-To: <3B88FEE2-FEC5-47BA-91C6-C200C6342C8F@oracle.com> References: <3B88FEE2-FEC5-47BA-91C6-C200C6342C8F@oracle.com> Message-ID: <070826EE-D602-4E31-B2C6-0F9D22BAE959@kodewerk.com> Hi Magnus, I?ve tried this new build process on my Mac (OSX 10.11.3 with all latest patches, xcode 7.2.1 with all latest patches) and I get this error. configure: error: Could not find freetype! /Users/kirk/Projects/OpenJDK/build-infra-jdk9/common/autoconf/generated-configure.sh: line 82: 5: Bad file descriptor configure exiting with result code 1 freetype is on my machine. I also went and rebuilt freetype version 6.3.2 (configure, make, sudo make install). It all seemed to end well but the build still failed with the same message. I?ve not dug deeper as of yet. I have logs from the freetype build and I?ve turned on tracing in the configure script (set -xv). It?s a lot of output so I?ll only send it if you?re interested in taking a peek. Kind regards, Kirk Pepperdine > On Feb 12, 2016, at 12:42 PM, Magnus Ihse Bursie wrote: > > ... or, well, more to the truth, we're *not* hiring. At least not in the sense that we'll pay you money. But we do want beta testers anyway! :-) Your reward will be a new build system that will work on the systems and configurations you care about, right out of the box, and a fuzzy warm feeling. > > A document that describes how to try out the new build system, and that answers many questions that you might have, is here: > > http://cr.openjdk.java.net/~ihse/docs/new-hotspot-build.html > > The TL;DR: > Clone the project forest. > > hg clone http://hg.openjdk.java.net/build-infra/jdk9 build-infra-jdk9 > cd build-infra-jdk9 && bash get_source.sh [additional closed url] > The build infra project is constantly on the move. The safest way to get to a working state is by using a tag, e.g. build-infra-beta-01. > > bash common/bin/hgforest.sh update -r build-infra-beta-01 > Build it. This works just as the with old build. > > bash configure && make > If you have questions or want to report bugs or enhancement requests, please direct them to the build-infra project list build-infra-dev at openjdk.java.net . Note that this is different from the Build Group mailing list build-dev at openjdk.java.net . > > Before asking questions, please check http://cr.openjdk.java.net/~ihse/docs/new-hotspot-build.html to see if they have been answered there first. > > /Magnus > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From roland.westrelin at oracle.com Mon Feb 15 08:19:55 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 15 Feb 2016 09:19:55 +0100 Subject: RFR(XS): 8149543: range check CastII nodes should not be split through Phi In-Reply-To: <56BE3A10.9030402@oracle.com> References: <56BB7919.1060900@oracle.com> <85C8E279-8EB9-434B-9F27-BA7CB1FEBACA@oracle.com> <56BE3A10.9030402@oracle.com> Message-ID: Thanks Vladimir and Michael for the reviews. Roland. From rahul.v.raghavan at oracle.com Mon Feb 15 08:52:10 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 15 Feb 2016 00:52:10 -0800 (PST) Subject: RFR(S): 6378256: Performance problem with System.identityHashCode in client compiler In-Reply-To: <907A99AD-0BA9-469B-B8E6-D2253F95C068@oracle.com> References: <7B6F2230-90B3-4BF2-8EBA-CF4B58FCE5BB@oracle.com> <8cecd05b-37b5-4cc7-b3f1-d8fa7ca027a8@default> <907A99AD-0BA9-469B-B8E6-D2253F95C068@oracle.com> Message-ID: <9108388b-c080-4bda-ad5d-e177c396a988@default> Hi, Yes, Thank you for the points Roland. Changes and testing done. Latest webrev for review: http://cr.openjdk.java.net/~thartmann/6378256/webrev.05/ Thanks, Rahul > -----Original Message----- > From: Roland Westrelin > Sent: Thursday, February 11, 2016 7:50 PM > To: Rahul Raghavan > Cc: hotspot-compiler-dev at openjdk.java.net > > Hi Rahul, > > > webrev: http://cr.openjdk.java.net/~thartmann/6378256/webrev.04/ > > Thanks for the updated webrev. > > It would be better if he declaration of inline_check_hashcode_from_object_header() is private. When it?s called: > > SharedRuntime::inline_check_hashcode_from_object_header() > > SharedRuntime:: is useless: > > inline_check_hashcode_from_object_header() > > is sufficient. > > Roland. > > > > > New changes done here are - > > i. added new inline_check_hashcode_from_object_header() in SharedRuntime class [sharedRuntime.hpp] guarded with 'X86 && > COMPILER1' > > ii. required comment text justification done. > > > > Confirmed no issues with jprt testing (-testset hotspot) and unit tests. > > > > Thank you, > > Rahul > > > >> -----Original Message----- > >> From: Roland Westrelin > Sent: Monday, February 08, 2016 11:00 PM > To: Rahul Raghavan > Cc: hotspot-compiler- > dev at openjdk.java.net > >> > >> Hi Rahul, > >> > >>> Please review revised patch, notes for JDK-6378256. > >>> https://bugs.openjdk.java.net/browse/JDK-6378256 > >>> > >>> > >>> Latest webrev-03: http://cr.openjdk.java.net/~thartmann/6378256/webrev.03/ > >> > >> Thanks for making the change. I would say it?s better to add inline_check_hashcode_from_object_header() to sharedRuntime.hpp > >> with #ifdef X86 rather than have the inline declaration. Not sure what others think. > >> > >>>>> Can you justify the comments again? > >> > >> I meant justify as text justification that is right align that comment: > >> > >> 36 // --------------------------------------------------------------------------- > >> 37 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word > >> 38 // instead of doing a full VM transition once it's been computed. > >> 39 // Since hashCode is usually polymorphic at call sites we can't do > >> 40 // this optimization at the call site without a lot of work. > >> > >> and that comment > >> > >> 2019 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word > >> 2020 // instead of doing a full VM transition once it's been computed. > >> 2021 // Since hashCode is usually polymorphic at call sites we can't do > >> 2022 // this optimization at the call site without a lot of work. > >> > >> Sorry for the confusion. The code looks good to me/ > >> > >> Roland. > >> > >> > From roland.westrelin at oracle.com Mon Feb 15 09:09:34 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 15 Feb 2016 10:09:34 +0100 Subject: RFR(S): 8149745: C2 should optimize long accumulations in a counted loop In-Reply-To: <56BE3001.2010007@oracle.com> References: <56BE3001.2010007@oracle.com> Message-ID: <1BB13E3F-B7C7-4361-B44D-5EEA35ADD69B@oracle.com> Thanks for looking at this, Vladimir. Here is a new webrev: http://cr.openjdk.java.net/~roland/8149745/webrev.01/ > incr2->Opcode() is called several time now but it is virtual method. Can you put it in local variable? Done. > Add assert before next line assert(opc == Op_AddI || opc == Op_AddL > + BasicType bt = incr2->Opcode() == Op_AddI ? T_INT : T_LONG; Done. > May need to add cast (jlong)stride2->get_int() to make all CC happy: > jlong stride_con2 = (bt == T_INT) ? stride2->get_int() : stride2->get_long(); Done. > You need to add new ConvI2LNode(init2) in case bt == T_LONG: > > Node* diff = SubNode::make(bt, init2, ratio_init); I don?t think it?s required. init2 is an input to the Phi of type long when bt == T_LONG. Roland. > > Otherwise this looks good. > > Thanks, > Vlaidmir > > On 2/12/16 7:53 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8149745/webrev.00/ >> >> This extends the code that looks for a parallel induction variable to long accumulations so in the following code: >> >> public static long testLongAcc() { >> long acc = 0; >> >> for (int i = 0; i < 1000; i++) { >> acc += 8; >> } >> >> return acc; >> } >> >> the loop is optimized out. >> >> What I find puzzling is that code for integer accumulations doesn?t try to estimate the benefit of turning one AddI into a more expensive MulI + AddI. Maybe it?s too unpredictable but in the case of the long accumulations would we want to check that, for instance, the long Phi has no use in the loop? >> >> Roland. >> >> From tobias.hartmann at oracle.com Mon Feb 15 09:17:31 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 15 Feb 2016 10:17:31 +0100 Subject: [8u] Request for approval: Backport of 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException Message-ID: <56C197AB.3050208@oracle.com> Hi, please approve and review the following backport to 8u. 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException https://bugs.openjdk.java.net/browse/JDK-8148752 http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021176.html http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4130663a3de8 The fix was pushed to hs-comp last week and nightly testing showed no problems. Thanks, Tobias From roland.westrelin at oracle.com Mon Feb 15 09:21:43 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 15 Feb 2016 10:21:43 +0100 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: <56BE3612.4080305@oracle.com> References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> <56BDB707.6090409@redhat.com> <8339FB73-9C21-4513-B07B-5DEBB8583188@oracle.com> <56BE3612.4080305@oracle.com> Message-ID: > Can you create new webrev which includes everything (aarch64)? Here it is: http://cr.openjdk.java.net/~roland/8087341/webrev.01/ Roland. > And I am satisfied with your answers to my objections. > > Thanks, > Vladimir > > On 2/12/16 4:36 AM, Roland Westrelin wrote: >> Hi Andrew, >> >>> A patch for the AArch64 C2 volatile/CAS generation code which deals with >>> the effects of your proposed C2 patch is available as a webrev >>> >>> http://cr.openjdk.java.net/~adinn/8087341-aarch64/webrev.00/ >> >> Thanks for putting that together. I didn?t expect that simple change to cause so much trouble. >> >>> n.b. I have /not/ created a separate issue for the AArch64 part of this >>> fix. I am not sure whether you want to combine it with your patch or >>> push it as a separate stage. >> >> I can push everything together and list you as a contributor (in the contributed-by field) if that works for you. >> >> Vladimir, can you take another look at this? Your two objections were: >> >>> Also we have specialized insert_mem_bar_volatile() if we don't want wide memory affect. Why not use it? >> >> The membar in the change takes the entire memory state as input but only changes raw memory. I don?t think that can be achieved with insert_mem_bar_volatile(). As explained by Mikael, the membar is here to force ordering between the oop store and the card table load. That?s why I think the membar?s inputs and outputs should be set up that way. >> >>> And we need to keep precedent edge link to oop store in case EA eliminates related allocation. >> >> Mikael said it?s not ok to eliminate the memory barrier if we leave the gc barrier. >> >> Roland. >> From roland.westrelin at oracle.com Mon Feb 15 09:23:32 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 15 Feb 2016 10:23:32 +0100 Subject: RFR(S): 6378256: Performance problem with System.identityHashCode in client compiler In-Reply-To: <9108388b-c080-4bda-ad5d-e177c396a988@default> References: <7B6F2230-90B3-4BF2-8EBA-CF4B58FCE5BB@oracle.com> <8cecd05b-37b5-4cc7-b3f1-d8fa7ca027a8@default> <907A99AD-0BA9-469B-B8E6-D2253F95C068@oracle.com> <9108388b-c080-4bda-ad5d-e177c396a988@default> Message-ID: <737FC3D9-B441-46A1-8595-24155D7D26F8@oracle.com> > Changes and testing done. Thanks. > Latest webrev for review: http://cr.openjdk.java.net/~thartmann/6378256/webrev.05/ That looks good to me. Roland. From sean.coffey at oracle.com Mon Feb 15 09:36:21 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 15 Feb 2016 09:36:21 +0000 Subject: [8u] Request for approval: Backport of 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56C197AB.3050208@oracle.com> References: <56C197AB.3050208@oracle.com> Message-ID: <56C19C15.5030205@oracle.com> Approved. Regards, Sean. On 15/02/2016 09:17, Tobias Hartmann wrote: > Hi, > > please approve and review the following backport to 8u. > > 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException > https://bugs.openjdk.java.net/browse/JDK-8148752 > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021176.html > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4130663a3de8 > > The fix was pushed to hs-comp last week and nightly testing showed no problems. > > Thanks, > Tobias From rahul.v.raghavan at oracle.com Mon Feb 15 09:41:11 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 15 Feb 2016 01:41:11 -0800 (PST) Subject: RFR(S): 6378256: Performance problem with System.identityHashCode in client compiler In-Reply-To: <737FC3D9-B441-46A1-8595-24155D7D26F8@oracle.com> References: <7B6F2230-90B3-4BF2-8EBA-CF4B58FCE5BB@oracle.com> <8cecd05b-37b5-4cc7-b3f1-d8fa7ca027a8@default> <907A99AD-0BA9-469B-B8E6-D2253F95C068@oracle.com> <9108388b-c080-4bda-ad5d-e177c396a988@default> <737FC3D9-B441-46A1-8595-24155D7D26F8@oracle.com> Message-ID: Thank you Roland. > -----Original Message----- > From: Roland Westrelin > Sent: Monday, February 15, 2016 2:54 PM > To: Rahul Raghavan > Cc: hotspot-compiler-dev at openjdk.java.net > > > Changes and testing done. > > Thanks. > > > Latest webrev for review: http://cr.openjdk.java.net/~thartmann/6378256/webrev.05/ > > That looks good to me. > > Roland. > From roland.westrelin at oracle.com Mon Feb 15 09:58:53 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 15 Feb 2016 10:58:53 +0100 Subject: RFR(S): 8148786: xml.tranform fails on x86-64 Message-ID: <75A71E7B-0876-4296-AB34-E8BFB0EF2184@oracle.com> http://cr.openjdk.java.net/~roland/8148786/webrev.00/ During CCP, a change in the type of one of the input the counted loop exit?s CmpI should cause the type of the loop?s Phi to be recomputed. Otherwise, the loop?s Phi may end up with an incorrect type. Roland. From tobias.hartmann at oracle.com Mon Feb 15 10:38:15 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 15 Feb 2016 11:38:15 +0100 Subject: [8u] Request for approval: Backport of 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56C19C15.5030205@oracle.com> References: <56C197AB.3050208@oracle.com> <56C19C15.5030205@oracle.com> Message-ID: <56C1AA97.5020500@oracle.com> Thanks, Sean. Best, Tobias On 15.02.2016 10:36, Se?n Coffey wrote: > Approved. > > Regards, > Sean. > > On 15/02/2016 09:17, Tobias Hartmann wrote: >> Hi, >> >> please approve and review the following backport to 8u. >> >> 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException >> https://bugs.openjdk.java.net/browse/JDK-8148752 >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021176.html >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4130663a3de8 >> >> The fix was pushed to hs-comp last week and nightly testing showed no problems. >> >> Thanks, >> Tobias > From adinn at redhat.com Mon Feb 15 11:08:07 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 15 Feb 2016 11:08:07 +0000 Subject: [aarch64-port-dev ] RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> <56BDB707.6090409@redhat.com> <8339FB73-9C21-4513-B07B-5DEBB8583188@oracle.com> <56BE3612.4080305@oracle.com> Message-ID: <56C1B197.7060708@redhat.com> On 15/02/16 09:21, Roland Westrelin wrote: > >> Can you create new webrev which includes everything (aarch64)? > > Here it is: > http://cr.openjdk.java.net/~roland/8087341/webrev.01/ Thanks Roland. Looks good to go. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From vladimir.kempik at oracle.com Mon Feb 15 13:06:24 2016 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Mon, 15 Feb 2016 16:06:24 +0300 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56BE7A46.5060104@oracle.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> Message-ID: <56C1CD50.3010100@oracle.com> Hello Sorry I spoke too soon last friday. Not all tests pass. On solaris x64 the testcase fails, also BigIntegerTest and ModPow65537 tests failed. I've changed asm to asm volatile for MACC and MACC2 and tried solaris x64 again. Now the testcase pass, ModPow65537 pass. BigIntegerTest still fails, but only partially: java BigIntegerTest Mersenne prime 3 failed. Mersenne prime 4 failed. Mersenne prime 5 failed. Mersenne prime 6 failed. Prime: Failed(4) nextProbablePrime: Passed Arithmetic I for 100 bits: Passed Arithmetic II for 100 bits: Passed Arithmetic I for 2760 bits: Passed ..... Do you have a clue what else could be missing for solaris x64? Is asm volatile safe for MACC and MACC2 or better to keep it volatile only for solaris x64? Thanks, Vladimir. On 13.02.2016 3:35, Vladimir Kozlov wrote: > Hotspot changes looks good to me. > > Thanks, > Vladimir > > On 2/12/16 10:29 AM, Vladimir Kempik wrote: >> Hello >> >> Please review this backport of 8130150 to jdk8u. >> >> Implement BigInteger.montgomeryMultiply intrinsic >> >> The patch didn't apply cleanly, some changes were needed. Most of >> them are just to make patch apply, except one. >> for MACC and MACC2 defines, __asm__ were changed to asm, to make >> solaris compiler (SS12U1) happy. >> >> The patch has two parts, for jdk and hotspot. >> >> Testing: jprt, testcase. >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8130150 >> Webrev:http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.00/ >> >> Thanks >> -Vladimir >> From aleksey.shipilev at oracle.com Mon Feb 15 13:17:33 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 15 Feb 2016 16:17:33 +0300 Subject: RFR (S) 8149813: Move trusted final field handling from C2 LoadNode::Value to shared code Message-ID: <56C1CFED.9080202@oracle.com> Hi, I would like us to consider moving out the "trusted fields" logic from C2-ish LoadNode::Value to a shared code: https://bugs.openjdk.java.net/browse/JDK-8149813 Webrev: http://cr.openjdk.java.net/~shade/8149813/webrev.00/ With this patch, primitive boxes and Strings are handled in the shared code, where all other special cases are listed. Not only this is cleaner, it also lets C1 to constant fold those cases too: http://cr.openjdk.java.net/~shade/8149813/notes.txt Some changes were neede in StringOpts, because it used to rely on constant oop present in a graph after LoadNode::Value -- which was inconsistent with the way we pull get_constant_coder anyway. Testing: JPRT -testset hotspot, microbenchmarks, eyeballing assembly Cheers, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Mon Feb 15 13:27:45 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 15 Feb 2016 14:27:45 +0100 Subject: RFR (S) 8149813: Move trusted final field handling from C2 LoadNode::Value to shared code In-Reply-To: <56C1CFED.9080202@oracle.com> References: <56C1CFED.9080202@oracle.com> Message-ID: <56C1D251.9020804@oracle.com> Hi Aleksey, this looks good to me (not a reviewer). Thanks for cleaning up string opts! Best, Tobias On 15.02.2016 14:17, Aleksey Shipilev wrote: > Hi, > > I would like us to consider moving out the "trusted fields" logic from > C2-ish LoadNode::Value to a shared code: > https://bugs.openjdk.java.net/browse/JDK-8149813 > > Webrev: > http://cr.openjdk.java.net/~shade/8149813/webrev.00/ > > With this patch, primitive boxes and Strings are handled in the shared > code, where all other special cases are listed. Not only this is > cleaner, it also lets C1 to constant fold those cases too: > http://cr.openjdk.java.net/~shade/8149813/notes.txt > > Some changes were neede in StringOpts, because it used to rely on > constant oop present in a graph after LoadNode::Value -- which was > inconsistent with the way we pull get_constant_coder anyway. > > Testing: JPRT -testset hotspot, microbenchmarks, eyeballing assembly > > Cheers, > -Aleksey > From roland.westrelin at oracle.com Mon Feb 15 14:19:47 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 15 Feb 2016 15:19:47 +0100 Subject: RFR(XS): 8149797: Compilation fails with "assert(in_hash) failed: node should be in igvn hash table" Message-ID: <873472A2-ABB7-4AF5-BE2C-A0EE511D8D90@oracle.com> http://cr.openjdk.java.net/~roland/8149797/webrev.00/ The code that looks for a dominating cast that is ?as good or better? finds a dead cast and uses it. Roland. From aph at redhat.com Mon Feb 15 14:21:58 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Feb 2016 14:21:58 +0000 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C1CD50.3010100@oracle.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> Message-ID: <56C1DF06.4090401@redhat.com> On 02/15/2016 01:06 PM, Vladimir Kempik wrote: > Do you have a clue what else could be missing for solaris x64? > Is asm volatile safe for MACC and MACC2 or better to keep it volatile > only for solaris x64? It really shouldn't matter, as long as all the inputs, outputs, and clobbers are correct. If "volatile" does make a difference, we're looking at a compiler bug. I've looked hard at the register and clobber lists in MACC and MACC2 and AFAICS they're fine. Maybe someone else should look too. One thing may be relevant: the asm in the "sub" function doesn't clobber "cc". I think it should. Andrew. From zoltan.majo at oracle.com Mon Feb 15 15:22:00 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 15 Feb 2016 16:22:00 +0100 Subject: [9] RFR (S): 8148754: C2 loop unrolling fails due to unexpected graph shape Message-ID: <56C1ED18.6060903@oracle.com> Hi, please review the patch for 8148754. https://bugs.openjdk.java.net/browse/JDK-8148754 Problem: Compilation fails when the C2 compiler attempts loop unrolling. The cause of the failure is that the loop unrolling optimization expects a well-defined graph shape at the entry control of a 'CountedLoopNode' ('IfTrue'/'IfFalse' preceeded by 'If' preceeded by 'Bool' preceeded by 'CmpI'). Solution: I investigated several different instances of the same failure. It turns out that the shape of the graph at a loop's entry control is often different from the way loop unrolling expects it to be (please find some examples in the bug's JBS issue). The various graph shapes are a result of previously performed transformations, e.g., split-if optimization and loop peeling. Loop unrolling requires the above mentioned graph shape so that it can adjust the zero-trip guard of the loop. With the unexpected graph shapes, it is not possible to perform loop unrolling. However, the graph is still in a valid state (except for loop unrolling) and can be used to produce correct code. I propose that (1) we check if an unexpected graph shape is encountered and (2) bail out of loop unrolling if it is (but not fail in the compiler in such cases). The failure was triggered by Aleksey's Indify String Concatenation changes but the generated bytecodes are valid. So this seems to be a compiler issue that was previously there but was not yet triggered. Webrev: http://cr.openjdk.java.net/~zmajo/8148754/webrev.00/ Testing: - JPRT; - local testing (linux-86_64) with the failing test case; - executed all hotspot tests locally, all tests pass that pass with an unmodified build. Thank you! Best regards, Zoltan From vladimir.x.ivanov at oracle.com Mon Feb 15 15:37:32 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 15 Feb 2016 18:37:32 +0300 Subject: On external_word_Relocation and StubCodeDesc Message-ID: <56C1F0BC.7090700@oracle.com> While working on JDK-8138922 [1], I noticed that StubCodeDesc::desc_for is called for every external address embedded in the code [2]. It is done to save some space on relocations (record an index in the stub list instead of full address). StubCodeDesc::desc_for does linear search over the list and there are around 100 stubs registered on x64. The problem is that the hit rate is very low. My experiments (on Octane [3]) show that there are thousands of requests with 0% hit rate. So, instead of speeding up the search (switch to array, sort it and do binary search to compute the index or lookup the address by index), I suggest to completely remove that logic and always record the address for external_word relocations. What's your take on that? Best regards, Vladimir Ivanov PS: there are some prospects in compacting some "well-known" addresses [4], but it seems stubs aren't good candidates for that. [1] https://bugs.openjdk.java.net/browse/JDK-8138922 http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-February/021702.html [2] hotspot/src/share/vm/code/relocInfo.cpp: void external_word_Relocation::pack_data_to(CodeSection* dest) { short* p = (short*) dest->locs_end(); int32_t index = runtime_address_to_index(_target); where runtime_address_to_index looks for the _target among stubs registered in StubCodeDescs::_list: int32_t Relocation::runtime_address_to_index(address runtime_address) { assert(!is_reloc_index((intptr_t)runtime_address), "must not look like an index"); if (runtime_address == NULL) return 0; StubCodeDesc* p = StubCodeDesc::desc_for(runtime_address); if (p != NULL && p->begin() == runtime_address) { assert(is_reloc_index(p->index()), "there must not be too many stubs"); return (int32_t)p->index(); [3] perf counters: sun.ci.stubCodeDesc::total_reqs=11788 sun.ci.stubCodeDesc::total_reqs_hit=0 sun.ci.stubCodeDesc::total_reqs=4117 sun.ci.stubCodeDesc::total_reqs_hit=0 sun.ci.stubCodeDesc::total_reqs=3270 sun.ci.stubCodeDesc::total_reqs_hit=0 sun.ci.stubCodeDesc::total_reqs=5183 sun.ci.stubCodeDesc::total_reqs_hit=0 sun.ci.stubCodeDesc::total_reqs=7001 sun.ci.stubCodeDesc::total_reqs_hit=0 sun.ci.stubCodeDesc::total_reqs=2909 sun.ci.stubCodeDesc::total_reqs_hit=0 sun.ci.stubCodeDesc::total_reqs=10335 sun.ci.stubCodeDesc::total_reqs_hit=0 sun.ci.stubCodeDesc::total_reqs=4698 sun.ci.stubCodeDesc::total_reqs_hit=0 sun.ci.stubCodeDesc::total_reqs=5059 sun.ci.stubCodeDesc::total_reqs_hit=0 sun.ci.stubCodeDesc::total_reqs=2763 sun.ci.stubCodeDesc::total_reqs_hit=0 sun.ci.stubCodeDesc::total_reqs=3035 sun.ci.stubCodeDesc::total_reqs_hit=0 sun.ci.stubCodeDesc::total_reqs=7244 sun.ci.stubCodeDesc::total_reqs_hit=0 [4] Box2D external addresses stats: 5628 0x0000000102601396 16 0x00000001027cba58 20 0x00000001027cba60 85 0x00000001027cc198 110 0x00000001027d82a2 55 0x00000001027ee720 351 0x00000001027eea80 9 0x0000000102814380 41 0x00000001028143a0 2 0x0000000103246460 3812 0x0000000103246480 From aleksey.shipilev at oracle.com Mon Feb 15 15:40:44 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 15 Feb 2016 18:40:44 +0300 Subject: [9] RFR (S): 8148754: C2 loop unrolling fails due to unexpected graph shape In-Reply-To: <56C1ED18.6060903@oracle.com> References: <56C1ED18.6060903@oracle.com> Message-ID: <56C1F17C.9080306@oracle.com> On 02/15/2016 06:22 PM, Zolt?n Maj? wrote: > The failure was triggered by Aleksey's Indify String Concatenation > changes but the generated bytecodes are valid. So this seems to be a > compiler issue that was previously there but was not yet triggered. Oh wow, but ISC does not do anything heavy (yet) -- the bytecode is the same as javac produces, except that we generate a separate method and then @ForceInline it through j.l.i.CallSite -- which puzzles me why ISC had triggered this. > Webrev: > http://cr.openjdk.java.net/~zmajo/8148754/webrev.00/ Anyhow, the explanation and the patch looks fine to me. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From doug.simon at oracle.com Mon Feb 15 15:44:26 2016 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 15 Feb 2016 16:44:26 +0100 Subject: [9] RFR (S): 8148754: C2 loop unrolling fails due to unexpected graph shape In-Reply-To: <56C1ED18.6060903@oracle.com> References: <56C1ED18.6060903@oracle.com> Message-ID: 1460 // cases, so give the attempt to unroll the loop (but still continue 1461 // compilation). is that meant to be ?so give up on the attempt?? > On 15 Feb 2016, at 16:22, Zolt?n Maj? wrote: > > Hi, > > > please review the patch for 8148754. > > https://bugs.openjdk.java.net/browse/JDK-8148754 > > Problem: Compilation fails when the C2 compiler attempts loop unrolling. The cause of the failure is that the loop unrolling optimization expects a well-defined graph shape at the entry control of a 'CountedLoopNode' ('IfTrue'/'IfFalse' preceeded by 'If' preceeded by 'Bool' preceeded by 'CmpI'). > > > Solution: I investigated several different instances of the same failure. It turns out that the shape of the graph at a loop's entry control is often different from the way loop unrolling expects it to be (please find some examples in the bug's JBS issue). The various graph shapes are a result of previously performed transformations, e.g., split-if optimization and loop peeling. > > Loop unrolling requires the above mentioned graph shape so that it can adjust the zero-trip guard of the loop. With the unexpected graph shapes, it is not possible to perform loop unrolling. However, the graph is still in a valid state (except for loop unrolling) and can be used to produce correct code. > > I propose that (1) we check if an unexpected graph shape is encountered and (2) bail out of loop unrolling if it is (but not fail in the compiler in such cases). > > The failure was triggered by Aleksey's Indify String Concatenation changes but the generated bytecodes are valid. So this seems to be a compiler issue that was previously there but was not yet triggered. > > > Webrev: > http://cr.openjdk.java.net/~zmajo/8148754/webrev.00/ > > Testing: > - JPRT; > - local testing (linux-86_64) with the failing test case; > - executed all hotspot tests locally, all tests pass that pass with an unmodified build. > > Thank you! > > Best regards, > > > Zoltan > From pavel.punegov at oracle.com Mon Feb 15 16:26:59 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Mon, 15 Feb 2016 19:26:59 +0300 Subject: RFR (XXS): 8144621: CompilerControl: inline tests timeout with Xcomp Message-ID: <4245B7A0-D8AA-4623-9F73-F794B00F15A6@oracle.com> Hi, please review this small fix for CompilerControl tests. Issue: tests that generate commands like "inline *.*" (-XX:CompileCommand or directives) with Xcomp make compilers forcibly inline everything. This significantly increases execution time leading to timeout. Fix: don?t generated *.* patterns at all for such tests. It will also makes tests that use PrintAssembly to not fail with OOME by decreasing of the amount of output. bug: https://bugs.openjdk.java.net/browse/JDK-8144621 webrev: http://cr.openjdk.java.net/~ppunegov/8144621/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Feb 15 16:41:58 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 08:41:58 -0800 Subject: RFR (XXS): 8144621: CompilerControl: inline tests timeout with Xcomp In-Reply-To: <4245B7A0-D8AA-4623-9F73-F794B00F15A6@oracle.com> References: <4245B7A0-D8AA-4623-9F73-F794B00F15A6@oracle.com> Message-ID: <56C1FFD6.2050708@oracle.com> Should we fix tests with *.* commands instead? Could you, please, list those tests (I want to look)? May be add -Xmixed if they don't like -Xcomp? Or use real method's names instead of *.*? Thanks, Vladimir On 2/15/16 8:26 AM, Pavel Punegov wrote: > Hi, > > please review this small fix for CompilerControl tests. > > Issue: tests that generate commands like "inline *.*" (-XX:CompileCommand or directives) with Xcomp make compilers > forcibly inline everything. This significantly increases execution time leading to timeout. > Fix: don?t generated *.* patterns at all for such tests. It will also makes tests that use PrintAssembly to not fail > with OOME by decreasing of the amount of output. > > bug: https://bugs.openjdk.java.net/browse/JDK-8144621 > webrev: http://cr.openjdk.java.net/~ppunegov/8144621/webrev.00/ From zoltan.majo at oracle.com Mon Feb 15 16:45:03 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 15 Feb 2016 17:45:03 +0100 Subject: [9] RFR (S): 8148754: C2 loop unrolling fails due to unexpected graph shape In-Reply-To: <56C1F17C.9080306@oracle.com> References: <56C1ED18.6060903@oracle.com> <56C1F17C.9080306@oracle.com> Message-ID: <56C2008F.20500@oracle.com> Hi Aleksey, thank you for the feedback! On 02/15/2016 04:40 PM, Aleksey Shipilev wrote: > On 02/15/2016 06:22 PM, Zolt?n Maj? wrote: >> The failure was triggered by Aleksey's Indify String Concatenation >> changes but the generated bytecodes are valid. So this seems to be a >> compiler issue that was previously there but was not yet triggered. > Oh wow, but ISC does not do anything heavy (yet) -- the bytecode is the > same as javac produces, except that we generate a separate method and > then @ForceInline it through j.l.i.CallSite -- which puzzles me why ISC > had triggered this. The failure started to appear in the compiler nightlies just after we have pulled down hs-main. There are lots of changes there and I cannot point to ISC as being the cause with 100% confidence. Sorry for the inaccuracy in my original text. However, a the pre-ISC build inlines a different set of methods than a post-ISC build when compiling IeeeRecommendedTests::testFloatBooleanMethods In the post-ISC build, two of the methods inlined into testFloatBooleanMethods() static jint Tests.test(jobject, jfloat, jint, jint) static jint Tests.test(jobject, jfloat, jdouble, jfloat, jfloat) contain invokedynamic calls to makeConcatWithConstants(). So, as I mentioned, I don't think ISC is at fault here as the bytecodes look fine to me. But maybe the body/annotation of some inlined methods has slightly changed due to ISC. As a result, inlining is performed differently, which, I suspect, results in the bug being triggered. One would have to investigate further to confirm/disprove the above hypothesis. Best regards, Zoltan > >> Webrev: >> http://cr.openjdk.java.net/~zmajo/8148754/webrev.00/ > Anyhow, the explanation and the patch looks fine to me. > > -Aleksey > > From zoltan.majo at oracle.com Mon Feb 15 16:48:24 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 15 Feb 2016 17:48:24 +0100 Subject: [9] RFR (S): 8148754: C2 loop unrolling fails due to unexpected graph shape In-Reply-To: References: <56C1ED18.6060903@oracle.com> Message-ID: <56C20158.3090104@oracle.com> Hi Doug, On 02/15/2016 04:44 PM, Doug Simon wrote: > 1460 // cases, so give the attempt to unroll the loop (but still continue > 1461 // compilation). > > is that meant to be ?so give up on the attempt?? yes, that is what I meant. This is what happens when re-editing the text and forgetting to re-read the complete sentence. Thank you for catching the mistake! Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8148754/webrev.01/ Best regards, Zoltan > >> On 15 Feb 2016, at 16:22, Zolt?n Maj? wrote: >> >> Hi, >> >> >> please review the patch for 8148754. >> >> https://bugs.openjdk.java.net/browse/JDK-8148754 >> >> Problem: Compilation fails when the C2 compiler attempts loop unrolling. The cause of the failure is that the loop unrolling optimization expects a well-defined graph shape at the entry control of a 'CountedLoopNode' ('IfTrue'/'IfFalse' preceeded by 'If' preceeded by 'Bool' preceeded by 'CmpI'). >> >> >> Solution: I investigated several different instances of the same failure. It turns out that the shape of the graph at a loop's entry control is often different from the way loop unrolling expects it to be (please find some examples in the bug's JBS issue). The various graph shapes are a result of previously performed transformations, e.g., split-if optimization and loop peeling. >> >> Loop unrolling requires the above mentioned graph shape so that it can adjust the zero-trip guard of the loop. With the unexpected graph shapes, it is not possible to perform loop unrolling. However, the graph is still in a valid state (except for loop unrolling) and can be used to produce correct code. >> >> I propose that (1) we check if an unexpected graph shape is encountered and (2) bail out of loop unrolling if it is (but not fail in the compiler in such cases). >> >> The failure was triggered by Aleksey's Indify String Concatenation changes but the generated bytecodes are valid. So this seems to be a compiler issue that was previously there but was not yet triggered. >> >> >> Webrev: >> http://cr.openjdk.java.net/~zmajo/8148754/webrev.00/ >> >> Testing: >> - JPRT; >> - local testing (linux-86_64) with the failing test case; >> - executed all hotspot tests locally, all tests pass that pass with an unmodified build. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> From vladimir.kozlov at oracle.com Mon Feb 15 17:04:54 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 09:04:54 -0800 Subject: RFR(XS): 8149797: Compilation fails with "assert(in_hash) failed: node should be in igvn hash table" In-Reply-To: <873472A2-ABB7-4AF5-BE2C-A0EE511D8D90@oracle.com> References: <873472A2-ABB7-4AF5-BE2C-A0EE511D8D90@oracle.com> Message-ID: <56C20536.2000507@oracle.com> Good. Thanks, Vladimir On 2/15/16 6:19 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8149797/webrev.00/ > > The code that looks for a dominating cast that is ?as good or better? finds a dead cast and uses it. > > Roland. > From roland.westrelin at oracle.com Mon Feb 15 17:07:00 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 15 Feb 2016 18:07:00 +0100 Subject: RFR(XS): 8149797: Compilation fails with "assert(in_hash) failed: node should be in igvn hash table" In-Reply-To: <56C20536.2000507@oracle.com> References: <873472A2-ABB7-4AF5-BE2C-A0EE511D8D90@oracle.com> <56C20536.2000507@oracle.com> Message-ID: <78112E07-78A6-491D-A38A-0AA695C20298@oracle.com> Thanks for the review. Roland. > On Feb 15, 2016, at 6:04 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 2/15/16 6:19 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8149797/webrev.00/ >> >> The code that looks for a dominating cast that is ?as good or better? finds a dead cast and uses it. >> >> Roland. >> From vladimir.kozlov at oracle.com Mon Feb 15 17:13:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 09:13:05 -0800 Subject: [8u] Request for approval: Backport of 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56C197AB.3050208@oracle.com> References: <56C197AB.3050208@oracle.com> Message-ID: <56C20721.5020001@oracle.com> Looks good. Thanks, Vladimir On 2/15/16 1:17 AM, Tobias Hartmann wrote: > Hi, > > please approve and review the following backport to 8u. > > 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException > https://bugs.openjdk.java.net/browse/JDK-8148752 > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021176.html > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4130663a3de8 > > The fix was pushed to hs-comp last week and nightly testing showed no problems. > > Thanks, > Tobias > From vladimir.kozlov at oracle.com Mon Feb 15 17:20:15 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 09:20:15 -0800 Subject: RFR(S): 8148786: xml.tranform fails on x86-64 In-Reply-To: <75A71E7B-0876-4296-AB34-E8BFB0EF2184@oracle.com> References: <75A71E7B-0876-4296-AB34-E8BFB0EF2184@oracle.com> Message-ID: <56C208CF.1010700@oracle.com> CmpI and Bool nodes could have several users (your code is looking on first one only). Should we go through all uses and if they different counted loops put their Phi on worklist? Thanks, Vladimir On 2/15/16 1:58 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8148786/webrev.00/ > > During CCP, a change in the type of one of the input the counted loop exit?s CmpI should cause the type of the loop?s Phi to be recomputed. Otherwise, the loop?s Phi may end up with an incorrect type. > > Roland. > From vladimir.kozlov at oracle.com Mon Feb 15 17:26:32 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 09:26:32 -0800 Subject: RFR(S): 8149745: C2 should optimize long accumulations in a counted loop In-Reply-To: <1BB13E3F-B7C7-4361-B44D-5EEA35ADD69B@oracle.com> References: <56BE3001.2010007@oracle.com> <1BB13E3F-B7C7-4361-B44D-5EEA35ADD69B@oracle.com> Message-ID: <56C20A48.8010105@oracle.com> Looks good. You are right about init2. Thanks, Vladimir On 2/15/16 1:09 AM, Roland Westrelin wrote: > Thanks for looking at this, Vladimir. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8149745/webrev.01/ > >> incr2->Opcode() is called several time now but it is virtual method. Can you put it in local variable? > > Done. > >> Add assert before next line assert(opc == Op_AddI || opc == Op_AddL >> + BasicType bt = incr2->Opcode() == Op_AddI ? T_INT : T_LONG; > > Done. > >> May need to add cast (jlong)stride2->get_int() to make all CC happy: >> jlong stride_con2 = (bt == T_INT) ? stride2->get_int() : stride2->get_long(); > > Done. > >> You need to add new ConvI2LNode(init2) in case bt == T_LONG: >> >> Node* diff = SubNode::make(bt, init2, ratio_init); > > I don?t think it?s required. init2 is an input to the Phi of type long when bt == T_LONG. > > Roland. > >> >> Otherwise this looks good. >> >> Thanks, >> Vlaidmir >> >> On 2/12/16 7:53 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8149745/webrev.00/ >>> >>> This extends the code that looks for a parallel induction variable to long accumulations so in the following code: >>> >>> public static long testLongAcc() { >>> long acc = 0; >>> >>> for (int i = 0; i < 1000; i++) { >>> acc += 8; >>> } >>> >>> return acc; >>> } >>> >>> the loop is optimized out. >>> >>> What I find puzzling is that code for integer accumulations doesn?t try to estimate the benefit of turning one AddI into a more expensive MulI + AddI. Maybe it?s too unpredictable but in the case of the long accumulations would we want to check that, for instance, the long Phi has no use in the loop? >>> >>> Roland. >>> >>> > From vladimir.kozlov at oracle.com Mon Feb 15 17:33:08 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 09:33:08 -0800 Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1 In-Reply-To: References: <56AA260B.8080101@redhat.com> <434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com> <56BB01E2.2090004@redhat.com> <9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com> <56BDB707.6090409@redhat.com> <8339FB73-9C21-4513-B07B-5DEBB8583188@oracle.com> <56BE3612.4080305@oracle.com> Message-ID: <56C20BD4.8030800@oracle.com> Good. Thank you. Vladimir On 2/15/16 1:21 AM, Roland Westrelin wrote: > >> Can you create new webrev which includes everything (aarch64)? > > Here it is: > http://cr.openjdk.java.net/~roland/8087341/webrev.01/ > > Roland. > >> And I am satisfied with your answers to my objections. >> >> Thanks, >> Vladimir >> >> On 2/12/16 4:36 AM, Roland Westrelin wrote: >>> Hi Andrew, >>> >>>> A patch for the AArch64 C2 volatile/CAS generation code which deals with >>>> the effects of your proposed C2 patch is available as a webrev >>>> >>>> http://cr.openjdk.java.net/~adinn/8087341-aarch64/webrev.00/ >>> >>> Thanks for putting that together. I didn?t expect that simple change to cause so much trouble. >>> >>>> n.b. I have /not/ created a separate issue for the AArch64 part of this >>>> fix. I am not sure whether you want to combine it with your patch or >>>> push it as a separate stage. >>> >>> I can push everything together and list you as a contributor (in the contributed-by field) if that works for you. >>> >>> Vladimir, can you take another look at this? Your two objections were: >>> >>>> Also we have specialized insert_mem_bar_volatile() if we don't want wide memory affect. Why not use it? >>> >>> The membar in the change takes the entire memory state as input but only changes raw memory. I don?t think that can be achieved with insert_mem_bar_volatile(). As explained by Mikael, the membar is here to force ordering between the oop store and the card table load. That?s why I think the membar?s inputs and outputs should be set up that way. >>> >>>> And we need to keep precedent edge link to oop store in case EA eliminates related allocation. >>> >>> Mikael said it?s not ok to eliminate the memory barrier if we leave the gc barrier. >>> >>> Roland. >>> > From vladimir.x.ivanov at oracle.com Mon Feb 15 17:38:45 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 15 Feb 2016 20:38:45 +0300 Subject: RFR(S): 8149745: C2 should optimize long accumulations in a counted loop In-Reply-To: <1BB13E3F-B7C7-4361-B44D-5EEA35ADD69B@oracle.com> References: <56BE3001.2010007@oracle.com> <1BB13E3F-B7C7-4361-B44D-5EEA35ADD69B@oracle.com> Message-ID: <56C20D25.8030106@oracle.com> Roland, + Node* ratio_idx = MulINode::make(bt, conv_phi, ratio); A typo? Shouldn't MulNode::make be used? Best regards, Vladimir Ivanov On 2/15/16 12:09 PM, Roland Westrelin wrote: > Thanks for looking at this, Vladimir. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8149745/webrev.01/ > >> incr2->Opcode() is called several time now but it is virtual method. Can you put it in local variable? > > Done. > >> Add assert before next line assert(opc == Op_AddI || opc == Op_AddL >> + BasicType bt = incr2->Opcode() == Op_AddI ? T_INT : T_LONG; > > Done. > >> May need to add cast (jlong)stride2->get_int() to make all CC happy: >> jlong stride_con2 = (bt == T_INT) ? stride2->get_int() : stride2->get_long(); > > Done. > >> You need to add new ConvI2LNode(init2) in case bt == T_LONG: >> >> Node* diff = SubNode::make(bt, init2, ratio_init); > > I don?t think it?s required. init2 is an input to the Phi of type long when bt == T_LONG. > > Roland. > >> >> Otherwise this looks good. >> >> Thanks, >> Vlaidmir >> >> On 2/12/16 7:53 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8149745/webrev.00/ >>> >>> This extends the code that looks for a parallel induction variable to long accumulations so in the following code: >>> >>> public static long testLongAcc() { >>> long acc = 0; >>> >>> for (int i = 0; i < 1000; i++) { >>> acc += 8; >>> } >>> >>> return acc; >>> } >>> >>> the loop is optimized out. >>> >>> What I find puzzling is that code for integer accumulations doesn?t try to estimate the benefit of turning one AddI into a more expensive MulI + AddI. Maybe it?s too unpredictable but in the case of the long accumulations would we want to check that, for instance, the long Phi has no use in the loop? >>> >>> Roland. >>> >>> > From pavel.punegov at oracle.com Mon Feb 15 17:43:08 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Mon, 15 Feb 2016 20:43:08 +0300 Subject: RFR (XXS): 8144621: CompilerControl: inline tests timeout with Xcomp In-Reply-To: <56C1FFD6.2050708@oracle.com> References: <4245B7A0-D8AA-4623-9F73-F794B00F15A6@oracle.com> <56C1FFD6.2050708@oracle.com> Message-ID: <043BBA72-A4F2-40E6-80A9-05C670B7EABD@oracle.com> see inline > On 15 Feb 2016, at 19:41, Vladimir Kozlov wrote: > > Should we fix tests with *.* commands instead? Most tests generate their commands with the getValidMethodDescriptor() method. This fix makes it not use *.* patterns at all. If we found this pattern, the method returns a plain method name. > Could you, please, list those tests (I want to look)? compiler/compilercontrol/jcmd/PrintDirectivesTest.java compiler/compilercontrol/parser/DirectiveStressTest.java Closed inlining tests are also affected. As for PrintAssembly tests: compiler/compilercontrol/directives/PrintTest.java compiler/compilercontrol/commands/PrintTest.java but they suffer from the JDK-8140354 that is also caused by *.* with Xcomp. I plan to rewrite OutputAnalyzer to save output on disk. > May be add -Xmixed if they don't like -Xcomp? Well, this could be a fix, but then all inlining tests would be run only with Xmixed. > Or use real method's names instead of *.*? that the fix is about. > > Thanks, > Vladimir > > On 2/15/16 8:26 AM, Pavel Punegov wrote: >> Hi, >> >> please review this small fix for CompilerControl tests. >> >> Issue: tests that generate commands like "inline *.*" (-XX:CompileCommand or directives) with Xcomp make compilers >> forcibly inline everything. This significantly increases execution time leading to timeout. >> Fix: don?t generated *.* patterns at all for such tests. It will also makes tests that use PrintAssembly to not fail >> with OOME by decreasing of the amount of output. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8144621 >> webrev: http://cr.openjdk.java.net/~ppunegov/8144621/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Feb 15 18:14:27 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 10:14:27 -0800 Subject: RFR(S): 8149745: C2 should optimize long accumulations in a counted loop In-Reply-To: <56C20D25.8030106@oracle.com> References: <56BE3001.2010007@oracle.com> <1BB13E3F-B7C7-4361-B44D-5EEA35ADD69B@oracle.com> <56C20D25.8030106@oracle.com> Message-ID: <56C21583.9060200@oracle.com> That is why we need 2 reviews! :) Vladimir K On 2/15/16 9:38 AM, Vladimir Ivanov wrote: > Roland, > > + Node* ratio_idx = MulINode::make(bt, conv_phi, ratio); > > A typo? Shouldn't MulNode::make be used? > > Best regards, > Vladimir Ivanov > > On 2/15/16 12:09 PM, Roland Westrelin wrote: >> Thanks for looking at this, Vladimir. Here is a new webrev: >> >> http://cr.openjdk.java.net/~roland/8149745/webrev.01/ >> >>> incr2->Opcode() is called several time now but it is virtual method. Can you put it in local variable? >> >> Done. >> >>> Add assert before next line assert(opc == Op_AddI || opc == Op_AddL >>> + BasicType bt = incr2->Opcode() == Op_AddI ? T_INT : T_LONG; >> >> Done. >> >>> May need to add cast (jlong)stride2->get_int() to make all CC happy: >>> jlong stride_con2 = (bt == T_INT) ? stride2->get_int() : stride2->get_long(); >> >> Done. >> >>> You need to add new ConvI2LNode(init2) in case bt == T_LONG: >>> >>> Node* diff = SubNode::make(bt, init2, ratio_init); >> >> I don?t think it?s required. init2 is an input to the Phi of type long when bt == T_LONG. >> >> Roland. >> >>> >>> Otherwise this looks good. >>> >>> Thanks, >>> Vlaidmir >>> >>> On 2/12/16 7:53 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~roland/8149745/webrev.00/ >>>> >>>> This extends the code that looks for a parallel induction variable to long accumulations so in the following code: >>>> >>>> public static long testLongAcc() { >>>> long acc = 0; >>>> >>>> for (int i = 0; i < 1000; i++) { >>>> acc += 8; >>>> } >>>> >>>> return acc; >>>> } >>>> >>>> the loop is optimized out. >>>> >>>> What I find puzzling is that code for integer accumulations doesn?t try to estimate the benefit of turning one AddI >>>> into a more expensive MulI + AddI. Maybe it?s too unpredictable but in the case of the long accumulations would we >>>> want to check that, for instance, the long Phi has no use in the loop? >>>> >>>> Roland. >>>> >>>> >> From vladimir.kozlov at oracle.com Mon Feb 15 18:44:53 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 10:44:53 -0800 Subject: RFR (XXS): 8144621: CompilerControl: inline tests timeout with Xcomp In-Reply-To: <043BBA72-A4F2-40E6-80A9-05C670B7EABD@oracle.com> References: <4245B7A0-D8AA-4623-9F73-F794B00F15A6@oracle.com> <56C1FFD6.2050708@oracle.com> <043BBA72-A4F2-40E6-80A9-05C670B7EABD@oracle.com> Message-ID: <56C21CA5.8020908@oracle.com> Thank you, Pavel, now I understand the fix. Looks good. Vladimir On 2/15/16 9:43 AM, Pavel Punegov wrote: > see inline > >> On 15 Feb 2016, at 19:41, Vladimir Kozlov > wrote: >> >> Should we fix tests with *.* commands instead? > Most tests generate their commands with the getValidMethodDescriptor() method. This fix makes it not use *.* patterns at > all. If we found this pattern, the method returns a plain method name. > >> Could you, please, list those tests (I want to look)? > compiler/compilercontrol/jcmd/PrintDirectivesTest.java > compiler/compilercontrol/parser/DirectiveStressTest.java > Closed inlining tests are also affected. > > As for PrintAssembly tests: > compiler/compilercontrol/directives/PrintTest.java > compiler/compilercontrol/commands/PrintTest.java > but they suffer from the JDK-8140354 that is also caused by *.* with > Xcomp. I plan to rewrite OutputAnalyzer to save output on disk. > >> May be add -Xmixed if they don't like -Xcomp? > Well, this could be a fix, but then all inlining tests would be run only with Xmixed. > >> Or use real method's names instead of *.*? > that the fix is about. > >> >> Thanks, >> Vladimir >> >> On 2/15/16 8:26 AM, Pavel Punegov wrote: >>> Hi, >>> >>> please review this small fix for CompilerControl tests. >>> >>> Issue: tests that generate commands like "inline *.*" (-XX:CompileCommand or directives) with Xcomp make compilers >>> forcibly inline everything. This significantly increases execution time leading to timeout. >>> Fix: don?t generated *.* patterns at all for such tests. It will also makes tests that use PrintAssembly to not fail >>> with OOME by decreasing of the amount of output. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8144621 >>> webrev: http://cr.openjdk.java.net/~ppunegov/8144621/webrev.00/ > From vladimir.x.ivanov at oracle.com Mon Feb 15 19:01:47 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 15 Feb 2016 22:01:47 +0300 Subject: [9] RFR (XS): 8148518: Unsafe.getCharUnaligned() loads aren't folded in case of -XX:-UseUnalignedAccesses Message-ID: <56C2209B.8090604@oracle.com> http://cr.openjdk.java.net/~vlivanov/8148518/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8148518 Current Unsafe::getCharUnaligned Java implementation isn't fully optimized by C2: it never constant folds such loads from char fields. C2 matches the types of a load and a location and does constant folding only if they match. For getCharUnaligned it sees a load of a short value, but the field is of type char. The fix is to call Unsafe::getChar when offset is aligned. It doesn't matter what is used for unaligned case, so I decided to keep makeShort(). Testing: failing test, JPRT. Best regards, Vladimir Ivanov PS: I don't update the test because it was refactored in Jigsaw [1]. To avoid unnecessary conflicts during merges, I filed an RFE [2] to adjust the test once the fix and Jake are integrated. [1] http://hg.openjdk.java.net/jigsaw/jake/hotspot/file/f6daf3633512/test/compiler/unsafe/UnsafeGetConstantField.java [2] https://bugs.openjdk.java.net/browse/JDK-8149844 From vladimir.kozlov at oracle.com Mon Feb 15 19:06:55 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 11:06:55 -0800 Subject: RFR (S) 8149813: Move trusted final field handling from C2 LoadNode::Value to shared code In-Reply-To: <56C1CFED.9080202@oracle.com> References: <56C1CFED.9080202@oracle.com> Message-ID: <56C221CF.7030104@oracle.com> Yes, looks good. Thanks, Vladimir On 2/15/16 5:17 AM, Aleksey Shipilev wrote: > Hi, > > I would like us to consider moving out the "trusted fields" logic from > C2-ish LoadNode::Value to a shared code: > https://bugs.openjdk.java.net/browse/JDK-8149813 > > Webrev: > http://cr.openjdk.java.net/~shade/8149813/webrev.00/ > > With this patch, primitive boxes and Strings are handled in the shared > code, where all other special cases are listed. Not only this is > cleaner, it also lets C1 to constant fold those cases too: > http://cr.openjdk.java.net/~shade/8149813/notes.txt > > Some changes were neede in StringOpts, because it used to rely on > constant oop present in a graph after LoadNode::Value -- which was > inconsistent with the way we pull get_constant_coder anyway. > > Testing: JPRT -testset hotspot, microbenchmarks, eyeballing assembly > > Cheers, > -Aleksey > From vladimir.kozlov at oracle.com Mon Feb 15 19:45:58 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 11:45:58 -0800 Subject: [9] RFR (XS): 8148518: Unsafe.getCharUnaligned() loads aren't folded in case of -XX:-UseUnalignedAccesses In-Reply-To: <56C2209B.8090604@oracle.com> References: <56C2209B.8090604@oracle.com> Message-ID: <56C22AF6.10007@oracle.com> Looks good to me. Thanks, Vladimir K On 2/15/16 11:01 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8148518/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8148518 > > Current Unsafe::getCharUnaligned Java implementation isn't fully optimized by C2: it never constant folds such loads > from char fields. > > C2 matches the types of a load and a location and does constant folding only if they match. For getCharUnaligned it sees > a load of a short value, but the field is of type char. > > The fix is to call Unsafe::getChar when offset is aligned. It doesn't matter what is used for unaligned case, so I > decided to keep makeShort(). > > Testing: failing test, JPRT. > > Best regards, > Vladimir Ivanov > > PS: I don't update the test because it was refactored in Jigsaw [1]. To avoid unnecessary conflicts during merges, I > filed an RFE [2] to adjust the test once the fix and Jake are integrated. > > [1] http://hg.openjdk.java.net/jigsaw/jake/hotspot/file/f6daf3633512/test/compiler/unsafe/UnsafeGetConstantField.java > > [2] https://bugs.openjdk.java.net/browse/JDK-8149844 From aleksey.shipilev at oracle.com Mon Feb 15 20:06:31 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 15 Feb 2016 23:06:31 +0300 Subject: [9] RFR (XS): 8148518: Unsafe.getCharUnaligned() loads aren't folded in case of -XX:-UseUnalignedAccesses In-Reply-To: <56C2209B.8090604@oracle.com> References: <56C2209B.8090604@oracle.com> Message-ID: <56C22FC7.30808@oracle.com> On 02/15/2016 10:01 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8148518/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8148518 +1 > Current Unsafe::getCharUnaligned Java implementation isn't fully > optimized by C2: it never constant folds such loads from char fields. > C2 matches the types of a load and a location and does constant folding > only if they match. For getCharUnaligned it sees a load of a short > value, but the field is of type char. Does the same affect putCharUnaligned? Cheers, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vladimir.kozlov at oracle.com Mon Feb 15 20:17:52 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 12:17:52 -0800 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C1CD50.3010100@oracle.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> Message-ID: <56C23270.9040308@oracle.com> Do all these tests pass with jdk9? I would suggest to run slowdebug and fastdebug to see if optimization level has affect. then it is definitely compiler bug. Andrew can we make MACC and MACC2 as method (with force inline) instead of macros? Vladimir, you may need to backport JDK-8139907. Thanks, Vladimir On 2/15/16 5:06 AM, Vladimir Kempik wrote: > Hello > > Sorry I spoke too soon last friday. > > Not all tests pass. > > On solaris x64 the testcase fails, also BigIntegerTest and ModPow65537 tests failed. > I've changed asm to asm volatile for MACC and MACC2 and tried solaris x64 again. > > Now the testcase pass, ModPow65537 pass. BigIntegerTest still fails, but only partially: > > java BigIntegerTest > Mersenne prime 3 failed. > Mersenne prime 4 failed. > Mersenne prime 5 failed. > Mersenne prime 6 failed. > Prime: Failed(4) > nextProbablePrime: Passed > Arithmetic I for 100 bits: Passed > Arithmetic II for 100 bits: Passed > Arithmetic I for 2760 bits: Passed > ..... > Do you have a clue what else could be missing for solaris x64? > Is asm volatile safe for MACC and MACC2 or better to keep it volatile only for solaris x64? > > Thanks, Vladimir. > > > On 13.02.2016 3:35, Vladimir Kozlov wrote: >> Hotspot changes looks good to me. >> >> Thanks, >> Vladimir >> >> On 2/12/16 10:29 AM, Vladimir Kempik wrote: >>> Hello >>> >>> Please review this backport of 8130150 to jdk8u. >>> >>> Implement BigInteger.montgomeryMultiply intrinsic >>> >>> The patch didn't apply cleanly, some changes were needed. Most of them are just to make patch apply, except one. >>> for MACC and MACC2 defines, __asm__ were changed to asm, to make solaris compiler (SS12U1) happy. >>> >>> The patch has two parts, for jdk and hotspot. >>> >>> Testing: jprt, testcase. >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8130150 >>> Webrev:http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.00/ >>> >>> Thanks >>> -Vladimir >>> > From aleksey.shipilev at oracle.com Mon Feb 15 20:30:45 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 15 Feb 2016 23:30:45 +0300 Subject: RFR (S) 8149813: Move trusted final field handling from C2 LoadNode::Value to shared code In-Reply-To: <56C221CF.7030104@oracle.com> References: <56C1CFED.9080202@oracle.com> <56C221CF.7030104@oracle.com> Message-ID: <56C23575.7090208@oracle.com> Thank you for reviews, Vladimir and Tobias! Cheers, -Aleksey On 02/15/2016 10:06 PM, Vladimir Kozlov wrote: > Yes, looks good. > > Thanks, > Vladimir > > On 2/15/16 5:17 AM, Aleksey Shipilev wrote: >> Hi, >> >> I would like us to consider moving out the "trusted fields" logic from >> C2-ish LoadNode::Value to a shared code: >> https://bugs.openjdk.java.net/browse/JDK-8149813 >> >> Webrev: >> http://cr.openjdk.java.net/~shade/8149813/webrev.00/ >> >> With this patch, primitive boxes and Strings are handled in the shared >> code, where all other special cases are listed. Not only this is >> cleaner, it also lets C1 to constant fold those cases too: >> http://cr.openjdk.java.net/~shade/8149813/notes.txt >> >> Some changes were needed in StringOpts, because it used to rely on >> constant oop present in a graph after LoadNode::Value -- which was >> inconsistent with the way we pull get_constant_coder anyway. >> >> Testing: JPRT -testset hotspot, microbenchmarks, eyeballing assembly >> >> Cheers, >> -Aleksey >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dean.long at oracle.com Mon Feb 15 21:17:06 2016 From: dean.long at oracle.com (Dean Long) Date: Mon, 15 Feb 2016 13:17:06 -0800 Subject: On external_word_Relocation and StubCodeDesc In-Reply-To: <56C1F0BC.7090700@oracle.com> References: <56C1F0BC.7090700@oracle.com> Message-ID: <56C24052.9010703@oracle.com> How many unique external addresses do we typically have? If we really want to conserve footprint, would it make sense to store them all in a table, and not just stub addresses? However, aren't external_word relocations rare? It may not be worth it to encode the address as an index, or even to encode a 64-bit address as something smaller using deltas. Do you have any statistics on the effect of external_word relocations on footprint? dl On 2/15/2016 7:37 AM, Vladimir Ivanov wrote: > While working on JDK-8138922 [1], I noticed that > StubCodeDesc::desc_for is called for every external address embedded > in the code [2]. It is done to save some space on relocations (record > an index in the stub list instead of full address). > > StubCodeDesc::desc_for does linear search over the list and there are > around 100 stubs registered on x64. > > The problem is that the hit rate is very low. My experiments (on > Octane [3]) show that there are thousands of requests with 0% hit rate. > > So, instead of speeding up the search (switch to array, sort it and do > binary search to compute the index or lookup the address by index), I > suggest to completely remove that logic and always record the address > for external_word relocations. > > What's your take on that? > > Best regards, > Vladimir Ivanov > > PS: there are some prospects in compacting some "well-known" addresses > [4], but it seems stubs aren't good candidates for that. > > [1] https://bugs.openjdk.java.net/browse/JDK-8138922 > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-February/021702.html > > > [2] hotspot/src/share/vm/code/relocInfo.cpp: > void external_word_Relocation::pack_data_to(CodeSection* dest) { > short* p = (short*) dest->locs_end(); > int32_t index = runtime_address_to_index(_target); > > where runtime_address_to_index looks for the _target among stubs > registered in StubCodeDescs::_list: > > int32_t Relocation::runtime_address_to_index(address runtime_address) { > assert(!is_reloc_index((intptr_t)runtime_address), "must not look > like an index"); > > if (runtime_address == NULL) return 0; > > StubCodeDesc* p = StubCodeDesc::desc_for(runtime_address); > if (p != NULL && p->begin() == runtime_address) { > assert(is_reloc_index(p->index()), "there must not be too many > stubs"); > return (int32_t)p->index(); > > [3] perf counters: > sun.ci.stubCodeDesc::total_reqs=11788 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=4117 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=3270 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=5183 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=7001 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=2909 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=10335 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=4698 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=5059 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=2763 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=3035 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=7244 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > [4] Box2D external addresses stats: > 5628 0x0000000102601396 > 16 0x00000001027cba58 > 20 0x00000001027cba60 > 85 0x00000001027cc198 > 110 0x00000001027d82a2 > 55 0x00000001027ee720 > 351 0x00000001027eea80 > 9 0x0000000102814380 > 41 0x00000001028143a0 > 2 0x0000000103246460 > 3812 0x0000000103246480 From vladimir.kozlov at oracle.com Mon Feb 15 22:47:51 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 14:47:51 -0800 Subject: On external_word_Relocation and StubCodeDesc In-Reply-To: <56C1F0BC.7090700@oracle.com> References: <56C1F0BC.7090700@oracle.com> Message-ID: <56C25597.7010306@oracle.com> Actually you could optimize it in case of segmented CodeCache (default with tiered) by checking if PC is in Non-nmethods segment. Also stub's address should not be external since stubs are located in CodeCache. External addresses are used for runtime (or C-heap) addresses. Thanks, Vladimir K On 2/15/16 7:37 AM, Vladimir Ivanov wrote: > While working on JDK-8138922 [1], I noticed that StubCodeDesc::desc_for > is called for every external address embedded in the code [2]. It is > done to save some space on relocations (record an index in the stub list > instead of full address). > > StubCodeDesc::desc_for does linear search over the list and there are > around 100 stubs registered on x64. > > The problem is that the hit rate is very low. My experiments (on Octane > [3]) show that there are thousands of requests with 0% hit rate. > > So, instead of speeding up the search (switch to array, sort it and do > binary search to compute the index or lookup the address by index), I > suggest to completely remove that logic and always record the address > for external_word relocations. > > What's your take on that? > > Best regards, > Vladimir Ivanov > > PS: there are some prospects in compacting some "well-known" addresses > [4], but it seems stubs aren't good candidates for that. > > [1] https://bugs.openjdk.java.net/browse/JDK-8138922 > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-February/021702.html > > > [2] hotspot/src/share/vm/code/relocInfo.cpp: > void external_word_Relocation::pack_data_to(CodeSection* dest) { > short* p = (short*) dest->locs_end(); > int32_t index = runtime_address_to_index(_target); > > where runtime_address_to_index looks for the _target among stubs > registered in StubCodeDescs::_list: > > int32_t Relocation::runtime_address_to_index(address runtime_address) { > assert(!is_reloc_index((intptr_t)runtime_address), "must not look > like an index"); > > if (runtime_address == NULL) return 0; > > StubCodeDesc* p = StubCodeDesc::desc_for(runtime_address); > if (p != NULL && p->begin() == runtime_address) { > assert(is_reloc_index(p->index()), "there must not be too many > stubs"); > return (int32_t)p->index(); > > [3] perf counters: > sun.ci.stubCodeDesc::total_reqs=11788 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=4117 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=3270 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=5183 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=7001 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=2909 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=10335 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=4698 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=5059 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=2763 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=3035 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > sun.ci.stubCodeDesc::total_reqs=7244 > sun.ci.stubCodeDesc::total_reqs_hit=0 > > [4] Box2D external addresses stats: > 5628 0x0000000102601396 > 16 0x00000001027cba58 > 20 0x00000001027cba60 > 85 0x00000001027cc198 > 110 0x00000001027d82a2 > 55 0x00000001027ee720 > 351 0x00000001027eea80 > 9 0x0000000102814380 > 41 0x00000001028143a0 > 2 0x0000000103246460 > 3812 0x0000000103246480 From vladimir.kozlov at oracle.com Tue Feb 16 00:11:21 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Feb 2016 16:11:21 -0800 Subject: [9] RFR (S): 8148754: C2 loop unrolling fails due to unexpected graph shape In-Reply-To: <56C1ED18.6060903@oracle.com> References: <56C1ED18.6060903@oracle.com> Message-ID: <56C26929.4050706@oracle.com> Zoltan, It should not be "main" loop if peeling happened. See do_peeling(): if (cl->is_main_loop()) { cl->set_normal_loop(); Split-if optimization should not split through loop's phi. And generally not through loop's head since it is not making code better - split through backedge moves code into loop again. Making loop body more complicated as this case shows. Bailout unrolling is fine but performance may suffer because in some cases loop unrolling is better then split-if. Thanks, Vladimir On 2/15/16 7:22 AM, Zolt?n Maj? wrote: > Hi, > > > please review the patch for 8148754. > > https://bugs.openjdk.java.net/browse/JDK-8148754 > > Problem: Compilation fails when the C2 compiler attempts loop unrolling. > The cause of the failure is that the loop unrolling optimization expects > a well-defined graph shape at the entry control of a 'CountedLoopNode' > ('IfTrue'/'IfFalse' preceeded by 'If' preceeded by 'Bool' preceeded by > 'CmpI'). > > > Solution: I investigated several different instances of the same > failure. It turns out that the shape of the graph at a loop's entry > control is often different from the way loop unrolling expects it to be > (please find some examples in the bug's JBS issue). The various graph > shapes are a result of previously performed transformations, e.g., > split-if optimization and loop peeling. > > Loop unrolling requires the above mentioned graph shape so that it can > adjust the zero-trip guard of the loop. With the unexpected graph > shapes, it is not possible to perform loop unrolling. However, the graph > is still in a valid state (except for loop unrolling) and can be used to > produce correct code. > > I propose that (1) we check if an unexpected graph shape is encountered > and (2) bail out of loop unrolling if it is (but not fail in the > compiler in such cases). > > The failure was triggered by Aleksey's Indify String Concatenation > changes but the generated bytecodes are valid. So this seems to be a > compiler issue that was previously there but was not yet triggered. > > > Webrev: > http://cr.openjdk.java.net/~zmajo/8148754/webrev.00/ > > Testing: > - JPRT; > - local testing (linux-86_64) with the failing test case; > - executed all hotspot tests locally, all tests pass that pass with an > unmodified build. > > Thank you! > > Best regards, > > > Zoltan > From tobias.hartmann at oracle.com Tue Feb 16 06:59:01 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 16 Feb 2016 07:59:01 +0100 Subject: [8u] Request for approval: Backport of 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56C20721.5020001@oracle.com> References: <56C197AB.3050208@oracle.com> <56C20721.5020001@oracle.com> Message-ID: <56C2C8B5.6020709@oracle.com> Thanks, Vladimir. Best, Tobias On 15.02.2016 18:13, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 2/15/16 1:17 AM, Tobias Hartmann wrote: >> Hi, >> >> please approve and review the following backport to 8u. >> >> 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException >> https://bugs.openjdk.java.net/browse/JDK-8148752 >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021176.html >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4130663a3de8 >> >> The fix was pushed to hs-comp last week and nightly testing showed no problems. >> >> Thanks, >> Tobias >> From tobias.hartmann at oracle.com Tue Feb 16 08:02:45 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 16 Feb 2016 09:02:45 +0100 Subject: [8u] Request for approval: Backport of 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56C2D394.7020903@oracle.com> References: <56C197AB.3050208@oracle.com> <56C20721.5020001@oracle.com> <56C2C8B5.6020709@oracle.com> <56C2D394.7020903@oracle.com> Message-ID: <56C2D7A5.7000001@oracle.com> Thanks, David. Best, Tobias On 16.02.2016 08:45, david buck wrote: > approved for backport to 8u-dev (assuming changeset applies cleanly to 8u-dev forest) > > Cheers, > -Buck > > On 2016/02/16 15:59, Tobias Hartmann wrote: >> Thanks, Vladimir. >> >> Best, >> Tobias >> >> On 15.02.2016 18:13, Vladimir Kozlov wrote: >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 2/15/16 1:17 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please approve and review the following backport to 8u. >>>> >>>> 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException >>>> https://bugs.openjdk.java.net/browse/JDK-8148752 >>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021176.html >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4130663a3de8 >>>> >>>> The fix was pushed to hs-comp last week and nightly testing showed no problems. >>>> >>>> Thanks, >>>> Tobias >>>> From vladimir.x.ivanov at oracle.com Tue Feb 16 10:56:26 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 16 Feb 2016 13:56:26 +0300 Subject: [9] RFR (XS): 8148518: Unsafe.getCharUnaligned() loads aren't folded in case of -XX:-UseUnalignedAccesses In-Reply-To: <56C22FC7.30808@oracle.com> References: <56C2209B.8090604@oracle.com> <56C22FC7.30808@oracle.com> Message-ID: <56C3005A.4010109@oracle.com> Vladimir, Aleksey, thanks for the reviews. >> Current Unsafe::getCharUnaligned Java implementation isn't fully >> optimized by C2: it never constant folds such loads from char fields. >> C2 matches the types of a load and a location and does constant folding >> only if they match. For getCharUnaligned it sees a load of a short >> value, but the field is of type char. > > Does the same affect putCharUnaligned? No, the logic is specific to unsafe loads. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Tue Feb 16 11:18:37 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 16 Feb 2016 14:18:37 +0300 Subject: On external_word_Relocation and StubCodeDesc In-Reply-To: <56C24052.9010703@oracle.com> References: <56C1F0BC.7090700@oracle.com> <56C24052.9010703@oracle.com> Message-ID: <56C3058D.3010609@oracle.com> On 2/16/16 12:17 AM, Dean Long wrote: > How many unique external addresses do we typically have? If we really > want to conserve footprint, would it make sense to store them all in a > table, and not just stub addresses? As I mentioned, my quick experiment [1] demonstrated that most of the addresses are heavily used: there are 11 unique addresses used in 12k relocations. So, interning them in a table should work. > However, aren't external_word relocations rare? It may not be worth it > to encode the address as an index, or even to encode a 64-bit address as > something smaller using deltas. Do you have any statistics on the > effect of external_word relocations on footprint? Well, I haven't done any extensive measurements, but I observe thousands (3k-12k) of external_word relocations on Octane benchmarks. Saving half-word on every relocation sums up to 12-46Kb savings in ideal case. But it is far from reality: (1) I track relocations across application lifetime, so their number should be much smaller at every moment in time; (2) actual savings can be levelled by alignment. So, it doesn't look very attractive. Best regards, Vladimir Ivanov [1] 5628 0x0000000102601396 16 0x00000001027cba58 20 0x00000001027cba60 85 0x00000001027cc198 110 0x00000001027d82a2 55 0x00000001027ee720 351 0x00000001027eea80 9 0x0000000102814380 41 0x00000001028143a0 2 0x0000000103246460 3812 0x0000000103246480 > > dl > > On 2/15/2016 7:37 AM, Vladimir Ivanov wrote: >> While working on JDK-8138922 [1], I noticed that >> StubCodeDesc::desc_for is called for every external address embedded >> in the code [2]. It is done to save some space on relocations (record >> an index in the stub list instead of full address). >> >> StubCodeDesc::desc_for does linear search over the list and there are >> around 100 stubs registered on x64. >> >> The problem is that the hit rate is very low. My experiments (on >> Octane [3]) show that there are thousands of requests with 0% hit rate. >> >> So, instead of speeding up the search (switch to array, sort it and do >> binary search to compute the index or lookup the address by index), I >> suggest to completely remove that logic and always record the address >> for external_word relocations. >> >> What's your take on that? >> >> Best regards, >> Vladimir Ivanov >> >> PS: there are some prospects in compacting some "well-known" addresses >> [4], but it seems stubs aren't good candidates for that. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8138922 >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-February/021702.html >> >> >> [2] hotspot/src/share/vm/code/relocInfo.cpp: >> void external_word_Relocation::pack_data_to(CodeSection* dest) { >> short* p = (short*) dest->locs_end(); >> int32_t index = runtime_address_to_index(_target); >> >> where runtime_address_to_index looks for the _target among stubs >> registered in StubCodeDescs::_list: >> >> int32_t Relocation::runtime_address_to_index(address runtime_address) { >> assert(!is_reloc_index((intptr_t)runtime_address), "must not look >> like an index"); >> >> if (runtime_address == NULL) return 0; >> >> StubCodeDesc* p = StubCodeDesc::desc_for(runtime_address); >> if (p != NULL && p->begin() == runtime_address) { >> assert(is_reloc_index(p->index()), "there must not be too many >> stubs"); >> return (int32_t)p->index(); >> >> [3] perf counters: >> sun.ci.stubCodeDesc::total_reqs=11788 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=4117 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=3270 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=5183 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=7001 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=2909 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=10335 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=4698 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=5059 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=2763 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=3035 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=7244 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> [4] Box2D external addresses stats: >> 5628 0x0000000102601396 >> 16 0x00000001027cba58 >> 20 0x00000001027cba60 >> 85 0x00000001027cc198 >> 110 0x00000001027d82a2 >> 55 0x00000001027ee720 >> 351 0x00000001027eea80 >> 9 0x0000000102814380 >> 41 0x00000001028143a0 >> 2 0x0000000103246460 >> 3812 0x0000000103246480 > From felix.yang at linaro.org Tue Feb 16 11:28:13 2016 From: felix.yang at linaro.org (Felix Yang) Date: Tue, 16 Feb 2016 19:28:13 +0800 Subject: RFR: 8149907: aarch64: use load/store pair instructions in call_stub Message-ID: Hi, Please review the following webrev: http://cr.openjdk.java.net/~fyang/8149907/webrev.00/ Jira issue: https://bugs.openjdk.java.net/browse/JDK-8149907 This patch make use of load/store pair instructions in call_stub saving 24 load/store instructions. Tested with jtreg hotspot & langtools. Is it OK? Thanks, Felix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Tue Feb 16 11:46:54 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 16 Feb 2016 11:46:54 +0000 Subject: [aarch64-port-dev ] RFR: 8149907: aarch64: use load/store pair instructions in call_stub In-Reply-To: References: Message-ID: <56C30C2E.4080206@redhat.com> On 02/16/2016 11:28 AM, Felix Yang wrote: > Please review the following webrev: > http://cr.openjdk.java.net/~fyang/8149907/webrev.00/ I guess this is okay, but it's a lot less self-documenting than it was. If there are any unused locals (e.g. r27_save) you must delete them or use them in assertions. Andrew. From roland.westrelin at oracle.com Tue Feb 16 12:02:03 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 16 Feb 2016 13:02:03 +0100 Subject: RFR(XS): 8149916: Test case for 8149797 Message-ID: <9370DE73-F7F4-4C15-9128-821CFCDA09DD@oracle.com> http://cr.openjdk.java.net/~roland/8149916/webrev.00/ I pushed yesterday?s CheckCastPP fix without a test case. Here is one. Roland. From vladimir.x.ivanov at oracle.com Tue Feb 16 12:30:53 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 16 Feb 2016 15:30:53 +0300 Subject: On external_word_Relocation and StubCodeDesc In-Reply-To: <56C25597.7010306@oracle.com> References: <56C1F0BC.7090700@oracle.com> <56C25597.7010306@oracle.com> Message-ID: <56C3167D.2070605@oracle.com> On 2/16/16 1:47 AM, Vladimir Kozlov wrote: > Actually you could optimize it in case of segmented CodeCache (default > with tiered) by checking if PC is in Non-nmethods segment. Yes, it should help. But what I'm trying to understand is how viable is the current scheme (when stub entry points are treated specially). It seems stubs are rare among external addresses. Also, there are other stubs (e.g., produced by Runtime1::generate_blob_for) which aren't put in StubCodeDesc::_list. So, if it is viable to save on external relocation encoding, we have to come up with a universal solution. Otherwise, I'd prefer to keep things simple and completely remove stub-specific logic. > Also stub's address should not be external since stubs are located in > CodeCache. External addresses are used for runtime (or C-heap) addresses. I don't think it is always the case, e.g: * many stubs are referenced as ExternalAddress (e.g. [1]); * range_check [2] issues external addresses, but SharedRuntime::gen_i2c_adapter passes in addresses within the code cache [3]. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/9cf33e51c2d4/src/cpu/x86/vm/macroAssembler_x86.cpp#l10233 [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/9cf33e51c2d4/src/cpu/x86/vm/sharedRuntime_x86_64.cpp#l683 [3] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/9cf33e51c2d4/src/cpu/x86/vm/sharedRuntime_x86_64.cpp#l731 > > Thanks, > Vladimir K > > On 2/15/16 7:37 AM, Vladimir Ivanov wrote: >> While working on JDK-8138922 [1], I noticed that StubCodeDesc::desc_for >> is called for every external address embedded in the code [2]. It is >> done to save some space on relocations (record an index in the stub list >> instead of full address). >> >> StubCodeDesc::desc_for does linear search over the list and there are >> around 100 stubs registered on x64. >> >> The problem is that the hit rate is very low. My experiments (on Octane >> [3]) show that there are thousands of requests with 0% hit rate. >> >> So, instead of speeding up the search (switch to array, sort it and do >> binary search to compute the index or lookup the address by index), I >> suggest to completely remove that logic and always record the address >> for external_word relocations. >> >> What's your take on that? >> >> Best regards, >> Vladimir Ivanov >> >> PS: there are some prospects in compacting some "well-known" addresses >> [4], but it seems stubs aren't good candidates for that. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8138922 >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-February/021702.html >> >> >> >> [2] hotspot/src/share/vm/code/relocInfo.cpp: >> void external_word_Relocation::pack_data_to(CodeSection* dest) { >> short* p = (short*) dest->locs_end(); >> int32_t index = runtime_address_to_index(_target); >> >> where runtime_address_to_index looks for the _target among stubs >> registered in StubCodeDescs::_list: >> >> int32_t Relocation::runtime_address_to_index(address runtime_address) { >> assert(!is_reloc_index((intptr_t)runtime_address), "must not look >> like an index"); >> >> if (runtime_address == NULL) return 0; >> >> StubCodeDesc* p = StubCodeDesc::desc_for(runtime_address); >> if (p != NULL && p->begin() == runtime_address) { >> assert(is_reloc_index(p->index()), "there must not be too many >> stubs"); >> return (int32_t)p->index(); >> >> [3] perf counters: >> sun.ci.stubCodeDesc::total_reqs=11788 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=4117 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=3270 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=5183 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=7001 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=2909 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=10335 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=4698 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=5059 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=2763 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=3035 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> sun.ci.stubCodeDesc::total_reqs=7244 >> sun.ci.stubCodeDesc::total_reqs_hit=0 >> >> [4] Box2D external addresses stats: >> 5628 0x0000000102601396 >> 16 0x00000001027cba58 >> 20 0x00000001027cba60 >> 85 0x00000001027cc198 >> 110 0x00000001027d82a2 >> 55 0x00000001027ee720 >> 351 0x00000001027eea80 >> 9 0x0000000102814380 >> 41 0x00000001028143a0 >> 2 0x0000000103246460 >> 3812 0x0000000103246480 From nils.eliasson at oracle.com Tue Feb 16 13:01:29 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 16 Feb 2016 14:01:29 +0100 Subject: RFR(S): 8148159: [TESTBUG] TestCompilerDirectivesCompatibility tests fails on non-tiered server VMs Message-ID: <56C31DA9.3070607@oracle.com> Hi, Please review this change. The tests relied on C1 always being available and thus fails on C2 only server configurations. The fix adds two whitebox methods for checking if C1 and C2 is available, and then tests both compilers separately. Also adding Xmixed to the commandline since this test doesn't need Xcomp testing. Bug: https://bugs.openjdk.java.net/browse/JDK-8148159 Webrev: http://cr.openjdk.java.net/~neliasso/8148159/webrev.01/ http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.01/ Regards, Nils Eliasson From jamsheed.c.m at oracle.com Tue Feb 16 13:20:29 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 16 Feb 2016 18:50:29 +0530 Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash In-Reply-To: <41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com> References: <56BC90DC.10004@oracle.com> <56BD8DF9.1070605@oracle.com> <56BE1274.4020506@oracle.com> <41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com> Message-ID: <56C3221D.2040507@oracle.com> Hi Chris, Revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/ This code take care of every jvmci flags automatically. Best Regards, Jamsheed On 2/13/2016 3:24 AM, Christian Thalinger wrote: > >> On Feb 12, 2016, at 7:12 AM, Jamsheed C m > > wrote: >> >> >> Hi Chris, >> >> On 2/12/2016 10:12 PM, Christian Thalinger wrote: >>> Well, now you have to manually check all flags that had a constraint >>> directive. That is the annoying part and what I complained about in: >> check against original value, and if not fail ? > > Same check for all flags; they all depend on +EnableJVMCI. > >>> >>> https://bugs.openjdk.java.net/browse/JDK-8145357 >>> >>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now empty >>> and I think we should remove them. >> i kept the file as there can be future use. Ok, i will remove it. >> >> Best Regards, >> Jamsheed >>> >>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m >>> > wrote: >>>> >>>> Hi Chris, >>>> >>>> revised webrev: >>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/ >>>> >>>> Best Regards, >>>> Jamsheed >>>> >>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote: >>>>> >>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Request for review >>>>>> >>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333 >>>>>> web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ >>>>>> >>>>> >>>>> That looks alright but we should remove the constraints from all >>>>> the JVMCI command line flags because the way we use them is not >>>>> supported. >>>>> >>>>> Also, can you change the error message? Right now it looks like this: >>>>> >>>>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java >>>>> -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler >>>>> EnableJVMCI must be enabled >>>>> Improperly specified VM option 'UseJVMCICompiler' >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> I think with your changes we will only see the first line without >>>>> mentioning UseJVMCICompiler. Is that correct? >>>>> >>>>>> >>>>>> Fix Summary: added jvmci flag consistency check after arg parsing. >>>>>> >>>>>> tests: jprt >>>>>> unit test: command line verification >>>>>> >>>>>> Best Regards, >>>>>> Jamsheed >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.eriksson at oracle.com Tue Feb 16 14:24:12 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Tue, 16 Feb 2016 15:24:12 +0100 Subject: RFR(S): 8146096: [TEST BUG] compiler/loopopts/UseCountedLoopSafepoints.java Timeouts In-Reply-To: <569F52B8.7020802@oracle.com> References: <569E2CDE.3060805@oracle.com> <569E3109.8090107@oracle.com> <569EA0A9.8050406@oracle.com> <569F52B8.7020802@oracle.com> Message-ID: <56C3310C.2020008@oracle.com> Hi, I've changed the test so it will not timeout, by using the WhiteBox.forceSafepoint() in a separate thread. If there is a safepoint in the loop, then the test will exit after taking one safepoint. If instead all safepoints in the loop were removed, then the safepoint operation will timeout after two seconds (because of -XX:+SafepointTimeout) and it will be detected and the test will fail. Webrev: http://cr.openjdk.java.net/~aeriksso/8146096/webrev.00/ Regards, Andreas On 2016-01-20 10:26, Andreas Eriksson wrote: > Vladimir Kozlov and Vladimir Ivanov, > > Ok, I'll look into using the whitebox api to fix the test. > Thanks for looking at this. > > - Andreas > > On 2016-01-19 21:46, Vladimir Kozlov wrote: >> Simple use timeout to check for generated safepoint is bad idea. It >> is very inaccurate. At least you need to check call stack to see if >> it stopped in compiled method. >> I would prefer to see WB new interface which would check that loop >> SafePointNode is generated during compilation of method. It will be >> precise. >> >> And we need such tests to make sure a feature is working - we can't >> remove them. >> >> Thanks, >> Vladimir >> >> On 1/19/16 4:50 AM, Vladimir Ivanov wrote: >>> As an idea to improve the test: spawn a thread which executes the >>> counted loop and then use WhiteBox.forceSafepoint() to >>> trigger a safepoint. >>> >>> If the test times out, it means there's no safepoint in the loop. >>> >>> Also, it also simplifies the implementation - no need to spawn a >>> child process, the check can be done in-process. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 1/19/16 3:32 PM, Andreas Eriksson wrote: >>>> Hi, >>>> >>>> Can I please have a review for the removal of >>>> hotspot/test/compiler/loopopts/UseCountedLoopSafepoints.java. >>>> >>>> The test needs to do a loop that takes more than two seconds to >>>> execute >>>> fully without doing a safepointing call. For this expensive atomic >>>> operations were used. The problem is that on certain embedded >>>> platforms >>>> they are too expensive, and the test times out. >>>> The loop length could probably be reduced, and it should still work on >>>> faster machines. However, the test is not very useful, so I think it's >>>> better to just remove it to avoid future problems. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146096 >>>> Test to be removed: >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/d84a55e7aaf8/test/compiler/loopopts/UseCountedLoopSafepoints.java >>>> >>>> >>>> (I can create a webrev if you think it necessary.) >>>> >>>> Thanks, >>>> Andreas > From vladimir.kozlov at oracle.com Tue Feb 16 16:02:31 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Feb 2016 08:02:31 -0800 Subject: RFR(XS): 8149916: Test case for 8149797 In-Reply-To: <9370DE73-F7F4-4C15-9128-821CFCDA09DD@oracle.com> References: <9370DE73-F7F4-4C15-9128-821CFCDA09DD@oracle.com> Message-ID: <56C34817.4060700@oracle.com> Good. Thanks, Vladimir On 2/16/16 4:02 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8149916/webrev.00/ > > I pushed yesterday?s CheckCastPP fix without a test case. Here is one. > > Roland. > From vladimir.kozlov at oracle.com Tue Feb 16 16:22:04 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Feb 2016 08:22:04 -0800 Subject: On external_word_Relocation and StubCodeDesc In-Reply-To: <56C3167D.2070605@oracle.com> References: <56C1F0BC.7090700@oracle.com> <56C25597.7010306@oracle.com> <56C3167D.2070605@oracle.com> Message-ID: <56C34CAC.3070105@oracle.com> On 2/16/16 4:30 AM, Vladimir Ivanov wrote: > On 2/16/16 1:47 AM, Vladimir Kozlov wrote: >> Actually you could optimize it in case of segmented CodeCache (default >> with tiered) by checking if PC is in Non-nmethods segment. > Yes, it should help. > > But what I'm trying to understand is how viable is the current scheme (when stub entry points are treated specially). It > seems stubs are rare among external addresses. > > Also, there are other stubs (e.g., produced by Runtime1::generate_blob_for) which aren't put in StubCodeDesc::_list. > > So, if it is viable to save on external relocation encoding, we have to come up with a universal solution. Otherwise, > I'd prefer to keep things simple and completely remove stub-specific logic. > >> Also stub's address should not be external since stubs are located in >> CodeCache. External addresses are used for runtime (or C-heap) addresses. > I don't think it is always the case, e.g: > * many stubs are referenced as ExternalAddress (e.g. [1]); It is table in C-heap and not a stub in codecache. It is not on StubCodeDesc::_list. > > * range_check [2] issues external addresses, but SharedRuntime::gen_i2c_adapter passes in addresses within the code > cache [3]. First, I think it is mistake to use ExternalAddress in range_check. And second none of those addresses are present in StubCodeDesc::_list. I think your experiment with hit rate is confirmation that StubCodeDesc::desc_for() will find nothing when called from external_word_Relocation::pack_data_to(). May be we should path flag as parameter to avoid calling StubCodeDesc::desc_for() in such case. Thanks, Vladimir > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/9cf33e51c2d4/src/cpu/x86/vm/macroAssembler_x86.cpp#l10233 > > [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/9cf33e51c2d4/src/cpu/x86/vm/sharedRuntime_x86_64.cpp#l683 > > [3] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/9cf33e51c2d4/src/cpu/x86/vm/sharedRuntime_x86_64.cpp#l731 > >> >> Thanks, >> Vladimir K >> >> On 2/15/16 7:37 AM, Vladimir Ivanov wrote: >>> While working on JDK-8138922 [1], I noticed that StubCodeDesc::desc_for >>> is called for every external address embedded in the code [2]. It is >>> done to save some space on relocations (record an index in the stub list >>> instead of full address). >>> >>> StubCodeDesc::desc_for does linear search over the list and there are >>> around 100 stubs registered on x64. >>> >>> The problem is that the hit rate is very low. My experiments (on Octane >>> [3]) show that there are thousands of requests with 0% hit rate. >>> >>> So, instead of speeding up the search (switch to array, sort it and do >>> binary search to compute the index or lookup the address by index), I >>> suggest to completely remove that logic and always record the address >>> for external_word relocations. >>> >>> What's your take on that? >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> PS: there are some prospects in compacting some "well-known" addresses >>> [4], but it seems stubs aren't good candidates for that. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8138922 >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-February/021702.html >>> >>> >>> >>> [2] hotspot/src/share/vm/code/relocInfo.cpp: >>> void external_word_Relocation::pack_data_to(CodeSection* dest) { >>> short* p = (short*) dest->locs_end(); >>> int32_t index = runtime_address_to_index(_target); >>> >>> where runtime_address_to_index looks for the _target among stubs >>> registered in StubCodeDescs::_list: >>> >>> int32_t Relocation::runtime_address_to_index(address runtime_address) { >>> assert(!is_reloc_index((intptr_t)runtime_address), "must not look >>> like an index"); >>> >>> if (runtime_address == NULL) return 0; >>> >>> StubCodeDesc* p = StubCodeDesc::desc_for(runtime_address); >>> if (p != NULL && p->begin() == runtime_address) { >>> assert(is_reloc_index(p->index()), "there must not be too many >>> stubs"); >>> return (int32_t)p->index(); >>> >>> [3] perf counters: >>> sun.ci.stubCodeDesc::total_reqs=11788 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> sun.ci.stubCodeDesc::total_reqs=4117 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> sun.ci.stubCodeDesc::total_reqs=3270 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> sun.ci.stubCodeDesc::total_reqs=5183 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> sun.ci.stubCodeDesc::total_reqs=7001 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> sun.ci.stubCodeDesc::total_reqs=2909 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> sun.ci.stubCodeDesc::total_reqs=10335 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> sun.ci.stubCodeDesc::total_reqs=4698 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> sun.ci.stubCodeDesc::total_reqs=5059 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> sun.ci.stubCodeDesc::total_reqs=2763 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> sun.ci.stubCodeDesc::total_reqs=3035 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> sun.ci.stubCodeDesc::total_reqs=7244 >>> sun.ci.stubCodeDesc::total_reqs_hit=0 >>> >>> [4] Box2D external addresses stats: >>> 5628 0x0000000102601396 >>> 16 0x00000001027cba58 >>> 20 0x00000001027cba60 >>> 85 0x00000001027cc198 >>> 110 0x00000001027d82a2 >>> 55 0x00000001027ee720 >>> 351 0x00000001027eea80 >>> 9 0x0000000102814380 >>> 41 0x00000001028143a0 >>> 2 0x0000000103246460 >>> 3812 0x0000000103246480 From nils.eliasson at oracle.com Tue Feb 16 17:41:53 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 16 Feb 2016 18:41:53 +0100 Subject: RFR (XXS): 8144621: CompilerControl: inline tests timeout with Xcomp In-Reply-To: <56C1FFD6.2050708@oracle.com> References: <4245B7A0-D8AA-4623-9F73-F794B00F15A6@oracle.com> <56C1FFD6.2050708@oracle.com> Message-ID: <56C35F61.2090704@oracle.com> On 2016-02-15 17:41, Vladimir Kozlov wrote: > Should we fix tests with *.* commands instead? Could you, please, list > those tests (I want to look)? May be add -Xmixed if they don't like > -Xcomp? Or use real method's names instead of *.*? +1 on adding -Xmixed to all the compiler control tests. Xcomp doesn't add any value to these tests. Otherwise - looks good. Thanks for fixing! Nils Eliasson > > Thanks, > Vladimir > > On 2/15/16 8:26 AM, Pavel Punegov wrote: >> Hi, >> >> please review this small fix for CompilerControl tests. >> >> Issue: tests that generate commands like "inline *.*" >> (-XX:CompileCommand or directives) with Xcomp make compilers >> forcibly inline everything. This significantly increases execution >> time leading to timeout. >> Fix: don?t generated *.* patterns at all for such tests. It will also >> makes tests that use PrintAssembly to not fail >> with OOME by decreasing of the amount of output. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8144621 >> webrev: http://cr.openjdk.java.net/~ppunegov/8144621/webrev.00/ From vladimir.x.ivanov at oracle.com Tue Feb 16 18:40:11 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 16 Feb 2016 21:40:11 +0300 Subject: On external_word_Relocation and StubCodeDesc In-Reply-To: <56C34CAC.3070105@oracle.com> References: <56C1F0BC.7090700@oracle.com> <56C25597.7010306@oracle.com> <56C3167D.2070605@oracle.com> <56C34CAC.3070105@oracle.com> Message-ID: <56C36D0B.5040007@oracle.com> Vladimir, >>> Also stub's address should not be external since stubs are located in >>> CodeCache. External addresses are used for runtime (or C-heap) >>> addresses. >> I don't think it is always the case, e.g: >> * many stubs are referenced as ExternalAddress (e.g. [1]); > > It is table in C-heap and not a stub in codecache. It is not on > StubCodeDesc::_list. Yes, you are right. >> * range_check [2] issues external addresses, but >> SharedRuntime::gen_i2c_adapter passes in addresses within the code >> cache [3]. > > First, I think it is mistake to use ExternalAddress in range_check. Do you think we should fix that? There are other places, e.g.: * src/cpu/x86/vm/templateTable_x86.cpp ExternalAddress(Interpreter::_throw_ArithmeticException_entry)); * src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp __ jump(ExternalAddress(Interpreter::throw_exception_entry())); __ jump(ExternalAddress(StubRoutines::throw_StackOverflowError_entry())); > And second none of those addresses are present in StubCodeDesc::_list. For the following case: range_check(masm, rax, r11, StubRoutines::code1()->code_begin(), StubRoutines::code1()->code_end(), L_ok); StubRoutines::code1()->code_begin() == entry point for StubRoutines::forward_exception. So, the first address is replaced with the index. But it's definitely not important from footprint POV. FTR the data I provided on hit rates was gathered with product binaries. > I think your experiment with hit rate is confirmation that > StubCodeDesc::desc_for() will find nothing when called from > external_word_Relocation::pack_data_to(). May be we should path flag as > parameter to avoid calling StubCodeDesc::desc_for() in such case. I'm inclined to completely remove Relocation::runtime_address_to_index. I'll prepare a webrev and send it out for review. Best regards, Vladimir Ivanov From sean.coffey at oracle.com Tue Feb 16 19:14:59 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 16 Feb 2016 19:14:59 +0000 Subject: [8u-dev] Request for approval to backport: 8081778: Use Intel x64 CPU instructions for RSA acceleration In-Reply-To: <56BE3096.8010808@oracle.com> References: <56BE29A1.1040207@oracle.com> <56BE3096.8010808@oracle.com> Message-ID: <56C37533.10907@oracle.com> Approved for jdk8u-dev. Regards, Sean. On 12/02/2016 19:20, Vladimir Kozlov wrote: > 8u changes looks good. > > Thanks, > Vladimir > > On 2/12/16 10:51 AM, Ivan Gerasimov wrote: >> Hello! >> >> I'm seeking an approval to backport this performance enhancement to >> jdk8u-dev. >> The change applies *almost* cleanly. >> The only change I had to make was adding the extra argument to the >> 'new' operator, which is required in jdk8, but not jdk9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8081778 >> Jdk9 hotspot change: >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/578f086f3435 >> Jdk9 jdk change: >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/de309dbe42bf >> Jdk9 review: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-May/018106.html >> >> The changes, comparing to jdk9 are in >> hotspot/src/share/vm/opto/library_call.cpp at lines #5956 and #5964; >> >> Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8081778/00/webrev/ >> >> Patched Jdk was successfully built and tested on all supported >> platforms. >> >> Would you please approve this backport? >> >> Sincerely yours, >> Ivan >> >> >> From aph at redhat.com Tue Feb 16 19:19:23 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 16 Feb 2016 19:19:23 +0000 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C23270.9040308@oracle.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com> Message-ID: <56C3763B.8070900@redhat.com> On 02/15/2016 08:17 PM, Vladimir Kozlov wrote: > Andrew can we make MACC and MACC2 as method (with force inline) instead of macros? Yes, but I can see no reason why that would make any difference. Andrew. From vladimir.kozlov at oracle.com Tue Feb 16 19:45:50 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Feb 2016 11:45:50 -0800 Subject: RFR(S): 8146096: [TEST BUG] compiler/loopopts/UseCountedLoopSafepoints.java Timeouts In-Reply-To: <56C3310C.2020008@oracle.com> References: <569E2CDE.3060805@oracle.com> <569E3109.8090107@oracle.com> <569EA0A9.8050406@oracle.com> <569F52B8.7020802@oracle.com> <56C3310C.2020008@oracle.com> Message-ID: <56C37C6E.3070306@oracle.com> So you implemented Vladimir Ivanov's suggestion. Okay but you should add a check that it did not finish the loop by checking _num value. Imaging very fast machine that will take less then 2 sec to finish loop without safepoint. Thanks, Vladimir On 2/16/16 6:24 AM, Andreas Eriksson wrote: > Hi, > > I've changed the test so it will not timeout, by using the > WhiteBox.forceSafepoint() in a separate thread. > If there is a safepoint in the loop, then the test will exit after > taking one safepoint. > If instead all safepoints in the loop were removed, then the safepoint > operation will timeout after two seconds (because of > -XX:+SafepointTimeout) and it will be detected and the test will fail. > > Webrev: http://cr.openjdk.java.net/~aeriksso/8146096/webrev.00/ > > Regards, > Andreas > > On 2016-01-20 10:26, Andreas Eriksson wrote: >> Vladimir Kozlov and Vladimir Ivanov, >> >> Ok, I'll look into using the whitebox api to fix the test. >> Thanks for looking at this. >> >> - Andreas >> >> On 2016-01-19 21:46, Vladimir Kozlov wrote: >>> Simple use timeout to check for generated safepoint is bad idea. It >>> is very inaccurate. At least you need to check call stack to see if >>> it stopped in compiled method. >>> I would prefer to see WB new interface which would check that loop >>> SafePointNode is generated during compilation of method. It will be >>> precise. >>> >>> And we need such tests to make sure a feature is working - we can't >>> remove them. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/19/16 4:50 AM, Vladimir Ivanov wrote: >>>> As an idea to improve the test: spawn a thread which executes the >>>> counted loop and then use WhiteBox.forceSafepoint() to >>>> trigger a safepoint. >>>> >>>> If the test times out, it means there's no safepoint in the loop. >>>> >>>> Also, it also simplifies the implementation - no need to spawn a >>>> child process, the check can be done in-process. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 1/19/16 3:32 PM, Andreas Eriksson wrote: >>>>> Hi, >>>>> >>>>> Can I please have a review for the removal of >>>>> hotspot/test/compiler/loopopts/UseCountedLoopSafepoints.java. >>>>> >>>>> The test needs to do a loop that takes more than two seconds to >>>>> execute >>>>> fully without doing a safepointing call. For this expensive atomic >>>>> operations were used. The problem is that on certain embedded >>>>> platforms >>>>> they are too expensive, and the test times out. >>>>> The loop length could probably be reduced, and it should still work on >>>>> faster machines. However, the test is not very useful, so I think it's >>>>> better to just remove it to avoid future problems. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146096 >>>>> Test to be removed: >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/d84a55e7aaf8/test/compiler/loopopts/UseCountedLoopSafepoints.java >>>>> >>>>> >>>>> (I can create a webrev if you think it necessary.) >>>>> >>>>> Thanks, >>>>> Andreas >> > From tom.rodriguez at oracle.com Tue Feb 16 20:25:31 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 16 Feb 2016 12:25:31 -0800 Subject: RFR(S) 8149969: [JVMCI] PrintNMethods is ignored for CompilerToVM.installCode when not called from the broker Message-ID: http://cr.openjdk.java.net/~never/8149969/webrev/index.html CompilerToVM.installCode can be used without going through the CompileBroker which will bypass the PrintNMethods machinery there so make sure it?s get?s printed in this case. I factored out the logic slightly to avoid more duplication. Tested with -XX:+PrintNMethods and print directives. tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Feb 16 21:45:24 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Feb 2016 13:45:24 -0800 Subject: RFR(S) 8149969: [JVMCI] PrintNMethods is ignored for CompilerToVM.installCode when not called from the broker In-Reply-To: References: Message-ID: <56C39874.4040702@oracle.com> Looks good. Thanks, Vladimir On 2/16/16 12:25 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8149969/webrev/index.html > > CompilerToVM.installCode can be used without going through the > CompileBroker which will bypass the PrintNMethods machinery there so > make sure it?s get?s printed in this case. I factored out the logic > slightly to avoid more duplication. Tested with -XX:+PrintNMethods and > print directives. > > tom From john.r.rose at oracle.com Tue Feb 16 22:18:39 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 16 Feb 2016 14:18:39 -0800 Subject: On external_word_Relocation and StubCodeDesc In-Reply-To: <56C36D0B.5040007@oracle.com> References: <56C1F0BC.7090700@oracle.com> <56C25597.7010306@oracle.com> <56C3167D.2070605@oracle.com> <56C34CAC.3070105@oracle.com> <56C36D0B.5040007@oracle.com> Message-ID: On Feb 16, 2016, at 10:40 AM, Vladimir Ivanov wrote: > > I'm inclined to completely remove Relocation::runtime_address_to_index. I'll prepare a webrev and send it out for review. I think that's OK. It's really just a solution waiting for a problem. Anyway, there are better ways to reduce footprint in the reloc. records. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Wed Feb 17 08:14:15 2016 From: dean.long at oracle.com (Dean Long) Date: Wed, 17 Feb 2016 00:14:15 -0800 Subject: RFR(S): 6378256: Performance problem with System.identityHashCode in client compiler In-Reply-To: <9108388b-c080-4bda-ad5d-e177c396a988@default> References: <7B6F2230-90B3-4BF2-8EBA-CF4B58FCE5BB@oracle.com> <8cecd05b-37b5-4cc7-b3f1-d8fa7ca027a8@default> <907A99AD-0BA9-469B-B8E6-D2253F95C068@oracle.com> <9108388b-c080-4bda-ad5d-e177c396a988@default> Message-ID: <56C42BD7.8020305@oracle.com> Looks good. dl On 2/15/2016 12:52 AM, Rahul Raghavan wrote: > Hi, > > Yes, Thank you for the points Roland. > Changes and testing done. > > Latest webrev for review: http://cr.openjdk.java.net/~thartmann/6378256/webrev.05/ > > Thanks, > Rahul > >> -----Original Message----- >> From: Roland Westrelin > Sent: Thursday, February 11, 2016 7:50 PM > To: Rahul Raghavan > Cc: hotspot-compiler-dev at openjdk.java.net >> >> Hi Rahul, >> >>> webrev: http://cr.openjdk.java.net/~thartmann/6378256/webrev.04/ >> Thanks for the updated webrev. >> >> It would be better if he declaration of inline_check_hashcode_from_object_header() is private. When it?s called: >> >> SharedRuntime::inline_check_hashcode_from_object_header() >> >> SharedRuntime:: is useless: >> >> inline_check_hashcode_from_object_header() >> >> is sufficient. >> >> Roland. >> >>> New changes done here are - >>> i. added new inline_check_hashcode_from_object_header() in SharedRuntime class [sharedRuntime.hpp] guarded with 'X86 && >> COMPILER1' >>> ii. required comment text justification done. >>> >>> Confirmed no issues with jprt testing (-testset hotspot) and unit tests. >>> >>> Thank you, >>> Rahul >>> >>>> -----Original Message----- >>>> From: Roland Westrelin > Sent: Monday, February 08, 2016 11:00 PM > To: Rahul Raghavan > Cc: hotspot-compiler- >> dev at openjdk.java.net >>>> Hi Rahul, >>>> >>>>> Please review revised patch, notes for JDK-6378256. >>>>> https://bugs.openjdk.java.net/browse/JDK-6378256 >>>>> >>>>> >>>>> Latest webrev-03: http://cr.openjdk.java.net/~thartmann/6378256/webrev.03/ >>>> Thanks for making the change. I would say it?s better to add inline_check_hashcode_from_object_header() to sharedRuntime.hpp >>>> with #ifdef X86 rather than have the inline declaration. Not sure what others think. >>>> >>>>>>> Can you justify the comments again? >>>> I meant justify as text justification that is right align that comment: >>>> >>>> 36 // --------------------------------------------------------------------------- >>>> 37 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word >>>> 38 // instead of doing a full VM transition once it's been computed. >>>> 39 // Since hashCode is usually polymorphic at call sites we can't do >>>> 40 // this optimization at the call site without a lot of work. >>>> >>>> and that comment >>>> >>>> 2019 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word >>>> 2020 // instead of doing a full VM transition once it's been computed. >>>> 2021 // Since hashCode is usually polymorphic at call sites we can't do >>>> 2022 // this optimization at the call site without a lot of work. >>>> >>>> Sorry for the confusion. The code looks good to me/ >>>> >>>> Roland. >>>> >>>> From rahul.v.raghavan at oracle.com Wed Feb 17 08:24:06 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 17 Feb 2016 00:24:06 -0800 (PST) Subject: RFR(S): 6378256: Performance problem with System.identityHashCode in client compiler In-Reply-To: <56C42BD7.8020305@oracle.com> References: <7B6F2230-90B3-4BF2-8EBA-CF4B58FCE5BB@oracle.com> <8cecd05b-37b5-4cc7-b3f1-d8fa7ca027a8@default> <907A99AD-0BA9-469B-B8E6-D2253F95C068@oracle.com> <9108388b-c080-4bda-ad5d-e177c396a988@default> <56C42BD7.8020305@oracle.com> Message-ID: <39891084-d8b2-4c57-a781-2aa6666c2a27@default> Thank you Dean. > -----Original Message----- > From: Dean Long > Sent: Wednesday, February 17, 2016 1:44 PM > To: Rahul Raghavan; Roland Westrelin; hotspot-compiler-dev at openjdk.java.net > > Looks good. > > dl > > On 2/15/2016 12:52 AM, Rahul Raghavan wrote: > > Hi, > > > > Yes, Thank you for the points Roland. > > Changes and testing done. > > > > Latest webrev for review: http://cr.openjdk.java.net/~thartmann/6378256/webrev.05/ > > > > Thanks, > > Rahul > > > >> -----Original Message----- > >> From: Roland Westrelin > Sent: Thursday, February 11, 2016 7:50 PM > To: Rahul Raghavan > Cc: hotspot-compiler- > dev at openjdk.java.net > >> > >> Hi Rahul, > >> > >>> webrev: http://cr.openjdk.java.net/~thartmann/6378256/webrev.04/ > >> Thanks for the updated webrev. > >> > >> It would be better if he declaration of inline_check_hashcode_from_object_header() is private. When it?s called: > >> > >> SharedRuntime::inline_check_hashcode_from_object_header() > >> > >> SharedRuntime:: is useless: > >> > >> inline_check_hashcode_from_object_header() > >> > >> is sufficient. > >> > >> Roland. > >> > >>> New changes done here are - > >>> i. added new inline_check_hashcode_from_object_header() in SharedRuntime class [sharedRuntime.hpp] guarded with 'X86 > && > >> COMPILER1' > >>> ii. required comment text justification done. > >>> > >>> Confirmed no issues with jprt testing (-testset hotspot) and unit tests. > >>> > >>> Thank you, > >>> Rahul > >>> > >>>> -----Original Message----- > >>>> From: Roland Westrelin > Sent: Monday, February 08, 2016 11:00 PM > To: Rahul Raghavan > Cc: hotspot-compiler- > >> dev at openjdk.java.net > >>>> Hi Rahul, > >>>> > >>>>> Please review revised patch, notes for JDK-6378256. > >>>>> https://bugs.openjdk.java.net/browse/JDK-6378256 > >>>>> > >>>>> > >>>>> Latest webrev-03: http://cr.openjdk.java.net/~thartmann/6378256/webrev.03/ > >>>> Thanks for making the change. I would say it?s better to add inline_check_hashcode_from_object_header() to > sharedRuntime.hpp > >>>> with #ifdef X86 rather than have the inline declaration. Not sure what others think. > >>>> > >>>>>>> Can you justify the comments again? > >>>> I meant justify as text justification that is right align that comment: > >>>> > >>>> 36 // --------------------------------------------------------------------------- > >>>> 37 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word > >>>> 38 // instead of doing a full VM transition once it's been computed. > >>>> 39 // Since hashCode is usually polymorphic at call sites we can't do > >>>> 40 // this optimization at the call site without a lot of work. > >>>> > >>>> and that comment > >>>> > >>>> 2019 // Object.hashCode, System.identityHashCode can pull the hashCode from the header word > >>>> 2020 // instead of doing a full VM transition once it's been computed. > >>>> 2021 // Since hashCode is usually polymorphic at call sites we can't do > >>>> 2022 // this optimization at the call site without a lot of work. > >>>> > >>>> Sorry for the confusion. The code looks good to me/ > >>>> > >>>> Roland. > >>>> > >>>> > From roland.westrelin at oracle.com Wed Feb 17 10:09:29 2016 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 17 Feb 2016 11:09:29 +0100 Subject: RFR(S): 8148786: xml.tranform fails on x86-64 In-Reply-To: <56C208CF.1010700@oracle.com> References: <75A71E7B-0876-4296-AB34-E8BFB0EF2184@oracle.com> <56C208CF.1010700@oracle.com> Message-ID: <806215C3-EB89-474F-AAA4-686B43401967@oracle.com> Thanks for looking at this, Vladimir. > CmpI and Bool nodes could have several users (your code is looking on first one only). > Should we go through all uses and if they different counted loops put their Phi on worklist? Here is a new webrev: http://cr.openjdk.java.net/~roland/8148786/webrev.01/ Roland. From martin.doerr at sap.com Wed Feb 17 10:10:44 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 17 Feb 2016 10:10:44 +0000 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56BE7AAC.3060006@oracle.com> References: <56BE24A5.2060203@oracle.com> <56BE24FA.3080100@oracle.com> <56BE7AAC.3060006@oracle.com> Message-ID: Hi, is it allowed to add a public method to MutableBigInteger in jdk8u? I guess this will need additional approval. Alternatively, the method "static long inverseMod64(long val)" could be moved into BigInteger.java as private method. Otherwise, the jdk8u change looks good. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Samstag, 13. Februar 2016 01:37 To: Vladimir Kempik ; hotspot-compiler-dev at openjdk.java.net Subject: Re: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic Looks fine but you need to send this to jdk8u-dev at openjdk.java.net to get approval for backport. Vladimir On 2/12/16 10:31 AM, Vladimir Kempik wrote: > Webrev for jdk part: > http://cr.openjdk.java.net/~vkempik/8130150/webrev_jdk.00/ > > > On 12.02.2016 21:29, Vladimir Kempik wrote: >> Hello >> >> Please review this backport of 8130150 to jdk8u. >> >> Implement BigInteger.montgomeryMultiply intrinsic >> >> The patch didn't apply cleanly, some changes were needed. Most of them are just to make patch apply, except one. >> for MACC and MACC2 defines, __asm__ were changed to asm, to make solaris compiler (SS12U1) happy. >> >> The patch has two parts, for jdk and hotspot. >> >> Testing: jprt, testcase. >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8130150 >> Webrev:http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.00/ >> >> Thanks >> -Vladimir > From volker.simonis at gmail.com Wed Feb 17 10:50:04 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Feb 2016 11:50:04 +0100 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: References: <56BE24A5.2060203@oracle.com> <56BE24FA.3080100@oracle.com> <56BE7AAC.3060006@oracle.com> Message-ID: Hi Martin, I think adding a public method to MutableBigInteger is fine because MutableBigInteger is package private. So adding methods to it wouldn't change the public API. Regards, Volker On Wed, Feb 17, 2016 at 11:10 AM, Doerr, Martin wrote: > Hi, > > is it allowed to add a public method to MutableBigInteger in jdk8u? > > I guess this will need additional approval. Alternatively, the method "static long inverseMod64(long val)" could be moved into BigInteger.java as private method. > > Otherwise, the jdk8u change looks good. > > Best regards, > Martin > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Samstag, 13. Februar 2016 01:37 > To: Vladimir Kempik ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic > > Looks fine but you need to send this to jdk8u-dev at openjdk.java.net to > get approval for backport. > > Vladimir > > On 2/12/16 10:31 AM, Vladimir Kempik wrote: >> Webrev for jdk part: >> http://cr.openjdk.java.net/~vkempik/8130150/webrev_jdk.00/ >> >> >> On 12.02.2016 21:29, Vladimir Kempik wrote: >>> Hello >>> >>> Please review this backport of 8130150 to jdk8u. >>> >>> Implement BigInteger.montgomeryMultiply intrinsic >>> >>> The patch didn't apply cleanly, some changes were needed. Most of them are just to make patch apply, except one. >>> for MACC and MACC2 defines, __asm__ were changed to asm, to make solaris compiler (SS12U1) happy. >>> >>> The patch has two parts, for jdk and hotspot. >>> >>> Testing: jprt, testcase. >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8130150 >>> Webrev:http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.00/ >>> >>> Thanks >>> -Vladimir >> From vladimir.kempik at oracle.com Wed Feb 17 13:15:16 2016 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Wed, 17 Feb 2016 16:15:16 +0300 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C23270.9040308@oracle.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com> Message-ID: <56C47264.3010103@oracle.com> Hello BigIntegerTest pass with jdk9 (solX64) Compiler used to build jdk9 on soalris - 12u3, jdk7/8 - 12u1. Fastdebug fails same way. Only working with -Xint which is obvious. Thanks. Vladimir. On 15.02.2016 23:17, Vladimir Kozlov wrote: > Do all these tests pass with jdk9? > > I would suggest to run slowdebug and fastdebug to see if optimization > level has affect. then it is definitely compiler bug. > > Andrew can we make MACC and MACC2 as method (with force inline) > instead of macros? > > Vladimir, you may need to backport JDK-8139907. > > Thanks, > Vladimir > > On 2/15/16 5:06 AM, Vladimir Kempik wrote: >> Hello >> >> Sorry I spoke too soon last friday. >> >> Not all tests pass. >> >> On solaris x64 the testcase fails, also BigIntegerTest and >> ModPow65537 tests failed. >> I've changed asm to asm volatile for MACC and MACC2 and tried solaris >> x64 again. >> >> Now the testcase pass, ModPow65537 pass. BigIntegerTest still fails, >> but only partially: >> >> java BigIntegerTest >> Mersenne prime 3 failed. >> Mersenne prime 4 failed. >> Mersenne prime 5 failed. >> Mersenne prime 6 failed. >> Prime: Failed(4) >> nextProbablePrime: Passed >> Arithmetic I for 100 bits: Passed >> Arithmetic II for 100 bits: Passed >> Arithmetic I for 2760 bits: Passed >> ..... >> Do you have a clue what else could be missing for solaris x64? >> Is asm volatile safe for MACC and MACC2 or better to keep it volatile >> only for solaris x64? >> >> Thanks, Vladimir. >> >> >> On 13.02.2016 3:35, Vladimir Kozlov wrote: >>> Hotspot changes looks good to me. >>> >>> Thanks, >>> Vladimir >>> >>> On 2/12/16 10:29 AM, Vladimir Kempik wrote: >>>> Hello >>>> >>>> Please review this backport of 8130150 to jdk8u. >>>> >>>> Implement BigInteger.montgomeryMultiply intrinsic >>>> >>>> The patch didn't apply cleanly, some changes were needed. Most of >>>> them are just to make patch apply, except one. >>>> for MACC and MACC2 defines, __asm__ were changed to asm, to make >>>> solaris compiler (SS12U1) happy. >>>> >>>> The patch has two parts, for jdk and hotspot. >>>> >>>> Testing: jprt, testcase. >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8130150 >>>> Webrev:http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.00/ >>>> >>>> Thanks >>>> -Vladimir >>>> >> From andreas.eriksson at oracle.com Wed Feb 17 13:15:56 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 17 Feb 2016 14:15:56 +0100 Subject: RFR(S): 8146096: [TEST BUG] compiler/loopopts/UseCountedLoopSafepoints.java Timeouts In-Reply-To: <56C37C6E.3070306@oracle.com> References: <569E2CDE.3060805@oracle.com> <569E3109.8090107@oracle.com> <569EA0A9.8050406@oracle.com> <569F52B8.7020802@oracle.com> <56C3310C.2020008@oracle.com> <56C37C6E.3070306@oracle.com> Message-ID: <56C4728C.3020106@oracle.com> Hi, On 2016-02-16 20:45, Vladimir Kozlov wrote: > So you implemented Vladimir Ivanov's suggestion. Yes, and also added whitebox API calls to make sure that the method is C2 compiled, so checking the call stack shouldn't be necessary. Regarding your suggestion on a new WB interface: I wasn't sure on how to do use WB to check that a SafePointNode was generated. It looks to me like WB isn't hooked in to the actual compilation steps, but instead IsMethodCompiled etc. just lookup fields on the nmethod, at a point where we don't have access to the Ideal graph anymore. So adding an interface to actually hook into the Ideal graph to check for a SafePointNode seemed like a big investment for this test. If I've misunderstood what you meant, or if there actually is an easy way to do this, please let me know. > Okay but you should add a check that it did not finish the loop by > checking _num value. Imaging very fast machine that will take less > then 2 sec to finish loop without safepoint. Changed it so it throws an exception if the loop is ever finished. New webrev: http://cr.openjdk.java.net/~aeriksso/8146096/webrev.01/ Diff: http://cr.openjdk.java.net/~aeriksso/8146096/webrev.00.to.01/ Regards, Andreas > > Thanks, > Vladimir > > On 2/16/16 6:24 AM, Andreas Eriksson wrote: >> Hi, >> >> I've changed the test so it will not timeout, by using the >> WhiteBox.forceSafepoint() in a separate thread. >> If there is a safepoint in the loop, then the test will exit after >> taking one safepoint. >> If instead all safepoints in the loop were removed, then the safepoint >> operation will timeout after two seconds (because of >> -XX:+SafepointTimeout) and it will be detected and the test will fail. >> >> Webrev: http://cr.openjdk.java.net/~aeriksso/8146096/webrev.00/ >> >> Regards, >> Andreas >> >> On 2016-01-20 10:26, Andreas Eriksson wrote: >>> Vladimir Kozlov and Vladimir Ivanov, >>> >>> Ok, I'll look into using the whitebox api to fix the test. >>> Thanks for looking at this. >>> >>> - Andreas >>> >>> On 2016-01-19 21:46, Vladimir Kozlov wrote: >>>> Simple use timeout to check for generated safepoint is bad idea. It >>>> is very inaccurate. At least you need to check call stack to see if >>>> it stopped in compiled method. >>>> I would prefer to see WB new interface which would check that loop >>>> SafePointNode is generated during compilation of method. It will be >>>> precise. >>>> >>>> And we need such tests to make sure a feature is working - we can't >>>> remove them. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/19/16 4:50 AM, Vladimir Ivanov wrote: >>>>> As an idea to improve the test: spawn a thread which executes the >>>>> counted loop and then use WhiteBox.forceSafepoint() to >>>>> trigger a safepoint. >>>>> >>>>> If the test times out, it means there's no safepoint in the loop. >>>>> >>>>> Also, it also simplifies the implementation - no need to spawn a >>>>> child process, the check can be done in-process. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 1/19/16 3:32 PM, Andreas Eriksson wrote: >>>>>> Hi, >>>>>> >>>>>> Can I please have a review for the removal of >>>>>> hotspot/test/compiler/loopopts/UseCountedLoopSafepoints.java. >>>>>> >>>>>> The test needs to do a loop that takes more than two seconds to >>>>>> execute >>>>>> fully without doing a safepointing call. For this expensive atomic >>>>>> operations were used. The problem is that on certain embedded >>>>>> platforms >>>>>> they are too expensive, and the test times out. >>>>>> The loop length could probably be reduced, and it should still >>>>>> work on >>>>>> faster machines. However, the test is not very useful, so I think >>>>>> it's >>>>>> better to just remove it to avoid future problems. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146096 >>>>>> Test to be removed: >>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/d84a55e7aaf8/test/compiler/loopopts/UseCountedLoopSafepoints.java >>>>>> >>>>>> >>>>>> >>>>>> (I can create a webrev if you think it necessary.) >>>>>> >>>>>> Thanks, >>>>>> Andreas >>> >> From aph at redhat.com Wed Feb 17 13:18:31 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 17 Feb 2016 13:18:31 +0000 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C47264.3010103@oracle.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com> <56C47264.3010103@oracle.com> Message-ID: <56C47327.3060708@redhat.com> On 02/17/2016 01:15 PM, Vladimir Kempik wrote: > BigIntegerTest pass with jdk9 (solX64) > > Compiler used to build jdk9 on soalris - 12u3, jdk7/8 - 12u1. > > Fastdebug fails same way. Only working with -Xint which is obvious. And this is the same C++ compiler, compiling the same C++ source? Andrew. From vladimir.kempik at oracle.com Wed Feb 17 13:22:45 2016 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Wed, 17 Feb 2016 16:22:45 +0300 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C47327.3060708@redhat.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com> <56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com> Message-ID: <56C47425.3020404@oracle.com> No. It's slightly newer c++ compiler compiling same c++ source. Only obvious difference is how they process asm inlines. solaris studio compiler is compatible with gcc asm inlines, but some caveats might exist. Right now I plan to replace asm inlines with slower c++ code to see if it matters. Vladimir. On 17.02.2016 16:18, Andrew Haley wrote: > And this is the same C++ compiler, compiling the same C++ source? From aph at redhat.com Wed Feb 17 13:26:03 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 17 Feb 2016 13:26:03 +0000 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C47425.3020404@oracle.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com> <56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com> <56C47425.3020404@oracle.com> Message-ID: <56C474EB.8070908@redhat.com> On 02/17/2016 01:22 PM, Vladimir Kempik wrote: > It's slightly newer c++ compiler compiling same c++ source. > > Only obvious difference is how they process asm inlines. solaris studio > compiler is compatible with gcc asm inlines, but some caveats might exist. Okay. I did test this pretty carefully on Solaris studio when I wrote it, but I suppose there might have been a compiler-related regression. > Right now I plan to replace asm inlines with slower c++ code to see if > it matters. Fair enough. Please keep me in the loop. Andrew. From aleksey.shipilev at oracle.com Wed Feb 17 13:33:56 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 17 Feb 2016 16:33:56 +0300 Subject: RFR(S): 8146828: Subsequent arraycopy does not always eliminate array zeroing In-Reply-To: References: <86A6E1D0-F2CB-4A36-B6C8-77B12FDEF169@oracle.com> <56BD1CD8.4090308@oracle.com> Message-ID: <56C476C4.2050101@oracle.com> Hi Roland, On 02/12/2016 06:23 PM, Roland Westrelin wrote: > Thanks for taking a look at this, Vladimir. > >> Yes, it is complicated code with assumptions not covered by comments. >> >> Needs more comments in place where you check too_many_traps to explain why such reasons are checked (this bug description). > > Here is a new webrev with more comments: > http://cr.openjdk.java.net/~roland/8146828/webrev.01/ This patch indeed improves the benchmark from the bug report. However, the ArrayList.toArray case from which the benchmark was derived is not improving. To follow up further I have updated the benchmark with more cases: http://cr.openjdk.java.net/~shade/8146828/ArrayZeroingBench.java http://cr.openjdk.java.net/~shade/8146828/benchmarks.jar The test cases from the previous benchmarks are now known as "*_backtoback" -- and they are indeed improving a lot, due to the absence of zeroing. ArrayList.toArray case is closer to "field_generic_inline", although it may turn into "field_generic_dontinline" if inlining hiccups -- and it had not improved. Another thing that concerns me is that "base" case that does not cover the destination array in full: @Benchmark public Foo[] base() { Foo[] dst = new Foo[size]; System.arraycopy(src, 0, dst, 0, size - 1); return dst; } ...now eliminates zeroing. This sounds like a functional bug. Cheers, -Aleksey -------------------------------------------------------------------------- *** Original hs-comp: Benchmark (size) Mode Cnt Score Error Units # Eliminate zeroing copyOf_field 1000 avgt 15 670.242 ? 7.064 ns/op copyOf_srcLength 1000 avgt 15 663.790 ? 4.337 ns/op srcLength_backtoback 1000 avgt 15 678.564 ? 16.078 ns/op # Have zeroing base 1000 avgt 15 899.566 ? 10.140 ns/op dstLength_backtoback 1000 avgt 15 901.168 ? 7.448 ns/op dstLength_dontinline 1000 avgt 15 893.555 ? 6.441 ns/op dstLength_generic_dontinline 1000 avgt 15 906.428 ? 12.023 ns/op dstLength_generic_inline 1000 avgt 15 890.435 ? 5.727 ns/op dstLength_inline 1000 avgt 15 893.364 ? 6.754 ns/op field_backtoback 1000 avgt 15 896.103 ? 6.933 ns/op field_dontinline 1000 avgt 15 895.276 ? 5.245 ns/op field_generic_dontinline 1000 avgt 15 913.208 ? 33.095 ns/op field_generic_inline 1000 avgt 15 896.768 ? 19.996 ns/op field_inline 1000 avgt 15 893.639 ? 5.799 ns/op srcLength_dontinline 1000 avgt 15 900.281 ? 9.121 ns/op srcLength_generic_dontinline 1000 avgt 15 894.431 ? 6.684 ns/op srcLength_generic_inline 1000 avgt 15 899.178 ? 12.900 ns/op srcLength_inline 1000 avgt 15 897.053 ? 5.433 ns/op -------------------------------------------------------------------------- *** Patched hs-comp: Benchmark (size) Mode Cnt Score Error Units # Eliminate zeroing base 1000 avgt 15 686.523 ? 6.865 ns/op copyOf_field 1000 avgt 15 682.847 ? 11.112 ns/op copyOf_srcLength 1000 avgt 15 676.604 ? 6.397 ns/op dstLength_backtoback 1000 avgt 15 673.739 ? 8.046 ns/op field_backtoback 1000 avgt 15 684.339 ? 16.042 ns/op srcLength_backtoback 1000 avgt 15 668.501 ? 7.876 ns/op # Have zeroing dstLength_dontinline 1000 avgt 15 898.067 ? 7.785 ns/op dstLength_generic_dontinline 1000 avgt 15 897.727 ? 12.140 ns/op dstLength_generic_inline 1000 avgt 15 893.653 ? 7.720 ns/op dstLength_inline 1000 avgt 15 892.346 ? 5.594 ns/op field_dontinline 1000 avgt 15 898.671 ? 10.030 ns/op field_generic_dontinline 1000 avgt 15 899.473 ? 6.913 ns/op field_generic_inline 1000 avgt 15 898.713 ? 19.982 ns/op field_inline 1000 avgt 15 905.791 ? 14.564 ns/op srcLength_dontinline 1000 avgt 15 903.012 ? 11.919 ns/op srcLength_generic_dontinline 1000 avgt 15 894.738 ? 8.232 ns/op srcLength_generic_inline 1000 avgt 15 905.205 ? 18.927 ns/op srcLength_inline 1000 avgt 15 920.086 ? 20.310 ns/op -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From konstantin.shefov at oracle.com Wed Feb 17 13:53:29 2016 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 17 Feb 2016 16:53:29 +0300 Subject: [9] RFR JDK-8141616: Add new methods to the java Whitebox API Message-ID: <56C47B59.5090606@oracle.com> Hello Please review some new methods added to the sun.hotspot.WhiteBox API. These methods are needed to test JVMCI CompilerToVM methods, see https://bugs.openjdk.java.net/browse/JDK-8138708 for more info. Bug: https://bugs.openjdk.java.net/browse/JDK-8141616 Webrev for java part: http://cr.openjdk.java.net/~kshefov/8141616/root/webrev.00/ Webrev for native part: http://cr.openjdk.java.net/~kshefov/8141616/hotspot/webrev.00/ Thanks -Konstantin From konstantin.shefov at oracle.com Wed Feb 17 13:57:44 2016 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 17 Feb 2016 16:57:44 +0300 Subject: [9] RFR JDK-8141618: Change JVMCI compilerToVM constant pool tests to support CP caching Message-ID: <56C47C58.9090104@oracle.com> Hello Please review a test enhancement. It is an improvement for JVMCI CompilerToVM class tests. See https://bugs.openjdk.java.net/browse/JDK-8138708 for more info. Bug: https://bugs.openjdk.java.net/browse/JDK-8141618 Webrev: http://cr.openjdk.java.net/~kshefov/8141618/webrev.00/ Thanks -Konstantin From konstantin.shefov at oracle.com Wed Feb 17 14:00:41 2016 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 17 Feb 2016 17:00:41 +0300 Subject: [9] RFR JDK-8141619: Develop new tests for JVMCI compilerToVM class' CP related methods Message-ID: <56C47D09.4030006@oracle.com> Hello Please review new tests for methods of JVMCI jdk.vm.ci.hotspot.CompilerToVM class. See https://bugs.openjdk.java.net/browse/JDK-8138708 for more info. Bug: https://bugs.openjdk.java.net/browse/JDK-8141619 Webrev: http://cr.openjdk.java.net/~kshefov/8141619/webrev.00/ Thanks -Konstantin From felix.yang at linaro.org Wed Feb 17 14:11:33 2016 From: felix.yang at linaro.org (Felix Yang) Date: Wed, 17 Feb 2016 22:11:33 +0800 Subject: [aarch64-port-dev ] RFR: 8149907: aarch64: use load/store pair instructions in call_stub In-Reply-To: <56C30C2E.4080206@redhat.com> References: <56C30C2E.4080206@redhat.com> Message-ID: Hi Andrew, Thanks for the suggestions. I have updated the patch with the unused locals removed. New webrev: http://cr.openjdk.java.net/~fyang/8149907/webrev.01/ How about this one? Thanks for your help, Felix On 16 February 2016 at 19:46, Andrew Haley wrote: > On 02/16/2016 11:28 AM, Felix Yang wrote: > > Please review the following webrev: > > http://cr.openjdk.java.net/~fyang/8149907/webrev.00/ > > I guess this is okay, but it's a lot less self-documenting than it > was. > > If there are any unused locals (e.g. r27_save) you must delete > them or use them in assertions. > > Andrew. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Feb 17 14:16:10 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 17 Feb 2016 14:16:10 +0000 Subject: [aarch64-port-dev ] RFR: 8149907: aarch64: use load/store pair instructions in call_stub In-Reply-To: References: <56C30C2E.4080206@redhat.com> Message-ID: <56C480AA.2090606@redhat.com> On 02/17/2016 02:11 PM, Felix Yang wrote: > Thanks for the suggestions. I have updated the patch with the unused > locals removed. > New webrev: http://cr.openjdk.java.net/~fyang/8149907/webrev.01/ > How about this one? What are r19_off and its friends used for now? Why are they still defined? Andrew. From felix.yang at linaro.org Wed Feb 17 14:33:21 2016 From: felix.yang at linaro.org (Felix Yang) Date: Wed, 17 Feb 2016 22:33:21 +0800 Subject: RFR: 8150038: aarch64: make use of CBZ and CBNZ when comparing narrow pointer with zero Message-ID: Hi, Please review the following webrev: *http://cr.openjdk.java.net/~fyang/8150038/webrev.00/ * Jira issue: *https://bugs.openjdk.java.net/browse/JDK-8150038 * For several times I noticed the following pattern in C2 JIT code (the java heap size is set to 200MB): 2042 0x0000007f6c9419c4: ldr w14, [x11,#32] ;*getfield buffer 2048 0x0000007f6c9419c8: cmp w14, wzr 2049 0x0000007f6c9419cc: b.eq 0x0000007f6c9425e4 ;*invokevirtual reset The two cmp and b.eq instructions can be combined into one "cbz" instruction. Currently, the aarch64 port only makes use of CBZ and CBNZ when comparing operands with Integer/Long/Pointer type with zero. Patch fixes the issue by adding one similar combine pattern in the AD file for Narrow pointer types(just like the sparc port does). Tested with jtreg hotspot & langtools. Is it OK? Thanks, Felix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.punegov at oracle.com Wed Feb 17 14:39:16 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 17 Feb 2016 17:39:16 +0300 Subject: RFR (XXS): 8144621: CompilerControl: inline tests timeout with Xcomp In-Reply-To: <56C35F61.2090704@oracle.com> References: <4245B7A0-D8AA-4623-9F73-F794B00F15A6@oracle.com> <56C1FFD6.2050708@oracle.com> <56C35F61.2090704@oracle.com> Message-ID: <5F04063F-DD82-4CA0-81C9-567092C0D0B7@oracle.com> Thank you for review, Vladimir & Nils. I filed a new issue to add Xmixed to all tests that need it: https://bugs.openjdk.java.net/browse/JDK-8150054 and going to make a fix soon ? Pavel. > On 16 Feb 2016, at 20:41, Nils Eliasson wrote: > > > On 2016-02-15 17:41, Vladimir Kozlov wrote: >> Should we fix tests with *.* commands instead? Could you, please, list those tests (I want to look)? May be add -Xmixed if they don't like -Xcomp? Or use real method's names instead of *.*? > > +1 on adding -Xmixed to all the compiler control tests. Xcomp doesn't add any value to these tests. > > Otherwise - looks good. > > Thanks for fixing! > Nils Eliasson > >> >> Thanks, >> Vladimir >> >> On 2/15/16 8:26 AM, Pavel Punegov wrote: >>> Hi, >>> >>> please review this small fix for CompilerControl tests. >>> >>> Issue: tests that generate commands like "inline *.*" (-XX:CompileCommand or directives) with Xcomp make compilers >>> forcibly inline everything. This significantly increases execution time leading to timeout. >>> Fix: don?t generated *.* patterns at all for such tests. It will also makes tests that use PrintAssembly to not fail >>> with OOME by decreasing of the amount of output. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8144621 >>> webrev: http://cr.openjdk.java.net/~ppunegov/8144621/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Wed Feb 17 14:52:38 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 17 Feb 2016 20:22:38 +0530 Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash In-Reply-To: <56C3221D.2040507@oracle.com> References: <56BC90DC.10004@oracle.com> <56BD8DF9.1070605@oracle.com> <56BE1274.4020506@oracle.com> <41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com> <56C3221D.2040507@oracle.com> Message-ID: <56C48936.4090303@oracle.com> experimental and diagnostic flags are under condition checks now. http://cr.openjdk.java.net/~thartmann/8145333/webrev.03/ Best Regards, Jamsheed On 2/16/2016 6:50 PM, Jamsheed C m wrote: > Hi Chris, > > Revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/ > > This code take care of every jvmci flags automatically. > > Best Regards, > Jamsheed > > On 2/13/2016 3:24 AM, Christian Thalinger wrote: >> >>> On Feb 12, 2016, at 7:12 AM, Jamsheed C m >>> wrote: >>> >>> >>> Hi Chris, >>> >>> On 2/12/2016 10:12 PM, Christian Thalinger wrote: >>>> Well, now you have to manually check all flags that had >>>> a constraint directive. That is the annoying part and what I >>>> complained about in: >>> check against original value, and if not fail ? >> >> Same check for all flags; they all depend on +EnableJVMCI. >> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8145357 >>>> >>>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now empty >>>> and I think we should remove them. >>> i kept the file as there can be future use. Ok, i will remove it. >>> >>> Best Regards, >>> Jamsheed >>>> >>>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m >>>> > wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> revised webrev: >>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/ >>>>> >>>>> Best Regards, >>>>> Jamsheed >>>>> >>>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote: >>>>>> >>>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Request for review >>>>>>> >>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333 >>>>>>> web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ >>>>>> >>>>>> That looks alright but we should remove the constraints from all >>>>>> the JVMCI command line flags because the way we use them is not >>>>>> supported. >>>>>> >>>>>> Also, can you change the error message? Right now it looks like >>>>>> this: >>>>>> >>>>>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java >>>>>> -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler >>>>>> EnableJVMCI must be enabled >>>>>> Improperly specified VM option 'UseJVMCICompiler' >>>>>> Error: Could not create the Java Virtual Machine. >>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>> >>>>>> I think with your changes we will only see the first line without >>>>>> mentioning UseJVMCICompiler. Is that correct? >>>>>> >>>>>>> >>>>>>> Fix Summary: added jvmci flag consistency check after arg parsing. >>>>>>> >>>>>>> tests: jprt >>>>>>> unit test: command line verification >>>>>>> >>>>>>> Best Regards, >>>>>>> Jamsheed >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Feb 17 15:07:26 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 17 Feb 2016 15:07:26 +0000 Subject: [aarch64-port-dev ] RFR: 8150038: aarch64: make use of CBZ and CBNZ when comparing narrow pointer with zero In-Reply-To: References: Message-ID: <56C48CAE.9040704@redhat.com> On 02/17/2016 02:33 PM, Felix Yang wrote: > Tested with jtreg hotspot & langtools. Is it OK? Sure, that looks fine. Thanks, Andrew. From vladimir.x.ivanov at oracle.com Wed Feb 17 15:21:49 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 17 Feb 2016 18:21:49 +0300 Subject: [9] RFR (M): 8149741: Don't refer to stub entry points by index in external_word relocations Message-ID: <56C4900D.6080708@oracle.com> http://cr.openjdk.java.net/~vlivanov/8149741/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8149741 As a followup on the discussion about using indexes instead of raw addresses in external relocations [1], here's the request for removal of the corresponding logic. To ease reviewing I splitted the changes into 3 groups: (1) http://cr.openjdk.java.net/~vlivanov/8149741/webrev.00.removal/ Get rid of runtime_address_to_index/index_to_runtime_address functions and adjust pack_data_to/unpack_data in external_word_Relocation to operate on raw addresses. (2) http://cr.openjdk.java.net/~vlivanov/8149741/webrev.00.cleanup/ Different cleanups in StubCodeDesc implementation. Simplified iteration over the list and PrintStubCode support. (3) http://cr.openjdk.java.net/~vlivanov/8149741/webrev.00.index/ Cleaned up some outdated usages of ExternalAddress. Its constructor adjusts relocation type according to address. For NULL address it doesn't create a relocation and there's no need in special cases then. Also, I looked through all ExternalAddress usages, but didn't find any places where values which aren't external addresses are used [2]. So, I converted is_reloc_index check into an assert in external_word_Relocation::can_be_relocated(). Let me know if you see any problems with that. Testing: hotspot regression tests, JPRT. Thanks! Best regards, Vladimir Ivanov [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021354.html [2] static relocInfo::relocType reloc_for_target(address target) { // Sometimes ExternalAddress is used for values which aren't // exactly addresses, like the card table base. // external_word_type can't be used for values in the first page // so just skip the reloc in that case. return external_word_Relocation::can_be_relocated(target) ? relocInfo::external_word_type : relocInfo::none; } From pavel.punegov at oracle.com Wed Feb 17 15:52:17 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 17 Feb 2016 18:52:17 +0300 Subject: RFR(S): 8148159: [TESTBUG] TestCompilerDirectivesCompatibility tests fails on non-tiered server VMs In-Reply-To: <56C31DA9.3070607@oracle.com> References: <56C31DA9.3070607@oracle.com> Message-ID: <115A77CE-C62D-4749-8E4A-2EE4A2F662AB@oracle.com> Hi Nils, Do we need hasC1/2Compiler methods? There is a compiler.tstlibrary.CompilerUtils class that provides tests with available levels. There is an example of usage in test/compiler/compilercontrol/share/actions/CompileAction.java. Also, what about JVMCI in case of hasC2Compiler? AFAIK it works with levels, but I don?t know if it will with such ifdef. Otherwise, it looks good (not a Reviewer) > On 16 Feb 2016, at 16:01, Nils Eliasson wrote: > > Hi, > > Please review this change. > > The tests relied on C1 always being available and thus fails on C2 only server configurations. The fix adds two whitebox methods for checking if C1 and C2 is available, and then tests both compilers separately. Also adding Xmixed to the commandline since this test doesn't need Xcomp testing. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8148159 > > Webrev: > http://cr.openjdk.java.net/~neliasso/8148159/webrev.01/ > http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.01/ > > Regards, > Nils Eliasson ? Thanks, Pavel Punegov -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Fri Feb 12 18:51:13 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 12 Feb 2016 21:51:13 +0300 Subject: [8u-dev] Request for approval to backport: 8081778: Use Intel x64 CPU instructions for RSA acceleration Message-ID: <56BE29A1.1040207@oracle.com> Hello! I'm seeking an approval to backport this performance enhancement to jdk8u-dev. The change applies *almost* cleanly. The only change I had to make was adding the extra argument to the 'new' operator, which is required in jdk8, but not jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-8081778 Jdk9 hotspot change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/578f086f3435 Jdk9 jdk change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/de309dbe42bf Jdk9 review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-May/018106.html The changes, comparing to jdk9 are in hotspot/src/share/vm/opto/library_call.cpp at lines #5956 and #5964; Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8081778/00/webrev/ Patched Jdk was successfully built and tested on all supported platforms. Would you please approve this backport? Sincerely yours, Ivan From david.buck at oracle.com Tue Feb 16 07:45:24 2016 From: david.buck at oracle.com (david buck) Date: Tue, 16 Feb 2016 16:45:24 +0900 Subject: [8u] Request for approval: Backport of 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException In-Reply-To: <56C2C8B5.6020709@oracle.com> References: <56C197AB.3050208@oracle.com> <56C20721.5020001@oracle.com> <56C2C8B5.6020709@oracle.com> Message-ID: <56C2D394.7020903@oracle.com> approved for backport to 8u-dev (assuming changeset applies cleanly to 8u-dev forest) Cheers, -Buck On 2016/02/16 15:59, Tobias Hartmann wrote: > Thanks, Vladimir. > > Best, > Tobias > > On 15.02.2016 18:13, Vladimir Kozlov wrote: >> Looks good. >> >> Thanks, >> Vladimir >> >> On 2/15/16 1:17 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please approve and review the following backport to 8u. >>> >>> 8148752: Compiled StringBuilder code throws StringIndexOutOfBoundsException >>> https://bugs.openjdk.java.net/browse/JDK-8148752 >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021176.html >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4130663a3de8 >>> >>> The fix was pushed to hs-comp last week and nightly testing showed no problems. >>> >>> Thanks, >>> Tobias >>> From tom.rodriguez at oracle.com Wed Feb 17 18:03:24 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 17 Feb 2016 10:03:24 -0800 Subject: RFR(S) 8150075: [JVMCI] expose reserved stack machinery and Inline flag in HotSpotVMConfig Message-ID: <84A70EFC-C905-4A98-9F76-C4E463642BAD@oracle.com> http://cr.openjdk.java.net/~never/8150075/webrev/index.html JVMCI compilers need access to the reserved stack machinery and the Inline flag to properly run tests. Tested with Graal using these new fields. tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kempik at oracle.com Wed Feb 17 18:19:35 2016 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Wed, 17 Feb 2016 21:19:35 +0300 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C474EB.8070908@redhat.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com> <56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com> <56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com> Message-ID: <56C4B9B7.80800@oracle.com> Hello I have replaced sub, MACC and MACC2 by c++ version (also changed MACC from defines to inline functions, so changed call to MACC and t0,t1,t2 passed by reference) and getting same result, except linux amd64 is failing same way now. So it's probably not asm code that's an issue. I think my C code works because another test we use to measure speed of BigInteger operations still has 3x improvement in time and it supposed to check the result. http://cr.openjdk.java.net/~vkempik/8130150/asmInC.txt Could it be alloca failing? btw, Andrew, in sub asm inline, you modify CF (with clc) but didnt use "cc" at end of asm to notify compiler about it, not sure if that needed tho. On 17.02.2016 16:26, Andrew Haley wrote: > On 02/17/2016 01:22 PM, Vladimir Kempik wrote: >> It's slightly newer c++ compiler compiling same c++ source. >> >> Only obvious difference is how they process asm inlines. solaris studio >> compiler is compatible with gcc asm inlines, but some caveats might exist. > Okay. I did test this pretty carefully on Solaris studio when I wrote > it, but I suppose there might have been a compiler-related regression. > >> Right now I plan to replace asm inlines with slower c++ code to see if >> it matters. > Fair enough. Please keep me in the loop. > > Andrew. > From vladimir.kozlov at oracle.com Wed Feb 17 18:22:47 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Feb 2016 10:22:47 -0800 Subject: RFR(S): 8148786: xml.tranform fails on x86-64 In-Reply-To: <806215C3-EB89-474F-AAA4-686B43401967@oracle.com> References: <75A71E7B-0876-4296-AB34-E8BFB0EF2184@oracle.com> <56C208CF.1010700@oracle.com> <806215C3-EB89-474F-AAA4-686B43401967@oracle.com> Message-ID: <56C4BA77.3090901@oracle.com> Looks good. Thanks, Vladimir On 2/17/16 2:09 AM, Roland Westrelin wrote: > Thanks for looking at this, Vladimir. > >> CmpI and Bool nodes could have several users (your code is looking on first one only). >> Should we go through all uses and if they different counted loops put their Phi on worklist? > > Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8148786/webrev.01/ > > Roland. > From aph at redhat.com Wed Feb 17 18:33:22 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 17 Feb 2016 18:33:22 +0000 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C4B9B7.80800@oracle.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com> <56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com> <56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com> <56C4B9B7.80800@oracle.com> Message-ID: <56C4BCF2.9050302@redhat.com> On 02/17/2016 06:19 PM, Vladimir Kempik wrote: > I have replaced sub, MACC and MACC2 by c++ version (also changed MACC > from defines to inline functions, so changed call to MACC and t0,t1,t2 > passed by reference) and getting same result, except linux amd64 is > failing same way now. So it's probably not asm code that's an issue. OK. > I think my C code works because another test we use to measure speed > of BigInteger operations still has 3x improvement in time and it > supposed to check the result. It's extremely hard to write this stuff in portable C. I can't tell for sure if your code is correct. It looks reasonable enough. > http://cr.openjdk.java.net/~vkempik/8130150/asmInC.txt > > Could it be alloca failing? Seems very unlikley. What would be really helpful would be if you could capture what was passed to montgomeryMultiply when the test case fails. You can perhaps print out all arguments as a string of hex digits inside montgomeryMultiply. Then we can debug it. The real error might be much higher up, though: perhaps some problem with the way the builtin is expanded. > btw, Andrew, in sub asm inline, you modify CF (with clc) but didnt use > "cc" at end of asm to notify compiler about it, not sure if that needed tho. I already said that in an earlier message. Needs to clobber "cc". Andrew. From christian.thalinger at oracle.com Wed Feb 17 18:43:51 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Feb 2016 08:43:51 -1000 Subject: [9] RFR JDK-8141618: Change JVMCI compilerToVM constant pool tests to support CP caching In-Reply-To: <56C47C58.9090104@oracle.com> References: <56C47C58.9090104@oracle.com> Message-ID: <68AEB7F8-14A8-4BC5-B910-501E2980F646@oracle.com> Why do you have to break every line at, what, 50 characters? This is unreadable: + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.CLASS, + ConstantTypes.CONSTANT_CLASS); + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.FIELDREF, + ConstantTypes.CONSTANT_FIELDREF); + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.METHODREF, + ConstantTypes.CONSTANT_METHODREF); + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.INTERFACEMETHODREF, + ConstantTypes.CONSTANT_INTERFACEMETHODREF); + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.STRING, + ConstantTypes.CONSTANT_STRING); + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.INTEGER, + ConstantTypes.CONSTANT_INTEGER); + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.FLOAT, + ConstantTypes.CONSTANT_FLOAT); + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.LONG, + ConstantTypes.CONSTANT_LONG); + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.DOUBLE, And this is not the only occurrence. I can?t review this. > On Feb 17, 2016, at 3:57 AM, Konstantin Shefov wrote: > > Hello > > Please review a test enhancement. > It is an improvement for JVMCI CompilerToVM class tests. > > See https://bugs.openjdk.java.net/browse/JDK-8138708 for more info. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8141618 > Webrev: http://cr.openjdk.java.net/~kshefov/8141618/webrev.00/ > > Thanks > -Konstantin From christian.thalinger at oracle.com Wed Feb 17 18:46:26 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Feb 2016 08:46:26 -1000 Subject: [9] RFR JDK-8141619: Develop new tests for JVMCI compilerToVM class' CP related methods In-Reply-To: <56C47D09.4030006@oracle.com> References: <56C47D09.4030006@oracle.com> Message-ID: > On Feb 17, 2016, at 4:00 AM, Konstantin Shefov wrote: > > Hello > > Please review new tests for methods of JVMCI jdk.vm.ci.hotspot.CompilerToVM class. > > See https://bugs.openjdk.java.net/browse/JDK-8138708 for more info. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8141619 > Webrev: http://cr.openjdk.java.net/~kshefov/8141619/webrev.00/ Link is wrong: http://cr.openjdk.java.net/~kshefov/8141619/webrev/ > > Thanks > -Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Feb 17 18:51:27 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Feb 2016 10:51:27 -0800 Subject: RFR(S) 8150075: [JVMCI] expose reserved stack machinery and Inline flag in HotSpotVMConfig In-Reply-To: <84A70EFC-C905-4A98-9F76-C4E463642BAD@oracle.com> References: <84A70EFC-C905-4A98-9F76-C4E463642BAD@oracle.com> Message-ID: <56C4C12F.2060902@oracle.com> Looks good. Thanks, Vladimir On 2/17/16 10:03 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8150075/webrev/index.html > > JVMCI compilers need access to the reserved stack machinery and the Inline flag to properly run tests. Tested with > Graal using these new fields. > > tom From christian.thalinger at oracle.com Wed Feb 17 19:06:16 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Feb 2016 09:06:16 -1000 Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash In-Reply-To: <56C48936.4090303@oracle.com> References: <56BC90DC.10004@oracle.com> <56BD8DF9.1070605@oracle.com> <56BE1274.4020506@oracle.com> <41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com> <56C3221D.2040507@oracle.com> <56C48936.4090303@oracle.com> Message-ID: > On Feb 17, 2016, at 4:52 AM, Jamsheed C m wrote: > > experimental and diagnostic flags are under condition checks now. > > http://cr.openjdk.java.net/~thartmann/8145333/webrev.03/ I?m not very happy about the new macros but I can see why it?s useful. +#if INCLUDE_JVMCI + +// Check consistency of jvmci vm argument settings. +bool Arguments::check_jvmci_args_consistency() { + + + if (!EnableJVMCI && is_any_jvmci_arg_values_changed()) { + print_jvmci_arg_inconsistency_error_message(); + return false; Please remove all these empty lines. There are others as well. +bool is_any_jvmci_arg_values_changed() { This method needs another name. + int check_count = 0, fail_count = 0; I don?t like the check_count/fail_count logic because it?s fragile. +// Check if any jvmci global defaults changed. +bool is_any_jvmci_arg_values_changed(); +// Print jvmci args inconsistency error message. +void print_jvmci_arg_inconsistency_error_message(); These should be in some kind of namespace or class. Maybe put them into: class JVMCIGlobals > > > Best Regards, > Jamsheed > > On 2/16/2016 6:50 PM, Jamsheed C m wrote: >> Hi Chris, >> >> Revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/ >> >> This code take care of every jvmci flags automatically. >> >> Best Regards, >> Jamsheed >> >> On 2/13/2016 3:24 AM, Christian Thalinger wrote: >>> >>>> On Feb 12, 2016, at 7:12 AM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote: >>>> >>>> >>>> Hi Chris, >>>> >>>> On 2/12/2016 10:12 PM, Christian Thalinger wrote: >>>>> Well, now you have to manually check all flags that had a constraint directive. That is the annoying part and what I complained about in: >>>> check against original value, and if not fail ? >>> >>> Same check for all flags; they all depend on +EnableJVMCI. >>> >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8145357 >>>>> >>>>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now empty and I think we should remove them. >>>> i kept the file as there can be future use. Ok, i will remove it. >>>> >>>> Best Regards, >>>> Jamsheed >>>>> >>>>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m > wrote: >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/ >>>>>> >>>>>> Best Regards, >>>>>> Jamsheed >>>>>> >>>>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote: >>>>>>> >>>>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Request for review >>>>>>>> >>>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333 >>>>>>>> web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ >>>>>>> >>>>>>> That looks alright but we should remove the constraints from all the JVMCI command line flags because the way we use them is not supported. >>>>>>> >>>>>>> Also, can you change the error message? Right now it looks like this: >>>>>>> >>>>>>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler >>>>>>> EnableJVMCI must be enabled >>>>>>> Improperly specified VM option 'UseJVMCICompiler' >>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>> >>>>>>> I think with your changes we will only see the first line without mentioning UseJVMCICompiler. Is that correct? >>>>>>> >>>>>>>> >>>>>>>> Fix Summary: added jvmci flag consistency check after arg parsing. >>>>>>>> >>>>>>>> tests: jprt >>>>>>>> unit test: command line verification >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Jamsheed >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Wed Feb 17 19:10:56 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Feb 2016 09:10:56 -1000 Subject: RFR(S) 8150075: [JVMCI] expose reserved stack machinery and Inline flag in HotSpotVMConfig In-Reply-To: <84A70EFC-C905-4A98-9F76-C4E463642BAD@oracle.com> References: <84A70EFC-C905-4A98-9F76-C4E463642BAD@oracle.com> Message-ID: Why not put the documentation for hasReservedStackAccess on the interface method? Otherwise looks good. > On Feb 17, 2016, at 8:03 AM, Tom Rodriguez wrote: > > http://cr.openjdk.java.net/~never/8150075/webrev/index.html > > JVMCI compilers need access to the reserved stack machinery and the Inline flag to properly run tests. Tested with Graal using these new fields. > > tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.rodriguez at oracle.com Wed Feb 17 22:02:34 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 17 Feb 2016 14:02:34 -0800 Subject: RFR(S) 8150075: [JVMCI] expose reserved stack machinery and Inline flag in HotSpotVMConfig In-Reply-To: References: <84A70EFC-C905-4A98-9F76-C4E463642BAD@oracle.com> Message-ID: <4F4796C7-04A9-4C85-9EEC-7AA979956C0A@oracle.com> Just forgot to copy it there. It seems to exist in both places for these methods. I?ll add it. Thanks! tom > On Feb 17, 2016, at 11:10 AM, Christian Thalinger wrote: > > Why not put the documentation for hasReservedStackAccess on the interface method? Otherwise looks good. > >> On Feb 17, 2016, at 8:03 AM, Tom Rodriguez > wrote: >> >> http://cr.openjdk.java.net/~never/8150075/webrev/index.html >> >> JVMCI compilers need access to the reserved stack machinery and the Inline flag to properly run tests. Tested with Graal using these new fields. >> >> tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.rodriguez at oracle.com Wed Feb 17 22:22:30 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 17 Feb 2016 14:22:30 -0800 Subject: RFR(S) 8150075: [JVMCI] expose reserved stack machinery and Inline flag in HotSpotVMConfig In-Reply-To: <4F4796C7-04A9-4C85-9EEC-7AA979956C0A@oracle.com> References: <84A70EFC-C905-4A98-9F76-C4E463642BAD@oracle.com> <4F4796C7-04A9-4C85-9EEC-7AA979956C0A@oracle.com> Message-ID: It?s there now. http://cr.openjdk.java.net/~never/8150075.01/webrev/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java.udiff.html tom > On Feb 17, 2016, at 2:02 PM, Tom Rodriguez wrote: > > Just forgot to copy it there. It seems to exist in both places for these methods. I?ll add it. Thanks! > > tom > >> On Feb 17, 2016, at 11:10 AM, Christian Thalinger > wrote: >> >> Why not put the documentation for hasReservedStackAccess on the interface method? Otherwise looks good. >> >>> On Feb 17, 2016, at 8:03 AM, Tom Rodriguez > wrote: >>> >>> http://cr.openjdk.java.net/~never/8150075/webrev/index.html >>> >>> JVMCI compilers need access to the reserved stack machinery and the Inline flag to properly run tests. Tested with Graal using these new fields. >>> >>> tom >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Wed Feb 17 23:05:36 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 18 Feb 2016 02:05:36 +0300 Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted arrays Message-ID: <56C4FCC0.2010809@oracle.com> Hi, Please review a small tuneup in C1 arraylength folding: https://bugs.openjdk.java.net/browse/JDK-8150102 http://cr.openjdk.java.net/~shade/8150102/webrev.00 After this patch, C1 successfully folds the general arraylength accesses. In the end, this lets to fold String.length() for constant Strings: http://cr.openjdk.java.net/~shade/8150102/FoldArrayLength.java I am actually wondering if as_LoadField path is ever hit in applications, because the targeted microbenchmark for static final array had improved with new as_Constant path. Testing: JPRT -testset hotspot (half of the platforms completed, now infra is stalled), microbenchmarks Cheers, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From christian.thalinger at oracle.com Wed Feb 17 23:53:45 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Feb 2016 13:53:45 -1000 Subject: RFR(S) 8150075: [JVMCI] expose reserved stack machinery and Inline flag in HotSpotVMConfig In-Reply-To: References: <84A70EFC-C905-4A98-9F76-C4E463642BAD@oracle.com> <4F4796C7-04A9-4C85-9EEC-7AA979956C0A@oracle.com> Message-ID: <6CC547D3-7799-4D8E-9CFC-76E2B31FF97D@oracle.com> Looks good. > On Feb 17, 2016, at 12:22 PM, Tom Rodriguez wrote: > > It?s there now. http://cr.openjdk.java.net/~never/8150075.01/webrev/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java.udiff.html > > tom > >> On Feb 17, 2016, at 2:02 PM, Tom Rodriguez > wrote: >> >> Just forgot to copy it there. It seems to exist in both places for these methods. I?ll add it. Thanks! >> >> tom >> >>> On Feb 17, 2016, at 11:10 AM, Christian Thalinger > wrote: >>> >>> Why not put the documentation for hasReservedStackAccess on the interface method? Otherwise looks good. >>> >>>> On Feb 17, 2016, at 8:03 AM, Tom Rodriguez > wrote: >>>> >>>> http://cr.openjdk.java.net/~never/8150075/webrev/index.html >>>> >>>> JVMCI compilers need access to the reserved stack machinery and the Inline flag to properly run tests. Tested with Graal using these new fields. >>>> >>>> tom >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Thu Feb 18 00:54:21 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 18 Feb 2016 06:24:21 +0530 Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler -XX:-EnableJVMCI makes JVM crash In-Reply-To: References: <56BC90DC.10004@oracle.com> <56BD8DF9.1070605@oracle.com> <56BE1274.4020506@oracle.com> <41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com> <56C3221D.2040507@oracle.com> <56C48936.4090303@oracle.com> Message-ID: <56C5163D.7010208@oracle.com> On 2/18/2016 12:36 AM, Christian Thalinger wrote: > >> On Feb 17, 2016, at 4:52 AM, Jamsheed C m > > wrote: >> >> experimental and diagnostic flags are under condition checks now. >> >> http://cr.openjdk.java.net/~thartmann/8145333/webrev.03/ >> > > I?m not very happy about the new macros but I can see why it?s useful. > > +#if INCLUDE_JVMCI > + > +// Check consistency of jvmci vm argument settings. > +bool Arguments::check_jvmci_args_consistency() { > + > + > + if (!EnableJVMCI && is_any_jvmci_arg_values_changed()) { > + print_jvmci_arg_inconsistency_error_message(); > + return false; > > Please remove all these empty lines. There are others as well. > > +bool is_any_jvmci_arg_values_changed() { > > This method needs another name. > Ok. > + int check_count = 0, fail_count = 0; > > I don?t like the check_count/fail_count logic because it?s fragile. As EanbleJVMCI flag cannot be avoided from macro expansion logic, i had to use some technique to exclude this flag from failure decision making. Check_count/fail_count logic was added as a solution for this. i.e When EnableJVMCI is changed, code requires at-least 2 check failures to decide a real failure. otherwise one failure is sufficient. if i remove this logic, i will have to use strcmp(#FLAG, "EnableJVMCI") which will add a little more instructions that will execute at-least once for every flag consistent run. let me know if i need to take second approach. or if existing code is ok. > > +// Check if any jvmci global defaults changed. > +bool is_any_jvmci_arg_values_changed(); > +// Print jvmci args inconsistency error message. > +void print_jvmci_arg_inconsistency_error_message(); > > These should be in some kind of namespace or class. Maybe put them > into: class JVMCIGlobals Ok. Best Regards, Jamsheed > >> >> >> Best Regards, >> Jamsheed >> >> On 2/16/2016 6:50 PM, Jamsheed C m wrote: >>> Hi Chris, >>> >>> Revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/ >>> >>> This code take care of every jvmci flags automatically. >>> >>> Best Regards, >>> Jamsheed >>> >>> On 2/13/2016 3:24 AM, Christian Thalinger wrote: >>>> >>>>> On Feb 12, 2016, at 7:12 AM, Jamsheed C m >>>>> wrote: >>>>> >>>>> >>>>> Hi Chris, >>>>> >>>>> On 2/12/2016 10:12 PM, Christian Thalinger wrote: >>>>>> Well, now you have to manually check all flags that had >>>>>> a constraint directive. That is the annoying part and what I >>>>>> complained about in: >>>>> check against original value, and if not fail ? >>>> >>>> Same check for all flags; they all depend on +EnableJVMCI. >>>> >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8145357 >>>>>> >>>>>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now >>>>>> empty and I think we should remove them. >>>>> i kept the file as there can be future use. Ok, i will remove it. >>>>> >>>>> Best Regards, >>>>> Jamsheed >>>>>> >>>>>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m >>>>>>> > wrote: >>>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> revised webrev: >>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/ >>>>>>> >>>>>>> Best Regards, >>>>>>> Jamsheed >>>>>>> >>>>>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote: >>>>>>>> >>>>>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Request for review >>>>>>>>> >>>>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333 >>>>>>>>> web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ >>>>>>>> >>>>>>>> That looks alright but we should remove the constraints from >>>>>>>> all the JVMCI command line flags because the way we use them is >>>>>>>> not supported. >>>>>>>> >>>>>>>> Also, can you change the error message? Right now it looks >>>>>>>> like this: >>>>>>>> >>>>>>>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java >>>>>>>> -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler >>>>>>>> EnableJVMCI must be enabled >>>>>>>> Improperly specified VM option 'UseJVMCICompiler' >>>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>>> >>>>>>>> I think with your changes we will only see the first line >>>>>>>> without mentioning UseJVMCICompiler. Is that correct? >>>>>>>> >>>>>>>>> >>>>>>>>> Fix Summary: added jvmci flag consistency check after arg parsing. >>>>>>>>> >>>>>>>>> tests: jprt >>>>>>>>> unit test: command line verification >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Jamsheed >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Feb 18 03:09:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Feb 2016 19:09:56 -0800 Subject: [9] RFR JDK-8141616: Add new methods to the java Whitebox API In-Reply-To: <56C47B59.5090606@oracle.com> References: <56C47B59.5090606@oracle.com> Message-ID: <56C53604.8040107@oracle.com> Looks good. Thanks, Vladimir On 2/17/16 5:53 AM, Konstantin Shefov wrote: > Hello > > Please review some new methods added to the sun.hotspot.WhiteBox API. > These methods are needed to test JVMCI CompilerToVM methods, see > https://bugs.openjdk.java.net/browse/JDK-8138708 for more info. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8141616 > Webrev for java part: > http://cr.openjdk.java.net/~kshefov/8141616/root/webrev.00/ > Webrev for native part: > http://cr.openjdk.java.net/~kshefov/8141616/hotspot/webrev.00/ > > Thanks > -Konstantin From vladimir.kozlov at oracle.com Thu Feb 18 03:17:50 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Feb 2016 19:17:50 -0800 Subject: RFR(S): 8146096: [TEST BUG] compiler/loopopts/UseCountedLoopSafepoints.java Timeouts In-Reply-To: <56C4728C.3020106@oracle.com> References: <569E2CDE.3060805@oracle.com> <569E3109.8090107@oracle.com> <569EA0A9.8050406@oracle.com> <569F52B8.7020802@oracle.com> <56C3310C.2020008@oracle.com> <56C37C6E.3070306@oracle.com> <56C4728C.3020106@oracle.com> Message-ID: <56C537DE.5060806@oracle.com> nmethod has flags which record some compilation information: // set during construction unsigned int _has_unsafe_access:1; // May fault due to unsafe access. unsigned int _has_method_handle_invokes:1; // Has this method MethodHandle invokes? unsigned int _lazy_critical_native:1; // Lazy JNI critical native unsigned int _has_wide_vectors:1; // Preserve wide vectors at safepoints I thought about extending it. It could be difficult to justify adding a flag just for testing but if we add it only for debug VM it should be fine. Do we do WB testing only with [fast]debug VM? Anyway, I agree with your exception after loop - changes are fine now. Reviewed. Thanks, Vladimir On 2/17/16 5:15 AM, Andreas Eriksson wrote: > Hi, > > On 2016-02-16 20:45, Vladimir Kozlov wrote: >> So you implemented Vladimir Ivanov's suggestion. > > Yes, and also added whitebox API calls to make sure that the method is > C2 compiled, so checking the call stack shouldn't be necessary. > > Regarding your suggestion on a new WB interface: > I wasn't sure on how to do use WB to check that a SafePointNode was > generated. It looks to me like WB isn't hooked in to the actual > compilation steps, but instead IsMethodCompiled etc. just lookup fields > on the nmethod, at a point where we don't have access to the Ideal graph > anymore. So adding an interface to actually hook into the Ideal graph to > check for a SafePointNode seemed like a big investment for this test. > If I've misunderstood what you meant, or if there actually is an easy > way to do this, please let me know. > >> Okay but you should add a check that it did not finish the loop by >> checking _num value. Imaging very fast machine that will take less >> then 2 sec to finish loop without safepoint. > > Changed it so it throws an exception if the loop is ever finished. > New webrev: http://cr.openjdk.java.net/~aeriksso/8146096/webrev.01/ > Diff: http://cr.openjdk.java.net/~aeriksso/8146096/webrev.00.to.01/ > > Regards, > Andreas > >> >> Thanks, >> Vladimir >> >> On 2/16/16 6:24 AM, Andreas Eriksson wrote: >>> Hi, >>> >>> I've changed the test so it will not timeout, by using the >>> WhiteBox.forceSafepoint() in a separate thread. >>> If there is a safepoint in the loop, then the test will exit after >>> taking one safepoint. >>> If instead all safepoints in the loop were removed, then the safepoint >>> operation will timeout after two seconds (because of >>> -XX:+SafepointTimeout) and it will be detected and the test will fail. >>> >>> Webrev: http://cr.openjdk.java.net/~aeriksso/8146096/webrev.00/ >>> >>> Regards, >>> Andreas >>> >>> On 2016-01-20 10:26, Andreas Eriksson wrote: >>>> Vladimir Kozlov and Vladimir Ivanov, >>>> >>>> Ok, I'll look into using the whitebox api to fix the test. >>>> Thanks for looking at this. >>>> >>>> - Andreas >>>> >>>> On 2016-01-19 21:46, Vladimir Kozlov wrote: >>>>> Simple use timeout to check for generated safepoint is bad idea. It >>>>> is very inaccurate. At least you need to check call stack to see if >>>>> it stopped in compiled method. >>>>> I would prefer to see WB new interface which would check that loop >>>>> SafePointNode is generated during compilation of method. It will be >>>>> precise. >>>>> >>>>> And we need such tests to make sure a feature is working - we can't >>>>> remove them. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/19/16 4:50 AM, Vladimir Ivanov wrote: >>>>>> As an idea to improve the test: spawn a thread which executes the >>>>>> counted loop and then use WhiteBox.forceSafepoint() to >>>>>> trigger a safepoint. >>>>>> >>>>>> If the test times out, it means there's no safepoint in the loop. >>>>>> >>>>>> Also, it also simplifies the implementation - no need to spawn a >>>>>> child process, the check can be done in-process. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 1/19/16 3:32 PM, Andreas Eriksson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Can I please have a review for the removal of >>>>>>> hotspot/test/compiler/loopopts/UseCountedLoopSafepoints.java. >>>>>>> >>>>>>> The test needs to do a loop that takes more than two seconds to >>>>>>> execute >>>>>>> fully without doing a safepointing call. For this expensive atomic >>>>>>> operations were used. The problem is that on certain embedded >>>>>>> platforms >>>>>>> they are too expensive, and the test times out. >>>>>>> The loop length could probably be reduced, and it should still >>>>>>> work on >>>>>>> faster machines. However, the test is not very useful, so I think >>>>>>> it's >>>>>>> better to just remove it to avoid future problems. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146096 >>>>>>> Test to be removed: >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/d84a55e7aaf8/test/compiler/loopopts/UseCountedLoopSafepoints.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> (I can create a webrev if you think it necessary.) >>>>>>> >>>>>>> Thanks, >>>>>>> Andreas >>>> >>> > From vladimir.kozlov at oracle.com Thu Feb 18 03:52:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Feb 2016 19:52:35 -0800 Subject: [9] RFR (M): 8149741: Don't refer to stub entry points by index in external_word relocations In-Reply-To: <56C4900D.6080708@oracle.com> References: <56C4900D.6080708@oracle.com> Message-ID: <56C54003.6070603@oracle.com> Nice clean up! On 2/17/16 7:21 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8149741/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8149741 > > As a followup on the discussion about using indexes instead of raw > addresses in external relocations [1], here's the request for removal of > the corresponding logic. > > To ease reviewing I splitted the changes into 3 groups: > > (1) http://cr.openjdk.java.net/~vlivanov/8149741/webrev.00.removal/ Good. > > Get rid of runtime_address_to_index/index_to_runtime_address functions > and adjust pack_data_to/unpack_data in external_word_Relocation to > operate on raw addresses. > > (2) http://cr.openjdk.java.net/~vlivanov/8149741/webrev.00.cleanup/ Good. > > Different cleanups in StubCodeDesc implementation. Simplified iteration > over the list and PrintStubCode support. > > (3) http://cr.openjdk.java.net/~vlivanov/8149741/webrev.00.index/ Casts should be the same: (uintptr_t)target >= (uint)os::vm_page_size() Why in assembler_windows_x86.cpp you used NULL_WORD and not simple NULL? NULL_WORD is used for integer values and NULL for pointers which is this case. Thanks, Vladimir K > > Cleaned up some outdated usages of ExternalAddress. Its constructor > adjusts relocation type according to address. For NULL address it > doesn't create a relocation and there's no need in special cases then. > > Also, I looked through all ExternalAddress usages, but didn't find any > places where values which aren't external addresses are used [2]. So, I > converted is_reloc_index check into an assert in > external_word_Relocation::can_be_relocated(). Let me know if you see any > problems with that. > > Testing: hotspot regression tests, JPRT. > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021354.html > > > [2] > static relocInfo::relocType reloc_for_target(address target) { > // Sometimes ExternalAddress is used for values which aren't > // exactly addresses, like the card table base. > // external_word_type can't be used for values in the first page > // so just skip the reloc in that case. > return external_word_Relocation::can_be_relocated(target) ? > relocInfo::external_word_type : relocInfo::none; > } From aleksey.shipilev at oracle.com Thu Feb 18 07:55:26 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 18 Feb 2016 10:55:26 +0300 Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted arrays In-Reply-To: <56C4FCC0.2010809@oracle.com> References: <56C4FCC0.2010809@oracle.com> Message-ID: <56C578EE.6080702@oracle.com> On 02/18/2016 02:05 AM, Aleksey Shipilev wrote: > Please review a small tuneup in C1 arraylength folding: > https://bugs.openjdk.java.net/browse/JDK-8150102 > http://cr.openjdk.java.net/~shade/8150102/webrev.00 > > After this patch, C1 successfully folds the general arraylength > accesses. In the end, this lets to fold String.length() for constant > Strings: > http://cr.openjdk.java.net/~shade/8150102/FoldArrayLength.java > > I am actually wondering if as_LoadField path is ever hit in > applications, because the targeted microbenchmark for static final array > had improved with new as_Constant path. > > Testing: JPRT -testset hotspot (half of the platforms completed, now > infra is stalled), microbenchmarks Passes JPRT -testset hotspot fine. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vladimir.x.ivanov at oracle.com Thu Feb 18 08:08:39 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 18 Feb 2016 11:08:39 +0300 Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted arrays In-Reply-To: <56C4FCC0.2010809@oracle.com> References: <56C4FCC0.2010809@oracle.com> Message-ID: <56C57C07.2020307@oracle.com> Looks good. On 2/18/16 2:05 AM, Aleksey Shipilev wrote: > Hi, > > Please review a small tuneup in C1 arraylength folding: > https://bugs.openjdk.java.net/browse/JDK-8150102 > http://cr.openjdk.java.net/~shade/8150102/webrev.00 > > After this patch, C1 successfully folds the general arraylength > accesses. In the end, this lets to fold String.length() for constant > Strings: > http://cr.openjdk.java.net/~shade/8150102/FoldArrayLength.java > > I am actually wondering if as_LoadField path is ever hit in > applications, because the targeted microbenchmark for static final array > had improved with new as_Constant path. I don't think it happens. GraphBuilder::access_field already folds loads into constants. Best regards, Vladimir Ivanov From aleksey.shipilev at oracle.com Thu Feb 18 08:16:41 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 18 Feb 2016 11:16:41 +0300 Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted arrays In-Reply-To: <56C57C07.2020307@oracle.com> References: <56C4FCC0.2010809@oracle.com> <56C57C07.2020307@oracle.com> Message-ID: <56C57DE9.9010700@oracle.com> On 02/18/2016 11:08 AM, Vladimir Ivanov wrote: > Looks good. Thanks! > On 2/18/16 2:05 AM, Aleksey Shipilev wrote: >> Hi, >> >> Please review a small tuneup in C1 arraylength folding: >> https://bugs.openjdk.java.net/browse/JDK-8150102 >> http://cr.openjdk.java.net/~shade/8150102/webrev.00 >> >> After this patch, C1 successfully folds the general arraylength >> accesses. In the end, this lets to fold String.length() for constant >> Strings: >> http://cr.openjdk.java.net/~shade/8150102/FoldArrayLength.java >> >> I am actually wondering if as_LoadField path is ever hit in >> applications, because the targeted microbenchmark for static final array >> had improved with new as_Constant path. > I don't think it happens. GraphBuilder::access_field already folds loads > into constants. So, would you like me to strip away as_LoadField path, and place a debug assert there? -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vladimir.x.ivanov at oracle.com Thu Feb 18 08:20:23 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 18 Feb 2016 11:20:23 +0300 Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted arrays In-Reply-To: <56C57DE9.9010700@oracle.com> References: <56C4FCC0.2010809@oracle.com> <56C57C07.2020307@oracle.com> <56C57DE9.9010700@oracle.com> Message-ID: <56C57EC7.7030104@oracle.com> > So, would you like me to strip away as_LoadField path, and place a debug > assert there? Yes, that would be nice. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Thu Feb 18 08:43:24 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 18 Feb 2016 11:43:24 +0300 Subject: [9] RFR (M): 8149741: Don't refer to stub entry points by index in external_word relocations In-Reply-To: <56C54003.6070603@oracle.com> References: <56C4900D.6080708@oracle.com> <56C54003.6070603@oracle.com> Message-ID: <56C5842C.4090009@oracle.com> > Nice clean up! Thanks, Vladimir. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8149741/webrev.01.index/ > > Casts should be the same: > > (uintptr_t)target >= (uint)os::vm_page_size() Fixed. > Why in assembler_windows_x86.cpp you used NULL_WORD and not simple NULL? > NULL_WORD is used for integer values and NULL for pointers > which is this case. Fixed. Best regards, Vladimir Ivanov From aleksey.shipilev at oracle.com Thu Feb 18 09:25:38 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 18 Feb 2016 12:25:38 +0300 Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted arrays In-Reply-To: <56C57EC7.7030104@oracle.com> References: <56C4FCC0.2010809@oracle.com> <56C57C07.2020307@oracle.com> <56C57DE9.9010700@oracle.com> <56C57EC7.7030104@oracle.com> Message-ID: <56C58E12.2050603@oracle.com> On 02/18/2016 11:20 AM, Vladimir Ivanov wrote: >> So, would you like me to strip away as_LoadField path, and place a debug >> assert there? > Yes, that would be nice. Okay: http://cr.openjdk.java.net/~shade/8150102/webrev.01/ JPRT -testset hotspot still passes. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From konstantin.shefov at oracle.com Thu Feb 18 10:43:09 2016 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 18 Feb 2016 13:43:09 +0300 Subject: [9] RFR JDK-8141618: Change JVMCI compilerToVM constant pool tests to support CP caching In-Reply-To: <68AEB7F8-14A8-4BC5-B910-501E2980F646@oracle.com> References: <56C47C58.9090104@oracle.com> <68AEB7F8-14A8-4BC5-B910-501E2980F646@oracle.com> Message-ID: <56C5A03D.9040602@oracle.com> Christian, thanks for looking into this I have reformatted the code to make it look better: http://cr.openjdk.java.net/~kshefov/8141618/webrev.01 -Konstantin On 02/17/2016 09:43 PM, Christian Thalinger wrote: > Why do you have to break every line at, what, 50 characters? This is unreadable: > > + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.CLASS, > + ConstantTypes.CONSTANT_CLASS); > + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.FIELDREF, > + ConstantTypes.CONSTANT_FIELDREF); > + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.METHODREF, > + ConstantTypes.CONSTANT_METHODREF); > + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.INTERFACEMETHODREF, > + ConstantTypes.CONSTANT_INTERFACEMETHODREF); > + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.STRING, > + ConstantTypes.CONSTANT_STRING); > + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.INTEGER, > + ConstantTypes.CONSTANT_INTEGER); > + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.FLOAT, > + ConstantTypes.CONSTANT_FLOAT); > + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.LONG, > + ConstantTypes.CONSTANT_LONG); > + TAG_TO_TYPE_MAP.put(ConstantPool.Tag.DOUBLE, > > And this is not the only occurrence. I can?t review this. > >> On Feb 17, 2016, at 3:57 AM, Konstantin Shefov wrote: >> >> Hello >> >> Please review a test enhancement. >> It is an improvement for JVMCI CompilerToVM class tests. >> >> See https://bugs.openjdk.java.net/browse/JDK-8138708 for more info. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8141618 >> Webrev: http://cr.openjdk.java.net/~kshefov/8141618/webrev.00/ >> >> Thanks >> -Konstantin From konstantin.shefov at oracle.com Thu Feb 18 10:44:27 2016 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 18 Feb 2016 13:44:27 +0300 Subject: [9] RFR JDK-8141619: Develop new tests for JVMCI compilerToVM class' CP related methods In-Reply-To: References: <56C47D09.4030006@oracle.com> Message-ID: <56C5A08B.50001@oracle.com> According to Christian's comments to RFR JDK-8141618 I have reformatted the code to make it look better: http://cr.openjdk.java.net/~kshefov/8141619/webrev.01/ -Konstantin On 02/17/2016 09:46 PM, Christian Thalinger wrote: > >> On Feb 17, 2016, at 4:00 AM, Konstantin Shefov >> > >> wrote: >> >> Hello >> >> Please review new tests for methods of JVMCI >> jdk.vm.ci.hotspot.CompilerToVM class. >> >> See https://bugs.openjdk.java.net/browse/JDK-8138708 for more info. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8141619 >> Webrev: http://cr.openjdk.java.net/~kshefov/8141619/webrev.00/ >> > > Link is wrong: http://cr.openjdk.java.net/~kshefov/8141619/webrev/ > > >> >> Thanks >> -Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Feb 18 11:08:41 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 18 Feb 2016 11:08:41 +0000 Subject: RFR 8149469: ByteBuffer API and implementation enhancements for VarHandles In-Reply-To: <6F457380-0E56-4909-BFBF-B3D6FE45B326@oracle.com> References: <6F457380-0E56-4909-BFBF-B3D6FE45B326@oracle.com> Message-ID: <949FB585-4AF7-4D6D-923C-A336EDFB40ED@oracle.com> On 9 Feb 2016, at 15:05, Paul Sandoz wrote: > Hi, > > This patch contains API and internal enhancements to ByteBuffer: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149469-byte-buffer-align-and-unifying-enhancements/webrev/index.html This is certainly for advanced/power users feature. I expect it may not be used all that widely, but I do see your requirement with VarHandles. A few specific comments: - I find the comment in Buffer.java a little confusing. Specifically where is says that byte[] allocations might no align to a word boundary on 32-bit systems. I think you mean that the alignment will not be 8-byte aligned. I get that slices can be arbitrary. - The changes to set isReadOnly do not seem related, but you explained off-list that these are in preparation for VarHandlers. They seem benign. - The computation in misalignment is based on assumptions about layout, that may, or may not, be valid ( but it is had to see otherwise ). You had suggested that UOE could be thrown here? - Minor spec issue in alignedSlice: "If rounding results in out-of-bound values then this buffers capacity and limit will be zero.?. You mean "the new byte buffer", right? -Chris. > I am CC?ing hotspot-compiler because i want to push to hs-comp to reduce time delays for reviewing/pushing dependent VarHandle patches (which also depends on the Unsafe enhancements currently under review that are also to be pushed to hs-comp). > > > The API enhancements provide support for querying misalignment of an index and unit size, and also slicing a buffer to align for a unit size. Such functionality enables one to set up for aligned access for unit sizes bytes, if supported by the platform. > > The internal enhancements enable consistent use of fields readOnly and address. For the moment i have only enabled consistent use of address for ByteBuffers. > > A primary motivation for these enhancements is too support VarHandles access to ByteBuffer contents. The API enhancement enables access to values at known aligned indexes and therefore provides stronger atomicity guarantees and enhanced atomic accesses that follow from that. The internal enhancement allows VarHandle implementations to uniformly access buffers using the Unsafe double addressing mode [*]. > > I believe these enhancements are also valuable independently of the VarHandles work. Furthermore, the internal enhancements are a stepping stone to potentially consolidating many aspects of heap and direct buffers. > > Thanks, > Paul. > > [*] > For heap buffers > Buffer.address == Unsafe.ARRAY_BYTE_BASE_OFFSET + offset; > ByteBuffer.hb != null, > > For direct buffers > Buffer.address == ; > ByteBuffer.hb == null, From vladimir.kempik at oracle.com Thu Feb 18 11:41:03 2016 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Thu, 18 Feb 2016 14:41:03 +0300 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C4BCF2.9050302@redhat.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com> <56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com> <56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com> <56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com> Message-ID: <56C5ADCF.60805@oracle.com> Hello making this routine to always use montgomery_multiply helped to workaround the issue - if (len >= MONTGOMERY_SQUARING_THRESHOLD) { + if (0) { ::montgomery_square(a, n, m, (unsigned long)inv, longwords); } else { ::montgomery_multiply(a, a, n, m, (unsigned long)inv, longwords); } Vladimir. On 17.02.2016 21:33, Andrew Haley wrote: > On 02/17/2016 06:19 PM, Vladimir Kempik wrote: >> I have replaced sub, MACC and MACC2 by c++ version (also changed MACC >> from defines to inline functions, so changed call to MACC and t0,t1,t2 >> passed by reference) and getting same result, except linux amd64 is >> failing same way now. So it's probably not asm code that's an issue. > OK. > >> I think my C code works because another test we use to measure speed >> of BigInteger operations still has 3x improvement in time and it >> supposed to check the result. > It's extremely hard to write this stuff in portable C. I can't tell > for sure if your code is correct. It looks reasonable enough. > >> http://cr.openjdk.java.net/~vkempik/8130150/asmInC.txt >> >> Could it be alloca failing? > Seems very unlikley. > > What would be really helpful would be if you could capture what was > passed to montgomeryMultiply when the test case fails. > > You can perhaps print out all arguments as a string of hex digits > inside montgomeryMultiply. Then we can debug it. > > The real error might be much higher up, though: perhaps some problem > with the way the builtin is expanded. > >> btw, Andrew, in sub asm inline, you modify CF (with clc) but didnt use >> "cc" at end of asm to notify compiler about it, not sure if that needed tho. > I already said that in an earlier message. Needs to clobber "cc". > > Andrew. From aph at redhat.com Thu Feb 18 11:45:24 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Feb 2016 11:45:24 +0000 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C5ADCF.60805@oracle.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com> <56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com> <56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com> <56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com> <56C5ADCF.60805@oracle.com> Message-ID: <56C5AED4.90601@redhat.com> On 02/18/2016 11:41 AM, Vladimir Kempik wrote: > making this routine to always use montgomery_multiply helped to > workaround the issue OK, so possibly a bug in montgomery_square. I'm not sure what "helped" means, though. I guess it doesn't mean "fixes the bug". Andrew. From vladimir.kempik at oracle.com Thu Feb 18 12:16:05 2016 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Thu, 18 Feb 2016 15:16:05 +0300 Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply intrinsic In-Reply-To: <56C5AED4.90601@redhat.com> References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com> <56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com> <56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com> <56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com> <56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com> <56C5ADCF.60805@oracle.com> <56C5AED4.90601@redhat.com> Message-ID: <56C5B605.6060606@oracle.com> Hello Vladimir Kozlov, do you think I can backport this to jdk8/7 with mentioned workaround (for solaris amd64 only) and then create a bug to investigate why montgomery_square fails with jdk8/7 and solaris studio 12u1 compiler ? It passed the jprt tests now. If so It's ok I'll prepare. Thanks. On 18.02.2016 14:45, Andrew Haley wrote: > On 02/18/2016 11:41 AM, Vladimir Kempik wrote: >> making this routine to always use montgomery_multiply helped to >> workaround the issue > OK, so possibly a bug in montgomery_square. I'm not sure what > "helped" means, though. I guess it doesn't mean "fixes the bug". > > Andrew. > From vladimir.x.ivanov at oracle.com Thu Feb 18 12:56:43 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 18 Feb 2016 15:56:43 +0300 Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted arrays In-Reply-To: <56C58E12.2050603@oracle.com> References: <56C4FCC0.2010809@oracle.com> <56C57C07.2020307@oracle.com> <56C57DE9.9010700@oracle.com> <56C57EC7.7030104@oracle.com> <56C58E12.2050603@oracle.com> Message-ID: <56C5BF8B.1020504@oracle.com> > http://cr.openjdk.java.net/~shade/8150102/webrev.01/ Why don't you fold as_LoadField into the assert? Also, field->is_static() is redundant: ciField::initialize_from does all necessary checks. Something like: + } else { + assert(x->array()->as_LoadField() == NULL || !field->is_constant(), "constant field loads are folded during parsing"); + } Best regards, Vladimir Ivanov PS: I noticed the following check in the original code: - ciObject* c = field->constant_value().as_object(); - if (c->is_array()) { I don't see how !c->is_array() is possible, so it looks like an unnecessary precaution. From aleksey.shipilev at oracle.com Thu Feb 18 13:20:31 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 18 Feb 2016 16:20:31 +0300 Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted arrays In-Reply-To: <56C5BF8B.1020504@oracle.com> References: <56C4FCC0.2010809@oracle.com> <56C57C07.2020307@oracle.com> <56C57DE9.9010700@oracle.com> <56C57EC7.7030104@oracle.com> <56C58E12.2050603@oracle.com> <56C5BF8B.1020504@oracle.com> Message-ID: <56C5C51F.3090403@oracle.com> On 02/18/2016 03:56 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~shade/8150102/webrev.01/ > Why don't you fold as_LoadField into the assert? Because "lf->field()" is polled from as_LoadField: } else if ((lf = x->array()->as_LoadField()) != NULL) { // GraphBuilder should emit Constants in static final case, //let's assert that. ciField* field = lf->field(); assert (!(field->is_constant() && field->is_static()), "Array loads from static final fields should be handled as Constants"); } Granted, we can construct a convoluted short-circuiting boolean expression that folds that, but I think explicitly matching the "type" is cleaner (sucks that our code does not have proper pattern matching). > Also, field->is_static() is redundant: ciField::initialize_from does all > necessary checks. No, it isn't redundant: is_constant() is TRUE for trusted non-static finals, like String.value. The old code predicated on is_static() to pull the constant value without having an instance to introspect. Perhaps, we need to fold (is_constant == TRUE, is_static == FALSE) loads during parsing too to make a stronger assertion? > Something like: > + } else { > + assert(x->array()->as_LoadField() == NULL || !field->is_constant(), > "constant field loads are folded during parsing"); > + } The assert message is good though, stole that! See: http://cr.openjdk.java.net/~shade/8150102/webrev.02/ -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vladimir.x.ivanov at oracle.com Thu Feb 18 14:02:51 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 18 Feb 2016 17:02:51 +0300 Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted arrays In-Reply-To: <56C5C51F.3090403@oracle.com> References: <56C4FCC0.2010809@oracle.com> <56C57C07.2020307@oracle.com> <56C57DE9.9010700@oracle.com> <56C57EC7.7030104@oracle.com> <56C58E12.2050603@oracle.com> <56C5BF8B.1020504@oracle.com> <56C5C51F.3090403@oracle.com> Message-ID: <56C5CF0B.4080807@oracle.com> >> Why don't you fold as_LoadField into the assert? > > Because "lf->field()" is polled from as_LoadField: > > } else if ((lf = x->array()->as_LoadField()) != NULL) { > // GraphBuilder should emit Constants in static final case, > //let's assert that. > ciField* field = lf->field(); > assert (!(field->is_constant() && field->is_static()), > "Array loads from static final fields should be handled as > Constants"); > } > > Granted, we can construct a convoluted short-circuiting boolean > expression that folds that, but I think explicitly matching the "type" > is cleaner (sucks that our code does not have proper pattern matching). Agree, it doesn't look pretty when both is_constant() && is_static() checks are present. Maybe structure it as follows? } else { #ifdef ASSERT LoadField* lf = x->array()->as_LoadField(); bool is_static_constant = (lf != NULL) && lf->field()->is_constant() && lf->field()->is_static(); assert(!is_static_constant, "constant field loads are folded during parsing"); #endif // ASSERT } But choose whatever version you like. I don't have a strong opinion here. >> Also, field->is_static() is redundant: ciField::initialize_from does all >> necessary checks. > > No, it isn't redundant: is_constant() is TRUE for trusted non-static > finals, like String.value. The old code predicated on is_static() to > pull the constant value without having an instance to introspect. > Perhaps, we need to fold (is_constant == TRUE, is_static == FALSE) loads > during parsing too to make a stronger assertion? Yes, you are right. > http://cr.openjdk.java.net/~shade/8150102/webrev.02/ Looks good. Best regards, Vladimir Ivanov From felix.yang at linaro.org Thu Feb 18 15:02:06 2016 From: felix.yang at linaro.org (Felix Yang) Date: Thu, 18 Feb 2016 23:02:06 +0800 Subject: [aarch64-port-dev ] RFR: 8149907: aarch64: use load/store pair instructions in call_stub In-Reply-To: <56C480AA.2090606@redhat.com> References: <56C30C2E.4080206@redhat.com> <56C480AA.2090606@redhat.com> Message-ID: Hi, I updated the webrev with the unused ENUM members removed. New webrev: http://cr.openjdk.java.net/~fyang/8149907/webrev.02/ Thanks, Felix On 17 February 2016 at 22:16, Andrew Haley wrote: > On 02/17/2016 02:11 PM, Felix Yang wrote: > > > Thanks for the suggestions. I have updated the patch with the unused > > locals removed. > > New webrev: http://cr.openjdk.java.net/~fyang/8149907/webrev.01/ > > How about this one? > > What are r19_off and its friends used for now? Why are they still > defined? > > Andrew. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at gmail.com Thu Feb 18 15:31:45 2016 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Thu, 18 Feb 2016 18:31:45 +0300 Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down fastdebug builds' performance In-Reply-To: References: <54F99281.7020101@oracle.com> <56B489D0.3070700@oracle.com> <56BDCF17.30308@oracle.com> Message-ID: Hi, I've looked at how frequently misses are actually occur and how far false positives are from the interval we're looking for. Also I've tried to implement interval_cmp so that it returns 0 if difference between interval "from" values is below some threshold: http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/stats.txt All those misses with distance greater than 64 came from javax.swing.plaf.synth.SynthStyle::populateDefaultValues [1]. I've also looked to another possible slowness sources and we spend about 10% of time in LinearScan's verify_intervals method which checks that every two intervals don't simultaneously intersect and share the same register [2]. I don't see a way to significantly speed up such verification, but I've slightly improved performance by rearranging some expressions. Here is an updated webrev: http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/ Also, unless CommentedAssembly flag is explicitly turned off, we're generating comments for stubs even if we're not going to print it out. Avoiding comments generation in such case will speed up compilation a bit more, but I think it would be better to deal with it in a separate RFE. Difference in code emission time is about 30% when CommentedAssembly is off (~ 40s w/ CommentedAssembly, ~ 25s w/o CommentedAssembly). [1] http://hg.openjdk.java.net/jdk9/hs-comp/jdk/file/6c649a7ac744/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthStyle.java#l68 [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/cffca6de2c45/src/share/vm/c1/c1_LinearScan.cpp#l3226 On Fri, Feb 12, 2016 at 7:08 PM, Filipp Zhinkin wrote: > Hi Aleksey, > > On Fri, Feb 12, 2016 at 3:24 PM, Aleksey Shipilev > wrote: >> Hi Filipp, >> >> On 02/12/2016 02:47 PM, Filipp Zhinkin wrote: >>> here is a new webrev: http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.01/ >> >> The webrev seems incomplete: it has only hotspot.patch in it, but no >> other views? > > It seems like only wdiff's are empty for some reason. > What else is missed out there? > >> >> I wonder how many intervals have the same "from", prompting you to >> wiggle around looking for the exact interval? > > Well, there should be (relatively) many intervals with "from" == 0 > created for physical registers. > For virtual registers there could be few intervals that share the same > "from" value: > it depends on amount of temporary registers required by an operation > and amount of outputs it produces. > > So we may simply scan intervals from beginning if key's from value is 0. > >> Can we define >> "interval_cmp" so that "(interval_cmp(i1, i2) == 0) iff (i1 == i2)", > > No, unfortunately we can't, because intervals are ordered only by "from" value. > >> or at least make the false positives less frequent with more extensive >> interval key (assuming collisions are indeed problematic)? >> > > Not sure that I've got you. > > Nevertheless, I'll run CTW and check how many false positives are > actually found. > >> >>> I've hacked VM sources a bit to run CTW with product bits and C1 >>> compilation time on my x86_64 linux laptop >>> slowed down by 0.4% (from 51029 ? 306 ms to 51230 ? 293 ms). Please >>> let me know if it too slow. >> >> I think this is within the error margin, and therefore statistically >> insignificant. Even if it was significant, 0.4% is okay for compilation >> time regression in C1. >> >>> With fastdebug bits provided patch allow to reduce C1 compilation time twice. >> >> This is a very good improvement, but we need to see if that's the end of >> it, or we can squeeze even more with a few changes. I would suggest >> running the CTW scenario under Solaris Studio Performance Analyzer (see >> e.g. >> http://shipilev.net/blog/2016/arrays-wisdom-ancients/#_meet_solaris_studio_performance_analyzer). > > Thank you for the suggestion, I'll check it. > > Regards, > Filipp. > >> >> Thanks, >> -Aleksey >> >> From paul.sandoz at oracle.com Thu Feb 18 15:54:08 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 18 Feb 2016 16:54:08 +0100 Subject: RFR 8149469: ByteBuffer API and implementation enhancements for VarHandles In-Reply-To: <949FB585-4AF7-4D6D-923C-A336EDFB40ED@oracle.com> References: <6F457380-0E56-4909-BFBF-B3D6FE45B326@oracle.com> <949FB585-4AF7-4D6D-923C-A336EDFB40ED@oracle.com> Message-ID: <7D96A27B-E240-448D-8D6E-DF2DD54D3BBC@oracle.com> > On 18 Feb 2016, at 12:08, Chris Hegarty wrote: > > On 9 Feb 2016, at 15:05, Paul Sandoz wrote: > >> Hi, >> >> This patch contains API and internal enhancements to ByteBuffer: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149469-byte-buffer-align-and-unifying-enhancements/webrev/index.html > > This is certainly for advanced/power users feature. I expect it may not be > used all that widely, but I do see your requirement with VarHandles. > Right. Note that it is also useful in general if one wants certain guarantees on atomic accesses (if supported by the impl). For example, now that the wider get/put accessors use Unsafe.get/put*Unaligned it?s possible to align things to the most efficient form of plain *and* atomic access on systems that do not support misaligned accesses (or performance-wise even for systems that do since there might be an additional cost). It may be possible to carefully spruce up the spec in that respect in terms of atomicity guarantees with these new methods in place. > A few specific comments: > > - I find the comment in Buffer.java a little confusing. Specifically where is > says that byte[] allocations might no align to a word boundary on 32-bit > systems. I think you mean that the alignment will not be 8-byte aligned. > I get that slices can be arbitrary. > Yes. > - The changes to set isReadOnly do not seem related, but you explained > off-list that these are in preparation for VarHandlers. They seem benign. > I included all relevant changes required for VHs rather than try and spread ?em out. There is a lot more we could do to clean things up but i resisted the temptation. And Brian et. al. might be interested in taking on such work? hint hint :-) > - The computation in misalignment is based on assumptions about layout, > that may, or may not, be valid ( but it is had to see otherwise ). You had > suggested that UOE could be thrown here? > Yes, an omission on my part, thanks for spotting the discrepancy. We discussed such aspects on valhalla-dev: http://mail.openjdk.java.net/pipermail/valhalla-dev/2016-January/001731.html > - Minor spec issue in alignedSlice: "If rounding results in out-of-bound values > then this buffers capacity and limit will be zero.?. You mean "the new byte > buffer", right? > Yes, thanks! See diffs below. Webrev updated. I still need to think a little more about the upper bound of unitSize, i put a limit of 64 (cache line size) to stop silly values: - implementation-wise, for non-direct buffers any value above 8 should throw a USO. - for direct buffers is 64 too small? what about for page size alignment? Paul. diff -r 39af902887a4 src/java.base/share/classes/java/nio/Buffer.java --- a/src/java.base/share/classes/java/nio/Buffer.java Thu Feb 11 11:59:05 2016 +0100 +++ b/src/java.base/share/classes/java/nio/Buffer.java Thu Feb 18 16:38:46 2016 +0100 @@ -192,8 +192,8 @@ // Used by heap byte buffers or direct buffers with Unsafe access // For heap byte buffers this field will be the address relative to the // array base address and offset into that array. The address might - // not align on a word boundary for slices, nor for byte[] allocations - // on 32-bit systems. + // not align on a word boundary for slices, nor align at a long word + // (8 byte) boundary for byte[] allocations on 32-bit systems. // For direct buffers it is the start address of the memory region. The // address might not align on a word boundary for slices, nor when created // using JNI, see NewDirectByteBuffer(void*, long). diff -r 39af902887a4 src/java.base/share/classes/java/nio/X-Buffer.java.template --- a/src/java.base/share/classes/java/nio/X-Buffer.java.template Thu Feb 11 11:59:05 2016 +0100 +++ b/src/java.base/share/classes/java/nio/X-Buffer.java.template Thu Feb 18 16:38:46 2016 +0100 @@ -1643,6 +1643,15 @@ * If the index is negative or the unit size is not a positive * power of 2, or is greater than 64 * + * @throws UnsupportedOperationException + * If the native platform does not guarantee stable misalignment + * values for the given unit size when managing the memory regions + * of buffers of the same kind as this buffer (direct or + * non-direct). For example, if garbage collection would result + * in the moving of a memory region covered by a non-direct buffer + * from one location to another and both locations have different + * misalignment characteristics. + * * @see #alignedSlice(int) * @since 9 */ @@ -1665,8 +1674,8 @@ * position rounded up to the index of the nearest aligned byte for the * given unit size, and end at this buffer's limit rounded down to the index * of the nearest aligned byte for the given unit size. - * If rounding results in out-of-bound values then this buffers capacity and - * limit will be zero. If rounding is within bounds the following + * If rounding results in out-of-bound values then the new buffer's capacity + * and limit will be zero. If rounding is within bounds the following * expressions will be true for a new buffer {@code nb} and unit size * {@code unitSize}: * 
{@code
@@ -1700,6 +1709,15 @@
      * @throws IllegalArgumentException
      *         If the unit size not a positive power of 2, or is greater than 64
      *
+     * @throws UnsupportedOperationException
+     *         If the native platform does not guarantee stable aligned slices
+     *         for the given unit size when managing the memory regions
+     *         of buffers of the same kind as this buffer (direct or
+     *         non-direct).  For example, if garbage collection would result
+     *         in the moving of a memory region covered by a non-direct buffer
+     *         from one location to another and both locations have different
+     *         alignment characteristics.
+     *
      * @see #misalignment(int, int)
      * @see #slice()
      * @since 9


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: 

From aleksey.shipilev at oracle.com  Thu Feb 18 15:55:03 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 18 Feb 2016 18:55:03 +0300
Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down
	fastdebug builds' performance
In-Reply-To: 
References: 
	<54F99281.7020101@oracle.com>
	
	
	<56B489D0.3070700@oracle.com>
	
	
	<56BDCF17.30308@oracle.com>
	
	
Message-ID: <56C5E957.60009@oracle.com>

Hi Filipp,

On 02/18/2016 06:31 PM, Filipp Zhinkin wrote:
> I've looked at how frequently misses are actually occur and
> how far false positives are from the interval we're looking for.
> 
> Also I've tried to implement interval_cmp so that it returns 0
> if difference between interval "from" values is below some threshold:
> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/stats.txt
> 
> All those misses with distance greater than 64 came from
> javax.swing.plaf.synth.SynthStyle::populateDefaultValues [1].

Okay, let me recap: your data seems to say that current binary search
misses in 25% of the cases, and around 95% of the misses are within 8
intervals from the false value, right? And almost all 99.99% are within
32 intervals?

This does not seem bad, I was afraid of orders of magnitude larger values.

> I've also looked to another possible slowness sources and
> we spend about 10% of time in LinearScan's verify_intervals method
> which checks that every two intervals don't simultaneously intersect
> and share the same register [2].
> 
> I don't see a way to significantly speed up such verification,
> but I've slightly improved performance by rearranging some expressions.

Yes, those re-arrangements make sense.

> Here is an updated webrev:
> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/

Looks good to me (not a Reviewer).

> Also, unless CommentedAssembly flag is explicitly turned off,
> we're generating comments for stubs even if we're not going to print it out.
> Avoiding comments generation in such case will speed up compilation a bit more,
> but I think it would be better to deal with it in a separate RFE.
> Difference in code emission time is about 30% when CommentedAssembly is off
> (~ 40s w/ CommentedAssembly, ~ 25s w/o CommentedAssembly).

Oh wow. Let's fix that! Of course, separate RFE is fine.

Cheers,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From aleksey.shipilev at oracle.com  Thu Feb 18 16:03:59 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 18 Feb 2016 19:03:59 +0300
Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted
	arrays
In-Reply-To: <56C5CF0B.4080807@oracle.com>
References: <56C4FCC0.2010809@oracle.com> <56C57C07.2020307@oracle.com>
	<56C57DE9.9010700@oracle.com> <56C57EC7.7030104@oracle.com>
	<56C58E12.2050603@oracle.com> <56C5BF8B.1020504@oracle.com>
	<56C5C51F.3090403@oracle.com> <56C5CF0B.4080807@oracle.com>
Message-ID: <56C5EB6F.4010604@oracle.com>

On 02/18/2016 05:02 PM, Vladimir Ivanov wrote:
> Maybe structure it as follows?
>   } else {
> #ifdef ASSERT
>     LoadField* lf = x->array()->as_LoadField();
>     bool is_static_constant = (lf != NULL) && lf->field()->is_constant()
> && lf->field()->is_static();
>     assert(!is_static_constant, "constant field loads are folded during
> parsing");
> #endif // ASSERT
>   }
> 
> But choose whatever version you like. I don't have a strong opinion here.

I like this version better:
  http://cr.openjdk.java.net/~shade/8150102/webrev.03/

Still passes JPRT -testset hotspot.

Cheers,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From vladimir.x.ivanov at oracle.com  Thu Feb 18 16:08:08 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 18 Feb 2016 19:08:08 +0300
Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down
	fastdebug builds' performance
In-Reply-To: 
References: 
	<54F99281.7020101@oracle.com>
	
	
	<56B489D0.3070700@oracle.com>
	
	
	<56BDCF17.30308@oracle.com>
	
	
Message-ID: <56C5EC68.5010003@oracle.com>

Thanks, Filipp.

I suggest to address CommentedAssembly separately.

One question: why don't you simply typedef IntervalArray/IntervalList to 
GrowableArray? It will eliminate numerous renamings you did.

Otherwise, looks good.

Best regards,
Vladimir Ivanov

On 2/18/16 6:31 PM, Filipp Zhinkin wrote:
> Hi,
>
> I've looked at how frequently misses are actually occur and
> how far false positives are from the interval we're looking for.
>
> Also I've tried to implement interval_cmp so that it returns 0
> if difference between interval "from" values is below some threshold:
> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/stats.txt
>
> All those misses with distance greater than 64 came from
> javax.swing.plaf.synth.SynthStyle::populateDefaultValues [1].
>
> I've also looked to another possible slowness sources and
> we spend about 10% of time in LinearScan's verify_intervals method
> which checks that every two intervals don't simultaneously intersect
> and share the same register [2].
>
> I don't see a way to significantly speed up such verification,
> but I've slightly improved performance by rearranging some expressions.
>
> Here is an updated webrev:
> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/
>
> Also, unless CommentedAssembly flag is explicitly turned off,
> we're generating comments for stubs even if we're not going to print it out.
> Avoiding comments generation in such case will speed up compilation a bit more,
> but I think it would be better to deal with it in a separate RFE.
> Difference in code emission time is about 30% when CommentedAssembly is off
> (~ 40s w/ CommentedAssembly, ~ 25s w/o CommentedAssembly).
>
> [1] http://hg.openjdk.java.net/jdk9/hs-comp/jdk/file/6c649a7ac744/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthStyle.java#l68
> [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/cffca6de2c45/src/share/vm/c1/c1_LinearScan.cpp#l3226
>
> On Fri, Feb 12, 2016 at 7:08 PM, Filipp Zhinkin
>  wrote:
>> Hi Aleksey,
>>
>> On Fri, Feb 12, 2016 at 3:24 PM, Aleksey Shipilev
>>  wrote:
>>> Hi Filipp,
>>>
>>> On 02/12/2016 02:47 PM, Filipp Zhinkin wrote:
>>>> here is a new webrev: http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.01/
>>>
>>> The webrev seems incomplete: it has only hotspot.patch in it, but no
>>> other views?
>>
>> It seems like only wdiff's are empty for some reason.
>> What else is missed out there?
>>
>>>
>>> I wonder how many intervals have the same "from", prompting you to
>>> wiggle around looking for the exact interval?
>>
>> Well, there should be (relatively) many intervals with "from" == 0
>> created for physical registers.
>> For virtual registers there could be few intervals that share the same
>> "from" value:
>> it depends on amount of temporary registers required by an operation
>> and amount of outputs it produces.
>>
>> So we may simply scan intervals from beginning if key's from value is 0.
>>
>>> Can we define
>>> "interval_cmp" so that "(interval_cmp(i1, i2) == 0) iff (i1 == i2)",
>>
>> No, unfortunately we can't, because intervals are ordered only by "from" value.
>>
>>> or at least make the false positives less frequent with more extensive
>>> interval key (assuming collisions are indeed problematic)?
>>>
>>
>> Not sure that I've got you.
>>
>> Nevertheless, I'll run CTW and check how many false positives are
>> actually found.
>>
>>>
>>>> I've hacked VM sources a bit to run CTW with product bits and C1
>>>> compilation time on my x86_64 linux laptop
>>>> slowed down by 0.4% (from 51029 ? 306 ms to 51230 ? 293 ms). Please
>>>> let me know if it too slow.
>>>
>>> I think this is within the error margin, and therefore statistically
>>> insignificant. Even if it was significant, 0.4% is okay for compilation
>>> time regression in C1.
>>>
>>>> With fastdebug bits provided patch allow to reduce C1 compilation time twice.
>>>
>>> This is a very good improvement, but we need to see if that's the end of
>>> it, or we can squeeze even more with a few changes. I would suggest
>>> running the CTW scenario under Solaris Studio Performance Analyzer (see
>>> e.g.
>>> http://shipilev.net/blog/2016/arrays-wisdom-ancients/#_meet_solaris_studio_performance_analyzer).
>>
>> Thank you for the suggestion, I'll check it.
>>
>> Regards,
>> Filipp.
>>
>>>
>>> Thanks,
>>> -Aleksey
>>>
>>>

From vladimir.x.ivanov at oracle.com  Thu Feb 18 16:10:56 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 18 Feb 2016 19:10:56 +0300
Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted
	arrays
In-Reply-To: <56C5EB6F.4010604@oracle.com>
References: <56C4FCC0.2010809@oracle.com> <56C57C07.2020307@oracle.com>
	<56C57DE9.9010700@oracle.com> <56C57EC7.7030104@oracle.com>
	<56C58E12.2050603@oracle.com> <56C5BF8B.1020504@oracle.com>
	<56C5C51F.3090403@oracle.com> <56C5CF0B.4080807@oracle.com>
	<56C5EB6F.4010604@oracle.com>
Message-ID: <56C5ED10.2090007@oracle.com>

>    http://cr.openjdk.java.net/~shade/8150102/webrev.03/
Reviewed.

Best regards,
Vladimir Ivanov

From jamsheed.c.m at oracle.com  Thu Feb 18 16:26:50 2016
From: jamsheed.c.m at oracle.com (Jamsheed C m)
Date: Thu, 18 Feb 2016 21:56:50 +0530
Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler
	-XX:-EnableJVMCI makes JVM crash
In-Reply-To: <56C5163D.7010208@oracle.com>
References: <56BC90DC.10004@oracle.com>
	
	<56BD8DF9.1070605@oracle.com>
	
	<56BE1274.4020506@oracle.com>
	<41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com>
	<56C3221D.2040507@oracle.com> <56C48936.4090303@oracle.com>
	
	<56C5163D.7010208@oracle.com>
Message-ID: <56C5F0CA.5010307@oracle.com>

Hi Chris,

Made all suggested changes.

Revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.04/

Best Regards,
Jamsheed

On 2/18/2016 6:24 AM, Jamsheed C m wrote:
>
>
> On 2/18/2016 12:36 AM, Christian Thalinger wrote:
>>
>>> On Feb 17, 2016, at 4:52 AM, Jamsheed C m  
>>> wrote:
>>>
>>> experimental and diagnostic flags are under condition checks now.
>>>
>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.03/ 
>>> 
>>
>> I?m not very happy about the new macros but I can see why it?s useful.
>>
>> +#if INCLUDE_JVMCI
>> +
>> +// Check consistency of jvmci vm argument settings.
>> +bool Arguments::check_jvmci_args_consistency() {
>> +
>> +
>> +  if (!EnableJVMCI && is_any_jvmci_arg_values_changed()) {
>> +    print_jvmci_arg_inconsistency_error_message();
>> +    return false;
>>
>> Please remove all these empty lines.  There are others as well.
>>
>> +bool is_any_jvmci_arg_values_changed() {
>>
>> This method needs another name.
>>
> Ok.
>> +  int check_count = 0, fail_count = 0;
>>
>> I don?t like the check_count/fail_count logic because it?s fragile.
> As  EanbleJVMCI flag cannot be avoided from macro expansion logic, i 
> had to use some technique to exclude this flag from failure decision 
> making.
> Check_count/fail_count logic was added as a solution for this. i.e 
> When EnableJVMCI is changed, code requires at-least 2 check failures 
> to decide a real failure. otherwise one failure is sufficient.
>
> if i remove this logic, i will have to use strcmp(#FLAG, 
> "EnableJVMCI") which will add a little more instructions that will  
> execute at-least once for every flag consistent run.
>
> let me know if i need to take second approach. or if existing code is ok.
>>
>> +// Check if any jvmci global defaults changed.
>> +bool is_any_jvmci_arg_values_changed();
>> +// Print jvmci args inconsistency error message.
>> +void print_jvmci_arg_inconsistency_error_message();
>>
>> These should be in some kind of namespace or class.  Maybe put them 
>> into: class JVMCIGlobals
> Ok.
>
> Best Regards,
> Jamsheed
>>
>>>
>>>
>>> Best Regards,
>>> Jamsheed
>>>
>>> On 2/16/2016 6:50 PM, Jamsheed C m wrote:
>>>> Hi Chris,
>>>>
>>>> Revised webrev: 
>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/
>>>>
>>>> This code take care of every jvmci flags automatically.
>>>>
>>>> Best Regards,
>>>> Jamsheed
>>>>
>>>> On 2/13/2016 3:24 AM, Christian Thalinger wrote:
>>>>>
>>>>>> On Feb 12, 2016, at 7:12 AM, Jamsheed C m 
>>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> On 2/12/2016 10:12 PM, Christian Thalinger wrote:
>>>>>>> Well, now you have to manually check all flags that had 
>>>>>>> a constraint directive.  That is the annoying part and what I 
>>>>>>> complained about in:
>>>>>> check against original value, and if not fail ?
>>>>>
>>>>> Same check for all flags; they all depend on +EnableJVMCI.
>>>>>
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8145357
>>>>>>>
>>>>>>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now 
>>>>>>> empty and I think we should remove them.
>>>>>> i kept the file as there can be future use. Ok, i will remove it.
>>>>>>
>>>>>> Best Regards,
>>>>>> Jamsheed
>>>>>>>
>>>>>>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m 
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>> revised webrev: 
>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Jamsheed
>>>>>>>>
>>>>>>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote:
>>>>>>>>>
>>>>>>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m 
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Request for review
>>>>>>>>>>
>>>>>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333
>>>>>>>>>> web url: http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/
>>>>>>>>>
>>>>>>>>> That looks alright but we should remove the constraints from 
>>>>>>>>> all the JVMCI command line flags because the way we use them 
>>>>>>>>> is not supported.
>>>>>>>>>
>>>>>>>>> Also, can you change the error message?  Right now it looks 
>>>>>>>>> like this:
>>>>>>>>>
>>>>>>>>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java 
>>>>>>>>> -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler
>>>>>>>>> EnableJVMCI must be enabled
>>>>>>>>> Improperly specified VM option 'UseJVMCICompiler'
>>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>>
>>>>>>>>> I think with your changes we will only see the first line 
>>>>>>>>> without mentioning UseJVMCICompiler.  Is that correct?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Fix Summary: added jvmci flag consistency check after arg 
>>>>>>>>>> parsing.
>>>>>>>>>>
>>>>>>>>>> tests: jprt
>>>>>>>>>> unit test: command line verification
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Jamsheed
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From christian.thalinger at oracle.com  Thu Feb 18 17:51:19 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 18 Feb 2016 07:51:19 -1000
Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler
	-XX:-EnableJVMCI makes JVM crash
In-Reply-To: <56C5F0CA.5010307@oracle.com>
References: <56BC90DC.10004@oracle.com>
	
	<56BD8DF9.1070605@oracle.com>
	
	<56BE1274.4020506@oracle.com>
	<41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com>
	<56C3221D.2040507@oracle.com> <56C48936.4090303@oracle.com>
	
	<56C5163D.7010208@oracle.com> <56C5F0CA.5010307@oracle.com>
Message-ID: 

+  if (EnableJVMCI)
+    return true;

Please use { } for all if statements.

Thanks for the comments; it?s easier to understand now.  May I suggest to do:

  int skip_fail_count;  
  if (!FLAG_IS_DEFAULT(EnableJVMCI)) {
    skip_fail_count = 1;
  } else {
    skip_fail_count = 0;  
  }

> On Feb 18, 2016, at 6:26 AM, Jamsheed C m  wrote:
> 
> Hi Chris,
> 
> Made all suggested changes.
> 
> Revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.04/ 
> 
> Best Regards,
> Jamsheed
> 
> On 2/18/2016 6:24 AM, Jamsheed C m wrote:
>> 
>> 
>> On 2/18/2016 12:36 AM, Christian Thalinger wrote:
>>> 
>>>> On Feb 17, 2016, at 4:52 AM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote:
>>>> 
>>>> experimental and diagnostic flags are under condition checks now.
>>>> 
>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.03/ 
>>> 
>>> I?m not very happy about the new macros but I can see why it?s useful.
>>> 
>>> +#if INCLUDE_JVMCI
>>> +
>>> +// Check consistency of jvmci vm argument settings.
>>> +bool Arguments::check_jvmci_args_consistency() {
>>> + 
>>> +
>>> +  if (!EnableJVMCI && is_any_jvmci_arg_values_changed()) { 
>>> +    print_jvmci_arg_inconsistency_error_message(); 
>>> +    return false;
>>> 
>>> Please remove all these empty lines.  There are others as well.
>>> 
>>> +bool is_any_jvmci_arg_values_changed() {  
>>> 
>>> This method needs another name.
>>> 
>> Ok.
>>> +  int check_count = 0, fail_count = 0;
>>> 
>>> I don?t like the check_count/fail_count logic because it?s fragile.
>> As  EanbleJVMCI flag cannot be avoided from macro expansion logic, i had to use some technique to exclude this flag from failure decision making. 
>> Check_count/fail_count logic was added as a solution for this. i.e When EnableJVMCI is changed, code requires at-least 2 check failures to decide a real failure. otherwise one failure is sufficient. 
>>  
>> if i remove this logic, i will have to use strcmp(#FLAG, "EnableJVMCI") which will add a little more instructions that will  execute at-least once for every flag consistent run.
>> 
>> let me know if i need to take second approach. or if existing code is ok.
>>> 
>>> +// Check if any jvmci global defaults changed.
>>> +bool is_any_jvmci_arg_values_changed();
>>> +// Print jvmci args inconsistency error message.
>>> +void print_jvmci_arg_inconsistency_error_message();
>>> 
>>> These should be in some kind of namespace or class.  Maybe put them into: class JVMCIGlobals
>> Ok.
>> 
>> Best Regards,
>> Jamsheed
>>> 
>>>> 
>>>> 
>>>> Best Regards,
>>>> Jamsheed
>>>> 
>>>> On 2/16/2016 6:50 PM, Jamsheed C m wrote:
>>>>> Hi Chris,
>>>>> 
>>>>> Revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/ 
>>>>> 
>>>>> This code take care of every jvmci flags automatically.
>>>>> 
>>>>> Best Regards,
>>>>> Jamsheed
>>>>> 
>>>>> On 2/13/2016 3:24 AM, Christian Thalinger wrote:
>>>>>> 
>>>>>>> On Feb 12, 2016, at 7:12 AM, Jamsheed C m > wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Hi Chris,
>>>>>>> 
>>>>>>> On 2/12/2016 10:12 PM, Christian Thalinger wrote:
>>>>>>>> Well, now you have to manually check all flags that had a constraint directive.  That is the annoying part and what I complained about in:
>>>>>>> check against original value, and if not fail ?
>>>>>> 
>>>>>> Same check for all flags; they all depend on +EnableJVMCI.
>>>>>> 
>>>>>>>> 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8145357 
>>>>>>>> 
>>>>>>>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now empty and I think we should remove them.
>>>>>>> i kept the file as there can be future use. Ok, i will remove it.
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> Jamsheed
>>>>>>>> 
>>>>>>>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote:
>>>>>>>>> 
>>>>>>>>> Hi Chris,
>>>>>>>>> 
>>>>>>>>> revised webrev:  http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/ 
>>>>>>>>> 
>>>>>>>>> Best Regards,
>>>>>>>>> Jamsheed
>>>>>>>>> 
>>>>>>>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote:
>>>>>>>>>> 
>>>>>>>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> Request for review
>>>>>>>>>>> 
>>>>>>>>>>> bug url:   https://bugs.openjdk.java.net/browse/JDK-8145333 
>>>>>>>>>>> web url:  http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ 
>>>>>>>>>> 
>>>>>>>>>> That looks alright but we should remove the constraints from all the JVMCI command line flags because the way we use them is not supported.
>>>>>>>>>> 
>>>>>>>>>> Also, can you change the error message?  Right now it looks like this:
>>>>>>>>>> 
>>>>>>>>>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler
>>>>>>>>>> EnableJVMCI must be enabled
>>>>>>>>>> Improperly specified VM option 'UseJVMCICompiler'
>>>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>>> 
>>>>>>>>>> I think with your changes we will only see the first line without mentioning UseJVMCICompiler.  Is that correct?
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Fix Summary: added jvmci flag consistency check after arg parsing.
>>>>>>>>>>> 
>>>>>>>>>>> tests: jprt
>>>>>>>>>>> unit test: command line verification
>>>>>>>>>>> 
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Jamsheed
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rahul.v.raghavan at oracle.com  Thu Feb 18 18:10:42 2016
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Thu, 18 Feb 2016 10:10:42 -0800 (PST)
Subject: RFR (XS): 8145707: 4 Null pointer dereference defect groups in
	compileBroker.cpp
Message-ID: <6d4d97ca-b46e-4c24-a54d-147d2333965b@default>

Hi,

Please review following patch proposal to avoid possible null pointer dereference warnings / errors for internal tests.

webrev: http://cr.openjdk.java.net/~thartmann/8145707/webrev.02/

Confirmed no issues with jprt run (-testset hotspot).

Thanks,
Rahul

From vladimir.kozlov at oracle.com  Thu Feb 18 18:13:25 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Feb 2016 10:13:25 -0800
Subject: RFR (XS): 8145707: 4 Null pointer dereference defect groups in
	compileBroker.cpp
In-Reply-To: <6d4d97ca-b46e-4c24-a54d-147d2333965b@default>
References: <6d4d97ca-b46e-4c24-a54d-147d2333965b@default>
Message-ID: <56C609C5.7000609@oracle.com>

Looks good.

Thanks,
Vladimir

On 2/18/16 10:10 AM, Rahul Raghavan wrote:
> Hi,
>
> Please review following patch proposal to avoid possible null pointer dereference warnings / errors for internal tests.
>
> webrev: http://cr.openjdk.java.net/~thartmann/8145707/webrev.02/
>
> Confirmed no issues with jprt run (-testset hotspot).
>
> Thanks,
> Rahul
>

From rahul.v.raghavan at oracle.com  Thu Feb 18 18:19:01 2016
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Thu, 18 Feb 2016 10:19:01 -0800 (PST)
Subject: RFR (XS): 8145707: 4 Null pointer dereference defect groups in
	compileBroker.cpp
In-Reply-To: <56C609C5.7000609@oracle.com>
References: <6d4d97ca-b46e-4c24-a54d-147d2333965b@default>
	<56C609C5.7000609@oracle.com>
Message-ID: <4ce04ba5-7f85-4b5c-a70c-e6ba075325e1@default>

Thank you Vladimir.

> -----Original Message-----
> From: Vladimir Kozlov > Sent: Thursday, February 18, 2016 11:43 PM > To: hotspot-compiler-dev at openjdk.java.net
> 
> Looks good.
> 
> Thanks,
> Vladimir
> 
> On 2/18/16 10:10 AM, Rahul Raghavan wrote:
> > Hi,
> >
> > Please review following patch proposal to avoid possible null pointer dereference warnings / errors for internal tests.
> >
> > webrev: http://cr.openjdk.java.net/~thartmann/8145707/webrev.02/
> >
> > Confirmed no issues with jprt run (-testset hotspot).
> >
> > Thanks,
> > Rahul
> >

From christian.thalinger at oracle.com  Thu Feb 18 18:52:14 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 18 Feb 2016 08:52:14 -1000
Subject: [9] RFR JDK-8141618: Change JVMCI compilerToVM constant pool
	tests to support CP caching
In-Reply-To: <56C5A03D.9040602@oracle.com>
References: <56C47C58.9090104@oracle.com>
	<68AEB7F8-14A8-4BC5-B910-501E2980F646@oracle.com>
	<56C5A03D.9040602@oracle.com>
Message-ID: <827C7189-9979-4174-9E0F-549F848B37CA@oracle.com>

It?s difficult to follow the logic and make sure there is no bug.  I did not verify all this.  Looks good anyway.

> On Feb 18, 2016, at 12:43 AM, Konstantin Shefov  wrote:
> 
> Christian, thanks for looking into this
> 
> I have reformatted the code to make it look better:
> http://cr.openjdk.java.net/~kshefov/8141618/webrev.01
> 
> -Konstantin
> 
> On 02/17/2016 09:43 PM, Christian Thalinger wrote:
>> Why do you have to break every line at, what, 50 characters?  This is unreadable:
>> 
>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.CLASS,
>> +                ConstantTypes.CONSTANT_CLASS);
>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.FIELDREF,
>> +                ConstantTypes.CONSTANT_FIELDREF);
>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.METHODREF,
>> +                ConstantTypes.CONSTANT_METHODREF);
>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.INTERFACEMETHODREF,
>> +                ConstantTypes.CONSTANT_INTERFACEMETHODREF);
>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.STRING,
>> +                ConstantTypes.CONSTANT_STRING);
>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.INTEGER,
>> +                ConstantTypes.CONSTANT_INTEGER);
>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.FLOAT,
>> +                ConstantTypes.CONSTANT_FLOAT);
>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.LONG,
>> +                ConstantTypes.CONSTANT_LONG);
>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.DOUBLE,
>> 
>> And this is not the only occurrence.  I can?t review this.
>> 
>>> On Feb 17, 2016, at 3:57 AM, Konstantin Shefov  wrote:
>>> 
>>> Hello
>>> 
>>> Please review a test enhancement.
>>> It is an improvement for JVMCI CompilerToVM class tests.
>>> 
>>> See https://bugs.openjdk.java.net/browse/JDK-8138708 for more info.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141618
>>> Webrev: http://cr.openjdk.java.net/~kshefov/8141618/webrev.00/
>>> 
>>> Thanks
>>> -Konstantin
> 


From aleksey.shipilev at oracle.com  Thu Feb 18 18:53:46 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 18 Feb 2016 21:53:46 +0300
Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted
	arrays
In-Reply-To: <56C5ED10.2090007@oracle.com>
References: <56C4FCC0.2010809@oracle.com> <56C57C07.2020307@oracle.com>
	<56C57DE9.9010700@oracle.com> <56C57EC7.7030104@oracle.com>
	<56C58E12.2050603@oracle.com> <56C5BF8B.1020504@oracle.com>
	<56C5C51F.3090403@oracle.com> <56C5CF0B.4080807@oracle.com>
	<56C5EB6F.4010604@oracle.com> <56C5ED10.2090007@oracle.com>
Message-ID: <56C6133A.1020900@oracle.com>

On 02/18/2016 07:10 PM, Vladimir Ivanov wrote:
>>    http://cr.openjdk.java.net/~shade/8150102/webrev.03/
> Reviewed.

Thanks Vladimir! Any more reviews?

-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From christian.thalinger at oracle.com  Thu Feb 18 18:56:03 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 18 Feb 2016 08:56:03 -1000
Subject: [9] RFR JDK-8141619: Develop new tests for JVMCI compilerToVM
	class' CP related methods
In-Reply-To: <56C5A08B.50001@oracle.com>
References: <56C47D09.4030006@oracle.com>
	
	<56C5A08B.50001@oracle.com>
Message-ID: <7663E05E-544E-4FFB-8E7F-A329143B64A5@oracle.com>

  57         typeTests.put(ConstantPoolTestCase.ConstantTypes.CONSTANT_METHODREF,
  58                       LookupNameAndTypeRefIndexInPoolTest::validate);

You should use static imports so you can get rid of ConstantPoolTestCase.ConstantTypes.  Actually, the same would be useful in your other review too.

> On Feb 18, 2016, at 12:44 AM, Konstantin Shefov  wrote:
> 
> According to Christian's comments to RFR JDK-8141618 I have reformatted the code to make it look better:
> http://cr.openjdk.java.net/~kshefov/8141619/webrev.01/ 
> 
> -Konstantin
> 
> On 02/17/2016 09:46 PM, Christian Thalinger wrote:
>> 
>>> On Feb 17, 2016, at 4:00 AM, Konstantin Shefov > wrote:
>>> 
>>> Hello
>>> 
>>> Please review new tests for methods of JVMCI jdk.vm.ci.hotspot.CompilerToVM class.
>>> 
>>> See https://bugs.openjdk.java.net/browse/JDK-8138708  for more info.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141619 
>>> Webrev: http://cr.openjdk.java.net/~kshefov/8141619/webrev.00/ 
>> 
>> Link is wrong: http://cr.openjdk.java.net/~kshefov/8141619/webrev/ 
>> 
>>> 
>>> Thanks
>>> -Konstantin
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From goetz.lindenmaier at sap.com  Thu Feb 18 19:50:08 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 18 Feb 2016 19:50:08 +0000
Subject: RFR(L) 8149655: PPC64: Implement CompactString intrinsics
In-Reply-To: 
References: 
Message-ID: <6d2ee7af0e2947abb989fa84369f4f0f@DEWDFE13DE09.global.corp.sap>

Hi Martin,

I finally had a look at this change.  Good work!

What did you test this with,  besides our hs-comp nighttests, which
already is quite a lot?

ppc.ad:
I saw you added more conditions to the predicate of  string_indexOf_imm1_char() etc.
Isn't this obvious because needleImm is an immP?

macroassmbler_ppc.cpp:
if (stride1 == 1) { lbz(chr1, 0, str1); } else { lhz(chr1, 0 ,str1); }
Space before comma.  There are more of these, search for '0 ,'
guarantee(needlecntval != 1,
not indented ... or is this on purpose?

Best regards,
  Goetz.

From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin
Sent: Thursday, February 11, 2016 4:11 PM
To: hotspot-compiler-dev at openjdk.java.net
Subject: RFR(L) 8149655: PPC64: Implement CompactString intrinsics

Hi,

I have created a webrev which adds the following String intrinsics to PPC64:
0 string_compareL
1 string_compareU
2 string_compareLU
3 string_compareUL
4 string_equalsL
5 string_equalsU
6 array_equalsB
7 array_equalsC
8 indexOf_imm1_char_U
9 indexOf_imm1_char_L
10 indexOf_imm1_char_UL
11 indexOf_imm1_U
12 indexOf_imm1_L
13 indexOf_imm1_UL
14 indexOfChar_U
15 indexOf_imm_U
16 indexOf_imm_L
17 indexOf_imm_UL
18 indexOf_U
19 indexOf_L
20 indexOf_UL
21 string_compress
22 string_inflate
23 has_negatives
24 encode_iso_array

It also contains some other minor improvements.

The webrev is here:
http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.00/

Please review.

I will also need a sponsor from Oracle because the change touches one java test file (test/compiler/intrinsics/string/TestStringIntrinsics2.java).

Best regards,
Martin




-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vladimir.kozlov at oracle.com  Thu Feb 18 20:10:46 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Feb 2016 12:10:46 -0800
Subject: [9] RFR (M): 8149741: Don't refer to stub entry points by index
	in external_word relocations
In-Reply-To: <56C5842C.4090009@oracle.com>
References: <56C4900D.6080708@oracle.com> <56C54003.6070603@oracle.com>
	<56C5842C.4090009@oracle.com>
Message-ID: <56C62546.9050804@oracle.com>

Looks good.

thanks,
Vladimir

On 2/18/16 12:43 AM, Vladimir Ivanov wrote:
>> Nice clean up!
> Thanks, Vladimir.
>
> Updated webrev:
>    http://cr.openjdk.java.net/~vlivanov/8149741/webrev.01.index/
>
>>
>> Casts should be the same:
>>
>> (uintptr_t)target >= (uint)os::vm_page_size()
> Fixed.
>
>> Why in assembler_windows_x86.cpp you used NULL_WORD and not simple NULL?
>> NULL_WORD is used for integer values and NULL for pointers
>> which is this case.
> Fixed.
>
> Best regards,
> Vladimir Ivanov

From vladimir.kozlov at oracle.com  Thu Feb 18 20:25:58 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Feb 2016 12:25:58 -0800
Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply
	intrinsic
In-Reply-To: <56C5B605.6060606@oracle.com>
References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com>
	<56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com>
	<56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com>
	<56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com>
	<56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com>
	<56C5ADCF.60805@oracle.com> <56C5AED4.90601@redhat.com>
	<56C5B605.6060606@oracle.com>
Message-ID: <56C628D6.5090902@oracle.com>

To be clear. You are proposing only the next change nothing else we discussed before. Right?

-  if (len >= MONTGOMERY_SQUARING_THRESHOLD) {
+  if (0) {
     ::montgomery_square(a, n, m, (unsigned long)inv, longwords);

What about 'volatile asm'? Using C code instead of asm?

In general I am fine with that since it looks like it is only performance issue.

Thanks,
Vladimir

On 2/18/16 4:16 AM, Vladimir Kempik wrote:
> Hello
>
> Vladimir Kozlov, do you think I can backport this to jdk8/7 with mentioned workaround (for solaris amd64 only) and then
> create a bug to investigate why montgomery_square fails with jdk8/7 and solaris studio 12u1 compiler ?
>
> It passed the jprt tests now.
>
> If so It's ok I'll prepare.
>
> Thanks.
> On 18.02.2016 14:45, Andrew Haley wrote:
>> On 02/18/2016 11:41 AM, Vladimir Kempik wrote:
>>> making this routine to always use montgomery_multiply helped to
>>> workaround the issue
>> OK, so possibly a bug in montgomery_square.  I'm not sure what
>> "helped" means, though.  I guess it doesn't mean "fixes the bug".
>>
>> Andrew.
>>
>

From vladimir.kempik at oracle.com  Thu Feb 18 20:38:02 2016
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Thu, 18 Feb 2016 23:38:02 +0300
Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply
	intrinsic
In-Reply-To: <56C628D6.5090902@oracle.com>
References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com>
	<56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com>
	<56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com>
	<56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com>
	<56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com>
	<56C5ADCF.60805@oracle.com> <56C5AED4.90601@redhat.com>
	<56C5B605.6060606@oracle.com> <56C628D6.5090902@oracle.com>
Message-ID: <28D00379-E85F-4D57-B54A-7A6545459BE5@oracle.com>

Hello

To be clear. 

I'm proposing :
1)if(0), only for Solaris (via ifdef Solaris )
2)volatile asm. 

That is the combination that passes all jprt tests.

I'll prepare updated webrev a bit later this week.
Vladimir.

?????????? ? iPad

> 18 ????. 2016 ?., ? 23:25, Vladimir Kozlov  ???????(?):
> 
> To be clear. You are proposing only the next change nothing else we discussed before. Right?
> 
> -  if (len >= MONTGOMERY_SQUARING_THRESHOLD) {
> +  if (0) {
>    ::montgomery_square(a, n, m, (unsigned long)inv, longwords);
> 
> What about 'volatile asm'? Using C code instead of asm?
> 
> In general I am fine with that since it looks like it is only performance issue.
> 
> Thanks,
> Vladimir
> 
>> On 2/18/16 4:16 AM, Vladimir Kempik wrote:
>> Hello
>> 
>> Vladimir Kozlov, do you think I can backport this to jdk8/7 with mentioned workaround (for solaris amd64 only) and then
>> create a bug to investigate why montgomery_square fails with jdk8/7 and solaris studio 12u1 compiler ?
>> 
>> It passed the jprt tests now.
>> 
>> If so It's ok I'll prepare.
>> 
>> Thanks.
>>> On 18.02.2016 14:45, Andrew Haley wrote:
>>>> On 02/18/2016 11:41 AM, Vladimir Kempik wrote:
>>>> making this routine to always use montgomery_multiply helped to
>>>> workaround the issue
>>> OK, so possibly a bug in montgomery_square.  I'm not sure what
>>> "helped" means, though.  I guess it doesn't mean "fixes the bug".
>>> 
>>> Andrew.
>>> 
>> 

From vladimir.kozlov at oracle.com  Thu Feb 18 21:05:11 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Feb 2016 13:05:11 -0800
Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply
	intrinsic
In-Reply-To: <28D00379-E85F-4D57-B54A-7A6545459BE5@oracle.com>
References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com>
	<56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com>
	<56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com>
	<56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com>
	<56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com>
	<56C5ADCF.60805@oracle.com> <56C5AED4.90601@redhat.com>
	<56C5B605.6060606@oracle.com> <56C628D6.5090902@oracle.com>
	<28D00379-E85F-4D57-B54A-7A6545459BE5@oracle.com>
Message-ID: <56C63207.6090308@oracle.com>

Okay.

On 2/18/16 12:38 PM, Vladimir Kempik wrote:
> Hello
>
> To be clear.
>
> I'm proposing :
> 1)if(0), only for Solaris (via ifdef Solaris )
> 2)volatile asm.
>
> That is the combination that passes all jprt tests.
>
> I'll prepare updated webrev a bit later this week.
> Vladimir.
>
> ?????????? ? iPad
>
>> 18 ????. 2016 ?., ? 23:25, Vladimir Kozlov  ???????(?):
>>
>> To be clear. You are proposing only the next change nothing else we discussed before. Right?
>>
>> -  if (len >= MONTGOMERY_SQUARING_THRESHOLD) {
>> +  if (0) {
>>     ::montgomery_square(a, n, m, (unsigned long)inv, longwords);
>>
>> What about 'volatile asm'? Using C code instead of asm?
>>
>> In general I am fine with that since it looks like it is only performance issue.
>>
>> Thanks,
>> Vladimir
>>
>>> On 2/18/16 4:16 AM, Vladimir Kempik wrote:
>>> Hello
>>>
>>> Vladimir Kozlov, do you think I can backport this to jdk8/7 with mentioned workaround (for solaris amd64 only) and then
>>> create a bug to investigate why montgomery_square fails with jdk8/7 and solaris studio 12u1 compiler ?
>>>
>>> It passed the jprt tests now.
>>>
>>> If so It's ok I'll prepare.
>>>
>>> Thanks.
>>>> On 18.02.2016 14:45, Andrew Haley wrote:
>>>>> On 02/18/2016 11:41 AM, Vladimir Kempik wrote:
>>>>> making this routine to always use montgomery_multiply helped to
>>>>> workaround the issue
>>>> OK, so possibly a bug in montgomery_square.  I'm not sure what
>>>> "helped" means, though.  I guess it doesn't mean "fixes the bug".
>>>>
>>>> Andrew.
>>>>
>>>

From vladimir.kozlov at oracle.com  Thu Feb 18 21:28:10 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Feb 2016 13:28:10 -0800
Subject: RFR (S) 8150102: C1 should fold arraylength for constant/trusted
	arrays
In-Reply-To: <56C6133A.1020900@oracle.com>
References: <56C4FCC0.2010809@oracle.com> <56C57C07.2020307@oracle.com>
	<56C57DE9.9010700@oracle.com> <56C57EC7.7030104@oracle.com>
	<56C58E12.2050603@oracle.com> <56C5BF8B.1020504@oracle.com>
	<56C5C51F.3090403@oracle.com> <56C5CF0B.4080807@oracle.com>
	<56C5EB6F.4010604@oracle.com> <56C5ED10.2090007@oracle.com>
	<56C6133A.1020900@oracle.com>
Message-ID: <56C6376A.1090407@oracle.com>

Seems good.

thanks,
Vladimir K

On 2/18/16 10:53 AM, Aleksey Shipilev wrote:
> On 02/18/2016 07:10 PM, Vladimir Ivanov wrote:
>>>     http://cr.openjdk.java.net/~shade/8150102/webrev.03/
>> Reviewed.
>
> Thanks Vladimir! Any more reviews?
>
> -Aleksey
>
>

From jamsheed.c.m at oracle.com  Fri Feb 19 05:23:42 2016
From: jamsheed.c.m at oracle.com (Jamsheed C m)
Date: Fri, 19 Feb 2016 10:53:42 +0530
Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler
	-XX:-EnableJVMCI makes JVM crash
In-Reply-To: 
References: <56BC90DC.10004@oracle.com>
	
	<56BD8DF9.1070605@oracle.com>
	
	<56BE1274.4020506@oracle.com>
	<41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com>
	<56C3221D.2040507@oracle.com> <56C48936.4090303@oracle.com>
	
	<56C5163D.7010208@oracle.com> <56C5F0CA.5010307@oracle.com>
	
Message-ID: <56C6A6DE.9060806@oracle.com>



On 2/18/2016 11:21 PM, Christian Thalinger wrote:
> +  if (EnableJVMCI)
> +    return true;
>
> Please use { } for all if statements.
Ok.
>
> Thanks for the comments; it?s easier to understand now.  May I suggest 
> to do:
>
>   int skip_fail_count;
>   if (!FLAG_IS_DEFAULT(EnableJVMCI)) {
>     skip_fail_count = 1;
>   } else {
>     skip_fail_count = 0;
>   }
Ok.

Best Regards,
Jamsheed
>
>> On Feb 18, 2016, at 6:26 AM, Jamsheed C m > > wrote:
>>
>> Hi Chris,
>>
>> Made all suggested changes.
>>
>> Revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.04/
>>
>> Best Regards,
>> Jamsheed
>>
>> On 2/18/2016 6:24 AM, Jamsheed C m wrote:
>>>
>>>
>>> On 2/18/2016 12:36 AM, Christian Thalinger wrote:
>>>>
>>>>> On Feb 17, 2016, at 4:52 AM, Jamsheed C m 
>>>>>  wrote:
>>>>>
>>>>> experimental and diagnostic flags are under condition checks now.
>>>>>
>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.03/ 
>>>>> 
>>>>
>>>> I?m not very happy about the new macros but I can see why it?s useful.
>>>>
>>>> +#if INCLUDE_JVMCI
>>>> +
>>>> +// Check consistency of jvmci vm argument settings.
>>>> +bool Arguments::check_jvmci_args_consistency() {
>>>> +
>>>> +
>>>> +  if (!EnableJVMCI && is_any_jvmci_arg_values_changed()) {
>>>> +  print_jvmci_arg_inconsistency_error_message();
>>>> +    return false;
>>>>
>>>> Please remove all these empty lines.  There are others as well.
>>>>
>>>> +bool is_any_jvmci_arg_values_changed() {
>>>>
>>>> This method needs another name.
>>>>
>>> Ok.
>>>> +  int check_count = 0, fail_count = 0;
>>>>
>>>> I don?t like the check_count/fail_count logic because it?s fragile.
>>> As  EanbleJVMCI flag cannot be avoided from macro expansion logic, i 
>>> had to use some technique to exclude this flag from failure decision 
>>> making.
>>> Check_count/fail_count logic was added as a solution for this. i.e 
>>> When EnableJVMCI is changed, code requires at-least 2 check failures 
>>> to decide a real failure. otherwise one failure is sufficient.
>>>
>>> if i remove this logic, i will have to use strcmp(#FLAG, 
>>> "EnableJVMCI") which will add a little more instructions that will  
>>> execute at-least once for every flag consistent run.
>>>
>>> let me know if i need to take second approach. or if existing code 
>>> is ok.
>>>>
>>>> +// Check if any jvmci global defaults changed.
>>>> +bool is_any_jvmci_arg_values_changed();
>>>> +// Print jvmci args inconsistency error message.
>>>> +void print_jvmci_arg_inconsistency_error_message();
>>>>
>>>> These should be in some kind of namespace or class.  Maybe put them 
>>>> into: class JVMCIGlobals
>>> Ok.
>>>
>>> Best Regards,
>>> Jamsheed
>>>>
>>>>>
>>>>>
>>>>> Best Regards,
>>>>> Jamsheed
>>>>>
>>>>> On 2/16/2016 6:50 PM, Jamsheed C m wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>> Revised webrev: 
>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/
>>>>>>
>>>>>> This code take care of every jvmci flags automatically.
>>>>>>
>>>>>> Best Regards,
>>>>>> Jamsheed
>>>>>>
>>>>>> On 2/13/2016 3:24 AM, Christian Thalinger wrote:
>>>>>>>
>>>>>>>> On Feb 12, 2016, at 7:12 AM, Jamsheed C m 
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>> On 2/12/2016 10:12 PM, Christian Thalinger wrote:
>>>>>>>>> Well, now you have to manually check all flags that had 
>>>>>>>>> a constraint directive.  That is the annoying part and what I 
>>>>>>>>> complained about in:
>>>>>>>> check against original value, and if not fail ?
>>>>>>>
>>>>>>> Same check for all flags; they all depend on +EnableJVMCI.
>>>>>>>
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8145357
>>>>>>>>>
>>>>>>>>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now 
>>>>>>>>> empty and I think we should remove them.
>>>>>>>> i kept the file as there can be future use. Ok, i will remove it.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Jamsheed
>>>>>>>>>
>>>>>>>>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m 
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Chris,
>>>>>>>>>>
>>>>>>>>>> revised webrev: 
>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Jamsheed
>>>>>>>>>>
>>>>>>>>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m 
>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Request for review
>>>>>>>>>>>>
>>>>>>>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333
>>>>>>>>>>>> web url: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> That looks alright but we should remove the constraints from 
>>>>>>>>>>> all the JVMCI command line flags because the way we use them 
>>>>>>>>>>> is not supported.
>>>>>>>>>>>
>>>>>>>>>>> Also, can you change the error message?  Right now it looks 
>>>>>>>>>>> like this:
>>>>>>>>>>>
>>>>>>>>>>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java 
>>>>>>>>>>> -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler
>>>>>>>>>>> EnableJVMCI must be enabled
>>>>>>>>>>> Improperly specified VM option 'UseJVMCICompiler'
>>>>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>>>>
>>>>>>>>>>> I think with your changes we will only see the first line 
>>>>>>>>>>> without mentioning UseJVMCICompiler.  Is that correct?
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Fix Summary: added jvmci flag consistency check after arg 
>>>>>>>>>>>> parsing.
>>>>>>>>>>>>
>>>>>>>>>>>> tests: jprt
>>>>>>>>>>>> unit test: command line verification
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From filipp.zhinkin at gmail.com  Fri Feb 19 07:12:01 2016
From: filipp.zhinkin at gmail.com (Filipp Zhinkin)
Date: Fri, 19 Feb 2016 10:12:01 +0300
Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down
	fastdebug builds' performance
In-Reply-To: <56C5E957.60009@oracle.com>
References: 
	<54F99281.7020101@oracle.com>
	
	
	<56B489D0.3070700@oracle.com>
	
	
	<56BDCF17.30308@oracle.com>
	
	
	<56C5E957.60009@oracle.com>
Message-ID: 

Hi Aleksey,

On Thu, Feb 18, 2016 at 6:55 PM, Aleksey Shipilev
 wrote:
> Hi Filipp,
>
> On 02/18/2016 06:31 PM, Filipp Zhinkin wrote:
>> I've looked at how frequently misses are actually occur and
>> how far false positives are from the interval we're looking for.
>>
>> Also I've tried to implement interval_cmp so that it returns 0
>> if difference between interval "from" values is below some threshold:
>> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/stats.txt
>>
>> All those misses with distance greater than 64 came from
>> javax.swing.plaf.synth.SynthStyle::populateDefaultValues [1].
>
> Okay, let me recap: your data seems to say that current binary search
> misses in 25% of the cases, and around 95% of the misses are within 8
> intervals from the false value, right? And almost all 99.99% are within
> 32 intervals?

Right.

>
> This does not seem bad, I was afraid of orders of magnitude larger values.
>
>> I've also looked to another possible slowness sources and
>> we spend about 10% of time in LinearScan's verify_intervals method
>> which checks that every two intervals don't simultaneously intersect
>> and share the same register [2].
>>
>> I don't see a way to significantly speed up such verification,
>> but I've slightly improved performance by rearranging some expressions.
>
> Yes, those re-arrangements make sense.
>
>> Here is an updated webrev:
>> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/
>
> Looks good to me (not a Reviewer).

Thanks!

>
>> Also, unless CommentedAssembly flag is explicitly turned off,
>> we're generating comments for stubs even if we're not going to print it out.
>> Avoiding comments generation in such case will speed up compilation a bit more,
>> but I think it would be better to deal with it in a separate RFE.
>> Difference in code emission time is about 30% when CommentedAssembly is off
>> (~ 40s w/ CommentedAssembly, ~ 25s w/o CommentedAssembly).
>
> Oh wow. Let's fix that! Of course, separate RFE is fine.

Here is it: https://bugs.openjdk.java.net/browse/JDK-8150222

Regards,
Filipp.

>
> Cheers,
> -Aleksey
>

From roland.westrelin at oracle.com  Fri Feb 19 07:54:26 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 19 Feb 2016 08:54:26 +0100
Subject: RFR(S): 8087341: C2 doesn't optimize redundant memory operations
	with G1
In-Reply-To: <56C20BD4.8030800@oracle.com>
References: 
	<56AA260B.8080101@redhat.com>
	<434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com>
	<56BB01E2.2090004@redhat.com>
	<9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com>
	<56BDB707.6090409@redhat.com>
	<8339FB73-9C21-4513-B07B-5DEBB8583188@oracle.com>
	<56BE3612.4080305@oracle.com>
	
	<56C20BD4.8030800@oracle.com>
Message-ID: 

Thanks for the review, Vladimir.

Roland.

> On Feb 15, 2016, at 6:33 PM, Vladimir Kozlov  wrote:
> 
> Good. Thank you.
> 
> Vladimir
> 
> On 2/15/16 1:21 AM, Roland Westrelin wrote:
>> 
>>> Can you create new webrev which includes everything (aarch64)?
>> 
>> Here it is:
>> http://cr.openjdk.java.net/~roland/8087341/webrev.01/
>> 
>> Roland.
>> 
>>> And I am satisfied with your answers to my objections.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 2/12/16 4:36 AM, Roland Westrelin wrote:
>>>> Hi Andrew,
>>>> 
>>>>> A patch for the AArch64 C2 volatile/CAS generation code which deals with
>>>>> the effects of your proposed C2 patch is available as a webrev
>>>>> 
>>>>> http://cr.openjdk.java.net/~adinn/8087341-aarch64/webrev.00/
>>>> 
>>>> Thanks for putting that together. I didn?t expect that simple change to cause so much trouble.
>>>> 
>>>>> n.b. I have /not/ created a separate issue for the AArch64 part of this
>>>>> fix. I am not sure whether you want to combine it with your patch or
>>>>> push it as a separate stage.
>>>> 
>>>> I can push everything together and list you as a contributor (in the contributed-by field) if that works for you.
>>>> 
>>>> Vladimir, can you take another look at this? Your two objections were:
>>>> 
>>>>> Also we have specialized insert_mem_bar_volatile() if we don't want wide memory affect. Why not use it?
>>>> 
>>>> The membar in the change takes the entire memory state as input but only changes raw memory. I don?t think that can be achieved with insert_mem_bar_volatile(). As explained by Mikael, the membar is here to force ordering between the oop store and the card table load. That?s why I think the membar?s inputs and outputs should be set up that way.
>>>> 
>>>>> And we need to keep precedent edge link to oop store in case EA eliminates related allocation.
>>>> 
>>>> Mikael said it?s not ok to eliminate the memory barrier if we leave the gc barrier.
>>>> 
>>>> Roland.
>>>> 
>> 


From roland.westrelin at oracle.com  Fri Feb 19 07:54:55 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 19 Feb 2016 08:54:55 +0100
Subject: [aarch64-port-dev ] RFR(S): 8087341: C2 doesn't optimize
	redundant memory operations with G1
In-Reply-To: <56C1B197.7060708@redhat.com>
References: 
	<56AA260B.8080101@redhat.com>
	<434839E5-8AB1-4FEC-BDD7-AD30ABBD6C76@oracle.com>
	<56BB01E2.2090004@redhat.com>
	<9C43B8E9-A34B-41EC-A433-CCA9B67623F5@oracle.com>
	<56BDB707.6090409@redhat.com>
	<8339FB73-9C21-4513-B07B-5DEBB8583188@oracle.com>
	<56BE3612.4080305@oracle.com>
	
	<56C1B197.7060708@redhat.com>
Message-ID: <8112862F-B94D-4043-AD3C-DF59BB8FB862@oracle.com>

Thanks, Andrew!

Roland.

> On Feb 15, 2016, at 12:08 PM, Andrew Dinn  wrote:
> 
> On 15/02/16 09:21, Roland Westrelin wrote:
>> 
>>> Can you create new webrev which includes everything (aarch64)?
>> 
>> Here it is:
>> http://cr.openjdk.java.net/~roland/8087341/webrev.01/
> 
> Thanks Roland. Looks good to go.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul
> Argiry (US)


From filipp.zhinkin at gmail.com  Fri Feb 19 08:05:48 2016
From: filipp.zhinkin at gmail.com (Filipp Zhinkin)
Date: Fri, 19 Feb 2016 11:05:48 +0300
Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down
	fastdebug builds' performance
In-Reply-To: <56C5EC68.5010003@oracle.com>
References: 
	<54F99281.7020101@oracle.com>
	
	
	<56B489D0.3070700@oracle.com>
	
	
	<56BDCF17.30308@oracle.com>
	
	
	<56C5EC68.5010003@oracle.com>
Message-ID: 

Hi Vladimir,

On Thu, Feb 18, 2016 at 7:08 PM, Vladimir Ivanov
 wrote:
> Thanks, Filipp.
>
> I suggest to address CommentedAssembly separately.
>
> One question: why don't you simply typedef IntervalArray/IntervalList to
> GrowableArray? It will eliminate numerous renamings you did.

Well, I'd prefer to explicitly declare type (unless there are numerous
nested template args).
But I'm fine with using typedef there.

Here is updated webrev:
http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.03/

Thanks,
Filipp.

>
> Otherwise, looks good.
>
> Best regards,
> Vladimir Ivanov
>
>
> On 2/18/16 6:31 PM, Filipp Zhinkin wrote:
>>
>> Hi,
>>
>> I've looked at how frequently misses are actually occur and
>> how far false positives are from the interval we're looking for.
>>
>> Also I've tried to implement interval_cmp so that it returns 0
>> if difference between interval "from" values is below some threshold:
>> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/stats.txt
>>
>> All those misses with distance greater than 64 came from
>> javax.swing.plaf.synth.SynthStyle::populateDefaultValues [1].
>>
>> I've also looked to another possible slowness sources and
>> we spend about 10% of time in LinearScan's verify_intervals method
>> which checks that every two intervals don't simultaneously intersect
>> and share the same register [2].
>>
>> I don't see a way to significantly speed up such verification,
>> but I've slightly improved performance by rearranging some expressions.
>>
>> Here is an updated webrev:
>> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/
>>
>> Also, unless CommentedAssembly flag is explicitly turned off,
>> we're generating comments for stubs even if we're not going to print it
>> out.
>> Avoiding comments generation in such case will speed up compilation a bit
>> more,
>> but I think it would be better to deal with it in a separate RFE.
>> Difference in code emission time is about 30% when CommentedAssembly is
>> off
>> (~ 40s w/ CommentedAssembly, ~ 25s w/o CommentedAssembly).
>>
>> [1]
>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/file/6c649a7ac744/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthStyle.java#l68
>> [2]
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/cffca6de2c45/src/share/vm/c1/c1_LinearScan.cpp#l3226
>>
>> On Fri, Feb 12, 2016 at 7:08 PM, Filipp Zhinkin
>>  wrote:
>>>
>>> Hi Aleksey,
>>>
>>> On Fri, Feb 12, 2016 at 3:24 PM, Aleksey Shipilev
>>>  wrote:
>>>>
>>>> Hi Filipp,
>>>>
>>>> On 02/12/2016 02:47 PM, Filipp Zhinkin wrote:
>>>>>
>>>>> here is a new webrev:
>>>>> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.01/
>>>>
>>>>
>>>> The webrev seems incomplete: it has only hotspot.patch in it, but no
>>>> other views?
>>>
>>>
>>> It seems like only wdiff's are empty for some reason.
>>> What else is missed out there?
>>>
>>>>
>>>> I wonder how many intervals have the same "from", prompting you to
>>>> wiggle around looking for the exact interval?
>>>
>>>
>>> Well, there should be (relatively) many intervals with "from" == 0
>>> created for physical registers.
>>> For virtual registers there could be few intervals that share the same
>>> "from" value:
>>> it depends on amount of temporary registers required by an operation
>>> and amount of outputs it produces.
>>>
>>> So we may simply scan intervals from beginning if key's from value is 0.
>>>
>>>> Can we define
>>>> "interval_cmp" so that "(interval_cmp(i1, i2) == 0) iff (i1 == i2)",
>>>
>>>
>>> No, unfortunately we can't, because intervals are ordered only by "from"
>>> value.
>>>
>>>> or at least make the false positives less frequent with more extensive
>>>> interval key (assuming collisions are indeed problematic)?
>>>>
>>>
>>> Not sure that I've got you.
>>>
>>> Nevertheless, I'll run CTW and check how many false positives are
>>> actually found.
>>>
>>>>
>>>>> I've hacked VM sources a bit to run CTW with product bits and C1
>>>>> compilation time on my x86_64 linux laptop
>>>>> slowed down by 0.4% (from 51029 ? 306 ms to 51230 ? 293 ms). Please
>>>>> let me know if it too slow.
>>>>
>>>>
>>>> I think this is within the error margin, and therefore statistically
>>>> insignificant. Even if it was significant, 0.4% is okay for compilation
>>>> time regression in C1.
>>>>
>>>>> With fastdebug bits provided patch allow to reduce C1 compilation time
>>>>> twice.
>>>>
>>>>
>>>> This is a very good improvement, but we need to see if that's the end of
>>>> it, or we can squeeze even more with a few changes. I would suggest
>>>> running the CTW scenario under Solaris Studio Performance Analyzer (see
>>>> e.g.
>>>>
>>>> http://shipilev.net/blog/2016/arrays-wisdom-ancients/#_meet_solaris_studio_performance_analyzer).
>>>
>>>
>>> Thank you for the suggestion, I'll check it.
>>>
>>> Regards,
>>> Filipp.
>>>
>>>>
>>>> Thanks,
>>>> -Aleksey
>>>>
>>>>
>

From vladimir.x.ivanov at oracle.com  Fri Feb 19 10:30:20 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 19 Feb 2016 13:30:20 +0300
Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down
	fastdebug builds' performance
In-Reply-To: 
References: 
	<54F99281.7020101@oracle.com>
	
	
	<56B489D0.3070700@oracle.com>
	
	
	<56BDCF17.30308@oracle.com>
	
	
	<56C5EC68.5010003@oracle.com>
	
Message-ID: <56C6EEBC.8060309@oracle.com>


> Well, I'd prefer to explicitly declare type (unless there are numerous
> nested template args).
> But I'm fine with using typedef there.
You could extend GrowableArray instead, but it doesn't worth 
it unless there's a need to introduce new methods.

> Here is updated webrev:
> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.03/
Looks good. Thanks for taking care of it!

I'll sponsor the change.

Best regards,
Vladimir Ivanov

From vladimir.x.ivanov at oracle.com  Fri Feb 19 10:30:55 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 19 Feb 2016 13:30:55 +0300
Subject: [9] RFR (M): 8149741: Don't refer to stub entry points by index
	in external_word relocations
In-Reply-To: <56C62546.9050804@oracle.com>
References: <56C4900D.6080708@oracle.com> <56C54003.6070603@oracle.com>
	<56C5842C.4090009@oracle.com> <56C62546.9050804@oracle.com>
Message-ID: <56C6EEDF.3050300@oracle.com>

Thanks, Vladimir.

Best regards,
Vladimir Ivanov

On 2/18/16 11:10 PM, Vladimir Kozlov wrote:
> Looks good.
>
> thanks,
> Vladimir
>
> On 2/18/16 12:43 AM, Vladimir Ivanov wrote:
>>> Nice clean up!
>> Thanks, Vladimir.
>>
>> Updated webrev:
>>    http://cr.openjdk.java.net/~vlivanov/8149741/webrev.01.index/
>>
>>>
>>> Casts should be the same:
>>>
>>> (uintptr_t)target >= (uint)os::vm_page_size()
>> Fixed.
>>
>>> Why in assembler_windows_x86.cpp you used NULL_WORD and not simple NULL?
>>> NULL_WORD is used for integer values and NULL for pointers
>>> which is this case.
>> Fixed.
>>
>> Best regards,
>> Vladimir Ivanov

From martin.doerr at sap.com  Fri Feb 19 10:37:34 2016
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 19 Feb 2016 10:37:34 +0000
Subject: RFR(L) 8149655: PPC64: Implement CompactString intrinsics
In-Reply-To: <6d2ee7af0e2947abb989fa84369f4f0f@DEWDFE13DE09.global.corp.sap>
References: 
	<6d2ee7af0e2947abb989fa84369f4f0f@DEWDFE13DE09.global.corp.sap>
Message-ID: <717d9d731f294a8eb3ba6be83e7e4c05@DEWDFE13DE13.global.corp.sap>

Hi G?tz,

thanks for the review. I basically used small micro-benchmarks and tests and later our nightly tests which I have extended a little bit with this change. There were some match rules which I only hit with the change I made in TestStringIntrinsics2.

I think you're right. The addition to the predicate for string_indexOf_imm1_charNode should not be needed because the AddP node for the immediate needle gets matched with the StrIndexOfNode.
I have removed it again from this node and from the new nodes which match indexOf_imm1_char in the 3 different flavors.

Spaces before comma are also fixed.

The guarantee(needlecntval != 1, ...) is not new. It was already there in the non-CompactStrings version. string_indexof wouldn't generate correct code. There's a separate match rule for that case.

New webrev is here:
http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.01/

Best regards,
Martin


From: Lindenmaier, Goetz
Sent: Donnerstag, 18. Februar 2016 20:50
To: Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net
Subject: RE: RFR(L) 8149655: PPC64: Implement CompactString intrinsics

Hi Martin,

I finally had a look at this change.  Good work!

What did you test this with,  besides our hs-comp nighttests, which
already is quite a lot?

ppc.ad:
I saw you added more conditions to the predicate of  string_indexOf_imm1_char() etc.
Isn't this obvious because needleImm is an immP?

macroassmbler_ppc.cpp:
if (stride1 == 1) { lbz(chr1, 0, str1); } else { lhz(chr1, 0 ,str1); }
Space before comma.  There are more of these, search for '0 ,'
guarantee(needlecntval != 1,
not indented ... or is this on purpose?

Best regards,
  Goetz.

From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin
Sent: Thursday, February 11, 2016 4:11 PM
To: hotspot-compiler-dev at openjdk.java.net
Subject: RFR(L) 8149655: PPC64: Implement CompactString intrinsics

Hi,

I have created a webrev which adds the following String intrinsics to PPC64:
0 string_compareL
1 string_compareU
2 string_compareLU
3 string_compareUL
4 string_equalsL
5 string_equalsU
6 array_equalsB
7 array_equalsC
8 indexOf_imm1_char_U
9 indexOf_imm1_char_L
10 indexOf_imm1_char_UL
11 indexOf_imm1_U
12 indexOf_imm1_L
13 indexOf_imm1_UL
14 indexOfChar_U
15 indexOf_imm_U
16 indexOf_imm_L
17 indexOf_imm_UL
18 indexOf_U
19 indexOf_L
20 indexOf_UL
21 string_compress
22 string_inflate
23 has_negatives
24 encode_iso_array

It also contains some other minor improvements.

The webrev is here:
http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.00/

Please review.

I will also need a sponsor from Oracle because the change touches one java test file (test/compiler/intrinsics/string/TestStringIntrinsics2.java).

Best regards,
Martin




-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From filipp.zhinkin at gmail.com  Fri Feb 19 11:03:05 2016
From: filipp.zhinkin at gmail.com (Filipp Zhinkin)
Date: Fri, 19 Feb 2016 14:03:05 +0300
Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down
	fastdebug builds' performance
In-Reply-To: <56C6EEBC.8060309@oracle.com>
References: 
	<54F99281.7020101@oracle.com>
	
	
	<56B489D0.3070700@oracle.com>
	
	
	<56BDCF17.30308@oracle.com>
	
	
	<56C5EC68.5010003@oracle.com>
	
	<56C6EEBC.8060309@oracle.com>
Message-ID: 

Thank you, Vladimir.

Regards,
Filipp.

On Fri, Feb 19, 2016 at 1:30 PM, Vladimir Ivanov
 wrote:
>
>> Well, I'd prefer to explicitly declare type (unless there are numerous
>> nested template args).
>> But I'm fine with using typedef there.
>
> You could extend GrowableArray instead, but it doesn't worth it
> unless there's a need to introduce new methods.
>
>> Here is updated webrev:
>> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.03/
>
> Looks good. Thanks for taking care of it!
>
> I'll sponsor the change.
>
> Best regards,
> Vladimir Ivanov

From aleksey.shipilev at oracle.com  Fri Feb 19 11:55:34 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 19 Feb 2016 14:55:34 +0300
Subject: RFR (S) 8150180: String.value contents should be trusted
Message-ID: <56C702B6.5010903@oracle.com>

Hi,

Please review a simple performance improvement in Strings:
  https://bugs.openjdk.java.net/browse/JDK-8150180

In short, we want VM to trust constant String contents, so that
"Foo".charAt(0) is folded. As far as current Hotspot goes, this is only
achievable with @Stable -- we need to trust the array contents:
  http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/

This, however, steps into the compiler bug caused by StringUTF16.getChar
intrinsic producing a mismatched load, that is then folded incorrectly.
So we instead rely on Java level folding in cases like these:
  http://cr.openjdk.java.net/~shade/8150180/webrev.hs.01/

...and it works:
  http://cr.openjdk.java.net/~shade/8150180/notes.txt

While VM change looks like a workaround, Vladimir I. and me concluded
that @Stable folding code should just reject folding mismatched loads to
begin with. So, getChar intrinsic change is the actual fix. Vladimir I.
ought to add more assertions in @Stable folding code separately:
  https://bugs.openjdk.java.net/browse/JDK-8150186

Since this issue might trigger compiler bugs, I would like to push
through hs-comp to pass compiler nightlies.

Cheers,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From hui.shi at linaro.org  Fri Feb 19 12:13:28 2016
From: hui.shi at linaro.org (Hui Shi)
Date: Fri, 19 Feb 2016 20:13:28 +0800
Subject: RFR: 8149733: AArch64: refactor
	char_array_equals/byte_array_equals/string_equals
Message-ID: 

Hi,

Could some one help review this patch? This patch mainly aims to
refactoring similar code on AArch64 for string equals/ char array equals
and byte array equals.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8149733
webrev: http://cr.openjdk.java.net/~hshi/8149733/webrev/

Patch includes:
1. Add new method MacroAssembler::generic_arrays_equals method, its
implementation combines string_equals and char/byte_array_equals.
   For array length >= 8 bytes, compare main body and tail bytes in 8 bytes
wide. Same with current string equals' implementation. This eliminates tail
branches and loads and improve performance on short length compare.
   For array length < 8 bytes, compare in test-ld-cmp sequence. It out
performs loop copy in string_equals.
2. Remove unnecessary lea address computation (mov array pointer to last
word) in string_equals.
3. Remove unnecessary tmp register for string_equals.

JTreg doesn?t show regression and performance also doesn't degradate with
different length combination. Small char/byte equals improves in most
tests. There is one slow run with new implementation, because last several
chars are different in test case. Original char array equals can find the
difference with first test-ld-cmp check, test-ld-cmp sequence might be
faster than entire unaligned 8 byte compare in some corner cases. Test
different chars in middle of string, performance is close for both
implementation.

Test case: http://cr.openjdk.java.net/~hshi/8149733/TestArrayEqual.java
Test result: http://cr.openjdk.java.net/~hshi/8149733/ArrayEqual.pdf

Regards
Hui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From felix.yang at linaro.org  Fri Feb 19 12:23:11 2016
From: felix.yang at linaro.org (Felix Yang)
Date: Fri, 19 Feb 2016 20:23:11 +0800
Subject: RFR: 8150229: aarch64: c2 fix pipeline class for several instructions.
Message-ID: 

Hi,

Please review the following webrev:

    http://cr.openjdk.java.net/~fyang/8150229/webrev.00/

Jira issue: *https://bugs.openjdk.java.net/browse/JDK-8150229
*

The pipeline class for some instructions is not set correctly.  An example:

instruct MoveF2I_reg_reg(iRegINoSp dst, vRegF src) %{
  match(Set dst (MoveF2I src));
  effect(DEF dst, USE src);

  ins_cost(INSN_COST);
  format %{ "fmovs $dst, $src\t# MoveF2I_reg_reg" %}

  ins_encode %{
    __ fmovs($dst$$Register, as_FloatRegister($src$$reg));
  %}

  ins_pipe(pipe_class_memory);    =>    Should be "fp_f2i"
%}

Patch fixes this issue.  Tested with jtreg hotspot.  Please help
commit this patch if it's OK.

Thanks,
Felix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From aph at redhat.com  Fri Feb 19 12:23:25 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 19 Feb 2016 12:23:25 +0000
Subject: [aarch64-port-dev ] RFR: 8149733: AArch64: refactor
	char_array_equals/byte_array_equals/string_equals
In-Reply-To: 
References: 
Message-ID: <56C7093D.9070408@redhat.com>

On 02/19/2016 12:13 PM, Hui Shi wrote:
> Could some one help review this patch? This patch mainly aims to
> refactoring similar code on AArch64 for string equals/ char array equals
> and byte array equals.

I'm looking at it.  It's quite complex and I won't reply immediately.

Thanks,

Andrew.


From aleksey.shipilev at oracle.com  Fri Feb 19 12:36:18 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 19 Feb 2016 15:36:18 +0300
Subject: RFR: 8149733: AArch64: refactor
	char_array_equals/byte_array_equals/string_equals
In-Reply-To: 
References: 
Message-ID: <56C70C42.5020309@oracle.com>

Hi Hui,

On 02/19/2016 03:13 PM, Hui Shi wrote:
> webrev: http://cr.openjdk.java.net/~hshi/8149733/webrev/
> 

Not savvy with AArch64 assembly, but it does not look bad.

My other comments are superficial:

 * Desperately needs spell-checking: "implenetaions", "implemenation",
"eqauls", "comapre"

 * Inconsistent naming, e.g. "... = wordSize/step_size;"

 * "if (is_string_equal == false) {"

 * "if (exact_log >0 )"

 * Shouldn't be:

	4533     ldrw(cnt1, Address(ary1, length_offset));
	4534     ldrw(tmp2, Address(ary2, length_offset));
	4535     cmp(cnt1, tmp2);

  spelled like:

	4533 ldrw(cnt1, Address(ary1, length_offset));
	4534 ldrw(cnt2, Address(ary2, length_offset));
	4535 cmp(cnt1, cnt2);

 * Would be nice to keep the comments like "// 0-7 bytes left, cnt1 =
#bytes left - 4"

 * Why TAIL01 block is predicated on (step_size == 1) now?

> Test case: http://cr.openjdk.java.net/~hshi/8149733/TestArrayEqual.java
> 

I think you should really, really, really use JMH for these benchmarks:
 http://openjdk.java.net/projects/code-tools/jmh/

It would also provide you an easy access to generated code profiling,
with -prof perfasm. It is usually pretty clear from that output if your
generated code needs even more tuneups.

Cheers,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From vladimir.x.ivanov at oracle.com  Fri Feb 19 12:42:18 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 19 Feb 2016 15:42:18 +0300
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56C702B6.5010903@oracle.com>
References: <56C702B6.5010903@oracle.com>
Message-ID: <56C70DAA.6000806@oracle.com>

>    http://cr.openjdk.java.net/~shade/8150180/webrev.hs.01/

Why don't you check that index is also a constant? Otherwise, C2 can't 
constant fold the loads.

+  if (value->is_Con()) {
+    return false;
+  }

Best regards,
Vladimir Ivanov

From goetz.lindenmaier at sap.com  Fri Feb 19 13:14:39 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 19 Feb 2016 13:14:39 +0000
Subject: RFR(L) 8149655: PPC64: Implement CompactString intrinsics
In-Reply-To: <717d9d731f294a8eb3ba6be83e7e4c05@DEWDFE13DE13.global.corp.sap>
References: 
	<6d2ee7af0e2947abb989fa84369f4f0f@DEWDFE13DE09.global.corp.sap>
	<717d9d731f294a8eb3ba6be83e7e4c05@DEWDFE13DE13.global.corp.sap>
Message-ID: <898cbee841884ef7b4f3ad9e3681e282@DEWDFE13DE09.global.corp.sap>

Hi Martin,

looks good now. Could someone please sponsor?

Thanks for the fixes,
  Goetz.

From: Doerr, Martin
Sent: Friday, February 19, 2016 11:38 AM
To: Lindenmaier, Goetz ; hotspot-compiler-dev at openjdk.java.net
Subject: RE: RFR(L) 8149655: PPC64: Implement CompactString intrinsics

Hi G?tz,

thanks for the review. I basically used small micro-benchmarks and tests and later our nightly tests which I have extended a little bit with this change. There were some match rules which I only hit with the change I made in TestStringIntrinsics2.

I think you're right. The addition to the predicate for string_indexOf_imm1_charNode should not be needed because the AddP node for the immediate needle gets matched with the StrIndexOfNode.
I have removed it again from this node and from the new nodes which match indexOf_imm1_char in the 3 different flavors.

Spaces before comma are also fixed.

The guarantee(needlecntval != 1, ...) is not new. It was already there in the non-CompactStrings version. string_indexof wouldn't generate correct code. There's a separate match rule for that case.

New webrev is here:
http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.01/

Best regards,
Martin


From: Lindenmaier, Goetz
Sent: Donnerstag, 18. Februar 2016 20:50
To: Doerr, Martin >; hotspot-compiler-dev at openjdk.java.net
Subject: RE: RFR(L) 8149655: PPC64: Implement CompactString intrinsics

Hi Martin,

I finally had a look at this change.  Good work!

What did you test this with,  besides our hs-comp nighttests, which
already is quite a lot?

ppc.ad:
I saw you added more conditions to the predicate of  string_indexOf_imm1_char() etc.
Isn't this obvious because needleImm is an immP?

macroassmbler_ppc.cpp:
if (stride1 == 1) { lbz(chr1, 0, str1); } else { lhz(chr1, 0 ,str1); }
Space before comma.  There are more of these, search for '0 ,'
guarantee(needlecntval != 1,
not indented ... or is this on purpose?

Best regards,
  Goetz.

From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin
Sent: Thursday, February 11, 2016 4:11 PM
To: hotspot-compiler-dev at openjdk.java.net
Subject: RFR(L) 8149655: PPC64: Implement CompactString intrinsics

Hi,

I have created a webrev which adds the following String intrinsics to PPC64:
0 string_compareL
1 string_compareU
2 string_compareLU
3 string_compareUL
4 string_equalsL
5 string_equalsU
6 array_equalsB
7 array_equalsC
8 indexOf_imm1_char_U
9 indexOf_imm1_char_L
10 indexOf_imm1_char_UL
11 indexOf_imm1_U
12 indexOf_imm1_L
13 indexOf_imm1_UL
14 indexOfChar_U
15 indexOf_imm_U
16 indexOf_imm_L
17 indexOf_imm_UL
18 indexOf_U
19 indexOf_L
20 indexOf_UL
21 string_compress
22 string_inflate
23 has_negatives
24 encode_iso_array

It also contains some other minor improvements.

The webrev is here:
http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.00/

Please review.

I will also need a sponsor from Oracle because the change touches one java test file (test/compiler/intrinsics/string/TestStringIntrinsics2.java).

Best regards,
Martin




-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From paul.sandoz at oracle.com  Fri Feb 19 13:41:58 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 19 Feb 2016 14:41:58 +0100
Subject: RFR 8149469: ByteBuffer API and implementation enhancements for
	VarHandles
In-Reply-To: <7D96A27B-E240-448D-8D6E-DF2DD54D3BBC@oracle.com>
References: <6F457380-0E56-4909-BFBF-B3D6FE45B326@oracle.com>
	<949FB585-4AF7-4D6D-923C-A336EDFB40ED@oracle.com>
	<7D96A27B-E240-448D-8D6E-DF2DD54D3BBC@oracle.com>
Message-ID: <91AAEDB8-C893-4431-BECF-CA6754D9CB0A@oracle.com>


> On 18 Feb 2016, at 16:54, Paul Sandoz  wrote:
> I still need to think a little more about the upper bound of unitSize, i put a limit of 64 (cache line size) to stop silly values:
> 
> - implementation-wise, for non-direct buffers any value above 8 should throw a USO.
> 
> - for direct buffers is 64 too small? what about for page size alignment?
> 

I updated the webrev in place to:

1) throw a USO for non-direct buffers with unit sizes > 8, this is documented in an implementation note.

2) removed the upper limit on unit size, so for direct buffers one could choose page size as the unit size

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149469-byte-buffer-align-and-unifying-enhancements/webrev/ 

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: 

From peter.levart at gmail.com  Fri Feb 19 14:05:12 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 19 Feb 2016 15:05:12 +0100
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56C702B6.5010903@oracle.com>
References: <56C702B6.5010903@oracle.com>
Message-ID: <56C72118.6030304@gmail.com>

Hi,

Just a stupid question.

Your comment in String:

  140      * @implNote Note this field is not {@link Stable}, because we 
want
  141      * LATIN1 (0) coder to fold too. {@link Stable} would not 
allow that,
  142      * as it reserves the default value as "not initialized" value.
  143      * Constant-folding this field is handled internally in VM.
  144      */
  145     private final byte coder;


Couldn't @Stable final instance fields constant-fold the default value 
too in general? I mean can't it be assumed that the final field has been 
set before JIT kicks in?

Regards, Peter

On 02/19/2016 12:55 PM, Aleksey Shipilev wrote:
> Hi,
>
> Please review a simple performance improvement in Strings:
>    https://bugs.openjdk.java.net/browse/JDK-8150180
>
> In short, we want VM to trust constant String contents, so that
> "Foo".charAt(0) is folded. As far as current Hotspot goes, this is only
> achievable with @Stable -- we need to trust the array contents:
>    http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/
>
> This, however, steps into the compiler bug caused by StringUTF16.getChar
> intrinsic producing a mismatched load, that is then folded incorrectly.
> So we instead rely on Java level folding in cases like these:
>    http://cr.openjdk.java.net/~shade/8150180/webrev.hs.01/
>
> ...and it works:
>    http://cr.openjdk.java.net/~shade/8150180/notes.txt
>
> While VM change looks like a workaround, Vladimir I. and me concluded
> that @Stable folding code should just reject folding mismatched loads to
> begin with. So, getChar intrinsic change is the actual fix. Vladimir I.
> ought to add more assertions in @Stable folding code separately:
>    https://bugs.openjdk.java.net/browse/JDK-8150186
>
> Since this issue might trigger compiler bugs, I would like to push
> through hs-comp to pass compiler nightlies.
>
> Cheers,
> -Aleksey
>


From aleksey.shipilev at oracle.com  Fri Feb 19 14:07:57 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 19 Feb 2016 17:07:57 +0300
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56C72118.6030304@gmail.com>
References: <56C702B6.5010903@oracle.com> <56C72118.6030304@gmail.com>
Message-ID: <56C721BD.9010505@oracle.com>

Hi Peter,

On 02/19/2016 05:05 PM, Peter Levart wrote:
> Your comment in String:
> 
>  140      * @implNote Note this field is not {@link Stable}, because we
> want
>  141      * LATIN1 (0) coder to fold too. {@link Stable} would not allow
> that,
>  142      * as it reserves the default value as "not initialized" value.
>  143      * Constant-folding this field is handled internally in VM.
>  144      */
>  145     private final byte coder;
> 
> 
> Couldn't @Stable final instance fields constant-fold the default value
> too in general? I mean can't it be assumed that the final field has been
> set before JIT kicks in?

We've been over this multiple times, actually. @Stable is not designed
to fold default value -- it is a part of its design to ignore final
fields with default values. Because @Stable is used largely for lazy
initialization, and default value is the important marker in field's
lifecycles.

Cheers,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From aleksey.shipilev at oracle.com  Fri Feb 19 14:17:43 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 19 Feb 2016 17:17:43 +0300
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56C70DAA.6000806@oracle.com>
References: <56C702B6.5010903@oracle.com> <56C70DAA.6000806@oracle.com>
Message-ID: <56C72407.2070301@oracle.com>

On 02/19/2016 03:42 PM, Vladimir Ivanov wrote:
>>    http://cr.openjdk.java.net/~shade/8150180/webrev.hs.01/
> 
> Why don't you check that index is also a constant? Otherwise, C2 can't
> constant fold the loads.
> 
> +  if (value->is_Con()) {
> +    return false;
> +  }

Right. Without that, constant-value + non-constant-index also bail
unnecessarily. Actually, we should also bail only for getChar, but not
putChar:
  http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/
  http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/

Cheers,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From konstantin.shefov at oracle.com  Fri Feb 19 14:27:05 2016
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 19 Feb 2016 17:27:05 +0300
Subject: [9] RFR JDK-8141618: Change JVMCI compilerToVM constant pool
	tests to support CP caching
In-Reply-To: <827C7189-9979-4174-9E0F-549F848B37CA@oracle.com>
References: <56C47C58.9090104@oracle.com>
	<68AEB7F8-14A8-4BC5-B910-501E2980F646@oracle.com>
	<56C5A03D.9040602@oracle.com>
	<827C7189-9979-4174-9E0F-549F848B37CA@oracle.com>
Message-ID: <56C72639.7070905@oracle.com>

Chris,

I have added some imports to get rid of long names.
http://cr.openjdk.java.net/~kshefov/8141618/webrev.02/

-Konstantin

On 02/18/2016 09:52 PM, Christian Thalinger wrote:
> It?s difficult to follow the logic and make sure there is no bug.  I did not verify all this.  Looks good anyway.
>
>> On Feb 18, 2016, at 12:43 AM, Konstantin Shefov  wrote:
>>
>> Christian, thanks for looking into this
>>
>> I have reformatted the code to make it look better:
>> http://cr.openjdk.java.net/~kshefov/8141618/webrev.01
>>
>> -Konstantin
>>
>> On 02/17/2016 09:43 PM, Christian Thalinger wrote:
>>> Why do you have to break every line at, what, 50 characters?  This is unreadable:
>>>
>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.CLASS,
>>> +                ConstantTypes.CONSTANT_CLASS);
>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.FIELDREF,
>>> +                ConstantTypes.CONSTANT_FIELDREF);
>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.METHODREF,
>>> +                ConstantTypes.CONSTANT_METHODREF);
>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.INTERFACEMETHODREF,
>>> +                ConstantTypes.CONSTANT_INTERFACEMETHODREF);
>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.STRING,
>>> +                ConstantTypes.CONSTANT_STRING);
>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.INTEGER,
>>> +                ConstantTypes.CONSTANT_INTEGER);
>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.FLOAT,
>>> +                ConstantTypes.CONSTANT_FLOAT);
>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.LONG,
>>> +                ConstantTypes.CONSTANT_LONG);
>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.DOUBLE,
>>>
>>> And this is not the only occurrence.  I can?t review this.
>>>
>>>> On Feb 17, 2016, at 3:57 AM, Konstantin Shefov  wrote:
>>>>
>>>> Hello
>>>>
>>>> Please review a test enhancement.
>>>> It is an improvement for JVMCI CompilerToVM class tests.
>>>>
>>>> See https://bugs.openjdk.java.net/browse/JDK-8138708 for more info.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141618
>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8141618/webrev.00/
>>>>
>>>> Thanks
>>>> -Konstantin


From konstantin.shefov at oracle.com  Fri Feb 19 14:27:40 2016
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 19 Feb 2016 17:27:40 +0300
Subject: [9] RFR JDK-8141619: Develop new tests for JVMCI compilerToVM
	class' CP related methods
In-Reply-To: <7663E05E-544E-4FFB-8E7F-A329143B64A5@oracle.com>
References: <56C47D09.4030006@oracle.com>
	
	<56C5A08B.50001@oracle.com>
	<7663E05E-544E-4FFB-8E7F-A329143B64A5@oracle.com>
Message-ID: <56C7265C.3070108@oracle.com>

Chris,

I have added some imports to get rid of long names.
http://cr.openjdk.java.net/~kshefov/8141619/webrev.02/

-Konstantin

On 02/18/2016 09:56 PM, Christian Thalinger wrote:
>   57 typeTests.put(ConstantPoolTestCase.ConstantTypes.CONSTANT_METHODREF,
>   58 LookupNameAndTypeRefIndexInPoolTest::validate);
>
> You should use static imports so you can get rid 
> of ConstantPoolTestCase.ConstantTypes.  Actually, the same would be 
> useful in your other review too.
>
>> On Feb 18, 2016, at 12:44 AM, Konstantin Shefov 
>> > 
>> wrote:
>>
>> According to Christian's comments to RFR JDK-8141618 I have 
>> reformatted the code to make it look better:
>> http://cr.openjdk.java.net/~kshefov/8141619/webrev.01/
>>
>> -Konstantin
>>
>> On 02/17/2016 09:46 PM, Christian Thalinger wrote:
>>>
>>>> On Feb 17, 2016, at 4:00 AM, Konstantin Shefov 
>>>> >>> > wrote:
>>>>
>>>> Hello
>>>>
>>>> Please review new tests for methods of JVMCI 
>>>> jdk.vm.ci.hotspot.CompilerToVM class.
>>>>
>>>> See https://bugs.openjdk.java.net/browse/JDK-8138708 for more info.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141619
>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8141619/webrev.00/ 
>>>> 
>>>
>>> Link is wrong: http://cr.openjdk.java.net/~kshefov/8141619/webrev/ 
>>> 
>>>
>>>>
>>>> Thanks
>>>> -Konstantin
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.levart at gmail.com  Fri Feb 19 14:36:36 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 19 Feb 2016 15:36:36 +0100
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56C721BD.9010505@oracle.com>
References: <56C702B6.5010903@oracle.com> <56C72118.6030304@gmail.com>
	<56C721BD.9010505@oracle.com>
Message-ID: <56C72874.2070606@gmail.com>



On 02/19/2016 03:07 PM, Aleksey Shipilev wrote:
> Hi Peter,
>
> On 02/19/2016 05:05 PM, Peter Levart wrote:
>> Your comment in String:
>>
>>   140      * @implNote Note this field is not {@link Stable}, because we
>> want
>>   141      * LATIN1 (0) coder to fold too. {@link Stable} would not allow
>> that,
>>   142      * as it reserves the default value as "not initialized" value.
>>   143      * Constant-folding this field is handled internally in VM.
>>   144      */
>>   145     private final byte coder;
>>
>>
>> Couldn't @Stable final instance fields constant-fold the default value
>> too in general? I mean can't it be assumed that the final field has been
>> set before JIT kicks in?
> We've been over this multiple times, actually. @Stable is not designed
> to fold default value -- it is a part of its design to ignore final
> fields with default values. Because @Stable is used largely for lazy
> initialization, and default value is the important marker in field's
> lifecycles.
>
> Cheers,
> -Aleksey
>

Yes, I understand the general principle of @Stable design and the role 
of default value in @Stable fields. But given that:

- instance final fields must be set in the constructor
- the reference to the constructed object can not be assigned to a 
static final field until the constructor is finished

...the compiler could assume that even the default value is the final 
field's stable value, couldn't it?

I understand that these are Java language constraints and not 
necessarily bytecode constraints. Also, while a static final field can 
only be assigned to reference an instance after the instance is fully 
constructed, this does not hold for @Stable fields in general, for example:

class Foo {
     @Stable static Foo foo;

     @Stable final int coder;

     Foo() {
         foo = this;
         // outside code could already access Foo.foo.coder and constant 
fold it to 0
         coder = 1;
     }
}

...given that @Stable is an internal annotation, such usages could be 
advised against. It is generally bad practice to publish an object from 
within its constructor anyway.

But never mind. This is just me thinking loud.

Regards, Peter


From vladimir.x.ivanov at oracle.com  Fri Feb 19 14:42:27 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 19 Feb 2016 17:42:27 +0300
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56C72407.2070301@oracle.com>
References: <56C702B6.5010903@oracle.com> <56C70DAA.6000806@oracle.com>
	<56C72407.2070301@oracle.com>
Message-ID: <56C729D3.80404@oracle.com>

>    http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/
>    http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/
Looks good.

Best regards,
Vladimir Ivanov

From jamsheed.c.m at oracle.com  Fri Feb 19 15:38:02 2016
From: jamsheed.c.m at oracle.com (Jamsheed C m)
Date: Fri, 19 Feb 2016 21:08:02 +0530
Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler
	-XX:-EnableJVMCI makes JVM crash
In-Reply-To: <56C6A6DE.9060806@oracle.com>
References: <56BC90DC.10004@oracle.com>
	
	<56BD8DF9.1070605@oracle.com>
	
	<56BE1274.4020506@oracle.com>
	<41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com>
	<56C3221D.2040507@oracle.com> <56C48936.4090303@oracle.com>
	
	<56C5163D.7010208@oracle.com> <56C5F0CA.5010307@oracle.com>
	
	<56C6A6DE.9060806@oracle.com>
Message-ID: <56C736DA.304@oracle.com>

Hi Chris,

Made all suggested changes.

Revised webrev: http://cr.openjdk.java.net/~jcm/8145333/webrev.05/

Thanks and Best Regards,
Jamsheed

On 2/19/2016 10:53 AM, Jamsheed C m wrote:
>
>
> On 2/18/2016 11:21 PM, Christian Thalinger wrote:
>> +  if (EnableJVMCI)
>> +    return true;
>>
>> Please use { } for all if statements.
> Ok.
>>
>> Thanks for the comments; it?s easier to understand now.  May I 
>> suggest to do:
>>
>>   int skip_fail_count;
>>   if (!FLAG_IS_DEFAULT(EnableJVMCI)) {
>>     skip_fail_count = 1;
>>   } else {
>>     skip_fail_count = 0;
>>   }
> Ok.
>
> Best Regards,
> Jamsheed
>>
>>> On Feb 18, 2016, at 6:26 AM, Jamsheed C m  
>>> wrote:
>>>
>>> Hi Chris,
>>>
>>> Made all suggested changes.
>>>
>>> Revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.04/
>>>
>>> Best Regards,
>>> Jamsheed
>>>
>>> On 2/18/2016 6:24 AM, Jamsheed C m wrote:
>>>>
>>>>
>>>> On 2/18/2016 12:36 AM, Christian Thalinger wrote:
>>>>>
>>>>>> On Feb 17, 2016, at 4:52 AM, Jamsheed C m 
>>>>>>  wrote:
>>>>>>
>>>>>> experimental and diagnostic flags are under condition checks now.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.03/ 
>>>>>> 
>>>>>
>>>>> I?m not very happy about the new macros but I can see why it?s useful.
>>>>>
>>>>> +#if INCLUDE_JVMCI
>>>>> +
>>>>> +// Check consistency of jvmci vm argument settings.
>>>>> +bool Arguments::check_jvmci_args_consistency() {
>>>>> +
>>>>> +
>>>>> +  if (!EnableJVMCI && is_any_jvmci_arg_values_changed()) {
>>>>> +  print_jvmci_arg_inconsistency_error_message();
>>>>> +    return false;
>>>>>
>>>>> Please remove all these empty lines.  There are others as well.
>>>>>
>>>>> +bool is_any_jvmci_arg_values_changed() {
>>>>>
>>>>> This method needs another name.
>>>>>
>>>> Ok.
>>>>> +  int check_count = 0, fail_count = 0;
>>>>>
>>>>> I don?t like the check_count/fail_count logic because it?s fragile.
>>>> As  EanbleJVMCI flag cannot be avoided from macro expansion logic, 
>>>> i had to use some technique to exclude this flag from failure 
>>>> decision making.
>>>> Check_count/fail_count logic was added as a solution for this. i.e 
>>>> When EnableJVMCI is changed, code requires at-least 2 check 
>>>> failures to decide a real failure. otherwise one failure is 
>>>> sufficient.
>>>>
>>>> if i remove this logic, i will have to use strcmp(#FLAG, 
>>>> "EnableJVMCI") which will add a little more instructions that will  
>>>> execute at-least once for every flag consistent run.
>>>>
>>>> let me know if i need to take second approach. or if existing code 
>>>> is ok.
>>>>>
>>>>> +// Check if any jvmci global defaults changed.
>>>>> +bool is_any_jvmci_arg_values_changed();
>>>>> +// Print jvmci args inconsistency error message.
>>>>> +void print_jvmci_arg_inconsistency_error_message();
>>>>>
>>>>> These should be in some kind of namespace or class.  Maybe put 
>>>>> them into: class JVMCIGlobals
>>>> Ok.
>>>>
>>>> Best Regards,
>>>> Jamsheed
>>>>>
>>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>> Jamsheed
>>>>>>
>>>>>> On 2/16/2016 6:50 PM, Jamsheed C m wrote:
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> Revised webrev: 
>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/
>>>>>>>
>>>>>>> This code take care of every jvmci flags automatically.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Jamsheed
>>>>>>>
>>>>>>> On 2/13/2016 3:24 AM, Christian Thalinger wrote:
>>>>>>>>
>>>>>>>>> On Feb 12, 2016, at 7:12 AM, Jamsheed C m 
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>> On 2/12/2016 10:12 PM, Christian Thalinger wrote:
>>>>>>>>>> Well, now you have to manually check all flags that had 
>>>>>>>>>> a constraint directive.  That is the annoying part and what I 
>>>>>>>>>> complained about in:
>>>>>>>>> check against original value, and if not fail ?
>>>>>>>>
>>>>>>>> Same check for all flags; they all depend on +EnableJVMCI.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8145357
>>>>>>>>>>
>>>>>>>>>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now 
>>>>>>>>>> empty and I think we should remove them.
>>>>>>>>> i kept the file as there can be future use. Ok, i will remove it.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Jamsheed
>>>>>>>>>>
>>>>>>>>>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m 
>>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>
>>>>>>>>>>> revised webrev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Jamsheed
>>>>>>>>>>>
>>>>>>>>>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m 
>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Request for review
>>>>>>>>>>>>>
>>>>>>>>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333
>>>>>>>>>>>>> web url: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> That looks alright but we should remove the constraints 
>>>>>>>>>>>> from all the JVMCI command line flags because the way we 
>>>>>>>>>>>> use them is not supported.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, can you change the error message?  Right now it looks 
>>>>>>>>>>>> like this:
>>>>>>>>>>>>
>>>>>>>>>>>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java 
>>>>>>>>>>>> -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler
>>>>>>>>>>>> EnableJVMCI must be enabled
>>>>>>>>>>>> Improperly specified VM option 'UseJVMCICompiler'
>>>>>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>>>>>
>>>>>>>>>>>> I think with your changes we will only see the first line 
>>>>>>>>>>>> without mentioning UseJVMCICompiler.  Is that correct?
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Fix Summary: added jvmci flag consistency check after arg 
>>>>>>>>>>>>> parsing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> tests: jprt
>>>>>>>>>>>>> unit test: command line verification
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From aleksey.shipilev at oracle.com  Fri Feb 19 15:50:16 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 19 Feb 2016 18:50:16 +0300
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56C72874.2070606@gmail.com>
References: <56C702B6.5010903@oracle.com> <56C72118.6030304@gmail.com>
	<56C721BD.9010505@oracle.com> <56C72874.2070606@gmail.com>
Message-ID: <56C739B8.3020601@oracle.com>

On 02/19/2016 05:36 PM, Peter Levart wrote:
> Yes, I understand the general principle of @Stable design and the role
> of default value in @Stable fields. But given that:
> 
> But never mind. This is just me thinking loud.

Sure. The answer to those questions about @Stable is, as always: it
works like that; it was never supposed to do more than it does right
now; the time spent dealing with @Stable is better spent dealing with
generic problem of trusting final fields, without VM internal
annotations. @Stable paves the way in VM internals for that, but it does
not mean it should be catch-all feature.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From vladimir.kempik at oracle.com  Fri Feb 19 16:28:00 2016
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Fri, 19 Feb 2016 19:28:00 +0300
Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply
	intrinsic
In-Reply-To: <56C63207.6090308@oracle.com>
References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com>
	<56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com>
	<56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com>
	<56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com>
	<56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com>
	<56C5ADCF.60805@oracle.com> <56C5AED4.90601@redhat.com>
	<56C5B605.6060606@oracle.com> <56C628D6.5090902@oracle.com>
	<28D00379-E85F-4D57-B54A-7A6545459BE5@oracle.com>
	<56C63207.6090308@oracle.com>
Message-ID: <56C74290.7060007@oracle.com>

Hello

Here is updated webrev for 8130150 for jdk8.

only hotspot part was updated.

http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.01

Changes:
sharedRuntime_x86_64.cpp

a) use asm volatile instead of __asm__
b) don't use montgomery_square on Solaris.


Testing: jprt, included testcase.
THanks, Vladimir.

On 19.02.2016 0:05, Vladimir Kozlov wrote:
> Okay.
>
> On 2/18/16 12:38 PM, Vladimir Kempik wrote:
>> Hello
>>
>> To be clear.
>>
>> I'm proposing :
>> 1)if(0), only for Solaris (via ifdef Solaris )
>> 2)volatile asm.
>>
>> That is the combination that passes all jprt tests.
>>
>> I'll prepare updated webrev a bit later this week.
>> Vladimir.
>>
>> ?????????? ? iPad
>>
>>> 18 ????. 2016 ?., ? 23:25, Vladimir Kozlov 
>>>  ???????(?):
>>>
>>> To be clear. You are proposing only the next change nothing else we 
>>> discussed before. Right?
>>>
>>> -  if (len >= MONTGOMERY_SQUARING_THRESHOLD) {
>>> +  if (0) {
>>>     ::montgomery_square(a, n, m, (unsigned long)inv, longwords);
>>>
>>> What about 'volatile asm'? Using C code instead of asm?
>>>
>>> In general I am fine with that since it looks like it is only 
>>> performance issue.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>> On 2/18/16 4:16 AM, Vladimir Kempik wrote:
>>>> Hello
>>>>
>>>> Vladimir Kozlov, do you think I can backport this to jdk8/7 with 
>>>> mentioned workaround (for solaris amd64 only) and then
>>>> create a bug to investigate why montgomery_square fails with jdk8/7 
>>>> and solaris studio 12u1 compiler ?
>>>>
>>>> It passed the jprt tests now.
>>>>
>>>> If so It's ok I'll prepare.
>>>>
>>>> Thanks.
>>>>> On 18.02.2016 14:45, Andrew Haley wrote:
>>>>>> On 02/18/2016 11:41 AM, Vladimir Kempik wrote:
>>>>>> making this routine to always use montgomery_multiply helped to
>>>>>> workaround the issue
>>>>> OK, so possibly a bug in montgomery_square.  I'm not sure what
>>>>> "helped" means, though.  I guess it doesn't mean "fixes the bug".
>>>>>
>>>>> Andrew.
>>>>>
>>>>


From vladimir.kozlov at oracle.com  Fri Feb 19 16:39:55 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Feb 2016 08:39:55 -0800
Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply
	intrinsic
In-Reply-To: <56C74290.7060007@oracle.com>
References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com>
	<56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com>
	<56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com>
	<56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com>
	<56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com>
	<56C5ADCF.60805@oracle.com> <56C5AED4.90601@redhat.com>
	<56C5B605.6060606@oracle.com> <56C628D6.5090902@oracle.com>
	<28D00379-E85F-4D57-B54A-7A6545459BE5@oracle.com>
	<56C63207.6090308@oracle.com> <56C74290.7060007@oracle.com>
Message-ID: <56C7455B.9040201@oracle.com>

Looks good. I said it before that you need to backport 8139907 too to execute tests only on platforms which have 
intrinsic. Or use other ways to limit platforms on which execute the test.

Thanks,
Vladimir

On 2/19/16 8:28 AM, Vladimir Kempik wrote:
> Hello
>
> Here is updated webrev for 8130150 for jdk8.
>
> only hotspot part was updated.
>
> http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.01
>
> Changes:
> sharedRuntime_x86_64.cpp
>
> a) use asm volatile instead of __asm__
> b) don't use montgomery_square on Solaris.
>
>
> Testing: jprt, included testcase.
> THanks, Vladimir.
>
> On 19.02.2016 0:05, Vladimir Kozlov wrote:
>> Okay.
>>
>> On 2/18/16 12:38 PM, Vladimir Kempik wrote:
>>> Hello
>>>
>>> To be clear.
>>>
>>> I'm proposing :
>>> 1)if(0), only for Solaris (via ifdef Solaris )
>>> 2)volatile asm.
>>>
>>> That is the combination that passes all jprt tests.
>>>
>>> I'll prepare updated webrev a bit later this week.
>>> Vladimir.
>>>
>>> ?????????? ? iPad
>>>
>>>> 18 ????. 2016 ?., ? 23:25, Vladimir Kozlov  ???????(?):
>>>>
>>>> To be clear. You are proposing only the next change nothing else we discussed before. Right?
>>>>
>>>> -  if (len >= MONTGOMERY_SQUARING_THRESHOLD) {
>>>> +  if (0) {
>>>>     ::montgomery_square(a, n, m, (unsigned long)inv, longwords);
>>>>
>>>> What about 'volatile asm'? Using C code instead of asm?
>>>>
>>>> In general I am fine with that since it looks like it is only performance issue.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>>> On 2/18/16 4:16 AM, Vladimir Kempik wrote:
>>>>> Hello
>>>>>
>>>>> Vladimir Kozlov, do you think I can backport this to jdk8/7 with mentioned workaround (for solaris amd64 only) and
>>>>> then
>>>>> create a bug to investigate why montgomery_square fails with jdk8/7 and solaris studio 12u1 compiler ?
>>>>>
>>>>> It passed the jprt tests now.
>>>>>
>>>>> If so It's ok I'll prepare.
>>>>>
>>>>> Thanks.
>>>>>> On 18.02.2016 14:45, Andrew Haley wrote:
>>>>>>> On 02/18/2016 11:41 AM, Vladimir Kempik wrote:
>>>>>>> making this routine to always use montgomery_multiply helped to
>>>>>>> workaround the issue
>>>>>> OK, so possibly a bug in montgomery_square.  I'm not sure what
>>>>>> "helped" means, though.  I guess it doesn't mean "fixes the bug".
>>>>>>
>>>>>> Andrew.
>>>>>>
>>>>>
>

From vladimir.kempik at oracle.com  Fri Feb 19 16:56:15 2016
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Fri, 19 Feb 2016 19:56:15 +0300
Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply
	intrinsic
In-Reply-To: <56C7455B.9040201@oracle.com>
References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com>
	<56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com>
	<56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com>
	<56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com>
	<56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com>
	<56C5ADCF.60805@oracle.com> <56C5AED4.90601@redhat.com>
	<56C5B605.6060606@oracle.com> <56C628D6.5090902@oracle.com>
	<28D00379-E85F-4D57-B54A-7A6545459BE5@oracle.com>
	<56C63207.6090308@oracle.com> <56C74290.7060007@oracle.com>
	<56C7455B.9040201@oracle.com>
Message-ID: <56C7492F.6070005@oracle.com>

Hello

Will work on 8139907 next, but First I'll need to backport 
https://bugs.openjdk.java.net/browse/JDK-8130832 to jdk8 to make 8139907 
work.

Vladimir.

On 19.02.2016 19:39, Vladimir Kozlov wrote:
> Looks good. I said it before that you need to backport 8139907 too to 
> execute tests only on platforms which have intrinsic. Or use other 
> ways to limit platforms on which execute the test.
>
> Thanks,
> Vladimir
>
> On 2/19/16 8:28 AM, Vladimir Kempik wrote:
>> Hello
>>
>> Here is updated webrev for 8130150 for jdk8.
>>
>> only hotspot part was updated.
>>
>> http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.01
>>
>> Changes:
>> sharedRuntime_x86_64.cpp
>>
>> a) use asm volatile instead of __asm__
>> b) don't use montgomery_square on Solaris.
>>
>>
>> Testing: jprt, included testcase.
>> THanks, Vladimir.
>>
>> On 19.02.2016 0:05, Vladimir Kozlov wrote:
>>> Okay.
>>>
>>> On 2/18/16 12:38 PM, Vladimir Kempik wrote:
>>>> Hello
>>>>
>>>> To be clear.
>>>>
>>>> I'm proposing :
>>>> 1)if(0), only for Solaris (via ifdef Solaris )
>>>> 2)volatile asm.
>>>>
>>>> That is the combination that passes all jprt tests.
>>>>
>>>> I'll prepare updated webrev a bit later this week.
>>>> Vladimir.
>>>>
>>>> ?????????? ? iPad
>>>>
>>>>> 18 ????. 2016 ?., ? 23:25, Vladimir Kozlov 
>>>>>  ???????(?):
>>>>>
>>>>> To be clear. You are proposing only the next change nothing else 
>>>>> we discussed before. Right?
>>>>>
>>>>> -  if (len >= MONTGOMERY_SQUARING_THRESHOLD) {
>>>>> +  if (0) {
>>>>>     ::montgomery_square(a, n, m, (unsigned long)inv, longwords);
>>>>>
>>>>> What about 'volatile asm'? Using C code instead of asm?
>>>>>
>>>>> In general I am fine with that since it looks like it is only 
>>>>> performance issue.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>>> On 2/18/16 4:16 AM, Vladimir Kempik wrote:
>>>>>> Hello
>>>>>>
>>>>>> Vladimir Kozlov, do you think I can backport this to jdk8/7 with 
>>>>>> mentioned workaround (for solaris amd64 only) and
>>>>>> then
>>>>>> create a bug to investigate why montgomery_square fails with 
>>>>>> jdk8/7 and solaris studio 12u1 compiler ?
>>>>>>
>>>>>> It passed the jprt tests now.
>>>>>>
>>>>>> If so It's ok I'll prepare.
>>>>>>
>>>>>> Thanks.
>>>>>>> On 18.02.2016 14:45, Andrew Haley wrote:
>>>>>>>> On 02/18/2016 11:41 AM, Vladimir Kempik wrote:
>>>>>>>> making this routine to always use montgomery_multiply helped to
>>>>>>>> workaround the issue
>>>>>>> OK, so possibly a bug in montgomery_square.  I'm not sure what
>>>>>>> "helped" means, though.  I guess it doesn't mean "fixes the bug".
>>>>>>>
>>>>>>> Andrew.
>>>>>>>
>>>>>>
>>


From pavel.punegov at oracle.com  Fri Feb 19 17:04:29 2016
From: pavel.punegov at oracle.com (Pavel Punegov)
Date: Fri, 19 Feb 2016 20:04:29 +0300
Subject: RFR (S): 8148563:
	compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java timesout
Message-ID: <47423DF0-C7C7-4053-BEC0-1D12A558E982@oracle.com>

Hi,

please review the fix for a test bug.

Issue: 
1. Test timeouts because it executes a lot of jcmd processes. Number of threads is calculated as number of processors (cores) * 10, that led to an enormous number of jcmds executed on hosts with lots of CPUs/cores. 
2. Test also spends a lot of time to generate 5 huge directive files, that were tried to be added on to the directives stack. Directive stack has a limit (default 50, controlled by  CompilerDirectivesLimit).

Fix: 
1. Calculate number of threads as a log of the number of CPUs/cores * 10.
2. Generate only one file that is less than specified CompilerDirectivesLimit. 
3. Add different commands to execute (add, clear, remove and print) and generate them on demand.

webrev: http://cr.openjdk.java.net/~ppunegov/8148563/webrev.00/ 
bug: https://bugs.openjdk.java.net/browse/JDK-8148563 

? Pavel.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From christian.thalinger at oracle.com  Fri Feb 19 17:26:02 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Feb 2016 07:26:02 -1000
Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler
	-XX:-EnableJVMCI makes JVM crash
In-Reply-To: <56C736DA.304@oracle.com>
References: <56BC90DC.10004@oracle.com>
	
	<56BD8DF9.1070605@oracle.com>
	
	<56BE1274.4020506@oracle.com>
	<41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com>
	<56C3221D.2040507@oracle.com> <56C48936.4090303@oracle.com>
	
	<56C5163D.7010208@oracle.com> <56C5F0CA.5010307@oracle.com>
	
	<56C6A6DE.9060806@oracle.com> <56C736DA.304@oracle.com>
Message-ID: 

Looks good.  Thanks.

> On Feb 19, 2016, at 5:38 AM, Jamsheed C m  wrote:
> 
> Hi Chris,
> 
> Made all suggested changes.
> 
> Revised webrev: http://cr.openjdk.java.net/~jcm/8145333/webrev.05/ 
> 
> Thanks and Best Regards,
> Jamsheed
> 
> On 2/19/2016 10:53 AM, Jamsheed C m wrote:
>> 
>> 
>> On 2/18/2016 11:21 PM, Christian Thalinger wrote:
>>> +  if (EnableJVMCI)
>>> +    return true;
>>> 
>>> Please use { } for all if statements.
>> Ok.
>>> 
>>> Thanks for the comments; it?s easier to understand now.  May I suggest to do:
>>> 
>>>   int skip_fail_count;  
>>>   if (!FLAG_IS_DEFAULT(EnableJVMCI)) {
>>>     skip_fail_count = 1;
>>>   } else {
>>>     skip_fail_count = 0;  
>>>   }
>> Ok. 
>> 
>> Best Regards,
>> Jamsheed
>>> 
>>>> On Feb 18, 2016, at 6:26 AM, Jamsheed C m > wrote:
>>>> 
>>>> Hi Chris,
>>>> 
>>>> Made all suggested changes.
>>>> 
>>>> Revised webrev: http://cr.openjdk.java.net/~thartmann/8145333/webrev.04/ 
>>>> 
>>>> Best Regards,
>>>> Jamsheed
>>>> 
>>>> On 2/18/2016 6:24 AM, Jamsheed C m wrote:
>>>>> 
>>>>> 
>>>>> On 2/18/2016 12:36 AM, Christian Thalinger wrote:
>>>>>> 
>>>>>>> On Feb 17, 2016, at 4:52 AM, Jamsheed C m > wrote:
>>>>>>> 
>>>>>>> experimental and diagnostic flags are under condition checks now.
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.03/ 
>>>>>> 
>>>>>> I?m not very happy about the new macros but I can see why it?s useful.
>>>>>> 
>>>>>> +#if INCLUDE_JVMCI
>>>>>> +
>>>>>> +// Check consistency of jvmci vm argument settings.
>>>>>> +bool Arguments::check_jvmci_args_consistency() {
>>>>>> + 
>>>>>> +
>>>>>> +  if (!EnableJVMCI && is_any_jvmci_arg_values_changed()) { 
>>>>>> +    print_jvmci_arg_inconsistency_error_message(); 
>>>>>> +    return false;
>>>>>> 
>>>>>> Please remove all these empty lines.  There are others as well.
>>>>>> 
>>>>>> +bool is_any_jvmci_arg_values_changed() {  
>>>>>> 
>>>>>> This method needs another name.
>>>>>> 
>>>>> Ok.
>>>>>> +  int check_count = 0, fail_count = 0;
>>>>>> 
>>>>>> I don?t like the check_count/fail_count logic because it?s fragile.
>>>>> As  EanbleJVMCI flag cannot be avoided from macro expansion logic, i had to use some technique to exclude this flag from failure decision making. 
>>>>> Check_count/fail_count logic was added as a solution for this. i.e When EnableJVMCI is changed, code requires at-least 2 check failures to decide a real failure. otherwise one failure is sufficient. 
>>>>>  
>>>>> if i remove this logic, i will have to use strcmp(#FLAG, "EnableJVMCI") which will add a little more instructions that will  execute at-least once for every flag consistent run.
>>>>> 
>>>>> let me know if i need to take second approach. or if existing code is ok.
>>>>>> 
>>>>>> +// Check if any jvmci global defaults changed.
>>>>>> +bool is_any_jvmci_arg_values_changed();
>>>>>> +// Print jvmci args inconsistency error message.
>>>>>> +void print_jvmci_arg_inconsistency_error_message();
>>>>>> 
>>>>>> These should be in some kind of namespace or class.  Maybe put them into: class JVMCIGlobals
>>>>> Ok.
>>>>> 
>>>>> Best Regards,
>>>>> Jamsheed
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> Jamsheed
>>>>>>> 
>>>>>>> On 2/16/2016 6:50 PM, Jamsheed C m wrote:
>>>>>>>> Hi Chris,
>>>>>>>> 
>>>>>>>> Revised webrev:  http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/ 
>>>>>>>> 
>>>>>>>> This code take care of every jvmci flags automatically.
>>>>>>>> 
>>>>>>>> Best Regards,
>>>>>>>> Jamsheed
>>>>>>>> 
>>>>>>>> On 2/13/2016 3:24 AM, Christian Thalinger wrote:
>>>>>>>>> 
>>>>>>>>>> On Feb 12, 2016, at 7:12 AM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Hi Chris,
>>>>>>>>>> 
>>>>>>>>>> On 2/12/2016 10:12 PM, Christian Thalinger wrote:
>>>>>>>>>>> Well, now you have to manually check all flags that had a constraint directive.  That is the annoying part and what I complained about in:
>>>>>>>>>> check against original value, and if not fail ?
>>>>>>>>> 
>>>>>>>>> Same check for all flags; they all depend on +EnableJVMCI.
>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>  https://bugs.openjdk.java.net/browse/JDK-8145357 
>>>>>>>>>>> 
>>>>>>>>>>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now empty and I think we should remove them.
>>>>>>>>>> i kept the file as there can be future use. Ok, i will remove it.
>>>>>>>>>> 
>>>>>>>>>> Best Regards,
>>>>>>>>>> Jamsheed
>>>>>>>>>>> 
>>>>>>>>>>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>> 
>>>>>>>>>>>> revised webrev:  http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/ 
>>>>>>>>>>>> 
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>> 
>>>>>>>>>>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Request for review
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> bug url:   https://bugs.openjdk.java.net/browse/JDK-8145333 
>>>>>>>>>>>>>> web url:  http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> That looks alright but we should remove the constraints from all the JVMCI command line flags because the way we use them is not supported.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Also, can you change the error message?  Right now it looks like this:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler
>>>>>>>>>>>>> EnableJVMCI must be enabled
>>>>>>>>>>>>> Improperly specified VM option 'UseJVMCICompiler'
>>>>>>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I think with your changes we will only see the first line without mentioning UseJVMCICompiler.  Is that correct?
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Fix Summary: added jvmci flag consistency check after arg parsing.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> tests: jprt
>>>>>>>>>>>>>> unit test: command line verification
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From christian.thalinger at oracle.com  Fri Feb 19 17:27:53 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Feb 2016 07:27:53 -1000
Subject: [9] RFR JDK-8141618: Change JVMCI compilerToVM constant pool
	tests to support CP caching
In-Reply-To: <56C72639.7070905@oracle.com>
References: <56C47C58.9090104@oracle.com>
	<68AEB7F8-14A8-4BC5-B910-501E2980F646@oracle.com>
	<56C5A03D.9040602@oracle.com>
	<827C7189-9979-4174-9E0F-549F848B37CA@oracle.com>
	<56C72639.7070905@oracle.com>
Message-ID: 

Much better.  Looks good.

> On Feb 19, 2016, at 4:27 AM, Konstantin Shefov  wrote:
> 
> Chris,
> 
> I have added some imports to get rid of long names.
> http://cr.openjdk.java.net/~kshefov/8141618/webrev.02/
> 
> -Konstantin
> 
> On 02/18/2016 09:52 PM, Christian Thalinger wrote:
>> It?s difficult to follow the logic and make sure there is no bug.  I did not verify all this.  Looks good anyway.
>> 
>>> On Feb 18, 2016, at 12:43 AM, Konstantin Shefov  wrote:
>>> 
>>> Christian, thanks for looking into this
>>> 
>>> I have reformatted the code to make it look better:
>>> http://cr.openjdk.java.net/~kshefov/8141618/webrev.01
>>> 
>>> -Konstantin
>>> 
>>> On 02/17/2016 09:43 PM, Christian Thalinger wrote:
>>>> Why do you have to break every line at, what, 50 characters?  This is unreadable:
>>>> 
>>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.CLASS,
>>>> +                ConstantTypes.CONSTANT_CLASS);
>>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.FIELDREF,
>>>> +                ConstantTypes.CONSTANT_FIELDREF);
>>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.METHODREF,
>>>> +                ConstantTypes.CONSTANT_METHODREF);
>>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.INTERFACEMETHODREF,
>>>> +                ConstantTypes.CONSTANT_INTERFACEMETHODREF);
>>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.STRING,
>>>> +                ConstantTypes.CONSTANT_STRING);
>>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.INTEGER,
>>>> +                ConstantTypes.CONSTANT_INTEGER);
>>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.FLOAT,
>>>> +                ConstantTypes.CONSTANT_FLOAT);
>>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.LONG,
>>>> +                ConstantTypes.CONSTANT_LONG);
>>>> +        TAG_TO_TYPE_MAP.put(ConstantPool.Tag.DOUBLE,
>>>> 
>>>> And this is not the only occurrence.  I can?t review this.
>>>> 
>>>>> On Feb 17, 2016, at 3:57 AM, Konstantin Shefov  wrote:
>>>>> 
>>>>> Hello
>>>>> 
>>>>> Please review a test enhancement.
>>>>> It is an improvement for JVMCI CompilerToVM class tests.
>>>>> 
>>>>> See https://bugs.openjdk.java.net/browse/JDK-8138708 for more info.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141618
>>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8141618/webrev.00/
>>>>> 
>>>>> Thanks
>>>>> -Konstantin
> 


From vladimir.kozlov at oracle.com  Fri Feb 19 17:41:07 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Feb 2016 09:41:07 -0800
Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply
	intrinsic
In-Reply-To: <56C7492F.6070005@oracle.com>
References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com>
	<56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com>
	<56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com>
	<56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com>
	<56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com>
	<56C5ADCF.60805@oracle.com> <56C5AED4.90601@redhat.com>
	<56C5B605.6060606@oracle.com> <56C628D6.5090902@oracle.com>
	<28D00379-E85F-4D57-B54A-7A6545459BE5@oracle.com>
	<56C63207.6090308@oracle.com> <56C74290.7060007@oracle.com>
	<56C7455B.9040201@oracle.com> <56C7492F.6070005@oracle.com>
Message-ID: <56C753B3.5040702@oracle.com>

Okay. Can you add for now @requires (os.simpleArch == "x64") & (os.family != "windows")? To limit test for x64 (64 bit) 
and not windows.

Thanks,
Vladimir

On 2/19/16 8:56 AM, Vladimir Kempik wrote:
> Hello
>
> Will work on 8139907 next, but First I'll need to backport https://bugs.openjdk.java.net/browse/JDK-8130832 to jdk8 to
> make 8139907 work.
>
> Vladimir.
>
> On 19.02.2016 19:39, Vladimir Kozlov wrote:
>> Looks good. I said it before that you need to backport 8139907 too to execute tests only on platforms which have
>> intrinsic. Or use other ways to limit platforms on which execute the test.
>>
>> Thanks,
>> Vladimir
>>
>> On 2/19/16 8:28 AM, Vladimir Kempik wrote:
>>> Hello
>>>
>>> Here is updated webrev for 8130150 for jdk8.
>>>
>>> only hotspot part was updated.
>>>
>>> http://cr.openjdk.java.net/~vkempik/8130150/webrev_hs.01
>>>
>>> Changes:
>>> sharedRuntime_x86_64.cpp
>>>
>>> a) use asm volatile instead of __asm__
>>> b) don't use montgomery_square on Solaris.
>>>
>>>
>>> Testing: jprt, included testcase.
>>> THanks, Vladimir.
>>>
>>> On 19.02.2016 0:05, Vladimir Kozlov wrote:
>>>> Okay.
>>>>
>>>> On 2/18/16 12:38 PM, Vladimir Kempik wrote:
>>>>> Hello
>>>>>
>>>>> To be clear.
>>>>>
>>>>> I'm proposing :
>>>>> 1)if(0), only for Solaris (via ifdef Solaris )
>>>>> 2)volatile asm.
>>>>>
>>>>> That is the combination that passes all jprt tests.
>>>>>
>>>>> I'll prepare updated webrev a bit later this week.
>>>>> Vladimir.
>>>>>
>>>>> ?????????? ? iPad
>>>>>
>>>>>> 18 ????. 2016 ?., ? 23:25, Vladimir Kozlov  ???????(?):
>>>>>>
>>>>>> To be clear. You are proposing only the next change nothing else we discussed before. Right?
>>>>>>
>>>>>> -  if (len >= MONTGOMERY_SQUARING_THRESHOLD) {
>>>>>> +  if (0) {
>>>>>>     ::montgomery_square(a, n, m, (unsigned long)inv, longwords);
>>>>>>
>>>>>> What about 'volatile asm'? Using C code instead of asm?
>>>>>>
>>>>>> In general I am fine with that since it looks like it is only performance issue.
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>>> On 2/18/16 4:16 AM, Vladimir Kempik wrote:
>>>>>>> Hello
>>>>>>>
>>>>>>> Vladimir Kozlov, do you think I can backport this to jdk8/7 with mentioned workaround (for solaris amd64 only) and
>>>>>>> then
>>>>>>> create a bug to investigate why montgomery_square fails with jdk8/7 and solaris studio 12u1 compiler ?
>>>>>>>
>>>>>>> It passed the jprt tests now.
>>>>>>>
>>>>>>> If so It's ok I'll prepare.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>> On 18.02.2016 14:45, Andrew Haley wrote:
>>>>>>>>> On 02/18/2016 11:41 AM, Vladimir Kempik wrote:
>>>>>>>>> making this routine to always use montgomery_multiply helped to
>>>>>>>>> workaround the issue
>>>>>>>> OK, so possibly a bug in montgomery_square.  I'm not sure what
>>>>>>>> "helped" means, though.  I guess it doesn't mean "fixes the bug".
>>>>>>>>
>>>>>>>> Andrew.
>>>>>>>>
>>>>>>>
>>>
>

From konstantin.shefov at oracle.com  Fri Feb 19 17:44:26 2016
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 19 Feb 2016 20:44:26 +0300
Subject: [9] RFR JDK-8141619: Develop new tests for JVMCI compilerToVM
	class' CP related methods
In-Reply-To: <56C7265C.3070108@oracle.com>
References: <56C47D09.4030006@oracle.com>
	
	<56C5A08B.50001@oracle.com>
	<7663E05E-544E-4FFB-8E7F-A329143B64A5@oracle.com>
	<56C7265C.3070108@oracle.com>
Message-ID: <56C7547A.5030600@oracle.com>

Chris,
Please, look also at this code.
http://cr.openjdk.java.net/~kshefov/8141619/webrev.02/

Thanks
-Konstantin

On 02/19/2016 05:27 PM, Konstantin Shefov wrote:
> Chris,
>
> I have added some imports to get rid of long names.
> http://cr.openjdk.java.net/~kshefov/8141619/webrev.02/
>
> -Konstantin
>
> On 02/18/2016 09:56 PM, Christian Thalinger wrote:
>>   57 typeTests.put(ConstantPoolTestCase.ConstantTypes.CONSTANT_METHODREF,
>>   58 LookupNameAndTypeRefIndexInPoolTest::validate);
>>
>> You should use static imports so you can get rid 
>> of ConstantPoolTestCase.ConstantTypes.  Actually, the same would be 
>> useful in your other review too.
>>
>>> On Feb 18, 2016, at 12:44 AM, Konstantin Shefov 
>>> > 
>>> wrote:
>>>
>>> According to Christian's comments to RFR JDK-8141618 I have 
>>> reformatted the code to make it look better:
>>> http://cr.openjdk.java.net/~kshefov/8141619/webrev.01/
>>>
>>> -Konstantin
>>>
>>> On 02/17/2016 09:46 PM, Christian Thalinger wrote:
>>>>
>>>>> On Feb 17, 2016, at 4:00 AM, Konstantin Shefov 
>>>>>  wrote:
>>>>>
>>>>> Hello
>>>>>
>>>>> Please review new tests for methods of JVMCI 
>>>>> jdk.vm.ci.hotspot.CompilerToVM class.
>>>>>
>>>>> See https://bugs.openjdk.java.net/browse/JDK-8138708 for more info.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141619
>>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8141619/webrev.00/ 
>>>>> 
>>>>
>>>> Link is wrong: http://cr.openjdk.java.net/~kshefov/8141619/webrev/ 
>>>> 
>>>>
>>>>>
>>>>> Thanks
>>>>> -Konstantin
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vladimir.kempik at oracle.com  Fri Feb 19 17:46:29 2016
From: vladimir.kempik at oracle.com (Vladimir Kempik)
Date: Fri, 19 Feb 2016 20:46:29 +0300
Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply
	intrinsic
In-Reply-To: <56C753B3.5040702@oracle.com>
References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com>
	<56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com>
	<56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com>
	<56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com>
	<56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com>
	<56C5ADCF.60805@oracle.com> <56C5AED4.90601@redhat.com>
	<56C5B605.6060606@oracle.com> <56C628D6.5090902@oracle.com>
	<28D00379-E85F-4D57-B54A-7A6545459BE5@oracle.com>
	<56C63207.6090308@oracle.com> <56C74290.7060007@oracle.com>
	<56C7455B.9040201@oracle.com> <56C7492F.6070005@oracle.com>
	<56C753B3.5040702@oracle.com>
Message-ID: <56C754F5.3020807@oracle.com>

Ok, I have added it to testcase, I guess reuploading webrev isn't necessary.

On 19.02.2016 20:41, Vladimir Kozlov wrote:
> @requires (os.simpleArch == "x64") & (os.family != "windows")


From vladimir.kozlov at oracle.com  Fri Feb 19 17:51:17 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Feb 2016 09:51:17 -0800
Subject: [8u] RFR 8130150: Implement BigInteger.montgomeryMultiply
	intrinsic
In-Reply-To: <56C754F5.3020807@oracle.com>
References: <56BE24A5.2060203@oracle.com> <56BE7A46.5060104@oracle.com>
	<56C1CD50.3010100@oracle.com> <56C23270.9040308@oracle.com>
	<56C47264.3010103@oracle.com> <56C47327.3060708@redhat.com>
	<56C47425.3020404@oracle.com> <56C474EB.8070908@redhat.com>
	<56C4B9B7.80800@oracle.com> <56C4BCF2.9050302@redhat.com>
	<56C5ADCF.60805@oracle.com> <56C5AED4.90601@redhat.com>
	<56C5B605.6060606@oracle.com> <56C628D6.5090902@oracle.com>
	<28D00379-E85F-4D57-B54A-7A6545459BE5@oracle.com>
	<56C63207.6090308@oracle.com> <56C74290.7060007@oracle.com>
	<56C7455B.9040201@oracle.com> <56C7492F.6070005@oracle.com>
	<56C753B3.5040702@oracle.com> <56C754F5.3020807@oracle.com>
Message-ID: <56C75615.4030707@oracle.com>

Thanks!

On 2/19/16 9:46 AM, Vladimir Kempik wrote:
> Ok, I have added it to testcase, I guess reuploading webrev isn't necessary.
>
> On 19.02.2016 20:41, Vladimir Kozlov wrote:
>> @requires (os.simpleArch == "x64") & (os.family != "windows")
>

From christian.thalinger at oracle.com  Fri Feb 19 17:52:23 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Feb 2016 07:52:23 -1000
Subject: [9] RFR JDK-8141619: Develop new tests for JVMCI compilerToVM
	class' CP related methods
In-Reply-To: <56C7547A.5030600@oracle.com>
References: <56C47D09.4030006@oracle.com>
	
	<56C5A08B.50001@oracle.com>
	<7663E05E-544E-4FFB-8E7F-A329143B64A5@oracle.com>
	<56C7265C.3070108@oracle.com> <56C7547A.5030600@oracle.com>
Message-ID: 

Looks good.

> On Feb 19, 2016, at 7:44 AM, Konstantin Shefov  wrote:
> 
> Chris,
> Please, look also at this code.
> http://cr.openjdk.java.net/~kshefov/8141619/webrev.02/ 
> 
> Thanks
> -Konstantin
> 
> On 02/19/2016 05:27 PM, Konstantin Shefov wrote:
>> Chris,
>> 
>> I have added some imports to get rid of long names.
>> http://cr.openjdk.java.net/~kshefov/8141619/webrev.02/ 
>> 
>> -Konstantin
>> 
>> On 02/18/2016 09:56 PM, Christian Thalinger wrote:
>>>   57         typeTests.put(ConstantPoolTestCase.ConstantTypes.CONSTANT_METHODREF,
>>>   58                       LookupNameAndTypeRefIndexInPoolTest::validate);
>>> 
>>> You should use static imports so you can get rid of ConstantPoolTestCase.ConstantTypes.  Actually, the same would be useful in your other review too.
>>> 
>>>> On Feb 18, 2016, at 12:44 AM, Konstantin Shefov > wrote:
>>>> 
>>>> According to Christian's comments to RFR JDK-8141618 I have reformatted the code to make it look better:
>>>> http://cr.openjdk.java.net/~kshefov/8141619/webrev.01/ 
>>>> 
>>>> -Konstantin
>>>> 
>>>> On 02/17/2016 09:46 PM, Christian Thalinger wrote:
>>>>> 
>>>>>> On Feb 17, 2016, at 4:00 AM, Konstantin Shefov < konstantin.shefov at oracle.com > wrote:
>>>>>> 
>>>>>> Hello
>>>>>> 
>>>>>> Please review new tests for methods of JVMCI jdk.vm.ci.hotspot.CompilerToVM class.
>>>>>> 
>>>>>> See https://bugs.openjdk.java.net/browse/JDK-8138708  for more info.
>>>>>> 
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141619 
>>>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8141619/webrev.00/ 
>>>>> 
>>>>> Link is wrong: http://cr.openjdk.java.net/~kshefov/8141619/webrev/ 
>>>>> 
>>>>>> 
>>>>>> Thanks
>>>>>> -Konstantin
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From christian.thalinger at oracle.com  Fri Feb 19 17:57:07 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Feb 2016 07:57:07 -1000
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56C72118.6030304@gmail.com>
References: <56C702B6.5010903@oracle.com> <56C72118.6030304@gmail.com>
Message-ID: <7AB17C7E-B33A-4EA4-A04F-C77E8E0EA21B@oracle.com>


> On Feb 19, 2016, at 4:05 AM, Peter Levart  wrote:
> 
> Hi,
> 
> Just a stupid question.
> 
> Your comment in String:
> 
> 140      * @implNote Note this field is not {@link Stable}, because we want
> 141      * LATIN1 (0) coder to fold too. {@link Stable} would not allow that,
> 142      * as it reserves the default value as "not initialized" value.
> 143      * Constant-folding this field is handled internally in VM.
> 144      */
> 145     private final byte coder;

Why don?t you change the values to:

    static final byte LATIN1 = 1;
    static final byte UTF16  = 2;

?

> 
> 
> Couldn't @Stable final instance fields constant-fold the default value too in general? I mean can't it be assumed that the final field has been set before JIT kicks in?
> 
> Regards, Peter
> 
> On 02/19/2016 12:55 PM, Aleksey Shipilev wrote:
>> Hi,
>> 
>> Please review a simple performance improvement in Strings:
>>   https://bugs.openjdk.java.net/browse/JDK-8150180
>> 
>> In short, we want VM to trust constant String contents, so that
>> "Foo".charAt(0) is folded. As far as current Hotspot goes, this is only
>> achievable with @Stable -- we need to trust the array contents:
>>   http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/
>> 
>> This, however, steps into the compiler bug caused by StringUTF16.getChar
>> intrinsic producing a mismatched load, that is then folded incorrectly.
>> So we instead rely on Java level folding in cases like these:
>>   http://cr.openjdk.java.net/~shade/8150180/webrev.hs.01/
>> 
>> ...and it works:
>>   http://cr.openjdk.java.net/~shade/8150180/notes.txt
>> 
>> While VM change looks like a workaround, Vladimir I. and me concluded
>> that @Stable folding code should just reject folding mismatched loads to
>> begin with. So, getChar intrinsic change is the actual fix. Vladimir I.
>> ought to add more assertions in @Stable folding code separately:
>>   https://bugs.openjdk.java.net/browse/JDK-8150186
>> 
>> Since this issue might trigger compiler bugs, I would like to push
>> through hs-comp to pass compiler nightlies.
>> 
>> Cheers,
>> -Aleksey
>> 
> 


From vladimir.x.ivanov at oracle.com  Fri Feb 19 18:34:19 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 19 Feb 2016 21:34:19 +0300
Subject: [9] RFR (M): 8143407: C1: @Stable array support
Message-ID: <56C7602B.3090300@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8143407/webrev.01
https://bugs.openjdk.java.net/browse/JDK-8143407

Add C1 support for constant folding loads from @Stable arrays.
It aligns C1 & C2 behavior w.r.t. @Stable fields and was requested for 
VarHandles [1] implementation.

I introduced StableArrayConstant to track stable array dimension.

It is needed to disambiguate the following cases:
  (1) @Stable int[][][] intArr = new int[...][...][...];
  (2) @Stable  Object[] objArr = new int[...][...][...];

In the first case, all elements of multi-dimensional array w/ 
non-default values are considered constant.

In the latter, only elements of objArray (which are int[][] instances).

Testing: unit tests on @Stable support, JPRT.

Thanks!

Best regards,
Vladimir Ivanov

[1] http://openjdk.java.net/jeps/193

From john.r.rose at oracle.com  Fri Feb 19 19:03:53 2016
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 19 Feb 2016 11:03:53 -0800
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <7AB17C7E-B33A-4EA4-A04F-C77E8E0EA21B@oracle.com>
References: <56C702B6.5010903@oracle.com> <56C72118.6030304@gmail.com>
	<7AB17C7E-B33A-4EA4-A04F-C77E8E0EA21B@oracle.com>
Message-ID: 

On Feb 19, 2016, at 9:57 AM, Christian Thalinger  wrote:
> 
> Why don?t you change the values to:
> 
>    static final byte LATIN1 = 1;
>    static final byte UTF16  = 2;


Not sure what you are asking, but here's my take on why 0,1 is the (slight) winner.
The values 0,1 are the log2 of the array element sizes 1,2, so they can be used with shift instructions.
With 1,2 they would have to be used with multiply instructions, or else tweaked back to shift inputs.
Most loops will speculate on the scale factor, but those loops which must work with a non-constant scale will be slightly cleaner with 0,1.

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vladimir.kozlov at oracle.com  Fri Feb 19 20:45:46 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Feb 2016 12:45:46 -0800
Subject: RFR (S): 8148563:
	compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java timesout
In-Reply-To: <47423DF0-C7C7-4053-BEC0-1D12A558E982@oracle.com>
References: <47423DF0-C7C7-4053-BEC0-1D12A558E982@oracle.com>
Message-ID: <56C77EFA.1060702@oracle.com>

Seems fine. What size of directive files was before and after this fix? 
JBS does not have this information.

Thanks,
Vladimir

On 2/19/16 9:04 AM, Pavel Punegov wrote:
> Hi,
>
> please review the fix for a test bug.
>
> Issue:
> 1. Test timeouts because it executes a lot of jcmd processes. Number of
> threads is calculated as number of processors (cores) * 10, that led to
> an enormous number of jcmds executed on hosts with lots of CPUs/cores.
> 2. Test also spends a lot of time to generate 5 huge directive files,
> that were tried to be added on to the directives stack. Directive stack
> has a limit (default 50, controlled by  CompilerDirectivesLimit).
>
> Fix:
> 1. Calculate number of threads as a log of the number of CPUs/cores * 10.
> 2. Generate only one file that is less than specified
> CompilerDirectivesLimit.
> 3. Add different commands to execute (add, clear, remove and print) and
> generate them on demand.
>
> webrev: http://cr.openjdk.java.net/~ppunegov/8148563/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8148563
>
> ? Pavel.
>

From vladimir.kozlov at oracle.com  Fri Feb 19 21:06:15 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Feb 2016 13:06:15 -0800
Subject: RFR(L) 8149655: PPC64: Implement CompactString intrinsics
In-Reply-To: <898cbee841884ef7b4f3ad9e3681e282@DEWDFE13DE09.global.corp.sap>
References: 
	<6d2ee7af0e2947abb989fa84369f4f0f@DEWDFE13DE09.global.corp.sap>
	<717d9d731f294a8eb3ba6be83e7e4c05@DEWDFE13DE13.global.corp.sap>
	<898cbee841884ef7b4f3ad9e3681e282@DEWDFE13DE09.global.corp.sap>
Message-ID: <56C783C7.70201@oracle.com>

Job is submitted to JPRT.

Thanks,
Vladimir

On 2/19/16 5:14 AM, Lindenmaier, Goetz wrote:
> Hi Martin,
>
> looks good now. Could someone please sponsor?
>
> Thanks for the fixes,
>
>    Goetz.
>
> *From:*Doerr, Martin
> *Sent:* Friday, February 19, 2016 11:38 AM
> *To:* Lindenmaier, Goetz ;
> hotspot-compiler-dev at openjdk.java.net
> *Subject:* RE: RFR(L) 8149655: PPC64: Implement CompactString intrinsics
>
> Hi G?tz,
>
> thanks for the review. I basically used small micro-benchmarks and tests
> and later our nightly tests which I have extended a little bit with this
> change. There were some match rules which I only hit with the change I
> made in TestStringIntrinsics2.
>
> I think you?re right. The addition to the predicate for
> string_indexOf_imm1_charNodeshould not be needed because the AddP node
> for the immediate needle gets matched with the StrIndexOfNode.
>
> I have removed it again from this node and from the new nodes which
> match indexOf_imm1_char in the 3 different flavors.
>
> Spaces before comma are also fixed.
>
> The guarantee(needlecntval != 1, ?) is not new. It was already there in
> the non-CompactStrings version. string_indexof wouldn?t generate correct
> code. There?s a separate match rule for that case.
>
> New webrev is here:
>
> http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.01/
>
> Best regards,
>
> Martin
>
> *From:*Lindenmaier, Goetz
> *Sent:* Donnerstag, 18. Februar 2016 20:50
> *To:* Doerr, Martin  >; hotspot-compiler-dev at openjdk.java.net
> 
> *Subject:* RE: RFR(L) 8149655: PPC64: Implement CompactString intrinsics
>
> Hi Martin,
>
> I finally had a look at this change.  Good work!
>
> What did you test this with,  besides our hs-comp nighttests, which
>
> already is quite a lot?
>
> ppc.ad:
>
> I saw you added more conditions to the predicate of
> string_indexOf_imm1_char() etc.
>
> Isn?t this obvious because needleImm is an immP?
>
> macroassmbler_ppc.cpp:
>
> if (stride1 == 1) { lbz(chr1, 0, str1); } else { lhz(chr1, 0 ,str1); }
>
> Space before comma.  There are more of these, search for ?0 ,?
>
> guarantee(needlecntval != 1,
>
> not indented ? or is this on purpose?
>
> Best regards,
>
>    Goetz.
>
> *From:*hotspot-compiler-dev
> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] *On Behalf Of
> *Doerr, Martin
> *Sent:* Thursday, February 11, 2016 4:11 PM
> *To:* hotspot-compiler-dev at openjdk.java.net
> 
> *Subject:* RFR(L) 8149655: PPC64: Implement CompactString intrinsics
>
> Hi,
>
> I have created a webrev which adds the following String intrinsics to PPC64:
>
> 0 string_compareL
>
> 1 string_compareU
>
> 2 string_compareLU
>
> 3 string_compareUL
>
> 4 string_equalsL
>
> 5 string_equalsU
>
> 6 array_equalsB
>
> 7 array_equalsC
>
> 8 indexOf_imm1_char_U
>
> 9 indexOf_imm1_char_L
>
> 10 indexOf_imm1_char_UL
>
> 11 indexOf_imm1_U
>
> 12 indexOf_imm1_L
>
> 13 indexOf_imm1_UL
>
> 14 indexOfChar_U
>
> 15 indexOf_imm_U
>
> 16 indexOf_imm_L
>
> 17 indexOf_imm_UL
>
> 18 indexOf_U
>
> 19 indexOf_L
>
> 20 indexOf_UL
>
> 21 string_compress
>
> 22 string_inflate
>
> 23 has_negatives
>
> 24 encode_iso_array
>
> It also contains some other minor improvements.
>
> The webrev is here:
>
> http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.00/
>
> Please review.
>
> I will also need a sponsor from Oracle because the change touches one
> java test file (test/compiler/intrinsics/string/TestStringIntrinsics2.java).
>
> Best regards,
>
> Martin
>

From christian.thalinger at oracle.com  Fri Feb 19 22:40:40 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Feb 2016 12:40:40 -1000
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: 
References: <56C702B6.5010903@oracle.com> <56C72118.6030304@gmail.com>
	<7AB17C7E-B33A-4EA4-A04F-C77E8E0EA21B@oracle.com>
	
Message-ID: <14FEA851-0CA5-4565-8B7B-22AD26EFB204@oracle.com>


> On Feb 19, 2016, at 9:03 AM, John Rose  wrote:
> 
> On Feb 19, 2016, at 9:57 AM, Christian Thalinger > wrote:
>> 
>> Why don?t you change the values to:
>> 
>>    static final byte LATIN1 = 1;
>>    static final byte UTF16  = 2;
> 
> 
> Not sure what you are asking, but here's my take on why 0,1 is the (slight) winner.
> The values 0,1 are the log2 of the array element sizes 1,2, so they can be used with shift instructions.
> With 1,2 they would have to be used with multiply instructions, or else tweaked back to shift inputs.
> Most loops will speculate on the scale factor, but those loops which must work with a non-constant scale will be slightly cleaner with 0,1.

I see what you are saying:

  int len = val.length >> coder;  // assume LATIN1=0/UTF16=1;

But if coder is stable for both values the compiler can constant fold the if-statement for the shift value:

  int len = val.length >> (coder == LATIN1 ? 0 : 1);

That should produce the same code and we would avoid:

143      * Constant-folding this field is handled internally in VM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From john.r.rose at oracle.com  Fri Feb 19 22:54:05 2016
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 19 Feb 2016 14:54:05 -0800
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <14FEA851-0CA5-4565-8B7B-22AD26EFB204@oracle.com>
References: <56C702B6.5010903@oracle.com> <56C72118.6030304@gmail.com>
	<7AB17C7E-B33A-4EA4-A04F-C77E8E0EA21B@oracle.com>
	
	<14FEA851-0CA5-4565-8B7B-22AD26EFB204@oracle.com>
Message-ID: <195285F1-8037-46F6-952E-64DC3AC3FE0E@oracle.com>

On Feb 19, 2016, at 2:40 PM, Christian Thalinger  wrote:
> 
>> 
>> On Feb 19, 2016, at 9:03 AM, John Rose > wrote:
>> 
>> On Feb 19, 2016, at 9:57 AM, Christian Thalinger > wrote:
>>> 
>>> Why don?t you change the values to:
>>> 
>>>    static final byte LATIN1 = 1;
>>>    static final byte UTF16  = 2;
>> 
>> 
>> Not sure what you are asking, but here's my take on why 0,1 is the (slight) winner.
>> The values 0,1 are the log2 of the array element sizes 1,2, so they can be used with shift instructions.
>> With 1,2 they would have to be used with multiply instructions, or else tweaked back to shift inputs.
>> Most loops will speculate on the scale factor, but those loops which must work with a non-constant scale will be slightly cleaner with 0,1.
> 
> I see what you are saying:
> 
>   int len = val.length >> coder;  // assume LATIN1=0/UTF16=1;
> 
> But if coder is stable for both values the compiler can constant fold the if-statement for the shift value:
> 
>   int len = val.length >> (coder == LATIN1 ? 0 : 1);
> 
> That should produce the same code and we would avoid:
> 
> 143      * Constant-folding this field is handled internally in VM.


Yes, the coder value can usually be speculated, especially if we encourage the JIT to pay special attention.
I'm only talking about the parts where the coder cannot be speculated upon.
? John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From aleksey.shipilev at oracle.com  Fri Feb 19 23:22:28 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Sat, 20 Feb 2016 02:22:28 +0300
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <14FEA851-0CA5-4565-8B7B-22AD26EFB204@oracle.com>
References: <56C702B6.5010903@oracle.com> <56C72118.6030304@gmail.com>
	<7AB17C7E-B33A-4EA4-A04F-C77E8E0EA21B@oracle.com>
	
	<14FEA851-0CA5-4565-8B7B-22AD26EFB204@oracle.com>
Message-ID: <56C7A3B4.7010904@oracle.com>

On 02/20/2016 01:40 AM, Christian Thalinger wrote:
>> On Feb 19, 2016, at 9:03 AM, John Rose  wrote:
>> On Feb 19, 2016, at 9:57 AM, Christian Thalinger > wrote:
>>> Why don?t you change the values to:
>>>
>>>    static final byte LATIN1 = 1;
>>>    static final byte UTF16  = 2;

We've been over this during Compact Strings development. The idea that
John has below is related to our actual insights leading to 0/1 instead
of 1/2. The best thing you can do with 1/2 is, apparently:

  int length() {
     return value.length >> (coder - 1);
  }

  char charAt(int idx) {
     return getCharAt(idx * coder);        // variant 1
     return getCharAt(idx << (coder - 1)); // variant 2
  }

...and you are better off not doing excess "-1" or
non-strength-reducible multiplications in a very hot paths in String.

Anyhow, that ship had sailed, and any change in coder definitions would
require to respin an awful lot of Compact String testing, and probably
revalidating lots of premises in the code. This is good as a thought
experiment, but not practical at this point in JDK 9 development.


> But if coder is stable for both values the compiler can constant fold the if-statement for the shift value:
> 
>   int len = val.length >> (coder == LATIN1 ? 0 : 1);
> 
> That should produce the same code and we would avoid:
> 
> 143      * Constant-folding this field is handled internally in VM.

The constant-folding story is not the only story you should care about.

For most Strings, we do not know either String.value or String.coder
statically. This particular constant-folding bit affects String
concatenation with constants, but the solution to it cannot possibly
regress an overwhelming case of non-constant Strings. Changing the coder
designations *would* affect non-constant Strings.

I would guess that the comment on "coder" field throws a reader into
thinking that @Stable is the answer to constant folding woes. But VM
already trusts final fields in String (e.g. String.value.arraylength is
folded, see JDK-8149813) -- as the part of TrustStaticNonFinalFields
machinery, which hopefully some day would get exposed to other fields.
Frozen arrays would hit the final (pun intended) nail into String.value
folding. @Stable hack is doing that today; but that's a hack, for a very
performance-sensitive corner in JDK.

Hopefully the rewritten comments spell it better:
  http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.02/
  http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/

Cheers,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From christian.thalinger at oracle.com  Fri Feb 19 23:31:06 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Feb 2016 13:31:06 -1000
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56C7A3B4.7010904@oracle.com>
References: <56C702B6.5010903@oracle.com> <56C72118.6030304@gmail.com>
	<7AB17C7E-B33A-4EA4-A04F-C77E8E0EA21B@oracle.com>
	
	<14FEA851-0CA5-4565-8B7B-22AD26EFB204@oracle.com>
	<56C7A3B4.7010904@oracle.com>
Message-ID: <60B3151D-7EDB-43A1-87BA-C2459501F0AD@oracle.com>


> On Feb 19, 2016, at 1:22 PM, Aleksey Shipilev  wrote:
> 
> On 02/20/2016 01:40 AM, Christian Thalinger wrote:
>>> On Feb 19, 2016, at 9:03 AM, John Rose  wrote:
>>> On Feb 19, 2016, at 9:57 AM, Christian Thalinger > wrote:
>>>> Why don?t you change the values to:
>>>> 
>>>>   static final byte LATIN1 = 1;
>>>>   static final byte UTF16  = 2;
> 
> We've been over this during Compact Strings development. The idea that
> John has below is related to our actual insights leading to 0/1 instead
> of 1/2. The best thing you can do with 1/2 is, apparently:
> 
>  int length() {
>     return value.length >> (coder - 1);
>  }
> 
>  char charAt(int idx) {
>     return getCharAt(idx * coder);        // variant 1
>     return getCharAt(idx << (coder - 1)); // variant 2
>  }
> 
> ...and you are better off not doing excess "-1" or
> non-strength-reducible multiplications in a very hot paths in String.
> 
> Anyhow, that ship had sailed, and any change in coder definitions would
> require to respin an awful lot of Compact String testing, and probably
> revalidating lots of premises in the code. This is good as a thought
> experiment, but not practical at this point in JDK 9 development.
> 
> 
>> But if coder is stable for both values the compiler can constant fold the if-statement for the shift value:
>> 
>>  int len = val.length >> (coder == LATIN1 ? 0 : 1);
>> 
>> That should produce the same code and we would avoid:
>> 
>> 143      * Constant-folding this field is handled internally in VM.
> 
> The constant-folding story is not the only story you should care about.
> 
> For most Strings, we do not know either String.value or String.coder
> statically. This particular constant-folding bit affects String
> concatenation with constants, but the solution to it cannot possibly
> regress an overwhelming case of non-constant Strings. Changing the coder
> designations *would* affect non-constant Strings.
> 
> I would guess that the comment on "coder" field throws a reader into
> thinking that @Stable is the answer to constant folding woes. But VM
> already trusts final fields in String (e.g. String.value.arraylength is
> folded, see JDK-8149813) -- as the part of TrustStaticNonFinalFields
> machinery, which hopefully some day would get exposed to other fields.
> Frozen arrays would hit the final (pun intended) nail into String.value
> folding. @Stable hack is doing that today; but that's a hack, for a very
> performance-sensitive corner in JDK.
> 
> Hopefully the rewritten comments spell it better:

That comment is better.

>  http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.02/
>  http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/
> 
> Cheers,
> -Aleksey
> 
> 


From jamsheed.c.m at oracle.com  Fri Feb 19 23:40:33 2016
From: jamsheed.c.m at oracle.com (Jamsheed C m)
Date: Sat, 20 Feb 2016 05:10:33 +0530
Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler
	-XX:-EnableJVMCI makes JVM crash
In-Reply-To: 
References: <56BC90DC.10004@oracle.com>
	
	<56BD8DF9.1070605@oracle.com>
	
	<56BE1274.4020506@oracle.com>
	<41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com>
	<56C3221D.2040507@oracle.com> <56C48936.4090303@oracle.com>
	
	<56C5163D.7010208@oracle.com> <56C5F0CA.5010307@oracle.com>
	
	<56C6A6DE.9060806@oracle.com> <56C736DA.304@oracle.com>
	
Message-ID: <56C7A7F1.3090500@oracle.com>

Thanks, Chris.

Best Regards,
Jamsheed

On 2/19/2016 10:56 PM, Christian Thalinger wrote:
> Looks good.  Thanks.
>
>> On Feb 19, 2016, at 5:38 AM, Jamsheed C m > > wrote:
>>
>> Hi Chris,
>>
>> Made all suggested changes.
>>
>> Revised webrev: http://cr.openjdk.java.net/~jcm/8145333/webrev.05/
>>
>> Thanks and Best Regards,
>> Jamsheed
>>
>> On 2/19/2016 10:53 AM, Jamsheed C m wrote:
>>>
>>>
>>> On 2/18/2016 11:21 PM, Christian Thalinger wrote:
>>>> +  if (EnableJVMCI)
>>>> +    return true;
>>>>
>>>> Please use { } for all if statements.
>>> Ok.
>>>>
>>>> Thanks for the comments; it?s easier to understand now.  May I 
>>>> suggest to do:
>>>>
>>>>   int skip_fail_count;
>>>>   if (!FLAG_IS_DEFAULT(EnableJVMCI)) {
>>>>     skip_fail_count = 1;
>>>>   } else {
>>>>     skip_fail_count = 0;
>>>>   }
>>> Ok.
>>>
>>> Best Regards,
>>> Jamsheed
>>>>
>>>>> On Feb 18, 2016, at 6:26 AM, Jamsheed C m 
>>>>>  wrote:
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Made all suggested changes.
>>>>>
>>>>> Revised webrev: 
>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.04/
>>>>>
>>>>> Best Regards,
>>>>> Jamsheed
>>>>>
>>>>> On 2/18/2016 6:24 AM, Jamsheed C m wrote:
>>>>>>
>>>>>>
>>>>>> On 2/18/2016 12:36 AM, Christian Thalinger wrote:
>>>>>>>
>>>>>>>> On Feb 17, 2016, at 4:52 AM, Jamsheed C m 
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> experimental and diagnostic flags are under condition checks now.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.03/ 
>>>>>>>> 
>>>>>>>
>>>>>>> I?m not very happy about the new macros but I can see why it?s 
>>>>>>> useful.
>>>>>>>
>>>>>>> +#if INCLUDE_JVMCI
>>>>>>> +
>>>>>>> +// Check consistency of jvmci vm argument settings.
>>>>>>> +bool Arguments::check_jvmci_args_consistency() {
>>>>>>> +
>>>>>>> +
>>>>>>> +  if (!EnableJVMCI && is_any_jvmci_arg_values_changed()) {
>>>>>>> +  print_jvmci_arg_inconsistency_error_message();
>>>>>>> +    return false;
>>>>>>>
>>>>>>> Please remove all these empty lines.  There are others as well.
>>>>>>>
>>>>>>> +bool is_any_jvmci_arg_values_changed() {
>>>>>>>
>>>>>>> This method needs another name.
>>>>>>>
>>>>>> Ok.
>>>>>>> +  int check_count = 0, fail_count = 0;
>>>>>>>
>>>>>>> I don?t like the check_count/fail_count logic because it?s fragile.
>>>>>> As  EanbleJVMCI flag cannot be avoided from macro expansion 
>>>>>> logic, i had to use some technique to exclude this flag from 
>>>>>> failure decision making.
>>>>>> Check_count/fail_count logic was added as a solution for this. 
>>>>>> i.e When EnableJVMCI is changed, code requires at-least 2 check 
>>>>>> failures to decide a real failure. otherwise one failure is 
>>>>>> sufficient.
>>>>>>
>>>>>> if i remove this logic, i will have to use strcmp(#FLAG, 
>>>>>> "EnableJVMCI") which will add a little more instructions that 
>>>>>> will  execute at-least once for every flag consistent run.
>>>>>>
>>>>>> let me know if i need to take second approach. or if existing 
>>>>>> code is ok.
>>>>>>>
>>>>>>> +// Check if any jvmci global defaults changed.
>>>>>>> +bool is_any_jvmci_arg_values_changed();
>>>>>>> +// Print jvmci args inconsistency error message.
>>>>>>> +void print_jvmci_arg_inconsistency_error_message();
>>>>>>>
>>>>>>> These should be in some kind of namespace or class.  Maybe put 
>>>>>>> them into: class JVMCIGlobals
>>>>>> Ok.
>>>>>>
>>>>>> Best Regards,
>>>>>> Jamsheed
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Jamsheed
>>>>>>>>
>>>>>>>> On 2/16/2016 6:50 PM, Jamsheed C m wrote:
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>> Revised webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/
>>>>>>>>>
>>>>>>>>> This code take care of every jvmci flags automatically.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Jamsheed
>>>>>>>>>
>>>>>>>>> On 2/13/2016 3:24 AM, Christian Thalinger wrote:
>>>>>>>>>>
>>>>>>>>>>> On Feb 12, 2016, at 7:12 AM, Jamsheed C m 
>>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>
>>>>>>>>>>> On 2/12/2016 10:12 PM, Christian Thalinger wrote:
>>>>>>>>>>>> Well, now you have to manually check all flags that had 
>>>>>>>>>>>> a constraint directive.  That is the annoying part and what 
>>>>>>>>>>>> I complained about in:
>>>>>>>>>>> check against original value, and if not fail ?
>>>>>>>>>>
>>>>>>>>>> Same check for all flags; they all depend on +EnableJVMCI.
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8145357
>>>>>>>>>>>>
>>>>>>>>>>>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are 
>>>>>>>>>>>> now empty and I think we should remove them.
>>>>>>>>>>> i kept the file as there can be future use. Ok, i will 
>>>>>>>>>>> remove it.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Jamsheed
>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m 
>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>>>
>>>>>>>>>>>>> revised webrev: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m 
>>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Request for review
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333
>>>>>>>>>>>>>>> web url: 
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That looks alright but we should remove the constraints 
>>>>>>>>>>>>>> from all the JVMCI command line flags because the way we 
>>>>>>>>>>>>>> use them is not supported.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, can you change the error message?  Right now it 
>>>>>>>>>>>>>> looks like this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> $ 
>>>>>>>>>>>>>> ./build/macosx-x86_64-normal-server-release/jdk/bin/java 
>>>>>>>>>>>>>> -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler
>>>>>>>>>>>>>> EnableJVMCI must be enabled
>>>>>>>>>>>>>> Improperly specified VM option 'UseJVMCICompiler'
>>>>>>>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think with your changes we will only see the first line 
>>>>>>>>>>>>>> without mentioning UseJVMCICompiler.  Is that correct?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Fix Summary: added jvmci flag consistency check after 
>>>>>>>>>>>>>>> arg parsing.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> tests: jprt
>>>>>>>>>>>>>>> unit test: command line verification
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pavel.punegov at oracle.com  Sat Feb 20 12:25:22 2016
From: pavel.punegov at oracle.com (Pavel Punegov)
Date: Sat, 20 Feb 2016 15:25:22 +0300
Subject: RFR (S): 8148563:
	compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java timesout
In-Reply-To: <56C77EFA.1060702@oracle.com>
References: <47423DF0-C7C7-4053-BEC0-1D12A558E982@oracle.com>
	<56C77EFA.1060702@oracle.com>
Message-ID: <56C85B32.4040405@oracle.com>

Vladimir,

Test generated 5 directives of size 1000 directives before.
Previously test added them to directives stack one after another, making 
VM fail with native OOM (JDK-8144246 
). 
CompilerDirectivesLimit flag was added with default value of 50. Since 
that test began to add directives on the stack failing every time.

I changed the test to create only one file (999 directives) to reach the 
limit of 1000 (set by option). So it still can try to add directives 
over the limit, but it also executes other commands like "clear", 
"remove" and "print".

Added Nils to CC. Nils, could you please take a look also?

On 19.02.2016 23:45, Vladimir Kozlov wrote:
> Seems fine. What size of directive files was before and after this 
> fix? JBS does not have this information.
>
> Thanks,
> Vladimir
>
> On 2/19/16 9:04 AM, Pavel Punegov wrote:
>> Hi,
>>
>> please review the fix for a test bug.
>>
>> Issue:
>> 1. Test timeouts because it executes a lot of jcmd processes. Number of
>> threads is calculated as number of processors (cores) * 10, that led to
>> an enormous number of jcmds executed on hosts with lots of CPUs/cores.
>> 2. Test also spends a lot of time to generate 5 huge directive files,
>> that were tried to be added on to the directives stack. Directive stack
>> has a limit (default 50, controlled by CompilerDirectivesLimit).
>>
>> Fix:
>> 1. Calculate number of threads as a log of the number of CPUs/cores * 
>> 10.
>> 2. Generate only one file that is less than specified
>> CompilerDirectivesLimit.
>> 3. Add different commands to execute (add, clear, remove and print) and
>> generate them on demand.
>>
>> webrev: http://cr.openjdk.java.net/~ppunegov/8148563/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8148563
>>
>> ? Pavel.
>>

-- 
Thanks,
Pavel Punegov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pavel.punegov at oracle.com  Sat Feb 20 13:14:25 2016
From: pavel.punegov at oracle.com (Pavel Punegov)
Date: Sat, 20 Feb 2016 16:14:25 +0300
Subject: RFR (S): 8148563:
	compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java timesout
In-Reply-To: <56C85B32.4040405@oracle.com>
References: <47423DF0-C7C7-4053-BEC0-1D12A558E982@oracle.com>	<56C77EFA.1060702@oracle.com>
	<56C85B32.4040405@oracle.com>
Message-ID: <56C866B1.2030207@oracle.com>

Added Nils. Somehow previous message doesn't have him in CC

On 20.02.2016 15:25, Pavel Punegov wrote:
> Vladimir,
>
> Test generated 5 directives of size 1000 directives before.
> Previously test added them to directives stack one after another, 
> making VM fail with native OOM (JDK-8144246 
> ). 
> CompilerDirectivesLimit flag was added with default value of 50. Since 
> that test began to add directives on the stack failing every time.
>
> I changed the test to create only one file (999 directives) to reach 
> the limit of 1000 (set by option). So it still can try to add 
> directives over the limit, but it also executes other commands like 
> "clear", "remove" and "print".
>
> Added Nils to CC. Nils, could you please take a look also?
>
> On 19.02.2016 23:45, Vladimir Kozlov wrote:
>> Seems fine. What size of directive files was before and after this 
>> fix? JBS does not have this information.
>>
>> Thanks,
>> Vladimir
>>
>> On 2/19/16 9:04 AM, Pavel Punegov wrote:
>>> Hi,
>>>
>>> please review the fix for a test bug.
>>>
>>> Issue:
>>> 1. Test timeouts because it executes a lot of jcmd processes. Number of
>>> threads is calculated as number of processors (cores) * 10, that led to
>>> an enormous number of jcmds executed on hosts with lots of CPUs/cores.
>>> 2. Test also spends a lot of time to generate 5 huge directive files,
>>> that were tried to be added on to the directives stack. Directive stack
>>> has a limit (default 50, controlled by CompilerDirectivesLimit).
>>>
>>> Fix:
>>> 1. Calculate number of threads as a log of the number of CPUs/cores 
>>> * 10.
>>> 2. Generate only one file that is less than specified
>>> CompilerDirectivesLimit.
>>> 3. Add different commands to execute (add, clear, remove and print) and
>>> generate them on demand.
>>>
>>> webrev: http://cr.openjdk.java.net/~ppunegov/8148563/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8148563
>>>
>>> ? Pavel.
>>>
>
> -- 
> Thanks,
> Pavel Punegov

-- 
Thanks,
Pavel Punegov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jamsheed.c.m at oracle.com  Sat Feb 20 18:12:50 2016
From: jamsheed.c.m at oracle.com (Jamsheed C m)
Date: Sat, 20 Feb 2016 23:42:50 +0530
Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler
	-XX:-EnableJVMCI makes JVM crash
In-Reply-To: <56C7A7F1.3090500@oracle.com>
References: <56BC90DC.10004@oracle.com>
	
	<56BD8DF9.1070605@oracle.com>
	
	<56BE1274.4020506@oracle.com>
	<41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com>
	<56C3221D.2040507@oracle.com> <56C48936.4090303@oracle.com>
	
	<56C5163D.7010208@oracle.com> <56C5F0CA.5010307@oracle.com>
	
	<56C6A6DE.9060806@oracle.com> <56C736DA.304@oracle.com>
	
	<56C7A7F1.3090500@oracle.com>
Message-ID: <56C8ACA2.5070906@oracle.com>

Hi Chris,

I missed handling a valid case where 
UnlockExperimentalVMOptions/UnlockDiagnosticVMOptions are made false 
after experimental/diagnostic jvmci flags are modified.

i.e :  bin/java  -XX:+UnlockExperimentalVMOptions -XX:-EnableJVMCI 
-XX:+UseJVMCICompiler -XX:-UnlockExperimentalVMOptions -version

made changes to handle this case.

code change

+ // Check consistency of diagnostic flags if UnlockDiagnosticVMOptions 
is true
+ // or not default. UnlockDiagnosticVMOptions is default true in debug 
builds.
+ if (UnlockDiagnosticVMOptions ||
+ !FLAG_IS_DEFAULT(UnlockDiagnosticVMOptions)) { + // Check consistency 
of experimental flags if UnlockExperimentalVMOptions is
+ // true or not default.
+ if (UnlockExperimentalVMOptions ||
+ !FLAG_IS_DEFAULT(UnlockExperimentalVMOptions)) {



revised webrev: http://cr.openjdk.java.net/~jcm/8145333/webrev.06/

Thanks and Best Regards,
Jamsheed

On 2/20/2016 5:10 AM, Jamsheed C m wrote:
> Thanks, Chris.
>
> Best Regards,
> Jamsheed
>
> On 2/19/2016 10:56 PM, Christian Thalinger wrote:
>> Looks good.  Thanks.
>>
>>> On Feb 19, 2016, at 5:38 AM, Jamsheed C m  
>>> wrote:
>>>
>>> Hi Chris,
>>>
>>> Made all suggested changes.
>>>
>>> Revised webrev: http://cr.openjdk.java.net/~jcm/8145333/webrev.05/
>>>
>>> Thanks and Best Regards,
>>> Jamsheed
>>>
>>> On 2/19/2016 10:53 AM, Jamsheed C m wrote:
>>>>
>>>>
>>>> On 2/18/2016 11:21 PM, Christian Thalinger wrote:
>>>>> +  if (EnableJVMCI)
>>>>> +    return true;
>>>>>
>>>>> Please use { } for all if statements.
>>>> Ok.
>>>>>
>>>>> Thanks for the comments; it?s easier to understand now.  May I 
>>>>> suggest to do:
>>>>>
>>>>>   int skip_fail_count;
>>>>>   if (!FLAG_IS_DEFAULT(EnableJVMCI)) {
>>>>>     skip_fail_count = 1;
>>>>>   } else {
>>>>>     skip_fail_count = 0;
>>>>>   }
>>>> Ok.
>>>>
>>>> Best Regards,
>>>> Jamsheed
>>>>>
>>>>>> On Feb 18, 2016, at 6:26 AM, Jamsheed C m 
>>>>>>  wrote:
>>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> Made all suggested changes.
>>>>>>
>>>>>> Revised webrev: 
>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.04/
>>>>>>
>>>>>> Best Regards,
>>>>>> Jamsheed
>>>>>>
>>>>>> On 2/18/2016 6:24 AM, Jamsheed C m wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2/18/2016 12:36 AM, Christian Thalinger wrote:
>>>>>>>>
>>>>>>>>> On Feb 17, 2016, at 4:52 AM, Jamsheed C m 
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>> experimental and diagnostic flags are under condition checks now.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.03/ 
>>>>>>>>> 
>>>>>>>>
>>>>>>>> I?m not very happy about the new macros but I can see why it?s 
>>>>>>>> useful.
>>>>>>>>
>>>>>>>> +#if INCLUDE_JVMCI
>>>>>>>> +
>>>>>>>> +// Check consistency of jvmci vm argument settings.
>>>>>>>> +bool Arguments::check_jvmci_args_consistency() {
>>>>>>>> +
>>>>>>>> +
>>>>>>>> +  if (!EnableJVMCI && is_any_jvmci_arg_values_changed()) {
>>>>>>>> +  print_jvmci_arg_inconsistency_error_message();
>>>>>>>> +    return false;
>>>>>>>>
>>>>>>>> Please remove all these empty lines.  There are others as well.
>>>>>>>>
>>>>>>>> +bool is_any_jvmci_arg_values_changed() {
>>>>>>>>
>>>>>>>> This method needs another name.
>>>>>>>>
>>>>>>> Ok.
>>>>>>>> +  int check_count = 0, fail_count = 0;
>>>>>>>>
>>>>>>>> I don?t like the check_count/fail_count logic because it?s fragile.
>>>>>>> As  EanbleJVMCI flag cannot be avoided from macro expansion 
>>>>>>> logic, i had to use some technique to exclude this flag from 
>>>>>>> failure decision making.
>>>>>>> Check_count/fail_count logic was added as a solution for this. 
>>>>>>> i.e When EnableJVMCI is changed, code requires at-least 2 check 
>>>>>>> failures to decide a real failure. otherwise one failure is 
>>>>>>> sufficient.
>>>>>>>
>>>>>>> if i remove this logic, i will have to use strcmp(#FLAG, 
>>>>>>> "EnableJVMCI") which will add a little more instructions that 
>>>>>>> will  execute at-least once for every flag consistent run.
>>>>>>>
>>>>>>> let me know if i need to take second approach. or if existing 
>>>>>>> code is ok.
>>>>>>>>
>>>>>>>> +// Check if any jvmci global defaults changed.
>>>>>>>> +bool is_any_jvmci_arg_values_changed();
>>>>>>>> +// Print jvmci args inconsistency error message.
>>>>>>>> +void print_jvmci_arg_inconsistency_error_message();
>>>>>>>>
>>>>>>>> These should be in some kind of namespace or class.  Maybe put 
>>>>>>>> them into: class JVMCIGlobals
>>>>>>> Ok.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Jamsheed
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Jamsheed
>>>>>>>>>
>>>>>>>>> On 2/16/2016 6:50 PM, Jamsheed C m wrote:
>>>>>>>>>> Hi Chris,
>>>>>>>>>>
>>>>>>>>>> Revised webrev: 
>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/
>>>>>>>>>>
>>>>>>>>>> This code take care of every jvmci flags automatically.
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Jamsheed
>>>>>>>>>>
>>>>>>>>>> On 2/13/2016 3:24 AM, Christian Thalinger wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Feb 12, 2016, at 7:12 AM, Jamsheed C m 
>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/12/2016 10:12 PM, Christian Thalinger wrote:
>>>>>>>>>>>>> Well, now you have to manually check all flags that had 
>>>>>>>>>>>>> a constraint directive.  That is the annoying part and 
>>>>>>>>>>>>> what I complained about in:
>>>>>>>>>>>> check against original value, and if not fail ?
>>>>>>>>>>>
>>>>>>>>>>> Same check for all flags; they all depend on +EnableJVMCI.
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8145357
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are 
>>>>>>>>>>>>> now empty and I think we should remove them.
>>>>>>>>>>>> i kept the file as there can be future use. Ok, i will 
>>>>>>>>>>>> remove it.
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m 
>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> revised webrev: 
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m 
>>>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Request for review
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8145333
>>>>>>>>>>>>>>>> web url: 
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That looks alright but we should remove the constraints 
>>>>>>>>>>>>>>> from all the JVMCI command line flags because the way we 
>>>>>>>>>>>>>>> use them is not supported.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Also, can you change the error message?  Right now it 
>>>>>>>>>>>>>>> looks like this:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> $ 
>>>>>>>>>>>>>>> ./build/macosx-x86_64-normal-server-release/jdk/bin/java 
>>>>>>>>>>>>>>> -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler
>>>>>>>>>>>>>>> EnableJVMCI must be enabled
>>>>>>>>>>>>>>> Improperly specified VM option 'UseJVMCICompiler'
>>>>>>>>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think with your changes we will only see the first 
>>>>>>>>>>>>>>> line without mentioning UseJVMCICompiler.  Is that correct?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Fix Summary: added jvmci flag consistency check after 
>>>>>>>>>>>>>>>> arg parsing.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> tests: jprt
>>>>>>>>>>>>>>>> unit test: command line verification
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From martin.doerr at sap.com  Mon Feb 22 08:17:24 2016
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 22 Feb 2016 08:17:24 +0000
Subject: RFR(L) 8149655: PPC64: Implement CompactString intrinsics
In-Reply-To: <56C783C7.70201@oracle.com>
References: 
	<6d2ee7af0e2947abb989fa84369f4f0f@DEWDFE13DE09.global.corp.sap>
	<717d9d731f294a8eb3ba6be83e7e4c05@DEWDFE13DE13.global.corp.sap>
	<898cbee841884ef7b4f3ad9e3681e282@DEWDFE13DE09.global.corp.sap>
	<56C783C7.70201@oracle.com>
Message-ID: <7d4c8b809f0f4655af340969f634de9f@DEWDFE13DE14.global.corp.sap>

Hi Vladimir,

thank you very much for sponsoring so quickly.

Best regards,
Martin

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Freitag, 19. Februar 2016 22:06
To: Lindenmaier, Goetz ; Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(L) 8149655: PPC64: Implement CompactString intrinsics

Job is submitted to JPRT.

Thanks,
Vladimir

On 2/19/16 5:14 AM, Lindenmaier, Goetz wrote:
> Hi Martin,
>
> looks good now. Could someone please sponsor?
>
> Thanks for the fixes,
>
>    Goetz.
>
> *From:*Doerr, Martin
> *Sent:* Friday, February 19, 2016 11:38 AM
> *To:* Lindenmaier, Goetz ;
> hotspot-compiler-dev at openjdk.java.net
> *Subject:* RE: RFR(L) 8149655: PPC64: Implement CompactString intrinsics
>
> Hi G?tz,
>
> thanks for the review. I basically used small micro-benchmarks and tests
> and later our nightly tests which I have extended a little bit with this
> change. There were some match rules which I only hit with the change I
> made in TestStringIntrinsics2.
>
> I think you're right. The addition to the predicate for
> string_indexOf_imm1_charNodeshould not be needed because the AddP node
> for the immediate needle gets matched with the StrIndexOfNode.
>
> I have removed it again from this node and from the new nodes which
> match indexOf_imm1_char in the 3 different flavors.
>
> Spaces before comma are also fixed.
>
> The guarantee(needlecntval != 1, .) is not new. It was already there in
> the non-CompactStrings version. string_indexof wouldn't generate correct
> code. There's a separate match rule for that case.
>
> New webrev is here:
>
> http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.01/
>
> Best regards,
>
> Martin
>
> *From:*Lindenmaier, Goetz
> *Sent:* Donnerstag, 18. Februar 2016 20:50
> *To:* Doerr, Martin  >; hotspot-compiler-dev at openjdk.java.net
> 
> *Subject:* RE: RFR(L) 8149655: PPC64: Implement CompactString intrinsics
>
> Hi Martin,
>
> I finally had a look at this change.  Good work!
>
> What did you test this with,  besides our hs-comp nighttests, which
>
> already is quite a lot?
>
> ppc.ad:
>
> I saw you added more conditions to the predicate of
> string_indexOf_imm1_char() etc.
>
> Isn't this obvious because needleImm is an immP?
>
> macroassmbler_ppc.cpp:
>
> if (stride1 == 1) { lbz(chr1, 0, str1); } else { lhz(chr1, 0 ,str1); }
>
> Space before comma.  There are more of these, search for '0 ,'
>
> guarantee(needlecntval != 1,
>
> not indented . or is this on purpose?
>
> Best regards,
>
>    Goetz.
>
> *From:*hotspot-compiler-dev
> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] *On Behalf Of
> *Doerr, Martin
> *Sent:* Thursday, February 11, 2016 4:11 PM
> *To:* hotspot-compiler-dev at openjdk.java.net
> 
> *Subject:* RFR(L) 8149655: PPC64: Implement CompactString intrinsics
>
> Hi,
>
> I have created a webrev which adds the following String intrinsics to PPC64:
>
> 0 string_compareL
>
> 1 string_compareU
>
> 2 string_compareLU
>
> 3 string_compareUL
>
> 4 string_equalsL
>
> 5 string_equalsU
>
> 6 array_equalsB
>
> 7 array_equalsC
>
> 8 indexOf_imm1_char_U
>
> 9 indexOf_imm1_char_L
>
> 10 indexOf_imm1_char_UL
>
> 11 indexOf_imm1_U
>
> 12 indexOf_imm1_L
>
> 13 indexOf_imm1_UL
>
> 14 indexOfChar_U
>
> 15 indexOf_imm_U
>
> 16 indexOf_imm_L
>
> 17 indexOf_imm_UL
>
> 18 indexOf_U
>
> 19 indexOf_L
>
> 20 indexOf_UL
>
> 21 string_compress
>
> 22 string_inflate
>
> 23 has_negatives
>
> 24 encode_iso_array
>
> It also contains some other minor improvements.
>
> The webrev is here:
>
> http://cr.openjdk.java.net/~mdoerr/8149655_PPC64_StringIntrinsics/webrev.00/
>
> Please review.
>
> I will also need a sponsor from Oracle because the change touches one
> java test file (test/compiler/intrinsics/string/TestStringIntrinsics2.java).
>
> Best regards,
>
> Martin
>

From nils.eliasson at oracle.com  Mon Feb 22 09:47:59 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 22 Feb 2016 10:47:59 +0100
Subject: RFR(S): 8148159: [TESTBUG] TestCompilerDirectivesCompatibility
	tests fails on non-tiered server VMs
In-Reply-To: <115A77CE-C62D-4749-8E4A-2EE4A2F662AB@oracle.com>
References: <56C31DA9.3070607@oracle.com>
	<115A77CE-C62D-4749-8E4A-2EE4A2F662AB@oracle.com>
Message-ID: <56CAD94F.8080406@oracle.com>

Hi Pavel,

On 2016-02-17 16:52, Pavel Punegov wrote:
> Hi Nils,
>
> Do we need hasC1/2Compiler methods? 

I wanted to know exactly what compilers I am testing.

> There is a compiler.tstlibrary.CompilerUtils class that provides tests 
> with available levels. 

Didn't know about that one. It fills a good purpose but it should not 
guess what compiler levels are available - rather query the VM directly. 
We should also move a lot of useful constants from CompilerWhiteBoxTest 
to CompilerUtils.

> There is an example of usage 
> in test/compiler/compilercontrol/share/actions/CompileAction.java.
> Also, what about JVMCI in case of hasC2Compiler? AFAIK it works with 
> levels, but I don?t know if it will with such ifdef.

I only test the compilers that I know will support this flag. We would 
need some additional test utils for querying what compiler uses the 
JVMCI interface.

>
> Otherwise, it looks good (not a Reviewer)

Thanks for taking a look,
Nils

>
>> On 16 Feb 2016, at 16:01, Nils Eliasson > > wrote:
>>
>> Hi,
>>
>> Please review this change.
>>
>> The tests relied on C1 always being available and thus fails on C2 
>> only server configurations. The fix adds two whitebox methods for 
>> checking if C1 and C2 is available, and then tests both compilers 
>> separately. Also adding Xmixed to the commandline since this test 
>> doesn't need Xcomp testing.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8148159
>>
>> Webrev:
>> http://cr.openjdk.java.net/~neliasso/8148159/webrev.01/
>> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.01/
>>
>> Regards,
>> Nils Eliasson
>
>
>
> ? Thanks,
> Pavel Punegov
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From roland.westrelin at oracle.com  Mon Feb 22 10:05:37 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 22 Feb 2016 11:05:37 +0100
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
Message-ID: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>

Native code is passed an int (in a 64 bit register) which has some bits set in the upper 32 bit half. The native code uses that value for an address computation. That results in a wrong memory access. From a few experiments with code generated by gcc, it seems it expects values to be clean on function entry. The fix cleans the 32 bit value before the native call.

http://cr.openjdk.java.net/~roland/8148353/webrev.00/

Roland.

From roland.westrelin at oracle.com  Mon Feb 22 10:23:14 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 22 Feb 2016 11:23:14 +0100
Subject: RFR(XS): 8149916: Test case for 8149797
In-Reply-To: <56C34817.4060700@oracle.com>
References: <9370DE73-F7F4-4C15-9128-821CFCDA09DD@oracle.com>
	<56C34817.4060700@oracle.com>
Message-ID: <2A3D40F0-D11F-4A13-831D-47475432B9AA@oracle.com>

Thanks for the review, Vladimir.

Roland.


From roland.westrelin at oracle.com  Mon Feb 22 10:25:26 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 22 Feb 2016 11:25:26 +0100
Subject: RFR(S): 8148786: xml.tranform fails on x86-64
In-Reply-To: <56C4BA77.3090901@oracle.com>
References: <75A71E7B-0876-4296-AB34-E8BFB0EF2184@oracle.com>
	<56C208CF.1010700@oracle.com>
	<806215C3-EB89-474F-AAA4-686B43401967@oracle.com>
	<56C4BA77.3090901@oracle.com>
Message-ID: 

Thanks for the review, Vladimir.

Roland.

From nils.eliasson at oracle.com  Mon Feb 22 10:37:49 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 22 Feb 2016 11:37:49 +0100
Subject: RFR(S): 8148159: [TESTBUG] TestCompilerDirectivesCompatibility
	tests fails on non-tiered server VMs
In-Reply-To: <56CAD94F.8080406@oracle.com>
References: <56C31DA9.3070607@oracle.com>
	<115A77CE-C62D-4749-8E4A-2EE4A2F662AB@oracle.com>
	<56CAD94F.8080406@oracle.com>
Message-ID: <56CAE4FD.7000605@oracle.com>

Hi,

Webrev using comp levels from CompilerUtils instead:

http://cr.openjdk.java.net/~neliasso/8148159/webrev.02/
http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.02/

Best regards,
Nils Eliasson

On 2016-02-22 10:47, Nils Eliasson wrote:
> Hi Pavel,
>
> On 2016-02-17 16:52, Pavel Punegov wrote:
>> Hi Nils,
>>
>> Do we need hasC1/2Compiler methods? 
>
> I wanted to know exactly what compilers I am testing.
>
>> There is a compiler.tstlibrary.CompilerUtils class that provides 
>> tests with available levels. 
>
> Didn't know about that one. It fills a good purpose but it should not 
> guess what compiler levels are available - rather query the VM 
> directly. We should also move a lot of useful constants from 
> CompilerWhiteBoxTest to CompilerUtils.
>
>> There is an example of usage 
>> in test/compiler/compilercontrol/share/actions/CompileAction.java.
>> Also, what about JVMCI in case of hasC2Compiler? AFAIK it works with 
>> levels, but I don?t know if it will with such ifdef.
>
> I only test the compilers that I know will support this flag. We would 
> need some additional test utils for querying what compiler uses the 
> JVMCI interface.
>
>>
>> Otherwise, it looks good (not a Reviewer)
>
> Thanks for taking a look,
> Nils
>
>>
>>> On 16 Feb 2016, at 16:01, Nils Eliasson >> > wrote:
>>>
>>> Hi,
>>>
>>> Please review this change.
>>>
>>> The tests relied on C1 always being available and thus fails on C2 
>>> only server configurations. The fix adds two whitebox methods for 
>>> checking if C1 and C2 is available, and then tests both compilers 
>>> separately. Also adding Xmixed to the commandline since this test 
>>> doesn't need Xcomp testing.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8148159
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev.01/
>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.01/
>>>
>>> Regards,
>>> Nils Eliasson
>>
>>
>>
>> ? Thanks,
>> Pavel Punegov
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hui.shi at linaro.org  Mon Feb 22 11:56:25 2016
From: hui.shi at linaro.org (Hui Shi)
Date: Mon, 22 Feb 2016 19:56:25 +0800
Subject: RFR: 8149733: AArch64: refactor
	char_array_equals/byte_array_equals/string_equals
In-Reply-To: <56C70C42.5020309@oracle.com>
References: 
	<56C70C42.5020309@oracle.com>
Message-ID: 

Thanks Aleksey & Andrew!

Patch is updated in http://cr.openjdk.java.net/~hshi/8149733/webrev2/ , it
adds on
1. Fix misc spelling and format issues
2. Use cnt2 for array length compare, comment that cnt2 can?t be used after
length compare
3. Add more comments for tail handling

JMH test in
http://cr.openjdk.java.net/~hshi/8149733/webrev2/JMHSample_97_ArrayEqual.java
. Run with java -jar ../benchmarks.jar '.*JMHSample_97*' -w 5 -wi 3 -i 5 -r
10 -f 0

Following is testing result before and after apply this patch. Refactoring
looks better in most cases.

Length 1-8 before
Benchmark                                 Mode  Cnt     Score   Error  Units
JMHSample_97_ArrayEqual.byte_equal        avgt    5  2954.349 ? 0.076  us/op
JMHSample_97_ArrayEqual.byte_not_equal    avgt    5  3232.505 ? 7.050  us/op
JMHSample_97_ArrayEqual.char_equal        avgt    5  2916.643 ? 0.126  us/op
JMHSample_97_ArrayEqual.char_not_equal    avgt    5  2778.486 ? 3.539  us/op
JMHSample_97_ArrayEqual.string_equal      avgt    5  4411.364 ? 0.149  us/op
JMHSample_97_ArrayEqual.string_not_equal  avgt    5  3898.965 ? 0.122  us/op

Length 1-8 after
Benchmark                                 Mode  Cnt     Score     Error
 Units
JMHSample_97_ArrayEqual.byte_equal        avgt    5  2890.122 ?   1.279
 us/op
JMHSample_97_ArrayEqual.byte_not_equal    avgt    5  2893.002 ?   5.914
 us/op
JMHSample_97_ArrayEqual.char_equal        avgt    5  2735.193 ?   0.096
 us/op
JMHSample_97_ArrayEqual.char_not_equal    avgt    5  2753.818 ?   0.708
 us/op
JMHSample_97_ArrayEqual.string_equal      avgt    5  4162.080 ? 818.652
 us/op
JMHSample_97_ArrayEqual.string_not_equal  avgt    5  3824.308 ?   0.621
 us/op


Length 9-16 before
Benchmark                                 Mode  Cnt     Score    Error
 Units
JMHSample_97_ArrayEqual.byte_equal        avgt    5  4193.783 ?  22.731
 us/op
JMHSample_97_ArrayEqual.byte_not_equal    avgt    5  3819.967 ?  61.053
 us/op
JMHSample_97_ArrayEqual.char_equal        avgt    5  5780.135 ? 104.966
 us/op
JMHSample_97_ArrayEqual.char_not_equal    avgt    5  5694.717 ?  87.426
 us/op
JMHSample_97_ArrayEqual.string_equal      avgt    5  6741.276 ?   1.112
 us/op
JMHSample_97_ArrayEqual.string_not_equal  avgt    5  6439.345 ? 161.295
 us/op

Length 9-16 after
Benchmark                                 Mode  Cnt     Score   Error  Units
JMHSample_97_ArrayEqual.byte_equal        avgt    5  2937.688 ? 0.074  us/op
JMHSample_97_ArrayEqual.byte_not_equal    avgt    5  2842.832 ? 0.038  us/op
JMHSample_97_ArrayEqual.char_equal        avgt    5  5274.417 ? 0.912  us/op
JMHSample_97_ArrayEqual.char_not_equal    avgt    5  4611.007 ? 0.592  us/op
JMHSample_97_ArrayEqual.string_equal      avgt    5  6778.782 ? 28.918
 us/op
JMHSample_97_ArrayEqual.string_not_equal  avgt    5  6455.762 ? 10.674
 us/op

Length 32-39 before
Benchmark                                 Mode  Cnt      Score    Error
 Units
JMHSample_97_ArrayEqual.byte_equal        avgt    5   5519.248 ?  1.799
 us/op
JMHSample_97_ArrayEqual.byte_not_equal    avgt    5   7204.390 ? 72.663
 us/op
JMHSample_97_ArrayEqual.char_equal        avgt    5   7891.681 ?  4.859
 us/op
JMHSample_97_ArrayEqual.char_not_equal    avgt    5   9830.466 ?  0.800
 us/op
JMHSample_97_ArrayEqual.string_equal      avgt    5  10087.074 ?  1.976
 us/op
JMHSample_97_ArrayEqual.string_not_equal  avgt    5  11383.347 ?  1.712
 us/op

Length 32-39 after
Benchmark                                 Mode  Cnt      Score    Error
 Units
JMHSample_97_ArrayEqual.byte_equal        avgt    5   5445.432 ?  1.396
 us/op
JMHSample_97_ArrayEqual.byte_not_equal    avgt    5   5856.414 ?  0.996
 us/op
JMHSample_97_ArrayEqual.char_equal        avgt    5   7864.556 ?  1.408
 us/op
JMHSample_97_ArrayEqual.char_not_equal    avgt    5   9274.953 ? 30.892
 us/op
JMHSample_97_ArrayEqual.string_equal      avgt    5   9841.792 ?  0.721
 us/op
JMHSample_97_ArrayEqual.string_not_equal  avgt    5  10750.615 ?  1.252
 us/op

Length 1025-1032 before
Benchmark                                 Mode  Cnt       Score     Error
 Units
JMHSample_97_ArrayEqual.byte_equal        avgt    5  103655.644 ? 15794.521
 us/op
JMHSample_97_ArrayEqual.byte_not_equal    avgt    5   90908.990 ? 120.387
 us/op
JMHSample_97_ArrayEqual.char_equal        avgt    5  155515.192 ? 233.650
 us/op
JMHSample_97_ArrayEqual.char_not_equal    avgt    5  148312.632 ?  59.342
 us/op
JMHSample_97_ArrayEqual.string_equal      avgt    5  134281.945 ?  20.829
 us/op
JMHSample_97_ArrayEqual.string_not_equal  avgt    5  138580.479 ? 137.336
 us/o

Length 1025-1032 after
Benchmark                                 Mode  Cnt       Score       Error
 Units
JMHSample_97_ArrayEqual.byte_equal        avgt    5  102232.913 ? 1950.542
 us/op
JMHSample_97_ArrayEqual.byte_not_equal    avgt    5   90179.625 ? 102.160
 us/op
JMHSample_97_ArrayEqual.char_equal        avgt    5  152515.169 ?   167.507
 us/op
JMHSample_97_ArrayEqual.char_not_equal    avgt    5  140293.463 ?   198.916
 us/op
JMHSample_97_ArrayEqual.string_equal      avgt    5  141776.676 ?    42.597
 us/op
JMHSample_97_ArrayEqual.string_not_equal  avgt    5  130141.577 ?    29.875
 us/op

Regards
Hui

On 19 February 2016 at 20:36, Aleksey Shipilev 
wrote:

> Hi Hui,
>
> On 02/19/2016 03:13 PM, Hui Shi wrote:
> > webrev: http://cr.openjdk.java.net/~hshi/8149733/webrev/
> > 
>
> Not savvy with AArch64 assembly, but it does not look bad.
>
> My other comments are superficial:
>
>  * Desperately needs spell-checking: "implenetaions", "implemenation",
> "eqauls", "comapre"
>
>  * Inconsistent naming, e.g. "... = wordSize/step_size;"
>
>  * "if (is_string_equal == false) {"
>
>  * "if (exact_log >0 )"
>
>  * Shouldn't be:
>
>         4533     ldrw(cnt1, Address(ary1, length_offset));
>         4534     ldrw(tmp2, Address(ary2, length_offset));
>         4535     cmp(cnt1, tmp2);
>
>   spelled like:
>
>         4533 ldrw(cnt1, Address(ary1, length_offset));
>         4534 ldrw(cnt2, Address(ary2, length_offset));
>         4535 cmp(cnt1, cnt2);
>
>  * Would be nice to keep the comments like "// 0-7 bytes left, cnt1 =
> #bytes left - 4"
>
>  * Why TAIL01 block is predicated on (step_size == 1) now?
>
> > Test case: http://cr.openjdk.java.net/~hshi/8149733/TestArrayEqual.java
> > 
>
> I think you should really, really, really use JMH for these benchmarks:
>  http://openjdk.java.net/projects/code-tools/jmh/
>
> It would also provide you an easy access to generated code profiling,
> with -prof perfasm. It is usually pretty clear from that output if your
> generated code needs even more tuneups.
>
> Cheers,
> -Aleksey
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From nils.eliasson at oracle.com  Mon Feb 22 13:12:03 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 22 Feb 2016 14:12:03 +0100
Subject: RFR(S): [TESTBUG]
	compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java spawns
	tens of thousands of threads
Message-ID: <56CB0923.2090308@oracle.com>

Hi,

Please review this update of the compiler control stress tests.

This change includes the following changes:
* Change the test to only use a small fix number of threads.
* Removes the 
test/compiler/compilercontrol/jcmd/StressAddSequentiallyTest.java. The 
Multithreaded tests tests the same things - no need to duplicate.
* Removes the time limited runner - testing adding directives will makes 
us hit the limit pretty fast - no idea continue adding tests in a loop 
for two minutes when they are rejected after a few seconds.
* Add -XX:CompilerDirectivesLimit=1601 to make sure we can test an 
unusually big amount of directives.
* Add -Xmixed to make sure we don't get PrintAssembly for every method 
in Xcomp.
* Remove the increased timeout.

The end result is that this test will use 4 threads to add 4 files of up 
to 100 directives each.

webrev: http://cr.openjdk.java.net/~neliasso/8149060/webrev.03/
bug: https://bugs.openjdk.java.net/browse/JDK-8149060

Best regards,
Nils Eliasson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From zoltan.majo at oracle.com  Mon Feb 22 14:22:15 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Mon, 22 Feb 2016 15:22:15 +0100
Subject: [9] RFR (S): 8148754: C2 loop unrolling fails due to unexpected
	graph shape
In-Reply-To: <56C26929.4050706@oracle.com>
References: <56C1ED18.6060903@oracle.com> <56C26929.4050706@oracle.com>
Message-ID: <56CB1997.40107@oracle.com>

Hi Vladimir,


thank you for the feedback!

On 02/16/2016 01:11 AM, Vladimir Kozlov wrote:
> Zoltan,
>
> It should not be "main" loop if peeling happened. See do_peeling():
>
>     if (cl->is_main_loop()) {
>       cl->set_normal_loop();
>
> Split-if optimization should not split through loop's phi. And 
> generally not through loop's head since it is not making code better - 
> split through backedge moves code into loop again. Making loop body 
> more complicated as this case shows.

I did more investigation to understand what causes the invalid graph 
shape to appear. It seems that the invalid graph shape appears because 
the compiler uses the Compile:: _major_progress inconsistently. Here are 
some details.

- If _major_progress *is set*, the compiler expects more loop 
optimizations to happen. Therefore, certain transformations on the graph 
are not allowed so that the graph is in a shape that can be processed by 
loop optimizations. See:
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/2c3c43037e14/src/share/vm/opto/convertnode.cpp#l253
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/2c3c43037e14/src/share/vm/opto/castnode.cpp#l251
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/2c3c43037e14/src/share/vm/opto/loopnode.cpp#l950
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/2c3c43037e14/src/share/vm/opto/opaquenode.cpp#l37

- If _major_progress *is not set*, the compiler is allowed to perform 
all possible transformations (because it does not have to care about 
future loop optimizations).

The crash reported for the current issue appears because _major_progress 
*can be accidentally set again* after the compiler decided to stop 
performing loop optimizations. As a result, invalid graph shapes appear.

Here are details about how this happens for both failures I've been 
studying:
https://bugs.openjdk.java.net/browse/JDK-8148754?focusedCommentId=13901941&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13901941

I would propose to change the compiler to use _major_progress 
consistently. (This goes into the same direction as Tobias's recent work 
on JDK-8144487.)

I propose that _major_progress:
- can be SET when the compiler is initialized (because loop 
optimizations are expected to happen afterwards);
- can be SET/RESET in the scope of loop optimizations (because we want 
to see if loop optimizations made progress);
- cannot be SET/RESET by neither incremental inlining nor IGVN (even if 
the IGVN is performed in the scope of loop optimizations).

Here is the updated webrev:
http://cr.openjdk.java.net/~zmajo/8148754/webrev.02/

Performance evaluation:
- The proposed webrev does not cause performance regressions for 
SPECjvm2008, SPECjbb2005, and Octane.

Testing:
- all hotspot JTREG tests on all supported platforms;
- JPRT;
- failing test case.

Thank you and best regards,


Zoltan


>
> Bailout unrolling is fine but performance may suffer because in some 
> cases loop unrolling is better then split-if.


>
> Thanks,
> Vladimir
>
> On 2/15/16 7:22 AM, Zolt?n Maj? wrote:
>> Hi,
>>
>>
>> please review the patch for 8148754.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8148754
>>
>> Problem: Compilation fails when the C2 compiler attempts loop unrolling.
>> The cause of the failure is that the loop unrolling optimization expects
>> a well-defined graph shape at the entry control of a 'CountedLoopNode'
>> ('IfTrue'/'IfFalse' preceeded by 'If' preceeded by 'Bool' preceeded by
>> 'CmpI').
>>
>>
>> Solution: I investigated several different instances of the same
>> failure. It turns out that the shape of the graph at a loop's entry
>> control is often different from the way loop unrolling expects it to be
>> (please find some examples in the bug's JBS issue). The various graph
>> shapes are a result of previously performed transformations, e.g.,
>> split-if optimization and loop peeling.
>>
>> Loop unrolling requires the above mentioned graph shape so that it can
>> adjust the zero-trip guard of the loop. With the unexpected graph
>> shapes, it is not possible to perform loop unrolling. However, the graph
>> is still in a valid state (except for loop unrolling) and can be used to
>> produce correct code.
>>
>> I propose that (1) we check if an unexpected graph shape is encountered
>> and (2) bail out of loop unrolling if it is (but not fail in the
>> compiler in such cases).
>>
>> The failure was triggered by Aleksey's Indify String Concatenation
>> changes but the generated bytecodes are valid. So this seems to be a
>> compiler issue that was previously there but was not yet triggered.
>>
>>
>> Webrev:
>> http://cr.openjdk.java.net/~zmajo/8148754/webrev.00/
>>
>> Testing:
>> - JPRT;
>> - local testing (linux-86_64) with the failing test case;
>> - executed all hotspot tests locally, all tests pass that pass with an
>> unmodified build.
>>
>> Thank you!
>>
>> Best regards,
>>
>>
>> Zoltan
>>


From nils.eliasson at oracle.com  Mon Feb 22 15:00:54 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 22 Feb 2016 16:00:54 +0100
Subject: RFR (S): 8148563:
	compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java timesout
In-Reply-To: <56C85B32.4040405@oracle.com>
References: <47423DF0-C7C7-4053-BEC0-1D12A558E982@oracle.com>
	<56C77EFA.1060702@oracle.com> <56C85B32.4040405@oracle.com>
Message-ID: <56CB22A6.2090502@oracle.com>

Hi,

I posted my own webrev for the same issue before reading this thread. I 
didn't see when the bug changed owner.

My reflections are:

1) The sequantial test is redudant - the multi version tests everything.
2) Very good that you added more that just the add command!
3) Making this test run for 120 second is way too much in my opinion. 20 
seconds should be more than enough each night. We are testing a stack 
guarded by a lock.
4) Are you sure "Runtime.getRuntime().availableProcessors()" don't 
return all processors on a system (regardless of how many our image are 
allowed to use). I would limit to four threads or so - just to make sure 
there are possibilities for concurrent operations.

Best regards,
Nils Eliasson


On 2016-02-20 13:25, Pavel Punegov wrote:
> Vladimir,
>
> Test generated 5 directives of size 1000 directives before.
> Previously test added them to directives stack one after another, 
> making VM fail with native OOM (JDK-8144246 
> ). 
> CompilerDirectivesLimit flag was added with default value of 50. Since 
> that test began to add directives on the stack failing every time.
>
> I changed the test to create only one file (999 directives) to reach 
> the limit of 1000 (set by option). So it still can try to add 
> directives over the limit, but it also executes other commands like 
> "clear", "remove" and "print".
>
> Added Nils to CC. Nils, could you please take a look also?
>
> On 19.02.2016 23:45, Vladimir Kozlov wrote:
>> Seems fine. What size of directive files was before and after this 
>> fix? JBS does not have this information.
>>
>> Thanks,
>> Vladimir
>>
>> On 2/19/16 9:04 AM, Pavel Punegov wrote:
>>> Hi,
>>>
>>> please review the fix for a test bug.
>>>
>>> Issue:
>>> 1. Test timeouts because it executes a lot of jcmd processes. Number of
>>> threads is calculated as number of processors (cores) * 10, that led to
>>> an enormous number of jcmds executed on hosts with lots of CPUs/cores.
>>> 2. Test also spends a lot of time to generate 5 huge directive files,
>>> that were tried to be added on to the directives stack. Directive stack
>>> has a limit (default 50, controlled by CompilerDirectivesLimit).
>>>
>>> Fix:
>>> 1. Calculate number of threads as a log of the number of CPUs/cores 
>>> * 10.
>>> 2. Generate only one file that is less than specified
>>> CompilerDirectivesLimit.
>>> 3. Add different commands to execute (add, clear, remove and print) and
>>> generate them on demand.
>>>
>>> webrev: http://cr.openjdk.java.net/~ppunegov/8148563/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8148563
>>>
>>> ? Pavel.
>>>
>
> -- 
> Thanks,
> Pavel Punegov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From paul.sandoz at oracle.com  Mon Feb 22 16:07:55 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 22 Feb 2016 17:07:55 +0100
Subject: [9] RFR (M): 8143407: C1: @Stable array support
In-Reply-To: <56C7602B.3090300@oracle.com>
References: <56C7602B.3090300@oracle.com>
Message-ID: <129D16D1-B64C-497C-8570-ED97E535BE08@oracle.com>


> On 19 Feb 2016, at 19:34, Vladimir Ivanov  wrote:
> 
> http://cr.openjdk.java.net/~vlivanov/8143407/webrev.01
> https://bugs.openjdk.java.net/browse/JDK-8143407
> 
> Add C1 support for constant folding loads from @Stable arrays.
> It aligns C1 & C2 behavior w.r.t. @Stable fields and was requested for VarHandles [1] implementation.
> 

Many thanks for doing this.

I gave the patch a test run on x86 with a modified VarHandles impl, collapsing if/else over enum ordinals to stable array access. All tests pass and i observed no performance regression. More importantly, with a future internal refactor to VHs, i can push some casting functionality up from the access implementations into more general code, making things safer.

Paul.

> I introduced StableArrayConstant to track stable array dimension.
> 
> It is needed to disambiguate the following cases:
> (1) @Stable int[][][] intArr = new int[...][...][...];
> (2) @Stable  Object[] objArr = new int[...][...][...];
> 
> In the first case, all elements of multi-dimensional array w/ non-default values are considered constant.
> 
> In the latter, only elements of objArray (which are int[][] instances).
> 
> Testing: unit tests on @Stable support, JPRT.
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] http://openjdk.java.net/jeps/193

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: 

From vladimir.kozlov at oracle.com  Mon Feb 22 18:18:43 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 22 Feb 2016 10:18:43 -0800
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
Message-ID: <56CB5103.6080008@oracle.com>

Use macroassembler instruction signx() for sign extension. Otherwise it 
is good.
Do you know where move32_64() is called from in this case? Compiled code 
should clean upper bits for int arguments.

Thanks,
Vladimir

On 2/22/16 2:05 AM, Roland Westrelin wrote:
> Native code is passed an int (in a 64 bit register) which has some bits set in the upper 32 bit half. The native code uses that value for an address computation. That results in a wrong memory access. From a few experiments with code generated by gcc, it seems it expects values to be clean on function entry. The fix cleans the 32 bit value before the native call.
>
> http://cr.openjdk.java.net/~roland/8148353/webrev.00/
>
> Roland.
>

From christian.thalinger at oracle.com  Mon Feb 22 19:30:39 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 22 Feb 2016 09:30:39 -1000
Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler
	-XX:-EnableJVMCI makes JVM crash
In-Reply-To: <56C8ACA2.5070906@oracle.com>
References: <56BC90DC.10004@oracle.com>
	
	<56BD8DF9.1070605@oracle.com>
	
	<56BE1274.4020506@oracle.com>
	<41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com>
	<56C3221D.2040507@oracle.com> <56C48936.4090303@oracle.com>
	
	<56C5163D.7010208@oracle.com> <56C5F0CA.5010307@oracle.com>
	
	<56C6A6DE.9060806@oracle.com> <56C736DA.304@oracle.com>
	
	<56C7A7F1.3090500@oracle.com> <56C8ACA2.5070906@oracle.com>
Message-ID: <983E70B3-C940-4AAD-A2A3-468AAE6E1047@oracle.com>


> On Feb 20, 2016, at 8:12 AM, Jamsheed C m  wrote:
> 
> Hi Chris,
> 
> I missed handling a valid case where UnlockExperimentalVMOptions/UnlockDiagnosticVMOptions are made false after experimental/diagnostic jvmci flags are modified.
> 
> i.e :  bin/java  -XX:+UnlockExperimentalVMOptions -XX:-EnableJVMCI -XX:+UseJVMCICompiler -XX:-UnlockExperimentalVMOptions -version
> 
> made changes to handle this case.
> 
> code change
> +   // Check consistency of diagnostic flags if UnlockDiagnosticVMOptions is true
> +   // or not default. UnlockDiagnosticVMOptions is default true in debug builds.
> +   if (UnlockDiagnosticVMOptions ||
> +       !FLAG_IS_DEFAULT(UnlockDiagnosticVMOptions)) {
> 
> 
> +   // Check consistency of experimental flags if UnlockExperimentalVMOptions is 
> +   // true or not default.
> +   if (UnlockExperimentalVMOptions ||
> +       !FLAG_IS_DEFAULT(UnlockExperimentalVMOptions)) {

Oh, good.  But please don?t break the line.  No new webrev needed.

> 
> 
> revised webrev: http://cr.openjdk.java.net/~jcm/8145333/webrev.06/ 
> 
> Thanks and Best Regards,
> Jamsheed
> 
> On 2/20/2016 5:10 AM, Jamsheed C m wrote:
>> Thanks, Chris.
>> 
>> Best Regards,
>> Jamsheed
>> 
>> On 2/19/2016 10:56 PM, Christian Thalinger wrote:
>>> Looks good.  Thanks.
>>> 
>>>> On Feb 19, 2016, at 5:38 AM, Jamsheed C m > wrote:
>>>> 
>>>> Hi Chris,
>>>> 
>>>> Made all suggested changes.
>>>> 
>>>> Revised webrev: http://cr.openjdk.java.net/~jcm/8145333/webrev.05/ 
>>>> 
>>>> Thanks and Best Regards,
>>>> Jamsheed
>>>> 
>>>> On 2/19/2016 10:53 AM, Jamsheed C m wrote:
>>>>> 
>>>>> 
>>>>> On 2/18/2016 11:21 PM, Christian Thalinger wrote:
>>>>>> +  if (EnableJVMCI)
>>>>>> +    return true;
>>>>>> 
>>>>>> Please use { } for all if statements.
>>>>> Ok.
>>>>>> 
>>>>>> Thanks for the comments; it?s easier to understand now.  May I suggest to do:
>>>>>> 
>>>>>>   int skip_fail_count;  
>>>>>>   if (!FLAG_IS_DEFAULT(EnableJVMCI)) {
>>>>>>     skip_fail_count = 1;
>>>>>>   } else {
>>>>>>     skip_fail_count = 0;  
>>>>>>   }
>>>>> Ok. 
>>>>> 
>>>>> Best Regards,
>>>>> Jamsheed
>>>>>> 
>>>>>>> On Feb 18, 2016, at 6:26 AM, Jamsheed C m > wrote:
>>>>>>> 
>>>>>>> Hi Chris,
>>>>>>> 
>>>>>>> Made all suggested changes.
>>>>>>> 
>>>>>>> Revised webrev:  http://cr.openjdk.java.net/~thartmann/8145333/webrev.04/ 
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> Jamsheed
>>>>>>> 
>>>>>>> On 2/18/2016 6:24 AM, Jamsheed C m wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 2/18/2016 12:36 AM, Christian Thalinger wrote:
>>>>>>>>> 
>>>>>>>>>> On Feb 17, 2016, at 4:52 AM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote:
>>>>>>>>>> 
>>>>>>>>>> experimental and diagnostic flags are under condition checks now.
>>>>>>>>>> 
>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8145333/webrev.03/ 
>>>>>>>>> 
>>>>>>>>> I?m not very happy about the new macros but I can see why it?s useful.
>>>>>>>>> 
>>>>>>>>> +#if INCLUDE_JVMCI
>>>>>>>>> +
>>>>>>>>> +// Check consistency of jvmci vm argument settings.
>>>>>>>>> +bool Arguments::check_jvmci_args_consistency() {
>>>>>>>>> + 
>>>>>>>>> +
>>>>>>>>> +  if (!EnableJVMCI && is_any_jvmci_arg_values_changed()) { 
>>>>>>>>> +    print_jvmci_arg_inconsistency_error_message(); 
>>>>>>>>> +    return false;
>>>>>>>>> 
>>>>>>>>> Please remove all these empty lines.  There are others as well.
>>>>>>>>> 
>>>>>>>>> +bool is_any_jvmci_arg_values_changed() {  
>>>>>>>>> 
>>>>>>>>> This method needs another name.
>>>>>>>>> 
>>>>>>>> Ok.
>>>>>>>>> +  int check_count = 0, fail_count = 0;
>>>>>>>>> 
>>>>>>>>> I don?t like the check_count/fail_count logic because it?s fragile.
>>>>>>>> As  EanbleJVMCI flag cannot be avoided from macro expansion logic, i had to use some technique to exclude this flag from failure decision making. 
>>>>>>>> Check_count/fail_count logic was added as a solution for this. i.e When EnableJVMCI is changed, code requires at-least 2 check failures to decide a real failure. otherwise one failure is sufficient. 
>>>>>>>>  
>>>>>>>> if i remove this logic, i will have to use strcmp(#FLAG, "EnableJVMCI") which will add a little more instructions that will  execute at-least once for every flag consistent run.
>>>>>>>> 
>>>>>>>> let me know if i need to take second approach. or if existing code is ok.
>>>>>>>>> 
>>>>>>>>> +// Check if any jvmci global defaults changed.
>>>>>>>>> +bool is_any_jvmci_arg_values_changed();
>>>>>>>>> +// Print jvmci args inconsistency error message.
>>>>>>>>> +void print_jvmci_arg_inconsistency_error_message();
>>>>>>>>> 
>>>>>>>>> These should be in some kind of namespace or class.  Maybe put them into: class JVMCIGlobals
>>>>>>>> Ok.
>>>>>>>> 
>>>>>>>> Best Regards,
>>>>>>>> Jamsheed
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Best Regards,
>>>>>>>>>> Jamsheed
>>>>>>>>>> 
>>>>>>>>>> On 2/16/2016 6:50 PM, Jamsheed C m wrote:
>>>>>>>>>>> Hi Chris,
>>>>>>>>>>> 
>>>>>>>>>>> Revised webrev:  http://cr.openjdk.java.net/~thartmann/8145333/webrev.02/ 
>>>>>>>>>>> 
>>>>>>>>>>> This code take care of every jvmci flags automatically.
>>>>>>>>>>> 
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Jamsheed
>>>>>>>>>>> 
>>>>>>>>>>> On 2/13/2016 3:24 AM, Christian Thalinger wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Feb 12, 2016, at 7:12 AM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 2/12/2016 10:12 PM, Christian Thalinger wrote:
>>>>>>>>>>>>>> Well, now you have to manually check all flags that had a constraint directive.  That is the annoying part and what I complained about in:
>>>>>>>>>>>>> check against original value, and if not fail ?
>>>>>>>>>>>> 
>>>>>>>>>>>> Same check for all flags; they all depend on +EnableJVMCI.
>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>  https://bugs.openjdk.java.net/browse/JDK-8145357 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Also, commandLineFlagConstraintsJVMCI.{cpp,hpp} files are now empty and I think we should remove them.
>>>>>>>>>>>>> i kept the file as there can be future use. Ok, i will remove it.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Feb 11, 2016, at 9:47 PM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> revised webrev:  http://cr.openjdk.java.net/~thartmann/8145333/webrev.01/ 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 2/11/2016 11:31 PM, Christian Thalinger wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Feb 11, 2016, at 3:47 AM, Jamsheed C m < jamsheed.c.m at oracle.com > wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Request for review
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> bug url:   https://bugs.openjdk.java.net/browse/JDK-8145333 
>>>>>>>>>>>>>>>>> web url:  http://cr.openjdk.java.net/~thartmann/8145333/webrev.00/ 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> That looks alright but we should remove the constraints from all the JVMCI command line flags because the way we use them is not supported.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Also, can you change the error message?  Right now it looks like this:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> $ ./build/macosx-x86_64-normal-server-release/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler
>>>>>>>>>>>>>>>> EnableJVMCI must be enabled
>>>>>>>>>>>>>>>> Improperly specified VM option 'UseJVMCICompiler'
>>>>>>>>>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>>>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I think with your changes we will only see the first line without mentioning UseJVMCICompiler.  Is that correct?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Fix Summary: added jvmci flag consistency check after arg parsing.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> tests: jprt
>>>>>>>>>>>>>>>>> unit test: command line verification
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>> Jamsheed
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From christian.thalinger at oracle.com  Mon Feb 22 19:33:37 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 22 Feb 2016 09:33:37 -1000
Subject: [9] RFR JDK-8141616: Add new methods to the java Whitebox API
In-Reply-To: <56C47B59.5090606@oracle.com>
References: <56C47B59.5090606@oracle.com>
Message-ID: 

+WB_ENTRY(jint, WB_GetConstantPoolCacheLength(JNIEnv* env, jobject wb, jclass klass))
+  instanceKlassHandle ikh(java_lang_Class::as_Klass(JNIHandles::resolve(klass)));
+  ConstantPool* cp = ikh->constants();
+  if (cp->cache() == NULL) {
+      return -1;
+  }

Shouldn?t this throw an exception like in the other methods?

> On Feb 17, 2016, at 3:53 AM, Konstantin Shefov  wrote:
> 
> Hello
> 
> Please review some new methods added to the sun.hotspot.WhiteBox API.
> These methods are needed to test JVMCI CompilerToVM methods, see https://bugs.openjdk.java.net/browse/JDK-8138708 for more info.
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8141616
> Webrev for java part: http://cr.openjdk.java.net/~kshefov/8141616/root/webrev.00/
> Webrev for native part: http://cr.openjdk.java.net/~kshefov/8141616/hotspot/webrev.00/
> 
> Thanks
> -Konstantin


From christian.thalinger at oracle.com  Mon Feb 22 19:39:40 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 22 Feb 2016 09:39:40 -1000
Subject: RFR (S): 8067014: LinearScan::is_sorted significantly slows down
	fastdebug builds' performance
In-Reply-To: 
References: 
	<54F99281.7020101@oracle.com>
	
	
	<56B489D0.3070700@oracle.com>
	
	
	<56BDCF17.30308@oracle.com>
	
	
	<56C5EC68.5010003@oracle.com>
	
Message-ID: 


> On Feb 18, 2016, at 10:05 PM, Filipp Zhinkin  wrote:
> 
> Hi Vladimir,
> 
> On Thu, Feb 18, 2016 at 7:08 PM, Vladimir Ivanov
>  wrote:
>> Thanks, Filipp.
>> 
>> I suggest to address CommentedAssembly separately.
>> 
>> One question: why don't you simply typedef IntervalArray/IntervalList to
>> GrowableArray? It will eliminate numerous renamings you did.
> 
> Well, I'd prefer to explicitly declare type (unless there are numerous
> nested template args).
> But I'm fine with using typedef there.

Please don?t.  There is no good reason to use a typedef and it?s just confusing to the reader.  To avoid renaming changes should never be a reason for not doing something.

> 
> Here is updated webrev:
> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.03/
> 
> Thanks,
> Filipp.
> 
>> 
>> Otherwise, looks good.
>> 
>> Best regards,
>> Vladimir Ivanov
>> 
>> 
>> On 2/18/16 6:31 PM, Filipp Zhinkin wrote:
>>> 
>>> Hi,
>>> 
>>> I've looked at how frequently misses are actually occur and
>>> how far false positives are from the interval we're looking for.
>>> 
>>> Also I've tried to implement interval_cmp so that it returns 0
>>> if difference between interval "from" values is below some threshold:
>>> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/stats.txt
>>> 
>>> All those misses with distance greater than 64 came from
>>> javax.swing.plaf.synth.SynthStyle::populateDefaultValues [1].
>>> 
>>> I've also looked to another possible slowness sources and
>>> we spend about 10% of time in LinearScan's verify_intervals method
>>> which checks that every two intervals don't simultaneously intersect
>>> and share the same register [2].
>>> 
>>> I don't see a way to significantly speed up such verification,
>>> but I've slightly improved performance by rearranging some expressions.
>>> 
>>> Here is an updated webrev:
>>> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.02/
>>> 
>>> Also, unless CommentedAssembly flag is explicitly turned off,
>>> we're generating comments for stubs even if we're not going to print it
>>> out.
>>> Avoiding comments generation in such case will speed up compilation a bit
>>> more,
>>> but I think it would be better to deal with it in a separate RFE.
>>> Difference in code emission time is about 30% when CommentedAssembly is
>>> off
>>> (~ 40s w/ CommentedAssembly, ~ 25s w/o CommentedAssembly).
>>> 
>>> [1]
>>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/file/6c649a7ac744/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthStyle.java#l68
>>> [2]
>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/cffca6de2c45/src/share/vm/c1/c1_LinearScan.cpp#l3226
>>> 
>>> On Fri, Feb 12, 2016 at 7:08 PM, Filipp Zhinkin
>>>  wrote:
>>>> 
>>>> Hi Aleksey,
>>>> 
>>>> On Fri, Feb 12, 2016 at 3:24 PM, Aleksey Shipilev
>>>>  wrote:
>>>>> 
>>>>> Hi Filipp,
>>>>> 
>>>>> On 02/12/2016 02:47 PM, Filipp Zhinkin wrote:
>>>>>> 
>>>>>> here is a new webrev:
>>>>>> http://cr.openjdk.java.net/~fzhinkin/8067014/webrev.01/
>>>>> 
>>>>> 
>>>>> The webrev seems incomplete: it has only hotspot.patch in it, but no
>>>>> other views?
>>>> 
>>>> 
>>>> It seems like only wdiff's are empty for some reason.
>>>> What else is missed out there?
>>>> 
>>>>> 
>>>>> I wonder how many intervals have the same "from", prompting you to
>>>>> wiggle around looking for the exact interval?
>>>> 
>>>> 
>>>> Well, there should be (relatively) many intervals with "from" == 0
>>>> created for physical registers.
>>>> For virtual registers there could be few intervals that share the same
>>>> "from" value:
>>>> it depends on amount of temporary registers required by an operation
>>>> and amount of outputs it produces.
>>>> 
>>>> So we may simply scan intervals from beginning if key's from value is 0.
>>>> 
>>>>> Can we define
>>>>> "interval_cmp" so that "(interval_cmp(i1, i2) == 0) iff (i1 == i2)",
>>>> 
>>>> 
>>>> No, unfortunately we can't, because intervals are ordered only by "from"
>>>> value.
>>>> 
>>>>> or at least make the false positives less frequent with more extensive
>>>>> interval key (assuming collisions are indeed problematic)?
>>>>> 
>>>> 
>>>> Not sure that I've got you.
>>>> 
>>>> Nevertheless, I'll run CTW and check how many false positives are
>>>> actually found.
>>>> 
>>>>> 
>>>>>> I've hacked VM sources a bit to run CTW with product bits and C1
>>>>>> compilation time on my x86_64 linux laptop
>>>>>> slowed down by 0.4% (from 51029 ? 306 ms to 51230 ? 293 ms). Please
>>>>>> let me know if it too slow.
>>>>> 
>>>>> 
>>>>> I think this is within the error margin, and therefore statistically
>>>>> insignificant. Even if it was significant, 0.4% is okay for compilation
>>>>> time regression in C1.
>>>>> 
>>>>>> With fastdebug bits provided patch allow to reduce C1 compilation time
>>>>>> twice.
>>>>> 
>>>>> 
>>>>> This is a very good improvement, but we need to see if that's the end of
>>>>> it, or we can squeeze even more with a few changes. I would suggest
>>>>> running the CTW scenario under Solaris Studio Performance Analyzer (see
>>>>> e.g.
>>>>> 
>>>>> http://shipilev.net/blog/2016/arrays-wisdom-ancients/#_meet_solaris_studio_performance_analyzer).
>>>> 
>>>> 
>>>> Thank you for the suggestion, I'll check it.
>>>> 
>>>> Regards,
>>>> Filipp.
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> -Aleksey
>>>>> 
>>>>> 
>> 


From edward.nevill at gmail.com  Mon Feb 22 20:32:10 2016
From: edward.nevill at gmail.com (Edward Nevill)
Date: Mon, 22 Feb 2016 20:32:10 +0000
Subject: RFR: 8150394: aarch64: add support for 8.1 LSE CAS instructions
Message-ID: <1456173130.2735.8.camel@mint>

Hi,

Please review the following webrev

http://cr.openjdk.java.net/~enevill/8150394/webrev.0/

This adds support for the CAS instructions in armv8.1.

The use of the instructions is enabled/disabled by the use of -XX:+/-UseLSE. This is enabled automatically if detected in the hwcap. If UseLSE is enabled on a CPU which does not support these instructions a warning is issued but the instructions are enabled in any case. This is to allow use of the LSE extensions on 8.1 systems which are running older kernels.

Tested before and after with jcstress (default mode). In both cases there was 1 failure which is due to a missing Unsafe method and always occurs with jdk9.

Thanks for the review,
Ed.



From dean.long at oracle.com  Mon Feb 22 21:53:09 2016
From: dean.long at oracle.com (Dean Long)
Date: Mon, 22 Feb 2016 13:53:09 -0800
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
Message-ID: <56CB8345.5020203@oracle.com>

How does this relate to CCallingConventionRequiresIntsAsLongs?  Can you 
just set it to true for Sparc?  It seems like fixing a similar issue on 
ppc64 required a lot more changes, so I'm concerned we might be missing 
something.

dl

On 2/22/2016 2:05 AM, Roland Westrelin wrote:
> Native code is passed an int (in a 64 bit register) which has some bits set in the upper 32 bit half. The native code uses that value for an address computation. That results in a wrong memory access. From a few experiments with code generated by gcc, it seems it expects values to be clean on function entry. The fix cleans the 32 bit value before the native call.
>
> http://cr.openjdk.java.net/~roland/8148353/webrev.00/
>
> Roland.


From dean.long at oracle.com  Mon Feb 22 22:02:33 2016
From: dean.long at oracle.com (Dean Long)
Date: Mon, 22 Feb 2016 14:02:33 -0800
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: <56CB8345.5020203@oracle.com>
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
	<56CB8345.5020203@oracle.com>
Message-ID: <56CB8579.4060102@oracle.com>

And is this a duplicate of 8056950?

dl

On 2/22/2016 1:53 PM, Dean Long wrote:
> How does this relate to CCallingConventionRequiresIntsAsLongs?  Can 
> you just set it to true for Sparc?  It seems like fixing a similar 
> issue on ppc64 required a lot more changes, so I'm concerned we might 
> be missing something.
>
> dl
>
> On 2/22/2016 2:05 AM, Roland Westrelin wrote:
>> Native code is passed an int (in a 64 bit register) which has some 
>> bits set in the upper 32 bit half. The native code uses that value 
>> for an address computation. That results in a wrong memory access. 
>> From a few experiments with code generated by gcc, it seems it 
>> expects values to be clean on function entry. The fix cleans the 32 
>> bit value before the native call.
>>
>> http://cr.openjdk.java.net/~roland/8148353/webrev.00/
>>
>> Roland.
>


From dean.long at oracle.com  Mon Feb 22 22:31:35 2016
From: dean.long at oracle.com (Dean Long)
Date: Mon, 22 Feb 2016 14:31:35 -0800
Subject: RFR (XXS) 8066292: Test java/nio/file/Files/CheckPermissions.java
	triggers stack overflow with -server -Xcomp
Message-ID: <56CB8C47.8030200@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8066292

http://cr.openjdk.java.net/~dlong/8066292/webrev/

With -Xcomp, a cycle between compile requests and class loading can 
cause infinite recursion resulting in StackOverflowError's that are 
silently ignored.  To break the cycle, this changeset removes the 
ancient call to Method::load_signature_classes() for C2.  This call is 
no longer needed.

Tested in RBT with --test 
vm.compiler.testlist,hotspot/test/:hotspot_compiler_closed,hotspot/test/:hotspot_compiler_1,hotspot/test/:hotspot_compiler_2,hotspot/test/:hotspot_compiler_3

dl

From jamsheed.c.m at oracle.com  Tue Feb 23 06:07:45 2016
From: jamsheed.c.m at oracle.com (Jamsheed C m)
Date: Tue, 23 Feb 2016 11:37:45 +0530
Subject: RFR(XS): 8145333: -XX:+EnableJVMCI -XX:+UseJVMCICompiler
	-XX:-EnableJVMCI makes JVM crash
In-Reply-To: <983E70B3-C940-4AAD-A2A3-468AAE6E1047@oracle.com>
References: <56BC90DC.10004@oracle.com>
	
	<56BD8DF9.1070605@oracle.com>
	
	<56BE1274.4020506@oracle.com>
	<41CB30DB-33EE-4478-9EF8-57BF70CF6379@oracle.com>
	<56C3221D.2040507@oracle.com> <56C48936.4090303@oracle.com>
	
	<56C5163D.7010208@oracle.com> <56C5F0CA.5010307@oracle.com>
	
	<56C6A6DE.9060806@oracle.com> <56C736DA.304@oracle.com>
	
	<56C7A7F1.3090500@oracle.com> <56C8ACA2.5070906@oracle.com>
	<983E70B3-C940-4AAD-A2A3-468AAE6E1047@oracle.com>
Message-ID: <56CBF731.5020905@oracle.com>



On 2/23/2016 1:00 AM, Christian Thalinger wrote:
>> + // Check consistency of diagnostic flags if 
>> UnlockDiagnosticVMOptions is true
>> + // or not default. UnlockDiagnosticVMOptions is default true in 
>> debug builds.
>> + if (UnlockDiagnosticVMOptions ||
>> + !FLAG_IS_DEFAULT(UnlockDiagnosticVMOptions)) { + // Check 
>> consistency of experimental flags if UnlockExperimentalVMOptions is
>> + // true or not default.
>> + if (UnlockExperimentalVMOptions ||
>> + !FLAG_IS_DEFAULT(UnlockExperimentalVMOptions)) {
>
> Oh, good.  But please don?t break the line.  No new webrev needed.

Thanks, Chris!

Best Regards,
Jamsheed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From roland.westrelin at oracle.com  Tue Feb 23 09:25:25 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 23 Feb 2016 10:25:25 +0100
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: <56CB5103.6080008@oracle.com>
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
	<56CB5103.6080008@oracle.com>
Message-ID: <679E5C4D-E790-4316-8AB5-BEE8D7BBF234@oracle.com>

Thanks for looking at this, Vladimir.

> Use macroassembler instruction signx() for sign extension. Otherwise it is good.

Ok.

> Do you know where move32_64() is called from in this case? Compiled code should clean upper bits for int arguments.

If you look at the jtreg test case, c2 compiles the ?compiled? method as:

000   B1: # B3 B2 <- BLOCK HEAD IS JUNK   Freq: 1
000        ! stack bang (272 bytes)
        SAVE   R_SP,-144,R_SP
014        SLL    R_I0,#2,R_O0
018          CALL,static  ; NOP ==>  TestDirtyInt::test
        # TestDirtyInt::compiled @ bci:3  L[0]=_
        # OopMap{off=32}
020
020   B2: #        N1 <- B1  Freq: 0.99998
        # Block is sole successor of call
020 +   MOV    R_O0,R_I0        ! spill
024 +    SETHI  #PollAddr,L0     ! Load Polling address
  LDX    [L0],G0  !Poll for Safepointing
  RET
     RESTORE
038 +    ! return
038
038   B3: #  N1 <- B1  Freq: 1e-05
038        ! exception oop is in R_O0; no code emitted
038 +        MOV    R_O0,R_I0        ! spill
03c +    RESTORE
040 +    Jmp    rethrow_stub
040

so c2 doesn't clean the upper bits before the native call. move32_64 is then called by the compiled native wrapper on the int method argument.

Roland.

> 
> Thanks,
> Vladimir
> 
> On 2/22/16 2:05 AM, Roland Westrelin wrote:
>> Native code is passed an int (in a 64 bit register) which has some bits set in the upper 32 bit half. The native code uses that value for an address computation. That results in a wrong memory access. From a few experiments with code generated by gcc, it seems it expects values to be clean on function entry. The fix cleans the 32 bit value before the native call.
>> 
>> http://cr.openjdk.java.net/~roland/8148353/webrev.00/
>> 
>> Roland.
>> 


From aleksey.shipilev at oracle.com  Tue Feb 23 10:01:28 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 23 Feb 2016 13:01:28 +0300
Subject: RFR: 8149733: AArch64: refactor
	char_array_equals/byte_array_equals/string_equals
In-Reply-To: 
References: 
	<56C70C42.5020309@oracle.com>
	
Message-ID: <56CC2DF8.60806@oracle.com>

On 02/22/2016 02:56 PM, Hui Shi wrote:
> Thanks Aleksey & Andrew!
> 
> Patch is updated in http://cr.openjdk.java.net/~hshi/8149733/webrev2/
>  , it adds on
> 1. Fix misc spelling and format issues
> 2. Use cnt2 for array length compare, comment that cnt2 can?t be used
> after length compare
> 3. Add more comments for tail handling

Still not getting this part:

4526   cmp(ary1, ary2);
4527   mov(result, false);
4528   br(Assembler::EQ, SAME);

Should the mov be *after* the branch?

Also, "if (is_string_equal == false) {" should be "if (!is_string_equals)".

> JMH test
> in http://cr.openjdk.java.net/~hshi/8149733/webrev2/JMHSample_97_ArrayEqual.java
> 
> . Run with java -jar ../benchmarks.jar '.*JMHSample_97*' -w 5 -wi 3 -i 5
> -r 10 -f 0 

Um, -f 0 is bad: you contaminate the profiles. Also, the benchmark could
be made much more idiomatic, solving a few other benchmarking pitfalls:
  http://cr.openjdk.java.net/~shade/scratch/ByteArrayEquals.java

You might want to re-run with your updated code.

Cheers,
-Aleksey



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From aleksey.shipilev at oracle.com  Tue Feb 23 10:24:41 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 23 Feb 2016 13:24:41 +0300
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56C729D3.80404@oracle.com>
References: <56C702B6.5010903@oracle.com> <56C70DAA.6000806@oracle.com>
	<56C72407.2070301@oracle.com> <56C729D3.80404@oracle.com>
Message-ID: <56CC3369.2000804@oracle.com>

On 02/19/2016 05:42 PM, Vladimir Ivanov wrote:
>>    http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/
>>    http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/
> Looks good.

A few more reviews, please?

Cheers,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From hui.shi at linaro.org  Tue Feb 23 11:33:55 2016
From: hui.shi at linaro.org (=?utf-8?B?aHVpLnNoaQ==?=)
Date: Tue, 23 Feb 2016 19:33:55 +0800
Subject: =?utf-8?B?5Zue5aSN77yaUkZSOiA4MTQ5NzMzOiBBQXJjaDY0?=
	=?utf-8?B?OiByZWZhY3RvcmNoYXJfYXJyYXlfZXF1YWxzL2J5?=
	=?utf-8?B?dGVfYXJyYXlfZXF1YWxzL3N0cmluZ19lcXVhbHM=?=
References: <56CC2DF8.60806@oracle.com><56C70C42.5020309@oracle.com>

An HTML attachment was scrubbed...
URL: 

From roland.westrelin at oracle.com  Tue Feb 23 12:54:58 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 23 Feb 2016 13:54:58 +0100
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: <56CB8345.5020203@oracle.com>
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
	<56CB8345.5020203@oracle.com>
Message-ID: 

Hi Dean,

> How does this relate to CCallingConventionRequiresIntsAsLongs?  Can you just set it to true for Sparc?  It seems like fixing a similar issue on ppc64 required a lot more changes, so I'm concerned we might be missing something.

That sounds like a good suggestion. Here is a new webrev:

http://cr.openjdk.java.net/~roland/8148353/webrev.01/

Roland.

From roland.westrelin at oracle.com  Tue Feb 23 13:01:31 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 23 Feb 2016 14:01:31 +0100
Subject: RFR(S): 8007986: GrowableArray should implement binary search
In-Reply-To: 
References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com>
	
	
	
	<740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com>
	
	
	
	<4509C310-E616-4B6E-A1A0-7E30070F8CBA@oracle.com>
	
Message-ID: <3CEEE098-94B7-4736-9714-6E0CA3D8EA29@oracle.com>


I haven?t anything more on this so I?m pushing it. Thanks for looking at this John & Vladimir.

Roland.

> On Feb 12, 2016, at 4:31 PM, Roland Westrelin  wrote:
> 
> Hi John,
> 
> Thanks for looking at this.
> 
>>> overflow issue in the binary search 
>> 
>> The outer parens look wrong on the fix.  You want to cast to int *after* dividing by two, I think.
> 
> You?re right obviously. Is it good to go if I add the missing parentheses?
> 
> int mid = (int)(((uint)max + min) / 2);
> 
> Roland.
> 
> 


From aph at redhat.com  Tue Feb 23 13:28:40 2016
From: aph at redhat.com (Andrew Haley)
Date: Tue, 23 Feb 2016 13:28:40 +0000
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJGUjogODE0OTczMzogQUFyY2g2NDogcmVmYWN0?=
	=?UTF-8?Q?orchar=5farray=5fequals/byte=5farray=5fequals/string=5fequals?=
In-Reply-To: 
References: <56CC2DF8.60806@oracle.com>
	
	<56C70C42.5020309@oracle.com> 
Message-ID: <56CC5E88.7040309@redhat.com>

On 02/23/2016 11:33 AM, hui.shi wrote:
> thanks! I will update and rerun JMH.

I want to make some changes.  Please wait until then.

Thanks,

Andrew.


From claes.redestad at oracle.com  Tue Feb 23 14:39:24 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 23 Feb 2016 15:39:24 +0100
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56CC3369.2000804@oracle.com>
References: <56C702B6.5010903@oracle.com> <56C70DAA.6000806@oracle.com>
	<56C72407.2070301@oracle.com> <56C729D3.80404@oracle.com>
	<56CC3369.2000804@oracle.com>
Message-ID: <56CC6F1C.2050207@oracle.com>

Looks good to me, but I assume you mean to push 
http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.02 (which looks 
even better)?

Thanks!

/Claes

On 2016-02-23 11:24, Aleksey Shipilev wrote:
> On 02/19/2016 05:42 PM, Vladimir Ivanov wrote:
>>>     http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/
>>>     http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/
>> Looks good.
> A few more reviews, please?
>
> Cheers,
> -Aleksey
>
>


From aleksey.shipilev at oracle.com  Tue Feb 23 14:52:12 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 23 Feb 2016 17:52:12 +0300
Subject: RFR (S) 8150180: String.value contents should be trusted
In-Reply-To: <56CC6F1C.2050207@oracle.com>
References: <56C702B6.5010903@oracle.com> <56C70DAA.6000806@oracle.com>
	<56C72407.2070301@oracle.com> <56C729D3.80404@oracle.com>
	<56CC3369.2000804@oracle.com> <56CC6F1C.2050207@oracle.com>
Message-ID: <56CC721C.7070008@oracle.com>

Yes, sorry, pushing these two:
  http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.02
  http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/

-Aleksey

On 02/23/2016 05:39 PM, Claes Redestad wrote:
> Looks good to me, but I assume you mean to push
> http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.02 (which looks
> even better)?
> 
> Thanks!
> 
> /Claes
> 
> On 2016-02-23 11:24, Aleksey Shipilev wrote:
>> On 02/19/2016 05:42 PM, Vladimir Ivanov wrote:
>>>>     http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/
>>>>     http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/
>>> Looks good.
>> A few more reviews, please?
>>
>> Cheers,
>> -Aleksey
>>
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From nils.eliasson at oracle.com  Tue Feb 23 15:16:09 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 23 Feb 2016 16:16:09 +0100
Subject: RFR(S): 8149789: SIGSEGV in CompileTask::print
Message-ID: <56CC77B9.8030003@oracle.com>

Hi,

Summary:
In bug JDK-8063112 I removed the vm_operation from some compiler 
diagnostic commands. That was ok, but I also added printing of the 
threads with active compile tasks in the Compiler.queue command. That 
printing is not safe. In this crash a compiler thread finishes compiling 
a task while the diagnostic command is printing the tasks.

Solution:
Make this diagnostic command require a safepoint - then it will have to 
block until no compiler threads are running in the compileBroker 
(possibly freeing tasks). When the safepoint is reached, it is safe to 
print the tasks, since then no compile threads can reach the state where 
tasks are freed without blocking.

Testing:
Running the repro in the bug + dedicated jcmd Compiler.queue test.

Webrev: http://cr.openjdk.java.net/~neliasso/8149789/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8149789

Please review!

Best regards,
Nils Eliasson

From aph at redhat.com  Tue Feb 23 16:17:52 2016
From: aph at redhat.com (Andrew Haley)
Date: Tue, 23 Feb 2016 16:17:52 +0000
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJGUjogODE0OTczMzogQUFyY2g2NDogcmVmYWN0?=
	=?UTF-8?Q?orchar=5farray=5fequals/byte=5farray=5fequals/string=5fequals?=
In-Reply-To: 
References: <56CC2DF8.60806@oracle.com>
	
	<56C70C42.5020309@oracle.com> 
Message-ID: <56CC8630.2020708@redhat.com>

My version is at

http://cr.openjdk.java.net/~aph/8149733/

The changes I made are:

        I rewrote most of the comments because I couldn't understand
        them.  I intend no criticism, and I understand that English
        isn't the language of your birth.  Please tell me if you can
        understand my comments.

	"generic_array_equals" -> "arrays_equals"
        Reason: it's not generic, it's only bytes and chars.
        Also, this is what x86_64 calls the same routine.

        "ary1" -> "a"
        Reason: "ary" just looks odd.  Also, these are the names in the
	java code.

        "cmp; br.nz" -> "eor, bnz"
        Reason: Don't clobber flags for no reason.

        There's no need to check for the same arrays if we're
        comparing strings.

Otherwise, the code is the same.  I haven't much tested this, but it
should give the same performance.  Please test it, and tell me if I've
broken anything.

Thanks,

Andrew.

From roland.westrelin at oracle.com  Tue Feb 23 16:28:01 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 23 Feb 2016 17:28:01 +0100
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: 
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
	<56CB8345.5020203@oracle.com>
	
Message-ID: <2502DFC4-B50D-44E9-BF63-12FBDF308423@oracle.com>

Another webrev because using L5 is not necessary when the argument is moved from register to register:

http://cr.openjdk.java.net/~roland/8148353/webrev.02/

Roland.

From john.r.rose at oracle.com  Tue Feb 23 21:05:46 2016
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 23 Feb 2016 13:05:46 -0800
Subject: RFR(S): 8007986: GrowableArray should implement binary search
In-Reply-To: <3CEEE098-94B7-4736-9714-6E0CA3D8EA29@oracle.com>
References: <7F49BA10-F7B2-45BC-83F1-FE770672C3E4@oracle.com>
	
	
	
	<740C04B7-7487-47E8-BD14-3EBAAD22CB76@oracle.com>
	
	
	
	<4509C310-E616-4B6E-A1A0-7E30070F8CBA@oracle.com>
	
	<3CEEE098-94B7-4736-9714-6E0CA3D8EA29@oracle.com>
Message-ID: <3E8399E5-A6C4-402E-8C61-33636A842A12@oracle.com>

+1  Thanks, Roland.

> On Feb 23, 2016, at 5:01 AM, Roland Westrelin  wrote:
> 
> 
> I haven?t anything more on this so I?m pushing it. Thanks for looking at this John & Vladimir.
> 
> Roland.
> 
>> On Feb 12, 2016, at 4:31 PM, Roland Westrelin  wrote:
>> 
>> Hi John,
>> 
>> Thanks for looking at this.
>> 
>>>> overflow issue in the binary search 
>>> 
>>> The outer parens look wrong on the fix.  You want to cast to int *after* dividing by two, I think.
>> 
>> You?re right obviously. Is it good to go if I add the missing parentheses?
>> 
>> int mid = (int)(((uint)max + min) / 2);
>> 
>> Roland.
>> 
>> 
> 


From vladimir.kozlov at oracle.com  Tue Feb 23 21:32:10 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Feb 2016 13:32:10 -0800
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: <2502DFC4-B50D-44E9-BF63-12FBDF308423@oracle.com>
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
	<56CB8345.5020203@oracle.com>
	
	<2502DFC4-B50D-44E9-BF63-12FBDF308423@oracle.com>
Message-ID: <56CCCFDA.6030902@oracle.com>

Code in sharedRuntime_sparc.cpp looks fine but I am worry about CCallingConventionRequiresIntsAsLongs change. You get 
additional slots on stack which is not expected on sparc:
     if (CCallingConventionRequiresIntsAsLongs && f->isa_int()) {
       fields[cnt++] = TypeLong::LONG;
       fields[cnt] = Type::HALF; // Must add an additional half for a long.

I found next text which says that integer values takes one stack slot only (but it does requires sign extension to 64 bits):
https://docs.oracle.com/cd/E26502_01/html/E28387/gentextid-2734.html#scrolltoc

Thanks,
Vladimir

On 2/23/16 8:28 AM, Roland Westrelin wrote:
> Another webrev because using L5 is not necessary when the argument is moved from register to register:
>
> http://cr.openjdk.java.net/~roland/8148353/webrev.02/
>
> Roland.
>

From dean.long at oracle.com  Tue Feb 23 21:46:05 2016
From: dean.long at oracle.com (Dean Long)
Date: Tue, 23 Feb 2016 13:46:05 -0800
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: <2502DFC4-B50D-44E9-BF63-12FBDF308423@oracle.com>
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
	<56CB8345.5020203@oracle.com>
	
	<2502DFC4-B50D-44E9-BF63-12FBDF308423@oracle.com>
Message-ID: <56CCD31D.3030604@oracle.com>

It all looks reasonable, but I'm still not clear on the connection 
between CCallingConventionRequiresIntsAsLongs and signx in move32_64.  
Do they cover different paths, so both are needed, or does 
CCallingConventionRequiresIntsAsLongs mean that move32_64 is used less 
often?

dl

On 2/23/2016 8:28 AM, Roland Westrelin wrote:
> Another webrev because using L5 is not necessary when the argument is moved from register to register:
>
> http://cr.openjdk.java.net/~roland/8148353/webrev.02/
>
> Roland.


From vladimir.kozlov at oracle.com  Tue Feb 23 22:03:16 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Feb 2016 14:03:16 -0800
Subject: RFR (XXS) 8066292: Test java/nio/file/Files/CheckPermissions.java
	triggers stack overflow with -server -Xcomp
In-Reply-To: <56CB8C47.8030200@oracle.com>
References: <56CB8C47.8030200@oracle.com>
Message-ID: <56CCD724.1060809@oracle.com>

On 2/22/16 2:31 PM, Dean Long wrote:
> https://bugs.openjdk.java.net/browse/JDK-8066292
>
> http://cr.openjdk.java.net/~dlong/8066292/webrev/
>
> With -Xcomp, a cycle between compile requests and class loading can cause infinite recursion resulting in
> StackOverflowError's that are silently ignored.  To break the cycle, this changeset removes the ancient call to
> Method::load_signature_classes() for C2.  This call is no longer needed.

"This call is no longer needed" because ...? Why it is not needed? C2 can't compile methods if these classes are not loaded.

Thanks,
Vladimir

>
> Tested in RBT with --test
> vm.compiler.testlist,hotspot/test/:hotspot_compiler_closed,hotspot/test/:hotspot_compiler_1,hotspot/test/:hotspot_compiler_2,hotspot/test/:hotspot_compiler_3
>
>
> dl

From vladimir.kozlov at oracle.com  Tue Feb 23 22:41:33 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Feb 2016 14:41:33 -0800
Subject: RFR(S): 8148159: [TESTBUG] TestCompilerDirectivesCompatibility
	tests fails on non-tiered server VMs
In-Reply-To: <56CAE4FD.7000605@oracle.com>
References: <56C31DA9.3070607@oracle.com>
	<115A77CE-C62D-4749-8E4A-2EE4A2F662AB@oracle.com>
	<56CAD94F.8080406@oracle.com> <56CAE4FD.7000605@oracle.com>
Message-ID: <56CCE01D.9060701@oracle.com>

COMP_LEVEL_* is mess. I see a several tests which are repeating their definitions.
I think we should use the same values already defined in test/compiler/whitebox/CompilerWhiteBoxTest.java

Thanks,
Vladimir

On 2/22/16 2:37 AM, Nils Eliasson wrote:
> Hi,
>
> Webrev using comp levels from CompilerUtils instead:
>
> http://cr.openjdk.java.net/~neliasso/8148159/webrev.02/
> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.02/
>
> Best regards,
> Nils Eliasson
>
> On 2016-02-22 10:47, Nils Eliasson wrote:
>> Hi Pavel,
>>
>> On 2016-02-17 16:52, Pavel Punegov wrote:
>>> Hi Nils,
>>>
>>> Do we need hasC1/2Compiler methods?
>>
>> I wanted to know exactly what compilers I am testing.
>>
>>> There is a compiler.tstlibrary.CompilerUtils class that provides tests with available levels.
>>
>> Didn't know about that one. It fills a good purpose but it should not guess what compiler levels are available -
>> rather query the VM directly. We should also move a lot of useful constants from CompilerWhiteBoxTest to CompilerUtils.
>>
>>> There is an example of usage in test/compiler/compilercontrol/share/actions/CompileAction.java.
>>> Also, what about JVMCI in case of hasC2Compiler? AFAIK it works with levels, but I don?t know if it will with such ifdef.
>>
>> I only test the compilers that I know will support this flag. We would need some additional test utils for querying
>> what compiler uses the JVMCI interface.
>>
>>>
>>> Otherwise, it looks good (not a Reviewer)
>>
>> Thanks for taking a look,
>> Nils
>>
>>>
>>>> On 16 Feb 2016, at 16:01, Nils Eliasson > wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review this change.
>>>>
>>>> The tests relied on C1 always being available and thus fails on C2 only server configurations. The fix adds two
>>>> whitebox methods for checking if C1 and C2 is available, and then tests both compilers separately. Also adding
>>>> Xmixed to the commandline since this test doesn't need Xcomp testing.
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8148159
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev.01/
>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.01/
>>>>
>>>> Regards,
>>>> Nils Eliasson
>>>
>>>
>>>
>>> ? Thanks,
>>> Pavel Punegov
>>>
>>
>

From vladimir.kozlov at oracle.com  Tue Feb 23 22:50:08 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Feb 2016 14:50:08 -0800
Subject: RFR(S): 8149789: SIGSEGV in CompileTask::print
In-Reply-To: <56CC77B9.8030003@oracle.com>
References: <56CC77B9.8030003@oracle.com>
Message-ID: <56CCE220.4080704@oracle.com>

Looks good.

Thanks,
Vladimir

On 2/23/16 7:16 AM, Nils Eliasson wrote:
> Hi,
>
> Summary:
> In bug JDK-8063112 I removed the vm_operation from some compiler diagnostic commands. That was ok, but I also added
> printing of the threads with active compile tasks in the Compiler.queue command. That printing is not safe. In this
> crash a compiler thread finishes compiling a task while the diagnostic command is printing the tasks.
>
> Solution:
> Make this diagnostic command require a safepoint - then it will have to block until no compiler threads are running in
> the compileBroker (possibly freeing tasks). When the safepoint is reached, it is safe to print the tasks, since then no
> compile threads can reach the state where tasks are freed without blocking.
>
> Testing:
> Running the repro in the bug + dedicated jcmd Compiler.queue test.
>
> Webrev: http://cr.openjdk.java.net/~neliasso/8149789/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8149789
>
> Please review!
>
> Best regards,
> Nils Eliasson

From dean.long at oracle.com  Wed Feb 24 00:22:04 2016
From: dean.long at oracle.com (Dean Long)
Date: Tue, 23 Feb 2016 16:22:04 -0800
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: <56CCCFDA.6030902@oracle.com>
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
	<56CB8345.5020203@oracle.com>
	
	<2502DFC4-B50D-44E9-BF63-12FBDF308423@oracle.com>
	<56CCCFDA.6030902@oracle.com>
Message-ID: <56CCF7AC.2090308@oracle.com>

Vladimir, my understanding is that this is just because of the way LONG 
and DOUBLE are represented internally, and doesn't mean we use two 
native stack slots.  So we are forcing C2 to treat int args as longs:

JRT_BLOCK_ENTRY(void, OptoRuntime::new_array_C(Klass* array_type, int 
len, JavaThread *thread))

we generate code as if it was

JRT_BLOCK_ENTRY(void, OptoRuntime::new_array_C(Klass* array_type, 
int64_t len, JavaThread *thread))

and we wrap a ConvI2LNode around "len" when we call.

dl

On 2/23/2016 1:32 PM, Vladimir Kozlov wrote:
> Code in sharedRuntime_sparc.cpp looks fine but I am worry about 
> CCallingConventionRequiresIntsAsLongs change. You get additional slots 
> on stack which is not expected on sparc:
>     if (CCallingConventionRequiresIntsAsLongs && f->isa_int()) {
>       fields[cnt++] = TypeLong::LONG;
>       fields[cnt] = Type::HALF; // Must add an additional half for a 
> long.
>
> I found next text which says that integer values takes one stack slot 
> only (but it does requires sign extension to 64 bits):
> https://docs.oracle.com/cd/E26502_01/html/E28387/gentextid-2734.html#scrolltoc 
>
>
> Thanks,
> Vladimir
>
> On 2/23/16 8:28 AM, Roland Westrelin wrote:
>> Another webrev because using L5 is not necessary when the argument is 
>> moved from register to register:
>>
>> http://cr.openjdk.java.net/~roland/8148353/webrev.02/
>>
>> Roland.
>>


From dean.long at oracle.com  Wed Feb 24 00:28:55 2016
From: dean.long at oracle.com (Dean Long)
Date: Tue, 23 Feb 2016 16:28:55 -0800
Subject: RFR (XXS) 8066292: Test java/nio/file/Files/CheckPermissions.java
	triggers stack overflow with -server -Xcomp
In-Reply-To: <56CCD724.1060809@oracle.com>
References: <56CB8C47.8030200@oracle.com> <56CCD724.1060809@oracle.com>
Message-ID: <56CCF947.3030500@oracle.com>

On 2/23/2016 2:03 PM, Vladimir Kozlov wrote:
> On 2/22/16 2:31 PM, Dean Long wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8066292
>>
>> http://cr.openjdk.java.net/~dlong/8066292/webrev/
>>
>> With -Xcomp, a cycle between compile requests and class loading can 
>> cause infinite recursion resulting in
>> StackOverflowError's that are silently ignored.  To break the cycle, 
>> this changeset removes the ancient call to
>> Method::load_signature_classes() for C2.  This call is no longer needed.
>
> "This call is no longer needed" because ...? Why it is not needed? C2 
> can't compile methods if these classes are not loaded.
>

That was my understanding from internal discussions.  Chris or John, can 
you chime in here?

I know that C2 creates placeholder classes if a class isn't loaded. Can 
you point me to where we fail the compilation is signature classes are 
not loaded?

dl

> Thanks,
> Vladimir
>
>>
>> Tested in RBT with --test
>> vm.compiler.testlist,hotspot/test/:hotspot_compiler_closed,hotspot/test/:hotspot_compiler_1,hotspot/test/:hotspot_compiler_2,hotspot/test/:hotspot_compiler_3 
>>
>>
>>
>> dl


From dean.long at oracle.com  Wed Feb 24 01:59:06 2016
From: dean.long at oracle.com (Dean Long)
Date: Tue, 23 Feb 2016 17:59:06 -0800
Subject: RFR (XXS) 8066292: Test java/nio/file/Files/CheckPermissions.java
	triggers stack overflow with -server -Xcomp
In-Reply-To: <56CCF947.3030500@oracle.com>
References: <56CB8C47.8030200@oracle.com> <56CCD724.1060809@oracle.com>
	<56CCF947.3030500@oracle.com>
Message-ID: <56CD0E6A.8010001@oracle.com>

On 2/23/2016 4:28 PM, Dean Long wrote:
> On 2/23/2016 2:03 PM, Vladimir Kozlov wrote:
>> On 2/22/16 2:31 PM, Dean Long wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8066292
>>>
>>> http://cr.openjdk.java.net/~dlong/8066292/webrev/
>>>
>>> With -Xcomp, a cycle between compile requests and class loading can 
>>> cause infinite recursion resulting in
>>> StackOverflowError's that are silently ignored.  To break the cycle, 
>>> this changeset removes the ancient call to
>>> Method::load_signature_classes() for C2.  This call is no longer 
>>> needed.
>>
>> "This call is no longer needed" because ...? Why it is not needed? C2 
>> can't compile methods if these classes are not loaded.
>>
>
> That was my understanding from internal discussions.  Chris or John, 
> can you chime in here?
>
> I know that C2 creates placeholder classes if a class isn't loaded. 
> Can you point me to where we fail the compilation is signature classes 
> are not loaded?
>
> dl
>

Hi Vladimir, I took another look, and I think you must have been 
thinking about inlining.  Yes, we won't inline a callee if its signature 
classes aren't loaded.  But if we really wanted to maximum inlining for 
-Xcomp mode, (which some people think should just go away), wouldn't it 
be better to execute the method in the interpreter a few times, so that 
more of the callee tree would have its classes loaded?

dl

>> Thanks,
>> Vladimir
>>
>>>
>>> Tested in RBT with --test
>>> vm.compiler.testlist,hotspot/test/:hotspot_compiler_closed,hotspot/test/:hotspot_compiler_1,hotspot/test/:hotspot_compiler_2,hotspot/test/:hotspot_compiler_3 
>>>
>>>
>>>
>>> dl
>


From vladimir.kozlov at oracle.com  Wed Feb 24 02:31:11 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Feb 2016 18:31:11 -0800
Subject: RFR (XXS) 8066292: Test java/nio/file/Files/CheckPermissions.java
	triggers stack overflow with -server -Xcomp
In-Reply-To: <56CD0E6A.8010001@oracle.com>
References: <56CB8C47.8030200@oracle.com> <56CCD724.1060809@oracle.com>
	<56CCF947.3030500@oracle.com> <56CD0E6A.8010001@oracle.com>
Message-ID: <56CD15EF.8070508@oracle.com>

On 2/23/16 5:59 PM, Dean Long wrote:
> On 2/23/2016 4:28 PM, Dean Long wrote:
>> On 2/23/2016 2:03 PM, Vladimir Kozlov wrote:
>>> On 2/22/16 2:31 PM, Dean Long wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8066292
>>>>
>>>> http://cr.openjdk.java.net/~dlong/8066292/webrev/
>>>>
>>>> With -Xcomp, a cycle between compile requests and class loading can cause infinite recursion resulting in
>>>> StackOverflowError's that are silently ignored.  To break the cycle, this changeset removes the ancient call to
>>>> Method::load_signature_classes() for C2.  This call is no longer needed.
>>>
>>> "This call is no longer needed" because ...? Why it is not needed? C2 can't compile methods if these classes are not
>>> loaded.
>>>
>>
>> That was my understanding from internal discussions.  Chris or John, can you chime in here?
>>
>> I know that C2 creates placeholder classes if a class isn't loaded. Can you point me to where we fail the compilation
>> is signature classes are not loaded?
>>
>> dl
>>
>
> Hi Vladimir, I took another look, and I think you must have been thinking about inlining.  Yes, we won't inline a callee
> if its signature classes aren't loaded.  But if we really wanted to maximum inlining for -Xcomp mode, (which some people
> think should just go away), wouldn't it be better to execute the method in the interpreter a few times, so that more of
> the callee tree would have its classes loaded?

No, I am thinking about what happens when we start compiling a method which signature has unloaded klass.
 From what I see CI will created "unloaded" ciKlass in such case. It does not have any information except name.
And it looks like ciTypeFlow will treat it as NULL in such case (see ciTypeFlow::StateVector::do_null_assert()).
As result C2 may generate uncommon trap on first access to such parameter.

May be it is okay since -Xcomp usually produces uncommon traps a lot.

I could miss other places in C2 which handle such case.

Thanks,
Vladimir

>
> dl
>
>>> Thanks,
>>> Vladimir
>>>
>>>>
>>>> Tested in RBT with --test
>>>> vm.compiler.testlist,hotspot/test/:hotspot_compiler_closed,hotspot/test/:hotspot_compiler_1,hotspot/test/:hotspot_compiler_2,hotspot/test/:hotspot_compiler_3
>>>>
>>>>
>>>>
>>>> dl
>>
>

From roland.westrelin at oracle.com  Wed Feb 24 07:24:03 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 24 Feb 2016 08:24:03 +0100
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: <56CCCFDA.6030902@oracle.com>
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
	<56CB8345.5020203@oracle.com>
	
	<2502DFC4-B50D-44E9-BF63-12FBDF308423@oracle.com>
	<56CCCFDA.6030902@oracle.com>
Message-ID: <1C852648-1F3D-47A6-8D70-ED1DEA7CE20C@oracle.com>

> Code in sharedRuntime_sparc.cpp looks fine but I am worry about CCallingConventionRequiresIntsAsLongs change.

I?m asked to move fast with that fix because it affects a tck test and to backport it to 8. So I?d like to push the sharedRuntime_sparc change and leave the CCallingConventionRequiresIntsAsLongs one out for later. Does that sound good?

Roland.

From nils.eliasson at oracle.com  Wed Feb 24 08:57:27 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 24 Feb 2016 09:57:27 +0100
Subject: RFR(S): 8148159: [TESTBUG] TestCompilerDirectivesCompatibility
	tests fails on non-tiered server VMs
In-Reply-To: <56CCE01D.9060701@oracle.com>
References: <56C31DA9.3070607@oracle.com>
	<115A77CE-C62D-4749-8E4A-2EE4A2F662AB@oracle.com>
	<56CAD94F.8080406@oracle.com> <56CAE4FD.7000605@oracle.com>
	<56CCE01D.9060701@oracle.com>
Message-ID: <56CD7077.5010105@oracle.com>

Hi Vladimir,

CompilerWhiteBoxTest.java includes a lot of other unrelated things too. 
I suggest to put all the common constants in CompilerUtils and import 
that one into CompilerWhiteBox.

Regards,
Nils

On 2016-02-23 23:41, Vladimir Kozlov wrote:
> COMP_LEVEL_* is mess. I see a several tests which are repeating their 
> definitions.
> I think we should use the same values already defined in 
> test/compiler/whitebox/CompilerWhiteBoxTest.java
>
> Thanks,
> Vladimir
>
> On 2/22/16 2:37 AM, Nils Eliasson wrote:
>> Hi,
>>
>> Webrev using comp levels from CompilerUtils instead:
>>
>> http://cr.openjdk.java.net/~neliasso/8148159/webrev.02/
>> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.02/
>>
>> Best regards,
>> Nils Eliasson
>>
>> On 2016-02-22 10:47, Nils Eliasson wrote:
>>> Hi Pavel,
>>>
>>> On 2016-02-17 16:52, Pavel Punegov wrote:
>>>> Hi Nils,
>>>>
>>>> Do we need hasC1/2Compiler methods?
>>>
>>> I wanted to know exactly what compilers I am testing.
>>>
>>>> There is a compiler.tstlibrary.CompilerUtils class that provides 
>>>> tests with available levels.
>>>
>>> Didn't know about that one. It fills a good purpose but it should 
>>> not guess what compiler levels are available -
>>> rather query the VM directly. We should also move a lot of useful 
>>> constants from CompilerWhiteBoxTest to CompilerUtils.
>>>
>>>> There is an example of usage in 
>>>> test/compiler/compilercontrol/share/actions/CompileAction.java.
>>>> Also, what about JVMCI in case of hasC2Compiler? AFAIK it works 
>>>> with levels, but I don?t know if it will with such ifdef.
>>>
>>> I only test the compilers that I know will support this flag. We 
>>> would need some additional test utils for querying
>>> what compiler uses the JVMCI interface.
>>>
>>>>
>>>> Otherwise, it looks good (not a Reviewer)
>>>
>>> Thanks for taking a look,
>>> Nils
>>>
>>>>
>>>>> On 16 Feb 2016, at 16:01, Nils Eliasson >>>> > wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please review this change.
>>>>>
>>>>> The tests relied on C1 always being available and thus fails on C2 
>>>>> only server configurations. The fix adds two
>>>>> whitebox methods for checking if C1 and C2 is available, and then 
>>>>> tests both compilers separately. Also adding
>>>>> Xmixed to the commandline since this test doesn't need Xcomp testing.
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8148159
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev.01/
>>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.01/
>>>>>
>>>>> Regards,
>>>>> Nils Eliasson
>>>>
>>>>
>>>>
>>>> ? Thanks,
>>>> Pavel Punegov
>>>>
>>>
>>


From aleksey.shipilev at oracle.com  Wed Feb 24 09:10:38 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 24 Feb 2016 12:10:38 +0300
Subject: RFR (S) 8150514: C1 crashes in Canonicalizer::do_ArrayLength() after
	fix for JDK-8150102
Message-ID: <56CD738E.3040502@oracle.com>

Hi,

The C1 Canonicalizer fix for arraylength folding (JDK-8150102) crashes
the VM when array constant is "null", and ArrayConstant is not
available. This happens every so often in nightly testing.

Here is a quick fix for that:
  http://cr.openjdk.java.net/~shade/8150514/webrev.01/

Testing: regression test in Linux x86_64/fastdebug

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From tobias.hartmann at oracle.com  Wed Feb 24 09:22:49 2016
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 24 Feb 2016 10:22:49 +0100
Subject: RFR (S) 8150514: C1 crashes in Canonicalizer::do_ArrayLength()
	after fix for JDK-8150102
In-Reply-To: <56CD738E.3040502@oracle.com>
References: <56CD738E.3040502@oracle.com>
Message-ID: <56CD7669.6070705@oracle.com>

Hi Aleksey,

On 24.02.2016 10:10, Aleksey Shipilev wrote:
> Hi,
> 
> The C1 Canonicalizer fix for arraylength folding (JDK-8150102) crashes
> the VM when array constant is "null", and ArrayConstant is not
> available. This happens every so often in nightly testing.
> 
> Here is a quick fix for that:
>   http://cr.openjdk.java.net/~shade/8150514/webrev.01/

Looks good to me.

> Testing: regression test in Linux x86_64/fastdebug

Please don't use bug numbers for test names/folders but use a name describing the purpose of the test.

Best regards,
Tobias

> 
> Thanks,
> -Aleksey
> 

From konstantin.shefov at oracle.com  Wed Feb 24 09:25:06 2016
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Wed, 24 Feb 2016 12:25:06 +0300
Subject: [9] RFR JDK-8141616: Add new methods to the java Whitebox API
In-Reply-To: 
References: <56C47B59.5090606@oracle.com>
	
Message-ID: <56CD76F2.9080204@oracle.com>

Hi Christian

Thanks for reviewing

On 02/22/2016 10:33 PM, Christian Thalinger wrote:
> +WB_ENTRY(jint, WB_GetConstantPoolCacheLength(JNIEnv* env, jobject wb, jclass klass))
> +  instanceKlassHandle ikh(java_lang_Class::as_Klass(JNIHandles::resolve(klass)));
> +  ConstantPool* cp = ikh->constants();
> +  if (cp->cache() == NULL) {
> +      return -1;
> +  }
>
> Shouldn?t this throw an exception like in the other methods?

Half of the tests from JDK-8141618 and JDK-8141619 have "cp->cache() == 
NULL", so I think it is better to compare the length of cpcache with 0 
than to catch an exception every time.

-Konstantin
>
>> On Feb 17, 2016, at 3:53 AM, Konstantin Shefov  wrote:
>>
>> Hello
>>
>> Please review some new methods added to the sun.hotspot.WhiteBox API.
>> These methods are needed to test JVMCI CompilerToVM methods, see https://bugs.openjdk.java.net/browse/JDK-8138708 for more info.
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141616
>> Webrev for java part: http://cr.openjdk.java.net/~kshefov/8141616/root/webrev.00/
>> Webrev for native part: http://cr.openjdk.java.net/~kshefov/8141616/hotspot/webrev.00/
>>
>> Thanks
>> -Konstantin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From aleksey.shipilev at oracle.com  Wed Feb 24 09:30:39 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 24 Feb 2016 12:30:39 +0300
Subject: RFR (S) 8150514: C1 crashes in Canonicalizer::do_ArrayLength()
	after fix for JDK-8150102
In-Reply-To: <56CD7669.6070705@oracle.com>
References: <56CD738E.3040502@oracle.com> <56CD7669.6070705@oracle.com>
Message-ID: <56CD783F.3010509@oracle.com>

On 02/24/2016 12:22 PM, Tobias Hartmann wrote:
> On 24.02.2016 10:10, Aleksey Shipilev wrote:
>> Hi,
>>
>> The C1 Canonicalizer fix for arraylength folding (JDK-8150102) crashes
>> the VM when array constant is "null", and ArrayConstant is not
>> available. This happens every so often in nightly testing.
>>
>> Here is a quick fix for that:
>>   http://cr.openjdk.java.net/~shade/8150514/webrev.01/
> 
> Looks good to me.

Thanks Tobias!

>> Testing: regression test in Linux x86_64/fastdebug
> 
> Please don't use bug numbers for test names/folders but use a name describing the purpose of the test.

Okay, let's do this instead:
  http://cr.openjdk.java.net/~shade/8150514/webrev.02/

Cheers,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From tobias.hartmann at oracle.com  Wed Feb 24 09:33:49 2016
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 24 Feb 2016 10:33:49 +0100
Subject: RFR (S) 8150514: C1 crashes in Canonicalizer::do_ArrayLength()
	after fix for JDK-8150102
In-Reply-To: <56CD783F.3010509@oracle.com>
References: <56CD738E.3040502@oracle.com> <56CD7669.6070705@oracle.com>
	<56CD783F.3010509@oracle.com>
Message-ID: <56CD78FD.8040200@oracle.com>

Hi Aleksey,

On 24.02.2016 10:30, Aleksey Shipilev wrote:
> On 02/24/2016 12:22 PM, Tobias Hartmann wrote:
>> On 24.02.2016 10:10, Aleksey Shipilev wrote:
>>> Hi,
>>>
>>> The C1 Canonicalizer fix for arraylength folding (JDK-8150102) crashes
>>> the VM when array constant is "null", and ArrayConstant is not
>>> available. This happens every so often in nightly testing.
>>>
>>> Here is a quick fix for that:
>>>   http://cr.openjdk.java.net/~shade/8150514/webrev.01/
>>
>> Looks good to me.
> 
> Thanks Tobias!
> 
>>> Testing: regression test in Linux x86_64/fastdebug
>>
>> Please don't use bug numbers for test names/folders but use a name describing the purpose of the test.
> 
> Okay, let's do this instead:
>   http://cr.openjdk.java.net/~shade/8150514/webrev.02/

Looks good!

Best regards,
Tobias

> 
> Cheers,
> -Aleksey
> 
> 

From aleksey.shipilev at oracle.com  Wed Feb 24 09:38:10 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 24 Feb 2016 12:38:10 +0300
Subject: RFR (S) 8150514: C1 crashes in Canonicalizer::do_ArrayLength()
	after fix for JDK-8150102
In-Reply-To: <56CD78FD.8040200@oracle.com>
References: <56CD738E.3040502@oracle.com> <56CD7669.6070705@oracle.com>
	<56CD783F.3010509@oracle.com> <56CD78FD.8040200@oracle.com>
Message-ID: <56CD7A02.4050002@oracle.com>

On 02/24/2016 12:33 PM, Tobias Hartmann wrote:
> On 24.02.2016 10:30, Aleksey Shipilev wrote:
>> Okay, let's do this instead:
>>   http://cr.openjdk.java.net/~shade/8150514/webrev.02/
> 
> Looks good!

Thanks Tobias!

Need more reviews to push it.

-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From vladimir.kozlov at oracle.com  Wed Feb 24 10:03:03 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Feb 2016 02:03:03 -0800
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: <1C852648-1F3D-47A6-8D70-ED1DEA7CE20C@oracle.com>
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
	<56CB8345.5020203@oracle.com>
	
	<2502DFC4-B50D-44E9-BF63-12FBDF308423@oracle.com>
	<56CCCFDA.6030902@oracle.com>
	<1C852648-1F3D-47A6-8D70-ED1DEA7CE20C@oracle.com>
Message-ID: <56CD7FD7.7040902@oracle.com>

Yes, sounds good.

Vladimir

On 2/23/16 11:24 PM, Roland Westrelin wrote:
>> Code in sharedRuntime_sparc.cpp looks fine but I am worry about CCallingConventionRequiresIntsAsLongs change.
>
> I?m asked to move fast with that fix because it affects a tck test and to backport it to 8. So I?d like to push the sharedRuntime_sparc change and leave the CCallingConventionRequiresIntsAsLongs one out for later. Does that sound good?
>
> Roland.
>

From roland.westrelin at oracle.com  Wed Feb 24 10:29:12 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 24 Feb 2016 11:29:12 +0100
Subject: RFR(XS): 8148353: [linux-sparc] Crash in libawt.so on Linux SPARC
In-Reply-To: <56CCD31D.3030604@oracle.com>
References: <8DEA8F34-023C-439A-8E37-9E0BEDDE9704@oracle.com>
	<56CB8345.5020203@oracle.com>
	
	<2502DFC4-B50D-44E9-BF63-12FBDF308423@oracle.com>
	<56CCD31D.3030604@oracle.com>
Message-ID: <48771173-3F64-4077-87AE-0308A194121E@oracle.com>

> It all looks reasonable, but I'm still not clear on the connection between CCallingConventionRequiresIntsAsLongs and signx in move32_64.  Do they cover different paths, so both are needed, or does CCallingConventionRequiresIntsAsLongs mean that move32_64 is used less often?

It?s my understanding that they do cover different paths. The mov32_64 change is used for native java method calls and CCallingConventionRequiresIntsAsLongs covers calls to the runtime from a compiled java method.

Roland.

From vladimir.x.ivanov at oracle.com  Wed Feb 24 10:32:13 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 24 Feb 2016 13:32:13 +0300
Subject: RFR (S) 8150514: C1 crashes in Canonicalizer::do_ArrayLength()
	after fix for JDK-8150102
In-Reply-To: <56CD783F.3010509@oracle.com>
References: <56CD738E.3040502@oracle.com> <56CD7669.6070705@oracle.com>
	<56CD783F.3010509@oracle.com>
Message-ID: <56CD86AD.1010502@oracle.com>

>    http://cr.openjdk.java.net/~shade/8150514/webrev.02/
Reviewed.

Best regards,
Vladimir Ivanov

From aph at redhat.com  Wed Feb 24 10:58:23 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 24 Feb 2016 10:58:23 +0000
Subject: RFR: 8150394: aarch64: add support for 8.1 LSE CAS instructions
In-Reply-To: <1456173130.2735.8.camel@mint>
References: <1456173130.2735.8.camel@mint>
Message-ID: <56CD8CCF.1030404@redhat.com>

On 22/02/16 20:32, Edward Nevill wrote:
> http://cr.openjdk.java.net/~enevill/8150394/webrev.0/
> 
> This adds support for the CAS instructions in armv8.1.

The C2 code for aarch64_enc_cmpxchg* is missing.

It's quite tricky to refactor to allow LSE instructions.  I'd add
a wordsize parameter to the cas instruction, like this:

#define INSN(NAME, a, r)                                                \
  void NAME(operand_size sz, Register Rs, Register Rt, Register Rn) {   \
    assert(Rs != Rn && Rs != Rt, "unpredictable instruction");          \
    compare_and_swap(Rs, Rt, Rn, sz, 1, a, r);                          \
  }
  INSN(cas, 0, 0)

And this gets rid of a ton of instruction definitions: we only need
CAS{A,L,AL}.

Pass the operand size down to MacroAssembler::cmpxchgw:

  enc_class aarch64_enc_cmpxchgw(memory mem, iRegINoSp oldval, iRegINoSp newval) %{
    MacroAssembler _masm(&cbuf);
    guarantee($mem$$index == -1 && $mem$$disp == 0, "impossible encoding");
    __ cmpxchg(Assembler::word, $mem$$base$$Register, $oldval$$Register,
               $newval$$Register,
               &Assembler::ldxrw, &MacroAssembler::cmpw, &Assembler::stlxrw);
  %}

void MacroAssembler::cmpxchgw(operand_size sz, Register oldv,
                              Register newv, Register addr, Register tmp,
			      Label &succeed, Label *fail) {

  if (UseLSE) {
    ...

It'll be necessary to pass a memory barrier flag too.

Andrew.

From aph at redhat.com  Wed Feb 24 12:49:30 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 24 Feb 2016 12:49:30 +0000
Subject: RFR: 8150394: aarch64: add support for 8.1 LSE CAS instructions
In-Reply-To: <56CD8CCF.1030404@redhat.com>
References: <1456173130.2735.8.camel@mint> <56CD8CCF.1030404@redhat.com>
Message-ID: <56CDA6DA.3080901@redhat.com>

One more thing: with 8148146 we have new entry points and C2 nodes
for WeakCompareAndSwapX.  We'll need to add a "bool weak" parameter
to MacroAssembler::cmpxchgw.  I suppose it's OK for this to be done
in a later commit.

Andrew.


From aph at redhat.com  Wed Feb 24 12:59:16 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 24 Feb 2016 12:59:16 +0000
Subject: [aarch64-port-dev ] RFR: 8150394: aarch64: add support for 8.1
	LSE CAS instructions
In-Reply-To: <56CDA6DA.3080901@redhat.com>
References: <1456173130.2735.8.camel@mint> <56CD8CCF.1030404@redhat.com>
	<56CDA6DA.3080901@redhat.com>
Message-ID: <56CDA924.6050106@redhat.com>

On 02/24/2016 12:49 PM, Andrew Haley wrote:
> One more thing: with 8148146 we have new entry points and C2 nodes
> for WeakCompareAndSwapX.  We'll need to add a "bool weak" parameter
> to MacroAssembler::cmpxchgw.  I suppose it's OK for this to be done
> in a later commit.

Forget that: hs-comp is currently broken because of Unsafe changes.  I'm
going to make it build again and push.  Your changes can go on top of
that.

Andrew.


From hui.shi at linaro.org  Wed Feb 24 13:02:48 2016
From: hui.shi at linaro.org (Hui Shi)
Date: Wed, 24 Feb 2016 21:02:48 +0800
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJGUjogODE0OTczMzogQUFyY2g2NDogcmVmYWN0b3JjaGFyX2Fycg==?=
	=?UTF-8?B?YXlfZXF1YWxzL2J5dGVfYXJyYXlfZXF1YWxzL3N0cmluZ19lcXVhbHM=?=
In-Reply-To: <56CC8630.2020708@redhat.com>
References: <56CC2DF8.60806@oracle.com>
	
	<56C70C42.5020309@oracle.com>
	
	<56CC8630.2020708@redhat.com>
Message-ID: 

Thanks Andrew! Your comment looks really better and performance doesn't
change when run JMHSample_97_ArrayEqual.java

 test.

latest webrev http://cr.openjdk.java.net/~hshi/8149733/webrev3/
several small name and format issues:
1. "ary1" -> "a" in method declaration

2. Use tmp1 instead of rscratch1 directly
+    ldrw(cnt1, Address(a1, length_offset));
+    ldrw(cnt2, Address(a2, length_offset));
+    eorw(rscratch1, cnt1, cnt2);
+    cbnzw(rscratch1, DONE);

3.       Blank after ?!?
+  if (! is_string) {


Following is result with Aleksey's updated test case (-w 5 -wi 3 -i3 -r
10), first 4 group are for base run with base string length 0, 8, 31, 1024.
Performance with patch doesn't show same improvement with early test. Only
small length string equal tests still show obvious improvement.

grep -A 6 "^Benchmark" base.result
Benchmark                         (baselength)  (size)  Mode  Cnt   Score
Error  Units
JMH_ArrayEquals.byte_equal                   0     500  avgt    9  15.563 ?
0.005  us/op
JMH_ArrayEquals.byte_not_equal               0     500  avgt    9  16.425 ?
0.167  us/op
JMH_ArrayEquals.char_equal                   0     500  avgt    9  15.635 ?
0.294  us/op
JMH_ArrayEquals.char_not_equal               0     500  avgt    9  15.557 ?
0.377  us/op
JMH_ArrayEquals.string_equal                 0     500  avgt    9  22.307 ?
0.063  us/op
JMH_ArrayEquals.string_not_equal             0     500  avgt    9  21.368 ?
0.025  us/op
--
Benchmark                         (baselength)  (size)  Mode  Cnt   Score
Error  Units
JMH_ArrayEquals.byte_equal                   8     500  avgt    9  16.058 ?
0.012  us/op
JMH_ArrayEquals.byte_not_equal               8     500  avgt    9  16.910 ?
0.574  us/op
JMH_ArrayEquals.char_equal                   8     500  avgt    9  17.094 ?
0.008  us/op
JMH_ArrayEquals.char_not_equal               8     500  avgt    9  17.114 ?
0.156  us/op
JMH_ArrayEquals.string_equal                 8     500  avgt    9  25.033 ?
0.074  us/op
JMH_ArrayEquals.string_not_equal             8     500  avgt    9  24.968 ?
0.244  us/op
--
Benchmark                         (baselength)  (size)  Mode  Cnt   Score
Error  Units
JMH_ArrayEquals.byte_equal                  31     500  avgt    9  18.821 ?
0.091  us/op
JMH_ArrayEquals.byte_not_equal              31     500  avgt    9  19.763 ?
0.002  us/op
JMH_ArrayEquals.char_equal                  31     500  avgt    9  24.210 ?
0.033  us/op
JMH_ArrayEquals.char_not_equal              31     500  avgt    9  27.400 ?
0.382  us/op
JMH_ArrayEquals.string_equal                31     500  avgt    9  29.825 ?
0.098  us/op
JMH_ArrayEquals.string_not_equal            31     500  avgt    9  31.918 ?
0.100  us/op
--
Benchmark                         (baselength)  (size)  Mode  Cnt    Score
  Error  Units
JMH_ArrayEquals.byte_equal                1024     500  avgt    9  188.613
? 7.386  us/op
JMH_ArrayEquals.byte_not_equal            1024     500  avgt    9  193.399
? 4.448  us/op
JMH_ArrayEquals.char_equal                1024     500  avgt    9  316.324
? 9.976  us/op
JMH_ArrayEquals.char_not_equal            1024     500  avgt    9  341.307
? 1.082  us/op
JMH_ArrayEquals.string_equal              1024     500  avgt    9  324.059
? 2.352  us/op
JMH_ArrayEquals.string_not_equal          1024     500  avgt    9  326.954
? 1.121  us/op




grep -A 6 "^Benchmark" opt.result
Benchmark                         (baselength)  (size)  Mode  Cnt   Score
Error  Units
JMH_ArrayEquals.byte_equal                   0     500  avgt    9  15.923 ?
0.132  us/op
JMH_ArrayEquals.byte_not_equal               0     500  avgt    9  15.996 ?
0.336  us/op
JMH_ArrayEquals.char_equal                   0     500  avgt    9  16.001 ?
0.127  us/op
JMH_ArrayEquals.char_not_equal               0     500  avgt    9  15.361 ?
0.004  us/op
JMH_ArrayEquals.string_equal                 0     500  avgt    9  21.083 ?
0.337  us/op
JMH_ArrayEquals.string_not_equal             0     500  avgt    9  19.887 ?
0.479  us/op
--
Benchmark                         (baselength)  (size)  Mode  Cnt   Score
Error  Units
JMH_ArrayEquals.byte_equal                   8     500  avgt    9  16.574 ?
0.148  us/op
JMH_ArrayEquals.byte_not_equal               8     500  avgt    9  16.596 ?
0.719  us/op
JMH_ArrayEquals.char_equal                   8     500  avgt    9  17.874 ?
0.431  us/op
JMH_ArrayEquals.char_not_equal               8     500  avgt    9  17.831 ?
0.284  us/op
JMH_ArrayEquals.string_equal                 8     500  avgt    9  24.279 ?
0.033  us/op
JMH_ArrayEquals.string_not_equal             8     500  avgt    9  22.850 ?
0.444  us/op
--
Benchmark                         (baselength)  (size)  Mode  Cnt   Score
Error  Units
JMH_ArrayEquals.byte_equal                  31     500  avgt    9  19.010 ?
0.006  us/op
JMH_ArrayEquals.byte_not_equal              31     500  avgt    9  19.962 ?
0.071  us/op
JMH_ArrayEquals.char_equal                  31     500  avgt    9  25.038 ?
0.108  us/op
JMH_ArrayEquals.char_not_equal              31     500  avgt    9  27.268 ?
0.063  us/op
JMH_ArrayEquals.string_equal                31     500  avgt    9  29.366 ?
0.103  us/op
JMH_ArrayEquals.string_not_equal            31     500  avgt    9  31.357 ?
0.047  us/op
--
Benchmark                         (baselength)  (size)  Mode  Cnt    Score
  Error  Units
JMH_ArrayEquals.byte_equal                1024     500  avgt    9  190.034
? 4.067  us/op
JMH_ArrayEquals.byte_not_equal            1024     500  avgt    9  192.504
? 4.675  us/op
JMH_ArrayEquals.char_equal                1024     500  avgt    9  313.925
? 8.476  us/op
JMH_ArrayEquals.char_not_equal            1024     500  avgt    9  342.520
? 7.915  us/op
JMH_ArrayEquals.string_equal              1024     500  avgt    9  326.392
? 2.009  us/op
JMH_ArrayEquals.string_not_equal          1024     500  avgt    9  328.526
? 3.617  us/op


Regards
Hui

On 24 February 2016 at 00:17, Andrew Haley  wrote:

> My version is at
>
> http://cr.openjdk.java.net/~aph/8149733/
>
> The changes I made are:
>
>         I rewrote most of the comments because I couldn't understand
>         them.  I intend no criticism, and I understand that English
>         isn't the language of your birth.  Please tell me if you can
>         understand my comments.
>
>         "generic_array_equals" -> "arrays_equals"
>         Reason: it's not generic, it's only bytes and chars.
>         Also, this is what x86_64 calls the same routine.
>
>         "ary1" -> "a"
>         Reason: "ary" just looks odd.  Also, these are the names in the
>         java code.
>
>         "cmp; br.nz" -> "eor, bnz"
>         Reason: Don't clobber flags for no reason.
>
>         There's no need to check for the same arrays if we're
>         comparing strings.
>
> Otherwise, the code is the same.  I haven't much tested this, but it
> should give the same performance.  Please test it, and tell me if I've
> broken anything.
>
> Thanks,
>
> Andrew.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From nils.eliasson at oracle.com  Wed Feb 24 14:06:37 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 24 Feb 2016 15:06:37 +0100
Subject: RFR(S/M): 8069160:
	serviceability/dcmd/compiler/CompilerQueueTest.java fails due to class
	not found
Message-ID: <56CDB8ED.3070907@oracle.com>

Hi,

I need a review of this fix of the CompilerQueueTest.

Summary:
This test was checking the output from the Compiler.queue diagnostic 
command - testing each queue entry by reflection. This was fragile 
because different methods end up in the queue every run and what classes 
are reflectable changes over time.

Solution:
In the improved version the whitebox API is used to block compilation 
and then enqueue methods for all available compilation levels. Then the 
jcmd is executed and the output is verified to contain the specific test 
methods. In some scenarios where the compile queue is overwhelmed by 
requestm, entries might get evicted. The test take that into account too.

Testing:
Run test on all platforms

Bug: https://bugs.openjdk.java.net/browse/JDK-8069160
Webrev: http://cr.openjdk.java.net/~neliasso/8069160/webrev.03/

Best regards,
Nils Eliasson

From aleksey.shipilev at oracle.com  Wed Feb 24 14:24:42 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 24 Feb 2016 17:24:42 +0300
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJGUjogODE0OTczMzogQUFyY2g2NDogcmVmYWN0?=
	=?UTF-8?Q?orchar=5farray=5fequals/byte=5farray=5fequals/string=5fequals?=
In-Reply-To: 
References: <56CC2DF8.60806@oracle.com>
	
	<56C70C42.5020309@oracle.com> 
	<56CC8630.2020708@redhat.com>
	
Message-ID: <56CDBD2A.9050002@oracle.com>

On 02/24/2016 04:02 PM, Hui Shi wrote:
> Thanks Andrew! Your comment looks really better and performance doesn't
> change when run JMHSample_97_ArrayEqual.java
>  test. 
> 
> latest webrev http://cr.openjdk.java.net/~hshi/8149733/webrev3/
> 

Good.

> Following is result with Aleksey's updated test case (-w 5 -wi 3 -i3 -r
> 10), first 4 group are for base run with base string length 0, 8, 31,
> 1024. Performance with patch doesn't show same improvement with early
> test. Only small length string equal tests still show obvious improvement. 

...and that's okay for refactoring.

Cheers,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From nils.eliasson at oracle.com  Wed Feb 24 14:24:01 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 24 Feb 2016 15:24:01 +0100
Subject: RFR(S): 8148159: [TESTBUG] TestCompilerDirectivesCompatibility
	tests fails on non-tiered server VMs
In-Reply-To: <56CD7077.5010105@oracle.com>
References: <56C31DA9.3070607@oracle.com>
	<115A77CE-C62D-4749-8E4A-2EE4A2F662AB@oracle.com>
	<56CAD94F.8080406@oracle.com> <56CAE4FD.7000605@oracle.com>
	<56CCE01D.9060701@oracle.com> <56CD7077.5010105@oracle.com>
Message-ID: <56CDBD01.1040909@oracle.com>

On second thought - I'll import the constants from CompilerWhiteBox and 
then we can discuss what we want to do with CompilerUtils and 
CompilerWhiteBox in the future.

Webrev: http://cr.openjdk.java.net/~neliasso/8148159/webrev.03/
JDK Webrev: http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.02/ 
(Not changed)

Best regards,
Nils Eliasson

On 2016-02-24 09:57, Nils Eliasson wrote:
> Hi Vladimir,
>
> CompilerWhiteBoxTest.java includes a lot of other unrelated things 
> too. I suggest to put all the common constants in CompilerUtils and 
> import that one into CompilerWhiteBox.
>
> Regards,
> Nils
>
> On 2016-02-23 23:41, Vladimir Kozlov wrote:
>> COMP_LEVEL_* is mess. I see a several tests which are repeating their 
>> definitions.
>> I think we should use the same values already defined in 
>> test/compiler/whitebox/CompilerWhiteBoxTest.java
>>
>> Thanks,
>> Vladimir
>>
>> On 2/22/16 2:37 AM, Nils Eliasson wrote:
>>> Hi,
>>>
>>> Webrev using comp levels from CompilerUtils instead:
>>>
>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev.02/
>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.02/
>>>
>>> Best regards,
>>> Nils Eliasson
>>>
>>> On 2016-02-22 10:47, Nils Eliasson wrote:
>>>> Hi Pavel,
>>>>
>>>> On 2016-02-17 16:52, Pavel Punegov wrote:
>>>>> Hi Nils,
>>>>>
>>>>> Do we need hasC1/2Compiler methods?
>>>>
>>>> I wanted to know exactly what compilers I am testing.
>>>>
>>>>> There is a compiler.tstlibrary.CompilerUtils class that provides 
>>>>> tests with available levels.
>>>>
>>>> Didn't know about that one. It fills a good purpose but it should 
>>>> not guess what compiler levels are available -
>>>> rather query the VM directly. We should also move a lot of useful 
>>>> constants from CompilerWhiteBoxTest to CompilerUtils.
>>>>
>>>>> There is an example of usage in 
>>>>> test/compiler/compilercontrol/share/actions/CompileAction.java.
>>>>> Also, what about JVMCI in case of hasC2Compiler? AFAIK it works 
>>>>> with levels, but I don?t know if it will with such ifdef.
>>>>
>>>> I only test the compilers that I know will support this flag. We 
>>>> would need some additional test utils for querying
>>>> what compiler uses the JVMCI interface.
>>>>
>>>>>
>>>>> Otherwise, it looks good (not a Reviewer)
>>>>
>>>> Thanks for taking a look,
>>>> Nils
>>>>
>>>>>
>>>>>> On 16 Feb 2016, at 16:01, Nils Eliasson >>>>> > wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please review this change.
>>>>>>
>>>>>> The tests relied on C1 always being available and thus fails on 
>>>>>> C2 only server configurations. The fix adds two
>>>>>> whitebox methods for checking if C1 and C2 is available, and then 
>>>>>> tests both compilers separately. Also adding
>>>>>> Xmixed to the commandline since this test doesn't need Xcomp 
>>>>>> testing.
>>>>>>
>>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8148159
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev.01/
>>>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.01/
>>>>>>
>>>>>> Regards,
>>>>>> Nils Eliasson
>>>>>
>>>>>
>>>>>
>>>>> ? Thanks,
>>>>> Pavel Punegov
>>>>>
>>>>
>>>
>


From nils.eliasson at oracle.com  Wed Feb 24 14:26:25 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 24 Feb 2016 15:26:25 +0100
Subject: RFR(S): 8149789: SIGSEGV in CompileTask::print
In-Reply-To: <56CCE220.4080704@oracle.com>
References: <56CC77B9.8030003@oracle.com> <56CCE220.4080704@oracle.com>
Message-ID: <56CDBD91.3070109@oracle.com>

Thank you Vladimir!

I'll push this together with the updated CompilerQueueTest (FR(S/M): 
8069160: serviceability/dcmd/compiler/CompilerQueueTest.java fails due 
to class not found) when it has passed review.

Best regards,
Nils Eliasson

On 2016-02-23 23:50, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 2/23/16 7:16 AM, Nils Eliasson wrote:
>> Hi,
>>
>> Summary:
>> In bug JDK-8063112 I removed the vm_operation from some compiler 
>> diagnostic commands. That was ok, but I also added
>> printing of the threads with active compile tasks in the 
>> Compiler.queue command. That printing is not safe. In this
>> crash a compiler thread finishes compiling a task while the 
>> diagnostic command is printing the tasks.
>>
>> Solution:
>> Make this diagnostic command require a safepoint - then it will have 
>> to block until no compiler threads are running in
>> the compileBroker (possibly freeing tasks). When the safepoint is 
>> reached, it is safe to print the tasks, since then no
>> compile threads can reach the state where tasks are freed without 
>> blocking.
>>
>> Testing:
>> Running the repro in the bug + dedicated jcmd Compiler.queue test.
>>
>> Webrev: http://cr.openjdk.java.net/~neliasso/8149789/webrev.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149789
>>
>> Please review!
>>
>> Best regards,
>> Nils Eliasson


From vladimir.x.ivanov at oracle.com  Wed Feb 24 16:06:12 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 24 Feb 2016 19:06:12 +0300
Subject: [9] RFR (S): 8150186: Folding mismatched accesses with @Stable is
	incorrect
Message-ID: <56CDD4F4.2070907@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8150186/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8150186

Constant folding from stable arrays doesn't check for mismatched accesses.

The fix is to disable the optimization for mismatched accesses.

Also, added missing range checks in ciArray::element_value_by_offset.

Testing: failing tests, JPRT

Best regards,
Vladimir Ivanov

PS: I considered converting is_mismatched_access check in 
fold_stable_ary_elem into an assert, but I spotted some quirks in 
mismatched access detection (filed JDK-8150543 [1]). So, I'd prefer to 
keep the check and refine the code as part of JDK-8150543 when more test 
coverage is available.

[1] https://bugs.openjdk.java.net/browse/JDK-8150543

From vladimir.x.ivanov at oracle.com  Wed Feb 24 16:14:29 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 24 Feb 2016 19:14:29 +0300
Subject: [9] RFR (XS): 8150436: Incorrect invocation mode when linkToInteface
	linker is eliminated
Message-ID: <56CDD6E5.2090001@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8150436/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8150436

When MH.linkToInterface is eliminated, but the target method is not 
inlined, either default or concrete method is attached to the call site. 
During call site resolution, invokeinterface invocation mode is used, 
but resolution fails when the target method is concrete.

The fix is to adjust invocation mode to invokevirtual when concrete 
method is attached.

Testing: failing test, JPRT.

Thanks!

Best regards,
Vladimir Ivanov

From aleksey.shipilev at oracle.com  Wed Feb 24 16:15:44 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 24 Feb 2016 19:15:44 +0300
Subject: [9] RFR (S): 8150186: Folding mismatched accesses with @Stable is
	incorrect
In-Reply-To: <56CDD4F4.2070907@oracle.com>
References: <56CDD4F4.2070907@oracle.com>
Message-ID: <56CDD730.20208@oracle.com>

On 02/24/2016 07:06 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8150186/webrev.00/

Looks good, thanks!

FTR, this change fixes a few tests failing in nightly after String.value
became @Stable.

Cheers,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From adinn at redhat.com  Wed Feb 24 16:50:58 2016
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 24 Feb 2016 16:50:58 +0000
Subject: [aarch64-port-dev ] RFR: 8150394: aarch64: add support for 8.1
	LSE CAS instructions
In-Reply-To: <56CD8CCF.1030404@redhat.com>
References: <1456173130.2735.8.camel@mint> <56CD8CCF.1030404@redhat.com>
Message-ID: <56CDDF72.9080304@redhat.com>



On 24/02/16 10:58, Andrew Haley wrote:
> On 22/02/16 20:32, Edward Nevill wrote:
>> http://cr.openjdk.java.net/~enevill/8150394/webrev.0/
>>
>> This adds support for the CAS instructions in armv8.1.
> 
> The C2 code for aarch64_enc_cmpxchg* is missing.
> 
> It's quite tricky to refactor to allow LSE instructions.  I'd add
> a wordsize parameter to the cas instruction, like this:
> 
> #define INSN(NAME, a, r)                                                \
>   void NAME(operand_size sz, Register Rs, Register Rt, Register Rn) {   \
>     assert(Rs != Rn && Rs != Rt, "unpredictable instruction");          \
>     compare_and_swap(Rs, Rt, Rn, sz, 1, a, r);                          \
>   }
>   INSN(cas, 0, 0)
> 
> And this gets rid of a ton of instruction definitions: we only need
> CAS{A,L,AL}.
> 
> Pass the operand size down to MacroAssembler::cmpxchgw:
> 
>   enc_class aarch64_enc_cmpxchgw(memory mem, iRegINoSp oldval, iRegINoSp newval) %{
>     MacroAssembler _masm(&cbuf);
>     guarantee($mem$$index == -1 && $mem$$disp == 0, "impossible encoding");
>     __ cmpxchg(Assembler::word, $mem$$base$$Register, $oldval$$Register,
>                $newval$$Register,
>                &Assembler::ldxrw, &MacroAssembler::cmpw, &Assembler::stlxrw);
>   %}
> 
> void MacroAssembler::cmpxchgw(operand_size sz, Register oldv,
>                               Register newv, Register addr, Register tmp,
> 			      Label &succeed, Label *fail) {
> 
>   if (UseLSE) {
>     ...
> 
> It'll be necessary to pass a memory barrier flag too.

You mean to deal with the difference between aarch64_enc_cmpxchg and
aarch64_enc_cmpxchg_acq? The former uses ldxr and is employed for CAS
when UseBarriersForVolatile is true. The latter uses ldaxr and is
employed when we optimize CAS because UseBarriersForVolatile is false.
We need to use the relevant flavour of casxx iside cmpxchg for each of
these two encodings.

I was also going to recommend using LSE in cmpxchg but I was not sure
exactly how it would need to work. The lock code does not loop when the
stlxr fails (it branches to cas_failed). However the CAS code loops back
to retry the load. If cmpxchg is rewritten to use casal (or casl) does
it not still need to loop?

Also, what does casxx allow us to do to implement the weaker variants of
the new unsafe CAS API other than to include or exclude the acquire? Is
there a variant of CAS operations which could use casa rather than
casal? or even just cas?

regards,


Andrew Dinn
-----------


From aph at redhat.com  Wed Feb 24 16:53:49 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 24 Feb 2016 16:53:49 +0000
Subject: [aarch64-port-dev ] RFR: 8150394: aarch64: add support for 8.1
	LSE CAS instructions
In-Reply-To: <56CDDF72.9080304@redhat.com>
References: <1456173130.2735.8.camel@mint> <56CD8CCF.1030404@redhat.com>
	<56CDDF72.9080304@redhat.com>
Message-ID: <56CDE01D.6080702@redhat.com>

On 02/24/2016 04:50 PM, Andrew Dinn wrote:
> You mean to deal with the difference between aarch64_enc_cmpxchg and
> aarch64_enc_cmpxchg_acq?

We now have CAS for non-ordered memory too.

I'm preparing a patch as we speak.  It should become clearer.

Andrew.


From aleksey.shipilev at oracle.com  Wed Feb 24 17:25:21 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 24 Feb 2016 20:25:21 +0300
Subject: RFR (S) 8150534: C1 compilation fails with "Constant field loads are
	folded during parsing"
Message-ID: <56CDE781.9050706@oracle.com>

Hi,

In JDK-8150102, we assumed that all suitable constants are exposed as
Constants after parsing, and added the assert to test that invariant is
true. And of course, it asserts in some corner cases which we cannot
reliably reproduce.

With no clear way to fix the underlying issue, we would like to
re-introduce the deleted branch in Canonicalizer:
  https://bugs.openjdk.java.net/browse/JDK-8150534
  http://cr.openjdk.java.net/~shade/8150534/webrev.01/

Note that it fixes the case when -XX:+PatchALot is used, which
definitely asserts. Some tests unreliably assert even with
out-of-the-box config. I forked the investigation about the Constant
field loads to:
  https://bugs.openjdk.java.net/browse/JDK-8150547

Testing: regression tests; JPRT (in progress)

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From vladimir.x.ivanov at oracle.com  Wed Feb 24 18:17:54 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 24 Feb 2016 21:17:54 +0300
Subject: RFR (S) 8150534: C1 compilation fails with "Constant field loads
	are folded during parsing"
In-Reply-To: <56CDE781.9050706@oracle.com>
References: <56CDE781.9050706@oracle.com>
Message-ID: <56CDF3D2.8090803@oracle.com>

The failures are caused by ScavengeRootsInCode < 2. In such case, 
compilers don't constant fold object-producing loads, because they can 
lead to embedded oops. But it's fine to constant fold an array length, 
since it produces an int.

I suggest the following adjustments [1]:

   (1) add the following assert:
      if (field->is_constant() && field->is_static()) {
+      assert(PatchALot || ScavengeRootsInCode < 2, "Constant field 
loads are folded during parsing");

   (2) replace the guarantee with an assert (hidden in as_array()); 
verifier should guarantee the arrayref points to an array:

        if (!c->is_null_object()) {
-        guarantee(c->is_array(), "Arraylength should reference the array");
-        set_constant(((ciArray*) c)->length());
+        set_constant(c->as_array()->length());
        }

   (3) add 2 new test modes to the test:

+ * @run main/othervm ... -XX:ScavengeRootsInCode=0
+ * @run main/othervm ... -XX:ScavengeRootsInCode=1

Best regards,
Vladimir Ivanov

[1] diff --git a/src/share/vm/c1/c1_Canonicalizer.cpp 
b/src/share/vm/c1/c1_Canonicalizer.cpp
--- a/src/share/vm/c1/c1_Canonicalizer.cpp
+++ b/src/share/vm/c1/c1_Canonicalizer.cpp
@@ -248,10 +248,10 @@
    } else if ((lf = x->array()->as_LoadField()) != NULL) {
      ciField* field = lf->field();
      if (field->is_constant() && field->is_static()) {
+      assert(PatchALot || ScavengeRootsInCode < 2, "Constant field 
loads are folded during parsing");
        ciObject* c = field->constant_value().as_object();
        if (!c->is_null_object()) {
-        guarantee(c->is_array(), "Arraylength should reference the array");
-        set_constant(((ciArray*) c)->length());
+        set_constant(c->as_array()->length());
        }
      }
    }
diff --git a/test/compiler/c1/CanonicalizeArrayLength.java 
b/test/compiler/c1/CanonicalizeArrayLength.java
--- a/test/compiler/c1/CanonicalizeArrayLength.java
+++ b/test/compiler/c1/CanonicalizeArrayLength.java
@@ -27,6 +27,8 @@
   * @summary C1 crashes in Canonicalizer::do_ArrayLength() after fix 
for JDK-8150102
   * @run main/othervm -XX:CompileThreshold=100 -XX:+TieredCompilation 
-XX:TieredStopAtLevel=1 -XX:-BackgroundCompilation 
CanonicalizeArrayLength
   * @run main/othervm -XX:CompileThreshold=100 -XX:+TieredCompilation 
-XX:TieredStopAtLevel=1 -XX:-BackgroundCompilation -XX:+PatchALot 
CanonicalizeArrayLength
+ * @run main/othervm -XX:CompileThreshold=100 -XX:+TieredCompilation 
-XX:TieredStopAtLevel=1 -XX:-BackgroundCompilation 
-XX:ScavengeRootsInCode=0 CanonicalizeArrayLength
+ * @run main/othervm -XX:CompileThreshold=100 -XX:+TieredCompilation 
-XX:TieredStopAtLevel=1 -XX:-BackgroundCompilation 
-XX:ScavengeRootsInCode=1 CanonicalizeArrayLength
   *
   */

On 2/24/16 8:25 PM, Aleksey Shipilev wrote:
> Hi,
>
> In JDK-8150102, we assumed that all suitable constants are exposed as
> Constants after parsing, and added the assert to test that invariant is
> true. And of course, it asserts in some corner cases which we cannot
> reliably reproduce.
>
> With no clear way to fix the underlying issue, we would like to
> re-introduce the deleted branch in Canonicalizer:
>    https://bugs.openjdk.java.net/browse/JDK-8150534
>    http://cr.openjdk.java.net/~shade/8150534/webrev.01/
>
> Note that it fixes the case when -XX:+PatchALot is used, which
> definitely asserts. Some tests unreliably assert even with
> out-of-the-box config. I forked the investigation about the Constant
> field loads to:
>    https://bugs.openjdk.java.net/browse/JDK-8150547
>
> Testing: regression tests; JPRT (in progress)
>
> Thanks,
> -Aleksey
>

From aleksey.shipilev at oracle.com  Wed Feb 24 18:37:49 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 24 Feb 2016 21:37:49 +0300
Subject: RFR (S) 8150534: C1 compilation fails with "Constant field loads
	are folded during parsing"
In-Reply-To: <56CDF3D2.8090803@oracle.com>
References: <56CDE781.9050706@oracle.com> <56CDF3D2.8090803@oracle.com>
Message-ID: <56CDF87D.1090405@oracle.com>

On 02/24/2016 09:17 PM, Vladimir Ivanov wrote:
> The failures are caused by ScavengeRootsInCode < 2. In such case,
> compilers don't constant fold object-producing loads, because they can
> lead to embedded oops. But it's fine to constant fold an array length,
> since it produces an int.

Oh, that explains it, thanks!

> I suggest the following adjustments [1]:

Agreed:
  http://cr.openjdk.java.net/~shade/8150534/webrev.02/

-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From vladimir.x.ivanov at oracle.com  Wed Feb 24 18:39:36 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 24 Feb 2016 21:39:36 +0300
Subject: RFR (S) 8150534: C1 compilation fails with "Constant field loads
	are folded during parsing"
In-Reply-To: <56CDF87D.1090405@oracle.com>
References: <56CDE781.9050706@oracle.com> <56CDF3D2.8090803@oracle.com>
	<56CDF87D.1090405@oracle.com>
Message-ID: <56CDF8E8.5070300@oracle.com>

>    http://cr.openjdk.java.net/~shade/8150534/webrev.02/
Looks good.

Best regards,
Vladimir Ivanov

From aleksey.shipilev at oracle.com  Wed Feb 24 19:09:26 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 24 Feb 2016 22:09:26 +0300
Subject: [9] RFR (XS): 8150436: Incorrect invocation mode when
	linkToInteface linker is eliminated
In-Reply-To: <56CDD6E5.2090001@oracle.com>
References: <56CDD6E5.2090001@oracle.com>
Message-ID: <56CDFFE6.1090709@oracle.com>

On 02/24/2016 07:14 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8150436/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8150436

This is my first time looking into that code, but the description and
the fix make sense.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From aleksey.shipilev at oracle.com  Wed Feb 24 20:08:49 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 24 Feb 2016 23:08:49 +0300
Subject: RFR (S) 8150514: C1 crashes in Canonicalizer::do_ArrayLength()
	after fix for JDK-8150102
In-Reply-To: <56CD86AD.1010502@oracle.com>
References: <56CD738E.3040502@oracle.com> <56CD7669.6070705@oracle.com>
	<56CD783F.3010509@oracle.com> <56CD86AD.1010502@oracle.com>
Message-ID: <56CE0DD1.7040507@oracle.com>

On 02/24/2016 01:32 PM, Vladimir Ivanov wrote:
>>    http://cr.openjdk.java.net/~shade/8150514/webrev.02/
> Reviewed.

Thanks Vladimir and Tobias, pushed.

-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From christian.thalinger at oracle.com  Wed Feb 24 21:00:40 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 24 Feb 2016 11:00:40 -1000
Subject: RFR: 8150561: [AArch64] JVMCI improvements
Message-ID: 

https://bugs.openjdk.java.net/browse/JDK-8150561
http://cr.openjdk.java.net/~twisti/8150561/webrev.01/

With these changes it is possible to run Graal?s bytecode unit tests.

The patch includes a change in src/share/vm/jvmci/jvmciCodeInstaller.cpp to use PrintNMethods and CompileCommand directives to print disassembly when code installation is not going through the broker.

Also, it includes a fix for a mis-merge in src/share/vm/runtime/frame.cpp which broke printing of method names for JVMCI compiled methods:

# J 20 JVMCI  (null)null (196 bytes) @ 0x00007fb38a369f2f [0x00007fb38a369e80+0x00000000000000af]


From vladimir.kozlov at oracle.com  Wed Feb 24 23:12:52 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Feb 2016 15:12:52 -0800
Subject: RFR: 8150561: [AArch64] JVMCI improvements
In-Reply-To: 
References: 
Message-ID: <56CE38F4.4010304@oracle.com>

Looks good.

Thanks,
Vladimir

On 2/24/16 1:00 PM, Christian Thalinger wrote:
> https://bugs.openjdk.java.net/browse/JDK-8150561
> http://cr.openjdk.java.net/~twisti/8150561/webrev.01/
>
> With these changes it is possible to run Graal?s bytecode unit tests.
>
> The patch includes a change in src/share/vm/jvmci/jvmciCodeInstaller.cpp to use PrintNMethods and CompileCommand directives to print disassembly when code installation is not going through the broker.
>
> Also, it includes a fix for a mis-merge in src/share/vm/runtime/frame.cpp which broke printing of method names for JVMCI compiled methods:
>
> # J 20 JVMCI  (null)null (196 bytes) @ 0x00007fb38a369f2f [0x00007fb38a369e80+0x00000000000000af]
>

From vladimir.kozlov at oracle.com  Wed Feb 24 23:25:26 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Feb 2016 15:25:26 -0800
Subject: [9] RFR (XS): 8150436: Incorrect invocation mode when
	linkToInteface linker is eliminated
In-Reply-To: <56CDD6E5.2090001@oracle.com>
References: <56CDD6E5.2090001@oracle.com>
Message-ID: <56CE3BE6.2010805@oracle.com>

Looks good.

Thanks,
Vladimir

On 2/24/16 8:14 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8150436/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8150436
>
> When MH.linkToInterface is eliminated, but the target method is not
> inlined, either default or concrete method is attached to the call site.
> During call site resolution, invokeinterface invocation mode is used,
> but resolution fails when the target method is concrete.
>
> The fix is to adjust invocation mode to invokevirtual when concrete
> method is attached.
>
> Testing: failing test, JPRT.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov

From vladimir.kozlov at oracle.com  Thu Feb 25 00:29:44 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Feb 2016 16:29:44 -0800
Subject: [9] RFR (S): 8150186: Folding mismatched accesses with @Stable is
	incorrect
In-Reply-To: <56CDD4F4.2070907@oracle.com>
References: <56CDD4F4.2070907@oracle.com>
Message-ID: <56CE4AF8.20401@oracle.com>

Looks good.

Test: Copyright 2016.

Thanks,
Vladimir

On 2/24/16 8:06 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8150186/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8150186
>
> Constant folding from stable arrays doesn't check for mismatched accesses.
>
> The fix is to disable the optimization for mismatched accesses.
>
> Also, added missing range checks in ciArray::element_value_by_offset.
>
> Testing: failing tests, JPRT
>
> Best regards,
> Vladimir Ivanov
>
> PS: I considered converting is_mismatched_access check in
> fold_stable_ary_elem into an assert, but I spotted some quirks in
> mismatched access detection (filed JDK-8150543 [1]). So, I'd prefer to
> keep the check and refine the code as part of JDK-8150543 when more test
> coverage is available.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8150543

From vladimir.kozlov at oracle.com  Thu Feb 25 00:31:43 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Feb 2016 16:31:43 -0800
Subject: RFR(S): 8148159: [TESTBUG] TestCompilerDirectivesCompatibility
	tests fails on non-tiered server VMs
In-Reply-To: <56CDBD01.1040909@oracle.com>
References: <56C31DA9.3070607@oracle.com>
	<115A77CE-C62D-4749-8E4A-2EE4A2F662AB@oracle.com>
	<56CAD94F.8080406@oracle.com> <56CAE4FD.7000605@oracle.com>
	<56CCE01D.9060701@oracle.com> <56CD7077.5010105@oracle.com>
	<56CDBD01.1040909@oracle.com>
Message-ID: <56CE4B6F.1050405@oracle.com>

This look good.

Thanks,
Vladimir

On 2/24/16 6:24 AM, Nils Eliasson wrote:
> On second thought - I'll import the constants from CompilerWhiteBox and
> then we can discuss what we want to do with CompilerUtils and
> CompilerWhiteBox in the future.
>
> Webrev: http://cr.openjdk.java.net/~neliasso/8148159/webrev.03/
> JDK Webrev: http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.02/
> (Not changed)
>
> Best regards,
> Nils Eliasson
>
> On 2016-02-24 09:57, Nils Eliasson wrote:
>> Hi Vladimir,
>>
>> CompilerWhiteBoxTest.java includes a lot of other unrelated things
>> too. I suggest to put all the common constants in CompilerUtils and
>> import that one into CompilerWhiteBox.
>>
>> Regards,
>> Nils
>>
>> On 2016-02-23 23:41, Vladimir Kozlov wrote:
>>> COMP_LEVEL_* is mess. I see a several tests which are repeating their
>>> definitions.
>>> I think we should use the same values already defined in
>>> test/compiler/whitebox/CompilerWhiteBoxTest.java
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 2/22/16 2:37 AM, Nils Eliasson wrote:
>>>> Hi,
>>>>
>>>> Webrev using comp levels from CompilerUtils instead:
>>>>
>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev.02/
>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.02/
>>>>
>>>> Best regards,
>>>> Nils Eliasson
>>>>
>>>> On 2016-02-22 10:47, Nils Eliasson wrote:
>>>>> Hi Pavel,
>>>>>
>>>>> On 2016-02-17 16:52, Pavel Punegov wrote:
>>>>>> Hi Nils,
>>>>>>
>>>>>> Do we need hasC1/2Compiler methods?
>>>>>
>>>>> I wanted to know exactly what compilers I am testing.
>>>>>
>>>>>> There is a compiler.tstlibrary.CompilerUtils class that provides
>>>>>> tests with available levels.
>>>>>
>>>>> Didn't know about that one. It fills a good purpose but it should
>>>>> not guess what compiler levels are available -
>>>>> rather query the VM directly. We should also move a lot of useful
>>>>> constants from CompilerWhiteBoxTest to CompilerUtils.
>>>>>
>>>>>> There is an example of usage in
>>>>>> test/compiler/compilercontrol/share/actions/CompileAction.java.
>>>>>> Also, what about JVMCI in case of hasC2Compiler? AFAIK it works
>>>>>> with levels, but I don?t know if it will with such ifdef.
>>>>>
>>>>> I only test the compilers that I know will support this flag. We
>>>>> would need some additional test utils for querying
>>>>> what compiler uses the JVMCI interface.
>>>>>
>>>>>>
>>>>>> Otherwise, it looks good (not a Reviewer)
>>>>>
>>>>> Thanks for taking a look,
>>>>> Nils
>>>>>
>>>>>>
>>>>>>> On 16 Feb 2016, at 16:01, Nils Eliasson >>>>>> > wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review this change.
>>>>>>>
>>>>>>> The tests relied on C1 always being available and thus fails on
>>>>>>> C2 only server configurations. The fix adds two
>>>>>>> whitebox methods for checking if C1 and C2 is available, and then
>>>>>>> tests both compilers separately. Also adding
>>>>>>> Xmixed to the commandline since this test doesn't need Xcomp
>>>>>>> testing.
>>>>>>>
>>>>>>> Bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8148159
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev.01/
>>>>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.01/
>>>>>>>
>>>>>>> Regards,
>>>>>>> Nils Eliasson
>>>>>>
>>>>>>
>>>>>>
>>>>>> ? Thanks,
>>>>>> Pavel Punegov
>>>>>>
>>>>>
>>>>
>>
>

From vladimir.kozlov at oracle.com  Thu Feb 25 00:40:01 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Feb 2016 16:40:01 -0800
Subject: RFR(S/M): 8069160:
	serviceability/dcmd/compiler/CompilerQueueTest.java fails due to class
	not found
In-Reply-To: <56CDB8ED.3070907@oracle.com>
References: <56CDB8ED.3070907@oracle.com>
Message-ID: <56CE4D61.1010100@oracle.com>

Seems fine.

Thanks,
Vladimir

On 2/24/16 6:06 AM, Nils Eliasson wrote:
> Hi,
>
> I need a review of this fix of the CompilerQueueTest.
>
> Summary:
> This test was checking the output from the Compiler.queue diagnostic
> command - testing each queue entry by reflection. This was fragile
> because different methods end up in the queue every run and what classes
> are reflectable changes over time.
>
> Solution:
> In the improved version the whitebox API is used to block compilation
> and then enqueue methods for all available compilation levels. Then the
> jcmd is executed and the output is verified to contain the specific test
> methods. In some scenarios where the compile queue is overwhelmed by
> requestm, entries might get evicted. The test take that into account too.
>
> Testing:
> Run test on all platforms
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8069160
> Webrev: http://cr.openjdk.java.net/~neliasso/8069160/webrev.03/
>
> Best regards,
> Nils Eliasson

From chris.plummer at oracle.com  Thu Feb 25 00:57:46 2016
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 24 Feb 2016 16:57:46 -0800
Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1
In-Reply-To: <56B40480.6060703@oracle.com>
References: <56B2FBB4.70407@oracle.com> <56B3FE5A.9010806@oracle.com>
	<56B40480.6060703@oracle.com>
Message-ID: <56CE518A.2050706@oracle.com>

Hello,

I still need to finish up review of this change. I added the change that 
David suggested. Since it's minor, I'll just post the code from 
arguments.cpp here:

#if !defined(COMPILER2) && !INCLUDE_JVMCI
   UNSUPPORTED_OPTION(ProfileInterpreter, "ProfileInterpreter");
   UNSUPPORTED_OPTION(TraceProfileInterpreter, "TraceProfileInterpreter");
   UNSUPPORTED_OPTION(PrintMethodData, "PrintMethodData");
#endif

The ProfileInterpreter related code was in the original code review. The 
other two flag checks I just added.

thanks,

Chris

On 2/4/16 6:10 PM, Chris Plummer wrote:
> Hi David,
>
> On 2/4/16 5:43 PM, David Holmes wrote:
>> Hi Chris,
>>
>> On 4/02/2016 5:20 PM, Chris Plummer wrote:
>>> Hello,
>>>
>>> Please review the following for removing Method::_method_data when only
>>> supporting C1 (or more specifically, when not supporting C2 or JVMCI).
>>
>> Does JVMCI exist with C1 only?
> My understanding is it can exists with C2 or on its own, but currently 
> is not included with C1 builds.
>> The COMPILER2_OR_JVMCI conjunction makes things a bit messy. Can we 
>> abstract that behind a single variable, INCLUDE_METHOD_DATA (or some 
>> such) to make it cleaner?
> I'll also be using COMPILER2_OR_JVMCI with another change to that 
> removes some MethodCounter fields. So yes, I can add 
> INCLUDE_METHOD_DATA, but then will need another INCLUDE_XXX for the 
> MethodCounter fields I'll be conditionally removing.
>>
>>> This will help reduce dynamic footprint usage for the minimal VM.
>>>
>>> As part of this fix, ProfileInterperter is forced to false unless C2 or
>>> JVMCI is supported. This was mainly done to avoid crashes if it is
>>> turned on and Method::_method_data has been excluded, but also because
>>> it is not useful except to C2 or JVMCI.
>>
>> Are you saying that the information generated by ProfileInterpreter 
>> is only used by C2 and JVMCI? If that is case it should really have 
>> been a C2 only flag.
>>
> That is my understanding. Coleen confirmed it for me. I believe she 
> got her info from the compiler team. BTW, we need a mechanism to make 
> these conditionally unsupported flags a constant value when they are 
> not supported. It would help deadstrip code.
>> If ProfileInterpreter is forced to false then shouldn't you also be 
>> checking TraceProfileInterpreter and PrintMethodData use as well
> Yes, I can add those.
>
> thanks,
>
> Chris
>>
>> Thanks,
>> David
>>
>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8147978/webrev.02/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147978
>>>
>>> Test with JPRT -testset hotspot.
>>>
>>> thanks,
>>>
>>> Chris
>


From christian.thalinger at oracle.com  Thu Feb 25 02:23:34 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 24 Feb 2016 16:23:34 -1000
Subject: RFR: 8150561: [AArch64] JVMCI improvements
In-Reply-To: <56CE38F4.4010304@oracle.com>
References: 
	<56CE38F4.4010304@oracle.com>
Message-ID: <92E72F97-AE84-4379-A320-EEA5ABB980E2@oracle.com>

Thanks, Vladimir.

> On Feb 24, 2016, at 1:12 PM, Vladimir Kozlov  wrote:
> 
> Looks good.
> 
> Thanks,
> Vladimir
> 
> On 2/24/16 1:00 PM, Christian Thalinger wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8150561
>> http://cr.openjdk.java.net/~twisti/8150561/webrev.01/
>> 
>> With these changes it is possible to run Graal?s bytecode unit tests.
>> 
>> The patch includes a change in src/share/vm/jvmci/jvmciCodeInstaller.cpp to use PrintNMethods and CompileCommand directives to print disassembly when code installation is not going through the broker.
>> 
>> Also, it includes a fix for a mis-merge in src/share/vm/runtime/frame.cpp which broke printing of method names for JVMCI compiled methods:
>> 
>> # J 20 JVMCI  (null)null (196 bytes) @ 0x00007fb38a369f2f [0x00007fb38a369e80+0x00000000000000af]
>> 


From vladimir.kozlov at oracle.com  Thu Feb 25 02:53:35 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Feb 2016 18:53:35 -0800
Subject: [9] RFR (S): 8148754: C2 loop unrolling fails due to unexpected
	graph shape
In-Reply-To: <56CB1997.40107@oracle.com>
References: <56C1ED18.6060903@oracle.com> <56C26929.4050706@oracle.com>
	<56CB1997.40107@oracle.com>
Message-ID: <56CE6CAF.9090904@oracle.com>

So it is again _major_progress problem.
I have to spend more time on this. It is not simple.

We may add an other state when Ideal transformation could be executed. 
For example, after all loop opts:

http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/0fc557e05fc0/src/share/vm/opto/compile.cpp#l2286

Or more states to specify which Ideal transformations and loop 
optimizations could be executed in which state.

The main problem from your description is elimination of Opaque1 on 
which loop optimizations relies.

We can simply remove Opaque1Node::Identity(PhaseGVN* phase) because 
PhaseMacroExpand::expand_macro_nodes() will remove them after all loop 
opts. On other hand we may do want to execute some simple loop 
optimizations even after Opaque, CastII and CastI2L are optimized out. 
For example, removing empty loops or one iteration loops (pre-loops). 
But definitely not ones which use cloning or other aggressive optimizations.

Inline_Warm() is not used since InlineWarmCalls for very long time. The 
code could be very rotten by now. So removing set_major_progress from it 
is fine.

It is also fine to remove it from inline_incrementally since it will be 
restored by skip_loop_opts code (and cleared if method is empty or set 
if there are expensive nodes).

LoopNode::Ideal() change seems also fine. LoopNode is created only in 
loop opts (RootNode has own Ideal()) so if it has TOP input it will be 
removed by RegionNode::Ideal most likely.

Which leaves remove_useless_bool() code only and I have concern about 
it. It could happened after CCP phase and we may want to execute loop 
opts after it. I am actually want to set major progress after CCP 
unconditionally since some If nodes could be folded by it.

As you can see it is not simple :(

Thanks,
Vladimir

On 2/22/16 6:22 AM, Zolt?n Maj? wrote:
> Hi Vladimir,
>
>
> thank you for the feedback!
>
> On 02/16/2016 01:11 AM, Vladimir Kozlov wrote:
>> Zoltan,
>>
>> It should not be "main" loop if peeling happened. See do_peeling():
>>
>>     if (cl->is_main_loop()) {
>>       cl->set_normal_loop();
>>
>> Split-if optimization should not split through loop's phi. And
>> generally not through loop's head since it is not making code better -
>> split through backedge moves code into loop again. Making loop body
>> more complicated as this case shows.
>
> I did more investigation to understand what causes the invalid graph
> shape to appear. It seems that the invalid graph shape appears because
> the compiler uses the Compile:: _major_progress inconsistently. Here are
> some details.
>
> - If _major_progress *is set*, the compiler expects more loop
> optimizations to happen. Therefore, certain transformations on the graph
> are not allowed so that the graph is in a shape that can be processed by
> loop optimizations. See:
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/2c3c43037e14/src/share/vm/opto/convertnode.cpp#l253
>
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/2c3c43037e14/src/share/vm/opto/castnode.cpp#l251
>
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/2c3c43037e14/src/share/vm/opto/loopnode.cpp#l950
>
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/2c3c43037e14/src/share/vm/opto/opaquenode.cpp#l37
>
>
> - If _major_progress *is not set*, the compiler is allowed to perform
> all possible transformations (because it does not have to care about
> future loop optimizations).
>
> The crash reported for the current issue appears because _major_progress
> *can be accidentally set again* after the compiler decided to stop
> performing loop optimizations. As a result, invalid graph shapes appear.
>
> Here are details about how this happens for both failures I've been
> studying:
> https://bugs.openjdk.java.net/browse/JDK-8148754?focusedCommentId=13901941&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13901941
>
>
> I would propose to change the compiler to use _major_progress
> consistently. (This goes into the same direction as Tobias's recent work
> on JDK-8144487.)
>
> I propose that _major_progress:
> - can be SET when the compiler is initialized (because loop
> optimizations are expected to happen afterwards);
> - can be SET/RESET in the scope of loop optimizations (because we want
> to see if loop optimizations made progress);
> - cannot be SET/RESET by neither incremental inlining nor IGVN (even if
> the IGVN is performed in the scope of loop optimizations).
>
> Here is the updated webrev:
> http://cr.openjdk.java.net/~zmajo/8148754/webrev.02/
>
> Performance evaluation:
> - The proposed webrev does not cause performance regressions for
> SPECjvm2008, SPECjbb2005, and Octane.
>
> Testing:
> - all hotspot JTREG tests on all supported platforms;
> - JPRT;
> - failing test case.
>
> Thank you and best regards,
>
>
> Zoltan
>
>
>>
>> Bailout unrolling is fine but performance may suffer because in some
>> cases loop unrolling is better then split-if.
>
>
>>
>> Thanks,
>> Vladimir
>>
>> On 2/15/16 7:22 AM, Zolt?n Maj? wrote:
>>> Hi,
>>>
>>>
>>> please review the patch for 8148754.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8148754
>>>
>>> Problem: Compilation fails when the C2 compiler attempts loop unrolling.
>>> The cause of the failure is that the loop unrolling optimization expects
>>> a well-defined graph shape at the entry control of a 'CountedLoopNode'
>>> ('IfTrue'/'IfFalse' preceeded by 'If' preceeded by 'Bool' preceeded by
>>> 'CmpI').
>>>
>>>
>>> Solution: I investigated several different instances of the same
>>> failure. It turns out that the shape of the graph at a loop's entry
>>> control is often different from the way loop unrolling expects it to be
>>> (please find some examples in the bug's JBS issue). The various graph
>>> shapes are a result of previously performed transformations, e.g.,
>>> split-if optimization and loop peeling.
>>>
>>> Loop unrolling requires the above mentioned graph shape so that it can
>>> adjust the zero-trip guard of the loop. With the unexpected graph
>>> shapes, it is not possible to perform loop unrolling. However, the graph
>>> is still in a valid state (except for loop unrolling) and can be used to
>>> produce correct code.
>>>
>>> I propose that (1) we check if an unexpected graph shape is encountered
>>> and (2) bail out of loop unrolling if it is (but not fail in the
>>> compiler in such cases).
>>>
>>> The failure was triggered by Aleksey's Indify String Concatenation
>>> changes but the generated bytecodes are valid. So this seems to be a
>>> compiler issue that was previously there but was not yet triggered.
>>>
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~zmajo/8148754/webrev.00/
>>>
>>> Testing:
>>> - JPRT;
>>> - local testing (linux-86_64) with the failing test case;
>>> - executed all hotspot tests locally, all tests pass that pass with an
>>> unmodified build.
>>>
>>> Thank you!
>>>
>>> Best regards,
>>>
>>>
>>> Zoltan
>>>
>

From john.r.rose at oracle.com  Thu Feb 25 04:56:06 2016
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 24 Feb 2016 20:56:06 -0800
Subject: [9] RFR (S): 8150186: Folding mismatched accesses with @Stable is
	incorrect
In-Reply-To: <56CDD4F4.2070907@oracle.com>
References: <56CDD4F4.2070907@oracle.com>
Message-ID: <78F4D925-399D-416A-8F9E-E635D1250175@oracle.com>

Reviewed. 

? John

> On Feb 24, 2016, at 8:06 AM, Vladimir Ivanov  wrote:
> 
> http://cr.openjdk.java.net/~vlivanov/8150186/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8150186
> 
> Constant folding from stable arrays doesn't check for mismatched accesses.
> 
> The fix is to disable the optimization for mismatched accesses.
> 
> Also, added missing range checks in ciArray::element_value_by_offset.
> 
> Testing: failing tests, JPRT
> 
> Best regards,
> Vladimir Ivanov
> 
> PS: I considered converting is_mismatched_access check in fold_stable_ary_elem into an assert, but I spotted some quirks in mismatched access detection (filed JDK-8150543 [1]). So, I'd prefer to keep the check and refine the code as part of JDK-8150543 when more test coverage is available.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8150543

From david.holmes at oracle.com  Thu Feb 25 07:46:17 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 25 Feb 2016 17:46:17 +1000
Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1
In-Reply-To: <56CE518A.2050706@oracle.com>
References: <56B2FBB4.70407@oracle.com> <56B3FE5A.9010806@oracle.com>
	<56B40480.6060703@oracle.com> <56CE518A.2050706@oracle.com>
Message-ID: <56CEB149.6050208@oracle.com>

On 25/02/2016 10:57 AM, Chris Plummer wrote:
> Hello,
>
> I still need to finish up review of this change. I added the change that
> David suggested. Since it's minor, I'll just post the code from
> arguments.cpp here:
>
> #if !defined(COMPILER2) && !INCLUDE_JVMCI
>    UNSUPPORTED_OPTION(ProfileInterpreter, "ProfileInterpreter");
>    UNSUPPORTED_OPTION(TraceProfileInterpreter, "TraceProfileInterpreter");
>    UNSUPPORTED_OPTION(PrintMethodData, "PrintMethodData");
> #endif
>
> The ProfileInterpreter related code was in the original code review. The
> other two flag checks I just added.

That addition seems fine to me. But I'll leave it to the compiler folk 
to review the core changes.

Thanks,
David

> thanks,
>
> Chris
>
> On 2/4/16 6:10 PM, Chris Plummer wrote:
>> Hi David,
>>
>> On 2/4/16 5:43 PM, David Holmes wrote:
>>> Hi Chris,
>>>
>>> On 4/02/2016 5:20 PM, Chris Plummer wrote:
>>>> Hello,
>>>>
>>>> Please review the following for removing Method::_method_data when only
>>>> supporting C1 (or more specifically, when not supporting C2 or JVMCI).
>>>
>>> Does JVMCI exist with C1 only?
>> My understanding is it can exists with C2 or on its own, but currently
>> is not included with C1 builds.
>>> The COMPILER2_OR_JVMCI conjunction makes things a bit messy. Can we
>>> abstract that behind a single variable, INCLUDE_METHOD_DATA (or some
>>> such) to make it cleaner?
>> I'll also be using COMPILER2_OR_JVMCI with another change to that
>> removes some MethodCounter fields. So yes, I can add
>> INCLUDE_METHOD_DATA, but then will need another INCLUDE_XXX for the
>> MethodCounter fields I'll be conditionally removing.
>>>
>>>> This will help reduce dynamic footprint usage for the minimal VM.
>>>>
>>>> As part of this fix, ProfileInterperter is forced to false unless C2 or
>>>> JVMCI is supported. This was mainly done to avoid crashes if it is
>>>> turned on and Method::_method_data has been excluded, but also because
>>>> it is not useful except to C2 or JVMCI.
>>>
>>> Are you saying that the information generated by ProfileInterpreter
>>> is only used by C2 and JVMCI? If that is case it should really have
>>> been a C2 only flag.
>>>
>> That is my understanding. Coleen confirmed it for me. I believe she
>> got her info from the compiler team. BTW, we need a mechanism to make
>> these conditionally unsupported flags a constant value when they are
>> not supported. It would help deadstrip code.
>>> If ProfileInterpreter is forced to false then shouldn't you also be
>>> checking TraceProfileInterpreter and PrintMethodData use as well
>> Yes, I can add those.
>>
>> thanks,
>>
>> Chris
>>>
>>> Thanks,
>>> David
>>>
>>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8147978/webrev.02/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147978
>>>>
>>>> Test with JPRT -testset hotspot.
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>
>

From aleksey.shipilev at oracle.com  Thu Feb 25 09:21:37 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 25 Feb 2016 12:21:37 +0300
Subject: RFR (S) 8150534: C1 compilation fails with "Constant field loads
	are folded during parsing"
In-Reply-To: <56CDF8E8.5070300@oracle.com>
References: <56CDE781.9050706@oracle.com> <56CDF3D2.8090803@oracle.com>
	<56CDF87D.1090405@oracle.com> <56CDF8E8.5070300@oracle.com>
Message-ID: <56CEC7A1.90504@oracle.com>

On 02/24/2016 09:39 PM, Vladimir Ivanov wrote:
>>    http://cr.openjdk.java.net/~shade/8150534/webrev.02/
> Looks good.

Thanks Vladimir!

Any more reviews? I'd like to push this.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From nils.eliasson at oracle.com  Thu Feb 25 09:38:25 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 25 Feb 2016 10:38:25 +0100
Subject: RFR(S): 8148159: [TESTBUG] TestCompilerDirectivesCompatibility
	tests fails on non-tiered server VMs
In-Reply-To: <56CE4B6F.1050405@oracle.com>
References: <56C31DA9.3070607@oracle.com>
	<115A77CE-C62D-4749-8E4A-2EE4A2F662AB@oracle.com>
	<56CAD94F.8080406@oracle.com> <56CAE4FD.7000605@oracle.com>
	<56CCE01D.9060701@oracle.com> <56CD7077.5010105@oracle.com>
	<56CDBD01.1040909@oracle.com> <56CE4B6F.1050405@oracle.com>
Message-ID: <56CECB91.6040400@oracle.com>

Thank you Vladimir!

//Nils

On 2016-02-25 01:31, Vladimir Kozlov wrote:
> This look good.
>
> Thanks,
> Vladimir
>
> On 2/24/16 6:24 AM, Nils Eliasson wrote:
>> On second thought - I'll import the constants from CompilerWhiteBox and
>> then we can discuss what we want to do with CompilerUtils and
>> CompilerWhiteBox in the future.
>>
>> Webrev: http://cr.openjdk.java.net/~neliasso/8148159/webrev.03/
>> JDK Webrev: http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.02/
>> (Not changed)
>>
>> Best regards,
>> Nils Eliasson
>>
>> On 2016-02-24 09:57, Nils Eliasson wrote:
>>> Hi Vladimir,
>>>
>>> CompilerWhiteBoxTest.java includes a lot of other unrelated things
>>> too. I suggest to put all the common constants in CompilerUtils and
>>> import that one into CompilerWhiteBox.
>>>
>>> Regards,
>>> Nils
>>>
>>> On 2016-02-23 23:41, Vladimir Kozlov wrote:
>>>> COMP_LEVEL_* is mess. I see a several tests which are repeating their
>>>> definitions.
>>>> I think we should use the same values already defined in
>>>> test/compiler/whitebox/CompilerWhiteBoxTest.java
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 2/22/16 2:37 AM, Nils Eliasson wrote:
>>>>> Hi,
>>>>>
>>>>> Webrev using comp levels from CompilerUtils instead:
>>>>>
>>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev.02/
>>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.02/
>>>>>
>>>>> Best regards,
>>>>> Nils Eliasson
>>>>>
>>>>> On 2016-02-22 10:47, Nils Eliasson wrote:
>>>>>> Hi Pavel,
>>>>>>
>>>>>> On 2016-02-17 16:52, Pavel Punegov wrote:
>>>>>>> Hi Nils,
>>>>>>>
>>>>>>> Do we need hasC1/2Compiler methods?
>>>>>>
>>>>>> I wanted to know exactly what compilers I am testing.
>>>>>>
>>>>>>> There is a compiler.tstlibrary.CompilerUtils class that provides
>>>>>>> tests with available levels.
>>>>>>
>>>>>> Didn't know about that one. It fills a good purpose but it should
>>>>>> not guess what compiler levels are available -
>>>>>> rather query the VM directly. We should also move a lot of useful
>>>>>> constants from CompilerWhiteBoxTest to CompilerUtils.
>>>>>>
>>>>>>> There is an example of usage in
>>>>>>> test/compiler/compilercontrol/share/actions/CompileAction.java.
>>>>>>> Also, what about JVMCI in case of hasC2Compiler? AFAIK it works
>>>>>>> with levels, but I don?t know if it will with such ifdef.
>>>>>>
>>>>>> I only test the compilers that I know will support this flag. We
>>>>>> would need some additional test utils for querying
>>>>>> what compiler uses the JVMCI interface.
>>>>>>
>>>>>>>
>>>>>>> Otherwise, it looks good (not a Reviewer)
>>>>>>
>>>>>> Thanks for taking a look,
>>>>>> Nils
>>>>>>
>>>>>>>
>>>>>>>> On 16 Feb 2016, at 16:01, Nils Eliasson >>>>>>> > wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review this change.
>>>>>>>>
>>>>>>>> The tests relied on C1 always being available and thus fails on
>>>>>>>> C2 only server configurations. The fix adds two
>>>>>>>> whitebox methods for checking if C1 and C2 is available, and then
>>>>>>>> tests both compilers separately. Also adding
>>>>>>>> Xmixed to the commandline since this test doesn't need Xcomp
>>>>>>>> testing.
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8148159
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev.01/
>>>>>>>> http://cr.openjdk.java.net/~neliasso/8148159/webrev_jdk.01/
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Nils Eliasson
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ? Thanks,
>>>>>>> Pavel Punegov
>>>>>>>
>>>>>>
>>>>>
>>>
>>


From tobias.hartmann at oracle.com  Thu Feb 25 09:51:34 2016
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 25 Feb 2016 10:51:34 +0100
Subject: RFR (S) 8150534: C1 compilation fails with "Constant field loads
	are folded during parsing"
In-Reply-To: <56CEC7A1.90504@oracle.com>
References: <56CDE781.9050706@oracle.com> <56CDF3D2.8090803@oracle.com>
	<56CDF87D.1090405@oracle.com> <56CDF8E8.5070300@oracle.com>
	<56CEC7A1.90504@oracle.com>
Message-ID: <56CECEA6.4060905@oracle.com>

Hi Aleksey,

On 25.02.2016 10:21, Aleksey Shipilev wrote:
> On 02/24/2016 09:39 PM, Vladimir Ivanov wrote:
>>>    http://cr.openjdk.java.net/~shade/8150534/webrev.02/

This looks good to me.

Best regards,
Tobias

From nils.eliasson at oracle.com  Thu Feb 25 09:46:29 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 25 Feb 2016 10:46:29 +0100
Subject: RFR(S/M): 8069160:
	serviceability/dcmd/compiler/CompilerQueueTest.java fails due to class
	not found
In-Reply-To: <56CE4D61.1010100@oracle.com>
References: <56CDB8ED.3070907@oracle.com> <56CE4D61.1010100@oracle.com>
Message-ID: <56CECD75.3020705@oracle.com>

Thanks Vladimir!

//Nils

On 2016-02-25 01:40, Vladimir Kozlov wrote:
> Seems fine.
>
> Thanks,
> Vladimir
>
> On 2/24/16 6:06 AM, Nils Eliasson wrote:
>> Hi,
>>
>> I need a review of this fix of the CompilerQueueTest.
>>
>> Summary:
>> This test was checking the output from the Compiler.queue diagnostic
>> command - testing each queue entry by reflection. This was fragile
>> because different methods end up in the queue every run and what classes
>> are reflectable changes over time.
>>
>> Solution:
>> In the improved version the whitebox API is used to block compilation
>> and then enqueue methods for all available compilation levels. Then the
>> jcmd is executed and the output is verified to contain the specific test
>> methods. In some scenarios where the compile queue is overwhelmed by
>> requestm, entries might get evicted. The test take that into account 
>> too.
>>
>> Testing:
>> Run test on all platforms
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069160
>> Webrev: http://cr.openjdk.java.net/~neliasso/8069160/webrev.03/
>>
>> Best regards,
>> Nils Eliasson


From edward.nevill at gmail.com  Thu Feb 25 10:06:26 2016
From: edward.nevill at gmail.com (Edward Nevill)
Date: Thu, 25 Feb 2016 10:06:26 +0000
Subject: RFR: 8150394: aarch64: add support for 8.1 LSE CAS instructions
In-Reply-To: <56CD8CCF.1030404@redhat.com>
References: <1456173130.2735.8.camel@mint>  <56CD8CCF.1030404@redhat.com>
Message-ID: <1456394786.1383.18.camel@mint>

On Wed, 2016-02-24 at 10:58 +0000, Andrew Haley wrote:
> On 22/02/16 20:32, Edward Nevill wrote:

> And this gets rid of a ton of instruction definitions: we only need
> CAS{A,L,AL}.
> 
> Pass the operand size down to MacroAssembler::cmpxchgw:
> 
>   enc_class aarch64_enc_cmpxchgw(memory mem, iRegINoSp oldval, iRegINoSp newval) %{
>     MacroAssembler _masm(&cbuf);
>     guarantee($mem$$index == -1 && $mem$$disp == 0, "impossible encoding");
>     __ cmpxchg(Assembler::word, $mem$$base$$Register, $oldval$$Register,
>                $newval$$Register,
>                &Assembler::ldxrw, &MacroAssembler::cmpw, &Assembler::stlxrw);
>   %}
> 
> void MacroAssembler::cmpxchgw(operand_size sz, Register oldv,
>                               Register newv, Register addr, Register tmp,
> 			      Label &succeed, Label *fail) {
> 
>   if (UseLSE) {
>     ...
> 
> It'll be necessary to pass a memory barrier flag too.

Hi,

Is this something like what you had in mind?

http://cr.openjdk.java.net/~enevill/8150394/webrev.1/

WRT WeakCompareAndSwap I think it would be better if that went in as a separate change as we will have to backport this to jdk8 and doing it as one change means unpicking it later.

Tested with jcstress with and without -XX:UseLSE

All the best,
Ed.



From aph at redhat.com  Thu Feb 25 10:16:45 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 25 Feb 2016 10:16:45 +0000
Subject: RFR: 8150394: aarch64: add support for 8.1 LSE CAS instructions
In-Reply-To: <1456394786.1383.18.camel@mint>
References: <1456173130.2735.8.camel@mint> <56CD8CCF.1030404@redhat.com>
	<1456394786.1383.18.camel@mint>
Message-ID: <56CED48D.9090702@redhat.com>

On 25/02/16 10:06, Edward Nevill wrote:
> Is this something like what you had in mind?
> 
> http://cr.openjdk.java.net/~enevill/8150394/webrev.1/

Something like.  I'll integrate what I've got with this and post
it soon.

Andrew.


From vladimir.x.ivanov at oracle.com  Thu Feb 25 10:56:31 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 25 Feb 2016 13:56:31 +0300
Subject: [9] RFR (XS): 8150436: Incorrect invocation mode when
	linkToInteface linker is eliminated
In-Reply-To: <56CE3BE6.2010805@oracle.com>
References: <56CDD6E5.2090001@oracle.com> <56CE3BE6.2010805@oracle.com>
Message-ID: <56CEDDDF.3090600@oracle.com>

Vladimir, Aleksey, thanks for the reviews.

Best regards,
Vladimir Ivanov

On 2/25/16 2:25 AM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 2/24/16 8:14 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8150436/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8150436
>>
>> When MH.linkToInterface is eliminated, but the target method is not
>> inlined, either default or concrete method is attached to the call site.
>> During call site resolution, invokeinterface invocation mode is used,
>> but resolution fails when the target method is concrete.
>>
>> The fix is to adjust invocation mode to invokevirtual when concrete
>> method is attached.
>>
>> Testing: failing test, JPRT.
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov

From vladimir.x.ivanov at oracle.com  Thu Feb 25 10:56:53 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 25 Feb 2016 13:56:53 +0300
Subject: [9] RFR (S): 8150186: Folding mismatched accesses with @Stable is
	incorrect
In-Reply-To: <78F4D925-399D-416A-8F9E-E635D1250175@oracle.com>
References: <56CDD4F4.2070907@oracle.com>
	<78F4D925-399D-416A-8F9E-E635D1250175@oracle.com>
Message-ID: <56CEDDF5.3010506@oracle.com>

Vladimir, John, Aleksey, thanks for the reviews.

Best regards,
Vladimir Ivanov

On 2/25/16 7:56 AM, John Rose wrote:
> Reviewed.
>
> ? John
>
>> On Feb 24, 2016, at 8:06 AM, Vladimir Ivanov  wrote:
>>
>> http://cr.openjdk.java.net/~vlivanov/8150186/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8150186
>>
>> Constant folding from stable arrays doesn't check for mismatched accesses.
>>
>> The fix is to disable the optimization for mismatched accesses.
>>
>> Also, added missing range checks in ciArray::element_value_by_offset.
>>
>> Testing: failing tests, JPRT
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> PS: I considered converting is_mismatched_access check in fold_stable_ary_elem into an assert, but I spotted some quirks in mismatched access detection (filed JDK-8150543 [1]). So, I'd prefer to keep the check and refine the code as part of JDK-8150543 when more test coverage is available.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8150543

From zoltan.majo at oracle.com  Thu Feb 25 14:17:45 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Thu, 25 Feb 2016 15:17:45 +0100
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
Message-ID: <56CF0D09.1080508@oracle.com>

Hi,


please review the patch for 8150349.

https://bugs.openjdk.java.net/browse/JDK-8150349

Problem: The hotspot_compiler_3 group of tests takes more than 30 
minutes on our slowest platforms.


Solution: Remove a number of long-running tests from the 
hotspot_compiler_3 group. All removed tests are related to intrinsics, 
that is, they check the functionality of a reduced set of the VM's 
functionality that is not often modified. Also, we execute all removed 
tests daily (in our nightly testing).

Here is the time spent in hotspot_compiler_3 on our slowest platforms 
after removing the tests:

West:
solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3     success(15m 22s)
     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=6 
parallelcount=6 ram=31744MB cpufreqmhz=2848
linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(19m 09s)
     platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12 
parallelcount=12 ram=60690MB cpufreqmhz=2294

Stockholm:
solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3     success(15m 32s)
     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=12 
parallelcount=12 ram=24576MB    cpufreqmhz=2848
linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(20m 24s)
     platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8 
parallelcount=8 ram=16061MB


Webrev:
http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/

Thank you!

Best regards,


Zoltan


From aph at redhat.com  Thu Feb 25 14:49:54 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 25 Feb 2016 14:49:54 +0000
Subject: RFR: 8150394: aarch64: add support for 8.1 LSE CAS instructions
In-Reply-To: <1456394786.1383.18.camel@mint>
References: <1456173130.2735.8.camel@mint> <56CD8CCF.1030404@redhat.com>
	<1456394786.1383.18.camel@mint>
Message-ID: <56CF1492.1000400@redhat.com>

Here's what I've got, merging my changes for VarHandles with yours
for LSE CAS:

http://cr.openjdk.java.net/~aph/aarch64-lse-cas/

Please test it.

Thanks,

Andrew.

From nils.eliasson at oracle.com  Thu Feb 25 15:01:50 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 25 Feb 2016 16:01:50 +0100
Subject: RFR(S/M): 8150646: Add support for blocking compiles through whitebox
	API
Message-ID: <56CF175E.1030806@oracle.com>

Hi,

Please review this change that adds support for blocking compiles in the 
whitebox API. This enables simpler less time consuming tests.

Motivation:
* -XX:-BackgroundCompilation is a global flag and can be time consuming
* Blocking compiles removes the need for waiting on the compile queue to 
complete
* Compiles put in the queue may be evicted if the queue grows to big - 
causing indeterminism in the test
* Less VM-flags allows for more tests in the same VM

Testing:
Posting a separate RFR for test fix that uses this change. They will be 
pushed at the same time.

RFE: https://bugs.openjdk.java.net/browse/JDK-8150646
JDK rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev_jdk.01/
Hotspot rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev.02/

Best regards,
Nils Eliasson

From nils.eliasson at oracle.com  Thu Feb 25 15:02:02 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 25 Feb 2016 16:02:02 +0100
Subject: RFR(S/M): 8073793: serviceability/dcmd/compiler/CodelistTest.java
	fails with ClassNotFoundException trying to load VM anonymous class
Message-ID: <56CF176A.7090705@oracle.com>

Hi,

Please review this fix of the CodelistTest.

Summary:
The test iterated over the output and tried to reflect some Classes for 
verification. This is fragile since some classes are not reflectable and 
it changes over time.

Solution:
Instead ensure compilation of some select methods, on different compile 
levels, and verify that those methods show up in the output.

Testing:
Test run on all platforms.

This change requires: https://bugs.openjdk.java.net/browse/JDK-8150646

Bug: https://bugs.openjdk.java.net/browse/JDK-8073793
Webrev: http://cr.openjdk.java.net/~neliasso/8073793/webrev.01/

Best regards,
Nils Eliasson

From nils.eliasson at oracle.com  Thu Feb 25 15:22:00 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 25 Feb 2016 16:22:00 +0100
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
In-Reply-To: <56CF0D09.1080508@oracle.com>
References: <56CF0D09.1080508@oracle.com>
Message-ID: <56CF1C18.3080808@oracle.com>

Hi Zoltan,

Have you opened a bug for fixing the tests?

Do we really want to remove the String intrinsics from the list? aren't 
they pretty new?

Thanks for fixing this,
Nils Eliasson

On 2016-02-25 15:17, Zolt?n Maj? wrote:
> Hi,
>
>
> please review the patch for 8150349.
>
> https://bugs.openjdk.java.net/browse/JDK-8150349
>
> Problem: The hotspot_compiler_3 group of tests takes more than 30 
> minutes on our slowest platforms.
>
>
> Solution: Remove a number of long-running tests from the 
> hotspot_compiler_3 group. All removed tests are related to intrinsics, 
> that is, they check the functionality of a reduced set of the VM's 
> functionality that is not often modified. Also, we execute all removed 
> tests daily (in our nightly testing).
>
> Here is the time spent in hotspot_compiler_3 on our slowest platforms 
> after removing the tests:
>
> West:
> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 22s)
>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=6 
> parallelcount=6 ram=31744MB cpufreqmhz=2848
> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(19m 09s)
>     platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12 
> parallelcount=12 ram=60690MB cpufreqmhz=2294
>
> Stockholm:
> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 32s)
>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=12 
> parallelcount=12 ram=24576MB    cpufreqmhz=2848
> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(20m 24s)
>     platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8 
> parallelcount=8 ram=16061MB
>
>
> Webrev:
> http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/
>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>


From zoltan.majo at oracle.com  Thu Feb 25 16:12:58 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Thu, 25 Feb 2016 17:12:58 +0100
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
In-Reply-To: <56CF1C18.3080808@oracle.com>
References: <56CF0D09.1080508@oracle.com> <56CF1C18.3080808@oracle.com>
Message-ID: <56CF280A.1010705@oracle.com>

Hi Nils,


thank you for the feedback!

On 02/25/2016 04:22 PM, Nils Eliasson wrote:
> Hi Zoltan,
>
> Have you opened a bug for fixing the tests?

No, I have not, because there is an existing issue (INTJDK-7620326) that 
is supposed to take care of the high execution time of intrinsic-related 
tests on platforms where the relevant intrinsics are not available. I've 
linked the two issues.

>
> Do we really want to remove the String intrinsics from the list? 
> aren't they pretty new?

You are right, they are in part new (in part old intrinsics have been 
updated). I thought to remove them nevertheless, because they take a 
long time to execute and are anyway executed in our nightlies.

Best regards,


Zoltan

>
> Thanks for fixing this,
> Nils Eliasson
>
> On 2016-02-25 15:17, Zolt?n Maj? wrote:
>> Hi,
>>
>>
>> please review the patch for 8150349.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8150349
>>
>> Problem: The hotspot_compiler_3 group of tests takes more than 30 
>> minutes on our slowest platforms.
>>
>>
>> Solution: Remove a number of long-running tests from the 
>> hotspot_compiler_3 group. All removed tests are related to 
>> intrinsics, that is, they check the functionality of a reduced set of 
>> the VM's functionality that is not often modified. Also, we execute 
>> all removed tests daily (in our nightly testing).
>>
>> Here is the time spent in hotspot_compiler_3 on our slowest platforms 
>> after removing the tests:
>>
>> West:
>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 22s)
>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=6 
>> parallelcount=6 ram=31744MB cpufreqmhz=2848
>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(19m 09s)
>>     platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12 
>> parallelcount=12 ram=60690MB cpufreqmhz=2294
>>
>> Stockholm:
>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 32s)
>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=12 
>> parallelcount=12 ram=24576MB    cpufreqmhz=2848
>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(20m 24s)
>>     platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8 
>> parallelcount=8 ram=16061MB
>>
>>
>> Webrev:
>> http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/
>>
>> Thank you!
>>
>> Best regards,
>>
>>
>> Zoltan
>>
>


From zoltan.majo at oracle.com  Thu Feb 25 16:27:35 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Thu, 25 Feb 2016 17:27:35 +0100
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can time
	out due to frequent safepointing
Message-ID: <56CF2B77.9000707@oracle.com>

Hi,


please review the patch for 8148940:

https://bugs.openjdk.java.net/browse/JDK-8148940

Problem: Since Indify String Concatenation (JDK-8148483) was pushed, the 
execution time of the FinalizeOverride.java test increased by 2-89X.

The increase can be measured both with -Xmixed and -Xcomp and it results 
from a combination of two main factors:
(1) The test spends an increased amount of time in the VM (e.g., because 
an ISC-enabled build can trigger up to 2X more compilations than a 
non-ISC-enabled build);
(2) The test triggers safepointing frequently.

Here are more details on these factors and the exact cause of the failure:
https://bugs.openjdk.java.net/browse/JDK-8148940?focusedCommentId=13904102&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13904102


Possible solutions: Update the test to give more chance to the VM to 
progress. I see two ways of doing that:
Solution #1: Reduce the freqency of triggering GCs
http://cr.openjdk.java.net/~zmajo/8148940/webrev.00/

Solution #2: Remove string operations from finalizers.
http://cr.openjdk.java.net/~zmajo/8148940/webrev.01/

Solution #2 is faster, but it makes more difficult to monitor the 
progress of the test than in the case of Solution #1.

Here are the execution times for both solutions on two platforms:
https://bugs.openjdk.java.net/browse/JDK-8148940?focusedCommentId=13904104&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13904104


Testing: Executed the updated test on the both platforms used for 
evaluation.

Thank you!

Best regards,


Zoltan



From aleksey.shipilev at oracle.com  Thu Feb 25 16:38:21 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 25 Feb 2016 19:38:21 +0300
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56CF2B77.9000707@oracle.com>
References: <56CF2B77.9000707@oracle.com>
Message-ID: <56CF2DFD.2090604@oracle.com>

On 02/25/2016 07:27 PM, Zolt?n Maj? wrote:
> (1) The test spends an increased amount of time in the VM (e.g.,
> because an ISC-enabled build can trigger up to 2X more compilations
> than a non-ISC-enabled build);

I am confused about this. I thought we bootstrap the concatenations once
per concat site, and then we only "roll" with the linked in
implementation. Is that one-shot action enough to get into the despair
vortex in the test?


> Possible solutions: Update the test to give more chance to the VM to
> progress. I see two ways of doing that:
> Solution #1: Reduce the freqency of triggering GCs
> http://cr.openjdk.java.net/~zmajo/8148940/webrev.00/

From the set of presented solutions, I like this solution better,
because it breaks the Denial-of-Service setup. Other work after ISC --
e.g. harder GCs -- can possibly trigger the same trouble, right?

> Solution #2: Remove string operations from finalizers.
> http://cr.openjdk.java.net/~zmajo/8148940/webrev.01/
> 
> Solution #2 is faster, but it makes more difficult to monitor the
> progress of the test than in the case of Solution #1.

Solution #3: Compile the test with -XDstringConcat=inline to disable ISC
for this test; jtreg allows this with @compile tag. Mention the vicious
feedback cycle in comments.

Solution #4: Kick finalize() methods in classes to link concats
preemptively, before entering System.gc+System.runFinalization loop.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From vladimir.kozlov at oracle.com  Thu Feb 25 16:40:01 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 25 Feb 2016 08:40:01 -0800
Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1
In-Reply-To: <56CEB149.6050208@oracle.com>
References: <56B2FBB4.70407@oracle.com> <56B3FE5A.9010806@oracle.com>
	<56B40480.6060703@oracle.com> <56CE518A.2050706@oracle.com>
	<56CEB149.6050208@oracle.com>
Message-ID: <56CF2E61.1090803@oracle.com>

Looks fine to me. I assume you tested with Client VM (only C1).

Thanks,
Vladimir

On 2/24/16 11:46 PM, David Holmes wrote:
> On 25/02/2016 10:57 AM, Chris Plummer wrote:
>> Hello,
>>
>> I still need to finish up review of this change. I added the change that
>> David suggested. Since it's minor, I'll just post the code from
>> arguments.cpp here:
>>
>> #if !defined(COMPILER2) && !INCLUDE_JVMCI
>>    UNSUPPORTED_OPTION(ProfileInterpreter, "ProfileInterpreter");
>>    UNSUPPORTED_OPTION(TraceProfileInterpreter, "TraceProfileInterpreter");
>>    UNSUPPORTED_OPTION(PrintMethodData, "PrintMethodData");
>> #endif
>>
>> The ProfileInterpreter related code was in the original code review. The
>> other two flag checks I just added.
>
> That addition seems fine to me. But I'll leave it to the compiler folk to review the core changes.
>
> Thanks,
> David
>
>> thanks,
>>
>> Chris
>>
>> On 2/4/16 6:10 PM, Chris Plummer wrote:
>>> Hi David,
>>>
>>> On 2/4/16 5:43 PM, David Holmes wrote:
>>>> Hi Chris,
>>>>
>>>> On 4/02/2016 5:20 PM, Chris Plummer wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following for removing Method::_method_data when only
>>>>> supporting C1 (or more specifically, when not supporting C2 or JVMCI).
>>>>
>>>> Does JVMCI exist with C1 only?
>>> My understanding is it can exists with C2 or on its own, but currently
>>> is not included with C1 builds.
>>>> The COMPILER2_OR_JVMCI conjunction makes things a bit messy. Can we
>>>> abstract that behind a single variable, INCLUDE_METHOD_DATA (or some
>>>> such) to make it cleaner?
>>> I'll also be using COMPILER2_OR_JVMCI with another change to that
>>> removes some MethodCounter fields. So yes, I can add
>>> INCLUDE_METHOD_DATA, but then will need another INCLUDE_XXX for the
>>> MethodCounter fields I'll be conditionally removing.
>>>>
>>>>> This will help reduce dynamic footprint usage for the minimal VM.
>>>>>
>>>>> As part of this fix, ProfileInterperter is forced to false unless C2 or
>>>>> JVMCI is supported. This was mainly done to avoid crashes if it is
>>>>> turned on and Method::_method_data has been excluded, but also because
>>>>> it is not useful except to C2 or JVMCI.
>>>>
>>>> Are you saying that the information generated by ProfileInterpreter
>>>> is only used by C2 and JVMCI? If that is case it should really have
>>>> been a C2 only flag.
>>>>
>>> That is my understanding. Coleen confirmed it for me. I believe she
>>> got her info from the compiler team. BTW, we need a mechanism to make
>>> these conditionally unsupported flags a constant value when they are
>>> not supported. It would help deadstrip code.
>>>> If ProfileInterpreter is forced to false then shouldn't you also be
>>>> checking TraceProfileInterpreter and PrintMethodData use as well
>>> Yes, I can add those.
>>>
>>> thanks,
>>>
>>> Chris
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8147978/webrev.02/
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147978
>>>>>
>>>>> Test with JPRT -testset hotspot.
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>
>>

From aleksey.shipilev at oracle.com  Thu Feb 25 16:41:19 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 25 Feb 2016 19:41:19 +0300
Subject: RFR (S) 8150534: C1 compilation fails with "Constant field loads
	are folded during parsing"
In-Reply-To: <56CECEA6.4060905@oracle.com>
References: <56CDE781.9050706@oracle.com> <56CDF3D2.8090803@oracle.com>
	<56CDF87D.1090405@oracle.com> <56CDF8E8.5070300@oracle.com>
	<56CEC7A1.90504@oracle.com> <56CECEA6.4060905@oracle.com>
Message-ID: <56CF2EAF.9030500@oracle.com>

On 02/25/2016 12:51 PM, Tobias Hartmann wrote:
> Hi Aleksey,
> 
> On 25.02.2016 10:21, Aleksey Shipilev wrote:
>> On 02/24/2016 09:39 PM, Vladimir Ivanov wrote:
>>>>    http://cr.openjdk.java.net/~shade/8150534/webrev.02/
> 
> This looks good to me.

Thanks Vladimir and Tobias. Pushed.

-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From chris.plummer at oracle.com  Thu Feb 25 16:44:55 2016
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 25 Feb 2016 08:44:55 -0800
Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1
In-Reply-To: <56CF2E61.1090803@oracle.com>
References: <56B2FBB4.70407@oracle.com> <56B3FE5A.9010806@oracle.com>
	<56B40480.6060703@oracle.com> <56CE518A.2050706@oracle.com>
	<56CEB149.6050208@oracle.com> <56CF2E61.1090803@oracle.com>
Message-ID: <56CF2F87.3030909@oracle.com>

Yes. "-testset hotspot" does plenty of c1 test runs.

thanks,

Chris

On 2/25/16 8:40 AM, Vladimir Kozlov wrote:
> Looks fine to me. I assume you tested with Client VM (only C1).
>
> Thanks,
> Vladimir
>
> On 2/24/16 11:46 PM, David Holmes wrote:
>> On 25/02/2016 10:57 AM, Chris Plummer wrote:
>>> Hello,
>>>
>>> I still need to finish up review of this change. I added the change 
>>> that
>>> David suggested. Since it's minor, I'll just post the code from
>>> arguments.cpp here:
>>>
>>> #if !defined(COMPILER2) && !INCLUDE_JVMCI
>>>    UNSUPPORTED_OPTION(ProfileInterpreter, "ProfileInterpreter");
>>>    UNSUPPORTED_OPTION(TraceProfileInterpreter, 
>>> "TraceProfileInterpreter");
>>>    UNSUPPORTED_OPTION(PrintMethodData, "PrintMethodData");
>>> #endif
>>>
>>> The ProfileInterpreter related code was in the original code review. 
>>> The
>>> other two flag checks I just added.
>>
>> That addition seems fine to me. But I'll leave it to the compiler 
>> folk to review the core changes.
>>
>> Thanks,
>> David
>>
>>> thanks,
>>>
>>> Chris
>>>
>>> On 2/4/16 6:10 PM, Chris Plummer wrote:
>>>> Hi David,
>>>>
>>>> On 2/4/16 5:43 PM, David Holmes wrote:
>>>>> Hi Chris,
>>>>>
>>>>> On 4/02/2016 5:20 PM, Chris Plummer wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following for removing Method::_method_data 
>>>>>> when only
>>>>>> supporting C1 (or more specifically, when not supporting C2 or 
>>>>>> JVMCI).
>>>>>
>>>>> Does JVMCI exist with C1 only?
>>>> My understanding is it can exists with C2 or on its own, but currently
>>>> is not included with C1 builds.
>>>>> The COMPILER2_OR_JVMCI conjunction makes things a bit messy. Can we
>>>>> abstract that behind a single variable, INCLUDE_METHOD_DATA (or some
>>>>> such) to make it cleaner?
>>>> I'll also be using COMPILER2_OR_JVMCI with another change to that
>>>> removes some MethodCounter fields. So yes, I can add
>>>> INCLUDE_METHOD_DATA, but then will need another INCLUDE_XXX for the
>>>> MethodCounter fields I'll be conditionally removing.
>>>>>
>>>>>> This will help reduce dynamic footprint usage for the minimal VM.
>>>>>>
>>>>>> As part of this fix, ProfileInterperter is forced to false unless 
>>>>>> C2 or
>>>>>> JVMCI is supported. This was mainly done to avoid crashes if it is
>>>>>> turned on and Method::_method_data has been excluded, but also 
>>>>>> because
>>>>>> it is not useful except to C2 or JVMCI.
>>>>>
>>>>> Are you saying that the information generated by ProfileInterpreter
>>>>> is only used by C2 and JVMCI? If that is case it should really have
>>>>> been a C2 only flag.
>>>>>
>>>> That is my understanding. Coleen confirmed it for me. I believe she
>>>> got her info from the compiler team. BTW, we need a mechanism to make
>>>> these conditionally unsupported flags a constant value when they are
>>>> not supported. It would help deadstrip code.
>>>>> If ProfileInterpreter is forced to false then shouldn't you also be
>>>>> checking TraceProfileInterpreter and PrintMethodData use as well
>>>> Yes, I can add those.
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8147978/webrev.02/
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147978
>>>>>>
>>>>>> Test with JPRT -testset hotspot.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Chris
>>>>
>>>


From vladimir.kozlov at oracle.com  Thu Feb 25 17:21:00 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 25 Feb 2016 09:21:00 -0800
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
In-Reply-To: <56CF280A.1010705@oracle.com>
References: <56CF0D09.1080508@oracle.com> <56CF1C18.3080808@oracle.com>
	<56CF280A.1010705@oracle.com>
Message-ID: <56CF37FC.1080906@oracle.com>

I am fine with removal of adler32 and bmi testing from JPRT runs because we don't have a plan to touch them.
But code related to CRC32, CRC32c and string may be touched soon for some platforms.
What if we created hotspot_compiler_4 group for them? How much time it would take to run it on slow platforms?

Thanks,
Vladimir

On 2/25/16 8:12 AM, Zolt?n Maj? wrote:
> Hi Nils,
>
>
> thank you for the feedback!
>
> On 02/25/2016 04:22 PM, Nils Eliasson wrote:
>> Hi Zoltan,
>>
>> Have you opened a bug for fixing the tests?
>
> No, I have not, because there is an existing issue (INTJDK-7620326) that is supposed to take care of the high execution
> time of intrinsic-related tests on platforms where the relevant intrinsics are not available. I've linked the two issues.
>
>>
>> Do we really want to remove the String intrinsics from the list? aren't they pretty new?
>
> You are right, they are in part new (in part old intrinsics have been updated). I thought to remove them nevertheless,
> because they take a long time to execute and are anyway executed in our nightlies.
>
> Best regards,
>
>
> Zoltan
>
>>
>> Thanks for fixing this,
>> Nils Eliasson
>>
>> On 2016-02-25 15:17, Zolt?n Maj? wrote:
>>> Hi,
>>>
>>>
>>> please review the patch for 8150349.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8150349
>>>
>>> Problem: The hotspot_compiler_3 group of tests takes more than 30 minutes on our slowest platforms.
>>>
>>>
>>> Solution: Remove a number of long-running tests from the hotspot_compiler_3 group. All removed tests are related to
>>> intrinsics, that is, they check the functionality of a reduced set of the VM's functionality that is not often
>>> modified. Also, we execute all removed tests daily (in our nightly testing).
>>>
>>> Here is the time spent in hotspot_compiler_3 on our slowest platforms after removing the tests:
>>>
>>> West:
>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 22s)
>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=6 parallelcount=6 ram=31744MB cpufreqmhz=2848
>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(19m 09s)
>>>     platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12 parallelcount=12 ram=60690MB cpufreqmhz=2294
>>>
>>> Stockholm:
>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 32s)
>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=12 parallelcount=12 ram=24576MB    cpufreqmhz=2848
>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(20m 24s)
>>>     platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8 parallelcount=8 ram=16061MB
>>>
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/
>>>
>>> Thank you!
>>>
>>> Best regards,
>>>
>>>
>>> Zoltan
>>>
>>
>

From uschindler at apache.org  Thu Feb 25 17:30:49 2016
From: uschindler at apache.org (Uwe Schindler)
Date: Thu, 25 Feb 2016 18:30:49 +0100
Subject: [9] RFR (XS): 8150436: Incorrect invocation mode when
	linkToInteface	linker is eliminated
In-Reply-To: <56CDD6E5.2090001@oracle.com>
References: <56CDD6E5.2090001@oracle.com>
Message-ID: <00dc01d16ff2$488612d0$d9923870$@apache.org>

Hi Vladimir,

thanks for taking care so fast. To me the fix looks fine and this explains why we have seen that with Lucene! I hope my test case was fine, but it was quite clear under which circumstances this happened. As I am not able to build a full patched JDK on my own, but I hope you tried the fix with my test case (as attached to issue).

Many, many thanks!
Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-
> bounces at openjdk.java.net] On Behalf Of Vladimir Ivanov
> Sent: Wednesday, February 24, 2016 5:14 PM
> To: hotspot compiler 
> Subject: [9] RFR (XS): 8150436: Incorrect invocation mode when
> linkToInteface linker is eliminated
> 
> http://cr.openjdk.java.net/~vlivanov/8150436/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8150436
> 
> When MH.linkToInterface is eliminated, but the target method is not
> inlined, either default or concrete method is attached to the call site.
> During call site resolution, invokeinterface invocation mode is used,
> but resolution fails when the target method is concrete.
> 
> The fix is to adjust invocation mode to invokevirtual when concrete
> method is attached.
> 
> Testing: failing test, JPRT.
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov


From edward.nevill at gmail.com  Thu Feb 25 17:44:46 2016
From: edward.nevill at gmail.com (Edward Nevill)
Date: Thu, 25 Feb 2016 17:44:46 +0000
Subject: RFR: 8150394: aarch64: add support for 8.1 LSE CAS instructions
In-Reply-To: <56CF1492.1000400@redhat.com>
References: <1456173130.2735.8.camel@mint> <56CD8CCF.1030404@redhat.com>
	<1456394786.1383.18.camel@mint>  <56CF1492.1000400@redhat.com>
Message-ID: <1456422286.21810.2.camel@mint>

On Thu, 2016-02-25 at 14:49 +0000, Andrew Haley wrote:
> Here's what I've got, merging my changes for VarHandles with yours
> for LSE CAS:
> 
> http://cr.openjdk.java.net/~aph/aarch64-lse-cas/
> 
> Please test it.
> 

Hi,

Clean run through jcstress with -XX:+UseLSE. Also clean on some partners tests with and without -XX:+UseLSE.

Looks fine,
Ed.



From pavel.punegov at oracle.com  Thu Feb 25 17:54:04 2016
From: pavel.punegov at oracle.com (Pavel Punegov)
Date: Thu, 25 Feb 2016 20:54:04 +0300
Subject: RFR (S): 8148563:
	compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java timesout
In-Reply-To: <56CB22A6.2090502@oracle.com>
References: <47423DF0-C7C7-4053-BEC0-1D12A558E982@oracle.com>
	<56C77EFA.1060702@oracle.com> <56C85B32.4040405@oracle.com>
	<56CB22A6.2090502@oracle.com>
Message-ID: 

HI,

I updated a webrev according to discussion: http://cr.openjdk.java.net/~ppunegov/8148563/webrev.02/ 

1. Remove sequential test.
2. As in previous webrev use different commands, not only Compiler.directives_add.
3. Make test execute only 20 commands, and not more than 30 seconds (controlled by TimeLimitedRunner).
4. Make test execute diagnostic commands in the fixed set of 5 threads.

? Pavel.

> On 22 Feb 2016, at 18:00, Nils Eliasson  wrote:
> 
> Hi,
> 
> I posted my own webrev for the same issue before reading this thread. I didn't see when the bug changed owner.
> 
> My reflections are:
> 
> 1) The sequantial test is redudant - the multi version tests everything.
> 2) Very good that you added more that just the add command!
> 3) Making this test run for 120 second is way too much in my opinion. 20 seconds should be more than enough each night. We are testing a stack guarded by a lock. 
> 4) Are you sure "Runtime.getRuntime().availableProcessors()" don't return all processors on a system (regardless of how many our image are allowed to use). I would limit to four threads or so - just to make sure there are possibilities for concurrent operations.
> 
> Best regards,
> Nils Eliasson
> 
> 
> On 2016-02-20 13:25, Pavel Punegov wrote:
>> Vladimir,
>> 
>> Test generated 5 directives of size 1000 directives before.
>> Previously test added them to directives stack one after another, making VM fail with native OOM (JDK-8144246 ). CompilerDirectivesLimit flag was added with default value of 50. Since that test began to add directives on the stack failing every time.
>> 
>> I changed the test to create only one file (999 directives) to reach the limit of 1000 (set by option). So it still can try to add directives over the limit, but it also executes other commands like "clear", "remove" and "print".
>> 
>> Added Nils to CC. Nils, could you please take a look also?
>> 
>> On 19.02.2016 23:45, Vladimir Kozlov wrote:
>>> Seems fine. What size of directive files was before and after this fix? JBS does not have this information. 
>>> 
>>> Thanks, 
>>> Vladimir 
>>> 
>>> On 2/19/16 9:04 AM, Pavel Punegov wrote: 
>>>> Hi, 
>>>> 
>>>> please review the fix for a test bug. 
>>>> 
>>>> Issue: 
>>>> 1. Test timeouts because it executes a lot of jcmd processes. Number of 
>>>> threads is calculated as number of processors (cores) * 10, that led to 
>>>> an enormous number of jcmds executed on hosts with lots of CPUs/cores. 
>>>> 2. Test also spends a lot of time to generate 5 huge directive files, 
>>>> that were tried to be added on to the directives stack. Directive stack 
>>>> has a limit (default 50, controlled by  CompilerDirectivesLimit). 
>>>> 
>>>> Fix: 
>>>> 1. Calculate number of threads as a log of the number of CPUs/cores * 10. 
>>>> 2. Generate only one file that is less than specified 
>>>> CompilerDirectivesLimit. 
>>>> 3. Add different commands to execute (add, clear, remove and print) and 
>>>> generate them on demand. 
>>>> 
>>>> webrev: http://cr.openjdk.java.net/~ppunegov/8148563/webrev.00/  
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8148563  
>>>> 
>>>> ? Pavel. 
>>>> 
>> 
>> -- 
>> Thanks,
>> Pavel Punegov
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vladimir.x.ivanov at oracle.com  Thu Feb 25 19:03:38 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 25 Feb 2016 22:03:38 +0300
Subject: [9] RFR (XS): 8150436: Incorrect invocation mode when
	linkToInteface linker is eliminated
In-Reply-To: <00dc01d16ff2$488612d0$d9923870$@apache.org>
References: <56CDD6E5.2090001@oracle.com>
	<00dc01d16ff2$488612d0$d9923870$@apache.org>
Message-ID: <56CF500A.3090709@oracle.com>

Uwe, I verified that your test case works fine after the fix.

Best regards,
Vladimir Ivanov

PS: thanks a lot for the minimized test case and detailed report! It 
saved me lots of time.

On 2/25/16 8:30 PM, Uwe Schindler wrote:
> Hi Vladimir,
>
> thanks for taking care so fast. To me the fix looks fine and this explains why we have seen that with Lucene! I hope my test case was fine, but it was quite clear under which circumstances this happened. As I am not able to build a full patched JDK on my own, but I hope you tried the fix with my test case (as attached to issue).
>
> Many, many thanks!
> Uwe
>
> -----
> Uwe Schindler
> uschindler at apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
>> -----Original Message-----
>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-
>> bounces at openjdk.java.net] On Behalf Of Vladimir Ivanov
>> Sent: Wednesday, February 24, 2016 5:14 PM
>> To: hotspot compiler 
>> Subject: [9] RFR (XS): 8150436: Incorrect invocation mode when
>> linkToInteface linker is eliminated
>>
>> http://cr.openjdk.java.net/~vlivanov/8150436/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8150436
>>
>> When MH.linkToInterface is eliminated, but the target method is not
>> inlined, either default or concrete method is attached to the call site.
>> During call site resolution, invokeinterface invocation mode is used,
>> but resolution fails when the target method is concrete.
>>
>> The fix is to adjust invocation mode to invokevirtual when concrete
>> method is attached.
>>
>> Testing: failing test, JPRT.
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>

From aleksey.shipilev at oracle.com  Thu Feb 25 20:56:30 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 25 Feb 2016 23:56:30 +0300
Subject: RFR (S) 8150669: C1 intrinsic for Class.isPrimitive
Message-ID: <56CF6A7E.7080204@oracle.com>

Hi,

I would like to amend C1 with handling Class.isPrimitive intrinsic:
  http://cr.openjdk.java.net/~shade/8150669/webrev.01/
  https://bugs.openjdk.java.net/browse/JDK-8150669

Through a long chain of dependencies, it would benefit String
concatenation, possibly startup (lots of usages in java.lang.invoke, and
who knows how many other places in JDK that use reflective meddling),
and also, for a fun of it, fastdebug builds.

Performance data shows we improve all interesting cases:
  http://cr.openjdk.java.net/~shade/8150669/notes.txt

Testing: new test; targeted benchmarks; JPRT -testset hotspot

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From vladimir.kozlov at oracle.com  Thu Feb 25 21:14:05 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 25 Feb 2016 13:14:05 -0800
Subject: RFR(S/M): 8150646: Add support for blocking compiles through
	whitebox API
In-Reply-To: <56CF175E.1030806@oracle.com>
References: <56CF175E.1030806@oracle.com>
Message-ID: <56CF6E9D.8060507@oracle.com>

You are adding parameter which is used only for testing.
Can we have callback(or check field) into WB instead? Similar to 
WhiteBox::compilation_locked.

Thanks,
Vladimir

On 2/25/16 7:01 AM, Nils Eliasson wrote:
> Hi,
>
> Please review this change that adds support for blocking compiles in the
> whitebox API. This enables simpler less time consuming tests.
>
> Motivation:
> * -XX:-BackgroundCompilation is a global flag and can be time consuming
> * Blocking compiles removes the need for waiting on the compile queue to
> complete
> * Compiles put in the queue may be evicted if the queue grows to big -
> causing indeterminism in the test
> * Less VM-flags allows for more tests in the same VM
>
> Testing:
> Posting a separate RFR for test fix that uses this change. They will be
> pushed at the same time.
>
> RFE: https://bugs.openjdk.java.net/browse/JDK-8150646
> JDK rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev_jdk.01/
> Hotspot rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev.02/
>
> Best regards,
> Nils Eliasson

From vladimir.x.ivanov at oracle.com  Thu Feb 25 22:09:31 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 26 Feb 2016 01:09:31 +0300
Subject: [9] RFR (M): 8068038: C2: large constant offsets aren't handled on
	SPARC
Message-ID: <56CF7B9B.5000007@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8068038/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8068038

C2 doesn't handle large constant offsets ((>=2^12 bytes) on SPARC and 
simply bails out the compilation and marks the method as non-compilable.

It has severe performance impact For example, some Octane benchmarks 
suffer >10x slowdown.

The fix is to use variable-sized encoding and put large offsets in the 
register. It means that all match rules and instructions which depend on 
emit_form3_mem_reg become variable-sized as well and their size should 
be computed dynamically.

I verified C2 compilation times and code emission still takes ~3-4%.

Also, did some cleanups: got rid of size computations in 
MachSpillCopyNode::implementation and helper methods, refactored 
printing logic.

Testing: octane, JPRT.

Thanks!

Best regards,
Vladimir Ivanov

PS: there's an additional cleanup [1] in sparc.ad (mostly 32-bit SPARC 
removal, but also added some comments). It can go along with this fix or 
as part of the 32-bit SPARC complete removal (JDK-8150388). Let me know 
what do you prefer.

[1] http://cr.openjdk.java.net/~vlivanov/8068038/webrev.cleanup

From vladimir.kozlov at oracle.com  Thu Feb 25 23:54:58 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 25 Feb 2016 15:54:58 -0800
Subject: [9] RFR (M): 8068038: C2: large constant offsets aren't handled
	on SPARC
In-Reply-To: <56CF7B9B.5000007@oracle.com>
References: <56CF7B9B.5000007@oracle.com>
Message-ID: <56CF9452.7050606@oracle.com>

On 2/25/16 2:09 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8068038/webrev.00

Looks fine but leave 32-bit removal to JDK-8150388.

> https://bugs.openjdk.java.net/browse/JDK-8068038
>
> C2 doesn't handle large constant offsets ((>=2^12 bytes) on SPARC and
> simply bails out the compilation and marks the method as non-compilable.
>
> It has severe performance impact For example, some Octane benchmarks
> suffer >10x slowdown.
>
> The fix is to use variable-sized encoding and put large offsets in the
> register. It means that all match rules and instructions which depend on
> emit_form3_mem_reg become variable-sized as well and their size should
> be computed dynamically.
>
> I verified C2 compilation times and code emission still takes ~3-4%.
>
> Also, did some cleanups: got rid of size computations in
> MachSpillCopyNode::implementation and helper methods, refactored
> printing logic.
>
> Testing: octane, JPRT.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
>
> PS: there's an additional cleanup [1] in sparc.ad (mostly 32-bit SPARC
> removal, but also added some comments). It can go along with this fix or
> as part of the 32-bit SPARC complete removal (JDK-8150388). Let me know
> what do you prefer.

Should be part of JDK-8150388 changes.

Thanks,
Vladimir

>
> [1] http://cr.openjdk.java.net/~vlivanov/8068038/webrev.cleanup

From chris.plummer at oracle.com  Fri Feb 26 00:01:03 2016
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 25 Feb 2016 16:01:03 -0800
Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1
In-Reply-To: <56CF2F87.3030909@oracle.com>
References: <56B2FBB4.70407@oracle.com> <56B3FE5A.9010806@oracle.com>
	<56B40480.6060703@oracle.com> <56CE518A.2050706@oracle.com>
	<56CEB149.6050208@oracle.com> <56CF2E61.1090803@oracle.com>
	<56CF2F87.3030909@oracle.com>
Message-ID: <56CF95BF.5070300@oracle.com>

The TraceProfileInterpreter UNSUPPORTED_OPTION check  I added failed to 
compile for release builds because TraceProfileInterpreter is a 
developer flag. I had to add NOT_PRODUCT:

#if !defined(COMPILER2) && !INCLUDE_JVMCI
   UNSUPPORTED_OPTION(ProfileInterpreter, "ProfileInterpreter");
   NOT_PRODUCT(UNSUPPORTED_OPTION(TraceProfileInterpreter, 
"TraceProfileInterpreter"));
   UNSUPPORTED_OPTION(PrintMethodData, "PrintMethodData");
#endif

Chris

On 2/25/16 8:44 AM, Chris Plummer wrote:
> Yes. "-testset hotspot" does plenty of c1 test runs.
>
> thanks,
>
> Chris
>
> On 2/25/16 8:40 AM, Vladimir Kozlov wrote:
>> Looks fine to me. I assume you tested with Client VM (only C1).
>>
>> Thanks,
>> Vladimir
>>
>> On 2/24/16 11:46 PM, David Holmes wrote:
>>> On 25/02/2016 10:57 AM, Chris Plummer wrote:
>>>> Hello,
>>>>
>>>> I still need to finish up review of this change. I added the change 
>>>> that
>>>> David suggested. Since it's minor, I'll just post the code from
>>>> arguments.cpp here:
>>>>
>>>> #if !defined(COMPILER2) && !INCLUDE_JVMCI
>>>>    UNSUPPORTED_OPTION(ProfileInterpreter, "ProfileInterpreter");
>>>>    UNSUPPORTED_OPTION(TraceProfileInterpreter, 
>>>> "TraceProfileInterpreter");
>>>>    UNSUPPORTED_OPTION(PrintMethodData, "PrintMethodData");
>>>> #endif
>>>>
>>>> The ProfileInterpreter related code was in the original code 
>>>> review. The
>>>> other two flag checks I just added.
>>>
>>> That addition seems fine to me. But I'll leave it to the compiler 
>>> folk to review the core changes.
>>>
>>> Thanks,
>>> David
>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>> On 2/4/16 6:10 PM, Chris Plummer wrote:
>>>>> Hi David,
>>>>>
>>>>> On 2/4/16 5:43 PM, David Holmes wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>> On 4/02/2016 5:20 PM, Chris Plummer wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the following for removing Method::_method_data 
>>>>>>> when only
>>>>>>> supporting C1 (or more specifically, when not supporting C2 or 
>>>>>>> JVMCI).
>>>>>>
>>>>>> Does JVMCI exist with C1 only?
>>>>> My understanding is it can exists with C2 or on its own, but 
>>>>> currently
>>>>> is not included with C1 builds.
>>>>>> The COMPILER2_OR_JVMCI conjunction makes things a bit messy. Can we
>>>>>> abstract that behind a single variable, INCLUDE_METHOD_DATA (or some
>>>>>> such) to make it cleaner?
>>>>> I'll also be using COMPILER2_OR_JVMCI with another change to that
>>>>> removes some MethodCounter fields. So yes, I can add
>>>>> INCLUDE_METHOD_DATA, but then will need another INCLUDE_XXX for the
>>>>> MethodCounter fields I'll be conditionally removing.
>>>>>>
>>>>>>> This will help reduce dynamic footprint usage for the minimal VM.
>>>>>>>
>>>>>>> As part of this fix, ProfileInterperter is forced to false 
>>>>>>> unless C2 or
>>>>>>> JVMCI is supported. This was mainly done to avoid crashes if it is
>>>>>>> turned on and Method::_method_data has been excluded, but also 
>>>>>>> because
>>>>>>> it is not useful except to C2 or JVMCI.
>>>>>>
>>>>>> Are you saying that the information generated by ProfileInterpreter
>>>>>> is only used by C2 and JVMCI? If that is case it should really have
>>>>>> been a C2 only flag.
>>>>>>
>>>>> That is my understanding. Coleen confirmed it for me. I believe she
>>>>> got her info from the compiler team. BTW, we need a mechanism to make
>>>>> these conditionally unsupported flags a constant value when they are
>>>>> not supported. It would help deadstrip code.
>>>>>> If ProfileInterpreter is forced to false then shouldn't you also be
>>>>>> checking TraceProfileInterpreter and PrintMethodData use as well
>>>>> Yes, I can add those.
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8147978/webrev.02/
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147978
>>>>>>>
>>>>>>> Test with JPRT -testset hotspot.
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Chris
>>>>>
>>>>
>


From john.r.rose at oracle.com  Fri Feb 26 01:14:29 2016
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 25 Feb 2016 17:14:29 -0800
Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1
In-Reply-To: <56B2FBB4.70407@oracle.com>
References: <56B2FBB4.70407@oracle.com>
Message-ID: <5C2E2190-CCBF-4513-BD86-906B6E314D55@oracle.com>

On Feb 3, 2016, at 11:20 PM, Chris Plummer  wrote:
> 
> Please review the following for removing Method::_method_data when only supporting C1 (or more specifically, when not supporting C2 or JVMCI). This will help reduce dynamic footprint usage for the minimal VM.

Even with C2 we could save footprint if we could merge the _method_data and _method_counters field.

Even on C1, with this change, we could save more footprint if we could make the _method_counters field a tagged union between a short count and the full method counters field, allocated lazily after (say) 10 iterations of a method.

The tracking bug for this is https://bugs.openjdk.java.net/browse/JDK-8013169 

I just added a comment explaining the lazy allocation idea.

Any takers?

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vladimir.kozlov at oracle.com  Fri Feb 26 02:28:17 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 25 Feb 2016 18:28:17 -0800
Subject: RFR(S/M): 8073793: serviceability/dcmd/compiler/CodelistTest.java
	fails with ClassNotFoundException trying to load VM anonymous class
In-Reply-To: <56CF176A.7090705@oracle.com>
References: <56CF176A.7090705@oracle.com>
Message-ID: <56CFB841.6000300@oracle.com>

this change is fine but we need to discuss how implement 8150646.

Thanks,
Vladimir

On 2/25/16 7:02 AM, Nils Eliasson wrote:
> Hi,
>
> Please review this fix of the CodelistTest.
>
> Summary:
> The test iterated over the output and tried to reflect some Classes for
> verification. This is fragile since some classes are not reflectable and
> it changes over time.
>
> Solution:
> Instead ensure compilation of some select methods, on different compile
> levels, and verify that those methods show up in the output.
>
> Testing:
> Test run on all platforms.
>
> This change requires: https://bugs.openjdk.java.net/browse/JDK-8150646
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8073793
> Webrev: http://cr.openjdk.java.net/~neliasso/8073793/webrev.01/
>
> Best regards,
> Nils Eliasson

From chris.plummer at oracle.com  Fri Feb 26 03:31:05 2016
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 25 Feb 2016 19:31:05 -0800
Subject: [9] RFR (S) 8147978: Remove Method::_method_data for C1
In-Reply-To: <5C2E2190-CCBF-4513-BD86-906B6E314D55@oracle.com>
References: <56B2FBB4.70407@oracle.com>
	<5C2E2190-CCBF-4513-BD86-906B6E314D55@oracle.com>
Message-ID: <56CFC6F9.1060204@oracle.com>

An HTML attachment was scrubbed...
URL: 

From volker.simonis at gmail.com  Fri Feb 26 08:10:22 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 26 Feb 2016 09:10:22 +0100
Subject: RFR(S/M): 8150646: Add support for blocking compiles through
	whitebox API
In-Reply-To: <56CF175E.1030806@oracle.com>
References: <56CF175E.1030806@oracle.com>
Message-ID: 

Hi Nils,

I have a similar fix like yours in my patch queue since a while but
never managed to send it out for review.

I took a little different approach and made -XX:BackgroundCompilation
applicable on a per-method base trough the compiler directive
framework. Can you please give me a few hours to prepare a clean
webrev of my solution so we can discuss it as well. Maybe we can even
merge both solutions?

And I think there's two things you can improve even if we completely
stay with your solution. You will have to change
AdvancedThresholdPolicy::is_stale() to prevent methods from beeing
removed from the compile queue because they are considered stale. This
happens quite often if you register a method for compilation but don't
call it anymore.

And you can change AdvancedThresholdPolicy::compare_methods() to
prefer blocking compiles over non-blocking ones. This will decrease
the time you'll have to wait for a blocking compilation and decreases
the chance that a method registered for a blocking compile gets stale
(see previous section).

Regards,
Volker


On Thu, Feb 25, 2016 at 4:01 PM, Nils Eliasson  wrote:
> Hi,
>
> Please review this change that adds support for blocking compiles in the
> whitebox API. This enables simpler less time consuming tests.
>
> Motivation:
> * -XX:-BackgroundCompilation is a global flag and can be time consuming
> * Blocking compiles removes the need for waiting on the compile queue to
> complete
> * Compiles put in the queue may be evicted if the queue grows to big -
> causing indeterminism in the test
> * Less VM-flags allows for more tests in the same VM
>
> Testing:
> Posting a separate RFR for test fix that uses this change. They will be
> pushed at the same time.
>
> RFE: https://bugs.openjdk.java.net/browse/JDK-8150646
> JDK rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev_jdk.01/
> Hotspot rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev.02/
>
> Best regards,
> Nils Eliasson

From nils.eliasson at oracle.com  Fri Feb 26 08:26:14 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 26 Feb 2016 09:26:14 +0100
Subject: RFR(S/M): 8150646: Add support for blocking compiles through
	whitebox API
In-Reply-To: 
References: <56CF175E.1030806@oracle.com>
	
Message-ID: <56D00C26.1080707@oracle.com>

Hi Volker,

On 2016-02-26 09:10, Volker Simonis wrote:
> Hi Nils,
>
> I have a similar fix like yours in my patch queue since a while but
> never managed to send it out for review.
>
> I took a little different approach and made -XX:BackgroundCompilation
> applicable on a per-method base trough the compiler directive
> framework. Can you please give me a few hours to prepare a clean
> webrev of my solution so we can discuss it as well. Maybe we can even
> merge both solutions?
Excellent - I have such a directives patch too! I look forward to see 
how we can merge them.

I think both variants are need - directives is the full solution, and 
this patch for having a simple way to submit single compiles in tests 
that already use Whitebox.

> And I think there's two things you can improve even if we completely
> stay with your solution. You will have to change
> AdvancedThresholdPolicy::is_stale() to prevent methods from beeing
> removed from the compile queue because they are considered stale. This
> happens quite often if you register a method for compilation but don't
> call it anymore.
I have run into the is_stale-problems too, but not for compiles that are 
blocked on. I'll take a second look at that.
> And you can change AdvancedThresholdPolicy::compare_methods() to
> prefer blocking compiles over non-blocking ones. This will decrease
> the time you'll have to wait for a blocking compilation and decreases
> the chance that a method registered for a blocking compile gets stale
> (see previous section).
That is a good idea. I'll look into it.

Best regards,
Nils Eliasson

> Regards,
> Volker
>
>
> On Thu, Feb 25, 2016 at 4:01 PM, Nils Eliasson  wrote:
>> Hi,
>>
>> Please review this change that adds support for blocking compiles in the
>> whitebox API. This enables simpler less time consuming tests.
>>
>> Motivation:
>> * -XX:-BackgroundCompilation is a global flag and can be time consuming
>> * Blocking compiles removes the need for waiting on the compile queue to
>> complete
>> * Compiles put in the queue may be evicted if the queue grows to big -
>> causing indeterminism in the test
>> * Less VM-flags allows for more tests in the same VM
>>
>> Testing:
>> Posting a separate RFR for test fix that uses this change. They will be
>> pushed at the same time.
>>
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8150646
>> JDK rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev_jdk.01/
>> Hotspot rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev.02/
>>
>> Best regards,
>> Nils Eliasson


From nils.eliasson at oracle.com  Fri Feb 26 08:36:59 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 26 Feb 2016 09:36:59 +0100
Subject: RFR(S/M): 8150646: Add support for blocking compiles through
	whitebox API
In-Reply-To: <56CF6E9D.8060507@oracle.com>
References: <56CF175E.1030806@oracle.com> <56CF6E9D.8060507@oracle.com>
Message-ID: <56D00EAB.1010009@oracle.com>

Hi Vladimir,

WhiteBox::compilation_locked is a global state that temporarily stops 
all compilations. I this case I just want to achieve blocking 
compilation for a single compile without affecting the rest of the 
system. The tests using it will continue executing as soon as that 
compile is finished, saving time where wait-loops is used today. It adds 
nice determinism to tests.

Best regards,
Nils Eliasson

On 2016-02-25 22:14, Vladimir Kozlov wrote:
> You are adding parameter which is used only for testing.
> Can we have callback(or check field) into WB instead? Similar to 
> WhiteBox::compilation_locked.
>
> Thanks,
> Vladimir
>
> On 2/25/16 7:01 AM, Nils Eliasson wrote:
>> Hi,
>>
>> Please review this change that adds support for blocking compiles in the
>> whitebox API. This enables simpler less time consuming tests.
>>
>> Motivation:
>> * -XX:-BackgroundCompilation is a global flag and can be time consuming
>> * Blocking compiles removes the need for waiting on the compile queue to
>> complete
>> * Compiles put in the queue may be evicted if the queue grows to big -
>> causing indeterminism in the test
>> * Less VM-flags allows for more tests in the same VM
>>
>> Testing:
>> Posting a separate RFR for test fix that uses this change. They will be
>> pushed at the same time.
>>
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8150646
>> JDK rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev_jdk.01/
>> Hotspot rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev.02/
>>
>> Best regards,
>> Nils Eliasson


From uschindler at apache.org  Fri Feb 26 08:57:24 2016
From: uschindler at apache.org (Uwe Schindler)
Date: Fri, 26 Feb 2016 09:57:24 +0100
Subject: [9] RFR (XS): 8150436: Incorrect invocation mode when
	linkToInteface linker is eliminated
In-Reply-To: <56CF500A.3090709@oracle.com>
References: <56CDD6E5.2090001@oracle.com>
	<00dc01d16ff2$488612d0$d9923870$@apache.org>
	<56CF500A.3090709@oracle.com>
Message-ID: <01c501d17073$b82b2400$28816c00$@apache.org>

Hi,


> Uwe, I verified that your test case works fine after the fix.

Thanks!

> Best regards,
> Vladimir Ivanov
> 
> PS: thanks a lot for the minimized test case and detailed report! It
> saved me lots of time.

Hihi, it took me the whole night to figure out that you have to prevent inlining of the interface method :-)

Uwe

> On 2/25/16 8:30 PM, Uwe Schindler wrote:
> > Hi Vladimir,
> >
> > thanks for taking care so fast. To me the fix looks fine and this explains why
> we have seen that with Lucene! I hope my test case was fine, but it was
> quite clear under which circumstances this happened. As I am not able to
> build a full patched JDK on my own, but I hope you tried the fix with my test
> case (as attached to issue).
> >
> > Many, many thanks!
> > Uwe
> >
> > -----
> > Uwe Schindler
> > uschindler at apache.org
> > ASF Member, Apache Lucene PMC / Committer
> > Bremen, Germany
> > http://lucene.apache.org/
> >
> >> -----Original Message-----
> >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-
> >> bounces at openjdk.java.net] On Behalf Of Vladimir Ivanov
> >> Sent: Wednesday, February 24, 2016 5:14 PM
> >> To: hotspot compiler 
> >> Subject: [9] RFR (XS): 8150436: Incorrect invocation mode when
> >> linkToInteface linker is eliminated
> >>
> >> http://cr.openjdk.java.net/~vlivanov/8150436/webrev.00/
> >> https://bugs.openjdk.java.net/browse/JDK-8150436
> >>
> >> When MH.linkToInterface is eliminated, but the target method is not
> >> inlined, either default or concrete method is attached to the call site.
> >> During call site resolution, invokeinterface invocation mode is used,
> >> but resolution fails when the target method is concrete.
> >>
> >> The fix is to adjust invocation mode to invokevirtual when concrete
> >> method is attached.
> >>
> >> Testing: failing test, JPRT.
> >>
> >> Thanks!
> >>
> >> Best regards,
> >> Vladimir Ivanov
> >


From zoltan.majo at oracle.com  Fri Feb 26 10:17:39 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Fri, 26 Feb 2016 11:17:39 +0100
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56CF2DFD.2090604@oracle.com>
References: <56CF2B77.9000707@oracle.com> <56CF2DFD.2090604@oracle.com>
Message-ID: <56D02643.50608@oracle.com>

Hi Aleksey,


thank you for the feedback!

On 02/25/2016 05:38 PM, Aleksey Shipilev wrote:
> On 02/25/2016 07:27 PM, Zolt?n Maj? wrote:
>> (1) The test spends an increased amount of time in the VM (e.g.,
>> because an ISC-enabled build can trigger up to 2X more compilations
>> than a non-ISC-enabled build);
> I am confused about this. I thought we bootstrap the concatenations once
> per concat site, and then we only "roll" with the linked in
> implementation.

You are right about that. Most "action" related to setting up 
concatenations happens once (in the case of this test during the 
execution of the first finalizer, i.e., FinalizeOverride$Base.finalize()).

> Is that one-shot action enough to get into the despair
> vortex in the test?

Yes, it is. In its original version, the test spends the largest part of 
its execution time in FinalizeOverride$Base.finalize().

>
>> Possible solutions: Update the test to give more chance to the VM to
>> progress. I see two ways of doing that:
>> Solution #1: Reduce the freqency of triggering GCs
>> http://cr.openjdk.java.net/~zmajo/8148940/webrev.00/
>  From the set of presented solutions, I like this solution better,
> because it breaks the Denial-of-Service setup. Other work after ISC --
> e.g. harder GCs -- can possibly trigger the same trouble, right?

I would expect "harder" GCs to trigger the same trouble. I would also 
expect the same (or similar) to happen if a lambda expression were used 
in the finalizer (instead of the string concatenation). But I did not do 
any experiments to confirm/deny this.

>> Solution #2: Remove string operations from finalizers.
>> http://cr.openjdk.java.net/~zmajo/8148940/webrev.01/
>>
>> Solution #2 is faster, but it makes more difficult to monitor the
>> progress of the test than in the case of Solution #1.
> Solution #3: Compile the test with -XDstringConcat=inline to disable ISC
> for this test; jtreg allows this with @compile tag. Mention the vicious
> feedback cycle in comments.

I would not want to do this as ISC will be (already is) the default in 
JDK 9 and we want to test that.

> Solution #4: Kick finalize() methods in classes to link concats
> preemptively, before entering System.gc+System.runFinalization loop.

Yes, that is also a viable solution. But it is a workaround similar to 
Solution #1 that I've already tested/evaluated.

So, based on your feedback, I'd prefer to go with Solution #1:
http://cr.openjdk.java.net/~zmajo/8148940/webrev.00/

Thank you!

Best regards,


Zoltan

>
> -Aleksey
>


From aleksey.shipilev at oracle.com  Fri Feb 26 10:34:21 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 26 Feb 2016 13:34:21 +0300
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56D02643.50608@oracle.com>
References: <56CF2B77.9000707@oracle.com> <56CF2DFD.2090604@oracle.com>
	<56D02643.50608@oracle.com>
Message-ID: <56D02A2D.1020309@oracle.com>

On 02/26/2016 01:17 PM, Zolt?n Maj? wrote:
> So, based on your feedback, I'd prefer to go with Solution #1:
> http://cr.openjdk.java.net/~zmajo/8148940/webrev.00/

Yes, fine by me. Really, DoS-ing the VM like this is calling for
trouble, and we should really use backoffs in these DoS loops.

Cheers,
-Aleksey



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From tobias.hartmann at oracle.com  Fri Feb 26 10:47:10 2016
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 26 Feb 2016 11:47:10 +0100
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56D02643.50608@oracle.com>
References: <56CF2B77.9000707@oracle.com> <56CF2DFD.2090604@oracle.com>
	<56D02643.50608@oracle.com>
Message-ID: <56D02D2E.5020100@oracle.com>

Hi Zoltan,

On 26.02.2016 11:17, Zolt?n Maj? wrote:
> On 02/25/2016 05:38 PM, Aleksey Shipilev wrote:
>> On 02/25/2016 07:27 PM, Zolt?n Maj? wrote:
>>> (1) The test spends an increased amount of time in the VM (e.g.,
>>> because an ISC-enabled build can trigger up to 2X more compilations
>>> than a non-ISC-enabled build);
>> I am confused about this. I thought we bootstrap the concatenations once
>> per concat site, and then we only "roll" with the linked in
>> implementation.
> 
> You are right about that. Most "action" related to setting up concatenations happens once (in the case of this test during the execution of the first finalizer, i.e., FinalizeOverride$Base.finalize()).

I still wonder why we then do 2x compilations with ISC enabled? Do the bootstrapped invokedynamic call sites invoke that many methods compared to the baseline without ISC?
 
> I would expect "harder" GCs to trigger the same trouble. I would also expect the same (or similar) to happen if a lambda expression were used in the finalizer (instead of the string concatenation). But I did not do any experiments to confirm/deny this.

So this sounds like a general problem to me. Your evaluation shows a significant slowdown that potentially affects many other applications. Could you file a new bug for investigation?

> So, based on your feedback, I'd prefer to go with Solution #1:
> http://cr.openjdk.java.net/~zmajo/8148940/webrev.00/

Looks good to me.

Best regards,
Tobias

From aleksey.shipilev at oracle.com  Fri Feb 26 10:50:52 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 26 Feb 2016 13:50:52 +0300
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56D02D2E.5020100@oracle.com>
References: <56CF2B77.9000707@oracle.com> <56CF2DFD.2090604@oracle.com>
	<56D02643.50608@oracle.com> <56D02D2E.5020100@oracle.com>
Message-ID: <56D02E0C.4020405@oracle.com>

On 02/26/2016 01:47 PM, Tobias Hartmann wrote:
> I still wonder why we then do 2x compilations with ISC enabled? Do 
> the bootstrapped invokedynamic call sites invoke that many methods
> compared to the baseline without ISC?

I think that's because current ISC not only prompts the compilation of
java.lang.invoke infra, but also spins up an anonymous class that holds
the concat stub (to be switched off in a few weeks), which would also
get compiled when hot.

Anyhow, that's a trigger, and not the underlying issue. The underlying
issue is DoSing the JVM through System.gc/runFinalization busyloop.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From vladimir.x.ivanov at oracle.com  Fri Feb 26 11:07:03 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 26 Feb 2016 14:07:03 +0300
Subject: [9] RFR (M): 8068038: C2: large constant offsets aren't handled
	on SPARC
In-Reply-To: <56CF9452.7050606@oracle.com>
References: <56CF7B9B.5000007@oracle.com> <56CF9452.7050606@oracle.com>
Message-ID: <56D031D7.9070506@oracle.com>

Thanks, Vladimir.

>> http://cr.openjdk.java.net/~vlivanov/8068038/webrev.00
>
> Looks fine but leave 32-bit removal to JDK-8150388.
No problem, updated webrev in place.

>> PS: there's an additional cleanup [1] in sparc.ad (mostly 32-bit SPARC
>> removal, but also added some comments). It can go along with this fix or
>> as part of the 32-bit SPARC complete removal (JDK-8150388). Let me know
>> what do you prefer.
>
> Should be part of JDK-8150388 changes.
Sure. Updated JDK-8150388 with the link to the webrev.

Best regards,
Vladimir Ivanov

From zoltan.majo at oracle.com  Fri Feb 26 11:09:18 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Fri, 26 Feb 2016 12:09:18 +0100
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56D02E0C.4020405@oracle.com>
References: <56CF2B77.9000707@oracle.com> <56CF2DFD.2090604@oracle.com>
	<56D02643.50608@oracle.com> <56D02D2E.5020100@oracle.com>
	<56D02E0C.4020405@oracle.com>
Message-ID: <56D0325E.8080806@oracle.com>

Hi,


On 02/26/2016 11:50 AM, Aleksey Shipilev wrote:
> On 02/26/2016 01:47 PM, Tobias Hartmann wrote:
>> I still wonder why we then do 2x compilations with ISC enabled? Do
>> the bootstrapped invokedynamic call sites invoke that many methods
>> compared to the baseline without ISC?
> I think that's because current ISC not only prompts the compilation of
> java.lang.invoke infra, but also spins up an anonymous class that holds
> the concat stub (to be switched off in a few weeks), which would also
> get compiled when hot.

It would be interesting to know what the contribution (1) of the 
initialization of the java.lang.invoke infrastructure and (2) of the 
concat stub is.

> Anyhow, that's a trigger, and not the underlying issue. The underlying
> issue is DoSing the JVM through System.gc/runFinalization busyloop.

Yes, I agree that this is a test problem that ISC triggered.

But I think it is important to figure out what is the cost of the 
initialization of the java.lang.invoke infrastructure and of the ISC 
infrastructure. If these initializations happen at (or closely after) VM 
startup, they can potentially increase VM startup time.

So I filed a bug to investigate this problem:
https://bugs.openjdk.java.net/browse/JDK-8150717

Thank you!

Best regards,


Zoltan



>
> -Aleksey
>


From tobias.hartmann at oracle.com  Fri Feb 26 11:16:37 2016
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 26 Feb 2016 12:16:37 +0100
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56D02E0C.4020405@oracle.com>
References: <56CF2B77.9000707@oracle.com> <56CF2DFD.2090604@oracle.com>
	<56D02643.50608@oracle.com> <56D02D2E.5020100@oracle.com>
	<56D02E0C.4020405@oracle.com>
Message-ID: <56D03415.2010706@oracle.com>


On 26.02.2016 11:50, Aleksey Shipilev wrote:
> On 02/26/2016 01:47 PM, Tobias Hartmann wrote:
>> I still wonder why we then do 2x compilations with ISC enabled? Do 
>> the bootstrapped invokedynamic call sites invoke that many methods
>> compared to the baseline without ISC?
> 
> I think that's because current ISC not only prompts the compilation of
> java.lang.invoke infra, but also spins up an anonymous class that holds
> the concat stub (to be switched off in a few weeks), which would also
> get compiled when hot.

Sure but it's surprising that this triggers the compilation of 81 additional methods (or 1127 with -Xcomp). I think it makes sense to investigate and see if we can reduce the number of compilations.

> Anyhow, that's a trigger, and not the underlying issue. The underlying
> issue is DoSing the JVM through System.gc/runFinalization busyloop.

Yes, I agree.

Best regards,
Tobias

From aleksey.shipilev at oracle.com  Fri Feb 26 11:20:47 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 26 Feb 2016 14:20:47 +0300
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56D0325E.8080806@oracle.com>
References: <56CF2B77.9000707@oracle.com> <56CF2DFD.2090604@oracle.com>
	<56D02643.50608@oracle.com> <56D02D2E.5020100@oracle.com>
	<56D02E0C.4020405@oracle.com> <56D0325E.8080806@oracle.com>
Message-ID: <56D0350F.7060200@oracle.com>

On 02/26/2016 02:09 PM, Zolt?n Maj? wrote:
> But I think it is important to figure out what is the cost of the
> initialization of the java.lang.invoke infrastructure and of the ISC
> infrastructure. If these initializations happen at (or closely after) VM
> startup, they can potentially increase VM startup time.

Yes they can, but our experiments so far showed the impact is minimal in
normal operation. What seems to trip this test is any hiccup, however
transient, in VM code that is about to run finalize() code?

> So I filed a bug to investigate this problem:
> https://bugs.openjdk.java.net/browse/JDK-8150717

We already have:
 https://bugs.openjdk.java.net/browse/JDK-8086045

Cheers,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From aleksey.shipilev at oracle.com  Fri Feb 26 11:37:07 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 26 Feb 2016 14:37:07 +0300
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56D03415.2010706@oracle.com>
References: <56CF2B77.9000707@oracle.com> <56CF2DFD.2090604@oracle.com>
	<56D02643.50608@oracle.com> <56D02D2E.5020100@oracle.com>
	<56D02E0C.4020405@oracle.com> <56D03415.2010706@oracle.com>
Message-ID: <56D038E3.6080903@oracle.com>

On 02/26/2016 02:16 PM, Tobias Hartmann wrote:
> 
> On 26.02.2016 11:50, Aleksey Shipilev wrote:
>> On 02/26/2016 01:47 PM, Tobias Hartmann wrote:
>>> I still wonder why we then do 2x compilations with ISC enabled? Do 
>>> the bootstrapped invokedynamic call sites invoke that many methods
>>> compared to the baseline without ISC?
>>
>> I think that's because current ISC not only prompts the compilation of
>> java.lang.invoke infra, but also spins up an anonymous class that holds
>> the concat stub (to be switched off in a few weeks), which would also
>> get compiled when hot.
> 
> Sure but it's surprising that this triggers the compilation of 81
> additional methods (or 1127 with -Xcomp). I think it makes sense to
> investigate and see if we can reduce the number of compilations.

Yes, java.lang.invoke infra has that many interesting methods. See my
comment here:
  https://bugs.openjdk.java.net/browse/JDK-8150717?focusedCommentId=13904458

...or these:
  http://cr.openjdk.java.net/~shade/8150717/compilation-oob.txt
  http://cr.openjdk.java.net/~shade/8150717/compilation-Xcomp.txt

Cheers,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From zoltan.majo at oracle.com  Fri Feb 26 11:42:46 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Fri, 26 Feb 2016 12:42:46 +0100
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56D0350F.7060200@oracle.com>
References: <56CF2B77.9000707@oracle.com> <56CF2DFD.2090604@oracle.com>
	<56D02643.50608@oracle.com> <56D02D2E.5020100@oracle.com>
	<56D02E0C.4020405@oracle.com> <56D0325E.8080806@oracle.com>
	<56D0350F.7060200@oracle.com>
Message-ID: <56D03A36.1020801@oracle.com>


On 02/26/2016 12:20 PM, Aleksey Shipilev wrote:
> On 02/26/2016 02:09 PM, Zolt?n Maj? wrote:
>> But I think it is important to figure out what is the cost of the
>> initialization of the java.lang.invoke infrastructure and of the ISC
>> infrastructure. If these initializations happen at (or closely after) VM
>> startup, they can potentially increase VM startup time.
> Yes they can, but our experiments so far showed the impact is minimal in
> normal operation. What seems to trip this test is any hiccup, however
> transient, in VM code that is about to run finalize() code?

Yes, I assume so.

>> So I filed a bug to investigate this problem:
>> https://bugs.openjdk.java.net/browse/JDK-8150717
> We already have:
>   https://bugs.openjdk.java.net/browse/JDK-8086045

Okay, I closed JDK-8150717 as a duplicate of JDK-8086045.

Best regards,


Zoltan

>
> Cheers,
> -Aleksey
>


From claes.redestad at oracle.com  Fri Feb 26 11:40:27 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 26 Feb 2016 12:40:27 +0100
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
Message-ID: <56D039AB.5050605@oracle.com>

Hi,

src/share/vm/opto/parse1.cpp currently defines a number of global 
counters that is used to collect some statistics. Some of these counters 
are incremented in product builds, but ever only displayed in 
non-product builds if run with -XX:+PrintOptoStatistics.

This patch masks such counters from product builds, removes a few 
counters that were never read, fixes an issue with implicit_null_throws 
which was never incremented in current code (seems it was moved to 
SharedRuntime a long time ago without updating print_statistics) and 
removes an unused enum (InlineStyle):

webrev: http://cr.openjdk.java.net/~redestad/8150720/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8150720

Testing: RBT --test hotspot/test/:hotspot_all, manual verification that 
-XX:+PrintOptoStatistics prints out a count for implicit NPE's thrown

Thanks!

/Claes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rahul.v.raghavan at oracle.com  Fri Feb 26 11:45:43 2016
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Fri, 26 Feb 2016 03:45:43 -0800 (PST)
Subject: RFR(XS): 8140721: ProfilerNumberOf*Methods flags should be diagnostic
Message-ID: 

Hi,

Please review the following patch for JDK-8140721.

- Bug: https://bugs.openjdk.java.net/browse/JDK-8140721
- Webrev: http://cr.openjdk.java.net/~rraghavan/8140721/webrev.00/

- Changed following four flags from 'develop' to 'diagnostic' -
    [ProfilerNumberOfInterpretedMethods, ProfilerNumberOfCompiledMethods, ProfilerNumberOfStubMethods, ProfilerNumberOfRuntimeStubNodes]

- No issues with JPRT (-testset hotspot).
- Confirmed no issues, expected behavior with the change for small unit tests.
  (for debug/release VM with combinations of the flags, UnlockDiagnosticVMOptions usages)
- Found no existing tests using the flags to be changed.

Thanks,
Rahul

From aleksey.shipilev at oracle.com  Fri Feb 26 11:57:08 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 26 Feb 2016 14:57:08 +0300
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D039AB.5050605@oracle.com>
References: <56D039AB.5050605@oracle.com>
Message-ID: <56D03D94.1060901@oracle.com>

On 02/26/2016 02:40 PM, Claes Redestad wrote:
> webrev: http://cr.openjdk.java.net/~redestad/8150720/webrev.00/

Wait, I don't get these parts in the original code:

src/share/vm/opto/node.cpp:
 621 #ifdef ASSERT
 622     if( edge_end+node_size == compile->node_arena()->hwm() ) {
 623       reclaim_in  += edge_size;
 624       reclaim_node+= node_size;
 625     }
 626 #else
 627     // It was; free the input array and object all in one hit
 628     compile->node_arena()->Afree(_in,edge_size+node_size);
 629 #endif

...

 639     // Free just the object
 640 #ifdef ASSERT
 641     if( ((char*)this) + node_size == compile->node_arena()->hwm() )
 642       reclaim_node+= node_size;
 643 #else
 644     compile->node_arena()->Afree(this,node_size);
 645 #endif

We are not freeing when ASSERT is not defined? O_o The patch that
apparently does an equivalent transformation of the original code makes
it even creepier.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From tobias.hartmann at oracle.com  Fri Feb 26 11:59:40 2016
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 26 Feb 2016 12:59:40 +0100
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56D038E3.6080903@oracle.com>
References: <56CF2B77.9000707@oracle.com> <56CF2DFD.2090604@oracle.com>
	<56D02643.50608@oracle.com> <56D02D2E.5020100@oracle.com>
	<56D02E0C.4020405@oracle.com> <56D03415.2010706@oracle.com>
	<56D038E3.6080903@oracle.com>
Message-ID: <56D03E2C.8050109@oracle.com>


On 26.02.2016 12:37, Aleksey Shipilev wrote:
> On 02/26/2016 02:16 PM, Tobias Hartmann wrote:
>>
>> On 26.02.2016 11:50, Aleksey Shipilev wrote:
>>> On 02/26/2016 01:47 PM, Tobias Hartmann wrote:
>>>> I still wonder why we then do 2x compilations with ISC enabled? Do 
>>>> the bootstrapped invokedynamic call sites invoke that many methods
>>>> compared to the baseline without ISC?
>>>
>>> I think that's because current ISC not only prompts the compilation of
>>> java.lang.invoke infra, but also spins up an anonymous class that holds
>>> the concat stub (to be switched off in a few weeks), which would also
>>> get compiled when hot.
>>
>> Sure but it's surprising that this triggers the compilation of 81
>> additional methods (or 1127 with -Xcomp). I think it makes sense to
>> investigate and see if we can reduce the number of compilations.
> 
> Yes, java.lang.invoke infra has that many interesting methods. See my
> comment here:
>   https://bugs.openjdk.java.net/browse/JDK-8150717?focusedCommentId=13904458
> 
> ...or these:
>   http://cr.openjdk.java.net/~shade/8150717/compilation-oob.txt
>   http://cr.openjdk.java.net/~shade/8150717/compilation-Xcomp.txt

Okay. Still surprising that all of these are compiled even without -Xcomp since I assume they are only used for bootstrapping.

Best regards,
Tobias

From claes.redestad at oracle.com  Fri Feb 26 12:22:00 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 26 Feb 2016 13:22:00 +0100
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D03D94.1060901@oracle.com>
References: <56D039AB.5050605@oracle.com> <56D03D94.1060901@oracle.com>
Message-ID: <56D04368.9040304@oracle.com>

Hi,

On 2016-02-26 12:57, Aleksey Shipilev wrote:
> On 02/26/2016 02:40 PM, Claes Redestad wrote:
>> webrev: http://cr.openjdk.java.net/~redestad/8150720/webrev.00/
> Wait, I don't get these parts in the original code:
>
> src/share/vm/opto/node.cpp:
>   621 #ifdef ASSERT
>   622     if( edge_end+node_size == compile->node_arena()->hwm() ) {
>   623       reclaim_in  += edge_size;
>   624       reclaim_node+= node_size;
>   625     }
>   626 #else
>   627     // It was; free the input array and object all in one hit
>   628     compile->node_arena()->Afree(_in,edge_size+node_size);
>   629 #endif
>
> ...
>
>   639     // Free just the object
>   640 #ifdef ASSERT
>   641     if( ((char*)this) + node_size == compile->node_arena()->hwm() )
>   642       reclaim_node+= node_size;
>   643 #else
>   644     compile->node_arena()->Afree(this,node_size);
>   645 #endif
>
> We are not freeing when ASSERT is not defined? O_o The patch that
> apparently does an equivalent transformation of the original code makes
> it even creepier.

yes, this is a weirdness in the original code, and not preserving this 
pattern makes the VM crash early in fastdebug mode.

There is also a small "leak" in the corner case where "edge_end == 
(char*)this" since we're not freeing the input array in this case.

Either way I think diving into this is out of scope for this cleanup, 
though.

/Claes

>
> -Aleksey
>


From vladimir.x.ivanov at oracle.com  Fri Feb 26 12:28:09 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 26 Feb 2016 15:28:09 +0300
Subject: [9] RFR (XS): 8150543: Mismatched access detection is inaccurate
Message-ID: <56D044D9.5030805@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8150543/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8150543

Mismatched access detection doesn't differentiate between boolean[] and 
byte[] element accesses. Alias type flattening erases element type for 
boolean[] to T_BYTE.

The fix is to use more accurate source of information: the address type.

Also, marked the tests as not applicable to C1, since it doesn't 
constant fold unsafe accesses.

Testing: regression test, JPRT.

Best regards,
Vladimir Ivanov

From zoltan.majo at oracle.com  Fri Feb 26 12:29:26 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Fri, 26 Feb 2016 13:29:26 +0100
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
In-Reply-To: <56CF37FC.1080906@oracle.com>
References: <56CF0D09.1080508@oracle.com> <56CF1C18.3080808@oracle.com>
	<56CF280A.1010705@oracle.com> <56CF37FC.1080906@oracle.com>
Message-ID: <56D04526.5040803@oracle.com>

Hi Vladimir,


On 02/25/2016 06:21 PM, Vladimir Kozlov wrote:
> I am fine with removal of adler32 and bmi testing from JPRT runs 
> because we don't have a plan to touch them.
> But code related to CRC32, CRC32c and string may be touched soon for 
> some platforms.

OK, so I've re-enabled testing of the CRC23, CRC32c and string 
intrinsics (still within the hotspot_compiler_3 group). Running the 
group still takes < 30 minutes on our slowest platforms, here are the 
execution times:

West:
  linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(25m 12s)
  solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(11m 46s)

Stockholm:
   linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(24m 18s)
   solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(21m 01s)

Here is the updated webrev:
http://cr.openjdk.java.net/~zmajo/8150349/webrev.01/

> What if we created hotspot_compiler_4 group for them? How much time it 
> would take to run it on slow platforms?

I think it's fine to leave all tests in hotspot_compiler_3 as all 
execution times are still below 30 minutes.

I filed INTJDK-7622854: "Track the execution time of JPRT tests groups" 
so that we can better track the execution times of the 
hotspot_compiler_[1-3] test groups.

Thank you!

Best regards,


Zoltan

>
> Thanks,
> Vladimir
>
> On 2/25/16 8:12 AM, Zolt?n Maj? wrote:
>> Hi Nils,
>>
>>
>> thank you for the feedback!
>>
>> On 02/25/2016 04:22 PM, Nils Eliasson wrote:
>>> Hi Zoltan,
>>>
>>> Have you opened a bug for fixing the tests?
>>
>> No, I have not, because there is an existing issue (INTJDK-7620326) 
>> that is supposed to take care of the high execution
>> time of intrinsic-related tests on platforms where the relevant 
>> intrinsics are not available. I've linked the two issues.
>>
>>>
>>> Do we really want to remove the String intrinsics from the list? 
>>> aren't they pretty new?
>>
>> You are right, they are in part new (in part old intrinsics have been 
>> updated). I thought to remove them nevertheless,
>> because they take a long time to execute and are anyway executed in 
>> our nightlies.
>>
>> Best regards,
>>
>>
>> Zoltan
>>
>>>
>>> Thanks for fixing this,
>>> Nils Eliasson
>>>
>>> On 2016-02-25 15:17, Zolt?n Maj? wrote:
>>>> Hi,
>>>>
>>>>
>>>> please review the patch for 8150349.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8150349
>>>>
>>>> Problem: The hotspot_compiler_3 group of tests takes more than 30 
>>>> minutes on our slowest platforms.
>>>>
>>>>
>>>> Solution: Remove a number of long-running tests from the 
>>>> hotspot_compiler_3 group. All removed tests are related to
>>>> intrinsics, that is, they check the functionality of a reduced set 
>>>> of the VM's functionality that is not often
>>>> modified. Also, we execute all removed tests daily (in our nightly 
>>>> testing).
>>>>
>>>> Here is the time spent in hotspot_compiler_3 on our slowest 
>>>> platforms after removing the tests:
>>>>
>>>> West:
>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 22s)
>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=6 
>>>> parallelcount=6 ram=31744MB cpufreqmhz=2848
>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(19m 09s)
>>>>     platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12 
>>>> parallelcount=12 ram=60690MB cpufreqmhz=2294
>>>>
>>>> Stockholm:
>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 32s)
>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=12 
>>>> parallelcount=12 ram=24576MB    cpufreqmhz=2848
>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(20m 24s)
>>>>     platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8 
>>>> parallelcount=8 ram=16061MB
>>>>
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/
>>>>
>>>> Thank you!
>>>>
>>>> Best regards,
>>>>
>>>>
>>>> Zoltan
>>>>
>>>
>>


From aleksey.shipilev at oracle.com  Fri Feb 26 12:41:19 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 26 Feb 2016 15:41:19 +0300
Subject: [9] RFR (XS): 8150543: Mismatched access detection is inaccurate
In-Reply-To: <56D044D9.5030805@oracle.com>
References: <56D044D9.5030805@oracle.com>
Message-ID: <56D047EF.9040307@oracle.com>

On 02/26/2016 03:28 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8150543/webrev.00/

Looks good.

> Also, marked the tests as not applicable to C1, since it doesn't
> constant fold unsafe accesses.

Okay, but does it hurt to run those tests with C1? My concern is that we
might forget to enable those tests back once/if C1 learns to constant
fold unsafe accesses.

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From aleksey.shipilev at oracle.com  Fri Feb 26 12:43:45 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 26 Feb 2016 15:43:45 +0300
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D04368.9040304@oracle.com>
References: <56D039AB.5050605@oracle.com> <56D03D94.1060901@oracle.com>
	<56D04368.9040304@oracle.com>
Message-ID: <56D04881.60802@oracle.com>

On 02/26/2016 03:22 PM, Claes Redestad wrote:
> Hi,
> 
> On 2016-02-26 12:57, Aleksey Shipilev wrote:
>> On 02/26/2016 02:40 PM, Claes Redestad wrote:
>>> webrev: http://cr.openjdk.java.net/~redestad/8150720/webrev.00/
>> Wait, I don't get these parts in the original code:
>>
>> src/share/vm/opto/node.cpp:
>>   621 #ifdef ASSERT
>>   622     if( edge_end+node_size == compile->node_arena()->hwm() ) {
>>   623       reclaim_in  += edge_size;
>>   624       reclaim_node+= node_size;
>>   625     }
>>   626 #else
>>   627     // It was; free the input array and object all in one hit
>>   628     compile->node_arena()->Afree(_in,edge_size+node_size);
>>   629 #endif
>>
>> ...
>>
>>   639     // Free just the object
>>   640 #ifdef ASSERT
>>   641     if( ((char*)this) + node_size == compile->node_arena()->hwm() )
>>   642       reclaim_node+= node_size;
>>   643 #else
>>   644     compile->node_arena()->Afree(this,node_size);
>>   645 #endif
>>
>> We are not freeing when ASSERT is not defined? O_o The patch that
>> apparently does an equivalent transformation of the original code makes
>> it even creepier.
> 
> yes, this is a weirdness in the original code, and not preserving this
> pattern makes the VM crash early in fastdebug mode.

Dear God.

> There is also a small "leak" in the corner case where "edge_end ==
> (char*)this" since we're not freeing the input array in this case.
> 
> Either way I think diving into this is out of scope for this cleanup,
> though.

Yes, I agree. I don't see other troubles in the patch.

-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From vladimir.x.ivanov at oracle.com  Fri Feb 26 12:51:01 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 26 Feb 2016 15:51:01 +0300
Subject: [9] RFR (XS): 8150543: Mismatched access detection is inaccurate
In-Reply-To: <56D047EF.9040307@oracle.com>
References: <56D044D9.5030805@oracle.com> <56D047EF.9040307@oracle.com>
Message-ID: <56D04A35.2090801@oracle.com>

Thanks for the review, Aleksey.

>> Also, marked the tests as not applicable to C1, since it doesn't
>> constant fold unsafe accesses.
>
> Okay, but does it hurt to run those tests with C1? My concern is that we
> might forget to enable those tests back once/if C1 learns to constant
> fold unsafe accesses.
It requires additional logic in the tests: both to encode expected 
results for different configurations and detect what compiler is in use. 
If C1 support is added, question about testing aspect will naturally 
arise. So, I consider it very unlikely that it will stay untested.

Best regards,
Vladimir Ivanov

From claes.redestad at oracle.com  Fri Feb 26 12:59:33 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 26 Feb 2016 13:59:33 +0100
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D04881.60802@oracle.com>
References: <56D039AB.5050605@oracle.com> <56D03D94.1060901@oracle.com>
	<56D04368.9040304@oracle.com> <56D04881.60802@oracle.com>
Message-ID: <56D04C35.7070808@oracle.com>

On 2016-02-26 13:43, Aleksey Shipilev wrote:
> Yes, I agree. I don't see other troubles in the patch.

Thanks for reviewing!

Anyone else?

/Claes

From vladimir.x.ivanov at oracle.com  Fri Feb 26 13:20:35 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 26 Feb 2016 16:20:35 +0300
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D039AB.5050605@oracle.com>
References: <56D039AB.5050605@oracle.com>
Message-ID: <56D05123.6030108@oracle.com>

I'm curious why not expose them as PerfCounters then.

Best regards,
Vladimir Ivanov

On 2/26/16 2:40 PM, Claes Redestad wrote:
> Hi,
>
> src/share/vm/opto/parse1.cpp currently defines a number of global
> counters that is used to collect some statistics. Some of these counters
> are incremented in product builds, but ever only displayed in
> non-product builds if run with -XX:+PrintOptoStatistics.
>
> This patch masks such counters from product builds, removes a few
> counters that were never read, fixes an issue with implicit_null_throws
> which was never incremented in current code (seems it was moved to
> SharedRuntime a long time ago without updating print_statistics) and
> removes an unused enum (InlineStyle):
>
> webrev: http://cr.openjdk.java.net/~redestad/8150720/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8150720
>
> Testing: RBT --test hotspot/test/:hotspot_all, manual verification that
> -XX:+PrintOptoStatistics prints out a count for implicit NPE's thrown
>
> Thanks!
>
> /Claes

From claes.redestad at oracle.com  Fri Feb 26 13:31:26 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 26 Feb 2016 14:31:26 +0100
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D05123.6030108@oracle.com>
References: <56D039AB.5050605@oracle.com> <56D05123.6030108@oracle.com>
Message-ID: <56D053AE.1020609@oracle.com>

On 2016-02-26 14:20, Vladimir Ivanov wrote:
> I'm curious why not expose them as PerfCounters then.

This might make sense for some of these, but I felt that needs to be 
evaluated
on a case-by-case basis and should be backed up by request for making 
this particular
data available in product builds. I don't think this cleanup needs to be 
blocked while
investigating other options for making potentially useful data available.

Thanks!

/Claes
>
> Best regards,
> Vladimir Ivanov
>
> On 2/26/16 2:40 PM, Claes Redestad wrote:
>> Hi,
>>
>> src/share/vm/opto/parse1.cpp currently defines a number of global
>> counters that is used to collect some statistics. Some of these counters
>> are incremented in product builds, but ever only displayed in
>> non-product builds if run with -XX:+PrintOptoStatistics.
>>
>> This patch masks such counters from product builds, removes a few
>> counters that were never read, fixes an issue with implicit_null_throws
>> which was never incremented in current code (seems it was moved to
>> SharedRuntime a long time ago without updating print_statistics) and
>> removes an unused enum (InlineStyle):
>>
>> webrev: http://cr.openjdk.java.net/~redestad/8150720/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8150720
>>
>> Testing: RBT --test hotspot/test/:hotspot_all, manual verification that
>> -XX:+PrintOptoStatistics prints out a count for implicit NPE's thrown
>>
>> Thanks!
>>
>> /Claes


From nils.eliasson at oracle.com  Fri Feb 26 13:50:26 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 26 Feb 2016 14:50:26 +0100
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
In-Reply-To: <56D04526.5040803@oracle.com>
References: <56CF0D09.1080508@oracle.com> <56CF1C18.3080808@oracle.com>
	<56CF280A.1010705@oracle.com> <56CF37FC.1080906@oracle.com>
	<56D04526.5040803@oracle.com>
Message-ID: <56D05822.2030801@oracle.com>

Hi Zoltan,

On 2016-02-26 13:29, Zolt?n Maj? wrote:
> Hi Vladimir,
>
>
> On 02/25/2016 06:21 PM, Vladimir Kozlov wrote:
>> I am fine with removal of adler32 and bmi testing from JPRT runs 
>> because we don't have a plan to touch them.
>> But code related to CRC32, CRC32c and string may be touched soon for 
>> some platforms.
>
> OK, so I've re-enabled testing of the CRC23, CRC32c and string 
> intrinsics (still within the hotspot_compiler_3 group). Running the 
> group still takes < 30 minutes on our slowest platforms, here are the 
> execution times:
>
> West:
>  linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(25m 12s)
>  solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(11m 46s)
>
> Stockholm:
>   linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(24m 18s)
>   solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(21m 01s)
>
> Here is the updated webrev:
> http://cr.openjdk.java.net/~zmajo/8150349/webrev.01/
>
>> What if we created hotspot_compiler_4 group for them? How much time 
>> it would take to run it on slow platforms?
>
> I think it's fine to leave all tests in hotspot_compiler_3 as all 
> execution times are still below 30 minutes.

Removing these test solves this issue in the JPRT run, but they will 
still run in nightlies. We should still file bugs for making these tests 
faster.

Regards,
Nils

>
> I filed INTJDK-7622854: "Track the execution time of JPRT tests 
> groups" so that we can better track the execution times of the 
> hotspot_compiler_[1-3] test groups.
>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>
>>
>> Thanks,
>> Vladimir
>>
>> On 2/25/16 8:12 AM, Zolt?n Maj? wrote:
>>> Hi Nils,
>>>
>>>
>>> thank you for the feedback!
>>>
>>> On 02/25/2016 04:22 PM, Nils Eliasson wrote:
>>>> Hi Zoltan,
>>>>
>>>> Have you opened a bug for fixing the tests?
>>>
>>> No, I have not, because there is an existing issue (INTJDK-7620326) 
>>> that is supposed to take care of the high execution
>>> time of intrinsic-related tests on platforms where the relevant 
>>> intrinsics are not available. I've linked the two issues.
>>>
>>>>
>>>> Do we really want to remove the String intrinsics from the list? 
>>>> aren't they pretty new?
>>>
>>> You are right, they are in part new (in part old intrinsics have 
>>> been updated). I thought to remove them nevertheless,
>>> because they take a long time to execute and are anyway executed in 
>>> our nightlies.
>>>
>>> Best regards,
>>>
>>>
>>> Zoltan
>>>
>>>>
>>>> Thanks for fixing this,
>>>> Nils Eliasson
>>>>
>>>> On 2016-02-25 15:17, Zolt?n Maj? wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> please review the patch for 8150349.
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8150349
>>>>>
>>>>> Problem: The hotspot_compiler_3 group of tests takes more than 30 
>>>>> minutes on our slowest platforms.
>>>>>
>>>>>
>>>>> Solution: Remove a number of long-running tests from the 
>>>>> hotspot_compiler_3 group. All removed tests are related to
>>>>> intrinsics, that is, they check the functionality of a reduced set 
>>>>> of the VM's functionality that is not often
>>>>> modified. Also, we execute all removed tests daily (in our nightly 
>>>>> testing).
>>>>>
>>>>> Here is the time spent in hotspot_compiler_3 on our slowest 
>>>>> platforms after removing the tests:
>>>>>
>>>>> West:
>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 22s)
>>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=6 
>>>>> parallelcount=6 ram=31744MB cpufreqmhz=2848
>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(19m 09s)
>>>>>     platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12 
>>>>> parallelcount=12 ram=60690MB cpufreqmhz=2294
>>>>>
>>>>> Stockholm:
>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 32s)
>>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc 
>>>>> cpus=12 parallelcount=12 ram=24576MB cpufreqmhz=2848
>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(20m 24s)
>>>>>     platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8 
>>>>> parallelcount=8 ram=16061MB
>>>>>
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/
>>>>>
>>>>> Thank you!
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>> Zoltan
>>>>>
>>>>
>>>
>


From nils.eliasson at oracle.com  Fri Feb 26 13:51:58 2016
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 26 Feb 2016 14:51:58 +0100
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
In-Reply-To: <56CF37FC.1080906@oracle.com>
References: <56CF0D09.1080508@oracle.com> <56CF1C18.3080808@oracle.com>
	<56CF280A.1010705@oracle.com> <56CF37FC.1080906@oracle.com>
Message-ID: <56D0587E.4010602@oracle.com>

Hi Vladimir,

On 2016-02-25 18:21, Vladimir Kozlov wrote:
> I am fine with removal of adler32 and bmi testing from JPRT runs 
> because we don't have a plan to touch them.
> But code related to CRC32, CRC32c and string may be touched soon for 
> some platforms.
> What if we created hotspot_compiler_4 group for them? How much time it 
> would take to run it on slow platforms?
I don't think the other teams will be happy if we add yet another batch 
to JPRT. We can speed up some of these time consuming tests a lot.

Regards,
Nils Eliasson

>
> Thanks,
> Vladimir
>
> On 2/25/16 8:12 AM, Zolt?n Maj? wrote:
>> Hi Nils,
>>
>>
>> thank you for the feedback!
>>
>> On 02/25/2016 04:22 PM, Nils Eliasson wrote:
>>> Hi Zoltan,
>>>
>>> Have you opened a bug for fixing the tests?
>>
>> No, I have not, because there is an existing issue (INTJDK-7620326) 
>> that is supposed to take care of the high execution
>> time of intrinsic-related tests on platforms where the relevant 
>> intrinsics are not available. I've linked the two issues.
>>
>>>
>>> Do we really want to remove the String intrinsics from the list? 
>>> aren't they pretty new?
>>
>> You are right, they are in part new (in part old intrinsics have been 
>> updated). I thought to remove them nevertheless,
>> because they take a long time to execute and are anyway executed in 
>> our nightlies.
>>
>> Best regards,
>>
>>
>> Zoltan
>>
>>>
>>> Thanks for fixing this,
>>> Nils Eliasson
>>>
>>> On 2016-02-25 15:17, Zolt?n Maj? wrote:
>>>> Hi,
>>>>
>>>>
>>>> please review the patch for 8150349.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8150349
>>>>
>>>> Problem: The hotspot_compiler_3 group of tests takes more than 30 
>>>> minutes on our slowest platforms.
>>>>
>>>>
>>>> Solution: Remove a number of long-running tests from the 
>>>> hotspot_compiler_3 group. All removed tests are related to
>>>> intrinsics, that is, they check the functionality of a reduced set 
>>>> of the VM's functionality that is not often
>>>> modified. Also, we execute all removed tests daily (in our nightly 
>>>> testing).
>>>>
>>>> Here is the time spent in hotspot_compiler_3 on our slowest 
>>>> platforms after removing the tests:
>>>>
>>>> West:
>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 22s)
>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=6 
>>>> parallelcount=6 ram=31744MB cpufreqmhz=2848
>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(19m 09s)
>>>>     platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12 
>>>> parallelcount=12 ram=60690MB cpufreqmhz=2294
>>>>
>>>> Stockholm:
>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 32s)
>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=12 
>>>> parallelcount=12 ram=24576MB    cpufreqmhz=2848
>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(20m 24s)
>>>>     platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8 
>>>> parallelcount=8 ram=16061MB
>>>>
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/
>>>>
>>>> Thank you!
>>>>
>>>> Best regards,
>>>>
>>>>
>>>> Zoltan
>>>>
>>>
>>


From zoltan.majo at oracle.com  Fri Feb 26 13:55:30 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Fri, 26 Feb 2016 14:55:30 +0100
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
In-Reply-To: <56D05822.2030801@oracle.com>
References: <56CF0D09.1080508@oracle.com> <56CF1C18.3080808@oracle.com>
	<56CF280A.1010705@oracle.com> <56CF37FC.1080906@oracle.com>
	<56D04526.5040803@oracle.com> <56D05822.2030801@oracle.com>
Message-ID: <56D05952.4070200@oracle.com>

HI Nils,


On 02/26/2016 02:50 PM, Nils Eliasson wrote:
> [...]
> Removing these test solves this issue in the JPRT run, but they will 
> still run in nightlies. We should still file bugs for making these 
> tests faster.

Yes, I agree. There is an existing bug, INTJDK-7620326, and I linked the 
current issue to that one.

Best regards,


Zoltan

>
> Regards,
> Nils
>
>>
>> I filed INTJDK-7622854: "Track the execution time of JPRT tests 
>> groups" so that we can better track the execution times of the 
>> hotspot_compiler_[1-3] test groups.
>>
>> Thank you!
>>
>> Best regards,
>>
>>
>> Zoltan
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 2/25/16 8:12 AM, Zolt?n Maj? wrote:
>>>> Hi Nils,
>>>>
>>>>
>>>> thank you for the feedback!
>>>>
>>>> On 02/25/2016 04:22 PM, Nils Eliasson wrote:
>>>>> Hi Zoltan,
>>>>>
>>>>> Have you opened a bug for fixing the tests?
>>>>
>>>> No, I have not, because there is an existing issue (INTJDK-7620326) 
>>>> that is supposed to take care of the high execution
>>>> time of intrinsic-related tests on platforms where the relevant 
>>>> intrinsics are not available. I've linked the two issues.
>>>>
>>>>>
>>>>> Do we really want to remove the String intrinsics from the list? 
>>>>> aren't they pretty new?
>>>>
>>>> You are right, they are in part new (in part old intrinsics have 
>>>> been updated). I thought to remove them nevertheless,
>>>> because they take a long time to execute and are anyway executed in 
>>>> our nightlies.
>>>>
>>>> Best regards,
>>>>
>>>>
>>>> Zoltan
>>>>
>>>>>
>>>>> Thanks for fixing this,
>>>>> Nils Eliasson
>>>>>
>>>>> On 2016-02-25 15:17, Zolt?n Maj? wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> please review the patch for 8150349.
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8150349
>>>>>>
>>>>>> Problem: The hotspot_compiler_3 group of tests takes more than 30 
>>>>>> minutes on our slowest platforms.
>>>>>>
>>>>>>
>>>>>> Solution: Remove a number of long-running tests from the 
>>>>>> hotspot_compiler_3 group. All removed tests are related to
>>>>>> intrinsics, that is, they check the functionality of a reduced 
>>>>>> set of the VM's functionality that is not often
>>>>>> modified. Also, we execute all removed tests daily (in our 
>>>>>> nightly testing).
>>>>>>
>>>>>> Here is the time spent in hotspot_compiler_3 on our slowest 
>>>>>> platforms after removing the tests:
>>>>>>
>>>>>> West:
>>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 
>>>>>> 22s)
>>>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc 
>>>>>> cpus=6 parallelcount=6 ram=31744MB cpufreqmhz=2848
>>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(19m 09s)
>>>>>>     platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12 
>>>>>> parallelcount=12 ram=60690MB cpufreqmhz=2294
>>>>>>
>>>>>> Stockholm:
>>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 
>>>>>> 32s)
>>>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc 
>>>>>> cpus=12 parallelcount=12 ram=24576MB cpufreqmhz=2848
>>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(20m 24s)
>>>>>>     platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8 
>>>>>> parallelcount=8 ram=16061MB
>>>>>>
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/
>>>>>>
>>>>>> Thank you!
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>>
>>>>>> Zoltan
>>>>>>
>>>>>
>>>>
>>
>


From zoltan.majo at oracle.com  Fri Feb 26 14:00:47 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Fri, 26 Feb 2016 15:00:47 +0100
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
In-Reply-To: <56D05952.4070200@oracle.com>
References: <56CF0D09.1080508@oracle.com> <56CF1C18.3080808@oracle.com>
	<56CF280A.1010705@oracle.com> <56CF37FC.1080906@oracle.com>
	<56D04526.5040803@oracle.com> <56D05822.2030801@oracle.com>
	<56D05952.4070200@oracle.com>
Message-ID: <56D05A8F.5030300@oracle.com>



On 02/26/2016 02:55 PM, Zolt?n Maj? wrote:
> HI Nils,
>
>
> On 02/26/2016 02:50 PM, Nils Eliasson wrote:
>> [...]
>> Removing these test solves this issue in the JPRT run, but they will 
>> still run in nightlies. We should still file bugs for making these 
>> tests faster.
>
> Yes, I agree. There is an existing bug, INTJDK-7620326, and I linked 
> the current issue to that one.

P.S.: Forgot to mention: The goal of INTJDK-7620326 is to execute 
intrinsic-related tests only on platforms where intrinsics are 
available. This solves some, but not all of our problems. Some 
intrinsic-related tests take a long time even on platforms where the 
intrinsic is available.

I know you reduced the execution time of the Adler32 intrinsic by 
changing it to execute fewer iterations. Is there a bug filed for that?
>
> Best regards,
>
>
> Zoltan
>
>>
>> Regards,
>> Nils
>>
>>>
>>> I filed INTJDK-7622854: "Track the execution time of JPRT tests 
>>> groups" so that we can better track the execution times of the 
>>> hotspot_compiler_[1-3] test groups.
>>>
>>> Thank you!
>>>
>>> Best regards,
>>>
>>>
>>> Zoltan
>>>
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 2/25/16 8:12 AM, Zolt?n Maj? wrote:
>>>>> Hi Nils,
>>>>>
>>>>>
>>>>> thank you for the feedback!
>>>>>
>>>>> On 02/25/2016 04:22 PM, Nils Eliasson wrote:
>>>>>> Hi Zoltan,
>>>>>>
>>>>>> Have you opened a bug for fixing the tests?
>>>>>
>>>>> No, I have not, because there is an existing issue 
>>>>> (INTJDK-7620326) that is supposed to take care of the high execution
>>>>> time of intrinsic-related tests on platforms where the relevant 
>>>>> intrinsics are not available. I've linked the two issues.
>>>>>
>>>>>>
>>>>>> Do we really want to remove the String intrinsics from the list? 
>>>>>> aren't they pretty new?
>>>>>
>>>>> You are right, they are in part new (in part old intrinsics have 
>>>>> been updated). I thought to remove them nevertheless,
>>>>> because they take a long time to execute and are anyway executed 
>>>>> in our nightlies.
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>> Zoltan
>>>>>
>>>>>>
>>>>>> Thanks for fixing this,
>>>>>> Nils Eliasson
>>>>>>
>>>>>> On 2016-02-25 15:17, Zolt?n Maj? wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> please review the patch for 8150349.
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8150349
>>>>>>>
>>>>>>> Problem: The hotspot_compiler_3 group of tests takes more than 
>>>>>>> 30 minutes on our slowest platforms.
>>>>>>>
>>>>>>>
>>>>>>> Solution: Remove a number of long-running tests from the 
>>>>>>> hotspot_compiler_3 group. All removed tests are related to
>>>>>>> intrinsics, that is, they check the functionality of a reduced 
>>>>>>> set of the VM's functionality that is not often
>>>>>>> modified. Also, we execute all removed tests daily (in our 
>>>>>>> nightly testing).
>>>>>>>
>>>>>>> Here is the time spent in hotspot_compiler_3 on our slowest 
>>>>>>> platforms after removing the tests:
>>>>>>>
>>>>>>> West:
>>>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 
>>>>>>> 22s)
>>>>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc 
>>>>>>> cpus=6 parallelcount=6 ram=31744MB cpufreqmhz=2848
>>>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(19m 09s)
>>>>>>>     platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12 
>>>>>>> parallelcount=12 ram=60690MB cpufreqmhz=2294
>>>>>>>
>>>>>>> Stockholm:
>>>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 
>>>>>>> 32s)
>>>>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc 
>>>>>>> cpus=12 parallelcount=12 ram=24576MB cpufreqmhz=2848
>>>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(20m 24s)
>>>>>>>     platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8 
>>>>>>> parallelcount=8 ram=16061MB
>>>>>>>
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/
>>>>>>>
>>>>>>> Thank you!
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>>
>>>>>>> Zoltan
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>


From hui.shi at linaro.org  Fri Feb 26 14:28:01 2016
From: hui.shi at linaro.org (Hui Shi)
Date: Fri, 26 Feb 2016 22:28:01 +0800
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJGUjogODE0OTczMzogQUFyY2g2NDogcmVmYWN0b3JjaGFyX2Fycg==?=
	=?UTF-8?B?YXlfZXF1YWxzL2J5dGVfYXJyYXlfZXF1YWxzL3N0cmluZ19lcXVhbHM=?=
In-Reply-To: <56CDBD2A.9050002@oracle.com>
References: <56CC2DF8.60806@oracle.com>
	
	<56C70C42.5020309@oracle.com>
	
	<56CC8630.2020708@redhat.com>
	
	<56CDBD2A.9050002@oracle.com>
Message-ID: 

Thanks Aleksey!

Can I have another review for this patch?

Regards
Hui

On 24 February 2016 at 22:24, Aleksey Shipilev 
wrote:

> On 02/24/2016 04:02 PM, Hui Shi wrote:
> > Thanks Andrew! Your comment looks really better and performance doesn't
> > change when run JMHSample_97_ArrayEqual.java
> > <
> http://cr.openjdk.java.net/%7Ehshi/8149733/webrev2/JMHSample_97_ArrayEqual.java>
> test.
> >
> > latest webrev http://cr.openjdk.java.net/~hshi/8149733/webrev3/
> > 
>
> Good.
>
> > Following is result with Aleksey's updated test case (-w 5 -wi 3 -i3 -r
> > 10), first 4 group are for base run with base string length 0, 8, 31,
> > 1024. Performance with patch doesn't show same improvement with early
> > test. Only small length string equal tests still show obvious
> improvement.
>
> ...and that's okay for refactoring.
>
> Cheers,
> -Aleksey
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From aph at redhat.com  Fri Feb 26 14:37:57 2016
From: aph at redhat.com (Andrew Haley)
Date: Fri, 26 Feb 2016 14:37:57 +0000
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJGUjogODE0OTczMzogQUFyY2g2NDogcmVmYWN0?=
	=?UTF-8?Q?orchar=5farray=5fequals/byte=5farray=5fequals/string=5fequals?=
In-Reply-To: 
References: <56CC2DF8.60806@oracle.com>
	
	<56C70C42.5020309@oracle.com> 
	<56CC8630.2020708@redhat.com>
	
	<56CDBD2A.9050002@oracle.com>
	
Message-ID: <56D06345.7010309@redhat.com>

On 02/26/2016 02:28 PM, Hui Shi wrote:
> Can I have another review for this patch?

If you insist.  OK.

Andrew.


From roland.schatz at oracle.com  Fri Feb 26 14:47:14 2016
From: roland.schatz at oracle.com (Roland Schatz)
Date: Fri, 26 Feb 2016 15:47:14 +0100
Subject: RFR(XS): 8150727: [JVMCI] add LoadLoad to the implicit memory
	barriers on AMD64
Message-ID: <56D06572.7060406@oracle.com>

Hi,

Please review and integrate this small fix:
http://cr.openjdk.java.net/~rschatz/JDK-8150727/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8150727

It was contributed by Benoit Daloze (cc'ed), and lgtm (but I'm not a 
reviewer myself).

Thanks,
Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vladimir.x.ivanov at oracle.com  Fri Feb 26 15:31:31 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 26 Feb 2016 18:31:31 +0300
Subject: [9] RFR (M): 8143407: C1: @Stable array support
In-Reply-To: <56C7602B.3090300@oracle.com>
References: <56C7602B.3090300@oracle.com>
Message-ID: <56D06FD3.4080306@oracle.com>

Any reviews, please?

Best regards,
Vladimir Ivanov

On 2/19/16 9:34 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8143407/webrev.01
> https://bugs.openjdk.java.net/browse/JDK-8143407
>
> Add C1 support for constant folding loads from @Stable arrays.
> It aligns C1 & C2 behavior w.r.t. @Stable fields and was requested for
> VarHandles [1] implementation.
>
> I introduced StableArrayConstant to track stable array dimension.
>
> It is needed to disambiguate the following cases:
>   (1) @Stable int[][][] intArr = new int[...][...][...];
>   (2) @Stable  Object[] objArr = new int[...][...][...];
>
> In the first case, all elements of multi-dimensional array w/
> non-default values are considered constant.
>
> In the latter, only elements of objArray (which are int[][] instances).
>
> Testing: unit tests on @Stable support, JPRT.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
>
> [1] http://openjdk.java.net/jeps/193

From vladimir.x.ivanov at oracle.com  Fri Feb 26 15:59:51 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 26 Feb 2016 18:59:51 +0300
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D053AE.1020609@oracle.com>
References: <56D039AB.5050605@oracle.com> <56D05123.6030108@oracle.com>
	<56D053AE.1020609@oracle.com>
Message-ID: <56D07677.2040904@oracle.com>

PrintOptoStatistics is not the only flag which guards the usage:

src/share/vm/runtime/java.cpp:
#ifdef COMPILER2
   if ((PrintOptoStatistics || LogVMOutput || LogCompilation) && 
UseCompiler) {
     FlagSetting fs(DisplayVMOutput, DisplayVMOutput && 
PrintOptoStatistics);
     Compile::print_statistics();

LogCompilation is diagnostic, so it is possible to dump some of the 
counters in product binaries.

You can even make PrintOptoStatistics diagnostic as well. It will 
significantly the cleanup part ;-)

Best regards,
Vladimir Ivanov

On 2/26/16 4:31 PM, Claes Redestad wrote:
> On 2016-02-26 14:20, Vladimir Ivanov wrote:
>> I'm curious why not expose them as PerfCounters then.
>
> This might make sense for some of these, but I felt that needs to be
> evaluated
> on a case-by-case basis and should be backed up by request for making
> this particular
> data available in product builds. I don't think this cleanup needs to be
> blocked while
> investigating other options for making potentially useful data available.
>
> Thanks!
>
> /Claes
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 2/26/16 2:40 PM, Claes Redestad wrote:
>>> Hi,
>>>
>>> src/share/vm/opto/parse1.cpp currently defines a number of global
>>> counters that is used to collect some statistics. Some of these counters
>>> are incremented in product builds, but ever only displayed in
>>> non-product builds if run with -XX:+PrintOptoStatistics.
>>>
>>> This patch masks such counters from product builds, removes a few
>>> counters that were never read, fixes an issue with implicit_null_throws
>>> which was never incremented in current code (seems it was moved to
>>> SharedRuntime a long time ago without updating print_statistics) and
>>> removes an unused enum (InlineStyle):
>>>
>>> webrev: http://cr.openjdk.java.net/~redestad/8150720/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8150720
>>>
>>> Testing: RBT --test hotspot/test/:hotspot_all, manual verification that
>>> -XX:+PrintOptoStatistics prints out a count for implicit NPE's thrown
>>>
>>> Thanks!
>>>
>>> /Claes
>

From claes.redestad at oracle.com  Fri Feb 26 16:23:43 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 26 Feb 2016 17:23:43 +0100
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D07677.2040904@oracle.com>
References: <56D039AB.5050605@oracle.com> <56D05123.6030108@oracle.com>
	<56D053AE.1020609@oracle.com> <56D07677.2040904@oracle.com>
Message-ID: <56D07C0F.4060209@oracle.com>

While LogCompilation is diagnostic, Parse::print_statistics is the only 
place where any of the affected counters are printed out, and it's not 
defined in product binaries.

If there's agreement that PrintOptoStatistics should be made diagnostic 
(or converted to UL) then I won't object, but if so I'd insist in 
wrapping the values in PerfCounters, since that makes them more useful 
as well as pads the values (haven't measured whether or not these cause 
any measurable false sharing, but global, non-atomically updated values 
do make me uneasy).

I'd prefer pushing this as-is and follow-up on converting some or all 
counters to diagnostic separately, though.

Thanks!

/Claes

On 2016-02-26 16:59, Vladimir Ivanov wrote:
> PrintOptoStatistics is not the only flag which guards the usage:
>
> src/share/vm/runtime/java.cpp:
> #ifdef COMPILER2
>   if ((PrintOptoStatistics || LogVMOutput || LogCompilation) && 
> UseCompiler) {
>     FlagSetting fs(DisplayVMOutput, DisplayVMOutput && 
> PrintOptoStatistics);
>     Compile::print_statistics();
>
> LogCompilation is diagnostic, so it is possible to dump some of the 
> counters in product binaries.
>
> You can even make PrintOptoStatistics diagnostic as well. It will 
> significantly the cleanup part ;-)
>
> Best regards,
> Vladimir Ivanov
>
> On 2/26/16 4:31 PM, Claes Redestad wrote:
>> On 2016-02-26 14:20, Vladimir Ivanov wrote:
>>> I'm curious why not expose them as PerfCounters then.
>>
>> This might make sense for some of these, but I felt that needs to be
>> evaluated
>> on a case-by-case basis and should be backed up by request for making
>> this particular
>> data available in product builds. I don't think this cleanup needs to be
>> blocked while
>> investigating other options for making potentially useful data 
>> available.
>>
>> Thanks!
>>
>> /Claes
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 2/26/16 2:40 PM, Claes Redestad wrote:
>>>> Hi,
>>>>
>>>> src/share/vm/opto/parse1.cpp currently defines a number of global
>>>> counters that is used to collect some statistics. Some of these 
>>>> counters
>>>> are incremented in product builds, but ever only displayed in
>>>> non-product builds if run with -XX:+PrintOptoStatistics.
>>>>
>>>> This patch masks such counters from product builds, removes a few
>>>> counters that were never read, fixes an issue with 
>>>> implicit_null_throws
>>>> which was never incremented in current code (seems it was moved to
>>>> SharedRuntime a long time ago without updating print_statistics) and
>>>> removes an unused enum (InlineStyle):
>>>>
>>>> webrev: http://cr.openjdk.java.net/~redestad/8150720/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8150720
>>>>
>>>> Testing: RBT --test hotspot/test/:hotspot_all, manual verification 
>>>> that
>>>> -XX:+PrintOptoStatistics prints out a count for implicit NPE's thrown
>>>>
>>>> Thanks!
>>>>
>>>> /Claes
>>


From vladimir.x.ivanov at oracle.com  Fri Feb 26 16:52:15 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 26 Feb 2016 19:52:15 +0300
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D07C0F.4060209@oracle.com>
References: <56D039AB.5050605@oracle.com> <56D05123.6030108@oracle.com>
	<56D053AE.1020609@oracle.com> <56D07677.2040904@oracle.com>
	<56D07C0F.4060209@oracle.com>
Message-ID: <56D082BF.9000702@oracle.com>

> While LogCompilation is diagnostic, Parse::print_statistics is the only
> place where any of the affected counters are printed out, and it's not
> defined in product binaries.
Yes, you are right. I missed that Compile::print_statics is empty in 
product binaries:
   static void print_statistics() PRODUCT_RETURN;

> If there's agreement that PrintOptoStatistics should be made diagnostic
> (or converted to UL) then I won't object, but if so I'd insist in
> wrapping the values in PerfCounters, since that makes them more useful
> as well as pads the values (haven't measured whether or not these cause
> any measurable false sharing, but global, non-atomically updated values
> do make me uneasy).
>
> I'd prefer pushing this as-is and follow-up on converting some or all
> counters to diagnostic separately, though.
I'm fine with removing unused counters, but I don't feel very 
comfortable with all these new macro usages.

So, I'd prefer to defer that part and clean it up when making 
PrintOptoStatistics diagnostics and converting the raw counters to 
PerfCounters.

Best regards,
Vladimir Ivanov

From vladimir.kozlov at oracle.com  Fri Feb 26 17:56:21 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 26 Feb 2016 09:56:21 -0800
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D039AB.5050605@oracle.com>
References: <56D039AB.5050605@oracle.com>
Message-ID: <56D091C5.1050903@oracle.com>

Good changes. We indeed print statistics only in non-product build.

graphKit.cpp - add {} to code:

+#ifndef PRODUCT
      if (null_true == top())
        explicit_null_checks_elided++;
+#endif

ifnode.cpp - add {} and adjust spaces "if (dist > 2) {":

+#ifndef PRODUCT
    if( dist > 2 )              // Add to count of NULL checks elided
      explicit_null_checks_elided++;
+#endif

parse1.cpp - the same:

-  if( implicit_null_throws )
+  if( SharedRuntime::_implicit_null_throws )
      tty->print_cr("%d implicit null exceptions at runtime",
-                  implicit_null_throws);
+                  SharedRuntime::_implicit_null_throws);


 > There is also a small "leak" in the corner case where "edge_end ==
 > (char*)this" since we're not freeing the input array in this case.

There is no "leak" since after compilation is done all C2 arenas are 
cleaned/freed. Yes, during compilation required space could be increased.

 > We are not freeing when ASSERT is not defined? O_o The patch that
 > apparently does an equivalent transformation of the original code 
makes it even creepier.

It is done to catch dangling Node* pointers in debug build:

  661 #ifdef ASSERT
  662   // We will not actually delete the storage, but we'll make the 
node unusable.
  663   *(address*)this = badAddress;  // smash the C++ vtbl, probably
  664   _in = _out = (Node**) badAddress;

So please revert that code back except the code which just increment 
unused counters and can be indeed removed.

Thanks,
Vladimir

On 2/26/16 3:40 AM, Claes Redestad wrote:
> Hi,
>
> src/share/vm/opto/parse1.cpp currently defines a number of global
> counters that is used to collect some statistics. Some of these counters
> are incremented in product builds, but ever only displayed in
> non-product builds if run with -XX:+PrintOptoStatistics.
>
> This patch masks such counters from product builds, removes a few
> counters that were never read, fixes an issue with implicit_null_throws
> which was never incremented in current code (seems it was moved to
> SharedRuntime a long time ago without updating print_statistics) and
> removes an unused enum (InlineStyle):
>
> webrev: http://cr.openjdk.java.net/~redestad/8150720/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8150720
>
> Testing: RBT --test hotspot/test/:hotspot_all, manual verification that
> -XX:+PrintOptoStatistics prints out a count for implicit NPE's thrown
>
> Thanks!
>
> /Claes

From vladimir.kozlov at oracle.com  Fri Feb 26 18:14:59 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 26 Feb 2016 10:14:59 -0800
Subject: [9] RFR (M): 8068038: C2: large constant offsets aren't handled
	on SPARC
In-Reply-To: <56D031D7.9070506@oracle.com>
References: <56CF7B9B.5000007@oracle.com> <56CF9452.7050606@oracle.com>
	<56D031D7.9070506@oracle.com>
Message-ID: <56D09623.9090003@oracle.com>

Good.

Thanks,
Vladimir

On 2/26/16 3:07 AM, Vladimir Ivanov wrote:
> Thanks, Vladimir.
>
>>> http://cr.openjdk.java.net/~vlivanov/8068038/webrev.00
>>
>> Looks fine but leave 32-bit removal to JDK-8150388.
> No problem, updated webrev in place.
>
>>> PS: there's an additional cleanup [1] in sparc.ad (mostly 32-bit SPARC
>>> removal, but also added some comments). It can go along with this fix or
>>> as part of the 32-bit SPARC complete removal (JDK-8150388). Let me know
>>> what do you prefer.
>>
>> Should be part of JDK-8150388 changes.
> Sure. Updated JDK-8150388 with the link to the webrev.
>
> Best regards,
> Vladimir Ivanov

From vladimir.kozlov at oracle.com  Fri Feb 26 18:27:38 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 26 Feb 2016 10:27:38 -0800
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
In-Reply-To: <56D04526.5040803@oracle.com>
References: <56CF0D09.1080508@oracle.com> <56CF1C18.3080808@oracle.com>
	<56CF280A.1010705@oracle.com> <56CF37FC.1080906@oracle.com>
	<56D04526.5040803@oracle.com>
Message-ID: <56D0991A.1000404@oracle.com>

Good. I am fine to not split test group since, as you pointed, we will 
work on tests time improvement.

Thanks,
Vladimir

On 2/26/16 4:29 AM, Zolt?n Maj? wrote:
> Hi Vladimir,
>
>
> On 02/25/2016 06:21 PM, Vladimir Kozlov wrote:
>> I am fine with removal of adler32 and bmi testing from JPRT runs
>> because we don't have a plan to touch them.
>> But code related to CRC32, CRC32c and string may be touched soon for
>> some platforms.
>
> OK, so I've re-enabled testing of the CRC23, CRC32c and string
> intrinsics (still within the hotspot_compiler_3 group). Running the
> group still takes < 30 minutes on our slowest platforms, here are the
> execution times:
>
> West:
>   linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(25m 12s)
>   solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(11m 46s)
>
> Stockholm:
>    linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3     success(24m 18s)
>    solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(21m 01s)
>
> Here is the updated webrev:
> http://cr.openjdk.java.net/~zmajo/8150349/webrev.01/
>
>> What if we created hotspot_compiler_4 group for them? How much time it
>> would take to run it on slow platforms?
>
> I think it's fine to leave all tests in hotspot_compiler_3 as all
> execution times are still below 30 minutes.
>
> I filed INTJDK-7622854: "Track the execution time of JPRT tests groups"
> so that we can better track the execution times of the
> hotspot_compiler_[1-3] test groups.
>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>
>>
>> Thanks,
>> Vladimir
>>
>> On 2/25/16 8:12 AM, Zolt?n Maj? wrote:
>>> Hi Nils,
>>>
>>>
>>> thank you for the feedback!
>>>
>>> On 02/25/2016 04:22 PM, Nils Eliasson wrote:
>>>> Hi Zoltan,
>>>>
>>>> Have you opened a bug for fixing the tests?
>>>
>>> No, I have not, because there is an existing issue (INTJDK-7620326)
>>> that is supposed to take care of the high execution
>>> time of intrinsic-related tests on platforms where the relevant
>>> intrinsics are not available. I've linked the two issues.
>>>
>>>>
>>>> Do we really want to remove the String intrinsics from the list?
>>>> aren't they pretty new?
>>>
>>> You are right, they are in part new (in part old intrinsics have been
>>> updated). I thought to remove them nevertheless,
>>> because they take a long time to execute and are anyway executed in
>>> our nightlies.
>>>
>>> Best regards,
>>>
>>>
>>> Zoltan
>>>
>>>>
>>>> Thanks for fixing this,
>>>> Nils Eliasson
>>>>
>>>> On 2016-02-25 15:17, Zolt?n Maj? wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> please review the patch for 8150349.
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8150349
>>>>>
>>>>> Problem: The hotspot_compiler_3 group of tests takes more than 30
>>>>> minutes on our slowest platforms.
>>>>>
>>>>>
>>>>> Solution: Remove a number of long-running tests from the
>>>>> hotspot_compiler_3 group. All removed tests are related to
>>>>> intrinsics, that is, they check the functionality of a reduced set
>>>>> of the VM's functionality that is not often
>>>>> modified. Also, we execute all removed tests daily (in our nightly
>>>>> testing).
>>>>>
>>>>> Here is the time spent in hotspot_compiler_3 on our slowest
>>>>> platforms after removing the tests:
>>>>>
>>>>> West:
>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 22s)
>>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=6
>>>>> parallelcount=6 ram=31744MB cpufreqmhz=2848
>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(19m 09s)
>>>>>     platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12
>>>>> parallelcount=12 ram=60690MB cpufreqmhz=2294
>>>>>
>>>>> Stockholm:
>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 32s)
>>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=12
>>>>> parallelcount=12 ram=24576MB    cpufreqmhz=2848
>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(20m 24s)
>>>>>     platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8
>>>>> parallelcount=8 ram=16061MB
>>>>>
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/
>>>>>
>>>>> Thank you!
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>> Zoltan
>>>>>
>>>>
>>>
>

From christian.thalinger at oracle.com  Fri Feb 26 18:29:22 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 26 Feb 2016 08:29:22 -1000
Subject: RFR(XS): 8140721: ProfilerNumberOf*Methods flags should be
	diagnostic
In-Reply-To: 
References: 
Message-ID: 

Looks good.

> On Feb 26, 2016, at 1:45 AM, Rahul Raghavan  wrote:
> 
> Hi,
> 
> Please review the following patch for JDK-8140721.
> 
> - Bug: https://bugs.openjdk.java.net/browse/JDK-8140721
> - Webrev: http://cr.openjdk.java.net/~rraghavan/8140721/webrev.00/
> 
> - Changed following four flags from 'develop' to 'diagnostic' -
>    [ProfilerNumberOfInterpretedMethods, ProfilerNumberOfCompiledMethods, ProfilerNumberOfStubMethods, ProfilerNumberOfRuntimeStubNodes]
> 
> - No issues with JPRT (-testset hotspot).
> - Confirmed no issues, expected behavior with the change for small unit tests.
>  (for debug/release VM with combinations of the flags, UnlockDiagnosticVMOptions usages)
> - Found no existing tests using the flags to be changed.
> 
> Thanks,
> Rahul


From vladimir.x.ivanov at oracle.com  Fri Feb 26 18:31:01 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 26 Feb 2016 21:31:01 +0300
Subject: [9] RFR (M): 8068038: C2: large constant offsets aren't handled
	on SPARC
In-Reply-To: <56D09623.9090003@oracle.com>
References: <56CF7B9B.5000007@oracle.com> <56CF9452.7050606@oracle.com>
	<56D031D7.9070506@oracle.com> <56D09623.9090003@oracle.com>
Message-ID: <56D099E5.6060106@oracle.com>

Thanks, Vladimir.

Best regards,
Vladimir Ivanov

On 2/26/16 9:14 PM, Vladimir Kozlov wrote:
> Good.
>
> Thanks,
> Vladimir
>
> On 2/26/16 3:07 AM, Vladimir Ivanov wrote:
>> Thanks, Vladimir.
>>
>>>> http://cr.openjdk.java.net/~vlivanov/8068038/webrev.00
>>>
>>> Looks fine but leave 32-bit removal to JDK-8150388.
>> No problem, updated webrev in place.
>>
>>>> PS: there's an additional cleanup [1] in sparc.ad (mostly 32-bit SPARC
>>>> removal, but also added some comments). It can go along with this
>>>> fix or
>>>> as part of the 32-bit SPARC complete removal (JDK-8150388). Let me know
>>>> what do you prefer.
>>>
>>> Should be part of JDK-8150388 changes.
>> Sure. Updated JDK-8150388 with the link to the webrev.
>>
>> Best regards,
>> Vladimir Ivanov

From christian.thalinger at oracle.com  Fri Feb 26 18:32:48 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 26 Feb 2016 08:32:48 -1000
Subject: RFR(XS): 8150727: [JVMCI] add LoadLoad to the implicit memory
	barriers on AMD64
In-Reply-To: <56D06572.7060406@oracle.com>
References: <56D06572.7060406@oracle.com>
Message-ID: 

I?m assuming this doesn?t change the generated code at all.  Does it reduce the number of nodes in compiler graphs?

> On Feb 26, 2016, at 4:47 AM, Roland Schatz  wrote:
> 
> Hi,
> 
> Please review and integrate this small fix:
> http://cr.openjdk.java.net/~rschatz/JDK-8150727/webrev.00/ 
> https://bugs.openjdk.java.net/browse/JDK-8150727 
> 
> It was contributed by Benoit Daloze (cc'ed), and lgtm (but I'm not a reviewer myself).
> 
> Thanks,
> Roland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From christian.thalinger at oracle.com  Fri Feb 26 18:38:24 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 26 Feb 2016 08:38:24 -1000
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
In-Reply-To: <56D0587E.4010602@oracle.com>
References: <56CF0D09.1080508@oracle.com> <56CF1C18.3080808@oracle.com>
	<56CF280A.1010705@oracle.com> <56CF37FC.1080906@oracle.com>
	<56D0587E.4010602@oracle.com>
Message-ID: 


> On Feb 26, 2016, at 3:51 AM, Nils Eliasson  wrote:
> 
> Hi Vladimir,
> 
> On 2016-02-25 18:21, Vladimir Kozlov wrote:
>> I am fine with removal of adler32 and bmi testing from JPRT runs because we don't have a plan to touch them.
>> But code related to CRC32, CRC32c and string may be touched soon for some platforms.
>> What if we created hotspot_compiler_4 group for them? How much time it would take to run it on slow platforms?
> I don't think the other teams will be happy if we add yet another batch to JPRT.

Why do you think that?  More parallelism is usually better.

> We can speed up some of these time consuming tests a lot.
> 
> Regards,
> Nils Eliasson
> 
>> 
>> Thanks,
>> Vladimir
>> 
>> On 2/25/16 8:12 AM, Zolt?n Maj? wrote:
>>> Hi Nils,
>>> 
>>> 
>>> thank you for the feedback!
>>> 
>>> On 02/25/2016 04:22 PM, Nils Eliasson wrote:
>>>> Hi Zoltan,
>>>> 
>>>> Have you opened a bug for fixing the tests?
>>> 
>>> No, I have not, because there is an existing issue (INTJDK-7620326) that is supposed to take care of the high execution
>>> time of intrinsic-related tests on platforms where the relevant intrinsics are not available. I've linked the two issues.
>>> 
>>>> 
>>>> Do we really want to remove the String intrinsics from the list? aren't they pretty new?
>>> 
>>> You are right, they are in part new (in part old intrinsics have been updated). I thought to remove them nevertheless,
>>> because they take a long time to execute and are anyway executed in our nightlies.
>>> 
>>> Best regards,
>>> 
>>> 
>>> Zoltan
>>> 
>>>> 
>>>> Thanks for fixing this,
>>>> Nils Eliasson
>>>> 
>>>> On 2016-02-25 15:17, Zolt?n Maj? wrote:
>>>>> Hi,
>>>>> 
>>>>> 
>>>>> please review the patch for 8150349.
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8150349
>>>>> 
>>>>> Problem: The hotspot_compiler_3 group of tests takes more than 30 minutes on our slowest platforms.
>>>>> 
>>>>> 
>>>>> Solution: Remove a number of long-running tests from the hotspot_compiler_3 group. All removed tests are related to
>>>>> intrinsics, that is, they check the functionality of a reduced set of the VM's functionality that is not often
>>>>> modified. Also, we execute all removed tests daily (in our nightly testing).
>>>>> 
>>>>> Here is the time spent in hotspot_compiler_3 on our slowest platforms after removing the tests:
>>>>> 
>>>>> West:
>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 22s)
>>>>>    platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=6 parallelcount=6 ram=31744MB cpufreqmhz=2848
>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(19m 09s)
>>>>>    platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12 parallelcount=12 ram=60690MB cpufreqmhz=2294
>>>>> 
>>>>> Stockholm:
>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 32s)
>>>>>    platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=12 parallelcount=12 ram=24576MB    cpufreqmhz=2848
>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(20m 24s)
>>>>>    platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8 parallelcount=8 ram=16061MB
>>>>> 
>>>>> 
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> 
>>>>> Zoltan
>>>>> 
>>>> 
>>> 
> 


From volker.simonis at gmail.com  Fri Feb 26 18:47:21 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 26 Feb 2016 19:47:21 +0100
Subject: RFR(S/M): 8150646: Add support for blocking compiles through
	whitebox API
In-Reply-To: <56D00EAB.1010009@oracle.com>
References: <56CF175E.1030806@oracle.com> <56CF6E9D.8060507@oracle.com>
	<56D00EAB.1010009@oracle.com>
Message-ID: 

Hi,

so I want to propose the following solution for this problem:

http://cr.openjdk.java.net/~simonis/webrevs/2016/8150646_toplevel
http://cr.openjdk.java.net/~simonis/webrevs/2016/8150646_hotspot/

I've started from the opposite site and made the BackgroundCompilation
manageable through the compiler directives framework. Once this works
(and it's actually trivial due to the nice design of the
CompilerDirectives framework :), we get the possibility to set the
BackgroundCompilation option on a per method base on the command line
via the CompileCommand option for free:

-XX:CompileCommand="option,java.lang.String::charAt,bool,BackgroundCompilation,false"

And of course we can also use it directly as a compiler directive:

[{ match: "java.lang.String::charAt", BackgroundCompilation: false }]

It also becomes possible to use this directly from the Whitebox API
through the DiagnosticCommand.compilerDirectivesAdd command.
Unfortunately, this command takes a file with compiler directives as
argument. I think this would be overkill in this context. So because
it was so easy and convenient, I added the following two new Whitebox
methods:

  public native void addCompilerDirective(String compDirect);
  public native void removeCompilerDirective();

which can now be used to set arbitrary CompilerDirective command
directly from within the WhiteBox API. (The implementation of these
two methods is trivial as you can see in whitebox.cpp).

The blocking versions of enqueueMethodForCompilation() now become
simple wrappers around the existing methods without the need of any
code changes in their native implementation. This is good, because it
keeps the WhiteBox API stable!

Finally some words about the implementation of the per-method
BackgroundCompilation functionality. It actually only requires two
small changes:

1. extending CompileBroker::is_compile_blocking() to take the method
and compilation level as arguments and use them to query the
DirectivesStack for the corresponding BackgroundCompilation value.

2. changing AdvancedThresholdPolicy::select_task() such that it
prefers blocking compilations. This is not only necessary, because it
decreases the time we have to wait for a blocking compilation, but
also because it prevents blocking compiles from getting stale. This
could otherwise easily happen in AdvancedThresholdPolicy::is_stale()
for methods which only get artificially compiled during a test because
their invocations counters are usually too small.

There's still a small probability that a blocking compilation will be
not blocking. This can happen if a method for which we request the
blocking compilation is already in the compilation queue (see the
check 'compilation_is_in_queue(method)' in
CompileBroker::compile_method_base()). In testing scenarios this will
rarely happen because methods which are manually compiled shouldn't
get called that many times to implicitly place them into the compile
queue. But we can even completely avoid this problem by using
WB.isMethodQueuedForCompilation() to make sure that a method is not in
the queue before we request a blocking compilation.

I've also added a small regression test to demonstrate and verify the
new functionality.

Regards,
Volker




On Fri, Feb 26, 2016 at 9:36 AM, Nils Eliasson  wrote:
> Hi Vladimir,
>
> WhiteBox::compilation_locked is a global state that temporarily stops all
> compilations. I this case I just want to achieve blocking compilation for a
> single compile without affecting the rest of the system. The tests using it
> will continue executing as soon as that compile is finished, saving time
> where wait-loops is used today. It adds nice determinism to tests.
>
> Best regards,
> Nils Eliasson
>
>
> On 2016-02-25 22:14, Vladimir Kozlov wrote:
>>
>> You are adding parameter which is used only for testing.
>> Can we have callback(or check field) into WB instead? Similar to
>> WhiteBox::compilation_locked.
>>
>> Thanks,
>> Vladimir
>>
>> On 2/25/16 7:01 AM, Nils Eliasson wrote:
>>>
>>> Hi,
>>>
>>> Please review this change that adds support for blocking compiles in the
>>> whitebox API. This enables simpler less time consuming tests.
>>>
>>> Motivation:
>>> * -XX:-BackgroundCompilation is a global flag and can be time consuming
>>> * Blocking compiles removes the need for waiting on the compile queue to
>>> complete
>>> * Compiles put in the queue may be evicted if the queue grows to big -
>>> causing indeterminism in the test
>>> * Less VM-flags allows for more tests in the same VM
>>>
>>> Testing:
>>> Posting a separate RFR for test fix that uses this change. They will be
>>> pushed at the same time.
>>>
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8150646
>>> JDK rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev_jdk.01/
>>> Hotspot rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev.02/
>>>
>>> Best regards,
>>> Nils Eliasson
>
>

From christian.thalinger at oracle.com  Fri Feb 26 19:11:18 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 26 Feb 2016 09:11:18 -1000
Subject: RFR: 8150738: [JVMCI] runtime/CommandLine/TraceExceptionsTest.java
	fails with: java.lang.RuntimeException: '' missing from
	stdout/stderr
Message-ID: <32FC884E-1F2B-4CA4-9CE4-E9370E65BB23@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8150738

JDK-8144953 missed changing the exception logging code in JVMCI.

diff -r 1e4d74c1b3d0 src/share/vm/jvmci/jvmciRuntime.cpp
--- a/src/share/vm/jvmci/jvmciRuntime.cpp	Wed Feb 24 09:22:45 2016 -0800
+++ b/src/share/vm/jvmci/jvmciRuntime.cpp	Fri Feb 26 09:08:28 2016 -1000
@@ -293,13 +293,11 @@ JRT_ENTRY_NO_ASYNC(static address, excep
     // tracing
     if (log_is_enabled(Info, exceptions)) {
       ResourceMark rm;
-      log_info(exceptions)("Exception <%s> (" INTPTR_FORMAT ") thrown in"
-                           " compiled method <%s> at PC " INTPTR_FORMAT
-                           " for thread " INTPTR_FORMAT,
-                           exception->print_value_string(),
-                           p2i((address)exception()),
-                           nm->method()->print_value_string(), p2i(pc),
-                           p2i(thread));
+      stringStream tempst;
+      tempst.print("compiled method <%s>\n"
+                   " at PC" INTPTR_FORMAT " for thread " INTPTR_FORMAT,
+                   nm->method()->print_value_string(), p2i(pc), p2i(thread));
+      Exceptions::log_exception(exception, tempst);
     }
     // for AbortVMOnException flag
     NOT_PRODUCT(Exceptions::debug_check_abort(exception));


From aleksey.shipilev at oracle.com  Fri Feb 26 19:14:26 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 26 Feb 2016 22:14:26 +0300
Subject: [9] RFR (XS): 8150543: Mismatched access detection is inaccurate
In-Reply-To: <56D04A35.2090801@oracle.com>
References: <56D044D9.5030805@oracle.com> <56D047EF.9040307@oracle.com>
	<56D04A35.2090801@oracle.com>
Message-ID: <56D0A412.7020203@oracle.com>

On 02/26/2016 03:51 PM, Vladimir Ivanov wrote:
>>> Also, marked the tests as not applicable to C1, since it doesn't
>>> constant fold unsafe accesses.
>>
>> Okay, but does it hurt to run those tests with C1? My concern is that we
>> might forget to enable those tests back once/if C1 learns to constant
>> fold unsafe accesses.
> It requires additional logic in the tests: both to encode expected
> results for different configurations and detect what compiler is in use.

Oh, okay then!

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From tom.rodriguez at oracle.com  Fri Feb 26 19:24:18 2016
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 26 Feb 2016 11:24:18 -0800
Subject: RFR(XS): 8150727: [JVMCI] add LoadLoad to the implicit memory
	barriers on AMD64
In-Reply-To: 
References: <56D06572.7060406@oracle.com>
	
Message-ID: <7FCD252E-CFF1-4D33-A4D3-39950FABED4B@oracle.com>

It shouldn?t.  A MembarNode is still built since we have to order the memory operations.  The implicit barriers stuff just means we don?t need extra instructions to ensure the ordering beyond issuing them in the right order.

tom

> On Feb 26, 2016, at 10:32 AM, Christian Thalinger  wrote:
> 
> I?m assuming this doesn?t change the generated code at all.  Does it reduce the number of nodes in compiler graphs?
> 
>> On Feb 26, 2016, at 4:47 AM, Roland Schatz > wrote:
>> 
>> Hi,
>> 
>> Please review and integrate this small fix:
>> http://cr.openjdk.java.net/~rschatz/JDK-8150727/webrev.00/ 
>> https://bugs.openjdk.java.net/browse/JDK-8150727 
>> 
>> It was contributed by Benoit Daloze (cc'ed), and lgtm (but I'm not a reviewer myself).
>> 
>> Thanks,
>> Roland
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From christian.thalinger at oracle.com  Fri Feb 26 19:27:41 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 26 Feb 2016 09:27:41 -1000
Subject: [9] RFR (M): 8143407: C1: @Stable array support
In-Reply-To: <56D06FD3.4080306@oracle.com>
References: <56C7602B.3090300@oracle.com> <56D06FD3.4080306@oracle.com>
Message-ID: <84572150-41B0-4D99-A296-F2528A768DB4@oracle.com>

          // Stable static fields are checked for non-default values in ciField::initialize_from().
+         assert(!field->is_stable() || !field_value.is_null_or_zero(), "should not be a constant");

I don?t understand this assert.  Especially the message text.

+   switch (field_type) {
+     case T_ARRAY:
+     case T_OBJECT:
+       if (field_value.as_object()->should_be_constant()) {
+         return new Constant(value);
+       }
+       break;
+     default:
+      return new Constant(value);
+   }
+   return NULL; // Not a constant.

Could you move the return NULL up to where the break is?  Would make it easier to read.

+            if (FoldStableValues && field->is_stable() && field_value.is_null_or_zero()) {
               // Stable field with default value can't be constant.
-              constant = NULL;

I understand that the null assignment is not needed but it would be nice to keep it.

Otherwise the logic seems to be fine.  I couldn?t spot any obvious mistakes.

> On Feb 26, 2016, at 5:31 AM, Vladimir Ivanov  wrote:
> 
> Any reviews, please?
> 
> Best regards,
> Vladimir Ivanov
> 
> On 2/19/16 9:34 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8143407/webrev.01
>> https://bugs.openjdk.java.net/browse/JDK-8143407
>> 
>> Add C1 support for constant folding loads from @Stable arrays.
>> It aligns C1 & C2 behavior w.r.t. @Stable fields and was requested for
>> VarHandles [1] implementation.
>> 
>> I introduced StableArrayConstant to track stable array dimension.
>> 
>> It is needed to disambiguate the following cases:
>>  (1) @Stable int[][][] intArr = new int[...][...][...];
>>  (2) @Stable  Object[] objArr = new int[...][...][...];
>> 
>> In the first case, all elements of multi-dimensional array w/
>> non-default values are considered constant.
>> 
>> In the latter, only elements of objArray (which are int[][] instances).
>> 
>> Testing: unit tests on @Stable support, JPRT.
>> 
>> Thanks!
>> 
>> Best regards,
>> Vladimir Ivanov
>> 
>> [1] http://openjdk.java.net/jeps/193


From christian.thalinger at oracle.com  Fri Feb 26 19:30:08 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 26 Feb 2016 09:30:08 -1000
Subject: RFR(XS): 8150727: [JVMCI] add LoadLoad to the implicit memory
	barriers on AMD64
In-Reply-To: <7FCD252E-CFF1-4D33-A4D3-39950FABED4B@oracle.com>
References: <56D06572.7060406@oracle.com>
	
	<7FCD252E-CFF1-4D33-A4D3-39950FABED4B@oracle.com>
Message-ID: 


> On Feb 26, 2016, at 9:24 AM, Tom Rodriguez  wrote:
> 
> It shouldn?t.  A MembarNode is still built since we have to order the memory operations.  The implicit barriers stuff just means we don?t need extra instructions to ensure the ordering beyond issuing them in the right order.

Right, it?s used in the LIRGenerator:

com.oracle.graal.lir.gen.LIRGeneratorTool.emitMembar(int)

Looks good.

> 
> tom
> 
>> On Feb 26, 2016, at 10:32 AM, Christian Thalinger > wrote:
>> 
>> I?m assuming this doesn?t change the generated code at all.  Does it reduce the number of nodes in compiler graphs?
>> 
>>> On Feb 26, 2016, at 4:47 AM, Roland Schatz > wrote:
>>> 
>>> Hi,
>>> 
>>> Please review and integrate this small fix:
>>> http://cr.openjdk.java.net/~rschatz/JDK-8150727/webrev.00/ 
>>> https://bugs.openjdk.java.net/browse/JDK-8150727 
>>> 
>>> It was contributed by Benoit Daloze (cc'ed), and lgtm (but I'm not a reviewer myself).
>>> 
>>> Thanks,
>>> Roland
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rahul.v.raghavan at oracle.com  Fri Feb 26 19:36:42 2016
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Fri, 26 Feb 2016 11:36:42 -0800 (PST)
Subject: RFR(XS): 8140721: ProfilerNumberOf*Methods flags should be
	diagnostic
In-Reply-To: 
References: 
	
Message-ID: 

> -----Original Message-----
> From: Christian Thalinger > Sent: Friday, February 26, 2016 11:59 PM > To: Rahul Raghavan > Cc: hotspot-compiler-dev at openjdk.java.net
> 
> Looks good.

Thank you Chris.

> 
> > On Feb 26, 2016, at 1:45 AM, Rahul Raghavan  wrote:
> >
> > Hi,
> >
> > Please review the following patch for JDK-8140721.
> >
> > - Bug: https://bugs.openjdk.java.net/browse/JDK-8140721
> > - Webrev: http://cr.openjdk.java.net/~rraghavan/8140721/webrev.00/
> >
> > - Changed following four flags from 'develop' to 'diagnostic' -
> >    [ProfilerNumberOfInterpretedMethods, ProfilerNumberOfCompiledMethods, ProfilerNumberOfStubMethods,
> ProfilerNumberOfRuntimeStubNodes]
> >
> > - No issues with JPRT (-testset hotspot).
> > - Confirmed no issues, expected behavior with the change for small unit tests.
> >  (for debug/release VM with combinations of the flags, UnlockDiagnosticVMOptions usages)
> > - Found no existing tests using the flags to be changed.
> >
> > Thanks,
> > Rahul
> 

From coleen.phillimore at oracle.com  Fri Feb 26 20:09:41 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 26 Feb 2016 15:09:41 -0500
Subject: RFR: 8150738: [JVMCI]
	runtime/CommandLine/TraceExceptionsTest.java fails with:
	java.lang.RuntimeException: '' missing from stdout/stderr
In-Reply-To: <32FC884E-1F2B-4CA4-9CE4-E9370E65BB23@oracle.com>
References: <32FC884E-1F2B-4CA4-9CE4-E9370E65BB23@oracle.com>
Message-ID: <56D0B105.2040703@oracle.com>

Looks good!
Coleen

On 2/26/16 2:11 PM, Christian Thalinger wrote:
> https://bugs.openjdk.java.net/browse/JDK-8150738
>
> JDK-8144953 missed changing the exception logging code in JVMCI.
>
> diff -r 1e4d74c1b3d0 src/share/vm/jvmci/jvmciRuntime.cpp
> --- a/src/share/vm/jvmci/jvmciRuntime.cpp	Wed Feb 24 09:22:45 2016 -0800
> +++ b/src/share/vm/jvmci/jvmciRuntime.cpp	Fri Feb 26 09:08:28 2016 -1000
> @@ -293,13 +293,11 @@ JRT_ENTRY_NO_ASYNC(static address, excep
>       // tracing
>       if (log_is_enabled(Info, exceptions)) {
>         ResourceMark rm;
> -      log_info(exceptions)("Exception <%s> (" INTPTR_FORMAT ") thrown in"
> -                           " compiled method <%s> at PC " INTPTR_FORMAT
> -                           " for thread " INTPTR_FORMAT,
> -                           exception->print_value_string(),
> -                           p2i((address)exception()),
> -                           nm->method()->print_value_string(), p2i(pc),
> -                           p2i(thread));
> +      stringStream tempst;
> +      tempst.print("compiled method <%s>\n"
> +                   " at PC" INTPTR_FORMAT " for thread " INTPTR_FORMAT,
> +                   nm->method()->print_value_string(), p2i(pc), p2i(thread));
> +      Exceptions::log_exception(exception, tempst);
>       }
>       // for AbortVMOnException flag
>       NOT_PRODUCT(Exceptions::debug_check_abort(exception));
>


From vladimir.x.ivanov at oracle.com  Fri Feb 26 21:05:27 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Sat, 27 Feb 2016 00:05:27 +0300
Subject: [9] RFR (M): 8143407: C1: @Stable array support
In-Reply-To: <84572150-41B0-4D99-A296-F2528A768DB4@oracle.com>
References: <56C7602B.3090300@oracle.com> <56D06FD3.4080306@oracle.com>
	<84572150-41B0-4D99-A296-F2528A768DB4@oracle.com>
Message-ID: <56D0BE17.7020104@oracle.com>

Thanks for the feedback, Chris.

Updated webrev in place:
   http://cr.openjdk.java.net/~vlivanov/8143407/webrev.01
On 2/26/16 10:27 PM, Christian Thalinger wrote:
>            // Stable static fields are checked for non-default values in ciField::initialize_from().
> +         assert(!field->is_stable() || !field_value.is_null_or_zero(), "should not be a constant");
>
> I don?t understand this assert.  Especially the message text.
It checks an invariant between ciField::is_constant/constant_value & 
ciField::is_stable(). For static fields constant folding happens when 
ciField instance is constructed, so the assert ensures that for a stable 
static field its default value is never seen as a constant.

I slightly reworded the assert message. Hope it reads better now:
+         assert(!field->is_stable() || !field_value.is_null_or_zero(),
+                "stable static w/ default value should not be a constant");
+

> +   switch (field_type) {
> +     case T_ARRAY:
> +     case T_OBJECT:
> +       if (field_value.as_object()->should_be_constant()) {
> +         return new Constant(value);
> +       }
> +       break;
> +     default:
> +      return new Constant(value);
> +   }
> +   return NULL; // Not a constant.
>
> Could you move the return NULL up to where the break is?  Would make it easier to read.
Ok.

> +            if (FoldStableValues && field->is_stable() && field_value.is_null_or_zero()) {
>                 // Stable field with default value can't be constant.
> -              constant = NULL;
>
> I understand that the null assignment is not needed but it would be nice to keep it.
Ok.

Best regards,
Vladimir Ivanov

From christian.thalinger at oracle.com  Fri Feb 26 21:07:19 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 26 Feb 2016 11:07:19 -1000
Subject: RFR: 8150738: [JVMCI]
	runtime/CommandLine/TraceExceptionsTest.java fails with:
	java.lang.RuntimeException: '' missing from
	stdout/stderr
In-Reply-To: <56D0B105.2040703@oracle.com>
References: <32FC884E-1F2B-4CA4-9CE4-E9370E65BB23@oracle.com>
	<56D0B105.2040703@oracle.com>
Message-ID: <23B7E427-BA81-43A3-A1BE-99260F2EEF00@oracle.com>

Thanks, Coleen.

> On Feb 26, 2016, at 10:09 AM, Coleen Phillimore  wrote:
> 
> Looks good!
> Coleen
> 
> On 2/26/16 2:11 PM, Christian Thalinger wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8150738
>> 
>> JDK-8144953 missed changing the exception logging code in JVMCI.
>> 
>> diff -r 1e4d74c1b3d0 src/share/vm/jvmci/jvmciRuntime.cpp
>> --- a/src/share/vm/jvmci/jvmciRuntime.cpp	Wed Feb 24 09:22:45 2016 -0800
>> +++ b/src/share/vm/jvmci/jvmciRuntime.cpp	Fri Feb 26 09:08:28 2016 -1000
>> @@ -293,13 +293,11 @@ JRT_ENTRY_NO_ASYNC(static address, excep
>>      // tracing
>>      if (log_is_enabled(Info, exceptions)) {
>>        ResourceMark rm;
>> -      log_info(exceptions)("Exception <%s> (" INTPTR_FORMAT ") thrown in"
>> -                           " compiled method <%s> at PC " INTPTR_FORMAT
>> -                           " for thread " INTPTR_FORMAT,
>> -                           exception->print_value_string(),
>> -                           p2i((address)exception()),
>> -                           nm->method()->print_value_string(), p2i(pc),
>> -                           p2i(thread));
>> +      stringStream tempst;
>> +      tempst.print("compiled method <%s>\n"
>> +                   " at PC" INTPTR_FORMAT " for thread " INTPTR_FORMAT,
>> +                   nm->method()->print_value_string(), p2i(pc), p2i(thread));
>> +      Exceptions::log_exception(exception, tempst);
>>      }
>>      // for AbortVMOnException flag
>>      NOT_PRODUCT(Exceptions::debug_check_abort(exception));
>> 
> 


From christian.thalinger at oracle.com  Fri Feb 26 21:12:13 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 26 Feb 2016 11:12:13 -1000
Subject: [9] RFR (M): 8143407: C1: @Stable array support
In-Reply-To: <56D0BE17.7020104@oracle.com>
References: <56C7602B.3090300@oracle.com> <56D06FD3.4080306@oracle.com>
	<84572150-41B0-4D99-A296-F2528A768DB4@oracle.com>
	<56D0BE17.7020104@oracle.com>
Message-ID: <7FEA138A-F1FA-495E-BA1D-410E17B006D7@oracle.com>


> On Feb 26, 2016, at 11:05 AM, Vladimir Ivanov  wrote:
> 
> Thanks for the feedback, Chris.
> 
> Updated webrev in place:
>  http://cr.openjdk.java.net/~vlivanov/8143407/webrev.01
> On 2/26/16 10:27 PM, Christian Thalinger wrote:
>>           // Stable static fields are checked for non-default values in ciField::initialize_from().
>> +         assert(!field->is_stable() || !field_value.is_null_or_zero(), "should not be a constant");
>> 
>> I don?t understand this assert.  Especially the message text.
> It checks an invariant between ciField::is_constant/constant_value & ciField::is_stable(). For static fields constant folding happens when ciField instance is constructed, so the assert ensures that for a stable static field its default value is never seen as a constant.
> 
> I slightly reworded the assert message. Hope it reads better now:
> +         assert(!field->is_stable() || !field_value.is_null_or_zero(),
> +                "stable static w/ default value should not be a constant?);

Better, thanks.  Are we saving bytes in assert messages now? ;-)

> +
> 
>> +   switch (field_type) {
>> +     case T_ARRAY:
>> +     case T_OBJECT:
>> +       if (field_value.as_object()->should_be_constant()) {
>> +         return new Constant(value);
>> +       }
>> +       break;
>> +     default:
>> +      return new Constant(value);

Just noticed the indent is wrong on this line.

>> +   }
>> +   return NULL; // Not a constant.
>> 
>> Could you move the return NULL up to where the break is?  Would make it easier to read.
> Ok.
> 
>> +            if (FoldStableValues && field->is_stable() && field_value.is_null_or_zero()) {
>>                // Stable field with default value can't be constant.
>> -              constant = NULL;
>> 
>> I understand that the null assignment is not needed but it would be nice to keep it.
> Ok.
> 
> Best regards,
> Vladimir Ivanov


From dean.long at oracle.com  Fri Feb 26 22:01:27 2016
From: dean.long at oracle.com (Dean Long)
Date: Fri, 26 Feb 2016 14:01:27 -0800
Subject: [9] RFR (M): 8068038: C2: large constant offsets aren't handled
	on SPARC
In-Reply-To: <56D031D7.9070506@oracle.com>
References: <56CF7B9B.5000007@oracle.com> <56CF9452.7050606@oracle.com>
	<56D031D7.9070506@oracle.com>
Message-ID: <56D0CB37.1040400@oracle.com>

These changes look good.

dl

On 2/26/2016 3:07 AM, Vladimir Ivanov wrote:
> Thanks, Vladimir.
>
>>> http://cr.openjdk.java.net/~vlivanov/8068038/webrev.00
>>
>> Looks fine but leave 32-bit removal to JDK-8150388.
> No problem, updated webrev in place.
>
>>> PS: there's an additional cleanup [1] in sparc.ad (mostly 32-bit SPARC
>>> removal, but also added some comments). It can go along with this 
>>> fix or
>>> as part of the 32-bit SPARC complete removal (JDK-8150388). Let me know
>>> what do you prefer.
>>
>> Should be part of JDK-8150388 changes.
> Sure. Updated JDK-8150388 with the link to the webrev.
>
> Best regards,
> Vladimir Ivanov


From claes.redestad at oracle.com  Fri Feb 26 23:19:06 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 27 Feb 2016 00:19:06 +0100
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D091C5.1050903@oracle.com>
References: <56D039AB.5050605@oracle.com> <56D091C5.1050903@oracle.com>
Message-ID: <56D0DD6A.6070202@oracle.com>

Hi,

On 2016-02-26 18:56, Vladimir Kozlov wrote:
> Good changes. We indeed print statistics only in non-product build.

Thanks!

>
> graphKit.cpp - add {} to code:
>
> +#ifndef PRODUCT
>      if (null_true == top())
>        explicit_null_checks_elided++;
> +#endif
>
> ifnode.cpp - add {} and adjust spaces "if (dist > 2) {":
>
> +#ifndef PRODUCT
>    if( dist > 2 )              // Add to count of NULL checks elided
>      explicit_null_checks_elided++;
> +#endif
>
> parse1.cpp - the same:
>
> -  if( implicit_null_throws )
> +  if( SharedRuntime::_implicit_null_throws )
>      tty->print_cr("%d implicit null exceptions at runtime",
> -                  implicit_null_throws);
> +                  SharedRuntime::_implicit_null_throws);

Sure! Mind if I clean up nearby to keep things consistent?

http://cr.openjdk.java.net/~redestad/8150720/webrev.01/

>
>
> > There is also a small "leak" in the corner case where "edge_end ==
> > (char*)this" since we're not freeing the input array in this case.
>
> There is no "leak" since after compilation is done all C2 arenas are 
> cleaned/freed. Yes, during compilation required space could be increased.
>
> > We are not freeing when ASSERT is not defined? O_o The patch that
> > apparently does an equivalent transformation of the original code 
> makes it even creepier.
>
> It is done to catch dangling Node* pointers in debug build:
>
>  661 #ifdef ASSERT
>  662   // We will not actually delete the storage, but we'll make the 
> node unusable.
>  663   *(address*)this = badAddress;  // smash the C++ vtbl, probably
>  664   _in = _out = (Node**) badAddress;
>
> So please revert that code back except the code which just increment 
> unused counters and can be indeed removed.

Thanks for clarifying and explaining this!

I do think the code in node.cpp is correctly transformed to do the same 
thing apart from the counters and does not need to be reverted though?

Thanks!

/Claes

>
> Thanks,
> Vladimir
>
> On 2/26/16 3:40 AM, Claes Redestad wrote:
>> Hi,
>>
>> src/share/vm/opto/parse1.cpp currently defines a number of global
>> counters that is used to collect some statistics. Some of these counters
>> are incremented in product builds, but ever only displayed in
>> non-product builds if run with -XX:+PrintOptoStatistics.
>>
>> This patch masks such counters from product builds, removes a few
>> counters that were never read, fixes an issue with implicit_null_throws
>> which was never incremented in current code (seems it was moved to
>> SharedRuntime a long time ago without updating print_statistics) and
>> removes an unused enum (InlineStyle):
>>
>> webrev: http://cr.openjdk.java.net/~redestad/8150720/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8150720
>>
>> Testing: RBT --test hotspot/test/:hotspot_all, manual verification that
>> -XX:+PrintOptoStatistics prints out a count for implicit NPE's thrown
>>
>> Thanks!
>>
>> /Claes


From vivek.r.deshpande at intel.com  Sat Feb 27 00:37:56 2016
From: vivek.r.deshpande at intel.com (Deshpande, Vivek R)
Date: Sat, 27 Feb 2016 00:37:56 +0000
Subject: RFR (M): 8150767: Update for x86 SHA Extensions enabling
Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A36FCA@ORSMSX106.amr.corp.intel.com>

Hi all

I would like to contribute a patch which optimizes SHA-1 and SHA-256 for 64 and 32 bit X86 architecture using Intel SHA extensions.
Could you please review and sponsor this patch.

Bug-id:
https://bugs.openjdk.java.net/browse/JDK-8150767
webrev:
 http://cr.openjdk.java.net/~vdeshpande/SHANI/8150767/webrev.00/


Thanks and regards,
Vivek

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vladimir.kozlov at oracle.com  Sat Feb 27 02:15:51 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 26 Feb 2016 18:15:51 -0800
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D0DD6A.6070202@oracle.com>
References: <56D039AB.5050605@oracle.com> <56D091C5.1050903@oracle.com>
	<56D0DD6A.6070202@oracle.com>
Message-ID: <56D106D7.6030205@oracle.com>

Clearing nearby code is good. You missed {} in ifnode.cpp (no need to 
resend webrev)

+  if (this == dom)
      return NULL;

Yes, changes in node.cpp are good.

Thanks,
Vladimir

On 2/26/16 3:19 PM, Claes Redestad wrote:
> Hi,
>
> On 2016-02-26 18:56, Vladimir Kozlov wrote:
>> Good changes. We indeed print statistics only in non-product build.
>
> Thanks!
>
>>
>> graphKit.cpp - add {} to code:
>>
>> +#ifndef PRODUCT
>>      if (null_true == top())
>>        explicit_null_checks_elided++;
>> +#endif
>>
>> ifnode.cpp - add {} and adjust spaces "if (dist > 2) {":
>>
>> +#ifndef PRODUCT
>>    if( dist > 2 )              // Add to count of NULL checks elided
>>      explicit_null_checks_elided++;
>> +#endif
>>
>> parse1.cpp - the same:
>>
>> -  if( implicit_null_throws )
>> +  if( SharedRuntime::_implicit_null_throws )
>>      tty->print_cr("%d implicit null exceptions at runtime",
>> -                  implicit_null_throws);
>> +                  SharedRuntime::_implicit_null_throws);
>
> Sure! Mind if I clean up nearby to keep things consistent?
>
> http://cr.openjdk.java.net/~redestad/8150720/webrev.01/
>
>>
>>
>> > There is also a small "leak" in the corner case where "edge_end ==
>> > (char*)this" since we're not freeing the input array in this case.
>>
>> There is no "leak" since after compilation is done all C2 arenas are
>> cleaned/freed. Yes, during compilation required space could be increased.
>>
>> > We are not freeing when ASSERT is not defined? O_o The patch that
>> > apparently does an equivalent transformation of the original code
>> makes it even creepier.
>>
>> It is done to catch dangling Node* pointers in debug build:
>>
>>  661 #ifdef ASSERT
>>  662   // We will not actually delete the storage, but we'll make the
>> node unusable.
>>  663   *(address*)this = badAddress;  // smash the C++ vtbl, probably
>>  664   _in = _out = (Node**) badAddress;
>>
>> So please revert that code back except the code which just increment
>> unused counters and can be indeed removed.
>
> Thanks for clarifying and explaining this!
>
> I do think the code in node.cpp is correctly transformed to do the same
> thing apart from the counters and does not need to be reverted though?
>
> Thanks!
>
> /Claes
>
>>
>> Thanks,
>> Vladimir
>>
>> On 2/26/16 3:40 AM, Claes Redestad wrote:
>>> Hi,
>>>
>>> src/share/vm/opto/parse1.cpp currently defines a number of global
>>> counters that is used to collect some statistics. Some of these counters
>>> are incremented in product builds, but ever only displayed in
>>> non-product builds if run with -XX:+PrintOptoStatistics.
>>>
>>> This patch masks such counters from product builds, removes a few
>>> counters that were never read, fixes an issue with implicit_null_throws
>>> which was never incremented in current code (seems it was moved to
>>> SharedRuntime a long time ago without updating print_statistics) and
>>> removes an unused enum (InlineStyle):
>>>
>>> webrev: http://cr.openjdk.java.net/~redestad/8150720/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8150720
>>>
>>> Testing: RBT --test hotspot/test/:hotspot_all, manual verification that
>>> -XX:+PrintOptoStatistics prints out a count for implicit NPE's thrown
>>>
>>> Thanks!
>>>
>>> /Claes
>

From vladimir.kozlov at oracle.com  Sat Feb 27 02:50:22 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 26 Feb 2016 18:50:22 -0800
Subject: RFR (M): 8150767: Update for x86 SHA Extensions enabling
In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A36FCA@ORSMSX106.amr.corp.intel.com>
References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A36FCA@ORSMSX106.amr.corp.intel.com>
Message-ID: <56D10EEE.4040604@oracle.com>

Very nice, Vivek!!!

Did you run tests with both 32- and 64-bit VMs?

Small notes:

In vm_version_x86.hpp spacing are not aligned in next line:

    static bool supports_avxonly()    { return ((supports_avx2() || 
supports_avx()) && !supports_evex()); }
+  static bool supports_sha()      { return (_features & CPU_SHA) != 0; }

Flags setting code in vm_version_x86.cpp should be like this (you can 
check supports_sha() only once, don't split '} else {' line, set UseSHA 
false if all intrinsics flags are false (I included UseSHA512Intrinsics 
for future) ):

   if (supports_sha()) {
     if (FLAG_IS_DEFAULT(UseSHA)) {
       UseSHA = true;
     }
   } else if (UseSHA) {
     warning("SHA instructions are not available on this CPU");
     FLAG_SET_DEFAULT(UseSHA, false);
   }

   if (UseSHA) {
     if (FLAG_IS_DEFAULT(UseSHA1Intrinsics)) {
       FLAG_SET_DEFAULT(UseSHA1Intrinsics, true);
     }
   } else if (UseSHA1Intrinsics) {
     warning("Intrinsics for SHA-1 crypto hash functions not available 
on this CPU.");
     FLAG_SET_DEFAULT(UseSHA1Intrinsics, false);
   }

   if (UseSHA) {
     if (FLAG_IS_DEFAULT(UseSHA256Intrinsics)) {
       FLAG_SET_DEFAULT(UseSHA256Intrinsics, true);
     }
   } else if (UseSHA256Intrinsics) {
     warning("Intrinsics for SHA-224 and SHA-256 crypto hash functions 
not available on this CPU.");
     FLAG_SET_DEFAULT(UseSHA256Intrinsics, false);
   }

   if (UseSHA512Intrinsics) {
     warning("Intrinsics for SHA-384 and SHA-512 crypto hash functions 
not available on this CPU.");
     FLAG_SET_DEFAULT(UseSHA512Intrinsics, false);
   }

   if (!(UseSHA1Intrinsics || UseSHA256Intrinsics || UseSHA512Intrinsics)) {
     FLAG_SET_DEFAULT(UseSHA, false);
   }


Thanks,
Vladimir

On 2/26/16 4:37 PM, Deshpande, Vivek R wrote:
> Hi all
>
> I would like to contribute a patch which optimizesSHA-1 andSHA-256 for
> 64 and 32 bitX86architecture using Intel SHA extensions.
>
> Could you please review and sponsor this patch.
>
> Bug-id:
>
> https://bugs.openjdk.java.net/browse/JDK-8150767
> webrev:
>
> http://cr.openjdk.java.net/~vdeshpande/SHANI/8150767/webrev.00/
>
> Thanks and regards,
>
> Vivek
>

From hui.shi at linaro.org  Sat Feb 27 11:40:29 2016
From: hui.shi at linaro.org (Hui Shi)
Date: Sat, 27 Feb 2016 19:40:29 +0800
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJGUjogODE0OTczMzogQUFyY2g2NDogcmVmYWN0b3JjaGFyX2Fycg==?=
	=?UTF-8?B?YXlfZXF1YWxzL2J5dGVfYXJyYXlfZXF1YWxzL3N0cmluZ19lcXVhbHM=?=
In-Reply-To: <56D06345.7010309@redhat.com>
References: <56CC2DF8.60806@oracle.com>
	
	<56C70C42.5020309@oracle.com>
	
	<56CC8630.2020708@redhat.com>
	
	<56CDBD2A.9050002@oracle.com>
	
	<56D06345.7010309@redhat.com>
Message-ID: 

Thanks!

On 26 February 2016 at 22:37, Andrew Haley  wrote:

> On 02/26/2016 02:28 PM, Hui Shi wrote:
> > Can I have another review for this patch?
>
> If you insist.  OK.
>
> Andrew.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From zoltan.majo at oracle.com  Mon Feb 29 07:03:53 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Mon, 29 Feb 2016 08:03:53 +0100
Subject: [9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can
	time out due to frequent safepointing
In-Reply-To: <56D02643.50608@oracle.com>
References: <56CF2B77.9000707@oracle.com> <56CF2DFD.2090604@oracle.com>
	<56D02643.50608@oracle.com>
Message-ID: <56D3ED59.9000002@oracle.com>

Thank you, Aleksey and Tobias, for the review!

On 02/26/2016 11:17 AM, Zolt?n Maj? wrote:
> [...]
>
> So, based on your feedback, I'd prefer to go with Solution #1:
> http://cr.openjdk.java.net/~zmajo/8148940/webrev.00/

For the record: I'll push the changes for Solution #1. But I've added a 
comment to the test so that it is clear, why the test sleeps after every 
GC/finalization cycle. Here is the updated webrev:

http://cr.openjdk.java.net/~zmajo/8148940/webrev.02/

I'll start the push job shortly.

Thank you!

Best regards,


Zoltan

>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>
>>
>> -Aleksey
>>
>


From zoltan.majo at oracle.com  Mon Feb 29 11:50:52 2016
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Mon, 29 Feb 2016 12:50:52 +0100
Subject: [9] RFR (S): 8150349: Reduce the execution time of the
	hotspot_compiler_3 group
In-Reply-To: <56D0991A.1000404@oracle.com>
References: <56CF0D09.1080508@oracle.com> <56CF1C18.3080808@oracle.com>
	<56CF280A.1010705@oracle.com> <56CF37FC.1080906@oracle.com>
	<56D04526.5040803@oracle.com> <56D0991A.1000404@oracle.com>
Message-ID: <56D4309C.6030201@oracle.com>

Hi,


I think all issues that were brought up with this fix were address, so 
I'll push the fix shortly.

Thank you, Vladimir and Nils, for the review!

Best regards,


Zoltan


On 02/26/2016 07:27 PM, Vladimir Kozlov wrote:
> Good. I am fine to not split test group since, as you pointed, we will 
> work on tests time improvement.
>
> Thanks,
> Vladimir
>
> On 2/26/16 4:29 AM, Zolt?n Maj? wrote:
>> Hi Vladimir,
>>
>>
>> On 02/25/2016 06:21 PM, Vladimir Kozlov wrote:
>>> I am fine with removal of adler32 and bmi testing from JPRT runs
>>> because we don't have a plan to touch them.
>>> But code related to CRC32, CRC32c and string may be touched soon for
>>> some platforms.
>>
>> OK, so I've re-enabled testing of the CRC23, CRC32c and string
>> intrinsics (still within the hotspot_compiler_3 group). Running the
>> group still takes < 30 minutes on our slowest platforms, here are the
>> execution times:
>>
>> West:
>>   linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(25m 12s)
>>   solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(11m 46s)
>>
>> Stockholm:
>>    linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(24m 18s)
>>    solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(21m 01s)
>>
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~zmajo/8150349/webrev.01/
>>
>>> What if we created hotspot_compiler_4 group for them? How much time it
>>> would take to run it on slow platforms?
>>
>> I think it's fine to leave all tests in hotspot_compiler_3 as all
>> execution times are still below 30 minutes.
>>
>> I filed INTJDK-7622854: "Track the execution time of JPRT tests groups"
>> so that we can better track the execution times of the
>> hotspot_compiler_[1-3] test groups.
>>
>> Thank you!
>>
>> Best regards,
>>
>>
>> Zoltan
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 2/25/16 8:12 AM, Zolt?n Maj? wrote:
>>>> Hi Nils,
>>>>
>>>>
>>>> thank you for the feedback!
>>>>
>>>> On 02/25/2016 04:22 PM, Nils Eliasson wrote:
>>>>> Hi Zoltan,
>>>>>
>>>>> Have you opened a bug for fixing the tests?
>>>>
>>>> No, I have not, because there is an existing issue (INTJDK-7620326)
>>>> that is supposed to take care of the high execution
>>>> time of intrinsic-related tests on platforms where the relevant
>>>> intrinsics are not available. I've linked the two issues.
>>>>
>>>>>
>>>>> Do we really want to remove the String intrinsics from the list?
>>>>> aren't they pretty new?
>>>>
>>>> You are right, they are in part new (in part old intrinsics have been
>>>> updated). I thought to remove them nevertheless,
>>>> because they take a long time to execute and are anyway executed in
>>>> our nightlies.
>>>>
>>>> Best regards,
>>>>
>>>>
>>>> Zoltan
>>>>
>>>>>
>>>>> Thanks for fixing this,
>>>>> Nils Eliasson
>>>>>
>>>>> On 2016-02-25 15:17, Zolt?n Maj? wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> please review the patch for 8150349.
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8150349
>>>>>>
>>>>>> Problem: The hotspot_compiler_3 group of tests takes more than 30
>>>>>> minutes on our slowest platforms.
>>>>>>
>>>>>>
>>>>>> Solution: Remove a number of long-running tests from the
>>>>>> hotspot_compiler_3 group. All removed tests are related to
>>>>>> intrinsics, that is, they check the functionality of a reduced set
>>>>>> of the VM's functionality that is not often
>>>>>> modified. Also, we execute all removed tests daily (in our nightly
>>>>>> testing).
>>>>>>
>>>>>> Here is the time spent in hotspot_compiler_3 on our slowest
>>>>>> platforms after removing the tests:
>>>>>>
>>>>>> West:
>>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 
>>>>>> 22s)
>>>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=6
>>>>>> parallelcount=6 ram=31744MB cpufreqmhz=2848
>>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(19m 09s)
>>>>>>     platform=linux_x64_3.8 osname=linux osarch=x64 cpus=12
>>>>>> parallelcount=12 ram=60690MB cpufreqmhz=2294
>>>>>>
>>>>>> Stockholm:
>>>>>> solaris_sparcv9_5.11-fastdebug-c2-hotspot_compiler_3 success(15m 
>>>>>> 32s)
>>>>>>     platform=solaris_sparc_5.11 osname=solaris osarch=sparc cpus=12
>>>>>> parallelcount=12 ram=24576MB    cpufreqmhz=2848
>>>>>> linux_arm64_2.6-fastdebug-c2-hotspot_compiler_3 success(20m 24s)
>>>>>>     platform=linux_arm64_3.13 osname=linux osarch=arm64 cpus=8
>>>>>> parallelcount=8 ram=16061MB
>>>>>>
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~zmajo/8150349/webrev.00/
>>>>>>
>>>>>> Thank you!
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>>
>>>>>> Zoltan
>>>>>>
>>>>>
>>>>
>>


From aleksey.shipilev at oracle.com  Mon Feb 29 11:54:39 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 29 Feb 2016 14:54:39 +0300
Subject: RFR (S) 8150669: C1 intrinsic for Class.isPrimitive
In-Reply-To: <56CF6A7E.7080204@oracle.com>
References: <56CF6A7E.7080204@oracle.com>
Message-ID: <56D4317F.8040305@oracle.com>

On 02/25/2016 11:56 PM, Aleksey Shipilev wrote:
> I would like to amend C1 with handling Class.isPrimitive intrinsic:
>   http://cr.openjdk.java.net/~shade/8150669/webrev.01/
>   https://bugs.openjdk.java.net/browse/JDK-8150669
> 
> Through a long chain of dependencies, it would benefit String
> concatenation, possibly startup (lots of usages in java.lang.invoke, and
> who knows how many other places in JDK that use reflective meddling),
> and also, for a fun of it, fastdebug builds.
> 
> Performance data shows we improve all interesting cases:
>   http://cr.openjdk.java.net/~shade/8150669/notes.txt
> 
> Testing: new test; targeted benchmarks; JPRT -testset hotspot

Also, RBT tests are passing:
 hotspot/test/:hotspot_all,vm.runtime.testlist,vm.compiler.testlist

Please review!

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From vladimir.x.ivanov at oracle.com  Mon Feb 29 12:36:53 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 29 Feb 2016 15:36:53 +0300
Subject: [9] RFR (XS): 8150543: Mismatched access detection is inaccurate
In-Reply-To: <56D044D9.5030805@oracle.com>
References: <56D044D9.5030805@oracle.com>
Message-ID: <56D43B65.1080007@oracle.com>

Updated version:
   http://cr.openjdk.java.net/~vlivanov/8150543/webrev.01/

Adjusted is_mismatched_access for LoadP node which has memory_type() == 
T_ARRAY.

Best regards,
Vladimir Ivanov

On 2/26/16 3:28 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8150543/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8150543
>
> Mismatched access detection doesn't differentiate between boolean[] and
> byte[] element accesses. Alias type flattening erases element type for
> boolean[] to T_BYTE.
>
> The fix is to use more accurate source of information: the address type.
>
> Also, marked the tests as not applicable to C1, since it doesn't
> constant fold unsafe accesses.
>
> Testing: regression test, JPRT.
>
> Best regards,
> Vladimir Ivanov

From vladimir.x.ivanov at oracle.com  Mon Feb 29 12:37:14 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 29 Feb 2016 15:37:14 +0300
Subject: [9] RFR (M): 8068038: C2: large constant offsets aren't handled
	on SPARC
In-Reply-To: <56D0CB37.1040400@oracle.com>
References: <56CF7B9B.5000007@oracle.com> <56CF9452.7050606@oracle.com>
	<56D031D7.9070506@oracle.com> <56D0CB37.1040400@oracle.com>
Message-ID: <56D43B7A.1090905@oracle.com>

Thanks, Dean.

Best regards,
Vladimir Ivanov

On 2/27/16 1:01 AM, Dean Long wrote:
> These changes look good.
>
> dl
>
> On 2/26/2016 3:07 AM, Vladimir Ivanov wrote:
>> Thanks, Vladimir.
>>
>>>> http://cr.openjdk.java.net/~vlivanov/8068038/webrev.00
>>>
>>> Looks fine but leave 32-bit removal to JDK-8150388.
>> No problem, updated webrev in place.
>>
>>>> PS: there's an additional cleanup [1] in sparc.ad (mostly 32-bit SPARC
>>>> removal, but also added some comments). It can go along with this
>>>> fix or
>>>> as part of the 32-bit SPARC complete removal (JDK-8150388). Let me know
>>>> what do you prefer.
>>>
>>> Should be part of JDK-8150388 changes.
>> Sure. Updated JDK-8150388 with the link to the webrev.
>>
>> Best regards,
>> Vladimir Ivanov
>

From vladimir.x.ivanov at oracle.com  Mon Feb 29 12:39:29 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 29 Feb 2016 15:39:29 +0300
Subject: [9] RFR (XS): 8150543: Mismatched access detection is inaccurate
In-Reply-To: <56D43B65.1080007@oracle.com>
References: <56D044D9.5030805@oracle.com> <56D43B65.1080007@oracle.com>
Message-ID: <56D43C01.3040309@oracle.com>

On 2/29/16 3:36 PM, Vladimir Ivanov wrote:
> Updated version:
>    http://cr.openjdk.java.net/~vlivanov/8150543/webrev.01/
>
> Adjusted is_mismatched_access for LoadP node which has memory_type() ==
> T_ARRAY.
Sorry, T_ADDRESS:
   virtual BasicType memory_type() const { return T_ADDRESS; }

Best regards,
Vladimir Ivanov

From aleksey.shipilev at oracle.com  Mon Feb 29 13:00:25 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 29 Feb 2016 16:00:25 +0300
Subject: [9] RFR (XS): 8150543: Mismatched access detection is inaccurate
In-Reply-To: <56D43C01.3040309@oracle.com>
References: <56D044D9.5030805@oracle.com> <56D43B65.1080007@oracle.com>
	<56D43C01.3040309@oracle.com>
Message-ID: <56D440E9.1030007@oracle.com>

On 02/29/2016 03:39 PM, Vladimir Ivanov wrote:
> On 2/29/16 3:36 PM, Vladimir Ivanov wrote:
>> Updated version:
>>    http://cr.openjdk.java.net/~vlivanov/8150543/webrev.01/

Still okay. Can probably common the cases:

   switch (loadbt) {
     case T_BOOLEAN:
       loadbt = T_BYTE;
       break;
     case T_NARROWOOP:
     case T_ARRAY:
     case T_ADDRESS:
       loadbt = T_OBJECT;
       break;
   }

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From claes.redestad at oracle.com  Mon Feb 29 13:16:59 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 29 Feb 2016 14:16:59 +0100
Subject: RFR: 8150720: Cleanup code around PrintOptoStatistics
In-Reply-To: <56D106D7.6030205@oracle.com>
References: <56D039AB.5050605@oracle.com> <56D091C5.1050903@oracle.com>
	<56D0DD6A.6070202@oracle.com> <56D106D7.6030205@oracle.com>
Message-ID: <56D444CB.2090704@oracle.com>

On 2016-02-27 03:15, Vladimir Kozlov wrote:
> Clearing nearby code is good. You missed {} in ifnode.cpp (no need to 
> resend webrev)
>
> +  if (this == dom)
>      return NULL;

Fixed (and updated in-place[1]).

>
> Yes, changes in node.cpp are good.

Vladimir I. also OK'd this offline, so I'll go ahead and push this version

Thanks for reviewing!

/Claes

[1] http://cr.openjdk.java.net/~redestad/8150720/webrev.01/

From vladimir.x.ivanov at oracle.com  Mon Feb 29 13:21:11 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 29 Feb 2016 16:21:11 +0300
Subject: [9] RFR (M): 8143407: C1: @Stable array support
In-Reply-To: <7FEA138A-F1FA-495E-BA1D-410E17B006D7@oracle.com>
References: <56C7602B.3090300@oracle.com> <56D06FD3.4080306@oracle.com>
	<84572150-41B0-4D99-A296-F2528A768DB4@oracle.com>
	<56D0BE17.7020104@oracle.com>
	<7FEA138A-F1FA-495E-BA1D-410E17B006D7@oracle.com>
Message-ID: <56D445C7.7040703@oracle.com>

Chris,

>> I slightly reworded the assert message. Hope it reads better now:
>> +         assert(!field->is_stable() || !field_value.is_null_or_zero(),
>> +                "stable static w/ default value should not be a constant?);
>
> Better, thanks.  Are we saving bytes in assert messages now? ;-)
Well, more like keystrokes :-) But I can expand the message if you wish.

>>> +   switch (field_type) {
>>> +     case T_ARRAY:
>>> +     case T_OBJECT:
>>> +       if (field_value.as_object()->should_be_constant()) {
>>> +         return new Constant(value);
>>> +       }
>>> +       break;
>>> +     default:
>>> +      return new Constant(value);
>
> Just noticed the indent is wrong on this line.
Fixed.

Best regards,
Vladimir Ivanov

From claes.redestad at oracle.com  Mon Feb 29 14:28:26 2016
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 29 Feb 2016 15:28:26 +0100
Subject: RFR (S) 8150669: C1 intrinsic for Class.isPrimitive
In-Reply-To: <56D4317F.8040305@oracle.com>
References: <56CF6A7E.7080204@oracle.com> <56D4317F.8040305@oracle.com>
Message-ID: <56D4558A.7050605@oracle.com>

Hi,

On 2016-02-29 12:54, Aleksey Shipilev wrote:
> On 02/25/2016 11:56 PM, Aleksey Shipilev wrote:
>> I would like to amend C1 with handling Class.isPrimitive intrinsic:
>>    http://cr.openjdk.java.net/~shade/8150669/webrev.01/

I'm not intimate with the C1 code, but overall the changes and the
added test seems OK to me.

>>    https://bugs.openjdk.java.net/browse/JDK-8150669
>>
>> Through a long chain of dependencies, it would benefit String
>> concatenation, possibly startup (lots of usages in java.lang.invoke, and
>> who knows how many other places in JDK that use reflective meddling),
>> and also, for a fun of it, fastdebug builds.
>>
>> Performance data shows we improve all interesting cases:
>>    http://cr.openjdk.java.net/~shade/8150669/notes.txt

This looks really good!

Thanks!

/Claes

>>
>> Testing: new test; targeted benchmarks; JPRT -testset hotspot
> Also, RBT tests are passing:
>   hotspot/test/:hotspot_all,vm.runtime.testlist,vm.compiler.testlist
>
> Please review!
>
> -Aleksey
>


From rahul.v.raghavan at oracle.com  Mon Feb 29 18:12:40 2016
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Mon, 29 Feb 2016 10:12:40 -0800 (PST)
Subject: RFR(XS): 8145348: Make intrinsics flags diagnostic
Message-ID: <34a9defd-e509-4a0e-b410-74d12add6a77@default>

Hi,

Please review the following patch for JDK-8145348.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145348
Webrev: http://cr.openjdk.java.net/~rraghavan/8145348/webrev.00/

- Identified flags which control intrinsics generation, from vmIntrinsics::is_disabled_by_flags().

- Changed following flags from 'product' or 'develop' to 'diagnostic' type -
      [globals.hpp]
          UseGHASHIntrinsics
          InlineArrayCopy
          InlineObjectHash
          InlineNatives
          InlineMathNatives
          InlineClassNatives
          InlineThreadNatives
          InlineUnsafeOps
          UseAESIntrinsics
          UseAESCTRIntrinsics
          UseSHA1Intrinsics
          UseSHA256Intrinsics
          UseSHA512Intrinsics
          UseCRC32Intrinsics
          UseCRC32CIntrinsics
          UseAdler32Intrinsics
          UseVectorizedMismatchIntrinsic
 
      [c1_globals.hpp]
          InlineNIOCheckIndex
 
      [c2_globals.hpp]
          InlineReflectionGetCallerClass
          InlineObjectCopy
          SpecialStringCompareTo
          SpecialStringIndexOf
          SpecialStringEquals
          SpecialArraysEquals
          SpecialEncodeISOArray
          UseMathExactIntrinsics
          UseMultiplyToLenIntrinsic
          UseSquareToLenIntrinsic
          UseMulAddIntrinsic
          UseMontgomeryMultiplyIntrinsic
          UseMontgomerySquareIntrinsic

- Added required -XX:+UnlockDiagnosticVMOptions to @run for following two tests using the intrinsic flags.
                hotspot/test/compiler/intrinsics/muladd/TestMulAdd.java
                hotspot/test/compiler/runtime/6859338/Test6859338.java
  (confirmed all other tests using any intrinsic flags got required -XX:+UnlockDiagnosticVMOptions also)

- No issues with JPRT (-testset hotspot).
- Confirmed no issues, expected behavior with the change for small unit tests.
    (for debug/release VM with flags on/off, UnlockDiagnosticVMOptions usage combinations)


Thanks,
Rahul

From pavel.punegov at oracle.com  Mon Feb 29 19:01:48 2016
From: pavel.punegov at oracle.com (Pavel Punegov)
Date: Mon, 29 Feb 2016 22:01:48 +0300
Subject: RFR(S/M): 8150646: Add support for blocking compiles through
	whitebox API
In-Reply-To: 
References: <56CF175E.1030806@oracle.com> <56CF6E9D.8060507@oracle.com>
	<56D00EAB.1010009@oracle.com>
	
Message-ID: 

Hi Volker,

I have some comments and questions about your patch:

- src/share/vm/runtime/advancedThresholdPolicy.cpp

You check for background compilation  (blocking) by the searching for an appropriate directive. 
But there is a CompileTask::is_blocking() method, that returns a value set in CompilerBroker::compile_method_base when a compile task was created. It seems that CompileBroker::is_compile_blocking() finds the right directive and checks for BackgroundCompilation for being set.

I think that checking it twice could lead to an issue with different directives being set on the stack. With diagnostic commands I can clear the directives stack, or remove directives. If I do this in between the task was submitted and being checked  in AdvancedThresholdPolicy::select_task, this task could became non blocking.

- src/share/vm/compiler/compileBroker.cpp

1317   backgroundCompilation = directive->BackgroundCompilationOption;

Does it check the BackgroundCompilation for being set for both c1 and c2 at the same time? What will happen if I set BackgroundCompilation to c1 only?
AFAIK, there are different queues for c1 and c2, and hence we could have BackgroundCompilation to be set separately for both compilers.

- test/lib/sun/hotspot/WhiteBox.java
 <>
318       addCompilerDirective("[{ match: ? 

I?m not quite sure that this is a right way to set a method to be blocking. Adding a directive on top of the stack makes already set directives for that method not used.
For example, if I would like to set method to be logged (LogCompilation) and disable some inlining, but then enqueue it with WB, I will get it to be only compiled without LogCompilation.
But, AFAIK, setting CompileCommand option will work for already set directive through a compatibility in CompilerDirectives.

So, I would prefer to have a directive (file or WB) or an option set by myself, and then invoke standard WB.enqueueMethodForCompilation().

? Thanks,
Pavel Punegov

> On 26 Feb 2016, at 21:47, Volker Simonis  wrote:
> 
> Hi,
> 
> so I want to propose the following solution for this problem:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8150646_toplevel
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8150646_hotspot/
> 
> I've started from the opposite site and made the BackgroundCompilation
> manageable through the compiler directives framework. Once this works
> (and it's actually trivial due to the nice design of the
> CompilerDirectives framework :), we get the possibility to set the
> BackgroundCompilation option on a per method base on the command line
> via the CompileCommand option for free:
> 
> -XX:CompileCommand="option,java.lang.String::charAt,bool,BackgroundCompilation,false"
> 
> And of course we can also use it directly as a compiler directive:
> 
> [{ match: "java.lang.String::charAt", BackgroundCompilation: false }]
> 
> It also becomes possible to use this directly from the Whitebox API
> through the DiagnosticCommand.compilerDirectivesAdd command.
> Unfortunately, this command takes a file with compiler directives as
> argument. I think this would be overkill in this context. So because
> it was so easy and convenient, I added the following two new Whitebox
> methods:
> 
>  public native void addCompilerDirective(String compDirect);
>  public native void removeCompilerDirective();
> 
> which can now be used to set arbitrary CompilerDirective command
> directly from within the WhiteBox API. (The implementation of these
> two methods is trivial as you can see in whitebox.cpp).
> 
> The blocking versions of enqueueMethodForCompilation() now become
> simple wrappers around the existing methods without the need of any
> code changes in their native implementation. This is good, because it
> keeps the WhiteBox API stable!
> 
> Finally some words about the implementation of the per-method
> BackgroundCompilation functionality. It actually only requires two
> small changes:
> 
> 1. extending CompileBroker::is_compile_blocking() to take the method
> and compilation level as arguments and use them to query the
> DirectivesStack for the corresponding BackgroundCompilation value.
> 
> 2. changing AdvancedThresholdPolicy::select_task() such that it
> prefers blocking compilations. This is not only necessary, because it
> decreases the time we have to wait for a blocking compilation, but
> also because it prevents blocking compiles from getting stale. This
> could otherwise easily happen in AdvancedThresholdPolicy::is_stale()
> for methods which only get artificially compiled during a test because
> their invocations counters are usually too small.
> 
> There's still a small probability that a blocking compilation will be
> not blocking. This can happen if a method for which we request the
> blocking compilation is already in the compilation queue (see the
> check 'compilation_is_in_queue(method)' in
> CompileBroker::compile_method_base()). In testing scenarios this will
> rarely happen because methods which are manually compiled shouldn't
> get called that many times to implicitly place them into the compile
> queue. But we can even completely avoid this problem by using
> WB.isMethodQueuedForCompilation() to make sure that a method is not in
> the queue before we request a blocking compilation.
> 
> I've also added a small regression test to demonstrate and verify the
> new functionality.
> 
> Regards,
> Volker
> 
> 
> 
> 
> On Fri, Feb 26, 2016 at 9:36 AM, Nils Eliasson  wrote:
>> Hi Vladimir,
>> 
>> WhiteBox::compilation_locked is a global state that temporarily stops all
>> compilations. I this case I just want to achieve blocking compilation for a
>> single compile without affecting the rest of the system. The tests using it
>> will continue executing as soon as that compile is finished, saving time
>> where wait-loops is used today. It adds nice determinism to tests.
>> 
>> Best regards,
>> Nils Eliasson
>> 
>> 
>> On 2016-02-25 22:14, Vladimir Kozlov wrote:
>>> 
>>> You are adding parameter which is used only for testing.
>>> Can we have callback(or check field) into WB instead? Similar to
>>> WhiteBox::compilation_locked.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 2/25/16 7:01 AM, Nils Eliasson wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Please review this change that adds support for blocking compiles in the
>>>> whitebox API. This enables simpler less time consuming tests.
>>>> 
>>>> Motivation:
>>>> * -XX:-BackgroundCompilation is a global flag and can be time consuming
>>>> * Blocking compiles removes the need for waiting on the compile queue to
>>>> complete
>>>> * Compiles put in the queue may be evicted if the queue grows to big -
>>>> causing indeterminism in the test
>>>> * Less VM-flags allows for more tests in the same VM
>>>> 
>>>> Testing:
>>>> Posting a separate RFR for test fix that uses this change. They will be
>>>> pushed at the same time.
>>>> 
>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8150646
>>>> JDK rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev_jdk.01/
>>>> Hotspot rev: http://cr.openjdk.java.net/~neliasso/8150646/webrev.02/
>>>> 
>>>> Best regards,
>>>> Nils Eliasson
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vladimir.kozlov at oracle.com  Mon Feb 29 20:19:48 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 29 Feb 2016 12:19:48 -0800
Subject: [9] RFR (XS): 8150543: Mismatched access detection is inaccurate
In-Reply-To: <56D43C01.3040309@oracle.com>
References: <56D044D9.5030805@oracle.com> <56D43B65.1080007@oracle.com>
	<56D43C01.3040309@oracle.com>
Message-ID: <56D4A7E4.4000107@oracle.com>

Looks good.

Thanks,
Vladimir

On 2/29/16 4:39 AM, Vladimir Ivanov wrote:
> On 2/29/16 3:36 PM, Vladimir Ivanov wrote:
>> Updated version:
>>    http://cr.openjdk.java.net/~vlivanov/8150543/webrev.01/
>>
>> Adjusted is_mismatched_access for LoadP node which has memory_type() ==
>> T_ARRAY.
> Sorry, T_ADDRESS:
>    virtual BasicType memory_type() const { return T_ADDRESS; }
>
> Best regards,
> Vladimir Ivanov

From vladimir.kozlov at oracle.com  Mon Feb 29 20:34:54 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 29 Feb 2016 12:34:54 -0800
Subject: RFR(XS): 8145348: Make intrinsics flags diagnostic
In-Reply-To: <34a9defd-e509-4a0e-b410-74d12add6a77@default>
References: <34a9defd-e509-4a0e-b410-74d12add6a77@default>
Message-ID: <56D4AB6E.7090005@oracle.com>

Looks good but we need to file CCC request since we changing product 
flags. You can push after it is approved.

Thanks,
Vladimir

On 2/29/16 10:12 AM, Rahul Raghavan wrote:
> Hi,
>
> Please review the following patch for JDK-8145348.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145348
> Webrev: http://cr.openjdk.java.net/~rraghavan/8145348/webrev.00/
>
> - Identified flags which control intrinsics generation, from vmIntrinsics::is_disabled_by_flags().
>
> - Changed following flags from 'product' or 'develop' to 'diagnostic' type -
>        [globals.hpp]
>            UseGHASHIntrinsics
>            InlineArrayCopy
>            InlineObjectHash
>            InlineNatives
>            InlineMathNatives
>            InlineClassNatives
>            InlineThreadNatives
>            InlineUnsafeOps
>            UseAESIntrinsics
>            UseAESCTRIntrinsics
>            UseSHA1Intrinsics
>            UseSHA256Intrinsics
>            UseSHA512Intrinsics
>            UseCRC32Intrinsics
>            UseCRC32CIntrinsics
>            UseAdler32Intrinsics
>            UseVectorizedMismatchIntrinsic
>
>        [c1_globals.hpp]
>            InlineNIOCheckIndex
>
>        [c2_globals.hpp]
>            InlineReflectionGetCallerClass
>            InlineObjectCopy
>            SpecialStringCompareTo
>            SpecialStringIndexOf
>            SpecialStringEquals
>            SpecialArraysEquals
>            SpecialEncodeISOArray
>            UseMathExactIntrinsics
>            UseMultiplyToLenIntrinsic
>            UseSquareToLenIntrinsic
>            UseMulAddIntrinsic
>            UseMontgomeryMultiplyIntrinsic
>            UseMontgomerySquareIntrinsic
>
> - Added required -XX:+UnlockDiagnosticVMOptions to @run for following two tests using the intrinsic flags.
>                  hotspot/test/compiler/intrinsics/muladd/TestMulAdd.java
>                  hotspot/test/compiler/runtime/6859338/Test6859338.java
>    (confirmed all other tests using any intrinsic flags got required -XX:+UnlockDiagnosticVMOptions also)
>
> - No issues with JPRT (-testset hotspot).
> - Confirmed no issues, expected behavior with the change for small unit tests.
>      (for debug/release VM with flags on/off, UnlockDiagnosticVMOptions usage combinations)
>
>
> Thanks,
> Rahul
>

From vladimir.x.ivanov at oracle.com  Mon Feb 29 20:44:06 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 29 Feb 2016 23:44:06 +0300
Subject: [9] RFR (XS): 8150543: Mismatched access detection is inaccurate
In-Reply-To: <56D4A7E4.4000107@oracle.com>
References: <56D044D9.5030805@oracle.com> <56D43B65.1080007@oracle.com>
	<56D43C01.3040309@oracle.com> <56D4A7E4.4000107@oracle.com>
Message-ID: <56D4AD96.4030002@oracle.com>

Vladimir, Aleksey, thanks!

Best regards,
Vladimir Ivanov

On 2/29/16 11:19 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 2/29/16 4:39 AM, Vladimir Ivanov wrote:
>> On 2/29/16 3:36 PM, Vladimir Ivanov wrote:
>>> Updated version:
>>>    http://cr.openjdk.java.net/~vlivanov/8150543/webrev.01/
>>>
>>> Adjusted is_mismatched_access for LoadP node which has memory_type() ==
>>> T_ARRAY.
>> Sorry, T_ADDRESS:
>>    virtual BasicType memory_type() const { return T_ADDRESS; }
>>
>> Best regards,
>> Vladimir Ivanov

From aleksey.shipilev at oracle.com  Mon Feb 29 21:02:47 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 1 Mar 2016 00:02:47 +0300
Subject: RFR (S) 8146801: Allocating short arrays of non-constant size is slow
Message-ID: <56D4B1F7.4040201@oracle.com>

Hi,

Object storage zeroing uses "rep stos" instructions on x86, which are
fast on long lengths, but have the setup penalty. We successfully avoid
that penalty when zeroing the objects of known lengths (all objects and
arrays of constant sizes). However, we don't do anything for arrays of
non-constant sizes, which are very frequent.

See more details here:
  https://bugs.openjdk.java.net/browse/JDK-8146801

Patch:
  http://cr.openjdk.java.net/~shade/8146801/webrev.02/

The core of the changes is at MacroAssembler::clear_mem.

The rest is collateral:
  a) pulling InitArrayShortSize from Matchers to global VM options to
get the access to it in MacroAssembler;
  b) dragging ClearArrayNode::_is_large when ClearArrayNode::Ideal bails
on large constant length -- otherwise we produce effectively dead code
for short loop in MacroAssembler, that is never taken.

With this patch, the allocation performance for small arrays is improved
3-4x. Performance data and disassemblies:
  http://cr.openjdk.java.net/~shade/8146801/notes.txt

Testing: JPRT -testset hotspot; targeted microbenchmarks; RBT
hotspot/test/:hotspot_all,vm.runtime.testlist,vm.compiler.testlist

Cheers,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From vivek.r.deshpande at intel.com  Mon Feb 29 21:29:58 2016
From: vivek.r.deshpande at intel.com (Deshpande, Vivek R)
Date: Mon, 29 Feb 2016 21:29:58 +0000
Subject: RFR (M): 8150767: Update for x86 SHA Extensions enabling
In-Reply-To: <56D10EEE.4040604@oracle.com>
References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A36FCA@ORSMSX106.amr.corp.intel.com>
	<56D10EEE.4040604@oracle.com>
Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A38CB7@ORSMSX106.amr.corp.intel.com>

HI Vladimir

Thank you for your review.
I have updated the patch with the changes you have suggested.
The new webrev is at this location:
http://cr.openjdk.java.net/~vdeshpande/SHANI/8150767/webrev.01/

Regards
Vivek

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Friday, February 26, 2016 6:50 PM
To: Deshpande, Vivek R; hotspot compiler
Cc: Viswanathan, Sandhya; Rukmannagari, Shravya
Subject: Re: RFR (M): 8150767: Update for x86 SHA Extensions enabling

Very nice, Vivek!!!

Did you run tests with both 32- and 64-bit VMs?

Small notes:

In vm_version_x86.hpp spacing are not aligned in next line:

    static bool supports_avxonly()    { return ((supports_avx2() || 
supports_avx()) && !supports_evex()); }
+  static bool supports_sha()      { return (_features & CPU_SHA) != 0; }

Flags setting code in vm_version_x86.cpp should be like this (you can check supports_sha() only once, don't split '} else {' line, set UseSHA false if all intrinsics flags are false (I included UseSHA512Intrinsics for future) ):

   if (supports_sha()) {
     if (FLAG_IS_DEFAULT(UseSHA)) {
       UseSHA = true;
     }
   } else if (UseSHA) {
     warning("SHA instructions are not available on this CPU");
     FLAG_SET_DEFAULT(UseSHA, false);
   }

   if (UseSHA) {
     if (FLAG_IS_DEFAULT(UseSHA1Intrinsics)) {
       FLAG_SET_DEFAULT(UseSHA1Intrinsics, true);
     }
   } else if (UseSHA1Intrinsics) {
     warning("Intrinsics for SHA-1 crypto hash functions not available on this CPU.");
     FLAG_SET_DEFAULT(UseSHA1Intrinsics, false);
   }

   if (UseSHA) {
     if (FLAG_IS_DEFAULT(UseSHA256Intrinsics)) {
       FLAG_SET_DEFAULT(UseSHA256Intrinsics, true);
     }
   } else if (UseSHA256Intrinsics) {
     warning("Intrinsics for SHA-224 and SHA-256 crypto hash functions not available on this CPU.");
     FLAG_SET_DEFAULT(UseSHA256Intrinsics, false);
   }

   if (UseSHA512Intrinsics) {
     warning("Intrinsics for SHA-384 and SHA-512 crypto hash functions not available on this CPU.");
     FLAG_SET_DEFAULT(UseSHA512Intrinsics, false);
   }

   if (!(UseSHA1Intrinsics || UseSHA256Intrinsics || UseSHA512Intrinsics)) {
     FLAG_SET_DEFAULT(UseSHA, false);
   }


Thanks,
Vladimir

On 2/26/16 4:37 PM, Deshpande, Vivek R wrote:
> Hi all
>
> I would like to contribute a patch which optimizesSHA-1 andSHA-256 for
> 64 and 32 bitX86architecture using Intel SHA extensions.
>
> Could you please review and sponsor this patch.
>
> Bug-id:
>
> https://bugs.openjdk.java.net/browse/JDK-8150767
> webrev:
>
> http://cr.openjdk.java.net/~vdeshpande/SHANI/8150767/webrev.00/
>
> Thanks and regards,
>
> Vivek
>

From christian.thalinger at oracle.com  Mon Feb 29 21:46:54 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 29 Feb 2016 11:46:54 -1000
Subject: RFR (S) 8150669: C1 intrinsic for Class.isPrimitive
In-Reply-To: <56CF6A7E.7080204@oracle.com>
References: <56CF6A7E.7080204@oracle.com>
Message-ID: 


> On Feb 25, 2016, at 10:56 AM, Aleksey Shipilev  wrote:
> 
> Hi,
> 
> I would like to amend C1 with handling Class.isPrimitive intrinsic:
>  http://cr.openjdk.java.net/~shade/8150669/webrev.01/
>  https://bugs.openjdk.java.net/browse/JDK-8150669
> 
> Through a long chain of dependencies, it would benefit String
> concatenation, possibly startup (lots of usages in java.lang.invoke, and
> who knows how many other places in JDK that use reflective meddling),
> and also, for a fun of it, fastdebug builds.

Can you explain the fastdebug comment a bit?  Have we seen real issues or is this just a nice side-effect?

> 
> Performance data shows we improve all interesting cases:
>  http://cr.openjdk.java.net/~shade/8150669/notes.txt
> 
> Testing: new test; targeted benchmarks; JPRT -testset hotspot
> 
> Thanks,
> -Aleksey
> 


From christian.thalinger at oracle.com  Mon Feb 29 21:53:41 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 29 Feb 2016 11:53:41 -1000
Subject: RFR (S) 8146801: Allocating short arrays of non-constant size is
	slow
In-Reply-To: <56D4B1F7.4040201@oracle.com>
References: <56D4B1F7.4040201@oracle.com>
Message-ID: 


> On Feb 29, 2016, at 11:02 AM, Aleksey Shipilev  wrote:
> 
> Hi,
> 
> Object storage zeroing uses "rep stos" instructions on x86, which are
> fast on long lengths, but have the setup penalty. We successfully avoid
> that penalty when zeroing the objects of known lengths (all objects and
> arrays of constant sizes). However, we don't do anything for arrays of
> non-constant sizes, which are very frequent.
> 
> See more details here:
>  https://bugs.openjdk.java.net/browse/JDK-8146801
> 
> Patch:
>  http://cr.openjdk.java.net/~shade/8146801/webrev.02/
> 
> The core of the changes is at MacroAssembler::clear_mem.
> 
> The rest is collateral:
>  a) pulling InitArrayShortSize from Matchers to global VM options to
> get the access to it in MacroAssembler;

+  product_pd(intx, InitArrayShortSize,                                      \

Don?t make it a product flag; diagnostic should be sufficient.  This will require adding diagnostic_pd support.  If you don?t want to do that make the flag develop.

>   b) dragging ClearArrayNode::_is_large when ClearArrayNode::Ideal bails
> on large constant length -- otherwise we produce effectively dead code
> for short loop in MacroAssembler, that is never taken.
> 
> With this patch, the allocation performance for small arrays is improved
> 3-4x. Performance data and disassemblies:
>  http://cr.openjdk.java.net/~shade/8146801/notes.txt
> 
> Testing: JPRT -testset hotspot; targeted microbenchmarks; RBT
> hotspot/test/:hotspot_all,vm.runtime.testlist,vm.compiler.testlist
> 
> Cheers,
> -Aleksey
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vivek.r.deshpande at intel.com  Mon Feb 29 21:54:37 2016
From: vivek.r.deshpande at intel.com (Deshpande, Vivek R)
Date: Mon, 29 Feb 2016 21:54:37 +0000
Subject: RFR (M): 8150767: Update for x86 SHA Extensions enabling
In-Reply-To: <56D10EEE.4040604@oracle.com>
References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A36FCA@ORSMSX106.amr.corp.intel.com>
	<56D10EEE.4040604@oracle.com>
Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A38D87@ORSMSX106.amr.corp.intel.com>

Hi Vladimir

I have tested it on both 32 bit and 64 bit VMs using TestSHA.java in jtreg test in jdk\test.

Regards
Vivek

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Friday, February 26, 2016 6:50 PM
To: Deshpande, Vivek R; hotspot compiler
Cc: Viswanathan, Sandhya; Rukmannagari, Shravya
Subject: Re: RFR (M): 8150767: Update for x86 SHA Extensions enabling

Very nice, Vivek!!!

Did you run tests with both 32- and 64-bit VMs?

Small notes:

In vm_version_x86.hpp spacing are not aligned in next line:

    static bool supports_avxonly()    { return ((supports_avx2() || 
supports_avx()) && !supports_evex()); }
+  static bool supports_sha()      { return (_features & CPU_SHA) != 0; }

Flags setting code in vm_version_x86.cpp should be like this (you can check supports_sha() only once, don't split '} else {' line, set UseSHA false if all intrinsics flags are false (I included UseSHA512Intrinsics for future) ):

   if (supports_sha()) {
     if (FLAG_IS_DEFAULT(UseSHA)) {
       UseSHA = true;
     }
   } else if (UseSHA) {
     warning("SHA instructions are not available on this CPU");
     FLAG_SET_DEFAULT(UseSHA, false);
   }

   if (UseSHA) {
     if (FLAG_IS_DEFAULT(UseSHA1Intrinsics)) {
       FLAG_SET_DEFAULT(UseSHA1Intrinsics, true);
     }
   } else if (UseSHA1Intrinsics) {
     warning("Intrinsics for SHA-1 crypto hash functions not available on this CPU.");
     FLAG_SET_DEFAULT(UseSHA1Intrinsics, false);
   }

   if (UseSHA) {
     if (FLAG_IS_DEFAULT(UseSHA256Intrinsics)) {
       FLAG_SET_DEFAULT(UseSHA256Intrinsics, true);
     }
   } else if (UseSHA256Intrinsics) {
     warning("Intrinsics for SHA-224 and SHA-256 crypto hash functions not available on this CPU.");
     FLAG_SET_DEFAULT(UseSHA256Intrinsics, false);
   }

   if (UseSHA512Intrinsics) {
     warning("Intrinsics for SHA-384 and SHA-512 crypto hash functions not available on this CPU.");
     FLAG_SET_DEFAULT(UseSHA512Intrinsics, false);
   }

   if (!(UseSHA1Intrinsics || UseSHA256Intrinsics || UseSHA512Intrinsics)) {
     FLAG_SET_DEFAULT(UseSHA, false);
   }


Thanks,
Vladimir

On 2/26/16 4:37 PM, Deshpande, Vivek R wrote:
> Hi all
>
> I would like to contribute a patch which optimizesSHA-1 andSHA-256 for
> 64 and 32 bitX86architecture using Intel SHA extensions.
>
> Could you please review and sponsor this patch.
>
> Bug-id:
>
> https://bugs.openjdk.java.net/browse/JDK-8150767
> webrev:
>
> http://cr.openjdk.java.net/~vdeshpande/SHANI/8150767/webrev.00/
>
> Thanks and regards,
>
> Vivek
>

From christian.thalinger at oracle.com  Mon Feb 29 21:57:30 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 29 Feb 2016 11:57:30 -1000
Subject: RFR (M): 8150767: Update for x86 SHA Extensions enabling
In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A38CB7@ORSMSX106.amr.corp.intel.com>
References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A36FCA@ORSMSX106.amr.corp.intel.com>
	<56D10EEE.4040604@oracle.com>
	<53E8E64DB2403849AFD89B7D4DAC8B2A56A38CB7@ORSMSX106.amr.corp.intel.com>
Message-ID: 

Why is the new file called macroAssembler_intel_x86.cpp?

> On Feb 29, 2016, at 11:29 AM, Deshpande, Vivek R  wrote:
> 
> HI Vladimir
> 
> Thank you for your review.
> I have updated the patch with the changes you have suggested.
> The new webrev is at this location:
> http://cr.openjdk.java.net/~vdeshpande/SHANI/8150767/webrev.01/
> 
> Regards
> Vivek
> 
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
> Sent: Friday, February 26, 2016 6:50 PM
> To: Deshpande, Vivek R; hotspot compiler
> Cc: Viswanathan, Sandhya; Rukmannagari, Shravya
> Subject: Re: RFR (M): 8150767: Update for x86 SHA Extensions enabling
> 
> Very nice, Vivek!!!
> 
> Did you run tests with both 32- and 64-bit VMs?
> 
> Small notes:
> 
> In vm_version_x86.hpp spacing are not aligned in next line:
> 
>    static bool supports_avxonly()    { return ((supports_avx2() || 
> supports_avx()) && !supports_evex()); }
> +  static bool supports_sha()      { return (_features & CPU_SHA) != 0; }
> 
> Flags setting code in vm_version_x86.cpp should be like this (you can check supports_sha() only once, don't split '} else {' line, set UseSHA false if all intrinsics flags are false (I included UseSHA512Intrinsics for future) ):
> 
>   if (supports_sha()) {
>     if (FLAG_IS_DEFAULT(UseSHA)) {
>       UseSHA = true;
>     }
>   } else if (UseSHA) {
>     warning("SHA instructions are not available on this CPU");
>     FLAG_SET_DEFAULT(UseSHA, false);
>   }
> 
>   if (UseSHA) {
>     if (FLAG_IS_DEFAULT(UseSHA1Intrinsics)) {
>       FLAG_SET_DEFAULT(UseSHA1Intrinsics, true);
>     }
>   } else if (UseSHA1Intrinsics) {
>     warning("Intrinsics for SHA-1 crypto hash functions not available on this CPU.");
>     FLAG_SET_DEFAULT(UseSHA1Intrinsics, false);
>   }
> 
>   if (UseSHA) {
>     if (FLAG_IS_DEFAULT(UseSHA256Intrinsics)) {
>       FLAG_SET_DEFAULT(UseSHA256Intrinsics, true);
>     }
>   } else if (UseSHA256Intrinsics) {
>     warning("Intrinsics for SHA-224 and SHA-256 crypto hash functions not available on this CPU.");
>     FLAG_SET_DEFAULT(UseSHA256Intrinsics, false);
>   }
> 
>   if (UseSHA512Intrinsics) {
>     warning("Intrinsics for SHA-384 and SHA-512 crypto hash functions not available on this CPU.");
>     FLAG_SET_DEFAULT(UseSHA512Intrinsics, false);
>   }
> 
>   if (!(UseSHA1Intrinsics || UseSHA256Intrinsics || UseSHA512Intrinsics)) {
>     FLAG_SET_DEFAULT(UseSHA, false);
>   }
> 
> 
> Thanks,
> Vladimir
> 
> On 2/26/16 4:37 PM, Deshpande, Vivek R wrote:
>> Hi all
>> 
>> I would like to contribute a patch which optimizesSHA-1 andSHA-256 for
>> 64 and 32 bitX86architecture using Intel SHA extensions.
>> 
>> Could you please review and sponsor this patch.
>> 
>> Bug-id:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8150767
>> webrev:
>> 
>> http://cr.openjdk.java.net/~vdeshpande/SHANI/8150767/webrev.00/
>> 
>> Thanks and regards,
>> 
>> Vivek
>> 


From aleksey.shipilev at oracle.com  Mon Feb 29 21:58:59 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 1 Mar 2016 00:58:59 +0300
Subject: RFR (S) 8150669: C1 intrinsic for Class.isPrimitive
In-Reply-To: 
References: <56CF6A7E.7080204@oracle.com>
	
Message-ID: <56D4BF23.2070308@oracle.com>

On 03/01/2016 12:46 AM, Christian Thalinger wrote:
>> I would like to amend C1 with handling Class.isPrimitive intrinsic:
>>  http://cr.openjdk.java.net/~shade/8150669/webrev.01/
>>  https://bugs.openjdk.java.net/browse/JDK-8150669
>>
>> Through a long chain of dependencies, it would benefit String
>> concatenation, possibly startup (lots of usages in java.lang.invoke, and
>> who knows how many other places in JDK that use reflective meddling),
>> and also, for a fun of it, fastdebug builds.
> 
> Can you explain the fastdebug comment a bit?  Have we seen real issues or is this just a nice side-effect?

See the notes at the bottom:
 http://cr.openjdk.java.net/~shade/8150669/notes.txt

Nice side-effect of not going through Java-to-native transition. The
patch coincided with Zoltan trying to trim down on (fastdebug) testing
time, so I mentioned that for fun.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From aleksey.shipilev at oracle.com  Mon Feb 29 22:24:00 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 1 Mar 2016 01:24:00 +0300
Subject: RFR (S) 8146801: Allocating short arrays of non-constant size is
	slow
In-Reply-To: 
References: <56D4B1F7.4040201@oracle.com>
	
Message-ID: <56D4C500.20100@oracle.com>

On 03/01/2016 12:53 AM, Christian Thalinger wrote:
>> On Feb 29, 2016, at 11:02 AM, Aleksey Shipilev
> +  product_pd(intx, InitArrayShortSize,                                
>      \
> 
> Don?t make it a product flag; diagnostic should be sufficient.  This
> will require adding diagnostic_pd support.  If you don?t want to do that
> make the flag develop.

Okay, develop_pd now:
  http://cr.openjdk.java.net/~shade/8146801/webrev.03/

diagnostic_pd would certainly be nice to have, but I don't really want
to get even deeper into this rabbit hole.

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From christian.thalinger at oracle.com  Mon Feb 29 22:35:57 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 29 Feb 2016 12:35:57 -1000
Subject: RFR (S) 8150669: C1 intrinsic for Class.isPrimitive
In-Reply-To: <56D4BF23.2070308@oracle.com>
References: <56CF6A7E.7080204@oracle.com>
	
	<56D4BF23.2070308@oracle.com>
Message-ID: <4AAA9FF6-99A5-47F4-B707-0C6E0CB2D3BC@oracle.com>


> On Feb 29, 2016, at 11:58 AM, Aleksey Shipilev  wrote:
> 
> On 03/01/2016 12:46 AM, Christian Thalinger wrote:
>>> I would like to amend C1 with handling Class.isPrimitive intrinsic:
>>> http://cr.openjdk.java.net/~shade/8150669/webrev.01/
>>> https://bugs.openjdk.java.net/browse/JDK-8150669
>>> 
>>> Through a long chain of dependencies, it would benefit String
>>> concatenation, possibly startup (lots of usages in java.lang.invoke, and
>>> who knows how many other places in JDK that use reflective meddling),
>>> and also, for a fun of it, fastdebug builds.
>> 
>> Can you explain the fastdebug comment a bit?  Have we seen real issues or is this just a nice side-effect?
> 
> See the notes at the bottom:
> http://cr.openjdk.java.net/~shade/8150669/notes.txt

That?s good.  I wonder why this wasn?t intrinsified before.

One nit:  can we rename IsPrimitive.java to TestClassIsPrimitive.java?  Most of our tests are called Test* while support files have other names.  Not sure if we have a hard-convention on this but it certainly is nice and helpful sometimes.

> 
> Nice side-effect of not going through Java-to-native transition. The
> patch coincided with Zoltan trying to trim down on (fastdebug) testing
> time, so I mentioned that for fun.
> 
> -Aleksey
> 


From christian.thalinger at oracle.com  Mon Feb 29 22:42:29 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 29 Feb 2016 12:42:29 -1000
Subject: RFR (S) 8146801: Allocating short arrays of non-constant size is
	slow
In-Reply-To: <56D4C500.20100@oracle.com>
References: <56D4B1F7.4040201@oracle.com>
	
	<56D4C500.20100@oracle.com>
Message-ID: <400E2369-DB6B-4BD2-84A0-586D95705F7C@oracle.com>


> On Feb 29, 2016, at 12:24 PM, Aleksey Shipilev  wrote:
> 
> On 03/01/2016 12:53 AM, Christian Thalinger wrote:
>>> On Feb 29, 2016, at 11:02 AM, Aleksey Shipilev
>> +  product_pd(intx, InitArrayShortSize,                                
>>     \
>> 
>> Don?t make it a product flag; diagnostic should be sufficient.  This
>> will require adding diagnostic_pd support.  If you don?t want to do that
>> make the flag develop.
> 
> Okay, develop_pd now:
>  http://cr.openjdk.java.net/~shade/8146801/webrev.03/

+define_pd_global(intx, InitArrayShortSize,           18*BytesPerLong);

Can you remove the spaces in all files?  Otherwise this looks good.

> 
> diagnostic_pd would certainly be nice to have, but I don't really want
> to get even deeper into this rabbit hole.

?which I understand.  We should file a starter Enhancement.

> 
> Thanks,
> -Aleksey
> 


From aleksey.shipilev at oracle.com  Mon Feb 29 22:59:14 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 1 Mar 2016 01:59:14 +0300
Subject: RFR (S) 8150669: C1 intrinsic for Class.isPrimitive
In-Reply-To: <4AAA9FF6-99A5-47F4-B707-0C6E0CB2D3BC@oracle.com>
References: <56CF6A7E.7080204@oracle.com>
	
	<56D4BF23.2070308@oracle.com>
	<4AAA9FF6-99A5-47F4-B707-0C6E0CB2D3BC@oracle.com>
Message-ID: <56D4CD42.2050101@oracle.com>

On 03/01/2016 01:35 AM, Christian Thalinger wrote:
>> On Feb 29, 2016, at 11:58 AM, Aleksey Shipilev
>>  wrote: See the notes at the bottom: 
>> http://cr.openjdk.java.net/~shade/8150669/notes.txt
> 
> That?s good.  I wonder why this wasn?t intrinsified before.

Yup, puzzled me too.

> One nit:  can we rename IsPrimitive.java to
> TestClassIsPrimitive.java?  Most of our tests are called Test* while
> support files have other names.  Not sure if we have a
> hard-convention on this but it certainly is nice and helpful
> sometimes.

Yes, we can:
 http://cr.openjdk.java.net/~shade/8150669/webrev.02/

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From aleksey.shipilev at oracle.com  Mon Feb 29 23:19:02 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 1 Mar 2016 02:19:02 +0300
Subject: RFR (S) 8146801: Allocating short arrays of non-constant size is
	slow
In-Reply-To: <400E2369-DB6B-4BD2-84A0-586D95705F7C@oracle.com>
References: <56D4B1F7.4040201@oracle.com>
	
	<56D4C500.20100@oracle.com>
	<400E2369-DB6B-4BD2-84A0-586D95705F7C@oracle.com>
Message-ID: <56D4D1E6.1090809@oracle.com>

On 03/01/2016 01:42 AM, Christian Thalinger wrote:
>> On Feb 29, 2016, at 12:24 PM, Aleksey Shipilev  wrote:
>> On 03/01/2016 12:53 AM, Christian Thalinger wrote:
>>>> On Feb 29, 2016, at 11:02 AM, Aleksey Shipilev
>>> +  product_pd(intx, InitArrayShortSize,                                
>>>     \
>>>
>>> Don?t make it a product flag; diagnostic should be sufficient.  This
>>> will require adding diagnostic_pd support.  If you don?t want to do that
>>> make the flag develop.
>>
>> Okay, develop_pd now:
>>  http://cr.openjdk.java.net/~shade/8146801/webrev.03/
> 
> +define_pd_global(intx, InitArrayShortSize,           18*BytesPerLong);
> 
> Can you remove the spaces in all files?  Otherwise this looks good.

Yup:
  http://cr.openjdk.java.net/~shade/8146801/webrev.04/

>> diagnostic_pd would certainly be nice to have, but I don't really want
>> to get even deeper into this rabbit hole.
> 
> ?which I understand.  We should file a starter Enhancement.

Here:
  https://bugs.openjdk.java.net/browse/JDK-8150900

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: 

From nileema.shingte at gmail.com  Mon Feb 29 22:59:53 2016
From: nileema.shingte at gmail.com (nileema)
Date: Mon, 29 Feb 2016 15:59:53 -0700 (MST)
Subject: JIT stops compiling after a while (java 8u45)
Message-ID: <1456786793750-259603.post@n7.nabble.com>

We are seeing an issue with the CodeCache becoming full which causes the
compiler to be disabled in jdk-8u45 to jdk-8u72. 

We had seen a similar issue in Java7 (old issue:
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-August/011333.html).
This issue went away with earlier versions of Java 8.

We used the test http://github.com/martint/jittest to compare the behavior
of jdk-8u25 and jdk-8u45. For this test, we did not see any CodeCache full
messages with jdk-8u25  but did see them with 8u45+ (8u60  and 8u74)

Test results comparing 8u25, 8u45 and 8u74:
https://gist.github.com/nileema/6fb667a215e95919242f

In the results you can see that 8u25 starts collecting the code cache much
sooner than 8u45. 8u45 very quickly hits the limit for code cache. If we
force a full gc when it is about to hit the code cache limit, we see the
code cache size go down. 

Is this a known issue? 

Thanks! 

Nileema



--
View this message in context: http://openjdk.5641.n7.nabble.com/JIT-stops-compiling-after-a-while-java-8u45-tp259603.html
Sent from the OpenJDK Hotspot Compiler Development List mailing list archive at Nabble.com.