[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