On 2010/04/22 18:17:54, jaimeyap wrote:
Requesting feedback. Will cover with appropriate test cases once
consensus is
reached on what the API should look like.
First of all it is fine to have an ability to get stack trace information
from
the C++ API. Maybe it should be in the normal API instead of in the debug
API.
As far as I can see the basic stack traversal is the same as is used in
Runtime_CollectStackTrace, but instead of just storing relevant information
from
the frame some calculations are done along the way. The main purpose of
Runtime_CollectStackTrace is to be fast at collecting data as the
information
will most likely be discarded.
Also you new API will not avoid garbage collection as is allocates new
objects
and calls functions which might allocate objects as well.
I don't think you should mention any specific numbers on the speed of one
API
over another. This may change over time, and each API provides different
levels
of information.
From the API point of wiev I think the information returned should be
presented
as a C++ objects and not just an array of arrays. Internally using an array
is
fine, but I don't think it should be exposed. I think you should be able to
create objects which "wraps" the arrays generated just like the API objects
"wraps" internal handles. E.g. the class Message is an interface to an
internal
JS Object, and likewise class StackTrace and class StackFrame could be
interfaces to a FixedArray (no need for a JS Array then).
Local<v8::StackTrace> GetStackTrace(<flags to indicate level of
information>)
class StackTrace {
int GetFrameCount();
Local<v8::StackFrame> GetFrame(int index);
}
class StackFrame {
...
}
I also think that it should be possible to decide what information to get
hold
of using some kind of flags, so that we are not ending up with a fixed API
which
can only return two strings and two numbers for each frame.
Of cause patches to improve performance of the other ways of working with
the
stack are always welcome.
http://codereview.chromium.org/1694011/show
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
