There are several ways of collecting the stack. The debugger API has the function v8::Debug::Call where you pass a JavaScript function which will have the execution state passed and from there can do all the inspection of the stack which is required. I am not sure whether using this API will have the performance required as it will create a lot of mirror objects in the process, and stack traversal might still be n*2 in the stack height, however this might provide an opportunity to look more closely at the interface to stack inspection.
Another approach will be to use the more lightweight interface used to collect stack traces for exceptions. There the runtime function %CollectStackTrace is used - look in messages.js for the details (this was added in r2302). One way to leverage this then is to add a function v8::Debug::StackTrace(v8::Handle<v8::Function> fun = v8::Handle<v8::Function>(), int limit) where the function passed is given the array collected by %CollectStackTrace to process and return whatever makes sense. Passing an empty handle could return the result of the default formatting used in messages.js. /Søren On Thu, Feb 4, 2010 at 14:07, Pavel Feldman <[email protected]> wrote: > Please also note, that the real goal here is to get entire stack info for > the timeline entry. Does this change any views on the approach? > > Pavel > > 2010/2/4 Yury Semikhatsky <[email protected]> > > I suggest we measure performance of each approach taking into account that >> the code will be executed pretty often when timeline agent is on. Also the >> call into v8::Debug will make the debug context live 'forever' which would >> add additional memory overhead. >> >> Yury >> >> 2010/2/4 Søren Gjesse <[email protected]> >> >> Hi Ilya, >>> >>> The following code should illustrate how to use the function mirror to >>> get the source line. To run it you can add it to the end of the >>> GetMirror test in test/cctest/test-debug.cc and run tools/test.py cctest >>> /test-debug/GetMirror. >>> >>> v8::ScriptOrigin origin = >>> v8::ScriptOrigin(v8::String::New("test")); >>> v8::Script::Compile(script, &origin)->Run(); >>> v8::Local<v8::Function> f = >>> v8::Local<v8::Function>::Cast(env >>> ->Global()->Get(v8::String::New("f"))); >>> v8::Local<v8::Function> g = >>> v8::Local<v8::Function>::Cast(env >>> ->Global()->Get(v8::String::New("g"))); >>> >>> v8::Handle<v8::Value> mirror_f = v8::Debug::GetMirror(f); >>> v8::Handle<v8::Value> mirror_g = v8::Debug::GetMirror(g); >>> >>> v8::Handle<v8::Function> function_info = >>> v8::Handle<v8::Function>::Cast( >>> v8::Script::New( >>> v8::String::New( >>> "function functionInfo(mirror) {" >>> " return mirror.sourceLocation().line;" >>> "}" >>> "" >>> "functionInfo;"))->Run()); >>> result = function_info->Call(env->Global(), 1, &mirror_f); >>> CHECK_EQ(0, result->Int32Value()); >>> result = function_info->Call(env->Global(), 1, &mirror_g); >>> CHECK_EQ(3, result->Int32Value()); >>> >>> I suggest you return a JavaScript object which contains all the >>> information needed that is something like >>> >>> function functionInfo(mirror) { >>> return { script: script().name(), line: mirror.sourceLocation().line >>> } >>> } >>> >>> Look in src/mirror-delay.js to see what information is available for >>> object mirrors. >>> >>> /Søren >>> >>> On Wed, Feb 3, 2010 at 12:12, Søren Gjesse <[email protected]> wrote: >>> >>>> I think looking at performance is the right thing to do. Please try to >>>> use the GetMirror API in the code in V8Proxy.cpp, before adding devtools >>>> specific functions to the V8 debugger API. Remember that you can compile >>>> the >>>> JavaScript function taking the FunctionMirror object once. If using the >>>> mirror has a performance overhead then maybe providing more direct access >>>> to >>>> the script/line for a function on the FunctionMirror could solve the >>>> problem. >>>> >>>> If more features are needed in the debugger API I think the API should >>>> be more general, like providing a full mirror like API. >>>> >>>> Regards, >>>> Søren >>>> >>>> >>>> On Tue, Feb 2, 2010 at 18:26, Ilya Tikhonovsky <[email protected]>wrote: >>>> >>>>> Hi, >>>>> >>>>> Please see preliminary patch for third step. >>>>> >>>>> https://bugs.webkit.org/show_bug.cgi?id=33995 >>>>> >>>>> as far as that portion of code will be called a number of times I think >>>>> it would be nice to have a performance metrics for these possible >>>>> implementations. >>>>> Yury: Where I can implement this perf test? >>>>> Søren: in context of timeline implementation it does not necessary to >>>>> have the position it the row because we only select the corresponding >>>>> source >>>>> line, >>>>> but probably it will be useful for some other use cases. >>>>> The only situation when the position is really useful is an obfuscated >>>>> code. >>>>> >>>>> >>>>> <https://bugs.webkit.org/show_bug.cgi?id=33995> >>>>> Regards, >>>>> Tim. >>>>> >>>>> >>>>> >>>>> On Tue, Feb 2, 2010 at 6:55 AM, <[email protected]> wrote: >>>>> >>>>>> On 2010/02/02 00:41:55, loislo wrote: >>>>>> >>>>>>> A patch for v8 for extending Timeline panel's functionality. >>>>>>> >>>>>> Could you upload the patch where this new method is going to be used >>>>>> so that >>>>>> it's easier to evaluate whether the new API method is necessary? >>>>>> >>>>>> >>>>>> >>>>>> http://codereview.chromium.org/565007 >>>>>> >>>>> >>>>> >>>> >>> >> > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
