From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7480 invoked by alias); 31 Dec 2010 23:12:05 -0000 Received: (qmail 7471 invoked by uid 22791); 31 Dec 2010 23:12:04 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 31 Dec 2010 23:11:59 +0000 Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id oBVNBvwn014326 for ; Fri, 31 Dec 2010 15:11:57 -0800 Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by kpbe14.cbf.corp.google.com with ESMTP id oBVNBuDh005841 for ; Fri, 31 Dec 2010 15:11:56 -0800 Received: by gwb11 with SMTP id 11so5711266gwb.39 for ; Fri, 31 Dec 2010 15:11:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.7.15 with SMTP id k15mr9226991agi.167.1293837115869; Fri, 31 Dec 2010 15:11:55 -0800 (PST) Received: by 10.90.33.17 with HTTP; Fri, 31 Dec 2010 15:11:55 -0800 (PST) In-Reply-To: <201012312222.54063.pedro@codesourcery.com> References: <201012312010.09002.pedro@codesourcery.com> <201012312222.54063.pedro@codesourcery.com> Date: Fri, 31 Dec 2010 23:12:00 -0000 Message-ID: Subject: Re: JIT interface slowness From: Vyacheslav Egorov To: Pedro Alves Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 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: 2010-12/txt/msg00095.txt.bz2 On Fri, Dec 31, 2010 at 11:22 PM, Pedro Alves wrote: > or change design to make it so you have fewer objects. Yep, this is the most obvious optimization to pursue and I am already tried to figure out some way of merging ELF-objects for different code objects together. Unfortunately it is not easy due to the lazy nature of JIT compilation. > > 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. If this is not the case I can just form a queue on my side and let a separate thread poll it and register incoming elf-objects (in V8 compilation and execution are performed in the same thread). > What was the cost for a first registrations? Up to 88 it is < 2ms Up to 276 --- < 10ms Up to 535 --- < 50ms > is this native debugging, or remote debugging? native > What's the elf object's or debug info's size? for ia32 below 1k. average seems to be 600 bytes. Contents are (in addition to standard ELF header, section table, string table for section table): .text section: type = NOBITS, address = start of JIT emitted code object, size = size of JIT emitted code object .symtab section: 2 symbols, one of type FILE with local binding, one of type FUNC with global binding and the name equal to name of JIT emitted code object. plus for code objects with available line information: .debug_info section with one compilation unit, .debug_abbrev section with one abbreviation corresponding to compilation unit from .debug_info, .debug_line with DWARF2 encoded line information. -- Vyacheslav Egorov