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

[Vladimir Kozlov]

On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote:
> 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.

Okay.

Vladimir

>
> 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.
>>>