From volker.simonis at gmail.com Wed Jul 15 14:23:54 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jul 2015 16:23:54 +0200 Subject: How to prevent /proc//status from running slow on AIX ? Message-ID: Hi AIX experts, do you have any idea how to prevent /proc//status from running slow on AIX (compared to times() and getrusage())? Please have a look at the attached program which describes and demonstrates the problem in full detail. I'd need a workaround for this problem for the AIX port of the new ProcessHandle implementation which came as part of JEP 102. Thank you and best regards, Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: times.c Type: text/x-csrc Size: 3761 bytes Desc: not available URL: From dean.long at oracle.com Thu Jul 16 20:27:21 2015 From: dean.long at oracle.com (Dean Long) Date: Thu, 16 Jul 2015 13:27:21 -0700 Subject: How to prevent /proc//status from running slow on AIX ? In-Reply-To: References: Message-ID: <55A813A9.3060106@oracle.com> If you read /proc//status twice in a row, does the value increase or stay the same? I found the following that implies it's not being updated between reads: http://fixunix.com/aix/85091-reading-proc-status-file.html If that's the case then the accuracy would be limited by how often an internal snapshot is done for procfs. Being off by a clock tick sounds reasonable, but being off by 1 second? not so reasonable. dl On 7/15/2015 7:23 AM, Volker Simonis wrote: > Hi AIX experts, > > do you have any idea how to prevent /proc//status from running > slow on AIX (compared to times() and getrusage())? > > Please have a look at the attached program which describes and > demonstrates the problem in full detail. > > I'd need a workaround for this problem for the AIX port of the new > ProcessHandle implementation which came as part of JEP 102. > > Thank you and best regards, > Volker From volker.simonis at gmail.com Fri Jul 17 18:34:45 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jul 2015 20:34:45 +0200 Subject: How to prevent /proc//status from running slow on AIX ? In-Reply-To: <55A813A9.3060106@oracle.com> References: <55A813A9.3060106@oracle.com> Message-ID: Yes, reading /proc//status twice in a row will report exactly the same (inaccurate) value. It really seems that the update interval of /proc//status on AIX is much to coarse compared to other Unix implementations. Regards, Volker On Thu, Jul 16, 2015 at 10:27 PM, Dean Long wrote: > If you read /proc//status twice in a row, does the value increase or > stay the same? I found the following that implies it's not being updated > between reads: > > http://fixunix.com/aix/85091-reading-proc-status-file.html > > If that's the case then the accuracy would be limited by how often an > internal snapshot is done for procfs. > Being off by a clock tick sounds reasonable, but being off by 1 second? not > so reasonable. > > dl > > > On 7/15/2015 7:23 AM, Volker Simonis wrote: >> >> Hi AIX experts, >> >> do you have any idea how to prevent /proc//status from running >> slow on AIX (compared to times() and getrusage())? >> >> Please have a look at the attached program which describes and >> demonstrates the problem in full detail. >> >> I'd need a workaround for this problem for the AIX port of the new >> ProcessHandle implementation which came as part of JEP 102. >> >> Thank you and best regards, >> Volker > > From volker.simonis at gmail.com Fri Jul 24 06:50:24 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Jul 2015 08:50:24 +0200 Subject: How to prevent /proc//status from running slow on AIX ? In-Reply-To: References: <55A813A9.3060106@oracle.com> Message-ID: Hi, just for reference I want to post the answer I got from the IBM support here. Unfortunately, it seems that the described behaviour (i.e./proc//status running slow on AIX) seems to be the known, default behaviour which can not be changed easily: ".. /proc//status gets its data from a different source (pvproc), than does getrusage and times (the ublock). The ublock data is updated each time a thread leaves the CPU, while the pvproc data is aggregated from the threads by sched every second. Therefore, the pvproc based times are usually almost always behind the ublock based ones.." Regards, Volker On Fri, Jul 17, 2015 at 8:34 PM, Volker Simonis wrote: > Yes, reading /proc//status twice in a row will report exactly the > same (inaccurate) value. > > It really seems that the update interval of /proc//status on AIX > is much to coarse compared to other Unix implementations. > > Regards, > Volker > > On Thu, Jul 16, 2015 at 10:27 PM, Dean Long wrote: >> If you read /proc//status twice in a row, does the value increase or >> stay the same? I found the following that implies it's not being updated >> between reads: >> >> http://fixunix.com/aix/85091-reading-proc-status-file.html >> >> If that's the case then the accuracy would be limited by how often an >> internal snapshot is done for procfs. >> Being off by a clock tick sounds reasonable, but being off by 1 second? not >> so reasonable. >> >> dl >> >> >> On 7/15/2015 7:23 AM, Volker Simonis wrote: >>> >>> Hi AIX experts, >>> >>> do you have any idea how to prevent /proc//status from running >>> slow on AIX (compared to times() and getrusage())? >>> >>> Please have a look at the attached program which describes and >>> demonstrates the problem in full detail. >>> >>> I'd need a workaround for this problem for the AIX port of the new >>> ProcessHandle implementation which came as part of JEP 102. >>> >>> Thank you and best regards, >>> Volker >> >> From aleksey.shipilev at oracle.com Fri Jul 24 09:49:10 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 24 Jul 2015 12:49:10 +0300 Subject: RFR (S) 8131682: C1 should use multibyte nops everywhere In-Reply-To: <55AF500B.9000505@oracle.com> References: <55A9033C.2030302@oracle.com> <55AA0567.6070602@oracle.com> <55AD0AE0.3060803@oracle.com> <55AEAB5C.8050307@oracle.com> <55AF500B.9000505@oracle.com> Message-ID: <55B20A16.7020300@oracle.com> (explicitly cc'ing AArch64 and PPC folks) Thanks, -Aleksey On 22.07.2015 11:10, Aleksey Shipilev wrote: > Thanks for review, Dean! > > I'd like to hear the opinions of AArch64 and Power folks, since we > contaminate their assemblers a bit to gain access to x86 fat nops. > > -Aleksey > > On 21.07.2015 23:28, Dean Long wrote: >> This version looks good. >> >> dl >> >> On 7/20/2015 7:51 AM, Aleksey Shipilev wrote: >>> Hi Dean, >>> >>> Thanks for taking a look! >>> >>> Silly me, I should have left the call patching cases intact, because >>> you're right, we should be able to patch the nops partially while still >>> producing the correct instruction stream. Therefore, I reverted the >>> cases where we do nop-ing for *instruction* patching, and added the >>> comment there. >>> >>> Other places seem to use the nop sequences to provide the alignment, not >>> for the general patching. Especially interesting for us is the case of >>> aligning the patcheable immediate in the existing call. C2 does the nops >>> in these cases. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~shade/8131682/webrev.01/ >>> >>> Testing: >>> * JPRT -testset hotspot on open platforms; >>> * Targeted benchmarks, plus eyeballing the assembly; >>> >>> Thanks, >>> -Aleksey >>> >>> On 18.07.2015 10:51, Dean Long wrote: >>>> I think we should distinguish the different uses and treat them >>>> accordingly: >>>> >>>> 1) padding nops for patching, executed >>>> >>>> We need to be careful about inserting a fat nop here, if later patching >>>> overwrites only part of the fat nop, resulting in an illegal intruction. >>>> >>>> 2) padding nops for patching, never executed >>>> >>>> It should be safe insert a fat nop here, but there's no point if the >>>> nops are not reachable and never executed. >>>> >>>> >>>> 3) alignment nops, never patched, executed >>>> >>>> Fat nops are fine, but on some CPUs branching may be even better, so I >>>> suggest using align() for this, and letting align() decide what to >>>> generate. The change in check_icache() could use a version of align >>>> that takes the target offset as an argument: >>>> >>>> 348 align(CodeEntryAlignment,__ offset() + ic_cmp_size); >>>> >>>> 4) alignment nops, never patched, never executed >>>> >>>> Doesn't matter what we emit here, but we might as well make it >>>> understandable by humans using a debugger. >>>> >>>> >>>> I believe the patching nops in c1_CodeStubs_x86.cpp and >>>> c1_LIRAssembler.cpp are patched concurrently while the code is running, >>>> not at a safepoint, so it's not clear to me if it's safe to use fat nops >>>> on x86. I would consider those changes unsafe on x86 without further >>>> analysis of what happens during patching. >>>> >>>> dl >>>> >>>> On 7/17/2015 6:29 AM, Aleksey Shipilev wrote: >>>>> Hi there, >>>>> >>>>> C1 is not very good at inlining and intrisifying methods, and hence the >>>>> call performance is important there. One nit that we can see in the >>>>> generated code on x86 is that C1 uses the single-byte nops, even for >>>>> long nop strides. >>>>> >>>>> This improvement fixes that: >>>>> https://bugs.openjdk.java.net/browse/JDK-8131682 >>>>> http://cr.openjdk.java.net/~shade/8131682/webrev.00/ >>>>> >>>>> Testing: >>>>> - JPRT -testset hotspot on open platforms >>>>> - eyeballing the generated assembly with -XX:TieredStopAtLevel=1 >>>>> >>>>> (I understand the symmetric change is going to be needed in closed >>>>> parts, but let's polish the open part first). >>>>> >>>>> Thanks, >>>>> -Aleksey >>>>> >>> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From goetz.lindenmaier at sap.com Fri Jul 24 10:38:10 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 24 Jul 2015 10:38:10 +0000 Subject: RFR (S) 8131682: C1 should use multibyte nops everywhere In-Reply-To: <55B20A16.7020300@oracle.com> References: <55A9033C.2030302@oracle.com> <55AA0567.6070602@oracle.com> <55AD0AE0.3060803@oracle.com> <55AEAB5C.8050307@oracle.com> <55AF500B.9000505@oracle.com> <55B20A16.7020300@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D00A472@DEWDFEMB12A.global.corp.sap> Hi Aleksey, thanks for pointing us to that change! Looks good, but does not compile. Default arg should only be in the header. See below. Ppc part reviewed and I don?t need a new webrev. Best regards, Goetz. --- a/src/cpu/ppc/vm/assembler_ppc.inline. +++ b/src/cpu/ppc/vm/assembler_ppc.inline.hpp @@ -210,7 +210,7 @@ inline void Assembler::extsw( Register a, Register s) { emit_int32(EXTSW_OPCODE | rta(a) | rs(s) | rc(0)); } // extended mnemonics -inline void Assembler::nop() { Assembler::ori(R0, R0, 0); } +inline void Assembler::nop(int count) { for (int i = 0; i < count; i++) { Assembler::ori(R0, R0, 0); } } // NOP for FP and BR units (different versions to allow them to be in one group) inline void Assembler::fpnop0() { Assembler::fmr(F30, F30); } inline void Assembler::fpnop1() { Assembler::fmr(F31, F31); } g++ 4.8.3: In file included from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/share/vm/asm/assembler.inline.hpp:43:0, from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/cpu/ppc/vm/macroAssembler_ppc.inline.hpp:29, from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/share/vm/asm/macroAssembler.inline.hpp:43, from ../generated/adfiles/ad_ppc_64.cpp:56: /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/cpu/ppc/vm/assembler_ppc.inline.hpp:213:41: error: default argument given for parameter 1 of void Assembler::nop(int) [-fpermissive] inline void Assembler::nop(int count = 1) { for(int i = 0; i < count; i++) ^ In file included from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/share/vm/asm/assembler.hpp:434:0, from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/cpu/ppc/vm/nativeInst_ppc.hpp:29, from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/share/vm/code/nativeInst.hpp:41, from ../generated/adfiles/ad_ppc_64.hpp:57, from ../generated/adfiles/ad_ppc_64.cpp:54: /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/cpu/ppc/vm/assembler_ppc.hpp:1383:15: error: after previous specification in void Assembler::nop(int) [-fpermissive] inline void nop(int count = 1); ^ -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Aleksey Shipilev Sent: Friday, July 24, 2015 11:49 AM To: Dean Long; hotspot compiler Cc: ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: Re: RFR (S) 8131682: C1 should use multibyte nops everywhere * PGP Signed by an unknown key (explicitly cc'ing AArch64 and PPC folks) Thanks, -Aleksey On 22.07.2015 11:10, Aleksey Shipilev wrote: > Thanks for review, Dean! > > I'd like to hear the opinions of AArch64 and Power folks, since we > contaminate their assemblers a bit to gain access to x86 fat nops. > > -Aleksey > > On 21.07.2015 23:28, Dean Long wrote: >> This version looks good. >> >> dl >> >> On 7/20/2015 7:51 AM, Aleksey Shipilev wrote: >>> Hi Dean, >>> >>> Thanks for taking a look! >>> >>> Silly me, I should have left the call patching cases intact, because >>> you're right, we should be able to patch the nops partially while still >>> producing the correct instruction stream. Therefore, I reverted the >>> cases where we do nop-ing for *instruction* patching, and added the >>> comment there. >>> >>> Other places seem to use the nop sequences to provide the alignment, not >>> for the general patching. Especially interesting for us is the case of >>> aligning the patcheable immediate in the existing call. C2 does the nops >>> in these cases. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~shade/8131682/webrev.01/ >>> >>> Testing: >>> * JPRT -testset hotspot on open platforms; >>> * Targeted benchmarks, plus eyeballing the assembly; >>> >>> Thanks, >>> -Aleksey >>> >>> On 18.07.2015 10:51, Dean Long wrote: >>>> I think we should distinguish the different uses and treat them >>>> accordingly: >>>> >>>> 1) padding nops for patching, executed >>>> >>>> We need to be careful about inserting a fat nop here, if later patching >>>> overwrites only part of the fat nop, resulting in an illegal intruction. >>>> >>>> 2) padding nops for patching, never executed >>>> >>>> It should be safe insert a fat nop here, but there's no point if the >>>> nops are not reachable and never executed. >>>> >>>> >>>> 3) alignment nops, never patched, executed >>>> >>>> Fat nops are fine, but on some CPUs branching may be even better, so I >>>> suggest using align() for this, and letting align() decide what to >>>> generate. The change in check_icache() could use a version of align >>>> that takes the target offset as an argument: >>>> >>>> 348 align(CodeEntryAlignment,__ offset() + ic_cmp_size); >>>> >>>> 4) alignment nops, never patched, never executed >>>> >>>> Doesn't matter what we emit here, but we might as well make it >>>> understandable by humans using a debugger. >>>> >>>> >>>> I believe the patching nops in c1_CodeStubs_x86.cpp and >>>> c1_LIRAssembler.cpp are patched concurrently while the code is running, >>>> not at a safepoint, so it's not clear to me if it's safe to use fat nops >>>> on x86. I would consider those changes unsafe on x86 without further >>>> analysis of what happens during patching. >>>> >>>> dl >>>> >>>> On 7/17/2015 6:29 AM, Aleksey Shipilev wrote: >>>>> Hi there, >>>>> >>>>> C1 is not very good at inlining and intrisifying methods, and hence the >>>>> call performance is important there. One nit that we can see in the >>>>> generated code on x86 is that C1 uses the single-byte nops, even for >>>>> long nop strides. >>>>> >>>>> This improvement fixes that: >>>>> https://bugs.openjdk.java.net/browse/JDK-8131682 >>>>> http://cr.openjdk.java.net/~shade/8131682/webrev.00/ >>>>> >>>>> Testing: >>>>> - JPRT -testset hotspot on open platforms >>>>> - eyeballing the generated assembly with -XX:TieredStopAtLevel=1 >>>>> >>>>> (I understand the symmetric change is going to be needed in closed >>>>> parts, but let's polish the open part first). >>>>> >>>>> Thanks, >>>>> -Aleksey >>>>> >>> >> > > * Unknown Key * 0x62A119A7 From aleksey.shipilev at oracle.com Mon Jul 27 09:13:53 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 27 Jul 2015 12:13:53 +0300 Subject: RFR (S) 8131682: C1 should use multibyte nops everywhere In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D00A472@DEWDFEMB12A.global.corp.sap> References: <55A9033C.2030302@oracle.com> <55AA0567.6070602@oracle.com> <55AD0AE0.3060803@oracle.com> <55AEAB5C.8050307@oracle.com> <55AF500B.9000505@oracle.com> <55B20A16.7020300@oracle.com> <4295855A5C1DE049A61835A1887419CC2D00A472@DEWDFEMB12A.global.corp.sap> Message-ID: <55B5F651.5090509@oracle.com> Thanks Goetz! Fixed the assembler_ppc.inline.hpp. Andrew/Edward, are you OK with AArch64 part? http://cr.openjdk.java.net/~shade/8131682/webrev.02/ Thanks, -Aleksey On 07/24/2015 01:38 PM, Lindenmaier, Goetz wrote: > Hi Aleksey, > > thanks for pointing us to that change! > Looks good, but does not compile. Default arg should only be in the header. > See below. > > Ppc part reviewed and I don?t need a new webrev. > > Best regards, > Goetz. > > --- a/src/cpu/ppc/vm/assembler_ppc.inline. > +++ b/src/cpu/ppc/vm/assembler_ppc.inline.hpp > @@ -210,7 +210,7 @@ > inline void Assembler::extsw( Register a, Register s) { emit_int32(EXTSW_OPCODE | rta(a) | rs(s) | rc(0)); } > > // extended mnemonics > -inline void Assembler::nop() { Assembler::ori(R0, R0, 0); } > +inline void Assembler::nop(int count) { for (int i = 0; i < count; i++) { Assembler::ori(R0, R0, 0); } } > // NOP for FP and BR units (different versions to allow them to be in one group) > inline void Assembler::fpnop0() { Assembler::fmr(F30, F30); } > inline void Assembler::fpnop1() { Assembler::fmr(F31, F31); } > > > g++ 4.8.3: > In file included from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/share/vm/asm/assembler.inline.hpp:43:0, > from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/cpu/ppc/vm/macroAssembler_ppc.inline.hpp:29, > from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/share/vm/asm/macroAssembler.inline.hpp:43, > from ../generated/adfiles/ad_ppc_64.cpp:56: > /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/cpu/ppc/vm/assembler_ppc.inline.hpp:213:41: error: default argument given for parameter 1 of void Assembler::nop(int) [-fpermissive] > inline void Assembler::nop(int count = 1) { for(int i = 0; i < count; i++) > ^ > In file included from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/share/vm/asm/assembler.hpp:434:0, > from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/cpu/ppc/vm/nativeInst_ppc.hpp:29, > from /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/share/vm/code/nativeInst.hpp:41, > from ../generated/adfiles/ad_ppc_64.hpp:57, > from ../generated/adfiles/ad_ppc_64.cpp:54: > /sapmnt/home1/d045726/oJ/8131682-hs-comp/src/cpu/ppc/vm/assembler_ppc.hpp:1383:15: error: after previous specification in void Assembler::nop(int) [-fpermissive] > inline void nop(int count = 1); > ^ > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Aleksey Shipilev > Sent: Friday, July 24, 2015 11:49 AM > To: Dean Long; hotspot compiler > Cc: ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net > Subject: Re: RFR (S) 8131682: C1 should use multibyte nops everywhere > > * PGP Signed by an unknown key > > (explicitly cc'ing AArch64 and PPC folks) > > Thanks, > -Aleksey > > On 22.07.2015 11:10, Aleksey Shipilev wrote: >> Thanks for review, Dean! >> >> I'd like to hear the opinions of AArch64 and Power folks, since we >> contaminate their assemblers a bit to gain access to x86 fat nops. >> >> -Aleksey >> >> On 21.07.2015 23:28, Dean Long wrote: >>> This version looks good. >>> >>> dl >>> >>> On 7/20/2015 7:51 AM, Aleksey Shipilev wrote: >>>> Hi Dean, >>>> >>>> Thanks for taking a look! >>>> >>>> Silly me, I should have left the call patching cases intact, because >>>> you're right, we should be able to patch the nops partially while still >>>> producing the correct instruction stream. Therefore, I reverted the >>>> cases where we do nop-ing for *instruction* patching, and added the >>>> comment there. >>>> >>>> Other places seem to use the nop sequences to provide the alignment, not >>>> for the general patching. Especially interesting for us is the case of >>>> aligning the patcheable immediate in the existing call. C2 does the nops >>>> in these cases. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~shade/8131682/webrev.01/ >>>> >>>> Testing: >>>> * JPRT -testset hotspot on open platforms; >>>> * Targeted benchmarks, plus eyeballing the assembly; >>>> >>>> Thanks, >>>> -Aleksey >>>> >>>> On 18.07.2015 10:51, Dean Long wrote: >>>>> I think we should distinguish the different uses and treat them >>>>> accordingly: >>>>> >>>>> 1) padding nops for patching, executed >>>>> >>>>> We need to be careful about inserting a fat nop here, if later patching >>>>> overwrites only part of the fat nop, resulting in an illegal intruction. >>>>> >>>>> 2) padding nops for patching, never executed >>>>> >>>>> It should be safe insert a fat nop here, but there's no point if the >>>>> nops are not reachable and never executed. >>>>> >>>>> >>>>> 3) alignment nops, never patched, executed >>>>> >>>>> Fat nops are fine, but on some CPUs branching may be even better, so I >>>>> suggest using align() for this, and letting align() decide what to >>>>> generate. The change in check_icache() could use a version of align >>>>> that takes the target offset as an argument: >>>>> >>>>> 348 align(CodeEntryAlignment,__ offset() + ic_cmp_size); >>>>> >>>>> 4) alignment nops, never patched, never executed >>>>> >>>>> Doesn't matter what we emit here, but we might as well make it >>>>> understandable by humans using a debugger. >>>>> >>>>> >>>>> I believe the patching nops in c1_CodeStubs_x86.cpp and >>>>> c1_LIRAssembler.cpp are patched concurrently while the code is running, >>>>> not at a safepoint, so it's not clear to me if it's safe to use fat nops >>>>> on x86. I would consider those changes unsafe on x86 without further >>>>> analysis of what happens during patching. >>>>> >>>>> dl >>>>> >>>>> On 7/17/2015 6:29 AM, Aleksey Shipilev wrote: >>>>>> Hi there, >>>>>> >>>>>> C1 is not very good at inlining and intrisifying methods, and hence the >>>>>> call performance is important there. One nit that we can see in the >>>>>> generated code on x86 is that C1 uses the single-byte nops, even for >>>>>> long nop strides. >>>>>> >>>>>> This improvement fixes that: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8131682 >>>>>> http://cr.openjdk.java.net/~shade/8131682/webrev.00/ >>>>>> >>>>>> Testing: >>>>>> - JPRT -testset hotspot on open platforms >>>>>> - eyeballing the generated assembly with -XX:TieredStopAtLevel=1 >>>>>> >>>>>> (I understand the symmetric change is going to be needed in closed >>>>>> parts, but let's polish the open part first). >>>>>> >>>>>> Thanks, >>>>>> -Aleksey >>>>>> >>>> >>> >> >> > > > > * Unknown Key > * 0x62A119A7 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From adinn at redhat.com Mon Jul 27 09:35:09 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 27 Jul 2015 10:35:09 +0100 Subject: [aarch64-port-dev ] RFR (S) 8131682: C1 should use multibyte nops everywhere In-Reply-To: <55B5F651.5090509@oracle.com> References: <55A9033C.2030302@oracle.com> <55AA0567.6070602@oracle.com> <55AD0AE0.3060803@oracle.com> <55AEAB5C.8050307@oracle.com> <55AF500B.9000505@oracle.com> <55B20A16.7020300@oracle.com> <4295855A5C1DE049A61835A1887419CC2D00A472@DEWDFEMB12A.global.corp.sap> <55B5F651.5090509@oracle.com> Message-ID: <55B5FB4D.4070603@redhat.com> On 27/07/15 10:13, Aleksey Shipilev wrote: > Thanks Goetz! Fixed the assembler_ppc.inline.hpp. > > Andrew/Edward, are you OK with AArch64 part? > http://cr.openjdk.java.net/~shade/8131682/webrev.02/ Yes, it's fine. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From aleksey.shipilev at oracle.com Mon Jul 27 10:53:20 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 27 Jul 2015 13:53:20 +0300 Subject: [aarch64-port-dev ] RFR (S) 8131682: C1 should use multibyte nops everywhere In-Reply-To: <55B6063B.3070604@redhat.com> References: <55A9033C.2030302@oracle.com> <55AA0567.6070602@oracle.com> <55AD0AE0.3060803@oracle.com> <55AEAB5C.8050307@oracle.com> <55AF500B.9000505@oracle.com> <55B20A16.7020300@oracle.com> <4295855A5C1DE049A61835A1887419CC2D00A472@DEWDFEMB12A.global.corp.sap> <55B5F651.5090509@oracle.com> <55B6063B.3070604@redhat.com> Message-ID: <55B60DA0.30501@oracle.com> On 07/27/2015 01:21 PM, Andrew Haley wrote: > On 27/07/15 10:13, Aleksey Shipilev wrote: >> Thanks Goetz! Fixed the assembler_ppc.inline.hpp. >> >> Andrew/Edward, are you OK with AArch64 part? >> http://cr.openjdk.java.net/~shade/8131682/webrev.02/ > > I agree that it looks good. Please have a look to see how many NOPs take the > same time as a branch. Thanks! I don't quite believe we should spend time trying branches for nops, at least for x86. The change we are discussing follows the Intel Optimization Reference Manual 3.5.1.10 "Using NOPs", which Assembler::align for x86 seems to implement with some bells and whistles. Agner agrees on using multi-byte nops (0F 1F ...) on modern x86 chips as well; up to the point he claims 4 insn/clock throughput for them. Is there a vendor-recommended strategy for using something else? Even if it's so, this calls for experimenting with Assembler::align itself (that also touches C2 usages), and not the C1-specific usages this trivial change addresses. Thanks again, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From aleksey.shipilev at oracle.com Wed Jul 29 14:01:00 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 29 Jul 2015 17:01:00 +0300 Subject: [aarch64-port-dev ] RFR (S) 8131682: C1 should use multibyte nops everywhere In-Reply-To: <55B6063B.3070604@redhat.com> References: <55A9033C.2030302@oracle.com> <55AA0567.6070602@oracle.com> <55AD0AE0.3060803@oracle.com> <55AEAB5C.8050307@oracle.com> <55AF500B.9000505@oracle.com> <55B20A16.7020300@oracle.com> <4295855A5C1DE049A61835A1887419CC2D00A472@DEWDFEMB12A.global.corp.sap> <55B5F651.5090509@oracle.com> <55B6063B.3070604@redhat.com> Message-ID: <55B8DC9C.7010003@oracle.com> On 07/27/2015 01:21 PM, Andrew Haley wrote: > On 27/07/15 10:13, Aleksey Shipilev wrote: >> Thanks Goetz! Fixed the assembler_ppc.inline.hpp. >> >> Andrew/Edward, are you OK with AArch64 part? >> http://cr.openjdk.java.net/~shade/8131682/webrev.02/ > > I agree that it looks good. So, we have reviews from Dean Long, Goetz Lindenmaier, Andrew Dinn, and Andrew Haley. Still no Capital (R)eviewers. Otherwise, I think we are good to go. I respinned the JPRT with open+closed sources, and it would seem the changes in closed sources are not required. Please review and sponsor! Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vladimir.x.ivanov at oracle.com Wed Jul 29 14:16:19 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 Jul 2015 17:16:19 +0300 Subject: [aarch64-port-dev ] RFR (S) 8131682: C1 should use multibyte nops everywhere In-Reply-To: <55B8DC9C.7010003@oracle.com> References: <55A9033C.2030302@oracle.com> <55AA0567.6070602@oracle.com> <55AD0AE0.3060803@oracle.com> <55AEAB5C.8050307@oracle.com> <55AF500B.9000505@oracle.com> <55B20A16.7020300@oracle.com> <4295855A5C1DE049A61835A1887419CC2D00A472@DEWDFEMB12A.global.corp.sap> <55B5F651.5090509@oracle.com> <55B6063B.3070604@redhat.com> <55B8DC9C.7010003@oracle.com> Message-ID: <55B8E033.4060900@oracle.com> Looks good. Best regards, Vladimir Ivanov On 7/29/15 5:01 PM, Aleksey Shipilev wrote: > On 07/27/2015 01:21 PM, Andrew Haley wrote: >> On 27/07/15 10:13, Aleksey Shipilev wrote: >>> Thanks Goetz! Fixed the assembler_ppc.inline.hpp. >>> >>> Andrew/Edward, are you OK with AArch64 part? >>> http://cr.openjdk.java.net/~shade/8131682/webrev.02/ >> >> I agree that it looks good. > > So, we have reviews from Dean Long, Goetz Lindenmaier, Andrew Dinn, and > Andrew Haley. Still no Capital (R)eviewers. > > Otherwise, I think we are good to go. I respinned the JPRT with > open+closed sources, and it would seem the changes in closed sources are > not required. > > Please review and sponsor! > > Thanks, > -Aleksey > > From dean.long at oracle.com Wed Jul 29 16:30:24 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 29 Jul 2015 09:30:24 -0700 Subject: [aarch64-port-dev ] RFR (S) 8131682: C1 should use multibyte nops everywhere In-Reply-To: <55B8DC9C.7010003@oracle.com> References: <55A9033C.2030302@oracle.com> <55AA0567.6070602@oracle.com> <55AD0AE0.3060803@oracle.com> <55AEAB5C.8050307@oracle.com> <55AF500B.9000505@oracle.com> <55B20A16.7020300@oracle.com> <4295855A5C1DE049A61835A1887419CC2D00A472@DEWDFEMB12A.global.corp.sap> <55B5F651.5090509@oracle.com> <55B6063B.3070604@redhat.com> <55B8DC9C.7010003@oracle.com> Message-ID: <55B8FFA0.4070105@oracle.com> On 7/29/2015 7:01 AM, Aleksey Shipilev wrote: > On 07/27/2015 01:21 PM, Andrew Haley wrote: >> On 27/07/15 10:13, Aleksey Shipilev wrote: >>> Thanks Goetz! Fixed the assembler_ppc.inline.hpp. >>> >>> Andrew/Edward, are you OK with AArch64 part? >>> http://cr.openjdk.java.net/~shade/8131682/webrev.02/ >> I agree that it looks good. > So, we have reviews from Dean Long, Goetz Lindenmaier, Andrew Dinn, and > Andrew Haley. Still no Capital (R)eviewers. > > Otherwise, I think we are good to go. I respinned the JPRT with > open+closed sources, and it would seem the changes in closed sources are > not required. The changes to sparc and ppc may not be required anymore. dl > Please review and sponsor! > > Thanks, > -Aleksey > > From martin.doerr at sap.com Thu Jul 30 13:48:36 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 30 Jul 2015 13:48:36 +0000 Subject: Linux PPC64LE: argument passing problem when passing 15 floats in native call Message-ID: <7C9B87B351A4BA4AA9EC95BB418116566AD4681E@DEWDFEMB19C.global.corp.sap> Hi all, seems like the ABIv2 calling convention needs different treatment for float arguments. The following native call test passes 15 float parameters, but the native code doesn't get them correctly: http://cr.openjdk.java.net/~goetz/webrevs/ppc64le_native_float_arg_test/ Adding 15 times 1.0f resulted in 13.0f on a LE machine. The BE machine correctly returns 15.0f. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: