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

[Aleksey Shipilev]

On 31.10.2014 00:17, David Chase wrote:
> 0) The code that guards against concurrent redefinition has some stores that should not
> be reordered by the (hotspot) compiler.  They take the form:
>    A : store
>    B : volatile store
>    C : store
> Am I okay?  Or do I need to do more than just a volatile store in the middle?  (A and C are
> stores to array elements, so I can’t trivially make them volatile.)  Yes, there is a big wordy
> comment where this happens.

JMM-wise, that sequence of stores is "reorderable" into ACB and CAB.
Even if compiler does not reorder, weakly ordered architectures might do
that for you under cover. Since you are already on mostly-VM side of
things, you are better off doing the explicit Unsafe.*fence-s?

However, I fail to match your example to your code. Where's A, B, C?

I can guess:
  A: "element_data[oldCap] = element_data[oldCap-1]"
  B: "size++" // note: this is BOTH volatile read and volatile store
  C: "element_data[i] = element_data[i-1]" ???

Thanks,
-Aleksey.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20141031/86eadfcc/signature.asc>