RFC: 64 bit literal oops

Stuart Monteith stuart.monteith at linaro.org
Tue Oct 2 21:54:42 UTC 2018


Hello,
   I've been testing my patch to make literal oops 64-bit rather than
48-bit. This is a necessary prerequisite for ZGC to operate on aarch64
using tagged pointers. I'm not submitting this in it's final form, but
just for a view on whether this is the proper way to do this.

The patch is here:
http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/

I've tested it against jtreg and G1GC, and get clean results as
compared to without the patch. No issues are apparent running
SPECjbb-2015.

There are essentially 7 changes:
   1. There is a new options: -XX:+Use64BitLiteralOops
   2. MacroAssembler::patch_oop(address,address) patches 64-bit
addresses if the flag is enabled.
   3.  MacroAssembler::target_addr_for_insn(address, unsigned) is
modified to pull out a 64-bit target address, if there is an extra
movk, and then calls ShouldNotReachHere().
   4. MacroAssembler::mov(Register, Address) has been changed to call
movptr with a flag set if the address is an Oop.
   5.  MacroAssembler::movptr(Register, uintptr_t) has been modified
to take a flag indicating if it is an oop that is being emitted. If
Use64BitLiteralOops has been set, then an additional movk is emitted
to make up the 64 bit literal.
   6. NativeInstruction::is_oop_at(int) was added, to detect if an oop
exists at the address.
   7. NativeMovConstReg::next_instruction_address() has been changed
to handle get the address after "movz, movk, movk" and with 64 bit
oops "movz, movk, movk, movk."

(6) has never been observed,, so I don't consider it tested - there
aren't circumstances where it returns true, so arguably it it should
be replaced by an appropriate assert.
Likewise, (3) is also an unnecessary change - the ShouldNotReachHere()
never traps during testing - it was left in for review purposes.

It has been mentioned to me that we could just use 64-bit literals, as
that would make things simpler - I look forward to people's opinions.
It was also mentioned ages ago that in future the coloured bits could
be made irrelevant for ZGC.

There is the up and coming 52-bit VA scheme for Arm v8. If we are to
use >48 bits of address space we will have to ask for it explicitly,
in which case we'd need to use 64 bit oops. The class metadata could
remain 48-bit in that case. There is an interesting presentation on
52-bit VA here: https://connect.linaro.org/resources/yvr18/yvr18-119/

BR,
    Stuart


More information about the zgc-dev mailing list