RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide.

[Lindenmaier, Goetz]

Hi David, Vladimir,

I also would prefer MemBarFenceAquire/Release, for two reasons
 - the same prefix shows they are all similar nodes.
 - I don't have to change MemBarVolatile to FullFence, which I didn't
   change yet and which is used in more places.

Best regards,
  Goetz.

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Monday, November 18, 2013 10:49 PM
To: Vladimir Kozlov
Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide.

Vladimir,

On 19/11/2013 5:36 AM, Vladimir Kozlov wrote:
> I think David asked for different nodes not just one.
> We can have new membar nodes with names matching Unsafe methods names:
> LoadFence, StoreFence, FullFence. I am fine with it.

But I don't think that actually describes them - they don't distinguish 
between loads and stores only the direction in which the barrier 
operates. "acquire" only allows accesses to move below it; "release" 
only allows accesses to move above it ie:

load a
store b, c
acquire();
load d
store e,f
release();
load g
store h, i

allows the loads of 'a' and 'g' to move into the  region between acquire 
and release; similarly for the stores to b and h. But the load of d nor 
the store to e can not move in relation to either acquire or release.

Thanks,
David

> MemBar and Fence have similar meaning so lets don't mix them in node names.
>
> Thanks,
> Vladimir
>
> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote:
>> Hi David,
>>
>> as reply to your comment on the bug:
>>
>> Well, I sitll would need 2 different nodes, as on PPC we do
>>    MemBarAcquireWide --> lwsync
>>    MemBarReleaseWide --> lwsync
>>    MemBarVolatile      --> sync.
>> On Sparc, you even do 3 different operations.
>>
>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease?
>> This all depends a lot on the available instructions of the processors.
>> Therefore I think a really clean representation that, at the same
>> time, allows
>> to find the cheapest set of instructions to express it on all
>> processors, is impossible.
>>
>> Best regards,
>>    Goetz
>>
>> PS:  Should I respond to comments in the bug right in the bug
>> or on the mailing lists?
>>
>>
>>
>>
>>
>>
>>
>>
>> From: ppc-aix-port-dev-bounces at openjdk.java.net
>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of
>> Lindenmaier, Goetz
>> Sent: Montag, 18. November 2013 15:19
>> To: 'hotspot-dev at openjdk.java.net';
>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov
>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce
>> MemBarAcquire/ReleaseWide.
>>
>> Hi,
>>
>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory
>> ordering in various places. Some order a certain load/store with other
>> operations. Inline_unsafe_fence() inserts MemBars that do not
>> correspont to a memory operation. So far, the same nodes were used.
>>
>> This change introduces MemBarAcquire/ReleaseWide to use where no
>> dedicated load/store is ordered. With this change, these nodes can be
>> matched differently, what is needed on PPC64.
>>
>> When reviewing 8024921 (part 113) we decided to avoid #defines in
>> inline_unsafe_fence() and to introduce new MemBar operations.
>>
>> Please review and test this change.
>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/
>>
>> Best regards,
>>    Goetz.
>>