From david.buck at oracle.com Tue Aug 1 12:32:01 2017 From: david.buck at oracle.com (David Buck) Date: Tue, 1 Aug 2017 21:32:01 +0900 Subject: RFR(XS): 8185567: fix hsdis cpu to architecture mapping on various Linux platforms In-Reply-To: References: Message-ID: Hi! It was suggested that I also loop in build-dev to the review of this proposed change. Cheers, -Buck On 2017/07/31 22:06, David Buck wrote: > Hi! > > Would you please review this small set of very simple build fixes to hsdis? > > bug report: https://bugs.openjdk.java.net/browse/JDK-8185567 > > proposed fix: http://cr.openjdk.java.net/~dbuck/8185567.0/ > > With these changes, hsdis should now correctly build out of the box (no > manual editing of files needed) on Linux with any of the following > return values of "uname -m": > > i386 > i686 > amd64 > x86_64 > *arm* > aarch64 > > I made it a point to *not* break anything that previously worked. So, > for example, aarch64 environments will still compile for aarch64 even > when the build target is "all" and not "all64". While forcing it to try > and build a 32-bit binary would be more consistent with what happens > with "make all" on linux-amd64 or solaris-sparcv9, I decided to leave > things as they are in case any aarch64 users depend on the current > behavior. Similarly, an attempt to run "make all" on linux-sparcv9 will > continue to try and build against whatever the return value of "uname > -m" was. Of course running "make all64" now does the right thing and > targets "sparcv9". > > Cheers, > -Buck > > From david.holmes at oracle.com Tue Aug 1 12:36:59 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Aug 2017 22:36:59 +1000 Subject: RFR(XS): 8185567: fix hsdis cpu to architecture mapping on various Linux platforms In-Reply-To: References: Message-ID: Hi Buck, On 1/08/2017 10:32 PM, David Buck wrote: > Hi! > > It was suggested that I also loop in build-dev to the review of this > proposed change. Thanks for that. As I said in other email the changes seem reasonable, but the arm support seems to be for a native arm build whereas we use cross-compilation for ARM in the main build. For that matter the arm64 port also uses cross-compilation. Cheers, David > Cheers, > -Buck > > On 2017/07/31 22:06, David Buck wrote: >> Hi! >> >> Would you please review this small set of very simple build fixes to >> hsdis? >> >> bug report: https://bugs.openjdk.java.net/browse/JDK-8185567 >> >> proposed fix: http://cr.openjdk.java.net/~dbuck/8185567.0/ >> >> With these changes, hsdis should now correctly build out of the box >> (no manual editing of files needed) on Linux with any of the following >> return values of "uname -m": >> >> i386 >> i686 >> amd64 >> x86_64 >> *arm* >> aarch64 >> >> I made it a point to *not* break anything that previously worked. So, >> for example, aarch64 environments will still compile for aarch64 even >> when the build target is "all" and not "all64". While forcing it to >> try and build a 32-bit binary would be more consistent with what >> happens with "make all" on linux-amd64 or solaris-sparcv9, I decided >> to leave things as they are in case any aarch64 users depend on the >> current behavior. Similarly, an attempt to run "make all" on >> linux-sparcv9 will continue to try and build against whatever the >> return value of "uname -m" was. Of course running "make all64" now >> does the right thing and targets "sparcv9". >> >> Cheers, >> -Buck >> >> From goetz.lindenmaier at sap.com Tue Aug 1 12:58:34 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Aug 2017 12:58:34 +0000 Subject: RFR(M) 8180823: [s390] Rework/optimize AES intrinsics In-Reply-To: References: <6E7AAFCF-5299-45BD-942A-61C5CDDCD873@sap.com> <1172fad27aab4336b32c8642a76e17a3@sap.com> Message-ID: Hi Lutz, I had a look at your change. It looks good. I ran the aes jtreg tests on it which passed. I?m not completely happy with the error message in vm_version, as it differs from that on x86 with the same flag settings. I think similar behavior of the platforms is desirable. But the string seems not to be tested, thus does no harm to the tests. Best regards, Goetz. From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz Sent: Montag, 31. Juli 2017 17:43 To: Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(M) 8180823: [s390] Rework/optimize AES intrinsics Hi Martin, Thanks for the review. Please find my comments re. your findings below, marked with ?>>>?. The changes are reflected in a new webrev iteration at http://cr.openjdk.java.net/~lucy/webrevs/8180823.01/ Regards, Lutz On 31.07.2017, 15:28, "Doerr, Martin" > wrote: Hi Lutz, nice change. Thanks for also fixing the stack pointer update order (missing part of 8180659). I didn?t find real bugs, but I?d like to get at least some comments fixed. * The comment in front of generate_push_Block mentions a ?JIT_TIMER? timer which you didn?t contribute. >>> You are right. JIT_TIMER is a SAP internal tool. Comment removed. * The comments describing the stack layout claim that there were requirements ?min. size AES_parmBlk_addspace? and ?Z_SP after expansion, octoword-aligned?. I think neither the minimal size nor the octoword alignment of the SP are required, so please remove these comments if this is correct. I believe that only the parmBlk needs the alignment. >>> Comments are fixed. * The stack reservation is a little oversized. Maximum space used by alignment is AES_parmBlk_align-8. Please fix at least the comment. The spill space is also oversized (only 2 slots are used). I leave it up to you if you want to reduce stack space reservation. As this frame is only on top while processing AES stuff, it?s not really an issue to waste a few bytes. >>> Add?l (spill) space requirement is adapted (3*8 bytes). I would like to keep the alignment stuff ?as is?. * generate_AES_cipherBlock contains an unnecessary rotate_then_insert instruction which seems to be a leftover from some removed functionality. >>> removed. Was a JIT_TIMER leftover which wasn?t correctly annotated. I can also sponsor this change after we go a 2nd review. Best regards, Martin From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz Sent: Freitag, 28. Juli 2017 13:06 To: hotspot-compiler-dev at openjdk.java.net Subject: RFR(M) 8180823: [s390] Rework/optimize AES intrinsics Dear all, I would like to request reviews for this s390-only enhancement: Bug: https://bugs.openjdk.java.net/browse/JDK-8180823 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8180823.00/ The code for AES intrinsics in stubGenerator_s390.cpp is reworked to get rid of multiple copies of basically the same code snippets. Some chances for minor performance improvements are also taken advantage of. The code has been active locally @SAP for several weeks now. No problems popped up. Thank you! Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutz.schmidt at sap.com Tue Aug 1 13:05:40 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 1 Aug 2017 13:05:40 +0000 Subject: RFR(M) 8180823: [s390] Rework/optimize AES intrinsics In-Reply-To: References: <6E7AAFCF-5299-45BD-942A-61C5CDDCD873@sap.com> <1172fad27aab4336b32c8642a76e17a3@sap.com> Message-ID: <3F71472A-7F9F-4E4F-B1E9-6AE2FBEAEEB1@sap.com> Thanks, Goetz, for having a look. Regards, Lutz On 01.08.2017, 14:58, "Lindenmaier, Goetz" > wrote: Hi Lutz, I had a look at your change. It looks good. I ran the aes jtreg tests on it which passed. I?m not completely happy with the error message in vm_version, as it differs from that on x86 with the same flag settings. I think similar behavior of the platforms is desirable. But the string seems not to be tested, thus does no harm to the tests. Best regards, Goetz. From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz Sent: Montag, 31. Juli 2017 17:43 To: Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(M) 8180823: [s390] Rework/optimize AES intrinsics Hi Martin, Thanks for the review. Please find my comments re. your findings below, marked with ?>>>?. The changes are reflected in a new webrev iteration at http://cr.openjdk.java.net/~lucy/webrevs/8180823.01/ Regards, Lutz On 31.07.2017, 15:28, "Doerr, Martin" > wrote: Hi Lutz, nice change. Thanks for also fixing the stack pointer update order (missing part of 8180659). I didn?t find real bugs, but I?d like to get at least some comments fixed. * The comment in front of generate_push_Block mentions a ?JIT_TIMER? timer which you didn?t contribute. >>> You are right. JIT_TIMER is a SAP internal tool. Comment removed. * The comments describing the stack layout claim that there were requirements ?min. size AES_parmBlk_addspace? and ?Z_SP after expansion, octoword-aligned?. I think neither the minimal size nor the octoword alignment of the SP are required, so please remove these comments if this is correct. I believe that only the parmBlk needs the alignment. >>> Comments are fixed. * The stack reservation is a little oversized. Maximum space used by alignment is AES_parmBlk_align-8. Please fix at least the comment. The spill space is also oversized (only 2 slots are used). I leave it up to you if you want to reduce stack space reservation. As this frame is only on top while processing AES stuff, it?s not really an issue to waste a few bytes. >>> Add?l (spill) space requirement is adapted (3*8 bytes). I would like to keep the alignment stuff ?as is?. * generate_AES_cipherBlock contains an unnecessary rotate_then_insert instruction which seems to be a leftover from some removed functionality. >>> removed. Was a JIT_TIMER leftover which wasn?t correctly annotated. I can also sponsor this change after we go a 2nd review. Best regards, Martin From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz Sent: Freitag, 28. Juli 2017 13:06 To: hotspot-compiler-dev at openjdk.java.net Subject: RFR(M) 8180823: [s390] Rework/optimize AES intrinsics Dear all, I would like to request reviews for this s390-only enhancement: Bug: https://bugs.openjdk.java.net/browse/JDK-8180823 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8180823.00/ The code for AES intrinsics in stubGenerator_s390.cpp is reworked to get rid of multiple copies of basically the same code snippets. Some chances for minor performance improvements are also taken advantage of. The code has been active locally @SAP for several weeks now. No problems popped up. Thank you! Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Tue Aug 1 13:12:38 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 1 Aug 2017 13:12:38 +0000 Subject: RFR(M) 8180823: [s390] Rework/optimize AES intrinsics In-Reply-To: <3F71472A-7F9F-4E4F-B1E9-6AE2FBEAEEB1@sap.com> References: <6E7AAFCF-5299-45BD-942A-61C5CDDCD873@sap.com> <1172fad27aab4336b32c8642a76e17a3@sap.com> <3F71472A-7F9F-4E4F-B1E9-6AE2FBEAEEB1@sap.com> Message-ID: <6ef88bfee310459483f89c1267944729@sap.com> Pushed with adapted error message and updated copyright. Best regards, Martin From: Schmidt, Lutz Sent: Dienstag, 1. August 2017 15:06 To: Lindenmaier, Goetz ; Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(M) 8180823: [s390] Rework/optimize AES intrinsics Thanks, Goetz, for having a look. Regards, Lutz On 01.08.2017, 14:58, "Lindenmaier, Goetz" > wrote: Hi Lutz, I had a look at your change. It looks good. I ran the aes jtreg tests on it which passed. I?m not completely happy with the error message in vm_version, as it differs from that on x86 with the same flag settings. I think similar behavior of the platforms is desirable. But the string seems not to be tested, thus does no harm to the tests. Best regards, Goetz. From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz Sent: Montag, 31. Juli 2017 17:43 To: Doerr, Martin >; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(M) 8180823: [s390] Rework/optimize AES intrinsics Hi Martin, Thanks for the review. Please find my comments re. your findings below, marked with ?>>>?. The changes are reflected in a new webrev iteration at http://cr.openjdk.java.net/~lucy/webrevs/8180823.01/ Regards, Lutz On 31.07.2017, 15:28, "Doerr, Martin" > wrote: Hi Lutz, nice change. Thanks for also fixing the stack pointer update order (missing part of 8180659). I didn?t find real bugs, but I?d like to get at least some comments fixed. * The comment in front of generate_push_Block mentions a ?JIT_TIMER? timer which you didn?t contribute. >>> You are right. JIT_TIMER is a SAP internal tool. Comment removed. * The comments describing the stack layout claim that there were requirements ?min. size AES_parmBlk_addspace? and ?Z_SP after expansion, octoword-aligned?. I think neither the minimal size nor the octoword alignment of the SP are required, so please remove these comments if this is correct. I believe that only the parmBlk needs the alignment. >>> Comments are fixed. * The stack reservation is a little oversized. Maximum space used by alignment is AES_parmBlk_align-8. Please fix at least the comment. The spill space is also oversized (only 2 slots are used). I leave it up to you if you want to reduce stack space reservation. As this frame is only on top while processing AES stuff, it?s not really an issue to waste a few bytes. >>> Add?l (spill) space requirement is adapted (3*8 bytes). I would like to keep the alignment stuff ?as is?. * generate_AES_cipherBlock contains an unnecessary rotate_then_insert instruction which seems to be a leftover from some removed functionality. >>> removed. Was a JIT_TIMER leftover which wasn?t correctly annotated. I can also sponsor this change after we go a 2nd review. Best regards, Martin From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz Sent: Freitag, 28. Juli 2017 13:06 To: hotspot-compiler-dev at openjdk.java.net Subject: RFR(M) 8180823: [s390] Rework/optimize AES intrinsics Dear all, I would like to request reviews for this s390-only enhancement: Bug: https://bugs.openjdk.java.net/browse/JDK-8180823 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8180823.00/ The code for AES intrinsics in stubGenerator_s390.cpp is reworked to get rid of multiple copies of basically the same code snippets. Some chances for minor performance improvements are also taken advantage of. The code has been active locally @SAP for several weeks now. No problems popped up. Thank you! Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Aug 1 15:51:19 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 1 Aug 2017 08:51:19 -0700 Subject: RFR(S) : 8185536 : @key aot should be replaced w/ @requires vm.aot Message-ID: http://cr.openjdk.java.net/~iignatyev//8185536/webrev.00/index.html > 81 lines changed: 19 ins; 0 del; 62 mod Hi all, could you please review this small patch which introduces 'vm.aot' property into jtreg @requires context and replaces all '@key aot' added by 8185046[1] w/ '@requiers vm.aot'? Goetz(author of 8185046) is checking that it works for their configurations. JBS: https://bugs.openjdk.java.net/browse/JDK-8185536 webrev: http://cr.openjdk.java.net/~iignatyev//8185536/webrev.00/index.html testing: hotspot/test/compiler/aot tests - on linux-x64 : 56 tests selected/run - on linux-x86 : 0 tests selected/run - on windows-x64 (after remove tests from problemlist) : 56 tests selected/run - on windows-x86 (after remove tests from problemlist) : 0 tests selected/run [1] https://bugs.openjdk.java.net/browse/JDK-8185046 Thanks, -- Igor From vladimir.kozlov at oracle.com Tue Aug 1 20:33:18 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 1 Aug 2017 13:33:18 -0700 Subject: RFR(S) : 8185536 : @key aot should be replaced w/ @requires vm.aot In-Reply-To: References: Message-ID: Looks good. Thanks, Vladimir On 8/1/17 8:51 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8185536/webrev.00/index.html >> 81 lines changed: 19 ins; 0 del; 62 mod > > Hi all, > > could you please review this small patch which introduces 'vm.aot' property into jtreg @requires context and replaces all '@key aot' added by 8185046[1] w/ '@requiers vm.aot'? > Goetz(author of 8185046) is checking that it works for their configurations. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185536 > webrev: http://cr.openjdk.java.net/~iignatyev//8185536/webrev.00/index.html > testing: hotspot/test/compiler/aot tests > - on linux-x64 : 56 tests selected/run > - on linux-x86 : 0 tests selected/run > - on windows-x64 (after remove tests from problemlist) : 56 tests selected/run > - on windows-x86 (after remove tests from problemlist) : 0 tests selected/run > > [1] https://bugs.openjdk.java.net/browse/JDK-8185046 > > Thanks, > -- Igor > From mandy.chung at oracle.com Wed Aug 2 05:31:58 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 1 Aug 2017 22:31:58 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <4506356.BY5Vv2ZSov@logoutik> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <70D79D86-E20A-4D7B-9EF3-04DD0C3FA2A4@oracle.com> <4506356.BY5Vv2ZSov@logoutik> Message-ID: <92954922-7C4F-4B33-BC8B-DC5FC7D3F1FA@oracle.com> > On Jul 27, 2017, at 2:07 AM, Jaroslav Tulach wrote: > >> One consideration might be to separate the JVMCI MBean provider in its own >> module so that it?s registered only when such module is resolved in the >> module graph. This way JVMCI can work even if java.management is not >> present. > > Yes, I can create something like jdk.internal.vm.ci.management and move the > JVMCIMXBeans.java (to be renamed to JVMCIMBeans.java per Vladimir's > suggestion, if I remember correctly) there. This module would have dependency > on jdk.internal.vm.ci and java.management and bridge them together. > > How do I make sure this module is enabled when possible? Or is that automatic? > Service binding will resolve a service provider module during resolution. In other words, if java.management is in the resolved graph, any modules providing the services it uses will be added to the graph. >>>> Is the MBean in jdk.internal.vm.compiler or in Lab?s Graal compiler? >>> >>> Anything in Lab?s Graal compiler is destined for JDK Graal so the >>> distinction is only temporary at best. >> Good to know. > > The bean is in there and implements DynamicMBean interface. E.g. this part of > Graal compiler module has to have dependency on java.management - that means > to make that dependency optional or split the module in two, I assume. This is Graal-specific MBean. It doesn?t seem that it must be registered as ?platform mbean? which has to implement PlatformManagedObject. Graal can register the MBean at runtime when java.management is present by calling ManagementFactory.getPlatformMBeanServer().registerMBean method. That seems to be a better alternative. Separating the MBean in a different module would still be applicable. Mandy From goetz.lindenmaier at sap.com Wed Aug 2 12:49:36 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Aug 2017 12:49:36 +0000 Subject: RFR(S) : 8185536 : @key aot should be replaced w/ @requires vm.aot In-Reply-To: References: Message-ID: <80032ee276ee4224b0979e90fd29eb41@sap.com> Hi Igor, the change is looking good. A small thing, I would spell vmAot() as vmAOT(), all abbreviations (except for Jvmci) are capitalized here. It passed the tests on all platforms that have been running so far. (Some had an unrelated issue tonight). Best regards, Goetz. > -----Original Message----- > From: Igor Ignatyev [mailto:igor.ignatyev at oracle.com] > Sent: Dienstag, 1. August 2017 17:51 > To: hotspot-compiler-dev at openjdk.java.net compiler dev at openjdk.java.net> > Cc: Lindenmaier, Goetz > Subject: RFR(S) : 8185536 : @key aot should be replaced w/ @requires > vm.aot > > http://cr.openjdk.java.net/~iignatyev//8185536/webrev.00/index.html > > 81 lines changed: 19 ins; 0 del; 62 mod > > Hi all, > > could you please review this small patch which introduces 'vm.aot' property > into jtreg @requires context and replaces all '@key aot' added by 8185046[1] > w/ '@requiers vm.aot'? > Goetz(author of 8185046) is checking that it works for their configurations. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185536 > webrev: > http://cr.openjdk.java.net/~iignatyev//8185536/webrev.00/index.html > testing: hotspot/test/compiler/aot tests > - on linux-x64 : 56 tests selected/run > - on linux-x86 : 0 tests selected/run > - on windows-x64 (after remove tests from problemlist) : 56 tests > selected/run > - on windows-x86 (after remove tests from problemlist) : 0 tests > selected/run > > [1] https://bugs.openjdk.java.net/browse/JDK-8185046 > > Thanks, > -- Igor From mandy.chung at oracle.com Wed Aug 2 14:37:54 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Aug 2017 07:37:54 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <3097604.jcdSgtZXxL@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <4506356.BY5Vv2ZSov@logoutik> <92954922-7C4F-4B33-BC8B-DC5FC7D3F1FA@oracle.com> <3097604.jcdSgtZXxL@pracovni> Message-ID: > On Aug 2, 2017, at 7:08 AM, Jaroslav Tulach wrote: > >> This is Graal-specific MBean. It doesn?t seem that it must be registered as >> ?platform mbean? which has to implement PlatformManagedObject. >> >> Graal can register the MBean at runtime when java.management is present by >> calling ManagementFactory.getPlatformMBeanServer().registerMBean method. >> That seems to be a better alternative. Separating the MBean in a different >> module would still be applicable. > > This is not possible to do cleanly. When shall Graal register the bean? On > first compilation? Then it may enable the whole ManagementFactory > infrastructure too early and influence results of regular Java programs. > > We have seen a benchmark failure due to registering the Graal bean too early. > The bean registration triggered the java.util.logging infrastructure on and as > a result the benchmarking test failed. > > The test tried to set "java.util.logging.config.file" property and then it > assumed it will be used on subsequent call to Logger.getLogger(...). But the > property was ignored as the Logger was already initialized. > > I believe that exactly for this reason there is the PlatformManagedObject & > co. infrastructure. To not trigger the management infrastructure on > prematurely. All the HotSpot beans are registered "lazily". As part of > internal JDK infrastructure we believe Graal should have a way to be part of > such "lazy initialization" too. > > I hope the need for the requested functionality is now clearer. As described in the previous mail, the current way to register a platform MBean is to have a provider module that provides sun.management.spi.PlatformMBeanProvider. The provider module will get resolved during service binding. jdk.management is one example. Mandy From igor.ignatyev at oracle.com Wed Aug 2 17:53:52 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 2 Aug 2017 10:53:52 -0700 Subject: RFR(S) : 8185536 : @key aot should be replaced w/ @requires vm.aot In-Reply-To: <80032ee276ee4224b0979e90fd29eb41@sap.com> References: <80032ee276ee4224b0979e90fd29eb41@sap.com> Message-ID: <774D7CF2-5F36-4271-A234-A2F7154EBA4F@oracle.com> Vladimir, Goetz, thank you for your review. Although abbreviations should not be upper-cased in method names, I've renamed vmAot to vmAOT to be consistent w/ the rest of the class. -- Igor > On Aug 2, 2017, at 5:49 AM, Lindenmaier, Goetz wrote: > > Hi Igor, > > the change is looking good. > > A small thing, I would spell vmAot() as vmAOT(), all abbreviations > (except for Jvmci) are capitalized here. > > It passed the tests on all platforms that have been running so far. > (Some had an unrelated issue tonight). > > Best regards, > Goetz. > >> -----Original Message----- >> From: Igor Ignatyev [mailto:igor.ignatyev at oracle.com] >> Sent: Dienstag, 1. August 2017 17:51 >> To: hotspot-compiler-dev at openjdk.java.net compiler > dev at openjdk.java.net> >> Cc: Lindenmaier, Goetz >> Subject: RFR(S) : 8185536 : @key aot should be replaced w/ @requires >> vm.aot >> >> http://cr.openjdk.java.net/~iignatyev//8185536/webrev.00/index.html >>> 81 lines changed: 19 ins; 0 del; 62 mod >> >> Hi all, >> >> could you please review this small patch which introduces 'vm.aot' property >> into jtreg @requires context and replaces all '@key aot' added by 8185046[1] >> w/ '@requiers vm.aot'? >> Goetz(author of 8185046) is checking that it works for their configurations. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8185536 >> webrev: >> http://cr.openjdk.java.net/~iignatyev//8185536/webrev.00/index.html >> testing: hotspot/test/compiler/aot tests >> - on linux-x64 : 56 tests selected/run >> - on linux-x86 : 0 tests selected/run >> - on windows-x64 (after remove tests from problemlist) : 56 tests >> selected/run >> - on windows-x86 (after remove tests from problemlist) : 0 tests >> selected/run >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8185046 >> >> Thanks, >> -- Igor From vladimir.kozlov at oracle.com Wed Aug 2 18:02:18 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 2 Aug 2017 11:02:18 -0700 Subject: RFR(S) : 8185536 : @key aot should be replaced w/ @requires vm.aot In-Reply-To: <774D7CF2-5F36-4271-A234-A2F7154EBA4F@oracle.com> References: <80032ee276ee4224b0979e90fd29eb41@sap.com> <774D7CF2-5F36-4271-A234-A2F7154EBA4F@oracle.com> Message-ID: <1E212A52-C426-4FEA-BD0D-63485A0EFEFD@oracle.com> Okay. Thanks Vladimir Sent from my iPhone > On Aug 2, 2017, at 10:53 AM, Igor Ignatyev wrote: > > Vladimir, Goetz, > > thank you for your review. Although abbreviations should not be upper-cased in method names, I've renamed vmAot to vmAOT to be consistent w/ the rest of the class. > > -- Igor > >> On Aug 2, 2017, at 5:49 AM, Lindenmaier, Goetz wrote: >> >> Hi Igor, >> >> the change is looking good. >> >> A small thing, I would spell vmAot() as vmAOT(), all abbreviations >> (except for Jvmci) are capitalized here. >> >> It passed the tests on all platforms that have been running so far. >> (Some had an unrelated issue tonight). >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: Igor Ignatyev [mailto:igor.ignatyev at oracle.com] >>> Sent: Dienstag, 1. August 2017 17:51 >>> To: hotspot-compiler-dev at openjdk.java.net compiler >> dev at openjdk.java.net> >>> Cc: Lindenmaier, Goetz >>> Subject: RFR(S) : 8185536 : @key aot should be replaced w/ @requires >>> vm.aot >>> >>> http://cr.openjdk.java.net/~iignatyev//8185536/webrev.00/index.html >>>> 81 lines changed: 19 ins; 0 del; 62 mod >>> >>> Hi all, >>> >>> could you please review this small patch which introduces 'vm.aot' property >>> into jtreg @requires context and replaces all '@key aot' added by 8185046[1] >>> w/ '@requiers vm.aot'? >>> Goetz(author of 8185046) is checking that it works for their configurations. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8185536 >>> webrev: >>> http://cr.openjdk.java.net/~iignatyev//8185536/webrev.00/index.html >>> testing: hotspot/test/compiler/aot tests >>> - on linux-x64 : 56 tests selected/run >>> - on linux-x86 : 0 tests selected/run >>> - on windows-x64 (after remove tests from problemlist) : 56 tests >>> selected/run >>> - on windows-x86 (after remove tests from problemlist) : 0 tests >>> selected/run >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8185046 >>> >>> Thanks, >>> -- Igor > From david.holmes at oracle.com Thu Aug 3 01:02:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Aug 2017 11:02:41 +1000 Subject: RFR(XS): 8185567: fix hsdis cpu to architecture mapping on various Linux platforms In-Reply-To: References: Message-ID: <97d895e5-d86d-aa98-d463-65b22b2fdb43@oracle.com> Hi Buck, After some extensive offlist discussion the native build support for arm seems fine, so this is good to go IMHO. Thanks, David On 1/08/2017 10:36 PM, David Holmes wrote: > Hi Buck, > > On 1/08/2017 10:32 PM, David Buck wrote: >> Hi! >> >> It was suggested that I also loop in build-dev to the review of this >> proposed change. > > Thanks for that. As I said in other email the changes seem reasonable, > but the arm support seems to be for a native arm build whereas we use > cross-compilation for ARM in the main build. For that matter the arm64 > port also uses cross-compilation. > > Cheers, > David > >> Cheers, >> -Buck >> >> On 2017/07/31 22:06, David Buck wrote: >>> Hi! >>> >>> Would you please review this small set of very simple build fixes to >>> hsdis? >>> >>> bug report: https://bugs.openjdk.java.net/browse/JDK-8185567 >>> >>> proposed fix: http://cr.openjdk.java.net/~dbuck/8185567.0/ >>> >>> With these changes, hsdis should now correctly build out of the box >>> (no manual editing of files needed) on Linux with any of the >>> following return values of "uname -m": >>> >>> i386 >>> i686 >>> amd64 >>> x86_64 >>> *arm* >>> aarch64 >>> >>> I made it a point to *not* break anything that previously worked. So, >>> for example, aarch64 environments will still compile for aarch64 even >>> when the build target is "all" and not "all64". While forcing it to >>> try and build a 32-bit binary would be more consistent with what >>> happens with "make all" on linux-amd64 or solaris-sparcv9, I decided >>> to leave things as they are in case any aarch64 users depend on the >>> current behavior. Similarly, an attempt to run "make all" on >>> linux-sparcv9 will continue to try and build against whatever the >>> return value of "uname -m" was. Of course running "make all64" now >>> does the right thing and targets "sparcv9". >>> >>> Cheers, >>> -Buck >>> >>> From vladimir.kozlov at oracle.com Thu Aug 3 17:32:12 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 Aug 2017 10:32:12 -0700 Subject: [10] RFR(XS) 8185802: Enable AVX3 by default Message-ID: https://bugs.openjdk.java.net/browse/JDK-8185802 JDK-8183103 fix in JDK 9 disable AVXV3 by default (it set UseAVX to 2 by default). Now that fix was pushed into JDK 10 which disables AVX3 testing. Enable AVX3 again. src/cpu/x86/vm/globals_x86.hpp @@ -116,7 +116,7 @@ product(bool, UseStoreImmI16, true, \ "Use store immediate 16-bits value instruction on x86") \ \ - product(intx, UseAVX, 2, \ + product(intx, UseAVX, 3, \ "Highest supported AVX instructions set on x86/x64") \ range(0, 99) \ \ Thanks, Vladimir From vladimir.x.ivanov at oracle.com Thu Aug 3 20:08:49 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 3 Aug 2017 13:08:49 -0700 Subject: RFR(XS): 8185567: fix hsdis cpu to architecture mapping on various Linux platforms In-Reply-To: References: Message-ID: <495e6d8b-1874-d10d-94bc-a4f7d04e0ec2@oracle.com> Looks good! Best regards, Vladimir Ivanov On 8/1/17 5:32 AM, David Buck wrote: > Hi! > > It was suggested that I also loop in build-dev to the review of this > proposed change. > > Cheers, > -Buck > > On 2017/07/31 22:06, David Buck wrote: >> Hi! >> >> Would you please review this small set of very simple build fixes to >> hsdis? >> >> bug report: https://bugs.openjdk.java.net/browse/JDK-8185567 >> >> proposed fix: http://cr.openjdk.java.net/~dbuck/8185567.0/ >> >> With these changes, hsdis should now correctly build out of the box >> (no manual editing of files needed) on Linux with any of the following >> return values of "uname -m": >> >> i386 >> i686 >> amd64 >> x86_64 >> *arm* >> aarch64 >> >> I made it a point to *not* break anything that previously worked. So, >> for example, aarch64 environments will still compile for aarch64 even >> when the build target is "all" and not "all64". While forcing it to >> try and build a 32-bit binary would be more consistent with what >> happens with "make all" on linux-amd64 or solaris-sparcv9, I decided >> to leave things as they are in case any aarch64 users depend on the >> current behavior. Similarly, an attempt to run "make all" on >> linux-sparcv9 will continue to try and build against whatever the >> return value of "uname -m" was. Of course running "make all64" now >> does the right thing and targets "sparcv9". >> >> Cheers, >> -Buck >> >> From igor.ignatyev at oracle.com Thu Aug 3 23:15:26 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 3 Aug 2017 16:15:26 -0700 Subject: RFR(M) : 8184738: CTW fails with assert(!method->method_holder()->is_not_initialized()) failed: method holder must be initialized Message-ID: <39D6BBFC-A244-47AF-B860-18B70B67F393@oracle.com> > http://cr.openjdk.java.net/~iignatyev//8184738/webrev.00 > 547 lines changed: 220 ins; 166 del; 161 mod; Hi all, could you please review this patch for CTW library? problem: we didn't run for some classes, it might have lead to assert in native code during compilation. fix: now we load and init a class inside try-catch block, so if there is any issue w/ class loading/initialization we will report an warning and skip this class. as a part of this patch, I've also done some refactoring (mainly in *Entry classes) to make code more readable and remove duplication. jbs: https://bugs.openjdk.java.net/browse/JDK-8184738 webrev: http://cr.openjdk.java.net/~iignatyev//8184738/webrev.00 testing: hotspot/test/applications/ctw, hotspot/test/testlibrary_tests/ctw Thanks, -- Igor From tim.bell at oracle.com Thu Aug 3 20:49:27 2017 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 03 Aug 2017 13:49:27 -0700 Subject: RFR(XS): 8185567: fix hsdis cpu to architecture mapping on various Linux platforms In-Reply-To: <495e6d8b-1874-d10d-94bc-a4f7d04e0ec2@oracle.com> References: <495e6d8b-1874-d10d-94bc-a4f7d04e0ec2@oracle.com> Message-ID: <59838C57.8090903@oracle.com> > On 8/1/17 5:32 AM, David Buck wrote: >> Hi! >> >> It was suggested that I also loop in build-dev to the review of this >> proposed change. The build Makefile change looks good. Tim On 08/03/17 13:08, Vladimir Ivanov wrote:> Looks good! > > Best regards, > Vladimir Ivanov > >> >> Cheers, >> -Buck >> >> On 2017/07/31 22:06, David Buck wrote: >>> Hi! >>> >>> Would you please review this small set of very simple build fixes to >>> hsdis? >>> >>> bug report: https://bugs.openjdk.java.net/browse/JDK-8185567 >>> >>> proposed fix: http://cr.openjdk.java.net/~dbuck/8185567.0/ >>> >>> With these changes, hsdis should now correctly build out of the box >>> (no manual editing of files needed) on Linux with any of the >>> following return values of "uname -m": >>> >>> i386 >>> i686 >>> amd64 >>> x86_64 >>> *arm* >>> aarch64 >>> >>> I made it a point to *not* break anything that previously worked. So, >>> for example, aarch64 environments will still compile for aarch64 even >>> when the build target is "all" and not "all64". While forcing it to >>> try and build a 32-bit binary would be more consistent with what >>> happens with "make all" on linux-amd64 or solaris-sparcv9, I decided >>> to leave things as they are in case any aarch64 users depend on the >>> current behavior. Similarly, an attempt to run "make all" on >>> linux-sparcv9 will continue to try and build against whatever the >>> return value of "uname -m" was. Of course running "make all64" now >>> does the right thing and targets "sparcv9". >>> >>> Cheers, >>> -Buck >>> >>> From tobias.hartmann at oracle.com Fri Aug 4 05:35:35 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 4 Aug 2017 07:35:35 +0200 Subject: [10] RFR(XS) 8185802: Enable AVX3 by default In-Reply-To: References: Message-ID: Hi Vladimir, looks good to me. Best regards, Tobias On 8/3/2017 7:32 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8185802 > > JDK-8183103 fix in JDK 9 disable AVXV3 by default (it set UseAVX to 2 by > default). Now that fix was pushed into JDK 10 which disables AVX3 > testing. Enable AVX3 again. > > src/cpu/x86/vm/globals_x86.hpp > @@ -116,7 +116,7 @@ > product(bool, UseStoreImmI16, true, \ > "Use store immediate 16-bits value instruction on x86") \ > > \ > - product(intx, UseAVX, 2, \ > + product(intx, UseAVX, 3, \ > "Highest supported AVX instructions set on x86/x64") \ > range(0, 99) \ > > \ > > > Thanks, > Vladimir From dean.long at oracle.com Fri Aug 4 06:00:19 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 3 Aug 2017 23:00:19 -0700 Subject: RFR(XL) 8185829: Update Graal Message-ID: This is a Graal update. Please see the JBS entry for the complete list of upstream changes included. http://cr.openjdk.java.net/~dlong/8185829/webrev/ https://bugs.openjdk.java.net/browse/JDK-8185829 dl From muthusamy.chinnathambi at oracle.com Fri Aug 4 11:42:08 2017 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Fri, 4 Aug 2017 04:42:08 -0700 (PDT) Subject: [10] RFR (XS) 8185843: fix broken HotSpotInternals wiki links Message-ID: Hi, Please review this trivial change for the fix of bug 'JDK-8185843 fix broken HotSpotInternals wiki links' Summary: The old "wikis.oracle.com" links are no longer accessible as they are moved to "wiki.openjdk.java.net". Some code comments and README files still point to the old URLs and this change is to fix those broken links. jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8185843 webrev link: http://cr.openjdk.java.net/~shshahma/Muthu/8185843/webrev.00/ Testing: ran jprt Regards, Muthusamy C From igor.veresov at oracle.com Fri Aug 4 15:07:26 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 4 Aug 2017 08:07:26 -0700 Subject: RFR(XL) 8185829: Update Graal In-Reply-To: References: Message-ID: Looks good. Thanks for doing the merge. igor > On Aug 3, 2017, at 11:00 PM, dean.long at oracle.com wrote: > > This is a Graal update. Please see the JBS entry for the complete list of upstream changes included. > > http://cr.openjdk.java.net/~dlong/8185829/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8185829 > > dl From 515248659 at qq.com Fri Aug 4 16:29:44 2017 From: 515248659 at qq.com (QQ mail) Date: Sat, 5 Aug 2017 00:29:44 +0800 Subject: Some doubts about the LIR Operand Message-ID: Hi all,? I want to Insert a runtime function to print the StoreField's write barrier information produced by C1 compiler. But it seems that the passed LIR operands sometimes crash the hotspot. Details: First I write a debug function to print the values: jdk8u/hotspot/src/share/vm/c1/c1_Runtime1.cpp JRT_LEAF(void, Runtime1::debug_function(HeapWord* field_addr, HeapWord* target_addr)) ? tty->print(" C1 : after ?decode: src addr: %#lx , dst addr: %#lx \n",(unsigned long)field_addr, (unsigned long)target_addr); JRT_END Then, I build a runtime function invoke ?in :?void LIRGenerator::do_StoreField(StoreField* x) , just after the post_barrier() . The source code: jdk8u/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp void LIRGenerator::do_StoreField(StoreField* x) { ? bool needs_patching = x->needs_patching(); ? bool is_volatile = x->field()->is_volatile(); ? BasicType field_type = x->field_type(); ? bool is_oop = (field_type == T_ARRAY || field_type == T_OBJECT); ? CodeEmitInfo* info = NULL; ? if (needs_patching) { ? ? assert(x->explicit_null_check() == NULL, "can't fold null check into patching field access"); ? ? info = state_for(x, x->state_before()); ? } else if (x->needs_null_check()) { ? ? NullCheck* nc = x->explicit_null_check(); ? ? if (nc == NULL) { ? ? ? info = state_for(x); ? ? } else { ? ? ? info = state_for(nc); ? ? } ? } ? LIRItem object(x->obj(), this); ? LIRItem value(x->value(), ?this); ? object.load_item(); ? if (is_volatile || needs_patching) { ? ? // load item if field is volatile (fewer special cases for volatiles) ? ? // load item if field not initialized ? ? // load item if field not constant ? ? // because of code patching we cannot inline constants ? ? if (field_type == T_BYTE || field_type == T_BOOLEAN) { ? ? ? value.load_byte_item(); ? ? } else ?{ ? ? ? value.load_item(); ? ? } ? } else { ? ? value.load_for_store(field_type); ? } ? set_no_result(x); #ifndef PRODUCT ? if (PrintNotLoaded && needs_patching) { ? ? tty->print_cr(" ? ###class not loaded at store_%s bci %d", ? ? ? ? ? ? ? ? ? x->is_static() ? ?"static" : "field", x->printable_bci()); ? } #endif ? if (x->needs_null_check() && ? ? ? (needs_patching || ? ? ? ?MacroAssembler::needs_explicit_null_check(x->offset()))) { ? ? // emit an explicit null check because the offset is too large ? ? __ null_check(object.result(), new CodeEmitInfo(info)); ? } ? LIR_Address* address; ? if (needs_patching) { ? ? // we need to patch the offset in the instruction so don't allow ? ? // generate_address to try to be smart about emitting the -1. ? ? // Otherwise the patching code won't know how to find the ? ? // instruction to patch. ? ? address = new LIR_Address(object.result(), PATCHED_ADDR, field_type); ? } else { ? ? address = generate_address(object.result(), x->offset(), field_type); ? } ? if (is_volatile && os::is_MP()) { ? ? __ membar_release(); ? } ? if (is_oop) { ? ? // Do the pre-write barrier, if any. ? ? pre_barrier(LIR_OprFact::address(address), ? ? ? ? ? ? ? ? LIR_OprFact::illegalOpr /* pre_val */, ? ? ? ? ? ? ? ? true /* do_load*/, ? ? ? ? ? ? ? ? needs_patching, ? ? ? ? ? ? ? ? (info ? new CodeEmitInfo(info) : NULL)); ? } ? if (is_volatile && !needs_patching) { ? ? volatile_field_store(value.result(), address, info); ? } else { ? ? LIR_PatchCode patch_code = needs_patching ? lir_patch_normal : lir_patch_none; ? ? __ store(value.result(), address, info, patch_code); ? } ? if (is_oop) { ? ? // Store to object so mark the card of the header ? ? post_barrier(object.result(), value.result()); ? ? ? //debug ? ? BasicTypeList signature; ? ? signature.append(NOT_LP64(T_INT) LP64_ONLY(T_LONG)); ?// 1st argument, HeapWord* src_addr, ? ? signature.append(NOT_LP64(T_INT) LP64_ONLY(T_LONG)); ?// 2nd argument, HeapWord* target_addr, ? ? CallingConvention* cc = frame_map()->c_calling_convention(&signature); ? ? __ move(object.result(), cc->args()->at(0)); ? ? ? ? ?// &obj.field ?-> 1st arg ? ? __ move(value.result(), cc->args()->at(1)); ? ? ? ? ? // target addr -> 2nd arg ? ? __ call_runtime_leaf( CAST_FROM_FN_PTR(u_char*, Runtime1::debug_function), getThreadTemp(), LIR_OprFact::illegalOpr,cc->args()); ?? ? } ? if (is_volatile && os::is_MP()) { ? ? __ membar(); ? } } Then it sometimes crashes and print the call stack: (gdb) bt #0 ?0x00007ffff7a47c37 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 ?0x00007ffff7a4b028 in __GI_abort () at abort.c:89 #2 ?0x00007ffff6ce804a in os::abort (dump_core=true) at /home2/spark06/jdk8u/hotspot/src/os/linux/vm/os_linux.cpp:1496 #3 ?0x00007ffff6eb4ba2 in VMError::report_and_die (this=0x7fff7b9f7e90) at /home2/spark06/jdk8u/hotspot/src/share/vm/utilities/vmError.cpp:1060 #4 ?0x00007ffff684647b in report_vm_error (file=0x7ffff6f610f0 "/home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.hpp", line=420, error_msg=0x7ffff6f612a8 "assert(is_single_cpu() && !is_virtual()) failed", ? ?detail_msg=0x7ffff6f61155 "type check") at /home2/spark06/jdk8u/hotspot/src/share/vm/utilities/debug.cpp:226 #5 ?0x00007ffff6673596 in LIR_OprDesc::cpu_regnr (this=0x93) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.hpp:420 #6 ?0x00007ffff666971e in LIR_OprDesc::as_register (this=0x93) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.cpp:34 #7 ?0x00007ffff667be52 in LIR_Assembler::const2reg (this=0x7fff7b9f8290, src=0x7ffe50056170, dest=0x93, patch_code=lir_patch_none, info=0x0) at /home2/spark06/jdk8u/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:681 #8 ?0x00007ffff6677d2e in LIR_Assembler::move_op (this=0x7fff7b9f8290, src=0x7ffe50056170, dest=0x93, type=T_LONG, patch_code=lir_patch_none, info=0x0, pop_fpu_stack=false, unaligned=false, wide=false) ? ?at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:841 #9 ?0x00007ffff6676dcc in LIR_Assembler::emit_op1 (this=0x7fff7b9f8290, op=0x7ffe5802f9d0) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:523 #10 0x00007ffff666def7 in LIR_Op1::emit_code (this=0x7ffe5802f9d0, masm=0x7fff7b9f8290) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.cpp:1103 #11 0x00007ffff6676255 in LIR_Assembler::emit_lir_list (this=0x7fff7b9f8290, list=0x7ffe50056080) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:308 #12 0x00007ffff6676081 in LIR_Assembler::emit_block (this=0x7fff7b9f8290, block=0x7ffe50052390) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:274 #13 0x00007ffff6675e61 in LIR_Assembler::emit_code (this=0x7fff7b9f8290, hir=0x7ffe50054600) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:233 #14 0x00007ffff663564b in Compilation::emit_code_body (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:343 #15 0x00007ffff663593b in Compilation::compile_java_method (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:395 #16 0x00007ffff6635c31 in Compilation::compile_method (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:448 #17 0x00007ffff6636275 in Compilation::Compilation (this=0x7fff7b9f8590, compiler=0x7ffff01bda50, env=0x7fff7b9f8a30, method=0x7ffe58028400, osr_bci=-1, buffer_blob=0x7fffe11f5650) ? ?at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:559 #18 0x00007ffff6638f7e in Compiler::compile_method (this=0x7ffff01bda50, env=0x7fff7b9f8a30, method=0x7ffe58028400, entry_bci=-1) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compiler.cpp:106 #19 0x00007ffff67e20f4 in CompileBroker::invoke_compiler_on_method (task=0x7ffff027d680) at /home2/spark06/jdk8u/hotspot/src/share/vm/compiler/compileBroker.cpp:2000 #20 0x00007ffff67e1651 in CompileBroker::compiler_thread_loop () at /home2/spark06/jdk8u/hotspot/src/share/vm/compiler/compileBroker.cpp:1815 #21 0x00007ffff6e58c92 in compiler_thread_entry (thread=0x7ffff01fd800, __the_thread__=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:3233 #22 0x00007ffff6e5402e in JavaThread::thread_main_inner (this=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:1702 #23 0x00007ffff6e53efb in JavaThread::run (this=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:1682 #24 0x00007ffff6ce6b33 in java_start (thread=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/os/linux/vm/os_linux.cpp:782 #25 0x00007ffff75f7184 in start_thread (arg=0x7fff7b9f9700) at pthread_create.c:312 #26 0x00007ffff7b0effd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 It seems that, the operand , object.result() and value.result() cause the error. But I can?t understand why, if this is a oop store field , I think the object.result() and value.result() should be pointer(LIR_OprPtr) or array address(LIR_Address), Why it cause errors? Can any one give me some advices ? Thank you for your help. Chenxi Wang. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Fri Aug 4 17:43:43 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 4 Aug 2017 10:43:43 -0700 Subject: RFR(XL) 8185829: Update Graal In-Reply-To: References: Message-ID: <67747f34-28a5-ce2e-73ff-67a94a027bc4@oracle.com> Thanks for the review, and the help! dl On 8/4/17 8:07 AM, Igor Veresov wrote: > Looks good. Thanks for doing the merge. > > igor > >> On Aug 3, 2017, at 11:00 PM, dean.long at oracle.com wrote: >> >> This is a Graal update. Please see the JBS entry for the complete list of upstream changes included. >> >> http://cr.openjdk.java.net/~dlong/8185829/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8185829 >> >> dl From vladimir.kozlov at oracle.com Fri Aug 4 19:31:25 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 4 Aug 2017 12:31:25 -0700 Subject: [10] RFR(XS) 8185802: Enable AVX3 by default In-Reply-To: References: Message-ID: Thanks you, Tobias Vladimir On 8/3/17 10:35 PM, Tobias Hartmann wrote: > Hi Vladimir, > > looks good to me. > > Best regards, > Tobias > > On 8/3/2017 7:32 PM, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8185802 >> >> JDK-8183103 fix in JDK 9 disable AVXV3 by default (it set UseAVX to 2 >> by default). Now that fix was pushed into JDK 10 which disables AVX3 >> testing. Enable AVX3 again. >> >> src/cpu/x86/vm/globals_x86.hpp >> @@ -116,7 +116,7 @@ >> product(bool, UseStoreImmI16, true, \ >> "Use store immediate 16-bits value instruction on >> x86") \ >> >> \ >> - product(intx, UseAVX, 2, \ >> + product(intx, UseAVX, 3, \ >> "Highest supported AVX instructions set on x86/x64") \ >> range(0, 99) \ >> >> \ >> >> >> Thanks, >> Vladimir From daniel.daugherty at oracle.com Fri Aug 4 21:53:48 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 4 Aug 2017 15:53:48 -0600 Subject: RFR(XXS): quarantine compiler/ciReplay/TestSA.sh (8185876) Message-ID: <9bdab5db-6708-d504-d9cc-1957575cd69a@oracle.com> Greetings, I'm quarantining compiler/ciReplay/TestSA.sh as it continues to fail in the JDK10-hs nightly. 8185876 quarantine compiler/ciReplay/TestSA.sh https://bugs.openjdk.java.net/browse/JDK-8185876 $ hg diff test/ProblemList.txt diff -r 2cbcc2fdc073 test/ProblemList.txt --- a/test/ProblemList.txt Fri Aug 04 12:24:33 2017 -0700 +++ b/test/ProblemList.txt Fri Aug 04 14:51:00 2017 -0700 @@ -40,6 +40,7 @@ # :hotspot_compiler +compiler/ciReplay/TestSA.sh 8029528 generic-all compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 generic-all compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 8140405 generic-all compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 generic-all This fix is targeted to JDK10/hs. Dan From vladimir.kozlov at oracle.com Fri Aug 4 22:07:31 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 4 Aug 2017 15:07:31 -0700 Subject: RFR(XXS): quarantine compiler/ciReplay/TestSA.sh (8185876) In-Reply-To: <9bdab5db-6708-d504-d9cc-1957575cd69a@oracle.com> References: <9bdab5db-6708-d504-d9cc-1957575cd69a@oracle.com> Message-ID: Tere are no compiler/ciReplay/TestSA.sh file after 8155219 changes. Script was replaced by Java files. I agree with quarantine these tests but names should be correct. Thanks, Vladimir On 8/4/17 2:53 PM, Daniel D. Daugherty wrote: > Greetings, > > I'm quarantining compiler/ciReplay/TestSA.sh as it continues to fail in > the JDK10-hs nightly. > > 8185876 quarantine compiler/ciReplay/TestSA.sh > https://bugs.openjdk.java.net/browse/JDK-8185876 > > $ hg diff test/ProblemList.txt > diff -r 2cbcc2fdc073 test/ProblemList.txt > --- a/test/ProblemList.txt Fri Aug 04 12:24:33 2017 -0700 > +++ b/test/ProblemList.txt Fri Aug 04 14:51:00 2017 -0700 > @@ -40,6 +40,7 @@ > > # :hotspot_compiler > > +compiler/ciReplay/TestSA.sh 8029528 generic-all > compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 > generic-all > compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java > 8140405 generic-all > compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 > generic-all > > This fix is targeted to JDK10/hs. > > Dan From igor.ignatyev at oracle.com Fri Aug 4 22:13:57 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 4 Aug 2017 15:13:57 -0700 Subject: RFR(S) : 8183337 : hotspot/compiler/aot tests fail due to missed tools Message-ID: <78D4B9D8-7FB1-491A-B86E-BBF9F961712F@oracle.com> http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html > 226 lines changed: 160 ins; 62 del; 4 mod; Hi all, could you please review this small patch which aims to solve the problem w/ missed linker in aot tests? problem: jaotc tool needs linker to be installed, but at some hosts, esp. windows and mac, it is not always a case. as a results, aot tests which use jaotc fail on such hosts. fix: on hosts which don't have 'ld' in PATH, we download the devkit and pass the path to the linker from it to jaotc tool. caveats: - oracle implementation of artifacts resolver does not work concurrently, so the tests have to be run in 'exclusiveAccess' mode - some devkits (linux, solaris) are applicable only for a specific OS version bug: https://bugs.openjdk.java.net/browse/JDK-8183337 webrev: http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html testing: hotspot/compiler/aot on all platforms including systems w/o installed linker Thanks, -- Igor From vladimir.kozlov at oracle.com Fri Aug 4 22:37:56 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 4 Aug 2017 15:37:56 -0700 Subject: RFR(S) : 8183337 : hotspot/compiler/aot tests fail due to missed tools In-Reply-To: <78D4B9D8-7FB1-491A-B86E-BBF9F961712F@oracle.com> References: <78D4B9D8-7FB1-491A-B86E-BBF9F961712F@oracle.com> Message-ID: <20d9621a-9706-128a-3875-840ec1f0024a@oracle.com> This is ugly. Embedding into tests versions of compilers we use. I see they are listed in common/conf/jib-profiles.js. Can we extract them from there or other place? Such change may be okay for internal use but what about community? And can you add a simple tests that artifacts resolver exist at all? Thanks, Vladimir On 8/4/17 3:13 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >> 226 lines changed: 160 ins; 62 del; 4 mod; > > > Hi all, > > could you please review this small patch which aims to solve the problem w/ missed linker in aot tests? > > problem: jaotc tool needs linker to be installed, but at some hosts, esp. windows and mac, it is not always a case. as a results, aot tests which use jaotc fail on such hosts. > fix: on hosts which don't have 'ld' in PATH, we download the devkit and pass the path to the linker from it to jaotc tool. > caveats: > - oracle implementation of artifacts resolver does not work concurrently, so the tests have to be run in 'exclusiveAccess' mode > - some devkits (linux, solaris) are applicable only for a specific OS version > > bug: https://bugs.openjdk.java.net/browse/JDK-8183337 > webrev: http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html > testing: hotspot/compiler/aot on all platforms including systems w/o installed linker > > Thanks, > -- Igor > From vladimir.x.ivanov at oracle.com Fri Aug 4 23:07:29 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 4 Aug 2017 16:07:29 -0700 Subject: [10] RFR (XS) 8185843: fix broken HotSpotInternals wiki links In-Reply-To: References: Message-ID: <6ef6964c-45a5-c5b2-07f9-7bacac82118a@oracle.com> Looks good. Best regards, Vladimir Ivanov On 8/4/17 4:42 AM, Muthusamy Chinnathambi wrote: > Hi, > > Please review this trivial change for the fix of bug 'JDK-8185843 fix broken HotSpotInternals wiki links' > > Summary: > The old "wikis.oracle.com" links are no longer accessible as they are moved to "wiki.openjdk.java.net". Some code comments and README files still point to the old URLs and this change is to fix those broken links. > > jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8185843 > webrev link: http://cr.openjdk.java.net/~shshahma/Muthu/8185843/webrev.00/ > > Testing: ran jprt > > Regards, > Muthusamy C > From david.holmes at oracle.com Fri Aug 4 23:31:58 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 5 Aug 2017 09:31:58 +1000 Subject: [10] RFR (XS) 8185843: fix broken HotSpotInternals wiki links In-Reply-To: References: Message-ID: > Muthusamy Chinnathambi muthusamy.chinnathambi at oracle.com > Fri Aug 4 11:42:08 UTC 2017 > > Hi, > > Please review this trivial change for the fix of bug 'JDK-8185843 fix broken HotSpotInternals wiki links' > > Summary: > The old "wikis.oracle.com" links are no longer accessible as they are moved to "wiki.openjdk.java.net". Some code comments and README files still point to the old URLs and this change is to fix those broken links. > > jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8185843 > webrev link: http://cr.openjdk.java.net/~shshahma/Muthu/8185843/webrev.00/ Looks fine - and all URLs verified. Thanks, David > Testing: ran jprt > > Regards, > Muthusamy C From vladimir.kozlov at oracle.com Sat Aug 5 02:04:48 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 4 Aug 2017 19:04:48 -0700 Subject: [10] RFR (XS) 8185843: fix broken HotSpotInternals wiki links In-Reply-To: References: Message-ID: I will sponsor it. We have 2 *R*eviewes. And I need to clean up mess I created with rerun JPRT job ;) Thanks, Vladimir On 8/4/17 4:31 PM, David Holmes wrote: >> Muthusamy Chinnathambi muthusamy.chinnathambi at oracle.com >> Fri Aug 4 11:42:08 UTC 2017 >> >> Hi, >> >> Please review this trivial change for the fix of bug 'JDK-8185843 fix >> broken HotSpotInternals wiki links' >> >> Summary: >> The old "wikis.oracle.com" links are no longer accessible as they are >> moved to "wiki.openjdk.java.net". Some code comments and README files >> still point to the old URLs and this change is to fix those broken links. >> >> jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8185843 >> webrev link: >> http://cr.openjdk.java.net/~shshahma/Muthu/8185843/webrev.00/ > > Looks fine - and all URLs verified. > > Thanks, > David > >> Testing: ran jprt >> >> Regards, >> Muthusamy C From muthusamy.chinnathambi at oracle.com Mon Aug 7 06:52:07 2017 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Sun, 6 Aug 2017 23:52:07 -0700 (PDT) Subject: [10] RFR (XS) 8185843: fix broken HotSpotInternals wiki links In-Reply-To: References: Message-ID: Thanks Vladimir. Regards, Muthusamy C -----Original Message----- From: Vladimir Kozlov Sent: Saturday, August 5, 2017 7:35 AM To: hotspot-compiler-dev at openjdk.java.net Cc: Muthusamy Chinnathambi Subject: Re: [10] RFR (XS) 8185843: fix broken HotSpotInternals wiki links I will sponsor it. We have 2 *R*eviewes. And I need to clean up mess I created with rerun JPRT job ;) Thanks, Vladimir On 8/4/17 4:31 PM, David Holmes wrote: >> Muthusamy Chinnathambi muthusamy.chinnathambi at oracle.com >> Fri Aug 4 11:42:08 UTC 2017 >> >> Hi, >> >> Please review this trivial change for the fix of bug 'JDK-8185843 fix >> broken HotSpotInternals wiki links' >> >> Summary: >> The old "wikis.oracle.com" links are no longer accessible as they are >> moved to "wiki.openjdk.java.net". Some code comments and README files >> still point to the old URLs and this change is to fix those broken links. >> >> jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8185843 >> webrev link: >> http://cr.openjdk.java.net/~shshahma/Muthu/8185843/webrev.00/ > > Looks fine - and all URLs verified. > > Thanks, > David > >> Testing: ran jprt >> >> Regards, >> Muthusamy C From nils.eliasson at oracle.com Mon Aug 7 14:16:40 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 7 Aug 2017 16:16:40 +0200 Subject: [10] RFR(XS): 8169766: c1 + Xcomp reresolving call target every invocation Message-ID: Hi, Please review this patch. In bug https://bugs.openjdk.java.net/browse/JDK-8160543 I changed the behaviour for some calls in c1 generated code to make it comply with the VM-spec - LinkageError must be thrown before NPE. One detail was missed in that fix: Some calls, that was static bound and became optimized virtual calls, now became vanilla virtual calls. The virtual calls use the unverified entry, but for the static_bound calls the reciever_klass was not set making the receiver check fail on every invocation. This scenario is only common with Xcomp when methods are compiled that have call targets that have not been run earlier. Also a c1 thing, c2 uses uncommontraps for this case. Bug: https://bugs.openjdk.java.net/browse/JDK-8160543 Webrev: http://cr.openjdk.java.net/~neliasso/8169766/webrev.01/ Regards, Nils Eliasson From vladimir.kozlov at oracle.com Mon Aug 7 16:42:17 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 7 Aug 2017 09:42:17 -0700 Subject: [10] RFR(XS): 8169766: c1 + Xcomp reresolving call target every invocation In-Reply-To: References: Message-ID: <8c45aa96-7f8a-506c-f7ba-6ad12f7a3201@oracle.com> Good. Question. Both, this and 8160543, bugs talk about C1 only. Does the problem exist with C2 too? Comments in compiledIC.cpp also talk about C1. Should we guard 8160543 and this changes in compiledIC.cpp with if (method_code->is_compiled_by_c1()) ? Thanks, Vladimir On 8/7/17 7:16 AM, Nils Eliasson wrote: > Hi, > > Please review this patch. > > In bug https://bugs.openjdk.java.net/browse/JDK-8160543 I changed the > behaviour for some calls in c1 generated code to make it comply with the > VM-spec - LinkageError must be thrown before NPE. > > One detail was missed in that fix: Some calls, that was static bound and > became optimized virtual calls, now became vanilla virtual calls. The > virtual calls use the unverified entry, but for the static_bound calls > the reciever_klass was not set making the receiver check fail on every > invocation. > > This scenario is only common with Xcomp when methods are compiled that > have call targets that have not been run earlier. Also a c1 thing, c2 > uses uncommontraps for this case. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160543 > > Webrev: http://cr.openjdk.java.net/~neliasso/8169766/webrev.01/ > > Regards, > > Nils Eliasson > From igor.ignatyev at oracle.com Mon Aug 7 23:23:09 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 7 Aug 2017 16:23:09 -0700 Subject: RFR(S) : 8183337 : hotspot/compiler/aot tests fail due to missed tools In-Reply-To: <20d9621a-9706-128a-3875-840ec1f0024a@oracle.com> References: <78D4B9D8-7FB1-491A-B86E-BBF9F961712F@oracle.com> <20d9621a-9706-128a-3875-840ec1f0024a@oracle.com> Message-ID: > On Aug 4, 2017, at 3:37 PM, Vladimir Kozlov wrote: > > This is ugly. Embedding into tests versions of compilers we use. I see they are listed in common/conf/jib-profiles.js. Can we extract them from there or other place? I agree that this is not a beauty. but extracting compiler version info from jib-profiles.js will introduce a dependency b/w the tests and source code outside the testbase, we tend to avoid such dependencies as they might break some infra configurations. unfortunately there is no place inside the testbase which has this info. so although I don't like having compiler versions in the tests, I dislike introducing this kind of dependency even more. > Such change may be okay for internal use but what about community? the changes don't make it any worse for community. 1st, the test will continue to work as before on hosts which have a linker installed. 2nd, there is a default implementation of artifacts resolver which basically uses java property to specify paths to artifacts. so if someone runs hotspot/compiler/aot tests on a host w/ a linker in PATH, the tests will use this linker, if the tests are run on a host w/o a linker, the tests will try to resolve an artifact and either "install" it using default artifacts resolve or fail w/ a clearer error message. so this patch increases aot test-coverage for community as well. I also would like to mention that infra team has plans to make it easier for community to use ArtifactResolver and JIB. Hence I believe this won't be much of a problem. > And can you add a simple tests that artifacts resolver exist at all? not sure I understand that you mean. the default artifact resolver always exists. and we already have the tests which use an artifact resolver, e.g. hotspot/test/applications/scimark/Scimark.java . Thanks -- Igor > > Thanks, > Vladimir > > On 8/4/17 3:13 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >>> 226 lines changed: 160 ins; 62 del; 4 mod; >> Hi all, >> could you please review this small patch which aims to solve the problem w/ missed linker in aot tests? >> problem: jaotc tool needs linker to be installed, but at some hosts, esp. windows and mac, it is not always a case. as a results, aot tests which use jaotc fail on such hosts. >> fix: on hosts which don't have 'ld' in PATH, we download the devkit and pass the path to the linker from it to jaotc tool. >> caveats: >> - oracle implementation of artifacts resolver does not work concurrently, so the tests have to be run in 'exclusiveAccess' mode >> - some devkits (linux, solaris) are applicable only for a specific OS version >> bug: https://bugs.openjdk.java.net/browse/JDK-8183337 >> webrev: http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >> testing: hotspot/compiler/aot on all platforms including systems w/o installed linker >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Mon Aug 7 23:51:18 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 7 Aug 2017 16:51:18 -0700 Subject: RFR(M) : 8184738: CTW fails with assert(!method->method_holder()->is_not_initialized()) failed: method holder must be initialized In-Reply-To: <39D6BBFC-A244-47AF-B860-18B70B67F393@oracle.com> References: <39D6BBFC-A244-47AF-B860-18B70B67F393@oracle.com> Message-ID: a reminder. -- Igor > On Aug 3, 2017, at 4:15 PM, Igor Ignatyev wrote: > >> http://cr.openjdk.java.net/~iignatyev//8184738/webrev.00 >> 547 lines changed: 220 ins; 166 del; 161 mod; > > > Hi all, > > could you please review this patch for CTW library? > > problem: we didn't run for some classes, it might have lead to assert in native code during compilation. > fix: now we load and init a class inside try-catch block, so if there is any issue w/ class loading/initialization we will report an warning and skip this class. > > as a part of this patch, I've also done some refactoring (mainly in *Entry classes) to make code more readable and remove duplication. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8184738 > webrev: http://cr.openjdk.java.net/~iignatyev//8184738/webrev.00 > testing: hotspot/test/applications/ctw, hotspot/test/testlibrary_tests/ctw > > Thanks, > -- Igor From vladimir.kozlov at oracle.com Tue Aug 8 02:09:06 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 7 Aug 2017 19:09:06 -0700 Subject: RFR(M) : 8184738: CTW fails with assert(!method->method_holder()->is_not_initialized()) failed: method holder must be initialized In-Reply-To: References: <39D6BBFC-A244-47AF-B860-18B70B67F393@oracle.com> Message-ID: <92593c72-1c8a-ac19-f332-99f8cb12b1bc@oracle.com> Looks good to me. Thanks, Vladimir On 8/7/17 4:51 PM, Igor Ignatyev wrote: > a reminder. > > -- Igor > >> On Aug 3, 2017, at 4:15 PM, Igor Ignatyev wrote: >> >>> http://cr.openjdk.java.net/~iignatyev//8184738/webrev.00 >>> 547 lines changed: 220 ins; 166 del; 161 mod; >> >> >> Hi all, >> >> could you please review this patch for CTW library? >> >> problem: we didn't run for some classes, it might have lead to assert in native code during compilation. >> fix: now we load and init a class inside try-catch block, so if there is any issue w/ class loading/initialization we will report an warning and skip this class. >> >> as a part of this patch, I've also done some refactoring (mainly in *Entry classes) to make code more readable and remove duplication. >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8184738 >> webrev: http://cr.openjdk.java.net/~iignatyev//8184738/webrev.00 >> testing: hotspot/test/applications/ctw, hotspot/test/testlibrary_tests/ctw >> >> Thanks, >> -- Igor > From igor.ignatyev at oracle.com Tue Aug 8 19:38:40 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 8 Aug 2017 12:38:40 -0700 Subject: RFR(M) : 8184738: CTW fails with assert(!method->method_holder()->is_not_initialized()) failed: method holder must be initialized In-Reply-To: <92593c72-1c8a-ac19-f332-99f8cb12b1bc@oracle.com> References: <39D6BBFC-A244-47AF-B860-18B70B67F393@oracle.com> <92593c72-1c8a-ac19-f332-99f8cb12b1bc@oracle.com> Message-ID: <4AF471AD-A11D-469B-B72D-6AD76B0C0390@oracle.com> Hi Vladimir, thank you for the review. Cheers, -- Igor > On Aug 7, 2017, at 7:09 PM, Vladimir Kozlov wrote: > > Looks good to me. > > Thanks, > Vladimir > > On 8/7/17 4:51 PM, Igor Ignatyev wrote: >> a reminder. >> -- Igor >>> On Aug 3, 2017, at 4:15 PM, Igor Ignatyev wrote: >>> >>>> http://cr.openjdk.java.net/~iignatyev//8184738/webrev.00 >>>> 547 lines changed: 220 ins; 166 del; 161 mod; >>> >>> >>> Hi all, >>> >>> could you please review this patch for CTW library? >>> >>> problem: we didn't run for some classes, it might have lead to assert in native code during compilation. >>> fix: now we load and init a class inside try-catch block, so if there is any issue w/ class loading/initialization we will report an warning and skip this class. >>> >>> as a part of this patch, I've also done some refactoring (mainly in *Entry classes) to make code more readable and remove duplication. >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8184738 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8184738/webrev.00 >>> testing: hotspot/test/applications/ctw, hotspot/test/testlibrary_tests/ctw >>> >>> Thanks, >>> -- Igor From tom.rodriguez at oracle.com Tue Aug 8 20:47:52 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 08 Aug 2017 13:47:52 -0700 Subject: [10] RFR(XS) 8185736: missing default exception handler in calls to rethrow_Stub Message-ID: <598A2378.9040103@oracle.com> http://cr.openjdk.java.net/~never/8185736/webrev https://bugs.openjdk.java.net/browse/JDK-8185736 C2 exception handler tables must always contain a handler for the bci -1 since exceptions thrown during exception dispatch will attempt to redispatch the recursive exception at bci -1. C2's rethrow stub may end up without a throw to the exit so one must be explicitly inserted to ensure the VM doesn't abort during dispatch. This happened reliably because of a StackOverflowException in a Graal system running R code but I was unable to build a test case for it. You can see this missing catch_pco by inspecting the -XX:+PrintExceptionHandlers output, so the assert by itself show any place where C2 is exposed to this problem. I believe C1 builds it's exception handler tables differently and doesn't necessarily include a -1 handler since it always contains an unwind handler entry point which is used when no other handler is specified. Vladimir ran I believe ran this through RBT. tom From vladimir.kozlov at oracle.com Tue Aug 8 22:11:08 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 8 Aug 2017 15:11:08 -0700 Subject: [10] RFR(XS) 8185736: missing default exception handler in calls to rethrow_Stub In-Reply-To: <598A2378.9040103@oracle.com> References: <598A2378.9040103@oracle.com> Message-ID: On 8/8/17 1:47 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8185736/webrev > https://bugs.openjdk.java.net/browse/JDK-8185736 Looks good. > > C2 exception handler tables must always contain a handler for the bci -1 > since exceptions thrown during exception dispatch will attempt to > redispatch the recursive exception at bci -1. C2's rethrow stub may end > up without a throw to the exit so one must be explicitly inserted to > ensure the VM doesn't abort during dispatch. This happened reliably > because of a StackOverflowException in a Graal system running R code but > I was unable to build a test case for it. You can see this missing > catch_pco by inspecting the -XX:+PrintExceptionHandlers output, so the > assert by itself show any place where C2 is exposed to this problem. I > believe C1 builds it's exception handler tables differently and doesn't > necessarily include a -1 handler since it always contains an unwind > handler entry point which is used when no other handler is specified. > > Vladimir ran I believe ran this through RBT. Yes, it passed compiler's RBT. Vladimir > > tom From vladimir.kozlov at oracle.com Wed Aug 9 17:12:41 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 9 Aug 2017 10:12:41 -0700 Subject: [10] RFR(S) 8185790: [JVMCI] getNextStackFrame and materializeVirtualObjects need to forward exceptions Message-ID: <57807379-aff0-4152-d748-d30452f4a614@oracle.com> http://cr.openjdk.java.net/~kvn/8185790/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8185790 Contributed by Lukas Stadler. Check for and forward OOM exceptions in getNextStackFrame() and materializeVirtualObjects(). Passed RBT testing. Thanks, Vladimir From vladimir.kozlov at oracle.com Wed Aug 9 21:58:47 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 9 Aug 2017 14:58:47 -0700 Subject: [10] RFR(S) 8185950: [JVMCI] fix NPE possibility in HotSpotSpeculationLog.speculate Message-ID: <7008bc98-d4ca-9e3e-2320-b067ac00121c@oracle.com> http://cr.openjdk.java.net/~kvn/8185950/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8185950 Contributed by Doug Simon. Fix NPE possibility in HotSpotSpeculationLog.speculate(). Passed RBT testing. Thanks, Vladimir From igor.ignatyev at oracle.com Thu Aug 10 02:56:57 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 9 Aug 2017 19:56:57 -0700 Subject: RFR(S) : 8184689 : Test applications/ctw/Modules.java fails with AssertionError in sun.hotspot.tools.ctw.Utils.fileNameToClassName Message-ID: http://cr.openjdk.java.net/~iignatyev//8184689/webrev.00/index.html > 13 lines changed: 7 ins; 4 del; 2 mod; Hi all, could you please review this bugfix for CTW library? problem: assert in sun.hotspot.tools.ctw.Utils fails for jimage entry, b/c such entries have "//" prefix and module_name can have a period in it, e.g. '/java.activation/com/sun/activation/registries/LineTokenizer.class' fix: remove module name from jimage entry names, so they will pass assert. this also made workaround in Utils::fileNameToClassName redundant, so it has been removed. bug: https://bugs.openjdk.java.net/browse/JDK-8184689 webrev: http://cr.openjdk.java.net/~iignatyev//8184689/webrev.00/index.html testing: hotspot/test/applications/ctw/Modules.java w/ '-ea -esa' Thanks, -- Igor From tobias.hartmann at oracle.com Thu Aug 10 02:59:28 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 10 Aug 2017 08:29:28 +0530 Subject: [10] RFR(S) 8185950: [JVMCI] fix NPE possibility in HotSpotSpeculationLog.speculate In-Reply-To: <7008bc98-d4ca-9e3e-2320-b067ac00121c@oracle.com> References: <7008bc98-d4ca-9e3e-2320-b067ac00121c@oracle.com> Message-ID: <8d76d010-504e-fad7-b72c-23bb1d8b3019@oracle.com> Hi Vladimir, On 10.08.2017 03:28, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8185950/webrev.00/ Looks good to me. Best regards, Tobias From david.buck at oracle.com Thu Aug 10 04:50:08 2017 From: david.buck at oracle.com (David Buck) Date: Thu, 10 Aug 2017 13:50:08 +0900 Subject: [8u-dev] Request for Approval: Backport of 8184271 and 8184009 In-Reply-To: <85fc3a25-5cbe-2c29-a9b0-db657cce80fc@oracle.com> References: <85fc3a25-5cbe-2c29-a9b0-db657cce80fc@oracle.com> Message-ID: approved pending successful code review of the JDK 8 version of the changeset I am CCing the HotSpot Compiler Development alias. If any Reviewers include this thread / alias when they approve, no further action will be required before pushing this change to jdk8u-dev. The definition we use for "trivial" requires the changeset exported from JDK 9/10 to be applicable to the JDK 8 forest as-is. This means zero manual editing. The only exceptions we make are for copyright year and path un-shuffling. Even if the surrounding lines of code which prevent a patch from being applied have nothing to do with the change, we require a new code review for the JDK 8 version of the change. Cheers, -Buck On 2017/08/10 12:02, Tobias Hartmann wrote: > Hi, > > just a reminder. I don't need a dev review for the trivial merge, right? > > Thanks, > Tobias > > On 02.08.2017 18:53, Tobias Hartmann wrote: >> Hi, >> >> please approve the backports of the following fixes to JDK 8u: >> >> 8184271: Time related C1 intrinsics produce inconsistent results when >> floating around >> https://bugs.openjdk.java.net/browse/JDK-8184271 >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-July/026681.html >> >> http://cr.openjdk.java.net/~thartmann/8184271/webrev.00/ >> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/cc2bc9993d64 >> >> The patch does not apply cleanly but requires a (trivial) merge: >> http://cr.openjdk.java.net/~thartmann/8184271_8u/webrev.00/ >> >> 8184009: Missing null pointer check in >> InterpreterRuntime::update_mdp_for_ret() >> https://bugs.openjdk.java.net/browse/JDK-8184009 >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-July/027514.html >> http://cr.openjdk.java.net/~thartmann/8184009/webrev.00/ >> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/56a68e37d23b >> >> Both fixes were pushed to JDK 10 and testing showed no problems. >> >> Thanks, >> Tobias From igor.veresov at oracle.com Thu Aug 10 05:11:14 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 9 Aug 2017 22:11:14 -0700 Subject: [10] RFR(S) 8185790: [JVMCI] getNextStackFrame and materializeVirtualObjects need to forward exceptions In-Reply-To: <57807379-aff0-4152-d748-d30452f4a614@oracle.com> References: <57807379-aff0-4152-d748-d30452f4a614@oracle.com> Message-ID: <24FBC66A-440C-47F1-9887-4F16BDD8DAB4@oracle.com> Looks good. igor > On Aug 9, 2017, at 10:12 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8185790/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8185790 > > Contributed by Lukas Stadler. > > Check for and forward OOM exceptions in getNextStackFrame() and materializeVirtualObjects(). > > Passed RBT testing. > > Thanks, > Vladimir From tobias.hartmann at oracle.com Thu Aug 10 10:51:10 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 10 Aug 2017 16:21:10 +0530 Subject: [8u-dev] Request for Approval: Backport of 8184271 and 8184009 In-Reply-To: References: <85fc3a25-5cbe-2c29-a9b0-db657cce80fc@oracle.com> Message-ID: Thanks David! Pushed it. Best regards, Tobias On 10.08.2017 10:20, David Buck wrote: > approved pending successful code review of the JDK 8 version of the changeset > > I am CCing the HotSpot Compiler Development alias. If any Reviewers include this thread / alias when they approve, no > further action will be required before pushing this change to jdk8u-dev. > > The definition we use for "trivial" requires the changeset exported from JDK 9/10 to be applicable to the JDK 8 forest > as-is. This means zero manual editing. The only exceptions we make are for copyright year and path un-shuffling. Even if > the surrounding lines of code which prevent a patch from being applied have nothing to do with the change, we require a > new code review for the JDK 8 version of the change. > > Cheers, > -Buck > > On 2017/08/10 12:02, Tobias Hartmann wrote: >> Hi, >> >> just a reminder. I don't need a dev review for the trivial merge, right? >> >> Thanks, >> Tobias >> >> On 02.08.2017 18:53, Tobias Hartmann wrote: >>> Hi, >>> >>> please approve the backports of the following fixes to JDK 8u: >>> >>> 8184271: Time related C1 intrinsics produce inconsistent results when floating around >>> https://bugs.openjdk.java.net/browse/JDK-8184271 >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-July/026681.html >>> http://cr.openjdk.java.net/~thartmann/8184271/webrev.00/ >>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/cc2bc9993d64 >>> >>> The patch does not apply cleanly but requires a (trivial) merge: >>> http://cr.openjdk.java.net/~thartmann/8184271_8u/webrev.00/ >>> >>> 8184009: Missing null pointer check in InterpreterRuntime::update_mdp_for_ret() >>> https://bugs.openjdk.java.net/browse/JDK-8184009 >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-July/027514.html >>> http://cr.openjdk.java.net/~thartmann/8184009/webrev.00/ >>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/56a68e37d23b >>> >>> Both fixes were pushed to JDK 10 and testing showed no problems. >>> >>> Thanks, >>> Tobias From poonam.bajaj at oracle.com Thu Aug 10 13:26:21 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Thu, 10 Aug 2017 06:26:21 -0700 (PDT) Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines Message-ID: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> Hello, Please review this simple patch: Bug: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8185572" JDK-8185572: Enable AssumeMP by default on SPARC machines Webrev: http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ This change enables AssumeMP by default on SPARC machines. On Sparc T7, to finalize BIS instructions the server compiler needs to add a 'membar' instruction at the end. But the generation of 'membar' is guarded by os::is_MP(), and os::is_MP() returns false when there is a single cpu available on the system. Now, in virtualized/container environments, the number of processors allocated to a virtual machine can dynamically change during the application runtime. That could lead to incorrect generation of BIS instructions and can cause JVM crashes. Enabling AssumeMP makes is_MP() always return true on SPARC systems. In future, we may consider making generation of 'membar ' unconditional with the enhancement request: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8150715" \o "Use new BIS algorithm for arraycopy on M7 SPARC" JDK-8150715. Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Thu Aug 10 14:33:04 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 Aug 2017 15:33:04 +0100 Subject: Is this a bug in the C2 matcher code? Message-ID: <58b6e810-3c1f-08f1-c4fb-4f904b639f56@redhat.com> /* CompareAndSet, Long: */ case vmIntrinsics::_compareAndSetLong: if (!Matcher::match_rule_supported(Op_CompareAndSwapL)) return false; break; case vmIntrinsics::_weakCompareAndSetLongPlain: case vmIntrinsics::_weakCompareAndSetLongAcquire: case vmIntrinsics::_weakCompareAndSetLongRelease: case vmIntrinsics::_weakCompareAndSetLong: if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapL)) return false; break; /* CompareAndSet, Int: */ case vmIntrinsics::_compareAndSetInt: if (!Matcher::match_rule_supported(Op_CompareAndSwapI)) return false; break; case vmIntrinsics::_weakCompareAndSetIntPlain: case vmIntrinsics::_weakCompareAndSetIntAcquire: case vmIntrinsics::_weakCompareAndSetIntRelease: case vmIntrinsics::_weakCompareAndSetInt: if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapL)) return false; break; Note that last line: if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapL)... Shouldn't that be Op_WeakCompareAndSwapI ? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Thu Aug 10 14:53:49 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 10 Aug 2017 15:53:49 +0100 Subject: Is this a bug in the C2 matcher code? In-Reply-To: <58b6e810-3c1f-08f1-c4fb-4f904b639f56@redhat.com> References: <58b6e810-3c1f-08f1-c4fb-4f904b639f56@redhat.com> Message-ID: <1f45ce99-4089-a3e2-b455-b9fcec90d608@redhat.com> On 10/08/17 15:33, Andrew Haley wrote: > if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapL)) return false; Yes, it is. Nice catch. Although, it seems to have been innocuous since every platform that has Op_WeakCompareAndSwapI also has Op_WeakCompareAndSwapL (I checked aarch64, x86_32/64, sparc and ppc). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.kozlov at oracle.com Thu Aug 10 16:40:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Aug 2017 09:40:50 -0700 Subject: RFR(S) : 8184689 : Test applications/ctw/Modules.java fails with AssertionError in sun.hotspot.tools.ctw.Utils.fileNameToClassName In-Reply-To: References: Message-ID: Good. Thanks, Vladimir On 8/9/17 7:56 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8184689/webrev.00/index.html >> 13 lines changed: 7 ins; 4 del; 2 mod; > > Hi all, > > could you please review this bugfix for CTW library? > > problem: assert in sun.hotspot.tools.ctw.Utils fails for jimage entry, b/c such entries have "//" prefix and module_name can have a period in it, e.g. '/java.activation/com/sun/activation/registries/LineTokenizer.class' > fix: remove module name from jimage entry names, so they will pass assert. this also made workaround in Utils::fileNameToClassName redundant, so it has been removed. > > bug: https://bugs.openjdk.java.net/browse/JDK-8184689 > webrev: http://cr.openjdk.java.net/~iignatyev//8184689/webrev.00/index.html > testing: hotspot/test/applications/ctw/Modules.java w/ '-ea -esa' > > Thanks, > -- Igor > From vladimir.kozlov at oracle.com Thu Aug 10 16:41:25 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Aug 2017 09:41:25 -0700 Subject: [10] RFR(S) 8185950: [JVMCI] fix NPE possibility in HotSpotSpeculationLog.speculate In-Reply-To: <8d76d010-504e-fad7-b72c-23bb1d8b3019@oracle.com> References: <7008bc98-d4ca-9e3e-2320-b067ac00121c@oracle.com> <8d76d010-504e-fad7-b72c-23bb1d8b3019@oracle.com> Message-ID: <9e0e794f-7d2c-7bcb-c34c-e6453ab5cf5b@oracle.com> Thank you, Tobias Vladimir On 8/9/17 7:59 PM, Tobias Hartmann wrote: > Hi Vladimir, > > On 10.08.2017 03:28, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8185950/webrev.00/ > > Looks good to me. > > Best regards, > Tobias From vladimir.kozlov at oracle.com Thu Aug 10 16:43:15 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Aug 2017 09:43:15 -0700 Subject: [10] RFR(S) 8185790: [JVMCI] getNextStackFrame and materializeVirtualObjects need to forward exceptions In-Reply-To: <24FBC66A-440C-47F1-9887-4F16BDD8DAB4@oracle.com> References: <57807379-aff0-4152-d748-d30452f4a614@oracle.com> <24FBC66A-440C-47F1-9887-4F16BDD8DAB4@oracle.com> Message-ID: <4244709c-975c-7c5c-f71d-fb4f9314e553@oracle.com> Thank you, Igor Vladimir On 8/9/17 10:11 PM, Igor Veresov wrote: > Looks good. > > igor > >> On Aug 9, 2017, at 10:12 AM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8185790/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8185790 >> >> Contributed by Lukas Stadler. >> >> Check for and forward OOM exceptions in getNextStackFrame() and materializeVirtualObjects(). >> >> Passed RBT testing. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Thu Aug 10 16:46:57 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Aug 2017 09:46:57 -0700 Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines In-Reply-To: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> References: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> Message-ID: CCing to Runtime. Can you add comment explaining why it set to true on SPARC? Thanks, Vladimir On 8/10/17 6:26 AM, Poonam Parhar wrote: > Hello, > > Please review this simple patch: > > Bug:_JDK-8185572_:Enable > AssumeMP by default on SPARC machines > > Webrev:http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ > > This change enables AssumeMP by default on SPARC machines. On Sparc T7, > to finalize BIS instructions the server compiler needs toadd > a?membar?instruction at the end.But the generation of?membar?is guarded > byos::is_MP(), andos::is_MP()returns false when there isa singlecpu > available on the system. Now,invirtualized/containerenvironments, the > number ofprocessorsallocated to a virtual machine can dynamically change > during the application runtime.That could lead to incorrect generation > of BIS instructions and can cause JVM crashes.Enabling AssumeMP makes > is_MP() always return true on SPARC systems. > > In future, we may consider makinggeneration of?membar?unconditional > withtheenhancementrequest:_JDK-8150715_. > > Thanks, > > Poonam > From vladimir.kozlov at oracle.com Thu Aug 10 16:51:52 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Aug 2017 09:51:52 -0700 Subject: Is this a bug in the C2 matcher code? In-Reply-To: <1f45ce99-4089-a3e2-b455-b9fcec90d608@redhat.com> References: <58b6e810-3c1f-08f1-c4fb-4f904b639f56@redhat.com> <1f45ce99-4089-a3e2-b455-b9fcec90d608@redhat.com> Message-ID: <03a5eb45-6506-6eae-819e-7baae667e015@oracle.com> Please, file bug. Thanks, Vladimir On 8/10/17 7:53 AM, Andrew Dinn wrote: > On 10/08/17 15:33, Andrew Haley wrote: >> if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapL)) return false; > > Yes, it is. Nice catch. > > Although, it seems to have been innocuous since every platform that has > Op_WeakCompareAndSwapI also has Op_WeakCompareAndSwapL (I checked > aarch64, x86_32/64, sparc and ppc). > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From gustavo.scalet at eldorado.org.br Thu Aug 10 17:19:35 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Thu, 10 Aug 2017 17:19:35 +0000 Subject: FW: [10] RFR(XS): 8185975: PPC64: Fix vsldoi interface according to the ISA In-Reply-To: <1772227f57984a6184ad0704e7e6474d@sap.com> References: <1772227f57984a6184ad0704e7e6474d@sap.com> Message-ID: <3f27fa9658014b87b03a46570b2d9f8f@serv031.corp.eldorado.org.br> -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: quarta-feira, 9 de agosto de 2017 09:14 To: Gustavo Serra Scalet ; ppc-aix-port-dev at openjdk.java.net Subject: RE: [10] RFR(XS): 8185975: PPC64: Fix vsldoi interface according to the ISA Hi Gustavo, thanks for the webrev. Looks good. I'd only like to rename si4 to ui4. But I can do that before pushing (no need for new webrev). Best regards, Martin -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet Sent: Dienstag, 8. August 2017 22:19 To: ppc-aix-port-dev at openjdk.java.net Subject: [10] RFR(XS): 8185975: PPC64: Fix vsldoi interface according to the ISA Hi, Could you please review this specific PPC64 change to hotspot? It was previously discussed with Martin Doerr on [1]. JBS: https://bugs.openjdk.java.net/browse/JDK-8185975 Webrev: https://gut.github.io/openjdk/webrev/JDK-8185975/webrev/ Best regards, Gustavo Serra Scalet [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-February/002913.html From gustavo.scalet at eldorado.org.br Thu Aug 10 17:21:16 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Thu, 10 Aug 2017 17:21:16 +0000 Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> Message-ID: Hi Martin, Alright. I'll analyze that and update to a new webrev. Thanks -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: quarta-feira, 9 de agosto de 2017 09:58 To: Gustavo Serra Scalet ; ppc-aix-port-dev at openjdk.java.net Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers Hi Gustavo, seems like you're preparing new VSR code :-) Nice change, but please update the copyright messages in the modified files. register_ppc.cpp to_vsr(): I don't like large code for a trivial computation. I'd prefer something like "return as_VectorSRegister(encoding() + 32)". I can sponsor this change. Thanks and best regards, Martin -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet Sent: Dienstag, 8. August 2017 22:19 To: ppc-aix-port-dev at openjdk.java.net Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers Hi, Could you please review this specific PPC64 change to hotspot? The aim of these changes is to allow a more complete usage of VSR. I make use of these interfaces on an instrinsic that I plan to send next but I decided to separate this change and send it first. JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ Best regards, Gustavo Serra Scalet From gustavo.scalet at eldorado.org.br Thu Aug 10 17:22:13 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Thu, 10 Aug 2017 17:22:13 +0000 Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics In-Reply-To: References: Message-ID: <1f159ee480284095b8e5c3f444dceb96@serv031.corp.eldorado.org.br> -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet Sent: ter?a-feira, 8 de agosto de 2017 17:19 To: ppc-aix-port-dev at openjdk.java.net Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics Hi, Could you please review this specific PPC64 change to hotspot? By implementing these intrinsics I noticed a small improvement with microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, only when backporting to JDK8 an improvement was noticed. JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ Motivation for this implementation: https://twitter.com/ijuma/status/698309312498835457 Best regards, Gustavo Serra Scalet From martin.doerr at sap.com Thu Aug 10 17:25:04 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 10 Aug 2017 17:25:04 +0000 Subject: [10] RFR(XS): 8185975: PPC64: Fix vsldoi interface according to the ISA In-Reply-To: <3f27fa9658014b87b03a46570b2d9f8f@serv031.corp.eldorado.org.br> References: <1772227f57984a6184ad0704e7e6474d@sap.com> <3f27fa9658014b87b03a46570b2d9f8f@serv031.corp.eldorado.org.br> Message-ID: Reviewed and pushed. Thanks and best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet Sent: Donnerstag, 10. August 2017 19:20 To: 'hotspot-compiler-dev at openjdk.java.net' Subject: FW: [10] RFR(XS): 8185975: PPC64: Fix vsldoi interface according to the ISA -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: quarta-feira, 9 de agosto de 2017 09:14 To: Gustavo Serra Scalet ; ppc-aix-port-dev at openjdk.java.net Subject: RE: [10] RFR(XS): 8185975: PPC64: Fix vsldoi interface according to the ISA Hi Gustavo, thanks for the webrev. Looks good. I'd only like to rename si4 to ui4. But I can do that before pushing (no need for new webrev). Best regards, Martin -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet Sent: Dienstag, 8. August 2017 22:19 To: ppc-aix-port-dev at openjdk.java.net Subject: [10] RFR(XS): 8185975: PPC64: Fix vsldoi interface according to the ISA Hi, Could you please review this specific PPC64 change to hotspot? It was previously discussed with Martin Doerr on [1]. JBS: https://bugs.openjdk.java.net/browse/JDK-8185975 Webrev: https://gut.github.io/openjdk/webrev/JDK-8185975/webrev/ Best regards, Gustavo Serra Scalet [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-February/002913.html From poonam.bajaj at oracle.com Thu Aug 10 17:44:09 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Thu, 10 Aug 2017 10:44:09 -0700 (PDT) Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines In-Reply-To: References: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> Message-ID: <0285fdb7-8548-48e5-b019-3de62f66cffe@default> Thanks Vladimir. Since the SPARC machines are always multi-cores, we can safely set AssumeMP to true on these. Adding my comments from the previous mail here again for better readability: ------------------------------------- Bug: https://bugs.openjdk.java.net/browse/JDK-8185572: Enable AssumeMP by default on SPARC machines Webrev: http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ This change enables AssumeMP by default on SPARC machines. On Sparc T7, to finalize BIS instructions the server compiler needs to add a 'membar' instruction at the end. But the generation of 'membar' is guarded by os::is_MP(), and os::is_MP() returns false when there is a single cpu available on the system. Now, in virtualized/container environments, the number of processors allocated to a virtual machine can dynamically change during the application runtime. That could lead to incorrect generation of BIS instructions and can cause JVM crashes. Enabling AssumeMP makes is_MP() always return true on SPARC systems. In future, we may consider making generation of 'membar' unconditional with the enhancement request: https://bugs.openjdk.java.net/browse/JDK-8150715. Thanks, Poonam > -----Original Message----- > From: Vladimir Kozlov > Sent: Thursday, August 10, 2017 9:47 AM > To: Poonam Parhar; hotspot-compiler-dev at openjdk.java.net > Cc: hotspot-runtime-dev at openjdk.java.net runtime > Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC > machines > > CCing to Runtime. > > Can you add comment explaining why it set to true on SPARC? > > Thanks, > Vladimir > > On 8/10/17 6:26 AM, Poonam Parhar wrote: > > Hello, > > > > Please review this simple patch: > > > > Bug:_JDK-8185572_ 8185572>:En > > able > > AssumeMP by default on SPARC machines > > > > Webrev:http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ > > > > This change enables AssumeMP by default on SPARC machines. On Sparc > > T7, to finalize BIS instructions the server compiler needs toadd > > a'membar'instruction at the end.But the generation of'membar'is > > guarded byos::is_MP(), andos::is_MP()returns false when there isa > > singlecpu available on the system. > > Now,invirtualized/containerenvironments, the number > > ofprocessorsallocated to a virtual machine can dynamically change > > during the application runtime.That could lead to incorrect > generation > > of BIS instructions and can cause JVM crashes.Enabling AssumeMP makes > > is_MP() always return true on SPARC systems. > > > > In future, we may consider makinggeneration of'membar'unconditional > > withtheenhancementrequest:_JDK- > 8150715_. > > > > Thanks, > > > > Poonam > > From vladimir.kozlov at oracle.com Thu Aug 10 18:23:54 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Aug 2017 11:23:54 -0700 Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines In-Reply-To: <0285fdb7-8548-48e5-b019-3de62f66cffe@default> References: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> <0285fdb7-8548-48e5-b019-3de62f66cffe@default> Message-ID: <80530dcf-57f4-8d8f-e084-360e770520a6@oracle.com> Poonam, I mean to add a small (one or two sentences) comment to the code. Some thing like next but may better wording: + if (FLAG_IS_DEFAULT(AssumeMP)) { + // BIS instructions require 'membar' instruction regardless number of CPU. + // Otherwise in virtualized/container environments which use only 1 cpu BIS instructions may produce incorrect results. + FLAG_SET_DEFAULT(AssumeMP, true); Thanks, Vladimir On 8/10/17 10:44 AM, Poonam Parhar wrote: > Thanks Vladimir. > > Since the SPARC machines are always multi-cores, we can safely set AssumeMP to true on these. > > Adding my comments from the previous mail here again for better readability: > ------------------------------------- > Bug: https://bugs.openjdk.java.net/browse/JDK-8185572: Enable AssumeMP by default on SPARC machines > Webrev: http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ > > This change enables AssumeMP by default on SPARC machines. On Sparc T7, to finalize BIS instructions the server compiler needs to add a 'membar' instruction at the end. But the generation of 'membar' is guarded by os::is_MP(), and os::is_MP() returns false when there is a single cpu available on the system. Now, in virtualized/container environments, the number of processors allocated to a virtual machine can dynamically change during the application runtime. That could lead to incorrect generation of BIS instructions and can cause JVM crashes. Enabling AssumeMP makes is_MP() always return true on SPARC systems. > > In future, we may consider making generation of 'membar' unconditional with the enhancement request: https://bugs.openjdk.java.net/browse/JDK-8150715. > > Thanks, > Poonam > > >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: Thursday, August 10, 2017 9:47 AM >> To: Poonam Parhar; hotspot-compiler-dev at openjdk.java.net >> Cc: hotspot-runtime-dev at openjdk.java.net runtime >> Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC >> machines >> >> CCing to Runtime. >> >> Can you add comment explaining why it set to true on SPARC? >> >> Thanks, >> Vladimir >> >> On 8/10/17 6:26 AM, Poonam Parhar wrote: >>> Hello, >>> >>> Please review this simple patch: >>> >>> Bug:_JDK-8185572_> 8185572>:En >>> able >>> AssumeMP by default on SPARC machines >>> >>> Webrev:http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >>> >>> This change enables AssumeMP by default on SPARC machines. On Sparc >>> T7, to finalize BIS instructions the server compiler needs toadd >>> a'membar'instruction at the end.But the generation of'membar'is >>> guarded byos::is_MP(), andos::is_MP()returns false when there isa >>> singlecpu available on the system. >>> Now,invirtualized/containerenvironments, the number >>> ofprocessorsallocated to a virtual machine can dynamically change >>> during the application runtime.That could lead to incorrect >> generation >>> of BIS instructions and can cause JVM crashes.Enabling AssumeMP makes >>> is_MP() always return true on SPARC systems. >>> >>> In future, we may consider makinggeneration of'membar'unconditional >>> withtheenhancementrequest:_JDK- >> 8150715_. >>> >>> Thanks, >>> >>> Poonam >>> From bob.vandette at oracle.com Thu Aug 10 18:53:30 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 10 Aug 2017 14:53:30 -0400 Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines In-Reply-To: <80530dcf-57f4-8d8f-e084-360e770520a6@oracle.com> References: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> <0285fdb7-8548-48e5-b019-3de62f66cffe@default> <80530dcf-57f4-8d8f-e084-360e770520a6@oracle.com> Message-ID: <38ABC51B-73E3-4DEF-B5E1-B44B8B25160D@oracle.com> Can we just always run with AssumeMP true for all platforms these days? Surely single CPU systems are rare now. We might have issues with Docker containers that have a limit 1 CPU on a large mp system which may cause issues. Bob. > On Aug 10, 2017, at 2:23 PM, Vladimir Kozlov wrote: > > Poonam, > > I mean to add a small (one or two sentences) comment to the code. Some thing like next but may better wording: > > + if (FLAG_IS_DEFAULT(AssumeMP)) { > + // BIS instructions require 'membar' instruction regardless number of CPU. > + // Otherwise in virtualized/container environments which use only 1 cpu BIS instructions may produce incorrect results. > + FLAG_SET_DEFAULT(AssumeMP, true); > > Thanks, > Vladimir > > On 8/10/17 10:44 AM, Poonam Parhar wrote: >> Thanks Vladimir. >> Since the SPARC machines are always multi-cores, we can safely set AssumeMP to true on these. >> Adding my comments from the previous mail here again for better readability: >> ------------------------------------- >> Bug: https://bugs.openjdk.java.net/browse/JDK-8185572: Enable AssumeMP by default on SPARC machines >> Webrev: http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >> This change enables AssumeMP by default on SPARC machines. On Sparc T7, to finalize BIS instructions the server compiler needs to add a 'membar' instruction at the end. But the generation of 'membar' is guarded by os::is_MP(), and os::is_MP() returns false when there is a single cpu available on the system. Now, in virtualized/container environments, the number of processors allocated to a virtual machine can dynamically change during the application runtime. That could lead to incorrect generation of BIS instructions and can cause JVM crashes. Enabling AssumeMP makes is_MP() always return true on SPARC systems. >> In future, we may consider making generation of 'membar' unconditional with the enhancement request: https://bugs.openjdk.java.net/browse/JDK-8150715. >> Thanks, >> Poonam >>> -----Original Message----- >>> From: Vladimir Kozlov >>> Sent: Thursday, August 10, 2017 9:47 AM >>> To: Poonam Parhar; hotspot-compiler-dev at openjdk.java.net >>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >>> Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC >>> machines >>> >>> CCing to Runtime. >>> >>> Can you add comment explaining why it set to true on SPARC? >>> >>> Thanks, >>> Vladimir >>> >>> On 8/10/17 6:26 AM, Poonam Parhar wrote: >>>> Hello, >>>> >>>> Please review this simple patch: >>>> >>>> Bug:_JDK-8185572_>> 8185572>:En >>>> able >>>> AssumeMP by default on SPARC machines >>>> >>>> Webrev:http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >>>> >>>> This change enables AssumeMP by default on SPARC machines. On Sparc >>>> T7, to finalize BIS instructions the server compiler needs toadd >>>> a'membar'instruction at the end.But the generation of'membar'is >>>> guarded byos::is_MP(), andos::is_MP()returns false when there isa >>>> singlecpu available on the system. >>>> Now,invirtualized/containerenvironments, the number >>>> ofprocessorsallocated to a virtual machine can dynamically change >>>> during the application runtime.That could lead to incorrect >>> generation >>>> of BIS instructions and can cause JVM crashes.Enabling AssumeMP makes >>>> is_MP() always return true on SPARC systems. >>>> >>>> In future, we may consider makinggeneration of'membar'unconditional >>>> withtheenhancementrequest:_JDK- >>> 8150715_. >>>> >>>> Thanks, >>>> >>>> Poonam >>>> From poonam.bajaj at oracle.com Thu Aug 10 18:55:15 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Thu, 10 Aug 2017 11:55:15 -0700 (PDT) Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines In-Reply-To: <80530dcf-57f4-8d8f-e084-360e770520a6@oracle.com> References: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> <0285fdb7-8548-48e5-b019-3de62f66cffe@default> <80530dcf-57f4-8d8f-e084-360e770520a6@oracle.com> Message-ID: Updated the webrev with comments: http://cr.openjdk.java.net/~poonam/8185572/webrev.01/ Thanks, Poonam > -----Original Message----- > From: Vladimir Kozlov > Sent: Thursday, August 10, 2017 11:24 AM > To: hotspot-compiler-dev at openjdk.java.net; Poonam Bajaj Parhar > Cc: hotspot-runtime-dev at openjdk.java.net runtime > Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC > machines > > Poonam, > > I mean to add a small (one or two sentences) comment to the code. Some > thing like next but may better wording: > > + if (FLAG_IS_DEFAULT(AssumeMP)) { > + // BIS instructions require 'membar' instruction regardless number > of CPU. > + // Otherwise in virtualized/container environments which use only > 1 > cpu BIS instructions may produce incorrect results. > + FLAG_SET_DEFAULT(AssumeMP, true); > > Thanks, > Vladimir > > On 8/10/17 10:44 AM, Poonam Parhar wrote: > > Thanks Vladimir. > > > > Since the SPARC machines are always multi-cores, we can safely set > AssumeMP to true on these. > > > > Adding my comments from the previous mail here again for better > readability: > > ------------------------------------- > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185572: Enable > AssumeMP > > by default on SPARC machines > > Webrev: http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ > > > > This change enables AssumeMP by default on SPARC machines. On Sparc > T7, to finalize BIS instructions the server compiler needs to add a > 'membar' instruction at the end. But the generation of 'membar' is > guarded by os::is_MP(), and os::is_MP() returns false when there is a > single cpu available on the system. Now, in virtualized/container > environments, the number of processors allocated to a virtual machine > can dynamically change during the application runtime. That could lead > to incorrect generation of BIS instructions and can cause JVM crashes. > Enabling AssumeMP makes is_MP() always return true on SPARC systems. > > > > In future, we may consider making generation of 'membar' > unconditional with the enhancement request: > https://bugs.openjdk.java.net/browse/JDK-8150715. > > > > Thanks, > > Poonam > > > > > >> -----Original Message----- > >> From: Vladimir Kozlov > >> Sent: Thursday, August 10, 2017 9:47 AM > >> To: Poonam Parhar; hotspot-compiler-dev at openjdk.java.net > >> Cc: hotspot-runtime-dev at openjdk.java.net runtime > >> Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on > >> SPARC machines > >> > >> CCing to Runtime. > >> > >> Can you add comment explaining why it set to true on SPARC? > >> > >> Thanks, > >> Vladimir > >> > >> On 8/10/17 6:26 AM, Poonam Parhar wrote: > >>> Hello, > >>> > >>> Please review this simple patch: > >>> > >>> Bug:_JDK-8185572_ >> 8185572>:En > >>> able > >>> AssumeMP by default on SPARC machines > >>> > >>> Webrev:http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ > >>> > >>> This change enables AssumeMP by default on SPARC machines. On Sparc > >>> T7, to finalize BIS instructions the server compiler needs toadd > >>> a'membar'instruction at the end.But the generation of'membar'is > >>> guarded byos::is_MP(), andos::is_MP()returns false when there isa > >>> singlecpu available on the system. > >>> Now,invirtualized/containerenvironments, the number > >>> ofprocessorsallocated to a virtual machine can dynamically change > >>> during the application runtime.That could lead to incorrect > >> generation > >>> of BIS instructions and can cause JVM crashes.Enabling AssumeMP > >>> makes > >>> is_MP() always return true on SPARC systems. > >>> > >>> In future, we may consider makinggeneration of'membar'unconditional > >>> withtheenhancementrequest:_JDK- > >> 8150715_. > >>> > >>> Thanks, > >>> > >>> Poonam > >>> From vladimir.kozlov at oracle.com Thu Aug 10 19:10:37 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Aug 2017 12:10:37 -0700 Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines In-Reply-To: <38ABC51B-73E3-4DEF-B5E1-B44B8B25160D@oracle.com> References: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> <0285fdb7-8548-48e5-b019-3de62f66cffe@default> <80530dcf-57f4-8d8f-e084-360e770520a6@oracle.com> <38ABC51B-73E3-4DEF-B5E1-B44B8B25160D@oracle.com> Message-ID: <58512f71-b5e6-f2b0-f99e-005c239e911e@oracle.com> Bob, we have JDK-8185062 for that: https://bugs.openjdk.java.net/browse/JDK-8185062 IMHO this fix is intended for backports, should be simple and don't cause regression, for example on embedded platforms. But I am fine if runtime group think it is fine to enable it on all platforms in jdk 7, 8 and 9. I agree that due to problem with dynamic cpus configuration in containers it may be good to enable it on all platforms in previous releases too. Thanks, Vladimir On 8/10/17 11:53 AM, Bob Vandette wrote: > Can we just always run with AssumeMP true for all platforms these days? > Surely single CPU systems are rare now. > > We might have issues with Docker containers that have a limit 1 CPU > on a large mp system which may cause issues. > > Bob. > > >> On Aug 10, 2017, at 2:23 PM, Vladimir Kozlov wrote: >> >> Poonam, >> >> I mean to add a small (one or two sentences) comment to the code. Some thing like next but may better wording: >> >> + if (FLAG_IS_DEFAULT(AssumeMP)) { >> + // BIS instructions require 'membar' instruction regardless number of CPU. >> + // Otherwise in virtualized/container environments which use only 1 cpu BIS instructions may produce incorrect results. >> + FLAG_SET_DEFAULT(AssumeMP, true); >> >> Thanks, >> Vladimir >> >> On 8/10/17 10:44 AM, Poonam Parhar wrote: >>> Thanks Vladimir. >>> Since the SPARC machines are always multi-cores, we can safely set AssumeMP to true on these. >>> Adding my comments from the previous mail here again for better readability: >>> ------------------------------------- >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8185572: Enable AssumeMP by default on SPARC machines >>> Webrev: http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >>> This change enables AssumeMP by default on SPARC machines. On Sparc T7, to finalize BIS instructions the server compiler needs to add a 'membar' instruction at the end. But the generation of 'membar' is guarded by os::is_MP(), and os::is_MP() returns false when there is a single cpu available on the system. Now, in virtualized/container environments, the number of processors allocated to a virtual machine can dynamically change during the application runtime. That could lead to incorrect generation of BIS instructions and can cause JVM crashes. Enabling AssumeMP makes is_MP() always return true on SPARC systems. >>> In future, we may consider making generation of 'membar' unconditional with the enhancement request: https://bugs.openjdk.java.net/browse/JDK-8150715. >>> Thanks, >>> Poonam >>>> -----Original Message----- >>>> From: Vladimir Kozlov >>>> Sent: Thursday, August 10, 2017 9:47 AM >>>> To: Poonam Parhar; hotspot-compiler-dev at openjdk.java.net >>>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >>>> Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC >>>> machines >>>> >>>> CCing to Runtime. >>>> >>>> Can you add comment explaining why it set to true on SPARC? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/10/17 6:26 AM, Poonam Parhar wrote: >>>>> Hello, >>>>> >>>>> Please review this simple patch: >>>>> >>>>> Bug:_JDK-8185572_>>> 8185572>:En >>>>> able >>>>> AssumeMP by default on SPARC machines >>>>> >>>>> Webrev:http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >>>>> >>>>> This change enables AssumeMP by default on SPARC machines. On Sparc >>>>> T7, to finalize BIS instructions the server compiler needs toadd >>>>> a'membar'instruction at the end.But the generation of'membar'is >>>>> guarded byos::is_MP(), andos::is_MP()returns false when there isa >>>>> singlecpu available on the system. >>>>> Now,invirtualized/containerenvironments, the number >>>>> ofprocessorsallocated to a virtual machine can dynamically change >>>>> during the application runtime.That could lead to incorrect >>>> generation >>>>> of BIS instructions and can cause JVM crashes.Enabling AssumeMP makes >>>>> is_MP() always return true on SPARC systems. >>>>> >>>>> In future, we may consider makinggeneration of'membar'unconditional >>>>> withtheenhancementrequest:_JDK- >>>> 8150715_. >>>>> >>>>> Thanks, >>>>> >>>>> Poonam >>>>> > From vladimir.kozlov at oracle.com Thu Aug 10 19:11:39 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Aug 2017 12:11:39 -0700 Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines In-Reply-To: References: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> <0285fdb7-8548-48e5-b019-3de62f66cffe@default> <80530dcf-57f4-8d8f-e084-360e770520a6@oracle.com> Message-ID: <72e1f78f-595c-b25f-e30f-98fd62f66093@oracle.com> Looks good. I think someone from Runtime have to review it too. Thanks, Vladimir On 8/10/17 11:55 AM, Poonam Parhar wrote: > Updated the webrev with comments: > http://cr.openjdk.java.net/~poonam/8185572/webrev.01/ > > Thanks, > Poonam > > >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: Thursday, August 10, 2017 11:24 AM >> To: hotspot-compiler-dev at openjdk.java.net; Poonam Bajaj Parhar >> Cc: hotspot-runtime-dev at openjdk.java.net runtime >> Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC >> machines >> >> Poonam, >> >> I mean to add a small (one or two sentences) comment to the code. Some >> thing like next but may better wording: >> >> + if (FLAG_IS_DEFAULT(AssumeMP)) { >> + // BIS instructions require 'membar' instruction regardless number >> of CPU. >> + // Otherwise in virtualized/container environments which use only >> 1 >> cpu BIS instructions may produce incorrect results. >> + FLAG_SET_DEFAULT(AssumeMP, true); >> >> Thanks, >> Vladimir >> >> On 8/10/17 10:44 AM, Poonam Parhar wrote: >>> Thanks Vladimir. >>> >>> Since the SPARC machines are always multi-cores, we can safely set >> AssumeMP to true on these. >>> >>> Adding my comments from the previous mail here again for better >> readability: >>> ------------------------------------- >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8185572: Enable >> AssumeMP >>> by default on SPARC machines >>> Webrev: http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >>> >>> This change enables AssumeMP by default on SPARC machines. On Sparc >> T7, to finalize BIS instructions the server compiler needs to add a >> 'membar' instruction at the end. But the generation of 'membar' is >> guarded by os::is_MP(), and os::is_MP() returns false when there is a >> single cpu available on the system. Now, in virtualized/container >> environments, the number of processors allocated to a virtual machine >> can dynamically change during the application runtime. That could lead >> to incorrect generation of BIS instructions and can cause JVM crashes. >> Enabling AssumeMP makes is_MP() always return true on SPARC systems. >>> >>> In future, we may consider making generation of 'membar' >> unconditional with the enhancement request: >> https://bugs.openjdk.java.net/browse/JDK-8150715. >>> >>> Thanks, >>> Poonam >>> >>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov >>>> Sent: Thursday, August 10, 2017 9:47 AM >>>> To: Poonam Parhar; hotspot-compiler-dev at openjdk.java.net >>>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >>>> Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on >>>> SPARC machines >>>> >>>> CCing to Runtime. >>>> >>>> Can you add comment explaining why it set to true on SPARC? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/10/17 6:26 AM, Poonam Parhar wrote: >>>>> Hello, >>>>> >>>>> Please review this simple patch: >>>>> >>>>> Bug:_JDK-8185572_>>> 8185572>:En >>>>> able >>>>> AssumeMP by default on SPARC machines >>>>> >>>>> Webrev:http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >>>>> >>>>> This change enables AssumeMP by default on SPARC machines. On Sparc >>>>> T7, to finalize BIS instructions the server compiler needs toadd >>>>> a'membar'instruction at the end.But the generation of'membar'is >>>>> guarded byos::is_MP(), andos::is_MP()returns false when there isa >>>>> singlecpu available on the system. >>>>> Now,invirtualized/containerenvironments, the number >>>>> ofprocessorsallocated to a virtual machine can dynamically change >>>>> during the application runtime.That could lead to incorrect >>>> generation >>>>> of BIS instructions and can cause JVM crashes.Enabling AssumeMP >>>>> makes >>>>> is_MP() always return true on SPARC systems. >>>>> >>>>> In future, we may consider makinggeneration of'membar'unconditional >>>>> withtheenhancementrequest:_JDK- >>>> 8150715_. >>>>> >>>>> Thanks, >>>>> >>>>> Poonam >>>>> From bob.vandette at oracle.com Thu Aug 10 19:13:46 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 10 Aug 2017 15:13:46 -0400 Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines In-Reply-To: <58512f71-b5e6-f2b0-f99e-005c239e911e@oracle.com> References: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> <0285fdb7-8548-48e5-b019-3de62f66cffe@default> <80530dcf-57f4-8d8f-e084-360e770520a6@oracle.com> <38ABC51B-73E3-4DEF-B5E1-B44B8B25160D@oracle.com> <58512f71-b5e6-f2b0-f99e-005c239e911e@oracle.com> Message-ID: I don?t think that we should backport it to JDK 7 and 8 since older single CPU systems may get a security update for these older releases and see a performance regression. Perhaps JDK9 and 10 would be ok. Bob. > On Aug 10, 2017, at 3:10 PM, Vladimir Kozlov wrote: > > Bob, we have JDK-8185062 for that: > > https://bugs.openjdk.java.net/browse/JDK-8185062 > > IMHO this fix is intended for backports, should be simple and don't cause regression, for example on embedded platforms. > > But I am fine if runtime group think it is fine to enable it on all platforms in jdk 7, 8 and 9. > > I agree that due to problem with dynamic cpus configuration in containers it may be good to enable it on all platforms in previous releases too. > > Thanks, > Vladimir > > On 8/10/17 11:53 AM, Bob Vandette wrote: >> Can we just always run with AssumeMP true for all platforms these days? >> Surely single CPU systems are rare now. >> We might have issues with Docker containers that have a limit 1 CPU >> on a large mp system which may cause issues. >> Bob. >>> On Aug 10, 2017, at 2:23 PM, Vladimir Kozlov wrote: >>> >>> Poonam, >>> >>> I mean to add a small (one or two sentences) comment to the code. Some thing like next but may better wording: >>> >>> + if (FLAG_IS_DEFAULT(AssumeMP)) { >>> + // BIS instructions require 'membar' instruction regardless number of CPU. >>> + // Otherwise in virtualized/container environments which use only 1 cpu BIS instructions may produce incorrect results. >>> + FLAG_SET_DEFAULT(AssumeMP, true); >>> >>> Thanks, >>> Vladimir >>> >>> On 8/10/17 10:44 AM, Poonam Parhar wrote: >>>> Thanks Vladimir. >>>> Since the SPARC machines are always multi-cores, we can safely set AssumeMP to true on these. >>>> Adding my comments from the previous mail here again for better readability: >>>> ------------------------------------- >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8185572: Enable AssumeMP by default on SPARC machines >>>> Webrev: http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >>>> This change enables AssumeMP by default on SPARC machines. On Sparc T7, to finalize BIS instructions the server compiler needs to add a 'membar' instruction at the end. But the generation of 'membar' is guarded by os::is_MP(), and os::is_MP() returns false when there is a single cpu available on the system. Now, in virtualized/container environments, the number of processors allocated to a virtual machine can dynamically change during the application runtime. That could lead to incorrect generation of BIS instructions and can cause JVM crashes. Enabling AssumeMP makes is_MP() always return true on SPARC systems. >>>> In future, we may consider making generation of 'membar' unconditional with the enhancement request: https://bugs.openjdk.java.net/browse/JDK-8150715. >>>> Thanks, >>>> Poonam >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov >>>>> Sent: Thursday, August 10, 2017 9:47 AM >>>>> To: Poonam Parhar; hotspot-compiler-dev at openjdk.java.net >>>>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >>>>> Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC >>>>> machines >>>>> >>>>> CCing to Runtime. >>>>> >>>>> Can you add comment explaining why it set to true on SPARC? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/10/17 6:26 AM, Poonam Parhar wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this simple patch: >>>>>> >>>>>> Bug:_JDK-8185572_>>>> 8185572>:En >>>>>> able >>>>>> AssumeMP by default on SPARC machines >>>>>> >>>>>> Webrev:http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >>>>>> >>>>>> This change enables AssumeMP by default on SPARC machines. On Sparc >>>>>> T7, to finalize BIS instructions the server compiler needs toadd >>>>>> a'membar'instruction at the end.But the generation of'membar'is >>>>>> guarded byos::is_MP(), andos::is_MP()returns false when there isa >>>>>> singlecpu available on the system. >>>>>> Now,invirtualized/containerenvironments, the number >>>>>> ofprocessorsallocated to a virtual machine can dynamically change >>>>>> during the application runtime.That could lead to incorrect >>>>> generation >>>>>> of BIS instructions and can cause JVM crashes.Enabling AssumeMP makes >>>>>> is_MP() always return true on SPARC systems. >>>>>> >>>>>> In future, we may consider makinggeneration of'membar'unconditional >>>>>> withtheenhancementrequest:_JDK- >>>>> 8150715_. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Poonam >>>>>> From goetz.lindenmaier at sap.com Thu Aug 10 19:57:43 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 10 Aug 2017 19:57:43 +0000 Subject: [10] RFR(XS): 8185975: PPC64: Fix vsldoi interface according to the ISA In-Reply-To: <3f27fa9658014b87b03a46570b2d9f8f@serv031.corp.eldorado.org.br> References: <1772227f57984a6184ad0704e7e6474d@sap.com> <3f27fa9658014b87b03a46570b2d9f8f@serv031.corp.eldorado.org.br> Message-ID: <3e0f9a4d39b0450197329bf2b29b7eae@sap.com> Looks good, Thanks, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: Thursday, August 10, 2017 7:20 PM > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: FW: [10] RFR(XS): 8185975: PPC64: Fix vsldoi interface according to > the ISA > > > > -----Original Message----- > From: Doerr, Martin [mailto:martin.doerr at sap.com] > Sent: quarta-feira, 9 de agosto de 2017 09:14 > To: Gustavo Serra Scalet ; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: [10] RFR(XS): 8185975: PPC64: Fix vsldoi interface according to > the ISA > > Hi Gustavo, > > thanks for the webrev. Looks good. I'd only like to rename si4 to ui4. But I > can do that before pushing (no need for new webrev). > > Best regards, > Martin > > > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] > On Behalf Of Gustavo Serra Scalet > Sent: Dienstag, 8. August 2017 22:19 > To: ppc-aix-port-dev at openjdk.java.net > Subject: [10] RFR(XS): 8185975: PPC64: Fix vsldoi interface according to the > ISA > > Hi, > > Could you please review this specific PPC64 change to hotspot? It was > previously discussed with Martin Doerr on [1]. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185975 > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185975/webrev/ > > Best regards, > Gustavo Serra Scalet > > [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017- > February/002913.html From poonam.bajaj at oracle.com Thu Aug 10 21:32:39 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Thu, 10 Aug 2017 14:32:39 -0700 (PDT) Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines In-Reply-To: References: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> <0285fdb7-8548-48e5-b019-3de62f66cffe@default> <80530dcf-57f4-8d8f-e084-360e770520a6@oracle.com> <38ABC51B-73E3-4DEF-B5E1-B44B8B25160D@oracle.com> <58512f71-b5e6-f2b0-f99e-005c239e911e@oracle.com> Message-ID: <10fb6c8d-104d-4fc3-94e3-e82db3fa8273@default> We have customer reports of crashes with 8u on T7 sparc systems. So the change needs to be made in 8, and possibly in 7 too. Thanks, Poonam > -----Original Message----- > From: Bob Vandette > Sent: Thursday, August 10, 2017 12:14 PM > To: Vladimir Kozlov > Cc: hotspot-compiler-dev at openjdk.java.net; Poonam Bajaj Parhar; > hotspot-runtime-dev at openjdk.java.net runtime > Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC > machines > > I don?t think that we should backport it to JDK 7 and 8 since older > single CPU systems may get a security update for these older releases > and see a performance regression. > Perhaps JDK9 and 10 would be ok. > > Bob. > > > > On Aug 10, 2017, at 3:10 PM, Vladimir Kozlov > wrote: > > > > Bob, we have JDK-8185062 for that: > > > > https://bugs.openjdk.java.net/browse/JDK-8185062 > > > > IMHO this fix is intended for backports, should be simple and don't > cause regression, for example on embedded platforms. > > > > But I am fine if runtime group think it is fine to enable it on all > platforms in jdk 7, 8 and 9. > > > > I agree that due to problem with dynamic cpus configuration in > containers it may be good to enable it on all platforms in previous > releases too. > > > > Thanks, > > Vladimir > > > > On 8/10/17 11:53 AM, Bob Vandette wrote: > >> Can we just always run with AssumeMP true for all platforms these > days? > >> Surely single CPU systems are rare now. > >> We might have issues with Docker containers that have a limit 1 CPU > >> on a large mp system which may cause issues. > >> Bob. > >>> On Aug 10, 2017, at 2:23 PM, Vladimir Kozlov > wrote: > >>> > >>> Poonam, > >>> > >>> I mean to add a small (one or two sentences) comment to the code. > Some thing like next but may better wording: > >>> > >>> + if (FLAG_IS_DEFAULT(AssumeMP)) { > >>> + // BIS instructions require 'membar' instruction regardless > number of CPU. > >>> + // Otherwise in virtualized/container environments which use > only 1 cpu BIS instructions may produce incorrect results. > >>> + FLAG_SET_DEFAULT(AssumeMP, true); > >>> > >>> Thanks, > >>> Vladimir > >>> > >>> On 8/10/17 10:44 AM, Poonam Parhar wrote: > >>>> Thanks Vladimir. > >>>> Since the SPARC machines are always multi-cores, we can safely set > AssumeMP to true on these. > >>>> Adding my comments from the previous mail here again for better > readability: > >>>> ------------------------------------- > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8185572: Enable > >>>> AssumeMP by default on SPARC machines > >>>> Webrev: http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ > >>>> This change enables AssumeMP by default on SPARC machines. On > Sparc T7, to finalize BIS instructions the server compiler needs to add > a 'membar' instruction at the end. But the generation of 'membar' is > guarded by os::is_MP(), and os::is_MP() returns false when there is a > single cpu available on the system. Now, in virtualized/container > environments, the number of processors allocated to a virtual machine > can dynamically change during the application runtime. That could lead > to incorrect generation of BIS instructions and can cause JVM crashes. > Enabling AssumeMP makes is_MP() always return true on SPARC systems. > >>>> In future, we may consider making generation of 'membar' > unconditional with the enhancement request: > https://bugs.openjdk.java.net/browse/JDK-8150715. > >>>> Thanks, > >>>> Poonam > >>>>> -----Original Message----- > >>>>> From: Vladimir Kozlov > >>>>> Sent: Thursday, August 10, 2017 9:47 AM > >>>>> To: Poonam Parhar; hotspot-compiler-dev at openjdk.java.net > >>>>> Cc: hotspot-runtime-dev at openjdk.java.net runtime > >>>>> Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on > >>>>> SPARC machines > >>>>> > >>>>> CCing to Runtime. > >>>>> > >>>>> Can you add comment explaining why it set to true on SPARC? > >>>>> > >>>>> Thanks, > >>>>> Vladimir > >>>>> > >>>>> On 8/10/17 6:26 AM, Poonam Parhar wrote: > >>>>>> Hello, > >>>>>> > >>>>>> Please review this simple patch: > >>>>>> > >>>>>> Bug:_JDK-8185572_ >>>>> 8185572>:En > >>>>>> able > >>>>>> AssumeMP by default on SPARC machines > >>>>>> > >>>>>> Webrev:http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ > >>>>>> > >>>>>> This change enables AssumeMP by default on SPARC machines. On > >>>>>> Sparc T7, to finalize BIS instructions the server compiler needs > >>>>>> toadd a'membar'instruction at the end.But the generation > >>>>>> of'membar'is guarded byos::is_MP(), andos::is_MP()returns false > >>>>>> when there isa singlecpu available on the system. > >>>>>> Now,invirtualized/containerenvironments, the number > >>>>>> ofprocessorsallocated to a virtual machine can dynamically > change > >>>>>> during the application runtime.That could lead to incorrect > >>>>> generation > >>>>>> of BIS instructions and can cause JVM crashes.Enabling AssumeMP > >>>>>> makes > >>>>>> is_MP() always return true on SPARC systems. > >>>>>> > >>>>>> In future, we may consider makinggeneration > >>>>>> of'membar'unconditional > >>>>>> withtheenhancementrequest:_JDK- > >>>>> 8150715_. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Poonam > >>>>>> > From david.holmes at oracle.com Thu Aug 10 21:57:24 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Aug 2017 07:57:24 +1000 Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines In-Reply-To: <0285fdb7-8548-48e5-b019-3de62f66cffe@default> References: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> <0285fdb7-8548-48e5-b019-3de62f66cffe@default> Message-ID: <46b484c8-e080-8c6a-a6bb-8471ce5efd9f@oracle.com> Hi Poonam, On 11/08/2017 3:44 AM, Poonam Parhar wrote: > Thanks Vladimir. > > Since the SPARC machines are always multi-cores, we can safely set AssumeMP to true on these. I'm still unclear about the reported problem here. As Vladimir pointed out in the bug report the is_MP checks uses _processor_count which is set to the number of cpus on the machine _not_ the number of cpus currently available to the VM. void os::Solaris::initialize_system_info() { set_processor_count(sysconf(_SC_NPROCESSORS_CONF)); So all this discussion about containers and dynamic changes to available cpus should be moot. So the only way this can fail is if the number of configured processors on the machine dynamically changed _and_ it was initially 1 - which seems to me to be impossible with sparc unless the hardware info is being incorrectly reported (ie virtualization bug?) That aside I have no issue with the fix as we will likely be assuming MP always in the future. Thanks, David > Adding my comments from the previous mail here again for better readability: > ------------------------------------- > Bug: https://bugs.openjdk.java.net/browse/JDK-8185572: Enable AssumeMP by default on SPARC machines > Webrev: http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ > > This change enables AssumeMP by default on SPARC machines. On Sparc T7, to finalize BIS instructions the server compiler needs to add a 'membar' instruction at the end. But the generation of 'membar' is guarded by os::is_MP(), and os::is_MP() returns false when there is a single cpu available on the system. Now, in virtualized/container environments, the number of processors allocated to a virtual machine can dynamically change during the application runtime. That could lead to incorrect generation of BIS instructions and can cause JVM crashes. Enabling AssumeMP makes is_MP() always return true on SPARC systems. > > In future, we may consider making generation of 'membar' unconditional with the enhancement request: https://bugs.openjdk.java.net/browse/JDK-8150715. > > Thanks, > Poonam > > >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: Thursday, August 10, 2017 9:47 AM >> To: Poonam Parhar; hotspot-compiler-dev at openjdk.java.net >> Cc: hotspot-runtime-dev at openjdk.java.net runtime >> Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC >> machines >> >> CCing to Runtime. >> >> Can you add comment explaining why it set to true on SPARC? >> >> Thanks, >> Vladimir >> >> On 8/10/17 6:26 AM, Poonam Parhar wrote: >>> Hello, >>> >>> Please review this simple patch: >>> >>> Bug:_JDK-8185572_> 8185572>:En >>> able >>> AssumeMP by default on SPARC machines >>> >>> Webrev:http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >>> >>> This change enables AssumeMP by default on SPARC machines. On Sparc >>> T7, to finalize BIS instructions the server compiler needs toadd >>> a'membar'instruction at the end.But the generation of'membar'is >>> guarded byos::is_MP(), andos::is_MP()returns false when there isa >>> singlecpu available on the system. >>> Now,invirtualized/containerenvironments, the number >>> ofprocessorsallocated to a virtual machine can dynamically change >>> during the application runtime.That could lead to incorrect >> generation >>> of BIS instructions and can cause JVM crashes.Enabling AssumeMP makes >>> is_MP() always return true on SPARC systems. >>> >>> In future, we may consider makinggeneration of'membar'unconditional >>> withtheenhancementrequest:_JDK- >> 8150715_. >>> >>> Thanks, >>> >>> Poonam >>> From igor.ignatyev at oracle.com Thu Aug 10 23:33:58 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 10 Aug 2017 16:33:58 -0700 Subject: RFR(S): 8174202 : jtreg AOT tests should not assume library extension of .so Message-ID: <0E750D7A-FEC4-4D3A-96F2-A917BA5271F3@oracle.com> http://cr.openjdk.java.net/~iignatyev//8174202/webrev.00/index.html > 67 lines changed: 47 ins; 11 del; 9 mod; Hi all, could you please review this small fix? problem: some of aot tests assumed that output file is named unnamed.so regardless the platform. the problem was worked around in jaotc tool. fix: the workaround was removed and now we use platform-specific extension for default output name. it's unnamed.dll on windows, unnamed.dylib on mac and unnamed.so on all other platforms. the tests have been updated correspondingly. webrev: http://cr.openjdk.java.net/~iignatyev//8174202/webrev.00/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8174202 testing: hotspot/compiler/aot (w/ 8183337[1] applied) on all supported platforms [1] http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html Thanks, -- Igor From vladimir.kozlov at oracle.com Fri Aug 11 00:24:31 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Aug 2017 17:24:31 -0700 Subject: RFR(S): 8174202 : jtreg AOT tests should not assume library extension of .so In-Reply-To: <0E750D7A-FEC4-4D3A-96F2-A917BA5271F3@oracle.com> References: <0E750D7A-FEC4-4D3A-96F2-A917BA5271F3@oracle.com> Message-ID: <9a04dbb2-ea60-157c-1db7-f9fc522c431a@oracle.com> Good. Thanks, Vladimir On 8/10/17 4:33 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8174202/webrev.00/index.html >> 67 lines changed: 47 ins; 11 del; 9 mod; > > Hi all, > > could you please review this small fix? > > problem: some of aot tests assumed that output file is named unnamed.so regardless the platform. the problem was worked around in jaotc tool. > fix: the workaround was removed and now we use platform-specific extension for default output name. it's unnamed.dll on windows, unnamed.dylib on mac and unnamed.so on all other platforms. > the tests have been updated correspondingly. > > webrev: http://cr.openjdk.java.net/~iignatyev//8174202/webrev.00/index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8174202 > testing: hotspot/compiler/aot (w/ 8183337[1] applied) on all supported platforms > > [1] http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Fri Aug 11 02:11:06 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 10 Aug 2017 19:11:06 -0700 Subject: RFR(S): 8174202 : jtreg AOT tests should not assume library extension of .so In-Reply-To: <9a04dbb2-ea60-157c-1db7-f9fc522c431a@oracle.com> References: <0E750D7A-FEC4-4D3A-96F2-A917BA5271F3@oracle.com> <9a04dbb2-ea60-157c-1db7-f9fc522c431a@oracle.com> Message-ID: <452C6FE2-3F66-42D4-B741-10612F561197@oracle.com> Thank you Vladimir. I've found a couple of copy-paste errors in jdk/tools/jaotc/Main.java, I always used '.so' substringing output filename to object filename. > --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Main.java Thu Aug 10 14:23:51 2017 -0700 > +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Main.java Thu Aug 10 19:07:31 2017 -0700 > @@ -577,7 +577,7 @@ > break; > case "Mac OS X": > if (name.endsWith(".dylib")) { > - objectFileName = name.substring(0, name.length() - ".so".length()); > + objectFileName = name.substring(0, name.length() - ".dylib".length()); > } > objectFileName = objectFileName + ".o"; > linkerPath = (options.linkerpath != null) ? options.linkerpath : "ld"; > @@ -586,7 +586,7 @@ > default: > if (osName.startsWith("Windows")) { > if (name.endsWith(".dll")) { > - objectFileName = name.substring(0, name.length() - ".so".length()); > + objectFileName = name.substring(0, name.length() - ".dll".length()); > } > objectFileName = objectFileName + ".obj"; > linkerPath = (options.linkerpath != null) ? options.linkerpath : getWindowsLinkPath(); Thanks, -- Igor > On Aug 10, 2017, at 5:24 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 8/10/17 4:33 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8174202/webrev.00/index.html >>> 67 lines changed: 47 ins; 11 del; 9 mod; >> Hi all, >> could you please review this small fix? >> problem: some of aot tests assumed that output file is named unnamed.so regardless the platform. the problem was worked around in jaotc tool. >> fix: the workaround was removed and now we use platform-specific extension for default output name. it's unnamed.dll on windows, unnamed.dylib on mac and unnamed.so on all other platforms. >> the tests have been updated correspondingly. >> webrev: http://cr.openjdk.java.net/~iignatyev//8174202/webrev.00/index.html >> jbs: https://bugs.openjdk.java.net/browse/JDK-8174202 >> testing: hotspot/compiler/aot (w/ 8183337[1] applied) on all supported platforms >> [1] http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >> Thanks, >> -- Igor From 515248659 at qq.com Fri Aug 11 03:59:24 2017 From: 515248659 at qq.com (Chenxi Wang) Date: Fri, 11 Aug 2017 11:59:24 +0800 Subject: Some doubts about the LIR Operand In-Reply-To: References: Message-ID: I think I know the reason. This crash is caused by the wrong type assigned to arguments. Some times, the object.result() can be T_INT, so it?s better to assign T_OBJECT as the parameter type. ? ? BasicTypeList signature; ? // ?signature.append(NOT_LP64(T_INT) LP64_ONLY(T_LONG)); ?// 1st argument, HeapWord* src_addr, ? ? signature.append(T_OBJECT); ?// 1st argument,? ? ? signature.append(T_OBJECT); ?// 2nd argument,? ? ? CallingConvention* cc = frame_map()->c_calling_convention(&signature); ? ? __ move(object.result(), cc->args()->at(0)); ? ? ? ?? ? ? __ move(value.result(), cc->args()->at(1)); ? ? ?? ? ? __ call_runtime_leaf( CAST_FROM_FN_PTR(u_char*, Runtime1::debug_function), getThreadTemp(), LIR_OprFact::illegalOpr,cc->args()); I?m new here. If I asked questions in a wrong way, please tell me. I will correct it. Thank you for your help. On 5 August 2017 at 12:29:44 AM, QQ mail (515248659 at qq.com) wrote: Hi all,? I want to Insert a runtime function to print the StoreField's write barrier information produced by C1 compiler. But it seems that the passed LIR operands sometimes crash the hotspot. Details: First I write a debug function to print the values: jdk8u/hotspot/src/share/vm/c1/c1_Runtime1.cpp JRT_LEAF(void, Runtime1::debug_function(HeapWord* field_addr, HeapWord* target_addr)) ? tty->print(" C1 : after ?decode: src addr: %#lx , dst addr: %#lx \n",(unsigned long)field_addr, (unsigned long)target_addr); JRT_END Then, I build a runtime function invoke ?in :?void LIRGenerator::do_StoreField(StoreField* x) , just after the post_barrier() . The source code: jdk8u/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp void LIRGenerator::do_StoreField(StoreField* x) { ? bool needs_patching = x->needs_patching(); ? bool is_volatile = x->field()->is_volatile(); ? BasicType field_type = x->field_type(); ? bool is_oop = (field_type == T_ARRAY || field_type == T_OBJECT); ? CodeEmitInfo* info = NULL; ? if (needs_patching) { ? ? assert(x->explicit_null_check() == NULL, "can't fold null check into patching field access"); ? ? info = state_for(x, x->state_before()); ? } else if (x->needs_null_check()) { ? ? NullCheck* nc = x->explicit_null_check(); ? ? if (nc == NULL) { ? ? ? info = state_for(x); ? ? } else { ? ? ? info = state_for(nc); ? ? } ? } ? LIRItem object(x->obj(), this); ? LIRItem value(x->value(), ?this); ? object.load_item(); ? if (is_volatile || needs_patching) { ? ? // load item if field is volatile (fewer special cases for volatiles) ? ? // load item if field not initialized ? ? // load item if field not constant ? ? // because of code patching we cannot inline constants ? ? if (field_type == T_BYTE || field_type == T_BOOLEAN) { ? ? ? value.load_byte_item(); ? ? } else ?{ ? ? ? value.load_item(); ? ? } ? } else { ? ? value.load_for_store(field_type); ? } ? set_no_result(x); #ifndef PRODUCT ? if (PrintNotLoaded && needs_patching) { ? ? tty->print_cr(" ? ###class not loaded at store_%s bci %d", ? ? ? ? ? ? ? ? ? x->is_static() ? ?"static" : "field", x->printable_bci()); ? } #endif ? if (x->needs_null_check() && ? ? ? (needs_patching || ? ? ? ?MacroAssembler::needs_explicit_null_check(x->offset()))) { ? ? // emit an explicit null check because the offset is too large ? ? __ null_check(object.result(), new CodeEmitInfo(info)); ? } ? LIR_Address* address; ? if (needs_patching) { ? ? // we need to patch the offset in the instruction so don't allow ? ? // generate_address to try to be smart about emitting the -1. ? ? // Otherwise the patching code won't know how to find the ? ? // instruction to patch. ? ? address = new LIR_Address(object.result(), PATCHED_ADDR, field_type); ? } else { ? ? address = generate_address(object.result(), x->offset(), field_type); ? } ? if (is_volatile && os::is_MP()) { ? ? __ membar_release(); ? } ? if (is_oop) { ? ? // Do the pre-write barrier, if any. ? ? pre_barrier(LIR_OprFact::address(address), ? ? ? ? ? ? ? ? LIR_OprFact::illegalOpr /* pre_val */, ? ? ? ? ? ? ? ? true /* do_load*/, ? ? ? ? ? ? ? ? needs_patching, ? ? ? ? ? ? ? ? (info ? new CodeEmitInfo(info) : NULL)); ? } ? if (is_volatile && !needs_patching) { ? ? volatile_field_store(value.result(), address, info); ? } else { ? ? LIR_PatchCode patch_code = needs_patching ? lir_patch_normal : lir_patch_none; ? ? __ store(value.result(), address, info, patch_code); ? } ? if (is_oop) { ? ? // Store to object so mark the card of the header ? ? post_barrier(object.result(), value.result()); ? ? ? //debug ? ? BasicTypeList signature; ? ? signature.append(NOT_LP64(T_INT) LP64_ONLY(T_LONG)); ?// 1st argument, HeapWord* src_addr, ? ? signature.append(NOT_LP64(T_INT) LP64_ONLY(T_LONG)); ?// 2nd argument, HeapWord* target_addr, ? ? CallingConvention* cc = frame_map()->c_calling_convention(&signature); ? ? __ move(object.result(), cc->args()->at(0)); ? ? ? ? ?// &obj.field ?-> 1st arg ? ? __ move(value.result(), cc->args()->at(1)); ? ? ? ? ? // target addr -> 2nd arg ? ? __ call_runtime_leaf( CAST_FROM_FN_PTR(u_char*, Runtime1::debug_function), getThreadTemp(), LIR_OprFact::illegalOpr,cc->args()); ?? ? } ? if (is_volatile && os::is_MP()) { ? ? __ membar(); ? } } Then it sometimes crashes and print the call stack: (gdb) bt #0 ?0x00007ffff7a47c37 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 ?0x00007ffff7a4b028 in __GI_abort () at abort.c:89 #2 ?0x00007ffff6ce804a in os::abort (dump_core=true) at /home2/spark06/jdk8u/hotspot/src/os/linux/vm/os_linux.cpp:1496 #3 ?0x00007ffff6eb4ba2 in VMError::report_and_die (this=0x7fff7b9f7e90) at /home2/spark06/jdk8u/hotspot/src/share/vm/utilities/vmError.cpp:1060 #4 ?0x00007ffff684647b in report_vm_error (file=0x7ffff6f610f0 "/home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.hpp", line=420, error_msg=0x7ffff6f612a8 "assert(is_single_cpu() && !is_virtual()) failed", ? ?detail_msg=0x7ffff6f61155 "type check") at /home2/spark06/jdk8u/hotspot/src/share/vm/utilities/debug.cpp:226 #5 ?0x00007ffff6673596 in LIR_OprDesc::cpu_regnr (this=0x93) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.hpp:420 #6 ?0x00007ffff666971e in LIR_OprDesc::as_register (this=0x93) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.cpp:34 #7 ?0x00007ffff667be52 in LIR_Assembler::const2reg (this=0x7fff7b9f8290, src=0x7ffe50056170, dest=0x93, patch_code=lir_patch_none, info=0x0) at /home2/spark06/jdk8u/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:681 #8 ?0x00007ffff6677d2e in LIR_Assembler::move_op (this=0x7fff7b9f8290, src=0x7ffe50056170, dest=0x93, type=T_LONG, patch_code=lir_patch_none, info=0x0, pop_fpu_stack=false, unaligned=false, wide=false) ? ?at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:841 #9 ?0x00007ffff6676dcc in LIR_Assembler::emit_op1 (this=0x7fff7b9f8290, op=0x7ffe5802f9d0) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:523 #10 0x00007ffff666def7 in LIR_Op1::emit_code (this=0x7ffe5802f9d0, masm=0x7fff7b9f8290) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIR.cpp:1103 #11 0x00007ffff6676255 in LIR_Assembler::emit_lir_list (this=0x7fff7b9f8290, list=0x7ffe50056080) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:308 #12 0x00007ffff6676081 in LIR_Assembler::emit_block (this=0x7fff7b9f8290, block=0x7ffe50052390) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:274 #13 0x00007ffff6675e61 in LIR_Assembler::emit_code (this=0x7fff7b9f8290, hir=0x7ffe50054600) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_LIRAssembler.cpp:233 #14 0x00007ffff663564b in Compilation::emit_code_body (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:343 #15 0x00007ffff663593b in Compilation::compile_java_method (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:395 #16 0x00007ffff6635c31 in Compilation::compile_method (this=0x7fff7b9f8590) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:448 #17 0x00007ffff6636275 in Compilation::Compilation (this=0x7fff7b9f8590, compiler=0x7ffff01bda50, env=0x7fff7b9f8a30, method=0x7ffe58028400, osr_bci=-1, buffer_blob=0x7fffe11f5650) ? ?at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compilation.cpp:559 #18 0x00007ffff6638f7e in Compiler::compile_method (this=0x7ffff01bda50, env=0x7fff7b9f8a30, method=0x7ffe58028400, entry_bci=-1) at /home2/spark06/jdk8u/hotspot/src/share/vm/c1/c1_Compiler.cpp:106 #19 0x00007ffff67e20f4 in CompileBroker::invoke_compiler_on_method (task=0x7ffff027d680) at /home2/spark06/jdk8u/hotspot/src/share/vm/compiler/compileBroker.cpp:2000 #20 0x00007ffff67e1651 in CompileBroker::compiler_thread_loop () at /home2/spark06/jdk8u/hotspot/src/share/vm/compiler/compileBroker.cpp:1815 #21 0x00007ffff6e58c92 in compiler_thread_entry (thread=0x7ffff01fd800, __the_thread__=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:3233 #22 0x00007ffff6e5402e in JavaThread::thread_main_inner (this=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:1702 #23 0x00007ffff6e53efb in JavaThread::run (this=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/share/vm/runtime/thread.cpp:1682 #24 0x00007ffff6ce6b33 in java_start (thread=0x7ffff01fd800) at /home2/spark06/jdk8u/hotspot/src/os/linux/vm/os_linux.cpp:782 #25 0x00007ffff75f7184 in start_thread (arg=0x7fff7b9f9700) at pthread_create.c:312 #26 0x00007ffff7b0effd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 It seems that, the operand , object.result() and value.result() cause the error. But I can?t understand why, if this is a oop store field , I think the object.result() and value.result() should be pointer(LIR_OprPtr) or array address(LIR_Address), Why it cause errors? Can any one give me some advices ? Thank you for your help. Chenxi Wang. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cthalinger at twitter.com Fri Aug 11 09:16:53 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 11 Aug 2017 11:16:53 +0200 Subject: compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java fails with Graal In-Reply-To: References: <818EB92D-77F8-4DED-A2AC-0DCC3EB2F327@oracle.com> Message-ID: <7A2496A2-1929-4345-B284-AD1B712E7837@twitter.com> > On Jun 27, 2017, at 7:20 PM, Doug Simon wrote: > > >> On 27 Jun 2017, at 18:34, Christian Thalinger wrote: >> >>> >>> On Jun 26, 2017, at 8:47 PM, Doug Simon wrote: >>> >>> >>>> On 27 Jun 2017, at 01:37, Christian Thalinger wrote: >>>> >>>> So, this change: >>>> >>>> $ hg log -r fbb9c8026495 -p compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>> changeset: 12748:fbb9c8026495 >>>> tag: jdk-9+168 >>>> user: dnsimon >>>> date: Fri Apr 28 02:54:05 2017 -0700 >>>> summary: 8177845: Need a mechanism to load Graal >>>> >>>> diff --git a/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java b/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>> --- a/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>> +++ b/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>> @@ -39,7 +39,7 @@ >>>> * @run main/othervm -Xbootclasspath/a:. >>>> * -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI >>>> * -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI >>>> - * -XX:-BackgroundCompilation >>>> + * -XX:-BackgroundCompilation -Djvmci.Compiler=null >>>> * compiler.jvmci.compilerToVM.HasCompiledCodeForOSRTest >>>> */ >>>> >>>> >>>> sets the JVMCI compiler to null. How is this test supposed to work when running with UseJVMCICompiler and Graal? >>> >>> It's not which is why the flags needed to enable Graal aren't present. >> >> But what if you run with -vmoptions:?-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler?? Which is what you do when you want to run all tests with Graal. > > Then I guess the test will have to be modified/fixed. Has anyone filed a bug and/or picked this up? From doug.simon at oracle.com Fri Aug 11 09:47:40 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 11 Aug 2017 11:47:40 +0200 Subject: compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java fails with Graal In-Reply-To: <7A2496A2-1929-4345-B284-AD1B712E7837@twitter.com> References: <818EB92D-77F8-4DED-A2AC-0DCC3EB2F327@oracle.com> <7A2496A2-1929-4345-B284-AD1B712E7837@twitter.com> Message-ID: <83D4AF9A-1B65-4117-AD79-E4BA0DF6E9D9@oracle.com> > On 11 Aug 2017, at 11:16, Christian Thalinger wrote: > >> >> On Jun 27, 2017, at 7:20 PM, Doug Simon wrote: >> >> >>> On 27 Jun 2017, at 18:34, Christian Thalinger wrote: >>> >>>> >>>> On Jun 26, 2017, at 8:47 PM, Doug Simon wrote: >>>> >>>> >>>>> On 27 Jun 2017, at 01:37, Christian Thalinger wrote: >>>>> >>>>> So, this change: >>>>> >>>>> $ hg log -r fbb9c8026495 -p compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>> changeset: 12748:fbb9c8026495 >>>>> tag: jdk-9+168 >>>>> user: dnsimon >>>>> date: Fri Apr 28 02:54:05 2017 -0700 >>>>> summary: 8177845: Need a mechanism to load Graal >>>>> >>>>> diff --git a/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java b/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>> --- a/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>> +++ b/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>> @@ -39,7 +39,7 @@ >>>>> * @run main/othervm -Xbootclasspath/a:. >>>>> * -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI >>>>> * -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI >>>>> - * -XX:-BackgroundCompilation >>>>> + * -XX:-BackgroundCompilation -Djvmci.Compiler=null >>>>> * compiler.jvmci.compilerToVM.HasCompiledCodeForOSRTest >>>>> */ >>>>> >>>>> >>>>> sets the JVMCI compiler to null. How is this test supposed to work when running with UseJVMCICompiler and Graal? >>>> >>>> It's not which is why the flags needed to enable Graal aren't present. >>> >>> But what if you run with -vmoptions:?-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler?? Which is what you do when you want to run all tests with Graal. >> >> Then I guess the test will have to be modified/fixed. > > Has anyone filed a bug and/or picked this up? Not as far as I'm aware. -Doug From cthalinger at twitter.com Fri Aug 11 10:09:32 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 11 Aug 2017 12:09:32 +0200 Subject: compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java fails with Graal In-Reply-To: <83D4AF9A-1B65-4117-AD79-E4BA0DF6E9D9@oracle.com> References: <818EB92D-77F8-4DED-A2AC-0DCC3EB2F327@oracle.com> <7A2496A2-1929-4345-B284-AD1B712E7837@twitter.com> <83D4AF9A-1B65-4117-AD79-E4BA0DF6E9D9@oracle.com> Message-ID: <29A3A7E1-4712-4B1F-842D-3F702EC499EF@twitter.com> > On Aug 11, 2017, at 11:47 AM, Doug Simon wrote: > > >> On 11 Aug 2017, at 11:16, Christian Thalinger wrote: >> >>> >>> On Jun 27, 2017, at 7:20 PM, Doug Simon wrote: >>> >>> >>>> On 27 Jun 2017, at 18:34, Christian Thalinger wrote: >>>> >>>>> >>>>> On Jun 26, 2017, at 8:47 PM, Doug Simon wrote: >>>>> >>>>> >>>>>> On 27 Jun 2017, at 01:37, Christian Thalinger wrote: >>>>>> >>>>>> So, this change: >>>>>> >>>>>> $ hg log -r fbb9c8026495 -p compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>>> changeset: 12748:fbb9c8026495 >>>>>> tag: jdk-9+168 >>>>>> user: dnsimon >>>>>> date: Fri Apr 28 02:54:05 2017 -0700 >>>>>> summary: 8177845: Need a mechanism to load Graal >>>>>> >>>>>> diff --git a/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java b/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>>> --- a/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>>> +++ b/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>>> @@ -39,7 +39,7 @@ >>>>>> * @run main/othervm -Xbootclasspath/a:. >>>>>> * -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI >>>>>> * -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI >>>>>> - * -XX:-BackgroundCompilation >>>>>> + * -XX:-BackgroundCompilation -Djvmci.Compiler=null >>>>>> * compiler.jvmci.compilerToVM.HasCompiledCodeForOSRTest >>>>>> */ >>>>>> >>>>>> >>>>>> sets the JVMCI compiler to null. How is this test supposed to work when running with UseJVMCICompiler and Graal? >>>>> >>>>> It's not which is why the flags needed to enable Graal aren't present. >>>> >>>> But what if you run with -vmoptions:?-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler?? Which is what you do when you want to run all tests with Graal. >>> >>> Then I guess the test will have to be modified/fixed. >> >> Has anyone filed a bug and/or picked this up? > > Not as far as I'm aware. I?ll file one. From cthalinger at twitter.com Fri Aug 11 11:13:58 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 11 Aug 2017 13:13:58 +0200 Subject: compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java fails with Graal In-Reply-To: <29A3A7E1-4712-4B1F-842D-3F702EC499EF@twitter.com> References: <818EB92D-77F8-4DED-A2AC-0DCC3EB2F327@oracle.com> <7A2496A2-1929-4345-B284-AD1B712E7837@twitter.com> <83D4AF9A-1B65-4117-AD79-E4BA0DF6E9D9@oracle.com> <29A3A7E1-4712-4B1F-842D-3F702EC499EF@twitter.com> Message-ID: <8848ED98-7827-49C3-AE08-2C5E6FA077E8@twitter.com> > On Aug 11, 2017, at 12:09 PM, Christian Thalinger wrote: > >> >> On Aug 11, 2017, at 11:47 AM, Doug Simon wrote: >> >> >>> On 11 Aug 2017, at 11:16, Christian Thalinger wrote: >>> >>>> >>>> On Jun 27, 2017, at 7:20 PM, Doug Simon wrote: >>>> >>>> >>>>> On 27 Jun 2017, at 18:34, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On Jun 26, 2017, at 8:47 PM, Doug Simon wrote: >>>>>> >>>>>> >>>>>>> On 27 Jun 2017, at 01:37, Christian Thalinger wrote: >>>>>>> >>>>>>> So, this change: >>>>>>> >>>>>>> $ hg log -r fbb9c8026495 -p compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>>>> changeset: 12748:fbb9c8026495 >>>>>>> tag: jdk-9+168 >>>>>>> user: dnsimon >>>>>>> date: Fri Apr 28 02:54:05 2017 -0700 >>>>>>> summary: 8177845: Need a mechanism to load Graal >>>>>>> >>>>>>> diff --git a/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java b/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>>>> --- a/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>>>> +++ b/test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java >>>>>>> @@ -39,7 +39,7 @@ >>>>>>> * @run main/othervm -Xbootclasspath/a:. >>>>>>> * -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI >>>>>>> * -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI >>>>>>> - * -XX:-BackgroundCompilation >>>>>>> + * -XX:-BackgroundCompilation -Djvmci.Compiler=null >>>>>>> * compiler.jvmci.compilerToVM.HasCompiledCodeForOSRTest >>>>>>> */ >>>>>>> >>>>>>> >>>>>>> sets the JVMCI compiler to null. How is this test supposed to work when running with UseJVMCICompiler and Graal? >>>>>> >>>>>> It's not which is why the flags needed to enable Graal aren't present. >>>>> >>>>> But what if you run with -vmoptions:?-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler?? Which is what you do when you want to run all tests with Graal. >>>> >>>> Then I guess the test will have to be modified/fixed. >>> >>> Has anyone filed a bug and/or picked this up? >> >> Not as far as I'm aware. > > I?ll file one. https://bugs.openjdk.java.net/browse/JDK-8186136 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.scalet at eldorado.org.br Fri Aug 11 13:55:26 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Fri, 11 Aug 2017 13:55:26 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> Message-ID: It worked for me Martin. Please check the new webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ Thanks for the review. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: quinta-feira, 10 de agosto de 2017 14:21 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Martin, > > Alright. I'll analyze that and update to a new webrev. > > Thanks > > -----Original Message----- > From: Doerr, Martin [mailto:martin.doerr at sap.com] > Sent: quarta-feira, 9 de agosto de 2017 09:58 > To: Gustavo Serra Scalet ; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > seems like you're preparing new VSR code :-) Nice change, but please > update the copyright messages in the modified files. > > register_ppc.cpp > to_vsr(): I don't like large code for a trivial computation. I'd prefer > something like "return as_VectorSRegister(encoding() + 32)". > > I can sponsor this change. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: Dienstag, 8. August 2017 22:19 > To: ppc-aix-port-dev at openjdk.java.net > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to > 64 registers > > Hi, > > Could you please review this specific PPC64 change to hotspot? The aim > of these changes is to allow a more complete usage of VSR. I make use of > these interfaces on an instrinsic that I plan to send next but I decided > to separate this change and send it first. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > Best regards, > Gustavo Serra Scalet From martin.doerr at sap.com Fri Aug 11 14:14:21 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 11 Aug 2017 14:14:21 +0000 Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics In-Reply-To: <1f159ee480284095b8e5c3f444dceb96@serv031.corp.eldorado.org.br> References: <1f159ee480284095b8e5c3f444dceb96@serv031.corp.eldorado.org.br> Message-ID: <16e8b68451e94eb79cdd7d9cb5d7984c@sap.com> Hi Gustavo, thanks for the webrev and for sharing performance numbers. I've found a couple of things which should get addressed. First of all, C2 does not perform sign extend when calling stubs. The int parms need to get zero/sign extended. (Could even be done without extra instructions by replacing sldi -> rldicl, cmpdi -> extsw_ in some cases.) macroAssembler_ppc.cpp: - Indentation should be 2 spaces. stubGenerator_ppc:cpp: - or_, addi_ should get replaced by orr, addi when CR0 result is not needed. - Where is lplw initialized? - I believe that the updating load/store instructions e.g. lwzu don't perform well on some processors. At least using stwu 2 times in the loop doesn't make sense. - Note: It should be possible to use 8 byte instead of 4 byte instructions: MacroAssembler::multiply64, addc, adde. But I'm not requesting to change that because I guess it would make the code very complicated, especially when supporting both endianess versions. - The squareToLen stub implementation is very close the Java implementation. So it'd be interesting to understand what C2 doesn't do as well as the hand written assembly code. Do you know that? (Not absolutely necessary for accepting this change as long as the stub is measurably faster.) Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet Sent: Donnerstag, 10. August 2017 19:22 To: 'hotspot-compiler-dev at openjdk.java.net' Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet Sent: ter?a-feira, 8 de agosto de 2017 17:19 To: ppc-aix-port-dev at openjdk.java.net Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics Hi, Could you please review this specific PPC64 change to hotspot? By implementing these intrinsics I noticed a small improvement with microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, only when backporting to JDK8 an improvement was noticed. JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ Motivation for this implementation: https://twitter.com/ijuma/status/698309312498835457 Best regards, Gustavo Serra Scalet From nils.eliasson at oracle.com Fri Aug 11 14:42:45 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 11 Aug 2017 16:42:45 +0200 Subject: [10] RFR(XS): 8169766: c1 + Xcomp reresolving call target every invocation In-Reply-To: <8c45aa96-7f8a-506c-f7ba-6ad12f7a3201@oracle.com> References: <8c45aa96-7f8a-506c-f7ba-6ad12f7a3201@oracle.com> Message-ID: Hi Vladimir, On 2017-08-07 18:42, Vladimir Kozlov wrote: > Good. > > Question. Both, this and 8160543, bugs talk about C1 only. Does the > problem exist with C2 too? The problem only exists with C1. The code is shared with C2, but C2 won't be affected because it never tries to emit optimized calls to unloaded methods. (Static bound methods that are loaded have the is_optimized flag set - so they still become optimized calls) > Comments in compiledIC.cpp also talk about C1. Should we guard 8160543 > and this changes in compiledIC.cpp with > if (method_code->is_compiled_by_c1()) ? No, I am removing the c1 specific parts, what's left is used by both. The static_bound argument isn't used anymore and can be removed from the function call: http://cr.openjdk.java.net/~neliasso/8169766/webrev.02/ If I put a diff of the two changes in this function together it becomes more clear why the first one was insufficient. - if (static_bound || is_optimized) { + if (is_optimized) { entry = method_code->verified_entry_point(); } else { entry = method_code->entry_point(); } .... - info.set_compiled_entry(entry, (static_bound || is_optimized) ? NULL : receiver_klass, is_optimized); + info.set_compiled_entry(entry, is_optimized ? NULL : receiver_klass, is_optimized); Thanks for having a look, Nils > Thanks, Vladimir On 8/7/17 7:16 AM, Nils Eliasson wrote: >> Hi, Please review this patch. In bug >> https://bugs.openjdk.java.net/browse/JDK-8160543 I changed the >> behaviour for some calls in c1 generated code to make it comply with >> the VM-spec - LinkageError must be thrown before NPE. One detail was >> missed in that fix: Some calls, that was static bound and became >> optimized virtual calls, now became vanilla virtual calls. The >> virtual calls use the unverified entry, but for the static_bound >> calls the reciever_klass was not set making the receiver check fail >> on every invocation. This scenario is only common with Xcomp when >> methods are compiled that have call targets that have not been run >> earlier. Also a c1 thing, c2 uses uncommontraps for this case. Bug: >> https://bugs.openjdk.java.net/browse/JDK-8160543 Webrev: >> http://cr.openjdk.java.net/~neliasso/8169766/webrev.01/ Regards, Nils >> Eliasson -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Aug 11 14:55:40 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 11 Aug 2017 14:55:40 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> Message-ID: <4c61f03b278d46959ca496f7c31db929@sap.com> Hi Gustavo, thanks for the new change and posting to the other lists :) I appreciate the shorter function. I think you need to check for noreg and keep that unchanged, though. Some copyrights are not updated to 2017. Consider it reviewed if the new function is fixed. I posted the webrev on the cr server: http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ and added you as contributor. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: Freitag, 11. August 2017 15:55 > To: Doerr, Martin > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > It worked for me Martin. Please check the new webrev: > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > Thanks for the review. > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > To: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Martin, > > > > Alright. I'll analyze that and update to a new webrev. > > > > Thanks > > > > -----Original Message----- > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > To: Gustavo Serra Scalet ; ppc-aix-port- > > dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > seems like you're preparing new VSR code :-) Nice change, but please > > update the copyright messages in the modified files. > > > > register_ppc.cpp > > to_vsr(): I don't like large code for a trivial computation. I'd prefer > > something like "return as_VectorSRegister(encoding() + 32)". > > > > I can sponsor this change. > > > > Thanks and best regards, > > Martin > > > > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Dienstag, 8. August 2017 22:19 > > To: ppc-aix-port-dev at openjdk.java.net > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to > > 64 registers > > > > Hi, > > > > Could you please review this specific PPC64 change to hotspot? The aim > > of these changes is to allow a more complete usage of VSR. I make use of > > these interfaces on an instrinsic that I plan to send next but I decided > > to separate this change and send it first. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > Best regards, > > Gustavo Serra Scalet From vladimir.kozlov at oracle.com Fri Aug 11 16:51:45 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Aug 2017 09:51:45 -0700 Subject: RFR(S): 8174202 : jtreg AOT tests should not assume library extension of .so In-Reply-To: <452C6FE2-3F66-42D4-B741-10612F561197@oracle.com> References: <0E750D7A-FEC4-4D3A-96F2-A917BA5271F3@oracle.com> <9a04dbb2-ea60-157c-1db7-f9fc522c431a@oracle.com> <452C6FE2-3F66-42D4-B741-10612F561197@oracle.com> Message-ID: On 8/10/17 7:11 PM, Igor Ignatyev wrote: > Thank you Vladimir. > I've found a couple of copy-paste errors in jdk/tools/jaotc/Main.java, I always used '.so' substringing output filename to object filename. > >> --- a/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Main.java Thu Aug 10 14:23:51 2017 -0700 >> +++ b/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Main.java Thu Aug 10 19:07:31 2017 -0700 >> @@ -577,7 +577,7 @@ >> break; >> case "Mac OS X": >> if (name.endsWith(".dylib")) { >> - objectFileName = name.substring(0, name.length() - ".so".length()); >> + objectFileName = name.substring(0, name.length() - ".dylib".length()); >> } >> objectFileName = objectFileName + ".o"; >> linkerPath = (options.linkerpath != null) ? options.linkerpath : "ld"; >> @@ -586,7 +586,7 @@ >> default: >> if (osName.startsWith("Windows")) { >> if (name.endsWith(".dll")) { >> - objectFileName = name.substring(0, name.length() - ".so".length()); >> + objectFileName = name.substring(0, name.length() - ".dll".length()); >> } >> objectFileName = objectFileName + ".obj"; >> linkerPath = (options.linkerpath != null) ? options.linkerpath : getWindowsLinkPath(); Good. I thought it was intentional :) Vladimir > > Thanks, > -- Igor > >> On Aug 10, 2017, at 5:24 PM, Vladimir Kozlov wrote: >> >> Good. >> >> Thanks, >> Vladimir >> >> On 8/10/17 4:33 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8174202/webrev.00/index.html >>>> 67 lines changed: 47 ins; 11 del; 9 mod; >>> Hi all, >>> could you please review this small fix? >>> problem: some of aot tests assumed that output file is named unnamed.so regardless the platform. the problem was worked around in jaotc tool. >>> fix: the workaround was removed and now we use platform-specific extension for default output name. it's unnamed.dll on windows, unnamed.dylib on mac and unnamed.so on all other platforms. >>> the tests have been updated correspondingly. >>> webrev: http://cr.openjdk.java.net/~iignatyev//8174202/webrev.00/index.html >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8174202 >>> testing: hotspot/compiler/aot (w/ 8183337[1] applied) on all supported platforms >>> [1] http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >>> Thanks, >>> -- Igor > From vladimir.kozlov at oracle.com Fri Aug 11 17:09:15 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Aug 2017 10:09:15 -0700 Subject: [10] RFR(XS): 8169766: c1 + Xcomp reresolving call target every invocation In-Reply-To: References: <8c45aa96-7f8a-506c-f7ba-6ad12f7a3201@oracle.com> Message-ID: On 8/11/17 7:42 AM, Nils Eliasson wrote: > Hi Vladimir, > > > On 2017-08-07 18:42, Vladimir Kozlov wrote: >> Good. >> >> Question. Both, this and 8160543, bugs talk about C1 only. Does the >> problem exist with C2 too? > > The problem only exists with C1. The code is shared with C2, but C2 > won't be affected because it never tries to emit optimized calls to > unloaded methods. > > (Static bound methods that are loaded have the is_optimized flag set - > so they still become optimized calls) > >> Comments in compiledIC.cpp also talk about C1. Should we guard 8160543 >> and this changes in compiledIC.cpp with >> if (method_code->is_compiled_by_c1()) ? > > No, I am removing the c1 specific parts, what's left is used by both. > > The static_bound argument isn't used anymore and can be removed from the > function call: > > http://cr.openjdk.java.net/~neliasso/8169766/webrev.02/ Good. Thanks, Vladimir > > If I put a diff of the two changes in this function together it becomes > more clear why the first one was insufficient. > > > - if (static_bound || is_optimized) { > + if (is_optimized) { > entry = method_code->verified_entry_point(); > } else { > entry = method_code->entry_point(); } > .... - info.set_compiled_entry(entry, (static_bound || is_optimized) ? > NULL : receiver_klass, is_optimized); > + info.set_compiled_entry(entry, is_optimized ? NULL : receiver_klass, > is_optimized); > > > Thanks for having a look, > Nils > >> Thanks, Vladimir On 8/7/17 7:16 AM, Nils Eliasson wrote: >>> Hi, Please review this patch. In bug >>> https://bugs.openjdk.java.net/browse/JDK-8160543 I changed the >>> behaviour for some calls in c1 generated code to make it comply with >>> the VM-spec - LinkageError must be thrown before NPE. One detail was >>> missed in that fix: Some calls, that was static bound and became >>> optimized virtual calls, now became vanilla virtual calls. The >>> virtual calls use the unverified entry, but for the static_bound >>> calls the reciever_klass was not set making the receiver check fail >>> on every invocation. This scenario is only common with Xcomp when >>> methods are compiled that have call targets that have not been run >>> earlier. Also a c1 thing, c2 uses uncommontraps for this case. Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8160543 Webrev: >>> http://cr.openjdk.java.net/~neliasso/8169766/webrev.01/ Regards, Nils >>> Eliasson From daniel.daugherty at oracle.com Fri Aug 11 17:25:37 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Aug 2017 11:25:37 -0600 Subject: RFR(XXS): try simple @build fix in compiler/jsr292/PollutedTrapCounts.java (8186151) Message-ID: <39ca265b-20d2-4372-fdb6-a6beaf40bd91@oracle.com> Greetings, I was about to quarantine compiler/jsr292/PollutedTrapCounts.java in JDK10-hs when Ioi suggested the following simple @build fix: $ hg diff test/compiler/jsr292/PollutedTrapCounts.java diff -r 7b88d261529b test/compiler/jsr292/PollutedTrapCounts.java --- a/test/compiler/jsr292/PollutedTrapCounts.java Fri Aug 11 11:20:37 2017 -0600 +++ b/test/compiler/jsr292/PollutedTrapCounts.java Fri Aug 11 11:22:13 2017 -0600 @@ -26,7 +26,8 @@ * @bug 8074551 * @modules java.base/jdk.internal.misc * @library /test/lib - * + * @build jdk.test.lib.* + * @build jdk.test.lib.process.* * @run driver compiler.jsr292.PollutedTrapCounts */ 8186151 try simple @build fix in compiler/jsr292/PollutedTrapCounts.java https://bugs.openjdk.java.net/browse/JDK-8186151 This fix is targeted to JDK10/hs. Dan From dmitrij.pochepko at bell-sw.com Fri Aug 11 17:30:20 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 11 Aug 2017 20:30:20 +0300 Subject: [10] RFR(S): JDK-8184943: AARCH64: Intrinsify hasNegatives In-Reply-To: <10ae906b-9cfc-cd5b-4b66-ecec1af233b1@redhat.com> References: <7f1a11ea-c795-a26a-a104-78ae3aac6930@redhat.com> <61a090b3-47bd-dacd-eeaa-0b201a4a4ee7@bell-sw.com> <2dc11588-fec0-603b-faf1-e214e9feeb2d@redhat.com> <10ae906b-9cfc-cd5b-4b66-ecec1af233b1@redhat.com> Message-ID: <9605fe42-89fa-a7a9-91df-db895c0195aa@bell-sw.com> Hi, please review a new version of this RFR [1] which is significantly re-worked. Changes compared to original posting: - 2 versions of hasNegatives intrinsic were merged, which result in good performance for both small and large array. - large array case and "at-the-end-of-mem-page" case were moved to stub to save code cache and help register allocator Raw performance numbers for the original hasNegativesBench.loopingFastMethod [2] are here[3] and accompanied by updated comparison charts for Raspberry Pi 3 [4] and ThunderX T88 [5]. In short, intrinsified hasNegatives is x4 faster on T88 and x2.5 on R-Pi for 31 byte array and up to 8 times faster on large arrays. I've also created small and simple benchmark [6] which demonstrates performance difference for string constructor for strings without negative byte values. Raw results [7] shows significantly increased performance on Thunder X T88. Results also can be seen on comparison charts [8]. Due to large amount of allocations and gc this benchmark is not applicable for R-Pi, which has 1GB system memory and sd-card as main drive. This patch should be considered as patch with 2 contributors (stuart.monteith at linaro.org and dmitrij.pochepko at bell-sw.com (openjdk login dpochepk)). Also I'd like to thank Andrew Haley for early reviews and consulting. No regressions were found via jtreg tests. Thanks, Dmitrij [1] Webrev: http://cr.openjdk.java.net/~dpochepk/8184943/webrev.02/ [2] http://cr.openjdk.java.net/~aph/HasNegativesBench/ [3] http://cr.openjdk.java.net/~dpochepk/8184943/perf_numbers.txt [4] http://cr.openjdk.java.net/~dpochepk/8184943/Cortex_A53_comparison.png [5] http://cr.openjdk.java.net/~dpochepk/8184943/ThunderX_comparison.png [6] http://cr.openjdk.java.net/~dpochepk/8184943/StringConstructorBench.java [7] http://cr.openjdk.java.net/~dpochepk/8184943/StringConstructorBench.txt [8] http://cr.openjdk.java.net/~dpochepk/8184943/ThunderX-StringConstructor.png On 21.07.2017 11:26, Andrew Haley wrote: > On 20/07/17 19:27, Dmitrij Pochepko wrote: >> Probably best way would be to merge large data loads from my patch and >> Stuart's lightning-fast small arrays handling. > Yes. > >> I'll be happy to merge these ideas in one intrinsic that works fastest >> on small and large arrays if Stuart does not mind. I could use some help >> testing the final solution on some of the HW we don't have. I don't mind >> if Stuart want to merge it, then we'll help him with testing on h/w he >> doesn't have. > Have fun! The performance to care about is small strings (< 31 bytes) and, > less commonly, very long ones. Super-fast handling of small strings is > very important. > From aph at redhat.com Fri Aug 11 17:57:11 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Aug 2017 18:57:11 +0100 Subject: [10] RFR(S): JDK-8184943: AARCH64: Intrinsify hasNegatives In-Reply-To: <9605fe42-89fa-a7a9-91df-db895c0195aa@bell-sw.com> References: <7f1a11ea-c795-a26a-a104-78ae3aac6930@redhat.com> <61a090b3-47bd-dacd-eeaa-0b201a4a4ee7@bell-sw.com> <2dc11588-fec0-603b-faf1-e214e9feeb2d@redhat.com> <10ae906b-9cfc-cd5b-4b66-ecec1af233b1@redhat.com> <9605fe42-89fa-a7a9-91df-db895c0195aa@bell-sw.com> Message-ID: <3b7a274e-4524-3244-837f-0e873a66b269@redhat.com> On 11/08/17 18:30, Dmitrij Pochepko wrote: > This patch should be considered as patch with 2 contributors > (stuart.monteith at linaro.org and dmitrij.pochepko at bell-sw.com (openjdk > login dpochepk)). Also I'd like to thank Andrew Haley for early > reviews and consulting. > > No regressions were found via jtreg tests. Good work. I think we're done. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Fri Aug 11 17:59:04 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Aug 2017 10:59:04 -0700 Subject: RFR(XXS): try simple @build fix in compiler/jsr292/PollutedTrapCounts.java (8186151) In-Reply-To: <39ca265b-20d2-4372-fdb6-a6beaf40bd91@oracle.com> References: <39ca265b-20d2-4372-fdb6-a6beaf40bd91@oracle.com> Message-ID: Okay, lets try it. Vladimir On 8/11/17 10:25 AM, Daniel D. Daugherty wrote: > Greetings, > > I was about to quarantine compiler/jsr292/PollutedTrapCounts.java in > JDK10-hs when Ioi suggested the following simple @build fix: > > $ hg diff test/compiler/jsr292/PollutedTrapCounts.java > diff -r 7b88d261529b test/compiler/jsr292/PollutedTrapCounts.java > --- a/test/compiler/jsr292/PollutedTrapCounts.java Fri Aug 11 > 11:20:37 2017 -0600 > +++ b/test/compiler/jsr292/PollutedTrapCounts.java Fri Aug 11 > 11:22:13 2017 -0600 > @@ -26,7 +26,8 @@ > * @bug 8074551 > * @modules java.base/jdk.internal.misc > * @library /test/lib > - * > + * @build jdk.test.lib.* > + * @build jdk.test.lib.process.* > * @run driver compiler.jsr292.PollutedTrapCounts > */ > > > 8186151 try simple @build fix in compiler/jsr292/PollutedTrapCounts.java > https://bugs.openjdk.java.net/browse/JDK-8186151 > > This fix is targeted to JDK10/hs. > > Dan From daniel.daugherty at oracle.com Fri Aug 11 18:00:27 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Aug 2017 12:00:27 -0600 Subject: RFR(XXS): try simple @build fix in compiler/jsr292/PollutedTrapCounts.java (8186151) In-Reply-To: References: <39ca265b-20d2-4372-fdb6-a6beaf40bd91@oracle.com> Message-ID: <74ce2543-f4fa-5e72-ff81-efced65303d1@oracle.com> Thanks Vladimir! Dan On 8/11/17 11:59 AM, Vladimir Kozlov wrote: > Okay, lets try it. > > Vladimir > > On 8/11/17 10:25 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I was about to quarantine compiler/jsr292/PollutedTrapCounts.java in >> JDK10-hs when Ioi suggested the following simple @build fix: >> >> $ hg diff test/compiler/jsr292/PollutedTrapCounts.java >> diff -r 7b88d261529b test/compiler/jsr292/PollutedTrapCounts.java >> --- a/test/compiler/jsr292/PollutedTrapCounts.java Fri Aug 11 >> 11:20:37 2017 -0600 >> +++ b/test/compiler/jsr292/PollutedTrapCounts.java Fri Aug 11 >> 11:22:13 2017 -0600 >> @@ -26,7 +26,8 @@ >> * @bug 8074551 >> * @modules java.base/jdk.internal.misc >> * @library /test/lib >> - * >> + * @build jdk.test.lib.* >> + * @build jdk.test.lib.process.* >> * @run driver compiler.jsr292.PollutedTrapCounts >> */ >> >> >> 8186151 try simple @build fix in compiler/jsr292/PollutedTrapCounts.java >> https://bugs.openjdk.java.net/browse/JDK-8186151 >> >> This fix is targeted to JDK10/hs. >> >> Dan From aph at redhat.com Fri Aug 11 18:14:52 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Aug 2017 19:14:52 +0100 Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics In-Reply-To: <1f159ee480284095b8e5c3f444dceb96@serv031.corp.eldorado.org.br> References: <1f159ee480284095b8e5c3f444dceb96@serv031.corp.eldorado.org.br> Message-ID: On 10/08/17 18:22, Gustavo Serra Scalet wrote: > Could you please review this specific PPC64 change to hotspot? By implementing these intrinsics I noticed a small improvement with microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, only when backporting to JDK8 an improvement was noticed. I'm surprised it's worth bothering. JDK-8145913 surely does most of the work for RSA. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gustavo.scalet at eldorado.org.br Fri Aug 11 20:02:45 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Fri, 11 Aug 2017 20:02:45 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <4c61f03b278d46959ca496f7c31db929@sap.com> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> Message-ID: <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> Hello Goetz, About the noreg: if the VectorRegisterImpl::encoding() is not a value from 0-32 expected, it was an invalid VectorRegister which will, in turn, continue to be invalid as VectorSRegister. Anyway, do you want me to add a verification of "if ((encoding() < 0) || (encoding() > 32)) return vsnoregi;" before? Or an assert? And about the copyright, where do you mean? Thanks > -----Original Message----- > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > Sent: sexta-feira, 11 de agosto de 2017 11:56 > To: Gustavo Serra Scalet ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > thanks for the new change and posting to the other lists :) > > I appreciate the shorter function. I think you need to check for noreg > and keep that unchanged, though. > Some copyrights are not updated to 2017. > Consider it reviewed if the new function is fixed. > > I posted the webrev on the cr server: > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > and added you as contributor. > > Best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Freitag, 11. August 2017 15:55 > > To: Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > up to 64 registers > > > > It worked for me Martin. Please check the new webrev: > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > Thanks for the review. > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net> > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Martin, > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > Thanks > > > > > > -----Original Message----- > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > To: Gustavo Serra Scalet ; > > > ppc-aix-port- dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > seems like you're preparing new VSR code :-) Nice change, but please > > > update the copyright messages in the modified files. > > > > > > register_ppc.cpp > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > prefer something like "return as_VectorSRegister(encoding() + 32)". > > > > > > I can sponsor this change. > > > > > > Thanks and best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Dienstag, 8. August 2017 22:19 > > > To: ppc-aix-port-dev at openjdk.java.net > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > > to > > > 64 registers > > > > > > Hi, > > > > > > Could you please review this specific PPC64 change to hotspot? The > > > aim of these changes is to allow a more complete usage of VSR. I > > > make use of these interfaces on an instrinsic that I plan to send > > > next but I decided to separate this change and send it first. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > Best regards, > > > Gustavo Serra Scalet From igor.veresov at oracle.com Fri Aug 11 22:18:29 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 11 Aug 2017 15:18:29 -0700 Subject: RFR(XL) 8186158: Update Graal Message-ID: <90405C0A-DB32-41DE-8DA3-A936358C65DB@oracle.com> This is a Graal update. The list of changesets included is listed in the JBS entry. JBS: https://bugs.openjdk.java.net/browse/JDK-8186158 Webrev: http://cr.openjdk.java.net/~iveresov/8186158/ Thanks, igor From vladimir.kozlov at oracle.com Fri Aug 11 22:35:04 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Aug 2017 15:35:04 -0700 Subject: RFR(XL) 8186158: Update Graal In-Reply-To: <90405C0A-DB32-41DE-8DA3-A936358C65DB@oracle.com> References: <90405C0A-DB32-41DE-8DA3-A936358C65DB@oracle.com> Message-ID: Igor, Changes in org.graalvm.graphio files added trailing spaces! Are you running jcheck? Vladimir On 8/11/17 3:18 PM, Igor Veresov wrote: > This is a Graal update. The list of changesets included is listed in the JBS entry. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8186158 > Webrev: http://cr.openjdk.java.net/~iveresov/8186158/ > > Thanks, > igor > From igor.veresov at oracle.com Fri Aug 11 22:50:29 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 11 Aug 2017 15:50:29 -0700 Subject: RFR(XL) 8186158: Update Graal In-Reply-To: References: <90405C0A-DB32-41DE-8DA3-A936358C65DB@oracle.com> Message-ID: No yet. I?ll fix those. igor > On Aug 11, 2017, at 3:35 PM, Vladimir Kozlov wrote: > > Igor, > > Changes in org.graalvm.graphio files added trailing spaces! > Are you running jcheck? > > Vladimir > > On 8/11/17 3:18 PM, Igor Veresov wrote: >> This is a Graal update. The list of changesets included is listed in the JBS entry. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8186158 >> Webrev: http://cr.openjdk.java.net/~iveresov/8186158/ >> Thanks, >> igor From igor.veresov at oracle.com Fri Aug 11 23:04:55 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 11 Aug 2017 16:04:55 -0700 Subject: RFR(XL) 8186158: Update Graal In-Reply-To: References: <90405C0A-DB32-41DE-8DA3-A936358C65DB@oracle.com> Message-ID: Webrev update in-place. I?ll also push the whitespace fixes upstream. igor > On Aug 11, 2017, at 3:50 PM, Igor Veresov wrote: > > No yet. I?ll fix those. > > igor > >> On Aug 11, 2017, at 3:35 PM, Vladimir Kozlov wrote: >> >> Igor, >> >> Changes in org.graalvm.graphio files added trailing spaces! >> Are you running jcheck? >> >> Vladimir >> >> On 8/11/17 3:18 PM, Igor Veresov wrote: >>> This is a Graal update. The list of changesets included is listed in the JBS entry. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8186158 >>> Webrev: http://cr.openjdk.java.net/~iveresov/8186158/ >>> Thanks, >>> igor > From david.holmes at oracle.com Fri Aug 11 23:36:15 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Aug 2017 09:36:15 +1000 Subject: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC machines In-Reply-To: <46b484c8-e080-8c6a-a6bb-8471ce5efd9f@oracle.com> References: <6e333994-ee8b-4fb4-b9a9-59afc751217d@default> <0285fdb7-8548-48e5-b019-3de62f66cffe@default> <46b484c8-e080-8c6a-a6bb-8471ce5efd9f@oracle.com> Message-ID: On 11/08/2017 7:57 AM, David Holmes wrote: > Hi Poonam, > > On 11/08/2017 3:44 AM, Poonam Parhar wrote: >> Thanks Vladimir. >> >> Since the SPARC machines are always multi-cores, we can safely set >> AssumeMP to true on these. > > I'm still unclear about the reported problem here. As Vladimir pointed > out in the bug report the is_MP checks uses _processor_count which is > set to the number of cpus on the machine _not_ the number of cpus > currently available to the VM. > > void os::Solaris::initialize_system_info() { > set_processor_count(sysconf(_SC_NPROCESSORS_CONF)); > > So all this discussion about containers and dynamic changes to available > cpus should be moot. So the only way this can fail is if the number of > configured processors on the machine dynamically changed _and_ it was > initially 1 - which seems to me to be impossible with sparc unless the > hardware info is being incorrectly reported (ie virtualization bug?) No it isn't impossible as a LDOM can be configured with 1 "cpu", and 1 is what sysconf(_SC_NPROCESSORS_CONF) will return. A change to the number of cpus is not the issue here, but the simple fact that the BIS instructions have to have a membar issued, and that is elided when there is only 1 processor - unless AssumeMP is set true. Sorry for the noise. David > That aside I have no issue with the fix as we will likely be assuming MP > always in the future. > > Thanks, > David > >> Adding my comments from the previous mail here again for better >> readability: >> ------------------------------------- >> Bug: https://bugs.openjdk.java.net/browse/JDK-8185572: Enable AssumeMP >> by default on SPARC machines >> Webrev: http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >> >> This change enables AssumeMP by default on SPARC machines. On Sparc >> T7, to finalize BIS instructions the server compiler needs to add a >> 'membar' instruction at the end. But the generation of 'membar' is >> guarded by os::is_MP(), and os::is_MP() returns false when there is a >> single cpu available on the system. Now, in virtualized/container >> environments, the number of processors allocated to a virtual machine >> can dynamically change during the application runtime. That could lead >> to incorrect generation of BIS instructions and can cause JVM crashes. >> Enabling AssumeMP makes is_MP() always return true on SPARC systems. >> >> In future, we may consider making generation of 'membar' unconditional >> with the enhancement request: >> https://bugs.openjdk.java.net/browse/JDK-8150715. >> >> Thanks, >> Poonam >> >> >>> -----Original Message----- >>> From: Vladimir Kozlov >>> Sent: Thursday, August 10, 2017 9:47 AM >>> To: Poonam Parhar; hotspot-compiler-dev at openjdk.java.net >>> Cc: hotspot-runtime-dev at openjdk.java.net runtime >>> Subject: Re: [10] RFR(S): 8185572: Enable AssumeMP by default on SPARC >>> machines >>> >>> CCing to Runtime. >>> >>> Can you add comment explaining why it set to true on SPARC? >>> >>> Thanks, >>> Vladimir >>> >>> On 8/10/17 6:26 AM, Poonam Parhar wrote: >>>> Hello, >>>> >>>> Please review this simple patch: >>>> >>>> Bug:_JDK-8185572_>> 8185572>:En >>>> able >>>> AssumeMP by default on SPARC machines >>>> >>>> Webrev:http://cr.openjdk.java.net/~poonam/8185572/webrev.00/ >>>> >>>> This change enables AssumeMP by default on SPARC machines. On Sparc >>>> T7, to finalize BIS instructions the server compiler needs toadd >>>> a'membar'instruction at the end.But the generation of'membar'is >>>> guarded byos::is_MP(), andos::is_MP()returns false when there isa >>>> singlecpu available on the system. >>>> Now,invirtualized/containerenvironments, the number >>>> ofprocessorsallocated to a virtual machine can dynamically change >>>> during the application runtime.That could lead to incorrect >>> generation >>>> of BIS instructions and can cause JVM crashes.Enabling AssumeMP makes >>>> is_MP() always return true on SPARC systems. >>>> >>>> In future, we may consider makinggeneration of'membar'unconditional >>>> withtheenhancementrequest:_JDK- >>> 8150715_. >>>> >>>> Thanks, >>>> >>>> Poonam >>>> From vladimir.kozlov at oracle.com Sat Aug 12 00:21:32 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Aug 2017 17:21:32 -0700 Subject: RFR(XL) 8186158: Update Graal In-Reply-To: References: <90405C0A-DB32-41DE-8DA3-A936358C65DB@oracle.com> Message-ID: <4c277c7d-91bf-a5d9-26d1-3e252e324ae9@oracle.com> Good. Thanks, Vladimir On 8/11/17 4:04 PM, Igor Veresov wrote: > Webrev update in-place. I?ll also push the whitespace fixes upstream. > > igor > >> On Aug 11, 2017, at 3:50 PM, Igor Veresov wrote: >> >> No yet. I?ll fix those. >> >> igor >> >>> On Aug 11, 2017, at 3:35 PM, Vladimir Kozlov wrote: >>> >>> Igor, >>> >>> Changes in org.graalvm.graphio files added trailing spaces! >>> Are you running jcheck? >>> >>> Vladimir >>> >>> On 8/11/17 3:18 PM, Igor Veresov wrote: >>>> This is a Graal update. The list of changesets included is listed in the JBS entry. >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8186158 >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8186158/ >>>> Thanks, >>>> igor >> > From igor.veresov at oracle.com Sat Aug 12 00:34:41 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 11 Aug 2017 17:34:41 -0700 Subject: RFR(XL) 8186158: Update Graal In-Reply-To: <4c277c7d-91bf-a5d9-26d1-3e252e324ae9@oracle.com> References: <90405C0A-DB32-41DE-8DA3-A936358C65DB@oracle.com> <4c277c7d-91bf-a5d9-26d1-3e252e324ae9@oracle.com> Message-ID: <06E40229-F923-4371-9507-E13F5F9A6F64@oracle.com> Thanks! igor > On Aug 11, 2017, at 5:21 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 8/11/17 4:04 PM, Igor Veresov wrote: >> Webrev update in-place. I?ll also push the whitespace fixes upstream. >> igor >>> On Aug 11, 2017, at 3:50 PM, Igor Veresov wrote: >>> >>> No yet. I?ll fix those. >>> >>> igor >>> >>>> On Aug 11, 2017, at 3:35 PM, Vladimir Kozlov wrote: >>>> >>>> Igor, >>>> >>>> Changes in org.graalvm.graphio files added trailing spaces! >>>> Are you running jcheck? >>>> >>>> Vladimir >>>> >>>> On 8/11/17 3:18 PM, Igor Veresov wrote: >>>>> This is a Graal update. The list of changesets included is listed in the JBS entry. >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8186158 >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8186158/ >>>>> Thanks, >>>>> igor >>> From martin.doerr at sap.com Sat Aug 12 10:01:17 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Sat, 12 Aug 2017 10:01:17 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> Message-ID: Hi Gustavo, I think returning vsnoregi is the better choice. If you want to check the upper limit as well, it should be ">=32". Copyright year needs to be updated in the header (first 2 lines) of the register_ppc files. Thanks and best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Freitag, 11. August 2017 22:03 To: Lindenmaier, Goetz ; Doerr, Martin Cc: 'hotspot-compiler-dev at openjdk.java.net' ; hotspot-dev at openjdk.java.net Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers Hello Goetz, About the noreg: if the VectorRegisterImpl::encoding() is not a value from 0-32 expected, it was an invalid VectorRegister which will, in turn, continue to be invalid as VectorSRegister. Anyway, do you want me to add a verification of "if ((encoding() < 0) || (encoding() > 32)) return vsnoregi;" before? Or an assert? And about the copyright, where do you mean? Thanks > -----Original Message----- > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > Sent: sexta-feira, 11 de agosto de 2017 11:56 > To: Gustavo Serra Scalet ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > thanks for the new change and posting to the other lists :) > > I appreciate the shorter function. I think you need to check for noreg > and keep that unchanged, though. > Some copyrights are not updated to 2017. > Consider it reviewed if the new function is fixed. > > I posted the webrev on the cr server: > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > and added you as contributor. > > Best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Freitag, 11. August 2017 15:55 > > To: Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > up to 64 registers > > > > It worked for me Martin. Please check the new webrev: > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > Thanks for the review. > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net> > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Martin, > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > Thanks > > > > > > -----Original Message----- > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > To: Gustavo Serra Scalet ; > > > ppc-aix-port- dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > seems like you're preparing new VSR code :-) Nice change, but please > > > update the copyright messages in the modified files. > > > > > > register_ppc.cpp > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > prefer something like "return as_VectorSRegister(encoding() + 32)". > > > > > > I can sponsor this change. > > > > > > Thanks and best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Dienstag, 8. August 2017 22:19 > > > To: ppc-aix-port-dev at openjdk.java.net > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > > to > > > 64 registers > > > > > > Hi, > > > > > > Could you please review this specific PPC64 change to hotspot? The > > > aim of these changes is to allow a more complete usage of VSR. I > > > make use of these interfaces on an instrinsic that I plan to send > > > next but I decided to separate this change and send it first. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > Best regards, > > > Gustavo Serra Scalet From doug.simon at oracle.com Sat Aug 12 11:05:18 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 12 Aug 2017 13:05:18 +0200 Subject: RFR: 8186163: bad signatures should be detected by MetaAccessProvider.parseMethodDescriptor Message-ID: <35936655-C9D0-4DB7-886D-95338C547B91@oracle.com> Please review this small change to improve error handling when an invalid string is passed to MetaAccessProvider.parseMethodDescriptor https://bugs.openjdk.java.net/browse/JDK-8186163 http://cr.openjdk.java.net/~dnsimon/8186163/ -Doug From vladimir.kozlov at oracle.com Sat Aug 12 17:24:06 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 12 Aug 2017 10:24:06 -0700 Subject: RFR: 8186163: bad signatures should be detected by MetaAccessProvider.parseMethodDescriptor In-Reply-To: <35936655-C9D0-4DB7-886D-95338C547B91@oracle.com> References: <35936655-C9D0-4DB7-886D-95338C547B91@oracle.com> Message-ID: Looks good. Vladimir On 8/12/17 4:05 AM, Doug Simon wrote: > Please review this small change to improve error handling when an invalid string is passed to MetaAccessProvider.parseMethodDescriptor > > https://bugs.openjdk.java.net/browse/JDK-8186163 > http://cr.openjdk.java.net/~dnsimon/8186163/ > > -Doug > From doug.simon at oracle.com Sat Aug 12 21:43:46 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 12 Aug 2017 23:43:46 +0200 Subject: RFR: 8186163: bad signatures should be detected by MetaAccessProvider.parseMethodDescriptor In-Reply-To: References: <35936655-C9D0-4DB7-886D-95338C547B91@oracle.com> Message-ID: <84C45CA9-236C-4112-A7A8-BFC7E184E3EA@oracle.com> > On 12 Aug 2017, at 19:24, Vladimir Kozlov wrote: > > Looks good. Thanks. Do I need another review? BTW, please remind me of the process for requesting a 9u back port. It's not so important for this change but may be for others. -Doug > > On 8/12/17 4:05 AM, Doug Simon wrote: >> Please review this small change to improve error handling when an invalid string is passed to MetaAccessProvider.parseMethodDescriptor >> https://bugs.openjdk.java.net/browse/JDK-8186163 >> http://cr.openjdk.java.net/~dnsimon/8186163/ >> -Doug From goetz.lindenmaier at sap.com Mon Aug 14 10:17:28 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Aug 2017 10:17:28 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> Message-ID: <83ad97f2d3a24b65806055531f426c1c@sap.com> Hi Gustavo, noreg* is meant to be used intentionally. So you should not match any illegal values to noreg*. I would implement it like this: if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you feel like, you can assert for values < -1 and > 31. For the copyrights: You must adapt the copyright year of the Oracle copyright line in any file you edit. There must always be a trailing comma. I.e., you change * Copyright (c) 2000, Oracle and/or its affiliates. All rights reserved. to * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved. or * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved. to * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved. You may add one line of your own copyright. But this is only common in new files. New files usually also get the Oracle copyright line. That's why these files have the SAP copyright. You don't need to update the SAP copyright :). Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Samstag, 12. August 2017 12:01 > To: Gustavo Serra Scalet ; Lindenmaier, > Goetz > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hi Gustavo, > > I think returning vsnoregi is the better choice. If you want to check the upper > limit as well, it should be ">=32". > Copyright year needs to be updated in the header (first 2 lines) of the > register_ppc files. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Freitag, 11. August 2017 22:03 > To: Lindenmaier, Goetz ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hello Goetz, > > About the noreg: if the VectorRegisterImpl::encoding() is not a value from 0-32 > expected, it was an invalid VectorRegister which will, in turn, continue to be > invalid as VectorSRegister. > > Anyway, do you want me to add a verification of "if ((encoding() < 0) || > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > And about the copyright, where do you mean? > > Thanks > > > -----Original Message----- > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > To: Gustavo Serra Scalet ; Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > thanks for the new change and posting to the other lists :) > > > > I appreciate the shorter function. I think you need to check for noreg > > and keep that unchanged, though. > > Some copyrights are not updated to 2017. > > Consider it reviewed if the new function is fixed. > > > > I posted the webrev on the cr server: > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > and added you as contributor. > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Freitag, 11. August 2017 15:55 > > > To: Doerr, Martin > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > It worked for me Martin. Please check the new webrev: > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > Thanks for the review. > > > > > > > -----Original Message----- > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net> > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Martin, > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > Thanks > > > > > > > > -----Original Message----- > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > To: Gustavo Serra Scalet ; > > > > ppc-aix-port- dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > seems like you're preparing new VSR code :-) Nice change, but please > > > > update the copyright messages in the modified files. > > > > > > > > register_ppc.cpp > > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > > prefer something like "return as_VectorSRegister(encoding() + 32)". > > > > > > > > I can sponsor this change. > > > > > > > > Thanks and best regards, > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > > > to > > > > 64 registers > > > > > > > > Hi, > > > > > > > > Could you please review this specific PPC64 change to hotspot? The > > > > aim of these changes is to allow a more complete usage of VSR. I > > > > make use of these interfaces on an instrinsic that I plan to send > > > > next but I decided to separate this change and send it first. > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > Best regards, > > > > Gustavo Serra Scalet From stuart.monteith at linaro.org Mon Aug 14 10:47:54 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 14 Aug 2017 11:47:54 +0100 Subject: [10] RFR(S): JDK-8184943: AARCH64: Intrinsify hasNegatives In-Reply-To: <9605fe42-89fa-a7a9-91df-db895c0195aa@bell-sw.com> References: <7f1a11ea-c795-a26a-a104-78ae3aac6930@redhat.com> <61a090b3-47bd-dacd-eeaa-0b201a4a4ee7@bell-sw.com> <2dc11588-fec0-603b-faf1-e214e9feeb2d@redhat.com> <10ae906b-9cfc-cd5b-4b66-ecec1af233b1@redhat.com> <9605fe42-89fa-a7a9-91df-db895c0195aa@bell-sw.com> Message-ID: Thanks Dmitrij, I'll look at what you've done and try your patch on my machines. BR, Stuart On 11 August 2017 at 18:30, Dmitrij Pochepko wrote: > Hi, > > please review a new version of this RFR [1] which is significantly > re-worked. > > > Changes compared to original posting: > > - 2 versions of hasNegatives intrinsic were merged, which result in good > performance for both small and large array. > > - large array case and "at-the-end-of-mem-page" case were moved to stub to > save code cache and help register allocator > > > Raw performance numbers for the original hasNegativesBench.loopingFastMethod > [2] are here[3] and accompanied by updated comparison charts for Raspberry > Pi 3 [4] and ThunderX T88 [5]. In short, intrinsified hasNegatives is x4 > faster on T88 and x2.5 on R-Pi for 31 byte array and up to 8 times faster on > large arrays. > > I've also created small and simple benchmark [6] which demonstrates > performance difference for string constructor for strings without negative > byte values. Raw results [7] shows significantly increased performance on > Thunder X T88. Results also can be seen on comparison charts [8]. Due to > large amount of allocations and gc this benchmark is not applicable for > R-Pi, which has 1GB system memory and sd-card as main drive. > > > This patch should be considered as patch with 2 contributors > (stuart.monteith at linaro.org and dmitrij.pochepko at bell-sw.com (openjdk login > dpochepk)). Also I'd like to thank Andrew Haley for early reviews and > consulting. > > No regressions were found via jtreg tests. > > Thanks, > > Dmitrij > > > [1] Webrev: http://cr.openjdk.java.net/~dpochepk/8184943/webrev.02/ > [2] http://cr.openjdk.java.net/~aph/HasNegativesBench/ > [3] http://cr.openjdk.java.net/~dpochepk/8184943/perf_numbers.txt > [4] http://cr.openjdk.java.net/~dpochepk/8184943/Cortex_A53_comparison.png > [5] http://cr.openjdk.java.net/~dpochepk/8184943/ThunderX_comparison.png > [6] > http://cr.openjdk.java.net/~dpochepk/8184943/StringConstructorBench.java > [7] http://cr.openjdk.java.net/~dpochepk/8184943/StringConstructorBench.txt > [8] > http://cr.openjdk.java.net/~dpochepk/8184943/ThunderX-StringConstructor.png > > > On 21.07.2017 11:26, Andrew Haley wrote: >> >> On 20/07/17 19:27, Dmitrij Pochepko wrote: >>> >>> Probably best way would be to merge large data loads from my patch and >>> Stuart's lightning-fast small arrays handling. >> >> Yes. >> >>> I'll be happy to merge these ideas in one intrinsic that works fastest >>> on small and large arrays if Stuart does not mind. I could use some help >>> testing the final solution on some of the HW we don't have. I don't mind >>> if Stuart want to merge it, then we'll help him with testing on h/w he >>> doesn't have. >> >> Have fun! The performance to care about is small strings (< 31 bytes) >> and, >> less commonly, very long ones. Super-fast handling of small strings is >> very important. >> > From gustavo.scalet at eldorado.org.br Mon Aug 14 12:38:36 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Mon, 14 Aug 2017 12:38:36 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <83ad97f2d3a24b65806055531f426c1c@sap.com> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> Message-ID: <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> Hi Goetz and Martin, Thanks for your comments. The webrev was updated accordingly: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > -----Original Message----- > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > Sent: segunda-feira, 14 de agosto de 2017 07:17 > To: Doerr, Martin ; Gustavo Serra Scalet > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > noreg* is meant to be used intentionally. So you should not match any > illegal values to noreg*. I would implement it like this: > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you feel > like, you can assert for values < -1 and > 31. > > For the copyrights: > You must adapt the copyright year of the Oracle copyright line in any > file you edit. There must always be a trailing comma. I.e., > you change > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > reserved. > to > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > reserved. > or > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights > reserved. > to > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > reserved. > > You may add one line of your own copyright. But this is only common in > new files. New files usually also get the Oracle copyright line. > That's why these files have the SAP copyright. You don't need to update > the SAP copyright :). > > Best regards, > Goetz. > > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Samstag, 12. August 2017 12:01 > > To: Gustavo Serra Scalet ; > > Lindenmaier, Goetz > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > up to 64 registers > > > > Hi Gustavo, > > > > I think returning vsnoregi is the better choice. If you want to check > > the upper limit as well, it should be ">=32". > > Copyright year needs to be updated in the header (first 2 lines) of > > the register_ppc files. > > > > Thanks and best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Freitag, 11. August 2017 22:03 > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > up to 64 registers > > > > Hello Goetz, > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a value > > from 0-32 expected, it was an invalid VectorRegister which will, in > > turn, continue to be invalid as VectorSRegister. > > > > Anyway, do you want me to add a verification of "if ((encoding() < 0) > > || > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > And about the copyright, where do you mean? > > > > Thanks > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > To: Gustavo Serra Scalet ; Doerr, > > > Martin > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > thanks for the new change and posting to the other lists :) > > > > > > I appreciate the shorter function. I think you need to check for > > > noreg and keep that unchanged, though. > > > Some copyrights are not updated to 2017. > > > Consider it reviewed if the new function is fixed. > > > > > > I posted the webrev on the cr server: > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > and added you as contributor. > > > > > > Best regards, > > > Goetz. > > > > > > > -----Original Message----- > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > Sent: Freitag, 11. August 2017 15:55 > > > > To: Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > use up to 64 registers > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > Thanks for the review. > > > > > > > > > -----Original Message----- > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net> > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hi Martin, > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > Thanks > > > > > > > > > > -----Original Message----- > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > To: Gustavo Serra Scalet ; > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hi Gustavo, > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, but > > > > > please update the copyright messages in the modified files. > > > > > > > > > > register_ppc.cpp > > > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > > > prefer something like "return as_VectorSRegister(encoding() + > 32)". > > > > > > > > > > I can sponsor this change. > > > > > > > > > > Thanks and best regards, > > > > > Martin > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > > up to > > > > > 64 registers > > > > > > > > > > Hi, > > > > > > > > > > Could you please review this specific PPC64 change to hotspot? > > > > > The aim of these changes is to allow a more complete usage of > > > > > VSR. I make use of these interfaces on an instrinsic that I plan > > > > > to send next but I decided to separate this change and send it > first. > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > Best regards, > > > > > Gustavo Serra Scalet From goetz.lindenmaier at sap.com Mon Aug 14 12:50:23 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Aug 2017 12:50:23 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> Message-ID: <155aa1c770674d88938f8318012faa0e@sap.com> Hi Gustavo, hmm, I tried to say that noreg is a special value and _not_ an illegal one. You _must_ map vnoreg to vsnoregi and not any other values. You _can_ assert for illegal values: assert (encoding() >=-1 && encoding() <=31, "register encoding out of range") See for example check_klass_subtype_slow_path() on ppc how we use noreg. Please list only first and last year in register_ppc.cpp copyright. Thanks, Goetz. > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Montag, 14. August 2017 14:39 > To: Lindenmaier, Goetz ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hi Goetz and Martin, > > Thanks for your comments. The webrev was updated accordingly: > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > > > > > -----Original Message----- > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > Sent: segunda-feira, 14 de agosto de 2017 07:17 > > To: Doerr, Martin ; Gustavo Serra Scalet > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > noreg* is meant to be used intentionally. So you should not match any > > illegal values to noreg*. I would implement it like this: > > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you feel > > like, you can assert for values < -1 and > 31. > > > > For the copyrights: > > You must adapt the copyright year of the Oracle copyright line in any > > file you edit. There must always be a trailing comma. I.e., > > you change > > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > > reserved. > > to > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > > reserved. > > or > > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights > > reserved. > > to > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > > reserved. > > > > You may add one line of your own copyright. But this is only common in > > new files. New files usually also get the Oracle copyright line. > > That's why these files have the SAP copyright. You don't need to update > > the SAP copyright :). > > > > Best regards, > > Goetz. > > > > > > > > > -----Original Message----- > > > From: Doerr, Martin > > > Sent: Samstag, 12. August 2017 12:01 > > > To: Gustavo Serra Scalet ; > > > Lindenmaier, Goetz > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > I think returning vsnoregi is the better choice. If you want to check > > > the upper limit as well, it should be ">=32". > > > Copyright year needs to be updated in the header (first 2 lines) of > > > the register_ppc files. > > > > > > Thanks and best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > Sent: Freitag, 11. August 2017 22:03 > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hello Goetz, > > > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a value > > > from 0-32 expected, it was an invalid VectorRegister which will, in > > > turn, continue to be invalid as VectorSRegister. > > > > > > Anyway, do you want me to add a verification of "if ((encoding() < 0) > > > || > > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > > > > And about the copyright, where do you mean? > > > > > > Thanks > > > > > > > -----Original Message----- > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > > To: Gustavo Serra Scalet ; Doerr, > > > > Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > thanks for the new change and posting to the other lists :) > > > > > > > > I appreciate the shorter function. I think you need to check for > > > > noreg and keep that unchanged, though. > > > > Some copyrights are not updated to 2017. > > > > Consider it reviewed if the new function is fixed. > > > > > > > > I posted the webrev on the cr server: > > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > > and added you as contributor. > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > -----Original Message----- > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > Sent: Freitag, 11. August 2017 15:55 > > > > > To: Doerr, Martin > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > > > Thanks for the review. > > > > > > > > > > > -----Original Message----- > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > > dev at openjdk.java.net> > > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > > > Thanks > > > > > > > > > > > > -----Original Message----- > > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > > To: Gustavo Serra Scalet ; > > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, but > > > > > > please update the copyright messages in the modified files. > > > > > > > > > > > > register_ppc.cpp > > > > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > > > > prefer something like "return as_VectorSRegister(encoding() + > > 32)". > > > > > > > > > > > > I can sponsor this change. > > > > > > > > > > > > Thanks and best regards, > > > > > > Martin > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > > > up to > > > > > > 64 registers > > > > > > > > > > > > Hi, > > > > > > > > > > > > Could you please review this specific PPC64 change to hotspot? > > > > > > The aim of these changes is to allow a more complete usage of > > > > > > VSR. I make use of these interfaces on an instrinsic that I plan > > > > > > to send next but I decided to separate this change and send it > > first. > > > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > > > Best regards, > > > > > > Gustavo Serra Scalet From martin.doerr at sap.com Mon Aug 14 12:53:21 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Aug 2017 12:53:21 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <155aa1c770674d88938f8318012faa0e@sap.com> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> <155aa1c770674d88938f8318012faa0e@sap.com> Message-ID: <159e123bb0804f329902116fdd1b6644@sap.com> Hi Gustavo, I can do these minor changes before pushing if you're ok with it. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 14. August 2017 14:50 To: Gustavo Serra Scalet ; Doerr, Martin Cc: 'hotspot-compiler-dev at openjdk.java.net' ; hotspot-dev at openjdk.java.net Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers Hi Gustavo, hmm, I tried to say that noreg is a special value and _not_ an illegal one. You _must_ map vnoreg to vsnoregi and not any other values. You _can_ assert for illegal values: assert (encoding() >=-1 && encoding() <=31, "register encoding out of range") See for example check_klass_subtype_slow_path() on ppc how we use noreg. Please list only first and last year in register_ppc.cpp copyright. Thanks, Goetz. > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Montag, 14. August 2017 14:39 > To: Lindenmaier, Goetz ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hi Goetz and Martin, > > Thanks for your comments. The webrev was updated accordingly: > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > > > > > -----Original Message----- > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > Sent: segunda-feira, 14 de agosto de 2017 07:17 > > To: Doerr, Martin ; Gustavo Serra Scalet > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > noreg* is meant to be used intentionally. So you should not match any > > illegal values to noreg*. I would implement it like this: > > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you feel > > like, you can assert for values < -1 and > 31. > > > > For the copyrights: > > You must adapt the copyright year of the Oracle copyright line in any > > file you edit. There must always be a trailing comma. I.e., > > you change > > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > > reserved. > > to > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > > reserved. > > or > > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights > > reserved. > > to > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights > > reserved. > > > > You may add one line of your own copyright. But this is only common in > > new files. New files usually also get the Oracle copyright line. > > That's why these files have the SAP copyright. You don't need to update > > the SAP copyright :). > > > > Best regards, > > Goetz. > > > > > > > > > -----Original Message----- > > > From: Doerr, Martin > > > Sent: Samstag, 12. August 2017 12:01 > > > To: Gustavo Serra Scalet ; > > > Lindenmaier, Goetz > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > I think returning vsnoregi is the better choice. If you want to check > > > the upper limit as well, it should be ">=32". > > > Copyright year needs to be updated in the header (first 2 lines) of > > > the register_ppc files. > > > > > > Thanks and best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > Sent: Freitag, 11. August 2017 22:03 > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hello Goetz, > > > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a value > > > from 0-32 expected, it was an invalid VectorRegister which will, in > > > turn, continue to be invalid as VectorSRegister. > > > > > > Anyway, do you want me to add a verification of "if ((encoding() < 0) > > > || > > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > > > > And about the copyright, where do you mean? > > > > > > Thanks > > > > > > > -----Original Message----- > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > > To: Gustavo Serra Scalet ; Doerr, > > > > Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > thanks for the new change and posting to the other lists :) > > > > > > > > I appreciate the shorter function. I think you need to check for > > > > noreg and keep that unchanged, though. > > > > Some copyrights are not updated to 2017. > > > > Consider it reviewed if the new function is fixed. > > > > > > > > I posted the webrev on the cr server: > > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > > and added you as contributor. > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > -----Original Message----- > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > Sent: Freitag, 11. August 2017 15:55 > > > > > To: Doerr, Martin > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > > > Thanks for the review. > > > > > > > > > > > -----Original Message----- > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > > dev at openjdk.java.net> > > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > > > Thanks > > > > > > > > > > > > -----Original Message----- > > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > > To: Gustavo Serra Scalet ; > > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, but > > > > > > please update the copyright messages in the modified files. > > > > > > > > > > > > register_ppc.cpp > > > > > > to_vsr(): I don't like large code for a trivial computation. I'd > > > > > > prefer something like "return as_VectorSRegister(encoding() + > > 32)". > > > > > > > > > > > > I can sponsor this change. > > > > > > > > > > > > Thanks and best regards, > > > > > > Martin > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > > > up to > > > > > > 64 registers > > > > > > > > > > > > Hi, > > > > > > > > > > > > Could you please review this specific PPC64 change to hotspot? > > > > > > The aim of these changes is to allow a more complete usage of > > > > > > VSR. I make use of these interfaces on an instrinsic that I plan > > > > > > to send next but I decided to separate this change and send it > > first. > > > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > > > Best regards, > > > > > > Gustavo Serra Scalet From gustavo.scalet at eldorado.org.br Mon Aug 14 13:12:59 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Mon, 14 Aug 2017 13:12:59 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: <159e123bb0804f329902116fdd1b6644@sap.com> References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> <155aa1c770674d88938f8318012faa0e@sap.com> <159e123bb0804f329902116fdd1b6644@sap.com> Message-ID: Hi Martin, Yes please. I'm ok with that. @Goetz: sorry, I misunderstood. I read your and Martin's comments and mixed them up. I got it now about keeping your original "if" and adding and "assert". > -----Original Message----- > From: Doerr, Martin [mailto:martin.doerr at sap.com] > Sent: segunda-feira, 14 de agosto de 2017 09:53 > To: Lindenmaier, Goetz ; Gustavo Serra Scalet > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > I can do these minor changes before pushing if you're ok with it. > > Best regards, > Martin > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 14. August 2017 14:50 > To: Gustavo Serra Scalet ; Doerr, Martin > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > to 64 registers > > Hi Gustavo, > > hmm, I tried to say that noreg is a special value and _not_ an illegal > one. > You _must_ map vnoreg to vsnoregi and not any other values. > You _can_ assert for illegal values: > assert (encoding() >=-1 && encoding() <=31, "register encoding out of > range") > > See for example check_klass_subtype_slow_path() on ppc how we use noreg. > > Please list only first and last year in register_ppc.cpp copyright. > > Thanks, > Goetz. > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Montag, 14. August 2017 14:39 > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > up to 64 registers > > > > Hi Goetz and Martin, > > > > Thanks for your comments. The webrev was updated accordingly: > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > > > > > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > Sent: segunda-feira, 14 de agosto de 2017 07:17 > > > To: Doerr, Martin ; Gustavo Serra Scalet > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Gustavo, > > > > > > noreg* is meant to be used intentionally. So you should not match > > > any illegal values to noreg*. I would implement it like this: > > > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you > > > feel like, you can assert for values < -1 and > 31. > > > > > > For the copyrights: > > > You must adapt the copyright year of the Oracle copyright line in > > > any file you edit. There must always be a trailing comma. I.e., you > > > change > > > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > > > reserved. > > > to > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > rights reserved. > > > or > > > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All > > > rights reserved. > > > to > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > rights reserved. > > > > > > You may add one line of your own copyright. But this is only common > > > in new files. New files usually also get the Oracle copyright line. > > > That's why these files have the SAP copyright. You don't need to > > > update the SAP copyright :). > > > > > > Best regards, > > > Goetz. > > > > > > > > > > > > > -----Original Message----- > > > > From: Doerr, Martin > > > > Sent: Samstag, 12. August 2017 12:01 > > > > To: Gustavo Serra Scalet ; > > > > Lindenmaier, Goetz > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > use up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > I think returning vsnoregi is the better choice. If you want to > > > > check the upper limit as well, it should be ">=32". > > > > Copyright year needs to be updated in the header (first 2 lines) > > > > of the register_ppc files. > > > > > > > > Thanks and best regards, > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > > Sent: Freitag, 11. August 2017 22:03 > > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > use up to 64 registers > > > > > > > > Hello Goetz, > > > > > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a > > > > value from 0-32 expected, it was an invalid VectorRegister which > > > > will, in turn, continue to be invalid as VectorSRegister. > > > > > > > > Anyway, do you want me to add a verification of "if ((encoding() < > > > > 0) > > > > || > > > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > > > > > > > And about the copyright, where do you mean? > > > > > > > > Thanks > > > > > > > > > -----Original Message----- > > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > > > To: Gustavo Serra Scalet ; > > > > > Doerr, Martin > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hi Gustavo, > > > > > > > > > > thanks for the new change and posting to the other lists :) > > > > > > > > > > I appreciate the shorter function. I think you need to check for > > > > > noreg and keep that unchanged, though. > > > > > Some copyrights are not updated to 2017. > > > > > Consider it reviewed if the new function is fixed. > > > > > > > > > > I posted the webrev on the cr server: > > > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > > > and added you as contributor. > > > > > > > > > > Best regards, > > > > > Goetz. > > > > > > > > > > > -----Original Message----- > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > Sent: Freitag, 11. August 2017 15:55 > > > > > > To: Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support > > > > > > to use up to 64 registers > > > > > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > > > > > Thanks for the review. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > > > > > > > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > > > To: Gustavo Serra Scalet ; > > > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, > > > > > > > but please update the copyright messages in the modified > files. > > > > > > > > > > > > > > register_ppc.cpp > > > > > > > to_vsr(): I don't like large code for a trivial computation. > > > > > > > I'd prefer something like "return > > > > > > > as_VectorSRegister(encoding() + > > > 32)". > > > > > > > > > > > > > > I can sponsor this change. > > > > > > > > > > > > > > Thanks and best regards, > > > > > > > Martin > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > > use up to > > > > > > > 64 registers > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Could you please review this specific PPC64 change to > hotspot? > > > > > > > The aim of these changes is to allow a more complete usage > > > > > > > of VSR. I make use of these interfaces on an instrinsic that > > > > > > > I plan to send next but I decided to separate this change > > > > > > > and send it > > > first. > > > > > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > > > Webrev: > > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > > > > > Best regards, > > > > > > > Gustavo Serra Scalet From goetz.lindenmaier at sap.com Mon Aug 14 13:35:13 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Aug 2017 13:35:13 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> <155aa1c770674d88938f8318012faa0e@sap.com> <159e123bb0804f329902116fdd1b6644@sap.com> Message-ID: Me too :) > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Montag, 14. August 2017 15:13 > To: Doerr, Martin ; Lindenmaier, Goetz > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hi Martin, > > Yes please. I'm ok with that. > > @Goetz: sorry, I misunderstood. I read your and Martin's comments and mixed > them up. I got it now about keeping your original "if" and adding and "assert". > > > > > -----Original Message----- > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > Sent: segunda-feira, 14 de agosto de 2017 09:53 > > To: Lindenmaier, Goetz ; Gustavo Serra Scalet > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > I can do these minor changes before pushing if you're ok with it. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Montag, 14. August 2017 14:50 > > To: Gustavo Serra Scalet ; Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > hmm, I tried to say that noreg is a special value and _not_ an illegal > > one. > > You _must_ map vnoreg to vsnoregi and not any other values. > > You _can_ assert for illegal values: > > assert (encoding() >=-1 && encoding() <=31, "register encoding out of > > range") > > > > See for example check_klass_subtype_slow_path() on ppc how we use noreg. > > > > Please list only first and last year in register_ppc.cpp copyright. > > > > Thanks, > > Goetz. > > > > > -----Original Message----- > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > Sent: Montag, 14. August 2017 14:39 > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Goetz and Martin, > > > > > > Thanks for your comments. The webrev was updated accordingly: > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > > > > > > > > > > > > > -----Original Message----- > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > Sent: segunda-feira, 14 de agosto de 2017 07:17 > > > > To: Doerr, Martin ; Gustavo Serra Scalet > > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > noreg* is meant to be used intentionally. So you should not match > > > > any illegal values to noreg*. I would implement it like this: > > > > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you > > > > feel like, you can assert for values < -1 and > 31. > > > > > > > > For the copyrights: > > > > You must adapt the copyright year of the Oracle copyright line in > > > > any file you edit. There must always be a trailing comma. I.e., you > > > > change > > > > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > > > > reserved. > > > > to > > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > > rights reserved. > > > > or > > > > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All > > > > rights reserved. > > > > to > > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > > rights reserved. > > > > > > > > You may add one line of your own copyright. But this is only common > > > > in new files. New files usually also get the Oracle copyright line. > > > > That's why these files have the SAP copyright. You don't need to > > > > update the SAP copyright :). > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Doerr, Martin > > > > > Sent: Samstag, 12. August 2017 12:01 > > > > > To: Gustavo Serra Scalet ; > > > > > Lindenmaier, Goetz > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hi Gustavo, > > > > > > > > > > I think returning vsnoregi is the better choice. If you want to > > > > > check the upper limit as well, it should be ">=32". > > > > > Copyright year needs to be updated in the header (first 2 lines) > > > > > of the register_ppc files. > > > > > > > > > > Thanks and best regards, > > > > > Martin > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > > > Sent: Freitag, 11. August 2017 22:03 > > > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hello Goetz, > > > > > > > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a > > > > > value from 0-32 expected, it was an invalid VectorRegister which > > > > > will, in turn, continue to be invalid as VectorSRegister. > > > > > > > > > > Anyway, do you want me to add a verification of "if ((encoding() < > > > > > 0) > > > > > || > > > > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > > > > > > > > > > And about the copyright, where do you mean? > > > > > > > > > > Thanks > > > > > > > > > > > -----Original Message----- > > > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > > > > To: Gustavo Serra Scalet ; > > > > > > Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > thanks for the new change and posting to the other lists :) > > > > > > > > > > > > I appreciate the shorter function. I think you need to check for > > > > > > noreg and keep that unchanged, though. > > > > > > Some copyrights are not updated to 2017. > > > > > > Consider it reviewed if the new function is fixed. > > > > > > > > > > > > I posted the webrev on the cr server: > > > > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > > > > and added you as contributor. > > > > > > > > > > > > Best regards, > > > > > > Goetz. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > Sent: Freitag, 11. August 2017 15:55 > > > > > > > To: Doerr, Martin > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support > > > > > > > to use up to 64 registers > > > > > > > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > > > > > > > Thanks for the review. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > > > > > > > > > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > > > > To: Gustavo Serra Scalet ; > > > > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, > > > > > > > > but please update the copyright messages in the modified > > files. > > > > > > > > > > > > > > > > register_ppc.cpp > > > > > > > > to_vsr(): I don't like large code for a trivial computation. > > > > > > > > I'd prefer something like "return > > > > > > > > as_VectorSRegister(encoding() + > > > > 32)". > > > > > > > > > > > > > > > > I can sponsor this change. > > > > > > > > > > > > > > > > Thanks and best regards, > > > > > > > > Martin > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > > > use up to > > > > > > > > 64 registers > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Could you please review this specific PPC64 change to > > hotspot? > > > > > > > > The aim of these changes is to allow a more complete usage > > > > > > > > of VSR. I make use of these interfaces on an instrinsic that > > > > > > > > I plan to send next but I decided to separate this change > > > > > > > > and send it > > > > first. > > > > > > > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > > > > Webrev: > > > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Gustavo Serra Scalet From stuart.monteith at linaro.org Mon Aug 14 14:03:52 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 14 Aug 2017 15:03:52 +0100 Subject: [10] RFR(S): JDK-8184943: AARCH64: Intrinsify hasNegatives In-Reply-To: References: <7f1a11ea-c795-a26a-a104-78ae3aac6930@redhat.com> <61a090b3-47bd-dacd-eeaa-0b201a4a4ee7@bell-sw.com> <2dc11588-fec0-603b-faf1-e214e9feeb2d@redhat.com> <10ae906b-9cfc-cd5b-4b66-ecec1af233b1@redhat.com> <9605fe42-89fa-a7a9-91df-db895c0195aa@bell-sw.com> Message-ID: Hello, Please find below hyperlinks to the jmh results - the graphs show the performance relative to the "steam" method - compiled by C2. There is an improvement for all platforms. With 100,000 bytes there is no improvement, but that is an unlikely circumstance. http://people.linaro.org/~stuart.monteith/hasneg-last/hasnegA-last.svg http://people.linaro.org/~stuart.monteith/hasneg-last/hasnegB-last.svg http://people.linaro.org/~stuart.monteith/hasneg-last/hasnegC-last.svg BR, Stuart On 14 August 2017 at 11:47, Stuart Monteith wrote: > Thanks Dmitrij, > I'll look at what you've done and try your patch on my machines. > > BR, > Stuart > > On 11 August 2017 at 18:30, Dmitrij Pochepko > wrote: >> Hi, >> >> please review a new version of this RFR [1] which is significantly >> re-worked. >> >> >> Changes compared to original posting: >> >> - 2 versions of hasNegatives intrinsic were merged, which result in good >> performance for both small and large array. >> >> - large array case and "at-the-end-of-mem-page" case were moved to stub to >> save code cache and help register allocator >> >> >> Raw performance numbers for the original hasNegativesBench.loopingFastMethod >> [2] are here[3] and accompanied by updated comparison charts for Raspberry >> Pi 3 [4] and ThunderX T88 [5]. In short, intrinsified hasNegatives is x4 >> faster on T88 and x2.5 on R-Pi for 31 byte array and up to 8 times faster on >> large arrays. >> >> I've also created small and simple benchmark [6] which demonstrates >> performance difference for string constructor for strings without negative >> byte values. Raw results [7] shows significantly increased performance on >> Thunder X T88. Results also can be seen on comparison charts [8]. Due to >> large amount of allocations and gc this benchmark is not applicable for >> R-Pi, which has 1GB system memory and sd-card as main drive. >> >> >> This patch should be considered as patch with 2 contributors >> (stuart.monteith at linaro.org and dmitrij.pochepko at bell-sw.com (openjdk login >> dpochepk)). Also I'd like to thank Andrew Haley for early reviews and >> consulting. >> >> No regressions were found via jtreg tests. >> >> Thanks, >> >> Dmitrij >> >> >> [1] Webrev: http://cr.openjdk.java.net/~dpochepk/8184943/webrev.02/ >> [2] http://cr.openjdk.java.net/~aph/HasNegativesBench/ >> [3] http://cr.openjdk.java.net/~dpochepk/8184943/perf_numbers.txt >> [4] http://cr.openjdk.java.net/~dpochepk/8184943/Cortex_A53_comparison.png >> [5] http://cr.openjdk.java.net/~dpochepk/8184943/ThunderX_comparison.png >> [6] >> http://cr.openjdk.java.net/~dpochepk/8184943/StringConstructorBench.java >> [7] http://cr.openjdk.java.net/~dpochepk/8184943/StringConstructorBench.txt >> [8] >> http://cr.openjdk.java.net/~dpochepk/8184943/ThunderX-StringConstructor.png >> >> >> On 21.07.2017 11:26, Andrew Haley wrote: >>> >>> On 20/07/17 19:27, Dmitrij Pochepko wrote: >>>> >>>> Probably best way would be to merge large data loads from my patch and >>>> Stuart's lightning-fast small arrays handling. >>> >>> Yes. >>> >>>> I'll be happy to merge these ideas in one intrinsic that works fastest >>>> on small and large arrays if Stuart does not mind. I could use some help >>>> testing the final solution on some of the HW we don't have. I don't mind >>>> if Stuart want to merge it, then we'll help him with testing on h/w he >>>> doesn't have. >>> >>> Have fun! The performance to care about is small strings (< 31 bytes) >>> and, >>> less commonly, very long ones. Super-fast handling of small strings is >>> very important. >>> >> From martin.doerr at sap.com Mon Aug 14 15:04:00 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Aug 2017 15:04:00 +0000 Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers In-Reply-To: References: <3ef7698470ca4e9fa679117cc643e8e2@serv030.corp.eldorado.org.br> <4c61f03b278d46959ca496f7c31db929@sap.com> <2b2ad6d82d40458ab3ba01355dcf0f73@serv031.corp.eldorado.org.br> <83ad97f2d3a24b65806055531f426c1c@sap.com> <43bf3a0ec9244968a07f492e6117c1c0@serv030.corp.eldorado.org.br> <155aa1c770674d88938f8318012faa0e@sap.com> <159e123bb0804f329902116fdd1b6644@sap.com> Message-ID: <1363c2f592e94e5ba208bfad67f0a627@sap.com> Tested and pushed with the modification. Note that the range assertion is done in encoding(). Thanks for the contribution and for reviewing. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 14. August 2017 15:35 To: Gustavo Serra Scalet ; Doerr, Martin Cc: 'hotspot-compiler-dev at openjdk.java.net' ; hotspot-dev at openjdk.java.net Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 registers Me too :) > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Montag, 14. August 2017 15:13 > To: Doerr, Martin ; Lindenmaier, Goetz > > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up to 64 > registers > > Hi Martin, > > Yes please. I'm ok with that. > > @Goetz: sorry, I misunderstood. I read your and Martin's comments and mixed > them up. I got it now about keeping your original "if" and adding and "assert". > > > > > -----Original Message----- > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > Sent: segunda-feira, 14 de agosto de 2017 09:53 > > To: Lindenmaier, Goetz ; Gustavo Serra Scalet > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > I can do these minor changes before pushing if you're ok with it. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Montag, 14. August 2017 14:50 > > To: Gustavo Serra Scalet ; Doerr, Martin > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use up > > to 64 registers > > > > Hi Gustavo, > > > > hmm, I tried to say that noreg is a special value and _not_ an illegal > > one. > > You _must_ map vnoreg to vsnoregi and not any other values. > > You _can_ assert for illegal values: > > assert (encoding() >=-1 && encoding() <=31, "register encoding out of > > range") > > > > See for example check_klass_subtype_slow_path() on ppc how we use noreg. > > > > Please list only first and last year in register_ppc.cpp copyright. > > > > Thanks, > > Goetz. > > > > > -----Original Message----- > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > Sent: Montag, 14. August 2017 14:39 > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > up to 64 registers > > > > > > Hi Goetz and Martin, > > > > > > Thanks for your comments. The webrev was updated accordingly: > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.02/ > > > > > > > > > > > > > -----Original Message----- > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > Sent: segunda-feira, 14 de agosto de 2017 07:17 > > > > To: Doerr, Martin ; Gustavo Serra Scalet > > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to use > > > > up to 64 registers > > > > > > > > Hi Gustavo, > > > > > > > > noreg* is meant to be used intentionally. So you should not match > > > > any illegal values to noreg*. I would implement it like this: > > > > if (encoding() == vnoreg->encoding()) { return vsnoregi; } If you > > > > feel like, you can assert for values < -1 and > 31. > > > > > > > > For the copyrights: > > > > You must adapt the copyright year of the Oracle copyright line in > > > > any file you edit. There must always be a trailing comma. I.e., you > > > > change > > > > * Copyright (c) 2000, Oracle and/or its affiliates. All rights > > > > reserved. > > > > to > > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > > rights reserved. > > > > or > > > > * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All > > > > rights reserved. > > > > to > > > > * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All > > > > rights reserved. > > > > > > > > You may add one line of your own copyright. But this is only common > > > > in new files. New files usually also get the Oracle copyright line. > > > > That's why these files have the SAP copyright. You don't need to > > > > update the SAP copyright :). > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Doerr, Martin > > > > > Sent: Samstag, 12. August 2017 12:01 > > > > > To: Gustavo Serra Scalet ; > > > > > Lindenmaier, Goetz > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hi Gustavo, > > > > > > > > > > I think returning vsnoregi is the better choice. If you want to > > > > > check the upper limit as well, it should be ">=32". > > > > > Copyright year needs to be updated in the header (first 2 lines) > > > > > of the register_ppc files. > > > > > > > > > > Thanks and best regards, > > > > > Martin > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > > > Sent: Freitag, 11. August 2017 22:03 > > > > > To: Lindenmaier, Goetz ; Doerr, Martin > > > > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > use up to 64 registers > > > > > > > > > > Hello Goetz, > > > > > > > > > > About the noreg: if the VectorRegisterImpl::encoding() is not a > > > > > value from 0-32 expected, it was an invalid VectorRegister which > > > > > will, in turn, continue to be invalid as VectorSRegister. > > > > > > > > > > Anyway, do you want me to add a verification of "if ((encoding() < > > > > > 0) > > > > > || > > > > > (encoding() > 32)) return vsnoregi;" before? Or an assert? > > > > > > > > > > > > > > > And about the copyright, where do you mean? > > > > > > > > > > Thanks > > > > > > > > > > > -----Original Message----- > > > > > > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > > > > > > Sent: sexta-feira, 11 de agosto de 2017 11:56 > > > > > > To: Gustavo Serra Scalet ; > > > > > > Doerr, Martin > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > use up to 64 registers > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > thanks for the new change and posting to the other lists :) > > > > > > > > > > > > I appreciate the shorter function. I think you need to check for > > > > > > noreg and keep that unchanged, though. > > > > > > Some copyrights are not updated to 2017. > > > > > > Consider it reviewed if the new function is fixed. > > > > > > > > > > > > I posted the webrev on the cr server: > > > > > > http://cr.openjdk.java.net/~goetz/wr17/8185969-ppcAsm/webrev.01/ > > > > > > and added you as contributor. > > > > > > > > > > > > Best regards, > > > > > > Goetz. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > Sent: Freitag, 11. August 2017 15:55 > > > > > > > To: Doerr, Martin > > > > > > > Cc: 'hotspot-compiler-dev at openjdk.java.net' > > > > > > dev at openjdk.java.net>; hotspot-dev at openjdk.java.net > > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR support > > > > > > > to use up to 64 registers > > > > > > > > > > > > > > It worked for me Martin. Please check the new webrev: > > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev.01/ > > > > > > > > > > > > > > Thanks for the review. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > > Sent: quinta-feira, 10 de agosto de 2017 14:21 > > > > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > > > > > > > > > > > > > Subject: FW: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > > > > > Alright. I'll analyze that and update to a new webrev. > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > > > > > > > Sent: quarta-feira, 9 de agosto de 2017 09:58 > > > > > > > > To: Gustavo Serra Scalet ; > > > > > > > > ppc-aix-port- dev at openjdk.java.net > > > > > > > > Subject: RE: [10] RFR(S): 8185969: PPC64: Improve VSR > > > > > > > > support to use up to 64 registers > > > > > > > > > > > > > > > > Hi Gustavo, > > > > > > > > > > > > > > > > seems like you're preparing new VSR code :-) Nice change, > > > > > > > > but please update the copyright messages in the modified > > files. > > > > > > > > > > > > > > > > register_ppc.cpp > > > > > > > > to_vsr(): I don't like large code for a trivial computation. > > > > > > > > I'd prefer something like "return > > > > > > > > as_VectorSRegister(encoding() + > > > > 32)". > > > > > > > > > > > > > > > > I can sponsor this change. > > > > > > > > > > > > > > > > Thanks and best regards, > > > > > > > > Martin > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > > > > Sent: Dienstag, 8. August 2017 22:19 > > > > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > > > > Subject: [10] RFR(S): 8185969: PPC64: Improve VSR support to > > > > > > > > use up to > > > > > > > > 64 registers > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Could you please review this specific PPC64 change to > > hotspot? > > > > > > > > The aim of these changes is to allow a more complete usage > > > > > > > > of VSR. I make use of these interfaces on an instrinsic that > > > > > > > > I plan to send next but I decided to separate this change > > > > > > > > and send it > > > > first. > > > > > > > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185969 > > > > > > > > Webrev: > > > > > > > > https://gut.github.io/openjdk/webrev/JDK-8185969/webrev/ > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Gustavo Serra Scalet From vladimir.kozlov at oracle.com Mon Aug 14 15:15:40 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Aug 2017 08:15:40 -0700 Subject: RFR: 8186163: bad signatures should be detected by MetaAccessProvider.parseMethodDescriptor In-Reply-To: <84C45CA9-236C-4112-A7A8-BFC7E184E3EA@oracle.com> References: <35936655-C9D0-4DB7-886D-95338C547B91@oracle.com> <84C45CA9-236C-4112-A7A8-BFC7E184E3EA@oracle.com> Message-ID: <7d34a1e7-66db-ae85-3457-1683e6bb4ce7@oracle.com> On 8/12/17 2:43 PM, Doug Simon wrote: > >> On 12 Aug 2017, at 19:24, Vladimir Kozlov wrote: >> >> Looks good. > > Thanks. Do I need another review? Yes. Ask Igor to look. > > BTW, please remind me of the process for requesting a 9u back port. It's not so important for this change but may be for others. I added 9-bp label to the bug. Thanks, Vladimir > > -Doug > >> >> On 8/12/17 4:05 AM, Doug Simon wrote: >>> Please review this small change to improve error handling when an invalid string is passed to MetaAccessProvider.parseMethodDescriptor >>> https://bugs.openjdk.java.net/browse/JDK-8186163 >>> http://cr.openjdk.java.net/~dnsimon/8186163/ >>> -Doug > From igor.veresov at oracle.com Mon Aug 14 20:44:41 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 14 Aug 2017 13:44:41 -0700 Subject: RFR: 8186163: bad signatures should be detected by MetaAccessProvider.parseMethodDescriptor In-Reply-To: <35936655-C9D0-4DB7-886D-95338C547B91@oracle.com> References: <35936655-C9D0-4DB7-886D-95338C547B91@oracle.com> Message-ID: Looks good to me too. igor > On Aug 12, 2017, at 4:05 AM, Doug Simon wrote: > > Please review this small change to improve error handling when an invalid string is passed to MetaAccessProvider.parseMethodDescriptor > > https://bugs.openjdk.java.net/browse/JDK-8186163 > http://cr.openjdk.java.net/~dnsimon/8186163/ > > -Doug From doug.simon at oracle.com Mon Aug 14 20:49:05 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 14 Aug 2017 22:49:05 +0200 Subject: RFR: 8186163: bad signatures should be detected by MetaAccessProvider.parseMethodDescriptor In-Reply-To: References: <35936655-C9D0-4DB7-886D-95338C547B91@oracle.com> Message-ID: <0025A932-5210-4352-B13B-753CAF832D80@oracle.com> Thanks for the review. > On 14 Aug 2017, at 22:44, Igor Veresov wrote: > > Looks good to me too. > > igor > >> On Aug 12, 2017, at 4:05 AM, Doug Simon wrote: >> >> Please review this small change to improve error handling when an invalid string is passed to MetaAccessProvider.parseMethodDescriptor >> >> https://bugs.openjdk.java.net/browse/JDK-8186163 >> http://cr.openjdk.java.net/~dnsimon/8186163/ >> >> -Doug > From nils.eliasson at oracle.com Tue Aug 15 14:18:42 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 15 Aug 2017 16:18:42 +0200 Subject: [10] RFR(XS): 8169766: c1 + Xcomp reresolving call target every invocation In-Reply-To: References: <8c45aa96-7f8a-506c-f7ba-6ad12f7a3201@oracle.com> Message-ID: Thank you, Vladimir! // Nils On 2017-08-11 19:09, Vladimir Kozlov wrote: > On 8/11/17 7:42 AM, Nils Eliasson wrote: >> Hi Vladimir, >> >> >> On 2017-08-07 18:42, Vladimir Kozlov wrote: >>> Good. >>> >>> Question. Both, this and 8160543, bugs talk about C1 only. Does the >>> problem exist with C2 too? >> >> The problem only exists with C1. The code is shared with C2, but C2 >> won't be affected because it never tries to emit optimized calls to >> unloaded methods. >> >> (Static bound methods that are loaded have the is_optimized flag set >> - so they still become optimized calls) >> >>> Comments in compiledIC.cpp also talk about C1. Should we guard >>> 8160543 and this changes in compiledIC.cpp with >>> if (method_code->is_compiled_by_c1()) ? >> >> No, I am removing the c1 specific parts, what's left is used by both. >> >> The static_bound argument isn't used anymore and can be removed from >> the function call: >> >> http://cr.openjdk.java.net/~neliasso/8169766/webrev.02/ > > Good. > > Thanks, > Vladimir > >> >> If I put a diff of the two changes in this function together it >> becomes more clear why the first one was insufficient. >> >> >> - if (static_bound || is_optimized) { >> + if (is_optimized) { >> entry = method_code->verified_entry_point(); >> } else { >> entry = method_code->entry_point(); } >> .... - info.set_compiled_entry(entry, (static_bound || is_optimized) >> ? NULL : receiver_klass, is_optimized); >> + info.set_compiled_entry(entry, is_optimized ? NULL : >> receiver_klass, is_optimized); >> >> >> Thanks for having a look, >> Nils >> >>> Thanks, Vladimir On 8/7/17 7:16 AM, Nils Eliasson wrote: >>>> Hi, Please review this patch. In bug >>>> https://bugs.openjdk.java.net/browse/JDK-8160543 I changed the >>>> behaviour for some calls in c1 generated code to make it comply >>>> with the VM-spec - LinkageError must be thrown before NPE. One >>>> detail was missed in that fix: Some calls, that was static bound >>>> and became optimized virtual calls, now became vanilla virtual >>>> calls. The virtual calls use the unverified entry, but for the >>>> static_bound calls the reciever_klass was not set making the >>>> receiver check fail on every invocation. This scenario is only >>>> common with Xcomp when methods are compiled that have call targets >>>> that have not been run earlier. Also a c1 thing, c2 uses >>>> uncommontraps for this case. Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8160543 Webrev: >>>> http://cr.openjdk.java.net/~neliasso/8169766/webrev.01/ Regards, >>>> Nils Eliasson From bob.vandette at oracle.com Tue Aug 15 18:55:52 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 15 Aug 2017 14:55:52 -0400 Subject: RFR: JDK-8186115 - libelf still referenced after 8172670 Message-ID: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> Please review these changes for JDK 10 that remove all dependencies on libelf from the JDK build system. Bug: https://bugs.openjdk.java.net/browse/JDK-8186115 Webrev: http://cr.openjdk.java.net/~bobv/8186115/ Compiler team: Please check CodeSectionProcessor. Is the stepping through all foreign call still necessary? I only removed the comment. Thanks, Bob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Aug 15 19:10:32 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Aug 2017 12:10:32 -0700 Subject: RFR: JDK-8186115 - libelf still referenced after 8172670 In-Reply-To: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> References: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> Message-ID: On 8/15/17 11:55 AM, Bob Vandette wrote: > Please review these changes for JDK 10 that remove all dependencies on > libelf from the JDK > build system. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8186115 > > Webrev: > http://cr.openjdk.java.net/~bobv/8186115/ Good. > > Compiler team: Please check CodeSectionProcessor. Is the stepping > through all > foreign call still necessary? I only removed the comment. I will look. It could be the problem was not libelf but loader. Thanks, Vladimir > > Thanks, > Bob. > From jaroslav.tulach at oracle.com Mon Aug 14 17:06:52 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 14 Aug 2017 19:06:52 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <14332343.G5UyyslDlL@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> <14332343.G5UyyslDlL@pracovni> Message-ID: <3471900.phhlVALLFS@pracovni> On ?tvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote: > On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: > > On 27/07/2017 10:07, Jaroslav Tulach wrote: > > > Yes, it seems like a desirable goal to let Graal compiler work with just > > > java.base. Is there a description how to build JDK9/10 with just > > > java.base > > > that I could follow and test against? > > > > You can use jlink to create a run-time image that only contains > > java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base > > --output smalljre). > > Status update: I've just tried to run Graal compiler against JDK9 with only > java.base and jdk.internal.vm.ci modules, and there are some problems. I > need to resolve them first before I provide updated version of my patch. FYI: As of https://github.com/graalvm/graal/commit/ ca9071941a1be7f1a3725529ecc231ff621d5ed0 the Graal compiler can run with java.base, jdk.unsupported and jdk.vm.ci only modules. But it wasn't easy, especially the http://wiki.apidesign.org/wiki/ PropertyChangeListener required a bit of work. -jt From cthalinger at twitter.com Wed Aug 16 07:37:24 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 16 Aug 2017 09:37:24 +0200 Subject: RFR: JDK-8186115 - libelf still referenced after 8172670 In-Reply-To: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> References: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> Message-ID: <83B517EB-14DD-400C-BB35-F7C69AA40028@twitter.com> > On Aug 15, 2017, at 8:55 PM, Bob Vandette wrote: > > Please review these changes for JDK 10 that remove all dependencies on libelf from the JDK > build system. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8186115 > > Webrev: > http://cr.openjdk.java.net/~bobv/8186115/ Looks good. > > Compiler team: Please check CodeSectionProcessor. Is the stepping through all > foreign call still necessary? I only removed the comment. > > Thanks, > Bob. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at bell-sw.com Wed Aug 16 15:13:26 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Wed, 16 Aug 2017 18:13:26 +0300 Subject: [10] RFR(S): 8186297: AARCH64: Intrinsify Unsafe.compareAndSetByte and compareAndSetShort Message-ID: Hi, please review small diff for JDK-8186297: AARCH64: Intrinsify Unsafe.compareAndSetByte and compareAndSetShort This small patch adds intrinsic for Unsafe::compareAndSetByte and Unsafe::compareAndSetShort in a same manner as existing compareAndSetInt/Long intrinsics are implemented. Intrinsic has shorter code with less barriers and overall instruction count. Generated assembly examples for short method: private static void testMethod() { unsafe.compareAndSetByte(null, BYTE_ARRAY_ADDR, (byte)0, (byte)1); } are here: - baseline version: http://cr.openjdk.java.net/~dpochepk/8186297/baseline_byte_assembly.txt - intrinsified version: http://cr.openjdk.java.net/~dpochepk/8186297/intrinsic_byte_assembly.txt I also created small benchmark which demonstrates performance difference(10-15%). Benchmark code is here: http://cr.openjdk.java.net/~dpochepk/8186297/UnsafeBench.java (should be launched with --add-opens java.base/jdk.internal.misc=ALL-UNNAMED to have access to unsafe) Performance results for ThunderX T88 are here: http://cr.openjdk.java.net/~dpochepk/8186297/ThunderX_T88_results.txt Performance results to Cortex A53 (R-Pi 3) are here: http://cr.openjdk.java.net/~dpochepk/8186297/CortexA53_results.txt webrev: http://cr.openjdk.java.net/~dpochepk/8186297/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8186297 I also run hotspot jtreg tests in compiler/unsafe/* and found no regressions. Thanks, Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Aug 16 15:52:31 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 16 Aug 2017 11:52:31 -0400 Subject: [aarch64-port-dev ] [10] RFR(S): 8186297: AARCH64: Intrinsify Unsafe.compareAndSetByte and compareAndSetShort In-Reply-To: References: Message-ID: <56bb1972-9439-ed56-cd27-1e8a4ba9b9ed@redhat.com> On 16/08/17 11:13, Dmitrij Pochepko wrote: > webrev: http://cr.openjdk.java.net/~dpochepk/8186297/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8186297 What about WeakCompareAndSwap ? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Aug 16 16:04:34 2017 From: dmitrij.pochepko at bell-sw.com (dmitrij.pochepko at bell-sw.com) Date: Wed, 16 Aug 2017 19:04:34 +0300 Subject: [aarch64-port-dev ] [10] RFR(S): 8186297: AARCH64: Intrinsify Unsafe.compareAndSetByte and compareAndSetShort In-Reply-To: <56bb1972-9439-ed56-cd27-1e8a4ba9b9ed@redhat.com> References: <56bb1972-9439-ed56-cd27-1e8a4ba9b9ed@redhat.com> Message-ID: <276711502899474@web19o.yandex.ru> An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Aug 16 16:33:37 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 16 Aug 2017 12:33:37 -0400 Subject: [aarch64-port-dev ] [10] RFR(S): 8186297: AARCH64: Intrinsify Unsafe.compareAndSetByte and compareAndSetShort In-Reply-To: <276711502899474@web19o.yandex.ru> References: <56bb1972-9439-ed56-cd27-1e8a4ba9b9ed@redhat.com> <276711502899474@web19o.yandex.ru> Message-ID: <4aff90da-1cd1-cb53-a59a-e312209fb7ec@redhat.com> On 16/08/17 12:04, dmitrij.pochepko at bell-sw.com wrote: > WeakCompareAndSwap seems to be already implemented. How weird; I wonder how that happened. OK, the patch is good. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Wed Aug 16 16:37:11 2017 From: dmitrij.pochepko at bell-sw.com (dmitrij.pochepko at bell-sw.com) Date: Wed, 16 Aug 2017 19:37:11 +0300 Subject: [aarch64-port-dev ] [10] RFR(S): 8186297: AARCH64: Intrinsify Unsafe.compareAndSetByte and compareAndSetShort In-Reply-To: <4aff90da-1cd1-cb53-a59a-e312209fb7ec@redhat.com> References: <56bb1972-9439-ed56-cd27-1e8a4ba9b9ed@redhat.com> <276711502899474@web19o.yandex.ru> <4aff90da-1cd1-cb53-a59a-e312209fb7ec@redhat.com> Message-ID: <426351502901431@web35o.yandex.ru> An HTML attachment was scrubbed... URL: From adinn at redhat.com Wed Aug 16 16:44:16 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 16 Aug 2017 17:44:16 +0100 Subject: [aarch64-port-dev ] [10] RFR(S): 8186297: AARCH64: Intrinsify Unsafe.compareAndSetByte and compareAndSetShort In-Reply-To: <4aff90da-1cd1-cb53-a59a-e312209fb7ec@redhat.com> References: <56bb1972-9439-ed56-cd27-1e8a4ba9b9ed@redhat.com> <276711502899474@web19o.yandex.ru> <4aff90da-1cd1-cb53-a59a-e312209fb7ec@redhat.com> Message-ID: <8bf1e713-d037-3b36-5048-918ec6f86206@redhat.com> On 16/08/17 17:33, Andrew Haley wrote: > On 16/08/17 12:04, dmitrij.pochepko at bell-sw.com wrote: > >> WeakCompareAndSwap seems to be already implemented. > How weird; I wonder how that happened. OK, the patch is good. No, please cancel that. The case statement in is_CAS should not be modified. It is used by the code which optimizes out dmbs and replaces the stores and loads with releasing stores and acquiring loads. If you look at the rules for CopareAndswapI/L/N/P you will see that they come in pairs. Your single rules do not include the matching pair rule. They will be able to generate the code that is used when dmb barriers are generated. But the change to the is_CAS case switch will stop the barriers being generated. If you revert is_CAS back to what it was then your single rules will be ok. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From gustavo.scalet at eldorado.org.br Wed Aug 16 16:49:32 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Wed, 16 Aug 2017 16:49:32 +0000 Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics In-Reply-To: <16e8b68451e94eb79cdd7d9cb5d7984c@sap.com> References: <1f159ee480284095b8e5c3f444dceb96@serv031.corp.eldorado.org.br> <16e8b68451e94eb79cdd7d9cb5d7984c@sap.com> Message-ID: <2425566a8ff74051af485c919a0bf5ee@serv030.corp.eldorado.org.br> Hi Martin, Thanks for dedicated review. It took me a while to be able to work on this but I hope to have your points solved. Please check below the review as well as my comments quoting your email: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > -----Original Message----- > First of all, C2 does not perform sign extend when calling stubs. The > int parms need to get zero/sign extended. (Could even be done without > extra instructions by replacing sldi -> rldicl, cmpdi -> extsw_ in some > cases.) Does it make a difference on my case? I guess you are talking about mulAdd preparation code. The only aspect I found about him is to force the cast from 32 bits -> 64 bits by cleaning higher bits. Offset is a signed integer but it can't be negative anyway. So I changed from: sldi (R5_ARG3, R5_ARG3, 2); to: rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > macroAssembler_ppc.cpp: > - Indentation should be 2 spaces. Done > stubGenerator_ppc:cpp: > - or_, addi_ should get replaced by orr, addi when CR0 result is not > needed. Done > - Where is lplw initialized? It should be initialized with 0, I missed that... > - I believe that the updating load/store instructions e.g. lwzu don't > perform well on some processors. At least using stwu 2 times in the loop > doesn't make sense. You are right. I could manipulate the bits differently and ended up with a single stdu in the loop. Neat! Although I could not reduce the total number of instructions. > - Note: It should be possible to use 8 byte instead of 4 byte > instructions: MacroAssembler::multiply64, addc, adde. But I'm not > requesting to change that because I guess it would make the code very > complicated, especially when supporting both endianess versions. Yes, that would require a new analysis on this code. May we consider it next? As you said, I prefer having an initial version that looks as simple as the original java code. > - The squareToLen stub implementation is very close the Java > implementation. So it'd be interesting to understand what C2 doesn't do > as well as the hand written assembly code. Do you know that? (Not > absolutely necessary for accepting this change as long as the stub is > measurably faster.) I don't know either. Basically I chose doing it because I noticed some performance gain on SpecJVM2008 when analyzing X64. Then, taking a closer look, I didn't notice any AVX or some special instructions on X64 so I decided to try it on ppc64 by using some basic assembly. Thanks > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: Donnerstag, 10. August 2017 19:22 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics > > > > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > To: ppc-aix-port-dev at openjdk.java.net > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen > intrinsics > > Hi, > > Could you please review this specific PPC64 change to hotspot? By > implementing these intrinsics I noticed a small improvement with > microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, only > when backporting to JDK8 an improvement was noticed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > Motivation for this implementation: > https://twitter.com/ijuma/status/698309312498835457 > > Best regards, > Gustavo Serra Scalet From david.holmes at oracle.com Thu Aug 17 05:50:28 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Aug 2017 15:50:28 +1000 Subject: RFR: JDK-8186115 - libelf still referenced after 8172670 In-Reply-To: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> References: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> Message-ID: <1fce5ab6-7df0-3cce-c8a2-2f7b31694a32@oracle.com> Hi Bob, These changes all seem fine to me. Thanks, David On 16/08/2017 4:55 AM, Bob Vandette wrote: > Please review these changes for JDK 10 that remove all dependencies on libelf from the JDK > build system. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8186115 > > Webrev: > http://cr.openjdk.java.net/~bobv/8186115/ > > Compiler team: Please check CodeSectionProcessor. Is the stepping through all > foreign call still necessary? I only removed the comment. > > Thanks, > Bob. > > > From dmitrij.pochepko at bell-sw.com Thu Aug 17 10:38:10 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 17 Aug 2017 13:38:10 +0300 Subject: [aarch64-port-dev ] [10] RFR(S): 8186297: AARCH64: Intrinsify Unsafe.compareAndSetByte and compareAndSetShort In-Reply-To: <8bf1e713-d037-3b36-5048-918ec6f86206@redhat.com> References: <56bb1972-9439-ed56-cd27-1e8a4ba9b9ed@redhat.com> <276711502899474@web19o.yandex.ru> <4aff90da-1cd1-cb53-a59a-e312209fb7ec@redhat.com> <8bf1e713-d037-3b36-5048-918ec6f86206@redhat.com> Message-ID: Hi Andrew, thank you for catching this! here is a webrev that fixes the issue you pointed out to: http://cr.openjdk.java.net/~dpochepk/8186297/webrev.02/ I believe it?s good enough for the Unsafe intrinsic which is the purpose of this fix. I?ll consider adding pair rules and tidy up that area in a separate enhancement if you don?t mind. -Dmitrij On 16.08.2017 19:44, Andrew Dinn wrote: > On 16/08/17 17:33, Andrew Haley wrote: >> On 16/08/17 12:04, dmitrij.pochepko at bell-sw.com wrote: >> >>> WeakCompareAndSwap seems to be already implemented. >> How weird; I wonder how that happened. OK, the patch is good. > No, please cancel that. > > The case statement in is_CAS should not be modified. It is used by the > code which optimizes out dmbs and replaces the stores and loads with > releasing stores and acquiring loads. If you look at the rules for > CopareAndswapI/L/N/P you will see that they come in pairs. Your single > rules do not include the matching pair rule. They will be able to > generate the code that is used when dmb barriers are generated. But the > change to the is_CAS case switch will stop the barriers being generated. > If you revert is_CAS back to what it was then your single rules will be ok. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Thu Aug 17 10:43:34 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 17 Aug 2017 10:43:34 +0000 Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics In-Reply-To: <2425566a8ff74051af485c919a0bf5ee@serv030.corp.eldorado.org.br> References: <1f159ee480284095b8e5c3f444dceb96@serv031.corp.eldorado.org.br> <16e8b68451e94eb79cdd7d9cb5d7984c@sap.com> <2425566a8ff74051af485c919a0bf5ee@serv030.corp.eldorado.org.br> Message-ID: <4ec93a6bcbe14cf99c2fa02d50a18965@sap.com> Hi Gustavo, thanks for the update. 1. Sign extending offset and len Right, sign and zero extending is equivalent for offset and len because they are guaranteed to be >=0 (by checks in Java). But you can only rely on bit 32 (IBM notation) to be 0. Bit 0-31 may contain garbage. rldicl was incorrect. My mistake, sorry for that. Correct would be rldic which also clears the least significant bits. len should also get fixed e.g. by replacing cmpdi by extsw_ in muladd. 2. Using 8 byte instructions for int The code which feeds stdu is endianess specific. Doesn't work on all PPC64 platforms. 3.Regarding Andrew's point: Superseded by Montgomery? The Montgomery change got backported to jdk8u (JDK-8150152 in 8u102). I'd expect the performance improvement of these intrinsics to be irrelevant for crypto.rsa. Did you measure with an older jdk8 release? (I think the change is still acceptable as the intrinsics could be used elsewhere and the implementation also exists on other platforms.) Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Mittwoch, 16. August 2017 18:50 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics Hi Martin, Thanks for dedicated review. It took me a while to be able to work on this but I hope to have your points solved. Please check below the review as well as my comments quoting your email: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > -----Original Message----- > First of all, C2 does not perform sign extend when calling stubs. The > int parms need to get zero/sign extended. (Could even be done without > extra instructions by replacing sldi -> rldicl, cmpdi -> extsw_ in some > cases.) Does it make a difference on my case? I guess you are talking about mulAdd preparation code. The only aspect I found about him is to force the cast from 32 bits -> 64 bits by cleaning higher bits. Offset is a signed integer but it can't be negative anyway. So I changed from: sldi (R5_ARG3, R5_ARG3, 2); to: rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > macroAssembler_ppc.cpp: > - Indentation should be 2 spaces. Done > stubGenerator_ppc:cpp: > - or_, addi_ should get replaced by orr, addi when CR0 result is not > needed. Done > - Where is lplw initialized? It should be initialized with 0, I missed that... > - I believe that the updating load/store instructions e.g. lwzu don't > perform well on some processors. At least using stwu 2 times in the loop > doesn't make sense. You are right. I could manipulate the bits differently and ended up with a single stdu in the loop. Neat! Although I could not reduce the total number of instructions. > - Note: It should be possible to use 8 byte instead of 4 byte > instructions: MacroAssembler::multiply64, addc, adde. But I'm not > requesting to change that because I guess it would make the code very > complicated, especially when supporting both endianess versions. Yes, that would require a new analysis on this code. May we consider it next? As you said, I prefer having an initial version that looks as simple as the original java code. > - The squareToLen stub implementation is very close the Java > implementation. So it'd be interesting to understand what C2 doesn't do > as well as the hand written assembly code. Do you know that? (Not > absolutely necessary for accepting this change as long as the stub is > measurably faster.) I don't know either. Basically I chose doing it because I noticed some performance gain on SpecJVM2008 when analyzing X64. Then, taking a closer look, I didn't notice any AVX or some special instructions on X64 so I decided to try it on ppc64 by using some basic assembly. Thanks > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: Donnerstag, 10. August 2017 19:22 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics > > > > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > To: ppc-aix-port-dev at openjdk.java.net > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen > intrinsics > > Hi, > > Could you please review this specific PPC64 change to hotspot? By > implementing these intrinsics I noticed a small improvement with > microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, only > when backporting to JDK8 an improvement was noticed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > Motivation for this implementation: > https://twitter.com/ijuma/status/698309312498835457 > > Best regards, > Gustavo Serra Scalet From vladimir.kozlov at oracle.com Thu Aug 17 18:45:51 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Aug 2017 11:45:51 -0700 Subject: RFR(S) : 8183337 : hotspot/compiler/aot tests fail due to missed tools In-Reply-To: References: <78D4B9D8-7FB1-491A-B86E-BBF9F961712F@oracle.com> <20d9621a-9706-128a-3875-840ec1f0024a@oracle.com> Message-ID: <616969e1-a0ca-72e3-24ce-b15f171c7b67@oracle.com> On 8/7/17 4:23 PM, Igor Ignatyev wrote: > >> On Aug 4, 2017, at 3:37 PM, Vladimir Kozlov wrote: >> >> This is ugly. Embedding into tests versions of compilers we use. I see they are listed in common/conf/jib-profiles.js. Can we extract them from there or other place? > I agree that this is not a beauty. but extracting compiler version info from jib-profiles.js will introduce a dependency b/w the tests and source code outside the testbase, we tend to avoid such dependencies as they might break some infra configurations. unfortunately there is no place inside the testbase which has this info. so although I don't like having compiler versions in the tests, I dislike introducing this kind of dependency even more. :( Okay. About next check. Should you also check for link.exe on Windows? Or it is not on PATH usually? + if (Files.exists(Paths.get(path).resolve("ld"))) { + // there is ld in PATH, jaotc is supposed to find it by its own + return null; + } > >> Such change may be okay for internal use but what about community? > the changes don't make it any worse for community. 1st, the test will continue to work as before on hosts which have a linker installed. 2nd, there is a default implementation of artifacts resolver which basically uses java property to specify paths to artifacts. so if someone runs hotspot/compiler/aot tests on a host w/ a linker in PATH, the tests will use this linker, if the tests are run on a host w/o a linker, the tests will try to resolve an artifact and either "install" it using default artifacts resolve or fail w/ a clearer error message. so this patch increases aot test-coverage for community as well. > > I also would like to mention that infra team has plans to make it easier for community to use ArtifactResolver and JIB. Hence I believe this won't be much of a problem. I did not know about that. Good. > >> And can you add a simple tests that artifacts resolver exist at all? > not sure I understand that you mean. the default artifact resolver always exists. and we already have the tests which use an artifact resolver, e.g. hotspot/test/applications/scimark/Scimark.java . I see. Thanks, Vladimir > > Thanks > -- Igor > >> >> Thanks, >> Vladimir >> >> On 8/4/17 3:13 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >>>> 226 lines changed: 160 ins; 62 del; 4 mod; >>> Hi all, >>> could you please review this small patch which aims to solve the problem w/ missed linker in aot tests? >>> problem: jaotc tool needs linker to be installed, but at some hosts, esp. windows and mac, it is not always a case. as a results, aot tests which use jaotc fail on such hosts. >>> fix: on hosts which don't have 'ld' in PATH, we download the devkit and pass the path to the linker from it to jaotc tool. >>> caveats: >>> - oracle implementation of artifacts resolver does not work concurrently, so the tests have to be run in 'exclusiveAccess' mode >>> - some devkits (linux, solaris) are applicable only for a specific OS version >>> bug: https://bugs.openjdk.java.net/browse/JDK-8183337 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >>> testing: hotspot/compiler/aot on all platforms including systems w/o installed linker >>> Thanks, >>> -- Igor > From vladimir.kozlov at oracle.com Thu Aug 17 18:54:34 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Aug 2017 11:54:34 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <3471900.phhlVALLFS@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> <14332343.G5UyyslDlL@pracovni> <3471900.phhlVALLFS@pracovni> Message-ID: Hi Jaroslav, What we should do with 8182701? Do you still need JVMCI changes? Note, your changes to Graal [GR-5435] were integrated recently into JDK (jdk10/hs): https://bugs.openjdk.java.net/browse/JDK-8186158 Thanks, Vladimir On 8/14/17 10:06 AM, Jaroslav Tulach wrote: > On ?tvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote: >> On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: >>> On 27/07/2017 10:07, Jaroslav Tulach wrote: >>>> Yes, it seems like a desirable goal to let Graal compiler work with just >>>> java.base. Is there a description how to build JDK9/10 with just >>>> java.base >>>> that I could follow and test against? >>> >>> You can use jlink to create a run-time image that only contains >>> java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base >>> --output smalljre). >> >> Status update: I've just tried to run Graal compiler against JDK9 with only >> java.base and jdk.internal.vm.ci modules, and there are some problems. I >> need to resolve them first before I provide updated version of my patch. > > FYI: As of > https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff621d5ed0 > the Graal compiler can run with java.base, jdk.unsupported and jdk.vm.ci only > modules. But it wasn't easy, especially the http://wiki.apidesign.org/wiki/PropertyChangeListener required a bit of work. > > -jt > > From gustavo.scalet at eldorado.org.br Thu Aug 17 19:05:36 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Thu, 17 Aug 2017 19:05:36 +0000 Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic Message-ID: Hi, Could you please review this specific PPC64 change to hotspot? By implementing this intrinsic I noticed a significant improvement when using SHA-2 (e.g: Sample run reduced 6.5s run to 2.8s for SHA256.) JBS: https://bugs.openjdk.java.net/browse/JDK-8185979 Webrev: https://gut.github.io/openjdk/webrev/JDK-8185979/webrev/ Best regards, Gustavo Serra Scalet From adinn at redhat.com Fri Aug 18 08:24:44 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 18 Aug 2017 09:24:44 +0100 Subject: [aarch64-port-dev ] [10] RFR(S): 8186297: AARCH64: Intrinsify Unsafe.compareAndSetByte and compareAndSetShort In-Reply-To: References: <56bb1972-9439-ed56-cd27-1e8a4ba9b9ed@redhat.com> <276711502899474@web19o.yandex.ru> <4aff90da-1cd1-cb53-a59a-e312209fb7ec@redhat.com> <8bf1e713-d037-3b36-5048-918ec6f86206@redhat.com> Message-ID: <1a66c21a-5dda-ca3b-892f-03429d35e4a7@redhat.com> Hi Dmitrij, On 17/08/17 11:38, Dmitrij Pochepko wrote: > thank you for catching this! here is a webrev that fixes the issue you > pointed out to: > > http://cr.openjdk.java.net/~dpochepk/8186297/webrev.02/ > > I believe it?s good enough for the Unsafe intrinsic which is the purpose > of this fix. I?ll consider adding pair rules and tidy up that area in a > separate enhancement if you don?t mind. Sure, this is good enough as is. The special case handling would be nice but is not urgent. When you do add the pair rules don't forget to update is_CAS :-) Thanks for fixing this. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dmitrij.pochepko at bell-sw.com Fri Aug 18 12:56:14 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 18 Aug 2017 15:56:14 +0300 Subject: [aarch64-port-dev ] [10] RFR(S): 8186297: AARCH64: Intrinsify Unsafe.compareAndSetByte and compareAndSetShort In-Reply-To: <1a66c21a-5dda-ca3b-892f-03429d35e4a7@redhat.com> References: <56bb1972-9439-ed56-cd27-1e8a4ba9b9ed@redhat.com> <276711502899474@web19o.yandex.ru> <4aff90da-1cd1-cb53-a59a-e312209fb7ec@redhat.com> <8bf1e713-d037-3b36-5048-918ec6f86206@redhat.com> <1a66c21a-5dda-ca3b-892f-03429d35e4a7@redhat.com> Message-ID: <7b83967e-2d6c-65f5-50e2-78e3a9bb7e4d@bell-sw.com> Thank you! On 18.08.2017 11:24, Andrew Dinn wrote: > Hi Dmitrij, > > On 17/08/17 11:38, Dmitrij Pochepko wrote: >> thank you for catching this! here is a webrev that fixes the issue you >> pointed out to: >> >> http://cr.openjdk.java.net/~dpochepk/8186297/webrev.02/ >> >> I believe it?s good enough for the Unsafe intrinThsic which is the purpose >> of this fix. I?ll consider adding pair rules and tidy up that area in a >> separate enhancement if you don?t mind. > Sure, this is good enough as is. The special case handling would be nice > but is not urgent. When you do add the pair rules don't forget to update > is_CAS :-) > > Thanks for fixing this. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From tom.rodriguez at oracle.com Fri Aug 18 18:40:01 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 18 Aug 2017 11:40:01 -0700 Subject: [10] RFR(S) 8181858: [JVMCI] JVMCI should update the trap counters when invalidating for Reason_not_compiled_exception_handler Message-ID: <59973481.6080805@oracle.com> http://cr.openjdk.java.net/~never/8181858/webrev https://bugs.openjdk.java.net/browse/JDK-8181858 JVMCI permits trapping when exception handlers haven't been compiled into the generated code. When this is a normal uncommon trap the counter in the MDO is updated but when the invalidation is forced during exception dispatch the counter isn't updated. This leads to invalidate/recompile cycles that will never terminate because the compiler doesn't know why the previous invalidation happened. Tested with a Graal unit test https://github.com/graalvm/graal/commit/d92dc3f90c0ba1502a9e28a4faf7973ffd9a1889#diff-96a2a5e9fc63d48d47a9ef9722a7c3d9R102. tom From vladimir.kozlov at oracle.com Fri Aug 18 18:49:44 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Aug 2017 11:49:44 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> <14332343.G5UyyslDlL@pracovni> <3471900.phhlVALLFS@pracovni> Message-ID: Updated changes in all repos: http://cr.openjdk.java.net/~kvn/8182701/webrev.01/ On 8/18/17 7:12 AM, Jaroslav Tulach wrote: Thanks for pushing me forward, Vladimir. Yes, the changes are still needed if we want the Graal compiler to expose its MBean in a lazy way. I am offering new webrev for review. It contains following changes: Per Mandy's suggestion I created new module jdk.vm.ci.management to bridge between JVMCI and jdk.management. Adding new module was a bit tricky, but with great help of Jan Lahoda I even managed to register it as a boot module. I renamed the JVMCIMXBean class and dropped X per Vladimir's advice. I fixed the non-standard location of JVMCIMXBean class. I changed the interface to use Map, so the compiler is able to expose more than a single bean. That's it. I am looking forward to your review comments. -jt Here are original changes for reference: http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ On 8/17/17 11:54 AM, Vladimir Kozlov wrote: > Hi Jaroslav, > > What we should do with 8182701? Do you still need JVMCI changes? > > Note, your changes to Graal [GR-5435] were integrated recently into JDK (jdk10/hs): > https://bugs.openjdk.java.net/browse/JDK-8186158 > > Thanks, > Vladimir > > On 8/14/17 10:06 AM, Jaroslav Tulach wrote: >> On ?tvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote: >>> On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: >>>> On 27/07/2017 10:07, Jaroslav Tulach wrote: >>>>> Yes, it seems like a desirable goal to let Graal compiler work with just >>>>> java.base. Is there a description how to build JDK9/10 with just >>>>> java.base >>>>> that I could follow and test against? >>>> >>>> You can use jlink to create a run-time image that only contains >>>> java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base >>>> --output smalljre). >>> >>> Status update: I've just tried to run Graal compiler against JDK9 with only >>> java.base and jdk.internal.vm.ci modules, and there are some problems. I >>> need to resolve them first before I provide updated version of my patch. >> >> FYI: As of >> https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff621d5ed0 >> the Graal compiler can run with java.base, jdk.unsupported and jdk.vm.ci only >> modules. But it wasn't easy, especially the http://wiki.apidesign.org/wiki/PropertyChangeListener required a bit of work. >> >> -jt >> >> From vladimir.kozlov at oracle.com Fri Aug 18 18:54:27 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Aug 2017 11:54:27 -0700 Subject: [10] RFR(XL) 8186453: [AOT] refactor AOT tool code Message-ID: <28d9448f-797f-2636-98ed-7989be50ed92@oracle.com> webrev: http://cr.openjdk.java.net/~kvn/8186453/webrev/ https://bugs.openjdk.java.net/browse/JDK-8186453 Refactoring AOT code: - Made most tool's klasses and methods package private and final (biggest change). - AOT library sections renaming to shorter names, removing 'JVM' from their global names. - Split MethodCounters GOT cells into separate section - now .kls.got (original .metaspace.got) section will have only klass pointers. - Made .method.metadata RO section - it is next big section after .text and it was incorrectly marked as RW due to old implementation. - Split big Main.java into separate class: Collector.java - collects classes and methods to compile based on flags; Linker.java - check if linker is present on machine and execute linking; Options.java - process flags. - Moved various print methods from Main.java to LogPrinter.java. - Split StubInformation.java from CompiledMethodInfo.java. - Renamed MiscUtils to CallInfo class. - Removed unused RelocType and other values. - Fixed Eclipse warnings (for example, removed unused imports and made methods static). Passed AOT jtreg tests and RBT testing. Thanks, Vladimir From doug.simon at oracle.com Fri Aug 18 19:11:28 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 18 Aug 2017 21:11:28 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> <14332343.G5UyyslDlL@pracovni> <3471900.phhlVALLFS@pracovni> Message-ID: <7E1AB15F-D365-4145-B31F-0931FC389EF9@oracle.com> Hi Jaroslav, In general, thanks for pushing through with this change. I don't think JVMCIMXBeans should be in the hotspot-agnostic jdk.vm.ci.services.internal package since it has a direct reference to HotSpotJVMCIRuntime. I would suggest moving it to jdk.vm.ci.hotspot. In HotSpotJVMCRuntime.java: 558 public String mbeanName() { 568 public Object mbean() { Any reason these methods don't follow the conventions of other getter methods in this class (i.e. getMBeanName() and getMBean())? 95 /** Name of the {@link MBeanInfo MBean} representing the internals This should be: /** * Gets the name of the ... Same comment for mbean() method. Also {@code null} is used in JVMCI instead of null. -Doug > On 18 Aug 2017, at 20:49, Vladimir Kozlov wrote: > > Updated changes in all repos: http://cr.openjdk.java.net/~kvn/8182701/webrev.01/ > > On 8/18/17 7:12 AM, Jaroslav Tulach wrote: > > Thanks for pushing me forward, Vladimir. Yes, the changes are still needed if > we want the Graal compiler to expose its MBean in a lazy way. I am offering > new webrev for review. It contains following changes: > > Per Mandy's suggestion I created new module jdk.vm.ci.management to bridge between > JVMCI and jdk.management. Adding new module was a bit tricky, but with great help of Jan > Lahoda I even managed to register it as a boot module. > > I renamed the JVMCIMXBean class and dropped X per Vladimir's advice. I fixed > the non-standard location of JVMCIMXBean class. > > I changed the interface to use Map, so the compiler is able to expose more > than a single bean. > > That's it. I am looking forward to your review comments. > -jt > > Here are original changes for reference: > > http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ > http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ > > On 8/17/17 11:54 AM, Vladimir Kozlov wrote: >> Hi Jaroslav, >> What we should do with 8182701? Do you still need JVMCI changes? >> Note, your changes to Graal [GR-5435] were integrated recently into JDK (jdk10/hs): >> https://bugs.openjdk.java.net/browse/JDK-8186158 >> Thanks, >> Vladimir >> On 8/14/17 10:06 AM, Jaroslav Tulach wrote: >>> On ?tvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote: >>>> On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: >>>>> On 27/07/2017 10:07, Jaroslav Tulach wrote: >>>>>> Yes, it seems like a desirable goal to let Graal compiler work with just >>>>>> java.base. Is there a description how to build JDK9/10 with just >>>>>> java.base >>>>>> that I could follow and test against? >>>>> >>>>> You can use jlink to create a run-time image that only contains >>>>> java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base >>>>> --output smalljre). >>>> >>>> Status update: I've just tried to run Graal compiler against JDK9 with only >>>> java.base and jdk.internal.vm.ci modules, and there are some problems. I >>>> need to resolve them first before I provide updated version of my patch. >>> >>> FYI: As of >>> https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff621d5ed0 >>> the Graal compiler can run with java.base, jdk.unsupported and jdk.vm.ci only >>> modules. But it wasn't easy, especially the http://wiki.apidesign.org/wiki/PropertyChangeListener required a bit of work. >>> >>> -jt >>> >>> From igor.ignatyev at oracle.com Fri Aug 18 19:55:03 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Aug 2017 12:55:03 -0700 Subject: RFR(S) : 8186390 : test for JDK-4755500 Message-ID: <0AF5D187-31C4-4092-B231-398681B4819C@oracle.com> http://cr.openjdk.java.net/~iignatyev//8186390/webrev.00/index.html > 49 lines changed: 49 ins; 0 del; 0 mod; Hi all, could you please review this small fix which adds a regression test for JDK-4755500[1] ? jbs: https://bugs.openjdk.java.net/browse/JDK-8186390 webrev: http://cr.openjdk.java.net/~iignatyev//8186390/webrev.00/index.html testing: new test on main platforms [1] https://bugs.openjdk.java.net/browse/JDK-4755500 Thanks, -- Igor From igor.veresov at oracle.com Fri Aug 18 20:13:20 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 18 Aug 2017 13:13:20 -0700 Subject: RFR(S) 8186235: [Graal] compiler/aot/RecompilationTest.java fails in case UseJVMCICompiler is enabled Message-ID: <3CA1CEA6-2518-4D41-8DCA-39638AD28193@oracle.com> Two problems here: 1. The test uses -XX:-Inline to control inlining. I think it?s reasonable to make a JVMCI compiler respect that option as well. 2. The second problem is the with the AdvancedThresholdPolicy it is possible that compilation requests would be ignored if the compilation queues are large enough when running at CompLevel_aot. I changed the test to use SimpleThresholdPolicy that doesn?t have any queue size feedback loops. Webrev: http://cr.openjdk.java.net/~iveresov/8186235/webrev.00/ igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Aug 18 20:22:41 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Aug 2017 13:22:41 -0700 Subject: RFR(S) 8186235: [Graal] compiler/aot/RecompilationTest.java fails in case UseJVMCICompiler is enabled In-Reply-To: <3CA1CEA6-2518-4D41-8DCA-39638AD28193@oracle.com> References: <3CA1CEA6-2518-4D41-8DCA-39638AD28193@oracle.com> Message-ID: <7d9b78e1-844a-a31d-a6e5-b9c48e6d43d0@oracle.com> Looks good. Thanks, Vladimir On 8/18/17 1:13 PM, Igor Veresov wrote: > Two problems here: > 1. The test uses -XX:-Inline to control inlining. I think it?s reasonable to make a JVMCI compiler respect that option as well. > 2. The second problem is the with the AdvancedThresholdPolicy it is possible that compilation requests would be ignored if the compilation queues are large enough when running at CompLevel_aot. I > changed the test to use SimpleThresholdPolicy that doesn?t have any queue size feedback loops. > > Webrev: http://cr.openjdk.java.net/~iveresov/8186235/webrev.00/ > > igor From doug.simon at oracle.com Fri Aug 18 20:32:21 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 18 Aug 2017 22:32:21 +0200 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError Message-ID: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8186459 http://cr.openjdk.java.net/~dnsimon/8186459/ -Doug From gerard.ziemski at oracle.com Fri Aug 18 21:04:37 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 18 Aug 2017 16:04:37 -0500 Subject: RFR 8173715 (rev2): Remove Flat Profiler Message-ID: hi all, The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it?s the time to remove the code and obsolete the -Xprof flag. Can someone please review the "hotspot/src/cpu/sparc/vm/macroAssembler_sparc.cpp? file to determine whether we still need the three "save_frame_and_mov(0, Lmethod, Lmethod);? calls where the comment said it was needed by -Xprof? Do we leave those save_frame_and_mov() calls as is (and add comment as to why they are still needed), or can we change them into save_frame() calls? http://cr.openjdk.java.net/~gziemski/8173715_rev2_hotspot/src/cpu/sparc/vm/macroAssembler_sparc.cpp.udiff.html issue: https://bugs.openjdk.java.net/browse/JDK-8173715 webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev2_hotspot From igor.ignatyev at oracle.com Fri Aug 18 21:34:39 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Aug 2017 14:34:39 -0700 Subject: RFR(S) : 8183337 : hotspot/compiler/aot tests fail due to missed tools In-Reply-To: <616969e1-a0ca-72e3-24ce-b15f171c7b67@oracle.com> References: <78D4B9D8-7FB1-491A-B86E-BBF9F961712F@oracle.com> <20d9621a-9706-128a-3875-840ec1f0024a@oracle.com> <616969e1-a0ca-72e3-24ce-b15f171c7b67@oracle.com> Message-ID: > On Aug 17, 2017, at 11:45 AM, Vladimir Kozlov wrote: > > On 8/7/17 4:23 PM, Igor Ignatyev wrote: >>> On Aug 4, 2017, at 3:37 PM, Vladimir Kozlov wrote: >>> >>> This is ugly. Embedding into tests versions of compilers we use. I see they are listed in common/conf/jib-profiles.js. Can we extract them from there or other place? >> I agree that this is not a beauty. but extracting compiler version info from jib-profiles.js will introduce a dependency b/w the tests and source code outside the testbase, we tend to avoid such dependencies as they might break some infra configurations. unfortunately there is no place inside the testbase which has this info. so although I don't like having compiler versions in the tests, I dislike introducing this kind of dependency even more. > > :( > > Okay. > > About next check. Should you also check for link.exe on Windows? Or it is not on PATH usually? > > + if (Files.exists(Paths.get(path).resolve("ld"))) { > + // there is ld in PATH, jaotc is supposed to find it by its own > + return null; > + } in some configurations, link.exe is on PATH, but jaotc tool does not use it from PATH, it's trying to find '\\VC\\bin\\amd64\\link.exe' in one of 'VS*COMNTOOLS' env. variables or uses link.exe from "well-known" location in "C:\\Program Files (x86)\\", I'll file an RFE for jatoc to search for link.exe in PATH 1st and then update this webrev. >>> Such change may be okay for internal use but what about community? >> the changes don't make it any worse for community. 1st, the test will continue to work as before on hosts which have a linker installed. 2nd, there is a default implementation of artifacts resolver which basically uses java property to specify paths to artifacts. so if someone runs hotspot/compiler/aot tests on a host w/ a linker in PATH, the tests will use this linker, if the tests are run on a host w/o a linker, the tests will try to resolve an artifact and either "install" it using default artifacts resolve or fail w/ a clearer error message. so this patch increases aot test-coverage for community as well. >> I also would like to mention that infra team has plans to make it easier for community to use ArtifactResolver and JIB. Hence I believe this won't be much of a problem. > > I did not know about that. Good. > >>> And can you add a simple tests that artifacts resolver exist at all? >> not sure I understand that you mean. the default artifact resolver always exists. and we already have the tests which use an artifact resolver, e.g. hotspot/test/applications/scimark/Scimark.java . > > I see. > > Thanks, > Vladimir > >> Thanks >> -- Igor >>> >>> Thanks, >>> Vladimir >>> >>> On 8/4/17 3:13 PM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >>>>> 226 lines changed: 160 ins; 62 del; 4 mod; >>>> Hi all, >>>> could you please review this small patch which aims to solve the problem w/ missed linker in aot tests? >>>> problem: jaotc tool needs linker to be installed, but at some hosts, esp. windows and mac, it is not always a case. as a results, aot tests which use jaotc fail on such hosts. >>>> fix: on hosts which don't have 'ld' in PATH, we download the devkit and pass the path to the linker from it to jaotc tool. >>>> caveats: >>>> - oracle implementation of artifacts resolver does not work concurrently, so the tests have to be run in 'exclusiveAccess' mode >>>> - some devkits (linux, solaris) are applicable only for a specific OS version >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8183337 >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >>>> testing: hotspot/compiler/aot on all platforms including systems w/o installed linker >>>> Thanks, >>>> -- Igor From vladimir.kozlov at oracle.com Fri Aug 18 21:41:35 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Aug 2017 14:41:35 -0700 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError In-Reply-To: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> References: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> Message-ID: Should you change C++ part of JVMCI instead and check PENDING_EXCEPTION like next? http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/oops/method.cpp#l1573 or call SystemDictionary::resolve_or_fail() instead of resolve_or_null()?: http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/classfile/systemDictionary.cpp#l191 Thanks, Vladimir On 8/18/17 1:32 PM, Doug Simon wrote: > https://bugs.openjdk.java.net/browse/JDK-8186459 > http://cr.openjdk.java.net/~dnsimon/8186459/ > > -Doug > From vladimir.kozlov at oracle.com Fri Aug 18 21:50:30 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Aug 2017 14:50:30 -0700 Subject: RFR(S) : 8183337 : hotspot/compiler/aot tests fail due to missed tools In-Reply-To: References: <78D4B9D8-7FB1-491A-B86E-BBF9F961712F@oracle.com> <20d9621a-9706-128a-3875-840ec1f0024a@oracle.com> <616969e1-a0ca-72e3-24ce-b15f171c7b67@oracle.com> Message-ID: <945b579b-7e1b-17a2-cf32-fc763b587715@oracle.com> On 8/18/17 2:34 PM, Igor Ignatyev wrote: > >> On Aug 17, 2017, at 11:45 AM, Vladimir Kozlov wrote: >> >> On 8/7/17 4:23 PM, Igor Ignatyev wrote: >>>> On Aug 4, 2017, at 3:37 PM, Vladimir Kozlov wrote: >>>> >>>> This is ugly. Embedding into tests versions of compilers we use. I see they are listed in common/conf/jib-profiles.js. Can we extract them from there or other place? >>> I agree that this is not a beauty. but extracting compiler version info from jib-profiles.js will introduce a dependency b/w the tests and source code outside the testbase, we tend to avoid such dependencies as they might break some infra configurations. unfortunately there is no place inside the testbase which has this info. so although I don't like having compiler versions in the tests, I dislike introducing this kind of dependency even more. >> >> :( >> >> Okay. >> >> About next check. Should you also check for link.exe on Windows? Or it is not on PATH usually? >> >> + if (Files.exists(Paths.get(path).resolve("ld"))) { >> + // there is ld in PATH, jaotc is supposed to find it by its own >> + return null; >> + } > in some configurations, link.exe is on PATH, but jaotc tool does not use it from PATH, it's trying to find '\\VC\\bin\\amd64\\link.exe' in one of 'VS*COMNTOOLS' env. variables or uses link.exe from "well-known" location in "C:\\Program Files (x86)\\", I'll file an RFE for jatoc to search for link.exe in PATH 1st and then update this webrev. Okay. I saw on some JPRT Win client link.exe in the PATH. Yes, file jaotc RFE. But you don't need to do in this changes which should be pushed first, I think. That RFE can update test code later. You answered all my questions. Reviewed. Thanks, Vladimir > > >>>> Such change may be okay for internal use but what about community? >>> the changes don't make it any worse for community. 1st, the test will continue to work as before on hosts which have a linker installed. 2nd, there is a default implementation of artifacts resolver which basically uses java property to specify paths to artifacts. so if someone runs hotspot/compiler/aot tests on a host w/ a linker in PATH, the tests will use this linker, if the tests are run on a host w/o a linker, the tests will try to resolve an artifact and either "install" it using default artifacts resolve or fail w/ a clearer error message. so this patch increases aot test-coverage for community as well. >>> I also would like to mention that infra team has plans to make it easier for community to use ArtifactResolver and JIB. Hence I believe this won't be much of a problem. >> >> I did not know about that. Good. >> >>>> And can you add a simple tests that artifacts resolver exist at all? >>> not sure I understand that you mean. the default artifact resolver always exists. and we already have the tests which use an artifact resolver, e.g. hotspot/test/applications/scimark/Scimark.java . >> >> I see. >> >> Thanks, >> Vladimir >> >>> Thanks >>> -- Igor >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/4/17 3:13 PM, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >>>>>> 226 lines changed: 160 ins; 62 del; 4 mod; >>>>> Hi all, >>>>> could you please review this small patch which aims to solve the problem w/ missed linker in aot tests? >>>>> problem: jaotc tool needs linker to be installed, but at some hosts, esp. windows and mac, it is not always a case. as a results, aot tests which use jaotc fail on such hosts. >>>>> fix: on hosts which don't have 'ld' in PATH, we download the devkit and pass the path to the linker from it to jaotc tool. >>>>> caveats: >>>>> - oracle implementation of artifacts resolver does not work concurrently, so the tests have to be run in 'exclusiveAccess' mode >>>>> - some devkits (linux, solaris) are applicable only for a specific OS version >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8183337 >>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >>>>> testing: hotspot/compiler/aot on all platforms including systems w/o installed linker >>>>> Thanks, >>>>> -- Igor > From doug.simon at oracle.com Fri Aug 18 21:49:13 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 18 Aug 2017 23:49:13 +0200 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError In-Reply-To: References: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> Message-ID: <6EE1DA0C-EB3F-41C9-9C43-CEC7DD09ABF9@oracle.com> It seems easier to do the exception handling in Java and I'm not sure I see a disadvantage to doing it there? -Doug > On 18 Aug 2017, at 23:41, Vladimir Kozlov wrote: > > Should you change C++ part of JVMCI instead and check PENDING_EXCEPTION like next? > > http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/oops/method.cpp#l1573 > > or call SystemDictionary::resolve_or_fail() instead of resolve_or_null()?: > > http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/classfile/systemDictionary.cpp#l191 > > Thanks, > Vladimir > > On 8/18/17 1:32 PM, Doug Simon wrote: >> https://bugs.openjdk.java.net/browse/JDK-8186459 >> http://cr.openjdk.java.net/~dnsimon/8186459/ >> -Doug From igor.ignatyev at oracle.com Fri Aug 18 21:51:07 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Aug 2017 14:51:07 -0700 Subject: RFR(S) : 8183337 : hotspot/compiler/aot tests fail due to missed tools In-Reply-To: <945b579b-7e1b-17a2-cf32-fc763b587715@oracle.com> References: <78D4B9D8-7FB1-491A-B86E-BBF9F961712F@oracle.com> <20d9621a-9706-128a-3875-840ec1f0024a@oracle.com> <616969e1-a0ca-72e3-24ce-b15f171c7b67@oracle.com> <945b579b-7e1b-17a2-cf32-fc763b587715@oracle.com> Message-ID: <6274CD21-CCD9-4109-B0B1-631B3B08B11D@oracle.com> > On Aug 18, 2017, at 2:50 PM, Vladimir Kozlov wrote: > > On 8/18/17 2:34 PM, Igor Ignatyev wrote: >>> On Aug 17, 2017, at 11:45 AM, Vladimir Kozlov wrote: >>> >>> On 8/7/17 4:23 PM, Igor Ignatyev wrote: >>>>> On Aug 4, 2017, at 3:37 PM, Vladimir Kozlov wrote: >>>>> >>>>> This is ugly. Embedding into tests versions of compilers we use. I see they are listed in common/conf/jib-profiles.js. Can we extract them from there or other place? >>>> I agree that this is not a beauty. but extracting compiler version info from jib-profiles.js will introduce a dependency b/w the tests and source code outside the testbase, we tend to avoid such dependencies as they might break some infra configurations. unfortunately there is no place inside the testbase which has this info. so although I don't like having compiler versions in the tests, I dislike introducing this kind of dependency even more. >>> >>> :( >>> >>> Okay. >>> >>> About next check. Should you also check for link.exe on Windows? Or it is not on PATH usually? >>> >>> + if (Files.exists(Paths.get(path).resolve("ld"))) { >>> + // there is ld in PATH, jaotc is supposed to find it by its own >>> + return null; >>> + } >> in some configurations, link.exe is on PATH, but jaotc tool does not use it from PATH, it's trying to find '\\VC\\bin\\amd64\\link.exe' in one of 'VS*COMNTOOLS' env. variables or uses link.exe from "well-known" location in "C:\\Program Files (x86)\\", I'll file an RFE for jatoc to search for link.exe in PATH 1st and then update this webrev. > > Okay. I saw on some JPRT Win client link.exe in the PATH. Yes, file jaotc RFE. > > But you don't need to do in this changes which should be pushed first, I think. That RFE can update test code later. I've filed https://bugs.openjdk.java.net/browse/JDK-8186463 . ok, I'll fix test code as part of 8186463. > > You answered all my questions. Reviewed. thank you Vladimir. -- Igor > > >>>>> Such change may be okay for internal use but what about community? >>>> the changes don't make it any worse for community. 1st, the test will continue to work as before on hosts which have a linker installed. 2nd, there is a default implementation of artifacts resolver which basically uses java property to specify paths to artifacts. so if someone runs hotspot/compiler/aot tests on a host w/ a linker in PATH, the tests will use this linker, if the tests are run on a host w/o a linker, the tests will try to resolve an artifact and either "install" it using default artifacts resolve or fail w/ a clearer error message. so this patch increases aot test-coverage for community as well. >>>> I also would like to mention that infra team has plans to make it easier for community to use ArtifactResolver and JIB. Hence I believe this won't be much of a problem. >>> >>> I did not know about that. Good. >>> >>>>> And can you add a simple tests that artifacts resolver exist at all? >>>> not sure I understand that you mean. the default artifact resolver always exists. and we already have the tests which use an artifact resolver, e.g. hotspot/test/applications/scimark/Scimark.java . >>> >>> I see. >>> >>> Thanks, >>> Vladimir >>> >>>> Thanks >>>> -- Igor >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/4/17 3:13 PM, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >>>>>>> 226 lines changed: 160 ins; 62 del; 4 mod; >>>>>> Hi all, >>>>>> could you please review this small patch which aims to solve the problem w/ missed linker in aot tests? >>>>>> problem: jaotc tool needs linker to be installed, but at some hosts, esp. windows and mac, it is not always a case. as a results, aot tests which use jaotc fail on such hosts. >>>>>> fix: on hosts which don't have 'ld' in PATH, we download the devkit and pass the path to the linker from it to jaotc tool. >>>>>> caveats: >>>>>> - oracle implementation of artifacts resolver does not work concurrently, so the tests have to be run in 'exclusiveAccess' mode >>>>>> - some devkits (linux, solaris) are applicable only for a specific OS version >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8183337 >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8183337/webrev.00/index.html >>>>>> testing: hotspot/compiler/aot on all platforms including systems w/o installed linker >>>>>> Thanks, >>>>>> -- Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Aug 18 21:58:00 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Aug 2017 14:58:00 -0700 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError In-Reply-To: <6EE1DA0C-EB3F-41C9-9C43-CEC7DD09ABF9@oracle.com> References: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> <6EE1DA0C-EB3F-41C9-9C43-CEC7DD09ABF9@oracle.com> Message-ID: <18c573f9-ea36-0f0d-630c-a59f24b73a29@oracle.com> On 8/18/17 2:49 PM, Doug Simon wrote: > It seems easier to do the exception handling in Java and I'm not sure I see a disadvantage to doing it there? :) I am C++ guy. Okay. Thanks, Vladimir > > -Doug > >> On 18 Aug 2017, at 23:41, Vladimir Kozlov wrote: >> >> Should you change C++ part of JVMCI instead and check PENDING_EXCEPTION like next? >> >> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/oops/method.cpp#l1573 >> >> or call SystemDictionary::resolve_or_fail() instead of resolve_or_null()?: >> >> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/classfile/systemDictionary.cpp#l191 >> >> Thanks, >> Vladimir >> >> On 8/18/17 1:32 PM, Doug Simon wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8186459 >>> http://cr.openjdk.java.net/~dnsimon/8186459/ >>> -Doug > From doug.simon at oracle.com Fri Aug 18 21:57:45 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 18 Aug 2017 23:57:45 +0200 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError In-Reply-To: <18c573f9-ea36-0f0d-630c-a59f24b73a29@oracle.com> References: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> <6EE1DA0C-EB3F-41C9-9C43-CEC7DD09ABF9@oracle.com> <18c573f9-ea36-0f0d-630c-a59f24b73a29@oracle.com> Message-ID: <2D2967B3-FCED-49B8-A92D-EB60186DE047@oracle.com> > On 18 Aug 2017, at 23:58, Vladimir Kozlov wrote: > > On 8/18/17 2:49 PM, Doug Simon wrote: >> It seems easier to do the exception handling in Java and I'm not sure I see a disadvantage to doing it there? > > :) I am C++ guy. I need to assign more Graal bugs to you to fix that ;-) > > Okay. > > Thanks, > Vladimir > >> -Doug >>> On 18 Aug 2017, at 23:41, Vladimir Kozlov wrote: >>> >>> Should you change C++ part of JVMCI instead and check PENDING_EXCEPTION like next? >>> >>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/oops/method.cpp#l1573 >>> >>> or call SystemDictionary::resolve_or_fail() instead of resolve_or_null()?: >>> >>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/classfile/systemDictionary.cpp#l191 >>> >>> Thanks, >>> Vladimir >>> >>> On 8/18/17 1:32 PM, Doug Simon wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8186459 >>>> http://cr.openjdk.java.net/~dnsimon/8186459/ >>>> -Doug From igor.veresov at oracle.com Sat Aug 19 02:34:42 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 18 Aug 2017 19:34:42 -0700 Subject: [10] RFR(XL) 8186453: [AOT] refactor AOT tool code In-Reply-To: <28d9448f-797f-2636-98ed-7989be50ed92@oracle.com> References: <28d9448f-797f-2636-98ed-7989be50ed92@oracle.com> Message-ID: <7C923487-B30D-4A92-A18C-249BB8245BA6@oracle.com> Very good cleanup. Thanks! igor > On Aug 18, 2017, at 11:54 AM, Vladimir Kozlov wrote: > > webrev: http://cr.openjdk.java.net/~kvn/8186453/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8186453 > > Refactoring AOT code: > > - Made most tool's klasses and methods package private and final (biggest change). > - AOT library sections renaming to shorter names, removing 'JVM' from their global names. > - Split MethodCounters GOT cells into separate section - now .kls.got (original .metaspace.got) section will have only klass pointers. > - Made .method.metadata RO section - it is next big section after .text and it was incorrectly marked as RW due to old implementation. > - Split big Main.java into separate class: > Collector.java - collects classes and methods to compile based on flags; > Linker.java - check if linker is present on machine and execute linking; > Options.java - process flags. > - Moved various print methods from Main.java to LogPrinter.java. > - Split StubInformation.java from CompiledMethodInfo.java. > - Renamed MiscUtils to CallInfo class. > - Removed unused RelocType and other values. > - Fixed Eclipse warnings (for example, removed unused imports and made methods static). > > Passed AOT jtreg tests and RBT testing. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Sat Aug 19 02:48:45 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Aug 2017 19:48:45 -0700 Subject: [10] RFR(XL) 8186453: [AOT] refactor AOT tool code In-Reply-To: <7C923487-B30D-4A92-A18C-249BB8245BA6@oracle.com> References: <28d9448f-797f-2636-98ed-7989be50ed92@oracle.com> <7C923487-B30D-4A92-A18C-249BB8245BA6@oracle.com> Message-ID: Thank you, Igor Vladimir On 8/18/17 7:34 PM, Igor Veresov wrote: > Very good cleanup. Thanks! > > igor > >> On Aug 18, 2017, at 11:54 AM, Vladimir Kozlov wrote: >> >> webrev: http://cr.openjdk.java.net/~kvn/8186453/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8186453 >> >> Refactoring AOT code: >> >> - Made most tool's klasses and methods package private and final (biggest change). >> - AOT library sections renaming to shorter names, removing 'JVM' from their global names. >> - Split MethodCounters GOT cells into separate section - now .kls.got (original .metaspace.got) section will have only klass pointers. >> - Made .method.metadata RO section - it is next big section after .text and it was incorrectly marked as RW due to old implementation. >> - Split big Main.java into separate class: >> Collector.java - collects classes and methods to compile based on flags; >> Linker.java - check if linker is present on machine and execute linking; >> Options.java - process flags. >> - Moved various print methods from Main.java to LogPrinter.java. >> - Split StubInformation.java from CompiledMethodInfo.java. >> - Renamed MiscUtils to CallInfo class. >> - Removed unused RelocType and other values. >> - Fixed Eclipse warnings (for example, removed unused imports and made methods static). >> >> Passed AOT jtreg tests and RBT testing. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Sat Aug 19 19:46:34 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 19 Aug 2017 12:46:34 -0700 Subject: RFR: JDK-8186115 - libelf still referenced after 8172670 In-Reply-To: References: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> Message-ID: <2a0c56ea-db3d-5d48-5514-b1a0e33a27d8@oracle.com> Bob, did you pushed it? If not yes, please fix .mx.graal/suite.py for unit tests Rickard added. They have dependency on jdk.tools.jaotc.collect: test/compiler/aot/jdk.tools.jaotc.test/ They failed when I modified collect and other classes. We need to have dependency on it in suite.py. Thanks, Vladimir On 8/15/17 12:10 PM, Vladimir Kozlov wrote: > On 8/15/17 11:55 AM, Bob Vandette wrote: >> Please review these changes for JDK 10 that remove all dependencies on >> libelf from the JDK >> build system. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8186115 >> >> Webrev: >> http://cr.openjdk.java.net/~bobv/8186115/ > > Good. > >> >> Compiler team: Please check CodeSectionProcessor. Is the stepping >> through all >> foreign call still necessary? I only removed the comment. > > I will look. It could be the problem was not libelf but loader. > > Thanks, > Vladimir > >> >> Thanks, >> Bob. >> From jaroslav.tulach at oracle.com Mon Aug 21 08:48:43 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 21 Aug 2017 10:48:43 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <7E1AB15F-D365-4145-B31F-0931FC389EF9@oracle.com> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <7E1AB15F-D365-4145-B31F-0931FC389EF9@oracle.com> Message-ID: <1711635.xZU8ZpfHaJ@pracovni> Hello Doug & co., I think your comments are about the old webrev. I hope most of them have been (by a chance) addressed in the newest webrev 01: http://cr.openjdk.java.net/~kvn/8182701/webrev.01/ On p?tek 18. srpna 2017 21:11:28 CEST Doug Simon wrote: > I don't think JVMCIMXBeans should be in the hotspot-agnostic > jdk.vm.ci.services.internal package since it has a direct reference to > HotSpotJVMCIRuntime. I would suggest moving it to jdk.vm.ci.hotspot. Mandy already suggested to put the JVMCIMBeans class into its own module with dependencies on jdk.management and jdk.vm.internal.ci modules. I think it is the cleanest solution from the point of modular architecture. The suggested module can be found in the webrev.01 under the name jdk.vm.ci.management. > In HotSpotJVMCRuntime.java: > > 558 public String mbeanName() { > 568 public Object mbean() { > > Any reason these methods don't follow the conventions of other getter > methods in this class (i.e. getMBeanName() and getMBean())? These two methods have been replaced by /** * Provides compiler specific platform MBeans. These MBeans will be automatically * exposed once the management system gets initialized. * * @return map from MBean names to their instances */ public Map mbeans() { return Collections.emptyMap(); } in the webrev.01. You are right, the name of the method could be getMBeans(). Let me know if I should rename that and also ... > > 95 /** Name of the {@link MBeanInfo MBean} representing the internals > > This should be: > > /** > * Gets the name of the ... ...please give me a better version of Javadoc, in case the current "Provides..." isn't sufficient. > Same comment for mbean() method. Also {@code null} is used in JVMCI instead > of null. The webrev.01 version never returns null. Instead Collections.emptyMap() is returned by default. Thus this comment no longer applies. Thanks for your comments. -jt > > On 18 Aug 2017, at 20:49, Vladimir Kozlov > > wrote: > > > > Updated changes in all repos: > > http://cr.openjdk.java.net/~kvn/8182701/webrev.01/ > > > > On 8/18/17 7:12 AM, Jaroslav Tulach wrote: > > > > Thanks for pushing me forward, Vladimir. Yes, the changes are still needed > > if we want the Graal compiler to expose its MBean in a lazy way. I am > > offering new webrev for review. It contains following changes: > > > > Per Mandy's suggestion I created new module jdk.vm.ci.management to bridge > > between JVMCI and jdk.management. Adding new module was a bit tricky, but > > with great help of Jan Lahoda I even managed to register it as a boot > > module. > > > > I renamed the JVMCIMXBean class and dropped X per Vladimir's advice. I > > fixed the non-standard location of JVMCIMXBean class. > > > > I changed the interface to use Map, so the compiler is able to expose more > > than a single bean. > > > > That's it. I am looking forward to your review comments. > > -jt > > > > Here are original changes for reference: > > > > http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ > > http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ > > > > On 8/17/17 11:54 AM, Vladimir Kozlov wrote: > >> Hi Jaroslav, > >> What we should do with 8182701? Do you still need JVMCI changes? > >> Note, your changes to Graal [GR-5435] were integrated recently into JDK > >> (jdk10/hs): https://bugs.openjdk.java.net/browse/JDK-8186158 > >> Thanks, > >> Vladimir > >> > >> On 8/14/17 10:06 AM, Jaroslav Tulach wrote: > >>> On ?tvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote: > >>>> On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: > >>>>> On 27/07/2017 10:07, Jaroslav Tulach wrote: > >>>>>> Yes, it seems like a desirable goal to let Graal compiler work with > >>>>>> just > >>>>>> java.base. Is there a description how to build JDK9/10 with just > >>>>>> java.base > >>>>>> that I could follow and test against? > >>>>> > >>>>> You can use jlink to create a run-time image that only contains > >>>>> java.base (jlink --module-path $JAVA_HOME/jmods --add-modules > >>>>> java.base > >>>>> --output smalljre). > >>>> > >>>> Status update: I've just tried to run Graal compiler against JDK9 with > >>>> only > >>>> java.base and jdk.internal.vm.ci modules, and there are some problems. > >>>> I > >>>> need to resolve them first before I provide updated version of my > >>>> patch. > >>> > >>> FYI: As of > >>> https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff > >>> 621d5ed0 the Graal compiler can run with java.base, jdk.unsupported and > >>> jdk.vm.ci only modules. But it wasn't easy, especially the > >>> http://wiki.apidesign.org/wiki/PropertyChangeListener required a bit of > >>> work. > >>> > >>> -jt From doug.simon at oracle.com Mon Aug 21 08:53:04 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 21 Aug 2017 10:53:04 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <1711635.xZU8ZpfHaJ@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <7E1AB15F-D365-4145-B31F-0931FC389EF9@oracle.com> <1711635.xZU8ZpfHaJ@pracovni> Message-ID: <22382F96-2533-4A43-A34D-E83CD40CD78B@oracle.com> > On 21 Aug 2017, at 10:48, Jaroslav Tulach wrote: > > Hello Doug & co., > I think your comments are about the old webrev. I hope most of them have been > (by a chance) addressed in the newest webrev 01: Indeed they are. Sorry again for missing the latest link when do the review ;-) -Doug From tobias.hartmann at oracle.com Mon Aug 21 09:28:39 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 21 Aug 2017 11:28:39 +0200 Subject: RFR(S) : 8186390 : test for JDK-4755500 In-Reply-To: <0AF5D187-31C4-4092-B231-398681B4819C@oracle.com> References: <0AF5D187-31C4-4092-B231-398681B4819C@oracle.com> Message-ID: <410d70b2-1680-8117-6191-11060625300c@oracle.com> Hi Igor, this looks good to me. Best regards, Tobias On 18.08.2017 21:55, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8186390/webrev.00/index.html >> 49 lines changed: 49 ins; 0 del; 0 mod; > > Hi all, > > could you please review this small fix which adds a regression test for JDK-4755500[1] ? > > jbs: https://bugs.openjdk.java.net/browse/JDK-8186390 > webrev: http://cr.openjdk.java.net/~iignatyev//8186390/webrev.00/index.html > testing: new test on main platforms > > [1] https://bugs.openjdk.java.net/browse/JDK-4755500 > > Thanks, > -- Igor > From erik.joelsson at oracle.com Mon Aug 21 13:03:11 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Aug 2017 15:03:11 +0200 Subject: RFR: JDK-8186115 - libelf still referenced after 8172670 In-Reply-To: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> References: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> Message-ID: <7680496d-7467-2023-ef26-44492d01354c@oracle.com> Build changes look ok. /Erik On 2017-08-15 20:55, Bob Vandette wrote: > Please review these changes for JDK 10 that remove all dependencies on libelf from the JDK > build system. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8186115 > > Webrev: > http://cr.openjdk.java.net/~bobv/8186115/ > > Compiler team: Please check CodeSectionProcessor. Is the stepping through all > foreign call still necessary? I only removed the comment. > > Thanks, > Bob. > > From bob.vandette at oracle.com Mon Aug 21 14:05:14 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 21 Aug 2017 10:05:14 -0400 Subject: RFR: JDK-8186115 - libelf still referenced after 8172670 In-Reply-To: <2a0c56ea-db3d-5d48-5514-b1a0e33a27d8@oracle.com> References: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> <2a0c56ea-db3d-5d48-5514-b1a0e33a27d8@oracle.com> Message-ID: <2A2661E5-5328-4D2D-87C7-E08164874870@oracle.com> No, I have not pushed this fix yet. I was waiting for you to look into the CodeSectionProcessor issue. Do you want me to just push it? Can you send me a diff of the change you want me to add? Bob. > On Aug 19, 2017, at 3:46 PM, Vladimir Kozlov wrote: > > Bob, did you pushed it? > > If not yes, please fix .mx.graal/suite.py for unit tests Rickard added. They have dependency on jdk.tools.jaotc.collect: > > test/compiler/aot/jdk.tools.jaotc.test/ > > They failed when I modified collect and other classes. We need to have dependency on it in suite.py. > > Thanks, > Vladimir > > On 8/15/17 12:10 PM, Vladimir Kozlov wrote: >> On 8/15/17 11:55 AM, Bob Vandette wrote: >>> Please review these changes for JDK 10 that remove all dependencies on libelf from the JDK >>> build system. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8186115 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bobv/8186115/ >> Good. >>> >>> Compiler team: Please check CodeSectionProcessor. Is the stepping through all >>> foreign call still necessary? I only removed the comment. >> I will look. It could be the problem was not libelf but loader. >> Thanks, >> Vladimir >>> >>> Thanks, >>> Bob. >>> From vladimir.kozlov at oracle.com Mon Aug 21 15:29:39 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Aug 2017 08:29:39 -0700 Subject: RFR: JDK-8186115 - libelf still referenced after 8172670 In-Reply-To: <2A2661E5-5328-4D2D-87C7-E08164874870@oracle.com> References: <399496D5-7C1E-4F47-98BD-EAC89FB68F59@oracle.com> <2a0c56ea-db3d-5d48-5514-b1a0e33a27d8@oracle.com> <2A2661E5-5328-4D2D-87C7-E08164874870@oracle.com> Message-ID: <445ecf7e-68b6-cd05-3f91-1a1151cb4a7f@oracle.com> On 8/21/17 7:05 AM, Bob Vandette wrote: > No, I have not pushed this fix yet. I was waiting for you to look into the CodeSectionProcessor issue. Leave CodeSectionProcessor.java as it is - don't even change comment. I will update it if needed. No updated webrev needed. > Do you want me to just push it? Yes. I saw Erik reviewed build change. > > Can you send me a diff of the change you want me to add? Ignore my comment. jdk.tools.jaotc.test has already recorded in suite.py. I missed it first. Your change to suite.py is good. Thanks, Vladimir > > Bob. > > >> On Aug 19, 2017, at 3:46 PM, Vladimir Kozlov wrote: >> >> Bob, did you pushed it? >> >> If not yes, please fix .mx.graal/suite.py for unit tests Rickard added. They have dependency on jdk.tools.jaotc.collect: >> >> test/compiler/aot/jdk.tools.jaotc.test/ >> >> They failed when I modified collect and other classes. We need to have dependency on it in suite.py. >> >> Thanks, >> Vladimir >> >> On 8/15/17 12:10 PM, Vladimir Kozlov wrote: >>> On 8/15/17 11:55 AM, Bob Vandette wrote: >>>> Please review these changes for JDK 10 that remove all dependencies on libelf from the JDK >>>> build system. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8186115 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bobv/8186115/ >>> Good. >>>> >>>> Compiler team: Please check CodeSectionProcessor. Is the stepping through all >>>> foreign call still necessary? I only removed the comment. >>> I will look. It could be the problem was not libelf but loader. >>> Thanks, >>> Vladimir >>>> >>>> Thanks, >>>> Bob. >>>> > From tom.rodriguez at oracle.com Mon Aug 21 17:43:36 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 21 Aug 2017 10:43:36 -0700 Subject: [10] RFR(S) 8181858: [JVMCI] JVMCI should update the trap counters when invalidating for Reason_not_compiled_exception_handler In-Reply-To: <59973481.6080805@oracle.com> References: <59973481.6080805@oracle.com> Message-ID: <599B1BC8.6010302@oracle.com> Can I get a review for this? It basically just moves the code and adds an MDO counter increment in the middle of the copy. tom Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8181858/webrev > https://bugs.openjdk.java.net/browse/JDK-8181858 > > JVMCI permits trapping when exception handlers haven't been compiled > into the generated code. When this is a normal uncommon trap the counter > in the MDO is updated but when the invalidation is forced during > exception dispatch the counter isn't updated. This leads to > invalidate/recompile cycles that will never terminate because the > compiler doesn't know why the previous invalidation happened. Tested > with a Graal unit test > https://github.com/graalvm/graal/commit/d92dc3f90c0ba1502a9e28a4faf7973ffd9a1889#diff-96a2a5e9fc63d48d47a9ef9722a7c3d9R102. > > > tom From mandy.chung at oracle.com Mon Aug 21 19:42:09 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 21 Aug 2017 12:42:09 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> <14332343.G5UyyslDlL@pracovni> <3471900.phhlVALLFS@pracovni> Message-ID: <3b46f521-add4-a169-4bbd-67ac3afd6f07@oracle.com> cc'ing serviceability-dev which is the right mailing list for platform management discussion. JVMCI is currently named as `jdk.internal.vm.ci` (a JDK internal module). I suppose this new module is intended to be kept as an internal module? 30 * @since 9 should be @since 10. JVMCIMBeans.java 55 @Override 56 public Set> mbeanInterfaces() { 57 return Collections.singleton(mbean.getClass()); 58 } This mbeanInterfaces method should return the MBean interface class but not the class of the mbean implementation. This allows the platform mbean to be looked up from ManagementFactory.getPlatformMXBean. If this is a dynamic mbean, then this method simply returns an empty list (see DiagnosticCommandMBean). To support standard mbean, HotSpotJVMCICompilerFactory::mbeans method would need to include the mbean interface type in addition to the name and the mbean implementation object, i.e. may need to define a specific type for it. Mandy On 8/18/17 11:49 AM, Vladimir Kozlov wrote: > Updated changes in all repos: > http://cr.openjdk.java.net/~kvn/8182701/webrev.01/ > > On 8/18/17 7:12 AM, Jaroslav Tulach wrote: > > Thanks for pushing me forward, Vladimir. Yes, the changes are still > needed if > we want the Graal compiler to expose its MBean in a lazy way. I am > offering > new webrev for review. It contains following changes: > > Per Mandy's suggestion I created new module jdk.vm.ci.management to > bridge between > JVMCI and jdk.management. Adding new module was a bit tricky, but with > great help of Jan > Lahoda I even managed to register it as a boot module. > > I renamed the JVMCIMXBean class and dropped X per Vladimir's advice. I > fixed > the non-standard location of JVMCIMXBean class. > > I changed the interface to use Map, so the compiler is able to expose > more > than a single bean. > > That's it. I am looking forward to your review comments. > -jt > > Here are original changes for reference: > > http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ > http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ > > On 8/17/17 11:54 AM, Vladimir Kozlov wrote: >> Hi Jaroslav, >> >> What we should do with 8182701? Do you still need JVMCI changes? >> >> Note, your changes to Graal [GR-5435] were integrated recently into >> JDK (jdk10/hs): >> https://bugs.openjdk.java.net/browse/JDK-8186158 >> >> Thanks, >> Vladimir >> >> On 8/14/17 10:06 AM, Jaroslav Tulach wrote: >>> On ?tvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote: >>>> On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: >>>>> On 27/07/2017 10:07, Jaroslav Tulach wrote: >>>>>> Yes, it seems like a desirable goal to let Graal compiler work >>>>>> with just >>>>>> java.base. Is there a description how to build JDK9/10 with just >>>>>> java.base >>>>>> that I could follow and test against? >>>>> >>>>> You can use jlink to create a run-time image that only contains >>>>> java.base (jlink --module-path $JAVA_HOME/jmods --add-modules >>>>> java.base >>>>> --output smalljre). >>>> >>>> Status update: I've just tried to run Graal compiler against JDK9 >>>> with only >>>> java.base and jdk.internal.vm.ci modules, and there are some >>>> problems. I >>>> need to resolve them first before I provide updated version of my >>>> patch. >>> >>> FYI: As of >>> https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff621d5ed0 >>> >>> the Graal compiler can run with java.base, jdk.unsupported and >>> jdk.vm.ci only >>> modules. But it wasn't easy, especially the >>> http://wiki.apidesign.org/wiki/PropertyChangeListener required a bit >>> of work. >>> >>> -jt >>> >>> From vladimir.kozlov at oracle.com Mon Aug 21 20:07:48 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Aug 2017 13:07:48 -0700 Subject: [10] RFR(S) 8181858: [JVMCI] JVMCI should update the trap counters when invalidating for Reason_not_compiled_exception_handler In-Reply-To: <59973481.6080805@oracle.com> References: <59973481.6080805@oracle.com> Message-ID: <6098bd61-7855-aa69-f0f9-ba5d9449a265@oracle.com> Looks good. Thanks, Vladimir On 8/18/17 11:40 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8181858/webrev > https://bugs.openjdk.java.net/browse/JDK-8181858 > > JVMCI permits trapping when exception handlers haven't been compiled > into the generated code.? When this is a normal uncommon trap the > counter in the MDO is updated but when the invalidation is forced during > exception dispatch the counter isn't updated.? This leads to > invalidate/recompile cycles that will never terminate because the > compiler doesn't know why the previous invalidation happened.? Tested > with a Graal unit test > https://github.com/graalvm/graal/commit/d92dc3f90c0ba1502a9e28a4faf7973ffd9a1889#diff-96a2a5e9fc63d48d47a9ef9722a7c3d9R102. > > > tom From igor.ignatyev at oracle.com Mon Aug 21 21:55:18 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 21 Aug 2017 14:55:18 -0700 Subject: RFR(S) : 8186537 : remove unnecessary @requires from hotspot/compiler/aot tests Message-ID: <28B24766-C74B-437B-AC5C-BD4790B196F7@oracle.com> http://cr.openjdk.java.net/~iignatyev//8186537/webrev.00/index.html > 54 lines changed: 0 ins; 54 del; 0 mod; Hi all, could you please review this small patch which cleans up @requires in aot tests? after JDK-8185536[1], all aot tests are marked w/ '@requires vm.aot', so they will be executed only if a VM under test supports AOT. this made '@requires vm.bits == "64" & (os.arch == "amd64" | os.arch == "x86_64")' in these tests redundant. webrev: http://cr.openjdk.java.net/~iignatyev//8186537/webrev.00/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8186537sca testing: hotspot/compiler/aot tests on platforms w/ and w/o AOT support. number of selected/run tests is the same as before the fix. [1] https://bugs.openjdk.java.net/browse/JDK-8185536 Thanks, -- Igor From vladimir.kozlov at oracle.com Mon Aug 21 23:36:57 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Aug 2017 16:36:57 -0700 Subject: RFR(S) : 8186537 : remove unnecessary @requires from hotspot/compiler/aot tests In-Reply-To: <28B24766-C74B-437B-AC5C-BD4790B196F7@oracle.com> References: <28B24766-C74B-437B-AC5C-BD4790B196F7@oracle.com> Message-ID: <5e6d9886-4b7f-cfee-d824-354f7a3bd714@oracle.com> Right. No need for @require now. Thanks, Vladimir On 8/21/17 2:55 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8186537/webrev.00/index.html >> 54 lines changed: 0 ins; 54 del; 0 mod; > > Hi all, > > could you please review this small patch which cleans up @requires in aot tests? > after JDK-8185536[1], all aot tests are marked w/ '@requires vm.aot', so they will be executed only if a VM under test supports AOT. this made '@requires vm.bits == "64" & (os.arch == "amd64" | os.arch == "x86_64")' in these tests redundant. > > webrev: http://cr.openjdk.java.net/~iignatyev//8186537/webrev.00/index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8186537sca > testing: hotspot/compiler/aot tests on platforms w/ and w/o AOT support. number of selected/run tests is the same as before the fix. > > [1] https://bugs.openjdk.java.net/browse/JDK-8185536 > > Thanks, > -- Igor > > From jaroslav.tulach at oracle.com Tue Aug 22 13:19:52 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 22 Aug 2017 15:19:52 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <3b46f521-add4-a169-4bbd-67ac3afd6f07@oracle.com> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <3b46f521-add4-a169-4bbd-67ac3afd6f07@oracle.com> Message-ID: <1906851.CDFazpJ8ns@pracovni> Thanks for your comments, Mandy. On pond?l? 21. srpna 2017 12:42:09 CEST mandy chung wrote: > cc'ing serviceability-dev which is the right mailing list for platform > management discussion. > > JVMCI is currently named as `jdk.internal.vm.ci` (a JDK internal > module). I suppose this new module is intended to be kept as an > internal module? The module doesn't export any API - e.g. it is internal. The current name is jdk.vm.ci.management - shall I change that to something like jdk.internal.vm.ci.management? Or some other (shorter) suggestion? > 30 * @since 9 > > should be @since 10. I see. I'll fix that. > JVMCIMBeans.java > > 55 @Override > 56 public Set> mbeanInterfaces() { > 57 return Collections.singleton(mbean.getClass()); > 58 } > > This mbeanInterfaces method should return the MBean interface class but > not the class of the mbean implementation. This allows the platform > mbean to be looked up from ManagementFactory.getPlatformMXBean. If this > is a dynamic mbean, then this method simply returns an empty list (see > DiagnosticCommandMBean). I am almost 100% sure that the bean(s) exposed from Truffle is going to be DynamicMBean - we compose the attributes dynamically, that wouldn't work with reflection. I'll change the code to return an empty list if the bean is DynamicMBean. > To support standard mbean, > HotSpotJVMCICompilerFactory::mbeans method would need to include the > mbean interface type in addition to the name and the mbean > implementation object, i.e. may need to define a specific type for it. As we don't have any use for this yet I suggest to keep things simple. I believe following contract could work: public Set> mbeanInterfaces() { if (mbean instanceof DynamicMBean) { return Collections.emptySet(); } else { Class[] interfaces = mbean.getClass().getInterfaces(); return new HashSet<>(Arrays.asList(interfaces)); } } if this is acceptable, I would change documentation of the mbean() method to mention how the set of mbeanInterfaces() is computed. OK? Thanks for the review. -jt > On 8/18/17 11:49 AM, Vladimir Kozlov wrote: > > Updated changes in all repos: > > http://cr.openjdk.java.net/~kvn/8182701/webrev.01/ > > > > On 8/18/17 7:12 AM, Jaroslav Tulach wrote: > > > > Thanks for pushing me forward, Vladimir. Yes, the changes are still > > needed if > > we want the Graal compiler to expose its MBean in a lazy way. I am > > offering > > new webrev for review. It contains following changes: > > > > Per Mandy's suggestion I created new module jdk.vm.ci.management to > > bridge between > > JVMCI and jdk.management. Adding new module was a bit tricky, but with > > great help of Jan > > Lahoda I even managed to register it as a boot module. > > > > I renamed the JVMCIMXBean class and dropped X per Vladimir's advice. I > > fixed > > the non-standard location of JVMCIMXBean class. > > > > I changed the interface to use Map, so the compiler is able to expose > > more > > than a single bean. > > > > That's it. I am looking forward to your review comments. > > -jt > > > > Here are original changes for reference: > > > > http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ > > http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ > > > > On 8/17/17 11:54 AM, Vladimir Kozlov wrote: > >> Hi Jaroslav, > >> > >> What we should do with 8182701? Do you still need JVMCI changes? > >> > >> Note, your changes to Graal [GR-5435] were integrated recently into > >> JDK (jdk10/hs): > >> https://bugs.openjdk.java.net/browse/JDK-8186158 > >> > >> Thanks, > >> Vladimir > >> > >> On 8/14/17 10:06 AM, Jaroslav Tulach wrote: > >>> On ?tvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote: > >>>> On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: > >>>>> On 27/07/2017 10:07, Jaroslav Tulach wrote: > >>>>>> Yes, it seems like a desirable goal to let Graal compiler work > >>>>>> with just > >>>>>> java.base. Is there a description how to build JDK9/10 with just > >>>>>> java.base > >>>>>> that I could follow and test against? > >>>>> > >>>>> You can use jlink to create a run-time image that only contains > >>>>> java.base (jlink --module-path $JAVA_HOME/jmods --add-modules > >>>>> java.base > >>>>> --output smalljre). > >>>> > >>>> Status update: I've just tried to run Graal compiler against JDK9 > >>>> with only > >>>> java.base and jdk.internal.vm.ci modules, and there are some > >>>> problems. I > >>>> need to resolve them first before I provide updated version of my > >>>> patch. > >>> > >>> FYI: As of > >>> https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff > >>> 621d5ed0 > >>> > >>> the Graal compiler can run with java.base, jdk.unsupported and > >>> jdk.vm.ci only > >>> modules. But it wasn't easy, especially the > >>> http://wiki.apidesign.org/wiki/PropertyChangeListener required a bit > >>> of work. > >>> > >>> -jt From goetz.lindenmaier at sap.com Tue Aug 22 13:19:56 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Aug 2017 13:19:56 +0000 Subject: RFR(S): 8186437: Lock held when compiler thread creation is aborted. Message-ID: Hi, Could I please get reviews for this small change? I also please need a sponsor. http://cr.openjdk.java.net/~goetz/wr17/8186437-compThrLock/ When the VM is aborted because compiler thread creation fails (seen in TestOprionsWithRanges with huge stack size) the Thread_lock was not released. Best regards, Goetz. From thomas.stuefe at gmail.com Tue Aug 22 13:37:00 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 22 Aug 2017 15:37:00 +0200 Subject: RFR(S): 8186437: Lock held when compiler thread creation is aborted. In-Reply-To: References: Message-ID: Hi Goetz, On Tue, Aug 22, 2017 at 3:19 PM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi, > > Could I please get reviews for this small change? I also please need a > sponsor. > http://cr.openjdk.java.net/~goetz/wr17/8186437-compThrLock/ > > When the VM is aborted because compiler thread creation fails (seen in > TestOprionsWithRanges with huge stack size) the Thread_lock was not > released. > > Seems fine, if a bit difficult to read. Alternatively, one could have unlocked manually - after all, we are never leaving this function, so the ~MutexLocker. That would have preserved the control. Cheers, Thomas > Best regards, > Goetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Tue Aug 22 14:38:24 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Aug 2017 14:38:24 +0000 Subject: RFR(S): 8186437: Lock held when compiler thread creation is aborted. In-Reply-To: References: Message-ID: Hi Thomas, thanks for the review! The control flow is just as in JVM_StartThread, there even an extra variable is maintained for the error case that is used only once. Best regards, Goetz. > -----Original Message----- > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Dienstag, 22. August 2017 15:37 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): 8186437: Lock held when compiler thread creation is > aborted. > > Hi Goetz, > > > > On Tue, Aug 22, 2017 at 3:19 PM, Lindenmaier, Goetz > > wrote: > > > Hi, > > Could I please get reviews for this small change? I also please need a > sponsor. > http://cr.openjdk.java.net/~goetz/wr17/8186437-compThrLock/ > > > When the VM is aborted because compiler thread creation fails (seen > in > TestOprionsWithRanges with huge stack size) the Thread_lock was not > released. > > > > > Seems fine, if a bit difficult to read. Alternatively, one could have unlocked > manually - after all, we are never leaving this function, so the ~MutexLocker. > That would have preserved the control. > > Cheers, Thomas > > > > > > Best regards, > Goetz. > > From mandy.chung at oracle.com Tue Aug 22 16:07:08 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 22 Aug 2017 09:07:08 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <1906851.CDFazpJ8ns@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <3b46f521-add4-a169-4bbd-67ac3afd6f07@oracle.com> <1906851.CDFazpJ8ns@pracovni> Message-ID: On 8/22/17 6:19 AM, Jaroslav Tulach wrote: > Thanks for your comments, Mandy. > > On pond?l? 21. srpna 2017 12:42:09 CEST mandy chung wrote: >> cc'ing serviceability-dev which is the right mailing list for platform >> management discussion. >> >> JVMCI is currently named as `jdk.internal.vm.ci` (a JDK internal >> module). I suppose this new module is intended to be kept as an >> internal module? > The module doesn't export any API - e.g. it is internal. The current name is > jdk.vm.ci.management - shall I change that to something like > jdk.internal.vm.ci.management? Or some other (shorter) suggestion? > Will get back to you on any suggestion. >> JVMCIMBeans.java >> >> 55 @Override >> 56 public Set> mbeanInterfaces() { >> 57 return Collections.singleton(mbean.getClass()); >> 58 } >> >> This mbeanInterfaces method should return the MBean interface class but >> not the class of the mbean implementation. This allows the platform >> mbean to be looked up from ManagementFactory.getPlatformMXBean. If this >> is a dynamic mbean, then this method simply returns an empty list (see >> DiagnosticCommandMBean). > I am almost 100% sure that the bean(s) exposed from Truffle is going to be > DynamicMBean - we compose the attributes dynamically, that wouldn't work with > reflection. > > I'll change the code to return an empty list if the bean is DynamicMBean. > >> To support standard mbean, >> HotSpotJVMCICompilerFactory::mbeans method would need to include the >> mbean interface type in addition to the name and the mbean >> implementation object, i.e. may need to define a specific type for it. > As we don't have any use for this yet I suggest to keep things simple. Since this is mainly for Truffle, keeping it simple is good. > I believe following contract could work: > > public Set> mbeanInterfaces() { > if (mbean instanceof DynamicMBean) { > return Collections.emptySet(); > } else { > Class[] interfaces = mbean.getClass().getInterfaces(); > return new HashSet<>(Arrays.asList(interfaces)); > } > } This isn't exactly right when there is one DynamicMBean and one StandardMBean. ? What about making this version only supporting DynamicMBean - i.e. the provider constructor throws IAE if the mbean instance is not DynamicMBean and mbeanInterfaces method simply returns an empty set. ? This could be enhanced in the future if there is a need to support standard mbean. > if this is acceptable, I would change documentation of the mbean() method to > mention how the set of mbeanInterfaces() is computed. OK? A comment would help. Mandy > Thanks for the review. > -jt > From cthalinger at twitter.com Tue Aug 22 19:37:13 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Tue, 22 Aug 2017 09:37:13 -1000 Subject: [10] RFR(S) 8181858: [JVMCI] JVMCI should update the trap counters when invalidating for Reason_not_compiled_exception_handler In-Reply-To: <59973481.6080805@oracle.com> References: <59973481.6080805@oracle.com> Message-ID: Great we got this finally fixed. Thanks. > On Aug 18, 2017, at 8:40 AM, Tom Rodriguez wrote: > > http://cr.openjdk.java.net/~never/8181858/webrev > https://bugs.openjdk.java.net/browse/JDK-8181858 > > JVMCI permits trapping when exception handlers haven't been compiled into the generated code. When this is a normal uncommon trap the counter in the MDO is updated but when the invalidation is forced during exception dispatch the counter isn't updated. This leads to invalidate/recompile cycles that will never terminate because the compiler doesn't know why the previous invalidation happened. Tested with a Graal unit test https://github.com/graalvm/graal/commit/d92dc3f90c0ba1502a9e28a4faf7973ffd9a1889#diff-96a2a5e9fc63d48d47a9ef9722a7c3d9R102. > > tom From doug.simon at oracle.com Wed Aug 23 15:14:11 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 23 Aug 2017 17:14:11 +0200 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError In-Reply-To: <2D2967B3-FCED-49B8-A92D-EB60186DE047@oracle.com> References: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> <6EE1DA0C-EB3F-41C9-9C43-CEC7DD09ABF9@oracle.com> <18c573f9-ea36-0f0d-630c-a59f24b73a29@oracle.com> <2D2967B3-FCED-49B8-A92D-EB60186DE047@oracle.com> Message-ID: Can I please get one more review on this RFR. -Doug > On 18 Aug 2017, at 23:57, Doug Simon wrote: > > >> On 18 Aug 2017, at 23:58, Vladimir Kozlov wrote: >> >> On 8/18/17 2:49 PM, Doug Simon wrote: >>> It seems easier to do the exception handling in Java and I'm not sure I see a disadvantage to doing it there? >> >> :) I am C++ guy. > > I need to assign more Graal bugs to you to fix that ;-) > >> >> Okay. >> >> Thanks, >> Vladimir >> >>> -Doug >>>> On 18 Aug 2017, at 23:41, Vladimir Kozlov wrote: >>>> >>>> Should you change C++ part of JVMCI instead and check PENDING_EXCEPTION like next? >>>> >>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/oops/method.cpp#l1573 >>>> >>>> or call SystemDictionary::resolve_or_fail() instead of resolve_or_null()?: >>>> >>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/classfile/systemDictionary.cpp#l191 >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/18/17 1:32 PM, Doug Simon wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8186459 >>>>> http://cr.openjdk.java.net/~dnsimon/8186459/ >>>>> -Doug > From igor.veresov at oracle.com Wed Aug 23 17:27:51 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 23 Aug 2017 10:27:51 -0700 Subject: RFR(XL) 8186681: Update Graal Message-ID: Webrev: http://cr.openjdk.java.net/~iveresov/8186681/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8186681 Thanks, igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Wed Aug 23 17:28:34 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 23 Aug 2017 10:28:34 -0700 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError In-Reply-To: References: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> <6EE1DA0C-EB3F-41C9-9C43-CEC7DD09ABF9@oracle.com> <18c573f9-ea36-0f0d-630c-a59f24b73a29@oracle.com> <2D2967B3-FCED-49B8-A92D-EB60186DE047@oracle.com> Message-ID: <9A36633D-986C-4764-BC75-AEB016F891E8@oracle.com> Looks good. igor > On Aug 23, 2017, at 8:14 AM, Doug Simon wrote: > > Can I please get one more review on this RFR. > > -Doug > >> On 18 Aug 2017, at 23:57, Doug Simon wrote: >> >> >>> On 18 Aug 2017, at 23:58, Vladimir Kozlov wrote: >>> >>> On 8/18/17 2:49 PM, Doug Simon wrote: >>>> It seems easier to do the exception handling in Java and I'm not sure I see a disadvantage to doing it there? >>> >>> :) I am C++ guy. >> >> I need to assign more Graal bugs to you to fix that ;-) >> >>> >>> Okay. >>> >>> Thanks, >>> Vladimir >>> >>>> -Doug >>>>> On 18 Aug 2017, at 23:41, Vladimir Kozlov wrote: >>>>> >>>>> Should you change C++ part of JVMCI instead and check PENDING_EXCEPTION like next? >>>>> >>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/oops/method.cpp#l1573 >>>>> >>>>> or call SystemDictionary::resolve_or_fail() instead of resolve_or_null()?: >>>>> >>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/classfile/systemDictionary.cpp#l191 >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/18/17 1:32 PM, Doug Simon wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8186459 >>>>>> http://cr.openjdk.java.net/~dnsimon/8186459/ >>>>>> -Doug >> > From vladimir.kozlov at oracle.com Wed Aug 23 18:02:28 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Aug 2017 11:02:28 -0700 Subject: RFR(XL) 8186681: Update Graal In-Reply-To: References: Message-ID: Looks good. Did you solve build problem you talked about? Thanks, Vladimir On 8/23/17 10:27 AM, Igor Veresov wrote: > Webrev: http://cr.openjdk.java.net/~iveresov/8186681/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8186681 > > > Thanks, > igor From igor.veresov at oracle.com Wed Aug 23 18:24:14 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 23 Aug 2017 11:24:14 -0700 Subject: RFR(XL) 8186681: Update Graal In-Reply-To: References: Message-ID: Yes. All is good. Thanks! igor > On Aug 23, 2017, at 11:02 AM, Vladimir Kozlov wrote: > > Looks good. > > Did you solve build problem you talked about? > > Thanks, > Vladimir > > On 8/23/17 10:27 AM, Igor Veresov wrote: >> Webrev: http://cr.openjdk.java.net/~iveresov/8186681/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8186681 >> Thanks, >> igor From doug.simon at oracle.com Wed Aug 23 20:58:46 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 23 Aug 2017 22:58:46 +0200 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError In-Reply-To: <9A36633D-986C-4764-BC75-AEB016F891E8@oracle.com> References: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> <6EE1DA0C-EB3F-41C9-9C43-CEC7DD09ABF9@oracle.com> <18c573f9-ea36-0f0d-630c-a59f24b73a29@oracle.com> <2D2967B3-FCED-49B8-A92D-EB60186DE047@oracle.com> <9A36633D-986C-4764-BC75-AEB016F891E8@oracle.com> Message-ID: Thanks Igor. I just ran jtreg locally which showed that I need to also fix a number of tests to account for the new checked exception. I also took the liberty of removing `-Djvmci.Compiler=null` from the tests I modified to remove the `jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected` noise. Please check that the test changes look ok. -Doug > On 23 Aug 2017, at 19:28, Igor Veresov wrote: > > Looks good. > > igor > >> On Aug 23, 2017, at 8:14 AM, Doug Simon wrote: >> >> Can I please get one more review on this RFR. >> >> -Doug >> >>> On 18 Aug 2017, at 23:57, Doug Simon wrote: >>> >>> >>>> On 18 Aug 2017, at 23:58, Vladimir Kozlov wrote: >>>> >>>> On 8/18/17 2:49 PM, Doug Simon wrote: >>>>> It seems easier to do the exception handling in Java and I'm not sure I see a disadvantage to doing it there? >>>> >>>> :) I am C++ guy. >>> >>> I need to assign more Graal bugs to you to fix that ;-) >>> >>>> >>>> Okay. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> -Doug >>>>>> On 18 Aug 2017, at 23:41, Vladimir Kozlov wrote: >>>>>> >>>>>> Should you change C++ part of JVMCI instead and check PENDING_EXCEPTION like next? >>>>>> >>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/oops/method.cpp#l1573 >>>>>> >>>>>> or call SystemDictionary::resolve_or_fail() instead of resolve_or_null()?: >>>>>> >>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/classfile/systemDictionary.cpp#l191 >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 8/18/17 1:32 PM, Doug Simon wrote: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186459 >>>>>>> http://cr.openjdk.java.net/~dnsimon/8186459/ >>>>>>> -Doug >>> >> > From vladimir.kozlov at oracle.com Wed Aug 23 21:05:37 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Aug 2017 14:05:37 -0700 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError In-Reply-To: References: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> <6EE1DA0C-EB3F-41C9-9C43-CEC7DD09ABF9@oracle.com> <18c573f9-ea36-0f0d-630c-a59f24b73a29@oracle.com> <2D2967B3-FCED-49B8-A92D-EB60186DE047@oracle.com> <9A36633D-986C-4764-BC75-AEB016F891E8@oracle.com> Message-ID: <308f4fd7-e57f-cc39-9720-06cd569b2518@oracle.com> Should tests be fixed as part of 8186136? Vladimir https://bugs.openjdk.java.net/browse/JDK-8186136 On 8/23/17 1:58 PM, Doug Simon wrote: > Thanks Igor. > > I just ran jtreg locally which showed that I need to also fix a number of tests to account for the new checked exception. I also took the liberty of removing `-Djvmci.Compiler=null` from the tests I modified to remove the `jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected` noise. > > Please check that the test changes look ok. > > -Doug > >> On 23 Aug 2017, at 19:28, Igor Veresov wrote: >> >> Looks good. >> >> igor >> >>> On Aug 23, 2017, at 8:14 AM, Doug Simon wrote: >>> >>> Can I please get one more review on this RFR. >>> >>> -Doug >>> >>>> On 18 Aug 2017, at 23:57, Doug Simon wrote: >>>> >>>> >>>>> On 18 Aug 2017, at 23:58, Vladimir Kozlov wrote: >>>>> >>>>> On 8/18/17 2:49 PM, Doug Simon wrote: >>>>>> It seems easier to do the exception handling in Java and I'm not sure I see a disadvantage to doing it there? >>>>> >>>>> :) I am C++ guy. >>>> >>>> I need to assign more Graal bugs to you to fix that ;-) >>>> >>>>> >>>>> Okay. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> -Doug >>>>>>> On 18 Aug 2017, at 23:41, Vladimir Kozlov wrote: >>>>>>> >>>>>>> Should you change C++ part of JVMCI instead and check PENDING_EXCEPTION like next? >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/oops/method.cpp#l1573 >>>>>>> >>>>>>> or call SystemDictionary::resolve_or_fail() instead of resolve_or_null()?: >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/classfile/systemDictionary.cpp#l191 >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 8/18/17 1:32 PM, Doug Simon wrote: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186459 >>>>>>>> http://cr.openjdk.java.net/~dnsimon/8186459/ >>>>>>>> -Doug >>>> >>> >> > From doug.simon at oracle.com Wed Aug 23 21:10:47 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 23 Aug 2017 23:10:47 +0200 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError In-Reply-To: <308f4fd7-e57f-cc39-9720-06cd569b2518@oracle.com> References: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> <6EE1DA0C-EB3F-41C9-9C43-CEC7DD09ABF9@oracle.com> <18c573f9-ea36-0f0d-630c-a59f24b73a29@oracle.com> <2D2967B3-FCED-49B8-A92D-EB60186DE047@oracle.com> <9A36633D-986C-4764-BC75-AEB016F891E8@oracle.com> <308f4fd7-e57f-cc39-9720-06cd569b2518@oracle.com> Message-ID: > On 23 Aug 2017, at 23:05, Vladimir Kozlov wrote: > > Should tests be fixed as part of 8186136? I assume you mean the removal of -Djvmci.Compiler=null? I guess it would be more consistent to remove this pattern in all the tests at once. I've undone that part of the change. -Doug > > Vladimir > > https://bugs.openjdk.java.net/browse/JDK-8186136 > > On 8/23/17 1:58 PM, Doug Simon wrote: >> Thanks Igor. >> I just ran jtreg locally which showed that I need to also fix a number of tests to account for the new checked exception. I also took the liberty of removing `-Djvmci.Compiler=null` from the tests I modified to remove the `jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected` noise. >> Please check that the test changes look ok. >> -Doug >>> On 23 Aug 2017, at 19:28, Igor Veresov wrote: >>> >>> Looks good. >>> >>> igor >>> >>>> On Aug 23, 2017, at 8:14 AM, Doug Simon wrote: >>>> >>>> Can I please get one more review on this RFR. >>>> >>>> -Doug >>>> >>>>> On 18 Aug 2017, at 23:57, Doug Simon wrote: >>>>> >>>>> >>>>>> On 18 Aug 2017, at 23:58, Vladimir Kozlov wrote: >>>>>> >>>>>> On 8/18/17 2:49 PM, Doug Simon wrote: >>>>>>> It seems easier to do the exception handling in Java and I'm not sure I see a disadvantage to doing it there? >>>>>> >>>>>> :) I am C++ guy. >>>>> >>>>> I need to assign more Graal bugs to you to fix that ;-) >>>>> >>>>>> >>>>>> Okay. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> -Doug >>>>>>>> On 18 Aug 2017, at 23:41, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>> Should you change C++ part of JVMCI instead and check PENDING_EXCEPTION like next? >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/oops/method.cpp#l1573 >>>>>>>> >>>>>>>> or call SystemDictionary::resolve_or_fail() instead of resolve_or_null()?: >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/classfile/systemDictionary.cpp#l191 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 8/18/17 1:32 PM, Doug Simon wrote: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186459 >>>>>>>>> http://cr.openjdk.java.net/~dnsimon/8186459/ >>>>>>>>> -Doug >>>>> >>>> >>> From vladimir.kozlov at oracle.com Wed Aug 23 21:21:11 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Aug 2017 14:21:11 -0700 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError In-Reply-To: References: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> <6EE1DA0C-EB3F-41C9-9C43-CEC7DD09ABF9@oracle.com> <18c573f9-ea36-0f0d-630c-a59f24b73a29@oracle.com> <2D2967B3-FCED-49B8-A92D-EB60186DE047@oracle.com> <9A36633D-986C-4764-BC75-AEB016F891E8@oracle.com> <308f4fd7-e57f-cc39-9720-06cd569b2518@oracle.com> Message-ID: Looks good now. Thanks, Vladimir On 8/23/17 2:10 PM, Doug Simon wrote: > >> On 23 Aug 2017, at 23:05, Vladimir Kozlov wrote: >> >> Should tests be fixed as part of 8186136? > > I assume you mean the removal of -Djvmci.Compiler=null? I guess it would be more consistent to remove this pattern in all the tests at once. I've undone that part of the change. > > -Doug > >> >> Vladimir >> >> https://bugs.openjdk.java.net/browse/JDK-8186136 >> >> On 8/23/17 1:58 PM, Doug Simon wrote: >>> Thanks Igor. >>> I just ran jtreg locally which showed that I need to also fix a number of tests to account for the new checked exception. I also took the liberty of removing `-Djvmci.Compiler=null` from the tests I modified to remove the `jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected` noise. >>> Please check that the test changes look ok. >>> -Doug >>>> On 23 Aug 2017, at 19:28, Igor Veresov wrote: >>>> >>>> Looks good. >>>> >>>> igor >>>> >>>>> On Aug 23, 2017, at 8:14 AM, Doug Simon wrote: >>>>> >>>>> Can I please get one more review on this RFR. >>>>> >>>>> -Doug >>>>> >>>>>> On 18 Aug 2017, at 23:57, Doug Simon wrote: >>>>>> >>>>>> >>>>>>> On 18 Aug 2017, at 23:58, Vladimir Kozlov wrote: >>>>>>> >>>>>>> On 8/18/17 2:49 PM, Doug Simon wrote: >>>>>>>> It seems easier to do the exception handling in Java and I'm not sure I see a disadvantage to doing it there? >>>>>>> >>>>>>> :) I am C++ guy. >>>>>> >>>>>> I need to assign more Graal bugs to you to fix that ;-) >>>>>> >>>>>>> >>>>>>> Okay. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> -Doug >>>>>>>>> On 18 Aug 2017, at 23:41, Vladimir Kozlov wrote: >>>>>>>>> >>>>>>>>> Should you change C++ part of JVMCI instead and check PENDING_EXCEPTION like next? >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/oops/method.cpp#l1573 >>>>>>>>> >>>>>>>>> or call SystemDictionary::resolve_or_fail() instead of resolve_or_null()?: >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/classfile/systemDictionary.cpp#l191 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 8/18/17 1:32 PM, Doug Simon wrote: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186459 >>>>>>>>>> http://cr.openjdk.java.net/~dnsimon/8186459/ >>>>>>>>>> -Doug >>>>>> >>>>> >>>> > From cthalinger at twitter.com Wed Aug 23 21:33:30 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 23 Aug 2017 11:33:30 -1000 Subject: FYI: Graal: [AMD64] implement String.compareTo substitutions Message-ID: https://github.com/graalvm/graal/pull/251 As stated, I cannot test the AVX512VLBW code path. Could someone from Oracle (if you have such machines) or Intel test the code, please? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cthalinger at twitter.com Thu Aug 24 00:08:13 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 23 Aug 2017 14:08:13 -1000 Subject: RFR: 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError In-Reply-To: <2D2967B3-FCED-49B8-A92D-EB60186DE047@oracle.com> References: <57B703CC-1EB1-4F54-AC11-49A99A7DD105@oracle.com> <6EE1DA0C-EB3F-41C9-9C43-CEC7DD09ABF9@oracle.com> <18c573f9-ea36-0f0d-630c-a59f24b73a29@oracle.com> <2D2967B3-FCED-49B8-A92D-EB60186DE047@oracle.com> Message-ID: > On Aug 18, 2017, at 11:57 AM, Doug Simon wrote: > > >> On 18 Aug 2017, at 23:58, Vladimir Kozlov wrote: >> >> On 8/18/17 2:49 PM, Doug Simon wrote: >>> It seems easier to do the exception handling in Java and I'm not sure I see a disadvantage to doing it there? >> >> :) I am C++ guy. > > I need to assign more Graal bugs to you to fix that ;-) LOL > >> >> Okay. >> >> Thanks, >> Vladimir >> >>> -Doug >>>> On 18 Aug 2017, at 23:41, Vladimir Kozlov wrote: >>>> >>>> Should you change C++ part of JVMCI instead and check PENDING_EXCEPTION like next? >>>> >>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/oops/method.cpp#l1573 >>>> >>>> or call SystemDictionary::resolve_or_fail() instead of resolve_or_null()?: >>>> >>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/c8607c55bfda/src/share/vm/classfile/systemDictionary.cpp#l191 >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/18/17 1:32 PM, Doug Simon wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8186459 >>>>> http://cr.openjdk.java.net/~dnsimon/8186459/ >>>>> -Doug > From martin.doerr at sap.com Thu Aug 24 15:02:06 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 24 Aug 2017 15:02:06 +0000 Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: References: Message-ID: <4999bc2a3f0640dfb6dd75d23b4f30ea@sap.com> Hi Gustavo, thank you for providing SHA2 acceleration. It basically looks good. I have also checked that it doesn't break the AIX build. But I have very few change requests. - The file name of the new file should end with _ppc.cpp. - "this->" should be removed from branch instructions: this->b - Why are you using Register references "const Register&"? That's not common. - It would be nice to have Big Endian support if it doesn't take much effort. (I can assist with testing.) Note: This change contains test changes, so a sponsor from Oracle is needed. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet Sent: Donnerstag, 17. August 2017 21:06 To: 'hotspot-compiler-dev at openjdk.java.net' Cc: ppc-aix-port-dev at openjdk.java.net Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic Hi, Could you please review this specific PPC64 change to hotspot? By implementing this intrinsic I noticed a significant improvement when using SHA-2 (e.g: Sample run reduced 6.5s run to 2.8s for SHA256.) JBS: https://bugs.openjdk.java.net/browse/JDK-8185979 Webrev: https://gut.github.io/openjdk/webrev/JDK-8185979/webrev/ Best regards, Gustavo Serra Scalet From vladimir.kozlov at oracle.com Thu Aug 24 16:31:19 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Aug 2017 09:31:19 -0700 Subject: [10] RFR(XS) 8186721: AOT tests fail with: section alignment is not valid: 128 Message-ID: https://bugs.openjdk.java.net/browse/JDK-8186721 Fixed typo in assert code in JDK-8186453 changes - I missed '!' negation: src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffSection.java @@ -50,7 +50,7 @@ byte[] Name = sectName.getBytes(); int max = Name.length <= IMAGE_SECTION_HEADER.Name.sz ? Name.length : IMAGE_SECTION_HEADER.Name.sz; - assert (sectAlign < 1 || sectAlign > 1024 || (sectAlign & (sectAlign - 1)) != 0) : "section alignment is not valid: " + sectAlign; + assert !(sectAlign < 1 || sectAlign > 1024 || (sectAlign & (sectAlign - 1)) != 0) : "section alignment is not valid: " + sectAlign; align = sectAlign; // Using 32 because IMAGE_SCN_ALIGN_*BYTES is value + 1 test/compiler/aot/AotCompiler.java Thu Aug 24 09:29:56 2017 -0700 @@ -113,6 +113,9 @@ args.add("--linker-path"); args.add(linker); } + // Execute with asserts + args.add("-J-ea"); + args.add("-J-esa"); return launchJaotc(args, extraopts); } We should run our JVMCI and AOT tests with -ea -esa so that problem like this do not slip through JPRT and normal testing. I created JDK-8186747 for that. For this bug fix I added -ea -esa for few AOT tests which use AotCompiler class to run jaotc. Thanks, Vladimir From vladimir.kozlov at oracle.com Thu Aug 24 17:48:09 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Aug 2017 10:48:09 -0700 Subject: [10] RFR(s) 8186136: [Graal] some tests setting -Djvmci.Compiler=null fail with: jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected Message-ID: <46f65ef0-509f-4ad2-f760-7c3a1e87ea39@oracle.com> http://cr.openjdk.java.net/~kvn/8186136/webrev/ https://bugs.openjdk.java.net/browse/JDK-8186136 I think most of jvmci tests do not need '-Djvmci.Compiler=graal' for execution - using -Djvmci.Compiler=null is correct thing. We reduce testing time if we don't load Graal. Only test which do compilation and need JIT compiler are fixed for the case when Graal is JIT compiler. I also fixed JVM_GetJVMCIRuntimeTest.java for JDK-8186144 - added -XX:-UseJVMCICompiler for -XX:-EnableJVMCI case. RBT tested and local test with both, default JIT and Graal JIT. Thanks, Vladimir From cthalinger at twitter.com Thu Aug 24 18:52:28 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 24 Aug 2017 08:52:28 -1000 Subject: [10] RFR(s) 8186136: [Graal] some tests setting -Djvmci.Compiler=null fail with: jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected In-Reply-To: <46f65ef0-509f-4ad2-f760-7c3a1e87ea39@oracle.com> References: <46f65ef0-509f-4ad2-f760-7c3a1e87ea39@oracle.com> Message-ID: <0EA6ACEE-5705-4FB4-9676-1E9CB2322CA5@twitter.com> > On Aug 24, 2017, at 7:48 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8186136/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8186136 > > I think most of jvmci tests do not need '-Djvmci.Compiler=graal' for execution - using -Djvmci.Compiler=null is correct thing. We reduce testing time if we don't load Graal. > > Only test which do compilation and need JIT compiler are fixed for the case when Graal is JIT compiler. But isn?t that a timing issue? What if tests are run with -TieredCompilation? > I also fixed JVM_GetJVMCIRuntimeTest.java for JDK-8186144 - added -XX:-UseJVMCICompiler for -XX:-EnableJVMCI case. > > RBT tested and local test with both, default JIT and Graal JIT. > > Thanks, > Vladimir > > From dean.long at oracle.com Thu Aug 24 19:20:01 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 24 Aug 2017 12:20:01 -0700 Subject: [10] RFR(XS) 8186721: AOT tests fail with: section alignment is not valid: 128 In-Reply-To: References: Message-ID: <2fc0dd42-07e4-7ee0-7282-701e6aebfd02@oracle.com> Looks good to me. dl On 8/24/17 9:31 AM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8186721 > > Fixed typo in assert code in JDK-8186453 changes - I missed '!' negation: > > src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffSection.java > > @@ -50,7 +50,7 @@ > byte[] Name = sectName.getBytes(); > int max = Name.length <= IMAGE_SECTION_HEADER.Name.sz ? > Name.length : IMAGE_SECTION_HEADER.Name.sz; > > - assert (sectAlign < 1 || sectAlign > 1024 || (sectAlign & > (sectAlign - 1)) != 0) : "section alignment is not valid: " + sectAlign; > + assert !(sectAlign < 1 || sectAlign > 1024 || (sectAlign & > (sectAlign - 1)) != 0) : "section alignment is not valid: " + sectAlign; > align = sectAlign; > > // Using 32 because IMAGE_SCN_ALIGN_*BYTES is value + 1 > > test/compiler/aot/AotCompiler.java Thu Aug 24 09:29:56 2017 -0700 > @@ -113,6 +113,9 @@ > args.add("--linker-path"); > args.add(linker); > } > + // Execute with asserts > + args.add("-J-ea"); > + args.add("-J-esa"); > return launchJaotc(args, extraopts); > } > > We should run our JVMCI and AOT tests with -ea -esa so that problem > like this do not slip through JPRT and normal testing. I created > JDK-8186747 for that. > > For this bug fix I added -ea -esa for few AOT tests which use > AotCompiler class to run jaotc. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Aug 24 20:01:00 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Aug 2017 13:01:00 -0700 Subject: [10] RFR(XS) 8186721: AOT tests fail with: section alignment is not valid: 128 In-Reply-To: <2fc0dd42-07e4-7ee0-7282-701e6aebfd02@oracle.com> References: <2fc0dd42-07e4-7ee0-7282-701e6aebfd02@oracle.com> Message-ID: <1dbe767d-8822-c139-bddd-86b9d9cd0d77@oracle.com> Thank you, Dean Vladimir On 8/24/17 12:20 PM, dean.long at oracle.com wrote: > Looks good to me. > > dl > > > On 8/24/17 9:31 AM, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8186721 >> >> Fixed typo in assert code in JDK-8186453 changes - I missed '!' negation: >> >> src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffSection.java >> >> @@ -50,7 +50,7 @@ >> ???????? byte[] Name = sectName.getBytes(); >> ???????? int max = Name.length <= IMAGE_SECTION_HEADER.Name.sz ? >> Name.length : IMAGE_SECTION_HEADER.Name.sz; >> >> -??????? assert (sectAlign < 1 || sectAlign > 1024 || (sectAlign & >> (sectAlign - 1)) != 0) : "section alignment is not valid: " + sectAlign; >> +??????? assert !(sectAlign < 1 || sectAlign > 1024 || (sectAlign & >> (sectAlign - 1)) != 0) : "section alignment is not valid: " + sectAlign; >> ???????? align = sectAlign; >> >> ???????? // Using 32 because IMAGE_SCN_ALIGN_*BYTES is value + 1 >> >> test/compiler/aot/AotCompiler.java??? Thu Aug 24 09:29:56 2017 -0700 >> @@ -113,6 +113,9 @@ >> ???????????? args.add("--linker-path"); >> ???????????? args.add(linker); >> ???????? } >> +??????? // Execute with asserts >> +??????? args.add("-J-ea"); >> +??????? args.add("-J-esa"); >> ???????? return launchJaotc(args, extraopts); >> ???? } >> >> We should run our JVMCI and AOT tests with -ea -esa so that problem >> like this do not slip through JPRT and normal testing. I created >> JDK-8186747 for that. >> >> For this bug fix I added -ea -esa for few AOT tests which use >> AotCompiler class to run jaotc. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Thu Aug 24 22:55:08 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Aug 2017 15:55:08 -0700 Subject: [10] RFR(s) 8186136: [Graal] some tests setting -Djvmci.Compiler=null fail with: jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected In-Reply-To: <0EA6ACEE-5705-4FB4-9676-1E9CB2322CA5@twitter.com> References: <46f65ef0-509f-4ad2-f760-7c3a1e87ea39@oracle.com> <0EA6ACEE-5705-4FB4-9676-1E9CB2322CA5@twitter.com> Message-ID: <0fccd1e7-8b06-336f-9030-6268fe10de3d@oracle.com> Thank you, Chris With -TieredCompilation I found other tests need to fix: compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java compiler/jvmci/compilerToVM/ReprofileTest.java And next test needs to be fixed too. I missed it because it is on problem list and failed in all configurations: compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java The rest tests do not do JIT compilation or don't have -Djvmci.Compiler flag. They passed in all configuration. There are other test problem 8186144 which I am working on too. I updated webrev: http://cr.openjdk.java.net/~kvn/8186136/webrev.01/ Thanks, Vladimir On 8/24/17 11:52 AM, Christian Thalinger wrote: > >> On Aug 24, 2017, at 7:48 AM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8186136/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8186136 >> >> I think most of jvmci tests do not need '-Djvmci.Compiler=graal' for execution - using -Djvmci.Compiler=null is correct thing. We reduce testing time if we don't load Graal. >> >> Only test which do compilation and need JIT compiler are fixed for the case when Graal is JIT compiler. > > But isn?t that a timing issue? What if tests are run with -TieredCompilation? > >> I also fixed JVM_GetJVMCIRuntimeTest.java for JDK-8186144 - added -XX:-UseJVMCICompiler for -XX:-EnableJVMCI case. >> >> RBT tested and local test with both, default JIT and Graal JIT. >> >> Thanks, >> Vladimir >> >> > From cthalinger at twitter.com Thu Aug 24 23:31:38 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 24 Aug 2017 13:31:38 -1000 Subject: [10] RFR(s) 8186136: [Graal] some tests setting -Djvmci.Compiler=null fail with: jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected In-Reply-To: <0fccd1e7-8b06-336f-9030-6268fe10de3d@oracle.com> References: <46f65ef0-509f-4ad2-f760-7c3a1e87ea39@oracle.com> <0EA6ACEE-5705-4FB4-9676-1E9CB2322CA5@twitter.com> <0fccd1e7-8b06-336f-9030-6268fe10de3d@oracle.com> Message-ID: <12A19D0D-FD99-4FB3-B203-815BAD970501@twitter.com> > On Aug 24, 2017, at 12:55 PM, Vladimir Kozlov wrote: > > Thank you, Chris > > With -TieredCompilation I found other tests need to fix: > > compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java > compiler/jvmci/compilerToVM/ReprofileTest.java > > And next test needs to be fixed too. I missed it because it is on problem list and failed in all configurations: > > compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java > > The rest tests do not do JIT compilation Trying not to mention -Xcomp :-) > or don't have -Djvmci.Compiler flag. They passed in all configuration. I think that?s good enough for now. > > There are other test problem 8186144 which I am working on too. > > I updated webrev: > > http://cr.openjdk.java.net/~kvn/8186136/webrev.01/ > > Thanks, > Vladimir > > > On 8/24/17 11:52 AM, Christian Thalinger wrote: >>> On Aug 24, 2017, at 7:48 AM, Vladimir Kozlov wrote: >>> >>> http://cr.openjdk.java.net/~kvn/8186136/webrev/ >>> https://bugs.openjdk.java.net/browse/JDK-8186136 >>> >>> I think most of jvmci tests do not need '-Djvmci.Compiler=graal' for execution - using -Djvmci.Compiler=null is correct thing. We reduce testing time if we don't load Graal. >>> >>> Only test which do compilation and need JIT compiler are fixed for the case when Graal is JIT compiler. >> But isn?t that a timing issue? What if tests are run with -TieredCompilation? >>> I also fixed JVM_GetJVMCIRuntimeTest.java for JDK-8186144 - added -XX:-UseJVMCICompiler for -XX:-EnableJVMCI case. >>> >>> RBT tested and local test with both, default JIT and Graal JIT. >>> >>> Thanks, >>> Vladimir >>> >>> From vladimir.kozlov at oracle.com Thu Aug 24 23:39:57 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Aug 2017 16:39:57 -0700 Subject: [10] RFR(s) 8186136: [Graal] some tests setting -Djvmci.Compiler=null fail with: jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected In-Reply-To: <12A19D0D-FD99-4FB3-B203-815BAD970501@twitter.com> References: <46f65ef0-509f-4ad2-f760-7c3a1e87ea39@oracle.com> <0EA6ACEE-5705-4FB4-9676-1E9CB2322CA5@twitter.com> <0fccd1e7-8b06-336f-9030-6268fe10de3d@oracle.com> <12A19D0D-FD99-4FB3-B203-815BAD970501@twitter.com> Message-ID: <5837a380-51cf-526c-9fee-f9e2d7697371@oracle.com> On 8/24/17 4:31 PM, Christian Thalinger wrote: > >> On Aug 24, 2017, at 12:55 PM, Vladimir Kozlov wrote: >> >> Thank you, Chris >> >> With -TieredCompilation I found other tests need to fix: >> >> compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java >> compiler/jvmci/compilerToVM/ReprofileTest.java >> >> And next test needs to be fixed too. I missed it because it is on problem list and failed in all configurations: >> >> compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java >> >> The rest tests do not do JIT compilation > > Trying not to mention -Xcomp :-) You already filed bug for that ;) https://bugs.openjdk.java.net/browse/JDK-8146528 > >> or don't have -Djvmci.Compiler flag. They passed in all configuration. > > I think that?s good enough for now. Thank you, Chris Vladimir > >> >> There are other test problem 8186144 which I am working on too. >> >> I updated webrev: >> >> http://cr.openjdk.java.net/~kvn/8186136/webrev.01/ >> >> Thanks, >> Vladimir >> >> >> On 8/24/17 11:52 AM, Christian Thalinger wrote: >>>> On Aug 24, 2017, at 7:48 AM, Vladimir Kozlov wrote: >>>> >>>> http://cr.openjdk.java.net/~kvn/8186136/webrev/ >>>> https://bugs.openjdk.java.net/browse/JDK-8186136 >>>> >>>> I think most of jvmci tests do not need '-Djvmci.Compiler=graal' for execution - using -Djvmci.Compiler=null is correct thing. We reduce testing time if we don't load Graal. >>>> >>>> Only test which do compilation and need JIT compiler are fixed for the case when Graal is JIT compiler. >>> But isn?t that a timing issue? What if tests are run with -TieredCompilation? >>>> I also fixed JVM_GetJVMCIRuntimeTest.java for JDK-8186144 - added -XX:-UseJVMCICompiler for -XX:-EnableJVMCI case. >>>> >>>> RBT tested and local test with both, default JIT and Graal JIT. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> > From cthalinger at twitter.com Thu Aug 24 23:42:29 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 24 Aug 2017 13:42:29 -1000 Subject: [10] RFR(s) 8186136: [Graal] some tests setting -Djvmci.Compiler=null fail with: jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected In-Reply-To: <5837a380-51cf-526c-9fee-f9e2d7697371@oracle.com> References: <46f65ef0-509f-4ad2-f760-7c3a1e87ea39@oracle.com> <0EA6ACEE-5705-4FB4-9676-1E9CB2322CA5@twitter.com> <0fccd1e7-8b06-336f-9030-6268fe10de3d@oracle.com> <12A19D0D-FD99-4FB3-B203-815BAD970501@twitter.com> <5837a380-51cf-526c-9fee-f9e2d7697371@oracle.com> Message-ID: > On Aug 24, 2017, at 1:39 PM, Vladimir Kozlov wrote: > > On 8/24/17 4:31 PM, Christian Thalinger wrote: >>> On Aug 24, 2017, at 12:55 PM, Vladimir Kozlov wrote: >>> >>> Thank you, Chris >>> >>> With -TieredCompilation I found other tests need to fix: >>> >>> compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java >>> compiler/jvmci/compilerToVM/ReprofileTest.java >>> >>> And next test needs to be fixed too. I missed it because it is on problem list and failed in all configurations: >>> >>> compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java >>> >>> The rest tests do not do JIT compilation >> Trying not to mention -Xcomp :-) > > You already filed bug for that ;) I did? > > https://bugs.openjdk.java.net/browse/JDK-8146528 "Permission violation? > >>> or don't have -Djvmci.Compiler flag. They passed in all configuration. >> I think that?s good enough for now. > > Thank you, Chris > > Vladimir > >>> >>> There are other test problem 8186144 which I am working on too. >>> >>> I updated webrev: >>> >>> http://cr.openjdk.java.net/~kvn/8186136/webrev.01/ >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 8/24/17 11:52 AM, Christian Thalinger wrote: >>>>> On Aug 24, 2017, at 7:48 AM, Vladimir Kozlov wrote: >>>>> >>>>> http://cr.openjdk.java.net/~kvn/8186136/webrev/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8186136 >>>>> >>>>> I think most of jvmci tests do not need '-Djvmci.Compiler=graal' for execution - using -Djvmci.Compiler=null is correct thing. We reduce testing time if we don't load Graal. >>>>> >>>>> Only test which do compilation and need JIT compiler are fixed for the case when Graal is JIT compiler. >>>> But isn?t that a timing issue? What if tests are run with -TieredCompilation? >>>>> I also fixed JVM_GetJVMCIRuntimeTest.java for JDK-8186144 - added -XX:-UseJVMCICompiler for -XX:-EnableJVMCI case. >>>>> >>>>> RBT tested and local test with both, default JIT and Graal JIT. >>>>> >>>>> Thanks, >>>>> Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Aug 24 23:52:03 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Aug 2017 16:52:03 -0700 Subject: [10] RFR(s) 8186136: [Graal] some tests setting -Djvmci.Compiler=null fail with: jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected In-Reply-To: References: <46f65ef0-509f-4ad2-f760-7c3a1e87ea39@oracle.com> <0EA6ACEE-5705-4FB4-9676-1E9CB2322CA5@twitter.com> <0fccd1e7-8b06-336f-9030-6268fe10de3d@oracle.com> <12A19D0D-FD99-4FB3-B203-815BAD970501@twitter.com> <5837a380-51cf-526c-9fee-f9e2d7697371@oracle.com> Message-ID: <8c42bcf1-0164-e427-8e7d-6863e82d2560@oracle.com> I opened 8146528. It was filed before AOT become opened. I think we should treat Graal's methods separately in -Xcomp case. Vladimir On 8/24/17 4:42 PM, Christian Thalinger wrote: > >> On Aug 24, 2017, at 1:39 PM, Vladimir Kozlov >> > wrote: >> >> On 8/24/17 4:31 PM, Christian Thalinger wrote: >>>> On Aug 24, 2017, at 12:55 PM, Vladimir Kozlov >>>> > wrote: >>>> >>>> Thank you, Chris >>>> >>>> With -TieredCompilation I found other tests need to fix: >>>> >>>> compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java >>>> compiler/jvmci/compilerToVM/ReprofileTest.java >>>> >>>> And next test needs to be fixed too. I missed it because it is on >>>> problem list and failed in all configurations: >>>> >>>> compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java >>>> >>>> The rest tests do not do JIT compilation >>> Trying not to mention -Xcomp :-) >> >> You already filed bug for that ;) > > I did? > >> >> https://bugs.openjdk.java.net/browse/JDK-8146528 > > "Permission violation? > >> >>>> or don't have -Djvmci.Compiler flag. They passed in all configuration. >>> I think that?s good enough for now. >> >> Thank you, Chris >> >> Vladimir >> >>>> >>>> There are other test problem 8186144 which I am working on too. >>>> >>>> I updated webrev: >>>> >>>> http://cr.openjdk.java.net/~kvn/8186136/webrev.01/ >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 8/24/17 11:52 AM, Christian Thalinger wrote: >>>>>> On Aug 24, 2017, at 7:48 AM, Vladimir Kozlov >>>>>> wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~kvn/8186136/webrev/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8186136 >>>>>> >>>>>> I think most of jvmci tests do not need '-Djvmci.Compiler=graal' >>>>>> for execution - using -Djvmci.Compiler=null is correct thing. We >>>>>> reduce testing time if we don't load Graal. >>>>>> >>>>>> Only test which do compilation and need JIT compiler are fixed for >>>>>> the case when Graal is JIT compiler. >>>>> But isn?t that a timing issue? ?What if tests are run with >>>>> -TieredCompilation? >>>>>> I also fixed JVM_GetJVMCIRuntimeTest.java for JDK-8186144 - added >>>>>> -XX:-UseJVMCICompiler for -XX:-EnableJVMCI case. >>>>>> >>>>>> RBT tested and local test with both, default JIT and Graal JIT. >>>>>> >>>>>> Thanks, >>>>>> Vladimir > From cthalinger at twitter.com Thu Aug 24 23:55:32 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 24 Aug 2017 13:55:32 -1000 Subject: [10] RFR(s) 8186136: [Graal] some tests setting -Djvmci.Compiler=null fail with: jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected In-Reply-To: <8c42bcf1-0164-e427-8e7d-6863e82d2560@oracle.com> References: <46f65ef0-509f-4ad2-f760-7c3a1e87ea39@oracle.com> <0EA6ACEE-5705-4FB4-9676-1E9CB2322CA5@twitter.com> <0fccd1e7-8b06-336f-9030-6268fe10de3d@oracle.com> <12A19D0D-FD99-4FB3-B203-815BAD970501@twitter.com> <5837a380-51cf-526c-9fee-f9e2d7697371@oracle.com> <8c42bcf1-0164-e427-8e7d-6863e82d2560@oracle.com> Message-ID: > On Aug 24, 2017, at 1:52 PM, Vladimir Kozlov wrote: > > I opened 8146528. It was filed before AOT become opened. > I think we should treat Graal's methods separately in -Xcomp case. I remember now. We could. Tier 4 compilations will be very slow but it might work. On a related note, is anyone working on a jlink plugin or something to AOT compile code? > > Vladimir > > On 8/24/17 4:42 PM, Christian Thalinger wrote: >>> On Aug 24, 2017, at 1:39 PM, Vladimir Kozlov > wrote: >>> >>> On 8/24/17 4:31 PM, Christian Thalinger wrote: >>>>> On Aug 24, 2017, at 12:55 PM, Vladimir Kozlov > wrote: >>>>> >>>>> Thank you, Chris >>>>> >>>>> With -TieredCompilation I found other tests need to fix: >>>>> >>>>> compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java >>>>> compiler/jvmci/compilerToVM/ReprofileTest.java >>>>> >>>>> And next test needs to be fixed too. I missed it because it is on problem list and failed in all configurations: >>>>> >>>>> compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java >>>>> >>>>> The rest tests do not do JIT compilation >>>> Trying not to mention -Xcomp :-) >>> >>> You already filed bug for that ;) >> I did? >>> >>> https://bugs.openjdk.java.net/browse/JDK-8146528 >> "Permission violation? >>> >>>>> or don't have -Djvmci.Compiler flag. They passed in all configuration. >>>> I think that?s good enough for now. >>> >>> Thank you, Chris >>> >>> Vladimir >>> >>>>> >>>>> There are other test problem 8186144 which I am working on too. >>>>> >>>>> I updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~kvn/8186136/webrev.01/ >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On 8/24/17 11:52 AM, Christian Thalinger wrote: >>>>>>> On Aug 24, 2017, at 7:48 AM, Vladimir Kozlov wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~kvn/8186136/webrev/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186136 >>>>>>> >>>>>>> I think most of jvmci tests do not need '-Djvmci.Compiler=graal' for execution - using -Djvmci.Compiler=null is correct thing. We reduce testing time if we don't load Graal. >>>>>>> >>>>>>> Only test which do compilation and need JIT compiler are fixed for the case when Graal is JIT compiler. >>>>>> But isn?t that a timing issue? What if tests are run with -TieredCompilation? >>>>>>> I also fixed JVM_GetJVMCIRuntimeTest.java for JDK-8186144 - added -XX:-UseJVMCICompiler for -XX:-EnableJVMCI case. >>>>>>> >>>>>>> RBT tested and local test with both, default JIT and Graal JIT. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir From goetz.lindenmaier at sap.com Fri Aug 25 06:56:41 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 25 Aug 2017 06:56:41 +0000 Subject: RFR(S): 8186437: Lock held when compiler thread creation is aborted. In-Reply-To: References: Message-ID: Hi, could I please get a second review? I also please need a sponsor. Thanks, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 22. August 2017 16:38 > To: Thomas St?fe > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: RE: RFR(S): 8186437: Lock held when compiler thread creation is > aborted. > > Hi Thomas, > > thanks for the review! > > The control flow is just as in JVM_StartThread, there even an > extra variable is maintained for the error case that is used only once. > > Best regards, > Goetz. > > > > -----Original Message----- > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > > Sent: Dienstag, 22. August 2017 15:37 > > To: Lindenmaier, Goetz > > Cc: hotspot-compiler-dev at openjdk.java.net > > Subject: Re: RFR(S): 8186437: Lock held when compiler thread creation is > > aborted. > > > > Hi Goetz, > > > > > > > > On Tue, Aug 22, 2017 at 3:19 PM, Lindenmaier, Goetz > > > wrote: > > > > > > Hi, > > > > Could I please get reviews for this small change? I also please need a > > sponsor. > > http://cr.openjdk.java.net/~goetz/wr17/8186437-compThrLock/ > > > > > > When the VM is aborted because compiler thread creation fails (seen > > in > > TestOprionsWithRanges with huge stack size) the Thread_lock was not > > released. > > > > > > > > > > Seems fine, if a bit difficult to read. Alternatively, one could have unlocked > > manually - after all, we are never leaving this function, so the ~MutexLocker. > > That would have preserved the control. > > > > Cheers, Thomas > > > > > > > > > > > > Best regards, > > Goetz. > > > > From gustavo.scalet at eldorado.org.br Fri Aug 25 12:57:22 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Fri, 25 Aug 2017 12:57:22 +0000 Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: <4999bc2a3f0640dfb6dd75d23b4f30ea@sap.com> References: <4999bc2a3f0640dfb6dd75d23b4f30ea@sap.com> Message-ID: <0089f9f653a6442aa672af2e15b2b864@serv030.corp.eldorado.org.br> Hi Martin, Thanks for the review! > -----Original Message----- > From: Doerr, Martin > - The file name of the new file should end with _ppc.cpp. It contains already the _ppc, but not as a suffix: "macroAssembler_ppc_sha.cpp" I followed the same idea behind other existing files like "macroAssembler_x86_log10.cpp", "macroAssembler_x86_pow.cpp", "macroAssembler_x86_tan.cpp"... Do you want me to change it to "macroAssembler_sha_ppc.cpp" ? > - "this->" should be removed from branch instructions: this->b Right! Thanks for spotting it. > - Why are you using Register references "const Register&"? That's not > common. For a moment I thought that "Register" was a structure so a reference would reduce initialization of that type, but analyzing now, it's a pointer. Therefore there is no reason to pass a reference to a pointer on my function. I'm changing that. Thanks > - It would be nice to have Big Endian support if it doesn't take much > effort. (I can assist with testing.) I don't see the reason for that because the vshasigmaw/vshasigmad are only available on POWER8 and beyond. Those systems are, AFAIK, little endian only, right? Otherwise I will need to reconsider some steps. But please advise if that will be useful for some platform. > Note: This change contains test changes, so a sponsor from Oracle is > needed. I didn't add tests. I only enabled them to ppc now which should be easy to review. How do I ask for that kind of sponsor? Thanks > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: Donnerstag, 17. August 2017 21:06 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net> > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic > > Hi, > > Could you please review this specific PPC64 change to hotspot? By > implementing this intrinsic I noticed a significant improvement when > using SHA-2 (e.g: Sample run reduced 6.5s run to 2.8s for SHA256.) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185979 > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185979/webrev/ > > Best regards, > Gustavo Serra Scalet From martin.doerr at sap.com Fri Aug 25 14:43:59 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 25 Aug 2017 14:43:59 +0000 Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: <0089f9f653a6442aa672af2e15b2b864@serv030.corp.eldorado.org.br> References: <4999bc2a3f0640dfb6dd75d23b4f30ea@sap.com> <0089f9f653a6442aa672af2e15b2b864@serv030.corp.eldorado.org.br> Message-ID: <59397a3749024e91b56be6e990a3250d@sap.com> Hi Gustavo, thanks for your reply. Ah, x86 uses this naming convention. Looks unusual, but I think we can live with _ppc_sha.cpp. Don't forget that openJDK supports AIX which is a Big Endian PPC64 platform. I think we can disable the code for Big Endian linux as it would require additional VRSAVE handling and I agree with that this platform is not relevant for Power 8. However, AIX is still relevant for modern Power processors. We are only allowed to sponsor changes in jdk or hotspot PPC64/s390 files. As soon as you touch any other hotspot file, you will need a sponsor from Oracle. I suggest that you ask for 2 SAP reviews, maybe somebody from IBM can also review as additional reviewer. It should be possible to find a sponsor from Oracle after the PPC files are thoroughly reviewed. Thanks again and best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Freitag, 25. August 2017 14:57 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Cc: ppc-aix-port-dev at openjdk.java.net Subject: RE: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic Hi Martin, Thanks for the review! > -----Original Message----- > From: Doerr, Martin > - The file name of the new file should end with _ppc.cpp. It contains already the _ppc, but not as a suffix: "macroAssembler_ppc_sha.cpp" I followed the same idea behind other existing files like "macroAssembler_x86_log10.cpp", "macroAssembler_x86_pow.cpp", "macroAssembler_x86_tan.cpp"... Do you want me to change it to "macroAssembler_sha_ppc.cpp" ? > - "this->" should be removed from branch instructions: this->b Right! Thanks for spotting it. > - Why are you using Register references "const Register&"? That's not > common. For a moment I thought that "Register" was a structure so a reference would reduce initialization of that type, but analyzing now, it's a pointer. Therefore there is no reason to pass a reference to a pointer on my function. I'm changing that. Thanks > - It would be nice to have Big Endian support if it doesn't take much > effort. (I can assist with testing.) I don't see the reason for that because the vshasigmaw/vshasigmad are only available on POWER8 and beyond. Those systems are, AFAIK, little endian only, right? Otherwise I will need to reconsider some steps. But please advise if that will be useful for some platform. > Note: This change contains test changes, so a sponsor from Oracle is > needed. I didn't add tests. I only enabled them to ppc now which should be easy to review. How do I ask for that kind of sponsor? Thanks > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: Donnerstag, 17. August 2017 21:06 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net> > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic > > Hi, > > Could you please review this specific PPC64 change to hotspot? By > implementing this intrinsic I noticed a significant improvement when > using SHA-2 (e.g: Sample run reduced 6.5s run to 2.8s for SHA256.) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185979 > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185979/webrev/ > > Best regards, > Gustavo Serra Scalet From gustavo.scalet at eldorado.org.br Fri Aug 25 15:54:25 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Fri, 25 Aug 2017 15:54:25 +0000 Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: <59397a3749024e91b56be6e990a3250d@sap.com> References: <4999bc2a3f0640dfb6dd75d23b4f30ea@sap.com> <0089f9f653a6442aa672af2e15b2b864@serv030.corp.eldorado.org.br> <59397a3749024e91b56be6e990a3250d@sap.com> Message-ID: Hi Martin and Vladimir, I'm cc'ing Vladimir in hope to get some review from Oracle. The following is the updated webrev: https://gut.github.io/openjdk/webrev/JDK-8185979/webrev.01/ Also I remembered the reason why I was using "this->b" when recompiling: there is a common variable named "b" (as I used the naming convention of a SHA-2 paper calling each of the 8 state elements "a" through "h") so that name was taken on those scopes. A cool nit is that I actually found parts that I didn't need the "b" variable despite being declared so I cleaned the sha256_load_h_vec interface and, on other spots, I renamed the "b" variable to "b_". Now I could use "b" instruction directly. > -----Original Message----- > From: Doerr, Martin > > Ah, x86 uses this naming convention. Looks unusual, but I think we can > live with _ppc_sha.cpp. Alright, I'm keeping that then. > Don't forget that openJDK supports AIX which is a Big Endian PPC64 > platform. I think we can disable the code for Big Endian linux as it > would require additional VRSAVE handling and I agree with that this > platform is not relevant for Power 8. However, AIX is still relevant for > modern Power processors. I see. But then is my change on "vm_version_ppc.cpp" enough? (Around the "#if defined(VM_LITTLE_ENDIAN)", on https://gut.github.io/openjdk/webrev/JDK-8185979/webrev.01/src/cpu/ppc/vm/vm_version_ppc.cpp.udiff.html ) Thanks once again > We are only allowed to sponsor changes in jdk or hotspot PPC64/s390 > files. As soon as you touch any other hotspot file, you will need a > sponsor from Oracle. I suggest that you ask for 2 SAP reviews, maybe > somebody from IBM can also review as additional reviewer. It should be > possible to find a sponsor from Oracle after the PPC files are > thoroughly reviewed. > > Thanks again and best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Freitag, 25. August 2017 14:57 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RE: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic > > Hi Martin, > > Thanks for the review! > > > -----Original Message----- > > From: Doerr, Martin > > - The file name of the new file should end with _ppc.cpp. > > It contains already the _ppc, but not as a suffix: > "macroAssembler_ppc_sha.cpp" > I followed the same idea behind other existing files like > "macroAssembler_x86_log10.cpp", "macroAssembler_x86_pow.cpp", > "macroAssembler_x86_tan.cpp"... > > Do you want me to change it to "macroAssembler_sha_ppc.cpp" ? > > > - "this->" should be removed from branch instructions: this->b > > Right! Thanks for spotting it. > > > - Why are you using Register references "const Register&"? That's not > > common. > > For a moment I thought that "Register" was a structure so a reference > would reduce initialization of that type, but analyzing now, it's a > pointer. Therefore there is no reason to pass a reference to a pointer > on my function. > > I'm changing that. Thanks > > > - It would be nice to have Big Endian support if it doesn't take much > > effort. (I can assist with testing.) > > I don't see the reason for that because the vshasigmaw/vshasigmad are > only available on POWER8 and beyond. Those systems are, AFAIK, little > endian only, right? > > Otherwise I will need to reconsider some steps. But please advise if > that will be useful for some platform. > > > Note: This change contains test changes, so a sponsor from Oracle is > > needed. > > I didn't add tests. I only enabled them to ppc now which should be easy > to review. > > How do I ask for that kind of sponsor? > > Thanks > > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Donnerstag, 17. August 2017 21:06 > > To: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net> > > Cc: ppc-aix-port-dev at openjdk.java.net > > Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic > > > > Hi, > > > > Could you please review this specific PPC64 change to hotspot? By > > implementing this intrinsic I noticed a significant improvement when > > using SHA-2 (e.g: Sample run reduced 6.5s run to 2.8s for SHA256.) > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185979 > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185979/webrev/ > > > > Best regards, > > Gustavo Serra Scalet From martin.doerr at sap.com Fri Aug 25 16:18:43 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 25 Aug 2017 16:18:43 +0000 Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: References: <4999bc2a3f0640dfb6dd75d23b4f30ea@sap.com> <0089f9f653a6442aa672af2e15b2b864@serv030.corp.eldorado.org.br> <59397a3749024e91b56be6e990a3250d@sap.com> Message-ID: <363c2378f23e4be2bf60b622594c60fe@sap.com> Hi Gustavo, thanks for the new webrev. You have mentioned a paper which you have used. I think it should be referenced in the comments. I think you didn't get my point about AIX. Your current version doesn't break AIX, but it lacks SHA2 acceleration for AIX on Power 8 and newer, which is still relevant. So I'd like to ask you kindly to take a look if Big Endian support for the stub could be added without high effort. AIX doesn't need VRSAVE handling (like Little Endian linux, unlike Big Endian linux), so a few lines in the stub could possibly be enough. I can assist with testing. Thanks for doing the other changes which I had proposed. Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Freitag, 25. August 2017 17:54 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Cc: ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov Subject: RE: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic Hi Martin and Vladimir, I'm cc'ing Vladimir in hope to get some review from Oracle. The following is the updated webrev: https://gut.github.io/openjdk/webrev/JDK-8185979/webrev.01/ Also I remembered the reason why I was using "this->b" when recompiling: there is a common variable named "b" (as I used the naming convention of a SHA-2 paper calling each of the 8 state elements "a" through "h") so that name was taken on those scopes. A cool nit is that I actually found parts that I didn't need the "b" variable despite being declared so I cleaned the sha256_load_h_vec interface and, on other spots, I renamed the "b" variable to "b_". Now I could use "b" instruction directly. > -----Original Message----- > From: Doerr, Martin > > Ah, x86 uses this naming convention. Looks unusual, but I think we can > live with _ppc_sha.cpp. Alright, I'm keeping that then. > Don't forget that openJDK supports AIX which is a Big Endian PPC64 > platform. I think we can disable the code for Big Endian linux as it > would require additional VRSAVE handling and I agree with that this > platform is not relevant for Power 8. However, AIX is still relevant for > modern Power processors. I see. But then is my change on "vm_version_ppc.cpp" enough? (Around the "#if defined(VM_LITTLE_ENDIAN)", on https://gut.github.io/openjdk/webrev/JDK-8185979/webrev.01/src/cpu/ppc/vm/vm_version_ppc.cpp.udiff.html ) Thanks once again > We are only allowed to sponsor changes in jdk or hotspot PPC64/s390 > files. As soon as you touch any other hotspot file, you will need a > sponsor from Oracle. I suggest that you ask for 2 SAP reviews, maybe > somebody from IBM can also review as additional reviewer. It should be > possible to find a sponsor from Oracle after the PPC files are > thoroughly reviewed. > > Thanks again and best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Freitag, 25. August 2017 14:57 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RE: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic > > Hi Martin, > > Thanks for the review! > > > -----Original Message----- > > From: Doerr, Martin > > - The file name of the new file should end with _ppc.cpp. > > It contains already the _ppc, but not as a suffix: > "macroAssembler_ppc_sha.cpp" > I followed the same idea behind other existing files like > "macroAssembler_x86_log10.cpp", "macroAssembler_x86_pow.cpp", > "macroAssembler_x86_tan.cpp"... > > Do you want me to change it to "macroAssembler_sha_ppc.cpp" ? > > > - "this->" should be removed from branch instructions: this->b > > Right! Thanks for spotting it. > > > - Why are you using Register references "const Register&"? That's not > > common. > > For a moment I thought that "Register" was a structure so a reference > would reduce initialization of that type, but analyzing now, it's a > pointer. Therefore there is no reason to pass a reference to a pointer > on my function. > > I'm changing that. Thanks > > > - It would be nice to have Big Endian support if it doesn't take much > > effort. (I can assist with testing.) > > I don't see the reason for that because the vshasigmaw/vshasigmad are > only available on POWER8 and beyond. Those systems are, AFAIK, little > endian only, right? > > Otherwise I will need to reconsider some steps. But please advise if > that will be useful for some platform. > > > Note: This change contains test changes, so a sponsor from Oracle is > > needed. > > I didn't add tests. I only enabled them to ppc now which should be easy > to review. > > How do I ask for that kind of sponsor? > > Thanks > > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Donnerstag, 17. August 2017 21:06 > > To: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net> > > Cc: ppc-aix-port-dev at openjdk.java.net > > Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic > > > > Hi, > > > > Could you please review this specific PPC64 change to hotspot? By > > implementing this intrinsic I noticed a significant improvement when > > using SHA-2 (e.g: Sample run reduced 6.5s run to 2.8s for SHA256.) > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185979 > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185979/webrev/ > > > > Best regards, > > Gustavo Serra Scalet From gustavo.scalet at eldorado.org.br Fri Aug 25 18:50:55 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Fri, 25 Aug 2017 18:50:55 +0000 Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: <363c2378f23e4be2bf60b622594c60fe@sap.com> References: <4999bc2a3f0640dfb6dd75d23b4f30ea@sap.com> <0089f9f653a6442aa672af2e15b2b864@serv030.corp.eldorado.org.br> <59397a3749024e91b56be6e990a3250d@sap.com> <363c2378f23e4be2bf60b622594c60fe@sap.com> Message-ID: <85906c0ec0d648e29f86e0e6e774ce51@serv031.corp.eldorado.org.br> Hi Martin, > -----Original Message----- > From: Doerr, Martin > > You have mentioned a paper which you have used. I think it should be > referenced in the comments. I've used the following paper: http://www.iwar.org.uk/comsec/resources/cipher/sha256-384-512.pdf You may add it wherever you feel comfortable. > I think you didn't get my point about AIX. > Your current version doesn't break AIX, but it lacks SHA2 acceleration > for AIX on Power 8 and newer, which is still relevant. > So I'd like to ask you kindly to take a look if Big Endian support for > the stub could be added without high effort. AIX doesn't need VRSAVE > handling (like Little Endian linux, unlike Big Endian linux), so a few > lines in the stub could possibly be enough. I can assist with testing. I see. Unfortunately I don't have access to a big endian Linux and it's also not the focus of my current project to improve big endian architectures, so I can't spend too much time on this. But to the best of my efforts, these are the changes that I see that need to be done (please test it then): $ hg diff diff -r c0e9986ddfdb src/cpu/ppc/vm/macroAssembler_ppc_sha.cpp --- a/src/cpu/ppc/vm/macroAssembler_ppc_sha.cpp Fri Aug 25 12:31:12 2017 -0300 +++ b/src/cpu/ppc/vm/macroAssembler_ppc_sha.cpp Fri Aug 25 15:45:58 2017 -0300 @@ -159,6 +159,7 @@ bind(after_w_load); +#if defined(VM_LITTLE_ENDIAN) // Byte swapping on little endian li (tmp, 8); lvsl (vt0, tmp); @@ -168,6 +169,7 @@ VectorRegister w = ws[n]; vperm (w, w, w, vt1); } +#endif // Loading k, which is always aligned to 16-bytes lvx (kpws[0], k); @@ -923,6 +925,7 @@ VectorRegister vsp8 = VR9; vspltish(vsp8, 8); +#if defined(VM_LITTLE_ENDIAN) // Convert input from Big Endian to Little Endian for (int c = 0; c < total_ws; c++) { VectorRegister w = ws[c]; @@ -936,6 +939,7 @@ VectorRegister w = ws[c]; vrld (w, w, vsp32); } +#endif Register Rb = R10; VectorRegister vRb = VR8; > > Thanks for doing the other changes which I had proposed. > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Freitag, 25. August 2017 17:54 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Cc: ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov > > Subject: RE: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic > > Hi Martin and Vladimir, > > I'm cc'ing Vladimir in hope to get some review from Oracle. > > The following is the updated webrev: > https://gut.github.io/openjdk/webrev/JDK-8185979/webrev.01/ > > Also I remembered the reason why I was using "this->b" when recompiling: > there is a common variable named "b" (as I used the naming convention of > a SHA-2 paper calling each of the 8 state elements "a" through "h") so > that name was taken on those scopes. > > A cool nit is that I actually found parts that I didn't need the "b" > variable despite being declared so I cleaned the sha256_load_h_vec > interface and, on other spots, I renamed the "b" variable to "b_". Now I > could use "b" instruction directly. > > > -----Original Message----- > > From: Doerr, Martin > > > > Ah, x86 uses this naming convention. Looks unusual, but I think we can > > live with _ppc_sha.cpp. > > Alright, I'm keeping that then. > > > Don't forget that openJDK supports AIX which is a Big Endian PPC64 > > platform. I think we can disable the code for Big Endian linux as it > > would require additional VRSAVE handling and I agree with that this > > platform is not relevant for Power 8. However, AIX is still relevant > > for modern Power processors. > > I see. But then is my change on "vm_version_ppc.cpp" enough? (Around the > "#if defined(VM_LITTLE_ENDIAN)", on > https://gut.github.io/openjdk/webrev/JDK- > 8185979/webrev.01/src/cpu/ppc/vm/vm_version_ppc.cpp.udiff.html ) > > > Thanks once again > > > We are only allowed to sponsor changes in jdk or hotspot PPC64/s390 > > files. As soon as you touch any other hotspot file, you will need a > > sponsor from Oracle. I suggest that you ask for 2 SAP reviews, maybe > > somebody from IBM can also review as additional reviewer. It should be > > possible to find a sponsor from Oracle after the PPC files are > > thoroughly reviewed. > > > > Thanks again and best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Freitag, 25. August 2017 14:57 > > To: Doerr, Martin ; 'hotspot-compiler- > > dev at openjdk.java.net' > > Cc: ppc-aix-port-dev at openjdk.java.net > > Subject: RE: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic > > > > Hi Martin, > > > > Thanks for the review! > > > > > -----Original Message----- > > > From: Doerr, Martin > > > - The file name of the new file should end with _ppc.cpp. > > > > It contains already the _ppc, but not as a suffix: > > "macroAssembler_ppc_sha.cpp" > > I followed the same idea behind other existing files like > > "macroAssembler_x86_log10.cpp", "macroAssembler_x86_pow.cpp", > > "macroAssembler_x86_tan.cpp"... > > > > Do you want me to change it to "macroAssembler_sha_ppc.cpp" ? > > > > > - "this->" should be removed from branch instructions: this->b > > > > Right! Thanks for spotting it. > > > > > - Why are you using Register references "const Register&"? That's > > > not common. > > > > For a moment I thought that "Register" was a structure so a reference > > would reduce initialization of that type, but analyzing now, it's a > > pointer. Therefore there is no reason to pass a reference to a pointer > > on my function. > > > > I'm changing that. Thanks > > > > > - It would be nice to have Big Endian support if it doesn't take > > > much effort. (I can assist with testing.) > > > > I don't see the reason for that because the vshasigmaw/vshasigmad are > > only available on POWER8 and beyond. Those systems are, AFAIK, little > > endian only, right? > > > > Otherwise I will need to reconsider some steps. But please advise if > > that will be useful for some platform. > > > > > Note: This change contains test changes, so a sponsor from Oracle is > > > needed. > > > > I didn't add tests. I only enabled them to ppc now which should be > > easy to review. > > > > How do I ask for that kind of sponsor? > > > > Thanks > > > > > > > > Best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Donnerstag, 17. August 2017 21:06 > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net> > > > Cc: ppc-aix-port-dev at openjdk.java.net > > > Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic > > > > > > Hi, > > > > > > Could you please review this specific PPC64 change to hotspot? By > > > implementing this intrinsic I noticed a significant improvement when > > > using SHA-2 (e.g: Sample run reduced 6.5s run to 2.8s for SHA256.) > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185979 > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185979/webrev/ > > > > > > Best regards, > > > Gustavo Serra Scalet From gromero at linux.vnet.ibm.com Fri Aug 25 20:35:00 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 25 Aug 2017 17:35:00 -0300 Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: <363c2378f23e4be2bf60b622594c60fe@sap.com> References: <4999bc2a3f0640dfb6dd75d23b4f30ea@sap.com> <0089f9f653a6442aa672af2e15b2b864@serv030.corp.eldorado.org.br> <59397a3749024e91b56be6e990a3250d@sap.com> <363c2378f23e4be2bf60b622594c60fe@sap.com> Message-ID: <59A089F4.6010504@linux.vnet.ibm.com> Hi Martin, On 25-08-2017 13:18, Doerr, Martin wrote: > I think you didn't get my point about AIX. > Your current version doesn't break AIX, but it lacks SHA2 acceleration for AIX on Power 8 and newer, which is still relevant. > So I'd like to ask you kindly to take a look if Big Endian support for the stub could be added without high effort. AIX doesn't need VRSAVE handling (like Little Endian linux, unlike Big Endian linux), so a few lines in the stub could possibly be enough. I can assist with testing. I don't think that VRSAVE is handled on Linux, even on BE. Although BE ABI [1] says: "Functions must ensure that the appropriate bits in the vrsave register are set for any vector registers they use" and LE ABI does not say that, even on Linux BE VRSAVE is not in effect used to determine which vector registers (VMX/Altivec) should be saved/restored. No application uses it on Linux, so I would say that VRSAVE is ignored on Linux completely both on BE and LE. save/restore library interfaces don't pay attention to it in glibc: VRSAVE is just saved/restored completely in mechanisms of swap/get/setcontext(), set/longjump(), and dl-trampoline() and that's all. I checked that with toolchain folks and they agree. We've already discussed that a long time ago but at that time I was just using the vector-scalar registers [2] and at that time I agreed that if VMX/Altivec was in use instead of the VSX so VRSAVE should be handled accordingly. But I have a different opinion now... I'm wondering if something would really break on Linux BE if we forget about VRSAVE at all in the JVM. If not, we could forget about VRSAVE forever on Linux. Looks like VRSAVE was sort of born to the oblivion... ? Kind regards, Gustavo [1] http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html [2] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-May/002508.html From vladimir.kozlov at oracle.com Fri Aug 25 20:51:58 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Aug 2017 13:51:58 -0700 Subject: RFR(S): 8186437: Lock held when compiler thread creation is aborted. In-Reply-To: References: Message-ID: <999dbc19-53cf-f967-95e3-844befeed30e@oracle.com> Looks good. I will sponsor it. Thanks, Vladimir On 8/24/17 11:56 PM, Lindenmaier, Goetz wrote: > Hi, > > could I please get a second review? I also please need a sponsor. > > Thanks, > Goetz. > > >> -----Original Message----- >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >> bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz >> Sent: Dienstag, 22. August 2017 16:38 >> To: Thomas St?fe >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: RE: RFR(S): 8186437: Lock held when compiler thread creation is >> aborted. >> >> Hi Thomas, >> >> thanks for the review! >> >> The control flow is just as in JVM_StartThread, there even an >> extra variable is maintained for the error case that is used only once. >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>> Sent: Dienstag, 22. August 2017 15:37 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-compiler-dev at openjdk.java.net >>> Subject: Re: RFR(S): 8186437: Lock held when compiler thread creation is >>> aborted. >>> >>> Hi Goetz, >>> >>> >>> >>> On Tue, Aug 22, 2017 at 3:19 PM, Lindenmaier, Goetz >>> > wrote: >>> >>> >>> Hi, >>> >>> Could I please get reviews for this small change? I also please need a >>> sponsor. >>> http://cr.openjdk.java.net/~goetz/wr17/8186437-compThrLock/ >>> >>> >>> When the VM is aborted because compiler thread creation fails (seen >>> in >>> TestOprionsWithRanges with huge stack size) the Thread_lock was not >>> released. >>> >>> >>> >>> >>> Seems fine, if a bit difficult to read. Alternatively, one could have unlocked >>> manually - after all, we are never leaving this function, so the ~MutexLocker. >>> That would have preserved the control. >>> >>> Cheers, Thomas >>> >>> >>> >>> >>> >>> Best regards, >>> Goetz. >>> >>> > From vladimir.kozlov at oracle.com Fri Aug 25 22:33:11 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Aug 2017 15:33:11 -0700 Subject: [10] RFR(S) 8186144: [Graal] some tests fail with: Improperly specified VM option UseJVMCICompiler: EnableJVMCI cannot be disabled Message-ID: webrev: http://cr.openjdk.java.net/~kvn/8186144/webrev/ https://bugs.openjdk.java.net/browse/JDK-8186144 Some jvmci tests disable JVMCI which cause problems if Graal is used as JIT. In such cases disable Graal by switching off UseJVMCICompiler. I also removed OSR compilation request from DisassembleCodeBlobTest.java because Graal correctly complains that compiled methods don't have loop. In SecurityRestrictionsTest.java I disable Graal in NO_JVMCI_ACCESS_PERM case when access restriction is enforced on JVMCI - we can't start Graal in such case. RBT and local testing. Thanks, Vladimir From cthalinger at twitter.com Fri Aug 25 22:39:44 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 25 Aug 2017 12:39:44 -1000 Subject: [10] RFR(S) 8186144: [Graal] some tests fail with: Improperly specified VM option UseJVMCICompiler: EnableJVMCI cannot be disabled In-Reply-To: References: Message-ID: > On Aug 25, 2017, at 12:33 PM, Vladimir Kozlov wrote: > > webrev: http://cr.openjdk.java.net/~kvn/8186144/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8186144 > > Some jvmci tests disable JVMCI which cause problems if Graal is used as JIT. In such cases disable Graal by switching off UseJVMCICompiler. Is it always guaranteed that the flags in the @run directive win over the ones passed on the command line? > > I also removed OSR compilation request from DisassembleCodeBlobTest.java because Graal correctly complains that compiled methods don't have loop. > > In SecurityRestrictionsTest.java I disable Graal in NO_JVMCI_ACCESS_PERM case when access restriction is enforced on JVMCI - we can't start Graal in such case. > > RBT and local testing. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Fri Aug 25 22:41:11 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Aug 2017 15:41:11 -0700 Subject: [10] RFR(S) 8186144: [Graal] some tests fail with: Improperly specified VM option UseJVMCICompiler: EnableJVMCI cannot be disabled In-Reply-To: References: Message-ID: <6108e024-1da0-6787-b37a-c030809b7d69@oracle.com> On 8/25/17 3:39 PM, Christian Thalinger wrote: > >> On Aug 25, 2017, at 12:33 PM, Vladimir Kozlov wrote: >> >> webrev: http://cr.openjdk.java.net/~kvn/8186144/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8186144 >> >> Some jvmci tests disable JVMCI which cause problems if Graal is used as JIT. In such cases disable Graal by switching off UseJVMCICompiler. > > Is it always guaranteed that the flags in the @run directive win over the ones passed on the command line? Yes. Vladimir > >> >> I also removed OSR compilation request from DisassembleCodeBlobTest.java because Graal correctly complains that compiled methods don't have loop. >> >> In SecurityRestrictionsTest.java I disable Graal in NO_JVMCI_ACCESS_PERM case when access restriction is enforced on JVMCI - we can't start Graal in such case. >> >> RBT and local testing. >> >> Thanks, >> Vladimir > From cthalinger at twitter.com Fri Aug 25 22:52:06 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 25 Aug 2017 12:52:06 -1000 Subject: [10] RFR(S) 8186144: [Graal] some tests fail with: Improperly specified VM option UseJVMCICompiler: EnableJVMCI cannot be disabled In-Reply-To: <6108e024-1da0-6787-b37a-c030809b7d69@oracle.com> References: <6108e024-1da0-6787-b37a-c030809b7d69@oracle.com> Message-ID: <5E1D862E-7189-4BB2-B9DB-D3D64E5A1282@twitter.com> > On Aug 25, 2017, at 12:41 PM, Vladimir Kozlov wrote: > > On 8/25/17 3:39 PM, Christian Thalinger wrote: >>> On Aug 25, 2017, at 12:33 PM, Vladimir Kozlov wrote: >>> >>> webrev: http://cr.openjdk.java.net/~kvn/8186144/webrev/ >>> https://bugs.openjdk.java.net/browse/JDK-8186144 >>> >>> Some jvmci tests disable JVMCI which cause problems if Graal is used as JIT. In such cases disable Graal by switching off UseJVMCICompiler. >> Is it always guaranteed that the flags in the @run directive win over the ones passed on the command line? > > Yes. Thanks for confirming. I wasn?t sure. Looks good. > > Vladimir > >>> >>> I also removed OSR compilation request from DisassembleCodeBlobTest.java because Graal correctly complains that compiled methods don't have loop. >>> >>> In SecurityRestrictionsTest.java I disable Graal in NO_JVMCI_ACCESS_PERM case when access restriction is enforced on JVMCI - we can't start Graal in such case. >>> >>> RBT and local testing. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Sat Aug 26 01:17:56 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Aug 2017 18:17:56 -0700 Subject: [10] RFR(S) 8186144: [Graal] some tests fail with: Improperly specified VM option UseJVMCICompiler: EnableJVMCI cannot be disabled In-Reply-To: <5E1D862E-7189-4BB2-B9DB-D3D64E5A1282@twitter.com> References: <6108e024-1da0-6787-b37a-c030809b7d69@oracle.com> <5E1D862E-7189-4BB2-B9DB-D3D64E5A1282@twitter.com> Message-ID: Thank you, Chris Vladimir On 8/25/17 3:52 PM, Christian Thalinger wrote: > >> On Aug 25, 2017, at 12:41 PM, Vladimir Kozlov wrote: >> >> On 8/25/17 3:39 PM, Christian Thalinger wrote: >>>> On Aug 25, 2017, at 12:33 PM, Vladimir Kozlov wrote: >>>> >>>> webrev: http://cr.openjdk.java.net/~kvn/8186144/webrev/ >>>> https://bugs.openjdk.java.net/browse/JDK-8186144 >>>> >>>> Some jvmci tests disable JVMCI which cause problems if Graal is used as JIT. In such cases disable Graal by switching off UseJVMCICompiler. >>> Is it always guaranteed that the flags in the @run directive win over the ones passed on the command line? >> >> Yes. > > Thanks for confirming. I wasn?t sure. Looks good. >> >> Vladimir >> >>>> >>>> I also removed OSR compilation request from DisassembleCodeBlobTest.java because Graal correctly complains that compiled methods don't have loop. >>>> >>>> In SecurityRestrictionsTest.java I disable Graal in NO_JVMCI_ACCESS_PERM case when access restriction is enforced on JVMCI - we can't start Graal in such case. >>>> >>>> RBT and local testing. >>>> >>>> Thanks, >>>> Vladimir > From goetz.lindenmaier at sap.com Sat Aug 26 13:22:44 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 26 Aug 2017 13:22:44 +0000 Subject: RFR(S): 8186437: Lock held when compiler thread creation is aborted. In-Reply-To: <999dbc19-53cf-f967-95e3-844befeed30e@oracle.com> References: <999dbc19-53cf-f967-95e3-844befeed30e@oracle.com> Message-ID: <80cd15520d444d46aa0814ec06b85e6f@sap.com> Hi Vladimir, thanks a lot! Best regards, Goetz. > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, August 25, 2017 10:52 PM > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): 8186437: Lock held when compiler thread creation is > aborted. > > Looks good. I will sponsor it. > > Thanks, > Vladimir > > On 8/24/17 11:56 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > could I please get a second review? I also please need a sponsor. > > > > Thanks, > > Goetz. > > > > > >> -----Original Message----- > >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > >> bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz > >> Sent: Dienstag, 22. August 2017 16:38 > >> To: Thomas St?fe > >> Cc: hotspot-compiler-dev at openjdk.java.net > >> Subject: RE: RFR(S): 8186437: Lock held when compiler thread creation is > >> aborted. > >> > >> Hi Thomas, > >> > >> thanks for the review! > >> > >> The control flow is just as in JVM_StartThread, there even an > >> extra variable is maintained for the error case that is used only once. > >> > >> Best regards, > >> Goetz. > >> > >> > >>> -----Original Message----- > >>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > >>> Sent: Dienstag, 22. August 2017 15:37 > >>> To: Lindenmaier, Goetz > >>> Cc: hotspot-compiler-dev at openjdk.java.net > >>> Subject: Re: RFR(S): 8186437: Lock held when compiler thread creation is > >>> aborted. > >>> > >>> Hi Goetz, > >>> > >>> > >>> > >>> On Tue, Aug 22, 2017 at 3:19 PM, Lindenmaier, Goetz > >>> > > wrote: > >>> > >>> > >>> Hi, > >>> > >>> Could I please get reviews for this small change? I also please need a > >>> sponsor. > >>> http://cr.openjdk.java.net/~goetz/wr17/8186437-compThrLock/ > >>> > >>> > >>> When the VM is aborted because compiler thread creation fails (seen > >>> in > >>> TestOprionsWithRanges with huge stack size) the Thread_lock was > not > >>> released. > >>> > >>> > >>> > >>> > >>> Seems fine, if a bit difficult to read. Alternatively, one could have > unlocked > >>> manually - after all, we are never leaving this function, so the > ~MutexLocker. > >>> That would have preserved the control. > >>> > >>> Cheers, Thomas > >>> > >>> > >>> > >>> > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > > From rahul.v.raghavan at oracle.com Mon Aug 28 12:22:33 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 28 Aug 2017 17:52:33 +0530 Subject: [10] RFR(XXS): 8186666: Bug in the C2 matcher code Message-ID: <84beeb94-bc2e-f4ae-625c-47dd72f8dbd1@oracle.com> Hi, Please review the following small fix proposal: - http://cr.openjdk.java.net/~rraghavan/8186666/webrev.00/ [src/share/vm/opto/c2compiler.cpp] case vmIntrinsics::_weakCompareAndSetInt: - if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapL)) return false; + if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapI)) return false; - https://bugs.openjdk.java.net/browse/JDK-8186666 - http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-August/026820.html Thank you Andrew Haley for reporting, contributing the fix. Thanks, Rahul From shade at redhat.com Mon Aug 28 06:55:22 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 28 Aug 2017 08:55:22 +0200 Subject: [10] RFR(XXS): 8186666: Bug in the C2 matcher code In-Reply-To: <84beeb94-bc2e-f4ae-625c-47dd72f8dbd1@oracle.com> References: <84beeb94-bc2e-f4ae-625c-47dd72f8dbd1@oracle.com> Message-ID: On 08/28/2017 02:22 PM, Rahul Raghavan wrote: > Hi, > > Please review the following small fix proposal: > > - http://cr.openjdk.java.net/~rraghavan/8186666/webrev.00/ > > [src/share/vm/opto/c2compiler.cpp] > case vmIntrinsics::_weakCompareAndSetInt: > - if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapL)) return false; > + if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapI)) return false; My fault. Fix looks good! -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Mon Aug 28 07:07:27 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 28 Aug 2017 09:07:27 +0200 Subject: [10] RFR(XXS): 8186666: Bug in the C2 matcher code In-Reply-To: <84beeb94-bc2e-f4ae-625c-47dd72f8dbd1@oracle.com> References: <84beeb94-bc2e-f4ae-625c-47dd72f8dbd1@oracle.com> Message-ID: Hi Rahul, looks good to me! Thanks, Tobias On 28.08.2017 14:22, Rahul Raghavan wrote: > Hi, > > Please review the following small fix proposal: > > - http://cr.openjdk.java.net/~rraghavan/8186666/webrev.00/ > > [src/share/vm/opto/c2compiler.cpp] > case vmIntrinsics::_weakCompareAndSetInt: > - if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapL)) return false; > + if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapI)) return false; > > > - https://bugs.openjdk.java.net/browse/JDK-8186666 > - http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-August/026820.html > > Thank you Andrew Haley for reporting, contributing the fix. > > > Thanks, > Rahul From rahul.v.raghavan at oracle.com Mon Aug 28 14:15:38 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 28 Aug 2017 14:15:38 +0000 Subject: [10] RFR(XXS): 8186666: Bug in the C2 matcher code In-Reply-To: References: <84beeb94-bc2e-f4ae-625c-47dd72f8dbd1@oracle.com> Message-ID: Thanks for your review Aleksey. -Rahul On Monday 28 August 2017 06:55 AM, Aleksey Shipilev wrote: > On 08/28/2017 02:22 PM, Rahul Raghavan wrote: >> Hi, >> >> Please review the following small fix proposal: >> >> - http://cr.openjdk.java.net/~rraghavan/8186666/webrev.00/ >> >> [src/share/vm/opto/c2compiler.cpp] >> case vmIntrinsics::_weakCompareAndSetInt: >> - if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapL)) return false; >> + if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapI)) return false; > > My fault. Fix looks good! > > -Aleksey > From rahul.v.raghavan at oracle.com Mon Aug 28 14:16:22 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 28 Aug 2017 14:16:22 +0000 Subject: [10] RFR(XXS): 8186666: Bug in the C2 matcher code In-Reply-To: References: <84beeb94-bc2e-f4ae-625c-47dd72f8dbd1@oracle.com> Message-ID: Thank you Tobias. On Monday 28 August 2017 07:07 AM, Tobias Hartmann wrote: > Hi Rahul, > > looks good to me! > > Thanks, > Tobias > > On 28.08.2017 14:22, Rahul Raghavan wrote: >> Hi, >> >> Please review the following small fix proposal: >> >> - http://cr.openjdk.java.net/~rraghavan/8186666/webrev.00/ >> >> [src/share/vm/opto/c2compiler.cpp] >> case vmIntrinsics::_weakCompareAndSetInt: >> - if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapL)) >> return false; >> + if (!Matcher::match_rule_supported(Op_WeakCompareAndSwapI)) >> return false; >> >> >> - https://bugs.openjdk.java.net/browse/JDK-8186666 >> - >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-August/026820.html >> >> >> Thank you Andrew Haley for reporting, contributing the fix. >> >> >> Thanks, >> Rahul From patric.hedlin at oracle.com Mon Aug 28 13:06:54 2017 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Mon, 28 Aug 2017 15:06:54 +0200 Subject: JDK10/RFR(L): 8167199: Add C2 SPARC intrinsic for BigInteger::multiplyToLen() method. Message-ID: Dear all, I would like to ask for help to review the following change/update: Issue: https://bugs.openjdk.java.net/browse/JDK-8167199 Webrev: http://cr.openjdk.java.net/~phedlin/tr8167199/ 8167199: Add C2 SPARC intrinsic for BigInteger::multiplyToLen() method. Added C2 SPARC support for intrinsic 'multiplyToLen', including generalised version based on 'mpmul' instruction (when available). The code emitted should be subject for evaluation (e.g. MME on SPARC Core C5 might be used in an improved version). Testing: Mostly tested on JDK9 (jtreg/RBT/hotspot/tier0-comp). Testing on JDK10 (jtreg/RBT/hotspot/precheckin-comp). Best regards, Patric From vladimir.kozlov at oracle.com Mon Aug 28 20:18:13 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Aug 2017 13:18:13 -0700 Subject: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build Message-ID: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> http://cr.openjdk.java.net/~kvn/8186462/webrev/ https://bugs.openjdk.java.net/browse/JDK-8186462 We are planning to have Graal as experimental JIT compiler on linux-x64 in next release. For that we should enable its build independent from AOT build. Thanks, Vladimir From cthalinger at twitter.com Mon Aug 28 20:56:55 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 28 Aug 2017 10:56:55 -1000 Subject: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build In-Reply-To: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> References: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> Message-ID: <556CDFD1-425F-4205-B469-4F97D7F770BD@twitter.com> > On Aug 28, 2017, at 10:18 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8186462/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8186462 > > We are planning to have Graal as experimental JIT compiler on linux-x64 in next release. For that we should enable its build independent from AOT build. Needless to say I am very happy to see this. The change looks good. > > Thanks, > Vladimir From igor.veresov at oracle.com Mon Aug 28 21:12:48 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 28 Aug 2017 14:12:48 -0700 Subject: RFR(L) 8186850: Update Graal Message-ID: <7C83609D-48BE-4C9D-8390-3E553B064B9F@oracle.com> Webrev: http://cr.openjdk.java.net/~iveresov/8186850/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8186850 Thanks, igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Aug 28 21:33:39 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Aug 2017 14:33:39 -0700 Subject: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build In-Reply-To: <556CDFD1-425F-4205-B469-4F97D7F770BD@twitter.com> References: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> <556CDFD1-425F-4205-B469-4F97D7F770BD@twitter.com> Message-ID: <7aa1d194-9039-b205-342a-01221ae27b4b@oracle.com> Thank you, Chris Vladimir On 8/28/17 1:56 PM, Christian Thalinger wrote: > >> On Aug 28, 2017, at 10:18 AM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8186462/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8186462 >> >> We are planning to have Graal as experimental JIT compiler on linux-x64 in next release. For that we should enable its build independent from AOT build. > > Needless to say I am very happy to see this. The change looks good. > >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Mon Aug 28 21:42:33 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Aug 2017 14:42:33 -0700 Subject: RFR(L) 8186850: Update Graal In-Reply-To: <7C83609D-48BE-4C9D-8390-3E553B064B9F@oracle.com> References: <7C83609D-48BE-4C9D-8390-3E553B064B9F@oracle.com> Message-ID: <99338566-5dcd-48c1-b3b8-5910199c7c45@oracle.com> Looks good. Thanks, Vladimir On 8/28/17 2:12 PM, Igor Veresov wrote: > Webrev: http://cr.openjdk.java.net/~iveresov/8186850/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8186850 > > Thanks, > igor From igor.veresov at oracle.com Mon Aug 28 21:43:06 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 28 Aug 2017 14:43:06 -0700 Subject: RFR(L) 8186850: Update Graal In-Reply-To: <99338566-5dcd-48c1-b3b8-5910199c7c45@oracle.com> References: <7C83609D-48BE-4C9D-8390-3E553B064B9F@oracle.com> <99338566-5dcd-48c1-b3b8-5910199c7c45@oracle.com> Message-ID: <2AA5E9E4-46ED-44BC-92BC-115BBB03D80D@oracle.com> Thanks, Vladimir! igor > On Aug 28, 2017, at 2:42 PM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 8/28/17 2:12 PM, Igor Veresov wrote: >> Webrev: http://cr.openjdk.java.net/~iveresov/8186850/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8186850 >> Thanks, >> igor From tobias.hartmann at oracle.com Tue Aug 29 05:20:56 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 29 Aug 2017 07:20:56 +0200 Subject: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build In-Reply-To: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> References: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> Message-ID: Hi Vladimir, On 28.08.2017 22:18, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8186462/webrev/ Looks good to me! Best regards, Tobias From vladimir.kozlov at oracle.com Tue Aug 29 06:09:14 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Aug 2017 23:09:14 -0700 Subject: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build In-Reply-To: References: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> Message-ID: <359a54e5-e58a-2f1a-691e-b2e546479080@oracle.com> Thank you, Tobias Vladimir On 8/28/17 10:20 PM, Tobias Hartmann wrote: > Hi Vladimir, > > On 28.08.2017 22:18, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8186462/webrev/ > > Looks good to me! > > Best regards, > Tobias From erik.joelsson at oracle.com Tue Aug 29 07:14:21 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 29 Aug 2017 09:14:21 +0200 Subject: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build In-Reply-To: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> References: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> Message-ID: <78736623-e167-6105-0bad-16f70e95adac@oracle.com> Looks good to me. /Erik On 2017-08-28 22:18, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8186462/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8186462 > > We are planning to have Graal as experimental JIT compiler on > linux-x64 in next release. For that we should enable its build > independent from AOT build. > > Thanks, > Vladimir From aph at redhat.com Tue Aug 29 08:15:15 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Aug 2017 09:15:15 +0100 Subject: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build In-Reply-To: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> References: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> Message-ID: On 28/08/17 21:18, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8186462/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8186462 > > We are planning to have Graal as experimental JIT compiler on linux-x64 > in next release. For that we should enable its build independent from > AOT build. Super! Good news. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nils.eliasson at oracle.com Tue Aug 29 09:22:04 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 29 Aug 2017 11:22:04 +0200 Subject: JDK10/RFR(L): 8167199: Add C2 SPARC intrinsic for BigInteger::multiplyToLen() method. In-Reply-To: References: Message-ID: Hi Patric, Looks good. Just make sure this code path is covered in the regular testing. Regards, Nils On 2017-08-28 15:06, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8167199 > > Webrev: http://cr.openjdk.java.net/~phedlin/tr8167199/ > > > 8167199: Add C2 SPARC intrinsic for BigInteger::multiplyToLen() method. > > Added C2 SPARC support for intrinsic 'multiplyToLen', including > generalised version based on 'mpmul' instruction (when available). > The code emitted should be subject for evaluation (e.g. MME on > SPARC Core C5 might be used in an improved version). > > Testing: > > Mostly tested on JDK9 (jtreg/RBT/hotspot/tier0-comp). > Testing on JDK10 (jtreg/RBT/hotspot/precheckin-comp). > > > Best regards, > Patric From robbin.ehn at oracle.com Tue Aug 29 10:31:17 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 29 Aug 2017 12:31:17 +0200 Subject: RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark Message-ID: <9fc2a70d-70bb-362b-16dd-6b5eaf018991@oracle.com> Hi please review, The issue 8180932 - "Parallelize safepoint cleanup" changed _stack_traversal_mark to load acquire/store release, this is at least half wrong. Instead for simplicity the write side storestore fence should be match with loadload on read side and the changes to _stack_traversal_mark undone (kept it volatile). Bug: https://bugs.openjdk.java.net/browse/JDK-8186837 Code: http://cr.openjdk.java.net/~rehn/8186837/hotspot.01/webrev/ It's not clear in this code if there other concurrent dependent read/writes. Is true that only when reading/writing _state and _stack_traversal_mark proper memory ordering is needed? To track that I created: https://bugs.openjdk.java.net/browse/JDK-8186839 Thanks Robbin From shafi.s.ahmad at oracle.com Tue Aug 29 10:53:12 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Tue, 29 Aug 2017 03:53:12 -0700 (PDT) Subject: [8u] RFR for backport of JDK-8148786: xml.transform fails on x86-64 Message-ID: <3f7c2def-477d-440f-b4af-4f52648d0ee3@default> Hi, Please review the backport of bug: "JDK-8148786: xml.transform fails on x86-64" to jdk8u-dev Please note that this is not a clean backport due to conflict in src/share/vm/opto/loopnode.hpp Webrev: http://cr.openjdk.java.net/~shshahma/8148786/webrev.00/ Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8148786 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/db7934bcad3b Test: Run jprt -testset hotspot Regards, Shafi From tobias.hartmann at oracle.com Tue Aug 29 11:37:46 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 29 Aug 2017 13:37:46 +0200 Subject: [8u] RFR for backport of JDK-8148786: xml.transform fails on x86-64 In-Reply-To: <3f7c2def-477d-440f-b4af-4f52648d0ee3@default> References: <3f7c2def-477d-440f-b4af-4f52648d0ee3@default> Message-ID: Hi Shafi, as we've discussed off-thread, this looks good to me! For the record: This backport is necessary to fix JDK-8181921 [1] in 8u. Best regards, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8181921 On 29.08.2017 12:53, Shafi Ahmad wrote: > Hi, > > Please review the backport of bug: "JDK-8148786: xml.transform fails on x86-64" to jdk8u-dev > Please note that this is not a clean backport due to conflict in src/share/vm/opto/loopnode.hpp > > Webrev: http://cr.openjdk.java.net/~shshahma/8148786/webrev.00/ > Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8148786 > Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/db7934bcad3b > > Test: Run jprt -testset hotspot > > Regards, > Shafi > From david.holmes at oracle.com Tue Aug 29 12:35:42 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Aug 2017 22:35:42 +1000 Subject: RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark In-Reply-To: <9fc2a70d-70bb-362b-16dd-6b5eaf018991@oracle.com> References: <9fc2a70d-70bb-362b-16dd-6b5eaf018991@oracle.com> Message-ID: <3cfddca1-12d8-eef4-1bfe-f6a8b9059634@oracle.com> Hi Robbin, On 29/08/2017 8:31 PM, Robbin Ehn wrote: > Hi please review, > > The issue 8180932 - "Parallelize safepoint cleanup" changed > _stack_traversal_mark to load acquire/store release, this is at least > half wrong. > Instead for simplicity the write side storestore fence should be match > with loadload on read side and the changes to _stack_traversal_mark > undone (kept it volatile). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8186837 > > Code: > http://cr.openjdk.java.net/~rehn/8186837/hotspot.01/webrev/ This seems okay to me. > It's not clear in this code if there other concurrent dependent > read/writes. > Is true that only when reading/writing _state and _stack_traversal_mark > proper memory ordering is needed? > To track that I created: https://bugs.openjdk.java.net/browse/JDK-8186839 Okay. We need to understand how concurrent lock-free accesses can occur to ensure we have the right ordering constraints in place. Thanks, David > Thanks Robbin From robbin.ehn at oracle.com Tue Aug 29 12:44:23 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 29 Aug 2017 14:44:23 +0200 Subject: RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark In-Reply-To: <3cfddca1-12d8-eef4-1bfe-f6a8b9059634@oracle.com> References: <9fc2a70d-70bb-362b-16dd-6b5eaf018991@oracle.com> <3cfddca1-12d8-eef4-1bfe-f6a8b9059634@oracle.com> Message-ID: Thanks David! /Robbin On 08/29/2017 02:35 PM, David Holmes wrote: > Hi Robbin, > > On 29/08/2017 8:31 PM, Robbin Ehn wrote: >> Hi please review, >> >> The issue 8180932 - "Parallelize safepoint cleanup" changed _stack_traversal_mark to load acquire/store release, this is at least half wrong. >> Instead for simplicity the write side storestore fence should be match with loadload on read side and the changes to _stack_traversal_mark undone (kept it volatile). >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8186837 >> >> Code: >> http://cr.openjdk.java.net/~rehn/8186837/hotspot.01/webrev/ > > This seems okay to me. > >> It's not clear in this code if there other concurrent dependent read/writes. >> Is true that only when reading/writing _state and _stack_traversal_mark proper memory ordering is needed? >> To track that I created: https://bugs.openjdk.java.net/browse/JDK-8186839 > > Okay. We need to understand how concurrent lock-free accesses can occur to ensure we have the right ordering constraints in place. > > Thanks, > David > >> Thanks Robbin From rkennke at redhat.com Tue Aug 29 13:00:22 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 29 Aug 2017 15:00:22 +0200 Subject: RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark In-Reply-To: <9fc2a70d-70bb-362b-16dd-6b5eaf018991@oracle.com> References: <9fc2a70d-70bb-362b-16dd-6b5eaf018991@oracle.com> Message-ID: Hi Robin, I doubt that we can assume a symmetry between loadload and storestore like there is with load-acquire and release-store. This doesn't seem right. In my experience loadload and storestore are rather special purpose: loadload ensures ordering between otherwise unrelated loads and storestore likewise with stores. And even symmetric use of load-acquire and release-store are often done wrong: those are not meant to protect concurrent access to the field, but to the stuff that is protected by the field access (think locks), I.e. what happens between the LA and RS. At least that is my understanding. I suggest to do what David said and try to understand what concurrent accesses to which fields we have, and which fences are actually needed to ensure correct ordering. And thanks for revisiting this! Cheers, Roman Am 29. August 2017 12:31:17 MESZ schrieb Robbin Ehn : >Hi please review, > >The issue 8180932 - "Parallelize safepoint cleanup" changed >_stack_traversal_mark to load acquire/store release, this is at least >half wrong. >Instead for simplicity the write side storestore fence should be match >with loadload on read side and the changes to _stack_traversal_mark >undone (kept it volatile). > >Bug: >https://bugs.openjdk.java.net/browse/JDK-8186837 > >Code: >http://cr.openjdk.java.net/~rehn/8186837/hotspot.01/webrev/ > >It's not clear in this code if there other concurrent dependent >read/writes. >Is true that only when reading/writing _state and _stack_traversal_mark >proper memory ordering is needed? >To track that I created: >https://bugs.openjdk.java.net/browse/JDK-8186839 > >Thanks Robbin -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Tue Aug 29 14:50:03 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 29 Aug 2017 16:50:03 +0200 Subject: RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark In-Reply-To: References: <9fc2a70d-70bb-362b-16dd-6b5eaf018991@oracle.com> Message-ID: <6b4e31ae-8c3c-92f7-8743-75f6791cae0d@oracle.com> Hi Roman thanks for having a look, On 08/29/2017 03:00 PM, Roman Kennke wrote: > Hi Robin, > > I doubt that we can assume a symmetry between loadload and storestore like there is with load-acquire and release-store. This doesn't seem right. In my experience loadload > and storestore are rather special purpose: loadload ensures ordering between otherwise unrelated loads and storestore likewise with stores. This exactly why I add loadload, to stop reordering of unrelated loads: ####################### The original code did: //nmethod::make_not_entrant_or_zombie store _stack_traversal_mark storestore store _state //NMethodSweeper::process_compiled_method load _state load _stack_traversal_mark // this is a none-volatile load, can be reordered by both gcc and hardware ####################### Adding la/sr + volatile to _stack_traversal_mark: store _stack_traversal_mark release // release not needed, we have a following storestore for the unrelated stores storestore store _state load _state load _stack_traversal_mark acquire // acquire not needed since we already loaded _state and any following writes/reads will be done after we have taken a Mutex. ####################### So therefore my conclusion was that, in this particular case: store _stack_traversal_mark storestore store _state load _state loadload load _stack_traversal_mark would be correct, agree? And as I said I have created another jira issue for the concerns me, you and David share. Thanks Robbin > > And even symmetric use of load-acquire and release-store are often done wrong: those are not meant to protect concurrent access to the field, but to the stuff that is > protected by the field access (think locks), I.e. what happens between the LA and RS. At least that is my understanding. > > I suggest to do what David said and try to understand what concurrent accesses to which fields we have, and which fences are actually needed to ensure correct ordering. > > And thanks for revisiting this! > > Cheers, Roman > > Am 29. August 2017 12:31:17 MESZ schrieb Robbin Ehn : > > Hi please review, > > The issue 8180932 - "Parallelize safepoint cleanup" changed _stack_traversal_mark to load acquire/store release, this is at least half wrong. > Instead for simplicity the write side storestore fence should be match with loadload on read side and the changes to _stack_traversal_mark undone (kept it volatile). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8186837 > > Code: > http://cr.openjdk.java.net/~rehn/8186837/hotspot.01/webrev/ > > It's not clear in this code if there other concurrent dependent read/writes. > Is true that only when reading/writing _state and _stack_traversal_mark proper memory ordering is needed? > To track that I created:https://bugs.openjdk.java.net/browse/JDK-8186839 > > Thanks Robbin > > > -- > Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From vladimir.kozlov at oracle.com Tue Aug 29 15:17:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Aug 2017 08:17:50 -0700 Subject: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build In-Reply-To: <78736623-e167-6105-0bad-16f70e95adac@oracle.com> References: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> <78736623-e167-6105-0bad-16f70e95adac@oracle.com> Message-ID: <175b48c4-370e-5dcd-e985-286bc128f545@oracle.com> Thank you, Erik Vladimir On 8/29/17 12:14 AM, Erik Joelsson wrote: > Looks good to me. > > /Erik > > > On 2017-08-28 22:18, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8186462/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8186462 >> >> We are planning to have Graal as experimental JIT compiler on linux-x64 in next release. For that we should enable its >> build independent from AOT build. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Tue Aug 29 15:50:55 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Aug 2017 08:50:55 -0700 Subject: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build In-Reply-To: References: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> Message-ID: On 8/29/17 12:30 AM, Lennart B?rjeson wrote: > Could we, please, get this on OSX/MacOS, too? Unfortunately we can not do that. We have very tight schedule for next release and we are doing only linux-x64 testing now due to most resources are used for JDK 9 final testing. Regards, Vladimir > > (For now, I enabling it in my own builds, but it would be nice to have it in the release builds.) > > Best regards, > > /Lennart > >> 28 aug. 2017 kl. 22:18 skrev Vladimir Kozlov : >> >> http://cr.openjdk.java.net/~kvn/8186462/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8186462 >> >> We are planning to have Graal as experimental JIT compiler on linux-x64 in next release. For that we should enable its build independent from AOT build. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Tue Aug 29 16:10:09 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Aug 2017 09:10:09 -0700 Subject: [8u] RFR for backport of JDK-8148786: xml.transform fails on x86-64 In-Reply-To: References: <3f7c2def-477d-440f-b4af-4f52648d0ee3@default> Message-ID: Good to me too. Thanks, Vladimir On 8/29/17 4:37 AM, Tobias Hartmann wrote: > Hi Shafi, > > as we've discussed off-thread, this looks good to me! > > For the record: This backport is necessary to fix JDK-8181921 [1] in 8u. > > Best regards, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8181921 > > On 29.08.2017 12:53, Shafi Ahmad wrote: >> Hi, >> Please review the backport of bug: "JDK-8148786: xml.transform fails on x86-64" to jdk8u-dev >> Please note that this is not a clean backport due to conflict in src/share/vm/opto/loopnode.hpp >> >> Webrev: http://cr.openjdk.java.net/~shshahma/8148786/webrev.00/ >> Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8148786 >> Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/db7934bcad3b >> >> Test: Run jprt -testset hotspot >> >> Regards, >> Shafi >> From vladimir.kozlov at oracle.com Tue Aug 29 16:43:34 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Aug 2017 09:43:34 -0700 Subject: JDK10/RFR(L): 8167199: Add C2 SPARC intrinsic for BigInteger::multiplyToLen() method. In-Reply-To: References: Message-ID: <6c567ae4-6061-0300-5c86-af3d7ff3249c@oracle.com> On 8/29/17 2:22 AM, Nils Eliasson wrote: > Hi Patric, > > Looks good. +1 > > Just make sure this code path is covered in the regular testing. There are jtreg multiplytolen tests. Make sure they run on SPARC. You can also run jvm2008 crypto sub-benchmarks. Thanks, Vladimir > > Regards, > > Nils > > > On 2017-08-28 15:06, Patric Hedlin wrote: >> Dear all, >> >> I would like to ask for help to review the following change/update: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8167199 >> >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8167199/ >> >> >> 8167199: Add C2 SPARC intrinsic for BigInteger::multiplyToLen() method. >> >> Added C2 SPARC support for intrinsic 'multiplyToLen', including >> generalised version based on 'mpmul' instruction (when available). >> The code emitted should be subject for evaluation (e.g. MME on >> SPARC Core C5 might be used in an improved version). >> >> Testing: >> >> Mostly tested on JDK9 (jtreg/RBT/hotspot/tier0-comp). >> Testing on JDK10 (jtreg/RBT/hotspot/precheckin-comp). >> >> >> Best regards, >> Patric > From gustavo.scalet at eldorado.org.br Tue Aug 29 20:36:34 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Tue, 29 Aug 2017 20:36:34 +0000 Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics In-Reply-To: <4ec93a6bcbe14cf99c2fa02d50a18965@sap.com> References: <1f159ee480284095b8e5c3f444dceb96@serv031.corp.eldorado.org.br> <16e8b68451e94eb79cdd7d9cb5d7984c@sap.com> <2425566a8ff74051af485c919a0bf5ee@serv030.corp.eldorado.org.br> <4ec93a6bcbe14cf99c2fa02d50a18965@sap.com> Message-ID: Hi Martin, New changes: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.02/ Check comments below, please. > -----Original Message----- > From: Doerr, Martin > > 1. Sign extending offset and len > Right, sign and zero extending is equivalent for offset and len because > they are guaranteed to be >=0 (by checks in Java). But you can only rely > on bit 32 (IBM notation) to be 0. Bit 0-31 may contain garbage. > rldicl was incorrect. My mistake, sorry for that. Correct would be rldic > which also clears the least significant bits. > len should also get fixed e.g. by replacing cmpdi by extsw_ in muladd. The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem to need further changes as it's being cleared with clrldi, which is the same as rldic with no shift. Therefore it's treated appropriately as requested for "offset" parameter. Do you agree? > 2. Using 8 byte instructions for int > The code which feeds stdu is endianess specific. Doesn't work on all > PPC64 platforms. You are right. The way I'm building the 64 bits of the register depends on which kind of endianness it is run. For now it works only on little endian so I'm adding a switch (just like I did for SHA) to make it available only on little endian systems. > 3.Regarding Andrew's point: Superseded by Montgomery? > The Montgomery change got backported to jdk8u (JDK-8150152 in 8u102). > I'd expect the performance improvement of these intrinsics to be > irrelevant for crypto.rsa. Did you measure with an older jdk8 release? No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 14:15:31 2017). The reported performance speedup was calculated by running the following test (TestSquareToLen.java): import java.math.BigInteger; public class TestSquareToLen { public static void main(String args[]) throws Exception { int n = 10000000; if (args.length >=1) { n = Integer.parseInt(args[0]); } BigInteger b1 = new BigInteger("348939809235573590863505149820825039200022983118773208599936739559418380102146884307139175604920787313701663155983793121475492609222378029211020760922327218480828933663005773596942372680852064103011811651644018048833823482390819947896524207635857984552089977996313113154016668718795349783157384006672542605760392289645528307"); BigInteger b2 = BigInteger.valueOf(0); BigInteger check = BigInteger.valueOf(1); for (int i = 0; i < n; i++) { b2 = b1.multiply(b1); if (i == 0) // Didn't JIT yet. Comparing against interpreted mode check = b2; } if (b2.compareTo(check) == 0) System.out.println("Check ok!"); else System.out.println("Check failed!"); } } I got these results on JDK8 on my POWER8 machine: $ ./javac TestSquareToLen.java $ sudo perf stat -r 5 ./java -XX:-UseMulAddIntrinsic -XX:-UseSquareToLenIntrinsic TestSquareToLen Check ok! Check ok! Check ok! Check ok! Check ok! Performance counter stats for './java -XX:-UseMulAddIntrinsic -XX:-UseSquareToLenIntrinsic TestSquareToLen' (5 runs): 15148.009557 task-clock (msec) # 1.053 CPUs utilized ( +- 0.48% ) 2,425 context-switches # 0.160 K/sec ( +- 5.84% ) 356 cpu-migrations # 0.023 K/sec ( +- 3.01% ) 5,153 page-faults # 0.340 K/sec ( +- 5.22% ) 54,536,889,909 cycles # 3.600 GHz ( +- 0.56% ) (66.68%) 239,554,105 stalled-cycles-frontend # 0.44% frontend cycles idle ( +- 4.87% ) (49.90%) 27,683,316,001 stalled-cycles-backend # 50.76% backend cycles idle ( +- 0.56% ) (50.17%) 102,020,229,733 instructions # 1.87 insn per cycle # 0.27 stalled cycles per insn ( +- 0.14% ) (66.94%) 7,706,072,218 branches # 508.718 M/sec ( +- 0.23% ) (50.20%) 456,051,162 branch-misses # 5.92% of all branches ( +- 0.09% ) (50.07%) 14.390840733 seconds time elapsed ( +- 0.09% ) $ sudo perf stat -r 5 ./java -XX:+UseMulAddIntrinsic -XX:+UseSquareToLenIntrinsic TestSquareToLen Check ok! Check ok! Check ok! Check ok! Check ok! Performance counter stats for './java -XX:+UseMulAddIntrinsic -XX:+UseSquareToLenIntrinsic TestSquareToLen' (5 runs): 11368.141410 task-clock (msec) # 1.045 CPUs utilized ( +- 0.64% ) 1,964 context-switches # 0.173 K/sec ( +- 8.93% ) 338 cpu-migrations # 0.030 K/sec ( +- 7.65% ) 5,627 page-faults # 0.495 K/sec ( +- 6.15% ) 41,100,168,967 cycles # 3.615 GHz ( +- 0.50% ) (66.36%) 309,052,316 stalled-cycles-frontend # 0.75% frontend cycles idle ( +- 2.84% ) (49.89%) 14,188,581,685 stalled-cycles-backend # 34.52% backend cycles idle ( +- 0.99% ) (50.34%) 77,846,029,829 instructions # 1.89 insn per cycle # 0.18 stalled cycles per insn ( +- 0.29% ) (66.96%) 8,435,216,989 branches # 742.005 M/sec ( +- 0.28% ) (50.17%) 339,903,936 branch-misses # 4.03% of all branches ( +- 0.27% ) (49.90%) 10.882357546 seconds time elapsed ( +- 0.24% ) (out of curiosity, these numbers are 15.19s (+- 0.32%) and 13.42s (+- 0.53%) on JDK10) I may run for SpecJVM2008's crypto.rsa if you are interested. Thank you once again for reviewing this. Best regards, Gustavo > (I think the change is still acceptable as the intrinsics could be used > elsewhere and the implementation also exists on other platforms.) > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Mittwoch, 16. August 2017 18:50 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics > > Hi Martin, > > Thanks for dedicated review. It took me a while to be able to work on > this but I hope to have your points solved. Please check below the > review as well as my comments quoting your email: > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > > > -----Original Message----- > > First of all, C2 does not perform sign extend when calling stubs. The > > int parms need to get zero/sign extended. (Could even be done without > > extra instructions by replacing sldi -> rldicl, cmpdi -> extsw_ in > > some > > cases.) > > Does it make a difference on my case? > > I guess you are talking about mulAdd preparation code. The only aspect I > found about him is to force the cast from 32 bits -> 64 bits by cleaning > higher bits. Offset is a signed integer but it can't be negative anyway. > > So I changed from: > sldi (R5_ARG3, R5_ARG3, 2); > > to: > rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > > > > macroAssembler_ppc.cpp: > > - Indentation should be 2 spaces. > > Done > > > > stubGenerator_ppc:cpp: > > - or_, addi_ should get replaced by orr, addi when CR0 result is not > > needed. > > Done > > > - Where is lplw initialized? > > It should be initialized with 0, I missed that... > > > - I believe that the updating load/store instructions e.g. lwzu don't > > perform well on some processors. At least using stwu 2 times in the > > loop doesn't make sense. > > You are right. I could manipulate the bits differently and ended up with > a single stdu in the loop. Neat! Although I could not reduce the total > number of instructions. > > > - Note: It should be possible to use 8 byte instead of 4 byte > > instructions: MacroAssembler::multiply64, addc, adde. But I'm not > > requesting to change that because I guess it would make the code very > > complicated, especially when supporting both endianess versions. > > Yes, that would require a new analysis on this code. May we consider it > next? As you said, I prefer having an initial version that looks as > simple as the original java code. > > > - The squareToLen stub implementation is very close the Java > > implementation. So it'd be interesting to understand what C2 doesn't > > do as well as the hand written assembly code. Do you know that? (Not > > absolutely necessary for accepting this change as long as the stub is > > measurably faster.) > > I don't know either. Basically I chose doing it because I noticed some > performance gain on SpecJVM2008 when analyzing X64. Then, taking a > closer look, I didn't notice any AVX or some special instructions on X64 > so I decided to try it on ppc64 by using some basic assembly. > > Thanks > > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Donnerstag, 10. August 2017 19:22 > > To: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > SquareToLen intrinsics > > > > > > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > > To: ppc-aix-port-dev at openjdk.java.net > > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen > > intrinsics > > > > Hi, > > > > Could you please review this specific PPC64 change to hotspot? By > > implementing these intrinsics I noticed a small improvement with > > microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, only > > when backporting to JDK8 an improvement was noticed. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > > > Motivation for this implementation: > > https://twitter.com/ijuma/status/698309312498835457 > > > > Best regards, > > Gustavo Serra Scalet From shafi.s.ahmad at oracle.com Wed Aug 30 10:52:23 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 30 Aug 2017 03:52:23 -0700 (PDT) Subject: [8u] RFR for backport of JDK-8148786: xml.transform fails on x86-64 In-Reply-To: References: <3f7c2def-477d-440f-b4af-4f52648d0ee3@default> Message-ID: <2ac20c30-9a2d-4ec1-b98f-490b3f6d907e@default> Thank you Vladimir and Tobias for the review. Regards, Shafi > -----Original Message----- > From: Vladimir Kozlov > Sent: Tuesday, August 29, 2017 9:40 PM > To: Tobias Hartmann ; Shafi Ahmad > ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: [8u] RFR for backport of JDK-8148786: xml.transform fails on x86- > 64 > > Good to me too. > > Thanks, > Vladimir > > On 8/29/17 4:37 AM, Tobias Hartmann wrote: > > Hi Shafi, > > > > as we've discussed off-thread, this looks good to me! > > > > For the record: This backport is necessary to fix JDK-8181921 [1] in 8u. > > > > Best regards, > > Tobias > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8181921 > > > > On 29.08.2017 12:53, Shafi Ahmad wrote: > >> Hi, > >> Please review the backport of bug: "JDK-8148786: xml.transform fails > >> on x86-64" to jdk8u-dev Please note that this is not a clean backport > >> due to conflict in src/share/vm/opto/loopnode.hpp > >> > >> Webrev: http://cr.openjdk.java.net/~shshahma/8148786/webrev.00/ > >> Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8148786 > >> Original patch pushed to jdk9: > >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/db7934bcad3b > >> > >> Test: Run jprt -testset hotspot > >> > >> Regards, > >> Shafi > >> From rkennke at redhat.com Wed Aug 30 10:14:02 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 30 Aug 2017 12:14:02 +0200 Subject: RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark In-Reply-To: <6b4e31ae-8c3c-92f7-8743-75f6791cae0d@oracle.com> References: <9fc2a70d-70bb-362b-16dd-6b5eaf018991@oracle.com> <6b4e31ae-8c3c-92f7-8743-75f6791cae0d@oracle.com> Message-ID: <9480F78C-F0FB-4F26-B272-E7522B8A92F5@redhat.com> It sounds to me like LA/RL would be required and sufficient on _state ? Roman Am 29. August 2017 16:50:03 MESZ schrieb Robbin Ehn : >Hi Roman thanks for having a look, > >On 08/29/2017 03:00 PM, Roman Kennke wrote: >> Hi Robin, >> >> I doubt that we can assume a symmetry between loadload and storestore >like there is with load-acquire and release-store. This doesn't seem >right. In my experience loadload >> and storestore are rather special purpose: loadload ensures ordering >between otherwise unrelated loads and storestore likewise with stores. > >This exactly why I add loadload, to stop reordering of unrelated loads: > >####################### >The original code did: > >//nmethod::make_not_entrant_or_zombie >store _stack_traversal_mark >storestore >store _state > >//NMethodSweeper::process_compiled_method >load _state >load _stack_traversal_mark // this is a none-volatile load, can be >reordered by both gcc and hardware > >####################### >Adding la/sr + volatile to _stack_traversal_mark: > >store _stack_traversal_mark release // release not needed, we have a >following storestore for the unrelated stores >storestore >store _state > >load _state >load _stack_traversal_mark acquire // acquire not needed since we >already loaded _state and any following writes/reads will be done after >we have taken a Mutex. > >####################### >So therefore my conclusion was that, in this particular case: > >store _stack_traversal_mark >storestore >store _state > >load _state >loadload >load _stack_traversal_mark > >would be correct, agree? > >And as I said I have created another jira issue for the concerns me, >you and David share. > >Thanks Robbin > >> >> And even symmetric use of load-acquire and release-store are often >done wrong: those are not meant to protect concurrent access to the >field, but to the stuff that is >> protected by the field access (think locks), I.e. what happens >between the LA and RS. At least that is my understanding. >> >> I suggest to do what David said and try to understand what concurrent >accesses to which fields we have, and which fences are actually needed >to ensure correct ordering. >> >> And thanks for revisiting this! >> >> Cheers, Roman >> >> Am 29. August 2017 12:31:17 MESZ schrieb Robbin Ehn >: >> >> Hi please review, >> >> The issue 8180932 - "Parallelize safepoint cleanup" changed >_stack_traversal_mark to load acquire/store release, this is at least >half wrong. >> Instead for simplicity the write side storestore fence should be >match with loadload on read side and the changes to >_stack_traversal_mark undone (kept it volatile). >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8186837 >> >> Code: >> http://cr.openjdk.java.net/~rehn/8186837/hotspot.01/webrev/ >> >> It's not clear in this code if there other concurrent dependent >read/writes. >> Is true that only when reading/writing _state and >_stack_traversal_mark proper memory ordering is needed? >> To track that I >created:https://bugs.openjdk.java.net/browse/JDK-8186839 >> >> Thanks Robbin >> >> >> -- >> Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Wed Aug 30 14:37:11 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 30 Aug 2017 14:37:11 +0000 Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics In-Reply-To: References: <1f159ee480284095b8e5c3f444dceb96@serv031.corp.eldorado.org.br> <16e8b68451e94eb79cdd7d9cb5d7984c@sap.com> <2425566a8ff74051af485c919a0bf5ee@serv030.corp.eldorado.org.br> <4ec93a6bcbe14cf99c2fa02d50a18965@sap.com> Message-ID: <0ef23b5fcbc54996aea876d4c60e4097@sap.com> Hi Gustavo, > The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem to need further changes as it's being cleared with clrldi, which is the > same as rldic with no shift. Therefore it's treated appropriately as requested for "offset" parameter. Do you agree? No, I didn't find clrldi for len in generate_mulAdd(). Only for k. Where are in_len and out_len fixed up in generate_squareToLen()? > You are right. The way I'm building the 64 bits of the register depends on which kind of endianness it is run. For now it works only on > little endian so I'm adding a switch (just like I did for SHA) to make it available only on little endian systems. It shouldn't be that hard to get it working on big endian ;-) Btw., my point was not to replace the 2 4-byte store instructions by an 8-byte one (though I'm also ok with that). It was that 2 stwu which update the same pointer doesn't make sense from performance point of view. Please keep something which works on big endian, too. > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 14:15:31 2017). The reported performance speedup was calculated by > running the following test (TestSquareToLen.java): Seems like JDK-8145913 has not been backported, yet. Sorry for not checking this earlier. So if you want to make RSA really fast, it should be so much better to backport that one. But I can still sponsor this change as it may be used elsewhere. Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Dienstag, 29. August 2017 22:37 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics Hi Martin, New changes: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.02/ Check comments below, please. > -----Original Message----- > From: Doerr, Martin > > 1. Sign extending offset and len > Right, sign and zero extending is equivalent for offset and len because > they are guaranteed to be >=0 (by checks in Java). But you can only rely > on bit 32 (IBM notation) to be 0. Bit 0-31 may contain garbage. > rldicl was incorrect. My mistake, sorry for that. Correct would be rldic > which also clears the least significant bits. > len should also get fixed e.g. by replacing cmpdi by extsw_ in muladd. The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem to need further changes as it's being cleared with clrldi, which is the same as rldic with no shift. Therefore it's treated appropriately as requested for "offset" parameter. Do you agree? > 2. Using 8 byte instructions for int > The code which feeds stdu is endianess specific. Doesn't work on all > PPC64 platforms. You are right. The way I'm building the 64 bits of the register depends on which kind of endianness it is run. For now it works only on little endian so I'm adding a switch (just like I did for SHA) to make it available only on little endian systems. > 3.Regarding Andrew's point: Superseded by Montgomery? > The Montgomery change got backported to jdk8u (JDK-8150152 in 8u102). > I'd expect the performance improvement of these intrinsics to be > irrelevant for crypto.rsa. Did you measure with an older jdk8 release? No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 14:15:31 2017). The reported performance speedup was calculated by running the following test (TestSquareToLen.java): import java.math.BigInteger; public class TestSquareToLen { public static void main(String args[]) throws Exception { int n = 10000000; if (args.length >=1) { n = Integer.parseInt(args[0]); } BigInteger b1 = new BigInteger("348939809235573590863505149820825039200022983118773208599936739559418380102146884307139175604920787313701663155983793121475492609222378029211020760922327218480828933663005773596942372680852064103011811651644018048833823482390819947896524207635857984552089977996313113154016668718795349783157384006672542605760392289645528307"); BigInteger b2 = BigInteger.valueOf(0); BigInteger check = BigInteger.valueOf(1); for (int i = 0; i < n; i++) { b2 = b1.multiply(b1); if (i == 0) // Didn't JIT yet. Comparing against interpreted mode check = b2; } if (b2.compareTo(check) == 0) System.out.println("Check ok!"); else System.out.println("Check failed!"); } } I got these results on JDK8 on my POWER8 machine: $ ./javac TestSquareToLen.java $ sudo perf stat -r 5 ./java -XX:-UseMulAddIntrinsic -XX:-UseSquareToLenIntrinsic TestSquareToLen Check ok! Check ok! Check ok! Check ok! Check ok! Performance counter stats for './java -XX:-UseMulAddIntrinsic -XX:-UseSquareToLenIntrinsic TestSquareToLen' (5 runs): 15148.009557 task-clock (msec) # 1.053 CPUs utilized ( +- 0.48% ) 2,425 context-switches # 0.160 K/sec ( +- 5.84% ) 356 cpu-migrations # 0.023 K/sec ( +- 3.01% ) 5,153 page-faults # 0.340 K/sec ( +- 5.22% ) 54,536,889,909 cycles # 3.600 GHz ( +- 0.56% ) (66.68%) 239,554,105 stalled-cycles-frontend # 0.44% frontend cycles idle ( +- 4.87% ) (49.90%) 27,683,316,001 stalled-cycles-backend # 50.76% backend cycles idle ( +- 0.56% ) (50.17%) 102,020,229,733 instructions # 1.87 insn per cycle # 0.27 stalled cycles per insn ( +- 0.14% ) (66.94%) 7,706,072,218 branches # 508.718 M/sec ( +- 0.23% ) (50.20%) 456,051,162 branch-misses # 5.92% of all branches ( +- 0.09% ) (50.07%) 14.390840733 seconds time elapsed ( +- 0.09% ) $ sudo perf stat -r 5 ./java -XX:+UseMulAddIntrinsic -XX:+UseSquareToLenIntrinsic TestSquareToLen Check ok! Check ok! Check ok! Check ok! Check ok! Performance counter stats for './java -XX:+UseMulAddIntrinsic -XX:+UseSquareToLenIntrinsic TestSquareToLen' (5 runs): 11368.141410 task-clock (msec) # 1.045 CPUs utilized ( +- 0.64% ) 1,964 context-switches # 0.173 K/sec ( +- 8.93% ) 338 cpu-migrations # 0.030 K/sec ( +- 7.65% ) 5,627 page-faults # 0.495 K/sec ( +- 6.15% ) 41,100,168,967 cycles # 3.615 GHz ( +- 0.50% ) (66.36%) 309,052,316 stalled-cycles-frontend # 0.75% frontend cycles idle ( +- 2.84% ) (49.89%) 14,188,581,685 stalled-cycles-backend # 34.52% backend cycles idle ( +- 0.99% ) (50.34%) 77,846,029,829 instructions # 1.89 insn per cycle # 0.18 stalled cycles per insn ( +- 0.29% ) (66.96%) 8,435,216,989 branches # 742.005 M/sec ( +- 0.28% ) (50.17%) 339,903,936 branch-misses # 4.03% of all branches ( +- 0.27% ) (49.90%) 10.882357546 seconds time elapsed ( +- 0.24% ) (out of curiosity, these numbers are 15.19s (+- 0.32%) and 13.42s (+- 0.53%) on JDK10) I may run for SpecJVM2008's crypto.rsa if you are interested. Thank you once again for reviewing this. Best regards, Gustavo > (I think the change is still acceptable as the intrinsics could be used > elsewhere and the implementation also exists on other platforms.) > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Mittwoch, 16. August 2017 18:50 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics > > Hi Martin, > > Thanks for dedicated review. It took me a while to be able to work on > this but I hope to have your points solved. Please check below the > review as well as my comments quoting your email: > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > > > -----Original Message----- > > First of all, C2 does not perform sign extend when calling stubs. The > > int parms need to get zero/sign extended. (Could even be done without > > extra instructions by replacing sldi -> rldicl, cmpdi -> extsw_ in > > some > > cases.) > > Does it make a difference on my case? > > I guess you are talking about mulAdd preparation code. The only aspect I > found about him is to force the cast from 32 bits -> 64 bits by cleaning > higher bits. Offset is a signed integer but it can't be negative anyway. > > So I changed from: > sldi (R5_ARG3, R5_ARG3, 2); > > to: > rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > > > > macroAssembler_ppc.cpp: > > - Indentation should be 2 spaces. > > Done > > > > stubGenerator_ppc:cpp: > > - or_, addi_ should get replaced by orr, addi when CR0 result is not > > needed. > > Done > > > - Where is lplw initialized? > > It should be initialized with 0, I missed that... > > > - I believe that the updating load/store instructions e.g. lwzu don't > > perform well on some processors. At least using stwu 2 times in the > > loop doesn't make sense. > > You are right. I could manipulate the bits differently and ended up with > a single stdu in the loop. Neat! Although I could not reduce the total > number of instructions. > > > - Note: It should be possible to use 8 byte instead of 4 byte > > instructions: MacroAssembler::multiply64, addc, adde. But I'm not > > requesting to change that because I guess it would make the code very > > complicated, especially when supporting both endianess versions. > > Yes, that would require a new analysis on this code. May we consider it > next? As you said, I prefer having an initial version that looks as > simple as the original java code. > > > - The squareToLen stub implementation is very close the Java > > implementation. So it'd be interesting to understand what C2 doesn't > > do as well as the hand written assembly code. Do you know that? (Not > > absolutely necessary for accepting this change as long as the stub is > > measurably faster.) > > I don't know either. Basically I chose doing it because I noticed some > performance gain on SpecJVM2008 when analyzing X64. Then, taking a > closer look, I didn't notice any AVX or some special instructions on X64 > so I decided to try it on ppc64 by using some basic assembly. > > Thanks > > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: Donnerstag, 10. August 2017 19:22 > > To: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > SquareToLen intrinsics > > > > > > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > > To: ppc-aix-port-dev at openjdk.java.net > > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen > > intrinsics > > > > Hi, > > > > Could you please review this specific PPC64 change to hotspot? By > > implementing these intrinsics I noticed a small improvement with > > microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, only > > when backporting to JDK8 an improvement was noticed. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > > > Motivation for this implementation: > > https://twitter.com/ijuma/status/698309312498835457 > > > > Best regards, > > Gustavo Serra Scalet From robbin.ehn at oracle.com Wed Aug 30 14:50:26 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 30 Aug 2017 16:50:26 +0200 Subject: RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark In-Reply-To: <9480F78C-F0FB-4F26-B272-E7522B8A92F5@redhat.com> References: <9fc2a70d-70bb-362b-16dd-6b5eaf018991@oracle.com> <6b4e31ae-8c3c-92f7-8743-75f6791cae0d@oracle.com> <9480F78C-F0FB-4F26-B272-E7522B8A92F5@redhat.com> Message-ID: Hi Roman, On 08/30/2017 12:14 PM, Roman Kennke wrote: > It sounds to me like LA/RL would be required and sufficient on _state ? Yes, but - Using la/rs just sometimes can be confusing, changing to get/set with la/rs semantics also means we need to change assembly to use proper memory ordering, e.g. lda instead of ldr on aarch64 and armv7 add e.g. ldr, dmb, etc... (I asked compiler, their thoughts was dirty reads are most likely okay in all other cases since _state only goes 'up') - Using la/rs in just this case means either duplicate methods with acquire semantic or adding a bool to a lot of methods since these are accessed in deep call hierarchies. - The write side is using storestore today For those reasons I said: > Instead for simplicity the write side storestore fence should be match with loadload on read side and the changes to _stack_traversal_mark undone (kept it volatile). I'm well aware this no near perfect, but we need that loadload fence, so can you can live with my proposed change? And we can discussed the bigger picture in 8186839? Thanks, Robbin > > Roman > > Am 29. August 2017 16:50:03 MESZ schrieb Robbin Ehn : > > Hi Roman thanks for having a look, > > On 08/29/2017 03:00 PM, Roman Kennke wrote: > > Hi Robin, > > I doubt that we can assume a symmetry between loadload and storestore like there is with load-acquire and release-store. This doesn't seem right. In my experience > loadload > and storestore are rather special purpose: loadload ensures ordering between otherwise unrelated loads and storestore likewise with stores. > > > This exactly why I add loadload, to stop reordering of unrelated loads: > > ####################### > The original code did: > > //nmethod::make_not_entrant_or_zombie > store _stack_traversal_mark > storestore > store _state > > //NMethodSweeper::process_compiled_method > load _state > load _stack_traversal_mark // this is a none-volatile load, can be reordered by both gcc and hardware > > ####################### > Adding la/sr + volatile to _stack_traversal_mark: > > store _stack_traversal_mark release // release not needed, we have a following storestore for the unrelated stores > storestore > store _state > > load _state > load _stack_traversal_mark acquire // acquire not needed since we already loaded _state and any following writes/reads will be done after we have taken a Mutex. > > ####################### > So therefore my conclusion was that, in this particular case: > > store _stack_traversal_mark > storestore > store _state > > load _state > loadload > load _stack_traversal_mark > > would be correct, agree? > > And as I said I have created another jira issue for the concerns me, you and David share. > > Thanks Robbin > > > And even symmetric use of load-acquire and release-store are often done wrong: those are not meant to protect concurrent access to the field, but to the stuff that is > protected by the field access (think locks), I.e. what happens between the LA and RS. At least that is my understanding. > > I suggest to do what David said and try to understand what concurrent accesses to which fields we have, and which fences are actually needed to ensure correct ordering. > > And thanks for revisiting this! > > Cheers, Roman > > Am 29. August 2017 12:31:17 MESZ schrieb Robbin Ehn : > > Hi please review, > > The issue 8180932 - "Parallelize safepoint cleanup" changed _stack_traversal_mark to load acquire/store release, this is at least half wrong. > Instead for simplicity the write side storestore fence should be match with loadload on read side and the changes to _stack_traversal_mark undone (kept it volatile). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8186837 > > Code: > http://cr.openjdk.java.net/~rehn/8186837/hotspot.01/webrev/ > > It's not clear in this code if there other concurrent dependent read/writes. > Is true that only when reading/writing _state and _stack_traversal_mark proper memory ordering is needed? > To track that I created:https://bugs.openjdk.java.net/browse/JDK-8186839 > > Thanks Robbin > > > -- > Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. > > > -- > Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From rkennke at redhat.com Wed Aug 30 15:03:43 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 30 Aug 2017 17:03:43 +0200 Subject: RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark In-Reply-To: References: <9fc2a70d-70bb-362b-16dd-6b5eaf018991@oracle.com> <6b4e31ae-8c3c-92f7-8743-75f6791cae0d@oracle.com> <9480F78C-F0FB-4F26-B272-E7522B8A92F5@redhat.com> Message-ID: OK :-) Cheers, Roman Am 30. August 2017 16:50:26 MESZ schrieb Robbin Ehn : >Hi Roman, > >On 08/30/2017 12:14 PM, Roman Kennke wrote: >> It sounds to me like LA/RL would be required and sufficient on _state >? > >Yes, but >- Using la/rs just sometimes can be confusing, changing to get/set with >la/rs semantics also means we need to change assembly to use proper >memory ordering, > e.g. lda instead of ldr on aarch64 and armv7 add e.g. ldr, dmb, etc... >(I asked compiler, their thoughts was dirty reads are most likely okay >in all other cases since _state only goes 'up') >- Using la/rs in just this case means either duplicate methods with >acquire semantic or adding a bool to a lot of methods since these are >accessed in deep call hierarchies. >- The write side is using storestore today > >For those reasons I said: > >> Instead for simplicity the write side storestore fence should be >match with loadload on read side and the changes to >_stack_traversal_mark undone (kept it volatile). > >I'm well aware this no near perfect, but we need that loadload fence, >so can you can live with my proposed change? >And we can discussed the bigger picture in 8186839? > >Thanks, Robbin > >> >> Roman >> >> Am 29. August 2017 16:50:03 MESZ schrieb Robbin Ehn >: >> >> Hi Roman thanks for having a look, >> >> On 08/29/2017 03:00 PM, Roman Kennke wrote: >> >> Hi Robin, >> >> I doubt that we can assume a symmetry between loadload and >storestore like there is with load-acquire and release-store. This >doesn't seem right. In my experience >> loadload >> and storestore are rather special purpose: loadload ensures >ordering between otherwise unrelated loads and storestore likewise with >stores. >> >> >> This exactly why I add loadload, to stop reordering of unrelated >loads: >> >> ####################### >> The original code did: >> >> //nmethod::make_not_entrant_or_zombie >> store _stack_traversal_mark >> storestore >> store _state >> >> //NMethodSweeper::process_compiled_method >> load _state >> load _stack_traversal_mark // this is a none-volatile load, can >be reordered by both gcc and hardware >> >> ####################### >> Adding la/sr + volatile to _stack_traversal_mark: >> >> store _stack_traversal_mark release // release not needed, we >have a following storestore for the unrelated stores >> storestore >> store _state >> >> load _state >> load _stack_traversal_mark acquire // acquire not needed since we >already loaded _state and any following writes/reads will be done after >we have taken a Mutex. >> >> ####################### >> So therefore my conclusion was that, in this particular case: >> >> store _stack_traversal_mark >> storestore >> store _state >> >> load _state >> loadload >> load _stack_traversal_mark >> >> would be correct, agree? >> >> And as I said I have created another jira issue for the concerns >me, you and David share. >> >> Thanks Robbin >> >> >> And even symmetric use of load-acquire and release-store are >often done wrong: those are not meant to protect concurrent access to >the field, but to the stuff that is >> protected by the field access (think locks), I.e. what >happens between the LA and RS. At least that is my understanding. >> >> I suggest to do what David said and try to understand what >concurrent accesses to which fields we have, and which fences are >actually needed to ensure correct ordering. >> >> And thanks for revisiting this! >> >> Cheers, Roman >> >> Am 29. August 2017 12:31:17 MESZ schrieb Robbin Ehn >: >> >> Hi please review, >> >> The issue 8180932 - "Parallelize safepoint cleanup" changed >_stack_traversal_mark to load acquire/store release, this is at least >half wrong. >> Instead for simplicity the write side storestore fence should >be match with loadload on read side and the changes to >_stack_traversal_mark undone (kept it volatile). >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8186837 >> >> Code: >> http://cr.openjdk.java.net/~rehn/8186837/hotspot.01/webrev/ >> >> It's not clear in this code if there other concurrent >dependent read/writes. >> Is true that only when reading/writing _state and >_stack_traversal_mark proper memory ordering is needed? >> To track that I >created:https://bugs.openjdk.java.net/browse/JDK-8186839 >> >> Thanks Robbin >> >> >> -- >> Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail >gesendet. >> >> >> -- >> Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.scalet at eldorado.org.br Wed Aug 30 17:02:54 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Wed, 30 Aug 2017 17:02:54 +0000 Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics In-Reply-To: <0ef23b5fcbc54996aea876d4c60e4097@sap.com> References: <1f159ee480284095b8e5c3f444dceb96@serv031.corp.eldorado.org.br> <16e8b68451e94eb79cdd7d9cb5d7984c@sap.com> <2425566a8ff74051af485c919a0bf5ee@serv030.corp.eldorado.org.br> <4ec93a6bcbe14cf99c2fa02d50a18965@sap.com> <0ef23b5fcbc54996aea876d4c60e4097@sap.com> Message-ID: <10a918efbd344b1fbf95c56b7beedbc0@serv031.corp.eldorado.org.br> Hi Martin, (webrev at the end) > -----Original Message----- > From: Doerr, Martin > > > The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem to > > need further changes as it's being cleared with clrldi, which is the > > same as rldic with no shift. Therefore it's treated appropriately as > > requested for "offset" parameter. Do you agree? > > No, I didn't find clrldi for len in generate_mulAdd(). Only for k. I'm sorry. I was thinking about "offset" and "k", which are both cleaned on generate_mulAdd(). "len" was not cleaned and it was being used on muladd() directly with cmpdi, which could lead to problems. That is being changed. > Where are in_len and out_len fixed up in generate_squareToLen()? They are not. According to your suggestions, I agree it also needs to be done for the same reason. > > You are right. The way I'm building the 64 bits of the register > > depends on which kind of endianness it is run. For now it works only on > > little endian so I'm adding a switch (just like I did for SHA) to make > > it available only on little endian systems. > > It shouldn't be that hard to get it working on big endian ;-) Btw., my > point was not to replace the 2 4-byte store instructions by an 8-byte > one (though I'm also ok with that). It was that 2 stwu which update the > same pointer doesn't make sense from performance point of view. Please > keep something which works on big endian, too. I see. The 2x stwu was being used like that because it was the trivial approach when considering the original java update: z[i++] = (lastProductLowWord << 31) | (int)(product >>> 33); z[i++] = (int)(product >>> 1); As you pointed out, that might cause some stall on the pipeline so I made it with 1s stdu (and could improve code by reducing 1 instruction) Now about having a big endian version: I'm not confident in doing so as I don't have access to such a machine at the moment. You were kind on offering test support but I don't know if it'd work like that. I may support you in checking out which places are endianness-related but I'm not comfortable in sending you untested code. Would you be interested in doing such a changes for making it work on Big Endian? For this patch, I provided an interesting test that might help you to verify if it worked. > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 14:15:31 > > 2017). The reported performance speedup was calculated by running the > > following test (TestSquareToLen.java): > > Seems like JDK-8145913 has not been backported, yet. Sorry for not > checking this earlier. So if you want to make RSA really fast, it should > be so much better to backport that one. But I can still sponsor this > change as it may be used elsewhere. No problem. It's nice to know that I may not need to request a backport of this patch for performance reasons. And at last, but not least, the new webrev with these clrldi changes: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.03/index.html Thank you once again, Gustavo Serra Scalet > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Dienstag, 29. August 2017 22:37 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics > > Hi Martin, > > New changes: > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.02/ > > Check comments below, please. > > > -----Original Message----- > > From: Doerr, Martin > > > > 1. Sign extending offset and len > > Right, sign and zero extending is equivalent for offset and len > > because they are guaranteed to be >=0 (by checks in Java). But you can > > only rely on bit 32 (IBM notation) to be 0. Bit 0-31 may contain > garbage. > > rldicl was incorrect. My mistake, sorry for that. Correct would be > > rldic which also clears the least significant bits. > > len should also get fixed e.g. by replacing cmpdi by extsw_ in muladd. > > The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem to > need further changes as it's being cleared with clrldi, which is the > same as rldic with no shift. Therefore it's treated appropriately as > requested for "offset" parameter. Do you agree? > > > 2. Using 8 byte instructions for int > > The code which feeds stdu is endianess specific. Doesn't work on all > > PPC64 platforms. > > You are right. The way I'm building the 64 bits of the register depends > on which kind of endianness it is run. For now it works only on little > endian so I'm adding a switch (just like I did for SHA) to make it > available only on little endian systems. > > > 3.Regarding Andrew's point: Superseded by Montgomery? > > The Montgomery change got backported to jdk8u (JDK-8150152 in 8u102). > > I'd expect the performance improvement of these intrinsics to be > > irrelevant for crypto.rsa. Did you measure with an older jdk8 release? > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 14:15:31 > 2017). The reported performance speedup was calculated by running the > following test (TestSquareToLen.java): > import java.math.BigInteger; > > public class TestSquareToLen { > > public static void main(String args[]) throws Exception { > > int n = 10000000; > if (args.length >=1) { > n = Integer.parseInt(args[0]); > } > > BigInteger b1 = new > BigInteger("348939809235573590863505149820825039200022983118773208599936 > 739559418380102146884307139175604920787313701663155983793121475492609222 > 378029211020760922327218480828933663005773596942372680852064103011811651 > 644018048833823482390819947896524207635857984552089977996313113154016668 > 718795349783157384006672542605760392289645528307"); > BigInteger b2 = BigInteger.valueOf(0); > BigInteger check = BigInteger.valueOf(1); > for (int i = 0; i < n; i++) { > b2 = b1.multiply(b1); > if (i == 0) > // Didn't JIT yet. Comparing against interpreted mode > check = b2; > } > if (b2.compareTo(check) == 0) > System.out.println("Check ok!"); > else > System.out.println("Check failed!"); > } > } > > > I got these results on JDK8 on my POWER8 machine: > $ ./javac TestSquareToLen.java > $ sudo perf stat -r 5 ./java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 15148.009557 task-clock (msec) # 1.053 CPUs > utilized ( +- 0.48% ) > 2,425 context-switches # 0.160 K/sec > ( +- 5.84% ) > 356 cpu-migrations # 0.023 K/sec > ( +- 3.01% ) > 5,153 page-faults # 0.340 K/sec > ( +- 5.22% ) > 54,536,889,909 cycles # 3.600 GHz > ( +- 0.56% ) (66.68%) > 239,554,105 stalled-cycles-frontend # 0.44% frontend > cycles idle ( +- 4.87% ) (49.90%) > 27,683,316,001 stalled-cycles-backend # 50.76% backend > cycles idle ( +- 0.56% ) (50.17%) > 102,020,229,733 instructions # 1.87 insn per > cycle > # 0.27 stalled > cycles per insn ( +- 0.14% ) (66.94%) > 7,706,072,218 branches # 508.718 M/sec > ( +- 0.23% ) (50.20%) > 456,051,162 branch-misses # 5.92% of all > branches ( +- 0.09% ) (50.07%) > > 14.390840733 seconds time elapsed > ( +- 0.09% ) > > $ sudo perf stat -r 5 ./java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 11368.141410 task-clock (msec) # 1.045 CPUs > utilized ( +- 0.64% ) > 1,964 context-switches # 0.173 K/sec > ( +- 8.93% ) > 338 cpu-migrations # 0.030 K/sec > ( +- 7.65% ) > 5,627 page-faults # 0.495 K/sec > ( +- 6.15% ) > 41,100,168,967 cycles # 3.615 GHz > ( +- 0.50% ) (66.36%) > 309,052,316 stalled-cycles-frontend # 0.75% frontend > cycles idle ( +- 2.84% ) (49.89%) > 14,188,581,685 stalled-cycles-backend # 34.52% backend > cycles idle ( +- 0.99% ) (50.34%) > 77,846,029,829 instructions # 1.89 insn per > cycle > # 0.18 stalled > cycles per insn ( +- 0.29% ) (66.96%) > 8,435,216,989 branches # 742.005 M/sec > ( +- 0.28% ) (50.17%) > 339,903,936 branch-misses # 4.03% of all > branches ( +- 0.27% ) (49.90%) > > 10.882357546 seconds time elapsed > ( +- 0.24% ) > > > (out of curiosity, these numbers are 15.19s (+- 0.32%) and 13.42s (+- > 0.53%) on JDK10) > > I may run for SpecJVM2008's crypto.rsa if you are interested. > > Thank you once again for reviewing this. > > Best regards, > Gustavo > > > (I think the change is still acceptable as the intrinsics could be > > used elsewhere and the implementation also exists on other platforms.) > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Mittwoch, 16. August 2017 18:50 > > To: Doerr, Martin ; 'hotspot-compiler- > > dev at openjdk.java.net' > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > SquareToLen intrinsics > > > > Hi Martin, > > > > Thanks for dedicated review. It took me a while to be able to work on > > this but I hope to have your points solved. Please check below the > > review as well as my comments quoting your email: > > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > > > > > -----Original Message----- > > > First of all, C2 does not perform sign extend when calling stubs. > > > The int parms need to get zero/sign extended. (Could even be done > > > without extra instructions by replacing sldi -> rldicl, cmpdi -> > > > extsw_ in some > > > cases.) > > > > Does it make a difference on my case? > > > > I guess you are talking about mulAdd preparation code. The only aspect > > I found about him is to force the cast from 32 bits -> 64 bits by > > cleaning higher bits. Offset is a signed integer but it can't be > negative anyway. > > > > So I changed from: > > sldi (R5_ARG3, R5_ARG3, 2); > > > > to: > > rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > > > > > > > macroAssembler_ppc.cpp: > > > - Indentation should be 2 spaces. > > > > Done > > > > > > > stubGenerator_ppc:cpp: > > > - or_, addi_ should get replaced by orr, addi when CR0 result is not > > > needed. > > > > Done > > > > > - Where is lplw initialized? > > > > It should be initialized with 0, I missed that... > > > > > - I believe that the updating load/store instructions e.g. lwzu > > > don't perform well on some processors. At least using stwu 2 times > > > in the loop doesn't make sense. > > > > You are right. I could manipulate the bits differently and ended up > > with a single stdu in the loop. Neat! Although I could not reduce the > > total number of instructions. > > > > > - Note: It should be possible to use 8 byte instead of 4 byte > > > instructions: MacroAssembler::multiply64, addc, adde. But I'm not > > > requesting to change that because I guess it would make the code > > > very complicated, especially when supporting both endianess > versions. > > > > Yes, that would require a new analysis on this code. May we consider > > it next? As you said, I prefer having an initial version that looks as > > simple as the original java code. > > > > > - The squareToLen stub implementation is very close the Java > > > implementation. So it'd be interesting to understand what C2 doesn't > > > do as well as the hand written assembly code. Do you know that? (Not > > > absolutely necessary for accepting this change as long as the stub > > > is measurably faster.) > > > > I don't know either. Basically I chose doing it because I noticed some > > performance gain on SpecJVM2008 when analyzing X64. Then, taking a > > closer look, I didn't notice any AVX or some special instructions on > > X64 so I decided to try it on ppc64 by using some basic assembly. > > > > Thanks > > > > > > > > Best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Donnerstag, 10. August 2017 19:22 > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net> > > > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > > > > > > > -----Original Message----- > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > > > To: ppc-aix-port-dev at openjdk.java.net > > > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > Hi, > > > > > > Could you please review this specific PPC64 change to hotspot? By > > > implementing these intrinsics I noticed a small improvement with > > > microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, > > > only when backporting to JDK8 an improvement was noticed. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > > > > > Motivation for this implementation: > > > https://twitter.com/ijuma/status/698309312498835457 > > > > > > Best regards, > > > Gustavo Serra Scalet From robbin.ehn at oracle.com Thu Aug 31 06:13:26 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 31 Aug 2017 08:13:26 +0200 Subject: RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark In-Reply-To: References: <9fc2a70d-70bb-362b-16dd-6b5eaf018991@oracle.com> <6b4e31ae-8c3c-92f7-8743-75f6791cae0d@oracle.com> <9480F78C-F0FB-4F26-B272-E7522B8A92F5@redhat.com> Message-ID: On 08/30/2017 05:03 PM, Roman Kennke wrote: > OK :-) Thanks, Robbin > > Cheers, Roman > > > Am 30. August 2017 16:50:26 MESZ schrieb Robbin Ehn : > > Hi Roman, > > On 08/30/2017 12:14 PM, Roman Kennke wrote: > > It sounds to me like LA/RL would be required and sufficient on _state ? > > > Yes, but > - Using la/rs just sometimes can be confusing, changing to get/set with la/rs semantics also means we need to change assembly to use proper memory ordering, > e.g. lda instead of ldr on aarch64 and armv7 add e.g. ldr, dmb, etc... > (I asked compiler, their thoughts was dirty reads are most likely okay in all other cases since _state only goes 'up') > - Using la/rs in just this case means either duplicate methods with acquire semantic or adding a bool to a lot of methods since these are accessed in deep call hierarchies. > - The write side is using storestore today > > For those reasons I said: > > Instead for simplicity the write side storestore fence should be match with loadload on read side and the changes to _stack_traversal_mark undone (kept it volatile). > > > I'm well aware this no near perfect, but we need that loadload fence, so can you can live with my proposed change? > And we can discussed the bigger picture in 8186839? > > Thanks, Robbin > > > Roman > > Am 29. August 2017 16:50:03 MESZ schrieb Robbin Ehn : > > Hi Roman thanks for having a look, > > On 08/29/2017 03:00 PM, Roman Kennke wrote: > > Hi Robin, > > I doubt that we can assume a symmetry between loadload and storestore like there is with load-acquire and release-store. This doesn't seem right. In my experience > loadload > and storestore are rather special purpose: loadload ensures ordering between otherwise unrelated loads and storestore likewise with stores. > > > This exactly why I add loadload, to stop reordering of unrelated loads: > > ####################### > The original code did: > > //nmethod::make_not_entrant_or_zombie > store _stack_traversal_mark > storestore > store _state > > //NMethodSweeper::process_compiled_method > load _state > load _stack_traversal_mark // this is a none-volatile load, can be reordered by both gcc and hardware > > ####################### > Adding la/sr + volatile to _stack_traversal_mark: > > store _stack_traversal_mark release // release not needed, we have a following storestore for the unrelated stores > storestore > store _state > > load _state > load _stack_traversal_mark acquire // acquire not needed since we already loaded _state and any following writes/reads will be done after we have taken a Mutex. > > ####################### > So therefore my conclusion was that, in this particular case: > > store _stack_traversal_mark > storestore > store _state > > load _state > loadload > load _stack_traversal_mark > > would be correct, agree? > > And as I said I have created another jira issue for the concerns me, you and David share. > > Thanks Robbin > > > And even symmetric use of load-acquire and release-store are often done wrong: those are not meant to protect concurrent access to the field, but to the stuff that is > protected by the field access (think locks), I.e. what happens between the LA and RS. At least that is my understanding. > > I suggest to do what David said and try to understand what concurrent accesses to which fields we have, and which fences are actually needed to ensure correct ordering. > > And thanks for revisiting this! > > Cheers, Roman > > Am 29. August 2017 12:31:17 MESZ schrieb Robbin Ehn : > > Hi please review, > > The issue 8180932 - "Parallelize safepoint cleanup" changed _stack_traversal_mark to load acquire/store release, this is at least half wrong. > Instead for simplicity the write side storestore fence should be match with loadload on read side and the changes to _stack_traversal_mark undone (kept it volatile). > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8186837 > > Code: > http://cr.openjdk.java.net/~rehn/8186837/hotspot.01/webrev/ > > It's not clear in this code if there other concurrent dependent read/writes. > Is true that only when reading/writing _state and _stack_traversal_mark proper memory ordering is needed? > To track that I created:https://bugs.openjdk.java.net/browse/JDK-8186839 > > Thanks Robbin > > > -- > Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. > > > -- > Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. > > > -- > Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From dmitrij.pochepko at bell-sw.com Thu Aug 31 13:39:29 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 31 Aug 2017 16:39:29 +0300 Subject: [10] RFR: 8186915 - AARCH64: Intrinsify squareToLen and mulAdd Message-ID: Hi, please review a patch for "8186915 - AARCH64: Intrinsify squareToLen and mulAdd" which adds respective intrinsics. webrev: http://cr.openjdk.java.net/~dpochepk/8186915/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8186915 With these intrinsics implemented I see 8% improvement in specjvm2008 crypto.rsa: 2333.13 ops/m vs 2520.11 ops/m. (results for specjvm2008 crypto rsa are here: http://cr.openjdk.java.net/~dpochepk/8186915/specjvm_crypto.rsa_baseline.txt and http://cr.openjdk.java.net/~dpochepk/8186915/specjvm_crypto.rsa_intrinsic.txt) I've also created a small microbenchmark: http://cr.openjdk.java.net/~dpochepk/8186915/BigIntegerBench.java which calls respective method and shows up to about 30% improvement on intrinsified version. raw numbers for: ThunderX: - baseline squareToLen: http://cr.openjdk.java.net/~dpochepk/8186915/squareToLen_baseline.txt - intrinsic squareToLen: http://cr.openjdk.java.net/~dpochepk/8186915/squareToLen_squareToLen.txt - baseline mulAdd: http://cr.openjdk.java.net/~dpochepk/8186915/muladd_baseline_t88.txt - intrinsic mulAdd: http://cr.openjdk.java.net/~dpochepk/8186915/muladd_intrinsic_t88.txt Cortex A53: - baseline squareToLen: http://cr.openjdk.java.net/~dpochepk/8186915/squareToLen_baseline_RPi.txt - intrinsic squareToLen: http://cr.openjdk.java.net/~dpochepk/8186915/squareToLen_squareToLen_RPi.txt - baseline mulAdd: http://cr.openjdk.java.net/~dpochepk/8186915/mulAdd_baseline_RPi.txt - intrinsic mulAdd: http://cr.openjdk.java.net/~dpochepk/8186915/mulAdd_intrinsic_RPi.txt I've also run jtreg tests in jdk/test/java/math/BigInteger/* and found no new failures. Thanks, Dmitrij From martin.doerr at sap.com Thu Aug 31 16:21:05 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 31 Aug 2017 16:21:05 +0000 Subject: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic In-Reply-To: <59A089F4.6010504@linux.vnet.ibm.com> References: <4999bc2a3f0640dfb6dd75d23b4f30ea@sap.com> <0089f9f653a6442aa672af2e15b2b864@serv030.corp.eldorado.org.br> <59397a3749024e91b56be6e990a3250d@sap.com> <363c2378f23e4be2bf60b622594c60fe@sap.com> <59A089F4.6010504@linux.vnet.ibm.com> Message-ID: <34e6550d426440bab3b8a54a82e25190@sap.com> Hi Gustavo R, I guess you're right. vrsave is already set to -1, so all Vector Registers get saved. It'd be good to know where it is set (OS, Flag in ELF header, ???) and if this is guaranteed. I don't want to risk getting sporadic errors on some OS versions. I'd like to enable SHA intrinsics on linux BE as well. I already managed to get the 256 bit version working (was quite some work!). Thanks and best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Freitag, 25. August 2017 22:35 To: Doerr, Martin Cc: Gustavo Serra Scalet ; 'hotspot-compiler-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net Subject: Re: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic Hi Martin, On 25-08-2017 13:18, Doerr, Martin wrote: > I think you didn't get my point about AIX. > Your current version doesn't break AIX, but it lacks SHA2 acceleration for AIX on Power 8 and newer, which is still relevant. > So I'd like to ask you kindly to take a look if Big Endian support for the stub could be added without high effort. AIX doesn't need VRSAVE handling (like Little Endian linux, unlike Big Endian linux), so a few lines in the stub could possibly be enough. I can assist with testing. I don't think that VRSAVE is handled on Linux, even on BE. Although BE ABI [1] says: "Functions must ensure that the appropriate bits in the vrsave register are set for any vector registers they use" and LE ABI does not say that, even on Linux BE VRSAVE is not in effect used to determine which vector registers (VMX/Altivec) should be saved/restored. No application uses it on Linux, so I would say that VRSAVE is ignored on Linux completely both on BE and LE. save/restore library interfaces don't pay attention to it in glibc: VRSAVE is just saved/restored completely in mechanisms of swap/get/setcontext(), set/longjump(), and dl-trampoline() and that's all. I checked that with toolchain folks and they agree. We've already discussed that a long time ago but at that time I was just using the vector-scalar registers [2] and at that time I agreed that if VMX/Altivec was in use instead of the VSX so VRSAVE should be handled accordingly. But I have a different opinion now... I'm wondering if something would really break on Linux BE if we forget about VRSAVE at all in the JVM. If not, we could forget about VRSAVE forever on Linux. Looks like VRSAVE was sort of born to the oblivion... ? Kind regards, Gustavo [1] http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html [2] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-May/002508.html From aph at redhat.com Thu Aug 31 17:27:39 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Aug 2017 18:27:39 +0100 Subject: [10] RFR: 8186915 - AARCH64: Intrinsify squareToLen and mulAdd In-Reply-To: References: Message-ID: <8ba3ab4d-6d71-b0f5-352f-463ca71ba2a5@redhat.com> On 31/08/17 14:39, Dmitrij Pochepko wrote: > please review a patch for "8186915 - AARCH64: Intrinsify squareToLen and > mulAdd" which adds respective intrinsics. > > webrev: http://cr.openjdk.java.net/~dpochepk/8186915/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8186915 > > With these intrinsics implemented I see 8% improvement in specjvm2008 > crypto.rsa: 2333.13 ops/m vs 2520.11 ops/m. I don't see anything like that. I see an improvement of 1.6%, which is what I'd expect, given this profile: samples cum. samples % cum. % symbol name 31866443 31866443 59.7443 59.7443 montgomerySquare 6125600 37992043 11.4845 71.2287 montgomeryMultiply 4036511 42028554 7.5678 78.7965 java.math.MutableBigInteger java.math.MutableBigInteger.divideMagnitude(java.math.MutableBigInteger, java.math.MutableBigInteger, boolean)~1 2056787 44085341 3.8561 82.6527 java.math.BigInteger java.math.BigInteger.oddModPow(java.math.BigInteger, java.math.BigInteger)~2 1145996 45231337 2.1486 84.8012 Ljava/math/MutableBigInteger;divideMagnitude(Ljava/math/MutableBigInteger;Ljava/math/MutableBigInteger;Z)Ljava/math/MutableBigInteger;%32 1140132 46371469 2.1376 86.9388 int[] java.math.BigInteger.montReduce(int[], int[], int, int)~2 558960 46930429 1.0480 87.9867 java.security.Provider$Service java.security.Provider.getService(java.lang.String, java.lang.String) after your patch, I get: samples cum. samples % cum. % symbol name 32574982 32574982 60.3583 60.3583 montgomerySquare 6196936 38771918 11.4823 71.8407 montgomeryMultiply 5103970 43875888 9.4572 81.2978 java.math.MutableBigInteger java.math.MutableBigInteger.divideMagnitude(java.math.MutableBigInteger, java.math.MutableBigInteger, boolean) 1991144 45867032 3.6894 84.9872 java.math.BigInteger java.math.BigInteger.oddModPow(java.math.BigInteger, java.math.BigInteger)~1 792336 46659368 1.4681 86.4554 mulAdd 586130 47245498 1.0860 87.5414 java.security.Provider$Service java.security.Provider.getService(java.lang.String, java.lang.String) So we're seeing a boost to the performance of BigInteger.montReduce, which is dominated by mulAdd, which makes sense, but it's not a very large part of the total. Your mul_add routine is less efficient than it should be. It uses 32-bit multiply operations when it could use 64-bit ones, just as the multiply_to_len does. Your square_to_len routine has the same problem. There is an x86 example of how square_to_len should be done. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From igor.ignatyev at oracle.com Thu Aug 31 18:02:35 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 31 Aug 2017 11:02:35 -0700 Subject: RFR(XS) : 8187020 : AOT tests should not fail if devkit dependency isn't resolved Message-ID: <5827C35C-76F1-437D-844A-1543F7C80C41@oracle.com> http://cr.openjdk.java.net/~iignatyev//8187020/webrev.00/index.html > 11 lines changed: 5 ins; 0 del; 6 mod; Hi all, could you please review this tiny fix or AOT tests? Prior this fix, the tests would fail w/ FileNotFoundException when devkit dependency can't be resolved even if jaotc is able to find a linker, e.g. in one of VS*COMNTOOLS. after this fix, if tests aren't able to download devkit, they will allow jaotc to try to find a linker. This patch also remove search for 'ld' in PATH on windows b/c jaotc doesn't use it on windows. webrev: http://cr.openjdk.java.net/~iignatyev//8187020/webrev.00/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8187020 testing: compiler/aot tests Thanks, -- Igor From bob.vandette at oracle.com Thu Aug 31 19:14:21 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 31 Aug 2017 15:14:21 -0400 Subject: RFR(XS) : 8187020 : AOT tests should not fail if devkit dependency isn't resolved In-Reply-To: <5827C35C-76F1-437D-844A-1543F7C80C41@oracle.com> References: <5827C35C-76F1-437D-844A-1543F7C80C41@oracle.com> Message-ID: The change looks ok to me. Bob. > On Aug 31, 2017, at 2:02 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8187020/webrev.00/index.html >> 11 lines changed: 5 ins; 0 del; 6 mod; > > Hi all, > > could you please review this tiny fix or AOT tests? Prior this fix, the tests would fail w/ FileNotFoundException when devkit dependency can't be resolved even if jaotc is able to find a linker, e.g. in one of VS*COMNTOOLS. after this fix, if tests aren't able to download devkit, they will allow jaotc to try to find a linker. This patch also remove search for 'ld' in PATH on windows b/c jaotc doesn't use it on windows. > > webrev: http://cr.openjdk.java.net/~iignatyev//8187020/webrev.00/index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8187020 > testing: compiler/aot tests > > Thanks, > -- Igor From vladimir.kozlov at oracle.com Thu Aug 31 21:12:27 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Aug 2017 14:12:27 -0700 Subject: RFR(XS) : 8187020 : AOT tests should not fail if devkit dependency isn't resolved In-Reply-To: <5827C35C-76F1-437D-844A-1543F7C80C41@oracle.com> References: <5827C35C-76F1-437D-844A-1543F7C80C41@oracle.com> Message-ID: On MacOS we also have problem when 'ld' is present on path but Xcode is missing: % /usr/bin/ld -v xcode-select: error: no developer tools were found at '/Applications/Xcode.app', and no install could be requested (perhaps no UI is present), please install manually from 'developer.apple.com'. AOT tests will fail in such case too. May be AotCompiler test code also have to execute ld -v (or ld -V on Solaris) to check that we can use linker similar to JAOTC tool: http://hg.openjdk.java.net/jdk10/hs/hotspot/file/a8ec32aa385e/src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Linker.java#l104 Vladimir On 8/31/17 11:02 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8187020/webrev.00/index.html >> 11 lines changed: 5 ins; 0 del; 6 mod; > > Hi all, > > could you please review this tiny fix or AOT tests? Prior this fix, the tests would fail w/ FileNotFoundException when devkit dependency can't be resolved even if jaotc is able to find a linker, e.g. in one of VS*COMNTOOLS. after this fix, if tests aren't able to download devkit, they will allow jaotc to try to find a linker. This patch also remove search for 'ld' in PATH on windows b/c jaotc doesn't use it on windows. > > webrev: http://cr.openjdk.java.net/~iignatyev//8187020/webrev.00/index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8187020 > testing: compiler/aot tests > > Thanks, > -- Igor > From dmitrij.pochepko at bell-sw.com Thu Aug 31 22:46:39 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 1 Sep 2017 01:46:39 +0300 Subject: [10] RFR: 8186915 - AARCH64: Intrinsify squareToLen and mulAdd In-Reply-To: <8ba3ab4d-6d71-b0f5-352f-463ca71ba2a5@redhat.com> References: <8ba3ab4d-6d71-b0f5-352f-463ca71ba2a5@redhat.com> Message-ID: On 31.08.2017 20:27, Andrew Haley wrote: > On 31/08/17 14:39, Dmitrij Pochepko wrote: >> please review a patch for "8186915 - AARCH64: Intrinsify squareToLen and >> mulAdd" which adds respective intrinsics. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8186915/webrev.01/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8186915 >> >> With these intrinsics implemented I see 8% improvement in specjvm2008 >> crypto.rsa: 2333.13 ops/m vs 2520.11 ops/m. > I don't see anything like that. I see an improvement of 1.6%, which is > what I'd expect, given this profile: > > samples cum. samples % cum. % symbol name > 31866443 31866443 59.7443 59.7443 montgomerySquare > 6125600 37992043 11.4845 71.2287 montgomeryMultiply > 4036511 42028554 7.5678 78.7965 java.math.MutableBigInteger java.math.MutableBigInteger.divideMagnitude(java.math.MutableBigInteger, java.math.MutableBigInteger, boolean)~1 > 2056787 44085341 3.8561 82.6527 java.math.BigInteger java.math.BigInteger.oddModPow(java.math.BigInteger, java.math.BigInteger)~2 > 1145996 45231337 2.1486 84.8012 Ljava/math/MutableBigInteger;divideMagnitude(Ljava/math/MutableBigInteger;Ljava/math/MutableBigInteger;Z)Ljava/math/MutableBigInteger;%32 > 1140132 46371469 2.1376 86.9388 int[] java.math.BigInteger.montReduce(int[], int[], int, int)~2 > 558960 46930429 1.0480 87.9867 java.security.Provider$Service java.security.Provider.getService(java.lang.String, java.lang.String) > > after your patch, I get: > > samples cum. samples % cum. % symbol name > 32574982 32574982 60.3583 60.3583 montgomerySquare > 6196936 38771918 11.4823 71.8407 montgomeryMultiply > 5103970 43875888 9.4572 81.2978 java.math.MutableBigInteger java.math.MutableBigInteger.divideMagnitude(java.math.MutableBigInteger, java.math.MutableBigInteger, boolean) > 1991144 45867032 3.6894 84.9872 java.math.BigInteger java.math.BigInteger.oddModPow(java.math.BigInteger, java.math.BigInteger)~1 > 792336 46659368 1.4681 86.4554 mulAdd > 586130 47245498 1.0860 87.5414 java.security.Provider$Service java.security.Provider.getService(java.lang.String, java.lang.String) > > So we're seeing a boost to the performance of BigInteger.montReduce, > which is dominated by mulAdd, which makes sense, but it's not a very > large part of the total. > > Your mul_add routine is less efficient than it should be. It uses > 32-bit multiply operations when it could use 64-bit ones, just as the > multiply_to_len does. Your square_to_len routine has the same > problem. > > There is an x86 example of how square_to_len should be done. > Hi, I tried a number of initial versions first. I also tried to use wider multiplication via umulh (and larger load instructions like ldp/ldr), but after measuring all versions I've found that version I've initially sent appeared to be the fastest (I was measuring it on ThunderX which I have in hand). It might be because of lots of additional ror(..., 32) operations in other versions to convert values from initial layout to register and back. Another reason might be more complex overall logic and larger code, which triggers more icache lines to be loaded. Or even some umulh specifics on some CPUs. So, after measuring, I've abandoned these versions in a middle of development and polished the fastest one. I have some raw development unpolished versions of such approaches left(not sure I have debugged versions saved, but at least has an overall idea). I attached squares_v2.3.1.diff: early version which is using mul/umulh for just one case. It was surprisingly slower for this case than version I've sent to review, so, I've abandoned this approach. I've also tried version with large load instructions(ldp/ldr): squares_v1.diff and it was also slower(it has another, slower, mul_add loop implementation, but I was comparing to the same version, which is using ldrw-only). I'm not sure if I should use 64-bit multiplications and/or 64/128 bit loads. I can try to return back to one of such versions and try to polish it, but I'll probably get slower results again on h/w I have and it's not clear if it'll be faster on any other h/w(which one? It takes a lot of time to iteratively improve and measure every version on respective h/w). Thanks, Dmitrij -------------- next part -------------- A non-text attachment was scrubbed... Name: squares_v1.diff Type: text/x-patch Size: 15640 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: squares_v2.3.1.diff Type: text/x-patch Size: 8339 bytes Desc: not available URL: From jaroslav.tulach at oracle.com Wed Aug 2 14:10:43 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 02 Aug 2017 14:10:43 -0000 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <92954922-7C4F-4B33-BC8B-DC5FC7D3F1FA@oracle.com> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <4506356.BY5Vv2ZSov@logoutik> <92954922-7C4F-4B33-BC8B-DC5FC7D3F1FA@oracle.com> Message-ID: <3097604.jcdSgtZXxL@pracovni> > This is Graal-specific MBean. It doesn?t seem that it must be registered as > ?platform mbean? which has to implement PlatformManagedObject. > > Graal can register the MBean at runtime when java.management is present by > calling ManagementFactory.getPlatformMBeanServer().registerMBean method. > That seems to be a better alternative. Separating the MBean in a different > module would still be applicable. This is not possible to do cleanly. When shall Graal register the bean? On first compilation? Then it may enable the whole ManagementFactory infrastructure too early and influence results of regular Java programs. We have seen a benchmark failure due to registering the Graal bean too early. The bean registration triggered the java.util.logging infrastructure on and as a result the benchmarking test failed. The test tried to set "java.util.logging.config.file" property and then it assumed it will be used on subsequent call to Logger.getLogger(...). But the property was ignored as the Logger was already initialized. I believe that exactly for this reason there is the PlatformManagedObject & co. infrastructure. To not trigger the management infrastructure on prematurely. All the HotSpot beans are registered "lazily". As part of internal JDK infrastructure we believe Graal should have a way to be part of such "lazy initialization" too. I hope the need for the requested functionality is now clearer. -jt From jaroslav.tulach at oracle.com Thu Aug 3 15:06:01 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 03 Aug 2017 15:06:01 -0000 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <4506356.BY5Vv2ZSov@logoutik> <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> Message-ID: <14332343.G5UyyslDlL@pracovni> On ?tvrtek 27. ?ervence 2017 15:01:17 CEST Alan Bateman wrote: > On 27/07/2017 10:07, Jaroslav Tulach wrote: > > Yes, it seems like a desirable goal to let Graal compiler work with just > > java.base. Is there a description how to build JDK9/10 with just java.base > > that I could follow and test against? > > You can use jlink to create a run-time image that only contains > java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base > --output smalljre). Status update: I've just tried to run Graal compiler against JDK9 with only java.base and jdk.internal.vm.ci modules, and there are some problems. I need to resolve them first before I provide updated version of my patch. Thanks for your support so far. -jt > >> If it exposes a MBean, the dependency would be needed. > > > > Isn't there a way to require an optional dependency? That would be > > sufficient - as the classes in question are only loaded once > > java.management searches for them. E.g. only when java.management is > > installed. > > There is `requires static` but it would be a lot cleaner if the > management support could be refactored into its own service provider > module, meaning JVMCIMXBeans would be in its own module. > > -Alan From lenborje at gmail.com Tue Aug 29 07:32:47 2017 From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=) Date: Tue, 29 Aug 2017 07:32:47 -0000 Subject: [10] RFR(S) 8186462: [Graal] build Graal regardless AOT build In-Reply-To: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> References: <9e323ea7-2943-4921-05be-4c87cafc4067@oracle.com> Message-ID: Could we, please, get this on OSX/MacOS, too? (For now, I enabling it in my own builds, but it would be nice to have it in the release builds.) Best regards, /Lennart > 28 aug. 2017 kl. 22:18 skrev Vladimir Kozlov : > > http://cr.openjdk.java.net/~kvn/8186462/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8186462 > > We are planning to have Graal as experimental JIT compiler on linux-x64 in next release. For that we should enable its build independent from AOT build. > > Thanks, > Vladimir