This is the mail archive of the
mailing list for the GDB project.
Re: JIT interface slowness
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: Vyacheslav Egorov <vegorov at chromium dot org>, gdb at sourceware dot org
- Date: Sat, 1 Jan 2011 23:07:08 -0800
- Subject: Re: JIT interface slowness
- References: <AANLkTin-2B+1wCQCpNEiYsrLTuaOCgWLNWA=VXRfPoc4@mail.gmail.com> <email@example.com> <AANLkTimp_X92h4uXAS3fm=BSLSej-pD69Tkk=TowzYp_@mail.gmail.com> <firstname.lastname@example.org>
On Fri, Dec 31, 2010 at 3:36 PM, Pedro Alves <email@example.com> wrote:
> On Friday 31 December 2010 23:11:55, Vyacheslav Egorov wrote:
>> > 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.
>> I thought you said that hitting __jit_debug_register_code stops the
>> world i.e. stops all threads.
> I did, and it does, in all-stop mode, which is the gdb default
> mode. ?There's a new-ish mode (called the non-stop mode), where
> gdb does _not_ stop all your threads whenever a breakpoint is
> hit --- only the particular thread that hit the breakpoint.
> (There's a chapter about it in the manual). ?Not all your users
> will want to enable this mode. ?And most frontends don't know
> about it either, so, it's not really a "fix" for everyone, I
>> > What was the cost for a first registrations?
>> Up to 88 it is < 2ms
>> Up to 276 --- < 10ms
>> Up to 535 --- < 50ms
>> 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]
> It would be quite interesting to know what causes this.
> You should also try a recent snapshot (or cvs head), and
> 7.2, if you aren't already.
FWIW, when Reid K. was implementing this in GSoC, his use case was
Unladen Swallow (http://en.wikipedia.org/wiki/Unladen_Swallow), and I
don't think he expected 1K+ separate JITted ELF objects.
In jit.c, I see
objfile = symbol_file_add_from_bfd (nbfd, 0, sai, OBJF_SHARED);
And in symfile.c (new_symfile_objfile):
else if ((add_flags & SYMFILE_DEFER_BP_RESET) == 0)
I think this is going to repeatedly remove and re-insert JIT
breakpoint into every added jit ELF, giving O(N*N) runtime, wouldn't