From tobias.hartmann at oracle.com Wed Jun 1 05:48:10 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 1 Jun 2016 07:48:10 +0200 Subject: [9] RFR(XS): 8157842: indexOfChar intrinsic is not emitted on x86 In-Reply-To: <6945f503-10c7-f22c-c2ed-93f8844535b4@oracle.com> References: <574C228E.6050108@oracle.com> <2df2a2b0-f903-d0a9-16c9-4be0701fdeb0@oracle.com> <574D5A3A.1010101@oracle.com> <6945f503-10c7-f22c-c2ed-93f8844535b4@oracle.com> Message-ID: <574E771A.4030404@oracle.com> Thanks, Vladimir! Best regards, Tobias On 31.05.2016 20:04, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 5/31/16 2:32 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> On 30.05.2016 19:45, Vladimir Kozlov wrote: >>> match_rule_supported() should check UseSSE42Intrinsics instead since it is used in predicate: >>> >>> predicate(UseSSE42Intrinsics); >>> match(Set result (StrIndexOfChar (Binary str1 cnt1) ch)); >> >> Right, checking for UseSSE42Intrinsics is more consistent. >> >>> Also we can remove "assert(UseSSE >= 4" in MacroAssembler::string_indexof_char() because UseSSE42Intrinsics will be false if UseSSE < 4. See code in vm_version_x86.cpp >> >> Okay, I also removed the same checks from the other string intrinsics. >> >> Here's the new webrev: >> http://cr.openjdk.java.net/~thartmann/8157842/webrev.01/ >> >> While testing I noticed that the VM crashes if UseSSE < 4 is set. I filed JDK-8158214. >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8158214 >> >>> >>> Thanks, >>> Vladimir >>> >>> On 5/30/16 4:22 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8157842 >>>> http://cr.openjdk.java.net/~thartmann/8157842/webrev.00/ >>>> >>>> Andrew Haley noticed that there is a typo in x86.ad that prevents the StrIndexOfChar intrinsic from being emitted [1]. The problem is that we check for UseSSE > 4 instead of UseSSE >= 4 in Matcher::match_rule_supported() on x86. >>>> >>>> Tested with JPRT, RBT is running. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/023218.html >>>> From jamsheed.c.m at oracle.com Wed Jun 1 11:33:16 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 1 Jun 2016 17:03:16 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> Message-ID: <89a56cc4-f8df-fb2f-1c6d-c3e4866724e6@oracle.com> Hi Roland, and All, earlier implementation was not correct! i have updated the patch in place. Please review. Best Regards, Jamsheed On 5/31/2016 4:36 PM, Jamsheed C m wrote: > Hi Roland, and All, > > I have made shared only change. > > Revised webrev: http://cr.openjdk.java.net/~jcm/8146416/webrev.01/ > > Best Regards, > > Jamsheed > > > On 5/27/2016 7:56 PM, Jamsheed C m wrote: >> some of the code that may require change >> >> this is based on quick grep result.. not based on analysis >> >> ... >> guarantee(!(thread->deopt_nmethod()->is_compiled_by_c2() && >> *bcp == Bytecodes::_monitorenter && >> exec_mode == Deoptimization::Unpack_exception), >> "shouldn't get exception during monitorenter"); >> >> ... >> } else if (JvmtiExport::can_force_early_return() && state != NULL >> && state->is_earlyret_pending()) { >> >> ... >> >> (is_top_frame && (exec_mode == Unpack_exception) && >> iframe->interpreter_frame_expression_stack_size() == 0) || >> >> >> Best Regards, >> Jamsheed >> On 5/27/2016 2:52 PM, Jamsheed C m wrote: >>> My concern is like adding checks in shared code, would reduce >>> readability still further.. >>> >>> for platform change its simple check and forward change, a detailed >>> comment would do! >>> >>> Best Regards, >>> Jamsheed >>> >>> On 5/27/2016 1:13 PM, Roland Westrelin wrote: >>>> Hi Jamsheed, >>>> >>>>> can i go ahead with this change ? >>>> I still think a shared code only change would be better (unless you >>>> demonstrate a reasonable shared code change is not possible). What do >>>> others think? >>>> >>>> Roland. >>> >> > From tobias.hartmann at oracle.com Wed Jun 1 12:12:47 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 1 Jun 2016 14:12:47 +0200 Subject: [9] RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays Message-ID: <574ED13F.1050003@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8158228 http://cr.openjdk.java.net/~thartmann/8158228/webrev.00/ Multiple tests fail since JDK 9 b110 because String.charAt() returns a wrong value for a constant string. In b110, JDK-8143407 [1] enabled C1 to constant fold stable array elements and since JDK-8150180 [2] String.value is constant. The problem is that C1 does not correctly fold mismatched loads from stable arrays. In this case, String.value is a stable byte[] and StringUTF16.charAt() is intrinsified as char load. Instead of a char load, C1 emits a byte load because it does not check for mismatched loads. I fixed this by passing the BasicType of the mismatched load to ciArray::element_value() to ensure the correct constant is emitted. I verified that both 'Lex06403.java' and 'NewTestCase.java' pass with the fix. Also tested with JPRT and RBT (running). Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8143407 [2] https://bugs.openjdk.java.net/browse/JDK-8150180 From jamsheed.c.m at oracle.com Wed Jun 1 12:23:47 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 1 Jun 2016 17:53:47 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <89a56cc4-f8df-fb2f-1c6d-c3e4866724e6@oracle.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <89a56cc4-f8df-fb2f-1c6d-c3e4866724e6@oracle.com> Message-ID: <829625f0-07ab-aa79-7631-abb723755f80@oracle.com> with this fix, i need to skip verify (exception) oop in Interpreter::_rethrow_exception_entry for realloc failure case.(as in uncommon_trap case current implementation doesn't support exception handling) this is platform specific change, let me know if i can do that. Best Regards, Jamsheed On 6/1/2016 5:03 PM, Jamsheed C m wrote: > Hi Roland, and All, > > earlier implementation was not correct! > > i have updated the patch in place. > > Please review. > > Best Regards, > > Jamsheed > > > On 5/31/2016 4:36 PM, Jamsheed C m wrote: >> Hi Roland, and All, >> >> I have made shared only change. >> >> Revised webrev: http://cr.openjdk.java.net/~jcm/8146416/webrev.01/ >> >> Best Regards, >> >> Jamsheed >> >> >> On 5/27/2016 7:56 PM, Jamsheed C m wrote: >>> some of the code that may require change >>> >>> this is based on quick grep result.. not based on analysis >>> >>> ... >>> guarantee(!(thread->deopt_nmethod()->is_compiled_by_c2() && >>> *bcp == Bytecodes::_monitorenter && >>> exec_mode == Deoptimization::Unpack_exception), >>> "shouldn't get exception during monitorenter"); >>> >>> ... >>> } else if (JvmtiExport::can_force_early_return() && state != >>> NULL && state->is_earlyret_pending()) { >>> >>> ... >>> >>> (is_top_frame && (exec_mode == Unpack_exception) && >>> iframe->interpreter_frame_expression_stack_size() == 0) || >>> >>> >>> Best Regards, >>> Jamsheed >>> On 5/27/2016 2:52 PM, Jamsheed C m wrote: >>>> My concern is like adding checks in shared code, would reduce >>>> readability still further.. >>>> >>>> for platform change its simple check and forward change, a detailed >>>> comment would do! >>>> >>>> Best Regards, >>>> Jamsheed >>>> >>>> On 5/27/2016 1:13 PM, Roland Westrelin wrote: >>>>> Hi Jamsheed, >>>>> >>>>>> can i go ahead with this change ? >>>>> I still think a shared code only change would be better (unless you >>>>> demonstrate a reasonable shared code change is not possible). What do >>>>> others think? >>>>> >>>>> Roland. >>>> >>> >> > From rwestrel at redhat.com Wed Jun 1 12:56:14 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 1 Jun 2016 14:56:14 +0200 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> Message-ID: <574EDB6E.2050401@redhat.com> Hi Jamsheed, > I have made shared only change. > > Revised webrev: http://cr.openjdk.java.net/~jcm/8146416/webrev.01/ Thanks for putting a shared only change together. I noticed you added a test case (DeoptReallocFailureUncommonTrap). Is that one expected to fail with the same assert as well? I tried it but it seems to run fine. Backing up a bit: the issue triggered by your other test case is that when the deoptimization mode is Unpack_exception, vframeArrayElement::unpack_on_stack() forces the return to the interpreter to not go through the deopt entries but straight to the exception handling code with a pending exception and that's what's causing the assert to fire, right? Can you explain in details what other issues you're trying to fix? Roland. > > Best Regards, > > Jamsheed > > > On 5/27/2016 7:56 PM, Jamsheed C m wrote: >> some of the code that may require change >> >> this is based on quick grep result.. not based on analysis >> >> ... >> guarantee(!(thread->deopt_nmethod()->is_compiled_by_c2() && >> *bcp == Bytecodes::_monitorenter && >> exec_mode == Deoptimization::Unpack_exception), >> "shouldn't get exception during monitorenter"); >> >> ... >> } else if (JvmtiExport::can_force_early_return() && state != NULL >> && state->is_earlyret_pending()) { >> >> ... >> >> (is_top_frame && (exec_mode == Unpack_exception) && >> iframe->interpreter_frame_expression_stack_size() == 0) || >> >> >> Best Regards, >> Jamsheed >> On 5/27/2016 2:52 PM, Jamsheed C m wrote: >>> My concern is like adding checks in shared code, would reduce >>> readability still further.. >>> >>> for platform change its simple check and forward change, a detailed >>> comment would do! >>> >>> Best Regards, >>> Jamsheed >>> >>> On 5/27/2016 1:13 PM, Roland Westrelin wrote: >>>> Hi Jamsheed, >>>> >>>>> can i go ahead with this change ? >>>> I still think a shared code only change would be better (unless you >>>> demonstrate a reasonable shared code change is not possible). What do >>>> others think? >>>> >>>> Roland. >>> >> > From jamsheed.c.m at oracle.com Wed Jun 1 13:19:37 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 1 Jun 2016 18:49:37 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <574EDB6E.2050401@redhat.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> Message-ID: <441aa477-df1d-d32c-19f0-7abf3b1146b9@oracle.com> Hi Roland, On 6/1/2016 6:26 PM, Roland Westrelin wrote: > I noticed you added a > test case (DeoptReallocFailureUncommonTrap). Is that one expected to > fail with the same assert as well? I tried it but it seems to run fine. no its not expected to give same assert. as exception handling and poping will not work as in case of non uncommon_trap case. uncommon_trap case don't have exception handling and return pc is never set to Interpreter::_rethrow_exception_entry. so normal execution will continue with (failed realloc) interpreter frames. classloading will be triggered here in failed realloc execution. may be it will again throw exception, which clears pending_exception field and rethrow. may be poping starts here(whihc will work fine) but incorrect. > Backing up a bit: the issue triggered by your other test case is that > when the deoptimization mode is Unpack_exception, > vframeArrayElement::unpack_on_stack() forces the return to the > interpreter to not go through the deopt entries but straight to the > exception handling code with a pending exception and that's what's > causing the assert to fire, right? no, it goes through deopt entries , but as pending exception is set return from InterpreterRuntime::exception_handler_for_exception forwards exception again to Interpreter::_rethrow_exception_entry. at this point *do_not_unlock_if_synchronized is set, pop_count is decremented by one*. so same deopt frame will again come in rethrow_exception_handler context with frames_to_pop_failed_realloc none. this will go for normal handling, with *do_not_unlock_if_synchronized is set. which throws assert. Best Regards, Jamsheed * -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Wed Jun 1 13:38:47 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 1 Jun 2016 16:38:47 +0300 Subject: [9] RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays In-Reply-To: <574ED13F.1050003@oracle.com> References: <574ED13F.1050003@oracle.com> Message-ID: <51074461-132f-c775-bfe5-d6488cca099a@oracle.com> Tobias, Thanks for taking care of the bug. > https://bugs.openjdk.java.net/browse/JDK-8158228 > http://cr.openjdk.java.net/~thartmann/8158228/webrev.00/ > > Multiple tests fail since JDK 9 b110 because String.charAt() returns a wrong value for a constant string. In b110, JDK-8143407 [1] enabled C1 to constant fold stable array elements and since JDK-8150180 [2] String.value is constant. The problem is that C1 does not correctly fold mismatched loads from stable arrays. In this case, String.value is a stable byte[] and StringUTF16.charAt() is intrinsified as char load. Instead of a char load, C1 emits a byte load because it does not check for mismatched loads. > > I fixed this by passing the BasicType of the mismatched load to ciArray::element_value() to ensure the correct constant is emitted. I verified that both 'Lex06403.java' and 'NewTestCase.java' pass with the fix. Also tested with JPRT and RBT (running). As I understand the only source of mismatched accesses are String intrinsics (getCharStringU/putCharStringU). (Unsafe accesses are the main source of mismatched accesses, but C1 doesn't optimize them). Can you issue UnsafeObjectOp instead of LoadIndexed/StoreIndexed in GraphBuilder::append_char_access or does C1 produce less efficient code for unsafe accesses? Otherwise, I suggest to mark LoadIndexed/StoreIndexed as mismatched (or introduce UnsafeLoadIndexed/UnsafeStoreIndexed node) and check that in Canonicalizer::do_LoadIndexed. Mismatch detection is more complex than just comparing basic types (see Type::make_constant_from_array_element() & check_mismatched_access(), though some checks are C2-specific). Since C1 doesn't optimize unsafe accesses, I suggest to confine the fix to String intrinsics. Best regards, Vladimir Ivanov > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8143407 > [2] https://bugs.openjdk.java.net/browse/JDK-8150180 From rwestrel at redhat.com Wed Jun 1 13:55:28 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 1 Jun 2016 15:55:28 +0200 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <441aa477-df1d-d32c-19f0-7abf3b1146b9@oracle.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <441aa477-df1d-d32c-19f0-7abf3b1146b9@oracle.com> Message-ID: <574EE950.10508@redhat.com> >> I noticed you added a >> test case (DeoptReallocFailureUncommonTrap). Is that one expected to >> fail with the same assert as well? I tried it but it seems to run fine. > no its not expected to give same assert. as exception handling and > poping will not work as in case of non uncommon_trap case. > > uncommon_trap case don't have exception handling and return pc is never > set to Interpreter::_rethrow_exception_entry. so normal execution will > continue with (failed realloc) interpreter frames. > > classloading will be triggered here in failed realloc execution. may be > it will again throw exception, which clears pending_exception field and > rethrow. may be poping starts here(whihc will work fine) but incorrect. So is the test expected to fail at all? Is the failure intermittent? And the problem this test triggers is that class loading clears the pending exception? Roland. From tobias.hartmann at oracle.com Wed Jun 1 14:03:11 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 1 Jun 2016 16:03:11 +0200 Subject: [9] RFR(S): 8158214: Crash with "assert(VM_Version::supports_sse4_1()) failed" if UseSSE < 4 is set In-Reply-To: <92b567c1-5c3d-d37b-3a28-2fb8c379c1c9@oracle.com> References: <574D8817.70105@oracle.com> <92b567c1-5c3d-d37b-3a28-2fb8c379c1c9@oracle.com> Message-ID: <574EEB1F.5050008@oracle.com> Hi Vladimir, thanks for the review! On 31.05.2016 19:48, Vladimir Kozlov wrote: > Is it only pinsrd instruction requires sse4.1? I looked on crc32 code and we can use pinsrw instruction with shift: > > if (supports_sse4_1()) { > pinsrd(xmm1, crc, 0); > } else { > pinsrw(xmm1, crc, 0); > shrl(crc, 16); > pinsrw(xmm1, crc, 1); > } Right, 'pinsrd' is the only SSE 4.1 instruction in the crc32 code, so this works. Here's the new webrev: http://cr.openjdk.java.net/~thartmann/8158214/webrev.01/ Thanks, Tobias > Unfortunately UseAESCTRIntrinsics use more sse4.1 instructions so we can't do that. And it is already guarded by supports_sse4_1(). > > Changes which remove UseSSE checks in vm_version_x86.cpp are good. > > Thanks, > Vladimir > > > On 5/31/16 5:48 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> https://bugs.openjdk.java.net/browse/JDK-8158214 >> http://cr.openjdk.java.net/~thartmann/8158214/webrev.00/ >> >> The VM crashes during stub generation if UseSSE = 3 is set. The problem is that even if SSE 4 is not available or disabled, MacroAssembler::kernel_crc32() emits the 'pinsrd' instruction which is a SSE 4.1 instruction. >> >> The solution is to only emit CRC32 intrinsics if SSE 4.1 is available (the UseSSE > 2 check is not strong enough). I also removed the unnecessary UseSSE >= 4 checks because they are included in the supports_sse4_2() check. >> >> Tested with JPRT and RBT (running). >> >> Thanks, >> Tobias >> From jamsheed.c.m at oracle.com Wed Jun 1 14:14:16 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 1 Jun 2016 19:44:16 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <441aa477-df1d-d32c-19f0-7abf3b1146b9@oracle.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <441aa477-df1d-d32c-19f0-7abf3b1146b9@oracle.com> Message-ID: Hi Roland, On 6/1/2016 6:49 PM, Jamsheed C m wrote: > Backing up a bit: the issue triggered by your other test case is that > when the deoptimization mode is Unpack_exception, > vframeArrayElement::unpack_on_stack() forces the return to the > interpreter to not go through the deopt entries but straight to the > exception handling code with a pending exception and that's what's > causing the assert to fire, right? i am not sure whether i understood your question correctly. returning to deopt_entries with pending exception is not allowed in present code. going directly to rethrow_exception_handler with pending exception too is not expected in present code for normal conditions. my latest fix is a special case. and handles pending_exception gracefully. so its fine i guess. i went with this approach, as uncomon_trap has no means to throw exception without a platform change. Best Regards, Jamsheed From rwestrel at redhat.com Wed Jun 1 14:16:38 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 1 Jun 2016 16:16:38 +0200 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <441aa477-df1d-d32c-19f0-7abf3b1146b9@oracle.com> Message-ID: <574EEE46.3070801@redhat.com> > i am not sure whether i understood your question correctly. I'm trying to understand how many problems you've identified and are fixing. Is it only the deoptimization with Unpack_exception or is there another one? Given you've added another test case, I suppose there's another one so I'd like to understand what that other problem is. Roland. From paul.sandoz at oracle.com Wed Jun 1 14:17:24 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 1 Jun 2016 16:17:24 +0200 Subject: Java shared memory In-Reply-To: <808B4C05-4F65-4DD4-9E12-49423A84CC0A@gmail.com> References: <6B8F88FE-24AF-40E6-96DE-D7443667DA47@gmail.com> <574C9E41.30302@redhat.com> <808B4C05-4F65-4DD4-9E12-49423A84CC0A@gmail.com> Message-ID: Hi Radek, > On 31 May 2016, at 12:44, Radek wrote: > > Dear Paul and Adrew, > > Indeed I?ve messed up with a coping long. I don?t know why I have done it, as my first approach actually involved buff.getLong(). I?ve took, as well, closer look at my tests and right now I use JDK9 build 120, as a reference points. > > There is a performance gain (build 120 vs custom slow debug) but right now it?s 12%, not so huge. Maybe after code polishing and additional optimisation I could get 15-20%. > I am still skeptical, sorry. I strongly recommend writing JMH benchmarks, and also run with the perfasm option to produce the hot parts of the generated benchmarked code. Otherwise it?s hard to trust the results. But it?s hard to trust *any* performance results :-) using JMH makes it easier to evaluate. > I don?t know if in such a case my work could be interesting. > My suggestion is to look more closely at Panama, there might be some synergy and reuse of what you are learned in HotSpot. Paul. > Best regards, > Radek > PS Attached please find latest results, the MappedByteBuffer case uses for (int i=0; i < mbuff.limit(); i+=8) loop. > -------------- 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 jamsheed.c.m at oracle.com Wed Jun 1 14:27:49 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 1 Jun 2016 19:57:49 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <574EEE46.3070801@redhat.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <441aa477-df1d-d32c-19f0-7abf3b1146b9@oracle.com> <574EEE46.3070801@redhat.com> Message-ID: <0f892327-8f6b-8064-c82f-c6a6e2e38a08@oracle.com> On 6/1/2016 7:46 PM, Roland Westrelin wrote: >> i am not sure whether i understood your question correctly. > I'm trying to understand how many problems you've identified and are > fixing. Is it only the deoptimization with Unpack_exception or is there > another one? Given you've added another test case, I suppose there's > another one so I'd like to understand what that other problem is. realloc failure can happen for all kind of deoptimization, i am addressing all cases. Best Regards, Jamsheed > Roland. From rwestrel at redhat.com Wed Jun 1 14:31:26 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 1 Jun 2016 16:31:26 +0200 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <0f892327-8f6b-8064-c82f-c6a6e2e38a08@oracle.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <441aa477-df1d-d32c-19f0-7abf3b1146b9@oracle.com> <574EEE46.3070801@redhat.com> <0f892327-8f6b-8064-c82f-c6a6e2e38a08@oracle.com> Message-ID: <574EF1BE.3080604@redhat.com> >>> i am not sure whether i understood your question correctly. >> I'm trying to understand how many problems you've identified and are >> fixing. Is it only the deoptimization with Unpack_exception or is there >> another one? Given you've added another test case, I suppose there's >> another one so I'd like to understand what that other problem is. > realloc failure can happen for all kind of deoptimization, i am > addressing all cases. It's already addressed now. It was added by 6898462. What this bug shows is that it doesn't work in all cases. I'd like to know what cases are not covered. Is it only Unpack_exception or is there another one? Roland. From jamsheed.c.m at oracle.com Wed Jun 1 14:33:42 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 1 Jun 2016 20:03:42 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <574EF1BE.3080604@redhat.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <441aa477-df1d-d32c-19f0-7abf3b1146b9@oracle.com> <574EEE46.3070801@redhat.com> <0f892327-8f6b-8064-c82f-c6a6e2e38a08@oracle.com> <574EF1BE.3080604@redhat.com> Message-ID: On 6/1/2016 8:01 PM, Roland Westrelin wrote: >>>> i am not sure whether i understood your question correctly. >>> I'm trying to understand how many problems you've identified and are >>> fixing. Is it only the deoptimization with Unpack_exception or is there >>> another one? Given you've added another test case, I suppose there's >>> another one so I'd like to understand what that other problem is. >> realloc failure can happen for all kind of deoptimization, i am >> addressing all cases. > It's already addressed now. It was added by 6898462. What this bug shows > is that it doesn't work in all cases. I'd like to know what cases are > not covered. Is it only Unpack_exception or is there another one? 1) Unpack_exception 2) deopt without unpack_exception( i didnt write a test case for this) 3) Uncommon_trap Best Regards, Jamsheed > > Roland. From vladimir.kozlov at oracle.com Wed Jun 1 16:20:46 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Jun 2016 09:20:46 -0700 Subject: [9] RFR(S): 8158214: Crash with "assert(VM_Version::supports_sse4_1()) failed" if UseSSE < 4 is set In-Reply-To: <574EEB1F.5050008@oracle.com> References: <574D8817.70105@oracle.com> <92b567c1-5c3d-d37b-3a28-2fb8c379c1c9@oracle.com> <574EEB1F.5050008@oracle.com> Message-ID: <872a0edc-9ddf-5e45-ff07-b92f2f4819c5@oracle.com> Looks good. Thanks, Vladimir On 6/1/16 7:03 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review! > > On 31.05.2016 19:48, Vladimir Kozlov wrote: >> Is it only pinsrd instruction requires sse4.1? I looked on crc32 code and we can use pinsrw instruction with shift: >> >> if (supports_sse4_1()) { >> pinsrd(xmm1, crc, 0); >> } else { >> pinsrw(xmm1, crc, 0); >> shrl(crc, 16); >> pinsrw(xmm1, crc, 1); >> } > > Right, 'pinsrd' is the only SSE 4.1 instruction in the crc32 code, so this works. > > Here's the new webrev: > http://cr.openjdk.java.net/~thartmann/8158214/webrev.01/ > > Thanks, > Tobias > >> Unfortunately UseAESCTRIntrinsics use more sse4.1 instructions so we can't do that. And it is already guarded by supports_sse4_1(). >> >> Changes which remove UseSSE checks in vm_version_x86.cpp are good. >> >> Thanks, >> Vladimir >> >> >> On 5/31/16 5:48 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8158214 >>> http://cr.openjdk.java.net/~thartmann/8158214/webrev.00/ >>> >>> The VM crashes during stub generation if UseSSE = 3 is set. The problem is that even if SSE 4 is not available or disabled, MacroAssembler::kernel_crc32() emits the 'pinsrd' instruction which is a SSE 4.1 instruction. >>> >>> The solution is to only emit CRC32 intrinsics if SSE 4.1 is available (the UseSSE > 2 check is not strong enough). I also removed the unnecessary UseSSE >= 4 checks because they are included in the supports_sse4_2() check. >>> >>> Tested with JPRT and RBT (running). >>> >>> Thanks, >>> Tobias >>> From rwestrel at redhat.com Wed Jun 1 16:25:45 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 1 Jun 2016 18:25:45 +0200 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <441aa477-df1d-d32c-19f0-7abf3b1146b9@oracle.com> <574EEE46.3070801@redhat.com> <0f892327-8f6b-8064-c82f-c6a6e2e38a08@oracle.com> <574EF1BE.3080604@redhat.com> Message-ID: <574F0C89.90005@redhat.com> >> It's already addressed now. It was added by 6898462. What this bug shows >> is that it doesn't work in all cases. I'd like to know what cases are >> not covered. Is it only Unpack_exception or is there another one? > 1) Unpack_exception > 2) deopt without unpack_exception( i didnt write a test case for this) > 3) Uncommon_trap What I see from the code of vframeArrayElement::unpack_on_stack(): case Deoptimization::Unpack_uncommon_trap: case Deoptimization::Unpack_reexecute: // redo last byte code pc = Interpreter::deopt_entry(vtos, 0); both Unpack_uncommon_trap/Unpack_reexecute are fine. Unpack_exception is always a problem because it doesn't return to a deopt entry. Unpack_deopt is sometimes a problem because it doesn't return to a deopt entry, sometimes (for bytecodes return and athrow). Roland. From jamsheed.c.m at oracle.com Wed Jun 1 17:29:14 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 1 Jun 2016 22:59:14 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <574EDB6E.2050401@redhat.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> Message-ID: <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> Hi Roland, On 6/1/2016 6:26 PM, Roland Westrelin wrote: > noticed you added a > test case (DeoptReallocFailureUncommonTrap). Is that one expected to > fail with the same assert as well? I tried it but it seems to run fine. > > Backing up a bit: the issue triggered by your other test case is that > when the deoptimization mode is Unpack_exception, > vframeArrayElement::unpack_on_stack() forces the return to the > interpreter to not go through the deopt entries but straight to the > exception handling code with a pending exception and that's what's > causing the assert to fire, right? you are right, it works fine due to deopt_entry pending exception handling.. i had looked at this earlier, and just forgot about this due to this comment IRT_ENTRY(void, InterpreterRuntime::throw_pending_exception(JavaThread* thread)) assert(thread->has_pending_exception(), "must only ne called if there's an exception pending"); // nothing to do - eventually we should remove this code entirely (see comments @ call sites) IRT_END Yes you are right, making all deopt realloc failure cases to take this path is probably right thing to do. may be we should move the pending exception code a bit up (above jvmci locking code) also remove this comment " // nothing to do - eventually we should remove this code entirely (see comments @ call sites)" too.. Best Regards, Jamsheed From doug.simon at oracle.com Wed Jun 1 22:21:01 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 2 Jun 2016 00:21:01 +0200 Subject: RFR(XS): 8158351: [JVMCI] NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI Message-ID: <5091E2EA-C1CF-42FB-9736-5D14CEEA34E7@oracle.com> Please review this trivial test bug fix. https://bugs.openjdk.java.net/browse/JDK-8158351 http://cr.openjdk.java.net/~dnsimon/8158351/ -Doug From tobias.hartmann at oracle.com Thu Jun 2 06:10:26 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 2 Jun 2016 08:10:26 +0200 Subject: [9] RFR(S): 8158214: Crash with "assert(VM_Version::supports_sse4_1()) failed" if UseSSE < 4 is set In-Reply-To: <872a0edc-9ddf-5e45-ff07-b92f2f4819c5@oracle.com> References: <574D8817.70105@oracle.com> <92b567c1-5c3d-d37b-3a28-2fb8c379c1c9@oracle.com> <574EEB1F.5050008@oracle.com> <872a0edc-9ddf-5e45-ff07-b92f2f4819c5@oracle.com> Message-ID: <574FCDD2.2070804@oracle.com> Thanks, Vladimir! Best regards, Tobias On 01.06.2016 18:20, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 6/1/16 7:03 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> On 31.05.2016 19:48, Vladimir Kozlov wrote: >>> Is it only pinsrd instruction requires sse4.1? I looked on crc32 code and we can use pinsrw instruction with shift: >>> >>> if (supports_sse4_1()) { >>> pinsrd(xmm1, crc, 0); >>> } else { >>> pinsrw(xmm1, crc, 0); >>> shrl(crc, 16); >>> pinsrw(xmm1, crc, 1); >>> } >> >> Right, 'pinsrd' is the only SSE 4.1 instruction in the crc32 code, so this works. >> >> Here's the new webrev: >> http://cr.openjdk.java.net/~thartmann/8158214/webrev.01/ >> >> Thanks, >> Tobias >> >>> Unfortunately UseAESCTRIntrinsics use more sse4.1 instructions so we can't do that. And it is already guarded by supports_sse4_1(). >>> >>> Changes which remove UseSSE checks in vm_version_x86.cpp are good. >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 5/31/16 5:48 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8158214 >>>> http://cr.openjdk.java.net/~thartmann/8158214/webrev.00/ >>>> >>>> The VM crashes during stub generation if UseSSE = 3 is set. The problem is that even if SSE 4 is not available or disabled, MacroAssembler::kernel_crc32() emits the 'pinsrd' instruction which is a SSE 4.1 instruction. >>>> >>>> The solution is to only emit CRC32 intrinsics if SSE 4.1 is available (the UseSSE > 2 check is not strong enough). I also removed the unnecessary UseSSE >= 4 checks because they are included in the supports_sse4_2() check. >>>> >>>> Tested with JPRT and RBT (running). >>>> >>>> Thanks, >>>> Tobias >>>> From rwestrel at redhat.com Thu Jun 2 07:33:51 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 02 Jun 2016 09:33:51 +0200 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> Message-ID: Hi Jamsheed, So given uncommon traps are unaffected and only deopts are, isn't the change below good enough? Roland. diff --git a/src/share/vm/runtime/deoptimization.cpp b/src/share/vm/runtime/deoptimization.cpp --- a/src/share/vm/runtime/deoptimization.cpp +++ b/src/share/vm/runtime/deoptimization.cpp @@ -497,6 +497,12 @@ exec_mode = Unpack_exception; } #endif + if (thread->frames_to_pop_failed_realloc() > 0) { + assert(thread->has_pending_exception(), "should have thrown OOME"); + thread->set_exception_oop(thread->pending_exception()); + thread->clear_pending_exception(); + exec_mode = Unpack_exception; + } UnrollBlock* info = new UnrollBlock(array->frame_size() * BytesPerWord, caller_adjustment * BytesPerWord, From jamsheed.c.m at oracle.com Thu Jun 2 07:36:07 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 2 Jun 2016 13:06:07 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> Message-ID: <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> Hi Roland On 6/2/2016 1:03 PM, Roland Westrelin wrote: > Hi Jamsheed, > > So given uncommon traps are unaffected and only deopts are, isn't the > change below good enough? uncommon traps are affected in JVMCI case. pending exception check is after jvmci lock code. Beest Regards Jamsheed > > Roland. > > diff --git a/src/share/vm/runtime/deoptimization.cpp b/src/share/vm/runtime/deoptimization.cpp > --- a/src/share/vm/runtime/deoptimization.cpp > +++ b/src/share/vm/runtime/deoptimization.cpp > @@ -497,6 +497,12 @@ > exec_mode = Unpack_exception; > } > #endif > + if (thread->frames_to_pop_failed_realloc() > 0) { > + assert(thread->has_pending_exception(), "should have thrown OOME"); > + thread->set_exception_oop(thread->pending_exception()); > + thread->clear_pending_exception(); > + exec_mode = Unpack_exception; > + } > > UnrollBlock* info = new UnrollBlock(array->frame_size() * BytesPerWord, > caller_adjustment * BytesPerWord, From nils.eliasson at oracle.com Thu Jun 2 08:04:45 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 2 Jun 2016 10:04:45 +0200 Subject: RFR: 8155638: Resource allocated BitMaps are often cleared twice In-Reply-To: <572C7621.7000001@oracle.com> References: <572C7621.7000001@oracle.com> Message-ID: <574FE89D.8070208@oracle.com> Hi Stefan, I prefer the reinitialize alternative in c1_linearscan.cpp. Please use that version. Reviewed. Thanks for fixing this! Nils On 2016-05-06 12:46, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove some redundant clearing of bitmaps. > > http://cr.openjdk.java.net/~stefank/8155638/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8155638 > > > It used to be the case that Resource allocated bitmaps were _not_ > cleared in the constructor, and that explicit calls to clear() were > needed. However, when G1 was open sourced all the Resource allocated > bitmaps were always cleared in the BitMap constructor: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/diff/37f87013dfd8/src/share/vm/utilities/bitMap.cpp > > > It's apparent that the lazy clearing of bitmaps was used to skip > clearing when it wasn't necessary. > > See, for example: > http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/c1/c1_IR.cpp.udiff.html > > where _requires_phi_function is cleared even when all bits are going > to be set to 1. > > and: > http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/compiler/methodLiveness.cpp.frames.html > > in MethodLiveness::BasicBlock::get_liveness_at > > 1010 ResourceBitMap g(_gen.size()); g.set_from(_gen); > 1011 ResourceBitMap k(_kill.size()); k.set_from(_kill); > > where we first clear the bitmap, then copy all bits with set_from. > Before G1 was introduced, the unnecessary clearing was not done. > > I've created a new CR for these kind of issues: > > https://bugs.openjdk.java.net/browse/JDK-8156207 - Resource allocated > BitMaps are often cleared unnecessarily > > > During the review of "8141501: Problems with BitMap buffer > management", I got the request do the following change: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/022969.html > > I tried it, but felt that the change didn't fit the surrounding code, > where shallow-copying was used for other bitmaps. It would be great if > reviewers of this patch could decide if I should change the code as > suggested. > > > Thanks, > StefanK > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwestrel at redhat.com Thu Jun 2 08:17:23 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 02 Jun 2016 10:17:23 +0200 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> Message-ID: >> So given uncommon traps are unaffected and only deopts are, isn't the >> change below good enough? > uncommon traps are affected in JVMCI case. pending exception check is > after jvmci lock code. That code in TemplateInterpreterGenerator::generate_deopt_entry_for()? #if INCLUDE_JVMCI // Check if we need to take lock at entry of synchronized method. if (UseJVMCICompiler) { Label L; __ cmpb(Address(thread, JavaThread::pending_monitorenter_offset()), 0); __ jcc(Assembler::zero, L); // Clear flag. __ movb(Address(thread, JavaThread::pending_monitorenter_offset()), 0); // Satisfy calling convention for lock_method(). __ get_method(rbx); // Take lock. lock_method(); __ bind(L); } #endif Roland. From nils.eliasson at oracle.com Thu Jun 2 08:23:48 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 2 Jun 2016 10:23:48 +0200 Subject: RFR: 8155638: Resource allocated BitMaps are often cleared twice In-Reply-To: <574FE89D.8070208@oracle.com> References: <572C7621.7000001@oracle.com> <574FE89D.8070208@oracle.com> Message-ID: <574FED14.4010404@oracle.com> Hi, After some additional discussions with Stefan we concluded that it is better to keep the non-reinitialize version. There is the future possiblity of reusing the bitmap in every iteration in this loop, but reinitalize doesn't do that at the moment. And more testing would be required for such a change. Regards, Nils Eliasson On 2016-06-02 10:04, Nils Eliasson wrote: > Hi Stefan, > > I prefer the reinitialize alternative in c1_linearscan.cpp. Please use > that version. > > Reviewed. > > Thanks for fixing this! > Nils > > > On 2016-05-06 12:46, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to remove some redundant clearing of bitmaps. >> >> http://cr.openjdk.java.net/~stefank/8155638/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8155638 >> >> >> It used to be the case that Resource allocated bitmaps were _not_ >> cleared in the constructor, and that explicit calls to clear() were >> needed. However, when G1 was open sourced all the Resource allocated >> bitmaps were always cleared in the BitMap constructor: >> >> http://hg.openjdk.java.net/jdk9/hs/hotspot/diff/37f87013dfd8/src/share/vm/utilities/bitMap.cpp >> >> >> It's apparent that the lazy clearing of bitmaps was used to skip >> clearing when it wasn't necessary. >> >> See, for example: >> http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/c1/c1_IR.cpp.udiff.html >> >> where _requires_phi_function is cleared even when all bits are going >> to be set to 1. >> >> and: >> http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/compiler/methodLiveness.cpp.frames.html >> >> in MethodLiveness::BasicBlock::get_liveness_at >> >> 1010 ResourceBitMap g(_gen.size()); g.set_from(_gen); >> 1011 ResourceBitMap k(_kill.size()); k.set_from(_kill); >> >> where we first clear the bitmap, then copy all bits with set_from. >> Before G1 was introduced, the unnecessary clearing was not done. >> >> I've created a new CR for these kind of issues: >> >> https://bugs.openjdk.java.net/browse/JDK-8156207 - Resource allocated >> BitMaps are often cleared unnecessarily >> >> >> During the review of "8141501: Problems with BitMap buffer >> management", I got the request do the following change: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/022969.html >> >> I tried it, but felt that the change didn't fit the surrounding code, >> where shallow-copying was used for other bitmaps. It would be great >> if reviewers of this patch could decide if I should change the code >> as suggested. >> >> >> Thanks, >> StefanK >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Thu Jun 2 08:46:57 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 2 Jun 2016 14:16:57 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> Message-ID: On 6/2/2016 1:47 PM, Roland Westrelin wrote: >>> So given uncommon traps are unaffected and only deopts are, isn't the >>> change below good enough? >> uncommon traps are affected in JVMCI case. pending exception check is >> after jvmci lock code. > That code in TemplateInterpreterGenerator::generate_deopt_entry_for()? > > #if INCLUDE_JVMCI > // Check if we need to take lock at entry of synchronized method. > if (UseJVMCICompiler) { > Label L; > __ cmpb(Address(thread, JavaThread::pending_monitorenter_offset()), 0); > __ jcc(Assembler::zero, L); > // Clear flag. > __ movb(Address(thread, JavaThread::pending_monitorenter_offset()), 0); > // Satisfy calling convention for lock_method(). > __ get_method(rbx); > // Take lock. > lock_method(); > __ bind(L); > } > #endif Yes. Best Regards, Jamsheed > > Roland. From rwestrel at redhat.com Thu Jun 2 08:56:23 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 02 Jun 2016 10:56:23 +0200 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: References: <57453D5A.1080000@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> Message-ID: >>>> So given uncommon traps are unaffected and only deopts are, isn't the >>>> change below good enough? >>> uncommon traps are affected in JVMCI case. pending exception check is >>> after jvmci lock code. >> That code in TemplateInterpreterGenerator::generate_deopt_entry_for()? >> >> #if INCLUDE_JVMCI >> // Check if we need to take lock at entry of synchronized method. >> if (UseJVMCICompiler) { >> Label L; >> __ cmpb(Address(thread, JavaThread::pending_monitorenter_offset()), 0); >> __ jcc(Assembler::zero, L); >> // Clear flag. >> __ movb(Address(thread, JavaThread::pending_monitorenter_offset()), 0); >> // Satisfy calling convention for lock_method(). >> __ get_method(rbx); >> // Take lock. >> lock_method(); >> __ bind(L); >> } >> #endif > Yes. Can't we simply clear pending_monitorenter, for instance in Deoptimization::pop_frames_failed_reallocs? Roland. diff --git a/src/share/vm/runtime/deoptimization.cpp b/src/share/vm/runtime/deoptimization.cpp --- a/src/share/vm/runtime/deoptimization.cpp +++ b/src/share/vm/runtime/deoptimization.cpp @@ -497,6 +497,12 @@ exec_mode = Unpack_exception; } #endif + if (thread->frames_to_pop_failed_realloc() > 0) { + assert(thread->has_pending_exception(), "should have thrown OOME"); + thread->set_exception_oop(thread->pending_exception()); + thread->clear_pending_exception(); + exec_mode = Unpack_exception; + } UnrollBlock* info = new UnrollBlock(array->frame_size() * BytesPerWord, caller_adjustment * BytesPerWord, @@ -1228,6 +1234,7 @@ #endif } } + thread->set_pending_monitorenter(false); } #endif From jamsheed.c.m at oracle.com Thu Jun 2 08:59:04 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 2 Jun 2016 14:29:04 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: References: <57453D5A.1080000@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> Message-ID: <29aff9c8-525e-e3d4-56d0-4275a1bc3615@oracle.com> On 6/2/2016 2:26 PM, Roland Westrelin wrote: >>>>> So given uncommon traps are unaffected and only deopts are, isn't the >>>>> change below good enough? >>>> uncommon traps are affected in JVMCI case. pending exception check is >>>> after jvmci lock code. >>> That code in TemplateInterpreterGenerator::generate_deopt_entry_for()? >>> >>> #if INCLUDE_JVMCI >>> // Check if we need to take lock at entry of synchronized method. >>> if (UseJVMCICompiler) { >>> Label L; >>> __ cmpb(Address(thread, JavaThread::pending_monitorenter_offset()), 0); >>> __ jcc(Assembler::zero, L); >>> // Clear flag. >>> __ movb(Address(thread, JavaThread::pending_monitorenter_offset()), 0); >>> // Satisfy calling convention for lock_method(). >>> __ get_method(rbx); >>> // Take lock. >>> lock_method(); >>> __ bind(L); >>> } >>> #endif >> Yes. > Can't we simply clear pending_monitorenter, for instance in > Deoptimization::pop_frames_failed_reallocs? Yes we can do that. that should solve all our issues.. Best Regards, Jamsheed > > Roland. > > > diff --git a/src/share/vm/runtime/deoptimization.cpp b/src/share/vm/runtime/deoptimization.cpp > --- a/src/share/vm/runtime/deoptimization.cpp > +++ b/src/share/vm/runtime/deoptimization.cpp > @@ -497,6 +497,12 @@ > exec_mode = Unpack_exception; > } > #endif > + if (thread->frames_to_pop_failed_realloc() > 0) { > + assert(thread->has_pending_exception(), "should have thrown OOME"); > + thread->set_exception_oop(thread->pending_exception()); > + thread->clear_pending_exception(); > + exec_mode = Unpack_exception; > + } > > UnrollBlock* info = new UnrollBlock(array->frame_size() * BytesPerWord, > caller_adjustment * BytesPerWord, > @@ -1228,6 +1234,7 @@ > #endif > } > } > + thread->set_pending_monitorenter(false); > } > #endif > From zoltan.majo at oracle.com Thu Jun 2 09:29:54 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 2 Jun 2016 11:29:54 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> Message-ID: <574FFC92.6010606@oracle.com> Hi Vladimir, On 05/18/2016 03:47 PM, Vladimir Ivanov wrote: > [...] > > So, I'm in favor of a generic fix to align the behavior with JVMS. OK, so I have implemented a generic fix that adds the checks required by the JVMS. For bytecodes modifying final fields, the VM checks - that the accessing method is (for static fields) - that the accessing method is (for instance fields) and thrown an IllegalAccessError if any of the checks fails. Here is the new webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.02/ I did the following testing: - JPRT - pre-PIT RBT run (in progress) - the reproducer. The reproducer now behaves as expected (an IllegalAccessError is thrown). Also, the pre-PIT RBT run has shown no new failures so far. But there is a problem with JPRT: A JCK test, putstatic01801m, fails. The reason for the failure is that the the test generates a method that contains a putstatic to a static final field (i.e., the bytecodes generated by the test do not conform to the JVMS). (Even the test mentions that the Java source equivalent to the generated bytecodes is compilable only if the "final" keyword is removed from the declaration of the static field.) So (if we decide to push the current fix) the issue with the test needs to be fixed first. Do you know how we could proceed with that? Thank you and best regards, Zoltan > > Best regards, > Vladimir Ivanov > >> >> I agree with you, alternatively we can propose a more generic fix (fix >> the interpreter and the compilers as well). The fix would most likely >> affect field resolution in LinkResolver::resolve_field() around here: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >> >> >> >> Changing resolve_field() to throw an IllegalAccessError for >> inappropriate field access will propagate the exception to the >> interpreter. Changing ciField::will_link() will most likely kill (some) >> compilations (if, e.g., fields are linked through ciField::will_link()). >> >> I'd prefer to take the second option (changing field resolution), but >> there might be some disadvantages related to option I might be >> overseeing. > > > > >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> >>> >>>> More details about the failure are here [3]. >>>> >>>> With the patch applied, the program always completes as it is expected >>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>> always interpret methods non-conforming with the VM spec). >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>> Bailing out the whole compilation in C2 is even less appropriate. It >>> should generate an uncommon trap for such accesses instead (see >>> Parse::do_field_access). >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>> >>> >> From jamsheed.c.m at oracle.com Thu Jun 2 09:55:30 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 2 Jun 2016 15:25:30 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <29aff9c8-525e-e3d4-56d0-4275a1bc3615@oracle.com> References: <57453D5A.1080000@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> <5745CF61.6040500@redhat.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> <29aff9c8-525e-e3d4-56d0-4275a1bc3615@oracle.com> Message-ID: <6e27d0e1-f79f-50a0-a139-d28bb61ff6fb@oracle.com> Hi Roland and All, revised webrev: http://cr.openjdk.java.net/~jcm/8146416/webrev.02/ Best Regards, Jamsheed On 6/2/2016 2:29 PM, Jamsheed C m wrote: > > > On 6/2/2016 2:26 PM, Roland Westrelin wrote: >>>>>> So given uncommon traps are unaffected and only deopts are, isn't >>>>>> the >>>>>> change below good enough? >>>>> uncommon traps are affected in JVMCI case. pending exception >>>>> check is >>>>> after jvmci lock code. >>>> That code in TemplateInterpreterGenerator::generate_deopt_entry_for()? >>>> >>>> #if INCLUDE_JVMCI >>>> // Check if we need to take lock at entry of synchronized method. >>>> if (UseJVMCICompiler) { >>>> Label L; >>>> __ cmpb(Address(thread, >>>> JavaThread::pending_monitorenter_offset()), 0); >>>> __ jcc(Assembler::zero, L); >>>> // Clear flag. >>>> __ movb(Address(thread, >>>> JavaThread::pending_monitorenter_offset()), 0); >>>> // Satisfy calling convention for lock_method(). >>>> __ get_method(rbx); >>>> // Take lock. >>>> lock_method(); >>>> __ bind(L); >>>> } >>>> #endif >>> Yes. >> Can't we simply clear pending_monitorenter, for instance in >> Deoptimization::pop_frames_failed_reallocs? > Yes we can do that. > > that should solve all our issues.. > > Best Regards, > Jamsheed >> >> Roland. >> >> >> diff --git a/src/share/vm/runtime/deoptimization.cpp >> b/src/share/vm/runtime/deoptimization.cpp >> --- a/src/share/vm/runtime/deoptimization.cpp >> +++ b/src/share/vm/runtime/deoptimization.cpp >> @@ -497,6 +497,12 @@ >> exec_mode = Unpack_exception; >> } >> #endif >> + if (thread->frames_to_pop_failed_realloc() > 0) { >> + assert(thread->has_pending_exception(), "should have thrown OOME"); >> + thread->set_exception_oop(thread->pending_exception()); >> + thread->clear_pending_exception(); >> + exec_mode = Unpack_exception; >> + } >> UnrollBlock* info = new UnrollBlock(array->frame_size() * >> BytesPerWord, >> caller_adjustment * >> BytesPerWord, >> @@ -1228,6 +1234,7 @@ >> #endif >> } >> } >> + thread->set_pending_monitorenter(false); >> } >> #endif > From doug.simon at oracle.com Thu Jun 2 10:10:24 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 2 Jun 2016 12:10:24 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <574FFC92.6010606@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> Message-ID: <6561A080-8A08-43EB-A4AF-865884ADD389@oracle.com> Could you please copy the javadoc for the `method` parameter from jdk.vm.ci.meta.ConstantPool.lookupField to jdk.vm.ci.hotspot.CompilerToVM.resolveFieldInPool. Otherwise, the changes to the JVMCI code look good. -Doug > On 02 Jun 2016, at 11:29, Zolt?n Maj? wrote: > > Hi Vladimir, > > > On 05/18/2016 03:47 PM, Vladimir Ivanov wrote: >> [...] >> >> So, I'm in favor of a generic fix to align the behavior with JVMS. > > OK, so I have implemented a generic fix that adds the checks required by the JVMS. > > For bytecodes modifying final fields, the VM checks > - that the accessing method is (for static fields) > - that the accessing method is (for instance fields) > and thrown an IllegalAccessError if any of the checks fails. > > Here is the new webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.02/ > > I did the following testing: > - JPRT > - pre-PIT RBT run (in progress) > - the reproducer. > > The reproducer now behaves as expected (an IllegalAccessError is thrown). Also, the pre-PIT RBT run has shown no new failures so far. > > But there is a problem with JPRT: A JCK test, putstatic01801m, fails. > > The reason for the failure is that the the test generates a method that contains a putstatic to a static final field (i.e., the bytecodes generated by the test do not conform to the JVMS). (Even the test mentions that the Java source equivalent to the generated bytecodes is compilable only if the "final" keyword is removed from the declaration of the static field.) > > So (if we decide to push the current fix) the issue with the test needs to be fixed first. Do you know how we could proceed with that? > > Thank you and best regards, > > > Zoltan > >> >> Best regards, >> Vladimir Ivanov >> >>> >>> I agree with you, alternatively we can propose a more generic fix (fix >>> the interpreter and the compilers as well). The fix would most likely >>> affect field resolution in LinkResolver::resolve_field() around here: >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>> >>> >>> Changing resolve_field() to throw an IllegalAccessError for >>> inappropriate field access will propagate the exception to the >>> interpreter. Changing ciField::will_link() will most likely kill (some) >>> compilations (if, e.g., fields are linked through ciField::will_link()). >>> >>> I'd prefer to take the second option (changing field resolution), but >>> there might be some disadvantages related to option I might be overseeing. >> >> >> >> >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> >>>> >>>>> More details about the failure are here [3]. >>>>> >>>>> With the patch applied, the program always completes as it is expected >>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>> always interpret methods non-conforming with the VM spec). >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>> should generate an uncommon trap for such accesses instead (see >>>> Parse::do_field_access). >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>> >>> > From zoltan.majo at oracle.com Thu Jun 2 10:29:22 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 2 Jun 2016 12:29:22 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <6561A080-8A08-43EB-A4AF-865884ADD389@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <6561A080-8A08-43EB-A4AF-865884ADD389@oracle.com> Message-ID: <57500A82.6000907@oracle.com> Hi Doug, On 06/02/2016 12:10 PM, Doug Simon wrote: > Could you please copy the javadoc for the `method` parameter from jdk.vm.ci.meta.ConstantPool.lookupField to jdk.vm.ci.hotspot.CompilerToVM.resolveFieldInPool. thank you for the feedback! Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.03/ Best regards, Zoltan > > Otherwise, the changes to the JVMCI code look good. > > -Doug > >> On 02 Jun 2016, at 11:29, Zolt?n Maj? wrote: >> >> Hi Vladimir, >> >> >> On 05/18/2016 03:47 PM, Vladimir Ivanov wrote: >>> [...] >>> >>> So, I'm in favor of a generic fix to align the behavior with JVMS. >> OK, so I have implemented a generic fix that adds the checks required by the JVMS. >> >> For bytecodes modifying final fields, the VM checks >> - that the accessing method is (for static fields) >> - that the accessing method is (for instance fields) >> and thrown an IllegalAccessError if any of the checks fails. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.02/ >> >> I did the following testing: >> - JPRT >> - pre-PIT RBT run (in progress) >> - the reproducer. >> >> The reproducer now behaves as expected (an IllegalAccessError is thrown). Also, the pre-PIT RBT run has shown no new failures so far. >> >> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >> >> The reason for the failure is that the the test generates a method that contains a putstatic to a static final field (i.e., the bytecodes generated by the test do not conform to the JVMS). (Even the test mentions that the Java source equivalent to the generated bytecodes is compilable only if the "final" keyword is removed from the declaration of the static field.) >> >> So (if we decide to push the current fix) the issue with the test needs to be fixed first. Do you know how we could proceed with that? >> >> Thank you and best regards, >> >> >> Zoltan >> >>> Best regards, >>> Vladimir Ivanov >>> >>>> I agree with you, alternatively we can propose a more generic fix (fix >>>> the interpreter and the compilers as well). The fix would most likely >>>> affect field resolution in LinkResolver::resolve_field() around here: >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>> >>>> >>>> Changing resolve_field() to throw an IllegalAccessError for >>>> inappropriate field access will propagate the exception to the >>>> interpreter. Changing ciField::will_link() will most likely kill (some) >>>> compilations (if, e.g., fields are linked through ciField::will_link()). >>>> >>>> I'd prefer to take the second option (changing field resolution), but >>>> there might be some disadvantages related to option I might be overseeing. >>> >>> >>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>>>> More details about the failure are here [3]. >>>>>> >>>>>> With the patch applied, the program always completes as it is expected >>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>>> always interpret methods non-conforming with the VM spec). >>>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>> should generate an uncommon trap for such accesses instead (see >>>>> Parse::do_field_access). >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>> From vladimir.x.ivanov at oracle.com Thu Jun 2 10:47:09 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 2 Jun 2016 13:47:09 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <574FFC92.6010606@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> Message-ID: <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> Zoltan, (broadening the audience to hotspot-dev@) I'd like to draw attention from Runtime group to this change. > OK, so I have implemented a generic fix that adds the checks required by > the JVMS. > > For bytecodes modifying final fields, the VM checks > - that the accessing method is (for static fields) > - that the accessing method is (for instance fields) > and thrown an IllegalAccessError if any of the checks fails. > > Here is the new webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.02/ Regarding tightening linkage checks, your fix doesn't take into account JVMS changes between 6 & 7 (expected behavior differs depending on class file version). Before JVMS-7, where putfield/putstatic linkage checks were tightened, it was allowed to change final fields from anywhere in the same class. putfield "Linking Exceptions": JVMS-6 [1]: "Otherwise, if the field is final, it must be declared in the current class. Otherwise, an IllegalAccessError is thrown." JVMS-7 [2]: "Otherwise, if the field is final, it must be declared in the current class, and the instruction must occur in an instance initialization method () of the current class. Otherwise, an IllegalAccessError is thrown." src/share/vm/interpreter/linkResolver.cpp: + (byte == Bytecodes::_putstatic && fd.is_static() && method_name != vmSymbols::class_initializer_name()) || + ((byte == Bytecodes::_putfield || byte == Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != vmSymbols::object_initializer_name()) Also, as we found earlier, checking method name is not enough: bool Method::is_static_initializer() const { // For classfiles version 51 or greater, ensure that the clinit method is // static. Non-static methods with the name "" are not static // initializers. (older classfiles exempted for backward compatibility) return name() == vmSymbols::class_initializer_name() && has_valid_initializer_flags(); } - LinkInfo link_info(defc, name, type, KlassHandle(), /*check_access=*/false); + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, /*check_access=*/false); Use Handle() instead of NULL. Also, I'd prefer to see LinkInfo::_current_method and new constructor added: LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* signature, Handle current_method, bool check_access = true) : _current_klass can be derived from _current_method, since: // current_klass = sending method holder (i.e., class containing the method // containing the call being resolved) > I did the following testing: > - JPRT > - pre-PIT RBT run (in progress) > - the reproducer. > > The reproducer now behaves as expected (an IllegalAccessError is > thrown). Also, the pre-PIT RBT run has shown no new failures so far. > > But there is a problem with JPRT: A JCK test, putstatic01801m, fails. > > The reason for the failure is that the the test generates a method that > contains a putstatic to a static final field (i.e., the bytecodes > generated by the test do not conform to the JVMS). (Even the test > mentions that the Java source equivalent to the generated bytecodes is > compilable only if the "final" keyword is removed from the declaration > of the static field.) > > So (if we decide to push the current fix) the issue with the test needs > to be fixed first. Do you know how we could proceed with that? File a bug against JCK. Best regards, Vladimir Ivanov [1] https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html [2] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield [3] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 > > Thank you and best regards, > > > Zoltan > >> >> Best regards, >> Vladimir Ivanov >> >>> >>> I agree with you, alternatively we can propose a more generic fix (fix >>> the interpreter and the compilers as well). The fix would most likely >>> affect field resolution in LinkResolver::resolve_field() around here: >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>> >>> >>> >>> Changing resolve_field() to throw an IllegalAccessError for >>> inappropriate field access will propagate the exception to the >>> interpreter. Changing ciField::will_link() will most likely kill (some) >>> compilations (if, e.g., fields are linked through ciField::will_link()). >>> >>> I'd prefer to take the second option (changing field resolution), but >>> there might be some disadvantages related to option I might be >>> overseeing. >> >> >> >> >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> >>>> >>>>> More details about the failure are here [3]. >>>>> >>>>> With the patch applied, the program always completes as it is expected >>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>> always interpret methods non-conforming with the VM spec). >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>> should generate an uncommon trap for such accesses instead (see >>>> Parse::do_field_access). >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>> >>>> >>> > From vladimir.x.ivanov at oracle.com Thu Jun 2 11:26:04 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 2 Jun 2016 14:26:04 +0300 Subject: RFR(XS): 8158351: [JVMCI] NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI In-Reply-To: <5091E2EA-C1CF-42FB-9736-5D14CEEA34E7@oracle.com> References: <5091E2EA-C1CF-42FB-9736-5D14CEEA34E7@oracle.com> Message-ID: Looks good. Best regards, Vladimir Ivanov On 6/2/16 1:21 AM, Doug Simon wrote: > Please review this trivial test bug fix. > > https://bugs.openjdk.java.net/browse/JDK-8158351 > http://cr.openjdk.java.net/~dnsimon/8158351/ > > -Doug > From rwestrel at redhat.com Thu Jun 2 11:32:37 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 02 Jun 2016 13:32:37 +0200 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <6e27d0e1-f79f-50a0-a139-d28bb61ff6fb@oracle.com> References: <57453D5A.1080000@oracle.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> <29aff9c8-525e-e3d4-56d0-4275a1bc3615@oracle.com> <6e27d0e1-f79f-50a0-a139-d28bb61ff6fb@oracle.com> Message-ID: > revised webrev: http://cr.openjdk.java.net/~jcm/8146416/webrev.02/ Thanks for making the change. In vframeArrayElement::unpack_on_stack(), for jvmti's early return, I think you want to call state->clear_earlyret_pending() otherwise the early ret is still pending and that could lead to an unexpected behaviour. In your test cases, I would suggest bumping the heap size to avoid future problems with the test case like this one: https://bugs.openjdk.java.net/browse/JDK-8042557 Does DeoptReallocFailureUncommonTrap.java cover a case that's not covered by test/compiler/uncommontrap/TestDeoptOOM.java? Does it fail with jvmci/graal? Roland. From david.holmes at oracle.com Thu Jun 2 11:51:02 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Jun 2016 21:51:02 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> Message-ID: <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> On 2/06/2016 8:47 PM, Vladimir Ivanov wrote: > Zoltan, > > (broadening the audience to hotspot-dev@) > > I'd like to draw attention from Runtime group to this change. >> OK, so I have implemented a generic fix that adds the checks required by >> the JVMS. >> >> For bytecodes modifying final fields, the VM checks >> - that the accessing method is (for static fields) >> - that the accessing method is (for instance fields) >> and thrown an IllegalAccessError if any of the checks fails. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.02/ > > Regarding tightening linkage checks, your fix doesn't take into account > JVMS changes between 6 & 7 (expected behavior differs depending on class > file version). The simplest, and common, approach to these kind of issues is to only apply the correction for the current class file version and keep the relaxed rules for all others. That provides the best compatibility story. Of course if security is a concern then that is a different matter - but such concerns can not be discussed here. David ----- > Before JVMS-7, where putfield/putstatic linkage checks were tightened, > it was allowed to change final fields from anywhere in the same class. > > putfield "Linking Exceptions": > > JVMS-6 [1]: > "Otherwise, if the field is final, it must be declared in the > current class. Otherwise, an IllegalAccessError is thrown." > > JVMS-7 [2]: > "Otherwise, if the field is final, it must be declared in the > current class, and the instruction must occur in an instance > initialization method () of the current class. Otherwise, an > IllegalAccessError is thrown." > > > src/share/vm/interpreter/linkResolver.cpp: > > + (byte == Bytecodes::_putstatic && fd.is_static() && > method_name != vmSymbols::class_initializer_name()) || > + ((byte == Bytecodes::_putfield || byte == > Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != > vmSymbols::object_initializer_name()) > > > Also, as we found earlier, checking method name is not enough: > > bool Method::is_static_initializer() const { > // For classfiles version 51 or greater, ensure that the clinit method is > // static. Non-static methods with the name "" are not static > // initializers. (older classfiles exempted for backward compatibility) > return name() == vmSymbols::class_initializer_name() && > has_valid_initializer_flags(); > } > > > - LinkInfo link_info(defc, name, type, KlassHandle(), > /*check_access=*/false); > + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, > /*check_access=*/false); > > Use Handle() instead of NULL. > > Also, I'd prefer to see LinkInfo::_current_method and new constructor > added: > > LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* signature, > Handle current_method, bool check_access = true) : > > _current_klass can be derived from _current_method, since: > > // current_klass = sending method holder (i.e., class containing the > method > // containing the call being resolved) > >> I did the following testing: >> - JPRT >> - pre-PIT RBT run (in progress) >> - the reproducer. >> >> The reproducer now behaves as expected (an IllegalAccessError is >> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >> >> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >> >> The reason for the failure is that the the test generates a method that >> contains a putstatic to a static final field (i.e., the bytecodes >> generated by the test do not conform to the JVMS). (Even the test >> mentions that the Java source equivalent to the generated bytecodes is >> compilable only if the "final" keyword is removed from the declaration >> of the static field.) >> >> So (if we decide to push the current fix) the issue with the test needs >> to be fixed first. Do you know how we could proceed with that? > File a bug against JCK. > > Best regards, > Vladimir Ivanov > > [1] > https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html > > [2] > https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield > > > [3] > https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 > >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>>> >>>> I agree with you, alternatively we can propose a more generic fix (fix >>>> the interpreter and the compilers as well). The fix would most likely >>>> affect field resolution in LinkResolver::resolve_field() around here: >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>> >>>> >>>> >>>> >>>> Changing resolve_field() to throw an IllegalAccessError for >>>> inappropriate field access will propagate the exception to the >>>> interpreter. Changing ciField::will_link() will most likely kill (some) >>>> compilations (if, e.g., fields are linked through >>>> ciField::will_link()). >>>> >>>> I'd prefer to take the second option (changing field resolution), but >>>> there might be some disadvantages related to option I might be >>>> overseeing. >>> >>> >>> >>> >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>>> >>>>>> More details about the failure are here [3]. >>>>>> >>>>>> With the patch applied, the program always completes as it is >>>>>> expected >>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>>> always interpret methods non-conforming with the VM spec). >>>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>> should generate an uncommon trap for such accesses instead (see >>>>> Parse::do_field_access). >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>> >>>>> >>>>> >>>> >> From jamsheed.c.m at oracle.com Thu Jun 2 12:03:39 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 2 Jun 2016 17:33:39 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: References: <57453D5A.1080000@oracle.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> <29aff9c8-525e-e3d4-56d0-4275a1bc3615@oracle.com> <6e27d0e1-f79f-50a0-a139-d28bb61ff6fb@oracle.com> Message-ID: <3994d1db-5f77-019b-f970-1f2618721fb5@oracle.com> Hi Roland, Thank for the review comments. On 6/2/2016 5:02 PM, Roland Westrelin wrote: >> revised webrev: http://cr.openjdk.java.net/~jcm/8146416/webrev.02/ > Thanks for making the change. > > In vframeArrayElement::unpack_on_stack(), for jvmti's early return, I > think you want to call state->clear_earlyret_pending() otherwise the > early ret is still pending and that could lead to an unexpected > behaviour. i missed that one, will make the change. > > In your test cases, I would suggest bumping the heap size to avoid > future problems with the test case like this one: > > https://bugs.openjdk.java.net/browse/JDK-8042557 Ok > > Does DeoptReallocFailureUncommonTrap.java cover a case that's not > covered by test/compiler/uncommontrap/TestDeoptOOM.java? Does it fail > with jvmci/graal? i added this test case for uncommon_trap verification. let me check whether this one duplicate a test in TestDeoptOOM.java. Best Regards, Jamsheed > > Roland. From doug.simon at oracle.com Thu Jun 2 12:15:12 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 2 Jun 2016 14:15:12 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57500A82.6000907@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <6561A080-8A08-43EB-A4AF-865884ADD389@oracle.com> <57500A82.6000907@oracle.com> Message-ID: <7D199487-651A-4E81-818D-6673FFBE36F0@oracle.com> Thanks, looks good. > On 02 Jun 2016, at 12:29, Zolt?n Maj? wrote: > > Hi Doug, > > > On 06/02/2016 12:10 PM, Doug Simon wrote: >> Could you please copy the javadoc for the `method` parameter from jdk.vm.ci.meta.ConstantPool.lookupField to jdk.vm.ci.hotspot.CompilerToVM.resolveFieldInPool. > > thank you for the feedback! Here is the updated webrev: > > http://cr.openjdk.java.net/~zmajo/8157181/webrev.03/ > > Best regards, > > > Zoltan > >> >> Otherwise, the changes to the JVMCI code look good. >> >> -Doug >> >>> On 02 Jun 2016, at 11:29, Zolt?n Maj? wrote: >>> >>> Hi Vladimir, >>> >>> >>> On 05/18/2016 03:47 PM, Vladimir Ivanov wrote: >>>> [...] >>>> >>>> So, I'm in favor of a generic fix to align the behavior with JVMS. >>> OK, so I have implemented a generic fix that adds the checks required by the JVMS. >>> >>> For bytecodes modifying final fields, the VM checks >>> - that the accessing method is (for static fields) >>> - that the accessing method is (for instance fields) >>> and thrown an IllegalAccessError if any of the checks fails. >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.02/ >>> >>> I did the following testing: >>> - JPRT >>> - pre-PIT RBT run (in progress) >>> - the reproducer. >>> >>> The reproducer now behaves as expected (an IllegalAccessError is thrown). Also, the pre-PIT RBT run has shown no new failures so far. >>> >>> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >>> >>> The reason for the failure is that the the test generates a method that contains a putstatic to a static final field (i.e., the bytecodes generated by the test do not conform to the JVMS). (Even the test mentions that the Java source equivalent to the generated bytecodes is compilable only if the "final" keyword is removed from the declaration of the static field.) >>> >>> So (if we decide to push the current fix) the issue with the test needs to be fixed first. Do you know how we could proceed with that? >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>> I agree with you, alternatively we can propose a more generic fix (fix >>>>> the interpreter and the compilers as well). The fix would most likely >>>>> affect field resolution in LinkResolver::resolve_field() around here: >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>> >>>>> >>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>> inappropriate field access will propagate the exception to the >>>>> interpreter. Changing ciField::will_link() will most likely kill (some) >>>>> compilations (if, e.g., fields are linked through ciField::will_link()). >>>>> >>>>> I'd prefer to take the second option (changing field resolution), but >>>>> there might be some disadvantages related to option I might be overseeing. >>>> >>>> >>>> >>>>> Thank you! >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>> >>>>>>> More details about the failure are here [3]. >>>>>>> >>>>>>> With the patch applied, the program always completes as it is expected >>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>> >>>>>>> Here is the updated webrev: >>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>>> should generate an uncommon trap for such accesses instead (see >>>>>> Parse::do_field_access). >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>> > From tobias.hartmann at oracle.com Thu Jun 2 13:32:22 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 2 Jun 2016 15:32:22 +0200 Subject: [9] RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays In-Reply-To: <51074461-132f-c775-bfe5-d6488cca099a@oracle.com> References: <574ED13F.1050003@oracle.com> <51074461-132f-c775-bfe5-d6488cca099a@oracle.com> Message-ID: <57503566.9080801@oracle.com> Hi Vladimir, thanks for the feedback! On 01.06.2016 15:38, Vladimir Ivanov wrote: > Tobias, > > Thanks for taking care of the bug. > >> https://bugs.openjdk.java.net/browse/JDK-8158228 >> http://cr.openjdk.java.net/~thartmann/8158228/webrev.00/ >> >> Multiple tests fail since JDK 9 b110 because String.charAt() returns a wrong value for a constant string. In b110, JDK-8143407 [1] enabled C1 to constant fold stable array elements and since JDK-8150180 [2] String.value is constant. The problem is that C1 does not correctly fold mismatched loads from stable arrays. In this case, String.value is a stable byte[] and StringUTF16.charAt() is intrinsified as char load. Instead of a char load, C1 emits a byte load because it does not check for mismatched loads. >> >> I fixed this by passing the BasicType of the mismatched load to ciArray::element_value() to ensure the correct constant is emitted. I verified that both 'Lex06403.java' and 'NewTestCase.java' pass with the fix. Also tested with JPRT and RBT (running). > > As I understand the only source of mismatched accesses are String intrinsics (getCharStringU/putCharStringU). Yes, the mismatched access is emitted by the getCharStringU intrinsic. > (Unsafe accesses are the main source of mismatched accesses, but C1 doesn't optimize them). > > Can you issue UnsafeObjectOp instead of LoadIndexed/StoreIndexed in GraphBuilder::append_char_access or does C1 produce less efficient code for unsafe accesses? It's possible but some boilerplate code to compute the offset is necessary: http://cr.openjdk.java.net/~thartmann/8158228/webrev.unsafe/ However, the code is far less than optimal: 0x00007fe4d159746a: mov $0x1c,%rdx 0x00007fe4d1597474: mov $0x6d4e80818,%rsi 0x00007fe4d159747e: movzwl (%rsi,%rdx,1),%edx 0x00007fe4d1597482: and $0xffff,%edx 0x00007fe4d1597488: and $0xffff,%edx 0x00007fe4d159748e: mov %rdx,%rbx 0x00007fe4d1597491: cmp $0x67,%ebx vs. 0x00007fe14559744a: mov $0x67,%ebx 0x00007fe14559744f: cmp $0x67,%ebx The load is not folded, we don't use addressing modes (because we compute the long offset beforehand) and there is a useless 'and'. > Otherwise, I suggest to mark LoadIndexed/StoreIndexed as mismatched (or introduce UnsafeLoadIndexed/UnsafeStoreIndexed node) and check that in Canonicalizer::do_LoadIndexed. > > Mismatch detection is more complex than just comparing basic types (see Type::make_constant_from_array_element() & check_mismatched_access(), though some checks are C2-specific). Right, I agree. I would like to go with marking LoadIndexed/StoreIndexed as mismatched when emitting the intrinsic: http://cr.openjdk.java.net/~thartmann/8158228/webrev.01/ Like this we still have optimal code. What do you think? Thanks, Tobias > Since C1 doesn't optimize unsafe accesses, I suggest to confine the fix to String intrinsics. > > Best regards, > Vladimir Ivanov > >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8143407 >> [2] https://bugs.openjdk.java.net/browse/JDK-8150180 From vladimir.x.ivanov at oracle.com Thu Jun 2 13:49:26 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 2 Jun 2016 16:49:26 +0300 Subject: [9] RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays In-Reply-To: <57503566.9080801@oracle.com> References: <574ED13F.1050003@oracle.com> <51074461-132f-c775-bfe5-d6488cca099a@oracle.com> <57503566.9080801@oracle.com> Message-ID: <1f4211fb-54d9-957d-6e44-651b302a1531@oracle.com> >> Mismatch detection is more complex than just comparing basic types (see Type::make_constant_from_array_element() & check_mismatched_access(), though some checks are C2-specific). > > Right, I agree. I would like to go with marking LoadIndexed/StoreIndexed as mismatched when emitting the intrinsic: > http://cr.openjdk.java.net/~thartmann/8158228/webrev.01/ > > Like this we still have optimal code. What do you think? I suggest to completely disable constant folding in Canonicalizer::do_LoadIndexed if LoadIndexed node is marked as mismatched. Please, leave ciArray::element_value_impl as is. Otherwise, looks good. Best regards, Vladimir Ivanov From tobias.hartmann at oracle.com Thu Jun 2 14:54:11 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 2 Jun 2016 16:54:11 +0200 Subject: [9] RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays In-Reply-To: <1f4211fb-54d9-957d-6e44-651b302a1531@oracle.com> References: <574ED13F.1050003@oracle.com> <51074461-132f-c775-bfe5-d6488cca099a@oracle.com> <57503566.9080801@oracle.com> <1f4211fb-54d9-957d-6e44-651b302a1531@oracle.com> Message-ID: <57504893.3090607@oracle.com> Hi Vladimir, On 02.06.2016 15:49, Vladimir Ivanov wrote: > >>> Mismatch detection is more complex than just comparing basic types (see Type::make_constant_from_array_element() & check_mismatched_access(), though some checks are C2-specific). >> >> Right, I agree. I would like to go with marking LoadIndexed/StoreIndexed as mismatched when emitting the intrinsic: >> http://cr.openjdk.java.net/~thartmann/8158228/webrev.01/ >> >> Like this we still have optimal code. What do you think? > I suggest to completely disable constant folding in Canonicalizer::do_LoadIndexed if LoadIndexed node is marked as mismatched. > > Please, leave ciArray::element_value_impl as is. Okay, I noticed that C2 also does not fold mismatched accesses. Could you please explain why that is? Here's the new webrev: http://cr.openjdk.java.net/~thartmann/8158228/webrev.02/ Thanks, Tobias > > Otherwise, looks good. > > Best regards, > Vladimir Ivanov From zoltan.majo at oracle.com Thu Jun 2 15:20:37 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 2 Jun 2016 17:20:37 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <574FFC92.6010606@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> Message-ID: <57504EC5.40209@oracle.com> Hi, On 06/02/2016 11:29 AM, Zolt?n Maj? wrote: > [...] > > But there is a problem with JPRT: A JCK test, putstatic01801m, fails. > > The reason for the failure is that the the test generates a method > that contains a putstatic to a static final field (i.e., the bytecodes > generated by the test do not conform to the JVMS). (Even the test > mentions that the Java source equivalent to the generated bytecodes is > compilable only if the "final" keyword is removed from the declaration > of the static field.) > > So (if we decide to push the current fix) the issue with the test > needs to be fixed first. Do you know how we could proceed with that? After a (private) discussion with Igor Ignatyev, I've filed a bug with the JCK team to address the issue with the putstatic01801m test. In the bug report, David Holmes suggest the following: "If this is a long standing non-compliance with the JVMS then its impact can not be considered high. The longer the VM and spec do not match the more likely we adjust the spec to match the VM behaviour. When that is not feasible then the usual approach is to enforce the correct rules as of the current classfile version, otherwise we risk introducing compatibility issues. Even if we make the correct behaviour the default, we will usually provide a flag to enable the old behaviour for compatibility purposes. Only if this is a security concern would we force the change to the new behaviour. " So, to follow David's suggestions, I did the following modifications to the previous webrev: - the check for the caller method in LinkResolver::resolve_field() is performed only for classes with _major_version >= 52; - I added a new diagnostic flag, CheckFinalFieldModifications to disable the new checks (please feel free to suggest a better flag name). That should solve the problem with the JCK test. However, if we follow David's suggestions, we can't guarantee for all classes that final fields won't change after initialization. So the compilers can generate incorrect code when compiling accessing to fields of those classes. Therefore, in the current webrev, I've disabled folding of accesses to all non-stable fields. We could relax that criteria, e.g., by disabling folding only for those field that were declared in a class with _major_version < 52. But it would be great if you could give me some feedback before I look into that. Thank you very much in advance! Updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ Testing: JPRT in progress. Best regards, Zoltan > > Thank you and best regards, > > > Zoltan > >> >> Best regards, >> Vladimir Ivanov >> >>> >>> I agree with you, alternatively we can propose a more generic fix (fix >>> the interpreter and the compilers as well). The fix would most likely >>> affect field resolution in LinkResolver::resolve_field() around here: >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>> >>> >>> >>> Changing resolve_field() to throw an IllegalAccessError for >>> inappropriate field access will propagate the exception to the >>> interpreter. Changing ciField::will_link() will most likely kill (some) >>> compilations (if, e.g., fields are linked through >>> ciField::will_link()). >>> >>> I'd prefer to take the second option (changing field resolution), but >>> there might be some disadvantages related to option I might be >>> overseeing. >> >> >> >> >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> >>>> >>>>> More details about the failure are here [3]. >>>>> >>>>> With the patch applied, the program always completes as it is >>>>> expected >>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>> always interpret methods non-conforming with the VM spec). >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>> should generate an uncommon trap for such accesses instead (see >>>> Parse::do_field_access). >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>> >>>> >>> > From forax at univ-mlv.fr Thu Jun 2 16:30:35 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 2 Jun 2016 18:30:35 +0200 (CEST) Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57504EC5.40209@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> Message-ID: <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Zolt?n Maj?" > ?: hotspot-compiler-dev at openjdk.java.net > Envoy?: Jeudi 2 Juin 2016 17:20:37 > Objet: Re: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods > > Hi, > > > On 06/02/2016 11:29 AM, Zolt?n Maj? wrote: > > [...] > > > > But there is a problem with JPRT: A JCK test, putstatic01801m, fails. > > > > The reason for the failure is that the the test generates a method > > that contains a putstatic to a static final field (i.e., the bytecodes > > generated by the test do not conform to the JVMS). (Even the test > > mentions that the Java source equivalent to the generated bytecodes is > > compilable only if the "final" keyword is removed from the declaration > > of the static field.) > > > > So (if we decide to push the current fix) the issue with the test > > needs to be fixed first. Do you know how we could proceed with that? > > After a (private) discussion with Igor Ignatyev, I've filed a bug with > the JCK team to address the issue with the putstatic01801m test. > > In the bug report, David Holmes suggest the following: > > "If this is a long standing non-compliance with the JVMS then its impact > can not be considered high. The longer the VM and spec do not match the > more likely we adjust the spec to match the VM behaviour. When that is > not feasible then the usual approach is to enforce the correct rules as > of the current classfile version, otherwise we risk introducing > compatibility issues. Even if we make the correct behaviour the default, > we will usually provide a flag to enable the old behaviour for > compatibility purposes. Only if this is a security concern would we > force the change to the new behaviour. " > > So, to follow David's suggestions, I did the following modifications to > the previous webrev: > - the check for the caller method in LinkResolver::resolve_field() is > performed only for classes with _major_version >= 52; > - I added a new diagnostic flag, CheckFinalFieldModifications to disable > the new checks (please feel free to suggest a better flag name). > > That should solve the problem with the JCK test. However, if we follow > David's suggestions, we can't guarantee for all classes that final > fields won't change after initialization. So the compilers can generate > incorrect code when compiling accessing to fields of those classes. > > Therefore, in the current webrev, I've disabled folding of accesses to > all non-stable fields. Please do not do that, it will be a huge regression in term of perf at least for the language runtimes i maintain (and i suppose for Nashorn, JRuby or Groovy), Here are the perf assertions i use routinely, static final method handle is considered as constant, final fields (even not static) of VM anonymous class is considered as truly final. > > We could relax that criteria, e.g., by disabling folding only for those > field that were declared in a class with _major_version < 52. But it > would be great if you could give me some feedback before I look into > that. Thank you very much in advance! > > Updated webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ > > Testing: JPRT in progress. > > Best regards, > > > Zoltan R?mi > > > > > Thank you and best regards, > > > > > > Zoltan > > > >> > >> Best regards, > >> Vladimir Ivanov > >> > >>> > >>> I agree with you, alternatively we can propose a more generic fix (fix > >>> the interpreter and the compilers as well). The fix would most likely > >>> affect field resolution in LinkResolver::resolve_field() around here: > >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 > >>> > >>> > >>> > >>> Changing resolve_field() to throw an IllegalAccessError for > >>> inappropriate field access will propagate the exception to the > >>> interpreter. Changing ciField::will_link() will most likely kill (some) > >>> compilations (if, e.g., fields are linked through > >>> ciField::will_link()). > >>> > >>> I'd prefer to take the second option (changing field resolution), but > >>> there might be some disadvantages related to option I might be > >>> overseeing. > >> > >> > >> > >> > >>> > >>> Thank you! > >>> > >>> Best regards, > >>> > >>> > >>> Zoltan > >>> > >>> > >>>> > >>>>> More details about the failure are here [3]. > >>>>> > >>>>> With the patch applied, the program always completes as it is > >>>>> expected > >>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we > >>>>> always interpret methods non-conforming with the VM spec). > >>>>> > >>>>> Here is the updated webrev: > >>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ > >>>> Bailing out the whole compilation in C2 is even less appropriate. It > >>>> should generate an uncommon trap for such accesses instead (see > >>>> Parse::do_field_access). > >>>> > >>>> Best regards, > >>>> Vladimir Ivanov > >>>> > >>>> [1] > >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 > >>>> > >>>> > >>> > > > > From zoltan.majo at oracle.com Thu Jun 2 16:48:03 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 2 Jun 2016 18:48:03 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> Message-ID: <57506343.7040409@oracle.com> Hi R?mi, On 06/02/2016 06:30 PM, Remi Forax wrote: > [...] > > ----- Mail original ----- >> De: "Zolt?n Maj?" >> ?: hotspot-compiler-dev at openjdk.java.net >> Envoy?: Jeudi 2 Juin 2016 17:20:37 >> Objet: Re: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods >> >> Hi, >> >> >> On 06/02/2016 11:29 AM, Zolt?n Maj? wrote: >>> [...] >>> >>> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >>> >>> The reason for the failure is that the the test generates a method >>> that contains a putstatic to a static final field (i.e., the bytecodes >>> generated by the test do not conform to the JVMS). (Even the test >>> mentions that the Java source equivalent to the generated bytecodes is >>> compilable only if the "final" keyword is removed from the declaration >>> of the static field.) >>> >>> So (if we decide to push the current fix) the issue with the test >>> needs to be fixed first. Do you know how we could proceed with that? >> After a (private) discussion with Igor Ignatyev, I've filed a bug with >> the JCK team to address the issue with the putstatic01801m test. >> >> In the bug report, David Holmes suggest the following: >> >> "If this is a long standing non-compliance with the JVMS then its impact >> can not be considered high. The longer the VM and spec do not match the >> more likely we adjust the spec to match the VM behaviour. When that is >> not feasible then the usual approach is to enforce the correct rules as >> of the current classfile version, otherwise we risk introducing >> compatibility issues. Even if we make the correct behaviour the default, >> we will usually provide a flag to enable the old behaviour for >> compatibility purposes. Only if this is a security concern would we >> force the change to the new behaviour. " >> >> So, to follow David's suggestions, I did the following modifications to >> the previous webrev: >> - the check for the caller method in LinkResolver::resolve_field() is >> performed only for classes with _major_version >= 52; >> - I added a new diagnostic flag, CheckFinalFieldModifications to disable >> the new checks (please feel free to suggest a better flag name). >> >> That should solve the problem with the JCK test. However, if we follow >> David's suggestions, we can't guarantee for all classes that final >> fields won't change after initialization. So the compilers can generate >> incorrect code when compiling accessing to fields of those classes. >> >> Therefore, in the current webrev, I've disabled folding of accesses to >> all non-stable fields. > Please do not do that, it will be a huge regression in term of perf at least for the language runtimes i maintain > (and i suppose for Nashorn, JRuby or Groovy), Here are the perf assertions i use routinely, > static final method handle is considered as constant, final fields (even not static) of VM anonymous class is considered as truly final. > I fully understand your concerns. And thank you for sharing your asserts! Let's see what others think about how to go about this problem. So far the following options were explored - bail out compilation of non-compliant methods; - enforce JVMS conformance for all classes and keep constant folding enabled; - enforce JVMS conformance only for classes with _major_version >=52 and completely disable constant folding. I'm not sure which option is the best. Also, there might be other options as well. Thank you and best regards, Zoltan >> We could relax that criteria, e.g., by disabling folding only for those >> field that were declared in a class with _major_version < 52. But it >> would be great if you could give me some feedback before I look into >> that. Thank you very much in advance! >> >> Updated webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >> >> Testing: JPRT in progress. >> >> Best regards, >> >> >> Zoltan > R?mi > >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>> I agree with you, alternatively we can propose a more generic fix (fix >>>>> the interpreter and the compilers as well). The fix would most likely >>>>> affect field resolution in LinkResolver::resolve_field() around here: >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>> >>>>> >>>>> >>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>> inappropriate field access will propagate the exception to the >>>>> interpreter. Changing ciField::will_link() will most likely kill (some) >>>>> compilations (if, e.g., fields are linked through >>>>> ciField::will_link()). >>>>> >>>>> I'd prefer to take the second option (changing field resolution), but >>>>> there might be some disadvantages related to option I might be >>>>> overseeing. >>>> >>>> >>>> >>>>> Thank you! >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>> >>>>>>> More details about the failure are here [3]. >>>>>>> >>>>>>> With the patch applied, the program always completes as it is >>>>>>> expected >>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>> >>>>>>> Here is the updated webrev: >>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>>> should generate an uncommon trap for such accesses instead (see >>>>>> Parse::do_field_access). >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>> >>>>>> >> From forax at univ-mlv.fr Thu Jun 2 16:55:02 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 2 Jun 2016 18:55:02 +0200 (CEST) Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57506343.7040409@oracle.com> References: <573C2DAD.1030903@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> Message-ID: <2074215461.1970597.1464886502016.JavaMail.zimbra@u-pem.fr> Hi Zoltan ----- Mail original ----- > De: "Zolt?n Maj?" > ?: "Remi Forax" > Cc: hotspot-compiler-dev at openjdk.java.net > > Hi R?mi, > > > On 06/02/2016 06:30 PM, Remi Forax wrote: > > [...] > > > > ----- Mail original ----- > >> De: "Zolt?n Maj?" > >> ?: hotspot-compiler-dev at openjdk.java.net > >> Envoy?: Jeudi 2 Juin 2016 17:20:37 > >> Objet: Re: [9] RFR (S): 8157181: Compilers accept modification of final > >> fields outside initializer methods > >> > >> Hi, > >> > >> > >> On 06/02/2016 11:29 AM, Zolt?n Maj? wrote: > >>> [...] > >>> > >>> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. > >>> > >>> The reason for the failure is that the the test generates a method > >>> that contains a putstatic to a static final field (i.e., the bytecodes > >>> generated by the test do not conform to the JVMS). (Even the test > >>> mentions that the Java source equivalent to the generated bytecodes is > >>> compilable only if the "final" keyword is removed from the declaration > >>> of the static field.) > >>> > >>> So (if we decide to push the current fix) the issue with the test > >>> needs to be fixed first. Do you know how we could proceed with that? > >> After a (private) discussion with Igor Ignatyev, I've filed a bug with > >> the JCK team to address the issue with the putstatic01801m test. > >> > >> In the bug report, David Holmes suggest the following: > >> > >> "If this is a long standing non-compliance with the JVMS then its impact > >> can not be considered high. The longer the VM and spec do not match the > >> more likely we adjust the spec to match the VM behaviour. When that is > >> not feasible then the usual approach is to enforce the correct rules as > >> of the current classfile version, otherwise we risk introducing > >> compatibility issues. Even if we make the correct behaviour the default, > >> we will usually provide a flag to enable the old behaviour for > >> compatibility purposes. Only if this is a security concern would we > >> force the change to the new behaviour. " > >> > >> So, to follow David's suggestions, I did the following modifications to > >> the previous webrev: > >> - the check for the caller method in LinkResolver::resolve_field() is > >> performed only for classes with _major_version >= 52; > >> - I added a new diagnostic flag, CheckFinalFieldModifications to disable > >> the new checks (please feel free to suggest a better flag name). > >> > >> That should solve the problem with the JCK test. However, if we follow > >> David's suggestions, we can't guarantee for all classes that final > >> fields won't change after initialization. So the compilers can generate > >> incorrect code when compiling accessing to fields of those classes. > >> > >> Therefore, in the current webrev, I've disabled folding of accesses to > >> all non-stable fields. > > Please do not do that, it will be a huge regression in term of perf at > > least for the language runtimes i maintain > > (and i suppose for Nashorn, JRuby or Groovy), Here are the perf assertions > > i use routinely, > > static final method handle is considered as constant, final fields (even > > not static) of VM anonymous class is considered as truly final. > > > > I fully understand your concerns. And thank you for sharing your asserts! > > Let's see what others think about how to go about this problem. So far > the following options were explored > - bail out compilation of non-compliant methods; > - enforce JVMS conformance for all classes and keep constant folding > enabled; > - enforce JVMS conformance only for classes with _major_version >=52 and > completely disable constant folding. > > I'm not sure which option is the best. Also, there might be other > options as well. what about bailing out compilation of non-compliant methods if major <= 52 or if a backward compat flag is set and enforcing the JVMS spec for major >= 53 ? > > Thank you and best regards, > > > Zoltan R?mi > > > > >> We could relax that criteria, e.g., by disabling folding only for those > >> field that were declared in a class with _major_version < 52. But it > >> would be great if you could give me some feedback before I look into > >> that. Thank you very much in advance! > >> > >> Updated webrev: > >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ > >> > >> Testing: JPRT in progress. > >> > >> Best regards, > >> > >> > >> Zoltan > > R?mi > > > >>> Thank you and best regards, > >>> > >>> > >>> Zoltan > >>> > >>>> Best regards, > >>>> Vladimir Ivanov > >>>> > >>>>> I agree with you, alternatively we can propose a more generic fix (fix > >>>>> the interpreter and the compilers as well). The fix would most likely > >>>>> affect field resolution in LinkResolver::resolve_field() around here: > >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 > >>>>> > >>>>> > >>>>> > >>>>> Changing resolve_field() to throw an IllegalAccessError for > >>>>> inappropriate field access will propagate the exception to the > >>>>> interpreter. Changing ciField::will_link() will most likely kill (some) > >>>>> compilations (if, e.g., fields are linked through > >>>>> ciField::will_link()). > >>>>> > >>>>> I'd prefer to take the second option (changing field resolution), but > >>>>> there might be some disadvantages related to option I might be > >>>>> overseeing. > >>>> > >>>> > >>>> > >>>>> Thank you! > >>>>> > >>>>> Best regards, > >>>>> > >>>>> > >>>>> Zoltan > >>>>> > >>>>> > >>>>>>> More details about the failure are here [3]. > >>>>>>> > >>>>>>> With the patch applied, the program always completes as it is > >>>>>>> expected > >>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we > >>>>>>> always interpret methods non-conforming with the VM spec). > >>>>>>> > >>>>>>> Here is the updated webrev: > >>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ > >>>>>> Bailing out the whole compilation in C2 is even less appropriate. It > >>>>>> should generate an uncommon trap for such accesses instead (see > >>>>>> Parse::do_field_access). > >>>>>> > >>>>>> Best regards, > >>>>>> Vladimir Ivanov > >>>>>> > >>>>>> [1] > >>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 > >>>>>> > >>>>>> > >> > > From vladimir.kozlov at oracle.com Thu Jun 2 17:48:29 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Jun 2016 10:48:29 -0700 Subject: ATTENTION: hg: jdk9/hs-comp/hotspot: 8149418: AArch64: replace tst+br with tbz instruction when tst's constant operand is 2 power In-Reply-To: <201606021314.u52DEdiq012412@aojmv0008.oracle.com> References: <201606021314.u52DEdiq012412@aojmv0008.oracle.com> Message-ID: <3ec3c10f-66d1-952f-5fcf-8d7562e51b32@oracle.com> Please, don't push RFE(Enhancement) changes without approval. Even if it is platform specific code. We passed FC (Feature Complete) date May 26: http://openjdk.java.net/projects/jdk9 All RFE(Enhancement) changes for JDK 9 should be approved before pushing them. Or target RFE for JDK 10. If changes are ready you still need to get approval. Unfortunately the procedure for openjdk contribution approval is not finalized yet. Please, wait a little. For now add FC exemption request comment if you want to push into JDK 9. See for example: https://bugs.openjdk.java.net/browse/JDK-8156839 Note, if shared code (or platforms specific code which Oracle support) is changed by RFE it will be a lot harder to get approval. Regards, Vladimir On 6/2/16 6:14 AM, felix.yang at linaro.org wrote: > Changeset: 48a15de056b8 > Author: fyang > Date: 2016-06-02 21:12 +0800 > URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/48a15de056b8 > > 8149418: AArch64: replace tst+br with tbz instruction when tst's constant operand is 2 power > Summary: replace tst+br with tbz instruction when tst's constant operand is 2 power > Reviewed-by: aph > > ! src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp > ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp > ! src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp > ! src/cpu/aarch64/vm/templateTable_aarch64.cpp > From tom.rodriguez at oracle.com Thu Jun 2 17:51:21 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 2 Jun 2016 10:51:21 -0700 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57506343.7040409@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> Message-ID: <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> >>> Therefore, in the current webrev, I've disabled folding of accesses to >>> all non-stable fields. >> Please do not do that, it will be a huge regression in term of perf at least for the language runtimes i maintain >> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf assertions i use routinely, >> static final method handle is considered as constant, final fields (even not static) of VM anonymous class is considered as truly final. >> > > I fully understand your concerns. And thank you for sharing your asserts! The folding within the compiler should be handled differently since the concerns are different and removing it will likely cause invokeynamic performance to collapse. The compiler is only folding final instance fields that are part of a chain of constants, so the main concern is whether an object has been published before it?s been fully constructed or if someone is going to use reflection to modify a final field after the object has been published. The trust_final_non_static_fields logic in ciField.cpp is calling out classes which we control that shouldn?t violate those rules and that are important for performance. So I think it should be left as is. It really doesn?t relate to the issue at hand I think. Also you?ve removed folding of static final fields which would be a very bad thing to do. ciField has some caching logic for _known_to_link_with_get/set and if you are adding a ciMethod* argument you also need to cache the method that was checked last time as well. tom > > Let's see what others think about how to go about this problem. So far the following options were explored > - bail out compilation of non-compliant methods; > - enforce JVMS conformance for all classes and keep constant folding enabled; > - enforce JVMS conformance only for classes with _major_version >=52 and completely disable constant folding. > > I'm not sure which option is the best. Also, there might be other options as well. > > Thank you and best regards, > > > Zoltan > > > >>> We could relax that criteria, e.g., by disabling folding only for those >>> field that were declared in a class with _major_version < 52. But it >>> would be great if you could give me some feedback before I look into >>> that. Thank you very much in advance! >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>> >>> Testing: JPRT in progress. >>> >>> Best regards, >>> >>> >>> Zoltan >> R?mi >> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>>> I agree with you, alternatively we can propose a more generic fix (fix >>>>>> the interpreter and the compilers as well). The fix would most likely >>>>>> affect field resolution in LinkResolver::resolve_field() around here: >>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>> >>>>>> >>>>>> >>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>> inappropriate field access will propagate the exception to the >>>>>> interpreter. Changing ciField::will_link() will most likely kill (some) >>>>>> compilations (if, e.g., fields are linked through >>>>>> ciField::will_link()). >>>>>> >>>>>> I'd prefer to take the second option (changing field resolution), but >>>>>> there might be some disadvantages related to option I might be >>>>>> overseeing. >>>>> >>>>> >>>>> >>>>>> Thank you! >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>> >>>>>>>> More details about the failure are here [3]. >>>>>>>> >>>>>>>> With the patch applied, the program always completes as it is >>>>>>>> expected >>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>> >>>>>>>> Here is the updated webrev: >>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>> Parse::do_field_access). >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> [1] >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Jun 3 00:08:02 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Jun 2016 17:08:02 -0700 Subject: RFR: 8155638: Resource allocated BitMaps are often cleared twice In-Reply-To: <572C7621.7000001@oracle.com> References: <572C7621.7000001@oracle.com> Message-ID: <5750CA62.3060209@oracle.com> Looks good. Thanks, Vladimir On 5/6/16 3:46 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove some redundant clearing of bitmaps. > > http://cr.openjdk.java.net/~stefank/8155638/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8155638 > > > It used to be the case that Resource allocated bitmaps were _not_ cleared in the constructor, and that explicit calls to clear() were needed. However, when G1 was open sourced all the Resource > allocated bitmaps were always cleared in the BitMap constructor: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/diff/37f87013dfd8/src/share/vm/utilities/bitMap.cpp > > > It's apparent that the lazy clearing of bitmaps was used to skip clearing when it wasn't necessary. > > See, for example: > http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/c1/c1_IR.cpp.udiff.html > > where _requires_phi_function is cleared even when all bits are going to be set to 1. > > and: > http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/compiler/methodLiveness.cpp.frames.html > > in MethodLiveness::BasicBlock::get_liveness_at > > 1010 ResourceBitMap g(_gen.size()); g.set_from(_gen); > 1011 ResourceBitMap k(_kill.size()); k.set_from(_kill); > > where we first clear the bitmap, then copy all bits with set_from. Before G1 was introduced, the unnecessary clearing was not done. > > I've created a new CR for these kind of issues: > > https://bugs.openjdk.java.net/browse/JDK-8156207 - Resource allocated BitMaps are often cleared unnecessarily > > > During the review of "8141501: Problems with BitMap buffer management", I got the request do the following change: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/022969.html > > I tried it, but felt that the change didn't fit the surrounding code, where shallow-copying was used for other bitmaps. It would be great if reviewers of this patch could decide if I should change the > code as suggested. > > > Thanks, > StefanK > From vladimir.kozlov at oracle.com Fri Jun 3 00:14:40 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Jun 2016 17:14:40 -0700 Subject: RFR(XS): 8158351: [JVMCI] NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI In-Reply-To: <5091E2EA-C1CF-42FB-9736-5D14CEEA34E7@oracle.com> References: <5091E2EA-C1CF-42FB-9736-5D14CEEA34E7@oracle.com> Message-ID: <5750CBF0.8030706@oracle.com> Good. Thanks, Vladimir On 6/1/16 3:21 PM, Doug Simon wrote: > Please review this trivial test bug fix. > > https://bugs.openjdk.java.net/browse/JDK-8158351 > http://cr.openjdk.java.net/~dnsimon/8158351/ > > -Doug > From stefan.karlsson at oracle.com Fri Jun 3 07:34:37 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 3 Jun 2016 09:34:37 +0200 Subject: RFR: 8155638: Resource allocated BitMaps are often cleared twice In-Reply-To: <5750CA62.3060209@oracle.com> References: <572C7621.7000001@oracle.com> <5750CA62.3060209@oracle.com> Message-ID: <5751330D.40401@oracle.com> Thanks, Vladimir! StefanK On 2016-06-03 02:08, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 5/6/16 3:46 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to remove some redundant clearing of bitmaps. >> >> http://cr.openjdk.java.net/~stefank/8155638/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8155638 >> >> >> It used to be the case that Resource allocated bitmaps were _not_ >> cleared in the constructor, and that explicit calls to clear() were >> needed. However, when G1 was open sourced all the Resource >> allocated bitmaps were always cleared in the BitMap constructor: >> >> http://hg.openjdk.java.net/jdk9/hs/hotspot/diff/37f87013dfd8/src/share/vm/utilities/bitMap.cpp >> >> >> >> It's apparent that the lazy clearing of bitmaps was used to skip >> clearing when it wasn't necessary. >> >> See, for example: >> http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/c1/c1_IR.cpp.udiff.html >> >> >> where _requires_phi_function is cleared even when all bits are going >> to be set to 1. >> >> and: >> http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/compiler/methodLiveness.cpp.frames.html >> >> >> in MethodLiveness::BasicBlock::get_liveness_at >> >> 1010 ResourceBitMap g(_gen.size()); g.set_from(_gen); >> 1011 ResourceBitMap k(_kill.size()); k.set_from(_kill); >> >> where we first clear the bitmap, then copy all bits with set_from. >> Before G1 was introduced, the unnecessary clearing was not done. >> >> I've created a new CR for these kind of issues: >> >> https://bugs.openjdk.java.net/browse/JDK-8156207 - Resource allocated >> BitMaps are often cleared unnecessarily >> >> >> During the review of "8141501: Problems with BitMap buffer >> management", I got the request do the following change: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/022969.html >> >> I tried it, but felt that the change didn't fit the surrounding code, >> where shallow-copying was used for other bitmaps. It would be great >> if reviewers of this patch could decide if I should change the >> code as suggested. >> >> >> Thanks, >> StefanK >> From stefan.karlsson at oracle.com Fri Jun 3 07:35:32 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 3 Jun 2016 09:35:32 +0200 Subject: RFR: 8155638: Resource allocated BitMaps are often cleared twice In-Reply-To: <574FED14.4010404@oracle.com> References: <572C7621.7000001@oracle.com> <574FE89D.8070208@oracle.com> <574FED14.4010404@oracle.com> Message-ID: <57513344.2080905@oracle.com> Thanks for reviewing, Nils! StefanK On 2016-06-02 10:23, Nils Eliasson wrote: > Hi, > > After some additional discussions with Stefan we concluded that it is > better to keep the non-reinitialize version. There is the future > possiblity of reusing the bitmap in every iteration in this loop, but > reinitalize doesn't do that at the moment. And more testing would be > required for such a change. > > Regards, > Nils Eliasson > > On 2016-06-02 10:04, Nils Eliasson wrote: >> Hi Stefan, >> >> I prefer the reinitialize alternative in c1_linearscan.cpp. Please >> use that version. >> >> Reviewed. >> >> Thanks for fixing this! >> Nils >> >> >> On 2016-05-06 12:46, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to remove some redundant clearing of bitmaps. >>> >>> http://cr.openjdk.java.net/~stefank/8155638/webrev.01 >>> https://bugs.openjdk.java.net/browse/JDK-8155638 >>> >>> >>> It used to be the case that Resource allocated bitmaps were _not_ >>> cleared in the constructor, and that explicit calls to clear() were >>> needed. However, when G1 was open sourced all the Resource allocated >>> bitmaps were always cleared in the BitMap constructor: >>> >>> http://hg.openjdk.java.net/jdk9/hs/hotspot/diff/37f87013dfd8/src/share/vm/utilities/bitMap.cpp >>> >>> >>> It's apparent that the lazy clearing of bitmaps was used to skip >>> clearing when it wasn't necessary. >>> >>> See, for example: >>> http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/c1/c1_IR.cpp.udiff.html >>> >>> where _requires_phi_function is cleared even when all bits are going >>> to be set to 1. >>> >>> and: >>> http://cr.openjdk.java.net/~stefank/8155638/webrev.01/src/share/vm/compiler/methodLiveness.cpp.frames.html >>> >>> in MethodLiveness::BasicBlock::get_liveness_at >>> >>> 1010 ResourceBitMap g(_gen.size()); g.set_from(_gen); >>> 1011 ResourceBitMap k(_kill.size()); k.set_from(_kill); >>> >>> where we first clear the bitmap, then copy all bits with set_from. >>> Before G1 was introduced, the unnecessary clearing was not done. >>> >>> I've created a new CR for these kind of issues: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8156207 - Resource >>> allocated BitMaps are often cleared unnecessarily >>> >>> >>> During the review of "8141501: Problems with BitMap buffer >>> management", I got the request do the following change: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/022969.html >>> >>> I tried it, but felt that the change didn't fit the surrounding >>> code, where shallow-copying was used for other bitmaps. It would be >>> great if reviewers of this patch could decide if I should change the >>> code as suggested. >>> >>> >>> Thanks, >>> StefanK >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Fri Jun 3 09:10:12 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 3 Jun 2016 14:40:12 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <3994d1db-5f77-019b-f970-1f2618721fb5@oracle.com> References: <57453D5A.1080000@oracle.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> <29aff9c8-525e-e3d4-56d0-4275a1bc3615@oracle.com> <6e27d0e1-f79f-50a0-a139-d28bb61ff6fb@oracle.com> <3994d1db-5f77-019b-f970-1f2618721fb5@oracle.com> Message-ID: <2385b93f-a65f-2828-33fc-2e822445b9b9@oracle.com> Hi Roland, Addressed all comments: 1) removed xmx settings 2) cleared JVMTI pending early return. 3) Removed Uncommon trap test case(as its heavily tuned, and will not work for most of heap settings). revised webrev: http://cr.openjdk.java.net/~jcm/8146416/webrev.03/ Best Regards, Jamsheed On 6/2/2016 5:33 PM, Jamsheed C m wrote: > > Hi Roland, > > Thank you for the review comments. > > On 6/2/2016 5:02 PM, Roland Westrelin wrote: >>> revised webrev: http://cr.openjdk.java.net/~jcm/8146416/webrev.02/ >> Thanks for making the change. >> >> In vframeArrayElement::unpack_on_stack(), for jvmti's early return, I >> think you want to call state->clear_earlyret_pending() otherwise the >> early ret is still pending and that could lead to an unexpected >> behaviour. > i missed that one, will make the change. >> >> In your test cases, I would suggest bumping the heap size to avoid >> future problems with the test case like this one: >> >> https://bugs.openjdk.java.net/browse/JDK-8042557 > > Ok >> >> Does DeoptReallocFailureUncommonTrap.java cover a case that's not >> covered by test/compiler/uncommontrap/TestDeoptOOM.java? Does it fail >> with jvmci/graal? > i added this test case for uncommon_trap verification. let me check > whether this one duplicate a test in TestDeoptOOM.java. > > Best Regards, > Jamsheed > >> >> Roland. > From rwestrel at redhat.com Fri Jun 3 10:06:27 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 3 Jun 2016 12:06:27 +0200 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <2385b93f-a65f-2828-33fc-2e822445b9b9@oracle.com> References: <57453D5A.1080000@oracle.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> <29aff9c8-525e-e3d4-56d0-4275a1bc3615@oracle.com> <6e27d0e1-f79f-50a0-a139-d28bb61ff6fb@oracle.com> <3994d1db-5f77-019b-f970-1f2618721fb5@oracle.com> <2385b93f-a65f-2828-33fc-2e822445b9b9@oracle.com> Message-ID: <575156A3.9090201@redhat.com> Hi Jamsheed, > Addressed all comments: > > 1) removed xmx settings > > 2) cleared JVMTI pending early return. > > 3) Removed Uncommon trap test case(as its heavily tuned, and will not > work for most of heap settings). > > revised webrev: http://cr.openjdk.java.net/~jcm/8146416/webrev.03/ That looks good to me. It's probably a good idea to keep a large enough -Xmx for the test case. Anyway, that doesn't require a new webrev. Roland. From vladimir.x.ivanov at oracle.com Fri Jun 3 10:26:09 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 3 Jun 2016 13:26:09 +0300 Subject: [9] RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays In-Reply-To: <57504893.3090607@oracle.com> References: <574ED13F.1050003@oracle.com> <51074461-132f-c775-bfe5-d6488cca099a@oracle.com> <57503566.9080801@oracle.com> <1f4211fb-54d9-957d-6e44-651b302a1531@oracle.com> <57504893.3090607@oracle.com> Message-ID: <3606d086-c627-b0b2-f4d7-613e5de031d8@oracle.com> >>> Like this we still have optimal code. What do you think? >> I suggest to completely disable constant folding in Canonicalizer::do_LoadIndexed if LoadIndexed node is marked as mismatched. >> >> Please, leave ciArray::element_value_impl as is. > > Okay, I noticed that C2 also does not fold mismatched accesses. Could you please explain why that is? Primarily to keep the code sane :-) Unsafe accesses are the source of mismatched accesses and additional checks are required to filter out all problematic cases. So, I decided to leave them out when enabled constant folding of unsafe loads. My main motivation for the change was to make method handles for field / array element accesses as fast as using bytecode, and mismatched accesses didn't justify all the complications they cause. > Here's the new webrev: > http://cr.openjdk.java.net/~thartmann/8158228/webrev.02/ Looks good. Best regards, Vladimir Ivanov From jamsheed.c.m at oracle.com Fri Jun 3 10:32:51 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 3 Jun 2016 16:02:51 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized In-Reply-To: <575156A3.9090201@redhat.com> References: <57453D5A.1080000@oracle.com> <5745D977.900@oracle.com> <5746C1F9.2000405@redhat.com> <5746C65A.5010207@oracle.com> <5746DD9B.3080606@redhat.com> <5746ED38.2050005@oracle.com> <5746ED82.5050906@redhat.com> <5747B28A.7030603@oracle.com> <5747FAB1.6030908@redhat.com> <574811B9.2000301@oracle.com> <5748590A.10607@oracle.com> <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> <574EDB6E.2050401@redhat.com> <90e15845-95ad-1845-3d23-26fd41ce9f8a@oracle.com> <9ff2adae-b765-075a-5e94-7d70ddbc939e@oracle.com> <29aff9c8-525e-e3d4-56d0-4275a1bc3615@oracle.com> <6e27d0e1-f79f-50a0-a139-d28bb61ff6fb@oracle.com> <3994d1db-5f77-019b-f970-1f2618721fb5@oracle.com> <2385b93f-a65f-2828-33fc-2e822445b9b9@oracle.com> <575156A3.9090201@redhat.com> Message-ID: <87080321-a576-1371-c2bf-55495e6e4328@oracle.com> On 6/3/2016 3:36 PM, Roland Westrelin wrote: > That looks good to me. It's probably a good idea to keep a large enough > -Xmx for the test case. Anyway, that doesn't require a new webrev. Sure. Thank you, Roland! Best Regards, Jamsheed From vladimir.x.ivanov at oracle.com Fri Jun 3 10:59:11 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 3 Jun 2016 13:59:11 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> Message-ID: (forgot to add hotspot-compiler-dev@) Best regards, Vladimir Ivanov On 6/3/16 1:48 PM, Vladimir Ivanov wrote: > > > On 6/3/16 7:11 AM, Vladimir Kozlov wrote: >> How about only fixing C1 to take into account the store (or not constant >> fold in such case) because it was allowed before JVMS-7? >> >> And file a separate issue for JVMS-7 conformance. It looks like it may >> have huge impact on performance and we are already very late in JDK 9 >> development to make such changes in rush. > > Yes, let's separate them (considering the difference in impact) and > align the JVM behavior with the JVMS separately. > > For now, disabling constant folding of static/instance field loads in > static/instance initializers should solve the immediate problem for > well-behaved (according to JVMS) programs. Also, such change should not > cause any performance regressions. > > Considering it is possible to update static final fields through > Reflection API, I don't see JVMS conformance issue (ability to update > final static fields outside of static initializer on bytecode level) as > a problem of the same level for JIT-compilers. It can be fixed as part > of aligning the JVM with JVMS (but still in JDK9). > > Best regards, > Vladimir Ivanov > >> >> Zoltan, what C2 does in such case? >> Tom, what Graal does in such case? >> >> The case is: >> >> https://bugs.openjdk.java.net/browse/JDK-8157181?focusedCommentId=13942824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13942824 >> >> >> >> "While compiling bytecode @29, the C1 compiler assumes that the value of >> the _pyx0.self field has already been set in the class initializer >> method (as the class is initialized). The C1 compiler also >> assumes that the field will not change (as it is static final). >> Therefore, the C1 compiler omits reading the field _pyx0.self and passes >> the current value of the field ('null') to the >> org/python/core/Py.newCode() method called at bytecode @37. (The correct >> value would be 'this'.)" >> >> Thanks, >> Vladimir >> >> On 6/2/16 10:51 AM, Tom Rodriguez wrote: >>>>>> Therefore, in the current webrev, I've disabled folding of >>>>>> accesses to >>>>>> all non-stable fields. >>>>> Please do not do that, it will be a huge regression in term of perf >>>>> at least for the language runtimes i maintain >>>>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf >>>>> assertions i use routinely, >>>>> static final method handle is considered as constant, final fields >>>>> (even not static) of VM anonymous class is considered as truly final. >>>>> >>>> >>>> I fully understand your concerns. And thank you for sharing your >>>> asserts! >>> >>> The folding within the compiler should be handled differently since >>> the concerns are different and removing it will likely cause >>> invokeynamic performance to collapse. The compiler is only folding >>> final instance fields that are part of a chain of constants, so the >>> main concern is whether an object has been published before it?s been >>> fully constructed or if someone is going to use reflection to >>> modify a final field after the object has been published. The >>> trust_final_non_static_fields logic in ciField.cpp is calling out >>> classes which we control that shouldn?t violate those rules and that >>> are important for performance. So I think it should be left as is. >>> It really doesn?t relate to the issue at hand I think. >>> >>> Also you?ve removed folding of static final fields which would be a >>> very bad thing to do. >>> >>> ciField has some caching logic for _known_to_link_with_get/set and if >>> you are adding a ciMethod* argument you also need to cache the method >>> that was checked last time as well. >>> >>> tom >>> >>>> >>>> Let's see what others think about how to go about this problem. So >>>> far the following options were explored >>>> - bail out compilation of non-compliant methods; >>>> - enforce JVMS conformance for all classes and keep constant folding >>>> enabled; >>>> - enforce JVMS conformance only for classes with _major_version >=52 >>>> and completely disable constant folding. >>>> >>>> I'm not sure which option is the best. Also, there might be other >>>> options as well. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>> >>>>>> We could relax that criteria, e.g., by disabling folding only for >>>>>> those >>>>>> field that were declared in a class with _major_version < 52. But it >>>>>> would be great if you could give me some feedback before I look into >>>>>> that. Thank you very much in advance! >>>>>> >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>>>> >>>>>> Testing: JPRT in progress. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>> R?mi >>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>>> I agree with you, alternatively we can propose a more generic >>>>>>>>> fix (fix >>>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>>> likely >>>>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>>>> here: >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>>>> (some) >>>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>>> ciField::will_link()). >>>>>>>>> >>>>>>>>> I'd prefer to take the second option (changing field >>>>>>>>> resolution), but >>>>>>>>> there might be some disadvantages related to option I might be >>>>>>>>> overseeing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Zoltan >>>>>>>>> >>>>>>>>> >>>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>>> >>>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>>> expected >>>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>>> (because we >>>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>>> >>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>>> appropriate. It >>>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>>> Parse::do_field_access). >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>>> >>>>>>>>>> >>> From tobias.hartmann at oracle.com Fri Jun 3 13:07:21 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 3 Jun 2016 15:07:21 +0200 Subject: [9] RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays In-Reply-To: <3606d086-c627-b0b2-f4d7-613e5de031d8@oracle.com> References: <574ED13F.1050003@oracle.com> <51074461-132f-c775-bfe5-d6488cca099a@oracle.com> <57503566.9080801@oracle.com> <1f4211fb-54d9-957d-6e44-651b302a1531@oracle.com> <57504893.3090607@oracle.com> <3606d086-c627-b0b2-f4d7-613e5de031d8@oracle.com> Message-ID: <57518109.4050905@oracle.com> Hi Vladimir, On 03.06.2016 12:26, Vladimir Ivanov wrote: >>>> Like this we still have optimal code. What do you think? >>> I suggest to completely disable constant folding in Canonicalizer::do_LoadIndexed if LoadIndexed node is marked as mismatched. >>> >>> Please, leave ciArray::element_value_impl as is. >> >> Okay, I noticed that C2 also does not fold mismatched accesses. Could you please explain why that is? > > Primarily to keep the code sane :-) Unsafe accesses are the source of mismatched accesses and additional checks are required to filter out all problematic cases. So, I decided to leave them out when enabled constant folding of unsafe loads. My main motivation for the change was to make method handles for field / array element accesses as fast as using bytecode, and mismatched accesses didn't justify all the complications they cause. Okay, but in the case of the getChar intrinsic it should be safe to fold the mismatched access without additional checks, right? >> Here's the new webrev: >> http://cr.openjdk.java.net/~thartmann/8158228/webrev.02/ > > Looks good. Thank you! Best regards, Tobias > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Jun 3 13:28:43 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 3 Jun 2016 16:28:43 +0300 Subject: [9] RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays In-Reply-To: <57518109.4050905@oracle.com> References: <574ED13F.1050003@oracle.com> <51074461-132f-c775-bfe5-d6488cca099a@oracle.com> <57503566.9080801@oracle.com> <1f4211fb-54d9-957d-6e44-651b302a1531@oracle.com> <57504893.3090607@oracle.com> <3606d086-c627-b0b2-f4d7-613e5de031d8@oracle.com> <57518109.4050905@oracle.com> Message-ID: <20c658e2-c085-2dbe-9715-8631245eafde@oracle.com> >> Primarily to keep the code sane :-) Unsafe accesses are the source of mismatched accesses and additional checks are required to filter out all problematic cases. So, I decided to leave them out when enabled constant folding of unsafe loads. My main motivation for the change was to make method handles for field / array element accesses as fast as using bytecode, and mismatched accesses didn't justify all the complications they cause. > > Okay, but in the case of the getChar intrinsic it should be safe to fold the mismatched access without additional checks, right? Yes, it will. But naive Java implementation does the job as good. C2 intrinsic has the following code [1]: bool LibraryCallKit::inline_string_char_access(bool is_store) { ... // Bail when getChar over constants is requested: constant folding would // reject folding mismatched char access over byte[]. A normal inlining for getChar // Java method would constant fold nicely instead. if (!is_store && value->is_Con() && index->is_Con()) { return false; } You can do the same in C1. While browsing the code, I noticed the following in j.l.StringUTF16: @HotSpotIntrinsicCandidate public static char getChar(byte[] val, int index) { index <<= 1; return (char)(((val[index++] & 0xff) << HI_BYTE_SHIFT) | ((val[index] & 0xff) << LO_BYTE_SHIFT)); } public static char charAt(byte[] value, int index) { if (index < 0 || index >= value.length >> 1) { throw new StringIndexOutOfBoundsException(index); } return getChar(value, index); } _getCharStringU doesn't do any out-of-bounds checks, but StringUTF16.getChar() is pervasively used across java.lang. Is it intentional? I'd expect to see StringUTF16.getChar() private and users calling StringUTF16.charAt(). Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/7f42e988b083/src/share/vm/opto/library_call.cpp#l1629 From jlent at tivo.com Thu Jun 2 15:56:32 2016 From: jlent at tivo.com (James Lent) Date: Thu, 2 Jun 2016 11:56:32 -0400 Subject: Java 8 Performance Issue With Tiered Compilation Disabled Message-ID: <57505730.402@tivo.com> We are running a Solr/Lucene based server on Java 8: openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-b14) OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) Recently we tried to run with Tiered Compilation disabled: -XX:-TieredCompilation In production the system performed very well for about 70 hours and then performance start to degrade very sharply. HotSpot logs indicated that 100s of methods had reached their recompile limit. A sample of the logs is below: made not compilable on levels 0 1 2 3 4 java.lang.String::equals (81 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.lucene.util.OpenBitSetIterator::nextDoc (136 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.solr.search.SolrConstantScoreQuery$ConstantScorer::score (5 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.roaringbitmap.Util::fillArrayAND (92 bytes) decompile_count > PerMethodRecompilationCutoff The methods that hit this limit include Java, Lucene, Solr, and RoaringBitMap methods. I was able to reproduce this in a dev environment by just running very light real world traffic. What I observed was that many methods were being recompiled 3 or more times per hour. I was able to "fix" this issue by one of two methods: 1) Increase max code cache size: -XX:ReservedCodeCacheSize=240m 2) Disable code cache flushing: -XX:-UseCodeCacheFlushing After running for over 12 hours the maximum number of decompiles for a method is 14 and that method hit 11 decompiles very quickly and then leveled off (with the first fix it is still at 11). Only 7 methods have 8 or more decompiles and this has held steady for hours now). I also tried the following based on a suggestion from Chris Newland, but, it did not help: -XX:-UseBimorphicInlining My theory is that the Code Cache flushing algorithm coupled with the Code Cache demands of my application are causing the HotSpot compiler to "thrash". Keep cycling the methods through the Code Cache: 1) Compile method A 2) Compile method B 3) Kick out method A and compile method C 4) Kick out method B and compile method A Observations: 1) When Tiered Compilation is disabled the Code Cache max drops from 240mb to 48mb. 2) When not constrained (i.e. when one of my two "fixes" is applied) my application under this traffic load levels out at just below 22mb in the Code Cache. 3) When neither of my fixes is applied then the Code Cache usage peaks about 18mb, but, is highly variable minute to minute. We are planning to implement fix one above in production soon. Any comments? I can provide HotSpot logs. Chris has provided me the required options to get the more detailed information. ________________________________ This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement. From doug.simon at oracle.com Fri Jun 3 20:35:11 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 3 Jun 2016 22:35:11 +0200 Subject: RFR(S): 8156587: [JVMCI] remove Unsafe.getJavaMirror and Unsafe.getKlassPointer Message-ID: <3B348DD8-2723-4007-8917-AF1162A36120@oracle.com> Please review this removal of unused Unsafe methods that were originally intended for JVMCI usage but never ended up being used. https://bugs.openjdk.java.net/browse/JDK-8156587 http://cr.openjdk.java.net/~dnsimon/8156587/jdk http://cr.openjdk.java.net/~dnsimon/8156587/hotspot -Doug From vladimir.kozlov at oracle.com Fri Jun 3 20:43:46 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 3 Jun 2016 13:43:46 -0700 Subject: RFR(S): 8156587: [JVMCI] remove Unsafe.getJavaMirror and Unsafe.getKlassPointer In-Reply-To: <3B348DD8-2723-4007-8917-AF1162A36120@oracle.com> References: <3B348DD8-2723-4007-8917-AF1162A36120@oracle.com> Message-ID: <1ed3918c-31d2-edd0-5642-48d43f1e394c@oracle.com> Thank you, Doug Looks good. I will push it after testing. Thanks, Vladimir On 6/3/16 1:35 PM, Doug Simon wrote: > Please review this removal of unused Unsafe methods that were originally intended for JVMCI usage but never ended up being used. > > https://bugs.openjdk.java.net/browse/JDK-8156587 > http://cr.openjdk.java.net/~dnsimon/8156587/jdk > http://cr.openjdk.java.net/~dnsimon/8156587/hotspot > > -Doug > From tobias.hartmann at oracle.com Mon Jun 6 08:00:33 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Jun 2016 10:00:33 +0200 Subject: Java 8 Performance Issue With Tiered Compilation Disabled In-Reply-To: <57505730.402@tivo.com> References: <57505730.402@tivo.com> Message-ID: <57552DA1.6040205@oracle.com> Hi James, thanks for the report, please find some questions below. On 02.06.2016 17:56, James Lent wrote: > We are running a Solr/Lucene based server on Java 8: > > openjdk version "1.8.0_91" > OpenJDK Runtime Environment (build 1.8.0_91-b14) > OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) > > Recently we tried to run with Tiered Compilation disabled: > > -XX:-TieredCompilation > > In production the system performed very well for about 70 hours and then > performance start to degrade very sharply. HotSpot logs indicated that > 100s of methods had reached their recompile limit. A sample of the logs > is below: > > made not compilable on levels 0 1 2 3 4 java.lang.String::equals (81 > bytes) decompile_count > PerMethodRecompilationCutoff > made not compilable on levels 0 1 2 3 4 > org.apache.lucene.util.OpenBitSetIterator::nextDoc (136 bytes) > decompile_count > PerMethodRecompilationCutoff > made not compilable on levels 0 1 2 3 4 > org.apache.solr.search.SolrConstantScoreQuery$ConstantScorer::score (5 > bytes) decompile_count > PerMethodRecompilationCutoff > made not compilable on levels 0 1 2 3 4 > org.roaringbitmap.Util::fillArrayAND (92 bytes) decompile_count > > PerMethodRecompilationCutoff > > The methods that hit this limit include Java, Lucene, Solr, and > RoaringBitMap methods. > > I was able to reproduce this in a dev environment by just running very > light real world traffic. What I observed was that many methods were > being recompiled 3 or more times per hour. > > I was able to "fix" this issue by one of two methods: > > 1) Increase max code cache size: > > -XX:ReservedCodeCacheSize=240m > > 2) Disable code cache flushing: > > -XX:-UseCodeCacheFlushing > > After running for over 12 hours the maximum number of decompiles for a > method is 14 and that method hit 11 decompiles very quickly and then > leveled off (with the first fix it is still at 11). Only 7 methods have > 8 or more decompiles and this has held steady for hours now). > > I also tried the following based on a suggestion from Chris Newland, > but, it did not help: > > -XX:-UseBimorphicInlining > > My theory is that the Code Cache flushing algorithm coupled with the > Code Cache demands of my application are causing the HotSpot compiler to > "thrash". Keep cycling the methods through the Code Cache: > > 1) Compile method A > 2) Compile method B > 3) Kick out method A and compile method C > 4) Kick out method B and compile method A > > Observations: > > 1) When Tiered Compilation is disabled the Code Cache max drops from > 240mb to 48mb. Did the problem also show up with Tiered Compilation? > 2) When not constrained (i.e. when one of my two "fixes" is applied) my > application under this traffic load levels out at just below 22mb in the > Code Cache. > 3) When neither of my fixes is applied then the Code Cache usage peaks > about 18mb, but, is highly variable minute to minute. You could try to use a lower value of -XX:NmethodSweepActivity to avoid aggressive sweeping when the code cache is getting full. But I doubt that this helps because there is still enough space in the code cache. > We are planning to implement fix one above in production soon. Any > comments? I think increasing the code cache size does not hurt and prevents aggressive sweeping in this case because a larger code cache size leads to a larger per method hotness threshold for flushing. Did you try to reproduce the problem with a JDK 9 early access build? The symptoms you are describing sound quite similar to an issue we encountered with JDK 9. This was fixed by code aging [1] but the fix was never backported to JDK 8. You can enable/disable code aging with -XX:UseCodeAging in 9. If the problem turns out to be fixed, we could provide a prototype backport of code aging for testing in your environment. Best regards, Tobias [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/975d903e1de3 > I can provide HotSpot logs. Chris has provided me the required options > to get the more detailed information. > > ________________________________ > > This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement. From tobias.hartmann at oracle.com Mon Jun 6 10:56:58 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Jun 2016 12:56:58 +0200 Subject: [9] RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays In-Reply-To: <20c658e2-c085-2dbe-9715-8631245eafde@oracle.com> References: <574ED13F.1050003@oracle.com> <51074461-132f-c775-bfe5-d6488cca099a@oracle.com> <57503566.9080801@oracle.com> <1f4211fb-54d9-957d-6e44-651b302a1531@oracle.com> <57504893.3090607@oracle.com> <3606d086-c627-b0b2-f4d7-613e5de031d8@oracle.com> <57518109.4050905@oracle.com> <20c658e2-c085-2dbe-9715-8631245eafde@oracle.com> Message-ID: <575556FA.9010608@oracle.com> Hi Vladimir, On 03.06.2016 15:28, Vladimir Ivanov wrote: > >>> Primarily to keep the code sane :-) Unsafe accesses are the source of mismatched accesses and additional checks are required to filter out all problematic cases. So, I decided to leave them out when enabled constant folding of unsafe loads. My main motivation for the change was to make method handles for field / array element accesses as fast as using bytecode, and mismatched accesses didn't justify all the complications they cause. >> >> Okay, but in the case of the getChar intrinsic it should be safe to fold the mismatched access without additional checks, right? > Yes, it will. But naive Java implementation does the job as good. > > C2 intrinsic has the following code [1]: > > bool LibraryCallKit::inline_string_char_access(bool is_store) { > ... > // Bail when getChar over constants is requested: constant folding would > // reject folding mismatched char access over byte[]. A normal inlining for getChar > // Java method would constant fold nicely instead. > if (!is_store && value->is_Con() && index->is_Con()) { > return false; > } > > You can do the same in C1. Right, this code was added by JDK-8150180. When bailing out from the intrinsic we still have the chance to constant fold the accesses from the Java implementation. However, this seems to only work fine with C2 but not with C1: http://cr.openjdk.java.net/~thartmann/8158228/webrev.03/ The generated code looks like this: 0x00007f7b19597d12: mov $0x6d4e01688,%rdx // Array address 0x00007f7b19597d1c: cmpl $0xd,0xc(%rdx) 0x00007f7b19597d23: jbe 0x00007f7b19597ef9 0x00007f7b19597d29: movsbl 0x1d(%rdx),%edx // Byte load 0x00007f7b19597d2d: and $0xff,%edx 0x00007f7b19597d33: shl $0x8,%edx 0x00007f7b19597d36: or $0x67,%edx 0x00007f7b19597d39: and $0xffff,%edx 0x00007f7b19597d3f: and $0xffff,%edx 0x00007f7b19597d45: and $0xffff,%edx 0x00007f7b19597d4b: and $0xffff,%edx 0x00007f7b19597d51: mov %rdx,%rbx 0x00007f7b19597d54: cmp $0x67,%ebx C1 is not able to fold the second byte load that is shifted by 8 bits. With webrev.02 (using the intrinsic but not constant folding the loads) it looks like this: 0x00007fb780714cea: mov $0x6d4e01688,%rdx 0x00007fb780714cf4: movzwl 0x1c(%rdx),%edx 0x00007fb780714cf8: and $0xffff,%edx 0x00007fb780714cfe: and $0xffff,%edx 0x00007fb780714d04: mov %rdx,%rbx 0x00007fb780714d07: cmp $0x67,%ebx I would therefore prefer to go with webrev.02. What do you think? > While browsing the code, I noticed the following in j.l.StringUTF16: > > @HotSpotIntrinsicCandidate > public static char getChar(byte[] val, int index) { > index <<= 1; > return (char)(((val[index++] & 0xff) << HI_BYTE_SHIFT) | > ((val[index] & 0xff) << LO_BYTE_SHIFT)); > } > > public static char charAt(byte[] value, int index) { > if (index < 0 || index >= value.length >> 1) { > throw new StringIndexOutOfBoundsException(index); > } > return getChar(value, index); > } > > _getCharStringU doesn't do any out-of-bounds checks, but StringUTF16.getChar() is pervasively used across java.lang. > > Is it intentional? I'd expect to see StringUTF16.getChar() private and users calling StringUTF16.charAt(). Yes, this is/was intentional. See my explanation here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/023047.html "The problem is that some of the intrinsified String methods are heavily used and C2 is not always able to remove the range checks introduced by the public wrapper method. For example, StringUTF16::getChar() is used in places where we implicitly know that the access is in bounds (for example, because the array length is always a multiple of two) but C2 cannot prove this. Therefore, if we want to avoid a regression, we have to call the unchecked version of the intrinsic in some cases." I completely agree that we should try to avoid this and I plan to revisit the issue with JDK-8156534. Thanks, Tobias > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/7f42e988b083/src/share/vm/opto/library_call.cpp#l1629 From vladimir.x.ivanov at oracle.com Mon Jun 6 11:11:26 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 6 Jun 2016 14:11:26 +0300 Subject: [9] RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays In-Reply-To: <575556FA.9010608@oracle.com> References: <574ED13F.1050003@oracle.com> <51074461-132f-c775-bfe5-d6488cca099a@oracle.com> <57503566.9080801@oracle.com> <1f4211fb-54d9-957d-6e44-651b302a1531@oracle.com> <57504893.3090607@oracle.com> <3606d086-c627-b0b2-f4d7-613e5de031d8@oracle.com> <57518109.4050905@oracle.com> <20c658e2-c085-2dbe-9715-8631245eafde@oracle.com> <575556FA.9010608@oracle.com> Message-ID: >>> Okay, but in the case of the getChar intrinsic it should be safe to fold the mismatched access without additional checks, right? >> Yes, it will. But naive Java implementation does the job as good. >> >> C2 intrinsic has the following code [1]: >> >> bool LibraryCallKit::inline_string_char_access(bool is_store) { >> ... >> // Bail when getChar over constants is requested: constant folding would >> // reject folding mismatched char access over byte[]. A normal inlining for getChar >> // Java method would constant fold nicely instead. >> if (!is_store && value->is_Con() && index->is_Con()) { >> return false; >> } >> >> You can do the same in C1. > > Right, this code was added by JDK-8150180. When bailing out from the intrinsic we still have the chance to constant fold the accesses from the Java implementation. > > However, this seems to only work fine with C2 but not with C1: > http://cr.openjdk.java.net/~thartmann/8158228/webrev.03/ You could take a different route and issue 2 byte loads instead of 1 mismatched char load in the intrinsic when byte[] and element index are constants. But I don't think that constant folding of chars from String is crucial in C1-generated code. > The generated code looks like this: > > 0x00007f7b19597d12: mov $0x6d4e01688,%rdx // Array address > 0x00007f7b19597d1c: cmpl $0xd,0xc(%rdx) > 0x00007f7b19597d23: jbe 0x00007f7b19597ef9 > 0x00007f7b19597d29: movsbl 0x1d(%rdx),%edx // Byte load > 0x00007f7b19597d2d: and $0xff,%edx > 0x00007f7b19597d33: shl $0x8,%edx > 0x00007f7b19597d36: or $0x67,%edx > 0x00007f7b19597d39: and $0xffff,%edx > 0x00007f7b19597d3f: and $0xffff,%edx > 0x00007f7b19597d45: and $0xffff,%edx > 0x00007f7b19597d4b: and $0xffff,%edx > 0x00007f7b19597d51: mov %rdx,%rbx > 0x00007f7b19597d54: cmp $0x67,%ebx > > C1 is not able to fold the second byte load that is shifted by 8 bits. > > With webrev.02 (using the intrinsic but not constant folding the loads) it looks like this: > > 0x00007fb780714cea: mov $0x6d4e01688,%rdx > 0x00007fb780714cf4: movzwl 0x1c(%rdx),%edx > 0x00007fb780714cf8: and $0xffff,%edx > 0x00007fb780714cfe: and $0xffff,%edx > 0x00007fb780714d04: mov %rdx,%rbx > 0x00007fb780714d07: cmp $0x67,%ebx > > I would therefore prefer to go with webrev.02. What do you think? Agree. webrev.02 looks good enough to me. >> While browsing the code, I noticed the following in j.l.StringUTF16: >> >> @HotSpotIntrinsicCandidate >> public static char getChar(byte[] val, int index) { >> index <<= 1; >> return (char)(((val[index++] & 0xff) << HI_BYTE_SHIFT) | >> ((val[index] & 0xff) << LO_BYTE_SHIFT)); >> } >> >> public static char charAt(byte[] value, int index) { >> if (index < 0 || index >= value.length >> 1) { >> throw new StringIndexOutOfBoundsException(index); >> } >> return getChar(value, index); >> } >> >> _getCharStringU doesn't do any out-of-bounds checks, but StringUTF16.getChar() is pervasively used across java.lang. >> >> Is it intentional? I'd expect to see StringUTF16.getChar() private and users calling StringUTF16.charAt(). > > Yes, this is/was intentional. See my explanation here: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/023047.html > > "The problem is that some of the intrinsified String methods are heavily used and C2 is not always able to remove the range checks introduced by the public wrapper method. For example, StringUTF16::getChar() is used in places where we implicitly know that the access is in bounds (for example, because the array length is always a multiple of two) but C2 cannot prove this. Therefore, if we want to avoid a regression, we have to call the unchecked version of the intrinsic in some cases." > > I completely agree that we should try to avoid this and I plan to revisit the issue with JDK-8156534. No problem. Just wanted to double-check. Also, noticed redundant bounds checks: @Override public char charAt(int index) { checkIndex(index, count); if (isLatin1()) { return (char)(value[index] & 0xff); } return StringUTF16.charAt(value, index); } ... public static char charAt(byte[] value, int index) { if (index < 0 || index >= value.length >> 1) { throw new StringIndexOutOfBoundsException(index); } return getChar(value, index); } Best regards, Vladimir Ivanov From tobias.hartmann at oracle.com Mon Jun 6 11:22:46 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Jun 2016 13:22:46 +0200 Subject: [9] RFR(S): 8158228: C1 incorrectly folds mismatched loads from stable arrays In-Reply-To: References: <574ED13F.1050003@oracle.com> <51074461-132f-c775-bfe5-d6488cca099a@oracle.com> <57503566.9080801@oracle.com> <1f4211fb-54d9-957d-6e44-651b302a1531@oracle.com> <57504893.3090607@oracle.com> <3606d086-c627-b0b2-f4d7-613e5de031d8@oracle.com> <57518109.4050905@oracle.com> <20c658e2-c085-2dbe-9715-8631245eafde@oracle.com> <575556FA.9010608@oracle.com> Message-ID: <57555D06.1020909@oracle.com> Hi Vladimir, thanks again for the review. On 06.06.2016 13:11, Vladimir Ivanov wrote: > >>>> Okay, but in the case of the getChar intrinsic it should be safe to fold the mismatched access without additional checks, right? >>> Yes, it will. But naive Java implementation does the job as good. >>> >>> C2 intrinsic has the following code [1]: >>> >>> bool LibraryCallKit::inline_string_char_access(bool is_store) { >>> ... >>> // Bail when getChar over constants is requested: constant folding would >>> // reject folding mismatched char access over byte[]. A normal inlining for getChar >>> // Java method would constant fold nicely instead. >>> if (!is_store && value->is_Con() && index->is_Con()) { >>> return false; >>> } >>> >>> You can do the same in C1. >> >> Right, this code was added by JDK-8150180. When bailing out from the intrinsic we still have the chance to constant fold the accesses from the Java implementation. >> >> However, this seems to only work fine with C2 but not with C1: >> http://cr.openjdk.java.net/~thartmann/8158228/webrev.03/ > > You could take a different route and issue 2 byte loads instead of 1 mismatched char load in the intrinsic when byte[] and element index are constants. > > But I don't think that constant folding of chars from String is crucial in C1-generated code. I don't think so either, so I would like to avoid special casing the intrinsic. >> The generated code looks like this: >> >> 0x00007f7b19597d12: mov $0x6d4e01688,%rdx // Array address >> 0x00007f7b19597d1c: cmpl $0xd,0xc(%rdx) >> 0x00007f7b19597d23: jbe 0x00007f7b19597ef9 >> 0x00007f7b19597d29: movsbl 0x1d(%rdx),%edx // Byte load >> 0x00007f7b19597d2d: and $0xff,%edx >> 0x00007f7b19597d33: shl $0x8,%edx >> 0x00007f7b19597d36: or $0x67,%edx >> 0x00007f7b19597d39: and $0xffff,%edx >> 0x00007f7b19597d3f: and $0xffff,%edx >> 0x00007f7b19597d45: and $0xffff,%edx >> 0x00007f7b19597d4b: and $0xffff,%edx >> 0x00007f7b19597d51: mov %rdx,%rbx >> 0x00007f7b19597d54: cmp $0x67,%ebx >> >> C1 is not able to fold the second byte load that is shifted by 8 bits. > >> >> With webrev.02 (using the intrinsic but not constant folding the loads) it looks like this: >> >> 0x00007fb780714cea: mov $0x6d4e01688,%rdx >> 0x00007fb780714cf4: movzwl 0x1c(%rdx),%edx >> 0x00007fb780714cf8: and $0xffff,%edx >> 0x00007fb780714cfe: and $0xffff,%edx >> 0x00007fb780714d04: mov %rdx,%rbx >> 0x00007fb780714d07: cmp $0x67,%ebx >> >> I would therefore prefer to go with webrev.02. What do you think? > > Agree. webrev.02 looks good enough to me. Okay, thanks. I'll go with webrev.02 then: http://cr.openjdk.java.net/~thartmann/8158228/webrev.02/ >>> While browsing the code, I noticed the following in j.l.StringUTF16: >>> >>> @HotSpotIntrinsicCandidate >>> public static char getChar(byte[] val, int index) { >>> index <<= 1; >>> return (char)(((val[index++] & 0xff) << HI_BYTE_SHIFT) | >>> ((val[index] & 0xff) << LO_BYTE_SHIFT)); >>> } >>> >>> public static char charAt(byte[] value, int index) { >>> if (index < 0 || index >= value.length >> 1) { >>> throw new StringIndexOutOfBoundsException(index); >>> } >>> return getChar(value, index); >>> } >>> >>> _getCharStringU doesn't do any out-of-bounds checks, but StringUTF16.getChar() is pervasively used across java.lang. >>> >>> Is it intentional? I'd expect to see StringUTF16.getChar() private and users calling StringUTF16.charAt(). >> >> Yes, this is/was intentional. See my explanation here: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/023047.html >> >> "The problem is that some of the intrinsified String methods are heavily used and C2 is not always able to remove the range checks introduced by the public wrapper method. For example, StringUTF16::getChar() is used in places where we implicitly know that the access is in bounds (for example, because the array length is always a multiple of two) but C2 cannot prove this. Therefore, if we want to avoid a regression, we have to call the unchecked version of the intrinsic in some cases." >> >> I completely agree that we should try to avoid this and I plan to revisit the issue with JDK-8156534. > > No problem. Just wanted to double-check. > > Also, noticed redundant bounds checks: > @Override > public char charAt(int index) { > checkIndex(index, count); > if (isLatin1()) { > return (char)(value[index] & 0xff); > } > return StringUTF16.charAt(value, index); > } > ... > public static char charAt(byte[] value, int index) { > if (index < 0 || index >= value.length >> 1) { > throw new StringIndexOutOfBoundsException(index); > } > return getChar(value, index); > } Thanks, I added this to JDK-8156534. Best regards, Tobias > > Best regards, > Vladimir Ivanov From jlent at tivo.com Mon Jun 6 12:52:06 2016 From: jlent at tivo.com (James Lent) Date: Mon, 6 Jun 2016 08:52:06 -0400 Subject: Java 8 Performance Issue With Tiered Compilation Disabled In-Reply-To: <57552DA1.6040205@oracle.com> References: <57505730.402@tivo.com> <57552DA1.6040205@oracle.com> Message-ID: <575571F6.2040101@tivo.com> Thanks for your interest. Answer in-line. On 06/06/2016 04:00 AM, Tobias Hartmann wrote: Hi James, thanks for the report, please find some questions below. On 02.06.2016 17:56, James Lent wrote: We are running a Solr/Lucene based server on Java 8: openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-b14) OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) Recently we tried to run with Tiered Compilation disabled: -XX:-TieredCompilation In production the system performed very well for about 70 hours and then performance start to degrade very sharply. HotSpot logs indicated that 100s of methods had reached their recompile limit. A sample of the logs is below: made not compilable on levels 0 1 2 3 4 java.lang.String::equals (81 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.lucene.util.OpenBitSetIterator::nextDoc (136 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.solr.search.SolrConstantScoreQuery$ConstantScorer::score (5 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.roaringbitmap.Util::fillArrayAND (92 bytes) decompile_count > PerMethodRecompilationCutoff The methods that hit this limit include Java, Lucene, Solr, and RoaringBitMap methods. I was able to reproduce this in a dev environment by just running very light real world traffic. What I observed was that many methods were being recompiled 3 or more times per hour. I was able to "fix" this issue by one of two methods: 1) Increase max code cache size: -XX:ReservedCodeCacheSize=240m 2) Disable code cache flushing: -XX:-UseCodeCacheFlushing After running for over 12 hours the maximum number of decompiles for a method is 14 and that method hit 11 decompiles very quickly and then leveled off (with the first fix it is still at 11). Only 7 methods have 8 or more decompiles and this has held steady for hours now). I also tried the following based on a suggestion from Chris Newland, but, it did not help: -XX:-UseBimorphicInlining My theory is that the Code Cache flushing algorithm coupled with the Code Cache demands of my application are causing the HotSpot compiler to "thrash". Keep cycling the methods through the Code Cache: 1) Compile method A 2) Compile method B 3) Kick out method A and compile method C 4) Kick out method B and compile method A Observations: 1) When Tiered Compilation is disabled the Code Cache max drops from 240mb to 48mb. Did the problem also show up with Tiered Compilation? This problem did not. Of course with tiered compilation enabled the code cache max seems to default to 240mb. I did not try running tiered with a smaller max code cache size. I did not that tiered seems to use a lot more code cache. The same application exceeds 70mb when it is enabled. However with tiered compilations enabled we were seeing a hard to understand drop in performance after about 4.5 hours in both production (2 second response times suddenly jump to 3 to 5 seconds). I was able to reproduce this issue in a dev environment with surprisingly little trouble. I investigated this issue from many angles to try to understand what was going on (heap, linux file cache, background network traffic, processor load, EC2 variability). The one thing that did seem to work in dev was turning off Tiered compilation (a desperation idea). I have not been able to identify any interesting compiler logs that correlate with that issue. When we tried it in production it worked very well for 70 hours and then this issue occurred which was actually much worse. I was not a hero. I sent an email on this first issue to the hotspot-dev mailing list (before the "turn off tiered compilation fix" failed in production), but, was not expecting much help because I could not provide much data to work with. Just a description of the symptoms. 2) When not constrained (i.e. when one of my two "fixes" is applied) my application under this traffic load levels out at just below 22mb in the Code Cache. 3) When neither of my fixes is applied then the Code Cache usage peaks about 18mb, but, is highly variable minute to minute. You could try to use a lower value of -XX:NmethodSweepActivity to avoid aggressive sweeping when the code cache is getting full. But I doubt that this helps because there is still enough space in the code cache. I will try to give it a try as time permits, but, I have torn down my dev environment for now. I was able to reproduce this issue right on my dev box, but doing so consumes most of its resources. I may try to set it up before I leave tonight. We are planning to implement fix one above in production soon. Any comments? I think increasing the code cache size does not hurt and prevents aggressive sweeping in this case because a larger code cache size leads to a larger per method hotness threshold for flushing. Did you try to reproduce the problem with a JDK 9 early access build? The symptoms you are describing sound quite similar to an issue we encountered with JDK 9. This was fixed by code aging [1] but the fix was never backported to JDK 8. You can enable/disable code aging with -XX:UseCodeAging in 9. If the problem turns out to be fixed, we could provide a prototype backport of code aging for testing in your environment. Thanks for the info. I have not tried with Java 9. I will put that on the list to try. Best regards, Tobias [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/975d903e1de3 I can provide HotSpot logs. Chris has provided me the required options to get the more detailed information. ________________________________ This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement. James Lent Senior Software Engineer Digitalsmiths A TiVo Company www.digitalsmiths.com jlent at digitalsmiths.com | office 919.460.4747 ________________________________ This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rednaxelafx at gmail.com Tue Jun 7 01:43:39 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 6 Jun 2016 18:43:39 -0700 Subject: Update C1Visualizer for JDK8+ (post-NPG)? Message-ID: Hi guys, This probably isn't the best mailing list for the topic, but the audience should cover a lot of the developers/users of C1Visualizer, so here I go: It looks like even the latest C1Visualizer doesn't handle CFG files produced by a JDK8+ HotSpot C1 well, due to the NoPermGen/Metadata changes. For instance, the following is an excerpt from a CFG file produced by a JDK8u76 build: begin_intervals name "Before Register Allocation" 0 fixed "[rsi|I]" 0 -1 [0, 4[ [48, 50[ [60, 61[ "no spill store" 1 fixed "[rdi|I]" 1 187 [0, 1[ [58, 61[ "no spill store" 2 fixed "[rbx|I]" 2 -1 [0, 1[ [60, 61[ "no definition" 3 fixed "[rax|I]" 3 185 [0, 1[ [10, 11[ [60, 61[ [152, 153[ [154, 155[ [156, 158[ "no optimization" 4 fixed "[rdx|I]" 4 -1 [0, 6[ [60, 61[ "no definition" 5 fixed "[rcx|I]" 5 -1 [0, 1[ [60, 61[ "no definition" 6 fixed "[r8|I]" 6 -1 [0, 1[ [60, 61[ "no definition" 7 fixed "[r9|I]" 7 -1 [0, 1[ [60, 61[ "no definition" 8 fixed "[r11|I]" 8 -1 [0, 1[ [60, 61[ "no definition" 9 fixed "[r13|I]" 9 -1 [0, 1[ [60, 61[ "no definition" 10 fixed "[r14|I]" 10 -1 [0, 1[ [60, 61[ "no definition" 177 object 177 0 [4, 27[ 4 M 10 M "no spill store" 178 object 178 4 [6, 38[ 6 M 38 S "no spill store" 179 int 179 -1 [8, 11[ 8 M 10 M "no spill store" 180 object 180 -1 [10, 11[ 10 M "no definition" 181 *metadata* 181 -1 [12, 18[ 12 M 14 M 18 M "no spill store" 182 int 182 -1 [14, 24[ 14 M 16 M 18 M 22 M 24 M "no optimization" 183 *metadata* 183 -1 [20, 26[ 20 M 26 M "no spill store" The "*metadata*" type is new from the NPG change, and apparently C1Visualizer doesn't recognize that. If I open this file with the latest C1Visualizer, I get a couple of errors saying: Error while parsing input: -- line 936 col 5: ident expected ... In C1Visualizer/Compilation Model/src/at/ssw/visualizer/parser/CompilationOutput.atg, CHARACTERS identCh = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-|:". cr = '\r'. lf = '\n'. TOKENS ident = identCh { identCh }. The identCh rule should be updated to include '*', so that it'll be able to parse "*metadata*", "*narrowoop*", etc. (as in HotSpot's globalDefinitions.cpp type2name_tab). In C1Visualizer/Interval Editor/src/at/ssw/visualizer/interval/ViewSettings.java, typeIntervalColors = new HashMap(); typeIntervalColors.put("fixed", new Color(128, 128, 128)); typeIntervalColors.put("object", new Color(192, 64, 255)); typeIntervalColors.put("int", new Color(64, 192, 255)); typeIntervalColors.put("long", new Color(0, 128, 255)); typeIntervalColors.put("float", new Color(192, 255, 64)); typeIntervalColors.put("double", new Color(128, 255, 0)); The constructor of ViewSettings should include colors for the *...* types such as *metadata* and *narrowoop*. Is there anybody on the list that would be able to put the fix into C1Visualizer? Any help would be appreciated. Best regards, Kris (OpenJDK username: kmo) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Leonid.Mesnik at oracle.com Tue Jun 7 09:34:56 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Tue, 7 Jun 2016 12:34:56 +0300 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: References: <5746FDF3.3030102@oracle.com> Message-ID: <57569540.9010106@oracle.com> Hi Added jtreg-use at openjdk.java.net I think that you are right. Here is the documentation: http://openjdk.java.net/jtreg/tag-spec.html "@requires Express a dependence on characteristics of the system being tested. Some harnesses allow tests to be selected according to the characteristics of the system being tested. The expression may be composed of the following elements:" "os.arch The operating system architecture, as given by the corresponding system property." So user could expect to have "os.arch" of tested VM. If filed jtreg issues for this: 1. CODETOOLS-7901695 jtreg uses value 'os.arch' property of JDK which executed JDK and not of tested JDK Following fix could be used as a temporary workaround while jtreg fix is not ready. Does it make a sense? I this case it is needed to change linux-arm64 back to linux-aarch64 to minimize changes. Leonid On 31.05.2016 04:26, David Holmes wrote: > Hi Leonid, > > This really strikes me as as a jtreg problem that should be fixed in > jtreg. When writing an @requires clause in a test the test writer > should not have to be thinking "oh wait! Is this going to query the VM > running jtreg or the VM running the test?". It should obviously be the > VM running the test. > > That said we also seem to have a problem with the definition of os.arch: > > os.arch Operating system architecture > > if it is returning the build architecture of the VM and not the OS it > is running on. That in itself argues for two distinct properties. > > David > > On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >> Hi >> >> Could you please review following fix: >> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >> >> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >> >> for bug >> https://bugs.openjdk.java.net/browse/JDK-8157831 >> >> >> The property "os.name" which was used to filter tests depends on the >> arch of jdk which is used to run jtreg. It might differ from arch of >> tested jdk. >> This fix introduce new property "vm.arch" which depends on the arch of >> tested jdk and could be used to filter tests with @requires. >> >> I verified that tests are filtered where it is expected. >> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >> testing. >> >> Leonid >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.nevill at gmail.com Tue Jun 7 10:26:01 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 07 Jun 2016 11:26:01 +0100 Subject: 8158913: RFR: aarch64: SEGV running Spark terasort Message-ID: <1465295161.28716.13.camel@mylittlepony.linaroharston> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8158913/webrev/ JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8158913 The problem occurs in gen_write_ref_array_post_barrier in the following code __ BIND(L_loop); __ strb(zr, Address(start, count)); __ subs(count, count, 1); __ br(Assembler::HS, L_loop); which, when given a count of 0 will continue zeroing memory beyond the end of the byte map because of the use of unsigned comparison. Both x86 and Sparc use a signed comparison here. The webrev above just changes the unsigned comparison to signed to match x86 and sparc. However, in the case that count is 0 there will will still be one store to the byte map. This is harmless as it just means that it unnecessarily dirties an entry in the byte map (provided that the start address is correct). Is this the correct fix. Or is it better to fix all of x86, spark, etc so that they do not do any stores when the count is 0? All the best, Ed. From aph at redhat.com Tue Jun 7 12:17:23 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 Jun 2016 13:17:23 +0100 Subject: [aarch64-port-dev ] 8158913: RFR: aarch64: SEGV running Spark terasort In-Reply-To: <1465295161.28716.13.camel@mylittlepony.linaroharston> References: <1465295161.28716.13.camel@mylittlepony.linaroharston> Message-ID: <5756BB53.4000407@redhat.com> On 07/06/16 11:26, Edward Nevill wrote: > Is this the correct fix. I'm kinda surprised that we even get to that code when the count is zero, but I can see where it's being called from. OK. Andrew. From doug.simon at oracle.com Tue Jun 7 22:03:46 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 8 Jun 2016 00:03:46 +0200 Subject: RFR: 8158985: [JVMCI] access to HotSpotJVMCIRuntime.vmEventListeners must be thread safe Message-ID: https://bugs.openjdk.java.net/browse/JDK-8158985 http://cr.openjdk.java.net/~dnsimon/8158985/ -Doug From vladimir.kozlov at oracle.com Tue Jun 7 22:17:46 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Jun 2016 15:17:46 -0700 Subject: RFR: 8158985: [JVMCI] access to HotSpotJVMCIRuntime.vmEventListeners must be thread safe In-Reply-To: References: Message-ID: <6ffa474a-6ec6-3dfe-177c-c957e2d72340@oracle.com> Would be nice to have more meaningful name for listener: HotSpotVMEventListener l; You used vmEventListener in other places. Thanks, Vladimir On 6/7/16 3:03 PM, Doug Simon wrote: > https://bugs.openjdk.java.net/browse/JDK-8158985 > http://cr.openjdk.java.net/~dnsimon/8158985/ > > -Doug > From igor.veresov at oracle.com Tue Jun 7 22:18:40 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 7 Jun 2016 15:18:40 -0700 Subject: RFR: 8158985: [JVMCI] access to HotSpotJVMCIRuntime.vmEventListeners must be thread safe In-Reply-To: References: Message-ID: <43BBA7CD-E407-491F-A063-9D3BD0C1A7F2@oracle.com> It seems possible that the callers of getVmEventListeners() would be able to see a partially formed list, right? May be delay assignment to vmEventListeners until the list is fully formed? igor > On Jun 7, 2016, at 3:03 PM, Doug Simon wrote: > > https://bugs.openjdk.java.net/browse/JDK-8158985 > http://cr.openjdk.java.net/~dnsimon/8158985/ > > -Doug From doug.simon at oracle.com Tue Jun 7 23:04:12 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 8 Jun 2016 01:04:12 +0200 Subject: RFR: 8158985: [JVMCI] access to HotSpotJVMCIRuntime.vmEventListeners must be thread safe In-Reply-To: <6ffa474a-6ec6-3dfe-177c-c957e2d72340@oracle.com> References: <6ffa474a-6ec6-3dfe-177c-c957e2d72340@oracle.com> Message-ID: Thanks for the suggestion - I updated the webrev with the suggested name. > On 08 Jun 2016, at 00:17, Vladimir Kozlov wrote: > > Would be nice to have more meaningful name for listener: > > HotSpotVMEventListener l; > > You used vmEventListener in other places. > > Thanks, > Vladimir > > On 6/7/16 3:03 PM, Doug Simon wrote: >> https://bugs.openjdk.java.net/browse/JDK-8158985 >> http://cr.openjdk.java.net/~dnsimon/8158985/ >> >> -Doug >> From doug.simon at oracle.com Tue Jun 7 23:04:31 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 8 Jun 2016 01:04:31 +0200 Subject: RFR: 8158985: [JVMCI] access to HotSpotJVMCIRuntime.vmEventListeners must be thread safe In-Reply-To: <43BBA7CD-E407-491F-A063-9D3BD0C1A7F2@oracle.com> References: <43BBA7CD-E407-491F-A063-9D3BD0C1A7F2@oracle.com> Message-ID: <372B9092-FDC1-4037-9611-8AF8EB6748D6@oracle.com> Thanks for the suggestion - I updated the webrev with the suggested change. > On 08 Jun 2016, at 00:18, Igor Veresov wrote: > > It seems possible that the callers of getVmEventListeners() would be able to see a partially formed list, right? > May be delay assignment to vmEventListeners until the list is fully formed? > > igor > >> On Jun 7, 2016, at 3:03 PM, Doug Simon wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8158985 >> http://cr.openjdk.java.net/~dnsimon/8158985/ >> >> -Doug > From vladimir.kozlov at oracle.com Tue Jun 7 23:15:06 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Jun 2016 16:15:06 -0700 Subject: RFR: 8158985: [JVMCI] access to HotSpotJVMCIRuntime.vmEventListeners must be thread safe In-Reply-To: <372B9092-FDC1-4037-9611-8AF8EB6748D6@oracle.com> References: <43BBA7CD-E407-491F-A063-9D3BD0C1A7F2@oracle.com> <372B9092-FDC1-4037-9611-8AF8EB6748D6@oracle.com> Message-ID: <63fb99f8-62fd-9f9a-9367-59cd220f4f49@oracle.com> + for (HotSpotVMEventListener vmEventListener : ServiceLoader.load(HotSpotVMEventListener.class)) { + vmEventListeners.add(vmEventListener); should be listeners.add(vmEventListener); + } + vmEventListeners = listeners; On 6/7/16 4:04 PM, Doug Simon wrote: > Thanks for the suggestion - I updated the webrev with the suggested change. > >> On 08 Jun 2016, at 00:18, Igor Veresov wrote: >> >> It seems possible that the callers of getVmEventListeners() would be able to see a partially formed list, right? >> May be delay assignment to vmEventListeners until the list is fully formed? >> >> igor >> >>> On Jun 7, 2016, at 3:03 PM, Doug Simon wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8158985 >>> http://cr.openjdk.java.net/~dnsimon/8158985/ >>> >>> -Doug >> > From doug.simon at oracle.com Tue Jun 7 23:27:28 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 8 Jun 2016 01:27:28 +0200 Subject: RFR: 8158985: [JVMCI] access to HotSpotJVMCIRuntime.vmEventListeners must be thread safe In-Reply-To: <63fb99f8-62fd-9f9a-9367-59cd220f4f49@oracle.com> References: <43BBA7CD-E407-491F-A063-9D3BD0C1A7F2@oracle.com> <372B9092-FDC1-4037-9611-8AF8EB6748D6@oracle.com> <63fb99f8-62fd-9f9a-9367-59cd220f4f49@oracle.com> Message-ID: <5946289A-BD7A-4E99-9E5B-4D36426B5B69@oracle.com> I should go to bed! ;-) Fixed in the webrev. > On 08 Jun 2016, at 01:15, Vladimir Kozlov wrote: > > + for (HotSpotVMEventListener vmEventListener : ServiceLoader.load(HotSpotVMEventListener.class)) { > + vmEventListeners.add(vmEventListener); > > should be listeners.add(vmEventListener); > > + } > + vmEventListeners = listeners; > > > On 6/7/16 4:04 PM, Doug Simon wrote: >> Thanks for the suggestion - I updated the webrev with the suggested change. >> >>> On 08 Jun 2016, at 00:18, Igor Veresov wrote: >>> >>> It seems possible that the callers of getVmEventListeners() would be able to see a partially formed list, right? >>> May be delay assignment to vmEventListeners until the list is fully formed? >>> >>> igor >>> >>>> On Jun 7, 2016, at 3:03 PM, Doug Simon wrote: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8158985 >>>> http://cr.openjdk.java.net/~dnsimon/8158985/ >>>> >>>> -Doug >>> >> From vladimir.kozlov at oracle.com Wed Jun 8 00:06:36 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Jun 2016 17:06:36 -0700 Subject: RFR: 8158985: [JVMCI] access to HotSpotJVMCIRuntime.vmEventListeners must be thread safe In-Reply-To: <5946289A-BD7A-4E99-9E5B-4D36426B5B69@oracle.com> References: <43BBA7CD-E407-491F-A063-9D3BD0C1A7F2@oracle.com> <372B9092-FDC1-4037-9611-8AF8EB6748D6@oracle.com> <63fb99f8-62fd-9f9a-9367-59cd220f4f49@oracle.com> <5946289A-BD7A-4E99-9E5B-4D36426B5B69@oracle.com> Message-ID: Good. I will sponsor it. Thanks, Vladimir On 6/7/16 4:27 PM, Doug Simon wrote: > I should go to bed! ;-) > > Fixed in the webrev. > >> On 08 Jun 2016, at 01:15, Vladimir Kozlov wrote: >> >> + for (HotSpotVMEventListener vmEventListener : ServiceLoader.load(HotSpotVMEventListener.class)) { >> + vmEventListeners.add(vmEventListener); >> >> should be listeners.add(vmEventListener); >> >> + } >> + vmEventListeners = listeners; >> >> >> On 6/7/16 4:04 PM, Doug Simon wrote: >>> Thanks for the suggestion - I updated the webrev with the suggested change. >>> >>>> On 08 Jun 2016, at 00:18, Igor Veresov wrote: >>>> >>>> It seems possible that the callers of getVmEventListeners() would be able to see a partially formed list, right? >>>> May be delay assignment to vmEventListeners until the list is fully formed? >>>> >>>> igor >>>> >>>>> On Jun 7, 2016, at 3:03 PM, Doug Simon wrote: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8158985 >>>>> http://cr.openjdk.java.net/~dnsimon/8158985/ >>>>> >>>>> -Doug >>>> >>> > From rahul.v.raghavan at oracle.com Wed Jun 8 07:14:52 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 8 Jun 2016 00:14:52 -0700 (PDT) Subject: RFR: 8151661: Performance regression on Solaris-SPARC in 9-b103 Message-ID: <42cb523b-2cc3-4b62-9725-8a7cdd7f14b0@default> Hi, Please review following patch for JDK- 8151661. : http://cr.openjdk.java.net/~rraghavan/8151661/webrev.00/ 1. : https://bugs.openjdk.java.net/browse/JDK-8151661 Performance regression reported with internal benchmark harness on Solaris-SPARC in JDK9-b103 build onwards. 2. Found that following adlc change done as part of old JDK-8145438 fix as the root cause of the Performance regression. (https://bugs.openjdk.java.net/browse/JDK-8145438 - Guarantee failures since 8144028: Use AArch64 bit-test instructions in C2) (https://bugs.openjdk.java.net/browse/JDK-8144028 - Use AArch64 bit-test instructions in C2) (http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/558ddc947c8d ) [src/share/vm/adlc/formssel.cpp] bool InstructForm::check_branch_variant(ArchDesc &AD, InstructForm *short_branch) { if (_matrule != NULL && this != short_branch && // Don't match myself !is_short_branch() && // Don't match another short branch variant reduce_result() != NULL && strcmp(reduce_result(), short_branch->reduce_result()) == 0 && - _matrule->equivalent(AD.globalNames(), short_branch->_matrule)) { + _matrule->equivalent(AD.globalNames(), short_branch->_matrule) && + equivalent_predicates(this, short_branch)) { // The instructions are equivalent. 3. The extra 'equivalent_predicates()' check added is not working for following 'long / short' branchNode variants combinations for SPARC. (in sparc.ad - only the short variants got 'predicate(UseCBCond)' and no predicate set for long variants) branchNode / branch_shortNode cmpI_reg_branchNode / cmpI_reg_branch_shortNode cmpI_imm_branchNode / cmpI_imm_branch_shortNode cmpU_reg_branchNode / cmpU_reg_branch_shortNode cmpU_imm_branchNode / cmpU_imm_branch_shortNode cmpL_reg_branchNode / cmpL_reg_branch_shortNode cmpL_imm_branchNode / cmpL_imm_branch_shortNode cmpP_reg_branchNode / cmpP_reg_branch_shortNode cmpP_null_branchNode / cmpP_null_branch_shortNode cmpN_reg_branchNode / cmpN_reg_branch_shortNode cmpN_null_branchNode / cmpN_null_branch_shortNode cmpI_reg_branchLoopEndNode / cmpI_reg_branchLoopEnd_shortNode cmpI_imm_branchLoopEndNode / cmpI_imm_branchLoopEnd_shortNode 4. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020450.html >From this old 8145438 - RFR email thread, seems the adlc change was done independently, not as an integral part of original 8145438/8144028 -fix. The same change was done based on the assumption that short and long branch variants cannot have different predicates. But this is wrong for above SPARC cases. Reverting only the adlc change, could not find any issues with - JPRT testing (default -testset hotspot) , 'hotspot/test/compiler/codegen/8144028/BitTests.java' jtreg test run for Sparc, AArch64) So in general predicates for short and long branches could be different and should not be compared for check_branch_variant()! The above proposed webrev.00 fix proposal is the same reverting earlier 8145438 adlc change. Thanks, Rahul From rahul.v.raghavan at oracle.com Wed Jun 8 07:38:31 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 8 Jun 2016 00:38:31 -0700 (PDT) Subject: RFR: 8151661: Performance regression on Solaris-SPARC in 9-b103 Message-ID: <7f065da6-c1f4-4f17-a52b-cda265a88f78@default> > -----Original Message----- > From: Rahul Raghavan > Sent: Wednesday, June 08, 2016 12:45 PM > To: hotspot-compiler-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: RFR: 8151661: Performance regression on Solaris-SPARC in 9-b103 Hi, Please review following patch for JDK- 8151661. : http://cr.openjdk.java.net/~rraghavan/8151661/webrev.00/ 1. : https://bugs.openjdk.java.net/browse/JDK-8151661 Performance regression reported with internal benchmark harness on Solaris-SPARC in JDK9-b103 build onwards. 2. Found that following adlc change done as part of old JDK-8145438 fix as the root cause of the Performance regression. (https://bugs.openjdk.java.net/browse/JDK-8145438 - Guarantee failures since 8144028: Use AArch64 bit-test instructions in C2) (https://bugs.openjdk.java.net/browse/JDK-8144028 - Use AArch64 bit-test instructions in C2) (http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/558ddc947c8d) [src/share/vm/adlc/formssel.cpp] bool InstructForm::check_branch_variant(ArchDesc &AD, InstructForm *short_branch) { if (_matrule != NULL && this != short_branch && // Don't match myself !is_short_branch() && // Don't match another short branch variant reduce_result() != NULL && strcmp(reduce_result(), short_branch->reduce_result()) == 0 && - _matrule->equivalent(AD.globalNames(), short_branch->_matrule)) { + _matrule->equivalent(AD.globalNames(), short_branch->_matrule) && + equivalent_predicates(this, short_branch)) { // The instructions are equivalent. 3. The extra 'equivalent_predicates()' check added is not working for following 'long / short' branchNode variants combinations for SPARC. (in sparc.ad - only the short variants got 'predicate(UseCBCond)' and no predicate set for long variants) branchNode / branch_shortNode cmpI_reg_branchNode / cmpI_reg_branch_shortNode cmpI_imm_branchNode / cmpI_imm_branch_shortNode cmpU_reg_branchNode / cmpU_reg_branch_shortNode cmpU_imm_branchNode / cmpU_imm_branch_shortNode cmpL_reg_branchNode / cmpL_reg_branch_shortNode cmpL_imm_branchNode / cmpL_imm_branch_shortNode cmpP_reg_branchNode / cmpP_reg_branch_shortNode cmpP_null_branchNode / cmpP_null_branch_shortNode cmpN_reg_branchNode / cmpN_reg_branch_shortNode cmpN_null_branchNode / cmpN_null_branch_shortNode cmpI_reg_branchLoopEndNode / cmpI_reg_branchLoopEnd_shortNode cmpI_imm_branchLoopEndNode / cmpI_imm_branchLoopEnd_shortNode 4. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020450.html >From this old 8145438 - RFR email thread, seems the adlc change was done independently, not as an integral part of original 8145438/8144028 -fix. The same change was done based on the assumption that short and long branch variants cannot have different predicates. But this is wrong for above SPARC cases. Reverting only the adlc change, could not find any issues with - JPRT testing (default -testset hotspot) , 'hotspot/test/compiler/codegen/8144028/BitTests.java' jtreg test run for Sparc, AArch64) So in general predicates for short and long branches could be different and should not be compared for check_branch_variant()! The above proposed webrev.00 fix proposal is the same reverting earlier 8145438 adlc change. Thanks, Rahul From aph at redhat.com Wed Jun 8 08:22:45 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Jun 2016 09:22:45 +0100 Subject: RFR: 8151661: Performance regression on Solaris-SPARC in 9-b103 In-Reply-To: <42cb523b-2cc3-4b62-9725-8a7cdd7f14b0@default> References: <42cb523b-2cc3-4b62-9725-8a7cdd7f14b0@default> Message-ID: <5757D5D5.6000806@redhat.com> On 08/06/16 08:14, Rahul Raghavan wrote: > 4. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020450.html > From this old 8145438 - RFR email thread, seems the adlc change was > done independently, not as an integral part of original > 8145438/8144028 -fix. > The same change was done based on the assumption that short and long > branch variants cannot have different predicates. > But this is wrong for above SPARC cases. > Reverting only the adlc change, could not find any issues with - > JPRT testing (default -testset hotspot) , 'hotspot/test/compiler/codegen/8144028/BitTests.java' jtreg test run for Sparc, AArch64) > > So in general predicates for short and long branches could be > different and should not be compared for check_branch_variant()! > The above proposed webrev.00 fix proposal is the same reverting > earlier 8145438 adlc change. That just re-introduces the bug. check_branch_variant() is suposed to test whether one branch can be replaced by another, and the predicate may be an important part of that. For example, in the case of AArch64 some predicates test if an operand is a power of two: only then may a bit test and branch instruction be used. The versions of branch with and without this test are not semantically equivalent, so one branch cannot be replaced by another. I wonder if there is a better way to solve this problem without weakening check_branch_variant(). The fact that it didn't check predicates to see if one branch can be replaced by another was a bug. It was a useful bug, sure, but still a bug. We could -- in extremis -- #ifdef AARCH64 in check_branch_variant(), but it would be better to find another way to do it. For example, we could define a semantic_predicate and use that. That way we would separate predicates which change the meaning of patterns from those which merely enable them based on some global flag. Andrew. From edward.nevill at gmail.com Wed Jun 8 15:25:45 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 08 Jun 2016 16:25:45 +0100 Subject: RFR: 8159063: aarch64: optimise unaligned array copy long Message-ID: <1465399545.18136.11.camel@mylittlepony.linaroharston> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8159063/webrev JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8159063 This webrev optimises the code generate for copy array long to ensure that loads/stores are always done on 128 bit boundaries. This can be switched on/off with -XX:+/-AvoidUnalignedAccesses which is set by default for those partners where there is a benefit. The following is my test case. http://cr.openjdk.java.net/~enevill/8159063/ArrayCopyAligned.java To run do java ArrayCopyAligned This shows the results for partners A and B with the parameters 10 0 1024 32. http://cr.openjdk.java.net/~enevill/8159063/arraycopy.pdf OK to push to jdk8u now (and later to jdk9)? Thanks, Ed. From aph at redhat.com Wed Jun 8 15:36:33 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Jun 2016 16:36:33 +0100 Subject: [aarch64-port-dev ] RFR: 8159063: aarch64: optimise unaligned array copy long In-Reply-To: <1465399545.18136.11.camel@mylittlepony.linaroharston> References: <1465399545.18136.11.camel@mylittlepony.linaroharston> Message-ID: <57583B81.5020008@redhat.com> On 08/06/16 16:25, Edward Nevill wrote: > http://cr.openjdk.java.net/~enevill/8159063/arraycopy.pdf > > OK to push to jdk8u now (and later to jdk9)? Hmm. This looks a bit risky. I'm prepared to approve it for jdk9, but jdk8 is production code. So no, please don't push it. Andrew. From vladimir.kozlov at oracle.com Wed Jun 8 16:01:54 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 8 Jun 2016 09:01:54 -0700 Subject: RFR: 8159063: aarch64: optimise unaligned array copy long In-Reply-To: <1465399545.18136.11.camel@mylittlepony.linaroharston> References: <1465399545.18136.11.camel@mylittlepony.linaroharston> Message-ID: <4331ad27-6c58-712e-4bf1-34972fee8cfc@oracle.com> Please, hold on pushing this RFE into jdk 9. We are post FC and it needs approval. Thanks, Vladimir On 6/8/16 8:25 AM, Edward Nevill wrote: > Hi, > > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8159063/webrev > > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8159063 > > This webrev optimises the code generate for copy array long to ensure > that loads/stores are always done on 128 bit boundaries. > > This can be switched on/off with -XX:+/-AvoidUnalignedAccesses which is > set by default for those partners where there is a benefit. > > The following is my test case. > > http://cr.openjdk.java.net/~enevill/8159063/ArrayCopyAligned.java > > To run do > > java ArrayCopyAligned > > This shows the results for partners A and B with the parameters 10 0 > 1024 32. > > http://cr.openjdk.java.net/~enevill/8159063/arraycopy.pdf > > OK to push to jdk8u now (and later to jdk9)? > > Thanks, > Ed. > > From aph at redhat.com Wed Jun 8 16:04:48 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Jun 2016 17:04:48 +0100 Subject: RFR: 8159063: aarch64: optimise unaligned array copy long In-Reply-To: <4331ad27-6c58-712e-4bf1-34972fee8cfc@oracle.com> References: <1465399545.18136.11.camel@mylittlepony.linaroharston> <4331ad27-6c58-712e-4bf1-34972fee8cfc@oracle.com> Message-ID: <57584220.8060804@redhat.com> On 08/06/16 17:01, Vladimir Kozlov wrote: > Please, hold on pushing this RFE into jdk 9. We are post FC and it needs > approval. Yeah, we know. It won't be pushed to JDK9. However, I'm still going to review it. Andrew. From vladimir.kozlov at oracle.com Wed Jun 8 16:27:24 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 8 Jun 2016 09:27:24 -0700 Subject: RFR: 8151661: Performance regression on Solaris-SPARC in 9-b103 In-Reply-To: <5757D5D5.6000806@redhat.com> References: <42cb523b-2cc3-4b62-9725-8a7cdd7f14b0@default> <5757D5D5.6000806@redhat.com> Message-ID: <4903f7eb-7dfa-11c8-2d8e-f5404cce0ba8@oracle.com> Hi Andrew, > the predicates. It makes no sense at all for short and long variants > to have different predicates, so suspect this is a bug in adlc. I think this statement is not correct as SPARC problem shows. New branch instructions could be introduced on new CPU (cbcond in this case) and it usage will be guarded by predicate in .ad file. In such case predicates for long and short branches will be different. I also understand your case when you use predicate to check condition code. Yes, in such case you have to match predicates. But the same result you can get with specialized cmpOp operands. And specialized immI (for op2) when you check is_power_of_2(). Regards, Vladimir On 6/8/16 1:22 AM, Andrew Haley wrote: > On 08/06/16 08:14, Rahul Raghavan wrote: > >> 4. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020450.html > >> From this old 8145438 - RFR email thread, seems the adlc change was >> done independently, not as an integral part of original >> 8145438/8144028 -fix. > >> The same change was done based on the assumption that short and long >> branch variants cannot have different predicates. > >> But this is wrong for above SPARC cases. > >> Reverting only the adlc change, could not find any issues with - >> JPRT testing (default -testset hotspot) , 'hotspot/test/compiler/codegen/8144028/BitTests.java' jtreg test run for Sparc, AArch64) >> >> So in general predicates for short and long branches could be >> different and should not be compared for check_branch_variant()! > >> The above proposed webrev.00 fix proposal is the same reverting >> earlier 8145438 adlc change. > > That just re-introduces the bug. check_branch_variant() is suposed to > test whether one branch can be replaced by another, and the predicate > may be an important part of that. For example, in the case of AArch64 > some predicates test if an operand is a power of two: only then may a > bit test and branch instruction be used. The versions of branch with > and without this test are not semantically equivalent, so one branch > cannot be replaced by another. > > I wonder if there is a better way to solve this problem without > weakening check_branch_variant(). The fact that it didn't check > predicates to see if one branch can be replaced by another was a bug. > It was a useful bug, sure, but still a bug. > > We could -- in extremis -- #ifdef AARCH64 in check_branch_variant(), > but it would be better to find another way to do it. For example, we > could define a semantic_predicate and use that. That way we would > separate predicates which change the meaning of patterns from those > which merely enable them based on some global flag. > > Andrew. > From zoltan.majo at oracle.com Wed Jun 8 17:52:17 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 19:52:17 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> Message-ID: <57585B51.1020503@oracle.com> Hi Vladimir, thank you for the feedback. Please see comments inline. On 06/02/2016 12:47 PM, Vladimir Ivanov wrote: > Zoltan, > > (broadening the audience to hotspot-dev@) > > I'd like to draw attention from Runtime group to this change. >> OK, so I have implemented a generic fix that adds the checks required by >> the JVMS. >> >> For bytecodes modifying final fields, the VM checks >> - that the accessing method is (for static fields) >> - that the accessing method is (for instance fields) >> and thrown an IllegalAccessError if any of the checks fails. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.02/ > > Regarding tightening linkage checks, your fix doesn't take into > account JVMS changes between 6 & 7 (expected behavior differs > depending on class file version). > > Before JVMS-7, where putfield/putstatic linkage checks were tightened, > it was allowed to change final fields from anywhere in the same class. > > putfield "Linking Exceptions": > > JVMS-6 [1]: > "Otherwise, if the field is final, it must be declared in the > current class. Otherwise, an IllegalAccessError is thrown." > > JVMS-7 [2]: > "Otherwise, if the field is final, it must be declared in the > current class, and the instruction must occur in an instance > initialization method () of the current class. Otherwise, an > IllegalAccessError is thrown." Thanks for drawing attention of the different specification for version 6. > > > src/share/vm/interpreter/linkResolver.cpp: > > + (byte == Bytecodes::_putstatic && fd.is_static() && > method_name != vmSymbols::class_initializer_name()) || > + ((byte == Bytecodes::_putfield || byte == > Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != > vmSymbols::object_initializer_name()) > > > Also, as we found earlier, checking method name is not enough: > > bool Method::is_static_initializer() const { > // For classfiles version 51 or greater, ensure that the clinit > method is > // static. Non-static methods with the name "" are not static > // initializers. (older classfiles exempted for backward compatibility) > return name() == vmSymbols::class_initializer_name() && > has_valid_initializer_flags(); > } Right. I missed that issue, but have addressed it in the latest webrev (webrev.06). > > > - LinkInfo link_info(defc, name, type, KlassHandle(), > /*check_access=*/false); > + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, > /*check_access=*/false); > > Use Handle() instead of NULL. It seems that methodHandle() works better for these cases, but... (see below) > > > Also, I'd prefer to see LinkInfo::_current_method and new constructor > added: > > LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* signature, > Handle current_method, bool check_access = true) : > > _current_klass can be derived from _current_method, since: > > // current_klass = sending method holder (i.e., class containing > the method > // containing the call being resolved) ... I've added two new constructors. One of them derives _current_method from _current_klass, the other uses methodHandle() within the constructor. Please see the updated webrev (webrev.06) in the reply to Vladimir K. Best regards, Zoltan > >> I did the following testing: >> - JPRT >> - pre-PIT RBT run (in progress) >> - the reproducer. >> >> The reproducer now behaves as expected (an IllegalAccessError is >> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >> >> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >> >> The reason for the failure is that the the test generates a method that >> contains a putstatic to a static final field (i.e., the bytecodes >> generated by the test do not conform to the JVMS). (Even the test >> mentions that the Java source equivalent to the generated bytecodes is >> compilable only if the "final" keyword is removed from the declaration >> of the static field.) >> >> So (if we decide to push the current fix) the issue with the test needs >> to be fixed first. Do you know how we could proceed with that? > File a bug against JCK. > > Best regards, > Vladimir Ivanov > > [1] > https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html > > [2] > https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield > > [3] > https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 > >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>>> >>>> I agree with you, alternatively we can propose a more generic fix (fix >>>> the interpreter and the compilers as well). The fix would most likely >>>> affect field resolution in LinkResolver::resolve_field() around here: >>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>> >>>> >>>> >>>> >>>> Changing resolve_field() to throw an IllegalAccessError for >>>> inappropriate field access will propagate the exception to the >>>> interpreter. Changing ciField::will_link() will most likely kill >>>> (some) >>>> compilations (if, e.g., fields are linked through >>>> ciField::will_link()). >>>> >>>> I'd prefer to take the second option (changing field resolution), but >>>> there might be some disadvantages related to option I might be >>>> overseeing. >>> >>> >>> >>> >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>>> >>>>>> More details about the failure are here [3]. >>>>>> >>>>>> With the patch applied, the program always completes as it is >>>>>> expected >>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>>> always interpret methods non-conforming with the VM spec). >>>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>> should generate an uncommon trap for such accesses instead (see >>>>> Parse::do_field_access). >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>> >>>>> >>>>> >>>> >> From zoltan.majo at oracle.com Wed Jun 8 17:52:54 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 19:52:54 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> Message-ID: <57585B76.5050809@oracle.com> Hi David, On 06/02/2016 01:51 PM, David Holmes wrote: > [...] > The simplest, and common, approach to these kind of issues is to only > apply the correction for the current class file version and keep the > relaxed rules for all others. That provides the best compatibility > story. Of course if security is a concern then that is a different > matter - but such concerns can not be discussed here. thank you for the suggestion! In the latest webrev (webrev.06), I enable the additional check for classfile version >= 51 (JAVA_7_VERSION). With that version, we're conforming with the specification. So far no problems have showed up with our test base. The new check can be disabled with the CheckFinalFieldModifications flag (you've suggested that in your JBS comment). We can also change the checked version to 52 (JAVA_8) or 53 (JAVA_9). Please see the updated webrev (webrev.06) in my reply to Vladimir K. Thank you! Best regards, Zoltan > > David > ----- > >> Before JVMS-7, where putfield/putstatic linkage checks were tightened, >> it was allowed to change final fields from anywhere in the same class. >> >> putfield "Linking Exceptions": >> >> JVMS-6 [1]: >> "Otherwise, if the field is final, it must be declared in the >> current class. Otherwise, an IllegalAccessError is thrown." >> >> JVMS-7 [2]: >> "Otherwise, if the field is final, it must be declared in the >> current class, and the instruction must occur in an instance >> initialization method () of the current class. Otherwise, an >> IllegalAccessError is thrown." >> >> >> src/share/vm/interpreter/linkResolver.cpp: >> >> + (byte == Bytecodes::_putstatic && fd.is_static() && >> method_name != vmSymbols::class_initializer_name()) || >> + ((byte == Bytecodes::_putfield || byte == >> Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != >> vmSymbols::object_initializer_name()) >> >> >> Also, as we found earlier, checking method name is not enough: >> >> bool Method::is_static_initializer() const { >> // For classfiles version 51 or greater, ensure that the clinit >> method is >> // static. Non-static methods with the name "" are not static >> // initializers. (older classfiles exempted for backward >> compatibility) >> return name() == vmSymbols::class_initializer_name() && >> has_valid_initializer_flags(); >> } >> >> >> - LinkInfo link_info(defc, name, type, KlassHandle(), >> /*check_access=*/false); >> + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, >> /*check_access=*/false); >> >> Use Handle() instead of NULL. >> >> Also, I'd prefer to see LinkInfo::_current_method and new constructor >> added: >> >> LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* signature, >> Handle current_method, bool check_access = true) : >> >> _current_klass can be derived from _current_method, since: >> >> // current_klass = sending method holder (i.e., class containing the >> method >> // containing the call being resolved) >> >>> I did the following testing: >>> - JPRT >>> - pre-PIT RBT run (in progress) >>> - the reproducer. >>> >>> The reproducer now behaves as expected (an IllegalAccessError is >>> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >>> >>> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >>> >>> The reason for the failure is that the the test generates a method that >>> contains a putstatic to a static final field (i.e., the bytecodes >>> generated by the test do not conform to the JVMS). (Even the test >>> mentions that the Java source equivalent to the generated bytecodes is >>> compilable only if the "final" keyword is removed from the declaration >>> of the static field.) >>> >>> So (if we decide to push the current fix) the issue with the test needs >>> to be fixed first. Do you know how we could proceed with that? >> File a bug against JCK. >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >> >> >> [2] >> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >> >> >> >> [3] >> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 >> >> >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>> >>>>> I agree with you, alternatively we can propose a more generic fix >>>>> (fix >>>>> the interpreter and the compilers as well). The fix would most likely >>>>> affect field resolution in LinkResolver::resolve_field() around here: >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>> inappropriate field access will propagate the exception to the >>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>> (some) >>>>> compilations (if, e.g., fields are linked through >>>>> ciField::will_link()). >>>>> >>>>> I'd prefer to take the second option (changing field resolution), but >>>>> there might be some disadvantages related to option I might be >>>>> overseeing. >>>> >>>> >>>> >>>> >>>>> >>>>> Thank you! >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>> >>>>>> >>>>>>> More details about the failure are here [3]. >>>>>>> >>>>>>> With the patch applied, the program always completes as it is >>>>>>> expected >>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>> (because we >>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>> >>>>>>> Here is the updated webrev: >>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>>> should generate an uncommon trap for such accesses instead (see >>>>>> Parse::do_field_access). >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>> From zoltan.majo at oracle.com Wed Jun 8 17:53:42 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 19:53:42 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <2074215461.1970597.1464886502016.JavaMail.zimbra@u-pem.fr> References: <573C2DAD.1030903@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <2074215461.1970597.1464886502016.JavaMail.zimbra@u-pem.fr> Message-ID: <57585BA6.8000002@oracle.com> Hi R?mi, On 06/02/2016 06:55 PM, forax at univ-mlv.fr wrote: > [...] > I fully understand your concerns. And thank you for sharing your asserts! > > Let's see what others think about how to go about this problem. So far > the following options were explored > - bail out compilation of non-compliant methods; > - enforce JVMS conformance for all classes and keep constant folding > enabled; > - enforce JVMS conformance only for classes with _major_version >=52 and > completely disable constant folding. > > I'm not sure which option is the best. Also, there might be other > options as well. > what about bailing out compilation of non-compliant methods if major <= 52 or if a backward compat flag is set and enforcing the JVMS spec for major >= 53 ? In the latest webrev (webrev.06) compilation is not bailed out for non-compliant methods, only constant folding is disabled. The JVMS is enforced for version >= 51 (the exact version is subject to discussion). Please see the latest webrev (webrev.06) in my reply to Vladimir K. Thank you and best regards, Zolt?n >> Thank you and best regards, >> >> >> Zoltan > R?mi > >>>> We could relax that criteria, e.g., by disabling folding only for those >>>> field that were declared in a class with _major_version < 52. But it >>>> would be great if you could give me some feedback before I look into >>>> that. Thank you very much in advance! >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>> >>>> Testing: JPRT in progress. >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>> R?mi >>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>>> I agree with you, alternatively we can propose a more generic fix (fix >>>>>>> the interpreter and the compilers as well). The fix would most likely >>>>>>> affect field resolution in LinkResolver::resolve_field() around here: >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>> inappropriate field access will propagate the exception to the >>>>>>> interpreter. Changing ciField::will_link() will most likely kill (some) >>>>>>> compilations (if, e.g., fields are linked through >>>>>>> ciField::will_link()). >>>>>>> >>>>>>> I'd prefer to take the second option (changing field resolution), but >>>>>>> there might be some disadvantages related to option I might be >>>>>>> overseeing. >>>>>>> Thank you! >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>> >>>>>>>>> More details about the failure are here [3]. >>>>>>>>> >>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>> expected >>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed (because we >>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>> >>>>>>>>> Here is the updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>> Parse::do_field_access). >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> [1] >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>> >>>>>>>> From zoltan.majo at oracle.com Wed Jun 8 17:55:06 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 19:55:06 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> Message-ID: <57585BFA.4040806@oracle.com> Hi Tom, thank you for your input and suggestions! Please see comments inline. On 06/02/2016 07:51 PM, Tom Rodriguez wrote: >>>> Therefore, in the current webrev, I've disabled folding of accesses to >>>> all non-stable fields. >>> Please do not do that, it will be a huge regression in term of perf >>> at least for the language runtimes i maintain >>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf >>> assertions i use routinely, >>> static final method handle is considered as constant, final fields >>> (even not static) of VM anonymous class is considered as truly final. >>> >> >> I fully understand your concerns. And thank you for sharing your asserts! > > The folding within the compiler should be handled differently since > the concerns are different and removing it will likely cause > invokeynamic performance to collapse. The compiler is only folding > final instance fields that are part of a chain of constants, so the > main concern is whether an object has been published before it?s been > fully constructed or if someone is going to use reflection to modify a > final field after the object has been published. > The trust_final_non_static_fields logic in ciField.cpp is calling out > classes which we control that shouldn?t violate those rules and that > are important for performance. So I think it should be left as is. > It really doesn?t relate to the issue at hand I think. Thank you for clarifying -- I agree and won't touch the folding of final instance fields. > > Also you?ve removed folding of static final fields which would be a > very bad thing to do. Yes, you're right. But I was curious of how much degradation does the removal of folding (most) static final fields cause. So, *as a side experiment*, I have changed the logic controlling folding of static final fields [1] from _is_constant = true; to _is_constant = is_stable_field || trust_final_non_static_fields(_holder); (that is similar to what we do for instance final fields). SPECjvm2008 is unaffected. For the Octane benchmarks we get <10% degradation in 66/70 different configurations, <20% degradation in the remaining cases. The experiment was done on the side and related changes are not included in the newest webrev (webrev.06). > > ciField has some caching logic for _known_to_link_with_get/set and if > you are adding a ciMethod* argument you also need to cache the method > that was checked last time as well. Thanks for pointing that out! I've addressed the caching of methods in the webrev.06 (URL in my reply to Vladimir K.) Best regards, Zoltan [1]: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/84ff58dfd5e0/src/share/vm/ci/ciField.cpp#l256 > > tom > >> >> Let's see what others think about how to go about this problem. So >> far the following options were explored >> - bail out compilation of non-compliant methods; >> - enforce JVMS conformance for all classes and keep constant folding >> enabled; >> - enforce JVMS conformance only for classes with _major_version >=52 >> and completely disable constant folding. >> >> I'm not sure which option is the best. Also, there might be other >> options as well. >> >> Thank you and best regards, >> >> >> Zoltan >> >> >> >>>> We could relax that criteria, e.g., by disabling folding only for those >>>> field that were declared in a class with _major_version < 52. But it >>>> would be great if you could give me some feedback before I look into >>>> that. Thank you very much in advance! >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>> >>>> >>>> Testing: JPRT in progress. >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>> R?mi >>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>>> I agree with you, alternatively we can propose a more generic >>>>>>> fix (fix >>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>> likely >>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>> here: >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>> inappropriate field access will propagate the exception to the >>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>> (some) >>>>>>> compilations (if, e.g., fields are linked through >>>>>>> ciField::will_link()). >>>>>>> >>>>>>> I'd prefer to take the second option (changing field >>>>>>> resolution), but >>>>>>> there might be some disadvantages related to option I might be >>>>>>> overseeing. >>>>>> >>>>>> >>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>> >>>>>>>>> More details about the failure are here [3]. >>>>>>>>> >>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>> expected >>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>> (because we >>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>> >>>>>>>>> Here is the updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>> >>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>> appropriate. It >>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>> Parse::do_field_access). >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> [1] >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 > From zoltan.majo at oracle.com Wed Jun 8 18:00:10 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 20:00:10 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57510383.4090506@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> Message-ID: <57585D2A.3010906@oracle.com> Hi Vladimir, thank you for the feedback! On 06/03/2016 06:11 AM, Vladimir Kozlov wrote: > How about only fixing C1 to take into account the store (or not > constant fold in such case) because it was allowed before JVMS-7? before JVMS-7, any method of a class 'C' (not just the class initializer) is allowed to modify a *static* final field 'C::f' of that class. The same is true for *instance* final fields (any method, not only constructors, is allowed to modify them). So, to avoid problems similar to the current one, we would have to disable constant folding completely if JVMS-7 is not enforced by the VM. That is not a walkable path due to performance reasons. Fortunately, there are *very few* classes that "misbehave" the above way. (So far I've seen *only two* such classes, Jython and a single JCK test, although I've run all pre-PIT testing with -Xcomp and -Xmixed.) So, a solution would be to detect misbehaving fields and disable constant folding only for those fields. And that is what the latest webrev (webrev.06) does. To summarize, webrev.06 - *detects misbehaving fields in the verifier* for classes with version < JAVA_7_VERSION and *disables constant folding for those fields only*; - *enforces JVMS-7 conformance* for classes with version >= JAVA_7_VERSION and *leaves constant folding as it is* (no performance impact). As I mentioned to David Holmes, we can use JAVA_8_VERSION or JAVA_9_VERSION instead of JAVA_7_VERSION. I'm currently running pre-PIT RBT to see if there are any problems with our testbase. Performance runs are also in progress. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.06/ Testing: - JPRT; - local testing with reproducer (verified that interpreter/compiled code behave the same way); - pre-PIT RBT in progress. > > And file a separate issue for JVMS-7 conformance. It looks like it may > have huge impact on performance and we are already very late in JDK 9 > development to make such changes in rush. I agree that the two issues can be treated as unrelated. But, for now, I'd like to keep them together as by fixing them together we cover both the > JAVA_7_VERSION and the <= JAVA_7_VERSION case at the same time. The performance runs (in progress) show that the fix has no performance impact (because we disable constant folding in very rare cases). I'll report all numbers once they become available. > > Zoltan, what C2 does in such case? I can reproduce the problem only with -Xcomp. With -Xcomp, there is not enough profiling information available for C2 to compile the problematic bytecode. Thus, C2 deoptimizes before execution proceeds to that bytecode. But C2 folds final fields as well, therefore C2-compiled methods can also be negatively impacted if final fields chang after they have been initialized. Fortunately, with the current fix we have to disable folding only in very rare cases. Thank you! Best regards, Zoltan > Tom, what Graal does in such case? > > The case is: > > https://bugs.openjdk.java.net/browse/JDK-8157181?focusedCommentId=13942824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13942824 > > > "While compiling bytecode @29, the C1 compiler assumes that the value > of the _pyx0.self field has already been set in the class initializer > method (as the class is initialized). The C1 compiler also > assumes that the field will not change (as it is static final). > Therefore, the C1 compiler omits reading the field _pyx0.self and > passes the current value of the field ('null') to the > org/python/core/Py.newCode() method called at bytecode @37. (The > correct value would be 'this'.)" > > Thanks, > Vladimir > > On 6/2/16 10:51 AM, Tom Rodriguez wrote: >>>>> Therefore, in the current webrev, I've disabled folding of >>>>> accesses to >>>>> all non-stable fields. >>>> Please do not do that, it will be a huge regression in term of perf >>>> at least for the language runtimes i maintain >>>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf >>>> assertions i use routinely, >>>> static final method handle is considered as constant, final fields >>>> (even not static) of VM anonymous class is considered as truly final. >>>> >>> >>> I fully understand your concerns. And thank you for sharing your >>> asserts! >> >> The folding within the compiler should be handled differently since >> the concerns are different and removing it will likely cause >> invokeynamic performance to collapse. The compiler is only folding >> final instance fields that are part of a chain of constants, so the >> main concern is whether an object has been published before it?s been >> fully constructed or if someone is going to use reflection to >> modify a final field after the object has been published. The >> trust_final_non_static_fields logic in ciField.cpp is calling out >> classes which we control that shouldn?t violate those rules and that >> are important for performance. So I think it should be left as is. >> It really doesn?t relate to the issue at hand I think. >> >> Also you?ve removed folding of static final fields which would be a >> very bad thing to do. >> >> ciField has some caching logic for _known_to_link_with_get/set and if >> you are adding a ciMethod* argument you also need to cache the method >> that was checked last time as well. >> >> tom >> >>> >>> Let's see what others think about how to go about this problem. So >>> far the following options were explored >>> - bail out compilation of non-compliant methods; >>> - enforce JVMS conformance for all classes and keep constant folding >>> enabled; >>> - enforce JVMS conformance only for classes with _major_version >=52 >>> and completely disable constant folding. >>> >>> I'm not sure which option is the best. Also, there might be other >>> options as well. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>> >>> >>>>> We could relax that criteria, e.g., by disabling folding only for >>>>> those >>>>> field that were declared in a class with _major_version < 52. But it >>>>> would be great if you could give me some feedback before I look into >>>>> that. Thank you very much in advance! >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>>> >>>>> Testing: JPRT in progress. >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>> R?mi >>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>>> I agree with you, alternatively we can propose a more generic >>>>>>>> fix (fix >>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>> likely >>>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>>> here: >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>> interpreter. Changing ciField::will_link() will most likely >>>>>>>> kill (some) >>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>> ciField::will_link()). >>>>>>>> >>>>>>>> I'd prefer to take the second option (changing field >>>>>>>> resolution), but >>>>>>>> there might be some disadvantages related to option I might be >>>>>>>> overseeing. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thank you! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> >>>>>>>> Zoltan >>>>>>>> >>>>>>>> >>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>> >>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>> expected >>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>> (because we >>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>> >>>>>>>>>> Here is the updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>> appropriate. It >>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>> Parse::do_field_access). >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>> >> From zoltan.majo at oracle.com Wed Jun 8 18:01:12 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Jun 2016 20:01:12 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> Message-ID: <57585D68.7030108@oracle.com> Hi Vladimir, thank you for the feedback (both on the mailing list and in private)! On 06/03/2016 12:48 PM, Vladimir Ivanov wrote: > > > On 6/3/16 7:11 AM, Vladimir Kozlov wrote: >> How about only fixing C1 to take into account the store (or not constant >> fold in such case) because it was allowed before JVMS-7? >> >> And file a separate issue for JVMS-7 conformance. It looks like it may >> have huge impact on performance and we are already very late in JDK 9 >> development to make such changes in rush. > > Yes, let's separate them (considering the difference in impact) and > align the JVM behavior with the JVMS separately. As I mentioned to Vladimir K, I would like to keep the two issues together (at least for now). That way we have a fix that covers both cases > JAVA_7_VERSION and <= JAVA_7_VERSION at once. > > For now, disabling constant folding of static/instance field loads in > static/instance initializers should solve the immediate problem for > well-behaved (according to JVMS) programs. Also, such change should > not cause any performance regressions. > > Considering it is possible to update static final fields through > Reflection API, I don't see JVMS conformance issue (ability to update > final static fields outside of static initializer on bytecode level) > as a problem of the same level for JIT-compilers. It can be fixed as > part of aligning the JVM with JVMS (but still in JDK9). I hope I've addressed your comments in my replies to other people. Can you please let me know, if not? Thank you! Best regards, Zoltan > > Best regards, > Vladimir Ivanov > >> >> Zoltan, what C2 does in such case? >> Tom, what Graal does in such case? >> >> The case is: >> >> https://bugs.openjdk.java.net/browse/JDK-8157181?focusedCommentId=13942824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13942824 >> >> >> >> "While compiling bytecode @29, the C1 compiler assumes that the value of >> the _pyx0.self field has already been set in the class initializer >> method (as the class is initialized). The C1 compiler also >> assumes that the field will not change (as it is static final). >> Therefore, the C1 compiler omits reading the field _pyx0.self and passes >> the current value of the field ('null') to the >> org/python/core/Py.newCode() method called at bytecode @37. (The correct >> value would be 'this'.)" >> >> Thanks, >> Vladimir >> >> On 6/2/16 10:51 AM, Tom Rodriguez wrote: >>>>>> Therefore, in the current webrev, I've disabled folding of >>>>>> accesses to >>>>>> all non-stable fields. >>>>> Please do not do that, it will be a huge regression in term of perf >>>>> at least for the language runtimes i maintain >>>>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf >>>>> assertions i use routinely, >>>>> static final method handle is considered as constant, final fields >>>>> (even not static) of VM anonymous class is considered as truly final. >>>>> >>>> >>>> I fully understand your concerns. And thank you for sharing your >>>> asserts! >>> >>> The folding within the compiler should be handled differently since >>> the concerns are different and removing it will likely cause >>> invokeynamic performance to collapse. The compiler is only folding >>> final instance fields that are part of a chain of constants, so the >>> main concern is whether an object has been published before it?s been >>> fully constructed or if someone is going to use reflection to >>> modify a final field after the object has been published. The >>> trust_final_non_static_fields logic in ciField.cpp is calling out >>> classes which we control that shouldn?t violate those rules and that >>> are important for performance. So I think it should be left as is. >>> It really doesn?t relate to the issue at hand I think. >>> >>> Also you?ve removed folding of static final fields which would be a >>> very bad thing to do. >>> >>> ciField has some caching logic for _known_to_link_with_get/set and if >>> you are adding a ciMethod* argument you also need to cache the method >>> that was checked last time as well. >>> >>> tom >>> >>>> >>>> Let's see what others think about how to go about this problem. So >>>> far the following options were explored >>>> - bail out compilation of non-compliant methods; >>>> - enforce JVMS conformance for all classes and keep constant folding >>>> enabled; >>>> - enforce JVMS conformance only for classes with _major_version >=52 >>>> and completely disable constant folding. >>>> >>>> I'm not sure which option is the best. Also, there might be other >>>> options as well. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>> >>>>>> We could relax that criteria, e.g., by disabling folding only for >>>>>> those >>>>>> field that were declared in a class with _major_version < 52. But it >>>>>> would be great if you could give me some feedback before I look into >>>>>> that. Thank you very much in advance! >>>>>> >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>>>> >>>>>> Testing: JPRT in progress. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>> R?mi >>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>>> I agree with you, alternatively we can propose a more generic >>>>>>>>> fix (fix >>>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>>> likely >>>>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>>>> here: >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>>>> (some) >>>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>>> ciField::will_link()). >>>>>>>>> >>>>>>>>> I'd prefer to take the second option (changing field >>>>>>>>> resolution), but >>>>>>>>> there might be some disadvantages related to option I might be >>>>>>>>> overseeing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Zoltan >>>>>>>>> >>>>>>>>> >>>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>>> >>>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>>> expected >>>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>>> (because we >>>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>>> >>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>>> appropriate. It >>>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>>> Parse::do_field_access). >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>>> >>>>>>>>>> >>> From david.holmes at oracle.com Thu Jun 9 00:43:18 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Jun 2016 10:43:18 +1000 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <57569540.9010106@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> Message-ID: <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> Hi Leonid, Sorry for the delay. On 7/06/2016 7:34 PM, Leonid Mesnik wrote: > Hi > > Added jtreg-use at openjdk.java.net > > I think that you are right. Here is the documentation: > http://openjdk.java.net/jtreg/tag-spec.html > > > "@requires > > Express a dependence on characteristics of the system being tested. > Some harnesses allow tests to be selected according to the > characteristics of the system being tested. The expression may be > composed of the following elements:" > > "os.arch The operating system architecture, as given by the > corresponding system property." > > So user could expect to have "os.arch" of tested VM. > > If filed jtreg issues for this: > > 1. CODETOOLS-7901695 > jtreg uses > value 'os.arch' property of JDK which executed JDK and not of tested JDK > > > Following fix could be used as a temporary workaround while jtreg fix is > not ready. Does it make a sense? I this case it is needed to change > linux-arm64 back to linux-aarch64 to minimize changes. I still think we have a fundamental problem concerning what os.arch means. This workaround seems to work but I find it all very confusing. We really need a vm.arch property, distinct from os.arch. David ----- > Leonid > > On 31.05.2016 04:26, David Holmes wrote: >> Hi Leonid, >> >> This really strikes me as as a jtreg problem that should be fixed in >> jtreg. When writing an @requires clause in a test the test writer >> should not have to be thinking "oh wait! Is this going to query the VM >> running jtreg or the VM running the test?". It should obviously be the >> VM running the test. >> >> That said we also seem to have a problem with the definition of os.arch: >> >> os.arch Operating system architecture >> >> if it is returning the build architecture of the VM and not the OS it >> is running on. That in itself argues for two distinct properties. >> >> David >> >> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>> Hi >>> >>> Could you please review following fix: >>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>> >>> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>> >>> for bug >>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>> >>> >>> The property "os.name" which was used to filter tests depends on the >>> arch of jdk which is used to run jtreg. It might differ from arch of >>> tested jdk. >>> This fix introduce new property "vm.arch" which depends on the arch of >>> tested jdk and could be used to filter tests with @requires. >>> >>> I verified that tests are filtered where it is expected. >>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>> testing. >>> >>> Leonid >>> > From vladimir.x.ivanov at oracle.com Thu Jun 9 11:28:23 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 9 Jun 2016 14:28:23 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57585D2A.3010906@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> Message-ID: Zoltan, > To summarize, webrev.06 > - *detects misbehaving fields in the verifier* for classes with version > < JAVA_7_VERSION and *disables constant folding for those fields only*; > - *enforces JVMS-7 conformance* for classes with version >= > JAVA_7_VERSION and *leaves constant folding as it is* (no performance > impact). > > As I mentioned to David Holmes, we can use JAVA_8_VERSION or > JAVA_9_VERSION instead of JAVA_7_VERSION. Agree. > I'm currently running pre-PIT RBT to see if there are any problems with > our testbase. Performance runs are also in progress. > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.06/ I really like how it shapes out! Some comments follow: Unfortunately, it doesn't (and, moreover, can't) cover class redefinition: if a new version of a method contains final field update, all the generated code which embed previous value should be invalidated. The only way to handle such case now is to add nmethod dependencies when static final field loads are constant folded. Please, file a separate bug (P4) for that and let's decide how to proceed with it later. --- src/share/vm/classfile/verifier.cpp: + void Verifier::detect_invalid_final_field_accesses(instanceKlassHandle klass) { The name is misleading: such accesses are legal according to JVMS-6 (and earlier). Maybe something like detect_initialized_final_field_updates? Same for: + bool has_invalid_final_access() const { return access_flags().has_field_invalid_final_access(); } + void set_has_invalid_final_access(const bool value) { + JVM_ACC_FIELD_INVALID_FINAL_ACCESS = 0x00000100, --- Why do you care about _nofast_putfield? The bytecode hasn't been rewritten yet. + if (klass()->major_version() < 51 && !klass->is_rewritten()) { ... + if (opcode == Bytecodes::_putstatic || opcode == Bytecodes::_putfield || opcode == Bytecodes::_nofast_putfield) { --- Also, I don't think in its current shape it is part of verification, but instanceKlass linkage phase instead: bool InstanceKlass::link_class_impl( instanceKlassHandle this_k, bool throw_verifyerror, TRAPS) { ... if (!this_k->is_linked()) { if (!this_k->is_rewritten()) { { bool verify_ok = verify_code(this_k, throw_verifyerror, THREAD); if (!verify_ok) { return false; } } ... << HERE >> ... // also sets rewritten this_k->rewrite_class(CHECK_false); --- I don't see much benefit in tracking the problematic updates per-methods and not per-class. So, you could do the checks in ClassVerifier::verify_field_instructions [1] and mark the whole class (ClassVerifier::_klass) as containing problematic instructions. --- src/share/vm/interpreter/linkResolver.cpp: THROW(vmSymbols::java_lang_IllegalAccessError()); + THROW(vmSymbols::java_lang_IllegalAccessError()); Please, add an error message for diagnostic purposes. --- src/share/vm/ci/ciField.cpp: - if (_known_to_link_with_put == accessing_klass) { + if (_known_to_link_with_put_klass == accessing_klass && _known_to_link_with_put_method) { Don't you need to check _known_to_link_with_put_method with accessing_method? Why don't you use accessing_method instead of accessing_klass and migrate _known_to_link_with_put/get to ciMethod*? bool will_link(ciMethod* accessing_method, Bytecodes::Code bc); I looked at all will_link usages and accessing_method is always available. Otherwise, looks good! Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/84ff58dfd5e0/src/share/vm/classfile/verifier.cpp#l2226 From jlent at tivo.com Tue Jun 7 20:58:25 2016 From: jlent at tivo.com (James Lent) Date: Tue, 7 Jun 2016 16:58:25 -0400 Subject: Java 8 Performance Issue With Tiered Compilation Disabled In-Reply-To: <575571F6.2040101@tivo.com> References: <57505730.402@tivo.com> <57552DA1.6040205@oracle.com> <575571F6.2040101@tivo.com> Message-ID: <57573571.3030103@tivo.com> Tried to run my app using Java 9: java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+119) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+119, mixed mode) and it would not start: Caused by: java.lang.IllegalAccessError: class org.apache.hadoop.security.KerberosName (in unnamed module @0x2480acc3) cannot access class sun.security.krb5.KrbException (in module java.security.jgss) because module java.security.jgss does not export sun.security.krb5 to unnamed module @0x2480acc3 This may be just the tip of the iceberg. Tried building against Java 9 and had other issues (tools.jar, etc.). My guess is I will not be able to test using Java 9 any time soon. Sorry, Jim On 06/06/2016 08:52 AM, James Lent wrote: Thanks for your interest. Answer in-line. On 06/06/2016 04:00 AM, Tobias Hartmann wrote: Hi James, thanks for the report, please find some questions below. On 02.06.2016 17:56, James Lent wrote: We are running a Solr/Lucene based server on Java 8: openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-b14) OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) Recently we tried to run with Tiered Compilation disabled: -XX:-TieredCompilation In production the system performed very well for about 70 hours and then performance start to degrade very sharply. HotSpot logs indicated that 100s of methods had reached their recompile limit. A sample of the logs is below: made not compilable on levels 0 1 2 3 4 java.lang.String::equals (81 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.lucene.util.OpenBitSetIterator::nextDoc (136 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.solr.search.SolrConstantScoreQuery$ConstantScorer::score (5 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.roaringbitmap.Util::fillArrayAND (92 bytes) decompile_count > PerMethodRecompilationCutoff The methods that hit this limit include Java, Lucene, Solr, and RoaringBitMap methods. I was able to reproduce this in a dev environment by just running very light real world traffic. What I observed was that many methods were being recompiled 3 or more times per hour. I was able to "fix" this issue by one of two methods: 1) Increase max code cache size: -XX:ReservedCodeCacheSize=240m 2) Disable code cache flushing: -XX:-UseCodeCacheFlushing After running for over 12 hours the maximum number of decompiles for a method is 14 and that method hit 11 decompiles very quickly and then leveled off (with the first fix it is still at 11). Only 7 methods have 8 or more decompiles and this has held steady for hours now). I also tried the following based on a suggestion from Chris Newland, but, it did not help: -XX:-UseBimorphicInlining My theory is that the Code Cache flushing algorithm coupled with the Code Cache demands of my application are causing the HotSpot compiler to "thrash". Keep cycling the methods through the Code Cache: 1) Compile method A 2) Compile method B 3) Kick out method A and compile method C 4) Kick out method B and compile method A Observations: 1) When Tiered Compilation is disabled the Code Cache max drops from 240mb to 48mb. Did the problem also show up with Tiered Compilation? This problem did not. Of course with tiered compilation enabled the code cache max seems to default to 240mb. I did not try running tiered with a smaller max code cache size. I did not that tiered seems to use a lot more code cache. The same application exceeds 70mb when it is enabled. However with tiered compilations enabled we were seeing a hard to understand drop in performance after about 4.5 hours in both production (2 second response times suddenly jump to 3 to 5 seconds). I was able to reproduce this issue in a dev environment with surprisingly little trouble. I investigated this issue from many angles to try to understand what was going on (heap, linux file cache, background network traffic, processor load, EC2 variability). The one thing that did seem to work in dev was turning off Tiered compilation (a desperation idea). I have not been able to identify any interesting compiler logs that correlate with that issue. When we tried it in production it worked very well for 70 hours and then this issue occurred which was actually much worse. I was not a hero. I sent an email on this first issue to the hotspot-dev mailing list (before the "turn off tiered compilation fix" failed in production), but, was not expecting much help because I could not provide much data to work with. Just a description of the symptoms. 2) When not constrained (i.e. when one of my two "fixes" is applied) my application under this traffic load levels out at just below 22mb in the Code Cache. 3) When neither of my fixes is applied then the Code Cache usage peaks about 18mb, but, is highly variable minute to minute. You could try to use a lower value of -XX:NmethodSweepActivity to avoid aggressive sweeping when the code cache is getting full. But I doubt that this helps because there is still enough space in the code cache. I will try to give it a try as time permits, but, I have torn down my dev environment for now. I was able to reproduce this issue right on my dev box, but doing so consumes most of its resources. I may try to set it up before I leave tonight. We are planning to implement fix one above in production soon. Any comments? I think increasing the code cache size does not hurt and prevents aggressive sweeping in this case because a larger code cache size leads to a larger per method hotness threshold for flushing. Did you try to reproduce the problem with a JDK 9 early access build? The symptoms you are describing sound quite similar to an issue we encountered with JDK 9. This was fixed by code aging [1] but the fix was never backported to JDK 8. You can enable/disable code aging with -XX:UseCodeAging in 9. If the problem turns out to be fixed, we could provide a prototype backport of code aging for testing in your environment. Thanks for the info. I have not tried with Java 9. I will put that on the list to try. Best regards, Tobias [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/975d903e1de3 I can provide HotSpot logs. Chris has provided me the required options to get the more detailed information. ________________________________ This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement. James Lent Senior Software Engineer Digitalsmiths A TiVo Company www.digitalsmiths.com jlent at digitalsmiths.com | office 919.460.4747 James Lent Senior Software Engineer Digitalsmiths A TiVo Company www.digitalsmiths.com jlent at digitalsmiths.com | office 919.460.4747 ________________________________ This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Thu Jun 9 14:00:19 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 9 Jun 2016 16:00:19 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> Message-ID: <57597673.4070103@oracle.com> Hi Vladimir, thank you for the feedback! Please see comments inline. On 06/09/2016 01:28 PM, Vladimir Ivanov wrote: > Zoltan, > >> To summarize, webrev.06 >> - *detects misbehaving fields in the verifier* for classes with version >> < JAVA_7_VERSION and *disables constant folding for those fields only*; >> - *enforces JVMS-7 conformance* for classes with version >= >> JAVA_7_VERSION and *leaves constant folding as it is* (no performance >> impact). >> >> As I mentioned to David Holmes, we can use JAVA_8_VERSION or >> JAVA_9_VERSION instead of JAVA_7_VERSION. > > Agree. OK. > >> I'm currently running pre-PIT RBT to see if there are any problems with >> our testbase. Performance runs are also in progress. >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.06/ > > I really like how it shapes out! Thank you, I'm glad to hear that! > > Some comments follow: > > Unfortunately, it doesn't (and, moreover, can't) cover class > redefinition: if a new version of a method contains final field > update, all the generated code which embed previous value should be > invalidated. > > The only way to handle such case now is to add nmethod dependencies > when static final field loads are constant folded. > > Please, file a separate bug (P4) for that and let's decide how to > proceed with it later. OK, I've filed JDK-8159150 [1]. > > --- > src/share/vm/classfile/verifier.cpp: > > + void > Verifier::detect_invalid_final_field_accesses(instanceKlassHandle > klass) { > > The name is misleading: such accesses are legal according to JVMS-6 > (and earlier). Maybe something like > detect_initialized_final_field_updates? > > Same for: > + bool has_invalid_final_access() const { return > access_flags().has_field_invalid_final_access(); } > + void set_has_invalid_final_access(const bool value) { > + JVM_ACC_FIELD_INVALID_FINAL_ACCESS = 0x00000100, > Yes, that name sounds better and I've updated the code accordingly. > > --- > Why do you care about _nofast_putfield? The bytecode hasn't been > rewritten yet. > > + if (klass()->major_version() < 51 && !klass->is_rewritten()) { > ... > + if (opcode == Bytecodes::_putstatic || opcode == > Bytecodes::_putfield || opcode == Bytecodes::_nofast_putfield) { That is a mistake, I've removed the condition related to _nofast_putfield. > > --- > Also, I don't think in its current shape it is part of verification, > but instanceKlass linkage phase instead: > > bool InstanceKlass::link_class_impl( > instanceKlassHandle this_k, bool throw_verifyerror, TRAPS) { > ... > if (!this_k->is_linked()) { > if (!this_k->is_rewritten()) { > { > bool verify_ok = verify_code(this_k, throw_verifyerror, > THREAD); > if (!verify_ok) { > return false; > } > } > ... > << HERE >> > ... > // also sets rewritten > this_k->rewrite_class(CHECK_false); I agree and have updated the code. > > --- > I don't see much benefit in tracking the problematic updates > per-methods and not per-class. So, you could do the checks in > ClassVerifier::verify_field_instructions [1] and mark the whole class > (ClassVerifier::_klass) as containing problematic instructions. The problematic updates are tracked *per-field* (and not *per-method* or * per-class*). Initially, I had a version that tracked problematic instructions on a per-class basis. With that version, once a problematic instruction was detected, the whole class was marked as containing problematic instructions. As a result, constant folding was disabled for accesses to *all* final fields of that class. Tracking problematic updates on a per-field basis seems to be less intrusive. That way we disable folding *only for fields to which problematic accesses are made* (and leave constant folding enabled for accesses to all other fields). So we can fold some accesses even for "misbehaving" classes. I hope that is fine. Regarding doing checks in verify_field_instructions() [2]: It turns out that we have two verifiers, one that is called for major_version >= STACKMAP_ATTRIBUTE_MAJOR_VERSION and a second one that is called for major_version < STACKMAP_ATTRIBUTE_MAJOR_VERSION. ClassVerifier::verify_field_instructions() is called only for class files >= STACKMAP_ATTRIBUTE_MAJOR_VERSION so we need to call detect_initialized_final_field_updates() after verification. But I think it is a good idea to move the check to the linkage phase (as you've suggested above). > > --- > src/share/vm/interpreter/linkResolver.cpp: > > THROW(vmSymbols::java_lang_IllegalAccessError()); > > + THROW(vmSymbols::java_lang_IllegalAccessError()); > > Please, add an error message for diagnostic purposes. OK, I did that. > > --- > src/share/vm/ci/ciField.cpp: > > - if (_known_to_link_with_put == accessing_klass) { > + if (_known_to_link_with_put_klass == accessing_klass && > _known_to_link_with_put_method) { > > Don't you need to check _known_to_link_with_put_method with > accessing_method? Sure I do. Thank you for catching that mistake. > > Why don't you use accessing_method instead of accessing_klass and > migrate _known_to_link_with_put/get to ciMethod*? > > bool will_link(ciMethod* accessing_method, Bytecodes::Code bc); > > I looked at all will_link usages and accessing_method is always > available. That is a good idea. I've removed the parameter accessing_klass and use only accessing_method. For put bytecodes, the VM caches the accessing method. For get bytecodes, it is sufficient to cache the accessing klass; we derive the accessing klass from the accessing _method. Please let me know if you think we should proceed differently. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.07/ JPRT is in progress. > > > Otherwise, looks good! Thanks a lot! Best regards, Zoltan [1] https://bugs.openjdk.java.net/browse/JDK-8159150 [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/84ff58dfd5e0/src/share/vm/classfile/verifier.cpp#l173 > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/84ff58dfd5e0/src/share/vm/classfile/verifier.cpp#l2226 From zoltan.majo at oracle.com Thu Jun 9 14:03:20 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 9 Jun 2016 16:03:20 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57585D2A.3010906@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> Message-ID: <57597728.1030604@oracle.com> Hi, On 06/08/2016 08:00 PM, Zolt?n Maj? wrote: > [...] > I'm currently running pre-PIT RBT to see if there are any problems > with our testbase. Performance runs are also in progress. Just to report on the performance/correctness results: The change does not cause any performance regression; pre-PIT RBT completed successfully. Thank you! Best regards, Zoltan > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.06/ > > Testing: > - JPRT; > - local testing with reproducer (verified that interpreter/compiled > code behave the same way); > - pre-PIT RBT in progress. > > >> >> And file a separate issue for JVMS-7 conformance. It looks like it >> may have huge impact on performance and we are already very late in >> JDK 9 development to make such changes in rush. > > I agree that the two issues can be treated as unrelated. But, for now, > I'd like to keep them together as by fixing them together we cover > both the > JAVA_7_VERSION and the <= JAVA_7_VERSION case at the same > time. > > The performance runs (in progress) show that the fix has no > performance impact (because we disable constant folding in very rare > cases). I'll report all numbers once they become available. > >> >> Zoltan, what C2 does in such case? > > I can reproduce the problem only with -Xcomp. With -Xcomp, there is > not enough profiling information available for C2 to compile the > problematic bytecode. Thus, C2 deoptimizes before execution proceeds > to that bytecode. > > But C2 folds final fields as well, therefore C2-compiled methods can > also be negatively impacted if final fields chang after they have been > initialized. Fortunately, with the current fix we have to disable > folding only in very rare cases. > > Thank you! > > Best regards, > > > Zoltan > >> Tom, what Graal does in such case? >> >> The case is: >> >> https://bugs.openjdk.java.net/browse/JDK-8157181?focusedCommentId=13942824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13942824 >> >> >> "While compiling bytecode @29, the C1 compiler assumes that the value >> of the _pyx0.self field has already been set in the class initializer >> method (as the class is initialized). The C1 compiler also >> assumes that the field will not change (as it is static final). >> Therefore, the C1 compiler omits reading the field _pyx0.self and >> passes the current value of the field ('null') to the >> org/python/core/Py.newCode() method called at bytecode @37. (The >> correct value would be 'this'.)" >> >> Thanks, >> Vladimir >> >> On 6/2/16 10:51 AM, Tom Rodriguez wrote: >>>>>> Therefore, in the current webrev, I've disabled folding of >>>>>> accesses to >>>>>> all non-stable fields. >>>>> Please do not do that, it will be a huge regression in term of >>>>> perf at least for the language runtimes i maintain >>>>> (and i suppose for Nashorn, JRuby or Groovy), Here are the perf >>>>> assertions i use routinely, >>>>> static final method handle is considered as constant, final fields >>>>> (even not static) of VM anonymous class is considered as truly final. >>>>> >>>> >>>> I fully understand your concerns. And thank you for sharing your >>>> asserts! >>> >>> The folding within the compiler should be handled differently since >>> the concerns are different and removing it will likely cause >>> invokeynamic performance to collapse. The compiler is only folding >>> final instance fields that are part of a chain of constants, so the >>> main concern is whether an object has been published before it?s >>> been fully constructed or if someone is going to use reflection to >>> modify a final field after the object has been published. The >>> trust_final_non_static_fields logic in ciField.cpp is calling out >>> classes which we control that shouldn?t violate those rules and that >>> are important for performance. So I think it should be left as is. >>> It really doesn?t relate to the issue at hand I think. >>> >>> Also you?ve removed folding of static final fields which would be a >>> very bad thing to do. >>> >>> ciField has some caching logic for _known_to_link_with_get/set and >>> if you are adding a ciMethod* argument you also need to cache the >>> method that was checked last time as well. >>> >>> tom >>> >>>> >>>> Let's see what others think about how to go about this problem. So >>>> far the following options were explored >>>> - bail out compilation of non-compliant methods; >>>> - enforce JVMS conformance for all classes and keep constant >>>> folding enabled; >>>> - enforce JVMS conformance only for classes with _major_version >>>> >=52 and completely disable constant folding. >>>> >>>> I'm not sure which option is the best. Also, there might be other >>>> options as well. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>> >>>>>> We could relax that criteria, e.g., by disabling folding only for >>>>>> those >>>>>> field that were declared in a class with _major_version < 52. But it >>>>>> would be great if you could give me some feedback before I look into >>>>>> that. Thank you very much in advance! >>>>>> >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.05/ >>>>>> >>>>>> Testing: JPRT in progress. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>> R?mi >>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>>> I agree with you, alternatively we can propose a more generic >>>>>>>>> fix (fix >>>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>>> likely >>>>>>>>> affect field resolution in LinkResolver::resolve_field() >>>>>>>>> around here: >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>>> interpreter. Changing ciField::will_link() will most likely >>>>>>>>> kill (some) >>>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>>> ciField::will_link()). >>>>>>>>> >>>>>>>>> I'd prefer to take the second option (changing field >>>>>>>>> resolution), but >>>>>>>>> there might be some disadvantages related to option I might be >>>>>>>>> overseeing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Zoltan >>>>>>>>> >>>>>>>>> >>>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>>> >>>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>>> expected >>>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>>> (because we >>>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>>> >>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>>> appropriate. It >>>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>>> Parse::do_field_access). >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>>> >>> > From forax at univ-mlv.fr Thu Jun 9 14:05:33 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 9 Jun 2016 16:05:33 +0200 (CEST) Subject: Java 8 Performance Issue With Tiered Compilation Disabled In-Reply-To: <57573571.3030103@tivo.com> References: <57505730.402@tivo.com> <57552DA1.6040205@oracle.com> <575571F6.2040101@tivo.com> <57573571.3030103@tivo.com> Message-ID: <1472716014.1849991.1465481133880.JavaMail.zimbra@u-pem.fr> Hi James, you can run jdk-9/bin/jdeps --jdkinternals on your jars to see every non public APIs you use, you will need to fix that before being able to hope to run jdk9. regrads, R?mi ----- Mail original ----- > De: "James Lent" > ?: "Tobias Hartmann" , > hotspot-compiler-dev at openjdk.java.net > Envoy?: Mardi 7 Juin 2016 22:58:25 > Objet: Re: Java 8 Performance Issue With Tiered Compilation Disabled > Tried to run my app using Java 9: > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+119) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+119, mixed mode) > and it would not start: > Caused by: java.lang.IllegalAccessError: class > org.apache.hadoop.security.KerberosName (in unnamed module @0x2480acc3) > cannot access class sun.security.krb5.KrbException (in module > java.security.jgss) because module java.security.jgss does not export > sun.security.krb5 to unnamed module @0x2480acc3 > This may be just the tip of the iceberg. > Tried building against Java 9 and had other issues (tools.jar, etc.). > My guess is I will not be able to test using Java 9 any time soon. > Sorry, > Jim > On 06/06/2016 08:52 AM, James Lent wrote: > > Thanks for your interest. Answer in-line. > > > On 06/06/2016 04:00 AM, Tobias Hartmann wrote: > > > > Hi James, > > > > > > thanks for the report, please find some questions below. > > > > > > On 02.06.2016 17:56, James Lent wrote: > > > > > > > We are running a Solr/Lucene based server on Java 8: > > > > > > > > > > openjdk version "1.8.0_91" > > > > > > > > > > OpenJDK Runtime Environment (build 1.8.0_91-b14) > > > > > > > > > > OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) > > > > > > > > > > Recently we tried to run with Tiered Compilation disabled: > > > > > > > > > > -XX:-TieredCompilation > > > > > > > > > > In production the system performed very well for about 70 hours and > > > > then > > > > > > > > > > performance start to degrade very sharply. HotSpot logs indicated that > > > > > > > > > > 100s of methods had reached their recompile limit. A sample of the > > > > logs > > > > > > > > > > is below: > > > > > > > > > > made not compilable on levels 0 1 2 3 4 java.lang.String::equals (81 > > > > > > > > > > bytes) decompile_count > PerMethodRecompilationCutoff > > > > > > > > > > made not compilable on levels 0 1 2 3 4 > > > > > > > > > > org.apache.lucene.util.OpenBitSetIterator::nextDoc (136 bytes) > > > > > > > > > > decompile_count > PerMethodRecompilationCutoff > > > > > > > > > > made not compilable on levels 0 1 2 3 4 > > > > > > > > > > org.apache.solr.search.SolrConstantScoreQuery$ConstantScorer::score (5 > > > > > > > > > > bytes) decompile_count > PerMethodRecompilationCutoff > > > > > > > > > > made not compilable on levels 0 1 2 3 4 > > > > > > > > > > org.roaringbitmap.Util::fillArrayAND (92 bytes) decompile_count > > > > > > > > > > > PerMethodRecompilationCutoff > > > > > > > > > > The methods that hit this limit include Java, Lucene, Solr, and > > > > > > > > > > RoaringBitMap methods. > > > > > > > > > > I was able to reproduce this in a dev environment by just running very > > > > > > > > > > light real world traffic. What I observed was that many methods were > > > > > > > > > > being recompiled 3 or more times per hour. > > > > > > > > > > I was able to "fix" this issue by one of two methods: > > > > > > > > > > 1) Increase max code cache size: > > > > > > > > > > -XX:ReservedCodeCacheSize=240m > > > > > > > > > > 2) Disable code cache flushing: > > > > > > > > > > -XX:-UseCodeCacheFlushing > > > > > > > > > > After running for over 12 hours the maximum number of decompiles for a > > > > > > > > > > method is 14 and that method hit 11 decompiles very quickly and then > > > > > > > > > > leveled off (with the first fix it is still at 11). Only 7 methods > > > > have > > > > > > > > > > 8 or more decompiles and this has held steady for hours now). > > > > > > > > > > I also tried the following based on a suggestion from Chris Newland, > > > > > > > > > > but, it did not help: > > > > > > > > > > -XX:-UseBimorphicInlining > > > > > > > > > > My theory is that the Code Cache flushing algorithm coupled with the > > > > > > > > > > Code Cache demands of my application are causing the HotSpot compiler > > > > to > > > > > > > > > > "thrash". Keep cycling the methods through the Code Cache: > > > > > > > > > > 1) Compile method A > > > > > > > > > > 2) Compile method B > > > > > > > > > > 3) Kick out method A and compile method C > > > > > > > > > > 4) Kick out method B and compile method A > > > > > > > > > > Observations: > > > > > > > > > > 1) When Tiered Compilation is disabled the Code Cache max drops from > > > > > > > > > > 240mb to 48mb. > > > > > > > > > Did the problem also show up with Tiered Compilation? > > > > > This problem did not. Of course with tiered compilation enabled the code > > cache max seems to default to 240mb. I did not try running tiered with a > > smaller max code cache size. I did not that tiered seems to use a lot more > > code cache. The same application exceeds 70mb when it is enabled. > > > However with tiered compilations enabled we were seeing a hard to > > understand > > drop in performance after about 4.5 hours in both production (2 second > > response times suddenly jump to 3 to 5 seconds). I was able to reproduce > > this issue in a dev environment with surprisingly little trouble. I > > investigated this issue from many angles to try to understand what was > > going > > on (heap, linux file cache, background network traffic, processor load, EC2 > > variability). The one thing that did seem to work in dev was turning off > > Tiered compilation (a desperation idea). I have not been able to identify > > any interesting compiler logs that correlate with that issue. When we tried > > it in production it worked very well for 70 hours and then this issue > > occurred which was actually much worse. I was not a hero. > > > I sent an email on this first issue to the hotspot-dev mailing list (before > > the "turn off tiered compilation fix" failed in production), but, was not > > expecting much help because I could not provide much data to work with. > > Just > > a description of the symptoms. > > > > > 2) When not constrained (i.e. when one of my two "fixes" is applied) my > > > > > > > > > > application under this traffic load levels out at just below 22mb in > > > > the > > > > > > > > > > Code Cache. > > > > > > > > > > 3) When neither of my fixes is applied then the Code Cache usage peaks > > > > > > > > > > about 18mb, but, is highly variable minute to minute. > > > > > > > > > You could try to use a lower value of -XX:NmethodSweepActivity to avoid > > > aggressive sweeping when the code cache is getting full. But I doubt that > > > this helps because there is still enough space in the code cache. > > > > > I will try to give it a try as time permits, but, I have torn down my dev > > environment for now. I was able to reproduce this issue right on my dev > > box, > > but doing so consumes most of its resources. I may try to set it up before > > I > > leave tonight. > > > > > We are planning to implement fix one above in production soon. Any > > > > > > > > > > comments? > > > > > > > > > I think increasing the code cache size does not hurt and prevents > > > aggressive > > > sweeping in this case because a larger code cache size leads to a larger > > > per > > > method hotness threshold for flushing. > > > > > > Did you try to reproduce the problem with a JDK 9 early access build? The > > > symptoms you are describing sound quite similar to an issue we > > > encountered > > > with JDK 9. This was fixed by code aging [1] but the fix was never > > > backported to JDK 8. You can enable/disable code aging with > > > -XX:UseCodeAging > > > in 9. If the problem turns out to be fixed, we could provide a prototype > > > backport of code aging for testing in your environment. > > > > > Thanks for the info. I have not tried with Java 9. I will put that on the > > list to try. > > > > Best regards, > > > > > > Tobias > > > > > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/975d903e1de3 > > > > > > > I can provide HotSpot logs. Chris has provided me the required options > > > > > > > > > > to get the more detailed information. > > > > > > > > > > ________________________________ > > > > > > > > > > This email and any attachments may contain confidential and privileged > > > > material for the sole use of the intended recipient. Any review, > > > > copying, > > > > or > > > > distribution of this email (or any attachments) by others is > > > > prohibited. > > > > If > > > > you are not the intended recipient, please contact the sender > > > > immediately > > > > and permanently delete this email and any attachments. No employee or > > > > agent > > > > of TiVo Inc. is authorized to conclude any binding agreement on behalf > > > > of > > > > TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made > > > > by > > > > a > > > > signed written agreement. > > > > > > > > James Lent > > > Senior Software Engineer > > > Digitalsmiths > > > A TiVo Company > > > www.digitalsmiths.com > > > jlent at digitalsmiths.com | office 919.460.4747 > > James Lent > Senior Software Engineer > Digitalsmiths > A TiVo Company > www.digitalsmiths.com > jlent at digitalsmiths.com | office 919.460.4747 > This email and any attachments may contain confidential and privileged > material for the sole use of the intended recipient. Any review, copying, or > distribution of this email (or any attachments) by others is prohibited. If > you are not the intended recipient, please contact the sender immediately > and permanently delete this email and any attachments. No employee or agent > of TiVo Inc. is authorized to conclude any binding agreement on behalf of > TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a > signed written agreement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Jun 10 00:59:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Jun 2016 10:59:44 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57585B76.5050809@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> <57585B76.5050809@oracle.com> Message-ID: Hi Zoltan, On 9/06/2016 3:52 AM, Zolt?n Maj? wrote: > Hi David, > > > > On 06/02/2016 01:51 PM, David Holmes wrote: >> [...] >> The simplest, and common, approach to these kind of issues is to only >> apply the correction for the current class file version and keep the >> relaxed rules for all others. That provides the best compatibility >> story. Of course if security is a concern then that is a different >> matter - but such concerns can not be discussed here. > > thank you for the suggestion! > > In the latest webrev (webrev.06), I enable the additional check for > classfile version >= 51 (JAVA_7_VERSION). With that version, we're > conforming with the specification. So far no problems have showed up > with our test base. The new check can be disabled with the > CheckFinalFieldModifications flag (you've suggested that in your JBS > comment). > > We can also change the checked version to 52 (JAVA_8) or 53 (JAVA_9). I think this needs to go to CCC so that the compatibility issue can be examined. Normally, after long periods of non-conformance, we don't "back date" tighter checks - so my initial feeling is that this should only be enforced for Java 9 classfiles onwards. But that is not a decision for individual engineers to make. Thanks, David > Please see the updated webrev (webrev.06) in my reply to Vladimir K. > > Thank you! > > Best regards, > > > Zoltan > >> >> David >> ----- >> >>> Before JVMS-7, where putfield/putstatic linkage checks were tightened, >>> it was allowed to change final fields from anywhere in the same class. >>> >>> putfield "Linking Exceptions": >>> >>> JVMS-6 [1]: >>> "Otherwise, if the field is final, it must be declared in the >>> current class. Otherwise, an IllegalAccessError is thrown." >>> >>> JVMS-7 [2]: >>> "Otherwise, if the field is final, it must be declared in the >>> current class, and the instruction must occur in an instance >>> initialization method () of the current class. Otherwise, an >>> IllegalAccessError is thrown." >>> >>> >>> src/share/vm/interpreter/linkResolver.cpp: >>> >>> + (byte == Bytecodes::_putstatic && fd.is_static() && >>> method_name != vmSymbols::class_initializer_name()) || >>> + ((byte == Bytecodes::_putfield || byte == >>> Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != >>> vmSymbols::object_initializer_name()) >>> >>> >>> Also, as we found earlier, checking method name is not enough: >>> >>> bool Method::is_static_initializer() const { >>> // For classfiles version 51 or greater, ensure that the clinit >>> method is >>> // static. Non-static methods with the name "" are not static >>> // initializers. (older classfiles exempted for backward >>> compatibility) >>> return name() == vmSymbols::class_initializer_name() && >>> has_valid_initializer_flags(); >>> } >>> >>> >>> - LinkInfo link_info(defc, name, type, KlassHandle(), >>> /*check_access=*/false); >>> + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, >>> /*check_access=*/false); >>> >>> Use Handle() instead of NULL. >>> >>> Also, I'd prefer to see LinkInfo::_current_method and new constructor >>> added: >>> >>> LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* signature, >>> Handle current_method, bool check_access = true) : >>> >>> _current_klass can be derived from _current_method, since: >>> >>> // current_klass = sending method holder (i.e., class containing the >>> method >>> // containing the call being resolved) >>> >>>> I did the following testing: >>>> - JPRT >>>> - pre-PIT RBT run (in progress) >>>> - the reproducer. >>>> >>>> The reproducer now behaves as expected (an IllegalAccessError is >>>> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >>>> >>>> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >>>> >>>> The reason for the failure is that the the test generates a method that >>>> contains a putstatic to a static final field (i.e., the bytecodes >>>> generated by the test do not conform to the JVMS). (Even the test >>>> mentions that the Java source equivalent to the generated bytecodes is >>>> compilable only if the "final" keyword is removed from the declaration >>>> of the static field.) >>>> >>>> So (if we decide to push the current fix) the issue with the test needs >>>> to be fixed first. Do you know how we could proceed with that? >>> File a bug against JCK. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] >>> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >>> >>> >>> [2] >>> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >>> >>> >>> >>> [3] >>> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 >>> >>> >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>>> >>>>>> I agree with you, alternatively we can propose a more generic fix >>>>>> (fix >>>>>> the interpreter and the compilers as well). The fix would most likely >>>>>> affect field resolution in LinkResolver::resolve_field() around here: >>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>> inappropriate field access will propagate the exception to the >>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>> (some) >>>>>> compilations (if, e.g., fields are linked through >>>>>> ciField::will_link()). >>>>>> >>>>>> I'd prefer to take the second option (changing field resolution), but >>>>>> there might be some disadvantages related to option I might be >>>>>> overseeing. >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Thank you! >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>> >>>>>>> >>>>>>>> More details about the failure are here [3]. >>>>>>>> >>>>>>>> With the patch applied, the program always completes as it is >>>>>>>> expected >>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>> (because we >>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>> >>>>>>>> Here is the updated webrev: >>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>> Bailing out the whole compilation in C2 is even less appropriate. It >>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>> Parse::do_field_access). >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> [1] >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> > From zoltan.majo at oracle.com Fri Jun 10 06:38:38 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 08:38:38 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> <57585B76.5050809@oracle.com> Message-ID: <575A606E.90906@oracle.com> Hi David, On 06/10/2016 02:59 AM, David Holmes wrote: > Hi Zoltan, > > On 9/06/2016 3:52 AM, Zolt?n Maj? wrote: >> Hi David, >> >> >> >> On 06/02/2016 01:51 PM, David Holmes wrote: >>> [...] >>> The simplest, and common, approach to these kind of issues is to only >>> apply the correction for the current class file version and keep the >>> relaxed rules for all others. That provides the best compatibility >>> story. Of course if security is a concern then that is a different >>> matter - but such concerns can not be discussed here. >> >> thank you for the suggestion! >> >> In the latest webrev (webrev.06), I enable the additional check for >> classfile version >= 51 (JAVA_7_VERSION). With that version, we're >> conforming with the specification. So far no problems have showed up >> with our test base. The new check can be disabled with the >> CheckFinalFieldModifications flag (you've suggested that in your JBS >> comment). >> >> We can also change the checked version to 52 (JAVA_8) or 53 (JAVA_9). > > I think this needs to go to CCC so that the compatibility issue can be > examined. Normally, after long periods of non-conformance, we don't > "back date" tighter checks - so my initial feeling is that this should > only be enforced for Java 9 classfiles onwards. But that is not a > decision for individual engineers to make. Thank you for the feedback! I have changed the checked version to JAVA_9 (as you initially suggested). Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.08/ I hope we don't need CCC approval if we apply the correction for the current class version only. I can file a new bug to investigate if the checks can be tightened up to pre-JAVA_9 -- that could form the discussion with the CCC. Thank you! Best regards, Zoltan > > > Thanks, > David > >> Please see the updated webrev (webrev.06) in my reply to Vladimir K. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> David >>> ----- >>> >>>> Before JVMS-7, where putfield/putstatic linkage checks were tightened, >>>> it was allowed to change final fields from anywhere in the same class. >>>> >>>> putfield "Linking Exceptions": >>>> >>>> JVMS-6 [1]: >>>> "Otherwise, if the field is final, it must be declared in the >>>> current class. Otherwise, an IllegalAccessError is thrown." >>>> >>>> JVMS-7 [2]: >>>> "Otherwise, if the field is final, it must be declared in the >>>> current class, and the instruction must occur in an instance >>>> initialization method () of the current class. Otherwise, an >>>> IllegalAccessError is thrown." >>>> >>>> >>>> src/share/vm/interpreter/linkResolver.cpp: >>>> >>>> + (byte == Bytecodes::_putstatic && fd.is_static() && >>>> method_name != vmSymbols::class_initializer_name()) || >>>> + ((byte == Bytecodes::_putfield || byte == >>>> Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != >>>> vmSymbols::object_initializer_name()) >>>> >>>> >>>> Also, as we found earlier, checking method name is not enough: >>>> >>>> bool Method::is_static_initializer() const { >>>> // For classfiles version 51 or greater, ensure that the clinit >>>> method is >>>> // static. Non-static methods with the name "" are not >>>> static >>>> // initializers. (older classfiles exempted for backward >>>> compatibility) >>>> return name() == vmSymbols::class_initializer_name() && >>>> has_valid_initializer_flags(); >>>> } >>>> >>>> >>>> - LinkInfo link_info(defc, name, type, KlassHandle(), >>>> /*check_access=*/false); >>>> + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, >>>> /*check_access=*/false); >>>> >>>> Use Handle() instead of NULL. >>>> >>>> Also, I'd prefer to see LinkInfo::_current_method and new constructor >>>> added: >>>> >>>> LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* >>>> signature, >>>> Handle current_method, bool check_access = true) : >>>> >>>> _current_klass can be derived from _current_method, since: >>>> >>>> // current_klass = sending method holder (i.e., class containing >>>> the >>>> method >>>> // containing the call being resolved) >>>> >>>>> I did the following testing: >>>>> - JPRT >>>>> - pre-PIT RBT run (in progress) >>>>> - the reproducer. >>>>> >>>>> The reproducer now behaves as expected (an IllegalAccessError is >>>>> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >>>>> >>>>> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >>>>> >>>>> The reason for the failure is that the the test generates a method >>>>> that >>>>> contains a putstatic to a static final field (i.e., the bytecodes >>>>> generated by the test do not conform to the JVMS). (Even the test >>>>> mentions that the Java source equivalent to the generated >>>>> bytecodes is >>>>> compilable only if the "final" keyword is removed from the >>>>> declaration >>>>> of the static field.) >>>>> >>>>> So (if we decide to push the current fix) the issue with the test >>>>> needs >>>>> to be fixed first. Do you know how we could proceed with that? >>>> File a bug against JCK. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] >>>> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >>>> >>>> >>>> >>>> [2] >>>> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >>>> >>>> >>>> >>>> >>>> [3] >>>> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 >>>> >>>> >>>> >>>>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>>> >>>>>>> I agree with you, alternatively we can propose a more generic fix >>>>>>> (fix >>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>> likely >>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>> here: >>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>> inappropriate field access will propagate the exception to the >>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>> (some) >>>>>>> compilations (if, e.g., fields are linked through >>>>>>> ciField::will_link()). >>>>>>> >>>>>>> I'd prefer to take the second option (changing field >>>>>>> resolution), but >>>>>>> there might be some disadvantages related to option I might be >>>>>>> overseeing. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> More details about the failure are here [3]. >>>>>>>>> >>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>> expected >>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>> (because we >>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>> >>>>>>>>> Here is the updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>> appropriate. It >>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>> Parse::do_field_access). >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> [1] >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >> From zoltan.majo at oracle.com Fri Jun 10 06:45:32 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 08:45:32 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575A606E.90906@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> <57585B76.5050809@oracle.com> <575A606E.90906@oracle.com> Message-ID: <575A620C.706@oracle.com> P.S.: Correction of small typo: On 06/10/2016 08:38 AM, Zolt?n Maj? wrote: > [...] > I can file a new bug to investigate if the checks can be tightened up > to pre-JAVA_9 -- that could form *the base of* the discussion with the > CCC. From david.holmes at oracle.com Fri Jun 10 07:30:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Jun 2016 17:30:07 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575A606E.90906@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> <57585B76.5050809@oracle.com> <575A606E.90906@oracle.com> Message-ID: <365a7891-abce-b2e9-4974-34307410341a@oracle.com> On 10/06/2016 4:38 PM, Zolt?n Maj? wrote: > Hi David, > > > On 06/10/2016 02:59 AM, David Holmes wrote: >> Hi Zoltan, >> >> On 9/06/2016 3:52 AM, Zolt?n Maj? wrote: >>> Hi David, >>> >>> >>> >>> On 06/02/2016 01:51 PM, David Holmes wrote: >>>> [...] >>>> The simplest, and common, approach to these kind of issues is to only >>>> apply the correction for the current class file version and keep the >>>> relaxed rules for all others. That provides the best compatibility >>>> story. Of course if security is a concern then that is a different >>>> matter - but such concerns can not be discussed here. >>> >>> thank you for the suggestion! >>> >>> In the latest webrev (webrev.06), I enable the additional check for >>> classfile version >= 51 (JAVA_7_VERSION). With that version, we're >>> conforming with the specification. So far no problems have showed up >>> with our test base. The new check can be disabled with the >>> CheckFinalFieldModifications flag (you've suggested that in your JBS >>> comment). >>> >>> We can also change the checked version to 52 (JAVA_8) or 53 (JAVA_9). >> >> I think this needs to go to CCC so that the compatibility issue can be >> examined. Normally, after long periods of non-conformance, we don't >> "back date" tighter checks - so my initial feeling is that this should >> only be enforced for Java 9 classfiles onwards. But that is not a >> decision for individual engineers to make. > > Thank you for the feedback! > > I have changed the checked version to JAVA_9 (as you initially > suggested). Here is the updated webrev: > > http://cr.openjdk.java.net/~zmajo/8157181/webrev.08/ > > I hope we don't need CCC approval if we apply the correction for the > current class version only. > > I can file a new bug to investigate if the checks can be tightened up to > pre-JAVA_9 -- that could form the discussion with the CCC. That sounds fine - thanks. Note I have not reviewed the actual code. Cheers, David > Thank you! > > Best regards, > > > Zoltan > >> >> >> Thanks, >> David >> >>> Please see the updated webrev (webrev.06) in my reply to Vladimir K. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>>> >>>> David >>>> ----- >>>> >>>>> Before JVMS-7, where putfield/putstatic linkage checks were tightened, >>>>> it was allowed to change final fields from anywhere in the same class. >>>>> >>>>> putfield "Linking Exceptions": >>>>> >>>>> JVMS-6 [1]: >>>>> "Otherwise, if the field is final, it must be declared in the >>>>> current class. Otherwise, an IllegalAccessError is thrown." >>>>> >>>>> JVMS-7 [2]: >>>>> "Otherwise, if the field is final, it must be declared in the >>>>> current class, and the instruction must occur in an instance >>>>> initialization method () of the current class. Otherwise, an >>>>> IllegalAccessError is thrown." >>>>> >>>>> >>>>> src/share/vm/interpreter/linkResolver.cpp: >>>>> >>>>> + (byte == Bytecodes::_putstatic && fd.is_static() && >>>>> method_name != vmSymbols::class_initializer_name()) || >>>>> + ((byte == Bytecodes::_putfield || byte == >>>>> Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != >>>>> vmSymbols::object_initializer_name()) >>>>> >>>>> >>>>> Also, as we found earlier, checking method name is not enough: >>>>> >>>>> bool Method::is_static_initializer() const { >>>>> // For classfiles version 51 or greater, ensure that the clinit >>>>> method is >>>>> // static. Non-static methods with the name "" are not >>>>> static >>>>> // initializers. (older classfiles exempted for backward >>>>> compatibility) >>>>> return name() == vmSymbols::class_initializer_name() && >>>>> has_valid_initializer_flags(); >>>>> } >>>>> >>>>> >>>>> - LinkInfo link_info(defc, name, type, KlassHandle(), >>>>> /*check_access=*/false); >>>>> + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, >>>>> /*check_access=*/false); >>>>> >>>>> Use Handle() instead of NULL. >>>>> >>>>> Also, I'd prefer to see LinkInfo::_current_method and new constructor >>>>> added: >>>>> >>>>> LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* >>>>> signature, >>>>> Handle current_method, bool check_access = true) : >>>>> >>>>> _current_klass can be derived from _current_method, since: >>>>> >>>>> // current_klass = sending method holder (i.e., class containing >>>>> the >>>>> method >>>>> // containing the call being resolved) >>>>> >>>>>> I did the following testing: >>>>>> - JPRT >>>>>> - pre-PIT RBT run (in progress) >>>>>> - the reproducer. >>>>>> >>>>>> The reproducer now behaves as expected (an IllegalAccessError is >>>>>> thrown). Also, the pre-PIT RBT run has shown no new failures so far. >>>>>> >>>>>> But there is a problem with JPRT: A JCK test, putstatic01801m, fails. >>>>>> >>>>>> The reason for the failure is that the the test generates a method >>>>>> that >>>>>> contains a putstatic to a static final field (i.e., the bytecodes >>>>>> generated by the test do not conform to the JVMS). (Even the test >>>>>> mentions that the Java source equivalent to the generated >>>>>> bytecodes is >>>>>> compilable only if the "final" keyword is removed from the >>>>>> declaration >>>>>> of the static field.) >>>>>> >>>>>> So (if we decide to push the current fix) the issue with the test >>>>>> needs >>>>>> to be fixed first. Do you know how we could proceed with that? >>>>> File a bug against JCK. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] >>>>> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >>>>> >>>>> >>>>> >>>>> [2] >>>>> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >>>>> >>>>> >>>>> >>>>> >>>>> [3] >>>>> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 >>>>> >>>>> >>>>> >>>>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>>> >>>>>>>> I agree with you, alternatively we can propose a more generic fix >>>>>>>> (fix >>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>> likely >>>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>>> here: >>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>>> (some) >>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>> ciField::will_link()). >>>>>>>> >>>>>>>> I'd prefer to take the second option (changing field >>>>>>>> resolution), but >>>>>>>> there might be some disadvantages related to option I might be >>>>>>>> overseeing. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thank you! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> >>>>>>>> Zoltan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>> >>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>> expected >>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>> (because we >>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>> >>>>>>>>>> Here is the updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>> appropriate. It >>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>> Parse::do_field_access). >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Vladimir Ivanov >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>> > From zoltan.majo at oracle.com Fri Jun 10 08:36:18 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 10:36:18 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <365a7891-abce-b2e9-4974-34307410341a@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <988f2271-0d7e-7a02-b301-c6237f123262@oracle.com> <93b3fe16-2bb0-3e77-9333-61989f33ff1c@oracle.com> <57585B76.5050809@oracle.com> <575A606E.90906@oracle.com> <365a7891-abce-b2e9-4974-34307410341a@oracle.com> Message-ID: <575A7C02.30103@oracle.com> Hi David, On 06/10/2016 09:30 AM, David Holmes wrote: > > On 10/06/2016 4:38 PM, Zolt?n Maj? wrote: >> Hi David, >> >> >> On 06/10/2016 02:59 AM, David Holmes wrote: >>> Hi Zoltan, >>> >>> On 9/06/2016 3:52 AM, Zolt?n Maj? wrote: >>>> Hi David, >>>> >>>> >>>> >>>> On 06/02/2016 01:51 PM, David Holmes wrote: >>>>> [...] >>>>> The simplest, and common, approach to these kind of issues is to only >>>>> apply the correction for the current class file version and keep the >>>>> relaxed rules for all others. That provides the best compatibility >>>>> story. Of course if security is a concern then that is a different >>>>> matter - but such concerns can not be discussed here. >>>> >>>> thank you for the suggestion! >>>> >>>> In the latest webrev (webrev.06), I enable the additional check for >>>> classfile version >= 51 (JAVA_7_VERSION). With that version, we're >>>> conforming with the specification. So far no problems have showed up >>>> with our test base. The new check can be disabled with the >>>> CheckFinalFieldModifications flag (you've suggested that in your JBS >>>> comment). >>>> >>>> We can also change the checked version to 52 (JAVA_8) or 53 (JAVA_9). >>> >>> I think this needs to go to CCC so that the compatibility issue can be >>> examined. Normally, after long periods of non-conformance, we don't >>> "back date" tighter checks - so my initial feeling is that this should >>> only be enforced for Java 9 classfiles onwards. But that is not a >>> decision for individual engineers to make. >> >> Thank you for the feedback! >> >> I have changed the checked version to JAVA_9 (as you initially >> suggested). Here is the updated webrev: >> >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.08/ >> >> I hope we don't need CCC approval if we apply the correction for the >> current class version only. >> >> I can file a new bug to investigate if the checks can be tightened up to >> pre-JAVA_9 -- that could form the discussion with the CCC. > > That sounds fine - thanks. Thank you! I've filed JDK-8159215 [1] for tightening up the checks for Java 7 and/or Java 8. > > Note I have not reviewed the actual code. I've noted that. Thank you for all the suggestions/feedback! Best regards, Zoltan [1] https://bugs.openjdk.java.net/browse/JDK-8159215 > > Cheers, > David > >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> >>> Thanks, >>> David >>> >>>> Please see the updated webrev (webrev.06) in my reply to Vladimir K. >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Before JVMS-7, where putfield/putstatic linkage checks were >>>>>> tightened, >>>>>> it was allowed to change final fields from anywhere in the same >>>>>> class. >>>>>> >>>>>> putfield "Linking Exceptions": >>>>>> >>>>>> JVMS-6 [1]: >>>>>> "Otherwise, if the field is final, it must be declared in the >>>>>> current class. Otherwise, an IllegalAccessError is thrown." >>>>>> >>>>>> JVMS-7 [2]: >>>>>> "Otherwise, if the field is final, it must be declared in the >>>>>> current class, and the instruction must occur in an instance >>>>>> initialization method () of the current class. Otherwise, an >>>>>> IllegalAccessError is thrown." >>>>>> >>>>>> >>>>>> src/share/vm/interpreter/linkResolver.cpp: >>>>>> >>>>>> + (byte == Bytecodes::_putstatic && fd.is_static() && >>>>>> method_name != vmSymbols::class_initializer_name()) || >>>>>> + ((byte == Bytecodes::_putfield || byte == >>>>>> Bytecodes::_nofast_putfield) && !fd.is_static() && method_name != >>>>>> vmSymbols::object_initializer_name()) >>>>>> >>>>>> >>>>>> Also, as we found earlier, checking method name is not enough: >>>>>> >>>>>> bool Method::is_static_initializer() const { >>>>>> // For classfiles version 51 or greater, ensure that the clinit >>>>>> method is >>>>>> // static. Non-static methods with the name "" are not >>>>>> static >>>>>> // initializers. (older classfiles exempted for backward >>>>>> compatibility) >>>>>> return name() == vmSymbols::class_initializer_name() && >>>>>> has_valid_initializer_flags(); >>>>>> } >>>>>> >>>>>> >>>>>> - LinkInfo link_info(defc, name, type, KlassHandle(), >>>>>> /*check_access=*/false); >>>>>> + LinkInfo link_info(defc, name, type, KlassHandle(), NULL, >>>>>> /*check_access=*/false); >>>>>> >>>>>> Use Handle() instead of NULL. >>>>>> >>>>>> Also, I'd prefer to see LinkInfo::_current_method and new >>>>>> constructor >>>>>> added: >>>>>> >>>>>> LinkInfo(KlassHandle resolved_klass, Symbol* name, Symbol* >>>>>> signature, >>>>>> Handle current_method, bool check_access = true) : >>>>>> >>>>>> _current_klass can be derived from _current_method, since: >>>>>> >>>>>> // current_klass = sending method holder (i.e., class containing >>>>>> the >>>>>> method >>>>>> // containing the call being resolved) >>>>>> >>>>>>> I did the following testing: >>>>>>> - JPRT >>>>>>> - pre-PIT RBT run (in progress) >>>>>>> - the reproducer. >>>>>>> >>>>>>> The reproducer now behaves as expected (an IllegalAccessError is >>>>>>> thrown). Also, the pre-PIT RBT run has shown no new failures so >>>>>>> far. >>>>>>> >>>>>>> But there is a problem with JPRT: A JCK test, putstatic01801m, >>>>>>> fails. >>>>>>> >>>>>>> The reason for the failure is that the the test generates a method >>>>>>> that >>>>>>> contains a putstatic to a static final field (i.e., the bytecodes >>>>>>> generated by the test do not conform to the JVMS). (Even the test >>>>>>> mentions that the Java source equivalent to the generated >>>>>>> bytecodes is >>>>>>> compilable only if the "final" keyword is removed from the >>>>>>> declaration >>>>>>> of the static field.) >>>>>>> >>>>>>> So (if we decide to push the current fix) the issue with the test >>>>>>> needs >>>>>>> to be fixed first. Do you know how we could proceed with that? >>>>>> File a bug against JCK. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> [1] >>>>>> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [2] >>>>>> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [3] >>>>>> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.3.2 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>>> >>>>>>>>> I agree with you, alternatively we can propose a more generic fix >>>>>>>>> (fix >>>>>>>>> the interpreter and the compilers as well). The fix would most >>>>>>>>> likely >>>>>>>>> affect field resolution in LinkResolver::resolve_field() around >>>>>>>>> here: >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Changing resolve_field() to throw an IllegalAccessError for >>>>>>>>> inappropriate field access will propagate the exception to the >>>>>>>>> interpreter. Changing ciField::will_link() will most likely kill >>>>>>>>> (some) >>>>>>>>> compilations (if, e.g., fields are linked through >>>>>>>>> ciField::will_link()). >>>>>>>>> >>>>>>>>> I'd prefer to take the second option (changing field >>>>>>>>> resolution), but >>>>>>>>> there might be some disadvantages related to option I might be >>>>>>>>> overseeing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Zoltan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> More details about the failure are here [3]. >>>>>>>>>>> >>>>>>>>>>> With the patch applied, the program always completes as it is >>>>>>>>>>> expected >>>>>>>>>>> by Jython, no matter if we use -Xint, -Xcomp, or -Xmixed >>>>>>>>>>> (because we >>>>>>>>>>> always interpret methods non-conforming with the VM spec). >>>>>>>>>>> >>>>>>>>>>> Here is the updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.01/ >>>>>>>>>> Bailing out the whole compilation in C2 is even less >>>>>>>>>> appropriate. It >>>>>>>>>> should generate an uncommon trap for such accesses instead (see >>>>>>>>>> Parse::do_field_access). >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Vladimir Ivanov >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/c1/c1_GraphBuilder.cpp#l1595 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >> From vladimir.x.ivanov at oracle.com Fri Jun 10 12:56:53 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Jun 2016 15:56:53 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57597673.4070103@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> Message-ID: <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> http://cr.openjdk.java.net/~zmajo/8157181/webrev.08 I'm fine with enabling the checks only for 9 for now and handle 7 & 8 class files separately. >> src/share/vm/classfile/verifier.cpp: >> >> + void >> Verifier::detect_invalid_final_field_accesses(instanceKlassHandle >> klass) { >> >> The name is misleading: such accesses are legal according to JVMS-6 >> (and earlier). Maybe something like >> detect_initialized_final_field_updates? >> >> Same for: >> + bool has_invalid_final_access() const { return >> access_flags().has_field_invalid_final_access(); } >> + void set_has_invalid_final_access(const bool value) { >> + JVM_ACC_FIELD_INVALID_FINAL_ACCESS = 0x00000100, >> > > Yes, that name sounds better and I've updated the code accordingly. A leftover: src/share/vm/runtime/fieldDescriptor.hpp: + void set_has_invalid_final_access(const bool value) { >> --- >> I don't see much benefit in tracking the problematic updates >> per-methods and not per-class. So, you could do the checks in >> ClassVerifier::verify_field_instructions [1] and mark the whole class >> (ClassVerifier::_klass) as containing problematic instructions. > > The problematic updates are tracked *per-field* (and not *per-method* or > * per-class*). > > Initially, I had a version that tracked problematic instructions on a > per-class basis. With that version, once a problematic instruction was > detected, the whole class was marked as containing problematic > instructions. As a result, constant folding was disabled for accesses to > *all* final fields of that class. > > Tracking problematic updates on a per-field basis seems to be less > intrusive. That way we disable folding *only for fields to which > problematic accesses are made* (and leave constant folding enabled for > accesses to all other fields). So we can fold some accesses even for > "misbehaving" classes. I hope that is fine. > > Regarding doing checks in verify_field_instructions() [2]: It turns out > that we have two verifiers, one that is called for > > major_version >= STACKMAP_ATTRIBUTE_MAJOR_VERSION > > and a second one that is called for > > major_version < STACKMAP_ATTRIBUTE_MAJOR_VERSION. > > ClassVerifier::verify_field_instructions() is called only for class > files >= STACKMAP_ATTRIBUTE_MAJOR_VERSION so we need to call > detect_initialized_final_field_updates() after verification. > > But I think it is a good idea to move the check to the linkage phase (as > you've suggested above). While browsing the code, I got another idea: what about piggybacking on Rewriter pass (see Rewriter::scan_method)? It already sets some per-method properties (e.g., Method::has_monitor_bytecodes()). I'd like to avoid additional pass over the bytecode, because it can cause slow downs during class loading (just a precaution - I haven't measured the impact). >> --- >> src/share/vm/interpreter/linkResolver.cpp: >> >> THROW(vmSymbols::java_lang_IllegalAccessError()); >> >> + THROW(vmSymbols::java_lang_IllegalAccessError()); >> >> Please, add an error message for diagnostic purposes. > > OK, I did that. src/share/vm/interpreter/linkResolver.cpp: + if (is_put && fd.access_flags().is_final()) { + ResourceMark rm(THREAD); + char msg[200]; There's much more convenient way now - stringStream. It takes care of memory management in resource area for you and provides convenient utility functions: ResourceMark rm(THREAD); stringStream ss; ss.printf("...", ...); THROW_MSG(vmSymbols::java_lang_IllegalAccessError(), ss.as_string()); --- + if ((byte == Bytecodes::_putstatic && fd.is_static() && !m()->is_static_initializer()) || + ((byte == Bytecodes::_putfield || byte == Bytecodes::_nofast_putfield) && !fd.is_static() && !m->is_object_initializer())) { Maybe refactor it to make more readable? bool is_static_final_update = ...; bool is_instance_final_update = ...; if (is_static_final_update || is_instance_final_update) { ... Otherwise, looks good. Best regards, Vladimir Ivanov From zoltan.majo at oracle.com Fri Jun 10 14:50:40 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 16:50:40 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> Message-ID: <575AD3C0.8040303@oracle.com> Hi Vladimir, thank you for the feedback! On 06/10/2016 02:56 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.08 > > I'm fine with enabling the checks only for 9 for now and handle 7 & 8 > class files separately. OK, thanks! > >>> src/share/vm/classfile/verifier.cpp: >>> >>> + void >>> Verifier::detect_invalid_final_field_accesses(instanceKlassHandle >>> klass) { >>> >>> The name is misleading: such accesses are legal according to JVMS-6 >>> (and earlier). Maybe something like >>> detect_initialized_final_field_updates? >>> >>> Same for: >>> + bool has_invalid_final_access() const { return >>> access_flags().has_field_invalid_final_access(); } >>> + void set_has_invalid_final_access(const bool value) { >>> + JVM_ACC_FIELD_INVALID_FINAL_ACCESS = 0x00000100, >>> >> >> Yes, that name sounds better and I've updated the code accordingly. > > A leftover: > > src/share/vm/runtime/fieldDescriptor.hpp: > > + void set_has_invalid_final_access(const bool value) { Thanks for catching that, corrected. > >>> --- >>> I don't see much benefit in tracking the problematic updates >>> per-methods and not per-class. So, you could do the checks in >>> ClassVerifier::verify_field_instructions [1] and mark the whole class >>> (ClassVerifier::_klass) as containing problematic instructions. >> >> The problematic updates are tracked *per-field* (and not *per-method* or >> * per-class*). >> >> Initially, I had a version that tracked problematic instructions on a >> per-class basis. With that version, once a problematic instruction was >> detected, the whole class was marked as containing problematic >> instructions. As a result, constant folding was disabled for accesses to >> *all* final fields of that class. >> >> Tracking problematic updates on a per-field basis seems to be less >> intrusive. That way we disable folding *only for fields to which >> problematic accesses are made* (and leave constant folding enabled for >> accesses to all other fields). So we can fold some accesses even for >> "misbehaving" classes. I hope that is fine. >> >> Regarding doing checks in verify_field_instructions() [2]: It turns out >> that we have two verifiers, one that is called for >> >> major_version >= STACKMAP_ATTRIBUTE_MAJOR_VERSION >> >> and a second one that is called for >> >> major_version < STACKMAP_ATTRIBUTE_MAJOR_VERSION. >> >> ClassVerifier::verify_field_instructions() is called only for class >> files >= STACKMAP_ATTRIBUTE_MAJOR_VERSION so we need to call >> detect_initialized_final_field_updates() after verification. >> >> But I think it is a good idea to move the check to the linkage phase (as >> you've suggested above). > > While browsing the code, I got another idea: what about piggybacking > on Rewriter pass (see Rewriter::scan_method)? It already sets some > per-method properties (e.g., Method::has_monitor_bytecodes()). > > I'd like to avoid additional pass over the bytecode, because it can > cause slow downs during class loading (just a precaution - I haven't > measured the impact). I understand your concern and have moved the detection of initialized final field updates to Rewriter::scan_method(). > >>> --- >>> src/share/vm/interpreter/linkResolver.cpp: >>> >>> THROW(vmSymbols::java_lang_IllegalAccessError()); >>> >>> + THROW(vmSymbols::java_lang_IllegalAccessError()); >>> >>> Please, add an error message for diagnostic purposes. >> >> OK, I did that. > > src/share/vm/interpreter/linkResolver.cpp: > > + if (is_put && fd.access_flags().is_final()) { > + ResourceMark rm(THREAD); > + char msg[200]; > > There's much more convenient way now - stringStream. It takes care of > memory management in resource area for you and provides convenient > utility functions: > > ResourceMark rm(THREAD); > stringStream ss; > ss.printf("...", ...); > THROW_MSG(vmSymbols::java_lang_IllegalAccessError(), ss.as_string()); OK, I changed that part. > > --- > + if ((byte == Bytecodes::_putstatic && fd.is_static() && > !m()->is_static_initializer()) || > + ((byte == Bytecodes::_putfield || byte == > Bytecodes::_nofast_putfield) && !fd.is_static() && > !m->is_object_initializer())) { > > Maybe refactor it to make more readable? > > bool is_static_final_update = ...; > bool is_instance_final_update = ...; > if (is_static_final_update || is_instance_final_update) { OK, I did that. > ... > > Otherwise, looks good. Thank you! Please let me know if you spot anything with the newest changes. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.09/ JPRT is running. Best regards, Zoltan > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Jun 10 15:09:41 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Jun 2016 18:09:41 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575AD3C0.8040303@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> Message-ID: > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.09/ Looks good. Last comment: src/share/vm/interpreter/rewriter.cpp: + if (!(method->is_native() || method->is_abstract() || method->is_overpass())) { Seems redundant. Native & abstract methods don't have body. Shouldn't happen for overpasses as well (AFAIK they don't contain putstatic/putfield instructions), but it's better to analyze them (just in case). Best regards, Vladimir Ivanov From zoltan.majo at oracle.com Fri Jun 10 15:20:56 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 17:20:56 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> Message-ID: <575ADAD8.1030907@oracle.com> Hi Vladimir, On 06/10/2016 05:09 PM, Vladimir Ivanov wrote: >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.09/ > > Looks good. thank you! > > Last comment: > > src/share/vm/interpreter/rewriter.cpp: > > + if (!(method->is_native() || method->is_abstract() || > method->is_overpass())) { > > Seems redundant. Native & abstract methods don't have body. > Shouldn't happen for overpasses as well (AFAIK they don't contain > putstatic/putfield instructions), but it's better to analyze them > (just in case). OK, I've removed that condition. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.10/ JPRT is in progress. Thank you and best regards, Zoltan > > Best regards, > Vladimir Ivanov From zoltan.majo at oracle.com Fri Jun 10 15:53:17 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 17:53:17 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575ADAD8.1030907@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> Message-ID: <575AE26D.4010409@oracle.com> Hi Vladimir, On 06/10/2016 05:20 PM, Zolt?n Maj? wrote: > [...] > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.10/ > Please note an additional small change in rewriter.cpp: +if (!reverse) { // Check if any final field of the class given as parameter is modified // outside of initializer methods of the class. Fields that are modified ... +} It's sufficient to check fields during rewriting (i.e., we're coming from Rewriter::rewrite_bytecodes()). We do not need to do the checks if the class has already been rewritten but we're reversing changes due to some failure that appeared during rewriting (in that case scan_method() is called from Rewriter::restore_bytecodes()). Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ JPRT is in progress. Thank you and best regards, Zoltan > JPRT is in progress. > > Thank you and best regards, > > > Zoltan > >> >> Best regards, >> Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Fri Jun 10 16:05:21 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Jun 2016 19:05:21 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575AE26D.4010409@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> Message-ID: <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> > Please note an additional small change in rewriter.cpp: > > +if (!reverse) { > // Check if any final field of the class given as parameter is modified > // outside of initializer methods of the class. Fields that are modified > ... > +} > > It's sufficient to check fields during rewriting (i.e., we're coming > from Rewriter::rewrite_bytecodes()). We do not need to do the checks if > the class has already been rewritten but we're reversing changes due to > some failure that appeared during rewriting (in that case scan_method() > is called from Rewriter::restore_bytecodes()). Ok. > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ Looks good. src/share/vm/runtime/globals.hpp + "for classfile version >= 51") s/51/53/ (no need to send new webrev). Best regards, Vladimir Ivanov From zoltan.majo at oracle.com Fri Jun 10 17:40:32 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Jun 2016 19:40:32 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> Message-ID: <575AFB90.5060001@oracle.com> Hi Vladimir, On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: > >> Please note an additional small change in rewriter.cpp: >> >> +if (!reverse) { >> // Check if any final field of the class given as parameter is modified >> // outside of initializer methods of the class. Fields that are modified >> ... >> +} >> >> It's sufficient to check fields during rewriting (i.e., we're coming >> from Rewriter::rewrite_bytecodes()). We do not need to do the checks if >> the class has already been rewritten but we're reversing changes due to >> some failure that appeared during rewriting (in that case scan_method() >> is called from Rewriter::restore_bytecodes()). > > Ok. > >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ > > Looks good. > > src/share/vm/runtime/globals.hpp > > + "for classfile version >= 51") > > s/51/53/ (no need to send new webrev). OK, I've corrected the code in-situ (in webrev.11). I also have the JPRT results now, all tests pass. Thank you! Best regards, Zoltan > > Best regards, > Vladimir Ivanov From david.holmes at oracle.com Sat Jun 11 00:26:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 11 Jun 2016 10:26:52 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> Message-ID: <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> Hi Coleen, If I may ... On 11/06/2016 5:43 AM, Coleen Phillimore wrote: > > Hi, > > I'm late to the thread, which is good because it's better that this > check is done in the rewriter, than in InstanceKlass. > > But I'm fuzzy on why this wasn't checked in the verifier, and what the > purpose of the has_initialized_final_update (which means a non > method has updated a final field, which is a verify error, right? Can't comment on the verifier part. The check is only currently enforced for classfile versions for JDK9+ > Also, have you run the JCK tests? > > Why have a global flag if it's an error? We are enforcing a rule that has not been enforced before. To deal with compatibility issues we have provided, as is customary for non-security issues, a flag that allows the enforcement to be turned off, if it causes a problem. (Though that is more likely needed for JDK 7/8 compatibility than for 9). David > Thanks, > Coleen > > > > On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>> >>>> Please note an additional small change in rewriter.cpp: >>>> >>>> +if (!reverse) { >>>> // Check if any final field of the class given as parameter is modified >>>> // outside of initializer methods of the class. Fields that are >>>> modified >>>> ... >>>> +} >>>> >>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>> from Rewriter::rewrite_bytecodes()). We do not need to do the checks if >>>> the class has already been rewritten but we're reversing changes due to >>>> some failure that appeared during rewriting (in that case scan_method() >>>> is called from Rewriter::restore_bytecodes()). >>> >>> Ok. >>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>> >>> Looks good. >>> >>> src/share/vm/runtime/globals.hpp >>> >>> + "for classfile version >= 51") >>> >>> s/51/53/ (no need to send new webrev). >> >> OK, I've corrected the code in-situ (in webrev.11). I also have the >> JPRT results now, all tests pass. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> >> >>> >>> Best regards, >>> Vladimir Ivanov >> > From zoltan.majo at oracle.com Sat Jun 11 10:13:56 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Sat, 11 Jun 2016 12:13:56 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> Message-ID: <575BE464.4030001@oracle.com> Hi David, On 06/11/2016 02:26 AM, David Holmes wrote: > > > Hi Coleen, > > If I may ... > > On 11/06/2016 5:43 AM, Coleen Phillimore wrote: >> >> Hi, >> >> I'm late to the thread, which is good because it's better that this >> check is done in the rewriter, than in InstanceKlass. >> >> But I'm fuzzy on why this wasn't checked in the verifier, and what the >> purpose of the has_initialized_final_update (which means a non >> method has updated a final field, which is a verify error, right? > > Can't comment on the verifier part. > > The check is only currently enforced for classfile versions for JDK9+ > >> Also, have you run the JCK tests? >> >> Why have a global flag if it's an error? > > We are enforcing a rule that has not been enforced before. To deal > with compatibility issues we have provided, as is customary for > non-security issues, a flag that allows the enforcement to be turned > off, if it causes a problem. (Though that is more likely needed for > JDK 7/8 compatibility than for 9). thank you for clarifying that! Best regards, Zoltan > > David > >> Thanks, >> Coleen >> >> >> >> On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >>> Hi Vladimir, >>> >>> >>> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>>> >>>>> Please note an additional small change in rewriter.cpp: >>>>> >>>>> +if (!reverse) { >>>>> // Check if any final field of the class given as parameter is >>>>> modified >>>>> // outside of initializer methods of the class. Fields that are >>>>> modified >>>>> ... >>>>> +} >>>>> >>>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>>> from Rewriter::rewrite_bytecodes()). We do not need to do the >>>>> checks if >>>>> the class has already been rewritten but we're reversing changes >>>>> due to >>>>> some failure that appeared during rewriting (in that case >>>>> scan_method() >>>>> is called from Rewriter::restore_bytecodes()). >>>> >>>> Ok. >>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>>> >>>> Looks good. >>>> >>>> src/share/vm/runtime/globals.hpp >>>> >>>> + "for classfile version >= 51") >>>> >>>> s/51/53/ (no need to send new webrev). >>> >>> OK, I've corrected the code in-situ (in webrev.11). I also have the >>> JPRT results now, all tests pass. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>> >> From zoltan.majo at oracle.com Sat Jun 11 10:14:54 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Sat, 11 Jun 2016 12:14:54 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575BE438.6010904@oracle.com> References: <575BE438.6010904@oracle.com> Message-ID: <575BE49E.3030708@oracle.com> Forgot to add hotspot-compiler-dev, sorry. Best regards, Zoltan -------- Forwarded Message -------- Subject: Re: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods Date: Sat, 11 Jun 2016 12:13:12 +0200 From: Zolt?n Maj? To: Coleen Phillimore , hotspot-dev at openjdk.java.net Hi Coleen, thank you for the feedback! On 06/10/2016 09:43 PM, Coleen Phillimore wrote: > > Hi, > > I'm late to the thread, which is good because it's better that this > check is done in the rewriter, than in InstanceKlass. I'm glad you are OK with that. > > But I'm fuzzy on why this wasn't checked in the verifier, and what the > purpose of the has_initialized_final_update (which means a non > method has updated a final field, which is a verify error, right? I think it is a linking exception that is supposed to be thrown during field resolution. Please see some details below (I use putfield as an example). For putfield "Linking Exceptions", the JVMS-6 [1] states: "During resolution of the symbolic reference to the field, any of the exceptions pertaining to field resolution documented in Section 5.4.3.2 can be thrown. [...] Otherwise, if the field is final, it must be declared in the current class. Otherwise, an IllegalAccessError is thrown." With JVMS-7 [2], the second sentence has changed the following way: "Otherwise, if the field is final, it must be declared in the current class, and the instruction must occur in an instance initialization method () of the current class. Otherwise, an IllegalAccessError is thrown." HotSpot currently enforces JVMS-6 (i.e.,that the final field accessed by the putfield must be declared in the current class). That condition is checked in LinkResolver::resolve_field() in linkResolver.cpp. The current patch proposes to check *also* that the instruction occurs in the method, as required by JVMS-7. I've added that check also to LinkResolver::resolve_field() (I had the feeling that the two checks belong together). The new check is, however, enforced only for class file versions >=JDK-9 (as David pointed out earlier). Regarding has_initialized_final_update: Some compiler optimizations assume that final fields are modified only in initializer methods. That assumption does always not hold (e.g., for class file versions > Also, have you run the JCK tests? Yes, I've run all all JCK tests executed in JPRT (the runThese8 target). I also did a complete pre-PIT RBT (with -Xmixed and -Xcomp) run. No failures have occurred. > > Why have a global flag if it's an error? David has pointed out the reasons in his reply. Thank you! Best regards, Zoltan [1] https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html [2] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield > > Thanks, > Coleen > > > > On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>> >>>> Please note an additional small change in rewriter.cpp: >>>> >>>> +if (!reverse) { >>>> // Check if any final field of the class given as parameter is >>>> modified >>>> // outside of initializer methods of the class. Fields that are >>>> modified >>>> ... >>>> +} >>>> >>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>> from Rewriter::rewrite_bytecodes()). We do not need to do the >>>> checks if >>>> the class has already been rewritten but we're reversing changes >>>> due to >>>> some failure that appeared during rewriting (in that case >>>> scan_method() >>>> is called from Rewriter::restore_bytecodes()). >>> >>> Ok. >>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>> >>> Looks good. >>> >>> src/share/vm/runtime/globals.hpp >>> >>> + "for classfile version >= 51") >>> >>> s/51/53/ (no need to send new webrev). >> >> OK, I've corrected the code in-situ (in webrev.11). I also have the >> JPRT results now, all tests pass. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> >> >>> >>> Best regards, >>> Vladimir Ivanov >> > From tobias.hartmann at oracle.com Mon Jun 13 09:26:40 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 13 Jun 2016 11:26:40 +0200 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape Message-ID: <575E7C50.7060900@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8159244 http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. Thanks, Tobias [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm From coleen.phillimore at oracle.com Mon Jun 13 12:24:45 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 13 Jun 2016 08:24:45 -0400 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <575BE464.4030001@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <575BE464.4030001@oracle.com> Message-ID: <4043b483-c940-beb5-3bd1-908b7cab024a@oracle.com> One more question. On 6/11/16 6:13 AM, Zolt?n Maj? wrote: > Hi David, > > > On 06/11/2016 02:26 AM, David Holmes wrote: >> >> >> Hi Coleen, >> >> If I may ... >> >> On 11/06/2016 5:43 AM, Coleen Phillimore wrote: >>> >>> Hi, >>> >>> I'm late to the thread, which is good because it's better that this >>> check is done in the rewriter, than in InstanceKlass. >>> >>> But I'm fuzzy on why this wasn't checked in the verifier, and what the >>> purpose of the has_initialized_final_update (which means a non >>> method has updated a final field, which is a verify error, right? >> >> Can't comment on the verifier part. >> >> The check is only currently enforced for classfile versions for JDK9+ >> >>> Also, have you run the JCK tests? >>> >>> Why have a global flag if it's an error? >> >> We are enforcing a rule that has not been enforced before. To deal >> with compatibility issues we have provided, as is customary for >> non-security issues, a flag that allows the enforcement to be turned >> off, if it causes a problem. (Though that is more likely needed for >> JDK 7/8 compatibility than for 9). > > thank you for clarifying that! Can we time-bomb this option, so we can remove it in 10? thanks, Coleen > > Best regards, > > > Zoltan > >> >> David >> >>> Thanks, >>> Coleen >>> >>> >>> >>> On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >>>> Hi Vladimir, >>>> >>>> >>>> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>>>> >>>>>> Please note an additional small change in rewriter.cpp: >>>>>> >>>>>> +if (!reverse) { >>>>>> // Check if any final field of the class given as parameter is >>>>>> modified >>>>>> // outside of initializer methods of the class. Fields that are >>>>>> modified >>>>>> ... >>>>>> +} >>>>>> >>>>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>>>> from Rewriter::rewrite_bytecodes()). We do not need to do the >>>>>> checks if >>>>>> the class has already been rewritten but we're reversing changes >>>>>> due to >>>>>> some failure that appeared during rewriting (in that case >>>>>> scan_method() >>>>>> is called from Rewriter::restore_bytecodes()). >>>>> >>>>> Ok. >>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>>>> >>>>> Looks good. >>>>> >>>>> src/share/vm/runtime/globals.hpp >>>>> >>>>> + "for classfile version >= 51") >>>>> >>>>> s/51/53/ (no need to send new webrev). >>>> >>>> OK, I've corrected the code in-situ (in webrev.11). I also have the >>>> JPRT results now, all tests pass. >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>> >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>> >>> > From vladimir.kozlov at oracle.com Mon Jun 13 17:09:50 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Jun 2016 10:09:50 -0700 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: <575E7C50.7060900@oracle.com> References: <575E7C50.7060900@oracle.com> Message-ID: Nice work, Tobias. Use next tag: @requires vm.gc == "Parallel" | vm.gc == "null" It will run the test when UseParallelGC is specified or no GC is specified by test environment. Otherwise you may get problem if CMS or other (not G1) is specified. We should generate similar barriers code we generate at the end of constructors. See Parse::do_exits() what is applicable for String constructor in your case. Thanks, Vladimir On 6/13/16 2:26 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8159244 > http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ > http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ > > C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). > Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. > > The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). > > TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png > [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png > [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png > [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log > [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log > [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log > [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm > [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm > From dean.long at oracle.com Mon Jun 13 20:09:52 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 13 Jun 2016 13:09:52 -0700 Subject: RFS(XXS): 8159282: quarantine compiler/jvmci/compilerToVM/ReprofileTest.java Message-ID: Quarantine this intermittently-failing test: diff -r e3e630ffcd86 test/compiler/jvmci/compilerToVM/ReprofileTest.java --- a/test/compiler/jvmci/compilerToVM/ReprofileTest.java Fri Jun 10 02:43:53 2016 +0000 +++ b/test/compiler/jvmci/compilerToVM/ReprofileTest.java Mon Jun 13 12:57:40 2016 -0700 @@ -34,6 +34,7 @@ * jdk.vm.ci/jdk.vm.ci.hotspot * jdk.vm.ci/jdk.vm.ci.code * jdk.vm.ci/jdk.vm.ci.meta + * @ignore 8157861 * @build jdk.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper * @build sun.hotspot.WhiteBox * @build compiler.jvmci.compilerToVM.ReprofileTest dl From david.holmes at oracle.com Mon Jun 13 22:05:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jun 2016 08:05:08 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <4043b483-c940-beb5-3bd1-908b7cab024a@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <575BE464.4030001@oracle.com> <4043b483-c940-beb5-3bd1-908b7cab024a@oracle.com> Message-ID: On 13/06/2016 10:24 PM, Coleen Phillimore wrote: > One more question. >>>> Why have a global flag if it's an error? >>> >>> We are enforcing a rule that has not been enforced before. To deal >>> with compatibility issues we have provided, as is customary for >>> non-security issues, a flag that allows the enforcement to be turned >>> off, if it causes a problem. (Though that is more likely needed for >>> JDK 7/8 compatibility than for 9). >> >> thank you for clarifying that! > > Can we time-bomb this option, so we can remove it in 10? I think it would have to follow a staged deprecation process: deprecate in 10 and remove in 11. To some extent it depends on whether the systems that currently produce this non-compliant bytecode can be modified in the JDK 9 and 10 timeframes so that the problem disappears. It may be this becomes a non-issue even before 9 GA ... David > thanks, > Coleen > >> >> Best regards, >> >> >> Zoltan >> >>> >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> >>>> On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >>>>> Hi Vladimir, >>>>> >>>>> >>>>> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>>>>> >>>>>>> Please note an additional small change in rewriter.cpp: >>>>>>> >>>>>>> +if (!reverse) { >>>>>>> // Check if any final field of the class given as parameter is >>>>>>> modified >>>>>>> // outside of initializer methods of the class. Fields that are >>>>>>> modified >>>>>>> ... >>>>>>> +} >>>>>>> >>>>>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>>>>> from Rewriter::rewrite_bytecodes()). We do not need to do the >>>>>>> checks if >>>>>>> the class has already been rewritten but we're reversing changes >>>>>>> due to >>>>>>> some failure that appeared during rewriting (in that case >>>>>>> scan_method() >>>>>>> is called from Rewriter::restore_bytecodes()). >>>>>> >>>>>> Ok. >>>>>> >>>>>>> Here is the updated webrev: >>>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>>>>> >>>>>> Looks good. >>>>>> >>>>>> src/share/vm/runtime/globals.hpp >>>>>> >>>>>> + "for classfile version >= 51") >>>>>> >>>>>> s/51/53/ (no need to send new webrev). >>>>> >>>>> OK, I've corrected the code in-situ (in webrev.11). I also have the >>>>> JPRT results now, all tests pass. >>>>> >>>>> Thank you! >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>> >>>>> >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>> >>>> >> > From dean.long at oracle.com Mon Jun 13 22:28:31 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 13 Jun 2016 15:28:31 -0700 Subject: RFR(XS): 8158360: C1: SEGV in generated code Message-ID: <4a36aa15-b8c5-e84b-a459-884fbbb5b749@oracle.com> The (closed) bug 8158360 is caused by a misplaced null-check on one of our closed platforms, when compressed oops are involved. However, the failure was not showing up in nightly testing, so I am updating an existing test to cover this case. Tested by hand and with RBT hs-nightly-comp.js. http://cr.openjdk.java.net/~dlong/8158360/webrev/ dl From tom.rodriguez at oracle.com Tue Jun 14 00:26:19 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 13 Jun 2016 17:26:19 -0700 Subject: RFR 8158850: [JVMCI] be more precise when enforcing OopMapValue encoding limitations Message-ID: http://cr.openjdk.java.net/~never/8158850/webrev The encoding used by OopMapValue puts a limit on the offset in the frame that can hold an oop. Previously this was enforced by setting a limit on the actual frame size but that value wasn?t accurate. It also sets an arbitrary limit on the total size of a frame, even if the encoding limits aren?t reached. Instead JVMCI should export the max offset that can be encoded and will throw an error if that offset is used. The relationship between the max offset and the encoding limits is computed from OopMapValue and checked by asserts. I also added a test that verifies the limits. Tested with jtreg test and with Graal based tests. tom From tobias.hartmann at oracle.com Tue Jun 14 10:08:12 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 14 Jun 2016 12:08:12 +0200 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: References: <575E7C50.7060900@oracle.com> Message-ID: <575FD78C.8080802@oracle.com> Hi Vladimir, thanks for the review! On 13.06.2016 19:09, Vladimir Kozlov wrote: > Nice work, Tobias. > > Use next tag: > > @requires vm.gc == "Parallel" | vm.gc == "null" > > It will run the test when UseParallelGC is specified or no GC is specified by test environment. Otherwise you may get problem if CMS or other (not G1) is specified. Right, I added the precondition to the test. > We should generate similar barriers code we generate at the end of constructors. See Parse::do_exits() what is applicable for String constructor in your case. In Parse::do_exits() we emit a MemBarRelease if the constructor writes to a final field to ensure that the effect of the initialization is committed to memory before any code publishes a reference to the newly constructed object. I agree that we should do the same after constructing/initializing a new String object because the String.value field is final. >From my understanding, a MemBarRelease is basically a combination of a LoadStoreBarrier and a StoreStoreBarrier. See sparc.ad: __ membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); So I wondered why a StoreStoreBarrier is not sufficient in this case. For the record, I found this nice description of a case where a StoreStore is not sufficient: http://www.hboehm.info/c++mm/no_write_fences.html New webrevs: http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.01 http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01 Thanks, Tobias > Thanks, > Vladimir > > On 6/13/16 2:26 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> https://bugs.openjdk.java.net/browse/JDK-8159244 >> http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ >> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ >> >> C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). >> Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. >> >> The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). >> >> TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png >> [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png >> [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png >> [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log >> [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log >> [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log >> [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm >> [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm >> From vladimir.x.ivanov at oracle.com Tue Jun 14 12:17:10 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Jun 2016 15:17:10 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> Message-ID: <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> >> Also, have you run the JCK tests? >> >> Why have a global flag if it's an error? > > We are enforcing a rule that has not been enforced before. To deal with > compatibility issues we have provided, as is customary for non-security > issues, a flag that allows the enforcement to be turned off, if it > causes a problem. (Though that is more likely needed for JDK 7/8 > compatibility than for 9). FTR I'd like to see the checks turned ON by default for 7/8 in 9 and the flag providing an escape hatch for compatibility purposes. It is motivated by the desire to limit possibilities of final field updates at runtime, so JIT-compilers have more freedom optimizing loads from final fields. It will be unfortunate if we effectively forbid final field updates outside of initializers starting only from 9 (class files >=53) and not 7 (cf >=51). The change requires a CCC request and will be investigated separately (JDK-8159215 [1]). If there are serious compatibility issues found during EA testing, we can turn the checks OFF by default. The flag is declared as diagnostic, so I don't think we need to go through deprecation process (as we do for product flags) and just remove it in the next(?) major release. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8159215 From david.holmes at oracle.com Tue Jun 14 13:08:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jun 2016 23:08:14 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> Message-ID: On 14/06/2016 10:17 PM, Vladimir Ivanov wrote: >>> Also, have you run the JCK tests? >>> >>> Why have a global flag if it's an error? >> >> We are enforcing a rule that has not been enforced before. To deal with >> compatibility issues we have provided, as is customary for non-security >> issues, a flag that allows the enforcement to be turned off, if it >> causes a problem. (Though that is more likely needed for JDK 7/8 >> compatibility than for 9). > > FTR I'd like to see the checks turned ON by default for 7/8 in 9 and the > flag providing an escape hatch for compatibility purposes. > > It is motivated by the desire to limit possibilities of final field > updates at runtime, so JIT-compilers have more freedom optimizing loads > from final fields. It will be unfortunate if we effectively forbid final > field updates outside of initializers starting only from 9 (class files >>=53) and not 7 (cf >=51). > > The change requires a CCC request and will be investigated separately > (JDK-8159215 [1]). Ok. JDK 7/8 code exists now and by changing the rules you may break code that was working. We can't expect that code to be fixed, but that is why we have to provide the flag to disable the check. The question is whether this will impact a large or small number of users, and whether it will impact things that can readily have the flag applied. > If there are serious compatibility issues found during EA testing, we > can turn the checks OFF by default. I doubt we will test very much that would expose this. As I understand it this only affects non-Java languages running on the JVM. (Though I supposed hand-assembled Java code could also have this.) > The flag is declared as diagnostic, so I don't think we need to go > through deprecation process (as we do for product flags) and just remove > it in the next(?) major release. I had not looked at the code and did not know the flag was marked diagnostic - that doesn't seem right to me. This isn't about diagnostics. The issue with removing the flag is when you can reasonably expect any existing "bad" code will be updated. I can't judge the scope/extent of the problem - it may be trivially small, or may not. Thanks, David > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8159215 From vladimir.x.ivanov at oracle.com Tue Jun 14 14:17:00 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Jun 2016 17:17:00 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> Message-ID: <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> >>>> Also, have you run the JCK tests? >>>> >>>> Why have a global flag if it's an error? >>> >>> We are enforcing a rule that has not been enforced before. To deal with >>> compatibility issues we have provided, as is customary for non-security >>> issues, a flag that allows the enforcement to be turned off, if it >>> causes a problem. (Though that is more likely needed for JDK 7/8 >>> compatibility than for 9). >> >> FTR I'd like to see the checks turned ON by default for 7/8 in 9 and the >> flag providing an escape hatch for compatibility purposes. >> >> It is motivated by the desire to limit possibilities of final field >> updates at runtime, so JIT-compilers have more freedom optimizing loads >> from final fields. It will be unfortunate if we effectively forbid final >> field updates outside of initializers starting only from 9 (class files >>> =53) and not 7 (cf >=51). >> >> The change requires a CCC request and will be investigated separately >> (JDK-8159215 [1]). > > Ok. JDK 7/8 code exists now and by changing the rules you may break code > that was working. We can't expect that code to be fixed, but that is why > we have to provide the flag to disable the check. The question is > whether this will impact a large or small number of users, and whether > it will impact things that can readily have the flag applied. Yes, impact is what should drive the decision. The plan is to have the checks (either ON or OFF by default) only in 9 (no backports to 7/8). If the checks are ON by default, users should handle any problems caused by them when migrating between major releases, which sounds reasonable (if impact is low). There will be a choice to fix the library/application or disable problematic checks (by setting the flag). >> If there are serious compatibility issues found during EA testing, we >> can turn the checks OFF by default. > > I doubt we will test very much that would expose this. As I understand > it this only affects non-Java languages running on the JVM. (Though I > supposed hand-assembled Java code could also have this.) There's Quality Outreach program [1] (conducted by Adoption Group) and many popular FOSS Java projects test OpenJDK 9 builds. So, the projects involved should notice if the change affects them. >> The flag is declared as diagnostic, so I don't think we need to go >> through deprecation process (as we do for product flags) and just remove >> it in the next(?) major release. > > I had not looked at the code and did not know the flag was marked > diagnostic - that doesn't seem right to me. This isn't about diagnostics. Good point. Maybe make it product and deprecate right from the beginning then? > The issue with removing the flag is when you can reasonably expect any > existing "bad" code will be updated. I can't judge the scope/extent of > the problem - it may be trivially small, or may not. Thinking about that more, I don't see much value in the flag if the checks are OFF for 7-8 (cf <53) by default. If we don't enable the checks in 9, I'm sure we will never change that. I don't see any value in providing opt-out option for 9 (cf >=53). The impact is limited: javac doesn't produce such code shape and bytecode generators require a change to produce cf =53. New code should adhere to JVMS in this particular case. So, if we decide that enabling the checks for 7-8 is too risky, we can remove the flag. Best regards, Vladimir Ivanov [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach From coleen.phillimore at oracle.com Tue Jun 14 14:34:17 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Jun 2016 10:34:17 -0400 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> Message-ID: <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> On 6/14/16 10:17 AM, Vladimir Ivanov wrote: > >>>>> Also, have you run the JCK tests? >>>>> >>>>> Why have a global flag if it's an error? >>>> >>>> We are enforcing a rule that has not been enforced before. To deal >>>> with >>>> compatibility issues we have provided, as is customary for >>>> non-security >>>> issues, a flag that allows the enforcement to be turned off, if it >>>> causes a problem. (Though that is more likely needed for JDK 7/8 >>>> compatibility than for 9). >>> >>> FTR I'd like to see the checks turned ON by default for 7/8 in 9 and >>> the >>> flag providing an escape hatch for compatibility purposes. >>> >>> It is motivated by the desire to limit possibilities of final field >>> updates at runtime, so JIT-compilers have more freedom optimizing loads >>> from final fields. It will be unfortunate if we effectively forbid >>> final >>> field updates outside of initializers starting only from 9 (class files >>>> =53) and not 7 (cf >=51). >>> >>> The change requires a CCC request and will be investigated separately >>> (JDK-8159215 [1]). >> >> Ok. JDK 7/8 code exists now and by changing the rules you may break code >> that was working. We can't expect that code to be fixed, but that is why >> we have to provide the flag to disable the check. The question is >> whether this will impact a large or small number of users, and whether >> it will impact things that can readily have the flag applied. > > Yes, impact is what should drive the decision. > > The plan is to have the checks (either ON or OFF by default) only in 9 > (no backports to 7/8). > > If the checks are ON by default, users should handle any problems > caused by them when migrating between major releases, which sounds > reasonable (if impact is low). There will be a choice to fix the > library/application or disable problematic checks (by setting the flag). > >>> If there are serious compatibility issues found during EA testing, we >>> can turn the checks OFF by default. >> >> I doubt we will test very much that would expose this. As I understand >> it this only affects non-Java languages running on the JVM. (Though I >> supposed hand-assembled Java code could also have this.) > > There's Quality Outreach program [1] (conducted by Adoption Group) and > many popular FOSS Java projects test OpenJDK 9 builds. So, the > projects involved should notice if the change affects them. > >>> The flag is declared as diagnostic, so I don't think we need to go >>> through deprecation process (as we do for product flags) and just >>> remove >>> it in the next(?) major release. >> >> I had not looked at the code and did not know the flag was marked >> diagnostic - that doesn't seem right to me. This isn't about >> diagnostics. > > Good point. Maybe make it product and deprecate right from the > beginning then? > >> The issue with removing the flag is when you can reasonably expect any >> existing "bad" code will be updated. I can't judge the scope/extent of >> the problem - it may be trivially small, or may not. > > Thinking about that more, I don't see much value in the flag if the > checks are OFF for 7-8 (cf <53) by default. If we don't enable the > checks in 9, I'm sure we will never change that. > > I don't see any value in providing opt-out option for 9 (cf >=53). The > impact is limited: javac doesn't produce such code shape and bytecode > generators require a change to produce cf =53. New code should adhere > to JVMS in this particular case. > > So, if we decide that enabling the checks for 7-8 is too risky, we can > remove the flag. I would vote for pre-deprecating or removing the flag. We don't generally add flags for new spec enforcement unless we anticipate a lot of customers having problems with the new rule. Just make sure the error message is really good though, so that when people hit this new rule, they'll know what to fix. Coleen > > Best regards, > Vladimir Ivanov > > [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach From vladimir.kozlov at oracle.com Tue Jun 14 16:16:01 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jun 2016 09:16:01 -0700 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: <575FD78C.8080802@oracle.com> References: <575E7C50.7060900@oracle.com> <575FD78C.8080802@oracle.com> Message-ID: Looks good to me. Thanks, Vladimir On 6/14/16 3:08 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review! > > On 13.06.2016 19:09, Vladimir Kozlov wrote: >> Nice work, Tobias. >> >> Use next tag: >> >> @requires vm.gc == "Parallel" | vm.gc == "null" >> >> It will run the test when UseParallelGC is specified or no GC is specified by test environment. Otherwise you may get problem if CMS or other (not G1) is specified. > > Right, I added the precondition to the test. > >> We should generate similar barriers code we generate at the end of constructors. See Parse::do_exits() what is applicable for String constructor in your case. > > In Parse::do_exits() we emit a MemBarRelease if the constructor writes to a final field to ensure that the effect of the initialization is committed to memory before any code publishes a reference to the newly constructed object. I agree that we should do the same after constructing/initializing a new String object because the String.value field is final. > > From my understanding, a MemBarRelease is basically a combination of a LoadStoreBarrier and a StoreStoreBarrier. See sparc.ad: > > __ membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); > > So I wondered why a StoreStoreBarrier is not sufficient in this case. For the record, I found this nice description of a case where a StoreStore is not sufficient: http://www.hboehm.info/c++mm/no_write_fences.html > > New webrevs: > http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.01 > http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01 > > Thanks, > Tobias > >> Thanks, >> Vladimir >> >> On 6/13/16 2:26 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8159244 >>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ >>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ >>> >>> C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). >>> Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. >>> >>> The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). >>> >>> TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png >>> [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png >>> [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png >>> [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log >>> [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log >>> [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log >>> [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm >>> [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm >>> From tobias.hartmann at oracle.com Tue Jun 14 16:22:20 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 14 Jun 2016 18:22:20 +0200 Subject: [8u/9] RFR(S): 8159244: Partially initialized string object created by C2's string concat optimization may escape In-Reply-To: References: <575E7C50.7060900@oracle.com> <575FD78C.8080802@oracle.com> Message-ID: <57602F3C.20601@oracle.com> Thanks, Vladimir! Best regards, Tobias On 14.06.2016 18:16, Vladimir Kozlov wrote: > Looks good to me. > > Thanks, > Vladimir > > On 6/14/16 3:08 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> On 13.06.2016 19:09, Vladimir Kozlov wrote: >>> Nice work, Tobias. >>> >>> Use next tag: >>> >>> @requires vm.gc == "Parallel" | vm.gc == "null" >>> >>> It will run the test when UseParallelGC is specified or no GC is specified by test environment. Otherwise you may get problem if CMS or other (not G1) is specified. >> >> Right, I added the precondition to the test. >> >>> We should generate similar barriers code we generate at the end of constructors. See Parse::do_exits() what is applicable for String constructor in your case. >> >> In Parse::do_exits() we emit a MemBarRelease if the constructor writes to a final field to ensure that the effect of the initialization is committed to memory before any code publishes a reference to the newly constructed object. I agree that we should do the same after constructing/initializing a new String object because the String.value field is final. >> >> From my understanding, a MemBarRelease is basically a combination of a LoadStoreBarrier and a StoreStoreBarrier. See sparc.ad: >> >> __ membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); >> >> So I wondered why a StoreStoreBarrier is not sufficient in this case. For the record, I found this nice description of a case where a StoreStore is not sufficient: http://www.hboehm.info/c++mm/no_write_fences.html >> >> New webrevs: >> http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.01 >> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01 >> >> Thanks, >> Tobias >> >>> Thanks, >>> Vladimir >>> >>> On 6/13/16 2:26 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8159244 >>>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.9.00/ >>>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.00/ >>>> >>>> C2's String concatenation optimization replaces a series of StringBuilder.append() calls by creating a single char buffer array (or byte array with Compact Strings) and emitting direct loads/stores to/from this array. The final StringBuilder.toString() call is replaced by a new String allocation which is initialized to the buffer array (see [1] -> [2], CallStaticJava is replaced). >>>> Depending on the scheduling of instructions, it may happen that a reference to the newly allocated String object escapes before the String.value field is initialized (see [2], '334 StoreP' stores the String object, '514 StoreP' initializes the String.value field). In a highly concurrent setting, another thread may try to dereference String.value from such a partially initialized String object and crash. >>>> >>>> The solution is to add a StoreStore barrier after the String object initialization to prevent subsequent stores to float above (we do the same for the Object.clone intrinsic). I verified correctness of the C2 graph (see [3]) and the generated assembly code (compare baseline [7] and fix [8]). >>>> >>>> TestStringObjectInitialization.java reproduces this problem with JDK 7, 8 and 9 (see [4], [5], [6]) in approximately 1 out of 10 runs. I had to disable Indify String Concat, Compressed Oops and G1 to trigger the bug with JDK 9. Tested with JPRT and RBT. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/secure/attachment/60305/graph_baseline_before%20SC.png >>>> [2] https://bugs.openjdk.java.net/secure/attachment/60306/graph_baseline_after_sc.png >>>> [3] https://bugs.openjdk.java.net/secure/attachment/60304/graph_fix.png >>>> [4] https://bugs.openjdk.java.net/secure/attachment/60298/JDK7_hs_err_pid17491.log >>>> [5] https://bugs.openjdk.java.net/secure/attachment/60264/JDK8u_hs_err_pid23015.log >>>> [6] https://bugs.openjdk.java.net/secure/attachment/60263/JDK9_hs_err_pid383.log >>>> [7] https://bugs.openjdk.java.net/secure/attachment/60303/baseline.asm >>>> [8] https://bugs.openjdk.java.net/secure/attachment/60302/fix.asm >>>> From volker.simonis at gmail.com Tue Jun 14 18:12:19 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jun 2016 20:12:19 +0200 Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions Message-ID: Hi, can I please get a review for this small change which fixes a code generation problem on ppc64: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ https://bugs.openjdk.java.net/browse/JDK-8158260 In the case where we access an unaligned address trough Unsafe, we could generate an illegal instruction because we didn't correctly specify the memory operand of some match rules. The fix is trivial. Although this change is ppc64-specific I think I need a sponsor because the change contains a new regression test which is supposed to run on all platforms. On platforms where Unsafe.unalignedAccess() will return false (e.g. Solaris/SPARC) this test will return immediately (and I've verified that it works). I've also added aarch64 to the list of recipients because on aarch64 Unsafe.unalignedAccess() is apparently supported and it would be nice if somebody could check that the new regression test is indeed working there. @Hiroshi, Gustavo: could you please verify that this change is enough to fix the initial problems you've observed when running Cassandra on Linux/ppc64? The changes from ppc64.ad should easily apply to the 8u-dev repository. Once we've got this into jdk9 I'll trigger a downport request to get the fix into jdk8 as well. Thank you and best regards, Volker From vladimir.kozlov at oracle.com Tue Jun 14 18:40:08 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jun 2016 11:40:08 -0700 Subject: RFR: 8159063: aarch64: optimise unaligned array copy long In-Reply-To: <4331ad27-6c58-712e-4bf1-34972fee8cfc@oracle.com> References: <1465399545.18136.11.camel@mylittlepony.linaroharston> <4331ad27-6c58-712e-4bf1-34972fee8cfc@oracle.com> Message-ID: <712dcd1a-14f0-d671-6094-b55a9d1b99c6@oracle.com> Mark R. sent mail about approval process: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html " - If you own a JEP or a small enhancement that is not yet complete then you can request an FC extension as follows: Update the JBS issue to add a comment whose first line is "FC Extension Request". In that comment describe the remaining work to be done, the risk level, a brief justification, and your best estimate of the date by which the feature will be complete. Add the label "jdk9-fc-request" to the issue. " If you have reviewed changes add link to the RFE. Regards, Vladimir On 6/8/16 9:01 AM, Vladimir Kozlov wrote: > Please, hold on pushing this RFE into jdk 9. We are post FC and it needs > approval. > > Thanks, > Vladimir > > On 6/8/16 8:25 AM, Edward Nevill wrote: >> Hi, >> >> Please review the following webrev >> >> http://cr.openjdk.java.net/~enevill/8159063/webrev >> >> JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8159063 >> >> This webrev optimises the code generate for copy array long to ensure >> that loads/stores are always done on 128 bit boundaries. >> >> This can be switched on/off with -XX:+/-AvoidUnalignedAccesses which is >> set by default for those partners where there is a benefit. >> >> The following is my test case. >> >> http://cr.openjdk.java.net/~enevill/8159063/ArrayCopyAligned.java >> >> To run do >> >> java ArrayCopyAligned >> >> This shows the results for partners A and B with the parameters 10 0 >> 1024 32. >> >> http://cr.openjdk.java.net/~enevill/8159063/arraycopy.pdf >> >> OK to push to jdk8u now (and later to jdk9)? >> >> Thanks, >> Ed. >> >> From david.holmes at oracle.com Tue Jun 14 21:02:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jun 2016 07:02:15 +1000 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> References: <573C2DAD.1030903@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> Message-ID: On 15/06/2016 12:34 AM, Coleen Phillimore wrote: > > > On 6/14/16 10:17 AM, Vladimir Ivanov wrote: >> >>>>>> Also, have you run the JCK tests? >>>>>> >>>>>> Why have a global flag if it's an error? >>>>> >>>>> We are enforcing a rule that has not been enforced before. To deal >>>>> with >>>>> compatibility issues we have provided, as is customary for >>>>> non-security >>>>> issues, a flag that allows the enforcement to be turned off, if it >>>>> causes a problem. (Though that is more likely needed for JDK 7/8 >>>>> compatibility than for 9). >>>> >>>> FTR I'd like to see the checks turned ON by default for 7/8 in 9 and >>>> the >>>> flag providing an escape hatch for compatibility purposes. >>>> >>>> It is motivated by the desire to limit possibilities of final field >>>> updates at runtime, so JIT-compilers have more freedom optimizing loads >>>> from final fields. It will be unfortunate if we effectively forbid >>>> final >>>> field updates outside of initializers starting only from 9 (class files >>>>> =53) and not 7 (cf >=51). >>>> >>>> The change requires a CCC request and will be investigated separately >>>> (JDK-8159215 [1]). >>> >>> Ok. JDK 7/8 code exists now and by changing the rules you may break code >>> that was working. We can't expect that code to be fixed, but that is why >>> we have to provide the flag to disable the check. The question is >>> whether this will impact a large or small number of users, and whether >>> it will impact things that can readily have the flag applied. >> >> Yes, impact is what should drive the decision. >> >> The plan is to have the checks (either ON or OFF by default) only in 9 >> (no backports to 7/8). >> >> If the checks are ON by default, users should handle any problems >> caused by them when migrating between major releases, which sounds >> reasonable (if impact is low). There will be a choice to fix the >> library/application or disable problematic checks (by setting the flag). >> >>>> If there are serious compatibility issues found during EA testing, we >>>> can turn the checks OFF by default. >>> >>> I doubt we will test very much that would expose this. As I understand >>> it this only affects non-Java languages running on the JVM. (Though I >>> supposed hand-assembled Java code could also have this.) >> >> There's Quality Outreach program [1] (conducted by Adoption Group) and >> many popular FOSS Java projects test OpenJDK 9 builds. So, the >> projects involved should notice if the change affects them. >> >>>> The flag is declared as diagnostic, so I don't think we need to go >>>> through deprecation process (as we do for product flags) and just >>>> remove >>>> it in the next(?) major release. >>> >>> I had not looked at the code and did not know the flag was marked >>> diagnostic - that doesn't seem right to me. This isn't about >>> diagnostics. >> >> Good point. Maybe make it product and deprecate right from the >> beginning then? >> >>> The issue with removing the flag is when you can reasonably expect any >>> existing "bad" code will be updated. I can't judge the scope/extent of >>> the problem - it may be trivially small, or may not. >> >> Thinking about that more, I don't see much value in the flag if the >> checks are OFF for 7-8 (cf <53) by default. If we don't enable the >> checks in 9, I'm sure we will never change that. >> >> I don't see any value in providing opt-out option for 9 (cf >=53). The >> impact is limited: javac doesn't produce such code shape and bytecode >> generators require a change to produce cf =53. New code should adhere >> to JVMS in this particular case. >> >> So, if we decide that enabling the checks for 7-8 is too risky, we can >> remove the flag. > > I would vote for pre-deprecating or removing the flag. We don't > generally add flags for new spec enforcement unless we anticipate a lot > of customers having problems with the new rule. Just make sure the > error message is really good though, so that when people hit this new > rule, they'll know what to fix. Okay. If this is restricted to 9 then we can drop the flag and require any "offenders" to become compliant if they plan to ship Java 9 version bytecode. David ----- > > Coleen >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach > From dean.long at oracle.com Tue Jun 14 21:35:05 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 14 Jun 2016 14:35:05 -0700 Subject: RFS(XXS): 8159282: quarantine compiler/jvmci/compilerToVM/ReprofileTest.java Message-ID: <6ce40df6-2568-a3ce-c523-ff066939b1f4@oracle.com> [expanded audience to include runtime] Quarantine this intermittently-failing test: diff -r e3e630ffcd86 test/compiler/jvmci/compilerToVM/ReprofileTest.java --- a/test/compiler/jvmci/compilerToVM/ReprofileTest.java Fri Jun 10 02:43:53 2016 +0000 +++ b/test/compiler/jvmci/compilerToVM/ReprofileTest.java Mon Jun 13 12:57:40 2016 -0700 @@ -34,6 +34,7 @@ * jdk.vm.ci/jdk.vm.ci.hotspot * jdk.vm.ci/jdk.vm.ci.code * jdk.vm.ci/jdk.vm.ci.meta + * @ignore 8157861 * @build jdk.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper * @build sun.hotspot.WhiteBox * @build compiler.jvmci.compilerToVM.ReprofileTest dl From dean.long at oracle.com Tue Jun 14 21:36:04 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 14 Jun 2016 14:36:04 -0700 Subject: PING RFR(XS): 8158360: C1: SEGV in generated code Message-ID: The (closed) bug 8158360 is caused by a misplaced null-check on one of our closed platforms, when compressed oops are involved. However, the failure was not showing up in nightly testing, so I am updating an existing test to cover this case. Tested by hand and with RBT hs-nightly-comp.js. http://cr.openjdk.java.net/~dlong/8158360/webrev/ dl From igor.ignatyev at oracle.com Tue Jun 14 22:03:18 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 15 Jun 2016 01:03:18 +0300 Subject: RFS(XXS): 8159282: quarantine compiler/jvmci/compilerToVM/ReprofileTest.java In-Reply-To: References: Message-ID: <622BE066-D5DC-41B8-A232-0C062E32B593@oracle.com> Dean, looks good to me. Thanks, ? Igor > On Jun 13, 2016, at 11:09 PM, dean.long at oracle.com wrote: > > Quarantine this intermittently-failing test: > > diff -r e3e630ffcd86 test/compiler/jvmci/compilerToVM/ReprofileTest.java > --- a/test/compiler/jvmci/compilerToVM/ReprofileTest.java Fri Jun 10 02:43:53 2016 +0000 > +++ b/test/compiler/jvmci/compilerToVM/ReprofileTest.java Mon Jun 13 12:57:40 2016 -0700 > @@ -34,6 +34,7 @@ > * jdk.vm.ci/jdk.vm.ci.hotspot > * jdk.vm.ci/jdk.vm.ci.code > * jdk.vm.ci/jdk.vm.ci.meta > + * @ignore 8157861 > * @build jdk.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper > * @build sun.hotspot.WhiteBox > * @build compiler.jvmci.compilerToVM.ReprofileTest > > > dl > From dean.long at oracle.com Tue Jun 14 22:19:45 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 14 Jun 2016 15:19:45 -0700 Subject: RFS(XXS): 8159282: quarantine compiler/jvmci/compilerToVM/ReprofileTest.java In-Reply-To: <622BE066-D5DC-41B8-A232-0C062E32B593@oracle.com> References: <622BE066-D5DC-41B8-A232-0C062E32B593@oracle.com> Message-ID: <4aba0ccc-bcfd-9f47-dd97-f492d5ae97e1@oracle.com> Thanks Igor. dl On 6/14/16 3:03 PM, Igor Ignatyev wrote: > Dean, > > looks good to me. > > Thanks, > ? Igor >> On Jun 13, 2016, at 11:09 PM, dean.long at oracle.com wrote: >> >> Quarantine this intermittently-failing test: >> >> diff -r e3e630ffcd86 test/compiler/jvmci/compilerToVM/ReprofileTest.java >> --- a/test/compiler/jvmci/compilerToVM/ReprofileTest.java Fri Jun 10 02:43:53 2016 +0000 >> +++ b/test/compiler/jvmci/compilerToVM/ReprofileTest.java Mon Jun 13 12:57:40 2016 -0700 >> @@ -34,6 +34,7 @@ >> * jdk.vm.ci/jdk.vm.ci.hotspot >> * jdk.vm.ci/jdk.vm.ci.code >> * jdk.vm.ci/jdk.vm.ci.meta >> + * @ignore 8157861 >> * @build jdk.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper >> * @build sun.hotspot.WhiteBox >> * @build compiler.jvmci.compilerToVM.ReprofileTest >> >> >> dl >> From vladimir.kozlov at oracle.com Tue Jun 14 22:24:51 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jun 2016 15:24:51 -0700 Subject: PING RFR(XS): 8158360: C1: SEGV in generated code In-Reply-To: References: Message-ID: <868606f3-6b0f-4d0a-cb66-0b6c37706077@oracle.com> Good. Thanks, Vladimir On 6/14/16 2:36 PM, dean.long at oracle.com wrote: > The (closed) bug 8158360 is caused by a misplaced null-check on one of > our closed platforms, when compressed oops are involved. However, the > failure was not showing up in nightly testing, so I am updating an > existing test to cover this case. > > Tested by hand and with RBT hs-nightly-comp.js. > > http://cr.openjdk.java.net/~dlong/8158360/webrev/ > > dl > From dean.long at oracle.com Tue Jun 14 23:10:33 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 14 Jun 2016 16:10:33 -0700 Subject: PING RFR(XS): 8158360: C1: SEGV in generated code In-Reply-To: <868606f3-6b0f-4d0a-cb66-0b6c37706077@oracle.com> References: <868606f3-6b0f-4d0a-cb66-0b6c37706077@oracle.com> Message-ID: <4206fbe6-df13-03e5-965e-e6d32c4b222b@oracle.com> Thanks Vladimir. dl On 6/14/16 3:24 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 6/14/16 2:36 PM, dean.long at oracle.com wrote: >> The (closed) bug 8158360 is caused by a misplaced null-check on one of >> our closed platforms, when compressed oops are involved. However, the >> failure was not showing up in nightly testing, so I am updating an >> existing test to cover this case. >> >> Tested by hand and with RBT hs-nightly-comp.js. >> >> http://cr.openjdk.java.net/~dlong/8158360/webrev/ >> >> dl >> From vladimir.kozlov at oracle.com Wed Jun 15 00:57:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jun 2016 17:57:05 -0700 Subject: RFS(XXS): 8159282: quarantine compiler/jvmci/compilerToVM/ReprofileTest.java In-Reply-To: <6ce40df6-2568-a3ce-c523-ff066939b1f4@oracle.com> References: <6ce40df6-2568-a3ce-c523-ff066939b1f4@oracle.com> Message-ID: Good. Thanks, Vladimir On 6/14/16 2:35 PM, dean.long at oracle.com wrote: > [expanded audience to include runtime] > > Quarantine this intermittently-failing test: > > diff -r e3e630ffcd86 test/compiler/jvmci/compilerToVM/ReprofileTest.java > --- a/test/compiler/jvmci/compilerToVM/ReprofileTest.java Fri Jun 10 > 02:43:53 2016 +0000 > +++ b/test/compiler/jvmci/compilerToVM/ReprofileTest.java Mon Jun 13 > 12:57:40 2016 -0700 > @@ -34,6 +34,7 @@ > * jdk.vm.ci/jdk.vm.ci.hotspot > * jdk.vm.ci/jdk.vm.ci.code > * jdk.vm.ci/jdk.vm.ci.meta > + * @ignore 8157861 > * @build jdk.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper > * @build sun.hotspot.WhiteBox > * @build compiler.jvmci.compilerToVM.ReprofileTest > > > dl > From david.holmes at oracle.com Wed Jun 15 01:37:59 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jun 2016 11:37:59 +1000 Subject: RFS(XXS): 8159282: quarantine compiler/jvmci/compilerToVM/ReprofileTest.java In-Reply-To: <6ce40df6-2568-a3ce-c523-ff066939b1f4@oracle.com> References: <6ce40df6-2568-a3ce-c523-ff066939b1f4@oracle.com> Message-ID: <231aadaf-351c-045c-0f55-316dcd46a8c5@oracle.com> On 15/06/2016 7:35 AM, dean.long at oracle.com wrote: > [expanded audience to include runtime] > > Quarantine this intermittently-failing test: > > diff -r e3e630ffcd86 test/compiler/jvmci/compilerToVM/ReprofileTest.java > --- a/test/compiler/jvmci/compilerToVM/ReprofileTest.java Fri Jun 10 > 02:43:53 2016 +0000 > +++ b/test/compiler/jvmci/compilerToVM/ReprofileTest.java Mon Jun 13 > 12:57:40 2016 -0700 > @@ -34,6 +34,7 @@ > * jdk.vm.ci/jdk.vm.ci.hotspot > * jdk.vm.ci/jdk.vm.ci.code > * jdk.vm.ci/jdk.vm.ci.meta > + * @ignore 8157861 Ok. I assume the attempt to exclude this from JPRT but keep it in nightlies got too complex? Thanks, David > * @build jdk.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper > * @build sun.hotspot.WhiteBox > * @build compiler.jvmci.compilerToVM.ReprofileTest > > > dl > From dean.long at oracle.com Wed Jun 15 03:02:00 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 14 Jun 2016 20:02:00 -0700 Subject: RFS(XXS): 8159282: quarantine compiler/jvmci/compilerToVM/ReprofileTest.java In-Reply-To: <231aadaf-351c-045c-0f55-316dcd46a8c5@oracle.com> References: <6ce40df6-2568-a3ce-c523-ff066939b1f4@oracle.com> <231aadaf-351c-045c-0f55-316dcd46a8c5@oracle.com> Message-ID: On 6/14/16 6:37 PM, David Holmes wrote: > On 15/06/2016 7:35 AM, dean.long at oracle.com wrote: >> [expanded audience to include runtime] >> >> Quarantine this intermittently-failing test: >> >> diff -r e3e630ffcd86 test/compiler/jvmci/compilerToVM/ReprofileTest.java >> --- a/test/compiler/jvmci/compilerToVM/ReprofileTest.java Fri Jun 10 >> 02:43:53 2016 +0000 >> +++ b/test/compiler/jvmci/compilerToVM/ReprofileTest.java Mon Jun 13 >> 12:57:40 2016 -0700 >> @@ -34,6 +34,7 @@ >> * jdk.vm.ci/jdk.vm.ci.hotspot >> * jdk.vm.ci/jdk.vm.ci.code >> * jdk.vm.ci/jdk.vm.ci.meta >> + * @ignore 8157861 > > Ok. I assume the attempt to exclude this from JPRT but keep it in > nightlies got too complex? > I looked at how other jtreg tests were quarantined, and this is how it was done. What I'm not clear on is whether I now need to add the "hs-comp-quarantined" label to the bug. dl > Thanks, > David > > >> * @build jdk.vm.ci/jdk.vm.ci.hotspot.CompilerToVMHelper >> * @build sun.hotspot.WhiteBox >> * @build compiler.jvmci.compilerToVM.ReprofileTest >> >> >> dl >> From rickard.backman at oracle.com Wed Jun 15 07:55:18 2016 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 15 Jun 2016 09:55:18 +0200 Subject: RFR(XXS): 8139379: Tests fail with assert(nm->insts_contains(original_pc)) failed: original PC must be in nmethod Message-ID: <20160615075518.GM22447@rbackman> Hi, can I please have reviews for this small change? Looking at core files from the asserts it seems that we called frame::verify_deopt_original_pc() from frame::adjust_unextended_sp() even though the pc is no longer at the deopt entry for the method. The deopt for C2 methods on x86-64 looks like: 0x0000 call 0x0005 0x0005 sub [esp], 5 0x000a jmp ... so when the pc is after the call the offset where the original pc is retrieved is no longer correct. For methods compiled with a JVMCI compiler the deopt_entry is also valid at entry + 5. Adding a check for this should fix the problem. Webrev: cr.openjdk.java.net/~rbackman/8139379 Bug: https://bugs.openjdk.java.net/browse/JDK-8139379 Thanks /R From markus.gronlund at oracle.com Wed Jun 15 09:01:15 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 15 Jun 2016 02:01:15 -0700 (PDT) Subject: RFR(XXS): 8139379: Tests fail with assert(nm->insts_contains(original_pc)) failed: original PC must be in nmethod In-Reply-To: <20160615075518.GM22447@rbackman> References: <20160615075518.GM22447@rbackman> Message-ID: Hi Rickard, Looks good. Markus -----Original Message----- From: Rickard B?ckman Sent: den 15 juni 2016 09:55 To: hotspot-compiler-dev at openjdk.java.net Subject: RFR(XXS): 8139379: Tests fail with assert(nm->insts_contains(original_pc)) failed: original PC must be in nmethod Hi, can I please have reviews for this small change? Looking at core files from the asserts it seems that we called frame::verify_deopt_original_pc() from frame::adjust_unextended_sp() even though the pc is no longer at the deopt entry for the method. The deopt for C2 methods on x86-64 looks like: 0x0000 call 0x0005 0x0005 sub [esp], 5 0x000a jmp ... so when the pc is after the call the offset where the original pc is retrieved is no longer correct. For methods compiled with a JVMCI compiler the deopt_entry is also valid at entry + 5. Adding a check for this should fix the problem. Webrev: cr.openjdk.java.net/~rbackman/8139379 Bug: https://bugs.openjdk.java.net/browse/JDK-8139379 Thanks /R From rickard.backman at oracle.com Wed Jun 15 09:14:56 2016 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 15 Jun 2016 11:14:56 +0200 Subject: RFR(XXS): 8139379: Tests fail with assert(nm->insts_contains(original_pc)) failed: original PC must be in nmethod In-Reply-To: References: <20160615075518.GM22447@rbackman> Message-ID: <20160615091456.GP22447@rbackman> Thank you Markus! /R On 06/15, Markus Gronlund wrote: > Hi Rickard, > > Looks good. > > Markus > > -----Original Message----- > From: Rickard B?ckman > Sent: den 15 juni 2016 09:55 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR(XXS): 8139379: Tests fail with assert(nm->insts_contains(original_pc)) failed: original PC must be in nmethod > > Hi, > > can I please have reviews for this small change? > Looking at core files from the asserts it seems that we called > frame::verify_deopt_original_pc() from frame::adjust_unextended_sp() even though the pc is no longer at the deopt entry for the method. > > The deopt for C2 methods on x86-64 looks like: > > 0x0000 call 0x0005 > 0x0005 sub [esp], 5 > 0x000a jmp ... > > so when the pc is after the call the offset where the original pc is retrieved is no longer correct. > > For methods compiled with a JVMCI compiler the deopt_entry is also valid at entry + 5. Adding a check for this should fix the problem. > > Webrev: cr.openjdk.java.net/~rbackman/8139379 > Bug: https://bugs.openjdk.java.net/browse/JDK-8139379 > > Thanks > /R From zoltan.majo at oracle.com Wed Jun 15 12:00:33 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:00:33 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <575BE438.6010904@oracle.com> Message-ID: <57614361.3020102@oracle.com> Hi Coleen, thank you for the feedback! Please see some detailed answers inline. On 06/13/2016 02:23 PM, Coleen Phillimore wrote: > > Hi Zoltan, > > On 6/11/16 6:13 AM, Zolt?n Maj? wrote: >> Hi Coleen, >> >> >> thank you for the feedback! >> >> On 06/10/2016 09:43 PM, Coleen Phillimore wrote: >>> >>> Hi, >>> >>> I'm late to the thread, which is good because it's better that this >>> check is done in the rewriter, than in InstanceKlass. >> >> I'm glad you are OK with that. > > Yes, I think this is better. We only want one bytecode iteration > during linking. At one point, we talked about not having the rewriter > but that'll never happen. >> >>> >>> But I'm fuzzy on why this wasn't checked in the verifier, and what >>> the purpose of the has_initialized_final_update (which means a non >>> method has updated a final field, which is a verify error, >>> right? >> >> I think it is a linking exception that is supposed to be thrown >> during field resolution. Please see some details below (I use >> putfield as an example). >> >> For putfield "Linking Exceptions", the JVMS-6 [1] states: >> >> "During resolution of the symbolic reference to the field, any of the >> exceptions pertaining to field resolution documented in Section >> 5.4.3.2 can be thrown. >> [...] >> Otherwise, if the field is final, it must be declared in the current >> class. Otherwise, an IllegalAccessError is thrown." >> >> With JVMS-7 [2], the second sentence has changed the following way: >> >> "Otherwise, if the field is final, it must be declared in the current >> class, and the instruction must occur in an instance initialization >> method () of the current class. Otherwise, an >> IllegalAccessError is thrown." >> >> HotSpot currently enforces JVMS-6 (i.e.,that the final field accessed >> by the putfield must be declared in the current class). That >> condition is checked in LinkResolver::resolve_field() in >> linkResolver.cpp. > > Thank you for the clarification. It looks correct. Thank you! >> >> The current patch proposes to check *also* that the instruction >> occurs in the method, as required by JVMS-7. I've added that >> check also to LinkResolver::resolve_field() (I had the feeling that >> the two checks belong together). The new check is, however, enforced >> only for class file versions >=JDK-9 (as David pointed out earlier). >> >> Regarding has_initialized_final_update: Some compiler optimizations >> assume that final fields are modified only in initializer methods. >> That assumption does always not hold (e.g., for class file versions >> > updated outside initializers; for such fields >> has_initialized_final_update() returns true. >> >> The analysis to detect "invalid" updates to final fields must be >> performed before any of a class's methods is compiled. So the >> analysis is performed at class loading and initialization. > > Ok. I didn't understand how it affected the compilers but that's > beyond the scope of my review anyway. > >> >> The current patch proposes to do the analysis in the rewriter. That >> way we don't introduce an extra iteration over all bytecodes that are >> loaded (because we piggyback on the iteration performed by the >> rewriter). So we reduce the risk of potential performance degradations. >> >>> >>> Also, have you run the JCK tests? >> >> Yes, I've run all all JCK tests executed in JPRT (the runThese8 >> target). I also did a complete pre-PIT RBT (with -Xmixed and -Xcomp) >> run. No failures have occurred. >> > > I'll send you a link to how to run the jck9 jck tests. They take a > bit longer to run. They may run with the pre-PIT RBT though, so you > might be ok. Please check that this is the case. Thank you for sending me the instructions! To be an the safe side, I've run all JCK tests (the way you've suggested), all pass. I've attached to the bug description a file containing the test output and some details on the setup I used to run the tests. > >>> >>> Why have a global flag if it's an error? >> >> David has pointed out the reasons in his reply. >> > > Ok. Makes sense. I wonder if I should have done that with > https://bugs.openjdk.java.net/browse/JDK-8145148 I'm not sure. For the current bug, it seems that we've have agreed to not have a global flag after all. For JDK-8145148, we would probably would have to think of the possible (customer) impact of the introduced changes by and decide then if such a flag is necessary. Also, the fix for JDK-8145148 was not backported to earlier releases, so maybe it's fine to have stricter checks introduced with a new major release. Thank you! Best regards, Zoltan > > > Thanks, > Coleen >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> [1] >> https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc11.html >> >> [2] >> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.putfield >>> >>> Thanks, >>> Coleen >>> >>> >>> >>> On 6/10/16 1:40 PM, Zolt?n Maj? wrote: >>>> Hi Vladimir, >>>> >>>> >>>> On 06/10/2016 06:05 PM, Vladimir Ivanov wrote: >>>>> >>>>>> Please note an additional small change in rewriter.cpp: >>>>>> >>>>>> +if (!reverse) { >>>>>> // Check if any final field of the class given as parameter is >>>>>> modified >>>>>> // outside of initializer methods of the class. Fields that are >>>>>> modified >>>>>> ... >>>>>> +} >>>>>> >>>>>> It's sufficient to check fields during rewriting (i.e., we're coming >>>>>> from Rewriter::rewrite_bytecodes()). We do not need to do the >>>>>> checks if >>>>>> the class has already been rewritten but we're reversing changes >>>>>> due to >>>>>> some failure that appeared during rewriting (in that case >>>>>> scan_method() >>>>>> is called from Rewriter::restore_bytecodes()). >>>>> >>>>> Ok. >>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/ >>>>> >>>>> Looks good. >>>>> >>>>> src/share/vm/runtime/globals.hpp >>>>> >>>>> + "for classfile version >= 51") >>>>> >>>>> s/51/53/ (no need to send new webrev). >>>> >>>> OK, I've corrected the code in-situ (in webrev.11). I also have the >>>> JPRT results now, all tests pass. >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> >>>> >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>> >>> >> > From zoltan.majo at oracle.com Wed Jun 15 12:03:34 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:03:34 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> References: <573C2DAD.1030903@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> Message-ID: <57614416.2090804@oracle.com> Hi Coleen, On 06/14/2016 04:34 PM, Coleen Phillimore wrote: > [...] > > I would vote for pre-deprecating or removing the flag. We don't > generally add flags for new spec enforcement unless we anticipate a > lot of customers having problems with the new rule. OK. > Just make sure the error message is really good though, so that when > people hit this new rule, they'll know what to fix. The change I propose tries to make the error message a bit more informative, please see the changes to linkResolver.cpp in the webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/src/share/vm/interpreter/linkResolver.cpp.sdiff.html I hope that is good enough. Thank you and best regards, Zoltan > > Coleen >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach > From zoltan.majo at oracle.com Wed Jun 15 12:07:21 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:07:21 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> Message-ID: <576144F9.9040508@oracle.com> Hi David, On 06/14/2016 11:02 PM, David Holmes wrote: > [...] >> I would vote for pre-deprecating or removing the flag. We don't >> generally add flags for new spec enforcement unless we anticipate a lot >> of customers having problems with the new rule. Just make sure the >> error message is really good though, so that when people hit this new >> rule, they'll know what to fix. > > Okay. If this is restricted to 9 then we can drop the flag and require > any "offenders" to become compliant if they plan to ship Java 9 > version bytecode. OK, I've removed the flag. Here is the newest webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.12/ Thank you! Best regards, Zoltan > > David > ----- > >> >> Coleen >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >> From coleen.phillimore at oracle.com Wed Jun 15 12:07:54 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 15 Jun 2016 08:07:54 -0400 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <57614416.2090804@oracle.com> References: <573C2DAD.1030903@oracle.com> <574FFC92.6010606@oracle.com> <57504EC5.40209@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> <57614416.2090804@oracle.com> Message-ID: <6fcf4965-af17-5fa3-409d-52a0b2e25b59@oracle.com> On 6/15/16 8:03 AM, Zolt?n Maj? wrote: > Hi Coleen, > > > On 06/14/2016 04:34 PM, Coleen Phillimore wrote: >> [...] >> >> I would vote for pre-deprecating or removing the flag. We don't >> generally add flags for new spec enforcement unless we anticipate a >> lot of customers having problems with the new rule. > > OK. > >> Just make sure the error message is really good though, so that when >> people hit this new rule, they'll know what to fix. > > The change I propose tries to make the error message a bit more > informative, please see the changes to linkResolver.cpp in the webrev: > > http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/src/share/vm/interpreter/linkResolver.cpp.sdiff.html > > > I hope that is good enough. These messages and this change looks good (looked at cdiff because sdiffs don't look right). Thanks, Coleen > > Thank you and best regards, > > > Zoltan > >> >> Coleen >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >> > From coleen.phillimore at oracle.com Wed Jun 15 12:09:17 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 15 Jun 2016 08:09:17 -0400 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <576144F9.9040508@oracle.com> References: <573C2DAD.1030903@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> <576144F9.9040508@oracle.com> Message-ID: <6e31c4dd-fa63-18df-ce30-e81980408a3e@oracle.com> Okay with this one ... Thank you for making this significant change. Coleen On 6/15/16 8:07 AM, Zolt?n Maj? wrote: > Hi David, > > > On 06/14/2016 11:02 PM, David Holmes wrote: >> [...] >>> I would vote for pre-deprecating or removing the flag. We don't >>> generally add flags for new spec enforcement unless we anticipate a lot >>> of customers having problems with the new rule. Just make sure the >>> error message is really good though, so that when people hit this new >>> rule, they'll know what to fix. >> >> Okay. If this is restricted to 9 then we can drop the flag and >> require any "offenders" to become compliant if they plan to ship Java >> 9 version bytecode. > > OK, I've removed the flag. Here is the newest webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.12/ > > Thank you! > > Best regards, > > > Zoltan > >> >> David >> ----- >> >>> >>> Coleen >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >>> > From zoltan.majo at oracle.com Wed Jun 15 12:17:58 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:17:58 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <6fcf4965-af17-5fa3-409d-52a0b2e25b59@oracle.com> References: <573C2DAD.1030903@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> <57614416.2090804@oracle.com> <6fcf4965-af17-5fa3-409d-52a0b2e25b59@oracle.com> Message-ID: <57614776.30403@oracle.com> Hi Coleen, On 06/15/2016 02:07 PM, Coleen Phillimore wrote: > > > > On 6/15/16 8:03 AM, Zolt?n Maj? wrote: >> Hi Coleen, >> >> >> On 06/14/2016 04:34 PM, Coleen Phillimore wrote: >>> [...] >>> >>> I would vote for pre-deprecating or removing the flag. We don't >>> generally add flags for new spec enforcement unless we anticipate a >>> lot of customers having problems with the new rule. >> >> OK. >> >>> Just make sure the error message is really good though, so that when >>> people hit this new rule, they'll know what to fix. >> >> The change I propose tries to make the error message a bit more >> informative, please see the changes to linkResolver.cpp in the webrev: >> >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.11/src/share/vm/interpreter/linkResolver.cpp.sdiff.html >> >> >> I hope that is good enough. > > These messages and this change looks good Thank you! > (looked at cdiff because sdiffs don't look right). Sorry, I should have sent you the cdiffs... Best regards, Zoltan > > Thanks, > Coleen >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Coleen >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >>> >> > From zoltan.majo at oracle.com Wed Jun 15 12:18:45 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:18:45 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <6e31c4dd-fa63-18df-ce30-e81980408a3e@oracle.com> References: <573C2DAD.1030903@oracle.com> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> <576144F9.9040508@oracle.com> <6e31c4dd-fa63-18df-ce30-e81980408a3e@oracle.com> Message-ID: <576147A5.5050807@oracle.com> Hi Coleen, On 06/15/2016 02:09 PM, Coleen Phillimore wrote: > > Okay with this one ... Thank you for making this significant change. thank you for the review! Best regards, Zoltan > Coleen > > > On 6/15/16 8:07 AM, Zolt?n Maj? wrote: >> Hi David, >> >> >> On 06/14/2016 11:02 PM, David Holmes wrote: >>> [...] >>>> I would vote for pre-deprecating or removing the flag. We don't >>>> generally add flags for new spec enforcement unless we anticipate a >>>> lot >>>> of customers having problems with the new rule. Just make sure the >>>> error message is really good though, so that when people hit this new >>>> rule, they'll know what to fix. >>> >>> Okay. If this is restricted to 9 then we can drop the flag and >>> require any "offenders" to become compliant if they plan to ship >>> Java 9 version bytecode. >> >> OK, I've removed the flag. Here is the newest webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.12/ >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> David >>> ----- >>> >>>> >>>> Coleen >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >>>> >> > From zoltan.majo at oracle.com Wed Jun 15 12:22:05 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Jun 2016 14:22:05 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <576144F9.9040508@oracle.com> References: <573C2DAD.1030903@oracle.com> <1805307603.1964988.1464885035124.JavaMail.zimbra@u-pem.fr> <57506343.7040409@oracle.com> <5E116F02-F3A1-4911-B367-D806EB11E441@oracle.com> <57510383.4090506@oracle.com> <57585D2A.3010906@oracle.com> <57597673.4070103@oracle.com> <6438339c-11b8-2299-c3e9-5515256a9dd6@oracle.com> <575AD3C0.8040303@oracle.com> <575ADAD8.1030907@oracle.com> <575AE26D.4010409@oracle.com> <7d20ab19-767e-83dd-db7f-176b0725cc19@oracle.com> <575AFB90.5060001@oracle.com> <334a63a7-f0e5-326d-510e-d149d9545cc5@oracle.com> <829496b7-1473-48cd-441f-b5899bbf3dc9@oracle.com> <94570f62-2276-1c94-7431-c694d0cf7043@oracle.com> <711d840a-5df1-3dbd-0a2f-c0ee64834a57@oracle.com> <4b85c1f9-8e63-9546-6c65-8208c369cb89@oracle.com> <576144F9.9040508@oracle.com> Message-ID: <5761486D.4080403@oracle.com> Thanks to everyone for the reviews/feedback/suggestions! For the record: I'll push the latest version (webrev.12) later today. Best regards, Zoltan On 06/15/2016 02:07 PM, Zolt?n Maj? wrote: > Hi David, > > > On 06/14/2016 11:02 PM, David Holmes wrote: >> [...] >>> I would vote for pre-deprecating or removing the flag. We don't >>> generally add flags for new spec enforcement unless we anticipate a lot >>> of customers having problems with the new rule. Just make sure the >>> error message is really good though, so that when people hit this new >>> rule, they'll know what to fix. >> >> Okay. If this is restricted to 9 then we can drop the flag and >> require any "offenders" to become compliant if they plan to ship Java >> 9 version bytecode. > > OK, I've removed the flag. Here is the newest webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.12/ > > Thank you! > > Best regards, > > > Zoltan > >> >> David >> ----- >> >>> >>> Coleen >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >>> > From roland.schatz at oracle.com Wed Jun 15 15:27:17 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Wed, 15 Jun 2016 17:27:17 +0200 Subject: RFR: 8159167: [JVMCI] fix HotSpotVMConfig startup performance Message-ID: Hi, Please review this change: http://cr.openjdk.java.net/~rschatz/JDK-8159167/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8159167 This gets rid of all reflection during JVMCI startup. Thanks, Roland From gilles.m.duboscq at oracle.com Wed Jun 15 15:30:10 2016 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Wed, 15 Jun 2016 17:30:10 +0200 Subject: RFR: 8159236: [JVMCI] Window-saved SPARC registers should not be considered callee-save Message-ID: <476dc0ac-cfcb-3dd6-9ab6-2e951404f325@oracle.com> Hi, Please review the following changes: Webrev: http://cr.openjdk.java.net/~gdub/webrev-8159236/ JIRA: https://bugs.openjdk.java.net/browse/JDK-8159236 As explained in jira, SPARCHotSpotRegisterConfig currently declares the window-saved registers as callee-saved registers. This causes problems if the compiler tries to emit code to save those registers. The fix is to not return those registers as callee-save. Gilles From igor.ignatyev at oracle.com Wed Jun 15 20:03:24 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 15 Jun 2016 23:03:24 +0300 Subject: RFR(XXS) : 8158754 : compilercontrol tests: RandomCommandsTest.java and RandomValidCommandsTest.java - fail in PIT Message-ID: http://cr.openjdk.java.net/~iignatyev/8158754/webrev.00/ > 1 line changed: 1 ins; 0 del; 0 mod; Hi all, could you please review this tiny fix for two compiler control tests? the tests spawn a new jvm and pass CompilerDirectivesLimit flag which is diagnostic, but don?t pass -XX:+UnlockDiagnosticVMOptions. so the tests fail on product builds. the fix simply adds -XX:+UnlockDiagnosticVMOptions. tested: locally on macos using both product and fastdebug builds JBS: https://bugs.openjdk.java.net/browse/JDK-8158754 webrev: http://cr.openjdk.java.net/~iignatyev/8158754/webrev.00/ Thanks, ? Igor From gromero at linux.vnet.ibm.com Wed Jun 15 20:16:15 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 15 Jun 2016 17:16:15 -0300 Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions In-Reply-To: References: Message-ID: <5761B78F.5010609@linux.vnet.ibm.com> Hi Volker! Thank you very much for all the help. I also confirm that the change is enough to fix the initial problem on Cassandra test suite on Linux/PPC64 LE. Just as reference I provide the Cassandra test suite log [1]. The change applies clean to jdk8u-dev and jdk8u as well. http://hg.openjdk.java.net/jdk8u/jdk8u-dev 37bd26595d99 tip http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot cf1faa9100dd tip http://hg.openjdk.java.net/jdk8u/jdk8u/ 37bd26595d99 tip http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot b857e4abb00c tip Best regards, Gustavo [1] http://pastebin.com/0Ay4yE7S On 14-06-2016 15:12, Volker Simonis wrote: > Hi, > > can I please get a review for this small change which fixes a code > generation problem on ppc64: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ > https://bugs.openjdk.java.net/browse/JDK-8158260 > > In the case where we access an unaligned address trough Unsafe, we > could generate an illegal instruction because we didn't correctly > specify the memory operand of some match rules. The fix is trivial. > > Although this change is ppc64-specific I think I need a sponsor > because the change contains a new regression test which is supposed to > run on all platforms. > > On platforms where Unsafe.unalignedAccess() will return false (e.g. > Solaris/SPARC) this test will return immediately (and I've verified > that it works). > > I've also added aarch64 to the list of recipients because on aarch64 > Unsafe.unalignedAccess() is apparently supported and it would be nice > if somebody could check that the new regression test is indeed working > there. > > @Hiroshi, Gustavo: could you please verify that this change is enough > to fix the initial problems you've observed when running Cassandra on > Linux/ppc64? The changes from ppc64.ad should easily apply to the > 8u-dev repository. Once we've got this into jdk9 I'll trigger a > downport request to get the fix into jdk8 as well. > > Thank you and best regards, > Volker > From igor.veresov at oracle.com Thu Jun 16 04:59:52 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 15 Jun 2016 21:59:52 -0700 Subject: RFR: 8159167: [JVMCI] fix HotSpotVMConfig startup performance In-Reply-To: References: Message-ID: Looks fine to me. igor > On Jun 15, 2016, at 8:27 AM, Roland Schatz wrote: > > Hi, > > Please review this change: > http://cr.openjdk.java.net/~rschatz/JDK-8159167/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8159167 > > This gets rid of all reflection during JVMCI startup. > > Thanks, > Roland > From igor.veresov at oracle.com Thu Jun 16 05:01:10 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 15 Jun 2016 22:01:10 -0700 Subject: RFR: 8159236: [JVMCI] Window-saved SPARC registers should not be considered callee-save In-Reply-To: <476dc0ac-cfcb-3dd6-9ab6-2e951404f325@oracle.com> References: <476dc0ac-cfcb-3dd6-9ab6-2e951404f325@oracle.com> Message-ID: Looks good. igor > On Jun 15, 2016, at 8:30 AM, Gilles Duboscq wrote: > > Hi, > > Please review the following changes: > > Webrev: > http://cr.openjdk.java.net/~gdub/webrev-8159236/ > JIRA: > https://bugs.openjdk.java.net/browse/JDK-8159236 > > As explained in jira, SPARCHotSpotRegisterConfig currently declares the window-saved registers as callee-saved registers. > This causes problems if the compiler tries to emit code to save those registers. > > The fix is to not return those registers as callee-save. > > Gilles From goetz.lindenmaier at sap.com Thu Jun 16 09:02:56 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 Jun 2016 09:02:56 +0000 Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions In-Reply-To: References: Message-ID: <09d3ebc7433941a0a48c82ac274a76d5@DEWDFE13DE09.global.corp.sap> Hi Volker, I've looked at the change, it's fine. Thanks for fixing this. Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Volker Simonis > Sent: Dienstag, 14. Juni 2016 20:12 > To: hotspot compiler ; ppc-aix- > port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net > Cc: Hiroshi H Horii ; Gustavo Romero > > Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the > generation of illegal instructions > > Hi, > > can I please get a review for this small change which fixes a code > generation problem on ppc64: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ > https://bugs.openjdk.java.net/browse/JDK-8158260 > > In the case where we access an unaligned address trough Unsafe, we > could generate an illegal instruction because we didn't correctly > specify the memory operand of some match rules. The fix is trivial. > > Although this change is ppc64-specific I think I need a sponsor > because the change contains a new regression test which is supposed to > run on all platforms. > > On platforms where Unsafe.unalignedAccess() will return false (e.g. > Solaris/SPARC) this test will return immediately (and I've verified > that it works). > > I've also added aarch64 to the list of recipients because on aarch64 > Unsafe.unalignedAccess() is apparently supported and it would be nice > if somebody could check that the new regression test is indeed working > there. > > @Hiroshi, Gustavo: could you please verify that this change is enough > to fix the initial problems you've observed when running Cassandra on > Linux/ppc64? The changes from ppc64.ad should easily apply to the > 8u-dev repository. Once we've got this into jdk9 I'll trigger a > downport request to get the fix into jdk8 as well. > > Thank you and best regards, > Volker From leonid.mesnik at oracle.com Thu Jun 16 10:47:32 2016 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 16 Jun 2016 13:47:32 +0300 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> Message-ID: <576283C4.4050008@oracle.com> Hi On 09.06.2016 03:43, David Holmes wrote: > Hi Leonid, > > Sorry for the delay. > > On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >> Hi >> >> Added jtreg-use at openjdk.java.net >> >> I think that you are right. Here is the documentation: >> http://openjdk.java.net/jtreg/tag-spec.html >> >> >> "@requires >> >> Express a dependence on characteristics of the system being tested. >> Some harnesses allow tests to be selected according to the >> characteristics of the system being tested. The expression may be >> composed of the following elements:" >> >> "os.arch The operating system architecture, as given by the >> corresponding system property." >> >> So user could expect to have "os.arch" of tested VM. >> >> If filed jtreg issues for this: >> >> 1. CODETOOLS-7901695 >> jtreg uses >> value 'os.arch' property of JDK which executed JDK and not of >> tested JDK >> >> >> Following fix could be used as a temporary workaround while jtreg fix is >> not ready. Does it make a sense? I this case it is needed to change >> linux-arm64 back to linux-aarch64 to minimize changes. > > I still think we have a fundamental problem concerning what os.arch > means. This workaround seems to work but I find it all very confusing. > We really need a vm.arch property, distinct from os.arch. I see that CODETOOLS-7901695 is going to be fixed. After it is implemented the 'os.arch' property will point to 'os.arch' of tested JDK as it described in jtreg documentation. However there are 64 failures in nightly are caused by failures of JVMCI tests. Does it make a sense to implement this fix as a workaround to remove noise until jtreg is fixed? Leonid > > David > ----- > > > >> Leonid >> >> On 31.05.2016 04:26, David Holmes wrote: >>> Hi Leonid, >>> >>> This really strikes me as as a jtreg problem that should be fixed in >>> jtreg. When writing an @requires clause in a test the test writer >>> should not have to be thinking "oh wait! Is this going to query the VM >>> running jtreg or the VM running the test?". It should obviously be the >>> VM running the test. >>> >>> That said we also seem to have a problem with the definition of >>> os.arch: >>> >>> os.arch Operating system architecture >>> >>> if it is returning the build architecture of the VM and not the OS it >>> is running on. That in itself argues for two distinct properties. >>> >>> David >>> >>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Could you please review following fix: >>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>> >>>> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>> >>>> for bug >>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>> >>>> >>>> The property "os.name" which was used to filter tests depends on the >>>> arch of jdk which is used to run jtreg. It might differ from arch of >>>> tested jdk. >>>> This fix introduce new property "vm.arch" which depends on the arch of >>>> tested jdk and could be used to filter tests with @requires. >>>> >>>> I verified that tests are filtered where it is expected. >>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>>> testing. >>>> >>>> Leonid >>>> >> From david.holmes at oracle.com Thu Jun 16 10:55:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jun 2016 20:55:30 +1000 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <576283C4.4050008@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> <576283C4.4050008@oracle.com> Message-ID: On 16/06/2016 8:47 PM, Leonid Mesnik wrote: > Hi > > On 09.06.2016 03:43, David Holmes wrote: >> Hi Leonid, >> >> Sorry for the delay. >> >> On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >>> Hi >>> >>> Added jtreg-use at openjdk.java.net >>> >>> I think that you are right. Here is the documentation: >>> http://openjdk.java.net/jtreg/tag-spec.html >>> >>> >>> "@requires >>> >>> Express a dependence on characteristics of the system being tested. >>> Some harnesses allow tests to be selected according to the >>> characteristics of the system being tested. The expression may be >>> composed of the following elements:" >>> >>> "os.arch The operating system architecture, as given by the >>> corresponding system property." >>> >>> So user could expect to have "os.arch" of tested VM. >>> >>> If filed jtreg issues for this: >>> >>> 1. CODETOOLS-7901695 >>> jtreg uses >>> value 'os.arch' property of JDK which executed JDK and not of >>> tested JDK >>> >>> >>> Following fix could be used as a temporary workaround while jtreg fix is >>> not ready. Does it make a sense? I this case it is needed to change >>> linux-arm64 back to linux-aarch64 to minimize changes. >> >> I still think we have a fundamental problem concerning what os.arch >> means. This workaround seems to work but I find it all very confusing. >> We really need a vm.arch property, distinct from os.arch. > I see that CODETOOLS-7901695 is going to be fixed. After it is > implemented the 'os.arch' property will point to 'os.arch' of tested JDK > as it described in jtreg documentation. > However there are 64 failures in nightly are caused by failures of JVMCI > tests. Does it make a sense to implement this fix as a workaround to > remove noise until jtreg is fixed? There may be some delay between jtreg being fixed and the updated version being put in to use. Implementing the workaround seems reasonable. Thanks, David > Leonid >> >> David >> ----- >> >> >> >>> Leonid >>> >>> On 31.05.2016 04:26, David Holmes wrote: >>>> Hi Leonid, >>>> >>>> This really strikes me as as a jtreg problem that should be fixed in >>>> jtreg. When writing an @requires clause in a test the test writer >>>> should not have to be thinking "oh wait! Is this going to query the VM >>>> running jtreg or the VM running the test?". It should obviously be the >>>> VM running the test. >>>> >>>> That said we also seem to have a problem with the definition of >>>> os.arch: >>>> >>>> os.arch Operating system architecture >>>> >>>> if it is returning the build architecture of the VM and not the OS it >>>> is running on. That in itself argues for two distinct properties. >>>> >>>> David >>>> >>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> Could you please review following fix: >>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>>> >>>>> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>>> >>>>> for bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>>> >>>>> >>>>> The property "os.name" which was used to filter tests depends on the >>>>> arch of jdk which is used to run jtreg. It might differ from arch of >>>>> tested jdk. >>>>> This fix introduce new property "vm.arch" which depends on the arch of >>>>> tested jdk and could be used to filter tests with @requires. >>>>> >>>>> I verified that tests are filtered where it is expected. >>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>>>> testing. >>>>> >>>>> Leonid >>>>> >>> > From adinn at redhat.com Thu Jun 16 11:08:31 2016 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 16 Jun 2016 12:08:31 +0100 Subject: [aarch64-port-dev ] RFR: 8159063: aarch64: optimise unaligned array copy long In-Reply-To: <57583B81.5020008@redhat.com> References: <1465399545.18136.11.camel@mylittlepony.linaroharston> <57583B81.5020008@redhat.com> Message-ID: <576288AF.1030609@redhat.com> On 08/06/16 16:36, Andrew Haley wrote: > On 08/06/16 16:25, Edward Nevill wrote: >> http://cr.openjdk.java.net/~enevill/8159063/arraycopy.pdf >> >> OK to push to jdk8u now (and later to jdk9)? > > Hmm. This looks a bit risky. I'm prepared to approve it for jdk9, > but jdk8 is production code. So no, please don't push it. Andrew asked me also to review this for jdk9. I think it is ok as is but I would prefer to push it with more comments to explain what it is doing. Also, I think it is much clearer if the last 2 word copy is done using the same model as for the 8 and 4 word copies rather than mimicking the code in the aligned case. I find the use of the adjust method with boolean arg supplied by the repeated expression direction == copy_backwards particularly opaque. After my sig is a revised version of your patch which addresses both these issues. I have tested it on my Mustang hw using your supplied test code and it succeeds and with the same results as your original patch whether I pass -XX:+AvoidUnalignedAccesses or -XX:-AvoidUnalignedAccesses on the command line. I don't have access to any other hw to test it on. Could you and Andrew try out and review this revised patch. If it is ok then I think this would be better to push this to jdk9. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- # HG changeset patch # User enevill # Date 1466073728 14400 # Thu Jun 16 06:42:08 2016 -0400 # Node ID 9570d342c207e43ce262a9466eb862e68e790c54 # Parent 385eae4265489a6b9f92b6cc6ab37467c8454563 8159063: aarch64: optimise unaligned array copy long Reviewed-by: aph, adinn diff -r 385eae426548 -r 9570d342c207 src/cpu/aarch64/vm/globals_aarch64.hpp --- a/src/cpu/aarch64/vm/globals_aarch64.hpp Wed Jun 15 12:44:20 2016 +0200 +++ b/src/cpu/aarch64/vm/globals_aarch64.hpp Thu Jun 16 06:42:08 2016 -0400 @@ -118,6 +118,7 @@ // Don't attempt to use Neon on builtin sim until builtin sim supports it #define UseCRC32 false #define UseSIMDForMemoryOps false +#define AvoidUnalignedAcesses false #else #define UseBuiltinSim false @@ -144,6 +145,8 @@ "Use CRC32 instructions for CRC32 computation") \ product(bool, UseSIMDForMemoryOps, false, \ "Use SIMD instructions in generated memory move code") \ + product(bool, AvoidUnalignedAccesses, false, \ + "Avoid generating unaligned memory accesses") \ product(bool, UseLSE, false, \ "Use LSE instructions") \ product(bool, UseBlockZeroing, true, \ diff -r 385eae426548 -r 9570d342c207 src/cpu/aarch64/vm/stubGenerator_aarch64.cpp --- a/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Wed Jun 15 12:44:20 2016 +0200 +++ b/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Thu Jun 16 06:42:08 2016 -0400 @@ -801,6 +801,12 @@ StubCodeMark mark(this, "StubRoutines", stub_name); __ align(CodeEntryAlignment); __ bind(start); + + Label unaligned_copy_long; + if (AvoidUnalignedAccesses) { + __ tbnz(d, 3, unaligned_copy_long); + } + if (direction == copy_forwards) { __ sub(s, s, bias); __ sub(d, d, bias); @@ -901,6 +907,198 @@ } __ ret(lr); + + if (AvoidUnalignedAccesses) { + Label drain, again; + // Register order for storing. Order is different for backward copy. + + __ bind(unaligned_copy_long); + + // source address is even aligned, target odd aligned + // + // when forward copying word pairs we read long pairs at offsets + // {0, 2, 4, 6} (in long words). when backwards copying we read + // long pairs at offsets {-2, -4, -6, -8}. We adjust the source + // address by -2 in the forwards case so we can compute the + // source offsets for both as {2, 4, 6, 8} * unit where unit = 1 + // or -1. + // + // when forward copying we need to store 1 word, 3 pairs and + // then 1 word at offsets {0, 1, 3, 5, 7}. Rather thna use a + // zero offset We adjust the destination by -1 which means we + // have to use offsets { 1, 2, 4, 6, 8} * unit for the stores. + // + // When backwards copyng we need to store 1 word, 3 pairs and + // then 1 word at offsets {-1, -3, -5, -7, -8} i.e. we use + // offsets {1, 3, 5, 7, 8} * unit. + + if (direction == copy_forwards) { + __ sub(s, s, 16); + __ sub(d, d, 8); + } + + // Fill 8 registers + // + // for forwards copy s was offset by -16 from the original input + // value of s so the register contents are at these offsets + // relative to the 64 bit block addressed by that original input + // and so on for each successive 64 byte block when s is updated + // + // t0 at offset 0, t1 at offset 8 + // t2 at offset 16, t3 at offset 24 + // t4 at offset 32, t5 at offset 40 + // t6 at offset 48, t7 at offset 56 + + // for backwards copy s was not offset so the register contents + // are at these offsets into the preceding 64 byte block + // relative to that original input and so on for each successive + // preceding 64 byte block when s is updated. this explains the + // slightly counter-intuitive looking pattern of register usage + // in the stp instructions for backwards copy. + // + // t0 at offset -16, t1 at offset -8 + // t2 at offset -32, t3 at offset -24 + // t4 at offset -48, t5 at offset -40 + // t6 at offset -64, t7 at offset -56 + + __ ldp(t0, t1, Address(s, 2 * unit)); + __ ldp(t2, t3, Address(s, 4 * unit)); + __ ldp(t4, t5, Address(s, 6 * unit)); + __ ldp(t6, t7, Address(__ pre(s, 8 * unit))); + + __ subs(count, count, 16); + __ br(Assembler::LO, drain); + + int prefetch = PrefetchCopyIntervalInBytes; + bool use_stride = false; + if (direction == copy_backwards) { + use_stride = prefetch > 256; + prefetch = -prefetch; + if (use_stride) __ mov(stride, prefetch); + } + + __ bind(again); + + if (PrefetchCopyIntervalInBytes > 0) + __ prfm(use_stride ? Address(s, stride) : Address(s, prefetch), PLDL1KEEP); + + if (direction == copy_forwards) { + // allowing for the offset of -8 the store instructions place + // registers into the target 64 bit block at the following + // offsets + // + // t0 at offset 0 + // t1 at offset 8, t2 at offset 16 + // t3 at offset 24, t4 at offset 32 + // t5 at offset 40, t6 at offset 48 + // t7 at offset 56 + + __ str(t0, Address(d, 1 * unit)); + __ stp(t1, t2, Address(d, 2 * unit)); + __ ldp(t0, t1, Address(s, 2 * unit)); + __ stp(t3, t4, Address(d, 4 * unit)); + __ ldp(t2, t3, Address(s, 4 * unit)); + __ stp(t5, t6, Address(d, 6 * unit)); + __ ldp(t4, t5, Address(s, 6 * unit)); + __ str(t7, Address(__ pre(d, 8 * unit))); + __ ldp(t6, t7, Address(__ pre(s, 8 * unit))); + } else { + // d was not offset when we started so the registers are + // written into the 64 bit block preceding d with the following + // offsets + // + // t1 at offset -8 + // t3 at offset -24, t0 at offset -16 + // t5 at offset -48, t2 at offset -32 + // t7 at offset -56, t4 at offset -48 + // t6 at offset -64 + // + // note that this matches the offsets previously noted for the + // loads + + __ str(t1, Address(d, 1 * unit)); + __ stp(t3, t0, Address(d, 3 * unit)); + __ ldp(t0, t1, Address(s, 2 * unit)); + __ stp(t5, t2, Address(d, 5 * unit)); + __ ldp(t2, t3, Address(s, 4 * unit)); + __ stp(t7, t4, Address(d, 7 * unit)); + __ ldp(t4, t5, Address(s, 6 * unit)); + __ str(t6, Address(__ pre(d, 8 * unit))); + __ ldp(t6, t7, Address(__ pre(s, 8 * unit))); + } + + __ subs(count, count, 8); + __ br(Assembler::HS, again); + + // Drain + // + // this uses the same pattern of offsets and register arguments + // as above + __ bind(drain); + if (direction == copy_forwards) { + __ str(t0, Address(d, 1 * unit)); + __ stp(t1, t2, Address(d, 2 * unit)); + __ stp(t3, t4, Address(d, 4 * unit)); + __ stp(t5, t6, Address(d, 6 * unit)); + __ str(t7, Address(__ pre(d, 8 * unit))); + } else { + __ str(t1, Address(d, 1 * unit)); + __ stp(t3, t0, Address(d, 3 * unit)); + __ stp(t5, t2, Address(d, 5 * unit)); + __ stp(t7, t4, Address(d, 7 * unit)); + __ str(t6, Address(__ pre(d, 8 * unit))); + } + // now we need to copy any remaining part block which may + // include a 4 word block subblock and/or a 2 word subblock. + // bits 2 and 1 in the count are the tell-tale for whetehr we + // have each such subblock + { + Label L1, L2; + __ tbz(count, exact_log2(4), L1); + // this is the same as above but copying only 4 longs hence + // with ony one intervening stp between the str instructions + // but note that the offsets and registers still follow the + // same pattern + __ ldp(t0, t1, Address(s, 2 * unit)); + __ ldp(t2, t3, Address(__ pre(s, 4 * unit))); + if (direction == copy_forwards) { + __ str(t0, Address(d, 1 * unit)); + __ stp(t1, t2, Address(d, 2 * unit)); + __ str(t3, Address(__ pre(d, 4 * unit))); + } else { + __ str(t1, Address(d, 1 * unit)); + __ stp(t3, t0, Address(d, 3 * unit)); + __ str(t2, Address(__ pre(d, 4 * unit))); + } + __ bind(L1); + + __ tbz(count, 1, L2); + // this is the same as above but copying only 2 longs hence + // there is no intervening stp between the str instructions + // but note that the offset and register patterns are still + // the same + __ ldp(t0, t1, Address(__ pre(s, 2 * unit))); + if (direction == copy_forwards) { + __ str(t0, Address(d, 1 * unit)); + __ str(t1, Address(__ pre(d, 2 * unit))); + } else { + __ str(t1, Address(d, 1 * unit)); + __ str(t0, Address(__ pre(d, 2 * unit))); + } + __ bind(L2); + + // for forwards copy we need to re-adjust the offsets we + // applied so that s and d are follow the last words written + + if (direction == copy_forwards) { + __ add(s, s, 16); + __ add(d, d, 8); + } + + } + + __ ret(lr); + } } // Small copy: less than 16 bytes. @@ -1024,11 +1222,9 @@ // (96 bytes if SIMD because we do 32 byes per instruction) __ bind(copy80); if (UseSIMDForMemoryOps) { - __ ldpq(v0, v1, Address(s, 0)); - __ ldpq(v2, v3, Address(s, 32)); + __ ld4(v0, v1, v2, v3, __ T16B, Address(s, 0)); __ ldpq(v4, v5, Address(send, -32)); - __ stpq(v0, v1, Address(d, 0)); - __ stpq(v2, v3, Address(d, 32)); + __ st4(v0, v1, v2, v3, __ T16B, Address(d, 0)); __ stpq(v4, v5, Address(dend, -32)); } else { __ ldp(t0, t1, Address(s, 0)); diff -r 385eae426548 -r 9570d342c207 src/cpu/aarch64/vm/vm_version_aarch64.cpp --- a/src/cpu/aarch64/vm/vm_version_aarch64.cpp Wed Jun 15 12:44:20 2016 +0200 +++ b/src/cpu/aarch64/vm/vm_version_aarch64.cpp Thu Jun 16 06:42:08 2016 -0400 @@ -175,7 +175,15 @@ } // Enable vendor specific features - if (_cpu == CPU_CAVIUM && _variant == 0) _features |= CPU_DMB_ATOMICS; + if (_cpu == CPU_CAVIUM) { + if (_variant == 0) _features |= CPU_DMB_ATOMICS; + if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { + FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); + } + if (FLAG_IS_DEFAULT(UseSIMDForMemoryOps)) { + FLAG_SET_DEFAULT(UseSIMDForMemoryOps, (_variant > 0)); + } + } if (_cpu == CPU_ARM && (_model == 0xd03 || _model2 == 0xd03)) _features |= CPU_A53MAC; if (_cpu == CPU_ARM && (_model == 0xd07 || _model2 == 0xd07)) _features |= CPU_STXR_PREFETCH; // If an olde style /proc/cpuinfo (cpu_lines == 1) then if _model is an A57 (0xd07) ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- From nils.eliasson at oracle.com Thu Jun 16 11:19:08 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 16 Jun 2016 13:19:08 +0200 Subject: RFR(XXS) : 8158754 : compilercontrol tests: RandomCommandsTest.java and RandomValidCommandsTest.java - fail in PIT In-Reply-To: References: Message-ID: <57628B2C.4090302@oracle.com> Hi, Looks good! Regards, Nils On 2016-06-15 22:03, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8158754/webrev.00/ >> 1 line changed: 1 ins; 0 del; 0 mod; > Hi all, > > could you please review this tiny fix for two compiler control tests? the tests spawn a new jvm and pass CompilerDirectivesLimit flag which is diagnostic, but don?t pass -XX:+UnlockDiagnosticVMOptions. so the tests fail on product builds. the fix simply adds -XX:+UnlockDiagnosticVMOptions. > > tested: locally on macos using both product and fastdebug builds > JBS: https://bugs.openjdk.java.net/browse/JDK-8158754 > webrev: http://cr.openjdk.java.net/~iignatyev/8158754/webrev.00/ > > Thanks, > ? Igor > > From stefan.anzinger at oracle.com Thu Jun 16 11:54:17 2016 From: stefan.anzinger at oracle.com (Stefan Anzinger) Date: Thu, 16 Jun 2016 13:54:17 +0200 Subject: RFR(S): 8159368: [JVMCI] SPARCHotSpotRegisterConfig.callingConvention gives incorrect calling convention for native calls containing fp args Message-ID: <57629369.4050001@oracle.com> Hello, we found a bug in the JVMCI defined SPARC calling convention when calling native methods with single float arguments. Previously the HotSpot Calling Convention was used, which is different to the one defined in the native ABI [1]. This fix implements the correct native calling convention in the SPARC ABI [1] in SPARCHotSpotRegisterConfig.java. The rest of the change is a jtreg test which exercises native calls on AMD64 and SPARC with code installed via JVMCI. Different parameter types and argument counts are tested. https://bugs.openjdk.java.net/browse/JDK-8159368 http://cr.openjdk.java.net/~sanzinger/8159368/webrev.01/ Reference: [1] http://sparc.org/wp-content/uploads/2014/01/SCD.2.4.1.pdf.gz Stefan From leonid.mesnik at oracle.com Thu Jun 16 12:34:33 2016 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 16 Jun 2016 15:34:33 +0300 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> <576283C4.4050008@oracle.com> Message-ID: <57629CD9.40609@oracle.com> Hi I've updated fix The vm.simpleArch variable has been added which corresponds to os.simpleArch of tested platform. All hotspot tests have been updated to use vm.simpleArch instead of os.simpleArch. Once jtreg is fixed to read 'os.arch' from tested JDK then it would be possible just revert this fix and preserver same behavior (See CODETOOLS-7901695 ) . Updated webrev: http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/ http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/ Testing is still in progress. Leonid On 16.06.2016 13:55, David Holmes wrote: > On 16/06/2016 8:47 PM, Leonid Mesnik wrote: >> Hi >> >> On 09.06.2016 03:43, David Holmes wrote: >>> Hi Leonid, >>> >>> Sorry for the delay. >>> >>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Added jtreg-use at openjdk.java.net >>>> >>>> I think that you are right. Here is the documentation: >>>> http://openjdk.java.net/jtreg/tag-spec.html >>>> >>>> >>>> "@requires >>>> >>>> Express a dependence on characteristics of the system being >>>> tested. >>>> Some harnesses allow tests to be selected according to the >>>> characteristics of the system being tested. The expression may be >>>> composed of the following elements:" >>>> >>>> "os.arch The operating system architecture, as given by the >>>> corresponding system property." >>>> >>>> So user could expect to have "os.arch" of tested VM. >>>> >>>> If filed jtreg issues for this: >>>> >>>> 1. CODETOOLS-7901695 >>>> jtreg uses >>>> value 'os.arch' property of JDK which executed JDK and not of >>>> tested JDK >>>> >>>> >>>> Following fix could be used as a temporary workaround while jtreg >>>> fix is >>>> not ready. Does it make a sense? I this case it is needed to change >>>> linux-arm64 back to linux-aarch64 to minimize changes. >>> >>> I still think we have a fundamental problem concerning what os.arch >>> means. This workaround seems to work but I find it all very confusing. >>> We really need a vm.arch property, distinct from os.arch. >> I see that CODETOOLS-7901695 is going to be fixed. After it is >> implemented the 'os.arch' property will point to 'os.arch' of tested JDK >> as it described in jtreg documentation. >> However there are 64 failures in nightly are caused by failures of JVMCI >> tests. Does it make a sense to implement this fix as a workaround to >> remove noise until jtreg is fixed? > > There may be some delay between jtreg being fixed and the updated > version being put in to use. > > Implementing the workaround seems reasonable. > > Thanks, > David > >> Leonid >>> >>> David >>> ----- >>> >>> >>> >>>> Leonid >>>> >>>> On 31.05.2016 04:26, David Holmes wrote: >>>>> Hi Leonid, >>>>> >>>>> This really strikes me as as a jtreg problem that should be fixed in >>>>> jtreg. When writing an @requires clause in a test the test writer >>>>> should not have to be thinking "oh wait! Is this going to query >>>>> the VM >>>>> running jtreg or the VM running the test?". It should obviously be >>>>> the >>>>> VM running the test. >>>>> >>>>> That said we also seem to have a problem with the definition of >>>>> os.arch: >>>>> >>>>> os.arch Operating system architecture >>>>> >>>>> if it is returning the build architecture of the VM and not the OS it >>>>> is running on. That in itself argues for two distinct properties. >>>>> >>>>> David >>>>> >>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> Could you please review following fix: >>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>>>> >>>>>> hotspot >>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>>>> >>>>>> for bug >>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>>>> >>>>>> >>>>>> The property "os.name" which was used to filter tests depends on the >>>>>> arch of jdk which is used to run jtreg. It might differ from arch of >>>>>> tested jdk. >>>>>> This fix introduce new property "vm.arch" which depends on the >>>>>> arch of >>>>>> tested jdk and could be used to filter tests with @requires. >>>>>> >>>>>> I verified that tests are filtered where it is expected. >>>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>>>>> testing. >>>>>> >>>>>> Leonid >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Thu Jun 16 13:27:15 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 16 Jun 2016 16:27:15 +0300 Subject: RFR(XS) : 8159149 : Several compiler tests fail with minimal VM Message-ID: http://cr.openjdk.java.net/~iignatyev/8159149/webrev.00/ > 70 lines changed: 4 ins; 1 del; 65 mod; Hi all, could you please review the fix for a couple of compiler tests to make it possible to run them on minimal VM or exclude them if they are not applicable? minimal VM doesn?t have several features such as jcmd, instrumentation agents and support only which is in java.compact2 module. - compiler/c2/8004867/TestIntUnsafeOrdered.java and compiler/codegen/8011901/Test8011901.java used sun.misc.Unsafe which is in jdk.unsupported module which is not in java.compact2 set, they tests were rewritten to use jdk.internal.misc.Unsafe instead. - compiler/jsr292/NonInlinedCall/RedefineTest.java uses instrumentation agent, compiler/compilercontrol/jcmd/PrintDirectivesTest.java uses jcmd, these features are not supported in minimal VM, the corresponding @requiers was added to exclude the tests - compiler/compilercontrol/mixed/RandomValidCommandsTest.java and compiler/compilercontrol/logcompilation/LogTest.java have indirect dependency on java.management module. this dependency is in driver code, not in test code, so converting ?@run main? to '@run driver? makes it possible to run these tests on minimal VM. PS there is a plan to get rid of this dependency JBS: https://bugs.openjdk.java.net/browse/JDK-8159149 webrev: http://cr.openjdk.java.net/~iignatyev/8159149/webrev.00/ testing: locally on macos w/ and w/o ?-limitmods java.compact2? and remotely on linux-x86 w/ ?-minimal -limitmods java.compact2' Thanks, ? Igor From tobias.hartmann at oracle.com Thu Jun 16 13:41:17 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 Jun 2016 15:41:17 +0200 Subject: [9] RFR(S): 8159715: Fix for 8072422 is incorrect Message-ID: <5762AC7D.60902@oracle.com> Hi, please review the following fix: https://bugs.openjdk.java.net/browse/JDK-8159715 http://cr.openjdk.java.net/~thartmann/8159715/webrev.00/ The fix for JDK-8072422 [1] removed the RangeLimitCheck flag that was set to true by default. In PhaseIdealLoop::do_range_check(), conditional_rc should now be always set to true. The LoopLimitCheck flag was also removed but the code in parse1.cpp and loopnode.cpp was not adapted correctly (see bug description). Tested with JPRT and RBT (running). Thanks, Tobias [1] http://cr.openjdk.java.net/~zmajo/8072422/webrev.02/ From dmitrij.pochepko at oracle.com Thu Jun 16 13:45:23 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 16 Jun 2016 16:45:23 +0300 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <57629CD9.40609@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> <576283C4.4050008@oracle.com> <57629CD9.40609@oracle.com> Message-ID: <5762AD73.9030506@oracle.com> Leonid, thank you for taking care of this issue. Looks good to me(not a reviewer). Thanks, Dmitrij > Hi > > I've updated fix > > The vm.simpleArch variable has been added which corresponds to > os.simpleArch of tested platform. All hotspot tests have been updated > to use vm.simpleArch instead of os.simpleArch. Once jtreg is fixed to > read 'os.arch' from tested JDK then it would be possible just revert > this fix and preserver same behavior (See CODETOOLS-7901695 > ) . > > Updated webrev: > http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/ > http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/ > > Testing is still in progress. > > Leonid > > On 16.06.2016 13:55, David Holmes wrote: >> On 16/06/2016 8:47 PM, Leonid Mesnik wrote: >>> Hi >>> >>> On 09.06.2016 03:43, David Holmes wrote: >>>> Hi Leonid, >>>> >>>> Sorry for the delay. >>>> >>>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> Added jtreg-use at openjdk.java.net >>>>> >>>>> I think that you are right. Here is the documentation: >>>>> http://openjdk.java.net/jtreg/tag-spec.html >>>>> >>>>> >>>>> "@requires >>>>> >>>>> Express a dependence on characteristics of the system being >>>>> tested. >>>>> Some harnesses allow tests to be selected according to the >>>>> characteristics of the system being tested. The expression may be >>>>> composed of the following elements:" >>>>> >>>>> "os.arch The operating system architecture, as given by the >>>>> corresponding system property." >>>>> >>>>> So user could expect to have "os.arch" of tested VM. >>>>> >>>>> If filed jtreg issues for this: >>>>> >>>>> 1. CODETOOLS-7901695 >>>>> jtreg uses >>>>> value 'os.arch' property of JDK which executed JDK and not of >>>>> tested JDK >>>>> >>>>> >>>>> Following fix could be used as a temporary workaround while jtreg >>>>> fix is >>>>> not ready. Does it make a sense? I this case it is needed to change >>>>> linux-arm64 back to linux-aarch64 to minimize changes. >>>> >>>> I still think we have a fundamental problem concerning what os.arch >>>> means. This workaround seems to work but I find it all very confusing. >>>> We really need a vm.arch property, distinct from os.arch. >>> I see that CODETOOLS-7901695 is going to be fixed. After it is >>> implemented the 'os.arch' property will point to 'os.arch' of tested >>> JDK >>> as it described in jtreg documentation. >>> However there are 64 failures in nightly are caused by failures of >>> JVMCI >>> tests. Does it make a sense to implement this fix as a workaround to >>> remove noise until jtreg is fixed? >> >> There may be some delay between jtreg being fixed and the updated >> version being put in to use. >> >> Implementing the workaround seems reasonable. >> >> Thanks, >> David >> >>> Leonid >>>> >>>> David >>>> ----- >>>> >>>> >>>> >>>>> Leonid >>>>> >>>>> On 31.05.2016 04:26, David Holmes wrote: >>>>>> Hi Leonid, >>>>>> >>>>>> This really strikes me as as a jtreg problem that should be fixed in >>>>>> jtreg. When writing an @requires clause in a test the test writer >>>>>> should not have to be thinking "oh wait! Is this going to query >>>>>> the VM >>>>>> running jtreg or the VM running the test?". It should obviously >>>>>> be the >>>>>> VM running the test. >>>>>> >>>>>> That said we also seem to have a problem with the definition of >>>>>> os.arch: >>>>>> >>>>>> os.arch Operating system architecture >>>>>> >>>>>> if it is returning the build architecture of the VM and not the >>>>>> OS it >>>>>> is running on. That in itself argues for two distinct properties. >>>>>> >>>>>> David >>>>>> >>>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>>>>> Hi >>>>>>> >>>>>>> Could you please review following fix: >>>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>>>>> >>>>>>> hotspot >>>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>>>>> >>>>>>> for bug >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>>>>> >>>>>>> >>>>>>> The property "os.name" which was used to filter tests depends on >>>>>>> the >>>>>>> arch of jdk which is used to run jtreg. It might differ from >>>>>>> arch of >>>>>>> tested jdk. >>>>>>> This fix introduce new property "vm.arch" which depends on the >>>>>>> arch of >>>>>>> tested jdk and could be used to filter tests with @requires. >>>>>>> >>>>>>> I verified that tests are filtered where it is expected. >>>>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>>>>>> testing. >>>>>>> >>>>>>> Leonid >>>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Thu Jun 16 13:50:28 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 16 Jun 2016 15:50:28 +0200 Subject: [9] RFR(S): 8159715: Fix for 8072422 is incorrect In-Reply-To: <5762AC7D.60902@oracle.com> References: <5762AC7D.60902@oracle.com> Message-ID: <5762AEA4.4050000@oracle.com> Hi Tobias, On 06/16/2016 03:41 PM, Tobias Hartmann wrote: > Hi, > > please review the following fix: > > https://bugs.openjdk.java.net/browse/JDK-8159715 > http://cr.openjdk.java.net/~thartmann/8159715/webrev.00/ thank you for catching those errors and for fixing them! The fix looks good to me. Best regards, Zoltan > > The fix for JDK-8072422 [1] removed the RangeLimitCheck flag that was set to true by default. In PhaseIdealLoop::do_range_check(), conditional_rc should now be always set to true. The LoopLimitCheck flag was also removed but the code in parse1.cpp and loopnode.cpp was not adapted correctly (see bug description). > > Tested with JPRT and RBT (running). > > Thanks, > Tobias > > [1] http://cr.openjdk.java.net/~zmajo/8072422/webrev.02/ From tobias.hartmann at oracle.com Thu Jun 16 14:00:53 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 Jun 2016 16:00:53 +0200 Subject: [9] RFR(S): 8159715: Fix for 8072422 is incorrect In-Reply-To: <5762AEA4.4050000@oracle.com> References: <5762AC7D.60902@oracle.com> <5762AEA4.4050000@oracle.com> Message-ID: <5762B115.6090900@oracle.com> Hi Zoltan, thanks for the review! Best regards, Tobias On 16.06.2016 15:50, Zolt?n Maj? wrote: > Hi Tobias, > > > On 06/16/2016 03:41 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following fix: >> >> https://bugs.openjdk.java.net/browse/JDK-8159715 >> http://cr.openjdk.java.net/~thartmann/8159715/webrev.00/ > > thank you for catching those errors and for fixing them! The fix looks good to me. > > Best regards, > > > Zoltan > >> >> The fix for JDK-8072422 [1] removed the RangeLimitCheck flag that was set to true by default. In PhaseIdealLoop::do_range_check(), conditional_rc should now be always set to true. The LoopLimitCheck flag was also removed but the code in parse1.cpp and loopnode.cpp was not adapted correctly (see bug description). >> >> Tested with JPRT and RBT (running). >> >> Thanks, >> Tobias >> >> [1] http://cr.openjdk.java.net/~zmajo/8072422/webrev.02/ > From xiang.yuan at linaro.org Thu Jun 16 14:54:09 2016 From: xiang.yuan at linaro.org (Xiang Yuan) Date: Thu, 16 Jun 2016 22:54:09 +0800 Subject: Fwd: A bug in C1 intrinsic arraycopy In-Reply-To: References: Message-ID: Hi all, We find a bug in hotspot C1 intrinsic arraycopy, and it is reported at https://bugs.openjdk.java.net/browse/JDK-8159431. This report includes test case, test result and patch. We have triggered it with AArch64 and x86 slowdebug & fastdebug JDK. We didn't test it on Sparc, however from the codes, it may have the same issue. *****Testcase Begin***** public class TestArrayCopy { public static void main(String args[]) { System.out.println("TestArrayCopy"); Object aArray[] = new Object[10]; for (int i = 0; i < 10; i++) { aArray[i] = new Object(); } new TestArrayCopy().test(aArray); } public void test(Object aArray[]) { Object a = new Object(); try { System.arraycopy(aArray, 0, a, 0, 1); throw new RuntimeException ("Test dst is not array failed!"); } catch (ArrayStoreException e) {} } } *****Testcase End***** To trigger this bug easier, run it with a fastdebug or slowdebug JDK. Command line: java -XX:TieredStopAtLevel=1 -XX:-UseCompressedClassPointers -Xcomp -XX:CompileOnly=TestArrayCopy.test,System.arraycopy TestArrayCopy Expected Result: TestArrayCopy Actual Result: TestArrayCopy Exception in thread "main" java.lang.RuntimeException: Test dst is not array failed! at TestArrayCopy.test(TestArrayCopy.java:18) at TestArrayCopy.main(TestArrayCopy.java:10) The cause of this bug is that in LIR_Assembler::emit_arraycopy, when the type check of dst or src is needed, it uses the following steps to do arraycopy: 1. check class of src and dst, if class_src is a sub-class of class_dst, GOTO 4. Type check includes: (1) MacroAssembler::check_klass_subtype_fast_path (2) Runtime1::slow_subtype_check 2. check whether src and dst are both object arrays. 3. ...... 4. do arraycopy. However, in the above test case, the src is an array of Object and the dst is an Object. And Object array is a sub-class of Object, and the check in Step 1 - (1) is passed. Then the arraycopy is done. This means the first element in src is copied into the dst, which is a object of class Object, not an object array. The option -XX:-UseCompressedClassPointers is necessary. With this option, when a new object ( not a array ) is created, C1_MacroAssembler::initialize_header will call store_klass_gap() to set 0 to the place where stores the length of an array. And before the above 4 steps in LIR_Assembler::emit_arraycopy, it will check whether the length of src or dst is large enough. Therefore, length 0 will cause this check fail, and arraycopy will not be done. Without this option, the memory location in an object (not array) which stores the length in an array is uninitialized which causes the bug is easier to be triggered in debug mode. The following patch can fix it in aarch64 ( which is also included in the bug report), and other platforms can fix it with similar patches. ******** Patch Begin ********* diff -r c0b5ea3442e1 src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Fri Jun 03 17:45:03 2016 -0400 +++ b/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Mon Jun 06 11:32:02 2016 +0800 @@ -2315,6 +2315,14 @@ __ load_klass(src, src); __ load_klass(dst, dst); + if (!(flags & LIR_OpArrayCopy::dst_objarray)) { + assert(SystemDictionary::Object_klass_loaded(), "check needed"); + Klass * obj_klass = SystemDictionary::well_known_klass(SystemDictionary::Object_klass_knum); + __ mov(tmp, (u_int64_t)obj_klass); + __ cmp(dst, tmp); + __ br(Assembler::EQ, slow); + } + __ check_klass_subtype_fast_path(src, dst, tmp, &cont, &slow, NULL); __ PUSH(src, dst); ******** Patch End ******** This patch checks whether dst's klass is Object. If so, goes to check whether dst is an object array. This check in the patch is a little late, that is after the length check of src and dst. This may make the check in the patch is not necessarily correct. For without the argument -XX:-UseCompressedClassPointers, the ? length? of an object ( not array ) is uninitialized. Set 0 to the ?length? of an object causes an extra store in each new operation. And we haven?t found a better solution. Thanks a lot! Best Wishes! Xiang Yuan 2016.06.16 -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Thu Jun 16 15:03:30 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 16 Jun 2016 08:03:30 -0700 Subject: RFR(S): 8159368: [JVMCI] SPARCHotSpotRegisterConfig.callingConvention gives incorrect calling convention for native calls containing fp args In-Reply-To: <57629369.4050001@oracle.com> References: <57629369.4050001@oracle.com> Message-ID: The .c file probably needs a copyright header. Otherwise looks good. igor > On Jun 16, 2016, at 4:54 AM, Stefan Anzinger wrote: > > Hello, > > we found a bug in the JVMCI defined SPARC calling convention when > calling native methods with single float arguments. Previously the > HotSpot Calling Convention was used, which is different to the one > defined in the native ABI [1]. > > This fix implements the correct native calling convention in the SPARC > ABI [1] in SPARCHotSpotRegisterConfig.java. > > The rest of the change is a jtreg test which exercises native calls on > AMD64 and SPARC with code installed via JVMCI. Different parameter types > and argument counts are tested. > > https://bugs.openjdk.java.net/browse/JDK-8159368 > http://cr.openjdk.java.net/~sanzinger/8159368/webrev.01/ > > Reference: > [1] http://sparc.org/wp-content/uploads/2014/01/SCD.2.4.1.pdf.gz > > Stefan From leonid.mesnik at oracle.com Thu Jun 16 15:09:36 2016 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 16 Jun 2016 18:09:36 +0300 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <5762AD73.9030506@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> <576283C4.4050008@oracle.com> <57629CD9.40609@oracle.com> <5762AD73.9030506@oracle.com> Message-ID: <5762C130.5030607@oracle.com> Thanks for reviewing. The testing finished successfully. Still waiting for more reviews. Leonid On 16.06.2016 16:45, Dmitrij Pochepko wrote: > Leonid, > > thank you for taking care of this issue. > Looks good to me(not a reviewer). > > Thanks, > Dmitrij >> Hi >> >> I've updated fix >> >> The vm.simpleArch variable has been added which corresponds to >> os.simpleArch of tested platform. All hotspot tests have been updated >> to use vm.simpleArch instead of os.simpleArch. Once jtreg is fixed >> to read 'os.arch' from tested JDK then it would be possible just >> revert this fix and preserver same behavior (See CODETOOLS-7901695 >> ) . >> >> Updated webrev: >> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/ >> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/ >> >> Testing is still in progress. >> >> Leonid >> >> On 16.06.2016 13:55, David Holmes wrote: >>> On 16/06/2016 8:47 PM, Leonid Mesnik wrote: >>>> Hi >>>> >>>> On 09.06.2016 03:43, David Holmes wrote: >>>>> Hi Leonid, >>>>> >>>>> Sorry for the delay. >>>>> >>>>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> Added jtreg-use at openjdk.java.net >>>>>> >>>>>> I think that you are right. Here is the documentation: >>>>>> http://openjdk.java.net/jtreg/tag-spec.html >>>>>> >>>>>> >>>>>> "@requires >>>>>> >>>>>> Express a dependence on characteristics of the system being >>>>>> tested. >>>>>> Some harnesses allow tests to be selected according to the >>>>>> characteristics of the system being tested. The expression >>>>>> may be >>>>>> composed of the following elements:" >>>>>> >>>>>> "os.arch The operating system architecture, as given by the >>>>>> corresponding system property." >>>>>> >>>>>> So user could expect to have "os.arch" of tested VM. >>>>>> >>>>>> If filed jtreg issues for this: >>>>>> >>>>>> 1. CODETOOLS-7901695 >>>>>> jtreg uses >>>>>> value 'os.arch' property of JDK which executed JDK and not of >>>>>> tested JDK >>>>>> >>>>>> >>>>>> Following fix could be used as a temporary workaround while jtreg >>>>>> fix is >>>>>> not ready. Does it make a sense? I this case it is needed to change >>>>>> linux-arm64 back to linux-aarch64 to minimize changes. >>>>> >>>>> I still think we have a fundamental problem concerning what os.arch >>>>> means. This workaround seems to work but I find it all very >>>>> confusing. >>>>> We really need a vm.arch property, distinct from os.arch. >>>> I see that CODETOOLS-7901695 is going to be fixed. After it is >>>> implemented the 'os.arch' property will point to 'os.arch' of >>>> tested JDK >>>> as it described in jtreg documentation. >>>> However there are 64 failures in nightly are caused by failures of >>>> JVMCI >>>> tests. Does it make a sense to implement this fix as a workaround to >>>> remove noise until jtreg is fixed? >>> >>> There may be some delay between jtreg being fixed and the updated >>> version being put in to use. >>> >>> Implementing the workaround seems reasonable. >>> >>> Thanks, >>> David >>> >>>> Leonid >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>> >>>>>> Leonid >>>>>> >>>>>> On 31.05.2016 04:26, David Holmes wrote: >>>>>>> Hi Leonid, >>>>>>> >>>>>>> This really strikes me as as a jtreg problem that should be >>>>>>> fixed in >>>>>>> jtreg. When writing an @requires clause in a test the test writer >>>>>>> should not have to be thinking "oh wait! Is this going to query >>>>>>> the VM >>>>>>> running jtreg or the VM running the test?". It should obviously >>>>>>> be the >>>>>>> VM running the test. >>>>>>> >>>>>>> That said we also seem to have a problem with the definition of >>>>>>> os.arch: >>>>>>> >>>>>>> os.arch Operating system architecture >>>>>>> >>>>>>> if it is returning the build architecture of the VM and not the >>>>>>> OS it >>>>>>> is running on. That in itself argues for two distinct properties. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> Could you please review following fix: >>>>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>>>>>> >>>>>>>> hotspot >>>>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>>>>>> >>>>>>>> for bug >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>>>>>> >>>>>>>> >>>>>>>> The property "os.name" which was used to filter tests depends >>>>>>>> on the >>>>>>>> arch of jdk which is used to run jtreg. It might differ from >>>>>>>> arch of >>>>>>>> tested jdk. >>>>>>>> This fix introduce new property "vm.arch" which depends on the >>>>>>>> arch of >>>>>>>> tested jdk and could be used to filter tests with @requires. >>>>>>>> >>>>>>>> I verified that tests are filtered where it is expected. >>>>>>>> Note: I am going to push this fix in jdk9/hs to fix regular >>>>>>>> hotspot >>>>>>>> testing. >>>>>>>> >>>>>>>> Leonid >>>>>>>> >>>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Thu Jun 16 15:14:22 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 16 Jun 2016 17:14:22 +0200 Subject: [aarch64-port-dev ] Fwd: A bug in C1 intrinsic arraycopy In-Reply-To: References: Message-ID: <5762C24E.6000000@oracle.com> Hi Xiang, thank you for reporting the problem! I'll look into it. Best regards, Zoltan On 06/16/2016 04:54 PM, Xiang Yuan wrote: > Hi all, > > We find a bug in hotspot C1 intrinsic arraycopy, and it is > reported at https://bugs.openjdk.java.net/browse/JDK-8159431. This report > includes test case, test result and patch. > > We have triggered it with AArch64 and x86 slowdebug & fastdebug JDK. We > didn't test it on Sparc, however from the codes, it may have the same issue. > > > > *****Testcase Begin***** > > public class TestArrayCopy { > > public static void main(String args[]) { > > System.out.println("TestArrayCopy"); > > Object aArray[] = new Object[10]; > > > > for (int i = 0; i < 10; i++) { > > aArray[i] = new Object(); > > } > > > > new TestArrayCopy().test(aArray); > > } > > > > public void test(Object aArray[]) { > > Object a = new Object(); > > > > try { > > System.arraycopy(aArray, 0, a, 0, 1); > > throw new RuntimeException ("Test dst is not array failed!"); > > } catch (ArrayStoreException e) {} > > } > > } > > *****Testcase End***** > > > > To trigger this bug easier, run it with a fastdebug or slowdebug JDK. > > > > Command line: java -XX:TieredStopAtLevel=1 -XX:-UseCompressedClassPointers > -Xcomp -XX:CompileOnly=TestArrayCopy.test,System.arraycopy TestArrayCopy > > > > Expected Result: > > TestArrayCopy > > > > Actual Result: > > TestArrayCopy > > Exception in thread "main" java.lang.RuntimeException: Test dst is not > array failed! > > at TestArrayCopy.test(TestArrayCopy.java:18) > > at TestArrayCopy.main(TestArrayCopy.java:10) > > > > > > The cause of this bug is that in LIR_Assembler::emit_arraycopy, > when the type check of dst or src is needed, it uses the following steps to > do arraycopy: > > 1. check class of src and dst, if class_src is a sub-class of class_dst, > GOTO 4. Type check includes: > > (1) MacroAssembler::check_klass_subtype_fast_path > > (2) Runtime1::slow_subtype_check > > 2. check whether src and dst are both object arrays. > > 3. ...... > > 4. do arraycopy. > > > > However, in the above test case, the src is an array of Object and > the dst is an Object. And Object array is a sub-class of Object, and the > check in Step 1 - (1) is passed. Then the arraycopy is done. This means the > first element in src is copied into the dst, which is a object of class > Object, not an object array. > > > > The option -XX:-UseCompressedClassPointers is necessary. With this > option, when a new object ( not a array ) is created, > C1_MacroAssembler::initialize_header will call store_klass_gap() to set 0 > to the place where stores the length of an array. > > And before the above 4 steps in LIR_Assembler::emit_arraycopy, it > will check whether the length of src or dst is large enough. Therefore, > length 0 will cause this check fail, and arraycopy will not be done. > > > > Without this option, the memory location in an object (not array) > which stores the length in an array is uninitialized which causes the bug > is easier to be triggered in debug mode. > > > > > > > > The following patch can fix it in aarch64 ( which is also included > in the bug report), and other platforms can fix it with similar patches. > > ******** Patch Begin ********* > > diff -r c0b5ea3442e1 src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp > > --- a/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Fri Jun 03 17:45:03 > 2016 -0400 > > +++ b/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Mon Jun 06 11:32:02 > 2016 +0800 > > @@ -2315,6 +2315,14 @@ > > __ load_klass(src, src); > > __ load_klass(dst, dst); > > > > + if (!(flags & LIR_OpArrayCopy::dst_objarray)) { > > + assert(SystemDictionary::Object_klass_loaded(), "check needed"); > > + Klass * obj_klass = > SystemDictionary::well_known_klass(SystemDictionary::Object_klass_knum); > > + __ mov(tmp, (u_int64_t)obj_klass); > > + __ cmp(dst, tmp); > > + __ br(Assembler::EQ, slow); > > + } > > + > > __ check_klass_subtype_fast_path(src, dst, tmp, &cont, &slow, NULL); > > > > __ PUSH(src, dst); > > ******** Patch End ******** > > > > This patch checks whether dst's klass is Object. If so, goes to > check whether dst is an object array. > > > > This check in the patch is a little late, that is after the length > check of src and dst. This may make the check in the patch is not > necessarily correct. > > For without the argument -XX:-UseCompressedClassPointers, the ? > length? of an object ( not array ) is uninitialized. > > Set 0 to the ?length? of an object causes an extra store in each new > operation. And we haven?t found a better solution. > > > > > > Thanks a lot! > > Best Wishes! > > > > Xiang Yuan > > 2016.06.16 From aph at redhat.com Thu Jun 16 15:38:46 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Jun 2016 16:38:46 +0100 Subject: C2: Compiler scheduling oddity Message-ID: <5762C806.2060000@redhat.com> I have an interesting problem with opto scheduling. At the moment I only see this with the AArch64 back-end in jdk8u, but I'm asking here because as far as I can see it could happen anywhere. I have a load and a store of the same field. The load must come before the store. The code looks like this: tree.accept(this); JCTree tmpResult = this.result; this.result = null; public T translate(T); Code: 0: aload_1 1: ifnonnull 6 4: aconst_null 5: areturn 6: aload_1 7: aload_0 8: invokevirtual #2 // Method com/sun/tools/javac/tree/JCTree.accept:(Lcom/sun/tools/javac/tree/JCTree$Visitor;)V 11: aload_0 12: getfield #3 // Field result:Lcom/sun/tools/javac/tree/JCTree; 15: astore_2 16: aload_0 17: aconst_null 18: putfield #3 // Field result:Lcom/sun/tools/javac/tree/JCTree; 21: aload_2 22: areturn Occasionally I get a segfault because the store (of NULL) at bci 18 is scheduled before the load. It only happens when the method is deeply inlined, and it only happens about 1 time in 30. Here's what happens: PhaseCFG::insert_anti_dependences notices that the load must be scheduled before the store. However, it does not insert a precedence link because the store is in a different basic block from the load, and that basic block is going to be executed after the load. As far as I can see the load is in a different basic block from the store because the load has an implicit null check. Later, the blocks containing the load and the store are merged, but there is nothing to stop the store from rising above the load, and occasionally it does. So, it's clear to me what is happening, but how to fix it? I don't know why this doesn't happen all the time. Does any of this sound familiar? I have appended the basic blocks in three phases. These are only the mach nodes, in order to keep the dumps reasonably small. Thanks, Andrew. The dumps: @@@@@@@@@@@@@@@@@@@@@ marks the load, ################# the store. ---- After ScheduleLate ---- B40: # B42 B41 <- N1329 N264 Freq: 0.999885 280 decodeHeapOop === _ 281 [[ 99 284 292 1063 ]] com/sun/tools/javac/tree/JCTree * Oop:com/sun/tools/javac/tree/JCTree * !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 281 loadN === _ 282 195 [[ 280 ]] narrowoop: com/sun/tools/javac/tree/JCTree * needs_anti_dependence_check !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 103 CallDynamicJavaDirect === 105 267 268 14 0 241 195 195 11 0 11 195 0 0 277 0 0 195 0 0 | 278 [[ 104 102 279 282 ]] Dynamic com.sun.tools.javac.tree.JCTree::accept # void ( com/sun/tools/javac/tree/JCTree:NotNull *, com/sun/tools/javac/tree/JCTree$Visitor * ) TreeTranslator::translate @ bci:8 TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 !jvms: TreeTranslator::translate @ bci:8 TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 271 storeimmB0 === 105 269 229 272 [[ 268 ]] memory Memory: @rawptr:BotPTR, idx=Raw; !jvms: TransTypes::translate @ bci:7 TransTypes::visitSelect @ bci:162 272 urShiftP_reg_imm === 105 195 [[ 271 ]] #9/0x00000009 273 storeN === 105 269 195 274 | 278 [[ 268 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+60 * [narrow], name=pt, idx=16; !jvms: TransTypes::translate @ bci:7 TransTypes::visitSelect @ bci:162 274 encodeHeapOop_not_null === 105 275 [[ 273 ]] narrowoop: com/sun/tools/javac/code/Type:NotNull * 277 decodeHeapOop === _ 278 [[ 103 ]] com/sun/tools/javac/code/Type * Oop:com/sun/tools/javac/code/Type * !jvms: TransTypes::translate @ bci:1 TransTypes::visitSelect @ bci:162 278 loadN === _ 269 195 [[ 277 293 803 273 103 ]] narrowoop: com/sun/tools/javac/code/Type * needs_anti_dependence_check !jvms: TransTypes::translate @ bci:1 TransTypes::visitSelect @ bci:162 B42: # B44 B43 <- N105 Freq: 0.999865 288 storeimmB0 === 1326 282 229 289 [[ 286 1059 1066 ]] memory Memory: @rawptr:BotPTR, idx=Raw; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 289 urShiftP_reg_imm === 1326 195 [[ 288 ]] #9/0x00000009 293 storeN === 1326 282 195 278 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+60 * [narrow], name=pt, idx=16; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 294 storeN === 1326 282 195 295 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+12 * [narrow], name=result, idx=17; !jvms: ################ TreeTranslator::translate @ bci:18 ################# TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 295 loadConN0 === 1 [[ 294 ]] narrowoop: NULL 99 cmpP_imm0_branch === 1326 280 [[ 98 1058 ]] P=0.999999, C=-1.000000 !jvms: TransTypes::visitSelect @ bci:165 ---- After GCM ---- B42: # B44 B43 <- N105 Freq: 0.999865 1720 loadN === _ 282 195 [[ 1719 ]] narrowoop: com/sun/tools/javac/tree/JCTree * needs_anti_dependence_check !orig=[281] !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 1719 decodeHeapOop === _ 1720 [[ 1063 284 292 ]] com/sun/tools/javac/tree/JCTree * Oop:com/sun/tools/javac/tree/JCTree * !orig=[280] !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 295 loadConN0 === 1 [[ 294 ]] narrowoop: NULL 289 urShiftP_reg_imm === 1326 195 [[ 288 ]] #9/0x00000009 288 storeimmB0 === 1326 282 229 289 [[ 286 1059 1066 ]] memory Memory: @rawptr:BotPTR, idx=Raw; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 294 storeN === 1326 282 195 295 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+12 * [narrow], name=result, idx=17; !jvms: ################ TreeTranslator::translate @ bci:18 ################# TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 293 storeN === 1326 282 195 278 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+60 * [narrow], name=pt, idx=16; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 284 loadNKlass === 1326 13 1719 [[ 283 1625 ]] narrowklass: klass com/sun/tools/javac/tree/JCTree: 0x0000007e89553d20 * !jvms: TransTypes::visitSelect @ bci:165 1625 NullCheck === 1326 284 [[ 1058 98 ]] ---- After Reg Alloc ---- B31: # B180 B32 <- N105 Freq: 0.999865 295 loadConN0 === 1 [[ 294 ]] narrowoop: NULL 1878 MachSpillCopy === _ 1859 [[ 1720 289 294 293 1883 ]] Oop:com/sun/tools/javac/comp/TransTypes:NotNull * 289 urShiftP_reg_imm === 1326 1878 [[ 288 ]] #9/0x00000009 294 storeN === 1326 282 1878 295 [[ 285 1059 1066 1880 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+12 * [narrow], name=result, idx=17; !jvms: ################ TreeTranslator::translate @ bci:18 ################# TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 1879 loadByteMapBase === 10 [[ 288 286 ]] 0x0000007f7a940000 1720 loadN === _ 282 1878 [[ 1719 ]] narrowoop: com/sun/tools/javac/tree/JCTree * needs_anti_dependence_check !orig=[281] !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 1880 MachSpillCopy === _ 1875 | 294 [[ 293 ]] 288 storeimmB0 === 1326 282 1879 289 [[ 286 1059 1066 ]] memory Memory: @rawptr:BotPTR, idx=Raw; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 1719 decodeHeapOop === _ 1720 [[ 1813 284 292 ]] com/sun/tools/javac/tree/JCTree * Oop:com/sun/tools/javac/tree/JCTree * !orig=[280] !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 293 storeN === 1326 282 1878 1880 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+60 * [narrow], name=pt, idx=16; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 284 loadNKlass === 1326 13 1719 [[ 283 1625 ]] narrowklass: klass com/sun/tools/javac/tree/JCTree: 0x0000007e89553d20 * !jvms: TransTypes::visitSelect @ bci:165 1625 NullCheck === 1326 284 [[ 1058 98 ]] 0x0000007f7135a660: bl 0x0000007f7135b4d0 ; OopMap{[0]=Oop [8]=Oop [16]=NarrowOop [32]=Oop off=804} ;*invokevirtual accept ; - com.sun.tools.javac.tree.TreeTranslator::translate at 8 (line 58) ; - com.sun.tools.javac.comp.TransTypes::translate at 12 (line 490) ; - com.sun.tools.javac.comp.TransTypes::visitSelect at 162 (line 825) ; {virtual_call} ;; B31: # B180 B32 <- B30 Freq: 0.999865 0x0000007f7135a664: mov x11, xzr 0x0000007f7135a668: ldr x13, [sp,#32] 0x0000007f7135a66c: lsr x12, x13, #9 0x0000007f7135a670: str w11, [x13,#12] ;*putfield result ; - com.sun.tools.javac.tree.TreeTranslator::translate at 18 (line 60) ; - com.sun.tools.javac.comp.TransTypes::translate at 12 (line 490) ; - com.sun.tools.javac.comp.TransTypes::visitSelect at 162 (line 825) 0x0000007f7135a674: adrp x14, word_map_base ; {external_word} 0x0000007f7135a678: ldr w10, [x13,#12] ;*getfield result ; - com.sun.tools.javac.tree.TreeTranslator::translate at 12 (line 59) ; - com.sun.tools.javac.comp.TransTypes::translate at 12 (line 490) ; - com.sun.tools.javac.comp.TransTypes::visitSelect at 162 (line 825) From aleksey.shipilev at oracle.com Thu Jun 16 16:14:40 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 16 Jun 2016 19:14:40 +0300 Subject: C2: Compiler scheduling oddity In-Reply-To: <5762C806.2060000@redhat.com> References: <5762C806.2060000@redhat.com> Message-ID: <5762D070.9080603@oracle.com> On 06/16/2016 06:38 PM, Andrew Haley wrote: > Later, the blocks containing the load and the store are merged, but > there is nothing to stop the store from rising above the load, and > occasionally it does. This sounds bad. Shouldn't we re-check anti-dependencies during local scheduling? > So, it's clear to me what is happening, but how to fix it? I don't > know why this doesn't happen all the time. Does any of this sound > familiar? I wonder if you can reliably reproduce it with -XX:+StressLCM (and maybe -XX:+StressGCM too). 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 paul.sandoz at oracle.com Thu Jun 16 17:40:28 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 16 Jun 2016 10:40:28 -0700 Subject: RFR(XS) : 8159149 : Several compiler tests fail with minimal VM In-Reply-To: References: Message-ID: <055DDA43-3671-4749-B322-B989FB3E0779@oracle.com> > On 16 Jun 2016, at 06:27, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8159149/webrev.00/ >> 70 lines changed: 4 ins; 1 del; 65 mod; > > Hi all, > > could you please review the fix for a couple of compiler tests to make it possible to run them on minimal VM or exclude them if they are not applicable? > > minimal VM doesn?t have several features such as jcmd, instrumentation agents and support only which is in java.compact2 module. > - compiler/c2/8004867/TestIntUnsafeOrdered.java and compiler/codegen/8011901/Test8011901.java used sun.misc.Unsafe which is in jdk.unsupported module which is not in java.compact2 set, they tests were rewritten to use jdk.internal.misc.Unsafe instead. > - compiler/jsr292/NonInlinedCall/RedefineTest.java uses instrumentation agent, compiler/compilercontrol/jcmd/PrintDirectivesTest.java uses jcmd, these features are not supported in minimal VM, the corresponding @requiers was added to exclude the tests > - compiler/compilercontrol/mixed/RandomValidCommandsTest.java and compiler/compilercontrol/logcompilation/LogTest.java have indirect dependency on java.management module. this dependency is in driver code, not in test code, so converting ?@run main? to '@run driver? makes it possible to run these tests on minimal VM. PS there is a plan to get rid of this dependency > > JBS: https://bugs.openjdk.java.net/browse/JDK-8159149 > webrev: http://cr.openjdk.java.net/~iignatyev/8159149/webrev.00/ > testing: locally on macos w/ and w/o ?-limitmods java.compact2? and remotely on linux-x86 w/ ?-minimal -limitmods java.compact2? > +1 (mostly on on changes on using internal Unsafe), but the other changes look ok to me too. 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 varming at gmail.com Thu Jun 16 17:51:34 2016 From: varming at gmail.com (Carsten Varming) Date: Thu, 16 Jun 2016 13:51:34 -0400 Subject: RFR JDK-8159720 C2 failures should not prevent C1 from compiling a method Message-ID: Dear compiler list, I ran into a few methods that C2 failed to compile due to their number of arguments. To my surprise C2's failure caused the methods to be executed in the interpreter; although they had previously been compiled with C1. It turns out that a few C2 failures marks a method as not compilable on all tiers. I went through all possible failures with this behavior and I don't see reasons for preventing C1 from compiling a method after C2 failed. Perhaps some of you know the reasons behind this. I wrote a small patch to prevent C2 failures from marking a method as not compilable on all tiers when tiered compilation is on. I filed a bug: JDK-8159720 and created a webrev: http://cr.openjdk.java.net/~cvarming/c2_failure_prevents_all_tiers/0/ Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From cthalinger at twitter.com Thu Jun 16 18:55:01 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 16 Jun 2016 11:55:01 -0700 Subject: RFR JDK-8159720 C2 failures should not prevent C1 from compiling a method In-Reply-To: References: Message-ID: > On Jun 16, 2016, at 10:51 AM, Carsten Varming wrote: > > Dear compiler list, > > I ran into a few methods that C2 failed to compile due to their number of arguments. To my surprise C2's failure caused the methods to be executed in the interpreter; although they had previously been compiled with C1. It turns out that a few C2 failures marks a method as not compilable on all tiers. I went through all possible failures with this behavior and I don't see reasons for preventing C1 from compiling a method after C2 failed. Perhaps some of you know the reasons behind this. I wrote a small patch to prevent C2 failures from marking a method as not compilable on all tiers when tiered compilation is on. I briefly looked at the history of that code and it?s there since the initial load into Mercurial. Does anyone have more history on this or is this just an oversight from early-stage planning? > > I filed a bug: JDK-8159720 > and created a webrev: http://cr.openjdk.java.net/~cvarming/c2_failure_prevents_all_tiers/0/ > > Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Thu Jun 16 19:20:31 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 16 Jun 2016 12:20:31 -0700 Subject: RFR JDK-8159720 C2 failures should not prevent C1 from compiling a method In-Reply-To: References: Message-ID: <0af7377b-c791-1a2a-6765-74c2bb1dcbde@oracle.com> On 6/16/16 11:55 AM, Christian Thalinger wrote: > >> On Jun 16, 2016, at 10:51 AM, Carsten Varming > > wrote: >> >> Dear compiler list, >> >> I ran into a few methods that C2 failed to compile due to their >> number of arguments. To my surprise C2's failure caused the methods >> to be executed in the interpreter; although they had previously been >> compiled with C1. It turns out that a few C2 failures marks a method >> as not compilable on all tiers. I went through all possible failures >> with this behavior and I don't see reasons for preventing C1 from >> compiling a method after C2 failed. Perhaps some of you know the >> reasons behind this. I wrote a small patch to prevent C2 failures >> from marking a method as not compilable on all tiers when tiered >> compilation is on. > > I briefly looked at the history of that code and it?s there since the > initial load into Mercurial. Does anyone have more history on this or > is this just an oversight from early-stage planning? > The _all_tiers part seems to come from https://bugs.openjdk.java.net/browse/JDK-4939496. dl >> >> I filed a bug: JDK-8159720 >> and created a webrev: >> http://cr.openjdk.java.net/~cvarming/c2_failure_prevents_all_tiers/0/ >> >> >> Carsten > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.rodriguez at oracle.com Thu Jun 16 19:34:19 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 16 Jun 2016 12:34:19 -0700 Subject: RFR 8158850: [JVMCI] be more precise when enforcing OopMapValue encoding limitations In-Reply-To: References: Message-ID: Any takers? tom > On Jun 13, 2016, at 5:26 PM, Tom Rodriguez wrote: > > http://cr.openjdk.java.net/~never/8158850/webrev > > The encoding used by OopMapValue puts a limit on the offset in the frame that can hold an oop. Previously this was enforced by setting a limit on the actual frame size but that value wasn?t accurate. It also sets an arbitrary limit on the total size of a frame, even if the encoding limits aren?t reached. Instead JVMCI should export the max offset that can be encoded and will throw an error if that offset is used. The relationship between the max offset and the encoding limits is computed from OopMapValue and checked by asserts. I also added a test that verifies the limits. Tested with jtreg test and with Graal based tests. > > tom From tom.rodriguez at oracle.com Thu Jun 16 19:41:16 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 16 Jun 2016 12:41:16 -0700 Subject: RFR 8159010: [JVMCI] crashes with class redefinition Message-ID: <8F230832-51A5-4F8F-A30B-D12E297CDD12@oracle.com> http://cr.openjdk.java.net/~never/8159010/webrev Running Graal with the VisualVM profiler resulted in some crashes. The profiler is based on the netbeans one that performs redefinition as part of the profiling. The primary problem was that ConstantPools weren?t being registered for metadata scanning. Additionally the logic that trimmed the list of WeakReferences was truncating the list because the iterator was incorrect. tom From vladimir.kozlov at oracle.com Thu Jun 16 19:49:53 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jun 2016 12:49:53 -0700 Subject: RFR 8158850: [JVMCI] be more precise when enforcing OopMapValue encoding limitations In-Reply-To: References: Message-ID: <576302E1.8090108@oracle.com> Field's name should start with '_': + static int max_oop_map_stack_offset; Otherwise looks good. Thanks, Vladimir On 6/16/16 12:34 PM, Tom Rodriguez wrote: > Any takers? > > tom > >> On Jun 13, 2016, at 5:26 PM, Tom Rodriguez wrote: >> >> http://cr.openjdk.java.net/~never/8158850/webrev >> >> The encoding used by OopMapValue puts a limit on the offset in the frame that can hold an oop. Previously this was enforced by setting a limit on the actual frame size but that value wasn?t accurate. It also sets an arbitrary limit on the total size of a frame, even if the encoding limits aren?t reached. Instead JVMCI should export the max offset that can be encoded and will throw an error if that offset is used. The relationship between the max offset and the encoding limits is computed from OopMapValue and checked by asserts. I also added a test that verifies the limits. Tested with jtreg test and with Graal based tests. >> >> tom > From vladimir.kozlov at oracle.com Thu Jun 16 19:52:30 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jun 2016 12:52:30 -0700 Subject: RFR 8159010: [JVMCI] crashes with class redefinition In-Reply-To: <8F230832-51A5-4F8F-A30B-D12E297CDD12@oracle.com> References: <8F230832-51A5-4F8F-A30B-D12E297CDD12@oracle.com> Message-ID: <5763037E.6030102@oracle.com> Looks good to me. thanks, Vladimir On 6/16/16 12:41 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8159010/webrev > > Running Graal with the VisualVM profiler resulted in some crashes. The profiler is based on the netbeans one that performs redefinition as part of the profiling. The primary problem was that ConstantPools weren?t being registered for metadata scanning. Additionally the logic that trimmed the list of WeakReferences was truncating the list because the iterator was incorrect. > > tom > From igor.veresov at oracle.com Thu Jun 16 20:11:04 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 16 Jun 2016 13:11:04 -0700 Subject: RFR JDK-8159720 C2 failures should not prevent C1 from compiling a method In-Reply-To: <0af7377b-c791-1a2a-6765-74c2bb1dcbde@oracle.com> References: <0af7377b-c791-1a2a-6765-74c2bb1dcbde@oracle.com> Message-ID: <0451527D-DA6A-41A5-93A5-957AA92C67B5@oracle.com> This could be from the times when there was an attempt to implement tiered compilation using C2-only. igor > On Jun 16, 2016, at 12:20 PM, dean.long at oracle.com wrote: > > On 6/16/16 11:55 AM, Christian Thalinger wrote: >> >>> On Jun 16, 2016, at 10:51 AM, Carsten Varming > wrote: >>> >>> Dear compiler list, >>> >>> I ran into a few methods that C2 failed to compile due to their number of arguments. To my surprise C2's failure caused the methods to be executed in the interpreter; although they had previously been compiled with C1. It turns out that a few C2 failures marks a method as not compilable on all tiers. I went through all possible failures with this behavior and I don't see reasons for preventing C1 from compiling a method after C2 failed. Perhaps some of you know the reasons behind this. I wrote a small patch to prevent C2 failures from marking a method as not compilable on all tiers when tiered compilation is on. >> >> I briefly looked at the history of that code and it?s there since the initial load into Mercurial. Does anyone have more history on this or is this just an oversight from early-stage planning? >> > The _all_tiers part seems to come from https://bugs.openjdk.java.net/browse/JDK-4939496 . > > dl > >>> >>> I filed a bug: JDK-8159720 >>> and created a webrev: http://cr.openjdk.java.net/~cvarming/c2_failure_prevents_all_tiers/0/ >>> >>> Carsten >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasbold at google.com Thu Jun 16 20:37:09 2016 From: rasbold at google.com (Chuck Rasbold) Date: Thu, 16 Jun 2016 13:37:09 -0700 Subject: RFR JDK-8159720 C2 failures should not prevent C1 from compiling a method In-Reply-To: <0451527D-DA6A-41A5-93A5-957AA92C67B5@oracle.com> References: <0af7377b-c791-1a2a-6765-74c2bb1dcbde@oracle.com> <0451527D-DA6A-41A5-93A5-957AA92C67B5@oracle.com> Message-ID: Igor is correct. The offending code is from the days when C2-only tiered compilation was the goal. On Thu, Jun 16, 2016 at 1:11 PM, Igor Veresov wrote: > This could be from the times when there was an attempt to implement tiered > compilation using C2-only. > > igor > > > On Jun 16, 2016, at 12:20 PM, dean.long at oracle.com wrote: > > On 6/16/16 11:55 AM, Christian Thalinger wrote: > > > On Jun 16, 2016, at 10:51 AM, Carsten Varming wrote: > > Dear compiler list, > > I ran into a few methods that C2 failed to compile due to their number of > arguments. To my surprise C2's failure caused the methods to be executed in > the interpreter; although they had previously been compiled with C1. It > turns out that a few C2 failures marks a method as not compilable on all > tiers. I went through all possible failures with this behavior and I don't > see reasons for preventing C1 from compiling a method after C2 failed. > Perhaps some of you know the reasons behind this. I wrote a small patch to > prevent C2 failures from marking a method as not compilable on all tiers > when tiered compilation is on. > > > I briefly looked at the history of that code and it?s there since the > initial load into Mercurial. Does anyone have more history on this or is > this just an oversight from early-stage planning? > > The _all_tiers part seems to come from > https://bugs.openjdk.java.net/browse/JDK-4939496. > > dl > > > I filed a bug: JDK-8159720 > and created a webrev: > > http://cr.openjdk.java.net/~cvarming/c2_failure_prevents_all_tiers/0/ > > Carsten > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.toal at gmail.com Thu Jun 16 18:00:42 2016 From: brian.toal at gmail.com (Brian Toal) Date: Thu, 16 Jun 2016 11:00:42 -0700 Subject: compiler monitorig/tuning Message-ID: Good day, - How do I monitor the length of the compiler queues (client and server)? I want to understand the backlog (if any) to determine if the application could benefit from more compilation threads. - I remember in the past being able to get detailed compiler statistics from a mbean or something where the metric was prefixed with java.ci and it contained execution count, total time, thread count exec for the client and server compilers. Where can I find this data in realtime for monitoring purposes? If I know the total time and thread count I suppose I can work out if the utilization of the compilation threads. - What other compilation metrics should I be paying close attention to? - Other than tiered compilation becoming the default in Java 8, where there any significant changes that would have slowed down compilation time? We've had -XX:-TieredCompilation set in Java 7 and 8 and haven't touched any other JIT related config. Was there some other setting default that changed which we would have needed to change when going fro 7 to 8? Looking at the various compiler parameters that I know about via PrintFlagsFinal from 7 and 8, there doesn't seem to be any change other than -XX:-TieredCompilation. Regards, - Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jun 16 21:07:41 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jun 2016 07:07:41 +1000 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <57629CD9.40609@oracle.com> References: <5746FDF3.3030102@oracle.com> <57569540.9010106@oracle.com> <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com> <576283C4.4050008@oracle.com> <57629CD9.40609@oracle.com> Message-ID: <58938c44-3915-9288-d329-481da167b0da@oracle.com> Looks good! Thanks, David On 16/06/2016 10:34 PM, Leonid Mesnik wrote: > Hi > > I've updated fix > > The vm.simpleArch variable has been added which corresponds to > os.simpleArch of tested platform. All hotspot tests have been updated to > use vm.simpleArch instead of os.simpleArch. Once jtreg is fixed to read > 'os.arch' from tested JDK then it would be possible just revert this fix > and preserver same behavior (See CODETOOLS-7901695 > ) . > > Updated webrev: > http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/ > http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/ > > Testing is still in progress. > > Leonid > > On 16.06.2016 13:55, David Holmes wrote: >> On 16/06/2016 8:47 PM, Leonid Mesnik wrote: >>> Hi >>> >>> On 09.06.2016 03:43, David Holmes wrote: >>>> Hi Leonid, >>>> >>>> Sorry for the delay. >>>> >>>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> Added jtreg-use at openjdk.java.net >>>>> >>>>> I think that you are right. Here is the documentation: >>>>> http://openjdk.java.net/jtreg/tag-spec.html >>>>> >>>>> >>>>> "@requires >>>>> >>>>> Express a dependence on characteristics of the system being >>>>> tested. >>>>> Some harnesses allow tests to be selected according to the >>>>> characteristics of the system being tested. The expression may be >>>>> composed of the following elements:" >>>>> >>>>> "os.arch The operating system architecture, as given by the >>>>> corresponding system property." >>>>> >>>>> So user could expect to have "os.arch" of tested VM. >>>>> >>>>> If filed jtreg issues for this: >>>>> >>>>> 1. CODETOOLS-7901695 >>>>> jtreg uses >>>>> value 'os.arch' property of JDK which executed JDK and not of >>>>> tested JDK >>>>> >>>>> >>>>> Following fix could be used as a temporary workaround while jtreg >>>>> fix is >>>>> not ready. Does it make a sense? I this case it is needed to change >>>>> linux-arm64 back to linux-aarch64 to minimize changes. >>>> >>>> I still think we have a fundamental problem concerning what os.arch >>>> means. This workaround seems to work but I find it all very confusing. >>>> We really need a vm.arch property, distinct from os.arch. >>> I see that CODETOOLS-7901695 is going to be fixed. After it is >>> implemented the 'os.arch' property will point to 'os.arch' of tested JDK >>> as it described in jtreg documentation. >>> However there are 64 failures in nightly are caused by failures of JVMCI >>> tests. Does it make a sense to implement this fix as a workaround to >>> remove noise until jtreg is fixed? >> >> There may be some delay between jtreg being fixed and the updated >> version being put in to use. >> >> Implementing the workaround seems reasonable. >> >> Thanks, >> David >> >>> Leonid >>>> >>>> David >>>> ----- >>>> >>>> >>>> >>>>> Leonid >>>>> >>>>> On 31.05.2016 04:26, David Holmes wrote: >>>>>> Hi Leonid, >>>>>> >>>>>> This really strikes me as as a jtreg problem that should be fixed in >>>>>> jtreg. When writing an @requires clause in a test the test writer >>>>>> should not have to be thinking "oh wait! Is this going to query >>>>>> the VM >>>>>> running jtreg or the VM running the test?". It should obviously be >>>>>> the >>>>>> VM running the test. >>>>>> >>>>>> That said we also seem to have a problem with the definition of >>>>>> os.arch: >>>>>> >>>>>> os.arch Operating system architecture >>>>>> >>>>>> if it is returning the build architecture of the VM and not the OS it >>>>>> is running on. That in itself argues for two distinct properties. >>>>>> >>>>>> David >>>>>> >>>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote: >>>>>>> Hi >>>>>>> >>>>>>> Could you please review following fix: >>>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/ >>>>>>> >>>>>>> hotspot >>>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/ >>>>>>> >>>>>>> for bug >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831 >>>>>>> >>>>>>> >>>>>>> The property "os.name" which was used to filter tests depends on the >>>>>>> arch of jdk which is used to run jtreg. It might differ from arch of >>>>>>> tested jdk. >>>>>>> This fix introduce new property "vm.arch" which depends on the >>>>>>> arch of >>>>>>> tested jdk and could be used to filter tests with @requires. >>>>>>> >>>>>>> I verified that tests are filtered where it is expected. >>>>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot >>>>>>> testing. >>>>>>> >>>>>>> Leonid >>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Fri Jun 17 00:02:15 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jun 2016 17:02:15 -0700 Subject: C2: Compiler scheduling oddity In-Reply-To: <5762C806.2060000@redhat.com> References: <5762C806.2060000@redhat.com> Message-ID: <57633E07.30105@oracle.com> Hi Andrew, One thing I notice is that there are 2 stores to the same address (Node 195) but they are treated as different addresses with different offsets: TransTypes+12 vs TransTypes+60 294 storeN === 1326 282 195 295 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+12 * [narrow], name=result, idx=17; !jvms: ################ TreeTranslator::translate @ bci:18 ################# TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 293 storeN === 1326 282 195 278 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+60 * [narrow], name=pt, idx=16; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 first stores NULL and second stores previous load result: 278 loadN === _ 269 195 [[ 277 293 803 273 103 ]] narrowoop: com/sun/tools/javac/code/Type * needs_anti_dependence_check !jvms: TransTypes::translate @ bci:1 TransTypes::visitSelect @ bci:162 "After ScheduleLate" looks to me as "After schedule_early()" because nodes are near their definitions. There is schedule_local() (after schedule_late()) which scheduled nodes in each block. Based on your output load node was cloned (172loadN !orig=[281]) into store's block semms due to PhaseCFG::call_catch_cleanup(). But nodes inserted at the beginning of block: // It is safe here to clone a node with anti_dependence // since clones dominate on each path. And nodes order looks correct in your "After GCM" output. It actually surprise to me that "After RA" nodes were reordered. RA should not do that. Usually you will see new MSC nodes or node's clones inserted. But in your case preexisting (before RA) nodes were reordered. It invalidates the above assumption in LCM. I would suggest to narrow down the phase in RA where it happens. Regards, Vladimir On 6/16/16 8:38 AM, Andrew Haley wrote: > I have an interesting problem with opto scheduling. At the moment I > only see this with the AArch64 back-end in jdk8u, but I'm asking here > because as far as I can see it could happen anywhere. > > I have a load and a store of the same field. The load must come > before the store. The code looks like this: > > tree.accept(this); > JCTree tmpResult = this.result; > this.result = null; > > public T translate(T); > Code: > 0: aload_1 > 1: ifnonnull 6 > 4: aconst_null > 5: areturn > 6: aload_1 > 7: aload_0 > 8: invokevirtual #2 // Method com/sun/tools/javac/tree/JCTree.accept:(Lcom/sun/tools/javac/tree/JCTree$Visitor;)V > 11: aload_0 > 12: getfield #3 // Field result:Lcom/sun/tools/javac/tree/JCTree; > 15: astore_2 > 16: aload_0 > 17: aconst_null > 18: putfield #3 // Field result:Lcom/sun/tools/javac/tree/JCTree; > 21: aload_2 > 22: areturn > > Occasionally I get a segfault because the store (of NULL) at bci 18 is > scheduled before the load. It only happens when the method is deeply > inlined, and it only happens about 1 time in 30. > > Here's what happens: > > PhaseCFG::insert_anti_dependences notices that the load must be > scheduled before the store. However, it does not insert a precedence > link because the store is in a different basic block from the load, > and that basic block is going to be executed after the load. As far > as I can see the load is in a different basic block from the store > because the load has an implicit null check. > > Later, the blocks containing the load and the store are merged, but > there is nothing to stop the store from rising above the load, and > occasionally it does. > > So, it's clear to me what is happening, but how to fix it? I don't > know why this doesn't happen all the time. Does any of this sound > familiar? > > I have appended the basic blocks in three phases. These are only the > mach nodes, in order to keep the dumps reasonably small. > > Thanks, > > Andrew. > > > > The dumps: @@@@@@@@@@@@@@@@@@@@@ marks the load, ################# the > store. > > > ---- After ScheduleLate ---- > > B40: # B42 B41 <- N1329 N264 Freq: 0.999885 > 280 decodeHeapOop === _ 281 [[ 99 284 292 1063 ]] com/sun/tools/javac/tree/JCTree * Oop:com/sun/tools/javac/tree/JCTree * !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 > 281 loadN === _ 282 195 [[ 280 ]] narrowoop: com/sun/tools/javac/tree/JCTree * needs_anti_dependence_check !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 > 103 CallDynamicJavaDirect === 105 267 268 14 0 241 195 195 11 0 11 195 0 0 277 0 0 195 0 0 | 278 [[ 104 102 279 282 ]] Dynamic com.sun.tools.javac.tree.JCTree::accept # void ( com/sun/tools/javac/tree/JCTree:NotNull *, com/sun/tools/javac/tree/JCTree$Visitor * ) TreeTranslator::translate @ bci:8 TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 !jvms: TreeTranslator::translate @ bci:8 TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 > 271 storeimmB0 === 105 269 229 272 [[ 268 ]] memory Memory: @rawptr:BotPTR, idx=Raw; !jvms: TransTypes::translate @ bci:7 TransTypes::visitSelect @ bci:162 > 272 urShiftP_reg_imm === 105 195 [[ 271 ]] #9/0x00000009 > 273 storeN === 105 269 195 274 | 278 [[ 268 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+60 * [narrow], name=pt, idx=16; !jvms: TransTypes::translate @ bci:7 TransTypes::visitSelect @ bci:162 > 274 encodeHeapOop_not_null === 105 275 [[ 273 ]] narrowoop: com/sun/tools/javac/code/Type:NotNull * > 277 decodeHeapOop === _ 278 [[ 103 ]] com/sun/tools/javac/code/Type * Oop:com/sun/tools/javac/code/Type * !jvms: TransTypes::translate @ bci:1 TransTypes::visitSelect @ bci:162 > 278 loadN === _ 269 195 [[ 277 293 803 273 103 ]] narrowoop: com/sun/tools/javac/code/Type * needs_anti_dependence_check !jvms: TransTypes::translate @ bci:1 TransTypes::visitSelect @ bci:162 > > B42: # B44 B43 <- N105 Freq: 0.999865 > 288 storeimmB0 === 1326 282 229 289 [[ 286 1059 1066 ]] memory Memory: @rawptr:BotPTR, idx=Raw; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 > 289 urShiftP_reg_imm === 1326 195 [[ 288 ]] #9/0x00000009 > 293 storeN === 1326 282 195 278 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+60 * [narrow], name=pt, idx=16; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 > 294 storeN === 1326 282 195 295 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+12 * [narrow], name=result, idx=17; !jvms: ################ TreeTranslator::translate @ bci:18 ################# TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 > 295 loadConN0 === 1 [[ 294 ]] narrowoop: NULL > 99 cmpP_imm0_branch === 1326 280 [[ 98 1058 ]] P=0.999999, C=-1.000000 !jvms: TransTypes::visitSelect @ bci:165 > > ---- After GCM ---- > > B42: # B44 B43 <- N105 Freq: 0.999865 > 1720 loadN === _ 282 195 [[ 1719 ]] narrowoop: com/sun/tools/javac/tree/JCTree * needs_anti_dependence_check !orig=[281] !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 > 1719 decodeHeapOop === _ 1720 [[ 1063 284 292 ]] com/sun/tools/javac/tree/JCTree * Oop:com/sun/tools/javac/tree/JCTree * !orig=[280] !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 > 295 loadConN0 === 1 [[ 294 ]] narrowoop: NULL > 289 urShiftP_reg_imm === 1326 195 [[ 288 ]] #9/0x00000009 > 288 storeimmB0 === 1326 282 229 289 [[ 286 1059 1066 ]] memory Memory: @rawptr:BotPTR, idx=Raw; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 > 294 storeN === 1326 282 195 295 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+12 * [narrow], name=result, idx=17; !jvms: ################ TreeTranslator::translate @ bci:18 ################# TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 > 293 storeN === 1326 282 195 278 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+60 * [narrow], name=pt, idx=16; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 > 284 loadNKlass === 1326 13 1719 [[ 283 1625 ]] narrowklass: klass com/sun/tools/javac/tree/JCTree: 0x0000007e89553d20 * !jvms: TransTypes::visitSelect @ bci:165 > 1625 NullCheck === 1326 284 [[ 1058 98 ]] > > ---- After Reg Alloc ---- > > B31: # B180 B32 <- N105 Freq: 0.999865 > 295 loadConN0 === 1 [[ 294 ]] narrowoop: NULL > 1878 MachSpillCopy === _ 1859 [[ 1720 289 294 293 1883 ]] Oop:com/sun/tools/javac/comp/TransTypes:NotNull * > 289 urShiftP_reg_imm === 1326 1878 [[ 288 ]] #9/0x00000009 > 294 storeN === 1326 282 1878 295 [[ 285 1059 1066 1880 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+12 * [narrow], name=result, idx=17; !jvms: ################ TreeTranslator::translate @ bci:18 ################# TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 > 1879 loadByteMapBase === 10 [[ 288 286 ]] 0x0000007f7a940000 > 1720 loadN === _ 282 1878 [[ 1719 ]] narrowoop: com/sun/tools/javac/tree/JCTree * needs_anti_dependence_check !orig=[281] !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 > 1880 MachSpillCopy === _ 1875 | 294 [[ 293 ]] > 288 storeimmB0 === 1326 282 1879 289 [[ 286 1059 1066 ]] memory Memory: @rawptr:BotPTR, idx=Raw; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 > 1719 decodeHeapOop === _ 1720 [[ 1813 284 292 ]] com/sun/tools/javac/tree/JCTree * Oop:com/sun/tools/javac/tree/JCTree * !orig=[280] !jvms: @@@@@@@@@@@@@@@@@@ TreeTranslator::translate @ bci:12 @@@@@@@@@@@@@@@@@@@@@ TransTypes::translate @ bci:12 TransTypes::visitSelect @ bci:162 > 293 storeN === 1326 282 1878 1880 [[ 285 1059 1066 ]] memory Memory: @com/sun/tools/javac/comp/TransTypes:NotNull+60 * [narrow], name=pt, idx=16; !jvms: TransTypes::translate @ bci:19 TransTypes::visitSelect @ bci:162 > 284 loadNKlass === 1326 13 1719 [[ 283 1625 ]] narrowklass: klass com/sun/tools/javac/tree/JCTree: 0x0000007e89553d20 * !jvms: TransTypes::visitSelect @ bci:165 > 1625 NullCheck === 1326 284 [[ 1058 98 ]] > > > > > > 0x0000007f7135a660: bl 0x0000007f7135b4d0 ; OopMap{[0]=Oop [8]=Oop [16]=NarrowOop [32]=Oop off=804} > ;*invokevirtual accept > ; - com.sun.tools.javac.tree.TreeTranslator::translate at 8 (line 58) > ; - com.sun.tools.javac.comp.TransTypes::translate at 12 (line 490) > ; - com.sun.tools.javac.comp.TransTypes::visitSelect at 162 (line 825) > ; {virtual_call} > ;; B31: # B180 B32 <- B30 Freq: 0.999865 > > 0x0000007f7135a664: mov x11, xzr > 0x0000007f7135a668: ldr x13, [sp,#32] > 0x0000007f7135a66c: lsr x12, x13, #9 > 0x0000007f7135a670: str w11, [x13,#12] ;*putfield result > ; - com.sun.tools.javac.tree.TreeTranslator::translate at 18 (line 60) > ; - com.sun.tools.javac.comp.TransTypes::translate at 12 (line 490) > ; - com.sun.tools.javac.comp.TransTypes::visitSelect at 162 (line 825) > > 0x0000007f7135a674: adrp x14, word_map_base ; {external_word} > 0x0000007f7135a678: ldr w10, [x13,#12] ;*getfield result > ; - com.sun.tools.javac.tree.TreeTranslator::translate at 12 (line 59) > ; - com.sun.tools.javac.comp.TransTypes::translate at 12 (line 490) > ; - com.sun.tools.javac.comp.TransTypes::visitSelect at 162 (line 825) > From vladimir.kozlov at oracle.com Fri Jun 17 00:52:16 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jun 2016 17:52:16 -0700 Subject: [9] RFR(S): 8159715: Fix for 8072422 is incorrect In-Reply-To: <5762AC7D.60902@oracle.com> References: <5762AC7D.60902@oracle.com> Message-ID: <576349C0.10401@oracle.com> Thank you, Tobias Changes look good. Please, try to run at least jtreg tests with -XX:-UseLoopPredicate. There could be some code that assume that predicates exist only with UseLoopPredicate (missed LoopLimitCheck originally). Thanks, Vladimir On 6/16/16 6:41 AM, Tobias Hartmann wrote: > Hi, > > please review the following fix: > > https://bugs.openjdk.java.net/browse/JDK-8159715 > http://cr.openjdk.java.net/~thartmann/8159715/webrev.00/ > > The fix for JDK-8072422 [1] removed the RangeLimitCheck flag that was set to true by default. In PhaseIdealLoop::do_range_check(), conditional_rc should now be always set to true. The LoopLimitCheck flag was also removed but the code in parse1.cpp and loopnode.cpp was not adapted correctly (see bug description). > > Tested with JPRT and RBT (running). > > Thanks, > Tobias > > [1] http://cr.openjdk.java.net/~zmajo/8072422/webrev.02/ > From cthalinger at twitter.com Fri Jun 17 00:57:23 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 16 Jun 2016 17:57:23 -0700 Subject: RFR JDK-8159720 C2 failures should not prevent C1 from compiling a method In-Reply-To: References: <0af7377b-c791-1a2a-6765-74c2bb1dcbde@oracle.com> <0451527D-DA6A-41A5-93A5-957AA92C67B5@oracle.com> Message-ID: <0C7266E1-B1E3-4CBF-AC50-74104752E109@twitter.com> > On Jun 16, 2016, at 1:37 PM, Chuck Rasbold wrote: > > Igor is correct. The offending code is from the days when C2-only tiered compilation was the goal. Excellent archeology! The change looks good to me then. > > On Thu, Jun 16, 2016 at 1:11 PM, Igor Veresov > wrote: > This could be from the times when there was an attempt to implement tiered compilation using C2-only. > > igor > > >> On Jun 16, 2016, at 12:20 PM, dean.long at oracle.com wrote: >> >> On 6/16/16 11:55 AM, Christian Thalinger wrote: >>> >>>> On Jun 16, 2016, at 10:51 AM, Carsten Varming > wrote: >>>> >>>> Dear compiler list, >>>> >>>> I ran into a few methods that C2 failed to compile due to their number of arguments. To my surprise C2's failure caused the methods to be executed in the interpreter; although they had previously been compiled with C1. It turns out that a few C2 failures marks a method as not compilable on all tiers. I went through all possible failures with this behavior and I don't see reasons for preventing C1 from compiling a method after C2 failed. Perhaps some of you know the reasons behind this. I wrote a small patch to prevent C2 failures from marking a method as not compilable on all tiers when tiered compilation is on. >>> >>> I briefly looked at the history of that code and it?s there since the initial load into Mercurial. Does anyone have more history on this or is this just an oversight from early-stage planning? >>> >> The _all_tiers part seems to come from https://bugs.openjdk.java.net/browse/JDK-4939496 . >> >> dl >> >>>> >>>> I filed a bug: JDK-8159720 >>>> and created a webrev: http://cr.openjdk.java.net/~cvarming/c2_failure_prevents_all_tiers/0/ >>>> >>>> Carsten >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Jun 17 01:05:36 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Jun 2016 18:05:36 -0700 Subject: RFR(XS) : 8159149 : Several compiler tests fail with minimal VM In-Reply-To: References: Message-ID: <57634CE0.2020209@oracle.com> Looks good. Thanks, Vladimir On 6/16/16 6:27 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8159149/webrev.00/ >> 70 lines changed: 4 ins; 1 del; 65 mod; > > Hi all, > > could you please review the fix for a couple of compiler tests to make it possible to run them on minimal VM or exclude them if they are not applicable? > > minimal VM doesn?t have several features such as jcmd, instrumentation agents and support only which is in java.compact2 module. > - compiler/c2/8004867/TestIntUnsafeOrdered.java and compiler/codegen/8011901/Test8011901.java used sun.misc.Unsafe which is in jdk.unsupported module which is not in java.compact2 set, they tests were rewritten to use jdk.internal.misc.Unsafe instead. > - compiler/jsr292/NonInlinedCall/RedefineTest.java uses instrumentation agent, compiler/compilercontrol/jcmd/PrintDirectivesTest.java uses jcmd, these features are not supported in minimal VM, the corresponding @requiers was added to exclude the tests > - compiler/compilercontrol/mixed/RandomValidCommandsTest.java and compiler/compilercontrol/logcompilation/LogTest.java have indirect dependency on java.management module. this dependency is in driver code, not in test code, so converting ?@run main? to '@run driver? makes it possible to run these tests on minimal VM. PS there is a plan to get rid of this dependency > > JBS: https://bugs.openjdk.java.net/browse/JDK-8159149 > webrev: http://cr.openjdk.java.net/~iignatyev/8159149/webrev.00/ > testing: locally on macos w/ and w/o ?-limitmods java.compact2? and remotely on linux-x86 w/ ?-minimal -limitmods java.compact2' > > Thanks, > ? Igor > > From zoltan.majo at oracle.com Fri Jun 17 06:54:11 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 17 Jun 2016 08:54:11 +0200 Subject: Slides for our presentation at the Bucharest Technology Week In-Reply-To: <978487420.314182.1464611784859.JavaMail.zimbra@u-pem.fr> References: <574BE7DF.8090106@oracle.com> <23072a3d-3f97-6ed5-f3e1-cdc2fe046ca5@oracle.com> <574C1412.6000002@oracle.com> <978487420.314182.1464611784859.JavaMail.zimbra@u-pem.fr> Message-ID: <57639E93.6090501@oracle.com> Hi R?mi, On 05/30/2016 02:36 PM, Remi Forax wrote: > Hi Tobias, > very nice set of slides, better than mine on tiered compilation. > > I think you should upload it on the Hotspot wiki for the future generation. John added a section to the HotSpot wiki that contains links to to a number of HotSpot-related presentations (including ours): https://wiki.openjdk.java.net/display/HotSpot/Presentations Best regards, Zoltan > > There is one thing which is not clear to me at the end of the second part, > in the LogLineBench, what policy did you use for String concatenation, is it one that use a StringBuilder or one that use method handles ? > > and BTW, part of the 'bloat' in the code cache also comes from the lambda forms compilation. > > regards, > R?mi > > ----- Mail original ----- >> De: "Tobias Hartmann" >> ?: "Vladimir Ivanov" >> Cc: hotspot-compiler-dev at openjdk.java.net, "hotspot compiler staff ww grp" >> Envoy?: Lundi 30 Mai 2016 12:21:06 >> Objet: Re: Slides for our presentation at the Bucharest Technology Week >> >> Hi Vladimir, >> >> On 30.05.2016 12:04, Vladimir Ivanov wrote: >>> Nice slide deck! >>> >>> I suggest to post the link on open list as well. >> Thank you! I CC'ed hotspot-compiler-dev. >> >> Best regards, >> Tobias >> >>> On 5/30/16 10:12 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> Zoltan and I gave a talk about "The Java HotSpot VM - Under the Hood" at >>>> the Bucharest Tech Week [1] last Friday. We introduced the (compiler) >>>> internals of the VM and presented two of the new features for JDK 9 >>>> (Segmented Code Cache and Compact Strings). >>>> >>>> In case you are interested, here are the slides: >>>> http://cr.openjdk.java.net/~thartmann/bucharest/presentation_oracle.pdf >>>> >>>> Best regards, >>>> Tobias >>>> >>>> [1] http://techweek.ro/agenda/#1459429498462-b7af1585-ddad >>>> From stefan.anzinger at oracle.com Fri Jun 17 07:14:04 2016 From: stefan.anzinger at oracle.com (Stefan Anzinger) Date: Fri, 17 Jun 2016 09:14:04 +0200 Subject: RFR(S): 8159368: [JVMCI] SPARCHotSpotRegisterConfig.callingConvention gives incorrect calling convention for native calls containing fp args In-Reply-To: References: <57629369.4050001@oracle.com> Message-ID: <5763A33C.4040609@oracle.com> Thank you, Igor. I've updated a webrev with the header in the .c file: http://cr.openjdk.java.net/~sanzinger/8159368/webrev.02/ The change is best applied on top of 8159167: [JVMCI] fix HotSpotVMConfig startup performance Thank you Stefan On 06/16/2016 05:03 PM, Igor Veresov wrote: > The .c file probably needs a copyright header. Otherwise looks good. > > igor > >> On Jun 16, 2016, at 4:54 AM, Stefan Anzinger wrote: >> >> Hello, >> >> we found a bug in the JVMCI defined SPARC calling convention when >> calling native methods with single float arguments. Previously the >> HotSpot Calling Convention was used, which is different to the one >> defined in the native ABI [1]. >> >> This fix implements the correct native calling convention in the SPARC >> ABI [1] in SPARCHotSpotRegisterConfig.java. >> >> The rest of the change is a jtreg test which exercises native calls on >> AMD64 and SPARC with code installed via JVMCI. Different parameter types >> and argument counts are tested. >> >> https://bugs.openjdk.java.net/browse/JDK-8159368 >> http://cr.openjdk.java.net/~sanzinger/8159368/webrev.01/ >> >> Reference: >> [1] http://sparc.org/wp-content/uploads/2014/01/SCD.2.4.1.pdf.gz >> >> Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Jun 17 08:49:23 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jun 2016 10:49:23 +0200 Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions In-Reply-To: <09d3ebc7433941a0a48c82ac274a76d5@DEWDFE13DE09.global.corp.sap> References: <09d3ebc7433941a0a48c82ac274a76d5@DEWDFE13DE09.global.corp.sap> Message-ID: Hi, can somebody please sponsor this change? It's ppc64-only but I think I still need a sponsor because it also has a jterg test included. Thank you and best regards, Volker On Thu, Jun 16, 2016 at 11:02 AM, Lindenmaier, Goetz wrote: > Hi Volker, > > I've looked at the change, it's fine. Thanks for fixing this. > > Best regards, > Goetz. > >> -----Original Message----- >> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >> bounces at openjdk.java.net] On Behalf Of Volker Simonis >> Sent: Dienstag, 14. Juni 2016 20:12 >> To: hotspot compiler ; ppc-aix- >> port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net >> Cc: Hiroshi H Horii ; Gustavo Romero >> >> Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the >> generation of illegal instructions >> >> Hi, >> >> can I please get a review for this small change which fixes a code >> generation problem on ppc64: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ >> https://bugs.openjdk.java.net/browse/JDK-8158260 >> >> In the case where we access an unaligned address trough Unsafe, we >> could generate an illegal instruction because we didn't correctly >> specify the memory operand of some match rules. The fix is trivial. >> >> Although this change is ppc64-specific I think I need a sponsor >> because the change contains a new regression test which is supposed to >> run on all platforms. >> >> On platforms where Unsafe.unalignedAccess() will return false (e.g. >> Solaris/SPARC) this test will return immediately (and I've verified >> that it works). >> >> I've also added aarch64 to the list of recipients because on aarch64 >> Unsafe.unalignedAccess() is apparently supported and it would be nice >> if somebody could check that the new regression test is indeed working >> there. >> >> @Hiroshi, Gustavo: could you please verify that this change is enough >> to fix the initial problems you've observed when running Cassandra on >> Linux/ppc64? The changes from ppc64.ad should easily apply to the >> 8u-dev repository. Once we've got this into jdk9 I'll trigger a >> downport request to get the fix into jdk8 as well. >> >> Thank you and best regards, >> Volker From zoltan.majo at oracle.com Fri Jun 17 08:55:10 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 17 Jun 2016 10:55:10 +0200 Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions In-Reply-To: References: <09d3ebc7433941a0a48c82ac274a76d5@DEWDFE13DE09.global.corp.sap> Message-ID: <5763BAEE.3060306@oracle.com> Hi Volker, On 06/17/2016 10:49 AM, Volker Simonis wrote: > Hi, > > can somebody please sponsor this change? > > It's ppc64-only but I think I still need a sponsor because it also has > a jterg test included. I'll sponsor the change. Thank you and best regards, Zoltan > > Thank you and best regards, > Volker > > > On Thu, Jun 16, 2016 at 11:02 AM, Lindenmaier, Goetz > wrote: >> Hi Volker, >> >> I've looked at the change, it's fine. Thanks for fixing this. >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >>> bounces at openjdk.java.net] On Behalf Of Volker Simonis >>> Sent: Dienstag, 14. Juni 2016 20:12 >>> To: hotspot compiler ; ppc-aix- >>> port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net >>> Cc: Hiroshi H Horii ; Gustavo Romero >>> >>> Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the >>> generation of illegal instructions >>> >>> Hi, >>> >>> can I please get a review for this small change which fixes a code >>> generation problem on ppc64: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ >>> https://bugs.openjdk.java.net/browse/JDK-8158260 >>> >>> In the case where we access an unaligned address trough Unsafe, we >>> could generate an illegal instruction because we didn't correctly >>> specify the memory operand of some match rules. The fix is trivial. >>> >>> Although this change is ppc64-specific I think I need a sponsor >>> because the change contains a new regression test which is supposed to >>> run on all platforms. >>> >>> On platforms where Unsafe.unalignedAccess() will return false (e.g. >>> Solaris/SPARC) this test will return immediately (and I've verified >>> that it works). >>> >>> I've also added aarch64 to the list of recipients because on aarch64 >>> Unsafe.unalignedAccess() is apparently supported and it would be nice >>> if somebody could check that the new regression test is indeed working >>> there. >>> >>> @Hiroshi, Gustavo: could you please verify that this change is enough >>> to fix the initial problems you've observed when running Cassandra on >>> Linux/ppc64? The changes from ppc64.ad should easily apply to the >>> 8u-dev repository. Once we've got this into jdk9 I'll trigger a >>> downport request to get the fix into jdk8 as well. >>> >>> Thank you and best regards, >>> Volker From tobias.hartmann at oracle.com Fri Jun 17 09:23:02 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Jun 2016 11:23:02 +0200 Subject: [9] RFR(S): 8159715: Fix for 8072422 is incorrect In-Reply-To: <576349C0.10401@oracle.com> References: <5762AC7D.60902@oracle.com> <576349C0.10401@oracle.com> Message-ID: <5763C176.3080406@oracle.com> Hi Vladimir, On 17.06.2016 02:52, Vladimir Kozlov wrote: > Thank you, Tobias > > Changes look good. Thanks for the review! > Please, try to run at least jtreg tests with -XX:-UseLoopPredicate. There could be some code that assume that predicates exist only with UseLoopPredicate (missed LoopLimitCheck originally). Right, the assert in IdealLoopTree::policy_range_check() assumes that predicates only exist with -XX:+UseLoopPredicate. This assert also failed before 8072422 and I think the UseLoopPredicate part should be removed because we always emit a LoopLimitCheck predicate. New webrev: http://cr.openjdk.java.net/~thartmann/8159715/webrev.01/ While testing, I noticed that -XX:-UseLoopPredicates causes some test failures (also with the latest hs-comp). I filed JDK-8159792 and will put the flag on my list of potential candidates for removal (we don't have a single test with -XX:-UseLoopPredicates). Best regards, Tobias > > Thanks, > Vladimir > > On 6/16/16 6:41 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following fix: >> >> https://bugs.openjdk.java.net/browse/JDK-8159715 >> http://cr.openjdk.java.net/~thartmann/8159715/webrev.00/ >> >> The fix for JDK-8072422 [1] removed the RangeLimitCheck flag that was set to true by default. In PhaseIdealLoop::do_range_check(), conditional_rc should now be always set to true. The LoopLimitCheck flag was also removed but the code in parse1.cpp and loopnode.cpp was not adapted correctly (see bug description). >> >> Tested with JPRT and RBT (running). >> >> Thanks, >> Tobias >> >> [1] http://cr.openjdk.java.net/~zmajo/8072422/webrev.02/ >> From nils.eliasson at oracle.com Fri Jun 17 09:53:55 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 17 Jun 2016 11:53:55 +0200 Subject: RFR(XXS): 8139379: Tests fail with assert(nm->insts_contains(original_pc)) failed: original PC must be in nmethod In-Reply-To: <20160615075518.GM22447@rbackman> References: <20160615075518.GM22447@rbackman> Message-ID: <5763C8B3.6010705@oracle.com> Hi Rickard, Looks good, Regards, Nils On 2016-06-15 09:55, Rickard B?ckman wrote: > Hi, > > can I please have reviews for this small change? > Looking at core files from the asserts it seems that we called > frame::verify_deopt_original_pc() from frame::adjust_unextended_sp() > even though the pc is no longer at the deopt entry for the method. > > The deopt for C2 methods on x86-64 looks like: > > 0x0000 call 0x0005 > 0x0005 sub [esp], 5 > 0x000a jmp ... > > so when the pc is after the call the offset where the original pc is > retrieved is no longer correct. > > For methods compiled with a JVMCI compiler the deopt_entry is also valid > at entry + 5. Adding a check for this should fix the problem. > > Webrev: cr.openjdk.java.net/~rbackman/8139379 > Bug: https://bugs.openjdk.java.net/browse/JDK-8139379 > > Thanks > /R From nils.eliasson at oracle.com Fri Jun 17 10:52:39 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 17 Jun 2016 12:52:39 +0200 Subject: [9] RFR(S): 8156659: assert(CodeCache::find_blob_unsafe(_pc) == _cb) failed: inconsistent Message-ID: <5763D677.3020508@oracle.com> Hi, Please review, Summary: Test is provoking stack overflow errors and is running with deoptimzeALot. The recently added method "look_for_reserved_stack_annotated_method(...)" will traverse the stack and encounter an deoptimized frame that triggers "assert(CodeCache::find_blob_unsafe(_pc) == _cb, "inconsistent");". It fails on deoptimzed frames where the pc is patched and need to be changed to use raw_pc() to work correctly. Testing: Running hotspot_all Bug: https://bugs.openjdk.java.net/browse/JDK-8156659 Webrev: http://cr.openjdk.java.net/~neliasso/8156659/webrev.02/ Regards, Nils Eliasson From vladimir.x.ivanov at oracle.com Fri Jun 17 12:26:34 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 17 Jun 2016 15:26:34 +0300 Subject: [9] RFR(S): 8156659: assert(CodeCache::find_blob_unsafe(_pc) == _cb) failed: inconsistent In-Reply-To: <5763D677.3020508@oracle.com> References: <5763D677.3020508@oracle.com> Message-ID: <302e66dd-d8db-e8f4-b702-03fadc3e3d28@oracle.com> Why aren't other platforms affected? hotspot/src/cpu/x86/vm/frame_x86.cpp: frame frame::sender(RegisterMap* map) const { ... assert(_cb == CodeCache::find_blob(pc()),"Must be the same"); Best regards, Vladimir Ivanov On 6/17/16 1:52 PM, Nils Eliasson wrote: > Hi, > > Please review, > > Summary: > Test is provoking stack overflow errors and is running with > deoptimzeALot. The recently added method > "look_for_reserved_stack_annotated_method(...)" will traverse the stack > and encounter an deoptimized frame that triggers > "assert(CodeCache::find_blob_unsafe(_pc) == _cb, "inconsistent");". It > fails on deoptimzed frames where the pc is patched and need to be > changed to use raw_pc() to work correctly. > > Testing: > Running hotspot_all > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156659 > Webrev: http://cr.openjdk.java.net/~neliasso/8156659/webrev.02/ > > Regards, > Nils Eliasson From dmitrij.pochepko at oracle.com Fri Jun 17 12:46:51 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 17 Jun 2016 15:46:51 +0300 Subject: RFR(S): 8158650 - [jittester] when generating tests with default parameters, generation hangs after 98 test Message-ID: <5763F13B.9000403@oracle.com> Hi all, please review fix for 8158650 - [jittester] when generating tests with default parameters, generation hangs after 98 test Jittester had a few loops conditions which caused infinite looping in special corner cases(case of too simple code without blocks and case of too complex code with large depth). I've re-organize respective loops code to have it fixed. webrev: http://cr.openjdk.java.net/~dpochepk/8158650/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8158650 I've verified fix locally on linux-amd64. Thanks, Dmitrij From dmitrij.pochepko at oracle.com Fri Jun 17 12:47:01 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 17 Jun 2016 15:47:01 +0300 Subject: RFR(XS): 8159803 - Jittester: FileAlreadyExists exception during tests generation Message-ID: <5763F145.1020302@oracle.com> Hi all, please review small fix for 8159803 - Jittester: FileAlreadyExists exception during tests generation A jittester rarely throws FileAlreadyExistsException while generating tests. This was caused by nonsuccessive generated test run. Such situation trigger test re-generation which fails because test file already exists. I've fixed this issue. webrev: http://cr.openjdk.java.net/~dpochepk/8159803/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8159803 I've tested this locally on linux-amd64 Thanks, Dmitij From edward.nevill at gmail.com Fri Jun 17 13:55:27 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 17 Jun 2016 14:55:27 +0100 Subject: [aarch64-port-dev ] RFR: 8159063: aarch64: optimise unaligned array copy long In-Reply-To: <576288AF.1030609@redhat.com> References: <1465399545.18136.11.camel@mylittlepony.linaroharston> <57583B81.5020008@redhat.com> <576288AF.1030609@redhat.com> Message-ID: <1466171727.24673.5.camel@mint> Hi Andrew, On Thu, 2016-06-16 at 12:08 +0100, Andrew Dinn wrote: > On 08/06/16 16:36, Andrew Haley wrote: > > On 08/06/16 16:25, Edward Nevill wrote: > >> http://cr.openjdk.java.net/~enevill/8159063/arraycopy.pdf > >> > >> OK to push to jdk8u now (and later to jdk9)? > > > > Hmm. This looks a bit risky. I'm prepared to approve it for jdk9, > > but jdk8 is production code. So no, please don't push it. > > Andrew asked me also to review this for jdk9. I think it is ok as is but > I would prefer to push it with more comments to explain what it is doing. > > Also, I think it is much clearer if the last 2 word copy is done using > the same model as for the 8 and 4 word copies rather than mimicking the > code in the aligned case. I find the use of the adjust method with > boolean arg supplied by the repeated expression direction == > copy_backwards particularly opaque. > > After my sig is a revised version of your patch which addresses both > these issues. I have tested it on my Mustang hw using your supplied test > code and it succeeds and with the same results as your original patch > whether I pass -XX:+AvoidUnalignedAccesses or > -XX:-AvoidUnalignedAccesses on the command line. Thanks for checking this patch and the tidy ups. Looks good to me. I have run a fastdebug build of jdk8u with your revised patch through jtreg hotspot, langtools and jdk with the following results. Original hotspot: Test results: passed: 686; failed: 19; error: 3 langtools: Test results: passed: 3,102; error: 1 jdk: Test results: passed: 5,186; failed: 576; error: 16 Patched: hotspot: Test results: passed: 686; failed: 19; error: 3 langtools: Test results: passed: 3,102; error: 1 jdk: Test results: passed: 5,187; failed: 576; error: 15 All the best, Ed. From igor.ignatyev at oracle.com Fri Jun 17 13:57:46 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 17 Jun 2016 16:57:46 +0300 Subject: RFR(XS): 8159803 - Jittester: FileAlreadyExists exception during tests generation In-Reply-To: <5763F145.1020302@oracle.com> References: <5763F145.1020302@oracle.com> Message-ID: <750F7E6F-A8C3-4C4B-9742-46A11D219ABA@oracle.com> Dmitrij, I guess it should be CREATE, WRITE and TRUNCATE_EXISTING. Thanks, ? Igor > On Jun 17, 2016, at 3:47 PM, Dmitrij Pochepko wrote: > > Hi all, > > please review small fix for 8159803 - Jittester: FileAlreadyExists exception during tests generation > > A jittester rarely throws FileAlreadyExistsException while generating tests. This was caused by nonsuccessive generated test run. Such situation trigger test re-generation which fails because test file already exists. I've fixed this issue. > > webrev: http://cr.openjdk.java.net/~dpochepk/8159803/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8159803 > > I've tested this locally on linux-amd64 > > Thanks, > Dmitij From aph at redhat.com Fri Jun 17 14:17:29 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 Jun 2016 15:17:29 +0100 Subject: C2: Compiler scheduling oddity In-Reply-To: <57633E07.30105@oracle.com> References: <5762C806.2060000@redhat.com> <57633E07.30105@oracle.com> Message-ID: <57640679.6090401@redhat.com> On 17/06/16 01:02, Vladimir Kozlov wrote: > "After ScheduleLate" looks to me as "After schedule_early()" because nodes are near their definitions. Really not: the dump is here. if (victim) { tty->print("\n---- After ScheduleLate ----\n"); for (uint i = 0; i < number_of_blocks(); i++) { Block* block = get_block(i); block->dump(); } } } // end ScheduleLate Andrew. From aph at redhat.com Fri Jun 17 14:39:09 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 Jun 2016 15:39:09 +0100 Subject: Is it possible to prevent HotSpot from quitting... Message-ID: <57640B8D.8030205@redhat.com> ...while it's still outputting compiler dumps? Thanks, Andrew. From tobias.hartmann at oracle.com Fri Jun 17 14:44:46 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Jun 2016 16:44:46 +0200 Subject: Is it possible to prevent HotSpot from quitting... In-Reply-To: <57640B8D.8030205@redhat.com> References: <57640B8D.8030205@redhat.com> Message-ID: <57640CDE.3090506@oracle.com> Hi Andrew, what about -Xbatch? Best regards, Tobias On 17.06.2016 16:39, Andrew Haley wrote: > ...while it's still outputting compiler dumps? > > Thanks, > > Andrew. > From aph at redhat.com Fri Jun 17 14:51:49 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 Jun 2016 15:51:49 +0100 Subject: Is it possible to prevent HotSpot from quitting... In-Reply-To: <57640CDE.3090506@oracle.com> References: <57640B8D.8030205@redhat.com> <57640CDE.3090506@oracle.com> Message-ID: <57640E85.9030904@redhat.com> On 17/06/16 15:44, Tobias Hartmann wrote: > what about -Xbatch? OK, I'll see if that works for me, but this thing is super-timing- critical and goes away if I change anything! Thanks, Andrew. From dmitrij.pochepko at oracle.com Fri Jun 17 15:48:45 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 17 Jun 2016 18:48:45 +0300 Subject: RFR(XS): 8159803 - Jittester: FileAlreadyExists exception during tests generation In-Reply-To: <750F7E6F-A8C3-4C4B-9742-46A11D219ABA@oracle.com> References: <5763F145.1020302@oracle.com> <750F7E6F-A8C3-4C4B-9742-46A11D219ABA@oracle.com> Message-ID: <57641BDD.2000109@oracle.com> Thank you for quick answer. Please take a look at v02. http://cr.openjdk.java.net/~dpochepk/8159803/webrev.02 Thanks, Dmitrij > Dmitrij, > > I guess it should be CREATE, WRITE and TRUNCATE_EXISTING. > > Thanks, > ? Igor >> On Jun 17, 2016, at 3:47 PM, Dmitrij Pochepko wrote: >> >> Hi all, >> >> please review small fix for 8159803 - Jittester: FileAlreadyExists exception during tests generation >> >> A jittester rarely throws FileAlreadyExistsException while generating tests. This was caused by nonsuccessive generated test run. Such situation trigger test re-generation which fails because test file already exists. I've fixed this issue. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8159803/webrev.01/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8159803 >> >> I've tested this locally on linux-amd64 >> >> Thanks, >> Dmitij From igor.ignatyev at oracle.com Fri Jun 17 16:34:05 2016 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Fri, 17 Jun 2016 19:34:05 +0300 Subject: =?utf-8?B?UmU6IFJGUihYUyk6IDgxNTk4MDMgLSBKaXR0ZXN0ZXI6IEZpbGVBbHJlYWR5RXhp?= =?utf-8?B?c3RzIGV4Y2VwdGlvbiBkdXJpbmcgdGVzdHMgZ2VuZXJhdGlvbg==?= Message-ID: <201606171634.u5HGY8UG001502@aserv0121.oracle.com> Perfect, thanks. -- II ----- Reply message ----- From: "Dmitrij Pochepko" To: "Igor Ignatyev" Cc: Subject: RFR(XS): 8159803 - Jittester: FileAlreadyExists exception during tests generation Date: Fri, Jun 17, 2016 18:48 Thank you for quick answer. Please take a look at v02. http://cr.openjdk.java.net/~dpochepk/8159803/webrev.02 Thanks, Dmitrij > Dmitrij, > > I guess it should be CREATE, WRITE and TRUNCATE_EXISTING. > > Thanks, > ? Igor >> On Jun 17, 2016, at 3:47 PM, Dmitrij Pochepko wrote: >> >> Hi all, >> >> please review small fix for 8159803 - Jittester: FileAlreadyExists exception during tests generation >> >> A jittester rarely throws FileAlreadyExistsException while generating tests. This was caused by nonsuccessive generated test run. Such situation trigger test re-generation which fails because test file already exists. I've fixed this issue. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8159803/webrev.01/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8159803 >> >> I've tested this locally on linux-amd64 >> >> Thanks, >> Dmitij -------------- next part -------------- An HTML attachment was scrubbed... URL: From varming at gmail.com Fri Jun 17 17:38:40 2016 From: varming at gmail.com (Carsten Varming) Date: Fri, 17 Jun 2016 13:38:40 -0400 Subject: RFR JDK-8159720 C2 failures should not prevent C1 from compiling a method In-Reply-To: References: <0af7377b-c791-1a2a-6765-74c2bb1dcbde@oracle.com> <0451527D-DA6A-41A5-93A5-957AA92C67B5@oracle.com> Message-ID: So we all agree that this is a bug. That means I am looking for a sponsor? Carsten On Thu, Jun 16, 2016 at 4:37 PM, Chuck Rasbold wrote: > Igor is correct. The offending code is from the days when C2-only tiered > compilation was the goal. > > On Thu, Jun 16, 2016 at 1:11 PM, Igor Veresov > wrote: > >> This could be from the times when there was an attempt to implement >> tiered compilation using C2-only. >> >> igor >> >> >> On Jun 16, 2016, at 12:20 PM, dean.long at oracle.com wrote: >> >> On 6/16/16 11:55 AM, Christian Thalinger wrote: >> >> >> On Jun 16, 2016, at 10:51 AM, Carsten Varming wrote: >> >> Dear compiler list, >> >> I ran into a few methods that C2 failed to compile due to their number of >> arguments. To my surprise C2's failure caused the methods to be executed in >> the interpreter; although they had previously been compiled with C1. It >> turns out that a few C2 failures marks a method as not compilable on all >> tiers. I went through all possible failures with this behavior and I don't >> see reasons for preventing C1 from compiling a method after C2 failed. >> Perhaps some of you know the reasons behind this. I wrote a small patch to >> prevent C2 failures from marking a method as not compilable on all tiers >> when tiered compilation is on. >> >> >> I briefly looked at the history of that code and it?s there since the >> initial load into Mercurial. Does anyone have more history on this or is >> this just an oversight from early-stage planning? >> >> The _all_tiers part seems to come from >> https://bugs.openjdk.java.net/browse/JDK-4939496. >> >> dl >> >> >> I filed a bug: JDK-8159720 >> and created a webrev: >> >> http://cr.openjdk.java.net/~cvarming/c2_failure_prevents_all_tiers/0/ >> >> Carsten >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.rodriguez at oracle.com Fri Jun 17 18:16:42 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 17 Jun 2016 11:16:42 -0700 Subject: RFR 8159010: [JVMCI] crashes with class redefinition In-Reply-To: <5763037E.6030102@oracle.com> References: <8F230832-51A5-4F8F-A30B-D12E297CDD12@oracle.com> <5763037E.6030102@oracle.com> Message-ID: <84029922-C6FC-457C-A645-6905A877623F@oracle.com> Thanks! tom > On Jun 16, 2016, at 12:52 PM, Vladimir Kozlov wrote: > > Looks good to me. > > thanks, > Vladimir > > On 6/16/16 12:41 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/8159010/webrev >> >> Running Graal with the VisualVM profiler resulted in some crashes. The profiler is based on the netbeans one that performs redefinition as part of the profiling. The primary problem was that ConstantPools weren?t being registered for metadata scanning. Additionally the logic that trimmed the list of WeakReferences was truncating the list because the iterator was incorrect. >> >> tom >> From vladimir.kozlov at oracle.com Fri Jun 17 19:23:10 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jun 2016 12:23:10 -0700 Subject: C2: Compiler scheduling oddity In-Reply-To: <57640679.6090401@redhat.com> References: <5762C806.2060000@redhat.com> <57633E07.30105@oracle.com> <57640679.6090401@redhat.com> Message-ID: <21d95f87-3963-a2fa-ab7b-0e47938d4f32@oracle.com> Okay. So these blocks are LCA for these nodes. What is not clear: why load node was placed between a Call and his CatchNode? Based on java code load should happen on fall-through path and not on exception path. So load should be in the following block after the call. Vladimir On 6/17/16 7:17 AM, Andrew Haley wrote: > On 17/06/16 01:02, Vladimir Kozlov wrote: >> "After ScheduleLate" looks to me as "After schedule_early()" because nodes are near their definitions. > > Really not: the dump is here. > > if (victim) { > tty->print("\n---- After ScheduleLate ----\n"); > for (uint i = 0; i < number_of_blocks(); i++) { > Block* block = get_block(i); > block->dump(); > } > } > > } // end ScheduleLate > > Andrew. > From tom.rodriguez at oracle.com Fri Jun 17 19:26:28 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 17 Jun 2016 12:26:28 -0700 Subject: RFR 8158850: [JVMCI] be more precise when enforcing OopMapValue encoding limitations In-Reply-To: <576302E1.8090108@oracle.com> References: <576302E1.8090108@oracle.com> Message-ID: <027A81C4-B138-4672-90C3-106EB7B3A7B6@oracle.com> Good point. I decided it made more sense to move it into CompilerToVM::Data like other values computed for the HotSpotVMConfig. I also merged against latest hs-comp which eliminated by VMConfig changes. Updated in place. tom > On Jun 16, 2016, at 12:49 PM, Vladimir Kozlov wrote: > > Field's name should start with '_': > > + static int max_oop_map_stack_offset; > > Otherwise looks good. > > Thanks, > Vladimir > > On 6/16/16 12:34 PM, Tom Rodriguez wrote: >> Any takers? >> >> tom >> >>> On Jun 13, 2016, at 5:26 PM, Tom Rodriguez wrote: >>> >>> http://cr.openjdk.java.net/~never/8158850/webrev >>> >>> The encoding used by OopMapValue puts a limit on the offset in the frame that can hold an oop. Previously this was enforced by setting a limit on the actual frame size but that value wasn?t accurate. It also sets an arbitrary limit on the total size of a frame, even if the encoding limits aren?t reached. Instead JVMCI should export the max offset that can be encoded and will throw an error if that offset is used. The relationship between the max offset and the encoding limits is computed from OopMapValue and checked by asserts. I also added a test that verifies the limits. Tested with jtreg test and with Graal based tests. >>> >>> tom >> From vladimir.kozlov at oracle.com Fri Jun 17 19:31:26 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jun 2016 12:31:26 -0700 Subject: RFR 8158850: [JVMCI] be more precise when enforcing OopMapValue encoding limitations In-Reply-To: <027A81C4-B138-4672-90C3-106EB7B3A7B6@oracle.com> References: <576302E1.8090108@oracle.com> <027A81C4-B138-4672-90C3-106EB7B3A7B6@oracle.com> Message-ID: <4637ecca-20ad-ba26-13b4-4ea510a6ac97@oracle.com> jvmciRuntime.hpp still have the field. Thanks, Vladimir On 6/17/16 12:26 PM, Tom Rodriguez wrote: > Good point. I decided it made more sense to move it into CompilerToVM::Data like other values computed for the HotSpotVMConfig. I also merged against latest hs-comp which eliminated by VMConfig changes. Updated in place. > > tom > >> On Jun 16, 2016, at 12:49 PM, Vladimir Kozlov wrote: >> >> Field's name should start with '_': >> >> + static int max_oop_map_stack_offset; >> >> Otherwise looks good. >> >> Thanks, >> Vladimir >> >> On 6/16/16 12:34 PM, Tom Rodriguez wrote: >>> Any takers? >>> >>> tom >>> >>>> On Jun 13, 2016, at 5:26 PM, Tom Rodriguez wrote: >>>> >>>> http://cr.openjdk.java.net/~never/8158850/webrev >>>> >>>> The encoding used by OopMapValue puts a limit on the offset in the frame that can hold an oop. Previously this was enforced by setting a limit on the actual frame size but that value wasn?t accurate. It also sets an arbitrary limit on the total size of a frame, even if the encoding limits aren?t reached. Instead JVMCI should export the max offset that can be encoded and will throw an error if that offset is used. The relationship between the max offset and the encoding limits is computed from OopMapValue and checked by asserts. I also added a test that verifies the limits. Tested with jtreg test and with Graal based tests. >>>> >>>> tom >>> > From vladimir.kozlov at oracle.com Fri Jun 17 19:38:52 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jun 2016 12:38:52 -0700 Subject: [9] RFR(S): 8159715: Fix for 8072422 is incorrect In-Reply-To: <5763C176.3080406@oracle.com> References: <5762AC7D.60902@oracle.com> <576349C0.10401@oracle.com> <5763C176.3080406@oracle.com> Message-ID: On 6/17/16 2:23 AM, Tobias Hartmann wrote: > Hi Vladimir, > > On 17.06.2016 02:52, Vladimir Kozlov wrote: >> Thank you, Tobias >> >> Changes look good. > > Thanks for the review! > >> Please, try to run at least jtreg tests with -XX:-UseLoopPredicate. There could be some code that assume that predicates exist only with UseLoopPredicate (missed LoopLimitCheck originally). > > Right, the assert in IdealLoopTree::policy_range_check() assumes that predicates only exist with -XX:+UseLoopPredicate. This assert also failed before 8072422 and I think the UseLoopPredicate part should be removed because we always emit a LoopLimitCheck predicate. Good. > > New webrev: > http://cr.openjdk.java.net/~thartmann/8159715/webrev.01/ Looks good. > > While testing, I noticed that -XX:-UseLoopPredicates causes some test failures (also with the latest hs-comp). I filed JDK-8159792 and will put the flag on my list of potential candidates for removal (we don't have a single test with -XX:-UseLoopPredicates). thanks, Vladimir > > Best regards, > Tobias > >> >> Thanks, >> Vladimir >> >> On 6/16/16 6:41 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following fix: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8159715 >>> http://cr.openjdk.java.net/~thartmann/8159715/webrev.00/ >>> >>> The fix for JDK-8072422 [1] removed the RangeLimitCheck flag that was set to true by default. In PhaseIdealLoop::do_range_check(), conditional_rc should now be always set to true. The LoopLimitCheck flag was also removed but the code in parse1.cpp and loopnode.cpp was not adapted correctly (see bug description). >>> >>> Tested with JPRT and RBT (running). >>> >>> Thanks, >>> Tobias >>> >>> [1] http://cr.openjdk.java.net/~zmajo/8072422/webrev.02/ >>> From tom.rodriguez at oracle.com Fri Jun 17 19:46:42 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 17 Jun 2016 12:46:42 -0700 Subject: RFR 8158850: [JVMCI] be more precise when enforcing OopMapValue encoding limitations In-Reply-To: <4637ecca-20ad-ba26-13b4-4ea510a6ac97@oracle.com> References: <576302E1.8090108@oracle.com> <027A81C4-B138-4672-90C3-106EB7B3A7B6@oracle.com> <4637ecca-20ad-ba26-13b4-4ea510a6ac97@oracle.com> Message-ID: <46F8B3C4-9421-494D-BF97-6BFFFB7DF943@oracle.com> Oops. It?s gone now. tom > On Jun 17, 2016, at 12:31 PM, Vladimir Kozlov wrote: > > jvmciRuntime.hpp still have the field. > > Thanks, > Vladimir > > On 6/17/16 12:26 PM, Tom Rodriguez wrote: >> Good point. I decided it made more sense to move it into CompilerToVM::Data like other values computed for the HotSpotVMConfig. I also merged against latest hs-comp which eliminated by VMConfig changes. Updated in place. >> >> tom >> >>> On Jun 16, 2016, at 12:49 PM, Vladimir Kozlov wrote: >>> >>> Field's name should start with '_': >>> >>> + static int max_oop_map_stack_offset; >>> >>> Otherwise looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/16/16 12:34 PM, Tom Rodriguez wrote: >>>> Any takers? >>>> >>>> tom >>>> >>>>> On Jun 13, 2016, at 5:26 PM, Tom Rodriguez wrote: >>>>> >>>>> http://cr.openjdk.java.net/~never/8158850/webrev >>>>> >>>>> The encoding used by OopMapValue puts a limit on the offset in the frame that can hold an oop. Previously this was enforced by setting a limit on the actual frame size but that value wasn?t accurate. It also sets an arbitrary limit on the total size of a frame, even if the encoding limits aren?t reached. Instead JVMCI should export the max offset that can be encoded and will throw an error if that offset is used. The relationship between the max offset and the encoding limits is computed from OopMapValue and checked by asserts. I also added a test that verifies the limits. Tested with jtreg test and with Graal based tests. >>>>> >>>>> tom >>>> >> From ahmed.khawaja at oracle.com Fri Jun 17 20:30:08 2016 From: ahmed.khawaja at oracle.com (Ahmed Khawaja) Date: Fri, 17 Jun 2016 15:30:08 -0500 Subject: OopMap and C2 Intrinsics Message-ID: Greetings, I am working on some C2 intrinsics that call into runtime C functions as opposed to stub routines and I occasionally run into crashes related to OopMap's. Looking online, it appears that a custom OopMap is required to be written for runtime functions that return objects/object references? Can someone point me in the right direction in regards to intrinsics and OopMap interactions? Ahmed From vladimir.kozlov at oracle.com Fri Jun 17 20:36:22 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jun 2016 13:36:22 -0700 Subject: RFR 8158850: [JVMCI] be more precise when enforcing OopMapValue encoding limitations In-Reply-To: <46F8B3C4-9421-494D-BF97-6BFFFB7DF943@oracle.com> References: <576302E1.8090108@oracle.com> <027A81C4-B138-4672-90C3-106EB7B3A7B6@oracle.com> <4637ecca-20ad-ba26-13b4-4ea510a6ac97@oracle.com> <46F8B3C4-9421-494D-BF97-6BFFFB7DF943@oracle.com> Message-ID: Good. Thanks, Vladimir On 6/17/16 12:46 PM, Tom Rodriguez wrote: > Oops. It?s gone now. > > tom > >> On Jun 17, 2016, at 12:31 PM, Vladimir Kozlov wrote: >> >> jvmciRuntime.hpp still have the field. >> >> Thanks, >> Vladimir >> >> On 6/17/16 12:26 PM, Tom Rodriguez wrote: >>> Good point. I decided it made more sense to move it into CompilerToVM::Data like other values computed for the HotSpotVMConfig. I also merged against latest hs-comp which eliminated by VMConfig changes. Updated in place. >>> >>> tom >>> >>>> On Jun 16, 2016, at 12:49 PM, Vladimir Kozlov wrote: >>>> >>>> Field's name should start with '_': >>>> >>>> + static int max_oop_map_stack_offset; >>>> >>>> Otherwise looks good. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/16/16 12:34 PM, Tom Rodriguez wrote: >>>>> Any takers? >>>>> >>>>> tom >>>>> >>>>>> On Jun 13, 2016, at 5:26 PM, Tom Rodriguez wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~never/8158850/webrev >>>>>> >>>>>> The encoding used by OopMapValue puts a limit on the offset in the frame that can hold an oop. Previously this was enforced by setting a limit on the actual frame size but that value wasn?t accurate. It also sets an arbitrary limit on the total size of a frame, even if the encoding limits aren?t reached. Instead JVMCI should export the max offset that can be encoded and will throw an error if that offset is used. The relationship between the max offset and the encoding limits is computed from OopMapValue and checked by asserts. I also added a test that verifies the limits. Tested with jtreg test and with Graal based tests. >>>>>> >>>>>> tom >>>>> >>> > From vladimir.kozlov at oracle.com Fri Jun 17 20:39:18 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jun 2016 13:39:18 -0700 Subject: RFR(XS): 8159803 - Jittester: FileAlreadyExists exception during tests generation In-Reply-To: <5763F145.1020302@oracle.com> References: <5763F145.1020302@oracle.com> Message-ID: <0b6d1c33-0d0f-a3dc-0e53-ef72199b61fe@oracle.com> Seems good. Vladimir On 6/17/16 5:47 AM, Dmitrij Pochepko wrote: > Hi all, > > please review small fix for 8159803 - Jittester: FileAlreadyExists exception during tests generation > > A jittester rarely throws FileAlreadyExistsException while generating tests. This was caused by nonsuccessive generated > test run. Such situation trigger test re-generation which fails because test file already exists. I've fixed this issue. > > webrev: http://cr.openjdk.java.net/~dpochepk/8159803/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8159803 > > I've tested this locally on linux-amd64 > > Thanks, > Dmitij From vladimir.kozlov at oracle.com Fri Jun 17 20:39:36 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jun 2016 13:39:36 -0700 Subject: RFR(S): 8158650 - [jittester] when generating tests with default parameters, generation hangs after 98 test In-Reply-To: <5763F13B.9000403@oracle.com> References: <5763F13B.9000403@oracle.com> Message-ID: <7e403a0f-5dc6-9458-e3ce-9883bdc5055c@oracle.com> Good. thanks, Vladimir On 6/17/16 5:46 AM, Dmitrij Pochepko wrote: > Hi all, > > please review fix for 8158650 - [jittester] when generating tests with default parameters, generation hangs after 98 test > > Jittester had a few loops conditions which caused infinite looping in special corner cases(case of too simple code > without blocks and case of too complex code with large depth). I've re-organize respective loops code to have it fixed. > > webrev: http://cr.openjdk.java.net/~dpochepk/8158650/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8158650 > > I've verified fix locally on linux-amd64. > > Thanks, > Dmitrij From vladimir.kozlov at oracle.com Sat Jun 18 02:24:15 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jun 2016 19:24:15 -0700 Subject: Is it possible to prevent HotSpot from quitting... In-Reply-To: <57640E85.9030904@redhat.com> References: <57640B8D.8030205@redhat.com> <57640CDE.3090506@oracle.com> <57640E85.9030904@redhat.com> Message-ID: <12c25e64-3205-4a81-b770-5421b917ce81@oracle.com> I suggest to use Compilation Replay assuming you are trying o reproduce load/store nodes reordering. You can specify -XX:CompileCommand=option,,DumpReplay which will produce several replay_.log per each compilation. Select one in which compiled code has wrong order and replay it with fastdebug VM (with the same other options): -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid2133.log Vladimir On 6/17/16 7:51 AM, Andrew Haley wrote: > On 17/06/16 15:44, Tobias Hartmann wrote: >> what about -Xbatch? > > OK, I'll see if that works for me, but this thing is super-timing- > critical and goes away if I change anything! > > Thanks, > > Andrew. > From tobias.hartmann at oracle.com Mon Jun 20 05:57:15 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 20 Jun 2016 07:57:15 +0200 Subject: [9] RFR(S): 8159715: Fix for 8072422 is incorrect In-Reply-To: References: <5762AC7D.60902@oracle.com> <576349C0.10401@oracle.com> <5763C176.3080406@oracle.com> Message-ID: <576785BB.9020403@oracle.com> Thanks, Vladimir! Best regards, Tobias On 17.06.2016 21:38, Vladimir Kozlov wrote: > On 6/17/16 2:23 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> On 17.06.2016 02:52, Vladimir Kozlov wrote: >>> Thank you, Tobias >>> >>> Changes look good. >> >> Thanks for the review! >> >>> Please, try to run at least jtreg tests with -XX:-UseLoopPredicate. There could be some code that assume that predicates exist only with UseLoopPredicate (missed LoopLimitCheck originally). >> >> Right, the assert in IdealLoopTree::policy_range_check() assumes that predicates only exist with -XX:+UseLoopPredicate. This assert also failed before 8072422 and I think the UseLoopPredicate part should be removed because we always emit a LoopLimitCheck predicate. > > Good. > >> >> New webrev: >> http://cr.openjdk.java.net/~thartmann/8159715/webrev.01/ > > Looks good. > >> >> While testing, I noticed that -XX:-UseLoopPredicates causes some test failures (also with the latest hs-comp). I filed JDK-8159792 and will put the flag on my list of potential candidates for removal (we don't have a single test with -XX:-UseLoopPredicates). > > thanks, > Vladimir > >> >> Best regards, >> Tobias >> >>> >>> Thanks, >>> Vladimir >>> >>> On 6/16/16 6:41 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following fix: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8159715 >>>> http://cr.openjdk.java.net/~thartmann/8159715/webrev.00/ >>>> >>>> The fix for JDK-8072422 [1] removed the RangeLimitCheck flag that was set to true by default. In PhaseIdealLoop::do_range_check(), conditional_rc should now be always set to true. The LoopLimitCheck flag was also removed but the code in parse1.cpp and loopnode.cpp was not adapted correctly (see bug description). >>>> >>>> Tested with JPRT and RBT (running). >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] http://cr.openjdk.java.net/~zmajo/8072422/webrev.02/ >>>> From tobias.hartmann at oracle.com Mon Jun 20 06:55:55 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 20 Jun 2016 08:55:55 +0200 Subject: RFR JDK-8159720 C2 failures should not prevent C1 from compiling a method In-Reply-To: References: <0af7377b-c791-1a2a-6765-74c2bb1dcbde@oracle.com> <0451527D-DA6A-41A5-93A5-957AA92C67B5@oracle.com> Message-ID: <5767937B.1000409@oracle.com> Hi Carsten, your fix looks good! Please send me a changeset and I'll do the sponsoring. Best regards, Tobias On 17.06.2016 19:38, Carsten Varming wrote: > So we all agree that this is a bug. > > That means I am looking for a sponsor? > > Carsten > > On Thu, Jun 16, 2016 at 4:37 PM, Chuck Rasbold > wrote: > > Igor is correct. The offending code is from the days when C2-only tiered compilation was the goal. > > On Thu, Jun 16, 2016 at 1:11 PM, Igor Veresov > wrote: > > This could be from the times when there was an attempt to implement tiered compilation using C2-only. > > igor > > >> On Jun 16, 2016, at 12:20 PM, dean.long at oracle.com wrote: >> >> On 6/16/16 11:55 AM, Christian Thalinger wrote: >> >>> >>>> On Jun 16, 2016, at 10:51 AM, Carsten Varming > wrote: >>>> >>>> Dear compiler list, >>>> >>>> I ran into a few methods that C2 failed to compile due to their number of arguments. To my surprise C2's failure caused the methods to be executed in the interpreter; although they had previously been compiled with C1. It turns out that a few C2 failures marks a method as not compilable on all tiers. I went through all possible failures with this behavior and I don't see reasons for preventing C1 from compiling a method after C2 failed. Perhaps some of you know the reasons behind this. I wrote a small patch to prevent C2 failures from marking a method as not compilable on all tiers when tiered compilation is on. >>> >>> I briefly looked at the history of that code and it?s there since the initial load into Mercurial. Does anyone have more history on this or is this just an oversight from early-stage planning? >>> >> The _all_tiers part seems to come from https://bugs.openjdk.java.net/browse/JDK-4939496. >> >> dl >> >>>> >>>> I filed a bug: JDK-8159720 >>>> and created a webrev: http://cr.openjdk.java.net/~cvarming/c2_failure_prevents_all_tiers/0/ >>>> >>>> Carsten >>> >> > > > From leonid.mesnik at oracle.com Mon Jun 20 13:26:36 2016 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 20 Jun 2016 16:26:36 +0300 Subject: RFR(XXS): JDK-8158581: ciReplay can not be run w/ JFR enabled Message-ID: <5767EF0C.6000503@oracle.com> Hi Could you please review following small fix which disable execution of ciReplay tests with JFR enabled. Webrev: http://cr.openjdk.java.net/~lmesnik/8158581/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8158581 I verified that tests are skipped when FlightRecorer is enabled and executed otherwise. Leonid From tom.rodriguez at oracle.com Mon Jun 20 17:27:35 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 20 Jun 2016 10:27:35 -0700 Subject: RFR 8159856: [JVMCI] InterpreterFrameSizeTest.java failed compilation Message-ID: <775E0751-1F4A-4F18-81EA-018D7AEFCC58@oracle.com> http://cr.openjdk.java.net/~never/8159856/webrev The test wasn?t passing everything it needed compiled in the @compile so depending on the order of test execution it might pass or fail. tom From dmitrij.pochepko at oracle.com Mon Jun 20 17:30:44 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 20 Jun 2016 20:30:44 +0300 Subject: RFR(S): 8158650 - [jittester] when generating tests with default parameters, generation hangs after 98 test In-Reply-To: <7e403a0f-5dc6-9458-e3ce-9883bdc5055c@oracle.com> References: <5763F13B.9000403@oracle.com> <7e403a0f-5dc6-9458-e3ce-9883bdc5055c@oracle.com> Message-ID: <57682844.5080805@oracle.com> Hi, I've got few offline comment and prepared v02 with basically 2 changes: 1) few variables were renamed 2) few lines of common code was moved to IRNode class. Is it still fine? Thanks, Dmitrij On 17.06.2016 23:39, Vladimir Kozlov wrote: > Good. > > thanks, > Vladimir > > On 6/17/16 5:46 AM, Dmitrij Pochepko wrote: >> Hi all, >> >> please review fix for 8158650 - [jittester] when generating tests >> with default parameters, generation hangs after 98 test >> >> Jittester had a few loops conditions which caused infinite looping in >> special corner cases(case of too simple code >> without blocks and case of too complex code with large depth). I've >> re-organize respective loops code to have it fixed. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8158650/webrev.01/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8158650 >> >> I've verified fix locally on linux-amd64. >> >> Thanks, >> Dmitrij From dmitrij.pochepko at oracle.com Mon Jun 20 17:31:19 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 20 Jun 2016 20:31:19 +0300 Subject: RFR(S): 8158650 - [jittester] when generating tests with default parameters, generation hangs after 98 test In-Reply-To: <57682844.5080805@oracle.com> References: <5763F13B.9000403@oracle.com> <7e403a0f-5dc6-9458-e3ce-9883bdc5055c@oracle.com> <57682844.5080805@oracle.com> Message-ID: <57682867.4090806@oracle.com> (just in case, a direct link: http://cr.openjdk.java.net/~dpochepk/8158650/webrev.02/) > Hi, > > I've got few offline comment and prepared v02 with basically 2 > changes: 1) few variables were renamed 2) few lines of common code was > moved to IRNode class. > Is it still fine? > > Thanks, > Dmitrij > > On 17.06.2016 23:39, Vladimir Kozlov wrote: >> Good. >> >> thanks, >> Vladimir >> >> On 6/17/16 5:46 AM, Dmitrij Pochepko wrote: >>> Hi all, >>> >>> please review fix for 8158650 - [jittester] when generating tests >>> with default parameters, generation hangs after 98 test >>> >>> Jittester had a few loops conditions which caused infinite looping >>> in special corner cases(case of too simple code >>> without blocks and case of too complex code with large depth). I've >>> re-organize respective loops code to have it fixed. >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8158650/webrev.01/ >>> CR: https://bugs.openjdk.java.net/browse/JDK-8158650 >>> >>> I've verified fix locally on linux-amd64. >>> >>> Thanks, >>> Dmitrij > From igor.ignatyev at oracle.com Mon Jun 20 17:38:24 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 20 Jun 2016 20:38:24 +0300 Subject: RFR(S): 8158650 - [jittester] when generating tests with default parameters, generation hangs after 98 test In-Reply-To: <57682867.4090806@oracle.com> References: <5763F13B.9000403@oracle.com> <7e403a0f-5dc6-9458-e3ce-9883bdc5055c@oracle.com> <57682844.5080805@oracle.com> <57682867.4090806@oracle.com> Message-ID: <648FB478-BA50-4CE3-AADF-61689C50211F@oracle.com> Dmitrij, looks good to me. Thanks, ? Igor > On Jun 20, 2016, at 8:31 PM, Dmitrij Pochepko wrote: > > > > (just in case, a direct link: http://cr.openjdk.java.net/~dpochepk/8158650/webrev.02/) >> Hi, >> >> I've got few offline comment and prepared v02 with basically 2 changes: 1) few variables were renamed 2) few lines of common code was moved to IRNode class. >> Is it still fine? >> >> Thanks, >> Dmitrij >> >> On 17.06.2016 23:39, Vladimir Kozlov wrote: >>> Good. >>> >>> thanks, >>> Vladimir >>> >>> On 6/17/16 5:46 AM, Dmitrij Pochepko wrote: >>>> Hi all, >>>> >>>> please review fix for 8158650 - [jittester] when generating tests with default parameters, generation hangs after 98 test >>>> >>>> Jittester had a few loops conditions which caused infinite looping in special corner cases(case of too simple code >>>> without blocks and case of too complex code with large depth). I've re-organize respective loops code to have it fixed. >>>> >>>> webrev: http://cr.openjdk.java.net/~dpochepk/8158650/webrev.01/ >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8158650 >>>> >>>> I've verified fix locally on linux-amd64. >>>> >>>> Thanks, >>>> Dmitrij >> > From dmitrij.pochepko at oracle.com Mon Jun 20 17:42:36 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 20 Jun 2016 20:42:36 +0300 Subject: RFR(S): 8159730 - compiler/jvmci/compilerToVM/IsMatureTest failed with "Multiple times invoked method should have method data (assert failed: 0 != 0)" Message-ID: <57682B0C.20909@oracle.com> Hi, please review fix for 8159730 - compiler/jvmci/compilerToVM/IsMatureTest failed with "Multiple times invoked method should have method data (assert failed: 0 != 0)" This test sometimes fails because it expects test method to have method data object even in case it's compiled at level 1(or even running in interpreter mode). I've added guard to disable last checks for compilation level 0 and 1. webrev: http://cr.openjdk.java.net/~dpochepk/8159730/webrev.01/ (somehow webrev haven't saved indentation, so, it's probably easier to look at diff directly: http://cr.openjdk.java.net/~dpochepk/8159730/webrev.01/hotspot.patch) CR: https://bugs.openjdk.java.net/browse/JDK-8159730 I've tested these changes locally on linux-x64 (including -XX:TieredStopAtLevel=1 mode). Thanks, Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Mon Jun 20 17:50:53 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 20 Jun 2016 20:50:53 +0300 Subject: RFR(S): 8158650 - [jittester] when generating tests with default parameters, generation hangs after 98 test In-Reply-To: <648FB478-BA50-4CE3-AADF-61689C50211F@oracle.com> References: <5763F13B.9000403@oracle.com> <7e403a0f-5dc6-9458-e3ce-9883bdc5055c@oracle.com> <57682844.5080805@oracle.com> <57682867.4090806@oracle.com> <648FB478-BA50-4CE3-AADF-61689C50211F@oracle.com> Message-ID: <57682CFD.5030305@oracle.com> Thank you! > Dmitrij, > > looks good to me. > > Thanks, > ? Igor >> On Jun 20, 2016, at 8:31 PM, Dmitrij Pochepko wrote: >> >> >> >> (just in case, a direct link: http://cr.openjdk.java.net/~dpochepk/8158650/webrev.02/) >>> Hi, >>> >>> I've got few offline comment and prepared v02 with basically 2 changes: 1) few variables were renamed 2) few lines of common code was moved to IRNode class. >>> Is it still fine? >>> >>> Thanks, >>> Dmitrij >>> >>> On 17.06.2016 23:39, Vladimir Kozlov wrote: >>>> Good. >>>> >>>> thanks, >>>> Vladimir >>>> >>>> On 6/17/16 5:46 AM, Dmitrij Pochepko wrote: >>>>> Hi all, >>>>> >>>>> please review fix for 8158650 - [jittester] when generating tests with default parameters, generation hangs after 98 test >>>>> >>>>> Jittester had a few loops conditions which caused infinite looping in special corner cases(case of too simple code >>>>> without blocks and case of too complex code with large depth). I've re-organize respective loops code to have it fixed. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8158650/webrev.01/ >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8158650 >>>>> >>>>> I've verified fix locally on linux-amd64. >>>>> >>>>> Thanks, >>>>> Dmitrij From aph at redhat.com Mon Jun 20 17:52:33 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 Jun 2016 18:52:33 +0100 Subject: Is it possible to prevent HotSpot from quitting... In-Reply-To: <12c25e64-3205-4a81-b770-5421b917ce81@oracle.com> References: <57640B8D.8030205@redhat.com> <57640CDE.3090506@oracle.com> <57640E85.9030904@redhat.com> <12c25e64-3205-4a81-b770-5421b917ce81@oracle.com> Message-ID: <57682D61.9040506@redhat.com> On 18/06/16 03:24, Vladimir Kozlov wrote: > I suggest to use Compilation Replay assuming you are trying o reproduce load/store nodes reordering. > > You can specify -XX:CompileCommand=option,,DumpReplay > which will produce several replay_.log per each compilation. Select one in which compiled code has wrong order and > replay it with fastdebug VM (with the same other options): > > -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid2133.log I have never had much success with ReplayCompiles, but I'm trying again: ------------------------------------------------------------------------------ $ java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid0x8239_compid4125.log Error while parsing line 726: constant pool length mismatch: wrong class files? Failed on constant pool length mismatch: wrong class files? ------------------------------------------------------------------------------ And Line 726 is the first ciInstanceKlass: ciInstanceKlass java/lang/Object 1 1 78 100 10 10 10 10 8 10 10 10 100 8 10 3 8 10 10 7 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 100 1 1 1 1 1 1 100 1 1 100 1 1 1 1 12 12 100 12 12 1 12 100 12 12 1 1 12 1 12 12 1 1 1 1 1 1 1 1 1 1 1 1 ciInstanceKlass java/io/Serializable 1 0 7 100 100 1 1 1 1 I guess I need to debug ReplayCompiles now... Andrew. From thomas.stuefe at gmail.com Mon Jun 20 18:37:31 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 20 Jun 2016 20:37:31 +0200 Subject: Is it possible to prevent HotSpot from quitting... In-Reply-To: <57640B8D.8030205@redhat.com> References: <57640B8D.8030205@redhat.com> Message-ID: Hi Andrew, Would -XX:ErrorLogTimeout solve your problem? Kind Regards, Thomas On Fri, Jun 17, 2016 at 4:39 PM, Andrew Haley wrote: > ...while it's still outputting compiler dumps? > > Thanks, > > Andrew. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Mon Jun 20 20:00:59 2016 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 20 Jun 2016 22:00:59 +0200 Subject: RFR: 8159613: [Findbugs] various warnings reported for JVMCI sources Message-ID: Please review this webrev which addresses all the issues[1] identified by FindBugs in the JVMCI Java code. A significant number of issues related to exposing array fields. For example: M V EI: jdk.vm.ci.hotspot.sparc.SPARCHotSpotRegisterConfig.getCallerSaveRegisters() may expose internal representation by returning SPARCHotSpotRegisterConfig.callerSaveRegisters At SPARCHotSpotRegisterConfig.java:[line 187] M V EI: jdk.vm.ci.amd64.AMD64.getAvailableValueRegisters() may expose internal representation by returning AMD64.valueRegistersSSE At AMD64.java:[line 252] These have been addressed by either creating an immutable array wrapper classes (e.g. RegisterArray) or by documenting intentional mutability and applying @SuppressFBWarnings where necessary. https://bugs.openjdk.java.net/browse/JDK-8159613 http://cr.openjdk.java.net/~dnsimon/8159613/ -Doug [1] http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt From igor.ignatyev at oracle.com Mon Jun 20 20:30:42 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 20 Jun 2016 23:30:42 +0300 Subject: RFR(M) : 8132920: use package in compiler testlibraries Message-ID: <0D24DFFA-770C-4301-9D40-F0A6921B2E70@oracle.com> http://cr.openjdk.java.net/~iignatyev/8132920/webrev.00 > 585 lines changed: 91 ins; 73 del; 421 mod; Hi all, could you please review the fix which adds package statement to all compiler test-libraries? as a part of this changeset, I?ve also changed '@run main? to ?@run driver? where it?s appropriate in the changed tests. JBS: https://bugs.openjdk.java.net/browse/JDK-8132920 webrev: http://cr.openjdk.java.net/~iignatyev/8132920/webrev.00 testing: :hotspot_compiler locally on mac Thanks, ? Igor From mail at smogura.eu Mon Jun 20 21:01:48 2016 From: mail at smogura.eu (=?iso-8859-2?Q?Rados=B3aw_Smogura?=) Date: Mon, 20 Jun 2016 21:01:48 +0000 Subject: JDK debug builds on OSX copying dSYM Message-ID: Hello, Recently I tried to compile JDK9 on OS X, I've found two issues related to installing debug symbols, which on OSX are package-folders. 1. Install-file macro doesn't remove dSYM folder, as used rm -f, instead of rm -rf 2. There was additional parenthesis in Dist.gmk which caused dSYM not to be copied. The overview of changes is attached. Kind regards, Radek Smogura -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk9-root-make-dsym-remove.diff Type: application/octet-stream Size: 1344 bytes Desc: jdk9-root-make-dsym-remove.diff URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk9-hotspot-osx-copy-dsym.diff Type: application/octet-stream Size: 593 bytes Desc: jdk9-hotspot-osx-copy-dsym.diff URL: From igor.veresov at oracle.com Mon Jun 20 21:59:50 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 20 Jun 2016 14:59:50 -0700 Subject: RFR 8159856: [JVMCI] InterpreterFrameSizeTest.java failed compilation In-Reply-To: <775E0751-1F4A-4F18-81EA-018D7AEFCC58@oracle.com> References: <775E0751-1F4A-4F18-81EA-018D7AEFCC58@oracle.com> Message-ID: <6C78CE5C-4203-4E23-AC17-80DEE11E29F8@oracle.com> Looks good. igor > On Jun 20, 2016, at 10:27 AM, Tom Rodriguez wrote: > > http://cr.openjdk.java.net/~never/8159856/webrev > > The test wasn?t passing everything it needed compiled in the @compile so depending on the order of test execution it might pass or fail. > > tom From aph at redhat.com Tue Jun 21 08:51:46 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Jun 2016 09:51:46 +0100 Subject: Is it possible to prevent HotSpot from quitting... In-Reply-To: References: <57640B8D.8030205@redhat.com> Message-ID: <57690022.20302@redhat.com> On 20/06/16 19:37, Thomas St?fe wrote: > Would -XX:ErrorLogTimeout solve your problem? OK, I'll try that, thanks. Andrew. From paul.sandoz at oracle.com Tue Jun 21 10:54:50 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 21 Jun 2016 12:54:50 +0200 Subject: RFR(M) : 8132920: use package in compiler testlibraries In-Reply-To: <0D24DFFA-770C-4301-9D40-F0A6921B2E70@oracle.com> References: <0D24DFFA-770C-4301-9D40-F0A6921B2E70@oracle.com> Message-ID: <739C01AC-EA24-435F-A39A-49200729332B@oracle.com> > On 20 Jun 2016, at 22:30, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8132920/webrev.00 >> 585 lines changed: 91 ins; 73 del; 421 mod; > > Hi all, > > could you please review the fix which adds package statement to all compiler test-libraries? as a part of this changeset, I?ve also changed '@run main? to ?@run driver? where it?s appropriate in the changed tests. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8132920 > webrev: http://cr.openjdk.java.net/~iignatyev/8132920/webrev.00 > testing: :hotspot_compiler locally on mac > +1 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 rwestrel at redhat.com Tue Jun 21 11:53:22 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 21 Jun 2016 13:53:22 +0200 Subject: Is it possible to prevent HotSpot from quitting... In-Reply-To: <57682D61.9040506@redhat.com> References: <57640B8D.8030205@redhat.com> <57640CDE.3090506@oracle.com> <57640E85.9030904@redhat.com> <12c25e64-3205-4a81-b770-5421b917ce81@oracle.com> <57682D61.9040506@redhat.com> Message-ID: <57692AB2.40906@redhat.com> > I have never had much success with ReplayCompiles, but I'm trying again: > > ------------------------------------------------------------------------------ > $ java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid0x8239_compid4125.log > Error while parsing line 726: constant pool length mismatch: wrong class files? > > Failed on constant pool length mismatch: wrong class files? > ------------------------------------------------------------------------------ > > And Line 726 is the first ciInstanceKlass: > > ciInstanceKlass java/lang/Object 1 1 78 100 10 10 10 10 8 10 10 10 100 8 10 3 8 10 10 7 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 100 1 1 1 1 1 1 100 1 1 100 1 1 1 1 12 12 100 12 12 1 12 100 12 12 1 1 12 1 12 12 1 1 1 1 1 1 1 1 1 1 1 1 > ciInstanceKlass java/io/Serializable 1 0 7 100 100 1 1 1 1 > > I guess I need to debug ReplayCompiles now... This usually happens when the jdk that created the replay file and the jdk that runs the replay file were not built from the exact same sources. Roland. From dmitrij.pochepko at oracle.com Tue Jun 21 13:17:50 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 21 Jun 2016 16:17:50 +0300 Subject: RFR(S): 8159730 - compiler/jvmci/compilerToVM/IsMatureTest failed with "Multiple times invoked method should have method data (assert failed: 0 != 0)" In-Reply-To: <57682B0C.20909@oracle.com> References: <57682B0C.20909@oracle.com> Message-ID: <57693E7E.8030006@oracle.com> Hi, I've prepared v02 with slightly another wording in comment to improve readability: http://cr.openjdk.java.net/~dpochepk/8159730/webrev.02/ Thanks, Dmitrij > Hi, > > please review fix for 8159730 - > compiler/jvmci/compilerToVM/IsMatureTest failed with "Multiple times > invoked method should have method data (assert failed: 0 != 0)" > > This test sometimes fails because it expects test method to have > method data object even in case it's compiled at level 1(or even > running in interpreter mode). > > I've added guard to disable last checks for compilation level 0 and 1. > > webrev: http://cr.openjdk.java.net/~dpochepk/8159730/webrev.01/ > > (somehow webrev haven't saved indentation, so, it's probably easier to > look at diff directly: > http://cr.openjdk.java.net/~dpochepk/8159730/webrev.01/hotspot.patch) > > CR: https://bugs.openjdk.java.net/browse/JDK-8159730 > > I've tested these changes locally on linux-x64 (including > -XX:TieredStopAtLevel=1 mode). > > Thanks, > Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From rahul.v.raghavan at oracle.com Tue Jun 21 13:18:23 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Tue, 21 Jun 2016 06:18:23 -0700 (PDT) Subject: [aarch64-port-dev ] RFR: 8151661: Performance regression on Solaris-SPARC in 9-b103 In-Reply-To: <5759221C.6090404@redhat.com> References: <42cb523b-2cc3-4b62-9725-8a7cdd7f14b0@default> <5757D5D5.6000806@redhat.com> <4903f7eb-7dfa-11c8-2d8e-f5404cce0ba8@oracle.com> <57584D21.7040104@redhat.com> <5759221C.6090404@redhat.com> Message-ID: Hi, Request help suggestions here. With reference to RFR email thread, to go forward can the following be done? - - Close 8151661 with changes http://cr.openjdk.java.net/~rraghavan/8151661/webrev.00/ - Open new separate, related bug for required AArch64 changes. - If required create a sub-task for the new bug, to quarantine 'hotspot/test/compiler/codegen/8144028/BitTests.java'. Thank you, Rahul > -----Original Message----- > From: Andrew Dinn [mailto:adinn at redhat.com] > Sent: Thursday, June 09, 2016 1:30 PM > To: Andrew Haley; aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR: 8151661: Performance regression on Solaris-SPARC in 9-b103 > > On 08/06/16 17:51, Andrew Haley wrote: > > OK, I'll go for that. So, rather than what I have now: > > > > instruct cmpL_branch_bit(cmpOp cmp, iRegL op1, immL op2, immL0 op3, label labl) %{ > > match(If cmp (CmpL (AndL op1 op2) op3)); > > predicate((n->in(1)->as_Bool()->_test._test == BoolTest::ne > > || n->in(1)->as_Bool()->_test._test == BoolTest::eq) > > && is_power_of_2(n->in(2)->in(1)->in(2)->get_long())); > > > > I'd have to find some way to express the predicate as a pattern. > > > > I know how to do the is_power_of_2 part as an operand in the pattern. > > I'm not sure how to express the idea that this must only match an EQ > > or NE cmpOp without using a predicate to distinguish. > > I'm not certain this will work but you might try the following: > > cmpOp is defined by an operand definition matching Bool (the defn is in > aarch64.ad). It includes an INTERFACE declaration which allows it to > operate as a compare operator with the right condition codes. > > If you introduce a similar operand cmpOpEqNe you can add a predicate in > that operand which includes the same checks on _test as the predicate > for the rule above (except you use n rather than n->in(1)->as_Bool()). I > think you should then be able to use that operand to type the rule input > and the matcher will pre-enforce the constraint before matching using > the new rule. > > You might have to introduce an operand cost preferring cmpOpEqNE over > and cmpOp to make this work (although actually I think it may well just > work without). > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Tue Jun 21 13:21:13 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Jun 2016 14:21:13 +0100 Subject: [aarch64-port-dev ] RFR: 8151661: Performance regression on Solaris-SPARC in 9-b103 In-Reply-To: References: <42cb523b-2cc3-4b62-9725-8a7cdd7f14b0@default> <5757D5D5.6000806@redhat.com> <4903f7eb-7dfa-11c8-2d8e-f5404cce0ba8@oracle.com> <57584D21.7040104@redhat.com> <5759221C.6090404@redhat.com> Message-ID: <57693F49.6080502@redhat.com> On 21/06/16 14:18, Rahul Raghavan wrote: > With reference to RFR email thread, to go forward can the following be done? - > > - Close 8151661 with changes http://cr.openjdk.java.net/~rraghavan/8151661/webrev.00/ > - Open new separate, related bug for required AArch64 changes. > - If required create a sub-task for the new bug, to quarantine 'hotspot/test/compiler/codegen/8144028/BitTests.java'. Yes, don't wait for me. I'm working on another bug. We can fix AArch64 later. Thanks, Andrew. From adinn at redhat.com Tue Jun 21 14:25:21 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 21 Jun 2016 15:25:21 +0100 Subject: [aarch64-port-dev ] RFR: 8159063: aarch64: optimise unaligned array copy long In-Reply-To: <1466171727.24673.5.camel@mint> References: <1465399545.18136.11.camel@mylittlepony.linaroharston> <57583B81.5020008@redhat.com> <576288AF.1030609@redhat.com> <1466171727.24673.5.camel@mint> Message-ID: <57694E51.9040907@redhat.com> On 17/06/16 14:55, Edward Nevill wrote: > Thanks for checking this patch and the tidy ups. Looks good to me. > > I have run a fastdebug build of jdk8u with your revised patch through > jtreg hotspot, langtools and jdk with the following results. > > Original > > hotspot: Test results: passed: 686; failed: 19; error: 3 > langtools: Test results: passed: 3,102; error: 1 > jdk: Test results: passed: 5,186; failed: 576; error: 16 > > Patched: > > hotspot: Test results: passed: 686; failed: 19; error: 3 > langtools: Test results: passed: 3,102; error: 1 > jdk: Test results: passed: 5,187; failed: 576; error: 15 Thanks, Ed. This looks good to use. Andrew Haley, are you ok to go with this patch for JDK9 (once it is agreed that we can proceed)? Would this version be acceptable for backport to JDK8? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Tue Jun 21 14:48:24 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Jun 2016 15:48:24 +0100 Subject: [aarch64-port-dev ] RFR: 8159063: aarch64: optimise unaligned array copy long In-Reply-To: <57694E51.9040907@redhat.com> References: <1465399545.18136.11.camel@mylittlepony.linaroharston> <57583B81.5020008@redhat.com> <576288AF.1030609@redhat.com> <1466171727.24673.5.camel@mint> <57694E51.9040907@redhat.com> Message-ID: <576953B8.4070601@redhat.com> On 21/06/16 15:25, Andrew Dinn wrote: > Andrew Haley, are you ok to go with this patch for JDK9 (once it is > agreed that we can proceed)? Yes. > Would this version be acceptable for backport to JDK8? I guess so. Andrew. From tobias.hartmann at oracle.com Tue Jun 21 15:19:42 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 21 Jun 2016 17:19:42 +0200 Subject: [9] RFR(S): 8159016: Over-unrolled loop is partially removed Message-ID: <57695B0E.3020001@oracle.com> Hi, please review the following fix: https://bugs.openjdk.java.net/browse/JDK-8159016 http://cr.openjdk.java.net/~thartmann/8159016/webrev.00/ I was able to reproduce the problem with a simple test: Object arr[] = new Object[3]; int lim = (arg & 3); for (int i = 0; i < lim; ++i) { arr[i] = new Object(); } The loop is split into pre, main and post loops. The pre loop is executed for at least one iteration, initializing arr[0]. The main loop is unrolled twice, initializing at least arr[1], arr[2], arr[3] and arr[4]. The arr[3] and arr[4] stores are always out of bounds and removed. However, C2 is unable to remove the "over-unrolled", dead main loop. As a result, there is a control path from the main loop to the PostScalarRce loop (see JDK-8151573) without a memory path since the last store was replaced by TOP. We crash because we use a memory edge from a non-dominating region. The out of bound stores in the over-unrolled loop are removed because their range check dependent CastII nodes are removed by the first optimization in CastIINode::Ideal(): CastII (AddI Phi 2) -> AddI (CastII Phi) 2 -> AddI TOP 2 The CastIINodes are replaced by TOP because the type of the loop Phi is >= 1 and the CastII is [1..2], i.e. there is no value >= 1 that is in the [1..2] range if +2 is added. The underlying problem is the over-unrolling of the loop. Since lim < 3, we always only execute at least 3 loop iterations. With the pre loop executing at least one iteration, the main loop should not be unrolled more than once. This problem is similar to JDK-4834191 where we over-unrolled a loop with a constant limit. I changed the implementation of IdealLoopTree::compute_exact_trip_count() to not only compute the exact trip count if the loop limit is constant but to also set the _trip_count field if we are able to determine an upper bound. Like this, the checks in IdealLoopTree::policy_unroll() prevent additional loop unrolling if the trip_count became too small and we keep the maximally unrolled version. An alternative fix would be to disable the CastII optimization for range check dependent CastII nodes but this does not fix the underlying problem of over-unrolling. Tested with regression test, JPRT and RBT (running). Thanks, Tobias From igor.ignatyev at oracle.com Tue Jun 21 16:39:51 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 21 Jun 2016 19:39:51 +0300 Subject: RFR(XXS): JDK-8158581: ciReplay can not be run w/ JFR enabled In-Reply-To: <5767EF0C.6000503@oracle.com> References: <5767EF0C.6000503@oracle.com> Message-ID: <50ED545C-5589-4D81-89B7-3F296691E0E2@oracle.com> Hi Leonid, looks good to me, thanks for fixing that. ? Igor > On Jun 20, 2016, at 4:26 PM, Leonid Mesnik wrote: > > Hi > > Could you please review following small fix which disable execution of ciReplay tests with JFR enabled. > Webrev: http://cr.openjdk.java.net/~lmesnik/8158581/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8158581 > > I verified that tests are skipped when FlightRecorer is enabled and executed otherwise. > > Leonid From tiago.daitx at canonical.com Tue Jun 21 16:34:54 2016 From: tiago.daitx at canonical.com (Tiago Daitx) Date: Tue, 21 Jun 2016 19:34:54 +0300 Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions In-Reply-To: <09d3ebc7433941a0a48c82ac274a76d5@DEWDFE13DE09.global.corp.sap> References: <09d3ebc7433941a0a48c82ac274a76d5@DEWDFE13DE09.global.corp.sap> Message-ID: Hi, I have seen this fix being applied to OpenJDK 9. As Gustavo said, it applies cleanly to jdk8u as well and would be great to have that fix there. Is there any plan to backport it? Regards, Tiago On Thu, Jun 16, 2016 at 12:02 PM, Lindenmaier, Goetz wrote: > Hi Volker, > > I've looked at the change, it's fine. Thanks for fixing this. > > Best regards, > Goetz. > >> -----Original Message----- >> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >> bounces at openjdk.java.net] On Behalf Of Volker Simonis >> Sent: Dienstag, 14. Juni 2016 20:12 >> To: hotspot compiler ; ppc-aix- >> port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net >> Cc: Hiroshi H Horii ; Gustavo Romero >> >> Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the >> generation of illegal instructions >> >> Hi, >> >> can I please get a review for this small change which fixes a code >> generation problem on ppc64: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ >> https://bugs.openjdk.java.net/browse/JDK-8158260 >> >> In the case where we access an unaligned address trough Unsafe, we >> could generate an illegal instruction because we didn't correctly >> specify the memory operand of some match rules. The fix is trivial. >> >> Although this change is ppc64-specific I think I need a sponsor >> because the change contains a new regression test which is supposed to >> run on all platforms. >> >> On platforms where Unsafe.unalignedAccess() will return false (e.g. >> Solaris/SPARC) this test will return immediately (and I've verified >> that it works). >> >> I've also added aarch64 to the list of recipients because on aarch64 >> Unsafe.unalignedAccess() is apparently supported and it would be nice >> if somebody could check that the new regression test is indeed working >> there. >> >> @Hiroshi, Gustavo: could you please verify that this change is enough >> to fix the initial problems you've observed when running Cassandra on >> Linux/ppc64? The changes from ppc64.ad should easily apply to the >> 8u-dev repository. Once we've got this into jdk9 I'll trigger a >> downport request to get the fix into jdk8 as well. >> >> Thank you and best regards, >> Volker -- Tiago St?rmer Daitx Software Engineer tiago.daitx at canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE From adinn at redhat.com Tue Jun 21 17:45:37 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 21 Jun 2016 18:45:37 +0100 Subject: [aarch64-port-dev ] RFR: 8151661: Performance regression on Solaris-SPARC in 9-b103 In-Reply-To: <57693F49.6080502@redhat.com> References: <42cb523b-2cc3-4b62-9725-8a7cdd7f14b0@default> <5757D5D5.6000806@redhat.com> <4903f7eb-7dfa-11c8-2d8e-f5404cce0ba8@oracle.com> <57584D21.7040104@redhat.com> <5759221C.6090404@redhat.com> <57693F49.6080502@redhat.com> Message-ID: <57697D41.2030405@redhat.com> On 21/06/16 14:21, Andrew Haley wrote: > On 21/06/16 14:18, Rahul Raghavan wrote: >> With reference to RFR email thread, to go forward can the following be done? - >> >> - Close 8151661 with changes http://cr.openjdk.java.net/~rraghavan/8151661/webrev.00/ >> - Open new separate, related bug for required AArch64 changes. >> - If required create a sub-task for the new bug, to quarantine 'hotspot/test/compiler/codegen/8144028/BitTests.java'. > > Yes, don't wait for me. I'm working on another bug. We can fix > AArch64 later. I have raised JDK-8610006 to cover the Aarch64 changes and posted an RFR for the necessary patch to aarch64-dev and hotspot-dev. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.kozlov at oracle.com Tue Jun 21 18:47:02 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 11:47:02 -0700 Subject: RFR(XXS): JDK-8158581: ciReplay can not be run w/ JFR enabled In-Reply-To: <5767EF0C.6000503@oracle.com> References: <5767EF0C.6000503@oracle.com> Message-ID: <29013878-8fda-0152-d15f-9cc8c8e263f1@oracle.com> Looks good. Thanks, Vladimir On 6/20/16 6:26 AM, Leonid Mesnik wrote: > Hi > > Could you please review following small fix which disable execution of ciReplay tests with JFR enabled. > Webrev: http://cr.openjdk.java.net/~lmesnik/8158581/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8158581 > > I verified that tests are skipped when FlightRecorer is enabled and executed otherwise. > > Leonid From vladimir.kozlov at oracle.com Tue Jun 21 19:59:50 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 12:59:50 -0700 Subject: [9] RFR(S): 8159016: Over-unrolled loop is partially removed In-Reply-To: <57695B0E.3020001@oracle.com> References: <57695B0E.3020001@oracle.com> Message-ID: Thank you, Tobias Your changes are good to have. You can still have a problem if unrolling is done before CCP phase which calculates array size and/or limit. Try to delay size calculation in test until CCP phase. Something like next (please, verify): // Simplified during CCP: int size = 2; for (; size < 4; size *= 2); Object arr[] = new Object[size - 1]; Why over-unrolling check code in IdealLoopTree::policy_unroll() does not work? I think the trip count check before main loop should collapse whole main loop code. Then we will not have this problem. Why it is not collapsed? About test. You do & 3 two times: int lim = (arg & 3); test(i & 3); Use 11_000 iterations because 10000 may not trigger compilation. Let array escape to avoid EA. For example, return it. Thanks, Vladimir On 6/21/16 8:19 AM, Tobias Hartmann wrote: > Hi, > > please review the following fix: > > https://bugs.openjdk.java.net/browse/JDK-8159016 > http://cr.openjdk.java.net/~thartmann/8159016/webrev.00/ > > I was able to reproduce the problem with a simple test: > > Object arr[] = new Object[3]; > int lim = (arg & 3); > for (int i = 0; i < lim; ++i) { > arr[i] = new Object(); > } > > The loop is split into pre, main and post loops. The pre loop is executed for at least one iteration, initializing arr[0]. The main loop is unrolled twice, initializing at least arr[1], arr[2], arr[3] and arr[4]. The arr[3] and arr[4] stores are always out of bounds and removed. However, C2 is unable to remove the "over-unrolled", dead main loop. As a result, there is a control path from the main loop to the PostScalarRce loop (see JDK-8151573) without a memory path since the last store was replaced by TOP. We crash because we use a memory edge from a non-dominating region. > > The out of bound stores in the over-unrolled loop are removed because their range check dependent CastII nodes are removed by the first optimization in CastIINode::Ideal(): > CastII (AddI Phi 2) -> AddI (CastII Phi) 2 -> AddI TOP 2 > > The CastIINodes are replaced by TOP because the type of the loop Phi is >= 1 and the CastII is [1..2], i.e. there is no value >= 1 that is in the [1..2] range if +2 is added. > > The underlying problem is the over-unrolling of the loop. Since lim < 3, we always only execute at least 3 loop iterations. With the pre loop executing at least one iteration, the main loop should not be unrolled more than once. This problem is similar to JDK-4834191 where we over-unrolled a loop with a constant limit. > > I changed the implementation of IdealLoopTree::compute_exact_trip_count() to not only compute the exact trip count if the loop limit is constant but to also set the _trip_count field if we are able to determine an upper bound. Like this, the checks in IdealLoopTree::policy_unroll() prevent additional loop unrolling if the trip_count became too small and we keep the maximally unrolled version. > > An alternative fix would be to disable the CastII optimization for range check dependent CastII nodes but this does not fix the underlying problem of over-unrolling. > > Tested with regression test, JPRT and RBT (running). > > Thanks, > Tobias > From vladimir.kozlov at oracle.com Tue Jun 21 20:17:07 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 13:17:07 -0700 Subject: RFR(S): 8159730 - compiler/jvmci/compilerToVM/IsMatureTest failed with "Multiple times invoked method should have method data (assert failed: 0 != 0)" In-Reply-To: <57693E7E.8030006@oracle.com> References: <57682B0C.20909@oracle.com> <57693E7E.8030006@oracle.com> Message-ID: <1321d153-866a-6c46-cc25-c09302ec5499@oracle.com> Looks good. Thanks, Vladimir On 6/21/16 6:17 AM, Dmitrij Pochepko wrote: > Hi, > > I've prepared v02 with slightly another wording in comment to improve readability: > http://cr.openjdk.java.net/~dpochepk/8159730/webrev.02/ > > Thanks, > Dmitrij >> Hi, >> >> please review fix for 8159730 - compiler/jvmci/compilerToVM/IsMatureTest failed with "Multiple times invoked method >> should have method data (assert failed: 0 != 0)" >> >> This test sometimes fails because it expects test method to have method data object even in case it's compiled at >> level 1(or even running in interpreter mode). >> >> I've added guard to disable last checks for compilation level 0 and 1. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8159730/webrev.01/ >> >> (somehow webrev haven't saved indentation, so, it's probably easier to look at diff directly: >> http://cr.openjdk.java.net/~dpochepk/8159730/webrev.01/hotspot.patch) >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8159730 >> >> I've tested these changes locally on linux-x64 (including -XX:TieredStopAtLevel=1 mode). >> >> Thanks, >> Dmitrij > From vladimir.kozlov at oracle.com Tue Jun 21 20:34:40 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 13:34:40 -0700 Subject: RFR(M) : 8132920: use package in compiler testlibraries In-Reply-To: <0D24DFFA-770C-4301-9D40-F0A6921B2E70@oracle.com> References: <0D24DFFA-770C-4301-9D40-F0A6921B2E70@oracle.com> Message-ID: <19a3730a-b158-ac35-e482-4808c77e10e2@oracle.com> Looks good. Thanks, Vladimir On 6/20/16 1:30 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8132920/webrev.00 >> 585 lines changed: 91 ins; 73 del; 421 mod; > > Hi all, > > could you please review the fix which adds package statement to all compiler test-libraries? as a part of this changeset, I?ve also changed '@run main? to ?@run driver? where it?s appropriate in the changed tests. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8132920 > webrev: http://cr.openjdk.java.net/~iignatyev/8132920/webrev.00 > testing: :hotspot_compiler locally on mac > > Thanks, > ? Igor > From igor.ignatyev at oracle.com Tue Jun 21 20:37:10 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 21 Jun 2016 23:37:10 +0300 Subject: RFR(M) : 8132920: use package in compiler testlibraries In-Reply-To: <19a3730a-b158-ac35-e482-4808c77e10e2@oracle.com> References: <0D24DFFA-770C-4301-9D40-F0A6921B2E70@oracle.com> <19a3730a-b158-ac35-e482-4808c77e10e2@oracle.com> Message-ID: Vladimir, Paul, Thank you for review. ? Igor > On Jun 21, 2016, at 11:34 PM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > On Jun 21, 2016, at 1:54 PM, Paul Sandoz wrote: > > +1 > > Paul. > On 6/20/16 1:30 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8132920/webrev.00 >>> 585 lines changed: 91 ins; 73 del; 421 mod; >> >> Hi all, >> >> could you please review the fix which adds package statement to all compiler test-libraries? as a part of this changeset, I?ve also changed '@run main? to ?@run driver? where it?s appropriate in the changed tests. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8132920 >> webrev: http://cr.openjdk.java.net/~iignatyev/8132920/webrev.00 >> testing: :hotspot_compiler locally on mac >> >> Thanks, >> ? Igor >> From vladimir.kozlov at oracle.com Tue Jun 21 20:40:22 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 13:40:22 -0700 Subject: RFR: 8159613: [Findbugs] various warnings reported for JVMCI sources In-Reply-To: References: Message-ID: Copyright year is wrong in new files. Otherwise looks good. Thanks, Vladimir On 6/20/16 1:00 PM, Doug Simon wrote: > Please review this webrev which addresses all the issues[1] identified by FindBugs in the JVMCI Java code. A significant number of issues related to exposing array fields. For example: > > M V EI: jdk.vm.ci.hotspot.sparc.SPARCHotSpotRegisterConfig.getCallerSaveRegisters() may expose internal representation by returning SPARCHotSpotRegisterConfig.callerSaveRegisters At SPARCHotSpotRegisterConfig.java:[line 187] > M V EI: jdk.vm.ci.amd64.AMD64.getAvailableValueRegisters() may expose internal representation by returning AMD64.valueRegistersSSE At AMD64.java:[line 252] > > These have been addressed by either creating an immutable array wrapper classes (e.g. RegisterArray) or by documenting intentional mutability and applying @SuppressFBWarnings where necessary. > > https://bugs.openjdk.java.net/browse/JDK-8159613 > http://cr.openjdk.java.net/~dnsimon/8159613/ > > -Doug > > [1] http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt > From vladimir.kozlov at oracle.com Tue Jun 21 20:46:06 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 13:46:06 -0700 Subject: RFR 8159856: [JVMCI] InterpreterFrameSizeTest.java failed compilation In-Reply-To: <775E0751-1F4A-4F18-81EA-018D7AEFCC58@oracle.com> References: <775E0751-1F4A-4F18-81EA-018D7AEFCC58@oracle.com> Message-ID: <82ca5a85-d0dd-6e9d-4072-4c7209d8fad2@oracle.com> Good. Thanks, Vladimir On 6/20/16 10:27 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8159856/webrev > > The test wasn?t passing everything it needed compiled in the @compile so depending on the order of test execution it might pass or fail. > > tom > From doug.simon at oracle.com Tue Jun 21 21:04:38 2016 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 21 Jun 2016 23:04:38 +0200 Subject: RFR: 8159613: [Findbugs] various warnings reported for JVMCI sources In-Reply-To: References: Message-ID: Thanks for the review. I?ve fixed the copyright year in the new files. -Doug > On 21 Jun 2016, at 22:40, Vladimir Kozlov wrote: > > Copyright year is wrong in new files. Otherwise looks good. > > Thanks, > Vladimir > > On 6/20/16 1:00 PM, Doug Simon wrote: >> Please review this webrev which addresses all the issues[1] identified by FindBugs in the JVMCI Java code. A significant number of issues related to exposing array fields. For example: >> >> M V EI: jdk.vm.ci.hotspot.sparc.SPARCHotSpotRegisterConfig.getCallerSaveRegisters() may expose internal representation by returning SPARCHotSpotRegisterConfig.callerSaveRegisters At SPARCHotSpotRegisterConfig.java:[line 187] >> M V EI: jdk.vm.ci.amd64.AMD64.getAvailableValueRegisters() may expose internal representation by returning AMD64.valueRegistersSSE At AMD64.java:[line 252] >> >> These have been addressed by either creating an immutable array wrapper classes (e.g. RegisterArray) or by documenting intentional mutability and applying @SuppressFBWarnings where necessary. >> >> https://bugs.openjdk.java.net/browse/JDK-8159613 >> http://cr.openjdk.java.net/~dnsimon/8159613/ >> >> -Doug >> >> [1] http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt >> From cthalinger at twitter.com Tue Jun 21 22:10:09 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Tue, 21 Jun 2016 15:10:09 -0700 Subject: RFR: 8159613: [Findbugs] various warnings reported for JVMCI sources In-Reply-To: References: Message-ID: <559A0E48-5DBA-4688-ABB3-D9602835622C@twitter.com> Why are we moving the static fields out of the inner classes in HotSpotMethodData? It makes it harder to understand. > On Jun 20, 2016, at 1:00 PM, Doug Simon wrote: > > Please review this webrev which addresses all the issues[1] identified by FindBugs in the JVMCI Java code. A significant number of issues related to exposing array fields. For example: > > M V EI: jdk.vm.ci.hotspot.sparc.SPARCHotSpotRegisterConfig.getCallerSaveRegisters() may expose internal representation by returning SPARCHotSpotRegisterConfig.callerSaveRegisters At SPARCHotSpotRegisterConfig.java:[line 187] > M V EI: jdk.vm.ci.amd64.AMD64.getAvailableValueRegisters() may expose internal representation by returning AMD64.valueRegistersSSE At AMD64.java:[line 252] > > These have been addressed by either creating an immutable array wrapper classes (e.g. RegisterArray) or by documenting intentional mutability and applying @SuppressFBWarnings where necessary. > > https://bugs.openjdk.java.net/browse/JDK-8159613 > http://cr.openjdk.java.net/~dnsimon/8159613/ > > -Doug > > [1] http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt From cthalinger at twitter.com Tue Jun 21 22:18:12 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Tue, 21 Jun 2016 15:18:12 -0700 Subject: RFR: 8159613: [Findbugs] various warnings reported for JVMCI sources In-Reply-To: References: Message-ID: src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java I guess the problem in getHostArchitectureName is the missing default case? I?d prefer something like this: - switch (arch) { - case "x86_64": return "amd64"; - case "sparcv9": return "sparc"; default: return arch; } > On Jun 20, 2016, at 1:00 PM, Doug Simon wrote: > > Please review this webrev which addresses all the issues[1] identified by FindBugs in the JVMCI Java code. A significant number of issues related to exposing array fields. For example: > > M V EI: jdk.vm.ci.hotspot.sparc.SPARCHotSpotRegisterConfig.getCallerSaveRegisters() may expose internal representation by returning SPARCHotSpotRegisterConfig.callerSaveRegisters At SPARCHotSpotRegisterConfig.java:[line 187] > M V EI: jdk.vm.ci.amd64.AMD64.getAvailableValueRegisters() may expose internal representation by returning AMD64.valueRegistersSSE At AMD64.java:[line 252] > > These have been addressed by either creating an immutable array wrapper classes (e.g. RegisterArray) or by documenting intentional mutability and applying @SuppressFBWarnings where necessary. > > https://bugs.openjdk.java.net/browse/JDK-8159613 > http://cr.openjdk.java.net/~dnsimon/8159613/ > > -Doug > > [1] http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Wed Jun 22 00:48:20 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 22 Jun 2016 03:48:20 +0300 Subject: RFR(XXS) : 8160025 : compiler/testlibrary/uncommontrap/Verifier doesn't close FileReader Message-ID: <1E70A481-D5DF-4D58-AD25-BC43014ED32E@oracle.com> http://cr.openjdk.java.net/~iignatyev/8160025/webrev.00/ > 4 lines changed: 3 ins; 0 del; 1 mod; Hi all, could you please review this tiny fix adds try-w/-resources to ensure that new created FileReader will be closed? because of this bug, compiler/uncommontrap/TestUnstableIfTrap.java fails on windows during 8132920 integration. we haven't see this before 8132920, because Verifier was run in othervm mode, so JVM which run it was always closed before clean-up phase. webrev: http://cr.openjdk.java.net/~iignatyev/8160025/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8160025 testing: compiler/uncommontrap/TestUnstableIfTrap.java on mac and windows (running) Thanks, ? Igor From vladimir.kozlov at oracle.com Wed Jun 22 02:28:54 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 19:28:54 -0700 Subject: RFR(XXS) : 8160025 : compiler/testlibrary/uncommontrap/Verifier doesn't close FileReader In-Reply-To: <1E70A481-D5DF-4D58-AD25-BC43014ED32E@oracle.com> References: <1E70A481-D5DF-4D58-AD25-BC43014ED32E@oracle.com> Message-ID: <5ab5ce7e-33f3-2617-bea2-000de45b1eda@oracle.com> Looks good. Thanks, Vladimir On 6/21/16 5:48 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8160025/webrev.00/ >> 4 lines changed: 3 ins; 0 del; 1 mod; > Hi all, > > could you please review this tiny fix adds try-w/-resources to ensure that new created FileReader will be closed? > > because of this bug, compiler/uncommontrap/TestUnstableIfTrap.java fails on windows during 8132920 integration. we haven't see this before 8132920, because Verifier was run in othervm mode, so JVM which run it was always closed before clean-up phase. > > webrev: http://cr.openjdk.java.net/~iignatyev/8160025/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8160025 > testing: compiler/uncommontrap/TestUnstableIfTrap.java on mac and windows (running) > > Thanks, > ? Igor > From vladimir.kozlov at oracle.com Wed Jun 22 04:01:31 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Jun 2016 21:01:31 -0700 Subject: compiler monitorig/tuning In-Reply-To: References: Message-ID: Hi Brian Could you explain what problems you are observing? Which JDK 8 update version you are testing? On 6/16/16 11:00 AM, Brian Toal wrote: > Good day, > > - How do I monitor the length of the compiler queues (client and server)? I want to understand the backlog (if any) to > determine if the application could benefit from more compilation threads. There is -XX:+PrintTieredEvents flag which outputs on display queues sizes for each compilation request (a lot of output). > > - I remember in the past being able to get detailed compiler statistics from a mbean or something where the metric was > prefixed with java.ci and it contained execution count, total time, thread count exec for the client > and server compilers. Where can I find this data in realtime for monitoring purposes? If I know the total time and > thread count I suppose I can work out if the utilization of the compilation threads. May be it was jvmstat monitoring utility (now jstat). But it does not collect queues sizes. > > - What other compilation metrics should I be paying close attention to? Very detailed compilation output file is created (on JVM exit) with -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation. You can build this output parser tool from sources in http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ba5ca8b6e48f/src/share/tools/LogCompilation (note it is jdk 9, for 8 update build from clone of http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/). > > - Other than tiered compilation becoming the default in Java 8, where there any significant changes that would have > slowed down compilation time? We've had -XX:-TieredCompilation set in Java 7 and 8 and haven't touched any other JIT > related config. Was there some other setting default that changed which we would have needed to change when going fro 7 > to 8? Looking at the various compiler parameters that I know about via PrintFlagsFinal from 7 and 8, there doesn't seem > to be any change other than -XX:-TieredCompilation. There were a lot of changes which could affected JIT compilation speed. > > Regards, > - Brian Regards, Vladimir From paul.sandoz at oracle.com Wed Jun 22 09:34:34 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 22 Jun 2016 11:34:34 +0200 Subject: RFR 8154737: Rename VarHandle.compareAndExchangeVolatile to VarHandle.compareAndExchange Message-ID: <2B6EC19F-03D1-492A-A409-9B7C6CABE9F5@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154737-vh-cae-volatile-rename/webrev/ This patch renames VarHandle.compareAndExchangeVolatile to VarHandle.compareAndExchange so the naming scheme is consistent with compareAndSet, and is also a little shorter. The patch is based off hs-comp to keep in sync with other recently pushed changes and avoid possible merging issues. Hence why hotspot-compiler-dev is included, although there are no changes to hotspot. CCC is approved. This issue is granted an FC exception under JEP 193. I created a follow on issue to rename the internal Unsafe methods. https://bugs.openjdk.java.net/browse/JDK-8159995 But we can do that post 9. Thanks, 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 volker.simonis at gmail.com Wed Jun 22 09:38:17 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Jun 2016 11:38:17 +0200 Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions In-Reply-To: References: <09d3ebc7433941a0a48c82ac274a76d5@DEWDFE13DE09.global.corp.sap> Message-ID: Sure. I've just send out the request for approval: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-June/005626.html Should be there in a few days. Regards, Volker On Tue, Jun 21, 2016 at 6:34 PM, Tiago Daitx wrote: > Hi, > > I have seen this fix being applied to OpenJDK 9. As Gustavo said, it > applies cleanly to jdk8u as well and would be great to have that fix > there. Is there any plan to backport it? > > Regards, > Tiago > > > On Thu, Jun 16, 2016 at 12:02 PM, Lindenmaier, Goetz > wrote: >> Hi Volker, >> >> I've looked at the change, it's fine. Thanks for fixing this. >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >>> bounces at openjdk.java.net] On Behalf Of Volker Simonis >>> Sent: Dienstag, 14. Juni 2016 20:12 >>> To: hotspot compiler ; ppc-aix- >>> port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net >>> Cc: Hiroshi H Horii ; Gustavo Romero >>> >>> Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the >>> generation of illegal instructions >>> >>> Hi, >>> >>> can I please get a review for this small change which fixes a code >>> generation problem on ppc64: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ >>> https://bugs.openjdk.java.net/browse/JDK-8158260 >>> >>> In the case where we access an unaligned address trough Unsafe, we >>> could generate an illegal instruction because we didn't correctly >>> specify the memory operand of some match rules. The fix is trivial. >>> >>> Although this change is ppc64-specific I think I need a sponsor >>> because the change contains a new regression test which is supposed to >>> run on all platforms. >>> >>> On platforms where Unsafe.unalignedAccess() will return false (e.g. >>> Solaris/SPARC) this test will return immediately (and I've verified >>> that it works). >>> >>> I've also added aarch64 to the list of recipients because on aarch64 >>> Unsafe.unalignedAccess() is apparently supported and it would be nice >>> if somebody could check that the new regression test is indeed working >>> there. >>> >>> @Hiroshi, Gustavo: could you please verify that this change is enough >>> to fix the initial problems you've observed when running Cassandra on >>> Linux/ppc64? The changes from ppc64.ad should easily apply to the >>> 8u-dev repository. Once we've got this into jdk9 I'll trigger a >>> downport request to get the fix into jdk8 as well. >>> >>> Thank you and best regards, >>> Volker > > > > -- > Tiago St?rmer Daitx > Software Engineer > tiago.daitx at canonical.com > > PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) > Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE From leonid.mesnik at oracle.com Wed Jun 22 10:05:45 2016 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Wed, 22 Jun 2016 13:05:45 +0300 Subject: RFR(XXS): JDK-8158581: ciReplay can not be run w/ JFR enabled In-Reply-To: <50ED545C-5589-4D81-89B7-3F296691E0E2@oracle.com> References: <5767EF0C.6000503@oracle.com> <50ED545C-5589-4D81-89B7-3F296691E0E2@oracle.com> Message-ID: <576A62F9.8030603@oracle.com> Thank you for review. Leonid On 21.06.2016 19:39, Igor Ignatyev wrote: > Hi Leonid, > > looks good to me, thanks for fixing that. > > ? Igor >> On Jun 20, 2016, at 4:26 PM, Leonid Mesnik wrote: >> >> Hi >> >> Could you please review following small fix which disable execution of ciReplay tests with JFR enabled. >> Webrev: http://cr.openjdk.java.net/~lmesnik/8158581/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8158581 >> >> I verified that tests are skipped when FlightRecorer is enabled and executed otherwise. >> >> Leonid From aleksey.shipilev at oracle.com Wed Jun 22 10:34:08 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 22 Jun 2016 13:34:08 +0300 Subject: RFR 8154737: Rename VarHandle.compareAndExchangeVolatile to VarHandle.compareAndExchange In-Reply-To: <2B6EC19F-03D1-492A-A409-9B7C6CABE9F5@oracle.com> References: <2B6EC19F-03D1-492A-A409-9B7C6CABE9F5@oracle.com> Message-ID: <576A69A0.70508@oracle.com> On 06/22/2016 12:34 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154737-vh-cae-volatile-rename/webrev/ +1 -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 martin.doerr at sap.com Wed Jun 22 11:06:17 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 22 Jun 2016 11:06:17 +0000 Subject: RFR(L) 8159976: PPC64: Add missing intrinsics for sub-word atomics Message-ID: Hi, after JDK-8157726 was pushed, the JVM supports intrinsics for sub-word atomics. I have adapted the PPC64 implementation: http://cr.openjdk.java.net/~mdoerr/8159976_PPC64_subword_atomics/webrev.00/ The change also removes old String intrinsics which are no longer needed (since the new ones are available). Please review. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at redhat.com Wed Jun 22 12:18:05 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 22 Jun 2016 13:18:05 +0100 Subject: [aarch64-port-dev ] RFR: 8159063: aarch64: optimise unaligned array copy long In-Reply-To: <576953B8.4070601@redhat.com> References: <1465399545.18136.11.camel@mylittlepony.linaroharston> <57583B81.5020008@redhat.com> <576288AF.1030609@redhat.com> <1466171727.24673.5.camel@mint> <57694E51.9040907@redhat.com> <576953B8.4070601@redhat.com> Message-ID: <576A81FD.5090205@redhat.com> On 21/06/16 15:48, Andrew Haley wrote: > On 21/06/16 15:25, Andrew Dinn wrote: >> Andrew Haley, are you ok to go with this patch for JDK9 (once it is >> agreed that we can proceed)? > > Yes. Vladimir, Would it be possible to push this to JDK9 now? Andrew agrees that my revised version of Ed's patch is preferable (it's provided below as an export -- if you prefer I can provide a webrev). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- # HG changeset patch # User enevill # Date 1466073728 14400 # Thu Jun 16 06:42:08 2016 -0400 # Node ID 9570d342c207e43ce262a9466eb862e68e790c54 # Parent 385eae4265489a6b9f92b6cc6ab37467c8454563 8159063: aarch64: optimise unaligned array copy long Reviewed-by: aph, adinn diff -r 385eae426548 -r 9570d342c207 src/cpu/aarch64/vm/globals_aarch64.hpp --- a/src/cpu/aarch64/vm/globals_aarch64.hpp Wed Jun 15 12:44:20 2016 +0200 +++ b/src/cpu/aarch64/vm/globals_aarch64.hpp Thu Jun 16 06:42:08 2016 -0400 @@ -118,6 +118,7 @@ // Don't attempt to use Neon on builtin sim until builtin sim supports it #define UseCRC32 false #define UseSIMDForMemoryOps false +#define AvoidUnalignedAcesses false #else #define UseBuiltinSim false @@ -144,6 +145,8 @@ "Use CRC32 instructions for CRC32 computation") \ product(bool, UseSIMDForMemoryOps, false, \ "Use SIMD instructions in generated memory move code") \ + product(bool, AvoidUnalignedAccesses, false, \ + "Avoid generating unaligned memory accesses") \ product(bool, UseLSE, false, \ "Use LSE instructions") \ product(bool, UseBlockZeroing, true, \ diff -r 385eae426548 -r 9570d342c207 src/cpu/aarch64/vm/stubGenerator_aarch64.cpp --- a/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Wed Jun 15 12:44:20 2016 +0200 +++ b/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Thu Jun 16 06:42:08 2016 -0400 @@ -801,6 +801,12 @@ StubCodeMark mark(this, "StubRoutines", stub_name); __ align(CodeEntryAlignment); __ bind(start); + + Label unaligned_copy_long; + if (AvoidUnalignedAccesses) { + __ tbnz(d, 3, unaligned_copy_long); + } + if (direction == copy_forwards) { __ sub(s, s, bias); __ sub(d, d, bias); @@ -901,6 +907,198 @@ } __ ret(lr); + + if (AvoidUnalignedAccesses) { + Label drain, again; + // Register order for storing. Order is different for backward copy. + + __ bind(unaligned_copy_long); + + // source address is even aligned, target odd aligned + // + // when forward copying word pairs we read long pairs at offsets + // {0, 2, 4, 6} (in long words). when backwards copying we read + // long pairs at offsets {-2, -4, -6, -8}. We adjust the source + // address by -2 in the forwards case so we can compute the + // source offsets for both as {2, 4, 6, 8} * unit where unit = 1 + // or -1. + // + // when forward copying we need to store 1 word, 3 pairs and + // then 1 word at offsets {0, 1, 3, 5, 7}. Rather thna use a + // zero offset We adjust the destination by -1 which means we + // have to use offsets { 1, 2, 4, 6, 8} * unit for the stores. + // + // When backwards copyng we need to store 1 word, 3 pairs and + // then 1 word at offsets {-1, -3, -5, -7, -8} i.e. we use + // offsets {1, 3, 5, 7, 8} * unit. + + if (direction == copy_forwards) { + __ sub(s, s, 16); + __ sub(d, d, 8); + } + + // Fill 8 registers + // + // for forwards copy s was offset by -16 from the original input + // value of s so the register contents are at these offsets + // relative to the 64 bit block addressed by that original input + // and so on for each successive 64 byte block when s is updated + // + // t0 at offset 0, t1 at offset 8 + // t2 at offset 16, t3 at offset 24 + // t4 at offset 32, t5 at offset 40 + // t6 at offset 48, t7 at offset 56 + + // for backwards copy s was not offset so the register contents + // are at these offsets into the preceding 64 byte block + // relative to that original input and so on for each successive + // preceding 64 byte block when s is updated. this explains the + // slightly counter-intuitive looking pattern of register usage + // in the stp instructions for backwards copy. + // + // t0 at offset -16, t1 at offset -8 + // t2 at offset -32, t3 at offset -24 + // t4 at offset -48, t5 at offset -40 + // t6 at offset -64, t7 at offset -56 + + __ ldp(t0, t1, Address(s, 2 * unit)); + __ ldp(t2, t3, Address(s, 4 * unit)); + __ ldp(t4, t5, Address(s, 6 * unit)); + __ ldp(t6, t7, Address(__ pre(s, 8 * unit))); + + __ subs(count, count, 16); + __ br(Assembler::LO, drain); + + int prefetch = PrefetchCopyIntervalInBytes; + bool use_stride = false; + if (direction == copy_backwards) { + use_stride = prefetch > 256; + prefetch = -prefetch; + if (use_stride) __ mov(stride, prefetch); + } + + __ bind(again); + + if (PrefetchCopyIntervalInBytes > 0) + __ prfm(use_stride ? Address(s, stride) : Address(s, prefetch), PLDL1KEEP); + + if (direction == copy_forwards) { + // allowing for the offset of -8 the store instructions place + // registers into the target 64 bit block at the following + // offsets + // + // t0 at offset 0 + // t1 at offset 8, t2 at offset 16 + // t3 at offset 24, t4 at offset 32 + // t5 at offset 40, t6 at offset 48 + // t7 at offset 56 + + __ str(t0, Address(d, 1 * unit)); + __ stp(t1, t2, Address(d, 2 * unit)); + __ ldp(t0, t1, Address(s, 2 * unit)); + __ stp(t3, t4, Address(d, 4 * unit)); + __ ldp(t2, t3, Address(s, 4 * unit)); + __ stp(t5, t6, Address(d, 6 * unit)); + __ ldp(t4, t5, Address(s, 6 * unit)); + __ str(t7, Address(__ pre(d, 8 * unit))); + __ ldp(t6, t7, Address(__ pre(s, 8 * unit))); + } else { + // d was not offset when we started so the registers are + // written into the 64 bit block preceding d with the following + // offsets + // + // t1 at offset -8 + // t3 at offset -24, t0 at offset -16 + // t5 at offset -48, t2 at offset -32 + // t7 at offset -56, t4 at offset -48 + // t6 at offset -64 + // + // note that this matches the offsets previously noted for the + // loads + + __ str(t1, Address(d, 1 * unit)); + __ stp(t3, t0, Address(d, 3 * unit)); + __ ldp(t0, t1, Address(s, 2 * unit)); + __ stp(t5, t2, Address(d, 5 * unit)); + __ ldp(t2, t3, Address(s, 4 * unit)); + __ stp(t7, t4, Address(d, 7 * unit)); + __ ldp(t4, t5, Address(s, 6 * unit)); + __ str(t6, Address(__ pre(d, 8 * unit))); + __ ldp(t6, t7, Address(__ pre(s, 8 * unit))); + } + + __ subs(count, count, 8); + __ br(Assembler::HS, again); + + // Drain + // + // this uses the same pattern of offsets and register arguments + // as above + __ bind(drain); + if (direction == copy_forwards) { + __ str(t0, Address(d, 1 * unit)); + __ stp(t1, t2, Address(d, 2 * unit)); + __ stp(t3, t4, Address(d, 4 * unit)); + __ stp(t5, t6, Address(d, 6 * unit)); + __ str(t7, Address(__ pre(d, 8 * unit))); + } else { + __ str(t1, Address(d, 1 * unit)); + __ stp(t3, t0, Address(d, 3 * unit)); + __ stp(t5, t2, Address(d, 5 * unit)); + __ stp(t7, t4, Address(d, 7 * unit)); + __ str(t6, Address(__ pre(d, 8 * unit))); + } + // now we need to copy any remaining part block which may + // include a 4 word block subblock and/or a 2 word subblock. + // bits 2 and 1 in the count are the tell-tale for whetehr we + // have each such subblock + { + Label L1, L2; + __ tbz(count, exact_log2(4), L1); + // this is the same as above but copying only 4 longs hence + // with ony one intervening stp between the str instructions + // but note that the offsets and registers still follow the + // same pattern + __ ldp(t0, t1, Address(s, 2 * unit)); + __ ldp(t2, t3, Address(__ pre(s, 4 * unit))); + if (direction == copy_forwards) { + __ str(t0, Address(d, 1 * unit)); + __ stp(t1, t2, Address(d, 2 * unit)); + __ str(t3, Address(__ pre(d, 4 * unit))); + } else { + __ str(t1, Address(d, 1 * unit)); + __ stp(t3, t0, Address(d, 3 * unit)); + __ str(t2, Address(__ pre(d, 4 * unit))); + } + __ bind(L1); + + __ tbz(count, 1, L2); + // this is the same as above but copying only 2 longs hence + // there is no intervening stp between the str instructions + // but note that the offset and register patterns are still + // the same + __ ldp(t0, t1, Address(__ pre(s, 2 * unit))); + if (direction == copy_forwards) { + __ str(t0, Address(d, 1 * unit)); + __ str(t1, Address(__ pre(d, 2 * unit))); + } else { + __ str(t1, Address(d, 1 * unit)); + __ str(t0, Address(__ pre(d, 2 * unit))); + } + __ bind(L2); + + // for forwards copy we need to re-adjust the offsets we + // applied so that s and d are follow the last words written + + if (direction == copy_forwards) { + __ add(s, s, 16); + __ add(d, d, 8); + } + + } + + __ ret(lr); + } } // Small copy: less than 16 bytes. @@ -1024,11 +1222,9 @@ // (96 bytes if SIMD because we do 32 byes per instruction) __ bind(copy80); if (UseSIMDForMemoryOps) { - __ ldpq(v0, v1, Address(s, 0)); - __ ldpq(v2, v3, Address(s, 32)); + __ ld4(v0, v1, v2, v3, __ T16B, Address(s, 0)); __ ldpq(v4, v5, Address(send, -32)); - __ stpq(v0, v1, Address(d, 0)); - __ stpq(v2, v3, Address(d, 32)); + __ st4(v0, v1, v2, v3, __ T16B, Address(d, 0)); __ stpq(v4, v5, Address(dend, -32)); } else { __ ldp(t0, t1, Address(s, 0)); diff -r 385eae426548 -r 9570d342c207 src/cpu/aarch64/vm/vm_version_aarch64.cpp --- a/src/cpu/aarch64/vm/vm_version_aarch64.cpp Wed Jun 15 12:44:20 2016 +0200 +++ b/src/cpu/aarch64/vm/vm_version_aarch64.cpp Thu Jun 16 06:42:08 2016 -0400 @@ -175,7 +175,15 @@ } // Enable vendor specific features - if (_cpu == CPU_CAVIUM && _variant == 0) _features |= CPU_DMB_ATOMICS; + if (_cpu == CPU_CAVIUM) { + if (_variant == 0) _features |= CPU_DMB_ATOMICS; + if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { + FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); + } + if (FLAG_IS_DEFAULT(UseSIMDForMemoryOps)) { + FLAG_SET_DEFAULT(UseSIMDForMemoryOps, (_variant > 0)); + } + } if (_cpu == CPU_ARM && (_model == 0xd03 || _model2 == 0xd03)) _features |= CPU_A53MAC; if (_cpu == CPU_ARM && (_model == 0xd07 || _model2 == 0xd07)) _features |= CPU_STXR_PREFETCH; // If an olde style /proc/cpuinfo (cpu_lines == 1) then if _model is an A57 (0xd07) ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- From tobias.hartmann at oracle.com Wed Jun 22 13:22:46 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 22 Jun 2016 15:22:46 +0200 Subject: [9] RFR(S): 8159016: Over-unrolled loop is partially removed In-Reply-To: References: <57695B0E.3020001@oracle.com> Message-ID: <576A9126.7020802@oracle.com> Hi Vladimir, thanks for the review! On 21.06.2016 21:59, Vladimir Kozlov wrote: > Thank you, Tobias > > Your changes are good to have. > > You can still have a problem if unrolling is done before CCP phase which calculates array size and/or limit. > > Try to delay size calculation in test until CCP phase. Something like next (please, verify): > > // Simplified during CCP: > int size = 2; > for (; size < 4; size *= 2); > Object arr[] = new Object[size - 1]; With a similar piece of code, I'm able to delay size calculation to after CCP but then the out of bound stores are not removed because the trip count Phi has type "int" (instead of "int:>=1"). I think this is because the CastIINode::Value() optimization for CastIIs with _carry_dependency is not able to determine a more restricted type before CCP. > Why over-unrolling check code in IdealLoopTree::policy_unroll() does not work? The code after "// Protect against over-unrolling when init or/and limit are not constant" can only detect over-unrolling if the type of the iv-Phi is narrow enough. In this case, the Phi's type is "#int:>=1:www". > I think the trip count check before main loop should collapse whole main loop code. Then we will not have this problem. Why it is not collapsed? The trip count check before the main loop is guarded by Opaque nodes and not folded until after loop unrolling. I think it's also better to unroll the loop at least twice instead of over-unrolling and then removing the loop. > About test. > > You do & 3 two times: > > int lim = (arg & 3); > test(i & 3); > > Use 11_000 iterations because 10000 may not trigger compilation. Right, I already fixed this but accidentally uploaded an old version of the test. We actually don't even need 10_000 iterations because the test runs with -Xcomp to avoid gathering "too much" profiling information for the loop. A loop with 42 iterations (for some reason we need some iterations) triggers the problem 100% on my machine. > Let array escape to avoid EA. For example, return it. Done, but this triggers another problem: We now crash in PhaseMacroExpand::expand_allocate_common() in line 1600 while adding a membar after an InitializeNode because all memory users were removed. The problem is that now parts of the post loop are removed before we can determine that the entire loop is dead (and it is dead because the pre-loop executes one iteration and the unrolled main loop executes the remaining two iterations). The post loop is only removed after the Opaque1Node that guards the predicate is removed which happens later in macro expansion. I think it should be safe to just add a guard for != NULL like we do in PhaseMacroExpand::process_users_of_allocation(). I verified that the post loop is removed after the Opaque1Node goes away. New webrev: http://cr.openjdk.java.net/~thartmann/8159016/webrev.01/ I'm re-running the testing. Thanks, Tobias > > Thanks, > Vladimir > > On 6/21/16 8:19 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following fix: >> >> https://bugs.openjdk.java.net/browse/JDK-8159016 >> http://cr.openjdk.java.net/~thartmann/8159016/webrev.00/ >> >> I was able to reproduce the problem with a simple test: >> >> Object arr[] = new Object[3]; >> int lim = (arg & 3); >> for (int i = 0; i < lim; ++i) { >> arr[i] = new Object(); >> } >> >> The loop is split into pre, main and post loops. The pre loop is executed for at least one iteration, initializing arr[0]. The main loop is unrolled twice, initializing at least arr[1], arr[2], arr[3] and arr[4]. The arr[3] and arr[4] stores are always out of bounds and removed. However, C2 is unable to remove the "over-unrolled", dead main loop. As a result, there is a control path from the main loop to the PostScalarRce loop (see JDK-8151573) without a memory path since the last store was replaced by TOP. We crash because we use a memory edge from a non-dominating region. >> >> The out of bound stores in the over-unrolled loop are removed because their range check dependent CastII nodes are removed by the first optimization in CastIINode::Ideal(): >> CastII (AddI Phi 2) -> AddI (CastII Phi) 2 -> AddI TOP 2 >> >> The CastIINodes are replaced by TOP because the type of the loop Phi is >= 1 and the CastII is [1..2], i.e. there is no value >= 1 that is in the [1..2] range if +2 is added. >> >> The underlying problem is the over-unrolling of the loop. Since lim < 3, we always only execute at least 3 loop iterations. With the pre loop executing at least one iteration, the main loop should not be unrolled more than once. This problem is similar to JDK-4834191 where we over-unrolled a loop with a constant limit. >> >> I changed the implementation of IdealLoopTree::compute_exact_trip_count() to not only compute the exact trip count if the loop limit is constant but to also set the _trip_count field if we are able to determine an upper bound. Like this, the checks in IdealLoopTree::policy_unroll() prevent additional loop unrolling if the trip_count became too small and we keep the maximally unrolled version. >> >> An alternative fix would be to disable the CastII optimization for range check dependent CastII nodes but this does not fix the underlying problem of over-unrolling. >> >> Tested with regression test, JPRT and RBT (running). >> >> Thanks, >> Tobias >> From doug.simon at oracle.com Wed Jun 22 14:23:28 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 22 Jun 2016 16:23:28 +0200 Subject: RFR: 8159613: [Findbugs] various warnings reported for JVMCI sources In-Reply-To: <559A0E48-5DBA-4688-ABB3-D9602835622C@twitter.com> References: <559A0E48-5DBA-4688-ABB3-D9602835622C@twitter.com> Message-ID: <20C1A7CE-EA17-47E2-904A-2F57D00D6CAA@oracle.com> > On 22 Jun 2016, at 00:10, Christian Thalinger wrote: > > Why are we moving the static fields out of the inner classes in HotSpotMethodData? It makes it harder to understand. This was done to resolve initialization circularity warnings[1] such as: M D IC: Initialization circularity between jdk.vm.ci.hotspot.HotSpotMethodData and jdk.vm.ci.hotspot.HotSpotMethodData$ArgInfoData At HotSpotMethodData.java:[lines 47-913] However, I get your point about decreasing readability and so have moved the constants to just before the nested classes that they used to be declared in. At the same time, I got rid of the completely unnecessary jdk.vm.ci.hotspot.HotSpotMethodDataAccessor.Tag enum which added no value and further complicated understanding of the initialization sequence. These changes are in HotSpotMethodData.java and HotSpotMethodDataAccessor.java in this updated webrev: http://cr.openjdk.java.net/~dnsimon/8159613-v2/ -Doug [1] http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt > >> On Jun 20, 2016, at 1:00 PM, Doug Simon wrote: >> >> Please review this webrev which addresses all the issues[1] identified by FindBugs in the JVMCI Java code. A significant number of issues related to exposing array fields. For example: >> >> M V EI: jdk.vm.ci.hotspot.sparc.SPARCHotSpotRegisterConfig.getCallerSaveRegisters() may expose internal representation by returning SPARCHotSpotRegisterConfig.callerSaveRegisters At SPARCHotSpotRegisterConfig.java:[line 187] >> M V EI: jdk.vm.ci.amd64.AMD64.getAvailableValueRegisters() may expose internal representation by returning AMD64.valueRegistersSSE At AMD64.java:[line 252] >> >> These have been addressed by either creating an immutable array wrapper classes (e.g. RegisterArray) or by documenting intentional mutability and applying @SuppressFBWarnings where necessary. >> >> https://bugs.openjdk.java.net/browse/JDK-8159613 >> http://cr.openjdk.java.net/~dnsimon/8159613/ >> >> -Doug >> >> [1] http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt > From doug.simon at oracle.com Wed Jun 22 14:25:32 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 22 Jun 2016 16:25:32 +0200 Subject: RFR: 8159613: [Findbugs] various warnings reported for JVMCI sources In-Reply-To: References: Message-ID: > On 22 Jun 2016, at 00:18, Christian Thalinger wrote: > > src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java > > I guess the problem in getHostArchitectureName is the missing default case? I?d prefer something like this: > > - switch (arch) { > - case "x86_64": > return "amd64"; > - case "sparcv9": > return "sparc"; > default: > return arch; > } Also addressed in the v2 of the webrev. -Doug From aleksey.shipilev at oracle.com Wed Jun 22 15:15:56 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 22 Jun 2016 18:15:56 +0300 Subject: RFR(L) 8159976: PPC64: Add missing intrinsics for sub-word atomics In-Reply-To: References: Message-ID: <576AABAC.6010305@oracle.com> On 06/22/2016 02:06 PM, Doerr, Martin wrote: > http://cr.openjdk.java.net/~mdoerr/8159976_PPC64_subword_atomics/webrev.00/ With a cursory look, the changes look fine. 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 cthalinger at twitter.com Wed Jun 22 16:51:09 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 22 Jun 2016 09:51:09 -0700 Subject: RFR: 8159613: [Findbugs] various warnings reported for JVMCI sources In-Reply-To: <20C1A7CE-EA17-47E2-904A-2F57D00D6CAA@oracle.com> References: <559A0E48-5DBA-4688-ABB3-D9602835622C@twitter.com> <20C1A7CE-EA17-47E2-904A-2F57D00D6CAA@oracle.com> Message-ID: <155AE470-3E25-4944-8F7D-45C976FF855F@twitter.com> > On Jun 22, 2016, at 7:23 AM, Doug Simon wrote: > > >> On 22 Jun 2016, at 00:10, Christian Thalinger wrote: >> >> Why are we moving the static fields out of the inner classes in HotSpotMethodData? It makes it harder to understand. > > This was done to resolve initialization circularity warnings[1] such as: > > M D IC: Initialization circularity between jdk.vm.ci.hotspot.HotSpotMethodData and jdk.vm.ci.hotspot.HotSpotMethodData$ArgInfoData At HotSpotMethodData.java:[lines 47-913] > > However, I get your point about decreasing readability and so have moved the constants to just before the nested classes that they used to be declared in. Yes, that?s better. > At the same time, I got rid of the completely unnecessary jdk.vm.ci.hotspot.HotSpotMethodDataAccessor.Tag enum which added no value and further complicated understanding of the initialization sequence. Good. > These changes are in HotSpotMethodData.java and HotSpotMethodDataAccessor.java in this updated webrev: > > http://cr.openjdk.java.net/~dnsimon/8159613-v2/ > > -Doug > > [1] http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt > >> >>> On Jun 20, 2016, at 1:00 PM, Doug Simon wrote: >>> >>> Please review this webrev which addresses all the issues[1] identified by FindBugs in the JVMCI Java code. A significant number of issues related to exposing array fields. For example: >>> >>> M V EI: jdk.vm.ci.hotspot.sparc.SPARCHotSpotRegisterConfig.getCallerSaveRegisters() may expose internal representation by returning SPARCHotSpotRegisterConfig.callerSaveRegisters At SPARCHotSpotRegisterConfig.java:[line 187] >>> M V EI: jdk.vm.ci.amd64.AMD64.getAvailableValueRegisters() may expose internal representation by returning AMD64.valueRegistersSSE At AMD64.java:[line 252] >>> >>> These have been addressed by either creating an immutable array wrapper classes (e.g. RegisterArray) or by documenting intentional mutability and applying @SuppressFBWarnings where necessary. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8159613 >>> http://cr.openjdk.java.net/~dnsimon/8159613/ >>> >>> -Doug >>> >>> [1] http://cr.openjdk.java.net/~dnsimon/8159613/FindBugsIssues.txt >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cthalinger at twitter.com Wed Jun 22 16:51:19 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 22 Jun 2016 09:51:19 -0700 Subject: RFR: 8159613: [Findbugs] various warnings reported for JVMCI sources In-Reply-To: References: Message-ID: <9C4D513B-046D-49E9-9ABF-67699E53FE17@twitter.com> > On Jun 22, 2016, at 7:25 AM, Doug Simon wrote: > >> >> On 22 Jun 2016, at 00:18, Christian Thalinger wrote: >> >> src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java >> >> I guess the problem in getHostArchitectureName is the missing default case? I?d prefer something like this: >> >> - switch (arch) { >> - case "x86_64": >> return "amd64"; >> - case "sparcv9": >> return "sparc"; >> default: >> return arch; >> } > > Also addressed in the v2 of the web rev. Thanks. Looks good. > > -Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris.molodenkov at oracle.com Wed Jun 22 17:02:06 2016 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Wed, 22 Jun 2016 20:02:06 +0300 Subject: [8u] RFR: JDK-8151722: TESTBUG: New test compiler/native/TestDirtyInt.sh should be modified Message-ID: <576AC48E.5000902@oracle.com> Hi All, Could you please review fix? Fixed string comparison and indentation. JBS: https://bugs.openjdk.java.net/browse/JDK-8151722 Webrev: http://cr.openjdk.java.net/~bmoloden/8151722/webrev.00/ Thanks, Boris From rahul.v.raghavan at oracle.com Wed Jun 22 17:20:25 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 22 Jun 2016 10:20:25 -0700 (PDT) Subject: RFR: 8153194: PreserveFPRegistersTest.java runs out of memory in the nightlies Message-ID: <47ea70f9-e79e-45c7-9e77-7de9c7cdd5fa@default> Hi, Please review the following test fix patch for JDK-8153194. : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.00/ Notes: https://bugs.openjdk.java.net/browse/JDK-8153194 - PreserveFPRegistersTest.java runs out of memory in the nightlies https://bugs.openjdk.java.net/browse/JDK-8148175 - C1: G1 barriers don't preserve FP registers - 'hotspot/test/compiler/gcbarriers/PreserveFPRegistersTest.java' was added as part of the old JDK-8148175 fix. - The 'PreserveFPRegistersTest.java' started failing in nightly tests for 64-bit targets only with -XX:-UseCompressedOops enabled. - Found wrong hard coded usage of reference size as 32 bits in test caused OutOfMemoryError, for -XX:-UseCompressedOops cases. Changes done - - Actual fix of setting reference size using WhiteBox.getHeapOopSize() and removed @ignore. - Used WhiteBox.g1RegionSize() instead of hard coded value. - Used -Xmx300m instead of -Xmx128m for run VM options. (found this change is required for the test to fail correctly using old JDK9 builds prior to JDK-8148175 fix. e.g.: for test to fail with "java.lang.AssertionError: Final value has changed: 0.0 != 6.0" using JDK9-b113. Please note same -Xmx300m used for failing case reported in JDK-8148175. - Added diagnostic output. Testing done - - Confirmed revised test fails as expected using old jdk9 builds prior to JDK-8148175 fix (e.g.: JDK9-b113) >> [Test finished: compiler/gcbarriers/PreserveFPRegistersTest.java: Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Final value has changed: 0.0 != 6.0] (for default run and with -XX:-UseCompressedOops) - Confirmed revised test is passing for latest source build (.i.e. with JDK-8148175 fix, starting from JDK9-b114) (with and without -XX:-UseCompressedOops) Thanks, Rahul From dmitrij.pochepko at oracle.com Wed Jun 22 17:26:05 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 22 Jun 2016 20:26:05 +0300 Subject: RFR(S): 8159730 - compiler/jvmci/compilerToVM/IsMatureTest failed with "Multiple times invoked method should have method data (assert failed: 0 != 0)" In-Reply-To: <1321d153-866a-6c46-cc25-c09302ec5499@oracle.com> References: <57682B0C.20909@oracle.com> <57693E7E.8030006@oracle.com> <1321d153-866a-6c46-cc25-c09302ec5499@oracle.com> Message-ID: <576ACA2D.2060505@oracle.com> Thank you! On 21.06.2016 23:17, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 6/21/16 6:17 AM, Dmitrij Pochepko wrote: >> Hi, >> >> I've prepared v02 with slightly another wording in comment to improve >> readability: >> http://cr.openjdk.java.net/~dpochepk/8159730/webrev.02/ >> >> Thanks, >> Dmitrij >>> Hi, >>> >>> please review fix for 8159730 - >>> compiler/jvmci/compilerToVM/IsMatureTest failed with "Multiple times >>> invoked method >>> should have method data (assert failed: 0 != 0)" >>> >>> This test sometimes fails because it expects test method to have >>> method data object even in case it's compiled at >>> level 1(or even running in interpreter mode). >>> >>> I've added guard to disable last checks for compilation level 0 and 1. >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8159730/webrev.01/ >>> >>> (somehow webrev haven't saved indentation, so, it's probably easier >>> to look at diff directly: >>> http://cr.openjdk.java.net/~dpochepk/8159730/webrev.01/hotspot.patch) >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8159730 >>> >>> I've tested these changes locally on linux-x64 (including >>> -XX:TieredStopAtLevel=1 mode). >>> >>> Thanks, >>> Dmitrij >> From vladimir.x.ivanov at oracle.com Wed Jun 22 18:16:25 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 22 Jun 2016 21:16:25 +0300 Subject: RFR: 8153194: PreserveFPRegistersTest.java runs out of memory in the nightlies In-Reply-To: <47ea70f9-e79e-45c7-9e77-7de9c7cdd5fa@default> References: <47ea70f9-e79e-45c7-9e77-7de9c7cdd5fa@default> Message-ID: <99835b15-d289-d6d5-4815-34bc86f2e7ab@oracle.com> Thanks for taking care of the bug, Rahul. > Please review the following test fix patch for JDK-8153194. > : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.00/ + * @run main ClassFileInstaller sun.hotspot.WhiteBox + * @run main/othervm/timeout=300 -XX:+UnlockDiagnosticVMOptions + * -XX:+WhiteBoxAPI -Xbatch -Xbootclasspath/a:. You can use "@run main/bootclasspath/othervm" instead. + long regionSize = wb.g1RegionSize(); What happens if G1 isn't used? Either explicitly specify -XX:+UseG1GC or use @requires. Otherwise, looks good. Best regards, Vladimir Ivanov > > > Notes: > > https://bugs.openjdk.java.net/browse/JDK-8153194 - PreserveFPRegistersTest.java runs out of memory in the nightlies > https://bugs.openjdk.java.net/browse/JDK-8148175 - C1: G1 barriers don't preserve FP registers > > - 'hotspot/test/compiler/gcbarriers/PreserveFPRegistersTest.java' was added as part of the old JDK-8148175 fix. > - The 'PreserveFPRegistersTest.java' started failing in nightly tests for 64-bit targets only with -XX:-UseCompressedOops enabled. > - Found wrong hard coded usage of reference size as 32 bits in test caused OutOfMemoryError, for -XX:-UseCompressedOops cases. > > Changes done - > - Actual fix of setting reference size using WhiteBox.getHeapOopSize() and removed @ignore. > - Used WhiteBox.g1RegionSize() instead of hard coded value. > - Used -Xmx300m instead of -Xmx128m for run VM options. > (found this change is required for the test to fail correctly using old JDK9 builds prior to JDK-8148175 fix. > e.g.: for test to fail with "java.lang.AssertionError: Final value has changed: 0.0 != 6.0" using JDK9-b113. > Please note same -Xmx300m used for failing case reported in JDK-8148175. > - Added diagnostic output. > > Testing done - > - Confirmed revised test fails as expected using old jdk9 builds prior to JDK-8148175 fix (e.g.: JDK9-b113) > >> [Test finished: compiler/gcbarriers/PreserveFPRegistersTest.java: Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Final value has changed: 0.0 != 6.0] > (for default run and with -XX:-UseCompressedOops) > > - Confirmed revised test is passing for latest source build (.i.e. with JDK-8148175 fix, starting from JDK9-b114) > (with and without -XX:-UseCompressedOops) > > > Thanks, > Rahul > From vladimir.kozlov at oracle.com Wed Jun 22 19:45:22 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2016 12:45:22 -0700 Subject: [9] RFR(S): 8159016: Over-unrolled loop is partially removed In-Reply-To: <576A9126.7020802@oracle.com> References: <57695B0E.3020001@oracle.com> <576A9126.7020802@oracle.com> Message-ID: <12f80807-7b61-46ec-dd6a-97524f433b9e@oracle.com> On 6/22/16 6:22 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review! > > On 21.06.2016 21:59, Vladimir Kozlov wrote: >> Thank you, Tobias >> >> Your changes are good to have. >> >> You can still have a problem if unrolling is done before CCP phase which calculates array size and/or limit. >> >> Try to delay size calculation in test until CCP phase. Something like next (please, verify): >> >> // Simplified during CCP: >> int size = 2; >> for (; size < 4; size *= 2); >> Object arr[] = new Object[size - 1]; > > With a similar piece of code, I'm able to delay size calculation to after CCP but then the out of bound stores are not removed because the trip count Phi has type "int" (instead of "int:>=1"). I think this is because the CastIINode::Value() optimization for CastIIs with _carry_dependency is not able to determine a more restricted type before CCP. Got it. > >> Why over-unrolling check code in IdealLoopTree::policy_unroll() does not work? > > The code after "// Protect against over-unrolling when init or/and limit are not constant" can only detect over-unrolling if the type of the iv-Phi is narrow enough. In this case, the Phi's type is "#int:>=1:www". Should we enhance this check? > >> I think the trip count check before main loop should collapse whole main loop code. Then we will not have this problem. Why it is not collapsed? > > The trip count check before the main loop is guarded by Opaque nodes and not folded until after loop unrolling. I think it's also better to unroll the loop at least twice instead of over-unrolling and then removing the loop. Okay. > >> About test. >> >> You do & 3 two times: >> >> int lim = (arg & 3); >> test(i & 3); >> >> Use 11_000 iterations because 10000 may not trigger compilation. > > Right, I already fixed this but accidentally uploaded an old version of the test. We actually don't even need 10_000 iterations because the test runs with -Xcomp to avoid gathering "too much" profiling information for the loop. A loop with 42 iterations (for some reason we need some iterations) triggers the problem 100% on my machine. Good. > >> Let array escape to avoid EA. For example, return it. > > Done, but this triggers another problem: We now crash in PhaseMacroExpand::expand_allocate_common() in line 1600 while adding a membar after an InitializeNode because all memory users were removed. The problem is that now parts of the post loop are removed before we can determine that the entire loop is dead (and it is dead because the pre-loop executes one iteration and the unrolled main loop executes the remaining two iterations). The post loop is only removed after the Opaque1Node that guards the predicate is removed which happens later in macro expansion. Hmm, all Opaque nodes are removed before allocation node expansion. But may be it does not enough to collapse post loop which looks like happens only during IGVN transformation after all expansions. But this should not happen. Allocation is done before loop and there are stores in pre-loop and main-loop which should be memory users of allocation. Are those stores collected by InitializeNode? In such case your changes are good (let IGVN code decide about MB removal). > > I think it should be safe to just add a guard for != NULL like we do in PhaseMacroExpand::process_users_of_allocation(). I verified that the post loop is removed after the Opaque1Node goes away. > > New webrev: > http://cr.openjdk.java.net/~thartmann/8159016/webrev.01/ Good. > > I'm re-running the testing. Add testing link to the bug report. Thanks, Vladimir > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >> On 6/21/16 8:19 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following fix: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8159016 >>> http://cr.openjdk.java.net/~thartmann/8159016/webrev.00/ >>> >>> I was able to reproduce the problem with a simple test: >>> >>> Object arr[] = new Object[3]; >>> int lim = (arg & 3); >>> for (int i = 0; i < lim; ++i) { >>> arr[i] = new Object(); >>> } >>> >>> The loop is split into pre, main and post loops. The pre loop is executed for at least one iteration, initializing arr[0]. The main loop is unrolled twice, initializing at least arr[1], arr[2], arr[3] and arr[4]. The arr[3] and arr[4] stores are always out of bounds and removed. However, C2 is unable to remove the "over-unrolled", dead main loop. As a result, there is a control path from the main loop to the PostScalarRce loop (see JDK-8151573) without a memory path since the last store was replaced by TOP. We crash because we use a memory edge from a non-dominating region. >>> >>> The out of bound stores in the over-unrolled loop are removed because their range check dependent CastII nodes are removed by the first optimization in CastIINode::Ideal(): >>> CastII (AddI Phi 2) -> AddI (CastII Phi) 2 -> AddI TOP 2 >>> >>> The CastIINodes are replaced by TOP because the type of the loop Phi is >= 1 and the CastII is [1..2], i.e. there is no value >= 1 that is in the [1..2] range if +2 is added. >>> >>> The underlying problem is the over-unrolling of the loop. Since lim < 3, we always only execute at least 3 loop iterations. With the pre loop executing at least one iteration, the main loop should not be unrolled more than once. This problem is similar to JDK-4834191 where we over-unrolled a loop with a constant limit. >>> >>> I changed the implementation of IdealLoopTree::compute_exact_trip_count() to not only compute the exact trip count if the loop limit is constant but to also set the _trip_count field if we are able to determine an upper bound. Like this, the checks in IdealLoopTree::policy_unroll() prevent additional loop unrolling if the trip_count became too small and we keep the maximally unrolled version. >>> >>> An alternative fix would be to disable the CastII optimization for range check dependent CastII nodes but this does not fix the underlying problem of over-unrolling. >>> >>> Tested with regression test, JPRT and RBT (running). >>> >>> Thanks, >>> Tobias >>> From vladimir.kozlov at oracle.com Wed Jun 22 19:50:12 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2016 12:50:12 -0700 Subject: [8u] RFR: JDK-8151722: TESTBUG: New test compiler/native/TestDirtyInt.sh should be modified In-Reply-To: <576AC48E.5000902@oracle.com> References: <576AC48E.5000902@oracle.com> Message-ID: <3db2443a-3a2e-6b5f-5751-847d6f143bf4@oracle.com> Looks good. Thanks, Vladimir On 6/22/16 10:02 AM, Boris Molodenkov wrote: > Hi All, > > Could you please review fix? > Fixed string comparison and indentation. > JBS: https://bugs.openjdk.java.net/browse/JDK-8151722 > Webrev: http://cr.openjdk.java.net/~bmoloden/8151722/webrev.00/ > > Thanks, > Boris > From tobias.hartmann at oracle.com Thu Jun 23 07:10:16 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Jun 2016 09:10:16 +0200 Subject: [8u] RFR(S): 8160122: Backport of JDK-8159244 uses wrong version of the JDK 9 fix Message-ID: <576B8B58.7000500@oracle.com> Hi, while backporting 8159244 [1] to JDK 8u, I accidentally used an old version of the webrev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/3e2abbf1320d This is the correct webrev: http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01/ Please review the following change that fixes this: https://bugs.openjdk.java.net/browse/JDK-8160122 http://cr.openjdk.java.net/~thartmann/8160122/webrev.00/ Sorry for the mess, I should have merged the JDK 9 changeset. Thanks and best regards, Tobias [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eadc4ebb7755 From tobias.hartmann at oracle.com Thu Jun 23 07:13:54 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Jun 2016 09:13:54 +0200 Subject: [8u] RFR(S): 8160122: Backport of JDK-8159244 uses wrong version of the JDK 9 fix In-Reply-To: <576B8B58.7000500@oracle.com> References: <576B8B58.7000500@oracle.com> Message-ID: <576B8C32.6040408@oracle.com> [CC'ing jdk8u-dev] On 23.06.2016 09:10, Tobias Hartmann wrote: > Hi, > > while backporting 8159244 [1] to JDK 8u, I accidentally used an old version of the webrev: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/3e2abbf1320d > This is the correct webrev: > http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01/ > > Please review the following change that fixes this: > https://bugs.openjdk.java.net/browse/JDK-8160122 > http://cr.openjdk.java.net/~thartmann/8160122/webrev.00/ > > Sorry for the mess, I should have merged the JDK 9 changeset. > > Thanks and best regards, > Tobias > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eadc4ebb7755 From tobias.hartmann at oracle.com Thu Jun 23 08:33:35 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Jun 2016 10:33:35 +0200 Subject: [9] RFR(S): 8159016: Over-unrolled loop is partially removed In-Reply-To: <12f80807-7b61-46ec-dd6a-97524f433b9e@oracle.com> References: <57695B0E.3020001@oracle.com> <576A9126.7020802@oracle.com> <12f80807-7b61-46ec-dd6a-97524f433b9e@oracle.com> Message-ID: <576B9EDF.6010408@oracle.com> Hi Vladimir, On 22.06.2016 21:45, Vladimir Kozlov wrote: > On 6/22/16 6:22 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> On 21.06.2016 21:59, Vladimir Kozlov wrote: >>> Thank you, Tobias >>> >>> Your changes are good to have. >>> >>> You can still have a problem if unrolling is done before CCP phase which calculates array size and/or limit. >>> >>> Try to delay size calculation in test until CCP phase. Something like next (please, verify): >>> >>> // Simplified during CCP: >>> int size = 2; >>> for (; size < 4; size *= 2); >>> Object arr[] = new Object[size - 1]; >> >> With a similar piece of code, I'm able to delay size calculation to after CCP but then the out of bound stores are not removed because the trip count Phi has type "int" (instead of "int:>=1"). I think this is because the CastIINode::Value() optimization for CastIIs with _carry_dependency is not able to determine a more restricted type before CCP. > > Got it. > >> >>> Why over-unrolling check code in IdealLoopTree::policy_unroll() does not work? >> >> The code after "// Protect against over-unrolling when init or/and limit are not constant" can only detect over-unrolling if the type of the iv-Phi is narrow enough. In this case, the Phi's type is "#int:>=1:www". > > Should we enhance this check? I'm not sure how. The problem is that we don't have enough type information about the loop Phi because the loop predicate is guarded by OpaqueNodes. We know that the pre-loop is executed once and therefore the initial value of the main loop induction variable is 1, but we are unable to determine the maximum number of iterations (hence "#int:>=1:www"). >>> I think the trip count check before main loop should collapse whole main loop code. Then we will not have this problem. Why it is not collapsed? >> >> The trip count check before the main loop is guarded by Opaque nodes and not folded until after loop unrolling. I think it's also better to unroll the loop at least twice instead of over-unrolling and then removing the loop. > > Okay. > > >> >>> About test. >>> >>> You do & 3 two times: >>> >>> int lim = (arg & 3); >>> test(i & 3); >>> >>> Use 11_000 iterations because 10000 may not trigger compilation. >> >> Right, I already fixed this but accidentally uploaded an old version of the test. We actually don't even need 10_000 iterations because the test runs with -Xcomp to avoid gathering "too much" profiling information for the loop. A loop with 42 iterations (for some reason we need some iterations) triggers the problem 100% on my machine. > > Good. > >> >>> Let array escape to avoid EA. For example, return it. >> >> Done, but this triggers another problem: We now crash in PhaseMacroExpand::expand_allocate_common() in line 1600 while adding a membar after an InitializeNode because all memory users were removed. The problem is that now parts of the post loop are removed before we can determine that the entire loop is dead (and it is dead because the pre-loop executes one iteration and the unrolled main loop executes the remaining two iterations). The post loop is only removed after the Opaque1Node that guards the predicate is removed which happens later in macro expansion. > > Hmm, all Opaque nodes are removed before allocation node expansion. But may be it does not enough to collapse post loop which looks like happens only during IGVN transformation after all expansions. Yes, the post loop only collapses after IGVN (i.e. after macro node expansion). > But this should not happen. Allocation is done before loop and there are stores in pre-loop and main-loop which should be memory users of allocation. Are those stores collected by InitializeNode? In such case your changes are good (let IGVN code decide about MB removal). Actually, the InitializeNode belongs to the "new Object()" allocation *in* the loop. The StoreNNode stores this new Object in arr[i]. Because the store is removed before the loop is collapsed, the InitializeNode has no memory users and the barrier insertion code fails. I think it should be safe to ignore this and let the subsequent IGVN remove the barrier. >> I think it should be safe to just add a guard for != NULL like we do in PhaseMacroExpand::process_users_of_allocation(). I verified that the post loop is removed after the Opaque1Node goes away. >> >> New webrev: >> http://cr.openjdk.java.net/~thartmann/8159016/webrev.01/ > > Good. > >> >> I'm re-running the testing. > > Add testing link to the bug report. Sure, done (no new failures). Best regards, Tobias > > Thanks, > Vladimir > >> >> Thanks, >> Tobias >> >>> >>> Thanks, >>> Vladimir >>> >>> On 6/21/16 8:19 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following fix: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8159016 >>>> http://cr.openjdk.java.net/~thartmann/8159016/webrev.00/ >>>> >>>> I was able to reproduce the problem with a simple test: >>>> >>>> Object arr[] = new Object[3]; >>>> int lim = (arg & 3); >>>> for (int i = 0; i < lim; ++i) { >>>> arr[i] = new Object(); >>>> } >>>> >>>> The loop is split into pre, main and post loops. The pre loop is executed for at least one iteration, initializing arr[0]. The main loop is unrolled twice, initializing at least arr[1], arr[2], arr[3] and arr[4]. The arr[3] and arr[4] stores are always out of bounds and removed. However, C2 is unable to remove the "over-unrolled", dead main loop. As a result, there is a control path from the main loop to the PostScalarRce loop (see JDK-8151573) without a memory path since the last store was replaced by TOP. We crash because we use a memory edge from a non-dominating region. >>>> >>>> The out of bound stores in the over-unrolled loop are removed because their range check dependent CastII nodes are removed by the first optimization in CastIINode::Ideal(): >>>> CastII (AddI Phi 2) -> AddI (CastII Phi) 2 -> AddI TOP 2 >>>> >>>> The CastIINodes are replaced by TOP because the type of the loop Phi is >= 1 and the CastII is [1..2], i.e. there is no value >= 1 that is in the [1..2] range if +2 is added. >>>> >>>> The underlying problem is the over-unrolling of the loop. Since lim < 3, we always only execute at least 3 loop iterations. With the pre loop executing at least one iteration, the main loop should not be unrolled more than once. This problem is similar to JDK-4834191 where we over-unrolled a loop with a constant limit. >>>> >>>> I changed the implementation of IdealLoopTree::compute_exact_trip_count() to not only compute the exact trip count if the loop limit is constant but to also set the _trip_count field if we are able to determine an upper bound. Like this, the checks in IdealLoopTree::policy_unroll() prevent additional loop unrolling if the trip_count became too small and we keep the maximally unrolled version. >>>> >>>> An alternative fix would be to disable the CastII optimization for range check dependent CastII nodes but this does not fix the underlying problem of over-unrolling. >>>> >>>> Tested with regression test, JPRT and RBT (running). >>>> >>>> Thanks, >>>> Tobias >>>> From volker.simonis at gmail.com Thu Jun 23 08:43:11 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Jun 2016 10:43:11 +0200 Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions In-Reply-To: References: <09d3ebc7433941a0a48c82ac274a76d5@DEWDFE13DE09.global.corp.sap> Message-ID: I've just pushed the fix to jdk8u-dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/6021c95f5944 Regards, Volker On Wed, Jun 22, 2016 at 11:38 AM, Volker Simonis wrote: > Sure. I've just send out the request for approval: > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-June/005626.html > > Should be there in a few days. > > Regards, > Volker > > On Tue, Jun 21, 2016 at 6:34 PM, Tiago Daitx wrote: >> Hi, >> >> I have seen this fix being applied to OpenJDK 9. As Gustavo said, it >> applies cleanly to jdk8u as well and would be great to have that fix >> there. Is there any plan to backport it? >> >> Regards, >> Tiago >> >> >> On Thu, Jun 16, 2016 at 12:02 PM, Lindenmaier, Goetz >> wrote: >>> Hi Volker, >>> >>> I've looked at the change, it's fine. Thanks for fixing this. >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >>>> bounces at openjdk.java.net] On Behalf Of Volker Simonis >>>> Sent: Dienstag, 14. Juni 2016 20:12 >>>> To: hotspot compiler ; ppc-aix- >>>> port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net >>>> Cc: Hiroshi H Horii ; Gustavo Romero >>>> >>>> Subject: RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the >>>> generation of illegal instructions >>>> >>>> Hi, >>>> >>>> can I please get a review for this small change which fixes a code >>>> generation problem on ppc64: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ >>>> https://bugs.openjdk.java.net/browse/JDK-8158260 >>>> >>>> In the case where we access an unaligned address trough Unsafe, we >>>> could generate an illegal instruction because we didn't correctly >>>> specify the memory operand of some match rules. The fix is trivial. >>>> >>>> Although this change is ppc64-specific I think I need a sponsor >>>> because the change contains a new regression test which is supposed to >>>> run on all platforms. >>>> >>>> On platforms where Unsafe.unalignedAccess() will return false (e.g. >>>> Solaris/SPARC) this test will return immediately (and I've verified >>>> that it works). >>>> >>>> I've also added aarch64 to the list of recipients because on aarch64 >>>> Unsafe.unalignedAccess() is apparently supported and it would be nice >>>> if somebody could check that the new regression test is indeed working >>>> there. >>>> >>>> @Hiroshi, Gustavo: could you please verify that this change is enough >>>> to fix the initial problems you've observed when running Cassandra on >>>> Linux/ppc64? The changes from ppc64.ad should easily apply to the >>>> 8u-dev repository. Once we've got this into jdk9 I'll trigger a >>>> downport request to get the fix into jdk8 as well. >>>> >>>> Thank you and best regards, >>>> Volker >> >> >> >> -- >> Tiago St?rmer Daitx >> Software Engineer >> tiago.daitx at canonical.com >> >> PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) >> Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE From goetz.lindenmaier at sap.com Thu Jun 23 09:29:44 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Jun 2016 09:29:44 +0000 Subject: RFR(L) 8159976: PPC64: Add missing intrinsics for sub-word atomics In-Reply-To: References: Message-ID: Hi Martin, I had a look at your changes. Thanks for doing all this, it's quite a piece of code! It took me a while to understand how you distinguish for older processor types ... I matched "instruction_type" on the size handled by the instruction right away, but not that you then use it to decide that you have to emulate the instructions for small sizes. Maybe you could !has_lqarx() or at least comment the if statement. Also, you properly sign extend the 1/2 byte values that are loaded with the Zero-extending l?arx instructions. Is this correct for Java chars? Or do these need to be handled unsigned? In the ad file, you say: // Variable size: instruction count smaller if regs are disjoint. Don't you want to enforce that by adding effect "TEMP_DEF dst"? Especially as you save a branch in that case. In some match rules this should hold already ad there is the TEMP_DEF effect specified. Besides that the code looks good. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > Sent: Mittwoch, 22. Juni 2016 13:06 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR(L) 8159976: PPC64: Add missing intrinsics for sub-word atomics > > Hi, > > > > after JDK-8157726 was pushed, the JVM supports intrinsics for sub-word > atomics. > > > > I have adapted the PPC64 implementation: > > http://cr.openjdk.java.net/~mdoerr/8159976_PPC64_subword_atomics/we > brev.00/ > ebrev.00/> > > > > The change also removes old String intrinsics which are no longer needed > (since the new ones are available). > > > > Please review. > > > > Best regards, > > Martin > > From martin.doerr at sap.com Thu Jun 23 12:13:58 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 23 Jun 2016 12:13:58 +0000 Subject: RFR(L) 8159976: PPC64: Add missing intrinsics for sub-word atomics In-Reply-To: References: Message-ID: Hi Aleksey and G?tz, thank you very much for reviewing. @G?tz: I have added comments as you requested. I also changed the compareAndSwap effects such that the result has a TEMP_DEF effect. This avoids the jump instruction and the variable length. New webrev is here: http://cr.openjdk.java.net/~mdoerr/8159976_PPC64_subword_atomics/webrev.01/ Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Donnerstag, 23. Juni 2016 11:30 To: Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net Subject: RE: RFR(L) 8159976: PPC64: Add missing intrinsics for sub-word atomics Hi Martin, I had a look at your changes. Thanks for doing all this, it's quite a piece of code! It took me a while to understand how you distinguish for older processor types ... I matched "instruction_type" on the size handled by the instruction right away, but not that you then use it to decide that you have to emulate the instructions for small sizes. Maybe you could !has_lqarx() or at least comment the if statement. Also, you properly sign extend the 1/2 byte values that are loaded with the Zero-extending l?arx instructions. Is this correct for Java chars? Or do these need to be handled unsigned? In the ad file, you say: // Variable size: instruction count smaller if regs are disjoint. Don't you want to enforce that by adding effect "TEMP_DEF dst"? Especially as you save a branch in that case. In some match rules this should hold already ad there is the TEMP_DEF effect specified. Besides that the code looks good. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > Sent: Mittwoch, 22. Juni 2016 13:06 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR(L) 8159976: PPC64: Add missing intrinsics for sub-word atomics > > Hi, > > > > after JDK-8157726 was pushed, the JVM supports intrinsics for sub-word > atomics. > > > > I have adapted the PPC64 implementation: > > http://cr.openjdk.java.net/~mdoerr/8159976_PPC64_subword_atomics/we > brev.00/ > ebrev.00/> > > > > The change also removes old String intrinsics which are no longer needed > (since the new ones are available). > > > > Please review. > > > > Best regards, > > Martin > > From goetz.lindenmaier at sap.com Thu Jun 23 12:34:41 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Jun 2016 12:34:41 +0000 Subject: RFR(L) 8159976: PPC64: Add missing intrinsics for sub-word atomics In-Reply-To: References: Message-ID: <5cb0f14a982248c0b596c8306d20bb41@DEWDFE13DE09.global.corp.sap> Hi Martin, thanks for doing these fixes. Looks perfect now. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Donnerstag, 23. Juni 2016 14:14 > To: Lindenmaier, Goetz ; hotspot-compiler- > dev at openjdk.java.net; Aleksey Shipilev (aleksey.shipilev at oracle.com) > > Subject: RE: RFR(L) 8159976: PPC64: Add missing intrinsics for sub-word > atomics > > Hi Aleksey and G?tz, > > thank you very much for reviewing. > > @G?tz: I have added comments as you requested. I also changed the > compareAndSwap effects such that the result has a TEMP_DEF effect. This > avoids the jump instruction and the variable length. > > New webrev is here: > http://cr.openjdk.java.net/~mdoerr/8159976_PPC64_subword_atomics/we > brev.01/ > > Best regards, > Martin > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 23. Juni 2016 11:30 > To: Doerr, Martin ; hotspot-compiler- > dev at openjdk.java.net > Subject: RE: RFR(L) 8159976: PPC64: Add missing intrinsics for sub-word > atomics > > Hi Martin, > > I had a look at your changes. Thanks for doing all this, it's quite > a piece of code! > > It took me a while to understand how you distinguish for older > processor types ... I matched "instruction_type" on the size handled > by the instruction right away, but not that you then use it to decide > that you have to emulate the instructions for small sizes. > > Maybe you could !has_lqarx() or at least comment the if statement. > > Also, you properly sign extend the 1/2 byte values that are loaded with the > Zero-extending l?arx instructions. Is this correct for Java chars? > Or do these need to be handled unsigned? > > In the ad file, you say: > // Variable size: instruction count smaller if regs are disjoint. > Don't you want to enforce that by adding effect "TEMP_DEF dst"? > Especially as you save a branch in that case. In some match rules > this should hold already ad there is the TEMP_DEF effect specified. > > Besides that the code looks good. > > Best regards, > Goetz. > > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > > Sent: Mittwoch, 22. Juni 2016 13:06 > > To: hotspot-compiler-dev at openjdk.java.net > > Subject: RFR(L) 8159976: PPC64: Add missing intrinsics for sub-word atomics > > > > Hi, > > > > > > > > after JDK-8157726 was pushed, the JVM supports intrinsics for sub-word > > atomics. > > > > > > > > I have adapted the PPC64 implementation: > > > > > http://cr.openjdk.java.net/~mdoerr/8159976_PPC64_subword_atomics/we > > brev.00/ > > > > ebrev.00/> > > > > > > > > The change also removes old String intrinsics which are no longer needed > > (since the new ones are available). > > > > > > > > Please review. > > > > > > > > Best regards, > > > > Martin > > > > From roland.schatz at oracle.com Thu Jun 23 15:53:34 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Thu, 23 Jun 2016 17:53:34 +0200 Subject: RFR(XS): 8160177: [JVMCI] race condition in HotSpotMemoryAccessProviderImpl.verifyReadRawObject Message-ID: <95289252-00bb-f0fd-5b7c-86ab5054c310@oracle.com> Hi, Please review this small bugfix: http://cr.openjdk.java.net/~rschatz/JDK-8160177/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8160177 This assertion doesn't really make sense, we're just reading the same value twice and asserting it's equal. - Roland From doug.simon at oracle.com Thu Jun 23 15:55:47 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 23 Jun 2016 17:55:47 +0200 Subject: RFR: 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI Message-ID: JVMCI cannot be initialized until after VM init phase 3 as it requires the jdk.vm.ci module to be available (phase 2) and ServiceLoader to be working (phase 3). This change moves the eager initialization of JVMCI (under the condition of !UseInterpreter || !BackgroundCompilation) to be after phase 3 as well as causing JVMCI compilations before phase 3 to be ignored. Thanks to Tom for most of this code! https://bugs.openjdk.java.net/browse/JDK-8160121 http://cr.openjdk.java.net/~dnsimon/8160121/ -Doug From pavel.punegov at oracle.com Thu Jun 23 17:04:14 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Thu, 23 Jun 2016 20:04:14 +0300 Subject: RFR (XXS): 8160085: @library' must appear before first `@run' Message-ID: Hi, please review this small fix that places @ignore after the @library. webrev: http://cr.openjdk.java.net/~ppunegov/8160085/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8160085 ? Thanks, Pavel Punegov -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Jun 23 17:06:19 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jun 2016 10:06:19 -0700 Subject: RFR: 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI In-Reply-To: References: Message-ID: <5162b163-3dfc-3571-187d-b534c1994667@oracle.com> Looks good. Thanks, Vladimir On 6/23/16 8:55 AM, Doug Simon wrote: > JVMCI cannot be initialized until after VM init phase 3 as it requires the jdk.vm.ci module to be available (phase 2) and ServiceLoader to be working (phase 3). This change moves the eager initialization of JVMCI (under the condition of !UseInterpreter || !BackgroundCompilation) to be after phase 3 as well as causing JVMCI compilations before phase 3 to be ignored. > > Thanks to Tom for most of this code! > > https://bugs.openjdk.java.net/browse/JDK-8160121 > http://cr.openjdk.java.net/~dnsimon/8160121/ > > -Doug > From vladimir.kozlov at oracle.com Thu Jun 23 17:09:02 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jun 2016 10:09:02 -0700 Subject: RFR (XXS): 8160085: @library' must appear before first `@run' In-Reply-To: References: Message-ID: <8a355bf5-a3f0-556d-3a09-4c1f4cd4e9cb@oracle.com> Looks good. Thanks, Vladimir On 6/23/16 10:04 AM, Pavel Punegov wrote: > Hi, > > please review this small fix that places @ignore after the @library. > > webrev: http://cr.openjdk.java.net/~ppunegov/8160085/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8160085 > > ? Thanks, > Pavel Punegov > From tatiana.pivovarova at oracle.com Thu Jun 23 17:19:37 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Thu, 23 Jun 2016 20:19:37 +0300 Subject: [9] RFR(S): 8143081: [ctw] Test CompileTheWorld.java needs to be updated for Jigsaw Message-ID: <576C1A29.3020804@oracle.com> Hi guys! Please review this patch To run CompileTheWorld harness with new jdk9 it is need to add compatibility to read .jimage files and to remove hardcoded links to rt.jar and "sun.boot.class.path" property. bug: https://bugs.openjdk.java.net/browse/JDK-8143081 webrev: http://cr.openjdk.java.net/~tpivovarova/8143081/webrev.01/ Tested locally by compilation lib/modules. Thanks, Tatiana -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Jun 23 17:32:32 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jun 2016 10:32:32 -0700 Subject: [8u] RFR(S): 8160122: Backport of JDK-8159244 uses wrong version of the JDK 9 fix In-Reply-To: <576B8C32.6040408@oracle.com> References: <576B8B58.7000500@oracle.com> <576B8C32.6040408@oracle.com> Message-ID: <38d5c0af-cf9e-5c7a-db92-25c023e47aa1@oracle.com> Changes are good. Reviewed. Thanks, Vladimir On 6/23/16 12:13 AM, Tobias Hartmann wrote: > [CC'ing jdk8u-dev] > > On 23.06.2016 09:10, Tobias Hartmann wrote: >> Hi, >> >> while backporting 8159244 [1] to JDK 8u, I accidentally used an old version of the webrev: >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/3e2abbf1320d >> This is the correct webrev: >> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01/ >> >> Please review the following change that fixes this: >> https://bugs.openjdk.java.net/browse/JDK-8160122 >> http://cr.openjdk.java.net/~thartmann/8160122/webrev.00/ >> >> Sorry for the mess, I should have merged the JDK 9 changeset. >> >> Thanks and best regards, >> Tobias >> >> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eadc4ebb7755 From tom.rodriguez at oracle.com Thu Jun 23 17:34:57 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 23 Jun 2016 10:34:57 -0700 Subject: RFR 8160197: [JVMCI] AllocatableValue.toString overrides are missing reference information Message-ID: <35A12331-46FE-4605-875A-0808BA82B249@oracle.com> http://cr.openjdk.java.net/~never/8160197/webrev When printing Values the current code restricts the information to a single character which cuts out any information about whether a type is a reference or not. Instead Value should allow subclasses more control over what is printed for the type information. In current graal this means instead of ?rax|q? you?ll see ?rax|QWORD[.]? for a reference type. This also makes the platform dependent types more obvious since you don?t have to guess what ?q? means. tom From vladimir.kozlov at oracle.com Thu Jun 23 17:38:34 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jun 2016 10:38:34 -0700 Subject: RFR 8160197: [JVMCI] AllocatableValue.toString overrides are missing reference information In-Reply-To: <35A12331-46FE-4605-875A-0808BA82B249@oracle.com> References: <35A12331-46FE-4605-875A-0808BA82B249@oracle.com> Message-ID: <0de11a80-ce00-84d8-134f-bdc13cdb1796@oracle.com> Good. Thanks, Vladimir On 6/23/16 10:34 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8160197/webrev > > When printing Values the current code restricts the information to a single character which cuts out any information about whether a type is a reference or not. Instead Value should allow subclasses more control over what is printed for the type information. In current graal this means instead of ?rax|q? you?ll see ?rax|QWORD[.]? for a reference type. This also makes the platform dependent types more obvious since you don?t have to guess what ?q? means. > > tom > From vladimir.kozlov at oracle.com Thu Jun 23 17:45:52 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jun 2016 10:45:52 -0700 Subject: RFR(XS): 8160177: [JVMCI] race condition in HotSpotMemoryAccessProviderImpl.verifyReadRawObject In-Reply-To: <95289252-00bb-f0fd-5b7c-86ab5054c310@oracle.com> References: <95289252-00bb-f0fd-5b7c-86ab5054c310@oracle.com> Message-ID: <103773f2-7457-2da0-4717-99b6df4d4ee0@oracle.com> Seems good. Thanks, Vladimir On 6/23/16 8:53 AM, Roland Schatz wrote: > Hi, > > Please review this small bugfix: > http://cr.openjdk.java.net/~rschatz/JDK-8160177/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8160177 > > This assertion doesn't really make sense, we're just reading the same value twice and asserting it's equal. > > - Roland > From vladimir.kozlov at oracle.com Thu Jun 23 18:29:06 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jun 2016 11:29:06 -0700 Subject: [9] RFR(S): 8159016: Over-unrolled loop is partially removed In-Reply-To: <576B9EDF.6010408@oracle.com> References: <57695B0E.3020001@oracle.com> <576A9126.7020802@oracle.com> <12f80807-7b61-46ec-dd6a-97524f433b9e@oracle.com> <576B9EDF.6010408@oracle.com> Message-ID: <826b8f92-bcdc-484f-680b-afe367cf9d8c@oracle.com> On 6/23/16 1:33 AM, Tobias Hartmann wrote: > Hi Vladimir, > > On 22.06.2016 21:45, Vladimir Kozlov wrote: >> On 6/22/16 6:22 AM, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> thanks for the review! >>> >>> On 21.06.2016 21:59, Vladimir Kozlov wrote: >>>> Thank you, Tobias >>>> >>>> Your changes are good to have. >>>> >>>> You can still have a problem if unrolling is done before CCP phase which calculates array size and/or limit. >>>> >>>> Try to delay size calculation in test until CCP phase. Something like next (please, verify): >>>> >>>> // Simplified during CCP: >>>> int size = 2; >>>> for (; size < 4; size *= 2); >>>> Object arr[] = new Object[size - 1]; >>> >>> With a similar piece of code, I'm able to delay size calculation to after CCP but then the out of bound stores are not removed because the trip count Phi has type "int" (instead of "int:>=1"). I think this is because the CastIINode::Value() optimization for CastIIs with _carry_dependency is not able to determine a more restricted type before CCP. >> >> Got it. >> >>> >>>> Why over-unrolling check code in IdealLoopTree::policy_unroll() does not work? >>> >>> The code after "// Protect against over-unrolling when init or/and limit are not constant" can only detect over-unrolling if the type of the iv-Phi is narrow enough. In this case, the Phi's type is "#int:>=1:www". >> >> Should we enhance this check? > > I'm not sure how. The problem is that we don't have enough type information about the loop Phi because the loop predicate is guarded by OpaqueNodes. We know that the pre-loop is executed once and therefore the initial value of the main loop induction variable is 1, but we are unable to determine the maximum number of iterations (hence "#int:>=1:www"). Okay, agree that we can do nothing if type is not more concrete. > >>>> I think the trip count check before main loop should collapse whole main loop code. Then we will not have this problem. Why it is not collapsed? >>> >>> The trip count check before the main loop is guarded by Opaque nodes and not folded until after loop unrolling. I think it's also better to unroll the loop at least twice instead of over-unrolling and then removing the loop. >> >> Okay. >> >> >>> >>>> About test. >>>> >>>> You do & 3 two times: >>>> >>>> int lim = (arg & 3); >>>> test(i & 3); >>>> >>>> Use 11_000 iterations because 10000 may not trigger compilation. >>> >>> Right, I already fixed this but accidentally uploaded an old version of the test. We actually don't even need 10_000 iterations because the test runs with -Xcomp to avoid gathering "too much" profiling information for the loop. A loop with 42 iterations (for some reason we need some iterations) triggers the problem 100% on my machine. >> >> Good. >> >>> >>>> Let array escape to avoid EA. For example, return it. >>> >>> Done, but this triggers another problem: We now crash in PhaseMacroExpand::expand_allocate_common() in line 1600 while adding a membar after an InitializeNode because all memory users were removed. The problem is that now parts of the post loop are removed before we can determine that the entire loop is dead (and it is dead because the pre-loop executes one iteration and the unrolled main loop executes the remaining two iterations). The post loop is only removed after the Opaque1Node that guards the predicate is removed which happens later in macro expansion. >> >> Hmm, all Opaque nodes are removed before allocation node expansion. But may be it does not enough to collapse post loop which looks like happens only during IGVN transformation after all expansions. > > Yes, the post loop only collapses after IGVN (i.e. after macro node expansion). OK. > >> But this should not happen. Allocation is done before loop and there are stores in pre-loop and main-loop which should be memory users of allocation. Are those stores collected by InitializeNode? In such case your changes are good (let IGVN code decide about MB removal). > > Actually, the InitializeNode belongs to the "new Object()" allocation *in* the loop. The StoreNNode stores this new Object in arr[i]. Because the store is removed before the loop is collapsed, the InitializeNode has no memory users and the barrier insertion code fails. I think it should be safe to ignore this and let the subsequent IGVN remove the barrier. Can you confirm that MB is removed by IGVN? > >>> I think it should be safe to just add a guard for != NULL like we do in PhaseMacroExpand::process_users_of_allocation(). I verified that the post loop is removed after the Opaque1Node goes away. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~thartmann/8159016/webrev.01/ >> >> Good. >> >>> >>> I'm re-running the testing. >> >> Add testing link to the bug report. > > Sure, done (no new failures). Good. Thanks, Vladimir > > Best regards, > Tobias > >> >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> Tobias >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/21/16 8:19 AM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following fix: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8159016 >>>>> http://cr.openjdk.java.net/~thartmann/8159016/webrev.00/ >>>>> >>>>> I was able to reproduce the problem with a simple test: >>>>> >>>>> Object arr[] = new Object[3]; >>>>> int lim = (arg & 3); >>>>> for (int i = 0; i < lim; ++i) { >>>>> arr[i] = new Object(); >>>>> } >>>>> >>>>> The loop is split into pre, main and post loops. The pre loop is executed for at least one iteration, initializing arr[0]. The main loop is unrolled twice, initializing at least arr[1], arr[2], arr[3] and arr[4]. The arr[3] and arr[4] stores are always out of bounds and removed. However, C2 is unable to remove the "over-unrolled", dead main loop. As a result, there is a control path from the main loop to the PostScalarRce loop (see JDK-8151573) without a memory path since the last store was replaced by TOP. We crash because we use a memory edge from a non-dominating region. >>>>> >>>>> The out of bound stores in the over-unrolled loop are removed because their range check dependent CastII nodes are removed by the first optimization in CastIINode::Ideal(): >>>>> CastII (AddI Phi 2) -> AddI (CastII Phi) 2 -> AddI TOP 2 >>>>> >>>>> The CastIINodes are replaced by TOP because the type of the loop Phi is >= 1 and the CastII is [1..2], i.e. there is no value >= 1 that is in the [1..2] range if +2 is added. >>>>> >>>>> The underlying problem is the over-unrolling of the loop. Since lim < 3, we always only execute at least 3 loop iterations. With the pre loop executing at least one iteration, the main loop should not be unrolled more than once. This problem is similar to JDK-4834191 where we over-unrolled a loop with a constant limit. >>>>> >>>>> I changed the implementation of IdealLoopTree::compute_exact_trip_count() to not only compute the exact trip count if the loop limit is constant but to also set the _trip_count field if we are able to determine an upper bound. Like this, the checks in IdealLoopTree::policy_unroll() prevent additional loop unrolling if the trip_count became too small and we keep the maximally unrolled version. >>>>> >>>>> An alternative fix would be to disable the CastII optimization for range check dependent CastII nodes but this does not fix the underlying problem of over-unrolling. >>>>> >>>>> Tested with regression test, JPRT and RBT (running). >>>>> >>>>> Thanks, >>>>> Tobias >>>>> From rahul.v.raghavan at oracle.com Thu Jun 23 18:38:36 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 23 Jun 2016 11:38:36 -0700 (PDT) Subject: RFR: 8153194: PreserveFPRegistersTest.java runs out of memory in the nightlies In-Reply-To: <99835b15-d289-d6d5-4815-34bc86f2e7ab@oracle.com> References: <47ea70f9-e79e-45c7-9e77-7de9c7cdd5fa@default> <99835b15-d289-d6d5-4815-34bc86f2e7ab@oracle.com> Message-ID: <49e3dee1-bd9e-4947-b740-dc2c8b971cef@default> Hi, Thank you Vladimir for your comments. Yes, agree to your points and made the changes. Also additionally added @build (found required when tried the single test run in RBT) Please check the revised : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.01/ No issues found with local jtreg testing, RBT . Thanks, Rahul > -----Original Message----- > From: Vladimir Ivanov > Sent: Wednesday, June 22, 2016 11:46 PM > > Thanks for taking care of the bug, Rahul. > > > Please review the following test fix patch for JDK-8153194. > > : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.00/ > > + * @run main ClassFileInstaller sun.hotspot.WhiteBox > + * @run main/othervm/timeout=300 -XX:+UnlockDiagnosticVMOptions > + * -XX:+WhiteBoxAPI -Xbatch -Xbootclasspath/a:. > > You can use "@run main/bootclasspath/othervm" instead. > > > + long regionSize = wb.g1RegionSize(); > > What happens if G1 isn't used? Either explicitly specify -XX:+UseG1GC or > use @requires. > > Otherwise, looks good. > > Best regards, > Vladimir Ivanov > > > > > > > Notes: > > > > https://bugs.openjdk.java.net/browse/JDK-8153194 - PreserveFPRegistersTest.java runs out of memory in the nightlies > > https://bugs.openjdk.java.net/browse/JDK-8148175 - C1: G1 barriers don't preserve FP registers > > > > - 'hotspot/test/compiler/gcbarriers/PreserveFPRegistersTest.java' was added as part of the old JDK-8148175 fix. > > - The 'PreserveFPRegistersTest.java' started failing in nightly tests for 64-bit targets only with -XX:-UseCompressedOops enabled. > > - Found wrong hard coded usage of reference size as 32 bits in test caused OutOfMemoryError, for -XX:-UseCompressedOops > cases. > > > > Changes done - > > - Actual fix of setting reference size using WhiteBox.getHeapOopSize() and removed @ignore. > > - Used WhiteBox.g1RegionSize() instead of hard coded value. > > - Used -Xmx300m instead of -Xmx128m for run VM options. > > (found this change is required for the test to fail correctly using old JDK9 builds prior to JDK-8148175 fix. > > e.g.: for test to fail with "java.lang.AssertionError: Final value has changed: 0.0 != 6.0" using JDK9-b113. > > Please note same -Xmx300m used for failing case reported in JDK-8148175. > > - Added diagnostic output. > > > > Testing done - > > - Confirmed revised test fails as expected using old jdk9 builds prior to JDK-8148175 fix (e.g.: JDK9-b113) > > >> [Test finished: compiler/gcbarriers/PreserveFPRegistersTest.java: Failed. Execution failed: `main' threw exception: > java.lang.AssertionError: Final value has changed: 0.0 != 6.0] > > (for default run and with -XX:-UseCompressedOops) > > > > - Confirmed revised test is passing for latest source build (.i.e. with JDK-8148175 fix, starting from JDK9-b114) > > (with and without -XX:-UseCompressedOops) > > > > > > Thanks, > > Rahul > > From igor.veresov at oracle.com Fri Jun 24 05:47:45 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 23 Jun 2016 22:47:45 -0700 Subject: RFR(XXS) 8157249: [JVMCI] remove ConstantReflectionProvider.isEmbeddable method Message-ID: This is just a removal of an unused API. http://cr.openjdk.java.net/~iveresov/8157249/webrev.00/ Thanks, igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Jun 24 06:11:23 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Jun 2016 23:11:23 -0700 Subject: RFR(XXS) 8157249: [JVMCI] remove ConstantReflectionProvider.isEmbeddable method In-Reply-To: References: Message-ID: <2bb6639f-c738-eb18-2802-2205621dbc2e@oracle.com> Looks good. Thanks, Vladimir On 6/23/16 10:47 PM, Igor Veresov wrote: > This is just a removal of an unused API. > > http://cr.openjdk.java.net/~iveresov/8157249/webrev.00/ > > Thanks, > igor From tobias.hartmann at oracle.com Fri Jun 24 06:34:25 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 24 Jun 2016 08:34:25 +0200 Subject: [8u] RFR(S): 8160122: Backport of JDK-8159244 uses wrong version of the JDK 9 fix In-Reply-To: <38d5c0af-cf9e-5c7a-db92-25c023e47aa1@oracle.com> References: <576B8B58.7000500@oracle.com> <576B8C32.6040408@oracle.com> <38d5c0af-cf9e-5c7a-db92-25c023e47aa1@oracle.com> Message-ID: <576CD471.6030502@oracle.com> Thanks, Vladimir! Best regards, Tobias On 23.06.2016 19:32, Vladimir Kozlov wrote: > Changes are good. Reviewed. > > Thanks, > Vladimir > > On 6/23/16 12:13 AM, Tobias Hartmann wrote: >> [CC'ing jdk8u-dev] >> >> On 23.06.2016 09:10, Tobias Hartmann wrote: >>> Hi, >>> >>> while backporting 8159244 [1] to JDK 8u, I accidentally used an old version of the webrev: >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/3e2abbf1320d >>> This is the correct webrev: >>> http://cr.openjdk.java.net/~thartmann/8159244/webrev.8u.01/ >>> >>> Please review the following change that fixes this: >>> https://bugs.openjdk.java.net/browse/JDK-8160122 >>> http://cr.openjdk.java.net/~thartmann/8160122/webrev.00/ >>> >>> Sorry for the mess, I should have merged the JDK 9 changeset. >>> >>> Thanks and best regards, >>> Tobias >>> >>> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eadc4ebb7755 From igor.veresov at oracle.com Fri Jun 24 07:24:12 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 24 Jun 2016 00:24:12 -0700 Subject: RFR(XXS) 8157249: [JVMCI] remove ConstantReflectionProvider.isEmbeddable method In-Reply-To: <2bb6639f-c738-eb18-2802-2205621dbc2e@oracle.com> References: <2bb6639f-c738-eb18-2802-2205621dbc2e@oracle.com> Message-ID: Thanks, Vladimir! igor > On Jun 23, 2016, at 11:11 PM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 6/23/16 10:47 PM, Igor Veresov wrote: >> This is just a removal of an unused API. >> >> http://cr.openjdk.java.net/~iveresov/8157249/webrev.00/ >> >> Thanks, >> igor From igor.veresov at oracle.com Fri Jun 24 08:06:42 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 24 Jun 2016 01:06:42 -0700 Subject: RFR(XXS) 8157249: [JVMCI] remove ConstantReflectionProvider.isEmbeddable method In-Reply-To: References: <2bb6639f-c738-eb18-2802-2205621dbc2e@oracle.com> Message-ID: <1020643F-082A-4B12-BFDF-C4B18A1BED60@oracle.com> Sorry, forgot to remove the test: http://cr.openjdk.java.net/~iveresov/8157249/webrev.01/ igor > On Jun 24, 2016, at 12:24 AM, Igor Veresov wrote: > > Thanks, Vladimir! > > igor > >> On Jun 23, 2016, at 11:11 PM, Vladimir Kozlov wrote: >> >> Looks good. >> >> Thanks, >> Vladimir >> >> On 6/23/16 10:47 PM, Igor Veresov wrote: >>> This is just a removal of an unused API. >>> >>> http://cr.openjdk.java.net/~iveresov/8157249/webrev.00/ >>> >>> Thanks, >>> igor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.nevill at gmail.com Fri Jun 24 11:09:03 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 24 Jun 2016 12:09:03 +0100 Subject: [aarch64-port-dev ] RFR: 8159063: aarch64: optimise unaligned array copy long In-Reply-To: <576953B8.4070601@redhat.com> References: <1465399545.18136.11.camel@mylittlepony.linaroharston> <57583B81.5020008@redhat.com> <576288AF.1030609@redhat.com> <1466171727.24673.5.camel@mint> <57694E51.9040907@redhat.com> <576953B8.4070601@redhat.com> Message-ID: <1466766543.26023.4.camel@gmail.com> On Tue, 2016-06-21 at 15:48 +0100, Andrew Haley wrote: > On 21/06/16 15:25, Andrew Dinn wrote: > > > > Andrew Haley, are you ok to go with this patch for JDK9 (once it is > > agreed that we can proceed)? > Yes. Here is the updated webrev with Andrew Dinn's changes. http://cr.openjdk.java.net/~enevill/8159063/webrev_jdk9.01/ Now that it is approved as jdk9-fc-yes is it OK to push this? > > > > > Would this version be acceptable for backport to JDK8? > I guess so. And here is the backport for jdk8u. http://cr.openjdk.java.net/~enevill/8159063/webrev_jdk8u.01/ OK to push? Thanks, Ed. From tobias.hartmann at oracle.com Fri Jun 24 12:43:13 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 24 Jun 2016 14:43:13 +0200 Subject: [9] RFR(S): 8159016: Over-unrolled loop is partially removed In-Reply-To: <826b8f92-bcdc-484f-680b-afe367cf9d8c@oracle.com> References: <57695B0E.3020001@oracle.com> <576A9126.7020802@oracle.com> <12f80807-7b61-46ec-dd6a-97524f433b9e@oracle.com> <576B9EDF.6010408@oracle.com> <826b8f92-bcdc-484f-680b-afe367cf9d8c@oracle.com> Message-ID: <576D2AE1.4060005@oracle.com> Hi Vladimir, On 23.06.2016 20:29, Vladimir Kozlov wrote: > On 6/23/16 1:33 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> On 22.06.2016 21:45, Vladimir Kozlov wrote: >>> On 6/22/16 6:22 AM, Tobias Hartmann wrote: >>>> Hi Vladimir, >>>> >>>> thanks for the review! >>>> >>>> On 21.06.2016 21:59, Vladimir Kozlov wrote: >>>>> Thank you, Tobias >>>>> >>>>> Your changes are good to have. >>>>> >>>>> You can still have a problem if unrolling is done before CCP phase which calculates array size and/or limit. >>>>> >>>>> Try to delay size calculation in test until CCP phase. Something like next (please, verify): >>>>> >>>>> // Simplified during CCP: >>>>> int size = 2; >>>>> for (; size < 4; size *= 2); >>>>> Object arr[] = new Object[size - 1]; >>>> >>>> With a similar piece of code, I'm able to delay size calculation to after CCP but then the out of bound stores are not removed because the trip count Phi has type "int" (instead of "int:>=1"). I think this is because the CastIINode::Value() optimization for CastIIs with _carry_dependency is not able to determine a more restricted type before CCP. >>> >>> Got it. >>> >>>> >>>>> Why over-unrolling check code in IdealLoopTree::policy_unroll() does not work? >>>> >>>> The code after "// Protect against over-unrolling when init or/and limit are not constant" can only detect over-unrolling if the type of the iv-Phi is narrow enough. In this case, the Phi's type is "#int:>=1:www". >>> >>> Should we enhance this check? >> >> I'm not sure how. The problem is that we don't have enough type information about the loop Phi because the loop predicate is guarded by OpaqueNodes. We know that the pre-loop is executed once and therefore the initial value of the main loop induction variable is 1, but we are unable to determine the maximum number of iterations (hence "#int:>=1:www"). > > Okay, agree that we can do nothing if type is not more concrete. > >> >>>>> I think the trip count check before main loop should collapse whole main loop code. Then we will not have this problem. Why it is not collapsed? >>>> >>>> The trip count check before the main loop is guarded by Opaque nodes and not folded until after loop unrolling. I think it's also better to unroll the loop at least twice instead of over-unrolling and then removing the loop. >>> >>> Okay. >>> >>> >>>> >>>>> About test. >>>>> >>>>> You do & 3 two times: >>>>> >>>>> int lim = (arg & 3); >>>>> test(i & 3); >>>>> >>>>> Use 11_000 iterations because 10000 may not trigger compilation. >>>> >>>> Right, I already fixed this but accidentally uploaded an old version of the test. We actually don't even need 10_000 iterations because the test runs with -Xcomp to avoid gathering "too much" profiling information for the loop. A loop with 42 iterations (for some reason we need some iterations) triggers the problem 100% on my machine. >>> >>> Good. >>> >>>> >>>>> Let array escape to avoid EA. For example, return it. >>>> >>>> Done, but this triggers another problem: We now crash in PhaseMacroExpand::expand_allocate_common() in line 1600 while adding a membar after an InitializeNode because all memory users were removed. The problem is that now parts of the post loop are removed before we can determine that the entire loop is dead (and it is dead because the pre-loop executes one iteration and the unrolled main loop executes the remaining two iterations). The post loop is only removed after the Opaque1Node that guards the predicate is removed which happens later in macro expansion. >>> >>> Hmm, all Opaque nodes are removed before allocation node expansion. But may be it does not enough to collapse post loop which looks like happens only during IGVN transformation after all expansions. >> >> Yes, the post loop only collapses after IGVN (i.e. after macro node expansion). > > OK. > >> >>> But this should not happen. Allocation is done before loop and there are stores in pre-loop and main-loop which should be memory users of allocation. Are those stores collected by InitializeNode? In such case your changes are good (let IGVN code decide about MB removal). >> >> Actually, the InitializeNode belongs to the "new Object()" allocation *in* the loop. The StoreNNode stores this new Object in arr[i]. Because the store is removed before the loop is collapsed, the InitializeNode has no memory users and the barrier insertion code fails. I think it should be safe to ignore this and let the subsequent IGVN remove the barrier. > > Can you confirm that MB is removed by IGVN? I verified that the IGVN after macro expansion removes the entire post loop, i.e., the barrier is removed as well. Thanks, Tobias >>>> I think it should be safe to just add a guard for != NULL like we do in PhaseMacroExpand::process_users_of_allocation(). I verified that the post loop is removed after the Opaque1Node goes away. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~thartmann/8159016/webrev.01/ >>> >>> Good. >>> >>>> >>>> I'm re-running the testing. >>> >>> Add testing link to the bug report. >> >> Sure, done (no new failures). > > Good. > > Thanks, > Vladimir > >> >> Best regards, >> Tobias >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/21/16 8:19 AM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following fix: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8159016 >>>>>> http://cr.openjdk.java.net/~thartmann/8159016/webrev.00/ >>>>>> >>>>>> I was able to reproduce the problem with a simple test: >>>>>> >>>>>> Object arr[] = new Object[3]; >>>>>> int lim = (arg & 3); >>>>>> for (int i = 0; i < lim; ++i) { >>>>>> arr[i] = new Object(); >>>>>> } >>>>>> >>>>>> The loop is split into pre, main and post loops. The pre loop is executed for at least one iteration, initializing arr[0]. The main loop is unrolled twice, initializing at least arr[1], arr[2], arr[3] and arr[4]. The arr[3] and arr[4] stores are always out of bounds and removed. However, C2 is unable to remove the "over-unrolled", dead main loop. As a result, there is a control path from the main loop to the PostScalarRce loop (see JDK-8151573) without a memory path since the last store was replaced by TOP. We crash because we use a memory edge from a non-dominating region. >>>>>> >>>>>> The out of bound stores in the over-unrolled loop are removed because their range check dependent CastII nodes are removed by the first optimization in CastIINode::Ideal(): >>>>>> CastII (AddI Phi 2) -> AddI (CastII Phi) 2 -> AddI TOP 2 >>>>>> >>>>>> The CastIINodes are replaced by TOP because the type of the loop Phi is >= 1 and the CastII is [1..2], i.e. there is no value >= 1 that is in the [1..2] range if +2 is added. >>>>>> >>>>>> The underlying problem is the over-unrolling of the loop. Since lim < 3, we always only execute at least 3 loop iterations. With the pre loop executing at least one iteration, the main loop should not be unrolled more than once. This problem is similar to JDK-4834191 where we over-unrolled a loop with a constant limit. >>>>>> >>>>>> I changed the implementation of IdealLoopTree::compute_exact_trip_count() to not only compute the exact trip count if the loop limit is constant but to also set the _trip_count field if we are able to determine an upper bound. Like this, the checks in IdealLoopTree::policy_unroll() prevent additional loop unrolling if the trip_count became too small and we keep the maximally unrolled version. >>>>>> >>>>>> An alternative fix would be to disable the CastII optimization for range check dependent CastII nodes but this does not fix the underlying problem of over-unrolling. >>>>>> >>>>>> Tested with regression test, JPRT and RBT (running). >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> From aph at redhat.com Fri Jun 24 12:51:09 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Jun 2016 13:51:09 +0100 Subject: [aarch64-port-dev ] RFR: 8159063: aarch64: optimise unaligned array copy long In-Reply-To: <1466766543.26023.4.camel@gmail.com> References: <1465399545.18136.11.camel@mylittlepony.linaroharston> <57583B81.5020008@redhat.com> <576288AF.1030609@redhat.com> <1466171727.24673.5.camel@mint> <57694E51.9040907@redhat.com> <576953B8.4070601@redhat.com> <1466766543.26023.4.camel@gmail.com> Message-ID: <576D2CBD.6030707@redhat.com> On 24/06/16 12:09, Edward Nevill wrote: > Now that it is approved as jdk9-fc-yes is it OK to push this? I think so, if I understand the rules properly. > And here is the backport for jdk8u. > > http://cr.openjdk.java.net/~enevill/8159063/webrev_jdk8u.01/ > > OK to push? OK. Andrew. From goetz.lindenmaier at sap.com Fri Jun 24 14:30:02 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 24 Jun 2016 14:30:02 +0000 Subject: RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. Message-ID: <6725033e7f604e9899c93b2f1fa1be70@DEWDFE13DE09.global.corp.sap> Hi, c1_LIR.hpp defines a row of functions guarded by platform defines. This is bad style and hinders new platform ports. (I'm working on S390 aka Z :)) This change removes the majority of these defines. It introduces common headers, and moves implementations to c1_LIR_.cpp files. It guards single_softfp() and double_softfp() by __SOFTFP__. This is not used in any openJdk platform. I can not test this on the closed platforms ARM32 and PPC32. It removes the guard around the LIR_Address constructor. There is no point in guarding this code, verify() assures by assertions that it can not be misused. I also introduce a new constructor that leaves out the scale argument and introduced some usages on X86. This change also moves verify() to the new platform files. In the header, LIR_ADDRESS_PD_VERIFY was used to guard usage of pd_verify(). Neither of these are used in openJdk. If this define is used in the closed ports pd_verify() must be renamed to verify(). The code that was previously guarded by ARM, ARM32 or PPC32 is moved to a properly guarded section in c1_LIR.cpp. Actually, it should be moved to according new files c1_LIR_.cpp in the closed ports. But this way the change should basically work for the closed ports. I added fnoreg on x86 to note down the code similarly on all Platforms. I cleaned up a flag with a limited range on PPC_32. Please review this change. I please need a sponsor. https://bugs.openjdk.java.net/browse/JDK-8160245 I built and tested this on linuxx86_64, solaris_sparc and the ppc platforms. Best regards, Goetz -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Jun 24 14:34:53 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 24 Jun 2016 14:34:53 +0000 Subject: RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: <6725033e7f604e9899c93b2f1fa1be70@DEWDFE13DE09.global.corp.sap> References: <6725033e7f604e9899c93b2f1fa1be70@DEWDFE13DE09.global.corp.sap> Message-ID: Sorry, the webrev URL was missing, added below: Hi, c1_LIR.hpp defines a row of functions guarded by platform defines. This is bad style and hinders new platform ports. (I'm working on S390 aka Z :)) This change removes the majority of these defines. It introduces common headers, and moves implementations to c1_LIR_.cpp files. It guards single_softfp() and double_softfp() by __SOFTFP__. This is not used in any openJdk platform. I can not test this on the closed platforms ARM32 and PPC32. It removes the guard around the LIR_Address constructor. There is no point in guarding this code, verify() assures by assertions that it can not be misused. I also introduce a new constructor that leaves out the scale argument and introduced some usages on X86. This change also moves verify() to the new platform files. In the header, LIR_ADDRESS_PD_VERIFY was used to guard usage of pd_verify(). Neither of these are used in openJdk. If this define is used in the closed ports pd_verify() must be renamed to verify(). The code that was previously guarded by ARM, ARM32 or PPC32 is moved to a properly guarded section in c1_LIR.cpp. Actually, it should be moved to according new files c1_LIR_.cpp in the closed ports. But this way the change should basically work for the closed ports. I added fnoreg on x86 to note down the code similarly on all Platforms. I cleaned up a flag with a limited range on PPC_32. Please review this change. I please need a sponsor. https://bugs.openjdk.java.net/browse/JDK-8160245 http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.01/ I built and tested this on linuxx86_64, solaris_sparc and the ppc platforms. Best regards, Goetz From zoltan.majo at oracle.com Fri Jun 24 16:05:20 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 24 Jun 2016 18:05:20 +0200 Subject: [9] RFR (S): 8159431: C1 arraycopy intrinsic type checks missing Message-ID: <576D5A40.9080404@oracle.com> Hi, please review the patch for 8159431. https://bugs.openjdk.java.net/browse/JDK-8159431 Problem: The C1 intrinsic for java.lang.System.arraycopy(Object src, int srcPos, Object dest, int destPos, int length) does not verify that 'src' or 'dest' is a "proper" array. As a result, the intrinsic reads the non-existing 'length' field from java.lang.Object (i.e., the intrinsic reads past the end of the java.lang.Object instance), which is incorrect. Also, the intrinsic only checks if 'src' is a subclass of 'dest' before writing into 'dest' without checking the special case 'dest'==java.lang.Object. That can result in data being written to a random heap location instead of the required ArrayStoreException being thrown. Solution: Check the type of 'src' and 'dest' at runtime if the compiler was not able to prove at compile-time that 'src' and 'dest' are "proper" arrays. Webrev: http://cr.openjdk.java.net/~zmajo/8159431/webrev.00/ Testing: JPRT (testset hotspot). I'll do an RBT run once the code is close to its final shape. The problem was originally reported by Xiang Yuan from Linaro. Once the code is reviewed, I plan to push the patch with Xiang and myself as contributors. The open arm port and ppc are also likely to be affected. I'll file bugs for those architectures and notify persons working on the appropriate ports. Thank you! Best regards, Zoltan From pavel.punegov at oracle.com Fri Jun 24 16:07:21 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Fri, 24 Jun 2016 19:07:21 +0300 Subject: RFR (XXS): 8160085: @library' must appear before first `@run' In-Reply-To: <8a355bf5-a3f0-556d-3a09-4c1f4cd4e9cb@oracle.com> References: <8a355bf5-a3f0-556d-3a09-4c1f4cd4e9cb@oracle.com> Message-ID: Thank you, Vladimir > On 23 Jun 2016, at 20:09, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 6/23/16 10:04 AM, Pavel Punegov wrote: >> Hi, >> >> please review this small fix that places @ignore after the @library. >> >> webrev: http://cr.openjdk.java.net/~ppunegov/8160085/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8160085 >> >> ? Thanks, >> Pavel Punegov >> From igor.ignatyev at oracle.com Fri Jun 24 17:03:41 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 24 Jun 2016 20:03:41 +0300 Subject: [9] RFR(S): 8143081: [ctw] Test CompileTheWorld.java needs to be updated for Jigsaw In-Reply-To: <576C1A29.3020804@oracle.com> References: <576C1A29.3020804@oracle.com> Message-ID: <6A4D519E-D2BE-46DA-96C3-A627E2A5B6C3@oracle.com> Hi Tatiana, 1st of all, thanks for fixing that. I?ve one suggest: could you please add a comment why we need to call System::exit and store cout/cerr in CompileTheWorld.java? otherwise looks good to me. Thanks, ? Igor > On Jun 23, 2016, at 8:19 PM, Tatiana Pivovarova wrote: > > Hi guys! > > Please review this patch > > To run CompileTheWorld harness with new jdk9 it is need to add compatibility to read .jimage files and to remove hardcoded links to rt.jar and "sun.boot.class.path" property. > > bug: https://bugs.openjdk.java.net/browse/JDK-8143081 > webrev: http://cr.openjdk.java.net/~tpivovarova/8143081/webrev.01/ > > Tested locally by compilation lib/modules. > > Thanks, > Tatiana > From vladimir.kozlov at oracle.com Fri Jun 24 17:37:34 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jun 2016 10:37:34 -0700 Subject: [9] RFR(S): 8159016: Over-unrolled loop is partially removed In-Reply-To: <576D2AE1.4060005@oracle.com> References: <57695B0E.3020001@oracle.com> <576A9126.7020802@oracle.com> <12f80807-7b61-46ec-dd6a-97524f433b9e@oracle.com> <576B9EDF.6010408@oracle.com> <826b8f92-bcdc-484f-680b-afe367cf9d8c@oracle.com> <576D2AE1.4060005@oracle.com> Message-ID: Thank you for verifying that MB is removed. I think changes are ready for push. Thanks, Vladimir On 6/24/16 5:43 AM, Tobias Hartmann wrote: > Hi Vladimir, > > On 23.06.2016 20:29, Vladimir Kozlov wrote: >> On 6/23/16 1:33 AM, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> On 22.06.2016 21:45, Vladimir Kozlov wrote: >>>> On 6/22/16 6:22 AM, Tobias Hartmann wrote: >>>>> Hi Vladimir, >>>>> >>>>> thanks for the review! >>>>> >>>>> On 21.06.2016 21:59, Vladimir Kozlov wrote: >>>>>> Thank you, Tobias >>>>>> >>>>>> Your changes are good to have. >>>>>> >>>>>> You can still have a problem if unrolling is done before CCP phase which calculates array size and/or limit. >>>>>> >>>>>> Try to delay size calculation in test until CCP phase. Something like next (please, verify): >>>>>> >>>>>> // Simplified during CCP: >>>>>> int size = 2; >>>>>> for (; size < 4; size *= 2); >>>>>> Object arr[] = new Object[size - 1]; >>>>> >>>>> With a similar piece of code, I'm able to delay size calculation to after CCP but then the out of bound stores are not removed because the trip count Phi has type "int" (instead of "int:>=1"). I think this is because the CastIINode::Value() optimization for CastIIs with _carry_dependency is not able to determine a more restricted type before CCP. >>>> >>>> Got it. >>>> >>>>> >>>>>> Why over-unrolling check code in IdealLoopTree::policy_unroll() does not work? >>>>> >>>>> The code after "// Protect against over-unrolling when init or/and limit are not constant" can only detect over-unrolling if the type of the iv-Phi is narrow enough. In this case, the Phi's type is "#int:>=1:www". >>>> >>>> Should we enhance this check? >>> >>> I'm not sure how. The problem is that we don't have enough type information about the loop Phi because the loop predicate is guarded by OpaqueNodes. We know that the pre-loop is executed once and therefore the initial value of the main loop induction variable is 1, but we are unable to determine the maximum number of iterations (hence "#int:>=1:www"). >> >> Okay, agree that we can do nothing if type is not more concrete. >> >>> >>>>>> I think the trip count check before main loop should collapse whole main loop code. Then we will not have this problem. Why it is not collapsed? >>>>> >>>>> The trip count check before the main loop is guarded by Opaque nodes and not folded until after loop unrolling. I think it's also better to unroll the loop at least twice instead of over-unrolling and then removing the loop. >>>> >>>> Okay. >>>> >>>> >>>>> >>>>>> About test. >>>>>> >>>>>> You do & 3 two times: >>>>>> >>>>>> int lim = (arg & 3); >>>>>> test(i & 3); >>>>>> >>>>>> Use 11_000 iterations because 10000 may not trigger compilation. >>>>> >>>>> Right, I already fixed this but accidentally uploaded an old version of the test. We actually don't even need 10_000 iterations because the test runs with -Xcomp to avoid gathering "too much" profiling information for the loop. A loop with 42 iterations (for some reason we need some iterations) triggers the problem 100% on my machine. >>>> >>>> Good. >>>> >>>>> >>>>>> Let array escape to avoid EA. For example, return it. >>>>> >>>>> Done, but this triggers another problem: We now crash in PhaseMacroExpand::expand_allocate_common() in line 1600 while adding a membar after an InitializeNode because all memory users were removed. The problem is that now parts of the post loop are removed before we can determine that the entire loop is dead (and it is dead because the pre-loop executes one iteration and the unrolled main loop executes the remaining two iterations). The post loop is only removed after the Opaque1Node that guards the predicate is removed which happens later in macro expansion. >>>> >>>> Hmm, all Opaque nodes are removed before allocation node expansion. But may be it does not enough to collapse post loop which looks like happens only during IGVN transformation after all expansions. >>> >>> Yes, the post loop only collapses after IGVN (i.e. after macro node expansion). >> >> OK. >> >>> >>>> But this should not happen. Allocation is done before loop and there are stores in pre-loop and main-loop which should be memory users of allocation. Are those stores collected by InitializeNode? In such case your changes are good (let IGVN code decide about MB removal). >>> >>> Actually, the InitializeNode belongs to the "new Object()" allocation *in* the loop. The StoreNNode stores this new Object in arr[i]. Because the store is removed before the loop is collapsed, the InitializeNode has no memory users and the barrier insertion code fails. I think it should be safe to ignore this and let the subsequent IGVN remove the barrier. >> >> Can you confirm that MB is removed by IGVN? > > I verified that the IGVN after macro expansion removes the entire post loop, i.e., the barrier is removed as well. > > Thanks, > Tobias > >>>>> I think it should be safe to just add a guard for != NULL like we do in PhaseMacroExpand::process_users_of_allocation(). I verified that the post loop is removed after the Opaque1Node goes away. >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~thartmann/8159016/webrev.01/ >>>> >>>> Good. >>>> >>>>> >>>>> I'm re-running the testing. >>>> >>>> Add testing link to the bug report. >>> >>> Sure, done (no new failures). >> >> Good. >> >> Thanks, >> Vladimir >> >>> >>> Best regards, >>> Tobias >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/21/16 8:19 AM, Tobias Hartmann wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review the following fix: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159016 >>>>>>> http://cr.openjdk.java.net/~thartmann/8159016/webrev.00/ >>>>>>> >>>>>>> I was able to reproduce the problem with a simple test: >>>>>>> >>>>>>> Object arr[] = new Object[3]; >>>>>>> int lim = (arg & 3); >>>>>>> for (int i = 0; i < lim; ++i) { >>>>>>> arr[i] = new Object(); >>>>>>> } >>>>>>> >>>>>>> The loop is split into pre, main and post loops. The pre loop is executed for at least one iteration, initializing arr[0]. The main loop is unrolled twice, initializing at least arr[1], arr[2], arr[3] and arr[4]. The arr[3] and arr[4] stores are always out of bounds and removed. However, C2 is unable to remove the "over-unrolled", dead main loop. As a result, there is a control path from the main loop to the PostScalarRce loop (see JDK-8151573) without a memory path since the last store was replaced by TOP. We crash because we use a memory edge from a non-dominating region. >>>>>>> >>>>>>> The out of bound stores in the over-unrolled loop are removed because their range check dependent CastII nodes are removed by the first optimization in CastIINode::Ideal(): >>>>>>> CastII (AddI Phi 2) -> AddI (CastII Phi) 2 -> AddI TOP 2 >>>>>>> >>>>>>> The CastIINodes are replaced by TOP because the type of the loop Phi is >= 1 and the CastII is [1..2], i.e. there is no value >= 1 that is in the [1..2] range if +2 is added. >>>>>>> >>>>>>> The underlying problem is the over-unrolling of the loop. Since lim < 3, we always only execute at least 3 loop iterations. With the pre loop executing at least one iteration, the main loop should not be unrolled more than once. This problem is similar to JDK-4834191 where we over-unrolled a loop with a constant limit. >>>>>>> >>>>>>> I changed the implementation of IdealLoopTree::compute_exact_trip_count() to not only compute the exact trip count if the loop limit is constant but to also set the _trip_count field if we are able to determine an upper bound. Like this, the checks in IdealLoopTree::policy_unroll() prevent additional loop unrolling if the trip_count became too small and we keep the maximally unrolled version. >>>>>>> >>>>>>> An alternative fix would be to disable the CastII optimization for range check dependent CastII nodes but this does not fix the underlying problem of over-unrolling. >>>>>>> >>>>>>> Tested with regression test, JPRT and RBT (running). >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> From vladimir.kozlov at oracle.com Fri Jun 24 17:38:47 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jun 2016 10:38:47 -0700 Subject: RFR(XXS) 8157249: [JVMCI] remove ConstantReflectionProvider.isEmbeddable method In-Reply-To: <1020643F-082A-4B12-BFDF-C4B18A1BED60@oracle.com> References: <2bb6639f-c738-eb18-2802-2205621dbc2e@oracle.com> <1020643F-082A-4B12-BFDF-C4B18A1BED60@oracle.com> Message-ID: Good. Vladimir On 6/24/16 1:06 AM, Igor Veresov wrote: > Sorry, forgot to remove the test: > > http://cr.openjdk.java.net/~iveresov/8157249/webrev.01/ > > igor > >> On Jun 24, 2016, at 12:24 AM, Igor Veresov > wrote: >> >> Thanks, Vladimir! >> >> igor >> >>> On Jun 23, 2016, at 11:11 PM, Vladimir Kozlov > wrote: >>> >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/23/16 10:47 PM, Igor Veresov wrote: >>>> This is just a removal of an unused API. >>>> >>>> http://cr.openjdk.java.net/~iveresov/8157249/webrev.00/ >>>> >>>> Thanks, >>>> igor >> > From igor.veresov at oracle.com Fri Jun 24 18:18:29 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 24 Jun 2016 11:18:29 -0700 Subject: RFR(XXS) 8157249: [JVMCI] remove ConstantReflectionProvider.isEmbeddable method In-Reply-To: References: <2bb6639f-c738-eb18-2802-2205621dbc2e@oracle.com> <1020643F-082A-4B12-BFDF-C4B18A1BED60@oracle.com> Message-ID: Thanks! igor > On Jun 24, 2016, at 10:38 AM, Vladimir Kozlov wrote: > > Good. > > Vladimir > > On 6/24/16 1:06 AM, Igor Veresov wrote: >> Sorry, forgot to remove the test: >> >> http://cr.openjdk.java.net/~iveresov/8157249/webrev.01/ >> >> igor >> >>> On Jun 24, 2016, at 12:24 AM, Igor Veresov > wrote: >>> >>> Thanks, Vladimir! >>> >>> igor >>> >>>> On Jun 23, 2016, at 11:11 PM, Vladimir Kozlov > wrote: >>>> >>>> Looks good. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/23/16 10:47 PM, Igor Veresov wrote: >>>>> This is just a removal of an unused API. >>>>> >>>>> http://cr.openjdk.java.net/~iveresov/8157249/webrev.00/ >>>>> >>>>> Thanks, >>>>> igor >>> >> From dmitrij.pochepko at oracle.com Fri Jun 24 18:59:18 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 24 Jun 2016 21:59:18 +0300 Subject: RFR: 8132318 - -XX:TraceJumps is broken on Sparc Message-ID: <576D8306.5060305@oracle.com> Hi, please review fix for 8132318: -XX:TraceJumps is broken on Sparc Since flag wasn't used recently and was "develop", it was decided to remove it. webrev: http://cr.openjdk.java.net/~dpochepk/8132318/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8132318 I've tested these changes in jprt. Thanks, Dmitrij From vladimir.kozlov at oracle.com Fri Jun 24 21:48:18 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jun 2016 14:48:18 -0700 Subject: RFR: 8132318 - -XX:TraceJumps is broken on Sparc In-Reply-To: <576D8306.5060305@oracle.com> References: <576D8306.5060305@oracle.com> Message-ID: <576DAAA2.8040008@oracle.com> Looks good. Removing unused and *not-working* code is good. Thanks, Vladimir On 6/24/16 11:59 AM, Dmitrij Pochepko wrote: > Hi, > > please review fix for 8132318: -XX:TraceJumps is broken on Sparc > > Since flag wasn't used recently and was "develop", it was decided to remove it. > > webrev: http://cr.openjdk.java.net/~dpochepk/8132318/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8132318 > > I've tested these changes in jprt. > > Thanks, > Dmitrij From vladimir.kozlov at oracle.com Fri Jun 24 22:56:22 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jun 2016 15:56:22 -0700 Subject: [9] RFR (S): 8159431: C1 arraycopy intrinsic type checks missing In-Reply-To: <576D5A40.9080404@oracle.com> References: <576D5A40.9080404@oracle.com> Message-ID: <576DBA96.20004@oracle.com> Zoltan, check that klass is not j.l.Object is not enough. See next code in stub generators how to check for arrays (similar code exists on all platforms): http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ff0c5aa32086/src/cpu/x86/vm/stubGenerator_x86_64.cpp#l2649 Thanks, Vladimir On 6/24/16 9:05 AM, Zolt?n Maj? wrote: > Hi, > > > please review the patch for 8159431. > > https://bugs.openjdk.java.net/browse/JDK-8159431 > > Problem: The C1 intrinsic for > java.lang.System.arraycopy(Object src, int srcPos, Object dest, int destPos, int length) > > does not verify that 'src' or 'dest' is a "proper" array. As a result, the intrinsic reads the non-existing 'length' field from java.lang.Object (i.e., the intrinsic reads past the end of the > java.lang.Object instance), which is incorrect. > > Also, the intrinsic only checks if 'src' is a subclass of 'dest' before writing into 'dest' without checking the special case 'dest'==java.lang.Object. That can result in data being written to a > random heap location instead of the required ArrayStoreException being thrown. > > Solution: Check the type of 'src' and 'dest' at runtime if the compiler was not able to prove at compile-time that 'src' and 'dest' are "proper" arrays. > > Webrev: > http://cr.openjdk.java.net/~zmajo/8159431/webrev.00/ > > Testing: JPRT (testset hotspot). > > I'll do an RBT run once the code is close to its final shape. > > The problem was originally reported by Xiang Yuan from Linaro. Once the code is reviewed, I plan to push the patch with Xiang and myself as contributors. > > The open arm port and ppc are also likely to be affected. I'll file bugs for those architectures and notify persons working on the appropriate ports. > > Thank you! > > Best regards, > > > Zoltan > From tobias.hartmann at oracle.com Mon Jun 27 05:55:08 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Jun 2016 07:55:08 +0200 Subject: [9] RFR(S): 8159016: Over-unrolled loop is partially removed In-Reply-To: References: <57695B0E.3020001@oracle.com> <576A9126.7020802@oracle.com> <12f80807-7b61-46ec-dd6a-97524f433b9e@oracle.com> <576B9EDF.6010408@oracle.com> <826b8f92-bcdc-484f-680b-afe367cf9d8c@oracle.com> <576D2AE1.4060005@oracle.com> Message-ID: <5770BFBC.7030103@oracle.com> Thanks, Vladimir! Best regards, Tobias On 24.06.2016 19:37, Vladimir Kozlov wrote: > Thank you for verifying that MB is removed. > I think changes are ready for push. > > Thanks, > Vladimir > > On 6/24/16 5:43 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> On 23.06.2016 20:29, Vladimir Kozlov wrote: >>> On 6/23/16 1:33 AM, Tobias Hartmann wrote: >>>> Hi Vladimir, >>>> >>>> On 22.06.2016 21:45, Vladimir Kozlov wrote: >>>>> On 6/22/16 6:22 AM, Tobias Hartmann wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> thanks for the review! >>>>>> >>>>>> On 21.06.2016 21:59, Vladimir Kozlov wrote: >>>>>>> Thank you, Tobias >>>>>>> >>>>>>> Your changes are good to have. >>>>>>> >>>>>>> You can still have a problem if unrolling is done before CCP phase which calculates array size and/or limit. >>>>>>> >>>>>>> Try to delay size calculation in test until CCP phase. Something like next (please, verify): >>>>>>> >>>>>>> // Simplified during CCP: >>>>>>> int size = 2; >>>>>>> for (; size < 4; size *= 2); >>>>>>> Object arr[] = new Object[size - 1]; >>>>>> >>>>>> With a similar piece of code, I'm able to delay size calculation to after CCP but then the out of bound stores are not removed because the trip count Phi has type "int" (instead of "int:>=1"). I think this is because the CastIINode::Value() optimization for CastIIs with _carry_dependency is not able to determine a more restricted type before CCP. >>>>> >>>>> Got it. >>>>> >>>>>> >>>>>>> Why over-unrolling check code in IdealLoopTree::policy_unroll() does not work? >>>>>> >>>>>> The code after "// Protect against over-unrolling when init or/and limit are not constant" can only detect over-unrolling if the type of the iv-Phi is narrow enough. In this case, the Phi's type is "#int:>=1:www". >>>>> >>>>> Should we enhance this check? >>>> >>>> I'm not sure how. The problem is that we don't have enough type information about the loop Phi because the loop predicate is guarded by OpaqueNodes. We know that the pre-loop is executed once and therefore the initial value of the main loop induction variable is 1, but we are unable to determine the maximum number of iterations (hence "#int:>=1:www"). >>> >>> Okay, agree that we can do nothing if type is not more concrete. >>> >>>> >>>>>>> I think the trip count check before main loop should collapse whole main loop code. Then we will not have this problem. Why it is not collapsed? >>>>>> >>>>>> The trip count check before the main loop is guarded by Opaque nodes and not folded until after loop unrolling. I think it's also better to unroll the loop at least twice instead of over-unrolling and then removing the loop. >>>>> >>>>> Okay. >>>>> >>>>> >>>>>> >>>>>>> About test. >>>>>>> >>>>>>> You do & 3 two times: >>>>>>> >>>>>>> int lim = (arg & 3); >>>>>>> test(i & 3); >>>>>>> >>>>>>> Use 11_000 iterations because 10000 may not trigger compilation. >>>>>> >>>>>> Right, I already fixed this but accidentally uploaded an old version of the test. We actually don't even need 10_000 iterations because the test runs with -Xcomp to avoid gathering "too much" profiling information for the loop. A loop with 42 iterations (for some reason we need some iterations) triggers the problem 100% on my machine. >>>>> >>>>> Good. >>>>> >>>>>> >>>>>>> Let array escape to avoid EA. For example, return it. >>>>>> >>>>>> Done, but this triggers another problem: We now crash in PhaseMacroExpand::expand_allocate_common() in line 1600 while adding a membar after an InitializeNode because all memory users were removed. The problem is that now parts of the post loop are removed before we can determine that the entire loop is dead (and it is dead because the pre-loop executes one iteration and the unrolled main loop executes the remaining two iterations). The post loop is only removed after the Opaque1Node that guards the predicate is removed which happens later in macro expansion. >>>>> >>>>> Hmm, all Opaque nodes are removed before allocation node expansion. But may be it does not enough to collapse post loop which looks like happens only during IGVN transformation after all expansions. >>>> >>>> Yes, the post loop only collapses after IGVN (i.e. after macro node expansion). >>> >>> OK. >>> >>>> >>>>> But this should not happen. Allocation is done before loop and there are stores in pre-loop and main-loop which should be memory users of allocation. Are those stores collected by InitializeNode? In such case your changes are good (let IGVN code decide about MB removal). >>>> >>>> Actually, the InitializeNode belongs to the "new Object()" allocation *in* the loop. The StoreNNode stores this new Object in arr[i]. Because the store is removed before the loop is collapsed, the InitializeNode has no memory users and the barrier insertion code fails. I think it should be safe to ignore this and let the subsequent IGVN remove the barrier. >>> >>> Can you confirm that MB is removed by IGVN? >> >> I verified that the IGVN after macro expansion removes the entire post loop, i.e., the barrier is removed as well. >> >> Thanks, >> Tobias >> >>>>>> I think it should be safe to just add a guard for != NULL like we do in PhaseMacroExpand::process_users_of_allocation(). I verified that the post loop is removed after the Opaque1Node goes away. >>>>>> >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~thartmann/8159016/webrev.01/ >>>>> >>>>> Good. >>>>> >>>>>> >>>>>> I'm re-running the testing. >>>>> >>>>> Add testing link to the bug report. >>>> >>>> Sure, done (no new failures). >>> >>> Good. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Best regards, >>>> Tobias >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/21/16 8:19 AM, Tobias Hartmann wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review the following fix: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8159016 >>>>>>>> http://cr.openjdk.java.net/~thartmann/8159016/webrev.00/ >>>>>>>> >>>>>>>> I was able to reproduce the problem with a simple test: >>>>>>>> >>>>>>>> Object arr[] = new Object[3]; >>>>>>>> int lim = (arg & 3); >>>>>>>> for (int i = 0; i < lim; ++i) { >>>>>>>> arr[i] = new Object(); >>>>>>>> } >>>>>>>> >>>>>>>> The loop is split into pre, main and post loops. The pre loop is executed for at least one iteration, initializing arr[0]. The main loop is unrolled twice, initializing at least arr[1], arr[2], arr[3] and arr[4]. The arr[3] and arr[4] stores are always out of bounds and removed. However, C2 is unable to remove the "over-unrolled", dead main loop. As a result, there is a control path from the main loop to the PostScalarRce loop (see JDK-8151573) without a memory path since the last store was replaced by TOP. We crash because we use a memory edge from a non-dominating region. >>>>>>>> >>>>>>>> The out of bound stores in the over-unrolled loop are removed because their range check dependent CastII nodes are removed by the first optimization in CastIINode::Ideal(): >>>>>>>> CastII (AddI Phi 2) -> AddI (CastII Phi) 2 -> AddI TOP 2 >>>>>>>> >>>>>>>> The CastIINodes are replaced by TOP because the type of the loop Phi is >= 1 and the CastII is [1..2], i.e. there is no value >= 1 that is in the [1..2] range if +2 is added. >>>>>>>> >>>>>>>> The underlying problem is the over-unrolling of the loop. Since lim < 3, we always only execute at least 3 loop iterations. With the pre loop executing at least one iteration, the main loop should not be unrolled more than once. This problem is similar to JDK-4834191 where we over-unrolled a loop with a constant limit. >>>>>>>> >>>>>>>> I changed the implementation of IdealLoopTree::compute_exact_trip_count() to not only compute the exact trip count if the loop limit is constant but to also set the _trip_count field if we are able to determine an upper bound. Like this, the checks in IdealLoopTree::policy_unroll() prevent additional loop unrolling if the trip_count became too small and we keep the maximally unrolled version. >>>>>>>> >>>>>>>> An alternative fix would be to disable the CastII optimization for range check dependent CastII nodes but this does not fix the underlying problem of over-unrolling. >>>>>>>> >>>>>>>> Tested with regression test, JPRT and RBT (running). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> From tobias.hartmann at oracle.com Mon Jun 27 06:05:57 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Jun 2016 08:05:57 +0200 Subject: RFR: 8132318 - -XX:TraceJumps is broken on Sparc In-Reply-To: <576D8306.5060305@oracle.com> References: <576D8306.5060305@oracle.com> Message-ID: <5770C245.70909@oracle.com> Hi Dmitrij, looks good, thanks for fixing this! Just a minor suggestion (you don't need to send another webrev): In sharedRuntime_sparc.cpp you can now remove the declarations of "pad". Best regards, Tobias On 24.06.2016 20:59, Dmitrij Pochepko wrote: > Hi, > > please review fix for 8132318: -XX:TraceJumps is broken on Sparc > > Since flag wasn't used recently and was "develop", it was decided to remove it. > > webrev: http://cr.openjdk.java.net/~dpochepk/8132318/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8132318 > > I've tested these changes in jprt. > > Thanks, > Dmitrij From tatiana.pivovarova at oracle.com Mon Jun 27 13:32:17 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Mon, 27 Jun 2016 16:32:17 +0300 Subject: [9] RFR(S): 8143081: [ctw] Test CompileTheWorld.java needs to be updated for Jigsaw In-Reply-To: <6A4D519E-D2BE-46DA-96C3-A627E2A5B6C3@oracle.com> References: <576C1A29.3020804@oracle.com> <6A4D519E-D2BE-46DA-96C3-A627E2A5B6C3@oracle.com> Message-ID: <57712AE1.4040003@oracle.com> Hi Igor! Thanks for your review. I added these comments. webrev : http://cr.openjdk.java.net/~tpivovarova/8143081/webrev.04/ Thanks, Tatiana On 06/24/2016 08:03 PM, Igor Ignatyev wrote: > Hi Tatiana, > > 1st of all, thanks for fixing that. > > I?ve one suggest: could you please add a comment why we need to call System::exit and store cout/cerr in CompileTheWorld.java? otherwise looks good to me. > > Thanks, > ? Igor > >> On Jun 23, 2016, at 8:19 PM, Tatiana Pivovarova wrote: >> >> Hi guys! >> >> Please review this patch >> >> To run CompileTheWorld harness with new jdk9 it is need to add compatibility to read .jimage files and to remove hardcoded links to rt.jar and "sun.boot.class.path" property. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8143081 >> webrev: http://cr.openjdk.java.net/~tpivovarova/8143081/webrev.01/ >> >> Tested locally by compilation lib/modules. >> >> Thanks, >> Tatiana >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Mon Jun 27 14:11:28 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 27 Jun 2016 17:11:28 +0300 Subject: RFR: 8132318 - -XX:TraceJumps is broken on Sparc In-Reply-To: <576DAAA2.8040008@oracle.com> References: <576D8306.5060305@oracle.com> <576DAAA2.8040008@oracle.com> Message-ID: <57713410.1050705@oracle.com> Thank you! On 25.06.2016 00:48, Vladimir Kozlov wrote: > Looks good. Removing unused and *not-working* code is good. > > Thanks, > Vladimir > > On 6/24/16 11:59 AM, Dmitrij Pochepko wrote: >> Hi, >> >> please review fix for 8132318: -XX:TraceJumps is broken on Sparc >> >> Since flag wasn't used recently and was "develop", it was decided to >> remove it. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8132318/webrev.01/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8132318 >> >> I've tested these changes in jprt. >> >> Thanks, >> Dmitrij From dmitrij.pochepko at oracle.com Mon Jun 27 14:13:51 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 27 Jun 2016 17:13:51 +0300 Subject: RFR: 8132318 - -XX:TraceJumps is broken on Sparc In-Reply-To: <5770C245.70909@oracle.com> References: <576D8306.5060305@oracle.com> <5770C245.70909@oracle.com> Message-ID: <5771349F.8030000@oracle.com> Thank you. I'll remove declaration and usage. > Hi Dmitrij, > > looks good, thanks for fixing this! > > Just a minor suggestion (you don't need to send another webrev): > In sharedRuntime_sparc.cpp you can now remove the declarations of "pad". > > Best regards, > Tobias > > On 24.06.2016 20:59, Dmitrij Pochepko wrote: >> Hi, >> >> please review fix for 8132318: -XX:TraceJumps is broken on Sparc >> >> Since flag wasn't used recently and was "develop", it was decided to remove it. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8132318/webrev.01/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8132318 >> >> I've tested these changes in jprt. >> >> Thanks, >> Dmitrij From brian.toal at gmail.com Wed Jun 22 23:56:58 2016 From: brian.toal at gmail.com (Brian Toal) Date: Wed, 22 Jun 2016 16:56:58 -0700 Subject: compiler monitorig/tuning In-Reply-To: References: Message-ID: Thanks Vladmir, Will look into -XX:+PrintTieredEvents. Might be useful to make queue lengths available by an MBean or whatever so that service owners can integrate those metrics with existing monitoring systems, and can understand when it might make sense to add more JIT threads to keep up with the enqueue rate. We recently upgraded from u66 -> u72 and around the same time we've noticed that 1-2 JVM's out of ~30-40 that are servicing the application tier run significantly slower and as a result take on more load, until the host is completely over saturated, exacerbating the problem worse. The workload is uniform across the hosts. We are looking at addressing the feedback system to ensure the requests are throttled, how ever we are trying to understand if some change in JIT behavior is causing the system to take longer to warm up. Looking at stacks from the active threads on the load ramp up, there isn't one hotspot that would explain the increase in load due to a feature regression, but rather what we see are arbitrary code paths. Could be due to the host being completely saturated and no real work progressing, or could be due to the code still running interpreted. - Brian On Tue, Jun 21, 2016 at 9:01 PM, Vladimir Kozlov wrote: > Hi Brian > > Could you explain what problems you are observing? Which JDK 8 update > version you are testing? > > On 6/16/16 11:00 AM, Brian Toal wrote: > >> Good day, >> >> - How do I monitor the length of the compiler queues (client and >> server)? I want to understand the backlog (if any) to >> determine if the application could benefit from more compilation threads. >> > > There is -XX:+PrintTieredEvents flag which outputs on display queues sizes > for each compilation request (a lot of output). > > >> - I remember in the past being able to get detailed compiler statistics >> from a mbean or something where the metric was >> prefixed with java.ci and it contained execution count, >> total time, thread count exec for the client >> and server compilers. Where can I find this data in realtime for >> monitoring purposes? If I know the total time and >> thread count I suppose I can work out if the utilization of the >> compilation threads. >> > > May be it was jvmstat monitoring utility (now jstat). But it does not > collect queues sizes. > > >> - What other compilation metrics should I be paying close attention to? >> > > Very detailed compilation output file is created (on JVM exit) with > -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation. > You can build this output parser tool from sources in > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ba5ca8b6e48f/src/share/tools/LogCompilation > (note it is jdk 9, for 8 update build from clone of > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/). > > >> - Other than tiered compilation becoming the default in Java 8, where >> there any significant changes that would have >> slowed down compilation time? We've had -XX:-TieredCompilation set in >> Java 7 and 8 and haven't touched any other JIT >> related config. Was there some other setting default that changed which >> we would have needed to change when going fro 7 >> to 8? Looking at the various compiler parameters that I know about via >> PrintFlagsFinal from 7 and 8, there doesn't seem >> to be any change other than -XX:-TieredCompilation. >> > > There were a lot of changes which could affected JIT compilation speed. > > >> Regards, >> - Brian >> > > Regards, > Vladimir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Mon Jun 27 18:20:18 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 27 Jun 2016 20:20:18 +0200 Subject: [9] RFR (S): 8159431: C1 arraycopy intrinsic type checks missing In-Reply-To: <576DBA96.20004@oracle.com> References: <576D5A40.9080404@oracle.com> <576DBA96.20004@oracle.com> Message-ID: <57716E62.10207@oracle.com> Hi Vladimir, thank you for the feedback! On 06/25/2016 12:56 AM, Vladimir Kozlov wrote: > Zoltan, check that klass is not j.l.Object is not enough. > See next code in stub generators how to check for arrays (similar code > exists on all platforms): > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ff0c5aa32086/src/cpu/x86/vm/stubGenerator_x86_64.cpp#l2649 > right, thank you for catching that! Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8159431/webrev.01/ Testing: JPRT (testset hotspot). Thank you! Best regards, Zoltan > > Thanks, > Vladimir > > On 6/24/16 9:05 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the patch for 8159431. >> >> https://bugs.openjdk.java.net/browse/JDK-8159431 >> >> Problem: The C1 intrinsic for >> java.lang.System.arraycopy(Object src, int srcPos, Object dest, int >> destPos, int length) >> >> does not verify that 'src' or 'dest' is a "proper" array. As a >> result, the intrinsic reads the non-existing 'length' field from >> java.lang.Object (i.e., the intrinsic reads past the end of the >> java.lang.Object instance), which is incorrect. >> >> Also, the intrinsic only checks if 'src' is a subclass of 'dest' >> before writing into 'dest' without checking the special case >> 'dest'==java.lang.Object. That can result in data being written to a >> random heap location instead of the required ArrayStoreException >> being thrown. >> >> Solution: Check the type of 'src' and 'dest' at runtime if the >> compiler was not able to prove at compile-time that 'src' and 'dest' >> are "proper" arrays. >> >> Webrev: >> http://cr.openjdk.java.net/~zmajo/8159431/webrev.00/ >> >> Testing: JPRT (testset hotspot). >> >> I'll do an RBT run once the code is close to its final shape. >> >> The problem was originally reported by Xiang Yuan from Linaro. Once >> the code is reviewed, I plan to push the patch with Xiang and myself >> as contributors. >> >> The open arm port and ppc are also likely to be affected. I'll file >> bugs for those architectures and notify persons working on the >> appropriate ports. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> From charlie.hunt at oracle.com Mon Jun 27 19:30:19 2016 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 27 Jun 2016 12:30:19 -0700 Subject: compiler monitorig/tuning In-Reply-To: References: Message-ID: Wrt ? > Might be useful to make queue lengths available by an MBean or whatever so that service owners can integrate those metrics with existing monitoring systems, and can understand when it might make sense to add more JIT threads to keep up with the enqueue rate. Contributions are welcome. :-] charlie > On Jun 22, 2016, at 4:56 PM, Brian Toal wrote: > > Thanks Vladmir, > > Will look into -XX:+PrintTieredEvents. Might be useful to make queue lengths available by an MBean or whatever so that service owners can integrate those metrics with existing monitoring systems, and can understand when it might make sense to add more JIT threads to keep up with the enqueue rate. > > We recently upgraded from u66 -> u72 and around the same time we've noticed that 1-2 JVM's out of ~30-40 that are servicing the application tier run significantly slower and as a result take on more load, until the host is completely over saturated, exacerbating the problem worse. The workload is uniform across the hosts. We are looking at addressing the feedback system to ensure the requests are throttled, how ever we are trying to understand if some change in JIT behavior is causing the system to take longer to warm up. > > Looking at stacks from the active threads on the load ramp up, there isn't one hotspot that would explain the increase in load due to a feature regression, but rather what we see are arbitrary code paths. Could be due to the host being completely saturated and no real work progressing, or could be due to the code still running interpreted. > > - Brian > > > > > > On Tue, Jun 21, 2016 at 9:01 PM, Vladimir Kozlov > wrote: > Hi Brian > > Could you explain what problems you are observing? Which JDK 8 update version you are testing? > > On 6/16/16 11:00 AM, Brian Toal wrote: > Good day, > > - How do I monitor the length of the compiler queues (client and server)? I want to understand the backlog (if any) to > determine if the application could benefit from more compilation threads. > > There is -XX:+PrintTieredEvents flag which outputs on display queues sizes for each compilation request (a lot of output). > > > - I remember in the past being able to get detailed compiler statistics from a mbean or something where the metric was > prefixed with java.ci > and it contained execution count, total time, thread count exec for the client > and server compilers. Where can I find this data in realtime for monitoring purposes? If I know the total time and > thread count I suppose I can work out if the utilization of the compilation threads. > > May be it was jvmstat monitoring utility (now jstat). But it does not collect queues sizes. > > > - What other compilation metrics should I be paying close attention to? > > Very detailed compilation output file is created (on JVM exit) with -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation. > You can build this output parser tool from sources in http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ba5ca8b6e48f/src/share/tools/LogCompilation (note it is jdk 9, for 8 update build from clone of http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/ ). > > > - Other than tiered compilation becoming the default in Java 8, where there any significant changes that would have > slowed down compilation time? We've had -XX:-TieredCompilation set in Java 7 and 8 and haven't touched any other JIT > related config. Was there some other setting default that changed which we would have needed to change when going fro 7 > to 8? Looking at the various compiler parameters that I know about via PrintFlagsFinal from 7 and 8, there doesn't seem > to be any change other than -XX:-TieredCompilation. > > There were a lot of changes which could affected JIT compilation speed. > > > Regards, > - Brian > > Regards, > Vladimir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Mon Jun 27 19:39:38 2016 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Mon, 27 Jun 2016 22:39:38 +0300 Subject: =?utf-8?B?UmU6IFs5XSBSRlIoUyk6IDgxNDMwODE6IFtjdHddIFRlc3QgQ29tcGlsZVRoZVdv?= =?utf-8?B?cmxkLmphdmEgbmVlZHMgdG8gYmUgdXBkYXRlZCBmb3IgSmlnc2F3?= Message-ID: <201606271939.u5RJdnoc020365@aserv0122.oracle.com> Hi Tatiana, Thank you for adding comments. Looks good to me. -- II ----- Reply message ----- From: "Tatiana Pivovarova" To: "Igor Ignatyev" Cc: Subject: [9] RFR(S): 8143081: [ctw] Test CompileTheWorld.java needs to be updated for Jigsaw Date: Mon, Jun 27, 2016 16:32 Hi Igor! Thanks for your review. I added these comments. webrev : http://cr.openjdk.java.net/~tpivovarova/8143081/webrev.04/ Thanks, Tatiana On 06/24/2016 08:03 PM, Igor Ignatyev wrote: Hi Tatiana, 1st of all, thanks for fixing that. I?ve one suggest: could you please add a comment why we need to call System::exit and store cout/cerr in CompileTheWorld.java? otherwise looks good to me. Thanks, ? Igor On Jun 23, 2016, at 8:19 PM, Tatiana Pivovarova wrote: Hi guys! Please review this patch To run CompileTheWorld harness with new jdk9 it is need to add compatibility to read .jimage files and to remove hardcoded links to rt.jar and "sun.boot.class.path" property. bug: https://bugs.openjdk.java.net/browse/JDK-8143081 webrev: http://cr.openjdk.java.net/~tpivovarova/8143081/webrev.01/ Tested locally by compilation lib/modules. Thanks, Tatiana -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.rodriguez at oracle.com Tue Jun 28 02:56:49 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 27 Jun 2016 19:56:49 -0700 Subject: RFR: 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI In-Reply-To: <5162b163-3dfc-3571-187d-b534c1994667@oracle.com> References: <5162b163-3dfc-3571-187d-b534c1994667@oracle.com> Message-ID: Some side discussion generated a minor change to this fix. simpleThresholdPolicy.cpp already had a check that JVMCI was in phase 2 before allowing compile, so instead of checking this over in jvmciCompiler.cpp I?ve modified the exist check to require phase 3. The new webrev is http://cr.openjdk.java.net/~never/8160121-v3/webrev . The only difference is there are no changes in jvmciCompiler.cpp and there are new changes in simpleThresholdPolicy.cpp. tom > On Jun 23, 2016, at 10:06 AM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 6/23/16 8:55 AM, Doug Simon wrote: >> JVMCI cannot be initialized until after VM init phase 3 as it requires the jdk.vm.ci module to be available (phase 2) and ServiceLoader to be working (phase 3). This change moves the eager initialization of JVMCI (under the condition of !UseInterpreter || !BackgroundCompilation) to be after phase 3 as well as causing JVMCI compilations before phase 3 to be ignored. >> >> Thanks to Tom for most of this code! >> >> https://bugs.openjdk.java.net/browse/JDK-8160121 >> http://cr.openjdk.java.net/~dnsimon/8160121/ >> >> -Doug >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Tue Jun 28 06:00:46 2016 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 28 Jun 2016 08:00:46 +0200 Subject: RFR: 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI In-Reply-To: References: <5162b163-3dfc-3571-187d-b534c1994667@oracle.com> Message-ID: <70C28635-B578-40D4-ACCB-FCC9C0B9B9A0@oracle.com> Looks good to me. > On 28 Jun 2016, at 04:56, Tom Rodriguez wrote: > > Some side discussion generated a minor change to this fix. simpleThresholdPolicy.cpp already had a check that JVMCI was in phase 2 before allowing compile, so instead of checking this over in jvmciCompiler.cpp I?ve modified the exist check to require phase 3. The new webrev is http://cr.openjdk.java.net/~never/8160121-v3/webrev. The only difference is there are no changes in jvmciCompiler.cpp and there are new changes in simpleThresholdPolicy.cpp. > > tom > >> On Jun 23, 2016, at 10:06 AM, Vladimir Kozlov wrote: >> >> Looks good. >> >> Thanks, >> Vladimir >> >> On 6/23/16 8:55 AM, Doug Simon wrote: >>> JVMCI cannot be initialized until after VM init phase 3 as it requires the jdk.vm.ci module to be available (phase 2) and ServiceLoader to be working (phase 3). This change moves the eager initialization of JVMCI (under the condition of !UseInterpreter || !BackgroundCompilation) to be after phase 3 as well as causing JVMCI compilations before phase 3 to be ignored. >>> >>> Thanks to Tom for most of this code! >>> >>> https://bugs.openjdk.java.net/browse/JDK-8160121 >>> http://cr.openjdk.java.net/~dnsimon/8160121/ >>> >>> -Doug >>> > From tobias.hartmann at oracle.com Tue Jun 28 11:47:04 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Jun 2016 13:47:04 +0200 Subject: [9] RFR(S): 8160425: Vectorization with signalling NaN returns wrong result Message-ID: <577263B8.6030506@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8160425 http://cr.openjdk.java.net/~thartmann/8159792/webrev.00/ We vectorize the following loop: for (int i = 0; i < 1024; ++i) { array[i] = (char)0xfff7; } The array store is replaced by a 64-bit vector store to four subsequent array elements. The vector should look like this '0xfff7fff7fff7fff7' and is read from the constant table. However, in floating point arithmetic, this is a signalling NaN which is converted to a quiet NaN when processed by the x87 FPU. After the signalling bit is set, the vector ends up in the constant table as '0xfffffff7fff7fff7' which leads to an incorrect result: [Constants] 0xee376ec0 (offset: 0): 0xfff7fff7 0xfffffff7fff7fff7 0xee376ec4 (offset: 4): 0xfffffff7 The problem is that the constant vector is passed around as a double in the C code. On x86 32-bit, floating point values are returned via the FPU stack and since the value is a signalling NaN, it's converted to a quiet NaN by the FPU instructions. In this case, 'replicate8_imm' returns a double value which is passed to the caller on the FPU stack. Because the value is a signalling NaN, the 'fldl' instruction sets the most-significant fraction bit to 1 (see Chapter 4.8.3.4 of the Intel manual [1] or [2] for a similar problem). This code was introduced by JDK-7119644 [3]. I think we should not use doubles/floats in the C code but ints/longs because those constants should not be treated as floating point values. For consistency, I also changed this on SPARC although I'm not aware of any problems there. With the fix, the constant table contains the correct value: [Constants] 0xee4154c0 (offset: 0): 0xfff7fff7 0xfff7fff7fff7fff7 0xee4154c4 (offset: 4): 0xfff7fff7 Tested with failing testcase, JPRT and RBT (running). Thanks, Tobias [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf [2] http://stackoverflow.com/questions/22816095/signalling-nan-was-corrupted-when-returning-from-x86-function-flds-fstps-of-x87 [3] https://bugs.openjdk.java.net/browse/JDK-7119644 From vladimir.x.ivanov at oracle.com Tue Jun 28 13:20:07 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Jun 2016 16:20:07 +0300 Subject: [9] RFR(S): 8160425: Vectorization with signalling NaN returns wrong result In-Reply-To: <577263B8.6030506@oracle.com> References: <577263B8.6030506@oracle.com> Message-ID: <901ca4f5-14a2-d3b0-2a3c-dd5ea55e4817@oracle.com> test/compiler/vectorization/TestNaNVector.java: 56 public void vectorizeNaNDP() { ... 59 // should look like this '0xffa0ffa0ffa0ffa0' and is read from the constant ... 63 // as '0xffa0ffa0ffa0ffa0' which leads to an incorrect result. The comment in the test is misleading. Otherwise, looks good. Best regards, Vladimir Ivanov On 6/28/16 2:47 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8160425 > http://cr.openjdk.java.net/~thartmann/8159792/webrev.00/ > > We vectorize the following loop: > > for (int i = 0; i < 1024; ++i) { > array[i] = (char)0xfff7; > } > > The array store is replaced by a 64-bit vector store to four subsequent array elements. The vector should look like this '0xfff7fff7fff7fff7' and is read from the constant table. However, in floating point arithmetic, this is a signalling NaN which is converted to a quiet NaN when processed by the x87 FPU. After the signalling bit is set, the vector ends up in the constant table as '0xfffffff7fff7fff7' which leads to an incorrect result: > > [Constants] > 0xee376ec0 (offset: 0): 0xfff7fff7 0xfffffff7fff7fff7 > 0xee376ec4 (offset: 4): 0xfffffff7 > > The problem is that the constant vector is passed around as a double in the C code. On x86 32-bit, floating point values are returned via the FPU stack and since the value is a signalling NaN, it's converted to a quiet NaN by the FPU instructions. In this case, 'replicate8_imm' returns a double value which is passed to the caller on the FPU stack. Because the value is a signalling NaN, the 'fldl' instruction sets the most-significant fraction bit to 1 (see Chapter 4.8.3.4 of the Intel manual [1] or [2] for a similar problem). > > This code was introduced by JDK-7119644 [3]. I think we should not use doubles/floats in the C code but ints/longs because those constants should not be treated as floating point values. For consistency, I also changed this on SPARC although I'm not aware of any problems there. With the fix, the constant table contains the correct value: > > [Constants] > 0xee4154c0 (offset: 0): 0xfff7fff7 0xfff7fff7fff7fff7 > 0xee4154c4 (offset: 4): 0xfff7fff7 > > Tested with failing testcase, JPRT and RBT (running). > > Thanks, > Tobias > > [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf > [2] http://stackoverflow.com/questions/22816095/signalling-nan-was-corrupted-when-returning-from-x86-function-flds-fstps-of-x87 > [3] https://bugs.openjdk.java.net/browse/JDK-7119644 > From tobias.hartmann at oracle.com Tue Jun 28 13:29:11 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Jun 2016 15:29:11 +0200 Subject: [9] RFR(S): 8160425: Vectorization with signalling NaN returns wrong result In-Reply-To: <901ca4f5-14a2-d3b0-2a3c-dd5ea55e4817@oracle.com> References: <577263B8.6030506@oracle.com> <901ca4f5-14a2-d3b0-2a3c-dd5ea55e4817@oracle.com> Message-ID: <57727BA7.5090904@oracle.com> Hi Vladimir, thanks for the review! On 28.06.2016 15:20, Vladimir Ivanov wrote: > test/compiler/vectorization/TestNaNVector.java: > > 56 public void vectorizeNaNDP() { > ... > 59 // should look like this '0xffa0ffa0ffa0ffa0' and is read from the constant > ... > 63 // as '0xffa0ffa0ffa0ffa0' which leads to an incorrect result. > > The comment in the test is misleading. Right, I first used a different constant and forgot to update the comment. The description in the RFR is correct. Also used the wrong bug id for the first webrev. Here's the new one: http://cr.openjdk.java.net/~thartmann/8160425/webrev.01/ Thanks, Tobias > Otherwise, looks good. > Best regards, > Vladimir Ivanov > > On 6/28/16 2:47 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> https://bugs.openjdk.java.net/browse/JDK-8160425 >> http://cr.openjdk.java.net/~thartmann/8160425/webrev.00/ >> >> We vectorize the following loop: >> >> for (int i = 0; i < 1024; ++i) { >> array[i] = (char)0xfff7; >> } >> >> The array store is replaced by a 64-bit vector store to four subsequent array elements. The vector should look like this '0xfff7fff7fff7fff7' and is read from the constant table. However, in floating point arithmetic, this is a signalling NaN which is converted to a quiet NaN when processed by the x87 FPU. After the signalling bit is set, the vector ends up in the constant table as '0xfffffff7fff7fff7' which leads to an incorrect result: >> >> [Constants] >> 0xee376ec0 (offset: 0): 0xfff7fff7 0xfffffff7fff7fff7 >> 0xee376ec4 (offset: 4): 0xfffffff7 >> >> The problem is that the constant vector is passed around as a double in the C code. On x86 32-bit, floating point values are returned via the FPU stack and since the value is a signalling NaN, it's converted to a quiet NaN by the FPU instructions. In this case, 'replicate8_imm' returns a double value which is passed to the caller on the FPU stack. Because the value is a signalling NaN, the 'fldl' instruction sets the most-significant fraction bit to 1 (see Chapter 4.8.3.4 of the Intel manual [1] or [2] for a similar problem). >> >> This code was introduced by JDK-7119644 [3]. I think we should not use doubles/floats in the C code but ints/longs because those constants should not be treated as floating point values. For consistency, I also changed this on SPARC although I'm not aware of any problems there. With the fix, the constant table contains the correct value: >> >> [Constants] >> 0xee4154c0 (offset: 0): 0xfff7fff7 0xfff7fff7fff7fff7 >> 0xee4154c4 (offset: 4): 0xfff7fff7 >> >> Tested with failing testcase, JPRT and RBT (running). >> >> Thanks, >> Tobias >> >> [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf >> [2] http://stackoverflow.com/questions/22816095/signalling-nan-was-corrupted-when-returning-from-x86-function-flds-fstps-of-x87 >> [3] https://bugs.openjdk.java.net/browse/JDK-7119644 >> From vladimir.x.ivanov at oracle.com Tue Jun 28 13:35:36 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Jun 2016 16:35:36 +0300 Subject: [9] RFR(S): 8160425: Vectorization with signalling NaN returns wrong result In-Reply-To: <57727BA7.5090904@oracle.com> References: <577263B8.6030506@oracle.com> <901ca4f5-14a2-d3b0-2a3c-dd5ea55e4817@oracle.com> <57727BA7.5090904@oracle.com> Message-ID: <468861e4-5a09-720d-b61d-e1b1af393187@oracle.com> > Also used the wrong bug id for the first webrev. Here's the new one: > http://cr.openjdk.java.net/~thartmann/8160425/webrev.01/ Looks good. Best regards, Vladimir Ivanov >> On 6/28/16 2:47 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8160425 >>> http://cr.openjdk.java.net/~thartmann/8160425/webrev.00/ >>> >>> We vectorize the following loop: >>> >>> for (int i = 0; i < 1024; ++i) { >>> array[i] = (char)0xfff7; >>> } >>> >>> The array store is replaced by a 64-bit vector store to four subsequent array elements. The vector should look like this '0xfff7fff7fff7fff7' and is read from the constant table. However, in floating point arithmetic, this is a signalling NaN which is converted to a quiet NaN when processed by the x87 FPU. After the signalling bit is set, the vector ends up in the constant table as '0xfffffff7fff7fff7' which leads to an incorrect result: >>> >>> [Constants] >>> 0xee376ec0 (offset: 0): 0xfff7fff7 0xfffffff7fff7fff7 >>> 0xee376ec4 (offset: 4): 0xfffffff7 >>> >>> The problem is that the constant vector is passed around as a double in the C code. On x86 32-bit, floating point values are returned via the FPU stack and since the value is a signalling NaN, it's converted to a quiet NaN by the FPU instructions. In this case, 'replicate8_imm' returns a double value which is passed to the caller on the FPU stack. Because the value is a signalling NaN, the 'fldl' instruction sets the most-significant fraction bit to 1 (see Chapter 4.8.3.4 of the Intel manual [1] or [2] for a similar problem). >>> >>> This code was introduced by JDK-7119644 [3]. I think we should not use doubles/floats in the C code but ints/longs because those constants should not be treated as floating point values. For consistency, I also changed this on SPARC although I'm not aware of any problems there. With the fix, the constant table contains the correct value: >>> >>> [Constants] >>> 0xee4154c0 (offset: 0): 0xfff7fff7 0xfff7fff7fff7fff7 >>> 0xee4154c4 (offset: 4): 0xfff7fff7 >>> >>> Tested with failing testcase, JPRT and RBT (running). >>> >>> Thanks, >>> Tobias >>> >>> [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf >>> [2] http://stackoverflow.com/questions/22816095/signalling-nan-was-corrupted-when-returning-from-x86-function-flds-fstps-of-x87 >>> [3] https://bugs.openjdk.java.net/browse/JDK-7119644 >>> From tobias.hartmann at oracle.com Tue Jun 28 13:35:27 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Jun 2016 15:35:27 +0200 Subject: [9] RFR(S): 8160425: Vectorization with signalling NaN returns wrong result In-Reply-To: <468861e4-5a09-720d-b61d-e1b1af393187@oracle.com> References: <577263B8.6030506@oracle.com> <901ca4f5-14a2-d3b0-2a3c-dd5ea55e4817@oracle.com> <57727BA7.5090904@oracle.com> <468861e4-5a09-720d-b61d-e1b1af393187@oracle.com> Message-ID: <57727D1F.9020400@oracle.com> Thanks, Vladimir! Best regards, Tobias On 28.06.2016 15:35, Vladimir Ivanov wrote: >> Also used the wrong bug id for the first webrev. Here's the new one: >> http://cr.openjdk.java.net/~thartmann/8160425/webrev.01/ > > Looks good. > > Best regards, > Vladimir Ivanov > >>> On 6/28/16 2:47 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8160425 >>>> http://cr.openjdk.java.net/~thartmann/8160425/webrev.00/ >>>> >>>> We vectorize the following loop: >>>> >>>> for (int i = 0; i < 1024; ++i) { >>>> array[i] = (char)0xfff7; >>>> } >>>> >>>> The array store is replaced by a 64-bit vector store to four subsequent array elements. The vector should look like this '0xfff7fff7fff7fff7' and is read from the constant table. However, in floating point arithmetic, this is a signalling NaN which is converted to a quiet NaN when processed by the x87 FPU. After the signalling bit is set, the vector ends up in the constant table as '0xfffffff7fff7fff7' which leads to an incorrect result: >>>> >>>> [Constants] >>>> 0xee376ec0 (offset: 0): 0xfff7fff7 0xfffffff7fff7fff7 >>>> 0xee376ec4 (offset: 4): 0xfffffff7 >>>> >>>> The problem is that the constant vector is passed around as a double in the C code. On x86 32-bit, floating point values are returned via the FPU stack and since the value is a signalling NaN, it's converted to a quiet NaN by the FPU instructions. In this case, 'replicate8_imm' returns a double value which is passed to the caller on the FPU stack. Because the value is a signalling NaN, the 'fldl' instruction sets the most-significant fraction bit to 1 (see Chapter 4.8.3.4 of the Intel manual [1] or [2] for a similar problem). >>>> >>>> This code was introduced by JDK-7119644 [3]. I think we should not use doubles/floats in the C code but ints/longs because those constants should not be treated as floating point values. For consistency, I also changed this on SPARC although I'm not aware of any problems there. With the fix, the constant table contains the correct value: >>>> >>>> [Constants] >>>> 0xee4154c0 (offset: 0): 0xfff7fff7 0xfff7fff7fff7fff7 >>>> 0xee4154c4 (offset: 4): 0xfff7fff7 >>>> >>>> Tested with failing testcase, JPRT and RBT (running). >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf >>>> [2] http://stackoverflow.com/questions/22816095/signalling-nan-was-corrupted-when-returning-from-x86-function-flds-fstps-of-x87 >>>> [3] https://bugs.openjdk.java.net/browse/JDK-7119644 >>>> From vladimir.kozlov at oracle.com Tue Jun 28 16:04:12 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jun 2016 09:04:12 -0700 Subject: [9] RFR(S): 8160425: Vectorization with signalling NaN returns wrong result In-Reply-To: <57727BA7.5090904@oracle.com> References: <577263B8.6030506@oracle.com> <901ca4f5-14a2-d3b0-2a3c-dd5ea55e4817@oracle.com> <57727BA7.5090904@oracle.com> Message-ID: <6986fefa-8a7d-69b1-51a0-e0755ee22499@oracle.com> Looks good. thanks, Vladimir On 6/28/16 6:29 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review! > > On 28.06.2016 15:20, Vladimir Ivanov wrote: >> test/compiler/vectorization/TestNaNVector.java: >> >> 56 public void vectorizeNaNDP() { >> ... >> 59 // should look like this '0xffa0ffa0ffa0ffa0' and is read from the constant >> ... >> 63 // as '0xffa0ffa0ffa0ffa0' which leads to an incorrect result. >> >> The comment in the test is misleading. > > Right, I first used a different constant and forgot to update the comment. The description in the RFR is correct. > > Also used the wrong bug id for the first webrev. Here's the new one: > http://cr.openjdk.java.net/~thartmann/8160425/webrev.01/ > > Thanks, > Tobias > >> Otherwise, looks good. >> Best regards, >> Vladimir Ivanov >> >> On 6/28/16 2:47 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8160425 >>> http://cr.openjdk.java.net/~thartmann/8160425/webrev.00/ >>> >>> We vectorize the following loop: >>> >>> for (int i = 0; i < 1024; ++i) { >>> array[i] = (char)0xfff7; >>> } >>> >>> The array store is replaced by a 64-bit vector store to four subsequent array elements. The vector should look like this '0xfff7fff7fff7fff7' and is read from the constant table. However, in floating point arithmetic, this is a signalling NaN which is converted to a quiet NaN when processed by the x87 FPU. After the signalling bit is set, the vector ends up in the constant table as '0xfffffff7fff7fff7' which leads to an incorrect result: >>> >>> [Constants] >>> 0xee376ec0 (offset: 0): 0xfff7fff7 0xfffffff7fff7fff7 >>> 0xee376ec4 (offset: 4): 0xfffffff7 >>> >>> The problem is that the constant vector is passed around as a double in the C code. On x86 32-bit, floating point values are returned via the FPU stack and since the value is a signalling NaN, it's converted to a quiet NaN by the FPU instructions. In this case, 'replicate8_imm' returns a double value which is passed to the caller on the FPU stack. Because the value is a signalling NaN, the 'fldl' instruction sets the most-significant fraction bit to 1 (see Chapter 4.8.3.4 of the Intel manual [1] or [2] for a similar problem). >>> >>> This code was introduced by JDK-7119644 [3]. I think we should not use doubles/floats in the C code but ints/longs because those constants should not be treated as floating point values. For consistency, I also changed this on SPARC although I'm not aware of any problems there. With the fix, the constant table contains the correct value: >>> >>> [Constants] >>> 0xee4154c0 (offset: 0): 0xfff7fff7 0xfff7fff7fff7fff7 >>> 0xee4154c4 (offset: 4): 0xfff7fff7 >>> >>> Tested with failing testcase, JPRT and RBT (running). >>> >>> Thanks, >>> Tobias >>> >>> [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf >>> [2] http://stackoverflow.com/questions/22816095/signalling-nan-was-corrupted-when-returning-from-x86-function-flds-fstps-of-x87 >>> [3] https://bugs.openjdk.java.net/browse/JDK-7119644 >>> From tobias.hartmann at oracle.com Tue Jun 28 16:05:31 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Jun 2016 18:05:31 +0200 Subject: [9] RFR(S): 8160425: Vectorization with signalling NaN returns wrong result In-Reply-To: <6986fefa-8a7d-69b1-51a0-e0755ee22499@oracle.com> References: <577263B8.6030506@oracle.com> <901ca4f5-14a2-d3b0-2a3c-dd5ea55e4817@oracle.com> <57727BA7.5090904@oracle.com> <6986fefa-8a7d-69b1-51a0-e0755ee22499@oracle.com> Message-ID: <5772A04B.5090208@oracle.com> Thanks, Vladimir! Best regards, Tobias On 28.06.2016 18:04, Vladimir Kozlov wrote: > Looks good. > > thanks, > Vladimir > > On 6/28/16 6:29 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> On 28.06.2016 15:20, Vladimir Ivanov wrote: >>> test/compiler/vectorization/TestNaNVector.java: >>> >>> 56 public void vectorizeNaNDP() { >>> ... >>> 59 // should look like this '0xffa0ffa0ffa0ffa0' and is read from the constant >>> ... >>> 63 // as '0xffa0ffa0ffa0ffa0' which leads to an incorrect result. >>> >>> The comment in the test is misleading. >> >> Right, I first used a different constant and forgot to update the comment. The description in the RFR is correct. >> >> Also used the wrong bug id for the first webrev. Here's the new one: >> http://cr.openjdk.java.net/~thartmann/8160425/webrev.01/ >> >> Thanks, >> Tobias >> >>> Otherwise, looks good. >>> Best regards, >>> Vladimir Ivanov >>> >>> On 6/28/16 2:47 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8160425 >>>> http://cr.openjdk.java.net/~thartmann/8160425/webrev.00/ >>>> >>>> We vectorize the following loop: >>>> >>>> for (int i = 0; i < 1024; ++i) { >>>> array[i] = (char)0xfff7; >>>> } >>>> >>>> The array store is replaced by a 64-bit vector store to four subsequent array elements. The vector should look like this '0xfff7fff7fff7fff7' and is read from the constant table. However, in floating point arithmetic, this is a signalling NaN which is converted to a quiet NaN when processed by the x87 FPU. After the signalling bit is set, the vector ends up in the constant table as '0xfffffff7fff7fff7' which leads to an incorrect result: >>>> >>>> [Constants] >>>> 0xee376ec0 (offset: 0): 0xfff7fff7 0xfffffff7fff7fff7 >>>> 0xee376ec4 (offset: 4): 0xfffffff7 >>>> >>>> The problem is that the constant vector is passed around as a double in the C code. On x86 32-bit, floating point values are returned via the FPU stack and since the value is a signalling NaN, it's converted to a quiet NaN by the FPU instructions. In this case, 'replicate8_imm' returns a double value which is passed to the caller on the FPU stack. Because the value is a signalling NaN, the 'fldl' instruction sets the most-significant fraction bit to 1 (see Chapter 4.8.3.4 of the Intel manual [1] or [2] for a similar problem). >>>> >>>> This code was introduced by JDK-7119644 [3]. I think we should not use doubles/floats in the C code but ints/longs because those constants should not be treated as floating point values. For consistency, I also changed this on SPARC although I'm not aware of any problems there. With the fix, the constant table contains the correct value: >>>> >>>> [Constants] >>>> 0xee4154c0 (offset: 0): 0xfff7fff7 0xfff7fff7fff7fff7 >>>> 0xee4154c4 (offset: 4): 0xfff7fff7 >>>> >>>> Tested with failing testcase, JPRT and RBT (running). >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf >>>> [2] http://stackoverflow.com/questions/22816095/signalling-nan-was-corrupted-when-returning-from-x86-function-flds-fstps-of-x87 >>>> [3] https://bugs.openjdk.java.net/browse/JDK-7119644 >>>> From vladimir.kozlov at oracle.com Tue Jun 28 16:32:41 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jun 2016 09:32:41 -0700 Subject: RFR: 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI In-Reply-To: References: <5162b163-3dfc-3571-187d-b534c1994667@oracle.com> Message-ID: <5ce3aa78-5dca-43ee-3f33-51aecba115aa@oracle.com> Looks good. Thanks, Vladimir On 6/27/16 7:56 PM, Tom Rodriguez wrote: > Some side discussion generated a minor change to this fix. > simpleThresholdPolicy.cpp already had a check that JVMCI was in phase 2 > before allowing compile, so instead of checking this over in > jvmciCompiler.cpp I?ve modified the exist check to require phase 3. The > new webrev is http://cr.openjdk.java.net/~never/8160121-v3/webrev. The > only difference is there are no changes in jvmciCompiler.cpp and there > are new changes in simpleThresholdPolicy.cpp. > > tom > >> On Jun 23, 2016, at 10:06 AM, Vladimir Kozlov >> > wrote: >> >> Looks good. >> >> Thanks, >> Vladimir >> >> On 6/23/16 8:55 AM, Doug Simon wrote: >>> JVMCI cannot be initialized until after VM init phase 3 as it >>> requires the jdk.vm.ci module to be available (phase 2) and >>> ServiceLoader to be working (phase 3). This change moves the eager >>> initialization of JVMCI (under the condition of !UseInterpreter || >>> !BackgroundCompilation) to be after phase 3 as well as causing JVMCI >>> compilations before phase 3 to be ignored. >>> >>> Thanks to Tom for most of this code! >>> >>> https://bugs.openjdk.java.net/browse/JDK-8160121 >>> http://cr.openjdk.java.net/~dnsimon/8160121/ >>> >>> -Doug >>> > From vladimir.x.ivanov at oracle.com Tue Jun 28 16:53:51 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Jun 2016 19:53:51 +0300 Subject: RFR: 8153194: PreserveFPRegistersTest.java runs out of memory in the nightlies In-Reply-To: <49e3dee1-bd9e-4947-b740-dc2c8b971cef@default> References: <47ea70f9-e79e-45c7-9e77-7de9c7cdd5fa@default> <99835b15-d289-d6d5-4815-34bc86f2e7ab@oracle.com> <49e3dee1-bd9e-4947-b740-dc2c8b971cef@default> Message-ID: <052c30ac-dcb1-17de-6996-ed93a778781e@oracle.com> Rahul, > Thank you Vladimir for your comments. > Yes, agree to your points and made the changes. > Also additionally added @build (found required when tried the single test run in RBT) > Please check the revised : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.01/ > No issues found with local jtreg testing, RBT . The following lines are redundant: test/compiler/gcbarriers/PreserveFPRegistersTest.java: + * @build ClassFileInstaller sun.hotspot.WhiteBox + * @run main ClassFileInstaller sun.hotspot.WhiteBox No need to install WhiteBox anywhere, bootclasspath mode already handles it. Otherwise, looks good. Best regards, Vladimir Ivanov >> -----Original Message----- >> From: Vladimir Ivanov > Sent: Wednesday, June 22, 2016 11:46 PM >> >> Thanks for taking care of the bug, Rahul. >> >>> Please review the following test fix patch for JDK-8153194. >>> : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.00/ >> >> + * @run main ClassFileInstaller sun.hotspot.WhiteBox >> + * @run main/othervm/timeout=300 -XX:+UnlockDiagnosticVMOptions >> + * -XX:+WhiteBoxAPI -Xbatch -Xbootclasspath/a:. >> >> You can use "@run main/bootclasspath/othervm" instead. >> >> >> + long regionSize = wb.g1RegionSize(); >> >> What happens if G1 isn't used? Either explicitly specify -XX:+UseG1GC or >> use @requires. >> >> Otherwise, looks good. >> >> Best regards, >> Vladimir Ivanov >> >>> >>> >>> Notes: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8153194 - PreserveFPRegistersTest.java runs out of memory in the nightlies >>> https://bugs.openjdk.java.net/browse/JDK-8148175 - C1: G1 barriers don't preserve FP registers >>> >>> - 'hotspot/test/compiler/gcbarriers/PreserveFPRegistersTest.java' was added as part of the old JDK-8148175 fix. >>> - The 'PreserveFPRegistersTest.java' started failing in nightly tests for 64-bit targets only with -XX:-UseCompressedOops enabled. >>> - Found wrong hard coded usage of reference size as 32 bits in test caused OutOfMemoryError, for -XX:-UseCompressedOops >> cases. >>> >>> Changes done - >>> - Actual fix of setting reference size using WhiteBox.getHeapOopSize() and removed @ignore. >>> - Used WhiteBox.g1RegionSize() instead of hard coded value. >>> - Used -Xmx300m instead of -Xmx128m for run VM options. >>> (found this change is required for the test to fail correctly using old JDK9 builds prior to JDK-8148175 fix. >>> e.g.: for test to fail with "java.lang.AssertionError: Final value has changed: 0.0 != 6.0" using JDK9-b113. >>> Please note same -Xmx300m used for failing case reported in JDK-8148175. >>> - Added diagnostic output. >>> >>> Testing done - >>> - Confirmed revised test fails as expected using old jdk9 builds prior to JDK-8148175 fix (e.g.: JDK9-b113) >>> >> [Test finished: compiler/gcbarriers/PreserveFPRegistersTest.java: Failed. Execution failed: `main' threw exception: >> java.lang.AssertionError: Final value has changed: 0.0 != 6.0] >>> (for default run and with -XX:-UseCompressedOops) >>> >>> - Confirmed revised test is passing for latest source build (.i.e. with JDK-8148175 fix, starting from JDK9-b114) >>> (with and without -XX:-UseCompressedOops) >>> >>> >>> Thanks, >>> Rahul >>> From vladimir.kozlov at oracle.com Tue Jun 28 16:54:10 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jun 2016 09:54:10 -0700 Subject: [9] RFR (S): 8159431: C1 arraycopy intrinsic type checks missing In-Reply-To: <57716E62.10207@oracle.com> References: <576D5A40.9080404@oracle.com> <576DBA96.20004@oracle.com> <57716E62.10207@oracle.com> Message-ID: Looks good. But you need to fix ot for aarch64 and ppc64 too. Please, ask SAP and RH for help with code and testing change if needed. Thanks, Vladimir On 6/27/16 11:20 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > thank you for the feedback! > > On 06/25/2016 12:56 AM, Vladimir Kozlov wrote: >> Zoltan, check that klass is not j.l.Object is not enough. >> See next code in stub generators how to check for arrays (similar code >> exists on all platforms): >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ff0c5aa32086/src/cpu/x86/vm/stubGenerator_x86_64.cpp#l2649 >> > > right, thank you for catching that! > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8159431/webrev.01/ > > Testing: JPRT (testset hotspot). > > Thank you! > > Best regards, > > > Zoltan > >> >> Thanks, >> Vladimir >> >> On 6/24/16 9:05 AM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the patch for 8159431. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8159431 >>> >>> Problem: The C1 intrinsic for >>> java.lang.System.arraycopy(Object src, int srcPos, Object dest, int >>> destPos, int length) >>> >>> does not verify that 'src' or 'dest' is a "proper" array. As a >>> result, the intrinsic reads the non-existing 'length' field from >>> java.lang.Object (i.e., the intrinsic reads past the end of the >>> java.lang.Object instance), which is incorrect. >>> >>> Also, the intrinsic only checks if 'src' is a subclass of 'dest' >>> before writing into 'dest' without checking the special case >>> 'dest'==java.lang.Object. That can result in data being written to a >>> random heap location instead of the required ArrayStoreException >>> being thrown. >>> >>> Solution: Check the type of 'src' and 'dest' at runtime if the >>> compiler was not able to prove at compile-time that 'src' and 'dest' >>> are "proper" arrays. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~zmajo/8159431/webrev.00/ >>> >>> Testing: JPRT (testset hotspot). >>> >>> I'll do an RBT run once the code is close to its final shape. >>> >>> The problem was originally reported by Xiang Yuan from Linaro. Once >>> the code is reviewed, I plan to push the patch with Xiang and myself >>> as contributors. >>> >>> The open arm port and ppc are also likely to be affected. I'll file >>> bugs for those architectures and notify persons working on the >>> appropriate ports. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> > From zoltan.majo at oracle.com Tue Jun 28 17:05:13 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 28 Jun 2016 19:05:13 +0200 Subject: [9] RFR (S): 8159431: C1 arraycopy intrinsic type checks missing In-Reply-To: References: <576D5A40.9080404@oracle.com> <576DBA96.20004@oracle.com> <57716E62.10207@oracle.com> Message-ID: <5772AE49.6090207@oracle.com> Hi Vladimir, On 06/28/2016 06:54 PM, Vladimir Kozlov wrote: > Looks good. But you need to fix ot for aarch64 and ppc64 too. Please, > ask SAP and RH for help with code and testing change if needed. thank you, Vladimir! OK, I'll contact SAP and RH then. Best regards, Zoltan > > Thanks, > Vladimir > > On 6/27/16 11:20 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> thank you for the feedback! >> >> On 06/25/2016 12:56 AM, Vladimir Kozlov wrote: >>> Zoltan, check that klass is not j.l.Object is not enough. >>> See next code in stub generators how to check for arrays (similar code >>> exists on all platforms): >>> >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ff0c5aa32086/src/cpu/x86/vm/stubGenerator_x86_64.cpp#l2649 >>> >>> >> >> right, thank you for catching that! >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8159431/webrev.01/ >> >> Testing: JPRT (testset hotspot). >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> Thanks, >>> Vladimir >>> >>> On 6/24/16 9:05 AM, Zolt?n Maj? wrote: >>>> Hi, >>>> >>>> >>>> please review the patch for 8159431. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8159431 >>>> >>>> Problem: The C1 intrinsic for >>>> java.lang.System.arraycopy(Object src, int srcPos, Object dest, int >>>> destPos, int length) >>>> >>>> does not verify that 'src' or 'dest' is a "proper" array. As a >>>> result, the intrinsic reads the non-existing 'length' field from >>>> java.lang.Object (i.e., the intrinsic reads past the end of the >>>> java.lang.Object instance), which is incorrect. >>>> >>>> Also, the intrinsic only checks if 'src' is a subclass of 'dest' >>>> before writing into 'dest' without checking the special case >>>> 'dest'==java.lang.Object. That can result in data being written to a >>>> random heap location instead of the required ArrayStoreException >>>> being thrown. >>>> >>>> Solution: Check the type of 'src' and 'dest' at runtime if the >>>> compiler was not able to prove at compile-time that 'src' and 'dest' >>>> are "proper" arrays. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~zmajo/8159431/webrev.00/ >>>> >>>> Testing: JPRT (testset hotspot). >>>> >>>> I'll do an RBT run once the code is close to its final shape. >>>> >>>> The problem was originally reported by Xiang Yuan from Linaro. Once >>>> the code is reviewed, I plan to push the patch with Xiang and myself >>>> as contributors. >>>> >>>> The open arm port and ppc are also likely to be affected. I'll file >>>> bugs for those architectures and notify persons working on the >>>> appropriate ports. >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >> From tom.rodriguez at oracle.com Tue Jun 28 17:15:41 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 28 Jun 2016 10:15:41 -0700 Subject: RFR: 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI In-Reply-To: <5ce3aa78-5dca-43ee-3f33-51aecba115aa@oracle.com> References: <5162b163-3dfc-3571-187d-b534c1994667@oracle.com> <5ce3aa78-5dca-43ee-3f33-51aecba115aa@oracle.com> Message-ID: <2F00178A-79FE-454A-AF76-12284F2C1D53@oracle.com> Thanks! tom > On Jun 28, 2016, at 9:32 AM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 6/27/16 7:56 PM, Tom Rodriguez wrote: >> Some side discussion generated a minor change to this fix. >> simpleThresholdPolicy.cpp already had a check that JVMCI was in phase 2 >> before allowing compile, so instead of checking this over in >> jvmciCompiler.cpp I?ve modified the exist check to require phase 3. The >> new webrev is http://cr.openjdk.java.net/~never/8160121-v3/webrev. The >> only difference is there are no changes in jvmciCompiler.cpp and there >> are new changes in simpleThresholdPolicy.cpp. >> >> tom >> >>> On Jun 23, 2016, at 10:06 AM, Vladimir Kozlov >>> > wrote: >>> >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/23/16 8:55 AM, Doug Simon wrote: >>>> JVMCI cannot be initialized until after VM init phase 3 as it >>>> requires the jdk.vm.ci module to be available (phase 2) and >>>> ServiceLoader to be working (phase 3). This change moves the eager >>>> initialization of JVMCI (under the condition of !UseInterpreter || >>>> !BackgroundCompilation) to be after phase 3 as well as causing JVMCI >>>> compilations before phase 3 to be ignored. >>>> >>>> Thanks to Tom for most of this code! >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8160121 >>>> http://cr.openjdk.java.net/~dnsimon/8160121/ >>>> >>>> -Doug >>>> >> From pavel.punegov at oracle.com Tue Jun 28 17:33:41 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Tue, 28 Jun 2016 20:33:41 +0300 Subject: 8160471: compiler/rangechecks/TestRangeCheckEliminationDisabled.java fails after JDK-8150900 Message-ID: <9F593B54-D829-4755-8366-5F3D3B813059@oracle.com> Hi, please review this small fix that adds UnlockDiagnosticVMOptions. The test began to fail in product builds after the fix for JDK-8150900 that makes PostLoopMultiversioning a diagnostic option. webrev: http://cr.openjdk.java.net/~ppunegov/8160471/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8160471 ? Thanks, Pavel Punegov -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Tue Jun 28 17:45:13 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Jun 2016 19:45:13 +0200 Subject: 8160471: compiler/rangechecks/TestRangeCheckEliminationDisabled.java fails after JDK-8150900 In-Reply-To: <9F593B54-D829-4755-8366-5F3D3B813059@oracle.com> References: <9F593B54-D829-4755-8366-5F3D3B813059@oracle.com> Message-ID: <5772B7A9.80108@oracle.com> Hi Pavel, looks good, thanks for fixing this! Best regards, Tobias On 28.06.2016 19:33, Pavel Punegov wrote: > Hi, > > please review this small fix that adds UnlockDiagnosticVMOptions. > The test began to fail in product builds after the fix for JDK-8150900 that makes PostLoopMultiversioning a diagnostic option. > > webrev: http://cr.openjdk.java.net/~ppunegov/8160471/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8160471 > > > ? Thanks, > Pavel Punegov > From vladimir.kozlov at oracle.com Tue Jun 28 18:01:26 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Jun 2016 11:01:26 -0700 Subject: 8160471: compiler/rangechecks/TestRangeCheckEliminationDisabled.java fails after JDK-8150900 In-Reply-To: <9F593B54-D829-4755-8366-5F3D3B813059@oracle.com> References: <9F593B54-D829-4755-8366-5F3D3B813059@oracle.com> Message-ID: <9b6e08c4-ce8e-5829-af47-88141923d9e9@oracle.com> Good. Thanks, Vladimir On 6/28/16 10:33 AM, Pavel Punegov wrote: > Hi, > > please review this small fix that adds UnlockDiagnosticVMOptions. > The test began to fail in product builds after the fix for JDK-8150900 > that makes PostLoopMultiversioning a diagnostic option. > > webrev: http://cr.openjdk.java.net/~ppunegov/8160471/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8160471 > > > ? Thanks, > Pavel Punegov > From cthalinger at twitter.com Tue Jun 28 23:19:54 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Tue, 28 Jun 2016 13:19:54 -1000 Subject: RFR: 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI In-Reply-To: References: <5162b163-3dfc-3571-187d-b534c1994667@oracle.com> Message-ID: <7116C346-E2E0-4326-A4CD-CE63F4F4C740@twitter.com> src/share/vm/runtime/simpleThresholdPolicy.cpp + assert(Universe::is_module_initialized(), "must be"); Shouldn?t that be !Universe::is_module_initialized()? No, that?s wrong too. I don?t think you can have this assert. > On Jun 27, 2016, at 4:56 PM, Tom Rodriguez wrote: > > Some side discussion generated a minor change to this fix. simpleThresholdPolicy.cpp already had a check that JVMCI was in phase 2 before allowing compile, so instead of checking this over in jvmciCompiler.cpp I?ve modified the exist check to require phase 3. The new webrev is http://cr.openjdk.java.net/~never/8160121-v3/webrev . The only difference is there are no changes in jvmciCompiler.cpp and there are new changes in simpleThresholdPolicy.cpp. > > tom > >> On Jun 23, 2016, at 10:06 AM, Vladimir Kozlov > wrote: >> >> Looks good. >> >> Thanks, >> Vladimir >> >> On 6/23/16 8:55 AM, Doug Simon wrote: >>> JVMCI cannot be initialized until after VM init phase 3 as it requires the jdk.vm.ci module to be available (phase 2) and ServiceLoader to be working (phase 3). This change moves the eager initialization of JVMCI (under the condition of !UseInterpreter || !BackgroundCompilation) to be after phase 3 as well as causing JVMCI compilations before phase 3 to be ignored. >>> >>> Thanks to Tom for most of this code! >>> >>> https://bugs.openjdk.java.net/browse/JDK-8160121 >>> http://cr.openjdk.java.net/~dnsimon/8160121/ >>> >>> -Doug >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.rodriguez at oracle.com Wed Jun 29 00:23:39 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 28 Jun 2016 17:23:39 -0700 Subject: RFR: 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI In-Reply-To: <7116C346-E2E0-4326-A4CD-CE63F4F4C740@twitter.com> References: <5162b163-3dfc-3571-187d-b534c1994667@oracle.com> <7116C346-E2E0-4326-A4CD-CE63F4F4C740@twitter.com> Message-ID: <8583CE44-BA92-41E5-8BD8-7E8B0167B829@oracle.com> I rearranged that during the push. + // We can't compile with a JVMCI compiler until the module system is initialized past + // phase 3. The JVMCI API itself isn't available until phase 2 and ServiceLoader isn't + // usable until after phase 3. + if (level == CompLevel_full_optimization && EnableJVMCI && UseJVMCICompiler) { + if (SystemDictionary::java_system_loader() == NULL) { + return; + } + assert(Universe::is_module_initialized(), "must be"); tom > On Jun 28, 2016, at 4:19 PM, Christian Thalinger wrote: > > src/share/vm/runtime/simpleThresholdPolicy.cpp > > + assert(Universe::is_module_initialized(), "must be"); > Shouldn?t that be !Universe::is_module_initialized()? No, that?s wrong too. I don?t think you can have this assert. > >> On Jun 27, 2016, at 4:56 PM, Tom Rodriguez > wrote: >> >> Some side discussion generated a minor change to this fix. simpleThresholdPolicy.cpp already had a check that JVMCI was in phase 2 before allowing compile, so instead of checking this over in jvmciCompiler.cpp I?ve modified the exist check to require phase 3. The new webrev is http://cr.openjdk.java.net/~never/8160121-v3/webrev . The only difference is there are no changes in jvmciCompiler.cpp and there are new changes in simpleThresholdPolicy.cpp. >> >> tom >> >>> On Jun 23, 2016, at 10:06 AM, Vladimir Kozlov > wrote: >>> >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/23/16 8:55 AM, Doug Simon wrote: >>>> JVMCI cannot be initialized until after VM init phase 3 as it requires the jdk.vm.ci module to be available (phase 2) and ServiceLoader to be working (phase 3). This change moves the eager initialization of JVMCI (under the condition of !UseInterpreter || !BackgroundCompilation) to be after phase 3 as well as causing JVMCI compilations before phase 3 to be ignored. >>>> >>>> Thanks to Tom for most of this code! >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8160121 >>>> http://cr.openjdk.java.net/~dnsimon/8160121/ >>>> >>>> -Doug >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Wed Jun 29 07:23:18 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 29 Jun 2016 07:23:18 +0000 Subject: RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. In-Reply-To: References: <6725033e7f604e9899c93b2f1fa1be70@DEWDFE13DE09.global.corp.sap> Message-ID: <95f3df9897954151adf1763cf98d3005@DEWDFE13DE09.global.corp.sap> Hi, I changed this to 'Enhancement'. Also, I found another, very similar cleanup which I added to this change: generate_stack_overflow_check() in templateInterpreterGenerator.hpp. I added default parameters noreg so that the signature is the same for all Platforms. I think it makes sense to add this because aarch and the closed platforms need to be tested with this, and this way double work can be avoided. I would appreciate to get a review for this rather simple change! http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.01 Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz > Sent: Freitag, 24. Juni 2016 16:35 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RE: RFR(M): 8160245: C1: Clean up platform #defines in c1_LIR.hpp. > > Sorry, the webrev URL was missing, added below: > > Hi, > > c1_LIR.hpp defines a row of functions guarded by platform > defines. This is bad style and hinders new platform ports. > (I'm working on S390 aka Z :)) > > This change removes the majority of these defines. It introduces > common headers, and moves implementations to c1_LIR_.cpp files. > > It guards single_softfp() and double_softfp() by __SOFTFP__. > This is not used in any openJdk platform. I can not test this > on the closed platforms ARM32 and PPC32. > > It removes the guard around the LIR_Address constructor. There > is no point in guarding this code, verify() assures by > assertions that it can not be misused. I also introduce a new > constructor that leaves out the scale argument and introduced > some usages on X86. > > This change also moves verify() to the new platform files. In the > header, LIR_ADDRESS_PD_VERIFY was used to guard usage > of pd_verify(). Neither of these are used in openJdk. If this define > is used in the closed ports pd_verify() must be renamed to verify(). > > The code that was previously guarded by ARM, ARM32 or PPC32 is > moved to a properly guarded section in c1_LIR.cpp. Actually, > it should be moved to according new files c1_LIR_.cpp in > the closed ports. But this way the change should basically > work for the closed ports. > > I added fnoreg on x86 to note down the code similarly on all > Platforms. > > I cleaned up a flag with a limited range on PPC_32. > > Please review this change. I please need a sponsor. > https://bugs.openjdk.java.net/browse/JDK-8160245 > http://cr.openjdk.java.net/~goetz/wr16/8160245-simplifyC1/webrev.01/ > > I built and tested this on linuxx86_64, solaris_sparc and the ppc platforms. > > Best regards, > Goetz From edward.nevill at gmail.com Wed Jun 29 09:17:49 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 29 Jun 2016 10:17:49 +0100 Subject: RFR: 8156943: aarch64: string compare does not support CompactStrings In-Reply-To: <574411E3.70806@redhat.com> References: <573F25DA.8000202@redhat.com> <573F34A2.70108@redhat.com> <1464078397.31264.25.camel@mylittlepony.linaroharston> <574411E3.70806@redhat.com> Message-ID: <1467191869.27591.3.camel@gmail.com> On Tue, 2016-05-24 at 09:33 +0100, Andrew Haley wrote: > On 05/24/2016 09:26 AM, Edward Nevill wrote: > > > > http://cr.openjdk.java.net/~enevill/8156943/webrev.02/ > > > > The different cases are handled as follows > > > > LL: 8 chars are loaded to each of 2 general regs > > UU: 4 chars are loaded to each of 2 general regs > > LU/UL: 4 U chars loaded to 1 general regs, 4 L chars loaded to a > > simd reg, zip1 used to convert L to U and then moved to a general > > reg. > > > > Tested fastdebug jtreg hotspot and langtools, > That looks fine, thanks. Hi, I have updated this so it applies cleanly after 8157834: aarch64: Hello World crashes with fastdebug build http://cr.openjdk.java.net/~enevill/8156943/webrev.03/ https://bugs.openjdk.java.net/browse/JDK-8156943 'jdk9-fc-yes' approved. OK to push? Ed. From aph at redhat.com Wed Jun 29 09:31:29 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Jun 2016 10:31:29 +0100 Subject: RFR: 8156943: aarch64: string compare does not support CompactStrings In-Reply-To: <1467191869.27591.3.camel@gmail.com> References: <573F25DA.8000202@redhat.com> <573F34A2.70108@redhat.com> <1464078397.31264.25.camel@mylittlepony.linaroharston> <574411E3.70806@redhat.com> <1467191869.27591.3.camel@gmail.com> Message-ID: <57739571.2020203@redhat.com> On 29/06/16 10:17, Edward Nevill wrote: > OK to push? I noticed another build failure yesterday because of a missing include file: diff -r 83e5b5190020 src/cpu/aarch64/vm/macroAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Thu Jun 23 17:58:59 2016 +0000 +++ b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Wed Jun 29 10:31:14 2016 +0100 @@ -36,6 +36,7 @@ #include "oops/klass.inline.hpp" #include "oops/oop.inline.hpp" #include "opto/compile.hpp" +#include "opto/intrinsicnode.hpp" #include "opto/node.hpp" #include "runtime/biasedLocking.hpp" #include "runtime/icache.hpp" From edward.nevill at gmail.com Wed Jun 29 10:02:31 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 29 Jun 2016 11:02:31 +0100 Subject: RFR: 8156943: aarch64: string compare does not support CompactStrings In-Reply-To: <57739571.2020203@redhat.com> References: <573F25DA.8000202@redhat.com> <573F34A2.70108@redhat.com> <1464078397.31264.25.camel@mylittlepony.linaroharston> <574411E3.70806@redhat.com> <1467191869.27591.3.camel@gmail.com> <57739571.2020203@redhat.com> Message-ID: <1467194551.27591.16.camel@gmail.com> On Wed, 2016-06-29 at 10:31 +0100, Andrew Haley wrote: > On 29/06/16 10:17, Edward Nevill wrote: > > > > OK to push? > I noticed another build failure yesterday because of a missing > include > file: Seemd to build OK for me. You are building without precompiled headers? Ed. From tatiana.pivovarova at oracle.com Wed Jun 29 10:13:58 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Wed, 29 Jun 2016 13:13:58 +0300 Subject: [9] RFR(XXS): 8153515: [ctw] CompileTheWorld testlibrary should trigger compilation of and Message-ID: <57739F66.8060501@oracle.com> Hello! Please review this small patch Summary: The CompileTheWorld test library does not trigger compilation of static initializers and constructors. This should be fixed to increase coverage. webrev : http://cr.openjdk.java.net/~tpivovarova/8153515/webrev.00/ bug : https://bugs.openjdk.java.net/browse/JDK-8153515 Tested locally Tanks, Tatiana -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Jun 29 10:13:19 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Jun 2016 11:13:19 +0100 Subject: RFR: 8156943: aarch64: string compare does not support CompactStrings In-Reply-To: <1467194551.27591.16.camel@gmail.com> References: <573F25DA.8000202@redhat.com> <573F34A2.70108@redhat.com> <1464078397.31264.25.camel@mylittlepony.linaroharston> <574411E3.70806@redhat.com> <1467191869.27591.3.camel@gmail.com> <57739571.2020203@redhat.com> <1467194551.27591.16.camel@gmail.com> Message-ID: <57739F3F.7070702@redhat.com> On 29/06/16 11:02, Edward Nevill wrote: > Seemd to build OK for me. You are building without precompiled headers? Yes. Checkins must make sure that include files aren't broken, and the only way to do this is to build without precompiled headers. Andrew. From tobias.hartmann at oracle.com Wed Jun 29 10:39:37 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 29 Jun 2016 12:39:37 +0200 Subject: [9] RFR(XXS): 8153515: [ctw] CompileTheWorld testlibrary should trigger compilation of and In-Reply-To: <57739F66.8060501@oracle.com> References: <57739F66.8060501@oracle.com> Message-ID: <5773A569.5090804@oracle.com> Hi Tatiana, looks good to me. Thanks for fixing this! Best regards, Tobias On 29.06.2016 12:13, Tatiana Pivovarova wrote: > Hello! > > Please review this small patch > Summary: > The CompileTheWorld test library does not trigger compilation of static initializers and constructors. This should be fixed to increase coverage. > > webrev : http://cr.openjdk.java.net/~tpivovarova/8153515/webrev.00/ > bug : https://bugs.openjdk.java.net/browse/JDK-8153515 > > Tested locally > > Tanks, > Tatiana From tobias.hartmann at oracle.com Wed Jun 29 10:57:10 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 29 Jun 2016 12:57:10 +0200 Subject: [9] RFR(S): 8159129: TestStringIntrinsicRangeChecks fails w/ No exception thrown for compressByte/inflateByte Message-ID: <5773A986.4090106@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8159129 http://cr.openjdk.java.net/~thartmann/8159129/webrev.00/ The test fails because the inflate/compress String intrinsic sometimes does not throw an exception if the src or dst offset are out of bounds. The problem is that we convert the char offsets to byte offsets only after the range check. We should do this before. To avoid such errors, we should try to move the range checks from the intrinsics into the Java code (I'll investigate this with JDK-8156534). I also slightly adapted the test to trigger this problem more often. Before, the intrinsic was not always used because the compile threshold wasn't reached or we issued too many compilations and the test finished before the compiled method was available. I noticed that in Compile::too_many_traps() we "// Assume PerBytecodeTrapLimit==0, for a more conservative heuristic." and therefore stop using the intrinsic if too many traps occurred even though PerBytecodeTrapLimit was not yet reached. Shouldn't we check something like "md->trap_count(reason) > PerBytecodeTrapLimit"? Tested with JPRT and RBT (running). Thanks, Tobias From tatiana.pivovarova at oracle.com Wed Jun 29 11:28:09 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Wed, 29 Jun 2016 14:28:09 +0300 Subject: [9] RFR(XXS): 8153515: [ctw] CompileTheWorld testlibrary should trigger compilation of and In-Reply-To: <5773A569.5090804@oracle.com> References: <57739F66.8060501@oracle.com> <5773A569.5090804@oracle.com> Message-ID: <5773B0C9.9060109@oracle.com> Hi Tobias, thanks for your review! Tatiana On 06/29/2016 01:39 PM, Tobias Hartmann wrote: > Hi Tatiana, > > looks good to me. Thanks for fixing this! > > Best regards, > Tobias > > On 29.06.2016 12:13, Tatiana Pivovarova wrote: >> Hello! >> >> Please review this small patch >> Summary: >> The CompileTheWorld test library does not trigger compilation of static initializers and constructors. This should be fixed to increase coverage. >> >> webrev : http://cr.openjdk.java.net/~tpivovarova/8153515/webrev.00/ >> bug : https://bugs.openjdk.java.net/browse/JDK-8153515 >> >> Tested locally >> >> Tanks, >> Tatiana -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.nevill at gmail.com Wed Jun 29 11:28:46 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 29 Jun 2016 12:28:46 +0100 Subject: RFR: 8160534: aarch64: fails to build after 8157834 In-Reply-To: <57739F3F.7070702@redhat.com> References: <573F25DA.8000202@redhat.com> <573F34A2.70108@redhat.com> <1464078397.31264.25.camel@mylittlepony.linaroharston> <574411E3.70806@redhat.com> <1467191869.27591.3.camel@gmail.com> <57739571.2020203@redhat.com> <1467194551.27591.16.camel@gmail.com> <57739F3F.7070702@redhat.com> Message-ID: <1467199726.27591.22.camel@gmail.com> Hi, Please review the following webrev which fixes a build failure introduced by 8157834. http://cr.openjdk.java.net/~enevill/8160534 https://bugs.openjdk.java.net/browse/JDK-8160534 Thanks, Ed. From aph at redhat.com Wed Jun 29 11:32:34 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Jun 2016 12:32:34 +0100 Subject: RFR: 8160534: aarch64: fails to build after 8157834 In-Reply-To: <1467199726.27591.22.camel@gmail.com> References: <573F25DA.8000202@redhat.com> <573F34A2.70108@redhat.com> <1464078397.31264.25.camel@mylittlepony.linaroharston> <574411E3.70806@redhat.com> <1467191869.27591.3.camel@gmail.com> <57739571.2020203@redhat.com> <1467194551.27591.16.camel@gmail.com> <57739F3F.7070702@redhat.com> <1467199726.27591.22.camel@gmail.com> Message-ID: <5773B1D2.7080508@redhat.com> On 29/06/16 12:28, Edward Nevill wrote: > Please review the following webrev which fixes a build failure introduced by 8157834. > > http://cr.openjdk.java.net/~enevill/8160534 > > https://bugs.openjdk.java.net/browse/JDK-8160534 OK, thanks. Andrew. From rwestrel at redhat.com Wed Jun 29 12:19:07 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 29 Jun 2016 14:19:07 +0200 Subject: inconsistent inlining behavior with CompileOnly Message-ID: With the testcase below, executed with latest hs-comp with: java -XX:CompileOnly=TestCompileCommand::m1 -XX:CompileOnly=TestCompileCommand::m2 -XX:CompileCommand=quiet -XX:-BackgroundCompilation -XX:+PrintCompilation -XX:+PrintInlining -XX:-TieredCompilation TestCompileCommand I get the following output: 170 1 b TestCompileCommand::m1 (4 bytes) @ 0 TestCompileCommand::m1_notinlined (1 bytes) not compilable (disabled) 170 2 b TestCompileCommand::m2 (8 bytes) @ 4 TestCompileCommand::m2_notinlined (1 bytes) inline (hot) Either both m1_notinlined & m2_notinlined should be inlined or neither should be. Is this a known issue? Roland. public class TestCompileCommand { static void m1_notinlined() { } static void m1() { m1_notinlined(); } static void m2_notinlined() { } static void m2(boolean flag) { if (flag) { m2_notinlined(); } } static public void main(String[] args) { for (int i = 0; i < 20000; i++) { m1_notinlined(); m1_notinlined(); m1(); m2((i%2) == 0); } } } From doug.simon at oracle.com Wed Jun 29 12:23:55 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 29 Jun 2016 14:23:55 +0200 Subject: REF: 8159888: [JVMCI] the client VM build is broken when INCLUDE_JVMCI is defined Message-ID: <26E91037-4C75-4667-BB81-E743D6EF2294@oracle.com> Even though client+JVMCI (i.e., !TIERED && COMPILER1 && INCLUDE_JVMCI) doesn?t appear to be a supported configuration, it should still be buildable and produce a working VM where a JVMCI compiler can be used in hosted mode. This bug addresses that. I was able to build an exploded jdk but building an image failed in a way I cannot understand: Building these configurations (matching CONF=release): * linux-x86_64-normal-client-release * linux-x86_64-normal-server-release Building target 'images' in configuration 'linux-x86_64-normal-client-release' Building JVM variant 'client' with features 'all-gcs cds compiler1 fprof jni-check jvmci jvmti management nmt services vm-structs' make[3]: *** [/home/dsimon/hs-comp/build/linux-x86_64-normal-client-release/support/classlist/classlist] Error 4 make[2]: *** [generate-classlist] Error 1 ERROR: Build failed for target 'images' in configuration 'linux-x86_64-normal-client-release' (exit code 2) No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: If caused by a warning, try configure --disable-warnings-as-errors. make[1]: *** [main] Error 1 make: *** [images] Error 2 Using the exploded jdk, I tested the changes on Graal. I had to manually edit build/linux-x86_64-normal-client-release/jdk/lib/amd64/jvm.cfg from: -server KNOWN -client IGNORE to: -client KNOWN -server IGNORE This file appears to be directly copied from jdk/src/java.base/unix/conf/amd64/jvm.cfg. If/when client builds on amd64 are supported, obviously the generation of jvm.cfg will have to be a little more dynamic. https://bugs.openjdk.java.net/browse/JDK-8159888 http://cr.openjdk.java.net/~dnsimon/8159888/ -Doug From tobias.hartmann at oracle.com Wed Jun 29 12:44:36 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 29 Jun 2016 14:44:36 +0200 Subject: inconsistent inlining behavior with CompileOnly In-Reply-To: References: Message-ID: <5773C2B4.8070908@oracle.com> Hi Roland, the only issue with CompileOnly I'm aware of is: https://bugs.openjdk.java.net/browse/JDK-8071652 Maybe Nils knows more but he's currently on vacation. Have you checked this with -XX:CompileCommand=compileonly ? Best regards, Tobias On 29.06.2016 14:19, Roland Westrelin wrote: > > With the testcase below, executed with latest hs-comp with: > > java -XX:CompileOnly=TestCompileCommand::m1 -XX:CompileOnly=TestCompileCommand::m2 -XX:CompileCommand=quiet -XX:-BackgroundCompilation -XX:+PrintCompilation -XX:+PrintInlining -XX:-TieredCompilation TestCompileCommand > > I get the following output: > > 170 1 b TestCompileCommand::m1 (4 bytes) > @ 0 TestCompileCommand::m1_notinlined (1 bytes) not compilable (disabled) > 170 2 b TestCompileCommand::m2 (8 bytes) > @ 4 TestCompileCommand::m2_notinlined (1 bytes) inline (hot) > > Either both m1_notinlined & m2_notinlined should be inlined or neither > should be. Is this a known issue? > > Roland. > > > public class TestCompileCommand { > > static void m1_notinlined() { > } > > static void m1() { > m1_notinlined(); > } > > static void m2_notinlined() { > } > > static void m2(boolean flag) { > if (flag) { > m2_notinlined(); > } > } > > static public void main(String[] args) { > for (int i = 0; i < 20000; i++) { > m1_notinlined(); > m1_notinlined(); > m1(); > m2((i%2) == 0); > } > } > } > From rwestrel at redhat.com Wed Jun 29 12:50:14 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 29 Jun 2016 14:50:14 +0200 Subject: inconsistent inlining behavior with CompileOnly In-Reply-To: <5773C2B4.8070908@oracle.com> References: <5773C2B4.8070908@oracle.com> Message-ID: <5773C406.20105@redhat.com> Hi Tobias, > the only issue with CompileOnly I'm aware of is: > https://bugs.openjdk.java.net/browse/JDK-8071652 > > Maybe Nils knows more but he's currently on vacation. > > Have you checked this with -XX:CompileCommand=compileonly ? Same behavior with CompileCommand=compileonly I suspect the problem is that if a compilation of the inlined method as a root of the compilation is attempted before some method tries to inline it, the method is marked as not compilable and then later on, inlining fails. Roland. > > Best regards, > Tobias > > On 29.06.2016 14:19, Roland Westrelin wrote: >> >> With the testcase below, executed with latest hs-comp with: >> >> java -XX:CompileOnly=TestCompileCommand::m1 -XX:CompileOnly=TestCompileCommand::m2 -XX:CompileCommand=quiet -XX:-BackgroundCompilation -XX:+PrintCompilation -XX:+PrintInlining -XX:-TieredCompilation TestCompileCommand >> >> I get the following output: >> >> 170 1 b TestCompileCommand::m1 (4 bytes) >> @ 0 TestCompileCommand::m1_notinlined (1 bytes) not compilable (disabled) >> 170 2 b TestCompileCommand::m2 (8 bytes) >> @ 4 TestCompileCommand::m2_notinlined (1 bytes) inline (hot) >> >> Either both m1_notinlined & m2_notinlined should be inlined or neither >> should be. Is this a known issue? >> >> Roland. >> >> >> public class TestCompileCommand { >> >> static void m1_notinlined() { >> } >> >> static void m1() { >> m1_notinlined(); >> } >> >> static void m2_notinlined() { >> } >> >> static void m2(boolean flag) { >> if (flag) { >> m2_notinlined(); >> } >> } >> >> static public void main(String[] args) { >> for (int i = 0; i < 20000; i++) { >> m1_notinlined(); >> m1_notinlined(); >> m1(); >> m2((i%2) == 0); >> } >> } >> } >> From vladimir.x.ivanov at oracle.com Wed Jun 29 12:52:11 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 Jun 2016 15:52:11 +0300 Subject: [9] RFR (XS): 8160360: Mismatched field loads are folded in LoadNode::Value Message-ID: <4c2063ec-46e5-abfa-e6e3-de489e6ce315@oracle.com> http://cr.openjdk.java.net/~vlivanov/8160360/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8160360 Mismatched access check is absent for fields in LoadNode::Value(). The fix adds missing check. Also, marked all "wide" on-heap accesses as mismatched. It's possible the type is narrowed later (e.g., during post-parse/incremental inlining) and becomes mismatched. Testing: failing tests, JPRT, PIT (hs-tier0-comp). Best regards, Vladimir Ivanov From tobias.hartmann at oracle.com Wed Jun 29 13:20:08 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 29 Jun 2016 15:20:08 +0200 Subject: inconsistent inlining behavior with CompileOnly In-Reply-To: <5773C406.20105@redhat.com> References: <5773C2B4.8070908@oracle.com> <5773C406.20105@redhat.com> Message-ID: <5773CB08.1070907@oracle.com> Hi Roland, On 29.06.2016 14:50, Roland Westrelin wrote: > Hi Tobias, > >> the only issue with CompileOnly I'm aware of is: >> https://bugs.openjdk.java.net/browse/JDK-8071652 >> >> Maybe Nils knows more but he's currently on vacation. >> >> Have you checked this with -XX:CompileCommand=compileonly ? > > Same behavior with CompileCommand=compileonly > I suspect the problem is that if a compilation of the inlined method as > a root of the compilation is attempted before some method tries to > inline it, the method is marked as not compilable and then later on, > inlining fails. Okay, so your saying that TestCompileCommand::m2_notinlined is inlined because it was not compiled as root method before and is therefore not set to not compilable (yet). Looking at the code, we only check CompileBroker::compilation_is_prohibited() in CompileBroker::compile_method() but not when inlining a method. I just executed a small test: java -XX:CompileOnly=java.lang.Thread::exit -XX:+PrintInlining -XX:+PrintCompilation -Xcomp -XX:MaxInlineSize=1000 -XX:CompileCommand=quiet -version This inlines a lot although only Thread::exit should be compiled: 3046 24 b 3 java.lang.Thread::exit (51 bytes) !m @ 12 java.lang.ThreadGroup::threadTerminated (63 bytes) !m @ 6 java.lang.ThreadGroup::remove (94 bytes) @ 59 java.lang.System::arraycopy (0 bytes) intrinsic @ 17 java.lang.Object::notifyAll (0 bytes) native method !m @ 49 java.lang.ThreadGroup::destroy (138 bytes) @ 5 java.lang.ThreadGroup::checkAccess (14 bytes) @ 0 java.lang.System::getSecurityManager (4 bytes) not compilable (disabled) [...] "java.lang.System::getSecurityManager" is compiled before and set to not compilable whereas "java.lang.ThreadGroup::checkAccess" is not compiled before and inlined. So it looks like your theory is correct. Could you file a bug? Best regards, Tobias > > Roland. > >> >> Best regards, >> Tobias >> >> On 29.06.2016 14:19, Roland Westrelin wrote: >>> >>> With the testcase below, executed with latest hs-comp with: >>> >>> java -XX:CompileOnly=TestCompileCommand::m1 -XX:CompileOnly=TestCompileCommand::m2 -XX:CompileCommand=quiet -XX:-BackgroundCompilation -XX:+PrintCompilation -XX:+PrintInlining -XX:-TieredCompilation TestCompileCommand >>> >>> I get the following output: >>> >>> 170 1 b TestCompileCommand::m1 (4 bytes) >>> @ 0 TestCompileCommand::m1_notinlined (1 bytes) not compilable (disabled) >>> 170 2 b TestCompileCommand::m2 (8 bytes) >>> @ 4 TestCompileCommand::m2_notinlined (1 bytes) inline (hot) >>> >>> Either both m1_notinlined & m2_notinlined should be inlined or neither >>> should be. Is this a known issue? >>> >>> Roland. >>> >>> >>> public class TestCompileCommand { >>> >>> static void m1_notinlined() { >>> } >>> >>> static void m1() { >>> m1_notinlined(); >>> } >>> >>> static void m2_notinlined() { >>> } >>> >>> static void m2(boolean flag) { >>> if (flag) { >>> m2_notinlined(); >>> } >>> } >>> >>> static public void main(String[] args) { >>> for (int i = 0; i < 20000; i++) { >>> m1_notinlined(); >>> m1_notinlined(); >>> m1(); >>> m2((i%2) == 0); >>> } >>> } >>> } >>> From rwestrel at redhat.com Wed Jun 29 13:32:46 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 29 Jun 2016 15:32:46 +0200 Subject: inconsistent inlining behavior with CompileOnly In-Reply-To: <5773CB08.1070907@oracle.com> References: <5773C2B4.8070908@oracle.com> <5773C406.20105@redhat.com> <5773CB08.1070907@oracle.com> Message-ID: <5773CDFE.7020204@redhat.com> Tobias, Thanks for looking at this. Here is the bug: https://bugs.openjdk.java.net/browse/JDK-8160548 > This inlines a lot although only Thread::exit should be compiled: > 3046 24 b 3 java.lang.Thread::exit (51 bytes) > !m @ 12 java.lang.ThreadGroup::threadTerminated (63 bytes) > !m @ 6 java.lang.ThreadGroup::remove (94 bytes) > @ 59 java.lang.System::arraycopy (0 bytes) intrinsic > @ 17 java.lang.Object::notifyAll (0 bytes) native method > !m @ 49 java.lang.ThreadGroup::destroy (138 bytes) > @ 5 java.lang.ThreadGroup::checkAccess (14 bytes) > @ 0 java.lang.System::getSecurityManager (4 bytes) not compilable (disabled) > > [...] Is the historical behavior (that excluding some methods from compilation also forbids inlining of those methods) still the expected behavior? FWIW, I really don't like it. It usually gets in the way for typical use cases: I want to only compile a set of methods because I want to focus on them but I still want them to be compiled like they would be without any CompileCommand arguments. Roland. From tobias.hartmann at oracle.com Wed Jun 29 13:38:44 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 29 Jun 2016 15:38:44 +0200 Subject: inconsistent inlining behavior with CompileOnly In-Reply-To: <5773CDFE.7020204@redhat.com> References: <5773C2B4.8070908@oracle.com> <5773C406.20105@redhat.com> <5773CB08.1070907@oracle.com> <5773CDFE.7020204@redhat.com> Message-ID: <5773CF64.7040604@oracle.com> Hi Roland, On 29.06.2016 15:32, Roland Westrelin wrote: > Tobias, > > Thanks for looking at this. Here is the bug: > > https://bugs.openjdk.java.net/browse/JDK-8160548 > >> This inlines a lot although only Thread::exit should be compiled: >> 3046 24 b 3 java.lang.Thread::exit (51 bytes) >> !m @ 12 java.lang.ThreadGroup::threadTerminated (63 bytes) >> !m @ 6 java.lang.ThreadGroup::remove (94 bytes) >> @ 59 java.lang.System::arraycopy (0 bytes) intrinsic >> @ 17 java.lang.Object::notifyAll (0 bytes) native method >> !m @ 49 java.lang.ThreadGroup::destroy (138 bytes) >> @ 5 java.lang.ThreadGroup::checkAccess (14 bytes) >> @ 0 java.lang.System::getSecurityManager (4 bytes) not compilable (disabled) >> >> [...] > > > Is the historical behavior (that excluding some methods from compilation > also forbids inlining of those methods) still the expected behavior? > FWIW, I really don't like it. It usually gets in the way for typical use > cases: I want to only compile a set of methods because I want to focus > on them but I still want them to be compiled like they would be without > any CompileCommand arguments. I'm not sure about this but in the case you pointed out there is clearly an inconsistency. I agree that for most use cases it would be better to only exclude "root compilations" and keep the inlining behavior untouched. Best regards, Tobias > > Roland. > From vladimir.x.ivanov at oracle.com Wed Jun 29 13:54:04 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 Jun 2016 16:54:04 +0300 Subject: inconsistent inlining behavior with CompileOnly In-Reply-To: <5773CDFE.7020204@redhat.com> References: <5773C2B4.8070908@oracle.com> <5773C406.20105@redhat.com> <5773CB08.1070907@oracle.com> <5773CDFE.7020204@redhat.com> Message-ID: > Is the historical behavior (that excluding some methods from compilation > also forbids inlining of those methods) still the expected behavior? It depends on what compile command you are talking about. For "exclude" command such behavior is expected. Disabling compilation of a method is used to workaround compiler bugs and it doesn't matter whether the problematic method is the root of a compilation or being inlined - compiler shouldn't try to compile the method at all. But for "compileonly" I'd prefer to see the behavior you suggest: it affects only root of a compilation and leave inlining decisions intact. I find it much more useful than current behavior. It seems we can do such change (I can't imagine any use cases for "compileonly" except testing), but it requires a CCC request. In the worst case (not allowed to change existing behavior), we can introduce new command. Best regards, Vladimir Ivanov > FWIW, I really don't like it. It usually gets in the way for typical use > cases: I want to only compile a set of methods because I want to focus > on them but I still want them to be compiled like they would be without > any CompileCommand arguments. > > Roland. > From rwestrel at redhat.com Wed Jun 29 14:12:02 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 29 Jun 2016 16:12:02 +0200 Subject: inconsistent inlining behavior with CompileOnly In-Reply-To: References: <5773C2B4.8070908@oracle.com> <5773C406.20105@redhat.com> <5773CB08.1070907@oracle.com> <5773CDFE.7020204@redhat.com> Message-ID: <5773D732.8000705@redhat.com> Hi Vladimir, > For "exclude" command such behavior is expected. Disabling compilation > of a method is used to workaround compiler bugs and it doesn't matter > whether the problematic method is the root of a compilation or being > inlined - compiler shouldn't try to compile the method at all. That makes sense indeed. Roland. From pavel.punegov at oracle.com Wed Jun 29 15:03:55 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 29 Jun 2016 18:03:55 +0300 Subject: 8160471: compiler/rangechecks/TestRangeCheckEliminationDisabled.java fails after JDK-8150900 In-Reply-To: <9b6e08c4-ce8e-5829-af47-88141923d9e9@oracle.com> References: <9F593B54-D829-4755-8366-5F3D3B813059@oracle.com> <9b6e08c4-ce8e-5829-af47-88141923d9e9@oracle.com> Message-ID: <81870D65-59C6-4C78-B300-609211B66DFF@oracle.com> Thank you, Tobias and Vladimir > On 28 Jun 2016, at 21:01, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 6/28/16 10:33 AM, Pavel Punegov wrote: >> Hi, >> >> please review this small fix that adds UnlockDiagnosticVMOptions. >> The test began to fail in product builds after the fix for JDK-8150900 >> that makes PostLoopMultiversioning a diagnostic option. >> >> webrev: http://cr.openjdk.java.net/~ppunegov/8160471/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8160471 >> >> >> ? Thanks, >> Pavel Punegov >> From pavel.punegov at oracle.com Wed Jun 29 16:07:49 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 29 Jun 2016 19:07:49 +0300 Subject: inconsistent inlining behavior with CompileOnly In-Reply-To: <5773D732.8000705@redhat.com> References: <5773C2B4.8070908@oracle.com> <5773C406.20105@redhat.com> <5773CB08.1070907@oracle.com> <5773CDFE.7020204@redhat.com> <5773D732.8000705@redhat.com> Message-ID: <1D293D8B-2A54-48D8-A948-2FF88E1EE21C@oracle.com> Hi Roland, I think CompilerControl could help you if you want to compile only m1 and m2 but disable inlining for other methods. You could use similar directives file: 1 [{ 2 match: ["Test::m1", "Test::m2"], 3 inline: ["-Test::m1_notinlined", "-Test::m2_notinlined"] 4 }, 5 { 6 match: "*.*", 7 c1: { 8 Exclude: true, 9 }, 10 c2: { 11 Exclude: true, 12 } 13 }] $ /Users/ppunegov/Temp/repr/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:CompilerDirectivesFile=directives.json -XX:-BackgroundCompilation -XX:+PrintCompilation -XX:+PrintInlining -XX:-TieredCompilation Test 2 compiler directives added ### Excluding compile: static Test::m1_notinlined made not compilable on levels 0 1 2 3 4 Test::m1_notinlined (1 bytes) excluded by CompileCommand 113 1 b Test::m1 (4 bytes) @ 0 Test::m1_notinlined (1 bytes) not compilable (disabled) 114 2 b Test::m2 (8 bytes) @ 4 Test::m2_notinlined (1 bytes) disallowed by CompileCommand ### Excluding compile: static Test::main made not compilable on levels 0 1 2 3 4 Test::main (39 bytes) excluded by CompileCommand ### Excluding compile: static Test::m2_notinlined made not compilable on levels 0 1 2 3 4 Test::m2_notinlined (1 bytes) excluded by CompileCommand ? Pavel. > On 29 Jun 2016, at 17:12, Roland Westrelin wrote: > > Hi Vladimir, > >> For "exclude" command such behavior is expected. Disabling compilation >> of a method is used to workaround compiler bugs and it doesn't matter >> whether the problematic method is the root of a compilation or being >> inlined - compiler shouldn't try to compile the method at all. > > That makes sense indeed. > > Roland. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cthalinger at twitter.com Wed Jun 29 16:50:49 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 29 Jun 2016 06:50:49 -1000 Subject: RFR: 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI In-Reply-To: <8583CE44-BA92-41E5-8BD8-7E8B0167B829@oracle.com> References: <5162b163-3dfc-3571-187d-b534c1994667@oracle.com> <7116C346-E2E0-4326-A4CD-CE63F4F4C740@twitter.com> <8583CE44-BA92-41E5-8BD8-7E8B0167B829@oracle.com> Message-ID: <32B38AEF-03BA-415F-9EBB-C7C983C8D29E@twitter.com> > On Jun 28, 2016, at 2:23 PM, Tom Rodriguez wrote: > > I rearranged that during the push. > > + // We can't compile with a JVMCI compiler until the module system is initialized past > + // phase 3. The JVMCI API itself isn't available until phase 2 and ServiceLoader isn't > + // usable until after phase 3. > + if (level == CompLevel_full_optimization && EnableJVMCI && UseJVMCICompiler) { > + if (SystemDictionary::java_system_loader() == NULL) { > + return; > + } > + assert(Universe::is_module_initialized(), "must be?); Good. > > tom > >> On Jun 28, 2016, at 4:19 PM, Christian Thalinger > wrote: >> >> src/share/vm/runtime/simpleThresholdPolicy.cpp >> >> + assert(Universe::is_module_initialized(), "must be"); >> Shouldn?t that be !Universe::is_module_initialized()? No, that?s wrong too. I don?t think you can have this assert. >> >>> On Jun 27, 2016, at 4:56 PM, Tom Rodriguez > wrote: >>> >>> Some side discussion generated a minor change to this fix. simpleThresholdPolicy.cpp already had a check that JVMCI was in phase 2 before allowing compile, so instead of checking this over in jvmciCompiler.cpp I?ve modified the exist check to require phase 3. The new webrev is http://cr.openjdk.java.net/~never/8160121-v3/webrev . The only difference is there are no changes in jvmciCompiler.cpp and there are new changes in simpleThresholdPolicy.cpp. >>> >>> tom >>> >>>> On Jun 23, 2016, at 10:06 AM, Vladimir Kozlov > wrote: >>>> >>>> Looks good. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/23/16 8:55 AM, Doug Simon wrote: >>>>> JVMCI cannot be initialized until after VM init phase 3 as it requires the jdk.vm.ci module to be available (phase 2) and ServiceLoader to be working (phase 3). This change moves the eager initialization of JVMCI (under the condition of !UseInterpreter || !BackgroundCompilation) to be after phase 3 as well as causing JVMCI compilations before phase 3 to be ignored. >>>>> >>>>> Thanks to Tom for most of this code! >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8160121 >>>>> http://cr.openjdk.java.net/~dnsimon/8160121/ >>>>> >>>>> -Doug >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cthalinger at twitter.com Wed Jun 29 16:58:13 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 29 Jun 2016 06:58:13 -1000 Subject: REF: 8159888: [JVMCI] the client VM build is broken when INCLUDE_JVMCI is defined In-Reply-To: <26E91037-4C75-4667-BB81-E743D6EF2294@oracle.com> References: <26E91037-4C75-4667-BB81-E743D6EF2294@oracle.com> Message-ID: Hmm. I can?t remember why we decided to only support JVMCI in a tiered configuration but there was a reason? Maybe it is Windows related? Did you run a JPRT job with your changes? > On Jun 29, 2016, at 2:23 AM, Doug Simon wrote: > > Even though client+JVMCI (i.e., !TIERED && COMPILER1 && INCLUDE_JVMCI) doesn?t appear to be a supported configuration, it should still be buildable and produce a working VM where a JVMCI compiler can be used in hosted mode. This bug addresses that. > > I was able to build an exploded jdk but building an image failed in a way I cannot understand: > > Building these configurations (matching CONF=release): > * linux-x86_64-normal-client-release > * linux-x86_64-normal-server-release > Building target 'images' in configuration 'linux-x86_64-normal-client-release' > Building JVM variant 'client' with features 'all-gcs cds compiler1 fprof jni-check jvmci jvmti management nmt services vm-structs' > make[3]: *** [/home/dsimon/hs-comp/build/linux-x86_64-normal-client-release/support/classlist/classlist] Error 4 > make[2]: *** [generate-classlist] Error 1 > > ERROR: Build failed for target 'images' in configuration 'linux-x86_64-normal-client-release' (exit code 2) > No indication of failed target found. > Hint: Try searching the build log for '] Error'. > Hint: If caused by a warning, try configure --disable-warnings-as-errors. > > make[1]: *** [main] Error 1 > make: *** [images] Error 2 > > > Using the exploded jdk, I tested the changes on Graal. I had to manually edit build/linux-x86_64-normal-client-release/jdk/lib/amd64/jvm.cfg from: > > -server KNOWN > -client IGNORE > > to: > > -client KNOWN > -server IGNORE > > This file appears to be directly copied from jdk/src/java.base/unix/conf/amd64/jvm.cfg. If/when client builds on amd64 are supported, obviously the generation of jvm.cfg will have to be a little more dynamic. > > https://bugs.openjdk.java.net/browse/JDK-8159888 > http://cr.openjdk.java.net/~dnsimon/8159888/ > > -Doug From doug.simon at oracle.com Wed Jun 29 20:12:35 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 29 Jun 2016 22:12:35 +0200 Subject: REF: 8159888: [JVMCI] the client VM build is broken when INCLUDE_JVMCI is defined In-Reply-To: References: <26E91037-4C75-4667-BB81-E743D6EF2294@oracle.com> Message-ID: <6412E99E-812C-46E8-89BC-1B4F5718F2CB@oracle.com> > On 29 Jun 2016, at 18:58, Christian Thalinger wrote: > > Hmm. I can?t remember why we decided to only support JVMCI in a tiered configuration but there was a reason? Maybe it is Windows related? Did you run a JPRT job with your changes? I ran a `-buildsonly -testset hotspot` JPRT job and it passed. -Doug > >> On Jun 29, 2016, at 2:23 AM, Doug Simon wrote: >> >> Even though client+JVMCI (i.e., !TIERED && COMPILER1 && INCLUDE_JVMCI) doesn?t appear to be a supported configuration, it should still be buildable and produce a working VM where a JVMCI compiler can be used in hosted mode. This bug addresses that. >> >> I was able to build an exploded jdk but building an image failed in a way I cannot understand: >> >> Building these configurations (matching CONF=release): >> * linux-x86_64-normal-client-release >> * linux-x86_64-normal-server-release >> Building target 'images' in configuration 'linux-x86_64-normal-client-release' >> Building JVM variant 'client' with features 'all-gcs cds compiler1 fprof jni-check jvmci jvmti management nmt services vm-structs' >> make[3]: *** [/home/dsimon/hs-comp/build/linux-x86_64-normal-client-release/support/classlist/classlist] Error 4 >> make[2]: *** [generate-classlist] Error 1 >> >> ERROR: Build failed for target 'images' in configuration 'linux-x86_64-normal-client-release' (exit code 2) >> No indication of failed target found. >> Hint: Try searching the build log for '] Error'. >> Hint: If caused by a warning, try configure --disable-warnings-as-errors. >> >> make[1]: *** [main] Error 1 >> make: *** [images] Error 2 >> >> >> Using the exploded jdk, I tested the changes on Graal. I had to manually edit build/linux-x86_64-normal-client-release/jdk/lib/amd64/jvm.cfg from: >> >> -server KNOWN >> -client IGNORE >> >> to: >> >> -client KNOWN >> -server IGNORE >> >> This file appears to be directly copied from jdk/src/java.base/unix/conf/amd64/jvm.cfg. If/when client builds on amd64 are supported, obviously the generation of jvm.cfg will have to be a little more dynamic. >> >> https://bugs.openjdk.java.net/browse/JDK-8159888 >> http://cr.openjdk.java.net/~dnsimon/8159888/ >> >> -Doug > From cthalinger at twitter.com Wed Jun 29 20:54:54 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 29 Jun 2016 10:54:54 -1000 Subject: REF: 8159888: [JVMCI] the client VM build is broken when INCLUDE_JVMCI is defined In-Reply-To: <6412E99E-812C-46E8-89BC-1B4F5718F2CB@oracle.com> References: <26E91037-4C75-4667-BB81-E743D6EF2294@oracle.com> <6412E99E-812C-46E8-89BC-1B4F5718F2CB@oracle.com> Message-ID: > On Jun 29, 2016, at 10:12 AM, Doug Simon wrote: > > >> On 29 Jun 2016, at 18:58, Christian Thalinger wrote: >> >> Hmm. I can?t remember why we decided to only support JVMCI in a tiered configuration but there was a reason? Maybe it is Windows related? Did you run a JPRT job with your changes? > > I ran a `-buildsonly -testset hotspot` JPRT job and it passed. Should be good then :-) > > -Doug > >> >>> On Jun 29, 2016, at 2:23 AM, Doug Simon wrote: >>> >>> Even though client+JVMCI (i.e., !TIERED && COMPILER1 && INCLUDE_JVMCI) doesn?t appear to be a supported configuration, it should still be buildable and produce a working VM where a JVMCI compiler can be used in hosted mode. This bug addresses that. >>> >>> I was able to build an exploded jdk but building an image failed in a way I cannot understand: >>> >>> Building these configurations (matching CONF=release): >>> * linux-x86_64-normal-client-release >>> * linux-x86_64-normal-server-release >>> Building target 'images' in configuration 'linux-x86_64-normal-client-release' >>> Building JVM variant 'client' with features 'all-gcs cds compiler1 fprof jni-check jvmci jvmti management nmt services vm-structs' >>> make[3]: *** [/home/dsimon/hs-comp/build/linux-x86_64-normal-client-release/support/classlist/classlist] Error 4 >>> make[2]: *** [generate-classlist] Error 1 >>> >>> ERROR: Build failed for target 'images' in configuration 'linux-x86_64-normal-client-release' (exit code 2) >>> No indication of failed target found. >>> Hint: Try searching the build log for '] Error'. >>> Hint: If caused by a warning, try configure --disable-warnings-as-errors. >>> >>> make[1]: *** [main] Error 1 >>> make: *** [images] Error 2 >>> >>> >>> Using the exploded jdk, I tested the changes on Graal. I had to manually edit build/linux-x86_64-normal-client-release/jdk/lib/amd64/jvm.cfg from: >>> >>> -server KNOWN >>> -client IGNORE >>> >>> to: >>> >>> -client KNOWN >>> -server IGNORE >>> >>> This file appears to be directly copied from jdk/src/java.base/unix/conf/amd64/jvm.cfg. If/when client builds on amd64 are supported, obviously the generation of jvm.cfg will have to be a little more dynamic. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8159888 >>> http://cr.openjdk.java.net/~dnsimon/8159888/ >>> >>> -Doug >> > From rahul.v.raghavan at oracle.com Thu Jun 30 11:55:10 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 30 Jun 2016 04:55:10 -0700 (PDT) Subject: RFR: 8153194: PreserveFPRegistersTest.java runs out of memory in the nightlies In-Reply-To: <052c30ac-dcb1-17de-6996-ed93a778781e@oracle.com> References: <47ea70f9-e79e-45c7-9e77-7de9c7cdd5fa@default> <99835b15-d289-d6d5-4815-34bc86f2e7ab@oracle.com> <49e3dee1-bd9e-4947-b740-dc2c8b971cef@default> <052c30ac-dcb1-17de-6996-ed93a778781e@oracle.com> Message-ID: > -----Original Message----- > From: Vladimir Ivanov > Sent: Tuesday, June 28, 2016 10:24 PM > > Rahul, > > > Thank you Vladimir for your comments. > > Yes, agree to your points and made the changes. > > Also additionally added @build (found required when tried the single test run in RBT) > > Please check the revised : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.01/ > > No issues found with local jtreg testing, RBT . > > The following lines are redundant: > test/compiler/gcbarriers/PreserveFPRegistersTest.java: > > + * @build ClassFileInstaller sun.hotspot.WhiteBox > + * @run main ClassFileInstaller sun.hotspot.WhiteBox > > No need to install WhiteBox anywhere, bootclasspath mode already handles it. > > Otherwise, looks good. Thank you Vladimir for the comments. Understood the point, changes done and confirmed no issues with jtreg, rbt testing. : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.02/ > > Best regards, > Vladimir Ivanov > > >> -----Original Message----- > >> From: Vladimir Ivanov > Sent: Wednesday, June 22, 2016 11:46 PM > >> > >> Thanks for taking care of the bug, Rahul. > >> > >>> Please review the following test fix patch for JDK-8153194. > >>> : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.00/ > >> > >> + * @run main ClassFileInstaller sun.hotspot.WhiteBox > >> + * @run main/othervm/timeout=300 -XX:+UnlockDiagnosticVMOptions > >> + * -XX:+WhiteBoxAPI -Xbatch -Xbootclasspath/a:. > >> > >> You can use "@run main/bootclasspath/othervm" instead. > >> > >> > >> + long regionSize = wb.g1RegionSize(); > >> > >> What happens if G1 isn't used? Either explicitly specify -XX:+UseG1GC or > >> use @requires. > >> > >> Otherwise, looks good. > >> > >> Best regards, > >> Vladimir Ivanov > >> > >>> > >>> > >>> Notes: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8153194 - PreserveFPRegistersTest.java runs out of memory in the nightlies > >>> https://bugs.openjdk.java.net/browse/JDK-8148175 - C1: G1 barriers don't preserve FP registers > >>> > >>> - 'hotspot/test/compiler/gcbarriers/PreserveFPRegistersTest.java' was added as part of the old JDK-8148175 fix. > >>> - The 'PreserveFPRegistersTest.java' started failing in nightly tests for 64-bit targets only with -XX:-UseCompressedOops enabled. > >>> - Found wrong hard coded usage of reference size as 32 bits in test caused OutOfMemoryError, for -XX:-UseCompressedOops > >> cases. > >>> > >>> Changes done - > >>> - Actual fix of setting reference size using WhiteBox.getHeapOopSize() and removed @ignore. > >>> - Used WhiteBox.g1RegionSize() instead of hard coded value. > >>> - Used -Xmx300m instead of -Xmx128m for run VM options. > >>> (found this change is required for the test to fail correctly using old JDK9 builds prior to JDK-8148175 fix. > >>> e.g.: for test to fail with "java.lang.AssertionError: Final value has changed: 0.0 != 6.0" using JDK9-b113. > >>> Please note same -Xmx300m used for failing case reported in JDK-8148175. > >>> - Added diagnostic output. > >>> > >>> Testing done - > >>> - Confirmed revised test fails as expected using old jdk9 builds prior to JDK-8148175 fix (e.g.: JDK9-b113) > >>> >> [Test finished: compiler/gcbarriers/PreserveFPRegistersTest.java: Failed. Execution failed: `main' threw exception: > >> java.lang.AssertionError: Final value has changed: 0.0 != 6.0] > >>> (for default run and with -XX:-UseCompressedOops) > >>> > >>> - Confirmed revised test is passing for latest source build (.i.e. with JDK-8148175 fix, starting from JDK9-b114) > >>> (with and without -XX:-UseCompressedOops) > >>> > >>> > >>> Thanks, > >>> Rahul > >>> From vladimir.x.ivanov at oracle.com Thu Jun 30 11:57:30 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 30 Jun 2016 14:57:30 +0300 Subject: RFR: 8153194: PreserveFPRegistersTest.java runs out of memory in the nightlies In-Reply-To: References: <47ea70f9-e79e-45c7-9e77-7de9c7cdd5fa@default> <99835b15-d289-d6d5-4815-34bc86f2e7ab@oracle.com> <49e3dee1-bd9e-4947-b740-dc2c8b971cef@default> <052c30ac-dcb1-17de-6996-ed93a778781e@oracle.com> Message-ID: <5df8c255-7a1d-50a1-50da-9868ef34901a@oracle.com> Looks good. Best regards, Vladimir Ivanov On 6/30/16 2:55 PM, Rahul Raghavan wrote: > >> -----Original Message----- >> From: Vladimir Ivanov > Sent: Tuesday, June 28, 2016 10:24 PM >> >> Rahul, >> >>> Thank you Vladimir for your comments. >>> Yes, agree to your points and made the changes. >>> Also additionally added @build (found required when tried the single test run in RBT) >>> Please check the revised : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.01/ >>> No issues found with local jtreg testing, RBT . >> >> The following lines are redundant: >> test/compiler/gcbarriers/PreserveFPRegistersTest.java: >> >> + * @build ClassFileInstaller sun.hotspot.WhiteBox >> + * @run main ClassFileInstaller sun.hotspot.WhiteBox >> >> No need to install WhiteBox anywhere, bootclasspath mode already handles it. >> >> Otherwise, looks good. > > Thank you Vladimir for the comments. > Understood the point, changes done and confirmed no issues with jtreg, rbt testing. > : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.02/ > >> >> Best regards, >> Vladimir Ivanov >> >>>> -----Original Message----- >>>> From: Vladimir Ivanov > Sent: Wednesday, June 22, 2016 11:46 PM >>>> >>>> Thanks for taking care of the bug, Rahul. >>>> >>>>> Please review the following test fix patch for JDK-8153194. >>>>> : http://cr.openjdk.java.net/~rraghavan/8153194/webrev.00/ >>>> >>>> + * @run main ClassFileInstaller sun.hotspot.WhiteBox >>>> + * @run main/othervm/timeout=300 -XX:+UnlockDiagnosticVMOptions >>>> + * -XX:+WhiteBoxAPI -Xbatch -Xbootclasspath/a:. >>>> >>>> You can use "@run main/bootclasspath/othervm" instead. >>>> >>>> >>>> + long regionSize = wb.g1RegionSize(); >>>> >>>> What happens if G1 isn't used? Either explicitly specify -XX:+UseG1GC or >>>> use @requires. >>>> >>>> Otherwise, looks good. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>> >>>>> >>>>> Notes: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8153194 - PreserveFPRegistersTest.java runs out of memory in the nightlies >>>>> https://bugs.openjdk.java.net/browse/JDK-8148175 - C1: G1 barriers don't preserve FP registers >>>>> >>>>> - 'hotspot/test/compiler/gcbarriers/PreserveFPRegistersTest.java' was added as part of the old JDK-8148175 fix. >>>>> - The 'PreserveFPRegistersTest.java' started failing in nightly tests for 64-bit targets only with -XX:-UseCompressedOops enabled. >>>>> - Found wrong hard coded usage of reference size as 32 bits in test caused OutOfMemoryError, for -XX:-UseCompressedOops >>>> cases. >>>>> >>>>> Changes done - >>>>> - Actual fix of setting reference size using WhiteBox.getHeapOopSize() and removed @ignore. >>>>> - Used WhiteBox.g1RegionSize() instead of hard coded value. >>>>> - Used -Xmx300m instead of -Xmx128m for run VM options. >>>>> (found this change is required for the test to fail correctly using old JDK9 builds prior to JDK-8148175 fix. >>>>> e.g.: for test to fail with "java.lang.AssertionError: Final value has changed: 0.0 != 6.0" using JDK9-b113. >>>>> Please note same -Xmx300m used for failing case reported in JDK-8148175. >>>>> - Added diagnostic output. >>>>> >>>>> Testing done - >>>>> - Confirmed revised test fails as expected using old jdk9 builds prior to JDK-8148175 fix (e.g.: JDK9-b113) >>>>> >> [Test finished: compiler/gcbarriers/PreserveFPRegistersTest.java: Failed. Execution failed: `main' threw exception: >>>> java.lang.AssertionError: Final value has changed: 0.0 != 6.0] >>>>> (for default run and with -XX:-UseCompressedOops) >>>>> >>>>> - Confirmed revised test is passing for latest source build (.i.e. with JDK-8148175 fix, starting from JDK9-b114) >>>>> (with and without -XX:-UseCompressedOops) >>>>> >>>>> >>>>> Thanks, >>>>> Rahul >>>>> From doug.simon at oracle.com Thu Jun 30 12:39:53 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 30 Jun 2016 14:39:53 +0200 Subject: RFR (XS): 8160647: [JVMCI] need to be able to copy internal arrays from LocalVariableTable and LineNumberTable Message-ID: <1CDD885F-5EB8-40CA-821F-0B64198270C6@oracle.com> Existing JVMCI clients create modified LocalVariableTable and LineNumberTable objects from existing ones. To support this, (copies of) these object's internals must be accessible. The fix for JDK-8159613 removed such access and this bug restores it. https://bugs.openjdk.java.net/browse/JDK-8160647 http://cr.openjdk.java.net/~dnsimon/8160647/ -Doug From edward.nevill at gmail.com Thu Jun 30 12:43:45 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 30 Jun 2016 13:43:45 +0100 Subject: RFR: 8156943: aarch64: string compare does not support CompactStrings In-Reply-To: <57739571.2020203@redhat.com> References: <573F25DA.8000202@redhat.com> <573F34A2.70108@redhat.com> <1464078397.31264.25.camel@mylittlepony.linaroharston> <574411E3.70806@redhat.com> <1467191869.27591.3.camel@gmail.com> <57739571.2020203@redhat.com> Message-ID: <1467290625.6034.4.camel@gmail.com> On Wed, 2016-06-29 at 10:31 +0100, Andrew Haley wrote: > On 29/06/16 10:17, Edward Nevill wrote: > > > > OK to push? > I noticed another build failure yesterday because of a missing include > file: > > diff -r 83e5b5190020 src/cpu/aarch64/vm/macroAssembler_aarch64.cpp > --- a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Thu Jun 23 17:58:59 2016 +0000 > +++ b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Wed Jun 29 10:31:14 2016 +0100 Is this OK to push now? I have verified that it builds without precompiled headers and done a quick smoke check with JTreg langtools (I have previously done a complete JTReg run hotspot/langtools/jdk with a fastdebug version). http://cr.openjdk.java.net/~enevill/8156943/webrev.03/ https://bugs.openjdk.java.net/browse/JDK-8156943 All the best, Ed From aph at redhat.com Thu Jun 30 12:52:44 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Jun 2016 13:52:44 +0100 Subject: RFR: 8156943: aarch64: string compare does not support CompactStrings In-Reply-To: <1467290625.6034.4.camel@gmail.com> References: <573F25DA.8000202@redhat.com> <573F34A2.70108@redhat.com> <1464078397.31264.25.camel@mylittlepony.linaroharston> <574411E3.70806@redhat.com> <1467191869.27591.3.camel@gmail.com> <57739571.2020203@redhat.com> <1467290625.6034.4.camel@gmail.com> Message-ID: <5775161C.1070301@redhat.com> On 30/06/16 13:43, Edward Nevill wrote: > Is this OK to push now? Yes: we've got approval for CompactStrings. Andrew. From tobias.hartmann at oracle.com Thu Jun 30 13:15:42 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 30 Jun 2016 15:15:42 +0200 Subject: [9] RFR(S): 8160651: StubRoutines::_dtan does not restore callee save register rbx Message-ID: <57751B7E.5090307@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8160651 http://cr.openjdk.java.net/~thartmann/8160651/webrev.00/ StubRoutines::_dtan overwrites the callee save register $rbx but does not restore the original value before returning. The problem is in MacroAssembler::fast_tan() introduced by JDK-8152907 [1]: we set $rbx to 32768 (0x8000) but do not pop the saved value from the stack before returning. This causes several test failures (see linked bugs) because $rbx contains incorrect values. The implementations of MacroAssembler::fast_cos() are MacroAssembler::fast_sin() are similar, but correctly restore $rbx [2]. I also removed the unused LibraryCallKit::inline_trig(). Tested with failing tests, JPRT and RBT (running). Thanks, Tobias [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/33f10a35ce20#l16.1052 [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/33f10a35ce20#l8.3947 From vladimir.x.ivanov at oracle.com Thu Jun 30 13:46:52 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 30 Jun 2016 16:46:52 +0300 Subject: [9] RFR(S): 8160651: StubRoutines::_dtan does not restore callee save register rbx In-Reply-To: <57751B7E.5090307@oracle.com> References: <57751B7E.5090307@oracle.com> Message-ID: <0962eb1a-3591-719e-9d13-39c4096a4f22@oracle.com> Looks good. Best regards, Vladimir Ivanov On 6/30/16 4:15 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8160651 > http://cr.openjdk.java.net/~thartmann/8160651/webrev.00/ > > StubRoutines::_dtan overwrites the callee save register $rbx but does not restore the original value before returning. The problem is in MacroAssembler::fast_tan() introduced by JDK-8152907 [1]: we set $rbx to 32768 (0x8000) but do not pop the saved value from the stack before returning. This causes several test failures (see linked bugs) because $rbx contains incorrect values. The implementations of MacroAssembler::fast_cos() are MacroAssembler::fast_sin() are similar, but correctly restore $rbx [2]. > > I also removed the unused LibraryCallKit::inline_trig(). > > Tested with failing tests, JPRT and RBT (running). > > Thanks, > Tobias > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/33f10a35ce20#l16.1052 > [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/33f10a35ce20#l8.3947 > From tobias.hartmann at oracle.com Thu Jun 30 13:49:57 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 30 Jun 2016 15:49:57 +0200 Subject: [9] RFR(S): 8160651: StubRoutines::_dtan does not restore callee save register rbx In-Reply-To: <0962eb1a-3591-719e-9d13-39c4096a4f22@oracle.com> References: <57751B7E.5090307@oracle.com> <0962eb1a-3591-719e-9d13-39c4096a4f22@oracle.com> Message-ID: <57752385.50502@oracle.com> Thanks, Vladimir! Best regards, Tobias On 30.06.2016 15:46, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 6/30/16 4:15 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> https://bugs.openjdk.java.net/browse/JDK-8160651 >> http://cr.openjdk.java.net/~thartmann/8160651/webrev.00/ >> >> StubRoutines::_dtan overwrites the callee save register $rbx but does not restore the original value before returning. The problem is in MacroAssembler::fast_tan() introduced by JDK-8152907 [1]: we set $rbx to 32768 (0x8000) but do not pop the saved value from the stack before returning. This causes several test failures (see linked bugs) because $rbx contains incorrect values. The implementations of MacroAssembler::fast_cos() are MacroAssembler::fast_sin() are similar, but correctly restore $rbx [2]. >> >> I also removed the unused LibraryCallKit::inline_trig(). >> >> Tested with failing tests, JPRT and RBT (running). >> >> Thanks, >> Tobias >> >> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/33f10a35ce20#l16.1052 >> [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/33f10a35ce20#l8.3947 >> From tatiana.pivovarova at oracle.com Thu Jun 30 15:38:41 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Thu, 30 Jun 2016 18:38:41 +0300 Subject: [9] RFR(M): 8132919: use package in compiler tests Message-ID: <57753D01.3080906@oracle.com> Hello, please review this patch Summary: Many hotspot tests and test libraries don't have package. It complicates test development process in IDE and makes it inconvenient to use a library. webrev: http://cr.openjdk.java.net/~iignatyev/8132919/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8132919 Tested on all platforms. This patch has been contributed by Igor Ignatyev. Thanks, Tatiana -------------- next part -------------- An HTML attachment was scrubbed... URL: From tatiana.pivovarova at oracle.com Thu Jun 30 16:17:01 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Thu, 30 Jun 2016 19:17:01 +0300 Subject: [9] RFR(M): 8151280: update hotspot tests to use vm.compMode instead of their own logic Message-ID: <577545FD.1010203@oracle.com> Hello, could you please review this patch? This review request covers two bugs: - 8151280: update hotspot tests to use vm.compMode instead of their own logic [1] - 8145848: Update hs compiler tests to get VM mode using j.t.l.Platform [2] Also it relays on bug fix for 8132919 [3] which I posted recently [4] Summary: it's possible now to rely on @requires expressions to choose vm.compMode At the moment several compiler tests parse java.vm.info property to get VM mode. It could be done using j.t.l.Platform. This patch has been contributed by Igor Ignatyev. Tested on on Linux-x86 and Solaris sparc top level webrev: http://cr.openjdk.java.net/~iignatyev/8145848/top/webrev.00/ hotspot webrev: http://cr.openjdk.java.net/~iignatyev/8145848/hotspot/webrev.00/ bugs: [1] [2] [1] https://bugs.openjdk.java.net/browse/JDK-8151280 [2] https://bugs.openjdk.java.net/browse/JDK-8145848 [3] https://bugs.openjdk.java.net/browse/JDK-8132919 [4] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-June/023599.html Thanks, Tatiana -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.rodriguez at oracle.com Thu Jun 30 16:51:22 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 30 Jun 2016 09:51:22 -0700 Subject: RFR (XS): 8160647: [JVMCI] need to be able to copy internal arrays from LocalVariableTable and LineNumberTable In-Reply-To: <1CDD885F-5EB8-40CA-821F-0B64198270C6@oracle.com> References: <1CDD885F-5EB8-40CA-821F-0B64198270C6@oracle.com> Message-ID: <3DFD7B3C-F340-4AAD-ADCC-582DE0E4F07A@oracle.com> Can you drop Copy from the names? They are documented as returning a copy. tom > On Jun 30, 2016, at 5:39 AM, Doug Simon wrote: > > Existing JVMCI clients create modified LocalVariableTable and LineNumberTable objects from existing ones. To support this, (copies of) these object's internals must be accessible. The fix for JDK-8159613 removed such access and this bug restores it. > > https://bugs.openjdk.java.net/browse/JDK-8160647 > http://cr.openjdk.java.net/~dnsimon/8160647/ > > -Doug From dmitrij.pochepko at oracle.com Thu Jun 30 17:02:01 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 30 Jun 2016 20:02:01 +0300 Subject: RFR(S): 8160276 - Jittester: bytecode tests generation hangs in ClassWriter infinite loop Message-ID: <57755089.6040005@oracle.com> Hi, please review fix for 8160276 - Jittester: bytecode tests generation hangs in ClassWriter infinite loop Jittester hangs in rare cases of specific seeds, so, fix launch test generation in separate thread and check for generation timeout. Test is generated again with next seed in case timeout was hit. webrev: http://cr.openjdk.java.net/~dpochepk/8160276/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8160276 I've tested it locally on linux-amd64. Thanks, Dmitrij From doug.simon at oracle.com Thu Jun 30 19:16:33 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 30 Jun 2016 21:16:33 +0200 Subject: RFR (XS): 8160647: [JVMCI] need to be able to copy internal arrays from LocalVariableTable and LineNumberTable In-Reply-To: <3DFD7B3C-F340-4AAD-ADCC-582DE0E4F07A@oracle.com> References: <1CDD885F-5EB8-40CA-821F-0B64198270C6@oracle.com> <3DFD7B3C-F340-4AAD-ADCC-582DE0E4F07A@oracle.com> Message-ID: <5A5FB684-B055-431B-9A12-0C3D02E90710@oracle.com> > On 30 Jun 2016, at 18:51, Tom Rodriguez wrote: > > Can you drop Copy from the names? They are documented as returning a copy. Done. > > tom > >> On Jun 30, 2016, at 5:39 AM, Doug Simon wrote: >> >> Existing JVMCI clients create modified LocalVariableTable and LineNumberTable objects from existing ones. To support this, (copies of) these object's internals must be accessible. The fix for JDK-8159613 removed such access and this bug restores it. >> >> https://bugs.openjdk.java.net/browse/JDK-8160647 >> http://cr.openjdk.java.net/~dnsimon/8160647/ >> >> -Doug >