[class] Add IC support for defining class fields to replace runtime call
Introduces several new runtime mechanics for defining private fields,
including:
- Bytecode StaKeyedPropertyAsDefine
- Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback}
- Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic}
- TurboFan IR opcode JSDefineProperty
These new operations can reduce a runtime call per class field into a
more traditional Store equivalent. In the microbenchmarks, this
results in a substantial win over the status quo (~8x benchmark score
for single fields with the changes, ~20x with multiple fields).
The TurboFan JSDefineProperty op is lowered in
JSNativeContextSpecialization, however this required some hacks.
Because private fields are defined as DONT_ENUM when added to the
object, we can't find a suitable transition using the typical data
property (NONE) flags. I've added a mechanism to specify the required
PropertyAttributes for the transition we want to look up.
Details:
New bytecodes:
- StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty
but with a different IC builtin (KeyedDefineOwnIC). This is a
bytecode rather than a flag for the existing StaKeyedProperty in
order to avoid impacting typical keyed stores in any way due to
additional branching and testing.
New builtins:
- StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for
StaNamedOwnProperty. Unlike the regular StoreIC, this variant will
no longer look up the property name in the prototype.
In adddition, this CL changes an assumption that
StoreNamedOwnProperty can't result in a map transition, as we
can't rely on the property already being present in the Map due
to an object literal boilerplate.
In the context of class features, this replaces the runtime
function %CreateDataProperty().
- KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the
new StaKeyedPropertyAsDefine bytecode. This is similar to an
ordinary KeyedStoreIC, but will not check the prototype for
setters, and for private fields, will take the slow path if the
field already exists.
In the context of class features, this replaces the runtime
function %AddPrivateField().
TurboFan IR:
- JSDefineProperty is introduced to represent a situation where we
need to use "Define" semantics, in particular, it codifies that we
do not consult the prototype chain, and the semantics relating to
private fields are implied as well.
R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org
Bug: v8:9888
Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77377}
2021-10-11 18:01:36 +00:00
|
|
|
// Copyright 2021 the V8 project authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
|
|
// found in the LICENSE file.
|
|
|
|
|
2022-04-28 14:22:23 +00:00
|
|
|
// Flags: --allow-natives-syntax --turbofan --trace-opt --trace-deopt
|
2021-11-02 02:58:01 +00:00
|
|
|
// Flags: --no-stress-flush-code --no-flush-bytecode
|
[class] Add IC support for defining class fields to replace runtime call
Introduces several new runtime mechanics for defining private fields,
including:
- Bytecode StaKeyedPropertyAsDefine
- Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback}
- Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic}
- TurboFan IR opcode JSDefineProperty
These new operations can reduce a runtime call per class field into a
more traditional Store equivalent. In the microbenchmarks, this
results in a substantial win over the status quo (~8x benchmark score
for single fields with the changes, ~20x with multiple fields).
The TurboFan JSDefineProperty op is lowered in
JSNativeContextSpecialization, however this required some hacks.
Because private fields are defined as DONT_ENUM when added to the
object, we can't find a suitable transition using the typical data
property (NONE) flags. I've added a mechanism to specify the required
PropertyAttributes for the transition we want to look up.
Details:
New bytecodes:
- StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty
but with a different IC builtin (KeyedDefineOwnIC). This is a
bytecode rather than a flag for the existing StaKeyedProperty in
order to avoid impacting typical keyed stores in any way due to
additional branching and testing.
New builtins:
- StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for
StaNamedOwnProperty. Unlike the regular StoreIC, this variant will
no longer look up the property name in the prototype.
In adddition, this CL changes an assumption that
StoreNamedOwnProperty can't result in a map transition, as we
can't rely on the property already being present in the Map due
to an object literal boilerplate.
In the context of class features, this replaces the runtime
function %CreateDataProperty().
- KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the
new StaKeyedPropertyAsDefine bytecode. This is similar to an
ordinary KeyedStoreIC, but will not check the prototype for
setters, and for private fields, will take the slow path if the
field already exists.
In the context of class features, this replaces the runtime
function %AddPrivateField().
TurboFan IR:
- JSDefineProperty is introduced to represent a situation where we
need to use "Define" semantics, in particular, it codifies that we
do not consult the prototype chain, and the semantics relating to
private fields are implied as well.
R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org
Bug: v8:9888
Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77377}
2021-10-11 18:01:36 +00:00
|
|
|
let privateSymbol = %CreatePrivateSymbol("private");
|
|
|
|
let privateName = %CreatePrivateNameSymbol("privateName");
|
|
|
|
|
|
|
|
function test() {
|
|
|
|
"use strict";
|
|
|
|
|
[ic] name Set/Define/Store property operations more consistently
For background and reasoning, see
https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit
This is the first step towards pulling the DefineNamedOwn operation out
of StoreIC.
Summary of the renamed identifiers:
Bytecodes:
- StaNamedProperty -> SetNamedProperty: calls StoreIC and emitted for
normal named property sets like obj.x = 1.
- StaNamedOwnProperty -> DefineNamedOwnProperty: calls
DefineNamedOwnIC (previously StoreOwnIC), and emitted for
initialization of named properties in object literals and named
public class fields.
- StaKeyedProperty -> SetKeyedProperty: calls KeyedStoreIC and emitted
for keyed property sets like obj[x] = 1.
- StaKeyedPropertyAsDefine -> DefineKeyedOwnProperty: calls
DefineKeyedOwnIC (previously KeyedDefineOwnIC) and emitted for
initialization of private class fields and computed public class
fields.
- StaDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: calls
DefineKeyedOwnPropertyInLiteral runtime function (previously
DefineDataPropertyInLiteral) and emitted for initialization of keyed
properties in object literals and static class initializers. (note
that previously the StoreDataPropertyInLiteral runtime function name
was taken by object spreads and array literal creation instead)
- LdaKeyedProperty -> GetKeyedProperty, LdaNamedProperty ->
GetNamedProperty, LdaNamedPropertyFromSuper ->
GetNamedPropertyFromSuper: we drop the Sta prefix for the property
store operations since the accumulator use is implicit and to make
the wording more natural, for symmetry the Lda prefix for the
property load operations is also dropped.
opcodes:
- (JS)StoreNamed -> (JS)SetNamedProperty: implements set semantics for
named properties, compiled from SetNamedProperty (previously
StaNamedProperty) and lowers to StoreIC or Runtime::kSetNamedProperty
- (JS)StoreNamedOwn -> (JS)DefineNamedOwnProperty: implements define
semantics for initializing named own properties in object literal and
public class fields, compiled from DefineNamedOwnProperty (previously
StaNamedOwnProperty) and lowers to DefineNamedOwnIC
(previously StoreOwnIC)
- (JS)StoreProperty -> (JS)SetKeyedProperty: implements set semantics
for keyed properties, only compiled from SetKeyedProperty(previously
StaKeyedProperty) and lowers to KeyedStoreIC
- (JS)DefineProperty -> (JS)DefineKeyedOwnProperty: implements define
semantics for initialization of private class fields and computed
public class fields, compiled from DefineKeyedOwnProperty (previously
StaKeyedPropertyAsDefine) and calls DefineKeyedOwnIC (previously
KeyedDefineOwnIC).
- (JS)StoreDataPropertyInLiteral ->
(JS)DefineKeyedOwnPropertyInLiteral: implements define semantics for
initialization of keyed properties in object literals and static
class initializers, compiled from DefineKeyedOwnPropertyInLiteral
(previously StaDataPropertyInLiteral) and calls the
DefineKeyedOwnPropertyInLiteral runtime function (previously
DefineDataPropertyInLiteral).
Runtime:
- DefineDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral:
following the bytecode/opcodes change, this is used by
DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral)
for object and class literal initialization.
- StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral_Simple:
it's just a simplified version of DefineDataPropertyInLiteral that
does not update feedback or perform function name configuration.
This is used by object spread and array literal creation. Since we
are renaming DefineDataPropertyInLiteral to
DefineKeyedOwnPropertyInLiteral, rename this simplified version with
a `_Simple` suffix. We can consider merging it into
DefineKeyedOwnPropertyInLiteral in the future. See
https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit?disco=AAAAQQIz6mU
- Other changes following the bytecode/IR changes
IC:
- StoreOwn -> DefineNamedOwn: used for initialization of named
properties in object literals and named public class fields.
- StoreOwnIC -> DefineNamedOwnIC
- StoreMode::kStoreOwn -> StoreMode::kDefineNamedOwn
- StoreICMode::kStoreOwn -> StoreICMode::kDefineNamedOwn
- IsStoreOwn() -> IsDefineNamedOwn()
- DefineOwn -> DefineKeyedOwn: IsDefineOwnIC() was already just
IsDefineKeyedOwnIC(), and IsAnyDefineOwn() includes both named and
keyed defines so we don't need an extra generic predicate.
- StoreMode::kDefineOwn -> StoreMode::kDefineKeyedOwn
- StoreICMode::kDefineOwn -> StoreICMode::kDefineKeyedOwn
- IsDefineOwn() -> IsDefineKeyedOwn()
- IsDefineOwnIC() -> IsDefineKeyedOwnIC()
- Removing IsKeyedDefineOwnIC() as its now a duplicate of
IsDefineKeyedOwnIC()
- KeyedDefineOwnIC -> DefineKeyedOwnIC,
KeyedDefineOwnGenericGenerator() -> DefineKeyedOwnGenericGenerator:
make the ordering of terms more consistent
- IsAnyStoreOwn() -> IsAnyDefineOwn(): this includes the renamed and
DefineNamedOwn and DefineKeyedOwn. Also is_any_store_own() is
removed since it's just a duplicate of this.
- IsKeyedStoreOwn() -> IsDefineNamedOwn(): it's unclear where the
"keyed" part came from, but it's only used when DefineNamedOwnIC
(previously StoreOwnIC) reuses KeyedStoreIC, so rename it accordingly
Interpreter & compiler:
- BytecodeArrayBuilder: following bytecode changes
- StoreNamedProperty -> SetNamedProperty
- StoreNamedOwnProperty -> DefineNamedOwnProperty
- StoreKeyedProperty -> SetKeyedProperty
- DefineKeyedProperty -> DefineKeyedOwnProperty
- StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral
- FeedbackSlotKind:
- kDefineOwnKeyed -> kDefineKeyedOwn: make the ordering of terms more
consistent
- kStoreOwnNamed -> kDefineNamedOwn: following the IC change
- kStoreNamed{Sloppy|Strict} -> kSetNamed{Sloppy|Strict}: only
used in StoreIC for set semantics
- kStoreKeyed{Sloppy|Strict} -> kSetKeyed{Sloppy|Strict}: only used
in KeyedStoreIC for set semantics
- kStoreDataPropertyInLiteral -> kDefineKeyedOwnPropertyInLiteral:
following the IC change
- BytecodeGraphBuilder
- StoreMode::kNormal, kOwn -> NamedStoreMode::kSet, kDefineOwn: this
is only used by BytecodeGraphBuilder::BuildNamedStore() to tell the
difference between SetNamedProperty and DefineNamedOwnProperty
operations.
Not changed:
- StoreIC and KeyedStoreIC currently contain mixed logic for both Set
and Define operations, and the paths are controlled by feedback. The
plan is to refactor the hierarchy like this:
```
- StoreIC
- DefineNamedOwnIC
- SetNamedIC (there could also be a NamedStoreIC if that's helpful)
- KeyedStoreIC
- SetKeyedIC
- DefineKeyedOwnIC
- DefineKeyedOwnICLiteral (could be merged into DefineKeyedOwnIC)
- StoreInArrayLiteralIC
- ...
```
StoreIC and KeyedStoreIC would then contain helpers shared by their
subclasses, therefore it still makes sense to keep the word "Store"
in their names since they would be generic base classes for both set
and define operations.
- The Lda and Sta prefixes of bytecodes not involving object properties
(e.g. Ldar, Star, LdaZero) are kept, since this patch focuses on
property operations, and distinction between Set and Define might be
less relevant or nonexistent for bytecodes not involving object
properties. We could consider rename some of them in future patches
if that's helpful though.
Bug: v8:12548
Change-Id: Ia36997b02f59a87da3247f20e0560a7eb13077f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3481475
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#79409}
2022-03-08 17:36:04 +00:00
|
|
|
// These computed properties are translated into
|
|
|
|
// JSDefineKeyedOwnPropertyInLiteral ops,
|
|
|
|
// and AccessInfoFactory::ComputePropertyAccessInfo should find a
|
[class] Add IC support for defining class fields to replace runtime call
Introduces several new runtime mechanics for defining private fields,
including:
- Bytecode StaKeyedPropertyAsDefine
- Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback}
- Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic}
- TurboFan IR opcode JSDefineProperty
These new operations can reduce a runtime call per class field into a
more traditional Store equivalent. In the microbenchmarks, this
results in a substantial win over the status quo (~8x benchmark score
for single fields with the changes, ~20x with multiple fields).
The TurboFan JSDefineProperty op is lowered in
JSNativeContextSpecialization, however this required some hacks.
Because private fields are defined as DONT_ENUM when added to the
object, we can't find a suitable transition using the typical data
property (NONE) flags. I've added a mechanism to specify the required
PropertyAttributes for the transition we want to look up.
Details:
New bytecodes:
- StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty
but with a different IC builtin (KeyedDefineOwnIC). This is a
bytecode rather than a flag for the existing StaKeyedProperty in
order to avoid impacting typical keyed stores in any way due to
additional branching and testing.
New builtins:
- StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for
StaNamedOwnProperty. Unlike the regular StoreIC, this variant will
no longer look up the property name in the prototype.
In adddition, this CL changes an assumption that
StoreNamedOwnProperty can't result in a map transition, as we
can't rely on the property already being present in the Map due
to an object literal boilerplate.
In the context of class features, this replaces the runtime
function %CreateDataProperty().
- KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the
new StaKeyedPropertyAsDefine bytecode. This is similar to an
ordinary KeyedStoreIC, but will not check the prototype for
setters, and for private fields, will take the slow path if the
field already exists.
In the context of class features, this replaces the runtime
function %AddPrivateField().
TurboFan IR:
- JSDefineProperty is introduced to represent a situation where we
need to use "Define" semantics, in particular, it codifies that we
do not consult the prototype chain, and the semantics relating to
private fields are implied as well.
R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org
Bug: v8:9888
Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77377}
2021-10-11 18:01:36 +00:00
|
|
|
// suitable map transition when optimizing. Even if the implementation details
|
|
|
|
// are ignored, we still want to assert that these properties are installed as
|
|
|
|
// non-enumerable, due to being private symbols.
|
|
|
|
|
|
|
|
let obj = {
|
|
|
|
[privateSymbol]: "private",
|
|
|
|
[privateName]: "privateName",
|
|
|
|
};
|
|
|
|
|
|
|
|
assertPropertiesEqual(Object.getOwnPropertyDescriptor(obj, privateSymbol), {
|
|
|
|
value: "private",
|
|
|
|
writable: true,
|
|
|
|
configurable: true,
|
|
|
|
enumerable: false,
|
|
|
|
});
|
|
|
|
|
|
|
|
assertPropertiesEqual(Object.getOwnPropertyDescriptor(obj, privateName), {
|
|
|
|
value: "privateName",
|
|
|
|
writable: true,
|
|
|
|
configurable: true,
|
|
|
|
enumerable: false,
|
|
|
|
});
|
|
|
|
|
|
|
|
// They don't leak via Object.keys(), Object.getOwnPropertyNames, or
|
|
|
|
// Object.getOwnPropertySymbols
|
|
|
|
let props = Object.getOwnPropertyNames(obj);
|
|
|
|
assertFalse(props.includes(privateSymbol));
|
|
|
|
assertFalse(props.includes(privateName));
|
|
|
|
|
|
|
|
let symbols = Object.getOwnPropertySymbols(obj);
|
|
|
|
assertFalse(symbols.includes(privateSymbol));
|
|
|
|
assertFalse(symbols.includes(privateName));
|
|
|
|
|
|
|
|
let keys = Object.keys(obj);
|
|
|
|
assertFalse(keys.includes(privateSymbol));
|
|
|
|
assertFalse(keys.includes(privateName));
|
|
|
|
|
|
|
|
return obj;
|
|
|
|
}
|
|
|
|
|
|
|
|
%PrepareFunctionForOptimization(test);
|
|
|
|
test();
|
|
|
|
test();
|
|
|
|
test();
|
|
|
|
%OptimizeFunctionOnNextCall(test);
|
|
|
|
test();
|
|
|
|
assertOptimized(test);
|