RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide.
David Holmes
david.holmes at oracle.com
Tue Nov 19 11:50:38 PST 2013
On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote:
> 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.
I don't think so! What is described for Unsafe are full bi-directional
fences and "acquire" and "release" are only uni-directional fences!
David
-----
> 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.
>>>>>
More information about the ppc-aix-port-dev
mailing list