[aarch64-port-dev ] AARCH64 stage: next steps

[Andrew Haley]

On 23/01/15 09:55, David Holmes wrote:
> On 23/01/2015 7:29 PM, Andrew Haley wrote:
>> On 23/01/15 02:10, David Holmes wrote:
>>> On 22/01/2015 9:17 PM, Andrew Haley wrote:
>>>> On 01/22/2015 10:12 AM, David Holmes wrote:
>>>>> Yes this is a badly documented flag. While originally (when we only had
>>>>> TSO systems) it allowed you to switch between the memory serialization
>>>>> pseudo-membar trick and full membars/fences,  you need UseMembar for any
>>>>> platform for which the memory serialization trick is not guaranteed to
>>>>> work. As we have discussed before we consider that to be any non-TSO
>>>>> platform, but PPC64 decided otherwise (did Aarch64 do the same?). :)
>>>>
>>>> UseMembar is enabled by default on AArch64.
>>>
>>> Then you don't need to use the thread_state()/set_thread_state()
>>> variants that PPC64 uses.
>>
>> Sorry, I still don't get it.  What's the connection?  The thread state
>> change needs to be communicated from the mutator thread to the
>> collector thread.  Without an acquire in thread_state() the collector
>> won't see the state change.  Also, the thread state is set in three
>> places during a native method but there is only one write to the
>> serialization page.
> 
> What are the mutator threads and collector threads you are referring to 
> here? Sorry if I missed the context. The primary use of thread_state is 
> for managing the safepoint mechanism, which is done via the 
> interfaceSupport routines, which in turn uses (potentially) the 
> serialization page to ensure communication, or else membars. The 
> accesses to thread_state within those routines should not need any 
> additional barriers.

But what is the point of changing thread_state is no other thread
needs to see it?

> As I said during the PPC64 review if there is some other code that is 
> utilizing thread_state separately then that code may need additional 
> barriers. My objection was to putting them inside the accessors because 
> they were then used in contexts where they were not needed.

Okay, I'll ask the question explicitly: if only a single thread_state
change needs to be visible, why change it three times?

Andrew.