From goetz.lindenmaier at sap.com Mon May 2 08:35:26 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 2 May 2016 08:35:26 +0000 Subject: RFR(XS): 8155738: C2: fix frame_complete_offset In-Reply-To: <5b697841-5471-cee3-7136-7a334ee2ca25@oracle.com> References: <2768884fbe2647e3a2e6b82da36b4fe6@DEWDFE13DE09.global.corp.sap> <5b697841-5471-cee3-7136-7a334ee2ca25@oracle.com> Message-ID: Thanks Vladimir! Best regards, Goetz. > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Freitag, 29. April 2016 18:56 > To: Lindenmaier, Goetz ; hotspot compiler > > Subject: Re: RFR(XS): 8155738: C2: fix frame_complete_offset > > "In the debug build the call at output.cpp:1831 build if (n->size(_regalloc) < > (current_offset-instr_offset)) overwrites > the proper value." > > So the fix is to not reset frame_complete_offset > (Compile::_code_offsets._values[Frame_Complete]) when node is emitted > into scratch buffer. > > Changes looks good. > > Thanks, > Vladimir > > On 4/29/16 7:09 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > > > > > In C2, frame_complete_offset is set wrong. It's also called during > scratch_emit_size, > > > > which happens at least in the debug build. > > > > I also added the missing call on ppc. > > > > > > > > Please review this small fix. I please need a sponsor: > > > > http://cr.openjdk.java.net/~goetz/wr16/8155738-frameCmplt/webrev.00/ > > > > > > > > Thanks and best regards, > > > > Goetz. > > From goetz.lindenmaier at sap.com Mon May 2 08:37:25 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 2 May 2016 08:37:25 +0000 Subject: RFR(XS): 8155738: C2: fix frame_complete_offset In-Reply-To: References: <2768884fbe2647e3a2e6b82da36b4fe6@DEWDFE13DE09.global.corp.sap> <5b697841-5471-cee3-7136-7a334ee2ca25@oracle.com> Message-ID: <024e9813be3d43d2b2cce187eedcbbf8@DEWDFE13DE09.global.corp.sap> Thanks, Dean, could you please sponsor this change? Best regards, Goetz. > -----Original Message----- > From: Dean Long [mailto:dean.long at oracle.com] > Sent: Freitag, 29. April 2016 22:51 > To: Vladimir Kozlov ; Lindenmaier, Goetz > ; hotspot compiler dev at openjdk.java.net> > Subject: Re: RFR(XS): 8155738: C2: fix frame_complete_offset > > Looks good. I will closed JDK-8008415 as a duplicate! > > dl > > > On 4/29/2016 9:55 AM, Vladimir Kozlov wrote: > > "In the debug build the call at output.cpp:1831 build if > > (n->size(_regalloc) < (current_offset-instr_offset)) overwrites the > > proper value." > > > > So the fix is to not reset frame_complete_offset > > (Compile::_code_offsets._values[Frame_Complete]) when node is > emitted > > into scratch buffer. > > > > Changes looks good. > > > > Thanks, > > Vladimir > > > > On 4/29/16 7:09 AM, Lindenmaier, Goetz wrote: > >> Hi, > >> > >> > >> > >> In C2, frame_complete_offset is set wrong. It's also called during > >> scratch_emit_size, > >> > >> which happens at least in the debug build. > >> > >> I also added the missing call on ppc. > >> > >> > >> > >> Please review this small fix. I please need a sponsor: > >> > >> http://cr.openjdk.java.net/~goetz/wr16/8155738- > frameCmplt/webrev.00/ > >> > >> > >> > >> Thanks and best regards, > >> > >> Goetz. > >> From aleksey.shipilev at oracle.com Mon May 2 11:56:35 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 2 May 2016 14:56:35 +0300 Subject: RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures In-Reply-To: <76809325-CB53-499E-885B-9ED4AB0DBBB5@oracle.com> References: <5723DC4D.8090507@oracle.com> <76809325-CB53-499E-885B-9ED4AB0DBBB5@oracle.com> Message-ID: <57274073.1070508@oracle.com> On 04/30/2016 02:42 AM, Paul Sandoz wrote: >> On 29 Apr 2016, at 15:12, Aleksey Shipilev wrote: > Looks good. > > Small tweak if you so wish to do so: > > #if[JdkInternalMisc] > static final int WEAK_ATTEMPTS = Integer.getInteger("weakAttempts", 10); > #end[JdkInternalMisc] > > which avoids changes to the SunMiscUnsafe* tests. Alas, there are still whitespace changes in SunMiscUnsafe* tests, so changes are unavoidable, and I would like to keep the patch in its current form. 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 roland.schatz at oracle.com Mon May 2 13:46:17 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Mon, 2 May 2016 15:46:17 +0200 Subject: RFR(XS): 8155735: use strings instead of Symbol* in JVMCI exception stubs In-Reply-To: References: <5723657C.6020804@oracle.com> <572383EE.5060608@oracle.com> Message-ID: <57275A29.10601@oracle.com> On 04/29/2016 09:49 PM, Tom Rodriguez wrote: > Sorry I was looking at the comment below lookup instead of above it. It?s very odd that both of these exist though and new_symbol just forwards to lookup. > > static Symbol* new_symbol(const char* utf8_buffer, int length, TRAPS) { > static Symbol* lookup(const char* name, int len, TRAPS); > > I do think you want the TempNewSymbol though. You're right. I misunderstood the semantics of lookup/new_symbol, they actually both do the same thing. Normally, the symbol we're looking up is a class name, so the lookup should never fail anyway. But we should still not leak anything if there is a wrong string passed in. New webrev, using TempNewSymbol: http://cr.openjdk.java.net/~rschatz/JDK-8155735/webrev.01/ I've also included an exception check after the symbol lookup, just to be sure. - Roland > >>> and let new_exception throw an exception if the class named by symbol doesn?t exist. >> throw_and_post_jvmti_exception will throw a `NoClassDefFoundError` when the exception class doesn't exist. >> >> >> Just to be sure, I tested this using graal. Temporarily passing in a wrong class name into the stub results in: >>> java.lang.NoClassDefFoundError: bla/java/lang/NullPointerException >>> at com.oracle.graal.replacements.test.CompiledNullPointerExceptionTest.testSnippet(CompiledNullPointerExceptionTest.java:93) >>> at jdk.vm.ci.hotspot.CompilerToVM.executeInstalledCode(Native Method) >>> at jdk.vm.ci.hotspot.HotSpotNmethod.executeVarargs(HotSpotNmethod.java:100) >>> at com.oracle.graal.compiler.test.GraalCompilerTest.executeActual(GraalCompilerTest.java:578) >>> [?] > Thanks for checking. > > tom > >> >> - Roland >> From volker.simonis at gmail.com Mon May 2 14:34:56 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 2 May 2016 16:34:56 +0200 Subject: RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures In-Reply-To: <76809325-CB53-499E-885B-9ED4AB0DBBB5@oracle.com> References: <5723DC4D.8090507@oracle.com> <76809325-CB53-499E-885B-9ED4AB0DBBB5@oracle.com> Message-ID: Hi Aleksey, thanks for this quick fix. The change looks good! Adding to Paul, you could restrict the definition of WEAK_ATTEMPTS even further if you want: #if[CAS] #if[JdkInternalMisc] static final int WEAK_ATTEMPTS = Integer.getInteger("weakAttempts", 10); #end[JdkInternalMisc] #end[CAS] We still have two other test failures with our new intrinsic implementation on ppc64, but that's pretty sure our fault :) Regards, Volker On Sat, Apr 30, 2016 at 1:42 AM, Paul Sandoz wrote: > >> On 29 Apr 2016, at 15:12, Aleksey Shipilev wrote: >> >> Hi, >> >> I would like to fix a simple testbug in our weakCompareAndSet VarHandles >> and Unsafe intrinsics tests. weakCompareAndSet is spec-ed to allow >> spurious failures, but current tests do not allow that. This blocks >> development and testing on non-x86 platforms. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8155739 >> >> Webrevs: >> http://cr.openjdk.java.net/~shade/8155739/webrev.hs.00/ >> http://cr.openjdk.java.net/~shade/8155739/webrev.jdk.00/ >> > > Looks good. > > Small tweak if you so wish to do so: > > #if[JdkInternalMisc] > static final int WEAK_ATTEMPTS = Integer.getInteger("weakAttempts", 10); > #end[JdkInternalMisc] > > which avoids changes to the SunMiscUnsafe* tests. > > Paul. > >> The tests are auto-generated, and the substantiative changes are in >> *.template files. I also removed obsolete generate-unsafe-tests.sh. I >> would like to push through hs-comp to expose this to Power and AArch64 >> folks early. >> >> Testing: x86_64, jdk:java/lang/invoke/VarHandle, hotspot:compiler/unsafe >> >> Thanks, >> -Aleksey >> > From roland.schatz at oracle.com Mon May 2 14:40:56 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Mon, 2 May 2016 16:40:56 +0200 Subject: RFR 8155719: remove TrustedInterface from JVMCI Message-ID: <572766F8.20403@oracle.com> Hi, Please review this jvmci change: webrev: http://cr.openjdk.java.net/~rschatz/JDK-8155719/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8155719 Thanks, Roland From christian.thalinger at oracle.com Mon May 2 16:50:48 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 2 May 2016 06:50:48 -1000 Subject: RFR 8155771: [JVMCI] expose JVM_ACC_IS_CLONEABLE_FAST In-Reply-To: <582A1B37-8F4C-4151-8E0C-D77E73236C93@oracle.com> References: <579B4981-C0D1-4177-9DED-8BCD6C233395@oracle.com> <0C76F8C6-012E-48F4-934D-4BFB9DC241A3@oracle.com> <582A1B37-8F4C-4151-8E0C-D77E73236C93@oracle.com> Message-ID: > On Apr 29, 2016, at 1:36 PM, Tom Rodriguez wrote: > > >> On Apr 29, 2016, at 4:10 PM, Christian Thalinger > wrote: >> >> >>> On Apr 29, 2016, at 12:04 PM, Tom Rodriguez > wrote: >>> >>> http://cr.openjdk.java.net/~never/8155771/webrev + boolean isAllocationCloneable(); >> That means ?allocation-cloneable?, not ?allocation is cloneable?, right? It could be interpreted both ways but the change is good. > > I knew what I meant so I didn?t see alternative readings. Is there something better? canBeClonedWithAllocation :) :-) Actually, that?s not a bad name. Or isClonableWithAllocation. > > tom > >> >>> >>> The new flag JVM_ACC_IS_CLONEABLE_FAST controls whether an object can be cloned by simply performing an allocation and copying the fields. Previously all Cloneable objects were assumed to be cloneable in this way. Add ResolvedJavaType.isAllocationCloneable to expose this notion. Tested with Graal. >>> >>> tom >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon May 2 16:53:03 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 2 May 2016 06:53:03 -1000 Subject: RFR(XS): 8155735: use strings instead of Symbol* in JVMCI exception stubs In-Reply-To: <57275A29.10601@oracle.com> References: <5723657C.6020804@oracle.com> <572383EE.5060608@oracle.com> <57275A29.10601@oracle.com> Message-ID: <345C0B1B-07D3-41A8-8C9F-2C73A41B3717@oracle.com> > On May 2, 2016, at 3:46 AM, Roland Schatz wrote: > > On 04/29/2016 09:49 PM, Tom Rodriguez wrote: >> Sorry I was looking at the comment below lookup instead of above it. It?s very odd that both of these exist though and new_symbol just forwards to lookup. >> >> static Symbol* new_symbol(const char* utf8_buffer, int length, TRAPS) { >> static Symbol* lookup(const char* name, int len, TRAPS); >> >> I do think you want the TempNewSymbol though. > You're right. I misunderstood the semantics of lookup/new_symbol, they actually both do the same thing. > > Normally, the symbol we're looking up is a class name, so the lookup should never fail anyway. But we should still not leak anything if there is a wrong string passed in. > > New webrev, using TempNewSymbol: > http://cr.openjdk.java.net/~rschatz/JDK-8155735/webrev.01/ > > I've also included an exception check after the symbol lookup, just to be sure. Use CHECK instead of HAS_PENDING_EXCEPTION. Otherwise this looks good. > > - Roland >> >>>> and let new_exception throw an exception if the class named by symbol doesn?t exist. >>> throw_and_post_jvmti_exception will throw a `NoClassDefFoundError` when the exception class doesn't exist. >>> >>> >>> Just to be sure, I tested this using graal. Temporarily passing in a wrong class name into the stub results in: >>>> java.lang.NoClassDefFoundError: bla/java/lang/NullPointerException >>>> at com.oracle.graal.replacements.test.CompiledNullPointerExceptionTest.testSnippet(CompiledNullPointerExceptionTest.java:93) >>>> at jdk.vm.ci.hotspot.CompilerToVM.executeInstalledCode(Native Method) >>>> at jdk.vm.ci.hotspot.HotSpotNmethod.executeVarargs(HotSpotNmethod.java:100) >>>> at com.oracle.graal.compiler.test.GraalCompilerTest.executeActual(GraalCompilerTest.java:578) >>>> [?] >> Thanks for checking. >> >> tom >> >>> >>> - Roland >>> > From christian.thalinger at oracle.com Mon May 2 16:55:18 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 2 May 2016 06:55:18 -1000 Subject: RFR 8155719: remove TrustedInterface from JVMCI In-Reply-To: <572766F8.20403@oracle.com> References: <572766F8.20403@oracle.com> Message-ID: <5D6FC0E0-BD08-4746-BC40-CD38822E929B@oracle.com> Looks good. > On May 2, 2016, at 4:40 AM, Roland Schatz wrote: > > Hi, > > Please review this jvmci change: > > webrev: http://cr.openjdk.java.net/~rschatz/JDK-8155719/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8155719 > > Thanks, > Roland From paul.sandoz at oracle.com Mon May 2 18:30:52 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 May 2016 11:30:52 -0700 Subject: RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures In-Reply-To: <57274073.1070508@oracle.com> References: <5723DC4D.8090507@oracle.com> <76809325-CB53-499E-885B-9ED4AB0DBBB5@oracle.com> <57274073.1070508@oracle.com> Message-ID: <585095F9-EE32-4110-8057-7C50F692CE66@oracle.com> > On 2 May 2016, at 04:56, Aleksey Shipilev wrote: > > On 04/30/2016 02:42 AM, Paul Sandoz wrote: >>> On 29 Apr 2016, at 15:12, Aleksey Shipilev wrote: >> Looks good. >> >> Small tweak if you so wish to do so: >> >> #if[JdkInternalMisc] >> static final int WEAK_ATTEMPTS = Integer.getInteger("weakAttempts", 10); >> #end[JdkInternalMisc] >> >> which avoids changes to the SunMiscUnsafe* tests. > > Alas, there are still whitespace changes in SunMiscUnsafe* tests, so > changes are unavoidable, and I would like to keep the patch in its > current form. > No objections from me. 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 tom.rodriguez at oracle.com Mon May 2 18:40:47 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 2 May 2016 11:40:47 -0700 Subject: RFR 8155771: [JVMCI] expose JVM_ACC_IS_CLONEABLE_FAST In-Reply-To: References: <579B4981-C0D1-4177-9DED-8BCD6C233395@oracle.com> <0C76F8C6-012E-48F4-934D-4BFB9DC241A3@oracle.com> <582A1B37-8F4C-4151-8E0C-D77E73236C93@oracle.com> Message-ID: <1413B33E-DFF5-4817-872E-1DAB9A1D8EA9@oracle.com> > On May 2, 2016, at 9:50 AM, Christian Thalinger wrote: > >> >> On Apr 29, 2016, at 1:36 PM, Tom Rodriguez > wrote: >> >> >>> On Apr 29, 2016, at 4:10 PM, Christian Thalinger > wrote: >>> >>> >>>> On Apr 29, 2016, at 12:04 PM, Tom Rodriguez > wrote: >>>> >>>> http://cr.openjdk.java.net/~never/8155771/webrev + boolean isAllocationCloneable(); >>> That means ?allocation-cloneable?, not ?allocation is cloneable?, right? It could be interpreted both ways but the change is good. >> >> I knew what I meant so I didn?t see alternative readings. Is there something better? canBeClonedWithAllocation :) > > :-) Actually, that?s not a bad name. Or isClonableWithAllocation. isClonableWithAllocation is ok, though it seems like it should be isCloneableWithAllocation? tom > >> >> tom >> >>> >>>> >>>> The new flag JVM_ACC_IS_CLONEABLE_FAST controls whether an object can be cloned by simply performing an allocation and copying the fields. Previously all Cloneable objects were assumed to be cloneable in this way. Add ResolvedJavaType.isAllocationCloneable to expose this notion. Tested with Graal. >>>> >>>> tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon May 2 20:13:23 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 2 May 2016 10:13:23 -1000 Subject: RFR 8155771: [JVMCI] expose JVM_ACC_IS_CLONEABLE_FAST In-Reply-To: <1413B33E-DFF5-4817-872E-1DAB9A1D8EA9@oracle.com> References: <579B4981-C0D1-4177-9DED-8BCD6C233395@oracle.com> <0C76F8C6-012E-48F4-934D-4BFB9DC241A3@oracle.com> <582A1B37-8F4C-4151-8E0C-D77E73236C93@oracle.com> <1413B33E-DFF5-4817-872E-1DAB9A1D8EA9@oracle.com> Message-ID: > On May 2, 2016, at 8:40 AM, Tom Rodriguez wrote: > >> >> On May 2, 2016, at 9:50 AM, Christian Thalinger > wrote: >> >>> >>> On Apr 29, 2016, at 1:36 PM, Tom Rodriguez > wrote: >>> >>> >>>> On Apr 29, 2016, at 4:10 PM, Christian Thalinger > wrote: >>>> >>>> >>>>> On Apr 29, 2016, at 12:04 PM, Tom Rodriguez > wrote: >>>>> >>>>> http://cr.openjdk.java.net/~never/8155771/webrev + boolean isAllocationCloneable(); >>>> That means ?allocation-cloneable?, not ?allocation is cloneable?, right? It could be interpreted both ways but the change is good. >>> >>> I knew what I meant so I didn?t see alternative readings. Is there something better? canBeClonedWithAllocation :) >> >> :-) Actually, that?s not a bad name. Or isClonableWithAllocation. > > isClonableWithAllocation is ok, though it seems like it should be isCloneableWithAllocation? Yes, that. Typo. > > tom > >> >>> >>> tom >>> >>>> >>>>> >>>>> The new flag JVM_ACC_IS_CLONEABLE_FAST controls whether an object can be cloned by simply performing an allocation and copying the fields. Previously all Cloneable objects were assumed to be cloneable in this way. Add ResolvedJavaType.isAllocationCloneable to expose this notion. Tested with Graal. >>>>> >>>>> tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon May 2 20:49:42 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 2 May 2016 10:49:42 -1000 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <57162A88.7030608@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> Message-ID: <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> > On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R wrote: > > Hi Christian > > I have updated the webrev and link for the same is here: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ > I am using mathfunc() to call the masm version of call_VM_leaf_base() and not the InterpreterMacroAssembler version. That?s better but, again, there is nothing math-y about this method: ! void MacroAssembler::mathfunc(address runtime_entry) { MacroAssembler::call_VM_leaf_base(runtime_entry, 0); } Also, there is this method: void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { call_VM_leaf_base(entry_point, number_of_arguments); } which has: void call_VM_leaf(address entry_point, int number_of_arguments = 0); Get rid of mathfunc completely and use call_VM_leaf directly. > > Regards, > Vivek > > ? <> > <>From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Thursday, April 21, 2016 2:35 PM > To: Deshpande, Vivek R > Cc: Nils Eliasson ; hotspot-compiler-dev at openjdk.java.net; Vladimir Kozlov > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > > On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R > wrote: > > Hi > > The correct URL for the updated webrev is this. > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ > > +void MacroAssembler::mathfunc(address runtime_entry) { > I don?t like the name of this method. Mainly because it?s only aligning the stack (shouldn?t that happen somewhere else?) and doing this 0x20 stack frame thing which I still don?t understand. > > Right, this is the one I was thinking about: > > void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { > > > Sorry for the spam. > > Regards, > Vivek > > From: Deshpande, Vivek R > Sent: Wednesday, April 20, 2016 5:10 PM > To: Deshpande, Vivek R; 'Nils Eliasson'; 'hotspot-compiler-dev at openjdk.java.net ' > Cc: 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian Thalinger'; Viswanathan, Sandhya > Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > Sent out the wrong link by mistake. > > updated webrev: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ > > Regards > Vivek > > > From: Deshpande, Vivek R > Sent: Wednesday, April 20, 2016 5:07 PM > To: 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net > Cc: Vladimir Kozlov; Volker Simonis; Christian Thalinger; Viswanathan, Sandhya > Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > Hi Nils > > I have updated the webrev with all the suggestions. > updated webrev: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ > Thanks for your comments and review. > > @Vladimir, > I have taken care of all the comments. Would you please review and sponsor the patch. > > Thanks and regards, > Vivek > > From: Nils Eliasson [mailto:nils.eliasson at oracle.com ] > Sent: Wednesday, April 20, 2016 12:27 PM > To: Deshpande, Vivek R; hotspot-compiler-dev at openjdk.java.net > Cc: Vladimir Kozlov; Volker Simonis; Christian Thalinger; Viswanathan, Sandhya > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > In vmSymbols.cpp together with the other flag checks. > > Regards, > Nils > > On 2016-04-20 02:44, Deshpande, Vivek R wrote: > HI Nils > > Yes you are right the function accesses the command line flag DisableIntrinsic and changes are static. > Could you point me the right location for the function ? > Also I have updated the webrev with rest of the comments here: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ > > Regards, > Vivek > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net ]On Behalf Of Nils Eliasson > Sent: Tuesday, April 19, 2016 5:55 AM > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > Hi Vivek, > > The changes in is_intrinsic_disabled in compilerDirectives.* are static and only access the command line flag DisableIntrinsics. As long as stubs are only generated during startup and don't have a method context - that is ok - but it doesn't belong in the compilerDirectives-files if it doens't use directives. > > Regards, > Nils > > On 2016-04-18 19:38, Deshpande, Vivek R wrote: > Hi all > > I would like to contribute a patch which helps to control the intrinsics in interpreter, c1 and c2 by disabling the stub generation. > This uses -XX:DisableIntrinsic option to achieve the same. > Could you please review and sponsor this patch. > > Bug-id: > https://bugs.openjdk.java.net/browse/JDK-8154473 > webrev: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ > > Thanks and regards, > Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Mon May 2 21:06:22 2016 From: dean.long at oracle.com (Dean Long) Date: Mon, 2 May 2016 14:06:22 -0700 Subject: RFR(XS): 8155738: C2: fix frame_complete_offset In-Reply-To: <024e9813be3d43d2b2cce187eedcbbf8@DEWDFE13DE09.global.corp.sap> References: <2768884fbe2647e3a2e6b82da36b4fe6@DEWDFE13DE09.global.corp.sap> <5b697841-5471-cee3-7136-7a334ee2ca25@oracle.com> <024e9813be3d43d2b2cce187eedcbbf8@DEWDFE13DE09.global.corp.sap> Message-ID: <5e42f9f6-fbba-d0f7-d455-64c21bea83a8@oracle.com> Sure. dl On 5/2/2016 1:37 AM, Lindenmaier, Goetz wrote: > Thanks, Dean, > > could you please sponsor this change? > > Best regards, > Goetz. > >> -----Original Message----- >> From: Dean Long [mailto:dean.long at oracle.com] >> Sent: Freitag, 29. April 2016 22:51 >> To: Vladimir Kozlov ; Lindenmaier, Goetz >> ; hotspot compiler > dev at openjdk.java.net> >> Subject: Re: RFR(XS): 8155738: C2: fix frame_complete_offset >> >> Looks good. I will closed JDK-8008415 as a duplicate! >> >> dl >> >> >> On 4/29/2016 9:55 AM, Vladimir Kozlov wrote: >>> "In the debug build the call at output.cpp:1831 build if >>> (n->size(_regalloc) < (current_offset-instr_offset)) overwrites the >>> proper value." >>> >>> So the fix is to not reset frame_complete_offset >>> (Compile::_code_offsets._values[Frame_Complete]) when node is >> emitted >>> into scratch buffer. >>> >>> Changes looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 4/29/16 7:09 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> >>>> >>>> In C2, frame_complete_offset is set wrong. It's also called during >>>> scratch_emit_size, >>>> >>>> which happens at least in the debug build. >>>> >>>> I also added the missing call on ppc. >>>> >>>> >>>> >>>> Please review this small fix. I please need a sponsor: >>>> >>>> http://cr.openjdk.java.net/~goetz/wr16/8155738- >> frameCmplt/webrev.00/ >>>> >>>> >>>> Thanks and best regards, >>>> >>>> Goetz. >>>> From christian.thalinger at oracle.com Mon May 2 22:43:57 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 2 May 2016 12:43:57 -1000 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <57162A88.7030608@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> Message-ID: > On May 2, 2016, at 11:53 AM, Deshpande, Vivek R wrote: > > Hi Christian > > I had tried using call_VM_leaf() which you mentioned. > > But this function > > void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { > call_VM_leaf_base(entry_point, number_of_arguments); > } > > ends up calling > > void InterpreterMacroAssembler::call_VM_leaf_base(address entry_point, > int number_of_arguments) { ... > from interp_masm_x86.cpp instead of > > void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { ? Frankly, I didn?t know that there is an overload for call_VM_leaf_base in InterpreterMacroAssembler. So this means there are two options: a) Add a method in MacroAssembler to call MacroAssembler::call_VM_leaf_base (what you did) or b) Add InterpreterMacroAssembler::call_VM_leaf and change MacroAssembler::call_VM_leaf to do: void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); } I will let the runtime team decide. > > So I had put mathfunc() to call the masm version of call_VM_leaf_base(). > > Let me know what you think. > > Thanks and regards, > Vivek > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Monday, May 02, 2016 1:50 PM > To: Deshpande, Vivek R > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > > On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R > wrote: > > Hi Christian > > I have updated the webrev and link for the same is here: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ > I am using mathfunc() to call the masm version of call_VM_leaf_base() and not the InterpreterMacroAssembler version. > > That?s better but, again, there is nothing math-y about this method: > ! void MacroAssembler::mathfunc(address runtime_entry) { > MacroAssembler::call_VM_leaf_base(runtime_entry, 0); > } > Also, there is this method: > > void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { > call_VM_leaf_base(entry_point, number_of_arguments); > } > > which has: > > void call_VM_leaf(address entry_point, > int number_of_arguments = 0); > > Get rid of mathfunc completely and use call_VM_leaf directly. > > > Regards, > Vivek > > ? <> > <>From: Christian Thalinger [mailto:christian.thalinger at oracle.com ] > Sent: Thursday, April 21, 2016 2:35 PM > To: Deshpande, Vivek R > > Cc: Nils Eliasson >; hotspot-compiler-dev at openjdk.java.net ; Vladimir Kozlov > > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > > On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R > wrote: > > Hi > > The correct URL for the updated webrev is this. > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ > > +void MacroAssembler::mathfunc(address runtime_entry) { > I don?t like the name of this method. Mainly because it?s only aligning the stack (shouldn?t that happen somewhere else?) and doing this 0x20 stack frame thing which I still don?t understand. > > Right, this is the one I was thinking about: > > void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { > > > > Sorry for the spam. > > Regards, > Vivek > > From: Deshpande, Vivek R > Sent: Wednesday, April 20, 2016 5:10 PM > To: Deshpande, Vivek R; 'Nils Eliasson'; 'hotspot-compiler-dev at openjdk.java.net ' > Cc: 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian Thalinger'; Viswanathan, Sandhya > Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > Sent out the wrong link by mistake. > > updated webrev: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ > > Regards > Vivek > > > From: Deshpande, Vivek R > Sent: Wednesday, April 20, 2016 5:07 PM > To: 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net > Cc: Vladimir Kozlov; Volker Simonis; Christian Thalinger; Viswanathan, Sandhya > Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > Hi Nils > > I have updated the webrev with all the suggestions. > updated webrev: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ > Thanks for your comments and review. > > @Vladimir, > I have taken care of all the comments. Would you please review and sponsor the patch. > > Thanks and regards, > Vivek > > From: Nils Eliasson [mailto:nils.eliasson at oracle.com ] > Sent: Wednesday, April 20, 2016 12:27 PM > To: Deshpande, Vivek R; hotspot-compiler-dev at openjdk.java.net > Cc: Vladimir Kozlov; Volker Simonis; Christian Thalinger; Viswanathan, Sandhya > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > In vmSymbols.cpp together with the other flag checks. > > Regards, > Nils > > On 2016-04-20 02:44, Deshpande, Vivek R wrote: > HI Nils > > Yes you are right the function accesses the command line flag DisableIntrinsic and changes are static. > Could you point me the right location for the function ? > Also I have updated the webrev with rest of the comments here: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ > > Regards, > Vivek > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net ]On Behalf Of Nils Eliasson > Sent: Tuesday, April 19, 2016 5:55 AM > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > Hi Vivek, > > The changes in is_intrinsic_disabled in compilerDirectives.* are static and only access the command line flag DisableIntrinsics. As long as stubs are only generated during startup and don't have a method context - that is ok - but it doesn't belong in the compilerDirectives-files if it doens't use directives. > > Regards, > Nils > > On 2016-04-18 19:38, Deshpande, Vivek R wrote: > Hi all > > I would like to contribute a patch which helps to control the intrinsics in interpreter, c1 and c2 by disabling the stub generation. > This uses -XX:DisableIntrinsic option to achieve the same. > Could you please review and sponsor this patch. > > Bug-id: > https://bugs.openjdk.java.net/browse/JDK-8154473 > webrev: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ > > Thanks and regards, > Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Tue May 3 05:09:30 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 2 May 2016 22:09:30 -0700 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants Message-ID: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> Please review the following changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8150921 Webrev (jdk): http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/jdk/webrev/ Webrev (hotspot/): http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/hotspot/webrev/ * Summary (see bug for some additional information) There are two versions of the Unsafe getter/setter methods: one which takes an Object and a long, and one which takes a single long argument. For example: float getFloat(Object o, long offset); float getFloat(long address); The two-argument (aka. double-register) version can operate both on Java heap data (if o is non-null) and data in native memory (if o is null). The latter, single-register version only supports native data, and behaves exactly like the corresponding double-register version with an 'o' argument of null. This change updates Unsafe.java to make the single-register versions do exactly that - call the double-register version with a first 'null' argument. Doing this on the Unsafe.java level means means that the VM only needs to implement support for a a single set of the primitives, and most of the rest of the changes are removing the code related to the (now) dead intrinsics. However, the changes in library_call.cpp are a bit less straightforward, so I would appreciate a detailed review of those changes in particular. To reduce the risk of any performance regressions the single-register methods have all been annotated with @ForceInline. This change also introduces a helper class called "MemoryAccess" in unsafe.cpp, which unifies and encapsulates the logic needed to perform the different types of memory accesses. Specifically, the class captures logic to: - use the right C++/Hotspot primitives for performing normal, volatile and mutex guarded memory accesses respectively - normalize the stored values - set and restore the doing_unsafe_access state in the thread if needed (checked by the signal handler in case a SIGBUS signal is raised) * Testing: I have used the following test to drive the development of this change: http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java Unfortunately, the test doesn't work reliably unless also applying some workaround changes the problem of the SIGBUS related exceptions not being thrown synchronously. Making the delivery synchronous is covered by [1]. I added the test as an attachment to [1] for future use. In addition to the above test I have run the normal JPRT smoke testing. I will also run some additional testing before pushing, but feel like this is a good time to get some feedback. Cheers, Mikael [1] https://bugs.openjdk.java.net/browse/JDK-8154592 From roland.schatz at oracle.com Tue May 3 10:02:29 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Tue, 3 May 2016 12:02:29 +0200 Subject: RFR(XS): 8155735: use strings instead of Symbol* in JVMCI exception stubs In-Reply-To: <345C0B1B-07D3-41A8-8C9F-2C73A41B3717@oracle.com> References: <5723657C.6020804@oracle.com> <572383EE.5060608@oracle.com> <57275A29.10601@oracle.com> <345C0B1B-07D3-41A8-8C9F-2C73A41B3717@oracle.com> Message-ID: <57287735.2060308@oracle.com> On 05/02/2016 06:53 PM, Christian Thalinger wrote: >> [...] >> >> I've also included an exception check after the symbol lookup, just to be sure. > Use CHECK instead of HAS_PENDING_EXCEPTION. Otherwise this looks good. Done: http://cr.openjdk.java.net/~rschatz/JDK-8155735/webrev.02/ - Roland From martin.doerr at sap.com Tue May 3 10:16:54 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 3 May 2016 10:16:54 +0000 Subject: RFR(M): 8141635: Implement new Unsafe intrinsics on POWER Message-ID: <075bd830305c426996ef758e0a37ed87@DEWDFE13DE14.global.corp.sap> Hi, I have implemented the C2 intrinsics for the new internal Unsafe methods (used by VarHandles) on PPC64. According to JEP 193, Compare and Swap/Exchange methods need to behave like volatile load + volatile store. Therefore, I had to make a change to the shared library_call implementation (support_IRIW_for_not_multiple_copy_atomic_cpu was not yet included). I also assert that GetAndAdd and GetAndSet are only used with seq_cst semantics, because the memory order is not passed to these intrinsics. C++2011 supports specifying weaker semantics for failed cases of atomic_compare_exchange than for successful ones. As I understand JEP 193, Java expects the semantics for failed cases to be the same as for successful cases. That means the memory barrier instruction must be executed even though the store was not executed. So the failed Compare and Swap/Exchange behaves like a volatile load. I made an exception to that rule for weak versions of Compare and Swap because they are allowed to fail a little more often as necessary. They do not return the loaded value, but only report whether the Swap was performed or not. The failure cause is not clearly identifiable and I don't see any purpose of executing a memory barrier in case of failure. Can somebody confirm if this is as required, please? Here's the webrev: http://cr.openjdk.java.net/~mdoerr/8141635_PPC_CAS/webrev.00/ Please review. I will also need a sponsor from Oracle, please. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Tue May 3 13:34:04 2016 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 3 May 2016 15:34:04 +0200 Subject: RFR: 8155023: jdk.vm.ci needs to securely export services Message-ID: https://bugs.openjdk.java.net/browse/JDK-8155023 http://cr.openjdk.java.net/~dnsimon/8155023/ -Doug From aleksey.shipilev at oracle.com Tue May 3 15:15:10 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 3 May 2016 18:15:10 +0300 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> Message-ID: <5728C07E.1070406@oracle.com> On 05/03/2016 08:09 AM, Mikael Vidstedt wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8150921 > Webrev (jdk): > http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/jdk/webrev/ > Webrev (hotspot/): > http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/hotspot/webrev/ Nice move overall! unsafe.cpp: *) Why do we Handle-ize incoming object in CompareAnd*? Is this because we may acquire a mutex, and the object may be gone? Either way, I see you have dropped Handle from Unsafe_CompareAndSwapLong, but kept it in Unsafe_CompareAndExchangeLong -- why? *) Ditto for old {Get|Set}LongVolatile -- it used to Handle-ize before acquiring a mutex -- now we don't do that in MemoryAccess. vmSymbols.cpp: *) {get|put}Address_raw intrinsics used to be conditionalized under UseUnalignedAccesses. Baffles me why, because the old native code in Unsafe_{Get|Set}NativeAddress/unsafe.cpp would seem to fail with misaligned addresses. I wonder if the intent was to never fail, and then we should really use Unsafe.{get|put}Unaligned in new Unsafe.java {get|set}Address to dodge misalign faults? library_call.cpp: *) What is the point for doing this check: 2372 if (_gvn.type(base)->isa_ptr() != TypePtr::NULL_PTR) { 2373 heap_base_oop = base; 2374 } In old code heap_base_oop != top() only for heap ptrs, even if base is NULL. In new code, if base is NULL, then heap_base_oop is top(). It would seem that new code is better, because it clearly separates heap vs. native accesses, and it does not seem to break anything downstream. Was that the intent? 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 ahmed.khawaja at oracle.com Tue May 3 15:38:10 2016 From: ahmed.khawaja at oracle.com (Ahmed Khawaja) Date: Tue, 3 May 2016 10:38:10 -0500 Subject: Intrinsic interactions with Deoptimization Message-ID: <5728C5E2.3010708@oracle.com> Greetings, I am working on a C2 intrinsic and I have a question concerning deoptimization. The calling method is being deoptimized after a certain point with the cause being unstable branches. While I understand that the calling method should be reprofiled/recompiled, it was my understanding that after an intrinsic was triggered, any calls to it (the intrinsified function) would always result in the intrinsic code running. What I am seeing is when the parent/calling method falls back to interpreter mode to re-profile, the intrinsic code is no longer being called and the Java implementation of the (called) method is being used. Can someone shine some light on the interaction between intrinsics and deoptimization? My hypothesis is that the intrinsic code that was generated is still there, but some glue code was flushed during deoptimization. The desired behavior I am pursuing is that once the method triggers intrinsification, the intrinsic should always be used. Is falling back to interpretation an all or nothing type behavior? Thank you, Ahmed Khawaja From tom.rodriguez at oracle.com Tue May 3 15:43:39 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 3 May 2016 08:43:39 -0700 Subject: RFR 8155771: [JVMCI] expose JVM_ACC_IS_CLONEABLE_FAST In-Reply-To: References: <579B4981-C0D1-4177-9DED-8BCD6C233395@oracle.com> <0C76F8C6-012E-48F4-934D-4BFB9DC241A3@oracle.com> <582A1B37-8F4C-4151-8E0C-D77E73236C93@oracle.com> <1413B33E-DFF5-4817-872E-1DAB9A1D8EA9@oracle.com> Message-ID: >>>>> >>>>> That means ?allocation-cloneable?, not ?allocation is cloneable?, right? It could be interpreted both ways but the change is good. >>>> >>>> I knew what I meant so I didn?t see alternative readings. Is there something better? canBeClonedWithAllocation :) >>> >>> :-) Actually, that?s not a bad name. Or isClonableWithAllocation. >> >> isClonableWithAllocation is ok, though it seems like it should be isCloneableWithAllocation? > > Yes, that. Typo. Updated and pushing. tom > >> >> tom >> >>> >>>> >>>> tom >>>> >>>>> >>>>>> >>>>>> The new flag JVM_ACC_IS_CLONEABLE_FAST controls whether an object can be cloned by simply performing an allocation and copying the fields. Previously all Cloneable objects were assumed to be cloneable in this way. Add ResolvedJavaType.isAllocationCloneable to expose this notion. Tested with Graal. >>>>>> >>>>>> tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue May 3 17:03:56 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 3 May 2016 07:03:56 -1000 Subject: RFR(XS): 8155735: use strings instead of Symbol* in JVMCI exception stubs In-Reply-To: <57287735.2060308@oracle.com> References: <5723657C.6020804@oracle.com> <572383EE.5060608@oracle.com> <57275A29.10601@oracle.com> <345C0B1B-07D3-41A8-8C9F-2C73A41B3717@oracle.com> <57287735.2060308@oracle.com> Message-ID: <6CC72946-0985-4E43-AA08-BC4016277E6F@oracle.com> > On May 3, 2016, at 12:02 AM, Roland Schatz wrote: > > On 05/02/2016 06:53 PM, Christian Thalinger wrote: >>> [...] >>> >>> I've also included an exception check after the symbol lookup, just to be sure. >> Use CHECK instead of HAS_PENDING_EXCEPTION. Otherwise this looks good. > Done: > http://cr.openjdk.java.net/~rschatz/JDK-8155735/webrev.02/ Thanks. I will integrate this. > > > - Roland From mikael.vidstedt at oracle.com Tue May 3 18:43:00 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 3 May 2016 11:43:00 -0700 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <5728C07E.1070406@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> Message-ID: <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> Thank you very much for the review, some comments inline... On 5/3/2016 8:15 AM, Aleksey Shipilev wrote: > On 05/03/2016 08:09 AM, Mikael Vidstedt wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150921 >> Webrev (jdk): >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/jdk/webrev/ >> Webrev (hotspot/): >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/hotspot/webrev/ > Nice move overall! > > unsafe.cpp: > > *) Why do we Handle-ize incoming object in CompareAnd*? Is this because > we may acquire a mutex, and the object may be gone? Either way, I see > you have dropped Handle from Unsafe_CompareAndSwapLong, but kept it in > Unsafe_CompareAndExchangeLong -- why? > > *) Ditto for old {Get|Set}LongVolatile -- it used to Handle-ize before > acquiring a mutex -- now we don't do that in MemoryAccess. My bad. As you say resolving the object should happen after the mutex has been acquired (see long comment starting on line 377 for the background). I have added back the Handle in CompareAndSwapLong and moved the addr() call in the mutex methods of MemoryAccess. Thank you for catching that! > > vmSymbols.cpp: > > *) {get|put}Address_raw intrinsics used to be conditionalized under > UseUnalignedAccesses. Baffles me why, because the old native code in > Unsafe_{Get|Set}NativeAddress/unsafe.cpp would seem to fail with > misaligned addresses. I wonder if the intent was to never fail, and then > we should really use Unsafe.{get|put}Unaligned in new Unsafe.java > {get|set}Address to dodge misalign faults? I also failed to see what the conditional intrinsification is trying to achieve given that the native code does nothing special for the unaligned case. Unless I'm missing something the proposed change makes it no worse, and will potentially improve performance a tad on the pickier platforms. If anything we may want to consider introducing methods for getAddressUnaligned and putAddressUnaligned as a separate change. > library_call.cpp: > > *) What is the point for doing this check: > > 2372 if (_gvn.type(base)->isa_ptr() != TypePtr::NULL_PTR) { > 2373 heap_base_oop = base; > 2374 } > > In old code heap_base_oop != top() only for heap ptrs, even if base is > NULL. In new code, if base is NULL, then heap_base_oop is top(). It > would seem that new code is better, because it clearly separates heap > vs. native accesses, and it does not seem to break anything downstream. > Was that the intent? Those three lines were actually donated to my by John Rose, so I'm hoping he or somebody else more knowledgeable in C2 can provide some helpful comments on the correctness and validity of that specific change. I also changed the normalize() methods to be private in the MemoryAccess class, and made the MemoryAccess class a StackObj. New webrev(s) here: jdk: http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/jdk/webrev/ hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/hotspot/webrev/ Incremental from webrev.01: jdk: N/A (no changes) hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02.incr/hotspot/webrev/ Cheers, Mikael > > Thanks, > -Aleksey > > From aleksey.shipilev at oracle.com Tue May 3 19:27:33 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 3 May 2016 22:27:33 +0300 Subject: RFR(M): 8141635: Implement new Unsafe intrinsics on POWER In-Reply-To: <075bd830305c426996ef758e0a37ed87@DEWDFE13DE14.global.corp.sap> References: <075bd830305c426996ef758e0a37ed87@DEWDFE13DE14.global.corp.sap> Message-ID: <5728FBA5.2010808@oracle.com> Hi Martin, On 05/03/2016 01:16 PM, Doerr, Martin wrote: > According to JEP 193, Compare and Swap/Exchange methods need to behave > like volatile load + volatile store. > > Therefore, I had to make a change to the shared library_call > implementation (support_IRIW_for_not_multiple_copy_atomic_cpu was not > yet included). Yes, CAS/CAE are supposed to be sequentially consistent. This change looks correct, if a hardware CAS is not SC: 2852 switch (access_kind) { ... 2856 case Release: 2857 insert_mem_bar(Op_MemBarRelease); 2858 break; 2859 case Volatile: 2860 if (support_IRIW_for_not_multiple_copy_atomic_cpu) { 2861 insert_mem_bar(Op_MemBarVolatile); 2862 } else { 2863 insert_mem_bar(Op_MemBarRelease); 2864 } 2865 break; Actually, that seems to mean current CAS implementation on POWER, prior to VarHandles, was also broken. > I also assert that GetAndAdd and GetAndSet are only used with seq_cst > semantics, because the memory order is not passed to these intrinsics. Yes, good. > C++2011 supports specifying weaker semantics for failed cases of > atomic_compare_exchange than for successful ones. > > As I understand JEP 193, Java expects the semantics for failed cases to > be the same as for successful cases. > > That means the memory barrier instruction must be executed even though > the store was not executed. So the failed Compare and Swap/Exchange > behaves like a volatile load. Yes, that's the difference between VarHandles and C++11 semantics. VarHandles provide a single memory ordering, regardless of success/failure. I wonder, however, why you need sync() after CAS? C++11 mappings on POWER: https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html ...say that Cmpxchg SeqCst is: hwsync; // Op_MemBarVolatile _loop: lwarx; cmp; bc _exit; stwcx.; bc _loop; isync; _exit: Load Seq Cst, which is similar to failing CAS semantics, is: hwsync; ld; cmp; bc; isync Therefore isync() is enough after CAS in ppc.ad? Also, why not fix the CAS in MacroAssembler with these barriers to match C++11 mappings, instead of doing special cases in .ad? > They do not return the loaded value, but only report whether the Swap > was performed or not. The failure cause is not clearly identifiable and > I don?t see any purpose of executing a memory barrier in case of failure. I don't think this is about the returned value, but rather about the transitive memory effects. So, I would post the barrier on the exit path for weakCAS{Acquire,Release} too. Thanks, -Aleksey P.S. Note that we have weakCompareAndSetVolatile intrinsics in works, which would probably require a few additional matches in .ad... https://bugs.openjdk.java.net/browse/JDK-8155965 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From aleksey.shipilev at oracle.com Tue May 3 20:05:26 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 3 May 2016 23:05:26 +0300 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> Message-ID: <57290486.6000304@oracle.com> On 05/03/2016 09:43 PM, Mikael Vidstedt wrote: > On 5/3/2016 8:15 AM, Aleksey Shipilev wrote: >> *) Why do we Handle-ize incoming object in CompareAnd*? Is this because >> we may acquire a mutex, and the object may be gone? Either way, I see >> you have dropped Handle from Unsafe_CompareAndSwapLong, but kept it in >> Unsafe_CompareAndExchangeLong -- why? >> >> *) Ditto for old {Get|Set}LongVolatile -- it used to Handle-ize before >> acquiring a mutex -- now we don't do that in MemoryAccess. > > My bad. As you say resolving the object should happen after the mutex > has been acquired (see long comment starting on line 377 for the > background). I have added back the Handle in CompareAndSwapLong and > moved the addr() call in the mutex methods of MemoryAccess. Thank you > for catching that! Right. We have two related problems: a) the code in Unsafe_{Get|Set}LongVolatile computes the address *before* acquiring the mutex, contrary to what comment suggests for safety; this is fixed by your patch -- MemoryAccess handles that; b) the code in Unsafe_CompareAnd{Exchange,Swap}Long computes the address *before* acquiring the mutex, and this is still problematic; I wonder if you want to soak in CAS/CAE into MemoryAccess too? I actually wonder why those accessors (especially non-long) are UNSAFE_ENTRY, not UNSAFE_LEAF, if "we can treat those as leaf routines"... Another question to pile on: why only LongVolatile is treated specially, but not DoubleVolatile too? Atomicity requirements are the same for both long and double. >> vmSymbols.cpp: >> >> *) {get|put}Address_raw intrinsics used to be conditionalized under >> UseUnalignedAccesses. Baffles me why, because the old native code in >> Unsafe_{Get|Set}NativeAddress/unsafe.cpp would seem to fail with >> misaligned addresses. I wonder if the intent was to never fail, and then >> we should really use Unsafe.{get|put}Unaligned in new Unsafe.java >> {get|set}Address to dodge misalign faults? > > I also failed to see what the conditional intrinsification is trying to > achieve given that the native code does nothing special for the > unaligned case. Unless I'm missing something the proposed change makes > it no worse, and will potentially improve performance a tad on the > pickier platforms. If anything we may want to consider introducing > methods for getAddressUnaligned and putAddressUnaligned as a separate > change. Yes, there is no advertised behavior for misaligned {get|put}Address. Only the intrinsic filters trip you off. I agree we can move on from there. > jdk: > http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/jdk/webrev/ > hotspot: > http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/hotspot/webrev/ 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 mikael.vidstedt at oracle.com Tue May 3 20:17:33 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 3 May 2016 13:17:33 -0700 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <57290486.6000304@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> <57290486.6000304@oracle.com> Message-ID: <2c216375-2574-64f7-5b9e-3d0519b479f7@oracle.com> On 5/3/2016 1:05 PM, Aleksey Shipilev wrote: > On 05/03/2016 09:43 PM, Mikael Vidstedt wrote: >> On 5/3/2016 8:15 AM, Aleksey Shipilev wrote: >>> *) Why do we Handle-ize incoming object in CompareAnd*? Is this because >>> we may acquire a mutex, and the object may be gone? Either way, I see >>> you have dropped Handle from Unsafe_CompareAndSwapLong, but kept it in >>> Unsafe_CompareAndExchangeLong -- why? >>> >>> *) Ditto for old {Get|Set}LongVolatile -- it used to Handle-ize before >>> acquiring a mutex -- now we don't do that in MemoryAccess. >> My bad. As you say resolving the object should happen after the mutex >> has been acquired (see long comment starting on line 377 for the >> background). I have added back the Handle in CompareAndSwapLong and >> moved the addr() call in the mutex methods of MemoryAccess. Thank you >> for catching that! > Right. We have two related problems: > > a) the code in Unsafe_{Get|Set}LongVolatile computes the address > *before* acquiring the mutex, contrary to what comment suggests for > safety; this is fixed by your patch -- MemoryAccess handles that; > > b) the code in Unsafe_CompareAnd{Exchange,Swap}Long computes the > address *before* acquiring the mutex, and this is still problematic; I > wonder if you want to soak in CAS/CAE into MemoryAccess too? > > I actually wonder why those accessors (especially non-long) are > UNSAFE_ENTRY, not UNSAFE_LEAF, if "we can treat those as leaf routines"... Ah, yes, now I see what you're saying. In general, since the mutex isn't actually checking for safepoints right now this isn't really a problem, but it would definitely be nice to unify it. How about I file a separate enhancement for moving the other memory operations into MemoryAccess? > Another question to pile on: why only LongVolatile is treated specially, > but not DoubleVolatile too? Atomicity requirements are the same for both > long and double. Very good question. I don't have the answer, but maybe somebody else knows. Cheers, Mikael > >>> vmSymbols.cpp: >>> >>> *) {get|put}Address_raw intrinsics used to be conditionalized under >>> UseUnalignedAccesses. Baffles me why, because the old native code in >>> Unsafe_{Get|Set}NativeAddress/unsafe.cpp would seem to fail with >>> misaligned addresses. I wonder if the intent was to never fail, and then >>> we should really use Unsafe.{get|put}Unaligned in new Unsafe.java >>> {get|set}Address to dodge misalign faults? >> I also failed to see what the conditional intrinsification is trying to >> achieve given that the native code does nothing special for the >> unaligned case. Unless I'm missing something the proposed change makes >> it no worse, and will potentially improve performance a tad on the >> pickier platforms. If anything we may want to consider introducing >> methods for getAddressUnaligned and putAddressUnaligned as a separate >> change. > Yes, there is no advertised behavior for misaligned {get|put}Address. > Only the intrinsic filters trip you off. I agree we can move on from there. > >> jdk: >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/jdk/webrev/ >> hotspot: >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/hotspot/webrev/ > Thanks, > -Aleksey > From aleksey.shipilev at oracle.com Tue May 3 20:33:49 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 3 May 2016 23:33:49 +0300 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <2c216375-2574-64f7-5b9e-3d0519b479f7@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> <57290486.6000304@oracle.com> <2c216375-2574-64f7-5b9e-3d0519b479f7@oracle.com> Message-ID: <57290B2D.80902@oracle.com> On 05/03/2016 11:17 PM, Mikael Vidstedt wrote: > On 5/3/2016 1:05 PM, Aleksey Shipilev wrote: >> I actually wonder why those accessors (especially non-long) are >> UNSAFE_ENTRY, not UNSAFE_LEAF, if "we can treat those as leaf >> routines"... > > Ah, yes, now I see what you're saying. In general, since the mutex isn't > actually checking for safepoints right now this isn't really a problem, > but it would definitely be nice to unify it. How about I file a separate > enhancement for moving the other memory operations into MemoryAccess? Sure, do that. That's not the end of unsafe.cpp story anyway. 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 david.holmes at oracle.com Tue May 3 20:55:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 May 2016 06:55:08 +1000 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <2c216375-2574-64f7-5b9e-3d0519b479f7@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> <57290486.6000304@oracle.com> <2c216375-2574-64f7-5b9e-3d0519b479f7@oracle.com> Message-ID: <9c5fb65a-09c9-36cc-8141-0d0c245cc781@oracle.com> On 4/05/2016 6:17 AM, Mikael Vidstedt wrote: > > > On 5/3/2016 1:05 PM, Aleksey Shipilev wrote: >> On 05/03/2016 09:43 PM, Mikael Vidstedt wrote: >>> On 5/3/2016 8:15 AM, Aleksey Shipilev wrote: >>>> *) Why do we Handle-ize incoming object in CompareAnd*? Is this because >>>> we may acquire a mutex, and the object may be gone? Either way, I see >>>> you have dropped Handle from Unsafe_CompareAndSwapLong, but kept it in >>>> Unsafe_CompareAndExchangeLong -- why? >>>> >>>> *) Ditto for old {Get|Set}LongVolatile -- it used to Handle-ize before >>>> acquiring a mutex -- now we don't do that in MemoryAccess. >>> My bad. As you say resolving the object should happen after the mutex >>> has been acquired (see long comment starting on line 377 for the >>> background). I have added back the Handle in CompareAndSwapLong and >>> moved the addr() call in the mutex methods of MemoryAccess. Thank you >>> for catching that! >> Right. We have two related problems: >> >> a) the code in Unsafe_{Get|Set}LongVolatile computes the address >> *before* acquiring the mutex, contrary to what comment suggests for >> safety; this is fixed by your patch -- MemoryAccess handles that; >> >> b) the code in Unsafe_CompareAnd{Exchange,Swap}Long computes the >> address *before* acquiring the mutex, and this is still problematic; I >> wonder if you want to soak in CAS/CAE into MemoryAccess too? >> >> I actually wonder why those accessors (especially non-long) are >> UNSAFE_ENTRY, not UNSAFE_LEAF, if "we can treat those as leaf >> routines"... > > Ah, yes, now I see what you're saying. In general, since the mutex isn't > actually checking for safepoints right now this isn't really a problem, > but it would definitely be nice to unify it. How about I file a separate > enhancement for moving the other memory operations into MemoryAccess? I need to look at this again to see what I previously changed it from and to. No safepoints means no object movement so calculating before the lock acquisition is safe. That does seem to make the use of Handles unnecessary though ... >> Another question to pile on: why only LongVolatile is treated specially, >> but not DoubleVolatile too? Atomicity requirements are the same for both >> long and double. > > Very good question. I don't have the answer, but maybe somebody else knows. For doubles we use FPU tricks to get atomicity for volatile accesses. The differences are historical. In theory we could have a platform that needs locking for volatile doubles too. David ----- > Cheers, > Mikael > >> >>>> vmSymbols.cpp: >>>> >>>> *) {get|put}Address_raw intrinsics used to be conditionalized under >>>> UseUnalignedAccesses. Baffles me why, because the old native code in >>>> Unsafe_{Get|Set}NativeAddress/unsafe.cpp would seem to fail with >>>> misaligned addresses. I wonder if the intent was to never fail, and >>>> then >>>> we should really use Unsafe.{get|put}Unaligned in new Unsafe.java >>>> {get|set}Address to dodge misalign faults? >>> I also failed to see what the conditional intrinsification is trying to >>> achieve given that the native code does nothing special for the >>> unaligned case. Unless I'm missing something the proposed change makes >>> it no worse, and will potentially improve performance a tad on the >>> pickier platforms. If anything we may want to consider introducing >>> methods for getAddressUnaligned and putAddressUnaligned as a separate >>> change. >> Yes, there is no advertised behavior for misaligned {get|put}Address. >> Only the intrinsic filters trip you off. I agree we can move on from >> there. >> >>> jdk: >>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/jdk/webrev/ >>> hotspot: >>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/hotspot/webrev/ >>> >> Thanks, >> -Aleksey >> > From john.r.rose at oracle.com Tue May 3 21:01:45 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 3 May 2016 14:01:45 -0700 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> Message-ID: <58A14778-142E-4238-B229-376381E4EE52@oracle.com> On May 3, 2016, at 11:43 AM, Mikael Vidstedt wrote: > >> >> library_call.cpp: >> >> *) What is the point for doing this check: >> >> 2372 if (_gvn.type(base)->isa_ptr() != TypePtr::NULL_PTR) { >> 2373 heap_base_oop = base; >> 2374 } >> >> In old code heap_base_oop != top() only for heap ptrs, even if base is >> NULL. In new code, if base is NULL, then heap_base_oop is top(). It >> would seem that new code is better, because it clearly separates heap >> vs. native accesses, and it does not seem to break anything downstream. >> Was that the intent? > > Those three lines were actually donated to my by John Rose, so I'm hoping he or somebody else more knowledgeable in C2 can provide some helpful comments on the correctness and validity of that specific change. Yes, the intent is that heap_base_oop is top (= absent) if the base argument is constant null (from any source). The heap_base_oop is present (i.e., it's not top) if and only if the base argument might be non-null. If it might be non-null, then some logic needs adjusting. The GC might need a handshake, and we might try to constant-fold from a Java object field. In the worst case, base may be either null or non-null, and we get here: // We can't tell at compile time if we are storing in the Java heap or outside // of it. So we need to emit code to conditionally do the proper type of // store. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Tue May 3 21:03:36 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 3 May 2016 14:03:36 -0700 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <2c216375-2574-64f7-5b9e-3d0519b479f7@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> <57290486.6000304@oracle.com> <2c216375-2574-64f7-5b9e-3d0519b479f7@oracle.com> Message-ID: <63B91162-5668-454F-B3C7-497C9D058F4C@oracle.com> On May 3, 2016, at 1:17 PM, Mikael Vidstedt wrote: > >> >> I actually wonder why those accessors (especially non-long) are >> UNSAFE_ENTRY, not UNSAFE_LEAF, if "we can treat those as leaf routines"... > > Ah, yes, now I see what you're saying. In general, since the mutex isn't actually checking for safepoints right now this isn't really a problem, but it would definitely be nice to unify it. How about I file a separate enhancement for moving the other memory operations into MemoryAccess? +1 >> Another question to pile on: why only LongVolatile is treated specially, >> but not DoubleVolatile too? Atomicity requirements are the same for both >> long and double. > > Very good question. I don't have the answer, but maybe somebody else knows. Probably nobody was using the double version, so we didn't bother to put it in. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Tue May 3 21:37:48 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 May 2016 14:37:48 -0700 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <63B91162-5668-454F-B3C7-497C9D058F4C@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> <57290486.6000304@oracle.com> <2c216375-2574-64f7-5b9e-3d0519b479f7@oracle.com> <63B91162-5668-454F-B3C7-497C9D058F4C@oracle.com> Message-ID: > On 3 May 2016, at 14:03, John Rose wrote: > >>> Another question to pile on: why only LongVolatile is treated specially, >>> but not DoubleVolatile too? Atomicity requirements are the same for both >>> long and double. >> >> Very good question. I don't have the answer, but maybe somebody else knows. > > Probably nobody was using the double version, so we didn't bother to put it in. > The single register variant U.get/putDouble is used by a native aligned DoubleBuffer view over a ByteBuffer. But who was using those? :-) 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 mikael.vidstedt at oracle.com Tue May 3 21:59:17 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 3 May 2016 14:59:17 -0700 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <57290B2D.80902@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> <57290486.6000304@oracle.com> <2c216375-2574-64f7-5b9e-3d0519b479f7@oracle.com> <57290B2D.80902@oracle.com> Message-ID: On 5/3/2016 1:33 PM, Aleksey Shipilev wrote: > On 05/03/2016 11:17 PM, Mikael Vidstedt wrote: >> On 5/3/2016 1:05 PM, Aleksey Shipilev wrote: >>> I actually wonder why those accessors (especially non-long) are >>> UNSAFE_ENTRY, not UNSAFE_LEAF, if "we can treat those as leaf >>> routines"... >> Ah, yes, now I see what you're saying. In general, since the mutex isn't >> actually checking for safepoints right now this isn't really a problem, >> but it would definitely be nice to unify it. How about I file a separate >> enhancement for moving the other memory operations into MemoryAccess? > Sure, do that. That's not the end of unsafe.cpp story anyway. We all wish it would be the end of the story, don't we... ;) I filed https://bugs.openjdk.java.net/browse/JDK-8155982 - "CompareAndExchange/Swap should leverage MemoryAccess class Cheers, Mikael > > Thanks, > -Aleksey > From vivek.r.deshpande at intel.com Tue May 3 23:09:24 2016 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Tue, 3 May 2016 23:09:24 +0000 Subject: RFR (XS): 8155864: Bug fix for api/java_lang/Math/cos_cos6 and sin_sin6 failure Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A8FE94@ORSMSX106.amr.corp.intel.com> Hi I have resolved the bug and fix for the same is here. http://cr.openjdk.java.net/~vdeshpande/8155864/webrev.00/ I have also updated the JBS entry. https://bugs.openjdk.java.net/browse/JDK-8155864 Would you please review it. Regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue May 3 23:10:46 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 3 May 2016 16:10:46 -0700 Subject: RFR (XS): 8155864: Bug fix for api/java_lang/Math/cos_cos6 and sin_sin6 failure In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A8FE94@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A8FE94@ORSMSX106.amr.corp.intel.com> Message-ID: <57292FF6.7000402@oracle.com> Changes are good. I will sponsor it into jdk9/hs. Thanks, Vladimir On 5/3/16 4:09 PM, Deshpande, Vivek R wrote: > Hi > > I have resolved the bug and fix for the same is here. > > http://cr.openjdk.java.net/~vdeshpande/8155864/webrev.00/ > > I have also updated the JBS entry. > > https://bugs.openjdk.java.net/browse/JDK-8155864 > > Would you please review it. > > Regards, > > Vivek > From paul.sandoz at oracle.com Tue May 3 23:16:27 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 May 2016 16:16:27 -0700 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> Message-ID: > On 3 May 2016, at 11:43, Mikael Vidstedt wrote: > New webrev(s) here: > > jdk: http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/jdk/webrev/ > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/hotspot/webrev/ > 266 /** @see #getInt(Object, long) */ 267 @ForceInline 268 public long getAddress(Object o, long offset) { 269 if (ADDRESS_SIZE == 4) { 270 return Integer.toUnsignedLong(getInt(o, offset)); 271 } else { 272 return getLong(o, offset); 273 } 274 } 275 276 /** @see #putInt(Object, long, int) */ 277 @ForceInline 278 public void putAddress(Object o, long offset, long x) { 279 if (ADDRESS_SIZE == 4) { 280 putInt(o, offset, (int)x); 281 } else { 282 putLong(o, offset, x); 283 } 284 } Why not just copy the documentation from the single register variant, or perhaps just switch it over? so the single @see?s the double register variant. Paul. > Incremental from webrev.01: > > jdk: N/A (no changes) > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02.incr/hotspot/webrev/ > > Cheers, > Mikael > >> >> Thanks, >> -Aleksey >> >> > -------------- 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 paul.sandoz at oracle.com Wed May 4 00:25:37 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 May 2016 17:25:37 -0700 Subject: RFR 8151268: Wire up the x86 _vectorizedMismatch stub routine in C1 Message-ID: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151268-int-c1-mismatch/webrev/ This webrev wires up the array mismatch stub to C1. (Previously i also wired this up to the interpreter but pulled that part out based on feedback, although i have left some updates in the comments). JPRT testsets core and hotspot pass. 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 paul.sandoz at oracle.com Wed May 4 00:30:19 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 May 2016 17:30:19 -0700 Subject: RFR (S): 8154975: Update for vectorizedMismatch with AVX512 In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A8658C@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A8658C@ORSMSX106.amr.corp.intel.com> Message-ID: Hi Vivek, Do you have any details on the performance you can share? Thanks, Paul. > On 22 Apr 2016, at 18:10, Deshpande, Vivek R wrote: > > Hi all > > I would like to contribute a patch with AVX512 support for the vectorizedMismatch intrinsic. > Could you please review and sponsor this patch. > > Bug-id: > https://bugs.openjdk.java.net/browse/JDK-8154975 > webrev: > http://cr.openjdk.java.net/~vdeshpande/8154975/webrev.00/ > > Thanks and regards, > Vivek -------------- 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 vivek.r.deshpande at intel.com Wed May 4 00:57:13 2016 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Wed, 4 May 2016 00:57:13 +0000 Subject: RFR (S): 8154975: Update for vectorizedMismatch with AVX512 In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A8658C@ORSMSX106.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A8FFA0@ORSMSX106.amr.corp.intel.com> Hi Paul We observed 2x gain with long arrays (1k bytes) over current intrinsic in avx2 using avx512. Regards, Vivek From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Paul Sandoz Sent: Tuesday, May 03, 2016 5:30 PM Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): 8154975: Update for vectorizedMismatch with AVX512 Hi Vivek, Do you have any details on the performance you can share? Thanks, Paul. On 22 Apr 2016, at 18:10, Deshpande, Vivek R > wrote: Hi all I would like to contribute a patch with AVX512 support for the vectorizedMismatch intrinsic. Could you please review and sponsor this patch. Bug-id: https://bugs.openjdk.java.net/browse/JDK-8154975 webrev: http://cr.openjdk.java.net/~vdeshpande/8154975/webrev.00/ Thanks and regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Wed May 4 03:42:49 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 May 2016 20:42:49 -0700 Subject: RFR (S): 8154975: Update for vectorizedMismatch with AVX512 In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A8FFA0@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A8658C@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8FFA0@ORSMSX106.amr.corp.intel.com> Message-ID: <47026F72-33BA-42EA-BACC-49A4A77071A5@oracle.com> > On 3 May 2016, at 17:57, Deshpande, Vivek R wrote: > > Hi Paul > > We observed 2x gain with long arrays (1k bytes) over current intrinsic in avx2 using avx512. > Ok, so grows ~linearly. Do you observe any performance differences based on alignment, i.e. array-start/offset-address % 64 ? 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 david.holmes at oracle.com Wed May 4 04:27:13 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 May 2016 14:27:13 +1000 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <9c5fb65a-09c9-36cc-8141-0d0c245cc781@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> <57290486.6000304@oracle.com> <2c216375-2574-64f7-5b9e-3d0519b479f7@oracle.com> <9c5fb65a-09c9-36cc-8141-0d0c245cc781@oracle.com> Message-ID: <4659bc96-bd2a-ee41-3bdb-abfc2898b065@oracle.com> On 4/05/2016 6:55 AM, David Holmes wrote: > > > On 4/05/2016 6:17 AM, Mikael Vidstedt wrote: >> >> >> On 5/3/2016 1:05 PM, Aleksey Shipilev wrote: >>> On 05/03/2016 09:43 PM, Mikael Vidstedt wrote: >>>> On 5/3/2016 8:15 AM, Aleksey Shipilev wrote: >>>>> *) Why do we Handle-ize incoming object in CompareAnd*? Is this >>>>> because >>>>> we may acquire a mutex, and the object may be gone? Either way, I see >>>>> you have dropped Handle from Unsafe_CompareAndSwapLong, but kept it in >>>>> Unsafe_CompareAndExchangeLong -- why? >>>>> >>>>> *) Ditto for old {Get|Set}LongVolatile -- it used to Handle-ize before >>>>> acquiring a mutex -- now we don't do that in MemoryAccess. >>>> My bad. As you say resolving the object should happen after the mutex >>>> has been acquired (see long comment starting on line 377 for the >>>> background). I have added back the Handle in CompareAndSwapLong and >>>> moved the addr() call in the mutex methods of MemoryAccess. Thank you >>>> for catching that! >>> Right. We have two related problems: >>> >>> a) the code in Unsafe_{Get|Set}LongVolatile computes the address >>> *before* acquiring the mutex, contrary to what comment suggests for >>> safety; this is fixed by your patch -- MemoryAccess handles that; >>> >>> b) the code in Unsafe_CompareAnd{Exchange,Swap}Long computes the >>> address *before* acquiring the mutex, and this is still problematic; I >>> wonder if you want to soak in CAS/CAE into MemoryAccess too? >>> >>> I actually wonder why those accessors (especially non-long) are >>> UNSAFE_ENTRY, not UNSAFE_LEAF, if "we can treat those as leaf >>> routines"... >> >> Ah, yes, now I see what you're saying. In general, since the mutex isn't >> actually checking for safepoints right now this isn't really a problem, >> but it would definitely be nice to unify it. How about I file a separate >> enhancement for moving the other memory operations into MemoryAccess? > > I need to look at this again to see what I previously changed it from > and to. No safepoints means no object movement so calculating before the > lock acquisition is safe. That does seem to make the use of Handles > unnecessary though ... Arguably the Handles are no longer needed - but all these methods utilize them. The locking choice was very specific as per the block comment: // As all the locked-regions are very short and themselves non-blocking we can treat // them as leaf routines and elide safepoint checks (ie we don't perform any thread // state transitions even when blocking for the lock). Note that if we do choose to // add safepoint checks and thread state transitions, we must ensure that we calculate // the address of the field _after_ we have acquired the lock, else the object may have // been moved by the GC David ----- >>> Another question to pile on: why only LongVolatile is treated specially, >>> but not DoubleVolatile too? Atomicity requirements are the same for both >>> long and double. >> >> Very good question. I don't have the answer, but maybe somebody else >> knows. > > For doubles we use FPU tricks to get atomicity for volatile accesses. > The differences are historical. In theory we could have a platform that > needs locking for volatile doubles too. > David > ----- > >> Cheers, >> Mikael >> >>> >>>>> vmSymbols.cpp: >>>>> >>>>> *) {get|put}Address_raw intrinsics used to be conditionalized under >>>>> UseUnalignedAccesses. Baffles me why, because the old native code in >>>>> Unsafe_{Get|Set}NativeAddress/unsafe.cpp would seem to fail with >>>>> misaligned addresses. I wonder if the intent was to never fail, and >>>>> then >>>>> we should really use Unsafe.{get|put}Unaligned in new Unsafe.java >>>>> {get|set}Address to dodge misalign faults? >>>> I also failed to see what the conditional intrinsification is trying to >>>> achieve given that the native code does nothing special for the >>>> unaligned case. Unless I'm missing something the proposed change makes >>>> it no worse, and will potentially improve performance a tad on the >>>> pickier platforms. If anything we may want to consider introducing >>>> methods for getAddressUnaligned and putAddressUnaligned as a separate >>>> change. >>> Yes, there is no advertised behavior for misaligned {get|put}Address. >>> Only the intrinsic filters trip you off. I agree we can move on from >>> there. >>> >>>> jdk: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/jdk/webrev/ >>>> >>>> hotspot: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/hotspot/webrev/ >>>> >>>> >>> Thanks, >>> -Aleksey >>> >> From david.holmes at oracle.com Wed May 4 05:07:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 May 2016 15:07:01 +1000 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> Message-ID: <9d5d8aae-1699-8701-7cfa-29473e41e7d0@oracle.com> On 4/05/2016 4:43 AM, Mikael Vidstedt wrote: > > Thank you very much for the review, some comments inline... > > On 5/3/2016 8:15 AM, Aleksey Shipilev wrote: >> On 05/03/2016 08:09 AM, Mikael Vidstedt wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150921 >>> Webrev (jdk): >>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/jdk/webrev/ >>> Webrev (hotspot/): >>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/hotspot/webrev/ >>> >> Nice move overall! >> >> unsafe.cpp: >> >> *) Why do we Handle-ize incoming object in CompareAnd*? Is this because >> we may acquire a mutex, and the object may be gone? Either way, I see >> you have dropped Handle from Unsafe_CompareAndSwapLong, but kept it in >> Unsafe_CompareAndExchangeLong -- why? >> >> *) Ditto for old {Get|Set}LongVolatile -- it used to Handle-ize before >> acquiring a mutex -- now we don't do that in MemoryAccess. > > My bad. As you say resolving the object should happen after the mutex > has been acquired (see long comment starting on line 377 for the > background). I have added back the Handle in CompareAndSwapLong and > moved the addr() call in the mutex methods of MemoryAccess. Thank you > for catching that! > >> >> vmSymbols.cpp: >> >> *) {get|put}Address_raw intrinsics used to be conditionalized under >> UseUnalignedAccesses. Baffles me why, because the old native code in >> Unsafe_{Get|Set}NativeAddress/unsafe.cpp would seem to fail with >> misaligned addresses. I wonder if the intent was to never fail, and then >> we should really use Unsafe.{get|put}Unaligned in new Unsafe.java >> {get|set}Address to dodge misalign faults? > > I also failed to see what the conditional intrinsification is trying to > achieve given that the native code does nothing special for the > unaligned case. Unless I'm missing something the proposed change makes > it no worse, and will potentially improve performance a tad on the > pickier platforms. If anything we may want to consider introducing > methods for getAddressUnaligned and putAddressUnaligned as a separate > change. > >> library_call.cpp: >> >> *) What is the point for doing this check: >> >> 2372 if (_gvn.type(base)->isa_ptr() != TypePtr::NULL_PTR) { >> 2373 heap_base_oop = base; >> 2374 } >> >> In old code heap_base_oop != top() only for heap ptrs, even if base is >> NULL. In new code, if base is NULL, then heap_base_oop is top(). It >> would seem that new code is better, because it clearly separates heap >> vs. native accesses, and it does not seem to break anything downstream. >> Was that the intent? > > Those three lines were actually donated to my by John Rose, so I'm > hoping he or somebody else more knowledgeable in C2 can provide some > helpful comments on the correctness and validity of that specific change. > > > I also changed the normalize() methods to be private in the MemoryAccess > class, and made the MemoryAccess class a StackObj. > > New webrev(s) here: > > jdk: > http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/jdk/webrev/ > hotspot: > http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/hotspot/webrev/ src/share/vm/prims/unsafe.cpp I think this is a bit over-generalized: 254 template 255 void put_mutex(T x) { 256 GuardUnsafeAccess guard(_thread, _obj); 257 258 MutexLockerEx mu(UnsafeJlong_lock, Mutex::_no_safepoint_check_flag); 259 260 T* p = (T*)addr(); 261 262 Atomic::store(normalize(x), p); 263 } The UnsafeJlong lock is, as the name suggests, only intended for use with jlongs - we have no need of it for any other type. I don't think this needs to be a template method. As noted before the lock could taken after calculating the address - to shorten the critical section. If you take care to ensure no uses of MemoryAccess transitively can hit a safepoint then you could store the oop directly rather than the jobject. That would avoid multiple calls to JNIHandles::resolve (in the GuardUnsafeAccess and addr() function). 405 if (VM_Version::supports_cx8()) { 406 return MemoryAccess(thread, obj, offset).get_volatile(); 407 } else { 408 return MemoryAccess(thread, obj, offset).get_mutex(); You could internalize the supports_cx8 check and the use of locking inside MemoryAccess.get_volatile rather than having get_volatile and get_mutex. If you prefer to keep it this way then get_volatile_with_mutex would be a more appropriate name (and it doesn't need to be a template method as I said before). Can't comment on the rest of the compiler related stuff too much, but I didn't see anything obviously odd looking. Thanks, David > > Incremental from webrev.01: > > jdk: N/A (no changes) > hotspot: > http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02.incr/hotspot/webrev/ > > > Cheers, > Mikael > >> >> Thanks, >> -Aleksey >> >> > From goetz.lindenmaier at sap.com Wed May 4 07:20:59 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 May 2016 07:20:59 +0000 Subject: RFR(XS): 8155738: C2: fix frame_complete_offset In-Reply-To: <5e42f9f6-fbba-d0f7-d455-64c21bea83a8@oracle.com> References: <2768884fbe2647e3a2e6b82da36b4fe6@DEWDFE13DE09.global.corp.sap> <5b697841-5471-cee3-7136-7a334ee2ca25@oracle.com> <024e9813be3d43d2b2cce187eedcbbf8@DEWDFE13DE09.global.corp.sap> <5e42f9f6-fbba-d0f7-d455-64c21bea83a8@oracle.com> Message-ID: Hi Dean, thanks a lot for sponsoring! Best regards, Goetz. > -----Original Message----- > From: Dean Long [mailto:dean.long at oracle.com] > Sent: Montag, 2. Mai 2016 23:06 > To: Lindenmaier, Goetz ; Vladimir Kozlov > ; hotspot compiler dev at openjdk.java.net> > Subject: Re: RFR(XS): 8155738: C2: fix frame_complete_offset > > Sure. > > dl > > > On 5/2/2016 1:37 AM, Lindenmaier, Goetz wrote: > > Thanks, Dean, > > > > could you please sponsor this change? > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Dean Long [mailto:dean.long at oracle.com] > >> Sent: Freitag, 29. April 2016 22:51 > >> To: Vladimir Kozlov ; Lindenmaier, Goetz > >> ; hotspot compiler >> dev at openjdk.java.net> > >> Subject: Re: RFR(XS): 8155738: C2: fix frame_complete_offset > >> > >> Looks good. I will closed JDK-8008415 as a duplicate! > >> > >> dl > >> > >> > >> On 4/29/2016 9:55 AM, Vladimir Kozlov wrote: > >>> "In the debug build the call at output.cpp:1831 build if > >>> (n->size(_regalloc) < (current_offset-instr_offset)) overwrites the > >>> proper value." > >>> > >>> So the fix is to not reset frame_complete_offset > >>> (Compile::_code_offsets._values[Frame_Complete]) when node is > >> emitted > >>> into scratch buffer. > >>> > >>> Changes looks good. > >>> > >>> Thanks, > >>> Vladimir > >>> > >>> On 4/29/16 7:09 AM, Lindenmaier, Goetz wrote: > >>>> Hi, > >>>> > >>>> > >>>> > >>>> In C2, frame_complete_offset is set wrong. It's also called during > >>>> scratch_emit_size, > >>>> > >>>> which happens at least in the debug build. > >>>> > >>>> I also added the missing call on ppc. > >>>> > >>>> > >>>> > >>>> Please review this small fix. I please need a sponsor: > >>>> > >>>> http://cr.openjdk.java.net/~goetz/wr16/8155738- > >> frameCmplt/webrev.00/ > >>>> > >>>> > >>>> Thanks and best regards, > >>>> > >>>> Goetz. > >>>> From rwestrel at redhat.com Wed May 4 07:30:29 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 4 May 2016 09:30:29 +0200 Subject: RFR(XS): 8155717: Aarch64: enable loop superword's unrolling analysis In-Reply-To: <5caad142-53f6-ed36-ac4e-e006c441bdc4@oracle.com> References: <5723201E.5080909@redhat.com> <572320F7.9030608@redhat.com> <57232234.7020504@redhat.com> <5caad142-53f6-ed36-ac4e-e006c441bdc4@oracle.com> Message-ID: <5729A515.2060204@redhat.com> Thanks for the review, Vladimir. Roland. On 04/29/2016 06:09 PM, Vladimir Kozlov wrote: > Changes looks good. I will run tests with it and will sponsor. > > Thanks, > Vladimir > > > On 4/29/16 1:58 AM, Roland Westrelin wrote: >> >>> OK, cool. Will Michael sponsor this, then? >> >> Thanks for reviewing it. I don't think Michael has that power. >> >> Roland. >> From rwestrel at redhat.com Wed May 4 07:36:34 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 4 May 2016 09:36:34 +0200 Subject: RFR(S): 8154943: AArch64: redundant address computation instructions with vectorization In-Reply-To: <71b64964-0682-2deb-c0d4-0102d7a8a939@oracle.com> References: <572267D5.8020605@oracle.com> <57238278.5030607@redhat.com> <71b64964-0682-2deb-c0d4-0102d7a8a939@oracle.com> Message-ID: <5729A682.4030407@redhat.com> Thanks for the review, Vladimir. Can someone sponsor this? Here is a changeset ready to be imported: http://cr.openjdk.java.net/~roland/8154943/8154943.patch Roland. On 04/29/2016 06:06 PM, Vladimir Kozlov wrote: > Yes, this looks good. > > Thanks, > Vladimir > > On 4/29/16 8:49 AM, Roland Westrelin wrote: >>> node.cpp change is good. >>> >>> compile.cpp I understand when you replace "similar" (same in(1)) node >>> with it but it is not clear that you also processing users (whole >>> following chain) to remove similar nodes. Add comment. >>> I think the check "!(k->Opcode() == Op_ConvI2L || ... " (and use >>> 'continue' instead of 'break') should be done when you push a node on >>> the list wq.push(u). >> >> Thanks for the review, Vladimir. What about this? >> >> http://cr.openjdk.java.net/~roland/8154943/webrev.01/ >> >> Roland. >> From rwestrel at redhat.com Wed May 4 07:38:01 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 4 May 2016 09:38:01 +0200 Subject: RFR(M): 8154826: AArch64: take better advantage of base + shifted offset addressing mode In-Reply-To: <571E20BD.3030907@redhat.com> References: <57188E03.5070303@redhat.com> <571E20BD.3030907@redhat.com> Message-ID: <5729A6D9.3010606@redhat.com> Anyone for a review of this? It's aarch64 specific but has some shared code changes. Roland. On 04/25/2016 03:50 PM, Roland Westrelin wrote: > > > On 04/21/2016 10:23 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8154826/webrev.00/ >> >> The aarch64 port implicitly transforms: >> (AddP base (AddP base address (LShiftL index con)) offset) >> into: >> (AddP base (AddP base offset) (LShiftL index con)) >> in the ad file to embed the shift (and possibly and i2l conversion) into >> the addressing mode of a memory operation. Exposing that transformation >> in the ideal graph allows: >> >> - (AddP base offset) to be scheduled (for instance outside a loop) >> - multiple identical (AddP base offset) to be commoned >> - (LShiftL index con) to be cloned during matching so that each memory >> access has its own > > Further testing revealed some problems with the previous change so here > is a new webrev: > > http://cr.openjdk.java.net/~roland/8154826/webrev.01/ > > Memory access instructions only accept a shift that matches the size of > the data being accessed (i.e. 2 for a 4 byte load). It's not always the > case that address expressions produced by c2 follow that constraint. As > expected, tt's very rare that it doesn't and seem to occur only with > unsafe. I added a predicate that skips the transformation of the address > subtree at the end of the optimization passes and prevent matching of > the address subtree if the constraint is not met for one use. As this is > uncommon, that seems good enough. > > Roland. > From vladimir.x.ivanov at oracle.com Wed May 4 08:27:11 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 4 May 2016 11:27:11 +0300 Subject: RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures In-Reply-To: <5723DC4D.8090507@oracle.com> References: <5723DC4D.8090507@oracle.com> Message-ID: <5729B25F.20209@oracle.com> Looks good. Best regards, Vladimir Ivanov On 4/30/16 1:12 AM, Aleksey Shipilev wrote: > Hi, > > I would like to fix a simple testbug in our weakCompareAndSet VarHandles > and Unsafe intrinsics tests. weakCompareAndSet is spec-ed to allow > spurious failures, but current tests do not allow that. This blocks > development and testing on non-x86 platforms. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8155739 > > Webrevs: > http://cr.openjdk.java.net/~shade/8155739/webrev.hs.00/ > http://cr.openjdk.java.net/~shade/8155739/webrev.jdk.00/ > > The tests are auto-generated, and the substantiative changes are in > *.template files. I also removed obsolete generate-unsafe-tests.sh. I > would like to push through hs-comp to expose this to Power and AArch64 > folks early. > > Testing: x86_64, jdk:java/lang/invoke/VarHandle, hotspot:compiler/unsafe > > Thanks, > -Aleksey > From aph at redhat.com Wed May 4 08:29:58 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 4 May 2016 09:29:58 +0100 Subject: RFR(M): 8154826: AArch64: take better advantage of base + shifted offset addressing mode In-Reply-To: <5729A6D9.3010606@redhat.com> References: <57188E03.5070303@redhat.com> <571E20BD.3030907@redhat.com> <5729A6D9.3010606@redhat.com> Message-ID: <5729B306.4010405@redhat.com> On 04/05/16 08:38, Roland Westrelin wrote: > Anyone for a review of this? It's aarch64 specific but has some shared > code changes. It looks great to me, but I need another reviewer with knowledge of C2 internals. Andrew. From martin.doerr at sap.com Wed May 4 09:03:10 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 4 May 2016 09:03:10 +0000 Subject: RFR(M): 8141635: Implement new Unsafe intrinsics on POWER In-Reply-To: <5728FBA5.2010808@oracle.com> References: <075bd830305c426996ef758e0a37ed87@DEWDFE13DE14.global.corp.sap> <5728FBA5.2010808@oracle.com> Message-ID: Hi Aleksey, thank you for reviewing my change. Here my answers: > Actually, that seems to mean current CAS implementation on POWER, prior > to VarHandles, was also broken. Good catch! We do have?a MemBarVolatile before CAS in the SAP JVM but somehow forgot to integrate it into OpenJDK :) > I wonder, however, why you need sync() after CAS? The sync is only for the case !support_IRIW_for_not_multiple_copy_atomic_cpu. So it's not used. With support_IRIW_for_not_multiple_copy_atomic_cpu: volatile load: sync+ld+acquire by isync volatile store: lwsync+st volatile CAS: sync+ld+st+isync Without support_IRIW_for_not_multiple_copy_atomic_cpu: volatile load: ld+acquire by isync volatile store: lwsync+st+sync volatile CAS: lwsync+ld+st+sync > Therefore isync() is enough after CAS in ppc.ad? Also, why not fix the > CAS in MacroAssembler with these barriers to match C++11 mappings, > instead of doing special cases in .ad? support_IRIW_for_not_multiple_copy_atomic_cpu is true on PPC64, so we already use isync after CAS with my current version of the change. I don't want to change the CAS implementation in MacroAssembler as it is also used for monitor locking etc. which is unrelated to this change. > I don't think this is about the returned value, but rather about the > transitive memory effects. So, I would post the barrier on the exit path > for weakCAS{Acquire,Release} too. Please note that we do execute the memory barrier before the CAS in both, the failed and the successful case. In the failed case, the failure reason may be a reservation loss due to an interrupt. It is not specified which value was loaded, so the CAS did not perform any memory access which is observable in Java. So what should be ordered by an additional memory barrier in this case? What is your concern about transitive memory effects? After the weak CAS (maybe after several retries) succeeds, we execute the memory barrier of course. > P.S. Note that we have weakCompareAndSetVolatile intrinsics in works, > which would probably require a few additional matches in .ad... Thanks for the heads-up. I think my change is ready for it. Best regards, Martin -----Original Message----- From: Aleksey Shipilev [mailto:aleksey.shipilev at oracle.com] Sent: Dienstag, 3. Mai 2016 21:28 To: Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(M): 8141635: Implement new Unsafe intrinsics on POWER * PGP Signature not checked Hi Martin, On 05/03/2016 01:16 PM, Doerr, Martin wrote: > According to JEP 193, Compare and Swap/Exchange methods need to behave > like volatile load + volatile store. > > Therefore, I had to make a change to the shared library_call > implementation (support_IRIW_for_not_multiple_copy_atomic_cpu was not > yet included). Yes, CAS/CAE are supposed to be sequentially consistent. This change looks correct, if a hardware CAS is not SC: 2852 switch (access_kind) { ... 2856 case Release: 2857 insert_mem_bar(Op_MemBarRelease); 2858 break; 2859 case Volatile: 2860 if (support_IRIW_for_not_multiple_copy_atomic_cpu) { 2861 insert_mem_bar(Op_MemBarVolatile); 2862 } else { 2863 insert_mem_bar(Op_MemBarRelease); 2864 } 2865 break; Actually, that seems to mean current CAS implementation on POWER, prior to VarHandles, was also broken. > I also assert that GetAndAdd and GetAndSet are only used with seq_cst > semantics, because the memory order is not passed to these intrinsics. Yes, good. > C++2011 supports specifying weaker semantics for failed cases of > atomic_compare_exchange than for successful ones. > > As I understand JEP 193, Java expects the semantics for failed cases to > be the same as for successful cases. > > That means the memory barrier instruction must be executed even though > the store was not executed. So the failed Compare and Swap/Exchange > behaves like a volatile load. Yes, that's the difference between VarHandles and C++11 semantics. VarHandles provide a single memory ordering, regardless of success/failure. I wonder, however, why you need sync() after CAS? C++11 mappings on POWER: https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html ...say that Cmpxchg SeqCst is: hwsync; // Op_MemBarVolatile _loop: lwarx; cmp; bc _exit; stwcx.; bc _loop; isync; _exit: Load Seq Cst, which is similar to failing CAS semantics, is: hwsync; ld; cmp; bc; isync Therefore isync() is enough after CAS in ppc.ad? Also, why not fix the CAS in MacroAssembler with these barriers to match C++11 mappings, instead of doing special cases in .ad? > They do not return the loaded value, but only report whether the Swap > was performed or not. The failure cause is not clearly identifiable and > I don't see any purpose of executing a memory barrier in case of failure. I don't think this is about the returned value, but rather about the transitive memory effects. So, I would post the barrier on the exit path for weakCAS{Acquire,Release} too. Thanks, -Aleksey P.S. Note that we have weakCompareAndSetVolatile intrinsics in works, which would probably require a few additional matches in .ad... https://bugs.openjdk.java.net/browse/JDK-8155965 * Signature checking is off by policy From roland.schatz at oracle.com Wed May 4 13:48:41 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Wed, 4 May 2016 15:48:41 +0200 Subject: RFR(S): 8156025: [JVMCI] make HotSpotResolvedObjectTypeImpl.createField non-public Message-ID: <5729FDB9.2080205@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~rschatz/JDK-8156025/webrev.00/hotspot.changeset https://bugs.openjdk.java.net/browse/JDK-8156025 This method is used only internally, it should never have been public. Thanks, Roland From volker.simonis at gmail.com Wed May 4 17:57:28 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 4 May 2016 19:57:28 +0200 Subject: RFR(M): 8141635: Implement new Unsafe intrinsics on POWER In-Reply-To: References: <075bd830305c426996ef758e0a37ed87@DEWDFE13DE14.global.corp.sap> <5728FBA5.2010808@oracle.com> Message-ID: Hi Martin, thanks for the explanation. I think the change looks good. Aleksey, could you please run the change through JPRT and sponsor it once your happy with it? Regards, Volker On Wed, May 4, 2016 at 11:03 AM, Doerr, Martin wrote: > Hi Aleksey, > > thank you for reviewing my change. Here my answers: > >> Actually, that seems to mean current CAS implementation on POWER, prior >> to VarHandles, was also broken. > Good catch! We do have a MemBarVolatile before CAS in the SAP JVM but somehow forgot to integrate it into OpenJDK :) > >> I wonder, however, why you need sync() after CAS? > The sync is only for the case !support_IRIW_for_not_multiple_copy_atomic_cpu. So it's not used. > > With support_IRIW_for_not_multiple_copy_atomic_cpu: > volatile load: sync+ld+acquire by isync > volatile store: lwsync+st > volatile CAS: sync+ld+st+isync > > Without support_IRIW_for_not_multiple_copy_atomic_cpu: > volatile load: ld+acquire by isync > volatile store: lwsync+st+sync > volatile CAS: lwsync+ld+st+sync > >> Therefore isync() is enough after CAS in ppc.ad? Also, why not fix the >> CAS in MacroAssembler with these barriers to match C++11 mappings, >> instead of doing special cases in .ad? > support_IRIW_for_not_multiple_copy_atomic_cpu is true on PPC64, so we already use isync after CAS with my current version of the change. > I don't want to change the CAS implementation in MacroAssembler as it is also used for monitor locking etc. which is unrelated to this change. > >> I don't think this is about the returned value, but rather about the >> transitive memory effects. So, I would post the barrier on the exit path >> for weakCAS{Acquire,Release} too. > Please note that we do execute the memory barrier before the CAS in both, the failed and the successful case. > In the failed case, the failure reason may be a reservation loss due to an interrupt. It is not specified which value was loaded, > so the CAS did not perform any memory access which is observable in Java. So what should be ordered by an additional memory barrier in this case? > What is your concern about transitive memory effects? > > After the weak CAS (maybe after several retries) succeeds, we execute the memory barrier of course. > >> P.S. Note that we have weakCompareAndSetVolatile intrinsics in works, >> which would probably require a few additional matches in .ad... > Thanks for the heads-up. I think my change is ready for it. > > Best regards, > Martin > > > -----Original Message----- > From: Aleksey Shipilev [mailto:aleksey.shipilev at oracle.com] > Sent: Dienstag, 3. Mai 2016 21:28 > To: Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(M): 8141635: Implement new Unsafe intrinsics on POWER > > * PGP Signature not checked > > Hi Martin, > > On 05/03/2016 01:16 PM, Doerr, Martin wrote: >> According to JEP 193, Compare and Swap/Exchange methods need to behave >> like volatile load + volatile store. >> >> Therefore, I had to make a change to the shared library_call >> implementation (support_IRIW_for_not_multiple_copy_atomic_cpu was not >> yet included). > > Yes, CAS/CAE are supposed to be sequentially consistent. This change > looks correct, if a hardware CAS is not SC: > > 2852 switch (access_kind) { > ... > 2856 case Release: > 2857 insert_mem_bar(Op_MemBarRelease); > 2858 break; > 2859 case Volatile: > 2860 if (support_IRIW_for_not_multiple_copy_atomic_cpu) { > 2861 insert_mem_bar(Op_MemBarVolatile); > 2862 } else { > 2863 insert_mem_bar(Op_MemBarRelease); > 2864 } > 2865 break; > > Actually, that seems to mean current CAS implementation on POWER, prior > to VarHandles, was also broken. > >> I also assert that GetAndAdd and GetAndSet are only used with seq_cst >> semantics, because the memory order is not passed to these intrinsics. > > Yes, good. > >> C++2011 supports specifying weaker semantics for failed cases of >> atomic_compare_exchange than for successful ones. >> >> As I understand JEP 193, Java expects the semantics for failed cases to >> be the same as for successful cases. >> >> That means the memory barrier instruction must be executed even though >> the store was not executed. So the failed Compare and Swap/Exchange >> behaves like a volatile load. > > Yes, that's the difference between VarHandles and C++11 semantics. > VarHandles provide a single memory ordering, regardless of success/failure. > > I wonder, however, why you need sync() after CAS? C++11 mappings on > POWER: https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html ...say > that Cmpxchg SeqCst is: > > hwsync; // Op_MemBarVolatile > _loop: lwarx; > cmp; > bc _exit; > stwcx.; > bc _loop; > isync; > _exit: > > Load Seq Cst, which is similar to failing CAS semantics, is: > > hwsync; > ld; > cmp; > bc; > isync > > Therefore isync() is enough after CAS in ppc.ad? Also, why not fix the > CAS in MacroAssembler with these barriers to match C++11 mappings, > instead of doing special cases in .ad? > >> They do not return the loaded value, but only report whether the Swap >> was performed or not. The failure cause is not clearly identifiable and >> I don't see any purpose of executing a memory barrier in case of failure. > > I don't think this is about the returned value, but rather about the > transitive memory effects. So, I would post the barrier on the exit path > for weakCAS{Acquire,Release} too. > > Thanks, > -Aleksey > > P.S. Note that we have weakCompareAndSetVolatile intrinsics in works, > which would probably require a few additional matches in .ad... > https://bugs.openjdk.java.net/browse/JDK-8155965 > > > * Signature checking is off by policy From christian.thalinger at oracle.com Wed May 4 19:13:55 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 4 May 2016 09:13:55 -1000 Subject: RFR: 8155023: jdk.vm.ci needs to securely export services In-Reply-To: References: Message-ID: <8E8E749B-9DFF-43C5-BEE4-EAC6662C3729@oracle.com> > On May 3, 2016, at 3:34 AM, Doug Simon wrote: > > https://bugs.openjdk.java.net/browse/JDK-8155023 > http://cr.openjdk.java.net/~dnsimon/8155023/ src/jdk.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. Why did you remove 2014? src/jdk.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java + /** * Gets an {@link Iterable} of the JVMCI providers available for a given service. + + * @throws SecurityException if a security manager is present and it denies + * {@code RuntimePermission("jvmci")} */ public static Iterable load(Class service) { + Module jvmci = Services.class.getModule(); + jvmci.addUses(service); return ServiceLoader.load(service); } Where is the SecurityException thrown? Also, there is a ?*? missing in the JavaDoc. src/jdk.vm.ci/share/classes/module-info.java + // 8153756 + requires jdk.unsupported; Why is this back? > > -Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Wed May 4 19:18:21 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 4 May 2016 09:18:21 -1000 Subject: Intrinsic interactions with Deoptimization In-Reply-To: <5728C5E2.3010708@oracle.com> References: <5728C5E2.3010708@oracle.com> Message-ID: > On May 3, 2016, at 5:38 AM, Ahmed Khawaja wrote: > > Greetings, > > I am working on a C2 intrinsic and I have a question concerning deoptimization. The calling method is being deoptimized after a certain point with the cause being unstable branches. While I understand that the calling method should be reprofiled/recompiled, it was my understanding that after an intrinsic was triggered, any calls to it (the intrinsified function) would always result in the intrinsic code running. What I am seeing is when the parent/calling method falls back to interpreter mode to re-profile, the intrinsic code is no longer being called and the Java implementation of the (called) method is being used. Can someone shine some light on the interaction between intrinsics and deoptimization? My hypothesis is that the intrinsic code that was generated is still there, but some glue code was flushed during deoptimization. The desired behavior I am pursuing is that once the method triggers intrinsification, the intrinsic should always be used. Is falling back to interpretation an all or nothing type behavior? Intrinsification is replacing a well-known Java method with some compiler IR in the compilation unit. There is no ?intrinsified function? since it never was a separate compilation unit. Once the compiled method is deoptimized you certainly fall back to the interpreter and whatever the Java byte code is you are executing. Maybe you are mixing up intrinsics and stubs? What are you working on? > > Thank you, > Ahmed Khawaja From christian.thalinger at oracle.com Wed May 4 19:20:45 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 4 May 2016 09:20:45 -1000 Subject: RFR(S): 8156025: [JVMCI] make HotSpotResolvedObjectTypeImpl.createField non-public In-Reply-To: <5729FDB9.2080205@oracle.com> References: <5729FDB9.2080205@oracle.com> Message-ID: > On May 4, 2016, at 3:48 AM, Roland Schatz wrote: > > Hi, > > Please review: > http://cr.openjdk.java.net/~rschatz/JDK-8156025/webrev.00/hotspot.changeset > https://bugs.openjdk.java.net/browse/JDK-8156025 > > This method is used only internally, it should never have been public. Looks good. All JVMCI tests pass? > > Thanks, > Roland From christian.thalinger at oracle.com Wed May 4 19:50:52 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 4 May 2016 09:50:52 -1000 Subject: RFR: 8155571: [JVMCI] split jdk.vm.ci module into jdk.vm.ci and jdk.vm.ci.hotspot Message-ID: <095B0BC3-D020-4F86-93EC-D483C0853790@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8155571 http://cr.openjdk.java.net/~twisti/8155571/webrev.01/ Read the JIRA entry why we need this change. Most changes are moving files around and fixing up tests. Top-level changes: diff -r e51a92f0f1ac make/CompileJavaModules.gmk --- a/make/CompileJavaModules.gmk Tue Apr 19 15:26:51 2016 -0400 +++ b/make/CompileJavaModules.gmk Wed May 04 09:45:13 2016 -1000 @@ -483,11 +483,11 @@ MODULESOURCEPATH := $(call GetModuleSrcP # Add imported modules to the modulepath MODULEPATH := $(call PathList, $(IMPORT_MODULES_CLASSES)) -ifeq ($(MODULE), jdk.vm.ci) - ## WORKAROUND jdk.vm.ci source structure issue +## WORKAROUND jdk.vm.ci source structure +ifneq ($(filter $(MODULE), jdk.vm.ci jdk.vm.ci.hotspot), ) JVMCI_MODULESOURCEPATH := $(MODULESOURCEPATH) \ - $(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \ - $(wildcard $(HOTSPOT_TOPDIR)/src/jdk.vm.ci/share/classes/*/src))) + $(subst src/$(MODULE)/,src/*/, $(filter-out %processor/src, \ + $(wildcard $(HOTSPOT_TOPDIR)/src/$(MODULE)/share/classes/*/src))) MODULESOURCEPATH := $(call PathList, $(JVMCI_MODULESOURCEPATH)) endif diff -r e51a92f0f1ac make/common/Modules.gmk --- a/make/common/Modules.gmk Tue Apr 19 15:26:51 2016 -0400 +++ b/make/common/Modules.gmk Wed May 04 09:45:13 2016 -1000 @@ -68,6 +68,7 @@ BOOT_MODULES += \ jdk.security.jgss \ jdk.unsupported \ jdk.vm.ci \ + jdk.vm.ci.hotspot \ # # to be deprivileged jdk/ changes: diff -r 909f38c3d339 src/java.base/share/classes/module-info.java --- a/src/java.base/share/classes/module-info.java Wed May 04 17:17:28 2016 +0300 +++ b/src/java.base/share/classes/module-info.java Wed May 04 09:46:02 2016 -1000 @@ -138,7 +138,7 @@ module java.base { exports jdk.internal.org.objectweb.asm to jdk.jlink, jdk.scripting.nashorn, - jdk.vm.ci; + jdk.vm.ci.hotspot; exports jdk.internal.org.objectweb.asm.tree to jdk.jlink; exports jdk.internal.org.objectweb.asm.util to @@ -173,7 +173,8 @@ module java.base { jdk.charsets, jdk.scripting.nashorn, jdk.unsupported, - jdk.vm.ci; + jdk.vm.ci, + jdk.vm.ci.hotspot; exports jdk.internal.perf to java.desktop, java.management, -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed May 4 20:21:19 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 4 May 2016 13:21:19 -0700 Subject: RFR: 8155571: [JVMCI] split jdk.vm.ci module into jdk.vm.ci and jdk.vm.ci.hotspot In-Reply-To: <095B0BC3-D020-4F86-93EC-D483C0853790@oracle.com> References: <095B0BC3-D020-4F86-93EC-D483C0853790@oracle.com> Message-ID: <572A59BF.5060508@oracle.com> Looks good. Thanks, Vladimir On 5/4/16 12:50 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8155571 > http://cr.openjdk.java.net/~twisti/8155571/webrev.01/ > > Read the JIRA entry why we need this change. Most changes are moving > files around and fixing up tests. > > Top-level changes: > > diff -r e51a92f0f1ac make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmkTue Apr 19 15:26:51 2016 -0400 > +++ b/make/CompileJavaModules.gmkWed May 04 09:45:13 2016 -1000 > @@ -483,11 +483,11 @@ MODULESOURCEPATH := $(call GetModuleSrcP > # Add imported modules to the modulepath > MODULEPATH := $(call PathList, $(IMPORT_MODULES_CLASSES)) > > > -ifeq ($(MODULE), jdk.vm.ci) > - ## WORKAROUND jdk.vm.ci source structure issue > +## WORKAROUND jdk.vm.ci source structure > +ifneq ($(filter $(MODULE), jdk.vm.ci jdk.vm.ci.hotspot), ) > JVMCI_MODULESOURCEPATH := $(MODULESOURCEPATH) \ > - $(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \ > - $(wildcard $(HOTSPOT_TOPDIR)/src/jdk.vm.ci/share/classes/*/src))) > + $(subst src/$(MODULE)/,src/*/, $(filter-out %processor/src, \ > + $(wildcard $(HOTSPOT_TOPDIR)/src/$(MODULE)/share/classes/*/src))) > MODULESOURCEPATH := $(call PathList, $(JVMCI_MODULESOURCEPATH)) > endif > > > diff -r e51a92f0f1ac make/common/Modules.gmk > --- a/make/common/Modules.gmkTue Apr 19 15:26:51 2016 -0400 > +++ b/make/common/Modules.gmkWed May 04 09:45:13 2016 -1000 > @@ -68,6 +68,7 @@ BOOT_MODULES += \ > jdk.security.jgss \ > jdk.unsupported \ > jdk.vm.ci \ > + jdk.vm.ci.hotspot \ > # > > > # to be deprivileged > > > jdk/ changes: > > diff -r 909f38c3d339 src/java.base/share/classes/module-info.java > --- a/src/java.base/share/classes/module-info.javaWed May 04 17:17:28 > 2016 +0300 > +++ b/src/java.base/share/classes/module-info.javaWed May 04 09:46:02 > 2016 -1000 > @@ -138,7 +138,7 @@ module java.base { > exports jdk.internal.org.objectweb.asm to > jdk.jlink, > jdk.scripting.nashorn, > - jdk.vm.ci; > + jdk.vm.ci.hotspot; > exports jdk.internal.org.objectweb.asm.tree to > jdk.jlink; > exports jdk.internal.org.objectweb.asm.util to > @@ -173,7 +173,8 @@ module java.base { > jdk.charsets, > jdk.scripting.nashorn, > jdk.unsupported, > - jdk.vm.ci; > + jdk.vm.ci, > + jdk.vm.ci.hotspot; > exports jdk.internal.perf to > java.desktop, > java.management, > From christian.thalinger at oracle.com Wed May 4 20:25:04 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 4 May 2016 10:25:04 -1000 Subject: RFR: 8155571: [JVMCI] split jdk.vm.ci module into jdk.vm.ci and jdk.vm.ci.hotspot In-Reply-To: <572A59BF.5060508@oracle.com> References: <095B0BC3-D020-4F86-93EC-D483C0853790@oracle.com> <572A59BF.5060508@oracle.com> Message-ID: <2570BA6B-0BCE-4E18-9BFA-3D5FC4ABF3D5@oracle.com> Thanks, Vladimir. > On May 4, 2016, at 10:21 AM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 5/4/16 12:50 PM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8155571 >> http://cr.openjdk.java.net/~twisti/8155571/webrev.01/ >> >> Read the JIRA entry why we need this change. Most changes are moving >> files around and fixing up tests. >> >> Top-level changes: >> >> diff -r e51a92f0f1ac make/CompileJavaModules.gmk >> --- a/make/CompileJavaModules.gmkTue Apr 19 15:26:51 2016 -0400 >> +++ b/make/CompileJavaModules.gmkWed May 04 09:45:13 2016 -1000 >> @@ -483,11 +483,11 @@ MODULESOURCEPATH := $(call GetModuleSrcP >> # Add imported modules to the modulepath >> MODULEPATH := $(call PathList, $(IMPORT_MODULES_CLASSES)) >> >> >> -ifeq ($(MODULE), jdk.vm.ci) >> - ## WORKAROUND jdk.vm.ci source structure issue >> +## WORKAROUND jdk.vm.ci source structure >> +ifneq ($(filter $(MODULE), jdk.vm.ci jdk.vm.ci.hotspot), ) >> JVMCI_MODULESOURCEPATH := $(MODULESOURCEPATH) \ >> - $(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \ >> - $(wildcard $(HOTSPOT_TOPDIR)/src/jdk.vm.ci/share/classes/*/src))) >> + $(subst src/$(MODULE)/,src/*/, $(filter-out %processor/src, \ >> + $(wildcard $(HOTSPOT_TOPDIR)/src/$(MODULE)/share/classes/*/src))) >> MODULESOURCEPATH := $(call PathList, $(JVMCI_MODULESOURCEPATH)) >> endif >> >> >> diff -r e51a92f0f1ac make/common/Modules.gmk >> --- a/make/common/Modules.gmkTue Apr 19 15:26:51 2016 -0400 >> +++ b/make/common/Modules.gmkWed May 04 09:45:13 2016 -1000 >> @@ -68,6 +68,7 @@ BOOT_MODULES += \ >> jdk.security.jgss \ >> jdk.unsupported \ >> jdk.vm.ci \ >> + jdk.vm.ci.hotspot \ >> # >> >> >> # to be deprivileged >> >> >> jdk/ changes: >> >> diff -r 909f38c3d339 src/java.base/share/classes/module-info.java >> --- a/src/java.base/share/classes/module-info.javaWed May 04 17:17:28 >> 2016 +0300 >> +++ b/src/java.base/share/classes/module-info.javaWed May 04 09:46:02 >> 2016 -1000 >> @@ -138,7 +138,7 @@ module java.base { >> exports jdk.internal.org.objectweb.asm to >> jdk.jlink, >> jdk.scripting.nashorn, >> - jdk.vm.ci; >> + jdk.vm.ci.hotspot; >> exports jdk.internal.org.objectweb.asm.tree to >> jdk.jlink; >> exports jdk.internal.org.objectweb.asm.util to >> @@ -173,7 +173,8 @@ module java.base { >> jdk.charsets, >> jdk.scripting.nashorn, >> jdk.unsupported, >> - jdk.vm.ci; >> + jdk.vm.ci, >> + jdk.vm.ci.hotspot; >> exports jdk.internal.perf to >> java.desktop, >> java.management, >> From doug.simon at oracle.com Wed May 4 21:11:42 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 4 May 2016 23:11:42 +0200 Subject: RFR: 8155023: jdk.vm.ci needs to securely export services In-Reply-To: <8E8E749B-9DFF-43C5-BEE4-EAC6662C3729@oracle.com> References: <8E8E749B-9DFF-43C5-BEE4-EAC6662C3729@oracle.com> Message-ID: <0F42335F-F9A7-4220-A6DB-547BBFE051B9@oracle.com> > On 04 May 2016, at 21:13, Christian Thalinger wrote: > > >> On May 3, 2016, at 3:34 AM, Doug Simon wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8155023 >> http://cr.openjdk.java.net/~dnsimon/8155023/ > src/jdk.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java > > - * Copyright (c) 2014, 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > Why did you remove 2014? Oversight - I restored it. > > src/jdk.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java > > + /** > > * Gets an {@link Iterable} of the JVMCI providers available for a given service. > > + > + * @throws SecurityException if a security manager is present and it denies > + * {@code RuntimePermission("jvmci")} > > */ > public static Iterable load(Class service) { > > + Module jvmci = Services.class.getModule(); > + jvmci.addUses(service); > > return ServiceLoader.load(service); > } > > Where is the SecurityException thrown? Also, there is a ?*? missing in the JavaDoc. Security checks got lost in refactoring - restored. Missing ?*? added. > > src/jdk.vm.ci/share/classes/module-info.java > > + // 8153756 > + requires jdk.unsupported; > Why is this back? Merge error. Fixed. Thanks for catching these issues. I?ve updated the webrev in situ. I also noticed that I removed --with-native-debug-symbols in the configure command issued in .mx_jvmci/mx_jvmci.py where as I meant to change it to --with-native-debug-symbols=external. I also fixed that in situ. -Doug From vladimir.kozlov at oracle.com Wed May 4 22:39:36 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 4 May 2016 15:39:36 -0700 Subject: RFR 8151268: Wire up the x86 _vectorizedMismatch stub routine in C1 In-Reply-To: References: Message-ID: <572A7A28.9000506@oracle.com> Hi Paul, Changes looks good. Thanks, Vladimir On 5/3/16 5:25 PM, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151268-int-c1-mismatch/webrev/ > > This webrev wires up the array mismatch stub to C1. (Previously i also > wired this up to the interpreter but pulled that part out based on > feedback, although i have left some updates in the comments). > > JPRT testsets core and hotspot pass. > > Paul. From vladimir.kozlov at oracle.com Wed May 4 22:58:01 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 4 May 2016 15:58:01 -0700 Subject: RFR (M): 8154974: AVX-512 equipped inflate, has_negatives & compress intrinsics In-Reply-To: <3616187E21868C40AD1B36D41D29F4C1520B04B1@FMSMSX106.amr.corp.intel.com> References: <3616187E21868C40AD1B36D41D29F4C1520B04B1@FMSMSX106.amr.corp.intel.com> Message-ID: <572A7E79.6070401@oracle.com> Looks good. What testing was done? Thanks, Vladimir On 4/29/16 4:57 PM, Wojtowicz, Tomasz wrote: > I would like to contribute following change: > > Review details > > Review Title: AVX-512 equipped inflate, has_negatives & compress > intrinsics > > Review ID: #8154974 > > Diff: http://cr.openjdk.java.net/~vdeshpande/8154974/webrev.00/ > > Description: 512 bit wide upgrades for previously 128-256 wide > implementations using mask registers for tail computations. > > Link: https://bugs.openjdk.java.net/browse/JDK-8154974 > > Author: Tomasz, Wojtowicz > > -- > > Thank you, > > Tomek > From vladimir.kozlov at oracle.com Wed May 4 23:10:18 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 4 May 2016 16:10:18 -0700 Subject: RFR (M): 8154974: AVX-512 equipped inflate, has_negatives & compress intrinsics In-Reply-To: <572A7E79.6070401@oracle.com> References: <3616187E21868C40AD1B36D41D29F4C1520B04B1@FMSMSX106.amr.corp.intel.com> <572A7E79.6070401@oracle.com> Message-ID: <572A815A.7040808@oracle.com> I can't apply changes to latest hs-comp/hotspot. Please, update. Vladimir On 5/4/16 3:58 PM, Vladimir Kozlov wrote: > Looks good. What testing was done? > > Thanks, > Vladimir > > On 4/29/16 4:57 PM, Wojtowicz, Tomasz wrote: >> I would like to contribute following change: >> >> Review details >> >> Review Title: AVX-512 equipped inflate, has_negatives & compress >> intrinsics >> >> Review ID: #8154974 >> >> Diff: http://cr.openjdk.java.net/~vdeshpande/8154974/webrev.00/ >> >> Description: 512 bit wide upgrades for previously 128-256 wide >> implementations using mask registers for tail computations. >> >> Link: https://bugs.openjdk.java.net/browse/JDK-8154974 >> >> Author: Tomasz, Wojtowicz >> >> -- >> >> Thank you, >> >> Tomek >> From tomasz.wojtowicz at intel.com Wed May 4 23:12:13 2016 From: tomasz.wojtowicz at intel.com (Wojtowicz, Tomasz) Date: Wed, 4 May 2016 23:12:13 +0000 Subject: RFR (M): 8154974: AVX-512 equipped inflate, has_negatives & compress intrinsics In-Reply-To: <572A7E79.6070401@oracle.com> References: <3616187E21868C40AD1B36D41D29F4C1520B04B1@FMSMSX106.amr.corp.intel.com> <572A7E79.6070401@oracle.com> Message-ID: <3616187E21868C40AD1B36D41D29F4C1520B12FC@FMSMSX106.amr.corp.intel.com> Internally developed ubenchmarks for performance & similar functional using Reflections API for those 3 intrinsics on an up to 4K chunks of pseudo random initialized data to verify correctness. Has_negatives had a negative sentinel as a last element in an array. Also tailored examples for compress which would test all of the possible entry scenarios (tail present/not present, non-compressable element found in head OR tail - to make sure that there is a coverage for all of the basic blocks inside intrinsic) Everything run at least 3 times for -XX:UseAVX=1 then 2 and 3, depending on a scenario for establishing performance baseline AND/OR correctness when "older"(AVX<=2) had been modified. -- Tomek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, May 4, 2016 3:58 PM To: Wojtowicz, Tomasz ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (M): 8154974: AVX-512 equipped inflate, has_negatives & compress intrinsics Looks good. What testing was done? Thanks, Vladimir On 4/29/16 4:57 PM, Wojtowicz, Tomasz wrote: > I would like to contribute following change: > > Review details > > Review Title: AVX-512 equipped inflate, has_negatives & compress > intrinsics > > Review ID: #8154974 > > Diff: http://cr.openjdk.java.net/~vdeshpande/8154974/webrev.00/ > > Description: 512 bit wide upgrades for previously 128-256 wide > implementations using mask registers for tail computations. > > Link: https://bugs.openjdk.java.net/browse/JDK-8154974 > > Author: Tomasz, Wojtowicz > > -- > > Thank you, > > Tomek > From vladimir.kozlov at oracle.com Wed May 4 23:27:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 4 May 2016 16:27:56 -0700 Subject: RFR (M): 8154974: AVX-512 equipped inflate, has_negatives & compress intrinsics In-Reply-To: <3616187E21868C40AD1B36D41D29F4C1520B12FC@FMSMSX106.amr.corp.intel.com> References: <3616187E21868C40AD1B36D41D29F4C1520B04B1@FMSMSX106.amr.corp.intel.com> <572A7E79.6070401@oracle.com> <3616187E21868C40AD1B36D41D29F4C1520B12FC@FMSMSX106.amr.corp.intel.com> Message-ID: <572A857C.3070904@oracle.com> Thanks, Tomek Please, add this as comment to JDK-8154974. Still need updated webrev. Thanks, Vladimir On 5/4/16 4:12 PM, Wojtowicz, Tomasz wrote: > Internally developed ubenchmarks for performance & similar functional using Reflections API for those 3 intrinsics on an up to 4K chunks of pseudo random initialized data to verify correctness. > Has_negatives had a negative sentinel as a last element in an array. > Also tailored examples for compress which would test all of the possible entry scenarios (tail present/not present, non-compressable element found in head OR tail - to make sure that there is a coverage for all of the basic blocks inside intrinsic) > > Everything run at least 3 times for -XX:UseAVX=1 then 2 and 3, depending on a scenario for establishing performance baseline AND/OR correctness when "older"(AVX<=2) had been modified. > > -- > Tomek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, May 4, 2016 3:58 PM > To: Wojtowicz, Tomasz ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (M): 8154974: AVX-512 equipped inflate, has_negatives & compress intrinsics > > Looks good. What testing was done? > > Thanks, > Vladimir > > On 4/29/16 4:57 PM, Wojtowicz, Tomasz wrote: >> I would like to contribute following change: >> >> Review details >> >> Review Title: AVX-512 equipped inflate, has_negatives & compress >> intrinsics >> >> Review ID: #8154974 >> >> Diff: http://cr.openjdk.java.net/~vdeshpande/8154974/webrev.00/ >> >> Description: 512 bit wide upgrades for previously 128-256 wide >> implementations using mask registers for tail computations. >> >> Link: https://bugs.openjdk.java.net/browse/JDK-8154974 >> >> Author: Tomasz, Wojtowicz >> >> -- >> >> Thank you, >> >> Tomek >> From doug.simon at oracle.com Wed May 4 23:43:31 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 5 May 2016 01:43:31 +0200 Subject: RFR: 8155571: [JVMCI] split jdk.vm.ci module into jdk.vm.ci and jdk.vm.ci.hotspot In-Reply-To: References: Message-ID: In light of the Services.exportJVMCITo method being proposed in http://cr.openjdk.java.net/~dnsimon/8155023, how do you want to handle security checks and dynamically exporting packages in the jdk.vm.ci.hotspot module to JVMCI client modules? -Doug > https://bugs.openjdk.java.net/browse/JDK-8155571 > http://cr.openjdk.java.net/~twisti/8155571/webrev.01/ > > Read the JIRA entry why we need this change. Most changes are moving files around and fixing up tests. > > Top-level changes: > > diff -r e51a92f0f1ac make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmk Tue Apr 19 15:26:51 2016 -0400 > +++ b/make/CompileJavaModules.gmk Wed May 04 09:45:13 2016 -1000 > @@ -483,11 +483,11 @@ MODULESOURCEPATH := $(call GetModuleSrcP > # Add imported modules to the modulepath > MODULEPATH := $(call PathList, $(IMPORT_MODULES_CLASSES)) > > -ifeq ($(MODULE), jdk.vm.ci) > - ## WORKAROUND jdk.vm.ci source structure issue > +## WORKAROUND jdk.vm.ci source structure > +ifneq ($(filter $(MODULE), jdk.vm.ci jdk.vm.ci.hotspot), ) > JVMCI_MODULESOURCEPATH := $(MODULESOURCEPATH) \ > - $(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \ > - $(wildcard $(HOTSPOT_TOPDIR)/src/jdk.vm.ci/share/classes/*/src))) > + $(subst src/$(MODULE)/,src/*/, $(filter-out %processor/src, \ > + $(wildcard $(HOTSPOT_TOPDIR)/src/$(MODULE)/share/classes/*/src))) > MODULESOURCEPATH := $(call PathList, $(JVMCI_MODULESOURCEPATH)) > endif > > diff -r e51a92f0f1ac make/common/Modules.gmk > --- a/make/common/Modules.gmk Tue Apr 19 15:26:51 2016 -0400 > +++ b/make/common/Modules.gmk Wed May 04 09:45:13 2016 -1000 > @@ -68,6 +68,7 @@ BOOT_MODULES += \ > jdk.security.jgss \ > jdk.unsupported \ > jdk.vm.ci \ > + jdk.vm.ci.hotspot \ > # > > # to be deprivileged > > > jdk/ changes: > > diff -r 909f38c3d339 src/java.base/share/classes/module-info.java > --- a/src/java.base/share/classes/module-info.java Wed May 04 17:17:28 2016 +0300 > +++ b/src/java.base/share/classes/module-info.java Wed May 04 09:46:02 2016 -1000 > @@ -138,7 +138,7 @@ module java.base { > exports jdk.internal.org.objectweb.asm to > jdk.jlink, > jdk.scripting.nashorn, > - jdk.vm.ci; > + jdk.vm.ci.hotspot; > exports jdk.internal.org.objectweb.asm.tree to > jdk.jlink; > exports jdk.internal.org.objectweb.asm.util to > @@ -173,7 +173,8 @@ module java.base { > jdk.charsets, > jdk.scripting.nashorn, > jdk.unsupported, > - jdk.vm.ci; > + jdk.vm.ci, > + jdk.vm.ci.hotspot; > exports jdk.internal.perf to > java.desktop, > java.management, > From paul.sandoz at oracle.com Thu May 5 01:04:06 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 May 2016 18:04:06 -0700 Subject: RFR (M): 8154974: AVX-512 equipped inflate, has_negatives & compress intrinsics In-Reply-To: <3616187E21868C40AD1B36D41D29F4C1520B12FC@FMSMSX106.amr.corp.intel.com> References: <3616187E21868C40AD1B36D41D29F4C1520B04B1@FMSMSX106.amr.corp.intel.com> <572A7E79.6070401@oracle.com> <3616187E21868C40AD1B36D41D29F4C1520B12FC@FMSMSX106.amr.corp.intel.com> Message-ID: <0B4E6F49-EA99-4A7F-BB62-B8E982F14A77@oracle.com> > On 4 May 2016, at 16:12, Wojtowicz, Tomasz wrote: > > Internally developed ubenchmarks for performance & similar functional using Reflections API for those 3 intrinsics on an up to 4K chunks of pseudo random initialized data to verify correctness. > Has_negatives had a negative sentinel as a last element in an array. > Also tailored examples for compress which would test all of the possible entry scenarios (tail present/not present, non-compressable element found in head OR tail - to make sure that there is a coverage for all of the basic blocks inside intrinsic) > > Everything run at least 3 times for -XX:UseAVX=1 then 2 and 3, depending on a scenario for establishing performance baseline AND/OR correctness when "older"(AVX<=2) had been modified. > The following JDK test should also give this intrinsic some exercise: test/java/util/Arrays/ArraysEqCmpTest.java 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 rahul.v.raghavan at oracle.com Thu May 5 11:31:51 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 5 May 2016 04:31:51 -0700 (PDT) Subject: RFR: 8153655: Make intrinsics flags diagnostic and update intrinsics tests to enable diagnostic options. In-Reply-To: <5722A4BD.5060607@oracle.com> References: <5722A4BD.5060607@oracle.com> Message-ID: <7032321c-0261-4d45-bda0-17ec3eefeadf@default> Hi, Thank you Vladimir for review comments. Yes, now updated the changes. Please review following revised webrev - http://cr.openjdk.java.net/~rraghavan/8153655/webrev.01/ (Modified 'test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForUnsupportedX86CPU.java') No issues found with testing done using product builds with proposed changes (hotspot/test/compiler/cpuflags/*, hotspot/test/compiler/intrinsics/* etc.) Complete pre-integration testing using product builds is in progress for this 'webrev.01'. (No issues with pre-integration testing done earlier for 'webrev.00'.) Thanks, Rahul > -----Original Message----- > From: Vladimir Kozlov > Sent: Friday, April 29, 2016 5:33 AM > > Hi Rahul, > > Changes looks good but you need to update changes for SHA tests because I changed them for JDK-8154495: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6a17c49de974 > > Thanks, > Vladimir > > On 4/27/16 2:45 AM, Rahul Raghavan wrote: > > Hi, > > > > Please review the following patch for JDK-8153655. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153655 > > Webrev: http://cr.openjdk.java.net/~rraghavan/8153655/webrev.00/ > > > > > > Notes: > > > > 1. This 8153655/webrev.00 re-includes earlier backed out, same JDK-8145348 changes > > (https://bugs.openjdk.java.net/browse/JDK-8145348 - Make intrinsics flags diagnostic) > > and also additional fixes in failing intrinsic tests. > > > > > > 2. Checked all the usages of changed intrinsic flags in tests and > > found JDK-8153655 type test failure issue (after initial JDK-8145348 fix) is present only for following tests - > > a. UseAESIntrinsics test (compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java) > > b. UseSHA* tests (at compiler/intrinsics/sha/cli/) > > > > > > 3. Summary of 8153655/webrev.00 changes. > > > > - Includes earlier backed out, same JDK-8145348 changes: > > src/share/vm/c1/c1_globals.hpp > > src/share/vm/opto/c2_globals.hpp > > src/share/vm/runtime/globals.hpp > > test/compiler/intrinsics/muladd/TestMulAdd.java > > test/compiler/runtime/6859338/Test6859338.java > > > > - 'test/compiler/cpuflags/AESIntrinsicsBase.java' > > Options were passed in wrong order. > > Changes done so that 'UnlockDiagnosticVMOptions' option precedes the diagnostic flags. > > > > - 'test/compiler/intrinsics/sha/cli/*' - (UseSHA* tests) > > 'UnlockDiagnosticVMOptions' option was not getting passed. > > Added support to precede intrinsic flag usages with explicit 'UnlockDiagnosticVMOptions'. > > > > > > 4. No issues found with testing done using product builds with proposed changes > > (hotspot/test/compiler/cpuflags/*, hotspot/test/compiler/intrinsics/*, hotspot/test/compiler/runtime/6859338/Test6859338.java) > > Complete pre-integration testing using product builds is in progress. > > > > > > Thanks, > > Rahul > > From doug.simon at oracle.com Thu May 5 12:39:13 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 5 May 2016 14:39:13 +0200 Subject: RFR: 8152311: allow JVMCI compiler to change the compilation policy for a method Message-ID: <2399DAF1-A2F2-4B94-A5F6-426DB8D7A35E@oracle.com> Please read the bug for a full description of this proposed change. https://bugs.openjdk.java.net/browse/JDK-8152311 http://cr.openjdk.java.net/~dnsimon/8152311/ -Doug From doug.simon at oracle.com Thu May 5 12:55:57 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 5 May 2016 14:55:57 +0200 Subject: RFR: 8152311: allow JVMCI compiler to change the compilation policy for a method In-Reply-To: <2399DAF1-A2F2-4B94-A5F6-426DB8D7A35E@oracle.com> References: <2399DAF1-A2F2-4B94-A5F6-426DB8D7A35E@oracle.com> Message-ID: <8CFCE10D-2570-4E48-AC86-3AB509A8C6F1@oracle.com> Note that this changes depends on https://bugs.openjdk.java.net/browse/JDK-8155023. > On 05 May 2016, at 14:39, Doug Simon wrote: > > Please read the bug for a full description of this proposed change. > > https://bugs.openjdk.java.net/browse/JDK-8152311 > http://cr.openjdk.java.net/~dnsimon/8152311/ > > -Doug From Alan.Bateman at oracle.com Thu May 5 14:55:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 15:55:54 +0100 Subject: RFR: 8155023: jdk.vm.ci needs to securely export services In-Reply-To: References: Message-ID: <572B5EFA.4050803@oracle.com> On 03/05/2016 14:34, Doug Simon wrote: > https://bugs.openjdk.java.net/browse/JDK-8155023 > http://cr.openjdk.java.net/~dnsimon/8155023/ > I skimmed through this. The module-info.java looks okay. The permission check idiom in JVMCICompilerFactory (and EventProvider) look fine. I'm not sure about using RuntimePermission("jvmci"). One reason is that RuntimePermission specifies in its javadoc all the possible targets. It might be better to just introduce a new basic permission for this. One thing about Services.load is that it uses ServiceLoader.load and hence the TCCL. I don't know if this is what you here, I suspect you want the system class loader. In passing, the @return for getTrivialPrefixes() suggests an empty array can be returned and so I assume the default should be to return an empty array rather than null. -Alan From doug.simon at oracle.com Thu May 5 15:45:53 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 5 May 2016 17:45:53 +0200 Subject: RFR: 8155023: jdk.vm.ci needs to securely export services In-Reply-To: <572B5EFA.4050803@oracle.com> References: <572B5EFA.4050803@oracle.com> Message-ID: <04E2339D-0EEB-4C31-947E-C46A0EE2A327@oracle.com> > On 05 May 2016, at 16:55, Alan Bateman wrote: > > On 03/05/2016 14:34, Doug Simon wrote: >> https://bugs.openjdk.java.net/browse/JDK-8155023 >> http://cr.openjdk.java.net/~dnsimon/8155023/ >> > I skimmed through this. > > The module-info.java looks okay. The permission check idiom in JVMCICompilerFactory (and EventProvider) look fine. > > I'm not sure about using RuntimePermission("jvmci"). One reason is that RuntimePermission specifies in its javadoc all the possible targets. It might be better to just introduce a new basic permission for this. Ok, I was not aware that the set of RuntimePermissions is effectively closed. I?ve created JVMCIPermission and updated the webrev. > > One thing about Services.load is that it uses ServiceLoader.load and hence the TCCL. I don't know if this is what you here, I suspect you want the system class loader. Is that because I should expect only trusted code to use this call? That is, only code available via the system class loader? I?ll admit that when to use TCCL versus the system class loader is not clear to me. > In passing, the @return for getTrivialPrefixes() suggests an empty array can be returned and so I assume the default should be to return an empty array rather than null. I?ve correct the javadoc to allow using null to disable the prefix mechanism for forcing compilations to be performed by C1. Thanks for the review! -Doug From christian.thalinger at oracle.com Thu May 5 17:45:37 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 5 May 2016 07:45:37 -1000 Subject: RFR: 8155571: [JVMCI] split jdk.vm.ci module into jdk.vm.ci and jdk.vm.ci.hotspot In-Reply-To: References: Message-ID: <6F91A500-920F-4526-B5E6-667FFC7B36ED@oracle.com> > On May 4, 2016, at 1:43 PM, Doug Simon wrote: > > In light of the Services.exportJVMCITo method being proposed in http://cr.openjdk.java.net/~dnsimon/8155023, how do you want to handle security checks and dynamically exporting packages in the jdk.vm.ci.hotspot module to JVMCI client modules? Good question. Let?s talk about this today? > > -Doug > >> https://bugs.openjdk.java.net/browse/JDK-8155571 >> http://cr.openjdk.java.net/~twisti/8155571/webrev.01/ >> >> Read the JIRA entry why we need this change. Most changes are moving files around and fixing up tests. >> >> Top-level changes: >> >> diff -r e51a92f0f1ac make/CompileJavaModules.gmk >> --- a/make/CompileJavaModules.gmk Tue Apr 19 15:26:51 2016 -0400 >> +++ b/make/CompileJavaModules.gmk Wed May 04 09:45:13 2016 -1000 >> @@ -483,11 +483,11 @@ MODULESOURCEPATH := $(call GetModuleSrcP >> # Add imported modules to the modulepath >> MODULEPATH := $(call PathList, $(IMPORT_MODULES_CLASSES)) >> >> -ifeq ($(MODULE), jdk.vm.ci) >> - ## WORKAROUND jdk.vm.ci source structure issue >> +## WORKAROUND jdk.vm.ci source structure >> +ifneq ($(filter $(MODULE), jdk.vm.ci jdk.vm.ci.hotspot), ) >> JVMCI_MODULESOURCEPATH := $(MODULESOURCEPATH) \ >> - $(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \ >> - $(wildcard $(HOTSPOT_TOPDIR)/src/jdk.vm.ci/share/classes/*/src))) >> + $(subst src/$(MODULE)/,src/*/, $(filter-out %processor/src, \ >> + $(wildcard $(HOTSPOT_TOPDIR)/src/$(MODULE)/share/classes/*/src))) >> MODULESOURCEPATH := $(call PathList, $(JVMCI_MODULESOURCEPATH)) >> endif >> >> diff -r e51a92f0f1ac make/common/Modules.gmk >> --- a/make/common/Modules.gmk Tue Apr 19 15:26:51 2016 -0400 >> +++ b/make/common/Modules.gmk Wed May 04 09:45:13 2016 -1000 >> @@ -68,6 +68,7 @@ BOOT_MODULES += \ >> jdk.security.jgss \ >> jdk.unsupported \ >> jdk.vm.ci \ >> + jdk.vm.ci.hotspot \ >> # >> >> # to be deprivileged >> >> >> jdk/ changes: >> >> diff -r 909f38c3d339 src/java.base/share/classes/module-info.java >> --- a/src/java.base/share/classes/module-info.java Wed May 04 17:17:28 2016 +0300 >> +++ b/src/java.base/share/classes/module-info.java Wed May 04 09:46:02 2016 -1000 >> @@ -138,7 +138,7 @@ module java.base { >> exports jdk.internal.org.objectweb.asm to >> jdk.jlink, >> jdk.scripting.nashorn, >> - jdk.vm.ci; >> + jdk.vm.ci.hotspot; >> exports jdk.internal.org.objectweb.asm.tree to >> jdk.jlink; >> exports jdk.internal.org.objectweb.asm.util to >> @@ -173,7 +173,8 @@ module java.base { >> jdk.charsets, >> jdk.scripting.nashorn, >> jdk.unsupported, >> - jdk.vm.ci; >> + jdk.vm.ci, >> + jdk.vm.ci.hotspot; >> exports jdk.internal.perf to >> java.desktop, >> java.management, >> > From vladimir.kozlov at oracle.com Thu May 5 18:06:59 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 5 May 2016 11:06:59 -0700 Subject: RFR: 8152311: allow JVMCI compiler to change the compilation policy for a method In-Reply-To: <2399DAF1-A2F2-4B94-A5F6-426DB8D7A35E@oracle.com> References: <2399DAF1-A2F2-4B94-A5F6-426DB8D7A35E@oracle.com> Message-ID: <572B8BC3.5010509@oracle.com> I looked on VM changes. You put #include under #if INCLUDE_JVMCI but call to JVMCIRuntime::adjust_comp_level() method are guarded only by flag. Some compilers may complain. In thread.hpp is there a reason to use several bool fields instead of one field for flags? Thanks, Vladimir On 5/5/16 5:39 AM, Doug Simon wrote: > Please read the bug for a full description of this proposed change. > > https://bugs.openjdk.java.net/browse/JDK-8152311 > http://cr.openjdk.java.net/~dnsimon/8152311/ > > -Doug > From pavel.punegov at oracle.com Thu May 5 18:06:24 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Thu, 5 May 2016 21:06:24 +0300 Subject: RFR (S): 8150247: CompilerControl: LogCompilation testing Message-ID: Hi, please review the following change to CompilerControl tests. It adds a new test to cover the gap found by JDK-8145345 [*]. The LogCompilation was empty after CompilerControl was integrated, but tests haven?t found that. This happened only when the LogCompilation was specified while there were no directives/CompileCommands enabled. With enabled directive/command it worked fine. Tests didn?t found the issue due to: 1. There were no standalone test for LogCompilation. All related tests enable appropriate log directive or command. 2. LogProcessor incorrectly worked for empty tasks that should be logged. It didn?t reported the issue. [*] https://bugs.openjdk.java.net/browse/JDK-8145345 bug: https://bugs.openjdk.java.net/browse/JDK-8150247 webrev: http://cr.openjdk.java.net/~ppunegov/8150247/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Thu May 5 18:35:52 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 5 May 2016 11:35:52 -0700 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <9d5d8aae-1699-8701-7cfa-29473e41e7d0@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> <9d5d8aae-1699-8701-7cfa-29473e41e7d0@oracle.com> Message-ID: <7798058d-4496-1890-2426-9e3436df5e57@oracle.com> Updated webrevs here: jdk: http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03/jdk/webrev/ hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03/hotspot/webrev/ Incremental from webrev.02: jdk: http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03.incr/jdk/webrev/ hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03.incr/hotspot/webrev/ Changes from webrev.02: - javadoc updates for getAddress/putAddress in line with Paul's feedback (move the more descriptive comment to the double-register methods, with an @see on the single-reg guys) - updates to make MemoryAccess::get_mutex jlong specific Some additional comments inline.. On 5/3/2016 10:07 PM, David Holmes wrote: > On 4/05/2016 4:43 AM, Mikael Vidstedt wrote: >> >> Thank you very much for the review, some comments inline... >> >> On 5/3/2016 8:15 AM, Aleksey Shipilev wrote: >>> On 05/03/2016 08:09 AM, Mikael Vidstedt wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150921 >>>> Webrev (jdk): >>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/jdk/webrev/ >>>> >>>> Webrev (hotspot/): >>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/hotspot/webrev/ >>>> >>>> >>> Nice move overall! >>> >>> unsafe.cpp: >>> >>> *) Why do we Handle-ize incoming object in CompareAnd*? Is this because >>> we may acquire a mutex, and the object may be gone? Either way, I see >>> you have dropped Handle from Unsafe_CompareAndSwapLong, but kept it in >>> Unsafe_CompareAndExchangeLong -- why? >>> >>> *) Ditto for old {Get|Set}LongVolatile -- it used to Handle-ize before >>> acquiring a mutex -- now we don't do that in MemoryAccess. >> >> My bad. As you say resolving the object should happen after the mutex >> has been acquired (see long comment starting on line 377 for the >> background). I have added back the Handle in CompareAndSwapLong and >> moved the addr() call in the mutex methods of MemoryAccess. Thank you >> for catching that! >> >>> >>> vmSymbols.cpp: >>> >>> *) {get|put}Address_raw intrinsics used to be conditionalized under >>> UseUnalignedAccesses. Baffles me why, because the old native code in >>> Unsafe_{Get|Set}NativeAddress/unsafe.cpp would seem to fail with >>> misaligned addresses. I wonder if the intent was to never fail, and >>> then >>> we should really use Unsafe.{get|put}Unaligned in new Unsafe.java >>> {get|set}Address to dodge misalign faults? >> >> I also failed to see what the conditional intrinsification is trying to >> achieve given that the native code does nothing special for the >> unaligned case. Unless I'm missing something the proposed change makes >> it no worse, and will potentially improve performance a tad on the >> pickier platforms. If anything we may want to consider introducing >> methods for getAddressUnaligned and putAddressUnaligned as a separate >> change. >> >>> library_call.cpp: >>> >>> *) What is the point for doing this check: >>> >>> 2372 if (_gvn.type(base)->isa_ptr() != TypePtr::NULL_PTR) { >>> 2373 heap_base_oop = base; >>> 2374 } >>> >>> In old code heap_base_oop != top() only for heap ptrs, even if base is >>> NULL. In new code, if base is NULL, then heap_base_oop is top(). It >>> would seem that new code is better, because it clearly separates heap >>> vs. native accesses, and it does not seem to break anything downstream. >>> Was that the intent? >> >> Those three lines were actually donated to my by John Rose, so I'm >> hoping he or somebody else more knowledgeable in C2 can provide some >> helpful comments on the correctness and validity of that specific >> change. >> >> >> I also changed the normalize() methods to be private in the MemoryAccess >> class, and made the MemoryAccess class a StackObj. >> >> New webrev(s) here: >> >> jdk: >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/jdk/webrev/ >> hotspot: >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/hotspot/webrev/ >> > > src/share/vm/prims/unsafe.cpp > > I think this is a bit over-generalized: > > 254 template > 255 void put_mutex(T x) { > 256 GuardUnsafeAccess guard(_thread, _obj); > 257 > 258 MutexLockerEx mu(UnsafeJlong_lock, > Mutex::_no_safepoint_check_flag); > 259 > 260 T* p = (T*)addr(); > 261 > 262 Atomic::store(normalize(x), p); > 263 } > > The UnsafeJlong lock is, as the name suggests, only intended for use > with jlongs - we have no need of it for any other type. I don't think > this needs to be a template method. Good point. I guess the method could be made to take the mutex as an argument, or internally decide which mutex to use depending on the type, but given that really only is used for jlong right now I made the function jlong specific (without the template argument). > As noted before the lock could taken after calculating the address - > to shorten the critical section. > > If you take care to ensure no uses of MemoryAccess transitively can > hit a safepoint then you could store the oop directly rather than the > jobject. That would avoid multiple calls to JNIHandles::resolve (in > the GuardUnsafeAccess and addr() function). Since the resolve call is really just dereferencing a pointer and the data should already be in the L1 cache I'm not sure this is worth optimizing a whole lot more, but if we really think it will actually make a difference we can definitely store the raw oop instead. I chose to leave it the way it is for now. > > 405 if (VM_Version::supports_cx8()) { > 406 return MemoryAccess(thread, obj, offset).get_volatile(); > > 407 } else { > 408 return MemoryAccess(thread, obj, offset).get_mutex(); > > You could internalize the supports_cx8 check and the use of locking > inside MemoryAccess.get_volatile rather than having > get_volatile and get_mutex. If you prefer to keep it this way then > get_volatile_with_mutex would be a more appropriate name (and it > doesn't need to be a template method as I said before). That's good, I like it! In the interest of drawing a line though I'm going to choose to leave that for a future enhancement. Cheers, Mikael > > Can't comment on the rest of the compiler related stuff too much, but > I didn't see anything obviously odd looking. > > Thanks, > David > >> >> Incremental from webrev.01: >> >> jdk: N/A (no changes) >> hotspot: >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02.incr/hotspot/webrev/ >> >> >> >> Cheers, >> Mikael >> >>> >>> Thanks, >>> -Aleksey >>> >>> >> From vladimir.x.ivanov at oracle.com Thu May 5 18:48:49 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 5 May 2016 21:48:49 +0300 Subject: [9] RFR (XS): 8155635: C2: opaque unsafe access triggers an assert Message-ID: <572B9591.4040505@oracle.com> http://cr.openjdk.java.net/~vlivanov/8155781/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8155781 The following code hits an assert in LibraryCallKit::inline_unsafe_access() during compilation of the following code: int test(Object o) { return UNSAFE.getInt(o, F_OFFSET); } It baffles the compiler since such shape can be used to access both on-heap and off-heap memory (due to double-register addressing mode). The proposed fix is to convert the asserts into guards which revert to native calls in such cases. Testing: JPRT, RBT (hs-tier0-comp). Thanks! Best regards, Vladimir Ivanov From aleksey.shipilev at oracle.com Thu May 5 19:06:44 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 5 May 2016 22:06:44 +0300 Subject: RFR (XS) 8156068: Unsafe.{get|set}Opaque should be single copy atomic Message-ID: <572B99C4.5080808@oracle.com> Hi, Please review a tiny fix in C2 intrinsics that make Unsafe.{get|set}Opaque single-copy atomic, as intended. These opaque methods are supposed to act like std::atomic(..., memord_relaxed), that is, do not induce ordering, but still provide access atomicity. Interpreter and C1 are delegating to volatile get/set, and so are atomic already. C2 has a little bug that was introduced along with the initial VarHandles change. Bug: https://bugs.openjdk.java.net/browse/JDK-8156068 Webrev: http://cr.openjdk.java.net/~shade/8156068/webrev.00/ Testing: jcstress atomicity test on 32-bit x86; RBT (hs-tier0-comp). Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From vladimir.x.ivanov at oracle.com Thu May 5 19:10:22 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 5 May 2016 22:10:22 +0300 Subject: [9] RFR (XS): 8155635: C2: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr In-Reply-To: <57240AB4.8040406@oracle.com> References: <5723EA35.5020809@oracle.com> <99d03b20-bdb4-5948-89aa-eced57b279af@oracle.com> <5723FB50.6050301@oracle.com> <57240AB4.8040406@oracle.com> Message-ID: <572B9A9E.8080805@oracle.com> >>> >>> Can you explain why we have such graph shape where we access memory >>> after a merge point and on one merged path has NULL as pointer to >>> object. There should be NULL check after merge before memory access in >>> such case. >> It's not necessarily a normal oop pointer. Double-register addressing >> mode is the source of such shapes. Consider the following example: >> >> Object o = (flag ? INSTANCE : null); >> long off = (flag ? F_OFFSET : ADDR); >> UNSAFE.getLong(o, off); > > I think for this graph shape C2 type system gave up and drops type to > general Ptr::BOTTOM because it does not know that 'off' can be address > and not a normal offset on dead path where base is NULL. We usually do: > > long l = flag ? o.field : UNSAFE.getLong(addr); > And for UNSAFE.getLong(addr) we generate Raw pointer address > (make_unsafe_address()). > > What I am saying is that C2 treat long value as address only when it was > used as direct parameter for unsafe. See > LibraryCallKit::classify_unsafe_addr(). The type I see during compilation for "opaque" access (mixed on-heap & off-heap) is the following: Oop:UnsafeAddP:exact+any * [narrow] LibraryCallKit::classify_unsafe_addr() produces Type::AnyPtr for such shapes. But it is used in LibraryCallKit::make_unsafe_address() just to decide on base value: inline Node* LibraryCallKit::make_unsafe_address(Node* base, Node* offset) { int kind = classify_unsafe_addr(base, offset); if (kind == Type::RawPtr) { return basic_plus_adr(top(), base, offset); } else { return basic_plus_adr(base, offset); } } Maybe we need to enhance the logic and produce a special shape for such accesses. > Who produces ADDR? May be we can't set flag to indicate that it is RAW > address. I don't see how we can achieve that. It's just a long constant (or value) which represents an absolute address at runtime: static final long addr = UNSAFE.allocateMemory(10); > We should discuss it with John who is *the* expert in this. John, what are your thoughts about that? Best regards, Vladimir Ivanov > > Thanks, > Vladimir > >> >> is translated into: >> >> LoadL mem (AddP (Phi #NULL #NonNull) off) >> >> If such AddP is split through the Phi, it turns into (AddP #NULL #NULL >> off) and (AddP #NonNull #NonNull off). The former is untyped and >> causes problems later. >> >> What I can't replicate is how X-shaped control flow eligible for >> SplitIf transformation is produced. >> >> In the failing case, initial null & exact type checks of an oop local >> (on OSR entry) merge into redundant X-shaped block. Unsafe accesses >> uses the local as a base later. >> >> Best regards, >> Vladimir Ivanov >> >>> >>> On 4/29/16 4:11 PM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8155635/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8155635 >>>> >>>> SplitIf transformation can produce untyped pointers when slitting AddP >>>> nodes for unsafe accesses through a Phi which >>>> merges non-null & null values: >>>> AddP ... (Phi (ConP #NULL) (CheckCastPP Oop:...:NotNull)) >>>> >>>> Proposed fix is to enable oop pointer to raw pointer conversion for >>>> absolute addresses. >>>> >>>> I also experimented with blocking SplitIf transformation is such >>>> cases, but the transformation seems viable and >>>> considerably simplifies the graph: X-shaped control flow is untangled >>>> by eliminating redundant and the transformation >>>> sharpens types on both branches. >>>> >>>> I checked specifically how Phi merges raw & oop pointers after the >>>> split and it works fine. >>>> >>>> Testing: failing test, JPRT, RBT (hs-tier0-comp.js). >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> PS: though AddP (Phi #NULL #NotNull) shape is common, I wasn't able to >>>> write a simplified test case which triggers >>>> SplitIf transformation. From aleksey.shipilev at oracle.com Thu May 5 19:14:30 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 5 May 2016 22:14:30 +0300 Subject: RFR (S) 8155965: Unsafe.weakCompareAndSetVolatile entry points and intrinsics Message-ID: <572B9B96.60309@oracle.com> Hi, Please review this addition to Unsafe and C2 intrinsics, that adds Unsafe.weakCompareAndSetVolatile family of entry points. This provides the VM support for additional VarHandles access modes (see JDK-8154755). Bug: https://bugs.openjdk.java.net/browse/JDK-8155965 Webrevs: http://cr.openjdk.java.net/~shade/8155965/webrev.jdk.00/ http://cr.openjdk.java.net/~shade/8155965/webrev.hs.00/ The bulk of changes is in tests. The actual change in compiler code is just a few lines declaring a new weakCAS shape. Testing: Linux x86_64 tests: hotspot/compiler/unsafe; RBT (hs-tier0-comp). Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From vladimir.kozlov at oracle.com Thu May 5 19:27:09 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 5 May 2016 12:27:09 -0700 Subject: [9] RFR (XS): 8155635: C2: opaque unsafe access triggers an assert In-Reply-To: <572B9591.4040505@oracle.com> References: <572B9591.4040505@oracle.com> Message-ID: <572B9E8D.7090405@oracle.com> Looks good. What actual alias type in such case? Thanks, Vladimir On 5/5/16 11:48 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8155781/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8155781 > > The following code hits an assert in LibraryCallKit::inline_unsafe_access() during compilation of the following code: > > int test(Object o) { > return UNSAFE.getInt(o, F_OFFSET); > } > > It baffles the compiler since such shape can be used to access both on-heap and off-heap memory (due to double-register addressing mode). > > The proposed fix is to convert the asserts into guards which revert to native calls in such cases. > > Testing: JPRT, RBT (hs-tier0-comp). > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Thu May 5 19:43:14 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 5 May 2016 12:43:14 -0700 Subject: [9] RFR (XS): 8155635: C2: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr In-Reply-To: <572B9A9E.8080805@oracle.com> References: <5723EA35.5020809@oracle.com> <99d03b20-bdb4-5948-89aa-eced57b279af@oracle.com> <5723FB50.6050301@oracle.com> <57240AB4.8040406@oracle.com> <572B9A9E.8080805@oracle.com> Message-ID: <572BA252.60003@oracle.com> On 5/5/16 12:10 PM, Vladimir Ivanov wrote: >>>> >>>> Can you explain why we have such graph shape where we access memory >>>> after a merge point and on one merged path has NULL as pointer to >>>> object. There should be NULL check after merge before memory access in >>>> such case. >>> It's not necessarily a normal oop pointer. Double-register addressing >>> mode is the source of such shapes. Consider the following example: >>> >>> Object o = (flag ? INSTANCE : null); >>> long off = (flag ? F_OFFSET : ADDR); >>> UNSAFE.getLong(o, off); >> >> I think for this graph shape C2 type system gave up and drops type to >> general Ptr::BOTTOM because it does not know that 'off' can be address >> and not a normal offset on dead path where base is NULL. We usually do: >> >> long l = flag ? o.field : UNSAFE.getLong(addr); >> And for UNSAFE.getLong(addr) we generate Raw pointer address >> (make_unsafe_address()). >> >> What I am saying is that C2 treat long value as address only when it was >> used as direct parameter for unsafe. See >> LibraryCallKit::classify_unsafe_addr(). > > The type I see during compilation for "opaque" access (mixed on-heap & off-heap) is the following: > > Oop:UnsafeAddP:exact+any * [narrow] > > LibraryCallKit::classify_unsafe_addr() produces Type::AnyPtr for such shapes. But it is used in LibraryCallKit::make_unsafe_address() just to decide on base value: MAy be classify_unsafe_addr() should produce RawPtr type in such case. > > inline Node* LibraryCallKit::make_unsafe_address(Node* base, Node* offset) { > int kind = classify_unsafe_addr(base, offset); > if (kind == Type::RawPtr) { > return basic_plus_adr(top(), base, offset); > } else { > return basic_plus_adr(base, offset); > } > } > > Maybe we need to enhance the logic and produce a special shape for such accesses. Yes, I think it is good place to enhance it since we know that we do unsafe access and can generate RAW acccess. > >> Who produces ADDR? May be we can't set flag to indicate that it is RAW >> address. > > I don't see how we can achieve that. It's just a long constant (or value) which represents an absolute address at runtime: > > static final long addr = UNSAFE.allocateMemory(10); Yes, flag will not work. But we access such addr only through UNSAFE api. So we should be able to produce RAW type for it at that point. Thanks, Vladimir > >> We should discuss it with John who is *the* expert in this. > > John, what are your thoughts about that? > > Best regards, > Vladimir Ivanov > >> >> Thanks, >> Vladimir >> >>> >>> is translated into: >>> >>> LoadL mem (AddP (Phi #NULL #NonNull) off) >>> >>> If such AddP is split through the Phi, it turns into (AddP #NULL #NULL >>> off) and (AddP #NonNull #NonNull off). The former is untyped and >>> causes problems later. >>> >>> What I can't replicate is how X-shaped control flow eligible for >>> SplitIf transformation is produced. >>> >>> In the failing case, initial null & exact type checks of an oop local >>> (on OSR entry) merge into redundant X-shaped block. Unsafe accesses >>> uses the local as a base later. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>>> >>>> On 4/29/16 4:11 PM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8155635/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8155635 >>>>> >>>>> SplitIf transformation can produce untyped pointers when slitting AddP >>>>> nodes for unsafe accesses through a Phi which >>>>> merges non-null & null values: >>>>> AddP ... (Phi (ConP #NULL) (CheckCastPP Oop:...:NotNull)) >>>>> >>>>> Proposed fix is to enable oop pointer to raw pointer conversion for >>>>> absolute addresses. >>>>> >>>>> I also experimented with blocking SplitIf transformation is such >>>>> cases, but the transformation seems viable and >>>>> considerably simplifies the graph: X-shaped control flow is untangled >>>>> by eliminating redundant and the transformation >>>>> sharpens types on both branches. >>>>> >>>>> I checked specifically how Phi merges raw & oop pointers after the >>>>> split and it works fine. >>>>> >>>>> Testing: failing test, JPRT, RBT (hs-tier0-comp.js). >>>>> >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> PS: though AddP (Phi #NULL #NotNull) shape is common, I wasn't able to >>>>> write a simplified test case which triggers >>>>> SplitIf transformation. From vladimir.kozlov at oracle.com Thu May 5 19:48:30 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 5 May 2016 12:48:30 -0700 Subject: RFR: 8153655: Make intrinsics flags diagnostic and update intrinsics tests to enable diagnostic options. In-Reply-To: <7032321c-0261-4d45-bda0-17ec3eefeadf@default> References: <5722A4BD.5060607@oracle.com> <7032321c-0261-4d45-bda0-17ec3eefeadf@default> Message-ID: <572BA38E.5050304@oracle.com> Looks good. thanks, Vladimir On 5/5/16 4:31 AM, Rahul Raghavan wrote: > Hi, > > Thank you Vladimir for review comments. > Yes, now updated the changes. > > Please review following revised webrev - > http://cr.openjdk.java.net/~rraghavan/8153655/webrev.01/ > (Modified 'test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForUnsupportedX86CPU.java') > > No issues found with testing done using product builds with proposed changes > (hotspot/test/compiler/cpuflags/*, hotspot/test/compiler/intrinsics/* etc.) > Complete pre-integration testing using product builds is in progress for this 'webrev.01'. > (No issues with pre-integration testing done earlier for 'webrev.00'.) > > Thanks, > Rahul > >> -----Original Message----- >> From: Vladimir Kozlov > Sent: Friday, April 29, 2016 5:33 AM >> >> Hi Rahul, >> >> Changes looks good but you need to update changes for SHA tests because I changed them for JDK-8154495: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6a17c49de974 >> >> Thanks, >> Vladimir >> >> On 4/27/16 2:45 AM, Rahul Raghavan wrote: >>> Hi, >>> >>> Please review the following patch for JDK-8153655. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153655 >>> Webrev: http://cr.openjdk.java.net/~rraghavan/8153655/webrev.00/ >>> >>> >>> Notes: >>> >>> 1. This 8153655/webrev.00 re-includes earlier backed out, same JDK-8145348 changes >>> (https://bugs.openjdk.java.net/browse/JDK-8145348 - Make intrinsics flags diagnostic) >>> and also additional fixes in failing intrinsic tests. >>> >>> >>> 2. Checked all the usages of changed intrinsic flags in tests and >>> found JDK-8153655 type test failure issue (after initial JDK-8145348 fix) is present only for following tests - >>> a. UseAESIntrinsics test (compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java) >>> b. UseSHA* tests (at compiler/intrinsics/sha/cli/) >>> >>> >>> 3. Summary of 8153655/webrev.00 changes. >>> >>> - Includes earlier backed out, same JDK-8145348 changes: >>> src/share/vm/c1/c1_globals.hpp >>> src/share/vm/opto/c2_globals.hpp >>> src/share/vm/runtime/globals.hpp >>> test/compiler/intrinsics/muladd/TestMulAdd.java >>> test/compiler/runtime/6859338/Test6859338.java >>> >>> - 'test/compiler/cpuflags/AESIntrinsicsBase.java' >>> Options were passed in wrong order. >>> Changes done so that 'UnlockDiagnosticVMOptions' option precedes the diagnostic flags. >>> >>> - 'test/compiler/intrinsics/sha/cli/*' - (UseSHA* tests) >>> 'UnlockDiagnosticVMOptions' option was not getting passed. >>> Added support to precede intrinsic flag usages with explicit 'UnlockDiagnosticVMOptions'. >>> >>> >>> 4. No issues found with testing done using product builds with proposed changes >>> (hotspot/test/compiler/cpuflags/*, hotspot/test/compiler/intrinsics/*, hotspot/test/compiler/runtime/6859338/Test6859338.java) >>> Complete pre-integration testing using product builds is in progress. >>> >>> >>> Thanks, >>> Rahul >>> From paul.sandoz at oracle.com Thu May 5 20:27:29 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 5 May 2016 13:27:29 -0700 Subject: RFR (XS) 8156068: Unsafe.{get|set}Opaque should be single copy atomic In-Reply-To: <572B99C4.5080808@oracle.com> References: <572B99C4.5080808@oracle.com> Message-ID: <0BBEC683-1D18-4C2B-A6A3-B0D059AFB776@oracle.com> > On 5 May 2016, at 12:06, Aleksey Shipilev wrote: > > Hi, > > Please review a tiny fix in C2 intrinsics that make > Unsafe.{get|set}Opaque single-copy atomic, as intended. These opaque > methods are supposed to act like std::atomic(..., memord_relaxed), that > is, do not induce ordering, but still provide access atomicity. > > Interpreter and C1 are delegating to volatile get/set, and so are atomic > already. C2 has a little bug that was introduced along with the initial > VarHandles change. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8156068 > > Webrev: > http://cr.openjdk.java.net/~shade/8156068/webrev.00/ > > Testing: jcstress atomicity test on 32-bit x86; RBT (hs-tier0-comp). > +1 Paul. > Thanks, > -Aleksey > > -------------- 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 paul.sandoz at oracle.com Thu May 5 20:32:08 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 5 May 2016 13:32:08 -0700 Subject: RFR (S) 8155965: Unsafe.weakCompareAndSetVolatile entry points and intrinsics In-Reply-To: <572B9B96.60309@oracle.com> References: <572B9B96.60309@oracle.com> Message-ID: <9EB14B66-3F28-4C6D-9E41-AC808116E3F0@oracle.com> > On 5 May 2016, at 12:14, Aleksey Shipilev wrote: > > Hi, > > Please review this addition to Unsafe and C2 intrinsics, that adds > Unsafe.weakCompareAndSetVolatile family of entry points. This provides > the VM support for additional VarHandles access modes (see JDK-8154755). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8155965 > > Webrevs: > http://cr.openjdk.java.net/~shade/8155965/webrev.jdk.00/ > http://cr.openjdk.java.net/~shade/8155965/webrev.hs.00/ > > The bulk of changes is in tests. The actual change in compiler code is > just a few lines declaring a new weakCAS shape. > > Testing: Linux x86_64 tests: hotspot/compiler/unsafe; RBT (hs-tier0-comp). > +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 doug.simon at oracle.com Thu May 5 21:14:58 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 5 May 2016 23:14:58 +0200 Subject: RFR: 8152311: allow JVMCI compiler to change the compilation policy for a method In-Reply-To: <572B8BC3.5010509@oracle.com> References: <2399DAF1-A2F2-4B94-A5F6-426DB8D7A35E@oracle.com> <572B8BC3.5010509@oracle.com> Message-ID: <5E0388C7-DA54-4869-91BD-F12CECFF9C00@oracle.com> > On 05 May 2016, at 20:06, Vladimir Kozlov wrote: > > I looked on VM changes. You put #include under #if INCLUDE_JVMCI but call to JVMCIRuntime::adjust_comp_level() method are guarded only by flag. Some compilers may complain. Ok, I added the missing #if INCLUDE_JVMCI guards. Are there regular test builds with INCLUDE_JVMCI=0 that would have caught this? > In thread.hpp is there a reason to use several bool fields instead of one field for flags? Probably didn?t seem worth it when there were only 2 bool fields. Now that there will be three, should I convert to using a flags field? Thanks for the review. -Doug > Thanks, > Vladimir > > On 5/5/16 5:39 AM, Doug Simon wrote: >> Please read the bug for a full description of this proposed change. >> >> https://bugs.openjdk.java.net/browse/JDK-8152311 >> http://cr.openjdk.java.net/~dnsimon/8152311/ >> >> -Doug >> From vladimir.kozlov at oracle.com Thu May 5 21:56:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 5 May 2016 14:56:20 -0700 Subject: RFR: 8152311: allow JVMCI compiler to change the compilation policy for a method In-Reply-To: <5E0388C7-DA54-4869-91BD-F12CECFF9C00@oracle.com> References: <2399DAF1-A2F2-4B94-A5F6-426DB8D7A35E@oracle.com> <572B8BC3.5010509@oracle.com> <5E0388C7-DA54-4869-91BD-F12CECFF9C00@oracle.com> Message-ID: <572BC184.5060309@oracle.com> On 5/5/16 2:14 PM, Doug Simon wrote: > >> On 05 May 2016, at 20:06, Vladimir Kozlov wrote: >> >> I looked on VM changes. You put #include under #if INCLUDE_JVMCI but call to JVMCIRuntime::adjust_comp_level() method are guarded only by flag. Some compilers may complain. > > Ok, I added the missing #if INCLUDE_JVMCI guards. Are there regular test builds with INCLUDE_JVMCI=0 that would have caught this? Try to use JPRT test run (-stree .). It will build on all platforms and some have INCLUDE_JVMCI = 0. > >> In thread.hpp is there a reason to use several bool fields instead of one field for flags? > > Probably didn?t seem worth it when there were only 2 bool fields. Now that there will be three, should I convert to using a flags field? Yes please use flags field (after int field to get more compact data). Thanks, Vladimir > > Thanks for the review. > > -Doug > >> Thanks, >> Vladimir >> >> On 5/5/16 5:39 AM, Doug Simon wrote: >>> Please read the bug for a full description of this proposed change. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8152311 >>> http://cr.openjdk.java.net/~dnsimon/8152311/ >>> >>> -Doug >>> > From david.holmes at oracle.com Thu May 5 21:56:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 May 2016 07:56:50 +1000 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: <7798058d-4496-1890-2426-9e3436df5e57@oracle.com> References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> <9d5d8aae-1699-8701-7cfa-29473e41e7d0@oracle.com> <7798058d-4496-1890-2426-9e3436df5e57@oracle.com> Message-ID: Hi Mikael, On 6/05/2016 4:35 AM, Mikael Vidstedt wrote: > > Updated webrevs here: > > jdk: > http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03/jdk/webrev/ > hotspot: > http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03/hotspot/webrev/ > > > Incremental from webrev.02: > > jdk: > http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03.incr/jdk/webrev/ > > hotspot: > http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03.incr/hotspot/webrev/ Sorry I'm going to have to insist on a minor renaming as we are not getting or putting mutexes. How about get_jlong_locked/put_jlong_locked ? No need to see another webrev. Thanks, David > > Changes from webrev.02: > > - javadoc updates for getAddress/putAddress in line with Paul's feedback > (move the more descriptive comment to the double-register methods, with > an @see on the single-reg guys) > - updates to make MemoryAccess::get_mutex jlong specific > > Some additional comments inline.. > > On 5/3/2016 10:07 PM, David Holmes wrote: >> On 4/05/2016 4:43 AM, Mikael Vidstedt wrote: >>> >>> Thank you very much for the review, some comments inline... >>> >>> On 5/3/2016 8:15 AM, Aleksey Shipilev wrote: >>>> On 05/03/2016 08:09 AM, Mikael Vidstedt wrote: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150921 >>>>> Webrev (jdk): >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/jdk/webrev/ >>>>> >>>>> Webrev (hotspot/): >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/hotspot/webrev/ >>>>> >>>>> >>>> Nice move overall! >>>> >>>> unsafe.cpp: >>>> >>>> *) Why do we Handle-ize incoming object in CompareAnd*? Is this because >>>> we may acquire a mutex, and the object may be gone? Either way, I see >>>> you have dropped Handle from Unsafe_CompareAndSwapLong, but kept it in >>>> Unsafe_CompareAndExchangeLong -- why? >>>> >>>> *) Ditto for old {Get|Set}LongVolatile -- it used to Handle-ize before >>>> acquiring a mutex -- now we don't do that in MemoryAccess. >>> >>> My bad. As you say resolving the object should happen after the mutex >>> has been acquired (see long comment starting on line 377 for the >>> background). I have added back the Handle in CompareAndSwapLong and >>> moved the addr() call in the mutex methods of MemoryAccess. Thank you >>> for catching that! >>> >>>> >>>> vmSymbols.cpp: >>>> >>>> *) {get|put}Address_raw intrinsics used to be conditionalized under >>>> UseUnalignedAccesses. Baffles me why, because the old native code in >>>> Unsafe_{Get|Set}NativeAddress/unsafe.cpp would seem to fail with >>>> misaligned addresses. I wonder if the intent was to never fail, and >>>> then >>>> we should really use Unsafe.{get|put}Unaligned in new Unsafe.java >>>> {get|set}Address to dodge misalign faults? >>> >>> I also failed to see what the conditional intrinsification is trying to >>> achieve given that the native code does nothing special for the >>> unaligned case. Unless I'm missing something the proposed change makes >>> it no worse, and will potentially improve performance a tad on the >>> pickier platforms. If anything we may want to consider introducing >>> methods for getAddressUnaligned and putAddressUnaligned as a separate >>> change. >>> >>>> library_call.cpp: >>>> >>>> *) What is the point for doing this check: >>>> >>>> 2372 if (_gvn.type(base)->isa_ptr() != TypePtr::NULL_PTR) { >>>> 2373 heap_base_oop = base; >>>> 2374 } >>>> >>>> In old code heap_base_oop != top() only for heap ptrs, even if base is >>>> NULL. In new code, if base is NULL, then heap_base_oop is top(). It >>>> would seem that new code is better, because it clearly separates heap >>>> vs. native accesses, and it does not seem to break anything downstream. >>>> Was that the intent? >>> >>> Those three lines were actually donated to my by John Rose, so I'm >>> hoping he or somebody else more knowledgeable in C2 can provide some >>> helpful comments on the correctness and validity of that specific >>> change. >>> >>> >>> I also changed the normalize() methods to be private in the MemoryAccess >>> class, and made the MemoryAccess class a StackObj. >>> >>> New webrev(s) here: >>> >>> jdk: >>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/jdk/webrev/ >>> hotspot: >>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/hotspot/webrev/ >>> >> >> src/share/vm/prims/unsafe.cpp >> >> I think this is a bit over-generalized: >> >> 254 template >> 255 void put_mutex(T x) { >> 256 GuardUnsafeAccess guard(_thread, _obj); >> 257 >> 258 MutexLockerEx mu(UnsafeJlong_lock, >> Mutex::_no_safepoint_check_flag); >> 259 >> 260 T* p = (T*)addr(); >> 261 >> 262 Atomic::store(normalize(x), p); >> 263 } >> >> The UnsafeJlong lock is, as the name suggests, only intended for use >> with jlongs - we have no need of it for any other type. I don't think >> this needs to be a template method. > > Good point. I guess the method could be made to take the mutex as an > argument, or internally decide which mutex to use depending on the type, > but given that really only is used for jlong right now I made the > function jlong specific (without the template argument). > >> As noted before the lock could taken after calculating the address - >> to shorten the critical section. >> >> If you take care to ensure no uses of MemoryAccess transitively can >> hit a safepoint then you could store the oop directly rather than the >> jobject. That would avoid multiple calls to JNIHandles::resolve (in >> the GuardUnsafeAccess and addr() function). > Since the resolve call is really just dereferencing a pointer and the > data should already be in the L1 cache I'm not sure this is worth > optimizing a whole lot more, but if we really think it will actually > make a difference we can definitely store the raw oop instead. I chose > to leave it the way it is for now. > >> >> 405 if (VM_Version::supports_cx8()) { >> 406 return MemoryAccess(thread, obj, offset).get_volatile(); >> >> 407 } else { >> 408 return MemoryAccess(thread, obj, offset).get_mutex(); >> >> You could internalize the supports_cx8 check and the use of locking >> inside MemoryAccess.get_volatile rather than having >> get_volatile and get_mutex. If you prefer to keep it this way then >> get_volatile_with_mutex would be a more appropriate name (and it >> doesn't need to be a template method as I said before). > > That's good, I like it! In the interest of drawing a line though I'm > going to choose to leave that for a future enhancement. > > Cheers, > Mikael > >> >> Can't comment on the rest of the compiler related stuff too much, but >> I didn't see anything obviously odd looking. >> >> Thanks, >> David >> >>> >>> Incremental from webrev.01: >>> >>> jdk: N/A (no changes) >>> hotspot: >>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02.incr/hotspot/webrev/ >>> >>> >>> >>> Cheers, >>> Mikael >>> >>>> >>>> Thanks, >>>> -Aleksey >>>> >>>> >>> > From vladimir.x.ivanov at oracle.com Thu May 5 22:12:56 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 May 2016 01:12:56 +0300 Subject: [9] RFR (XS): 8155635: C2: opaque unsafe access triggers an assert In-Reply-To: <572B9E8D.7090405@oracle.com> References: <572B9591.4040505@oracle.com> <572B9E8D.7090405@oracle.com> Message-ID: <572BC568.3040400@oracle.com> Thanks, Vladimir. > Looks good. What actual alias type in such case? Both adr_type & alias_type are: java/lang/Object+12 * [narrow] And LibraryCallKit::classify_unsafe_addr() returns Type::OopPtr for it. Best regards, Vladimir Ivanov > > Thanks, > Vladimir > > On 5/5/16 11:48 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8155781/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8155781 >> >> The following code hits an assert in >> LibraryCallKit::inline_unsafe_access() during compilation of the >> following code: >> >> int test(Object o) { >> return UNSAFE.getInt(o, F_OFFSET); >> } >> >> It baffles the compiler since such shape can be used to access both >> on-heap and off-heap memory (due to double-register addressing mode). >> >> The proposed fix is to convert the asserts into guards which revert to >> native calls in such cases. >> >> Testing: JPRT, RBT (hs-tier0-comp). >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From tomasz.wojtowicz at intel.com Thu May 5 22:26:13 2016 From: tomasz.wojtowicz at intel.com (Wojtowicz, Tomasz) Date: Thu, 5 May 2016 22:26:13 +0000 Subject: RFR (M): 8154974: AVX-512 equipped inflate, has_negatives & compress intrinsics In-Reply-To: <572A815A.7040808@oracle.com> References: <3616187E21868C40AD1B36D41D29F4C1520B04B1@FMSMSX106.amr.corp.intel.com> <572A7E79.6070401@oracle.com> <572A815A.7040808@oracle.com> Message-ID: <3616187E21868C40AD1B36D41D29F4C1520B1529@FMSMSX106.amr.corp.intel.com> Vladimir, Vivek uploaded for me the newest version which includes appropriate modification for clean integration http://cr.openjdk.java.net/~vdeshpande/8154974/webrev.02/ -- Tomek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, May 4, 2016 4:10 PM To: Wojtowicz, Tomasz ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (M): 8154974: AVX-512 equipped inflate, has_negatives & compress intrinsics I can't apply changes to latest hs-comp/hotspot. Please, update. Vladimir On 5/4/16 3:58 PM, Vladimir Kozlov wrote: > Looks good. What testing was done? > > Thanks, > Vladimir > > On 4/29/16 4:57 PM, Wojtowicz, Tomasz wrote: >> I would like to contribute following change: >> >> Review details >> >> Review Title: AVX-512 equipped inflate, has_negatives & compress >> intrinsics >> >> Review ID: #8154974 >> >> Diff: http://cr.openjdk.java.net/~vdeshpande/8154974/webrev.00/ >> >> Description: 512 bit wide upgrades for previously 128-256 wide >> implementations using mask registers for tail computations. >> >> Link: https://bugs.openjdk.java.net/browse/JDK-8154974 >> >> Author: Tomasz, Wojtowicz >> >> -- >> >> Thank you, >> >> Tomek >> From vladimir.x.ivanov at oracle.com Thu May 5 23:03:01 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 May 2016 02:03:01 +0300 Subject: [9] RFR (XS): 8155635: C2: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr In-Reply-To: <572BA252.60003@oracle.com> References: <5723EA35.5020809@oracle.com> <99d03b20-bdb4-5948-89aa-eced57b279af@oracle.com> <5723FB50.6050301@oracle.com> <57240AB4.8040406@oracle.com> <572B9A9E.8080805@oracle.com> <572BA252.60003@oracle.com> Message-ID: <572BD125.3020503@oracle.com> On 5/5/16 10:43 PM, Vladimir Kozlov wrote: > On 5/5/16 12:10 PM, Vladimir Ivanov wrote: >>>>> >>>>> Can you explain why we have such graph shape where we access memory >>>>> after a merge point and on one merged path has NULL as pointer to >>>>> object. There should be NULL check after merge before memory access in >>>>> such case. >>>> It's not necessarily a normal oop pointer. Double-register addressing >>>> mode is the source of such shapes. Consider the following example: >>>> >>>> Object o = (flag ? INSTANCE : null); >>>> long off = (flag ? F_OFFSET : ADDR); >>>> UNSAFE.getLong(o, off); >>> >>> I think for this graph shape C2 type system gave up and drops type to >>> general Ptr::BOTTOM because it does not know that 'off' can be address >>> and not a normal offset on dead path where base is NULL. We usually do: >>> >>> long l = flag ? o.field : UNSAFE.getLong(addr); >>> And for UNSAFE.getLong(addr) we generate Raw pointer address >>> (make_unsafe_address()). >>> >>> What I am saying is that C2 treat long value as address only when it was >>> used as direct parameter for unsafe. See >>> LibraryCallKit::classify_unsafe_addr(). >> >> The type I see during compilation for "opaque" access (mixed on-heap & >> off-heap) is the following: >> >> Oop:UnsafeAddP:exact+any * [narrow] >> >> LibraryCallKit::classify_unsafe_addr() produces Type::AnyPtr for such >> shapes. But it is used in LibraryCallKit::make_unsafe_address() just >> to decide on base value: > > MAy be classify_unsafe_addr() should produce RawPtr type in such case. > ... >> >>> Who produces ADDR? May be we can't set flag to indicate that it is RAW >>> address. >> >> I don't see how we can achieve that. It's just a long constant (or >> value) which represents an absolute address at runtime: >> >> static final long addr = UNSAFE.allocateMemory(10); > > Yes, flag will not work. But we access such addr only through UNSAFE > api. So we should be able to produce RAW type for it at that point. Sometimes we can. But my point is it's not always possible to distinguish between on-heap and off-heap accesses at compile time. Ideally it should be Type::AnyPtr. And it seems to me it's the right type for such broad access. The question is how to keep other parts of the compiler happy. Considering classify_unsafe_addr() returns Type::OopPtr for NULL+smallOffset, maybe AddPNode::Value should also produce a type with Type::OopPtr base? It will make alias analysis happy for the particular case that is failing (NULL+12). But it will not help with generic accesses produced in double-addressing mode. IMO the compiler still has to be able to convert AnyPtr to RawPtr/OopPtr depending on circumstances. Though we can limit such conversions only for unsafe accesses (AddPNode::unsafe?). Best regards, Vladimir Ivanov > > Thanks, > Vladimir > >> >>> We should discuss it with John who is *the* expert in this. >> >> John, what are your thoughts about that? >> >> Best regards, >> Vladimir Ivanov >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> is translated into: >>>> >>>> LoadL mem (AddP (Phi #NULL #NonNull) off) >>>> >>>> If such AddP is split through the Phi, it turns into (AddP #NULL #NULL >>>> off) and (AddP #NonNull #NonNull off). The former is untyped and >>>> causes problems later. >>>> >>>> What I can't replicate is how X-shaped control flow eligible for >>>> SplitIf transformation is produced. >>>> >>>> In the failing case, initial null & exact type checks of an oop local >>>> (on OSR entry) merge into redundant X-shaped block. Unsafe accesses >>>> uses the local as a base later. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>> >>>>> On 4/29/16 4:11 PM, Vladimir Ivanov wrote: >>>>>> http://cr.openjdk.java.net/~vlivanov/8155635/webrev.00/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8155635 >>>>>> >>>>>> SplitIf transformation can produce untyped pointers when slitting >>>>>> AddP >>>>>> nodes for unsafe accesses through a Phi which >>>>>> merges non-null & null values: >>>>>> AddP ... (Phi (ConP #NULL) (CheckCastPP Oop:...:NotNull)) >>>>>> >>>>>> Proposed fix is to enable oop pointer to raw pointer conversion for >>>>>> absolute addresses. >>>>>> >>>>>> I also experimented with blocking SplitIf transformation is such >>>>>> cases, but the transformation seems viable and >>>>>> considerably simplifies the graph: X-shaped control flow is untangled >>>>>> by eliminating redundant and the transformation >>>>>> sharpens types on both branches. >>>>>> >>>>>> I checked specifically how Phi merges raw & oop pointers after the >>>>>> split and it works fine. >>>>>> >>>>>> Testing: failing test, JPRT, RBT (hs-tier0-comp.js). >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> PS: though AddP (Phi #NULL #NotNull) shape is common, I wasn't >>>>>> able to >>>>>> write a simplified test case which triggers >>>>>> SplitIf transformation. From vladimir.kozlov at oracle.com Thu May 5 23:40:34 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 5 May 2016 16:40:34 -0700 Subject: [9] RFR (XS): 8155635: C2: opaque unsafe access triggers an assert In-Reply-To: <572BC568.3040400@oracle.com> References: <572B9591.4040505@oracle.com> <572B9E8D.7090405@oracle.com> <572BC568.3040400@oracle.com> Message-ID: <572BD9F2.30408@oracle.com> Thank you for info. Will this fix cause performance issue? It looks like common case for me. Thanks, Vladimir K On 5/5/16 3:12 PM, Vladimir Ivanov wrote: > Thanks, Vladimir. > >> Looks good. What actual alias type in such case? > > Both adr_type & alias_type are: > > java/lang/Object+12 * [narrow] > > And LibraryCallKit::classify_unsafe_addr() returns Type::OopPtr for it. > > Best regards, > Vladimir Ivanov >> >> Thanks, >> Vladimir >> >> On 5/5/16 11:48 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8155781/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8155781 >>> >>> The following code hits an assert in >>> LibraryCallKit::inline_unsafe_access() during compilation of the >>> following code: >>> >>> int test(Object o) { >>> return UNSAFE.getInt(o, F_OFFSET); >>> } >>> >>> It baffles the compiler since such shape can be used to access both >>> on-heap and off-heap memory (due to double-register addressing mode). >>> >>> The proposed fix is to convert the asserts into guards which revert to >>> native calls in such cases. >>> >>> Testing: JPRT, RBT (hs-tier0-comp). >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri May 6 00:00:50 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 May 2016 03:00:50 +0300 Subject: [9] RFR (XS): 8155635: C2: opaque unsafe access triggers an assert In-Reply-To: <572BD9F2.30408@oracle.com> References: <572B9591.4040505@oracle.com> <572B9E8D.7090405@oracle.com> <572BC568.3040400@oracle.com> <572BD9F2.30408@oracle.com> Message-ID: <572BDEB2.1030907@oracle.com> Yes, it can. But I don't think it's common. Otherwise, we would hit the assert much earlier (and not with a focused test case). Broad on-heap/off-heap accesses usually end up as TypeRawPtr::BOTTOM/TypeOopPtr::BOTTOM. I planned to investigate removal of the check separately. Best regards, Vladimir Ivanov On 5/6/16 2:40 AM, Vladimir Kozlov wrote: > Thank you for info. Will this fix cause performance issue? It looks like > common case for me. > > Thanks, > Vladimir K > > On 5/5/16 3:12 PM, Vladimir Ivanov wrote: >> Thanks, Vladimir. >> >>> Looks good. What actual alias type in such case? >> >> Both adr_type & alias_type are: >> >> java/lang/Object+12 * [narrow] >> >> And LibraryCallKit::classify_unsafe_addr() returns Type::OopPtr for it. >> >> Best regards, >> Vladimir Ivanov >>> >>> Thanks, >>> Vladimir >>> >>> On 5/5/16 11:48 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8155781/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8155781 >>>> >>>> The following code hits an assert in >>>> LibraryCallKit::inline_unsafe_access() during compilation of the >>>> following code: >>>> >>>> int test(Object o) { >>>> return UNSAFE.getInt(o, F_OFFSET); >>>> } >>>> >>>> It baffles the compiler since such shape can be used to access both >>>> on-heap and off-heap memory (due to double-register addressing mode). >>>> >>>> The proposed fix is to convert the asserts into guards which revert to >>>> native calls in such cases. >>>> >>>> Testing: JPRT, RBT (hs-tier0-comp). >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov From vladimir.kozlov at oracle.com Fri May 6 00:14:29 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 5 May 2016 17:14:29 -0700 Subject: RFR(M): 8154826: AArch64: take better advantage of base + shifted offset addressing mode In-Reply-To: <5729A6D9.3010606@redhat.com> References: <57188E03.5070303@redhat.com> <571E20BD.3030907@redhat.com> <5729A6D9.3010606@redhat.com> Message-ID: <572BE1E5.1040206@oracle.com> You did not remove Matcher::clone_shift_expressions variable initialization from all .ad files. Changes look correct - you cloned shared code into .ad files and make code platform specific. But duplicated code will increase maintenance cost. Can you leave code for clone_shift_expressions=false case (same code on several platforms) in matcher.cpp? Thanks, Vladimir On 5/4/16 12:38 AM, Roland Westrelin wrote: > Anyone for a review of this? It's aarch64 specific but has some shared > code changes. > > Roland. > > > On 04/25/2016 03:50 PM, Roland Westrelin wrote: >> >> >> On 04/21/2016 10:23 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8154826/webrev.00/ >>> >>> The aarch64 port implicitly transforms: >>> (AddP base (AddP base address (LShiftL index con)) offset) >>> into: >>> (AddP base (AddP base offset) (LShiftL index con)) >>> in the ad file to embed the shift (and possibly and i2l conversion) into >>> the addressing mode of a memory operation. Exposing that transformation >>> in the ideal graph allows: >>> >>> - (AddP base offset) to be scheduled (for instance outside a loop) >>> - multiple identical (AddP base offset) to be commoned >>> - (LShiftL index con) to be cloned during matching so that each memory >>> access has its own >> >> Further testing revealed some problems with the previous change so here >> is a new webrev: >> >> http://cr.openjdk.java.net/~roland/8154826/webrev.01/ >> >> Memory access instructions only accept a shift that matches the size of >> the data being accessed (i.e. 2 for a 4 byte load). It's not always the >> case that address expressions produced by c2 follow that constraint. As >> expected, tt's very rare that it doesn't and seem to occur only with >> unsafe. I added a predicate that skips the transformation of the address >> subtree at the end of the optimization passes and prevent matching of >> the address subtree if the constraint is not met for one use. As this is >> uncommon, that seems good enough. >> >> Roland. >> From vladimir.kozlov at oracle.com Fri May 6 00:39:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 5 May 2016 17:39:05 -0700 Subject: [9] RFR (XS): 8155635: C2: opaque unsafe access triggers an assert In-Reply-To: <572BDEB2.1030907@oracle.com> References: <572B9591.4040505@oracle.com> <572B9E8D.7090405@oracle.com> <572BC568.3040400@oracle.com> <572BD9F2.30408@oracle.com> <572BDEB2.1030907@oracle.com> Message-ID: <572BE7A9.8090909@oracle.com> Thanks. Consider it is reviewed. Vladimir K On 5/5/16 5:00 PM, Vladimir Ivanov wrote: > Yes, it can. But I don't think it's common. Otherwise, we would hit the assert much earlier (and not with a focused test case). > > Broad on-heap/off-heap accesses usually end up as TypeRawPtr::BOTTOM/TypeOopPtr::BOTTOM. > > I planned to investigate removal of the check separately. > > Best regards, > Vladimir Ivanov > > On 5/6/16 2:40 AM, Vladimir Kozlov wrote: >> Thank you for info. Will this fix cause performance issue? It looks like >> common case for me. >> >> Thanks, >> Vladimir K >> >> On 5/5/16 3:12 PM, Vladimir Ivanov wrote: >>> Thanks, Vladimir. >>> >>>> Looks good. What actual alias type in such case? >>> >>> Both adr_type & alias_type are: >>> >>> java/lang/Object+12 * [narrow] >>> >>> And LibraryCallKit::classify_unsafe_addr() returns Type::OopPtr for it. >>> >>> Best regards, >>> Vladimir Ivanov >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 5/5/16 11:48 AM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8155781/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8155781 >>>>> >>>>> The following code hits an assert in >>>>> LibraryCallKit::inline_unsafe_access() during compilation of the >>>>> following code: >>>>> >>>>> int test(Object o) { >>>>> return UNSAFE.getInt(o, F_OFFSET); >>>>> } >>>>> >>>>> It baffles the compiler since such shape can be used to access both >>>>> on-heap and off-heap memory (due to double-register addressing mode). >>>>> >>>>> The proposed fix is to convert the asserts into guards which revert to >>>>> native calls in such cases. >>>>> >>>>> Testing: JPRT, RBT (hs-tier0-comp). >>>>> >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov From vladimir.kozlov at oracle.com Fri May 6 00:44:04 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 5 May 2016 17:44:04 -0700 Subject: RFR (M): 8154974: AVX-512 equipped inflate, has_negatives & compress intrinsics In-Reply-To: <3616187E21868C40AD1B36D41D29F4C1520B1529@FMSMSX106.amr.corp.intel.com> References: <3616187E21868C40AD1B36D41D29F4C1520B04B1@FMSMSX106.amr.corp.intel.com> <572A7E79.6070401@oracle.com> <572A815A.7040808@oracle.com> <3616187E21868C40AD1B36D41D29F4C1520B1529@FMSMSX106.amr.corp.intel.com> Message-ID: <572BE8D4.80701@oracle.com> Submitted for testing (build passed). Thanks, Vladimir On 5/5/16 3:26 PM, Wojtowicz, Tomasz wrote: > Vladimir, > Vivek uploaded for me the newest version which includes appropriate modification for clean integration > http://cr.openjdk.java.net/~vdeshpande/8154974/webrev.02/ > > -- > Tomek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, May 4, 2016 4:10 PM > To: Wojtowicz, Tomasz ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (M): 8154974: AVX-512 equipped inflate, has_negatives & compress intrinsics > > I can't apply changes to latest hs-comp/hotspot. Please, update. > > Vladimir > > On 5/4/16 3:58 PM, Vladimir Kozlov wrote: >> Looks good. What testing was done? >> >> Thanks, >> Vladimir >> >> On 4/29/16 4:57 PM, Wojtowicz, Tomasz wrote: >>> I would like to contribute following change: >>> >>> Review details >>> >>> Review Title: AVX-512 equipped inflate, has_negatives & compress >>> intrinsics >>> >>> Review ID: #8154974 >>> >>> Diff: http://cr.openjdk.java.net/~vdeshpande/8154974/webrev.00/ >>> >>> Description: 512 bit wide upgrades for previously 128-256 wide >>> implementations using mask registers for tail computations. >>> >>> Link: https://bugs.openjdk.java.net/browse/JDK-8154974 >>> >>> Author: Tomasz, Wojtowicz >>> >>> -- >>> >>> Thank you, >>> >>> Tomek >>> From tom.rodriguez at oracle.com Fri May 6 04:22:07 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 5 May 2016 21:22:07 -0700 Subject: RFR 8156178: [JVMCI] expose StubRoutines trig functions Message-ID: <4C9AA2D4-303C-44E5-A99B-B53DAE387E79@oracle.com> http://cr.openjdk.java.net/~never/8156178/webrev JVMCI should expose the StubRoutines versions of the trig functions when they are available. Tested with graal Math tests. tom From vladimir.kozlov at oracle.com Fri May 6 04:51:31 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 5 May 2016 21:51:31 -0700 Subject: RFR 8156178: [JVMCI] expose StubRoutines trig functions In-Reply-To: <4C9AA2D4-303C-44E5-A99B-B53DAE387E79@oracle.com> References: <4C9AA2D4-303C-44E5-A99B-B53DAE387E79@oracle.com> Message-ID: <3b4d8bd5-d222-8542-18cb-14c46eb934d6@oracle.com> Looks good. Thanks, Vladimir On 5/5/16 9:22 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8156178/webrev > > JVMCI should expose the StubRoutines versions of the trig functions when they are available. Tested with graal Math tests. > > tom > From jamsheed.c.m at oracle.com Fri May 6 06:11:30 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 6 May 2016 11:41:30 +0530 Subject: RFR: 8156131: C2: MachProj dumps data on tty w/ -XX:+WizardMode Message-ID: <572C3592.80705@oracle.com> Hi, Request for review a trivial change. +WizardMode dont take a stream input. as its very small change sending diff. diff --git a/src/share/vm/opto/machnode.cpp b/src/share/vm/opto/machnode.cpp --- a/src/share/vm/opto/machnode.cpp +++ b/src/share/vm/opto/machnode.cpp @@ -600,8 +600,8 @@ void MachProjNode::dump_spec(outputStream *st) const { ProjNode::dump_spec(st); switch (_ideal_reg) { - case unmatched_proj: st->print("/unmatched"); break; - case fat_proj: st->print("/fat"); if (WizardMode) _rout.dump(); break; + case unmatched_proj: st->print("/unmatched"); break; + case fat_proj: st->print("/fat"); if (WizardMode) _rout.dump(st); break; } } #endif Best Regards, Jamsheed -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Fri May 6 06:20:52 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 6 May 2016 11:50:52 +0530 Subject: RFR: 8150016: small typo in ciReplay code Message-ID: <572C37C4.9090306@oracle.com> Hi Request for review of a trivial change. bug id : https://bugs.openjdk.java.net/browse/JDK-8150016 webrev: http://cr.openjdk.java.net/~jcm/8150016/webrev.00/ Best Regards, Jamsheed From goetz.lindenmaier at sap.com Fri May 6 08:01:01 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 May 2016 08:01:01 +0000 Subject: RFR(M): 8140594: Various minor code improvements (compiler) Message-ID: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> Hi, I did a final Coverity run on the jdk9 sources, and would like to fix the findings detailed below. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.00/index.html Best regards, Goetz. os_linux.cpp - Buffer not null terminated - size of pointer passed to jio_snprintf() os_linux_x86.cpp - wrong size passed, scaled automatically by C compiler. dfa.cpp/formssel./cpp - no real issues as this is a tool, but nevertheless... c1_LinearScan.cpp - Access with negative index if called with any_reg - Coverity doesn't grok that two calls to base_counter(i) result in same value. ciMethodBlocks.cpp - Out of bounds access classFileParser.cpp - Don't access array at BAD_ALLOCATION_TYPE, oob. - CHECK macro results in two statements, second is not in if body. classLoader.cpp - jio_snprintf does null termination. But it might return -1 if truncated, in this case array access at -1. systemDictionary.cpp - avoid %s in message text. compileBroker.cpp -_last_method_compiled is an array, not a pointer. compileLog.cpp - buffer not null terminated disassembler.cpp - lib_offset might be -1. logTagSet.cpp - possible buffer overrun constantPool.cpp - flagts not initialized generateOopMap.cpp - Remaining fields not initialized. block.cpp - assertion assigns instead of comparing. callnode.cpp -_bci not initialized. graphKit.cpp - assertion assings instead of comparing matcher.cpp - find_receiver might return any_reg relocator.cpp - delta might be -4 ... assert returns. -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri May 6 08:40:28 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 May 2016 08:40:28 +0000 Subject: RFR(XS): 8156190: [ppc] Fix build after "8151268: Wire up the x86 _vectorizedMismatch stub routine in C1" Message-ID: <7ddb567c248947769809ddb03ea9711f@DEWDFE13DE09.global.corp.sap> Hi, Please review this small syntax fix on ppc: http://cr.openjdk.java.net/~goetz/wr16/8156190-ppcC1build/webrev.00/ Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.schatz at oracle.com Fri May 6 09:18:51 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Fri, 6 May 2016 11:18:51 +0200 Subject: RFR(S): 8156025: [JVMCI] make HotSpotResolvedObjectTypeImpl.createField non-public In-Reply-To: References: <5729FDB9.2080205@oracle.com> Message-ID: <572C617B.8060204@oracle.com> On 05/04/2016 09:20 PM, Christian Thalinger wrote: >> On May 4, 2016, at 3:48 AM, Roland Schatz wrote: >> >> Hi, >> >> Please review: >> http://cr.openjdk.java.net/~rschatz/JDK-8156025/webrev.00/hotspot.changeset >> https://bugs.openjdk.java.net/browse/JDK-8156025 >> >> This method is used only internally, it should never have been public. > Looks good. All JVMCI tests pass? At least no new failures, as far as I can tell. Looks like quite a few are failing anyway on the current tip. > Test results: passed: 43; failed: 26; error: 5 Or am I doing something wrong running the test? - Roland From rwestrel at redhat.com Fri May 6 09:28:13 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 6 May 2016 11:28:13 +0200 Subject: RFR(S): 8154943: AArch64: redundant address computation instructions with vectorization In-Reply-To: <5729A682.4030407@redhat.com> References: <572267D5.8020605@oracle.com> <57238278.5030607@redhat.com> <71b64964-0682-2deb-c0d4-0102d7a8a939@oracle.com> <5729A682.4030407@redhat.com> Message-ID: <572C63AD.5000801@redhat.com> Thanks for pushing this, Vladimir! Roland. On 05/04/2016 09:36 AM, Roland Westrelin wrote: > Thanks for the review, Vladimir. Can someone sponsor this? Here is a > changeset ready to be imported: > > http://cr.openjdk.java.net/~roland/8154943/8154943.patch > > Roland. > > On 04/29/2016 06:06 PM, Vladimir Kozlov wrote: >> Yes, this looks good. >> >> Thanks, >> Vladimir >> >> On 4/29/16 8:49 AM, Roland Westrelin wrote: >>>> node.cpp change is good. >>>> >>>> compile.cpp I understand when you replace "similar" (same in(1)) node >>>> with it but it is not clear that you also processing users (whole >>>> following chain) to remove similar nodes. Add comment. >>>> I think the check "!(k->Opcode() == Op_ConvI2L || ... " (and use >>>> 'continue' instead of 'break') should be done when you push a node on >>>> the list wq.push(u). >>> >>> Thanks for the review, Vladimir. What about this? >>> >>> http://cr.openjdk.java.net/~roland/8154943/webrev.01/ >>> >>> Roland. >>> From doug.simon at oracle.com Fri May 6 10:17:25 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 6 May 2016 12:17:25 +0200 Subject: RFR: 8152311: allow JVMCI compiler to change the compilation policy for a method In-Reply-To: <572BC184.5060309@oracle.com> References: <2399DAF1-A2F2-4B94-A5F6-426DB8D7A35E@oracle.com> <572B8BC3.5010509@oracle.com> <5E0388C7-DA54-4869-91BD-F12CECFF9C00@oracle.com> <572BC184.5060309@oracle.com> Message-ID: <9F9452D1-37BA-4217-AEBD-610FA307D8EB@oracle.com> > On 05 May 2016, at 23:56, Vladimir Kozlov wrote: > > On 5/5/16 2:14 PM, Doug Simon wrote: >> >>> On 05 May 2016, at 20:06, Vladimir Kozlov wrote: >>> >>> I looked on VM changes. You put #include under #if INCLUDE_JVMCI but call to JVMCIRuntime::adjust_comp_level() method are guarded only by flag. Some compilers may complain. >> >> Ok, I added the missing #if INCLUDE_JVMCI guards. Are there regular test builds with INCLUDE_JVMCI=0 that would have caught this? > > Try to use JPRT test run (-stree .). It will build on all platforms and some have INCLUDE_JVMCI = 0. > >> >>> In thread.hpp is there a reason to use several bool fields instead of one field for flags? >> >> Probably didn?t seem worth it when there were only 2 bool fields. Now that there will be three, should I convert to using a flags field? > > Yes please use flags field (after int field to get more compact data). I've filed this as a separate bug (https://bugs.openjdk.java.net/browse/JDK-8156206) as it?s a somewhat larger change given that at least one of these fields is accessed from Java code and so we need to now expose both the flags field and flags constant via HotSpotVMConfig and change the logic to do bit twiddling instead of a simple byte filled update. For 8152311, I?ve made the bool fields adjacent now. -Doug > > Thanks, > Vladimir > >> >> Thanks for the review. >> >> -Doug >> >>> Thanks, >>> Vladimir >>> >>> On 5/5/16 5:39 AM, Doug Simon wrote: >>>> Please read the bug for a full description of this proposed change. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8152311 >>>> http://cr.openjdk.java.net/~dnsimon/8152311/ >>>> >>>> -Doug >>>> >> From rwestrel at redhat.com Fri May 6 10:18:28 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 6 May 2016 12:18:28 +0200 Subject: RFR(M): 8154826: AArch64: take better advantage of base + shifted offset addressing mode In-Reply-To: <572BE1E5.1040206@oracle.com> References: <57188E03.5070303@redhat.com> <571E20BD.3030907@redhat.com> <5729A6D9.3010606@redhat.com> <572BE1E5.1040206@oracle.com> Message-ID: <572C6F74.1030907@redhat.com> Thanks for looking at this, Vladimir. > You did not remove Matcher::clone_shift_expressions variable > initialization from all .ad files. > > Changes look correct - you cloned shared code into .ad files and make > code platform specific. > But duplicated code will increase maintenance cost. Can you leave code > for clone_shift_expressions=false case (same code on several platforms) > in matcher.cpp? What about this? http://cr.openjdk.java.net/~roland/8154826/webrev.02/ Roland. From vladimir.x.ivanov at oracle.com Fri May 6 10:41:26 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 May 2016 13:41:26 +0300 Subject: RFR: 8156131: C2: MachProj dumps data on tty w/ -XX:+WizardMode In-Reply-To: <572C3592.80705@oracle.com> References: <572C3592.80705@oracle.com> Message-ID: <572C74D6.6@oracle.com> Reviewed. I'll push it. Best regards, Vladimir Ivanov On 5/6/16 9:11 AM, Jamsheed C m wrote: > Hi, > > Request for review a trivial change. > > +WizardMode dont take a stream input. as its very small change sending diff. > > diff --git a/src/share/vm/opto/machnode.cpp b/src/share/vm/opto/machnode.cpp > --- a/src/share/vm/opto/machnode.cpp > +++ b/src/share/vm/opto/machnode.cpp > @@ -600,8 +600,8 @@ > void MachProjNode::dump_spec(outputStream *st) const { > ProjNode::dump_spec(st); > switch (_ideal_reg) { > - case unmatched_proj: st->print("/unmatched"); break; > - case fat_proj: st->print("/fat"); if (WizardMode) _rout.dump(); break; > + case unmatched_proj: st->print("/unmatched"); break; > + case fat_proj: st->print("/fat"); if (WizardMode) _rout.dump(st); break; > } > } > #endif > > Best Regards, > Jamsheed From stefan.karlsson at oracle.com Fri May 6 10:46:57 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 6 May 2016 12:46:57 +0200 Subject: RFR: 8155638: Resource allocated BitMaps are often cleared twice Message-ID: <572C7621.7000001@oracle.com> 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 May 6 10:56:12 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 6 May 2016 16:26:12 +0530 Subject: RFR: 8156126: LogCompilation: Dump additional info about deoptimization events Message-ID: <572C784C.9080104@oracle.com> Hi, bug id : https://bugs.openjdk.java.net/browse/JDK-8156126 webrev: http://cr.openjdk.java.net/~jcm/8156126/webrev.00/ Added more information to LogCompilation o/p for deoptimization events. Tested LogOptimization o/p with logc.jar Best Regards, Jamsheed From jamsheed.c.m at oracle.com Fri May 6 10:58:50 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 6 May 2016 16:28:50 +0530 Subject: RFR: 8156131: C2: MachProj dumps data on tty w/ -XX:+WizardMode In-Reply-To: <572C74D6.6@oracle.com> References: <572C3592.80705@oracle.com> <572C74D6.6@oracle.com> Message-ID: <572C78EA.2080509@oracle.com> Thank you Vladimir Ivanov! Best Regards, Jamsheed On 5/6/2016 4:11 PM, Vladimir Ivanov wrote: > Reviewed. I'll push it. > > Best regards, > Vladimir Ivanov > > On 5/6/16 9:11 AM, Jamsheed C m wrote: >> Hi, >> >> Request for review a trivial change. >> >> +WizardMode dont take a stream input. as its very small change >> sending diff. >> >> diff --git a/src/share/vm/opto/machnode.cpp >> b/src/share/vm/opto/machnode.cpp >> --- a/src/share/vm/opto/machnode.cpp >> +++ b/src/share/vm/opto/machnode.cpp >> @@ -600,8 +600,8 @@ >> void MachProjNode::dump_spec(outputStream *st) const { >> ProjNode::dump_spec(st); >> switch (_ideal_reg) { >> - case unmatched_proj: st->print("/unmatched"); break; >> - case fat_proj: st->print("/fat"); if (WizardMode) _rout.dump(); break; >> + case unmatched_proj: st->print("/unmatched"); break; >> + case fat_proj: st->print("/fat"); if (WizardMode) _rout.dump(st); >> break; >> } >> } >> #endif >> >> Best Regards, >> Jamsheed From vladimir.x.ivanov at oracle.com Fri May 6 11:02:26 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 May 2016 14:02:26 +0300 Subject: RFR: 8156126: LogCompilation: Dump additional info about deoptimization events In-Reply-To: <572C784C.9080104@oracle.com> References: <572C784C.9080104@oracle.com> Message-ID: <572C79C2.9010208@oracle.com> Reviewed. Best regards, Vladimir Ivanov On 5/6/16 1:56 PM, Jamsheed C m wrote: > Hi, > > bug id : https://bugs.openjdk.java.net/browse/JDK-8156126 > webrev: http://cr.openjdk.java.net/~jcm/8156126/webrev.00/ > > Added more information to LogCompilation o/p for deoptimization events. > > Tested LogOptimization o/p with logc.jar > > Best Regards, > Jamsheed > > From jamsheed.c.m at oracle.com Fri May 6 11:09:46 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 6 May 2016 16:39:46 +0530 Subject: RFR : 8156124: Update compiler/unsafe/UnsafeGetConstantField after JDK-8148518 is fixed Message-ID: <572C7B7A.1040509@oracle.com> Hi, Request for review a trivial change. bug id : https://bugs.openjdk.java.net/browse/JDK-8156124 webrev: http://cr.openjdk.java.net/~jcm/8156124/webrev.00/ As JDK-8148518 is fixed removing the checks/workaround. PIT result link is available in bug report. Best Regards, Jamsheed -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Fri May 6 11:12:38 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 6 May 2016 16:42:38 +0530 Subject: RFR: 8156126: LogCompilation: Dump additional info about deoptimization events In-Reply-To: <572C79C2.9010208@oracle.com> References: <572C784C.9080104@oracle.com> <572C79C2.9010208@oracle.com> Message-ID: <572C7C26.6090405@oracle.com> Thank you Vladimir Ivanov. Best Regards, Jamsheed On 5/6/2016 4:32 PM, Vladimir Ivanov wrote: > Reviewed. > > Best regards, > Vladimir Ivanov > > On 5/6/16 1:56 PM, Jamsheed C m wrote: >> Hi, >> >> bug id : https://bugs.openjdk.java.net/browse/JDK-8156126 >> webrev: http://cr.openjdk.java.net/~jcm/8156126/webrev.00/ >> >> Added more information to LogCompilation o/p for deoptimization events. >> >> Tested LogOptimization o/p with logc.jar >> >> Best Regards, >> Jamsheed >> >> From vladimir.x.ivanov at oracle.com Fri May 6 11:14:31 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 May 2016 14:14:31 +0300 Subject: RFR : 8156124: Update compiler/unsafe/UnsafeGetConstantField after JDK-8148518 is fixed In-Reply-To: <572C7B7A.1040509@oracle.com> References: <572C7B7A.1040509@oracle.com> Message-ID: <572C7C97.4090807@oracle.com> Reviewed. Best regards, Vladimir Ivanov On 5/6/16 2:09 PM, Jamsheed C m wrote: > Hi, > > Request for review a trivial change. > > bug id : https://bugs.openjdk.java.net/browse/JDK-8156124 > webrev: http://cr.openjdk.java.net/~jcm/8156124/webrev.00/ > > As JDK-8148518 is > fixed removing the checks/workaround. > > PIT result link is available in bug report. > > Best Regards, > Jamsheed > From jamsheed.c.m at oracle.com Fri May 6 11:21:24 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 6 May 2016 16:51:24 +0530 Subject: RFR: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted Message-ID: <572C7E34.60608@oracle.com> Hi, Request for review for an assert cleanup change. bug id : https://bugs.openjdk.java.net/browse/JDK-8144856 webrev: http://cr.openjdk.java.net/~jcm/8144856/webrev.00/ Best Regards, Jamsheed From roland.schatz at oracle.com Fri May 6 12:18:06 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Fri, 6 May 2016 14:18:06 +0200 Subject: RFR: 8156211: [JVMCI] ResolvedJava* interfaces should extend AnnotatedElement Message-ID: <572C8B7E.5020304@oracle.com> Please review this small jvmci change: http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8156211 This change was contributed by Vojin Jovanovic (cc'ed). Thanks, Roland From vladimir.x.ivanov at oracle.com Fri May 6 12:34:48 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 May 2016 15:34:48 +0300 Subject: RFR (XS) 8156068: Unsafe.{get|set}Opaque should be single copy atomic In-Reply-To: <572B99C4.5080808@oracle.com> References: <572B99C4.5080808@oracle.com> Message-ID: <572C8F68.9090408@oracle.com> Looks good. Best regards, Vladimir Ivanov On 5/5/16 10:06 PM, Aleksey Shipilev wrote: > Hi, > > Please review a tiny fix in C2 intrinsics that make > Unsafe.{get|set}Opaque single-copy atomic, as intended. These opaque > methods are supposed to act like std::atomic(..., memord_relaxed), that > is, do not induce ordering, but still provide access atomicity. > > Interpreter and C1 are delegating to volatile get/set, and so are atomic > already. C2 has a little bug that was introduced along with the initial > VarHandles change. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8156068 > > Webrev: > http://cr.openjdk.java.net/~shade/8156068/webrev.00/ > > Testing: jcstress atomicity test on 32-bit x86; RBT (hs-tier0-comp). > > Thanks, > -Aleksey > > From vladimir.x.ivanov at oracle.com Fri May 6 12:36:04 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 May 2016 15:36:04 +0300 Subject: RFR (S) 8155965: Unsafe.weakCompareAndSetVolatile entry points and intrinsics In-Reply-To: <572B9B96.60309@oracle.com> References: <572B9B96.60309@oracle.com> Message-ID: <572C8FB4.5050607@oracle.com> Looks good. Best regards, Vladimir Ivanov On 5/5/16 10:14 PM, Aleksey Shipilev wrote: > Hi, > > Please review this addition to Unsafe and C2 intrinsics, that adds > Unsafe.weakCompareAndSetVolatile family of entry points. This provides > the VM support for additional VarHandles access modes (see JDK-8154755). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8155965 > > Webrevs: > http://cr.openjdk.java.net/~shade/8155965/webrev.jdk.00/ > http://cr.openjdk.java.net/~shade/8155965/webrev.hs.00/ > > The bulk of changes is in tests. The actual change in compiler code is > just a few lines declaring a new weakCAS shape. > > Testing: Linux x86_64 tests: hotspot/compiler/unsafe; RBT (hs-tier0-comp). > > Thanks, > -Aleksey > From martin.doerr at sap.com Fri May 6 13:09:28 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 6 May 2016 13:09:28 +0000 Subject: RFR(XS): 8156190: [ppc] Fix build after "8151268: Wire up the x86 _vectorizedMismatch stub routine in C1" In-Reply-To: <7ddb567c248947769809ddb03ea9711f@DEWDFE13DE09.global.corp.sap> References: <7ddb567c248947769809ddb03ea9711f@DEWDFE13DE09.global.corp.sap> Message-ID: Hi G?tz, thanks for fixing this obvious copy&paste bug. The change is good. Best regards, Martin From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Freitag, 6. Mai 2016 10:40 To: hotspot compiler Subject: RFR(XS): 8156190: [ppc] Fix build after "8151268: Wire up the x86 _vectorizedMismatch stub routine in C1" Hi, Please review this small syntax fix on ppc: http://cr.openjdk.java.net/~goetz/wr16/8156190-ppcC1build/webrev.00/ Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Fri May 6 13:17:24 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 6 May 2016 18:47:24 +0530 Subject: RFR : 8156124: Update compiler/unsafe/UnsafeGetConstantField after JDK-8148518 is fixed In-Reply-To: <572C7C97.4090807@oracle.com> References: <572C7B7A.1040509@oracle.com> <572C7C97.4090807@oracle.com> Message-ID: <572C9964.1000503@oracle.com> Thankyou Vladimir Ivanov. Best Regards, Jamsheed On 5/6/2016 4:44 PM, Vladimir Ivanov wrote: > Reviewed. > > Best regards, > Vladimir Ivanov > > On 5/6/16 2:09 PM, Jamsheed C m wrote: >> Hi, >> >> Request for review a trivial change. >> >> bug id : https://bugs.openjdk.java.net/browse/JDK-8156124 >> webrev: http://cr.openjdk.java.net/~jcm/8156124/webrev.00/ >> >> As JDK-8148518 is >> fixed removing the checks/workaround. >> >> PIT result link is available in bug report. >> >> Best Regards, >> Jamsheed >> From goetz.lindenmaier at sap.com Fri May 6 14:03:36 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 May 2016 14:03:36 +0000 Subject: RFR(XS): 8156190: [ppc] Fix build after "8151268: Wire up the x86 _vectorizedMismatch stub routine in C1" In-Reply-To: References: <7ddb567c248947769809ddb03ea9711f@DEWDFE13DE09.global.corp.sap> Message-ID: Hi Martin, thanks for the review. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Freitag, 6. Mai 2016 15:09 > To: Lindenmaier, Goetz ; hotspot compiler > > Subject: RE: RFR(XS): 8156190: [ppc] Fix build after "8151268: Wire up the x86 > _vectorizedMismatch stub routine in C1" > > Hi G?tz, > > > > thanks for fixing this obvious copy&paste bug. The change is good. > > > > Best regards, > > Martin > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz > Sent: Freitag, 6. Mai 2016 10:40 > To: hotspot compiler > Subject: RFR(XS): 8156190: [ppc] Fix build after "8151268: Wire up the x86 > _vectorizedMismatch stub routine in C1" > > > > Hi, > > > > Please review this small syntax fix on ppc: > > http://cr.openjdk.java.net/~goetz/wr16/8156190-ppcC1build/webrev.00/ > > > > Best regards, > > Goetz. From dmitrij.pochepko at oracle.com Fri May 6 14:25:39 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 6 May 2016 17:25:39 +0300 Subject: RFR 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider Message-ID: <572CA963.3030906@oracle.com> Hi, please review patch for 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider A new tests were added for jdk.vm.ci.meta.MetaAccessProvider implementation. An existing TestMetaAccessProvider.java was used to add new tests. webrev: http://cr.openjdk.java.net/~dpochepk/8152343/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8152343 I've tested it on linux_x64. Thanks, Dmitrij From dmitrij.pochepko at oracle.com Fri May 6 14:38:52 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 6 May 2016 17:38:52 +0300 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider Message-ID: <572CAC7C.3040700@oracle.com> Hi, please review patch for 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider A new tests were added for MemoryAccessProvider implementation. This patch contains tests for all MemoryAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8152341 I've tested it on linux_x64 Thanks, Dmitrij From dmitrij.pochepko at oracle.com Fri May 6 14:44:24 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 6 May 2016 17:44:24 +0300 Subject: RFR: 8152342 - JVMCI test task: Unit tests for MethodHandleAccessProvider Message-ID: <572CADC8.4090004@oracle.com> Hi, please review patch for 8152342 - JVMCI test task: Unit tests for MethodHandleAccessProvider A new tests were added for MethodHandleAccessProvider implementation. This patch contains tests for all MethodHandleAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. MethodHandleAccessProviderData is used as testng data provider for MethodHandleAccessProviderTest. webrev: http://cr.openjdk.java.net/~dpochepk/8152342/webrev.01 CR: https://bugs.openjdk.java.net/browse/JDK-8152342 I've tested it on linux_x64 Thanks, Dmitrij From dmitrij.pochepko at oracle.com Fri May 6 14:59:22 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 6 May 2016 17:59:22 +0300 Subject: RFR(S): 8149463 - [jittester] rarely generates tests with compile error Message-ID: <572CB14A.8080009@oracle.com> Hi, please review fix for 8149463 - [jittester] rarely generates tests with compile error A reason for incorrect code generation was "removeSelf" method, which is called when IR tree is cut to meet constraints. This method is implemented in all loops to not remove node loop completely, but leave some of node content instead("header" and "initialization". In this specific order.) So, incorrect code was generated in case header code used some variable declared in initialization block, thus, leading to variable usage before declaration. So, this patch fixes this problem. Also, minor code improvement: instead of removing self(loop node), it's overwritten with "initialization" block and then a header content is added. webrev: http://cr.openjdk.java.net/~dpochepk/8149463/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8149463 I've tested this fix using linux_x64. Thanks, Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri May 6 15:53:36 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 6 May 2016 08:53:36 -0700 Subject: RFR(XS): 8156190: [ppc] Fix build after "8151268: Wire up the x86 _vectorizedMismatch stub routine in C1" In-Reply-To: <7ddb567c248947769809ddb03ea9711f@DEWDFE13DE09.global.corp.sap> References: <7ddb567c248947769809ddb03ea9711f@DEWDFE13DE09.global.corp.sap> Message-ID: <22059d9b-71a2-466f-cc0c-aa352f9c7f8f@oracle.com> Sorry about this mistake. Vladimir On 5/6/16 1:40 AM, Lindenmaier, Goetz wrote: > Hi, > > > > Please review this small syntax fix on ppc: > > http://cr.openjdk.java.net/~goetz/wr16/8156190-ppcC1build/webrev.00/ > > > > Best regards, > > Goetz. > From vladimir.kozlov at oracle.com Fri May 6 15:56:09 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 6 May 2016 08:56:09 -0700 Subject: RFR: 8152311: allow JVMCI compiler to change the compilation policy for a method In-Reply-To: <9F9452D1-37BA-4217-AEBD-610FA307D8EB@oracle.com> References: <2399DAF1-A2F2-4B94-A5F6-426DB8D7A35E@oracle.com> <572B8BC3.5010509@oracle.com> <5E0388C7-DA54-4869-91BD-F12CECFF9C00@oracle.com> <572BC184.5060309@oracle.com> <9F9452D1-37BA-4217-AEBD-610FA307D8EB@oracle.com> Message-ID: I agree with separate RFE. Thanks, Vladimir On 5/6/16 3:17 AM, Doug Simon wrote: > >> On 05 May 2016, at 23:56, Vladimir Kozlov wrote: >> >> On 5/5/16 2:14 PM, Doug Simon wrote: >>> >>>> On 05 May 2016, at 20:06, Vladimir Kozlov wrote: >>>> >>>> I looked on VM changes. You put #include under #if INCLUDE_JVMCI but call to JVMCIRuntime::adjust_comp_level() method are guarded only by flag. Some compilers may complain. >>> >>> Ok, I added the missing #if INCLUDE_JVMCI guards. Are there regular test builds with INCLUDE_JVMCI=0 that would have caught this? >> >> Try to use JPRT test run (-stree .). It will build on all platforms and some have INCLUDE_JVMCI = 0. >> >>> >>>> In thread.hpp is there a reason to use several bool fields instead of one field for flags? >>> >>> Probably didn?t seem worth it when there were only 2 bool fields. Now that there will be three, should I convert to using a flags field? >> >> Yes please use flags field (after int field to get more compact data). > > I've filed this as a separate bug (https://bugs.openjdk.java.net/browse/JDK-8156206) as it?s a somewhat larger change given that at least one of these fields is accessed from Java code and so we need to now expose both the flags field and flags constant via HotSpotVMConfig and change the logic to do bit twiddling instead of a simple byte filled update. > > For 8152311, I?ve made the bool fields adjacent now. > > -Doug > >> >> Thanks, >> Vladimir >> >>> >>> Thanks for the review. >>> >>> -Doug >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 5/5/16 5:39 AM, Doug Simon wrote: >>>>> Please read the bug for a full description of this proposed change. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8152311 >>>>> http://cr.openjdk.java.net/~dnsimon/8152311/ >>>>> >>>>> -Doug >>>>> >>> > From vladimir.kozlov at oracle.com Fri May 6 16:01:34 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 6 May 2016 09:01:34 -0700 Subject: RFR(M): 8154826: AArch64: take better advantage of base + shifted offset addressing mode In-Reply-To: <572C6F74.1030907@redhat.com> References: <57188E03.5070303@redhat.com> <571E20BD.3030907@redhat.com> <5729A6D9.3010606@redhat.com> <572BE1E5.1040206@oracle.com> <572C6F74.1030907@redhat.com> Message-ID: <8af6680d-e44e-ce5c-d9cc-e95c728b48a5@oracle.com> Yes, looks good. Closed changes will be simple now :) Roland, are you on hotspot-compiler-dev at openjdk.java.net list? Or I should CC to you for reviews? Thanks, Vladimir On 5/6/16 3:18 AM, Roland Westrelin wrote: > Thanks for looking at this, Vladimir. > >> You did not remove Matcher::clone_shift_expressions variable >> initialization from all .ad files. >> >> Changes look correct - you cloned shared code into .ad files and make >> code platform specific. >> But duplicated code will increase maintenance cost. Can you leave code >> for clone_shift_expressions=false case (same code on several platforms) >> in matcher.cpp? > > What about this? > > http://cr.openjdk.java.net/~roland/8154826/webrev.02/ > > Roland. > From paul.sandoz at oracle.com Fri May 6 16:16:22 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 6 May 2016 09:16:22 -0700 Subject: RFR(XS): 8156190: [ppc] Fix build after "8151268: Wire up the x86 _vectorizedMismatch stub routine in C1" In-Reply-To: <22059d9b-71a2-466f-cc0c-aa352f9c7f8f@oracle.com> References: <7ddb567c248947769809ddb03ea9711f@DEWDFE13DE09.global.corp.sap> <22059d9b-71a2-466f-cc0c-aa352f9c7f8f@oracle.com> Message-ID: > On 6 May 2016, at 08:53, Vladimir Kozlov wrote: > > Sorry about this mistake. > Oppps, that?s my bad, very sorry about that. 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 tom.rodriguez at oracle.com Fri May 6 16:43:25 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 6 May 2016 09:43:25 -0700 Subject: RFR 8156178: [JVMCI] expose StubRoutines trig functions In-Reply-To: <3b4d8bd5-d222-8542-18cb-14c46eb934d6@oracle.com> References: <4C9AA2D4-303C-44E5-A99B-B53DAE387E79@oracle.com> <3b4d8bd5-d222-8542-18cb-14c46eb934d6@oracle.com> Message-ID: <6A204A3E-19D3-4A3B-BD40-6FF27E4342F4@oracle.com> Thanks! tom > On May 5, 2016, at 9:51 PM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 5/5/16 9:22 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/8156178/webrev >> >> JVMCI should expose the StubRoutines versions of the trig functions when they are available. Tested with graal Math tests. >> >> tom >> From vladimir.kozlov at oracle.com Fri May 6 17:31:03 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 6 May 2016 10:31:03 -0700 Subject: RFR: 8150016: small typo in ciReplay code In-Reply-To: <572C37C4.9090306@oracle.com> References: <572C37C4.9090306@oracle.com> Message-ID: <2d50e277-569f-23a9-ca0b-56f95b26b3c9@oracle.com> Looks good. thanks, Vladimir On 5/5/16 11:20 PM, Jamsheed C m wrote: > Hi > > Request for review of a trivial change. > bug id : https://bugs.openjdk.java.net/browse/JDK-8150016 > webrev: http://cr.openjdk.java.net/~jcm/8150016/webrev.00/ > > Best Regards, > Jamsheed > > From rwestrel at redhat.com Fri May 6 18:57:40 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 06 May 2016 20:57:40 +0200 Subject: RFR(M): 8154826: AArch64: take better advantage of base + shifted offset addressing mode In-Reply-To: <8af6680d-e44e-ce5c-d9cc-e95c728b48a5@oracle.com> References: <57188E03.5070303@redhat.com> <571E20BD.3030907@redhat.com> <5729A6D9.3010606@redhat.com> <572BE1E5.1040206@oracle.com> <572C6F74.1030907@redhat.com> <8af6680d-e44e-ce5c-d9cc-e95c728b48a5@oracle.com> Message-ID: Thanks for the review. Here is a change that should import cleanly: http://cr.openjdk.java.net/~roland/8154826/8154826.patch > Yes, looks good. Closed changes will be simple now :) > > Roland, are you on hotspot-compiler-dev at openjdk.java.net list? Or I should CC to you for reviews? No CC needed. I'm on hotspot-compiler-dev at openjdk.java.net. Roland. From pavel.punegov at oracle.com Fri May 6 19:35:55 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Fri, 6 May 2016 22:35:55 +0300 Subject: RFR (S): 8150247: CompilerControl: LogCompilation testing In-Reply-To: References: Message-ID: <1F1FA86E-3224-4523-827B-8885C3F7C6C3@oracle.com> Hi, I have updated webrev to add @module to jtreg header http://cr.openjdk.java.net/~ppunegov/8150247/webrev.01/ ? Pavel. > On 05 May 2016, at 21:06, Pavel Punegov wrote: > > Hi, > > please review the following change to CompilerControl tests. It adds a new test to cover the gap found by JDK-8145345 [*]. > > The LogCompilation was empty after CompilerControl was integrated, but tests haven?t found that. This happened only when the LogCompilation was specified while there were no directives/CompileCommands enabled. With enabled directive/command it worked fine. > > Tests didn?t found the issue due to: > 1. There were no standalone test for LogCompilation. All related tests enable appropriate log directive or command. > 2. LogProcessor incorrectly worked for empty tasks that should be logged. It didn?t reported the issue. > > [*] https://bugs.openjdk.java.net/browse/JDK-8145345 > > bug: https://bugs.openjdk.java.net/browse/JDK-8150247 > webrev: http://cr.openjdk.java.net/~ppunegov/8150247/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri May 6 21:17:04 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 6 May 2016 11:17:04 -1000 Subject: RFR 8156178: [JVMCI] expose StubRoutines trig functions In-Reply-To: <4C9AA2D4-303C-44E5-A99B-B53DAE387E79@oracle.com> References: <4C9AA2D4-303C-44E5-A99B-B53DAE387E79@oracle.com> Message-ID: Looks good. > On May 5, 2016, at 6:22 PM, Tom Rodriguez wrote: > > http://cr.openjdk.java.net/~never/8156178/webrev > > JVMCI should expose the StubRoutines versions of the trig functions when they are available. Tested with graal Math tests. > > tom From christian.thalinger at oracle.com Fri May 6 21:19:43 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 6 May 2016 11:19:43 -1000 Subject: RFR(S): 8156025: [JVMCI] make HotSpotResolvedObjectTypeImpl.createField non-public In-Reply-To: <572C617B.8060204@oracle.com> References: <5729FDB9.2080205@oracle.com> <572C617B.8060204@oracle.com> Message-ID: <1AC0B756-42F9-44F1-8E1F-78F426BB69B7@oracle.com> > On May 5, 2016, at 11:18 PM, Roland Schatz wrote: > > On 05/04/2016 09:20 PM, Christian Thalinger wrote: >>> On May 4, 2016, at 3:48 AM, Roland Schatz wrote: >>> >>> Hi, >>> >>> Please review: >>> http://cr.openjdk.java.net/~rschatz/JDK-8156025/webrev.00/hotspot.changeset >>> https://bugs.openjdk.java.net/browse/JDK-8156025 >>> >>> This method is used only internally, it should never have been public. >> Looks good. All JVMCI tests pass? > At least no new failures, as far as I can tell. > > Looks like quite a few are failing anyway on the current tip. >> Test results: passed: 43; failed: 26; error: 5 > Or am I doing something wrong running the test? You must be doing something wrong. How are you running them? Also, use -ignore:quiet to not show the ignored tests (the errors). > > > - Roland From christian.thalinger at oracle.com Fri May 6 21:24:19 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 6 May 2016 11:24:19 -1000 Subject: RFR: 8156211: [JVMCI] ResolvedJava* interfaces should extend AnnotatedElement In-Reply-To: <572C8B7E.5020304@oracle.com> References: <572C8B7E.5020304@oracle.com> Message-ID: <94E88818-DE33-4778-9D98-153EF68978A9@oracle.com> > On May 6, 2016, at 2:18 AM, Roland Schatz wrote: > > Please review this small jvmci change: > > http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8156211 src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java + public Annotation[] getDeclaredAnnotations() { + Executable javaMethod = toJava(); + return javaMethod == null ? null : javaMethod.getDeclaredAnnotations(); + } This seems wrong. The specification says: * If there are no annotations directly present on this element, * the return value is an array of length 0. and the others return an empty array. > > This change was contributed by Vojin Jovanovic (cc'ed). > > Thanks, > Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri May 6 21:28:40 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 6 May 2016 11:28:40 -1000 Subject: RFR 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider In-Reply-To: <572CA963.3030906@oracle.com> References: <572CA963.3030906@oracle.com> Message-ID: <8CE8A2DA-4E8A-47F6-86E1-E083442F7B2C@oracle.com> > On May 6, 2016, at 4:25 AM, Dmitrij Pochepko wrote: > > Hi, > > please review patch for 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider > > A new tests were added for jdk.vm.ci.meta.MetaAccessProvider implementation. An existing TestMetaAccessProvider.java was used to add new tests. > > webrev: http://cr.openjdk.java.net/~dpochepk/8152343/webrev.01/ + private static final int[] VALID_ENCODED_VALUES = new int[]{-180, -436, -10932, -2147483572}; What are these values? Maybe it would make more sense to have them in hex-form? > > CR: https://bugs.openjdk.java.net/browse/JDK-8152343 > > I've tested it on linux_x64. > > Thanks, > Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri May 6 21:33:33 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 6 May 2016 11:33:33 -1000 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <572CAC7C.3040700@oracle.com> References: <572CAC7C.3040700@oracle.com> Message-ID: > On May 6, 2016, at 4:38 AM, Dmitrij Pochepko wrote: > > Hi, > > please review patch for 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider > > A new tests were added for MemoryAccessProvider implementation. This patch contains tests for all MemoryAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. > > webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ These two files don?t look like they have been formatted properly. Did you use an IDE to edit these? > CR: https://bugs.openjdk.java.net/browse/JDK-8152341 > > I've tested it on linux_x64 > > Thanks, > Dmitrij From christian.thalinger at oracle.com Fri May 6 21:35:25 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 6 May 2016 11:35:25 -1000 Subject: RFR: 8152342 - JVMCI test task: Unit tests for MethodHandleAccessProvider In-Reply-To: <572CADC8.4090004@oracle.com> References: <572CADC8.4090004@oracle.com> Message-ID: <23981544-7F7C-4CD0-B4CF-FAD8E42FA52F@oracle.com> > On May 6, 2016, at 4:44 AM, Dmitrij Pochepko wrote: > > Hi, > > please review patch for 8152342 - JVMCI test task: Unit tests for MethodHandleAccessProvider > > A new tests were added for MethodHandleAccessProvider implementation. This patch contains tests for all MethodHandleAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. MethodHandleAccessProviderData is used as testng data provider for MethodHandleAccessProviderTest. > > webrev: http://cr.openjdk.java.net/~dpochepk/8152342/webrev.01 Same formatting question. > CR: https://bugs.openjdk.java.net/browse/JDK-8152342 > > I've tested it on linux_x64 > > Thanks, > Dmitrij > > From mikael.vidstedt at oracle.com Fri May 6 21:40:13 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 6 May 2016 14:40:13 -0700 Subject: RFR(S): 8150921: Update Unsafe getters/setters to use double-register variants In-Reply-To: References: <41042e77-2e9e-d48e-c4b4-3ba39e0e51b3@oracle.com> <5728C07E.1070406@oracle.com> <9b826662-40d9-7db4-4681-7002b8f6bb57@oracle.com> <9d5d8aae-1699-8701-7cfa-29473e41e7d0@oracle.com> <7798058d-4496-1890-2426-9e3436df5e57@oracle.com> Message-ID: <2f30563d-9129-d85e-d07c-8f14e5f224ba@oracle.com> On 5/5/2016 2:56 PM, David Holmes wrote: > Hi Mikael, > > On 6/05/2016 4:35 AM, Mikael Vidstedt wrote: >> >> Updated webrevs here: >> >> jdk: >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03/jdk/webrev/ >> hotspot: >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03/hotspot/webrev/ >> >> >> >> Incremental from webrev.02: >> >> jdk: >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03.incr/jdk/webrev/ >> >> >> hotspot: >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.03.incr/hotspot/webrev/ >> > > Sorry I'm going to have to insist on a minor renaming as we are not > getting or putting mutexes. How about get_jlong_locked/put_jlong_locked ? > > No need to see another webrev. Ah, yes, fully agree. Will change before I push. David/Paul/Aleksey/John - thanks for reviews and feedback! Cheers, Mikael > > Thanks, > David > >> >> Changes from webrev.02: >> >> - javadoc updates for getAddress/putAddress in line with Paul's feedback >> (move the more descriptive comment to the double-register methods, with >> an @see on the single-reg guys) >> - updates to make MemoryAccess::get_mutex jlong specific >> >> Some additional comments inline.. >> >> On 5/3/2016 10:07 PM, David Holmes wrote: >>> On 4/05/2016 4:43 AM, Mikael Vidstedt wrote: >>>> >>>> Thank you very much for the review, some comments inline... >>>> >>>> On 5/3/2016 8:15 AM, Aleksey Shipilev wrote: >>>>> On 05/03/2016 08:09 AM, Mikael Vidstedt wrote: >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150921 >>>>>> Webrev (jdk): >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/jdk/webrev/ >>>>>> >>>>>> >>>>>> Webrev (hotspot/): >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.01/hotspot/webrev/ >>>>>> >>>>>> >>>>>> >>>>> Nice move overall! >>>>> >>>>> unsafe.cpp: >>>>> >>>>> *) Why do we Handle-ize incoming object in CompareAnd*? Is this >>>>> because >>>>> we may acquire a mutex, and the object may be gone? Either way, I see >>>>> you have dropped Handle from Unsafe_CompareAndSwapLong, but kept >>>>> it in >>>>> Unsafe_CompareAndExchangeLong -- why? >>>>> >>>>> *) Ditto for old {Get|Set}LongVolatile -- it used to Handle-ize >>>>> before >>>>> acquiring a mutex -- now we don't do that in MemoryAccess. >>>> >>>> My bad. As you say resolving the object should happen after the mutex >>>> has been acquired (see long comment starting on line 377 for the >>>> background). I have added back the Handle in CompareAndSwapLong and >>>> moved the addr() call in the mutex methods of MemoryAccess. Thank you >>>> for catching that! >>>> >>>>> >>>>> vmSymbols.cpp: >>>>> >>>>> *) {get|put}Address_raw intrinsics used to be conditionalized under >>>>> UseUnalignedAccesses. Baffles me why, because the old native code in >>>>> Unsafe_{Get|Set}NativeAddress/unsafe.cpp would seem to fail with >>>>> misaligned addresses. I wonder if the intent was to never fail, and >>>>> then >>>>> we should really use Unsafe.{get|put}Unaligned in new Unsafe.java >>>>> {get|set}Address to dodge misalign faults? >>>> >>>> I also failed to see what the conditional intrinsification is >>>> trying to >>>> achieve given that the native code does nothing special for the >>>> unaligned case. Unless I'm missing something the proposed change makes >>>> it no worse, and will potentially improve performance a tad on the >>>> pickier platforms. If anything we may want to consider introducing >>>> methods for getAddressUnaligned and putAddressUnaligned as a separate >>>> change. >>>> >>>>> library_call.cpp: >>>>> >>>>> *) What is the point for doing this check: >>>>> >>>>> 2372 if (_gvn.type(base)->isa_ptr() != TypePtr::NULL_PTR) { >>>>> 2373 heap_base_oop = base; >>>>> 2374 } >>>>> >>>>> In old code heap_base_oop != top() only for heap ptrs, even if >>>>> base is >>>>> NULL. In new code, if base is NULL, then heap_base_oop is top(). It >>>>> would seem that new code is better, because it clearly separates heap >>>>> vs. native accesses, and it does not seem to break anything >>>>> downstream. >>>>> Was that the intent? >>>> >>>> Those three lines were actually donated to my by John Rose, so I'm >>>> hoping he or somebody else more knowledgeable in C2 can provide some >>>> helpful comments on the correctness and validity of that specific >>>> change. >>>> >>>> >>>> I also changed the normalize() methods to be private in the >>>> MemoryAccess >>>> class, and made the MemoryAccess class a StackObj. >>>> >>>> New webrev(s) here: >>>> >>>> jdk: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/jdk/webrev/ >>>> >>>> hotspot: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02/hotspot/webrev/ >>>> >>>> >>> >>> src/share/vm/prims/unsafe.cpp >>> >>> I think this is a bit over-generalized: >>> >>> 254 template >>> 255 void put_mutex(T x) { >>> 256 GuardUnsafeAccess guard(_thread, _obj); >>> 257 >>> 258 MutexLockerEx mu(UnsafeJlong_lock, >>> Mutex::_no_safepoint_check_flag); >>> 259 >>> 260 T* p = (T*)addr(); >>> 261 >>> 262 Atomic::store(normalize(x), p); >>> 263 } >>> >>> The UnsafeJlong lock is, as the name suggests, only intended for use >>> with jlongs - we have no need of it for any other type. I don't think >>> this needs to be a template method. >> >> Good point. I guess the method could be made to take the mutex as an >> argument, or internally decide which mutex to use depending on the type, >> but given that really only is used for jlong right now I made the >> function jlong specific (without the template argument). >> >>> As noted before the lock could taken after calculating the address - >>> to shorten the critical section. >>> >>> If you take care to ensure no uses of MemoryAccess transitively can >>> hit a safepoint then you could store the oop directly rather than the >>> jobject. That would avoid multiple calls to JNIHandles::resolve (in >>> the GuardUnsafeAccess and addr() function). >> Since the resolve call is really just dereferencing a pointer and the >> data should already be in the L1 cache I'm not sure this is worth >> optimizing a whole lot more, but if we really think it will actually >> make a difference we can definitely store the raw oop instead. I chose >> to leave it the way it is for now. >> >>> >>> 405 if (VM_Version::supports_cx8()) { >>> 406 return MemoryAccess(thread, obj, >>> offset).get_volatile(); >>> >>> 407 } else { >>> 408 return MemoryAccess(thread, obj, offset).get_mutex(); >>> >>> You could internalize the supports_cx8 check and the use of locking >>> inside MemoryAccess.get_volatile rather than having >>> get_volatile and get_mutex. If you prefer to keep it this way then >>> get_volatile_with_mutex would be a more appropriate name (and it >>> doesn't need to be a template method as I said before). >> >> That's good, I like it! In the interest of drawing a line though I'm >> going to choose to leave that for a future enhancement. >> >> Cheers, >> Mikael >> >>> >>> Can't comment on the rest of the compiler related stuff too much, but >>> I didn't see anything obviously odd looking. >>> >>> Thanks, >>> David >>> >>>> >>>> Incremental from webrev.01: >>>> >>>> jdk: N/A (no changes) >>>> hotspot: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/webrev.02.incr/hotspot/webrev/ >>>> >>>> >>>> >>>> >>>> Cheers, >>>> Mikael >>>> >>>>> >>>>> Thanks, >>>>> -Aleksey >>>>> >>>>> >>>> >> From vladimir.kozlov at oracle.com Fri May 6 22:27:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 6 May 2016 15:27:05 -0700 Subject: RFR(M): 8154826: AArch64: take better advantage of base + shifted offset addressing mode In-Reply-To: References: <57188E03.5070303@redhat.com> <571E20BD.3030907@redhat.com> <5729A6D9.3010606@redhat.com> <572BE1E5.1040206@oracle.com> <572C6F74.1030907@redhat.com> <8af6680d-e44e-ce5c-d9cc-e95c728b48a5@oracle.com> Message-ID: <14eeba23-322a-be47-b854-56abb68d6418@oracle.com> Does not build: "hotspot/src/cpu/x86/vm/x86.ad", line 1898: Error: The type "AddPNode" is incomplete. ... Vladimir On 5/6/16 11:57 AM, Roland Westrelin wrote: > > Thanks for the review. > > Here is a change that should import cleanly: > > http://cr.openjdk.java.net/~roland/8154826/8154826.patch > >> Yes, looks good. Closed changes will be simple now :) >> >> Roland, are you on hotspot-compiler-dev at openjdk.java.net list? Or I should CC to you for reviews? > > No CC needed. I'm on hotspot-compiler-dev at openjdk.java.net. > > Roland. > From dean.long at oracle.com Fri May 6 23:37:09 2016 From: dean.long at oracle.com (Dean Long) Date: Fri, 6 May 2016 16:37:09 -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: <39497c08-d661-6e92-22de-54c8b53ba39b@oracle.com> Do we every call clear(), is_empty(), or is_full() twice in a row? We could add new "full" and "empty" flags so that we can quickly determine if an operation is redundant. If the code is complicated enough, we might not find all cases from static analysis. dl On 5/6/2016 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 dmitrij.pochepko at oracle.com Sat May 7 21:41:49 2016 From: dmitrij.pochepko at oracle.com (dmitrij pochepko) Date: Sun, 8 May 2016 00:41:49 +0300 Subject: RFR 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider In-Reply-To: <8CE8A2DA-4E8A-47F6-86E1-E083442F7B2C@oracle.com> References: <572CA963.3030906@oracle.com> <8CE8A2DA-4E8A-47F6-86E1-E083442F7B2C@oracle.com> Message-ID: <572E611D.7020700@oracle.com> > >> On May 6, 2016, at 4:25 AM, Dmitrij Pochepko >> > wrote: >> >> Hi, >> >> please review patch for 8152343: JVMCI test tasks: Unit tests for >> MetaAccessProvider >> >> A new tests were added for jdk.vm.ci.meta.MetaAccessProvider >> implementation. An existing TestMetaAccessProvider.java was used to >> add new tests. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8152343/webrev.01/ >> > + private static final int[] VALID_ENCODED_VALUES = new int[]{-180, > -436, -10932, -2147483572}; > What are these values? Maybe it would make more sense to have them in > hex-form? These values are encoded values for deoptReason=Aliasing, deoptAction=InvalidateRecompile and debugId={0, 1, 42, 8388607} so, we have 0, 1, , 0x7FFFFF which is a maximum debugId value here(all 23 bits set) I've created another webrev with hex values and respective comment added. http://cr.openjdk.java.net/~dpochepk/8152343/webrev.02 Thanks, Dmitrij > >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8152343 >> >> I've tested it on linux_x64. >> >> Thanks, >> Dmitrij > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Mon May 9 06:19:01 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 May 2016 06:19:01 +0000 Subject: RFR(XS): 8156190: [ppc] Fix build after "8151268: Wire up the x86 _vectorizedMismatch stub routine in C1" In-Reply-To: <22059d9b-71a2-466f-cc0c-aa352f9c7f8f@oracle.com> References: <7ddb567c248947769809ddb03ea9711f@DEWDFE13DE09.global.corp.sap> <22059d9b-71a2-466f-cc0c-aa352f9c7f8f@oracle.com> Message-ID: <26bd3144699b4448b07b4e71becb4580@DEWDFE13DE09.global.corp.sap> No matter, we could fix it without a sponsor :) Best regards Goetz. > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Freitag, 6. Mai 2016 17:54 > To: Lindenmaier, Goetz ; hotspot compiler > > Subject: Re: RFR(XS): 8156190: [ppc] Fix build after "8151268: Wire up the x86 > _vectorizedMismatch stub routine in C1" > > Sorry about this mistake. > > Vladimir > > On 5/6/16 1:40 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > > > > > Please review this small syntax fix on ppc: > > > > http://cr.openjdk.java.net/~goetz/wr16/8156190-ppcC1build/webrev.00/ > > > > > > > > Best regards, > > > > Goetz. > > From tobias.hartmann at oracle.com Mon May 9 07:36:32 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 May 2016 09:36:32 +0200 Subject: RFR(M): : Various minor code improvements (compiler) In-Reply-To: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> References: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> Message-ID: <57303E00.1000801@oracle.com> Hi Goetz, On 06.05.2016 10:01, Lindenmaier, Goetz wrote: > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.00/index.html This looks good to me. Thanks for the detailed explanation, please see some minor suggestions below. I can sponsor your fix but since we are close to JDK 9 FC, we are not allowed to push enhancements to hs-comp. Shouldn't this be a "bug" anyway? > os_linux.cpp > > - Buffer not null terminated > > - size of pointer passed to jio_snprintf() Please also fix the indentation in line 6004. > classLoader.cpp > > - jio_snprintf does null termination. But it might return -1 if truncated, > > in this case array access at -1. You can remove "int n;" > generateOopMap.cpp > > - Remaining fields not initialized. I would put the loop bodies in a new line. > relocator.cpp > > - delta might be -4 ... assert returns. I don't understand this change. If delta is -4, the assert in the baseline version is triggered. With your fix, the assert is triggered as well. Best regards, Tobias From tobias.hartmann at oracle.com Mon May 9 07:40:03 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 May 2016 09:40:03 +0200 Subject: RFR(M): 8140594: Various minor code improvements (compiler) In-Reply-To: <57303E00.1000801@oracle.com> References: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> <57303E00.1000801@oracle.com> Message-ID: <57303ED3.9020004@oracle.com> [Accidentally deleted the bug number from the subject line. Sorry for the noise.] On 09.05.2016 09:36, Tobias Hartmann wrote: > Hi Goetz, > > On 06.05.2016 10:01, Lindenmaier, Goetz wrote: >> Please review this change. I please need a sponsor. >> >> http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.00/index.html > > This looks good to me. Thanks for the detailed explanation, please see some minor suggestions below. > > I can sponsor your fix but since we are close to JDK 9 FC, we are not allowed to push enhancements to hs-comp. Shouldn't this be a "bug" anyway? > >> os_linux.cpp >> >> - Buffer not null terminated >> >> - size of pointer passed to jio_snprintf() > > Please also fix the indentation in line 6004. > >> classLoader.cpp >> >> - jio_snprintf does null termination. But it might return -1 if truncated, >> >> in this case array access at -1. > > You can remove "int n;" > >> generateOopMap.cpp >> >> - Remaining fields not initialized. > > I would put the loop bodies in a new line. > >> relocator.cpp >> >> - delta might be -4 ... assert returns. > > I don't understand this change. If delta is -4, the assert in the baseline version is triggered. With your fix, the assert is triggered as well. > > Best regards, > Tobias > From rahul.v.raghavan at oracle.com Mon May 9 08:08:31 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 9 May 2016 01:08:31 -0700 (PDT) Subject: RFR: 8153655: Make intrinsics flags diagnostic and update intrinsics tests to enable diagnostic options. In-Reply-To: <572BA38E.5050304@oracle.com> References: <5722A4BD.5060607@oracle.com> <7032321c-0261-4d45-bda0-17ec3eefeadf@default> <572BA38E.5050304@oracle.com> Message-ID: Thank you Vladimir. > -----Original Message----- > From: Vladimir Kozlov > Sent: Friday, May 06, 2016 1:19 AM > > Looks good. > > thanks, > Vladimir > > On 5/5/16 4:31 AM, Rahul Raghavan wrote: > > Hi, > > > > Thank you Vladimir for review comments. > > Yes, now updated the changes. > > > > Please review following revised webrev - > > http://cr.openjdk.java.net/~rraghavan/8153655/webrev.01/ > > (Modified 'test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForUnsupportedX86CPU.java') > > > > No issues found with testing done using product builds with proposed changes > > (hotspot/test/compiler/cpuflags/*, hotspot/test/compiler/intrinsics/* etc.) > > Complete pre-integration testing using product builds is in progress for this 'webrev.01'. > > (No issues with pre-integration testing done earlier for 'webrev.00'.) > > > > Thanks, > > Rahul > > > >> -----Original Message----- > >> From: Vladimir Kozlov > Sent: Friday, April 29, 2016 5:33 AM > >> > >> Hi Rahul, > >> > >> Changes looks good but you need to update changes for SHA tests because I changed them for JDK-8154495: > >> > >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6a17c49de974 > >> > >> Thanks, > >> Vladimir > >> > >> On 4/27/16 2:45 AM, Rahul Raghavan wrote: > >>> Hi, > >>> > >>> Please review the following patch for JDK-8153655. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153655 > >>> Webrev: http://cr.openjdk.java.net/~rraghavan/8153655/webrev.00/ > >>> > >>> > >>> Notes: > >>> > >>> 1. This 8153655/webrev.00 re-includes earlier backed out, same JDK-8145348 changes > >>> (https://bugs.openjdk.java.net/browse/JDK-8145348 - Make intrinsics flags diagnostic) > >>> and also additional fixes in failing intrinsic tests. > >>> > >>> > >>> 2. Checked all the usages of changed intrinsic flags in tests and > >>> found JDK-8153655 type test failure issue (after initial JDK-8145348 fix) is present only for following tests - > >>> a. UseAESIntrinsics test (compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java) > >>> b. UseSHA* tests (at compiler/intrinsics/sha/cli/) > >>> > >>> > >>> 3. Summary of 8153655/webrev.00 changes. > >>> > >>> - Includes earlier backed out, same JDK-8145348 changes: > >>> src/share/vm/c1/c1_globals.hpp > >>> src/share/vm/opto/c2_globals.hpp > >>> src/share/vm/runtime/globals.hpp > >>> test/compiler/intrinsics/muladd/TestMulAdd.java > >>> test/compiler/runtime/6859338/Test6859338.java > >>> > >>> - 'test/compiler/cpuflags/AESIntrinsicsBase.java' > >>> Options were passed in wrong order. > >>> Changes done so that 'UnlockDiagnosticVMOptions' option precedes the diagnostic flags. > >>> > >>> - 'test/compiler/intrinsics/sha/cli/*' - (UseSHA* tests) > >>> 'UnlockDiagnosticVMOptions' option was not getting passed. > >>> Added support to precede intrinsic flag usages with explicit 'UnlockDiagnosticVMOptions'. > >>> > >>> > >>> 4. No issues found with testing done using product builds with proposed changes > >>> (hotspot/test/compiler/cpuflags/*, hotspot/test/compiler/intrinsics/*, > hotspot/test/compiler/runtime/6859338/Test6859338.java) > >>> Complete pre-integration testing using product builds is in progress. > >>> > >>> > >>> Thanks, > >>> Rahul > >>> From tobias.hartmann at oracle.com Mon May 9 08:12:44 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 May 2016 10:12:44 +0200 Subject: RFR: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted In-Reply-To: <572C7E34.60608@oracle.com> References: <572C7E34.60608@oracle.com> Message-ID: <5730467C.5040605@oracle.com> Hi Jamsheed, On 06.05.2016 13:21, Jamsheed C m wrote: > > Hi, > > Request for review for an assert cleanup change. > bug id : https://bugs.openjdk.java.net/browse/JDK-8144856 > webrev: http://cr.openjdk.java.net/~jcm/8144856/webrev.00/ Looks good to me. Do you know why the assert is different on aarch64 (we don't check for destination == -1)? Best regards, Tobias From goetz.lindenmaier at sap.com Mon May 9 08:30:40 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 May 2016 08:30:40 +0000 Subject: RFR(M): : Various minor code improvements (compiler) In-Reply-To: <57303E00.1000801@oracle.com> References: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> <57303E00.1000801@oracle.com> Message-ID: <3ecea76a5493429a970a217cf171adf6@DEWDFE13DE09.global.corp.sap> Hi Tobias, > I can sponsor your fix but since we are close to JDK 9 FC, we are not allowed > to push enhancements to hs-comp. Shouldn't this be a "bug" anyway? Thanks for reviewing and the offer to sponsor! I changed the Jira issue to bug. Sorry for being that close to FC with my RFR. > > - size of pointer passed to jio_snprintf() > Please also fix the indentation in line 6004. Fixed. > > classLoader.cpp > > - jio_snprintf does null termination. But it might return -1 if truncated, > > in this case array access at -1. > You can remove "int n;" Fixed. > > generateOopMap.cpp > > - Remaining fields not initialized. > I would put the loop bodies in a new line. Fixed. > > relocator.cpp > > - delta might be -4 ... assert returns. > I don't understand this change. If delta is -4, the assert in the baseline version > is triggered. With your fix, the assert is triggered as well. Sorry, that's a bad comment. I meant that the assert does not protect against getting -4 in that line, because coverity knows about -XX:SuppressErrorAt. But that's pointless, as assert goes away in product builds anyways. The assert shall be triggered, therefore I moved it out of the if(). But the if() now protects against oob with -4 or smaller. I also rebased the change, and added you as reviewer. Find the new Webrev here: http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.01/ And the incremental patch: http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.01/incremental_diff.patch Best regards, Goetz. From jamsheed.c.m at oracle.com Mon May 9 08:37:06 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Mon, 9 May 2016 14:07:06 +0530 Subject: RFR: 8150016: small typo in ciReplay code In-Reply-To: <2d50e277-569f-23a9-ca0b-56f95b26b3c9@oracle.com> References: <572C37C4.9090306@oracle.com> <2d50e277-569f-23a9-ca0b-56f95b26b3c9@oracle.com> Message-ID: <57304C32.7000104@oracle.com> Thank you Vladimir. Best Regards, Jamsheed On 5/6/2016 11:01 PM, Vladimir Kozlov wrote: > Looks good. > > thanks, > Vladimir > > On 5/5/16 11:20 PM, Jamsheed C m wrote: >> Hi >> >> Request for review of a trivial change. >> bug id : https://bugs.openjdk.java.net/browse/JDK-8150016 >> webrev: http://cr.openjdk.java.net/~jcm/8150016/webrev.00/ >> >> Best Regards, >> Jamsheed >> >> From tobias.hartmann at oracle.com Mon May 9 08:40:33 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 May 2016 10:40:33 +0200 Subject: RFR(M): 8140594: Various minor code improvements (compiler) In-Reply-To: <3ecea76a5493429a970a217cf171adf6@DEWDFE13DE09.global.corp.sap> References: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> <57303E00.1000801@oracle.com> <3ecea76a5493429a970a217cf171adf6@DEWDFE13DE09.global.corp.sap> Message-ID: <57304D01.4010006@oracle.com> Hi Goetz, thanks for the explanation, this looks good to me! I'm running the hs-comp PIT now and will push the fix afterwards, if there are no objections. Thanks, Tobias On 09.05.2016 10:30, Lindenmaier, Goetz wrote: > Hi Tobias, > >> I can sponsor your fix but since we are close to JDK 9 FC, we are not allowed >> to push enhancements to hs-comp. Shouldn't this be a "bug" anyway? > Thanks for reviewing and the offer to sponsor! > I changed the Jira issue to bug. Sorry for being that close to FC with my RFR. > >>> - size of pointer passed to jio_snprintf() >> Please also fix the indentation in line 6004. > Fixed. > >>> classLoader.cpp >>> - jio_snprintf does null termination. But it might return -1 if truncated, >>> in this case array access at -1. >> You can remove "int n;" > Fixed. > >>> generateOopMap.cpp >>> - Remaining fields not initialized. >> I would put the loop bodies in a new line. > Fixed. > >>> relocator.cpp >>> - delta might be -4 ... assert returns. >> I don't understand this change. If delta is -4, the assert in the baseline version >> is triggered. With your fix, the assert is triggered as well. > > Sorry, that's a bad comment. I meant that the assert does not > protect against getting -4 in that line, because coverity knows > about -XX:SuppressErrorAt. But that's pointless, as assert goes > away in product builds anyways. > > The assert shall be triggered, therefore I moved it out of the if(). > But the if() now protects against oob with -4 or smaller. > > I also rebased the change, and added you as reviewer. Find the new > Webrev here: > http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.01/ > And the incremental patch: > http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.01/incremental_diff.patch > > Best regards, > Goetz. > From jamsheed.c.m at oracle.com Mon May 9 08:50:15 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Mon, 9 May 2016 14:20:15 +0530 Subject: RFR: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted In-Reply-To: <5730467C.5040605@oracle.com> References: <572C7E34.60608@oracle.com> <5730467C.5040605@oracle.com> Message-ID: <57304F47.8040202@oracle.com> Hi Tobias, On 5/9/2016 1:42 PM, Tobias Hartmann wrote: > Hi Jamsheed, > > On 06.05.2016 13:21, Jamsheed C m wrote: >> Hi, >> >> Request for review for an assert cleanup change. >> bug id : https://bugs.openjdk.java.net/browse/JDK-8144856 >> webrev: http://cr.openjdk.java.net/~jcm/8144856/webrev.00/ > Looks good to me. > > Do you know why the assert is different on aarch64 (we don't check for destination == -1)? i am not sure about this, and even Redhat guys don't remember why its like this. Best Regards, Jamsheed > > Best regards, > Tobias From goetz.lindenmaier at sap.com Mon May 9 08:52:01 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 May 2016 08:52:01 +0000 Subject: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted In-Reply-To: <572C7E34.60608@oracle.com> References: <572C7E34.60608@oracle.com> Message-ID: <82fe858d208f4bb8916e9cd4472d140e@DEWDFE13DE09.global.corp.sap> Hi Jamsheed, Do you want to avoid that data/destination are changed concurrently between the two compares? Or do you just want to save costs of the call? To assure the first, you need to make the two local variables volatile. Else the compilers can add reloads after inlining data() and jump_destination(). We observed this with the Visual Studio compiler and xlC on aix. Besides that the change looks good. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Jamsheed C m > Sent: Freitag, 6. Mai 2016 13:21 > To: hotspot compiler > Subject: RFR: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted > > > Hi, > > Request for review for an assert cleanup change. > bug id : https://bugs.openjdk.java.net/browse/JDK-8144856 > webrev: http://cr.openjdk.java.net/~jcm/8144856/webrev.00/ > > Best Regards, > Jamsheed > From tobias.hartmann at oracle.com Mon May 9 09:08:19 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 May 2016 11:08:19 +0200 Subject: RFR(M): 8140594: Various minor code improvements (compiler) In-Reply-To: <57304D01.4010006@oracle.com> References: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> <57303E00.1000801@oracle.com> <3ecea76a5493429a970a217cf171adf6@DEWDFE13DE09.global.corp.sap> <57304D01.4010006@oracle.com> Message-ID: <57305383.1090005@oracle.com> Hi Goetz, the build failed on Windows with: c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(721) : error C3861: 'snprintf': identifier not found c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(723) : error C3861: 'snprintf': identifier not found c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(728) : error C3861: 'snprintf': identifier not found c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(730) : error C3861: 'snprintf': identifier not found c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(740) : error C3861: 'snprintf': identifier not found c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(742) : error C3861: 'snprintf': identifier not found Looks like a missing include. Best regards, Tobias On 09.05.2016 10:40, Tobias Hartmann wrote: > Hi Goetz, > > thanks for the explanation, this looks good to me! > > I'm running the hs-comp PIT now and will push the fix afterwards, if there are no objections. > > Thanks, > Tobias > > On 09.05.2016 10:30, Lindenmaier, Goetz wrote: >> Hi Tobias, >> >>> I can sponsor your fix but since we are close to JDK 9 FC, we are not allowed >>> to push enhancements to hs-comp. Shouldn't this be a "bug" anyway? >> Thanks for reviewing and the offer to sponsor! >> I changed the Jira issue to bug. Sorry for being that close to FC with my RFR. >> >>>> - size of pointer passed to jio_snprintf() >>> Please also fix the indentation in line 6004. >> Fixed. >> >>>> classLoader.cpp >>>> - jio_snprintf does null termination. But it might return -1 if truncated, >>>> in this case array access at -1. >>> You can remove "int n;" >> Fixed. >> >>>> generateOopMap.cpp >>>> - Remaining fields not initialized. >>> I would put the loop bodies in a new line. >> Fixed. >> >>>> relocator.cpp >>>> - delta might be -4 ... assert returns. >>> I don't understand this change. If delta is -4, the assert in the baseline version >>> is triggered. With your fix, the assert is triggered as well. >> >> Sorry, that's a bad comment. I meant that the assert does not >> protect against getting -4 in that line, because coverity knows >> about -XX:SuppressErrorAt. But that's pointless, as assert goes >> away in product builds anyways. >> >> The assert shall be triggered, therefore I moved it out of the if(). >> But the if() now protects against oob with -4 or smaller. >> >> I also rebased the change, and added you as reviewer. Find the new >> Webrev here: >> http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.01/ >> And the incremental patch: >> http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.01/incremental_diff.patch >> >> Best regards, >> Goetz. >> From roland.schatz at oracle.com Mon May 9 09:28:57 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Mon, 9 May 2016 11:28:57 +0200 Subject: RFR(S): 8156025: [JVMCI] make HotSpotResolvedObjectTypeImpl.createField non-public In-Reply-To: <1AC0B756-42F9-44F1-8E1F-78F426BB69B7@oracle.com> References: <5729FDB9.2080205@oracle.com> <572C617B.8060204@oracle.com> <1AC0B756-42F9-44F1-8E1F-78F426BB69B7@oracle.com> Message-ID: <57305859.1080401@oracle.com> On 05/06/2016 11:19 PM, Christian Thalinger wrote: >> On May 5, 2016, at 11:18 PM, Roland Schatz wrote: >> >> On 05/04/2016 09:20 PM, Christian Thalinger wrote: >>>> On May 4, 2016, at 3:48 AM, Roland Schatz wrote: >>>> >>>> Hi, >>>> >>>> Please review: >>>> http://cr.openjdk.java.net/~rschatz/JDK-8156025/webrev.00/hotspot.changeset >>>> https://bugs.openjdk.java.net/browse/JDK-8156025 >>>> >>>> This method is used only internally, it should never have been public. >>> Looks good. All JVMCI tests pass? >> At least no new failures, as far as I can tell. >> >> Looks like quite a few are failing anyway on the current tip. >>> Test results: passed: 43; failed: 26; error: 5 >> Or am I doing something wrong running the test? > You must be doing something wrong. How are you running them? Also, use -ignore:quiet to not show the ignored tests (the errors). Just tried that on current hs-comp tip (clean rebuild, i.e. "rm -rf build JTwork JTreport; bash configure; make"): > [roland at oracle-rs hs-comp]$ ~/jtreg/bin/jtreg -testjdk > build/linux-x86_64-normal-server-release/jdk -ignore:quiet > hotspot/test/compiler/jvmci > Directory "JTwork" not found: creating > Directory "JTreport" not found: creating > Test results: passed: 43; failed: 26 > Report written to /home/roland/hg/jdk9/hs-comp/JTreport/html/report.html > Results written to /home/roland/hg/jdk9/hs-comp/JTwork > Error: Some tests failed or other problems occurred. > >> >> - Roland From stefan.karlsson at oracle.com Mon May 9 09:36:45 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 9 May 2016 11:36:45 +0200 Subject: RFR: 8155638: Resource allocated BitMaps are often cleared twice In-Reply-To: <39497c08-d661-6e92-22de-54c8b53ba39b@oracle.com> References: <572C7621.7000001@oracle.com> <39497c08-d661-6e92-22de-54c8b53ba39b@oracle.com> Message-ID: <57305A2D.2010805@oracle.com> Hi Dean, On 2016-05-07 01:37, Dean Long wrote: > Do we every call clear(), is_empty(), or is_full() twice in a row? We > could add new "full" and "empty" flags so that we can quickly > determine if an operation is redundant. If the code is complicated > enough, we might not find all cases from static analysis. Some of my changes to BitMap has been done to minimize the size of the BitMap class. If we add such a flag I'd prefer if it was done in a subclass, or a wrapper class, if possible. Thanks, StefanK > > dl > > > On 5/6/2016 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 roland.schatz at oracle.com Mon May 9 09:39:08 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Mon, 9 May 2016 11:39:08 +0200 Subject: RFR: 8156211: [JVMCI] ResolvedJava* interfaces should extend AnnotatedElement In-Reply-To: <94E88818-DE33-4778-9D98-153EF68978A9@oracle.com> References: <572C8B7E.5020304@oracle.com> <94E88818-DE33-4778-9D98-153EF68978A9@oracle.com> Message-ID: <57305ABC.2010804@oracle.com> Whoops... Good catch. Fixed: http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.01/ - Roland On 05/06/2016 11:24 PM, Christian Thalinger wrote: > >> On May 6, 2016, at 2:18 AM, Roland Schatz > > wrote: >> >> Please review this small jvmci change: >> >> http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8156211 > > > src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java > > + public Annotation[] getDeclaredAnnotations() { > + Executable javaMethod = toJava(); > + return javaMethod == null ? null : javaMethod.getDeclaredAnnotations(); > + } > This seems wrong. The specification says: > > * If there are no annotations directly present on this element, > * the return value is an array of length 0. > > and the others return an empty array. > >> >> This change was contributed by Vojin Jovanovic (cc'ed). >> >> Thanks, >> Roland > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwestrel at redhat.com Mon May 9 09:57:45 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 09 May 2016 11:57:45 +0200 Subject: RFR(M): 8154826: AArch64: take better advantage of base + shifted offset addressing mode In-Reply-To: <14eeba23-322a-be47-b854-56abb68d6418@oracle.com> References: <57188E03.5070303@redhat.com> <571E20BD.3030907@redhat.com> <5729A6D9.3010606@redhat.com> <572BE1E5.1040206@oracle.com> <572C6F74.1030907@redhat.com> <8af6680d-e44e-ce5c-d9cc-e95c728b48a5@oracle.com> <14eeba23-322a-be47-b854-56abb68d6418@oracle.com> Message-ID: Hi Vladimir, > Does not build: > > "hotspot/src/cpu/x86/vm/x86.ad", line 1898: Error: The type "AddPNode" is incomplete. > ... > Indeed it doesn't build with precompiled headers off. I updated: http://cr.openjdk.java.net/~roland/8154826/8154826.patch with the patch below. Roland. diff --git a/src/cpu/aarch64/vm/aarch64.ad b/src/cpu/aarch64/vm/aarch64.ad --- a/src/cpu/aarch64/vm/aarch64.ad +++ b/src/cpu/aarch64/vm/aarch64.ad @@ -996,6 +996,7 @@ source_hpp %{ #include "gc/shared/cardTableModRefBS.hpp" +#include "opto/addnode.hpp" class CallStubImpl { diff --git a/src/cpu/x86/vm/x86.ad b/src/cpu/x86/vm/x86.ad --- a/src/cpu/x86/vm/x86.ad +++ b/src/cpu/x86/vm/x86.ad @@ -1586,6 +1586,8 @@ source %{ +#include "opto/addnode.hpp" + // Emit exception handler code. // Stuff framesize into a register and call a VM stub routine. int HandlerImpl::emit_exception_handler(CodeBuffer& cbuf) { From goetz.lindenmaier at sap.com Mon May 9 10:30:24 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 May 2016 10:30:24 +0000 Subject: RFR(M): 8140594: Various minor code improvements (compiler) In-Reply-To: <57305383.1090005@oracle.com> References: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> <57303E00.1000801@oracle.com> <3ecea76a5493429a970a217cf171adf6@DEWDFE13DE09.global.corp.sap> <57304D01.4010006@oracle.com> <57305383.1090005@oracle.com> Message-ID: <401c1fc87d974708a404793235e7599f@DEWDFE13DE09.global.corp.sap> Hi Tobias, sorry for that! No, it's not just missing include, windows does not implement snprintf before Visual Studio 2015. http://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010 As this is only a build-time tool, I would prefer skipping this altogether above adding windows specific code: http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.02/ Best regrds, Goetz. > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Montag, 9. Mai 2016 11:08 > To: Lindenmaier, Goetz ; hotspot compiler > > Subject: Re: RFR(M): 8140594: Various minor code improvements (compiler) > > Hi Goetz, > > the build failed on Windows with: > c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(721) : > error C3861: 'snprintf': identifier not found > c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(723) : > error C3861: 'snprintf': identifier not found > c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(728) : > error C3861: 'snprintf': identifier not found > c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(730) : > error C3861: 'snprintf': identifier not found > c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(740) : > error C3861: 'snprintf': identifier not found > c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(742) : > error C3861: 'snprintf': identifier not found > > Looks like a missing include. > > Best regards, > Tobias > > On 09.05.2016 10:40, Tobias Hartmann wrote: > > Hi Goetz, > > > > thanks for the explanation, this looks good to me! > > > > I'm running the hs-comp PIT now and will push the fix afterwards, if there > are no objections. > > > > Thanks, > > Tobias > > > > On 09.05.2016 10:30, Lindenmaier, Goetz wrote: > >> Hi Tobias, > >> > >>> I can sponsor your fix but since we are close to JDK 9 FC, we are not > allowed > >>> to push enhancements to hs-comp. Shouldn't this be a "bug" anyway? > >> Thanks for reviewing and the offer to sponsor! > >> I changed the Jira issue to bug. Sorry for being that close to FC with my > RFR. > >> > >>>> - size of pointer passed to jio_snprintf() > >>> Please also fix the indentation in line 6004. > >> Fixed. > >> > >>>> classLoader.cpp > >>>> - jio_snprintf does null termination. But it might return -1 if truncated, > >>>> in this case array access at -1. > >>> You can remove "int n;" > >> Fixed. > >> > >>>> generateOopMap.cpp > >>>> - Remaining fields not initialized. > >>> I would put the loop bodies in a new line. > >> Fixed. > >> > >>>> relocator.cpp > >>>> - delta might be -4 ... assert returns. > >>> I don't understand this change. If delta is -4, the assert in the baseline > version > >>> is triggered. With your fix, the assert is triggered as well. > >> > >> Sorry, that's a bad comment. I meant that the assert does not > >> protect against getting -4 in that line, because coverity knows > >> about -XX:SuppressErrorAt. But that's pointless, as assert goes > >> away in product builds anyways. > >> > >> The assert shall be triggered, therefore I moved it out of the if(). > >> But the if() now protects against oob with -4 or smaller. > >> > >> I also rebased the change, and added you as reviewer. Find the new > >> Webrev here: > >> http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.01/ > >> And the incremental patch: > >> http://cr.openjdk.java.net/~goetz/wr16/8140594- > covCo/webrev.01/incremental_diff.patch > >> > >> Best regards, > >> Goetz. > >> From tobias.hartmann at oracle.com Mon May 9 11:42:02 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 May 2016 13:42:02 +0200 Subject: RFR(M): 8140594: Various minor code improvements (compiler) In-Reply-To: <401c1fc87d974708a404793235e7599f@DEWDFE13DE09.global.corp.sap> References: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> <57303E00.1000801@oracle.com> <3ecea76a5493429a970a217cf171adf6@DEWDFE13DE09.global.corp.sap> <57304D01.4010006@oracle.com> <57305383.1090005@oracle.com> <401c1fc87d974708a404793235e7599f@DEWDFE13DE09.global.corp.sap> Message-ID: <5730778A.6020906@oracle.com> Hi Goetz, On 09.05.2016 12:30, Lindenmaier, Goetz wrote: > Hi Tobias, > > sorry for that! No, it's not just missing include, windows does not > implement snprintf before Visual Studio 2015. > http://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010 > > As this is only a build-time tool, I would prefer skipping this altogether > above adding windows specific code: > http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.02/ That's fine with me but unfortunately the build still fails on Windows: c:/jprt/T/P1/105246.tohartma/s/hotspot/src/share/vm/logging/logTagSet.cpp(112) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data Best regards, Tobias > > Best regrds, > Goetz. > > > >> -----Original Message----- >> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >> Sent: Montag, 9. Mai 2016 11:08 >> To: Lindenmaier, Goetz ; hotspot compiler >> >> Subject: Re: RFR(M): 8140594: Various minor code improvements (compiler) >> >> Hi Goetz, >> >> the build failed on Windows with: >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(721) : >> error C3861: 'snprintf': identifier not found >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(723) : >> error C3861: 'snprintf': identifier not found >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(728) : >> error C3861: 'snprintf': identifier not found >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(730) : >> error C3861: 'snprintf': identifier not found >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(740) : >> error C3861: 'snprintf': identifier not found >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(742) : >> error C3861: 'snprintf': identifier not found >> >> Looks like a missing include. >> >> Best regards, >> Tobias >> >> On 09.05.2016 10:40, Tobias Hartmann wrote: >>> Hi Goetz, >>> >>> thanks for the explanation, this looks good to me! >>> >>> I'm running the hs-comp PIT now and will push the fix afterwards, if there >> are no objections. >>> >>> Thanks, >>> Tobias >>> >>> On 09.05.2016 10:30, Lindenmaier, Goetz wrote: >>>> Hi Tobias, >>>> >>>>> I can sponsor your fix but since we are close to JDK 9 FC, we are not >> allowed >>>>> to push enhancements to hs-comp. Shouldn't this be a "bug" anyway? >>>> Thanks for reviewing and the offer to sponsor! >>>> I changed the Jira issue to bug. Sorry for being that close to FC with my >> RFR. >>>> >>>>>> - size of pointer passed to jio_snprintf() >>>>> Please also fix the indentation in line 6004. >>>> Fixed. >>>> >>>>>> classLoader.cpp >>>>>> - jio_snprintf does null termination. But it might return -1 if truncated, >>>>>> in this case array access at -1. >>>>> You can remove "int n;" >>>> Fixed. >>>> >>>>>> generateOopMap.cpp >>>>>> - Remaining fields not initialized. >>>>> I would put the loop bodies in a new line. >>>> Fixed. >>>> >>>>>> relocator.cpp >>>>>> - delta might be -4 ... assert returns. >>>>> I don't understand this change. If delta is -4, the assert in the baseline >> version >>>>> is triggered. With your fix, the assert is triggered as well. >>>> >>>> Sorry, that's a bad comment. I meant that the assert does not >>>> protect against getting -4 in that line, because coverity knows >>>> about -XX:SuppressErrorAt. But that's pointless, as assert goes >>>> away in product builds anyways. >>>> >>>> The assert shall be triggered, therefore I moved it out of the if(). >>>> But the if() now protects against oob with -4 or smaller. >>>> >>>> I also rebased the change, and added you as reviewer. Find the new >>>> Webrev here: >>>> http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.01/ >>>> And the incremental patch: >>>> http://cr.openjdk.java.net/~goetz/wr16/8140594- >> covCo/webrev.01/incremental_diff.patch >>>> >>>> Best regards, >>>> Goetz. >>>> From doug.simon at oracle.com Mon May 9 11:50:40 2016 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 9 May 2016 13:50:40 +0200 Subject: RFR: 8155023: jdk.vm.ci needs to securely export services In-Reply-To: <04E2339D-0EEB-4C31-947E-C46A0EE2A327@oracle.com> References: <572B5EFA.4050803@oracle.com> <04E2339D-0EEB-4C31-947E-C46A0EE2A327@oracle.com> Message-ID: <10CA88EE-1A77-4AC9-819C-BED550F42667@oracle.com> Hi Alan, > On 05 May 2016, at 17:45, Doug Simon wrote: > > >> On 05 May 2016, at 16:55, Alan Bateman wrote: >> >> On 03/05/2016 14:34, Doug Simon wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8155023 >>> http://cr.openjdk.java.net/~dnsimon/8155023/ >>> >> I skimmed through this. >> >> The module-info.java looks okay. The permission check idiom in JVMCICompilerFactory (and EventProvider) look fine. >> >> I'm not sure about using RuntimePermission("jvmci"). One reason is that RuntimePermission specifies in its javadoc all the possible targets. It might be better to just introduce a new basic permission for this. > > Ok, I was not aware that the set of RuntimePermissions is effectively closed. I?ve created JVMCIPermission and updated the webrev. > >> >> One thing about Services.load is that it uses ServiceLoader.load and hence the TCCL. I don't know if this is what you here, I suspect you want the system class loader. > > Is that because I should expect only trusted code to use this call? That is, only code available via the system class loader? I?ll admit that when to use TCCL versus the system class loader is not clear to me. Should I be passing System.getSystemClassLoader() as the second argument to ServiceLoader.load()? -Doug From jamsheed.c.m at oracle.com Mon May 9 11:58:44 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Mon, 9 May 2016 17:28:44 +0530 Subject: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted In-Reply-To: <82fe858d208f4bb8916e9cd4472d140e@DEWDFE13DE09.global.corp.sap> References: <572C7E34.60608@oracle.com> <82fe858d208f4bb8916e9cd4472d140e@DEWDFE13DE09.global.corp.sap> Message-ID: <57307B74.9030703@oracle.com> Hi Goetz, Thank you for looking at this. On 5/9/2016 2:22 PM, Lindenmaier, Goetz wrote: > Hi Jamsheed, > > Do you want to avoid that data/destination are changed concurrently > between the two compares? Or do you just want to save costs of the call? This change was done in x86 as part of JDK-8062493 . from the comment in the change, it says its meant for first case. but, i couldn't find a case in current hotspot code where this could happen. may be its a precautionary change. ( Chris can help here). > > To assure the first, you need to make the two local variables volatile. > Else the compilers can add reloads after inlining data() and jump_destination(). > We observed this with the Visual Studio compiler and xlC on aix. i have made the two local variables as volatile. revised webrev: http://cr.openjdk.java.net/~jcm/8144856/webrev.01/ Best Regards, Jamsheed > > Besides that the change looks good. > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >> bounces at openjdk.java.net] On Behalf Of Jamsheed C m >> Sent: Freitag, 6. Mai 2016 13:21 >> To: hotspot compiler >> Subject: RFR: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted >> >> >> Hi, >> >> Request for review for an assert cleanup change. >> bug id : https://bugs.openjdk.java.net/browse/JDK-8144856 >> webrev: http://cr.openjdk.java.net/~jcm/8144856/webrev.00/ >> >> Best Regards, >> Jamsheed >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon May 9 12:30:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 9 May 2016 13:30:39 +0100 Subject: RFR: 8155023: jdk.vm.ci needs to securely export services In-Reply-To: <10CA88EE-1A77-4AC9-819C-BED550F42667@oracle.com> References: <572B5EFA.4050803@oracle.com> <04E2339D-0EEB-4C31-947E-C46A0EE2A327@oracle.com> <10CA88EE-1A77-4AC9-819C-BED550F42667@oracle.com> Message-ID: <573082EF.8060706@oracle.com> On 09/05/2016 12:50, Doug Simon wrote: > : > Should I be passing System.getSystemClassLoader() as the second argument to ServiceLoader.load()? > Probably as I assume you want to restrict deployments to the class path or module path. That is, I assume compiler implementation aren't going to be bundled with applications that are loaded into a running VM. If you do then you'll need to call ClassLoader::getSystemClassLoaded in a privileged block. The updated permission checks, to check JVMCIPermission, looks fine. Strictly speaking then the Services.loadXXX methods should need it but this isn't a general purpose service loading class so what you have is fine. -Alan From doug.simon at oracle.com Mon May 9 12:48:14 2016 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 9 May 2016 14:48:14 +0200 Subject: RFR: 8155023: jdk.vm.ci needs to securely export services In-Reply-To: <573082EF.8060706@oracle.com> References: <572B5EFA.4050803@oracle.com> <04E2339D-0EEB-4C31-947E-C46A0EE2A327@oracle.com> <10CA88EE-1A77-4AC9-819C-BED550F42667@oracle.com> <573082EF.8060706@oracle.com> Message-ID: > On 09 May 2016, at 14:30, Alan Bateman wrote: > > > > On 09/05/2016 12:50, Doug Simon wrote: >> : >> Should I be passing System.getSystemClassLoader() as the second argument to ServiceLoader.load()? >> > Probably as I assume you want to restrict deployments to the class path or module path. That is, I assume compiler implementation aren't going to be bundled with applications that are loaded into a running VM. That is correct. > If you do then you'll need to call ClassLoader::getSystemClassLoaded in a privileged block. Ok. I?ve pushed these changes along with a comment explaining the use of the system class loader: http://cr.openjdk.java.net/~dnsimon/8155023/src/jdk.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java.sdiff.html > The updated permission checks, to check JVMCIPermission, looks fine. Strictly speaking then the Services.loadXXX methods should need it but this isn't a general purpose service loading class so what you have is fine. Got it. Thanks for answering the final questions I have about this change. -Doug From goetz.lindenmaier at sap.com Mon May 9 13:11:50 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 May 2016 13:11:50 +0000 Subject: RFR(M): 8140594: Various minor code improvements (compiler) In-Reply-To: <5730778A.6020906@oracle.com> References: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> <57303E00.1000801@oracle.com> <3ecea76a5493429a970a217cf171adf6@DEWDFE13DE09.global.corp.sap> <57304D01.4010006@oracle.com> <57305383.1090005@oracle.com> <401c1fc87d974708a404793235e7599f@DEWDFE13DE09.global.corp.sap> <5730778A.6020906@oracle.com> Message-ID: <891791dfc0e6464a800c9a738341e05a@DEWDFE13DE09.global.corp.sap> Sorry for the double failure! I think this really works now, Christoph verified it with VS2010, thanks! http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.03/ I just removed prefix_len, it's added to newbuf_len, below anyways. Best regards, Goetz. > -----Original Message----- > From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > Sent: Montag, 9. Mai 2016 13:42 > To: Lindenmaier, Goetz ; hotspot compiler > > Subject: Re: RFR(M): 8140594: Various minor code improvements (compiler) > > Hi Goetz, > > On 09.05.2016 12:30, Lindenmaier, Goetz wrote: > > Hi Tobias, > > > > sorry for that! No, it's not just missing include, windows does not > > implement snprintf before Visual Studio 2015. > > http://stackoverflow.com/questions/2915672/snprintf-and-visual-studio- > 2010 > > > > As this is only a build-time tool, I would prefer skipping this altogether > > above adding windows specific code: > > http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.02/ > > That's fine with me but unfortunately the build still fails on Windows: > > c:/jprt/T/P1/105246.tohartma/s/hotspot/src/share/vm/logging/logTagSet.cp > p(112) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of > data > > Best regards, > Tobias > > > > Best regrds, > > Goetz. > > > > > > > >> -----Original Message----- > >> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] > >> Sent: Montag, 9. Mai 2016 11:08 > >> To: Lindenmaier, Goetz ; hotspot compiler > >> > >> Subject: Re: RFR(M): 8140594: Various minor code improvements > (compiler) > >> > >> Hi Goetz, > >> > >> the build failed on Windows with: > >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(721) > : > >> error C3861: 'snprintf': identifier not found > >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(723) > : > >> error C3861: 'snprintf': identifier not found > >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(728) > : > >> error C3861: 'snprintf': identifier not found > >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(730) > : > >> error C3861: 'snprintf': identifier not found > >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(740) > : > >> error C3861: 'snprintf': identifier not found > >> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(742) > : > >> error C3861: 'snprintf': identifier not found > >> > >> Looks like a missing include. > >> > >> Best regards, > >> Tobias > >> > >> On 09.05.2016 10:40, Tobias Hartmann wrote: > >>> Hi Goetz, > >>> > >>> thanks for the explanation, this looks good to me! > >>> > >>> I'm running the hs-comp PIT now and will push the fix afterwards, if > there > >> are no objections. > >>> > >>> Thanks, > >>> Tobias > >>> > >>> On 09.05.2016 10:30, Lindenmaier, Goetz wrote: > >>>> Hi Tobias, > >>>> > >>>>> I can sponsor your fix but since we are close to JDK 9 FC, we are not > >> allowed > >>>>> to push enhancements to hs-comp. Shouldn't this be a "bug" anyway? > >>>> Thanks for reviewing and the offer to sponsor! > >>>> I changed the Jira issue to bug. Sorry for being that close to FC with my > >> RFR. > >>>> > >>>>>> - size of pointer passed to jio_snprintf() > >>>>> Please also fix the indentation in line 6004. > >>>> Fixed. > >>>> > >>>>>> classLoader.cpp > >>>>>> - jio_snprintf does null termination. But it might return -1 if > truncated, > >>>>>> in this case array access at -1. > >>>>> You can remove "int n;" > >>>> Fixed. > >>>> > >>>>>> generateOopMap.cpp > >>>>>> - Remaining fields not initialized. > >>>>> I would put the loop bodies in a new line. > >>>> Fixed. > >>>> > >>>>>> relocator.cpp > >>>>>> - delta might be -4 ... assert returns. > >>>>> I don't understand this change. If delta is -4, the assert in the baseline > >> version > >>>>> is triggered. With your fix, the assert is triggered as well. > >>>> > >>>> Sorry, that's a bad comment. I meant that the assert does not > >>>> protect against getting -4 in that line, because coverity knows > >>>> about -XX:SuppressErrorAt. But that's pointless, as assert goes > >>>> away in product builds anyways. > >>>> > >>>> The assert shall be triggered, therefore I moved it out of the if(). > >>>> But the if() now protects against oob with -4 or smaller. > >>>> > >>>> I also rebased the change, and added you as reviewer. Find the new > >>>> Webrev here: > >>>> http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.01/ > >>>> And the incremental patch: > >>>> http://cr.openjdk.java.net/~goetz/wr16/8140594- > >> covCo/webrev.01/incremental_diff.patch > >>>> > >>>> Best regards, > >>>> Goetz. > >>>> From goetz.lindenmaier at sap.com Mon May 9 14:02:31 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 9 May 2016 14:02:31 +0000 Subject: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted In-Reply-To: <57307B74.9030703@oracle.com> References: <572C7E34.60608@oracle.com> <82fe858d208f4bb8916e9cd4472d140e@DEWDFE13DE09.global.corp.sap> <57307B74.9030703@oracle.com> Message-ID: <0d12bff834244064a0dc1757827294fb@DEWDFE13DE09.global.corp.sap> Hi Jamsheed, thanks for fixing this. I think this way compiler optimizations should be forbidden. What about the other platforms? If no one else objects, take it as reviewed. Best regards, Goetz. > -----Original Message----- > From: Jamsheed C m [mailto:jamsheed.c.m at oracle.com] > Sent: Montag, 9. Mai 2016 13:59 > To: Lindenmaier, Goetz ; hotspot compiler > > Subject: Re: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted > > Hi Goetz, > > Thank you for looking at this. > > > On 5/9/2016 2:22 PM, Lindenmaier, Goetz wrote: > > > Hi Jamsheed, > > Do you want to avoid that data/destination are changed concurrently > between the two compares? Or do you just want to save costs of the > call? > > This change was done in x86 as part of JDK-8062493 > . from the comment > in the change, it says its meant for first case. but, i couldn't find a case in > current hotspot code where this could happen. > may be its a precautionary change. ( Chris can help here). > > > > > To assure the first, you need to make the two local variables volatile. > Else the compilers can add reloads after inlining data() and > jump_destination(). > We observed this with the Visual Studio compiler and xlC on aix. > > i have made the two local variables as volatile. > revised webrev: http://cr.openjdk.java.net/~jcm/8144856/webrev.01/ > > Best Regards, > Jamsheed > > > > > Besides that the change looks good. > > Best regards, > Goetz. > > > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net > ] On Behalf Of Jamsheed C m > Sent: Freitag, 6. Mai 2016 13:21 > To: hotspot compiler dev at openjdk.java.net> > Subject: RFR: 8144856 : fix assert in > CompiledStaticCall::set_to_interpreted > > > Hi, > > Request for review for an assert cleanup change. > bug id : https://bugs.openjdk.java.net/browse/JDK-8144856 > webrev: > http://cr.openjdk.java.net/~jcm/8144856/webrev.00/ > > Best Regards, > Jamsheed > > > > From tobias.hartmann at oracle.com Mon May 9 14:14:35 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 May 2016 16:14:35 +0200 Subject: RFR(M): 8140594: Various minor code improvements (compiler) In-Reply-To: <891791dfc0e6464a800c9a738341e05a@DEWDFE13DE09.global.corp.sap> References: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> <57303E00.1000801@oracle.com> <3ecea76a5493429a970a217cf171adf6@DEWDFE13DE09.global.corp.sap> <57304D01.4010006@oracle.com> <57305383.1090005@oracle.com> <401c1fc87d974708a404793235e7599f@DEWDFE13DE09.global.corp.sap> <5730778A.6020906@oracle.com> <891791dfc0e6464a800c9a738341e05a@DEWDFE13DE09.global.corp.sap> Message-ID: <57309B4B.4050302@oracle.com> Hi Goetz, On 09.05.2016 15:11, Lindenmaier, Goetz wrote: > Sorry for the double failure! > I think this really works now, Christoph verified it with VS2010, thanks! > http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.03/ > > I just removed prefix_len, it's added to newbuf_len, below anyways. Looks good! The build completed on all platforms. PIT is running. Best regards, Tobias > Best regards, > Goetz. > > > >> -----Original Message----- >> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >> Sent: Montag, 9. Mai 2016 13:42 >> To: Lindenmaier, Goetz ; hotspot compiler >> >> Subject: Re: RFR(M): 8140594: Various minor code improvements (compiler) >> >> Hi Goetz, >> >> On 09.05.2016 12:30, Lindenmaier, Goetz wrote: >>> Hi Tobias, >>> >>> sorry for that! No, it's not just missing include, windows does not >>> implement snprintf before Visual Studio 2015. >>> http://stackoverflow.com/questions/2915672/snprintf-and-visual-studio- >> 2010 >>> >>> As this is only a build-time tool, I would prefer skipping this altogether >>> above adding windows specific code: >>> http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.02/ >> >> That's fine with me but unfortunately the build still fails on Windows: >> >> c:/jprt/T/P1/105246.tohartma/s/hotspot/src/share/vm/logging/logTagSet.cp >> p(112) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of >> data >> >> Best regards, >> Tobias >>> >>> Best regrds, >>> Goetz. >>> >>> >>> >>>> -----Original Message----- >>>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >>>> Sent: Montag, 9. Mai 2016 11:08 >>>> To: Lindenmaier, Goetz ; hotspot compiler >>>> >>>> Subject: Re: RFR(M): 8140594: Various minor code improvements >> (compiler) >>>> >>>> Hi Goetz, >>>> >>>> the build failed on Windows with: >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(721) >> : >>>> error C3861: 'snprintf': identifier not found >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(723) >> : >>>> error C3861: 'snprintf': identifier not found >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(728) >> : >>>> error C3861: 'snprintf': identifier not found >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(730) >> : >>>> error C3861: 'snprintf': identifier not found >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(740) >> : >>>> error C3861: 'snprintf': identifier not found >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(742) >> : >>>> error C3861: 'snprintf': identifier not found >>>> >>>> Looks like a missing include. >>>> >>>> Best regards, >>>> Tobias >>>> >>>> On 09.05.2016 10:40, Tobias Hartmann wrote: >>>>> Hi Goetz, >>>>> >>>>> thanks for the explanation, this looks good to me! >>>>> >>>>> I'm running the hs-comp PIT now and will push the fix afterwards, if >> there >>>> are no objections. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> On 09.05.2016 10:30, Lindenmaier, Goetz wrote: >>>>>> Hi Tobias, >>>>>> >>>>>>> I can sponsor your fix but since we are close to JDK 9 FC, we are not >>>> allowed >>>>>>> to push enhancements to hs-comp. Shouldn't this be a "bug" anyway? >>>>>> Thanks for reviewing and the offer to sponsor! >>>>>> I changed the Jira issue to bug. Sorry for being that close to FC with my >>>> RFR. >>>>>> >>>>>>>> - size of pointer passed to jio_snprintf() >>>>>>> Please also fix the indentation in line 6004. >>>>>> Fixed. >>>>>> >>>>>>>> classLoader.cpp >>>>>>>> - jio_snprintf does null termination. But it might return -1 if >> truncated, >>>>>>>> in this case array access at -1. >>>>>>> You can remove "int n;" >>>>>> Fixed. >>>>>> >>>>>>>> generateOopMap.cpp >>>>>>>> - Remaining fields not initialized. >>>>>>> I would put the loop bodies in a new line. >>>>>> Fixed. >>>>>> >>>>>>>> relocator.cpp >>>>>>>> - delta might be -4 ... assert returns. >>>>>>> I don't understand this change. If delta is -4, the assert in the baseline >>>> version >>>>>>> is triggered. With your fix, the assert is triggered as well. >>>>>> >>>>>> Sorry, that's a bad comment. I meant that the assert does not >>>>>> protect against getting -4 in that line, because coverity knows >>>>>> about -XX:SuppressErrorAt. But that's pointless, as assert goes >>>>>> away in product builds anyways. >>>>>> >>>>>> The assert shall be triggered, therefore I moved it out of the if(). >>>>>> But the if() now protects against oob with -4 or smaller. >>>>>> >>>>>> I also rebased the change, and added you as reviewer. Find the new >>>>>> Webrev here: >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.01/ >>>>>> And the incremental patch: >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8140594- >>>> covCo/webrev.01/incremental_diff.patch >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> From vladimir.kozlov at oracle.com Mon May 9 16:51:19 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 9 May 2016 09:51:19 -0700 Subject: RFR(M): 8140594: Various minor code improvements (compiler) In-Reply-To: <891791dfc0e6464a800c9a738341e05a@DEWDFE13DE09.global.corp.sap> References: <677b553592a74be9ba23c809b5dd32bd@DEWDFE13DE09.global.corp.sap> <57303E00.1000801@oracle.com> <3ecea76a5493429a970a217cf171adf6@DEWDFE13DE09.global.corp.sap> <57304D01.4010006@oracle.com> <57305383.1090005@oracle.com> <401c1fc87d974708a404793235e7599f@DEWDFE13DE09.global.corp.sap> <5730778A.6020906@oracle.com> <891791dfc0e6464a800c9a738341e05a@DEWDFE13DE09.global.corp.sap> Message-ID: <5730C007.8000109@oracle.com> This looks good to me. Thank you for cleaning up, Goetz. Vladimir On 5/9/16 6:11 AM, Lindenmaier, Goetz wrote: > Sorry for the double failure! > I think this really works now, Christoph verified it with VS2010, thanks! > http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.03/ > > I just removed prefix_len, it's added to newbuf_len, below anyways. > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >> Sent: Montag, 9. Mai 2016 13:42 >> To: Lindenmaier, Goetz ; hotspot compiler >> >> Subject: Re: RFR(M): 8140594: Various minor code improvements (compiler) >> >> Hi Goetz, >> >> On 09.05.2016 12:30, Lindenmaier, Goetz wrote: >>> Hi Tobias, >>> >>> sorry for that! No, it's not just missing include, windows does not >>> implement snprintf before Visual Studio 2015. >>> http://stackoverflow.com/questions/2915672/snprintf-and-visual-studio- >> 2010 >>> >>> As this is only a build-time tool, I would prefer skipping this altogether >>> above adding windows specific code: >>> http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.02/ >> >> That's fine with me but unfortunately the build still fails on Windows: >> >> c:/jprt/T/P1/105246.tohartma/s/hotspot/src/share/vm/logging/logTagSet.cp >> p(112) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of >> data >> >> Best regards, >> Tobias >>> >>> Best regrds, >>> Goetz. >>> >>> >>> >>>> -----Original Message----- >>>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] >>>> Sent: Montag, 9. Mai 2016 11:08 >>>> To: Lindenmaier, Goetz ; hotspot compiler >>>> >>>> Subject: Re: RFR(M): 8140594: Various minor code improvements >> (compiler) >>>> >>>> Hi Goetz, >>>> >>>> the build failed on Windows with: >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(721) >> : >>>> error C3861: 'snprintf': identifier not found >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(723) >> : >>>> error C3861: 'snprintf': identifier not found >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(728) >> : >>>> error C3861: 'snprintf': identifier not found >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(730) >> : >>>> error C3861: 'snprintf': identifier not found >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(740) >> : >>>> error C3861: 'snprintf': identifier not found >>>> c:/jprt/T/P1/083823.tohartma/s/hotspot/src/share/vm/adlc/dfa.cpp(742) >> : >>>> error C3861: 'snprintf': identifier not found >>>> >>>> Looks like a missing include. >>>> >>>> Best regards, >>>> Tobias >>>> >>>> On 09.05.2016 10:40, Tobias Hartmann wrote: >>>>> Hi Goetz, >>>>> >>>>> thanks for the explanation, this looks good to me! >>>>> >>>>> I'm running the hs-comp PIT now and will push the fix afterwards, if >> there >>>> are no objections. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> On 09.05.2016 10:30, Lindenmaier, Goetz wrote: >>>>>> Hi Tobias, >>>>>> >>>>>>> I can sponsor your fix but since we are close to JDK 9 FC, we are not >>>> allowed >>>>>>> to push enhancements to hs-comp. Shouldn't this be a "bug" anyway? >>>>>> Thanks for reviewing and the offer to sponsor! >>>>>> I changed the Jira issue to bug. Sorry for being that close to FC with my >>>> RFR. >>>>>> >>>>>>>> - size of pointer passed to jio_snprintf() >>>>>>> Please also fix the indentation in line 6004. >>>>>> Fixed. >>>>>> >>>>>>>> classLoader.cpp >>>>>>>> - jio_snprintf does null termination. But it might return -1 if >> truncated, >>>>>>>> in this case array access at -1. >>>>>>> You can remove "int n;" >>>>>> Fixed. >>>>>> >>>>>>>> generateOopMap.cpp >>>>>>>> - Remaining fields not initialized. >>>>>>> I would put the loop bodies in a new line. >>>>>> Fixed. >>>>>> >>>>>>>> relocator.cpp >>>>>>>> - delta might be -4 ... assert returns. >>>>>>> I don't understand this change. If delta is -4, the assert in the baseline >>>> version >>>>>>> is triggered. With your fix, the assert is triggered as well. >>>>>> >>>>>> Sorry, that's a bad comment. I meant that the assert does not >>>>>> protect against getting -4 in that line, because coverity knows >>>>>> about -XX:SuppressErrorAt. But that's pointless, as assert goes >>>>>> away in product builds anyways. >>>>>> >>>>>> The assert shall be triggered, therefore I moved it out of the if(). >>>>>> But the if() now protects against oob with -4 or smaller. >>>>>> >>>>>> I also rebased the change, and added you as reviewer. Find the new >>>>>> Webrev here: >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8140594-covCo/webrev.01/ >>>>>> And the incremental patch: >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8140594- >>>> covCo/webrev.01/incremental_diff.patch >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> From christian.thalinger at oracle.com Mon May 9 17:16:38 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 May 2016 07:16:38 -1000 Subject: RFR: 8156211: [JVMCI] ResolvedJava* interfaces should extend AnnotatedElement In-Reply-To: <57305ABC.2010804@oracle.com> References: <572C8B7E.5020304@oracle.com> <94E88818-DE33-4778-9D98-153EF68978A9@oracle.com> <57305ABC.2010804@oracle.com> Message-ID: > On May 8, 2016, at 11:39 PM, Roland Schatz wrote: > > Whoops... Good catch. > > Fixed: > http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.01/ Looks good. One nit: + public Annotation[] getDeclaredAnnotations() { + Field javaField = toJava(); + if (javaField != null) { + return javaField.getDeclaredAnnotations(); + } + return new Annotation[0]; + } + public Annotation[] getDeclaredAnnotations() { + Executable javaMethod = toJava(); + return javaMethod == null ? new Annotation[0] : javaMethod.getDeclaredAnnotations(); + } Make them look the same. > > - Roland > > On 05/06/2016 11:24 PM, Christian Thalinger wrote: >> >>> On May 6, 2016, at 2:18 AM, Roland Schatz < roland.schatz at oracle.com > wrote: >>> >>> Please review this small jvmci change: >>> >>> http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8156211 src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java >> >> + public Annotation[] getDeclaredAnnotations() { >> + Executable javaMethod = toJava(); >> + return javaMethod == null ? null : javaMethod.getDeclaredAnnotations(); >> + } >> This seems wrong. The specification says: >> >> * If there are no annotations directly present on this element, >> * the return value is an array of length 0. >> >> and the others return an empty array. >> >>> >>> This change was contributed by Vojin Jovanovic (cc'ed). >>> >>> Thanks, >>> Roland >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon May 9 17:21:04 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 May 2016 07:21:04 -1000 Subject: RFR(S): 8156025: [JVMCI] make HotSpotResolvedObjectTypeImpl.createField non-public In-Reply-To: <57305859.1080401@oracle.com> References: <5729FDB9.2080205@oracle.com> <572C617B.8060204@oracle.com> <1AC0B756-42F9-44F1-8E1F-78F426BB69B7@oracle.com> <57305859.1080401@oracle.com> Message-ID: <2EA5FD48-92E5-4FB5-8747-CC943E5FCA0C@oracle.com> > On May 8, 2016, at 11:28 PM, Roland Schatz wrote: > > On 05/06/2016 11:19 PM, Christian Thalinger wrote: >>> On May 5, 2016, at 11:18 PM, Roland Schatz wrote: >>> >>> On 05/04/2016 09:20 PM, Christian Thalinger wrote: >>>>> On May 4, 2016, at 3:48 AM, Roland Schatz wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review: >>>>> http://cr.openjdk.java.net/~rschatz/JDK-8156025/webrev.00/hotspot.changeset >>>>> https://bugs.openjdk.java.net/browse/JDK-8156025 >>>>> >>>>> This method is used only internally, it should never have been public. >>>> Looks good. All JVMCI tests pass? >>> At least no new failures, as far as I can tell. >>> >>> Looks like quite a few are failing anyway on the current tip. >>>> Test results: passed: 43; failed: 26; error: 5 >>> Or am I doing something wrong running the test? >> You must be doing something wrong. How are you running them? Also, use -ignore:quiet to not show the ignored tests (the errors). > > Just tried that on current hs-comp tip (clean rebuild, i.e. "rm -rf build JTwork JTreport; bash configure; make"): > >> [roland at oracle-rs hs-comp]$ ~/jtreg/bin/jtreg -testjdk build/linux-x86_64-normal-server-release/jdk -ignore:quiet hotspot/test/compiler/jvmci >> Directory "JTwork" not found: creating >> Directory "JTreport" not found: creating >> Test results: passed: 43; failed: 26 >> Report written to /home/roland/hg/jdk9/hs-comp/JTreport/html/report.html >> Results written to /home/roland/hg/jdk9/hs-comp/JTwork >> Error: Some tests failed or other problems occurred. That is really odd. Oh, that?s the exploded JDK; somehow it doesn?t work: java.lang.NoClassDefFoundError: jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod at compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:126) at java.util.ArrayList.forEach(java.base/ArrayList.java:1352) at compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base/Method.java:531) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(java.base/Thread.java:843) Caused by: java.lang.ClassNotFoundException: jdk.vm.ci.hotspot.HotSpotResolvedJavaMethod at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base/BuiltinClassLoader.java:366) at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base/ClassLoaders.java:184) at java.lang.ClassLoader.loadClass(java.base/ClassLoader.java:419) ... 9 more Build the image and use that. > > > >> >>> >>> - Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon May 9 17:34:28 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 May 2016 07:34:28 -1000 Subject: RFR 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider In-Reply-To: <572E611D.7020700@oracle.com> References: <572CA963.3030906@oracle.com> <8CE8A2DA-4E8A-47F6-86E1-E083442F7B2C@oracle.com> <572E611D.7020700@oracle.com> Message-ID: > On May 7, 2016, at 11:41 AM, dmitrij pochepko wrote: > >> >> >>> On May 6, 2016, at 4:25 AM, Dmitrij Pochepko > wrote: >>> >>> Hi, >>> >>> please review patch for 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider >>> >>> A new tests were added for jdk.vm.ci.meta.MetaAccessProvider implementation. An existing TestMetaAccessProvider.java was used to add new tests. >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8152343/webrev.01/ + private static final int[] VALID_ENCODED_VALUES = new int[]{-180, -436, -10932, -2147483572}; >> What are these values? Maybe it would make more sense to have them in hex-form? > These values are encoded values for deoptReason=Aliasing, deoptAction=InvalidateRecompile and debugId={0, 1, 42, 8388607} > so, we have 0, 1, , 0x7FFFFF which is a maximum debugId value here(all 23 bits set) > > I've created another webrev with hex values and respective comment added. > > http://cr.openjdk.java.net/~dpochepk/8152343/webrev.02 Better but I still don?t like them being hardcoded. You should calculate the values with some defined constants so that someone after you can understand what?s going on and be able to make changes. Also, what is this supposed to test? + @Test + public void decodeDeoptReasonTest() { + for (int encoded : VALID_ENCODED_VALUES) { + JavaConstant value = JavaConstant.forInt(encoded); + DeoptimizationReason reason = metaAccess.decodeDeoptReason(value); + DeoptimizationReason reason2 = metaAccess.decodeDeoptReason(value); + assertNotNull("Expected not null reason", reason); + assertEquals("Expected equal reasons", reason, reason2); + } + } That two invocations of the same method on the same receiver with the same value return the same value? I don?t see how that could fail. > > Thanks, > Dmitrij >> >> >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8152343 >>> >>> I've tested it on linux_x64. >>> >>> Thanks, >>> Dmitrij >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon May 9 18:28:48 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 9 May 2016 11:28:48 -0700 Subject: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted In-Reply-To: <57307B74.9030703@oracle.com> References: <572C7E34.60608@oracle.com> <82fe858d208f4bb8916e9cd4472d140e@DEWDFE13DE09.global.corp.sap> <57307B74.9030703@oracle.com> Message-ID: <5730D6E0.6020909@oracle.com> Jamsheed, your changes looks good. Thanks, Vladimir On 5/9/16 4:58 AM, Jamsheed C m wrote: > Hi Goetz, > > Thank you for looking at this. > > On 5/9/2016 2:22 PM, Lindenmaier, Goetz wrote: >> Hi Jamsheed, >> >> Do you want to avoid that data/destination are changed concurrently >> between the two compares? Or do you just want to save costs of the call? > This change was done in x86 as part of JDK-8062493 > . from the comment in > the change, it says its meant for first case. but, i couldn't find a > case in current hotspot code where this could happen. > may be its a precautionary change. ( Chris can help here). >> >> To assure the first, you need to make the two local variables volatile. >> Else the compilers can add reloads after inlining data() and jump_destination(). >> We observed this with the Visual Studio compiler and xlC on aix. > i have made the two local variables as volatile. > revised webrev: http://cr.openjdk.java.net/~jcm/8144856/webrev.01/ > > Best Regards, > Jamsheed >> >> Besides that the change looks good. >> >> Best regards, >> Goetz. >> >> >> >>> -----Original Message----- >>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >>> bounces at openjdk.java.net] On Behalf Of Jamsheed C m >>> Sent: Freitag, 6. Mai 2016 13:21 >>> To: hotspot compiler >>> Subject: RFR: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted >>> >>> >>> Hi, >>> >>> Request for review for an assert cleanup change. >>> bug id :https://bugs.openjdk.java.net/browse/JDK-8144856 >>> webrev:http://cr.openjdk.java.net/~jcm/8144856/webrev.00/ >>> >>> Best Regards, >>> Jamsheed >>> > From christian.thalinger at oracle.com Mon May 9 19:00:05 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 May 2016 09:00:05 -1000 Subject: RFR: 8156159: replace CompilerToVM.readUncompressedOop with Unsafe.getUncompressedObject Message-ID: <8C8EEEAD-44F3-489E-84A6-A5476B34F87D@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8156159 JDK-8022853 added the required methods to Unsafe. It's time to switch over. -------------- next part -------------- A non-text attachment was scrubbed... Name: 8156159.patch Type: application/octet-stream Size: 9705 bytes Desc: not available URL: From vladimir.kozlov at oracle.com Mon May 9 19:05:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 9 May 2016 12:05:20 -0700 Subject: RFR: 8156159: replace CompilerToVM.readUncompressedOop with Unsafe.getUncompressedObject In-Reply-To: <8C8EEEAD-44F3-489E-84A6-A5476B34F87D@oracle.com> References: <8C8EEEAD-44F3-489E-84A6-A5476B34F87D@oracle.com> Message-ID: <5730DF70.3040504@oracle.com> Please, send webrev on cr. server. Thanks, Vladimir On 5/9/16 12:00 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8156159 > > JDK-8022853 added the required methods to Unsafe. It's time to switch over. > From christian.thalinger at oracle.com Mon May 9 19:22:49 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 May 2016 09:22:49 -1000 Subject: RFR: 8156159: replace CompilerToVM.readUncompressedOop with Unsafe.getUncompressedObject In-Reply-To: <5730DF70.3040504@oracle.com> References: <8C8EEEAD-44F3-489E-84A6-A5476B34F87D@oracle.com> <5730DF70.3040504@oracle.com> Message-ID: > On May 9, 2016, at 9:05 AM, Vladimir Kozlov wrote: > > Please, send webrev on cr. server. Grrrr :-) http://cr.openjdk.java.net/~twisti/8156159/ > > Thanks, > Vladimir > > On 5/9/16 12:00 PM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8156159 >> >> JDK-8022853 added the required methods to Unsafe. It's time to switch over. >> From vladimir.kozlov at oracle.com Mon May 9 19:51:06 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 9 May 2016 12:51:06 -0700 Subject: RFR: 8156159: replace CompilerToVM.readUncompressedOop with Unsafe.getUncompressedObject In-Reply-To: References: <8C8EEEAD-44F3-489E-84A6-A5476B34F87D@oracle.com> <5730DF70.3040504@oracle.com> Message-ID: <5730EA2A.2070503@oracle.com> Looks good. Thanks, Vladimir On 5/9/16 12:22 PM, Christian Thalinger wrote: > >> On May 9, 2016, at 9:05 AM, Vladimir Kozlov wrote: >> >> Please, send webrev on cr. server. > > Grrrr :-) > > http://cr.openjdk.java.net/~twisti/8156159/ > >> >> Thanks, >> Vladimir >> >> On 5/9/16 12:00 PM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8156159 >>> >>> JDK-8022853 added the required methods to Unsafe. It's time to switch over. >>> > From christian.thalinger at oracle.com Mon May 9 19:59:30 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 May 2016 09:59:30 -1000 Subject: RFR: 8156159: replace CompilerToVM.readUncompressedOop with Unsafe.getUncompressedObject In-Reply-To: <5730EA2A.2070503@oracle.com> References: <8C8EEEAD-44F3-489E-84A6-A5476B34F87D@oracle.com> <5730DF70.3040504@oracle.com> <5730EA2A.2070503@oracle.com> Message-ID: <51222459-F715-49FE-B529-19EE6301146D@oracle.com> Thanks, Vladimir. > On May 9, 2016, at 9:51 AM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 5/9/16 12:22 PM, Christian Thalinger wrote: >> >>> On May 9, 2016, at 9:05 AM, Vladimir Kozlov wrote: >>> >>> Please, send webrev on cr. server. >> >> Grrrr :-) >> >> http://cr.openjdk.java.net/~twisti/8156159/ >> >>> >>> Thanks, >>> Vladimir >>> >>> On 5/9/16 12:00 PM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8156159 >>>> >>>> JDK-8022853 added the required methods to Unsafe. It's time to switch over. >>>> >> From vladimir.kozlov at oracle.com Mon May 9 21:06:39 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 9 May 2016 14:06:39 -0700 Subject: RFR (S): 8150247: CompilerControl: LogCompilation testing In-Reply-To: <1F1FA86E-3224-4523-827B-8885C3F7C6C3@oracle.com> References: <1F1FA86E-3224-4523-827B-8885C3F7C6C3@oracle.com> Message-ID: <5730FBDF.1090108@oracle.com> Looks good. Thank you for fixing this. Thanks, Vladimir On 5/6/16 12:35 PM, Pavel Punegov wrote: > Hi, > > I have updated webrev to add @module to jtreg header > http://cr.openjdk.java.net/~ppunegov/8150247/webrev.01/ > > ? Pavel. > >> On 05 May 2016, at 21:06, Pavel Punegov > > wrote: >> >> Hi, >> >> please review the following change to CompilerControl tests. It adds a >> new test to cover the gap found by JDK-8145345 [*]. >> The LogCompilation was empty after CompilerControl was integrated, but >> tests haven?t found that. This happened only when the LogCompilation >> was specified while there were no directives/CompileCommands enabled. >> With enabled directive/command it worked fine. >> >> Tests didn?t found the issue due to: >> 1. There were no standalone test for LogCompilation. All related tests >> enable appropriate log directive or command. >> 2. LogProcessor incorrectly worked for empty tasks that should be >> logged. It didn?t reported the issue. >> >> [*] https://bugs.openjdk.java.net/browse/JDK-8145345 >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8150247 >> webrev: http://cr.openjdk.java.net/~ppunegov/8150247/webrev.00/ > From vladimir.kozlov at oracle.com Mon May 9 22:16:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 9 May 2016 15:16:05 -0700 Subject: RFR(S): 8149463 - [jittester] rarely generates tests with compile error In-Reply-To: <572CB14A.8080009@oracle.com> References: <572CB14A.8080009@oracle.com> Message-ID: <57310C25.7040407@oracle.com> Seems fine. Thanks, Vladimir On 5/6/16 7:59 AM, Dmitrij Pochepko wrote: > Hi, > > please review fix for 8149463 - [jittester] rarely generates tests with > compile error > > A reason for incorrect code generation was "removeSelf" method, which is > called when IR tree is cut to meet constraints. This method is > implemented in all loops to not remove node loop completely, but leave > some of node content instead("header" and "initialization". In this > specific order.) So, incorrect code was generated in case header code > used some variable declared in initialization block, thus, leading to > variable usage before declaration. So, this patch fixes this problem. > Also, minor code improvement: instead of removing self(loop node), it's > overwritten with "initialization" block and then a header content is added. > > webrev: http://cr.openjdk.java.net/~dpochepk/8149463/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8149463 > > I've tested this fix using linux_x64. > > Thanks, > Dmitrij From jamsheed.c.m at oracle.com Tue May 10 06:09:55 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 10 May 2016 11:39:55 +0530 Subject: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted In-Reply-To: <0d12bff834244064a0dc1757827294fb@DEWDFE13DE09.global.corp.sap> References: <572C7E34.60608@oracle.com> <82fe858d208f4bb8916e9cd4472d140e@DEWDFE13DE09.global.corp.sap> <57307B74.9030703@oracle.com> <0d12bff834244064a0dc1757827294fb@DEWDFE13DE09.global.corp.sap> Message-ID: <57317B33.1020202@oracle.com> Thank you Goetz. Best Regards, Jamsheed On 5/9/2016 7:32 PM, Lindenmaier, Goetz wrote: > Hi Jamsheed, > > thanks for fixing this. I think this way compiler optimizations should be > forbidden. What about the other platforms? If no one else objects, > take it as reviewed. > > Best regards, > Goetz. > >> -----Original Message----- >> From: Jamsheed C m [mailto:jamsheed.c.m at oracle.com] >> Sent: Montag, 9. Mai 2016 13:59 >> To: Lindenmaier, Goetz ; hotspot compiler >> >> Subject: Re: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted >> >> Hi Goetz, >> >> Thank you for looking at this. >> >> >> On 5/9/2016 2:22 PM, Lindenmaier, Goetz wrote: >> >> >> Hi Jamsheed, >> >> Do you want to avoid that data/destination are changed concurrently >> between the two compares? Or do you just want to save costs of the >> call? >> >> This change was done in x86 as part of JDK-8062493 >> . from the comment >> in the change, it says its meant for first case. but, i couldn't find a case in >> current hotspot code where this could happen. >> may be its a precautionary change. ( Chris can help here). >> >> >> >> >> To assure the first, you need to make the two local variables volatile. >> Else the compilers can add reloads after inlining data() and >> jump_destination(). >> We observed this with the Visual Studio compiler and xlC on aix. >> >> i have made the two local variables as volatile. >> revised webrev: http://cr.openjdk.java.net/~jcm/8144856/webrev.01/ >> >> Best Regards, >> Jamsheed >> >> >> >> >> Besides that the change looks good. >> >> Best regards, >> Goetz. >> >> >> >> >> -----Original Message----- >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >> bounces at openjdk.java.net >> ] On Behalf Of Jamsheed C m >> Sent: Freitag, 6. Mai 2016 13:21 >> To: hotspot compiler > dev at openjdk.java.net> >> Subject: RFR: 8144856 : fix assert in >> CompiledStaticCall::set_to_interpreted >> >> >> Hi, >> >> Request for review for an assert cleanup change. >> bug id : https://bugs.openjdk.java.net/browse/JDK-8144856 >> webrev: >> http://cr.openjdk.java.net/~jcm/8144856/webrev.00/ >> >> Best Regards, >> Jamsheed >> >> >> >> From jamsheed.c.m at oracle.com Tue May 10 06:10:32 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 10 May 2016 11:40:32 +0530 Subject: 8144856 : fix assert in CompiledStaticCall::set_to_interpreted In-Reply-To: <5730D6E0.6020909@oracle.com> References: <572C7E34.60608@oracle.com> <82fe858d208f4bb8916e9cd4472d140e@DEWDFE13DE09.global.corp.sap> <57307B74.9030703@oracle.com> <5730D6E0.6020909@oracle.com> Message-ID: <57317B58.9050905@oracle.com> Thank you Vladimir. Best Regards, Jamsheed On 5/9/2016 11:58 PM, Vladimir Kozlov wrote: > Jamsheed, your changes looks good. > > Thanks, > Vladimir > > On 5/9/16 4:58 AM, Jamsheed C m wrote: >> Hi Goetz, >> >> Thank you for looking at this. >> >> On 5/9/2016 2:22 PM, Lindenmaier, Goetz wrote: >>> Hi Jamsheed, >>> >>> Do you want to avoid that data/destination are changed concurrently >>> between the two compares? Or do you just want to save costs of the >>> call? >> This change was done in x86 as part of JDK-8062493 >> . from the comment in >> the change, it says its meant for first case. but, i couldn't find a >> case in current hotspot code where this could happen. >> may be its a precautionary change. ( Chris can help here). >>> >>> To assure the first, you need to make the two local variables volatile. >>> Else the compilers can add reloads after inlining data() and >>> jump_destination(). >>> We observed this with the Visual Studio compiler and xlC on aix. >> i have made the two local variables as volatile. >> revised webrev: http://cr.openjdk.java.net/~jcm/8144856/webrev.01/ >> >> Best Regards, >> Jamsheed >>> >>> Besides that the change looks good. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>>> -----Original Message----- >>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >>>> bounces at openjdk.java.net] On Behalf Of Jamsheed C m >>>> Sent: Freitag, 6. Mai 2016 13:21 >>>> To: hotspot compiler >>>> Subject: RFR: 8144856 : fix assert in >>>> CompiledStaticCall::set_to_interpreted >>>> >>>> >>>> Hi, >>>> >>>> Request for review for an assert cleanup change. >>>> bug id :https://bugs.openjdk.java.net/browse/JDK-8144856 >>>> webrev:http://cr.openjdk.java.net/~jcm/8144856/webrev.00/ >>>> >>>> Best Regards, >>>> Jamsheed >>>> >> From rwestrel at redhat.com Tue May 10 07:01:21 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 10 May 2016 09:01:21 +0200 Subject: RFR(M): 8154826: AArch64: take better advantage of base + shifted offset addressing mode In-Reply-To: References: <57188E03.5070303@redhat.com> <571E20BD.3030907@redhat.com> <5729A6D9.3010606@redhat.com> <572BE1E5.1040206@oracle.com> <572C6F74.1030907@redhat.com> <8af6680d-e44e-ce5c-d9cc-e95c728b48a5@oracle.com> <14eeba23-322a-be47-b854-56abb68d6418@oracle.com> Message-ID: <57318741.5010703@redhat.com> Thanks for pushing, Vladimir. Roland. On 05/09/2016 11:57 AM, Roland Westrelin wrote: > > Hi Vladimir, > >> Does not build: >> >> "hotspot/src/cpu/x86/vm/x86.ad", line 1898: Error: The type "AddPNode" is incomplete. >> ... >> > > Indeed it doesn't build with precompiled headers off. > > I updated: > > http://cr.openjdk.java.net/~roland/8154826/8154826.patch > > with the patch below. > > Roland. > > diff --git a/src/cpu/aarch64/vm/aarch64.ad b/src/cpu/aarch64/vm/aarch64.ad > --- a/src/cpu/aarch64/vm/aarch64.ad > +++ b/src/cpu/aarch64/vm/aarch64.ad > @@ -996,6 +996,7 @@ > source_hpp %{ > > #include "gc/shared/cardTableModRefBS.hpp" > +#include "opto/addnode.hpp" > > class CallStubImpl { > > diff --git a/src/cpu/x86/vm/x86.ad b/src/cpu/x86/vm/x86.ad > --- a/src/cpu/x86/vm/x86.ad > +++ b/src/cpu/x86/vm/x86.ad > @@ -1586,6 +1586,8 @@ > > source %{ > > +#include "opto/addnode.hpp" > + > // Emit exception handler code. > // Stuff framesize into a register and call a VM stub routine. > int HandlerImpl::emit_exception_handler(CodeBuffer& cbuf) { > From roland.schatz at oracle.com Tue May 10 09:25:30 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Tue, 10 May 2016 11:25:30 +0200 Subject: RFR: 8156211: [JVMCI] ResolvedJava* interfaces should extend AnnotatedElement In-Reply-To: References: <572C8B7E.5020304@oracle.com> <94E88818-DE33-4778-9D98-153EF68978A9@oracle.com> <57305ABC.2010804@oracle.com> Message-ID: <5731A90A.50908@oracle.com> On 05/09/2016 07:16 PM, Christian Thalinger wrote: > >> On May 8, 2016, at 11:39 PM, Roland Schatz > > wrote: >> >> Whoops... Good catch. >> >> Fixed: >> http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.01/ > > Looks good. One nit: > + public Annotation[] getDeclaredAnnotations() { > + Field javaField = toJava(); > + if (javaField != null) { > + return javaField.getDeclaredAnnotations(); > + } > + return new Annotation[0]; > + } > + public Annotation[] getDeclaredAnnotations() { > + Executable javaMethod = toJava(); > + return javaMethod == null ? new Annotation[0] : > javaMethod.getDeclaredAnnotations(); > + } > Make them look the same. Done (and also made the existing getAnnotations() methods look the same, while we're at it). http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.02/ - Roland > >> >> - Roland >> >> On 05/06/2016 11:24 PM, Christian Thalinger wrote: >>> >>>> On May 6, 2016, at 2:18 AM, Roland Schatz >>>> wrote: >>>> >>>> Please review this small jvmci change: >>>> >>>> http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.00/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8156211 >>> >>> >>> src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java >>> >>> + public Annotation[] getDeclaredAnnotations() { >>> + Executable javaMethod = toJava(); >>> + return javaMethod == null ? null : >>> javaMethod.getDeclaredAnnotations(); >>> + } >>> This seems wrong. The specification says: >>> >>> * If there are no annotations directly present on this >>> element, >>> * the return value is an array of length 0. >>> >>> and the others return an empty array. >>> >>>> >>>> This change was contributed by Vojin Jovanovic (cc'ed). >>>> >>>> Thanks, >>>> Roland >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.schatz at oracle.com Tue May 10 09:33:20 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Tue, 10 May 2016 11:33:20 +0200 Subject: RFR(S): 8156025: [JVMCI] make HotSpotResolvedObjectTypeImpl.createField non-public In-Reply-To: <2EA5FD48-92E5-4FB5-8747-CC943E5FCA0C@oracle.com> References: <5729FDB9.2080205@oracle.com> <572C617B.8060204@oracle.com> <1AC0B756-42F9-44F1-8E1F-78F426BB69B7@oracle.com> <57305859.1080401@oracle.com> <2EA5FD48-92E5-4FB5-8747-CC943E5FCA0C@oracle.com> Message-ID: <5731AAE0.9050309@oracle.com> On 05/09/2016 07:21 PM, Christian Thalinger wrote: >>>>>> On May 4, 2016, at 3:48 AM, Roland Schatz >>>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review: >>>>>> http://cr.openjdk.java.net/~rschatz/JDK-8156025/webrev.00/hotspot.changeset >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8156025 >>>>>> >>>>>> This method is used only internally, it should never have been >>>>>> public. >>>>> Looks good. All JVMCI tests pass? >>>> [...] >>>> > > That is really odd. Oh, that?s the exploded JDK; somehow it doesn?t work: > [...] > Build the image and use that. That worked, thanks. All hotspot/test/compiler/jvmci tests pass with this change on top of the current hs-comp tip. - Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Tue May 10 10:26:19 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 10 May 2016 12:26:19 +0200 Subject: RFR(S): 8155241: Crash with assert in Xcomp mode and with disabled ReduceBulkZeroing Message-ID: <5731B74B.7090406@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8155241 http://cr.openjdk.java.net/~thartmann/8155241/webrev.00/ JDK-8076188 introduced code that eliminates an arraycopy if the destination is non escaping. The newly added LoadNode::find_previous_arraycopy() assumes that a clonebasic arraycopy that overwrites a newly allocated array always sets the corresponding InitializeNode to "complete", i.e., takes care of zeroing the array. However, this is only the case if ReduceBulkZeroing is enabled. I fixed the assert and added a regression test. Tested with JPRT and RBT (running). Thanks, Tobias From roland.schatz at oracle.com Tue May 10 11:14:36 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Tue, 10 May 2016 13:14:36 +0200 Subject: RFR 8155719: remove TrustedInterface from JVMCI In-Reply-To: <5D6FC0E0-BD08-4746-BC40-CD38822E929B@oracle.com> References: <572766F8.20403@oracle.com> <5D6FC0E0-BD08-4746-BC40-CD38822E929B@oracle.com> Message-ID: <5731C29C.7050800@oracle.com> Rebased on top of current tip: http://cr.openjdk.java.net/~rschatz/JDK-8155719/webrev.01/ This passes all jvmci tests. Can you please integrate this, Chris? Thanks, Roland On 05/02/2016 06:55 PM, Christian Thalinger wrote: > Looks good. > >> On May 2, 2016, at 4:40 AM, Roland Schatz wrote: >> >> Hi, >> >> Please review this jvmci change: >> >> webrev: http://cr.openjdk.java.net/~rschatz/JDK-8155719/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8155719 >> >> Thanks, >> Roland From doug.simon at oracle.com Tue May 10 12:34:53 2016 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 10 May 2016 14:34:53 +0200 Subject: RFR: 8153782: [JVMCI] update JVMCI sources to Eclipse 4.5.2 format style Message-ID: <2C00AED9-FE7D-4706-B98D-C60A2EB5A006@oracle.com> Eclipse 4.5 code formatting is not backward compatible with Eclipse 4.4 (?Luna?) (http://eclipse-n-mati.blogspot.ch/2015/06/eclipse-mars-how-to-switch-back-to.html). And only Eclipse 4.5 will have jdk9 support. This change updates the JVMCI code base such that the `mx eclipseformat` command can use Eclipse 4.5 to ensure consistent code format in JVMCI. https://bugs.openjdk.java.net/browse/JDK-8153782 http://cr.openjdk.java.net/~dnsimon/8153782 Note the above webrev is based on https://bugs.openjdk.java.net/browse/JDK-8152311 -Doug From vladimir.x.ivanov at oracle.com Tue May 10 13:26:00 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 10 May 2016 16:26:00 +0300 Subject: RFR(S): 8156025: [JVMCI] make HotSpotResolvedObjectTypeImpl.createField non-public In-Reply-To: <2EA5FD48-92E5-4FB5-8747-CC943E5FCA0C@oracle.com> References: <5729FDB9.2080205@oracle.com> <572C617B.8060204@oracle.com> <1AC0B756-42F9-44F1-8E1F-78F426BB69B7@oracle.com> <57305859.1080401@oracle.com> <2EA5FD48-92E5-4FB5-8747-CC943E5FCA0C@oracle.com> Message-ID: <4d2782de-87cc-a954-72ba-d2b9be785138@oracle.com> >>> [roland at oracle-rs hs-comp]$ ~/jtreg/bin/jtreg -testjdk >>> build/linux-x86_64-normal-server-release/jdk -ignore:quiet >>> hotspot/test/compiler/jvmci >>> Directory "JTwork" not found: creating >>> Directory "JTreport" not found: creating >>> Test results: passed: 43; failed: 26 >>> Report written to /home/roland/hg/jdk9/hs-comp/JTreport/html/report.html >>> Results written to /home/roland/hg/jdk9/hs-comp/JTwork >>> Error: Some tests failed or other problems occurred. > > That is really odd. Oh, that?s the exploded JDK; somehow it doesn?t work: Most likely it's caused by JDK-8154239: https://bugs.openjdk.java.net/browse/JDK-8154239 Best regards, Vladimir Ivanov > > java.lang.NoClassDefFoundError: jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod > at > compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:126) > at java.util.ArrayList.forEach(java.base/ArrayList.java:1352) > at > compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base/Method.java:531) > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at java.lang.Thread.run(java.base/Thread.java:843) > Caused by: java.lang.ClassNotFoundException: > jdk.vm.ci.hotspot.HotSpotResolvedJavaMethod > at > jdk.internal.loader.BuiltinClassLoader.loadClass(java.base/BuiltinClassLoader.java:366) > at > jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base/ClassLoaders.java:184) > at java.lang.ClassLoader.loadClass(java.base/ClassLoader.java:419) > ... 9 more > > Build the image and use that. > >> >> >> >>> >>>> >>>> - Roland > From dmitrij.pochepko at oracle.com Tue May 10 14:33:24 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 10 May 2016 17:33:24 +0300 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: References: <572CAC7C.3040700@oracle.com> Message-ID: <5731F134.8050102@oracle.com> Hi, Yes. I was using netbeans. I've applied eclipse formatter, then run mx checkstyle and fixed all warnings except " '.' is preceded with whitespace". Fixing this warning will make huge lines. Please take a look at v02. http://cr.openjdk.java.net/~dpochepk/8152341/webrev.02/ Thanks, Dmitrij >> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko wrote: >> >> Hi, >> >> please review patch for 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider >> >> A new tests were added for MemoryAccessProvider implementation. This patch contains tests for all MemoryAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ > These two files don?t look like they have been formatted properly. Did you use an IDE to edit these? > >> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >> >> I've tested it on linux_x64 >> >> Thanks, >> Dmitrij From doug.simon at oracle.com Tue May 10 15:49:30 2016 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 10 May 2016 17:49:30 +0200 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <5731F134.8050102@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> Message-ID: <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> > On 10 May 2016, at 16:33, Dmitrij Pochepko wrote: > > Hi, > > Yes. I was using netbeans. I've applied eclipse formatter, then run mx checkstyle and fixed all warnings except " '.' is preceded with whitespace". Fixing this warning will make huge lines. You can disable the formatter with: // @formatter:off code that won?t be formatted // @formatter:on However, the lines don?t look so long to me - maybe you need to get a larger monitor ;-) -Doug > > Thanks, > Dmitrij >>> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko wrote: >>> >>> Hi, >>> >>> please review patch for 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider >>> >>> A new tests were added for MemoryAccessProvider implementation. This patch contains tests for all MemoryAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ >> These two files don?t look like they have been formatted properly. Did you use an IDE to edit these? >> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >>> >>> I've tested it on linux_x64 >>> >>> Thanks, >>> Dmitrij > From tobias.hartmann at oracle.com Tue May 10 16:01:45 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 10 May 2016 18:01:45 +0200 Subject: [9] RFR(S): 8155643: Java crash with assert in Xcomp mode and disabled ReduceInitialCardMarks Message-ID: <573205E9.3010901@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8155643 http://cr.openjdk.java.net/~thartmann/8155643/webrev.00/ We hit the "should have klasses" assert in PhaseMacroExpand::generate_arraycopy() while intrinsifying Object[].clone() because the src and dst klass is not set. This is because if ReduceInitialCardMarks is disabled, we emit a copy of type 'CloneOop' instead of a 'CloneBasic'. In both cases we should not emit a subtype check. Tested on JPRT and RBT (running). Thanks, Tobias From vladimir.kozlov at oracle.com Tue May 10 16:06:22 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 10 May 2016 09:06:22 -0700 Subject: [9] RFR(S): 8155643: Java crash with assert in Xcomp mode and disabled ReduceInitialCardMarks In-Reply-To: <573205E9.3010901@oracle.com> References: <573205E9.3010901@oracle.com> Message-ID: <573206FE.9070300@oracle.com> Looks good. Thanks, Vladimir On 5/10/16 9:01 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8155643 > http://cr.openjdk.java.net/~thartmann/8155643/webrev.00/ > > We hit the "should have klasses" assert in PhaseMacroExpand::generate_arraycopy() while intrinsifying Object[].clone() because the src and dst klass is not set. This is because if ReduceInitialCardMarks is disabled, we emit a copy of type 'CloneOop' instead of a 'CloneBasic'. In both cases we should not emit a subtype check. > > Tested on JPRT and RBT (running). > > Thanks, > Tobias > From josef.eisl at jku.at Tue May 10 16:12:32 2016 From: josef.eisl at jku.at (Josef Eisl) Date: Tue, 10 May 2016 18:12:32 +0200 Subject: RFR: 8156034: [JVMCI] Notify the jvmci compiler on completion of a bootstrap Message-ID: <57320870.1040203@jku.at> Hi! May I get a review for this JVMCI change. webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8156034 It passes all jvmci tests. Note that this changes depends on https://bugs.openjdk.java.net/browse/JDK-8155023 Thanks in advance, Josef From tobias.hartmann at oracle.com Tue May 10 16:15:01 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 10 May 2016 18:15:01 +0200 Subject: [9] RFR(S): 8155643: Java crash with assert in Xcomp mode and disabled ReduceInitialCardMarks In-Reply-To: <573206FE.9070300@oracle.com> References: <573205E9.3010901@oracle.com> <573206FE.9070300@oracle.com> Message-ID: <57320905.4080101@oracle.com> Thanks, Vladimir! Best regards, Tobias On 10.05.2016 18:06, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 5/10/16 9:01 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> https://bugs.openjdk.java.net/browse/JDK-8155643 >> http://cr.openjdk.java.net/~thartmann/8155643/webrev.00/ >> >> We hit the "should have klasses" assert in PhaseMacroExpand::generate_arraycopy() while intrinsifying Object[].clone() because the src and dst klass is not set. This is because if ReduceInitialCardMarks is disabled, we emit a copy of type 'CloneOop' instead of a 'CloneBasic'. In both cases we should not emit a subtype check. >> >> Tested on JPRT and RBT (running). >> >> Thanks, >> Tobias >> From dmitrij.pochepko at oracle.com Tue May 10 16:51:54 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 10 May 2016 19:51:54 +0300 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> Message-ID: <573211AA.9000401@oracle.com> Hi, I've prepared v03 with no checkstyle errors by creating larger lines. http://cr.openjdk.java.net/~dpochepk/8152341/webrev.03/ Thanks, Dmitrij >> On 10 May 2016, at 16:33, Dmitrij Pochepko wrote: >> >> Hi, >> >> Yes. I was using netbeans. I've applied eclipse formatter, then run mx checkstyle and fixed all warnings except " '.' is preceded with whitespace". Fixing this warning will make huge lines. > You can disable the formatter with: > > // @formatter:off > > code that won?t be formatted > > // @formatter:on > > However, the lines don?t look so long to me - maybe you need to get a larger monitor ;-) > > -Doug > >> Thanks, >> Dmitrij >>>> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko wrote: >>>> >>>> Hi, >>>> >>>> please review patch for 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider >>>> >>>> A new tests were added for MemoryAccessProvider implementation. This patch contains tests for all MemoryAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. >>>> >>>> webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ >>> These two files don?t look like they have been formatted properly. Did you use an IDE to edit these? >>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >>>> >>>> I've tested it on linux_x64 >>>> >>>> Thanks, >>>> Dmitrij From christian.thalinger at oracle.com Tue May 10 17:30:54 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 07:30:54 -1000 Subject: RFR: 8156034: [JVMCI] Notify the jvmci compiler on completion of a bootstrap In-Reply-To: <57320870.1040203@jku.at> References: <57320870.1040203@jku.at> Message-ID: > On May 10, 2016, at 6:12 AM, Josef Eisl wrote: > > Hi! > > May I get a review for this JVMCI change. > > webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev/ src/share/vm/jvmci/jvmciCompiler.cpp + _bootstrap_compilation_request_seen = false; Remove the extra space after = src/share/vm/jvmci/jvmciCompiler.hpp + * True if we have seen the a bootstrap compilation request. Typo ?the a?. src/share/vm/jvmci/jvmciRuntime.cpp +void JVMCIRuntime::bootstrapFinished() { Rename the method to bootstrap_finished. Also, this method should use TRAPS and propagate the exception. In JNI_CreateJavaVM_inner use something like this to report exceptions: if (HAS_PENDING_EXCEPTION) { HandleMark hm; vm_exit_during_initialization(Handle(THREAD, PENDING_EXCEPTION)); } + if (_HotSpotJVMCIRuntime_instance != NULL) { Can this ever be not true at this point? test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java 27 * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | os.simpleArch == "aarch64") 28 * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | os.simpleArch == "aarch64") Remove duplicate line. > bug: https://bugs.openjdk.java.net/browse/JDK-8156034 > > It passes all jvmci tests. > > Note that this changes depends on > https://bugs.openjdk.java.net/browse/JDK-8155023 > > Thanks in advance, > Josef > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Tue May 10 17:34:21 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 10 May 2016 20:34:21 +0300 Subject: RFR: 8152342 - JVMCI test task: Unit tests for MethodHandleAccessProvider In-Reply-To: <23981544-7F7C-4CD0-B4CF-FAD8E42FA52F@oracle.com> References: <572CADC8.4090004@oracle.com> <23981544-7F7C-4CD0-B4CF-FAD8E42FA52F@oracle.com> Message-ID: <57321B9D.8000204@oracle.com> Hi, please check v02: http://cr.openjdk.java.net/~dpochepk/8152342/webrev.02/ I've applied eclipse formatter and fixed checkstyle warnings. Thanks, Dmitrij >> On May 6, 2016, at 4:44 AM, Dmitrij Pochepko wrote: >> >> Hi, >> >> please review patch for 8152342 - JVMCI test task: Unit tests for MethodHandleAccessProvider >> >> A new tests were added for MethodHandleAccessProvider implementation. This patch contains tests for all MethodHandleAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. MethodHandleAccessProviderData is used as testng data provider for MethodHandleAccessProviderTest. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8152342/webrev.01 > Same formatting question. > >> CR: https://bugs.openjdk.java.net/browse/JDK-8152342 >> >> I've tested it on linux_x64 >> >> Thanks, >> Dmitrij >> >> From vladimir.kozlov at oracle.com Tue May 10 17:33:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 10 May 2016 10:33:05 -0700 Subject: RFR(S): 8155241: Crash with assert in Xcomp mode and with disabled ReduceBulkZeroing In-Reply-To: <5731B74B.7090406@oracle.com> References: <5731B74B.7090406@oracle.com> Message-ID: <57321B51.4080002@oracle.com> Is it only assert problem? Based on your comment "takes care of zeroing the array" it may be not enough. Can you explain more? Thanks, Vladimir On 5/10/16 3:26 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8155241 > http://cr.openjdk.java.net/~thartmann/8155241/webrev.00/ > > JDK-8076188 introduced code that eliminates an arraycopy if the destination is non escaping. The newly added LoadNode::find_previous_arraycopy() assumes that a clonebasic arraycopy that overwrites a newly allocated array always sets the corresponding InitializeNode to "complete", i.e., takes care of zeroing the array. However, this is only the case if ReduceBulkZeroing is enabled. > > I fixed the assert and added a regression test. > > Tested with JPRT and RBT (running). > > Thanks, > Tobias > From christian.thalinger at oracle.com Tue May 10 17:33:07 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 07:33:07 -1000 Subject: RFR: 8153782: [JVMCI] update JVMCI sources to Eclipse 4.5.2 format style In-Reply-To: <2C00AED9-FE7D-4706-B98D-C60A2EB5A006@oracle.com> References: <2C00AED9-FE7D-4706-B98D-C60A2EB5A006@oracle.com> Message-ID: <87A1ABC9-EF5D-4D00-BA45-E32C5D7BEC40@oracle.com> Looks good. > On May 10, 2016, at 2:34 AM, Doug Simon wrote: > > Eclipse 4.5 code formatting is not backward compatible with Eclipse 4.4 (?Luna?) (http://eclipse-n-mati.blogspot.ch/2015/06/eclipse-mars-how-to-switch-back-to.html). And only Eclipse 4.5 will have jdk9 support. This change updates the JVMCI code base such that the `mx eclipseformat` command can use Eclipse 4.5 to ensure consistent code format in JVMCI. > > https://bugs.openjdk.java.net/browse/JDK-8153782 > http://cr.openjdk.java.net/~dnsimon/8153782 > > Note the above webrev is based on https://bugs.openjdk.java.net/browse/JDK-8152311 > > -Doug From tobias.hartmann at oracle.com Tue May 10 17:49:01 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 10 May 2016 19:49:01 +0200 Subject: RFR(S): 8155241: Crash with assert in Xcomp mode and with disabled ReduceBulkZeroing In-Reply-To: <57321B51.4080002@oracle.com> References: <5731B74B.7090406@oracle.com> <57321B51.4080002@oracle.com> Message-ID: <57321F0D.6050207@oracle.com> Hi Vladimir, On 10.05.2016 19:33, Vladimir Kozlov wrote: > Is it only assert problem? Based on your comment "takes care of zeroing the array" it may be not enough. Can you explain more? Yes, I think the assert is wrong because it assumes that a clonebasic arraycopy always takes care of zeroing (simply by overwriting) a newly allocated destination array. However, with -XX:-ReduceBulkZeroing this is not the case and the array is needlessly zeroed directly after the allocation and before the clonebasic which overwrites the array anyway. Maybe Roland (CC'ed) can verify. Thanks, Tobias > > Thanks, > Vladimir > > On 5/10/16 3:26 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> https://bugs.openjdk.java.net/browse/JDK-8155241 >> http://cr.openjdk.java.net/~thartmann/8155241/webrev.00/ >> >> JDK-8076188 introduced code that eliminates an arraycopy if the destination is non escaping. The newly added LoadNode::find_previous_arraycopy() assumes that a clonebasic arraycopy that overwrites a newly allocated array always sets the corresponding InitializeNode to "complete", i.e., takes care of zeroing the array. However, this is only the case if ReduceBulkZeroing is enabled. >> >> I fixed the assert and added a regression test. >> >> Tested with JPRT and RBT (running). >> >> Thanks, >> Tobias >> From vivek.r.deshpande at intel.com Tue May 10 17:59:56 2016 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Tue, 10 May 2016 17:59:56 +0000 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <57162A88.7030608@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A971AC@ORSMSX106.amr.corp.intel.com> HI Christian We have not heard from runtime team regarding this change. Shall we go ahead with the current solution ? I can send out the latest webrev. Let me know your thoughts. Regards, Vivek From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Monday, May 02, 2016 3:44 PM To: Deshpande, Vivek R Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics On May 2, 2016, at 11:53 AM, Deshpande, Vivek R > wrote: Hi Christian I had tried using call_VM_leaf() which you mentioned. But this function void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { call_VM_leaf_base(entry_point, number_of_arguments); } ends up calling void InterpreterMacroAssembler::call_VM_leaf_base(address entry_point, int number_of_arguments) { ... from interp_masm_x86.cpp instead of void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { ? Frankly, I didn?t know that there is an overload for call_VM_leaf_base in InterpreterMacroAssembler. So this means there are two options: a) Add a method in MacroAssembler to call MacroAssembler::call_VM_leaf_base (what you did) or b) Add InterpreterMacroAssembler::call_VM_leaf and change MacroAssembler::call_VM_leaf to do: void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); } I will let the runtime team decide. So I had put mathfunc() to call the masm version of call_VM_leaf_base(). Let me know what you think. Thanks and regards, Vivek From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Monday, May 02, 2016 1:50 PM To: Deshpande, Vivek R Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R > wrote: Hi Christian I have updated the webrev and link for the same is here: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ I am using mathfunc() to call the masm version of call_VM_leaf_base() and not the InterpreterMacroAssembler version. That?s better but, again, there is nothing math-y about this method: ! void MacroAssembler::mathfunc(address runtime_entry) { MacroAssembler::call_VM_leaf_base(runtime_entry, 0); } Also, there is this method: void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { call_VM_leaf_base(entry_point, number_of_arguments); } which has: void call_VM_leaf(address entry_point, int number_of_arguments = 0); Get rid of mathfunc completely and use call_VM_leaf directly. Regards, Vivek From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Thursday, April 21, 2016 2:35 PM To: Deshpande, Vivek R > Cc: Nils Eliasson >; hotspot-compiler-dev at openjdk.java.net; Vladimir Kozlov > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R > wrote: Hi The correct URL for the updated webrev is this. http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ +void MacroAssembler::mathfunc(address runtime_entry) { I don?t like the name of this method. Mainly because it?s only aligning the stack (shouldn?t that happen somewhere else?) and doing this 0x20 stack frame thing which I still don?t understand. Right, this is the one I was thinking about: void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { Sorry for the spam. Regards, Vivek From: Deshpande, Vivek R Sent: Wednesday, April 20, 2016 5:10 PM To: Deshpande, Vivek R; 'Nils Eliasson'; 'hotspot-compiler-dev at openjdk.java.net' Cc: 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian Thalinger'; Viswanathan, Sandhya Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics Sent out the wrong link by mistake. updated webrev: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ Regards Vivek From: Deshpande, Vivek R Sent: Wednesday, April 20, 2016 5:07 PM To: 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net Cc: Vladimir Kozlov; Volker Simonis; Christian Thalinger; Viswanathan, Sandhya Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics Hi Nils I have updated the webrev with all the suggestions. updated webrev: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ Thanks for your comments and review. @Vladimir, I have taken care of all the comments. Would you please review and sponsor the patch. Thanks and regards, Vivek From: Nils Eliasson [mailto:nils.eliasson at oracle.com] Sent: Wednesday, April 20, 2016 12:27 PM To: Deshpande, Vivek R; hotspot-compiler-dev at openjdk.java.net Cc: Vladimir Kozlov; Volker Simonis; Christian Thalinger; Viswanathan, Sandhya Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In vmSymbols.cpp together with the other flag checks. Regards, Nils On 2016-04-20 02:44, Deshpande, Vivek R wrote: HI Nils Yes you are right the function accesses the command line flag DisableIntrinsic and changes are static. Could you point me the right location for the function ? Also I have updated the webrev with rest of the comments here: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ Regards, Vivek From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]On Behalf Of Nils Eliasson Sent: Tuesday, April 19, 2016 5:55 AM To: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics Hi Vivek, The changes in is_intrinsic_disabled in compilerDirectives.* are static and only access the command line flag DisableIntrinsics. As long as stubs are only generated during startup and don't have a method context - that is ok - but it doesn't belong in the compilerDirectives-files if it doens't use directives. Regards, Nils On 2016-04-18 19:38, Deshpande, Vivek R wrote: Hi all I would like to contribute a patch which helps to control the intrinsics in interpreter, c1 and c2 by disabling the stub generation. This uses -XX:DisableIntrinsic option to achieve the same. Could you please review and sponsor this patch. Bug-id: https://bugs.openjdk.java.net/browse/JDK-8154473 webrev: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ Thanks and regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.rodriguez at oracle.com Tue May 10 18:06:01 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 10 May 2016 11:06:01 -0700 Subject: RFR 8137296: [JVMCI] Enable sharing of debug info by default in all configurations Message-ID: http://cr.openjdk.java.net/~never/8137296/webrev This webrev makes the JVMCI logic for sharing of debug info the default for all configurations. The code has been the default for quite a while with no issues so it makes sense to eliminate the old code. tom From christian.thalinger at oracle.com Tue May 10 18:25:52 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 08:25:52 -1000 Subject: RFR 8137296: [JVMCI] Enable sharing of debug info by default in all configurations In-Reply-To: References: Message-ID: <4BE1EFEB-0315-4AC8-B6BD-8DCF67DCB983@oracle.com> Looks good. > On May 10, 2016, at 8:06 AM, Tom Rodriguez wrote: > > http://cr.openjdk.java.net/~never/8137296/webrev > > This webrev makes the JVMCI logic for sharing of debug info the default for all configurations. The code has been the default for quite a while with no issues so it makes sense to eliminate the old code. > > tom From christian.thalinger at oracle.com Tue May 10 18:28:02 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 08:28:02 -1000 Subject: RFR(S): 8156025: [JVMCI] make HotSpotResolvedObjectTypeImpl.createField non-public In-Reply-To: <4d2782de-87cc-a954-72ba-d2b9be785138@oracle.com> References: <5729FDB9.2080205@oracle.com> <572C617B.8060204@oracle.com> <1AC0B756-42F9-44F1-8E1F-78F426BB69B7@oracle.com> <57305859.1080401@oracle.com> <2EA5FD48-92E5-4FB5-8747-CC943E5FCA0C@oracle.com> <4d2782de-87cc-a954-72ba-d2b9be785138@oracle.com> Message-ID: > On May 10, 2016, at 3:26 AM, Vladimir Ivanov wrote: > > >>>> [roland at oracle-rs hs-comp]$ ~/jtreg/bin/jtreg -testjdk >>>> build/linux-x86_64-normal-server-release/jdk -ignore:quiet >>>> hotspot/test/compiler/jvmci >>>> Directory "JTwork" not found: creating >>>> Directory "JTreport" not found: creating >>>> Test results: passed: 43; failed: 26 >>>> Report written to /home/roland/hg/jdk9/hs-comp/JTreport/html/report.html >>>> Results written to /home/roland/hg/jdk9/hs-comp/JTwork >>>> Error: Some tests failed or other problems occurred. >> >> That is really odd. Oh, that?s the exploded JDK; somehow it doesn?t work: > Most likely it's caused by JDK-8154239: > https://bugs.openjdk.java.net/browse/JDK-8154239 That?s probably it. > > Best regards, > Vladimir Ivanov > >> >> java.lang.NoClassDefFoundError: jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod >> at >> compiler.jvmci.compilerToVM.AllocateCompileIdTest.runSanityCorrectTest(AllocateCompileIdTest.java:126) >> at java.util.ArrayList.forEach(java.base/ArrayList.java:1352) >> at >> compiler.jvmci.compilerToVM.AllocateCompileIdTest.main(AllocateCompileIdTest.java:72) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(java.base/Method.java:531) >> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >> at java.lang.Thread.run(java.base/Thread.java:843) >> Caused by: java.lang.ClassNotFoundException: >> jdk.vm.ci.hotspot.HotSpotResolvedJavaMethod >> at >> jdk.internal.loader.BuiltinClassLoader.loadClass(java.base/BuiltinClassLoader.java:366) >> at >> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base/ClassLoaders.java:184) >> at java.lang.ClassLoader.loadClass(java.base/ClassLoader.java:419) >> ... 9 more >> >> Build the image and use that. >> >>> >>> >>> >>>> >>>>> >>>>> - Roland >> From christian.thalinger at oracle.com Tue May 10 18:31:54 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 08:31:54 -1000 Subject: RFR: 8156211: [JVMCI] ResolvedJava* interfaces should extend AnnotatedElement In-Reply-To: <5731A90A.50908@oracle.com> References: <572C8B7E.5020304@oracle.com> <94E88818-DE33-4778-9D98-153EF68978A9@oracle.com> <57305ABC.2010804@oracle.com> <5731A90A.50908@oracle.com> Message-ID: > On May 9, 2016, at 11:25 PM, Roland Schatz wrote: > > On 05/09/2016 07:16 PM, Christian Thalinger wrote: >> >>> On May 8, 2016, at 11:39 PM, Roland Schatz < roland.schatz at oracle.com > wrote: >>> >>> Whoops... Good catch. >>> >>> Fixed: >>> http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.01/ >> >> Looks good. One nit: >> + public Annotation[] getDeclaredAnnotations() { >> + Field javaField = toJava(); >> + if (javaField != null) { >> + return javaField.getDeclaredAnnotations(); >> + } >> + return new Annotation[0]; >> + } >> + public Annotation[] getDeclaredAnnotations() { >> + Executable javaMethod = toJava(); >> + return javaMethod == null ? new Annotation[0] : javaMethod.getDeclaredAnnotations(); >> + } >> Make them look the same. > > Done (and also made the existing getAnnotations() methods look the same, while we're at it). > > http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.02/ Thanks. > > - Roland > > >> >>> >>> - Roland >>> >>> On 05/06/2016 11:24 PM, Christian Thalinger wrote: >>>> >>>>> On May 6, 2016, at 2:18 AM, Roland Schatz > wrote: >>>>> >>>>> Please review this small jvmci change: >>>>> >>>>> http://cr.openjdk.java.net/~rschatz/JDK-8156211/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8156211 src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java >>>> >>>> + public Annotation[] getDeclaredAnnotations() { >>>> + Executable javaMethod = toJava(); >>>> + return javaMethod == null ? null : javaMethod.getDeclaredAnnotations(); >>>> + } >>>> This seems wrong. The specification says: >>>> >>>> * If there are no annotations directly present on this element, >>>> * the return value is an array of length 0. >>>> >>>> and the others return an empty array. >>>> >>>>> >>>>> This change was contributed by Vojin Jovanovic (cc'ed). >>>>> >>>>> Thanks, >>>>> Roland >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue May 10 18:34:51 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 10 May 2016 11:34:51 -0700 Subject: RFR 8137296: [JVMCI] Enable sharing of debug info by default in all configurations In-Reply-To: References: Message-ID: <573229CB.60703@oracle.com> Looks good. Thanks, Vladimir On 5/10/16 11:06 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8137296/webrev > > This webrev makes the JVMCI logic for sharing of debug info the default for all configurations. The code has been the default for quite a while with no issues so it makes sense to eliminate the old code. > > tom > From christian.thalinger at oracle.com Tue May 10 18:35:04 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 08:35:04 -1000 Subject: RFR 8155719: remove TrustedInterface from JVMCI In-Reply-To: <5731C29C.7050800@oracle.com> References: <572766F8.20403@oracle.com> <5D6FC0E0-BD08-4746-BC40-CD38822E929B@oracle.com> <5731C29C.7050800@oracle.com> Message-ID: <685C226A-33B5-4FBA-9A89-809179AEFED8@oracle.com> > On May 10, 2016, at 1:14 AM, Roland Schatz wrote: > > Rebased on top of current tip: > http://cr.openjdk.java.net/~rschatz/JDK-8155719/webrev.01/ > > This passes all jvmci tests. > > Can you please integrate this, Chris? Yes. > > Thanks, > Roland > > On 05/02/2016 06:55 PM, Christian Thalinger wrote: >> Looks good. >> >>> On May 2, 2016, at 4:40 AM, Roland Schatz wrote: >>> >>> Hi, >>> >>> Please review this jvmci change: >>> >>> webrev: http://cr.openjdk.java.net/~rschatz/JDK-8155719/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8155719 >>> >>> Thanks, >>> Roland > From rwestrel at redhat.com Tue May 10 18:49:35 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 10 May 2016 20:49:35 +0200 Subject: RFR(S): 8155241: Crash with assert in Xcomp mode and with disabled ReduceBulkZeroing In-Reply-To: <57321F0D.6050207@oracle.com> References: <5731B74B.7090406@oracle.com> <57321B51.4080002@oracle.com> <57321F0D.6050207@oracle.com> Message-ID: <57322D3F.1060803@redhat.com> > Yes, I think the assert is wrong because it assumes that a clonebasic > arraycopy always takes care of zeroing (simply by overwriting) a > newly allocated destination array. However, with > -XX:-ReduceBulkZeroing this is not the case and the array is > needlessly zeroed directly after the allocation and before the > clonebasic which overwrites the array anyway. > > Maybe Roland (CC'ed) can verify. I don't remember for sure but AFAICT, the assert is only a sanity check so I would say the change is good. Roland. From christian.thalinger at oracle.com Tue May 10 19:23:43 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 09:23:43 -1000 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <573211AA.9000401@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> <573211AA.9000401@oracle.com> Message-ID: <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> > On May 10, 2016, at 6:51 AM, Dmitrij Pochepko wrote: > > Hi, > > I've prepared v03 with no checkstyle errors by creating larger lines. > > http://cr.openjdk.java.net/~dpochepk/8152341/webrev.03/ 90 @Test(dataProvider = "negative", dataProviderClass = MemoryAccessProviderData.class, expectedExceptions = {IllegalArgumentException.class }) 91 public void testNegativeReadPrimitiveConstant(JavaKind kind, Constant base) { 92 PROVIDER.readPrimitiveConstant(kind, base, 0L, 93 kind == null ? 0 : kind.getBitCount()); 94 } The formatting still looks odd. I?ve noticed that sometimes Eclipse doesn?t merge lines when it actually could. Doug, have you noticed that too? > > Thanks, > Dmitrij >>> On 10 May 2016, at 16:33, Dmitrij Pochepko wrote: >>> >>> Hi, >>> >>> Yes. I was using netbeans. I've applied eclipse formatter, then run mx checkstyle and fixed all warnings except " '.' is preceded with whitespace". Fixing this warning will make huge lines. >> You can disable the formatter with: >> >> // @formatter:off >> >> code that won?t be formatted >> >> // @formatter:on >> >> However, the lines don?t look so long to me - maybe you need to get a larger monitor ;-) >> >> -Doug >> >>> Thanks, >>> Dmitrij >>>>> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko wrote: >>>>> >>>>> Hi, >>>>> >>>>> please review patch for 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider >>>>> >>>>> A new tests were added for MemoryAccessProvider implementation. This patch contains tests for all MemoryAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ >>>> These two files don?t look like they have been formatted properly. Did you use an IDE to edit these? >>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >>>>> >>>>> I've tested it on linux_x64 >>>>> >>>>> Thanks, >>>>> Dmitrij > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Tue May 10 20:03:04 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 10 May 2016 23:03:04 +0300 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> <573211AA.9000401@oracle.com> <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> Message-ID: <57323E78.3080508@oracle.com> Please take a look at v04 with this issue fixed. http://cr.openjdk.java.net/~dpochepk/8152341/webrev.04 Thanks, Dmitrij > >> On May 10, 2016, at 6:51 AM, Dmitrij Pochepko >> > wrote: >> >> Hi, >> >> I've prepared v03 with no checkstyle errors by creating larger lines. >> >> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.03/ >> > 90 @Test(dataProvider = "negative", dataProviderClass = MemoryAccessProviderData.class, expectedExceptions = {IllegalArgumentException.class }) > 91 public void testNegativeReadPrimitiveConstant(JavaKind kind, Constant base) { > 92 PROVIDER.readPrimitiveConstant(kind, base, 0L, > 93 kind == null ? 0 : kind.getBitCount()); > 94 } > The formatting still looks odd. I?ve noticed that sometimes Eclipse > doesn?t merge lines when it actually could. Doug, have you noticed > that too? > >> >> Thanks, >> Dmitrij >>>> On 10 May 2016, at 16:33, Dmitrij Pochepko >>>> > >>>> wrote: >>>> >>>> Hi, >>>> >>>> Yes. I was using netbeans. I've applied eclipse formatter, then run >>>> mx checkstyle and fixed all warnings except " '.' is preceded with >>>> whitespace". Fixing this warning will make huge lines. >>> You can disable the formatter with: >>> >>> // @formatter:off >>> >>> code that won?t be formatted >>> >>> // @formatter:on >>> >>> However, the lines don?t look so long to me - maybe you need to get >>> a larger monitor ;-) >>> >>> -Doug >>> >>>> Thanks, >>>> Dmitrij >>>>>> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> please review patch for 8152341 - JVMCI test task: Unit tests for >>>>>> MemoryAccessProvider >>>>>> >>>>>> A new tests were added for MemoryAccessProvider implementation. >>>>>> This patch contains tests for all MemoryAccessProvider methods >>>>>> (mostly a positive and few negative tests per method). A testng >>>>>> framework is used. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ >>>>>> >>>>> These two files don?t look like they have been formatted properly. >>>>> Did you use an IDE to edit these? >>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >>>>>> >>>>>> I've tested it on linux_x64 >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Tue May 10 20:20:27 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 10:20:27 -1000 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <57323E78.3080508@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> <573211AA.9000401@oracle.com> <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> <57323E78.3080508@oracle.com> Message-ID: > On May 10, 2016, at 10:03 AM, Dmitrij Pochepko wrote: > > > Please take a look at v04 with this issue fixed. That was just one example; there are many more like this. > > http://cr.openjdk.java.net/~dpochepk/8152341/webrev.04 > > Thanks, > Dmitrij >> >>> On May 10, 2016, at 6:51 AM, Dmitrij Pochepko > wrote: >>> >>> Hi, >>> >>> I've prepared v03 with no checkstyle errors by creating larger lines. >>> >>> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.03/ 90 @Test(dataProvider = "negative", dataProviderClass = MemoryAccessProviderData.class, expectedExceptions = {IllegalArgumentException.class }) >> 91 public void testNegativeReadPrimitiveConstant(JavaKind kind, Constant base) { >> 92 PROVIDER.readPrimitiveConstant(kind, base, 0L, >> 93 kind == null ? 0 : kind.getBitCount()); >> 94 } >> The formatting still looks odd. I?ve noticed that sometimes Eclipse doesn?t merge lines when it actually could. Doug, have you noticed that too? >> >>> >>> Thanks, >>> Dmitrij >>>>> On 10 May 2016, at 16:33, Dmitrij Pochepko > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Yes. I was using netbeans. I've applied eclipse formatter, then run mx checkstyle and fixed all warnings except " '.' is preceded with whitespace". Fixing this warning will make huge lines. >>>> You can disable the formatter with: >>>> >>>> // @formatter:off >>>> >>>> code that won?t be formatted >>>> >>>> // @formatter:on >>>> >>>> However, the lines don?t look so long to me - maybe you need to get a larger monitor ;-) >>>> >>>> -Doug >>>> >>>>> Thanks, >>>>> Dmitrij >>>>>>> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko < dmitrij.pochepko at oracle.com > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> please review patch for 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider >>>>>>> >>>>>>> A new tests were added for MemoryAccessProvider implementation. This patch contains tests for all MemoryAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ >>>>>> These two files don?t look like they have been formatted properly. Did you use an IDE to edit these? >>>>>> >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >>>>>>> >>>>>>> I've tested it on linux_x64 >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Tue May 10 20:21:34 2016 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 10 May 2016 22:21:34 +0200 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> <573211AA.9000401@oracle.com> <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> Message-ID: <5B6C11E5-AA99-41A0-8292-2081A26AA1D4@oracle.com> > On 10 May 2016, at 21:23, Christian Thalinger wrote: > > >> On May 10, 2016, at 6:51 AM, Dmitrij Pochepko wrote: >> >> Hi, >> >> I've prepared v03 with no checkstyle errors by creating larger lines. >> >> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.03/ > 90 @Test(dataProvider = "negative", dataProviderClass = MemoryAccessProviderData.class, expectedExceptions = {IllegalArgumentException.class }) > 91 public void testNegativeReadPrimitiveConstant(JavaKind kind, Constant base) { > 92 PROVIDER.readPrimitiveConstant(kind, base, 0L, > 93 kind == null ? 0 : kind.getBitCount()); > 94 } > > The formatting still looks odd. I?ve noticed that sometimes Eclipse doesn?t merge lines when it actually could. Doug, have you noticed that too? Due to popular demand, we disabled auto-line-merging for explicit new lines: https://github.com/graalvm/mx/commit/f1f464bc183536fe09e81ca9f5bf2bb0270964e9 > >> >> Thanks, >> Dmitrij >>>> On 10 May 2016, at 16:33, Dmitrij Pochepko wrote: >>>> >>>> Hi, >>>> >>>> Yes. I was using netbeans. I've applied eclipse formatter, then run mx checkstyle and fixed all warnings except " '.' is preceded with whitespace". Fixing this warning will make huge lines. >>> You can disable the formatter with: >>> >>> // @formatter:off >>> >>> code that won?t be formatted >>> >>> // @formatter:on >>> >>> However, the lines don?t look so long to me - maybe you need to get a larger monitor ;-) >>> >>> -Doug >>> >>>> Thanks, >>>> Dmitrij >>>>>> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> please review patch for 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider >>>>>> >>>>>> A new tests were added for MemoryAccessProvider implementation. This patch contains tests for all MemoryAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ >>>>> These two files don?t look like they have been formatted properly. Did you use an IDE to edit these? >>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >>>>>> >>>>>> I've tested it on linux_x64 >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >> > From christian.thalinger at oracle.com Tue May 10 20:24:48 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 10:24:48 -1000 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <5B6C11E5-AA99-41A0-8292-2081A26AA1D4@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> <573211AA.9000401@oracle.com> <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> <5B6C11E5-AA99-41A0-8292-2081A26AA1D4@oracle.com> Message-ID: > On May 10, 2016, at 10:21 AM, Doug Simon wrote: > >> >> On 10 May 2016, at 21:23, Christian Thalinger wrote: >> >> >>> On May 10, 2016, at 6:51 AM, Dmitrij Pochepko wrote: >>> >>> Hi, >>> >>> I've prepared v03 with no checkstyle errors by creating larger lines. >>> >>> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.03/ >> 90 @Test(dataProvider = "negative", dataProviderClass = MemoryAccessProviderData.class, expectedExceptions = {IllegalArgumentException.class }) >> 91 public void testNegativeReadPrimitiveConstant(JavaKind kind, Constant base) { >> 92 PROVIDER.readPrimitiveConstant(kind, base, 0L, >> 93 kind == null ? 0 : kind.getBitCount()); >> 94 } >> >> The formatting still looks odd. I?ve noticed that sometimes Eclipse doesn?t merge lines when it actually could. Doug, have you noticed that too? > > Due to popular demand, we disabled auto-line-merging for explicit new lines: > > https://github.com/graalvm/mx/commit/f1f464bc183536fe09e81ca9f5bf2bb0270964e9 Ahh! That explains it. It wasn?t popular demand on my side ;-) Ok, that means that you, Dmitrij, have to manually join all lines and reformat again. Or change the setting temporarily. That might be easier. > >> >>> >>> Thanks, >>> Dmitrij >>>>> On 10 May 2016, at 16:33, Dmitrij Pochepko wrote: >>>>> >>>>> Hi, >>>>> >>>>> Yes. I was using netbeans. I've applied eclipse formatter, then run mx checkstyle and fixed all warnings except " '.' is preceded with whitespace". Fixing this warning will make huge lines. >>>> You can disable the formatter with: >>>> >>>> // @formatter:off >>>> >>>> code that won?t be formatted >>>> >>>> // @formatter:on >>>> >>>> However, the lines don?t look so long to me - maybe you need to get a larger monitor ;-) >>>> >>>> -Doug >>>> >>>>> Thanks, >>>>> Dmitrij >>>>>>> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> please review patch for 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider >>>>>>> >>>>>>> A new tests were added for MemoryAccessProvider implementation. This patch contains tests for all MemoryAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ >>>>>> These two files don?t look like they have been formatted properly. Did you use an IDE to edit these? >>>>>> >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >>>>>>> >>>>>>> I've tested it on linux_x64 >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Tue May 10 20:37:47 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 10 May 2016 22:37:47 +0200 Subject: RFR 8144826 [JVMCI] Remove jdk.vm.ci.hotspot.Stable and use jdk.internal.vm.annotation.Stable Message-ID: <3035B405-BE13-457F-B6CB-9919B7888FB8@oracle.com> Hi Please review the following clean up to remove JVMCI?s jdk.vm.ci.hotspot.Stable and defer to jdk.internal.vm.annotation.Stable via a qualified export from java.base to jdk.vm.ci. hotspot: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8144826-use-internal-stable/webrev/index.html jdk: diff -r 72b2e58a1ac4 src/java.base/share/classes/module-info.java --- a/src/java.base/share/classes/module-info.java Fri May 06 19:35:34 2016 +0300 +++ b/src/java.base/share/classes/module-info.java Tue May 10 22:00:45 2016 +0200 @@ -185,7 +185,8 @@ jdk.scripting.nashorn, jdk.unsupported; exports jdk.internal.vm.annotation to - jdk.unsupported; + jdk.unsupported, + jdk.vm.ci; exports jdk.internal.util.jar to jdk.jartool; exports jdk.internal.vm to 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 vladimir.kozlov at oracle.com Tue May 10 20:49:03 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 10 May 2016 13:49:03 -0700 Subject: RFR(S): 8155241: Crash with assert in Xcomp mode and with disabled ReduceBulkZeroing In-Reply-To: <57322D3F.1060803@redhat.com> References: <5731B74B.7090406@oracle.com> <57321B51.4080002@oracle.com> <57321F0D.6050207@oracle.com> <57322D3F.1060803@redhat.com> Message-ID: <5732493F.90007@oracle.com> My concern is that the code which calls find_previous_arraycopy() may have dependency on object initialization by arracopy. It, for example, can assume that whole allocated object is initialized by so we can load value from arraycopy's src array. Why the assert checks that allocatoin is initialized by arraycopy otherwise? On other hand set_clonebasic() is only used in Object.clone() intrinsic where whole object is copied by arraycopy. So initialization complete check is useless unless set_clonebasic() could be used in other cases. Thanks, Vladimir On 5/10/16 11:49 AM, Roland Westrelin wrote: > >> Yes, I think the assert is wrong because it assumes that a clonebasic >> arraycopy always takes care of zeroing (simply by overwriting) a >> newly allocated destination array. However, with >> -XX:-ReduceBulkZeroing this is not the case and the array is >> needlessly zeroed directly after the allocation and before the >> clonebasic which overwrites the array anyway. >> >> Maybe Roland (CC'ed) can verify. > > I don't remember for sure but AFAICT, the assert is only a sanity check > so I would say the change is good. > > Roland. > From josef.eisl at jku.at Tue May 10 21:20:20 2016 From: josef.eisl at jku.at (Josef Eisl) Date: Tue, 10 May 2016 23:20:20 +0200 Subject: RFR: 8156034: [JVMCI] Notify the jvmci compiler on completion of a bootstrap In-Reply-To: References: <57320870.1040203@jku.at> Message-ID: <57325094.5050504@jku.at> Thank you for the review! update webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev.01 Thanks, Josef On 05/10/2016 07:30 PM, Christian Thalinger wrote: > >> On May 10, 2016, at 6:12 AM, Josef Eisl > > wrote: >> >> Hi! >> >> May I get a review for this JVMCI change. >> >> webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev/ > > > src/share/vm/jvmci/jvmciCompiler.cpp > > + _bootstrap_compilation_request_seen = false; > > Remove the extra space after = > > > src/share/vm/jvmci/jvmciCompiler.hpp > > + * True if we have seen the a bootstrap compilation request. > > Typo ?the a?. > > > src/share/vm/jvmci/jvmciRuntime.cpp > > +void JVMCIRuntime::bootstrapFinished() { > > Rename the method to bootstrap_finished. Also, this method should use > TRAPS and propagate the exception. In JNI_CreateJavaVM_inner use > something like this to report exceptions: > > if (HAS_PENDING_EXCEPTION) { > HandleMark hm; > vm_exit_during_initialization(Handle(THREAD, PENDING_EXCEPTION)); > } > > + if (_HotSpotJVMCIRuntime_instance != NULL) { > > Can this ever be not true at this point? No, I guess you are right. In jdk9 this condition should always hold. > > > *test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java* > > 27 * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | os.simpleArch == "aarch64") > 28 * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | os.simpleArch == "aarch64") > > Remove duplicate line. > >> bug: https://bugs.openjdk.java.net/browse/JDK-8156034 >> >> It passes all jvmci tests. >> >> Note that this changes depends on >> https://bugs.openjdk.java.net/browse/JDK-8155023 >> >> Thanks in advance, >> Josef >> > From christian.thalinger at oracle.com Tue May 10 21:27:17 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 11:27:17 -1000 Subject: RFR 8144826 [JVMCI] Remove jdk.vm.ci.hotspot.Stable and use jdk.internal.vm.annotation.Stable In-Reply-To: <3035B405-BE13-457F-B6CB-9919B7888FB8@oracle.com> References: <3035B405-BE13-457F-B6CB-9919B7888FB8@oracle.com> Message-ID: <174E05CE-932C-4F31-843B-90026A95E37C@oracle.com> Looks good. > On May 10, 2016, at 10:37 AM, Paul Sandoz wrote: > > > Hi > > Please review the following clean up to remove JVMCI?s jdk.vm.ci.hotspot.Stable and defer to jdk.internal.vm.annotation.Stable via a qualified export from java.base to jdk.vm.ci. > > hotspot: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8144826-use-internal-stable/webrev/index.html > > jdk: > > diff -r 72b2e58a1ac4 src/java.base/share/classes/module-info.java > --- a/src/java.base/share/classes/module-info.java Fri May 06 19:35:34 2016 +0300 > +++ b/src/java.base/share/classes/module-info.java Tue May 10 22:00:45 2016 +0200 > @@ -185,7 +185,8 @@ > jdk.scripting.nashorn, > jdk.unsupported; > exports jdk.internal.vm.annotation to > - jdk.unsupported; > + jdk.unsupported, > + jdk.vm.ci; > exports jdk.internal.util.jar to > jdk.jartool; > exports jdk.internal.vm to > > Paul. From christian.thalinger at oracle.com Tue May 10 21:33:27 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 11:33:27 -1000 Subject: RFR: 8156034: [JVMCI] Notify the jvmci compiler on completion of a bootstrap In-Reply-To: <57325094.5050504@jku.at> References: <57320870.1040203@jku.at> <57325094.5050504@jku.at> Message-ID: > On May 10, 2016, at 11:20 AM, Josef Eisl wrote: > > Thank you for the review! > > update webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev.01 I think your change works but the proper way is to pass THREAD to JVMCICompiler::bootstrap() and use CHECK here: + JVMCIRuntime::bootstrap_finished(CHECK); > > Thanks, > Josef > > On 05/10/2016 07:30 PM, Christian Thalinger wrote: >> >>> On May 10, 2016, at 6:12 AM, Josef Eisl >>> >> wrote: >>> >>> Hi! >>> >>> May I get a review for this JVMCI change. >>> >>> webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev/ >> >> >> src/share/vm/jvmci/jvmciCompiler.cpp >> >> + _bootstrap_compilation_request_seen = false; >> >> Remove the extra space after = >> >> >> src/share/vm/jvmci/jvmciCompiler.hpp >> >> + * True if we have seen the a bootstrap compilation request. >> >> Typo ?the a?. >> >> >> src/share/vm/jvmci/jvmciRuntime.cpp >> >> +void JVMCIRuntime::bootstrapFinished() { >> >> Rename the method to bootstrap_finished. Also, this method should use >> TRAPS and propagate the exception. In JNI_CreateJavaVM_inner use >> something like this to report exceptions: >> >> if (HAS_PENDING_EXCEPTION) { >> HandleMark hm; >> vm_exit_during_initialization(Handle(THREAD, PENDING_EXCEPTION)); >> } >> >> + if (_HotSpotJVMCIRuntime_instance != NULL) { >> >> Can this ever be not true at this point? > > No, I guess you are right. In jdk9 this condition should always hold. > >> >> >> *test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java* >> >> 27 * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | os.simpleArch == "aarch64") >> 28 * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | os.simpleArch == "aarch64") >> >> Remove duplicate line. >> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8156034 >>> >>> It passes all jvmci tests. >>> >>> Note that this changes depends on >>> https://bugs.openjdk.java.net/browse/JDK-8155023 >>> >>> Thanks in advance, >>> Josef -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Tue May 10 21:35:37 2016 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 10 May 2016 23:35:37 +0200 Subject: RFR: 8156034: [JVMCI] Notify the jvmci compiler on completion of a bootstrap In-Reply-To: <57325094.5050504@jku.at> References: <57320870.1040203@jku.at> <57325094.5050504@jku.at> Message-ID: The _bootstrap_compilation_request_seen variable should be renamed to _bootstrap_compilation_request_handled. > On 10 May 2016, at 23:20, Josef Eisl wrote: > > Thank you for the review! > > update webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev.01 > > Thanks, > Josef > > On 05/10/2016 07:30 PM, Christian Thalinger wrote: >> >>> On May 10, 2016, at 6:12 AM, Josef Eisl >> > wrote: >>> >>> Hi! >>> >>> May I get a review for this JVMCI change. >>> >>> webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev/ >> >> >> src/share/vm/jvmci/jvmciCompiler.cpp >> >> + _bootstrap_compilation_request_seen = false; >> >> Remove the extra space after = >> >> >> src/share/vm/jvmci/jvmciCompiler.hpp >> >> + * True if we have seen the a bootstrap compilation request. >> >> Typo ?the a?. >> >> >> src/share/vm/jvmci/jvmciRuntime.cpp >> >> +void JVMCIRuntime::bootstrapFinished() { >> >> Rename the method to bootstrap_finished. Also, this method should use >> TRAPS and propagate the exception. In JNI_CreateJavaVM_inner use >> something like this to report exceptions: >> >> if (HAS_PENDING_EXCEPTION) { >> HandleMark hm; >> vm_exit_during_initialization(Handle(THREAD, PENDING_EXCEPTION)); >> } >> >> + if (_HotSpotJVMCIRuntime_instance != NULL) { >> >> Can this ever be not true at this point? > > No, I guess you are right. In jdk9 this condition should always hold. > >> >> >> *test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java* >> >> 27 * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | os.simpleArch == "aarch64") >> 28 * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | os.simpleArch == "aarch64") >> >> Remove duplicate line. >> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8156034 >>> >>> It passes all jvmci tests. >>> >>> Note that this changes depends on >>> https://bugs.openjdk.java.net/browse/JDK-8155023 >>> >>> Thanks in advance, >>> Josef From tobias.hartmann at oracle.com Wed May 11 07:07:48 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 11 May 2016 09:07:48 +0200 Subject: RFR(S): 8155241: Crash with assert in Xcomp mode and with disabled ReduceBulkZeroing In-Reply-To: <5732493F.90007@oracle.com> References: <5731B74B.7090406@oracle.com> <57321B51.4080002@oracle.com> <57321F0D.6050207@oracle.com> <57322D3F.1060803@redhat.com> <5732493F.90007@oracle.com> Message-ID: <5732DA44.3090708@oracle.com> Thanks, Roland and Vladimir! On 10.05.2016 22:49, Vladimir Kozlov wrote: > My concern is that the code which calls find_previous_arraycopy() may have dependency on object initialization by arracopy. It, for example, can assume that whole allocated object is initialized by so we can load value from arraycopy's src array. Why the assert checks that allocatoin is initialized by arraycopy otherwise? Yes, I was first concerned about this as well but looking at the code, I don't think it's a problem: LoadNode::find_previous_arraycopy() searches for an arraycopy that writes to the same memory that is loaded by 'this'. The assert checks the CloneBasic case, which always initializes the whole object anyway. As Roland said, I think this assert is only a sanity check that is unrelated to the usage of find_previous_arraycopy(). It's safe to return a CloneBasic because it's guaranteed to initialize the whole object. > On other hand set_clonebasic() is only used in Object.clone() intrinsic where whole object is copied by arraycopy. So initialization complete check is useless unless set_clonebasic() could be used in other cases. Yes, with CloneBasic we always initialize the whole object and with ReduceBulkZeroing enabled, we set_complete_with_arraycopy() in LibraryCallKit::copy_to_clone() to avoid the useless zeroing. If ReduceBulkZeroing is disabled, we first zero the object and then overwrite it again. CloneBasic shouldn't be used in other cases. RBT testing showed no problems. Thanks, Tobias > > Thanks, > Vladimir > > On 5/10/16 11:49 AM, Roland Westrelin wrote: >> >>> Yes, I think the assert is wrong because it assumes that a clonebasic >>> arraycopy always takes care of zeroing (simply by overwriting) a >>> newly allocated destination array. However, with >>> -XX:-ReduceBulkZeroing this is not the case and the array is >>> needlessly zeroed directly after the allocation and before the >>> clonebasic which overwrites the array anyway. >>> >>> Maybe Roland (CC'ed) can verify. >> >> I don't remember for sure but AFAICT, the assert is only a sanity check >> so I would say the change is good. >> >> Roland. >> From vladimir.kozlov at oracle.com Wed May 11 07:23:14 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 May 2016 00:23:14 -0700 Subject: RFR(S): 8155241: Crash with assert in Xcomp mode and with disabled ReduceBulkZeroing In-Reply-To: <5732DA44.3090708@oracle.com> References: <5731B74B.7090406@oracle.com> <57321B51.4080002@oracle.com> <57321F0D.6050207@oracle.com> <57322D3F.1060803@redhat.com> <5732493F.90007@oracle.com> <5732DA44.3090708@oracle.com> Message-ID: Okay. Good. Reviewed. Thanks, Vladimir On 5/11/16 12:07 AM, Tobias Hartmann wrote: > Thanks, Roland and Vladimir! > > On 10.05.2016 22:49, Vladimir Kozlov wrote: >> My concern is that the code which calls find_previous_arraycopy() may have dependency on object initialization by arracopy. It, for example, can assume that whole allocated object is initialized by so we can load value from arraycopy's src array. Why the assert checks that allocatoin is initialized by arraycopy otherwise? > > Yes, I was first concerned about this as well but looking at the code, I don't think it's a problem: > LoadNode::find_previous_arraycopy() searches for an arraycopy that writes to the same memory that is loaded by 'this'. The assert checks the CloneBasic case, which always initializes the whole object anyway. > > As Roland said, I think this assert is only a sanity check that is unrelated to the usage of find_previous_arraycopy(). It's safe to return a CloneBasic because it's guaranteed to initialize the whole object. > >> On other hand set_clonebasic() is only used in Object.clone() intrinsic where whole object is copied by arraycopy. So initialization complete check is useless unless set_clonebasic() could be used in other cases. > > Yes, with CloneBasic we always initialize the whole object and with ReduceBulkZeroing enabled, we set_complete_with_arraycopy() in LibraryCallKit::copy_to_clone() to avoid the useless zeroing. If ReduceBulkZeroing is disabled, we first zero the object and then overwrite it again. CloneBasic shouldn't be used in other cases. > > RBT testing showed no problems. > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >> On 5/10/16 11:49 AM, Roland Westrelin wrote: >>> >>>> Yes, I think the assert is wrong because it assumes that a clonebasic >>>> arraycopy always takes care of zeroing (simply by overwriting) a >>>> newly allocated destination array. However, with >>>> -XX:-ReduceBulkZeroing this is not the case and the array is >>>> needlessly zeroed directly after the allocation and before the >>>> clonebasic which overwrites the array anyway. >>>> >>>> Maybe Roland (CC'ed) can verify. >>> >>> I don't remember for sure but AFAICT, the assert is only a sanity check >>> so I would say the change is good. >>> >>> Roland. >>> From tobias.hartmann at oracle.com Wed May 11 07:24:51 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 11 May 2016 09:24:51 +0200 Subject: RFR(S): 8155241: Crash with assert in Xcomp mode and with disabled ReduceBulkZeroing In-Reply-To: References: <5731B74B.7090406@oracle.com> <57321B51.4080002@oracle.com> <57321F0D.6050207@oracle.com> <57322D3F.1060803@redhat.com> <5732493F.90007@oracle.com> <5732DA44.3090708@oracle.com> Message-ID: <5732DE43.20805@oracle.com> Thanks, Vladimir! Best regards, Tobias On 11.05.2016 09:23, Vladimir Kozlov wrote: > Okay. Good. Reviewed. > > Thanks, > Vladimir > > On 5/11/16 12:07 AM, Tobias Hartmann wrote: >> Thanks, Roland and Vladimir! >> >> On 10.05.2016 22:49, Vladimir Kozlov wrote: >>> My concern is that the code which calls find_previous_arraycopy() may have dependency on object initialization by arracopy. It, for example, can assume that whole allocated object is initialized by so we can load value from arraycopy's src array. Why the assert checks that allocatoin is initialized by arraycopy otherwise? >> >> Yes, I was first concerned about this as well but looking at the code, I don't think it's a problem: >> LoadNode::find_previous_arraycopy() searches for an arraycopy that writes to the same memory that is loaded by 'this'. The assert checks the CloneBasic case, which always initializes the whole object anyway. >> >> As Roland said, I think this assert is only a sanity check that is unrelated to the usage of find_previous_arraycopy(). It's safe to return a CloneBasic because it's guaranteed to initialize the whole object. >> >>> On other hand set_clonebasic() is only used in Object.clone() intrinsic where whole object is copied by arraycopy. So initialization complete check is useless unless set_clonebasic() could be used in other cases. >> >> Yes, with CloneBasic we always initialize the whole object and with ReduceBulkZeroing enabled, we set_complete_with_arraycopy() in LibraryCallKit::copy_to_clone() to avoid the useless zeroing. If ReduceBulkZeroing is disabled, we first zero the object and then overwrite it again. CloneBasic shouldn't be used in other cases. >> >> RBT testing showed no problems. >> >> Thanks, >> Tobias >> >>> >>> Thanks, >>> Vladimir >>> >>> On 5/10/16 11:49 AM, Roland Westrelin wrote: >>>> >>>>> Yes, I think the assert is wrong because it assumes that a clonebasic >>>>> arraycopy always takes care of zeroing (simply by overwriting) a >>>>> newly allocated destination array. However, with >>>>> -XX:-ReduceBulkZeroing this is not the case and the array is >>>>> needlessly zeroed directly after the allocation and before the >>>>> clonebasic which overwrites the array anyway. >>>>> >>>>> Maybe Roland (CC'ed) can verify. >>>> >>>> I don't remember for sure but AFAICT, the assert is only a sanity check >>>> so I would say the change is good. >>>> >>>> Roland. >>>> From josef.eisl at jku.at Wed May 11 07:39:00 2016 From: josef.eisl at jku.at (Josef Eisl) Date: Wed, 11 May 2016 09:39:00 +0200 Subject: RFR: 8156034: [JVMCI] Notify the jvmci compiler on completion of a bootstrap In-Reply-To: References: <57320870.1040203@jku.at> <57325094.5050504@jku.at> Message-ID: <5732E194.8090306@jku.at> Thanks again, Chris and Doug! Next iteration of the webrev available here: http://cr.openjdk.java.net/~jeisl/8156034/webrev.02/ Thanks, Josef On 10/05/16 23:35, Doug Simon wrote: > The _bootstrap_compilation_request_seen variable should be renamed to > _bootstrap_compilation_request_handled. > > On 10/05/16 23:33, Christian Thalinger wrote: > >> On May 10, 2016, at 11:20 AM, Josef Eisl > > wrote: >> >> Thank you for the review! >> >> update webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev.01 >> > > I think your change works but the proper way is to pass THREAD > to JVMCICompiler::bootstrap() and use CHECK here: > > + JVMCIRuntime::bootstrap_finished(CHECK); That makes sense. I'm still figuring out where to use which macro but I'm getting closer :). >> >> Thanks, >> Josef >> >> On 05/10/2016 07:30 PM, Christian Thalinger wrote: >>> >>>> On May 10, 2016, at 6:12 AM, Josef Eisl >>> >>>> > wrote: >>>> >>>> Hi! >>>> >>>> May I get a review for this JVMCI change. >>>> >>>> webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev/ >>>> >>> >>> >>> src/share/vm/jvmci/jvmciCompiler.cpp >>> >>> + _bootstrap_compilation_request_seen = false; >>> >>> Remove the extra space after = >>> >>> >>> src/share/vm/jvmci/jvmciCompiler.hpp >>> >>> + * True if we have seen the a bootstrap compilation request. >>> >>> Typo ?the a?. >>> >>> >>> src/share/vm/jvmci/jvmciRuntime.cpp >>> >>> +void JVMCIRuntime::bootstrapFinished() { >>> >>> Rename the method to bootstrap_finished. Also, this method should use >>> TRAPS and propagate the exception. In JNI_CreateJavaVM_inner use >>> something like this to report exceptions: >>> >>> if (HAS_PENDING_EXCEPTION) { >>> HandleMark hm; >>> vm_exit_during_initialization(Handle(THREAD, PENDING_EXCEPTION)); >>> } >>> >>> + if (_HotSpotJVMCIRuntime_instance != NULL) { >>> >>> Can this ever be not true at this point? >> >> No, I guess you are right. In jdk9 this condition should always hold. >> >>> >>> >>> *test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java* >>> >>> 27 * @requires (os.simpleArch == "x64" | os.simpleArch == >>> "sparcv9" | os.simpleArch == "aarch64") >>> 28 * @requires (os.simpleArch == "x64" | os.simpleArch == >>> "sparcv9" | os.simpleArch == "aarch64") >>> >>> Remove duplicate line. >>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156034 >>>> >>>> It passes all jvmci tests. >>>> >>>> Note that this changes depends on >>>> https://bugs.openjdk.java.net/browse/JDK-8155023 >>>> >>>> Thanks in advance, >>>> Josef > From roland.schatz at oracle.com Wed May 11 10:20:25 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Wed, 11 May 2016 12:20:25 +0200 Subject: RFR: 8156552: [JVMCI] remove final and stable field handling from ConstantReflectionProvider Message-ID: <57330769.7010703@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~rschatz/JDK-8156552/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8156552 This is pure removal of a few methods from the ConstantReflectionProvider interface, their implementation, and their tests. All jvmci jtreg tests pass. Thanks, Roland From felix.yang at linaro.org Wed May 11 12:48:58 2016 From: felix.yang at linaro.org (Felix Yang) Date: Wed, 11 May 2016 20:48:58 +0800 Subject: RFR: 8156731: aarch64: java/util/Arrays/Correct.java fails due to _generic_arraycopy stub routine Message-ID: Hi, Please review webrev: http://cr.openjdk.java.net/~fyang/8156731/webrev.00/ JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8156731 As shown on the JIRA issue, jtreg test case java/util/Arrays/Correct.java fails to pass. After narrowing down, the issue is caused by _generic_arraycopy stub routine. Address calculation in this stub is not correct as compressed oops is not considered here. Patch also fixed a potential defect in generate_conjoint_copy stub routine. Tested with jtreg hotspot and langtools. OK to push? Thanks, Felix -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Wed May 11 13:35:45 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 11 May 2016 16:35:45 +0300 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <57323E78.3080508@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> <573211AA.9000401@oracle.com> <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> <57323E78.3080508@oracle.com> Message-ID: <57333531.2050408@oracle.com> I've merged broken lines and rerun mx eclipseformat with mx checkstyle. Please take a look at http://cr.openjdk.java.net/~dpochepk/8152341/webrev.05/ Thanks, Dmitrij > > Please take a look at v04 with this issue fixed. > > http://cr.openjdk.java.net/~dpochepk/8152341/webrev.04 > > Thanks, > Dmitrij >> >>> On May 10, 2016, at 6:51 AM, Dmitrij Pochepko >>> > >>> wrote: >>> >>> Hi, >>> >>> I've prepared v03 with no checkstyle errors by creating larger lines. >>> >>> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.03/ >>> >> 90 @Test(dataProvider = "negative", dataProviderClass = MemoryAccessProviderData.class, expectedExceptions = {IllegalArgumentException.class }) >> 91 public void testNegativeReadPrimitiveConstant(JavaKind kind, Constant base) { >> 92 PROVIDER.readPrimitiveConstant(kind, base, 0L, >> 93 kind == null ? 0 : kind.getBitCount()); >> 94 } >> The formatting still looks odd. I?ve noticed that sometimes Eclipse >> doesn?t merge lines when it actually could. Doug, have you noticed >> that too? >> >>> >>> Thanks, >>> Dmitrij >>>>> On 10 May 2016, at 16:33, Dmitrij Pochepko >>>>> > >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Yes. I was using netbeans. I've applied eclipse formatter, then >>>>> run mx checkstyle and fixed all warnings except " '.' is preceded >>>>> with whitespace". Fixing this warning will make huge lines. >>>> You can disable the formatter with: >>>> >>>> // @formatter:off >>>> >>>> code that won?t be formatted >>>> >>>> // @formatter:on >>>> >>>> However, the lines don?t look so long to me - maybe you need to get >>>> a larger monitor ;-) >>>> >>>> -Doug >>>> >>>>> Thanks, >>>>> Dmitrij >>>>>>> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> please review patch for 8152341 - JVMCI test task: Unit tests >>>>>>> for MemoryAccessProvider >>>>>>> >>>>>>> A new tests were added for MemoryAccessProvider implementation. >>>>>>> This patch contains tests for all MemoryAccessProvider methods >>>>>>> (mostly a positive and few negative tests per method). A testng >>>>>>> framework is used. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ >>>>>>> >>>>>> These two files don?t look like they have been formatted >>>>>> properly. Did you use an IDE to edit these? >>>>>> >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >>>>>>> >>>>>>> I've tested it on linux_x64 >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.schatz at oracle.com Wed May 11 14:23:55 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Wed, 11 May 2016 16:23:55 +0200 Subject: RFR(S): 8156741: [JVMCI] remove LocationIdentity interface Message-ID: <5733407B.1000508@oracle.com> Hi, Another pure removal change, please review: http://cr.openjdk.java.net/~rschatz/JDK-8156741/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8156741 Thanks, Roland From vladimir.kozlov at oracle.com Wed May 11 15:41:26 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 May 2016 08:41:26 -0700 Subject: RFR: 8156552: [JVMCI] remove final and stable field handling from ConstantReflectionProvider In-Reply-To: <57330769.7010703@oracle.com> References: <57330769.7010703@oracle.com> Message-ID: <573352A6.3020104@oracle.com> Looks good. Thanks, Vladimir On 5/11/16 3:20 AM, Roland Schatz wrote: > Hi, > > Please review: > http://cr.openjdk.java.net/~rschatz/JDK-8156552/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8156552 > > This is pure removal of a few methods from the > ConstantReflectionProvider interface, their implementation, and their > tests. > All jvmci jtreg tests pass. > > Thanks, > Roland From vladimir.kozlov at oracle.com Wed May 11 15:45:25 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 May 2016 08:45:25 -0700 Subject: RFR(S): 8156741: [JVMCI] remove LocationIdentity interface In-Reply-To: <5733407B.1000508@oracle.com> References: <5733407B.1000508@oracle.com> Message-ID: <57335395.9070509@oracle.com> Looks good. Thanks, Vladimir On 5/11/16 7:23 AM, Roland Schatz wrote: > Hi, > > Another pure removal change, please review: > http://cr.openjdk.java.net/~rschatz/JDK-8156741/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8156741 > > Thanks, > Roland From tom.rodriguez at oracle.com Wed May 11 16:45:26 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 11 May 2016 09:45:26 -0700 Subject: RFR 8156775: IGV: StringUtils is absent Message-ID: http://cr.openjdk.java.net/~never/8156775/webrev Forgot to add a file. tom From igor.veresov at oracle.com Wed May 11 16:45:43 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 11 May 2016 09:45:43 -0700 Subject: RFR(S): 8156741: [JVMCI] remove LocationIdentity interface In-Reply-To: <5733407B.1000508@oracle.com> References: <5733407B.1000508@oracle.com> Message-ID: <11561F1E-B84B-4206-B9A8-9FA6591F7EBD@oracle.com> What?s the new location of it in Graal? igor > On May 11, 2016, at 7:23 AM, Roland Schatz wrote: > > Hi, > > Another pure removal change, please review: > http://cr.openjdk.java.net/~rschatz/JDK-8156741/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8156741 > > Thanks, > Roland From vladimir.kozlov at oracle.com Wed May 11 16:46:51 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 May 2016 09:46:51 -0700 Subject: RFR 8156775: IGV: StringUtils is absent In-Reply-To: References: Message-ID: <573361FB.2000308@oracle.com> Good. Thanks, Vladimir On 5/11/16 9:45 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8156775/webrev > > Forgot to add a file. > > tom > From vladimir.x.ivanov at oracle.com Wed May 11 17:11:31 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 11 May 2016 20:11:31 +0300 Subject: RFR 8156775: IGV: StringUtils is absent In-Reply-To: References: Message-ID: <5a9656c2-34ff-813d-e970-d8d6ad979d86@oracle.com> Looks good! Best regards, Vladimir Ivanov On 5/11/16 7:45 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8156775/webrev > > Forgot to add a file. > > tom > From dmitrij.pochepko at oracle.com Wed May 11 18:54:22 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 11 May 2016 21:54:22 +0300 Subject: RFR 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider In-Reply-To: References: <572CA963.3030906@oracle.com> <8CE8A2DA-4E8A-47F6-86E1-E083442F7B2C@oracle.com> <572E611D.7020700@oracle.com> Message-ID: <57337FDE.2020600@oracle.com> Hi, i've added encoded values generation and changed test code to verify expected values based on generation input values. Please take a look at http://cr.openjdk.java.net/~dpochepk/8152343/webrev.03/ Thanks, Dmitrij > >> On May 7, 2016, at 11:41 AM, dmitrij pochepko >> > wrote: >> >>> >>> >>>> On May 6, 2016, at 4:25 AM, Dmitrij Pochepko >>>> > >>>> wrote: >>>> >>>> Hi, >>>> >>>> please review patch for 8152343: JVMCI test tasks: Unit tests for >>>> MetaAccessProvider >>>> >>>> A new tests were added for jdk.vm.ci.meta.MetaAccessProvider >>>> implementation. An existing TestMetaAccessProvider.java was used to >>>> add new tests. >>>> >>>> webrev:http://cr.openjdk.java.net/~dpochepk/8152343/webrev.01/ >>>> >>> + private static final int[] VALID_ENCODED_VALUES = new int[]{-180, >>> -436, -10932, -2147483572}; >>> What are these values? Maybe it would make more sense to have them >>> in hex-form? >> These values are encoded values for deoptReason=Aliasing, >> deoptAction=InvalidateRecompile and debugId={0, 1, 42, 8388607} >> so, we have 0, 1, , 0x7FFFFF which is a >> maximum debugId value here(all 23 bits set) >> >> I've created another webrev with hex values and respective comment added. >> >> http://cr.openjdk.java.net/~dpochepk/8152343/webrev.02 > > Better but I still don?t like them being hardcoded. You should > calculate the values with some defined constants so that someone after > you can understand what?s going on and be able to make changes. > > Also, what is this supposed to test? > + @Test > + public void decodeDeoptReasonTest() { > + for (int encoded : VALID_ENCODED_VALUES) { > + JavaConstant value = JavaConstant.forInt(encoded); > + DeoptimizationReason reason = metaAccess.decodeDeoptReason(value); > + DeoptimizationReason reason2 = metaAccess.decodeDeoptReason(value); > + assertNotNull("Expected not null reason", reason); > + assertEquals("Expected equal reasons", reason, reason2); > + } > + } > That two invocations of the same method on the same receiver with the > same value return the same value? I don?t see how that could fail. > >> >> Thanks, >> Dmitrij >>> >>>> >>>> CR:https://bugs.openjdk.java.net/browse/JDK-8152343 >>>> >>>> I've tested it on linux_x64. >>>> >>>> Thanks, >>>> Dmitrij >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed May 11 19:09:39 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 May 2016 12:09:39 -0700 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <57333531.2050408@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> <573211AA.9000401@oracle.com> <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> <57323E78.3080508@oracle.com> <57333531.2050408@oracle.com> Message-ID: <57338373.30806@oracle.com> Should you use jdk.internal.misc.Unsafe instead of sun.misc.Unsafe? Thanks, Vladimir On 5/11/16 6:35 AM, Dmitrij Pochepko wrote: > I've merged broken lines and rerun mx eclipseformat with mx checkstyle. > > Please take a look at > http://cr.openjdk.java.net/~dpochepk/8152341/webrev.05/ > > Thanks, > Dmitrij >> >> Please take a look at v04 with this issue fixed. >> >> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.04 >> >> Thanks, >> Dmitrij >>> >>>> On May 10, 2016, at 6:51 AM, Dmitrij Pochepko >>>> > >>>> wrote: >>>> >>>> Hi, >>>> >>>> I've prepared v03 with no checkstyle errors by creating larger lines. >>>> >>>> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.03/ >>>> >>> 90 @Test(dataProvider = "negative", dataProviderClass = MemoryAccessProviderData.class, expectedExceptions = {IllegalArgumentException.class }) >>> 91 public void testNegativeReadPrimitiveConstant(JavaKind kind, Constant base) { >>> 92 PROVIDER.readPrimitiveConstant(kind, base, 0L, >>> 93 kind == null ? 0 : kind.getBitCount()); >>> 94 } >>> The formatting still looks odd. I?ve noticed that sometimes Eclipse >>> doesn?t merge lines when it actually could. Doug, have you noticed >>> that too? >>> >>>> >>>> Thanks, >>>> Dmitrij >>>>>> On 10 May 2016, at 16:33, Dmitrij Pochepko >>>>>> <dmitrij.pochepko at oracle.com> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Yes. I was using netbeans. I've applied eclipse formatter, then >>>>>> run mx checkstyle and fixed all warnings except " '.' is preceded >>>>>> with whitespace". Fixing this warning will make huge lines. >>>>> You can disable the formatter with: >>>>> >>>>> // @formatter:off >>>>> >>>>> code that won?t be formatted >>>>> >>>>> // @formatter:on >>>>> >>>>> However, the lines don?t look so long to me - maybe you need to get >>>>> a larger monitor ;-) >>>>> >>>>> -Doug >>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>>>>> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review patch for 8152341 - JVMCI test task: Unit tests >>>>>>>> for MemoryAccessProvider >>>>>>>> >>>>>>>> A new tests were added for MemoryAccessProvider implementation. >>>>>>>> This patch contains tests for all MemoryAccessProvider methods >>>>>>>> (mostly a positive and few negative tests per method). A testng >>>>>>>> framework is used. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ >>>>>>>> >>>>>>> These two files don?t look like they have been formatted >>>>>>> properly. Did you use an IDE to edit these? >>>>>>> >>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >>>>>>>> >>>>>>>> I've tested it on linux_x64 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>> >>> >> > From christian.thalinger at oracle.com Wed May 11 19:21:03 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 May 2016 09:21:03 -1000 Subject: RFR: 8156034: [JVMCI] Notify the jvmci compiler on completion of a bootstrap In-Reply-To: <5732E194.8090306@jku.at> References: <57320870.1040203@jku.at> <57325094.5050504@jku.at> <5732E194.8090306@jku.at> Message-ID: <53410A45-2509-4ABC-8E6F-889F991C64DD@oracle.com> > On May 10, 2016, at 9:39 PM, Josef Eisl wrote: > > Thanks again, Chris and Doug! > > Next iteration of the webrev available here: > http://cr.openjdk.java.net/~jeisl/8156034/webrev.02/ That looks good. > > Thanks, > Josef > > On 10/05/16 23:35, Doug Simon wrote: >> The _bootstrap_compilation_request_seen variable should be renamed to >> _bootstrap_compilation_request_handled. >> >> > > On 10/05/16 23:33, Christian Thalinger wrote: >> >>> On May 10, 2016, at 11:20 AM, Josef Eisl >> > wrote: >>> >>> Thank you for the review! >>> >>> update webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev.01 >>> >> >> I think your change works but the proper way is to pass THREAD >> to JVMCICompiler::bootstrap() and use CHECK here: >> >> + JVMCIRuntime::bootstrap_finished(CHECK); > > That makes sense. I'm still figuring out where to use which macro but > I'm getting closer :). > >>> >>> Thanks, >>> Josef >>> >>> On 05/10/2016 07:30 PM, Christian Thalinger wrote: >>>> >>>>> On May 10, 2016, at 6:12 AM, Josef Eisl >>>> >>>>> > wrote: >>>>> >>>>> Hi! >>>>> >>>>> May I get a review for this JVMCI change. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev/ >>>>> >>>> >>>> >>>> src/share/vm/jvmci/jvmciCompiler.cpp >>>> >>>> + _bootstrap_compilation_request_seen = false; >>>> >>>> Remove the extra space after = >>>> >>>> >>>> src/share/vm/jvmci/jvmciCompiler.hpp >>>> >>>> + * True if we have seen the a bootstrap compilation request. >>>> >>>> Typo ?the a?. >>>> >>>> >>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>> >>>> +void JVMCIRuntime::bootstrapFinished() { >>>> >>>> Rename the method to bootstrap_finished. Also, this method should use >>>> TRAPS and propagate the exception. In JNI_CreateJavaVM_inner use >>>> something like this to report exceptions: >>>> >>>> if (HAS_PENDING_EXCEPTION) { >>>> HandleMark hm; >>>> vm_exit_during_initialization(Handle(THREAD, PENDING_EXCEPTION)); >>>> } >>>> >>>> + if (_HotSpotJVMCIRuntime_instance != NULL) { >>>> >>>> Can this ever be not true at this point? >>> >>> No, I guess you are right. In jdk9 this condition should always hold. >>> >>>> >>>> >>>> *test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java* >>>> >>>> 27 * @requires (os.simpleArch == "x64" | os.simpleArch == >>>> "sparcv9" | os.simpleArch == "aarch64") >>>> 28 * @requires (os.simpleArch == "x64" | os.simpleArch == >>>> "sparcv9" | os.simpleArch == "aarch64") >>>> >>>> Remove duplicate line. >>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156034 >>>>> >>>>> It passes all jvmci tests. >>>>> >>>>> Note that this changes depends on >>>>> https://bugs.openjdk.java.net/browse/JDK-8155023 >>>>> >>>>> Thanks in advance, >>>>> Josef >> > From vladimir.kozlov at oracle.com Wed May 11 19:21:54 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 May 2016 12:21:54 -0700 Subject: RFR: 8152342 - JVMCI test task: Unit tests for MethodHandleAccessProvider In-Reply-To: <57321B9D.8000204@oracle.com> References: <572CADC8.4090004@oracle.com> <23981544-7F7C-4CD0-B4CF-FAD8E42FA52F@oracle.com> <57321B9D.8000204@oracle.com> Message-ID: <57338652.4020803@oracle.com> Good. Missing @bug Thanks, Vladimir On 5/10/16 10:34 AM, Dmitrij Pochepko wrote: > Hi, > > please check v02: http://cr.openjdk.java.net/~dpochepk/8152342/webrev.02/ > > I've applied eclipse formatter and fixed checkstyle warnings. > > Thanks, > Dmitrij > >>> On May 6, 2016, at 4:44 AM, Dmitrij Pochepko >>> wrote: >>> >>> Hi, >>> >>> please review patch for 8152342 - JVMCI test task: Unit tests for >>> MethodHandleAccessProvider >>> >>> A new tests were added for MethodHandleAccessProvider implementation. >>> This patch contains tests for all MethodHandleAccessProvider methods >>> (mostly a positive and few negative tests per method). A testng >>> framework is used. MethodHandleAccessProviderData is used as testng >>> data provider for MethodHandleAccessProviderTest. >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8152342/webrev.01 >> Same formatting question. >> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8152342 >>> >>> I've tested it on linux_x64 >>> >>> Thanks, >>> Dmitrij >>> >>> > From christian.thalinger at oracle.com Wed May 11 19:22:24 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 May 2016 09:22:24 -1000 Subject: RFR: 8156552: [JVMCI] remove final and stable field handling from ConstantReflectionProvider In-Reply-To: <57330769.7010703@oracle.com> References: <57330769.7010703@oracle.com> Message-ID: <3CF27FBD-F37E-486B-B4AB-3F3591E22407@oracle.com> Looks good. > On May 11, 2016, at 12:20 AM, Roland Schatz wrote: > > Hi, > > Please review: > http://cr.openjdk.java.net/~rschatz/JDK-8156552/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8156552 > > This is pure removal of a few methods from the ConstantReflectionProvider interface, their implementation, and their tests. > All jvmci jtreg tests pass. > > Thanks, > Roland From paul.sandoz at oracle.com Wed May 11 19:27:17 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 11 May 2016 21:27:17 +0200 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <57338373.30806@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> <573211AA.9000401@oracle.com> <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> <57323E78.3080508@oracle.com> <57333531.2050408@oracle.com> <57338373.30806@oracle.com> Message-ID: <29C9C66B-02DA-4885-B18C-14CD4022E805@oracle.com> > On 11 May 2016, at 21:09, Vladimir Kozlov wrote: > > Should you use jdk.internal.misc.Unsafe instead of sun.misc.Unsafe? > Yes, see other tests that require the /test/lib library to import jdk.test.lib.Utils; and then declare, say: private static final Unsafe UNSAFE = Utils.getUnsafe(); such as in: test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java Since the data providers are only used from within the MemoryAccessProviderTest i recommend pulling them into MemoryAccessProviderTest unless the intention is that these should be accessible to other test classes at some point, or that is the agreed upon style for this area. 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 josef.eisl at jku.at Wed May 11 19:27:48 2016 From: josef.eisl at jku.at (Josef Eisl) Date: Wed, 11 May 2016 21:27:48 +0200 Subject: RFR: 8156034: [JVMCI] Notify the jvmci compiler on completion of a bootstrap In-Reply-To: <53410A45-2509-4ABC-8E6F-889F991C64DD@oracle.com> References: <57320870.1040203@jku.at> <57325094.5050504@jku.at> <5732E194.8090306@jku.at> <53410A45-2509-4ABC-8E6F-889F991C64DD@oracle.com> Message-ID: <573387B4.9060402@jku.at> Thanks Christian! On 05/11/2016 09:21 PM, Christian Thalinger wrote: > >> On May 10, 2016, at 9:39 PM, Josef Eisl wrote: >> >> Thanks again, Chris and Doug! >> >> Next iteration of the webrev available here: >> http://cr.openjdk.java.net/~jeisl/8156034/webrev.02/ > > That looks good. > >> >> Thanks, >> Josef >> >> On 10/05/16 23:35, Doug Simon wrote: >>> The _bootstrap_compilation_request_seen variable should be renamed to >>> _bootstrap_compilation_request_handled. >>> >>> >> >> On 10/05/16 23:33, Christian Thalinger wrote: >>> >>>> On May 10, 2016, at 11:20 AM, Josef Eisl >>> > wrote: >>>> >>>> Thank you for the review! >>>> >>>> update webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev.01 >>>> >>> >>> I think your change works but the proper way is to pass THREAD >>> to JVMCICompiler::bootstrap() and use CHECK here: >>> >>> + JVMCIRuntime::bootstrap_finished(CHECK); >> >> That makes sense. I'm still figuring out where to use which macro but >> I'm getting closer :). >> >>>> >>>> Thanks, >>>> Josef >>>> >>>> On 05/10/2016 07:30 PM, Christian Thalinger wrote: >>>>> >>>>>> On May 10, 2016, at 6:12 AM, Josef Eisl >>>>> >>>>>> > wrote: >>>>>> >>>>>> Hi! >>>>>> >>>>>> May I get a review for this JVMCI change. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev/ >>>>>> >>>>> >>>>> >>>>> src/share/vm/jvmci/jvmciCompiler.cpp >>>>> >>>>> + _bootstrap_compilation_request_seen = false; >>>>> >>>>> Remove the extra space after = >>>>> >>>>> >>>>> src/share/vm/jvmci/jvmciCompiler.hpp >>>>> >>>>> + * True if we have seen the a bootstrap compilation request. >>>>> >>>>> Typo ?the a?. >>>>> >>>>> >>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>> >>>>> +void JVMCIRuntime::bootstrapFinished() { >>>>> >>>>> Rename the method to bootstrap_finished. Also, this method should use >>>>> TRAPS and propagate the exception. In JNI_CreateJavaVM_inner use >>>>> something like this to report exceptions: >>>>> >>>>> if (HAS_PENDING_EXCEPTION) { >>>>> HandleMark hm; >>>>> vm_exit_during_initialization(Handle(THREAD, PENDING_EXCEPTION)); >>>>> } >>>>> >>>>> + if (_HotSpotJVMCIRuntime_instance != NULL) { >>>>> >>>>> Can this ever be not true at this point? >>>> >>>> No, I guess you are right. In jdk9 this condition should always hold. >>>> >>>>> >>>>> >>>>> *test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java* >>>>> >>>>> 27 * @requires (os.simpleArch == "x64" | os.simpleArch == >>>>> "sparcv9" | os.simpleArch == "aarch64") >>>>> 28 * @requires (os.simpleArch == "x64" | os.simpleArch == >>>>> "sparcv9" | os.simpleArch == "aarch64") >>>>> >>>>> Remove duplicate line. >>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156034 >>>>>> >>>>>> It passes all jvmci tests. >>>>>> >>>>>> Note that this changes depends on >>>>>> https://bugs.openjdk.java.net/browse/JDK-8155023 >>>>>> >>>>>> Thanks in advance, >>>>>> Josef >>> >> > From christian.thalinger at oracle.com Wed May 11 19:29:00 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 May 2016 09:29:00 -1000 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <57333531.2050408@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> <573211AA.9000401@oracle.com> <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> <57323E78.3080508@oracle.com> <57333531.2050408@oracle.com> Message-ID: <2CB45485-F133-46DA-977F-2A2D6FB0B739@oracle.com> > On May 11, 2016, at 3:35 AM, Dmitrij Pochepko wrote: > > I've merged broken lines and rerun mx eclipseformat with mx checkstyle. > > Please take a look at http://cr.openjdk.java.net/~dpochepk/8152341/webrev.05/ That looks good. > > Thanks, > Dmitrij >> >> Please take a look at v04 with this issue fixed. >> >> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.04 >> >> Thanks, >> Dmitrij >>> >>>> On May 10, 2016, at 6:51 AM, Dmitrij Pochepko > wrote: >>>> >>>> Hi, >>>> >>>> I've prepared v03 with no checkstyle errors by creating larger lines. >>>> >>>> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.03/ 90 @Test(dataProvider = "negative", dataProviderClass = MemoryAccessProviderData.class, expectedExceptions = {IllegalArgumentException.class }) >>> 91 public void testNegativeReadPrimitiveConstant(JavaKind kind, Constant base) { >>> 92 PROVIDER.readPrimitiveConstant(kind, base, 0L, >>> 93 kind == null ? 0 : kind.getBitCount()); >>> 94 } >>> The formatting still looks odd. I?ve noticed that sometimes Eclipse doesn?t merge lines when it actually could. Doug, have you noticed that too? >>> >>>> >>>> Thanks, >>>> Dmitrij >>>>>> On 10 May 2016, at 16:33, Dmitrij Pochepko < dmitrij.pochepko at oracle.com > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Yes. I was using netbeans. I've applied eclipse formatter, then run mx checkstyle and fixed all warnings except " '.' is preceded with whitespace". Fixing this warning will make huge lines. >>>>> You can disable the formatter with: >>>>> >>>>> // @formatter:off >>>>> >>>>> code that won?t be formatted >>>>> >>>>> // @formatter:on >>>>> >>>>> However, the lines don?t look so long to me - maybe you need to get a larger monitor ;-) >>>>> >>>>> -Doug >>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>>>>> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko < dmitrij.pochepko at oracle.com > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review patch for 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider >>>>>>>> >>>>>>>> A new tests were added for MemoryAccessProvider implementation. This patch contains tests for all MemoryAccessProvider methods (mostly a positive and few negative tests per method). A testng framework is used. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ >>>>>>> These two files don?t look like they have been formatted properly. Did you use an IDE to edit these? >>>>>>> >>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >>>>>>>> >>>>>>>> I've tested it on linux_x64 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Wed May 11 19:29:24 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 May 2016 09:29:24 -1000 Subject: RFR: 8156034: [JVMCI] Notify the jvmci compiler on completion of a bootstrap In-Reply-To: <573387B4.9060402@jku.at> References: <57320870.1040203@jku.at> <57325094.5050504@jku.at> <5732E194.8090306@jku.at> <53410A45-2509-4ABC-8E6F-889F991C64DD@oracle.com> <573387B4.9060402@jku.at> Message-ID: <9DE180B5-0247-4FBF-879D-32B53652DB8F@oracle.com> Do you need me to integrate this or will Tom do it? > On May 11, 2016, at 9:27 AM, Josef Eisl wrote: > > Thanks Christian! > > On 05/11/2016 09:21 PM, Christian Thalinger wrote: >> >>> On May 10, 2016, at 9:39 PM, Josef Eisl wrote: >>> >>> Thanks again, Chris and Doug! >>> >>> Next iteration of the webrev available here: >>> http://cr.openjdk.java.net/~jeisl/8156034/webrev.02/ >> >> That looks good. >> >>> >>> Thanks, >>> Josef >>> >>> On 10/05/16 23:35, Doug Simon wrote: >>>> The _bootstrap_compilation_request_seen variable should be renamed to >>>> _bootstrap_compilation_request_handled. >>>> >>>> >>> >>> On 10/05/16 23:33, Christian Thalinger wrote: >>>> >>>>> On May 10, 2016, at 11:20 AM, Josef Eisl >>>> > wrote: >>>>> >>>>> Thank you for the review! >>>>> >>>>> update webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev.01 >>>>> >>>> >>>> I think your change works but the proper way is to pass THREAD >>>> to JVMCICompiler::bootstrap() and use CHECK here: >>>> >>>> + JVMCIRuntime::bootstrap_finished(CHECK); >>> >>> That makes sense. I'm still figuring out where to use which macro but >>> I'm getting closer :). >>> >>>>> >>>>> Thanks, >>>>> Josef >>>>> >>>>> On 05/10/2016 07:30 PM, Christian Thalinger wrote: >>>>>> >>>>>>> On May 10, 2016, at 6:12 AM, Josef Eisl >>>>>> >>>>>>> > wrote: >>>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> May I get a review for this JVMCI change. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev/ >>>>>>> >>>>>> >>>>>> >>>>>> src/share/vm/jvmci/jvmciCompiler.cpp >>>>>> >>>>>> + _bootstrap_compilation_request_seen = false; >>>>>> >>>>>> Remove the extra space after = >>>>>> >>>>>> >>>>>> src/share/vm/jvmci/jvmciCompiler.hpp >>>>>> >>>>>> + * True if we have seen the a bootstrap compilation request. >>>>>> >>>>>> Typo ?the a?. >>>>>> >>>>>> >>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>> >>>>>> +void JVMCIRuntime::bootstrapFinished() { >>>>>> >>>>>> Rename the method to bootstrap_finished. Also, this method should use >>>>>> TRAPS and propagate the exception. In JNI_CreateJavaVM_inner use >>>>>> something like this to report exceptions: >>>>>> >>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>> HandleMark hm; >>>>>> vm_exit_during_initialization(Handle(THREAD, PENDING_EXCEPTION)); >>>>>> } >>>>>> >>>>>> + if (_HotSpotJVMCIRuntime_instance != NULL) { >>>>>> >>>>>> Can this ever be not true at this point? >>>>> >>>>> No, I guess you are right. In jdk9 this condition should always hold. >>>>> >>>>>> >>>>>> >>>>>> *test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java* >>>>>> >>>>>> 27 * @requires (os.simpleArch == "x64" | os.simpleArch == >>>>>> "sparcv9" | os.simpleArch == "aarch64") >>>>>> 28 * @requires (os.simpleArch == "x64" | os.simpleArch == >>>>>> "sparcv9" | os.simpleArch == "aarch64") >>>>>> >>>>>> Remove duplicate line. >>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156034 >>>>>>> >>>>>>> It passes all jvmci tests. >>>>>>> >>>>>>> Note that this changes depends on >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155023 >>>>>>> >>>>>>> Thanks in advance, >>>>>>> Josef >>>> >>> >> > From dmitrij.pochepko at oracle.com Wed May 11 19:33:07 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 11 May 2016 22:33:07 +0300 Subject: RFR: 8152341 - JVMCI test task: Unit tests for MemoryAccessProvider In-Reply-To: <2CB45485-F133-46DA-977F-2A2D6FB0B739@oracle.com> References: <572CAC7C.3040700@oracle.com> <5731F134.8050102@oracle.com> <442EB3F8-7B43-425E-9EB1-D44803519224@oracle.com> <573211AA.9000401@oracle.com> <20918FD9-C9AB-4704-88C8-526BC971ACE9@oracle.com> <57323E78.3080508@oracle.com> <57333531.2050408@oracle.com> <2CB45485-F133-46DA-977F-2A2D6FB0B739@oracle.com> Message-ID: <573388F3.4040803@oracle.com> Thank you! > >> On May 11, 2016, at 3:35 AM, Dmitrij Pochepko >> > wrote: >> >> I've merged broken lines and rerun mx eclipseformat with mx checkstyle. >> >> Please take a look at >> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.05/ > > That looks good. > >> >> Thanks, >> Dmitrij >>> >>> Please take a look at v04 with this issue fixed. >>> >>> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.04 >>> >>> Thanks, >>> Dmitrij >>>> >>>>> On May 10, 2016, at 6:51 AM, Dmitrij Pochepko >>>>> > >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I've prepared v03 with no checkstyle errors by creating larger lines. >>>>> >>>>> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.03/ >>>>> >>>> 90 @Test(dataProvider = "negative", dataProviderClass = MemoryAccessProviderData.class, expectedExceptions = {IllegalArgumentException.class }) >>>> 91 public void testNegativeReadPrimitiveConstant(JavaKind kind, Constant base) { >>>> 92 PROVIDER.readPrimitiveConstant(kind, base, 0L, >>>> 93 kind == null ? 0 : kind.getBitCount()); >>>> 94 } >>>> The formatting still looks odd. I?ve noticed that sometimes >>>> Eclipse doesn?t merge lines when it actually could. Doug, have you >>>> noticed that too? >>>> >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>>> On 10 May 2016, at 16:33, Dmitrij Pochepko >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Yes. I was using netbeans. I've applied eclipse formatter, then >>>>>>> run mx checkstyle and fixed all warnings except " '.' is >>>>>>> preceded with whitespace". Fixing this warning will make huge lines. >>>>>> You can disable the formatter with: >>>>>> >>>>>> // @formatter:off >>>>>> >>>>>> code that won?t be formatted >>>>>> >>>>>> // @formatter:on >>>>>> >>>>>> However, the lines don?t look so long to me - maybe you need to >>>>>> get a larger monitor ;-) >>>>>> >>>>>> -Doug >>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>>> On May 6, 2016, at 4:38 AM, Dmitrij Pochepko >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please review patch for 8152341 - JVMCI test task: Unit tests >>>>>>>>> for MemoryAccessProvider >>>>>>>>> >>>>>>>>> A new tests were added for MemoryAccessProvider >>>>>>>>> implementation. This patch contains tests for all >>>>>>>>> MemoryAccessProvider methods (mostly a positive and few >>>>>>>>> negative tests per method). A testng framework is used. >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~dpochepk/8152341/webrev.01/ >>>>>>>>> >>>>>>>> These two files don?t look like they have been formatted >>>>>>>> properly. Did you use an IDE to edit these? >>>>>>>> >>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152341 >>>>>>>>> >>>>>>>>> I've tested it on linux_x64 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Wed May 11 20:19:43 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 11 May 2016 22:19:43 +0200 Subject: RFR: 8156759: [JVMCI] remove JVMCIError and UnsafeUtil classes Message-ID: <180D47E0-D731-4BC2-9935-1B12BB376469@oracle.com> Please review this change which removes a couple of classes which do not need to be in JVMCI. I?ve also taken the liberty of including a change that updates the mx Java compliance level for all JVMCI projects to 9 since JDK9 API (e.g., java.lang.reflect.Module) is now used in JVMCI. This means building with mx has been broken since that API usage was introduced. I can pull this out into a separate RFE if necessary but am hoping it can piggy back on this bug. https://bugs.openjdk.java.net/browse/JDK-8156759 http://cr.openjdk.java.net/~dnsimon/8156759 -Doug From tom.rodriguez at oracle.com Wed May 11 20:36:48 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 11 May 2016 13:36:48 -0700 Subject: RFR: 8156034: [JVMCI] Notify the jvmci compiler on completion of a bootstrap In-Reply-To: <9DE180B5-0247-4FBF-879D-32B53652DB8F@oracle.com> References: <57320870.1040203@jku.at> <57325094.5050504@jku.at> <5732E194.8090306@jku.at> <53410A45-2509-4ABC-8E6F-889F991C64DD@oracle.com> <573387B4.9060402@jku.at> <9DE180B5-0247-4FBF-879D-32B53652DB8F@oracle.com> Message-ID: <78E6C860-F420-4EBF-AA97-9991D9EEF1FA@oracle.com> I can take care of it. tom > On May 11, 2016, at 12:29 PM, Christian Thalinger wrote: > > Do you need me to integrate this or will Tom do it? > >> On May 11, 2016, at 9:27 AM, Josef Eisl wrote: >> >> Thanks Christian! >> >> On 05/11/2016 09:21 PM, Christian Thalinger wrote: >>> >>>> On May 10, 2016, at 9:39 PM, Josef Eisl wrote: >>>> >>>> Thanks again, Chris and Doug! >>>> >>>> Next iteration of the webrev available here: >>>> http://cr.openjdk.java.net/~jeisl/8156034/webrev.02/ >>> >>> That looks good. >>> >>>> >>>> Thanks, >>>> Josef >>>> >>>> On 10/05/16 23:35, Doug Simon wrote: >>>>> The _bootstrap_compilation_request_seen variable should be renamed to >>>>> _bootstrap_compilation_request_handled. >>>>> >>>>> >>>> >>>> On 10/05/16 23:33, Christian Thalinger wrote: >>>>> >>>>>> On May 10, 2016, at 11:20 AM, Josef Eisl >>>>> > wrote: >>>>>> >>>>>> Thank you for the review! >>>>>> >>>>>> update webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev.01 >>>>>> >>>>> >>>>> I think your change works but the proper way is to pass THREAD >>>>> to JVMCICompiler::bootstrap() and use CHECK here: >>>>> >>>>> + JVMCIRuntime::bootstrap_finished(CHECK); >>>> >>>> That makes sense. I'm still figuring out where to use which macro but >>>> I'm getting closer :). >>>> >>>>>> >>>>>> Thanks, >>>>>> Josef >>>>>> >>>>>> On 05/10/2016 07:30 PM, Christian Thalinger wrote: >>>>>>> >>>>>>>> On May 10, 2016, at 6:12 AM, Josef Eisl >>>>>>> >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>> May I get a review for this JVMCI change. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~jeisl/8156034/webrev/ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> src/share/vm/jvmci/jvmciCompiler.cpp >>>>>>> >>>>>>> + _bootstrap_compilation_request_seen = false; >>>>>>> >>>>>>> Remove the extra space after = >>>>>>> >>>>>>> >>>>>>> src/share/vm/jvmci/jvmciCompiler.hpp >>>>>>> >>>>>>> + * True if we have seen the a bootstrap compilation request. >>>>>>> >>>>>>> Typo ?the a?. >>>>>>> >>>>>>> >>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp >>>>>>> >>>>>>> +void JVMCIRuntime::bootstrapFinished() { >>>>>>> >>>>>>> Rename the method to bootstrap_finished. Also, this method should use >>>>>>> TRAPS and propagate the exception. In JNI_CreateJavaVM_inner use >>>>>>> something like this to report exceptions: >>>>>>> >>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>> HandleMark hm; >>>>>>> vm_exit_during_initialization(Handle(THREAD, PENDING_EXCEPTION)); >>>>>>> } >>>>>>> >>>>>>> + if (_HotSpotJVMCIRuntime_instance != NULL) { >>>>>>> >>>>>>> Can this ever be not true at this point? >>>>>> >>>>>> No, I guess you are right. In jdk9 this condition should always hold. >>>>>> >>>>>>> >>>>>>> >>>>>>> *test/compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java* >>>>>>> >>>>>>> 27 * @requires (os.simpleArch == "x64" | os.simpleArch == >>>>>>> "sparcv9" | os.simpleArch == "aarch64") >>>>>>> 28 * @requires (os.simpleArch == "x64" | os.simpleArch == >>>>>>> "sparcv9" | os.simpleArch == "aarch64") >>>>>>> >>>>>>> Remove duplicate line. >>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156034 >>>>>>>> >>>>>>>> It passes all jvmci tests. >>>>>>>> >>>>>>>> Note that this changes depends on >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155023 >>>>>>>> >>>>>>>> Thanks in advance, >>>>>>>> Josef >>>>> >>>> >>> >> > From dmitrij.pochepko at oracle.com Wed May 11 20:43:21 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 11 May 2016 23:43:21 +0300 Subject: RFR 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider In-Reply-To: <57337FDE.2020600@oracle.com> References: <572CA963.3030906@oracle.com> <8CE8A2DA-4E8A-47F6-86E1-E083442F7B2C@oracle.com> <572E611D.7020700@oracle.com> <57337FDE.2020600@oracle.com> Message-ID: <57339969.1030809@oracle.com> Also performed mx eclipseformat and checkstyle and prepared v04 http://cr.openjdk.java.net/~dpochepk/8152343/webrev.04/ Thanks, Dmitrij > Hi, > > i've added encoded values generation and changed test code to verify > expected values based on generation input values. > > Please take a look at > http://cr.openjdk.java.net/~dpochepk/8152343/webrev.03/ > > Thanks, > Dmitrij >> >>> On May 7, 2016, at 11:41 AM, dmitrij pochepko >>> > >>> wrote: >>> >>>> >>>> >>>>> On May 6, 2016, at 4:25 AM, Dmitrij Pochepko >>>>> > >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> please review patch for 8152343: JVMCI test tasks: Unit tests for >>>>> MetaAccessProvider >>>>> >>>>> A new tests were added for jdk.vm.ci.meta.MetaAccessProvider >>>>> implementation. An existing TestMetaAccessProvider.java was used >>>>> to add new tests. >>>>> >>>>> webrev:http://cr.openjdk.java.net/~dpochepk/8152343/webrev.01/ >>>> + private static final int[] VALID_ENCODED_VALUES = new int[]{-180, >>>> -436, -10932, -2147483572}; >>>> What are these values? Maybe it would make more sense to have them >>>> in hex-form? >>> These values are encoded values for deoptReason=Aliasing, >>> deoptAction=InvalidateRecompile and debugId={0, 1, 42, 8388607} >>> so, we have 0, 1, , 0x7FFFFF which is a >>> maximum debugId value here(all 23 bits set) >>> >>> I've created another webrev with hex values and respective comment >>> added. >>> >>> http://cr.openjdk.java.net/~dpochepk/8152343/webrev.02 >> >> Better but I still don?t like them being hardcoded. You should >> calculate the values with some defined constants so that someone >> after you can understand what?s going on and be able to make changes. >> >> Also, what is this supposed to test? >> + @Test >> + public void decodeDeoptReasonTest() { >> + for (int encoded : VALID_ENCODED_VALUES) { >> + JavaConstant value = JavaConstant.forInt(encoded); >> + DeoptimizationReason reason = metaAccess.decodeDeoptReason(value); >> + DeoptimizationReason reason2 = metaAccess.decodeDeoptReason(value); >> + assertNotNull("Expected not null reason", reason); >> + assertEquals("Expected equal reasons", reason, reason2); >> + } >> + } >> That two invocations of the same method on the same receiver with the >> same value return the same value? I don?t see how that could fail. >> >>> >>> Thanks, >>> Dmitrij >>>> >>>>> >>>>> CR:https://bugs.openjdk.java.net/browse/JDK-8152343 >>>>> >>>>> I've tested it on linux_x64. >>>>> >>>>> Thanks, >>>>> Dmitrij >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Wed May 11 20:46:15 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 11 May 2016 23:46:15 +0300 Subject: RFR: 8152342 - JVMCI test task: Unit tests for MethodHandleAccessProvider In-Reply-To: <57321B9D.8000204@oracle.com> References: <572CADC8.4090004@oracle.com> <23981544-7F7C-4CD0-B4CF-FAD8E42FA52F@oracle.com> <57321B9D.8000204@oracle.com> Message-ID: <57339A17.6070805@oracle.com> Hi, please check v03. I've re-applied formatting after some merging lines. http://cr.openjdk.java.net/~dpochepk/8152342/webrev.03/ Thanks, Dmitrij > Hi, > > please check v02: http://cr.openjdk.java.net/~dpochepk/8152342/webrev.02/ > > I've applied eclipse formatter and fixed checkstyle warnings. > > Thanks, > Dmitrij > >>> On May 6, 2016, at 4:44 AM, Dmitrij Pochepko >>> wrote: >>> >>> Hi, >>> >>> please review patch for 8152342 - JVMCI test task: Unit tests for >>> MethodHandleAccessProvider >>> >>> A new tests were added for MethodHandleAccessProvider >>> implementation. This patch contains tests for all >>> MethodHandleAccessProvider methods (mostly a positive and few >>> negative tests per method). A testng framework is used. >>> MethodHandleAccessProviderData is used as testng data provider for >>> MethodHandleAccessProviderTest. >>> >>> webrev: http://cr.openjdk.java.net/~dpochepk/8152342/webrev.01 >> Same formatting question. >> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8152342 >>> >>> I've tested it on linux_x64 >>> >>> Thanks, >>> Dmitrij >>> >>> > From christian.thalinger at oracle.com Wed May 11 20:54:04 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 May 2016 10:54:04 -1000 Subject: RFR: 8156759: [JVMCI] remove JVMCIError and UnsafeUtil classes In-Reply-To: <180D47E0-D731-4BC2-9935-1B12BB376469@oracle.com> References: <180D47E0-D731-4BC2-9935-1B12BB376469@oracle.com> Message-ID: <196A4F27-3F03-4183-81B5-21748122185D@oracle.com> > On May 11, 2016, at 10:19 AM, Doug Simon wrote: > > Please review this change which removes a couple of classes which do not need to be in JVMCI. > > I?ve also taken the liberty of including a change that updates the mx Java compliance level for all JVMCI projects to 9 since JDK9 API (e.g., java.lang.reflect.Module) is now used in JVMCI. This means building with mx has been broken since that API usage was introduced. I can pull this out into a separate RFE if necessary but am hoping it can piggy back on this bug. > > https://bugs.openjdk.java.net/browse/JDK-8156759 The JIRA issue states: "Only Graal uses the context functionality of JVMCIError so it will move it Graal.? But there is more value to JVMCIError than just the context functionality. Having a separate JVMCI exception class can be useful when catching exceptions. > http://cr.openjdk.java.net/~dnsimon/8156759 > > -Doug From christian.thalinger at oracle.com Wed May 11 21:03:39 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 May 2016 11:03:39 -1000 Subject: RFR 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider In-Reply-To: <57339969.1030809@oracle.com> References: <572CA963.3030906@oracle.com> <8CE8A2DA-4E8A-47F6-86E1-E083442F7B2C@oracle.com> <572E611D.7020700@oracle.com> <57337FDE.2020600@oracle.com> <57339969.1030809@oracle.com> Message-ID: > On May 11, 2016, at 10:43 AM, Dmitrij Pochepko wrote: > > Also performed mx eclipseformat and checkstyle and prepared v04 > > http://cr.openjdk.java.net/~dpochepk/8152343/webrev.04/ That looks good. > > Thanks, > Dmitrij >> Hi, >> >> i've added encoded values generation and changed test code to verify expected values based on generation input values. >> >> Please take a look at http://cr.openjdk.java.net/~dpochepk/8152343/webrev.03/ >> >> Thanks, >> Dmitrij >>> >>>> On May 7, 2016, at 11:41 AM, dmitrij pochepko > wrote: >>>> >>>>> >>>>> >>>>>> On May 6, 2016, at 4:25 AM, Dmitrij Pochepko > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> please review patch for 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider >>>>>> >>>>>> A new tests were added for jdk.vm.ci.meta.MetaAccessProvider implementation. An existing TestMetaAccessProvider.java was used to add new tests. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8152343/webrev.01/ + private static final int[] VALID_ENCODED_VALUES = new int[]{-180, -436, -10932, -2147483572}; >>>>> What are these values? Maybe it would make more sense to have them in hex-form? >>>> These values are encoded values for deoptReason=Aliasing, deoptAction=InvalidateRecompile and debugId={0, 1, 42, 8388607} >>>> so, we have 0, 1, , 0x7FFFFF which is a maximum debugId value here(all 23 bits set) >>>> >>>> I've created another webrev with hex values and respective comment added. >>>> >>>> http://cr.openjdk.java.net/~dpochepk/8152343/webrev.02 >>> >>> Better but I still don?t like them being hardcoded. You should calculate the values with some defined constants so that someone after you can understand what?s going on and be able to make changes. >>> >>> Also, what is this supposed to test? >>> + @Test >>> + public void decodeDeoptReasonTest() { >>> + for (int encoded : VALID_ENCODED_VALUES) { >>> + JavaConstant value = JavaConstant.forInt(encoded); >>> + DeoptimizationReason reason = metaAccess.decodeDeoptReason(value); >>> + DeoptimizationReason reason2 = metaAccess.decodeDeoptReason(value); >>> + assertNotNull("Expected not null reason", reason); >>> + assertEquals("Expected equal reasons", reason, reason2); >>> + } >>> + } >>> That two invocations of the same method on the same receiver with the same value return the same value? I don?t see how that could fail. >>> >>>> >>>> Thanks, >>>> Dmitrij >>>>> >>>>> >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152343 >>>>>> >>>>>> I've tested it on linux_x64. >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Wed May 11 21:09:16 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 11 May 2016 23:09:16 +0200 Subject: RFR: 8156759: [JVMCI] remove JVMCIError and UnsafeUtil classes In-Reply-To: <196A4F27-3F03-4183-81B5-21748122185D@oracle.com> References: <180D47E0-D731-4BC2-9935-1B12BB376469@oracle.com> <196A4F27-3F03-4183-81B5-21748122185D@oracle.com> Message-ID: <43D7142F-FCE2-431F-B26A-4F01D6FFD284@oracle.com> > On 11 May 2016, at 22:54, Christian Thalinger wrote: > > >> On May 11, 2016, at 10:19 AM, Doug Simon wrote: >> >> Please review this change which removes a couple of classes which do not need to be in JVMCI. >> >> I?ve also taken the liberty of including a change that updates the mx Java compliance level for all JVMCI projects to 9 since JDK9 API (e.g., java.lang.reflect.Module) is now used in JVMCI. This means building with mx has been broken since that API usage was introduced. I can pull this out into a separate RFE if necessary but am hoping it can piggy back on this bug. >> >> https://bugs.openjdk.java.net/browse/JDK-8156759 > > The JIRA issue states: > > "Only Graal uses the context functionality of JVMCIError so it will move it Graal.? > > But there is more value to JVMCIError than just the context functionality. Having a separate JVMCI exception class can be useful when catching exceptions. Grepping through other jdk code, I see 587 instances of ?new InternalError? so I?d say it?s an appropriate choice. The stack trace is the most useful part of the errors thrown from within JVMCI and they aren?t going to change. What other uses do you have in mind? -Doug From doug.simon at oracle.com Wed May 11 21:21:21 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 11 May 2016 23:21:21 +0200 Subject: RFR: 8156759: [JVMCI] remove JVMCIError and UnsafeUtil classes In-Reply-To: <43D7142F-FCE2-431F-B26A-4F01D6FFD284@oracle.com> References: <180D47E0-D731-4BC2-9935-1B12BB376469@oracle.com> <196A4F27-3F03-4183-81B5-21748122185D@oracle.com> <43D7142F-FCE2-431F-B26A-4F01D6FFD284@oracle.com> Message-ID: <01EE8DDD-1BBE-4D87-800E-748937E4CBA0@oracle.com> > On 11 May 2016, at 23:09, Doug Simon wrote: > >> >> On 11 May 2016, at 22:54, Christian Thalinger wrote: >> >> >>> On May 11, 2016, at 10:19 AM, Doug Simon wrote: >>> >>> Please review this change which removes a couple of classes which do not need to be in JVMCI. >>> >>> I?ve also taken the liberty of including a change that updates the mx Java compliance level for all JVMCI projects to 9 since JDK9 API (e.g., java.lang.reflect.Module) is now used in JVMCI. This means building with mx has been broken since that API usage was introduced. I can pull this out into a separate RFE if necessary but am hoping it can piggy back on this bug. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8156759 >> >> The JIRA issue states: >> >> "Only Graal uses the context functionality of JVMCIError so it will move it Graal.? >> >> But there is more value to JVMCIError than just the context functionality. Having a separate JVMCI exception class can be useful when catching exceptions. > > Grepping through other jdk code, I see 587 instances of ?new InternalError? so I?d say it?s an appropriate choice. The stack trace is the most useful part of the errors thrown from within JVMCI and they aren?t going to change. What other uses do you have in mind? BTW, I have not seen any uses of 'catch (JVMCIError e) {...}?. -Doug From aleksey.shipilev at oracle.com Wed May 11 21:33:00 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 12 May 2016 00:33:00 +0300 Subject: RFR (XS) 8156803: Turn StressLCM/StressGCM flags to diagnostic Message-ID: <5733A50C.5010609@oracle.com> Hi, In order to better test the concurrency support in JVM, we introduced StressLCM/StressGCM flags that randomize C2's instruction scheduling: develop(bool, StressLCM, false, \ "Randomize instruction scheduling in LCM") \ develop(bool, StressGCM, false, \ "Randomize instruction scheduling in GCM") \ These, however, require fastdebug build, which is not really fast for concurrency testing, as it does lots of asserts in VM codepaths (notably, GC). We would be better off turning these flags to diagnostic, to pop out in product builds. Bug: https://bugs.openjdk.java.net/browse/JDK-8156803 Webrev: http://cr.openjdk.java.net/~shade/8156803/webrev.01/ Testing: manual testing with local x86_64/release build. I don't think we need to waste machine time on deeply testing this trivial change? 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 dmitrij.pochepko at oracle.com Wed May 11 21:48:19 2016 From: dmitrij.pochepko at oracle.com (dmitrij pochepko) Date: Thu, 12 May 2016 00:48:19 +0300 Subject: RFR 8152343: JVMCI test tasks: Unit tests for MetaAccessProvider In-Reply-To: References: <572CA963.3030906@oracle.com> <8CE8A2DA-4E8A-47F6-86E1-E083442F7B2C@oracle.com> <572E611D.7020700@oracle.com> <57337FDE.2020600@oracle.com> <57339969.1030809@oracle.com> Message-ID: <5733A8A3.2050608@oracle.com> Thank you! > >> On May 11, 2016, at 10:43 AM, Dmitrij Pochepko >> > wrote: >> >> Also performed mx eclipseformat and checkstyle and prepared v04 >> >> http://cr.openjdk.java.net/~dpochepk/8152343/webrev.04/ > > That looks good. > >> >> Thanks, >> Dmitrij >>> Hi, >>> >>> i've added encoded values generation and changed test code to verify >>> expected values based on generation input values. >>> >>> Please take a look at >>> http://cr.openjdk.java.net/~dpochepk/8152343/webrev.03/ >>> >>> Thanks, >>> Dmitrij >>>> >>>>> On May 7, 2016, at 11:41 AM, dmitrij pochepko >>>>> > >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>>> On May 6, 2016, at 4:25 AM, Dmitrij Pochepko >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> please review patch for 8152343: JVMCI test tasks: Unit tests >>>>>>> for MetaAccessProvider >>>>>>> >>>>>>> A new tests were added for jdk.vm.ci.meta.MetaAccessProvider >>>>>>> implementation. An existing TestMetaAccessProvider.java was used >>>>>>> to add new tests. >>>>>>> >>>>>>> webrev:http://cr.openjdk.java.net/~dpochepk/8152343/webrev.01/ >>>>>> + private static final int[] VALID_ENCODED_VALUES = new >>>>>> int[]{-180, -436, -10932, -2147483572}; >>>>>> What are these values? Maybe it would make more sense to have >>>>>> them in hex-form? >>>>> These values are encoded values for deoptReason=Aliasing, >>>>> deoptAction=InvalidateRecompile and debugId={0, 1, 42, 8388607} >>>>> so, we have 0, 1, , 0x7FFFFF which is a >>>>> maximum debugId value here(all 23 bits set) >>>>> >>>>> I've created another webrev with hex values and respective comment >>>>> added. >>>>> >>>>> http://cr.openjdk.java.net/~dpochepk/8152343/webrev.02 >>>> >>>> Better but I still don?t like them being hardcoded. You should >>>> calculate the values with some defined constants so that someone >>>> after you can understand what?s going on and be able to make changes. >>>> >>>> Also, what is this supposed to test? >>>> + @Test >>>> + public void decodeDeoptReasonTest() { >>>> + for (int encoded : VALID_ENCODED_VALUES) { >>>> + JavaConstant value = JavaConstant.forInt(encoded); >>>> + DeoptimizationReason reason = metaAccess.decodeDeoptReason(value); >>>> + DeoptimizationReason reason2 = metaAccess.decodeDeoptReason(value); >>>> + assertNotNull("Expected not null reason", reason); >>>> + assertEquals("Expected equal reasons", reason, reason2); >>>> + } >>>> + } >>>> That two invocations of the same method on the same receiver with >>>> the same value return the same value? I don?t see how that could fail. >>>> >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>> >>>>>>> >>>>>>> CR:https://bugs.openjdk.java.net/browse/JDK-8152343 >>>>>>> >>>>>>> I've tested it on linux_x64. >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.tornqvist at oracle.com Wed May 11 21:51:22 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 11 May 2016 17:51:22 -0400 Subject: RFR (XS) 8156803: Turn StressLCM/StressGCM flags to diagnostic In-Reply-To: <5733A50C.5010609@oracle.com> References: <5733A50C.5010609@oracle.com> Message-ID: <07fe01d1abcf$4276d8c0$c7648a40$@oracle.com> Hi Aleksey, FC for HS is in 4h, after that you can't check RFE's in. I suggest you postpone this change to the next minor release. Thanks, Christian -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Aleksey Shipilev Sent: Wednesday, May 11, 2016 5:33 PM To: hotspot compiler Subject: RFR (XS) 8156803: Turn StressLCM/StressGCM flags to diagnostic Hi, In order to better test the concurrency support in JVM, we introduced StressLCM/StressGCM flags that randomize C2's instruction scheduling: develop(bool, StressLCM, false, \ "Randomize instruction scheduling in LCM") \ develop(bool, StressGCM, false, \ "Randomize instruction scheduling in GCM") \ These, however, require fastdebug build, which is not really fast for concurrency testing, as it does lots of asserts in VM codepaths (notably, GC). We would be better off turning these flags to diagnostic, to pop out in product builds. Bug: https://bugs.openjdk.java.net/browse/JDK-8156803 Webrev: http://cr.openjdk.java.net/~shade/8156803/webrev.01/ Testing: manual testing with local x86_64/release build. I don't think we need to waste machine time on deeply testing this trivial change? Thanks, -Aleksey From vladimir.kozlov at oracle.com Wed May 11 21:54:32 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 May 2016 14:54:32 -0700 Subject: RFR (XS) 8156803: Turn StressLCM/StressGCM flags to diagnostic In-Reply-To: <5733A50C.5010609@oracle.com> References: <5733A50C.5010609@oracle.com> Message-ID: <5733AA18.3020702@oracle.com> Looks good. Thanks, Vladimir On 5/11/16 2:33 PM, Aleksey Shipilev wrote: > Hi, > > In order to better test the concurrency support in JVM, we introduced > StressLCM/StressGCM flags that randomize C2's instruction scheduling: > > develop(bool, StressLCM, false, \ > "Randomize instruction scheduling in LCM") \ > > develop(bool, StressGCM, false, \ > "Randomize instruction scheduling in GCM") \ > > These, however, require fastdebug build, which is not really fast for > concurrency testing, as it does lots of asserts in VM codepaths > (notably, GC). We would be better off turning these flags to diagnostic, > to pop out in product builds. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8156803 > > Webrev: > http://cr.openjdk.java.net/~shade/8156803/webrev.01/ > > Testing: manual testing with local x86_64/release build. I don't think > we need to waste machine time on deeply testing this trivial change? > > Thanks, > -Aleksey > From aleksey.shipilev at oracle.com Wed May 11 21:57:36 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 12 May 2016 00:57:36 +0300 Subject: RFR (XS) 8156803: Turn StressLCM/StressGCM flags to diagnostic In-Reply-To: <07fe01d1abcf$4276d8c0$c7648a40$@oracle.com> References: <5733A50C.5010609@oracle.com> <07fe01d1abcf$4276d8c0$c7648a40$@oracle.com> Message-ID: <5733AAD0.3010102@oracle.com> On 05/12/2016 12:51 AM, Christian Tornqvist wrote: > FC for HS is in 4h, after that you can't check RFE's in. I suggest > you postpone this change to the next minor release. Unfortunately, "next minor release" is too late if you want to test JDK 9 GA (e.g. VarHandles) properly. Which requires these flags to be available before then. I couldn't think up a sane definition of FC would preclude pushing this change, even after some additional scrutiny. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From aleksey.shipilev at oracle.com Wed May 11 22:16:48 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 12 May 2016 01:16:48 +0300 Subject: RFR (S) 8153792: EA: assert(ptn->as_LocalVar()->edge_count() > 0) failed: sanity when compiling compareAndExchange Message-ID: <5733AF50.9080402@oracle.com> Hi, Please review the bugfix for the EA assert failure when compiling new compareAndExchange intrinsics: https://bugs.openjdk.java.net/browse/JDK-8153792 The bug is caused by the initial VarHandles change in the EA, and is actually a simple overlook: Op_CompareAndExchange* were added at the same switch case as Op_GetAndSet* (since they are similar), but the condition within the case itself was not changed. So, EA misses an edge from the load, and complains. Easy fix: http://cr.openjdk.java.net/~shade/8153792/webrev.01/ Testing: local Linux x86/fastdebug and failing test; RBT (hs-comp-tier0) Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From vladimir.kozlov at oracle.com Wed May 11 22:27:58 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 May 2016 15:27:58 -0700 Subject: RFR (S) 8153792: EA: assert(ptn->as_LocalVar()->edge_count() > 0) failed: sanity when compiling compareAndExchange In-Reply-To: <5733AF50.9080402@oracle.com> References: <5733AF50.9080402@oracle.com> Message-ID: <5733B1EE.8090701@oracle.com> The fix is good but fix indent: + if (opcode == Op_GetAndSetP || opcode == Op_GetAndSetN || + opcode == Op_CompareAndExchangeN || opcode == Op_CompareAndExchangeP) { Thanks, Vladimir On 5/11/16 3:16 PM, Aleksey Shipilev wrote: > Hi, > > Please review the bugfix for the EA assert failure when compiling new > compareAndExchange intrinsics: > https://bugs.openjdk.java.net/browse/JDK-8153792 > > The bug is caused by the initial VarHandles change in the EA, and is > actually a simple overlook: Op_CompareAndExchange* were added at the > same switch case as Op_GetAndSet* (since they are similar), but the > condition within the case itself was not changed. So, EA misses an edge > from the load, and complains. > > Easy fix: > http://cr.openjdk.java.net/~shade/8153792/webrev.01/ > > Testing: local Linux x86/fastdebug and failing test; RBT (hs-comp-tier0) > > Thanks, > -Aleksey > From dmitrij.pochepko at oracle.com Thu May 12 01:41:51 2016 From: dmitrij.pochepko at oracle.com (dmitrij pochepko) Date: Thu, 12 May 2016 04:41:51 +0300 Subject: RFR: 8141149 - [jittester] create Visitor for generating bytecode Message-ID: <5733DF5F.5000504@oracle.com> Hi, please review cumulative fix for 8141149 - ?[jittester] create Visitor for generating bytecode? and 8149463 - ?[jittester] rarely generates tests with compile error?. 8141149 is a massive update introducing new functionality - direct bytecode generation. A special ByteCodeVisitor was created and a number of common classes were changed to support ByteCodeVisitor. These changes also affects java code generation part because of changes in common part. the changeset also includes a bug fix for 8149463 which caused incorrectly generated IR. webrev: http://cr.openjdk.java.net/~dpochepk/8141149/webrev.01/ CRs: https://bugs.openjdk.java.net/browse/JDK-8141149 https://bugs.openjdk.java.net/browse/JDK-8149463 Thanks, Dmitrij From igor.veresov at oracle.com Thu May 12 03:26:34 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 11 May 2016 20:26:34 -0700 Subject: RFR: 8141149 - [jittester] create Visitor for generating bytecode In-Reply-To: <5733DF5F.5000504@oracle.com> References: <5733DF5F.5000504@oracle.com> Message-ID: <151B0A30-F19C-40E4-91DE-1B8D05A7A574@oracle.com> Great job! Looks good to me. igor > On May 11, 2016, at 6:41 PM, dmitrij pochepko wrote: > > Hi, > > please review cumulative fix for 8141149 - ?[jittester] create Visitor for generating bytecode? and 8149463 - ?[jittester] rarely generates tests with compile error?. > > 8141149 is a massive update introducing new functionality - direct bytecode generation. A special ByteCodeVisitor was created and a number of common classes were changed to support ByteCodeVisitor. These changes also affects java code generation part because of changes in common part. the changeset also includes a bug fix for 8149463 which caused incorrectly generated IR. > > webrev: http://cr.openjdk.java.net/~dpochepk/8141149/webrev.01/ > CRs: https://bugs.openjdk.java.net/browse/JDK-8141149 > https://bugs.openjdk.java.net/browse/JDK-8149463 > > Thanks, > Dmitrij > > > From paul.sandoz at oracle.com Thu May 12 04:07:25 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 12 May 2016 06:07:25 +0200 Subject: RFR (S) 8153792: EA: assert(ptn->as_LocalVar()->edge_count() > 0) failed: sanity when compiling compareAndExchange In-Reply-To: <5733AF50.9080402@oracle.com> References: <5733AF50.9080402@oracle.com> Message-ID: <683D355F-0F71-41F4-B4D8-5A05AFD39E98@oracle.com> > On 12 May 2016, at 00:16, Aleksey Shipilev wrote: > > Hi, > > Please review the bugfix for the EA assert failure when compiling new > compareAndExchange intrinsics: > https://bugs.openjdk.java.net/browse/JDK-8153792 > > The bug is caused by the initial VarHandles change in the EA, and is > actually a simple overlook: Op_CompareAndExchange* were added at the > same switch case as Op_GetAndSet* (since they are similar), but the > condition within the case itself was not changed. So, EA misses an edge > from the load, and complains. > > Easy fix: > http://cr.openjdk.java.net/~shade/8153792/webrev.01/ > > Testing: local Linux x86/fastdebug and failing test; RBT (hs-comp-tier0) > +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 doug.simon at oracle.com Thu May 12 06:59:54 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 12 May 2016 08:59:54 +0200 Subject: RFR: 8156759: [JVMCI] remove JVMCIError and UnsafeUtil classes In-Reply-To: <01EE8DDD-1BBE-4D87-800E-748937E4CBA0@oracle.com> References: <180D47E0-D731-4BC2-9935-1B12BB376469@oracle.com> <196A4F27-3F03-4183-81B5-21748122185D@oracle.com> <43D7142F-FCE2-431F-B26A-4F01D6FFD284@oracle.com> <01EE8DDD-1BBE-4D87-800E-748937E4CBA0@oracle.com> Message-ID: Note that Graal has already decoupled itself from JVMCIError (http://hg.openjdk.java.net/graal/graal-core/rev/53fb0bdfd127) so we could leave JVMCIError around. However, we?re trying to do a final round of JVMCI reduction and this is a good candidate, especially since once we remove UnsafeUtil, we are left with a project (jdk.vm.ci.common) that contains exactly one class. -Doug > On 11 May 2016, at 23:21, Doug Simon wrote: > >> >> On 11 May 2016, at 23:09, Doug Simon wrote: >> >>> >>> On 11 May 2016, at 22:54, Christian Thalinger wrote: >>> >>> >>>> On May 11, 2016, at 10:19 AM, Doug Simon wrote: >>>> >>>> Please review this change which removes a couple of classes which do not need to be in JVMCI. >>>> >>>> I?ve also taken the liberty of including a change that updates the mx Java compliance level for all JVMCI projects to 9 since JDK9 API (e.g., java.lang.reflect.Module) is now used in JVMCI. This means building with mx has been broken since that API usage was introduced. I can pull this out into a separate RFE if necessary but am hoping it can piggy back on this bug. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8156759 >>> >>> The JIRA issue states: >>> >>> "Only Graal uses the context functionality of JVMCIError so it will move it Graal.? >>> >>> But there is more value to JVMCIError than just the context functionality. Having a separate JVMCI exception class can be useful when catching exceptions. >> >> Grepping through other jdk code, I see 587 instances of ?new InternalError? so I?d say it?s an appropriate choice. The stack trace is the most useful part of the errors thrown from within JVMCI and they aren?t going to change. What other uses do you have in mind? > > BTW, I have not seen any uses of 'catch (JVMCIError e) {...}?. > > -Doug From doug.simon at oracle.com Thu May 12 07:42:36 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 12 May 2016 09:42:36 +0200 Subject: RFR: 8156759: [JVMCI] remove JVMCIError and UnsafeUtil classes In-Reply-To: <196A4F27-3F03-4183-81B5-21748122185D@oracle.com> References: <180D47E0-D731-4BC2-9935-1B12BB376469@oracle.com> <196A4F27-3F03-4183-81B5-21748122185D@oracle.com> Message-ID: > On 11 May 2016, at 22:54, Christian Thalinger wrote: > > >> On May 11, 2016, at 10:19 AM, Doug Simon wrote: >> >> Please review this change which removes a couple of classes which do not need to be in JVMCI. >> >> I?ve also taken the liberty of including a change that updates the mx Java compliance level for all JVMCI projects to 9 since JDK9 API (e.g., java.lang.reflect.Module) is now used in JVMCI. This means building with mx has been broken since that API usage was introduced. I can pull this out into a separate RFE if necessary but am hoping it can piggy back on this bug. I?ve removed the above changes from the webrev. -Doug From igor.ignatyev at oracle.com Thu May 12 08:03:21 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 12 May 2016 11:03:21 +0300 Subject: RFR: 8141149 - [jittester] create Visitor for generating bytecode In-Reply-To: <151B0A30-F19C-40E4-91DE-1B8D05A7A574@oracle.com> References: <5733DF5F.5000504@oracle.com> <151B0A30-F19C-40E4-91DE-1B8D05A7A574@oracle.com> Message-ID: <3D60E9B2-E892-4C7E-BE1D-E19F2E6D6F95@oracle.com> Great job indeed! reviewed. Thanks, ? Igor > On May 12, 2016, at 6:26 AM, Igor Veresov wrote: > > Great job! Looks good to me. > > igor > >> On May 11, 2016, at 6:41 PM, dmitrij pochepko wrote: >> >> Hi, >> >> please review cumulative fix for 8141149 - ?[jittester] create Visitor for generating bytecode? and 8149463 - ?[jittester] rarely generates tests with compile error?. >> >> 8141149 is a massive update introducing new functionality - direct bytecode generation. A special ByteCodeVisitor was created and a number of common classes were changed to support ByteCodeVisitor. These changes also affects java code generation part because of changes in common part. the changeset also includes a bug fix for 8149463 which caused incorrectly generated IR. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8141149/webrev.01/ >> CRs: https://bugs.openjdk.java.net/browse/JDK-8141149 >> https://bugs.openjdk.java.net/browse/JDK-8149463 >> >> Thanks, >> Dmitrij >> >> >> > From roland.schatz at oracle.com Thu May 12 08:44:26 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Thu, 12 May 2016 10:44:26 +0200 Subject: RFR(S): 8156741: [JVMCI] remove LocationIdentity interface In-Reply-To: <11561F1E-B84B-4206-B9A8-9FA6591F7EBD@oracle.com> References: <5733407B.1000508@oracle.com> <11561F1E-B84B-4206-B9A8-9FA6591F7EBD@oracle.com> Message-ID: <5734426A.5090401@oracle.com> On 05/11/2016 06:45 PM, Igor Veresov wrote: > What?s the new location of it in Graal? com.oracle.graal.compiler.common.LocationIdentity > > igor > >> On May 11, 2016, at 7:23 AM, Roland Schatz wrote: >> >> Hi, >> >> Another pure removal change, please review: >> http://cr.openjdk.java.net/~rschatz/JDK-8156741/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8156741 >> >> Thanks, >> Roland From doug.simon at oracle.com Thu May 12 09:02:00 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 12 May 2016 11:02:00 +0200 Subject: RFR: 8156759: [JVMCI] remove JVMCIError and UnsafeUtil classes In-Reply-To: References: <180D47E0-D731-4BC2-9935-1B12BB376469@oracle.com> <196A4F27-3F03-4183-81B5-21748122185D@oracle.com> Message-ID: After some internal discussion, I?m going to withdraw this RFE. Instead, I?ll generate a ?JVMCI cleanup? RFE that among other changes: - preserves JVMCIError in jdk.vm.ci.common (but removes the context functionality) - moves InitTimer to jdk.vm.ci.common (getting rid of at least one single class project) -Doug > On 12 May 2016, at 09:42, Doug Simon wrote: > > >> On 11 May 2016, at 22:54, Christian Thalinger wrote: >> >> >>> On May 11, 2016, at 10:19 AM, Doug Simon wrote: >>> >>> Please review this change which removes a couple of classes which do not need to be in JVMCI. >>> >>> I?ve also taken the liberty of including a change that updates the mx Java compliance level for all JVMCI projects to 9 since JDK9 API (e.g., java.lang.reflect.Module) is now used in JVMCI. This means building with mx has been broken since that API usage was introduced. I can pull this out into a separate RFE if necessary but am hoping it can piggy back on this bug. > > I?ve removed the above changes from the webrev. > > -Doug From aleksey.shipilev at oracle.com Thu May 12 09:45:02 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 12 May 2016 12:45:02 +0300 Subject: RFR (S) 8153792: EA: assert(ptn->as_LocalVar()->edge_count() > 0) failed: sanity when compiling compareAndExchange In-Reply-To: <5733B1EE.8090701@oracle.com> References: <5733AF50.9080402@oracle.com> <5733B1EE.8090701@oracle.com> Message-ID: <5734509E.2010009@oracle.com> Thanks Paul and Vladimir! I'll fix the indent before the push, pushing it now. Thanks, -Aleksey On 05/12/2016 01:27 AM, Vladimir Kozlov wrote: > The fix is good but fix indent: > > + if (opcode == Op_GetAndSetP || opcode == Op_GetAndSetN || > + opcode == Op_CompareAndExchangeN || opcode == > Op_CompareAndExchangeP) { > > Thanks, > Vladimir > > On 5/11/16 3:16 PM, Aleksey Shipilev wrote: >> Hi, >> >> Please review the bugfix for the EA assert failure when compiling new >> compareAndExchange intrinsics: >> https://bugs.openjdk.java.net/browse/JDK-8153792 >> >> The bug is caused by the initial VarHandles change in the EA, and is >> actually a simple overlook: Op_CompareAndExchange* were added at the >> same switch case as Op_GetAndSet* (since they are similar), but the >> condition within the case itself was not changed. So, EA misses an edge >> from the load, and complains. >> >> Easy fix: >> http://cr.openjdk.java.net/~shade/8153792/webrev.01/ >> >> Testing: local Linux x86/fastdebug and failing test; RBT (hs-comp-tier0) >> >> 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 roland.schatz at oracle.com Thu May 12 11:44:12 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Thu, 12 May 2016 13:44:12 +0200 Subject: RFR: 8156768: [JVMCI] remove support for patching Symbol pointers Message-ID: <57346C8C.20904@oracle.com> Hi, Please review this change: http://cr.openjdk.java.net/~rschatz/JDK-8156768/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8156768 This is a followup on https://bugs.openjdk.java.net/browse/JDK-8155735, removing the stuff that's now unused. Thanks, Roland From roland.schatz at oracle.com Thu May 12 13:24:06 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Thu, 12 May 2016 15:24:06 +0200 Subject: RFR: 8156552: [JVMCI] remove final and stable field handling from ConstantReflectionProvider In-Reply-To: <573352A6.3020104@oracle.com> References: <57330769.7010703@oracle.com> <573352A6.3020104@oracle.com> Message-ID: <573483F6.5030404@oracle.com> Thanks for the reviews. Turns out I have missed a bit of code that should also be removed. I have uploaded an updated webrev: http://cr.openjdk.java.net/~rschatz/JDK-8156552/webrev.01/ Compared to the previous webrev this also removes the special handling of implicit stable fields in HotSpotResolvedJavaFieldImpl.isStable, making its behavior consistent with the other flag query methods. Please review again. Sorry for the iteration overhead ;) - Roland On 05/11/2016 05:41 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 5/11/16 3:20 AM, Roland Schatz wrote: >> Hi, >> >> Please review: >> http://cr.openjdk.java.net/~rschatz/JDK-8156552/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8156552 >> >> This is pure removal of a few methods from the >> ConstantReflectionProvider interface, their implementation, and their >> tests. >> All jvmci jtreg tests pass. >> >> Thanks, >> Roland From edward.nevill at gmail.com Thu May 12 14:30:13 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 12 May 2016 15:30:13 +0100 Subject: [aarch64-port-dev ] RFR: 8156839 : aarch64: indexOf does not support CompactStrings In-Reply-To: <57348A95.7080707@redhat.com> References: <1463060614.24642.8.camel@mint> <57348A95.7080707@redhat.com> Message-ID: <1463063413.24642.22.camel@mint> Added hotspot-compiler-dev On Thu, 2016-05-12 at 14:52 +0100, Andrew Haley wrote: > Hi, > > On 05/12/2016 02:43 PM, Edward Nevill wrote: > > Please review the following webrev which adds support for > > CompactStrings to the indexOf intrinsic. > > > > http://cr.openjdk.java.net/~enevill/8156839/webrev.01 > > Looks reasonable. > > > This adds support for the UU and LL encodings. Do we also need > > support for LU and UL? > > I'm not sure. What happens if you try to compare a latin1 and a UTF16 > string? Do we get compilation failures, or just a slow compare? AIUI you get a slow compare. I did the following test. In aarch64.ad I added UL and LU cases to the patterns without adding the corresponding support to the indexof routine in macroAssembler. Thus, if if matches these patterns it will get a guarantee failure. And indeed I get fatal errors from jtreg # Internal Error (macroAssembler_aarch64.cpp:4157), pid=11424,tid=13130 # guarantee(ae == StrIntrinsicNode::LL || ae == StrIntrinsicNode::UU) failed: unhandled argument encoding There are not many of these. Only 1 in the whole of langtools. And it goes away if I remove the predicates allowing UL and LU. > > > Also, I notice that StrComp doesn't seem to have support for > > CompactString either. Shall I do that also? > > > > Tested with jtreg hotspot and langtools. > > OK. But note well: hotspot/hs is frozen for the JDK9 release. OK. I will do StrComp as a separate webrev. Is hs-comp frozen as well? I also notice there is StrIndexOfChar which isn't implemented on aarch64. This should be simple because the code is already there as a special case of StrIndexOf. All the best, Ed. From aph at redhat.com Thu May 12 14:42:26 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 May 2016 15:42:26 +0100 Subject: [aarch64-port-dev ] RFR: 8156839 : aarch64: indexOf does not support CompactStrings In-Reply-To: <1463063413.24642.22.camel@mint> References: <1463060614.24642.8.camel@mint> <57348A95.7080707@redhat.com> <1463063413.24642.22.camel@mint> Message-ID: <57349652.8040404@redhat.com> On 05/12/2016 03:30 PM, Edward Nevill wrote: > OK. I will do StrComp as a separate webrev. > > Is hs-comp frozen as well? hs-comp is dead. > I also notice there is StrIndexOfChar which isn't implemented on aarch64. > > This should be simple because the code is already there as a special case of StrIndexOf. Andrew. From dmitrij.pochepko at oracle.com Thu May 12 15:00:46 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 12 May 2016 18:00:46 +0300 Subject: RFR: 8152342 - JVMCI test task: Unit tests for MethodHandleAccessProvider In-Reply-To: <57338652.4020803@oracle.com> References: <572CADC8.4090004@oracle.com> <23981544-7F7C-4CD0-B4CF-FAD8E42FA52F@oracle.com> <57321B9D.8000204@oracle.com> <57338652.4020803@oracle.com> Message-ID: <57349A9E.3090609@oracle.com> Thank you! > Good. Missing @bug > > Thanks, > Vladimir > > On 5/10/16 10:34 AM, Dmitrij Pochepko wrote: >> Hi, >> >> please check v02: >> http://cr.openjdk.java.net/~dpochepk/8152342/webrev.02/ >> >> I've applied eclipse formatter and fixed checkstyle warnings. >> >> Thanks, >> Dmitrij >> >>>> On May 6, 2016, at 4:44 AM, Dmitrij Pochepko >>>> wrote: >>>> >>>> Hi, >>>> >>>> please review patch for 8152342 - JVMCI test task: Unit tests for >>>> MethodHandleAccessProvider >>>> >>>> A new tests were added for MethodHandleAccessProvider implementation. >>>> This patch contains tests for all MethodHandleAccessProvider methods >>>> (mostly a positive and few negative tests per method). A testng >>>> framework is used. MethodHandleAccessProviderData is used as testng >>>> data provider for MethodHandleAccessProviderTest. >>>> >>>> webrev: http://cr.openjdk.java.net/~dpochepk/8152342/webrev.01 >>> Same formatting question. >>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8152342 >>>> >>>> I've tested it on linux_x64 >>>> >>>> Thanks, >>>> Dmitrij >>>> >>>> >> From volker.simonis at gmail.com Thu May 12 15:15:03 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 May 2016 17:15:03 +0200 Subject: [aarch64-port-dev ] RFR: 8156839 : aarch64: indexOf does not support CompactStrings In-Reply-To: <57349652.8040404@redhat.com> References: <1463060614.24642.8.camel@mint> <57348A95.7080707@redhat.com> <1463063413.24642.22.camel@mint> <57349652.8040404@redhat.com> Message-ID: On Thu, May 12, 2016 at 4:42 PM, Andrew Haley wrote: > On 05/12/2016 03:30 PM, Edward Nevill wrote: >> OK. I will do StrComp as a separate webrev. >> >> Is hs-comp frozen as well? > > hs-comp is dead. What do you mean by dead? hs-rt is dead, but as far as I know, hs-comp is still active (and not frozen - the last change there was about four hours ago http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/) > >> I also notice there is StrIndexOfChar which isn't implemented on aarch64. >> >> This should be simple because the code is already there as a special case of StrIndexOf. > > Andrew. > From aph at redhat.com Thu May 12 15:15:59 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 May 2016 16:15:59 +0100 Subject: [aarch64-port-dev ] RFR: 8156839 : aarch64: indexOf does not support CompactStrings In-Reply-To: References: <1463060614.24642.8.camel@mint> <57348A95.7080707@redhat.com> <1463063413.24642.22.camel@mint> <57349652.8040404@redhat.com> Message-ID: <57349E2F.3040405@redhat.com> On 05/12/2016 04:15 PM, Volker Simonis wrote: > On Thu, May 12, 2016 at 4:42 PM, Andrew Haley wrote: >> On 05/12/2016 03:30 PM, Edward Nevill wrote: >>> OK. I will do StrComp as a separate webrev. >>> >>> Is hs-comp frozen as well? >> >> hs-comp is dead. > > What do you mean by dead? > > hs-rt is dead, but as far as I know, hs-comp is still active (and not > frozen - the last change there was about four hours ago > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/) My apologies. Andrew. From igor.veresov at oracle.com Thu May 12 15:17:37 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 12 May 2016 08:17:37 -0700 Subject: RFR(S): 8156741: [JVMCI] remove LocationIdentity interface In-Reply-To: <5734426A.5090401@oracle.com> References: <5733407B.1000508@oracle.com> <11561F1E-B84B-4206-B9A8-9FA6591F7EBD@oracle.com> <5734426A.5090401@oracle.com> Message-ID: <56B4D87D-0841-48CC-8D9B-3D5CD81E7405@oracle.com> > On May 12, 2016, at 1:44 AM, Roland Schatz wrote: > > On 05/11/2016 06:45 PM, Igor Veresov wrote: >> What?s the new location of it in Graal? > com.oracle.graal.compiler.common.LocationIdentity Thanks! igor >> >> igor >> >>> On May 11, 2016, at 7:23 AM, Roland Schatz wrote: >>> >>> Hi, >>> >>> Another pure removal change, please review: >>> http://cr.openjdk.java.net/~rschatz/JDK-8156741/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8156741 >>> >>> Thanks, >>> Roland > From dmitrij.pochepko at oracle.com Thu May 12 15:26:00 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 12 May 2016 18:26:00 +0300 Subject: RFR(S): 8139703 - compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest fails using -Xcomp In-Reply-To: <56D727D6.50700@oracle.com> References: <56D70A6B.6000906@oracle.com> <56D727D6.50700@oracle.com> Message-ID: <5734A088.1090401@oracle.com> Hi, I've changed compilation threshold according to previous discussions. please take a look at v02: http://cr.openjdk.java.net/~dpochepk/8139703/webrev.02/ Thanks, Dmitrij > As we discussed in previous reviews CompilerWhiteBoxTest.THRESHOLD may > be not enough to trigger compilation. > > Thanks, > Vladimir > > On 3/2/16 7:44 AM, Dmitrij Pochepko wrote: >> Hi, >> >> please review fix for >> https://bugs.openjdk.java.net/browse/JDK-8139703 - [TESTBUG] >> compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest fails using >> -Xcomp >> >> A test compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest >> failed in Xcomp. After investigation, a bug related to >> escape analysis was >> filed(https://bugs.openjdk.java.net/browse/JDK-8140018). >> >> So, i've switched this test to use Xmixed mode. Also, this test was >> changed to trigger method compilation by calling >> method multiple times instead of using WhiteBox. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8139703 >> webrev: http://cr.openjdk.java.net/~dpochepk/8139703/webrev.01/ >> >> Thanks, >> Dmitrij From igor.veresov at oracle.com Thu May 12 15:36:24 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 12 May 2016 08:36:24 -0700 Subject: RFR: 8156768: [JVMCI] remove support for patching Symbol pointers In-Reply-To: <57346C8C.20904@oracle.com> References: <57346C8C.20904@oracle.com> Message-ID: <5D8E2D0A-F232-4101-A233-DE4A0C6AF52B@oracle.com> Looks good. igor > On May 12, 2016, at 4:44 AM, Roland Schatz wrote: > > Hi, > > Please review this change: > http://cr.openjdk.java.net/~rschatz/JDK-8156768/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8156768 > > This is a followup on https://bugs.openjdk.java.net/browse/JDK-8155735, removing the stuff that's now unused. > > Thanks, > Roland From vladimir.kozlov at oracle.com Thu May 12 16:02:58 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 May 2016 09:02:58 -0700 Subject: RFR: 8156552: [JVMCI] remove final and stable field handling from ConstantReflectionProvider In-Reply-To: <573483F6.5030404@oracle.com> References: <57330769.7010703@oracle.com> <573352A6.3020104@oracle.com> <573483F6.5030404@oracle.com> Message-ID: Still good. Thanks, Vladimir On 5/12/16 6:24 AM, Roland Schatz wrote: > Thanks for the reviews. > > Turns out I have missed a bit of code that should also be removed. > > I have uploaded an updated webrev: > http://cr.openjdk.java.net/~rschatz/JDK-8156552/webrev.01/ > > Compared to the previous webrev this also removes the special handling of implicit stable fields in > HotSpotResolvedJavaFieldImpl.isStable, making its behavior consistent with the other flag query methods. > > Please review again. > Sorry for the iteration overhead ;) > > - Roland > > On 05/11/2016 05:41 PM, Vladimir Kozlov wrote: >> Looks good. >> >> Thanks, >> Vladimir >> >> On 5/11/16 3:20 AM, Roland Schatz wrote: >>> Hi, >>> >>> Please review: >>> http://cr.openjdk.java.net/~rschatz/JDK-8156552/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8156552 >>> >>> This is pure removal of a few methods from the >>> ConstantReflectionProvider interface, their implementation, and their >>> tests. >>> All jvmci jtreg tests pass. >>> >>> Thanks, >>> Roland > From vladimir.kozlov at oracle.com Thu May 12 16:08:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 May 2016 09:08:05 -0700 Subject: RFR(S): 8139703 - compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest fails using -Xcomp In-Reply-To: <5734A088.1090401@oracle.com> References: <56D70A6B.6000906@oracle.com> <56D727D6.50700@oracle.com> <5734A088.1090401@oracle.com> Message-ID: Good. Thanks, Vladimir On 5/12/16 8:26 AM, Dmitrij Pochepko wrote: > Hi, > > I've changed compilation threshold according to previous discussions. > > please take a look at v02: http://cr.openjdk.java.net/~dpochepk/8139703/webrev.02/ > > Thanks, > Dmitrij > >> As we discussed in previous reviews CompilerWhiteBoxTest.THRESHOLD may be not enough to trigger compilation. >> >> Thanks, >> Vladimir >> >> On 3/2/16 7:44 AM, Dmitrij Pochepko wrote: >>> Hi, >>> >>> please review fix for https://bugs.openjdk.java.net/browse/JDK-8139703 - [TESTBUG] >>> compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest fails using -Xcomp >>> >>> A test compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest failed in Xcomp. After investigation, a bug related to >>> escape analysis was filed(https://bugs.openjdk.java.net/browse/JDK-8140018). >>> >>> So, i've switched this test to use Xmixed mode. Also, this test was changed to trigger method compilation by calling >>> method multiple times instead of using WhiteBox. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8139703 >>> webrev: http://cr.openjdk.java.net/~dpochepk/8139703/webrev.01/ >>> >>> Thanks, >>> Dmitrij > From tom.rodriguez at oracle.com Thu May 12 16:29:01 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 12 May 2016 09:29:01 -0700 Subject: RFR 8155047: [JVMCI] findLeafConcreteSubtype should handle arrays of leaf concrete subtype In-Reply-To: <81FC93A7-03F5-4A10-858A-9D227540D419@oracle.com> References: <3B2FE4AA-668D-4929-9FF4-EC65A11700A8@oracle.com> <6D4CBD60-A855-44A6-9C27-04D2012D050D@oracle.com> <81FC93A7-03F5-4A10-858A-9D227540D419@oracle.com> Message-ID: So can I considered this reviewed? tom > On Apr 28, 2016, at 4:55 PM, Tom Rodriguez wrote: > > >> On Apr 28, 2016, at 12:23 PM, Christian Thalinger > wrote: >> >> >>> On Apr 28, 2016, at 6:13 AM, Tom Rodriguez > wrote: >>> >>> http://cr.openjdk.java.net/~never/8155047/webrev >> >> public LeafType(ResolvedJavaType context) { >> + assert !context.isLeaf() : "assumption isn't required for leaf types"; >> This assert is confusing. The assumption is that a given type has no subtypes, which is also true for leaf types. Does this assert make sure it?s not used in the wrong places? > > LeafType is an assumption that a dynamic type that might someday have subclasses doesn?t currently have any. isLeaf() is a static guarantee that a type will never have subclasses, so we are asserting that we never emit a dynamic dependence for something that is statically true. I?m open to new wording. > > tom > >> >>> >>> findLeafConcreteSubtype should use the same machinery for the elemental type when identifying leaf array types. >>> >>> tom >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Thu May 12 16:45:53 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 12 May 2016 19:45:53 +0300 Subject: RFR(S): 8139703 - compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest fails using -Xcomp In-Reply-To: References: <56D70A6B.6000906@oracle.com> <56D727D6.50700@oracle.com> <5734A088.1090401@oracle.com> Message-ID: <5734B341.9010300@oracle.com> Thank you! > Good. > > Thanks, > Vladimir > > On 5/12/16 8:26 AM, Dmitrij Pochepko wrote: >> Hi, >> >> I've changed compilation threshold according to previous discussions. >> >> please take a look at v02: >> http://cr.openjdk.java.net/~dpochepk/8139703/webrev.02/ >> >> Thanks, >> Dmitrij >> >>> As we discussed in previous reviews CompilerWhiteBoxTest.THRESHOLD >>> may be not enough to trigger compilation. >>> >>> Thanks, >>> Vladimir >>> >>> On 3/2/16 7:44 AM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> please review fix for >>>> https://bugs.openjdk.java.net/browse/JDK-8139703 - [TESTBUG] >>>> compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest fails >>>> using -Xcomp >>>> >>>> A test compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest >>>> failed in Xcomp. After investigation, a bug related to >>>> escape analysis was >>>> filed(https://bugs.openjdk.java.net/browse/JDK-8140018). >>>> >>>> So, i've switched this test to use Xmixed mode. Also, this test was >>>> changed to trigger method compilation by calling >>>> method multiple times instead of using WhiteBox. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8139703 >>>> webrev: http://cr.openjdk.java.net/~dpochepk/8139703/webrev.01/ >>>> >>>> Thanks, >>>> Dmitrij >> From christian.thalinger at oracle.com Thu May 12 17:35:47 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 May 2016 07:35:47 -1000 Subject: RFR: 8156759: [JVMCI] remove JVMCIError and UnsafeUtil classes In-Reply-To: References: <180D47E0-D731-4BC2-9935-1B12BB376469@oracle.com> <196A4F27-3F03-4183-81B5-21748122185D@oracle.com> Message-ID: <98B919E1-AF5F-4A68-8917-FE6669B25822@oracle.com> > On May 11, 2016, at 11:02 PM, Doug Simon wrote: > > After some internal discussion, I?m going to withdraw this RFE. Instead, I?ll generate a ?JVMCI cleanup? RFE that among other changes: You didn?t give me time to respond! ;-) > > - preserves JVMCIError in jdk.vm.ci.common (but removes the context functionality) > - moves InitTimer to jdk.vm.ci.common (getting rid of at least one single class project) Sounds good. > > -Doug > >> On 12 May 2016, at 09:42, Doug Simon wrote: >> >> >>> On 11 May 2016, at 22:54, Christian Thalinger wrote: >>> >>> >>>> On May 11, 2016, at 10:19 AM, Doug Simon wrote: >>>> >>>> Please review this change which removes a couple of classes which do not need to be in JVMCI. >>>> >>>> I?ve also taken the liberty of including a change that updates the mx Java compliance level for all JVMCI projects to 9 since JDK9 API (e.g., java.lang.reflect.Module) is now used in JVMCI. This means building with mx has been broken since that API usage was introduced. I can pull this out into a separate RFE if necessary but am hoping it can piggy back on this bug. >> >> I?ve removed the above changes from the webrev. >> >> -Doug > From doug.simon at oracle.com Thu May 12 17:41:00 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 12 May 2016 19:41:00 +0200 Subject: RFR: 8156759: [JVMCI] remove JVMCIError and UnsafeUtil classes In-Reply-To: <98B919E1-AF5F-4A68-8917-FE6669B25822@oracle.com> References: <180D47E0-D731-4BC2-9935-1B12BB376469@oracle.com> <196A4F27-3F03-4183-81B5-21748122185D@oracle.com> <98B919E1-AF5F-4A68-8917-FE6669B25822@oracle.com> Message-ID: > On 12 May 2016, at 19:35, Christian Thalinger wrote: > > >> On May 11, 2016, at 11:02 PM, Doug Simon wrote: >> >> After some internal discussion, I?m going to withdraw this RFE. Instead, I?ll generate a ?JVMCI cleanup? RFE that among other changes: > > You didn?t give me time to respond! ;-) Sorry. I didn?t want you to waste your time on this issue any longer now that I?m generating a much larger webrev for you to review ;-) -Doug >>> On 12 May 2016, at 09:42, Doug Simon wrote: >>> >>> >>>> On 11 May 2016, at 22:54, Christian Thalinger wrote: >>>> >>>> >>>>> On May 11, 2016, at 10:19 AM, Doug Simon wrote: >>>>> >>>>> Please review this change which removes a couple of classes which do not need to be in JVMCI. >>>>> >>>>> I?ve also taken the liberty of including a change that updates the mx Java compliance level for all JVMCI projects to 9 since JDK9 API (e.g., java.lang.reflect.Module) is now used in JVMCI. This means building with mx has been broken since that API usage was introduced. I can pull this out into a separate RFE if necessary but am hoping it can piggy back on this bug. >>> >>> I?ve removed the above changes from the webrev. >>> >>> -Doug >> > From christian.thalinger at oracle.com Thu May 12 18:34:25 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 May 2016 08:34:25 -1000 Subject: RFR 8155047: [JVMCI] findLeafConcreteSubtype should handle arrays of leaf concrete subtype In-Reply-To: References: <3B2FE4AA-668D-4929-9FF4-EC65A11700A8@oracle.com> <6D4CBD60-A855-44A6-9C27-04D2012D050D@oracle.com> <81FC93A7-03F5-4A10-858A-9D227540D419@oracle.com> Message-ID: > On May 12, 2016, at 6:29 AM, Tom Rodriguez wrote: > > So can I considered this reviewed? Sorry, yes. > > tom > >> On Apr 28, 2016, at 4:55 PM, Tom Rodriguez > wrote: >> >> >>> On Apr 28, 2016, at 12:23 PM, Christian Thalinger > wrote: >>> >>> >>>> On Apr 28, 2016, at 6:13 AM, Tom Rodriguez > wrote: >>>> >>>> http://cr.openjdk.java.net/~never/8155047/webrev >>> >>> public LeafType(ResolvedJavaType context) { >>> + assert !context.isLeaf() : "assumption isn't required for leaf types"; >>> This assert is confusing. The assumption is that a given type has no subtypes, which is also true for leaf types. Does this assert make sure it?s not used in the wrong places? >> >> LeafType is an assumption that a dynamic type that might someday have subclasses doesn?t currently have any. isLeaf() is a static guarantee that a type will never have subclasses, so we are asserting that we never emit a dynamic dependence for something that is statically true. I?m open to new wording. >> >> tom >> >>> >>>> >>>> findLeafConcreteSubtype should use the same machinery for the elemental type when identifying leaf array types. >>>> >>>> tom >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Thu May 12 18:39:00 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 May 2016 08:39:00 -1000 Subject: RFR(S): 8139703 - compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest fails using -Xcomp In-Reply-To: <5734B341.9010300@oracle.com> References: <56D70A6B.6000906@oracle.com> <56D727D6.50700@oracle.com> <5734A088.1090401@oracle.com> <5734B341.9010300@oracle.com> Message-ID: <5E5BA4C1-C976-49D3-9A99-04FE096E6B81@oracle.com> Kind of off-topic but could we move all compilerToVM tests into an mx controlled directory, jdk.vm.ci.hotspot.test? > On May 12, 2016, at 6:45 AM, dmitrij pochepko wrote: > > Thank you! >> Good. >> >> Thanks, >> Vladimir >> >> On 5/12/16 8:26 AM, Dmitrij Pochepko wrote: >>> Hi, >>> >>> I've changed compilation threshold according to previous discussions. >>> >>> please take a look at v02: http://cr.openjdk.java.net/~dpochepk/8139703/webrev.02/ >>> >>> Thanks, >>> Dmitrij >>> >>>> As we discussed in previous reviews CompilerWhiteBoxTest.THRESHOLD may be not enough to trigger compilation. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 3/2/16 7:44 AM, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> >>>>> please review fix for https://bugs.openjdk.java.net/browse/JDK-8139703 - [TESTBUG] >>>>> compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest fails using -Xcomp >>>>> >>>>> A test compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest failed in Xcomp. After investigation, a bug related to >>>>> escape analysis was filed(https://bugs.openjdk.java.net/browse/JDK-8140018). >>>>> >>>>> So, i've switched this test to use Xmixed mode. Also, this test was changed to trigger method compilation by calling >>>>> method multiple times instead of using WhiteBox. >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8139703 >>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8139703/webrev.01/ >>>>> >>>>> Thanks, >>>>> Dmitrij >>> > From tom.rodriguez at oracle.com Thu May 12 20:50:48 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 12 May 2016 13:50:48 -0700 Subject: RFR 8155047: [JVMCI] findLeafConcreteSubtype should handle arrays of leaf concrete subtype In-Reply-To: References: <3B2FE4AA-668D-4929-9FF4-EC65A11700A8@oracle.com> <6D4CBD60-A855-44A6-9C27-04D2012D050D@oracle.com> <81FC93A7-03F5-4A10-858A-9D227540D419@oracle.com> Message-ID: <23E653A8-4DEC-4E5E-84F2-C92901790439@oracle.com> > On May 12, 2016, at 11:34 AM, Christian Thalinger wrote: > > >> On May 12, 2016, at 6:29 AM, Tom Rodriguez > wrote: >> >> So can I considered this reviewed? > > Sorry, yes. I forgot about it too until Doug pinged me. Thanks! tom > >> >> tom >> >>> On Apr 28, 2016, at 4:55 PM, Tom Rodriguez > wrote: >>> >>> >>>> On Apr 28, 2016, at 12:23 PM, Christian Thalinger > wrote: >>>> >>>> >>>>> On Apr 28, 2016, at 6:13 AM, Tom Rodriguez > wrote: >>>>> >>>>> http://cr.openjdk.java.net/~never/8155047/webrev >>>> >>>> public LeafType(ResolvedJavaType context) { >>>> + assert !context.isLeaf() : "assumption isn't required for leaf types"; >>>> This assert is confusing. The assumption is that a given type has no subtypes, which is also true for leaf types. Does this assert make sure it?s not used in the wrong places? >>> >>> LeafType is an assumption that a dynamic type that might someday have subclasses doesn?t currently have any. isLeaf() is a static guarantee that a type will never have subclasses, so we are asserting that we never emit a dynamic dependence for something that is statically true. I?m open to new wording. >>> >>> tom >>> >>>> >>>>> >>>>> findLeafConcreteSubtype should use the same machinery for the elemental type when identifying leaf array types. >>>>> >>>>> tom >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Fri May 13 11:40:58 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 13 May 2016 13:40:58 +0200 Subject: RFR: 8156835: [JVMCI] clean up and minimize JVMCI Message-ID: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> Please review this RFE that makes minor changes to clean up and minimize JVMCI. All jtreg tests pass as do all Graal tests. https://bugs.openjdk.java.net/browse/JDK-8156835 http://cr.openjdk.java.net/~dnsimon/8156835 -Doug From aleksey.shipilev at oracle.com Fri May 13 12:24:02 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 13 May 2016 15:24:02 +0300 Subject: RFR(M): 8141635: Implement new Unsafe intrinsics on POWER In-Reply-To: References: <075bd830305c426996ef758e0a37ed87@DEWDFE13DE14.global.corp.sap> <5728FBA5.2010808@oracle.com> Message-ID: <5735C762.20805@oracle.com> Hi, On 05/04/2016 08:57 PM, Volker Simonis wrote: > Aleksey, could you please run the change through JPRT and sponsor it > once your happy with it? I ran this version through our testing, and it seems clean: http://cr.openjdk.java.net/~shade/8141635/webrev.01/ My changes are mostly minimizing the impact on shared code parts. Not sure if we can push this to hs-comp, having the pending FC. Let us figure this out separately. I'll push as soon as it's clear what to do. 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 edward.nevill at gmail.com Fri May 13 13:02:05 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 13 May 2016 14:02:05 +0100 Subject: RFR: 8156943: aarch64: string compare does not support CompactStrings Message-ID: <1463144525.16443.8.camel@mint> Hi, Please review the following webrev which adds CompactStrings support to the StrComp intrinsic. http://cr.openjdk.java.net/~enevill/8156943/webrev As with the indexOf intringsic only support for the LL/UU encodings is provided. Tested with jtreg hotspot/langtools. All the best, Ed. From roland.schatz at oracle.com Fri May 13 15:32:44 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Fri, 13 May 2016 17:32:44 +0200 Subject: RFR: 8156942: [JVMCI] replace LIRKind with abstract base class Message-ID: <5735F39C.3050103@oracle.com> Hi, Please review this cleanup change: http://cr.openjdk.java.net/~rschatz/JDK-8156942/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8156942 Passes all jvmci jtreg tests and all graal unit tests. Thanks, Roland From doug.simon at oracle.com Fri May 13 15:53:11 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 13 May 2016 17:53:11 +0200 Subject: RFR: 8156759: [JVMCI] remove JVMCIError and UnsafeUtil classes In-Reply-To: References: <180D47E0-D731-4BC2-9935-1B12BB376469@oracle.com> <196A4F27-3F03-4183-81B5-21748122185D@oracle.com> Message-ID: Just for clarity, 8156759 has been closed as ?Won?t Fix? since https://bugs.openjdk.java.net/browse/JDK-8156835 replaces it. > On 12 May 2016, at 11:02, Doug Simon wrote: > > After some internal discussion, I?m going to withdraw this RFE. Instead, I?ll generate a ?JVMCI cleanup? RFE that among other changes: > > - preserves JVMCIError in jdk.vm.ci.common (but removes the context functionality) > - moves InitTimer to jdk.vm.ci.common (getting rid of at least one single class project) > > -Doug > >> On 12 May 2016, at 09:42, Doug Simon wrote: >> >> >>> On 11 May 2016, at 22:54, Christian Thalinger wrote: >>> >>> >>>> On May 11, 2016, at 10:19 AM, Doug Simon wrote: >>>> >>>> Please review this change which removes a couple of classes which do not need to be in JVMCI. >>>> >>>> I?ve also taken the liberty of including a change that updates the mx Java compliance level for all JVMCI projects to 9 since JDK9 API (e.g., java.lang.reflect.Module) is now used in JVMCI. This means building with mx has been broken since that API usage was introduced. I can pull this out into a separate RFE if necessary but am hoping it can piggy back on this bug. >> >> I?ve removed the above changes from the webrev. >> >> -Doug > From volker.simonis at gmail.com Fri May 13 16:01:21 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 May 2016 18:01:21 +0200 Subject: RFR(M): 8141635: Implement new Unsafe intrinsics on POWER In-Reply-To: <5735C762.20805@oracle.com> References: <075bd830305c426996ef758e0a37ed87@DEWDFE13DE14.global.corp.sap> <5728FBA5.2010808@oracle.com> <5735C762.20805@oracle.com> Message-ID: Hi Aleksey, thanks for testing! I think your changes are fine. Following the other discussion on the mailing list, I think hs-comp should be open for checkins and looking at the repo I see that there have been quite some pushes in the days. But it is of course better to double-check this. Thanks for sponsoring, Volker On Fri, May 13, 2016 at 2:24 PM, Aleksey Shipilev wrote: > Hi, > > On 05/04/2016 08:57 PM, Volker Simonis wrote: >> Aleksey, could you please run the change through JPRT and sponsor it >> once your happy with it? > > I ran this version through our testing, and it seems clean: > http://cr.openjdk.java.net/~shade/8141635/webrev.01/ > > My changes are mostly minimizing the impact on shared code parts. Not > sure if we can push this to hs-comp, having the pending FC. Let us > figure this out separately. I'll push as soon as it's clear what to do. > > Thanks, > -Aleksey > > From igor.veresov at oracle.com Fri May 13 16:21:37 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 13 May 2016 09:21:37 -0700 Subject: RFR: 8156835: [JVMCI] clean up and minimize JVMCI In-Reply-To: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> References: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> Message-ID: Looks ok igor > On May 13, 2016, at 4:40 AM, Doug Simon wrote: > > Please review this RFE that makes minor changes to clean up and minimize JVMCI. > > All jtreg tests pass as do all Graal tests. > > https://bugs.openjdk.java.net/browse/JDK-8156835 > http://cr.openjdk.java.net/~dnsimon/8156835 > > -Doug From igor.veresov at oracle.com Fri May 13 16:22:30 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 13 May 2016 09:22:30 -0700 Subject: RFR: 8156942: [JVMCI] replace LIRKind with abstract base class In-Reply-To: <5735F39C.3050103@oracle.com> References: <5735F39C.3050103@oracle.com> Message-ID: <5F033509-F355-4BFB-BA00-D6E07297D406@oracle.com> Looks ok igor > On May 13, 2016, at 8:32 AM, Roland Schatz wrote: > > Hi, > > Please review this cleanup change: > http://cr.openjdk.java.net/~rschatz/JDK-8156942/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8156942 > > Passes all jvmci jtreg tests and all graal unit tests. > > Thanks, > Roland From vladimir.kozlov at oracle.com Fri May 13 18:02:11 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 May 2016 11:02:11 -0700 Subject: RFR: 8156835: [JVMCI] clean up and minimize JVMCI In-Reply-To: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> References: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> Message-ID: <8e433374-234f-da85-2f62-7722dddb05f7@oracle.com> Looks good. thanks, Vladimir On 5/13/16 4:40 AM, Doug Simon wrote: > Please review this RFE that makes minor changes to clean up and minimize JVMCI. > > All jtreg tests pass as do all Graal tests. > > https://bugs.openjdk.java.net/browse/JDK-8156835 > http://cr.openjdk.java.net/~dnsimon/8156835 > > -Doug > From vladimir.kozlov at oracle.com Fri May 13 18:30:54 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 May 2016 11:30:54 -0700 Subject: RFR(M): 8141635: Implement new Unsafe intrinsics on POWER In-Reply-To: References: <075bd830305c426996ef758e0a37ed87@DEWDFE13DE14.global.corp.sap> <5728FBA5.2010808@oracle.com> <5735C762.20805@oracle.com> Message-ID: <676fcf92-485f-0de5-d0e7-b16e820de517@oracle.com> Looks good. It changed shared code so FC rules apply. But changes are under support_IRIW_for_not_multiple_copy_atomic_cpu flag which is true only for PPC. We can say it is platform specific. Should be pushed through JPRT since there are shared changes. Thanks, Vladimir On 5/13/16 9:01 AM, Volker Simonis wrote: > Hi Aleksey, > > thanks for testing! I think your changes are fine. > > Following the other discussion on the mailing list, I think hs-comp > should be open for checkins and looking at the repo I see that there > have been quite some pushes in the days. But it is of course better to > double-check this. > > Thanks for sponsoring, > Volker > > > On Fri, May 13, 2016 at 2:24 PM, Aleksey Shipilev > wrote: >> Hi, >> >> On 05/04/2016 08:57 PM, Volker Simonis wrote: >>> Aleksey, could you please run the change through JPRT and sponsor it >>> once your happy with it? >> >> I ran this version through our testing, and it seems clean: >> http://cr.openjdk.java.net/~shade/8141635/webrev.01/ >> >> My changes are mostly minimizing the impact on shared code parts. Not >> sure if we can push this to hs-comp, having the pending FC. Let us >> figure this out separately. I'll push as soon as it's clear what to do. >> >> Thanks, >> -Aleksey >> >> From christian.thalinger at oracle.com Fri May 13 19:03:05 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 13 May 2016 09:03:05 -1000 Subject: RFR: 8156835: [JVMCI] clean up and minimize JVMCI In-Reply-To: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> References: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> Message-ID: <350A3F9E-E3ED-42CE-BAB5-10A0CF389AA9@oracle.com> > On May 13, 2016, at 1:40 AM, Doug Simon wrote: > > Please review this RFE that makes minor changes to clean up and minimize JVMCI. > > All jtreg tests pass as do all Graal tests. > > https://bugs.openjdk.java.net/browse/JDK-8156835 > http://cr.openjdk.java.net/~dnsimon/8156835 src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodeFrame.java + * Specifies if this objects represents a frame state in the middle of executing a call. If ?this objects? src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CompiledCode.java + * into a managed code heap. Since the details of such are code are specific to each runtime, this ?are code are? > > -Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Fri May 13 19:53:30 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 13 May 2016 21:53:30 +0200 Subject: RFR: 8156835: [JVMCI] clean up and minimize JVMCI In-Reply-To: <350A3F9E-E3ED-42CE-BAB5-10A0CF389AA9@oracle.com> References: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> <350A3F9E-E3ED-42CE-BAB5-10A0CF389AA9@oracle.com> Message-ID: <8CA340A8-FA9C-426E-B74B-C19A1B8655EA@oracle.com> I?ve fixed the typos and updated the webrev. Thanks for the review! -Doug > On 13 May 2016, at 21:03, Christian Thalinger wrote: > > >> On May 13, 2016, at 1:40 AM, Doug Simon wrote: >> >> Please review this RFE that makes minor changes to clean up and minimize JVMCI. >> >> All jtreg tests pass as do all Graal tests. >> >> https://bugs.openjdk.java.net/browse/JDK-8156835 >> http://cr.openjdk.java.net/~dnsimon/8156835 > src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodeFrame.java > > + * Specifies if this objects represents a frame state in the middle of executing a call. If > ?this objects? > src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CompiledCode.java > > + * into a managed code heap. Since the details of such are code are specific to each runtime, this > ?are code are? > >> >> -Doug > From doug.simon at oracle.com Fri May 13 19:54:00 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 13 May 2016 21:54:00 +0200 Subject: RFR: 8156835: [JVMCI] clean up and minimize JVMCI In-Reply-To: <8e433374-234f-da85-2f62-7722dddb05f7@oracle.com> References: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> <8e433374-234f-da85-2f62-7722dddb05f7@oracle.com> Message-ID: Great - thanks for reviewing! > On 13 May 2016, at 20:02, Vladimir Kozlov wrote: > > Looks good. > > thanks, > Vladimir > > On 5/13/16 4:40 AM, Doug Simon wrote: >> Please review this RFE that makes minor changes to clean up and minimize JVMCI. >> >> All jtreg tests pass as do all Graal tests. >> >> https://bugs.openjdk.java.net/browse/JDK-8156835 >> http://cr.openjdk.java.net/~dnsimon/8156835 >> >> -Doug >> From doug.simon at oracle.com Fri May 13 19:54:25 2016 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 13 May 2016 21:54:25 +0200 Subject: RFR: 8156835: [JVMCI] clean up and minimize JVMCI In-Reply-To: References: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> Message-ID: <0E2B9ACF-4BB4-4A6F-A941-37564ACADDB0@oracle.com> > On 13 May 2016, at 18:21, Igor Veresov wrote: > > Looks ok Thanks for the review. -Doug >> On May 13, 2016, at 4:40 AM, Doug Simon wrote: >> >> Please review this RFE that makes minor changes to clean up and minimize JVMCI. >> >> All jtreg tests pass as do all Graal tests. >> >> https://bugs.openjdk.java.net/browse/JDK-8156835 >> http://cr.openjdk.java.net/~dnsimon/8156835 >> >> -Doug > From aph at redhat.com Mon May 16 12:53:40 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 May 2016 13:53:40 +0100 Subject: [aarch64-port-dev ] RFR: 8156839 : aarch64: indexOf does not support CompactStrings In-Reply-To: <1463063413.24642.22.camel@mint> References: <1463060614.24642.8.camel@mint> <57348A95.7080707@redhat.com> <1463063413.24642.22.camel@mint> Message-ID: <5739C2D4.5000401@redhat.com> On 05/12/2016 03:30 PM, Edward Nevill wrote: > AIUI you get a slow compare. I did the following test. In aarch64.ad I added UL and LU cases to the patterns without adding the corresponding support to the indexof routine in macroAssembler. Thus, if if matches these patterns it will get a guarantee failure. And indeed I get fatal errors from jtreg > > # Internal Error (macroAssembler_aarch64.cpp:4157), pid=11424,tid=13130 > # guarantee(ae == StrIntrinsicNode::LL || ae == StrIntrinsicNode::UU) failed: unhandled argument encoding > > There are not many of these. Only 1 in the whole of langtools. And it goes away if I remove the predicates allowing UL and LU. With your patches I get jtreg fails: STDOUT: Checking arrayEqualsB... Done. Checking arrayEqualsC... Done. Checking indexOfConstU... Done. Checking indexOfConstLargeU... Done. Checking indexOfConstEmptyU... o236 StrIndexOf === o235 o7 o253 o254 [[o216 86 ]] --N: o236 StrIndexOf === o235 o7 o253 o254 [[o216 86 ]] --N: o253 Binary === _ o154 o160 [[o236 ]] _Binary_iRegP_R1_iRegI_R2 0 _Binary_iRegP_R1_iRegI_R2 _Binary_iRegP_R3_iRegI_R4 0 _Binary_iRegP_R3_iRegI_R4 _Binary_iRegP_R1_iRegI_R4 0 _Binary_iRegP_R1_iRegI_R4 ... # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/matcher.cpp:1569 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/aph/hs/hotspot/src/share/vm/opto/matcher.cpp:1569), pid=13951, tid=14040 # assert(false) failed: bad AD file # # JRE version: OpenJDK Runtime Environment (9.0) (slowdebug build 9-internal+0-2016-05-16-113151.aph.hs) # Java VM: OpenJDK 64-Bit Server VM (slowdebug 9-internal+0-2016-05-16-113151.aph.hs, mixed mode, tiered, compressed oops, g1 gc, linux-aarch64) # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/aph/hs/hotspot/test/JTwork/scratch/hs_err_pid13951.log (gdb) p ((StrIndexOfNode*)n)->encoding() $4 = StrIntrinsicNode::UL So yes, we do have to cope with all of the combinations. Andrew. From roland.schatz at oracle.com Tue May 17 10:04:08 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Tue, 17 May 2016 12:04:08 +0200 Subject: RFR: 8156942: [JVMCI] replace LIRKind with abstract base class In-Reply-To: <5F033509-F355-4BFB-BA00-D6E07297D406@oracle.com> References: <5735F39C.3050103@oracle.com> <5F033509-F355-4BFB-BA00-D6E07297D406@oracle.com> Message-ID: <573AEC98.9070907@oracle.com> Thanks for the review! One minor update: http://cr.openjdk.java.net/~rschatz/JDK-8156942/webrev.01/ I missed a reference to the removed LIRKind class inside an assertion, breaking the debug builds. - Roland On 05/13/2016 06:22 PM, Igor Veresov wrote: > Looks ok > > igor > >> On May 13, 2016, at 8:32 AM, Roland Schatz wrote: >> >> Hi, >> >> Please review this cleanup change: >> http://cr.openjdk.java.net/~rschatz/JDK-8156942/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8156942 >> >> Passes all jvmci jtreg tests and all graal unit tests. >> >> Thanks, >> Roland From doug.simon at oracle.com Tue May 17 12:53:30 2016 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 17 May 2016 14:53:30 +0200 Subject: RFR: 8156835: [JVMCI] clean up and minimize JVMCI In-Reply-To: <0E2B9ACF-4BB4-4A6F-A941-37564ACADDB0@oracle.com> References: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> <0E2B9ACF-4BB4-4A6F-A941-37564ACADDB0@oracle.com> Message-ID: <2369BC35-646B-4AEE-B890-E6BFE5E37B73@oracle.com> I had forgotten to re-apply the removal of UnsafeUtil from https://bugs.openjdk.java.net/browse/JDK-8156759 to 8156835. I?ve applied it now and updated the webrev. > On 13 May 2016, at 21:54, Doug Simon wrote: > > >> On 13 May 2016, at 18:21, Igor Veresov wrote: >> >> Looks ok > > Thanks for the review. > > -Doug > >>> On May 13, 2016, at 4:40 AM, Doug Simon wrote: >>> >>> Please review this RFE that makes minor changes to clean up and minimize JVMCI. >>> >>> All jtreg tests pass as do all Graal tests. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8156835 >>> http://cr.openjdk.java.net/~dnsimon/8156835 >>> >>> -Doug >> > From igor.veresov at oracle.com Tue May 17 17:58:44 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 17 May 2016 10:58:44 -0700 Subject: RFR: 8156942: [JVMCI] replace LIRKind with abstract base class In-Reply-To: <573AEC98.9070907@oracle.com> References: <5735F39C.3050103@oracle.com> <5F033509-F355-4BFB-BA00-D6E07297D406@oracle.com> <573AEC98.9070907@oracle.com> Message-ID: <03EF693D-64FD-4387-8CB7-BC7E9BCC6273@oracle.com> Sill alright. igor > On May 17, 2016, at 3:04 AM, Roland Schatz wrote: > > Thanks for the review! > > One minor update: > http://cr.openjdk.java.net/~rschatz/JDK-8156942/webrev.01/ > > I missed a reference to the removed LIRKind class inside an assertion, breaking the debug builds. > > - Roland > > On 05/13/2016 06:22 PM, Igor Veresov wrote: >> Looks ok >> >> igor >> >>> On May 13, 2016, at 8:32 AM, Roland Schatz wrote: >>> >>> Hi, >>> >>> Please review this cleanup change: >>> http://cr.openjdk.java.net/~rschatz/JDK-8156942/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8156942 >>> >>> Passes all jvmci jtreg tests and all graal unit tests. >>> >>> Thanks, >>> Roland > From igor.veresov at oracle.com Tue May 17 17:59:24 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 17 May 2016 10:59:24 -0700 Subject: RFR: 8156835: [JVMCI] clean up and minimize JVMCI In-Reply-To: <2369BC35-646B-4AEE-B890-E6BFE5E37B73@oracle.com> References: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> <0E2B9ACF-4BB4-4A6F-A941-37564ACADDB0@oracle.com> <2369BC35-646B-4AEE-B890-E6BFE5E37B73@oracle.com> Message-ID: <552344DB-477E-41AF-96ED-249DF39B3843@oracle.com> Looks good. igor > On May 17, 2016, at 5:53 AM, Doug Simon wrote: > > I had forgotten to re-apply the removal of UnsafeUtil from https://bugs.openjdk.java.net/browse/JDK-8156759 to 8156835. I?ve applied it now and updated the webrev. > >> On 13 May 2016, at 21:54, Doug Simon wrote: >> >> >>> On 13 May 2016, at 18:21, Igor Veresov wrote: >>> >>> Looks ok >> >> Thanks for the review. >> >> -Doug >> >>>> On May 13, 2016, at 4:40 AM, Doug Simon wrote: >>>> >>>> Please review this RFE that makes minor changes to clean up and minimize JVMCI. >>>> >>>> All jtreg tests pass as do all Graal tests. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8156835 >>>> http://cr.openjdk.java.net/~dnsimon/8156835 >>>> >>>> -Doug >>> >> > From zoltan.majo at oracle.com Wed May 18 08:54:05 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 18 May 2016 10:54:05 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods Message-ID: <573C2DAD.1030903@oracle.com> Hi, please review the patch for 8157181. https://bugs.openjdk.java.net/browse/JDK-8157181 Problem: According to the Java VM Specification, the putstatic bytecode is allowed to modify a final field only - (1) if the field is declared in the current class (the class that declares the current method) and - (2) if the putstatic instruction appears in the class or interface initializer method of the current class. If any of the conditions above does not hold, an IllegalAccessError must be thrown. Similar conditions apply for putfield bytecodes targeting final fields. Currently, HotSpot checks only condition (1) but not (2) [1]. Methods that do not satisfy condition (2) violate the assumptions of the compilers (e.g., at [2]). Compiling such methods results in different behavior of compiled and interpreted code. The bug report describes such a case in detail. Solution: Bail out compilation of methods that do not satisfy condition (2). Webrev: http://cr.openjdk.java.net/~zmajo/8157181/webrev.00/ Testing: - JPRT - local testing with reproducer. It seems to me that the interpeter is affected by a related problem (i.e., the interpreter does not throw an IllegalAccessError if (2) does not hold). I'd prefer to file a separate bug for that problem. Thank you! Best regards, Zoltan [1]: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/interpreter/linkResolver.cpp#l910 [2]: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/07a5eceac654/src/share/vm/opto/parse3.cpp#l303 From vladimir.x.ivanov at oracle.com Wed May 18 10:02:53 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 18 May 2016 13:02:53 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <573C2DAD.1030903@oracle.com> References: <573C2DAD.1030903@oracle.com> Message-ID: > Webrev: > http://cr.openjdk.java.net/~zmajo/8157181/webrev.00/ src/share/vm/c1/c1_GraphBuilder.cpp: + if (field->is_constant() && + strcmp(method()->name()->as_quoted_ascii(), "") != 0) { + if (field->is_final() && + strcmp(method()->name()->as_quoted_ascii(), "") != 0) { Use Method::is_initializer()/is_static_initializer() instead. Also, instead of bailing out the whole compilation, you can emit an access as if the field access isn't linked yet (C1 supports that by setting field offset to -1). The JVM should throw an appropriate exception when trying to link the field. > It seems to me that the interpeter is affected by a related problem > (i.e., the interpreter does not throw an IllegalAccessError if (2) does > not hold). I'd prefer to file a separate bug for that problem. I'm confused. How do you observe the difference between -Xint & -Xcomp mode then? Best regards, Vladimir Ivanov From zoltan.majo at oracle.com Wed May 18 11:30:05 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 18 May 2016 13:30:05 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: References: <573C2DAD.1030903@oracle.com> Message-ID: <573C523D.4040505@oracle.com> Hi Vladimir, thank you for the feedback! On 05/18/2016 12:02 PM, Vladimir Ivanov wrote: >> Webrev: >> http://cr.openjdk.java.net/~zmajo/8157181/webrev.00/ > > src/share/vm/c1/c1_GraphBuilder.cpp: > + if (field->is_constant() && > + strcmp(method()->name()->as_quoted_ascii(), "") != > 0) { > > + if (field->is_final() && > + strcmp(method()->name()->as_quoted_ascii(), "") != 0) { > > Use Method::is_initializer()/is_static_initializer() instead. OK. The method is_static_initializer() is available only on Method but not on ciMethod. So I've "exported" it to ciMethod as well. The method is_initializer() returns true for both and . So I've added a new method, is_instance_initializer(), that returns true only for . > > Also, instead of bailing out the whole compilation, you can emit an > access as if the field access isn't linked yet (C1 supports that by > setting field offset to -1). The JVM should throw an appropriate > exception when trying to link the field. I tried that (by setting the variable 'offset' in GraphBuilder::access_field to -1. But C1 will generate an access to an offset of -1; executing that code results in data corruption. > >> It seems to me that the interpeter is affected by a related problem >> (i.e., the interpreter does not throw an IllegalAccessError if (2) does >> not hold). I'd prefer to file a separate bug for that problem. > I'm confused. How do you observe the difference between -Xint & -Xcomp > mode then? Without the patch applied: * With -Xint, the VM does not throw an exception IllegalAccessError (as required by the VM spec). Instead, the VM executes the putstatic to the static final field as any other putstatic. * -Xcomp generates optimized code that folds a constant and results in a NullPointerException being thrown. The behavior with -Xint is the behavior expected and accepted by Jython. The problem was there since at least JDK 6, but was never observed "in the wild". The reason is that the method triggering the problem is not hot enough to be compiled (and so it is only interpreted). 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/ Thank you and best regards, Zoltan [3] https://bugs.openjdk.java.net/browse/JDK-8157181?focusedCommentId=13942824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13942824 > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed May 18 12:17:35 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 18 May 2016 15:17:35 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <573C523D.4040505@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> Message-ID: <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> >> Also, instead of bailing out the whole compilation, you can emit an >> access as if the field access isn't linked yet (C1 supports that by >> setting field offset to -1). The JVM should throw an appropriate >> exception when trying to link the field. > > I tried that (by setting the variable 'offset' in > GraphBuilder::access_field to -1. But C1 will generate an access to an > offset of -1; executing that code results in data corruption. Have you set needs_patching as well? src/share/vm/c1/c1_GraphBuilder.cpp [1] void GraphBuilder::access_field(Bytecodes::Code code) { ... const bool needs_patching = !holder->is_loaded() || !field->will_link(method()->holder(), code) || PatchALot; ... const int offset = !needs_patching ? field->offset() : -1; ... case Bytecodes::_putstatic: { ... append(new StoreField(append(obj), offset, field, val, true, state_before, needs_patching)); Otherwise, it's a bug in C1 and patching is broken for unlinked field accesses. >>> It seems to me that the interpeter is affected by a related problem >>> (i.e., the interpreter does not throw an IllegalAccessError if (2) does >>> not hold). I'd prefer to file a separate bug for that problem. >> I'm confused. How do you observe the difference between -Xint & -Xcomp >> mode then? > > Without the patch applied: > * With -Xint, the VM does not throw an exception IllegalAccessError (as > required by the VM spec). Instead, the VM executes the putstatic to the > static final field as any other putstatic. > * -Xcomp generates optimized code that folds a constant and results in a > NullPointerException being thrown. It's a different bug then. Compilers should not constant fold final field loads (from the same class) in initializers. > The behavior with -Xint is the behavior expected and accepted by Jython. > The problem was there since at least JDK 6, but was never observed "in > the wild". The reason is that the method triggering the problem is not > hot enough to be compiled (and so it is only interpreted). I vaguely remember JVMS allowed changing final fields in the same class from any code, but then that part was tightened (in 5?). I'd prefer to avoid discrepancy in behavior between different execution modes. Either disable problematic constant folding in compilers for now or fix compilers and interpreter at once. > 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 edward.nevill at gmail.com Wed May 18 13:10:57 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 18 May 2016 14:10:57 +0100 Subject: [aarch64-port-dev ] RFR: 8156839 : aarch64: indexOf does not support CompactStrings In-Reply-To: <5739C2D4.5000401@redhat.com> References: <1463060614.24642.8.camel@mint> <57348A95.7080707@redhat.com> <1463063413.24642.22.camel@mint> <5739C2D4.5000401@redhat.com> Message-ID: Hi, On Mon, May 16, 2016 at 1:53 PM, Andrew Haley wrote: > > > So yes, we do have to cope with all of the combinations. > Please review the following webrev which handles all combinations. http://cr.openjdk.java.net/~enevill/8156839/webrev.02/ Tested with fastdebug jtreg hotspot & langtools Before: hotspot: Test results: passed: 1,163; failed: 62; error: 41 langtools: Test results: passed: 3,503; failed: 97; error: 29 After: hotspot: Test results: passed: 1,166; failed: 60; error: 40 langtools: Test results: passed: 3,503; failed: 97; error: 29 All the best, Ed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Wed May 18 13:25:35 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 18 May 2016 15:25:35 +0200 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> Message-ID: <573C6D4F.7050509@oracle.com> Hi Vladimir, thank you for the detailed feedback. Please see comments below. On 05/18/2016 02:17 PM, Vladimir Ivanov wrote: >>> Also, instead of bailing out the whole compilation, you can emit an >>> access as if the field access isn't linked yet (C1 supports that by >>> setting field offset to -1). The JVM should throw an appropriate >>> exception when trying to link the field. >> >> I tried that (by setting the variable 'offset' in >> GraphBuilder::access_field to -1. But C1 will generate an access to an >> offset of -1; executing that code results in data corruption. > Have you set needs_patching as well? No, I did not and that was the reason why the access to offset -1 was generated. > > src/share/vm/c1/c1_GraphBuilder.cpp [1] > > void GraphBuilder::access_field(Bytecodes::Code code) { > ... > const bool needs_patching = !holder->is_loaded() || > !field->will_link(method()->holder(), code) || > PatchALot; > ... > const int offset = !needs_patching ? field->offset() : -1; > ... > case Bytecodes::_putstatic: { > ... > append(new StoreField(append(obj), offset, field, val, true, > state_before, needs_patching)); > > Otherwise, it's a bug in C1 and patching is broken for unlinked field > accesses. I did what you suggested and patching works fine. The putstatic (and the corresponding StoreField from above) is treated as a unlinked (as expected). However, linking does not generate the appropriate exception. The reason is that LinkResolver::resolve_field() checks only if the holder of the field is the same as the holder of the method, but not if the method is an initializer. So execution continues to bytecode @29 (that is constant folded by the compiler) and the original failure still appears. > >>>> It seems to me that the interpeter is affected by a related problem >>>> (i.e., the interpreter does not throw an IllegalAccessError if (2) >>>> does >>>> not hold). I'd prefer to file a separate bug for that problem. >>> I'm confused. How do you observe the difference between -Xint & -Xcomp >>> mode then? >> >> Without the patch applied: >> * With -Xint, the VM does not throw an exception IllegalAccessError (as >> required by the VM spec). Instead, the VM executes the putstatic to the >> static final field as any other putstatic. >> * -Xcomp generates optimized code that folds a constant and results in a >> NullPointerException being thrown. > > It's a different bug then. Compilers should not constant fold final > field loads (from the same class) in initializers. > >> The behavior with -Xint is the behavior expected and accepted by Jython. >> The problem was there since at least JDK 6, but was never observed "in >> the wild". The reason is that the method triggering the problem is not >> hot enough to be compiled (and so it is only interpreted). > > I vaguely remember JVMS allowed changing final fields in the same > class from any code, but then that part was tightened (in 5?). > > I'd prefer to avoid discrepancy in behavior between different > execution modes. Either disable problematic constant folding in > compilers for now or fix compilers and interpreter at once. I assume by "problematic constant folding" you mean "constant fold final field loads (from the same class) in initializers" from above. My impression is that the compilers can be safe only by completely disabling folding of final fields. The reason is that, currently, any method of a class 'C' declaring a static final field 'f' can change the field 'f' after class 'C' has been initialized. So even if we are compiling a method 'm' of a class 'X' that is accessing field 'C::f', 'f' can change after 'm' has been compiled. So folding final fields must be disabled for all compilations. Or am I missing something? 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 Wed May 18 13:47:39 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 18 May 2016 16:47:39 +0300 Subject: [9] RFR (S): 8157181: Compilers accept modification of final fields outside initializer methods In-Reply-To: <573C6D4F.7050509@oracle.com> References: <573C2DAD.1030903@oracle.com> <573C523D.4040505@oracle.com> <5f755ed3-6029-7c4b-9fb8-33ac6e41353f@oracle.com> <573C6D4F.7050509@oracle.com> Message-ID: <6d438479-274c-ce51-97fe-6256cbd9a9ec@oracle.com> >> Otherwise, it's a bug in C1 and patching is broken for unlinked field >> accesses. > > I did what you suggested and patching works fine. The putstatic (and the > corresponding StoreField from above) is treated as a unlinked (as > expected). > > However, linking does not generate the appropriate exception. The reason > is that LinkResolver::resolve_field() checks only if the holder of the > field is the same as the holder of the method, but not if the method is > an initializer. So execution continues to bytecode @29 (that is constant > folded by the compiler) and the original failure still appears. It's contradicts JVMS, which requires an IAE to be thrown. I think major release is the right place to fix it. >> >> I vaguely remember JVMS allowed changing final fields in the same >> class from any code, but then that part was tightened (in 5?). >> >> I'd prefer to avoid discrepancy in behavior between different >> execution modes. Either disable problematic constant folding in >> compilers for now or fix compilers and interpreter at once. > > I assume by "problematic constant folding" you mean "constant fold final > field loads (from the same class) in initializers" from above. Yes, because JVMS allows multiple updates of final fields from initializers and compilers should respect that. > My impression is that the compilers can be safe only by completely > disabling folding of final fields. The reason is that, currently, any > method of a class 'C' declaring a static final field 'f' can change the > field 'f' after class 'C' has been initialized. So even if we are > compiling a method 'm' of a class 'X' that is accessing field 'C::f', > 'f' can change after 'm' has been compiled. > > So folding final fields must be disabled for all compilations. Or am I > missing something? Yes, you are right. The only way to completely avoid discrepancy is to disable constant folding of final fields. So, I'm in favor of a generic fix to align the behavior with JVMS. 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 vivek.r.deshpande at intel.com Wed May 18 17:36:36 2016 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Wed, 18 May 2016 17:36:36 +0000 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <57162A88.7030608@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> Hi Vladimir Could you please review and sponsor this patch with the current solution. This patch calls correct fallback version for LIBM methods when LIBM is disabled. Regards, Vivek From: Deshpande, Vivek R Sent: Tuesday, May 10, 2016 11:00 AM To: 'Christian Thalinger' Cc: Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics HI Christian We have not heard from runtime team regarding this change. Shall we go ahead with the current solution ? I can send out the latest webrev. Let me know your thoughts. Regards, Vivek From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Monday, May 02, 2016 3:44 PM To: Deshpande, Vivek R Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics On May 2, 2016, at 11:53 AM, Deshpande, Vivek R > wrote: Hi Christian I had tried using call_VM_leaf() which you mentioned. But this function void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { call_VM_leaf_base(entry_point, number_of_arguments); } ends up calling void InterpreterMacroAssembler::call_VM_leaf_base(address entry_point, int number_of_arguments) { ... from interp_masm_x86.cpp instead of void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { ? Frankly, I didn?t know that there is an overload for call_VM_leaf_base in InterpreterMacroAssembler. So this means there are two options: a) Add a method in MacroAssembler to call MacroAssembler::call_VM_leaf_base (what you did) or b) Add InterpreterMacroAssembler::call_VM_leaf and change MacroAssembler::call_VM_leaf to do: void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); } I will let the runtime team decide. So I had put mathfunc() to call the masm version of call_VM_leaf_base(). Let me know what you think. Thanks and regards, Vivek From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Monday, May 02, 2016 1:50 PM To: Deshpande, Vivek R Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R > wrote: Hi Christian I have updated the webrev and link for the same is here: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ I am using mathfunc() to call the masm version of call_VM_leaf_base() and not the InterpreterMacroAssembler version. That?s better but, again, there is nothing math-y about this method: ! void MacroAssembler::mathfunc(address runtime_entry) { MacroAssembler::call_VM_leaf_base(runtime_entry, 0); } Also, there is this method: void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { call_VM_leaf_base(entry_point, number_of_arguments); } which has: void call_VM_leaf(address entry_point, int number_of_arguments = 0); Get rid of mathfunc completely and use call_VM_leaf directly. Regards, Vivek From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Thursday, April 21, 2016 2:35 PM To: Deshpande, Vivek R > Cc: Nils Eliasson >; hotspot-compiler-dev at openjdk.java.net; Vladimir Kozlov > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R > wrote: Hi The correct URL for the updated webrev is this. http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ +void MacroAssembler::mathfunc(address runtime_entry) { I don?t like the name of this method. Mainly because it?s only aligning the stack (shouldn?t that happen somewhere else?) and doing this 0x20 stack frame thing which I still don?t understand. Right, this is the one I was thinking about: void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { Sorry for the spam. Regards, Vivek From: Deshpande, Vivek R Sent: Wednesday, April 20, 2016 5:10 PM To: Deshpande, Vivek R; 'Nils Eliasson'; 'hotspot-compiler-dev at openjdk.java.net' Cc: 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian Thalinger'; Viswanathan, Sandhya Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics Sent out the wrong link by mistake. updated webrev: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ Regards Vivek From: Deshpande, Vivek R Sent: Wednesday, April 20, 2016 5:07 PM To: 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net Cc: Vladimir Kozlov; Volker Simonis; Christian Thalinger; Viswanathan, Sandhya Subject: RE: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics Hi Nils I have updated the webrev with all the suggestions. updated webrev: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ Thanks for your comments and review. @Vladimir, I have taken care of all the comments. Would you please review and sponsor the patch. Thanks and regards, Vivek From: Nils Eliasson [mailto:nils.eliasson at oracle.com] Sent: Wednesday, April 20, 2016 12:27 PM To: Deshpande, Vivek R; hotspot-compiler-dev at openjdk.java.net Cc: Vladimir Kozlov; Volker Simonis; Christian Thalinger; Viswanathan, Sandhya Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In vmSymbols.cpp together with the other flag checks. Regards, Nils On 2016-04-20 02:44, Deshpande, Vivek R wrote: HI Nils Yes you are right the function accesses the command line flag DisableIntrinsic and changes are static. Could you point me the right location for the function ? Also I have updated the webrev with rest of the comments here: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ Regards, Vivek From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]On Behalf Of Nils Eliasson Sent: Tuesday, April 19, 2016 5:55 AM To: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics Hi Vivek, The changes in is_intrinsic_disabled in compilerDirectives.* are static and only access the command line flag DisableIntrinsics. As long as stubs are only generated during startup and don't have a method context - that is ok - but it doesn't belong in the compilerDirectives-files if it doens't use directives. Regards, Nils On 2016-04-18 19:38, Deshpande, Vivek R wrote: Hi all I would like to contribute a patch which helps to control the intrinsics in interpreter, c1 and c2 by disabling the stub generation. This uses -XX:DisableIntrinsic option to achieve the same. Could you please review and sponsor this patch. Bug-id: https://bugs.openjdk.java.net/browse/JDK-8154473 webrev: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ Thanks and regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed May 18 18:03:58 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 May 2016 11:03:58 -0700 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <57162A88.7030608@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> Message-ID: <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> Hi Vivek, Can you send link to latest webrev? The thread is long and it is not clear which webrev is final. Thanks, Vladimir On 5/18/16 10:36 AM, Deshpande, Vivek R wrote: > > > Hi Vladimir > > > > Could you please review and sponsor this patch with the current solution. > > This patch calls correct fallback version for LIBM methods when LIBM is > disabled. > > > > Regards, > > Vivek > > > > > > > > *From:*Deshpande, Vivek R > *Sent:* Tuesday, May 10, 2016 11:00 AM > *To:* 'Christian Thalinger' > *Cc:* Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; > hotspot-runtime-dev at openjdk.java.net runtime > *Subject:* RE: RFR (S): 8154473: Update for CompilerDirectives to > control stub generation and intrinsics > > > > HI Christian > > > > We have not heard from runtime team regarding this change. > > Shall we go ahead with the current solution ? > > I can send out the latest webrev. > > Let me know your thoughts. > > > > Regards, > > Vivek > > > > *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] > *Sent:* Monday, May 02, 2016 3:44 PM > *To:* Deshpande, Vivek R > *Cc:* Viswanathan, Sandhya; hotspot compiler; > hotspot-runtime-dev at openjdk.java.net > runtime > *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to > control stub generation and intrinsics > > > > > > On May 2, 2016, at 11:53 AM, Deshpande, Vivek R > > > wrote: > > > > Hi Christian > > > > I had tried using call_VM_leaf() which you mentioned. > > > > But this function > > > > void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) > { > > call_VM_leaf_base(entry_point, number_of_arguments); > > } > > > > ends up calling > > > > void InterpreterMacroAssembler::call_VM_leaf_base(address entry_point, > > int number_of_arguments) > { ... > > from interp_masm_x86.cpp instead of > > > > void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) > { ? > > > > Frankly, I didn?t know that there is an overload for call_VM_leaf_base > in InterpreterMacroAssembler. So this means there are two options: > > > > a) Add a method in MacroAssembler to call > MacroAssembler::call_VM_leaf_base (what you did) or > > > > b) Add InterpreterMacroAssembler::call_VM_leaf and > change MacroAssembler::call_VM_leaf to do: > > > > voidMacroAssembler::call_VM_leaf(address entry_point, int > number_of_arguments) { > > MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); > > } > > > > I will let the runtime team decide. > > > > > > So I had put mathfunc() to call the masm version of call_VM_leaf_base(). > > > > Let me know what you think. > > > > Thanks and regards, > Vivek > > > > *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] > *Sent:* Monday, May 02, 2016 1:50 PM > *To:* Deshpande, Vivek R > *Cc:* hotspot-compiler-dev at openjdk.java.net > > *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to > control stub generation and intrinsics > > > > > > On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R > > wrote: > > > > Hi Christian > > > > I have updated the webrev and link for the same is here: > > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ > > I am using mathfunc() to call the masm version of > call_VM_leaf_base() and not the InterpreterMacroAssembler version. > > > > That?s better but, again, there is nothing math-y about this method: > > ! void MacroAssembler::mathfunc(address runtime_entry) { > > MacroAssembler::call_VM_leaf_base(runtime_entry, 0); > > } > > Also, there is this method: > > > > void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) > { > > call_VM_leaf_base(entry_point, number_of_arguments); > > } > > > > which has: > > > > void call_VM_leaf(address entry_point, > > int number_of_arguments = 0); > > > > Get rid of mathfunc completely and use call_VM_leaf directly. > > > > > > Regards, > > Vivek > > > > > > *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] > *Sent:* Thursday, April 21, 2016 2:35 PM > *To:* Deshpande, Vivek R > > *Cc:* Nils Eliasson >; hotspot-compiler-dev at openjdk.java.net > ; Vladimir Kozlov > > > *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives > to control stub generation and intrinsics > > > > > > On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R > > wrote: > > > > Hi > > > > The correct URL for the updated webrev is this. > > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ > > > > +void MacroAssembler::mathfunc(address runtime_entry) { > > I don?t like the name of this method. Mainly because it?s only > aligning the stack (shouldn?t that happen somewhere else?) and > doing this 0x20 stack frame thing which I still don?t understand. > > > > Right, this is the one I was thinking about: > > > > void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) > { > > > > > Sorry for the spam. > > > > Regards, > > Vivek > > > > *From:* Deshpande, Vivek R > *Sent:* Wednesday, April 20, 2016 5:10 PM > *To:* Deshpande, Vivek R; 'Nils Eliasson'; > 'hotspot-compiler-dev at openjdk.java.net > ' > *Cc:* 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian > Thalinger'; Viswanathan, Sandhya > *Subject:* RE: RFR (S): 8154473: Update for > CompilerDirectives to control stub generation and intrinsics > > > > Sent out the wrong link by mistake. > > > > updated webrev: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ > > > > > Regards > > Vivek > > > > > > *From:* Deshpande, Vivek R > *Sent:* Wednesday, April 20, 2016 5:07 PM > *To:* 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net > > *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; > Viswanathan, Sandhya > *Subject:* RE: RFR (S): 8154473: Update for > CompilerDirectives to control stub generation and intrinsics > > > > Hi Nils > > > > I have updated the webrev with all the suggestions. > > updated webrev: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ > > Thanks for your comments and review. > > > > @Vladimir, > > I have taken care of all the comments. Would you please > review and sponsor the patch. > > > > Thanks and regards, > > Vivek > > > > *From:* Nils Eliasson [mailto:nils.eliasson at oracle.com] > *Sent:* Wednesday, April 20, 2016 12:27 PM > *To:* Deshpande, Vivek > R; hotspot-compiler-dev at openjdk.java.net > > *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; > Viswanathan, Sandhya > *Subject:* Re: RFR (S): 8154473: Update for > CompilerDirectives to control stub generation and intrinsics > > > > In vmSymbols.cpp together with the other flag checks. > > Regards, > Nils > > On 2016-04-20 02:44, Deshpande, Vivek R wrote: > > HI Nils > > > > Yes you are right the function accesses the command line > flag DisableIntrinsic and changes are static. > > Could you point me the right location for the function ? > > Also I have updated the webrev with rest of the comments > here: > > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.01/ > > > > Regards, > > Vivek > > > > *From:* hotspot-compiler-dev > [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]*On Behalf > Of *Nils Eliasson > *Sent:* Tuesday, April 19, 2016 5:55 AM > *To:* hotspot-compiler-dev at openjdk.java.net > > *Subject:* Re: RFR (S): 8154473: Update for > CompilerDirectives to control stub generation and intrinsics > > > > Hi Vivek, > > The changes in is_intrinsic_disabled in > compilerDirectives.* are static and only access the > command line flag DisableIntrinsics. As long as stubs > are only generated during startup and don't have a > method context - that is ok - but it doesn't belong in > the compilerDirectives-files if it doens't use directives. > > Regards, > Nils > > On 2016-04-18 19:38, Deshpande, Vivek R wrote: > > Hi all > > > > I would like to contribute a patch which helps to > control the intrinsics in interpreter, c1 and c2 by > disabling the stub generation. > > This uses -XX:DisableIntrinsic option to achieve the > same. > > Could you please review and sponsor this patch. > > > > Bug-id: > > https://bugs.openjdk.java.net/browse/JDK-8154473 > webrev: > > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ > > > > > Thanks and regards, > > Vivek > > > From vivek.r.deshpande at intel.com Wed May 18 18:27:37 2016 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Wed, 18 May 2016 18:27:37 +0000 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <57162A88.7030608@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D924@ORSMSX106.amr.corp.intel.com> Hi Vladimir The latest webrev is here: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ The bug ID for the same is: https://bugs.openjdk.java.net/browse/JDK-8154473 Thanks for looking into it. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, May 18, 2016 11:04 AM To: Deshpande, Vivek R Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics Hi Vivek, Can you send link to latest webrev? The thread is long and it is not clear which webrev is final. Thanks, Vladimir On 5/18/16 10:36 AM, Deshpande, Vivek R wrote: > > > Hi Vladimir > > > > Could you please review and sponsor this patch with the current solution. > > This patch calls correct fallback version for LIBM methods when LIBM > is disabled. > > > > Regards, > > Vivek > > > > > > > > *From:*Deshpande, Vivek R > *Sent:* Tuesday, May 10, 2016 11:00 AM > *To:* 'Christian Thalinger' > *Cc:* Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; > hotspot-runtime-dev at openjdk.java.net runtime > *Subject:* RE: RFR (S): 8154473: Update for CompilerDirectives to > control stub generation and intrinsics > > > > HI Christian > > > > We have not heard from runtime team regarding this change. > > Shall we go ahead with the current solution ? > > I can send out the latest webrev. > > Let me know your thoughts. > > > > Regards, > > Vivek > > > > *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] > *Sent:* Monday, May 02, 2016 3:44 PM > *To:* Deshpande, Vivek R > *Cc:* Viswanathan, Sandhya; hotspot compiler; > hotspot-runtime-dev at openjdk.java.net > runtime > *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to > control stub generation and intrinsics > > > > > > On May 2, 2016, at 11:53 AM, Deshpande, Vivek R > > > wrote: > > > > Hi Christian > > > > I had tried using call_VM_leaf() which you mentioned. > > > > But this function > > > > void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) > { > > call_VM_leaf_base(entry_point, number_of_arguments); > > } > > > > ends up calling > > > > void InterpreterMacroAssembler::call_VM_leaf_base(address > entry_point, > > int number_of_arguments) > { ... > > from interp_masm_x86.cpp instead of > > > > void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) > { ? > > > > Frankly, I didn?t know that there is an overload for call_VM_leaf_base > in InterpreterMacroAssembler. So this means there are two options: > > > > a) Add a method in MacroAssembler to call > MacroAssembler::call_VM_leaf_base (what you did) or > > > > b) Add InterpreterMacroAssembler::call_VM_leaf and change > MacroAssembler::call_VM_leaf to do: > > > > voidMacroAssembler::call_VM_leaf(address entry_point, int > number_of_arguments) { > > MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); > > } > > > > I will let the runtime team decide. > > > > > > So I had put mathfunc() to call the masm version of call_VM_leaf_base(). > > > > Let me know what you think. > > > > Thanks and regards, > Vivek > > > > *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] > *Sent:* Monday, May 02, 2016 1:50 PM > *To:* Deshpande, Vivek R > *Cc:* hotspot-compiler-dev at openjdk.java.net > > *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to > control stub generation and intrinsics > > > > > > On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R > > wrote: > > > > Hi Christian > > > > I have updated the webrev and link for the same is here: > > > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr > ev.03/ > > I am using mathfunc() to call the masm version of > call_VM_leaf_base() and not the InterpreterMacroAssembler version. > > > > That?s better but, again, there is nothing math-y about this method: > > ! void MacroAssembler::mathfunc(address runtime_entry) { > > MacroAssembler::call_VM_leaf_base(runtime_entry, 0); > > } > > Also, there is this method: > > > > void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) > { > > call_VM_leaf_base(entry_point, number_of_arguments); > > } > > > > which has: > > > > void call_VM_leaf(address entry_point, > > int number_of_arguments = 0); > > > > Get rid of mathfunc completely and use call_VM_leaf directly. > > > > > > Regards, > > Vivek > > > > > > *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] > *Sent:* Thursday, April 21, 2016 2:35 PM > *To:* Deshpande, Vivek R > > *Cc:* Nils Eliasson >; hotspot-compiler-dev at openjdk.java.net > ; Vladimir Kozlov > > > *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives > to control stub generation and intrinsics > > > > > > On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R > > wrote: > > > > Hi > > > > The correct URL for the updated webrev is this. > > > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr > ev.02/ > > > > +void MacroAssembler::mathfunc(address runtime_entry) { > > I don?t like the name of this method. Mainly because it?s only > aligning the stack (shouldn?t that happen somewhere else?) and > doing this 0x20 stack frame thing which I still don?t understand. > > > > Right, this is the one I was thinking about: > > > > void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) > { > > > > > Sorry for the spam. > > > > Regards, > > Vivek > > > > *From:* Deshpande, Vivek R > *Sent:* Wednesday, April 20, 2016 5:10 PM > *To:* Deshpande, Vivek R; 'Nils Eliasson'; > 'hotspot-compiler-dev at openjdk.java.net > ' > *Cc:* 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian > Thalinger'; Viswanathan, Sandhya > *Subject:* RE: RFR (S): 8154473: Update for > CompilerDirectives to control stub generation and > intrinsics > > > > Sent out the wrong link by mistake. > > > > updated webrev: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ > > rev.01/> > > > > Regards > > Vivek > > > > > > *From:* Deshpande, Vivek R > *Sent:* Wednesday, April 20, 2016 5:07 PM > *To:* 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net > > *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; > Viswanathan, Sandhya > *Subject:* RE: RFR (S): 8154473: Update for > CompilerDirectives to control stub generation and > intrinsics > > > > Hi Nils > > > > I have updated the webrev with all the suggestions. > > updated webrev: > > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr > ev.01/ > > Thanks for your comments and review. > > > > @Vladimir, > > I have taken care of all the comments. Would you please > review and sponsor the patch. > > > > Thanks and regards, > > Vivek > > > > *From:* Nils Eliasson [mailto:nils.eliasson at oracle.com] > *Sent:* Wednesday, April 20, 2016 12:27 PM > *To:* Deshpande, Vivek > R; hotspot-compiler-dev at openjdk.java.net > > *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; > Viswanathan, Sandhya > *Subject:* Re: RFR (S): 8154473: Update for > CompilerDirectives to control stub generation and > intrinsics > > > > In vmSymbols.cpp together with the other flag checks. > > Regards, > Nils > > On 2016-04-20 02:44, Deshpande, Vivek R wrote: > > HI Nils > > > > Yes you are right the function accesses the command line > flag DisableIntrinsic and changes are static. > > Could you point me the right location for the function ? > > Also I have updated the webrev with rest of the comments > here: > > > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr > ev.01/ > > > > Regards, > > Vivek > > > > *From:* hotspot-compiler-dev > [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]*On Behalf > Of *Nils Eliasson > *Sent:* Tuesday, April 19, 2016 5:55 AM > *To:* hotspot-compiler-dev at openjdk.java.net > > *Subject:* Re: RFR (S): 8154473: Update for > CompilerDirectives to control stub generation and > intrinsics > > > > Hi Vivek, > > The changes in is_intrinsic_disabled in > compilerDirectives.* are static and only access the > command line flag DisableIntrinsics. As long as stubs > are only generated during startup and don't have a > method context - that is ok - but it doesn't belong in > the compilerDirectives-files if it doens't use directives. > > Regards, > Nils > > On 2016-04-18 19:38, Deshpande, Vivek R wrote: > > Hi all > > > > I would like to contribute a patch which helps to > control the intrinsics in interpreter, c1 and c2 by > disabling the stub generation. > > This uses -XX:DisableIntrinsic option to achieve the > same. > > Could you please review and sponsor this patch. > > > > Bug-id: > > https://bugs.openjdk.java.net/browse/JDK-8154473 > webrev: > > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ > > ebrev.00/> > > > > Thanks and regards, > > Vivek > > > From vladimir.kozlov at oracle.com Wed May 18 19:24:00 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 May 2016 12:24:00 -0700 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D924@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <57162A88.7030608@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D924@ORSMSX106.amr.corp.intel.com> Message-ID: <62c7df4e-d9ed-8d72-6335-1de307fc6e08@oracle.com> First, 8154473 is RFE and we are post FC (feature complete). We have to wait until the process of RFEs approval is finalized. Or we can convert it to bug. Can you say what happens with current code if -XX:DisableIntrinsic=_dexp is used, for example? And what will happen after these changes? I don't see changes for: templateInterpreterGenerator_x86_32.cpp It would be better to have similar code there even if 32-bit code does not have stack problem. You did not implemented what Chris was asked: > a) Add a method in MacroAssembler to call MacroAssembler::call_VM_leaf_base (what you did) or > >b) Add InterpreterMacroAssembler::call_VM_leaf and change MacroAssembler::call_VM_leaf to do: > > void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { > MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); > } I would suggest an other method // Use this method when MacroAssembler version of call_VM_leaf_base() should be called. void MacroAssembler::call_VM_leaf0(address entry_point) { MacroAssembler::call_VM_leaf_base(entry_point, 0); } Thanks, Vladimir On 5/18/16 11:27 AM, Deshpande, Vivek R wrote: > Hi Vladimir > > The latest webrev is here: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ > The bug ID for the same is: > https://bugs.openjdk.java.net/browse/JDK-8154473 > > Thanks for looking into it. > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, May 18, 2016 11:04 AM > To: Deshpande, Vivek R > Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > Hi Vivek, > > Can you send link to latest webrev? The thread is long and it is not clear which webrev is final. > > Thanks, > Vladimir > > On 5/18/16 10:36 AM, Deshpande, Vivek R wrote: >> >> >> Hi Vladimir >> >> >> >> Could you please review and sponsor this patch with the current solution. >> >> This patch calls correct fallback version for LIBM methods when LIBM >> is disabled. >> >> >> >> Regards, >> >> Vivek >> >> >> >> >> >> >> >> *From:*Deshpande, Vivek R >> *Sent:* Tuesday, May 10, 2016 11:00 AM >> *To:* 'Christian Thalinger' >> *Cc:* Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; >> hotspot-runtime-dev at openjdk.java.net runtime >> *Subject:* RE: RFR (S): 8154473: Update for CompilerDirectives to >> control stub generation and intrinsics >> >> >> >> HI Christian >> >> >> >> We have not heard from runtime team regarding this change. >> >> Shall we go ahead with the current solution ? >> >> I can send out the latest webrev. >> >> Let me know your thoughts. >> >> >> >> Regards, >> >> Vivek >> >> >> >> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] >> *Sent:* Monday, May 02, 2016 3:44 PM >> *To:* Deshpande, Vivek R >> *Cc:* Viswanathan, Sandhya; hotspot compiler; >> hotspot-runtime-dev at openjdk.java.net >> runtime >> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >> control stub generation and intrinsics >> >> >> >> >> >> On May 2, 2016, at 11:53 AM, Deshpande, Vivek R >> > >> wrote: >> >> >> >> Hi Christian >> >> >> >> I had tried using call_VM_leaf() which you mentioned. >> >> >> >> But this function >> >> >> >> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >> { >> >> call_VM_leaf_base(entry_point, number_of_arguments); >> >> } >> >> >> >> ends up calling >> >> >> >> void InterpreterMacroAssembler::call_VM_leaf_base(address >> entry_point, >> >> int number_of_arguments) >> { ... >> >> from interp_masm_x86.cpp instead of >> >> >> >> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >> { ? >> >> >> >> Frankly, I didn?t know that there is an overload for call_VM_leaf_base >> in InterpreterMacroAssembler. So this means there are two options: >> >> >> >> a) Add a method in MacroAssembler to call >> MacroAssembler::call_VM_leaf_base (what you did) or >> >> >> >> b) Add InterpreterMacroAssembler::call_VM_leaf and change >> MacroAssembler::call_VM_leaf to do: >> >> >> >> voidMacroAssembler::call_VM_leaf(address entry_point, int >> number_of_arguments) { >> >> MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); >> >> } >> >> >> >> I will let the runtime team decide. >> >> >> >> >> >> So I had put mathfunc() to call the masm version of call_VM_leaf_base(). >> >> >> >> Let me know what you think. >> >> >> >> Thanks and regards, >> Vivek >> >> >> >> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >> *Sent:* Monday, May 02, 2016 1:50 PM >> *To:* Deshpande, Vivek R >> *Cc:* hotspot-compiler-dev at openjdk.java.net >> >> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >> control stub generation and intrinsics >> >> >> >> >> >> On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R >> > > wrote: >> >> >> >> Hi Christian >> >> >> >> I have updated the webrev and link for the same is here: >> >> >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >> ev.03/ >> >> I am using mathfunc() to call the masm version of >> call_VM_leaf_base() and not the InterpreterMacroAssembler version. >> >> >> >> That?s better but, again, there is nothing math-y about this method: >> >> ! void MacroAssembler::mathfunc(address runtime_entry) { >> >> MacroAssembler::call_VM_leaf_base(runtime_entry, 0); >> >> } >> >> Also, there is this method: >> >> >> >> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >> { >> >> call_VM_leaf_base(entry_point, number_of_arguments); >> >> } >> >> >> >> which has: >> >> >> >> void call_VM_leaf(address entry_point, >> >> int number_of_arguments = 0); >> >> >> >> Get rid of mathfunc completely and use call_VM_leaf directly. >> >> >> >> >> >> Regards, >> >> Vivek >> >> >> >> >> >> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >> *Sent:* Thursday, April 21, 2016 2:35 PM >> *To:* Deshpande, Vivek R > > >> *Cc:* Nils Eliasson > >; hotspot-compiler-dev at openjdk.java.net >> ; Vladimir Kozlov >> > >> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives >> to control stub generation and intrinsics >> >> >> >> >> >> On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R >> > > wrote: >> >> >> >> Hi >> >> >> >> The correct URL for the updated webrev is this. >> >> >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >> ev.02/ >> >> >> >> +void MacroAssembler::mathfunc(address runtime_entry) { >> >> I don?t like the name of this method. Mainly because it?s only >> aligning the stack (shouldn?t that happen somewhere else?) and >> doing this 0x20 stack frame thing which I still don?t understand. >> >> >> >> Right, this is the one I was thinking about: >> >> >> >> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >> { >> >> >> >> >> Sorry for the spam. >> >> >> >> Regards, >> >> Vivek >> >> >> >> *From:* Deshpande, Vivek R >> *Sent:* Wednesday, April 20, 2016 5:10 PM >> *To:* Deshpande, Vivek R; 'Nils Eliasson'; >> 'hotspot-compiler-dev at openjdk.java.net >> ' >> *Cc:* 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian >> Thalinger'; Viswanathan, Sandhya >> *Subject:* RE: RFR (S): 8154473: Update for >> CompilerDirectives to control stub generation and >> intrinsics >> >> >> >> Sent out the wrong link by mistake. >> >> >> >> updated webrev: >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ >> >> > rev.01/> >> >> >> >> Regards >> >> Vivek >> >> >> >> >> >> *From:* Deshpande, Vivek R >> *Sent:* Wednesday, April 20, 2016 5:07 PM >> *To:* 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net >> >> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >> Viswanathan, Sandhya >> *Subject:* RE: RFR (S): 8154473: Update for >> CompilerDirectives to control stub generation and >> intrinsics >> >> >> >> Hi Nils >> >> >> >> I have updated the webrev with all the suggestions. >> >> updated webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >> ev.01/ >> >> Thanks for your comments and review. >> >> >> >> @Vladimir, >> >> I have taken care of all the comments. Would you please >> review and sponsor the patch. >> >> >> >> Thanks and regards, >> >> Vivek >> >> >> >> *From:* Nils Eliasson [mailto:nils.eliasson at oracle.com] >> *Sent:* Wednesday, April 20, 2016 12:27 PM >> *To:* Deshpande, Vivek >> R; hotspot-compiler-dev at openjdk.java.net >> >> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >> Viswanathan, Sandhya >> *Subject:* Re: RFR (S): 8154473: Update for >> CompilerDirectives to control stub generation and >> intrinsics >> >> >> >> In vmSymbols.cpp together with the other flag checks. >> >> Regards, >> Nils >> >> On 2016-04-20 02:44, Deshpande, Vivek R wrote: >> >> HI Nils >> >> >> >> Yes you are right the function accesses the command line >> flag DisableIntrinsic and changes are static. >> >> Could you point me the right location for the function ? >> >> Also I have updated the webrev with rest of the comments >> here: >> >> >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >> ev.01/ >> >> >> >> Regards, >> >> Vivek >> >> >> >> *From:* hotspot-compiler-dev >> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]*On Behalf >> Of *Nils Eliasson >> *Sent:* Tuesday, April 19, 2016 5:55 AM >> *To:* hotspot-compiler-dev at openjdk.java.net >> >> *Subject:* Re: RFR (S): 8154473: Update for >> CompilerDirectives to control stub generation and >> intrinsics >> >> >> >> Hi Vivek, >> >> The changes in is_intrinsic_disabled in >> compilerDirectives.* are static and only access the >> command line flag DisableIntrinsics. As long as stubs >> are only generated during startup and don't have a >> method context - that is ok - but it doesn't belong in >> the compilerDirectives-files if it doens't use directives. >> >> Regards, >> Nils >> >> On 2016-04-18 19:38, Deshpande, Vivek R wrote: >> >> Hi all >> >> >> >> I would like to contribute a patch which helps to >> control the intrinsics in interpreter, c1 and c2 by >> disabling the stub generation. >> >> This uses -XX:DisableIntrinsic option to achieve the >> same. >> >> Could you please review and sponsor this patch. >> >> >> >> Bug-id: >> >> https://bugs.openjdk.java.net/browse/JDK-8154473 >> webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ >> >> > ebrev.00/> >> >> >> >> Thanks and regards, >> >> Vivek >> >> >> From vivek.r.deshpande at intel.com Wed May 18 19:36:22 2016 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Wed, 18 May 2016 19:36:22 +0000 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <62c7df4e-d9ed-8d72-6335-1de307fc6e08@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <57162A88.7030608@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D924@ORSMSX106.amr.corp.intel.com> <62c7df4e-d9ed-8d72-6335-1de307fc6e08@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DAC6@ORSMSX106.amr.corp.intel.com> HI Vladimir We can convert it to bug. With the change, using -XX:DisableIntrinsic=_dexp, will not generate the LIBM stub and all the calls will point to SharedRuntime::dexp correctly with stack adjustment. Currently with -XX:DisableIntrinsic=_dexp, stub gets generated and points to LIBM stub in interpreter. and just using option UseLibmIntrinsic to disable LIBM usage fails without stack adjustment for 64 bit. I can make changes for 32 bit in updated webrev. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, May 18, 2016 12:24 PM To: Deshpande, Vivek R Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics First, 8154473 is RFE and we are post FC (feature complete). We have to wait until the process of RFEs approval is finalized. Or we can convert it to bug. Can you say what happens with current code if -XX:DisableIntrinsic=_dexp is used, for example? And what will happen after these changes? I don't see changes for: templateInterpreterGenerator_x86_32.cpp It would be better to have similar code there even if 32-bit code does not have stack problem. You did not implemented what Chris was asked: > a) Add a method in MacroAssembler to call MacroAssembler::call_VM_leaf_base (what you did) or > >b) Add InterpreterMacroAssembler::call_VM_leaf and change MacroAssembler::call_VM_leaf to do: > > void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { > MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); > } I would suggest an other method // Use this method when MacroAssembler version of call_VM_leaf_base() should be called. void MacroAssembler::call_VM_leaf0(address entry_point) { MacroAssembler::call_VM_leaf_base(entry_point, 0); } Thanks, Vladimir On 5/18/16 11:27 AM, Deshpande, Vivek R wrote: > Hi Vladimir > > The latest webrev is here: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ > The bug ID for the same is: > https://bugs.openjdk.java.net/browse/JDK-8154473 > > Thanks for looking into it. > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, May 18, 2016 11:04 AM > To: Deshpande, Vivek R > Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > Hi Vivek, > > Can you send link to latest webrev? The thread is long and it is not clear which webrev is final. > > Thanks, > Vladimir > > On 5/18/16 10:36 AM, Deshpande, Vivek R wrote: >> >> >> Hi Vladimir >> >> >> >> Could you please review and sponsor this patch with the current solution. >> >> This patch calls correct fallback version for LIBM methods when LIBM >> is disabled. >> >> >> >> Regards, >> >> Vivek >> >> >> >> >> >> >> >> *From:*Deshpande, Vivek R >> *Sent:* Tuesday, May 10, 2016 11:00 AM >> *To:* 'Christian Thalinger' >> *Cc:* Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; >> hotspot-runtime-dev at openjdk.java.net runtime >> *Subject:* RE: RFR (S): 8154473: Update for CompilerDirectives to >> control stub generation and intrinsics >> >> >> >> HI Christian >> >> >> >> We have not heard from runtime team regarding this change. >> >> Shall we go ahead with the current solution ? >> >> I can send out the latest webrev. >> >> Let me know your thoughts. >> >> >> >> Regards, >> >> Vivek >> >> >> >> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] >> *Sent:* Monday, May 02, 2016 3:44 PM >> *To:* Deshpande, Vivek R >> *Cc:* Viswanathan, Sandhya; hotspot compiler; >> hotspot-runtime-dev at openjdk.java.net >> runtime >> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >> control stub generation and intrinsics >> >> >> >> >> >> On May 2, 2016, at 11:53 AM, Deshpande, Vivek R >> > >> wrote: >> >> >> >> Hi Christian >> >> >> >> I had tried using call_VM_leaf() which you mentioned. >> >> >> >> But this function >> >> >> >> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >> { >> >> call_VM_leaf_base(entry_point, number_of_arguments); >> >> } >> >> >> >> ends up calling >> >> >> >> void InterpreterMacroAssembler::call_VM_leaf_base(address >> entry_point, >> >> int number_of_arguments) >> { ... >> >> from interp_masm_x86.cpp instead of >> >> >> >> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >> { ? >> >> >> >> Frankly, I didn?t know that there is an overload for call_VM_leaf_base >> in InterpreterMacroAssembler. So this means there are two options: >> >> >> >> a) Add a method in MacroAssembler to call >> MacroAssembler::call_VM_leaf_base (what you did) or >> >> >> >> b) Add InterpreterMacroAssembler::call_VM_leaf and change >> MacroAssembler::call_VM_leaf to do: >> >> >> >> voidMacroAssembler::call_VM_leaf(address entry_point, int >> number_of_arguments) { >> >> MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); >> >> } >> >> >> >> I will let the runtime team decide. >> >> >> >> >> >> So I had put mathfunc() to call the masm version of call_VM_leaf_base(). >> >> >> >> Let me know what you think. >> >> >> >> Thanks and regards, >> Vivek >> >> >> >> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >> *Sent:* Monday, May 02, 2016 1:50 PM >> *To:* Deshpande, Vivek R >> *Cc:* hotspot-compiler-dev at openjdk.java.net >> >> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >> control stub generation and intrinsics >> >> >> >> >> >> On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R >> > > wrote: >> >> >> >> Hi Christian >> >> >> >> I have updated the webrev and link for the same is here: >> >> >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >> ev.03/ >> >> I am using mathfunc() to call the masm version of >> call_VM_leaf_base() and not the InterpreterMacroAssembler version. >> >> >> >> That?s better but, again, there is nothing math-y about this method: >> >> ! void MacroAssembler::mathfunc(address runtime_entry) { >> >> MacroAssembler::call_VM_leaf_base(runtime_entry, 0); >> >> } >> >> Also, there is this method: >> >> >> >> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >> { >> >> call_VM_leaf_base(entry_point, number_of_arguments); >> >> } >> >> >> >> which has: >> >> >> >> void call_VM_leaf(address entry_point, >> >> int number_of_arguments = 0); >> >> >> >> Get rid of mathfunc completely and use call_VM_leaf directly. >> >> >> >> >> >> Regards, >> >> Vivek >> >> >> >> >> >> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >> *Sent:* Thursday, April 21, 2016 2:35 PM >> *To:* Deshpande, Vivek R > > >> *Cc:* Nils Eliasson > >; hotspot-compiler-dev at openjdk.java.net >> ; Vladimir Kozlov >> > >> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives >> to control stub generation and intrinsics >> >> >> >> >> >> On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R >> > > wrote: >> >> >> >> Hi >> >> >> >> The correct URL for the updated webrev is this. >> >> >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >> ev.02/ >> >> >> >> +void MacroAssembler::mathfunc(address runtime_entry) { >> >> I don?t like the name of this method. Mainly because it?s only >> aligning the stack (shouldn?t that happen somewhere else?) and >> doing this 0x20 stack frame thing which I still don?t understand. >> >> >> >> Right, this is the one I was thinking about: >> >> >> >> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >> { >> >> >> >> >> Sorry for the spam. >> >> >> >> Regards, >> >> Vivek >> >> >> >> *From:* Deshpande, Vivek R >> *Sent:* Wednesday, April 20, 2016 5:10 PM >> *To:* Deshpande, Vivek R; 'Nils Eliasson'; >> 'hotspot-compiler-dev at openjdk.java.net >> ' >> *Cc:* 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian >> Thalinger'; Viswanathan, Sandhya >> *Subject:* RE: RFR (S): 8154473: Update for >> CompilerDirectives to control stub generation and >> intrinsics >> >> >> >> Sent out the wrong link by mistake. >> >> >> >> updated webrev: >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ >> >> > rev.01/> >> >> >> >> Regards >> >> Vivek >> >> >> >> >> >> *From:* Deshpande, Vivek R >> *Sent:* Wednesday, April 20, 2016 5:07 PM >> *To:* 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net >> >> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >> Viswanathan, Sandhya >> *Subject:* RE: RFR (S): 8154473: Update for >> CompilerDirectives to control stub generation and >> intrinsics >> >> >> >> Hi Nils >> >> >> >> I have updated the webrev with all the suggestions. >> >> updated webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >> ev.01/ >> >> Thanks for your comments and review. >> >> >> >> @Vladimir, >> >> I have taken care of all the comments. Would you please >> review and sponsor the patch. >> >> >> >> Thanks and regards, >> >> Vivek >> >> >> >> *From:* Nils Eliasson [mailto:nils.eliasson at oracle.com] >> *Sent:* Wednesday, April 20, 2016 12:27 PM >> *To:* Deshpande, Vivek >> R; hotspot-compiler-dev at openjdk.java.net >> >> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >> Viswanathan, Sandhya >> *Subject:* Re: RFR (S): 8154473: Update for >> CompilerDirectives to control stub generation and >> intrinsics >> >> >> >> In vmSymbols.cpp together with the other flag checks. >> >> Regards, >> Nils >> >> On 2016-04-20 02:44, Deshpande, Vivek R wrote: >> >> HI Nils >> >> >> >> Yes you are right the function accesses the command line >> flag DisableIntrinsic and changes are static. >> >> Could you point me the right location for the function ? >> >> Also I have updated the webrev with rest of the comments >> here: >> >> >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >> ev.01/ >> >> >> >> Regards, >> >> Vivek >> >> >> >> *From:* hotspot-compiler-dev >> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]*On Behalf >> Of *Nils Eliasson >> *Sent:* Tuesday, April 19, 2016 5:55 AM >> *To:* hotspot-compiler-dev at openjdk.java.net >> >> *Subject:* Re: RFR (S): 8154473: Update for >> CompilerDirectives to control stub generation and >> intrinsics >> >> >> >> Hi Vivek, >> >> The changes in is_intrinsic_disabled in >> compilerDirectives.* are static and only access the >> command line flag DisableIntrinsics. As long as stubs >> are only generated during startup and don't have a >> method context - that is ok - but it doesn't belong in >> the compilerDirectives-files if it doens't use directives. >> >> Regards, >> Nils >> >> On 2016-04-18 19:38, Deshpande, Vivek R wrote: >> >> Hi all >> >> >> >> I would like to contribute a patch which helps to >> control the intrinsics in interpreter, c1 and c2 by >> disabling the stub generation. >> >> This uses -XX:DisableIntrinsic option to achieve the >> same. >> >> Could you please review and sponsor this patch. >> >> >> >> Bug-id: >> >> https://bugs.openjdk.java.net/browse/JDK-8154473 >> webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ >> >> > ebrev.00/> >> >> >> >> Thanks and regards, >> >> Vivek >> >> >> From vladimir.kozlov at oracle.com Wed May 18 19:40:32 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 May 2016 12:40:32 -0700 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DAC6@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <57162A88.7030608@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D924@ORSMSX106.amr.corp.intel.com> <62c7df4e-d9ed-8d72-6335-1de307fc6e08@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DAC6@ORSMSX106.amr.corp.intel.com> Message-ID: Okay, convert it to bug saying that -XX:DisableIntrinsic does not disable intrinsic in Interpreter. Which can lead to results inconsistencies since different code is used in compiled code and Interpreter. Thanks, Vladimir On 5/18/16 12:36 PM, Deshpande, Vivek R wrote: > HI Vladimir > > We can convert it to bug. > With the change, using -XX:DisableIntrinsic=_dexp, will not generate the LIBM stub and all the calls will point to SharedRuntime::dexp correctly with stack adjustment. > Currently with -XX:DisableIntrinsic=_dexp, stub gets generated and points to LIBM stub in interpreter. > and just using option UseLibmIntrinsic to disable LIBM usage fails without stack adjustment for 64 bit. > I can make changes for 32 bit in updated webrev. > > Regards, > Vivek > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, May 18, 2016 12:24 PM > To: Deshpande, Vivek R > Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > First, 8154473 is RFE and we are post FC (feature complete). We have to wait until the process of RFEs approval is finalized. > > Or we can convert it to bug. Can you say what happens with current code if -XX:DisableIntrinsic=_dexp is used, for example? And what will happen after these changes? > > I don't see changes for: > templateInterpreterGenerator_x86_32.cpp > > It would be better to have similar code there even if 32-bit code does not have stack problem. > > > You did not implemented what Chris was asked: > > > a) Add a method in MacroAssembler to call > MacroAssembler::call_VM_leaf_base (what you did) or > > > >b) Add InterpreterMacroAssembler::call_VM_leaf and change > MacroAssembler::call_VM_leaf to do: > > > > void MacroAssembler::call_VM_leaf(address entry_point, int > number_of_arguments) { > > MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); > > } > > I would suggest an other method > > // Use this method when MacroAssembler version of call_VM_leaf_base() > should be called. > void MacroAssembler::call_VM_leaf0(address entry_point) { > MacroAssembler::call_VM_leaf_base(entry_point, 0); > } > > Thanks, > Vladimir > > On 5/18/16 11:27 AM, Deshpande, Vivek R wrote: >> Hi Vladimir >> >> The latest webrev is here: >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ >> The bug ID for the same is: >> https://bugs.openjdk.java.net/browse/JDK-8154473 >> >> Thanks for looking into it. >> >> Regards, >> Vivek >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, May 18, 2016 11:04 AM >> To: Deshpande, Vivek R >> Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime >> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics >> >> Hi Vivek, >> >> Can you send link to latest webrev? The thread is long and it is not clear which webrev is final. >> >> Thanks, >> Vladimir >> >> On 5/18/16 10:36 AM, Deshpande, Vivek R wrote: >>> >>> >>> Hi Vladimir >>> >>> >>> >>> Could you please review and sponsor this patch with the current solution. >>> >>> This patch calls correct fallback version for LIBM methods when LIBM >>> is disabled. >>> >>> >>> >>> Regards, >>> >>> Vivek >>> >>> >>> >>> >>> >>> >>> >>> *From:*Deshpande, Vivek R >>> *Sent:* Tuesday, May 10, 2016 11:00 AM >>> *To:* 'Christian Thalinger' >>> *Cc:* Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; >>> hotspot-runtime-dev at openjdk.java.net runtime >>> *Subject:* RE: RFR (S): 8154473: Update for CompilerDirectives to >>> control stub generation and intrinsics >>> >>> >>> >>> HI Christian >>> >>> >>> >>> We have not heard from runtime team regarding this change. >>> >>> Shall we go ahead with the current solution ? >>> >>> I can send out the latest webrev. >>> >>> Let me know your thoughts. >>> >>> >>> >>> Regards, >>> >>> Vivek >>> >>> >>> >>> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> *Sent:* Monday, May 02, 2016 3:44 PM >>> *To:* Deshpande, Vivek R >>> *Cc:* Viswanathan, Sandhya; hotspot compiler; >>> hotspot-runtime-dev at openjdk.java.net >>> runtime >>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>> control stub generation and intrinsics >>> >>> >>> >>> >>> >>> On May 2, 2016, at 11:53 AM, Deshpande, Vivek R >>> > >>> wrote: >>> >>> >>> >>> Hi Christian >>> >>> >>> >>> I had tried using call_VM_leaf() which you mentioned. >>> >>> >>> >>> But this function >>> >>> >>> >>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>> { >>> >>> call_VM_leaf_base(entry_point, number_of_arguments); >>> >>> } >>> >>> >>> >>> ends up calling >>> >>> >>> >>> void InterpreterMacroAssembler::call_VM_leaf_base(address >>> entry_point, >>> >>> int number_of_arguments) >>> { ... >>> >>> from interp_masm_x86.cpp instead of >>> >>> >>> >>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>> { ? >>> >>> >>> >>> Frankly, I didn?t know that there is an overload for call_VM_leaf_base >>> in InterpreterMacroAssembler. So this means there are two options: >>> >>> >>> >>> a) Add a method in MacroAssembler to call >>> MacroAssembler::call_VM_leaf_base (what you did) or >>> >>> >>> >>> b) Add InterpreterMacroAssembler::call_VM_leaf and change >>> MacroAssembler::call_VM_leaf to do: >>> >>> >>> >>> voidMacroAssembler::call_VM_leaf(address entry_point, int >>> number_of_arguments) { >>> >>> MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); >>> >>> } >>> >>> >>> >>> I will let the runtime team decide. >>> >>> >>> >>> >>> >>> So I had put mathfunc() to call the masm version of call_VM_leaf_base(). >>> >>> >>> >>> Let me know what you think. >>> >>> >>> >>> Thanks and regards, >>> Vivek >>> >>> >>> >>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> *Sent:* Monday, May 02, 2016 1:50 PM >>> *To:* Deshpande, Vivek R >>> *Cc:* hotspot-compiler-dev at openjdk.java.net >>> >>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>> control stub generation and intrinsics >>> >>> >>> >>> >>> >>> On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R >>> >> > wrote: >>> >>> >>> >>> Hi Christian >>> >>> >>> >>> I have updated the webrev and link for the same is here: >>> >>> >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>> ev.03/ >>> >>> I am using mathfunc() to call the masm version of >>> call_VM_leaf_base() and not the InterpreterMacroAssembler version. >>> >>> >>> >>> That?s better but, again, there is nothing math-y about this method: >>> >>> ! void MacroAssembler::mathfunc(address runtime_entry) { >>> >>> MacroAssembler::call_VM_leaf_base(runtime_entry, 0); >>> >>> } >>> >>> Also, there is this method: >>> >>> >>> >>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>> { >>> >>> call_VM_leaf_base(entry_point, number_of_arguments); >>> >>> } >>> >>> >>> >>> which has: >>> >>> >>> >>> void call_VM_leaf(address entry_point, >>> >>> int number_of_arguments = 0); >>> >>> >>> >>> Get rid of mathfunc completely and use call_VM_leaf directly. >>> >>> >>> >>> >>> >>> Regards, >>> >>> Vivek >>> >>> >>> >>> >>> >>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> *Sent:* Thursday, April 21, 2016 2:35 PM >>> *To:* Deshpande, Vivek R >> > >>> *Cc:* Nils Eliasson >> >; hotspot-compiler-dev at openjdk.java.net >>> ; Vladimir Kozlov >>> > >>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives >>> to control stub generation and intrinsics >>> >>> >>> >>> >>> >>> On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R >>> >> > wrote: >>> >>> >>> >>> Hi >>> >>> >>> >>> The correct URL for the updated webrev is this. >>> >>> >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>> ev.02/ >>> >>> >>> >>> +void MacroAssembler::mathfunc(address runtime_entry) { >>> >>> I don?t like the name of this method. Mainly because it?s only >>> aligning the stack (shouldn?t that happen somewhere else?) and >>> doing this 0x20 stack frame thing which I still don?t understand. >>> >>> >>> >>> Right, this is the one I was thinking about: >>> >>> >>> >>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>> { >>> >>> >>> >>> >>> Sorry for the spam. >>> >>> >>> >>> Regards, >>> >>> Vivek >>> >>> >>> >>> *From:* Deshpande, Vivek R >>> *Sent:* Wednesday, April 20, 2016 5:10 PM >>> *To:* Deshpande, Vivek R; 'Nils Eliasson'; >>> 'hotspot-compiler-dev at openjdk.java.net >>> ' >>> *Cc:* 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian >>> Thalinger'; Viswanathan, Sandhya >>> *Subject:* RE: RFR (S): 8154473: Update for >>> CompilerDirectives to control stub generation and >>> intrinsics >>> >>> >>> >>> Sent out the wrong link by mistake. >>> >>> >>> >>> updated webrev: >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ >>> >>> >> rev.01/> >>> >>> >>> >>> Regards >>> >>> Vivek >>> >>> >>> >>> >>> >>> *From:* Deshpande, Vivek R >>> *Sent:* Wednesday, April 20, 2016 5:07 PM >>> *To:* 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net >>> >>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>> Viswanathan, Sandhya >>> *Subject:* RE: RFR (S): 8154473: Update for >>> CompilerDirectives to control stub generation and >>> intrinsics >>> >>> >>> >>> Hi Nils >>> >>> >>> >>> I have updated the webrev with all the suggestions. >>> >>> updated webrev: >>> >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>> ev.01/ >>> >>> Thanks for your comments and review. >>> >>> >>> >>> @Vladimir, >>> >>> I have taken care of all the comments. Would you please >>> review and sponsor the patch. >>> >>> >>> >>> Thanks and regards, >>> >>> Vivek >>> >>> >>> >>> *From:* Nils Eliasson [mailto:nils.eliasson at oracle.com] >>> *Sent:* Wednesday, April 20, 2016 12:27 PM >>> *To:* Deshpande, Vivek >>> R; hotspot-compiler-dev at openjdk.java.net >>> >>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>> Viswanathan, Sandhya >>> *Subject:* Re: RFR (S): 8154473: Update for >>> CompilerDirectives to control stub generation and >>> intrinsics >>> >>> >>> >>> In vmSymbols.cpp together with the other flag checks. >>> >>> Regards, >>> Nils >>> >>> On 2016-04-20 02:44, Deshpande, Vivek R wrote: >>> >>> HI Nils >>> >>> >>> >>> Yes you are right the function accesses the command line >>> flag DisableIntrinsic and changes are static. >>> >>> Could you point me the right location for the function ? >>> >>> Also I have updated the webrev with rest of the comments >>> here: >>> >>> >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>> ev.01/ >>> >>> >>> >>> Regards, >>> >>> Vivek >>> >>> >>> >>> *From:* hotspot-compiler-dev >>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]*On Behalf >>> Of *Nils Eliasson >>> *Sent:* Tuesday, April 19, 2016 5:55 AM >>> *To:* hotspot-compiler-dev at openjdk.java.net >>> >>> *Subject:* Re: RFR (S): 8154473: Update for >>> CompilerDirectives to control stub generation and >>> intrinsics >>> >>> >>> >>> Hi Vivek, >>> >>> The changes in is_intrinsic_disabled in >>> compilerDirectives.* are static and only access the >>> command line flag DisableIntrinsics. As long as stubs >>> are only generated during startup and don't have a >>> method context - that is ok - but it doesn't belong in >>> the compilerDirectives-files if it doens't use directives. >>> >>> Regards, >>> Nils >>> >>> On 2016-04-18 19:38, Deshpande, Vivek R wrote: >>> >>> Hi all >>> >>> >>> >>> I would like to contribute a patch which helps to >>> control the intrinsics in interpreter, c1 and c2 by >>> disabling the stub generation. >>> >>> This uses -XX:DisableIntrinsic option to achieve the >>> same. >>> >>> Could you please review and sponsor this patch. >>> >>> >>> >>> Bug-id: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>> webrev: >>> >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ >>> >>> >> ebrev.00/> >>> >>> >>> >>> Thanks and regards, >>> >>> Vivek >>> >>> >>> From doug.simon at oracle.com Wed May 18 21:35:32 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 18 May 2016 23:35:32 +0200 Subject: RFR: 8156835: [JVMCI] clean up and minimize JVMCI In-Reply-To: <552344DB-477E-41AF-96ED-249DF39B3843@oracle.com> References: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> <0E2B9ACF-4BB4-4A6F-A941-37564ACADDB0@oracle.com> <2369BC35-646B-4AEE-B890-E6BFE5E37B73@oracle.com> <552344DB-477E-41AF-96ED-249DF39B3843@oracle.com> Message-ID: <2F944251-FF22-41E6-BB6A-730F8B1CC1AE@oracle.com> I made one last minor change to improve the javadoc for MemoryAccessProvider.readObjectConstant: @@ -59,7 +59,9 @@ * * @param base the base address from which the value is read * @param displacement the displacement within the object in bytes - * @return the read value encapsulated in a {@link Constant} object + * @return the read value encapsulated in a {@link Constant} object or {@code null} if the + * address computed from {@code base} and {@code displacement} does not denote a + * location holding an {@code Object} value */ JavaConstant readObjectConstant(Constant base, long displacement); } If that looks ok, then Tom will integrate the webrev. -Doug > On 17 May 2016, at 19:59, Igor Veresov wrote: > > Looks good. > > igor > >> On May 17, 2016, at 5:53 AM, Doug Simon wrote: >> >> I had forgotten to re-apply the removal of UnsafeUtil from https://bugs.openjdk.java.net/browse/JDK-8156759 to 8156835. I?ve applied it now and updated the webrev. >> >>> On 13 May 2016, at 21:54, Doug Simon wrote: >>> >>> >>>> On 13 May 2016, at 18:21, Igor Veresov wrote: >>>> >>>> Looks ok >>> >>> Thanks for the review. >>> >>> -Doug >>> >>>>> On May 13, 2016, at 4:40 AM, Doug Simon wrote: >>>>> >>>>> Please review this RFE that makes minor changes to clean up and minimize JVMCI. >>>>> >>>>> All jtreg tests pass as do all Graal tests. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8156835 >>>>> http://cr.openjdk.java.net/~dnsimon/8156835 >>>>> >>>>> -Doug >>>> >>> >> > From igor.veresov at oracle.com Wed May 18 22:05:24 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 18 May 2016 15:05:24 -0700 Subject: RFR: 8156835: [JVMCI] clean up and minimize JVMCI In-Reply-To: <2F944251-FF22-41E6-BB6A-730F8B1CC1AE@oracle.com> References: <5D93D2DB-020B-4EAE-BE65-46514821E8D4@oracle.com> <0E2B9ACF-4BB4-4A6F-A941-37564ACADDB0@oracle.com> <2369BC35-646B-4AEE-B890-E6BFE5E37B73@oracle.com> <552344DB-477E-41AF-96ED-249DF39B3843@oracle.com> <2F944251-FF22-41E6-BB6A-730F8B1CC1AE@oracle.com> Message-ID: <75B71AD3-6ED9-478F-85EB-6C467644B1D1@oracle.com> Looks ok. igor > On May 18, 2016, at 2:35 PM, Doug Simon wrote: > > I made one last minor change to improve the javadoc for MemoryAccessProvider.readObjectConstant: > > @@ -59,7 +59,9 @@ > * > * @param base the base address from which the value is read > * @param displacement the displacement within the object in bytes > - * @return the read value encapsulated in a {@link Constant} object > + * @return the read value encapsulated in a {@link Constant} object or {@code null} if the > + * address computed from {@code base} and {@code displacement} does not denote a > + * location holding an {@code Object} value > */ > JavaConstant readObjectConstant(Constant base, long displacement); > } > > If that looks ok, then Tom will integrate the webrev. > > -Doug > >> On 17 May 2016, at 19:59, Igor Veresov wrote: >> >> Looks good. >> >> igor >> >>> On May 17, 2016, at 5:53 AM, Doug Simon wrote: >>> >>> I had forgotten to re-apply the removal of UnsafeUtil from https://bugs.openjdk.java.net/browse/JDK-8156759 to 8156835. I?ve applied it now and updated the webrev. >>> >>>> On 13 May 2016, at 21:54, Doug Simon wrote: >>>> >>>> >>>>> On 13 May 2016, at 18:21, Igor Veresov wrote: >>>>> >>>>> Looks ok >>>> >>>> Thanks for the review. >>>> >>>> -Doug >>>> >>>>>> On May 13, 2016, at 4:40 AM, Doug Simon wrote: >>>>>> >>>>>> Please review this RFE that makes minor changes to clean up and minimize JVMCI. >>>>>> >>>>>> All jtreg tests pass as do all Graal tests. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8156835 >>>>>> http://cr.openjdk.java.net/~dnsimon/8156835 >>>>>> >>>>>> -Doug >>>>> >>>> >>> >> > From vivek.r.deshpande at intel.com Wed May 18 22:26:56 2016 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Wed, 18 May 2016 22:26:56 +0000 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <57162A88.7030608@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D924@ORSMSX106.amr.corp.intel.com> <62c7df4e-d9ed-8d72-6335-1de307fc6e08@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DAC6@ORSMSX106.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DD39@ORSMSX106.amr.corp.intel.com> Hi Vladimir I have the latest webrev with suggested changes here: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.04/ Could you please take a look at it. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, May 18, 2016 12:41 PM To: Deshpande, Vivek R Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics Okay, convert it to bug saying that -XX:DisableIntrinsic does not disable intrinsic in Interpreter. Which can lead to results inconsistencies since different code is used in compiled code and Interpreter. Thanks, Vladimir On 5/18/16 12:36 PM, Deshpande, Vivek R wrote: > HI Vladimir > > We can convert it to bug. > With the change, using -XX:DisableIntrinsic=_dexp, will not generate the LIBM stub and all the calls will point to SharedRuntime::dexp correctly with stack adjustment. > Currently with -XX:DisableIntrinsic=_dexp, stub gets generated and points to LIBM stub in interpreter. > and just using option UseLibmIntrinsic to disable LIBM usage fails without stack adjustment for 64 bit. > I can make changes for 32 bit in updated webrev. > > Regards, > Vivek > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, May 18, 2016 12:24 PM > To: Deshpande, Vivek R > Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > First, 8154473 is RFE and we are post FC (feature complete). We have to wait until the process of RFEs approval is finalized. > > Or we can convert it to bug. Can you say what happens with current code if -XX:DisableIntrinsic=_dexp is used, for example? And what will happen after these changes? > > I don't see changes for: > templateInterpreterGenerator_x86_32.cpp > > It would be better to have similar code there even if 32-bit code does not have stack problem. > > > You did not implemented what Chris was asked: > > > a) Add a method in MacroAssembler to call > MacroAssembler::call_VM_leaf_base (what you did) or > > > >b) Add InterpreterMacroAssembler::call_VM_leaf and change > MacroAssembler::call_VM_leaf to do: > > > > void MacroAssembler::call_VM_leaf(address entry_point, int > number_of_arguments) { > > MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); > > } > > I would suggest an other method > > // Use this method when MacroAssembler version of call_VM_leaf_base() > should be called. > void MacroAssembler::call_VM_leaf0(address entry_point) { > MacroAssembler::call_VM_leaf_base(entry_point, 0); > } > > Thanks, > Vladimir > > On 5/18/16 11:27 AM, Deshpande, Vivek R wrote: >> Hi Vladimir >> >> The latest webrev is here: >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ >> The bug ID for the same is: >> https://bugs.openjdk.java.net/browse/JDK-8154473 >> >> Thanks for looking into it. >> >> Regards, >> Vivek >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, May 18, 2016 11:04 AM >> To: Deshpande, Vivek R >> Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime >> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics >> >> Hi Vivek, >> >> Can you send link to latest webrev? The thread is long and it is not clear which webrev is final. >> >> Thanks, >> Vladimir >> >> On 5/18/16 10:36 AM, Deshpande, Vivek R wrote: >>> >>> >>> Hi Vladimir >>> >>> >>> >>> Could you please review and sponsor this patch with the current solution. >>> >>> This patch calls correct fallback version for LIBM methods when LIBM >>> is disabled. >>> >>> >>> >>> Regards, >>> >>> Vivek >>> >>> >>> >>> >>> >>> >>> >>> *From:*Deshpande, Vivek R >>> *Sent:* Tuesday, May 10, 2016 11:00 AM >>> *To:* 'Christian Thalinger' >>> *Cc:* Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; >>> hotspot-runtime-dev at openjdk.java.net runtime >>> *Subject:* RE: RFR (S): 8154473: Update for CompilerDirectives to >>> control stub generation and intrinsics >>> >>> >>> >>> HI Christian >>> >>> >>> >>> We have not heard from runtime team regarding this change. >>> >>> Shall we go ahead with the current solution ? >>> >>> I can send out the latest webrev. >>> >>> Let me know your thoughts. >>> >>> >>> >>> Regards, >>> >>> Vivek >>> >>> >>> >>> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> *Sent:* Monday, May 02, 2016 3:44 PM >>> *To:* Deshpande, Vivek R >>> *Cc:* Viswanathan, Sandhya; hotspot compiler; >>> hotspot-runtime-dev at openjdk.java.net >>> runtime >>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>> control stub generation and intrinsics >>> >>> >>> >>> >>> >>> On May 2, 2016, at 11:53 AM, Deshpande, Vivek R >>> > >>> wrote: >>> >>> >>> >>> Hi Christian >>> >>> >>> >>> I had tried using call_VM_leaf() which you mentioned. >>> >>> >>> >>> But this function >>> >>> >>> >>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>> { >>> >>> call_VM_leaf_base(entry_point, number_of_arguments); >>> >>> } >>> >>> >>> >>> ends up calling >>> >>> >>> >>> void InterpreterMacroAssembler::call_VM_leaf_base(address >>> entry_point, >>> >>> int number_of_arguments) >>> { ... >>> >>> from interp_masm_x86.cpp instead of >>> >>> >>> >>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>> { ? >>> >>> >>> >>> Frankly, I didn?t know that there is an overload for call_VM_leaf_base >>> in InterpreterMacroAssembler. So this means there are two options: >>> >>> >>> >>> a) Add a method in MacroAssembler to call >>> MacroAssembler::call_VM_leaf_base (what you did) or >>> >>> >>> >>> b) Add InterpreterMacroAssembler::call_VM_leaf and change >>> MacroAssembler::call_VM_leaf to do: >>> >>> >>> >>> voidMacroAssembler::call_VM_leaf(address entry_point, int >>> number_of_arguments) { >>> >>> MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); >>> >>> } >>> >>> >>> >>> I will let the runtime team decide. >>> >>> >>> >>> >>> >>> So I had put mathfunc() to call the masm version of call_VM_leaf_base(). >>> >>> >>> >>> Let me know what you think. >>> >>> >>> >>> Thanks and regards, >>> Vivek >>> >>> >>> >>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> *Sent:* Monday, May 02, 2016 1:50 PM >>> *To:* Deshpande, Vivek R >>> *Cc:* hotspot-compiler-dev at openjdk.java.net >>> >>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>> control stub generation and intrinsics >>> >>> >>> >>> >>> >>> On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R >>> >> > wrote: >>> >>> >>> >>> Hi Christian >>> >>> >>> >>> I have updated the webrev and link for the same is here: >>> >>> >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>> ev.03/ >>> >>> I am using mathfunc() to call the masm version of >>> call_VM_leaf_base() and not the InterpreterMacroAssembler version. >>> >>> >>> >>> That?s better but, again, there is nothing math-y about this method: >>> >>> ! void MacroAssembler::mathfunc(address runtime_entry) { >>> >>> MacroAssembler::call_VM_leaf_base(runtime_entry, 0); >>> >>> } >>> >>> Also, there is this method: >>> >>> >>> >>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>> { >>> >>> call_VM_leaf_base(entry_point, number_of_arguments); >>> >>> } >>> >>> >>> >>> which has: >>> >>> >>> >>> void call_VM_leaf(address entry_point, >>> >>> int number_of_arguments = 0); >>> >>> >>> >>> Get rid of mathfunc completely and use call_VM_leaf directly. >>> >>> >>> >>> >>> >>> Regards, >>> >>> Vivek >>> >>> >>> >>> >>> >>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> *Sent:* Thursday, April 21, 2016 2:35 PM >>> *To:* Deshpande, Vivek R >> > >>> *Cc:* Nils Eliasson >> >; hotspot-compiler-dev at openjdk.java.net >>> ; Vladimir Kozlov >>> > >>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives >>> to control stub generation and intrinsics >>> >>> >>> >>> >>> >>> On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R >>> >> > wrote: >>> >>> >>> >>> Hi >>> >>> >>> >>> The correct URL for the updated webrev is this. >>> >>> >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>> ev.02/ >>> >>> >>> >>> +void MacroAssembler::mathfunc(address runtime_entry) { >>> >>> I don?t like the name of this method. Mainly because it?s only >>> aligning the stack (shouldn?t that happen somewhere else?) and >>> doing this 0x20 stack frame thing which I still don?t understand. >>> >>> >>> >>> Right, this is the one I was thinking about: >>> >>> >>> >>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>> { >>> >>> >>> >>> >>> Sorry for the spam. >>> >>> >>> >>> Regards, >>> >>> Vivek >>> >>> >>> >>> *From:* Deshpande, Vivek R >>> *Sent:* Wednesday, April 20, 2016 5:10 PM >>> *To:* Deshpande, Vivek R; 'Nils Eliasson'; >>> 'hotspot-compiler-dev at openjdk.java.net >>> ' >>> *Cc:* 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian >>> Thalinger'; Viswanathan, Sandhya >>> *Subject:* RE: RFR (S): 8154473: Update for >>> CompilerDirectives to control stub generation and >>> intrinsics >>> >>> >>> >>> Sent out the wrong link by mistake. >>> >>> >>> >>> updated webrev: >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ >>> >>> >> rev.01/> >>> >>> >>> >>> Regards >>> >>> Vivek >>> >>> >>> >>> >>> >>> *From:* Deshpande, Vivek R >>> *Sent:* Wednesday, April 20, 2016 5:07 PM >>> *To:* 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net >>> >>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>> Viswanathan, Sandhya >>> *Subject:* RE: RFR (S): 8154473: Update for >>> CompilerDirectives to control stub generation and >>> intrinsics >>> >>> >>> >>> Hi Nils >>> >>> >>> >>> I have updated the webrev with all the suggestions. >>> >>> updated webrev: >>> >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>> ev.01/ >>> >>> Thanks for your comments and review. >>> >>> >>> >>> @Vladimir, >>> >>> I have taken care of all the comments. Would you please >>> review and sponsor the patch. >>> >>> >>> >>> Thanks and regards, >>> >>> Vivek >>> >>> >>> >>> *From:* Nils Eliasson [mailto:nils.eliasson at oracle.com] >>> *Sent:* Wednesday, April 20, 2016 12:27 PM >>> *To:* Deshpande, Vivek >>> R; hotspot-compiler-dev at openjdk.java.net >>> >>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>> Viswanathan, Sandhya >>> *Subject:* Re: RFR (S): 8154473: Update for >>> CompilerDirectives to control stub generation and >>> intrinsics >>> >>> >>> >>> In vmSymbols.cpp together with the other flag checks. >>> >>> Regards, >>> Nils >>> >>> On 2016-04-20 02:44, Deshpande, Vivek R wrote: >>> >>> HI Nils >>> >>> >>> >>> Yes you are right the function accesses the command line >>> flag DisableIntrinsic and changes are static. >>> >>> Could you point me the right location for the function ? >>> >>> Also I have updated the webrev with rest of the comments >>> here: >>> >>> >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>> ev.01/ >>> >>> >>> >>> Regards, >>> >>> Vivek >>> >>> >>> >>> *From:* hotspot-compiler-dev >>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]*On Behalf >>> Of *Nils Eliasson >>> *Sent:* Tuesday, April 19, 2016 5:55 AM >>> *To:* hotspot-compiler-dev at openjdk.java.net >>> >>> *Subject:* Re: RFR (S): 8154473: Update for >>> CompilerDirectives to control stub generation and >>> intrinsics >>> >>> >>> >>> Hi Vivek, >>> >>> The changes in is_intrinsic_disabled in >>> compilerDirectives.* are static and only access the >>> command line flag DisableIntrinsics. As long as stubs >>> are only generated during startup and don't have a >>> method context - that is ok - but it doesn't belong in >>> the compilerDirectives-files if it doens't use directives. >>> >>> Regards, >>> Nils >>> >>> On 2016-04-18 19:38, Deshpande, Vivek R wrote: >>> >>> Hi all >>> >>> >>> >>> I would like to contribute a patch which helps to >>> control the intrinsics in interpreter, c1 and c2 by >>> disabling the stub generation. >>> >>> This uses -XX:DisableIntrinsic option to achieve the >>> same. >>> >>> Could you please review and sponsor this patch. >>> >>> >>> >>> Bug-id: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>> webrev: >>> >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ >>> >>> >> ebrev.00/> >>> >>> >>> >>> Thanks and regards, >>> >>> Vivek >>> >>> >>> From vladimir.kozlov at oracle.com Wed May 18 23:18:16 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 May 2016 16:18:16 -0700 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DD39@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D924@ORSMSX106.amr.corp.intel.com> <62c7df4e-d9ed-8d72-6335-1de307fc6e08@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DAC6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DD39@ORSMSX106.amr.corp.intel.com> Message-ID: <30495ce0-7899-184d-2953-9ad682ab0978@oracle.com> You are still using mathfunc(). Vladimir On 5/18/16 3:26 PM, Deshpande, Vivek R wrote: > Hi Vladimir > > I have the latest webrev with suggested changes here: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.04/ > Could you please take a look at it. > > Regards, > Vivek > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, May 18, 2016 12:41 PM > To: Deshpande, Vivek R > Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > Okay, convert it to bug saying that -XX:DisableIntrinsic does not > disable intrinsic in Interpreter. Which can lead to results > inconsistencies since different code is used in compiled code and > Interpreter. > > Thanks, > Vladimir > > On 5/18/16 12:36 PM, Deshpande, Vivek R wrote: >> HI Vladimir >> >> We can convert it to bug. >> With the change, using -XX:DisableIntrinsic=_dexp, will not generate the LIBM stub and all the calls will point to SharedRuntime::dexp correctly with stack adjustment. >> Currently with -XX:DisableIntrinsic=_dexp, stub gets generated and points to LIBM stub in interpreter. >> and just using option UseLibmIntrinsic to disable LIBM usage fails without stack adjustment for 64 bit. >> I can make changes for 32 bit in updated webrev. >> >> Regards, >> Vivek >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, May 18, 2016 12:24 PM >> To: Deshpande, Vivek R >> Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime >> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics >> >> First, 8154473 is RFE and we are post FC (feature complete). We have to wait until the process of RFEs approval is finalized. >> >> Or we can convert it to bug. Can you say what happens with current code if -XX:DisableIntrinsic=_dexp is used, for example? And what will happen after these changes? >> >> I don't see changes for: >> templateInterpreterGenerator_x86_32.cpp >> >> It would be better to have similar code there even if 32-bit code does not have stack problem. >> >> >> You did not implemented what Chris was asked: >> >> > a) Add a method in MacroAssembler to call >> MacroAssembler::call_VM_leaf_base (what you did) or >> > >> >b) Add InterpreterMacroAssembler::call_VM_leaf and change >> MacroAssembler::call_VM_leaf to do: >> > >> > void MacroAssembler::call_VM_leaf(address entry_point, int >> number_of_arguments) { >> > MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); >> > } >> >> I would suggest an other method >> >> // Use this method when MacroAssembler version of call_VM_leaf_base() >> should be called. >> void MacroAssembler::call_VM_leaf0(address entry_point) { >> MacroAssembler::call_VM_leaf_base(entry_point, 0); >> } >> >> Thanks, >> Vladimir >> >> On 5/18/16 11:27 AM, Deshpande, Vivek R wrote: >>> Hi Vladimir >>> >>> The latest webrev is here: >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.03/ >>> The bug ID for the same is: >>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>> >>> Thanks for looking into it. >>> >>> Regards, >>> Vivek >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Wednesday, May 18, 2016 11:04 AM >>> To: Deshpande, Vivek R >>> Cc: Viswanathan, Sandhya; hotspot compiler; hotspot-runtime-dev at openjdk.java.net runtime >>> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics >>> >>> Hi Vivek, >>> >>> Can you send link to latest webrev? The thread is long and it is not clear which webrev is final. >>> >>> Thanks, >>> Vladimir >>> >>> On 5/18/16 10:36 AM, Deshpande, Vivek R wrote: >>>> >>>> >>>> Hi Vladimir >>>> >>>> >>>> >>>> Could you please review and sponsor this patch with the current solution. >>>> >>>> This patch calls correct fallback version for LIBM methods when LIBM >>>> is disabled. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From:*Deshpande, Vivek R >>>> *Sent:* Tuesday, May 10, 2016 11:00 AM >>>> *To:* 'Christian Thalinger' >>>> *Cc:* Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; >>>> hotspot-runtime-dev at openjdk.java.net runtime >>>> *Subject:* RE: RFR (S): 8154473: Update for CompilerDirectives to >>>> control stub generation and intrinsics >>>> >>>> >>>> >>>> HI Christian >>>> >>>> >>>> >>>> We have not heard from runtime team regarding this change. >>>> >>>> Shall we go ahead with the current solution ? >>>> >>>> I can send out the latest webrev. >>>> >>>> Let me know your thoughts. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> *Sent:* Monday, May 02, 2016 3:44 PM >>>> *To:* Deshpande, Vivek R >>>> *Cc:* Viswanathan, Sandhya; hotspot compiler; >>>> hotspot-runtime-dev at openjdk.java.net >>>> runtime >>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>>> control stub generation and intrinsics >>>> >>>> >>>> >>>> >>>> >>>> On May 2, 2016, at 11:53 AM, Deshpande, Vivek R >>>> > >>>> wrote: >>>> >>>> >>>> >>>> Hi Christian >>>> >>>> >>>> >>>> I had tried using call_VM_leaf() which you mentioned. >>>> >>>> >>>> >>>> But this function >>>> >>>> >>>> >>>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>>> { >>>> >>>> call_VM_leaf_base(entry_point, number_of_arguments); >>>> >>>> } >>>> >>>> >>>> >>>> ends up calling >>>> >>>> >>>> >>>> void InterpreterMacroAssembler::call_VM_leaf_base(address >>>> entry_point, >>>> >>>> int number_of_arguments) >>>> { ... >>>> >>>> from interp_masm_x86.cpp instead of >>>> >>>> >>>> >>>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>>> { ? >>>> >>>> >>>> >>>> Frankly, I didn?t know that there is an overload for call_VM_leaf_base >>>> in InterpreterMacroAssembler. So this means there are two options: >>>> >>>> >>>> >>>> a) Add a method in MacroAssembler to call >>>> MacroAssembler::call_VM_leaf_base (what you did) or >>>> >>>> >>>> >>>> b) Add InterpreterMacroAssembler::call_VM_leaf and change >>>> MacroAssembler::call_VM_leaf to do: >>>> >>>> >>>> >>>> voidMacroAssembler::call_VM_leaf(address entry_point, int >>>> number_of_arguments) { >>>> >>>> MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); >>>> >>>> } >>>> >>>> >>>> >>>> I will let the runtime team decide. >>>> >>>> >>>> >>>> >>>> >>>> So I had put mathfunc() to call the masm version of call_VM_leaf_base(). >>>> >>>> >>>> >>>> Let me know what you think. >>>> >>>> >>>> >>>> Thanks and regards, >>>> Vivek >>>> >>>> >>>> >>>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> *Sent:* Monday, May 02, 2016 1:50 PM >>>> *To:* Deshpande, Vivek R >>>> *Cc:* hotspot-compiler-dev at openjdk.java.net >>>> >>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>>> control stub generation and intrinsics >>>> >>>> >>>> >>>> >>>> >>>> On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R >>>> >>> > wrote: >>>> >>>> >>>> >>>> Hi Christian >>>> >>>> >>>> >>>> I have updated the webrev and link for the same is here: >>>> >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>>> ev.03/ >>>> >>>> I am using mathfunc() to call the masm version of >>>> call_VM_leaf_base() and not the InterpreterMacroAssembler version. >>>> >>>> >>>> >>>> That?s better but, again, there is nothing math-y about this method: >>>> >>>> ! void MacroAssembler::mathfunc(address runtime_entry) { >>>> >>>> MacroAssembler::call_VM_leaf_base(runtime_entry, 0); >>>> >>>> } >>>> >>>> Also, there is this method: >>>> >>>> >>>> >>>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>>> { >>>> >>>> call_VM_leaf_base(entry_point, number_of_arguments); >>>> >>>> } >>>> >>>> >>>> >>>> which has: >>>> >>>> >>>> >>>> void call_VM_leaf(address entry_point, >>>> >>>> int number_of_arguments = 0); >>>> >>>> >>>> >>>> Get rid of mathfunc completely and use call_VM_leaf directly. >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> >>>> >>>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> *Sent:* Thursday, April 21, 2016 2:35 PM >>>> *To:* Deshpande, Vivek R >>> > >>>> *Cc:* Nils Eliasson >>> >; hotspot-compiler-dev at openjdk.java.net >>>> ; Vladimir Kozlov >>>> > >>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives >>>> to control stub generation and intrinsics >>>> >>>> >>>> >>>> >>>> >>>> On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R >>>> >>> > wrote: >>>> >>>> >>>> >>>> Hi >>>> >>>> >>>> >>>> The correct URL for the updated webrev is this. >>>> >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>>> ev.02/ >>>> >>>> >>>> >>>> +void MacroAssembler::mathfunc(address runtime_entry) { >>>> >>>> I don?t like the name of this method. Mainly because it?s only >>>> aligning the stack (shouldn?t that happen somewhere else?) and >>>> doing this 0x20 stack frame thing which I still don?t understand. >>>> >>>> >>>> >>>> Right, this is the one I was thinking about: >>>> >>>> >>>> >>>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>>> { >>>> >>>> >>>> >>>> >>>> Sorry for the spam. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> *From:* Deshpande, Vivek R >>>> *Sent:* Wednesday, April 20, 2016 5:10 PM >>>> *To:* Deshpande, Vivek R; 'Nils Eliasson'; >>>> 'hotspot-compiler-dev at openjdk.java.net >>>> ' >>>> *Cc:* 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian >>>> Thalinger'; Viswanathan, Sandhya >>>> *Subject:* RE: RFR (S): 8154473: Update for >>>> CompilerDirectives to control stub generation and >>>> intrinsics >>>> >>>> >>>> >>>> Sent out the wrong link by mistake. >>>> >>>> >>>> >>>> updated webrev: >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.02/ >>>> >>>> >>> rev.01/> >>>> >>>> >>>> >>>> Regards >>>> >>>> Vivek >>>> >>>> >>>> >>>> >>>> >>>> *From:* Deshpande, Vivek R >>>> *Sent:* Wednesday, April 20, 2016 5:07 PM >>>> *To:* 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net >>>> >>>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>>> Viswanathan, Sandhya >>>> *Subject:* RE: RFR (S): 8154473: Update for >>>> CompilerDirectives to control stub generation and >>>> intrinsics >>>> >>>> >>>> >>>> Hi Nils >>>> >>>> >>>> >>>> I have updated the webrev with all the suggestions. >>>> >>>> updated webrev: >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>>> ev.01/ >>>> >>>> Thanks for your comments and review. >>>> >>>> >>>> >>>> @Vladimir, >>>> >>>> I have taken care of all the comments. Would you please >>>> review and sponsor the patch. >>>> >>>> >>>> >>>> Thanks and regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> *From:* Nils Eliasson [mailto:nils.eliasson at oracle.com] >>>> *Sent:* Wednesday, April 20, 2016 12:27 PM >>>> *To:* Deshpande, Vivek >>>> R; hotspot-compiler-dev at openjdk.java.net >>>> >>>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>>> Viswanathan, Sandhya >>>> *Subject:* Re: RFR (S): 8154473: Update for >>>> CompilerDirectives to control stub generation and >>>> intrinsics >>>> >>>> >>>> >>>> In vmSymbols.cpp together with the other flag checks. >>>> >>>> Regards, >>>> Nils >>>> >>>> On 2016-04-20 02:44, Deshpande, Vivek R wrote: >>>> >>>> HI Nils >>>> >>>> >>>> >>>> Yes you are right the function accesses the command line >>>> flag DisableIntrinsic and changes are static. >>>> >>>> Could you point me the right location for the function ? >>>> >>>> Also I have updated the webrev with rest of the comments >>>> here: >>>> >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >>>> ev.01/ >>>> >>>> >>>> >>>> Regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> *From:* hotspot-compiler-dev >>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]*On Behalf >>>> Of *Nils Eliasson >>>> *Sent:* Tuesday, April 19, 2016 5:55 AM >>>> *To:* hotspot-compiler-dev at openjdk.java.net >>>> >>>> *Subject:* Re: RFR (S): 8154473: Update for >>>> CompilerDirectives to control stub generation and >>>> intrinsics >>>> >>>> >>>> >>>> Hi Vivek, >>>> >>>> The changes in is_intrinsic_disabled in >>>> compilerDirectives.* are static and only access the >>>> command line flag DisableIntrinsics. As long as stubs >>>> are only generated during startup and don't have a >>>> method context - that is ok - but it doesn't belong in >>>> the compilerDirectives-files if it doens't use directives. >>>> >>>> Regards, >>>> Nils >>>> >>>> On 2016-04-18 19:38, Deshpande, Vivek R wrote: >>>> >>>> Hi all >>>> >>>> >>>> >>>> I would like to contribute a patch which helps to >>>> control the intrinsics in interpreter, c1 and c2 by >>>> disabling the stub generation. >>>> >>>> This uses -XX:DisableIntrinsic option to achieve the >>>> same. >>>> >>>> Could you please review and sponsor this patch. >>>> >>>> >>>> >>>> Bug-id: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>>> webrev: >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.00/ >>>> >>>> >>> ebrev.00/> >>>> >>>> >>>> >>>> Thanks and regards, >>>> >>>> Vivek >>>> >>>> >>>> From vivek.r.deshpande at intel.com Wed May 18 23:22:42 2016 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Wed, 18 May 2016 23:22:42 +0000 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <30495ce0-7899-184d-2953-9ad682ab0978@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A828A2@ORSMSX106.amr.corp.intel.com> <5717D7E8.5000108@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A84884@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D924@ORSMSX106.amr.corp.intel.com> <62c7df4e-d9ed-8d72-6335-1de307fc6e08@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DAC6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DD39@ORSMSX106.amr.corp.intel.com> <30495ce0-7899-184d-2953-9ad682ab0978@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DE0E@ORSMSX106.amr.corp.intel.com> HI Vladimir I need to call masm version of call_VM_leaf_base(). Using following from templateInterpreter_x86_64/32.cpp void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { call_VM_leaf_base(entry_point, number_of_arguments); } ends up calling void InterpreterMacroAssembler::call_VM_leaf_base(address entry_point, int number_of_arguments) { ... from interp_masm_x86.cpp instead of void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { ... So I had put mathfunc() to call the masm version of call_VM_leaf_base(). Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, May 18, 2016 4:18 PM To: Deshpande, Vivek R Cc: Viswanathan, Sandhya; hotspot compiler Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics You are still using mathfunc(). Vladimir On 5/18/16 3:26 PM, Deshpande, Vivek R wrote: > Hi Vladimir > > I have the latest webrev with suggested changes here: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr > ev.04/ > Could you please take a look at it. > > Regards, > Vivek > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, May 18, 2016 12:41 PM > To: Deshpande, Vivek R > Cc: Viswanathan, Sandhya; hotspot compiler; > hotspot-runtime-dev at openjdk.java.net runtime > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to > control stub generation and intrinsics > > Okay, convert it to bug saying that -XX:DisableIntrinsic does not > disable intrinsic in Interpreter. Which can lead to results > inconsistencies since different code is used in compiled code and > Interpreter. > > Thanks, > Vladimir > > On 5/18/16 12:36 PM, Deshpande, Vivek R wrote: >> HI Vladimir >> >> We can convert it to bug. >> With the change, using -XX:DisableIntrinsic=_dexp, will not generate the LIBM stub and all the calls will point to SharedRuntime::dexp correctly with stack adjustment. >> Currently with -XX:DisableIntrinsic=_dexp, stub gets generated and points to LIBM stub in interpreter. >> and just using option UseLibmIntrinsic to disable LIBM usage fails without stack adjustment for 64 bit. >> I can make changes for 32 bit in updated webrev. >> >> Regards, >> Vivek >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, May 18, 2016 12:24 PM >> To: Deshpande, Vivek R >> Cc: Viswanathan, Sandhya; hotspot compiler; >> hotspot-runtime-dev at openjdk.java.net runtime >> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >> control stub generation and intrinsics >> >> First, 8154473 is RFE and we are post FC (feature complete). We have to wait until the process of RFEs approval is finalized. >> >> Or we can convert it to bug. Can you say what happens with current code if -XX:DisableIntrinsic=_dexp is used, for example? And what will happen after these changes? >> >> I don't see changes for: >> templateInterpreterGenerator_x86_32.cpp >> >> It would be better to have similar code there even if 32-bit code does not have stack problem. >> >> >> You did not implemented what Chris was asked: >> >> > a) Add a method in MacroAssembler to call >> MacroAssembler::call_VM_leaf_base (what you did) or > >> >b) Add InterpreterMacroAssembler::call_VM_leaf and change >> MacroAssembler::call_VM_leaf to do: >> > >> > void MacroAssembler::call_VM_leaf(address entry_point, int >> number_of_arguments) { >> > MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); >> > } >> >> I would suggest an other method >> >> // Use this method when MacroAssembler version of call_VM_leaf_base() >> should be called. >> void MacroAssembler::call_VM_leaf0(address entry_point) { >> MacroAssembler::call_VM_leaf_base(entry_point, 0); } >> >> Thanks, >> Vladimir >> >> On 5/18/16 11:27 AM, Deshpande, Vivek R wrote: >>> Hi Vladimir >>> >>> The latest webrev is here: >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/we >>> brev.03/ >>> The bug ID for the same is: >>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>> >>> Thanks for looking into it. >>> >>> Regards, >>> Vivek >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Wednesday, May 18, 2016 11:04 AM >>> To: Deshpande, Vivek R >>> Cc: Viswanathan, Sandhya; hotspot compiler; >>> hotspot-runtime-dev at openjdk.java.net runtime >>> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >>> control stub generation and intrinsics >>> >>> Hi Vivek, >>> >>> Can you send link to latest webrev? The thread is long and it is not clear which webrev is final. >>> >>> Thanks, >>> Vladimir >>> >>> On 5/18/16 10:36 AM, Deshpande, Vivek R wrote: >>>> >>>> >>>> Hi Vladimir >>>> >>>> >>>> >>>> Could you please review and sponsor this patch with the current solution. >>>> >>>> This patch calls correct fallback version for LIBM methods when >>>> LIBM is disabled. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From:*Deshpande, Vivek R >>>> *Sent:* Tuesday, May 10, 2016 11:00 AM >>>> *To:* 'Christian Thalinger' >>>> *Cc:* Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; >>>> hotspot-runtime-dev at openjdk.java.net runtime >>>> *Subject:* RE: RFR (S): 8154473: Update for CompilerDirectives to >>>> control stub generation and intrinsics >>>> >>>> >>>> >>>> HI Christian >>>> >>>> >>>> >>>> We have not heard from runtime team regarding this change. >>>> >>>> Shall we go ahead with the current solution ? >>>> >>>> I can send out the latest webrev. >>>> >>>> Let me know your thoughts. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> *Sent:* Monday, May 02, 2016 3:44 PM >>>> *To:* Deshpande, Vivek R >>>> *Cc:* Viswanathan, Sandhya; hotspot compiler; >>>> hotspot-runtime-dev at openjdk.java.net >>>> runtime >>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>>> control stub generation and intrinsics >>>> >>>> >>>> >>>> >>>> >>>> On May 2, 2016, at 11:53 AM, Deshpande, Vivek R >>>> > >>>> wrote: >>>> >>>> >>>> >>>> Hi Christian >>>> >>>> >>>> >>>> I had tried using call_VM_leaf() which you mentioned. >>>> >>>> >>>> >>>> But this function >>>> >>>> >>>> >>>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>>> { >>>> >>>> call_VM_leaf_base(entry_point, number_of_arguments); >>>> >>>> } >>>> >>>> >>>> >>>> ends up calling >>>> >>>> >>>> >>>> void InterpreterMacroAssembler::call_VM_leaf_base(address >>>> entry_point, >>>> >>>> int number_of_arguments) >>>> { ... >>>> >>>> from interp_masm_x86.cpp instead of >>>> >>>> >>>> >>>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>>> { ? >>>> >>>> >>>> >>>> Frankly, I didn?t know that there is an overload for >>>> call_VM_leaf_base in InterpreterMacroAssembler. So this means there are two options: >>>> >>>> >>>> >>>> a) Add a method in MacroAssembler to call >>>> MacroAssembler::call_VM_leaf_base (what you did) or >>>> >>>> >>>> >>>> b) Add InterpreterMacroAssembler::call_VM_leaf and change >>>> MacroAssembler::call_VM_leaf to do: >>>> >>>> >>>> >>>> voidMacroAssembler::call_VM_leaf(address entry_point, int >>>> number_of_arguments) { >>>> >>>> MacroAssembler::call_VM_leaf_base(entry_point, >>>> number_of_arguments); >>>> >>>> } >>>> >>>> >>>> >>>> I will let the runtime team decide. >>>> >>>> >>>> >>>> >>>> >>>> So I had put mathfunc() to call the masm version of call_VM_leaf_base(). >>>> >>>> >>>> >>>> Let me know what you think. >>>> >>>> >>>> >>>> Thanks and regards, >>>> Vivek >>>> >>>> >>>> >>>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> *Sent:* Monday, May 02, 2016 1:50 PM >>>> *To:* Deshpande, Vivek R >>>> *Cc:* hotspot-compiler-dev at openjdk.java.net >>>> >>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>>> control stub generation and intrinsics >>>> >>>> >>>> >>>> >>>> >>>> On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R >>>> >>> > wrote: >>>> >>>> >>>> >>>> Hi Christian >>>> >>>> >>>> >>>> I have updated the webrev and link for the same is here: >>>> >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>> ebr >>>> ev.03/ >>>> >>>> I am using mathfunc() to call the masm version of >>>> call_VM_leaf_base() and not the InterpreterMacroAssembler version. >>>> >>>> >>>> >>>> That?s better but, again, there is nothing math-y about this method: >>>> >>>> ! void MacroAssembler::mathfunc(address runtime_entry) { >>>> >>>> MacroAssembler::call_VM_leaf_base(runtime_entry, 0); >>>> >>>> } >>>> >>>> Also, there is this method: >>>> >>>> >>>> >>>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>>> { >>>> >>>> call_VM_leaf_base(entry_point, number_of_arguments); >>>> >>>> } >>>> >>>> >>>> >>>> which has: >>>> >>>> >>>> >>>> void call_VM_leaf(address entry_point, >>>> >>>> int number_of_arguments = 0); >>>> >>>> >>>> >>>> Get rid of mathfunc completely and use call_VM_leaf directly. >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> >>>> >>>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> *Sent:* Thursday, April 21, 2016 2:35 PM >>>> *To:* Deshpande, Vivek R >>> > >>>> *Cc:* Nils Eliasson >>> >; hotspot-compiler-dev at openjdk.java.net >>>> ; Vladimir Kozlov >>>> > >>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives >>>> to control stub generation and intrinsics >>>> >>>> >>>> >>>> >>>> >>>> On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R >>>> >>> > wrote: >>>> >>>> >>>> >>>> Hi >>>> >>>> >>>> >>>> The correct URL for the updated webrev is this. >>>> >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>> ebr >>>> ev.02/ >>>> >>>> >>>> >>>> +void MacroAssembler::mathfunc(address runtime_entry) { >>>> >>>> I don?t like the name of this method. Mainly because it?s only >>>> aligning the stack (shouldn?t that happen somewhere else?) and >>>> doing this 0x20 stack frame thing which I still don?t understand. >>>> >>>> >>>> >>>> Right, this is the one I was thinking about: >>>> >>>> >>>> >>>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>>> { >>>> >>>> >>>> >>>> >>>> Sorry for the spam. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> *From:* Deshpande, Vivek R >>>> *Sent:* Wednesday, April 20, 2016 5:10 PM >>>> *To:* Deshpande, Vivek R; 'Nils Eliasson'; >>>> 'hotspot-compiler-dev at openjdk.java.net >>>> ' >>>> *Cc:* 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian >>>> Thalinger'; Viswanathan, Sandhya >>>> *Subject:* RE: RFR (S): 8154473: Update for >>>> CompilerDirectives to control stub generation and >>>> intrinsics >>>> >>>> >>>> >>>> Sent out the wrong link by mistake. >>>> >>>> >>>> >>>> updated webrev: >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>> ebrev.02/ >>>> >>>> >>> web >>>> rev.01/> >>>> >>>> >>>> >>>> Regards >>>> >>>> Vivek >>>> >>>> >>>> >>>> >>>> >>>> *From:* Deshpande, Vivek R >>>> *Sent:* Wednesday, April 20, 2016 5:07 PM >>>> *To:* 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net >>>> >>>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>>> Viswanathan, Sandhya >>>> *Subject:* RE: RFR (S): 8154473: Update for >>>> CompilerDirectives to control stub generation and >>>> intrinsics >>>> >>>> >>>> >>>> Hi Nils >>>> >>>> >>>> >>>> I have updated the webrev with all the suggestions. >>>> >>>> updated webrev: >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>> ebr >>>> ev.01/ >>>> >>>> Thanks for your comments and review. >>>> >>>> >>>> >>>> @Vladimir, >>>> >>>> I have taken care of all the comments. Would you please >>>> review and sponsor the patch. >>>> >>>> >>>> >>>> Thanks and regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> *From:* Nils Eliasson [mailto:nils.eliasson at oracle.com] >>>> *Sent:* Wednesday, April 20, 2016 12:27 PM >>>> *To:* Deshpande, Vivek >>>> R; hotspot-compiler-dev at openjdk.java.net >>>> >>>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>>> Viswanathan, Sandhya >>>> *Subject:* Re: RFR (S): 8154473: Update for >>>> CompilerDirectives to control stub generation and >>>> intrinsics >>>> >>>> >>>> >>>> In vmSymbols.cpp together with the other flag checks. >>>> >>>> Regards, >>>> Nils >>>> >>>> On 2016-04-20 02:44, Deshpande, Vivek R wrote: >>>> >>>> HI Nils >>>> >>>> >>>> >>>> Yes you are right the function accesses the command line >>>> flag DisableIntrinsic and changes are static. >>>> >>>> Could you point me the right location for the function ? >>>> >>>> Also I have updated the webrev with rest of the comments >>>> here: >>>> >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>> ebr >>>> ev.01/ >>>> >>>> >>>> >>>> Regards, >>>> >>>> Vivek >>>> >>>> >>>> >>>> *From:* hotspot-compiler-dev >>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]*On Behalf >>>> Of *Nils Eliasson >>>> *Sent:* Tuesday, April 19, 2016 5:55 AM >>>> *To:* hotspot-compiler-dev at openjdk.java.net >>>> >>>> *Subject:* Re: RFR (S): 8154473: Update for >>>> CompilerDirectives to control stub generation and >>>> intrinsics >>>> >>>> >>>> >>>> Hi Vivek, >>>> >>>> The changes in is_intrinsic_disabled in >>>> compilerDirectives.* are static and only access the >>>> command line flag DisableIntrinsics. As long as stubs >>>> are only generated during startup and don't have a >>>> method context - that is ok - but it doesn't belong in >>>> the compilerDirectives-files if it doens't use directives. >>>> >>>> Regards, >>>> Nils >>>> >>>> On 2016-04-18 19:38, Deshpande, Vivek R wrote: >>>> >>>> Hi all >>>> >>>> >>>> >>>> I would like to contribute a patch which helps to >>>> control the intrinsics in interpreter, c1 and c2 by >>>> disabling the stub generation. >>>> >>>> This uses -XX:DisableIntrinsic option to achieve the >>>> same. >>>> >>>> Could you please review and sponsor this patch. >>>> >>>> >>>> >>>> Bug-id: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>>> webrev: >>>> >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>> ebrev.00/ >>>> >>>> >>> 3/w >>>> ebrev.00/> >>>> >>>> >>>> >>>> Thanks and regards, >>>> >>>> Vivek >>>> >>>> >>>> From vladimir.kozlov at oracle.com Wed May 18 23:29:10 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 May 2016 16:29:10 -0700 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DE0E@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D924@ORSMSX106.amr.corp.intel.com> <62c7df4e-d9ed-8d72-6335-1de307fc6e08@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DAC6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DD39@ORSMSX106.amr.corp.intel.com> <30495ce0-7899-184d-2953-9ad682ab0978@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DE0E@ORSMSX106.amr.corp.intel.com> Message-ID: <62ad124b-dd17-117f-bce6-26f4c3d33737@oracle.com> That is why I suggested new method with '0' in name and no int parameter: // Use this method when MacroAssembler version of call_VM_leaf_base() should be called. void MacroAssembler::call_VM_leaf0(address entry_point) { MacroAssembler::call_VM_leaf_base(entry_point, 0); } Vladimir On 5/18/16 4:22 PM, Deshpande, Vivek R wrote: > HI Vladimir > > I need to call masm version of call_VM_leaf_base(). > > Using following from templateInterpreter_x86_64/32.cpp > > void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { > call_VM_leaf_base(entry_point, number_of_arguments); > } > > ends up calling > > void InterpreterMacroAssembler::call_VM_leaf_base(address entry_point, > int number_of_arguments) { ... > from interp_masm_x86.cpp instead of > > void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { ... > > So I had put mathfunc() to call the masm version of call_VM_leaf_base(). > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, May 18, 2016 4:18 PM > To: Deshpande, Vivek R > Cc: Viswanathan, Sandhya; hotspot compiler > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > You are still using mathfunc(). > > Vladimir > > On 5/18/16 3:26 PM, Deshpande, Vivek R wrote: >> Hi Vladimir >> >> I have the latest webrev with suggested changes here: >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webr >> ev.04/ >> Could you please take a look at it. >> >> Regards, >> Vivek >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, May 18, 2016 12:41 PM >> To: Deshpande, Vivek R >> Cc: Viswanathan, Sandhya; hotspot compiler; >> hotspot-runtime-dev at openjdk.java.net runtime >> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >> control stub generation and intrinsics >> >> Okay, convert it to bug saying that -XX:DisableIntrinsic does not >> disable intrinsic in Interpreter. Which can lead to results >> inconsistencies since different code is used in compiled code and >> Interpreter. >> >> Thanks, >> Vladimir >> >> On 5/18/16 12:36 PM, Deshpande, Vivek R wrote: >>> HI Vladimir >>> >>> We can convert it to bug. >>> With the change, using -XX:DisableIntrinsic=_dexp, will not generate the LIBM stub and all the calls will point to SharedRuntime::dexp correctly with stack adjustment. >>> Currently with -XX:DisableIntrinsic=_dexp, stub gets generated and points to LIBM stub in interpreter. >>> and just using option UseLibmIntrinsic to disable LIBM usage fails without stack adjustment for 64 bit. >>> I can make changes for 32 bit in updated webrev. >>> >>> Regards, >>> Vivek >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Wednesday, May 18, 2016 12:24 PM >>> To: Deshpande, Vivek R >>> Cc: Viswanathan, Sandhya; hotspot compiler; >>> hotspot-runtime-dev at openjdk.java.net runtime >>> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >>> control stub generation and intrinsics >>> >>> First, 8154473 is RFE and we are post FC (feature complete). We have to wait until the process of RFEs approval is finalized. >>> >>> Or we can convert it to bug. Can you say what happens with current code if -XX:DisableIntrinsic=_dexp is used, for example? And what will happen after these changes? >>> >>> I don't see changes for: >>> templateInterpreterGenerator_x86_32.cpp >>> >>> It would be better to have similar code there even if 32-bit code does not have stack problem. >>> >>> >>> You did not implemented what Chris was asked: >>> >>> > a) Add a method in MacroAssembler to call >>> MacroAssembler::call_VM_leaf_base (what you did) or > >>> >b) Add InterpreterMacroAssembler::call_VM_leaf and change >>> MacroAssembler::call_VM_leaf to do: >>> > >>> > void MacroAssembler::call_VM_leaf(address entry_point, int >>> number_of_arguments) { >>> > MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); >>> > } >>> >>> I would suggest an other method >>> >>> // Use this method when MacroAssembler version of call_VM_leaf_base() >>> should be called. >>> void MacroAssembler::call_VM_leaf0(address entry_point) { >>> MacroAssembler::call_VM_leaf_base(entry_point, 0); } >>> >>> Thanks, >>> Vladimir >>> >>> On 5/18/16 11:27 AM, Deshpande, Vivek R wrote: >>>> Hi Vladimir >>>> >>>> The latest webrev is here: >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/we >>>> brev.03/ >>>> The bug ID for the same is: >>>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>>> >>>> Thanks for looking into it. >>>> >>>> Regards, >>>> Vivek >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Wednesday, May 18, 2016 11:04 AM >>>> To: Deshpande, Vivek R >>>> Cc: Viswanathan, Sandhya; hotspot compiler; >>>> hotspot-runtime-dev at openjdk.java.net runtime >>>> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >>>> control stub generation and intrinsics >>>> >>>> Hi Vivek, >>>> >>>> Can you send link to latest webrev? The thread is long and it is not clear which webrev is final. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 5/18/16 10:36 AM, Deshpande, Vivek R wrote: >>>>> >>>>> >>>>> Hi Vladimir >>>>> >>>>> >>>>> >>>>> Could you please review and sponsor this patch with the current solution. >>>>> >>>>> This patch calls correct fallback version for LIBM methods when >>>>> LIBM is disabled. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:*Deshpande, Vivek R >>>>> *Sent:* Tuesday, May 10, 2016 11:00 AM >>>>> *To:* 'Christian Thalinger' >>>>> *Cc:* Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; >>>>> hotspot-runtime-dev at openjdk.java.net runtime >>>>> *Subject:* RE: RFR (S): 8154473: Update for CompilerDirectives to >>>>> control stub generation and intrinsics >>>>> >>>>> >>>>> >>>>> HI Christian >>>>> >>>>> >>>>> >>>>> We have not heard from runtime team regarding this change. >>>>> >>>>> Shall we go ahead with the current solution ? >>>>> >>>>> I can send out the latest webrev. >>>>> >>>>> Let me know your thoughts. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> *Sent:* Monday, May 02, 2016 3:44 PM >>>>> *To:* Deshpande, Vivek R >>>>> *Cc:* Viswanathan, Sandhya; hotspot compiler; >>>>> hotspot-runtime-dev at openjdk.java.net >>>>> runtime >>>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>>>> control stub generation and intrinsics >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On May 2, 2016, at 11:53 AM, Deshpande, Vivek R >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi Christian >>>>> >>>>> >>>>> >>>>> I had tried using call_VM_leaf() which you mentioned. >>>>> >>>>> >>>>> >>>>> But this function >>>>> >>>>> >>>>> >>>>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>>>> { >>>>> >>>>> call_VM_leaf_base(entry_point, number_of_arguments); >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> ends up calling >>>>> >>>>> >>>>> >>>>> void InterpreterMacroAssembler::call_VM_leaf_base(address >>>>> entry_point, >>>>> >>>>> int number_of_arguments) >>>>> { ... >>>>> >>>>> from interp_masm_x86.cpp instead of >>>>> >>>>> >>>>> >>>>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>>>> { ? >>>>> >>>>> >>>>> >>>>> Frankly, I didn?t know that there is an overload for >>>>> call_VM_leaf_base in InterpreterMacroAssembler. So this means there are two options: >>>>> >>>>> >>>>> >>>>> a) Add a method in MacroAssembler to call >>>>> MacroAssembler::call_VM_leaf_base (what you did) or >>>>> >>>>> >>>>> >>>>> b) Add InterpreterMacroAssembler::call_VM_leaf and change >>>>> MacroAssembler::call_VM_leaf to do: >>>>> >>>>> >>>>> >>>>> voidMacroAssembler::call_VM_leaf(address entry_point, int >>>>> number_of_arguments) { >>>>> >>>>> MacroAssembler::call_VM_leaf_base(entry_point, >>>>> number_of_arguments); >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> I will let the runtime team decide. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> So I had put mathfunc() to call the masm version of call_VM_leaf_base(). >>>>> >>>>> >>>>> >>>>> Let me know what you think. >>>>> >>>>> >>>>> >>>>> Thanks and regards, >>>>> Vivek >>>>> >>>>> >>>>> >>>>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> *Sent:* Monday, May 02, 2016 1:50 PM >>>>> *To:* Deshpande, Vivek R >>>>> *Cc:* hotspot-compiler-dev at openjdk.java.net >>>>> >>>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>>>> control stub generation and intrinsics >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R >>>>> >>>> > wrote: >>>>> >>>>> >>>>> >>>>> Hi Christian >>>>> >>>>> >>>>> >>>>> I have updated the webrev and link for the same is here: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>>> ebr >>>>> ev.03/ >>>>> >>>>> I am using mathfunc() to call the masm version of >>>>> call_VM_leaf_base() and not the InterpreterMacroAssembler version. >>>>> >>>>> >>>>> >>>>> That?s better but, again, there is nothing math-y about this method: >>>>> >>>>> ! void MacroAssembler::mathfunc(address runtime_entry) { >>>>> >>>>> MacroAssembler::call_VM_leaf_base(runtime_entry, 0); >>>>> >>>>> } >>>>> >>>>> Also, there is this method: >>>>> >>>>> >>>>> >>>>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>>>> { >>>>> >>>>> call_VM_leaf_base(entry_point, number_of_arguments); >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> which has: >>>>> >>>>> >>>>> >>>>> void call_VM_leaf(address entry_point, >>>>> >>>>> int number_of_arguments = 0); >>>>> >>>>> >>>>> >>>>> Get rid of mathfunc completely and use call_VM_leaf directly. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> *Sent:* Thursday, April 21, 2016 2:35 PM >>>>> *To:* Deshpande, Vivek R >>>> > >>>>> *Cc:* Nils Eliasson >>>> >; hotspot-compiler-dev at openjdk.java.net >>>>> ; Vladimir Kozlov >>>>> > >>>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives >>>>> to control stub generation and intrinsics >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R >>>>> >>>> > wrote: >>>>> >>>>> >>>>> >>>>> Hi >>>>> >>>>> >>>>> >>>>> The correct URL for the updated webrev is this. >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>>> ebr >>>>> ev.02/ >>>>> >>>>> >>>>> >>>>> +void MacroAssembler::mathfunc(address runtime_entry) { >>>>> >>>>> I don?t like the name of this method. Mainly because it?s only >>>>> aligning the stack (shouldn?t that happen somewhere else?) and >>>>> doing this 0x20 stack frame thing which I still don?t understand. >>>>> >>>>> >>>>> >>>>> Right, this is the one I was thinking about: >>>>> >>>>> >>>>> >>>>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>>>> { >>>>> >>>>> >>>>> >>>>> >>>>> Sorry for the spam. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> *From:* Deshpande, Vivek R >>>>> *Sent:* Wednesday, April 20, 2016 5:10 PM >>>>> *To:* Deshpande, Vivek R; 'Nils Eliasson'; >>>>> 'hotspot-compiler-dev at openjdk.java.net >>>>> ' >>>>> *Cc:* 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian >>>>> Thalinger'; Viswanathan, Sandhya >>>>> *Subject:* RE: RFR (S): 8154473: Update for >>>>> CompilerDirectives to control stub generation and >>>>> intrinsics >>>>> >>>>> >>>>> >>>>> Sent out the wrong link by mistake. >>>>> >>>>> >>>>> >>>>> updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>>> ebrev.02/ >>>>> >>>>> >>>> web >>>>> rev.01/> >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Deshpande, Vivek R >>>>> *Sent:* Wednesday, April 20, 2016 5:07 PM >>>>> *To:* 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net >>>>> >>>>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>>>> Viswanathan, Sandhya >>>>> *Subject:* RE: RFR (S): 8154473: Update for >>>>> CompilerDirectives to control stub generation and >>>>> intrinsics >>>>> >>>>> >>>>> >>>>> Hi Nils >>>>> >>>>> >>>>> >>>>> I have updated the webrev with all the suggestions. >>>>> >>>>> updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>>> ebr >>>>> ev.01/ >>>>> >>>>> Thanks for your comments and review. >>>>> >>>>> >>>>> >>>>> @Vladimir, >>>>> >>>>> I have taken care of all the comments. Would you please >>>>> review and sponsor the patch. >>>>> >>>>> >>>>> >>>>> Thanks and regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> *From:* Nils Eliasson [mailto:nils.eliasson at oracle.com] >>>>> *Sent:* Wednesday, April 20, 2016 12:27 PM >>>>> *To:* Deshpande, Vivek >>>>> R; hotspot-compiler-dev at openjdk.java.net >>>>> >>>>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>>>> Viswanathan, Sandhya >>>>> *Subject:* Re: RFR (S): 8154473: Update for >>>>> CompilerDirectives to control stub generation and >>>>> intrinsics >>>>> >>>>> >>>>> >>>>> In vmSymbols.cpp together with the other flag checks. >>>>> >>>>> Regards, >>>>> Nils >>>>> >>>>> On 2016-04-20 02:44, Deshpande, Vivek R wrote: >>>>> >>>>> HI Nils >>>>> >>>>> >>>>> >>>>> Yes you are right the function accesses the command line >>>>> flag DisableIntrinsic and changes are static. >>>>> >>>>> Could you point me the right location for the function ? >>>>> >>>>> Also I have updated the webrev with rest of the comments >>>>> here: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>>> ebr >>>>> ev.01/ >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> *From:* hotspot-compiler-dev >>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]*On Behalf >>>>> Of *Nils Eliasson >>>>> *Sent:* Tuesday, April 19, 2016 5:55 AM >>>>> *To:* hotspot-compiler-dev at openjdk.java.net >>>>> >>>>> *Subject:* Re: RFR (S): 8154473: Update for >>>>> CompilerDirectives to control stub generation and >>>>> intrinsics >>>>> >>>>> >>>>> >>>>> Hi Vivek, >>>>> >>>>> The changes in is_intrinsic_disabled in >>>>> compilerDirectives.* are static and only access the >>>>> command line flag DisableIntrinsics. As long as stubs >>>>> are only generated during startup and don't have a >>>>> method context - that is ok - but it doesn't belong in >>>>> the compilerDirectives-files if it doens't use directives. >>>>> >>>>> Regards, >>>>> Nils >>>>> >>>>> On 2016-04-18 19:38, Deshpande, Vivek R wrote: >>>>> >>>>> Hi all >>>>> >>>>> >>>>> >>>>> I would like to contribute a patch which helps to >>>>> control the intrinsics in interpreter, c1 and c2 by >>>>> disabling the stub generation. >>>>> >>>>> This uses -XX:DisableIntrinsic option to achieve the >>>>> same. >>>>> >>>>> Could you please review and sponsor this patch. >>>>> >>>>> >>>>> >>>>> Bug-id: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>>>> webrev: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>>> ebrev.00/ >>>>> >>>>> >>>> 3/w >>>>> ebrev.00/> >>>>> >>>>> >>>>> >>>>> Thanks and regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> From vivek.r.deshpande at intel.com Thu May 19 00:36:56 2016 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 19 May 2016 00:36:56 +0000 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <62ad124b-dd17-117f-bce6-26f4c3d33737@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <74581C88-CC26-441E-933B-73954C56F077@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A89A1C@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D924@ORSMSX106.amr.corp.intel.com> <62c7df4e-d9ed-8d72-6335-1de307fc6e08@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DAC6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DD39@ORSMSX106.amr.corp.intel.com> <30495ce0-7899-184d-2953-9ad682ab0978@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DE0E@ORSMSX106.amr.corp.intel.com> <62ad124b-dd17-117f-bce6-26f4c3d33737@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DECB@ORSMSX106.amr.corp.intel.com> Hi Vladimir Sorry I missed that part. Here is the webrev with that change: http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.05/ Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, May 18, 2016 4:29 PM To: Deshpande, Vivek R Cc: Viswanathan, Sandhya; hotspot compiler Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics That is why I suggested new method with '0' in name and no int parameter: // Use this method when MacroAssembler version of call_VM_leaf_base() should be called. void MacroAssembler::call_VM_leaf0(address entry_point) { MacroAssembler::call_VM_leaf_base(entry_point, 0); } Vladimir On 5/18/16 4:22 PM, Deshpande, Vivek R wrote: > HI Vladimir > > I need to call masm version of call_VM_leaf_base(). > > Using following from templateInterpreter_x86_64/32.cpp > > void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { > call_VM_leaf_base(entry_point, number_of_arguments); } > > ends up calling > > void InterpreterMacroAssembler::call_VM_leaf_base(address entry_point, > int number_of_arguments) { ... > from interp_masm_x86.cpp instead of > > void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { ... > > So I had put mathfunc() to call the masm version of call_VM_leaf_base(). > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, May 18, 2016 4:18 PM > To: Deshpande, Vivek R > Cc: Viswanathan, Sandhya; hotspot compiler > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to > control stub generation and intrinsics > > You are still using mathfunc(). > > Vladimir > > On 5/18/16 3:26 PM, Deshpande, Vivek R wrote: >> Hi Vladimir >> >> I have the latest webrev with suggested changes here: >> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/web >> r >> ev.04/ >> Could you please take a look at it. >> >> Regards, >> Vivek >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, May 18, 2016 12:41 PM >> To: Deshpande, Vivek R >> Cc: Viswanathan, Sandhya; hotspot compiler; >> hotspot-runtime-dev at openjdk.java.net runtime >> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >> control stub generation and intrinsics >> >> Okay, convert it to bug saying that -XX:DisableIntrinsic does not >> disable intrinsic in Interpreter. Which can lead to results >> inconsistencies since different code is used in compiled code and >> Interpreter. >> >> Thanks, >> Vladimir >> >> On 5/18/16 12:36 PM, Deshpande, Vivek R wrote: >>> HI Vladimir >>> >>> We can convert it to bug. >>> With the change, using -XX:DisableIntrinsic=_dexp, will not generate the LIBM stub and all the calls will point to SharedRuntime::dexp correctly with stack adjustment. >>> Currently with -XX:DisableIntrinsic=_dexp, stub gets generated and points to LIBM stub in interpreter. >>> and just using option UseLibmIntrinsic to disable LIBM usage fails without stack adjustment for 64 bit. >>> I can make changes for 32 bit in updated webrev. >>> >>> Regards, >>> Vivek >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Wednesday, May 18, 2016 12:24 PM >>> To: Deshpande, Vivek R >>> Cc: Viswanathan, Sandhya; hotspot compiler; >>> hotspot-runtime-dev at openjdk.java.net runtime >>> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >>> control stub generation and intrinsics >>> >>> First, 8154473 is RFE and we are post FC (feature complete). We have to wait until the process of RFEs approval is finalized. >>> >>> Or we can convert it to bug. Can you say what happens with current code if -XX:DisableIntrinsic=_dexp is used, for example? And what will happen after these changes? >>> >>> I don't see changes for: >>> templateInterpreterGenerator_x86_32.cpp >>> >>> It would be better to have similar code there even if 32-bit code does not have stack problem. >>> >>> >>> You did not implemented what Chris was asked: >>> >>> > a) Add a method in MacroAssembler to call >>> MacroAssembler::call_VM_leaf_base (what you did) or > >>> >b) Add InterpreterMacroAssembler::call_VM_leaf and change >>> MacroAssembler::call_VM_leaf to do: >>> > >>> > void MacroAssembler::call_VM_leaf(address entry_point, int >>> number_of_arguments) { >>> > MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); >>> > } >>> >>> I would suggest an other method >>> >>> // Use this method when MacroAssembler version of >>> call_VM_leaf_base() should be called. >>> void MacroAssembler::call_VM_leaf0(address entry_point) { >>> MacroAssembler::call_VM_leaf_base(entry_point, 0); } >>> >>> Thanks, >>> Vladimir >>> >>> On 5/18/16 11:27 AM, Deshpande, Vivek R wrote: >>>> Hi Vladimir >>>> >>>> The latest webrev is here: >>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>> e >>>> brev.03/ >>>> The bug ID for the same is: >>>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>>> >>>> Thanks for looking into it. >>>> >>>> Regards, >>>> Vivek >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Wednesday, May 18, 2016 11:04 AM >>>> To: Deshpande, Vivek R >>>> Cc: Viswanathan, Sandhya; hotspot compiler; >>>> hotspot-runtime-dev at openjdk.java.net runtime >>>> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >>>> control stub generation and intrinsics >>>> >>>> Hi Vivek, >>>> >>>> Can you send link to latest webrev? The thread is long and it is not clear which webrev is final. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 5/18/16 10:36 AM, Deshpande, Vivek R wrote: >>>>> >>>>> >>>>> Hi Vladimir >>>>> >>>>> >>>>> >>>>> Could you please review and sponsor this patch with the current solution. >>>>> >>>>> This patch calls correct fallback version for LIBM methods when >>>>> LIBM is disabled. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:*Deshpande, Vivek R >>>>> *Sent:* Tuesday, May 10, 2016 11:00 AM >>>>> *To:* 'Christian Thalinger' >>>>> *Cc:* Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; >>>>> hotspot-runtime-dev at openjdk.java.net runtime >>>>> *Subject:* RE: RFR (S): 8154473: Update for CompilerDirectives to >>>>> control stub generation and intrinsics >>>>> >>>>> >>>>> >>>>> HI Christian >>>>> >>>>> >>>>> >>>>> We have not heard from runtime team regarding this change. >>>>> >>>>> Shall we go ahead with the current solution ? >>>>> >>>>> I can send out the latest webrev. >>>>> >>>>> Let me know your thoughts. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> *Sent:* Monday, May 02, 2016 3:44 PM >>>>> *To:* Deshpande, Vivek R >>>>> *Cc:* Viswanathan, Sandhya; hotspot compiler; >>>>> hotspot-runtime-dev at openjdk.java.net >>>>> runtime >>>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>>>> control stub generation and intrinsics >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On May 2, 2016, at 11:53 AM, Deshpande, Vivek R >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi Christian >>>>> >>>>> >>>>> >>>>> I had tried using call_VM_leaf() which you mentioned. >>>>> >>>>> >>>>> >>>>> But this function >>>>> >>>>> >>>>> >>>>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>>>> { >>>>> >>>>> call_VM_leaf_base(entry_point, number_of_arguments); >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> ends up calling >>>>> >>>>> >>>>> >>>>> void InterpreterMacroAssembler::call_VM_leaf_base(address >>>>> entry_point, >>>>> >>>>> int number_of_arguments) >>>>> { ... >>>>> >>>>> from interp_masm_x86.cpp instead of >>>>> >>>>> >>>>> >>>>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>>>> { ? >>>>> >>>>> >>>>> >>>>> Frankly, I didn?t know that there is an overload for >>>>> call_VM_leaf_base in InterpreterMacroAssembler. So this means there are two options: >>>>> >>>>> >>>>> >>>>> a) Add a method in MacroAssembler to call >>>>> MacroAssembler::call_VM_leaf_base (what you did) or >>>>> >>>>> >>>>> >>>>> b) Add InterpreterMacroAssembler::call_VM_leaf and change >>>>> MacroAssembler::call_VM_leaf to do: >>>>> >>>>> >>>>> >>>>> voidMacroAssembler::call_VM_leaf(address entry_point, int >>>>> number_of_arguments) { >>>>> >>>>> MacroAssembler::call_VM_leaf_base(entry_point, >>>>> number_of_arguments); >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> I will let the runtime team decide. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> So I had put mathfunc() to call the masm version of call_VM_leaf_base(). >>>>> >>>>> >>>>> >>>>> Let me know what you think. >>>>> >>>>> >>>>> >>>>> Thanks and regards, >>>>> Vivek >>>>> >>>>> >>>>> >>>>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> *Sent:* Monday, May 02, 2016 1:50 PM >>>>> *To:* Deshpande, Vivek R >>>>> *Cc:* hotspot-compiler-dev at openjdk.java.net >>>>> >>>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>>>> control stub generation and intrinsics >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R >>>>> >>>> > wrote: >>>>> >>>>> >>>>> >>>>> Hi Christian >>>>> >>>>> >>>>> >>>>> I have updated the webrev and link for the same is here: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>> w >>>>> ebr >>>>> ev.03/ >>>>> >>>>> I am using mathfunc() to call the masm version of >>>>> call_VM_leaf_base() and not the InterpreterMacroAssembler version. >>>>> >>>>> >>>>> >>>>> That?s better but, again, there is nothing math-y about this method: >>>>> >>>>> ! void MacroAssembler::mathfunc(address runtime_entry) { >>>>> >>>>> MacroAssembler::call_VM_leaf_base(runtime_entry, 0); >>>>> >>>>> } >>>>> >>>>> Also, there is this method: >>>>> >>>>> >>>>> >>>>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>>>> { >>>>> >>>>> call_VM_leaf_base(entry_point, number_of_arguments); >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> which has: >>>>> >>>>> >>>>> >>>>> void call_VM_leaf(address entry_point, >>>>> >>>>> int number_of_arguments = 0); >>>>> >>>>> >>>>> >>>>> Get rid of mathfunc completely and use call_VM_leaf directly. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>> *Sent:* Thursday, April 21, 2016 2:35 PM >>>>> *To:* Deshpande, Vivek R >>>> > >>>>> *Cc:* Nils Eliasson >>>> >; hotspot-compiler-dev at openjdk.java.net >>>>> ; Vladimir Kozlov >>>>> > >>>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives >>>>> to control stub generation and intrinsics >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R >>>>> >>>> > wrote: >>>>> >>>>> >>>>> >>>>> Hi >>>>> >>>>> >>>>> >>>>> The correct URL for the updated webrev is this. >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>> w >>>>> ebr >>>>> ev.02/ >>>>> >>>>> >>>>> >>>>> +void MacroAssembler::mathfunc(address runtime_entry) { >>>>> >>>>> I don?t like the name of this method. Mainly because it?s only >>>>> aligning the stack (shouldn?t that happen somewhere else?) and >>>>> doing this 0x20 stack frame thing which I still don?t understand. >>>>> >>>>> >>>>> >>>>> Right, this is the one I was thinking about: >>>>> >>>>> >>>>> >>>>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>>>> { >>>>> >>>>> >>>>> >>>>> >>>>> Sorry for the spam. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> *From:* Deshpande, Vivek R >>>>> *Sent:* Wednesday, April 20, 2016 5:10 PM >>>>> *To:* Deshpande, Vivek R; 'Nils Eliasson'; >>>>> 'hotspot-compiler-dev at openjdk.java.net >>>>> ' >>>>> *Cc:* 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian >>>>> Thalinger'; Viswanathan, Sandhya >>>>> *Subject:* RE: RFR (S): 8154473: Update for >>>>> CompilerDirectives to control stub generation and >>>>> intrinsics >>>>> >>>>> >>>>> >>>>> Sent out the wrong link by mistake. >>>>> >>>>> >>>>> >>>>> updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>> w >>>>> ebrev.02/ >>>>> >>>>> >>>> / >>>>> web >>>>> rev.01/> >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Deshpande, Vivek R >>>>> *Sent:* Wednesday, April 20, 2016 5:07 PM >>>>> *To:* 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net >>>>> >>>>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>>>> Viswanathan, Sandhya >>>>> *Subject:* RE: RFR (S): 8154473: Update for >>>>> CompilerDirectives to control stub generation and >>>>> intrinsics >>>>> >>>>> >>>>> >>>>> Hi Nils >>>>> >>>>> >>>>> >>>>> I have updated the webrev with all the suggestions. >>>>> >>>>> updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>> w >>>>> ebr >>>>> ev.01/ >>>>> >>>>> Thanks for your comments and review. >>>>> >>>>> >>>>> >>>>> @Vladimir, >>>>> >>>>> I have taken care of all the comments. Would you please >>>>> review and sponsor the patch. >>>>> >>>>> >>>>> >>>>> Thanks and regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> *From:* Nils Eliasson [mailto:nils.eliasson at oracle.com] >>>>> *Sent:* Wednesday, April 20, 2016 12:27 PM >>>>> *To:* Deshpande, Vivek >>>>> R; hotspot-compiler-dev at openjdk.java.net >>>>> >>>>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>>>> Viswanathan, Sandhya >>>>> *Subject:* Re: RFR (S): 8154473: Update for >>>>> CompilerDirectives to control stub generation and >>>>> intrinsics >>>>> >>>>> >>>>> >>>>> In vmSymbols.cpp together with the other flag checks. >>>>> >>>>> Regards, >>>>> Nils >>>>> >>>>> On 2016-04-20 02:44, Deshpande, Vivek R wrote: >>>>> >>>>> HI Nils >>>>> >>>>> >>>>> >>>>> Yes you are right the function accesses the command line >>>>> flag DisableIntrinsic and changes are static. >>>>> >>>>> Could you point me the right location for the function ? >>>>> >>>>> Also I have updated the webrev with rest of the comments >>>>> here: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>> w >>>>> ebr >>>>> ev.01/ >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> >>>>> *From:* hotspot-compiler-dev >>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]*On Behalf >>>>> Of *Nils Eliasson >>>>> *Sent:* Tuesday, April 19, 2016 5:55 AM >>>>> *To:* hotspot-compiler-dev at openjdk.java.net >>>>> >>>>> *Subject:* Re: RFR (S): 8154473: Update for >>>>> CompilerDirectives to control stub generation and >>>>> intrinsics >>>>> >>>>> >>>>> >>>>> Hi Vivek, >>>>> >>>>> The changes in is_intrinsic_disabled in >>>>> compilerDirectives.* are static and only access the >>>>> command line flag DisableIntrinsics. As long as stubs >>>>> are only generated during startup and don't have a >>>>> method context - that is ok - but it doesn't belong in >>>>> the compilerDirectives-files if it doens't use directives. >>>>> >>>>> Regards, >>>>> Nils >>>>> >>>>> On 2016-04-18 19:38, Deshpande, Vivek R wrote: >>>>> >>>>> Hi all >>>>> >>>>> >>>>> >>>>> I would like to contribute a patch which helps to >>>>> control the intrinsics in interpreter, c1 and c2 by >>>>> disabling the stub generation. >>>>> >>>>> This uses -XX:DisableIntrinsic option to achieve the >>>>> same. >>>>> >>>>> Could you please review and sponsor this patch. >>>>> >>>>> >>>>> >>>>> Bug-id: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>>>> webrev: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>> w >>>>> ebrev.00/ >>>>> >>>>> >>>> 7 >>>>> 3/w >>>>> ebrev.00/> >>>>> >>>>> >>>>> >>>>> Thanks and regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>>> From vladimir.kozlov at oracle.com Thu May 19 01:29:37 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 May 2016 18:29:37 -0700 Subject: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DECB@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A56A800C7@ORSMSX106.amr.corp.intel.com> <9BBBF418-EC9D-4580-95D9-2625FEA4B0DD@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A8EAE6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D86E@ORSMSX106.amr.corp.intel.com> <423083c4-4101-0be3-760d-ad0461f69db1@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9D924@ORSMSX106.amr.corp.intel.com> <62c7df4e-d9ed-8d72-6335-1de307fc6e08@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DAC6@ORSMSX106.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DD39@ORSMSX106.amr.corp.intel.com> <30495ce0-7899-184d-2953-9ad682ab0978@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DE0E@ORSMSX106.amr.corp.intel.com> <62ad124b-dd17-117f-bce6-26f4c3d33737@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A56A9DECB@ORSMSX106.amr.corp.intel.com> Message-ID: <073797f8-4db3-f0c9-b345-3c7c2d4f2308@oracle.com> Good. I started testing. Thanks, Vladimir On 5/18/16 5:36 PM, Deshpande, Vivek R wrote: > Hi Vladimir > > Sorry I missed that part. > Here is the webrev with that change: > http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/webrev.05/ > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, May 18, 2016 4:29 PM > To: Deshpande, Vivek R > Cc: Viswanathan, Sandhya; hotspot compiler > Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to control stub generation and intrinsics > > That is why I suggested new method with '0' in name and no int parameter: > > // Use this method when MacroAssembler version of call_VM_leaf_base() should be called. > void MacroAssembler::call_VM_leaf0(address entry_point) { > MacroAssembler::call_VM_leaf_base(entry_point, 0); } > > Vladimir > > On 5/18/16 4:22 PM, Deshpande, Vivek R wrote: >> HI Vladimir >> >> I need to call masm version of call_VM_leaf_base(). >> >> Using following from templateInterpreter_x86_64/32.cpp >> >> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) { >> call_VM_leaf_base(entry_point, number_of_arguments); } >> >> ends up calling >> >> void InterpreterMacroAssembler::call_VM_leaf_base(address entry_point, >> int number_of_arguments) { ... >> from interp_masm_x86.cpp instead of >> >> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) { ... >> >> So I had put mathfunc() to call the masm version of call_VM_leaf_base(). >> >> Regards, >> Vivek >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, May 18, 2016 4:18 PM >> To: Deshpande, Vivek R >> Cc: Viswanathan, Sandhya; hotspot compiler >> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >> control stub generation and intrinsics >> >> You are still using mathfunc(). >> >> Vladimir >> >> On 5/18/16 3:26 PM, Deshpande, Vivek R wrote: >>> Hi Vladimir >>> >>> I have the latest webrev with suggested changes here: >>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/web >>> r >>> ev.04/ >>> Could you please take a look at it. >>> >>> Regards, >>> Vivek >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Wednesday, May 18, 2016 12:41 PM >>> To: Deshpande, Vivek R >>> Cc: Viswanathan, Sandhya; hotspot compiler; >>> hotspot-runtime-dev at openjdk.java.net runtime >>> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >>> control stub generation and intrinsics >>> >>> Okay, convert it to bug saying that -XX:DisableIntrinsic does not >>> disable intrinsic in Interpreter. Which can lead to results >>> inconsistencies since different code is used in compiled code and >>> Interpreter. >>> >>> Thanks, >>> Vladimir >>> >>> On 5/18/16 12:36 PM, Deshpande, Vivek R wrote: >>>> HI Vladimir >>>> >>>> We can convert it to bug. >>>> With the change, using -XX:DisableIntrinsic=_dexp, will not generate the LIBM stub and all the calls will point to SharedRuntime::dexp correctly with stack adjustment. >>>> Currently with -XX:DisableIntrinsic=_dexp, stub gets generated and points to LIBM stub in interpreter. >>>> and just using option UseLibmIntrinsic to disable LIBM usage fails without stack adjustment for 64 bit. >>>> I can make changes for 32 bit in updated webrev. >>>> >>>> Regards, >>>> Vivek >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Wednesday, May 18, 2016 12:24 PM >>>> To: Deshpande, Vivek R >>>> Cc: Viswanathan, Sandhya; hotspot compiler; >>>> hotspot-runtime-dev at openjdk.java.net runtime >>>> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >>>> control stub generation and intrinsics >>>> >>>> First, 8154473 is RFE and we are post FC (feature complete). We have to wait until the process of RFEs approval is finalized. >>>> >>>> Or we can convert it to bug. Can you say what happens with current code if -XX:DisableIntrinsic=_dexp is used, for example? And what will happen after these changes? >>>> >>>> I don't see changes for: >>>> templateInterpreterGenerator_x86_32.cpp >>>> >>>> It would be better to have similar code there even if 32-bit code does not have stack problem. >>>> >>>> >>>> You did not implemented what Chris was asked: >>>> >>>> > a) Add a method in MacroAssembler to call >>>> MacroAssembler::call_VM_leaf_base (what you did) or > >>>> >b) Add InterpreterMacroAssembler::call_VM_leaf and change >>>> MacroAssembler::call_VM_leaf to do: >>>> > >>>> > void MacroAssembler::call_VM_leaf(address entry_point, int >>>> number_of_arguments) { >>>> > MacroAssembler::call_VM_leaf_base(entry_point, number_of_arguments); >>>> > } >>>> >>>> I would suggest an other method >>>> >>>> // Use this method when MacroAssembler version of >>>> call_VM_leaf_base() should be called. >>>> void MacroAssembler::call_VM_leaf0(address entry_point) { >>>> MacroAssembler::call_VM_leaf_base(entry_point, 0); } >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 5/18/16 11:27 AM, Deshpande, Vivek R wrote: >>>>> Hi Vladimir >>>>> >>>>> The latest webrev is here: >>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/w >>>>> e >>>>> brev.03/ >>>>> The bug ID for the same is: >>>>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>>>> >>>>> Thanks for looking into it. >>>>> >>>>> Regards, >>>>> Vivek >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Wednesday, May 18, 2016 11:04 AM >>>>> To: Deshpande, Vivek R >>>>> Cc: Viswanathan, Sandhya; hotspot compiler; >>>>> hotspot-runtime-dev at openjdk.java.net runtime >>>>> Subject: Re: RFR (S): 8154473: Update for CompilerDirectives to >>>>> control stub generation and intrinsics >>>>> >>>>> Hi Vivek, >>>>> >>>>> Can you send link to latest webrev? The thread is long and it is not clear which webrev is final. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 5/18/16 10:36 AM, Deshpande, Vivek R wrote: >>>>>> >>>>>> >>>>>> Hi Vladimir >>>>>> >>>>>> >>>>>> >>>>>> Could you please review and sponsor this patch with the current solution. >>>>>> >>>>>> This patch calls correct fallback version for LIBM methods when >>>>>> LIBM is disabled. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Vivek >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:*Deshpande, Vivek R >>>>>> *Sent:* Tuesday, May 10, 2016 11:00 AM >>>>>> *To:* 'Christian Thalinger' >>>>>> *Cc:* Viswanathan, Sandhya; 'Vladimir Kozlov'; hotspot compiler; >>>>>> hotspot-runtime-dev at openjdk.java.net runtime >>>>>> *Subject:* RE: RFR (S): 8154473: Update for CompilerDirectives to >>>>>> control stub generation and intrinsics >>>>>> >>>>>> >>>>>> >>>>>> HI Christian >>>>>> >>>>>> >>>>>> >>>>>> We have not heard from runtime team regarding this change. >>>>>> >>>>>> Shall we go ahead with the current solution ? >>>>>> >>>>>> I can send out the latest webrev. >>>>>> >>>>>> Let me know your thoughts. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Vivek >>>>>> >>>>>> >>>>>> >>>>>> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>>> *Sent:* Monday, May 02, 2016 3:44 PM >>>>>> *To:* Deshpande, Vivek R >>>>>> *Cc:* Viswanathan, Sandhya; hotspot compiler; >>>>>> hotspot-runtime-dev at openjdk.java.net >>>>>> runtime >>>>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>>>>> control stub generation and intrinsics >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On May 2, 2016, at 11:53 AM, Deshpande, Vivek R >>>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi Christian >>>>>> >>>>>> >>>>>> >>>>>> I had tried using call_VM_leaf() which you mentioned. >>>>>> >>>>>> >>>>>> >>>>>> But this function >>>>>> >>>>>> >>>>>> >>>>>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>>>>> { >>>>>> >>>>>> call_VM_leaf_base(entry_point, number_of_arguments); >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> ends up calling >>>>>> >>>>>> >>>>>> >>>>>> void InterpreterMacroAssembler::call_VM_leaf_base(address >>>>>> entry_point, >>>>>> >>>>>> int number_of_arguments) >>>>>> { ... >>>>>> >>>>>> from interp_masm_x86.cpp instead of >>>>>> >>>>>> >>>>>> >>>>>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>>>>> { ? >>>>>> >>>>>> >>>>>> >>>>>> Frankly, I didn?t know that there is an overload for >>>>>> call_VM_leaf_base in InterpreterMacroAssembler. So this means there are two options: >>>>>> >>>>>> >>>>>> >>>>>> a) Add a method in MacroAssembler to call >>>>>> MacroAssembler::call_VM_leaf_base (what you did) or >>>>>> >>>>>> >>>>>> >>>>>> b) Add InterpreterMacroAssembler::call_VM_leaf and change >>>>>> MacroAssembler::call_VM_leaf to do: >>>>>> >>>>>> >>>>>> >>>>>> voidMacroAssembler::call_VM_leaf(address entry_point, int >>>>>> number_of_arguments) { >>>>>> >>>>>> MacroAssembler::call_VM_leaf_base(entry_point, >>>>>> number_of_arguments); >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> I will let the runtime team decide. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> So I had put mathfunc() to call the masm version of call_VM_leaf_base(). >>>>>> >>>>>> >>>>>> >>>>>> Let me know what you think. >>>>>> >>>>>> >>>>>> >>>>>> Thanks and regards, >>>>>> Vivek >>>>>> >>>>>> >>>>>> >>>>>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>>> *Sent:* Monday, May 02, 2016 1:50 PM >>>>>> *To:* Deshpande, Vivek R >>>>>> *Cc:* hotspot-compiler-dev at openjdk.java.net >>>>>> >>>>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives to >>>>>> control stub generation and intrinsics >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Apr 26, 2016, at 8:53 PM, Deshpande, Vivek R >>>>>> >>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi Christian >>>>>> >>>>>> >>>>>> >>>>>> I have updated the webrev and link for the same is here: >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>>> w >>>>>> ebr >>>>>> ev.03/ >>>>>> >>>>>> I am using mathfunc() to call the masm version of >>>>>> call_VM_leaf_base() and not the InterpreterMacroAssembler version. >>>>>> >>>>>> >>>>>> >>>>>> That?s better but, again, there is nothing math-y about this method: >>>>>> >>>>>> ! void MacroAssembler::mathfunc(address runtime_entry) { >>>>>> >>>>>> MacroAssembler::call_VM_leaf_base(runtime_entry, 0); >>>>>> >>>>>> } >>>>>> >>>>>> Also, there is this method: >>>>>> >>>>>> >>>>>> >>>>>> void MacroAssembler::call_VM_leaf(address entry_point, int number_of_arguments) >>>>>> { >>>>>> >>>>>> call_VM_leaf_base(entry_point, number_of_arguments); >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> which has: >>>>>> >>>>>> >>>>>> >>>>>> void call_VM_leaf(address entry_point, >>>>>> >>>>>> int number_of_arguments = 0); >>>>>> >>>>>> >>>>>> >>>>>> Get rid of mathfunc completely and use call_VM_leaf directly. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Vivek >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>>>> *Sent:* Thursday, April 21, 2016 2:35 PM >>>>>> *To:* Deshpande, Vivek R >>>>> > >>>>>> *Cc:* Nils Eliasson >>>>> >; hotspot-compiler-dev at openjdk.java.net >>>>>> ; Vladimir Kozlov >>>>>> > >>>>>> *Subject:* Re: RFR (S): 8154473: Update for CompilerDirectives >>>>>> to control stub generation and intrinsics >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Apr 20, 2016, at 2:13 PM, Deshpande, Vivek R >>>>>> >>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi >>>>>> >>>>>> >>>>>> >>>>>> The correct URL for the updated webrev is this. >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>>> w >>>>>> ebr >>>>>> ev.02/ >>>>>> >>>>>> >>>>>> >>>>>> +void MacroAssembler::mathfunc(address runtime_entry) { >>>>>> >>>>>> I don?t like the name of this method. Mainly because it?s only >>>>>> aligning the stack (shouldn?t that happen somewhere else?) and >>>>>> doing this 0x20 stack frame thing which I still don?t understand. >>>>>> >>>>>> >>>>>> >>>>>> Right, this is the one I was thinking about: >>>>>> >>>>>> >>>>>> >>>>>> void MacroAssembler::call_VM_leaf_base(address entry_point, int num_args) >>>>>> { >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sorry for the spam. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Vivek >>>>>> >>>>>> >>>>>> >>>>>> *From:* Deshpande, Vivek R >>>>>> *Sent:* Wednesday, April 20, 2016 5:10 PM >>>>>> *To:* Deshpande, Vivek R; 'Nils Eliasson'; >>>>>> 'hotspot-compiler-dev at openjdk.java.net >>>>>> ' >>>>>> *Cc:* 'Vladimir Kozlov'; 'Volker Simonis'; 'Christian >>>>>> Thalinger'; Viswanathan, Sandhya >>>>>> *Subject:* RE: RFR (S): 8154473: Update for >>>>>> CompilerDirectives to control stub generation and >>>>>> intrinsics >>>>>> >>>>>> >>>>>> >>>>>> Sent out the wrong link by mistake. >>>>>> >>>>>> >>>>>> >>>>>> updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>>> w >>>>>> ebrev.02/ >>>>>> >>>>>> >>>>> / >>>>>> web >>>>>> rev.01/> >>>>>> >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Vivek >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* Deshpande, Vivek R >>>>>> *Sent:* Wednesday, April 20, 2016 5:07 PM >>>>>> *To:* 'Nils Eliasson'; hotspot-compiler-dev at openjdk.java.net >>>>>> >>>>>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>>>>> Viswanathan, Sandhya >>>>>> *Subject:* RE: RFR (S): 8154473: Update for >>>>>> CompilerDirectives to control stub generation and >>>>>> intrinsics >>>>>> >>>>>> >>>>>> >>>>>> Hi Nils >>>>>> >>>>>> >>>>>> >>>>>> I have updated the webrev with all the suggestions. >>>>>> >>>>>> updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>>> w >>>>>> ebr >>>>>> ev.01/ >>>>>> >>>>>> Thanks for your comments and review. >>>>>> >>>>>> >>>>>> >>>>>> @Vladimir, >>>>>> >>>>>> I have taken care of all the comments. Would you please >>>>>> review and sponsor the patch. >>>>>> >>>>>> >>>>>> >>>>>> Thanks and regards, >>>>>> >>>>>> Vivek >>>>>> >>>>>> >>>>>> >>>>>> *From:* Nils Eliasson [mailto:nils.eliasson at oracle.com] >>>>>> *Sent:* Wednesday, April 20, 2016 12:27 PM >>>>>> *To:* Deshpande, Vivek >>>>>> R; hotspot-compiler-dev at openjdk.java.net >>>>>> >>>>>> *Cc:* Vladimir Kozlov; Volker Simonis; Christian Thalinger; >>>>>> Viswanathan, Sandhya >>>>>> *Subject:* Re: RFR (S): 8154473: Update for >>>>>> CompilerDirectives to control stub generation and >>>>>> intrinsics >>>>>> >>>>>> >>>>>> >>>>>> In vmSymbols.cpp together with the other flag checks. >>>>>> >>>>>> Regards, >>>>>> Nils >>>>>> >>>>>> On 2016-04-20 02:44, Deshpande, Vivek R wrote: >>>>>> >>>>>> HI Nils >>>>>> >>>>>> >>>>>> >>>>>> Yes you are right the function accesses the command line >>>>>> flag DisableIntrinsic and changes are static. >>>>>> >>>>>> Could you point me the right location for the function ? >>>>>> >>>>>> Also I have updated the webrev with rest of the comments >>>>>> here: >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>>> w >>>>>> ebr >>>>>> ev.01/ >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Vivek >>>>>> >>>>>> >>>>>> >>>>>> *From:* hotspot-compiler-dev >>>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net]*On Behalf >>>>>> Of *Nils Eliasson >>>>>> *Sent:* Tuesday, April 19, 2016 5:55 AM >>>>>> *To:* hotspot-compiler-dev at openjdk.java.net >>>>>> >>>>>> *Subject:* Re: RFR (S): 8154473: Update for >>>>>> CompilerDirectives to control stub generation and >>>>>> intrinsics >>>>>> >>>>>> >>>>>> >>>>>> Hi Vivek, >>>>>> >>>>>> The changes in is_intrinsic_disabled in >>>>>> compilerDirectives.* are static and only access the >>>>>> command line flag DisableIntrinsics. As long as stubs >>>>>> are only generated during startup and don't have a >>>>>> method context - that is ok - but it doesn't belong in >>>>>> the compilerDirectives-files if it doens't use directives. >>>>>> >>>>>> Regards, >>>>>> Nils >>>>>> >>>>>> On 2016-04-18 19:38, Deshpande, Vivek R wrote: >>>>>> >>>>>> Hi all >>>>>> >>>>>> >>>>>> >>>>>> I would like to contribute a patch which helps to >>>>>> control the intrinsics in interpreter, c1 and c2 by >>>>>> disabling the stub generation. >>>>>> >>>>>> This uses -XX:DisableIntrinsic option to achieve the >>>>>> same. >>>>>> >>>>>> Could you please review and sponsor this patch. >>>>>> >>>>>> >>>>>> >>>>>> Bug-id: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8154473 >>>>>> webrev: >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~vdeshpande/CompilerDirectives/8154473/ >>>>>> w >>>>>> ebrev.00/ >>>>>> >>>>>> >>>>> 7 >>>>>> 3/w >>>>>> ebrev.00/> >>>>>> >>>>>> >>>>>> >>>>>> Thanks and regards, >>>>>> >>>>>> Vivek >>>>>> >>>>>> >>>>>> From tom.rodriguez at oracle.com Thu May 19 02:45:50 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 18 May 2016 19:45:50 -0700 Subject: RFR 8157292: [JVMCI] add missing test files from 8156034 Message-ID: <182BE040-E94D-4AD4-BBDE-F3F4826B0734@oracle.com> http://cr.openjdk.java.net/~never/8157292/webrev https://bugs.openjdk.java.net/browse/JDK-8157292 When I pushed 8156034 I missed some test files from the webrev. tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From ningsheng.jian at linaro.org Thu May 19 02:55:56 2016 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Thu, 19 May 2016 10:55:56 +0800 Subject: [aarch64-port-dev ] RFR: 8156839 : aarch64: indexOf does not support CompactStrings In-Reply-To: References: <1463060614.24642.8.camel@mint> <57348A95.7080707@redhat.com> <1463063413.24642.22.camel@mint> <5739C2D4.5000401@redhat.com> Message-ID: Do we really need LU support for indexOf? In String.java implementation, the LU indexOf always returns -1. Thanks, Ningsheng On 18 May 2016 at 21:10, Edward Nevill wrote: > Hi, > > On Mon, May 16, 2016 at 1:53 PM, Andrew Haley wrote: > >> >> >> So yes, we do have to cope with all of the combinations. >> > > Please review the following webrev which handles all combinations. > > http://cr.openjdk.java.net/~enevill/8156839/webrev.02/ > > Tested with fastdebug jtreg hotspot & langtools > > Before: > > hotspot: Test results: passed: 1,163; failed: 62; error: 41 > langtools: Test results: passed: 3,503; failed: 97; error: 29 > > After: > > hotspot: Test results: passed: 1,166; failed: 60; error: 40 > langtools: Test results: passed: 3,503; failed: 97; error: 29 > > All the best, > Ed. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Thu May 19 07:45:45 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 May 2016 08:45:45 +0100 Subject: [aarch64-port-dev ] RFR: 8156839 : aarch64: indexOf does not support CompactStrings In-Reply-To: References: <1463060614.24642.8.camel@mint> <57348A95.7080707@redhat.com> <1463063413.24642.22.camel@mint> <5739C2D4.5000401@redhat.com> Message-ID: <573D6F29.1020008@redhat.com> On 05/19/2016 03:55 AM, Ningsheng Jian wrote: > Do we really need LU support for indexOf? In String.java implementation, > the LU indexOf always returns -1. I understand the argument, but I don't think that there is any point taking it out. Andrew. From nils.eliasson at oracle.com Thu May 19 11:33:22 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 19 May 2016 13:33:22 +0200 Subject: [9] RFR(S): 8155108: CompilerControl: Enable option set incorrectly Message-ID: <573DA482.303@oracle.com> Hi, Please review, Summary: This patches removes the special treatment of "enable"-option in directives parsing. In early version Enable was not part of the directive but a special case in the parser. This was refactored into more general code where the Enable-option was parsed and accessed like any other option. Somewhere along the way the old code was not removed properly. That code contains a bug where the argument to the set-function is casted improperly causing test failures on sparc. Testing: All jtreg tests on all platforms. Running. Bug: https://bugs.openjdk.java.net/browse/JDK-8155108 Webrev: http://cr.openjdk.java.net/~neliasso/8155108/webrev.01/ Best regards, Nils Eliasson From igor.veresov at oracle.com Thu May 19 16:45:07 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 19 May 2016 09:45:07 -0700 Subject: RFR 8157292: [JVMCI] add missing test files from 8156034 In-Reply-To: <182BE040-E94D-4AD4-BBDE-F3F4826B0734@oracle.com> References: <182BE040-E94D-4AD4-BBDE-F3F4826B0734@oracle.com> Message-ID: <0D4D57A4-D065-473D-A259-BF9641092913@oracle.com> Looks good. igor > On May 18, 2016, at 7:45 PM, Tom Rodriguez wrote: > > http://cr.openjdk.java.net/~never/8157292/webrev > https://bugs.openjdk.java.net/browse/JDK-8157292 > > When I pushed 8156034 I missed some test files from the webrev. > > tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Thu May 19 17:45:45 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 19 May 2016 20:45:45 +0300 Subject: [8u/9] RFR (S): 8154831: CastII/ConvI2L for a range check is prematurely eliminated Message-ID: http://cr.openjdk.java.net/~vlivanov/8154831/webrev.9.00/ http://cr.openjdk.java.net/~vlivanov/8154831/webrev.8u.00/ https://bugs.openjdk.java.net/browse/JDK-8154831 CastII node prematurely goes away and causes a cascade of other eliminations which severely corrupts the graph (the actual crash happens due to a memory edge coming from a non-dominating region). CastII is replaced with TOP due to a type conflict (ranges don't intersect) between the actual type of the value being range checked and the type CastII tries to assign. It happens on effectively dead path (range check always fails) which C2 can't eliminate due to a missing transformation for CmpU: Bool [lt] (CmpU (ConI #-1) (? #int)) => (ConI #0) The fix is to add the missing case in CmpUNode::sub(). It enables dead path elimination along with CastII. Also, fixed a couple of missing cases in 8u (not applicable in 9): * CastII nodes shouldn't be eliminated during CCP pass; * CastII comparion should take _range_check_dependency flag into account. Testing: * JPRT (8u/9); * RBT for 9 (hs-tier0-comp - in progress); * replay of problematic compilation (8u). Thanks! Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Thu May 19 18:25:07 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 May 2016 11:25:07 -0700 Subject: [8u/9] RFR (S): 8154831: CastII/ConvI2L for a range check is prematurely eliminated In-Reply-To: References: Message-ID: Can you make subnode.cpp changes in jdk9 and 8u similar? Why CastIINode::cmp() returns uint? Thanks, Vladimir On 5/19/16 10:45 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8154831/webrev.9.00/ > http://cr.openjdk.java.net/~vlivanov/8154831/webrev.8u.00/ > https://bugs.openjdk.java.net/browse/JDK-8154831 > > CastII node prematurely goes away and causes a cascade of other > eliminations which severely corrupts the graph (the actual crash happens > due to a memory edge coming from a non-dominating region). > > CastII is replaced with TOP due to a type conflict (ranges don't > intersect) between the actual type of the value being range checked and > the type CastII tries to assign. > > It happens on effectively dead path (range check always fails) which C2 > can't eliminate due to a missing transformation for CmpU: > > Bool [lt] (CmpU (ConI #-1) (? #int)) => (ConI #0) > > The fix is to add the missing case in CmpUNode::sub(). It enables dead > path elimination along with CastII. > > Also, fixed a couple of missing cases in 8u (not applicable in 9): > * CastII nodes shouldn't be eliminated during CCP pass; > * CastII comparion should take _range_check_dependency flag into account. > > Testing: > * JPRT (8u/9); > * RBT for 9 (hs-tier0-comp - in progress); > * replay of problematic compilation (8u). > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Thu May 19 18:33:10 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 May 2016 11:33:10 -0700 Subject: [9] RFR(S): 8155108: CompilerControl: Enable option set incorrectly In-Reply-To: <573DA482.303@oracle.com> References: <573DA482.303@oracle.com> Message-ID: <9270b0d2-c09e-ff83-985b-7d91c2d3ea74@oracle.com> Looks good. Thanks, Vladimir On 5/19/16 4:33 AM, Nils Eliasson wrote: > Hi, > > Please review, > > Summary: > This patches removes the special treatment of "enable"-option in > directives parsing. In early version Enable was not part of the > directive but a special case in the parser. This was refactored into > more general code where the Enable-option was parsed and accessed like > any other option. Somewhere along the way the old code was not removed > properly. That code contains a bug where the argument to the > set-function is casted improperly causing test failures on sparc. > > Testing: > All jtreg tests on all platforms. Running. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155108 > Webrev: http://cr.openjdk.java.net/~neliasso/8155108/webrev.01/ > > Best regards, > Nils Eliasson From vladimir.x.ivanov at oracle.com Thu May 19 20:29:59 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 19 May 2016 23:29:59 +0300 Subject: [8u/9] RFR (S): 8154831: CastII/ConvI2L for a range check is prematurely eliminated In-Reply-To: References: Message-ID: <0ba6a057-d252-0dd2-7157-73772dffddf8@oracle.com> Thanks for the feedback, Vladimir. > Can you make subnode.cpp changes in jdk9 and 8u similar? Fixed. Updated webrev.9.00 in place. > Why CastIINode::cmp() returns uint? That's how Node::cmp() is declared: virtual uint cmp( const Node &n ) const; Best regards, Vladimir Ivanov > On 5/19/16 10:45 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.9.00/ >> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.8u.00/ >> https://bugs.openjdk.java.net/browse/JDK-8154831 >> >> CastII node prematurely goes away and causes a cascade of other >> eliminations which severely corrupts the graph (the actual crash happens >> due to a memory edge coming from a non-dominating region). >> >> CastII is replaced with TOP due to a type conflict (ranges don't >> intersect) between the actual type of the value being range checked and >> the type CastII tries to assign. >> >> It happens on effectively dead path (range check always fails) which C2 >> can't eliminate due to a missing transformation for CmpU: >> >> Bool [lt] (CmpU (ConI #-1) (? #int)) => (ConI #0) >> >> The fix is to add the missing case in CmpUNode::sub(). It enables dead >> path elimination along with CastII. >> >> Also, fixed a couple of missing cases in 8u (not applicable in 9): >> * CastII nodes shouldn't be eliminated during CCP pass; >> * CastII comparion should take _range_check_dependency flag into >> account. >> >> Testing: >> * JPRT (8u/9); >> * RBT for 9 (hs-tier0-comp - in progress); >> * replay of problematic compilation (8u). >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From vladimir.kozlov at oracle.com Thu May 19 20:44:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 May 2016 13:44:35 -0700 Subject: [8u/9] RFR (S): 8154831: CastII/ConvI2L for a range check is prematurely eliminated In-Reply-To: <0ba6a057-d252-0dd2-7157-73772dffddf8@oracle.com> References: <0ba6a057-d252-0dd2-7157-73772dffddf8@oracle.com> Message-ID: <6dc46a38-fbba-967f-11a6-a76c36774690@oracle.com> On 5/19/16 1:29 PM, Vladimir Ivanov wrote: > Thanks for the feedback, Vladimir. > >> Can you make subnode.cpp changes in jdk9 and 8u similar? > > Fixed. Updated webrev.9.00 in place. Good. > >> Why CastIINode::cmp() returns uint? > > That's how Node::cmp() is declared: > > virtual uint cmp( const Node &n ) const; Please files starter RFE to fix it. I looked and result us used as bool. Thanks, Vladimir > > Best regards, > Vladimir Ivanov > >> On 5/19/16 10:45 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.9.00/ >>> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.8u.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8154831 >>> >>> CastII node prematurely goes away and causes a cascade of other >>> eliminations which severely corrupts the graph (the actual crash happens >>> due to a memory edge coming from a non-dominating region). >>> >>> CastII is replaced with TOP due to a type conflict (ranges don't >>> intersect) between the actual type of the value being range checked and >>> the type CastII tries to assign. >>> >>> It happens on effectively dead path (range check always fails) which C2 >>> can't eliminate due to a missing transformation for CmpU: >>> >>> Bool [lt] (CmpU (ConI #-1) (? #int)) => (ConI #0) >>> >>> The fix is to add the missing case in CmpUNode::sub(). It enables dead >>> path elimination along with CastII. >>> >>> Also, fixed a couple of missing cases in 8u (not applicable in 9): >>> * CastII nodes shouldn't be eliminated during CCP pass; >>> * CastII comparion should take _range_check_dependency flag into >>> account. >>> >>> Testing: >>> * JPRT (8u/9); >>> * RBT for 9 (hs-tier0-comp - in progress); >>> * replay of problematic compilation (8u). >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Thu May 19 21:07:04 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 20 May 2016 00:07:04 +0300 Subject: [8u/9] RFR (S): 8154831: CastII/ConvI2L for a range check is prematurely eliminated In-Reply-To: <6dc46a38-fbba-967f-11a6-a76c36774690@oracle.com> References: <0ba6a057-d252-0dd2-7157-73772dffddf8@oracle.com> <6dc46a38-fbba-967f-11a6-a76c36774690@oracle.com> Message-ID: Thanks, Vladimir. >>> Why CastIINode::cmp() returns uint? >> >> That's how Node::cmp() is declared: >> >> virtual uint cmp( const Node &n ) const; > > Please files starter RFE to fix it. I looked and result us used as bool. Done: https://bugs.openjdk.java.net/browse/JDK-8157372 Best regards, Vladimir Ivanov >>> On 5/19/16 10:45 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.9.00/ >>>> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.8u.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8154831 >>>> >>>> CastII node prematurely goes away and causes a cascade of other >>>> eliminations which severely corrupts the graph (the actual crash >>>> happens >>>> due to a memory edge coming from a non-dominating region). >>>> >>>> CastII is replaced with TOP due to a type conflict (ranges don't >>>> intersect) between the actual type of the value being range checked and >>>> the type CastII tries to assign. >>>> >>>> It happens on effectively dead path (range check always fails) which C2 >>>> can't eliminate due to a missing transformation for CmpU: >>>> >>>> Bool [lt] (CmpU (ConI #-1) (? #int)) => (ConI #0) >>>> >>>> The fix is to add the missing case in CmpUNode::sub(). It enables dead >>>> path elimination along with CastII. >>>> >>>> Also, fixed a couple of missing cases in 8u (not applicable in 9): >>>> * CastII nodes shouldn't be eliminated during CCP pass; >>>> * CastII comparion should take _range_check_dependency flag into >>>> account. >>>> >>>> Testing: >>>> * JPRT (8u/9); >>>> * RBT for 9 (hs-tier0-comp - in progress); >>>> * replay of problematic compilation (8u). >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov From tobias.hartmann at oracle.com Fri May 20 06:35:28 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 20 May 2016 08:35:28 +0200 Subject: [8u/9] RFR (S): 8154831: CastII/ConvI2L for a range check is prematurely eliminated In-Reply-To: References: Message-ID: <573EB030.8030408@oracle.com> Hi Vladimir, thanks a lot for fixing this! On 19.05.2016 19:45, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8154831/webrev.9.00/ > http://cr.openjdk.java.net/~vlivanov/8154831/webrev.8u.00/ > https://bugs.openjdk.java.net/browse/JDK-8154831 Looks good to me! > CastII node prematurely goes away and causes a cascade of other eliminations which severely corrupts the graph (the actual crash happens due to a memory edge coming from a non-dominating region). > > CastII is replaced with TOP due to a type conflict (ranges don't intersect) between the actual type of the value being range checked and the type CastII tries to assign. > > It happens on effectively dead path (range check always fails) which C2 can't eliminate due to a missing transformation for CmpU: > > Bool [lt] (CmpU (ConI #-1) (? #int)) => (ConI #0) > > The fix is to add the missing case in CmpUNode::sub(). It enables dead path elimination along with CastII. We discussed this already offline but I still wonder if it can happen that even if we would eliminate the range check, we replace the CastII first (due to IGVN ordering) and crash before the range check is eliminated? > Also, fixed a couple of missing cases in 8u (not applicable in 9): > * CastII nodes shouldn't be eliminated during CCP pass; > * CastII comparion should take _range_check_dependency flag into account. Thanks, I missed this in the backport because the code is different in 9. Best regards, Tobias > > Testing: > * JPRT (8u/9); > * RBT for 9 (hs-tier0-comp - in progress); > * replay of problematic compilation (8u). > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri May 20 11:57:36 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 20 May 2016 14:57:36 +0300 Subject: [8u/9] RFR (S): 8154831: CastII/ConvI2L for a range check is prematurely eliminated In-Reply-To: <573EB030.8030408@oracle.com> References: <573EB030.8030408@oracle.com> Message-ID: <46476e21-cf49-2133-84d9-24d08fe33798@oracle.com> >> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.9.00/ >> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.8u.00/ >> https://bugs.openjdk.java.net/browse/JDK-8154831 > > Looks good to me! Thanks, Tobias. >> CastII node prematurely goes away and causes a cascade of other eliminations which severely corrupts the graph (the actual crash happens due to a memory edge coming from a non-dominating region). >> >> CastII is replaced with TOP due to a type conflict (ranges don't intersect) between the actual type of the value being range checked and the type CastII tries to assign. >> >> It happens on effectively dead path (range check always fails) which C2 can't eliminate due to a missing transformation for CmpU: >> >> Bool [lt] (CmpU (ConI #-1) (? #int)) => (ConI #0) >> >> The fix is to add the missing case in CmpUNode::sub(). It enables dead path elimination along with CastII. > > We discussed this already offline but I still wonder if it can happen that even if we would eliminate the range check, we replace the CastII first (due to IGVN ordering) and crash before the range check is eliminated? I verified that the ordering is not a problem. If both range check and dependent CastII/ConvI2L nodes go away during the same IGVN pass, then the compiler encounters correct graph on the next iteration of loop optimization pass. Best regards, Vladimir Ivanov From tobias.hartmann at oracle.com Fri May 20 11:59:22 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 20 May 2016 13:59:22 +0200 Subject: [8u/9] RFR (S): 8154831: CastII/ConvI2L for a range check is prematurely eliminated In-Reply-To: <46476e21-cf49-2133-84d9-24d08fe33798@oracle.com> References: <573EB030.8030408@oracle.com> <46476e21-cf49-2133-84d9-24d08fe33798@oracle.com> Message-ID: <573EFC1A.7090203@oracle.com> Hi Vladimir, On 20.05.2016 13:57, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.9.00/ >>> http://cr.openjdk.java.net/~vlivanov/8154831/webrev.8u.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8154831 >> >> Looks good to me! > > Thanks, Tobias. > >>> CastII node prematurely goes away and causes a cascade of other eliminations which severely corrupts the graph (the actual crash happens due to a memory edge coming from a non-dominating region). >>> >>> CastII is replaced with TOP due to a type conflict (ranges don't intersect) between the actual type of the value being range checked and the type CastII tries to assign. >>> >>> It happens on effectively dead path (range check always fails) which C2 can't eliminate due to a missing transformation for CmpU: >>> >>> Bool [lt] (CmpU (ConI #-1) (? #int)) => (ConI #0) >>> >>> The fix is to add the missing case in CmpUNode::sub(). It enables dead path elimination along with CastII. >> >> We discussed this already offline but I still wonder if it can happen that even if we would eliminate the range check, we replace the CastII first (due to IGVN ordering) and crash before the range check is eliminated? > > I verified that the ordering is not a problem. If both range check and dependent CastII/ConvI2L nodes go away during the same IGVN pass, then the compiler encounters correct graph on the next iteration of loop optimization pass. Okay, thanks for clarifying! Best regards, Tobias > > Best regards, > Vladimir Ivanov From edward.nevill at gmail.com Fri May 20 14:46:23 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 20 May 2016 15:46:23 +0100 Subject: RFR: 8156943: aarch64: string compare does not support CompactStrings Message-ID: Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8156943/webrev.01/ This adds support for LL, LU and UL encodings of StrComp Tested with fastdebug build on jtreg hotspot & langtools. Regards, Ed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.schatz at oracle.com Fri May 20 15:12:38 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Fri, 20 May 2016 17:12:38 +0200 Subject: RFR(S): 8157428: [JVMCI] remove MemoryAccessProvider.readUnsafeConstant from API Message-ID: <573F2966.10900@oracle.com> Hi, Please review this small cleanup change: http://cr.openjdk.java.net/~rschatz/JDK-8157428/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8157428 This just changes a public method to package-private (and moves the JavaDoc over, no reason to delete it just because it's no longer public API). This should really have been in the recent cleanup (JDK-8156835), but somehow it slipped through. Thanks, Roland From dmitrij.pochepko at oracle.com Fri May 20 16:19:12 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 20 May 2016 19:19:12 +0300 Subject: RFR(S): 8157438 - JVMCI: MaterializeVirtualObjectTest fails w/ "CASE: invalidate=true: has no virtual object before" Message-ID: <573F3900.1030305@oracle.com> Hi, please review fix for 8157438 - JVMCI: MaterializeVirtualObjectTest fails w/ "CASE: invalidate=true: has no virtual object before" The reason was a test bug: compile threshold was calculated, but not correctly used, so, incorrect value was used in case of non-tiered mode. webrev: http://cr.openjdk.java.net/~dpochepk/8157438/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8157438 I've tested this fix on linux_x64 Thanks, Dmitrij From dmitrij.pochepko at oracle.com Fri May 20 16:43:48 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 20 May 2016 19:43:48 +0300 Subject: RFR: 8156470 - [JITtester] EOL on Windows Message-ID: <573F3EC4.1020508@oracle.com> Hi, please review patch for JDK-8156470 - [JITtester] EOL on Windows The problem is that generated tests are failing on windows because of different EOL on windows/linux(\r\n and \n respectively). So, tests generation code was modified to have no println usage for stdout(thus, no OS-specific EOL is used). Also, stdout and stderr comparison code was modified accordingly. webrev: http://cr.openjdk.java.net/~dpochepk/8156470/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8156470 I've verified this patch on linux and windows platforms Thanks, Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri May 20 16:49:33 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 20 May 2016 09:49:33 -0700 Subject: RFR(S): 8157438 - JVMCI: MaterializeVirtualObjectTest fails w/ "CASE: invalidate=true: has no virtual object before" In-Reply-To: <573F3900.1030305@oracle.com> References: <573F3900.1030305@oracle.com> Message-ID: Good. Thanks, Vladimir On 5/20/16 9:19 AM, Dmitrij Pochepko wrote: > Hi, > > please review fix for 8157438 - JVMCI: MaterializeVirtualObjectTest > fails w/ "CASE: invalidate=true: has no virtual object before" > The reason was a test bug: compile threshold was calculated, but not > correctly used, so, incorrect value was used in case of non-tiered mode. > > webrev: http://cr.openjdk.java.net/~dpochepk/8157438/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8157438 > > I've tested this fix on linux_x64 > > Thanks, > Dmitrij From vladimir.kozlov at oracle.com Fri May 20 16:49:52 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 20 May 2016 09:49:52 -0700 Subject: RFR: 8156470 - [JITtester] EOL on Windows In-Reply-To: <573F3EC4.1020508@oracle.com> References: <573F3EC4.1020508@oracle.com> Message-ID: <46d2c396-c02e-dc08-f9f7-2ba9d77c511c@oracle.com> Looks good. Thanks, Vladimir On 5/20/16 9:43 AM, Dmitrij Pochepko wrote: > Hi, > > please review patch for JDK-8156470 - [JITtester] EOL on Windows > > The problem is that generated tests are failing on windows because of > different EOL on windows/linux(\r\n and \n respectively). So, tests > generation code was modified to have no println usage for stdout(thus, > no OS-specific EOL is used). > Also, stdout and stderr comparison code was modified accordingly. > > webrev: http://cr.openjdk.java.net/~dpochepk/8156470/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8156470 > > I've verified this patch on linux and windows platforms > > Thanks, > Dmitrij From dmitrij.pochepko at oracle.com Fri May 20 17:17:53 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 20 May 2016 20:17:53 +0300 Subject: RFR(S): 8157438 - JVMCI: MaterializeVirtualObjectTest fails w/ "CASE: invalidate=true: has no virtual object before" In-Reply-To: References: <573F3900.1030305@oracle.com> Message-ID: <573F46C1.8020103@oracle.com> Thank you! > Good. > > Thanks, > Vladimir > > On 5/20/16 9:19 AM, Dmitrij Pochepko wrote: >> Hi, >> >> please review fix for 8157438 - JVMCI: MaterializeVirtualObjectTest >> fails w/ "CASE: invalidate=true: has no virtual object before" >> The reason was a test bug: compile threshold was calculated, but not >> correctly used, so, incorrect value was used in case of non-tiered mode. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8157438/webrev.01/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8157438 >> >> I've tested this fix on linux_x64 >> >> Thanks, >> Dmitrij From igor.veresov at oracle.com Fri May 20 18:58:52 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 20 May 2016 11:58:52 -0700 Subject: RFR(S): 8157428: [JVMCI] remove MemoryAccessProvider.readUnsafeConstant from API In-Reply-To: <573F2966.10900@oracle.com> References: <573F2966.10900@oracle.com> Message-ID: Seems ok. igor > On May 20, 2016, at 8:12 AM, Roland Schatz wrote: > > Hi, > > Please review this small cleanup change: > http://cr.openjdk.java.net/~rschatz/JDK-8157428/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8157428 > > This just changes a public method to package-private (and moves the JavaDoc over, no reason to delete it just because it's no longer public API). > This should really have been in the recent cleanup (JDK-8156835), but somehow it slipped through. > > Thanks, > Roland From zoltan.majo at oracle.com Mon May 23 11:00:22 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 23 May 2016 13:00:22 +0200 Subject: [9] RFR (XS): 8157560: Reserve space for allocation prefetch only in builds that support allocation prefetching Message-ID: <5742E2C6.3050004@oracle.com> Hi, please review the path for 8157560. https://bugs.openjdk.java.net/browse/JDK-8157560 Problem: Every thread-local allocation buffer (TLAB) contains a reserved area to accommodate allocation prefetches (i.e., to make sure that instructions performing allocation prefetch do not cause faults). The reserved area is at the end of the TLAB. Currently, all the reserved area is created in all builds, even though only the C2 compiler generates allocation prefetches. As a result, in builds without C2, some heap space is wasted at the end of each TLAB. Creating the reserved area also causes problems for internal testing of the AllocatePrefetchLines/AllocateInstancePrefetchLines command-line flags. Solution: Create the reserved area only in C2-enabled builds. Re-enable testing of the AllocatePrefetchLines/AllocateInstancePrefetchLines flags. Webrev: http://cr.openjdk.java.net/~zmajo/8157560/webrev.00/ Testing: - JPRT; - pre-PIT RBT in progress; - internal tests -- all pass. I plan to push the fix directly into hs as testing of AllocatePrefetchLines/AllocateInstancePrefetchLines is disabled only in hs. Thank you! Best regards, Zoltan From tobias.hartmann at oracle.com Mon May 23 11:19:49 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 23 May 2016 13:19:49 +0200 Subject: [9] RFR (XS): 8157560: Reserve space for allocation prefetch only in builds that support allocation prefetching In-Reply-To: <5742E2C6.3050004@oracle.com> References: <5742E2C6.3050004@oracle.com> Message-ID: <5742E755.5010202@oracle.com> Hi Zoltan, On 23.05.2016 13:00, Zolt?n Maj? wrote: > Hi, > > > please review the path for 8157560. > > https://bugs.openjdk.java.net/browse/JDK-8157560 > > Problem: Every thread-local allocation buffer (TLAB) contains a reserved area to accommodate allocation prefetches (i.e., to make sure that instructions performing allocation prefetch do not cause faults). The reserved area is at the end of the TLAB. > > Currently, all the reserved area is created in all builds, even though only the C2 compiler generates allocation prefetches. As a result, in builds without C2, some heap space is wasted at the end of each TLAB. Creating the reserved area also causes problems for internal testing of the AllocatePrefetchLines/AllocateInstancePrefetchLines command-line flags. > > Solution: Create the reserved area only in C2-enabled builds. Re-enable testing of the AllocatePrefetchLines/AllocateInstancePrefetchLines flags. This looks good to me! Best regards, Tobias > > Webrev: > http://cr.openjdk.java.net/~zmajo/8157560/webrev.00/ > > Testing: > - JPRT; > - pre-PIT RBT in progress; > - internal tests -- all pass. > > I plan to push the fix directly into hs as testing of AllocatePrefetchLines/AllocateInstancePrefetchLines is disabled only in hs. > > Thank you! > > Best regards, > > > Zoltan > From vladimir.kozlov at oracle.com Mon May 23 17:35:11 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 23 May 2016 10:35:11 -0700 Subject: [9] RFR (XS): 8157560: Reserve space for allocation prefetch only in builds that support allocation prefetching In-Reply-To: <5742E2C6.3050004@oracle.com> References: <5742E2C6.3050004@oracle.com> Message-ID: Looks good. thanks, Vladimir On 5/23/16 4:00 AM, Zolt?n Maj? wrote: > Hi, > > > please review the path for 8157560. > > https://bugs.openjdk.java.net/browse/JDK-8157560 > > Problem: Every thread-local allocation buffer (TLAB) contains a reserved > area to accommodate allocation prefetches (i.e., to make sure that > instructions performing allocation prefetch do not cause faults). The > reserved area is at the end of the TLAB. > > Currently, all the reserved area is created in all builds, even though > only the C2 compiler generates allocation prefetches. As a result, in > builds without C2, some heap space is wasted at the end of each TLAB. > Creating the reserved area also causes problems for internal testing of > the AllocatePrefetchLines/AllocateInstancePrefetchLines command-line flags. > > Solution: Create the reserved area only in C2-enabled builds. Re-enable > testing of the AllocatePrefetchLines/AllocateInstancePrefetchLines flags. > > Webrev: > http://cr.openjdk.java.net/~zmajo/8157560/webrev.00/ > > Testing: > - JPRT; > - pre-PIT RBT in progress; > - internal tests -- all pass. > > I plan to push the fix directly into hs as testing of > AllocatePrefetchLines/AllocateInstancePrefetchLines is disabled only in hs. > > Thank you! > > Best regards, > > > Zoltan > From zoltan.majo at oracle.com Tue May 24 06:49:47 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 24 May 2016 08:49:47 +0200 Subject: [9] RFR (XS): 8157560: Reserve space for allocation prefetch only in builds that support allocation prefetching In-Reply-To: References: <5742E2C6.3050004@oracle.com> Message-ID: <5743F98B.4000100@oracle.com> Thank you for the review, Vladimir and Tobias! Best regards, Zoltan From edward.nevill at gmail.com Tue May 24 08:26:37 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 24 May 2016 09:26:37 +0100 Subject: RFR: 8156943: aarch64: string compare does not support CompactStrings In-Reply-To: <573F34A2.70108@redhat.com> References: <573F25DA.8000202@redhat.com> <573F34A2.70108@redhat.com> Message-ID: <1464078397.31264.25.camel@mylittlepony.linaroharston> On Fri, 2016-05-20 at 17:00 +0100, Andrew Haley wrote: > On 05/20/2016 04:56 PM, Edward Nevill wrote: > > fcmpd(vtmpZ, 0.0) generates EQ iff the lower 64 bits of vtmpZ are 0 > > otherwise NE. > > > > If it is the case that fcmpd generates EQ for some bit pattern other than > > all 64 bits 0 then indeed it is broken. > > There are two zeroes, +0 and -0. > > Andrew. The following webrev fixes this by instead moving the simd registers to general registers. 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, All the best, Ed. From aph at redhat.com Tue May 24 08:33:39 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 May 2016 09:33:39 +0100 Subject: RFR: 8156943: aarch64: string compare does not support CompactStrings In-Reply-To: <1464078397.31264.25.camel@mylittlepony.linaroharston> References: <573F25DA.8000202@redhat.com> <573F34A2.70108@redhat.com> <1464078397.31264.25.camel@mylittlepony.linaroharston> Message-ID: <574411E3.70806@redhat.com> 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. Andrew. From edward.nevill at gmail.com Tue May 24 08:59:39 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 24 May 2016 09:59:39 +0100 Subject: [9] RFR (XS): 8157560: Reserve space for allocation prefetch only in builds that support allocation prefetching In-Reply-To: <5742E2C6.3050004@oracle.com> References: <5742E2C6.3050004@oracle.com> Message-ID: <1464080379.31264.32.camel@mylittlepony.linaroharston> Hi Zolt?n, On Mon, 2016-05-23 at 13:00 +0200, Zolt?n Maj? wrote: > Hi, > > > please review the path for 8157560. > > https://bugs.openjdk.java.net/browse/JDK-8157560 > > Problem: Every thread-local allocation buffer (TLAB) contains a reserved > area to accommodate allocation prefetches (i.e., to make sure that > instructions performing allocation prefetch do not cause faults). The > reserved area is at the end of the TLAB. On certain architectures (eg aarch64) prefetch will not cause faults. On these allocating the extra space is redundant. Is it possible to have this predicated on a pd_ variable (eg AllocateExtraTLAB which can be true for those arches that require it and false for those that don't) rather than having it just conditionalised on COMPILER2. All the best, Ed. From zoltan.majo at oracle.com Tue May 24 10:13:53 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 24 May 2016 12:13:53 +0200 Subject: [9] RFR (XS): 8157560: Reserve space for allocation prefetch only in builds that support allocation prefetching In-Reply-To: <1464080379.31264.32.camel@mylittlepony.linaroharston> References: <5742E2C6.3050004@oracle.com> <1464080379.31264.32.camel@mylittlepony.linaroharston> Message-ID: <57442961.5000106@oracle.com> Hi Ed, thank you for the feedback! On 05/24/2016 10:59 AM, Edward Nevill wrote: > Hi Zolt?n, > > On Mon, 2016-05-23 at 13:00 +0200, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the path for 8157560. >> >> https://bugs.openjdk.java.net/browse/JDK-8157560 >> >> Problem: Every thread-local allocation buffer (TLAB) contains a reserved >> area to accommodate allocation prefetches (i.e., to make sure that >> instructions performing allocation prefetch do not cause faults). The >> reserved area is at the end of the TLAB. > On certain architectures (eg aarch64) prefetch will not cause faults. On > these allocating the extra space is redundant. yes, that is true. As far as I'm aware, faulting instructions are currently generated only on SPARC (with the combination -XX:AllocatePrefetchInstr=1 -XX:AllocatePrefetchStyle=3) > Is it possible to have this predicated on a pd_ variable (eg > AllocateExtraTLAB which can be true for those arches that require it and > false for those that don't) rather than having it just conditionalised > on COMPILER2. I agree. Making the allocation of the reserved region dependent on a more precise condition is certainly a good idea. But maybe we don't need to introduce a new flag for that. An appropriate condition would probably be: if (Complevel_highest_tier == CompLevel_full_optimization && AllocatePrefetchStyle == 3 && AllocatePrefetchInstr == 1) What do you (and others) think? Thanks, Zoltan > > All the best, > Ed. > > From nils.eliasson at oracle.com Tue May 24 14:09:55 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 24 May 2016 16:09:55 +0200 Subject: [9] RFR(S/M): Crash with assert(pd != 0L) failed: PcDesc must not be NULL Message-ID: <574460B3.3040601@oracle.com> Hi all, Please review. Summary: The VM fails on "assert(pd != 0L) failed: PcDesc must not be NULL" when walking the Java frames on the stack after hitting a stack overflow. The asserts triggers when the trying to find the BCI of an address in an nmethod. This assert belongs to stack walking code introduced by JDK-8046936 "JEP 270: Reserved Stack Areas for Critical Sections". The BCI is not relevant for this code, as we only need the method to find the annotation. The similar stack walking code in java_lang_Throwable::fill_in_stack_trace in javaClasses.cpp do not have the assert in the same position suggesting the assert may have been to strong. This fix also makes this bug stop reproducing: https://bugs.openjdk.java.net/browse/JDK-8156659 "assert(CodeCache::find_blob_unsafe(_pc) == _cb) failed: inconsistent." Solution: I have rewritten and simplified the stack walking code in SharedRuntime::look_for_reserved_stack_annotated_method removing the lookup of BCI. Testing: Run :hotspot_all on all platforms with and without -Xcomp Separately run all uncommontrap tests and the test ReservedStackTest written for JEP270. Bug: https://bugs.openjdk.java.net/browse/JDK-8153352 Webrev: http://cr.openjdk.java.net/~neliasso/8153352/webrev.01/ Best regards, Nils Eliasson -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue May 24 15:55:38 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 May 2016 08:55:38 -0700 Subject: [9] RFR(S/M): Crash with assert(pd != 0L) failed: PcDesc must not be NULL In-Reply-To: <574460B3.3040601@oracle.com> References: <574460B3.3040601@oracle.com> Message-ID: Looks good to me. But please, run RBT too before pushing. Thanks, Vladimir On 5/24/16 7:09 AM, Nils Eliasson wrote: > Hi all, > > Please review. > > Summary: > The VM fails on "assert(pd != 0L) failed: PcDesc must not be NULL" when > walking the Java frames on the stack after hitting a stack overflow. > > The asserts triggers when the trying to find the BCI of an address in an > nmethod. This assert belongs to stack walking code introduced by > JDK-8046936 "JEP 270: Reserved Stack Areas for Critical Sections". The > BCI is not relevant for this code, as we only need the method to find > the annotation. The similar stack walking code in > java_lang_Throwable::fill_in_stack_trace in javaClasses.cpp do not have > the assert in the same position suggesting the assert may have been to > strong. > > This fix also makes this bug stop reproducing: > https://bugs.openjdk.java.net/browse/JDK-8156659 > "assert(CodeCache::find_blob_unsafe(_pc) == _cb) failed: inconsistent." > > Solution: > I have rewritten and simplified the stack walking code in > SharedRuntime::look_for_reserved_stack_annotated_method removing the > lookup of BCI. > > Testing: > Run :hotspot_all on all platforms with and without -Xcomp > Separately run all uncommontrap tests and the test ReservedStackTest > written for JEP270. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153352 > Webrev: http://cr.openjdk.java.net/~neliasso/8153352/webrev.01/ > > Best regards, > Nils Eliasson > > From dmitrij.pochepko at oracle.com Tue May 24 18:50:33 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 24 May 2016 21:50:33 +0300 Subject: RFR(XS): 8156585 - Cosmetic: AARCH64 defines in c1_LIRAssembler_aarch64.hpp Message-ID: <5744A279.7030800@oracle.com> Hi, please review small fix for 8156585 - Cosmetic: AARCH64 defines in c1_LIRAssembler_aarch64.hpp It's a renaming of guard macro parameter to have name adjusted with architecture name. webrev: http://cr.openjdk.java.net/~dpochepk/8156585/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8156585 Thanks, Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue May 24 19:07:18 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 May 2016 12:07:18 -0700 Subject: RFR(XS): 8156585 - Cosmetic: AARCH64 defines in c1_LIRAssembler_aarch64.hpp In-Reply-To: <5744A279.7030800@oracle.com> References: <5744A279.7030800@oracle.com> Message-ID: Good. Thanks, Vladimir On 5/24/16 11:50 AM, Dmitrij Pochepko wrote: > Hi, > > please review small fix for 8156585 - Cosmetic: AARCH64 defines in > c1_LIRAssembler_aarch64.hpp > > It's a renaming of guard macro parameter to have name adjusted with > architecture name. > > webrev: http://cr.openjdk.java.net/~dpochepk/8156585/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8156585 > > Thanks, > Dmitrij From paul.sandoz at oracle.com Tue May 24 20:22:38 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 24 May 2016 22:22:38 +0200 Subject: 8157683 Thread.onSpinWait intrinsification doesn't have sufficient test coverage Message-ID: Hi Please review a simple basic test ensuring no errors/exceptions occur when invoking Thread.onSpinWait when the intrinsic is enabled (on appropriate platforms) and explicitly disabled. JPRT with the hotspot test set passes on all platforms. Paul. diff -r 6054182379a7 test/compiler/onSpinWait/TestOnSpinWaitEnableDisable.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/compiler/onSpinWait/TestOnSpinWaitEnableDisable.java Tue May 24 18:21:39 2016 +0200 @@ -0,0 +1,39 @@ +/* + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright 2016 Azul Systems, Inc. All Rights Reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/** + * @test TestOnSpinWaitEnableDisable + * @summary Test to ensure basic functioning of java.lang.Thread.onSpinWait + * @bug 8157683 + * @run main/othervm TestOnSpinWaitEnableDisable + * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_onSpinWait TestOnSpinWaitEnableDisable + */ + +public class TestOnSpinWaitEnableDisable { + public static void main(String[] args) { + for (int i = 0; i < 50_000; i++) { + java.lang.Thread.onSpinWait(); + } + } +} -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Tue May 24 20:47:58 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 May 2016 13:47:58 -0700 Subject: 8157683 Thread.onSpinWait intrinsification doesn't have sufficient test coverage In-Reply-To: References: Message-ID: Looks good but you don't need /othervm when there no any flags: > @run main/othervm TestOnSpinWaitEnableDisable Thanks, Vladimir On 5/24/16 1:22 PM, Paul Sandoz wrote: > Hi > > Please review a simple basic test ensuring no errors/exceptions occur when invoking Thread.onSpinWait when the intrinsic is enabled (on appropriate platforms) and explicitly disabled. > > JPRT with the hotspot test set passes on all platforms. > > Paul. > > diff -r 6054182379a7 test/compiler/onSpinWait/TestOnSpinWaitEnableDisable.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/compiler/onSpinWait/TestOnSpinWaitEnableDisable.java Tue May 24 18:21:39 2016 +0200 > @@ -0,0 +1,39 @@ > +/* > + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright 2016 Azul Systems, Inc. All Rights Reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/** > + * @test TestOnSpinWaitEnableDisable > + * @summary Test to ensure basic functioning of java.lang.Thread.onSpinWait > + * @bug 8157683 > + * @run main/othervm TestOnSpinWaitEnableDisable > + * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_onSpinWait TestOnSpinWaitEnableDisable > + */ > + > +public class TestOnSpinWaitEnableDisable { > + public static void main(String[] args) { > + for (int i = 0; i < 50_000; i++) { > + java.lang.Thread.onSpinWait(); > + } > + } > +} > From paul.sandoz at oracle.com Tue May 24 20:53:11 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 24 May 2016 22:53:11 +0200 Subject: 8157683 Thread.onSpinWait intrinsification doesn't have sufficient test coverage In-Reply-To: References: Message-ID: <6BE11CFC-E515-4D26-A4E7-021D6FA0D154@oracle.com> > On 24 May 2016, at 22:47, Vladimir Kozlov wrote: > > Looks good but you don't need /othervm when there no any flags: > > > @run main/othervm TestOnSpinWaitEnableDisable > Updated, will push tomorrow, thanks, 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 jamsheed.c.m at oracle.com Wed May 25 05:51:22 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 25 May 2016 11:21:22 +0530 Subject: RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized Message-ID: <57453D5A.1080000@oracle.com> Hi, Request for review, bug id :https://bugs.openjdk.java.net/browse/JDK-8146416 webrev: http://cr.openjdk.java.net/~jcm/8146416/ testing: rbt pit, jprt; Best Regards, Jamsheed From vladimir.kozlov at oracle.com Wed May 25 06:27:45 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 May 2016 23:27:45 -0700 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: <57453D5A.1080000@oracle.com> References: <57453D5A.1080000@oracle.com> Message-ID: <9040cd47-cba1-be0c-569f-87d361f397d6@oracle.com> Hi Jamsheed, When sending RFR, please, explain the problem and the fix. What about other platforms (including closed)? Don't use jump_cc because StubRoutines::forward_exception_entry() address could be far. Other places use short conditional branch to (or over) code which does jump to this function. I don't think you can use call in SPARC code - you may mess up frames. Use tail jump as in other cases. Thanks, Vladimir On 5/24/16 10:51 PM, Jamsheed C m wrote: > Hi, > > Request for review, > > bug id :https://bugs.openjdk.java.net/browse/JDK-8146416 > webrev: http://cr.openjdk.java.net/~jcm/8146416/ > testing: rbt pit, jprt; > > Best Regards, > Jamsheed From rwestrel at redhat.com Wed May 25 07:47:28 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 25 May 2016 09:47: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: <57453D5A.1080000@oracle.com> References: <57453D5A.1080000@oracle.com> Message-ID: <57455890.2030301@redhat.com> Hi Jamsheed, > bug id :https://bugs.openjdk.java.net/browse/JDK-8146416 > webrev: http://cr.openjdk.java.net/~jcm/8146416/ > testing: rbt pit, jprt; With the change from 6898462, when we hit a OOME during deoptimization, we're supposed to go back to the interpreter and pop all just-deoptimized interpreter frames. When we go back to the interpreter TemplateInterpreterGenerator::generate_deopt_entry_for() checks for a pending exception. Why do we need to check in the uncommon trap blob then? With your test case, can the failure be reproduced with c2? Roland. From nils.eliasson at oracle.com Wed May 25 09:24:06 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 25 May 2016 11:24:06 +0200 Subject: [9] RFR(XS): 8157717: MultiCommand breaks directives amount limit Message-ID: <57456F36.4000107@oracle.com> Hi, Summary: The test fail because it generates more directives (up to 100) than the default VM settings allows (50). This failure is seen now because the test was ignored due to a problem in outputanalyzer which was recently fixed. Solution: Add flag that increases amounts of directives allowed in target VM. Testing: Test change only - verified this test with and without change, with seed for reported crash. Bug: https://bugs.openjdk.java.net/browse/JDK-8157717 Webrev: http://cr.openjdk.java.net/~neliasso/8157717/webrev.01/ Best regards, Nils Eliasson From jamsheed.c.m at oracle.com Wed May 25 09:46:46 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 25 May 2016 15:16:46 +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: <57455890.2030301@redhat.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> Message-ID: <57457486.7030007@oracle.com> Hi Roland, On 5/25/2016 1:17 PM, Roland Westrelin wrote: > Hi Jamsheed, > >> bug id :https://bugs.openjdk.java.net/browse/JDK-8146416 >> webrev: http://cr.openjdk.java.net/~jcm/8146416/ >> testing: rbt pit, jprt; > With the change from 6898462, when we hit a OOME during deoptimization, > we're supposed to go back to the interpreter and pop all > just-deoptimized interpreter frames. When we go back to the interpreter > TemplateInterpreterGenerator::generate_deopt_entry_for() checks for a > pending exception. Why do we need to check in the uncommon trap blob then? in exception triggered deopt, the interpreter continuation pc will be Interpreter::_rethrow_exception_entry without the pending_exception flag reset*(the realloc set pending exception flag). this causes code to take different path after InterpreterRuntime::exception_handler_for_exception(as pending_exception is still set). and pop frame logic doesnt work. and in case of single frame case deopt. pop never happens and do_not_unlock_if_synchronized is not made false. even in TemplateInterpreterGenerator::generate_deopt_entry_for case pending exception is not expected! see.. // handle exceptions { Label L; __ cmpptr(Address(thread, Thread::pending_exception_offset()), (int32_t) NULL_WORD); __ jcc(Assembler::zero, L); __ call_VM(noreg, CAST_FROM_FN_PTR(address, InterpreterRuntime::throw_pending_exception)); __ should_not_reach_here(); __ bind(L); } > > With your test case, can the failure be reproduced with c2? Yes. Thank you Jamsheed > Roland. From dmitrij.pochepko at oracle.com Wed May 25 13:12:35 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 25 May 2016 16:12:35 +0300 Subject: RFR(XS): 8156585 - Cosmetic: AARCH64 defines in c1_LIRAssembler_aarch64.hpp In-Reply-To: References: <5744A279.7030800@oracle.com> Message-ID: <5745A4C3.5030007@oracle.com> Thank you! On 24.05.2016 22:07, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 5/24/16 11:50 AM, Dmitrij Pochepko wrote: >> Hi, >> >> please review small fix for 8156585 - Cosmetic: AARCH64 defines in >> c1_LIRAssembler_aarch64.hpp >> >> It's a renaming of guard macro parameter to have name adjusted with >> architecture name. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8156585/webrev.01/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8156585 >> >> Thanks, >> Dmitrij From pavel.punegov at oracle.com Wed May 25 14:05:44 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 25 May 2016 17:05:44 +0300 Subject: [9] RFR(XS): 8157717: MultiCommand breaks directives amount limit In-Reply-To: <57456F36.4000107@oracle.com> References: <57456F36.4000107@oracle.com> Message-ID: <15A193D0-7F04-49CA-9B18-9F10E27294EE@oracle.com> Hi Nils, The fix looks good for me. Thanks for fixing that. (not a Reviewer) ? Pavel. > On 25 May 2016, at 12:24, Nils Eliasson wrote: > > Hi, > > Summary: > The test fail because it generates more directives (up to 100) than the default VM settings allows (50). This failure is seen now because the test was ignored due to a problem in outputanalyzer which was recently fixed. > > Solution: > Add flag that increases amounts of directives allowed in target VM. > > Testing: > Test change only - verified this test with and without change, with seed for reported crash. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157717 > Webrev: http://cr.openjdk.java.net/~neliasso/8157717/webrev.01/ > > Best regards, > Nils Eliasson -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsmogura at gmail.com Wed May 25 14:40:01 2016 From: rsmogura at gmail.com (Radek) Date: Wed, 25 May 2016 16:40:01 +0200 Subject: Testing and compiling hotspot Message-ID: <08723E59-6301-4FD5-B3FB-90CCA41CC674@gmail.com> Dear all, Please don?t kill me for asking less hotspot related question. I working on hotspot code (memory management). In order to build and debug it I firstly build JDK with following command: make CONF=linux-x86_64-normal-server-slowdebug JOBS=10 LOG=info hotspot jdk This takes a bit of time. I tried to analyse make files to answer my question, but ?. I wonder if you know some magical combination of commands so, - I can execute particular test, - I can start JVM without building JDK. Thanks in advance, Radek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From edward.nevill at gmail.com Wed May 25 15:16:55 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 25 May 2016 16:16:55 +0100 Subject: RFR: 8157834: aarch64: Hello World crashes with fastdebug build Message-ID: <1464189415.2400.4.camel@mylittlepony.linaroharston> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8157834/webrev/ jira issue: https://bugs.openjdk.java.net/browse/JDK-8157834 This crash is caused by StrIndexOf being called with argument encoding != UU even though CompactStrings is disabled. Fix is to implement LL, UL and LU encodings for StrIndexOf. All the best, Ed. From rwestrel at redhat.com Wed May 25 15:51:50 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 25 May 2016 17:51:50 +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: <57457486.7030007@oracle.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> Message-ID: <5745CA16.40808@redhat.com> > in exception triggered deopt, the interpreter continuation pc will be > Interpreter::_rethrow_exception_entry without the pending_exception flag > reset*(the realloc set pending exception flag). > this causes code to take different path after > InterpreterRuntime::exception_handler_for_exception(as pending_exception > is still set). and pop frame logic doesnt work. I think the fix then is to not go to Interpreter::_rethrow_exception_entry with a pending exception. So in that case, Deoptimization::realloc_objects() should overwrite _exception_oop rather than set _pending_exception. Unfortunately, because of this code at the end of fetch_unroll_info_helper): #ifdef INCLUDE_JVMCI if (exceptionObject() != NULL) { thread->set_exception_oop(exceptionObject()); exec_mode = Unpack_exception; } #endif that might not be good enough for JVMCI. So maybe we want something like this right after the code above: if (thread->has_pending_exception() && thread->exception_oop() != NULL) { assert(thread->frames_to_pop_failed_realloc() > 0, "realloc should have failed"); thread->set_exception_oop(thread->pending_exception()); thread->clear_pending_exception(); } Roland. > > and in case of single frame case deopt. pop never happens and > do_not_unlock_if_synchronized is not made false. > > even in TemplateInterpreterGenerator::generate_deopt_entry_for case > pending exception is not expected! > > see.. > // handle exceptions > > { > Label L; > __ cmpptr(Address(thread, Thread::pending_exception_offset()), > (int32_t) NULL_WORD); > __ jcc(Assembler::zero, L); > __ call_VM(noreg, > CAST_FROM_FN_PTR(address, > > InterpreterRuntime::throw_pending_exception)); > __ should_not_reach_here(); > __ bind(L); > } > >> >> With your test case, can the failure be reproduced with c2? > Yes. > > Thank you > Jamsheed >> Roland. > From jamsheed.c.m at oracle.com Wed May 25 16:12:49 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 25 May 2016 21:42: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: <5745CA16.40808@redhat.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> Message-ID: <5745CF01.5010804@oracle.com> On 5/25/2016 9:21 PM, Roland Westrelin wrote: >> in exception triggered deopt, the interpreter continuation pc will be >> Interpreter::_rethrow_exception_entry without the pending_exception flag >> reset*(the realloc set pending exception flag). >> this causes code to take different path after >> InterpreterRuntime::exception_handler_for_exception(as pending_exception >> is still set). and pop frame logic doesnt work. > I think the fix then is to not go to > Interpreter::_rethrow_exception_entry with a pending exception. So in > that case, Deoptimization::realloc_objects() should overwrite > _exception_oop rather than set _pending_exception. > > Unfortunately, because of this code at the end of fetch_unroll_info_helper): > > #ifdef INCLUDE_JVMCI > if (exceptionObject() != NULL) { > thread->set_exception_oop(exceptionObject()); > exec_mode = Unpack_exception; > } > #endif > > that might not be good enough for JVMCI. So maybe we want something like > this right after the code above: > > if (thread->has_pending_exception() && thread->exception_oop() != NULL) { > assert(thread->frames_to_pop_failed_realloc() > 0, "realloc should > have failed"); > thread->set_exception_oop(thread->pending_exception()); > thread->clear_pending_exception(); > } if realloc failure happened for non exception deoptimization then? we need to throw an exception at runtime exit.. this wouldn't take care that. Best Regards, Jamsheed > > Roland. > >> and in case of single frame case deopt. pop never happens and >> do_not_unlock_if_synchronized is not made false. >> >> even in TemplateInterpreterGenerator::generate_deopt_entry_for case >> pending exception is not expected! >> >> see.. >> // handle exceptions >> >> { >> Label L; >> __ cmpptr(Address(thread, Thread::pending_exception_offset()), >> (int32_t) NULL_WORD); >> __ jcc(Assembler::zero, L); >> __ call_VM(noreg, >> CAST_FROM_FN_PTR(address, >> >> InterpreterRuntime::throw_pending_exception)); >> __ should_not_reach_here(); >> __ bind(L); >> } >> >>> With your test case, can the failure be reproduced with c2? >> Yes. >> >> Thank you >> Jamsheed >>> Roland. From rwestrel at redhat.com Wed May 25 16:14:25 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 25 May 2016 18:14:25 +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: <5745CF01.5010804@oracle.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <5745CF01.5010804@oracle.com> Message-ID: <5745CF61.6040500@redhat.com> > if realloc failure happened for non exception deoptimization then? we > need to throw an exception at runtime exit.. Then thread->exception_oop() is null and we don't clear the pending exception? Roland. From vladimir.kozlov at oracle.com Wed May 25 16:31:26 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 May 2016 09:31:26 -0700 Subject: [9] RFR(XS): 8157717: MultiCommand breaks directives amount limit In-Reply-To: <57456F36.4000107@oracle.com> References: <57456F36.4000107@oracle.com> Message-ID: <616da0ec-fde5-ab25-455c-32d5b5b4d3fa@oracle.com> Good. Thanks, Vladimir On 5/25/16 2:24 AM, Nils Eliasson wrote: > Hi, > > Summary: > The test fail because it generates more directives (up to 100) than the default VM settings allows (50). This failure is > seen now because the test was ignored due to a problem in outputanalyzer which was recently fixed. > > Solution: > Add flag that increases amounts of directives allowed in target VM. > > Testing: > Test change only - verified this test with and without change, with seed for reported crash. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157717 > Webrev: http://cr.openjdk.java.net/~neliasso/8157717/webrev.01/ > > Best regards, > Nils Eliasson From edward.nevill at gmail.com Wed May 25 16:41:17 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 25 May 2016 17:41:17 +0100 Subject: Request for clarification: hs or hs-comp Message-ID: <1464194477.3492.9.camel@mylittlepony.linaroharston> Hi, Could someone please clarify which repo we should be pushing aarch64 compiler specific bug fixes to now that we are post FC. Should we continue pushing to hs-comp as before FC, or should we now be pushing to hs? Thanks, Ed. From vladimir.kozlov at oracle.com Wed May 25 16:46:06 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 May 2016 09:46:06 -0700 Subject: Testing and compiling hotspot In-Reply-To: <08723E59-6301-4FD5-B3FB-90CCA41CC674@gmail.com> References: <08723E59-6301-4FD5-B3FB-90CCA41CC674@gmail.com> Message-ID: <4a6da5de-c5d9-ae98-65d1-cf9cf03e4826@oracle.com> Your command line looks correct. You don't need 'hotspot', just 'jdk' is enough - it will build hotspot too. It takes time only for first build. If you change only hotspot after that the same command should be faster since only hotspot will be rebuilt. Vladimir On 5/25/16 7:40 AM, Radek wrote: > Dear all, > > Please don?t kill me for asking less hotspot related question. > > I working on hotspot code (memory management). In order to build and debug it I firstly build JDK with following command: > > make CONF=linux-x86_64-normal-server-slowdebug JOBS=10 LOG=info hotspot jdk > > This takes a bit of time. I tried to analyse make files to answer my question, but ?. > > I wonder if you know some magical combination of commands so, > - I can execute particular test, > - I can start JVM without building JDK. > > Thanks in advance, > Radek > From vladimir.kozlov at oracle.com Wed May 25 16:48:25 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 May 2016 09:48:25 -0700 Subject: Testing and compiling hotspot In-Reply-To: <08723E59-6301-4FD5-B3FB-90CCA41CC674@gmail.com> References: <08723E59-6301-4FD5-B3FB-90CCA41CC674@gmail.com> Message-ID: <0521fd75-00b5-e01a-cbf4-497ced3cc71f@oracle.com> Your command line looks correct. You don't need 'hotspot', just 'jdk' is enough - it will build hotspot too and put libjvm.so into built jdk. It takes time only for first build. If you change only hotspot after that the same command should be faster since only hotspot will be rebuilt. Vladimir On 5/25/16 7:40 AM, Radek wrote: > Dear all, > > Please don?t kill me for asking less hotspot related question. > > I working on hotspot code (memory management). In order to build and debug it I firstly build JDK with following command: > > make CONF=linux-x86_64-normal-server-slowdebug JOBS=10 LOG=info hotspot jdk > > This takes a bit of time. I tried to analyse make files to answer my question, but ?. > > I wonder if you know some magical combination of commands so, > - I can execute particular test, > - I can start JVM without building JDK. > > Thanks in advance, > Radek > From jamsheed.c.m at oracle.com Wed May 25 16:57:27 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 25 May 2016 22:27:27 +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: <5745CF61.6040500@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> Message-ID: <5745D977.900@oracle.com> On 5/25/2016 9:44 PM, Roland Westrelin wrote: >> if realloc failure happened for non exception deoptimization then? we >> need to throw an exception at runtime exit.. > Then thread->exception_oop() is null and we don't clear the pending > exception? my worry is this, we do all computation (vframe array) using one exception or no exception at all.. and later change it to realloc exception.. wouldn't this cause and issue at unpack. isn' t checking exception at interpreter return and pop all frames is better thing to do, here? Best Regards, Jamsheed > > Roland. From vladimir.kozlov at oracle.com Wed May 25 16:58:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 May 2016 09:58:56 -0700 Subject: Request for clarification: hs or hs-comp In-Reply-To: <14bfc2cb-14be-c180-8094-e21abe3e2527@oracle.com> References: <1464194477.3492.9.camel@mylittlepony.linaroharston> <14bfc2cb-14be-c180-8094-e21abe3e2527@oracle.com> Message-ID: <8b680967-4244-6b81-2231-5628c0b743ab@oracle.com> You can continue push *Bugs* fixes (like 8157841 and 8157834) into hs-comp after FC. But you should wait with 'Enhancement' changes (like 8156943) until approval process is finalized. Thanks, Vladimir On 5/25/16 9:44 AM, Jesper Wilhelmsson wrote: > You can continue to push to hs-comp. Integrations are done between all repos in the same way as before FC. > /Jesper > > Den 25/5/16 kl. 18:41, skrev Edward Nevill: >> Hi, >> >> Could someone please clarify which repo we should be pushing aarch64 compiler specific bug fixes to now that we are >> post FC. >> >> Should we continue pushing to hs-comp as before FC, or should we now be pushing to hs? >> >> Thanks, >> Ed. >> >> From jamsheed.c.m at oracle.com Thu May 26 04:51:07 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 26 May 2016 10:21: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: <5745CA16.40808@redhat.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> Message-ID: <574680BB.3080803@oracle.com> On 5/25/2016 9:21 PM, Roland Westrelin wrote: > if (thread->has_pending_exception() && thread->exception_oop() != NULL) { > assert(thread->frames_to_pop_failed_realloc() > 0, "realloc should > have failed"); > thread->set_exception_oop(thread->pending_exception()); > thread->clear_pending_exception(); > } with this fix wouldn't we have to eliminate escape analysis based eliminate allocation for JvmtiExport ::can_force_early_return () too ? Best Regards, Jamsheed -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamsheed.c.m at oracle.com Thu May 26 05:04:34 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 26 May 2016 10:34:34 +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: <9040cd47-cba1-be0c-569f-87d361f397d6@oracle.com> References: <57453D5A.1080000@oracle.com> <9040cd47-cba1-be0c-569f-87d361f397d6@oracle.com> Message-ID: <574683E2.4010005@oracle.com> Problem Description: Fix for https://bugs.openjdk.java.net/browse/JDK-6898462 was incomplete as Exception from deopt runtime was thrown with pending_exception set. other responses inlined On 5/25/2016 11:57 AM, Vladimir Kozlov wrote: > Hi Jamsheed, > > When sending RFR, please, explain the problem and the fix. > > What about other platforms (including closed)? > > Don't use jump_cc because StubRoutines::forward_exception_entry() > address could be far. Other places use short conditional branch to (or > over) code which does jump to this function. jump_cc do handle far address with a warning, i will make the required change. > > > I don't think you can use call in SPARC code - you may mess up frames. > Use tail jump as in other cases. i can use tail jump. > > Thanks, > Vladimir > > On 5/24/16 10:51 PM, Jamsheed C m wrote: >> Hi, >> >> Request for review, >> >> bug id :https://bugs.openjdk.java.net/browse/JDK-8146416 >> webrev: http://cr.openjdk.java.net/~jcm/8146416/ >> testing: rbt pit, jprt; >> >> Best Regards, >> Jamsheed From jamsheed.c.m at oracle.com Thu May 26 05:58:41 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 26 May 2016 11:28:41 +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: <574683E2.4010005@oracle.com> References: <57453D5A.1080000@oracle.com> <9040cd47-cba1-be0c-569f-87d361f397d6@oracle.com> <574683E2.4010005@oracle.com> Message-ID: <57469091.1020200@oracle.com> Hi Vladimir, (previous one was draft mail got accidentally sent) Problem Description: Fix for https://bugs.openjdk.java.net/browse/JDK-6898462 was incomplete Realloc failure deopt runtime exception was not handled properly! for other exception based deopt, it may get a piggy backed feeling, but as pending exception was not reset, pop logic will not work for first frame.(InterpreterRuntime::exception_handler_for_exception exit check for pending exception and forward again). for normal deopts, Realloc failure runtime exception is not handled at all. Best Regards, Jamsheed On 5/26/2016 10:34 AM, Jamsheed C m wrote: > > > other responses inlined > On 5/25/2016 11:57 AM, Vladimir Kozlov wrote: >> Hi Jamsheed, >> >> When sending RFR, please, explain the problem and the fix. >> >> What about other platforms (including closed)? Closed part was sent yesterday itself, AARCH64, and PPC was not done, as i didnt have testing framework. i will intimate them, once review is done. >> >> Don't use jump_cc because StubRoutines::forward_exception_entry() >> address could be far. Other places use short conditional branch to >> (or over) code which does jump to this function. > jump_cc do handle far address with a warning, i will make the required > change. >> >> >> I don't think you can use call in SPARC code - you may mess up >> frames. Use tail jump as in other cases. > i can use tail jump. Best Regards, Jamsheed >> >> Thanks, >> Vladimir >> >> On 5/24/16 10:51 PM, Jamsheed C m wrote: >>> Hi, >>> >>> Request for review, >>> >>> bug id :https://bugs.openjdk.java.net/browse/JDK-8146416 >>> webrev: http://cr.openjdk.java.net/~jcm/8146416/ >>> testing: rbt pit, jprt; >>> >>> Best Regards, >>> Jamsheed > From rwestrel at redhat.com Thu May 26 09:29:29 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 26 May 2016 11:29:29 +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: <5745D977.900@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> Message-ID: <5746C1F9.2000405@redhat.com> > my worry is this, we do all computation (vframe array) using one > exception or no exception at all.. and later change it to realloc > exception.. wouldn't this cause and issue at unpack. JVMCI does something similar so we can suppose it's safe. > isn' t checking exception at interpreter return and pop all frames is > better thing to do, here? In general, I think we want to avoid platform dependent changes as they are painful to implement and maintain. Also I find the exception propagation code quite hard to follow so not adding another special case seems like a good thing. Roland. From jamsheed.c.m at oracle.com Thu May 26 09:48:10 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 26 May 2016 15:18:10 +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: <5746C1F9.2000405@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> Message-ID: <5746C65A.5010207@oracle.com> On 5/26/2016 2:59 PM, Roland Westrelin wrote: >> >my worry is this, we do all computation (vframe array) using one >> >exception or no exception at all.. and later change it to realloc >> >exception.. wouldn't this cause and issue at unpack. > JVMCI does something similar so we can suppose it's safe. > some checks in unpack "(exec_mode == Unpack_exception) && iframe->interpreter_frame_expression_stack_size() == 0)" JVMCI code is for an already thrown exception right ? expression stack is expected to have exception object... what about a normal expression stack in unpack? From rwestrel at redhat.com Thu May 26 09:52:07 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 26 May 2016 11:52:07 +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: <574680BB.3080803@oracle.com> References: <57453D5A.1080000@oracle.com> <57455890.2030301@redhat.com> <57457486.7030007@oracle.com> <5745CA16.40808@redhat.com> <574680BB.3080803@oracle.com> Message-ID: > with this fix wouldn't we have to eliminate escape analysis based > eliminate allocation for > > JvmtiExport ::can_force_early_return too ? Because of: } else if (JvmtiExport::can_force_early_return() && state != NULL && state->is_earlyret_pending()) { // Force early return from top frame after deoptimization #ifndef CC_INTERP pc = Interpreter::remove_activation_early_entry(state->earlyret_tos()); #endif in vframeArrayElement::unpack_on_stack()? Good catch indeed. Maybe changing that test to: JvmtiExport::can_force_early_return() && state != NULL && state->is_earlyret_pending() && thread->frames_to_pop_failed_realloc() == 0 is good enough. I'm not sure. Testing for JvmtiExport::can_pop_frame(): if (!EliminateAllocations || JvmtiExport::can_pop_frame() || !alloc->_is_non_escaping) { return false; } in PhaseMacroExpand::eliminate_allocate_node() is conservative. Maybe it's not needed. Someone would need to take a closer look at the interaction of what we do when we throw OOME during deoptimization and jvmti. Roland. From rwestrel at redhat.com Thu May 26 11:27:23 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 26 May 2016 13:27: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: <5746C65A.5010207@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> Message-ID: <5746DD9B.3080606@redhat.com> >>> >my worry is this, we do all computation (vframe array) using one >>> >exception or no exception at all.. and later change it to realloc >>> >exception.. wouldn't this cause and issue at unpack. >> JVMCI does something similar so we can suppose it's safe. >> > some checks in unpack "(exec_mode == Unpack_exception) && > iframe->interpreter_frame_expression_stack_size() == 0)" > > JVMCI code is for an already thrown exception right ? > > expression stack is expected to have exception object... > > what about a normal expression stack in unpack? We are replacing an existing exception with another one. Why would the expression stack matter? Roland. From nils.eliasson at oracle.com Thu May 26 12:18:57 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 26 May 2016 14:18:57 +0200 Subject: [9] RFR(S/M): Crash with assert(pd != 0L) failed: PcDesc must not be NULL In-Reply-To: References: <574460B3.3040601@oracle.com> Message-ID: <5746E9B1.7010200@oracle.com> Thank you Vladimir, Test links in the bug report. Regards, Nils On 2016-05-24 17:55, Vladimir Kozlov wrote: > Looks good to me. But please, run RBT too before pushing. > > Thanks, > Vladimir > > On 5/24/16 7:09 AM, Nils Eliasson wrote: >> Hi all, >> >> Please review. >> >> Summary: >> The VM fails on "assert(pd != 0L) failed: PcDesc must not be NULL" when >> walking the Java frames on the stack after hitting a stack overflow. >> >> The asserts triggers when the trying to find the BCI of an address in an >> nmethod. This assert belongs to stack walking code introduced by >> JDK-8046936 "JEP 270: Reserved Stack Areas for Critical Sections". The >> BCI is not relevant for this code, as we only need the method to find >> the annotation. The similar stack walking code in >> java_lang_Throwable::fill_in_stack_trace in javaClasses.cpp do not have >> the assert in the same position suggesting the assert may have been to >> strong. >> >> This fix also makes this bug stop reproducing: >> https://bugs.openjdk.java.net/browse/JDK-8156659 >> "assert(CodeCache::find_blob_unsafe(_pc) == _cb) failed: inconsistent." >> >> Solution: >> I have rewritten and simplified the stack walking code in >> SharedRuntime::look_for_reserved_stack_annotated_method removing the >> lookup of BCI. >> >> Testing: >> Run :hotspot_all on all platforms with and without -Xcomp >> Separately run all uncommontrap tests and the test ReservedStackTest >> written for JEP270. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153352 >> Webrev: http://cr.openjdk.java.net/~neliasso/8153352/webrev.01/ >> >> Best regards, >> Nils Eliasson >> >> From nils.eliasson at oracle.com Thu May 26 12:19:17 2016 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 26 May 2016 14:19:17 +0200 Subject: [9] RFR(XS): 8157717: MultiCommand breaks directives amount limit In-Reply-To: <616da0ec-fde5-ab25-455c-32d5b5b4d3fa@oracle.com> References: <57456F36.4000107@oracle.com> <616da0ec-fde5-ab25-455c-32d5b5b4d3fa@oracle.com> Message-ID: <5746E9C5.5040202@oracle.com> Thank you Vladimir and Pavel, Regards, Nils On 2016-05-25 18:31, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 5/25/16 2:24 AM, Nils Eliasson wrote: >> Hi, >> >> Summary: >> The test fail because it generates more directives (up to 100) than >> the default VM settings allows (50). This failure is >> seen now because the test was ignored due to a problem in >> outputanalyzer which was recently fixed. >> >> Solution: >> Add flag that increases amounts of directives allowed in target VM. >> >> Testing: >> Test change only - verified this test with and without change, with >> seed for reported crash. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8157717 >> Webrev: http://cr.openjdk.java.net/~neliasso/8157717/webrev.01/ >> >> Best regards, >> Nils Eliasson From jamsheed.c.m at oracle.com Thu May 26 12:34:00 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 26 May 2016 18:04:00 +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: <5746DD9B.3080606@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> Message-ID: <5746ED38.2050005@oracle.com> On 5/26/2016 4:57 PM, Roland Westrelin wrote: > We are replacing an existing exception with another one. Why would the > expression stack matter? realloc failure in "non exception deoptimization" case. Best Regards Jamsheed From rwestrel at redhat.com Thu May 26 12:35:14 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 26 May 2016 14:35: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: <5746ED38.2050005@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> Message-ID: <5746ED82.5050906@redhat.com> > On 5/26/2016 4:57 PM, Roland Westrelin wrote: >> We are replacing an existing exception with another one. Why would the >> expression stack matter? > realloc failure in "non exception deoptimization" case. In that case, we do nothing more than the existing code does. Roland. From Leonid.Mesnik at oracle.com Thu May 26 13:45:23 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Thu, 26 May 2016 16:45:23 +0300 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 Message-ID: <5746FDF3.3030102@oracle.com> 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 felix.yang at linaro.org Thu May 26 17:26:49 2016 From: felix.yang at linaro.org (Felix Yang) Date: Fri, 27 May 2016 01:26:49 +0800 Subject: RFR: 8157906: aarch64: some more integer rotate instructions are never emitted Message-ID: Hi, Please review webrev: http://cr.openjdk.java.net/~fyang/8157906/webrev.00 JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8157906 This patch has been contributed by teng.lu at linaro.org The left rotate instructions have the same issue with https://bugs.openjdk.java.net/browse/JDK-8154537. (src << shift) | src >>> -shift) with src an int have some support in the aarch64.ad ad file: rolI_rReg_Var_C_32 and rolI_rReg_Var_C0, but their definitions is broken and never match any ideal graph subtree. Tested with fastdebug jtreg hotspot and langtools, OK to push? Simple test case: import java.lang.Integer.*; public class test { public static int foo (int x) { return Integer.rotateLeft(x, 1); } public static void main(String[] args) { int x = 0x1234; for (int i = 0; i < 50000; i++) { x = foo(x); } } } JIT code snippet before change: 0x0000007f74d13454: neg w11, w2 0x0000007f74d13458: lsr w12, w1, w11 0x0000007f74d1345c: lsl w10, w1, w2 0x0000007f74d13460: orr w0, w10, w12 ;*ior {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.Integer::rotateLeft at 7 (line 1751) JIT code snippet after change: 0x0000007f6cd135d4: neg w8, w2 0x0000007f6cd135d8: ror w0, w1, w8 ;*ior {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.Integer::rotateLeft at 7 (line 1751) -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Thu May 26 19:52:39 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 26 May 2016 22:52:39 +0300 Subject: RFR(XS) : 8157821 : [JITtester] OptionResolver and LiteralFactory use deprecated c-tors Message-ID: <6B56C0E1-B5E6-49C8-AE09-0B69B1D30576@oracle.com> http://cr.openjdk.java.net/~iignatyev/8157821/webrev.00/ > 4 lines changed: 0 ins; 0 del; 4 mod; Hi all, could you please review this straightforward tiny fix which replaces using of deprecated j.l.Integer/Long/../../Double::(LString;) w/ corresponding valueOf(String)? JBS: https://bugs.openjdk.java.net/browse/JDK-8157821 webrev: http://cr.openjdk.java.net/~iignatyev/8157821/webrev.00/ Thanks, ? Igor From vladimir.kozlov at oracle.com Thu May 26 20:00:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 26 May 2016 13:00:20 -0700 Subject: RFR(XS) : 8157821 : [JITtester] OptionResolver and LiteralFactory use deprecated c-tors In-Reply-To: <6B56C0E1-B5E6-49C8-AE09-0B69B1D30576@oracle.com> References: <6B56C0E1-B5E6-49C8-AE09-0B69B1D30576@oracle.com> Message-ID: <574755D4.7010701@oracle.com> Looks good. Thanks, Vladimir On 5/26/16 12:52 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8157821/webrev.00/ >> 4 lines changed: 0 ins; 0 del; 4 mod; > > Hi all, > > could you please review this straightforward tiny fix which replaces using of deprecated j.l.Integer/Long/../../Double::(LString;) w/ corresponding valueOf(String)? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8157821 > webrev: http://cr.openjdk.java.net/~iignatyev/8157821/webrev.00/ > > Thanks, > ? Igor > From rsmogura at gmail.com Thu May 26 20:25:48 2016 From: rsmogura at gmail.com (Radek) Date: Thu, 26 May 2016 22:25:48 +0200 Subject: Testing and compiling hotspot In-Reply-To: <0521fd75-00b5-e01a-cbf4-497ced3cc71f@oracle.com> References: <08723E59-6301-4FD5-B3FB-90CCA41CC674@gmail.com> <0521fd75-00b5-e01a-cbf4-497ced3cc71f@oracle.com> Message-ID: <42E1DC52-0F8C-499A-B919-CAD7D22E7ED8@gmail.com> Thank you Vladimir, I have few other, descriptive questions, and I apologises for less strict questions. I work on sharing memory in JVM, I have modified C1 and G1 (it works, but maybe I did something which I do not understand). Hotspot is pretty complicated, and there is a lot of ideas which are hard to be understand by code analyse. I have two concerns: one is ?state?, 2nd one is XHandlers. I wonder for what purposes the ?state? is used? I?ve seen that there is few places where state_for, and copy_state_* is used in LIR_Generator. My understanding is that this represents the state of VM before and after the given instruction. This state is expressed as ?instructions? used to obtain given value. Than, I suppose, the state is transformed to registers which can be used by instructions, so last stack value can represent REG_X in state before, and REG_Y in state after (ie. state before field is loaded and after)? Am I right? Please free to correct me. My 2nd question is about XHandlers. What XHandler actually is? Is this catch block? I?ve seen looking for XHandlers in signal block used to capture null references. Thanks in advance, Radek > On 25 May 2016, at 18:48, Vladimir Kozlov wrote: > > Your command line looks correct. You don't need 'hotspot', just 'jdk' is enough - it will build hotspot too and put libjvm.so into built jdk. > It takes time only for first build. If you change only hotspot after that the same command should be faster since only hotspot will be rebuilt. > > Vladimir > > On 5/25/16 7:40 AM, Radek wrote: >> Dear all, >> >> Please don?t kill me for asking less hotspot related question. >> >> I working on hotspot code (memory management). In order to build and debug it I firstly build JDK with following command: >> >> make CONF=linux-x86_64-normal-server-slowdebug JOBS=10 LOG=info hotspot jdk >> >> This takes a bit of time. I tried to analyse make files to answer my question, but ?. >> >> I wonder if you know some magical combination of commands so, >> - I can execute particular test, >> - I can start JVM without building JDK. >> >> Thanks in advance, >> Radek >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From igor.ignatyev at oracle.com Thu May 26 20:59:36 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 26 May 2016 23:59:36 +0300 Subject: RFR(S) : 8156469 : [JITtester] Difference in generated golden output when run with Jigsaw build Message-ID: <456F89E0-F712-4C7A-9497-3610B98D339C@oracle.com> http://cr.openjdk.java.net/~iignatyev/8156469/webrev.00/ > 56 lines changed: 23 ins; 13 del; 20 mod; Hi all, could you please review this small fix? since jit-tester tests can be generated by another version of JDK, there is probability that some of exception messages or stack trace have been changed. this can cause lots of false positive test results. in order to avoid that and make tests more robust, I have changed JIT tester to print/compare just only exception class names. JBS: https://bugs.openjdk.java.net/browse/JDK-8156469 webrev: http://cr.openjdk.java.net/~iignatyev/8156469/webrev.00/ Thanks, ? Igor From igor.ignatyev at oracle.com Thu May 26 21:00:31 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 27 May 2016 00:00:31 +0300 Subject: RFR(XS) : 8157821 : [JITtester] OptionResolver and LiteralFactory use deprecated c-tors In-Reply-To: <574755D4.7010701@oracle.com> References: <6B56C0E1-B5E6-49C8-AE09-0B69B1D30576@oracle.com> <574755D4.7010701@oracle.com> Message-ID: Vladimir, thanks a lot for such a prompt review. ? Igor > On May 26, 2016, at 11:00 PM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 5/26/16 12:52 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8157821/webrev.00/ >>> 4 lines changed: 0 ins; 0 del; 4 mod; >> >> Hi all, >> >> could you please review this straightforward tiny fix which replaces using of deprecated j.l.Integer/Long/../../Double::(LString;) w/ corresponding valueOf(String)? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8157821 >> webrev: http://cr.openjdk.java.net/~iignatyev/8157821/webrev.00/ >> >> Thanks, >> ? Igor >> From doug.simon at oracle.com Thu May 26 21:46:57 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 26 May 2016 23:46:57 +0200 Subject: RFR(XS): 8158000: [JVMCI] remove unused ParseClosure class Message-ID: <4B320310-E960-49D3-B4BE-927541F33EAB@oracle.com> Please review this tiny change to remove a left-over and unused class. https://bugs.openjdk.java.net/browse/JDK-8158000 http://cr.openjdk.java.net/~dnsimon/8158000/ -Doug From vladimir.kozlov at oracle.com Thu May 26 22:03:57 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 26 May 2016 15:03:57 -0700 Subject: Testing and compiling hotspot In-Reply-To: <42E1DC52-0F8C-499A-B919-CAD7D22E7ED8@gmail.com> References: <08723E59-6301-4FD5-B3FB-90CCA41CC674@gmail.com> <0521fd75-00b5-e01a-cbf4-497ced3cc71f@oracle.com> <42E1DC52-0F8C-499A-B919-CAD7D22E7ED8@gmail.com> Message-ID: <574772CD.4060803@oracle.com> Hi Radek, Disclaimer: I am not very familiar with C1, I am specializing on C2. On 5/26/16 1:25 PM, Radek wrote: > Thank you Vladimir, > > I have few other, descriptive questions, and I apologises for less strict questions. > > I work on sharing memory in JVM, I have modified C1 and G1 (it works, but maybe I did something which I do not understand). Hotspot is pretty complicated, and there is a lot of ideas which are hard to be understand by code analyse. > > I have two concerns: one is ?state?, 2nd one is XHandlers. > > I wonder for what purposes the ?state? is used? I?ve seen that there is few places where state_for, and copy_state_* is used in LIR_Generator. My understanding is that this represents the state of VM before and after the given instruction. This state is expressed as ?instructions? used to obtain given value. Than, I suppose, the state is transformed to registers which can be used by instructions, so last stack value can represent REG_X in state before, and REG_Y in state after (ie. state before field is loaded and after)? Am I right? Please free to correct me. As I understand 'state' is referring the JVM state when Interpreter executes this bytecode. JIT compiler have to track such states to be able "deoptimize" a compiled code and continue execution of this method in Interpreter. The state consist of BCI and mapping between locals, expressions, monitores and corresponding registers and stack slots in compiled code. > > My 2nd question is about XHandlers. What XHandler actually is? Is this catch block? I?ve seen looking for XHandlers in signal block used to capture null references. "// An XHandler is a C1 internal description for an exception handler" Yes, in simple term it is a class which associated with bytecode corresponding to java 'catch' block. But it covers not only exception clearly expressed in java but also exceptions generated by VM - like NULL pointer exceptions and others. Regards, Vladimir > > Thanks in advance, > Radek > > >> On 25 May 2016, at 18:48, Vladimir Kozlov wrote: >> >> Your command line looks correct. You don't need 'hotspot', just 'jdk' is enough - it will build hotspot too and put libjvm.so into built jdk. >> It takes time only for first build. If you change only hotspot after that the same command should be faster since only hotspot will be rebuilt. >> >> Vladimir >> >> On 5/25/16 7:40 AM, Radek wrote: >>> Dear all, >>> >>> Please don?t kill me for asking less hotspot related question. >>> >>> I working on hotspot code (memory management). In order to build and debug it I firstly build JDK with following command: >>> >>> make CONF=linux-x86_64-normal-server-slowdebug JOBS=10 LOG=info hotspot jdk >>> >>> This takes a bit of time. I tried to analyse make files to answer my question, but ?. >>> >>> I wonder if you know some magical combination of commands so, >>> - I can execute particular test, >>> - I can start JVM without building JDK. >>> >>> Thanks in advance, >>> Radek >>> > From vladimir.kozlov at oracle.com Thu May 26 22:06:16 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 26 May 2016 15:06:16 -0700 Subject: RFR(XS): 8158000: [JVMCI] remove unused ParseClosure class In-Reply-To: <4B320310-E960-49D3-B4BE-927541F33EAB@oracle.com> References: <4B320310-E960-49D3-B4BE-927541F33EAB@oracle.com> Message-ID: <57477358.3000304@oracle.com> Looks good. thanks, Vladimir On 5/26/16 2:46 PM, Doug Simon wrote: > Please review this tiny change to remove a left-over and unused class. > > https://bugs.openjdk.java.net/browse/JDK-8158000 > http://cr.openjdk.java.net/~dnsimon/8158000/ > > -Doug > From rsmogura at gmail.com Thu May 26 23:03:18 2016 From: rsmogura at gmail.com (Radek) Date: Fri, 27 May 2016 01:03:18 +0200 Subject: Testing and compiling hotspot In-Reply-To: <574772CD.4060803@oracle.com> References: <08723E59-6301-4FD5-B3FB-90CCA41CC674@gmail.com> <0521fd75-00b5-e01a-cbf4-497ced3cc71f@oracle.com> <42E1DC52-0F8C-499A-B919-CAD7D22E7ED8@gmail.com> <574772CD.4060803@oracle.com> Message-ID: Vladimir, Thank you for your help. Right now I?m able to change file writing directly to Java array :D BR, Radel PS. I?m drunk > On 27 May 2016, at 00:03, Vladimir Kozlov wrote: > > Hi Radek, > > Disclaimer: I am not very familiar with C1, I am specializing on C2. > > On 5/26/16 1:25 PM, Radek wrote: >> Thank you Vladimir, >> >> I have few other, descriptive questions, and I apologises for less strict questions. >> >> I work on sharing memory in JVM, I have modified C1 and G1 (it works, but maybe I did something which I do not understand). Hotspot is pretty complicated, and there is a lot of ideas which are hard to be understand by code analyse. >> >> I have two concerns: one is ?state?, 2nd one is XHandlers. >> >> I wonder for what purposes the ?state? is used? I?ve seen that there is few places where state_for, and copy_state_* is used in LIR_Generator. My understanding is that this represents the state of VM before and after the given instruction. This state is expressed as ?instructions? used to obtain given value. Than, I suppose, the state is transformed to registers which can be used by instructions, so last stack value can represent REG_X in state before, and REG_Y in state after (ie. state before field is loaded and after)? Am I right? Please free to correct me. > > As I understand 'state' is referring the JVM state when Interpreter executes this bytecode. > JIT compiler have to track such states to be able "deoptimize" a compiled code and continue execution of this method in Interpreter. The state consist of BCI and mapping between locals, expressions, monitores and corresponding registers and stack slots in compiled code. > >> >> My 2nd question is about XHandlers. What XHandler actually is? Is this catch block? I?ve seen looking for XHandlers in signal block used to capture null references. > > "// An XHandler is a C1 internal description for an exception handler" > > Yes, in simple term it is a class which associated with bytecode corresponding to java 'catch' block. > But it covers not only exception clearly expressed in java but also exceptions generated by VM - like NULL pointer exceptions and others. > > Regards, > Vladimir > >> >> Thanks in advance, >> Radek >> >> >>> On 25 May 2016, at 18:48, Vladimir Kozlov wrote: >>> >>> Your command line looks correct. You don't need 'hotspot', just 'jdk' is enough - it will build hotspot too and put libjvm.so into built jdk. >>> It takes time only for first build. If you change only hotspot after that the same command should be faster since only hotspot will be rebuilt. >>> >>> Vladimir >>> >>> On 5/25/16 7:40 AM, Radek wrote: >>>> Dear all, >>>> >>>> Please don?t kill me for asking less hotspot related question. >>>> >>>> I working on hotspot code (memory management). In order to build and debug it I firstly build JDK with following command: >>>> >>>> make CONF=linux-x86_64-normal-server-slowdebug JOBS=10 LOG=info hotspot jdk >>>> >>>> This takes a bit of time. I tried to analyse make files to answer my question, but ?. >>>> >>>> I wonder if you know some magical combination of commands so, >>>> - I can execute particular test, >>>> - I can start JVM without building JDK. >>>> >>>> Thanks in advance, >>>> Radek >>>> >> From jamsheed.c.m at oracle.com Fri May 27 02:35:54 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 27 May 2016 08:05:54 +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: <5746ED82.5050906@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> Message-ID: <5747B28A.7030603@oracle.com> Hi Roland, now i would like to defend my change a bit. By checking for any pending runtime exception before return to interpreter, i limit scope of my change and checks to small area of code. forward_exception_entry is used for checking any pending exception after runtime calls.. in this case , forward_exception_entry will work perfectly! as return_pc is used only for finding where to forward in case of runtime exception! and in our case its always interpreter rethrow exception handler, as return_pc is always is in interpreter. (return pc here can be either _rethrow_exception_entry, or a deopt_entry). interpreter rethrow exception handler is rethrow_exception_entry. return_pc is used only for finding this handler. and it will be always success! rethrow_exception_entry will handle exception as expected! can i go ahead with this change ? Best Regards, Jamsheed On 5/26/2016 6:05 PM, Roland Westrelin wrote: >> On 5/26/2016 4:57 PM, Roland Westrelin wrote: >>> We are replacing an existing exception with another one. Why would the >>> expression stack matter? >> realloc failure in "non exception deoptimization" case. > In that case, we do nothing more than the existing code does. > > Roland. From dean.long at oracle.com Fri May 27 03:58:37 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 26 May 2016 20:58:37 -0700 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: <5747B28A.7030603@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> Message-ID: Hi Jamsheed. I agree with Roland: it would be nice to have a fix in shared code if possible. Keep in mind that if the solution is in platform-specific code, then that also affects aarch64, ppc64, and our closed ports. dl On 5/26/16 7:35 PM, Jamsheed C m wrote: > Hi Roland, > > now i would like to defend my change a bit. > > By checking for any pending runtime exception before return to > interpreter, i limit scope of my change and checks to small area of code. > forward_exception_entry is used for checking any pending exception > after runtime calls.. > > in this case , > forward_exception_entry will work perfectly! as return_pc is used only > for finding where to forward in case of runtime exception! > and in our case its always interpreter rethrow exception handler, as > return_pc is always is in interpreter. > (return pc here can be either _rethrow_exception_entry, or a > deopt_entry). > > interpreter rethrow exception handler is rethrow_exception_entry. > return_pc is used only for finding this handler. and it will be always > success! > > rethrow_exception_entry will handle exception as expected! > > can i go ahead with this change ? > > Best Regards, > Jamsheed > > On 5/26/2016 6:05 PM, Roland Westrelin wrote: >>> On 5/26/2016 4:57 PM, Roland Westrelin wrote: >>>> We are replacing an existing exception with another one. Why would the >>>> expression stack matter? >>> realloc failure in "non exception deoptimization" case. >> In that case, we do nothing more than the existing code does. >> >> Roland. > From jamsheed.c.m at oracle.com Fri May 27 04:52:26 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 27 May 2016 10:22:26 +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> Message-ID: <5747D28A.7050009@oracle.com> Hi Dean, closed part port is already done. sparc, x86,x64 is too done. aarch64 and ppc ports are pending, i can do that as well, or intimate sap/redhat to take that up. Best Regards, Jamsheed On 5/27/2016 9:28 AM, dean.long at oracle.com wrote: > Hi Jamsheed. I agree with Roland: it would be nice to have a fix in > shared code if possible. Keep in mind that if the solution is in > platform-specific code, then that also affects aarch64, ppc64, and our > closed ports. > > dl > > > On 5/26/16 7:35 PM, Jamsheed C m wrote: >> Hi Roland, >> >> now i would like to defend my change a bit. >> >> By checking for any pending runtime exception before return to >> interpreter, i limit scope of my change and checks to small area of >> code. >> forward_exception_entry is used for checking any pending exception >> after runtime calls.. >> >> in this case , >> forward_exception_entry will work perfectly! as return_pc is used >> only for finding where to forward in case of runtime exception! >> and in our case its always interpreter rethrow exception handler, as >> return_pc is always is in interpreter. >> (return pc here can be either _rethrow_exception_entry, or a >> deopt_entry). >> >> interpreter rethrow exception handler is rethrow_exception_entry. >> return_pc is used only for finding this handler. and it will be >> always success! >> >> rethrow_exception_entry will handle exception as expected! >> >> can i go ahead with this change ? >> >> Best Regards, >> Jamsheed >> >> On 5/26/2016 6:05 PM, Roland Westrelin wrote: >>>> On 5/26/2016 4:57 PM, Roland Westrelin wrote: >>>>> We are replacing an existing exception with another one. Why would >>>>> the >>>>> expression stack matter? >>>> realloc failure in "non exception deoptimization" case. >>> In that case, we do nothing more than the existing code does. >>> >>> Roland. >> > From rwestrel at redhat.com Fri May 27 07:43:45 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 27 May 2016 09:43: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: <5747B28A.7030603@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> Message-ID: <5747FAB1.6030908@redhat.com> 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 Fri May 27 09:22:01 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 27 May 2016 14:52:01 +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: <5747FAB1.6030908@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> Message-ID: <574811B9.2000301@oracle.com> 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 vladimir.x.ivanov at oracle.com Fri May 27 14:09:36 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 27 May 2016 17:09:36 +0300 Subject: RFR(S) : 8156469 : [JITtester] Difference in generated golden output when run with Jigsaw build In-Reply-To: <456F89E0-F712-4C7A-9497-3610B98D339C@oracle.com> References: <456F89E0-F712-4C7A-9497-3610B98D339C@oracle.com> Message-ID: <819d01a2-24eb-68f7-0577-3fd5e76c3147@oracle.com> Looks good. Best regards, Vladimir Ivanov On 5/26/16 11:59 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8156469/webrev.00/ >> 56 lines changed: 23 ins; 13 del; 20 mod; > > Hi all, > > could you please review this small fix? > since jit-tester tests can be generated by another version of JDK, there is probability that some of exception messages or stack trace have been changed. this can cause lots of false positive test results. in order to avoid that and make tests more robust, I have changed JIT tester to print/compare just only exception class names. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8156469 > webrev: http://cr.openjdk.java.net/~iignatyev/8156469/webrev.00/ > > Thanks, > ? Igor > From igor.ignatyev at oracle.com Fri May 27 14:09:05 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 27 May 2016 17:09:05 +0300 Subject: RFR(S) : 8156469 : [JITtester] Difference in generated golden output when run with Jigsaw build In-Reply-To: <819d01a2-24eb-68f7-0577-3fd5e76c3147@oracle.com> References: <456F89E0-F712-4C7A-9497-3610B98D339C@oracle.com> <819d01a2-24eb-68f7-0577-3fd5e76c3147@oracle.com> Message-ID: <9D17C5A1-2FE5-4A49-A284-B5D85077F216@oracle.com> Vladimir, thanks for review! ? Igor > On May 27, 2016, at 5:09 PM, Vladimir Ivanov wrote: > > Looks good. > > Best regards, > Vladimir Ivanov > > On 5/26/16 11:59 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8156469/webrev.00/ >>> 56 lines changed: 23 ins; 13 del; 20 mod; >> >> Hi all, >> >> could you please review this small fix? >> since jit-tester tests can be generated by another version of JDK, there is probability that some of exception messages or stack trace have been changed. this can cause lots of false positive test results. in order to avoid that and make tests more robust, I have changed JIT tester to print/compare just only exception class names. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8156469 >> webrev: http://cr.openjdk.java.net/~iignatyev/8156469/webrev.00/ >> >> Thanks, >> ? Igor >> From jamsheed.c.m at oracle.com Fri May 27 14:26:18 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 27 May 2016 19:56:18 +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: <574811B9.2000301@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> Message-ID: <5748590A.10607@oracle.com> 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 dmitrij.pochepko at oracle.com Fri May 27 17:11:20 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 27 May 2016 20:11:20 +0300 Subject: RFR: 8158065 - [Jittester]: tests generation has tests generators hardcoded, blocking alternative tests generation Message-ID: <57487FB8.80309@oracle.com> Hi, please review fix for JDK-8158065: [Jittester]: tests generation has tests generators hardcoded, blocking alternative tests generation Current jittester tests generation design blocks usage of alternative(not hardcoded) tests generators. This patch provides redesign of tests generation part to have generation pluggable and configurable. It affects mostly test generators and its usage in Automation class. webrev: http://cr.openjdk.java.net/~dpochepk/8158065/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8158065 I've tested these changed on linux-amd64. Thanks, Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Mon May 30 10:21:06 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 30 May 2016 12:21:06 +0200 Subject: Slides for our presentation at the Bucharest Technology Week In-Reply-To: <23072a3d-3f97-6ed5-f3e1-cdc2fe046ca5@oracle.com> References: <574BE7DF.8090106@oracle.com> <23072a3d-3f97-6ed5-f3e1-cdc2fe046ca5@oracle.com> Message-ID: <574C1412.6000002@oracle.com> 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 tobias.hartmann at oracle.com Mon May 30 11:22:54 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 30 May 2016 13:22:54 +0200 Subject: [9] RFR(XS): 8157842: indexOfChar intrinsic is not emitted on x86 Message-ID: <574C228E.6050108@oracle.com> 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 rwestrel at redhat.com Mon May 30 12:18:42 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 30 May 2016 14:18:42 +0200 Subject: [9] RFR(XS): 8157842: indexOfChar intrinsic is not emitted on x86 In-Reply-To: <574C228E.6050108@oracle.com> References: <574C228E.6050108@oracle.com> Message-ID: > http://cr.openjdk.java.net/~thartmann/8157842/webrev.00/ That looks good to me. Roland. From tobias.hartmann at oracle.com Mon May 30 12:21:46 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 30 May 2016 14:21:46 +0200 Subject: [9] RFR(XS): 8157842: indexOfChar intrinsic is not emitted on x86 In-Reply-To: References: <574C228E.6050108@oracle.com> Message-ID: <574C305A.1050704@oracle.com> Thanks, Roland! Best regards, Tobias On 30.05.2016 14:18, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8157842/webrev.00/ > > That looks good to me. > > Roland. > From rickard.backman at oracle.com Mon May 30 12:25:37 2016 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Mon, 30 May 2016 14:25:37 +0200 Subject: [9] RFR(XS): 8157842: indexOfChar intrinsic is not emitted on x86 In-Reply-To: <574C228E.6050108@oracle.com> References: <574C228E.6050108@oracle.com> Message-ID: <20160530122537.GH22447@rbackman> Good. /R On 05/30, 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 aleksey.shipilev at oracle.com Mon May 30 12:25:47 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 30 May 2016 15:25:47 +0300 Subject: [9] RFR(XS): 8157842: indexOfChar intrinsic is not emitted on x86 In-Reply-To: <574C228E.6050108@oracle.com> References: <574C228E.6050108@oracle.com> Message-ID: <574C314B.3000403@oracle.com> On 05/30/2016 02:22 PM, Tobias Hartmann wrote: > https://bugs.openjdk.java.net/browse/JDK-8157842 > http://cr.openjdk.java.net/~thartmann/8157842/webrev.00/ +1 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 tobias.hartmann at oracle.com Mon May 30 12:36:23 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 30 May 2016 14:36:23 +0200 Subject: [9] RFR(XS): 8157842: indexOfChar intrinsic is not emitted on x86 In-Reply-To: <574C314B.3000403@oracle.com> References: <574C228E.6050108@oracle.com> <574C314B.3000403@oracle.com> Message-ID: <574C33C7.5090502@oracle.com> Thanks, Rickard and Aleksey! Best regards, Tobias On 30.05.2016 14:25, Aleksey Shipilev wrote: > On 05/30/2016 02:22 PM, Tobias Hartmann wrote: >> https://bugs.openjdk.java.net/browse/JDK-8157842 >> http://cr.openjdk.java.net/~thartmann/8157842/webrev.00/ > > +1 > > Thanks, > -Aleksey > > From forax at univ-mlv.fr Mon May 30 12:36:24 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 30 May 2016 14:36:24 +0200 (CEST) Subject: Slides for our presentation at the Bucharest Technology Week In-Reply-To: <574C1412.6000002@oracle.com> References: <574BE7DF.8090106@oracle.com> <23072a3d-3f97-6ed5-f3e1-cdc2fe046ca5@oracle.com> <574C1412.6000002@oracle.com> Message-ID: <978487420.314182.1464611784859.JavaMail.zimbra@u-pem.fr> 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. 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 zoltan.majo at oracle.com Mon May 30 12:44:27 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 30 May 2016 14:44:27 +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: <574C35AB.4040501@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. thank you for the positive feedback! > > I think you should upload it on the Hotspot wiki for the future generation. Good idea! We'll ask our colleagues on how to go about that. We'll keep you posted. Thank you and best regards, Zolt?n > > 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 tobias.hartmann at oracle.com Mon May 30 12:53:44 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 30 May 2016 14:53:44 +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: <574C37D8.70004@oracle.com> Hi Remi, On 30.05.2016 14:36, 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. Thank you! We'll discuss that. > 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 ? This example is from Aleksey's jfokus presentation (I used it with his consent, see [1], slide 48). Those measurements were done right after Compact Strings integration (JDK 9 b93) before Indify String Concat. I wanted to focus on Compact Strings, in Aleksey's slides you can also find measurements with ISC. > and BTW, part of the 'bloat' in the code cache also comes from the lambda forms compilation. Yes, I actually mentioned this in the talk. Best regards, Tobias [1] http://shipilev.net/talks/jfokus-Feb2016-lord-of-the-strings.pdf > 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 tobias.hartmann at oracle.com Mon May 30 13:55:32 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 30 May 2016 15:55:32 +0200 Subject: [9] RFR(S): 8155046: Parse::Block construction using undefined behavior Message-ID: <574C4654.1090102@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8155046 http://cr.openjdk.java.net/~thartmann/8155046/webrev.00/ Parse::init_blocks() initializes _blocks by allocating a chunk of memory and initializing the elements by treating them as blocks and calling Parse::Block::init_node(). This is undefined behavior because the objects are not created with "new". I replaced init_node() with the constructor and use placement new to create the blocks. I also added missing field initializations to the constructor. Tested with JPRT and RBT (running). Thanks, Tobias From igor.ignatyev at oracle.com Mon May 30 17:44:22 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 30 May 2016 20:44:22 +0300 Subject: RFR (XXS) : 8154123 : remove commented action from jdk/vm/ci/runtime/test/ConstantTest.java Message-ID: http://cr.openjdk.java.net/~iignatyev/8154123/webrev.00/ > 1 line changed: 0 ins; 1 del; 0 mod; Hi all, could you please review this very very tiny fix? JDK-8142968 introduced the commented action which should be removed. JBS: https://bugs.openjdk.java.net/browse/JDK-8154123 webrev: http://cr.openjdk.java.net/~iignatyev/8154123/webrev.00/ Thanks, ? Igor From vladimir.kozlov at oracle.com Mon May 30 17:45:47 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 May 2016 10:45:47 -0700 Subject: [9] RFR(XS): 8157842: indexOfChar intrinsic is not emitted on x86 In-Reply-To: <574C228E.6050108@oracle.com> References: <574C228E.6050108@oracle.com> Message-ID: <2df2a2b0-f903-d0a9-16c9-4be0701fdeb0@oracle.com> match_rule_supported() should check UseSSE42Intrinsics instead since it is used in predicate: predicate(UseSSE42Intrinsics); match(Set result (StrIndexOfChar (Binary str1 cnt1) ch)); 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 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 vladimir.kozlov at oracle.com Mon May 30 17:46:34 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 May 2016 10:46:34 -0700 Subject: RFR (XXS) : 8154123 : remove commented action from jdk/vm/ci/runtime/test/ConstantTest.java In-Reply-To: References: Message-ID: <90cfa067-1453-c762-21f8-a201c09f3c54@oracle.com> Good. thanks, Vladimir On 5/30/16 10:44 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8154123/webrev.00/ >> 1 line changed: 0 ins; 1 del; 0 mod; > > Hi all, > > could you please review this very very tiny fix? JDK-8142968 introduced the commented action which should be removed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154123 > webrev: http://cr.openjdk.java.net/~iignatyev/8154123/webrev.00/ > > Thanks, > ? Igor > From aleksey.shipilev at oracle.com Mon May 30 17:47:22 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 30 May 2016 20:47:22 +0300 Subject: RFR (XXS) : 8154123 : remove commented action from jdk/vm/ci/runtime/test/ConstantTest.java In-Reply-To: References: Message-ID: <574C7CAA.9030407@oracle.com> On 05/30/2016 08:44 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8154123/webrev.00/ >> 1 line changed: 0 ins; 1 del; 0 mod; Looks good. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From vladimir.kozlov at oracle.com Mon May 30 18:01:41 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 May 2016 11:01:41 -0700 Subject: [9] RFR(S): 8155046: Parse::Block construction using undefined behavior In-Reply-To: <574C4654.1090102@oracle.com> References: <574C4654.1090102@oracle.com> Message-ID: <476e77fd-9224-cb19-59b0-80bc7c89ac26@oracle.com> I think it was this way to avoid calling MethodLivenessResult constructor for _live_locals which required parameters until very recent change: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6784b64bacf0#l15.1 Your changes looks fine. Thanks, Vladimir On 5/30/16 6:55 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8155046 > http://cr.openjdk.java.net/~thartmann/8155046/webrev.00/ > > Parse::init_blocks() initializes _blocks by allocating a chunk of memory and initializing the elements by treating them as blocks and calling Parse::Block::init_node(). This is undefined behavior because the objects are not created with "new". I replaced init_node() with the constructor and use placement new to create the blocks. I also added missing field initializations to the constructor. > > Tested with JPRT and RBT (running). > > Thanks, > Tobias > From igor.ignatyev at oracle.com Mon May 30 18:03:27 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 30 May 2016 21:03:27 +0300 Subject: RFR(XS) : 8152376 : [TESTBUG] compiler/floatingpoint/Test15FloatJNIArgs should use run main/othervm/native In-Reply-To: <53A08B91-81FD-4C36-9FF2-780AAE3D99CB@oracle.com> References: <53A08B91-81FD-4C36-9FF2-780AAE3D99CB@oracle.com> Message-ID: <3C854013-1F9C-4E1E-96B6-434C724847CF@oracle.com> a friendly reminder ? Igor > On Apr 12, 2016, at 3:03 AM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8152376/webrev.00/ >> 3 lines changed: 0 ins; 0 del; 3 mod; > > > Hi all, > > could you please review this small fix which adds '/native? option to all main actions? the test uses native library, all such tests should be marked w/ ?/native? option so jtreg would be able to handle them accordingly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8152376 > webrev: http://cr.openjdk.java.net/~iignatyev/8152376/webrev.00/ > > Thanks, > ? Igor From vladimir.kozlov at oracle.com Mon May 30 18:05:21 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 May 2016 11:05:21 -0700 Subject: RFR(XS) : 8152376 : [TESTBUG] compiler/floatingpoint/Test15FloatJNIArgs should use run main/othervm/native In-Reply-To: <53A08B91-81FD-4C36-9FF2-780AAE3D99CB@oracle.com> References: <53A08B91-81FD-4C36-9FF2-780AAE3D99CB@oracle.com> Message-ID: <85a73baa-b716-e665-923d-906022604679@oracle.com> Good. Thanks, Vladimir On 4/11/16 5:03 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8152376/webrev.00/ >> 3 lines changed: 0 ins; 0 del; 3 mod; > > > Hi all, > > could you please review this small fix which adds '/native? option to all main actions? the test uses native library, all such tests should be marked w/ ?/native? option so jtreg would be able to handle them accordingly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8152376 > webrev: http://cr.openjdk.java.net/~iignatyev/8152376/webrev.00/ > > Thanks, > ? Igor > From rsmogura at gmail.com Mon May 30 18:48:10 2016 From: rsmogura at gmail.com (Radek) Date: Mon, 30 May 2016 20:48:10 +0200 Subject: Java shared memory Message-ID: <6B8F88FE-24AF-40E6-96DE-D7443667DA47@gmail.com> Dear all, Please don?t think I?m so crazy. Recently I was working on JVM changes to add shared memory / memory mapping support. I?m able to map part of files as primitive java arrays. First performance results are very optimistic (40% boost in searching min-max long in 1GB file) with mapped long[] as a replacement to LongBuffer. The work is not finished. I have adopted G1, c1 and c2, but I have got mainly stable solution (or I think so). I see three possible benefits of shared memory: 1. Shared memory and interprocess communication. 2. Mapping large files. 3. Aggressive inter-JVM string de-duplication. I?m looking for sponsorship for this change, with some guidelines how I can move forward with possible adoption into JDK. If solution would be viable, I would like to open JSR for JDK API modification. I use https://bitbucket.org/radoslaw_smogura/java-shared-memory/wiki/Home as umbrella repo, but I don?t update it quite often. Thanks in advance, Radek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From aph at redhat.com Mon May 30 20:10:41 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 May 2016 21:10:41 +0100 Subject: Java shared memory In-Reply-To: <6B8F88FE-24AF-40E6-96DE-D7443667DA47@gmail.com> References: <6B8F88FE-24AF-40E6-96DE-D7443667DA47@gmail.com> Message-ID: <574C9E41.30302@redhat.com> On 30/05/16 19:48, Radek wrote: > I?m able to map part of files as primitive java arrays. First > performance results are very optimistic (40% boost in searching > min-max long in 1GB file) with mapped long[] as a replacement to > LongBuffer. It shouldn't be significantly different in performance. Perhaps you can share your benchmark with us. Maybe we're missing vectorization opportunities. Andrew. From igor.ignatyev at oracle.com Mon May 30 20:38:53 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 30 May 2016 23:38:53 +0300 Subject: RFR(XS) : 8152376 : [TESTBUG] compiler/floatingpoint/Test15FloatJNIArgs should use run main/othervm/native In-Reply-To: <85a73baa-b716-e665-923d-906022604679@oracle.com> References: <53A08B91-81FD-4C36-9FF2-780AAE3D99CB@oracle.com> <85a73baa-b716-e665-923d-906022604679@oracle.com> Message-ID: Vladimir, thanks for review. ? Igor > On May 30, 2016, at 9:05 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 4/11/16 5:03 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8152376/webrev.00/ >>> 3 lines changed: 0 ins; 0 del; 3 mod; >> >> >> Hi all, >> >> could you please review this small fix which adds '/native? option to all main actions? the test uses native library, all such tests should be marked w/ ?/native? option so jtreg would be able to handle them accordingly. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8152376 >> webrev: http://cr.openjdk.java.net/~iignatyev/8152376/webrev.00/ >> >> Thanks, >> ? Igor >> From igor.ignatyev at oracle.com Mon May 30 20:39:57 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 30 May 2016 23:39:57 +0300 Subject: RFR (XXS) : 8154123 : remove commented action from jdk/vm/ci/runtime/test/ConstantTest.java In-Reply-To: <574C7CAA.9030407@oracle.com> References: <574C7CAA.9030407@oracle.com> Message-ID: <50811EC6-DDB5-4E23-8E71-02C5933FD25F@oracle.com> Aleksey/Vladimir, thank you both for review. ? Igor > On May 30, 2016, at 8:47 PM, Aleksey Shipilev wrote: > > On 05/30/2016 08:44 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8154123/webrev.00/ >>> 1 line changed: 0 ins; 1 del; 0 mod; > > Looks good. > > Thanks, > -Aleksey > > From igor.ignatyev at oracle.com Mon May 30 21:49:13 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 May 2016 00:49:13 +0300 Subject: RFR(XXS) : 8153994 : Compiler tests should be correctly marked with @module Message-ID: <1220E4AC-7FAD-4946-935F-2E73A2D33595@oracle.com> http://cr.openjdk.java.net/~iignatyev/8153994/webrev.00/ > 1 line changed: 1 ins; 0 del; 0 mod; Hi all, could you please review this tiny fix which adds missed dependency declaration to test/compiler/codecache/jmx/PoolsIndependenceTest.java? the test uses classes from java.management module, but didn?t have it declared via @modules. this causes false positive results in case this module is unavailable. JBS: https://bugs.openjdk.java.net/browse/JDK-8153994 webrev: http://cr.openjdk.java.net/~iignatyev/8153994/webrev.00/ testing: checked that the test isn?t run if '-limitmods java.compact2? is specified, and passed otherwise. Thanks, ? Igor From igor.ignatyev at oracle.com Mon May 30 21:58:51 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 May 2016 00:58:51 +0300 Subject: RFR: 8158065 - [Jittester]: tests generation has tests generators hardcoded, blocking alternative tests generation In-Reply-To: <57487FB8.80309@oracle.com> References: <57487FB8.80309@oracle.com> Message-ID: <81A95C60-8904-476D-99EC-4A16228E0EDB@oracle.com> Hi Dmitrij, looks good to me. Thanks, ? Igor > On May 27, 2016, at 8:11 PM, Dmitrij Pochepko wrote: > > Hi, > > please review fix for JDK-8158065: [Jittester]: tests generation has tests generators hardcoded, blocking alternative tests generation > > Current jittester tests generation design blocks usage of alternative(not hardcoded) tests generators. This patch provides redesign of tests generation part to have generation pluggable and configurable. It affects mostly test generators and its usage in Automation class. > > webrev: http://cr.openjdk.java.net/~dpochepk/8158065/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8158065 > > I've tested these changed on linux-amd64. > > Thanks, > Dmitrij > From igor.ignatyev at oracle.com Mon May 30 22:21:33 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 May 2016 01:21:33 +0300 Subject: RFR(S) : 8073159 : improve Test6857159.java Message-ID: http://cr.openjdk.java.net/~iignatyev/8073159/webrev.00/ > 57 lines changed: 1 ins; 54 del; 2 mod; Hi all, could you please review this fix for test/compiler/c2/6857159/Test6857159.java? the test was ported to java-only by JDK-8068440, but java implementation doesn?t pass exernal vm flags to a child process and doesn?t check that this process exists gracefully. the changeset fixes that and also removes shell-file which is unneeded after JDK-8068440. JBS: https://bugs.openjdk.java.net/browse/JDK-8073159 webrev: http://cr.openjdk.java.net/~iignatyev/8073159/webrev.00/ Thanks, ? Igor From rsmogura at gmail.com Mon May 30 22:57:26 2016 From: rsmogura at gmail.com (Radek) Date: Tue, 31 May 2016 00:57:26 +0200 Subject: Java shared memory In-Reply-To: <574C9E41.30302@redhat.com> References: <6B8F88FE-24AF-40E6-96DE-D7443667DA47@gmail.com> <574C9E41.30302@redhat.com> Message-ID: Dear Andrew, I?ve just modified test case to convert bytes to long in code. The results are comparable. Attached please find out files. Those are named as follow: * memorymap - from MemoryMapMinMax, file map from FileMapMinMax * memorymap2, filemap2 form *Bytes version respectively I?m attaching text files with results, and test classes (those are my test classes, so not nicely formatted). I could do something wrong with C2, but I think results are expected as NIO in back copies mapped array to Java array, does it? Best regards, Radek -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: filemap2_100000_jdkmod_oopcomp1_feature0.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: filemap2_100000_jdkmod_oopcomp1_feature0.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: memorymap_134217728_jdk9mod_oopcomp1_feature1.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: memorymap2_134217728_jdk9mod_oopcomp1_feature1.txt URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: FileMapMinMax.java Type: application/octet-stream Size: 4271 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FileMapMinMaxBytes.java Type: application/octet-stream Size: 4853 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MemoryMapMinMax.java Type: application/octet-stream Size: 2343 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MemoryMapMinMaxBytes.java Type: application/octet-stream Size: 2636 bytes Desc: not available URL: -------------- next part -------------- > On 30 May 2016, at 22:10, Andrew Haley wrote: > > On 30/05/16 19:48, Radek wrote: > >> I?m able to map part of files as primitive java arrays. First >> performance results are very optimistic (40% boost in searching >> min-max long in 1GB file) with mapped long[] as a replacement to >> LongBuffer. > > It shouldn't be significantly different in performance. Perhaps you > can share your benchmark with us. Maybe we're missing vectorization > opportunities. > > Andrew. From igor.ignatyev at oracle.com Mon May 30 23:39:03 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 May 2016 02:39:03 +0300 Subject: RFR(XS) : 8158182 : remove shell script from compiler/c2/6894807/IsInstanceTest.java Message-ID: http://cr.openjdk.java.net/~iignatyev/8158182/webrev.00/ > 57 lines changed: 0 ins; 55 del; 2 mod; Hi all, could you please review this fix which removes shell script from compiler/c2/6894807/IsInstanceTest.java test? the test used shell script to check that output of IsInstanceTest doesn?t contain 'Failed at index:? string. pretty much the same can be achieved by throwing an exception in IsInstanceTest class. webrev: http://cr.openjdk.java.net/~iignatyev/8158182/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8158182 testing: the modified test locally Thanks, ? Igor From igor.ignatyev at oracle.com Tue May 31 00:08:01 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 May 2016 03:08:01 +0300 Subject: RFR(XXS) : 8158185 : jdk/test/lib/FileInstaller throws NPE if dst is in current directory Message-ID: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ > 2 lines changed: 0 ins; 0 del; 2 mod; Hi all, could you please review this small changeset which fixes FileInstaller? FileInstaller throws NPE if 2nd argument (dst) is in current directory, this happens because Path::getParent returns null if Path doesn?t have a parent. to prevent this, I added Path::toAbsolutePath call. JBS: https://bugs.openjdk.java.net/browse/JDK-8158185 webrev: http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ Thanks, ? Igor From igor.ignatyev at oracle.com Tue May 31 00:15:52 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 May 2016 03:15:52 +0300 Subject: RFR(XS) : 8158184 : remove shell from compiler/c2/7070134/Stemmer.java Message-ID: <95615A5C-1B50-491D-886B-E82292765098@oracle.com> http://cr.openjdk.java.net/~iignatyev/8158184/webrev.00/ > 50 lines changed: 2 ins; 45 del; 3 mod; Hi all, could you please review this changeset which remove shell from compiler/c2/7070134/Stemmer.java test? the test uses shell script to copy a file from test sources to current directory before executing Stemmer class, now the test uses jdk/test/lib/FileInstaller for the same purpose. NB the fix is blocked by https://bugs.openjdk.java.net/browse/JDK-8158185 which is currently under review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/023245.html webrev: http://cr.openjdk.java.net/~iignatyev/8158184/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8158184 testing: the modified test Thanks, ? Igor From david.holmes at oracle.com Tue May 31 01:26:23 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 May 2016 11:26:23 +1000 Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32 In-Reply-To: <5746FDF3.3030102@oracle.com> References: <5746FDF3.3030102@oracle.com> Message-ID: 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 Tue May 31 02:07:14 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 May 2016 19:07:14 -0700 Subject: RFR(XXS) : 8153994 : Compiler tests should be correctly marked with @module In-Reply-To: <1220E4AC-7FAD-4946-935F-2E73A2D33595@oracle.com> References: <1220E4AC-7FAD-4946-935F-2E73A2D33595@oracle.com> Message-ID: Looks good. thanks, Vladimir On 5/30/16 2:49 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8153994/webrev.00/ >> 1 line changed: 1 ins; 0 del; 0 mod; > > Hi all, > > could you please review this tiny fix which adds missed dependency declaration to test/compiler/codecache/jmx/PoolsIndependenceTest.java? > the test uses classes from java.management module, but didn?t have it declared via @modules. this causes false positive results in case this module is unavailable. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8153994 > webrev: http://cr.openjdk.java.net/~iignatyev/8153994/webrev.00/ > testing: checked that the test isn?t run if '-limitmods java.compact2? is specified, and passed otherwise. > > Thanks, > ? Igor > From vladimir.kozlov at oracle.com Tue May 31 02:08:17 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 May 2016 19:08:17 -0700 Subject: RFR(S) : 8073159 : improve Test6857159.java In-Reply-To: References: Message-ID: Good. thanks, Vladimir On 5/30/16 3:21 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8073159/webrev.00/ >> 57 lines changed: 1 ins; 54 del; 2 mod; > > Hi all, > > could you please review this fix for test/compiler/c2/6857159/Test6857159.java? > the test was ported to java-only by JDK-8068440, but java implementation doesn?t pass exernal vm flags to a child process and doesn?t check that this process exists gracefully. the changeset fixes that and also removes shell-file which is unneeded after JDK-8068440. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8073159 > webrev: http://cr.openjdk.java.net/~iignatyev/8073159/webrev.00/ > > Thanks, > ? Igor > From vladimir.kozlov at oracle.com Tue May 31 02:10:18 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 May 2016 19:10:18 -0700 Subject: RFR(XS) : 8158182 : remove shell script from compiler/c2/6894807/IsInstanceTest.java In-Reply-To: References: Message-ID: <0215565f-b121-b164-16b3-a63838bf6d3a@oracle.com> Good. Thanks, Vladimir On 5/30/16 4:39 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8158182/webrev.00/ >> 57 lines changed: 0 ins; 55 del; 2 mod; > > Hi all, > > could you please review this fix which removes shell script from compiler/c2/6894807/IsInstanceTest.java test? > > the test used shell script to check that output of IsInstanceTest doesn?t contain 'Failed at index:? string. pretty much the same can be achieved by throwing an exception in IsInstanceTest class. > > webrev: http://cr.openjdk.java.net/~iignatyev/8158182/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8158182 > testing: the modified test locally > > Thanks, > ? Igor > From vladimir.kozlov at oracle.com Tue May 31 02:13:47 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 May 2016 19:13:47 -0700 Subject: RFR(XS) : 8158184 : remove shell from compiler/c2/7070134/Stemmer.java In-Reply-To: <95615A5C-1B50-491D-886B-E82292765098@oracle.com> References: <95615A5C-1B50-491D-886B-E82292765098@oracle.com> Message-ID: <8c9820ed-e26f-ec2c-cf15-af1921a1eb48@oracle.com> Good. Thanks, Vladimir On 5/30/16 5:15 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8158184/webrev.00/ >> 50 lines changed: 2 ins; 45 del; 3 mod; > > Hi all, > > could you please review this changeset which remove shell from compiler/c2/7070134/Stemmer.java test? the test uses shell script to copy a file from test sources to current directory before executing Stemmer class, now the test uses jdk/test/lib/FileInstaller for the same purpose. > > NB the fix is blocked by https://bugs.openjdk.java.net/browse/JDK-8158185 which is currently under review : http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-May/023245.html > > webrev: http://cr.openjdk.java.net/~iignatyev/8158184/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8158184 > testing: the modified test > > Thanks, > ? Igor > From vladimir.kozlov at oracle.com Tue May 31 02:14:59 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 May 2016 19:14:59 -0700 Subject: RFR(XXS) : 8158185 : jdk/test/lib/FileInstaller throws NPE if dst is in current directory In-Reply-To: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> References: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> Message-ID: <75237a6f-6688-9a3d-7c39-2debd2850271@oracle.com> Looks good. Igor, how are you testing all these tests fixes? Thanks, Vladimir On 5/30/16 5:08 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ >> 2 lines changed: 0 ins; 0 del; 2 mod; > > Hi all, > > could you please review this small changeset which fixes FileInstaller? FileInstaller throws NPE if 2nd argument (dst) is in current directory, this happens because Path::getParent returns null if Path doesn?t have a parent. to prevent this, I added Path::toAbsolutePath call. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8158185 > webrev: http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ > > Thanks, > ? Igor > From tobias.hartmann at oracle.com Tue May 31 06:00:55 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 31 May 2016 08:00:55 +0200 Subject: [9] RFR(S): 8155046: Parse::Block construction using undefined behavior In-Reply-To: <476e77fd-9224-cb19-59b0-80bc7c89ac26@oracle.com> References: <574C4654.1090102@oracle.com> <476e77fd-9224-cb19-59b0-80bc7c89ac26@oracle.com> Message-ID: <574D2897.2040204@oracle.com> Hi Vladimir, thanks for the review! On 30.05.2016 20:01, Vladimir Kozlov wrote: > I think it was this way to avoid calling MethodLivenessResult constructor for _live_locals which required parameters until very recent change: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6784b64bacf0#l15.1 Right, good that this was changed. > Your changes looks fine. Thanks, Tobias > > Thanks, > Vladimir > > On 5/30/16 6:55 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> https://bugs.openjdk.java.net/browse/JDK-8155046 >> http://cr.openjdk.java.net/~thartmann/8155046/webrev.00/ >> >> Parse::init_blocks() initializes _blocks by allocating a chunk of memory and initializing the elements by treating them as blocks and calling Parse::Block::init_node(). This is undefined behavior because the objects are not created with "new". I replaced init_node() with the constructor and use placement new to create the blocks. I also added missing field initializations to the constructor. >> >> Tested with JPRT and RBT (running). >> >> Thanks, >> Tobias >> From paul.sandoz at oracle.com Tue May 31 08:27:21 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 31 May 2016 10:27:21 +0200 Subject: Java shared memory In-Reply-To: References: <6B8F88FE-24AF-40E6-96DE-D7443667DA47@gmail.com> <574C9E41.30302@redhat.com> Message-ID: Hi Radek, > On 31 May 2016, at 00:57, Radek wrote: > > Dear Andrew, > > I?ve just modified test case to convert bytes to long in code. The results are comparable. > > Attached please find out files. Those are named as follow: > * memorymap - from MemoryMapMinMax, file map from FileMapMinMax > * memorymap2, filemap2 form *Bytes version respectively > > I?m attaching text files with results, and test classes (those are my test classes, so not nicely formatted). > > I could do something wrong with C2, but I think results are expected as NIO in back copies mapped array to Java array, does it? > Like Andrew my expectation was that a long view over a mapped byte buffer should not be significantly different. (Note: it?s hard to evaluate these kind of things without using JMH and also looking at the generated code). Here is your main loop for LongBuffer: while (lbuff.hasRemaining()) { lbuff.get(ll); for (long l : ll) { if (l < min) min = l; if (l > max) max = l; lastNumber = l; } } You are bulk copying into an array, that alone could explain an ~2x performance difference. Instead, use the indexed accessors LongBuffer.get(int ) e.g.something like: for (int i = 0; i < lbuffer.limit(); i++) { l = lbuff.get(i); if (l < min) min = l; if (l > max) max = l; lastNumber = l; ... } If you take a closer look at the buffer source you will notice long views over byte buffers are optimized in certain cases to direct calls to Unsafe.get/setLong. While lbuff.get(i) is not ll[i], it?s not far off :-) Relatedly, see the recent work by Mr. (David) Simms on this list, so that int[] implements Arrayish. I dunno if this can apply to classes, such as making LongBuffer implement Arrayish, and (thinking out loud) javac can support the array syntax for all arrayish things. Paul. > Best regards, > Radek > > > >> On 30 May 2016, at 22:10, Andrew Haley wrote: >> >> On 30/05/16 19:48, Radek wrote: >> >>> I?m able to map part of files as primitive java arrays. First >>> performance results are very optimistic (40% boost in searching >>> min-max long in 1GB file) with mapped long[] as a replacement to >>> LongBuffer. >> >> It shouldn't be significantly different in performance. Perhaps you >> can share your benchmark with us. Maybe we're missing vectorization >> opportunities. >> >> Andrew. > -------------- 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 tobias.hartmann at oracle.com Tue May 31 09:32:42 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 31 May 2016 11:32:42 +0200 Subject: [9] RFR(XS): 8157842: indexOfChar intrinsic is not emitted on x86 In-Reply-To: <2df2a2b0-f903-d0a9-16c9-4be0701fdeb0@oracle.com> References: <574C228E.6050108@oracle.com> <2df2a2b0-f903-d0a9-16c9-4be0701fdeb0@oracle.com> Message-ID: <574D5A3A.1010101@oracle.com> 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 rsmogura at gmail.com Tue May 31 10:44:16 2016 From: rsmogura at gmail.com (Radek) Date: Tue, 31 May 2016 12:44:16 +0200 Subject: Java shared memory In-Reply-To: References: <6B8F88FE-24AF-40E6-96DE-D7443667DA47@gmail.com> <574C9E41.30302@redhat.com> Message-ID: <808B4C05-4F65-4DD4-9E12-49423A84CC0A@gmail.com> 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 don?t know if in such a case my work could be interesting. 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 -------------- An embedded and charset-unspecified text was scrubbed... Name: JSM_Mapping_results.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MemoryMapMinMax.java Type: application/octet-stream Size: 2101 bytes Desc: not available URL: -------------- next part -------------- > On 31 May 2016, at 10:27, Paul Sandoz wrote: > > Hi Radek, > >> On 31 May 2016, at 00:57, Radek wrote: >> >> Dear Andrew, >> >> I?ve just modified test case to convert bytes to long in code. The results are comparable. >> >> Attached please find out files. Those are named as follow: >> * memorymap - from MemoryMapMinMax, file map from FileMapMinMax >> * memorymap2, filemap2 form *Bytes version respectively >> >> I?m attaching text files with results, and test classes (those are my test classes, so not nicely formatted). >> >> I could do something wrong with C2, but I think results are expected as NIO in back copies mapped array to Java array, does it? >> > > Like Andrew my expectation was that a long view over a mapped byte buffer should not be significantly different. > > (Note: it?s hard to evaluate these kind of things without using JMH and also looking at the generated code). > > Here is your main loop for LongBuffer: > > while (lbuff.hasRemaining()) { > lbuff.get(ll); > for (long l : ll) { > if (l < min) min = l; > if (l > max) max = l; > lastNumber = l; > } > } > > You are bulk copying into an array, that alone could explain an ~2x performance difference. > > Instead, use the indexed accessors LongBuffer.get(int ) e.g.something like: > > for (int i = 0; i < lbuffer.limit(); i++) { > l = lbuff.get(i); > if (l < min) min = l; > if (l > max) max = l; > lastNumber = l; ... > } > > If you take a closer look at the buffer source you will notice long views over byte buffers are optimized in certain cases to direct calls to Unsafe.get/setLong. > > While lbuff.get(i) is not ll[i], it?s not far off :-) > > > Relatedly, see the recent work by Mr. (David) Simms on this list, so that int[] implements Arrayish. I dunno if this can apply to classes, such as making LongBuffer implement Arrayish, and (thinking out loud) javac can support the array syntax for all arrayish things. > > Paul. > > >> Best regards, >> Radek >> >> >> >>> On 30 May 2016, at 22:10, Andrew Haley wrote: >>> >>> On 30/05/16 19:48, Radek wrote: >>> >>>> I?m able to map part of files as primitive java arrays. First >>>> performance results are very optimistic (40% boost in searching >>>> min-max long in 1GB file) with mapped long[] as a replacement to >>>> LongBuffer. >>> >>> It shouldn't be significantly different in performance. Perhaps you >>> can share your benchmark with us. Maybe we're missing vectorization >>> opportunities. >>> >>> Andrew. >> > From jamsheed.c.m at oracle.com Tue May 31 11:06:31 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Tue, 31 May 2016 16:36:31 +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: <5748590A.10607@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> Message-ID: <9c1e6f01-afd4-036c-d907-6fee19fecce1@oracle.com> 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 vladimir.x.ivanov at oracle.com Tue May 31 11:31:27 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 31 May 2016 14:31:27 +0300 Subject: Java shared memory In-Reply-To: <6B8F88FE-24AF-40E6-96DE-D7443667DA47@gmail.com> References: <6B8F88FE-24AF-40E6-96DE-D7443667DA47@gmail.com> Message-ID: <6cdfd335-8165-e6f8-3f58-26a43395c7d2@oracle.com> Radek, Unfortunately, I don't see any source file changes in the project you linked. It seems your project can be split into 2 independent parts: (1) accessing off-heap memory; (2) representing off-heap region as primitive array. As I understand, it should cover all use cases you mentioned. Off-heap memory access is already supported by NIO (MappedByteBuffer & DirectByteBuffer). In Java 9 VarHandles will provide int[]/long[]/... views over ByteBuffers (see MethodHandles.byteBufferViewVarHandle [1]) with impressive performance characteristics. Forward compatibility aspect (represent off-heap region as byte[]/int[]/... instance) fits perfectly into Arrays 2.0 project (see John's presentation at JVMLS 2012 for more details [2]). As Paul already mentioned, David Simms has been working on j.l.Arrayish [2] support and made impressive progress (the idea is the JVM can link *aload/*astore bytecode instructions to methods on Arrayish interface). Have you had a chance to look into ByteBuffers/Varhandles & j.l.Arrayish? It would be very interesting to hear about your experience. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.base/share/classes/java/lang/invoke/MethodHandles.java#l2405 [2] http://www.oracle.com/technetwork/java/javase/community/jvmls2012-1840099.html http://cr.openjdk.java.net/~jrose/pres/201207-Arrays-2.pdf [3] http://mail.openjdk.java.net/pipermail/valhalla-dev/2016-April/001892.html http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/tip/src/java.base/share/classes/java/lang/Arrayish.java On 5/30/16 9:48 PM, Radek wrote: > Dear all, > > Please don?t think I?m so crazy. Recently I was working on JVM changes to add shared memory / memory mapping support. > > I?m able to map part of files as primitive java arrays. First performance results are very optimistic (40% boost in searching min-max long in 1GB file) with mapped long[] as a replacement to LongBuffer. The work is not finished. I have adopted G1, c1 and c2, but I have got mainly stable solution (or I think so). > > I see three possible benefits of shared memory: > 1. Shared memory and interprocess communication. > 2. Mapping large files. > 3. Aggressive inter-JVM string de-duplication. > > I?m looking for sponsorship for this change, with some guidelines how I can move forward with possible adoption into JDK. If solution would be viable, I would like to open JSR for JDK API modification. > > I use https://bitbucket.org/radoslaw_smogura/java-shared-memory/wiki/Home as umbrella repo, but I don?t update it quite often. > > Thanks in advance, > Radek > > From dmitrij.pochepko at oracle.com Tue May 31 12:14:51 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 31 May 2016 15:14:51 +0300 Subject: RFR: 8158065 - [Jittester]: tests generation has tests generators hardcoded, blocking alternative tests generation In-Reply-To: <81A95C60-8904-476D-99EC-4A16228E0EDB@oracle.com> References: <57487FB8.80309@oracle.com> <81A95C60-8904-476D-99EC-4A16228E0EDB@oracle.com> Message-ID: <574D803B.6000807@oracle.com> Thank you for review! > Hi Dmitrij, > > looks good to me. > > Thanks, > ? Igor >> On May 27, 2016, at 8:11 PM, Dmitrij Pochepko wrote: >> >> Hi, >> >> please review fix for JDK-8158065: [Jittester]: tests generation has tests generators hardcoded, blocking alternative tests generation >> >> Current jittester tests generation design blocks usage of alternative(not hardcoded) tests generators. This patch provides redesign of tests generation part to have generation pluggable and configurable. It affects mostly test generators and its usage in Automation class. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8158065/webrev.01/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8158065 >> >> I've tested these changed on linux-amd64. >> >> Thanks, >> Dmitrij >> From tobias.hartmann at oracle.com Tue May 31 12:48:23 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 31 May 2016 14:48:23 +0200 Subject: [9] RFR(S): 8158214: Crash with "assert(VM_Version::supports_sse4_1()) failed" if UseSSE < 4 is set Message-ID: <574D8817.70105@oracle.com> 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 zoltan.majo at oracle.com Tue May 31 12:57:14 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 31 May 2016 14:57:14 +0200 Subject: [9] RFR(S): 8158214: Crash with "assert(VM_Version::supports_sse4_1()) failed" if UseSSE < 4 is set In-Reply-To: <574D8817.70105@oracle.com> References: <574D8817.70105@oracle.com> Message-ID: <574D8A2A.5030908@oracle.com> Hi Tobias, that looks good to me! Thank you and best regards, Zoltan On 05/31/2016 02:48 PM, 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 aph at redhat.com Tue May 31 13:13:25 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 May 2016 14:13:25 +0100 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: <574D8DF5.8010301@redhat.com> On 05/31/2016 11:44 AM, Radek wrote: > 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 would not expect to see any difference at all with mapped long buffers. I don't think this is worth doing, and I could not find the source for your changes to check for myself. Andrew. From tobias.hartmann at oracle.com Tue May 31 13:21:50 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 31 May 2016 15:21:50 +0200 Subject: [9] RFR(S): 8158214: Crash with "assert(VM_Version::supports_sse4_1()) failed" if UseSSE < 4 is set In-Reply-To: <574D8A2A.5030908@oracle.com> References: <574D8817.70105@oracle.com> <574D8A2A.5030908@oracle.com> Message-ID: <574D8FEE.5040906@oracle.com> Thanks, Zoltan! Best regards, Tobias On 31.05.2016 14:57, Zolt?n Maj? wrote: > Hi Tobias, > > > that looks good to me! > > Thank you and best regards, > > > Zoltan > > > On 05/31/2016 02:48 PM, 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 igor.ignatyev at oracle.com Tue May 31 13:29:59 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 May 2016 16:29:59 +0300 Subject: RFR(XXS) : 8158185 : jdk/test/lib/FileInstaller throws NPE if dst is in current directory In-Reply-To: <75237a6f-6688-9a3d-7c39-2debd2850271@oracle.com> References: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> <75237a6f-6688-9a3d-7c39-2debd2850271@oracle.com> Message-ID: Hi Vladimir, 1st of all, thank you for reviewing all these changes! regarding testing, I run all changed tests locally on mac and run all hotspot/compiler tests remotely on all supported platforms in fastdebug, product variant w/ Xcomp,Xmixed. this particular fix was tested as a part of JDK-8158184 testing. Thanks, ? Igor > On May 31, 2016, at 5:14 AM, Vladimir Kozlov wrote: > > Looks good. > > Igor, how are you testing all these tests fixes? > > Thanks, > Vladimir > > On 5/30/16 5:08 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ >>> 2 lines changed: 0 ins; 0 del; 2 mod; >> >> Hi all, >> >> could you please review this small changeset which fixes FileInstaller? FileInstaller throws NPE if 2nd argument (dst) is in current directory, this happens because Path::getParent returns null if Path doesn?t have a parent. to prevent this, I added Path::toAbsolutePath call. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8158185 >> webrev: http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ >> >> Thanks, >> ? Igor >> From rsmogura at gmail.com Tue May 31 13:30:49 2016 From: rsmogura at gmail.com (Radek) Date: Tue, 31 May 2016 15:30:49 +0200 Subject: Java shared memory In-Reply-To: <6cdfd335-8165-e6f8-3f58-26a43395c7d2@oracle.com> References: <6B8F88FE-24AF-40E6-96DE-D7443667DA47@gmail.com> <6cdfd335-8165-e6f8-3f58-26a43395c7d2@oracle.com> Message-ID: <9D0BEFF0-B512-4A6C-BAB6-554931732B0F@gmail.com> Dear all, Thank you for your effort, I understand that the proposal was rejected. I maintain code here https://bitbucket.org/radoslaw_smogura/jshm-jdk9-hotspot/ (please don?t laugh I started with this more as prototype, but remarks are always welcome). The approach I used is (or actually was) to store the pointer to actuall elements just after a length field (for primitive arrays). This pointer for ordinal arrays would point to heap space just after header, for attached arrays it can point anywhere. I exposed just attachMemory0 native call (which could be hidden in other ways from unrestricted access) to native library which did all the mappings. Someone could use this to create shared POSIX or other region to store char / bytes of String and then reduplicate Strings among JVMs. As pointer can be arbitrary I?m not limited to page boundaries for C mapping. With this approach for small cost of loading pointers, and slightly size increase I could maintain arrays as normal and keep assembly code still effective. The thing except changes to compiler were to properly handle SIGBUS. And yes it?s faster... Thanks for your time and have a nice day Radek > On 31 May 2016, at 13:31, Vladimir Ivanov wrote: > > Radek, > > Unfortunately, I don't see any source file changes in the project you linked. > > It seems your project can be split into 2 independent parts: > (1) accessing off-heap memory; > (2) representing off-heap region as primitive array. > > As I understand, it should cover all use cases you mentioned. > > Off-heap memory access is already supported by NIO (MappedByteBuffer & DirectByteBuffer). In Java 9 VarHandles will provide int[]/long[]/... views over ByteBuffers (see MethodHandles.byteBufferViewVarHandle [1]) with impressive performance characteristics. > > Forward compatibility aspect (represent off-heap region as byte[]/int[]/... instance) fits perfectly into Arrays 2.0 project (see John's presentation at JVMLS 2012 for more details [2]). As Paul already mentioned, David Simms has been working on j.l.Arrayish [2] support and made impressive progress (the idea is the JVM can link *aload/*astore bytecode instructions to methods on Arrayish interface). > > Have you had a chance to look into ByteBuffers/Varhandles & j.l.Arrayish? It would be very interesting to hear about your experience. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.base/share/classes/java/lang/invoke/MethodHandles.java#l2405 > > [2] http://www.oracle.com/technetwork/java/javase/community/jvmls2012-1840099.html > http://cr.openjdk.java.net/~jrose/pres/201207-Arrays-2.pdf > > [3] http://mail.openjdk.java.net/pipermail/valhalla-dev/2016-April/001892.html > http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/tip/src/java.base/share/classes/java/lang/Arrayish.java > > On 5/30/16 9:48 PM, Radek wrote: >> Dear all, >> >> Please don?t think I?m so crazy. Recently I was working on JVM changes to add shared memory / memory mapping support. >> >> I?m able to map part of files as primitive java arrays. First performance results are very optimistic (40% boost in searching min-max long in 1GB file) with mapped long[] as a replacement to LongBuffer. The work is not finished. I have adopted G1, c1 and c2, but I have got mainly stable solution (or I think so). >> >> I see three possible benefits of shared memory: >> 1. Shared memory and interprocess communication. >> 2. Mapping large files. >> 3. Aggressive inter-JVM string de-duplication. >> >> I?m looking for sponsorship for this change, with some guidelines how I can move forward with possible adoption into JDK. If solution would be viable, I would like to open JSR for JDK API modification. >> >> I use https://bitbucket.org/radoslaw_smogura/java-shared-memory/wiki/Home as umbrella repo, but I don?t update it quite often. >> >> Thanks in advance, >> Radek >> >> From vladimir.x.ivanov at oracle.com Tue May 31 13:48:55 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 31 May 2016 16:48:55 +0300 Subject: Java shared memory In-Reply-To: <9D0BEFF0-B512-4A6C-BAB6-554931732B0F@gmail.com> References: <6B8F88FE-24AF-40E6-96DE-D7443667DA47@gmail.com> <6cdfd335-8165-e6f8-3f58-26a43395c7d2@oracle.com> <9D0BEFF0-B512-4A6C-BAB6-554931732B0F@gmail.com> Message-ID: <5a82c73b-ac09-8015-e8e7-e21bd3a2d3c3@oracle.com> Radek, > Thank you for your effort, I understand that the proposal was rejected. > > I maintain code here https://bitbucket.org/radoslaw_smogura/jshm-jdk9-hotspot/ (please don?t laugh I started with this more as prototype, but remarks are always welcome). Thanks for sharing it! > The approach I used is (or actually was) to store the pointer to actuall elements just after a length field (for primitive arrays). This pointer for ordinal arrays would point to heap space just after header, for attached arrays it can point anywhere. It sounds very similar to Packed Objects by IBM [1], which generalize the idea from primitive arrays to arbitrary Java objects ( having (target,offset) pair as part of Java object header). Best regards, Vladimir Ivanov [1] http://www.oracle.com/technetwork/java/jvmls2013sciam-2013525.pdf > > I exposed just attachMemory0 native call (which could be hidden in other ways from unrestricted access) to native library which did all the mappings. Someone could use this to create shared POSIX or other region to store char / bytes of String and then reduplicate Strings among JVMs. As pointer can be arbitrary I?m not limited to page boundaries for C mapping. > > With this approach for small cost of loading pointers, and slightly size increase I could maintain arrays as normal and keep assembly code still effective. > > The thing except changes to compiler were to properly handle SIGBUS. > > And yes it?s faster... > > Thanks for your time and have a nice day > Radek > >> On 31 May 2016, at 13:31, Vladimir Ivanov wrote: >> >> Radek, >> >> Unfortunately, I don't see any source file changes in the project you linked. >> >> It seems your project can be split into 2 independent parts: >> (1) accessing off-heap memory; >> (2) representing off-heap region as primitive array. >> >> As I understand, it should cover all use cases you mentioned. >> >> Off-heap memory access is already supported by NIO (MappedByteBuffer & DirectByteBuffer). In Java 9 VarHandles will provide int[]/long[]/... views over ByteBuffers (see MethodHandles.byteBufferViewVarHandle [1]) with impressive performance characteristics. >> >> Forward compatibility aspect (represent off-heap region as byte[]/int[]/... instance) fits perfectly into Arrays 2.0 project (see John's presentation at JVMLS 2012 for more details [2]). As Paul already mentioned, David Simms has been working on j.l.Arrayish [2] support and made impressive progress (the idea is the JVM can link *aload/*astore bytecode instructions to methods on Arrayish interface). >> >> Have you had a chance to look into ByteBuffers/Varhandles & j.l.Arrayish? It would be very interesting to hear about your experience. >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.base/share/classes/java/lang/invoke/MethodHandles.java#l2405 >> >> [2] http://www.oracle.com/technetwork/java/javase/community/jvmls2012-1840099.html >> http://cr.openjdk.java.net/~jrose/pres/201207-Arrays-2.pdf >> >> [3] http://mail.openjdk.java.net/pipermail/valhalla-dev/2016-April/001892.html >> http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/tip/src/java.base/share/classes/java/lang/Arrayish.java >> >> On 5/30/16 9:48 PM, Radek wrote: >>> Dear all, >>> >>> Please don?t think I?m so crazy. Recently I was working on JVM changes to add shared memory / memory mapping support. >>> >>> I?m able to map part of files as primitive java arrays. First performance results are very optimistic (40% boost in searching min-max long in 1GB file) with mapped long[] as a replacement to LongBuffer. The work is not finished. I have adopted G1, c1 and c2, but I have got mainly stable solution (or I think so). >>> >>> I see three possible benefits of shared memory: >>> 1. Shared memory and interprocess communication. >>> 2. Mapping large files. >>> 3. Aggressive inter-JVM string de-duplication. >>> >>> I?m looking for sponsorship for this change, with some guidelines how I can move forward with possible adoption into JDK. If solution would be viable, I would like to open JSR for JDK API modification. >>> >>> I use https://bitbucket.org/radoslaw_smogura/java-shared-memory/wiki/Home as umbrella repo, but I don?t update it quite often. >>> >>> Thanks in advance, >>> Radek >>> >>> > From igor.ignatyev at oracle.com Tue May 31 16:46:55 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 May 2016 19:46:55 +0300 Subject: RFR(M) : 8149043 : Fix code indentation in test/compiler/stable tests Message-ID: http://cr.openjdk.java.net/~iignatyev/8149043/webrev.00/ > 308 lines changed: 0 ins; 2 del; 306 mod; Hi all, could you please review this whitespace-only changeset which restores code indentation in compiler/stable tests? JBS: https://bugs.openjdk.java.net/browse/JDK-8149043 webrev: http://cr.openjdk.java.net/~iignatyev/8149043/webrev.00/ testing: compiler/stable/* locally Thanks, ? Igor From igor.ignatyev at oracle.com Tue May 31 17:22:44 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 May 2016 20:22:44 +0300 Subject: RFR(M) : 8149043 : Fix code indentation in test/compiler/stable tests In-Reply-To: References: Message-ID: noticed that by default webrev ignores whitespaces, I?ve uploaded http://cr.openjdk.java.net/~iignatyev/8149043/webrev.01 which shows whitespaces as well. ? Igor > On May 31, 2016, at 7:46 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8149043/webrev.00/ >> 308 lines changed: 0 ins; 2 del; 306 mod; > > Hi all, > > could you please review this whitespace-only changeset which restores code indentation in compiler/stable tests? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8149043 > webrev: http://cr.openjdk.java.net/~iignatyev/8149043/webrev.00/ > testing: compiler/stable/* locally > > Thanks, > ? Igor From vladimir.x.ivanov at oracle.com Tue May 31 17:36:26 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 31 May 2016 20:36:26 +0300 Subject: RFR(M) : 8149043 : Fix code indentation in test/compiler/stable tests In-Reply-To: References: Message-ID: <81acd64a-ee95-5a14-c978-78056b15e977@oracle.com> Reviewed. Best regards, Vladimir Ivanov On 5/31/16 8:22 PM, Igor Ignatyev wrote: > noticed that by default webrev ignores whitespaces, I?ve uploaded http://cr.openjdk.java.net/~iignatyev/8149043/webrev.01 which shows whitespaces as well. > > ? Igor > >> On May 31, 2016, at 7:46 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev/8149043/webrev.00/ >>> 308 lines changed: 0 ins; 2 del; 306 mod; >> >> Hi all, >> >> could you please review this whitespace-only changeset which restores code indentation in compiler/stable tests? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8149043 >> webrev: http://cr.openjdk.java.net/~iignatyev/8149043/webrev.00/ >> testing: compiler/stable/* locally >> >> Thanks, >> ? Igor > From vladimir.kozlov at oracle.com Tue May 31 17:48:30 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 31 May 2016 10:48:30 -0700 Subject: [9] RFR(S): 8158214: Crash with "assert(VM_Version::supports_sse4_1()) failed" if UseSSE < 4 is set In-Reply-To: <574D8817.70105@oracle.com> References: <574D8817.70105@oracle.com> Message-ID: <92b567c1-5c3d-d37b-3a28-2fb8c379c1c9@oracle.com> 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); } 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 vladimir.kozlov at oracle.com Tue May 31 18:04:27 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 31 May 2016 11:04:27 -0700 Subject: [9] RFR(XS): 8157842: indexOfChar intrinsic is not emitted on x86 In-Reply-To: <574D5A3A.1010101@oracle.com> References: <574C228E.6050108@oracle.com> <2df2a2b0-f903-d0a9-16c9-4be0701fdeb0@oracle.com> <574D5A3A.1010101@oracle.com> Message-ID: <6945f503-10c7-f22c-c2ed-93f8844535b4@oracle.com> 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 vladimir.kozlov at oracle.com Tue May 31 18:17:12 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 31 May 2016 11:17:12 -0700 Subject: RFR(XXS) : 8158185 : jdk/test/lib/FileInstaller throws NPE if dst is in current directory In-Reply-To: References: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> <75237a6f-6688-9a3d-7c39-2debd2850271@oracle.com> Message-ID: Good. Thank you. Vladimir On 5/31/16 6:29 AM, Igor Ignatyev wrote: > Hi Vladimir, > > 1st of all, thank you for reviewing all these changes! > > regarding testing, I run all changed tests locally on mac and run all hotspot/compiler tests remotely on all supported platforms in fastdebug, product variant w/ Xcomp,Xmixed. > this particular fix was tested as a part of JDK-8158184 testing. > > Thanks, > ? Igor >> On May 31, 2016, at 5:14 AM, Vladimir Kozlov wrote: >> >> Looks good. >> >> Igor, how are you testing all these tests fixes? >> >> Thanks, >> Vladimir >> >> On 5/30/16 5:08 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ >>>> 2 lines changed: 0 ins; 0 del; 2 mod; >>> >>> Hi all, >>> >>> could you please review this small changeset which fixes FileInstaller? FileInstaller throws NPE if 2nd argument (dst) is in current directory, this happens because Path::getParent returns null if Path doesn?t have a parent. to prevent this, I added Path::toAbsolutePath call. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8158185 >>> webrev: http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ >>> >>> Thanks, >>> ? Igor >>> > From jesper.wilhelmsson at oracle.com Wed May 25 16:44:36 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 25 May 2016 18:44:36 +0200 Subject: Request for clarification: hs or hs-comp In-Reply-To: <1464194477.3492.9.camel@mylittlepony.linaroharston> References: <1464194477.3492.9.camel@mylittlepony.linaroharston> Message-ID: <14bfc2cb-14be-c180-8094-e21abe3e2527@oracle.com> You can continue to push to hs-comp. Integrations are done between all repos in the same way as before FC. /Jesper Den 25/5/16 kl. 18:41, skrev Edward Nevill: > Hi, > > Could someone please clarify which repo we should be pushing aarch64 compiler specific bug fixes to now that we are post FC. > > Should we continue pushing to hs-comp as before FC, or should we now be pushing to hs? > > Thanks, > Ed. > > From daniel.kallander at oracle.com Mon May 30 11:45:10 2016 From: daniel.kallander at oracle.com (Daniel Kallander) Date: Mon, 30 May 2016 13:45:10 +0200 Subject: Slides for our presentation at the Bucharest Technology Week In-Reply-To: <574C1412.6000002@oracle.com> References: <574BE7DF.8090106@oracle.com> <23072a3d-3f97-6ed5-f3e1-cdc2fe046ca5@oracle.com> <574C1412.6000002@oracle.com> Message-ID: Really nice presentation. Great stuff. cheers, -D > On 30 May 2016, at 12:21, Tobias Hartmann wrote: > > 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 david.therkelsen at oracle.com Mon May 30 13:47:49 2016 From: david.therkelsen at oracle.com (David Therkelsen) Date: Mon, 30 May 2016 09:47:49 -0400 Subject: Slides for our presentation at the Bucharest Technology Week In-Reply-To: <574C1412.6000002@oracle.com> References: <574BE7DF.8090106@oracle.com> <23072a3d-3f97-6ed5-f3e1-cdc2fe046ca5@oracle.com> <574C1412.6000002@oracle.com> Message-ID: <60DD5D37-ED79-4683-8E46-C7346CEC0AA8@oracle.com> Excellent slides. Thanks Tobias and Zoltan for covering this tech event for our org and doing such a great job w/ it. -Dave On May 30, 2016, at 6:21 AM, Tobias Hartmann wrote: > 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 >>>