Andrew Haley reported via e-mail:
On 8/2/16 6:25 PM, David Holmes wrote:
> Hi Andrew,
>
> On 3/08/2016 10:04 AM, Andrew Haley wrote:
>> Here's an interesting comment:
>>
>> static inline void transition_and_fence(JavaThread *thread, JavaThreadState from, JavaThreadState to) {
>> assert(thread->thread_state() == from, "coming from wrong thread state");
>> assert((from & 1) == 0 && (to & 1) == 0, "odd numbers are transitions states");
>> // Change to transition state (assumes total store ordering! -Urs)
>> thread->set_thread_state((JavaThreadState)(from + 1));
>>
>> The "assumes total store ordering!" comment is rather alarming. My
>> processor is not TSO. But as far as I can see, all this really
>> requires is single-variable coherency. Is that right?
>
> That comment is pre-historic. The code does not assume TSO. There is a direct, or implicit, full fence between the two stores:
>
> // Make sure new state is seen by VM thread
> if (os::is_MP()) {
> if (UseMembar) {
> // Force a fence between the write above and read below
> OrderAccess::fence();
> } else {
> // Must use this rather than serialization page in particular on Windows
> InterfaceSupport::serialize_memory(thread);
> }
> }
>
> Cheers,
> David
See http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024090.html
On 8/2/16 6:25 PM, David Holmes wrote:
> Hi Andrew,
>
> On 3/08/2016 10:04 AM, Andrew Haley wrote:
>> Here's an interesting comment:
>>
>> static inline void transition_and_fence(JavaThread *thread, JavaThreadState from, JavaThreadState to) {
>> assert(thread->thread_state() == from, "coming from wrong thread state");
>> assert((from & 1) == 0 && (to & 1) == 0, "odd numbers are transitions states");
>> // Change to transition state (assumes total store ordering! -Urs)
>> thread->set_thread_state((JavaThreadState)(from + 1));
>>
>> The "assumes total store ordering!" comment is rather alarming. My
>> processor is not TSO. But as far as I can see, all this really
>> requires is single-variable coherency. Is that right?
>
> That comment is pre-historic. The code does not assume TSO. There is a direct, or implicit, full fence between the two stores:
>
> // Make sure new state is seen by VM thread
> if (os::is_MP()) {
> if (UseMembar) {
> // Force a fence between the write above and read below
> OrderAccess::fence();
> } else {
> // Must use this rather than serialization page in particular on Windows
> InterfaceSupport::serialize_memory(thread);
> }
> }
>
> Cheers,
> David
See http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024090.html