Enables V8 integration with the Intel VTune performance analysis tool. This allows the VTune profi…

Enables V8 integration with the Intel VTune performance analysis tool.  This allows the VTune profiler to associate JavaScript source positions with code addresses and enables side-by-side display of JavaScript source code and generated machine instructions.
Patch submitted by Greeshma Yellareddy <greeshma.yellareddy@intel.com>;

[danno, 2012-08-01 14:41:24]

I will review this tomorrow. In the meantime, please make sure to take a look at
related changes that are happening in the JIT-event interface, they will
probably require changes to this patch.

http://codereview.chromium.org/10795074/

[danno, 2012-08-02 12:38:10]

My high-level feedback about this patch consists of two main points:

-  it should be rebased on http://codereview.chromium.org/10795074 when it
lands, becoming a client of the new SetJitCodeEventHandler API rather than
modifying core v8 routines explicitly. You can provide a .a that apps (Like d8
or Chromium) link to that sets up the VTUNE support.
- for functionality that is currently not currently supported by the
SetJitCodeEventHandler API (like line number to offset information), additional
Events should be added (e.g CODE_ADD_LINE_POS_INFO,
CODE_START_LINE_INFO_RECORDING). You can add fields to the EventRecort to
provide the data required to handle the event.

I realize that this is more intrusive than the existing patch, but the GDB
support is currently a little broken, and we'd like to cleanup and decouple the
external debugging functionality through a clean API before piling more fragile
code upon the existing mechanism. That's a big step to ensure that it doesn't
get broken in the future (e.g. by writing unit tests against the API).

http://codereview.chromium.org/10824032/diff/1/src/assembler.cc
File src/assembler.cc (right):

http://codereview.chromium.org/10824032/diff/1/src/assembler.cc#newcode1336
src/assembler.cc:1336: vtunejit_lineinfo_->AddLineInfo(
This should trigger an event callback in the API rather than being inline.

http://codereview.chromium.org/10824032/diff/1/src/assembler.h
File src/assembler.h (right):

http://codereview.chromium.org/10824032/diff/1/src/assembler.h#newcode830
src/assembler.h:830: VtuneJITLineInfo* vtunejit_lineinfo_;
Generalize to jit_code_event_line_info_

http://codereview.chromium.org/10824032/diff/1/src/mark-compact.cc
File src/mark-compact.cc (right):

http://codereview.chromium.org/10824032/diff/1/src/mark-compact.cc#newcode698
src/mark-compact.cc:698: compacting_ = false;
Can you extend siggi's SetJitCodeEventHandler API to take a "flags" argument,
where the flags are boolean flags, one being
"JIT_CODE_HANDLER_SUPPORTS_MOVED_CODE". If this flag is not set when the handler
is installed, then compacting_ is false (doesn't need to be conditional

http://codereview.chromium.org/10824032/diff/1/src/serialize.cc
File src/serialize.cc (right):

http://codereview.chromium.org/10824032/diff/1/src/serialize.cc#newcode745
src/serialize.cc:745: if (object->IsCode())
Deserialization is very performance sensitive, so adding this additional check
here isn't a good idea. The right thing to do here is to visit the code space
once deserialization is done, calling the JitCodeEventHandler for just code
objects. Siggi's patch will either do this, or he'll follow-up with his patch
with one that does.

[greeshma, 2012-08-03 00:57:58]

When is the JitCodeEvent CL expected to be upstreamed? Is the API more or less
stable that I can work off the patch if necessary?

[greeshma, 2012-08-03 19:45:28]

The JitCodeEvent structure does not currently have a "script" member. This would
be necessary for gdb-jit and Profiling as well. How is it being handled, if at
all?

[greeshma, 2012-08-13 18:17:56]

Pinging to check if there is any update expected for the other issue?

[Michael Starzinger, 2012-08-16 23:28:49]

Sorry for the long delay. I pinged Siggi about the status of the dependent CL.

About your question regarding the Script object. It should be possible to push
the Script object through the JitCodeEvent interface (for code objects that
originate from a script). It will then be an external Script object as declared
in ./include/v8.h though.

As mentioned in Danno's comment, we need a similar event handler for line-number
events (also based on external Script objects).

[danno, 2012-09-14 15:19:38]

Siggi's changes have landed, and based on our discussion on the phone last week,
greeshma, you should be able to proceed. 

On 2012/08/16 23:28:49, Michael Starzinger wrote:
> Sorry for the long delay. I pinged Siggi about the status of the dependent CL.
> 
> About your question regarding the Script object. It should be possible to push
> the Script object through the JitCodeEvent interface (for code objects that
> originate from a script). It will then be an external Script object as
declared
> in ./include/v8.h though.
> 
> As mentioned in Danno's comment, we need a similar event handler for
line-number
> events (also based on external Script objects).

[greeshma, 2012-09-20 01:55:36]

Thanks Daniel. I will be getting to this soon. Sorry for the delay.