From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3120 invoked by alias); 31 Dec 2010 22:23:04 -0000 Received: (qmail 3112 invoked by uid 22791); 31 Dec 2010 22:23:02 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 31 Dec 2010 22:22:58 +0000 Received: (qmail 19488 invoked from network); 31 Dec 2010 22:22:56 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Dec 2010 22:22:56 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: JIT interface slowness Date: Fri, 31 Dec 2010 22:23:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.33-29-realtime; KDE/4.4.5; x86_64; ; ) Cc: Vyacheslav Egorov References: <201012312010.09002.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012312222.54063.pedro@codesourcery.com> 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: 2010-12/txt/msg00094.txt.bz2 On Friday 31 December 2010 21:38:49, Vyacheslav Egorov wrote: > Sorry for not being clear. It is the former. V8 continuously generates > code objects while the application runs (and it generates more than it > reclaims at least on this particular node.js sample which I am using > to evaluate GDB JIT client implementation). > > During startup of the aforementioned sample (in the worst case when an > ELF object is emitted for each generated code object) 1118 code > objects are generated. Yeah. It may be useful to have a way for the client to batch informing gdb of the elf objects becoming available. IIRC, you only have the option of letting gdb know of one entry at a time currently. Not clear whether that'd be a clear gain without a better understanding of where time is spent. Or maybe you could paralelize on your end somehow, or change design to make it so you have fewer objects. 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. It may speed up interactive startup in this use case, since when the JIT notification breakpoint only stops the JIT thread (instead of all threads) in that mode, though it sounds like the debug info for the JIT compiled code would still take a bit to become available anyway. > > Also it seems that with each new ELF object registration of a single > new entry costs more and more: > > registered new entry, total 1101 entries [took 324 ms] > registered new entry, total 1102 entries [took 324 ms] > registered new entry, total 1103 entries [took 325 ms] > registered new entry, total 1104 entries [took 326 ms] > registered new entry, total 1105 entries [took 326 ms] > registered new entry, total 1106 entries [took 327 ms] > registered new entry, total 1107 entries [took 327 ms] > registered new entry, total 1108 entries [took 328 ms] > registered new entry, total 1109 entries [took 329 ms] > registered new entry, total 1110 entries [took 329 ms] > registered new entry, total 1111 entries [took 330 ms] > registered new entry, total 1112 entries [took 331 ms] > registered new entry, total 1113 entries [took 332 ms] > registered new entry, total 1114 entries [took 333 ms] > 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] > > // value in the brackets is not a sum; it's time spent on registering > a single entry. Yeah. Quite difficult to put the finger on a single culprit without digging deeper. Might be easy to fix, might not. What was the cost for a first registrations? If you're interested in investigating deeper, and perhaps addressing the problem, here are a few questions that could help investigate where most of the time is spent: is this native debugging, or remote debugging? If remote debugging, a significant chunk of time may be getting spent on reading the debug info from memory. What's the elf object's or debug info's size? (If most of time is spent on debug info parsing rather than extracting the file from memory, this may be something that could benefit from Tromey's multi-threading debug info reading patches.) > Happy New Year! Ditto! -- Pedro Alves