Re: JIT interface slowness

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Fri, Dec 31, 2010 at 3:36 PM, Pedro Alves <pedro@codesourcery.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
> guess.
>
>> > 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)
    {
      breakpoint_re_set ();
    }

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
it?

-- 
Paul Pluzhnikov