From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22419 invoked by alias); 3 Jan 2011 10:44:03 -0000 Received: (qmail 22408 invoked by uid 22791); 3 Jan 2011 10:44:01 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_20,DKIM_SIGNED,DKIM_VALID,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Jan 2011 10:43:55 +0000 Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p03AhqQ2022841 for ; Mon, 3 Jan 2011 02:43:52 -0800 Received: from pwj3 (pwj3.prod.google.com [10.241.219.67]) by kpbe20.cbf.corp.google.com with ESMTP id p03Ahoka005805 for ; Mon, 3 Jan 2011 02:43:51 -0800 Received: by pwj3 with SMTP id 3so1708433pwj.19 for ; Mon, 03 Jan 2011 02:43:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.161.17 with SMTP id n17mr16812552wfo.160.1294051430578; Mon, 03 Jan 2011 02:43:50 -0800 (PST) Received: by 10.142.230.18 with HTTP; Mon, 3 Jan 2011 02:43:50 -0800 (PST) In-Reply-To: References: <201012312222.54063.pedro@codesourcery.com> <201012312336.08222.pedro@codesourcery.com> Date: Mon, 03 Jan 2011 10:44:00 -0000 Message-ID: Subject: Re: JIT interface slowness From: Vyacheslav Egorov To: Paul Pluzhnikov Cc: Pedro Alves , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-01/txt/msg00002.txt.bz2 On Fri, Dec 31, 2010 at 3:36 PM, Pedro Alves 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 wr= ote: > 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 wr= ote: > On Fri, Dec 31, 2010 at 3:36 PM, Pedro Alves wro= te: >> 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. =A0There'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). =A0Not all your users >> will want to enable this mode. =A0And 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 > =A0objfile =3D symbol_file_add_from_bfd (nbfd, 0, sai, OBJF_SHARED); > > And in symfile.c (new_symfile_objfile): > > =A0else if ((add_flags & SYMFILE_DEFER_BP_RESET) =3D=3D 0) > =A0 =A0{ > =A0 =A0 =A0breakpoint_re_set (); > =A0 =A0} > > 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 >