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

[Tobias Hartmann]

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
re-enabled.

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

Best,
Tobias

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
>