lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Geoff Leyland wrote:
> On 6/04/2011, at 3:05 AM, Mike Pall wrote:
> > Well, the JIT compiled code doesn't call hooks ...
> 
> Oh.  Do you mean that if you're using hooks then nothing gets
> compiled or that I'll miss traces from compiled code?  Either
> way, that makes profiling awkward.

Trace recording is aborted if a hook is called. If you don't call
them all the time, then something will eventually be compiled of
course. Since compiled code doesn't call any hooks, it won't show
up in your profile.

In other words: use jit.off() or the C equivalent if you want to
profile Lua code in the LuaJIT interpreter.

Profiling compiled code is quite tricky. I use a homegrown
sampling profiler. It does high-speed sampling of g->vmstate from
another thread. This tells you the CPU percentage for each trace
and VM state (GC, interpreted, C code etc.). The following example
runs 100% in machine code, so only traces are shown:

$ luajit -jtprof scimark.lua LU >/dev/null
 76.5   7         scimark.lua:322
 15.0   8 (7/3)   scimark.lua:319
  3.3   5         scimark.lua:301
  1.8   3         scimark.lua:337
  1.6   6         scimark.lua:313
  0.4  13 (8/1)   scimark.lua:299
  0.4  11 (5/5)   scimark.lua:308
  0.3  12 (6/3)   scimark.lua:318
  0.3   4 (3/3)   scimark.lua:335
  0.2   9 (5/4)   scimark.lua:304

  ^-- CPU %       ^-- file    ^-- starting line
       ^-- trace number
            ^-- parent trace/exit number

But it's very experimental and incomplete. If someone with way too
much time at hand wants to take over maintenance and clean it up,
please mail me off-list.

Another option is to use the Linux kernel profiler (perftools).
See the comments in src/lj_trace.c near perftools_addtrace().

> > Note that it's sufficient to probe the outermost frame and one
> > below (one should be ok, the other not).
>
> Now you point it out, wouldn't you only need to probe the
> expected outermost frame?  If it's not there, then it was a
> tailcall.

Yes, you're right.

--Mike