objdump of translated JS program

[Albert]

Hi,

I'm studying hardware performance of JS programs. I tried with --print-
code switch with shell sample but the problem is I only got assembly
code. What I would like to have is something like objdump result of C/C
++ program. Is there a way of doing this?

Thanks,

[Vyacheslav Egorov]

Hi Albert,

Can you clarify?

What kind of information in your opinion is missing from the
--print-code output?

You can use --code-comments to make assembly more human readable.

Strictly speaking there is not such thing as a translated JS program as whole.

V8 compiles different functions separately as application runs. It
might compile the same function several times with different
compilers.

--
Vyacheslav Egorov

> --
> v8-users mailing list
> v8-u...@googlegroups.com
> http://groups.google.com/group/v8-users
>

[Zhaoshi Zheng]

Vyacheslav,

Thanks for your reply. Take this function for example, Benchmark in base.js of V8 benchmark suite:

0x7fe7ed6c2a07     7  49ba11a95a12e87f0000 REX.W movq r10,0x7fe8125aa911    ;; object: 0x7fe8125aa911 <FixedArray[2]>

In this line, the object at 0x7fe8125aa911 is not shown. I assume it is placed in "data section".

0x7fe7ed6c2a23    35  e8d8d8fdff     call 0x7fe7ed6a0300     ;; debug: statement 0
                                                             ;; code: STUB, CEntry, minor: 0

0x7fe7ed6c2a2e    46  e80d23feff     call 0x7fe7ed6a4d40     ;; code: STUB, StackCheck, minor: 0

In these two lines, the callees are not shown, I suppose CEntry and StackCheck are both built-in functions of v8.

Basically, my goal is to catch runtime instructions trace (this is the easy part) and relate it back to javascript source code. Will --gdbjit-dump help? Is this option only available in debug build?

--- Raw source ---
// A benchmark has a name (string) and a function that will be run to
// do the performance measurement. The optional setup and tearDown
// arguments are functions that will be invoked before and after
// running the benchmark, but the running time of these functions will
// not be accounted for in the benchmark score.
function Benchmark(name, run, setup, tearDown) {
  this.name = name;
  this.run = run;
  this.Setup = setup ? setup : function() { };
  this.TearDown = tearDown ? tearDown : function() { };
}



--- Code ---
kind = FUNCTION
Instructions (size = 72)
0x7fe7ed6c2a00     0  55             push rbp
0x7fe7ed6c2a01     1  4889e5         REX.W movq rbp,rsp
0x7fe7ed6c2a04     4  56             push rsi
0x7fe7ed6c2a05     5  57             push rdi
0x7fe7ed6c2a06     6  56             push rsi
0x7fe7ed6c2a07     7  49ba11a95a12e87f0000 REX.W movq r10,0x7fe8125aa911    ;; object: 0x7fe8125aa911 <FixedArray[2]>
0x7fe7ed6c2a11    17  4152           push r10
0x7fe7ed6c2a13    19  6a00           push 0x0
0x7fe7ed6c2a15    21  6a00           push 0x0
0x7fe7ed6c2a17    23  b804000000     movl rax,0x4
0x7fe7ed6c2a1c    28  498d9da0d792fe REX.W leaq rbx,[r13-0x16d2860]
0x7fe7ed6c2a23    35  e8d8d8fdff     call 0x7fe7ed6a0300     ;; debug: statement 0
                                                             ;; code: STUB, CEntry, minor: 0
0x7fe7ed6c2a28    40  493b6508       REX.W cmpq rsp,[r13+0x8]
0x7fe7ed6c2a2c    44  7305           jnc 51  (0x7fe7ed6c2a33)
0x7fe7ed6c2a2e    46  e80d23feff     call 0x7fe7ed6a4d40     ;; code: STUB, StackCheck, minor: 0
0x7fe7ed6c2a33    51  498b4598       REX.W movq rax,[r13-0x68]
0x7fe7ed6c2a37    55  488be5         REX.W movq rsp,rbp      ;; debug: statement 513
                                                             ;; js return
0x7fe7ed6c2a3a    58  5d             pop rbp
0x7fe7ed6c2a3b    59  c20800         ret 0x8
0x7fe7ed6c2a3e    62  cc             int3
0x7fe7ed6c2a3f    63  cc             int3
0x7fe7ed6c2a40    64  cc             int3
0x7fe7ed6c2a41    65  cc             int3
0x7fe7ed6c2a42    66  cc             int3
0x7fe7ed6c2a43    67  cc             int3

Deoptimization Output Data (deopt points = 0)

Stack checks (size = 0)
ast_id  pc_offset

RelocInfo (size = 14)
0x7fe7ed6c2a09  embedded object  (0x7fe8125aa911 <FixedArray[2]>)
0x7fe7ed6c2a23  statement position  (0)
0x7fe7ed6c2a24  code target (STUB)  (0x7fe7ed6a0300)
0x7fe7ed6c2a2f  code target (STUB)  (0x7fe7ed6a4d40)
0x7fe7ed6c2a37  statement position  (513)
0x7fe7ed6c2a37  js return

[Stephan Beal]

On Wed, Jul 6, 2011 at 7:15 PM, Vyacheslav Egorov <veg...@chromium.org> wrote:

V8 compiles different functions separately as application runs. It
might compile the same function several times with different
compilers.

Just out of curiosity: can you give us (or point us to) an overview of the different modes and why one mode might be chosen over another in a different context? i'd be particularly interested in knowing why the same function might get compiled in different ways. (Again, just of curiosity, not because i want to optimize at that level.)

-- 

----- stephan beal
http://wanderinghorse.net/home/stephan/

[Vyacheslav Egorov]

> In this line, the object at 0x7fe8125aa911 is not shown. I assume it is placed in "data section".

Well. There is not data section. The object itself lives in the heap.
If you look at relocation information you can see that object
0x7fe8125aa911 is a two element FixedArray.

You can extend Code::Disassemble to print all referenced objects
recursively but that would produce quite a large output with cycles.

Alternatively you can just put a breakpoint into
CodeGenerator::PrintCode, wait until V8 compiles and prints
interesting function and then expect heap state, print objects that
are interesting to you etc.

> In these two lines, the callees are not shown, I suppose CEntry and StackCheck are both built-in functions of v8.

They will be printed if you pass --print-code-stubs to V8 (your shell
should be compiled with snapshot=off).

> Basically, my goal is to catch runtime instructions trace (this is the easy part) and relate it back to javascript
> source code.

--code-comment will help you to do that.

> Will --gdbjit-dump help? Is this option only available in debug build?

GDBJIT interface produces object that contain debugging information
(like pc to line mapping) but no code. So I don't think --gdbjit-dump
will help you.

--
Vyacheslav Egorov

[Vyacheslav Egorov]

Short answer is:

There are two compilers: non-optimizing (aka full) and optimizing.

Every function starts non-optimized. V8 profiles the application as it
runs and tries to optimize hot functions making assumptions based on
type feedback it gathered during execution of non-optimized code.

--
Vyacheslav Egorov

[Zhaoshi Zheng]

Thank you very much for the tips.