Re: JIT interface slowness

[Vyacheslav Egorov <vegorov@chromium.org>]

Hi Pedro,

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.

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.

Happy New Year!

--
Vyacheslav Egorov


On Fri, Dec 31, 2010 at 9:10 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Friday 31 December 2010 19:43:12, Vyacheslav Egorov wrote:
>> Hi,
>>
>> I've implemented[1] basic GDB JIT client for V8[2] and when people
>> started testing it with node.js[3] we noticed that it makes execution
>> under GDB slower especially if JIT generates and registers inmemory
>> ELF object for every single code object it emits.
>>
>> Apparently GDB is just not optimized to handle tons of small ELF
>> objects being registered (and unregistered). When I just comment out
>> calls to __jit_debug_register_code (leaving ELF-generation intact)
>> everything becomes fast again.
>>
>> Is there any known bottlenecks in JIT interface/any known workaround for them?
>
> Your description of the problem is a bit ambiguous: are you saying that in
> your use case the JIT client is constantly registering and unregistering debug
> info with gdb, or that you generate a ton of small ELF objects in one go, and
> then gdb becomes slow with all of those loaded?
>
> If the former, I guess that would be attributed to the fact that whenever
> your client calls __jit_debug_register_code, your process hits a(n internal)
> breakpoint, which stops the world, then GDB reacts to that breakpoint,
> reading the debug info object that the client has generated (or unloaded),
> and then re-resumes the program (read, it's a syncronous, blocking process).
> Easy to imagine a lot of those in quick and constant succession slowing
> down execution significantly.  Logs would give a better hint (e.g.,
> "set debug timestamp on; set debug infrun 1", look for bp_jit_event).
>
> If the latter, how many is "tons"?
>
> --
> Pedro Alves
>