RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames
vitalyd at gmail.com
Fri Oct 31 21:45:38 UTC 2014
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>
> > 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
> is a global safepoint — officially I have no guarantee that the compiler
> put that somewhere inconvenient for me which is why I have to code
> and worry about what the compiler might do, but I do assume that if the
> 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
> 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
> I also added converted Christian’s test code into a jtreg test (which
> I am not excited about adding a level of indirection and converting all
> to jmethodid — are there other opinions here? I’ve attempted to confine
> and document the race-sensitive ugliness.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev