- 25 Mar, 2015 1 commit
-
-
mstarzinger authored
This switches full-codegen to no longer push and pop StackHandler markers onto the operand stack, but relies on a range-based handler table instead. We only use StackHandlers in JSEntryStubs to mark the transition from C to JS code. Note that this makes deoptimization and OSR from within any try-block work out of the box, makes the non-exception paths faster and should overall be neutral on the memory footprint (pros). On the other hand it makes the exception paths slower and actually throwing and exception more expensive (cons). R=yangguo@chromium.org TEST=cctest/test-run-jsexceptions/DeoptTry Review URL: https://codereview.chromium.org/1010883002 Cr-Commit-Position: refs/heads/master@{#27440}
-
- 18 Mar, 2015 1 commit
-
-
mstarzinger authored
This relands commit 96f79568. This makes the Isolate::Throw logic not depend on a prediction of whether an exception is caught or uncaught. Such a prediction is inherently undecidable because a finally block can decide between consuming or re-throwing an exception depending on arbitray control flow. There still is a conservative prediction mechanism in place that components like the debugger or tracing can use for reporting. With this change we can get rid of the StackHandler::kind field, a pre-requisite to do table-based lookups of exception handlers. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/997213003 Cr-Commit-Position: refs/heads/master@{#27263}
-
- 16 Mar, 2015 2 commits
-
-
mstarzinger authored
Revert of Remove kind field from StackHandler. (patchset #4 id:60001 of https://codereview.chromium.org/1002203002/) Reason for revert: Layout test failure in inspector/sources/debugger/debugger-pause-on-promise-rejection.html Original issue's description: > Remove kind field from StackHandler. > > This makes the Isolate::Throw logic not depend on a prediction of > whether an exception is caught or uncaught. Such a prediction is > inherently undecidable because a finally block can decide between > consuming or re-throwing an exception depending on arbitray control > flow. > > There still is a conservative prediction mechanism in place that > components like the debugger or tracing can use for reporting. > > With this change we can get rid of the StackHandler::kind field, a > pre-requisite to do table-based lookups of exception handlers. > > R=yangguo@chromium.org > > Committed: https://crrev.com/96f79568a926966ebcf0685bf9adc947f4e1fbff > Cr-Commit-Position: refs/heads/master@{#27210} TBR=yangguo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1009903002 Cr-Commit-Position: refs/heads/master@{#27215}
-
mstarzinger authored
This makes the Isolate::Throw logic not depend on a prediction of whether an exception is caught or uncaught. Such a prediction is inherently undecidable because a finally block can decide between consuming or re-throwing an exception depending on arbitray control flow. There still is a conservative prediction mechanism in place that components like the debugger or tracing can use for reporting. With this change we can get rid of the StackHandler::kind field, a pre-requisite to do table-based lookups of exception handlers. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1002203002 Cr-Commit-Position: refs/heads/master@{#27210}
-
- 10 Mar, 2015 2 commits
-
-
mstarzinger authored
This reduces the size of the StackHandler by yet another word. We no longer need to keep track of the frame pointer, as the stack walk will be able to recalculate it. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/991893003 Cr-Commit-Position: refs/heads/master@{#27115}
-
mstarzinger authored
This reduces the size of the StackHandler by one word. We no longer need to keep track of the code object, as the stack walk finds it. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/985803002 Cr-Commit-Position: refs/heads/master@{#27103}
-
- 05 Mar, 2015 1 commit
-
-
mstarzinger authored
This extends the stack unwinding logic to respect optimized frames and perform a lookup in the handler table to find handlers. It also contains fixes to the API call stubs to allow a stack walk while promoting scheduled exceptions. R=jarin@chromium.org TEST=cctest/test-run-jsexceptions Review URL: https://codereview.chromium.org/969533004 Cr-Commit-Position: refs/heads/master@{#27016}
-
- 03 Mar, 2015 1 commit
-
-
mstarzinger authored
R=jarin@chromium.org Review URL: https://codereview.chromium.org/960273002 Cr-Commit-Position: refs/heads/master@{#26957}
-
- 01 Oct, 2014 1 commit
-
-
svenpanne@chromium.org authored
These are some changes split off from https://codereview.chromium.org/422063005 frames-inl.h, frames.h based on https://github.com/andrewlow/v8ppc/commit/05db7d2d714c44bd4e0b710fdaa51d34938aaa27 On 64bit big endian systems, the integer value is in the second slot, thus we need a new offset. objects-inl.h, objects.h based on https://github.com/andrewlow/v8ppc/commit/09b680b2af7412fe8fa5a3a01f1b8e29698d7797 Similarly, the hash slot is an integer field and we need to do the right thing on 64bit big endian systems objects.cc based on: https://github.com/andrewlow/v8ppc/commit/065742b0783b0705d9f9711198248a92bac11d85 Prettier printing of constant pools test-strings.cc based on: https://github.com/andrewlow/v8ppc/commit/9889d60cd6e68e0d248c4a362ffdff0755b92aec endian fixes BUG= R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/551803004 Patch from Andrew Low <andrew_low@ca.ibm.com>. git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24365 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Aug, 2014 1 commit
-
-
bmeurer@chromium.org authored
This way we don't clash with the ASSERT* macros defined by GoogleTest, and we are one step closer to being able to replace our homegrown base/ with base/ from Chrome. R=jochen@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/430503007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Jul, 2014 1 commit
-
-
jkummerow@chromium.org authored
Also add IC tracing to a path where it was missing. R=jarin@chromium.org Review URL: https://codereview.chromium.org/368833003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22268 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
- this avoids using relative include paths which are forbidden by the style guide - makes the code more readable since it's clear which header is meant - allows for starting to use checkdeps BUG=none R=jkummerow@chromium.org, danno@chromium.org LOG=n Review URL: https://codereview.chromium.org/304153016 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 May, 2014 1 commit
-
-
yangguo@chromium.org authored
R=ulan@chromium.org Review URL: https://codereview.chromium.org/261253005 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21270 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/259183002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Mar, 2014 1 commit
-
-
jochen@chromium.org authored
BUG=354405 R=ulan@chromium.org, rodolph.perfetta@arm.com LOG=y Review URL: https://codereview.chromium.org/207823003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20148 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Mar, 2014 1 commit
-
-
rmcilroy@chromium.org authored
Ensure that the stack contains the correct constant pool pointer when a function deopts. This CL depends on https://codereview.chromium.org/183803022/ landing first. R=ulan@chromium.org Review URL: https://codereview.chromium.org/188063002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19940 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Feb, 2014 1 commit
-
-
ulan@chromium.org authored
BUG=v8:3113 LOG=Y R=jochen@chromium.org, rmcilroy@chromium.org, rodolph.perfetta@arm.com Review URL: https://codereview.chromium.org/148293020 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19311 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Jan, 2014 1 commit
-
-
rmcilroy@chromium.org authored
This CL fixes some bugs in the out of line constant pool implementation when constant pools are GCed. Namely: - Push/Pop pp register in exit frames and VisitPointer on it to ensure it is updated if the ConstantPoolArray is moved by GC. - Mark pp as a SafePoint Register for optimized functions. - Ensure that StandardFrame::IterateExpressions also iterates over the constant pool pointer in the stackframe. - Fix calculation of last_ptr_offset in ConstantPoolArray body iterator. - Make ensure that CONSTANT_POOL_ARRAY_TYPE is a pointer object InstanceType. R=ulan@chromium.org Review URL: https://codereview.chromium.org/123263005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18473 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Dec, 2013 1 commit
-
-
rmcilroy@chromium.org authored
Third stage of implementing an out-of-line constant pool for Arm. This CL adds a ConstantPool field to Code objects and initializes the pp register on function entry, and saves the pp register on the stack frame. The ConstantPool object is always empty and is unused currently. R=ulan@chromium.org Review URL: https://codereview.chromium.org/88043002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18425 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Nov, 2013 1 commit
-
-
rmcilroy@chromium.org authored
R=ulan@chromium.org Review URL: https://codereview.chromium.org/60763006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17925 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Oct, 2013 1 commit
-
-
danno@chromium.org authored
This change means that code which is never executed is garbage collected immediately, and code which is only executed once is collected more quickly (limiting heap growth), however, code which is re-executed is reset to the young age, thus being kept around for the same number of GC generations as currently. BUG=280984 R=danno@chromium.org, hpayer@chromium.org Review URL: https://codereview.chromium.org/23480031 Patch from Ross McIlroy <rmcilroy@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17343 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Jul, 2013 1 commit
-
-
haitao.feng@intel.com authored
The FP setting is different for X32 than the other platforms as kFPOnStackSize is double the kPointerSize and we have to clear the higher 32 bits to 0. R=danno@chromium.org Review URL: https://codereview.chromium.org/20073004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15966 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Jul, 2013 4 commits
-
-
yurys@chromium.org authored
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
-
haitao.feng@intel.com authored
BUG=None R=danno@chromium.org Review URL: https://codereview.chromium.org/19802002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15829 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
haitao.feng@intel.com authored
Revert "Addressed danno's comments" and "Introduce kRegisterSize, kPCOnStackSize and kFPOnStackSize constants" BUG=None R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/19483007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15824 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
haitao.feng@intel.com authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15822 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Jul, 2013 1 commit
-
-
titzer@chromium.org authored
BUG= Review URL: https://codereview.chromium.org/18404009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15638 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jul, 2013 2 commits
-
-
yurys@chromium.org authored
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
-
yurys@chromium.org authored
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
-
- 28 Jun, 2013 1 commit
-
-
danno@chromium.org authored
Adds more coverage for function entry hook, sufficient to capture profiles that are contiguous from C++, through JS and back out to C++. R=danno@chromium.org Committed: http://code.google.com/p/v8/source/detail?r=15361 Review URL: https://codereview.chromium.org/16578008 Patch from Sigurður Ásgeirsson <siggi@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15384 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 Jun, 2013 4 commits
-
-
ulan@chromium.org authored
R=siggi@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/18062006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15365 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
danno@chromium.org authored
Adds more coverage for function entry hook, sufficient to capture profiles that are contiguous from C++, through JS and back out to C++. R=danno@chromium.org Review URL: https://codereview.chromium.org/16578008 Patch from Sigurður Ásgeirsson <siggi@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15361 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
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
-
yurys@chromium.org authored
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
-
- 25 Jun, 2013 2 commits
-
-
yurys@chromium.org authored
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
-
yurys@chromium.org authored
SafeStackFrameIterator was used solely to implement SafeStackTraceFrameIterator. This CL simply merges them and updates usage of SafeStackTraceFrameIterator to use SafeStackFrameIterator (a bit shorter name). BUG=None R=loislo@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/17579005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15305 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Jun, 2013 2 commits
-
-
yurys@chromium.org authored
The method has identical implementation for all architectures. Moved it into frames.cc Drive-by: deleted SafeStackFrameIterator::is_working_iterator_, SafeStackFrameIterator::iteration_done_ is used instead. BUG=None R=loislo@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/17581004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15293 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
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
-
- 17 May, 2013 1 commit
-
-
mstarzinger@chromium.org authored
This unifies the translation of an optimized frame to a full JavaScript frame. Only the frame's context and fp register as well as alignment padding are different on each architecture and can be factored out. R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/14843020 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 May, 2013 1 commit
-
-
wingo@igalia.com authored
This CL adds machinery to unwind stack handlers from the stack and store them into a generator's operand array. It also includes routines to reinstate them. Together this allows generators to yield within try/catch and try/finally blocks. BUG=v8:2355 R=mstarzinger@chromium.org TEST=mjsunit/harmony/generators-iteration Review URL: https://codereview.chromium.org/14031028 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14586 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-