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}
Reason for revert:
Fails a lot of layout tests and blocks the roll. Can be easily reproduced with a local Chromium checkout.
Reference: https://codereview.chromium.org/1652413003/
Original issue's description:
> [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.
>
> 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.
>
> This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks.
>
> BUG=chromium:579009
> LOG=Y
>
> Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
> Cr-Commit-Position: refs/heads/master@{#33674}
TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:579009
Review URL: https://codereview.chromium.org/1660263003
Cr-Commit-Position: refs/heads/master@{#33698}
This includes 2 fixes:
1) We didn't properly advance the holder when checking whether
Receiver==Holder, so we'd inadvertently block loading the property if
the first property we find is on the typed array.
2) Reflect.get may cause any object on the prototype chain of the holder
to be the receiver; so we need to recheck for this special state for
each object we perform lookup on.
Review URL: https://codereview.chromium.org/1651913005
Cr-Commit-Position: refs/heads/master@{#33689}
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.
This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks.
BUG=chromium:579009
LOG=Y
Review URL: https://codereview.chromium.org/1642223003
Cr-Commit-Position: refs/heads/master@{#33674}
String wrappers (new String("foo")) are special objects: their string
characters are accessed like elements, and they also have an elements
backing store. This used to require a bunch of explicit checks like:
if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
/* Handle string characters */
}
// Handle regular elements (for string wrappers and other objects)
obj->GetElementsAccessor()->Whatever(...);
This CL introduces new ElementsKinds for string wrapper objects (one for
fast elements, one for dictionary elements), which allow folding the
special-casing into new StringWrapperElementsAccessors.
No observable change in behavior is intended.
Review URL: https://codereview.chromium.org/1612323003
Cr-Commit-Position: refs/heads/master@{#33616}
This translates the exception handler table attached to a bytecode array
correctly into exceptional projections within the TurboFan graph. We
perform an abstract simulation of handlers that are being entered and
exited by the bytecode iteration to track the correct handler for each
node.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1641723002
Cr-Commit-Position: refs/heads/master@{#33580}
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}
The body of a generator function can now refer to the generator's input value via a new
"function.sent" expression. We extend the proposal at
https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md
in the obvious way to also apply to GeneratorResumeAbrupt.
This will enable us to desugar yield*.
The new syntax is behind a new --harmony-function-sent flag.
BUG=v8:4700
LOG=n
Review URL: https://codereview.chromium.org/1620253003
Cr-Commit-Position: refs/heads/master@{#33574}
Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.
Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> 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...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}
TBR=bmeurer@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/1643533003
Cr-Commit-Position: refs/heads/master@{#33556}
This reverts commit 85ba94f28c.
All parallelism can be turned off using --predictable, or --noparallel-compaction.
This patch completely parallelizes
- semispace copy: from space -> to space (within newspace)
- newspace evacuation: newspace -> oldspace
- oldspace compaction: oldspace -> oldspace
Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).
Some low-level details:
- The hard cap on number of tasks has been lifted
- We cache store buffer entries locally before merging them back into the global
StoreBuffer in a finalization phase.
- We cache AllocationSite operations locally before merging them back into the
global pretenuring storage in a finalization phase.
- AllocationSite might be compacted while they would be needed for newspace
evacuation. To mitigate any problems we defer checking allocation sites for
newspace till merging locally buffered data.
CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
Review URL: https://codereview.chromium.org/1640563004
Cr-Commit-Position: refs/heads/master@{#33552}
(Fixed a bug found by nosnap builds.)
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...
TBR=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1642613002
Cr-Commit-Position: refs/heads/master@{#33548}
Reason for revert:
[Sheriff] Leads to crashes on all webrtc chromium testers, e.g.:
https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/49664
Original issue's description:
> [heap] Parallel newspace evacuation, semispace copy, and compaction \o/
>
> All parallelism can be turned off using --predictable, or --noparallel-compaction.
>
> This patch completely parallelizes
> - semispace copy: from space -> to space (within newspace)
> - newspace evacuation: newspace -> oldspace
> - oldspace compaction: oldspace -> oldspace
>
> Previously newspace has been handled sequentially (semispace copy, newspace
> evacuation) before compacting oldspace in parallel. However, on a high level
> there are no dependencies between those two actions, hence we parallelize them
> altogether. We base the number of evacuation tasks on the overall set of
> to-be-processed pages (newspace + oldspace compaction pages).
>
> Some low-level details:
> - The hard cap on number of tasks has been lifted
> - We cache store buffer entries locally before merging them back into the global
> StoreBuffer in a finalization phase.
> - We cache AllocationSite operations locally before merging them back into the
> global pretenuring storage in a finalization phase.
> - AllocationSite might be compacted while they would be needed for newspace
> evacuation. To mitigate any problems we defer checking allocation sites for
> newspace till merging locally buffered data.
>
> CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
> BUG=chromium:524425
> LOG=N
> R=hpayer@chromium.org, ulan@chromium.org
>
> Committed: https://crrev.com/8f0fd8c0370ae8c5aab56491b879d7e30c329062
> Cr-Commit-Position: refs/heads/master@{#33523}
TBR=hpayer@chromium.org,ulan@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425
Review URL: https://codereview.chromium.org/1643473002
Cr-Commit-Position: refs/heads/master@{#33539}
All parallelism can be turned off using --predictable, or --noparallel-compaction.
This patch completely parallelizes
- semispace copy: from space -> to space (within newspace)
- newspace evacuation: newspace -> oldspace
- oldspace compaction: oldspace -> oldspace
Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).
Some low-level details:
- The hard cap on number of tasks has been lifted
- We cache store buffer entries locally before merging them back into the global
StoreBuffer in a finalization phase.
- We cache AllocationSite operations locally before merging them back into the
global pretenuring storage in a finalization phase.
- AllocationSite might be compacted while they would be needed for newspace
evacuation. To mitigate any problems we defer checking allocation sites for
newspace till merging locally buffered data.
CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
Review URL: https://codereview.chromium.org/1577853007
Cr-Commit-Position: refs/heads/master@{#33523}
This replace HeapType with a dedicated class that implements just what we need for field type tracking. In the next CL, I plan to remove FieldType::Iterator because FieldType can iterate over at most one map.
The ultimate plan is to get rid of templates in types.(h|cc) and remove type-inl.h.
TBR=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1636013002
Cr-Commit-Position: refs/heads/master@{#33521}
Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.
Original issue's description:
> Type Feedback Vector lives in the closure
>
> 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...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}
TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# 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/1632993003
Cr-Commit-Position: refs/heads/master@{#33520}
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...
TBR=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1563213002
Cr-Commit-Position: refs/heads/master@{#33518}
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}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
Cr-Commit-Position: refs/heads/master@{#33438}
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33461}
Reason for revert:
let me quickly revert the revert, wut?
Goal: my CL should not be in the tree!
Original issue's description:
> Reland of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1619803003/ )
>
> Reason for revert:
> the deopt issues have been taken care of by benedikt
>
> Original issue's description:
> > Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
> >
> > Reason for revert:
> > tanks for-in significantly
> >
> > Original issue's description:
> > > [runtime] Do not use the enum-cache for keys retrieval.
> > >
> > > Currently we fail to properly handle shadowed properties. If the
> > > receiver defines a non-enumerable property that reappears on the
> > > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > > By extending the KeyAccumulator to track non-enumerable properties
> > > we can now properly filter them out when seeing them further up in
> > > the prototype-chain.
> > >
> > > BUG=v8:705
> > > LOG=y
> > >
> > > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > > Cr-Commit-Position: refs/heads/master@{#33405}
> >
> > TBR=jkummerow@chromium.org,bmeurer@chromium.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=v8:705
> > LOG=n
> >
> > Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> > Cr-Commit-Position: refs/heads/master@{#33443}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:705
>
> Committed: https://crrev.com/5569e270eda517b5ea74e3a7676b3230cbe2f7a9
> Cr-Commit-Position: refs/heads/master@{#33458}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1614313003
Cr-Commit-Position: refs/heads/master@{#33459}
Reason for revert:
the deopt issues have been taken care of by benedikt
Original issue's description:
> Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
>
> Reason for revert:
> tanks for-in significantly
>
> Original issue's description:
> > [runtime] Do not use the enum-cache for keys retrieval.
> >
> > Currently we fail to properly handle shadowed properties. If the
> > receiver defines a non-enumerable property that reappears on the
> > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > By extending the KeyAccumulator to track non-enumerable properties
> > we can now properly filter them out when seeing them further up in
> > the prototype-chain.
> >
> > BUG=v8:705
> > LOG=y
> >
> > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > Cr-Commit-Position: refs/heads/master@{#33405}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:705
> LOG=n
>
> Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> Cr-Commit-Position: refs/heads/master@{#33443}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1612413003
Cr-Commit-Position: refs/heads/master@{#33458}
Reason for revert:
[Sheriff] Breaks layout tests. Please fix upstream.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077
Original issue's description:
> Array length reduction should throw in strict mode if it can't delete an element.
>
> When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
>
> Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
>
> This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
>
> BUG=v8:4267
> LOG=Y
>
> Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
> Cr-Commit-Position: refs/heads/master@{#33438}
TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4267
Review URL: https://codereview.chromium.org/1611313003
Cr-Commit-Position: refs/heads/master@{#33444}
Reason for revert:
tanks for-in significantly
Original issue's description:
> [runtime] Do not use the enum-cache for keys retrieval.
>
> Currently we fail to properly handle shadowed properties. If the
> receiver defines a non-enumerable property that reappears on the
> prototype as enumerable it incorrectly shows up in [[Enumerate]].
> By extending the KeyAccumulator to track non-enumerable properties
> we can now properly filter them out when seeing them further up in
> the prototype-chain.
>
> BUG=v8:705
> LOG=y
>
> Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> Cr-Commit-Position: refs/heads/master@{#33405}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:705
LOG=n
Review URL: https://codereview.chromium.org/1619803003
Cr-Commit-Position: refs/heads/master@{#33443}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33438}
We divide character ranges into
- BMP, matched normally.
- non-BMP, matched as alternatives of surrogate pair ranges.
- lone surrogates, matched with lookaround assertion that its indeed lone.
R=erik.corry@gmail.com
BUG=v8:2952
LOG=N
Review URL: https://codereview.chromium.org/1578253005
Cr-Commit-Position: refs/heads/master@{#33432}
This change improves performance for the common case of
Object.getOwnPropertyDescriptor by up 3x-4x, where we just
return a property descriptor object for a regular data or
accessor property.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_chromium_rel_ng
R=yangguo@chromium.org
Committed: https://crrev.com/ffa9e82235b20c523ebb1151c6196bc6232296b9
Cr-Commit-Position: refs/heads/master@{#33398}
Review URL: https://codereview.chromium.org/1607943003
Cr-Commit-Position: refs/heads/master@{#33415}
Currently we fail to properly handle shadowed properties. If the
receiver defines a non-enumerable property that reappears on the
prototype as enumerable it incorrectly shows up in [[Enumerate]].
By extending the KeyAccumulator to track non-enumerable properties
we can now properly filter them out when seeing them further up in
the prototype-chain.
BUG=v8:705
LOG=y
Review URL: https://codereview.chromium.org/1608523002
Cr-Commit-Position: refs/heads/master@{#33405}
Reason for revert:
Predecessor CL suspect for roll breakage: https://codereview.chromium.org/1610563002
Original issue's description:
> [runtime] Introduce maps for the likely cases of FromPropertyDescriptor.
>
> This change improves performance for the common case of
> Object.getOwnPropertyDescriptor by up 3x-4x, where we just
> return a property descriptor object for a regular data or
> accessor property.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/ffa9e82235b20c523ebb1151c6196bc6232296b9
> Cr-Commit-Position: refs/heads/master@{#33398}
TBR=yangguo@chromium.org,bmeurer@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/1604243002
Cr-Commit-Position: refs/heads/master@{#33403}
This implements a first version of exception handler table construction
within the interpreter. Note that the local control flow for try-catch
and try-finally statements is still off, and also stack unwinding does
not yet respect interpreter frames. But generated handler tables should
be populated correctly already.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1607433005
Cr-Commit-Position: refs/heads/master@{#33400}
This change improves performance for the common case of
Object.getOwnPropertyDescriptor by up 3x-4x, where we just
return a property descriptor object for a regular data or
accessor property.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1607943003
Cr-Commit-Position: refs/heads/master@{#33398}
The old mechanism was a left-over from a previous time where the runtime
would rely on the presence or absence of the setter to figure out
whether or not the property is mutable. This is unnecessary by now.
Review URL: https://codereview.chromium.org/1600923002
Cr-Commit-Position: refs/heads/master@{#33377}
This adds a handler table field to the header of our BytecodeArray
objects. The field will eventually hold a range-based handler table
similar to full-codegen code, to support exception handlong within
interpreted code.
R=oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1606493002
Cr-Commit-Position: refs/heads/master@{#33373}
We can return the creation context of the [[BoundTargetFunction]], and
don't need to remember the context in which the function was bound.
R=verwaest@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1590273002
Cr-Commit-Position: refs/heads/master@{#33332}
That way, we don't have to implement the fast <-> slow migration logic,
and we don't allocate in-object properties anyways
BUG=chromium:571365
R=verwaest@chromium.org,neis@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1582773003
Cr-Commit-Position: refs/heads/master@{#33328}
Unify Object::ToObject and Execution::ToObject, and unify all users to
go to Object::ToObject directly. Also remove some dead code from the
frame details debug API.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1589323002
Cr-Commit-Position: refs/heads/master@{#33327}
That will allow for adding private symbols to JSProxies in a follow-up
change
BUG=chromium:571365
R=neis@chromium.org,verwaest@chromium.org,rossberg@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1575423002
Cr-Commit-Position: refs/heads/master@{#33241}
We use a scratchpad to remember visited allocation sites for post processing
(making tenure decisions). The previous implementation used a rooted FixedArray
with constant length (256) to remember all sites. Updating the scratchpad is a
bottleneck in any parallel/concurrent implementation of newspace evacuation.
The new implementation uses a HashMap with allocation sites as keys and
temporary counts as values. During evacuation we collect a local hashmap of
visited allocation sites. Upon merging the local hashmap back into a global one
we update potential forward pointers of compacted allocation sites. The
scavenger can directly enter its entries into the global hashmap. Note that the
actual memento found count is still kept on the AllocationSite as it needs to
survive scavenges and full GCs.
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1535723002
Cr-Commit-Position: refs/heads/master@{#33233}
This migrates the remaining Date builtins to C++ and removes obsolete
intrinsics and JavaScript wrappers. This reduces the overhead imposed
by the Date builtins, and will allow us to optimize them later in the
TurboFan compiler, while the interpreter doesn't need to worry about
them.
R=yangguo@chromium.org
BUG=chromium:576574
LOG=n
Committed: https://crrev.com/1e51af1a5c80b1650de47dd4bc8f846fa2d85281
Cr-Commit-Position: refs/heads/master@{#33228}
Review URL: https://codereview.chromium.org/1579613002
Cr-Commit-Position: refs/heads/master@{#33231}
Reason for revert:
[Sheriff] Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/5711
Original issue's description:
> [builtins] Refactor the remaining Date builtins.
>
> This migrates the remaining Date builtins to C++ and removes obsolete
> intrinsics and JavaScript wrappers. This reduces the overhead imposed
> by the Date builtins, and will allow us to optimize them later in the
> TurboFan compiler, while the interpreter doesn't need to worry about
> them.
>
> R=yangguo@chromium.org
> BUG=chromium:576574
> LOG=n
>
> Committed: https://crrev.com/1e51af1a5c80b1650de47dd4bc8f846fa2d85281
> Cr-Commit-Position: refs/heads/master@{#33228}
TBR=yangguo@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:576574
Review URL: https://codereview.chromium.org/1574223002
Cr-Commit-Position: refs/heads/master@{#33230}
This migrates the remaining Date builtins to C++ and removes obsolete
intrinsics and JavaScript wrappers. This reduces the overhead imposed
by the Date builtins, and will allow us to optimize them later in the
TurboFan compiler, while the interpreter doesn't need to worry about
them.
R=yangguo@chromium.org
BUG=chromium:576574
LOG=n
Review URL: https://codereview.chromium.org/1579613002
Cr-Commit-Position: refs/heads/master@{#33228}
This patch implements @@species, guarded behind the --harmony-species
flag, on Arrays. Methods which return an Array will instead return
the appropriate instance based on the ArraySpeciesCreate algorithm.
The algorithm is implemented in C++ to get access to realm information
and to implement some Array methods in C++, but it is also accessed
from JavaScript through a new runtime function. A couple interactive
Octane runs show no performance regression with the flag turned off,
but turning --harmony-species on will surely have a significant
regression, as Array methods now heavily use ObjectDefineProperty.
BUG=v8:4093
LOG=Y
R=adamk,cbruni
Review URL: https://codereview.chromium.org/1560763002
Cr-Commit-Position: refs/heads/master@{#33144}
For a prototype chain foo -> global_proxy -> global_object, we used to
register a dependency from foo -> global_object. This is incorrect when
the global_proxy/global_object pairing is modified, e.g. when navigating
in iframes. With this patch, we properly register foo -> global_proxy and
global_proxy -> global_object dependencies.
Additionally, when a prototype's prototype changes from null to something
else, this new usage relation must be registered if there are other users
further down on the prototype chain that might expect a complete chain of
registrations to exist (which was the case before, and must be preserved).
BUG=chromium:571517
LOG=n
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1559323002
Cr-Commit-Position: refs/heads/master@{#33119}
Almost all of the Date builtins always call into C++ at least once
anyway, so parsing, compiling and executing the JavaScript wrappers
is just a waste of time. The most important part here is the Date
constructor itself, which is one of the blockers for new.target in
TurboFan, because compiling the Date constructor takes too much time
with TurboFan (for no reason since we end up in C++ anway).
R=cbruni@chromium.org
Review URL: https://codereview.chromium.org/1556333002
Cr-Commit-Position: refs/heads/master@{#33109}
There's no point in keeping the ObjectCreate JavaScript wrapper
function, which even does allocation site pretenuring for the
instances created via Object.create (where ObjectCreate itself is
the AllocationSite), and does not offer any sane way forward.
Instead introduce a new ObjectCreate C++ builtin, which currently
serves as a baseline implementation, on top of which we can think
about ways to optimize Object.create for the common case (i.e.
frameworks such as Ember.js make heavy use of Object.create).
R=cbruni@chromium.orgTBR=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1558433002
Cr-Commit-Position: refs/heads/master@{#33061}
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.
There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.
The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
Cr-Commit-Position: refs/heads/master@{#33042}
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33044}
Reason for revert:
Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
Original issue's description:
> [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
>
> According to the ES2015 specification, bound functions are exotic
> objects, and thus don't need to be implemented as JSFunctions. So
> we introduce a new JSBoundFunction type to represent bound functions
> and make them optimizable. This already improves the performance of
> calling or constructing bound functions by 10-100x depending on the
> use case because we avoid the crazy dance between JavaScript and C++
> that was implemented in v8natives.js previously.
>
> There's still room for improvement in the performance of actually
> creating bound functions, which is also relevant in practice, but
> we already have a plan how to accomplish that later.
>
> The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> BUG=chromium:535408, chromium:571299, v8:4629
> LOG=n
>
> Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
> Cr-Commit-Position: refs/heads/master@{#33042}
TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:535408, chromium:571299, v8:4629
Review URL: https://codereview.chromium.org/1552473002
Cr-Commit-Position: refs/heads/master@{#33043}
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.
There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.
The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33042}
Add API-accessors for [[ProxyTarget]], [[ProxyHandler]]. Additionally
create new proxies and revoke proxies via the API.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1542943002
Cr-Commit-Position: refs/heads/master@{#33013}
There's actually no point trying to do Function.prototype.toString in
JavaScript, as it always calls into C++ at least once, so it only
complicates things (esp. once we start optimizing bound functions).
Drive-by-fix: Rename FunctionApply and FunctionCall builtins to also
reflect the fact that these are builtins in the Function.prototype and
not on Function itself.
TBR=hpayer@chromium.orgR=yangguo@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1540953004
Cr-Commit-Position: refs/heads/master@{#32996}
Introduce a new Apply builtin that forms a correct and optimizable
foundation for the Function.prototype.apply, Reflect.construct and
Reflect.apply builtins (which properly does the PrepareForTailCall
as required by the ES2015 spec).
The new Apply builtin avoids going to the runtime if it is safe to
just access the backing store elements of the argArray, i.e. if you
pass a JSArray with no holes, or an unmapped, unmodified sloppy or
strict arguments object.
mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com>
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
BUG=v8:4413, v8:4430
LOG=n
R=yangguo@chromium.org
Committed: e4d2538911
Review URL: https://codereview.chromium.org/1523753002 .
Cr-Commit-Position: refs/heads/master@{#32929}
Reason for revert:
Breaks TSAN somewhow: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/7000
Original issue's description:
> [es6] Correct Function.prototype.apply, Reflect.construct and Reflect.apply.
>
> Introduce a new Apply builtin that forms a correct and optimizable
> foundation for the Function.prototype.apply, Reflect.construct and
> Reflect.apply builtins (which properly does the PrepareForTailCall
> as required by the ES2015 spec).
>
> The new Apply builtin avoids going to the runtime if it is safe to
> just access the backing store elements of the argArray, i.e. if you
> pass a JSArray with no holes, or an unmapped, unmodified sloppy or
> strict arguments object.
>
> mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com>
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> BUG=v8:4413, v8:4430
> LOG=n
> R=yangguo@chromium.org
>
> Committed: e4d2538911TBR=yangguo@chromium.org,paul.lind@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4413, v8:4430
Review URL: https://codereview.chromium.org/1533803002 .
Cr-Commit-Position: refs/heads/master@{#32928}
Introduce a new Apply builtin that forms a correct and optimizable
foundation for the Function.prototype.apply, Reflect.construct and
Reflect.apply builtins (which properly does the PrepareForTailCall
as required by the ES2015 spec).
The new Apply builtin avoids going to the runtime if it is safe to
just access the backing store elements of the argArray, i.e. if you
pass a JSArray with no holes, or an unmapped, unmodified sloppy or
strict arguments object.
mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com>
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=v8:4413, v8:4430
LOG=n
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1523753002 .
Cr-Commit-Position: refs/heads/master@{#32927}
The FIRST-LAST_NONCALLABLE_SPEC_OBJECT_TYPE range was accidentially used
in field type tracking, where we should check for JSReceiver instead
(there's no need to exclude JSProxy or JSFunction from tracking).
And the use in %_ClassOf was actually wrong and didn't match the C++
implementation in JSReceiver::class_name() anymore. Now it's consistent
again.
R=yangguo@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1535523003 .
Cr-Commit-Position: refs/heads/master@{#32926}
We must print "[object Array]" for proxies that satisfy Array.isArray.
Cosmetic change on the side: move ObjectProtoToString from JSObject to Object
since it deals with arbitrary objects.
R=adamk@chromium.org, verwaest@chromium.org
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1526023002
Cr-Commit-Position: refs/heads/master@{#32902}
This CL makes proxy-related error messages more accurate and verbose.
(Exception: those used in deprecated functions in v8natives.js.) Some of
the old error messages were simply wrong.
On the side, fix ShouldThrow semantics of JSProxy::SetPrototype and
JSProxy::DefineOwnProperty.
R=cbruni@chromium.org, jkummerow@chromium.org
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1527583002
Cr-Commit-Position: refs/heads/master@{#32836}
This is necessary to guarantee that the whole descriptor would be marked, otherwise DescriptorArray pretenuring would cause crashes.
Review URL: https://codereview.chromium.org/1520613006
Cr-Commit-Position: refs/heads/master@{#32812}
The main impetus is to improve performance when --harmony-tostring
is enabled, thanks to using a generic property load instead of a
megamorphic IC.
This also reduces duplication, as the API function
v8::Object::ObjectProtoToString can share the runtime implementation.
The only functional change in this patch is to drop an accidental difference
between the JS and API implementations: the arguments object should toString
as "[object Arguments]". The JS side was corrected in
https://code.google.com/p/v8/source/detail?r=3279, but the API version was
missed in that patch.
BUG=chromium:555127, v8:3502
LOG=n
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1509533003
Cr-Commit-Position: refs/heads/master@{#32777}
Function subclasses did not have function properties installed (name, prototype, etc.).
Now when an instance of a Function subclass is created it gets initial map that corresponds
to the language mode of the function body. The language mode dependent maps are cached as
special transitions on initial map of the subclass constructor.
BUG=v8:4597, v8:3101, v8:3330
LOG=Y
Review URL: https://codereview.chromium.org/1510753005
Cr-Commit-Position: refs/heads/master@{#32764}
We either want to add code+literals to the map, or just literals.
A recent change in the structure of the map (it now uses WeakCells)
meant that we have to be more clear about what we want to do the right
thing.
BUG=
Review URL: https://codereview.chromium.org/1516833002
Cr-Commit-Position: refs/heads/master@{#32761}
In particular, return Maybe<bool> from any function that can throw, and
use MAYBE_RETURN and RETURN_FAILURE macros consistently where applicable.
No change in behavior intended.
Review URL: https://codereview.chromium.org/1513713002
Cr-Commit-Position: refs/heads/master@{#32723}
Compaction of the array with maps happens lazily upon adding new maps.
BUG=
Review URL: https://codereview.chromium.org/1481953002
Cr-Commit-Position: refs/heads/master@{#32717}
This is a simplified copy of JSObject::GetOwnElementKeys and will make it possible to eliminate the latter.
Review URL: https://codereview.chromium.org/1510083003
Cr-Commit-Position: refs/heads/master@{#32713}
Instead of iterating the whole map space to find dead transitions,
look in weak cell list and transition array list.
Simple transitions are in the weak cell list.
Full transitions are in the transitions array list.
BUG=chromium:554488
LOG=NO
Review URL: https://codereview.chromium.org/1488593003
Cr-Commit-Position: refs/heads/master@{#32684}
Error still to be done, since that's not yet available in the bootstrapper.
BUG=v8:3900, v8:3931, v8:1543, v8:3330
LOG=n
Review URL: https://codereview.chromium.org/1499923002
Cr-Commit-Position: refs/heads/master@{#32662}
- Add JSReceiver::SetIntegrityLevel, with a fast path for regular objects.
- Make Object.{freeze,seal} call this via %Object{Freeze,Seal}, thus no longer
using broken or deprecated functions from v8natives.js.
- Add JSReceiver::OwnPropertyKeys convenience function.
- Reenable harmony/proxies-hash.js test.
R=rossberg
BUG=v8:1543
LOG=N
Review URL: https://codereview.chromium.org/1489423002
Cr-Commit-Position: refs/heads/master@{#32651}
Having beefed up GetKeys() to support everything, use it for everything now.
This fixes Object.getOwnPropertyNames and Object.getOwnPropertySymbols for
Proxies, and gets rid of a bunch of code duplication.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1498593006
Cr-Commit-Position: refs/heads/master@{#32620}
For now, we revoke a proxy by setting its handler to null (as in the spec).
Change the "target" field from Object to JSReceiver as there's no point in
allowing more.
R=jkummerow@chromium.org, rossberg
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1496243003
Cr-Commit-Position: refs/heads/master@{#32608}
Reason for revert:
Seems to be (mostly) responsible for the most recent Speedometer regression, not 100% sure. Let's see what the bots have to say.
Original issue's description:
> Provide call counts for constructor calls, surface them as a vector IC.
>
> CallIC and CallConstructStub look so alike, at least in the feedback they gather even if the implementation differs...and CallIC has such a nice way of surfacing the feedback (CallICNexus), that there is a request to make CallConstructStub look analogous. Enter ConstructICStub.
>
> BUG=
>
> Committed: https://crrev.com/66d5a9df62da458a51e8c7ed1811dc9660f4f418
> Cr-Commit-Position: refs/heads/master@{#32452}
TBR=mvstanton@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1489413006
Cr-Commit-Position: refs/heads/master@{#32599}
It didn't support subclassing case at all and in non-subclassing case the runtime
allocation didn't do the slack tracking step.
BUG=chromium:563339
LOG=Y
Review URL: https://codereview.chromium.org/1488023002
Cr-Commit-Position: refs/heads/master@{#32547}
Split out of PropertyAttributes, and used for all filtering purposes.
Also moved PropertyAttributes into the v8::internal:: namespace.
No change in behavior intended.
Review URL: https://codereview.chromium.org/1492653004
Cr-Commit-Position: refs/heads/master@{#32525}
CallIC and CallConstructStub look so alike, at least in the feedback they gather even if the implementation differs...and CallIC has such a nice way of surfacing the feedback (CallICNexus), that there is a request to make CallConstructStub look analogous. Enter ConstructICStub.
BUG=
Review URL: https://codereview.chromium.org/1476413003
Cr-Commit-Position: refs/heads/master@{#32452}
