Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org
Cc: Vyacheslav Egorov <vegorov@chromium.org>
Subject: Re: JIT interface slowness
Date: Fri, 31 Dec 2010 20:10:00 -0000	[thread overview]
Message-ID: <201012312010.09002.pedro@codesourcery.com> (raw)
In-Reply-To: <AANLkTin-2B+1wCQCpNEiYsrLTuaOCgWLNWA=VXRfPoc4@mail.gmail.com>

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


  reply	other threads:[~2010-12-31 20:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-31 19:43 Vyacheslav Egorov
2010-12-31 20:10 ` Pedro Alves [this message]
2010-12-31 21:39   ` Vyacheslav Egorov
2010-12-31 22:23     ` Pedro Alves
2010-12-31 23:12       ` Vyacheslav Egorov
2010-12-31 23:36         ` Pedro Alves
2011-01-02  7:54           ` Paul Pluzhnikov
2011-01-03 10:44             ` Vyacheslav Egorov
2011-01-03 17:32               ` Paul Pluzhnikov
2011-01-03 22:01                 ` Paul Pluzhnikov
2011-01-03 23:32                   ` Pedro Alves
2011-01-03 23:40                     ` Pedro Alves
2011-01-03 23:47                     ` Paul Pluzhnikov
2011-01-04  0:13                       ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201012312010.09002.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb@sourceware.org \
    --cc=vegorov@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox