[aarch64-port-dev ] AARCH64 stage: next steps
aph at redhat.com
Fri Jan 23 10:09:43 UTC 2015
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?
More information about the hotspot-runtime-dev