[foreign-memaccess] on shared segments
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Fri Sep 27 12:36:07 UTC 2019
Ok, I've been looking at some HS code:
http://hg.openjdk.java.net/jdk/jdk/file/d10b732966ba/src/hotspot/share/opto/parse1.cpp#l1004
Seems like there's only a release fence there. So, yes, in principle
reads from thread A might be reordered after B accesses memory.
Maurizio
On 27/09/2019 13:12, Maurizio Cimadamore wrote:
>
> On 27/09/2019 12:54, Maurizio Cimadamore wrote:
>>
>> On 27/09/2019 11:46, Jorn Vernee wrote:
>>> Reading through the code, there is one caveat that doesn't seem to
>>> be addressed yet; only the owning thread can call asShared() or
>>> asConfined() (not being checked currently), and, at least for
>>> asConfined(), I think the owning thread has to submit to a full
>>> fence before transferring the segment to make sure no accesses
>>> 'spill over' into the new state.
>>
>> Right, I should add the checks.
>>
>> Not sure about the fence - I thought about that. We are creating a
>> _new_ object, and invalidating an old one. Only the old thread has
>> access to the old one, so it cannot possibly perform access on the
>> old segment AFTER it is closed. And, the new thread cannot access the
>> segment before the old thread is actually inside the transfer code
>> (which means he's done with the segment already).
>>
>> If we were modifying the ownership in place, I'd agree a fence would
>> be in order - but here?
>
> Yep - safe publication rules seem to cover it, see here
>
> https://shipilev.net/blog/2014/safe-public-construction/
>
> Since the Thread owner is a final field in the segment, the
> publication should be safe here...
>
> Maurizio
>
>>
>> Maurizio
>>
More information about the panama-dev
mailing list