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

[Lindenmaier, Goetz]

Hi David, 

this are the instrinsics for sun/misc/Unsafe, which are documented
as shown below.  So I guess that's just what is desired.

Best regards,
  Goetz.

    /**
     * Ensures lack of reordering of loads before the fence
     * with loads or stores after the fence.
     * @since 1.8
     */
    public native void loadFence();

    /**
     * Ensures lack of reordering of stores before the fence
     * with loads or stores after the fence.
     * @since 1.8
     */
    public native void storeFence();

    /**
     * Ensures lack of reordering of loads or stores before the fence
     * with loads or stores after the fence.
     * @since 1.8
     */
    public native void fullFence();



-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Tuesday, November 19, 2013 8:08 PM
To: Lindenmaier, Goetz
Cc: Vladimir Kozlov; '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.

So I like the rename but I am concerned there are semantic issues here:

    switch(id) {
      case vmIntrinsics::_loadFence:
-      insert_mem_bar(Op_MemBarAcquire);
+      insert_mem_bar(Op_MemBarFenceAcquire);
        return true;
      case vmIntrinsics::_storeFence:
-      insert_mem_bar(Op_MemBarRelease);
+      insert_mem_bar(Op_MemBarFenceRelease);
        return true;

What is a _loadFence operation? Does it really map to 
MembarFenceAcquire? Ditto for the _storeFence. These sound like 
bi-directional fences - are they? Are they really only concerned with 
loads or stores ?

David

On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> I made a new webrev, using the new names:
> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/
>
> Thanks,
>    Goetz.
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Montag, 18. November 2013 23:28
> To: Lindenmaier, Goetz; 'David Holmes'
> Cc: '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.
>
> 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.
>>>>