[9] RFR(S): 8071654: disassembler handles embedded OOPs not uniformly

Tobias Hartmann tobias.hartmann at oracle.com
Thu Jan 29 08:36:04 UTC 2015

Hi Zoltan,

looks good to me (not a reviewer).

Maybe you should change the bug type to "enhancement" to clarify that there is
no error in the current implementation but dead code is removed instead of being

I assume you'll close JDK-8066438 after pushing this, right?


On 28.01.2015 16:51, Zoltán Majó wrote:
> Hi,
> please review the following small patch.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071654
> Problem: The disassembler has two different ways of handling OOPs embedded into
> instructions.
> 1) Embedded OOPs are printed in hexadecimal within a disassembled instruction.
> The comment block following the instruction contains the name of the OOP's
> class. For example:
> 0x00007f52ed58e3e4: mov    $0x7f52c4e03d78,%rdi ;   {oop(a 'java/lang/Class' =
> 'java/lang/invoke/MethodHandle')}
> 2) Embedded OOPs are replaced in the disassembled instruction by the OOP's class
> name (this functionality was available only before PermGen removal, see
> JDK-8066438 for more details). The comment block following the disassembled
> instruction contains the same information *again* (the name of the OOP's class).
> For example:
> 0x01882738: cmp   edx, a 'sun/dyn/ToGeneric$A2';   {oop(a 'sun/dyn/ToGeneric$A2')}
> (output taken from https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly)
> Whether an OOP is replaced with its class name depends on the external binutils
> library. For some types of instructions (e.g., compares, jumps and calls on
> x86), binutils indicates to the VM that there are addresses embedded into the
> instruction (and then the VM applies Way 1). For some instructions (e.g., movs
> on x86), binutils does not indicate to the VM that the instruction contains an
> embedded address and the VM applies Way 2.
> Solution: This patch proposes that the disassembler handles OOPs in a single way
> (Way 1): An embedded OOP's is printed in hexadecimal within the instruction; the
> comment following the disassembled instruction prints the OOP's class. This way
> both the OOP as raw address and the OOP's class is available in the disassembly
> by default.
> The patch proposes to not print an OOP's class in decode_env::print_address()
> anymore; printing should be done only in nmethod::print_code_comment_on().
> Thenmethod::embeddedOop_at method is not needed any more and is therefore removed.
> Webrev: http://cr.openjdk.java.net/~zmajo/8071654/webrev.00/
> Testing: manual testing, built + minimal tests with JPRT on all supported
> platforms.
> Thank you!
> Best regards,
> Zoltan

More information about the hotspot-compiler-dev mailing list