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

[David Chase]

>> 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();

-------------- 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/20141103/92ec9f3f/signature.asc>