-
Enhancement
-
Resolution: Fixed
-
P4
-
9
-
b52
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8082872 | emb-9 | Zoltan Majo | P4 | Resolved | Fixed | team |
The disassembler has two different ways of handling OOP addresses.
1) Some OOP addresses are supposed to be replaced in the disassembled instruction that contains them by their class's name (this functionality was available only before PermGen removal, seeJDK-8066438 for more details). The comment block following the disassembled instruction contains the class's name as well. 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)
2) Some OOP addresses are printed in plain hexadecimal in the disassembly. The comment block, however, contains detailed information about the address in the disassembled instruction. For example,
0x00007f52ed58e3e4: mov $0x7f52c4e03d78,%rdi ; {oop(a 'java/lang/Class' = 'java/lang/invoke/MethodHandle')}
Whether addresses are replaced in an instruction depends on binutils: If binutils calls the 'print_address_func' callback for an address, the VM will replace that address with a suitable comment. In some cases, however, binutils does not call 'print_address_func' for addresses and as a result the VM does not replace addresses within a disassembled instruction.
A strange result of this logic within binutils is that in addresses are in some cases replaced twice within a single instruction: once in the instruction itself and once in the comment, thus eliminating the raw data address (e.g., in the instruction at 0x01882738 in the example above)
https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly
When debugging the VM, it is useful to have all addresses available for the investigation. Comments are very helpful as well, but they should complement and not replace addresses. Moreover, the VM's output should depend as little as possible on the way binutils handles (or does not handle) addresses.
The goals of this patch is to change the disassembler to handle OOP addresses uniformly:
1) Use hexadecimal OOP addresses in disassembled instructions at all places.
2) Provide information about oops only the comment block following each disassembled instruction.
1) Some OOP addresses are supposed to be replaced in the disassembled instruction that contains them by their class's name (this functionality was available only before PermGen removal, see
0x01882738: cmp edx, a 'sun/dyn/ToGeneric$A2'
; {oop(a 'sun/dyn/ToGeneric$A2')}
(output taken from https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly)
2) Some OOP addresses are printed in plain hexadecimal in the disassembly. The comment block, however, contains detailed information about the address in the disassembled instruction. For example,
0x00007f52ed58e3e4: mov $0x7f52c4e03d78,%rdi ; {oop(a 'java/lang/Class' = 'java/lang/invoke/MethodHandle')}
Whether addresses are replaced in an instruction depends on binutils: If binutils calls the 'print_address_func' callback for an address, the VM will replace that address with a suitable comment. In some cases, however, binutils does not call 'print_address_func' for addresses and as a result the VM does not replace addresses within a disassembled instruction.
A strange result of this logic within binutils is that in addresses are in some cases replaced twice within a single instruction: once in the instruction itself and once in the comment, thus eliminating the raw data address (e.g., in the instruction at 0x01882738 in the example above)
https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly
When debugging the VM, it is useful to have all addresses available for the investigation. Comments are very helpful as well, but they should complement and not replace addresses. Moreover, the VM's output should depend as little as possible on the way binutils handles (or does not handle) addresses.
The goals of this patch is to change the disassembler to handle OOP addresses uniformly:
1) Use hexadecimal OOP addresses in disassembled instructions at all places.
2) Provide information about oops only the comment block following each disassembled instruction.
- backported by
-
JDK-8082872 disassembler handles embedded OOPs not uniformly
-
- Resolved
-
- relates to
-
JDK-8066438 Disassembler plugin is unable to print embedded oops in instruction stream since perm gen removal
-
- Closed
-