- 16 Oct, 2015 1 commit
-
-
rmcilroy authored
Adds basic support for iterating interpreter stack frames for GC. Currently InterpreterStackFrames are treated just like JavaScriptStackFrames since the JavaScriptFrame::IterateExpressions() will correctly iterate over all the local / temp interpeter Registers, and will iterate over the interpreter_entry_trampoline pc address. There is no need to explicitly iterate over the BytecodeArray object since that is held in a machine register in the bytecode handler which is marked as kMachTaggedAny by TurboFan, and so will get iterated appropriately when iterating the bytecode handler stub's stack frame. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1407513003 Cr-Commit-Position: refs/heads/master@{#31342}
-
- 30 Sep, 2015 1 commit
-
-
mstarzinger authored
This enables linter checking for "readability/namespace" violations during presubmit and instead marks the few known exceptions that we allow explicitly. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1371083003 Cr-Commit-Position: refs/heads/master@{#31019}
-
- 01 Sep, 2015 1 commit
-
-
mstarzinger authored
Now that it is no longer needed, this also removes the invalid inclusion of "object-inl.h" within the "unique.h" header file. Note that this change still leaves 2 violations of that rule in the code, checked with the "tools/check-inline-includes.sh" tool. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1321223002 Cr-Commit-Position: refs/heads/master@{#30503}
-
- 13 Jul, 2015 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1235893002 Cr-Commit-Position: refs/heads/master@{#29607}
-
- 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}
-
- 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}
-
- 16 Jan, 2015 1 commit
-
-
Sven Panne authored
Contribution of PowerPC port (continuation of 422063005). The inital patch covers the core changes to the common files. Subsequent patches will cover changes to common files to support AIX and to update the ppc directories so they are current with the changes in the rest of the project. This is based off of the GitHub repository https://github.com/andrewlow/v8ppc BUG= R=svenpanne@chromium.org, danno@chromium.org, sevnpanne@chromium.org Review URL: https://codereview.chromium.org/817143002 Cr-Commit-Position: refs/heads/master@{#26091}
-
- 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
-
- 09 Jul, 2014 1 commit
-
-
dusan.milosavljevic@rt-rk.com authored
Summary: - Changes in common code are mainly boilerplate changes, gyp and test status files updates. - On mips64 simulator all tests pass from all test units. - Current issues: mjsunit JS debugger tests fail randomly on HW in release mode. Corresponding tests are skipped on HW. - Skipped tests on mips64: test-heap/ReleaseOverReservedPages, mjsunit/debug-* TEST= BUG= R=danno@chromium.org, plind44@gmail.com, ulan@chromium.org Review URL: https://codereview.chromium.org/371923006 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22297 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Jun, 2014 1 commit
-
-
mstarzinger@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/333013002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21894 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
-
- 23 May, 2014 1 commit
-
-
danno@chromium.org authored
Support x87-only platform (ia32 without SSE) R=danno@chromium.org Review URL: https://codereview.chromium.org/293743005 Patch from Weiliang Lin <weiliang.lin@intel.com>. git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21469 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
-
- 23 Jul, 2013 1 commit
-
-
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
-
- 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
-
- 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 3 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
-
- 25 Jun, 2013 1 commit
-
-
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 1 commit
-
-
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
-
- 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
-
- 26 Apr, 2013 2 commits
-
-
mstarzinger@chromium.org authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/14143008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14463 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
This CL extends the generator suspend and resume implementation to capture values on the operand stack. It factors out some helpers to measure and access the operand stack into the JavaScriptFrame class. It also refactors the suspend and resume helpers to avoid handle allocation. BUG=v8:2355 TEST=mjsunit/harmony/generators-iteration Review URL: https://codereview.chromium.org/14348003 Patch from Andy Wingo <wingo@igalia.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14458 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Feb, 2013 1 commit
-
-
danno@chromium.org authored
Review URL: https://codereview.chromium.org/12093089 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13593 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Jan, 2013 1 commit
-
-
danno@chromium.org authored
In preparation of supporting stubs that deopt and then need to push their register-based parameters to an arguments area on the stack that gets properly collected, add StubFailureTrampolineFrames to hold those parameters. R=mstarzinger@chromium.org Review URL: https://chromiumcodereview.appspot.com/12052053 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13533 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Dec, 2012 1 commit
-
-
danno@chromium.org authored
R=jkummerow@chromium.org Review URL: https://chromiumcodereview.appspot.com/11528003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13236 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Dec, 2012 1 commit
-
-
danno@chromium.org authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/11498006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13179 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Dec, 2012 1 commit
-
-
danno@chromium.org authored
This initial implementation generates only KeyedLoadICs using the new Hydrogen stub infrastructure. Committed: https://code.google.com/p/v8/source/detail?r=13105 Committed: https://code.google.com/p/v8/source/detail?r=13117 Review URL: https://codereview.chromium.org/10701054 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13140 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Dec, 2012 2 commits
-
-
danno@chromium.org authored
TBR=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/11415261 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13120 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
danno@chromium.org authored
This initial implementation generates only KeyedLoadICs using the new Hydrogen stub infrastructure. Committed: https://code.google.com/p/v8/source/detail?r=13105 Review URL: https://codereview.chromium.org/10701054 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13117 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-