disassembly for foreign call wrapper

Deneau, Tom tom.deneau at amd.com
Mon Dec 2 12:52:24 PST 2013


Doug or others --

In the case of a Foreign Call to Deoptimization::uncommon_trap, I see that gdb shows this code after we return from uncommon_trap...

   0x7fffeb05ddb1:	callq  0x7ffff68b130e <Deoptimization::uncommon_trap(JavaThread*, int)>
   0x7fffeb05ddb6:	movabs $0x0,%r10
   0x7fffeb05ddc0:	mov    %r10,0x200(%r15)
   0x7fffeb05ddc7:	jmpq   0x7fffeb05df99

and the code at 0x7fffeb05df99 eventually calls Deoptimization::unpack_frames and
then I think enters the interpreter.

So I was wondering where this wrapper code that follows the return from uncommon_trap gets generated

-- Tom


-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com] 
Sent: Thursday, November 21, 2013 2:59 PM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: disassembly for foreign call wrapper

This is no wrapper - just the foreign call plus maybe a prologue/epilogue around the call. For example, each of the calls in the output below is to foreign call described by SystemSubstitutions.JAVA_TIME_MILLIS:

$ mx --vm server unittest -G:Log=CodeInstall -G:MethodFilter=test System_nanoTime01 JUnit version 4.8 .Loaded disassembler from /Users/dsimon/linz/basic-graal/jdk1.7.0_45/product/jre/lib/hsdis-amd64.dylib
[thread:1] scope:
  [thread:1] scope: Compiling
    [thread:1] scope: Compiling.CodeInstall
    Code installed for HotSpotMethod<System_nanoTime01.test()>
----------------------------------------------------------------------
com/oracle/graal/jtt/jdk/System_nanoTime01.test  [0x000000010971dba0, 0x000000010971dc40]  1280 bytes [Disassembling for mach='i386:x86-64'] [Entry Point] [Verified Entry Point] [Constants]
  # {method} {0x0000000112bbfde8} 'test' '()I' in 'com/oracle/graal/jtt/jdk/System_nanoTime01'
  #           [sp+0x20]  (sp of caller)
  0x000000010971dba0: mov    %rax,-0x14000(%rsp)
  0x000000010971dba8: sub    $0x18,%rsp
  0x000000010971dbac: mov    %rbp,0x10(%rsp)
  0x000000010971dbb1: callq  0x0000000108c22934  ;   {runtime_call}
  0x000000010971dbb6: nop
  0x000000010971dbb7: mov    %rax,0x8(%rsp)
  0x000000010971dbbc: callq  0x0000000108c22934  ;   {runtime_call}
  0x000000010971dbc1: nop
  0x000000010971dbc2: sub    0x8(%rsp),%rax
  0x000000010971dbc7: cmp    $0x0,%rax
  0x000000010971dbcb: jg     0x000000010971dc0d
  0x000000010971dbd1: mov    $0x1,%eax
  0x000000010971dbd6: jmpq   0x000000010971dbff
  0x000000010971dbdb: nopl   0x0(%rax,%rax,1)
  0x000000010971dbe0: mov    %eax,0x4(%rsp)
  0x000000010971dbe4: callq  0x0000000108c22934  ;   {runtime_call}
  0x000000010971dbe9: nop
  0x000000010971dbea: sub    0x8(%rsp),%rax
  0x000000010971dbef: cmp    $0x0,%rax
  0x000000010971dbf3: jg     0x000000010971dc2a
  0x000000010971dbf9: mov    0x4(%rsp),%eax
  0x000000010971dbfd: inc    %eax
  0x000000010971dbff: cmp    $0x989680,%eax
  0x000000010971dc05: jge    0x000000010971dc23
  0x000000010971dc0b: jmp    0x000000010971dbe0
  0x000000010971dc0d: mov    $0x1,%eax
  0x000000010971dc12: mov    0x10(%rsp),%rbp
  0x000000010971dc17: add    $0x18,%rsp
  0x000000010971dc1b: mov    -0x1784c1b(%rip),%rbx        # 0x0000000107f99007
                                                ;   {poll_return}
  0x000000010971dc22: retq
  0x000000010971dc23: mov    $0x0,%eax
  0x000000010971dc28: jmp    0x000000010971dc12
  0x000000010971dc2a: mov    $0x1,%eax
  0x000000010971dc2f: jmp    0x000000010971dc12
[Exception Handler]
  0x000000010971dc31: callq  0x000000010971dd20  ;   {runtime_call}
  0x000000010971dc36: nop
[Deopt Handler Code]
  0x000000010971dc37: callq  0x00000001095deb00  ;   {runtime_call}
  0x000000010971dc3c: nop
[Stub Code]
  0x000000010971dc3d: hlt
  0x000000010971dc3e: hlt
  0x000000010971dc3f: hlt

On Nov 21, 2013, at 9:17 PM, Deneau, Tom <tom.deneau at amd.com> wrote:

> Is there a Log scoping that will show the disassembly for the code that is the wrapper for a foreign call to a non-stub.
> 
> I am currently using -G:Log=CodeInstall which gives me normal methods plus  CompilingStub.CodeInstall .
> 
> -- Tom





More information about the graal-dev mailing list