On Thu, 9 Mar 2023 16:00:53 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:
>> Yes this is really useful when debugging the template interpreter. It >> annotates the disassembly with the generator source code. It helped tracking >> down a bug in the ppc part oft this pr. Other platforms have it too. >> >> Example: >> >> invokedynamic 186 invokedynamic [0x00003fff80075a00, 0x00003fff80075dc8] >> 968 bytes >> >> -------------------------------------------------------------------------------- >> 0x00003fff80075a00: std r17,0(r15) ;;@FILE: >> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp >> ;; 2185: aep = >> __ pc(); __ push_ptr(); __ b(L); >> 0x00003fff80075a04: addi r15,r15,-8 >> 0x00003fff80075a08: b 0x00003fff80075a40 ;; 2185: aep = >> __ pc(); __ push_ptr(); __ b(L); >> 0x00003fff80075a0c: stfs f15,0(r15) ;; 2186: fep = >> __ pc(); __ push_f(); __ b(L); >> 0x00003fff80075a10: addi r15,r15,-8 >> 0x00003fff80075a14: b 0x00003fff80075a40 ;; 2186: fep = >> __ pc(); __ push_f(); __ b(L); >> 0x00003fff80075a18: stfd f15,-8(r15) ;; 2187: dep = >> __ pc(); __ push_d(); __ b(L); >> 0x00003fff80075a1c: addi r15,r15,-16 >> 0x00003fff80075a20: b 0x00003fff80075a40 ;; 2187: dep = >> __ pc(); __ push_d(); __ b(L); >> 0x00003fff80075a24: li r0,0 ;; 2188: lep = >> __ pc(); __ push_l(); __ b(L); >> 0x00003fff80075a28: std r0,0(r15) >> 0x00003fff80075a2c: std r17,-8(r15) >> 0x00003fff80075a30: addi r15,r15,-16 >> 0x00003fff80075a34: b 0x00003fff80075a40 ;; 2188: lep = >> __ pc(); __ push_l(); __ b(L); >> 0x00003fff80075a38: stw r17,0(r15) ;; 2189: __ >> align(32, 12, 24); // align L >> ;; 2191: iep = >> __ pc(); __ push_i(); >> 0x00003fff80075a3c: addi r15,r15,-8 >> 0x00003fff80075a40: li r21,1 ;; 2192: vep = >> __ pc(); >> ;; 2193: __ >> bind(L); >> ;;@FILE: >> src/hotspot/share/interpreter/templateInterpreterGenerator.cpp >> ;; 366: __ >> verify_FPU(1, t->tos_in()); >> ;;@FILE: >> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp >> ;; 2293: __ >> load_resolved_indy_entry(cache, index); >> 0x00003fff80075a44: lwax r21,r14,r21 >> 0x00003fff80075a48: nand r21,r21,r21 >> 0x00003fff80075a4c: ld r31,40(r27) >> 0x00003fff80075a50: rldicr r21,r21,4,59 >> 0x00003fff80075a54: addi r21,r21,8 >> 0x00003fff80075a58: add r31,r31,r21 >> 0x00003fff80075a5c: ld r22,0(r31) ;; 2294: __ >> ld_ptr(method, in_bytes(ResolvedIndyEntry::method_offset()), cache); >> 0x00003fff80075a60: cmpdi r22,0 ;; 2297: __ >> cmpdi(CCR0, method, 0); >> 0x00003fff80075a64: bne- 0x00003fff80075b94 ;; 2298: __ >> bne(CCR0, resolved);,bo=0b00100[no_hint] >> 0x00003fff80075a68: li r4,186 ;; 2304: __ >> li(R4_ARG2, code); >> 0x00003fff80075a6c: ld r11,0(r1) ;; 2305: __ >> call_VM(noreg, entry, R4_ARG2, true); > > This change should be in a further RFE though (and you can explain it there > so we can maybe use it in the other platforms too). Does it affect > performance when generating the template interpreter? Do you need to have > hsdis in the LD_LIBRARY_PATH environment variable to use this? I see it's > already used by default in one place. This looks cool. ------------- PR: https://git.openjdk.org/jdk/pull/12778
