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

[Vitaly Davidovich]

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

Sent from my phone
On Oct 31, 2014 2:11 PM, "David Chase" <david.r.chase at oracle.com> wrote:

>
> On 2014-10-31, at 1:09 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com>
> wrote:
> > 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]" ???
>
> That is the correct values of A/B/C — I missed the volatile read.
> Does the combined volatile read and volatile write get me what I need,
> or do I still need to drop a barrier in there?
>
> I’m not worried about architectural reordering, because the concurrent
> event
> is a global safepoint — officially I have no guarantee that the compiler
> won’t
> put that somewhere inconvenient for me which is why I have to code
> carefully
> and worry about what the compiler might do, but I do assume that if the
> safepoint
> occurs, all writes that nominally precede it will in fact complete before
> jvm code
> is entered.  (Note that this is a vanishingly rare but still possible
> event — it
> requires intern of a previously non-interned MemberName racing with class
> redefinition.)
>
> I found a lurking bug and updated the webrevs — I was mistaken
> about this version having passed the ute tests (but now, for real, it
> does).
>
> I also added converted Christian’s test code into a jtreg test (which
> passes):
>
> http://cr.openjdk.java.net/~drchase/8013267/hotspot.05/
> http://cr.openjdk.java.net/~drchase/8013267/jdk.05/
>
> I am not excited about adding a level of indirection and converting all
> this
> to jmethodid — are there other opinions here?  I’ve attempted to confine
> and document the race-sensitive ugliness.
>
> David
>
>