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

[David Chase]

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

-------------- 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/20141031/15754927/signature.asc>