>> My main concern is that the compiler is inhibited from any peculiar code
>> motion; I assume that taking a safe point has a bit of barrier built into it
>> anyway, especially given that the worry case is safepoint + JVMTI.
>>
>> Given the worry, what’s the best way to spell “barrier” here?
>> I could synchronize on classData (it would be a recursive lock in the
>> current version of the code)
>> synchronized (this) { size++; }
>> or I could synchronize on elementData (no longer used for a lock elsewhere,
>> so always uncontended)
>> synchronized (elementData) { size++; }
>> or is there some Unsafe thing that would be better?
>
> You're worried that writes moving array elements up for one slot would bubble
> up before write of size = size+1, right? If that happens, VM could skip an
> existing (last) element and not update it.
exactly, with the restriction that it would be compiler-induced bubbling, not
architectural.
Which is both better, and worse — I don’t have to worry about crazy hardware,
but the rules
of java/jvm "memory model" are not as thoroughly defined as those for java
itself.
I added a method to Atomic (.storeFence() ). New webrev to come after I
rebuild and retest.
Thanks much,
David
> It seems that Unsafe.storeFence() between size++ and moving of elements could
> do, as the javadoc for it says:
>
> /**
> * Ensures lack of reordering of stores before the fence
> * with loads or stores after the fence.
> * @since 1.8
> */
> public native void storeFence();
