[9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames

[David Chase]

On 2014-11-03, at 11:42 AM, Peter Levart <peter.levart at gmail.com> 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