Re: JIT interface slowness

[Pedro Alves <pedro at codesourcery dot com>]

On Friday 31 December 2010 21:38:49, Vyacheslav Egorov wrote:

> Sorry for not being clear. It is the former. V8 continuously generates
> code objects while the application runs (and it generates more than it
> reclaims at least on this particular node.js sample which I am using
> to evaluate GDB JIT client implementation).
> 
> During startup of the aforementioned sample (in the worst case when an
> ELF object is emitted for each generated code object) 1118 code
> objects are generated.

Yeah.  It may be useful to have a way for the client
to batch informing gdb of the elf objects becoming available.  IIRC,
you only have the option of letting gdb know of one entry at a time
currently.  Not clear whether that'd be a clear gain without a better
understanding of where time is spent.  Or maybe you could paralelize
on your end somehow, or change design to make it so you have fewer
objects.

If your JIT runs on a separate thread, and pausing just that
thread doesn't block all others immediately, you could try
running gdb in non-stop mode.  It may speed up interactive startup
in this use case, since when the JIT notification breakpoint only
stops the JIT thread (instead of all threads) in that mode,
though it sounds like the debug info for the JIT compiled code
would still take a bit to become available anyway.

> 
> Also it seems that with each new ELF object registration of a single
> new entry costs more and more:
> 
> registered new entry, total 1101 entries [took 324 ms]
> registered new entry, total 1102 entries [took 324 ms]
> registered new entry, total 1103 entries [took 325 ms]
> registered new entry, total 1104 entries [took 326 ms]
> registered new entry, total 1105 entries [took 326 ms]
> registered new entry, total 1106 entries [took 327 ms]
> registered new entry, total 1107 entries [took 327 ms]
> registered new entry, total 1108 entries [took 328 ms]
> registered new entry, total 1109 entries [took 329 ms]
> registered new entry, total 1110 entries [took 329 ms]
> registered new entry, total 1111 entries [took 330 ms]
> registered new entry, total 1112 entries [took 331 ms]
> registered new entry, total 1113 entries [took 332 ms]
> registered new entry, total 1114 entries [took 333 ms]
> registered new entry, total 1115 entries [took 333 ms]
> registered new entry, total 1116 entries [took 334 ms]
> registered new entry, total 1117 entries [took 335 ms]
> registered new entry, total 1118 entries [took 336 ms]
> 
> // value in the brackets is not a sum; it's time spent on registering
> a single entry.

Yeah.  Quite difficult to put the finger on a single
culprit without digging deeper.  Might be easy to fix,
might not.  What was the cost for a first registrations?

If you're interested in investigating deeper, and perhaps
addressing the problem, here are a few questions that could help
investigate where most of the time is spent: is this native
debugging, or remote debugging? If remote debugging, a significant
chunk of time may be getting spent on reading the debug info
from memory.  What's the elf object's or debug info's size?  (If
most of time is spent on debug info parsing rather than extracting the
file from memory, this may be something that could benefit
from Tromey's multi-threading debug info reading patches.)

> Happy New Year!

Ditto!

-- 
Pedro Alves