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

[David Holmes]

On 3/11/2014 10:05 AM, David Chase wrote:
>
> On 2014-10-31, at 5:45 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>> The volatile load prevents subsequent loads and stores from reordering with it, but that doesn't stop C from moving before the B store.  So breaking B into the load (call it BL) and store (BS) you can still get this ordering: A, BL, C, BS
>
> I think this should do the trick.
>
>                 element_data[oldCapacity] = element_data[oldCapacity - 1];
>                  // all array elements are non-null and sorted, increase size.
>                  // if store to element_data above floats below
>                  // store to size on the next line, that will be
>                  // inconsistent to the VM if a safepoint occurs here.
>                  size += 1;
>                  // Load of volatile size prevents movement of element_data store
>                  for (int i = size - 1; i > index; i--) {
>
> The change is to load the volatile size for the loop bound; this stops the stores
> in the loop from moving earlier, right?

Treating volatile accesses like memory barriers is playing a bit 
fast-and-loose with the spec+implementation. The basic happens-before 
relationship for volatiles states that if a volatile read sees a value 
X, then the volatile write that wrote X happened-before the read [1]. 
But in this code there are no checks of the values of the volatile 
fields. Instead you are relying on a volatile read "acting like 
acquire()" and a volatile write "acting like release()".

That said you are trying to "synchronize" the hotspot code with the JDK 
code so you have stepped outside the JMM in any case and reasoning about 
what is and is not allowed is somewhat moot - unless the hotspot code 
always uses Java-style accesses to the Java-level variables.

BTW the Java side of this needs to be reviewed on 
core-libs-dev at openjdk.java.net

David H.

[1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4.4


> David
>