From jamsheed.c.m at oracle.com Wed Feb 1 05:34:33 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 1 Feb 2017 11:04:33 +0530 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> Message-ID: <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> Hi Vladimir, On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: > On 1/31/17 10:37 AM, Jamsheed C m wrote: >> Hi Vladimir, >> >> ProfileTraps is develop_pd flag, should i be changing flag type ? > > No. Thinking more about this. The code guarded by ProfileTraps should > be only executed when ProfileInterpreter is true. And you set > ProfileInterpreter to false in client mode. Why you need these changes > then? Did you hit some ProfileTraps code which is not guarded by > ProfileInterpreter? with ProfileTraps ON may be the trap count updation in deopt pollute Runtime1::predicate_failed_trap trap count and may influence the recompilation time optimization decision? also create some more mdos(empty ones) in exceptions ? other than that i don't find any issues. just disabling ProfileTraps[1] in deoptimization should solve first problem. second problem of creation of mdos(empty ones) for exception is harmless i believe. [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { >> >> RTM test code doesn't pass VM options to spawned process, So >> predicate checking process and spawned process can be in >> different modes. spawned test process is always in emulated client >> mode in win32. >> >> the predicate checking process will be in emulated client or server >> based on passed -XX:+|-TieredCompilation option. >> as a fix i disabled RTM testing completely in win32. > > I still do not understand why you can't use > Platform.isEmulatedClient() instead of Platform.isWindows() && > Platform.is32bit(). > > And why changes in SupportedOS.java is not enough? Some tests doesn't pass vmoption to child process(cli tests). so same vm tests will be running in different modes ( i.e child will always run in emulated client mode, while predicate checking parent process will run in server or emulated client depending on option passed). so these tests require change if i am changing VM behavior with respect to options. //I would suggest to disable RTM only in client mode. // as per this discussion, i decided to not disable tests or vm behavior, just print some harmless warning in emulated client mode. Best Regards, Jamsheed > >> >> i will disable RTM completely in win32(both emulated client and server). > > I would suggest to disable RTM only in client mode. > > Thanks, > Vladimir > >> >> Best Regards, >> >> Jamsheed >> >> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>> Jamsheed >>> >>> Instead of adding check && !is_client_compilation_mode_vm() I think >>> we should set ProfileTraps to false in client mode. >>> >>> Why you not using Platform.isEmulatedClient() in tests changes? >>> >>> Thanks, >>> Vladimir >>> >>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>> Hi, >>>> >>>> Code change to disable ProfileTrap and UseRTMLocking in Win32 >>>> emulated client . >>>> >>>> 1) ProfileTrap is code is disabled >>>> >>>> 2) -XX:+ UseRTMLocking in win32 emulated client not supported. >>>> >>>> 3) All Supported and Unsupported testcases related RTM is disabled >>>> in win32. >>>> >>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>> >>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>> >>>> Best Regards, >>>> >>>> Jamsheed >>>> >> From tobias.hartmann at oracle.com Wed Feb 1 07:38:56 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 1 Feb 2017 08:38:56 +0100 Subject: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected In-Reply-To: <828151e6-62e5-43dd-91cb-5cf8f73a13d6@default> References: <78660a0f-f5eb-4a84-a78e-b23404bd8173@default> <7b706e31-502e-a840-b3a3-57a4be633328@oracle.com> <828151e6-62e5-43dd-91cb-5cf8f73a13d6@default> Message-ID: <8dcf7880-23bd-e8c7-5fb5-cf4ebf214c59@oracle.com> Hi Rahul, On 31.01.2017 19:55, Rahul Raghavan wrote: > Please see updated - > http://cr.openjdk.java.net/~rraghavan/8144484/webrev.01/ Looks good to me! Best regards, Tobias From rahul.v.raghavan at oracle.com Wed Feb 1 07:49:07 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Tue, 31 Jan 2017 23:49:07 -0800 (PST) Subject: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected In-Reply-To: <8dcf7880-23bd-e8c7-5fb5-cf4ebf214c59@oracle.com> References: <78660a0f-f5eb-4a84-a78e-b23404bd8173@default> <7b706e31-502e-a840-b3a3-57a4be633328@oracle.com> <828151e6-62e5-43dd-91cb-5cf8f73a13d6@default> <8dcf7880-23bd-e8c7-5fb5-cf4ebf214c59@oracle.com> Message-ID: <57d20d68-c3c9-4132-a101-34aaf3bca59f@default> Thank you Tobias. > -----Original Message----- > From: Tobias Hartmann > Sent: Wednesday, February 01, 2017 1:09 PM > To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected > > Hi Rahul, > > On 31.01.2017 19:55, Rahul Raghavan wrote: > > Please see updated - > > http://cr.openjdk.java.net/~rraghavan/8144484/webrev.01/ > > Looks good to me! > > Best regards, > Tobias From vladimir.kozlov at oracle.com Wed Feb 1 08:19:48 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Feb 2017 00:19:48 -0800 Subject: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected In-Reply-To: <8dcf7880-23bd-e8c7-5fb5-cf4ebf214c59@oracle.com> References: <78660a0f-f5eb-4a84-a78e-b23404bd8173@default> <7b706e31-502e-a840-b3a3-57a4be633328@oracle.com> <828151e6-62e5-43dd-91cb-5cf8f73a13d6@default> <8dcf7880-23bd-e8c7-5fb5-cf4ebf214c59@oracle.com> Message-ID: <46c2cd07-19b0-7c21-fc38-c54cdce4d0f7@oracle.com> Sorry, I don't like this fix. Based on your evaluation one control path is dead (top) and it will be optimized out later. It was unfortunate that Phi node was processed first. Change graph (split through MergeMem) is dangerous in this state of graph. I would suggest to bailout early: 1886 if (progress == NULL && can_reshape && type() == Type::MEMORY) { 1887 // see if this phi should be sliced 1888 uint merge_width = 0; 1889 bool saw_self = false; 1890 for( uint i=1; iis_MergeMem()) { 1893 MergeMemNode* n = ii->as_MergeMem(); Thanks, Vladimir On 1/31/17 11:38 PM, Tobias Hartmann wrote: > Hi Rahul, > > On 31.01.2017 19:55, Rahul Raghavan wrote: >> Please see updated - >> http://cr.openjdk.java.net/~rraghavan/8144484/webrev.01/ > > Looks good to me! > > Best regards, > Tobias > From vladimir.kozlov at oracle.com Wed Feb 1 09:02:06 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Feb 2017 01:02:06 -0800 Subject: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected In-Reply-To: <46c2cd07-19b0-7c21-fc38-c54cdce4d0f7@oracle.com> References: <78660a0f-f5eb-4a84-a78e-b23404bd8173@default> <7b706e31-502e-a840-b3a3-57a4be633328@oracle.com> <828151e6-62e5-43dd-91cb-5cf8f73a13d6@default> <8dcf7880-23bd-e8c7-5fb5-cf4ebf214c59@oracle.com> <46c2cd07-19b0-7c21-fc38-c54cdce4d0f7@oracle.com> Message-ID: <71637db5-b9dc-4d28-3e50-67d7af7510b9@oracle.com> On 2/1/17 12:19 AM, Vladimir Kozlov wrote: > Sorry, I don't like this fix. > > Based on your evaluation one control path is dead (top) and it will be optimized out later. It was unfortunate that Phi > node was processed first. Change graph (split through MergeMem) is dangerous in this state of graph. > > I would suggest to bailout early: > > 1886 if (progress == NULL && can_reshape && type() == Type::MEMORY) { > 1887 // see if this phi should be sliced > 1888 uint merge_width = 0; > 1889 bool saw_self = false; > 1890 for( uint i=1; i 1891 Node *ii = in(i); > > + // TOP inputs should not be counted as safe inputs because if the > + // Phi references itself through all other inputs then splitting the > + // Phi through memory merges would create dead loop at later stage. > + if (ii == top) { > + return top; // Delay optimization until graph is cleaned. Sorry, wrong return value. Should be return NULL; > + } > > 1892 if (ii->is_MergeMem()) { > 1893 MergeMemNode* n = ii->as_MergeMem(); > > Thanks, > Vladimir > > On 1/31/17 11:38 PM, Tobias Hartmann wrote: >> Hi Rahul, >> >> On 31.01.2017 19:55, Rahul Raghavan wrote: >>> Please see updated - >>> http://cr.openjdk.java.net/~rraghavan/8144484/webrev.01/ >> >> Looks good to me! >> >> Best regards, >> Tobias >> From doug.simon at oracle.com Wed Feb 1 11:07:21 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 12:07:21 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> Message-ID: <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: http://cr.openjdk.java.net/~dnsimon/8145337/ -Doug > On 30 Jan 2017, at 22:53, Mandy Chung wrote: > >> >> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >> >> >>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>> >>> >>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>> >>>> I?ve extended the webrev with that change - please re-review: >>>> >>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>> >>> >>> +1 >> >> Thanks. Is that a ?Reviewed?? >> > > Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. > > Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. > >> I think I should get at least one sign-off from the security team. >> > > Hope Sean will review this one. Please send an updated webrev. > >> Also, since this is effectively making jdk.vm.compiler an upgradeable module, > > No it does not. > >> what?s the implication for it being a hash-checked module? > > When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module > >> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. > > JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. > > Mandy > >> >> -Doug >> >>> >>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>> >>> >>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>> >>>> BTW, I never answered your question: >>>> >>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>> >>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>> >>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>> >>> Mandy From jamsheed.c.m at oracle.com Wed Feb 1 13:20:48 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 1 Feb 2017 18:50:48 +0530 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> Message-ID: <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> Hi Vladimir, revised webrev : http://cr.openjdk.java.net/~jcm/8173679/webrev.01/ 1) -XX:+UseRTMLocking displays informative warning in emulate client mode. 2) Disabled mdo update code in deopt. Best Regards, Jamsheed On 2/1/2017 11:04 AM, Jamsheed C m wrote: > Hi Vladimir, > > On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: >> On 1/31/17 10:37 AM, Jamsheed C m wrote: >>> Hi Vladimir, >>> >>> ProfileTraps is develop_pd flag, should i be changing flag type ? >> >> No. Thinking more about this. The code guarded by ProfileTraps should >> be only executed when ProfileInterpreter is true. And you set >> ProfileInterpreter to false in client mode. Why you need these >> changes then? Did you hit some ProfileTraps code which is not guarded >> by ProfileInterpreter? > with ProfileTraps ON may be the trap count updation in deopt pollute > Runtime1::predicate_failed_trap trap count and may influence the > recompilation time optimization decision? also create some more > mdos(empty ones) in exceptions ? > other than that i don't find any issues. > > just disabling ProfileTraps[1] in deoptimization should solve first > problem. second problem of creation of mdos(empty ones) for exception > is harmless i believe. > [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { > >>> >>> RTM test code doesn't pass VM options to spawned process, So >>> predicate checking process and spawned process can be in >>> different modes. spawned test process is always in emulated client >>> mode in win32. >>> >>> the predicate checking process will be in emulated client or server >>> based on passed -XX:+|-TieredCompilation option. >>> as a fix i disabled RTM testing completely in win32. >> >> I still do not understand why you can't use >> Platform.isEmulatedClient() instead of Platform.isWindows() && >> Platform.is32bit(). >> >> And why changes in SupportedOS.java is not enough? > Some tests doesn't pass vmoption to child process(cli tests). so same > vm tests will be running in different modes ( i.e child will always > run in emulated client mode, while predicate checking parent process > will run in server or emulated client depending on option passed). so > these tests require change if i am changing VM behavior with respect > to options. > > //I would suggest to disable RTM only in client mode. // > > as per this discussion, i decided to not disable tests or vm behavior, > just print some harmless warning in emulated client mode. > > Best Regards, > Jamsheed > >> >>> >>> i will disable RTM completely in win32(both emulated client and >>> server). >> >> I would suggest to disable RTM only in client mode. >> >> Thanks, >> Vladimir >> >>> >>> Best Regards, >>> >>> Jamsheed >>> >>> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>>> Jamsheed >>>> >>>> Instead of adding check && !is_client_compilation_mode_vm() I think >>>> we should set ProfileTraps to false in client mode. >>>> >>>> Why you not using Platform.isEmulatedClient() in tests changes? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>>> Hi, >>>>> >>>>> Code change to disable ProfileTrap and UseRTMLocking in Win32 >>>>> emulated client . >>>>> >>>>> 1) ProfileTrap is code is disabled >>>>> >>>>> 2) -XX:+ UseRTMLocking in win32 emulated client not supported. >>>>> >>>>> 3) All Supported and Unsupported testcases related RTM is >>>>> disabled in win32. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>>> >>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>>> >>>>> Best Regards, >>>>> >>>>> Jamsheed >>>>> >>> > From vladimir.kozlov at oracle.com Wed Feb 1 16:55:08 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Feb 2017 08:55:08 -0800 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> Message-ID: Sent from my iPhone > On Feb 1, 2017, at 5:20 AM, Jamsheed C m wrote: > > Hi Vladimir, > > revised webrev : http://cr.openjdk.java.net/~jcm/8173679/webrev.01/ > > 1) -XX:+UseRTMLocking displays informative warning in emulate client mode. Warning doesn't switch off RTM. where you are switching it off? Vladimir > > 2) Disabled mdo update code in deopt. > > Best Regards, > > Jamsheed > > >> On 2/1/2017 11:04 AM, Jamsheed C m wrote: >> Hi Vladimir, >> >>> On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: >>>> On 1/31/17 10:37 AM, Jamsheed C m wrote: >>>> Hi Vladimir, >>>> >>>> ProfileTraps is develop_pd flag, should i be changing flag type ? >>> >>> No. Thinking more about this. The code guarded by ProfileTraps should be only executed when ProfileInterpreter is true. And you set ProfileInterpreter to false in client mode. Why you need these changes then? Did you hit some ProfileTraps code which is not guarded by ProfileInterpreter? >> with ProfileTraps ON may be the trap count updation in deopt pollute Runtime1::predicate_failed_trap trap count and may influence the recompilation time optimization decision? also create some more mdos(empty ones) in exceptions ? >> other than that i don't find any issues. >> >> just disabling ProfileTraps[1] in deoptimization should solve first problem. second problem of creation of mdos(empty ones) for exception is harmless i believe. >> [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { >> >>>> >>>> RTM test code doesn't pass VM options to spawned process, So predicate checking process and spawned process can be in >>>> different modes. spawned test process is always in emulated client mode in win32. >>>> >>>> the predicate checking process will be in emulated client or server based on passed -XX:+|-TieredCompilation option. >>>> as a fix i disabled RTM testing completely in win32. >>> >>> I still do not understand why you can't use Platform.isEmulatedClient() instead of Platform.isWindows() && Platform.is32bit(). >>> >>> And why changes in SupportedOS.java is not enough? >> Some tests doesn't pass vmoption to child process(cli tests). so same vm tests will be running in different modes ( i.e child will always run in emulated client mode, while predicate checking parent process will run in server or emulated client depending on option passed). so these tests require change if i am changing VM behavior with respect to options. >> >> //I would suggest to disable RTM only in client mode. // >> >> as per this discussion, i decided to not disable tests or vm behavior, just print some harmless warning in emulated client mode. >> >> Best Regards, >> Jamsheed >> >>> >>>> >>>> i will disable RTM completely in win32(both emulated client and server). >>> >>> I would suggest to disable RTM only in client mode. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Best Regards, >>>> >>>> Jamsheed >>>> >>>>> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>>>> Jamsheed >>>>> >>>>> Instead of adding check && !is_client_compilation_mode_vm() I think we should set ProfileTraps to false in client mode. >>>>> >>>>> Why you not using Platform.isEmulatedClient() in tests changes? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>>>> Hi, >>>>>> >>>>>> Code change to disable ProfileTrap and UseRTMLocking in Win32 emulated client . >>>>>> >>>>>> 1) ProfileTrap is code is disabled >>>>>> >>>>>> 2) -XX:+ UseRTMLocking in win32 emulated client not supported. >>>>>> >>>>>> 3) All Supported and Unsupported testcases related RTM is disabled in win32. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>>>> >>>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Jamsheed >>>>>> >>>> >> > From jamsheed.c.m at oracle.com Wed Feb 1 17:07:13 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 1 Feb 2017 22:37:13 +0530 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> Message-ID: <6c221440-13f9-7f88-8d6d-ea037c218da1@oracle.com> Hi Vladimir, On 2/1/2017 10:25 PM, Vladimir Kozlov wrote: > > Sent from my iPhone > >> On Feb 1, 2017, at 5:20 AM, Jamsheed C m wrote: >> >> Hi Vladimir, >> >> revised webrev : http://cr.openjdk.java.net/~jcm/8173679/webrev.01/ >> >> 1) -XX:+UseRTMLocking displays informative warning in emulate client mode. > Warning doesn't switch off RTM. > where you are switching it off? i am not switching it off, i am just printing warning, User should explicitly remove option. Best Regards, Jamsheed > > Vladimir > >> 2) Disabled mdo update code in deopt. >> >> Best Regards, >> >> Jamsheed >> >> >>> On 2/1/2017 11:04 AM, Jamsheed C m wrote: >>> Hi Vladimir, >>> >>>> On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: >>>>> On 1/31/17 10:37 AM, Jamsheed C m wrote: >>>>> Hi Vladimir, >>>>> >>>>> ProfileTraps is develop_pd flag, should i be changing flag type ? >>>> No. Thinking more about this. The code guarded by ProfileTraps should be only executed when ProfileInterpreter is true. And you set ProfileInterpreter to false in client mode. Why you need these changes then? Did you hit some ProfileTraps code which is not guarded by ProfileInterpreter? >>> with ProfileTraps ON may be the trap count updation in deopt pollute Runtime1::predicate_failed_trap trap count and may influence the recompilation time optimization decision? also create some more mdos(empty ones) in exceptions ? >>> other than that i don't find any issues. >>> >>> just disabling ProfileTraps[1] in deoptimization should solve first problem. second problem of creation of mdos(empty ones) for exception is harmless i believe. >>> [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { >>> >>>>> RTM test code doesn't pass VM options to spawned process, So predicate checking process and spawned process can be in >>>>> different modes. spawned test process is always in emulated client mode in win32. >>>>> >>>>> the predicate checking process will be in emulated client or server based on passed -XX:+|-TieredCompilation option. >>>>> as a fix i disabled RTM testing completely in win32. >>>> I still do not understand why you can't use Platform.isEmulatedClient() instead of Platform.isWindows() && Platform.is32bit(). >>>> >>>> And why changes in SupportedOS.java is not enough? >>> Some tests doesn't pass vmoption to child process(cli tests). so same vm tests will be running in different modes ( i.e child will always run in emulated client mode, while predicate checking parent process will run in server or emulated client depending on option passed). so these tests require change if i am changing VM behavior with respect to options. >>> >>> //I would suggest to disable RTM only in client mode. // >>> >>> as per this discussion, i decided to not disable tests or vm behavior, just print some harmless warning in emulated client mode. >>> >>> Best Regards, >>> Jamsheed >>> >>>>> i will disable RTM completely in win32(both emulated client and server). >>>> I would suggest to disable RTM only in client mode. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> Best Regards, >>>>> >>>>> Jamsheed >>>>> >>>>>> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>>>>> Jamsheed >>>>>> >>>>>> Instead of adding check && !is_client_compilation_mode_vm() I think we should set ProfileTraps to false in client mode. >>>>>> >>>>>> Why you not using Platform.isEmulatedClient() in tests changes? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Code change to disable ProfileTrap and UseRTMLocking in Win32 emulated client . >>>>>>> >>>>>>> 1) ProfileTrap is code is disabled >>>>>>> >>>>>>> 2) -XX:+ UseRTMLocking in win32 emulated client not supported. >>>>>>> >>>>>>> 3) All Supported and Unsupported testcases related RTM is disabled in win32. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>>>>> >>>>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Jamsheed >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Wed Feb 1 20:03:50 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 21:03:50 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> Message-ID: <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> > On 1 Feb 2017, at 20:54, Sean Mullan wrote: > > Couple of comments: > > - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. Thanks - I removed it. > - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file? -Doug > On 2/1/17 6:07 AM, Doug Simon wrote: >> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >> >> http://cr.openjdk.java.net/~dnsimon/8145337/ >> >> -Doug >> >>> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >>> >>>> >>>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>>> >>>> >>>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>>> >>>>> >>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>>> >>>>>> I?ve extended the webrev with that change - please re-review: >>>>>> >>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>>> >>>>> >>>>> +1 >>>> >>>> Thanks. Is that a ?Reviewed?? >>>> >>> >>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >>> >>> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >>> >>>> I think I should get at least one sign-off from the security team. >>>> >>> >>> Hope Sean will review this one. Please send an updated webrev. >>> >>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >>> >>> No it does not. >>> >>>> what?s the implication for it being a hash-checked module? >>> >>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >>> >>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >>> >>> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >>> >>> Mandy >>> >>>> >>>> -Doug >>>> >>>>> >>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>>> >>>>> >>>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>>> >>>>>> BTW, I never answered your question: >>>>>> >>>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>>> >>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>>> >>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>>> >>>>> Mandy >> From vladimir.kozlov at oracle.com Wed Feb 1 21:19:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Feb 2017 13:19:50 -0800 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> Message-ID: <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> AOT tool jaotc does not run with SecurityManager. We assume it runs in secure environment and it does not access any external resources. Thanks Vladimir > On Feb 1, 2017, at 12:03 PM, Doug Simon wrote: > > >> On 1 Feb 2017, at 20:54, Sean Mullan wrote: >> >> Couple of comments: >> >> - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. > > Thanks - I removed it. > >> - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. > > Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file? > > -Doug > >>> On 2/1/17 6:07 AM, Doug Simon wrote: >>> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >>> >>> http://cr.openjdk.java.net/~dnsimon/8145337/ >>> >>> -Doug >>> >>>>> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >>>>> >>>>> >>>>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>>>> >>>>> >>>>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>>>> >>>>>> >>>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>>>> >>>>>>> I?ve extended the webrev with that change - please re-review: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>>>> >>>>>> >>>>>> +1 >>>>> >>>>> Thanks. Is that a ?Reviewed?? >>>>> >>>> >>>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >>>> >>>> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >>>> >>>>> I think I should get at least one sign-off from the security team. >>>>> >>>> >>>> Hope Sean will review this one. Please send an updated webrev. >>>> >>>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >>>> >>>> No it does not. >>>> >>>>> what?s the implication for it being a hash-checked module? >>>> >>>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >>>> >>>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >>>> >>>> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >>>> >>>> Mandy >>>> >>>>> >>>>> -Doug >>>>> >>>>>> >>>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>>>> >>>>>> >>>>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>>>> >>>>>>> BTW, I never answered your question: >>>>>>> >>>>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>>>> >>>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>>>> >>>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>>>> >>>>>> Mandy >>> > From doug.simon at oracle.com Wed Feb 1 21:27:47 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 22:27:47 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> Message-ID: > On 1 Feb 2017, at 22:19, Vladimir Kozlov wrote: > > AOT tool jaotc does not run with SecurityManager. We assume it runs in secure environment and it does not access any external resources. Great. Can I now consider this change reviewed and integrate it? -Doug >> On Feb 1, 2017, at 12:03 PM, Doug Simon wrote: >> >> >>> On 1 Feb 2017, at 20:54, Sean Mullan wrote: >>> >>> Couple of comments: >>> >>> - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. >> >> Thanks - I removed it. >> >>> - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. >> >> Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file? >> >> -Doug >> >>>> On 2/1/17 6:07 AM, Doug Simon wrote: >>>> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >>>> >>>> http://cr.openjdk.java.net/~dnsimon/8145337/ >>>> >>>> -Doug >>>> >>>>>> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >>>>>> >>>>>> >>>>>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>>>>> >>>>>> >>>>>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>>>>> >>>>>>> >>>>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>>>>> >>>>>>>> I?ve extended the webrev with that change - please re-review: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>>>>> >>>>>>> >>>>>>> +1 >>>>>> >>>>>> Thanks. Is that a ?Reviewed?? >>>>>> >>>>> >>>>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >>>>> >>>>> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >>>>> >>>>>> I think I should get at least one sign-off from the security team. >>>>>> >>>>> >>>>> Hope Sean will review this one. Please send an updated webrev. >>>>> >>>>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >>>>> >>>>> No it does not. >>>>> >>>>>> what?s the implication for it being a hash-checked module? >>>>> >>>>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >>>>> >>>>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >>>>> >>>>> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >>>>> >>>>> Mandy >>>>> >>>>>> >>>>>> -Doug >>>>>> >>>>>>> >>>>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>>>>> >>>>>>> >>>>>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>>>>> >>>>>>>> BTW, I never answered your question: >>>>>>>> >>>>>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>>>>> >>>>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>>>>> >>>>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>>>>> >>>>>>> Mandy >>>> >> > From Oleg.Pliss at Oracle.com Wed Feb 1 06:17:31 2017 From: Oleg.Pliss at Oracle.com (Oleg Pliss) Date: Tue, 31 Jan 2017 22:17:31 -0800 Subject: RFR: Fix for JDK-8173119, compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java fails with custom Tiered Level set externally Message-ID: http://cr.openjdk.java.net/~kvn/8173119/webrev/ From sean.mullan at oracle.com Wed Feb 1 19:54:43 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 1 Feb 2017 14:54:43 -0500 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> Message-ID: Couple of comments: - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. --Sean On 2/1/17 6:07 AM, Doug Simon wrote: > I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: > > http://cr.openjdk.java.net/~dnsimon/8145337/ > > -Doug > >> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >> >>> >>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>> >>> >>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>> >>>> >>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>> >>>>> I?ve extended the webrev with that change - please re-review: >>>>> >>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>> >>>> >>>> +1 >>> >>> Thanks. Is that a ?Reviewed?? >>> >> >> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >> >> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >> >>> I think I should get at least one sign-off from the security team. >>> >> >> Hope Sean will review this one. Please send an updated webrev. >> >>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >> >> No it does not. >> >>> what?s the implication for it being a hash-checked module? >> >> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >> >>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >> >> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >> >> Mandy >> >>> >>> -Doug >>> >>>> >>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>> >>>> >>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>> >>>>> BTW, I never answered your question: >>>>> >>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>> >>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>> >>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>> >>>> Mandy > From sean.mullan at oracle.com Wed Feb 1 22:17:07 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 1 Feb 2017 17:17:07 -0500 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> Message-ID: <317ffefa-5535-0a0c-0ad7-7e61260b26d0@oracle.com> On 2/1/17 4:27 PM, Doug Simon wrote: > Can I now consider this change reviewed and integrate it? Yes. --Sean From vladimir.kozlov at oracle.com Thu Feb 2 01:37:20 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Feb 2017 17:37:20 -0800 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: <6c221440-13f9-7f88-8d6d-ea037c218da1@oracle.com> References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> <6c221440-13f9-7f88-8d6d-ea037c218da1@oracle.com> Message-ID: On 2/1/17 9:07 AM, Jamsheed C m wrote: > Hi Vladimir, > > > On 2/1/2017 10:25 PM, Vladimir Kozlov wrote: >> >> Sent from my iPhone >> >>> On Feb 1, 2017, at 5:20 AM, Jamsheed C m wrote: >>> >>> Hi Vladimir, >>> >>> revised webrev : http://cr.openjdk.java.net/~jcm/8173679/webrev.01/ >>> >>> 1) -XX:+UseRTMLocking displays informative warning in emulate client mode. >> Warning doesn't switch off RTM. >> where you are switching it off? > i am not switching it off, i am just printing warning, User should explicitly remove option. Then it should be not warning but error. We can't run in Client mode with RTM on. Or I am missing something? Thanks, Vladimir > > Best Regards, Jamsheed > >> >> Vladimir >> >>> 2) Disabled mdo update code in deopt. >>> >>> Best Regards, >>> >>> Jamsheed >>> >>> >>>> On 2/1/2017 11:04 AM, Jamsheed C m wrote: >>>> Hi Vladimir, >>>> >>>>> On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: >>>>>> On 1/31/17 10:37 AM, Jamsheed C m wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> ProfileTraps is develop_pd flag, should i be changing flag type ? >>>>> No. Thinking more about this. The code guarded by ProfileTraps should be only executed when ProfileInterpreter is true. And you set ProfileInterpreter to false in client mode. Why you need these changes then? Did you hit some ProfileTraps code which is not guarded by ProfileInterpreter? >>>> with ProfileTraps ON may be the trap count updation in deopt pollute Runtime1::predicate_failed_trap trap count and may influence the recompilation time optimization decision? also create some more mdos(empty ones) in exceptions ? >>>> other than that i don't find any issues. >>>> >>>> just disabling ProfileTraps[1] in deoptimization should solve first problem. second problem of creation of mdos(empty ones) for exception is harmless i believe. >>>> [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { >>>> >>>>>> RTM test code doesn't pass VM options to spawned process, So predicate checking process and spawned process can be in >>>>>> different modes. spawned test process is always in emulated client mode in win32. >>>>>> >>>>>> the predicate checking process will be in emulated client or server based on passed -XX:+|-TieredCompilation option. >>>>>> as a fix i disabled RTM testing completely in win32. >>>>> I still do not understand why you can't use Platform.isEmulatedClient() instead of Platform.isWindows() && Platform.is32bit(). >>>>> >>>>> And why changes in SupportedOS.java is not enough? >>>> Some tests doesn't pass vmoption to child process(cli tests). so same vm tests will be running in different modes ( i.e child will always run in emulated client mode, while predicate checking parent process will run in server or emulated client depending on option passed). so these tests require change if i am changing VM behavior with respect to options. >>>> >>>> //I would suggest to disable RTM only in client mode. // >>>> >>>> as per this discussion, i decided to not disable tests or vm behavior, just print some harmless warning in emulated client mode. >>>> >>>> Best Regards, >>>> Jamsheed >>>> >>>>>> i will disable RTM completely in win32(both emulated client and server). >>>>> I would suggest to disable RTM only in client mode. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> Best Regards, >>>>>> >>>>>> Jamsheed >>>>>> >>>>>>> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>>>>>> Jamsheed >>>>>>> >>>>>>> Instead of adding check && !is_client_compilation_mode_vm() I think we should set ProfileTraps to false in client mode. >>>>>>> >>>>>>> Why you not using Platform.isEmulatedClient() in tests changes? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Code change to disable ProfileTrap and UseRTMLocking in Win32 emulated client . >>>>>>>> >>>>>>>> 1) ProfileTrap is code is disabled >>>>>>>> >>>>>>>> 2) -XX:+ UseRTMLocking in win32 emulated client not supported. >>>>>>>> >>>>>>>> 3) All Supported and Unsupported testcases related RTM is disabled in win32. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>>>>>> >>>>>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Jamsheed >>>>>>>> > From mandy.chung at oracle.com Thu Feb 2 02:12:26 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Feb 2017 18:12:26 -0800 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89! A429E0AE00@oracle.com> Message-ID: <970E0BAE-2DFA-4B30-8B4B-A730391308D5@oracle.com> > On Feb 1, 2017, at 3:07 AM, Doug Simon wrote: > > I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: > > http://cr.openjdk.java.net/~dnsimon/8145337/ Looks good. Mandy From jamsheed.c.m at oracle.com Thu Feb 2 02:19:55 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 2 Feb 2017 07:49:55 +0530 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> <6c221440-13f9-7f88-8d6d-ea037c218da1@oracle.com> Message-ID: Hi Vladimir, On 2/2/2017 7:07 AM, Vladimir Kozlov wrote: > On 2/1/17 9:07 AM, Jamsheed C m wrote: >> Hi Vladimir, >> >> >> On 2/1/2017 10:25 PM, Vladimir Kozlov wrote: >>> >>> Sent from my iPhone >>> >>>> On Feb 1, 2017, at 5:20 AM, Jamsheed C m >>>> wrote: >>>> >>>> Hi Vladimir, >>>> >>>> revised webrev : http://cr.openjdk.java.net/~jcm/8173679/webrev.01/ >>>> >>>> 1) -XX:+UseRTMLocking displays informative warning in emulate >>>> client mode. >>> Warning doesn't switch off RTM. >>> where you are switching it off? >> i am not switching it off, i am just printing warning, User should >> explicitly remove option. > > Then it should be not warning but error. We can't run in Client mode > with RTM on. Or I am missing something? RTM "ON" state is always user specified action. RTM is default OFF. from the code it says it disables BiasedLocking when RTM is ON and exit in client(lose both rtm + biased locking feature with -XX:+UseRTMLocking), i made it warning for emulated client. as it is User specified action, User can see warning that Biased lock get switched off with an unsupported option, and remove it from his commandline. Best Regards, Jamsheed > > Thanks, > Vladimir > >> >> Best Regards, Jamsheed >> >>> >>> Vladimir >>> >>>> 2) Disabled mdo update code in deopt. >>>> >>>> Best Regards, >>>> >>>> Jamsheed >>>> >>>> >>>>> On 2/1/2017 11:04 AM, Jamsheed C m wrote: >>>>> Hi Vladimir, >>>>> >>>>>> On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: >>>>>>> On 1/31/17 10:37 AM, Jamsheed C m wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> ProfileTraps is develop_pd flag, should i be changing flag type ? >>>>>> No. Thinking more about this. The code guarded by ProfileTraps >>>>>> should be only executed when ProfileInterpreter is true. And you >>>>>> set ProfileInterpreter to false in client mode. Why you need >>>>>> these changes then? Did you hit some ProfileTraps code which is >>>>>> not guarded by ProfileInterpreter? >>>>> with ProfileTraps ON may be the trap count updation in deopt >>>>> pollute Runtime1::predicate_failed_trap trap count and may >>>>> influence the recompilation time optimization decision? also >>>>> create some more mdos(empty ones) in exceptions ? >>>>> other than that i don't find any issues. >>>>> >>>>> just disabling ProfileTraps[1] in deoptimization should solve >>>>> first problem. second problem of creation of mdos(empty ones) for >>>>> exception is harmless i believe. >>>>> [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { >>>>> >>>>>>> RTM test code doesn't pass VM options to spawned process, So >>>>>>> predicate checking process and spawned process can be in >>>>>>> different modes. spawned test process is always in emulated >>>>>>> client mode in win32. >>>>>>> >>>>>>> the predicate checking process will be in emulated client or >>>>>>> server based on passed -XX:+|-TieredCompilation option. >>>>>>> as a fix i disabled RTM testing completely in win32. >>>>>> I still do not understand why you can't use >>>>>> Platform.isEmulatedClient() instead of Platform.isWindows() && >>>>>> Platform.is32bit(). >>>>>> >>>>>> And why changes in SupportedOS.java is not enough? >>>>> Some tests doesn't pass vmoption to child process(cli tests). so >>>>> same vm tests will be running in different modes ( i.e child will >>>>> always run in emulated client mode, while predicate checking >>>>> parent process will run in server or emulated client depending on >>>>> option passed). so these tests require change if i am changing VM >>>>> behavior with respect to options. >>>>> >>>>> //I would suggest to disable RTM only in client mode. // >>>>> >>>>> as per this discussion, i decided to not disable tests or vm >>>>> behavior, just print some harmless warning in emulated client mode. >>>>> >>>>> Best Regards, >>>>> Jamsheed >>>>> >>>>>>> i will disable RTM completely in win32(both emulated client and >>>>>>> server). >>>>>> I would suggest to disable RTM only in client mode. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Jamsheed >>>>>>> >>>>>>>> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>>>>>>> Jamsheed >>>>>>>> >>>>>>>> Instead of adding check && !is_client_compilation_mode_vm() I >>>>>>>> think we should set ProfileTraps to false in client mode. >>>>>>>> >>>>>>>> Why you not using Platform.isEmulatedClient() in tests changes? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Code change to disable ProfileTrap and UseRTMLocking in Win32 >>>>>>>>> emulated client . >>>>>>>>> >>>>>>>>> 1) ProfileTrap is code is disabled >>>>>>>>> >>>>>>>>> 2) -XX:+ UseRTMLocking in win32 emulated client not supported. >>>>>>>>> >>>>>>>>> 3) All Supported and Unsupported testcases related RTM is >>>>>>>>> disabled in win32. >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>>>>>>> >>>>>>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Jamsheed >>>>>>>>> >> From vladimir.kozlov at oracle.com Thu Feb 2 03:50:03 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Feb 2017 19:50:03 -0800 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> <6c221440-13f9-7f88-8d6d-ea037c218da1@oracle.com> Message-ID: <8bc609d5-cfe2-035d-b530-16ea20783a10@oracle.com> On 2/1/17 6:19 PM, Jamsheed C m wrote: > Hi Vladimir, > > On 2/2/2017 7:07 AM, Vladimir Kozlov wrote: >> On 2/1/17 9:07 AM, Jamsheed C m wrote: >>> Hi Vladimir, >>> >>> >>> On 2/1/2017 10:25 PM, Vladimir Kozlov wrote: >>>> >>>> Sent from my iPhone >>>> >>>>> On Feb 1, 2017, at 5:20 AM, Jamsheed C m wrote: >>>>> >>>>> Hi Vladimir, >>>>> >>>>> revised webrev : http://cr.openjdk.java.net/~jcm/8173679/webrev.01/ >>>>> >>>>> 1) -XX:+UseRTMLocking displays informative warning in emulate client mode. >>>> Warning doesn't switch off RTM. >>>> where you are switching it off? >>> i am not switching it off, i am just printing warning, User should explicitly remove option. >> >> Then it should be not warning but error. We can't run in Client mode with RTM on. Or I am missing something? > RTM "ON" state is always user specified action. RTM is default OFF. from the code it says it disables BiasedLocking when > RTM is ON and exit in client(lose both rtm + biased locking feature with -XX:+UseRTMLocking), i made it warning for Where it exits? It does not in VM_Version::use_biased_locking(). > emulated client. as it is User specified action, User can see warning that Biased lock get switched off with an > unsupported option, and remove it from his commandline. No, you have to explicitly call vm_exit_during_initialization() as it was done in preceding code (!supports_rtm() && UseRTMLocking). Note, users may ignores warnings because usually output is stored in log files. thanks, Vladimir > Best Regards, > Jamsheed >> >> Thanks, >> Vladimir >> >>> >>> Best Regards, Jamsheed >>> >>>> >>>> Vladimir >>>> >>>>> 2) Disabled mdo update code in deopt. >>>>> >>>>> Best Regards, >>>>> >>>>> Jamsheed >>>>> >>>>> >>>>>> On 2/1/2017 11:04 AM, Jamsheed C m wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>>> On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: >>>>>>>> On 1/31/17 10:37 AM, Jamsheed C m wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> ProfileTraps is develop_pd flag, should i be changing flag type ? >>>>>>> No. Thinking more about this. The code guarded by ProfileTraps should be only executed when ProfileInterpreter is >>>>>>> true. And you set ProfileInterpreter to false in client mode. Why you need these changes then? Did you hit some >>>>>>> ProfileTraps code which is not guarded by ProfileInterpreter? >>>>>> with ProfileTraps ON may be the trap count updation in deopt pollute Runtime1::predicate_failed_trap trap count >>>>>> and may influence the recompilation time optimization decision? also create some more mdos(empty ones) in >>>>>> exceptions ? >>>>>> other than that i don't find any issues. >>>>>> >>>>>> just disabling ProfileTraps[1] in deoptimization should solve first problem. second problem of creation of >>>>>> mdos(empty ones) for exception is harmless i believe. >>>>>> [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { >>>>>> >>>>>>>> RTM test code doesn't pass VM options to spawned process, So predicate checking process and spawned process >>>>>>>> can be in >>>>>>>> different modes. spawned test process is always in emulated client mode in win32. >>>>>>>> >>>>>>>> the predicate checking process will be in emulated client or server based on passed -XX:+|-TieredCompilation >>>>>>>> option. >>>>>>>> as a fix i disabled RTM testing completely in win32. >>>>>>> I still do not understand why you can't use Platform.isEmulatedClient() instead of Platform.isWindows() && >>>>>>> Platform.is32bit(). >>>>>>> >>>>>>> And why changes in SupportedOS.java is not enough? >>>>>> Some tests doesn't pass vmoption to child process(cli tests). so same vm tests will be running in different modes >>>>>> ( i.e child will always run in emulated client mode, while predicate checking parent process will run in server or >>>>>> emulated client depending on option passed). so these tests require change if i am changing VM behavior with >>>>>> respect to options. >>>>>> >>>>>> //I would suggest to disable RTM only in client mode. // >>>>>> >>>>>> as per this discussion, i decided to not disable tests or vm behavior, just print some harmless warning in >>>>>> emulated client mode. >>>>>> >>>>>> Best Regards, >>>>>> Jamsheed >>>>>> >>>>>>>> i will disable RTM completely in win32(both emulated client and server). >>>>>>> I would suggest to disable RTM only in client mode. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Jamsheed >>>>>>>> >>>>>>>>> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>>>>>>>> Jamsheed >>>>>>>>> >>>>>>>>> Instead of adding check && !is_client_compilation_mode_vm() I think we should set ProfileTraps to false in >>>>>>>>> client mode. >>>>>>>>> >>>>>>>>> Why you not using Platform.isEmulatedClient() in tests changes? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Code change to disable ProfileTrap and UseRTMLocking in Win32 emulated client . >>>>>>>>>> >>>>>>>>>> 1) ProfileTrap is code is disabled >>>>>>>>>> >>>>>>>>>> 2) -XX:+ UseRTMLocking in win32 emulated client not supported. >>>>>>>>>> >>>>>>>>>> 3) All Supported and Unsupported testcases related RTM is disabled in win32. >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>>>>>>>> >>>>>>>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> >>>>>>>>>> Jamsheed >>>>>>>>>> >>> > From jamsheed.c.m at oracle.com Thu Feb 2 05:29:30 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 2 Feb 2017 10:59:30 +0530 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: <8bc609d5-cfe2-035d-b530-16ea20783a10@oracle.com> References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> <6c221440-13f9-7f88-8d6d-ea037c218da1@oracle.com> <8bc609d5-cfe2-035d-b530-16ea20783a10@oracle.com> Message-ID: Hi Vladimir, On 2/2/2017 9:20 AM, Vladimir Kozlov wrote: > > > On 2/1/17 6:19 PM, Jamsheed C m wrote: >> Hi Vladimir, >> >> On 2/2/2017 7:07 AM, Vladimir Kozlov wrote: >>> On 2/1/17 9:07 AM, Jamsheed C m wrote: >>>> Hi Vladimir, >>>> >>>> >>>> On 2/1/2017 10:25 PM, Vladimir Kozlov wrote: >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Feb 1, 2017, at 5:20 AM, Jamsheed C m >>>>>> wrote: >>>>>> >>>>>> Hi Vladimir, >>>>>> >>>>>> revised webrev : http://cr.openjdk.java.net/~jcm/8173679/webrev.01/ >>>>>> >>>>>> 1) -XX:+UseRTMLocking displays informative warning in emulate >>>>>> client mode. >>>>> Warning doesn't switch off RTM. >>>>> where you are switching it off? >>>> i am not switching it off, i am just printing warning, User should >>>> explicitly remove option. >>> >>> Then it should be not warning but error. We can't run in Client mode >>> with RTM on. Or I am missing something? >> RTM "ON" state is always user specified action. RTM is default OFF. >> from the code it says it disables BiasedLocking when >> RTM is ON and exit in client(lose both rtm + biased locking feature >> with -XX:+UseRTMLocking), i made it warning for > > Where it exits? It does not in VM_Version::use_biased_locking(). i meant normal client exits. emulated client prints warning only, it doesn't exit or change flags. > >> emulated client. as it is User specified action, User can see warning >> that Biased lock get switched off with an >> unsupported option, and remove it from his commandline. > > No, you have to explicitly call vm_exit_during_initialization() as it > was done in preceding code (!supports_rtm() && UseRTMLocking). Note, > users may ignores warnings because usually output is stored in log files. Sure, i will do required code change , and send it for review. Best Regards, Jamsheed > > thanks, > Vladimir > >> Best Regards, >> Jamsheed >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Best Regards, Jamsheed >>>> >>>>> >>>>> Vladimir >>>>> >>>>>> 2) Disabled mdo update code in deopt. >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Jamsheed >>>>>> >>>>>> >>>>>>> On 2/1/2017 11:04 AM, Jamsheed C m wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>>> On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: >>>>>>>>> On 1/31/17 10:37 AM, Jamsheed C m wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> ProfileTraps is develop_pd flag, should i be changing flag type ? >>>>>>>> No. Thinking more about this. The code guarded by ProfileTraps >>>>>>>> should be only executed when ProfileInterpreter is >>>>>>>> true. And you set ProfileInterpreter to false in client mode. >>>>>>>> Why you need these changes then? Did you hit some >>>>>>>> ProfileTraps code which is not guarded by ProfileInterpreter? >>>>>>> with ProfileTraps ON may be the trap count updation in deopt >>>>>>> pollute Runtime1::predicate_failed_trap trap count >>>>>>> and may influence the recompilation time optimization decision? >>>>>>> also create some more mdos(empty ones) in >>>>>>> exceptions ? >>>>>>> other than that i don't find any issues. >>>>>>> >>>>>>> just disabling ProfileTraps[1] in deoptimization should solve >>>>>>> first problem. second problem of creation of >>>>>>> mdos(empty ones) for exception is harmless i believe. >>>>>>> [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { >>>>>>> >>>>>>>>> RTM test code doesn't pass VM options to spawned process, So >>>>>>>>> predicate checking process and spawned process >>>>>>>>> can be in >>>>>>>>> different modes. spawned test process is always in emulated >>>>>>>>> client mode in win32. >>>>>>>>> >>>>>>>>> the predicate checking process will be in emulated client or >>>>>>>>> server based on passed -XX:+|-TieredCompilation >>>>>>>>> option. >>>>>>>>> as a fix i disabled RTM testing completely in win32. >>>>>>>> I still do not understand why you can't use >>>>>>>> Platform.isEmulatedClient() instead of Platform.isWindows() && >>>>>>>> Platform.is32bit(). >>>>>>>> >>>>>>>> And why changes in SupportedOS.java is not enough? >>>>>>> Some tests doesn't pass vmoption to child process(cli tests). so >>>>>>> same vm tests will be running in different modes >>>>>>> ( i.e child will always run in emulated client mode, while >>>>>>> predicate checking parent process will run in server or >>>>>>> emulated client depending on option passed). so these tests >>>>>>> require change if i am changing VM behavior with >>>>>>> respect to options. >>>>>>> >>>>>>> //I would suggest to disable RTM only in client mode. // >>>>>>> >>>>>>> as per this discussion, i decided to not disable tests or vm >>>>>>> behavior, just print some harmless warning in >>>>>>> emulated client mode. >>>>>>> >>>>>>> Best Regards, >>>>>>> Jamsheed >>>>>>> >>>>>>>>> i will disable RTM completely in win32(both emulated client >>>>>>>>> and server). >>>>>>>> I would suggest to disable RTM only in client mode. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Jamsheed >>>>>>>>> >>>>>>>>>> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>>>>>>>>> Jamsheed >>>>>>>>>> >>>>>>>>>> Instead of adding check && !is_client_compilation_mode_vm() I >>>>>>>>>> think we should set ProfileTraps to false in >>>>>>>>>> client mode. >>>>>>>>>> >>>>>>>>>> Why you not using Platform.isEmulatedClient() in tests changes? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Code change to disable ProfileTrap and UseRTMLocking in >>>>>>>>>>> Win32 emulated client . >>>>>>>>>>> >>>>>>>>>>> 1) ProfileTrap is code is disabled >>>>>>>>>>> >>>>>>>>>>> 2) -XX:+ UseRTMLocking in win32 emulated client not supported. >>>>>>>>>>> >>>>>>>>>>> 3) All Supported and Unsupported testcases related RTM is >>>>>>>>>>> disabled in win32. >>>>>>>>>>> >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> >>>>>>>>>>> Jamsheed >>>>>>>>>>> >>>> >> From tobias.hartmann at oracle.com Thu Feb 2 07:28:30 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 2 Feb 2017 08:28:30 +0100 Subject: RFR: Fix for JDK-8173119, compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java fails with custom Tiered Level set externally In-Reply-To: References: Message-ID: Hi Oleg, when sending changes for review, please make sure that you add a comment briefly explaining the problem, your fix and what kind of testing you did. You can also use an email subject line in the form of "[JDK_VERSION] RFR(FIX_SIZE): BUGID: TITLE" to make it easier for reviewers to understand the get an overview. For example, "[9] RFR(S): 8173119: compiler/jvmci/events/[...]". On 01.02.2017 07:17, Oleg Pliss wrote: > http://cr.openjdk.java.net/~kvn/8173119/webrev/ Your changes look good to me. Please run RBT testing (I added a comment to the bug). Best regards, Tobias From Alan.Bateman at oracle.com Thu Feb 2 08:09:11 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Feb 2017 08:09:11 +0000 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <970E0BAE-2DFA-4B30-8B4B-A730391308D5@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89! A429E0AE00@oracle.com> <970E0BAE-2DFA-4B30-8B4B-A730391308D5@oracle.com> Message-ID: <913dc879-1b70-8530-7992-f06bc8674237@oracle.com> On 02/02/2017 02:12, Mandy Chung wrote: >> On Feb 1, 2017, at 3:07 AM, Doug Simon wrote: >> >> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >> >> http://cr.openjdk.java.net/~dnsimon/8145337/ > Looks good. > Looks okay to me too. -Alan. From tobias.hartmann at oracle.com Thu Feb 2 13:04:58 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 2 Feb 2017 14:04:58 +0100 Subject: [9] RFR(S): 8173699: Crash during deoptimization with "assert(result == __null || result->is_oop()) failed: must be oop" Message-ID: Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8173699 http://cr.openjdk.java.net/~thartmann/8173699/webrev.00/ The Graal compiled method java.lang.invoke.MemberName$Factory::resolve() calls into the method handle runtime via MethodHandleNatives::resolve() which throws a NoSuchMethodError because method resolution failed (see methodHandles.cpp, line 1234). We then call into JVMCIRuntime::exception_handler_for_pc() -> SharedRuntime::compute_compiled_exc_handler() to determine the appropriate exception handler. Because the ExceptionHandlerTable has no entry for this pc, we deoptimize and return to the DeoptimizationBlob at offset _unpack_with_exception_in_tls which calls Deoptimization::fetch_unroll_info(). Since the callee returns a MemberName object, the ScopeDesc is marked as return_oop() and the re-allocation code expects the return register (eax) to contain the oop of this returned object. We fail when trying to save the oop, because eax contains not an oop but the address of SharedRuntime::deopt_blob()->unpack_with_exception_in_tls() which was returned from JVMCIRuntime::exception_handler_for_pc() right before and is therefore still in eax. As Tom suggested in the bug comments, we should ignore the return_oop() when dispatching an exception and only try to retrieve the oop when performing re-allocation during a normal deoptimization (if exec_mode == Unpack_deopt). This code should be refactored with JDK 10. I filed JDK-8173823. This problem only affects JVMCI compiled code. C1 does not set return_oop() because it does not eliminate allocations (see IRScopeDebugInfo::record_debug_info()) and therefore does not need to re-allocate objects on deoptimization. C2 computes the exception handler via OptoRuntime::handle_exception_C() and uses DeoptimizationBlob::_unpack_with_exception as handler in case the nmethod was deoptimized. When calling Deoptimization::fetch_unroll_info() from the DeoptimizationBlob, eax still contains the exception oop and therefore the code works "by accident" because the exception oop is treated as returned oop. Tested with JVMCI test and RBT (running). Thanks to Tom and Dean for the help! Thanks, Tobias From vladimir.x.ivanov at oracle.com Thu Feb 2 13:06:09 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 2 Feb 2017 16:06:09 +0300 Subject: [9] RFR(S): 8173699: Crash during deoptimization with "assert(result == __null || result->is_oop()) failed: must be oop" In-Reply-To: References: Message-ID: <48238f65-4e00-3309-579a-be9ce3f2929c@oracle.com> Looks good. Best regards, Vladimir Ivanov On 2/2/17 4:04 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8173699 > http://cr.openjdk.java.net/~thartmann/8173699/webrev.00/ > > The Graal compiled method java.lang.invoke.MemberName$Factory::resolve() calls into the method handle runtime via MethodHandleNatives::resolve() which throws a NoSuchMethodError because method resolution failed (see methodHandles.cpp, line 1234). We then call into JVMCIRuntime::exception_handler_for_pc() -> SharedRuntime::compute_compiled_exc_handler() to determine the appropriate exception handler. Because the ExceptionHandlerTable has no entry for this pc, we deoptimize and return to the DeoptimizationBlob at offset _unpack_with_exception_in_tls which calls Deoptimization::fetch_unroll_info(). Since the callee returns a MemberName object, the ScopeDesc is marked as return_oop() and the re-allocation code expects the return register (eax) to contain the oop of this returned object. We fail when trying to save the oop, because eax contains not an oop but the address of SharedRuntime::deopt_blob()->unpack_with_exception_in_tls() which was returned from JVMCIRuntime::exception_handler_for_pc() right before and is therefore still in eax. > > As Tom suggested in the bug comments, we should ignore the return_oop() when dispatching an exception and only try to retrieve the oop when performing re-allocation during a normal deoptimization (if exec_mode == Unpack_deopt). This code should be refactored with JDK 10. I filed JDK-8173823. > > This problem only affects JVMCI compiled code. C1 does not set return_oop() because it does not eliminate allocations (see IRScopeDebugInfo::record_debug_info()) and therefore does not need to re-allocate objects on deoptimization. C2 computes the exception handler via OptoRuntime::handle_exception_C() and uses DeoptimizationBlob::_unpack_with_exception as handler in case the nmethod was deoptimized. When calling Deoptimization::fetch_unroll_info() from the DeoptimizationBlob, eax still contains the exception oop and therefore the code works "by accident" because the exception oop is treated as returned oop. > > Tested with JVMCI test and RBT (running). > > Thanks to Tom and Dean for the help! > > Thanks, > Tobias > From tobias.hartmann at oracle.com Thu Feb 2 13:07:46 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 2 Feb 2017 14:07:46 +0100 Subject: [9] RFR(S): 8173699: Crash during deoptimization with "assert(result == __null || result->is_oop()) failed: must be oop" In-Reply-To: <48238f65-4e00-3309-579a-be9ce3f2929c@oracle.com> References: <48238f65-4e00-3309-579a-be9ce3f2929c@oracle.com> Message-ID: <4562fadd-b761-cb46-694f-379a1178cc06@oracle.com> On 02.02.2017 14:06, Vladimir Ivanov wrote: > Looks good. Wow, that was fast :) Thank you! Best regards, Tobias > On 2/2/17 4:04 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8173699 >> http://cr.openjdk.java.net/~thartmann/8173699/webrev.00/ >> >> The Graal compiled method java.lang.invoke.MemberName$Factory::resolve() calls into the method handle runtime via MethodHandleNatives::resolve() which throws a NoSuchMethodError because method resolution failed (see methodHandles.cpp, line 1234). We then call into JVMCIRuntime::exception_handler_for_pc() -> SharedRuntime::compute_compiled_exc_handler() to determine the appropriate exception handler. Because the ExceptionHandlerTable has no entry for this pc, we deoptimize and return to the DeoptimizationBlob at offset _unpack_with_exception_in_tls which calls Deoptimization::fetch_unroll_info(). Since the callee returns a MemberName object, the ScopeDesc is marked as return_oop() and the re-allocation code expects the return register (eax) to contain the oop of this returned object. We fail when trying to save the oop, because eax contains not an oop but the address of SharedRuntime::deopt_blob()->unpack_with_exception_in_tls() which was returned from >> JVMCIRuntime::exception_handler_for_pc() right before and is therefore still in eax. >> >> As Tom suggested in the bug comments, we should ignore the return_oop() when dispatching an exception and only try to retrieve the oop when performing re-allocation during a normal deoptimization (if exec_mode == Unpack_deopt). This code should be refactored with JDK 10. I filed JDK-8173823. >> >> This problem only affects JVMCI compiled code. C1 does not set return_oop() because it does not eliminate allocations (see IRScopeDebugInfo::record_debug_info()) and therefore does not need to re-allocate objects on deoptimization. C2 computes the exception handler via OptoRuntime::handle_exception_C() and uses DeoptimizationBlob::_unpack_with_exception as handler in case the nmethod was deoptimized. When calling Deoptimization::fetch_unroll_info() from the DeoptimizationBlob, eax still contains the exception oop and therefore the code works "by accident" because the exception oop is treated as returned oop. >> >> Tested with JVMCI test and RBT (running). >> >> Thanks to Tom and Dean for the help! >> >> Thanks, >> Tobias >> From vladimir.kozlov at oracle.com Thu Feb 2 16:42:41 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Feb 2017 08:42:41 -0800 Subject: [9] RFR(S): 8173699: Crash during deoptimization with "assert(result == __null || result->is_oop()) failed: must be oop" In-Reply-To: <48238f65-4e00-3309-579a-be9ce3f2929c@oracle.com> References: <48238f65-4e00-3309-579a-be9ce3f2929c@oracle.com> Message-ID: <98d860e7-23c1-7c90-ce46-9f530561c10e@oracle.com> +1 Vladimir K On 2/2/17 5:06 AM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 2/2/17 4:04 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8173699 >> http://cr.openjdk.java.net/~thartmann/8173699/webrev.00/ >> >> The Graal compiled method >> java.lang.invoke.MemberName$Factory::resolve() calls into the method >> handle runtime via MethodHandleNatives::resolve() which throws a >> NoSuchMethodError because method resolution failed (see >> methodHandles.cpp, line 1234). We then call into >> JVMCIRuntime::exception_handler_for_pc() -> >> SharedRuntime::compute_compiled_exc_handler() to determine the >> appropriate exception handler. Because the ExceptionHandlerTable has >> no entry for this pc, we deoptimize and return to the >> DeoptimizationBlob at offset _unpack_with_exception_in_tls which calls >> Deoptimization::fetch_unroll_info(). Since the callee returns a >> MemberName object, the ScopeDesc is marked as return_oop() and the >> re-allocation code expects the return register (eax) to contain the >> oop of this returned object. We fail when trying to save the oop, >> because eax contains not an oop but the address of >> SharedRuntime::deopt_blob()->unpack_with_exception_in_tls() which was >> returned from JVMCIRuntime::exception_handler_for_pc() right before >> and is therefore still in eax. >> >> As Tom suggested in the bug comments, we should ignore the >> return_oop() when dispatching an exception and only try to retrieve >> the oop when performing re-allocation during a normal deoptimization >> (if exec_mode == Unpack_deopt). This code should be refactored with >> JDK 10. I filed JDK-8173823. >> >> This problem only affects JVMCI compiled code. C1 does not set >> return_oop() because it does not eliminate allocations (see >> IRScopeDebugInfo::record_debug_info()) and therefore does not need to >> re-allocate objects on deoptimization. C2 computes the exception >> handler via OptoRuntime::handle_exception_C() and uses >> DeoptimizationBlob::_unpack_with_exception as handler in case the >> nmethod was deoptimized. When calling >> Deoptimization::fetch_unroll_info() from the DeoptimizationBlob, eax >> still contains the exception oop and therefore the code works "by >> accident" because the exception oop is treated as returned oop. >> >> Tested with JVMCI test and RBT (running). >> >> Thanks to Tom and Dean for the help! >> >> Thanks, >> Tobias >> From tobias.hartmann at oracle.com Thu Feb 2 16:44:27 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 2 Feb 2017 17:44:27 +0100 Subject: [9] RFR(S): 8173699: Crash during deoptimization with "assert(result == __null || result->is_oop()) failed: must be oop" In-Reply-To: <98d860e7-23c1-7c90-ce46-9f530561c10e@oracle.com> References: <48238f65-4e00-3309-579a-be9ce3f2929c@oracle.com> <98d860e7-23c1-7c90-ce46-9f530561c10e@oracle.com> Message-ID: <22aa0c6e-15ef-9d24-7123-ca9aa39055c5@oracle.com> Thanks, Vladimir! Best regards, Tobias On 02.02.2017 17:42, Vladimir Kozlov wrote: > +1 > > Vladimir K > > On 2/2/17 5:06 AM, Vladimir Ivanov wrote: >> Looks good. >> >> Best regards, >> Vladimir Ivanov >> >> On 2/2/17 4:04 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8173699 >>> http://cr.openjdk.java.net/~thartmann/8173699/webrev.00/ >>> >>> The Graal compiled method >>> java.lang.invoke.MemberName$Factory::resolve() calls into the method >>> handle runtime via MethodHandleNatives::resolve() which throws a >>> NoSuchMethodError because method resolution failed (see >>> methodHandles.cpp, line 1234). We then call into >>> JVMCIRuntime::exception_handler_for_pc() -> >>> SharedRuntime::compute_compiled_exc_handler() to determine the >>> appropriate exception handler. Because the ExceptionHandlerTable has >>> no entry for this pc, we deoptimize and return to the >>> DeoptimizationBlob at offset _unpack_with_exception_in_tls which calls >>> Deoptimization::fetch_unroll_info(). Since the callee returns a >>> MemberName object, the ScopeDesc is marked as return_oop() and the >>> re-allocation code expects the return register (eax) to contain the >>> oop of this returned object. We fail when trying to save the oop, >>> because eax contains not an oop but the address of >>> SharedRuntime::deopt_blob()->unpack_with_exception_in_tls() which was >>> returned from JVMCIRuntime::exception_handler_for_pc() right before >>> and is therefore still in eax. >>> >>> As Tom suggested in the bug comments, we should ignore the >>> return_oop() when dispatching an exception and only try to retrieve >>> the oop when performing re-allocation during a normal deoptimization >>> (if exec_mode == Unpack_deopt). This code should be refactored with >>> JDK 10. I filed JDK-8173823. >>> >>> This problem only affects JVMCI compiled code. C1 does not set >>> return_oop() because it does not eliminate allocations (see >>> IRScopeDebugInfo::record_debug_info()) and therefore does not need to >>> re-allocate objects on deoptimization. C2 computes the exception >>> handler via OptoRuntime::handle_exception_C() and uses >>> DeoptimizationBlob::_unpack_with_exception as handler in case the >>> nmethod was deoptimized. When calling >>> Deoptimization::fetch_unroll_info() from the DeoptimizationBlob, eax >>> still contains the exception oop and therefore the code works "by >>> accident" because the exception oop is treated as returned oop. >>> >>> Tested with JVMCI test and RBT (running). >>> >>> Thanks to Tom and Dean for the help! >>> >>> Thanks, >>> Tobias >>> From rahul.v.raghavan at oracle.com Thu Feb 2 16:59:22 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 2 Feb 2017 08:59:22 -0800 (PST) Subject: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected In-Reply-To: <71637db5-b9dc-4d28-3e50-67d7af7510b9@oracle.com> References: <78660a0f-f5eb-4a84-a78e-b23404bd8173@default> <7b706e31-502e-a840-b3a3-57a4be633328@oracle.com> <828151e6-62e5-43dd-91cb-5cf8f73a13d6@default> <8dcf7880-23bd-e8c7-5fb5-cf4ebf214c59@oracle.com> <46c2cd07-19b0-7c21-fc38-c54cdce4d0f7@oracle.com> <71637db5-b9dc-4d28-3e50-67d7af7510b9@oracle.com> Message-ID: <91710ea0-420b-450e-8a52-2f7a6b7d9253@default> Hi, Thank you Vladimir for the review comments. Understood your point and agree that for the reported scenario bailing out early and delaying the optimization should be the fix. Please review updated - http://cr.openjdk.java.net/~rraghavan/8144484/webrev.02/ Confirmed no issues with testing (8144484 test, jprt -testset hotspot; so far no issues with RBT Pre-integration testing in progress ) Thanks, Rahul > -----Original Message----- > From: Vladimir Kozlov > Sent: Wednesday, February 01, 2017 2:32 PM > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected > > On 2/1/17 12:19 AM, Vladimir Kozlov wrote: > > Sorry, I don't like this fix. > > > > Based on your evaluation one control path is dead (top) and it will be optimized out later. It was unfortunate that Phi > > node was processed first. Change graph (split through MergeMem) is dangerous in this state of graph. > > > > I would suggest to bailout early: > > > > 1886 if (progress == NULL && can_reshape && type() == Type::MEMORY) { > > 1887 // see if this phi should be sliced > > 1888 uint merge_width = 0; > > 1889 bool saw_self = false; > > 1890 for( uint i=1; i > 1891 Node *ii = in(i); > > > > + // TOP inputs should not be counted as safe inputs because if the > > + // Phi references itself through all other inputs then splitting the > > + // Phi through memory merges would create dead loop at later stage. > > + if (ii == top) { > > + return top; // Delay optimization until graph is cleaned. > > Sorry, wrong return value. Should be return NULL; > > > + } > > > > 1892 if (ii->is_MergeMem()) { > > 1893 MergeMemNode* n = ii->as_MergeMem(); > > > > Thanks, > > Vladimir > > From vladimir.kozlov at oracle.com Thu Feb 2 17:00:59 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Feb 2017 09:00:59 -0800 Subject: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected In-Reply-To: <91710ea0-420b-450e-8a52-2f7a6b7d9253@default> References: <78660a0f-f5eb-4a84-a78e-b23404bd8173@default> <7b706e31-502e-a840-b3a3-57a4be633328@oracle.com> <828151e6-62e5-43dd-91cb-5cf8f73a13d6@default> <8dcf7880-23bd-e8c7-5fb5-cf4ebf214c59@oracle.com> <46c2cd07-19b0-7c21-fc38-c54cdce4d0f7@oracle.com> <71637db5-b9dc-4d28-3e50-67d7af7510b9@oracle.com> <91710ea0-420b-450e-8a52-2f7a6b7d9253@default> Message-ID: <624a6b45-5ab8-35e1-18d2-362c40dc63de@oracle.com> On 2/2/17 8:59 AM, Rahul Raghavan wrote: > Hi, > > Thank you Vladimir for the review comments. > Understood your point and agree that for the reported scenario > bailing out early and delaying the optimization should be the fix. > > Please review updated - http://cr.openjdk.java.net/~rraghavan/8144484/webrev.02/ Good. Thanks, Vladimir > > Confirmed no issues with testing > (8144484 test, jprt -testset hotspot; so far no issues with RBT Pre-integration testing in progress ) > > Thanks, > Rahul > >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: Wednesday, February 01, 2017 2:32 PM >> To: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected >> >> On 2/1/17 12:19 AM, Vladimir Kozlov wrote: >>> Sorry, I don't like this fix. >>> >>> Based on your evaluation one control path is dead (top) and it will be optimized out later. It was unfortunate that Phi >>> node was processed first. Change graph (split through MergeMem) is dangerous in this state of graph. >>> >>> I would suggest to bailout early: >>> >>> 1886 if (progress == NULL && can_reshape && type() == Type::MEMORY) { >>> 1887 // see if this phi should be sliced >>> 1888 uint merge_width = 0; >>> 1889 bool saw_self = false; >>> 1890 for( uint i=1; i>> 1891 Node *ii = in(i); >>> >>> + // TOP inputs should not be counted as safe inputs because if the >>> + // Phi references itself through all other inputs then splitting the >>> + // Phi through memory merges would create dead loop at later stage. >>> + if (ii == top) { >>> + return top; // Delay optimization until graph is cleaned. >> >> Sorry, wrong return value. Should be return NULL; >> >>> + } >>> >>> 1892 if (ii->is_MergeMem()) { >>> 1893 MergeMemNode* n = ii->as_MergeMem(); >>> >>> Thanks, >>> Vladimir >>> From vladimir.kozlov at oracle.com Thu Feb 2 17:03:22 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Feb 2017 09:03:22 -0800 Subject: RFR: Fix for JDK-8173119, compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java fails with custom Tiered Level set externally In-Reply-To: References: Message-ID: Good. Thanks, Vladimir K On 1/31/17 10:17 PM, Oleg Pliss wrote: > http://cr.openjdk.java.net/~kvn/8173119/webrev/ > From igor.veresov at oracle.com Thu Feb 2 19:14:35 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 2 Feb 2017 11:14:35 -0800 Subject: RFR(M) 8173846: [AOT] Stubs hang onto intermediate compiler state forever Message-ID: <9F2AA4C4-B4F3-451F-B91F-E361F3BC2051@oracle.com> This a port of Graal change that alters the API that is used by the jaotc. In order to maintain drop-in compatibility with Graal, it's important to follow this API change in jaotc. The change essentially gets rid of Stub.compResult and Stub.compiledCode fields that hang on to the compilation state. Webrev: http://cr.openjdk.java.net/~never/aot-stub-changes/webrev Thanks, igor From igor.veresov at oracle.com Thu Feb 2 22:22:31 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 2 Feb 2017 14:22:31 -0800 Subject: RFR(M) 8173846: [AOT] Stubs hang onto intermediate compiler state forever In-Reply-To: <9F2AA4C4-B4F3-451F-B91F-E361F3BC2051@oracle.com> References: <9F2AA4C4-B4F3-451F-B91F-E361F3BC2051@oracle.com> Message-ID: <76A6F54C-E807-4548-800C-6116E819B564@oracle.com> Forgot to mention that the code is contributed by Tom Rodriguez and the Graal part will be pushed to graal-core. igor > On Feb 2, 2017, at 11:14 AM, Igor Veresov wrote: > > This a port of Graal change that alters the API that is used by the jaotc. In order to maintain drop-in compatibility with Graal, it's important to follow this API change in jaotc. The change essentially gets rid of Stub.compResult and Stub.compiledCode fields that hang on to the compilation state. > > Webrev: http://cr.openjdk.java.net/~never/aot-stub-changes/webrev > > Thanks, > igor From vladimir.kozlov at oracle.com Thu Feb 2 22:43:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Feb 2017 14:43:50 -0800 Subject: RFR(M) 8173846: [AOT] Stubs hang onto intermediate compiler state forever In-Reply-To: <76A6F54C-E807-4548-800C-6116E819B564@oracle.com> References: <9F2AA4C4-B4F3-451F-B91F-E361F3BC2051@oracle.com> <76A6F54C-E807-4548-800C-6116E819B564@oracle.com> Message-ID: Looks good. Thanks, Vladimir On 2/2/17 2:22 PM, Igor Veresov wrote: > Forgot to mention that the code is contributed by Tom Rodriguez and the Graal part will be pushed to graal-core. > > igor > >> On Feb 2, 2017, at 11:14 AM, Igor Veresov wrote: >> >> This a port of Graal change that alters the API that is used by the jaotc. In order to maintain drop-in compatibility with Graal, it's important to follow this API change in jaotc. The change essentially gets rid of Stub.compResult and Stub.compiledCode fields that hang on to the compilation state. >> >> Webrev: http://cr.openjdk.java.net/~never/aot-stub-changes/webrev >> >> Thanks, >> igor > From igor.veresov at oracle.com Thu Feb 2 23:05:10 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 2 Feb 2017 15:05:10 -0800 Subject: RFR(M) 8173846: [AOT] Stubs hang onto intermediate compiler state forever In-Reply-To: References: <9F2AA4C4-B4F3-451F-B91F-E361F3BC2051@oracle.com> <76A6F54C-E807-4548-800C-6116E819B564@oracle.com> Message-ID: Thanks, Vladimir! igor > On Feb 2, 2017, at 2:43 PM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 2/2/17 2:22 PM, Igor Veresov wrote: >> Forgot to mention that the code is contributed by Tom Rodriguez and the Graal part will be pushed to graal-core. >> >> igor >> >>> On Feb 2, 2017, at 11:14 AM, Igor Veresov wrote: >>> >>> This a port of Graal change that alters the API that is used by the jaotc. In order to maintain drop-in compatibility with Graal, it's important to follow this API change in jaotc. The change essentially gets rid of Stub.compResult and Stub.compiledCode fields that hang on to the compilation state. >>> >>> Webrev: http://cr.openjdk.java.net/~never/aot-stub-changes/webrev >>> >>> Thanks, >>> igor >> From jamsheed.c.m at oracle.com Fri Feb 3 02:09:50 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 3 Feb 2017 07:39:50 +0530 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> <6c221440-13f9-7f88-8d6d-ea037c218da1@oracle.com> <8bc609d5-cfe2-035d-b530-16ea20783a10@oracle.com> Message-ID: Hi Vladimir, revised webrev : 1) Changes to make cli tests to run on sameVM root part: http://cr.openjdk.java.net/~jcm/8173679/webrev.00.hs/ 2) Changes for, disabling mdo trap count update on deopt, and to make +UseRTMLocking to exit. hotspot part: http://cr.openjdk.java.net/~jcm/8173679/webrev.02.hotspot/ Best Regards, Jamsheed On 2/2/2017 10:59 AM, Jamsheed C m wrote: > Hi Vladimir, > > On 2/2/2017 9:20 AM, Vladimir Kozlov wrote: >> >> >> On 2/1/17 6:19 PM, Jamsheed C m wrote: >>> Hi Vladimir, >>> >>> On 2/2/2017 7:07 AM, Vladimir Kozlov wrote: >>>> On 2/1/17 9:07 AM, Jamsheed C m wrote: >>>>> Hi Vladimir, >>>>> >>>>> >>>>> On 2/1/2017 10:25 PM, Vladimir Kozlov wrote: >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Feb 1, 2017, at 5:20 AM, Jamsheed C m >>>>>>> wrote: >>>>>>> >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> revised webrev : http://cr.openjdk.java.net/~jcm/8173679/webrev.01/ >>>>>>> >>>>>>> 1) -XX:+UseRTMLocking displays informative warning in emulate >>>>>>> client mode. >>>>>> Warning doesn't switch off RTM. >>>>>> where you are switching it off? >>>>> i am not switching it off, i am just printing warning, User should >>>>> explicitly remove option. >>>> >>>> Then it should be not warning but error. We can't run in Client >>>> mode with RTM on. Or I am missing something? >>> RTM "ON" state is always user specified action. RTM is default OFF. >>> from the code it says it disables BiasedLocking when >>> RTM is ON and exit in client(lose both rtm + biased locking feature >>> with -XX:+UseRTMLocking), i made it warning for >> >> Where it exits? It does not in VM_Version::use_biased_locking(). > i meant normal client exits. emulated client prints warning only, it > doesn't exit or change flags. >> >>> emulated client. as it is User specified action, User can see >>> warning that Biased lock get switched off with an >>> unsupported option, and remove it from his commandline. >> >> No, you have to explicitly call vm_exit_during_initialization() as it >> was done in preceding code (!supports_rtm() && UseRTMLocking). Note, >> users may ignores warnings because usually output is stored in log >> files. > Sure, i will do required code change , and send it for review. > Best Regards, > Jamsheed >> >> thanks, >> Vladimir >> >>> Best Regards, >>> Jamsheed >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Best Regards, Jamsheed >>>>> >>>>>> >>>>>> Vladimir >>>>>> >>>>>>> 2) Disabled mdo update code in deopt. >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Jamsheed >>>>>>> >>>>>>> >>>>>>>> On 2/1/2017 11:04 AM, Jamsheed C m wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>>> On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: >>>>>>>>>> On 1/31/17 10:37 AM, Jamsheed C m wrote: >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> ProfileTraps is develop_pd flag, should i be changing flag >>>>>>>>>> type ? >>>>>>>>> No. Thinking more about this. The code guarded by ProfileTraps >>>>>>>>> should be only executed when ProfileInterpreter is >>>>>>>>> true. And you set ProfileInterpreter to false in client mode. >>>>>>>>> Why you need these changes then? Did you hit some >>>>>>>>> ProfileTraps code which is not guarded by ProfileInterpreter? >>>>>>>> with ProfileTraps ON may be the trap count updation in deopt >>>>>>>> pollute Runtime1::predicate_failed_trap trap count >>>>>>>> and may influence the recompilation time optimization decision? >>>>>>>> also create some more mdos(empty ones) in >>>>>>>> exceptions ? >>>>>>>> other than that i don't find any issues. >>>>>>>> >>>>>>>> just disabling ProfileTraps[1] in deoptimization should solve >>>>>>>> first problem. second problem of creation of >>>>>>>> mdos(empty ones) for exception is harmless i believe. >>>>>>>> [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { >>>>>>>> >>>>>>>>>> RTM test code doesn't pass VM options to spawned process, >>>>>>>>>> So predicate checking process and spawned process >>>>>>>>>> can be in >>>>>>>>>> different modes. spawned test process is always in emulated >>>>>>>>>> client mode in win32. >>>>>>>>>> >>>>>>>>>> the predicate checking process will be in emulated client or >>>>>>>>>> server based on passed -XX:+|-TieredCompilation >>>>>>>>>> option. >>>>>>>>>> as a fix i disabled RTM testing completely in win32. >>>>>>>>> I still do not understand why you can't use >>>>>>>>> Platform.isEmulatedClient() instead of Platform.isWindows() && >>>>>>>>> Platform.is32bit(). >>>>>>>>> >>>>>>>>> And why changes in SupportedOS.java is not enough? >>>>>>>> Some tests doesn't pass vmoption to child process(cli tests). >>>>>>>> so same vm tests will be running in different modes >>>>>>>> ( i.e child will always run in emulated client mode, while >>>>>>>> predicate checking parent process will run in server or >>>>>>>> emulated client depending on option passed). so these tests >>>>>>>> require change if i am changing VM behavior with >>>>>>>> respect to options. >>>>>>>> >>>>>>>> //I would suggest to disable RTM only in client mode. // >>>>>>>> >>>>>>>> as per this discussion, i decided to not disable tests or vm >>>>>>>> behavior, just print some harmless warning in >>>>>>>> emulated client mode. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Jamsheed >>>>>>>> >>>>>>>>>> i will disable RTM completely in win32(both emulated client >>>>>>>>>> and server). >>>>>>>>> I would suggest to disable RTM only in client mode. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> >>>>>>>>>> Jamsheed >>>>>>>>>> >>>>>>>>>>> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>>>>>>>>>> Jamsheed >>>>>>>>>>> >>>>>>>>>>> Instead of adding check && !is_client_compilation_mode_vm() >>>>>>>>>>> I think we should set ProfileTraps to false in >>>>>>>>>>> client mode. >>>>>>>>>>> >>>>>>>>>>> Why you not using Platform.isEmulatedClient() in tests changes? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Code change to disable ProfileTrap and UseRTMLocking in >>>>>>>>>>>> Win32 emulated client . >>>>>>>>>>>> >>>>>>>>>>>> 1) ProfileTrap is code is disabled >>>>>>>>>>>> >>>>>>>>>>>> 2) -XX:+ UseRTMLocking in win32 emulated client not supported. >>>>>>>>>>>> >>>>>>>>>>>> 3) All Supported and Unsupported testcases related RTM is >>>>>>>>>>>> disabled in win32. >>>>>>>>>>>> >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>>>>>>>>>> >>>>>>>>>>>> Best Regards, >>>>>>>>>>>> >>>>>>>>>>>> Jamsheed >>>>>>>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Fri Feb 3 02:26:57 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Feb 2017 18:26:57 -0800 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> <6c221440-13f9-7f88-8d6d-ea037c218da1@oracle.com> <8bc609d5-cfe2-035d-b530-16ea20783a10@oracle.com> Message-ID: <10624bf4-b625-be84-5394-ee068fb39d84@oracle.com> This looks good. Thanks, Vladimir On 2/2/17 6:09 PM, Jamsheed C m wrote: > Hi Vladimir, > > revised webrev : > > 1) Changes to make cli tests to run on sameVM > > root part: http://cr.openjdk.java.net/~jcm/8173679/webrev.00.hs/ > > 2) Changes for, disabling mdo trap count update on deopt, and to make > +UseRTMLocking to exit. > > hotspot part: http://cr.openjdk.java.net/~jcm/8173679/webrev.02.hotspot/ > > Best Regards, > > Jamsheed > > On 2/2/2017 10:59 AM, Jamsheed C m wrote: >> Hi Vladimir, >> >> On 2/2/2017 9:20 AM, Vladimir Kozlov wrote: >>> >>> >>> On 2/1/17 6:19 PM, Jamsheed C m wrote: >>>> Hi Vladimir, >>>> >>>> On 2/2/2017 7:07 AM, Vladimir Kozlov wrote: >>>>> On 2/1/17 9:07 AM, Jamsheed C m wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> >>>>>> On 2/1/2017 10:25 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On Feb 1, 2017, at 5:20 AM, Jamsheed C m >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> revised webrev : http://cr.openjdk.java.net/~jcm/8173679/webrev.01/ >>>>>>>> >>>>>>>> 1) -XX:+UseRTMLocking displays informative warning in emulate >>>>>>>> client mode. >>>>>>> Warning doesn't switch off RTM. >>>>>>> where you are switching it off? >>>>>> i am not switching it off, i am just printing warning, User should >>>>>> explicitly remove option. >>>>> >>>>> Then it should be not warning but error. We can't run in Client >>>>> mode with RTM on. Or I am missing something? >>>> RTM "ON" state is always user specified action. RTM is default OFF. >>>> from the code it says it disables BiasedLocking when >>>> RTM is ON and exit in client(lose both rtm + biased locking feature >>>> with -XX:+UseRTMLocking), i made it warning for >>> >>> Where it exits? It does not in VM_Version::use_biased_locking(). >> i meant normal client exits. emulated client prints warning only, it >> doesn't exit or change flags. >>> >>>> emulated client. as it is User specified action, User can see >>>> warning that Biased lock get switched off with an >>>> unsupported option, and remove it from his commandline. >>> >>> No, you have to explicitly call vm_exit_during_initialization() as it >>> was done in preceding code (!supports_rtm() && UseRTMLocking). Note, >>> users may ignores warnings because usually output is stored in log >>> files. >> Sure, i will do required code change , and send it for review. >> Best Regards, >> Jamsheed >>> >>> thanks, >>> Vladimir >>> >>>> Best Regards, >>>> Jamsheed >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Best Regards, Jamsheed >>>>>> >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>>> 2) Disabled mdo update code in deopt. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Jamsheed >>>>>>>> >>>>>>>> >>>>>>>>> On 2/1/2017 11:04 AM, Jamsheed C m wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>>> On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: >>>>>>>>>>> On 1/31/17 10:37 AM, Jamsheed C m wrote: >>>>>>>>>>> Hi Vladimir, >>>>>>>>>>> >>>>>>>>>>> ProfileTraps is develop_pd flag, should i be changing flag >>>>>>>>>>> type ? >>>>>>>>>> No. Thinking more about this. The code guarded by ProfileTraps >>>>>>>>>> should be only executed when ProfileInterpreter is >>>>>>>>>> true. And you set ProfileInterpreter to false in client mode. >>>>>>>>>> Why you need these changes then? Did you hit some >>>>>>>>>> ProfileTraps code which is not guarded by ProfileInterpreter? >>>>>>>>> with ProfileTraps ON may be the trap count updation in deopt >>>>>>>>> pollute Runtime1::predicate_failed_trap trap count >>>>>>>>> and may influence the recompilation time optimization decision? >>>>>>>>> also create some more mdos(empty ones) in >>>>>>>>> exceptions ? >>>>>>>>> other than that i don't find any issues. >>>>>>>>> >>>>>>>>> just disabling ProfileTraps[1] in deoptimization should solve >>>>>>>>> first problem. second problem of creation of >>>>>>>>> mdos(empty ones) for exception is harmless i believe. >>>>>>>>> [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { >>>>>>>>> >>>>>>>>>>> RTM test code doesn't pass VM options to spawned process, >>>>>>>>>>> So predicate checking process and spawned process >>>>>>>>>>> can be in >>>>>>>>>>> different modes. spawned test process is always in emulated >>>>>>>>>>> client mode in win32. >>>>>>>>>>> >>>>>>>>>>> the predicate checking process will be in emulated client or >>>>>>>>>>> server based on passed -XX:+|-TieredCompilation >>>>>>>>>>> option. >>>>>>>>>>> as a fix i disabled RTM testing completely in win32. >>>>>>>>>> I still do not understand why you can't use >>>>>>>>>> Platform.isEmulatedClient() instead of Platform.isWindows() && >>>>>>>>>> Platform.is32bit(). >>>>>>>>>> >>>>>>>>>> And why changes in SupportedOS.java is not enough? >>>>>>>>> Some tests doesn't pass vmoption to child process(cli tests). >>>>>>>>> so same vm tests will be running in different modes >>>>>>>>> ( i.e child will always run in emulated client mode, while >>>>>>>>> predicate checking parent process will run in server or >>>>>>>>> emulated client depending on option passed). so these tests >>>>>>>>> require change if i am changing VM behavior with >>>>>>>>> respect to options. >>>>>>>>> >>>>>>>>> //I would suggest to disable RTM only in client mode. // >>>>>>>>> >>>>>>>>> as per this discussion, i decided to not disable tests or vm >>>>>>>>> behavior, just print some harmless warning in >>>>>>>>> emulated client mode. >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Jamsheed >>>>>>>>> >>>>>>>>>>> i will disable RTM completely in win32(both emulated client >>>>>>>>>>> and server). >>>>>>>>>> I would suggest to disable RTM only in client mode. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> >>>>>>>>>>> Jamsheed >>>>>>>>>>> >>>>>>>>>>>> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>>>>>>>>>>> Jamsheed >>>>>>>>>>>> >>>>>>>>>>>> Instead of adding check && !is_client_compilation_mode_vm() >>>>>>>>>>>> I think we should set ProfileTraps to false in >>>>>>>>>>>> client mode. >>>>>>>>>>>> >>>>>>>>>>>> Why you not using Platform.isEmulatedClient() in tests changes? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Code change to disable ProfileTrap and UseRTMLocking in >>>>>>>>>>>>> Win32 emulated client . >>>>>>>>>>>>> >>>>>>>>>>>>> 1) ProfileTrap is code is disabled >>>>>>>>>>>>> >>>>>>>>>>>>> 2) -XX:+ UseRTMLocking in win32 emulated client not supported. >>>>>>>>>>>>> >>>>>>>>>>>>> 3) All Supported and Unsupported testcases related RTM is >>>>>>>>>>>>> disabled in win32. >>>>>>>>>>>>> >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>>>>>>>>>>> >>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Jamsheed >>>>>>>>>>>>> >>>>>> >>>> >> > From tobias.hartmann at oracle.com Fri Feb 3 07:13:23 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 3 Feb 2017 08:13:23 +0100 Subject: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected In-Reply-To: <91710ea0-420b-450e-8a52-2f7a6b7d9253@default> References: <78660a0f-f5eb-4a84-a78e-b23404bd8173@default> <7b706e31-502e-a840-b3a3-57a4be633328@oracle.com> <828151e6-62e5-43dd-91cb-5cf8f73a13d6@default> <8dcf7880-23bd-e8c7-5fb5-cf4ebf214c59@oracle.com> <46c2cd07-19b0-7c21-fc38-c54cdce4d0f7@oracle.com> <71637db5-b9dc-4d28-3e50-67d7af7510b9@oracle.com> <91710ea0-420b-450e-8a52-2f7a6b7d9253@default> Message-ID: <639a66da-e105-01f4-150f-8aeaf9e6c0d5@oracle.com> Hi Rahul, On 02.02.2017 17:59, Rahul Raghavan wrote: > Please review updated - http://cr.openjdk.java.net/~rraghavan/8144484/webrev.02/ Looks good to me! Thanks, Tobias From jamsheed.c.m at oracle.com Fri Feb 3 07:47:57 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 3 Feb 2017 13:17:57 +0530 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: <10624bf4-b625-be84-5394-ee068fb39d84@oracle.com> References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> <6c221440-13f9-7f88-8d6d-ea037c218da1@oracle.com> <8bc609d5-cfe2-035d-b530-16ea20783a10@oracle.com> <10624bf4-b625-be84-5394-ee068fb39d84@oracle.com> Message-ID: <08c3d733-d480-6b17-585b-ccfd2223bf41@oracle.com> Thank you for the review, Vladimir while testing i found that i missed adding @requires !vm.emulatedClient in compiler/types/correctness/OffTest.java. i will be adding that with this push? is that Ok ? Best Regards, Jamsheed On 2/3/2017 7:56 AM, Vladimir Kozlov wrote: > This looks good. > > Thanks, > Vladimir > > On 2/2/17 6:09 PM, Jamsheed C m wrote: >> Hi Vladimir, >> >> revised webrev : >> >> 1) Changes to make cli tests to run on sameVM >> >> root part: http://cr.openjdk.java.net/~jcm/8173679/webrev.00.hs/ >> >> 2) Changes for, disabling mdo trap count update on deopt, and to make >> +UseRTMLocking to exit. >> >> hotspot part: http://cr.openjdk.java.net/~jcm/8173679/webrev.02.hotspot/ >> >> Best Regards, >> >> Jamsheed >> >> On 2/2/2017 10:59 AM, Jamsheed C m wrote: >>> Hi Vladimir, >>> >>> On 2/2/2017 9:20 AM, Vladimir Kozlov wrote: >>>> >>>> >>>> On 2/1/17 6:19 PM, Jamsheed C m wrote: >>>>> Hi Vladimir, >>>>> >>>>> On 2/2/2017 7:07 AM, Vladimir Kozlov wrote: >>>>>> On 2/1/17 9:07 AM, Jamsheed C m wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> >>>>>>> On 2/1/2017 10:25 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>>> On Feb 1, 2017, at 5:20 AM, Jamsheed C m >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> revised webrev : >>>>>>>>> http://cr.openjdk.java.net/~jcm/8173679/webrev.01/ >>>>>>>>> >>>>>>>>> 1) -XX:+UseRTMLocking displays informative warning in emulate >>>>>>>>> client mode. >>>>>>>> Warning doesn't switch off RTM. >>>>>>>> where you are switching it off? >>>>>>> i am not switching it off, i am just printing warning, User should >>>>>>> explicitly remove option. >>>>>> >>>>>> Then it should be not warning but error. We can't run in Client >>>>>> mode with RTM on. Or I am missing something? >>>>> RTM "ON" state is always user specified action. RTM is default OFF. >>>>> from the code it says it disables BiasedLocking when >>>>> RTM is ON and exit in client(lose both rtm + biased locking feature >>>>> with -XX:+UseRTMLocking), i made it warning for >>>> >>>> Where it exits? It does not in VM_Version::use_biased_locking(). >>> i meant normal client exits. emulated client prints warning only, it >>> doesn't exit or change flags. >>>> >>>>> emulated client. as it is User specified action, User can see >>>>> warning that Biased lock get switched off with an >>>>> unsupported option, and remove it from his commandline. >>>> >>>> No, you have to explicitly call vm_exit_during_initialization() as it >>>> was done in preceding code (!supports_rtm() && UseRTMLocking). Note, >>>> users may ignores warnings because usually output is stored in log >>>> files. >>> Sure, i will do required code change , and send it for review. >>> Best Regards, >>> Jamsheed >>>> >>>> thanks, >>>> Vladimir >>>> >>>>> Best Regards, >>>>> Jamsheed >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Best Regards, Jamsheed >>>>>>> >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> 2) Disabled mdo update code in deopt. >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Jamsheed >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2/1/2017 11:04 AM, Jamsheed C m wrote: >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>>> On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: >>>>>>>>>>>> On 1/31/17 10:37 AM, Jamsheed C m wrote: >>>>>>>>>>>> Hi Vladimir, >>>>>>>>>>>> >>>>>>>>>>>> ProfileTraps is develop_pd flag, should i be changing flag >>>>>>>>>>>> type ? >>>>>>>>>>> No. Thinking more about this. The code guarded by ProfileTraps >>>>>>>>>>> should be only executed when ProfileInterpreter is >>>>>>>>>>> true. And you set ProfileInterpreter to false in client mode. >>>>>>>>>>> Why you need these changes then? Did you hit some >>>>>>>>>>> ProfileTraps code which is not guarded by ProfileInterpreter? >>>>>>>>>> with ProfileTraps ON may be the trap count updation in deopt >>>>>>>>>> pollute Runtime1::predicate_failed_trap trap count >>>>>>>>>> and may influence the recompilation time optimization decision? >>>>>>>>>> also create some more mdos(empty ones) in >>>>>>>>>> exceptions ? >>>>>>>>>> other than that i don't find any issues. >>>>>>>>>> >>>>>>>>>> just disabling ProfileTraps[1] in deoptimization should solve >>>>>>>>>> first problem. second problem of creation of >>>>>>>>>> mdos(empty ones) for exception is harmless i believe. >>>>>>>>>> [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { >>>>>>>>>> >>>>>>>>>>>> RTM test code doesn't pass VM options to spawned process, >>>>>>>>>>>> So predicate checking process and spawned process >>>>>>>>>>>> can be in >>>>>>>>>>>> different modes. spawned test process is always in emulated >>>>>>>>>>>> client mode in win32. >>>>>>>>>>>> >>>>>>>>>>>> the predicate checking process will be in emulated client or >>>>>>>>>>>> server based on passed -XX:+|-TieredCompilation >>>>>>>>>>>> option. >>>>>>>>>>>> as a fix i disabled RTM testing completely in win32. >>>>>>>>>>> I still do not understand why you can't use >>>>>>>>>>> Platform.isEmulatedClient() instead of Platform.isWindows() && >>>>>>>>>>> Platform.is32bit(). >>>>>>>>>>> >>>>>>>>>>> And why changes in SupportedOS.java is not enough? >>>>>>>>>> Some tests doesn't pass vmoption to child process(cli tests). >>>>>>>>>> so same vm tests will be running in different modes >>>>>>>>>> ( i.e child will always run in emulated client mode, while >>>>>>>>>> predicate checking parent process will run in server or >>>>>>>>>> emulated client depending on option passed). so these tests >>>>>>>>>> require change if i am changing VM behavior with >>>>>>>>>> respect to options. >>>>>>>>>> >>>>>>>>>> //I would suggest to disable RTM only in client mode. // >>>>>>>>>> >>>>>>>>>> as per this discussion, i decided to not disable tests or vm >>>>>>>>>> behavior, just print some harmless warning in >>>>>>>>>> emulated client mode. >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> Jamsheed >>>>>>>>>> >>>>>>>>>>>> i will disable RTM completely in win32(both emulated client >>>>>>>>>>>> and server). >>>>>>>>>>> I would suggest to disable RTM only in client mode. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>>> Best Regards, >>>>>>>>>>>> >>>>>>>>>>>> Jamsheed >>>>>>>>>>>> >>>>>>>>>>>>> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>> Jamsheed >>>>>>>>>>>>> >>>>>>>>>>>>> Instead of adding check && !is_client_compilation_mode_vm() >>>>>>>>>>>>> I think we should set ProfileTraps to false in >>>>>>>>>>>>> client mode. >>>>>>>>>>>>> >>>>>>>>>>>>> Why you not using Platform.isEmulatedClient() in tests >>>>>>>>>>>>> changes? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Code change to disable ProfileTrap and UseRTMLocking in >>>>>>>>>>>>>> Win32 emulated client . >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) ProfileTrap is code is disabled >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) -XX:+ UseRTMLocking in win32 emulated client not >>>>>>>>>>>>>> supported. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3) All Supported and Unsupported testcases related RTM is >>>>>>>>>>>>>> disabled in win32. >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jamsheed >>>>>>>>>>>>>> >>>>>>> >>>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rahul.v.raghavan at oracle.com Fri Feb 3 08:18:42 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Fri, 3 Feb 2017 00:18:42 -0800 (PST) Subject: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected In-Reply-To: <639a66da-e105-01f4-150f-8aeaf9e6c0d5@oracle.com> References: <78660a0f-f5eb-4a84-a78e-b23404bd8173@default> <7b706e31-502e-a840-b3a3-57a4be633328@oracle.com> <828151e6-62e5-43dd-91cb-5cf8f73a13d6@default> <8dcf7880-23bd-e8c7-5fb5-cf4ebf214c59@oracle.com> <46c2cd07-19b0-7c21-fc38-c54cdce4d0f7@oracle.com> <71637db5-b9dc-4d28-3e50-67d7af7510b9@oracle.com> <91710ea0-420b-450e-8a52-2f7a6b7d9253@default> <639a66da-e105-01f4-150f-8aeaf9e6c0d5@oracle.com> Message-ID: Thank you for the review Tobias, Vladimir. > -----Original Message----- > From: Tobias Hartmann > Sent: Friday, February 03, 2017 12:43 PM > To: Rahul Raghavan; Vladimir Kozlov; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR: 8144484: assert(no_dead_loop) failed: dead loop detected > > Hi Rahul, > > On 02.02.2017 17:59, Rahul Raghavan wrote: > > Please review updated - http://cr.openjdk.java.net/~rraghavan/8144484/webrev.02/ > > Looks good to me! > > Thanks, > Tobias On 2/2/17 8:59 AM, Rahul Raghavan wrote: > Hi, > > Thank you Vladimir for the review comments. > Understood your point and agree that for the reported scenario > bailing out early and delaying the optimization should be the fix. > > Please review updated - http://cr.openjdk.java.net/~rraghavan/8144484/webrev.02/ Good. Thanks, Vladimir From dmitry.chuyko at oracle.com Fri Feb 3 14:19:30 2017 From: dmitry.chuyko at oracle.com (Dmitry Chuyko) Date: Fri, 3 Feb 2017 17:19:30 +0300 Subject: RFR : JDK-8166110 : C2 crash in compiling method handles Message-ID: Summary: some method handles can be used with actual parameters not matching their signatures. It's too expensive to check this on call but possible to check during inlining. Inlined MHs with wrong usage caused further assertion failures in debug builds. The fix adds checks for signatures match during MH inlining so it fails if they are not matching. New test checks linkToStatic and invokeBasic cases. Bug: https://bugs.openjdk.java.net/browse/JDK-8166110 Webrev: http://cr.openjdk.java.net/~vlivanov/dchuyko/8166110/webrev.00/ Testing: new test, Hotspot and JDK tests, promotion benchmarks. Thanks, -Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.chuyko at oracle.com Fri Feb 3 15:42:16 2017 From: dmitry.chuyko at oracle.com (Dmitry Chuyko) Date: Fri, 3 Feb 2017 18:42:16 +0300 Subject: RFR : JDK-8166110 : C2 crash in compiling method handles In-Reply-To: References: Message-ID: <72ca6df7-27fa-91d1-ee50-3e723cb1969b@oracle.com> The link url may be wrong depending on how html is handled by email client. Thanks to those who noticed that. Webrev: http://cr.openjdk.java.net/~vlivanov/dchuyko/8166110/webrev.00/ -Dmitry On 02/03/2017 05:19 PM, Dmitry Chuyko wrote: > > Summary: some method handles can be used with actual parameters not > matching their signatures. It's too expensive to check this on call > but possible to check during inlining. Inlined MHs with wrong usage > caused further assertion failures in debug builds. The fix adds checks > for signatures match during MH inlining so it fails if they are not > matching. New test checks linkToStatic and invokeBasic cases. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166110 > > Webrev: http://cr.openjdk.java.net/~vlivanov/dchuyko/8166110/webrev.00/ > > Testing: new test, Hotspot and JDK tests, promotion benchmarks. > > Thanks, > -Dmitry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Fri Feb 3 16:59:53 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 3 Feb 2017 19:59:53 +0300 Subject: RFR : JDK-8166110 : C2 crash in compiling method handles In-Reply-To: References: Message-ID: <75453181-ecc9-2eb6-5b31-964b640dd0f0@oracle.com> The fix looks good. More detailed description of the problem: MH.invokeBasic() and MH.linkTo* signature-polymorphic are inherently unsafe. There are no type checks involved and it's user responsibility to ensure there are no type mismatches possible. They are available only to trusted code (in java.lang.invoke), which ensures the signatures always match. Unfortunately, even though type mismatches aren't possible at runtime, JIT-compilers can encounter them in paradoxical situations. It usually happens when optimizing effectively dead code. BoundMethodHandle.arg(I) demonstrates one of the problematic code shapes: final Object arg(int i) { switch (speciesData().fieldType(i)) { case L_TYPE: return speciesData().getters[i].invokeBasic(this); case I_TYPE: return (int) speciesData().getters[i].invokeBasic(this); case J_TYPE: return (long) speciesData().getters[i].invokeBasic(this); case F_TYPE: return (float) speciesData().getters[i].invokeBasic(this); case D_TYPE: return (double) speciesData().getters[i].invokeBasic(this); } If C2 can constant fold speciesData().getters[i], it will try to inline through invokeBasic() on all execution paths, though only 1 of them is taken. On all other paths the signatures won't match and it can lead to type paradoxes on IR level though the code is effectively dead. Though it was observed only with invokeBasic() and I don't see such situations is possible with MH.linkTo*(), for consistency the fix touches MH linkers as well. Best regards, Vladimir Ivanov On 2/3/17 5:19 PM, Dmitry Chuyko wrote: > Summary: some method handles can be used with actual parameters not > matching their signatures. It's too expensive to check this on call but > possible to check during inlining. Inlined MHs with wrong usage caused > further assertion failures in debug builds. The fix adds checks for > signatures match during MH inlining so it fails if they are not > matching. New test checks linkToStatic and invokeBasic cases. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166110 > > Webrev: http://cr.openjdk.java.net/~vlivanov/dchuyko/8166110/webrev.00/ > > Testing: new test, Hotspot and JDK tests, promotion benchmarks. > > Thanks, > -Dmitry > From forax at univ-mlv.fr Fri Feb 3 17:15:16 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 3 Feb 2017 18:15:16 +0100 (CET) Subject: RFR : JDK-8166110 : C2 crash in compiling method handles In-Reply-To: <75453181-ecc9-2eb6-5b31-964b640dd0f0@oracle.com> References: <75453181-ecc9-2eb6-5b31-964b640dd0f0@oracle.com> Message-ID: <329012843.2560980.1486142116263.JavaMail.zimbra@u-pem.fr> Hi Vladimir, in the long term, c2 (and c1) should be fixed to stop to inline switch branches that have never been taken, the dynamic language I currently maintain tranforms all switch to a tree of GWTs because of that, i think we will need this improvement to implement pattern matching in 10 anyway*. R?mi * apart if we introduce a custom method handle. ----- Mail original ----- > De: "Vladimir Ivanov" > ?: "Dmitry Chuyko" , hotspot-compiler-dev at openjdk.java.net > Envoy?: Vendredi 3 F?vrier 2017 17:59:53 > Objet: Re: RFR : JDK-8166110 : C2 crash in compiling method handles > The fix looks good. > > More detailed description of the problem: > > MH.invokeBasic() and MH.linkTo* signature-polymorphic are inherently > unsafe. There are no type checks involved and it's user responsibility > to ensure there are no type mismatches possible. They are available only > to trusted code (in java.lang.invoke), which ensures the signatures > always match. > > Unfortunately, even though type mismatches aren't possible at runtime, > JIT-compilers can encounter them in paradoxical situations. It usually > happens when optimizing effectively dead code. > > BoundMethodHandle.arg(I) demonstrates one of the problematic code shapes: > > final Object arg(int i) { > switch (speciesData().fieldType(i)) { > case L_TYPE: return > speciesData().getters[i].invokeBasic(this); > case I_TYPE: return (int) > speciesData().getters[i].invokeBasic(this); > case J_TYPE: return (long) > speciesData().getters[i].invokeBasic(this); > case F_TYPE: return (float) > speciesData().getters[i].invokeBasic(this); > case D_TYPE: return (double) > speciesData().getters[i].invokeBasic(this); > } > > If C2 can constant fold speciesData().getters[i], it will try to inline > through invokeBasic() on all execution paths, though only 1 of them is > taken. On all other paths the signatures won't match and it can lead to > type paradoxes on IR level though the code is effectively dead. > > Though it was observed only with invokeBasic() and I don't see such > situations is possible with MH.linkTo*(), for consistency the fix > touches MH linkers as well. > > Best regards, > Vladimir Ivanov > > On 2/3/17 5:19 PM, Dmitry Chuyko wrote: >> Summary: some method handles can be used with actual parameters not >> matching their signatures. It's too expensive to check this on call but >> possible to check during inlining. Inlined MHs with wrong usage caused >> further assertion failures in debug builds. The fix adds checks for >> signatures match during MH inlining so it fails if they are not >> matching. New test checks linkToStatic and invokeBasic cases. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166110 >> >> Webrev: http://cr.openjdk.java.net/~vlivanov/dchuyko/8166110/webrev.00/ >> >> Testing: new test, Hotspot and JDK tests, promotion benchmarks. >> >> Thanks, >> -Dmitry From vladimir.x.ivanov at oracle.com Fri Feb 3 17:29:56 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 3 Feb 2017 20:29:56 +0300 Subject: RFR : JDK-8166110 : C2 crash in compiling method handles In-Reply-To: <329012843.2560980.1486142116263.JavaMail.zimbra@u-pem.fr> References: <75453181-ecc9-2eb6-5b31-964b640dd0f0@oracle.com> <329012843.2560980.1486142116263.JavaMail.zimbra@u-pem.fr> Message-ID: <73b2d354-7773-c946-8831-d03bd8625062@oracle.com> Remi, > in the long term, c2 (and c1) should be fixed to stop to inline switch branches that have never been taken, > the dynamic language I currently maintain tranforms all switch to a tree of GWTs because of that, > i think we will need this improvement to implement pattern matching in 10 anyway*. Yes, C2 can do better when optimizing switches (e.g., [1]), but profiling information is not our friend here. Even if it says all branches are equally taken, type paradoxes arise from decisions in the context of the current compilation where only one branch is always taken at runtime. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8058192 > ----- Mail original ----- >> De: "Vladimir Ivanov" >> ?: "Dmitry Chuyko" , hotspot-compiler-dev at openjdk.java.net >> Envoy?: Vendredi 3 F?vrier 2017 17:59:53 >> Objet: Re: RFR : JDK-8166110 : C2 crash in compiling method handles > >> The fix looks good. >> >> More detailed description of the problem: >> >> MH.invokeBasic() and MH.linkTo* signature-polymorphic are inherently >> unsafe. There are no type checks involved and it's user responsibility >> to ensure there are no type mismatches possible. They are available only >> to trusted code (in java.lang.invoke), which ensures the signatures >> always match. >> >> Unfortunately, even though type mismatches aren't possible at runtime, >> JIT-compilers can encounter them in paradoxical situations. It usually >> happens when optimizing effectively dead code. >> >> BoundMethodHandle.arg(I) demonstrates one of the problematic code shapes: >> >> final Object arg(int i) { >> switch (speciesData().fieldType(i)) { >> case L_TYPE: return >> speciesData().getters[i].invokeBasic(this); >> case I_TYPE: return (int) >> speciesData().getters[i].invokeBasic(this); >> case J_TYPE: return (long) >> speciesData().getters[i].invokeBasic(this); >> case F_TYPE: return (float) >> speciesData().getters[i].invokeBasic(this); >> case D_TYPE: return (double) >> speciesData().getters[i].invokeBasic(this); >> } >> >> If C2 can constant fold speciesData().getters[i], it will try to inline >> through invokeBasic() on all execution paths, though only 1 of them is >> taken. On all other paths the signatures won't match and it can lead to >> type paradoxes on IR level though the code is effectively dead. >> >> Though it was observed only with invokeBasic() and I don't see such >> situations is possible with MH.linkTo*(), for consistency the fix >> touches MH linkers as well. >> >> Best regards, >> Vladimir Ivanov >> >> On 2/3/17 5:19 PM, Dmitry Chuyko wrote: >>> Summary: some method handles can be used with actual parameters not >>> matching their signatures. It's too expensive to check this on call but >>> possible to check during inlining. Inlined MHs with wrong usage caused >>> further assertion failures in debug builds. The fix adds checks for >>> signatures match during MH inlining so it fails if they are not >>> matching. New test checks linkToStatic and invokeBasic cases. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166110 >>> >>> Webrev: http://cr.openjdk.java.net/~vlivanov/dchuyko/8166110/webrev.00/ >>> >>> Testing: new test, Hotspot and JDK tests, promotion benchmarks. >>> >>> Thanks, >>> -Dmitry From forax at univ-mlv.fr Fri Feb 3 18:22:40 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 3 Feb 2017 19:22:40 +0100 (CET) Subject: RFR : JDK-8166110 : C2 crash in compiling method handles In-Reply-To: <73b2d354-7773-c946-8831-d03bd8625062@oracle.com> References: <75453181-ecc9-2eb6-5b31-964b640dd0f0@oracle.com> <329012843.2560980.1486142116263.JavaMail.zimbra@u-pem.fr> <73b2d354-7773-c946-8831-d03bd8625062@oracle.com> Message-ID: <596295443.2579222.1486146160537.JavaMail.zimbra@u-pem.fr> Profile information false sharing ! Again, creating a thread local storage of MethodDatas at the starts of methodHandle.invoke so you will get profile info per method handle invoke. It seems better and more general than by example the adhoc way to profile the condition of a gwt. R?mi ----- Mail original ----- > De: "Vladimir Ivanov" > ?: "Remi Forax" > Cc: hotspot-compiler-dev at openjdk.java.net > Envoy?: Vendredi 3 F?vrier 2017 18:29:56 > Objet: Re: RFR : JDK-8166110 : C2 crash in compiling method handles > Remi, > >> in the long term, c2 (and c1) should be fixed to stop to inline switch branches >> that have never been taken, >> the dynamic language I currently maintain tranforms all switch to a tree of GWTs >> because of that, >> i think we will need this improvement to implement pattern matching in 10 >> anyway*. > > Yes, C2 can do better when optimizing switches (e.g., [1]), but > profiling information is not our friend here. Even if it says all > branches are equally taken, type paradoxes arise from decisions in the > context of the current compilation where only one branch is always taken > at runtime. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8058192 > >> ----- Mail original ----- >>> De: "Vladimir Ivanov" >>> ?: "Dmitry Chuyko" , >>> hotspot-compiler-dev at openjdk.java.net >>> Envoy?: Vendredi 3 F?vrier 2017 17:59:53 >>> Objet: Re: RFR : JDK-8166110 : C2 crash in compiling method handles >> >>> The fix looks good. >>> >>> More detailed description of the problem: >>> >>> MH.invokeBasic() and MH.linkTo* signature-polymorphic are inherently >>> unsafe. There are no type checks involved and it's user responsibility >>> to ensure there are no type mismatches possible. They are available only >>> to trusted code (in java.lang.invoke), which ensures the signatures >>> always match. >>> >>> Unfortunately, even though type mismatches aren't possible at runtime, >>> JIT-compilers can encounter them in paradoxical situations. It usually >>> happens when optimizing effectively dead code. >>> >>> BoundMethodHandle.arg(I) demonstrates one of the problematic code shapes: >>> >>> final Object arg(int i) { >>> switch (speciesData().fieldType(i)) { >>> case L_TYPE: return >>> speciesData().getters[i].invokeBasic(this); >>> case I_TYPE: return (int) >>> speciesData().getters[i].invokeBasic(this); >>> case J_TYPE: return (long) >>> speciesData().getters[i].invokeBasic(this); >>> case F_TYPE: return (float) >>> speciesData().getters[i].invokeBasic(this); >>> case D_TYPE: return (double) >>> speciesData().getters[i].invokeBasic(this); >>> } >>> >>> If C2 can constant fold speciesData().getters[i], it will try to inline >>> through invokeBasic() on all execution paths, though only 1 of them is >>> taken. On all other paths the signatures won't match and it can lead to >>> type paradoxes on IR level though the code is effectively dead. >>> >>> Though it was observed only with invokeBasic() and I don't see such >>> situations is possible with MH.linkTo*(), for consistency the fix >>> touches MH linkers as well. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 2/3/17 5:19 PM, Dmitry Chuyko wrote: >>>> Summary: some method handles can be used with actual parameters not >>>> matching their signatures. It's too expensive to check this on call but >>>> possible to check during inlining. Inlined MHs with wrong usage caused >>>> further assertion failures in debug builds. The fix adds checks for >>>> signatures match during MH inlining so it fails if they are not >>>> matching. New test checks linkToStatic and invokeBasic cases. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166110 >>>> >>>> Webrev: http://cr.openjdk.java.net/~vlivanov/dchuyko/8166110/webrev.00/ >>>> >>>> Testing: new test, Hotspot and JDK tests, promotion benchmarks. >>>> >>>> Thanks, > >>> -Dmitry From vladimir.kozlov at oracle.com Fri Feb 3 18:39:42 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 3 Feb 2017 10:39:42 -0800 Subject: RFR: 8173679: Disable ProfileTrap code and UseRTMLocking in emulated client Win32 In-Reply-To: <08c3d733-d480-6b17-585b-ccfd2223bf41@oracle.com> References: <6c182c3e-8686-fc7f-6d95-5ed50ea0c4c6@oracle.com> <86a33e36-eccd-e7c2-fada-56351715dde7@oracle.com> <678852b1-d565-4132-4af7-a6c9c371d504@oracle.com> <4c793c6e-f5f9-bc15-1b19-afd635af08e3@oracle.com> <18053a1b-d10a-2f38-87e4-303d7a81c0df@oracle.com> <6c221440-13f9-7f88-8d6d-ea037c218da1@oracle.com> <8bc609d5-cfe2-035d-b530-16ea20783a10@oracle.com> <10624bf4-b625-be84-5394-ee068fb39d84@oracle.com> <08c3d733-d480-6b17-585b-ccfd2223bf41@oracle.com> Message-ID: On 2/2/17 11:47 PM, Jamsheed C m wrote: > Thank you for the review, Vladimir > > while testing i found that i missed adding @requires !vm.emulatedClient > in compiler/types/correctness/OffTest.java. i will be adding that with > this push? is that Ok ? Yes, no need to send an other RFR. Thanks, Vladimir > > Best Regards, > > Jamsheed > > On 2/3/2017 7:56 AM, Vladimir Kozlov wrote: >> This looks good. >> >> Thanks, >> Vladimir >> >> On 2/2/17 6:09 PM, Jamsheed C m wrote: >>> Hi Vladimir, >>> >>> revised webrev : >>> >>> 1) Changes to make cli tests to run on sameVM >>> >>> root part: http://cr.openjdk.java.net/~jcm/8173679/webrev.00.hs/ >>> >>> 2) Changes for, disabling mdo trap count update on deopt, and to make >>> +UseRTMLocking to exit. >>> >>> hotspot part: http://cr.openjdk.java.net/~jcm/8173679/webrev.02.hotspot/ >>> >>> Best Regards, >>> >>> Jamsheed >>> >>> On 2/2/2017 10:59 AM, Jamsheed C m wrote: >>>> Hi Vladimir, >>>> >>>> On 2/2/2017 9:20 AM, Vladimir Kozlov wrote: >>>>> >>>>> >>>>> On 2/1/17 6:19 PM, Jamsheed C m wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> On 2/2/2017 7:07 AM, Vladimir Kozlov wrote: >>>>>>> On 2/1/17 9:07 AM, Jamsheed C m wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> >>>>>>>> On 2/1/2017 10:25 PM, Vladimir Kozlov wrote: >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>>> On Feb 1, 2017, at 5:20 AM, Jamsheed C m >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> revised webrev : >>>>>>>>>> http://cr.openjdk.java.net/~jcm/8173679/webrev.01/ >>>>>>>>>> >>>>>>>>>> 1) -XX:+UseRTMLocking displays informative warning in emulate >>>>>>>>>> client mode. >>>>>>>>> Warning doesn't switch off RTM. >>>>>>>>> where you are switching it off? >>>>>>>> i am not switching it off, i am just printing warning, User should >>>>>>>> explicitly remove option. >>>>>>> >>>>>>> Then it should be not warning but error. We can't run in Client >>>>>>> mode with RTM on. Or I am missing something? >>>>>> RTM "ON" state is always user specified action. RTM is default OFF. >>>>>> from the code it says it disables BiasedLocking when >>>>>> RTM is ON and exit in client(lose both rtm + biased locking feature >>>>>> with -XX:+UseRTMLocking), i made it warning for >>>>> >>>>> Where it exits? It does not in VM_Version::use_biased_locking(). >>>> i meant normal client exits. emulated client prints warning only, it >>>> doesn't exit or change flags. >>>>> >>>>>> emulated client. as it is User specified action, User can see >>>>>> warning that Biased lock get switched off with an >>>>>> unsupported option, and remove it from his commandline. >>>>> >>>>> No, you have to explicitly call vm_exit_during_initialization() as it >>>>> was done in preceding code (!supports_rtm() && UseRTMLocking). Note, >>>>> users may ignores warnings because usually output is stored in log >>>>> files. >>>> Sure, i will do required code change , and send it for review. >>>> Best Regards, >>>> Jamsheed >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>>> Best Regards, >>>>>> Jamsheed >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Best Regards, Jamsheed >>>>>>>> >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> 2) Disabled mdo update code in deopt. >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> >>>>>>>>>> Jamsheed >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2/1/2017 11:04 AM, Jamsheed C m wrote: >>>>>>>>>>> Hi Vladimir, >>>>>>>>>>> >>>>>>>>>>>> On 2/1/2017 1:39 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>> On 1/31/17 10:37 AM, Jamsheed C m wrote: >>>>>>>>>>>>> Hi Vladimir, >>>>>>>>>>>>> >>>>>>>>>>>>> ProfileTraps is develop_pd flag, should i be changing flag >>>>>>>>>>>>> type ? >>>>>>>>>>>> No. Thinking more about this. The code guarded by ProfileTraps >>>>>>>>>>>> should be only executed when ProfileInterpreter is >>>>>>>>>>>> true. And you set ProfileInterpreter to false in client mode. >>>>>>>>>>>> Why you need these changes then? Did you hit some >>>>>>>>>>>> ProfileTraps code which is not guarded by ProfileInterpreter? >>>>>>>>>>> with ProfileTraps ON may be the trap count updation in deopt >>>>>>>>>>> pollute Runtime1::predicate_failed_trap trap count >>>>>>>>>>> and may influence the recompilation time optimization decision? >>>>>>>>>>> also create some more mdos(empty ones) in >>>>>>>>>>> exceptions ? >>>>>>>>>>> other than that i don't find any issues. >>>>>>>>>>> >>>>>>>>>>> just disabling ProfileTraps[1] in deoptimization should solve >>>>>>>>>>> first problem. second problem of creation of >>>>>>>>>>> mdos(empty ones) for exception is harmless i believe. >>>>>>>>>>> [1] if (ProfileTraps && update_trap_state && trap_mdo != NULL) { >>>>>>>>>>> >>>>>>>>>>>>> RTM test code doesn't pass VM options to spawned process, >>>>>>>>>>>>> So predicate checking process and spawned process >>>>>>>>>>>>> can be in >>>>>>>>>>>>> different modes. spawned test process is always in emulated >>>>>>>>>>>>> client mode in win32. >>>>>>>>>>>>> >>>>>>>>>>>>> the predicate checking process will be in emulated client or >>>>>>>>>>>>> server based on passed -XX:+|-TieredCompilation >>>>>>>>>>>>> option. >>>>>>>>>>>>> as a fix i disabled RTM testing completely in win32. >>>>>>>>>>>> I still do not understand why you can't use >>>>>>>>>>>> Platform.isEmulatedClient() instead of Platform.isWindows() && >>>>>>>>>>>> Platform.is32bit(). >>>>>>>>>>>> >>>>>>>>>>>> And why changes in SupportedOS.java is not enough? >>>>>>>>>>> Some tests doesn't pass vmoption to child process(cli tests). >>>>>>>>>>> so same vm tests will be running in different modes >>>>>>>>>>> ( i.e child will always run in emulated client mode, while >>>>>>>>>>> predicate checking parent process will run in server or >>>>>>>>>>> emulated client depending on option passed). so these tests >>>>>>>>>>> require change if i am changing VM behavior with >>>>>>>>>>> respect to options. >>>>>>>>>>> >>>>>>>>>>> //I would suggest to disable RTM only in client mode. // >>>>>>>>>>> >>>>>>>>>>> as per this discussion, i decided to not disable tests or vm >>>>>>>>>>> behavior, just print some harmless warning in >>>>>>>>>>> emulated client mode. >>>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> Jamsheed >>>>>>>>>>> >>>>>>>>>>>>> i will disable RTM completely in win32(both emulated client >>>>>>>>>>>>> and server). >>>>>>>>>>>> I would suggest to disable RTM only in client mode. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Jamsheed >>>>>>>>>>>>> >>>>>>>>>>>>>> On 1/31/2017 11:15 PM, Vladimir Kozlov wrote: >>>>>>>>>>>>>> Jamsheed >>>>>>>>>>>>>> >>>>>>>>>>>>>> Instead of adding check && !is_client_compilation_mode_vm() >>>>>>>>>>>>>> I think we should set ProfileTraps to false in >>>>>>>>>>>>>> client mode. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why you not using Platform.isEmulatedClient() in tests >>>>>>>>>>>>>> changes? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 1/31/17 2:44 AM, Jamsheed C m wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Code change to disable ProfileTrap and UseRTMLocking in >>>>>>>>>>>>>>> Win32 emulated client . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) ProfileTrap is code is disabled >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2) -XX:+ UseRTMLocking in win32 emulated client not >>>>>>>>>>>>>>> supported. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3) All Supported and Unsupported testcases related RTM is >>>>>>>>>>>>>>> disabled in win32. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8173679/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8173679 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Jamsheed >>>>>>>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From jamsheed.c.m at oracle.com Sun Feb 5 19:14:22 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Mon, 6 Feb 2017 00:44:22 +0530 Subject: RFR: 8170455: C2: Access to [].clone from interfaces fails In-Reply-To: <3ffc99e1-304b-044c-1b1d-450608b3dc77@oracle.com> References: <3ffc99e1-304b-044c-1b1d-450608b3dc77@oracle.com> Message-ID: Hi, Vladimir Ivanov suggested a few changes in webrev.00 1) to move class accessibility check in lookup inside assert, as it is already being done by caller once. 2) to remove changes in resolve_invoke as it is not really required. revised webrev: http://cr.openjdk.java.net/~jcm/8170455/webrev.01/ Thanks a lot for detailed review Vladimir. Best Regards, Jamsheed On 1/31/2017 3:55 PM, Jamsheed C m wrote: > Hi, > > Array type are treated as Object type in Compiler (see [1]) and > lookup happens in Object Class in compiler interface. This used to > work before default method got introduced. with default methods > protected Object methods are inaccessible from interface , so lookup > fails, caller method always deopt as unloaded and decompile in C2. > This causes considerable degradation in performance. > > Fix: array types are directly passed to lookup code(fix), all other > code is kept as it is. > > bug id: https://bugs.openjdk.java.net/browse/JDK-8170455 > > webrev: http://cr.openjdk.java.net/~jcm/8170455/webrev.00/ > > Best Regards, > > Jamsheed > > [1] > > ciInstanceKlass* > ciEnv::get_instance_klass_for_declared_method_holder(ciKlass* > method_holder) { > // For the case of .clone(), the method holder can be a > ciArrayKlass > // instead of a ciInstanceKlass. For that case simply pretend that the > // declared holder is Object.clone since that's where the call will > bottom out. > // A more correct fix would trickle out through many interfaces in CI, > // requiring ciInstanceKlass* to become ciKlass* and many more > places would > // require checks to make sure the expected type was found. Given > that this > // only occurs for clone() the more extensive fix seems like > overkill so > // instead we simply smear the array type into Object. > > > > > From doug.simon at oracle.com Mon Feb 6 09:47:36 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 6 Feb 2017 10:47:36 +0100 Subject: RFR: 8173912: [JVMCI] fix memory overhead of JVMCI Message-ID: Please review this change that fixes footprint issues in JVMCI by reducing unnecessary memory allocation and reducing the total set of permanently live objects by an order of magnitude. The changes described below have been tested with JVMCI client Graal. HotSpotVMConfigStore ==================== HotSpotVMConfigStore communicates VM configuration info from the native VM code to the Java parts of JVMCI. This change reduces the amount of data crossing this boundary significantly: - Only the VM flags currently used by JVMCI and Graal are communicated. A VM call is added as a fallback for accessing the other flags. A test for the new getFlagValue() VM call is included. - The Java object values encoding the info are canonicalized in the VM using a ResourceHashtable. - Only the VM type sizes used by JVMCI and Graal are communicated. The above changes result in reducing the memory overhead of HotSpotVMConfigStore from 904,210 to 364,742 bytes. HotSpotResolvedObjectTypeImpl ============================= This change removes or slims down a number of caches for the fields and methods in HotSpotResolvedObjectTypeImpl. For method caches, a lighter weight array is now used that only falls back to a HashMap when more than 8 methods are requested for a given type. During a JVMCI bootstrap (i.e. -XX:+BootstrapJVMCI), of 8024 HotSpotResolvedObjectTypeImpl objects created, 4156 types never have a method requested, 3353 use the array-based cache and 253 fall back to the HashMap. For fields, caching has been removed entirely since HotSpotResolvedJavaFieldImpl is such a lightweight data structure that creating a new one every time doesn?t matter. In addition, changes described below made it lighter than it previously was. Method and field names ====================== The names of HotSpotResolvedJavaFieldImpl are rarely needed, mostly only being used in debugging code. In a JVMCI bootstrap only 1490 of 154699 fields have their names accessed. As such, the HotSpotResolvedJavaFieldImpl.name field has been removed and the name is now retrieved by a VM call. Also, since fields are no longer cached, the HotSpotResolvedJavaFieldImpl.toJavaCache field storing the java.lang.reflect.Field mirror has been removed. This mirror is only ever accessed by debug code. The names of most HotSpotResolvedJavaMethodImpl are also rarely needed. In a JVMCI bootstrap only 3259 of 11267 methods have their names accessed. However, if a name is accessed once for a method, it is typically accessed numerous times. As such, the name is now stored in a lazily created cache. In addition, the isConstructor() and isClassInitializer() methods have been changed to directly compare the raw Symbol* holding the name with the vmSymbols::object_initializer_name() and vmSymbols::class_initializer_name() values respectively. This further reduces the names created in a bootstrap to ~2000. Clean up ======== There?s a small clean up in .mx.jvmci/mx_jvmci.py that removes unused functionality for zipping up the JDK after running `make images`. https://bugs.openjdk.java.net/browse/JDK-8173912 http://cr.openjdk.java.net/~dnsimon/8173912/webrev/ -Doug From vladimir.x.ivanov at oracle.com Mon Feb 6 13:52:51 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 6 Feb 2017 16:52:51 +0300 Subject: RFR: 8170455: C2: Access to [].clone from interfaces fails In-Reply-To: References: <3ffc99e1-304b-044c-1b1d-450608b3dc77@oracle.com> Message-ID: <5570d933-fb05-6871-928e-871eb41a79a0@oracle.com> > revised webrev: http://cr.openjdk.java.net/~jcm/8170455/webrev.01/ Looks good. Best regards, Vladimir Ivanov > On 1/31/2017 3:55 PM, Jamsheed C m wrote: >> Hi, >> >> Array type are treated as Object type in Compiler (see [1]) and >> lookup happens in Object Class in compiler interface. This used to >> work before default method got introduced. with default methods >> protected Object methods are inaccessible from interface , so lookup >> fails, caller method always deopt as unloaded and decompile in C2. >> This causes considerable degradation in performance. >> >> Fix: array types are directly passed to lookup code(fix), all other >> code is kept as it is. >> >> bug id: https://bugs.openjdk.java.net/browse/JDK-8170455 >> >> webrev: http://cr.openjdk.java.net/~jcm/8170455/webrev.00/ >> >> Best Regards, >> >> Jamsheed >> >> [1] >> >> ciInstanceKlass* >> ciEnv::get_instance_klass_for_declared_method_holder(ciKlass* >> method_holder) { >> // For the case of .clone(), the method holder can be a >> ciArrayKlass >> // instead of a ciInstanceKlass. For that case simply pretend that the >> // declared holder is Object.clone since that's where the call will >> bottom out. >> // A more correct fix would trickle out through many interfaces in CI, >> // requiring ciInstanceKlass* to become ciKlass* and many more >> places would >> // require checks to make sure the expected type was found. Given >> that this >> // only occurs for clone() the more extensive fix seems like >> overkill so >> // instead we simply smear the array type into Object. >> >> >> >> >> > From jamsheed.c.m at oracle.com Mon Feb 6 14:53:34 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Mon, 6 Feb 2017 20:23:34 +0530 Subject: RFR: 8170455: C2: Access to [].clone from interfaces fails In-Reply-To: <5570d933-fb05-6871-928e-871eb41a79a0@oracle.com> References: <3ffc99e1-304b-044c-1b1d-450608b3dc77@oracle.com> <5570d933-fb05-6871-928e-871eb41a79a0@oracle.com> Message-ID: <45a6ffd9-7810-3ad9-9c7c-ae70bf3ec33a@oracle.com> Thank you, Vladimir! Best Regards, Jamsheed On 2/6/2017 7:22 PM, Vladimir Ivanov wrote: >> revised webrev: http://cr.openjdk.java.net/~jcm/8170455/webrev.01/ > > Looks good. > > Best regards, > Vladimir Ivanov > >> On 1/31/2017 3:55 PM, Jamsheed C m wrote: >>> Hi, >>> >>> Array type are treated as Object type in Compiler (see [1]) and >>> lookup happens in Object Class in compiler interface. This used to >>> work before default method got introduced. with default methods >>> protected Object methods are inaccessible from interface , so lookup >>> fails, caller method always deopt as unloaded and decompile in C2. >>> This causes considerable degradation in performance. >>> >>> Fix: array types are directly passed to lookup code(fix), all other >>> code is kept as it is. >>> >>> bug id: https://bugs.openjdk.java.net/browse/JDK-8170455 >>> >>> webrev: http://cr.openjdk.java.net/~jcm/8170455/webrev.00/ >>> >>> Best Regards, >>> >>> Jamsheed >>> >>> [1] >>> >>> ciInstanceKlass* >>> ciEnv::get_instance_klass_for_declared_method_holder(ciKlass* >>> method_holder) { >>> // For the case of .clone(), the method holder can be a >>> ciArrayKlass >>> // instead of a ciInstanceKlass. For that case simply pretend >>> that the >>> // declared holder is Object.clone since that's where the call will >>> bottom out. >>> // A more correct fix would trickle out through many interfaces in >>> CI, >>> // requiring ciInstanceKlass* to become ciKlass* and many more >>> places would >>> // require checks to make sure the expected type was found. Given >>> that this >>> // only occurs for clone() the more extensive fix seems like >>> overkill so >>> // instead we simply smear the array type into Object. >>> >>> >>> >>> >>> >> From zoltan.majo at oracle.com Mon Feb 6 15:29:15 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 6 Feb 2017 16:29:15 +0100 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test Message-ID: Hi, please review the fix for 8173151. https://bugs.openjdk.java.net/browse/JDK-8173151 http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ The crash reported in the bug is caused by the corruption of the 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code heap points to an address one segment before the heap's address space. The sweeper starts iterating through the code heap from the beginning of the heap's address space. Thus, the sweeper assumes that the first item in the code heap is a HeapBlock/FreeBlock (with the appropriate length and usage information). However, that is not the case, as the first item in the heap is actually *before* the heap. So the sweeper crashes. This is a hard-to-reproduce problem (I managed to reproduce it only once in 350 iterations, each iteration taking ~25 minutes). So the fix I propose is based on core file debugging and source code investigation. But I managed to write a regression test that triggers a problem similar to the original problem. I think that problem happens because a CodeBlob allocated in one code heap (A) is returned to a different code heap (B). When the CodeBlob is returned B, it is added to B's freelist. However, as the CodeBlob was allocated in A, the freelist of B now points into A (i.e., B is corrupted). The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to determine to which code heap a 'cb' is supposed to be returned to. Since 8171008 (AOT) [1], the check is: CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { assert(cb != NULL, "CodeBlob is null"); FOR_ALL_HEAPS(heap) { - if ((*heap)->contains(cb)) { + if ((*heap)->contains(cb->code_begin())) { return *heap; } } The blob 'cb' can be returned to the wrong heap if, for example: - 'cb' is at the end code heap A and - the size of the code contained in 'cb' is 0 (therefore code_begin() returns the address after 'cb', i.e., the first address in code heap B). The fix proposes to restore CodeCache::get_code_heap() to its pre-AOT state (as I'm not aware of the reasons why AOT changed that check). I also propose to add some guarantees after allocation/deallocation in the code heap to possibly easier catch this or related problems in the future. The regression test I propose achieves the above condition and results in a crash. The regression test works only with product builds, because in a product build a BufferBlob fits into one segment whereas in a fastdebug build it does not. The test needs to set the CodeCacheMinBlockLength flag to 1. The flag is currently develop and we would need to make it product for the test to work. (Other flags controlling the code cache, e.g., CodeCacheExpansionSize, are also product.) I could also experiment with reproducing the problem with different block lengths/segment sizes, but that would most likely make the test more fragile (and CodeCacheSegmentSize is anyway develop as well). I tested the fix with JPRT, RBT is in progress. Thank you! Best regards, Zoltan [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 From tobias.hartmann at oracle.com Mon Feb 6 15:52:20 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Feb 2017 16:52:20 +0100 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: References: Message-ID: Hi Zolt?n, good catch! Here are some questions/suggestions: - Wouldn't it make sense to include an upper bound check in the guarantees as well? - I wonder why AOT changed the code to use cb->code_begin() instead of cb, maybe someone more familiar with the AOT implementation could clarify this? - I'm not sure if we should make CodeCacheMinBlockLength a product flag because we would then also need more testing with different flag values. What about making it diagnostic or experimental? Thanks, Tobias On 06.02.2017 16:29, Zolt?n Maj? wrote: > Hi, > > > please review the fix for 8173151. > > https://bugs.openjdk.java.net/browse/JDK-8173151 > http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ > > The crash reported in the bug is caused by the corruption of the 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code heap points to an address one segment before the heap's address space. The sweeper starts iterating through the code heap from the beginning of the heap's address space. Thus, the sweeper assumes that the first item in the code heap is a HeapBlock/FreeBlock (with the appropriate length and usage information). However, that is not the case, as the first item in the heap is actually *before* the heap. So the sweeper crashes. > > This is a hard-to-reproduce problem (I managed to reproduce it only once in 350 iterations, each iteration taking ~25 minutes). So the fix I propose is based on core file debugging and source code investigation. But I managed to write a regression test that triggers a problem similar to the original problem. > > I think that problem happens because a CodeBlob allocated in one code heap (A) is returned to a different code heap (B). When the CodeBlob is returned B, it is added to B's freelist. However, as the CodeBlob was allocated in A, the freelist of B now points into A (i.e., B is corrupted). > > The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to determine to which code heap a 'cb' is supposed to be returned to. Since 8171008 (AOT) [1], the check is: > > CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { > assert(cb != NULL, "CodeBlob is null"); > FOR_ALL_HEAPS(heap) { > - if ((*heap)->contains(cb)) { > + if ((*heap)->contains(cb->code_begin())) { > return *heap; > } > } > > The blob 'cb' can be returned to the wrong heap if, for example: > - 'cb' is at the end code heap A and > - the size of the code contained in 'cb' is 0 (therefore code_begin() returns the address after 'cb', i.e., the first address in code heap B). > > The fix proposes to restore CodeCache::get_code_heap() to its pre-AOT state (as I'm not aware of the reasons why AOT changed that check). I also propose to add some guarantees after allocation/deallocation in the code heap to possibly easier catch this or related problems in the future. > > The regression test I propose achieves the above condition and results in a crash. The regression test works only with product builds, because in a product build a BufferBlob fits into one segment whereas in a fastdebug build it does not. > > The test needs to set the CodeCacheMinBlockLength flag to 1. The flag is currently develop and we would need to make it product for the test to work. (Other flags controlling the code cache, e.g., CodeCacheExpansionSize, are also product.) I could also experiment with reproducing the problem with different block lengths/segment sizes, but that would most likely make the test more fragile (and CodeCacheSegmentSize is anyway develop as well). > > I tested the fix with JPRT, RBT is in progress. > > Thank you! > > Best regards, > > > Zoltan > > [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 > From zoltan.majo at oracle.com Mon Feb 6 17:18:42 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 6 Feb 2017 18:18:42 +0100 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: References: Message-ID: Hi Tobias, thank you for the feedback! On 02/06/2017 04:52 PM, Tobias Hartmann wrote: > Hi Zolt?n, > > good catch! > > Here are some questions/suggestions: > - Wouldn't it make sense to include an upper bound check in the guarantees as well? That certainly makes sense, please see the updated webrev. > - I wonder why AOT changed the code to use cb->code_begin() instead of cb, maybe someone more familiar with the AOT implementation could clarify this? As we discussed offline, it seems that AOTCompiledMethods are allocated on the C heap (instead in the code cache). That is, only the code of an AOT method is allocated in the code cache. Could somebody from the AOT team please confirm that? If the above is true, we could add a virtual method CodeBlob::blob_begin() to CodeBlob, which would return 'this'. AOTCompiledMethod would then override blob_begin() to return code_begin(). In CodeCache::get_code_heap() we would then use ...contains(cb->blob_begin()). Would that make sense? (I'm sure we can find some better for that method.) > - I'm not sure if we should make CodeCacheMinBlockLength a product flag because we would then also need more testing with different flag values. What about making it diagnostic or experimental? Let's make it diagnostic then. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8173151/webrev.01/ JPRT testing is in progress. Thank you! Best regards, Zoltan > > Thanks, > Tobias > > On 06.02.2017 16:29, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the fix for 8173151. >> >> https://bugs.openjdk.java.net/browse/JDK-8173151 >> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >> >> The crash reported in the bug is caused by the corruption of the 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code heap points to an address one segment before the heap's address space. The sweeper starts iterating through the code heap from the beginning of the heap's address space. Thus, the sweeper assumes that the first item in the code heap is a HeapBlock/FreeBlock (with the appropriate length and usage information). However, that is not the case, as the first item in the heap is actually *before* the heap. So the sweeper crashes. >> >> This is a hard-to-reproduce problem (I managed to reproduce it only once in 350 iterations, each iteration taking ~25 minutes). So the fix I propose is based on core file debugging and source code investigation. But I managed to write a regression test that triggers a problem similar to the original problem. >> >> I think that problem happens because a CodeBlob allocated in one code heap (A) is returned to a different code heap (B). When the CodeBlob is returned B, it is added to B's freelist. However, as the CodeBlob was allocated in A, the freelist of B now points into A (i.e., B is corrupted). >> >> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to determine to which code heap a 'cb' is supposed to be returned to. Since 8171008 (AOT) [1], the check is: >> >> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >> assert(cb != NULL, "CodeBlob is null"); >> FOR_ALL_HEAPS(heap) { >> - if ((*heap)->contains(cb)) { >> + if ((*heap)->contains(cb->code_begin())) { >> return *heap; >> } >> } >> >> The blob 'cb' can be returned to the wrong heap if, for example: >> - 'cb' is at the end code heap A and >> - the size of the code contained in 'cb' is 0 (therefore code_begin() returns the address after 'cb', i.e., the first address in code heap B). >> >> The fix proposes to restore CodeCache::get_code_heap() to its pre-AOT state (as I'm not aware of the reasons why AOT changed that check). I also propose to add some guarantees after allocation/deallocation in the code heap to possibly easier catch this or related problems in the future. >> >> The regression test I propose achieves the above condition and results in a crash. The regression test works only with product builds, because in a product build a BufferBlob fits into one segment whereas in a fastdebug build it does not. >> >> The test needs to set the CodeCacheMinBlockLength flag to 1. The flag is currently develop and we would need to make it product for the test to work. (Other flags controlling the code cache, e.g., CodeCacheExpansionSize, are also product.) I could also experiment with reproducing the problem with different block lengths/segment sizes, but that would most likely make the test more fragile (and CodeCacheSegmentSize is anyway develop as well). >> >> I tested the fix with JPRT, RBT is in progress. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >> From vladimir.kozlov at oracle.com Mon Feb 6 18:08:04 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Feb 2017 10:08:04 -0800 Subject: RFR: 8173912: [JVMCI] fix memory overhead of JVMCI In-Reply-To: References: Message-ID: <59643ed9-f312-ab50-1306-55836f8b8ddc@oracle.com> Hi, Doug Changes look fine. Thank you for doing this - memory consumption is real issues for Java based JIT. Did you test changes with AOT (this is what concern me most)? Thanks, Vladimir On 2/6/17 1:47 AM, Doug Simon wrote: > Please review this change that fixes footprint issues in JVMCI by reducing unnecessary memory allocation > and reducing the total set of permanently live objects by an order of magnitude. The changes described > below have been tested with JVMCI client Graal. > > HotSpotVMConfigStore > ==================== > > HotSpotVMConfigStore communicates VM configuration info from the native VM code to the Java parts of JVMCI. > This change reduces the amount of data crossing this boundary significantly: > - Only the VM flags currently used by JVMCI and Graal are communicated. A VM call is added as a > fallback for accessing the other flags. A test for the new getFlagValue() VM call is included. > - The Java object values encoding the info are canonicalized in the VM using a ResourceHashtable. > - Only the VM type sizes used by JVMCI and Graal are communicated. > The above changes result in reducing the memory overhead of HotSpotVMConfigStore from 904,210 to 364,742 bytes. > > HotSpotResolvedObjectTypeImpl > ============================= > > This change removes or slims down a number of caches for the fields and methods in HotSpotResolvedObjectTypeImpl. > > For method caches, a lighter weight array is now used that only falls back to a HashMap when more than 8 methods > are requested for a given type. During a JVMCI bootstrap (i.e. -XX:+BootstrapJVMCI), of 8024 HotSpotResolvedObjectTypeImpl > objects created, 4156 types never have a method requested, 3353 use the array-based cache and 253 fall back to > the HashMap. > > For fields, caching has been removed entirely since HotSpotResolvedJavaFieldImpl is such a lightweight data > structure that creating a new one every time doesn?t matter. In addition, changes described below made it lighter > than it previously was. > > Method and field names > ====================== > > The names of HotSpotResolvedJavaFieldImpl are rarely needed, mostly only being used in debugging code. In a JVMCI bootstrap > only 1490 of 154699 fields have their names accessed. As such, the HotSpotResolvedJavaFieldImpl.name field has been removed > and the name is now retrieved by a VM call. Also, since fields are no longer cached, the HotSpotResolvedJavaFieldImpl.toJavaCache > field storing the java.lang.reflect.Field mirror has been removed. This mirror is only ever accessed by debug code. > > The names of most HotSpotResolvedJavaMethodImpl are also rarely needed. In a JVMCI bootstrap only 3259 of 11267 methods > have their names accessed. However, if a name is accessed once for a method, it is typically accessed numerous times. As > such, the name is now stored in a lazily created cache. In addition, the isConstructor() and isClassInitializer() methods > have been changed to directly compare the raw Symbol* holding the name with the vmSymbols::object_initializer_name() and > vmSymbols::class_initializer_name() values respectively. This further reduces the names created in a bootstrap to ~2000. > > Clean up > ======== > > There?s a small clean up in .mx.jvmci/mx_jvmci.py that removes unused functionality for zipping up the JDK > after running `make images`. > > https://bugs.openjdk.java.net/browse/JDK-8173912 > http://cr.openjdk.java.net/~dnsimon/8173912/webrev/ > > -Doug > From doug.simon at oracle.com Mon Feb 6 18:32:15 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 6 Feb 2017 19:32:15 +0100 Subject: RFR: 8173912: [JVMCI] fix memory overhead of JVMCI In-Reply-To: <59643ed9-f312-ab50-1306-55836f8b8ddc@oracle.com> References: <59643ed9-f312-ab50-1306-55836f8b8ddc@oracle.com> Message-ID: <21558C7E-CB2E-4F7E-A17E-AED3EC3C2BC4@oracle.com> > On 6 Feb 2017, at 19:08, Vladimir Kozlov wrote: > > Hi, Doug > > Changes look fine. Thanks for the review. > Thank you for doing this - memory consumption is real issues for Java based JIT. Yes. We also continuing to tackle this on the Graal side. > Did you test changes with AOT (this is what concern me most)? I?ve only tested with `jprt -testset hotspot ...` so far. What should I run to test with AOT? -Doug > On 2/6/17 1:47 AM, Doug Simon wrote: >> Please review this change that fixes footprint issues in JVMCI by reducing unnecessary memory allocation >> and reducing the total set of permanently live objects by an order of magnitude. The changes described >> below have been tested with JVMCI client Graal. >> >> HotSpotVMConfigStore >> ==================== >> >> HotSpotVMConfigStore communicates VM configuration info from the native VM code to the Java parts of JVMCI. >> This change reduces the amount of data crossing this boundary significantly: >> - Only the VM flags currently used by JVMCI and Graal are communicated. A VM call is added as a >> fallback for accessing the other flags. A test for the new getFlagValue() VM call is included. >> - The Java object values encoding the info are canonicalized in the VM using a ResourceHashtable. >> - Only the VM type sizes used by JVMCI and Graal are communicated. >> The above changes result in reducing the memory overhead of HotSpotVMConfigStore from 904,210 to 364,742 bytes. >> >> HotSpotResolvedObjectTypeImpl >> ============================= >> >> This change removes or slims down a number of caches for the fields and methods in HotSpotResolvedObjectTypeImpl. >> >> For method caches, a lighter weight array is now used that only falls back to a HashMap when more than 8 methods >> are requested for a given type. During a JVMCI bootstrap (i.e. -XX:+BootstrapJVMCI), of 8024 HotSpotResolvedObjectTypeImpl >> objects created, 4156 types never have a method requested, 3353 use the array-based cache and 253 fall back to >> the HashMap. >> >> For fields, caching has been removed entirely since HotSpotResolvedJavaFieldImpl is such a lightweight data >> structure that creating a new one every time doesn?t matter. In addition, changes described below made it lighter >> than it previously was. >> >> Method and field names >> ====================== >> >> The names of HotSpotResolvedJavaFieldImpl are rarely needed, mostly only being used in debugging code. In a JVMCI bootstrap >> only 1490 of 154699 fields have their names accessed. As such, the HotSpotResolvedJavaFieldImpl.name field has been removed >> and the name is now retrieved by a VM call. Also, since fields are no longer cached, the HotSpotResolvedJavaFieldImpl.toJavaCache >> field storing the java.lang.reflect.Field mirror has been removed. This mirror is only ever accessed by debug code. >> >> The names of most HotSpotResolvedJavaMethodImpl are also rarely needed. In a JVMCI bootstrap only 3259 of 11267 methods >> have their names accessed. However, if a name is accessed once for a method, it is typically accessed numerous times. As >> such, the name is now stored in a lazily created cache. In addition, the isConstructor() and isClassInitializer() methods >> have been changed to directly compare the raw Symbol* holding the name with the vmSymbols::object_initializer_name() and >> vmSymbols::class_initializer_name() values respectively. This further reduces the names created in a bootstrap to ~2000. >> >> Clean up >> ======== >> >> There?s a small clean up in .mx.jvmci/mx_jvmci.py that removes unused functionality for zipping up the JDK >> after running `make images`. >> >> https://bugs.openjdk.java.net/browse/JDK-8173912 >> http://cr.openjdk.java.net/~dnsimon/8173912/webrev/ >> >> -Doug >> From igor.veresov at oracle.com Mon Feb 6 20:04:52 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 6 Feb 2017 12:04:52 -0800 Subject: RFR(XS) 8173673: Fix comparison input types in GraalHotSpotVMConfigNode.inlineContiguousAllocationSupported() In-Reply-To: <4f4a49bb-ea4d-f85e-f2d8-fd6a1644d24f@oracle.com> References: <0EF5CD5A-650F-4758-B64D-B51B668F24A4@oracle.com> <4f4a49bb-ea4d-f85e-f2d8-fd6a1644d24f@oracle.com> Message-ID: The change got a bit bigger after the reviews on GitHub. So, I?m revising the webrev: http://cr.openjdk.java.net/~iveresov/8173673/webrev.01/ Relevant discussion here: https://github.com/graalvm/graal-core/pull/249 Thanks, igor > On Jan 31, 2017, at 9:14 AM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 1/30/17 11:10 PM, Igor Veresov wrote: >> In GraalHotSpotVMConfigNode.inlineContiguousAllocationSupported() we need a cast because loadConfigValue() returns a long, but the node it produces has an int type. It triggers an assert. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8173673/webrev.00/ >> >> >> Thanks, >> igor >> From vladimir.kozlov at oracle.com Mon Feb 6 20:22:41 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Feb 2017 12:22:41 -0800 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: References: Message-ID: On 2/6/17 9:18 AM, Zolt?n Maj? wrote: > Hi Tobias, > > > thank you for the feedback! > > On 02/06/2017 04:52 PM, Tobias Hartmann wrote: >> Hi Zolt?n, >> >> good catch! >> >> Here are some questions/suggestions: >> - Wouldn't it make sense to include an upper bound check in the >> guarantees as well? > > That certainly makes sense, please see the updated webrev. > >> - I wonder why AOT changed the code to use cb->code_begin() instead of >> cb, maybe someone more familiar with the AOT implementation could >> clarify this? > > As we discussed offline, it seems that AOTCompiledMethods are allocated > on the C heap (instead in the code cache). That is, only the code of an > AOT method is allocated in the code cache. Could somebody from the AOT > team please confirm that? Yes, CodeBlob descriptors of AOT methods are allocated in C heap since AOT code is in RO memory (in loaded AOT library) and we can't put modifiable (addresses are unknown during AOT lib generation) CodeBlob there. It is different from nmethods where CodeBlob is "wrapper" of nmethod code in CodeCache. That is why we have to use cb->code_begin(). Sorry but your changes for get_code_heap() are incorrect for AOT code. There is an other similar code which could be problematic - CodeBlobIterator: http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8d77eb1a669d/src/share/vm/code/codeCache.hpp#l298 Note, CodeHeap::contains() is virtual and aotCodeHeap overwrite it but still accept an address. Based on usage cases (how many) we may change it to accept CodeBlob type instead of address and do appropriate checks depending on AOT or not AOT heap. Or we add an other CodeHeap method contains_blob(CodeBlob *) which do that. > > If the above is true, we could add a virtual method > CodeBlob::blob_begin() to CodeBlob, which would return 'this'. > AOTCompiledMethod would then override blob_begin() to return > code_begin(). In CodeCache::get_code_heap() we would then use > ...contains(cb->blob_begin()). Would that make sense? (I'm sure we can > find some better for that method.) We worked very hard to avoid virtual calls in AOT code since we saw performance regression when scanning code cache. So we can't do virtual calls. Thanks, Vladimir > >> - I'm not sure if we should make CodeCacheMinBlockLength a product >> flag because we would then also need more testing with different flag >> values. What about making it diagnostic or experimental? > > Let's make it diagnostic then. > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8173151/webrev.01/ > > JPRT testing is in progress. > > Thank you! > > Best regards, > > > Zoltan > >> >> Thanks, >> Tobias >> >> On 06.02.2017 16:29, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the fix for 8173151. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8173151 >>> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >>> >>> The crash reported in the bug is caused by the corruption of the >>> 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code >>> heap points to an address one segment before the heap's address >>> space. The sweeper starts iterating through the code heap from the >>> beginning of the heap's address space. Thus, the sweeper assumes that >>> the first item in the code heap is a HeapBlock/FreeBlock (with the >>> appropriate length and usage information). However, that is not the >>> case, as the first item in the heap is actually *before* the heap. So >>> the sweeper crashes. >>> >>> This is a hard-to-reproduce problem (I managed to reproduce it only >>> once in 350 iterations, each iteration taking ~25 minutes). So the >>> fix I propose is based on core file debugging and source code >>> investigation. But I managed to write a regression test that triggers >>> a problem similar to the original problem. >>> >>> I think that problem happens because a CodeBlob allocated in one code >>> heap (A) is returned to a different code heap (B). When the CodeBlob >>> is returned B, it is added to B's freelist. However, as the CodeBlob >>> was allocated in A, the freelist of B now points into A (i.e., B is >>> corrupted). >>> >>> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to >>> determine to which code heap a 'cb' is supposed to be returned to. >>> Since 8171008 (AOT) [1], the check is: >>> >>> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >>> assert(cb != NULL, "CodeBlob is null"); >>> FOR_ALL_HEAPS(heap) { >>> - if ((*heap)->contains(cb)) { >>> + if ((*heap)->contains(cb->code_begin())) { >>> return *heap; >>> } >>> } >>> >>> The blob 'cb' can be returned to the wrong heap if, for example: >>> - 'cb' is at the end code heap A and >>> - the size of the code contained in 'cb' is 0 (therefore code_begin() >>> returns the address after 'cb', i.e., the first address in code heap B). >>> >>> The fix proposes to restore CodeCache::get_code_heap() to its pre-AOT >>> state (as I'm not aware of the reasons why AOT changed that check). I >>> also propose to add some guarantees after allocation/deallocation in >>> the code heap to possibly easier catch this or related problems in >>> the future. >>> >>> The regression test I propose achieves the above condition and >>> results in a crash. The regression test works only with product >>> builds, because in a product build a BufferBlob fits into one segment >>> whereas in a fastdebug build it does not. >>> >>> The test needs to set the CodeCacheMinBlockLength flag to 1. The flag >>> is currently develop and we would need to make it product for the >>> test to work. (Other flags controlling the code cache, e.g., >>> CodeCacheExpansionSize, are also product.) I could also experiment >>> with reproducing the problem with different block lengths/segment >>> sizes, but that would most likely make the test more fragile (and >>> CodeCacheSegmentSize is anyway develop as well). >>> >>> I tested the fix with JPRT, RBT is in progress. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> [1] >>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >>> > From vladimir.kozlov at oracle.com Mon Feb 6 20:26:51 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Feb 2017 12:26:51 -0800 Subject: RFR(XS) 8173673: Fix comparison input types in GraalHotSpotVMConfigNode.inlineContiguousAllocationSupported() In-Reply-To: References: <0EF5CD5A-650F-4758-B64D-B51B668F24A4@oracle.com> <4f4a49bb-ea4d-f85e-f2d8-fd6a1644d24f@oracle.com> Message-ID: <483cab5b-a136-57d7-69bc-4151c7cbc848@oracle.com> Good. Please, list GitHub reviewers in changeset (if they have openjdk id). Thanks, Vladimir On 2/6/17 12:04 PM, Igor Veresov wrote: > The change got a bit bigger after the reviews on GitHub. > So, I?m revising the webrev: http://cr.openjdk.java.net/~iveresov/8173673/webrev.01/ > Relevant discussion here: https://github.com/graalvm/graal-core/pull/249 > > Thanks, > igor > >> On Jan 31, 2017, at 9:14 AM, Vladimir Kozlov wrote: >> >> Good. >> >> Thanks, >> Vladimir >> >> On 1/30/17 11:10 PM, Igor Veresov wrote: >>> In GraalHotSpotVMConfigNode.inlineContiguousAllocationSupported() we need a cast because loadConfigValue() returns a long, but the node it produces has an int type. It triggers an assert. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8173673/webrev.00/ >>> >>> >>> Thanks, >>> igor >>> > From igor.veresov at oracle.com Mon Feb 6 22:15:26 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 6 Feb 2017 14:15:26 -0800 Subject: RFR(XS) 8173673: Fix comparison input types in GraalHotSpotVMConfigNode.inlineContiguousAllocationSupported() In-Reply-To: <483cab5b-a136-57d7-69bc-4151c7cbc848@oracle.com> References: <0EF5CD5A-650F-4758-B64D-B51B668F24A4@oracle.com> <4f4a49bb-ea4d-f85e-f2d8-fd6a1644d24f@oracle.com> <483cab5b-a136-57d7-69bc-4151c7cbc848@oracle.com> Message-ID: <04471C51-6F22-4533-8101-2E5C29DC1A86@oracle.com> Thanks, Vladimir! igor > On Feb 6, 2017, at 12:26 PM, Vladimir Kozlov wrote: > > Good. Please, list GitHub reviewers in changeset (if they have openjdk id). > > Thanks, > Vladimir > > On 2/6/17 12:04 PM, Igor Veresov wrote: >> The change got a bit bigger after the reviews on GitHub. >> So, I?m revising the webrev: http://cr.openjdk.java.net/~iveresov/8173673/webrev.01/ >> Relevant discussion here: https://github.com/graalvm/graal-core/pull/249 >> >> Thanks, >> igor >> >>> On Jan 31, 2017, at 9:14 AM, Vladimir Kozlov wrote: >>> >>> Good. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/30/17 11:10 PM, Igor Veresov wrote: >>>> In GraalHotSpotVMConfigNode.inlineContiguousAllocationSupported() we need a cast because loadConfigValue() returns a long, but the node it produces has an int type. It triggers an assert. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8173673/webrev.00/ >>>> >>>> >>>> Thanks, >>>> igor >>>> >> From dean.long at oracle.com Mon Feb 6 23:14:08 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 6 Feb 2017 15:14:08 -0800 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: References: Message-ID: <20aa7abe-92b5-471e-a7b7-c23577a72208@oracle.com> When do we allocate a CodeBlob with a code size of 0? Is it really useful? Would having a minimum code size of 1 fix the problem? dl On 2/6/17 7:29 AM, Zolt?n Maj? wrote: > Hi, > > > please review the fix for 8173151. > > https://bugs.openjdk.java.net/browse/JDK-8173151 > http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ > > The crash reported in the bug is caused by the corruption of the > 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code > heap points to an address one segment before the heap's address space. > The sweeper starts iterating through the code heap from the beginning > of the heap's address space. Thus, the sweeper assumes that the first > item in the code heap is a HeapBlock/FreeBlock (with the appropriate > length and usage information). However, that is not the case, as the > first item in the heap is actually *before* the heap. So the sweeper > crashes. > > This is a hard-to-reproduce problem (I managed to reproduce it only > once in 350 iterations, each iteration taking ~25 minutes). So the fix > I propose is based on core file debugging and source code > investigation. But I managed to write a regression test that triggers > a problem similar to the original problem. > > I think that problem happens because a CodeBlob allocated in one code > heap (A) is returned to a different code heap (B). When the CodeBlob > is returned B, it is added to B's freelist. However, as the CodeBlob > was allocated in A, the freelist of B now points into A (i.e., B is > corrupted). > > The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to > determine to which code heap a 'cb' is supposed to be returned to. > Since 8171008 (AOT) [1], the check is: > > CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { > assert(cb != NULL, "CodeBlob is null"); > FOR_ALL_HEAPS(heap) { > - if ((*heap)->contains(cb)) { > + if ((*heap)->contains(cb->code_begin())) { > return *heap; > } > } > > The blob 'cb' can be returned to the wrong heap if, for example: > - 'cb' is at the end code heap A and > - the size of the code contained in 'cb' is 0 (therefore code_begin() > returns the address after 'cb', i.e., the first address in code heap B). > > The fix proposes to restore CodeCache::get_code_heap() to its pre-AOT > state (as I'm not aware of the reasons why AOT changed that check). I > also propose to add some guarantees after allocation/deallocation in > the code heap to possibly easier catch this or related problems in the > future. > > The regression test I propose achieves the above condition and results > in a crash. The regression test works only with product builds, > because in a product build a BufferBlob fits into one segment whereas > in a fastdebug build it does not. > > The test needs to set the CodeCacheMinBlockLength flag to 1. The flag > is currently develop and we would need to make it product for the test > to work. (Other flags controlling the code cache, e.g., > CodeCacheExpansionSize, are also product.) I could also experiment > with reproducing the problem with different block lengths/segment > sizes, but that would most likely make the test more fragile (and > CodeCacheSegmentSize is anyway develop as well). > > I tested the fix with JPRT, RBT is in progress. > > Thank you! > > Best regards, > > > Zoltan > > [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 > From tobias.hartmann at oracle.com Tue Feb 7 06:01:51 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 7 Feb 2017 07:01:51 +0100 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: <20aa7abe-92b5-471e-a7b7-c23577a72208@oracle.com> References: <20aa7abe-92b5-471e-a7b7-c23577a72208@oracle.com> Message-ID: Hi Dean, On 07.02.2017 00:14, dean.long at oracle.com wrote: > When do we allocate a CodeBlob with a code size of 0? Is it really useful? Would having a minimum code size of 1 fix the problem? Yes, I've discussed that with Zoltan offline and I agree that we should enforce a minimum code size of 1 and fix the stress test(s) accordingly. It shouldn't be necessary to be able to create regular CodeBlobs with code size 0. Best regards, Tobias > dl > > > On 2/6/17 7:29 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the fix for 8173151. >> >> https://bugs.openjdk.java.net/browse/JDK-8173151 >> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >> >> The crash reported in the bug is caused by the corruption of the 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code heap points to an address one segment before the heap's address space. The sweeper starts iterating through the code heap from the beginning of the heap's address space. Thus, the sweeper assumes that the first item in the code heap is a HeapBlock/FreeBlock (with the appropriate length and usage information). However, that is not the case, as the first item in the heap is actually *before* the heap. So the sweeper crashes. >> >> This is a hard-to-reproduce problem (I managed to reproduce it only once in 350 iterations, each iteration taking ~25 minutes). So the fix I propose is based on core file debugging and source code investigation. But I managed to write a regression test that triggers a problem similar to the original problem. >> >> I think that problem happens because a CodeBlob allocated in one code heap (A) is returned to a different code heap (B). When the CodeBlob is returned B, it is added to B's freelist. However, as the CodeBlob was allocated in A, the freelist of B now points into A (i.e., B is corrupted). >> >> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to determine to which code heap a 'cb' is supposed to be returned to. Since 8171008 (AOT) [1], the check is: >> >> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >> assert(cb != NULL, "CodeBlob is null"); >> FOR_ALL_HEAPS(heap) { >> - if ((*heap)->contains(cb)) { >> + if ((*heap)->contains(cb->code_begin())) { >> return *heap; >> } >> } >> >> The blob 'cb' can be returned to the wrong heap if, for example: >> - 'cb' is at the end code heap A and >> - the size of the code contained in 'cb' is 0 (therefore code_begin() returns the address after 'cb', i.e., the first address in code heap B). >> >> The fix proposes to restore CodeCache::get_code_heap() to its pre-AOT state (as I'm not aware of the reasons why AOT changed that check). I also propose to add some guarantees after allocation/deallocation in the code heap to possibly easier catch this or related problems in the future. >> >> The regression test I propose achieves the above condition and results in a crash. The regression test works only with product builds, because in a product build a BufferBlob fits into one segment whereas in a fastdebug build it does not. >> >> The test needs to set the CodeCacheMinBlockLength flag to 1. The flag is currently develop and we would need to make it product for the test to work. (Other flags controlling the code cache, e.g., CodeCacheExpansionSize, are also product.) I could also experiment with reproducing the problem with different block lengths/segment sizes, but that would most likely make the test more fragile (and CodeCacheSegmentSize is anyway develop as well). >> >> I tested the fix with JPRT, RBT is in progress. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >> > From zoltan.majo at oracle.com Tue Feb 7 13:17:19 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 7 Feb 2017 14:17:19 +0100 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: References: <20aa7abe-92b5-471e-a7b7-c23577a72208@oracle.com> Message-ID: <831f5002-5a2c-8f31-dd4d-feb005576ab8@oracle.com> Hi Dean, Hi Tobias, thank you for the feedback! On 02/07/2017 07:01 AM, Tobias Hartmann wrote: > Hi Dean, > > On 07.02.2017 00:14, dean.long at oracle.com wrote: >> When do we allocate a CodeBlob with a code size of 0? Is it really useful? Would having a minimum code size of 1 fix the problem? > Yes, I've discussed that with Zoltan offline and I agree that we should enforce a minimum code size of 1 and fix the stress test(s) accordingly. It shouldn't be necessary to be able to create regular CodeBlobs with code size 0. It is indeed a valid point that code sizes of 0 are not useful in practice. However, the problem is a bit more complicated than the regression test (and my description) suggests it to be. The regression test works only if CodeCacheMinBlockLength set to 1. Only that way is it possible to allocate BufferBlobs with size == 1 segment and set CodeBlob::_code_begin to point to the next segment (which is possibly in the next code heap). For both crashes I've seen, however, CodeCacheMinBlockLength was equal to 4. With that CodeCacheMinBlockLength value, every allocation in the code heap is at least 4 segments long. It is therefore impossible to create a BufferBlob whose _code_begin points "outside" of the space reserved for that BufferBlob. (Because BufferBlob::_code_begin will either point to the beginning of second segment of the BufferBlob -- with product -- or somewhere into the second segment -- with fastdebug.) Other blob types can have their _code_begin point to the boundary of 4 segments. E.g., nmethods are between 2 and 3 segments long. If the relocation information in the nmethod fills up the space to the 4 segment boundary, _code_begin will be exactly at the segment boundary. But I don't know the exact sequence of steps lead to the code heap corruption (because the crash reproduced only twice so far). I just know that the first free block in the (corrupted) code heap is of length 8 segments (the contents of the first freelist item and of the segmap both confirm this); the heap is corrupted because the freelist starts before the code heap. What sequence of steps lead to this? Some nmethod allocations/deallocations interleaved with BufferBlob allocations/deallocations (possibly of size 0)? I'm not sure. In what way were blocks in the heap merged/split by the allocations/deallocations leading to the crash? I don't know. Did allocation/deallocation of BufferBlobs of size 0 play a role at all? I don't know either and I won't be able to tell unless the problem reproduces more often. However, by using code size == 0 it is possible to write a regression test that triggers a real problem (which is hopefully related to the crashes we've been seeing). So I'd like to allow code sizes of 0 for now and attempt to fix CodeCache::get_code_heap() and the CodeBlobIterator constructor the way Vladimir suggested. If that turns out to be difficult/risky or require large code changes, I'll propose a fix instead that disallows code sizes of 1 and fixes the test(s) -- just as you suggested. Best regards, Zoltan > Best regards, > Tobias > >> dl >> >> >> On 2/6/17 7:29 AM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the fix for 8173151. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8173151 >>> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >>> >>> The crash reported in the bug is caused by the corruption of the 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code heap points to an address one segment before the heap's address space. The sweeper starts iterating through the code heap from the beginning of the heap's address space. Thus, the sweeper assumes that the first item in the code heap is a HeapBlock/FreeBlock (with the appropriate length and usage information). However, that is not the case, as the first item in the heap is actually *before* the heap. So the sweeper crashes. >>> >>> This is a hard-to-reproduce problem (I managed to reproduce it only once in 350 iterations, each iteration taking ~25 minutes). So the fix I propose is based on core file debugging and source code investigation. But I managed to write a regression test that triggers a problem similar to the original problem. >>> >>> I think that problem happens because a CodeBlob allocated in one code heap (A) is returned to a different code heap (B). When the CodeBlob is returned B, it is added to B's freelist. However, as the CodeBlob was allocated in A, the freelist of B now points into A (i.e., B is corrupted). >>> >>> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to determine to which code heap a 'cb' is supposed to be returned to. Since 8171008 (AOT) [1], the check is: >>> >>> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >>> assert(cb != NULL, "CodeBlob is null"); >>> FOR_ALL_HEAPS(heap) { >>> - if ((*heap)->contains(cb)) { >>> + if ((*heap)->contains(cb->code_begin())) { >>> return *heap; >>> } >>> } >>> >>> The blob 'cb' can be returned to the wrong heap if, for example: >>> - 'cb' is at the end code heap A and >>> - the size of the code contained in 'cb' is 0 (therefore code_begin() returns the address after 'cb', i.e., the first address in code heap B). >>> >>> The fix proposes to restore CodeCache::get_code_heap() to its pre-AOT state (as I'm not aware of the reasons why AOT changed that check). I also propose to add some guarantees after allocation/deallocation in the code heap to possibly easier catch this or related problems in the future. >>> >>> The regression test I propose achieves the above condition and results in a crash. The regression test works only with product builds, because in a product build a BufferBlob fits into one segment whereas in a fastdebug build it does not. >>> >>> The test needs to set the CodeCacheMinBlockLength flag to 1. The flag is currently develop and we would need to make it product for the test to work. (Other flags controlling the code cache, e.g., CodeCacheExpansionSize, are also product.) I could also experiment with reproducing the problem with different block lengths/segment sizes, but that would most likely make the test more fragile (and CodeCacheSegmentSize is anyway develop as well). >>> >>> I tested the fix with JPRT, RBT is in progress. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >>> From zoltan.majo at oracle.com Tue Feb 7 13:17:36 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 7 Feb 2017 14:17:36 +0100 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: References: Message-ID: Hi Vladimir, thank you for the feedback! On 02/06/2017 09:22 PM, Vladimir Kozlov wrote: > On 2/6/17 9:18 AM, Zolt?n Maj? wrote: >> [...] >> >> As we discussed offline, it seems that AOTCompiledMethods are allocated >> on the C heap (instead in the code cache). That is, only the code of an >> AOT method is allocated in the code cache. Could somebody from the AOT >> team please confirm that? > > Yes, CodeBlob descriptors of AOT methods are allocated in C heap since > AOT code is in RO memory (in loaded AOT library) and we can't put > modifiable (addresses are unknown during AOT lib generation) CodeBlob > there. > > It is different from nmethods where CodeBlob is "wrapper" of nmethod > code in CodeCache. That is why we have to use cb->code_begin(). Thank you for clarifying. > > Sorry but your changes for get_code_heap() are incorrect for AOT code. > > There is an other similar code which could be problematic - > CodeBlobIterator: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8d77eb1a669d/src/share/vm/code/codeCache.hpp#l298 > No problem, thank you for pointing me to the other code location. > > Note, CodeHeap::contains() is virtual and aotCodeHeap overwrite it but > still accept an address. Based on usage cases (how many) we may change > it to accept CodeBlob type instead of address and do appropriate > checks depending on AOT or not AOT heap. Or we add an other CodeHeap > method contains_blob(CodeBlob *) which do that. OK, I added the CodeHeap::contains_blob(CodeBlob*) virtual method, as you suggested. I updated both CodeCache::get_code_heap() and CodeBlobIterator::CodeBlobIterator() to use that method instead of the CodeHeap::contains(void*) method (which is also virtual, so we did not increase the number of virtual calls by using contains_blob()). Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8173151/webrev.02/ > >> >> If the above is true, we could add a virtual method >> CodeBlob::blob_begin() to CodeBlob, which would return 'this'. >> AOTCompiledMethod would then override blob_begin() to return >> code_begin(). In CodeCache::get_code_heap() we would then use >> ...contains(cb->blob_begin()). Would that make sense? (I'm sure we can >> find some better for that method.) > > We worked very hard to avoid virtual calls in AOT code since we saw > performance regression when scanning code cache. So we can't do > virtual calls. I see. The solution in webrev.02 above does not increase the number of virtual calls (unless I miss something, of course). I tested the new patch with JPRT, all tests pass. I'll start RBT soon. Thank you! Best regards, Zoltan > > Thanks, > Vladimir > >> >>> - I'm not sure if we should make CodeCacheMinBlockLength a product >>> flag because we would then also need more testing with different flag >>> values. What about making it diagnostic or experimental? >> >> Let's make it diagnostic then. >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8173151/webrev.01/ >> >> JPRT testing is in progress. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> Thanks, >>> Tobias >>> >>> On 06.02.2017 16:29, Zolt?n Maj? wrote: >>>> Hi, >>>> >>>> >>>> please review the fix for 8173151. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8173151 >>>> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >>>> >>>> The crash reported in the bug is caused by the corruption of the >>>> 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code >>>> heap points to an address one segment before the heap's address >>>> space. The sweeper starts iterating through the code heap from the >>>> beginning of the heap's address space. Thus, the sweeper assumes that >>>> the first item in the code heap is a HeapBlock/FreeBlock (with the >>>> appropriate length and usage information). However, that is not the >>>> case, as the first item in the heap is actually *before* the heap. So >>>> the sweeper crashes. >>>> >>>> This is a hard-to-reproduce problem (I managed to reproduce it only >>>> once in 350 iterations, each iteration taking ~25 minutes). So the >>>> fix I propose is based on core file debugging and source code >>>> investigation. But I managed to write a regression test that triggers >>>> a problem similar to the original problem. >>>> >>>> I think that problem happens because a CodeBlob allocated in one code >>>> heap (A) is returned to a different code heap (B). When the CodeBlob >>>> is returned B, it is added to B's freelist. However, as the CodeBlob >>>> was allocated in A, the freelist of B now points into A (i.e., B is >>>> corrupted). >>>> >>>> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to >>>> determine to which code heap a 'cb' is supposed to be returned to. >>>> Since 8171008 (AOT) [1], the check is: >>>> >>>> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >>>> assert(cb != NULL, "CodeBlob is null"); >>>> FOR_ALL_HEAPS(heap) { >>>> - if ((*heap)->contains(cb)) { >>>> + if ((*heap)->contains(cb->code_begin())) { >>>> return *heap; >>>> } >>>> } >>>> >>>> The blob 'cb' can be returned to the wrong heap if, for example: >>>> - 'cb' is at the end code heap A and >>>> - the size of the code contained in 'cb' is 0 (therefore code_begin() >>>> returns the address after 'cb', i.e., the first address in code >>>> heap B). >>>> >>>> The fix proposes to restore CodeCache::get_code_heap() to its pre-AOT >>>> state (as I'm not aware of the reasons why AOT changed that check). I >>>> also propose to add some guarantees after allocation/deallocation in >>>> the code heap to possibly easier catch this or related problems in >>>> the future. >>>> >>>> The regression test I propose achieves the above condition and >>>> results in a crash. The regression test works only with product >>>> builds, because in a product build a BufferBlob fits into one segment >>>> whereas in a fastdebug build it does not. >>>> >>>> The test needs to set the CodeCacheMinBlockLength flag to 1. The flag >>>> is currently develop and we would need to make it product for the >>>> test to work. (Other flags controlling the code cache, e.g., >>>> CodeCacheExpansionSize, are also product.) I could also experiment >>>> with reproducing the problem with different block lengths/segment >>>> sizes, but that would most likely make the test more fragile (and >>>> CodeCacheSegmentSize is anyway develop as well). >>>> >>>> I tested the fix with JPRT, RBT is in progress. >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >>>> >> From vladimir.kozlov at oracle.com Tue Feb 7 17:27:03 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Feb 2017 09:27:03 -0800 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: <831f5002-5a2c-8f31-dd4d-feb005576ab8@oracle.com> References: <20aa7abe-92b5-471e-a7b7-c23577a72208@oracle.com> <831f5002-5a2c-8f31-dd4d-feb005576ab8@oracle.com> Message-ID: <1aa1e66d-49e2-aec0-45bb-0b8b6334de82@oracle.com> Hi, Zoltan Is it possible that the problem exist in free list maintenance code? Ot allocation? Or free size at the end of heap calculated incorrectly when CodeBlob is allocated there and it can cross boundary? Can you look in core file that all 3 heaps have consistent start address and size so that next heap start at correct address. Like _number_of_committed_segments, _number_of_reserved_segments, _next_segment I am concern that may be there is a code which check status of next segment and use it regardless if it belong to current heap or not. Thanks, Vladimir On 2/7/17 5:17 AM, Zolt?n Maj? wrote: > Hi Dean, > Hi Tobias, > > > thank you for the feedback! > > On 02/07/2017 07:01 AM, Tobias Hartmann wrote: >> Hi Dean, >> >> On 07.02.2017 00:14, dean.long at oracle.com wrote: >>> When do we allocate a CodeBlob with a code size of 0? Is it really >>> useful? Would having a minimum code size of 1 fix the problem? >> Yes, I've discussed that with Zoltan offline and I agree that we >> should enforce a minimum code size of 1 and fix the stress test(s) >> accordingly. It shouldn't be necessary to be able to create regular >> CodeBlobs with code size 0. > > It is indeed a valid point that code sizes of 0 are not useful in practice. > > However, the problem is a bit more complicated than the regression test > (and my description) suggests it to be. The regression test works only > if CodeCacheMinBlockLength set to 1. Only that way is it possible to > allocate BufferBlobs with size == 1 segment and set > CodeBlob::_code_begin to point to the next segment (which is possibly in > the next code heap). > > For both crashes I've seen, however, CodeCacheMinBlockLength was equal > to 4. With that CodeCacheMinBlockLength value, every allocation in the > code heap is at least 4 segments long. It is therefore impossible to > create a BufferBlob whose _code_begin points "outside" of the space > reserved for that BufferBlob. (Because BufferBlob::_code_begin will > either point to the beginning of second segment of the BufferBlob -- > with product -- or somewhere into the second segment -- with fastdebug.) > > Other blob types can have their _code_begin point to the boundary of 4 > segments. E.g., nmethods are between 2 and 3 segments long. If the > relocation information in the nmethod fills up the space to the 4 > segment boundary, _code_begin will be exactly at the segment boundary. > > But I don't know the exact sequence of steps lead to the code heap > corruption (because the crash reproduced only twice so far). I just > know that the first free block in the (corrupted) code heap is of length > 8 segments (the contents of the first freelist item and of the segmap > both confirm this); the heap is corrupted because the freelist starts > before the code heap. > > What sequence of steps lead to this? Some nmethod > allocations/deallocations interleaved with BufferBlob > allocations/deallocations (possibly of size 0)? I'm not sure. In what > way were blocks in the heap merged/split by the > allocations/deallocations leading to the crash? I don't know. > > Did allocation/deallocation of BufferBlobs of size 0 play a role at > all? I don't know either and I won't be able to tell unless the problem > reproduces more often. However, by using code size == 0 it is possible > to write a regression test that triggers a real problem (which is > hopefully related to the crashes we've been seeing). > > So I'd like to allow code sizes of 0 for now and attempt to fix > CodeCache::get_code_heap() and the CodeBlobIterator constructor the way > Vladimir suggested. If that turns out to be difficult/risky or require > large code changes, I'll propose a fix instead that disallows code sizes > of 1 and fixes the test(s) -- just as you suggested. > > Best regards, > > > Zoltan > >> Best regards, >> Tobias >> >>> dl >>> >>> >>> On 2/6/17 7:29 AM, Zolt?n Maj? wrote: >>>> Hi, >>>> >>>> >>>> please review the fix for 8173151. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8173151 >>>> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >>>> >>>> The crash reported in the bug is caused by the corruption of the >>>> 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code >>>> heap points to an address one segment before the heap's address >>>> space. The sweeper starts iterating through the code heap from the >>>> beginning of the heap's address space. Thus, the sweeper assumes >>>> that the first item in the code heap is a HeapBlock/FreeBlock (with >>>> the appropriate length and usage information). However, that is not >>>> the case, as the first item in the heap is actually *before* the >>>> heap. So the sweeper crashes. >>>> >>>> This is a hard-to-reproduce problem (I managed to reproduce it only >>>> once in 350 iterations, each iteration taking ~25 minutes). So the >>>> fix I propose is based on core file debugging and source code >>>> investigation. But I managed to write a regression test that >>>> triggers a problem similar to the original problem. >>>> >>>> I think that problem happens because a CodeBlob allocated in one >>>> code heap (A) is returned to a different code heap (B). When the >>>> CodeBlob is returned B, it is added to B's freelist. However, as the >>>> CodeBlob was allocated in A, the freelist of B now points into A >>>> (i.e., B is corrupted). >>>> >>>> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to >>>> determine to which code heap a 'cb' is supposed to be returned to. >>>> Since 8171008 (AOT) [1], the check is: >>>> >>>> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >>>> assert(cb != NULL, "CodeBlob is null"); >>>> FOR_ALL_HEAPS(heap) { >>>> - if ((*heap)->contains(cb)) { >>>> + if ((*heap)->contains(cb->code_begin())) { >>>> return *heap; >>>> } >>>> } >>>> >>>> The blob 'cb' can be returned to the wrong heap if, for example: >>>> - 'cb' is at the end code heap A and >>>> - the size of the code contained in 'cb' is 0 (therefore >>>> code_begin() returns the address after 'cb', i.e., the first address >>>> in code heap B). >>>> >>>> The fix proposes to restore CodeCache::get_code_heap() to its >>>> pre-AOT state (as I'm not aware of the reasons why AOT changed that >>>> check). I also propose to add some guarantees after >>>> allocation/deallocation in the code heap to possibly easier catch >>>> this or related problems in the future. >>>> >>>> The regression test I propose achieves the above condition and >>>> results in a crash. The regression test works only with product >>>> builds, because in a product build a BufferBlob fits into one >>>> segment whereas in a fastdebug build it does not. >>>> >>>> The test needs to set the CodeCacheMinBlockLength flag to 1. The >>>> flag is currently develop and we would need to make it product for >>>> the test to work. (Other flags controlling the code cache, e.g., >>>> CodeCacheExpansionSize, are also product.) I could also experiment >>>> with reproducing the problem with different block lengths/segment >>>> sizes, but that would most likely make the test more fragile (and >>>> CodeCacheSegmentSize is anyway develop as well). >>>> >>>> I tested the fix with JPRT, RBT is in progress. >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >>>> > From vladimir.kozlov at oracle.com Tue Feb 7 18:08:49 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Feb 2017 10:08:49 -0800 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: References: Message-ID: Yes, this looks good. I think it is good to push this first and see if we hit this problem again later. The problem could be related to segmented codecache and how we manipulate free and used segments. So the fix may not solve it but at least it will close one issue you found. Thanks, Vladimir On 2/7/17 5:17 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > thank you for the feedback! > > On 02/06/2017 09:22 PM, Vladimir Kozlov wrote: >> On 2/6/17 9:18 AM, Zolt?n Maj? wrote: >>> [...] >>> >>> As we discussed offline, it seems that AOTCompiledMethods are allocated >>> on the C heap (instead in the code cache). That is, only the code of an >>> AOT method is allocated in the code cache. Could somebody from the AOT >>> team please confirm that? >> >> Yes, CodeBlob descriptors of AOT methods are allocated in C heap since >> AOT code is in RO memory (in loaded AOT library) and we can't put >> modifiable (addresses are unknown during AOT lib generation) CodeBlob >> there. >> >> It is different from nmethods where CodeBlob is "wrapper" of nmethod >> code in CodeCache. That is why we have to use cb->code_begin(). > > Thank you for clarifying. > >> >> Sorry but your changes for get_code_heap() are incorrect for AOT code. >> >> There is an other similar code which could be problematic - >> CodeBlobIterator: >> >> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8d77eb1a669d/src/share/vm/code/codeCache.hpp#l298 >> > > No problem, thank you for pointing me to the other code location. > >> >> Note, CodeHeap::contains() is virtual and aotCodeHeap overwrite it but >> still accept an address. Based on usage cases (how many) we may change >> it to accept CodeBlob type instead of address and do appropriate >> checks depending on AOT or not AOT heap. Or we add an other CodeHeap >> method contains_blob(CodeBlob *) which do that. > > OK, I added the CodeHeap::contains_blob(CodeBlob*) virtual method, as > you suggested. I updated both CodeCache::get_code_heap() and > CodeBlobIterator::CodeBlobIterator() to use that method instead of the > CodeHeap::contains(void*) method (which is also virtual, so we did not > increase the number of virtual calls by using contains_blob()). > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8173151/webrev.02/ > >> >>> >>> If the above is true, we could add a virtual method >>> CodeBlob::blob_begin() to CodeBlob, which would return 'this'. >>> AOTCompiledMethod would then override blob_begin() to return >>> code_begin(). In CodeCache::get_code_heap() we would then use >>> ...contains(cb->blob_begin()). Would that make sense? (I'm sure we can >>> find some better for that method.) >> >> We worked very hard to avoid virtual calls in AOT code since we saw >> performance regression when scanning code cache. So we can't do >> virtual calls. > > I see. The solution in webrev.02 above does not increase the number of > virtual calls (unless I miss something, of course). > > I tested the new patch with JPRT, all tests pass. I'll start RBT soon. > > Thank you! > > Best regards, > > > Zoltan > >> >> Thanks, >> Vladimir >> >>> >>>> - I'm not sure if we should make CodeCacheMinBlockLength a product >>>> flag because we would then also need more testing with different flag >>>> values. What about making it diagnostic or experimental? >>> >>> Let's make it diagnostic then. >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~zmajo/8173151/webrev.01/ >>> >>> JPRT testing is in progress. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 06.02.2017 16:29, Zolt?n Maj? wrote: >>>>> Hi, >>>>> >>>>> >>>>> please review the fix for 8173151. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8173151 >>>>> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >>>>> >>>>> The crash reported in the bug is caused by the corruption of the >>>>> 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code >>>>> heap points to an address one segment before the heap's address >>>>> space. The sweeper starts iterating through the code heap from the >>>>> beginning of the heap's address space. Thus, the sweeper assumes that >>>>> the first item in the code heap is a HeapBlock/FreeBlock (with the >>>>> appropriate length and usage information). However, that is not the >>>>> case, as the first item in the heap is actually *before* the heap. So >>>>> the sweeper crashes. >>>>> >>>>> This is a hard-to-reproduce problem (I managed to reproduce it only >>>>> once in 350 iterations, each iteration taking ~25 minutes). So the >>>>> fix I propose is based on core file debugging and source code >>>>> investigation. But I managed to write a regression test that triggers >>>>> a problem similar to the original problem. >>>>> >>>>> I think that problem happens because a CodeBlob allocated in one code >>>>> heap (A) is returned to a different code heap (B). When the CodeBlob >>>>> is returned B, it is added to B's freelist. However, as the CodeBlob >>>>> was allocated in A, the freelist of B now points into A (i.e., B is >>>>> corrupted). >>>>> >>>>> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to >>>>> determine to which code heap a 'cb' is supposed to be returned to. >>>>> Since 8171008 (AOT) [1], the check is: >>>>> >>>>> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >>>>> assert(cb != NULL, "CodeBlob is null"); >>>>> FOR_ALL_HEAPS(heap) { >>>>> - if ((*heap)->contains(cb)) { >>>>> + if ((*heap)->contains(cb->code_begin())) { >>>>> return *heap; >>>>> } >>>>> } >>>>> >>>>> The blob 'cb' can be returned to the wrong heap if, for example: >>>>> - 'cb' is at the end code heap A and >>>>> - the size of the code contained in 'cb' is 0 (therefore code_begin() >>>>> returns the address after 'cb', i.e., the first address in code >>>>> heap B). >>>>> >>>>> The fix proposes to restore CodeCache::get_code_heap() to its pre-AOT >>>>> state (as I'm not aware of the reasons why AOT changed that check). I >>>>> also propose to add some guarantees after allocation/deallocation in >>>>> the code heap to possibly easier catch this or related problems in >>>>> the future. >>>>> >>>>> The regression test I propose achieves the above condition and >>>>> results in a crash. The regression test works only with product >>>>> builds, because in a product build a BufferBlob fits into one segment >>>>> whereas in a fastdebug build it does not. >>>>> >>>>> The test needs to set the CodeCacheMinBlockLength flag to 1. The flag >>>>> is currently develop and we would need to make it product for the >>>>> test to work. (Other flags controlling the code cache, e.g., >>>>> CodeCacheExpansionSize, are also product.) I could also experiment >>>>> with reproducing the problem with different block lengths/segment >>>>> sizes, but that would most likely make the test more fragile (and >>>>> CodeCacheSegmentSize is anyway develop as well). >>>>> >>>>> I tested the fix with JPRT, RBT is in progress. >>>>> >>>>> Thank you! >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >>>>> >>> > From zoltan.majo at oracle.com Wed Feb 8 09:18:29 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Feb 2017 10:18:29 +0100 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: References: Message-ID: <09f20f5f-810f-a965-4cdb-02d72abddc34@oracle.com> Hi Vladimir, On 02/07/2017 07:08 PM, Vladimir Kozlov wrote: > Yes, this looks good. thank you (and also Dean and Tobias) for the review. > > I think it is good to push this first and see if we hit this problem > again later. The problem could be related to segmented codecache and > how we manipulate free and used segments. So the fix may not solve it > but at least it will close one issue you found. OK, I'll push this once I have the results of RBT testing available and they look good. I'm also wondering if we hit this (or a similar problem) later. Maybe the guarantees added with the patch will help to get a better understanding of the problem later on. Thank you! Best regards, Zoltan > > Thanks, > Vladimir > > On 2/7/17 5:17 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> thank you for the feedback! >> >> On 02/06/2017 09:22 PM, Vladimir Kozlov wrote: >>> On 2/6/17 9:18 AM, Zolt?n Maj? wrote: >>>> [...] >>>> >>>> As we discussed offline, it seems that AOTCompiledMethods are >>>> allocated >>>> on the C heap (instead in the code cache). That is, only the code >>>> of an >>>> AOT method is allocated in the code cache. Could somebody from the AOT >>>> team please confirm that? >>> >>> Yes, CodeBlob descriptors of AOT methods are allocated in C heap since >>> AOT code is in RO memory (in loaded AOT library) and we can't put >>> modifiable (addresses are unknown during AOT lib generation) CodeBlob >>> there. >>> >>> It is different from nmethods where CodeBlob is "wrapper" of nmethod >>> code in CodeCache. That is why we have to use cb->code_begin(). >> >> Thank you for clarifying. >> >>> >>> Sorry but your changes for get_code_heap() are incorrect for AOT code. >>> >>> There is an other similar code which could be problematic - >>> CodeBlobIterator: >>> >>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/8d77eb1a669d/src/share/vm/code/codeCache.hpp#l298 >>> >>> >> >> No problem, thank you for pointing me to the other code location. >> >>> >>> Note, CodeHeap::contains() is virtual and aotCodeHeap overwrite it but >>> still accept an address. Based on usage cases (how many) we may change >>> it to accept CodeBlob type instead of address and do appropriate >>> checks depending on AOT or not AOT heap. Or we add an other CodeHeap >>> method contains_blob(CodeBlob *) which do that. >> >> OK, I added the CodeHeap::contains_blob(CodeBlob*) virtual method, as >> you suggested. I updated both CodeCache::get_code_heap() and >> CodeBlobIterator::CodeBlobIterator() to use that method instead of the >> CodeHeap::contains(void*) method (which is also virtual, so we did not >> increase the number of virtual calls by using contains_blob()). >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~zmajo/8173151/webrev.02/ >> >>> >>>> >>>> If the above is true, we could add a virtual method >>>> CodeBlob::blob_begin() to CodeBlob, which would return 'this'. >>>> AOTCompiledMethod would then override blob_begin() to return >>>> code_begin(). In CodeCache::get_code_heap() we would then use >>>> ...contains(cb->blob_begin()). Would that make sense? (I'm sure we can >>>> find some better for that method.) >>> >>> We worked very hard to avoid virtual calls in AOT code since we saw >>> performance regression when scanning code cache. So we can't do >>> virtual calls. >> >> I see. The solution in webrev.02 above does not increase the number of >> virtual calls (unless I miss something, of course). >> >> I tested the new patch with JPRT, all tests pass. I'll start RBT soon. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>>> - I'm not sure if we should make CodeCacheMinBlockLength a product >>>>> flag because we would then also need more testing with different flag >>>>> values. What about making it diagnostic or experimental? >>>> >>>> Let's make it diagnostic then. >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~zmajo/8173151/webrev.01/ >>>> >>>> JPRT testing is in progress. >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> On 06.02.2017 16:29, Zolt?n Maj? wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> please review the fix for 8173151. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8173151 >>>>>> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >>>>>> >>>>>> The crash reported in the bug is caused by the corruption of the >>>>>> 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code >>>>>> heap points to an address one segment before the heap's address >>>>>> space. The sweeper starts iterating through the code heap from the >>>>>> beginning of the heap's address space. Thus, the sweeper assumes >>>>>> that >>>>>> the first item in the code heap is a HeapBlock/FreeBlock (with the >>>>>> appropriate length and usage information). However, that is not the >>>>>> case, as the first item in the heap is actually *before* the >>>>>> heap. So >>>>>> the sweeper crashes. >>>>>> >>>>>> This is a hard-to-reproduce problem (I managed to reproduce it only >>>>>> once in 350 iterations, each iteration taking ~25 minutes). So the >>>>>> fix I propose is based on core file debugging and source code >>>>>> investigation. But I managed to write a regression test that >>>>>> triggers >>>>>> a problem similar to the original problem. >>>>>> >>>>>> I think that problem happens because a CodeBlob allocated in one >>>>>> code >>>>>> heap (A) is returned to a different code heap (B). When the CodeBlob >>>>>> is returned B, it is added to B's freelist. However, as the CodeBlob >>>>>> was allocated in A, the freelist of B now points into A (i.e., B is >>>>>> corrupted). >>>>>> >>>>>> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to >>>>>> determine to which code heap a 'cb' is supposed to be returned to. >>>>>> Since 8171008 (AOT) [1], the check is: >>>>>> >>>>>> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >>>>>> assert(cb != NULL, "CodeBlob is null"); >>>>>> FOR_ALL_HEAPS(heap) { >>>>>> - if ((*heap)->contains(cb)) { >>>>>> + if ((*heap)->contains(cb->code_begin())) { >>>>>> return *heap; >>>>>> } >>>>>> } >>>>>> >>>>>> The blob 'cb' can be returned to the wrong heap if, for example: >>>>>> - 'cb' is at the end code heap A and >>>>>> - the size of the code contained in 'cb' is 0 (therefore >>>>>> code_begin() >>>>>> returns the address after 'cb', i.e., the first address in code >>>>>> heap B). >>>>>> >>>>>> The fix proposes to restore CodeCache::get_code_heap() to its >>>>>> pre-AOT >>>>>> state (as I'm not aware of the reasons why AOT changed that >>>>>> check). I >>>>>> also propose to add some guarantees after allocation/deallocation in >>>>>> the code heap to possibly easier catch this or related problems in >>>>>> the future. >>>>>> >>>>>> The regression test I propose achieves the above condition and >>>>>> results in a crash. The regression test works only with product >>>>>> builds, because in a product build a BufferBlob fits into one >>>>>> segment >>>>>> whereas in a fastdebug build it does not. >>>>>> >>>>>> The test needs to set the CodeCacheMinBlockLength flag to 1. The >>>>>> flag >>>>>> is currently develop and we would need to make it product for the >>>>>> test to work. (Other flags controlling the code cache, e.g., >>>>>> CodeCacheExpansionSize, are also product.) I could also experiment >>>>>> with reproducing the problem with different block lengths/segment >>>>>> sizes, but that would most likely make the test more fragile (and >>>>>> CodeCacheSegmentSize is anyway develop as well). >>>>>> >>>>>> I tested the fix with JPRT, RBT is in progress. >>>>>> >>>>>> Thank you! >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >>>>>> >>>>>> >>>> >> From zoltan.majo at oracle.com Wed Feb 8 12:39:35 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 8 Feb 2017 13:39:35 +0100 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: <1aa1e66d-49e2-aec0-45bb-0b8b6334de82@oracle.com> References: <20aa7abe-92b5-471e-a7b7-c23577a72208@oracle.com> <831f5002-5a2c-8f31-dd4d-feb005576ab8@oracle.com> <1aa1e66d-49e2-aec0-45bb-0b8b6334de82@oracle.com> Message-ID: <58f47c52-9e6d-9b9f-d40b-963fd92d70a3@oracle.com> Hi Vladimir, On 02/07/2017 06:27 PM, Vladimir Kozlov wrote: > Hi, Zoltan > > Is it possible that the problem exist in free list maintenance code? > Ot allocation? > > Or free size at the end of heap calculated incorrectly when CodeBlob > is allocated there and it can cross boundary? I'm not sure. AOT did not change allocation / free list management code. It only changed CodeCache::get_code_heap() to use cb->code_begin() instead of cb directly. Also, the failure with RandomAllocationTest appeared only after AOT was pushed. Otherwise code cache management was not changed recently and we've been running RandomAllocationTest for two years now. That makes it likely that we would have hit this issue earlier. > > Can you look in core file that all 3 heaps have consistent start > address and size so that next heap start at correct address. Like > _number_of_committed_segments, _number_of_reserved_segments, > _next_segment > > I am concern that may be there is a code which check status of next > segment and use it regardless if it belong to current heap or not. Thank you for your suggestions! The test failed with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 and AOT disabled. So there are only two heaps. Here is the information for about both: (1) non-profiled nmethods heap CodeHeap 'non-profiled nmethods': size=238384Kb used=178496Kb max_used=224080Kb free=59887Kb bounds [0x000000011b20c000, 0x0000000129ad8000, 0x0000000129ad8000] Length of segment: 0xE8CC000 = 0x1D1980 segments _next_segment: 0x00000000001d13e6 -- < 0x1D1980 so within current heap _number_of_committed_segments: 0x00000000001d1980 -- OK _number_of_reserved_segments: 0x00000000001d1980 -- OK _freelist_segments: 0x00000000000749e1 -- < 0x1D1980 so fits into current heap _freelist: 0x000000011b20bf80 -- points into other code heap (2) non nmethod code heap CodeHeap 'non-nmethods': size=7376Kb used=5822Kb max_used=7376Kb free=1553Kb bounds [0x000000011aad8000, 0x000000011b20c000, 0x000000011b20c000] Length of segment: 0x734000 = 0xe680 segments -- OK _next_segment: 0x000000000000e680 -- size of current heap _number_of_committed_segments: 0x000000000000e680 -- size of current heap _number_of_reserved_segments: 0x000000000000e680 -- size of current heap _freelist_segments: 0x000000000000308d -- < 0xe680 so fits into current heap _freelist: 0x000000011ada6780 -- points into the current code heap There are two (possibly) suspicious elements: - For (1), the _freelist points to into (2) -- we've discussed this before. - For (2), _next_segment, _number_of_committed_segments, and _number_of_reserved_segments is equal to the size of the code heap. That is, _next_segment of (2) points into (1). So I checked places where _next_segment is modified. Other than cases when _next_segment is initialized to 0, only CodeHeap::allocate() changes _next_segment. http://hg.openjdk.java.net/jdk9/hs/hotspot/file/9b2ab23d5676/src/share/vm/memory/heap.cpp#l202 But I don't think an allocation can cause the code heap to overflow there. An overflow would imply that - (a) the number of committed segments is equal to the size of the memory space reserved for the code heap (in segments) and - (b) the newly allocated block points to (or after) _number_of_committed_segments. We can return a block pointing to _number_of_committed_segments if _next_segment==_number_of_committed_segments and number_of_segments <= 0 so that the condition _next_segment + number_of_segments <= _number_of_committed_segments holds. But we have an assert before that checks that number_of_segments >= sizeof(FreeBlock) (which is in turn > 0). Unfortunately, I don't see other ways the heap can become corrupted. But let's hope the guarantees the patch plans to add help catch this problem in the future (in case the patch does not already fix the problem). Thank you! Best regards, Zoltan > > Thanks, > Vladimir > > On 2/7/17 5:17 AM, Zolt?n Maj? wrote: >> Hi Dean, >> Hi Tobias, >> >> >> thank you for the feedback! >> >> On 02/07/2017 07:01 AM, Tobias Hartmann wrote: >>> Hi Dean, >>> >>> On 07.02.2017 00:14, dean.long at oracle.com wrote: >>>> When do we allocate a CodeBlob with a code size of 0? Is it really >>>> useful? Would having a minimum code size of 1 fix the problem? >>> Yes, I've discussed that with Zoltan offline and I agree that we >>> should enforce a minimum code size of 1 and fix the stress test(s) >>> accordingly. It shouldn't be necessary to be able to create regular >>> CodeBlobs with code size 0. >> >> It is indeed a valid point that code sizes of 0 are not useful in >> practice. >> >> However, the problem is a bit more complicated than the regression test >> (and my description) suggests it to be. The regression test works only >> if CodeCacheMinBlockLength set to 1. Only that way is it possible to >> allocate BufferBlobs with size == 1 segment and set >> CodeBlob::_code_begin to point to the next segment (which is possibly in >> the next code heap). >> >> For both crashes I've seen, however, CodeCacheMinBlockLength was equal >> to 4. With that CodeCacheMinBlockLength value, every allocation in the >> code heap is at least 4 segments long. It is therefore impossible to >> create a BufferBlob whose _code_begin points "outside" of the space >> reserved for that BufferBlob. (Because BufferBlob::_code_begin will >> either point to the beginning of second segment of the BufferBlob -- >> with product -- or somewhere into the second segment -- with fastdebug.) >> >> Other blob types can have their _code_begin point to the boundary of 4 >> segments. E.g., nmethods are between 2 and 3 segments long. If the >> relocation information in the nmethod fills up the space to the 4 >> segment boundary, _code_begin will be exactly at the segment boundary. >> >> But I don't know the exact sequence of steps lead to the code heap >> corruption (because the crash reproduced only twice so far). I just >> know that the first free block in the (corrupted) code heap is of length >> 8 segments (the contents of the first freelist item and of the segmap >> both confirm this); the heap is corrupted because the freelist starts >> before the code heap. >> >> What sequence of steps lead to this? Some nmethod >> allocations/deallocations interleaved with BufferBlob >> allocations/deallocations (possibly of size 0)? I'm not sure. In what >> way were blocks in the heap merged/split by the >> allocations/deallocations leading to the crash? I don't know. >> >> Did allocation/deallocation of BufferBlobs of size 0 play a role at >> all? I don't know either and I won't be able to tell unless the problem >> reproduces more often. However, by using code size == 0 it is possible >> to write a regression test that triggers a real problem (which is >> hopefully related to the crashes we've been seeing). >> >> So I'd like to allow code sizes of 0 for now and attempt to fix >> CodeCache::get_code_heap() and the CodeBlobIterator constructor the way >> Vladimir suggested. If that turns out to be difficult/risky or require >> large code changes, I'll propose a fix instead that disallows code sizes >> of 1 and fixes the test(s) -- just as you suggested. >> >> Best regards, >> >> >> Zoltan >> >>> Best regards, >>> Tobias >>> >>>> dl >>>> >>>> >>>> On 2/6/17 7:29 AM, Zolt?n Maj? wrote: >>>>> Hi, >>>>> >>>>> >>>>> please review the fix for 8173151. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8173151 >>>>> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >>>>> >>>>> The crash reported in the bug is caused by the corruption of the >>>>> 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code >>>>> heap points to an address one segment before the heap's address >>>>> space. The sweeper starts iterating through the code heap from the >>>>> beginning of the heap's address space. Thus, the sweeper assumes >>>>> that the first item in the code heap is a HeapBlock/FreeBlock (with >>>>> the appropriate length and usage information). However, that is not >>>>> the case, as the first item in the heap is actually *before* the >>>>> heap. So the sweeper crashes. >>>>> >>>>> This is a hard-to-reproduce problem (I managed to reproduce it only >>>>> once in 350 iterations, each iteration taking ~25 minutes). So the >>>>> fix I propose is based on core file debugging and source code >>>>> investigation. But I managed to write a regression test that >>>>> triggers a problem similar to the original problem. >>>>> >>>>> I think that problem happens because a CodeBlob allocated in one >>>>> code heap (A) is returned to a different code heap (B). When the >>>>> CodeBlob is returned B, it is added to B's freelist. However, as the >>>>> CodeBlob was allocated in A, the freelist of B now points into A >>>>> (i.e., B is corrupted). >>>>> >>>>> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to >>>>> determine to which code heap a 'cb' is supposed to be returned to. >>>>> Since 8171008 (AOT) [1], the check is: >>>>> >>>>> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >>>>> assert(cb != NULL, "CodeBlob is null"); >>>>> FOR_ALL_HEAPS(heap) { >>>>> - if ((*heap)->contains(cb)) { >>>>> + if ((*heap)->contains(cb->code_begin())) { >>>>> return *heap; >>>>> } >>>>> } >>>>> >>>>> The blob 'cb' can be returned to the wrong heap if, for example: >>>>> - 'cb' is at the end code heap A and >>>>> - the size of the code contained in 'cb' is 0 (therefore >>>>> code_begin() returns the address after 'cb', i.e., the first address >>>>> in code heap B). >>>>> >>>>> The fix proposes to restore CodeCache::get_code_heap() to its >>>>> pre-AOT state (as I'm not aware of the reasons why AOT changed that >>>>> check). I also propose to add some guarantees after >>>>> allocation/deallocation in the code heap to possibly easier catch >>>>> this or related problems in the future. >>>>> >>>>> The regression test I propose achieves the above condition and >>>>> results in a crash. The regression test works only with product >>>>> builds, because in a product build a BufferBlob fits into one >>>>> segment whereas in a fastdebug build it does not. >>>>> >>>>> The test needs to set the CodeCacheMinBlockLength flag to 1. The >>>>> flag is currently develop and we would need to make it product for >>>>> the test to work. (Other flags controlling the code cache, e.g., >>>>> CodeCacheExpansionSize, are also product.) I could also experiment >>>>> with reproducing the problem with different block lengths/segment >>>>> sizes, but that would most likely make the test more fragile (and >>>>> CodeCacheSegmentSize is anyway develop as well). >>>>> >>>>> I tested the fix with JPRT, RBT is in progress. >>>>> >>>>> Thank you! >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >>>>> >> From rwestrel at redhat.com Wed Feb 8 15:18:11 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 08 Feb 2017 16:18:11 +0100 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops Message-ID: http://cr.openjdk.java.net/~roland/8174164/webrev.00/ Handling of SafePointNode::_replaced_nodes is incompatible with irreducible loops: replaced nodes can be propagated and applied before all predecessor blocks (on a path to method entry) are processed which can lead to a broken graph. This was observed by one of our customers (crash in the compiler). The compilation in that case is an OSR compilation: OSR compilations can cause irreducible loops even if the methods that are compiled have no irreducible loops. The test case is an example of that. Note that this test case doesn't cause a compiler crash with 9 but it does with 8: with 8 static_field() returns a CheckCastPP of a constant to an interface but with 9 and because of 8076094, the CheckCastPP is optimized out (the checkCastPP of a constant is needed to have the same node when the replaced node is recorded and at the call return where replacement happens). Reverting 8076094 in 9 is enough to trigger the problem. Anyway, I intend to have this backported to 8 so I think the test case still has value. The solution I propose is to only consider nodes allocated in callees as candidates for replacement on method exit: on method exit, the risk is that the caller which is not fully parsed has an irreducible loop. The callee is fully parsed so even if it has an irreducible loop, there's no risk of breaking the graph. Roland. From rwestrel at redhat.com Wed Feb 8 15:58:35 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 08 Feb 2017 16:58:35 +0100 Subject: RFR(XS) [10]: 8174199: ci replay doesn't reallocate static final field of recorded klass Message-ID: http://cr.openjdk.java.net/~roland/8174199/webrev.00/ On failure, ci replay records the actual type of a static final field (when it's an instance) but on replay, it doesn't allocate a static final field of that type but of the signature type instead. Roland. From vladimir.kozlov at oracle.com Wed Feb 8 18:33:35 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 8 Feb 2017 10:33:35 -0800 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: <58f47c52-9e6d-9b9f-d40b-963fd92d70a3@oracle.com> References: <20aa7abe-92b5-471e-a7b7-c23577a72208@oracle.com> <831f5002-5a2c-8f31-dd4d-feb005576ab8@oracle.com> <1aa1e66d-49e2-aec0-45bb-0b8b6334de82@oracle.com> <58f47c52-9e6d-9b9f-d40b-963fd92d70a3@oracle.com> Message-ID: <02f4aa0f-fe2f-a0c7-8f85-28f87b1ad2f7@oracle.com> Thank you for looking on this, Zoltan > Also, the failure with RandomAllocationTest appeared only after AOT was > pushed. Otherwise code cache management was not changed recently and > we've been running RandomAllocationTest for two years now. That makes it > likely that we would have hit this issue earlier. Good point. Looking on the RandomAllocationTest test and it uses Random to generate size of CodeBlob and indeed could be 0 (+ header size). So lets hope this change fix the problem. Thanks, Vladimir On 2/8/17 4:39 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > On 02/07/2017 06:27 PM, Vladimir Kozlov wrote: >> Hi, Zoltan >> >> Is it possible that the problem exist in free list maintenance code? >> Ot allocation? >> >> Or free size at the end of heap calculated incorrectly when CodeBlob >> is allocated there and it can cross boundary? > > I'm not sure. AOT did not change allocation / free list management code. > It only changed CodeCache::get_code_heap() to use cb->code_begin() > instead of cb directly. > > Also, the failure with RandomAllocationTest appeared only after AOT was > pushed. Otherwise code cache management was not changed recently and > we've been running RandomAllocationTest for two years now. That makes it > likely that we would have hit this issue earlier. > >> >> Can you look in core file that all 3 heaps have consistent start >> address and size so that next heap start at correct address. Like >> _number_of_committed_segments, _number_of_reserved_segments, >> _next_segment >> >> I am concern that may be there is a code which check status of next >> segment and use it regardless if it belong to current heap or not. > > Thank you for your suggestions! > > The test failed with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 and > AOT disabled. So there are only two heaps. Here is the information for > about both: > > > (1) non-profiled nmethods heap > > CodeHeap 'non-profiled nmethods': size=238384Kb used=178496Kb > max_used=224080Kb free=59887Kb > bounds [0x000000011b20c000, 0x0000000129ad8000, 0x0000000129ad8000] > > Length of segment: 0xE8CC000 = 0x1D1980 segments > > _next_segment: 0x00000000001d13e6 -- < 0x1D1980 > so within current heap > _number_of_committed_segments: 0x00000000001d1980 -- OK > _number_of_reserved_segments: 0x00000000001d1980 -- OK > _freelist_segments: 0x00000000000749e1 -- < 0x1D1980 > so fits into current heap > _freelist: 0x000000011b20bf80 -- points > into other code heap > > > (2) non nmethod code heap > > CodeHeap 'non-nmethods': size=7376Kb used=5822Kb max_used=7376Kb > free=1553Kb > bounds [0x000000011aad8000, 0x000000011b20c000, 0x000000011b20c000] > > Length of segment: 0x734000 = 0xe680 segments -- OK > > _next_segment: 0x000000000000e680 -- size of > current heap > _number_of_committed_segments: 0x000000000000e680 -- size of > current heap > _number_of_reserved_segments: 0x000000000000e680 -- size of > current heap > _freelist_segments: 0x000000000000308d -- < 0xe680 > so fits into current heap > _freelist: 0x000000011ada6780 -- points > into the current code heap > > > There are two (possibly) suspicious elements: > - For (1), the _freelist points to into (2) -- we've discussed this before. > - For (2), _next_segment, _number_of_committed_segments, and > _number_of_reserved_segments is equal to the size of the code heap. That > is, _next_segment of (2) points into (1). > > So I checked places where _next_segment is modified. Other than cases > when _next_segment is initialized to 0, only CodeHeap::allocate() > changes _next_segment. > > http://hg.openjdk.java.net/jdk9/hs/hotspot/file/9b2ab23d5676/src/share/vm/memory/heap.cpp#l202 > > > But I don't think an allocation can cause the code heap to overflow > there. An overflow would imply that > - (a) the number of committed segments is equal to the size of the > memory space reserved for the code heap (in segments) and > - (b) the newly allocated block points to (or after) > _number_of_committed_segments. > > We can return a block pointing to _number_of_committed_segments if > _next_segment==_number_of_committed_segments and number_of_segments <= 0 > so that the condition > > _next_segment + number_of_segments <= _number_of_committed_segments > > holds. But we have an assert before that checks that number_of_segments >>= sizeof(FreeBlock) (which is in turn > 0). > > Unfortunately, I don't see other ways the heap can become corrupted. But > let's hope the guarantees the patch plans to add help catch this problem > in the future (in case the patch does not already fix the problem). > > Thank you! > > Best regards, > > > Zoltan > > >> >> Thanks, >> Vladimir >> >> On 2/7/17 5:17 AM, Zolt?n Maj? wrote: >>> Hi Dean, >>> Hi Tobias, >>> >>> >>> thank you for the feedback! >>> >>> On 02/07/2017 07:01 AM, Tobias Hartmann wrote: >>>> Hi Dean, >>>> >>>> On 07.02.2017 00:14, dean.long at oracle.com wrote: >>>>> When do we allocate a CodeBlob with a code size of 0? Is it really >>>>> useful? Would having a minimum code size of 1 fix the problem? >>>> Yes, I've discussed that with Zoltan offline and I agree that we >>>> should enforce a minimum code size of 1 and fix the stress test(s) >>>> accordingly. It shouldn't be necessary to be able to create regular >>>> CodeBlobs with code size 0. >>> >>> It is indeed a valid point that code sizes of 0 are not useful in >>> practice. >>> >>> However, the problem is a bit more complicated than the regression test >>> (and my description) suggests it to be. The regression test works only >>> if CodeCacheMinBlockLength set to 1. Only that way is it possible to >>> allocate BufferBlobs with size == 1 segment and set >>> CodeBlob::_code_begin to point to the next segment (which is possibly in >>> the next code heap). >>> >>> For both crashes I've seen, however, CodeCacheMinBlockLength was equal >>> to 4. With that CodeCacheMinBlockLength value, every allocation in the >>> code heap is at least 4 segments long. It is therefore impossible to >>> create a BufferBlob whose _code_begin points "outside" of the space >>> reserved for that BufferBlob. (Because BufferBlob::_code_begin will >>> either point to the beginning of second segment of the BufferBlob -- >>> with product -- or somewhere into the second segment -- with fastdebug.) >>> >>> Other blob types can have their _code_begin point to the boundary of 4 >>> segments. E.g., nmethods are between 2 and 3 segments long. If the >>> relocation information in the nmethod fills up the space to the 4 >>> segment boundary, _code_begin will be exactly at the segment boundary. >>> >>> But I don't know the exact sequence of steps lead to the code heap >>> corruption (because the crash reproduced only twice so far). I just >>> know that the first free block in the (corrupted) code heap is of length >>> 8 segments (the contents of the first freelist item and of the segmap >>> both confirm this); the heap is corrupted because the freelist starts >>> before the code heap. >>> >>> What sequence of steps lead to this? Some nmethod >>> allocations/deallocations interleaved with BufferBlob >>> allocations/deallocations (possibly of size 0)? I'm not sure. In what >>> way were blocks in the heap merged/split by the >>> allocations/deallocations leading to the crash? I don't know. >>> >>> Did allocation/deallocation of BufferBlobs of size 0 play a role at >>> all? I don't know either and I won't be able to tell unless the problem >>> reproduces more often. However, by using code size == 0 it is possible >>> to write a regression test that triggers a real problem (which is >>> hopefully related to the crashes we've been seeing). >>> >>> So I'd like to allow code sizes of 0 for now and attempt to fix >>> CodeCache::get_code_heap() and the CodeBlobIterator constructor the way >>> Vladimir suggested. If that turns out to be difficult/risky or require >>> large code changes, I'll propose a fix instead that disallows code sizes >>> of 1 and fixes the test(s) -- just as you suggested. >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>>> Best regards, >>>> Tobias >>>> >>>>> dl >>>>> >>>>> >>>>> On 2/6/17 7:29 AM, Zolt?n Maj? wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> please review the fix for 8173151. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8173151 >>>>>> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >>>>>> >>>>>> The crash reported in the bug is caused by the corruption of the >>>>>> 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code >>>>>> heap points to an address one segment before the heap's address >>>>>> space. The sweeper starts iterating through the code heap from the >>>>>> beginning of the heap's address space. Thus, the sweeper assumes >>>>>> that the first item in the code heap is a HeapBlock/FreeBlock (with >>>>>> the appropriate length and usage information). However, that is not >>>>>> the case, as the first item in the heap is actually *before* the >>>>>> heap. So the sweeper crashes. >>>>>> >>>>>> This is a hard-to-reproduce problem (I managed to reproduce it only >>>>>> once in 350 iterations, each iteration taking ~25 minutes). So the >>>>>> fix I propose is based on core file debugging and source code >>>>>> investigation. But I managed to write a regression test that >>>>>> triggers a problem similar to the original problem. >>>>>> >>>>>> I think that problem happens because a CodeBlob allocated in one >>>>>> code heap (A) is returned to a different code heap (B). When the >>>>>> CodeBlob is returned B, it is added to B's freelist. However, as the >>>>>> CodeBlob was allocated in A, the freelist of B now points into A >>>>>> (i.e., B is corrupted). >>>>>> >>>>>> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to >>>>>> determine to which code heap a 'cb' is supposed to be returned to. >>>>>> Since 8171008 (AOT) [1], the check is: >>>>>> >>>>>> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >>>>>> assert(cb != NULL, "CodeBlob is null"); >>>>>> FOR_ALL_HEAPS(heap) { >>>>>> - if ((*heap)->contains(cb)) { >>>>>> + if ((*heap)->contains(cb->code_begin())) { >>>>>> return *heap; >>>>>> } >>>>>> } >>>>>> >>>>>> The blob 'cb' can be returned to the wrong heap if, for example: >>>>>> - 'cb' is at the end code heap A and >>>>>> - the size of the code contained in 'cb' is 0 (therefore >>>>>> code_begin() returns the address after 'cb', i.e., the first address >>>>>> in code heap B). >>>>>> >>>>>> The fix proposes to restore CodeCache::get_code_heap() to its >>>>>> pre-AOT state (as I'm not aware of the reasons why AOT changed that >>>>>> check). I also propose to add some guarantees after >>>>>> allocation/deallocation in the code heap to possibly easier catch >>>>>> this or related problems in the future. >>>>>> >>>>>> The regression test I propose achieves the above condition and >>>>>> results in a crash. The regression test works only with product >>>>>> builds, because in a product build a BufferBlob fits into one >>>>>> segment whereas in a fastdebug build it does not. >>>>>> >>>>>> The test needs to set the CodeCacheMinBlockLength flag to 1. The >>>>>> flag is currently develop and we would need to make it product for >>>>>> the test to work. (Other flags controlling the code cache, e.g., >>>>>> CodeCacheExpansionSize, are also product.) I could also experiment >>>>>> with reproducing the problem with different block lengths/segment >>>>>> sizes, but that would most likely make the test more fragile (and >>>>>> CodeCacheSegmentSize is anyway develop as well). >>>>>> >>>>>> I tested the fix with JPRT, RBT is in progress. >>>>>> >>>>>> Thank you! >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >>>>>> >>> > From vladimir.kozlov at oracle.com Wed Feb 8 18:39:47 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 8 Feb 2017 10:39:47 -0800 Subject: RFR(XS) [10]: 8174199: ci replay doesn't reallocate static final field of recorded klass In-Reply-To: References: Message-ID: Looks good. Thank you for finding and fixing this. It looks like it was typo - field_signature was used instead of string_value. Vladimir On 2/8/17 7:58 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8174199/webrev.00/ > > On failure, ci replay records the actual type of a static final field > (when it's an instance) but on replay, it doesn't allocate a static > final field of that type but of the signature type instead. > > Roland. > From vladimir.kozlov at oracle.com Wed Feb 8 18:54:39 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 8 Feb 2017 10:54:39 -0800 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: Message-ID: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> What happens if Identity() was used for replacement and as result new node would exist and its idx < _new_idx? Or replacing nodes list records only new nodes? Also what happens for the rest of replacing nodes on the list? Thanks, Vladimir On 2/8/17 7:18 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8174164/webrev.00/ > > Handling of SafePointNode::_replaced_nodes is incompatible with > irreducible loops: replaced nodes can be propagated and applied before > all predecessor blocks (on a path to method entry) are processed which > can lead to a broken graph. > > This was observed by one of our customers (crash in the compiler). The > compilation in that case is an OSR compilation: OSR compilations can > cause irreducible loops even if the methods that are compiled have no > irreducible loops. The test case is an example of that. Note that this > test case doesn't cause a compiler crash with 9 but it does with 8: with > 8 static_field() returns a CheckCastPP of a constant to an interface but > with 9 and because of 8076094, the CheckCastPP is optimized out (the > checkCastPP of a constant is needed to have the same node when the > replaced node is recorded and at the call return where replacement > happens). Reverting 8076094 in 9 is enough to trigger the > problem. Anyway, I intend to have this backported to 8 so I think the > test case still has value. > > The solution I propose is to only consider nodes allocated in callees as > candidates for replacement on method exit: on method exit, the risk is > that the caller which is not fully parsed has an irreducible loop. The > callee is fully parsed so even if it has an irreducible loop, there's no > risk of breaking the graph. > > Roland. > From rwestrel at redhat.com Wed Feb 8 19:40:25 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 08 Feb 2017 20:40:25 +0100 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> Message-ID: Hi Vladimir, Thanks for looking at this. > What happens if Identity() was used for replacement and as result new > node would exist and its idx < _new_idx? Or replacing nodes list records > only new nodes? To put that back in context, the replaced node stuff was added so castnodes would propagate from callees to callers. Most castnodes are control dependent so Identity transforming the node sounds unlikely. Anyway, if that happens, then when the nodes are "replaced" (when parsing is over for a method), those nodes would be ignored. All nodes are recorded but only new nodes are considered. > Also what happens for the rest of replacing nodes on the list? They stay on the list. I suppose I could prune the list when it's propagated from a callee to a caller. Roland. From vladimir.kozlov at oracle.com Wed Feb 8 21:13:37 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 8 Feb 2017 13:13:37 -0800 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> Message-ID: <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> On 2/8/17 11:40 AM, Roland Westrelin wrote: > > Hi Vladimir, > > Thanks for looking at this. > >> What happens if Identity() was used for replacement and as result new >> node would exist and its idx < _new_idx? Or replacing nodes list records >> only new nodes? > > To put that back in context, the replaced node stuff was added so > castnodes would propagate from callees to callers. Most castnodes are > control dependent so Identity transforming the node sounds > unlikely. Anyway, if that happens, then when the nodes are "replaced" > (when parsing is over for a method), those nodes would be ignored. All > nodes are recorded but only new nodes are considered. Okay. > >> Also what happens for the rest of replacing nodes on the list? > > They stay on the list. I suppose I could prune the list when it's > propagated from a callee to a caller. Can you put old nodes pruned from list on IGVN list so they have chance to be optimized later? Thanks, Vladimir > > Roland. > From rwestrel at redhat.com Thu Feb 9 08:58:42 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 09 Feb 2017 09:58:42 +0100 Subject: RFR(XS) [10]: 8174199: ci replay doesn't reallocate static final field of recorded klass In-Reply-To: References: Message-ID: Thanks for reviewing this, Vladimir. Anyone to sponsor it? Roland. From tobias.hartmann at oracle.com Thu Feb 9 09:35:27 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 9 Feb 2017 10:35:27 +0100 Subject: RFR(XS) [10]: 8174199: ci replay doesn't reallocate static final field of recorded klass In-Reply-To: References: Message-ID: Hi Roland, On 09.02.2017 09:58, Roland Westrelin wrote: > > Thanks for reviewing this, Vladimir. Anyone to sponsor it? I can sponsor it, please send me the changeset. Best regards, Tobias From rwestrel at redhat.com Thu Feb 9 09:38:45 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 09 Feb 2017 10:38:45 +0100 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> Message-ID: >>> Also what happens for the rest of replacing nodes on the list? >> >> They stay on the list. I suppose I could prune the list when it's >> propagated from a callee to a caller. > > Can you put old nodes pruned from list on IGVN list so they have chance > to be optimized later? Actually, no, thinking more about this, I don't see how the list can be pruned more than it is today. The code collects (initial, improved) pairs of nodes every time replace_in_map is called. Then, at parse time, on method exit, the list of pairs is passed to the caller and nodes on the current safepoint state are replaced. ReplacedNodes::transfer_from() already has some pruning (pairs for which initial is a new node in a callee are not passed to the caller). I don't see what other nodes can be removed because we're sure they can't be candidates for replacement in callers. I don't think wether improved is new in a callee tells us anything about whether it can be replaced in a caller or not. Also, I don't think I understand why we would want to push nodes on the igvn list: assuming all those nodes are control dependent CheckCastPP or CastPP nodes, why do we think they can be optimized further at this point? Roland. From vladimir.kozlov at oracle.com Thu Feb 9 18:56:11 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 9 Feb 2017 10:56:11 -0800 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> Message-ID: On 2/9/17 1:38 AM, Roland Westrelin wrote: > >>>> Also what happens for the rest of replacing nodes on the list? >>> >>> They stay on the list. I suppose I could prune the list when it's >>> propagated from a callee to a caller. >> >> Can you put old nodes pruned from list on IGVN list so they have chance >> to be optimized later? > > Actually, no, thinking more about this, I don't see how the list can be > pruned more than it is today. The code collects (initial, improved) > pairs of nodes every time replace_in_map is called. Then, at parse time, > on method exit, the list of pairs is passed to the caller and nodes on > the current safepoint state are replaced. ReplacedNodes::transfer_from() > already has some pruning (pairs for which initial is a new node in a > callee are not passed to the caller). I don't see what other nodes can > be removed because we're sure they can't be candidates for replacement > in callers. I don't think wether improved is new in a callee tells us > anything about whether it can be replaced in a caller or not. Also, I > don't think I understand why we would want to push nodes on the igvn > list: assuming all those nodes are control dependent CheckCastPP or > CastPP nodes, why do we think they can be optimized further at this > point? The scenario I am concern with is next. Assuming that replacement happened in callee, for example, due to class check where one branch will go into UNC Trap. But at the same time node representing klass constant (CheckCastPP) is already present in caller (used for an other not related nodes). As result you will get 'improved' node as old node and it will not pass your new condition. So what happens in such case? Will we able to make replacement? Vladimir > > Roland. > From rwestrel at redhat.com Thu Feb 9 19:31:49 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 09 Feb 2017 20:31:49 +0100 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> Message-ID: > The scenario I am concern with is next. Assuming that replacement > happened in callee, for example, due to class check where one branch > will go into UNC Trap. But at the same time node representing klass > constant (CheckCastPP) is already present in caller (used for an other > not related nodes). As result you will get 'improved' node as old node > and it will not pass your new condition. So what happens in such case? > Will we able to make replacement? If the CheckCastPP is in the caller, then replace_in_map replaces the input of the CheckCastPP with the CheckCastPP in the caller's map. That improvement is done before the callee is called so is valid in the callee too. When parsing exits the callee, no replacement happens (CheckCastPP is not a new node in the callee) but there shouldn't be any to do because replace_in_map already modified the caller's map before the callee was parsed. When parsing exits the caller, replacement happens in the caller's caller map (the CheckCastPP is a new node). So the caller's caller, the caller and the callee should all see the improved nodes, right? Roland. From vladimir.kozlov at oracle.com Thu Feb 9 20:11:55 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 9 Feb 2017 12:11:55 -0800 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> Message-ID: <4c95c8ef-0252-91a2-3b46-b0315ed2284a@oracle.com> Hmm, may be you are right. I was thinking about value numbering due to the same hash value. But to have the same hash the input should be the same and it should be replaced in caller already as you said. May be different branch? But then has includes control edge too. Then in what cases your new check (_idx >= idx) fails? Vladimir On 2/9/17 11:31 AM, Roland Westrelin wrote: > >> The scenario I am concern with is next. Assuming that replacement >> happened in callee, for example, due to class check where one branch >> will go into UNC Trap. But at the same time node representing klass >> constant (CheckCastPP) is already present in caller (used for an other >> not related nodes). As result you will get 'improved' node as old node >> and it will not pass your new condition. So what happens in such case? >> Will we able to make replacement? > > If the CheckCastPP is in the caller, then replace_in_map replaces the > input of the CheckCastPP with the CheckCastPP in the caller's map. That > improvement is done before the callee is called so is valid in the > callee too. When parsing exits the callee, no replacement happens > (CheckCastPP is not a new node in the callee) but there shouldn't be any > to do because replace_in_map already modified the caller's map before > the callee was parsed. When parsing exits the caller, replacement > happens in the caller's caller map (the CheckCastPP is a new node). So > the caller's caller, the caller and the callee should all see the > improved nodes, right? > > Roland. > From zoltan.majo at oracle.com Fri Feb 10 07:24:02 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Feb 2017 08:24:02 +0100 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: <02f4aa0f-fe2f-a0c7-8f85-28f87b1ad2f7@oracle.com> References: <20aa7abe-92b5-471e-a7b7-c23577a72208@oracle.com> <831f5002-5a2c-8f31-dd4d-feb005576ab8@oracle.com> <1aa1e66d-49e2-aec0-45bb-0b8b6334de82@oracle.com> <58f47c52-9e6d-9b9f-d40b-963fd92d70a3@oracle.com> <02f4aa0f-fe2f-a0c7-8f85-28f87b1ad2f7@oracle.com> Message-ID: On 02/08/2017 07:33 PM, Vladimir Kozlov wrote: > Thank you for looking on this, Zoltan > > > Also, the failure with RandomAllocationTest appeared only after AOT was > > pushed. Otherwise code cache management was not changed recently and > > we've been running RandomAllocationTest for two years now. That > makes it > > likely that we would have hit this issue earlier. > > Good point. > > Looking on the RandomAllocationTest test and it uses Random to > generate size of CodeBlob and indeed could be 0 (+ header size). So > lets hope this change fix the problem. Thank you, Vladimir! Best regards, Zoltan > > Thanks, > Vladimir > > On 2/8/17 4:39 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> On 02/07/2017 06:27 PM, Vladimir Kozlov wrote: >>> Hi, Zoltan >>> >>> Is it possible that the problem exist in free list maintenance code? >>> Ot allocation? >>> >>> Or free size at the end of heap calculated incorrectly when CodeBlob >>> is allocated there and it can cross boundary? >> >> I'm not sure. AOT did not change allocation / free list management code. >> It only changed CodeCache::get_code_heap() to use cb->code_begin() >> instead of cb directly. >> >> Also, the failure with RandomAllocationTest appeared only after AOT was >> pushed. Otherwise code cache management was not changed recently and >> we've been running RandomAllocationTest for two years now. That makes it >> likely that we would have hit this issue earlier. >> >>> >>> Can you look in core file that all 3 heaps have consistent start >>> address and size so that next heap start at correct address. Like >>> _number_of_committed_segments, _number_of_reserved_segments, >>> _next_segment >>> >>> I am concern that may be there is a code which check status of next >>> segment and use it regardless if it belong to current heap or not. >> >> Thank you for your suggestions! >> >> The test failed with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 and >> AOT disabled. So there are only two heaps. Here is the information for >> about both: >> >> >> (1) non-profiled nmethods heap >> >> CodeHeap 'non-profiled nmethods': size=238384Kb used=178496Kb >> max_used=224080Kb free=59887Kb >> bounds [0x000000011b20c000, 0x0000000129ad8000, 0x0000000129ad8000] >> >> Length of segment: 0xE8CC000 = 0x1D1980 segments >> >> _next_segment: 0x00000000001d13e6 -- < 0x1D1980 >> so within current heap >> _number_of_committed_segments: 0x00000000001d1980 -- OK >> _number_of_reserved_segments: 0x00000000001d1980 -- OK >> _freelist_segments: 0x00000000000749e1 -- < 0x1D1980 >> so fits into current heap >> _freelist: 0x000000011b20bf80 -- points >> into other code heap >> >> >> (2) non nmethod code heap >> >> CodeHeap 'non-nmethods': size=7376Kb used=5822Kb max_used=7376Kb >> free=1553Kb >> bounds [0x000000011aad8000, 0x000000011b20c000, 0x000000011b20c000] >> >> Length of segment: 0x734000 = 0xe680 segments -- OK >> >> _next_segment: 0x000000000000e680 -- size of >> current heap >> _number_of_committed_segments: 0x000000000000e680 -- size of >> current heap >> _number_of_reserved_segments: 0x000000000000e680 -- size of >> current heap >> _freelist_segments: 0x000000000000308d -- < 0xe680 >> so fits into current heap >> _freelist: 0x000000011ada6780 -- points >> into the current code heap >> >> >> There are two (possibly) suspicious elements: >> - For (1), the _freelist points to into (2) -- we've discussed this >> before. >> - For (2), _next_segment, _number_of_committed_segments, and >> _number_of_reserved_segments is equal to the size of the code heap. That >> is, _next_segment of (2) points into (1). >> >> So I checked places where _next_segment is modified. Other than cases >> when _next_segment is initialized to 0, only CodeHeap::allocate() >> changes _next_segment. >> >> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/9b2ab23d5676/src/share/vm/memory/heap.cpp#l202 >> >> >> >> But I don't think an allocation can cause the code heap to overflow >> there. An overflow would imply that >> - (a) the number of committed segments is equal to the size of the >> memory space reserved for the code heap (in segments) and >> - (b) the newly allocated block points to (or after) >> _number_of_committed_segments. >> >> We can return a block pointing to _number_of_committed_segments if >> _next_segment==_number_of_committed_segments and number_of_segments <= 0 >> so that the condition >> >> _next_segment + number_of_segments <= _number_of_committed_segments >> >> holds. But we have an assert before that checks that number_of_segments >>> = sizeof(FreeBlock) (which is in turn > 0). >> >> Unfortunately, I don't see other ways the heap can become corrupted. But >> let's hope the guarantees the patch plans to add help catch this problem >> in the future (in case the patch does not already fix the problem). >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> >>> >>> Thanks, >>> Vladimir >>> >>> On 2/7/17 5:17 AM, Zolt?n Maj? wrote: >>>> Hi Dean, >>>> Hi Tobias, >>>> >>>> >>>> thank you for the feedback! >>>> >>>> On 02/07/2017 07:01 AM, Tobias Hartmann wrote: >>>>> Hi Dean, >>>>> >>>>> On 07.02.2017 00:14, dean.long at oracle.com wrote: >>>>>> When do we allocate a CodeBlob with a code size of 0? Is it really >>>>>> useful? Would having a minimum code size of 1 fix the problem? >>>>> Yes, I've discussed that with Zoltan offline and I agree that we >>>>> should enforce a minimum code size of 1 and fix the stress test(s) >>>>> accordingly. It shouldn't be necessary to be able to create regular >>>>> CodeBlobs with code size 0. >>>> >>>> It is indeed a valid point that code sizes of 0 are not useful in >>>> practice. >>>> >>>> However, the problem is a bit more complicated than the regression >>>> test >>>> (and my description) suggests it to be. The regression test works >>>> only >>>> if CodeCacheMinBlockLength set to 1. Only that way is it possible to >>>> allocate BufferBlobs with size == 1 segment and set >>>> CodeBlob::_code_begin to point to the next segment (which is >>>> possibly in >>>> the next code heap). >>>> >>>> For both crashes I've seen, however, CodeCacheMinBlockLength was equal >>>> to 4. With that CodeCacheMinBlockLength value, every allocation in >>>> the >>>> code heap is at least 4 segments long. It is therefore impossible to >>>> create a BufferBlob whose _code_begin points "outside" of the space >>>> reserved for that BufferBlob. (Because BufferBlob::_code_begin will >>>> either point to the beginning of second segment of the BufferBlob -- >>>> with product -- or somewhere into the second segment -- with >>>> fastdebug.) >>>> >>>> Other blob types can have their _code_begin point to the boundary of 4 >>>> segments. E.g., nmethods are between 2 and 3 segments long. If the >>>> relocation information in the nmethod fills up the space to the 4 >>>> segment boundary, _code_begin will be exactly at the segment boundary. >>>> >>>> But I don't know the exact sequence of steps lead to the code heap >>>> corruption (because the crash reproduced only twice so far). I just >>>> know that the first free block in the (corrupted) code heap is of >>>> length >>>> 8 segments (the contents of the first freelist item and of the segmap >>>> both confirm this); the heap is corrupted because the freelist starts >>>> before the code heap. >>>> >>>> What sequence of steps lead to this? Some nmethod >>>> allocations/deallocations interleaved with BufferBlob >>>> allocations/deallocations (possibly of size 0)? I'm not sure. In >>>> what >>>> way were blocks in the heap merged/split by the >>>> allocations/deallocations leading to the crash? I don't know. >>>> >>>> Did allocation/deallocation of BufferBlobs of size 0 play a role at >>>> all? I don't know either and I won't be able to tell unless the >>>> problem >>>> reproduces more often. However, by using code size == 0 it is >>>> possible >>>> to write a regression test that triggers a real problem (which is >>>> hopefully related to the crashes we've been seeing). >>>> >>>> So I'd like to allow code sizes of 0 for now and attempt to fix >>>> CodeCache::get_code_heap() and the CodeBlobIterator constructor the >>>> way >>>> Vladimir suggested. If that turns out to be difficult/risky or >>>> require >>>> large code changes, I'll propose a fix instead that disallows code >>>> sizes >>>> of 1 and fixes the test(s) -- just as you suggested. >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> Best regards, >>>>> Tobias >>>>> >>>>>> dl >>>>>> >>>>>> >>>>>> On 2/6/17 7:29 AM, Zolt?n Maj? wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> please review the fix for 8173151. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8173151 >>>>>>> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >>>>>>> >>>>>>> The crash reported in the bug is caused by the corruption of the >>>>>>> 'non-profiled nmethods' code heap. CodeHeap::_freelist for that >>>>>>> code >>>>>>> heap points to an address one segment before the heap's address >>>>>>> space. The sweeper starts iterating through the code heap from the >>>>>>> beginning of the heap's address space. Thus, the sweeper assumes >>>>>>> that the first item in the code heap is a HeapBlock/FreeBlock (with >>>>>>> the appropriate length and usage information). However, that is not >>>>>>> the case, as the first item in the heap is actually *before* the >>>>>>> heap. So the sweeper crashes. >>>>>>> >>>>>>> This is a hard-to-reproduce problem (I managed to reproduce it only >>>>>>> once in 350 iterations, each iteration taking ~25 minutes). So the >>>>>>> fix I propose is based on core file debugging and source code >>>>>>> investigation. But I managed to write a regression test that >>>>>>> triggers a problem similar to the original problem. >>>>>>> >>>>>>> I think that problem happens because a CodeBlob allocated in one >>>>>>> code heap (A) is returned to a different code heap (B). When the >>>>>>> CodeBlob is returned B, it is added to B's freelist. However, as >>>>>>> the >>>>>>> CodeBlob was allocated in A, the freelist of B now points into A >>>>>>> (i.e., B is corrupted). >>>>>>> >>>>>>> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to >>>>>>> determine to which code heap a 'cb' is supposed to be returned to. >>>>>>> Since 8171008 (AOT) [1], the check is: >>>>>>> >>>>>>> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >>>>>>> assert(cb != NULL, "CodeBlob is null"); >>>>>>> FOR_ALL_HEAPS(heap) { >>>>>>> - if ((*heap)->contains(cb)) { >>>>>>> + if ((*heap)->contains(cb->code_begin())) { >>>>>>> return *heap; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> The blob 'cb' can be returned to the wrong heap if, for example: >>>>>>> - 'cb' is at the end code heap A and >>>>>>> - the size of the code contained in 'cb' is 0 (therefore >>>>>>> code_begin() returns the address after 'cb', i.e., the first >>>>>>> address >>>>>>> in code heap B). >>>>>>> >>>>>>> The fix proposes to restore CodeCache::get_code_heap() to its >>>>>>> pre-AOT state (as I'm not aware of the reasons why AOT changed that >>>>>>> check). I also propose to add some guarantees after >>>>>>> allocation/deallocation in the code heap to possibly easier catch >>>>>>> this or related problems in the future. >>>>>>> >>>>>>> The regression test I propose achieves the above condition and >>>>>>> results in a crash. The regression test works only with product >>>>>>> builds, because in a product build a BufferBlob fits into one >>>>>>> segment whereas in a fastdebug build it does not. >>>>>>> >>>>>>> The test needs to set the CodeCacheMinBlockLength flag to 1. The >>>>>>> flag is currently develop and we would need to make it product for >>>>>>> the test to work. (Other flags controlling the code cache, e.g., >>>>>>> CodeCacheExpansionSize, are also product.) I could also experiment >>>>>>> with reproducing the problem with different block lengths/segment >>>>>>> sizes, but that would most likely make the test more fragile (and >>>>>>> CodeCacheSegmentSize is anyway develop as well). >>>>>>> >>>>>>> I tested the fix with JPRT, RBT is in progress. >>>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>> [1] >>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >>>>>>> >>>>>>> >>>> >> From rwestrel at redhat.com Fri Feb 10 09:34:20 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 10 Feb 2017 10:34:20 +0100 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: <4c95c8ef-0252-91a2-3b46-b0315ed2284a@oracle.com> References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> <4c95c8ef-0252-91a2-3b46-b0315ed2284a@oracle.com> Message-ID: > Then in what cases your new check (_idx >= idx) fails? Here is an example: static void test_helper(A a) { a.m(); // virtual call with polluted profile } static void inlined() {} static A field = new A(); static Object test() { A a1 = field; if (a1.getClass() != A.class) { // always fail return null; } A a2 = field; inlined(); test_helper(a2); return a1; } Without my change, C2 inlines the a.m() call. The exact class test in the test() method for a1 results in a call to replace_in_map that replaces the load of field in the map with a CheckCastPP and records that pair in the replaced nodes. On return from inlined(), the load of field (from a2 = field) is replaced by the CheckCastPP when the replaced nodes are processed. If we drop the inlined() call: static Object test() { A a1 = field; if (a1.getClass() != A.class) { // always fail return null; } A a2 = field; test_helper(a2); return a1; } then C2 doesn't inline the a.m() call anymore. If we put the inlined() call back and with the change we're discussing, C2 doesn't inline the a.m() call either (because the CheckCastPP is an "old" node on return from the inlined call). Again, the replaced nodes were added to propagate casts done in callees to callers. This example just happens to optimize well by accident. The other fix I see would be to disable replaced nodes if one of the callers was found to have a irreducible loop by ciTypeFlow. It doesn't look much better to me because OSR compilations would be randomly affected. Roland. From rickard.backman at oracle.com Fri Feb 10 10:34:42 2017 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 10 Feb 2017 11:34:42 +0100 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: References: Message-ID: <20170210103442.GN8074@rbackman> Sorry for being a bit late here... The reason for the change in the contains() check from cb to cb->code_begin() is that with the changes for AOT we no longer require the metadata (AOTCompiledMethod *) and code to be in one blob. AOT does things like: code-heap-start code-method-1 code-method-2 code-method-3 code-method-4 code-heap-end and when we link those methods we create AOTCompiledMethods which just have pointers to code-method-1. The AOTCodeHeap then knows the boundaries of the code heap. Checking if the heap contains the metadata (AOTCompiledMethod *) will fail. While checking if it contains the code will succeed. /R On 02/06, Zolt?n Maj? wrote: > Hi, > > > please review the fix for 8173151. > > https://bugs.openjdk.java.net/browse/JDK-8173151 > http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ > > The crash reported in the bug is caused by the corruption of the > 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code > heap points to an address one segment before the heap's address > space. The sweeper starts iterating through the code heap from the > beginning of the heap's address space. Thus, the sweeper assumes > that the first item in the code heap is a HeapBlock/FreeBlock (with > the appropriate length and usage information). However, that is not > the case, as the first item in the heap is actually *before* the > heap. So the sweeper crashes. > > This is a hard-to-reproduce problem (I managed to reproduce it only > once in 350 iterations, each iteration taking ~25 minutes). So the > fix I propose is based on core file debugging and source code > investigation. But I managed to write a regression test that > triggers a problem similar to the original problem. > > I think that problem happens because a CodeBlob allocated in one > code heap (A) is returned to a different code heap (B). When the > CodeBlob is returned B, it is added to B's freelist. However, as the > CodeBlob was allocated in A, the freelist of B now points into A > (i.e., B is corrupted). > > The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to > determine to which code heap a 'cb' is supposed to be returned to. > Since 8171008 (AOT) [1], the check is: > > CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { > assert(cb != NULL, "CodeBlob is null"); > FOR_ALL_HEAPS(heap) { > - if ((*heap)->contains(cb)) { > + if ((*heap)->contains(cb->code_begin())) { > return *heap; > } > } > > The blob 'cb' can be returned to the wrong heap if, for example: > - 'cb' is at the end code heap A and > - the size of the code contained in 'cb' is 0 (therefore > code_begin() returns the address after 'cb', i.e., the first address > in code heap B). > > The fix proposes to restore CodeCache::get_code_heap() to its > pre-AOT state (as I'm not aware of the reasons why AOT changed that > check). I also propose to add some guarantees after > allocation/deallocation in the code heap to possibly easier catch > this or related problems in the future. > > The regression test I propose achieves the above condition and > results in a crash. The regression test works only with product > builds, because in a product build a BufferBlob fits into one > segment whereas in a fastdebug build it does not. > > The test needs to set the CodeCacheMinBlockLength flag to 1. The > flag is currently develop and we would need to make it product for > the test to work. (Other flags controlling the code cache, e.g., > CodeCacheExpansionSize, are also product.) I could also experiment > with reproducing the problem with different block lengths/segment > sizes, but that would most likely make the test more fragile (and > CodeCacheSegmentSize is anyway develop as well). > > I tested the fix with JPRT, RBT is in progress. > > Thank you! > > Best regards, > > > Zoltan > > [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 > From zoltan.majo at oracle.com Fri Feb 10 14:33:01 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 10 Feb 2017 15:33:01 +0100 Subject: [9] RFR (S): 8173151: Code heap corruption due to incorrect inclusion test In-Reply-To: <20170210103442.GN8074@rbackman> References: <20170210103442.GN8074@rbackman> Message-ID: Hi Rickard, On 02/10/2017 11:34 AM, Rickard B?ckman wrote: > Sorry for being a bit late here... thank you for the clarification. Unfortunately, I was not able to mention you as a reviewer in the changeset, as pushing it has already succeeded by the time I've received your message. > > The reason for the change in the contains() check from cb to > cb->code_begin() is that with the changes for AOT we no longer require > the metadata (AOTCompiledMethod *) and code to be in one blob. > > AOT does things like: > > code-heap-start > code-method-1 > code-method-2 > code-method-3 > code-method-4 > code-heap-end > > and when we link those methods we create AOTCompiledMethods which just > have pointers to code-method-1. > > The AOTCodeHeap then knows the boundaries of the code heap. > Checking if the heap contains the metadata (AOTCompiledMethod *) will > fail. While checking if it contains the code will succeed. That was my understanding as well, I think: The changeset keeps the inclusion test based on code_begin() for AOT-compiled methods http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ed9e29cd84f5#l1.8 and changes the inclusion test only for other code blob types. http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ed9e29cd84f5#l5.9 Thank you! Best regards, Zoltan > > /R > > On 02/06, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the fix for 8173151. >> >> https://bugs.openjdk.java.net/browse/JDK-8173151 >> http://cr.openjdk.java.net/~zmajo/8173151/webrev.00/ >> >> The crash reported in the bug is caused by the corruption of the >> 'non-profiled nmethods' code heap. CodeHeap::_freelist for that code >> heap points to an address one segment before the heap's address >> space. The sweeper starts iterating through the code heap from the >> beginning of the heap's address space. Thus, the sweeper assumes >> that the first item in the code heap is a HeapBlock/FreeBlock (with >> the appropriate length and usage information). However, that is not >> the case, as the first item in the heap is actually *before* the >> heap. So the sweeper crashes. >> >> This is a hard-to-reproduce problem (I managed to reproduce it only >> once in 350 iterations, each iteration taking ~25 minutes). So the >> fix I propose is based on core file debugging and source code >> investigation. But I managed to write a regression test that >> triggers a problem similar to the original problem. >> >> I think that problem happens because a CodeBlob allocated in one >> code heap (A) is returned to a different code heap (B). When the >> CodeBlob is returned B, it is added to B's freelist. However, as the >> CodeBlob was allocated in A, the freelist of B now points into A >> (i.e., B is corrupted). >> >> The code cache uses CodeCache::get_code_heap(const CodeBlob* cb) to >> determine to which code heap a 'cb' is supposed to be returned to. >> Since 8171008 (AOT) [1], the check is: >> >> CodeHeap* CodeCache::get_code_heap(const CodeBlob* cb) { >> assert(cb != NULL, "CodeBlob is null"); >> FOR_ALL_HEAPS(heap) { >> - if ((*heap)->contains(cb)) { >> + if ((*heap)->contains(cb->code_begin())) { >> return *heap; >> } >> } >> >> The blob 'cb' can be returned to the wrong heap if, for example: >> - 'cb' is at the end code heap A and >> - the size of the code contained in 'cb' is 0 (therefore >> code_begin() returns the address after 'cb', i.e., the first address >> in code heap B). >> >> The fix proposes to restore CodeCache::get_code_heap() to its >> pre-AOT state (as I'm not aware of the reasons why AOT changed that >> check). I also propose to add some guarantees after >> allocation/deallocation in the code heap to possibly easier catch >> this or related problems in the future. >> >> The regression test I propose achieves the above condition and >> results in a crash. The regression test works only with product >> builds, because in a product build a BufferBlob fits into one >> segment whereas in a fastdebug build it does not. >> >> The test needs to set the CodeCacheMinBlockLength flag to 1. The >> flag is currently develop and we would need to make it product for >> the test to work. (Other flags controlling the code cache, e.g., >> CodeCacheExpansionSize, are also product.) I could also experiment >> with reproducing the problem with different block lengths/segment >> sizes, but that would most likely make the test more fragile (and >> CodeCacheSegmentSize is anyway develop as well). >> >> I tested the fix with JPRT, RBT is in progress. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/777aaa19c4b1#l116.71 >> From vladimir.x.ivanov at oracle.com Fri Feb 10 16:37:52 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Feb 2017 19:37:52 +0300 Subject: [9] RFR (S): 8174721: C1: Inlining through MH invokers/linkers in unreachable code is unsafe Message-ID: <2005c3ab-7a5a-e03c-73cb-90dce0473dbf@oracle.com> http://cr.openjdk.java.net/~vlivanov/8174721/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8174721 8166110 didn't touch C1, but newly added regression test provoked similar failure there. Add signature checks between linker & target methods to ensure inlining doesn't happen for evidently broken cases. Testing: regression test, JPRT, RBT Thanks! Best regards, Vladimir Ivanov From igor.veresov at oracle.com Fri Feb 10 17:00:43 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 10 Feb 2017 09:00:43 -0800 Subject: [9] RFR (S): 8174721: C1: Inlining through MH invokers/linkers in unreachable code is unsafe In-Reply-To: <2005c3ab-7a5a-e03c-73cb-90dce0473dbf@oracle.com> References: <2005c3ab-7a5a-e03c-73cb-90dce0473dbf@oracle.com> Message-ID: Looks good to me. igor > On Feb 10, 2017, at 8:37 AM, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8174721/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8174721 > > 8166110 didn't touch C1, but newly added regression test provoked similar failure there. > > Add signature checks between linker & target methods to ensure inlining doesn't happen for evidently broken cases. > > Testing: regression test, JPRT, RBT > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Feb 10 17:20:37 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 10 Feb 2017 20:20:37 +0300 Subject: [9] RFR (S): 8174721: C1: Inlining through MH invokers/linkers in unreachable code is unsafe In-Reply-To: References: <2005c3ab-7a5a-e03c-73cb-90dce0473dbf@oracle.com> Message-ID: <3fc30d10-3e20-1f8a-51e1-cc72a83c4a31@oracle.com> Thanks, Igor. Best regards, Vladimir Ivanov On 2/10/17 8:00 PM, Igor Veresov wrote: > Looks good to me. > > igor > >> On Feb 10, 2017, at 8:37 AM, Vladimir Ivanov wrote: >> >> http://cr.openjdk.java.net/~vlivanov/8174721/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8174721 >> >> 8166110 didn't touch C1, but newly added regression test provoked similar failure there. >> >> Add signature checks between linker & target methods to ensure inlining doesn't happen for evidently broken cases. >> >> Testing: regression test, JPRT, RBT >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From vladimir.kozlov at oracle.com Fri Feb 10 19:21:13 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Feb 2017 11:21:13 -0800 Subject: unified logging fingerprint ? In-Reply-To: <531035085.2693436.1486736322774.JavaMail.zimbra@u-pem.fr> References: <531035085.2693436.1486736322774.JavaMail.zimbra@u-pem.fr> Message-ID: <16a27dac-ef14-4af0-c50c-419431c924fd@oracle.com> Hi Remi, I think it is wrong. 0 fingerprint should be only for anonymous classes. Can you send command line and which build you use? And how you build AOT lib? Thanks, Vladimir On 2/10/17 6:18 AM, Remi Forax wrote: > Hi all, > while playing with jaotc, i have line like this if i enable the VM logging, > > [0.035s][info][class,fingerprint] java.util.concurrent.ConcurrentHashMap$KeySetView : expected = 0x0000000000000000 actual = 0x000015a151430d2a > [0.035s][info][class,load ] java.util.concurrent.ConcurrentHashMap$ValuesView source: jrt:/java.base > [0.035s][info][class,load ] java.util.concurrent.ConcurrentHashMap$EntrySetView source: jrt:/java.base > [0.035s][info][class,fingerprint] java.util.concurrent.ConcurrentHashMap$EntrySetView : expected = 0x0000000000000000 actual = 0x000019184fc557bd > [0.035s][info][class,load ] jdk.internal.reflect.Reflection source: jrt:/java.base > > i wonder if it's something normal or if i've done something wrong ? > > R?mi > From goetz.lindenmaier at sap.com Mon Feb 13 06:24:33 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 Feb 2017 06:24:33 +0000 Subject: [ping] JDK 10 RFR(S): 8173465: Introduce NearLabel for branches known to be short. Message-ID: Could someone please have a look? Thanks, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 30. Januar 2017 12:57 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: JDK 10 RFR(S): 8173465: Introduce NearLabel for branches known to > be short. > > Hi > > please review this small optimization of Labels. > This so far targets s390, but could be used on other platforms as well. > I please need a sponsor. > http://cr.openjdk.java.net/~goetz/wr17/8173465- > NearLbl/webrev.01/index.html > > Some branches issued to assembly code are obviously of short distance. Due > to separation into shared and platform code this not always is known when > the branch instruction is selected. > NearLabels indicate that a branch with short reach can be used. > > Best regards, > Goetz From doug.simon at oracle.com Mon Feb 13 12:13:16 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 13 Feb 2017 13:13:16 +0100 Subject: Package resolution when compiling jdk.aot against jdk.vm.ci In-Reply-To: <1b04b4f9-043b-7da1-3c10-1910f3fb5945@redhat.com> References: <1b04b4f9-043b-7da1-3c10-1910f3fb5945@redhat.com> Message-ID: Adding in hotspot-compiler-dev as they are more knowledge on building the aot code. > On 13 Feb 2017, at 12:49, Andrew Haley wrote: > > I have this patch: > > diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java > --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java > +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java > @@ -24,8 +24,10 @@ > package jdk.tools.jaotc; > > import jdk.tools.jaotc.CompiledMethodInfo.StubInformation; > +import jdk.tools.jaotc.aarch64.AArch64ELFMacroAssembler; > import jdk.tools.jaotc.amd64.AMD64ELFMacroAssembler; > > +import jdk.vm.ci.aarch64.AArch64; > import jdk.vm.ci.amd64.AMD64; > import jdk.vm.ci.code.Architecture; > import jdk.vm.ci.code.TargetDescription; > @@ -36,6 +38,8 @@ > Architecture architecture = target.arch; > if (architecture instanceof AMD64) { > return new AMD64ELFMacroAssembler(target); > + } else if (architecture instanceof AArch64) { > + return new AArch64ELFMacroAssembler(target); > } else { > throw new InternalError("Unsupported architecture " + architecture); > } > > but I get > > Compiling jdk.aot > /home/aph/jdk10/hs/hotspot/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java:30: error: package jdk.vm.ci.aarch64 does not exist > import jdk.vm.ci.aarch64.AArch64; > ^ > I presume that there is something I should be doing to enable javac to > see the jdk.vm.ci.aarch64 package. hotspot/make/gensrc/Gensrc-jdk.vm.compiler.gmk > already exports jdk.vm.ci.aarch64. > > Any ideas? > > Thanks, > > Andrew. From dmitrij.pochepko at oracle.com Mon Feb 13 16:47:29 2017 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 13 Feb 2017 19:47:29 +0300 Subject: RFR(S): 8172050 - some compiler/calls/ tests should have /native option Message-ID: Hi, please review small fix for: 8172050 - some compiler/calls/ tests should have /native option According to jtreg guidelines, a /native option should be added to tests run directive in case test use native libraries. This fix adds this option. This change is going to be pushed to jdk9/hs/hotspot since current push restrictions are not applied to test fixes. webrev: http://cr.openjdk.java.net/~dpochepk/8172050/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8172050 I've tested this change on linux-x64. Thanks, Dmitrij From dmitry.chuyko at oracle.com Mon Feb 13 18:44:34 2017 From: dmitry.chuyko at oracle.com (Dmitry Chuyko) Date: Mon, 13 Feb 2017 21:44:34 +0300 Subject: RFR : JDK-8174818 : bigapps/Weblogic12medrec fails with assert(check_call_consistency(jvms, cg)) failed: inconsistent info Message-ID: Summary: After refactoring one check in ciMethod::is_consistent_info became too strict for the case of unloaded types. Relaxing signatures match to symbolic match helps. Patch: 8174818.01.patch attached Testing: failed test, Hotspot & JDK tests (in progress). Thanks, -Dmitry -------------- next part -------------- A non-text attachment was scrubbed... Name: 8174818.01.patch Type: text/x-patch Size: 778 bytes Desc: not available URL: From vladimir.x.ivanov at oracle.com Mon Feb 13 20:48:26 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 13 Feb 2017 23:48:26 +0300 Subject: RFR : JDK-8174818 : bigapps/Weblogic12medrec fails with assert(check_call_consistency(jvms, cg)) failed: inconsistent info In-Reply-To: References: Message-ID: <98f7d544-040e-c049-18ee-6362f01d4673@oracle.com> Looks good. Best regards, Vladimir Ivanov On 2/13/17 9:44 PM, Dmitry Chuyko wrote: > Summary: After refactoring one check in ciMethod::is_consistent_info > became too strict for the case of unloaded types. Relaxing signatures > match to symbolic match helps. > > Patch: 8174818.01.patch attached > > Testing: failed test, Hotspot & JDK tests (in progress). > > Thanks, > -Dmitry > From rkennke at redhat.com Mon Feb 13 21:11:28 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 13 Feb 2017 22:11:28 +0100 Subject: RFR (S): JDK-8172434: CompareAndExchangeObject inserts two pre-barriers Message-ID: <1487020288.2822.27.camel@redhat.com> in LibaryCallKit::inline_unsafe_access(), the pre_barrier() gets inserted twice for LS_cmp_exchange, in one case it is treated like the other CAS instructions, and at the end it is treated like get_and_set. It's not causing incorrect behaviour, but might impact performance. The fix is to leave out the 2nd pre-barrier for CAE by checking for get_and_set. Testing: jcstress http://cr.openjdk.java.net/~rkennke/fix-cae-prebarrier/webrev.01/ Roman From vladimir.kozlov at oracle.com Mon Feb 13 21:38:29 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Feb 2017 13:38:29 -0800 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> <4c95c8ef-0252-91a2-3b46-b0315ed2284a@oracle.com> Message-ID: On 2/10/17 1:34 AM, Roland Westrelin wrote: > >> Then in what cases your new check (_idx >= idx) fails? > > Here is an example: > > static void test_helper(A a) { > a.m(); // virtual call with polluted profile > } I assume test_helper() is inlined into test() in all these cases. Right? > > static void inlined() {} > > static A field = new A(); > static Object test() { > A a1 = field; > if (a1.getClass() != A.class) { // always fail > return null; > } > A a2 = field; > inlined(); > test_helper(a2); > return a1; > } > > > Without my change, C2 inlines the a.m() call. The exact class test in > the test() method for a1 results in a call to replace_in_map that > replaces the load of field in the map with a CheckCastPP and records > that pair in the replaced nodes. On return from inlined(), the load of > field (from a2 = field) is replaced by the CheckCastPP when the replaced > nodes are processed. Why we do replacement on exit of method inlined() which not have any code? Should we do it in Call node map before we inline and parse it? > > If we drop the inlined() call: > > static Object test() { > A a1 = field; > if (a1.getClass() != A.class) { // always fail > return null; > } > A a2 = field; > test_helper(a2); > return a1; > } > > then C2 doesn't inline the a.m() call anymore. If we put the inlined() > call back and with the change we're discussing, C2 doesn't inline the > a.m() call either (because the CheckCastPP is an "old" node on return > from the inlined call). Is not this bad (not inlining)? > > Again, the replaced nodes were added to propagate casts done in callees > to callers. This example just happens to optimize well by accident. > > The other fix I see would be to disable replaced nodes if one of the > callers was found to have a irreducible loop by ciTypeFlow. It doesn't > look much better to me because OSR compilations would be randomly > affected. But I think it is smaller number of cases vs current fix. Also most OSR methods are recompiled as normal nmethods so affect will be only temporary. Thanks, Vladimir > > Roland. > From vladimir.kozlov at oracle.com Mon Feb 13 21:45:46 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Feb 2017 13:45:46 -0800 Subject: RFR(S): 8172050 - some compiler/calls/ tests should have /native option In-Reply-To: References: Message-ID: <30c13607-755d-ab59-23b8-d46cb154fc67@oracle.com> Bug should be P3 to be in jdk9. Changes looks good. Thanks, Vladimir On 2/13/17 8:47 AM, Dmitrij Pochepko wrote: > Hi, > > please review small fix for: 8172050 - some compiler/calls/ tests should have /native option > > According to jtreg guidelines, a /native option should be added to tests run directive in case test use native libraries. > > This fix adds this option. This change is going to be pushed to jdk9/hs/hotspot since current push restrictions are not applied to test fixes. > > > webrev: http://cr.openjdk.java.net/~dpochepk/8172050/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8172050 > > I've tested this change on linux-x64. > > Thanks, > > Dmitrij > From vladimir.kozlov at oracle.com Mon Feb 13 22:20:47 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Feb 2017 14:20:47 -0800 Subject: JDK 10 RFR(S): 8173465: Introduce NearLabel for branches known to be short. In-Reply-To: <0f988f3f257047ce9fff5d0101ea65e0@DEROTE13DE04.global.corp.sap> References: <0f988f3f257047ce9fff5d0101ea65e0@DEROTE13DE04.global.corp.sap> Message-ID: <0a13fe2f-f58a-7266-cf43-c073479ec366@oracle.com> I assume you are talking about hand written assembler code snippets (stubs, etc.) Usually we use appropriate short branch instructions for short forward distance (and there is assert which check that it is correct). For back branches we do it automatically depending on distance. So why you need special NearLabel for s390? Can you just have general short branch macroassembler method for this? Thanks, Vladimir On 1/30/17 2:57 AM, Lindenmaier, Goetz wrote: > Hi > > please review this small optimization of Labels. > This so far targets s390, but could be used on other platforms as well. > I please need a sponsor. > http://cr.openjdk.java.net/~goetz/wr17/8173465-NearLbl/webrev.01/index.html > > Some branches issued to assembly code are obviously of short distance. Due to separation into shared and platform code this not always is known when the branch instruction is selected. > NearLabels indicate that a branch with short reach can be used. > > Best regards, > Goetz > From vladimir.kozlov at oracle.com Tue Feb 14 00:41:23 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Feb 2017 16:41:23 -0800 Subject: RFR (S): JDK-8172434: CompareAndExchangeObject inserts two pre-barriers In-Reply-To: <1487020288.2822.27.camel@redhat.com> References: <1487020288.2822.27.camel@redhat.com> Message-ID: <4a842738-db6e-2abe-d67c-d0b6e4d90473@oracle.com> Looks good. Thanks, Vladimir On 2/13/17 1:11 PM, Roman Kennke wrote: > in LibaryCallKit::inline_unsafe_access(), the pre_barrier() gets > inserted twice for LS_cmp_exchange, in one case it is treated like the > other CAS instructions, and at the end it is treated like get_and_set. > It's not causing incorrect behaviour, but might impact performance. > > The fix is to leave out the 2nd pre-barrier for CAE by checking for > get_and_set. > > Testing: jcstress > > http://cr.openjdk.java.net/~rkennke/fix-cae-prebarrier/webrev.01/ > > Roman > From goetz.lindenmaier at sap.com Tue Feb 14 09:38:56 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 Feb 2017 09:38:56 +0000 Subject: JDK 10 RFR(S): 8173465: Introduce NearLabel for branches known to be short. In-Reply-To: <0a13fe2f-f58a-7266-cf43-c073479ec366@oracle.com> References: <0f988f3f257047ce9fff5d0101ea65e0@DEROTE13DE04.global.corp.sap> <0a13fe2f-f58a-7266-cf43-c073479ec366@oracle.com> Message-ID: <0c2255f342f14be598e7ff95eb0aefde@sap.com> Hi Vladimir, For forward branches the branch instruction is decided on before the Label is fixed. Sometimes the decision which branch instruction to use must be taken far down a call chain. You would have to pass down a boolean flag 'useShortBranch' all the call chain. See emit_typecheck_helper in c1_LIRAssembler_s390.cpp http://hg.openjdk.java.net/jdk10/hs/hotspot/file/df8746afee77/src/cpu/s390/vm/c1_LIRAssembler_s390.cpp It gets a label from emit_opTypeCheck which can point to a stub entry. This label is in some cases passed down to check_class_subtype_fast_path. In other cases, a local label is passed to this functions. We know for the local label the short branch will suffice, not so for the label coming from extern. So we use NearLable for the local one. Check_class_subtype_fast_path passes the label on to a s390 optimized branch emitter compare64_and_branch, which then sees whether it's a NearLabel and uses the short branch. Best regards, Goetz. > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 14. Februar 2017 00:21 > To: Lindenmaier, Goetz ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: Re: JDK 10 RFR(S): 8173465: Introduce NearLabel for branches known > to be short. > > I assume you are talking about hand written assembler code snippets (stubs, > etc.) > > Usually we use appropriate short branch instructions for short forward > distance (and there is assert which check that it is correct). For back branches > we do it automatically depending on distance. > > So why you need special NearLabel for s390? Can you just have general short > branch macroassembler method for this? > > Thanks, > Vladimir > > On 1/30/17 2:57 AM, Lindenmaier, Goetz wrote: > > Hi > > > > please review this small optimization of Labels. > > This so far targets s390, but could be used on other platforms as well. > > I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/wr17/8173465- > NearLbl/webrev.01/index.html > > > > Some branches issued to assembly code are obviously of short distance. > Due to separation into shared and platform code this not always is known > when the branch instruction is selected. > > NearLabels indicate that a branch with short reach can be used. > > > > Best regards, > > Goetz > > From rkennke at redhat.com Tue Feb 14 09:46:09 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 14 Feb 2017 10:46:09 +0100 Subject: RFR (S): JDK-8172434: CompareAndExchangeObject inserts two pre-barriers In-Reply-To: <4a842738-db6e-2abe-d67c-d0b6e4d90473@oracle.com> References: <1487020288.2822.27.camel@redhat.com> <4a842738-db6e-2abe-d67c-d0b6e4d90473@oracle.com> Message-ID: <1487065569.2822.32.camel@redhat.com> Hi Vladimir, thanks! I think I need a sponsor now? Can you do that? Thanks, Roman Am Montag, den 13.02.2017, 16:41 -0800 schrieb Vladimir Kozlov: > Looks good. > > Thanks, > Vladimir > > On 2/13/17 1:11 PM, Roman Kennke wrote: > > in LibaryCallKit::inline_unsafe_access(), the pre_barrier() gets > > inserted twice for LS_cmp_exchange, in one case it is treated like > > the > > other CAS instructions, and at the end it is treated like > > get_and_set. > > It's not causing incorrect behaviour, but might impact performance. > > > > The fix is to leave out the 2nd pre-barrier for CAE by checking for > > get_and_set. > > > > Testing: jcstress > > > > http://cr.openjdk.java.net/~rkennke/fix-cae-prebarrier/webrev.01/ > > > > Roman > > From rwestrel at redhat.com Tue Feb 14 10:13:52 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 14 Feb 2017 11:13:52 +0100 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> <4c95c8ef-0252-91a2-3b46-b0315ed2284a@oracle.com> Message-ID: > I assume test_helper() is inlined into test() in all these > cases. Right? Yes. > Why we do replacement on exit of method inlined() which not have any > code? Should we do it in Call node map before we inline and parse it? replaced nodes were introduced for this code pattern: static void inlined1(Object o) { A a = (A)o; } static void inlined2(Object o) { inlined1(o); } static void inlined3(Object o) { inlined2(o); } static void test(Object o) { inlined3(o); // use o that benefit from knowing it's of type A } This works if we propagate the replaced nodes at the end of parsing. > Is not this bad (not inlining)? Sure it's a bad thing. But then again it works by accident because there happens to be a call to inlined(). What would be nice is that the virtual call be inlined with or without the call to inlined() (apply replaced nodes after the load?). > But I think it is smaller number of cases vs current fix. Also most > OSR methods are recompiled as normal nmethods so affect will be only > temporary. My test case is pretty simple and it results in irreducible loops. Replaced nodes were added for nashorn and I remember they had simple scripts with a loop that would only get OSR compiled. Anyway, here is the fix with a check for irreducible loops: http://cr.openjdk.java.net/~roland/8174164/webrev.01/ Roland. From doug.simon at oracle.com Tue Feb 14 13:34:47 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 14 Feb 2017 14:34:47 +0100 Subject: Running jaotc with an external Graal In-Reply-To: References: Message-ID: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> I don?t know how one patches a module in the middle of the module graph. That is, we use --patch-module and --upgrade-module-path to override the jdk.vm.compiler module in the JDK. I don?t know what that means for modules such as jdk.aot that depend on jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help. -Doug > On 14 Feb 2017, at 12:26, Andrew Haley wrote: > > Is this possible? Seems that no matter what I do, aotc always prefers to > use the internal version of org.graalvm.compiler which is in HotSpot. > > I don't quite get why this is: I can run an external Graal using JVMCI > with no problems. I saw "8145337: [JVMCI] JVMCI initialization with > SecurityManager installed fails:" which might be related, but perhaps > it's not. > > So, why is it possible to use an external Graal with JVMCI, but > apparently not with jaotc? And is there anything I can do to make > progress? > > Thanks, > > Andrew. From dmitrij.pochepko at oracle.com Tue Feb 14 14:09:00 2017 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 14 Feb 2017 17:09:00 +0300 Subject: RFR(S): 8172050 - some compiler/calls/ tests should have /native option In-Reply-To: <30c13607-755d-ab59-23b8-d46cb154fc67@oracle.com> References: <30c13607-755d-ab59-23b8-d46cb154fc67@oracle.com> Message-ID: Thank you! On 14.02.2017 00:45, Vladimir Kozlov wrote: > Bug should be P3 to be in jdk9. > > Changes looks good. > > Thanks, > Vladimir > > On 2/13/17 8:47 AM, Dmitrij Pochepko wrote: >> Hi, >> >> please review small fix for: 8172050 - some compiler/calls/ tests >> should have /native option >> >> According to jtreg guidelines, a /native option should be added to >> tests run directive in case test use native libraries. >> >> This fix adds this option. This change is going to be pushed to >> jdk9/hs/hotspot since current push restrictions are not applied to >> test fixes. >> >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8172050/webrev.01/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8172050 >> >> I've tested this change on linux-x64. >> >> Thanks, >> >> Dmitrij >> From aph at redhat.com Tue Feb 14 14:20:54 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Feb 2017 14:20:54 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> Message-ID: <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> On 14/02/17 13:34, Doug Simon wrote: > I don?t know how one patches a module in the middle of the module > graph. That is, we use --patch-module and --upgrade-module-path to > override the jdk.vm.compiler module in the JDK. I don?t know what > that means for modules such as jdk.aot that depend on > jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help. OK, thanks. I guess I could try to upgrade the copy of Graal that is contained in HotSpot. I'll have a look. Andrew. From dmitrij.pochepko at oracle.com Tue Feb 14 14:35:14 2017 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 14 Feb 2017 17:35:14 +0300 Subject: RFR: 8138801 - develop tests to check that CompilerToVM::isMature state is consistence w/ reprofile Message-ID: <074cf590-b547-3690-9d2a-fc82e4a0ebf3@oracle.com> Hi, please review patch for 8138801 - develop tests to check that CompilerToVM::isMature state is consistence w/ reprofile This patch adds test which checks isMature method check before and after reprofiling. webrev: http://cr.openjdk.java.net/~dpochepk/8138801/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8138801 I've tested this patch on linux-x64. Thanks, Dmitrij From Alan.Bateman at oracle.com Tue Feb 14 14:37:05 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Feb 2017 14:37:05 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> Message-ID: <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> On 14/02/2017 14:20, Andrew Haley wrote: > On 14/02/17 13:34, Doug Simon wrote: > >> I don?t know how one patches a module in the middle of the module >> graph. That is, we use --patch-module and --upgrade-module-path to >> override the jdk.vm.compiler module in the JDK. I don?t know what >> that means for modules such as jdk.aot that depend on >> jdk.vm.compiler. Maybe someone from the AOT or jigsaw team can help. > OK, thanks. I guess I could try to upgrade the copy of Graal that is > contained in HotSpot. I'll have a look. > > --patch-module can be used to patch any module in the boot layer. So if you are looking to override or add classes then --patch-module should work. -Alan From dmitrij.pochepko at oracle.com Tue Feb 14 14:37:55 2017 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 14 Feb 2017 17:37:55 +0300 Subject: RFR: 8138799 - improve tests for CompilerToVM::MaterializeVirtualObjectTest Message-ID: <78e316a1-41a6-9b28-6e09-ba5a1aa37ac8@oracle.com> Hi, please review patch for 8138799 - improve tests for CompilerToVM::MaterializeVirtualObjectTest This patch adds logic which checks that frame materialization doesn't affect previous or next frame. webrev: http://cr.openjdk.java.net/~dpochepk/8138799/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8138799 I've tested this patch on linux-x64. Thanks, Dmitrij From aph at redhat.com Tue Feb 14 14:38:35 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Feb 2017 14:38:35 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> Message-ID: <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> On 14/02/17 14:37, Alan Bateman wrote: > --patch-module can be used to patch any module in the boot layer. So if > you are looking to override or add classes then --patch-module should work. Aha! Thanks, Andrew. From vladimir.x.ivanov at oracle.com Tue Feb 14 14:43:05 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Feb 2017 17:43:05 +0300 Subject: RFR (S): JDK-8172434: CompareAndExchangeObject inserts two pre-barriers In-Reply-To: <1487065569.2822.32.camel@redhat.com> References: <1487020288.2822.27.camel@redhat.com> <4a842738-db6e-2abe-d67c-d0b6e4d90473@oracle.com> <1487065569.2822.32.camel@redhat.com> Message-ID: Looks good. I'll sponsor the fix. Best regards, Vladimir Ivanov On 2/14/17 12:46 PM, Roman Kennke wrote: > Hi Vladimir, > > thanks! > > I think I need a sponsor now? Can you do that? > > Thanks, > Roman > > > Am Montag, den 13.02.2017, 16:41 -0800 schrieb Vladimir Kozlov: >> Looks good. >> >> Thanks, >> Vladimir >> >> On 2/13/17 1:11 PM, Roman Kennke wrote: >>> in LibaryCallKit::inline_unsafe_access(), the pre_barrier() gets >>> inserted twice for LS_cmp_exchange, in one case it is treated like >>> the >>> other CAS instructions, and at the end it is treated like >>> get_and_set. >>> It's not causing incorrect behaviour, but might impact performance. >>> >>> The fix is to leave out the 2nd pre-barrier for CAE by checking for >>> get_and_set. >>> >>> Testing: jcstress >>> >>> http://cr.openjdk.java.net/~rkennke/fix-cae-prebarrier/webrev.01/ >>> >>> Roman >>> From vladimir.x.ivanov at oracle.com Tue Feb 14 18:51:05 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Feb 2017 21:51:05 +0300 Subject: [10] RFR (M): 6986483: CHA: optimize calls through interfaces Message-ID: http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-6986483 Proposed change adds CHA support in C2 for interface calls. Consider the following hierarchy: interface Intf { m(); } class C implements Intf { public m() { ... } } class C1 extends C { /* doesn't override m() */ } ... class Cn extends C { /* doesn't override m() */ } Call site: invokeinterface Intf.m() ... If Intf were an abstract class, CHA could deduce that Intf::m() can be replaced with C::m(), but it doesn't work for interfaces. Verifier doesn't check interface types in bytecode, so CHA can't assume the receiver implements Intf. CHA in C1 handles such call sites for interfaces with a single implementor. It replaces invokeinterface Intf.m() with invokevirtual C.m() guarded by a subtype check (instanceof C). C2 doesn't do that and this request is about adding that. Type profiling doesn't help here (the call site is usually megamorphic), so C2 can't inline it. The proposed implementation is similar to C1, except that the code deoptimizes when subtype check fails and ICCE is thrown from the interpreter. While working on it, I spotted and fixed a couple of inefficiencies in C1 implementation: (1) dependency context being used was broader than necessary - resolved instead of declared interface (hence, possibility of unnecessary invalidations); (2) didn't work for interfaces w/ any default methods: CHA doesn't support default methods at the moment, so what matters is whether Intf::m() is default or not and not whether Intf has *any* concrete methods. Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress), LogCompilation tool. Thanks! Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Tue Feb 14 19:13:44 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Feb 2017 11:13:44 -0800 Subject: RFR: 8138799 - improve tests for CompilerToVM::MaterializeVirtualObjectTest In-Reply-To: <78e316a1-41a6-9b28-6e09-ba5a1aa37ac8@oracle.com> References: <78e316a1-41a6-9b28-6e09-ba5a1aa37ac8@oracle.com> Message-ID: <98e35058-80c7-9ae2-0400-0e2f6cb2d5fc@oracle.com> Okay. thanks, Vladimir On 2/14/17 6:37 AM, Dmitrij Pochepko wrote: > Hi, > > please review patch for 8138799 - improve tests for CompilerToVM::MaterializeVirtualObjectTest > > This patch adds logic which checks that frame materialization doesn't affect previous or next frame. > > > webrev: http://cr.openjdk.java.net/~dpochepk/8138799/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8138799 > > I've tested this patch on linux-x64. > > > Thanks, > > Dmitrij > From vladimir.kozlov at oracle.com Tue Feb 14 19:14:32 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Feb 2017 11:14:32 -0800 Subject: RFR: 8138801 - develop tests to check that CompilerToVM::isMature state is consistence w/ reprofile In-Reply-To: <074cf590-b547-3690-9d2a-fc82e4a0ebf3@oracle.com> References: <074cf590-b547-3690-9d2a-fc82e4a0ebf3@oracle.com> Message-ID: <81d5130e-4c1e-fe14-7fe1-5470bf8bafeb@oracle.com> Good. Thanks, Vladimir On 2/14/17 6:35 AM, Dmitrij Pochepko wrote: > Hi, > > please review patch for 8138801 - develop tests to check that CompilerToVM::isMature state is consistence w/ reprofile > > This patch adds test which checks isMature method check before and after reprofiling. > > webrev: http://cr.openjdk.java.net/~dpochepk/8138801/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8138801 > > I've tested this patch on linux-x64. > > > Thanks, > > Dmitrij > From dmitrij.pochepko at oracle.com Tue Feb 14 19:22:52 2017 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 14 Feb 2017 22:22:52 +0300 Subject: RFR: 8138799 - improve tests for CompilerToVM::MaterializeVirtualObjectTest In-Reply-To: <98e35058-80c7-9ae2-0400-0e2f6cb2d5fc@oracle.com> References: <78e316a1-41a6-9b28-6e09-ba5a1aa37ac8@oracle.com> <98e35058-80c7-9ae2-0400-0e2f6cb2d5fc@oracle.com> Message-ID: Thank you! On 14.02.2017 22:13, Vladimir Kozlov wrote: > Okay. > > thanks, > Vladimir > > On 2/14/17 6:37 AM, Dmitrij Pochepko wrote: >> Hi, >> >> please review patch for 8138799 - improve tests for >> CompilerToVM::MaterializeVirtualObjectTest >> >> This patch adds logic which checks that frame materialization doesn't >> affect previous or next frame. >> >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8138799/webrev.01/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8138799 >> >> I've tested this patch on linux-x64. >> >> >> Thanks, >> >> Dmitrij >> From doug.simon at oracle.com Tue Feb 14 20:11:34 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 14 Feb 2017 21:11:34 +0100 Subject: RFR: 8174961: [JVMCI] incorrect implementation of isCompilable Message-ID: Please review this fix for a rather embarrassing bug I committed as part of JDK-8172733. http://cr.openjdk.java.net/~dnsimon/8174961/webrev/ https://bugs.openjdk.java.net/browse/JDK-8174961 -Doug From vladimir.kozlov at oracle.com Tue Feb 14 20:17:15 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Feb 2017 12:17:15 -0800 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> <4c95c8ef-0252-91a2-3b46-b0315ed2284a@oracle.com> Message-ID: <03f84597-8a3a-668e-3971-f29dbaa117fc@oracle.com> Wow, so much changes. Can you add _irreducible_loop field to CallGenerator instead of passing as argument? Also instead of adding such field to 2 classes may be add it to base class GraphKit. Thanks, Vladimir On 2/14/17 2:13 AM, Roland Westrelin wrote: > >> I assume test_helper() is inlined into test() in all these >> cases. Right? > > Yes. > >> Why we do replacement on exit of method inlined() which not have any >> code? Should we do it in Call node map before we inline and parse it? > > replaced nodes were introduced for this code pattern: > > static void inlined1(Object o) { > A a = (A)o; > } > > static void inlined2(Object o) { > inlined1(o); > } > > static void inlined3(Object o) { > inlined2(o); > } > > static void test(Object o) { > inlined3(o); > // use o that benefit from knowing it's of type A > } > > This works if we propagate the replaced nodes at the end of parsing. > >> Is not this bad (not inlining)? > > Sure it's a bad thing. But then again it works by accident because there > happens to be a call to inlined(). What would be nice is that the > virtual call be inlined with or without the call to inlined() (apply > replaced nodes after the load?). > >> But I think it is smaller number of cases vs current fix. Also most >> OSR methods are recompiled as normal nmethods so affect will be only >> temporary. > > My test case is pretty simple and it results in irreducible > loops. Replaced nodes were added for nashorn and I remember they had > simple scripts with a loop that would only get OSR compiled. Anyway, > here is the fix with a check for irreducible loops: > > http://cr.openjdk.java.net/~roland/8174164/webrev.01/ > > Roland. > From vladimir.kozlov at oracle.com Tue Feb 14 20:28:44 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Feb 2017 12:28:44 -0800 Subject: RFR: 8174961: [JVMCI] incorrect implementation of isCompilable In-Reply-To: References: Message-ID: I did not get the condition. Why a method is *compilable* if JVMCICompiler is not used? Should it be UseJVMCICompiler && !method->is_not_compilable( Then comment is wrong. Please, explain. Thanks, Vladimir On 2/14/17 12:11 PM, Doug Simon wrote: > Please review this fix for a rather embarrassing bug I committed as part of JDK-8172733. > > http://cr.openjdk.java.net/~dnsimon/8174961/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8174961 > > -Doug > From doug.simon at oracle.com Tue Feb 14 20:40:19 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 14 Feb 2017 21:40:19 +0100 Subject: RFR: 8174961: [JVMCI] incorrect implementation of isCompilable In-Reply-To: References: Message-ID: <0C1BD311-DD7F-449B-BDF2-6736527FE7DB@oracle.com> > On 14 Feb 2017, at 21:28, Vladimir Kozlov wrote: > > I did not get the condition. Why a method is *compilable* if JVMCICompiler is not used? Should it be > > UseJVMCICompiler && !method->is_not_compilable( > > Then comment is wrong. Please, explain. If UseJVMCICompiler is false, then JVMCI is not being used by the VM as a jit but is only being used in hosted mode (e.g. by Truffle). The thinking was that hosted clients do not typically care about VM policies effecting the compilability of a method (e.g. whether it has a breakpoint etc). However, now that I reflect on this further, such clients should ignore this call altogether as they may be in a VM environment where both hosted and non-hosted compilations are being requested of JVMCI. With that in mind, I?ve updated the webrev to remove all mention and use of UseJVMCICompiler. -Doug > > On 2/14/17 12:11 PM, Doug Simon wrote: >> Please review this fix for a rather embarrassing bug I committed as part of JDK-8172733. >> >> http://cr.openjdk.java.net/~dnsimon/8174961/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8174961 >> >> -Doug >> From vladimir.kozlov at oracle.com Tue Feb 14 20:47:37 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Feb 2017 12:47:37 -0800 Subject: RFR: 8174961: [JVMCI] incorrect implementation of isCompilable In-Reply-To: <0C1BD311-DD7F-449B-BDF2-6736527FE7DB@oracle.com> References: <0C1BD311-DD7F-449B-BDF2-6736527FE7DB@oracle.com> Message-ID: <6d79a58c-5904-9479-262a-e99b0ad62e4d@oracle.com> Should you also remove flag check in previous lines in the test?: boolean isCompilable = CompilerToVMHelper.isCompilable(method); boolean expected = UseJVMCICompiler || WB.isMethodCompilable(aMethod); Thanks, Vladimir On 2/14/17 12:40 PM, Doug Simon wrote: > >> On 14 Feb 2017, at 21:28, Vladimir Kozlov wrote: >> >> I did not get the condition. Why a method is *compilable* if JVMCICompiler is not used? Should it be >> >> UseJVMCICompiler && !method->is_not_compilable( >> >> Then comment is wrong. Please, explain. > > If UseJVMCICompiler is false, then JVMCI is not being used by the VM as a jit but is only being used in hosted mode (e.g. by Truffle). The thinking was that hosted clients do not typically care about VM policies effecting the compilability of a method (e.g. whether it has a breakpoint etc). However, now that I reflect on this further, such clients should ignore this call altogether as they may be in a VM environment where both hosted and non-hosted compilations are being requested of JVMCI. With that in mind, I?ve updated the webrev to remove all mention and use of UseJVMCICompiler. > > -Doug > >> >> On 2/14/17 12:11 PM, Doug Simon wrote: >>> Please review this fix for a rather embarrassing bug I committed as part of JDK-8172733. >>> >>> http://cr.openjdk.java.net/~dnsimon/8174961/webrev/ >>> https://bugs.openjdk.java.net/browse/JDK-8174961 >>> >>> -Doug >>> > From doug.simon at oracle.com Tue Feb 14 20:59:07 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 14 Feb 2017 21:59:07 +0100 Subject: RFR: 8174961: [JVMCI] incorrect implementation of isCompilable In-Reply-To: <6d79a58c-5904-9479-262a-e99b0ad62e4d@oracle.com> References: <0C1BD311-DD7F-449B-BDF2-6736527FE7DB@oracle.com> <6d79a58c-5904-9479-262a-e99b0ad62e4d@oracle.com> Message-ID: > On 14 Feb 2017, at 21:47, Vladimir Kozlov wrote: > > Should you also remove flag check in previous lines in the test?: > > boolean isCompilable = CompilerToVMHelper.isCompilable(method); > boolean expected = UseJVMCICompiler || WB.isMethodCompilable(aMethod); > Yes, you?re right - webrev is updated with this change. Thanks for catching this oversight! -Doug > Thanks, > Vladimir > > On 2/14/17 12:40 PM, Doug Simon wrote: >> >>> On 14 Feb 2017, at 21:28, Vladimir Kozlov wrote: >>> >>> I did not get the condition. Why a method is *compilable* if JVMCICompiler is not used? Should it be >>> >>> UseJVMCICompiler && !method->is_not_compilable( >>> >>> Then comment is wrong. Please, explain. >> >> If UseJVMCICompiler is false, then JVMCI is not being used by the VM as a jit but is only being used in hosted mode (e.g. by Truffle). The thinking was that hosted clients do not typically care about VM policies effecting the compilability of a method (e.g. whether it has a breakpoint etc). However, now that I reflect on this further, such clients should ignore this call altogether as they may be in a VM environment where both hosted and non-hosted compilations are being requested of JVMCI. With that in mind, I?ve updated the webrev to remove all mention and use of UseJVMCICompiler. >> >> -Doug >> >>> >>> On 2/14/17 12:11 PM, Doug Simon wrote: >>>> Please review this fix for a rather embarrassing bug I committed as part of JDK-8172733. >>>> >>>> http://cr.openjdk.java.net/~dnsimon/8174961/webrev/ >>>> https://bugs.openjdk.java.net/browse/JDK-8174961 >>>> >>>> -Doug >>>> >> From vladimir.kozlov at oracle.com Tue Feb 14 22:01:17 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Feb 2017 14:01:17 -0800 Subject: RFR: 8174961: [JVMCI] incorrect implementation of isCompilable In-Reply-To: References: <0C1BD311-DD7F-449B-BDF2-6736527FE7DB@oracle.com> <6d79a58c-5904-9479-262a-e99b0ad62e4d@oracle.com> Message-ID: Good. Thanks, Vladimir On 2/14/17 12:59 PM, Doug Simon wrote: > >> On 14 Feb 2017, at 21:47, Vladimir Kozlov wrote: >> >> Should you also remove flag check in previous lines in the test?: >> >> boolean isCompilable = CompilerToVMHelper.isCompilable(method); >> boolean expected = UseJVMCICompiler || WB.isMethodCompilable(aMethod); >> > > Yes, you?re right - webrev is updated with this change. Thanks for catching this oversight! > > -Doug > >> Thanks, >> Vladimir >> >> On 2/14/17 12:40 PM, Doug Simon wrote: >>> >>>> On 14 Feb 2017, at 21:28, Vladimir Kozlov wrote: >>>> >>>> I did not get the condition. Why a method is *compilable* if JVMCICompiler is not used? Should it be >>>> >>>> UseJVMCICompiler && !method->is_not_compilable( >>>> >>>> Then comment is wrong. Please, explain. >>> >>> If UseJVMCICompiler is false, then JVMCI is not being used by the VM as a jit but is only being used in hosted mode (e.g. by Truffle). The thinking was that hosted clients do not typically care about VM policies effecting the compilability of a method (e.g. whether it has a breakpoint etc). However, now that I reflect on this further, such clients should ignore this call altogether as they may be in a VM environment where both hosted and non-hosted compilations are being requested of JVMCI. With that in mind, I?ve updated the webrev to remove all mention and use of UseJVMCICompiler. >>> >>> -Doug >>> >>>> >>>> On 2/14/17 12:11 PM, Doug Simon wrote: >>>>> Please review this fix for a rather embarrassing bug I committed as part of JDK-8172733. >>>>> >>>>> http://cr.openjdk.java.net/~dnsimon/8174961/webrev/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8174961 >>>>> >>>>> -Doug >>>>> >>> > From doug.simon at oracle.com Tue Feb 14 22:03:27 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 14 Feb 2017 23:03:27 +0100 Subject: RFR: 8174961: [JVMCI] incorrect implementation of isCompilable In-Reply-To: References: <0C1BD311-DD7F-449B-BDF2-6736527FE7DB@oracle.com> <6d79a58c-5904-9479-262a-e99b0ad62e4d@oracle.com> Message-ID: <156A154A-2D2A-40C6-A4A9-3CF899B86F23@oracle.com> Thanks for the thorough review. > On 14 Feb 2017, at 23:01, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 2/14/17 12:59 PM, Doug Simon wrote: >> >>> On 14 Feb 2017, at 21:47, Vladimir Kozlov wrote: >>> >>> Should you also remove flag check in previous lines in the test?: >>> >>> boolean isCompilable = CompilerToVMHelper.isCompilable(method); >>> boolean expected = UseJVMCICompiler || WB.isMethodCompilable(aMethod); >>> >> >> Yes, you?re right - webrev is updated with this change. Thanks for catching this oversight! >> >> -Doug >> >>> Thanks, >>> Vladimir >>> >>> On 2/14/17 12:40 PM, Doug Simon wrote: >>>> >>>>> On 14 Feb 2017, at 21:28, Vladimir Kozlov wrote: >>>>> >>>>> I did not get the condition. Why a method is *compilable* if JVMCICompiler is not used? Should it be >>>>> >>>>> UseJVMCICompiler && !method->is_not_compilable( >>>>> >>>>> Then comment is wrong. Please, explain. >>>> >>>> If UseJVMCICompiler is false, then JVMCI is not being used by the VM as a jit but is only being used in hosted mode (e.g. by Truffle). The thinking was that hosted clients do not typically care about VM policies effecting the compilability of a method (e.g. whether it has a breakpoint etc). However, now that I reflect on this further, such clients should ignore this call altogether as they may be in a VM environment where both hosted and non-hosted compilations are being requested of JVMCI. With that in mind, I?ve updated the webrev to remove all mention and use of UseJVMCICompiler. >>>> >>>> -Doug >>>> >>>>> >>>>> On 2/14/17 12:11 PM, Doug Simon wrote: >>>>>> Please review this fix for a rather embarrassing bug I committed as part of JDK-8172733. >>>>>> >>>>>> http://cr.openjdk.java.net/~dnsimon/8174961/webrev/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8174961 >>>>>> >>>>>> -Doug >>>>>> >>>> >> From rwestrel at redhat.com Wed Feb 15 09:40:56 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 15 Feb 2017 10:40:56 +0100 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: <03f84597-8a3a-668e-3971-f29dbaa117fc@oracle.com> References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> <4c95c8ef-0252-91a2-3b46-b0315ed2284a@oracle.com> <03f84597-8a3a-668e-3971-f29dbaa117fc@oracle.com> Message-ID: > Wow, so much changes. Doesn't that make my initial change (the one that only takes newer nodes into consideration) look more reasonable? > Can you add _irreducible_loop field to CallGenerator instead of passing as argument? The _irreducible_loop field only needs to be InlineCallGenerator so that does seem better. Unfortunately, LibraryIntrinsic objects are cached so there's no way to initialize _irreducible_loop for them (and there's a use of replaced nodes for the array copy intrinsic). Alternatively, we could use a coarser grain switch: make Compile::_parsed_irreducible_loop product and use it to decide whether to apply replaced nodes or not. Roland. From doug.simon at oracle.com Wed Feb 15 10:24:17 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 15 Feb 2017 11:24:17 +0100 Subject: RFR: 8174957: [JVMCI] jaotc is broken in Xcomp mode Message-ID: <46DCD4FD-6F32-457C-B242-6B488DC64FB6@oracle.com> Please review this fix for a bug introduced by JDK-8173912. The value written by readConfiguation (in jvmciCompilerToVM.cpp) to VMField.value may now be a Boolean. As such, the type of VMField.value must be Object. https://bugs.openjdk.java.net/browse/JDK-8174957 http://cr.openjdk.java.net/~dnsimon/8174957/webrev/ -Doug From rickard.backman at oracle.com Wed Feb 15 13:06:45 2017 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 15 Feb 2017 14:06:45 +0100 Subject: RFR(XS): 8165256: ARM64: vm/gc/concurrent/lp30yp10rp30mr0st300 Crash SIGBUS Message-ID: <20170215130645.GO8074@rbackman> Hi, can I please have this small change reviewed? We have seen crashes where it looks like a thread is seeing the call to the interpreter stub even though it doesn't yet see the correct values for the data and the jump. Adding both instruction cache invalidation of the interpreter stub when values are updated and a barrier between the stores of data/jump and the call. This is on the ARM64 platform (_arm). http://cr.openjdk.java.net/~rbackman/8165256/ https://bugs.openjdk.java.net/browse/JDK-8165256 Thanks /R From aph at redhat.com Wed Feb 15 15:02:05 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Feb 2017 15:02:05 +0000 Subject: RFR(XS): 8165256: ARM64: vm/gc/concurrent/lp30yp10rp30mr0st300 Crash SIGBUS In-Reply-To: <20170215130645.GO8074@rbackman> References: <20170215130645.GO8074@rbackman> Message-ID: <7e81666a-0b98-a3dc-47dd-6e2a09353750@redhat.com> On 15/02/17 13:06, Rickard B?ckman wrote: > Adding both instruction cache invalidation of the interpreter stub when > values are updated and a barrier between the stores of data/jump and the > call. I don't think the storestore fence does anything. ICache::invalidate_range should flush both caches to the point of unification. Andrew. From igor.veresov at oracle.com Wed Feb 15 16:32:55 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 15 Feb 2017 08:32:55 -0800 Subject: RFR: 8174957: [JVMCI] jaotc is broken in Xcomp mode In-Reply-To: <46DCD4FD-6F32-457C-B242-6B488DC64FB6@oracle.com> References: <46DCD4FD-6F32-457C-B242-6B488DC64FB6@oracle.com> Message-ID: <01C823A5-27F5-4071-A470-0CC15683D492@oracle.com> Looks good, but I think the following bit would also be required to fix this particular issue: diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java @@ -70,7 +70,7 @@ */ private void fillVMAddresses(HotSpotVMConfigStore config) { for (VMField vmField : config.getFields().values()) { - if (vmField.value != null) { + if (vmField.value != null && vmField.value instanceof Long) { final long address = vmField.value; String value = vmField.name; /* Thanks, igor > On Feb 15, 2017, at 2:24 AM, Doug Simon wrote: > > Please review this fix for a bug introduced by JDK-8173912. The value written by readConfiguation (in jvmciCompilerToVM.cpp) to VMField.value may now be a Boolean. As such, the type of VMField.value must be Object. > > https://bugs.openjdk.java.net/browse/JDK-8174957 > http://cr.openjdk.java.net/~dnsimon/8174957/webrev/ > > -Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Wed Feb 15 16:34:38 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 15 Feb 2017 08:34:38 -0800 Subject: RFR: 8174957: [JVMCI] jaotc is broken in Xcomp mode In-Reply-To: <01C823A5-27F5-4071-A470-0CC15683D492@oracle.com> References: <46DCD4FD-6F32-457C-B242-6B488DC64FB6@oracle.com> <01C823A5-27F5-4071-A470-0CC15683D492@oracle.com> Message-ID: <4973DEF7-4B7A-435A-AED0-8B6BD575F6A6@oracle.com> Sorry, it would also need a cast of course.. diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java @@ -70,8 +70,8 @@ */ private void fillVMAddresses(HotSpotVMConfigStore config) { for (VMField vmField : config.getFields().values()) { - if (vmField.value != null) { - final long address = vmField.value; + if (vmField.value != null && vmField.value instanceof Long) { + final long address = (Long) vmField.value; String value = vmField.name; /* * Some fields don't contain addresses but integer values. At least don't add zero > On Feb 15, 2017, at 8:32 AM, Igor Veresov wrote: > > Looks good, but I think the following bit would also be required to fix this particular issue: > > diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java > --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java > +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java > @@ -70,7 +70,7 @@ > */ > private void fillVMAddresses(HotSpotVMConfigStore config) { > for (VMField vmField : config.getFields().values()) { > - if (vmField.value != null) { > + if (vmField.value != null && vmField.value instanceof Long) { > final long address = vmField.value; > String value = vmField.name; > /* > > Thanks, > igor > >> On Feb 15, 2017, at 2:24 AM, Doug Simon > wrote: >> >> Please review this fix for a bug introduced by JDK-8173912. The value written by readConfiguation (in jvmciCompilerToVM.cpp) to VMField.value may now be a Boolean. As such, the type of VMField.value must be Object. >> >> https://bugs.openjdk.java.net/browse/JDK-8174957 >> http://cr.openjdk.java.net/~dnsimon/8174957/webrev/ >> >> -Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Wed Feb 15 16:46:30 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 15 Feb 2017 17:46:30 +0100 Subject: RFR: 8174957: [JVMCI] jaotc is broken in Xcomp mode In-Reply-To: <4973DEF7-4B7A-435A-AED0-8B6BD575F6A6@oracle.com> References: <46DCD4FD-6F32-457C-B242-6B488DC64FB6@oracle.com> <01C823A5-27F5-4071-A470-0CC15683D492@oracle.com> <4973DEF7-4B7A-435A-AED0-8B6BD575F6A6@oracle.com> Message-ID: Ok, I?ve updated the webrev. I assume the missing change to DataBuilder would have been caught by AOT specific tests in jprt? -Doug > On 15 Feb 2017, at 17:34, Igor Veresov wrote: > > Sorry, it would also need a cast of course.. > > diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java > --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java > +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java > @@ -70,8 +70,8 @@ > */ > private void fillVMAddresses(HotSpotVMConfigStore config) { > for (VMField vmField : config.getFields().values()) { > - if (vmField.value != null) { > - final long address = vmField.value; > + if (vmField.value != null && vmField.value instanceof Long) { > + final long address = (Long) vmField.value; > String value = vmField.name; > /* > * Some fields don't contain addresses but integer values. At least don't add zero > > >> On Feb 15, 2017, at 8:32 AM, Igor Veresov wrote: >> >> Looks good, but I think the following bit would also be required to fix this particular issue: >> >> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >> @@ -70,7 +70,7 @@ >> */ >> private void fillVMAddresses(HotSpotVMConfigStore config) { >> for (VMField vmField : config.getFields().values()) { >> - if (vmField.value != null) { >> + if (vmField.value != null && vmField.value instanceof Long) { >> final long address = vmField.value; >> String value = vmField.name; >> /* >> >> Thanks, >> igor >> >>> On Feb 15, 2017, at 2:24 AM, Doug Simon wrote: >>> >>> Please review this fix for a bug introduced by JDK-8173912. The value written by readConfiguation (in jvmciCompilerToVM.cpp) to VMField.value may now be a Boolean. As such, the type of VMField.value must be Object. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8174957 >>> http://cr.openjdk.java.net/~dnsimon/8174957/webrev/ >>> >>> -Doug >> > From igor.veresov at oracle.com Wed Feb 15 17:05:18 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 15 Feb 2017 09:05:18 -0800 Subject: RFR: 8174957: [JVMCI] jaotc is broken in Xcomp mode In-Reply-To: References: <46DCD4FD-6F32-457C-B242-6B488DC64FB6@oracle.com> <01C823A5-27F5-4071-A470-0CC15683D492@oracle.com> <4973DEF7-4B7A-435A-AED0-8B6BD575F6A6@oracle.com> Message-ID: <31C1E7F8-DBDE-4BA3-BF5C-2989D5AF2635@oracle.com> > On Feb 15, 2017, at 8:46 AM, Doug Simon wrote: > > Ok, I?ve updated the webrev. Thanks, looks good! > > I assume the missing change to DataBuilder would have been caught by AOT specific tests in jprt? > Yes, I think it would?ve failed building on linux x64. igor > -Doug > >> On 15 Feb 2017, at 17:34, Igor Veresov wrote: >> >> Sorry, it would also need a cast of course.. >> >> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >> @@ -70,8 +70,8 @@ >> */ >> private void fillVMAddresses(HotSpotVMConfigStore config) { >> for (VMField vmField : config.getFields().values()) { >> - if (vmField.value != null) { >> - final long address = vmField.value; >> + if (vmField.value != null && vmField.value instanceof Long) { >> + final long address = (Long) vmField.value; >> String value = vmField.name; >> /* >> * Some fields don't contain addresses but integer values. At least don't add zero >> >> >>> On Feb 15, 2017, at 8:32 AM, Igor Veresov wrote: >>> >>> Looks good, but I think the following bit would also be required to fix this particular issue: >>> >>> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>> @@ -70,7 +70,7 @@ >>> */ >>> private void fillVMAddresses(HotSpotVMConfigStore config) { >>> for (VMField vmField : config.getFields().values()) { >>> - if (vmField.value != null) { >>> + if (vmField.value != null && vmField.value instanceof Long) { >>> final long address = vmField.value; >>> String value = vmField.name; >>> /* >>> >>> Thanks, >>> igor >>> >>>> On Feb 15, 2017, at 2:24 AM, Doug Simon wrote: >>>> >>>> Please review this fix for a bug introduced by JDK-8173912. The value written by readConfiguation (in jvmciCompilerToVM.cpp) to VMField.value may now be a Boolean. As such, the type of VMField.value must be Object. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8174957 >>>> http://cr.openjdk.java.net/~dnsimon/8174957/webrev/ >>>> >>>> -Doug >>> >> > From doug.simon at oracle.com Wed Feb 15 17:19:12 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 15 Feb 2017 18:19:12 +0100 Subject: RFR: 8174957: [JVMCI] jaotc is broken in Xcomp mode In-Reply-To: <31C1E7F8-DBDE-4BA3-BF5C-2989D5AF2635@oracle.com> References: <46DCD4FD-6F32-457C-B242-6B488DC64FB6@oracle.com> <01C823A5-27F5-4071-A470-0CC15683D492@oracle.com> <4973DEF7-4B7A-435A-AED0-8B6BD575F6A6@oracle.com> <31C1E7F8-DBDE-4BA3-BF5C-2989D5AF2635@oracle.com> Message-ID: > On 15 Feb 2017, at 18:05, Igor Veresov wrote: > >> On Feb 15, 2017, at 8:46 AM, Doug Simon wrote: >> >> Ok, I?ve updated the webrev. > > Thanks, looks good! >> >> I assume the missing change to DataBuilder would have been caught by AOT specific tests in jprt? >> > > Yes, I think it would?ve failed building on linux x64. Good to know ;-) Thanks for the review. -Doug >> -Doug >> >>> On 15 Feb 2017, at 17:34, Igor Veresov wrote: >>> >>> Sorry, it would also need a cast of course.. >>> >>> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>> @@ -70,8 +70,8 @@ >>> */ >>> private void fillVMAddresses(HotSpotVMConfigStore config) { >>> for (VMField vmField : config.getFields().values()) { >>> - if (vmField.value != null) { >>> - final long address = vmField.value; >>> + if (vmField.value != null && vmField.value instanceof Long) { >>> + final long address = (Long) vmField.value; >>> String value = vmField.name; >>> /* >>> * Some fields don't contain addresses but integer values. At least don't add zero >>> >>> >>>> On Feb 15, 2017, at 8:32 AM, Igor Veresov wrote: >>>> >>>> Looks good, but I think the following bit would also be required to fix this particular issue: >>>> >>>> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>> @@ -70,7 +70,7 @@ >>>> */ >>>> private void fillVMAddresses(HotSpotVMConfigStore config) { >>>> for (VMField vmField : config.getFields().values()) { >>>> - if (vmField.value != null) { >>>> + if (vmField.value != null && vmField.value instanceof Long) { >>>> final long address = vmField.value; >>>> String value = vmField.name; >>>> /* >>>> >>>> Thanks, >>>> igor >>>> >>>>> On Feb 15, 2017, at 2:24 AM, Doug Simon wrote: >>>>> >>>>> Please review this fix for a bug introduced by JDK-8173912. The value written by readConfiguation (in jvmciCompilerToVM.cpp) to VMField.value may now be a Boolean. As such, the type of VMField.value must be Object. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8174957 >>>>> http://cr.openjdk.java.net/~dnsimon/8174957/webrev/ >>>>> >>>>> -Doug >>>> >>> >> > From vladimir.kozlov at oracle.com Wed Feb 15 18:16:15 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Feb 2017 10:16:15 -0800 Subject: RFR: 8174957: [JVMCI] jaotc is broken in Xcomp mode In-Reply-To: References: <46DCD4FD-6F32-457C-B242-6B488DC64FB6@oracle.com> <01C823A5-27F5-4071-A470-0CC15683D492@oracle.com> <4973DEF7-4B7A-435A-AED0-8B6BD575F6A6@oracle.com> <31C1E7F8-DBDE-4BA3-BF5C-2989D5AF2635@oracle.com> Message-ID: <99713bd0-1f98-1a4c-5155-588ecc7f29f6@oracle.com> On 2/15/17 9:19 AM, Doug Simon wrote: > >> On 15 Feb 2017, at 18:05, Igor Veresov wrote: >> >>> On Feb 15, 2017, at 8:46 AM, Doug Simon wrote: >>> >>> Ok, I?ve updated the webrev. >> >> Thanks, looks good! +1 >>> >>> I assume the missing change to DataBuilder would have been caught by AOT specific tests in jprt? >>> >> >> Yes, I think it would?ve failed building on linux x64. The original problem (with -Xcomp) was not caught by JPRT and Nightly testing because SQE stop running tests with -Xcomp flag. Only PIT testing, once per week, run them. But running RBT caught it - I hit it yesterday with testing jvmci module renaming. So we need to run our changes through RBT before pushing them. Thanks, Vladimir > > Good to know ;-) > > Thanks for the review. > > -Doug > >>> -Doug >>> >>>> On 15 Feb 2017, at 17:34, Igor Veresov wrote: >>>> >>>> Sorry, it would also need a cast of course.. >>>> >>>> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>> @@ -70,8 +70,8 @@ >>>> */ >>>> private void fillVMAddresses(HotSpotVMConfigStore config) { >>>> for (VMField vmField : config.getFields().values()) { >>>> - if (vmField.value != null) { >>>> - final long address = vmField.value; >>>> + if (vmField.value != null && vmField.value instanceof Long) { >>>> + final long address = (Long) vmField.value; >>>> String value = vmField.name; >>>> /* >>>> * Some fields don't contain addresses but integer values. At least don't add zero >>>> >>>> >>>>> On Feb 15, 2017, at 8:32 AM, Igor Veresov wrote: >>>>> >>>>> Looks good, but I think the following bit would also be required to fix this particular issue: >>>>> >>>>> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>>> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>>> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>>> @@ -70,7 +70,7 @@ >>>>> */ >>>>> private void fillVMAddresses(HotSpotVMConfigStore config) { >>>>> for (VMField vmField : config.getFields().values()) { >>>>> - if (vmField.value != null) { >>>>> + if (vmField.value != null && vmField.value instanceof Long) { >>>>> final long address = vmField.value; >>>>> String value = vmField.name; >>>>> /* >>>>> >>>>> Thanks, >>>>> igor >>>>> >>>>>> On Feb 15, 2017, at 2:24 AM, Doug Simon wrote: >>>>>> >>>>>> Please review this fix for a bug introduced by JDK-8173912. The value written by readConfiguation (in jvmciCompilerToVM.cpp) to VMField.value may now be a Boolean. As such, the type of VMField.value must be Object. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8174957 >>>>>> http://cr.openjdk.java.net/~dnsimon/8174957/webrev/ >>>>>> >>>>>> -Doug >>>>> >>>> >>> >> > From igor.veresov at oracle.com Wed Feb 15 18:23:25 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 15 Feb 2017 10:23:25 -0800 Subject: RFR: 8174957: [JVMCI] jaotc is broken in Xcomp mode In-Reply-To: <99713bd0-1f98-1a4c-5155-588ecc7f29f6@oracle.com> References: <46DCD4FD-6F32-457C-B242-6B488DC64FB6@oracle.com> <01C823A5-27F5-4071-A470-0CC15683D492@oracle.com> <4973DEF7-4B7A-435A-AED0-8B6BD575F6A6@oracle.com> <31C1E7F8-DBDE-4BA3-BF5C-2989D5AF2635@oracle.com> <99713bd0-1f98-1a4c-5155-588ecc7f29f6@oracle.com> Message-ID: <1A3B7212-8FBD-4113-B361-15F06E593A8F@oracle.com> > On Feb 15, 2017, at 10:16 AM, Vladimir Kozlov wrote: > > On 2/15/17 9:19 AM, Doug Simon wrote: >> >>> On 15 Feb 2017, at 18:05, Igor Veresov wrote: >>> >>>> On Feb 15, 2017, at 8:46 AM, Doug Simon wrote: >>>> >>>> Ok, I?ve updated the webrev. >>> >>> Thanks, looks good! > > +1 > >>>> >>>> I assume the missing change to DataBuilder would have been caught by AOT specific tests in jprt? >>>> >>> >>> Yes, I think it would?ve failed building on linux x64. > > The original problem (with -Xcomp) was not caught by JPRT and Nightly testing because SQE stop running tests with -Xcomp flag. Only PIT testing, once per week, run them. > > But running RBT caught it - I hit it yesterday with testing jvmci module renaming. > So we need to run our changes through RBT before pushing them. It?s alright, I?ve manually tested this one. But, yes, I guess, running RBT won?t hurt in general. igor > > Thanks, > Vladimir > >> >> Good to know ;-) >> >> Thanks for the review. >> >> -Doug >> >>>> -Doug >>>> >>>>> On 15 Feb 2017, at 17:34, Igor Veresov wrote: >>>>> >>>>> Sorry, it would also need a cast of course.. >>>>> >>>>> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>>> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>>> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>>> @@ -70,8 +70,8 @@ >>>>> */ >>>>> private void fillVMAddresses(HotSpotVMConfigStore config) { >>>>> for (VMField vmField : config.getFields().values()) { >>>>> - if (vmField.value != null) { >>>>> - final long address = vmField.value; >>>>> + if (vmField.value != null && vmField.value instanceof Long) { >>>>> + final long address = (Long) vmField.value; >>>>> String value = vmField.name; >>>>> /* >>>>> * Some fields don't contain addresses but integer values. At least don't add zero >>>>> >>>>> >>>>>> On Feb 15, 2017, at 8:32 AM, Igor Veresov wrote: >>>>>> >>>>>> Looks good, but I think the following bit would also be required to fix this particular issue: >>>>>> >>>>>> diff --git a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>>>> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>>>> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java >>>>>> @@ -70,7 +70,7 @@ >>>>>> */ >>>>>> private void fillVMAddresses(HotSpotVMConfigStore config) { >>>>>> for (VMField vmField : config.getFields().values()) { >>>>>> - if (vmField.value != null) { >>>>>> + if (vmField.value != null && vmField.value instanceof Long) { >>>>>> final long address = vmField.value; >>>>>> String value = vmField.name; >>>>>> /* >>>>>> >>>>>> Thanks, >>>>>> igor >>>>>> >>>>>>> On Feb 15, 2017, at 2:24 AM, Doug Simon wrote: >>>>>>> >>>>>>> Please review this fix for a bug introduced by JDK-8173912. The value written by readConfiguation (in jvmciCompilerToVM.cpp) to VMField.value may now be a Boolean. As such, the type of VMField.value must be Object. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8174957 >>>>>>> http://cr.openjdk.java.net/~dnsimon/8174957/webrev/ >>>>>>> >>>>>>> -Doug >>>>>> >>>>> >>>> >>> >> From vladimir.kozlov at oracle.com Wed Feb 15 20:15:10 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Feb 2017 12:15:10 -0800 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> <4c95c8ef-0252-91a2-3b46-b0315ed2284a@oracle.com> <03f84597-8a3a-668e-3971-f29dbaa117fc@oracle.com> Message-ID: <8993a656-c824-c29a-76ce-b35dd744832c@oracle.com> On 2/15/17 1:40 AM, Roland Westrelin wrote: > >> Wow, so much changes. > > Doesn't that make my initial change (the one that only takes newer nodes > into consideration) look more reasonable? Yes, I starting think to take my complains off and go with you original fix. Based on these latest changes it does not look worse (code generation wise). > >> Can you add _irreducible_loop field to CallGenerator instead of passing as argument? > > The _irreducible_loop field only needs to be InlineCallGenerator so that > does seem better. Unfortunately, LibraryIntrinsic objects are cached so > there's no way to initialize _irreducible_loop for them (and there's a > use of replaced nodes for the array copy intrinsic). > > Alternatively, we could use a coarser grain switch: make > Compile::_parsed_irreducible_loop product and use it to decide whether > to apply replaced nodes or not. This still leave my original concern that we may miss replacement optimization. I thought that we do immediate replacement without recording replacement nodes at all when we have irreducible loops. If we can't do that then lets go with you simple original fix. And thank you for explaining this problem in details to me. Vladimir > > Roland. > From vladimir.kozlov at oracle.com Wed Feb 15 20:18:27 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Feb 2017 12:18:27 -0800 Subject: JDK 10 RFR(S): 8173465: Introduce NearLabel for branches known to be short. In-Reply-To: <0c2255f342f14be598e7ff95eb0aefde@sap.com> References: <0f988f3f257047ce9fff5d0101ea65e0@DEROTE13DE04.global.corp.sap> <0a13fe2f-f58a-7266-cf43-c073479ec366@oracle.com> <0c2255f342f14be598e7ff95eb0aefde@sap.com> Message-ID: Okay, than it makes sense. One comment about changes I have is to use bool field instead of bit field for _is_near. Thanks, Vladimir On 2/14/17 1:38 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > For forward branches the branch instruction is decided on before > the Label is fixed. > Sometimes the decision which branch instruction to use must > be taken far down a call chain. You would have to pass down a > boolean flag 'useShortBranch' all the call chain. > > See emit_typecheck_helper in c1_LIRAssembler_s390.cpp http://hg.openjdk.java.net/jdk10/hs/hotspot/file/df8746afee77/src/cpu/s390/vm/c1_LIRAssembler_s390.cpp > > It gets a label from emit_opTypeCheck which can point to a stub entry. > This label is in some cases passed down > to check_class_subtype_fast_path. In other cases, a local label is > passed to this functions. We know for the local label the short > branch will suffice, not so for the label coming from extern. > So we use NearLable for the local one. > Check_class_subtype_fast_path passes the label on to a > s390 optimized branch emitter compare64_and_branch, which > then sees whether it's a NearLabel and uses the short branch. > > Best regards, > Goetz. > > > > > >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Dienstag, 14. Februar 2017 00:21 >> To: Lindenmaier, Goetz ; 'hotspot-compiler- >> dev at openjdk.java.net' >> Subject: Re: JDK 10 RFR(S): 8173465: Introduce NearLabel for branches known >> to be short. >> >> I assume you are talking about hand written assembler code snippets (stubs, >> etc.) >> >> Usually we use appropriate short branch instructions for short forward >> distance (and there is assert which check that it is correct). For back branches >> we do it automatically depending on distance. >> >> So why you need special NearLabel for s390? Can you just have general short >> branch macroassembler method for this? >> >> Thanks, >> Vladimir >> >> On 1/30/17 2:57 AM, Lindenmaier, Goetz wrote: >>> Hi >>> >>> please review this small optimization of Labels. >>> This so far targets s390, but could be used on other platforms as well. >>> I please need a sponsor. >>> http://cr.openjdk.java.net/~goetz/wr17/8173465- >> NearLbl/webrev.01/index.html >>> >>> Some branches issued to assembly code are obviously of short distance. >> Due to separation into shared and platform code this not always is known >> when the branch instruction is selected. >>> NearLabels indicate that a branch with short reach can be used. >>> >>> Best regards, >>> Goetz >>> From vladimir.kozlov at oracle.com Wed Feb 15 20:38:01 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Feb 2017 12:38:01 -0800 Subject: [10] RFR (M): 6986483: CHA: optimize calls through interfaces In-Reply-To: References: Message-ID: <118eb363-0cf8-a160-b5e0-ba5dbe00d27b@oracle.com> Seems fine to me. thanks, Vladimir K On 2/14/17 10:51 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-6986483 > > Proposed change adds CHA support in C2 for interface calls. > > Consider the following hierarchy: > > interface Intf { m(); } > class C implements Intf { public m() { ... } } > class C1 extends C { /* doesn't override m() */ } > ... > class Cn extends C { /* doesn't override m() */ } > > Call site: invokeinterface Intf.m() ... > > If Intf were an abstract class, CHA could deduce that Intf::m() can be replaced with C::m(), but it doesn't work for interfaces. Verifier doesn't check interface types in bytecode, so CHA can't assume > the receiver implements Intf. > > CHA in C1 handles such call sites for interfaces with a single implementor. It replaces invokeinterface Intf.m() with invokevirtual C.m() guarded by a subtype check (instanceof C). C2 doesn't do that > and this request is about adding that. Type profiling doesn't help here (the call site is usually megamorphic), so C2 can't inline it. > > The proposed implementation is similar to C1, except that the code deoptimizes when subtype check fails and ICCE is thrown from the interpreter. > > While working on it, I spotted and fixed a couple of inefficiencies in C1 implementation: > > (1) dependency context being used was broader than necessary - resolved instead of declared interface (hence, possibility of unnecessary invalidations); > > (2) didn't work for interfaces w/ any default methods: CHA doesn't support default methods at the moment, so what matters is whether Intf::m() is default or not and not whether Intf has *any* > concrete methods. > > Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress), LogCompilation tool. > > Thanks! > > Best regards, > Vladimir Ivanov From cthalinger at twitter.com Wed Feb 15 21:46:14 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 15 Feb 2017 11:46:14 -1000 Subject: RFR: Fix for JDK-8173119, compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java fails with custom Tiered Level set externally In-Reply-To: References: Message-ID: Sorry, I?m late to the party and I see there are many comments in the bug but I don?t agree with the fix. Printing a warning is fine but setting: + TieredStopAtLevel = CompLevel_full_optimization; because EnableJVMCI is turned on is just wrong. It should be perfectly fine to run in tiered mode with a JVMCI compiler but limit compilations to a lower level. It's not different than running with C2. The issue at hand happens because the test is using +BootstrapJVMCI and (understandably) the test wants the bootstrap to happen. I think the fix needs to be in the test. > On Jan 31, 2017, at 8:17 PM, Oleg Pliss wrote: > > http://cr.openjdk.java.net/~kvn/8173119/webrev/ > From cthalinger at twitter.com Wed Feb 15 21:56:41 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 15 Feb 2017 11:56:41 -1000 Subject: Running jaotc with an external Graal In-Reply-To: <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> Message-ID: <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> > On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: > > On 14/02/17 14:37, Alan Bateman wrote: >> --patch-module can be used to patch any module in the boot layer. So if >> you are looking to override or add classes then --patch-module should work. > > Aha! Thanks, Does it? From mandy.chung at oracle.com Wed Feb 15 22:44:19 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 14:44:19 -0800 Subject: Running jaotc with an external Graal In-Reply-To: <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> Message-ID: <9AFEE7EF-BCB8-47E3-B8D7-0BF1E2274805@oracle.com> > On Feb 15, 2017, at 1:56 PM, Christian Thalinger wrote: > > >> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >> >> On 14/02/17 14:37, Alan Bateman wrote: >>> --patch-module can be used to patch any module in the boot layer. So if >>> you are looking to override or add classes then --patch-module should work. >> >> Aha! Thanks, > > Does it? Yes it does except that module-info.class can?t be patched. You will get a warning if the patched path contains module-info.class. Are you seeing the otherwise? Mandy From forax at univ-mlv.fr Wed Feb 15 23:43:40 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 16 Feb 2017 00:43:40 +0100 (CET) Subject: Running jaotc with an external Graal In-Reply-To: <9AFEE7EF-BCB8-47E3-B8D7-0BF1E2274805@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <9AFEE7EF-BCB8-47E3-B8D7-0BF1E2274805@oracle.com> Message-ID: <716343417.1404138.1487202220423.JavaMail.zimbra@u-pem.fr> Can i say again that when using --patch-module, module-info.class should be merged instead of having a warning ? R?mi ----- Mail original ----- > De: "Mandy Chung" > ?: "Christian Thalinger" > Cc: jigsaw-dev at openjdk.java.net, "hotspot compiler" , graal-dev at openjdk.java.net > Envoy?: Mercredi 15 F?vrier 2017 23:44:19 > Objet: Re: Running jaotc with an external Graal >> On Feb 15, 2017, at 1:56 PM, Christian Thalinger wrote: >> >> >>> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >>> >>> On 14/02/17 14:37, Alan Bateman wrote: >>>> --patch-module can be used to patch any module in the boot layer. So if >>>> you are looking to override or add classes then --patch-module should work. >>> >>> Aha! Thanks, >> >> Does it? > > Yes it does except that module-info.class can?t be patched. You will get a > warning if the patched path contains module-info.class. Are you seeing the > otherwise? > > Mandy From vladimir.kozlov at oracle.com Thu Feb 16 01:37:15 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Feb 2017 17:37:15 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci Message-ID: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8174879 jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. Webrevs: top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ Tested with RBT. Thanks, Vladimir From mandy.chung at oracle.com Thu Feb 16 04:35:32 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 20:35:32 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> Message-ID: <1A3EDC42-9BFD-46E1-B8B7-04A6A781F891@oracle.com> > On Feb 15, 2017, at 5:37 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8174879 > > jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. > > Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. > Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. > > Webrevs: > > top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ > jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ > hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ The change looks fine to me. Mandy From vladimir.kozlov at oracle.com Thu Feb 16 06:09:36 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Feb 2017 22:09:36 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <1A3EDC42-9BFD-46E1-B8B7-04A6A781F891@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <1A3EDC42-9BFD-46E1-B8B7-04A6A781F891@oracle.com> Message-ID: <61ca272f-419b-902e-50ff-f7536f060cb7@oracle.com> Thank you, Mandy Vladimir On 2/15/17 8:35 PM, Mandy Chung wrote: > >> On Feb 15, 2017, at 5:37 PM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8174879 >> >> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >> >> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >> >> Webrevs: >> >> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ > > The change looks fine to me. > > Mandy > From goetz.lindenmaier at sap.com Thu Feb 16 06:40:56 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 Feb 2017 06:40:56 +0000 Subject: JDK 10 RFR(S): 8173465: Introduce NearLabel for branches known to be short. In-Reply-To: References: <0f988f3f257047ce9fff5d0101ea65e0@DEROTE13DE04.global.corp.sap> <0a13fe2f-f58a-7266-cf43-c073479ec366@oracle.com> <0c2255f342f14be598e7ff95eb0aefde@sap.com> Message-ID: <8c476343e90d4b4885d8c7180c8fe18e@sap.com> Hi Vladimir, I changed the field to Boolean. http://cr.openjdk.java.net/~goetz/wr17/8173465-NearLbl/webrev.02/ Thanks for looking at this! Best regards, Goetz. > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 15. Februar 2017 22:18 > To: Lindenmaier, Goetz ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: Re: JDK 10 RFR(S): 8173465: Introduce NearLabel for branches known > to be short. > > Okay, than it makes sense. One comment about changes I have is to use bool > field instead of bit field for _is_near. > > Thanks, > Vladimir > > On 2/14/17 1:38 AM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > > > For forward branches the branch instruction is decided on before > > the Label is fixed. > > Sometimes the decision which branch instruction to use must > > be taken far down a call chain. You would have to pass down a > > boolean flag 'useShortBranch' all the call chain. > > > > See emit_typecheck_helper in c1_LIRAssembler_s390.cpp > http://hg.openjdk.java.net/jdk10/hs/hotspot/file/df8746afee77/src/cpu/s390 > /vm/c1_LIRAssembler_s390.cpp > > > > It gets a label from emit_opTypeCheck which can point to a stub entry. > > This label is in some cases passed down > > to check_class_subtype_fast_path. In other cases, a local label is > > passed to this functions. We know for the local label the short > > branch will suffice, not so for the label coming from extern. > > So we use NearLable for the local one. > > Check_class_subtype_fast_path passes the label on to a > > s390 optimized branch emitter compare64_and_branch, which > > then sees whether it's a NearLabel and uses the short branch. > > > > Best regards, > > Goetz. > > > > > > > > > > > >> -----Original Message----- > >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > >> Sent: Dienstag, 14. Februar 2017 00:21 > >> To: Lindenmaier, Goetz ; 'hotspot- > compiler- > >> dev at openjdk.java.net' > >> Subject: Re: JDK 10 RFR(S): 8173465: Introduce NearLabel for branches > known > >> to be short. > >> > >> I assume you are talking about hand written assembler code snippets > (stubs, > >> etc.) > >> > >> Usually we use appropriate short branch instructions for short forward > >> distance (and there is assert which check that it is correct). For back > branches > >> we do it automatically depending on distance. > >> > >> So why you need special NearLabel for s390? Can you just have general > short > >> branch macroassembler method for this? > >> > >> Thanks, > >> Vladimir > >> > >> On 1/30/17 2:57 AM, Lindenmaier, Goetz wrote: > >>> Hi > >>> > >>> please review this small optimization of Labels. > >>> This so far targets s390, but could be used on other platforms as well. > >>> I please need a sponsor. > >>> http://cr.openjdk.java.net/~goetz/wr17/8173465- > >> NearLbl/webrev.01/index.html > >>> > >>> Some branches issued to assembly code are obviously of short distance. > >> Due to separation into shared and platform code this not always is > known > >> when the branch instruction is selected. > >>> NearLabels indicate that a branch with short reach can be used. > >>> > >>> Best regards, > >>> Goetz > >>> From magnus.ihse.bursie at oracle.com Thu Feb 16 07:54:53 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 16 Feb 2017 08:54:53 +0100 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> Message-ID: <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> On 2017-02-16 02:37, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8174879 > > jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is > only of interest to VM developers (and researchers), not general Java > developers. It'd be appropriate for it to be an internal module and > not to export any API. > > Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and > jdk.internal.vm.compiler. No packages renaming. > Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. > > Webrevs: > > top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ > jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ > hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ Looks good to me. /Magnus > > Tested with RBT. > > Thanks, > Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.backman at oracle.com Thu Feb 16 07:56:09 2017 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Thu, 16 Feb 2017 08:56:09 +0100 Subject: RFR(XS): 8165256: ARM64: vm/gc/concurrent/lp30yp10rp30mr0st300 Crash SIGBUS In-Reply-To: <7e81666a-0b98-a3dc-47dd-6e2a09353750@redhat.com> References: <20170215130645.GO8074@rbackman> <7e81666a-0b98-a3dc-47dd-6e2a09353750@redhat.com> Message-ID: <20170216075609.GP8074@rbackman> Thank you Andrew. I wasn't entirely sure about that. I'll remove the storestore. On 02/15, Andrew Haley wrote: > On 15/02/17 13:06, Rickard B?ckman wrote: > > Adding both instruction cache invalidation of the interpreter stub when > > values are updated and a barrier between the stores of data/jump and the > > call. > > I don't think the storestore fence does anything. ICache::invalidate_range > should flush both caches to the point of unification. > > Andrew. > /R From goetz.lindenmaier at sap.com Thu Feb 16 08:26:51 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 Feb 2017 08:26:51 +0000 Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. Message-ID: Hi, Constant shift operand > 31 (int) or > 63 (long) are pointless. Mask them in the ideal graph, i.e. if a constant is too large replace it by a smaller one. The code also should use BitsPerJavaInteger instead of BitsPerInt. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.01 >From the standard: https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19 If the promoted type of the left-hand operand is int, only the five lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & (?15.22.1) with the mask value 0x1f (0b11111). The shift distance actually used is therefore always in the range 0 to 31, inclusive. If the promoted type of the left-hand operand is long, then only the six lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & (?15.22.1) with the mask value 0x3f (0b111111). The shift distance actually used is therefore always in the range 0 to 63, inclusive. Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwestrel at redhat.com Thu Feb 16 08:56:06 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 16 Feb 2017 09:56:06 +0100 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: <8993a656-c824-c29a-76ce-b35dd744832c@oracle.com> References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> <4c95c8ef-0252-91a2-3b46-b0315ed2284a@oracle.com> <03f84597-8a3a-668e-3971-f29dbaa117fc@oracle.com> <8993a656-c824-c29a-76ce-b35dd744832c@oracle.com> Message-ID: I saw you pushed it. Thanks! > And thank you for explaining this problem in details to me. Well, thanks for taking the time to discuss it. Roland. From aph at redhat.com Thu Feb 16 09:13:47 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Feb 2017 09:13:47 +0000 Subject: RFR(XS): 8165256: ARM64: vm/gc/concurrent/lp30yp10rp30mr0st300 Crash SIGBUS In-Reply-To: <20170216075609.GP8074@rbackman> References: <20170215130645.GO8074@rbackman> <7e81666a-0b98-a3dc-47dd-6e2a09353750@redhat.com> <20170216075609.GP8074@rbackman> Message-ID: On 16/02/17 07:56, Rickard B?ckman wrote: > Thank you Andrew. > > I wasn't entirely sure about that. I'll remove the storestore. With that change the patch is OK. Andrew. From aph at redhat.com Thu Feb 16 09:17:12 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Feb 2017 09:17:12 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> Message-ID: <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> On 15/02/17 21:56, Christian Thalinger wrote: > >> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >> >> On 14/02/17 14:37, Alan Bateman wrote: >>> --patch-module can be used to patch any module in the boot layer. So if >>> you are looking to override or add classes then --patch-module should work. >> >> Aha! Thanks, > > Does it? Not quite. The problem is that the service loader finds classes in the Hotspot copy of Graal which don't exist in the external copy, and chaos ensues. I suppose the only way to make it work is to replace the copy of Graal in HotSpot, but I don't think that's a trivial thing to do. Andrew. From doug.simon at oracle.com Thu Feb 16 09:33:42 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 Feb 2017 10:33:42 +0100 Subject: Running jaotc with an external Graal In-Reply-To: <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> Message-ID: <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK: java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version However, the --patch-module + --upgrade-module-path trick[1] we?re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung: "-?patch-module is to patch a module to replace or add content of that module and yes it disables the hash checking on the patched module. However, it?s not intended to allow it to combine with ?-upgrade-module-path as you did, to change the module dependences." Given all the continuing flux around jigsaw, we cannot be sure that developing and using GitHub Graal on JDK 9 is stable until jigsaw is stable. -Doug [1] https://bugs.openjdk.java.net/browse/JDK-8171448?focusedCommentId=14046154&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14046154 > On 16 Feb 2017, at 10:17, Andrew Haley wrote: > > On 15/02/17 21:56, Christian Thalinger wrote: >> >>> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >>> >>> On 14/02/17 14:37, Alan Bateman wrote: >>>> --patch-module can be used to patch any module in the boot layer. So if >>>> you are looking to override or add classes then --patch-module should work. >>> >>> Aha! Thanks, >> >> Does it? > > Not quite. The problem is that the service loader finds classes in > the Hotspot copy of Graal which don't exist in the external copy, and > chaos ensues. > > I suppose the only way to make it work is to replace the copy of Graal > in HotSpot, but I don't think that's a trivial thing to do. > > Andrew. > From doug.simon at oracle.com Thu Feb 16 10:01:19 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 Feb 2017 11:01:19 +0100 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> Message-ID: <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> Just to note here, this means an external version of Graal will now have to use --add-exports VM options to access JVMCI. Which is ok since additional VM options are required anyway to put an external Graal on the module path. -Doug > On 16 Feb 2017, at 08:54, Magnus Ihse Bursie wrote: > > On 2017-02-16 02:37, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8174879 >> >> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >> >> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >> >> Webrevs: >> >> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ > > Looks good to me. > > /Magnus >> >> Tested with RBT. >> >> Thanks, >> Vladimir > From rwestrel at redhat.com Thu Feb 16 12:14:54 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 16 Feb 2017 13:14:54 +0100 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> <4c95c8ef-0252-91a2-3b46-b0315ed2284a@oracle.com> <03f84597-8a3a-668e-3971-f29dbaa117fc@oracle.com> <8993a656-c824-c29a-76ce-b35dd744832c@oracle.com> Message-ID: > I saw you pushed it. Thanks! I noticed the test case is not in the changeset. Roland. From aph at redhat.com Thu Feb 16 12:25:04 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Feb 2017 12:25:04 +0000 Subject: Running jaotc with an external Graal In-Reply-To: <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> Message-ID: <8093ab13-e039-c03c-136d-4518e46e1d81@redhat.com> On 16/02/17 09:33, Doug Simon wrote: > With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK: > > java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version > > However, the --patch-module + --upgrade-module-path trick[1] we?re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung: Magic, thank you. This works: ~/jdk10/hs/build/linux-aarch64-normal-server-release/jdk/bin/java \ -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI \ --add-exports=java.base/jdk.internal.module=jdk.vm.compiler \ --upgrade-module-path=/nfs/zebedee/home/graal/aph/graal-core/mxbuild/modules/jdk.vm.compiler.jar \ --patch-module=jdk.vm.compiler=.jar \ --module-path=/nfs/zebedee/home/graal/aph/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar:/nfs/zebedee/home/graal/aph/graal-core/mxbuild/modules/jdk.vm.compiler.jar \ -XX:+UseAOT -Djvmci.UseProfilingInformation=false \ -Dgraal.UseExceptionProbability=false -Djvmci.Compiler=graal \ --add-modules ALL-DEFAULT -m jdk.aot/jdk.tools.jaotc.Main ~/Hello.jar \ --output libHello.so I'm posting it here for posterity. It would indeed be very bad if we could not do something at least equivalent to this. Andrew. From lutz.schmidt at sap.com Thu Feb 16 15:55:20 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 16 Feb 2017 15:55:20 +0000 Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. In-Reply-To: References: Message-ID: Goetz, Your changes look good. Thanks for cleaning up! I do have one request, though: In the Ideal methods, you are using either local variable names con/in2_con or shift/in2_shift. Could you please decide for one variant? Thank you. Best regards, Lutz From: hotspot-compiler-dev > on behalf of G?tz Lindenmaier > Date: Donnerstag, 16. Februar 2017 um 09:26 To: "'hotspot-compiler-dev at openjdk.java.net'" > Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. Hi, Constant shift operand > 31 (int) or > 63 (long) are pointless. Mask them in the ideal graph, i.e. if a constant is too large replace it by a smaller one. The code also should use BitsPerJavaInteger instead of BitsPerInt. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.01 >From the standard: https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19 If the promoted type of the left-hand operand is int, only the five lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & (?15.22.1) with the mask value 0x1f (0b11111). The shift distance actually used is therefore always in the range 0 to 31, inclusive. If the promoted type of the left-hand operand is long, then only the six lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & (?15.22.1) with the mask value 0x3f (0b111111). The shift distance actually used is therefore always in the range 0 to 63, inclusive. Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Feb 16 15:57:08 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Feb 2017 07:57:08 -0800 Subject: Running jaotc with an external Graal In-Reply-To: <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> References: <5EF9A80E-8E23-4DB5-96CB-38E861F6D4A0@oracle.com> <677898c0-cc47-cea4-355d-a72bbcf80f7b@redhat.com> <4dd82907-8da0-ac21-92f9-8c784ec2674a@oracle.com> <933396d6-b5eb-290d-831c-b8883de8c025@redhat.com> <4674B2C0-9C4C-4B99-AF04-84A1AA39015A@twitter.com> <3570b9d9-aeb3-bff1-e38b-d473d8b41474@redhat.com> <455F160E-8154-4C93-8555-626289BC2BB3@oracle.com> Message-ID: <5DEE9908-53E3-4B4D-82A9-EE2A8D7D4DFB@oracle.com> > On Feb 16, 2017, at 1:33 AM, Doug Simon wrote: > > With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK: > > java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar --upgrade-module-path=/Users/dsimon/hs/graal-core/mxbuild/modules/jdk.vm.compiler.jar --patch-module=jdk.vm.compiler=.jar -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI -version > > However, the --patch-module + --upgrade-module-path trick[1] we?re using to replace the version of Graal in the JDK apparently only works due to a bug that will be fixed at some point. From Mandy Chung: > > "-?patch-module is to patch a module to replace or add content of that module and yes it disables the hash checking on the patched module. However, it?s not intended to allow it to combine with ?-upgrade-module-path as you did, to change the module dependences.? > It?s a bug that --patch-module + --upgrade-module-path work as described above. I have a patch to fix ?-patch-module that no longer has to disable the hash checking but allow patching the content of the mdoule. I think we will need to look into the alternatives how Graal can be upgraded to a different version of module-info.class. Mandy > Given all the continuing flux around jigsaw, we cannot be sure that developing and using GitHub Graal on JDK 9 is stable until jigsaw is stable. > > -Doug > > [1] https://bugs.openjdk.java.net/browse/JDK-8171448?focusedCommentId=14046154&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14046154 > >> On 16 Feb 2017, at 10:17, Andrew Haley wrote: >> >> On 15/02/17 21:56, Christian Thalinger wrote: >>> >>>> On Feb 14, 2017, at 4:38 AM, Andrew Haley wrote: >>>> >>>> On 14/02/17 14:37, Alan Bateman wrote: >>>>> --patch-module can be used to patch any module in the boot layer. So if >>>>> you are looking to override or add classes then --patch-module should work. >>>> >>>> Aha! Thanks, >>> >>> Does it? >> >> Not quite. The problem is that the service loader finds classes in >> the Hotspot copy of Graal which don't exist in the external copy, and >> chaos ensues. >> >> I suppose the only way to make it work is to replace the copy of Graal >> in HotSpot, but I don't think that's a trivial thing to do. >> >> Andrew. >> > From goetz.lindenmaier at sap.com Thu Feb 16 17:03:36 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 Feb 2017 17:03:36 +0000 Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. In-Reply-To: References: Message-ID: <69ee78c1ee774309980ba5bae62bb066@sap.com> Hi Lutz, thanks for the review. What about naming them con and maskedCon? Best regards, Goetz > -----Original Message----- > From: Schmidt, Lutz > Sent: Donnerstag, 16. Februar 2017 17:55 > To: Lindenmaier, Goetz ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > > Goetz, > > Your changes look good. Thanks for cleaning up! > > I do have one request, though: > In the Ideal methods, you are using either local variable names con/in2_con > or shift/in2_shift. Could you please decide for one variant? Thank you. > > Best regards, > Lutz > > From: hotspot-compiler-dev bounces at openjdk.java.net bounces at openjdk.java.net> > on behalf of G?tz Lindenmaier > > > Date: Donnerstag, 16. Februar 2017 um 09:26 > To: "'hotspot-compiler-dev at openjdk.java.net dev at openjdk.java.net> '" > > Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > > > > Hi, > > > > Constant shift operand > 31 (int) or > 63 (long) are pointless. > > Mask them in the ideal graph, i.e. > > if a constant is too large replace it by a smaller one. > > The code also should use BitsPerJavaInteger instead of BitsPerInt. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.01 > > > From the standard: > https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19 > > If the promoted type of the left-hand operand is int, only the five lowest- > order bits of the right-hand operand are used as the shift distance. It is as if > the right-hand operand were subjected to a bitwise logical AND operator & > (?15.22.1) with the mask value 0x1f (0b11111). The shift distance actually > used is therefore always in the range 0 to 31, inclusive. > > If the promoted type of the left-hand operand is long, then only the six > lowest-order bits of the right-hand operand are used as the shift distance. It > is as if the right-hand operand were subjected to a bitwise logical AND > operator & (?15.22.1) with the mask value 0x3f (0b111111). The shift > distance actually used is therefore always in the range 0 to 63, inclusive. > > > > Best regards, > > Goetz. From vladimir.kozlov at oracle.com Thu Feb 16 18:24:52 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Feb 2017 10:24:52 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> Message-ID: <678ae64e-aae8-74d3-c382-e47b17005be6@oracle.com> Thank you, Magnus Vladimir On 2/15/17 11:54 PM, Magnus Ihse Bursie wrote: > On 2017-02-16 02:37, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8174879 >> >> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and >> researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >> >> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >> >> Webrevs: >> >> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ > > Looks good to me. > > /Magnus >> >> Tested with RBT. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Thu Feb 16 18:30:59 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Feb 2017 10:30:59 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> Message-ID: <73ae8fc4-2641-eb1e-e1d7-34738801648f@oracle.com> Hi Doug, Is it because of next change?: module jdk.internal.vm.ci { - exports jdk.vm.ci.services; + exports jdk.vm.ci.services to jdk.internal.vm.compiler; But you said before that your version of graal has the same module name. Why you need --add-exports? Thanks, Vladimir On 2/16/17 2:01 AM, Doug Simon wrote: > Just to note here, this means an external version of Graal will now have to use --add-exports VM options to access JVMCI. Which is ok since additional VM options are required anyway to put an external Graal on the module path. > > -Doug > >> On 16 Feb 2017, at 08:54, Magnus Ihse Bursie wrote: >> >> On 2017-02-16 02:37, Vladimir Kozlov wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8174879 >>> >>> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >>> >>> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >>> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >>> >>> Webrevs: >>> >>> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >>> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >>> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ >> >> Looks good to me. >> >> /Magnus >>> >>> Tested with RBT. >>> >>> Thanks, >>> Vladimir >> > From doug.simon at oracle.com Thu Feb 16 18:57:14 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 Feb 2017 19:57:14 +0100 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <73ae8fc4-2641-eb1e-e1d7-34738801648f@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> <73ae8fc4-2641-eb1e-e1d7-34738801648f@oracle.com> Message-ID: <9B8A67FE-A748-4599-B9BC-A6D1BBF3F576@oracle.com> > On 16 Feb 2017, at 19:30, Vladimir Kozlov wrote: > > Hi Doug, > > Is it because of next change?: > > module jdk.internal.vm.ci { > - exports jdk.vm.ci.services; > + exports jdk.vm.ci.services to jdk.internal.vm.compiler; > > But you said before that your version of graal has the same module name. Why you need --add-exports? I am projecting ahead to the bug fix Mandy talks about in http://mail.openjdk.java.net/pipermail/graal-dev/2017-February/004889.html which means patching in an external version of Graal will no longer benefit from the qualified exports of JVMCI to jdk.vm.compiler. -Doug > On 2/16/17 2:01 AM, Doug Simon wrote: >> Just to note here, this means an external version of Graal will now have to use --add-exports VM options to access JVMCI. Which is ok since additional VM options are required anyway to put an external Graal on the module path. >> >> -Doug >> >>> On 16 Feb 2017, at 08:54, Magnus Ihse Bursie wrote: >>> >>> On 2017-02-16 02:37, Vladimir Kozlov wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8174879 >>>> >>>> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >>>> >>>> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >>>> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >>>> >>>> Webrevs: >>>> >>>> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >>>> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >>>> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ >>> >>> Looks good to me. >>> >>> /Magnus >>>> >>>> Tested with RBT. >>>> >>>> Thanks, >>>> Vladimir >>> >> From vivek.r.deshpande at intel.com Thu Feb 16 19:45:56 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 16 Feb 2017 19:45:56 +0000 Subject: RFR(S): 8175096: Use Subword Analysis for set vector size Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A63C6F5E1@ORSMSX106.amr.corp.intel.com> Hi Currently subword types cannot use entire vector width using SLP. This fix analyzes the subword in the loop for possibility of narrowing and sets the vector size accordingly. Webrev: http://cr.openjdk.java.net/~vdeshpande/8175096/webrev.00/ I have also updated the JBS entry. https://bugs.openjdk.java.net/browse/JDK-8175096 Would you please review and sponsor it. Regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Feb 16 19:50:02 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Feb 2017 11:50:02 -0800 Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. In-Reply-To: <69ee78c1ee774309980ba5bae62bb066@sap.com> References: <69ee78c1ee774309980ba5bae62bb066@sap.com> Message-ID: <5330af15-cd8b-5b81-7acd-4a4c7de479dd@oracle.com> Thank you, Goetz Very nice cleanup! On 2/16/17 9:03 AM, Lindenmaier, Goetz wrote: > Hi Lutz, > > thanks for the review. > > What about naming them con and maskedCon? shift and maskedShift And since you are doing cleanup ;) I want to ask you to factor out in separate methods (for long and int) checks which are duplicated in all this methods. All of them check if in(2) is integer constant and mask it. Thanks, Vladimir > > Best regards, > Goetz > >> -----Original Message----- >> From: Schmidt, Lutz >> Sent: Donnerstag, 16. Februar 2017 17:55 >> To: Lindenmaier, Goetz ; 'hotspot-compiler- >> dev at openjdk.java.net' >> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >> >> Goetz, >> >> Your changes look good. Thanks for cleaning up! >> >> I do have one request, though: >> In the Ideal methods, you are using either local variable names con/in2_con >> or shift/in2_shift. Could you please decide for one variant? Thank you. >> >> Best regards, >> Lutz >> >> From: hotspot-compiler-dev > bounces at openjdk.java.net > bounces at openjdk.java.net> > on behalf of G?tz Lindenmaier >> > >> Date: Donnerstag, 16. Februar 2017 um 09:26 >> To: "'hotspot-compiler-dev at openjdk.java.net > dev at openjdk.java.net> '" > > >> Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >> >> >> >> Hi, >> >> >> >> Constant shift operand > 31 (int) or > 63 (long) are pointless. >> >> Mask them in the ideal graph, i.e. >> >> if a constant is too large replace it by a smaller one. >> >> The code also should use BitsPerJavaInteger instead of BitsPerInt. >> >> Please review this change. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.01 >> >> >> From the standard: >> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19 >> >> If the promoted type of the left-hand operand is int, only the five lowest- >> order bits of the right-hand operand are used as the shift distance. It is as if >> the right-hand operand were subjected to a bitwise logical AND operator & >> (?15.22.1) with the mask value 0x1f (0b11111). The shift distance actually >> used is therefore always in the range 0 to 31, inclusive. >> >> If the promoted type of the left-hand operand is long, then only the six >> lowest-order bits of the right-hand operand are used as the shift distance. It >> is as if the right-hand operand were subjected to a bitwise logical AND >> operator & (?15.22.1) with the mask value 0x3f (0b111111). The shift >> distance actually used is therefore always in the range 0 to 63, inclusive. >> >> >> >> Best regards, >> >> Goetz. > From vladimir.kozlov at oracle.com Thu Feb 16 19:59:45 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Feb 2017 11:59:45 -0800 Subject: [9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: <89c4dd58-30a3-f5e5-4617-200506c7e88e@oracle.com> <3116dc2c-0aba-1675-38f5-6e32af050d59@oracle.com> <4c95c8ef-0252-91a2-3b46-b0315ed2284a@oracle.com> <03f84597-8a3a-668e-3971-f29dbaa117fc@oracle.com> <8993a656-c824-c29a-76ce-b35dd744832c@oracle.com> Message-ID: <55e71b88-f2db-38d2-78e0-bff79979c5e0@oracle.com> Changeset was not applied cleanly because test had trailing spaces. I have to fix it and forgot to hg add it. I filed bug https://bugs.openjdk.java.net/browse/JDK-8175097 Thanks, Vladimir On 2/16/17 4:14 AM, Roland Westrelin wrote: > >> I saw you pushed it. Thanks! > > I noticed the test case is not in the changeset. > > Roland. > From paul.sandoz at oracle.com Thu Feb 16 20:00:16 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 16 Feb 2017 12:00:16 -0800 Subject: [10] RFR (M): 6986483: CHA: optimize calls through interfaces In-Reply-To: References: Message-ID: <2080EA54-B6F3-4EC2-8093-0FD935EC872E@oracle.com> Hi, This is a nice surprise :-) I happened to be separately looking at this area, analysing the performance of interfaces/abstract classes to apply a certain implementation technique to avoid going megamorphic. I concluded that the implementation technique was not viable, but with your patch i think i can revive it and perform more detailed analysis. Based on my benchmark the performance improvement looks good. Thanks! Paul. > On 14 Feb 2017, at 10:51, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-6986483 > > Proposed change adds CHA support in C2 for interface calls. > > Consider the following hierarchy: > > interface Intf { m(); } > class C implements Intf { public m() { ... } } > class C1 extends C { /* doesn't override m() */ } > ... > class Cn extends C { /* doesn't override m() */ } > > Call site: invokeinterface Intf.m() ... > > If Intf were an abstract class, CHA could deduce that Intf::m() can be replaced with C::m(), but it doesn't work for interfaces. Verifier doesn't check interface types in bytecode, so CHA can't assume the receiver implements Intf. > > CHA in C1 handles such call sites for interfaces with a single implementor. It replaces invokeinterface Intf.m() with invokevirtual C.m() guarded by a subtype check (instanceof C). C2 doesn't do that and this request is about adding that. Type profiling doesn't help here (the call site is usually megamorphic), so C2 can't inline it. > > The proposed implementation is similar to C1, except that the code deoptimizes when subtype check fails and ICCE is thrown from the interpreter. > > While working on it, I spotted and fixed a couple of inefficiencies in C1 implementation: > > (1) dependency context being used was broader than necessary - resolved instead of declared interface (hence, possibility of unnecessary invalidations); > > (2) didn't work for interfaces w/ any default methods: CHA doesn't support default methods at the moment, so what matters is whether Intf::m() is default or not and not whether Intf has *any* concrete methods. > > Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress), LogCompilation tool. > > Thanks! > > Best regards, > Vladimir Ivanov -------------- 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 Thu Feb 16 20:01:32 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Feb 2017 12:01:32 -0800 Subject: [9] RFR(S) 8175097: [TESTBUG] 8174164 fix missed the test Message-ID: Original 8174164 changes had new test which was missing in the final push: http://cr.openjdk.java.net/~roland/8174164/webrev.00/ test/compiler/c2/TestReplacedNodesOSR.java I had to fix the test since it had trailing spaces and forgot to 'hg add' it. Thanks, Vladmir From vladimir.kozlov at oracle.com Thu Feb 16 23:16:36 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Feb 2017 15:16:36 -0800 Subject: [9] RFR(S) 8175097: [TESTBUG] 8174164 fix missed the test In-Reply-To: References: Message-ID: I will list Roland as Author and me as Reviewer since it was already reviewed for 8174164. Vladimir On 2/16/17 12:01 PM, Vladimir Kozlov wrote: > Original 8174164 changes had new test which was missing in the final push: > > http://cr.openjdk.java.net/~roland/8174164/webrev.00/ > > test/compiler/c2/TestReplacedNodesOSR.java > > I had to fix the test since it had trailing spaces and forgot to 'hg add' it. > > Thanks, > Vladmir From goetz.lindenmaier at sap.com Fri Feb 17 07:25:11 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Feb 2017 07:25:11 +0000 Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. In-Reply-To: <5330af15-cd8b-5b81-7acd-4a4c7de479dd@oracle.com> References: <69ee78c1ee774309980ba5bae62bb066@sap.com> <5330af15-cd8b-5b81-7acd-4a4c7de479dd@oracle.com> Message-ID: Hi Vladimir, Thanks for looking at this. I moved the code to a new method "maskShiftAmount" http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.02/ Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Donnerstag, 16. Februar 2017 21:50 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > > Thank you, Goetz > > Very nice cleanup! > > On 2/16/17 9:03 AM, Lindenmaier, Goetz wrote: > > Hi Lutz, > > > > thanks for the review. > > > > What about naming them con and maskedCon? > > shift and maskedShift > > And since you are doing cleanup ;) I want to ask you to factor out in separate > methods (for long and int) checks which > are duplicated in all this methods. All of them check if in(2) is integer > constant and mask it. > > Thanks, > Vladimir > > > > > Best regards, > > Goetz > > > >> -----Original Message----- > >> From: Schmidt, Lutz > >> Sent: Donnerstag, 16. Februar 2017 17:55 > >> To: Lindenmaier, Goetz ; 'hotspot- > compiler- > >> dev at openjdk.java.net' > >> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > >> > >> Goetz, > >> > >> Your changes look good. Thanks for cleaning up! > >> > >> I do have one request, though: > >> In the Ideal methods, you are using either local variable names > con/in2_con > >> or shift/in2_shift. Could you please decide for one variant? Thank you. > >> > >> Best regards, > >> Lutz > >> > >> From: hotspot-compiler-dev >> bounces at openjdk.java.net >> bounces at openjdk.java.net> > on behalf of G?tz Lindenmaier > >> > > >> Date: Donnerstag, 16. Februar 2017 um 09:26 > >> To: "'hotspot-compiler-dev at openjdk.java.net >> dev at openjdk.java.net> '" >> > > >> Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > >> > >> > >> > >> Hi, > >> > >> > >> > >> Constant shift operand > 31 (int) or > 63 (long) are pointless. > >> > >> Mask them in the ideal graph, i.e. > >> > >> if a constant is too large replace it by a smaller one. > >> > >> The code also should use BitsPerJavaInteger instead of BitsPerInt. > >> > >> Please review this change. I please need a sponsor. > >> http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.01 > >> > >> > >> From the standard: > >> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19 > >> > >> If the promoted type of the left-hand operand is int, only the five lowest- > >> order bits of the right-hand operand are used as the shift distance. It is as > if > >> the right-hand operand were subjected to a bitwise logical AND operator > & > >> (?15.22.1) with the mask value 0x1f (0b11111). The shift distance actually > >> used is therefore always in the range 0 to 31, inclusive. > >> > >> If the promoted type of the left-hand operand is long, then only the six > >> lowest-order bits of the right-hand operand are used as the shift > distance. It > >> is as if the right-hand operand were subjected to a bitwise logical AND > >> operator & (?15.22.1) with the mask value 0x3f (0b111111). The shift > >> distance actually used is therefore always in the range 0 to 63, inclusive. > >> > >> > >> > >> Best regards, > >> > >> Goetz. > > From rwestrel at redhat.com Fri Feb 17 13:00:36 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 17 Feb 2017 14:00:36 +0100 Subject: [9] RFR(S) 8175097: [TESTBUG] 8174164 fix missed the test In-Reply-To: References: Message-ID: Thanks for pushing the test case. Roland. From vladimir.kozlov at oracle.com Fri Feb 17 15:58:47 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Feb 2017 07:58:47 -0800 Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. In-Reply-To: References: <69ee78c1ee774309980ba5bae62bb066@sap.com> <5330af15-cd8b-5b81-7acd-4a4c7de479dd@oracle.com> Message-ID: <35888248-82f2-05eb-0d12-bf0be7e0f040@oracle.com> I was think about using find_int_con() and pass in(2) to maskedShiftAmount() static int maskShiftAmount(PhaseGVN *phase, Node *shiftNode, int nBits) { jint shift = phase->find_int_con(shiftNode, 0); // Use 0 as default for the check to work in both cases jint maskedShift = shift & (nBits - 1); if (maskedShift == 0) return 0; // Let Identity() handle 0 shift count. if (shift != maskedShift) { shiftNode->set_req(2, phase->intcon(maskedShift)); // Replace shift count with masked value. } return maskedShift; } And all Identity (with corresponding mask): Node* LShiftINode::Identity(PhaseGVN* phase) { return (phase->find_int_con(in(2), -1) & (BitsPerJavaInteger - 1)) == 0) ? in(1) : this; Thanks, Vladimir On 2/16/17 11:25 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > Thanks for looking at this. > > I moved the code to a new method "maskShiftAmount" > http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.02/ > > Best regards, > Goetz. > >> -----Original Message----- >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >> bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> Sent: Donnerstag, 16. Februar 2017 21:50 >> To: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >> >> Thank you, Goetz >> >> Very nice cleanup! >> >> On 2/16/17 9:03 AM, Lindenmaier, Goetz wrote: >>> Hi Lutz, >>> >>> thanks for the review. >>> >>> What about naming them con and maskedCon? >> >> shift and maskedShift >> >> And since you are doing cleanup ;) I want to ask you to factor out in separate >> methods (for long and int) checks which >> are duplicated in all this methods. All of them check if in(2) is integer >> constant and mask it. >> >> Thanks, >> Vladimir >> >>> >>> Best regards, >>> Goetz >>> >>>> -----Original Message----- >>>> From: Schmidt, Lutz >>>> Sent: Donnerstag, 16. Februar 2017 17:55 >>>> To: Lindenmaier, Goetz ; 'hotspot- >> compiler- >>>> dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >>>> >>>> Goetz, >>>> >>>> Your changes look good. Thanks for cleaning up! >>>> >>>> I do have one request, though: >>>> In the Ideal methods, you are using either local variable names >> con/in2_con >>>> or shift/in2_shift. Could you please decide for one variant? Thank you. >>>> >>>> Best regards, >>>> Lutz >>>> >>>> From: hotspot-compiler-dev >>> bounces at openjdk.java.net >>> bounces at openjdk.java.net> > on behalf of G?tz Lindenmaier >>>> > >>>> Date: Donnerstag, 16. Februar 2017 um 09:26 >>>> To: "'hotspot-compiler-dev at openjdk.java.net >>> dev at openjdk.java.net> '" >>> > >>>> Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> Constant shift operand > 31 (int) or > 63 (long) are pointless. >>>> >>>> Mask them in the ideal graph, i.e. >>>> >>>> if a constant is too large replace it by a smaller one. >>>> >>>> The code also should use BitsPerJavaInteger instead of BitsPerInt. >>>> >>>> Please review this change. I please need a sponsor. >>>> http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.01 >>>> >>>> >>>> From the standard: >>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19 >>>> >>>> If the promoted type of the left-hand operand is int, only the five lowest- >>>> order bits of the right-hand operand are used as the shift distance. It is as >> if >>>> the right-hand operand were subjected to a bitwise logical AND operator >> & >>>> (?15.22.1) with the mask value 0x1f (0b11111). The shift distance actually >>>> used is therefore always in the range 0 to 31, inclusive. >>>> >>>> If the promoted type of the left-hand operand is long, then only the six >>>> lowest-order bits of the right-hand operand are used as the shift >> distance. It >>>> is as if the right-hand operand were subjected to a bitwise logical AND >>>> operator & (?15.22.1) with the mask value 0x3f (0b111111). The shift >>>> distance actually used is therefore always in the range 0 to 63, inclusive. >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Goetz. >>> From vladimir.kozlov at oracle.com Fri Feb 17 22:01:53 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Feb 2017 14:01:53 -0800 Subject: [9] RFR(S) 8175052: [AOT] jaotc does not accept file name with .class Message-ID: <3a906546-976d-b089-9785-233ffbeccb10@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8175052 http://cr.openjdk.java.net/~kvn/8175052/webrev/ After 8169588 change jaotc stop accepting file.class names. Add back such ability. Print stack trace for "not found" error only with --info flag. Also changed error message to be less confusing. Instead of: Error: Failed to find: unknown:my.class Error: Failed to find: classname:my.class output: Error: Failed to find file: my.class when --class-name flag is used: Error: Failed to find class file: my.class Thanks, Vladimir From igor.veresov at oracle.com Sat Feb 18 04:35:31 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 17 Feb 2017 20:35:31 -0800 Subject: RFR(XXS) 8175217: [AOT] Fix suite.py after module renaming Message-ID: s/jdk.vm.ci/jdk.internal.vm.ci/ JBS: https://bugs.openjdk.java.net/browse/JDK-8175217 Webrev: http://cr.openjdk.java.net/~iveresov/8175217/webrev.00/ Thanks, igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Sat Feb 18 04:36:43 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 17 Feb 2017 20:36:43 -0800 Subject: [9] RFR(S) 8175052: [AOT] jaotc does not accept file name with .class In-Reply-To: <3a906546-976d-b089-9785-233ffbeccb10@oracle.com> References: <3a906546-976d-b089-9785-233ffbeccb10@oracle.com> Message-ID: Looks good. igor > On Feb 17, 2017, at 2:01 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8175052 > > http://cr.openjdk.java.net/~kvn/8175052/webrev/ > > After 8169588 change jaotc stop accepting file.class names. Add back such ability. > Print stack trace for "not found" error only with --info flag. > Also changed error message to be less confusing. Instead of: > > Error: Failed to find: unknown:my.class > Error: Failed to find: classname:my.class > > output: > Error: Failed to find file: my.class > > when --class-name flag is used: > Error: Failed to find class file: my.class > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Sat Feb 18 05:02:31 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Feb 2017 21:02:31 -0800 Subject: RFR(XXS) 8175217: [AOT] Fix suite.py after module renaming In-Reply-To: References: Message-ID: <08939c49-7fe9-0bf1-ab51-eabf71139fda@oracle.com> Sorry about this miss. Looks good. Thanks, Vladimir On 2/17/17 8:35 PM, Igor Veresov wrote: > s/jdk.vm.ci/jdk.internal.vm.ci/ > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8175217 > Webrev: http://cr.openjdk.java.net/~iveresov/8175217/webrev.00/ > > > Thanks, > igor From vladimir.kozlov at oracle.com Sat Feb 18 05:03:01 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Feb 2017 21:03:01 -0800 Subject: [9] RFR(S) 8175052: [AOT] jaotc does not accept file name with .class In-Reply-To: References: <3a906546-976d-b089-9785-233ffbeccb10@oracle.com> Message-ID: <3820b750-c040-14a1-9b35-08f5bb613643@oracle.com> Thank you, Igor Vladimir On 2/17/17 8:36 PM, Igor Veresov wrote: > Looks good. > > igor > >> On Feb 17, 2017, at 2:01 PM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8175052 >> >> http://cr.openjdk.java.net/~kvn/8175052/webrev/ >> >> After 8169588 change jaotc stop accepting file.class names. Add back such ability. >> Print stack trace for "not found" error only with --info flag. >> Also changed error message to be less confusing. Instead of: >> >> Error: Failed to find: unknown:my.class >> Error: Failed to find: classname:my.class >> >> output: >> Error: Failed to find file: my.class >> >> when --class-name flag is used: >> Error: Failed to find class file: my.class >> >> Thanks, >> Vladimir > From igor.veresov at oracle.com Sat Feb 18 05:53:34 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 17 Feb 2017 21:53:34 -0800 Subject: RFR(XXS) 8175217: [AOT] Fix suite.py after module renaming In-Reply-To: <08939c49-7fe9-0bf1-ab51-eabf71139fda@oracle.com> References: <08939c49-7fe9-0bf1-ab51-eabf71139fda@oracle.com> Message-ID: Thanks! igor > On Feb 17, 2017, at 9:02 PM, Vladimir Kozlov wrote: > > Sorry about this miss. > > Looks good. > > Thanks, > Vladimir > > On 2/17/17 8:35 PM, Igor Veresov wrote: >> s/jdk.vm.ci/jdk.internal.vm.ci/ >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8175217 >> Webrev: http://cr.openjdk.java.net/~iveresov/8175217/webrev.00/ >> >> >> Thanks, >> igor From goetz.lindenmaier at sap.com Sun Feb 19 18:52:22 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sun, 19 Feb 2017 18:52:22 +0000 Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. In-Reply-To: <35888248-82f2-05eb-0d12-bf0be7e0f040@oracle.com> References: <69ee78c1ee774309980ba5bae62bb066@sap.com> <5330af15-cd8b-5b81-7acd-4a4c7de479dd@oracle.com> <35888248-82f2-05eb-0d12-bf0be7e0f040@oracle.com> Message-ID: <1e7fb339a66f4f44bdb8a773e75d67df@sap.com> Hi Vladimir, I added getShiftCon(): http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.03/ Best regards, Goetz. > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Freitag, 17. Februar 2017 17:59 > To: Lindenmaier, Goetz ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > > I was think about using find_int_con() and pass in(2) to > maskedShiftAmount() > > static int maskShiftAmount(PhaseGVN *phase, Node *shiftNode, int nBits) { > jint shift = phase->find_int_con(shiftNode, 0); // Use 0 as default for > the check to work in both cases > jint maskedShift = shift & (nBits - 1); > > if (maskedShift == 0) return 0; // Let Identity() handle 0 shift count. > > if (shift != maskedShift) { > shiftNode->set_req(2, phase->intcon(maskedShift)); // Replace shift count > with masked value. > } > > return maskedShift; > } > > And all Identity (with corresponding mask): > > Node* LShiftINode::Identity(PhaseGVN* phase) { > return (phase->find_int_con(in(2), -1) & (BitsPerJavaInteger - 1)) == 0) ? > in(1) : this; > > > Thanks, > Vladimir > > On 2/16/17 11:25 PM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > > > Thanks for looking at this. > > > > I moved the code to a new method "maskShiftAmount" > > http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.02/ > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > >> bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > >> Sent: Donnerstag, 16. Februar 2017 21:50 > >> To: hotspot-compiler-dev at openjdk.java.net > >> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > >> > >> Thank you, Goetz > >> > >> Very nice cleanup! > >> > >> On 2/16/17 9:03 AM, Lindenmaier, Goetz wrote: > >>> Hi Lutz, > >>> > >>> thanks for the review. > >>> > >>> What about naming them con and maskedCon? > >> > >> shift and maskedShift > >> > >> And since you are doing cleanup ;) I want to ask you to factor out in > separate > >> methods (for long and int) checks which > >> are duplicated in all this methods. All of them check if in(2) is integer > >> constant and mask it. > >> > >> Thanks, > >> Vladimir > >> > >>> > >>> Best regards, > >>> Goetz > >>> > >>>> -----Original Message----- > >>>> From: Schmidt, Lutz > >>>> Sent: Donnerstag, 16. Februar 2017 17:55 > >>>> To: Lindenmaier, Goetz ; 'hotspot- > >> compiler- > >>>> dev at openjdk.java.net' > >>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > >>>> > >>>> Goetz, > >>>> > >>>> Your changes look good. Thanks for cleaning up! > >>>> > >>>> I do have one request, though: > >>>> In the Ideal methods, you are using either local variable names > >> con/in2_con > >>>> or shift/in2_shift. Could you please decide for one variant? Thank you. > >>>> > >>>> Best regards, > >>>> Lutz > >>>> > >>>> From: hotspot-compiler-dev >>>> bounces at openjdk.java.net >>>> bounces at openjdk.java.net> > on behalf of G?tz Lindenmaier > >>>> > > >>>> Date: Donnerstag, 16. Februar 2017 um 09:26 > >>>> To: "'hotspot-compiler-dev at openjdk.java.net compiler- > >>>> dev at openjdk.java.net> '" >>>> > > >>>> Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > >>>> > >>>> > >>>> > >>>> Hi, > >>>> > >>>> > >>>> > >>>> Constant shift operand > 31 (int) or > 63 (long) are pointless. > >>>> > >>>> Mask them in the ideal graph, i.e. > >>>> > >>>> if a constant is too large replace it by a smaller one. > >>>> > >>>> The code also should use BitsPerJavaInteger instead of BitsPerInt. > >>>> > >>>> Please review this change. I please need a sponsor. > >>>> http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.01 > >>>> > >>>> > >>>> From the standard: > >>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19 > >>>> 15.19> > >>>> If the promoted type of the left-hand operand is int, only the five > lowest- > >>>> order bits of the right-hand operand are used as the shift distance. It is > as > >> if > >>>> the right-hand operand were subjected to a bitwise logical AND > operator > >> & > >>>> (?15.22.1) with the mask value 0x1f (0b11111). The shift distance > actually > >>>> used is therefore always in the range 0 to 31, inclusive. > >>>> > >>>> If the promoted type of the left-hand operand is long, then only the six > >>>> lowest-order bits of the right-hand operand are used as the shift > >> distance. It > >>>> is as if the right-hand operand were subjected to a bitwise logical AND > >>>> operator & (?15.22.1) with the mask value 0x3f (0b111111). The shift > >>>> distance actually used is therefore always in the range 0 to 63, > inclusive. > >>>> > >>>> > >>>> > >>>> Best regards, > >>>> > >>>> Goetz. > >>> From vladimir.kozlov at oracle.com Tue Feb 21 22:58:47 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Feb 2017 14:58:47 -0800 Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. In-Reply-To: <1e7fb339a66f4f44bdb8a773e75d67df@sap.com> References: <69ee78c1ee774309980ba5bae62bb066@sap.com> <5330af15-cd8b-5b81-7acd-4a4c7de479dd@oracle.com> <35888248-82f2-05eb-0d12-bf0be7e0f040@oracle.com> <1e7fb339a66f4f44bdb8a773e75d67df@sap.com> Message-ID: Good. I will sponsor it after testing. Thanks, Vladimir On 2/19/17 10:52 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I added getShiftCon(): > http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.03/ > > Best regards, > Goetz. > >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Freitag, 17. Februar 2017 17:59 >> To: Lindenmaier, Goetz ; hotspot-compiler- >> dev at openjdk.java.net >> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >> >> I was think about using find_int_con() and pass in(2) to >> maskedShiftAmount() >> >> static int maskShiftAmount(PhaseGVN *phase, Node *shiftNode, int nBits) { >> jint shift = phase->find_int_con(shiftNode, 0); // Use 0 as default for >> the check to work in both cases >> jint maskedShift = shift & (nBits - 1); >> >> if (maskedShift == 0) return 0; // Let Identity() handle 0 shift count. >> >> if (shift != maskedShift) { >> shiftNode->set_req(2, phase->intcon(maskedShift)); // Replace shift count >> with masked value. >> } >> >> return maskedShift; >> } >> >> And all Identity (with corresponding mask): >> >> Node* LShiftINode::Identity(PhaseGVN* phase) { >> return (phase->find_int_con(in(2), -1) & (BitsPerJavaInteger - 1)) == 0) ? >> in(1) : this; >> >> >> Thanks, >> Vladimir >> >> On 2/16/17 11:25 PM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> Thanks for looking at this. >>> >>> I moved the code to a new method "maskShiftAmount" >>> http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.02/ >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >>>> bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>>> Sent: Donnerstag, 16. Februar 2017 21:50 >>>> To: hotspot-compiler-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >>>> >>>> Thank you, Goetz >>>> >>>> Very nice cleanup! >>>> >>>> On 2/16/17 9:03 AM, Lindenmaier, Goetz wrote: >>>>> Hi Lutz, >>>>> >>>>> thanks for the review. >>>>> >>>>> What about naming them con and maskedCon? >>>> >>>> shift and maskedShift >>>> >>>> And since you are doing cleanup ;) I want to ask you to factor out in >> separate >>>> methods (for long and int) checks which >>>> are duplicated in all this methods. All of them check if in(2) is integer >>>> constant and mask it. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Best regards, >>>>> Goetz >>>>> >>>>>> -----Original Message----- >>>>>> From: Schmidt, Lutz >>>>>> Sent: Donnerstag, 16. Februar 2017 17:55 >>>>>> To: Lindenmaier, Goetz ; 'hotspot- >>>> compiler- >>>>>> dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >>>>>> >>>>>> Goetz, >>>>>> >>>>>> Your changes look good. Thanks for cleaning up! >>>>>> >>>>>> I do have one request, though: >>>>>> In the Ideal methods, you are using either local variable names >>>> con/in2_con >>>>>> or shift/in2_shift. Could you please decide for one variant? Thank you. >>>>>> >>>>>> Best regards, >>>>>> Lutz >>>>>> >>>>>> From: hotspot-compiler-dev >>>>> bounces at openjdk.java.net >>>>> bounces at openjdk.java.net> > on behalf of G?tz Lindenmaier >>>>>> > >>>>>> Date: Donnerstag, 16. Februar 2017 um 09:26 >>>>>> To: "'hotspot-compiler-dev at openjdk.java.net > compiler- >>>>>> dev at openjdk.java.net> '" >>>>> > >>>>>> Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> Constant shift operand > 31 (int) or > 63 (long) are pointless. >>>>>> >>>>>> Mask them in the ideal graph, i.e. >>>>>> >>>>>> if a constant is too large replace it by a smaller one. >>>>>> >>>>>> The code also should use BitsPerJavaInteger instead of BitsPerInt. >>>>>> >>>>>> Please review this change. I please need a sponsor. >>>>>> http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.01 >>>>>> >>>>>> >>>>>> From the standard: >>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19 >>>>>> > 15.19> >>>>>> If the promoted type of the left-hand operand is int, only the five >> lowest- >>>>>> order bits of the right-hand operand are used as the shift distance. It is >> as >>>> if >>>>>> the right-hand operand were subjected to a bitwise logical AND >> operator >>>> & >>>>>> (?15.22.1) with the mask value 0x1f (0b11111). The shift distance >> actually >>>>>> used is therefore always in the range 0 to 31, inclusive. >>>>>> >>>>>> If the promoted type of the left-hand operand is long, then only the six >>>>>> lowest-order bits of the right-hand operand are used as the shift >>>> distance. It >>>>>> is as if the right-hand operand were subjected to a bitwise logical AND >>>>>> operator & (?15.22.1) with the mask value 0x3f (0b111111). The shift >>>>>> distance actually used is therefore always in the range 0 to 63, >> inclusive. >>>>>> >>>>>> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Goetz. >>>>> From goetz.lindenmaier at sap.com Wed Feb 22 08:47:33 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 22 Feb 2017 08:47:33 +0000 Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. In-Reply-To: References: <69ee78c1ee774309980ba5bae62bb066@sap.com> <5330af15-cd8b-5b81-7acd-4a4c7de479dd@oracle.com> <35888248-82f2-05eb-0d12-bf0be7e0f040@oracle.com> <1e7fb339a66f4f44bdb8a773e75d67df@sap.com> Message-ID: <20a0910fda3645a8ab9de85cc78911c5@sap.com> Hi Vladimir, that's great, thank you! Our tests are fine, also with my recent edits. Best regards, Goetz. > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 22. Februar 2017 00:59 > To: Lindenmaier, Goetz ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > > Good. I will sponsor it after testing. > > Thanks, > Vladimir > > > On 2/19/17 10:52 AM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > > > I added getShiftCon(): > > http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.03/ > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > >> Sent: Freitag, 17. Februar 2017 17:59 > >> To: Lindenmaier, Goetz ; hotspot-compiler- > >> dev at openjdk.java.net > >> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > >> > >> I was think about using find_int_con() and pass in(2) to > >> maskedShiftAmount() > >> > >> static int maskShiftAmount(PhaseGVN *phase, Node *shiftNode, int > nBits) { > >> jint shift = phase->find_int_con(shiftNode, 0); // Use 0 as default for > >> the check to work in both cases > >> jint maskedShift = shift & (nBits - 1); > >> > >> if (maskedShift == 0) return 0; // Let Identity() handle 0 shift count. > >> > >> if (shift != maskedShift) { > >> shiftNode->set_req(2, phase->intcon(maskedShift)); // Replace shift > count > >> with masked value. > >> } > >> > >> return maskedShift; > >> } > >> > >> And all Identity (with corresponding mask): > >> > >> Node* LShiftINode::Identity(PhaseGVN* phase) { > >> return (phase->find_int_con(in(2), -1) & (BitsPerJavaInteger - 1)) == 0) ? > >> in(1) : this; > >> > >> > >> Thanks, > >> Vladimir > >> > >> On 2/16/17 11:25 PM, Lindenmaier, Goetz wrote: > >>> Hi Vladimir, > >>> > >>> Thanks for looking at this. > >>> > >>> I moved the code to a new method "maskShiftAmount" > >>> http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.02/ > >>> > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > >>>> bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > >>>> Sent: Donnerstag, 16. Februar 2017 21:50 > >>>> To: hotspot-compiler-dev at openjdk.java.net > >>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > >>>> > >>>> Thank you, Goetz > >>>> > >>>> Very nice cleanup! > >>>> > >>>> On 2/16/17 9:03 AM, Lindenmaier, Goetz wrote: > >>>>> Hi Lutz, > >>>>> > >>>>> thanks for the review. > >>>>> > >>>>> What about naming them con and maskedCon? > >>>> > >>>> shift and maskedShift > >>>> > >>>> And since you are doing cleanup ;) I want to ask you to factor out in > >> separate > >>>> methods (for long and int) checks which > >>>> are duplicated in all this methods. All of them check if in(2) is integer > >>>> constant and mask it. > >>>> > >>>> Thanks, > >>>> Vladimir > >>>> > >>>>> > >>>>> Best regards, > >>>>> Goetz > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Schmidt, Lutz > >>>>>> Sent: Donnerstag, 16. Februar 2017 17:55 > >>>>>> To: Lindenmaier, Goetz ; 'hotspot- > >>>> compiler- > >>>>>> dev at openjdk.java.net' > >>>>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal > graph. > >>>>>> > >>>>>> Goetz, > >>>>>> > >>>>>> Your changes look good. Thanks for cleaning up! > >>>>>> > >>>>>> I do have one request, though: > >>>>>> In the Ideal methods, you are using either local variable names > >>>> con/in2_con > >>>>>> or shift/in2_shift. Could you please decide for one variant? Thank > you. > >>>>>> > >>>>>> Best regards, > >>>>>> Lutz > >>>>>> > >>>>>> From: hotspot-compiler-dev >>>>>> bounces at openjdk.java.net >>>>>> bounces at openjdk.java.net> > on behalf of G?tz Lindenmaier > >>>>>> > > > >>>>>> Date: Donnerstag, 16. Februar 2017 um 09:26 > >>>>>> To: "'hotspot-compiler-dev at openjdk.java.net >> compiler- > >>>>>> dev at openjdk.java.net> '" >>>>>> > > >>>>>> Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> > >>>>>> > >>>>>> Constant shift operand > 31 (int) or > 63 (long) are pointless. > >>>>>> > >>>>>> Mask them in the ideal graph, i.e. > >>>>>> > >>>>>> if a constant is too large replace it by a smaller one. > >>>>>> > >>>>>> The code also should use BitsPerJavaInteger instead of BitsPerInt. > >>>>>> > >>>>>> Please review this change. I please need a sponsor. > >>>>>> http://cr.openjdk.java.net/~goetz/wr17/8173470- > maskShift/webrev.01 > >>>>>> > >>>>>> > >>>>>> From the standard: > >>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls- > 15.19 > >>>>>> >> 15.19> > >>>>>> If the promoted type of the left-hand operand is int, only the five > >> lowest- > >>>>>> order bits of the right-hand operand are used as the shift distance. It > is > >> as > >>>> if > >>>>>> the right-hand operand were subjected to a bitwise logical AND > >> operator > >>>> & > >>>>>> (?15.22.1) with the mask value 0x1f (0b11111). The shift distance > >> actually > >>>>>> used is therefore always in the range 0 to 31, inclusive. > >>>>>> > >>>>>> If the promoted type of the left-hand operand is long, then only the > six > >>>>>> lowest-order bits of the right-hand operand are used as the shift > >>>> distance. It > >>>>>> is as if the right-hand operand were subjected to a bitwise logical > AND > >>>>>> operator & (?15.22.1) with the mask value 0x3f (0b111111). The shift > >>>>>> distance actually used is therefore always in the range 0 to 63, > >> inclusive. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Best regards, > >>>>>> > >>>>>> Goetz. > >>>>> From vitalyd at gmail.com Wed Feb 22 13:57:18 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 22 Feb 2017 13:57:18 +0000 Subject: [10] RFR (M): 6986483: CHA: optimize calls through interfaces In-Reply-To: <2080EA54-B6F3-4EC2-8093-0FD935EC872E@oracle.com> References: <2080EA54-B6F3-4EC2-8093-0FD935EC872E@oracle.com> Message-ID: On Thu, Feb 16, 2017 at 3:00 PM Paul Sandoz wrote: > Hi, > > This is a nice surprise :-) +1 - great work Vladimir! I didn't know C1 handled this already - always thought it's no better than C2 in any performance aspect :). A bit premature to ask perhaps, but could this conceivably be backported to Java 9? > > > I happened to be separately looking at this area, analysing the > performance of interfaces/abstract classes to apply a certain > implementation technique to avoid going megamorphic. > > I concluded that the implementation technique was not viable, but with > your patch i think i can revive it and perform more detailed analysis. > > Based on my benchmark the performance improvement looks good. > > Thanks! > Paul. > > > On 14 Feb 2017, at 10:51, Vladimir Ivanov > wrote: > > > > http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-6986483 > > > > Proposed change adds CHA support in C2 for interface calls. > > > > Consider the following hierarchy: > > > > interface Intf { m(); } > > class C implements Intf { public m() { ... } } > > class C1 extends C { /* doesn't override m() */ } > > ... > > class Cn extends C { /* doesn't override m() */ } > > > > Call site: invokeinterface Intf.m() ... > > > > If Intf were an abstract class, CHA could deduce that Intf::m() can be > replaced with C::m(), but it doesn't work for interfaces. Verifier doesn't > check interface types in bytecode, so CHA can't assume the receiver > implements Intf. > > > > CHA in C1 handles such call sites for interfaces with a single > implementor. It replaces invokeinterface Intf.m() with invokevirtual C.m() > guarded by a subtype check (instanceof C). C2 doesn't do that and this > request is about adding that. Type profiling doesn't help here (the call > site is usually megamorphic), so C2 can't inline it. > > > > The proposed implementation is similar to C1, except that the code > deoptimizes when subtype check fails and ICCE is thrown from the > interpreter. > > > > While working on it, I spotted and fixed a couple of inefficiencies in > C1 implementation: > > > > (1) dependency context being used was broader than necessary - resolved > instead of declared interface (hence, possibility of unnecessary > invalidations); > > > > (2) didn't work for interfaces w/ any default methods: CHA doesn't > support default methods at the moment, so what matters is whether Intf::m() > is default or not and not whether Intf has *any* concrete methods. > > > > Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress), > LogCompilation tool. > > > > Thanks! > > > > Best regards, > > Vladimir Ivanov > > -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Wed Feb 22 14:44:36 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 22 Feb 2017 17:44:36 +0300 Subject: [10] RFR (M): 6986483: CHA: optimize calls through interfaces In-Reply-To: <118eb363-0cf8-a160-b5e0-ba5dbe00d27b@oracle.com> References: <118eb363-0cf8-a160-b5e0-ba5dbe00d27b@oracle.com> Message-ID: Thanks, Vladimir. Best regards, Vladimir Ivanov On 2/15/17 11:38 PM, Vladimir Kozlov wrote: > Seems fine to me. > > thanks, > Vladimir K > > On 2/14/17 10:51 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-6986483 >> >> Proposed change adds CHA support in C2 for interface calls. >> >> Consider the following hierarchy: >> >> interface Intf { m(); } >> class C implements Intf { public m() { ... } } >> class C1 extends C { /* doesn't override m() */ } >> ... >> class Cn extends C { /* doesn't override m() */ } >> >> Call site: invokeinterface Intf.m() ... >> >> If Intf were an abstract class, CHA could deduce that Intf::m() can be >> replaced with C::m(), but it doesn't work for interfaces. Verifier >> doesn't check interface types in bytecode, so CHA can't assume >> the receiver implements Intf. >> >> CHA in C1 handles such call sites for interfaces with a single >> implementor. It replaces invokeinterface Intf.m() with invokevirtual >> C.m() guarded by a subtype check (instanceof C). C2 doesn't do that >> and this request is about adding that. Type profiling doesn't help >> here (the call site is usually megamorphic), so C2 can't inline it. >> >> The proposed implementation is similar to C1, except that the code >> deoptimizes when subtype check fails and ICCE is thrown from the >> interpreter. >> >> While working on it, I spotted and fixed a couple of inefficiencies in >> C1 implementation: >> >> (1) dependency context being used was broader than necessary - >> resolved instead of declared interface (hence, possibility of >> unnecessary invalidations); >> >> (2) didn't work for interfaces w/ any default methods: CHA doesn't >> support default methods at the moment, so what matters is whether >> Intf::m() is default or not and not whether Intf has *any* >> concrete methods. >> >> Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress), >> LogCompilation tool. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Feb 22 14:47:27 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 22 Feb 2017 17:47:27 +0300 Subject: [10] RFR (M): 6986483: CHA: optimize calls through interfaces In-Reply-To: References: <2080EA54-B6F3-4EC2-8093-0FD935EC872E@oracle.com> Message-ID: <2bb229a7-10e8-c567-39af-a8be4ca19f97@oracle.com> Vitaly, > A bit premature to ask perhaps, but could this conceivably be backported > to Java 9? Yes, once it gets enough testing in jdk10 repo I'll consider backporting it into upcoming 9u release. No chances to get it into jdk9 GA though. Best regards, Vladimir Ivanov > > I happened to be separately looking at this area, analysing the > performance of interfaces/abstract classes to apply a certain > implementation technique to avoid going megamorphic. > > I concluded that the implementation technique was not viable, but > with your patch i think i can revive it and perform more detailed > analysis. > > Based on my benchmark the performance improvement looks good. > > Thanks! > Paul. > > > On 14 Feb 2017, at 10:51, Vladimir Ivanov > > > wrote: > > > > http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-6986483 > > > > Proposed change adds CHA support in C2 for interface calls. > > > > Consider the following hierarchy: > > > > interface Intf { m(); } > > class C implements Intf { public m() { ... } } > > class C1 extends C { /* doesn't override m() */ } > > ... > > class Cn extends C { /* doesn't override m() */ } > > > > Call site: invokeinterface Intf.m() ... > > > > If Intf were an abstract class, CHA could deduce that Intf::m() > can be replaced with C::m(), but it doesn't work for interfaces. > Verifier doesn't check interface types in bytecode, so CHA can't > assume the receiver implements Intf. > > > > CHA in C1 handles such call sites for interfaces with a single > implementor. It replaces invokeinterface Intf.m() with invokevirtual > C.m() guarded by a subtype check (instanceof C). C2 doesn't do that > and this request is about adding that. Type profiling doesn't help > here (the call site is usually megamorphic), so C2 can't inline it. > > > > The proposed implementation is similar to C1, except that the code > deoptimizes when subtype check fails and ICCE is thrown from the > interpreter. > > > > While working on it, I spotted and fixed a couple of > inefficiencies in C1 implementation: > > > > (1) dependency context being used was broader than necessary - > resolved instead of declared interface (hence, possibility of > unnecessary invalidations); > > > > (2) didn't work for interfaces w/ any default methods: CHA > doesn't support default methods at the moment, so what matters is > whether Intf::m() is default or not and not whether Intf has *any* > concrete methods. > > > > Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in > progress), LogCompilation tool. > > > > Thanks! > > > > Best regards, > > Vladimir Ivanov > > -- > Sent from my phone From vitalyd at gmail.com Wed Feb 22 14:48:04 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 22 Feb 2017 09:48:04 -0500 Subject: [10] RFR (M): 6986483: CHA: optimize calls through interfaces In-Reply-To: <2bb229a7-10e8-c567-39af-a8be4ca19f97@oracle.com> References: <2080EA54-B6F3-4EC2-8093-0FD935EC872E@oracle.com> <2bb229a7-10e8-c567-39af-a8be4ca19f97@oracle.com> Message-ID: On Wed, Feb 22, 2017 at 9:47 AM, Vladimir Ivanov < vladimir.x.ivanov at oracle.com> wrote: > Vitaly, > > A bit premature to ask perhaps, but could this conceivably be backported >> to Java 9? >> > Yes, once it gets enough testing in jdk10 repo I'll consider backporting > it into upcoming 9u release. > > No chances to get it into jdk9 GA though. > Sounds great - thanks! > > Best regards, > Vladimir Ivanov > > >> I happened to be separately looking at this area, analysing the >> performance of interfaces/abstract classes to apply a certain >> implementation technique to avoid going megamorphic. >> >> I concluded that the implementation technique was not viable, but >> with your patch i think i can revive it and perform more detailed >> analysis. >> >> Based on my benchmark the performance improvement looks good. >> >> Thanks! >> Paul. >> >> > On 14 Feb 2017, at 10:51, Vladimir Ivanov >> > >> >> wrote: >> > >> > http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/ >> > https://bugs.openjdk.java.net/browse/JDK-6986483 >> > >> > Proposed change adds CHA support in C2 for interface calls. >> > >> > Consider the following hierarchy: >> > >> > interface Intf { m(); } >> > class C implements Intf { public m() { ... } } >> > class C1 extends C { /* doesn't override m() */ } >> > ... >> > class Cn extends C { /* doesn't override m() */ } >> > >> > Call site: invokeinterface Intf.m() ... >> > >> > If Intf were an abstract class, CHA could deduce that Intf::m() >> can be replaced with C::m(), but it doesn't work for interfaces. >> Verifier doesn't check interface types in bytecode, so CHA can't >> assume the receiver implements Intf. >> > >> > CHA in C1 handles such call sites for interfaces with a single >> implementor. It replaces invokeinterface Intf.m() with invokevirtual >> C.m() guarded by a subtype check (instanceof C). C2 doesn't do that >> and this request is about adding that. Type profiling doesn't help >> here (the call site is usually megamorphic), so C2 can't inline it. >> > >> > The proposed implementation is similar to C1, except that the code >> deoptimizes when subtype check fails and ICCE is thrown from the >> interpreter. >> > >> > While working on it, I spotted and fixed a couple of >> inefficiencies in C1 implementation: >> > >> > (1) dependency context being used was broader than necessary - >> resolved instead of declared interface (hence, possibility of >> unnecessary invalidations); >> > >> > (2) didn't work for interfaces w/ any default methods: CHA >> doesn't support default methods at the moment, so what matters is >> whether Intf::m() is default or not and not whether Intf has *any* >> concrete methods. >> > >> > Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in >> progress), LogCompilation tool. >> > >> > Thanks! >> > >> > Best regards, >> > Vladimir Ivanov >> >> -- >> Sent from my phone >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Wed Feb 22 14:50:30 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 22 Feb 2017 17:50:30 +0300 Subject: [10] RFR (M): 6986483: CHA: optimize calls through interfaces In-Reply-To: <2080EA54-B6F3-4EC2-8093-0FD935EC872E@oracle.com> References: <2080EA54-B6F3-4EC2-8093-0FD935EC872E@oracle.com> Message-ID: <5fb21baa-d0bb-257f-a75e-154f65c62dc1@oracle.com> > Based on my benchmark the performance improvement looks good. Glad to hear that, Paul. Thanks for verifying. Best regards, Vladimir Ivanov >> On 14 Feb 2017, at 10:51, Vladimir Ivanov wrote: >> >> http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-6986483 >> >> Proposed change adds CHA support in C2 for interface calls. >> >> Consider the following hierarchy: >> >> interface Intf { m(); } >> class C implements Intf { public m() { ... } } >> class C1 extends C { /* doesn't override m() */ } >> ... >> class Cn extends C { /* doesn't override m() */ } >> >> Call site: invokeinterface Intf.m() ... >> >> If Intf were an abstract class, CHA could deduce that Intf::m() can be replaced with C::m(), but it doesn't work for interfaces. Verifier doesn't check interface types in bytecode, so CHA can't assume the receiver implements Intf. >> >> CHA in C1 handles such call sites for interfaces with a single implementor. It replaces invokeinterface Intf.m() with invokevirtual C.m() guarded by a subtype check (instanceof C). C2 doesn't do that and this request is about adding that. Type profiling doesn't help here (the call site is usually megamorphic), so C2 can't inline it. >> >> The proposed implementation is similar to C1, except that the code deoptimizes when subtype check fails and ICCE is thrown from the interpreter. >> >> While working on it, I spotted and fixed a couple of inefficiencies in C1 implementation: >> >> (1) dependency context being used was broader than necessary - resolved instead of declared interface (hence, possibility of unnecessary invalidations); >> >> (2) didn't work for interfaces w/ any default methods: CHA doesn't support default methods at the moment, so what matters is whether Intf::m() is default or not and not whether Intf has *any* concrete methods. >> >> Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress), LogCompilation tool. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From tobias.hartmann at oracle.com Wed Feb 22 15:50:16 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 22 Feb 2017 16:50:16 +0100 Subject: [9] RFR(S): 8139906: assert(src->section_index_of(target) == CodeBuffer::SECT_NONE) failed: sanity Message-ID: <014c7561-1ed7-4f36-2b85-080399cf02bb@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8139906 http://cr.openjdk.java.net/~thartmann/8139906/webrev.00/ On ARM, the card table address used in the g1_post_barrier_slow stub should not be marked as relocatable (similar to what we do on x86 [1]). This was fixed on ARM before but the fix was removed by another change (see comments in the bug). Tested with failing test and RBT (running). Thanks, Tobias [1] http://hg.openjdk.java.net/jdk9/hs/hotspot/file/fcc911c59d4c/src/cpu/x86/vm/c1_Runtime1_x86.cpp#l1710 From vladimir.kozlov at oracle.com Wed Feb 22 19:09:58 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Feb 2017 11:09:58 -0800 Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. In-Reply-To: <20a0910fda3645a8ab9de85cc78911c5@sap.com> References: <69ee78c1ee774309980ba5bae62bb066@sap.com> <5330af15-cd8b-5b81-7acd-4a4c7de479dd@oracle.com> <35888248-82f2-05eb-0d12-bf0be7e0f040@oracle.com> <1e7fb339a66f4f44bdb8a773e75d67df@sap.com> <20a0910fda3645a8ab9de85cc78911c5@sap.com> Message-ID: <57e112d4-45d8-67a5-68ee-c9b1a165520b@oracle.com> Tests passed. I am pushing this fix. Thanks, Vladimir On 2/22/17 12:47 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > that's great, thank you! > Our tests are fine, also with my recent edits. > > Best regards, > Goetz. > >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Mittwoch, 22. Februar 2017 00:59 >> To: Lindenmaier, Goetz ; hotspot-compiler- >> dev at openjdk.java.net >> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >> >> Good. I will sponsor it after testing. >> >> Thanks, >> Vladimir >> >> >> On 2/19/17 10:52 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> I added getShiftCon(): >>> http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.03/ >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Freitag, 17. Februar 2017 17:59 >>>> To: Lindenmaier, Goetz ; hotspot-compiler- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >>>> >>>> I was think about using find_int_con() and pass in(2) to >>>> maskedShiftAmount() >>>> >>>> static int maskShiftAmount(PhaseGVN *phase, Node *shiftNode, int >> nBits) { >>>> jint shift = phase->find_int_con(shiftNode, 0); // Use 0 as default for >>>> the check to work in both cases >>>> jint maskedShift = shift & (nBits - 1); >>>> >>>> if (maskedShift == 0) return 0; // Let Identity() handle 0 shift count. >>>> >>>> if (shift != maskedShift) { >>>> shiftNode->set_req(2, phase->intcon(maskedShift)); // Replace shift >> count >>>> with masked value. >>>> } >>>> >>>> return maskedShift; >>>> } >>>> >>>> And all Identity (with corresponding mask): >>>> >>>> Node* LShiftINode::Identity(PhaseGVN* phase) { >>>> return (phase->find_int_con(in(2), -1) & (BitsPerJavaInteger - 1)) == 0) ? >>>> in(1) : this; >>>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 2/16/17 11:25 PM, Lindenmaier, Goetz wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thanks for looking at this. >>>>> >>>>> I moved the code to a new method "maskShiftAmount" >>>>> http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.02/ >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >>>>>> bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >>>>>> Sent: Donnerstag, 16. Februar 2017 21:50 >>>>>> To: hotspot-compiler-dev at openjdk.java.net >>>>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >>>>>> >>>>>> Thank you, Goetz >>>>>> >>>>>> Very nice cleanup! >>>>>> >>>>>> On 2/16/17 9:03 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi Lutz, >>>>>>> >>>>>>> thanks for the review. >>>>>>> >>>>>>> What about naming them con and maskedCon? >>>>>> >>>>>> shift and maskedShift >>>>>> >>>>>> And since you are doing cleanup ;) I want to ask you to factor out in >>>> separate >>>>>> methods (for long and int) checks which >>>>>> are duplicated in all this methods. All of them check if in(2) is integer >>>>>> constant and mask it. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Schmidt, Lutz >>>>>>>> Sent: Donnerstag, 16. Februar 2017 17:55 >>>>>>>> To: Lindenmaier, Goetz ; 'hotspot- >>>>>> compiler- >>>>>>>> dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal >> graph. >>>>>>>> >>>>>>>> Goetz, >>>>>>>> >>>>>>>> Your changes look good. Thanks for cleaning up! >>>>>>>> >>>>>>>> I do have one request, though: >>>>>>>> In the Ideal methods, you are using either local variable names >>>>>> con/in2_con >>>>>>>> or shift/in2_shift. Could you please decide for one variant? Thank >> you. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Lutz >>>>>>>> >>>>>>>> From: hotspot-compiler-dev >>>>>>> bounces at openjdk.java.net >>>>>>> bounces at openjdk.java.net> > on behalf of G?tz Lindenmaier >>>>>>>> >>> >>>>>>>> Date: Donnerstag, 16. Februar 2017 um 09:26 >>>>>>>> To: "'hotspot-compiler-dev at openjdk.java.net >>> compiler- >>>>>>>> dev at openjdk.java.net> '" >>>>>>> > >>>>>>>> Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Constant shift operand > 31 (int) or > 63 (long) are pointless. >>>>>>>> >>>>>>>> Mask them in the ideal graph, i.e. >>>>>>>> >>>>>>>> if a constant is too large replace it by a smaller one. >>>>>>>> >>>>>>>> The code also should use BitsPerJavaInteger instead of BitsPerInt. >>>>>>>> >>>>>>>> Please review this change. I please need a sponsor. >>>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8173470- >> maskShift/webrev.01 >>>>>>>> >>>>>>>> >>>>>>>> From the standard: >>>>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls- >> 15.19 >>>>>>>> >>> 15.19> >>>>>>>> If the promoted type of the left-hand operand is int, only the five >>>> lowest- >>>>>>>> order bits of the right-hand operand are used as the shift distance. It >> is >>>> as >>>>>> if >>>>>>>> the right-hand operand were subjected to a bitwise logical AND >>>> operator >>>>>> & >>>>>>>> (?15.22.1) with the mask value 0x1f (0b11111). The shift distance >>>> actually >>>>>>>> used is therefore always in the range 0 to 31, inclusive. >>>>>>>> >>>>>>>> If the promoted type of the left-hand operand is long, then only the >> six >>>>>>>> lowest-order bits of the right-hand operand are used as the shift >>>>>> distance. It >>>>>>>> is as if the right-hand operand were subjected to a bitwise logical >> AND >>>>>>>> operator & (?15.22.1) with the mask value 0x3f (0b111111). The shift >>>>>>>> distance actually used is therefore always in the range 0 to 63, >>>> inclusive. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Goetz. >>>>>>> From vladimir.kozlov at oracle.com Wed Feb 22 19:17:37 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Feb 2017 11:17:37 -0800 Subject: [9] RFR(S): 8139906: assert(src->section_index_of(target) == CodeBuffer::SECT_NONE) failed: sanity In-Reply-To: <014c7561-1ed7-4f36-2b85-080399cf02bb@oracle.com> References: <014c7561-1ed7-4f36-2b85-080399cf02bb@oracle.com> Message-ID: <19f5aaa3-79e9-ad73-1012-ef46906049f5@oracle.com> Looks good. Thanks, Vladimir On 2/22/17 7:50 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8139906 > http://cr.openjdk.java.net/~thartmann/8139906/webrev.00/ > > On ARM, the card table address used in the g1_post_barrier_slow stub should not be marked as relocatable (similar to what we do on x86 [1]). This was fixed on ARM before but the fix was removed by another change (see comments in the bug). > > Tested with failing test and RBT (running). > > Thanks, > Tobias > > [1] http://hg.openjdk.java.net/jdk9/hs/hotspot/file/fcc911c59d4c/src/cpu/x86/vm/c1_Runtime1_x86.cpp#l1710 > From vladimir.kozlov at oracle.com Wed Feb 22 20:09:03 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Feb 2017 12:09:03 -0800 Subject: RFR(S): 8175096: Use Subword Analysis for set vector size In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A63C6F5E1@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A63C6F5E1@ORSMSX106.amr.corp.intel.com> Message-ID: Hi Vivek, This should go into jdk 10 since it is enhancement. We will consider to backport it into jdk 9 update release later. First, please explain why "Currently subword types cannot use entire vector width using SLP". The only explanation I have is that if loop has mixing types operations then we narrow unroll factor for biggest type: if (cur_max_vector < max_vector) { max_vector = cur_max_vector; And we start with smallest type: int max_vector = Matcher::max_vector_size(T_BYTE); Should we do opposite and start from long T_LONG (small unroll factor) and widen it to smallest type (big unroll factor)?: if (cur_max_vector > max_vector) { max_vector = cur_max_vector; Note, max_vector_size() returns number of elements and not size of vector in bytes. Michael, you are author of this code. What do you think? Thanks, Vladimir On 2/16/17 11:45 AM, Deshpande, Vivek R wrote: > Hi > > > > Currently subword types cannot use entire vector width using SLP. > > This fix analyzes the subword in the loop for possibility of narrowing > and sets the vector size accordingly. > > > > Webrev: > > http://cr.openjdk.java.net/~vdeshpande/8175096/webrev.00/ > > I have also updated the JBS entry. > > https://bugs.openjdk.java.net/browse/JDK-8175096 > > Would you please review and sponsor it. > > > > Regards, > > Vivek > > > From goetz.lindenmaier at sap.com Thu Feb 23 06:17:53 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Feb 2017 06:17:53 +0000 Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. In-Reply-To: <57e112d4-45d8-67a5-68ee-c9b1a165520b@oracle.com> References: <69ee78c1ee774309980ba5bae62bb066@sap.com> <5330af15-cd8b-5b81-7acd-4a4c7de479dd@oracle.com> <35888248-82f2-05eb-0d12-bf0be7e0f040@oracle.com> <1e7fb339a66f4f44bdb8a773e75d67df@sap.com> <20a0910fda3645a8ab9de85cc78911c5@sap.com> <57e112d4-45d8-67a5-68ee-c9b1a165520b@oracle.com> Message-ID: <9c2b30c1b51745f0bf7e1af82abf47dc@sap.com> Hi Vladimir, thanks for sponsoring! Best regards, Goetz. > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 22. Februar 2017 21:10 > To: Lindenmaier, Goetz ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > > Tests passed. I am pushing this fix. > > Thanks, > Vladimir > > On 2/22/17 12:47 AM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > > > that's great, thank you! > > Our tests are fine, also with my recent edits. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > >> Sent: Mittwoch, 22. Februar 2017 00:59 > >> To: Lindenmaier, Goetz ; hotspot-compiler- > >> dev at openjdk.java.net > >> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > >> > >> Good. I will sponsor it after testing. > >> > >> Thanks, > >> Vladimir > >> > >> > >> On 2/19/17 10:52 AM, Lindenmaier, Goetz wrote: > >>> Hi Vladimir, > >>> > >>> I added getShiftCon(): > >>> http://cr.openjdk.java.net/~goetz/wr17/8173470-maskShift/webrev.03/ > >>> > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > >>>> Sent: Freitag, 17. Februar 2017 17:59 > >>>> To: Lindenmaier, Goetz ; hotspot- > compiler- > >>>> dev at openjdk.java.net > >>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > >>>> > >>>> I was think about using find_int_con() and pass in(2) to > >>>> maskedShiftAmount() > >>>> > >>>> static int maskShiftAmount(PhaseGVN *phase, Node *shiftNode, int > >> nBits) { > >>>> jint shift = phase->find_int_con(shiftNode, 0); // Use 0 as default > for > >>>> the check to work in both cases > >>>> jint maskedShift = shift & (nBits - 1); > >>>> > >>>> if (maskedShift == 0) return 0; // Let Identity() handle 0 shift count. > >>>> > >>>> if (shift != maskedShift) { > >>>> shiftNode->set_req(2, phase->intcon(maskedShift)); // Replace shift > >> count > >>>> with masked value. > >>>> } > >>>> > >>>> return maskedShift; > >>>> } > >>>> > >>>> And all Identity (with corresponding mask): > >>>> > >>>> Node* LShiftINode::Identity(PhaseGVN* phase) { > >>>> return (phase->find_int_con(in(2), -1) & (BitsPerJavaInteger - 1)) == 0) > ? > >>>> in(1) : this; > >>>> > >>>> > >>>> Thanks, > >>>> Vladimir > >>>> > >>>> On 2/16/17 11:25 PM, Lindenmaier, Goetz wrote: > >>>>> Hi Vladimir, > >>>>> > >>>>> Thanks for looking at this. > >>>>> > >>>>> I moved the code to a new method "maskShiftAmount" > >>>>> http://cr.openjdk.java.net/~goetz/wr17/8173470- > maskShift/webrev.02/ > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > >>>>>> bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > >>>>>> Sent: Donnerstag, 16. Februar 2017 21:50 > >>>>>> To: hotspot-compiler-dev at openjdk.java.net > >>>>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal > graph. > >>>>>> > >>>>>> Thank you, Goetz > >>>>>> > >>>>>> Very nice cleanup! > >>>>>> > >>>>>> On 2/16/17 9:03 AM, Lindenmaier, Goetz wrote: > >>>>>>> Hi Lutz, > >>>>>>> > >>>>>>> thanks for the review. > >>>>>>> > >>>>>>> What about naming them con and maskedCon? > >>>>>> > >>>>>> shift and maskedShift > >>>>>> > >>>>>> And since you are doing cleanup ;) I want to ask you to factor out in > >>>> separate > >>>>>> methods (for long and int) checks which > >>>>>> are duplicated in all this methods. All of them check if in(2) is integer > >>>>>> constant and mask it. > >>>>>> > >>>>>> Thanks, > >>>>>> Vladimir > >>>>>> > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Schmidt, Lutz > >>>>>>>> Sent: Donnerstag, 16. Februar 2017 17:55 > >>>>>>>> To: Lindenmaier, Goetz ; 'hotspot- > >>>>>> compiler- > >>>>>>>> dev at openjdk.java.net' > >>>>>>>> Subject: Re: RFR(M): 8173470: [C2] Mask shift operands in ideal > >> graph. > >>>>>>>> > >>>>>>>> Goetz, > >>>>>>>> > >>>>>>>> Your changes look good. Thanks for cleaning up! > >>>>>>>> > >>>>>>>> I do have one request, though: > >>>>>>>> In the Ideal methods, you are using either local variable names > >>>>>> con/in2_con > >>>>>>>> or shift/in2_shift. Could you please decide for one variant? Thank > >> you. > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Lutz > >>>>>>>> > >>>>>>>> From: hotspot-compiler-dev >>>>>>>> bounces at openjdk.java.net >>>>>>>> bounces at openjdk.java.net> > on behalf of G?tz Lindenmaier > >>>>>>>> > >>> > >>>>>>>> Date: Donnerstag, 16. Februar 2017 um 09:26 > >>>>>>>> To: "'hotspot-compiler-dev at openjdk.java.net >>>> compiler- > >>>>>>>> dev at openjdk.java.net> '" dev at openjdk.java.net > >>>>>>>> > > >>>>>>>> Subject: RFR(M): 8173470: [C2] Mask shift operands in ideal graph. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Constant shift operand > 31 (int) or > 63 (long) are pointless. > >>>>>>>> > >>>>>>>> Mask them in the ideal graph, i.e. > >>>>>>>> > >>>>>>>> if a constant is too large replace it by a smaller one. > >>>>>>>> > >>>>>>>> The code also should use BitsPerJavaInteger instead of BitsPerInt. > >>>>>>>> > >>>>>>>> Please review this change. I please need a sponsor. > >>>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8173470- > >> maskShift/webrev.01 > >>>>>>>> > >>>>>>>> > >>>>>>>> From the standard: > >>>>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls- > >> 15.19 > >>>>>>>> >>>> 15.19> > >>>>>>>> If the promoted type of the left-hand operand is int, only the five > >>>> lowest- > >>>>>>>> order bits of the right-hand operand are used as the shift distance. > It > >> is > >>>> as > >>>>>> if > >>>>>>>> the right-hand operand were subjected to a bitwise logical AND > >>>> operator > >>>>>> & > >>>>>>>> (?15.22.1) with the mask value 0x1f (0b11111). The shift distance > >>>> actually > >>>>>>>> used is therefore always in the range 0 to 31, inclusive. > >>>>>>>> > >>>>>>>> If the promoted type of the left-hand operand is long, then only > the > >> six > >>>>>>>> lowest-order bits of the right-hand operand are used as the shift > >>>>>> distance. It > >>>>>>>> is as if the right-hand operand were subjected to a bitwise logical > >> AND > >>>>>>>> operator & (?15.22.1) with the mask value 0x3f (0b111111). The > shift > >>>>>>>> distance actually used is therefore always in the range 0 to 63, > >>>> inclusive. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> > >>>>>>>> Goetz. > >>>>>>> From tobias.hartmann at oracle.com Thu Feb 23 09:08:23 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Feb 2017 10:08:23 +0100 Subject: [9] RFR(S): 8139906: assert(src->section_index_of(target) == CodeBuffer::SECT_NONE) failed: sanity In-Reply-To: <19f5aaa3-79e9-ad73-1012-ef46906049f5@oracle.com> References: <014c7561-1ed7-4f36-2b85-080399cf02bb@oracle.com> <19f5aaa3-79e9-ad73-1012-ef46906049f5@oracle.com> Message-ID: <027068e9-6be9-c880-1ad5-5e9e7da24e19@oracle.com> Thanks, Vladimir! Best regards, Tobias On 22.02.2017 20:17, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 2/22/17 7:50 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8139906 >> http://cr.openjdk.java.net/~thartmann/8139906/webrev.00/ >> >> On ARM, the card table address used in the g1_post_barrier_slow stub should not be marked as relocatable (similar to what we do on x86 [1]). This was fixed on ARM before but the fix was removed by another change (see comments in the bug). >> >> Tested with failing test and RBT (running). >> >> Thanks, >> Tobias >> >> [1] http://hg.openjdk.java.net/jdk9/hs/hotspot/file/fcc911c59d4c/src/cpu/x86/vm/c1_Runtime1_x86.cpp#l1710 >> From lutz.schmidt at sap.com Thu Feb 23 09:26:28 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 23 Feb 2017 09:26:28 +0000 Subject: RFR (S) 8175370: Fix C calling convention for CRC32C and Adler32 intrinsics Message-ID: Hi all, may I kindly request reviews for my small bug fix? Further down the road, I would need a sponsor, too. Bug: https://bugs.openjdk.java.net/browse/JDK-8175370 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175370/ Description: On some platforms (ppc, s390) the C calling convention requires ?int? arguments to be converted to ?long? by the caller. This requirement was not observed by c2-generated calls to the CRC32C and Adler32 intrinsics. The fix was rather simple, using the calls from the CRC32 intrinsics as a template. This is not an issue as of now. The affected intrinsics are not yet (but will soon be) implemented. You may see this as a preemptive bug fix. Thanks, Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.backman at oracle.com Thu Feb 23 12:56:25 2017 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Thu, 23 Feb 2017 13:56:25 +0100 Subject: RFR(S): 8175336: [TESTBUG] aot junit tests added by 8169588 are not executed. Message-ID: <20170223125625.GA23681@rbackman> Hi. Can I please have reviews for this change? Just a couple of test fixes that didn't come with the original push. http://cr.openjdk.java.net/~rbackman/8175336/ https://bugs.openjdk.java.net/browse/JDK-8175336 Thanks /R From michael.c.berg at intel.com Thu Feb 23 17:03:43 2017 From: michael.c.berg at intel.com (Berg, Michael C) Date: Thu, 23 Feb 2017 17:03:43 +0000 Subject: RFR(S): 8175096: Use Subword Analysis for set vector size In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2A63C6F5E1@ORSMSX106.amr.corp.intel.com> Message-ID: I think using the current approach is the best way, it find the consistent shared vectorsize that is optimal for the loop for unrolling to act to. This additional approach augments that by some testing of constraints as the subword types are often occluded by sign and zero extension artifacts that would otherwise have caused the next common size to surface. These subword types are only in the integer subtype domain. Regards, Michael -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, February 22, 2017 12:09 PM To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net Cc: Viswanathan, Sandhya ; Berg, Michael C Subject: Re: RFR(S): 8175096: Use Subword Analysis for set vector size Hi Vivek, This should go into jdk 10 since it is enhancement. We will consider to backport it into jdk 9 update release later. First, please explain why "Currently subword types cannot use entire vector width using SLP". The only explanation I have is that if loop has mixing types operations then we narrow unroll factor for biggest type: if (cur_max_vector < max_vector) { max_vector = cur_max_vector; And we start with smallest type: int max_vector = Matcher::max_vector_size(T_BYTE); Should we do opposite and start from long T_LONG (small unroll factor) and widen it to smallest type (big unroll factor)?: if (cur_max_vector > max_vector) { max_vector = cur_max_vector; Note, max_vector_size() returns number of elements and not size of vector in bytes. Michael, you are author of this code. What do you think? Thanks, Vladimir On 2/16/17 11:45 AM, Deshpande, Vivek R wrote: > Hi > > > > Currently subword types cannot use entire vector width using SLP. > > This fix analyzes the subword in the loop for possibility of narrowing > and sets the vector size accordingly. > > > > Webrev: > > http://cr.openjdk.java.net/~vdeshpande/8175096/webrev.00/ > > I have also updated the JBS entry. > > https://bugs.openjdk.java.net/browse/JDK-8175096 > > Would you please review and sponsor it. > > > > Regards, > > Vivek > > > From vladimir.kozlov at oracle.com Thu Feb 23 18:18:20 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Feb 2017 10:18:20 -0800 Subject: RFR(S): 8175336: [TESTBUG] aot junit tests added by 8169588 are not executed. In-Reply-To: <20170223125625.GA23681@rbackman> References: <20170223125625.GA23681@rbackman> Message-ID: <4a04ff1c-f4b0-6f14-1bd8-683dcb880650@oracle.com> Good. Thank you, Rickard. Vladimir On 2/23/17 4:56 AM, Rickard B?ckman wrote: > Hi. > Can I please have reviews for this change? > > Just a couple of test fixes that didn't come with the original push. > > http://cr.openjdk.java.net/~rbackman/8175336/ > https://bugs.openjdk.java.net/browse/JDK-8175336 > > Thanks > /R > From lutz.schmidt at sap.com Fri Feb 24 10:05:17 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 24 Feb 2017 10:05:17 +0000 Subject: RFR (S) 8175370: Fix C calling convention for CRC32C and Adler32 intrinsics In-Reply-To: References: Message-ID: <1D0735C5-A654-4019-98A1-49690BBA7A05@sap.com> Hi all, I would like to request to put all activities re this RFR on hold. As per private communication with Goetz, this fix should not be necessary. On the other hand, my prepared CRC32C contribution, despite almost identical to CRC32, does not run without it. I am looking for that needle? Sorry for the confusion! Regards, Lutz From: hotspot-compiler-dev on behalf of Lutz Schmidt Date: Donnerstag, 23. Februar 2017 um 10:26 To: "hotspot-compiler-dev at openjdk.java.net" Subject: RFR (S) 8175370: Fix C calling convention for CRC32C and Adler32 intrinsics Hi all, may I kindly request reviews for my small bug fix? Further down the road, I would need a sponsor, too. Bug: https://bugs.openjdk.java.net/browse/JDK-8175370 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175370/ Description: On some platforms (ppc, s390) the C calling convention requires ?int? arguments to be converted to ?long? by the caller. This requirement was not observed by c2-generated calls to the CRC32C and Adler32 intrinsics. The fix was rather simple, using the calls from the CRC32 intrinsics as a template. This is not an issue as of now. The affected intrinsics are not yet (but will soon be) implemented. You may see this as a preemptive bug fix. Thanks, Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Fri Feb 24 10:45:38 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 24 Feb 2017 11:45:38 +0100 Subject: RFR: 8175811: [JVMCI] StubRoutines::_multiplyToLen symbol needs to exported Message-ID: <5CEBBB95-5A84-4322-A847-AF7E37F90986@oracle.com> Graal needs to get the address of StubRoutines::_multiplyToLen to intrinsify BigInteger.multiplyToLen. The export of this address was accidentally omitted. http://cr.openjdk.java.net/~dnsimon/8175811/webrev/ https://bugs.openjdk.java.net/browse/JDK-8175811 -Doug From tobias.hartmann at oracle.com Fri Feb 24 10:50:52 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 24 Feb 2017 11:50:52 +0100 Subject: RFR: 8175811: [JVMCI] StubRoutines::_multiplyToLen symbol needs to exported In-Reply-To: <5CEBBB95-5A84-4322-A847-AF7E37F90986@oracle.com> References: <5CEBBB95-5A84-4322-A847-AF7E37F90986@oracle.com> Message-ID: <54c8d85f-31e7-19b9-5ce6-4b01072904da@oracle.com> Hi, On 24.02.2017 11:45, Doug Simon wrote: > Graal needs to get the address of StubRoutines::_multiplyToLen to intrinsify BigInteger.multiplyToLen. The export of this address was accidentally omitted. > > http://cr.openjdk.java.net/~dnsimon/8175811/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8175811 Looks good to me. Best regards, Tobias > > -Doug > From doug.simon at oracle.com Fri Feb 24 10:57:04 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 24 Feb 2017 11:57:04 +0100 Subject: RFR: 8175811: [JVMCI] StubRoutines::_multiplyToLen symbol needs to exported In-Reply-To: <54c8d85f-31e7-19b9-5ce6-4b01072904da@oracle.com> References: <5CEBBB95-5A84-4322-A847-AF7E37F90986@oracle.com> <54c8d85f-31e7-19b9-5ce6-4b01072904da@oracle.com> Message-ID: Thanks for the review. -Doug > On 24 Feb 2017, at 11:50, Tobias Hartmann wrote: > > Hi, > > On 24.02.2017 11:45, Doug Simon wrote: >> Graal needs to get the address of StubRoutines::_multiplyToLen to intrinsify BigInteger.multiplyToLen. The export of this address was accidentally omitted. >> >> http://cr.openjdk.java.net/~dnsimon/8175811/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8175811 > > Looks good to me. > > Best regards, > Tobias > >> >> -Doug >> From rickard.backman at oracle.com Fri Feb 24 12:52:25 2017 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 24 Feb 2017 13:52:25 +0100 Subject: RFR(XS): 8175815: Quarantine compiler/aot/DeoptimizationTest.java Message-ID: <20170224125225.GC3193@rbackman> Hi, this test is failing intermittently in JPRT. Suggest we quarantine the test until we have a fix. webrev: http://cr.openjdk.java.net/~rbackman/8175815/ bug: https://bugs.openjdk.java.net/browse/JDK-8175815 Thanks /R From tobias.hartmann at oracle.com Fri Feb 24 12:53:44 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 24 Feb 2017 13:53:44 +0100 Subject: RFR(XS): 8175815: Quarantine compiler/aot/DeoptimizationTest.java In-Reply-To: <20170224125225.GC3193@rbackman> References: <20170224125225.GC3193@rbackman> Message-ID: Hi Rickard, looks good. Thanks, Tobias On 24.02.2017 13:52, Rickard B?ckman wrote: > Hi, > > this test is failing intermittently in JPRT. Suggest we quarantine the > test until we have a fix. > > webrev: http://cr.openjdk.java.net/~rbackman/8175815/ > bug: https://bugs.openjdk.java.net/browse/JDK-8175815 > > Thanks > /R > From rickard.backman at oracle.com Fri Feb 24 12:56:11 2017 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 24 Feb 2017 13:56:11 +0100 Subject: RFR(XS): 8175815: Quarantine compiler/aot/DeoptimizationTest.java In-Reply-To: References: <20170224125225.GC3193@rbackman> Message-ID: <20170224125611.GD3193@rbackman> Thank you. /R On 02/24, Tobias Hartmann wrote: > Hi Rickard, > > looks good. > > Thanks, > Tobias > > On 24.02.2017 13:52, Rickard B?ckman wrote: > > Hi, > > > > this test is failing intermittently in JPRT. Suggest we quarantine the > > test until we have a fix. > > > > webrev: http://cr.openjdk.java.net/~rbackman/8175815/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8175815 > > > > Thanks > > /R > > From rwestrel at redhat.com Fri Feb 24 14:17:35 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 24 Feb 2017 15:17:35 +0100 Subject: [8u] request for approval: 8174164 & 8175097: SafePointNode::_replaced_nodes breaks with irreducible loops Message-ID: Hi, I'd like to backport 8174164 (and its test case 8175097) to 8u as it's an issue reported by one of our (Red Hat) customers. The patch doesn't apply cleanly: the part of library_call.cpp fails to apply but given library_call.cpp in 8u doesn't need to be changed for that fix, that part of the patch can simply be removed. So I assume no re-review is necessary. It was pushed to jdk9 1 week ago and hasn't caused any follow up bugs that I know of. https://bugs.openjdk.java.net/browse/JDK-8174164 http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/35db0413819a https://bugs.openjdk.java.net/browse/JDK-8175097 http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8241f87c4712 8u webrev: http://cr.openjdk.java.net/~roland/8174164.8u/webrev.00/ Roland. From rickard.backman at oracle.com Fri Feb 24 14:27:22 2017 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 24 Feb 2017 15:27:22 +0100 Subject: RFR(XS): 8175815: Quarantine compiler/aot/DeoptimizationTest.java In-Reply-To: <20170224125611.GD3193@rbackman> References: <20170224125225.GC3193@rbackman> <20170224125611.GD3193@rbackman> Message-ID: <20170224142722.GE3193@rbackman> This push failed in JPRT as well. Adding all Windows AOT tests. webrev: http://cr.openjdk.java.net/~rbackman/8175815.1/ /R On 02/24, Rickard B?ckman wrote: > Thank you. > > /R > > On 02/24, Tobias Hartmann wrote: > > Hi Rickard, > > > > looks good. > > > > Thanks, > > Tobias > > > > On 24.02.2017 13:52, Rickard B?ckman wrote: > > > Hi, > > > > > > this test is failing intermittently in JPRT. Suggest we quarantine the > > > test until we have a fix. > > > > > > webrev: http://cr.openjdk.java.net/~rbackman/8175815/ > > > bug: https://bugs.openjdk.java.net/browse/JDK-8175815 > > > > > > Thanks > > > /R > > > From tobias.hartmann at oracle.com Fri Feb 24 14:30:28 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 24 Feb 2017 15:30:28 +0100 Subject: RFR(XS): 8175815: Quarantine compiler/aot/DeoptimizationTest.java In-Reply-To: <20170224142722.GE3193@rbackman> References: <20170224125225.GC3193@rbackman> <20170224125611.GD3193@rbackman> <20170224142722.GE3193@rbackman> Message-ID: <8a9c39df-46dc-eaa1-3678-ec716bf54459@oracle.com> On 24.02.2017 15:27, Rickard B?ckman wrote: > This push failed in JPRT as well. > Adding all Windows AOT tests. > > webrev: http://cr.openjdk.java.net/~rbackman/8175815.1/ Looks good, please update the bug accordingly. Thanks, Tobias > > /R > > On 02/24, Rickard B?ckman wrote: >> Thank you. >> >> /R >> >> On 02/24, Tobias Hartmann wrote: >>> Hi Rickard, >>> >>> looks good. >>> >>> Thanks, >>> Tobias >>> >>> On 24.02.2017 13:52, Rickard B?ckman wrote: >>>> Hi, >>>> >>>> this test is failing intermittently in JPRT. Suggest we quarantine the >>>> test until we have a fix. >>>> >>>> webrev: http://cr.openjdk.java.net/~rbackman/8175815/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8175815 >>>> >>>> Thanks >>>> /R >>>> From rickard.backman at oracle.com Fri Feb 24 14:51:29 2017 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 24 Feb 2017 15:51:29 +0100 Subject: RFR(XS): 8175815: Quarantine compiler/aot/DeoptimizationTest.java In-Reply-To: <8a9c39df-46dc-eaa1-3678-ec716bf54459@oracle.com> References: <20170224125225.GC3193@rbackman> <20170224125611.GD3193@rbackman> <20170224142722.GE3193@rbackman> <8a9c39df-46dc-eaa1-3678-ec716bf54459@oracle.com> Message-ID: <20170224145129.GF3193@rbackman> Thank you. Updated the subtask. /R On 02/24, Tobias Hartmann wrote: > > On 24.02.2017 15:27, Rickard B?ckman wrote: > > This push failed in JPRT as well. > > Adding all Windows AOT tests. > > > > webrev: http://cr.openjdk.java.net/~rbackman/8175815.1/ > > Looks good, please update the bug accordingly. > > Thanks, > Tobias > > > > > /R > > > > On 02/24, Rickard B?ckman wrote: > >> Thank you. > >> > >> /R > >> > >> On 02/24, Tobias Hartmann wrote: > >>> Hi Rickard, > >>> > >>> looks good. > >>> > >>> Thanks, > >>> Tobias > >>> > >>> On 24.02.2017 13:52, Rickard B?ckman wrote: > >>>> Hi, > >>>> > >>>> this test is failing intermittently in JPRT. Suggest we quarantine the > >>>> test until we have a fix. > >>>> > >>>> webrev: http://cr.openjdk.java.net/~rbackman/8175815/ > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8175815 > >>>> > >>>> Thanks > >>>> /R > >>>> From lutz.schmidt at sap.com Fri Feb 24 15:27:38 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 24 Feb 2017 15:27:38 +0000 Subject: RFR (S) 8175370: Fix C calling convention for CRC32C and Adler32 intrinsics In-Reply-To: <1D0735C5-A654-4019-98A1-49690BBA7A05@sap.com> References: <1D0735C5-A654-4019-98A1-49690BBA7A05@sap.com> Message-ID: Dear all, I have closed the related bug as ?Not an Issue?. This RFR is herewith irrelevant. I hope you did not invest any of your valuable time. Best Regards, Lutz From: hotspot-compiler-dev on behalf of Lutz Schmidt Date: Freitag, 24. Februar 2017 um 11:05 To: "hotspot-compiler-dev at openjdk.java.net" Subject: Re: RFR (S) 8175370: Fix C calling convention for CRC32C and Adler32 intrinsics Hi all, I would like to request to put all activities re this RFR on hold. As per private communication with Goetz, this fix should not be necessary. On the other hand, my prepared CRC32C contribution, despite almost identical to CRC32, does not run without it. I am looking for that needle? Sorry for the confusion! Regards, Lutz From: hotspot-compiler-dev on behalf of Lutz Schmidt Date: Donnerstag, 23. Februar 2017 um 10:26 To: "hotspot-compiler-dev at openjdk.java.net" Subject: RFR (S) 8175370: Fix C calling convention for CRC32C and Adler32 intrinsics Hi all, may I kindly request reviews for my small bug fix? Further down the road, I would need a sponsor, too. Bug: https://bugs.openjdk.java.net/browse/JDK-8175370 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175370/ Description: On some platforms (ppc, s390) the C calling convention requires ?int? arguments to be converted to ?long? by the caller. This requirement was not observed by c2-generated calls to the CRC32C and Adler32 intrinsics. The fix was rather simple, using the calls from the CRC32 intrinsics as a template. This is not an issue as of now. The affected intrinsics are not yet (but will soon be) implemented. You may see this as a preemptive bug fix. Thanks, Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Feb 24 16:20:38 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Feb 2017 08:20:38 -0800 Subject: [8u] request for approval: 8174164 & 8175097: SafePointNode::_replaced_nodes breaks with irreducible loops In-Reply-To: References: Message-ID: <5f99874c-8f2e-735c-315e-bd9c454435e6@oracle.com> 8u changes looks good. Thanks, Vladimir On 2/24/17 6:17 AM, Roland Westrelin wrote: > > Hi, > > I'd like to backport 8174164 (and its test case 8175097) to 8u as it's > an issue reported by one of our (Red Hat) customers. The patch doesn't > apply cleanly: the part of library_call.cpp fails to apply but given > library_call.cpp in 8u doesn't need to be changed for that fix, that > part of the patch can simply be removed. So I assume no re-review is > necessary. It was pushed to jdk9 1 week ago and hasn't caused any follow > up bugs that I know of. > > https://bugs.openjdk.java.net/browse/JDK-8174164 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/35db0413819a > https://bugs.openjdk.java.net/browse/JDK-8175097 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/8241f87c4712 > > 8u webrev: > > http://cr.openjdk.java.net/~roland/8174164.8u/webrev.00/ > > Roland. > From vladimir.kozlov at oracle.com Fri Feb 24 17:28:23 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Feb 2017 09:28:23 -0800 Subject: [9] RFR(XS) 8175516: JNI exception pending in jdk_tools_jaotc_jnilibelf_JNILibELFAPI.c:97 Message-ID: <24f5a3d1-fecf-b507-5267-2e44709aacab@oracle.com> http://cr.openjdk.java.net/~kvn/8175516/webrev/ Added missing NULL check after JNI call. Thanks, Vladimir From vladimir.kozlov at oracle.com Fri Feb 24 18:07:00 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Feb 2017 10:07:00 -0800 Subject: RFR(S): 8175096: Use Subword Analysis for set vector size In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2A63C6F5E1@ORSMSX106.amr.corp.intel.com> Message-ID: <37b3da72-c082-7b1b-bf2d-18209b25faa2@oracle.com> On 2/23/17 9:03 AM, Berg, Michael C wrote: > I think using the current approach is the best way, it find the consistent shared vectorsize that is optimal for the loop for unrolling to act to. This additional approach augments that by some testing of constraints as the subword types are often occluded by sign and zero extension artifacts that would otherwise have caused the next common size to surface. These subword types are only in the integer subtype domain. "optimal" has wide meaning :) Currently it means small number of unrolls in presence of wide (long, double) values. And if it is optimal why we need this additional fix (8175096)? I still did not get answer about why "Currently subword types cannot use entire vector width using SLP". In what cases this happen? Thanks, Vladimir > > Regards, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, February 22, 2017 12:09 PM > To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net > Cc: Viswanathan, Sandhya ; Berg, Michael C > Subject: Re: RFR(S): 8175096: Use Subword Analysis for set vector size > > Hi Vivek, > > This should go into jdk 10 since it is enhancement. We will consider to backport it into jdk 9 update release later. > > First, please explain why "Currently subword types cannot use entire vector width using SLP". > > The only explanation I have is that if loop has mixing types operations then we narrow unroll factor for biggest type: > > if (cur_max_vector < max_vector) { > max_vector = cur_max_vector; > > And we start with smallest type: > > int max_vector = Matcher::max_vector_size(T_BYTE); > > Should we do opposite and start from long T_LONG (small unroll factor) and widen it to smallest type (big unroll factor)?: > > if (cur_max_vector > max_vector) { > max_vector = cur_max_vector; > > Note, max_vector_size() returns number of elements and not size of vector in bytes. > > Michael, you are author of this code. What do you think? > > Thanks, > Vladimir > > On 2/16/17 11:45 AM, Deshpande, Vivek R wrote: >> Hi >> >> >> >> Currently subword types cannot use entire vector width using SLP. >> >> This fix analyzes the subword in the loop for possibility of narrowing >> and sets the vector size accordingly. >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/8175096/webrev.00/ >> >> I have also updated the JBS entry. >> >> https://bugs.openjdk.java.net/browse/JDK-8175096 >> >> Would you please review and sponsor it. >> >> >> >> Regards, >> >> Vivek >> >> >> From michael.c.berg at intel.com Fri Feb 24 18:56:12 2017 From: michael.c.berg at intel.com (Berg, Michael C) Date: Fri, 24 Feb 2017 18:56:12 +0000 Subject: RFR(S): 8175096: Use Subword Analysis for set vector size In-Reply-To: <37b3da72-c082-7b1b-bf2d-18209b25faa2@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A63C6F5E1@ORSMSX106.amr.corp.intel.com> <37b3da72-c082-7b1b-bf2d-18209b25faa2@oracle.com> Message-ID: Vladimir, The cases for this are for short and byte types stmt expressions, where the memory operations are sized to the key types, but the arithmetic components are not, but instead int as in this case: if (!in->is_Mem() && in_bb(in) && in->bottom_type()->basic_type() == T_INT) for the inputs on short and byte typed operations, as the node n is already bound to is_subword_type(bt). Here is a snippet of code that would show the issue: static final int NUM = 1024; static byte[] data = new byte[NUM], data2 = new byte[NUM], data3 = new byte[NUM]; static short[] data4 = new short[NUM], data5 = new short[NUM], data6 = new short[NUM]; static int[] data7 = new int[NUM], data8 = new int[NUM], data9 = new int[NUM]; public static double count(long X) { long time1, time0 = System.nanoTime(); doit2(X); time1 = System.nanoTime(); return 1f*X/(time1-time0)*1e9; } public static void doit2(long X) { while (X > 0) { for (int i = 0; i < NUM; i++) { data[i] = (byte)(data2[i] + data3[i]); data4[i] = (short)(data5[i] + data6[i]); data7[i] = data8[i] + data9[i]; } X--; } } Where main inits the arrays to some set values for use above. You can even break this it into two cases for each of the byte and short stmt level expressions. We can assert that this is always safe as superword by design does not allow mixed type stmt level expressions where byte and short are intermingled at that level, just the artifacts of boxing the interior components, like arithmetic as int. Regards, Michael -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, February 24, 2017 10:07 AM To: Berg, Michael C ; Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net Cc: Viswanathan, Sandhya Subject: Re: RFR(S): 8175096: Use Subword Analysis for set vector size On 2/23/17 9:03 AM, Berg, Michael C wrote: > I think using the current approach is the best way, it find the consistent shared vectorsize that is optimal for the loop for unrolling to act to. This additional approach augments that by some testing of constraints as the subword types are often occluded by sign and zero extension artifacts that would otherwise have caused the next common size to surface. These subword types are only in the integer subtype domain. "optimal" has wide meaning :) Currently it means small number of unrolls in presence of wide (long, double) values. And if it is optimal why we need this additional fix (8175096)? I still did not get answer about why "Currently subword types cannot use entire vector width using SLP". In what cases this happen? Thanks, Vladimir > > Regards, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, February 22, 2017 12:09 PM > To: Deshpande, Vivek R ; > hotspot-compiler-dev at openjdk.java.net > Cc: Viswanathan, Sandhya ; Berg, > Michael C > Subject: Re: RFR(S): 8175096: Use Subword Analysis for set vector size > > Hi Vivek, > > This should go into jdk 10 since it is enhancement. We will consider to backport it into jdk 9 update release later. > > First, please explain why "Currently subword types cannot use entire vector width using SLP". > > The only explanation I have is that if loop has mixing types operations then we narrow unroll factor for biggest type: > > if (cur_max_vector < max_vector) { > max_vector = cur_max_vector; > > And we start with smallest type: > > int max_vector = Matcher::max_vector_size(T_BYTE); > > Should we do opposite and start from long T_LONG (small unroll factor) and widen it to smallest type (big unroll factor)?: > > if (cur_max_vector > max_vector) { > max_vector = cur_max_vector; > > Note, max_vector_size() returns number of elements and not size of vector in bytes. > > Michael, you are author of this code. What do you think? > > Thanks, > Vladimir > > On 2/16/17 11:45 AM, Deshpande, Vivek R wrote: >> Hi >> >> >> >> Currently subword types cannot use entire vector width using SLP. >> >> This fix analyzes the subword in the loop for possibility of >> narrowing and sets the vector size accordingly. >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/8175096/webrev.00/ >> >> I have also updated the JBS entry. >> >> https://bugs.openjdk.java.net/browse/JDK-8175096 >> >> Would you please review and sponsor it. >> >> >> >> Regards, >> >> Vivek >> >> >> From vivek.r.deshpande at intel.com Fri Feb 24 18:56:51 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Fri, 24 Feb 2017 18:56:51 +0000 Subject: RFR(S): 8175096: Use Subword Analysis for set vector size In-Reply-To: <37b3da72-c082-7b1b-bf2d-18209b25faa2@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A63C6F5E1@ORSMSX106.amr.corp.intel.com> <37b3da72-c082-7b1b-bf2d-18209b25faa2@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A63C7DE02@ORSMSX106.amr.corp.intel.com> Hi Vladimir Subwords get converted to int by broadening for the operations on them and max_vector gets set according to int, even if there are no mixed type operations, leading to short vector width instructions. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, February 24, 2017 10:07 AM To: Berg, Michael C; Deshpande, Vivek R; hotspot-compiler-dev at openjdk.java.net Cc: Viswanathan, Sandhya Subject: Re: RFR(S): 8175096: Use Subword Analysis for set vector size On 2/23/17 9:03 AM, Berg, Michael C wrote: > I think using the current approach is the best way, it find the consistent shared vectorsize that is optimal for the loop for unrolling to act to. This additional approach augments that by some testing of constraints as the subword types are often occluded by sign and zero extension artifacts that would otherwise have caused the next common size to surface. These subword types are only in the integer subtype domain. "optimal" has wide meaning :) Currently it means small number of unrolls in presence of wide (long, double) values. And if it is optimal why we need this additional fix (8175096)? I still did not get answer about why "Currently subword types cannot use entire vector width using SLP". In what cases this happen? Thanks, Vladimir > > Regards, > Michael > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, February 22, 2017 12:09 PM > To: Deshpande, Vivek R ; > hotspot-compiler-dev at openjdk.java.net > Cc: Viswanathan, Sandhya ; Berg, > Michael C > Subject: Re: RFR(S): 8175096: Use Subword Analysis for set vector size > > Hi Vivek, > > This should go into jdk 10 since it is enhancement. We will consider to backport it into jdk 9 update release later. > > First, please explain why "Currently subword types cannot use entire vector width using SLP". > > The only explanation I have is that if loop has mixing types operations then we narrow unroll factor for biggest type: > > if (cur_max_vector < max_vector) { > max_vector = cur_max_vector; > > And we start with smallest type: > > int max_vector = Matcher::max_vector_size(T_BYTE); > > Should we do opposite and start from long T_LONG (small unroll factor) and widen it to smallest type (big unroll factor)?: > > if (cur_max_vector > max_vector) { > max_vector = cur_max_vector; > > Note, max_vector_size() returns number of elements and not size of vector in bytes. > > Michael, you are author of this code. What do you think? > > Thanks, > Vladimir > > On 2/16/17 11:45 AM, Deshpande, Vivek R wrote: >> Hi >> >> >> >> Currently subword types cannot use entire vector width using SLP. >> >> This fix analyzes the subword in the loop for possibility of >> narrowing and sets the vector size accordingly. >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/8175096/webrev.00/ >> >> I have also updated the JBS entry. >> >> https://bugs.openjdk.java.net/browse/JDK-8175096 >> >> Would you please review and sponsor it. >> >> >> >> Regards, >> >> Vivek >> >> >> From igor.veresov at oracle.com Mon Feb 27 06:29:36 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Sun, 26 Feb 2017 22:29:36 -0800 Subject: [9] RFR(XS) 8175516: JNI exception pending in jdk_tools_jaotc_jnilibelf_JNILibELFAPI.c:97 In-Reply-To: <24f5a3d1-fecf-b507-5267-2e44709aacab@oracle.com> References: <24f5a3d1-fecf-b507-5267-2e44709aacab@oracle.com> Message-ID: <64C16ACC-E4AB-4110-9A48-D065033CC64B@oracle.com> retObj probably needs to be nulled out? Also there is a whole bunch of return values we don?t check in getNativeAddress() and makePointerObject(). igor > On Feb 24, 2017, at 9:28 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8175516/webrev/ > > Added missing NULL check after JNI call. > > Thanks, > Vladimir From shade at redhat.com Mon Feb 27 09:53:16 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 Feb 2017 10:53:16 +0100 Subject: RFC 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect? Message-ID: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> Hi, Seeing failures on new jcstress runs: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2017/056/results/ These "opaque" tests should never fail. I eyeballed the test, and this is not a test bug. C1 does not have intrinsics for Opaque, and therefore it should delegate Opaque ops to volatile via fallbacks in Unsafe.java. But now I read the C1 Unsafe.getObject handling, and my hair stand on end, because I think C1 {L,G}VN does not treat volatile Unsafe ops any specially, while it probably should: https://bugs.openjdk.java.net/browse/JDK-8175887 Makes sense? Thanks, -Aleksey P.S. Linaro CI seems misconfigured by always running with C1, so can't see if that is C1 specific or not: http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2017-February/004246.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Mon Feb 27 14:12:17 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 Feb 2017 15:12:17 +0100 Subject: RFR (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> Message-ID: On 02/27/2017 10:53 AM, Aleksey Shipilev wrote: > C1 does not have intrinsics for Opaque, and therefore it should delegate Opaque > ops to volatile via fallbacks in Unsafe.java. But now I read the C1 > Unsafe.getObject handling, and my hair stand on end, because I think C1 {L,G}VN > does not treat volatile Unsafe ops any specially, while it probably should: > https://bugs.openjdk.java.net/browse/JDK-8175887 > > Makes sense? This is the actual reproducible bug, changing the thread subject. Fix against jdk9/hs: http://cr.openjdk.java.net/~shade/8175887/webrev.01/ Testing: Linux x86_64/release hotspot/test/compiler, includes new tests I need a sponsor. I think this bugfix is too important to miss 9, and it even deserves backporting to 8u. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From stuart.monteith at linaro.org Mon Feb 27 14:32:05 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 27 Feb 2017 14:32:05 +0000 Subject: RFC 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect? In-Reply-To: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> Message-ID: <9fa5ead1-9736-f1a5-8ec6-3072a970d632@linaro.org> Hi, I've run this particular test with no options manually and a build from today and see the following: Will throw any pending exceptions at this point. Exception in thread "main" java.lang.AssertionError: TEST FAILURES: org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-client, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-server, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, -XX:+StressGCM]: Observed forbidden state: -1, 0 org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-server]: Observed forbidden state: -1, 0 org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-server, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-client]: Observed forbidden state: -1, 0 org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-server, -XX:-TieredCompilation, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, -XX:+StressGCM]: Observed forbidden state: -1, 0 Applying your patch and rerunning this test on the aarch64 machine causes these tests to pass. Now doing a full run. It should be finished by Tuesday. BR, Stuart On 27/02/17 09:53, Aleksey Shipilev wrote: > Hi, > > Seeing failures on new jcstress runs: > http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2017/056/results/ > > These "opaque" tests should never fail. I eyeballed the test, and this is not a > test bug. > > C1 does not have intrinsics for Opaque, and therefore it should delegate Opaque > ops to volatile via fallbacks in Unsafe.java. But now I read the C1 > Unsafe.getObject handling, and my hair stand on end, because I think C1 {L,G}VN > does not treat volatile Unsafe ops any specially, while it probably should: > https://bugs.openjdk.java.net/browse/JDK-8175887 > > Makes sense? > > Thanks, > -Aleksey > > P.S. Linaro CI seems misconfigured by always running with C1, so can't see if > that is C1 specific or not: > http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2017-February/004246.html > From shade at redhat.com Mon Feb 27 14:35:15 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 Feb 2017 15:35:15 +0100 Subject: RFC 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect? In-Reply-To: <9fa5ead1-9736-f1a5-8ec6-3072a970d632@linaro.org> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> <9fa5ead1-9736-f1a5-8ec6-3072a970d632@linaro.org> Message-ID: <6c8eddc6-6dc8-9f4b-bc1d-87c3c98c7aa8@redhat.com> Hi Stuart, On 02/27/2017 03:32 PM, Stuart Monteith wrote: > Will throw any pending exceptions at this point. > Exception in thread "main" java.lang.AssertionError: TEST FAILURES: > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-client, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-server, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, > -XX:+StressGCM]: Observed forbidden state: -1, 0 > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-server]: Observed forbidden state: -1, 0 > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-server, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-client]: Observed forbidden state: -1, 0 > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-server, -XX:-TieredCompilation, -XX:+UnlockDiagnosticVMOptions, > -XX:+StressLCM, -XX:+StressGCM]: Observed forbidden state: -1, 0 > > Applying your patch and rerunning this test on the aarch64 machine > causes these tests to pass. Now doing a full run. It should be finished > by Tuesday. So Opaque failures on your machines *are* related to this. Good to know, thanks! -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From shade at redhat.com Mon Feb 27 14:39:01 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 Feb 2017 15:39:01 +0100 Subject: RFC 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect? In-Reply-To: <6c8eddc6-6dc8-9f4b-bc1d-87c3c98c7aa8@redhat.com> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> <9fa5ead1-9736-f1a5-8ec6-3072a970d632@linaro.org> <6c8eddc6-6dc8-9f4b-bc1d-87c3c98c7aa8@redhat.com> Message-ID: <819e8dff-e898-4869-745b-de064d8b4c80@redhat.com> On 02/27/2017 03:35 PM, Aleksey Shipilev wrote: > On 02/27/2017 03:32 PM, Stuart Monteith wrote: >> Will throw any pending exceptions at this point. >> Exception in thread "main" java.lang.AssertionError: TEST FAILURES: >> >> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >> [-client, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 >> >> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >> [-server, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, >> -XX:+StressGCM]: Observed forbidden state: -1, 0 >> >> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >> [-server]: Observed forbidden state: -1, 0 >> >> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >> [-server, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 >> >> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >> [-client]: Observed forbidden state: -1, 0 >> >> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >> [-server, -XX:-TieredCompilation, -XX:+UnlockDiagnosticVMOptions, >> -XX:+StressLCM, -XX:+StressGCM]: Observed forbidden state: -1, 0 >> >> Applying your patch and rerunning this test on the aarch64 machine >> causes these tests to pass. Now doing a full run. It should be finished >> by Tuesday. > > So Opaque failures on your machines *are* related to this. Good to know, thanks! It does not sound right though: with -TieredCompilation only C2 should have been working, not C1. Must be something else. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From lutz.schmidt at sap.com Mon Feb 27 14:55:34 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 27 Feb 2017 14:55:34 +0000 Subject: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C Message-ID: Hi all, may I kindly request reviews for my medium enhancement? Further down the road, I would need a sponsor, too. Bug: https://bugs.openjdk.java.net/browse/JDK-8175368 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175368/ Description: This intrinsic implementation provides some performance benefit over the standard Java implementation. It uses only well-known ?standard? instructions, available on all supported IBM System z hardware. Being very similar to the CRC32 intrinsics, it was tried to share as much code as possible between these two. Performance may be expected to increase up to 2.0x, compared to a run with ?XX:-UseCRC32CIntrinsics. Actual speedup depends on the length of the byte array fed into CRC32C and, to some extent, on the H/W generation the test runs on. Thanks, Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.monteith at linaro.org Mon Feb 27 15:21:37 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 27 Feb 2017 15:21:37 +0000 Subject: RFC 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect? In-Reply-To: <819e8dff-e898-4869-745b-de064d8b4c80@redhat.com> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> <9fa5ead1-9736-f1a5-8ec6-3072a970d632@linaro.org> <6c8eddc6-6dc8-9f4b-bc1d-87c3c98c7aa8@redhat.com> <819e8dff-e898-4869-745b-de064d8b4c80@redhat.com> Message-ID: <2d131554-a2c8-e00f-2211-06b16fbd25ec@linaro.org> Actually, rerunning without any jvmargs (which reduced the coverage when testing your patch), I get: org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-client, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-server, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, -XX:+StressGCM]: Observed forbidden state: -1, 0 org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-server, -XX:-TieredCompilation, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, -XX:+StressGCM]: Observed forbidden state: -1, 0 org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-server]: Observed forbidden state: -1, 0 org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-server, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest [-client]: Observed forbidden state: -1, 0 So what I said before was wrong, I do get the failures. Running with -XX:TieredStopAtLevel=1, I don't get failures. Given that -server == -client, all of the failing tests are either against C2 or tiered C1 & C2 compilation. Running with the options passed explicity, "-m tough", the tests pass with: -XX:TieredStopAtLevel=1 (Patched & unpatched) Fails with: -XX:-TieredCompilation " No failures with: -XX:-TieredComplation -Xcomp My other two machines doen't exhibit the failure. BR, Stuart On 27/02/17 14:39, Aleksey Shipilev wrote: > On 02/27/2017 03:35 PM, Aleksey Shipilev wrote: >> On 02/27/2017 03:32 PM, Stuart Monteith wrote: >>> Will throw any pending exceptions at this point. >>> Exception in thread "main" java.lang.AssertionError: TEST FAILURES: >>> >>> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >>> [-client, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 >>> >>> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >>> [-server, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, >>> -XX:+StressGCM]: Observed forbidden state: -1, 0 >>> >>> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >>> [-server]: Observed forbidden state: -1, 0 >>> >>> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >>> [-server, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 >>> >>> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >>> [-client]: Observed forbidden state: -1, 0 >>> >>> org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest >>> [-server, -XX:-TieredCompilation, -XX:+UnlockDiagnosticVMOptions, >>> -XX:+StressLCM, -XX:+StressGCM]: Observed forbidden state: -1, 0 >>> >>> Applying your patch and rerunning this test on the aarch64 machine >>> causes these tests to pass. Now doing a full run. It should be finished >>> by Tuesday. >> >> So Opaque failures on your machines *are* related to this. Good to know, thanks! > > It does not sound right though: with -TieredCompilation only C2 should have been > working, not C1. Must be something else. > > -Aleksey > From shade at redhat.com Mon Feb 27 15:24:35 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 Feb 2017 16:24:35 +0100 Subject: RFC 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect? In-Reply-To: <2d131554-a2c8-e00f-2211-06b16fbd25ec@linaro.org> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> <9fa5ead1-9736-f1a5-8ec6-3072a970d632@linaro.org> <6c8eddc6-6dc8-9f4b-bc1d-87c3c98c7aa8@redhat.com> <819e8dff-e898-4869-745b-de064d8b4c80@redhat.com> <2d131554-a2c8-e00f-2211-06b16fbd25ec@linaro.org> Message-ID: On 02/27/2017 04:21 PM, Stuart Monteith wrote: > Actually, rerunning without any jvmargs (which reduced the coverage when > testing your patch), I get: > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-client, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-server, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, > -XX:+StressGCM]: Observed forbidden state: -1, 0 > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-server, -XX:-TieredCompilation, -XX:+UnlockDiagnosticVMOptions, > -XX:+StressLCM, -XX:+StressGCM]: Observed forbidden state: -1, 0 > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-server]: Observed forbidden state: -1, 0 > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-server, -XX:-TieredCompilation]: Observed forbidden state: -1, 0 > > org.openjdk.jcstress.tests.coherence.varHandles.fields.opaque.ShortTest > [-client]: Observed forbidden state: -1, 0 > > So what I said before was wrong, I do get the failures. > Running with -XX:TieredStopAtLevel=1, I don't get failures. Good. This is what I wanted to know for this patch. > Given that -server == -client, all of the failing tests are either > against C2 or tiered C1 & C2 compilation. > > Running with the options passed explicity, "-m tough", the tests pass with: > -XX:TieredStopAtLevel=1 (Patched & unpatched) > > Fails with: > -XX:-TieredCompilation " > > No failures with: > -XX:-TieredComplation -Xcomp > > My other two machines doen't exhibit the failure. Ok, let's discuss that one separately. These failures seem unrelated to this issue with C1, and most probably indicate some other peculiar issue. Thanks, -Aleksey Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From lutz.schmidt at sap.com Mon Feb 27 17:34:57 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 27 Feb 2017 17:34:57 +0000 Subject: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C In-Reply-To: References: Message-ID: Hi all, the webrev URL below was incorrect. It displayed the correct location, but pointed elsewhere. The issue is fixed now and the URLs are correct. Thank you! Lutz From: Lutz Schmidt Date: Montag, 27. Februar 2017 um 15:55 To: "hotspot-compiler-dev at openjdk.java.net" Subject: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C Hi all, may I kindly request reviews for my medium enhancement? Further down the road, I would need a sponsor, too. Bug: https://bugs.openjdk.java.net/browse/JDK-8175368 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175368/ Description: This intrinsic implementation provides some performance benefit over the standard Java implementation. It uses only well-known ?standard? instructions, available on all supported IBM System z hardware. Being very similar to the CRC32 intrinsics, it was tried to share as much code as possible between these two. Performance may be expected to increase up to 2.0x, compared to a run with ?XX:-UseCRC32CIntrinsics. Actual speedup depends on the length of the byte array fed into CRC32C and, to some extent, on the H/W generation the test runs on. Thanks, Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Feb 27 20:31:30 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Feb 2017 12:31:30 -0800 Subject: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C In-Reply-To: References: Message-ID: <78eb17b4-0451-59bd-1294-922b4cce850b@oracle.com> Hi, Lutz The link to webrev is wrong. It points to 8175370 changes. Vladimir On 2/27/17 6:55 AM, Schmidt, Lutz wrote: > Hi all, > > > > may I kindly request reviews for my medium enhancement? Further down the > road, I would need a sponsor, too. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175368 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175368/ > > > > > Description: > > This intrinsic implementation provides some performance benefit over the > standard Java implementation. It uses only well-known ?standard? > instructions, available on all supported IBM System z hardware. Being > very similar to the CRC32 intrinsics, it was tried to share as much code > as possible between these two. > > > > Performance may be expected to increase up to 2.0x, compared to a run > with ?XX:-UseCRC32CIntrinsics. Actual speedup depends on the length of > the byte array fed into CRC32C and, to some extent, on the H/W > generation the test runs on. > > > > Thanks, > > Lutz > > > From lutz.schmidt at sap.com Mon Feb 27 20:38:39 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 27 Feb 2017 20:38:39 +0000 Subject: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C In-Reply-To: <78eb17b4-0451-59bd-1294-922b4cce850b@oracle.com> References: <78eb17b4-0451-59bd-1294-922b4cce850b@oracle.com> Message-ID: Hi all, thanks, Vladimir, for pointing me to this. I already noticed it, corrected the URL and sent an update to the DL (approx. 3h ago). Regards, Lutz On 27.02.17, 21:31, "Vladimir Kozlov" wrote: Hi, Lutz The link to webrev is wrong. It points to 8175370 changes. Vladimir On 2/27/17 6:55 AM, Schmidt, Lutz wrote: > Hi all, > > > > may I kindly request reviews for my medium enhancement? Further down the > road, I would need a sponsor, too. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175368 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175368/ > > > > > Description: > > This intrinsic implementation provides some performance benefit over the > standard Java implementation. It uses only well-known ?standard? > instructions, available on all supported IBM System z hardware. Being > very similar to the CRC32 intrinsics, it was tried to share as much code > as possible between these two. > > > > Performance may be expected to increase up to 2.0x, compared to a run > with ?XX:-UseCRC32CIntrinsics. Actual speedup depends on the length of > the byte array fed into CRC32C and, to some extent, on the H/W > generation the test runs on. > > > > Thanks, > > Lutz > > > From vladimir.kozlov at oracle.com Mon Feb 27 20:51:29 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Feb 2017 12:51:29 -0800 Subject: [9] RFR(XS) 8175516: JNI exception pending in jdk_tools_jaotc_jnilibelf_JNILibELFAPI.c:97 In-Reply-To: <64C16ACC-E4AB-4110-9A48-D065033CC64B@oracle.com> References: <24f5a3d1-fecf-b507-5267-2e44709aacab@oracle.com> <64C16ACC-E4AB-4110-9A48-D065033CC64B@oracle.com> Message-ID: <5effc844-58ad-7998-094b-25cdba252595@oracle.com> On 2/26/17 10:29 PM, Igor Veresov wrote: > retObj probably needs to be nulled out? Right, I forgot that it is not Java. > > Also there is a whole bunch of return values we don?t check in getNativeAddress() and makePointerObject(). Fixed: http://cr.openjdk.java.net/~kvn/8175516/webrev/ Thanks, Vladimir > > igor > >> On Feb 24, 2017, at 9:28 AM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8175516/webrev/ >> >> Added missing NULL check after JNI call. >> >> Thanks, >> Vladimir > From shade at redhat.com Mon Feb 27 21:25:56 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 Feb 2017 22:25:56 +0100 Subject: RFR (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> Message-ID: On 02/27/2017 03:12 PM, Aleksey Shipilev wrote: > On 02/27/2017 10:53 AM, Aleksey Shipilev wrote: >> C1 does not have intrinsics for Opaque, and therefore it should delegate Opaque >> ops to volatile via fallbacks in Unsafe.java. But now I read the C1 >> Unsafe.getObject handling, and my hair stand on end, because I think C1 {L,G}VN >> does not treat volatile Unsafe ops any specially, while it probably should: >> https://bugs.openjdk.java.net/browse/JDK-8175887 >> >> Makes sense? > > This is the actual reproducible bug, changing the thread subject. > > Fix against jdk9/hs: > http://cr.openjdk.java.net/~shade/8175887/webrev.01/ Updated after off-list review (renamed tests, used internal Unsafe): http://cr.openjdk.java.net/~shade/8175887/webrev.02/ Everything else still stands: > Testing: Linux x86_64/release hotspot/test/compiler, includes new tests > > I need a sponsor. I think this bugfix is too important to miss 9, and it even > deserves backporting to 8u. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vladimir.kozlov at oracle.com Mon Feb 27 21:30:30 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Feb 2017 13:30:30 -0800 Subject: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C In-Reply-To: References: Message-ID: <63ff237e-2682-d91a-85f2-67e7a008d9ea@oracle.com> Shared changes are good. I assume s390 code will be reviewed by experts. Thanks, Vladimir On 2/27/17 9:34 AM, Schmidt, Lutz wrote: > Hi all, > > > > the webrev URL below was incorrect. It displayed the correct location, > but pointed elsewhere. The issue is fixed now and the URLs are correct. > > > > Thank you! > > Lutz > > > > *From: *Lutz Schmidt > *Date: *Montag, 27. Februar 2017 um 15:55 > *To: *"hotspot-compiler-dev at openjdk.java.net" > > *Subject: *RFR (M) 8175368: [s390] Provide intrinsic implementation for > CRC32C > > > > Hi all, > > > > may I kindly request reviews for my medium enhancement? Further down the > road, I would need a sponsor, too. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175368 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175368/ > > > > Description: > > This intrinsic implementation provides some performance benefit over the > standard Java implementation. It uses only well-known ?standard? > instructions, available on all supported IBM System z hardware. Being > very similar to the CRC32 intrinsics, it was tried to share as much code > as possible between these two. > > > > Performance may be expected to increase up to 2.0x, compared to a run > with ?XX:-UseCRC32CIntrinsics. Actual speedup depends on the length of > the byte array fed into CRC32C and, to some extent, on the H/W > generation the test runs on. > > > > Thanks, > > Lutz > > > From lutz.schmidt at sap.com Mon Feb 27 21:33:26 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 27 Feb 2017 21:33:26 +0000 Subject: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C In-Reply-To: <63ff237e-2682-d91a-85f2-67e7a008d9ea@oracle.com> References: <63ff237e-2682-d91a-85f2-67e7a008d9ea@oracle.com> Message-ID: Thank you, Vladimir, for looking at this. Regards, Lutz On 27.02.17, 22:30, "Vladimir Kozlov" wrote: Shared changes are good. I assume s390 code will be reviewed by experts. Thanks, Vladimir On 2/27/17 9:34 AM, Schmidt, Lutz wrote: > Hi all, > > > > the webrev URL below was incorrect. It displayed the correct location, > but pointed elsewhere. The issue is fixed now and the URLs are correct. > > > > Thank you! > > Lutz > > > > *From: *Lutz Schmidt > *Date: *Montag, 27. Februar 2017 um 15:55 > *To: *"hotspot-compiler-dev at openjdk.java.net" > > *Subject: *RFR (M) 8175368: [s390] Provide intrinsic implementation for > CRC32C > > > > Hi all, > > > > may I kindly request reviews for my medium enhancement? Further down the > road, I would need a sponsor, too. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175368 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175368/ > > > > Description: > > This intrinsic implementation provides some performance benefit over the > standard Java implementation. It uses only well-known ?standard? > instructions, available on all supported IBM System z hardware. Being > very similar to the CRC32 intrinsics, it was tried to share as much code > as possible between these two. > > > > Performance may be expected to increase up to 2.0x, compared to a run > with ?XX:-UseCRC32CIntrinsics. Actual speedup depends on the length of > the byte array fed into CRC32C and, to some extent, on the H/W > generation the test runs on. > > > > Thanks, > > Lutz > > > From igor.veresov at oracle.com Mon Feb 27 23:40:38 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 27 Feb 2017 15:40:38 -0800 Subject: [9] RFR(XS) 8175516: JNI exception pending in jdk_tools_jaotc_jnilibelf_JNILibELFAPI.c:97 In-Reply-To: <5effc844-58ad-7998-094b-25cdba252595@oracle.com> References: <24f5a3d1-fecf-b507-5267-2e44709aacab@oracle.com> <64C16ACC-E4AB-4110-9A48-D065033CC64B@oracle.com> <5effc844-58ad-7998-094b-25cdba252595@oracle.com> Message-ID: <06162B8F-2D18-4606-8B67-E6AC5BB4B1D6@oracle.com> Looks good. igor > On Feb 27, 2017, at 12:51 PM, Vladimir Kozlov wrote: > > On 2/26/17 10:29 PM, Igor Veresov wrote: >> retObj probably needs to be nulled out? > > Right, I forgot that it is not Java. > >> >> Also there is a whole bunch of return values we don?t check in getNativeAddress() and makePointerObject(). > > Fixed: > > http://cr.openjdk.java.net/~kvn/8175516/webrev/ > > Thanks, > Vladimir > >> >> igor >> >>> On Feb 24, 2017, at 9:28 AM, Vladimir Kozlov wrote: >>> >>> http://cr.openjdk.java.net/~kvn/8175516/webrev/ >>> >>> Added missing NULL check after JNI call. >>> >>> Thanks, >>> Vladimir >> From vladimir.kozlov at oracle.com Mon Feb 27 23:58:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Feb 2017 15:58:50 -0800 Subject: [9] RFR(XS) 8175516: JNI exception pending in jdk_tools_jaotc_jnilibelf_JNILibELFAPI.c:97 In-Reply-To: <06162B8F-2D18-4606-8B67-E6AC5BB4B1D6@oracle.com> References: <24f5a3d1-fecf-b507-5267-2e44709aacab@oracle.com> <64C16ACC-E4AB-4110-9A48-D065033CC64B@oracle.com> <5effc844-58ad-7998-094b-25cdba252595@oracle.com> <06162B8F-2D18-4606-8B67-E6AC5BB4B1D6@oracle.com> Message-ID: <98315753-8fc4-3064-e120-4b806e3d64cf@oracle.com> Thank you, Igor Vladimir On 2/27/17 3:40 PM, Igor Veresov wrote: > Looks good. > > igor > >> On Feb 27, 2017, at 12:51 PM, Vladimir Kozlov wrote: >> >> On 2/26/17 10:29 PM, Igor Veresov wrote: >>> retObj probably needs to be nulled out? >> >> Right, I forgot that it is not Java. >> >>> >>> Also there is a whole bunch of return values we don?t check in getNativeAddress() and makePointerObject(). >> >> Fixed: >> >> http://cr.openjdk.java.net/~kvn/8175516/webrev/ >> >> Thanks, >> Vladimir >> >>> >>> igor >>> >>>> On Feb 24, 2017, at 9:28 AM, Vladimir Kozlov wrote: >>>> >>>> http://cr.openjdk.java.net/~kvn/8175516/webrev/ >>>> >>>> Added missing NULL check after JNI call. >>>> >>>> Thanks, >>>> Vladimir >>> > From martin.doerr at sap.com Tue Feb 28 10:57:12 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 28 Feb 2017 10:57:12 +0000 Subject: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C In-Reply-To: References: <63ff237e-2682-d91a-85f2-67e7a008d9ea@oracle.com> Message-ID: <5e2830119227429b9e6a37ab4d3e6d35@sap.com> Hi Lutz, thank you very much for implementing it. It looks good. I especially like that you share a lot of the code between CRC32 and CRC32C. I only have some minor suggestions: c1_LIRGenerator_s390.cpp load_int_as_long was implemented for stubs which expect sign (or zero) extended integer parameters. As C2 was changed to no longer perform int to long conversions for stub calls, I think this should better be removed from C1, too. The stubs are shared between C1 and C2 and they don't need conversions anymore, so I'd appreciate if the load_int_as_long got removed completely. macroAssembler_s390.cpp The function update_1word_crc32 uses separate load and xor instructions. I think some of them should get combined by using xor register,mem. stubGenerator_s390.cpp The comment in generate_CRC32_updateBytes should be: "must be same register as in generate..." stubRoutines_s390.cpp I didn't review all numbers :-), but I guess you have tested well enough? It'd be nice if you could share some performance numbers. Thanks and best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz Sent: Montag, 27. Februar 2017 22:33 To: Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C Thank you, Vladimir, for looking at this. Regards, Lutz On 27.02.17, 22:30, "Vladimir Kozlov" wrote: Shared changes are good. I assume s390 code will be reviewed by experts. Thanks, Vladimir On 2/27/17 9:34 AM, Schmidt, Lutz wrote: > Hi all, > > > > the webrev URL below was incorrect. It displayed the correct location, > but pointed elsewhere. The issue is fixed now and the URLs are correct. > > > > Thank you! > > Lutz > > > > *From: *Lutz Schmidt > *Date: *Montag, 27. Februar 2017 um 15:55 > *To: *"hotspot-compiler-dev at openjdk.java.net" > > *Subject: *RFR (M) 8175368: [s390] Provide intrinsic implementation for > CRC32C > > > > Hi all, > > > > may I kindly request reviews for my medium enhancement? Further down the > road, I would need a sponsor, too. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175368 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175368/ > > > > Description: > > This intrinsic implementation provides some performance benefit over the > standard Java implementation. It uses only well-known ?standard? > instructions, available on all supported IBM System z hardware. Being > very similar to the CRC32 intrinsics, it was tried to share as much code > as possible between these two. > > > > Performance may be expected to increase up to 2.0x, compared to a run > with ?XX:-UseCRC32CIntrinsics. Actual speedup depends on the length of > the byte array fed into CRC32C and, to some extent, on the H/W > generation the test runs on. > > > > Thanks, > > Lutz > > > From paul.sandoz at oracle.com Tue Feb 28 11:04:05 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 28 Feb 2017 11:04:05 +0000 Subject: RFR (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> Message-ID: > On 27 Feb 2017, at 21:25, Aleksey Shipilev wrote: > > On 02/27/2017 03:12 PM, Aleksey Shipilev wrote: >> On 02/27/2017 10:53 AM, Aleksey Shipilev wrote: >>> C1 does not have intrinsics for Opaque, and therefore it should delegate Opaque >>> ops to volatile via fallbacks in Unsafe.java. But now I read the C1 >>> Unsafe.getObject handling, and my hair stand on end, because I think C1 {L,G}VN >>> does not treat volatile Unsafe ops any specially, while it probably should: >>> https://bugs.openjdk.java.net/browse/JDK-8175887 >>> >>> Makes sense? >> >> This is the actual reproducible bug, changing the thread subject. >> >> Fix against jdk9/hs: >> http://cr.openjdk.java.net/~shade/8175887/webrev.01/ > > Updated after off-list review (renamed tests, used internal Unsafe): > http://cr.openjdk.java.net/~shade/8175887/webrev.02/ > This looks good, with my limited knowledge of C1 (but expanded with some help from Aleksey on explaining GVN), but need someone from the compiler team to formally review. Paul. > Everything else still stands: > >> Testing: Linux x86_64/release hotspot/test/compiler, includes new tests >> >> I need a sponsor. I think this bugfix is too important to miss 9, and it even >> deserves backporting to 8u. > > -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 lutz.schmidt at sap.com Tue Feb 28 14:27:44 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 28 Feb 2017 14:27:44 +0000 Subject: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C In-Reply-To: <5e2830119227429b9e6a37ab4d3e6d35@sap.com> References: <63ff237e-2682-d91a-85f2-67e7a008d9ea@oracle.com> <5e2830119227429b9e6a37ab4d3e6d35@sap.com> Message-ID: <91A198C0-58B3-49B8-9E1E-734AA9129E7E@sap.com> Hi Martin, Thank you for reviewing and for your suggestions. I have reworked my changes to reflect your improvements. A new webrev can be found here: http://cr.openjdk.java.net/~lucy/webrevs/8175368.01/ The lookup tables in stubRoutines_s390.cpp have been verified by calculating CRC32C values for various byte streams with and without using the tables. Because the tables are auto-generated, it is very unlikely that just a few individual table elements are incorrect. Best regards, Lutz On 28.02.17, 11:57, "Doerr, Martin" wrote: Hi Lutz, thank you very much for implementing it. It looks good. I especially like that you share a lot of the code between CRC32 and CRC32C. I only have some minor suggestions: c1_LIRGenerator_s390.cpp load_int_as_long was implemented for stubs which expect sign (or zero) extended integer parameters. As C2 was changed to no longer perform int to long conversions for stub calls, I think this should better be removed from C1, too. The stubs are shared between C1 and C2 and they don't need conversions anymore, so I'd appreciate if the load_int_as_long got removed completely. macroAssembler_s390.cpp The function update_1word_crc32 uses separate load and xor instructions. I think some of them should get combined by using xor register,mem. stubGenerator_s390.cpp The comment in generate_CRC32_updateBytes should be: "must be same register as in generate..." stubRoutines_s390.cpp I didn't review all numbers :-), but I guess you have tested well enough? It'd be nice if you could share some performance numbers. Thanks and best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz Sent: Montag, 27. Februar 2017 22:33 To: Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C Thank you, Vladimir, for looking at this. Regards, Lutz On 27.02.17, 22:30, "Vladimir Kozlov" wrote: Shared changes are good. I assume s390 code will be reviewed by experts. Thanks, Vladimir On 2/27/17 9:34 AM, Schmidt, Lutz wrote: > Hi all, > > > > the webrev URL below was incorrect. It displayed the correct location, > but pointed elsewhere. The issue is fixed now and the URLs are correct. > > > > Thank you! > > Lutz > > > > *From: *Lutz Schmidt > *Date: *Montag, 27. Februar 2017 um 15:55 > *To: *"hotspot-compiler-dev at openjdk.java.net" > > *Subject: *RFR (M) 8175368: [s390] Provide intrinsic implementation for > CRC32C > > > > Hi all, > > > > may I kindly request reviews for my medium enhancement? Further down the > road, I would need a sponsor, too. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175368 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175368/ > > > > Description: > > This intrinsic implementation provides some performance benefit over the > standard Java implementation. It uses only well-known ?standard? > instructions, available on all supported IBM System z hardware. Being > very similar to the CRC32 intrinsics, it was tried to share as much code > as possible between these two. > > > > Performance may be expected to increase up to 2.0x, compared to a run > with ?XX:-UseCRC32CIntrinsics. Actual speedup depends on the length of > the byte array fed into CRC32C and, to some extent, on the H/W > generation the test runs on. > > > > Thanks, > > Lutz > > > From vladimir.x.ivanov at oracle.com Tue Feb 28 15:28:08 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Feb 2017 18:28:08 +0300 Subject: RFR (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> Message-ID: <34ab3925-b838-703e-447b-3aa03d7ece94@oracle.com> Thanks for the fix, Aleksey. > Updated after off-list review (renamed tests, used internal Unsafe): > http://cr.openjdk.java.net/~shade/8175887/webrev.02/ I'm fine with the fix in do_UnsafeGetObject. Changes in do_UnsafeGetRaw don't make much sense to me. Following the reasoning in the comment ("better be safe than sorry") you have to unconditionally kill memory for UnsafeGetObject as well :-) If there's a need in ordering raw loads, I'd prefer to see a dedicated flag (like UnsafeObjectOp::_is_volatile) introduced instead. Right now, UnsafeGetRaw usage is very limited (only for restoring frame state in OSR entry), so I don't see any reason in doing that. So, please, leave it as is. Best regards, Vladimir Ivanov > Everything else still stands: > >> Testing: Linux x86_64/release hotspot/test/compiler, includes new tests >> >> I need a sponsor. I think this bugfix is too important to miss 9, and it even >> deserves backporting to 8u. From shade at redhat.com Tue Feb 28 15:36:04 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 Feb 2017 16:36:04 +0100 Subject: RFR (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: <34ab3925-b838-703e-447b-3aa03d7ece94@oracle.com> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> <34ab3925-b838-703e-447b-3aa03d7ece94@oracle.com> Message-ID: <8a4ce928-a260-0b16-0d9a-c9d3dfabff03@redhat.com> On 02/28/2017 04:28 PM, Vladimir Ivanov wrote: > Thanks for the fix, Aleksey. > >> Updated after off-list review (renamed tests, used internal Unsafe): >> http://cr.openjdk.java.net/~shade/8175887/webrev.02/ > > I'm fine with the fix in do_UnsafeGetObject. > > Changes in do_UnsafeGetRaw don't make much sense to me. Following the reasoning > in the comment ("better be safe than sorry") you have to > unconditionally kill memory for UnsafeGetObject as well :-) > > If there's a need in ordering raw loads, I'd prefer to see a dedicated flag > (like UnsafeObjectOp::_is_volatile) introduced instead. > Right now, UnsafeGetRaw usage is very limited (only for restoring frame state in > OSR entry), so I don't see any reason in doing that. > > So, please, leave it as is. All right, fine: http://cr.openjdk.java.net/~shade/8175887/webrev.03/ -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From martin.doerr at sap.com Tue Feb 28 16:07:52 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 28 Feb 2017 16:07:52 +0000 Subject: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C In-Reply-To: <91A198C0-58B3-49B8-9E1E-734AA9129E7E@sap.com> References: <63ff237e-2682-d91a-85f2-67e7a008d9ea@oracle.com> <5e2830119227429b9e6a37ab4d3e6d35@sap.com> <91A198C0-58B3-49B8-9E1E-734AA9129E7E@sap.com> Message-ID: <37470f1c5ee14fcdaeab40dff379efa1@sap.com> Hi Lutz, thanks for implementing my suggestions and for the explanations. The change looks good to me. Best regards, Martin -----Original Message----- From: Schmidt, Lutz Sent: Dienstag, 28. Februar 2017 15:28 To: Doerr, Martin ; Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C Hi Martin, Thank you for reviewing and for your suggestions. I have reworked my changes to reflect your improvements. A new webrev can be found here: http://cr.openjdk.java.net/~lucy/webrevs/8175368.01/ The lookup tables in stubRoutines_s390.cpp have been verified by calculating CRC32C values for various byte streams with and without using the tables. Because the tables are auto-generated, it is very unlikely that just a few individual table elements are incorrect. Best regards, Lutz On 28.02.17, 11:57, "Doerr, Martin" wrote: Hi Lutz, thank you very much for implementing it. It looks good. I especially like that you share a lot of the code between CRC32 and CRC32C. I only have some minor suggestions: c1_LIRGenerator_s390.cpp load_int_as_long was implemented for stubs which expect sign (or zero) extended integer parameters. As C2 was changed to no longer perform int to long conversions for stub calls, I think this should better be removed from C1, too. The stubs are shared between C1 and C2 and they don't need conversions anymore, so I'd appreciate if the load_int_as_long got removed completely. macroAssembler_s390.cpp The function update_1word_crc32 uses separate load and xor instructions. I think some of them should get combined by using xor register,mem. stubGenerator_s390.cpp The comment in generate_CRC32_updateBytes should be: "must be same register as in generate..." stubRoutines_s390.cpp I didn't review all numbers :-), but I guess you have tested well enough? It'd be nice if you could share some performance numbers. Thanks and best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz Sent: Montag, 27. Februar 2017 22:33 To: Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (M) 8175368: [s390] Provide intrinsic implementation for CRC32C Thank you, Vladimir, for looking at this. Regards, Lutz On 27.02.17, 22:30, "Vladimir Kozlov" wrote: Shared changes are good. I assume s390 code will be reviewed by experts. Thanks, Vladimir On 2/27/17 9:34 AM, Schmidt, Lutz wrote: > Hi all, > > > > the webrev URL below was incorrect. It displayed the correct location, > but pointed elsewhere. The issue is fixed now and the URLs are correct. > > > > Thank you! > > Lutz > > > > *From: *Lutz Schmidt > *Date: *Montag, 27. Februar 2017 um 15:55 > *To: *"hotspot-compiler-dev at openjdk.java.net" > > *Subject: *RFR (M) 8175368: [s390] Provide intrinsic implementation for > CRC32C > > > > Hi all, > > > > may I kindly request reviews for my medium enhancement? Further down the > road, I would need a sponsor, too. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175368 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8175368/ > > > > Description: > > This intrinsic implementation provides some performance benefit over the > standard Java implementation. It uses only well-known ?standard? > instructions, available on all supported IBM System z hardware. Being > very similar to the CRC32 intrinsics, it was tried to share as much code > as possible between these two. > > > > Performance may be expected to increase up to 2.0x, compared to a run > with ?XX:-UseCRC32CIntrinsics. Actual speedup depends on the length of > the byte array fed into CRC32C and, to some extent, on the H/W > generation the test runs on. > > > > Thanks, > > Lutz > > > From vladimir.x.ivanov at oracle.com Tue Feb 28 16:42:10 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Feb 2017 19:42:10 +0300 Subject: RFR (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: <8a4ce928-a260-0b16-0d9a-c9d3dfabff03@redhat.com> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> <34ab3925-b838-703e-447b-3aa03d7ece94@oracle.com> <8a4ce928-a260-0b16-0d9a-c9d3dfabff03@redhat.com> Message-ID: <1dc5e254-d1c7-3ef9-1eb5-9236c9b51777@oracle.com> > All right, fine: > http://cr.openjdk.java.net/~shade/8175887/webrev.03/ Thanks, looks good. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Tue Feb 28 19:06:21 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Feb 2017 22:06:21 +0300 Subject: RFR (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: <1dc5e254-d1c7-3ef9-1eb5-9236c9b51777@oracle.com> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> <34ab3925-b838-703e-447b-3aa03d7ece94@oracle.com> <8a4ce928-a260-0b16-0d9a-c9d3dfabff03@redhat.com> <1dc5e254-d1c7-3ef9-1eb5-9236c9b51777@oracle.com> Message-ID: <795c55a9-e5b5-d423-c1be-abef5d2338b0@oracle.com> On 2/28/17 7:42 PM, Vladimir Ivanov wrote: >> All right, fine: >> http://cr.openjdk.java.net/~shade/8175887/webrev.03/ > > Thanks, looks good. FYI spotted a couple of issues in the tests. Once the testing is over I plan to push the following version (w/ some cleanups): http://cr.openjdk.java.net/~vlivanov/shade/8175887/ Best regards, Vladimir Ivanov From shade at redhat.com Tue Feb 28 19:08:59 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 Feb 2017 20:08:59 +0100 Subject: RFR (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: <795c55a9-e5b5-d423-c1be-abef5d2338b0@oracle.com> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> <34ab3925-b838-703e-447b-3aa03d7ece94@oracle.com> <8a4ce928-a260-0b16-0d9a-c9d3dfabff03@redhat.com> <1dc5e254-d1c7-3ef9-1eb5-9236c9b51777@oracle.com> <795c55a9-e5b5-d423-c1be-abef5d2338b0@oracle.com> Message-ID: <871d76fc-f9b1-e1b9-095b-573e0da694a7@redhat.com> On 02/28/2017 08:06 PM, Vladimir Ivanov wrote: > On 2/28/17 7:42 PM, Vladimir Ivanov wrote: >>> All right, fine: >>> http://cr.openjdk.java.net/~shade/8175887/webrev.03/ >> >> Thanks, looks good. > > FYI spotted a couple of issues in the tests. Once the testing is over I plan to > push the following version (w/ some cleanups): > http://cr.openjdk.java.net/~vlivanov/shade/8175887/ The cleanup look good, but are you sure AssertionError would get reported from the thread, and it would not silently die? The original test exited hard to handle this. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vladimir.x.ivanov at oracle.com Tue Feb 28 21:01:00 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 1 Mar 2017 00:01:00 +0300 Subject: RFR (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: <871d76fc-f9b1-e1b9-095b-573e0da694a7@redhat.com> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> <34ab3925-b838-703e-447b-3aa03d7ece94@oracle.com> <8a4ce928-a260-0b16-0d9a-c9d3dfabff03@redhat.com> <1dc5e254-d1c7-3ef9-1eb5-9236c9b51777@oracle.com> <795c55a9-e5b5-d423-c1be-abef5d2338b0@oracle.com> <871d76fc-f9b1-e1b9-095b-573e0da694a7@redhat.com> Message-ID: <385ce51d-c43b-8e8c-3db1-d26c25010589@oracle.com> >> http://cr.openjdk.java.net/~vlivanov/shade/8175887/ > > The cleanup look good, but are you sure AssertionError would get reported from > the thread, and it would not silently die? The original test exited hard to > handle this. Good point. Reverted that part. (Updated the webrev in place.) Best regards, Vladimir Ivanov From shade at redhat.com Tue Feb 28 21:01:55 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 Feb 2017 22:01:55 +0100 Subject: RFR (S) 8175887: C1 value numbering handling of Unsafe.get*Volatile is incorrect In-Reply-To: <385ce51d-c43b-8e8c-3db1-d26c25010589@oracle.com> References: <58fe8377-ee6d-9c80-2254-944e7b8f5ffc@redhat.com> <34ab3925-b838-703e-447b-3aa03d7ece94@oracle.com> <8a4ce928-a260-0b16-0d9a-c9d3dfabff03@redhat.com> <1dc5e254-d1c7-3ef9-1eb5-9236c9b51777@oracle.com> <795c55a9-e5b5-d423-c1be-abef5d2338b0@oracle.com> <871d76fc-f9b1-e1b9-095b-573e0da694a7@redhat.com> <385ce51d-c43b-8e8c-3db1-d26c25010589@oracle.com> Message-ID: <8ce63447-0a60-51b9-5a91-918fb58dd806@redhat.com> On 02/28/2017 10:01 PM, Vladimir Ivanov wrote: > >>> http://cr.openjdk.java.net/~vlivanov/shade/8175887/ >> >> The cleanup look good, but are you sure AssertionError would get reported from >> the thread, and it would not silently die? The original test exited hard to >> handle this. > > Good point. Reverted that part. (Updated the webrev in place.) Thumbs up. Thanks for handling this! -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: