V8 tracks already most useful information, but lacks proper tracing scopes
that make it possible to distinguish certain events from each other.
- add trace-scope to track lazy-parsing due to optimization
- add trace-scope to track code optimization
BUG=
Review URL: https://codereview.chromium.org/1661883003
Cr-Commit-Position: refs/heads/master@{#34002}
This is mostly preparation for allowing the function closure to be materialized.
As a drive-by fix, I have added ignition source position support to the frame inspector (this fixed some ignition test failures).
Review URL: https://codereview.chromium.org/1698743002
Cr-Commit-Position: refs/heads/master@{#33975}
The idea here is to perform the handler lookup in the deoptimizer, and then take the information from the handler table to build the catch handler frame in the deoptimizer. Specifically, we use the pc offset, context location and stack height (in full-code) to tweak the output frame.
Sadly, this still requires nasty voodoo for the liveness analyzer so that it keeps variables alive if they are used in the catch handler.
Review URL: https://codereview.chromium.org/1416543006
Cr-Commit-Position: refs/heads/master@{#33936}
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 removes uses of JSFunction by the (proper) deoptimizer. This will be useful
when we escape analyze JSFunction away. Unfortunately, the debugger still needs
JSFunction, so escape analysis would not work yet.
Review URL: https://codereview.chromium.org/1686183003
Cr-Commit-Position: refs/heads/master@{#33891}
JS_FRAME_FUNCTION can be expressed using the STACK_SLOT translation.
Review URL: https://codereview.chromium.org/1688023003
Cr-Commit-Position: refs/heads/master@{#33882}
There are a bunch of places in our builtins where we use %_Arguments and
%_ArgumentsLength for no good reason, as arguments object and/or rest
parameter is as good and performant in these cases. Now the only uses
of %_Arguments and %_ArgumentsLength left are in string.js, which
requires dedicated investigation.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg
R=yangguo@chromium.org
Committed: https://crrev.com/2160429fd458e3c095475e718c97f77ac90d906f
Cr-Commit-Position: refs/heads/master@{#33834}
Review URL: https://codereview.chromium.org/1678953004
Cr-Commit-Position: refs/heads/master@{#33881}
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}
Rename IntepreterExceptionEntryHandler builtin to InterpreterEnterBytecodeDispatch
and use it as the return address when building interpreter frames during deopt.
This ensures that we restart execution of the outer frame at the correct
bytecode.
BUG=v8:4280,v8:4678
LOG=N
Review URL: https://codereview.chromium.org/1633633002
Cr-Commit-Position: refs/heads/master@{#33512}
Escape analysis will eliminate the context, if possible. Materialization
must then ensure that the materialized object has the right map, and that
the context register is set accordingly.
R=jarin@chromium.org
BUG=569530,v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1572293002
Cr-Commit-Position: refs/heads/master@{#33201}
Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.
Two unittests test correctness of the IR level implementation.
Correctness for instruction selection / code generation
is tested by mjsunit tests.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1485183002
Cr-Commit-Position: refs/heads/master@{#33115}
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}
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}
Moves all files related to AST and scopes into ast/,
and all files related to scanner & parser to parsing/.
Also eliminates a couple of spurious dependencies.
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1481613002
Cr-Commit-Position: refs/heads/master@{#32351}
Currently we still (mis)used some machine operators in typed lowering
(namely Word32Or, Word32Xor and Word32And). But these operators are
"polymorphic" in the signedness of their inputs and output, hence the
representation selection (and thereby simplified lowering) was unable to
figure out whether a bitwise operation that was seen would produce an
unsigned or a signed result. If such nodes also have frame state uses,
the only safe choice was float64, which was not only a lot less ideal,
but also the main cause of the for-in related deoptimizer loops.
Adding dedicated NumberBitwiseOr, NumberBitwiseAnd and NumberBitwiseXor
simplified operators not only gives us precise (and correct) typing for
the bitwise operations, but also allows us to actually verify the graph
properly after typed lowering.
Drive-by-fix: Remove the double-to-smi magic from the Deoptimizer, which
is responsible for various deopt-loops in TurboFan, and is no longer
needed with the addition of the NumberBitwise operators.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1422213002
Cr-Commit-Position: refs/heads/master@{#31594}
Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.
Some highlights of changes:
* TurboFan's RegisterConfiguration class moved to V8's top level
so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
different platforms is now shared.
* The list of allocatable registers on each platform is declared
as a list rather than implicitly via the register index <->
code mapping.
Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
Cr-Commit-Position: refs/heads/master@{#30913}
Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
Cr-Commit-Position: refs/heads/master@{#31075}
Review URL: https://codereview.chromium.org/1287383003
Cr-Commit-Position: refs/heads/master@{#31087}
Reason for revert:
Failures on MIPS
Original issue's description:
> Remove register index/code indirection
>
> Previous to this patch, both the lithium and TurboFan register
> allocators tracked allocated registers by "indices", rather than
> the register codes used elsewhere in the runtime. This patch
> ensures that codes are used everywhere, and in the process cleans
> up a bunch of redundant code and adds more structure to how the
> set of allocatable registers is defined.
>
> Some highlights of changes:
>
> * TurboFan's RegisterConfiguration class moved to V8's top level
> so that it can be shared with Crankshaft.
> * Various "ToAllocationIndex" and related methods removed.
> * Code that can be easily shared between Register classes on
> different platforms is now shared.
> * The list of allocatable registers on each platform is declared
> as a list rather than implicitly via the register index <->
> code mapping.
>
> Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
> Cr-Commit-Position: refs/heads/master@{#30913}
>
> Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
> Cr-Commit-Position: refs/heads/master@{#31075}
TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1380863004
Cr-Commit-Position: refs/heads/master@{#31083}
Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.
Some highlights of changes:
* TurboFan's RegisterConfiguration class moved to V8's top level
so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
different platforms is now shared.
* The list of allocatable registers on each platform is declared
as a list rather than implicitly via the register index <->
code mapping.
Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
Cr-Commit-Position: refs/heads/master@{#30913}
Review URL: https://codereview.chromium.org/1287383003
Cr-Commit-Position: refs/heads/master@{#31075}
Reason for revert:
Failures on greedy RegAlloc, Fuzzer
Original issue's description:
> Remove register index/code indirection
>
> Previous to this patch, both the lithium and TurboFan register
> allocators tracked allocated registers by "indices", rather than
> the register codes used elsewhere in the runtime. This patch
> ensures that codes are used everywhere, and in the process cleans
> up a bunch of redundant code and adds more structure to how the
> set of allocatable registers is defined.
>
> Some highlights of changes:
>
> * TurboFan's RegisterConfiguration class moved to V8's top level
> so that it can be shared with Crankshaft.
> * Various "ToAllocationIndex" and related methods removed.
> * Code that can be easily shared between Register classes on
> different platforms is now shared.
> * The list of allocatable registers on each platform is declared
> as a list rather than implicitly via the register index <->
> code mapping.
>
> Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
> Cr-Commit-Position: refs/heads/master@{#30913}
TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1365073002
Cr-Commit-Position: refs/heads/master@{#30914}
Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.
Some highlights of changes:
* TurboFan's RegisterConfiguration class moved to V8's top level
so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
different platforms is now shared.
* The list of allocatable registers on each platform is declared
as a list rather than implicitly via the register index <->
code mapping.
Review URL: https://codereview.chromium.org/1287383003
Cr-Commit-Position: refs/heads/master@{#30913}
This makes it clear that only components within the "heap" directory
should be friends with the Heap class. The two notable exceptions are
Factory and Isolate which represent external interfaces into the heap.
R=mlippautz@chromium.org
Review URL: https://codereview.chromium.org/1320843002
Cr-Commit-Position: refs/heads/master@{#30408}
Replaces all instances of the code which computed the debug
name of a stub or function with calls to CompileInfo::GetDebugName instead.
Also:
- Removes useless parameter on CodeStub::GetMajorName
- Removes FakeStubForTesting since it is no longer required
- Adds CompileInfo::ShouldEnsureSpaceForLazyDeopt() to replace unclear calls to IsStub().
Review URL: https://codereview.chromium.org/1297203002
Cr-Commit-Position: refs/heads/master@{#30324}
Previously, it was not possible to specify StackSlotOperands for all
slots in both the caller and callee stacks. Specifically, the region
of the callee's stack including the saved return address, frame
pointer, function pointer and context pointer could not be addressed
by the register allocator/gap resolver.
In preparation for better tail call support, which will use the gap
resolver to reconcile outgoing parameters, this change makes it
possible to address all slots on the stack, because slots in the
previously inaccessible dead zone may become parameter slots for
outgoing tail calls. All caller stack slots are accessible as they
were before, with slot -1 corresponding to the last stack
parameter. Stack slot indices >= 0 access the callee stack, with slot
0 corresponding to the callee's saved return address, 1 corresponding
to the saved frame pointer, 2 corresponding to the current function
context, 3 corresponding to the frame marker/JSFunction, and slots 4
and above corresponding to spill slots.
The following changes were specifically needed:
* Frame has been changed to explicitly manage three areas of the
callee frame, the fixed header, the spill slot area, and the
callee-saved register area.
* Conversions from stack slot indices to fp offsets all now go through
a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
* The generation of deoptimization translation tables has been changed
to support the new stack slot indexing scheme. Crankshaft, which
doesn't support the new slot numbering in its register allocator,
must adapt the indexes when creating translation tables.
* Callee-saved parameters are now kept below spill slots, not above,
to support saving only the optimal set of used registers, which is
only known after register allocation is finished and spill slots
have been allocated.
Review URL: https://codereview.chromium.org/1261923007
Cr-Commit-Position: refs/heads/master@{#30224}
The calculation now takes into account the size of the arguments object
if it is present in the optimized frame.
(Yang, many thanks for the awesome repro!)
BUG=chromium:514362
LOG=N
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1264483008
Cr-Commit-Position: refs/heads/master@{#29973}
This fixes a bug introduced by r28826 (Unify decoding of deoptimization
translations, https://codereview.chromium.org/1136223004), where we
started leaking arguments marker sentinel to the debugger, which would
then cause crashes. This change replaces the sentinel with the undefined
value in the debugger-inspectable frame.
BUG=chromium:514362
LOG=n
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1263333002
Cr-Commit-Position: refs/heads/master@{#29971}
All of this is controlled by the CallDescriptor. It's simply the case
that if you specify less registers than the function arity calls for,
the rest are assumed to be on the stack.
Bailout handlers accept these constant stack arguments too.
BUG=
Review URL: https://codereview.chromium.org/1250563004
Cr-Commit-Position: refs/heads/master@{#29813}
This reverts commit 80b3f16951.
Revert "Record code slots that may point to evacuation candidate objects after deoptimizing them."
This reverts commit 4621210cfe.
BUG=chromium:507840
LOG=n
Review URL: https://codereview.chromium.org/1239383004
Cr-Commit-Position: refs/heads/master@{#29778}
Additionally, push the allocation site or undefined independently of creating a memento to preserve a fixed size for the construct frames.
BUG=
Review URL: https://codereview.chromium.org/1239593003
Cr-Commit-Position: refs/heads/master@{#29719}
Note that there are currently no objects that require a pre-allocated
properties backing store, all such slots are in-object properties from
the begining. Hence {unused + pre_allocated - inobject == 0} holds.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1226203011
Cr-Commit-Position: refs/heads/master@{#29590}
The only right way to enable access checks is to install access check callbacks on an object template via v8::ObjectTemplate::SetAccessCheckCallbacks(). It does not make sense to enable access checks on an arbitrary object.
Review URL: https://codereview.chromium.org/1217893012
Cr-Commit-Position: refs/heads/master@{#29439}
Up until now the context register was listed explicitly in each stub's
CallInterfaceDescriptor. This was problematic, because it was listed
first in the list of register parameters--which is fine for Crankshaft,
which is more or less built to handle the context as the first
parameter-- but not ideal for TurboFan, which adds the context at
the end of all function parameters. Now the context register is no
longer in the register list and can be handled appropriately by both
compilers. Specifically, this allows the FunctionType specified for
each CallInterfaceDescriptor to exactly match the parameter register
list.
Review URL: https://codereview.chromium.org/1211333003
Cr-Commit-Position: refs/heads/master@{#29402}
On MIPS32 we can't read a 8 bytes long data from a not 8 bytes aligned memory address.
BUG=
TEST=mjsunit/debug-backtrace
Review URL: https://codereview.chromium.org/1193433002
Cr-Commit-Position: refs/heads/master@{#29100}
Up until now we can only inline based on JSFunction, because of the way
the deoptimization works. With this change we will be able to inline
based on the SharedFunctionInfo and materialize the JSFunction from a
literal or a stack slot when necessary.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1169103004
Cr-Commit-Position: refs/heads/master@{#28906}