Class Constructors are special, because they are callable but [[Call]]
raises an exception. Instead of checking if a JS function is a class
constructor for every JS function call, this CL adds a new instance
type for class constructors.
This way we can use a fast instance type range check for the common
case, and only check for class constructors in the uncommon case were
a class constructor is called and when we need to raise an exception.
Change-Id: Ic6fdd9829722d05559fdfd01f6100c61873a0872
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186434
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77140}
This reverts commit 0adc1410b1.
Reason for revert: Reverting due to fail on V8 Linux - noi18n - debug https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8836095186331011153/+/u/Check_-_default/function-exist
Original change's description:
> [Temporal] Part 1 - Skeleton
>
> 1. Expose all the functions to empty buildins.
> 2. Wire up basic structure of classes and internal slots.
>
> Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/
>
> This is just a CL to establish a skeleton for Temporal.
> The Temporal is very big. The prototype CL is in
> https://chromium-review.googlesource.com/c/v8/v8/+/2967755
> but too big to be reviewed so I break up the basic structure here first.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel
> Bug: v8:11544
> Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76819}
Bug: v8:11544
Change-Id: I358f671452a986c8e87d1f831ab5eb1550a38441
Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160467
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76821}
1. Expose all the functions to empty buildins.
2. Wire up basic structure of classes and internal slots.
Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/
This is just a CL to establish a skeleton for Temporal.
The Temporal is very big. The prototype CL is in
https://chromium-review.googlesource.com/c/v8/v8/+/2967755
but too big to be reviewed so I break up the basic structure here first.
Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel
Bug: v8:11544
Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76819}
DataView constructor, DataView.prototype.byteLength
and DataView.prototype.byteOffset should throw
TypeError when the buffer was detached.
Both SpiderMonkey and JSC passed the test262 suites.
Bug: v8:12162
Change-Id: I126d24213c00e4d26540519bce9b5388862eb32c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140015
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76818}
Remove the BaselineData intermediate structure for baseline code, and
write the baseline Code object into the SharedFunctionInfo directly. We
still need a pointer to the BytecodeArray/InterpreterData, so re-use the
Code object's deoptimization data slot for this (baseline code doesn't
have deoptimization data).
A consequence of this is that the BytecodeArray pointer becomes
immutable when there is baseline code. This means that we cannot install
a debug BytecodeArray while baseline code is active (we have to flush it
first), and we can't tier-up code with debug BytecodeArray to baseline.
Change-Id: I53b93ec4d4c64b833603d7992f246982fcd97596
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118548
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76675}
Rather than depending on slow signature checks, receiver type checks are
performed using fast numeric instance type checks.
This CL adds a instance type range for embedders to assign values and
uses these to perform type checks.
Bug: v8:11476
Change-Id: Ie8236ae47ca0ba93ae76a7e690b81aa0a2b0f3e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883623
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76162}
Also introduce a separate error type for WebAssembly.Exception,
since the properties should not be added to RuntimeError.
R=jkummerow@chromium.org
Bug: v8:11992
Change-Id: I8f4ae0da9a95184366e07dc43e58a5a9ff4382ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055304
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76061}
The JS API constructor was renamed to "WebAssembly.Tag" to match the
spec:
https://github.com/WebAssembly/exception-handling/issues/159
Rename "exception" to "tag" throughout the codebase for consistency with
the JS API, and to match the spec terminology (e.g. "tag section").
R=clemensb@chromium.org,nicohartmann@chromium.org
Bug: v8:11992
Change-Id: I63f9f3101abfeefd49117461bd59c594ca5dab70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053583
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75994}
This is a first step towards supporting unwrapped WasmObject objects on
JavaScript side.
In addition this CL
1) introduces Representation::WasmValue which is used for all WasmObject
fields exposed to JavaScript side.
2) adds creation of meaningful DescriptorArrays for WasmObject's Maps.
Bug: v8:11804
Change-Id: I4afcd39da5cb77b659943da54a2ca34d13bcc9bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912776
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74744}
... and use the generated WasmObject instance type range for data refs
checks.
Bug: v8:11804
Change-Id: I855ff76404ff7e3ca919dabec238d35cb39c0baf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910784
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74713}
We used to recompile WasmCapiCallWrappers whenever they were
needed, but never garbage-collected them, which caused a memory
leak when many short-lived instances of the same module were
created. This patch makes the wrappers cacheable and caches them,
which avoids both repeated compilation effort and the unbounded
memory growth.
Drive-by cleanup: unify WasmCapiFunctionData with the other
Wasm*FunctionData classes by making it inherit from WasmFunctionData.
Bug: v8:11774
Change-Id: Ia0c0d76be2938dc7bebfdc845f4a1cfeafef4a70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905605
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74682}
This is a reland of 054ff044bc
Change since revert:
- Remove assignment to FLAG_enable_short_builtins in test since
it's write-once in CFI.
Original change's description:
> Reland^2 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64"
>
> This is a reland of 1f504c36da
>
> Changes since revert:
>
> - Removed disabling of RO heap sharing when --stress-snapshot is passed;
> was fixed by f4a6c628c9
> - Fixed crashing tests that caused revert separately in
> a61aa4919f
>
> Original change's description:
> > > [ptr-cage] Turn on shared pointer cage by default for arm64 and x64
> > >
> > > Reviewed-on:
> > https://chromium-review.googlesource.com/c/v8/v8/+/2873226
> > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#74422}
> >
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878855
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Adam Klein <adamk@chromium.org>
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Dan Elphick <delphick@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#74448}
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891460
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74546}
TBR=adamk@chromium.org
Bug: v8:11460
Change-Id: Ib7526270d421a562cb00aec9a28b4fc2296e4a86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2893567
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74548}
This is a reland of 1f504c36da
Changes since revert:
- Removed disabling of RO heap sharing when --stress-snapshot is passed;
was fixed by f4a6c628c9
- Fixed crashing tests that caused revert separately in
a61aa4919f
Original change's description:
> > [ptr-cage] Turn on shared pointer cage by default for arm64 and x64
> >
> > Reviewed-on:
> https://chromium-review.googlesource.com/c/v8/v8/+/2873226
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#74422}
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878855
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74448}
Bug: v8:11460
Change-Id: I4e491574437f4c832e24b29815de6bdfd8975511
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891460
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74546}
This is a reland of 6c65e858a6
Changes since revert:
- Add --disable-shared-ro-heap-for-testing flag that is implied by
d8's --stress-snapshot, since RO heap sharing currently
does not support deserializing/serializing while original Isolate
is still running
- Add BUILD.gn assert that v8_enable_pointer_compression_shared_cage
requires x64 or arm64
Original change's description:
> [ptr-cage] Turn on shared pointer cage by default for arm64 and x64
>
> Bug: v8:11460
> Change-Id: I9ab419b5e90fbe677e1d63b41699d90552839e98
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2873226
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74422}
Bug: v8:11460
Change-Id: I7eb189b7f8ac3e30da96b0dadd2c085f08a1a0b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878855
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74448}
By (mostly) unifying the different kinds of WasmFunctionData, and
precomputing and caching what we can, we can reduce the amount of
work that has to be done for each call.
We still have to store the current instance for JS function calls;
that may be eliminatable in the future.
WasmCapiFunctions are not included in the refactoring yet.
Bug: v8:7748,v8:9495
Change-Id: Ie6839153153d5854670cd01bc77a86111c1f68d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2856543
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74287}
This is a reland of c83c9590ba
Changes since revert: nothing, issue was crbug.com/v8/11666
Original change's description:
> [ic] Add a new MegaDOM IC
>
> This patch implements the MegaDOM IC setup and access. A new MegaDOM
> IC state indicates that we've seen only DOM accessors at this access
> site.
>
> This CL only adds support for DOM getters in LoadIC, other kinds of
> access will be added in follow on CLs.
>
> Still remaining TODO before shipping:
> 1. Have a mechanism to invalidate the protector
> 2. Have a mechanism to find the accessors that aren't overloaded
> 3. Use a new builtin to miss to runtime on access check failure
>
> Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
> Bug: v8:11321
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73733}
Bug: v8:11321
Change-Id: I2bec54465542b5b40c42adb6eb12b6ce72cce5bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794439
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74056}
This reverts commit c83c9590ba.
Reason for revert: Speculatively reverting for a failure on Arm GC stress bot - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Arm%20GC%20Stress/b8851256837192083520/overview
Original change's description:
> [ic] Add a new MegaDOM IC
>
> This patch implements the MegaDOM IC setup and access. A new MegaDOM
> IC state indicates that we've seen only DOM accessors at this access
> site.
>
> This CL only adds support for DOM getters in LoadIC, other kinds of
> access will be added in follow on CLs.
>
> Still remaining TODO before shipping:
> 1. Have a mechanism to invalidate the protector
> 2. Have a mechanism to find the accessors that aren't overloaded
> 3. Use a new builtin to miss to runtime on access check failure
>
> Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
> Bug: v8:11321
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73733}
Bug: v8:11321
Change-Id: Ib6a55796f2a3c345d4923f9eaa215a6ff55ed15b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794437
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73734}
This patch implements the MegaDOM IC setup and access. A new MegaDOM
IC state indicates that we've seen only DOM accessors at this access
site.
This CL only adds support for DOM getters in LoadIC, other kinds of
access will be added in follow on CLs.
Still remaining TODO before shipping:
1. Have a mechanism to invalidate the protector
2. Have a mechanism to find the accessors that aren't overloaded
3. Use a new builtin to miss to runtime on access check failure
Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
Bug: v8:11321
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73733}
This is a reland of 80f5dfda01. A condition
in pipeline.cc was inverted, which lead to a CSA verifier error.
Original change's description:
> [no-wasm] Exclude src/wasm from compilation
>
> This is the biggest chunk, including
> - all of src/wasm,
> - torque file for wasm objects,
> - torque file for wasm builtins,
> - wasm builtins,
> - wasm runtime functions,
> - int64 lowering,
> - simd scala lowering,
> - WasmGraphBuilder (TF graph construction for wasm),
> - wasm frame types,
> - wasm interrupts,
> - the JSWasmCall opcode,
> - wasm backing store allocation.
>
> Those components are all recursively entangled, so I found no way to
> split this change up further.
>
> Some includes that were recursively included by wasm headers needed to
> be added explicitly now.
>
> backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
> because it only tests wasm backing stores. This file is excluded from
> no-wasm builds then.
>
> R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
>
> Bug: v8:11238
> Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
> Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73344}
TBR=jgruber@chromium.org
Bug: v8:11238
Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73348}
This reverts commit 80f5dfda01.
Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview
Original change's description:
> [no-wasm] Exclude src/wasm from compilation
>
> This is the biggest chunk, including
> - all of src/wasm,
> - torque file for wasm objects,
> - torque file for wasm builtins,
> - wasm builtins,
> - wasm runtime functions,
> - int64 lowering,
> - simd scala lowering,
> - WasmGraphBuilder (TF graph construction for wasm),
> - wasm frame types,
> - wasm interrupts,
> - the JSWasmCall opcode,
> - wasm backing store allocation.
>
> Those components are all recursively entangled, so I found no way to
> split this change up further.
>
> Some includes that were recursively included by wasm headers needed to
> be added explicitly now.
>
> backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
> because it only tests wasm backing stores. This file is excluded from
> no-wasm builds then.
>
> R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
>
> Bug: v8:11238
> Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
> Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73344}
Bug: v8:11238
Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73346}
This is the biggest chunk, including
- all of src/wasm,
- torque file for wasm objects,
- torque file for wasm builtins,
- wasm builtins,
- wasm runtime functions,
- int64 lowering,
- simd scala lowering,
- WasmGraphBuilder (TF graph construction for wasm),
- wasm frame types,
- wasm interrupts,
- the JSWasmCall opcode,
- wasm backing store allocation.
Those components are all recursively entangled, so I found no way to
split this change up further.
Some includes that were recursively included by wasm headers needed to
be added explicitly now.
backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
because it only tests wasm backing stores. This file is excluded from
no-wasm builds then.
R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
Bug: v8:11238
Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73344}
This change relands the last part of https://crrev.com/c/2601880 .
ScopeInfo has a vestigial 'length' field from when it used to be a
FixedArray. This change removes that field, which saves some memory.
More specifically:
- Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
supplied the 'length' field.
- Change FactoryBase::NewScopeInfo to allocate the updated object shape.
It maintains the existing behavior of filling the newly-allocated
object with undefined, even though that's not a valid ScopeInfo and
further initialization is required.
- Change a few length computations to use HeapObject::kHeaderSize rather
than FixedArray::kHeaderSize.
- Remove an unnecessary heap verifier function.
Change-Id: I9b3980157568fdb0402fa31660949966b401fd31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2733037
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#73278}
This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/2688058
This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.
This CL adds the initialization code, factory functions and a
canonical SwissNameDictionary plus all helpers required for that.
Bug: v8:11388
Change-Id: I9cf66a3fa755288f7730f55abfb6e6cea82f6b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2703653
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72857}
This reverts commit f731e13f00.
Reason for revert: perf regressions, chromium:1179757
Original change's description:
> Remove 'length' field from ScopeInfo
>
> ScopeInfo has a vestigial 'length' field from when it used to be a
> FixedArray. This change removes that field, which saves some memory.
>
> More specifically:
>
> - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
> supplied the 'length' field.
> - Privatize the FixedArray-style functions that provide access to
> ScopeInfo fields by index, and move them from scope-info-inl.h to
> scope-info.cc. Those functions are still used pretty heavily during
> initialization (ScopeInfo::Create, etc.), but at least we can avoid
> presenting them to the rest of the world.
> - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
> It maintains the existing behavior of filling the newly-allocated
> object with undefined, even though that's not a valid ScopeInfo and
> further initialization is required.
> - Move part of AccessorAssembler::ScriptContextTableLookup into a new
> Torque macro, because it used to rely on casting ScopeInfo to
> FixedArrayBase.
> - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
> arrays. I think it makes more sense to list them under "(system)" in
> the dev tools, like most other V8 internal types.
>
> Bug: v8:8952
> Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72830}
Bug: v8:8952
Change-Id: I00a69da79e5ac6aaae4436a41ce773ae014cc775
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706086
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72855}
ScopeInfo has a vestigial 'length' field from when it used to be a
FixedArray. This change removes that field, which saves some memory.
More specifically:
- Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
supplied the 'length' field.
- Privatize the FixedArray-style functions that provide access to
ScopeInfo fields by index, and move them from scope-info-inl.h to
scope-info.cc. Those functions are still used pretty heavily during
initialization (ScopeInfo::Create, etc.), but at least we can avoid
presenting them to the rest of the world.
- Change FactoryBase::NewScopeInfo to allocate the updated object shape.
It maintains the existing behavior of filling the newly-allocated
object with undefined, even though that's not a valid ScopeInfo and
further initialization is required.
- Move part of AccessorAssembler::ScriptContextTableLookup into a new
Torque macro, because it used to rely on casting ScopeInfo to
FixedArrayBase.
- In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
arrays. I think it makes more sense to list them under "(system)" in
the dev tools, like most other V8 internal types.
Bug: v8:8952
Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72830}
This reverts commit 2f8a7561cb.
Reason for revert: Speculative revert, lots of segfaults on Arm:
https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/17781
Original change's description:
> [dict-proto] C++ implementation of SwissNameDictionary, pt. 3
>
> This CL is part of a series that adds the C++ implementation of
> SwissNameDictionary, a deterministic property backing store based on
> Swiss Tables.
>
> This CL adds the initialization code, factory functions and a
> canonical SwissNameDictionary plus all helpers required for that.
>
> Bug: v8:11388
> Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Frank Emrich <emrich@google.com>
> Cr-Commit-Position: refs/heads/master@{#72824}
Bug: v8:11388
Change-Id: Ia5dae584b0fb452b12c5d64ee63ffa418c83f91b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698758
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72829}
This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.
This CL adds the initialization code, factory functions and a
canonical SwissNameDictionary plus all helpers required for that.
Bug: v8:11388
Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#72824}
As outlined in the design document linked below, we're removing the
support for the non-standard Function.displayName property for the
purpose of Error.stack and DevTools Inspector stack traces. The
motivation here is that the negative lookup is costly, and we have
Function.name as a standard alternative (configurable since ES6 for
exactly this reason).
I dediced to go with JSFunction::GetDebugName(), since
JSFunction::GetName() was confusing in that it'd only get the "name"
property's value if it's a data property, but not with accessors.
JSFunction::GetDebugName() makes it clear that this is really a debug
helper function and might not give you the "name" property value.
Doc: https://bit.ly/devtools-function-displayName-removal
Bug: v8:8742, chromium:1177685, chromium:1077657, chromium:17356
Change-Id: I7717585cbace626174b2f2ed2a4f68f75429eca1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692189
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72715}
Currently we sometimes refer to baseline code or the baseline compiler
by its codename (Sparkplug). The codename is fun, but we should be
consistent and call things by one name or the other. Following the
pattern of Ignition stuff being called "interpreter", we call Sparkplug
"baseline", and leave the codename only in flags and variants.
Bug: v8:11420
Change-Id: I432e5629518be7c7ad38b6acff024c91d4cfd6d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692186
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72696}
Following up on https://crrev.com/c/2689185, this CL significantly
simplifies the whole implementation of the stack trace capturing.
Before this CL, capturing any stack trace (for the purpose of the API or
Error.stack) would roughly work like this:
1. The CaptureStackTrace() function uses the StackFrameIterator to
walk the system stack. For each native frame it uses the
FrameSummary abstraction to get all (including potentially inlined)
frames. For each of those it appends a record consisting of six
elements to a FrameArray (this holds pointers to the actual
closures and receivers).
2. Afterwards the FrameArray is shrinked to the required size, and a
new FixedArray is allocated, and initialized with new
StackTraceFrame objects where each holds a reference to the
FrameArray, the index of the frame, and an initially uninitialized
StackFrameInfo reference. This new FixedArray is then returned from
CaptureStackTrace() and either stored on a message object or
provided to the API as v8::StackTrace.
The new approach removes a lot of the machinery in between and directly
creates a FixedArray of StackFrameInfo objects in CaptureStackTrace().
These StackFrameInfo objects are directly exposed as v8::StackFrame on
the public API, and they hold the six fields that were previously stored
flat in the FrameArray. This not only avoids a lot of copying around of
data and creation of temporary objects and handles, but most importantly
unifies and simplifies the stack frame function inside StackFrameInfo,
so you no longer need to wonder which function / object might be
responsible for a certain API.
There's still a lot of room for improvement. In particular we currently
don't cache the source position for a given StackFrameInfo (or
globally), but rather recompute it every time. This is still very fast,
significantly faster than the previous approach.
There are some notable (potentially user visible) changes:
- The CallSite#GetPosition() method now consistently returns the
Wasm module relative bytecode offset for all Wasm frames (previously
it'd return the function relative bytecode offset for non-asm.js
Wasm frames).
- The column and line numbers returned from StackFrameInfo methods are
consistently 1-based now, instead of sometimes being 0-based (Wasm)
and sometimes being 1-based (JS and asm.js Wasm). The only
potentially noticable difference is that for
CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but
that was wrong and useless anyways.
- CallSite#GetThis() would sometimes return the_hole, another bug
flushed out by this CL.
The CL also contains some other not noteworthy drive-by-cleanups.
Fixed: chromium:1057211
Bug: chromium:1077657, chromium:1069425, v8:8742
Bug: chromium:1127391, chromium:1098530, chromium:981541
Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72694}
Sparkplug is a new baseline, non-optimising second-tier compiler,
designed to fit in the compiler trade-off space between Ignition and
TurboProp/TurboFan.
Design doc:
https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing
Bug: v8:11420
Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72686}
For a long time, V8 had two distinct ways to capture and store a stack
trace, one where we'd just collect and symbolize the information for the
v8::StackTrace API (script id, name, line and colum information mostly),
and one where V8 would also memorize the closures, receivers, and
optionally the parameters of the stack frame, which we use for
Error.stack and the non-standard CallSite APIs. Those two were often out
of sync and suffered from various different issues. Eventually they were
refactored into a single captureStackTrace() bottleneck that would
produce a FrameArray.
This CL is a logical continuation of the refactorings. It repairs a
regression where we'd compute the method name (as part of the
cached StackFrameInfo) even if we don't need them (as is the case for
the inspector and any other use of the v8::StackTrace API).
Everytime a method was invoked on StackTraceFrame, it'd call into
StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo
like this:
1. Create a FrameArrayIterator and point it to the FrameArray at the
index stored in the StackTraceFrame.
2. Invoke FrameArrayIterator::Frame(), which copies the information
from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame
or WasmStackFrame C++ object, and use the StackFrameBase virtual
methods to transfer all information to a newly created
StackFrameInfo object.
3. Kill the link to the FrameArray and put a link to the
StackFrameInfo object into the StackTraceFrame.
This caching turned out to be extremely costly, since beyond other
things, it'd always invoke JSStackFrame::GetMethodName(), which is
extremely costly (the execution time is linear in the number of
properties on the receiver and it's prototype chain). The cost was so
high that several work-arounds had been added, which would avoid
triggering the eager construction of the StackFrameInfo object (i.e.
https://crrev.com/c/2080663, https://crrev.com/c/2550504 or
https://crrev.com/c/2261736, but also https://crrev.com/c/1688927).
This CL removes the StackFrameInfo caching completely, since neither the
inspector nor Error.stack benefit from the caching at all. It's only the
first part in a series of refactorings that will significantly reduce
the complexity and overhead of the stack trace collection.
Doc: https://bit.ly/2wkbuIy
Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742
Bug: chromium:1127391, chromium:1098530, chromium:981541
Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72647}
This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.
This CL contains most of the boilerplate code for introducing a new
instance type.
Bug: v8:11388
Change-Id: Id263b8138a8ce4b465fb28d968223d2e1aaf05a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672030
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#72582}
BREAKING CHANGE: The values of Wasm locals, stack, and globals are now
represented as objects instead of holding the (primitive) values
directly, and SIMD128 values are no longer represented as Uint8Arrays.
The DWARF extension has been prepared for this breaking change.
The new `WasmValue` comes with `type` and `value` properties that hold
its contents. The motivation here is that this is a more extensible
approach. In case of SIMD128, the `value` property holds the canonical
string representation, which has the additional advantage that these
values can be compared with `===` (and `==`).
This partially reverts https://crrev.com/c/2614428, the main difference
here being that WasmValue is now a proper JSObject that can be exposed
on the DebugEvaluate proxy API.
Screenshot: https://imgur.com/rcahNKM.png
Bug: chromium:1170282, chromium:1071432, chromium:1159402
Change-Id: Iea304e3680775123c41deb4c3d172ac949da1b98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643384
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72570}
... and mark it as never-serialized wrt turbofan serialization.
Until this CL, the JSRegExp type was used as both for plain
user-visible regexp objects, and for internal regexp boilerplate
descriptions. Boilerplates are special: they are never exposed to the
user, they are only referenced from the feedback vector, they are
immutable.
To clarify this distinction, this CL introduces a dedicated struct
type RegExpBoilerplateDescription to hold the regexp boilerplate
description.
This makes Turbofan serialization simpler: boilerplates can be
accessed through direct reads since they are immutable. TF has no
special requirements on JSRegExp objects (it never reads into these
objects) and thus serializing only the references as a JSObjectRef is
fine.
Bug: v8:7790
Change-Id: I33b337fcfcf861a02bc6be6d0c6311d07cf05718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656257
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72522}
