Unasafe.putOdered -> Unsafe.releasePut

[David Holmes]

On 10/03/2015 6:32 PM, Paul Sandoz wrote:
> On Mar 10, 2015, at 3:06 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> So for example, j.u.c.atomic lazySet is defined as providing:
>>>>
>>>> *   <li> {@code lazySet} has the memory effects of writing (assigning)
>>>> *   a {@code volatile} variable except that it permits reorderings with
>>>> *   subsequent (but not previous) memory actions that do not themselves
>>>> *   impose reordering constraints with ordinary non-{@code volatile}
>>>> *   writes.
>>>>
>>>> and is implemented by a call to Unsafe.putOrdered, which in turn is implemented by doing a full volatile write, which is OrderAccess::release_store_fence.
>>>
>>> I don't observe that from looking at the C2 code, nor from the generated x86 code. Its implemented like a release_store and used accordingly with that in mind.
>>
>> I was referring to the non-intrinsified version of Unsafe:
>>
>> // The non-intrinsified versions of setOrdered just use setVolatile
>>
>> UNSAFE_ENTRY(void, Unsafe_SetOrderedInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint x))
>>   UnsafeWrapper("Unsafe_SetOrderedInt");
>>   SET_FIELD_VOLATILE(obj, offset, jint, x);
>> UNSAFE_END
>>
>> and IIRC that was something Martin complained about a few weeks back.
>>
>
> Ah! ok.
>
>
>> Okay in that case aligning the names makes more sense - and we should fix the the non-intrinsic form. :)
>>
>
> When would that non-intrinsified version be used, just for the interpreter?

Yes.

> I suppose it could be changed, but it does not seem absolutely necessary to do so. What's currently there seems a pragmatic solution to me given what happens when C1/C2 kick in.

No not essential to fix when you have the JIT - may be more of a concern 
in interpreter only environments.

David

> Paul.
>