The SafeStackFrameIterator used by CPU profiler checked if Isolate::c_entry_fp is null and if it is not it would think that the control flow currently is in some native code. This assumption is wrong because the native code could have called a JS function but JSEntryStub would not reset c_entry_fp to NULL in that case. This CL adds a check in SafeStackFrameIterator::IsValidTop for the case when there is a JAVA_SCRIPT frame on top of EXIT frame.
Also this CL changes ExternalCallbackScope behavior to provide access to the whole stack of the scope objects instead of only top one. This allowed to provide exact callback names for those EXIT frames where external callbacks are called. Without this change it was possible only for the top most native call.
BUG=None
R=loislo@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/19775017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This removes the isolate=>heap=>isolate nonsense and has the additional bonus
that it re-enables printing of code objects in GDB. NOT: To make the latter
work, one has to adapt GDB any macros using FindCodeObject! Keeping things as it
is and outlining Isolate::heap() was not really an option...
Side note: Currently we are lucky that we still have Isolate::Current()
available in GDB, although it is marked as INLINE. :-}
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/19785004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15770 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Their values are not used neither by the tick processor nor by CpuProfiler so it is just a waste of space.
TickSample used to be a transport for grabbed register values to TickSample::Trace, now they are passed in a special structure RegisterState which is allocated on the stack for the sampling period.
Some common pieces were moved from platform-dependent code into Sampler::SampleStack and TickSample::Init.
BUG=None
R=jkummerow@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/18620002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15484 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When pc is inside FunctionApply builtin function the top frame may be either
2) Internal stack frame created by FunctionApply itself.
In this case we know its caller's pc and can correctly resolve calling function.
1) Frame of the calling JavaScript function that invoked .apply(). In this case we have no practical reliable way to find out the caller's pc so we mark the caller's frame as 'unresolved'.
All this logic is implemented in ProfileGenerator. SafeStackFrameIterator is extended to provide type of the current top stack frame (iteration actually starts from the caller's frame as we know top function from pc).
BUG=252097
R=jkummerow@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/18269003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15468 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change introduces StackFrameIteratorBase which owns singleton frame instances and encapsulates some basic iterator functionality. It has two actual implementations: StackFrameIterator and SafeStackFrameIterator.
All logic specific to frame iteration at a random point (basically checks that fp and sp extracted from stack frames are within current stack boundaries) used only by CPU profiler is now concentrated in SafeStackFrameIterator.
Generic stack iteration used in all other places is put into StackFrameIterator. Also this iterator unlike SafeStackFrameIterator iterates through stack handlers.
StackAddressValidator and ExitFrameValidator classes were removed in favor of inline checks and simple methods.
BUG=None
R=loislo@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/17819003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15349 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
CPU profiler doesn't use stack handlers so there is no need to iterate through them while traversing stack. This change SafeStackFrameIterator always iterate only frames and removes checks corresponding to the handlers iteration.
The problem described in the bug occurred because of a false assumption in SafeStackFrameIterator that if Isolate::c_entry_fp is not NULL then the top frame on the stack is always a C++ frame. It is false because we may have entered JS code again, in which case JS_ENTRY code stub generated by JSEntryStub::GenerateBody() will save current c_entry_fp value but not reset it to NULL and after that it will create ENTRY stack frame and JS_ENTRY handler on the stack and put the latter into Isolate::handler(top). This means that if we start iterating from c_entry_fp frame and try to compare the frame's sp with Isolate::handler()->address() it will turn out that frame->sp() > handler->address() and the condition in SafeStackFrameIterator::CanIterateHandles is not held.
BUG=252097
R=loislo@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/17589022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15348 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change removes per-isolate counter of active SafeStackFrameIterators. The counter is used by stack frames implementations to avoid accessing pointers to heap objects when traversing stack for CPU profiler (so called "safe" mode). Each StackFrame instance is owned by single iterator and has a pointer to it so we can simply mark the iterator as "safe" or not and read the field in the stack frames instead of going into the isolate.
BUG=None
R=loislo@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/17585008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15317 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In order to fix https://code.google.com/p/chromium/issues/detail?id=252097 I
need to change SafeStackTraceFrameIterator. Stack iterators hierarchy looks
excessively complicated and I'd like to flatten it a bit by removing some
intermediate classes. In particular there are two hierarchies sharing
JavaScriptFrameIteratorTemp<T> template for no good reason.
This change extracts some of JavaScriptFrameIteratorTemp functionality directly
into SafeStackTraceFrameIterator. This made it obvious that a few checks were
performed twice.
The rest of JavaScriptFrameIteratorTemp<T> is merged with
JavaScriptFrameIterator. Now that the class is not a template some of its
implementation is moved from frames-inl.h into frames.cc
So in this change I removed JavaScriptFrameIterator and
SafeJavaScriptFrameIterator. As the next step I'm going to merge
SafeStackFrameIterator into SafeStackTraceFrameIterator.
BUG=None
R=loislo@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/16917004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15275 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
