Unasafe.putOdered -> Unsafe.releasePut

[Paul Sandoz]

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?

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.

Paul.