[9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames
David Chase
david.r.chase at oracle.com
Fri Oct 31 18:11:23 UTC 2014
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
More information about the hotspot-runtime-dev
mailing list