[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