aarch64: Concurrent class unloading, nmethod barriers, ZGC

[Stuart Monteith]

Hello Zhengyu, et al,
	This is the current state of the nmethod barrier code I have for ZGC on
aarch64. As I understand it, Zhengyu may have been working on this, and
so this is my sharing it:

	http://cr.openjdk.java.net/~smonteith/nmethod/webrev.0/

The code has various bits for debugging, prototype level code, with
comments and some notes interspersed throughout - it is not ready for
merging.

The approach I've taken for the nmethod barrier is to have the nmethod
barrier that is emitted be implemented like so:

  __ adr(rscratch1, __ pc());
  __ ldarw(rscratch2, rscratch1);
  __ ldrw(rscratch1, thread_disarmed_addr);
  __ cmpw(rscratch2, rscratch1);
  __ br(Assembler::EQ, continuation);

  __ mov(rscratch1, StubRoutines::aarch64::method_entry_barrier());
  __ blr(rscratch1);

 __ bind(continuation);


This code is patched up such that the ldarw is loading from a field I've
added to nmethod "_nmethod_guard". There don't appear to be existing
ways to emit a relocation (there aren't spare bits to do a small change)
from an address in nmethod emitted code into the nmethod data structure.
It is initialized to the instruction's current address and
BarrierSetNMethod::disarm will detect this known value and fix it up,
which occurs on initialization.

Currently the deoptmise path is broken. By setting the environment
variable "SRDM_forcedeopt", the deoptimisation can be provoked even when
not needed - the x86 implementation is good with this change. The
aarch64 code isn't working yet - I suspect I've followed the x86 code
too closely, and my offsets are perhaps miscalculated - I may be
pointing at the wrong frame, or I've neglected FP too much.

BR,
  Stuart