aarch64: Concurrent class unloading, nmethod barriers, ZGC

[Zhengyu Gu]

Hi Stuart,

Thanks for sharing.

Actually, Andrew Haley (cc'd) is helping us on implementing nmethod 
entry barrier.

Your patch is largely inline with what we have right now, but Andrew 
seems to have second thoughts :-)

-Zhengyu

On 1/7/20 6:34 PM, Stuart Monteith wrote:
> 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
>