[aarch64-port-dev ] Changes to JavaThread::_thread_state must use acquire and release

Andrew Dinn adinn at redhat.com
Mon Jan 19 10:48:08 UTC 2015


On 15/01/15 13:29, Andrew Haley wrote:
> The GC threads interact with changes to thread_state such that all
> accesses must be ordered.  In addition, we were incorrectly accessing
> thread_state as a doubleword in a few places.

I noticed that templateInterpreter_aarch64.cpp generates a read of the
thread_state field under InterpreterGenerator::generate_native_entry
when inserting a (debug build-only) sanity check:

    // change thread state
  #ifdef ASSERT
    {
      Label L;
==>   __ ldrw(t, Address(rthread, JavaThread::thread_state_offset()));
      __ cmp(t, _thread_in_Java);
      __ br(Assembler::EQ, L);
      __ stop("Wrong thread state in native stub");
      __ bind(L);
    }
  #endif


    // Change state to native
    __ mov(rscratch1, _thread_in_native);
    __ lea(rscratch2, Address(rthread, JavaThread::thread_state_offset()));
    __ stlrw(rscratch1, rscratch2);

Is it ok for that read to be ldrw or ought it to be ldarw? If all is ok
then I think it is safe to use an ldrw but the point of this code is to
find cases where something is rotten in the state of Danmark . . .

regards,


Andrew Dinn
-----------



More information about the aarch64-port-dev mailing list