From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6995 invoked by alias); 31 Dec 2010 20:10:22 -0000 Received: (qmail 6985 invoked by uid 22791); 31 Dec 2010 20:10:18 -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 20:10:14 +0000 Received: (qmail 29982 invoked from network); 31 Dec 2010 20:10:11 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Dec 2010 20:10:11 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: JIT interface slowness Date: Fri, 31 Dec 2010 20:10:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.33-29-realtime; KDE/4.4.5; x86_64; ; ) Cc: Vyacheslav Egorov References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012312010.09002.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/msg00092.txt.bz2 On Friday 31 December 2010 19:43:12, Vyacheslav Egorov wrote: > Hi, > > I've implemented[1] basic GDB JIT client for V8[2] and when people > started testing it with node.js[3] we noticed that it makes execution > under GDB slower especially if JIT generates and registers inmemory > ELF object for every single code object it emits. > > Apparently GDB is just not optimized to handle tons of small ELF > objects being registered (and unregistered). When I just comment out > calls to __jit_debug_register_code (leaving ELF-generation intact) > everything becomes fast again. > > Is there any known bottlenecks in JIT interface/any known workaround for them? Your description of the problem is a bit ambiguous: are you saying that in your use case the JIT client is constantly registering and unregistering debug info with gdb, or that you generate a ton of small ELF objects in one go, and then gdb becomes slow with all of those loaded? If the former, I guess that would be attributed to the fact that whenever your client calls __jit_debug_register_code, your process hits a(n internal) breakpoint, which stops the world, then GDB reacts to that breakpoint, reading the debug info object that the client has generated (or unloaded), and then re-resumes the program (read, it's a syncronous, blocking process). Easy to imagine a lot of those in quick and constant succession slowing down execution significantly. Logs would give a better hint (e.g., "set debug timestamp on; set debug infrun 1", look for bp_jit_event). If the latter, how many is "tons"? -- Pedro Alves