For functions declared in source code, the .toString() representation
will be an excerpt of the source code.
* For functions declared with the "function" keyword, the excerpt
starts at the "function" or "async" keyword and ends at the final "}".
The previous behavior would start the excerpt at the "(" of the
parameter list, and prepend a canonical `"function " + name` or
similar, which would discard comments and formatting surrounding the
function's name. Anonymous functions declared as function expressions
no longer get the name "anonymous" in their toString representation.
* For methods, the excerpt starts at the "get", "set", "*" (for
generator methods), or property name, whichever comes first.
Previously, the toString representation for methods would use a
canonical prefix before the "(" of the parameter list. Note that any
"static" keyword is omitted.
* For arrow functions and class declarations, the excerpt is unchanged.
For functions created with the Function, GeneratorFunction, or
AsyncFunction constructors:
* The string separating the parameter text and body text is now
"\n) {\n", where previously it was "\n/*``*/) {\n" or ") {\n".
* At one point, newline normalization was required by the spec here,
but that was removed from the spec, and so this CL does not do it.
Included in this CL is a fix for CreateDynamicFunction parsing. ')'
and '`' characters in the parameter string are no longer disallowed,
and Function("a=function(", "}){") is no longer allowed.
BUG=v8:4958, v8:4230
Review-Url: https://codereview.chromium.org/2156303002
Cr-Commit-Position: refs/heads/master@{#43262}
... and don't clear ICs during GC. The IC clearing used to prevent memory
leaks but it's not necessary anymore because all the handlers that need
to embed objects already use weak cells.
This CL unblocks inlining of IC dispatchers into bytecode handlers.
BUG=v8:5917
Change-Id: I229b9ba8dba44f431dfbe8ac5370d855e3e84dd6
Reviewed-on: https://chromium-review.googlesource.com/442127
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43209}
It's needed by code-stubs.h and it was defined in objects-inl.h.
That cannot work without violating the include rules.
BUG=v8:5402
R=mstarzinger@chromium.org
Change-Id: Icb84b97de5622df8cf76e9fc4d117982901c99d9
Reviewed-on: https://chromium-review.googlesource.com/441845
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43195}
Use private symbols to mark default promise handler, instead of calling out to default
handlers defined in JS. We check for this symbol in PromiseHandle and perform the
appropriate behavior as the default handlers.
Catch prediction logic is updated to account for a symbol.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2695593002
Cr-Commit-Position: refs/heads/master@{#43135}
Removes handles from bytecode generation, instead storing
un-internalized AstValues (and other, similar values such as Scopes and
AstRawStrings) in the constant array builder.
This will allow us in the future to generate the bytecode before
internalizing the AST.
BUG=v8:5832
Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da
Reviewed-on: https://chromium-review.googlesource.com/439326
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43115}
Collecting precise invocation counts need to be explicitly
enabled. Once enabled, we disable optimization (optimized
code does not increment invocation count, and may inline
callees), and make sure feedback vectors interesting for
code coverage is not garbage-collected.
R=hpayer@chromium.org, jgruber@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2686063002
Cr-Commit-Position: refs/heads/master@{#43082}
This CL includes runtime and IC parts of the tracking. It is controlled by
compile-time flag FLAG_constant_field_tracking and currently disabled.
Transition from kConst to kMutable still involves map deprecation.
BUG=v8:5495
Review-Url: https://codereview.chromium.org/2598543003
Cr-Commit-Position: refs/heads/master@{#43081}
Installing a feedback vector in a closure is a multi-step process.
The closure actually points to a Cell that points to a feedback
vector or undefined if we haven't created one yet.
This happens because we often create closures before we've compiled
the code.
JSFunction::EnsureLiterals is the bottleneck in our system that
creates a feedback vector if necessary. The predicates it used to
determine what to do were arcane. This CL allows it to think it
terms of state, and clarifies the reading of that useful
bottleneck.
I also did a few renamings in parts of the code that referred
to a "literals array," which we don't have any more.
BUG=
Review-Url: https://codereview.chromium.org/2681773004
Cr-Commit-Position: refs/heads/master@{#43035}
Now we can inline vector-based IC dispatchers to bytecode handlers.
BUG=v8:5917
Change-Id: Ie81750f252a730240097e514e69b348f410a48b7
Reviewed-on: https://chromium-review.googlesource.com/439265
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43028}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
- entries preview available even if debugger agent is disabled,
- less deprecated mirrors usage in debugger-script.js
- no usage of debugger context - zero probability of leaking it.
- better test coverage.
BUG=v8:5510
R=yangguo@chromium.org,jgruber@chromium.org,alph@chromium.org,luoe@chromium.org
Review-Url: https://codereview.chromium.org/2672213002
Cr-Commit-Position: refs/heads/master@{#42978}
This adapts the inlining logic to allow for inlining based solely on a
statically known underlying SharedFunctionInfo instead of a concrete
closure of the call target.
In cases where the closure is known, its bound context is constant
promoted just as before. In the new cases where only the SFI for an
entire class of closures is known, we use the dynamic SSA-value of the
bound context.
R=bmeurer@chromium.org
BUG=v8:2206
Review-Url: https://codereview.chromium.org/2626783003
Cr-Commit-Position: refs/heads/master@{#42968}
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.
Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.
Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.
This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
We don't need Code::CALL_IC for anything now that the CallICStub is
migrated and no longer hooks into the traditional IC system.
R=yangguo@chromium.org
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2669193002
Cr-Commit-Position: refs/heads/master@{#42890}
They have the same lifetime. It's a match!
Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.
A follow-on CL removes even more parser infrastructure related to this count.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
- kDebugPromiseCreated(task, parent_task)
This event occurs when promise is created (PromiseHookType::Init). V8Debugger uses this event to maintain task -> parent task map.
- kDebugEnqueueAsyncFunction(task)
This event occurs when first internal promise for async function is created. V8Debugger collects stack trace at this point.
- kDebugEnqueuePromiseResolve(task),
This event occurs when Promise fulfills with resolved status. V8Debugger collects stack trace at this point.
- kDebugEnqueuePromiseReject(task),
This event occurs when Promise fulfills with rejected status. V8Debugger collects stack trace at this point.
- kDebugPromiseCollected,
This event occurs when Promise is collected and no other chained callbacks can be added. V8Debugger removes information about async task for this promise.
- kDebugWillHandle,
This event occurs when chained promise function (either resolve or reject handler) is called. V8Debugger installs parent promise's stack (based on task -> parent_task map) as current if available or current promise's scheduled stack otherwise.
- kDebugDidHandle,
This event occurs after chained promise function has finished. V8Debugger restores asynchronous call chain to previous one.
With this change all instrumentation calls are related to current promise (before WillHandle and DidHandle were related to next async task).
Before V8Debugger supported only the following:
- asyncTaskScheduled(task1)
- asyncTaskStarted(task1)
- asyncTaskFinished(task1)
Now V8Debugger supports the following:
- asyncTaskScheduled(parent_task)
..
- asyncTaskCreated(task, parent_task),
- asyncTaskStarted(task), uses parent_task scheduled stack
- asyncTaskScheduled(task)
- asyncTaskFinished(task)
Additionally: WillHandle and DidHandle were migrated to PromiseHook API.
More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE
BUG=v8:5738
R=dgozman@chromium.org,gsathya@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2650803003
Cr-Commit-Position: refs/heads/master@{#42644}
V8 has internal mechanism to ignore steps and breaks inside internal scripts, in this CL it's reused for blackboxing implementation.
Advantages:
- much faster blackboxing implementation (before we at least wrap and collect current call stack for each step),
- get rid of StepFrame action and potential pause in blackboxed code after N StepFrame steps,
- simplification of debugger agent logic.
Disadvtanges:
- currently when user was paused in blackboxed code (e.g. on breakpoint) and then makes step action, debugger ignores blackboxed state of the script and allows to use step actions as usual - this behavior is regressed, we still able to support it on frontend side.
Current state and proposed changes for blackboxing: https://docs.google.com/document/d/1hnzaXPAN8_QC5ENxIgxgMNDbXLraM_OXT73rAyijTF8/edit?usp=sharing
BUG=v8:5842
R=yangguo@chromium.org,dgozman@chromium.org,alph@chromium.org
Review-Url: https://codereview.chromium.org/2633803002
Cr-Commit-Position: refs/heads/master@{#42614}
Manipulating the signaling NaN used for the hole and uninitialized double
field sentinel in C++, e.g. with bit_cast or HeapNumber::value()/set_value(),
will change its value on ia32 (the x87 stack is used to return values and
stores to the stack silently clear the signalling bit).
BUG=v8:5495
Review-Url: https://codereview.chromium.org/2652553003
Cr-Commit-Position: refs/heads/master@{#42609}
We are planning to add a few more debugger related bits, and are running
out of compiler hints bits. The new bit field is going to be part of the
debug info struct. If the debug info is not available, we store the bit
field in its place on the shared function info.
Review-Url: https://codereview.chromium.org/2649873002
Cr-Commit-Position: refs/heads/master@{#42594}
Convert strings to numbers if possible in the runtime call and store
in excluded property list.
BUG=v8:5549
Review-Url: https://codereview.chromium.org/2639333004
Cr-Commit-Position: refs/heads/master@{#42581}
Allocate space in the backing store for computed property names.
The property backing store was pre-allocated for the constant
properties up to the first non-constant (computed name) property.
To use lowering for storing data properties in literals
with computed property names effectively, a fast store is needed, i.e.,
available space in the property backing store for properties
with computed names.
backing_store_size is the number of all properties (including
computed names, but without __proto__)
that is calculated in the ast and passed to the runtime function that allocates
the property backing store. backing_store_size and
constant_properties constitute a BoilerplateDescription.
backing_store_size might be slightly too high because computed names
can evaluate to the same name, but that should be a rare
case so over-allocating is OK.
If a property is __proto__, we don't store it as a regular
property, because the map changes. Keep track of
has_seen_proto in the parser to calculate the
backing store size correctly.
BUG=v8:5625
Review-Url: https://codereview.chromium.org/2632503003
Cr-Commit-Position: refs/heads/master@{#42576}
Let the Typer assign proper types to Map, Set, WeakMap and WeakSet
builtins. Also assign a proper type to Array.isArray, Object.assign
and Object.create.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2640783006
Cr-Commit-Position: refs/heads/master@{#42535}
Also update a call in cctest to check the result.
BUG=chromium:681843
Review-Url: https://codereview.chromium.org/2647573003
Cr-Commit-Position: refs/heads/master@{#42513}
Since the script origin is part of the key used in the compilation
cache, this ensures that the cache never confuses a module with a
non-module script.
BUG=v8:1569,v8:5685
Review-Url: https://codereview.chromium.org/2611643002
Cr-Commit-Position: refs/heads/master@{#42490}
A future linear version of the hash table will only need the element count and
deleted element count. Hence moving them to the beginning of the underlying
fixed array makes the transition easier.
BUG=v8:5717
Review-Url: https://codereview.chromium.org/2630373002
Cr-Commit-Position: refs/heads/master@{#42459}
This rewrites the rest property into a runtime call which sets up the
correct properties in the newly created object.
- Changes flag to --harmony-object-rest-spread
- Changes pattern rewriter to desugar rest property
- Adds new runtime function CopyDataPropertiesWithExcludedProperties
BUG=v8:5549
Review-Url: https://codereview.chromium.org/2620943002
Cr-Commit-Position: refs/heads/master@{#42430}
In the ideal case, this will speed up Object.create(null) by ~10x.
Drive-by-fix: Spread usage of new IsSpecialReceiverMap() and
IsSpecialReceiverInstanceType(InstanceType) helpers.
BUG=v8:5788
Review-Url: https://codereview.chromium.org/2622723003
Cr-Commit-Position: refs/heads/master@{#42336}
In the ideal case, this will speed up Object.create(null) by ~10x.
Drive-by-fix: Spread usage of new IsSpecialReceiverMap() and
IsSpecialReceiverInstanceType(InstanceType) helpers.
BUG=v8:5788
Review-Url: https://codereview.chromium.org/2622723003
Cr-Commit-Position: refs/heads/master@{#42321}
Before, in `var p1 = p.then(() => {}) we would trigger the
before/after callbacks with p as the associated promise, but we must
call it with p1.
Also removes promise from PromiseReactionJobInfo.
Review-Url: https://codereview.chromium.org/2633443002
Cr-Commit-Position: refs/heads/master@{#42295}
The constant field tracking implies data constants to be stored
in fields instead of descriptor arrays. This CL does necessary
modifications to the JSModuleNamespace map setup.
BUG=v8:1569, v8:5495
Review-Url: https://codereview.chromium.org/2625093005
Cr-Commit-Position: refs/heads/master@{#42294}
This is a necessary cleanup before introducing PropertyConstness bit.
BUG=v8:5495
Review-Url: https://codereview.chromium.org/2624903003
Cr-Commit-Position: refs/heads/master@{#42277}
Reason for revert:
Blocks roll, ASan detects leaking ExternalStrings.
Original issue's description:
> Internalize strings in-place (reland^2)
>
> using newly introduced ThinStrings, which store a pointer to the actual,
> internalized string they represent.
>
> BUG=v8:4520
>
> (Previously landed as #42168 / af51befe69)
> (Previously landed as #42193 / 4c699e349a)
>
> Review-Url: https://codereview.chromium.org/2549773002
> Cr-Commit-Position: refs/heads/master@{#42235}
> Committed: ec45e6ed2eTBR=ishell@chromium.org,hpayer@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:4520
Review-Url: https://codereview.chromium.org/2626893005
Cr-Commit-Position: refs/heads/master@{#42271}
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2620753003
Cr-Original-Commit-Position: refs/heads/master@{#42258}
Committed: 3188780410
Review-Url: https://codereview.chromium.org/2620753003
Cr-Commit-Position: refs/heads/master@{#42264}
Reason for revert:
gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/8105
also on mac
Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2620753003
> Cr-Commit-Position: refs/heads/master@{#42258}
> Committed: 3188780410TBR=bmeurer@chromium.org,mstarzinger@chromium.org,yangguo@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2626863004
Cr-Commit-Position: refs/heads/master@{#42260}
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2620753003
Cr-Commit-Position: refs/heads/master@{#42258}
using newly introduced ThinStrings, which store a pointer to the actual,
internalized string they represent.
BUG=v8:4520
(Previously landed as #42168 / af51befe69)
(Previously landed as #42193 / 4c699e349a)
Review-Url: https://codereview.chromium.org/2549773002
Cr-Commit-Position: refs/heads/master@{#42235}
and rename WasmFrame to WasmCompiledFrame.
The WasmToInterpreterFrames are not used yet; this will follow in a
follow-up CL (see tracking bug for the overall picture).
Those frames will represent frames for WASM_TO_INTERPRETER stubs, which
call from wasm code to the wasm interpreter, implemented in C++.
They will support the Summarize method to inspect the stack frames in
the wasm interpreter.
R=yangguo@chromium.org, titzer@chromium.org
BUG=v8:5822
Review-Url: https://codereview.chromium.org/2623773004
Cr-Commit-Position: refs/heads/master@{#42213}
Reason for revert:
blocks roll, see: https://codereview.chromium.org/2628733002/
Debug mode runs into an Abort("External string expected, but not found").
Original issue's description:
> Internalize strings in-place (reland)
>
> using newly introduced ThinStrings, which store a pointer to the actual,
> internalized string they represent.
>
> BUG=v8:4520
>
> (Previously landed as #42168 / af51befe69.
>
> Review-Url: https://codereview.chromium.org/2549773002
> Cr-Commit-Position: refs/heads/master@{#42193}
> Committed: 4c699e349aTBR=ishell@chromium.org,hpayer@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:4520
Review-Url: https://codereview.chromium.org/2625073002
Cr-Commit-Position: refs/heads/master@{#42212}
using newly introduced ThinStrings, which store a pointer to the actual,
internalized string they represent.
BUG=v8:4520
(Previously landed as #42168 / af51befe69.
Review-Url: https://codereview.chromium.org/2549773002
Cr-Commit-Position: refs/heads/master@{#42193}
Including a fix: object-macros.h needs to be the last include: otherwise
we'll have a problem when a file does this:
#include "object-macros.h"
#include "x.h" // x.h also includes object-macros.h
BUG=v8:5402
Review-Url: https://codereview.chromium.org/2623573003
Cr-Commit-Position: refs/heads/master@{#42187}
... including property reconfiguring, elements kind change and migration
of a map to an up-to-date non-deprecated version.
BUG=v8:5495
Review-Url: https://codereview.chromium.org/2601643002
Cr-Commit-Position: refs/heads/master@{#42177}
using newly introduced ThinStrings, which store a pointer to the actual,
internalized string they represent.
BUG=v8:4520
Review-Url: https://codereview.chromium.org/2549773002
Cr-Commit-Position: refs/heads/master@{#42168}
The pattern IsNull(isolate) || IsUndefined(isolate) is used in many places all
over the code base.
Review-Url: https://codereview.chromium.org/2601503002
Cr-Commit-Position: refs/heads/master@{#42138}
This patch adds parsing of spread object property.
-- Changes ParsePropertyName to parse Token::ELLIPSIS.
-- Throws if rest is encountered by setting a pattern error.
-- Adds a new PropertyKind enum (SPREAD)
-- Adds a new ObjectLiteralProperty::kind (SPREAD)
-- Adds a new harmony-object-spread flag and protects the parser code
with it.
-- Adds a new runtime function called CopyDataProperties
-- Does not add any support for this feature in fullcodegen.
-- Ignition calls out to a runtime function CopyDataProperties to
perform spread operation.
-- Move FastAssign from builtins-objects.cc to objects.cc
-- Refactor Builtin_ObjectAssign to use SetOrCopyDataProperties
Object rest will be implemented in a follow on patch.
BUG=v8:5549
Review-Url: https://codereview.chromium.org/2606833002
Cr-Commit-Position: refs/heads/master@{#42102}
-- Removes remaning debug from promise.js and moves it to c++
-- Changes debug_id to be a smi in PromiseReactionJobInfo and
PromiseResolveThenableJobInfo.
-- Changes debug_name to be a smi in PromiseReactionJobInfo and
PromiseResolveThenableJobInfo.
-- Adds PromiseDebugActionName and PromiseDebugActionType enums
-- Adds PromiseDebugActionNameToString and
PromiseDebugActionTypeToString helper methods
-- Changes variable `status` to be int in runtime functions.
-- Changes debug_id to start from 1, not 0 for easier bookkeeping.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2606093002
Cr-Commit-Position: refs/heads/master@{#42052}
Migrate Date.prototype.valueOf and Date.prototype[ @@toPrimitive ]
to use the CodeStubAssembler, to avoid going through C++ always
when comparing or subtracting two dates.
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2608143003
Cr-Commit-Position: refs/heads/master@{#42030}
- Adds CodeAssembler::ConstructJS() to simplify calling JS functions as
constructors, used by NewPromiseCapability()
- Defines PromiseCapability as a special JSObject subclass, with a
non-exensible Map, and read-only non-configurable DataDescriptors which
point to its in-object fields. This allows its fields to be used by JS
builtins until there is no longer any need.
Currently, the performance benefit comes from
https://codereview.chromium.org/2567033003/, but does not appear to
regress performance in any significant way.
BUG=v8:5343
TBR=ulan@chromium.org
Review-Url: https://codereview.chromium.org/2567333002
Cr-Commit-Position: refs/heads/master@{#42014}
This patch stores the promise, resolve, reject properties of the
deferred object created by CreateInternalPromiseCapability and
NewPromiseCapability directly on the promise (if the promise hasn't
been fulfilled), otherwise they are stored on the
PromiseReactionJobInfo.
This patch removes the currently unused
CreateInternalPromiseCapability and inlines the call to create the
deferred promise object.
NewPromiseCapability is the only function that works with a deferred.
This patch results in a 8.5% improvement in benchmarks over 5 runs.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2590563003
Cr-Commit-Position: refs/heads/master@{#41991}
In certain corner-cases we would grow a FAST_ELEMENTS packed backing store of a
JS_ARGUMENTS_TYPE object without converting to holey elements kinds. As a side
effect you could then read out the_hole.
BUG=v8:5772
Review-Url: https://codereview.chromium.org/2597013004
Cr-Commit-Position: refs/heads/master@{#41921}
Reason for revert:
Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/
Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2504153002
> Cr-Commit-Position: refs/heads/master@{#41893}
> Committed: 93df094081TBR=bmeurer@chromium.org,mlippautz@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2597163002
Cr-Commit-Position: refs/heads/master@{#41917}
This CL includes several small bug fixes for trap handlers. Among the changes:
* Use the correct representation for ProtectedLoads, enabling protected loads of
floating point types.
* Including the protected instruction list in what gets serialized for Code
objects. This is needed to allow deserialization for Wasm modules to work.
* Get the context needed to through and exception from the Isolate rather than
getting it as a parameter to the Protected instructions. Passing it in as an
argument is problematic when code is compiled ahead of time, as the context
may not be known yet. The new approach is similar to how it works for TrapIf
and TrapUnless.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2591903002
Cr-Commit-Position: refs/heads/master@{#41907}
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2504153002
Cr-Commit-Position: refs/heads/master@{#41893}
Add inlineable fast-paths for Object::ToPropertyKey, Object::ToLength and
Object::ToIndex for the most common argument types.
BUG=
Review-Url: https://codereview.chromium.org/2587013002
Cr-Commit-Position: refs/heads/master@{#41856}
Add inlineable fast-paths for Object::ToPropertyKey, Object::ToLength and
Object::ToIndex for the most common argument types.
BUG=
Review-Url: https://codereview.chromium.org/2587013002
Cr-Commit-Position: refs/heads/master@{#41839}
STRUCT_LIST and INSTANCE_TYPE_LIST are now forced to have the same order
as the InstanceType enum.
Drive-by-fix 1: Move type check and cast functions closer together in objects-inl.h
Drive-by-fix 2: Remove unused instance types SIGNATURE_INFO_TYPE and TYPE_SWITCH_INFO_TYPE.
BUG=
Review-Url: https://codereview.chromium.org/2578573002
Cr-Commit-Position: refs/heads/master@{#41804}
This CL adds inlineable fast-cases for the above conversion functions in
objects-inl.h and a slower conversion function in objects.cc.
BUG=
Review-Url: https://codereview.chromium.org/2579023002
Cr-Commit-Position: refs/heads/master@{#41766}
Many websites use simple calls to String.prototype.indexOf with either a
one character ASCII needle or needles bigger than the search string. This
CL adds a TFJ builtin for these simple cases, giving up to factor 5 speedup.
Drive-by-fix: Add default Object type to Arguments.at
BUG=
Review-Url: https://codereview.chromium.org/2539093002
Cr-Commit-Position: refs/heads/master@{#41760}
This introduces an explicit struct for the communication channel between
the {ArrayLiteral} AST node and the corresponding runtime methods. Those
methods take a pair of {ElementsKind} as well as an array (can either be
a FixedArray or a FixedDoubleArray) of constant values.
For bonus points it also reduces the size of the involved heap object by
one word (i.e. length field of FixedArray not needed anymore).
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2581683003
Cr-Commit-Position: refs/heads/master@{#41752}
Reason for revert:
LiveEdit is broken in some cases.
Original issue's description:
> Store SharedFunctionInfos of a Script in a FixedArray indexed by their ID
>
> Now that SharedFunctionInfos have a unique ID (and the IDs are dense),
> we can use them as an index into an array, instead of using a
> WeakFixedArray where we have to do a linear scan.
>
> Hooking up liveedit is a bit more involved, see
> https://docs.google.com/presentation/d/1FtNa3U7WsF5bPhY9uGoJG5Y9hnz5VBDabfOWpb4unWI/edit
> for an overview
>
> BUG=v8:5589
> R=verwaest@chromium.org,jgruber@chromium.org
>
> Committed: https://crrev.com/6595e7405769dc9d49e9568d61485efc6d468baf
> Cr-Commit-Position: refs/heads/master@{#41600}
TBR=jgruber@chromium.org,verwaest@chromium.org,yangguo@chromium.org,jochen@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5589,chromium:673950
NOPRESUBMIT=true
Review-Url: https://codereview.chromium.org/2578433002
Cr-Commit-Position: refs/heads/master@{#41684}
Splits PromiseHandle into two TF builtins to account for catch
prediction. An exception in PromiseHandleReject builtin results in a
"caught" prediction whereas an expception in PromiseHandle results in a
"promise rejection" prediction.
An extra is_exception_caught bit is added to Code to mark this catch
prediction behavior.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2572623002
Cr-Commit-Position: refs/heads/master@{#41683}
Generalize Messages to include an error level.
Add a parameter to AddMessageHandler to select which error levels to receive, using a mask (default being just errors, i.e. the current behavior).
BUG=v8:4203
R=dgozman@chromium.org,machenbach@chromium.org,danno@chromium.org,bmeurer@chromium.org,jochen@chromium.org
Review-Url: https://codereview.chromium.org/2526703002
Cr-Commit-Position: refs/heads/master@{#41648}
Logging for --perf-prof is not GC safe. Now, we are going to
emit source position info for optimized code when we are
profiling, logging, or debugging, and under the same condition,
pre-compute the line ends array for line number computation.
R=tebbi@chromium.org
BUG=v8:5730
Review-Url: https://codereview.chromium.org/2562973002
Cr-Commit-Position: refs/heads/master@{#41619}
In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").
This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
table, but two (one for the call, one for the parent which does the
type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
two calls in the WASM_TO_JS wrapper (only if the module origin is
asm.js).
- the StackFrame::State struct now also holds the callee_pc_address,
which is set in ComputeCallerState. The WASM frame uses this
information to determine whether the callee frame is WASM_TO_JS, and
whether that frame is at the ToNumber conversion call.
- the same information is also stored in the FrameArray which is used
to reconstruct the stack trace later.
R=titzer@chromium.org, bradnelson@chromium.orgCC=jgruber@chromium.org
BUG=v8:4203,v8:5724
Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
Review-Url: https://codereview.chromium.org/2555243002
Cr-Original-Commit-Position: refs/heads/master@{#41599}
Cr-Commit-Position: refs/heads/master@{#41613}
Reason for revert:
gc-stress failures
Original issue's description:
> [wasm] Fix location for error in asm.js ToNumber conversion
>
> In the asm.js code translated to wasm, we call imported functions via a
> WASM_TO_JS stub, which first calls the function and then calls ToNumber
> on the return value. Exceptions can happen in both calls.
> We were only ever reporting the location of the function call, whereas
> asm.js code executed via turbofan reported the location of the type
> coercion operator ("+" on "+foo()" or "|" on "foo()|0").
>
> This CL implements the same behaviour for asm.js code translated to
> wasm. The following is changed:
> - the AsmWasmBuilder records the parent node when descending on a binary
> operator (also "+foo()" is represented by a binary operation).
> - it stores not one location per call in the source position side
> table, but two (one for the call, one for the parent which does the
> type coercion).
> - the wasm compiler annotates the source positions "0" and "1" to the
> two calls in the WASM_TO_JS wrapper (only if the module origin is
> asm.js).
> - during stack trace generation (in the StackTraceIterator), when we
> move from the WASM_TO_JS frame to the WASM frame, we remember at which
> call inside the WASM_TO_JS wrapper we are, and encode this information
> in the generated caller state, used for the WASM frame.
> - the same information is also stored in the FrameArray which is used
> to reconstruct the stack trace later.
>
> R=titzer@chromium.org, bradnelson@chromium.org
> CC=jgruber@chromium.org
> BUG=v8:4203,v8:5724
>
> Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
> Cr-Commit-Position: refs/heads/master@{#41599}
TBR=bradnelson@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4203,v8:5724
Review-Url: https://codereview.chromium.org/2563613003
Cr-Commit-Position: refs/heads/master@{#41601}
In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").
This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
table, but two (one for the call, one for the parent which does the
type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
two calls in the WASM_TO_JS wrapper (only if the module origin is
asm.js).
- during stack trace generation (in the StackTraceIterator), when we
move from the WASM_TO_JS frame to the WASM frame, we remember at which
call inside the WASM_TO_JS wrapper we are, and encode this information
in the generated caller state, used for the WASM frame.
- the same information is also stored in the FrameArray which is used
to reconstruct the stack trace later.
R=titzer@chromium.org, bradnelson@chromium.orgCC=jgruber@chromium.org
BUG=v8:4203,v8:5724
Review-Url: https://codereview.chromium.org/2555243002
Cr-Commit-Position: refs/heads/master@{#41599}
The patch was reverted due to a bug - we failed to evict OSR-optimized
code in the case where the SharedFunctionInfo OptimizedCodeMap was
empty/cleared.
Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point.
Review-Url: https://codereview.chromium.org/2561083002
Cr-Commit-Position: refs/heads/master@{#41584}
-- Moves promiseHasHandlerSymbol to inobject property
-- Ports PromiseResolveClosure to TF
-- Fix a non spec async-await test which fails now because we do a map
check for native promise check (instead of IsPromise). Changing the
constructor (in the test) invalidates the map check.
This patch results in a 7.1% performance improvement in the bluebird
benchmark (over 5 runs).
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2541283002
Cr-Commit-Position: refs/heads/master@{#41569}
Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point.
BUG=
Review-Url: https://codereview.chromium.org/2549753002
Cr-Commit-Position: refs/heads/master@{#41554}
This just calls into a runtime function for implementation currently.
Intermediate step in speeding up constructor calls containing a spread.
The NewWithSpread bytecode will probably end up having different arguments with future CLs - the constructor and the new.target should have their own regs. For now we are calling into the runtime function, so we need the regs together.
BUG=v8:5659
Review-Url: https://codereview.chromium.org/2541113004
Cr-Commit-Position: refs/heads/master@{#41542}
Reason for revert:
Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/11861
See:
https://github.com/v8/v8/wiki/Blink-layout-tests
Original issue's description:
> Object
> -- New JSObject for promises: JSPromise
>
> Builtins
> -- PromiseThen TFJ
> -- PromiseCreateAndSet TFJ for internal use
> -- PerformPromiseThen TFJ for internal use
> -- PromiseInit for initial promise setup
> -- SpeciesConstructor for use in PromiseThen
> -- ThrowIfNotJSReceiver for use in SpeciesConstructor
> -- AppendPromiseCallback to update FixedArray with new callback
> -- InternalPerformPromiseThen
>
> Promises.js
> -- Cleanup unused symbols
> -- Remove PerformPromiseThen
> -- Remove PromiseThen
> -- Remove PromiseSet
> -- Remove PromiseAttachCallbacks
>
> Runtime
> -- PromiseSet to set promise inobject values
> -- Refactor functions to use FixedArrays for callbacks instead of
> JSArray
> -- Runtime_PromiseStatus to return promise status
> -- Runtime_PromiseResult to return promise result
> -- Runtime_PromiseDeferred to return deferred attached to promise
> -- Runtime_PromiseRejectReactions to return reject reactions attached
> to promise
>
> This CL results in a 13.07% improvement in the promises benchmark
> (over 5 runs).
>
> BUG=v8:5343
>
> Committed: https://crrev.com/30b564c76f490f8f6b311a74b25b26cf0a96be2d
> Cr-Commit-Position: refs/heads/master@{#41503}
TBR=bmeurer@chromium.org,jgruber@chromium.org,caitp@igalia.com,gsathya@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2554013002
Cr-Commit-Position: refs/heads/master@{#41512}
-- New JSObject for promises: JSPromise
Builtins
-- PromiseThen TFJ
-- PromiseCreateAndSet TFJ for internal use
-- PerformPromiseThen TFJ for internal use
-- PromiseInit for initial promise setup
-- SpeciesConstructor for use in PromiseThen
-- ThrowIfNotJSReceiver for use in SpeciesConstructor
-- AppendPromiseCallback to update FixedArray with new callback
-- InternalPerformPromiseThen
Promises.js
-- Cleanup unused symbols
-- Remove PerformPromiseThen
-- Remove PromiseThen
-- Remove PromiseSet
-- Remove PromiseAttachCallbacks
Runtime
-- PromiseSet to set promise inobject values
-- Refactor functions to use FixedArrays for callbacks instead of
JSArray
-- Runtime_PromiseStatus to return promise status
-- Runtime_PromiseResult to return promise result
-- Runtime_PromiseDeferred to return deferred attached to promise
-- Runtime_PromiseRejectReactions to return reject reactions attached
to promise
This CL results in a 13.07% improvement in the promises benchmark
(over 5 runs).
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2536463002
Cr-Commit-Position: refs/heads/master@{#41503}
During bootstrapping when installing the global object we copy over the
properties from the snapshotted global object to the one created from a
provided template. Originally Genesis::TransferNamedProperties just iterated
over the entries, making the final order hash and thus platform dependent.
This CL fixes this by sorting the keys by enumeration index before copying them
to the destination object and thus making the key enumaration on the global
object platform independent.
Drive-by-fix: avoid crash when printing the global object during bootstrapping.
BUG=chromium:669029
Review-Url: https://codereview.chromium.org/2533223002
Cr-Commit-Position: refs/heads/master@{#41502}
Adds a bytecode_age field to BytecodeArray objects. This is incremented each
time the bytecode array is marked by GC, and reset to zero if the bytecode
is executed.
This is used to enable the CompilationCache for interpreted functions,
where Interpreted entries are evicted once the bytecode becomes old.
BUG=chromium:666275,v8:4680
Review-Url: https://codereview.chromium.org/2534763003
Cr-Commit-Position: refs/heads/master@{#41356}
MarkingParity was used to avoid performing an operation on an object if it was
marked multiple times. We no longer mark things multiple times, so this concept
is no longer required.
BUG=chromium:666275
Review-Url: https://codereview.chromium.org/2529173002
Cr-Commit-Position: refs/heads/master@{#41354}
FunctionTemplateInfo::SetPrototypeProviderTemplate adds support for sharing
prototypes between several function templates. This is used to properly set up
Image.prototype and HTMLImageElement.protoype which should be equal according
to the spec.
BUG=chromium:2969
Review-Url: https://codereview.chromium.org/2531653002
Cr-Commit-Position: refs/heads/master@{#41343}
The range-based exception handler table is by now only used for bytecode
arrays. The semantics of the interpreter are that bytecode offsets point
to the beginning of the currently executing bytecode instruction. Uses
hence need to compensate for lookups based on a "retrun address". This
change removes the need for such off-by-one compensations by changing
lookup semantics to be based on "current instruction" offsets.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2534893002
Cr-Commit-Position: refs/heads/master@{#41339}
TypedArrays need specific checks before calling OrdinaryDefineOwnProperty.
BUG=v8:5328
Review-Url: https://codereview.chromium.org/2431223005
Cr-Commit-Position: refs/heads/master@{#41333}
This removes the supporting function to perform a range-lookup in the
exception handler table for unoptimized code. Such tables are by now
guaranteed to be empty, the deoptimizer cannot encounter this case.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2529343003
Cr-Commit-Position: refs/heads/master@{#41318}
They're supposed to be stable across several parse passes, so we'll also
store them in the associated SharedFunctionInfos
To achieve this, the PreParser and Parser need to generated the same number of
FunctionLiterals. To achieve this, we teach the PreParser about desuggaring of
class literals.
For regular functions, the function IDs are assigned in the order they occur in
the source. For arrow functions, however, we only know that it's an arrow function
after parsing the parameter list, and so the ID assigned to the arrow function is
larger than the IDs assigned to functions defined in the parameter list. This
implies that we have to reset the function ID counter to before the parameter list
when re-parsing an arrow function. To be able to do this, we store the number of
function literals found in the parameter list of arrow functions as well.
BUG=v8:5589
Review-Url: https://codereview.chromium.org/2481163002
Cr-Commit-Position: refs/heads/master@{#41309}
For a couple of those Array builtins we can specify a useful type that
will help us to eliminate a couple of checks on their outputs.
R=yangguo@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2529233002
Cr-Commit-Position: refs/heads/master@{#41295}
Assign types to the remaining builtins on the String.prototype where we
know a meaningful type, i.e. where the type is not dependent on some
callable function that is pass or loaded.
BUG=v8:5267
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2532463002
Cr-Commit-Position: refs/heads/master@{#41294}
This removes support for try-catch as well as try-finally constructs
from the {FullCodeGenerator}. Consequently optimized code containing
such constructs must use the {BytecodeGraphBuilder} and can no longer
use the {AstGraphBuilder} for graph building.
R=jarin@chromium.org
BUG=v8:5657
Review-Url: https://codereview.chromium.org/2521233002
Cr-Commit-Position: refs/heads/master@{#41279}
For dictionary-mode receivers, the KeyedStoreGeneric stub can store
properties directly in most cases. Doing so avoids the need to have
an entry in the stub cache for every map/property combination.
Original review: https://codereview.chromium.org/2504403005/
Review-Url: https://codereview.chromium.org/2528883003
Cr-Commit-Position: refs/heads/master@{#41272}
Recognize a couple of builtins on the RegExp.prototype in the Typer and
assign useful types to them, so we can optimize various checks on their
results.
R=yangguo@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2531463002
Cr-Commit-Position: refs/heads/master@{#41240}
For dictionary-mode receivers, the KeyedStoreGeneric stub can store
properties directly in most cases. Doing so avoids the need to have
an entry in the stub cache for every map/property combination.
Original review: https://codereview.chromium.org/2504403005/
Review-Url: https://codereview.chromium.org/2524943002
Cr-Commit-Position: refs/heads/master@{#41218}
Passing in the isolate to retrieve the heap constants (undefine, the_hole, null)
has a positive performance impact.
BUG=
Review-Url: https://codereview.chromium.org/2517153002
Cr-Commit-Position: refs/heads/master@{#41210}
Reason for revert:
Blocks roll: https://codereview.chromium.org/2526573002/
Original issue's description:
> [stubs] KeyedStoreGeneric: inline dictionary property stores
>
> For dictionary-mode receivers, the KeyedStoreGeneric stub can store
> properties directly in most cases. Doing so avoids the need to have
> an entry in the stub cache for every map/property combination.
>
> Committed: https://crrev.com/af168e330e95c4460fd1bb7734f0e9a750f2e748
> Cr-Commit-Position: refs/heads/master@{#41185}
TBR=ishell@chromium.org,rmcilroy@chromium.org,jkummerow@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/2528583002
Cr-Commit-Position: refs/heads/master@{#41207}
For dictionary-mode receivers, the KeyedStoreGeneric stub can store
properties directly in most cases. Doing so avoids the need to have
an entry in the stub cache for every map/property combination.
Review-Url: https://codereview.chromium.org/2504403005
Cr-Commit-Position: refs/heads/master@{#41185}
The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results.
Other changes in this CL:
- DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front.
- I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan.
- I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention.
- I removed CodeDeoptEvent::position, as it is no longer used.
R=alph@chromium.org
BUG=v8:5432
Review-Url: https://codereview.chromium.org/2503393002
Cr-Commit-Position: refs/heads/master@{#41168}
This renames the {operand_stack} field to {register_file}, to refelct
how said field is used on all {JSGeneratorObject} instances by now. This
is a pure refactoring CL, not changes in semantics.
R=neis@chromium.org
Review-Url: https://codereview.chromium.org/2520913002
Cr-Commit-Position: refs/heads/master@{#41140}
This is the TurboFan counterpart of http://crrev.com/2504263004, but it
is a bit more involved, since in TurboFan we always inline the appropriate
call to the @@hasInstance handler, and by that we can optimize a lot more
patterns of instanceof than Crankshaft, and even yield fast instanceof
for custom @@hasInstance handlers (which we can now properly inline as
well).
Also we now properly optimize Function.prototype[@@hasInstance], even if
the right hand side of an instanceof doesn't have the Function.prototype
as its direct prototype.
For the baseline case, we still rely on the global protector cell, but
we can address that in a follow-up as well, and make it more robust in
general.
TEST=mjsunit/compiler/instanceof
BUG=v8:5640
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2511223003
Cr-Commit-Position: refs/heads/master@{#41092}
With this change, WebAssembly.Memory objects have backing stores allocated as an
8GB region where everything beyond the size of the Wasm heap is inaccessible.
GrowMemory is now implemented by changing the protection on the guard regions to
make the new portions of the heap accessible.
Guard pages are not enabled by default, but this change adds a flag and a test
variant to make sure we get test coverage on them.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2396433008
Cr-Commit-Position: refs/heads/master@{#41089}
Inspector uses this type for all internal scripts, e.g. injected-script-source.js. Scripts with new type are not reported by remote debugging protocol, frames from them are ignored.
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
BUG=none
R=yangguo@chromium.org,dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2499273003
Cr-Commit-Position: refs/heads/master@{#41056}
In case of an allocation failure in for-in over holey elements, use precise
number of elements to allocate a smaller buffer for the collected indices.
Drive-by-fix: make is_the_hole accept the isolate for faster checks.
BUG=chromium:609761
Review-Url: https://codereview.chromium.org/2041963003
Cr-Commit-Position: refs/heads/master@{#41010}
Before, we allocated one script per function per instance, and each
script referenced the wasm instance and the function index. Now we only
allocate one script per compiled wasm module, so the script also only
references this WasmCompiledModule, which causes changes to many interfaces.
Instead of fixing the disassemble API only used via debug.js, I decided
to drop it for now. Some later CL will reintroduce it via
DebugInterface.
BUG=v8:5530,chromium:659715
R=yangguo@chromium.org, titzer@chromium.orgCC=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2493823003
Cr-Commit-Position: refs/heads/master@{#41004}
SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
- The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
- The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
The following additional changes were necessary:
- The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
- The class HPositionInfo was effectively dead code and is now removed.
- SourcePosition has new printing and information facilities, including computing a full inlining stack.
- I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
- I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
- I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
- Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
BUG=v8:5432
Review-Url: https://codereview.chromium.org/2451853002
Cr-Commit-Position: refs/heads/master@{#40975}
- Creates a new promise-utils.{h, cc} which refactors out the
logic to create resolving functions. This is shared between the
runtime functions and builtins.
- Changes PromiseResolveThenableJobInfo to store the context
since we no longer create the resolving functions in JS.
- Changes EnqueuPromiseResolveThenableJob to take in the promise and
not the callbacks.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2487053002
Cr-Commit-Position: refs/heads/master@{#40941}
Adds an IsInterpreted() function to both SharedFunctionInfo and JSFunction.
This is used to fix the test-heap code-aging tests since Ignition doesn't
age code.
BUG=v8:4680
Review-Url: https://codereview.chromium.org/2481433002
Cr-Commit-Position: refs/heads/master@{#40868}
This makes use of the newly introduced cell indices to speed up variable
accesses. Imports and local exports are now directly stored in (separate)
arrays. In the future, we may merge the two arrays into a single one, or
even into the module context.
This CL also replaces the LoadImport and LoadExport runtime functions with
a single LoadVariable taking a variable index as argument (rather than a
name).
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2465283004
Cr-Commit-Position: refs/heads/master@{#40808}
Some accessors requires little to no computation at all, its result can be
cached in a private property, avoiding the call overhead.
Calls to the getter are translated into a cheap property load.
Follow-on to crrev.com/2347523003, from peterssen@google.com
BUG=chromium:634276, v8:5548
Review-Url: https://codereview.chromium.org/2405213002
Cr-Commit-Position: refs/heads/master@{#40765}
Instead of having a MODULE variable's index be 0 or 1, let it be the index of
its cell. In this CL, we assign the indices but we continue to only use them to
distinguish imports from exports. Actually using them to directly access the
cells will be done in a later CL.
R=adamk@chromium.org
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2460233003
Cr-Commit-Position: refs/heads/master@{#40752}
This CL adds support for primitive maps to
1) PrototypeIterator,
2) PropertyHandlerCompiler::CheckPrototypes(),
3) Map::GetOrCreatePrototypeChainValidityCell(),
4) Prototype checks in data-driven ICs.
BUG=v8:5561
Review-Url: https://codereview.chromium.org/2466553002
Cr-Commit-Position: refs/heads/master@{#40673}
This is useful for things that don't ever change, but we don't want to
eagerly compute the result.
Doing this from the embedder is difficult, using DefineOwnProperty would
read the property to get the property descriptor, creating an endless
recursion.
R=verwaest@chromium.org,haraken@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2449783006
Cr-Commit-Position: refs/heads/master@{#40648}
Reuses (and renames) the SFI "mark for optimization" flag to also permit
marking for baseline recompilation. The flag now represents a "tier up"
request, and CompileLazy can get baseline code as well as optimized
code.
BUG=v8:5512
Review-Url: https://codereview.chromium.org/2448933002
Cr-Commit-Position: refs/heads/master@{#40612}
For instance, when an import cannot be resolved, actually
point at the corresponding import statement.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2451153002
Cr-Commit-Position: refs/heads/master@{#40594}
Object.create(null) is most likely to be used for dictionary-like objects.
Hence it would be beneficial to directly create a slow-mode object and avoid
additional overhead later-on.
BUG=
Review-Url: https://codereview.chromium.org/2430273007
Cr-Commit-Position: refs/heads/master@{#40551}
The current method of marking functions for optimization, which replaces
the JSFunction's code object with one that triggers optimization, would
never allow unnamed functions to be optimized. This is an issue for a
style of programming which heavily relies on passing around closures.
This patch sets a bit on the SharedFunctionInfo when a JSFunction is
marked. When another JSFunction referring to the same SharedFunctionInfo
is lazily compiled, it immediately triggers a non-concurrent optimize.
BUG=v8:5512
Review-Url: https://chromiumcodereview.appspot.com/2437043002
Cr-Commit-Position: refs/heads/master@{#40506}
Implements the variations of CreateArrayIterator() in TFJ builtins
(ArrayPrototypeValues, ArrayPrototypeEntries and ArrayPrototypeKeys), and
provides two new Object types with numerous maps which identify certain
behaviours, which will be useful for inlining.
Removes src/js/array-iterator.js entirely
Also adds support for printing Symbol literals inserted by the Parser during
desugaring when FLAG_print_builtin_ast is set to true.
BUG=v8:5388
R=bmeurer@chromium.org, cbruni@chromium.orgTBR=ulan@chromium.org
Review-Url: https://codereview.chromium.org/2405253006
Cr-Commit-Position: refs/heads/master@{#40373}
Now that all accesses to the last match info are in C++ and TF code, we can
finally turn the last match info into a FixedArray. Similar to the ArrayList,
it uses its first field to store its length and grows dynamically in amortized
O(1) time.
Unlike previously, this means that the last match info pointer stored on the
context can actually change (in case the FixedArray needs to grow).
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2415103002
Cr-Commit-Position: refs/heads/master@{#40308}
This CL also adds separate runtime call stats buckets for data handlers.
BUG=
Review-Url: https://codereview.chromium.org/2419513002
Cr-Commit-Position: refs/heads/master@{#40281}
This moves the implementation of @@replace from regexp.js to builtins-regexp.cc
(the TurboFan fast path) and runtime-regexp.cc (slow path). The fast path
handles all cases in which the regexp itself is an unmodified JSRegExp
instance, the given 'replace' argument is not callable and does not contain any
'$' characters (i.e. we are doing a string replacement).
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2398423002
Cr-Commit-Position: refs/heads/master@{#40253}
