Reason for revert:
Build failure on Linux64 arm64 ASAN:
http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN%20arm64%20-%20debug%20builder/builds/4829
(Leaks memory, somehow.)
Original issue's description:
> Encode interpreter::SourcePositionTable as variable-length ints.
>
> This reduces the memory consumption of SourcePositionTable by ca. 2/3.
> Over Octane, this reduces the source position table memory consumption
> from ~370kB to ~115kB, which makes it ca. 10% of the total bytecode size
> (~1.1MB)
>
> BUG=
>
> Committed: https://crrev.com/a6f41f7b8226555c5900440f6e3092b3545ee0f6
> Cr-Commit-Position: refs/heads/master@{#34250}
TBR=jochen@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1728193003
Cr-Commit-Position: refs/heads/master@{#34251}
This reduces the memory consumption of SourcePositionTable by ca. 2/3.
Over Octane, this reduces the source position table memory consumption
from ~370kB to ~115kB, which makes it ca. 10% of the total bytecode size
(~1.1MB)
BUG=
Review URL: https://codereview.chromium.org/1704943002
Cr-Commit-Position: refs/heads/master@{#34250}
Since both null and undefined are also marked as undetectable now, we
can just test that bit instead of having the CompareNilIC try to collect
feedback to speed up the general case (without the undetectable bit
being used).
Drive-by-fix: Update the type system to match the new handling of
undetectable in the runtime.
R=danno@chromium.org
Review URL: https://codereview.chromium.org/1722193002
Cr-Commit-Position: refs/heads/master@{#34237}
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}
In ES2016, the Proxy enumerate trap is removed. This patch changes
for-in iteration on Proxies to use the ownKeys trap. Due to the clean
organization of that code, the patch basically consists of deletions.
R=adamk
LOG=Y
BUG=v8:4768
Review URL: https://codereview.chromium.org/1717893002
Cr-Commit-Position: refs/heads/master@{#34200}
Currently AllocationSite skips the weak_next pointer in IterateBody and IsValidSlot.
This is not correct because the weak_next is a valid slot in AllocationSite.
BUG=
Review URL: https://codereview.chromium.org/1719903002
Cr-Commit-Position: refs/heads/master@{#34192}
Adds a profiling counter to each BytecodeArray object, and adds
code to Jump and Return bytecode handlers to update this
counter by the size of the jump or the distance from the return
to the start of the function. This is more accurate than fullcodegen's
approach since it takes forward jumps into account as well as back-edges.
Modifies RuntimeProfiler to track ticks for interpreted frames.
Currently we use the SharedFunctionInfo::profiler_ticks() instead
of adding another to tick field to avoid adding another field to
BytecodeArray since SharedFunctionInfo::profiler_ticks() is only
used by Crankshaft otherwise so we shouldn't need both for
BUG=v8:4689
LOG=N
Review URL: https://codereview.chromium.org/1707693003
Cr-Commit-Position: refs/heads/master@{#34166}
Various syntactic forms now cause functions to have names where they
didn't before. Per the upcoming changes to the toString spec, only
a name that was literally part of a function's expression or declaration
is meant to be reflected in toString. This also happens to be the same
set of names that V8 currently outputs (without the --harmony-function-name
flag).
This required distinguishing anonymous FunctionExpressions from other sorts
of function definitions (like methods and getters/setters) in the AST, parser,
and at runtime.
The patch also takes the opportunity to remove one more argument (and enum)
from FunctionLiteral, as well as adding a special factory method for the
case of a FunctionLiteral representing toplevel or eval'd code.
BUG=v8:4760
LOG=n
Review URL: https://codereview.chromium.org/1712833002
Cr-Commit-Position: refs/heads/master@{#34132}
This frees up one bit in FunctionKind, which I plan to make slightly
more syntactic info about functions available in SharedFunctionInfo
(needed for ES2015 Function.name support).
BUG=v8:3956, v8:4760
LOG=n
Review URL: https://codereview.chromium.org/1704223002
Cr-Commit-Position: refs/heads/master@{#34125}
By short-cutting the DefineOwnProperty machinery similar to how ForceSet
does it, we should get a few cycles out of this heavily used API.
BUG=chromium:569668
R=verwaest@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1702353002
Cr-Commit-Position: refs/heads/master@{#34102}
Properly type String.prototype.concat, String.prototype.charCodeAt,
and String.prototype.toLowerCase/toUpperCase in TurboFan. Also assign
better type to %_StringCharFromCode.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1701673002
Cr-Commit-Position: refs/heads/master@{#33991}
Reason for revert:
No fix needed, original CL was perfectly fine!
Original issue's description:
> Revert of [interpreter] Correctly thread through catch prediction. (patchset #1 id:1 of https://codereview.chromium.org/1690973002/ )
>
> Reason for revert:
> Depends on the reverted https://codereview.chromium.org/1691723002
>
> Original issue's description:
> > [interpreter] Correctly thread through catch prediction.
> >
> > This change correctly sets the {CatchPrediction} field in exception
> > handler tables for bytecode and optimized code. It also adds tests
> > independent of promise handling for this prediction, to ensure all our
> > backends are in sync on their prediction.
> >
> > R=rmcilroy@chromium.org,yangguo@chromium.org
> > TEST=mjsunit/compiler/debug-catch-prediction
> > BUG=v8:4674
> > LOG=n
> >
> > Committed: https://crrev.com/ba55f5594cb0b4a1a1e9b35d87fe54afe2d93f3b
> > Cr-Commit-Position: refs/heads/master@{#33906}
>
> TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4674
>
> Committed: https://crrev.com/c5229b311968fd638a6cd537c341b1055eb7be97
> Cr-Commit-Position: refs/heads/master@{#33922}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4674
Review URL: https://codereview.chromium.org/1689113004
Cr-Commit-Position: refs/heads/master@{#33933}
The FastNewStrictArgumentsStub is very similar to the recently added
FastNewRestParameterStub, it's actually almost a copy of it, except that
it doesn't have the fast case we have for the empty rest parameter. This
patch improves strict arguments in TurboFan and fullcodegen by up to 10x
compared to the previous version.
Also introduce proper JSSloppyArgumentsObject and JSStrictArgumentsObject
for the in-object properties instead of having them as constants in the
Heap class.
Drive-by-fix: Use this stub and the FastNewRestParameterStub in the
interpreter to avoid the runtime call overhead for strict arguments
and rest parameter creation.
R=jarin@chromium.orgTBR=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1693513002
Cr-Commit-Position: refs/heads/master@{#33925}
Reason for revert:
Depends on the reverted https://codereview.chromium.org/1691723002
Original issue's description:
> [interpreter] Correctly thread through catch prediction.
>
> This change correctly sets the {CatchPrediction} field in exception
> handler tables for bytecode and optimized code. It also adds tests
> independent of promise handling for this prediction, to ensure all our
> backends are in sync on their prediction.
>
> R=rmcilroy@chromium.org,yangguo@chromium.org
> TEST=mjsunit/compiler/debug-catch-prediction
> BUG=v8:4674
> LOG=n
>
> Committed: https://crrev.com/ba55f5594cb0b4a1a1e9b35d87fe54afe2d93f3b
> Cr-Commit-Position: refs/heads/master@{#33906}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4674
Review URL: https://codereview.chromium.org/1695613002
Cr-Commit-Position: refs/heads/master@{#33922}
This change correctly sets the {CatchPrediction} field in exception
handler tables for bytecode and optimized code. It also adds tests
independent of promise handling for this prediction, to ensure all our
backends are in sync on their prediction.
R=rmcilroy@chromium.org,yangguo@chromium.org
TEST=mjsunit/compiler/debug-catch-prediction
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1690973002
Cr-Commit-Position: refs/heads/master@{#33906}
In the case of a simple fast-mode receiver without fancy properties, we
can just walk over the descriptor array to find all its initial property
names. As long as the map stays the same, we can also use that
descriptor array to figure out how to handle the properties.
This speeds up
https://github.com/kpdecker/six-speed/tree/master/tests/object-assign by
~2x.
BUG=
Review URL: https://codereview.chromium.org/1688953004
Cr-Commit-Position: refs/heads/master@{#33895}
The break location heavily relies on relocation info. This change
abstracts that away. Currently there is only one implementation for
this interface, for JIT code. Future changes will introduce an
implementation to iterate bytecode arrays.
R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1682853003
Cr-Commit-Position: refs/heads/master@{#33869}
Previously, Object.values() and Object.entries() were piggy-backing on
Object.keys(). This meant that they would pre-filter non-enumerable properties,
violating the runtime behaviour of the methods. Unfortunately, this does not
match the current proposal text.
Also incorporates several tests verifying this behaviour based on tests included
in the ChakraCore implementation.
In this reland, the new patch fills up the longer-lasting FixedArray with
`undefined` to avoid the crash in Heap::Verify().
Originally reviewed at https://codereview.chromium.org/1637753004
BUG=v8:4663
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org
Review URL: https://codereview.chromium.org/1673673002
Cr-Commit-Position: refs/heads/master@{#33818}
Generally we only care whether the next object is a hidden prototype.
It's simpler to check whether the current object has a hidden prototype
instead of walking to the next prototype and checking its map.
BUG=
Review URL: https://codereview.chromium.org/1675223002
Cr-Commit-Position: refs/heads/master@{#33816}
It's fine to use JS_OBJECT_TYPE for JSIteratorResult and only have a
preallocated initial map for them to avoid unnecessary polymorphism
from generators / builtin iterators. The instance type doesn't
provide any advantage, since we always have to treat JSIteratorResult
objects as regular JSObjects later.
R=yangguo@chromium.orgTBR=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1680513002
Cr-Commit-Position: refs/heads/master@{#33800}
Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.
The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.
BUG=chromium:579009
LOG=Y
Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
Cr-Commit-Position: refs/heads/master@{#33674}
Review URL: https://codereview.chromium.org/1642223003
Cr-Commit-Position: refs/heads/master@{#33798}
Reason for revert:
[Sheriff] Breaks gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/1642
Original issue's description:
> [es7] refactor and fix Object.values() / Object.entries()
>
> Previously, Object.values() and Object.entries() were piggy-backing on
> Object.keys(). This meant that they would pre-filter non-enumerable properties,
> violating the runtime behaviour of the methods. Unfortunately, this does not
> match the current proposal text.
>
> Also incorporates several tests verifying this behaviour based on tests included
> in the ChakraCore implementation.
>
> BUG=v8:4663
> LOG=N
> R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org
>
> Committed: https://crrev.com/5c5ccd9d7f8693990d1a9eb26ba3a94f376dcf0b
> Cr-Commit-Position: refs/heads/master@{#33782}
TBR=littledan@chromium.org,adamk@chromium.org,cbruni@chromium.org,rossberg@chromium.org,caitpotter88@gmail.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4663
Review URL: https://codereview.chromium.org/1675663002
Cr-Commit-Position: refs/heads/master@{#33787}
Previously, Object.values() and Object.entries() were piggy-backing on
Object.keys(). This meant that they would pre-filter non-enumerable properties,
violating the runtime behaviour of the methods. Unfortunately, this does not
match the current proposal text.
Also incorporates several tests verifying this behaviour based on tests included
in the ChakraCore implementation.
BUG=v8:4663
LOG=N
R=adamk@chromium.org, rossberg@chromium.org, littledan@chromium.org
Review URL: https://codereview.chromium.org/1637753004
Cr-Commit-Position: refs/heads/master@{#33782}
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}
Reason for revert:
Must revert for now due to chromium api natives issues.
Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}
TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1670813005
Cr-Commit-Position: refs/heads/master@{#33766}
Adds a new runtime function, %DefineDataPropertyInLiteral, which
takes a fifth argument specifying whether the property and value
are syntactically such that the value is a function (or class)
literal that should have its name set at runtime.
The new runtime call also allows us to eliminate the now-redundant
%DefineClassMethod runtime function.
This should get much less ugly once we can desugar the "dynamic"
part of object literals in the parser (but that work is currently
blocked on having a performant way of desugaring literals).
BUG=v8:3699, v8:3761
LOG=n
Review URL: https://codereview.chromium.org/1626423003
Cr-Commit-Position: refs/heads/master@{#33756}
Note: This is currently only used by yield*, we still need to support it in
other places (such as for-of loops). It can be used manually of course.
(This CL does not touch the full-codegen implementation of yield* because that
code is already dead. The yield* desugaring already supports return and doesn't
need to be touched.)
BUG=v8:3566
LOG=y
Review URL: https://codereview.chromium.org/1639343005
Cr-Commit-Position: refs/heads/master@{#33744}
(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.
This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.
The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.
TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1668103002
Cr-Commit-Position: refs/heads/master@{#33741}
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}
