aarch64: Concurrent class unloading, nmethod barriers, ZGC

Stuart Monteith stuart.monteith at linaro.org
Wed Jan 8 14:23:27 UTC 2020


Hi,
 I see there is LIR_Assembler::int_constant, which is only for C1, the
equivalent is MacroAssembler::ldr_constant, which uses an
InternalAddress.  I had looked at doing that first, however I had an
issue getting the address of the constants. The _consts CodeSection
information exists in the CodeBuffer when the code is being generated,
but I hadn't worked out after that point where the constant would be
after the relocation, which is what we'd need when arming/disarming
the guard, from which we have to navigate from the nmethod class.  My
assumption was that the nmethod would consist of the header,followed
by the relocations, followed by the code section which would include
the consts, and that my constant might be one of the first ones. I
don't believe I could make that a consistent address.  I chose to put
the guard into the nmethod data structure itself, but that of course
meant we had to check whether or not the guard needs initialized -
although I was thinking we could add an additional initialization
stage.

It occurs to me now that we could pull out the address of the guard
from the ADR instruction, as that will be relocated and we know its
location, and could do that unconditionally. I'll revisit using the
constants, as maybe the address of it is more deterministic than I
first thought.

Thanks,
   Stuart



On Wed, 8 Jan 2020 at 10:10, Andrew Haley <aph at redhat.com> wrote:
>
> On 1/7/20 11:34 PM, Stuart Monteith wrote:
> > 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.
>
> Yeah, there is. See MacroAssembler::int_constant.
>
> --
> 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