On 2014-11-03, at 11:42 AM, Peter Levart <[email protected]> wrote:
>> 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.
>>
>> 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();
> You might need a storeFence() between each two writes into the array too.
> Your moving loop is the following:
>
> 2544 for (int i = oldCapacity; i > index; i--) {
> 2545 // pre: element_data[i] is duplicated at [i+1]
> 2546 element_data[i] = element_data[i - 1];
> 2547 // post: element_data[i-1] is duplicated at [i]
> 2548 }
>
>
> If we start unrolling, it becomes:
>
> w1: element_data[old_capacity - 0] = element_data[old_capacity - 1];
> w2: element_data[old_capacity - 1] = element_data[old_capacity - 2];
> w3: element_data[old_capacity - 2] = element_data[old_capacity - 3];
> ...
>
> Can compiler reorder w2 and w3 (just writes - not the whole statements)? Say
> that it reads a chunk of elements into the registers and then writes them
> out, but in different order, and a check for safepoint comes inside this
> chunk of writes... This is hypothetical, but it could do it without breaking
> the local semantics…
I think you are right, certainly in theory, and if I don’t hear someone else
declaring that in practice we’re both just being paranoid, I’ll do that too.
Seems like it might eventually slow things down to do all those fences.
David
