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

[David Holmes]

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.

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.

Happy to be corrected on this.

Cheers,
David H.


>>> Despite reading the code for some time I've been unable to figure
>>> out how the serialization page is supposed to work.
>>
>> Try this:
>>
>> http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt
>
> Ah, thanks.
>
> Andrew.
>