Re: JIT interface slowness

[Paul Pluzhnikov <ppluzhnikov@google.com>]

On Mon, Jan 3, 2011 at 9:32 AM, Paul Pluzhnikov <ppluzhnikov@google.com> 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, &registering_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