From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19427 invoked by alias); 3 Jan 2011 22:01:29 -0000 Received: (qmail 19417 invoked by uid 22791); 3 Jan 2011 22:01:29 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 22:01:24 +0000 Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p03M1Kb6011244 for ; Mon, 3 Jan 2011 14:01:21 -0800 Received: from qyk29 (qyk29.prod.google.com [10.241.83.157]) by wpaz1.hot.corp.google.com with ESMTP id p03M1Js5010864 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 3 Jan 2011 14:01:19 -0800 Received: by qyk29 with SMTP id 29so13767019qyk.18 for ; Mon, 03 Jan 2011 14:01:19 -0800 (PST) Received: by 10.224.73.202 with SMTP id r10mr19961497qaj.131.1294092078510; Mon, 03 Jan 2011 14:01:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.7.132 with HTTP; Mon, 3 Jan 2011 14:00:48 -0800 (PST) In-Reply-To: References: <201012312222.54063.pedro@codesourcery.com> <201012312336.08222.pedro@codesourcery.com> From: Paul Pluzhnikov Date: Mon, 03 Jan 2011 22:01:00 -0000 Message-ID: Subject: Re: JIT interface slowness To: Vyacheslav Egorov Cc: Pedro Alves , 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: 2011-01/txt/msg00006.txt.bz2 On Mon, Jan 3, 2011 at 9:32 AM, Paul Pluzhnikov wrote: > My gut feeling though is that the really slow operation here is > jit_read_code_entry (which reads target memory) and everything else is > noise in comparison (but I haven't measured it). I've reproduced this with current CVS Head. I'd like to submit a test case for this, but where? gdb.base/, gdb.gdb/, elsewhere? I was also wrong about where the time is spent :-( The quadratic/cubic loop does not in fact happen (it is protected against with 'registering_code' in jit.c). But I wasn't completely off base -- breakpoints to have something to do with this. The profile (from 'perf') is: # Events: 19K cycles # # Overhead Command Shared Object Symbol # ........ ......... .................... ........................................ # 67.30% gdb64-cvs gdb [.] lookup_minimal_symbol_text 29.59% gdb64-cvs gdb [.] lookup_minimal_symbol 0.81% gdb64-cvs gdb [.] find_pc_section 0.19% gdb64-cvs libc-2.11.1.so [.] __ctype_b_loc And lookup_minimal_symbol_text is called from breakpoint_re_set: 10523 create_overlay_event_breakpoint ("_ovly_debug_event"); 10524 create_longjmp_master_breakpoint ("longjmp"); 10525 create_longjmp_master_breakpoint ("_longjmp"); 10526 create_longjmp_master_breakpoint ("siglongjmp"); 10527 create_longjmp_master_breakpoint ("_siglongjmp"); The following patch: Index: jit.c =================================================================== RCS file: /cvs/src/src/gdb/jit.c,v retrieving revision 1.8 diff -u -r1.8 jit.c --- jit.c 1 Jan 2011 15:33:09 -0000 1.8 +++ jit.c 3 Jan 2011 21:34:17 -0000 @@ -263,7 +263,7 @@ my_cleanups = make_cleanup (clear_int, ®istering_code); /* This call takes ownership of sai. */ - objfile = symbol_file_add_from_bfd (nbfd, 0, sai, OBJF_SHARED); + objfile = symbol_file_add_from_bfd (nbfd, SYMFILE_DEFER_BP_RESET, sai, OBJF_SHARED); /* Clear the registering_code flag. */ do_cleanups (my_cleanups); makes 100x difference (0.64s vs. 61.5s) for 1000 simulated JIT ELFs. I think it's pretty safe to assume that we don't need to search JITted objfiles for above functions, as JITs do not participate in normal symbol resolution at all. Do we need a new OBJF_JIT flag, or is above patch good enough? Thanks, -- Paul Pluzhnikov