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

[David Holmes]

On 23/01/2015 8:09 PM, Andrew Haley wrote:
> 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?

The VMThread needs to see it for the safepoint protocol.

>> 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?

The safepoint protocol uses dekker-style coordination between the 
VMThread and the other threads to avoid needing coarse locking for 
safepoints.

David
-----

> Andrew.
>