According to our style guide on Copyable and Movable Types,
copy/move operators should be disabled in the public: section, not
in the private: section. If disabled with a macro such as
DISALLOW_COPY_AND_ASSIGN, it should be at the end of the private: section,
and should be the last thing in the class.
BUG=
Review-Url: https://codereview.chromium.org/2271043003
Cr-Commit-Position: refs/heads/master@{#38878}
This implements graph construction for entry via on-stack replacement
within the {BytecodeGraphBuilder}. Entry points are at loop headers
similar to previous OSR implementations. All interpreter registers are
addressable via {OsrValue} nodes in the graph. Currently we rely on
{OsrPoll} bytecodes to be placed right after loop headers (i.e. at the
targets of back edges).
R=jarin@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2171083004
Cr-Commit-Position: refs/heads/master@{#38083}
Stack trace generation requires access to the receiver; and while the
receiver is already on the stack, we cannot determine its position
during stack trace generation (it's stored in argv[0], and argc is only
stored in a callee-saved register).
This patch grants access to the receiver by pushing argc onto builtin
exit frames as an extra argument. Compared to simply pushing the
receiver, this requires an additional dereference during stack trace
generation, but one fewer during builtin calls.
BUG=v8:4815
Review-Url: https://codereview.chromium.org/2106883003
Cr-Commit-Position: refs/heads/master@{#37500}
Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.
Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.
BUG=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg
Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
Review-Url: https://codereview.chromium.org/2090723005
Cr-Original-Commit-Position: refs/heads/master@{#37384}
Cr-Commit-Position: refs/heads/master@{#37416}
Reason for revert:
Looks like this breaks on nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/7626
Original issue's description:
> [builtins] New frame type for exits to C++ builtins
>
> Prior to this commit, calls to C++ builtins created standard exit
> frames, which are skipped when constructing JS stack traces. In order to
> show these calls on traces, we introduce a new builtin exit frame type.
>
> Builtin exit frames contain target and new.target on the stack and are
> not skipped during stack trace construction.
>
> BUG=v8:4815
> R=bmeurer@chromium.org, yangguo@chromium.org
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
> Cr-Commit-Position: refs/heads/master@{#37384}
TBR=yangguo@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4815
Review-Url: https://codereview.chromium.org/2106113002
Cr-Commit-Position: refs/heads/master@{#37394}
Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.
Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.
BUG=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review-Url: https://codereview.chromium.org/2090723005
Cr-Commit-Position: refs/heads/master@{#37384}
This changes many interfaces to accept StandardFrames instead of
JavaScriptFrames, and use the StackTraceFrameIterator instead of the
JavaScriptFrameIterator.
Also, the detailed frame information array now contains the script in
addition to the function, as wasm frames are not associated to any
javascript function.
This is a rebase of (https://codereview.chromium.org/2069823003/), since clemensh's internship has ended.
R=yangguo@chromium.org,ahaas@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2109093003
Cr-Commit-Position: refs/heads/master@{#37379}
This adds a new BUILTIN frame type, which supports variable number of
arguments for builtins implemented in hand-written native code (we will
extend this mechanism to TurboFan builtins at some point). Convert the
Math.max and Math.min builtins to construct a BUILTIN frame if required.
This does not yet work for C++ builtins, but that'll be the next step.
R=bmeurer@chromium.org, jarin@chromium.org
BUG=v8:4815
LOG=n
Review-Url: https://codereview.chromium.org/2069423002
Cr-Commit-Position: refs/heads/master@{#37051}
Empty function names are allowed and are output as such, unnamed
functions or functions with no valid UTF-8 name are output as
"<WASM UNNAMED>", while the CallSite object returns null as the
function name.
R=titzer@chromium.org, yangguo@chromium.org
Review-Url: https://codereview.chromium.org/1970503004
Cr-Commit-Position: refs/heads/master@{#36348}
This changes different locations to extract the reference to the wasm
object and the function index from the stack trace, and make it
available through all the APIs which process stack traces.
The javascript CallSite object now has the new methods isWasm(),
getWasmObject() and getWasmFunctionIndex(); the byte offset is
available via getPosition().
Function names of wasm frames should be fully functional with this
commit, position information works reliably for calls, but not for
traps like unreachable or out-of-bounds accesses.
R=titzer@chromium.org, yangguo@chromium.org
Review-Url: https://codereview.chromium.org/1909353002
Cr-Commit-Position: refs/heads/master@{#36067}
The approximate mode enables taking an approximate stack trace from GC,
where the top frames might be missing if inlined. Note that in that case,
the frame summary will refer to optimized code, so it will not be possible
to take source position. (The user of the summary will have to handle the
case frame_summary.abstract_code()->kind() == AbstractCode::OPTIMIZED_CODE
specially.)
Review URL: https://codereview.chromium.org/1907443002
Cr-Commit-Position: refs/heads/master@{#35728}
Removes the register file machine register from the interpreter and
replaces it will loads from the parent frame pointer. As part of this
change the raw operand values for register values changes to enable the
interpreter to keep using the operand value as the offset from the
parent frame pointer.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1894063002
Cr-Commit-Position: refs/heads/master@{#35618}
Reason for revert:
performance impact
Original issue's description:
> Correctly annotate eval origin.
>
> There were a couple of issues with it:
> - interpreter is not supported
> - the source position was just accidentally correct for full-codegen
> - the eval origin could have been cached
>
> Also fixes a few other places to use AbstractCode.
>
> R=mstarzinger@chromium.org
>
> Committed: https://crrev.com/2f3a171adc9e620c2235bf0562145b9d4eaba66d
> Cr-Commit-Position: refs/heads/master@{#35257}
>
> Committed: https://crrev.com/ad4e8a27963b704bb70ec8bac0991c57296b1d16
> Cr-Commit-Position: refs/heads/master@{#35481}
TBR=mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1888013002
Cr-Commit-Position: refs/heads/master@{#35491}
This particularly changes the StackTraceFrameIterator such that is not
only returs JavaScriptFrames, but also WasmFrames. Because of that,
some methods (Summarize, function, receiver) were pulled up to the
StandardFrame, with specializations in JavaScriptFrame and WasmFrame.
R=jfb@chromium.org, titzer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1861283002
Cr-Commit-Position: refs/heads/master@{#35293}
Introduce a ResumeGeneratorTrampoline, which does the actual stack state
reconstruction (currently always restores a fullcodegen frame), and
introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
%GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
this native builtin.
Also unify the flooding in case of step-in to always work based on
JSFunction and remove the special casing for JSGeneratorObject.
R=mstarzinger@chromium.org, neis@chromium.orgTBR=rossberg@chromium.org
BUG=chromium:513471
LOG=n
Review URL: https://codereview.chromium.org/1865833002
Cr-Commit-Position: refs/heads/master@{#35283}
There were a couple of issues with it:
- interpreter is not supported
- the source position was just accidentally correct for full-codegen
- the eval origin could have been cached
Also fixes a few other places to use AbstractCode.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1854713002
Cr-Commit-Position: refs/heads/master@{#35257}
Before this CL, various code stubs used different techniques
for marking their frames to enable stack-crawling and other
access to data in the frame. All of them were based on a abuse
of the "standard" frame representation, e.g. storing the a
context pointer immediately below the frame's fp, and a
function pointer after that. Although functional, this approach
tends to make stubs and builtins do an awkward, unnecessary
dance to appear like standard frames, even if they have
nothing to do with JavaScript execution.
This CL attempts to improve this by:
* Ensuring that there are only two fundamentally different
types of frames, a "standard" frame and a "typed" frame.
Standard frames, as before, contain both a context and
function pointer. Typed frames contain only a minimum
of a smi marker in the position immediately below the fp
where the context is in standard frames.
* Only interpreted, full codegen, and optimized Crankshaft and
TurboFan JavaScript frames use the "standard" format. All
other frames use the type frame format with an explicit
marker.
* Typed frames can contain one or more values below the
type marker. There is new magic macro machinery in
frames.h that simplifies defining the offsets of these fields
in typed frames.
* A new flag in the CallDescriptor enables specifying whether
a frame is a standard frame or a typed frame. Secondary
register location spilling is now only enabled for standard
frames.
* A zillion places in the code have been updated to deal with
the fact that most code stubs and internal frames use the
typed frame format. This includes changes in the
deoptimizer, debugger, and liveedit.
* StandardFrameConstants::kMarkerOffset is deprecated,
(CommonFrameConstants::kContextOrFrameTypeOffset
and StandardFrameConstants::kFrameOffset are now used
in its stead).
LOG=N
Review URL: https://codereview.chromium.org/1696043002
Cr-Commit-Position: refs/heads/master@{#34571}
Frames entering of inside wasm don't have a function or context argument.
Adding distinct wasm frame and function types to express this.
Fixes a GC issue on several embenchen wasm tests, reenabling them.
BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/wasm/embenchen
R=titzer@chromium.org,aseemgarg@chromium.org,jfb@chromium.org,yangguo@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1764603003
Cr-Commit-Position: refs/heads/master@{#34476}
For now WasmFrame doesn't summarize the wasm frames. That'll require adding the
metadata in wasm-compiler similar to DeoptimizationInputData.
Teach the basic backtrace to iterate over stack frames instead of JS frames.
Update the wasm stack test.
`git cl format` touches random lines in files I touch.
R=titzer@chromium.org
TEST=d8 --test --expose-wasm test/mjsunit/mjsunit.js test/mjsunit/wasm/stack.js
Originally landed in: https://codereview.chromium.org/1712003003/
Reverted in: https://codereview.chromium.org/1730673002/
This patch puts the JSFunction on the C++ stack.
Review URL: https://codereview.chromium.org/1724063002
Cr-Commit-Position: refs/heads/master@{#34225}
Reason for revert:
[Sheriff] Seems to break gcmole:
https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/8295
Original issue's description:
> Add WasmFrame, backtraces reflect wasm's presence
>
> For now WasmFrame doesn't summarize the wasm frames. That'll require adding the
> metadata in wasm-compiler similar to DeoptimizationInputData.
>
> Teach the basic backtrace to iterate over stack frames instead of JS frames.
>
> Update the wasm stack test.
>
> `git cl format` touches random lines in files I touch.
>
> R=titzer@chromium.org
> TEST=d8 --test --expose-wasm test/mjsunit/mjsunit.js test/mjsunit/wasm/stack.js
>
> Committed: https://crrev.com/aeca945786dcccad3efecfddbf2c07aefa524a56
> Cr-Commit-Position: refs/heads/master@{#34220}
TBR=titzer@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,jfb@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1730673002
Cr-Commit-Position: refs/heads/master@{#34221}
For now WasmFrame doesn't summarize the wasm frames. That'll require adding the
metadata in wasm-compiler similar to DeoptimizationInputData.
Teach the basic backtrace to iterate over stack frames instead of JS frames.
Update the wasm stack test.
`git cl format` touches random lines in files I touch.
R=titzer@chromium.org
TEST=d8 --test --expose-wasm test/mjsunit/mjsunit.js test/mjsunit/wasm/stack.js
Review URL: https://codereview.chromium.org/1712003003
Cr-Commit-Position: refs/heads/master@{#34220}
Frame slots indexes numbers are used more consistently for
computation in both TurboFan and Crankshaft. Specifically,
Crankshaft now uses frame slot indexes in LChunk, removing
the need for some special-case maths when building the
deoptimization translation table.
LOG=N
R=mstarzinger@chromium.org
Committed: https://crrev.com/81423b84dbb2eaf7e1a57b0f6029fc8e643b4755
Cr-Commit-Position: refs/heads/master@{#34078}
Review URL: https://codereview.chromium.org/1702593002
Cr-Commit-Position: refs/heads/master@{#34114}
Frame slots indexes numbers are used more consistently for
computation in both TurboFan and Crankshaft. Specifically,
Crankshaft now uses frame slot indexes in LChunk, removing
the need for some special-case maths when building the
deoptimization translation table.
LOG=N
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1702593002
Cr-Commit-Position: refs/heads/master@{#34078}
Various places assume that GetExpression returns the locals for a frame.
Modify InterpretedFrames such that GetExpression(0) returns the first
local, not the fixed parts of the interpreter frame.
BUG=v8:4690,v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1697223003
Cr-Commit-Position: refs/heads/master@{#34040}
Replaces the push of the dispatch table on the interpreted stack frame with a
push of the bytecode array. This enables the debugger to replace the bytecode
array with a patched version containing breakpoints.
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1699013002
Cr-Commit-Position: refs/heads/master@{#34032}
Saves and restores the dispatch pointer during calls to enable the debugger to
switch the dispatch table used by a function during it's execution.
Also moves the accumulator and context nodes to be Variables so that they will
be properly merged across branches.
BUG=v8:4280,v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1684073002
Cr-Commit-Position: refs/heads/master@{#33894}
This makes the field in question more generic by renaming it from the
previous "depth" to "data". Pure refactoring, no function change.
R=rmcilroy@chromium.org,yangguo@chromium.org
Review URL: https://codereview.chromium.org/1670983003
Cr-Commit-Position: refs/heads/master@{#33779}
This implements proper context switching while unwinding the stack due
to an exception being handled in interpreted code. The context under
which the handler is scoped is being preserved in a dedicated register
while the try-block is running. Both, the stack unwinding machinery as
well as the graph builder, restore the context from that register.
R=rmcilroy@chromium.org,bmeurer@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1665833002
Cr-Commit-Position: refs/heads/master@{#33733}
This change adds AbstractCode, which can be either Code or
BytecodeArray, and adds methods to calculate source position based
on that. Also cleans up to use code offsets instead of raw PC
where possible, and consistently uses the offset from instruction
start (as opposed to code object start).
R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1618343002
Cr-Commit-Position: refs/heads/master@{#33579}
This implements a first prototype of stack unwinding for interpreted
frames. The unwinding machinery performs a range-based lookup in the
given handler table and potentially continues dispatching at the handler
offset. Note that this does not yet correctly restore the context to the
correct value when the handler is being entered.
R=rmcilroy@chromium.org,oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1605633003
Cr-Commit-Position: refs/heads/master@{#33414}
Adds support for generating deoptimization translations for interpreter
stack frames, and building interpreter frames for these translations
when a function deopts. Also adds builtins for
InterpreterNotifyDeoptimized which resume the function's continuation at
the correct point in the interpreter after deopt.
MIPS patch contributed by balazs.kilvady@igmtec.com
BUG=v8:4280
LOG=N
TEST=test-deoptimization.cc with --ignition and --turbo
Review URL: https://codereview.chromium.org/1528913003
Cr-Commit-Position: refs/heads/master@{#32971}
Adds a slot for the bytecode offset to interpreter stack frames and
saves it on calls, and restores after calls.
Also fixes RawMachineAssembler::Return() to call MergeControlToEnd.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1512543002
Cr-Commit-Position: refs/heads/master@{#32906}
This drops the specific slot containing the new.target value from our
construct stub frames. This side-channel has been deprecated and will
no longer be accessed by any consumers.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1489353004
Cr-Commit-Position: refs/heads/master@{#32550}
This passes the new.target value in a register instead of through a
side-channel via the construct stub. The interpreter entry trampoline
stores this value in a bytecode register so that it can be accessed
directly by the interpreter. The size of the interpreter stack frame
hence grows by one slot.
R=oth@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1469313002
Cr-Commit-Position: refs/heads/master@{#32264}
This aligns the naming of "new target" with the spec text throughout
TurboFan and the stack frame walker. The goal is to avoid unnecessary
confusion for people familiar with the spec.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1442643002
Cr-Commit-Position: refs/heads/master@{#31978}
Fills out some more of the function prologue support in the
interpreter. Deals with creation of arguments objects and throwing
IllegalRedeclarations if necessary. Also adds (untested) support for
this.function and new.target variable assignment.
Also fixes a bug in Frames::is_java_script() to deal with
interpreter frames correctly.
Cleans up comments in builtins InterpreterEntryTrampoline about
missing prologue support.
Adds the following bytecodes:
- CreateArgumentsSloppy
- CreateArgumentsStrict
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1412953007
Cr-Commit-Position: refs/heads/master@{#31486}
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}
Implements support for declaring global variables. Also adds support for loading
from and storing to both global and unallocated global variables. Adds the
following bytecodes:
- StoreGlobal
- LoadContextSlot
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1378523005
Cr-Commit-Position: refs/heads/master@{#31166}
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}
