aarch64: Concurrent class unloading, nmethod barriers, ZGC

Stuart Monteith stuart.monteith at linaro.org
Fri Jan 10 16:56:16 UTC 2020

   Something like "adr(rscratch1, InternalAddress(nmethod field))" has
been suggested before. My problem has been finding what the address of
the nmethod fields would be without knowing where the instruction is
relative to them before the nmethod has been allocated. Relocations
can be performed between the sections  - constants, instructions and
stubs - with section_word_Relocation instead of
internal_word_Relocation. However, there doesn't appear to be a
concept for the CodeBlob header during code emissions.

If we have a method here:

 total in heap  [0x0000ffff68e0b010,0x0000ffff68e0b410] = 1024
 relocation     [0x0000ffff68e0b190,0x0000ffff68e0b1a8] = 24
 main code      [0x0000ffff68e0b1c0,0x0000ffff68e0b300] = 320
 stub code      [0x0000ffff68e0b300,0x0000ffff68e0b3a0] = 160
 metadata       [0x0000ffff68e0b3a0,0x0000ffff68e0b3b8] = 24
 scopes data    [0x0000ffff68e0b3b8,0x0000ffff68e0b3c8] = 16
 scopes pcs     [0x0000ffff68e0b3c8,0x0000ffff68e0b408] = 64
 dependencies   [0x0000ffff68e0b408,0x0000ffff68e0b410] = 8

The nmethod structure is at 0x0000ffff68e0b010. Between that address
and the main code is the relocation section, which we don't know the
size of during instruction emission into the CodeBuffer.
It appears that to relocate references to the nmethod structure from
the code section before the nmethod is constructed would require its
own relocation of sorts. I'm looking at adding a HEADER CodeSection
that would allow relocation of entries into the nmethod/CodeBlob
header.  There is no guarantee our CodeBuffer has a CodeBlob during
instruction emission - I've not looked to see whether that would be


On Thu, 9 Jan 2020 at 16:14, Andrew Haley <aph at redhat.com> wrote:
> On 1/9/20 4:02 PM, Stuart Monteith wrote:
> > 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
> > unloaded.
> OK, so we can stick with a field in nmethod. It is probably more economical
> on space anyway.
> You should be able to use adr(rscratch1, InternalAddress(nmethod field));
> --
> 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