Re: JIT interface slowness

[Vyacheslav Egorov <vegorov@chromium.org>]

On Fri, Dec 31, 2010 at 11:22 PM, Pedro Alves <pedro@codesourcery.com> 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