RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide.
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Wed Nov 20 01:37:22 PST 2013
Hi David,
I don't know what you mean by uni/bi-directional.
I guess we agree that the documentation of the intrinsics, let's take loadFence
for an example, talks about loads before the loadFence, and stores and loads after it:
loads
------------loadFence()--------------
loads, stores
With this, you can achieve any ordering by moving nodes up OR down:
Op1 Move Op1 Op2
Op2 down -------------
--------- =========> Op3
Op3 Op1
Alternatively, you can move op3 up, and get the same order:
Op1 Reorder Op2 Move Op3 Op2
Op2 Ops 1 and 2 Op1 up Op3
--------- =========> -------------- =========> Op1
Op3 Not restricted Op3 ----------
by later loadFence
So, if the operation restricts only moves in one direction, it's of no help because
you can still get an execution order you did not expect. So unidirectional operations
(e.g., only hindering operations from moving up) are pointless.
By the way, are you questioning whether the implementation is correct, or
whether the names express what is desired?
If it's the first, it's of no concern to this change, which is only about
matching these operations independently from those, that address
a dedicated memory operation.
If It's the second, please tell me what names to use, and I'll fix it.
(I hope you can properly read the 'drawings')
Best regards,
Goetz.
-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com]
Sent: Dienstag, 19. November 2013 20:51
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.
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>
>>>>> [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.
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20131120/3cf64bc0/attachment-0001.html
More information about the ppc-aix-port-dev
mailing list