[9] RFR(S): 8071654: disassembler handles embedded OOPs not uniformly
Zoltán Majó
zoltan.majo at oracle.com
Thu Jan 29 09:01:52 UTC 2015
Hi Tobias,
On 01/29/2015 09:36 AM, Tobias Hartmann wrote:
> Hi Zoltan,
>
> looks good to me (not a reviewer).
thank you for the feedback!
> 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.
That's a good idea, I changed the type.
> I assume you'll close JDK-8066438 after pushing this, right?
That is correct. We don't want to re-enable the dead code as suggested
by 8066438.
Thank you and best regards,
Zoltan
>
> 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
>>
More information about the hotspot-compiler-dev
mailing list