aarch64: Concurrent class unloading, nmethod barriers, ZGC

Stuart Monteith stuart.monteith at linaro.org
Thu Jan 9 16:02:35 UTC 2020

Thank you Andrew, that compiles and runs without error - the
deoptimize method is definitely being provoked. and continues without
apparent problems.

I've been trying to insert constants, and the issue you mention is
tripped when we enter a native method wrapper. Eric can perhaps
correct me, but I presume we might have to deoptimise a native method
if it was overriding a JIT-compiled method and it is subsequently been

In x86 it is inserted here:
on aarch64 I added the change in our generate_native_wrapper.


On Wed, 8 Jan 2020 at 15:37, Andrew Haley <aph at redhat.com> wrote:
> On 1/8/20 2:23 PM, Stuart Monteith wrote:
> >  I see there is LIR_Assembler::int_constant, which is only for C1, the
> > equivalent is MacroAssembler::ldr_constant, which uses an
> > InternalAddress.
> There is MacroAssembler::int_constant(n). It is there, and it returns an
> address that you can use with ADR and/or LDR . It won't work with a native
> method because they have no constant pool (int_constant() will return NULL)
> but I don't think you need barriers for native methods.
> (Um, perhaps you do, for synchronized ones? They have a reference to a class.)
> Anyway, this is your patch with a working (probably) deoptimize handler:
> http://cr.openjdk.java.net/~aph/aarch64-jdk-nmethod-barriers-3.patch
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-gc-dev mailing list