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

[David Chase]

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?

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20141102/f1d99dba/signature.asc>