Re: JIT interface slowness

[Vyacheslav Egorov <vegorov at chromium dot org>]

On Fri, Dec 31, 2010 at 3:36 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> 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.

Yep, it would be interesting to figure it out. I am not sure that I
will be able to invest my own time into investigating this though.

I am running gdb 7.2.

On Sun, Jan 2, 2011 at 8:07 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> I don't think he expected 1K+ separate JITted ELF objects.
> 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?

1K is just a startup of a sample. I would expect any realistic node.js
based application to generate more code objects during lifetime.

Currently I delay manifestation of the problem by not emitting
ELF-objects for code objects that does not have line info attached.
This reduces 1K to ~500. But this will not work as a long-term
solution: I will have to emit debug information (namely .debug_frame)
for all code object otherwise gdb is not able to unwind stack properly
on x64.

I thought that setting a breakpoint requires O(1) not O(n). It's a bit
disappointing.

--
Vyacheslav Egorov


On Sun, Jan 2, 2011 at 8:07 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> 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
>