This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: JIT interface slowness

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]