A question on endGroupNode

Mon Feb 6 19:44:17 UTC 2017

Hi Martin,

On 03-02-2017 07:53, Doerr, Martin wrote:
> Hi Gustavo,
> 
> the undesired endgroup instructions were generated by MacroAssembler::set_dest_of_bc_far_at. I had done some cleanup work when implementing and contributing C1. The following change removed these instructions and adapted MacroAssembler::get_dest_of_bc_far_at:
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/4a24de859a87

Thanks a lot for pointing that out.

> 
> I don't think replacing these few endgroup by the preferred nop instructions will show a measurable performance benefit, so we didn't backport it.

Hm, right. That's what colleagues were questioning me about. Thanks for clarifying that in advance :-)

Best regards,
Gustavo

> 
> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] 
> Sent: Donnerstag, 2. Februar 2017 19:20
> To: Doerr, Martin <martin.doerr at sap.com>; ppc-aix-port-dev at openjdk.java.net
> Subject: Re: A question on endGroupNode
> 
> Hi Martin,
> 
> On 01-02-2017 11:19, Doerr, Martin wrote:
>> Hi Gustavo,
>>
>> I can't see how endGroup nodes can get generated in the current jdk9 code.
>> If I remember correctly, endgroup instructions were emitted in conditional long branches when the branch destination is near. But this code is gone in the current jdk9 code.
>> Are you using an older version?
> 
> Yes, the ori r1,r1,0 on Hive was collected from 8. It's OpenJDK 8 on RHEL 7.2:
> 
> java -version
> openjdk version "1.8.0_111"
> OpenJDK Runtime Environment (build 1.8.0_111-b15) OpenJDK 64-Bit Server VM (build 25.111-b15, mixed mode)
> 
> java-1.8.0-openjdk.ppc64le 1:1.8.0.111-1.b15.el7_2 @local-rhn-server-os java-1.8.0-openjdk-devel.ppc64le 1:1.8.0.111-1.b15.el7_2 @local-rhn-server-os java-1.8.0-openjdk-headless.ppc64le 1:1.8.0.111-1.b15.el7_2 @local-rhn-server-os
> 
> Red Hat packages OpenJDK 8 from:
> http://hg.openjdk.java.net/aarch64-port/jdk8u/tags (tag: aarch64-jdk8u111-b15), that by its turn derives from tag jdk8u102-b14 on jdk8u/jdk8u, so it brings at least all the changes in jdk8u/jdk8u tag jdk8u102-b14.
> 
> When I used the SPECjvm2008 (plus -XX:+PrintOptoAssembly) to find out other occurrences of ori r1,r1,0 (without success) I used jdk8u/jdk8u tip.
> 
> However I could not find a change on jdk8u/jdk8u regarding the endGroupNode specifically.
> 
> On 9, your patch "8170991: PPC64: Bad code for initialization of short arrays"
> removed the emission of it by removing the call to endgroup() in
> MacroAssembler::clear_memory_doubleword() but in that case the ori r1,r1,0 would be preceded by a bdnz instruction and not beq or bge. But even so, it's guarded by if (InsertEndGroupPPC64), which is by default false.
> 
> I don't know yet from which case the ori r1,r1,0 in question comes from. I'll try to run Hive against a debug build with -XX:+PrintOptoAssembly to check if the annotation revels its origin exactly. I understand it comes from a C2 compilation.
> 
> 
>> The purpose of endgroup instructions is to optimize for Power6. They should get inserted before control flow merge points if the instruction group is not already completed. We have a special Power6 instruction scheduler which takes care of that, but we haven't contributed it. I guess Power6 optimization is not so relevant any more.
> hm, right.
> 
> Thanks!
> 
> 
> Best regards,
> Gustavo
> 
>>
>> Best regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: ppc-aix-port-dev 
>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of 
>> Gustavo Romero
>> Sent: Dienstag, 31. Januar 2017 12:19
>> To: ppc-aix-port-dev at openjdk.java.net
>> Subject: A question on endGroupNode
>> Importance: High
>>
>> Hi,
>>
>> Sometimes the JVM on PPC64 puts a group ending nop (ori r1,r1,0) after 
>> conditional branches, like, for instance, the following assembly 
>> sequence from
>> C2 generated from Hive code:
>>
>>    379 6.6e-04 :    10000980436c:       lwz     r14,16(r6)
>>    816  0.0014 :    100009804370:       cmplw   cr6,r7,r14
>>                :    100009804374:       bge     cr6,100009804ee8
>>                :    100009804378:       ori     r1,r1,0   <=== endGroup
>>    167 2.9e-04 :    10000980437c:       add     r15,r7,r8
>>    892  0.0015 :    100009804380:       addi    r17,r15,-1
>>                :    100009804384:       cmplw   cr5,r17,r14
>>                :    100009804388:       bge     cr5,100009804ee8
>>    262 4.5e-04 :    10000980438c:       ori     r1,r1,0   <=== endGroup
>>    648  0.0011 :    100009804390:       li      r14,0
>>                :    100009804394:       cmpld   cr6,r5,r14
>>                :    100009804398:       beq     cr6,100009804ee8
>>    267 4.6e-04 :    10000980439c:       ori     r1,r1,0   <=== endGroup
>>    930  0.0016 :    1000098043a0:       addis   r20,r29,384
>>                :    1000098043a4:       addi    r20,r20,16384
>>
>> The (ori r1, r1, 0) seems to be emitted from a endGroupNode defined in:
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/6c1e79a99176/src/cpu/p
>> pc/vm/ppc.ad#l13261
>>
>> Nonetheless, I could not generated any endGroupNode using SPECjvm2008 (i.e.
>> looking at the log from -XX:+PrintOptoAssembly there is no "End Bundle" anywhere).
>>
>> Any idea why it exists primarily and if there is any option to control its emission or even a particular way to avoid the creation of an endGroupNode?
>>
>> Thank you.
>>
>>
>> Best regards,
>> Gustavo
>>
> 