On 2010/04/23 08:33:49, Michail Naganov wrote:
Jaime, what usage scenario are you targeting on? The function you wrote
captures
the current stack, so to capture running JS code, this function needs to
be
called from inside it. How? And you can't call this function from another
thread, without stopping the V8 thread.
To clarify, this API is intended to satisfy the use case of the
InspectorTimelineAgent functionality in WebCore which feeds both the
timelinepanel in the WebKit Inspector, and Google Speed Tracer. This
infrastructure measures time spent in various portions of the browser code.
Things like Parsing HTML, running JavaScript, performing layout, etc... This
builds a tree structure that we serialize to a JavaScript object and send
over
to tools like the webkit inspector, or Speed Tracer.
Essentially, whenever JavaScript does something in the DOM bindings layer
that
causes (synchronously) HTML to be parsed, Layout to run, or Styles to be
rematched, the InspectorTimelineAgent grabs information about the top call
frame
(using the debug JS api) to see what JavaScript triggered it. This is very
useful for web developers who want to write efficient web apps.
The problem currently is that:
1. Even only grabbing information about the top stack frame is very slow
using
the current JS api.
2. Modern web apps use libraries to write their code. Thus the vast
majority of
the time the top stack frame is general library code and useless to the
developer. More stack frames are needed.
3. Frequently allowing GC to run during things like layout or style
rematching
is totally unacceptable for a browser profiler. This is not just observer
effect. This is an incorrect representation of what would happen in the
browser
during normal execution of the application. GC would never normally run
during
something like style rematching.
http://codereview.chromium.org/1694011/diff/1/3
File src/api.cc (right):
http://codereview.chromium.org/1694011/diff/1/3#newcode4028
src/api.cc:4028: inline int LineFromPosition(int position,
Please look at GetScriptLineNUmber in handles.cc.
Thanks. Will take a look.
http://codereview.chromium.org/1694011/diff/1/3#newcode4098
src/api.cc:4098: i::Handle<i::JSArray> stackFrame =
i::Factory::NewJSArray(4);
Why JSArray, not FixedArray?
No reason. Was just following precedent from other parts of the code. I
should
just change to a fixedArray.
http://codereview.chromium.org/1694011/diff/1/3#newcode4100
src/api.cc:4100: elements->set(0, script_name);
I'm not sure it is OK to return internal handle types. I think you need to
convert them.
I'm not sure I follow. I return an external handle type from this function
at
the end. It is a 2D v8::Array, so the caller never actually deals with an
internal Handle.
http://codereview.chromium.org/1694011/show
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
