Tip of tree puts both internalized and in-place-internalizable strings
into the shared heap object cache. But only internalized strings need
to go in there, since we can't have duplicates of those. It's fine to
allocate in-place-internalizable strings in the shared heap each time
a new Isolate is initialized, it'll be deduplicated if it's
internalized eventually.
Bug: chromium:1258918, v8:12007
Change-Id: I0e46b73a5ac3be83d0eaa31915a3a24f47a8c2bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3219690
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77388}
Due to caching issues we will not be able to store host-defined options
directly on the Script anymore. ScriptOrModule can thus no longer be
a i::Script.
NodeJS keeps weak references from ScriptOrModule to their import meta
data. This CL changes ScriptOrModule to be a temporary struct which has
a different lifetime. As a temporary fix until the API is fully updated
we introduce the v8_scriptormodule_legacy_lifetime compile-time flag.
It keeps references to ScriptOrModule alive on the Script to restore the
previous behavior (at an additional memory cost).
Bug: chromium:1244145
Change-Id: I1dc42d25930d7bc4f22ee3c9bba93d89425be406
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211575
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77382}
This guarantees that if it's context-allocated, it'll be the first
slot in the context. That in turn allows us to drop a special index on
scope-info pointing at the receiver entry; once we update arguments
object handling to take the receiver possibly being there into
account.
Change-Id: Idfd06cf172e6905b02c8d17a962382e2a9ea0874
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211999
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77360}
This CL adds a new snapshot to hold objects that are in the shared heap
or may need to be in the shared heap depending on runtime flags.
Currently this is to support --shared-string-table, which puts all
in-place-internalizable strings, internalized strings, and the
string table into the shared heap.
The shared heap snapshot is never deserialized into client Isolates.
This means when V8 is started without a shared Isolate, the shared heap
snapshot is deserialized into all Isolates.
Bug: v8:12007
Change-Id: I7eeab73080cda2e8250a5a49747f25b2440a349d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173905
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77309}
This is a reland of 0adc1410b1
1. Fork out test/mjsunit/temporal/function-exist.js test
to test/mjsunit/temporal/function-exist-no-i18n.js and mark
function-exist FAIL in no_i18n build.
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: I60eaface94ba9b3408cb235cd1ae425151a36732
Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160324
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77303}
This patch adds infrastructure for collecting feedback about call_ref
call targets in Liftoff code, and using that feedback for turning
such calls into inlineable direct calls when building Turbofan graphs.
The feature is considered experimental quality and hence off by default,
--wasm-speculative-inlining turns it on.
Bug: v8:7748
Change-Id: I0d0d776f8a71c3dd2c9124d3731f3cb06d4f5821
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3205902
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77287}
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}
Fix 1: Track Scope::needs_home_object and Scope::uses_super_property
accurately. When "eval" is seen, figure out whether it can access
"super" and if yes, set the corresponding home object as needed.
Fix 2: The object literal scope shouldn't be entered for things
inside spreads.
Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
This saves memory (the home object doesn't need to be stored for each
method, but only once per class) and hopefully makes the home object
a constant in the optimized code.
Detailed documentation of the changes:
https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
Bug: v8:9237
Bug: chromium:1167918
Bug: chromium:1167981
Bug: chromium:1167988
Bug: chromium:1168055
Bug: chromium:1171195
Bug: chromium:1171600
Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72422}
This adds a [[WebAssemblyMemory]] internal property to ArrayBuffer and
SharedArrayBuffer instances that are owned by WebAssembly.Memory
objects. This allows the devtools-frontend to find the
WebAssembly.Memory for any given ArrayBuffer, making it possible to
properly support WebAssembly.memory.grow() eventually, but also showing
a reasonable tab title.
Before: https://imgur.com/hod9jPR.png
After: https://imgur.com/v195VoC.png
Bug: chromium:1171621, chromium:1171619, chromium:1166577
Change-Id: Ife22cabdfcf54ab30c234ea4ca86bfbb711ab2f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653155
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72403}
This reverts commit f6450b97ec.
Reason for revert: ClusterFuzz bugs
Original change's description:
> Reland [super] Store home object in Context instead of JSFunction
>
> 1) Computed property keys (esp functions in them) shouldn't be inside
> the object literal scope.
>
> 2) I was using an imprecise "maybe uses super" and storing it to
> preparse data. This won't fly, since it pollutes sister scopes and
> leads to confusion wrt whether an object literal needs a home object
> or not. Made it precise (mostly cancelling changes in the original CL).
>
> 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
> this_function (which made it used) -> inconsistent scopes between
> parsing and preparsing.
>
> 4) MultipleEntryBlockContextScope was messing up the accumulator
>
> Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
>
> This saves memory (the home object doesn't need to be stored for each
> method, but only once per class) and hopefully makes the home object
> a constant in the optimized code.
>
> Detailed documentation of the changes:
> https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
>
> Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
> Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72169}
TBR=marja@chromium.org,leszeks@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9237
Bug: chromium:1167918
Bug: chromium:1167981
Bug: chromium:1167988
Bug: chromium:1168055
Bug: chromium:1171195
Bug: chromium:1171600
Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72391}
This is a reland of b77deeca4b
Changes compared to original: Add explicit narrowing casts in tests
for MSVC.
Original change's description:
> [wasm-gc] Remove abstract rtts
>
> In the latest wasm-gc spec, rtts of abstract types are no longer
> allowed. Consequently, canonical rtts of concrete types always have
> a depth of 0.
>
> Changes:
> - Change the immediate argument of rtts to a type index over a heap
> type. Abstract it with TypeIndexImmediate in function body decoding.
> This affects:
> value_type.h, read_value_type(), decoding of relevant opcodes,
> wasm subtyping, WasmInitExpr, consume_init_expr(), and
> wasm-module-builder.cc.
> - In function-body-decoder-impl.h, update rtt.canon to always produce
> an rtt of depth 0.
> - Pass a unit32_t type index over a HeapType to all rtt-related
> utilities.
> - Remove infrastructure for abstract-type rtts from the wasm compilers,
> setup-heap-internal.cc, roots.h, and module-instantiate.cc.
> - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches
> from ref.test, ref.cast and br_on_cast implementations in the wasm
> compilers.
> - Remove unused 'parent' field from WasmTypeInfo.
> - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap,
> and CreateArrayMap.
> - Use more convenient arguments in IsHeapSubtypeOf.
> - Update tests.
>
> Bug: v8:7748
> Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72321}
Bug: v8:7748
Change-Id: I22b204b486fd185077cd6c7f15d492f5143f48fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650207
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72355}
The contract between V8 and Blink is that embedder fields belong to
Blink, at least when the object has two or more of them. Now we had 2-3
embedder fields used by the debug proxies and that was confusing Blink,
since it expects the first slot to hold an aligned pointer in that case
and we had a HeapObject reference stored there.
This is a quickfix, which avoids internal fields completely for the
context extension proxy (using interceptors on the prototype instead)
and changes the named proxies to store the name table under a private
symbol instead of using a second internal field.
A proper but way more involved fix is to introduce a proper instance
type here and use space in the header instead of misusing embedder
fields.
Fixed: chromium:1170283
Bug: chromium:1159402
Change-Id: I6c4bbe2fe88fef29a6b9946708588245efbbe72b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649033
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72323}
This reverts commit b77deeca4b.
Reason for revert: MSVC compile fails: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/16535/overview
Original change's description:
> [wasm-gc] Remove abstract rtts
>
> In the latest wasm-gc spec, rtts of abstract types are no longer
> allowed. Consequently, canonical rtts of concrete types always have
> a depth of 0.
>
> Changes:
> - Change the immediate argument of rtts to a type index over a heap
> type. Abstract it with TypeIndexImmediate in function body decoding.
> This affects:
> value_type.h, read_value_type(), decoding of relevant opcodes,
> wasm subtyping, WasmInitExpr, consume_init_expr(), and
> wasm-module-builder.cc.
> - In function-body-decoder-impl.h, update rtt.canon to always produce
> an rtt of depth 0.
> - Pass a unit32_t type index over a HeapType to all rtt-related
> utilities.
> - Remove infrastructure for abstract-type rtts from the wasm compilers,
> setup-heap-internal.cc, roots.h, and module-instantiate.cc.
> - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches
> from ref.test, ref.cast and br_on_cast implementations in the wasm
> compilers.
> - Remove unused 'parent' field from WasmTypeInfo.
> - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap,
> and CreateArrayMap.
> - Use more convenient arguments in IsHeapSubtypeOf.
> - Update tests.
>
> Bug: v8:7748
> Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72321}
TBR=ulan@chromium.org,jkummerow@chromium.org,manoskouk@chromium.org
Change-Id: I2f0d97f1a34f7c81c5a97d7c37925cb84c66eea3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7748
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650206
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72322}
In the latest wasm-gc spec, rtts of abstract types are no longer
allowed. Consequently, canonical rtts of concrete types always have
a depth of 0.
Changes:
- Change the immediate argument of rtts to a type index over a heap
type. Abstract it with TypeIndexImmediate in function body decoding.
This affects:
value_type.h, read_value_type(), decoding of relevant opcodes,
wasm subtyping, WasmInitExpr, consume_init_expr(), and
wasm-module-builder.cc.
- In function-body-decoder-impl.h, update rtt.canon to always produce
an rtt of depth 0.
- Pass a unit32_t type index over a HeapType to all rtt-related
utilities.
- Remove infrastructure for abstract-type rtts from the wasm compilers,
setup-heap-internal.cc, roots.h, and module-instantiate.cc.
- Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches
from ref.test, ref.cast and br_on_cast implementations in the wasm
compilers.
- Remove unused 'parent' field from WasmTypeInfo.
- Make the parent argument optional in NewWasmTypeInfo, CreateStructMap,
and CreateArrayMap.
- Use more convenient arguments in IsHeapSubtypeOf.
- Update tests.
Bug: v8:7748
Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72321}
This CL implements the upcoming spec change:
https://github.com/tc39/proposal-regexp-match-indices/pull/49
A new JSRegExpResultWithIndices subclass is introduced with a separate map and
an extra slot for storing the indices. If /d is passed, exec() constructs a
JSRegExpResultWithIndices and eagerly builds indices.
The existing re-execution logic is removed.
Bug: v8:9548
Change-Id: Ic11853e7521017af5e8bd583c7b82bb672821132
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616873
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72306}
This ensures that large objects have alignment suitable for a fixed
double arrays.
Bug: chromium:1161759
Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72251}
This change adds Torque field definitions for ScopeInfo and begins to
use the Torque-generated accessors in some places. It does not change
the in-memory layout of ScopeInfo.
Torque compiler changes:
- Fix an issue where the parser created constexpr types for classes
based on the class name rather than the `generates` clause. This meant
that generated accessors referred to the imaginary type HashTable
rather than the real C++ type FixedArray.
- Don't pass Isolate* through the generated runtime functions that
implement Torque macros. Maybe we'll need it eventually, but we don't
right now and it complicates a lot of things.
- Don't emit `kSomeFieldOffset` if some_field has an unknown offset.
Instead, emit a member function `SomeFieldOffset()` which fetches the
slice for some_field and returns its offset.
- Emit an `AllocatedSize()` member function for classes which have
complex length expressions. It fetches the slice for the last field
and performs the multiply&add to compute the total object size.
- Emit field accessors for fields with complex length expressions, using
the new offset functions.
- Fix a few minor bugs where Torque can write uncompilable code.
With this change, most code still treats ScopeInfo like a FixedArray, so
I would like to follow up with some additional changes:
1. Generate a GC visitor for ScopeInfo and use it
2. Generate accessors for struct-typed fields (indexed or otherwise),
and use them
3. Get rid of the FixedArray-style get and set accessors; use
TaggedField::load and similar instead
4. Inherit from HeapObject rather than FixedArrayBase to remove the
unnecessary `length` field
After that, there will only be one ugly part left: initialization. I
think it's possible to generate a factory function that takes a bunch of
iterator parameters and returns a fully-formed, verifiably correct
ScopeInfo instance, but doing so is more complicated than the four
mostly-mechanical changes listed above.
Bug: v8:7793
Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72187}
1) Computed property keys (esp functions in them) shouldn't be inside
the object literal scope.
2) I was using an imprecise "maybe uses super" and storing it to
preparse data. This won't fly, since it pollutes sister scopes and
leads to confusion wrt whether an object literal needs a home object
or not. Made it precise (mostly cancelling changes in the original CL).
3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
this_function (which made it used) -> inconsistent scopes between
parsing and preparsing.
4) MultipleEntryBlockContextScope was messing up the accumulator
Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
This saves memory (the home object doesn't need to be stored for each
method, but only once per class) and hopefully makes the home object
a constant in the optimized code.
Detailed documentation of the changes:
https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72169}
This will allow us optimize the protector cell checks in the fast path
from checking against the function object in every context to just
doing a range check against the instance type.
This patch adds new instance types for constructor functions that
require such protector cell checks.
Bug: v8:11256
Change-Id: Iea722f9c6326dfa470149dd02e689a23942097f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595442
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72146}
This reverts commit 4d5b878b61.
Reason for revert: Suspected to cause a failure on ChromeOS, which is blocking the roll - https://chromium-review.googlesource.com/c/chromium/src/+/2636263
Original change's description:
> [super] Store home object in Context instead of JSFunction
>
> This saves memory (the home object doesn't need to be stored for each
> method, but only once per class) and hopefully makes the home object
> a constant in the optimized code.
>
> Detailed documentation of the changes:
> https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
>
> Bug: v8:9237
> Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72137}
TBR=marja@chromium.org,leszeks@chromium.org
Change-Id: Idc5a8240cef4da8893ccc608ee4ae0d7206a1ba8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637215
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72142}
Removes:
- v8_disable_arguments_adaptor GN flag
- ArgumentsAdaptorTrampoline
- ArgumentsAdaptorFrame class
Change-Id: I382ebe6c25c3c172bee5df3e86e762fca10fa392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622911
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72133}
This reverts commit b3d09001eb.
Reason for revert: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 has to be reverted, and this was a follow-up to that
Original change's description:
> [objects] Remove uncached internal external string type
>
> We shouldn't be creating those anymore since they are not thread-safe.
>
> Bug: v8:7790
> Change-Id: I4546d995fa32eb076c8dfe9d95301fad719c9e07
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615347
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72006}
TBR=rmcilroy@chromium.org,leszeks@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7790
Change-Id: I4eb1a6b8446fa602eeb5bf29fbf1fe57182cdbf3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2627605
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72122}
We shouldn't be creating those anymore since they are not thread-safe.
Bug: v8:7790
Change-Id: I4546d995fa32eb076c8dfe9d95301fad719c9e07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615347
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72006}
Previously we had introduced a special `v8::internal::WasmValue` type
which we used to expose Wasm values to the Scope view in Chromium
DevTools. The problem however is that these values cannot be exposed to
JavaScript (and in particular not to Debug Evaluate), which means that
particularly for v128 and i64 we have inconsistent representations
across the various parts of DevTools.
This change removes the `wasm` type from the RemoteObject and all the
adjacent logic, and paves the way for a uniform representation of Wasm
values throughout DevTools. For i64 we will simply use BigInt
consistently everywhere, and for i32, f32 and f64 we'll just use Number.
For externref we will represent the values as-is directly. For v128
values we currently use a Uint8Array, but will introduce a dedicated
WasmSimd128 class in a follow-up CL.
Bug: chromium:1071432
Fixed: chromium:1159402
Change-Id: I0671e5736c9c27d7ca376e23ed74f16d36e03c80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614428
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71962}
This allows the JSFunctionOrBoundFunction instance type range to no
longer be stuck at the last of the JSObject instance type range. This
will be useful in the future where we extend the function instance
types and include them in fast protector cell checks.
Bug: v8:11256
Change-Id: I955991576b3cca76b10f76c87748016fe527e3d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595275
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71826}
Previously, we were looking up the prototype of the receiver and
checking that against %TypedArrayPrototype% before invalidating the
protector cell.
This is incorrect as it's possible to patch the prototype and then
change the constructor property, bypassing this check.
This CL adds a new instance type to prototype of all TypedArray
constructors and checks the receiver against this instance type.
TBR: tebbi@chromium.org
Bug: v8:11274, v8:11256
Change-Id: I2ff6280e4cf820b06c5593fe4addd36f7ac656c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2594776
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71799}
In the future, these instance types will be used for fast range checks
rather than the current slow individual map checks.
Bug: v8:11256
Change-Id: I4ad7d5259fbd46c3272a80996a5ac45a400d1f5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2590040
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71791}
Also construct the `JSMap`s used to store these names lazily and
only on-demand, and construct them directly instead of first doing
a `std::vector<Handle<String>>` and using that to construct the
`JSMap`. The latter resulted in a gigantic root set of 150k+ handles,
which wasn't well received by the GC.
Bug: chromium:1154154
Fixed: chromium:1154564
Also-By: bmeurer@chromium.org
Change-Id: I92e8931f15eda133e2a62b5cc53fbe1f2dafcead
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2568275
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71589}
ScopeInfo objects generally start with three fields: flags, parameter
count, and local variable count. But a single read-only ScopeInfo
instance has none of those fields. This is the empty ScopeInfo, which is
used for contexts that don't correspond to any scope (the native context
and contexts for builtin functions). Since there is only ever a single
instance of the empty ScopeInfo, the memory savings of omitting these
fields is trivial, and we can simplify logic somewhat by including them.
Rather than checking for length to be zero, this change introduces a new
flag indicating that a ScopeInfo instance is the empty one.
On its own, this change doesn't provide a whole lot of value. However,
it sets us up for two further improvements, which are consistent with
the goals outlined in [1]:
1. We should fully describe ScopeInfo fields in Torque. Getting rid of
the requirement to check for emptiness would substantially simplify the
indexed field expressions.
2. ScopeInfo shouldn't inherit from FixedArray, and shouldn't begin with
a `length` field when the length can be computed from the other fields.
This would save a small amount of heap memory and avoid any possibility
of a mismatch between the two ways of computing the length.
[1] https://docs.google.com/document/d/1tiGK7_lubxPHnInI2vscUwMHfadn8gIEa1apmI8HxR4/edit#heading=h.n63k76b3zfwa
Bug: v8:8952
Change-Id: I018127698a5d91fb2a91684bc3aec2e27ee27c41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2561598
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71500}
Drive-by Torque changes:
- kSize can be non-aligned, use SizeFor() instead for map allocation.
- Factory functions use Torque-generated setters directly to work even
if they are shadowed.
- Allow class generation in the presence of custom weak fields, this
was supported already.
Bug: v8:7793
Change-Id: I7e2df45d550ff70973e5167459050fd84db03114
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2547285
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71371}
Previously, we performed "is A subtype of B?" checks by walking
A's supertypes list and comparing every found type to B.
This CL stores not just A's immediate parent type on A, but its
entire list of supertypes, and uses that list plus compile-time
knowledge of B's distance to the root type in order to compare
only exactly one of A's supertypes to B.
Bug: v8:7748
Change-Id: I0011b72c4b54440b16494918f64d8fb119bef8b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2527097
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71127}
This change plumbs import assertions from SourceTextModuleDescriptor's
ModuleRequestMap into SourceTextModuleInfo via a new ModuleRequest
type, where previously there had been only the specifier.
SourceTextModuleDescriptor::module_map now deduplicates module requests
using the specifier and the import assertions. Continuing to use the
specifier alone would cause a loss of information in the event that
a module imports from the same specifier multiple times using different
sets of assertions. Failing to deduplicate at all would result in
multiple requests for statements like `import {a,b,c} from "foo.js"`,
which would be a potential performance issue. See design doc at
https://docs.google.com/document/d/1yuXgNHSbTAPubT1Mg0JXp5uTrfirkvO1g5cHHCe-LmY
for more detail on this decision.
v8::internal::ModuleRequest holds the assertions as an array of the form
[key1, value1, position1, key2, value2, assertion2, ...]. However the
parser still needs to use a map, since duplicate assertion keys need to
be detected at parse time. A follow-up change will ensure that
assertions are sorted using a proper lexicographic sort.
Bug: v8:10958
Change-Id: Iff13fb9a37d58fc1622cd3cce78925ad2b7a14bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493060
Commit-Queue: Dan Clark <daniec@microsoft.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71066}
This is a reland of 26f10ecd95
Change compared to original CL:
The deserializer changes StrongDescriptorArray to DescriptorArray.
Since this CL uses separate BodyDescriptors for the two kinds of
descriptor arrays, this caused a DCHECK failure when the deserializer
changes the map while the object is visited from the concurrent marking
thread. Fix this by disabling the corresponding checks.
Original change's description:
> [torque] allow exported classes with custom C++ class
>
> Introduce a new annotation @customCppClass that can be used for
> non-extern @export classes, that is, generate everything, remove
> boilerplate from all the internal lists and switches, but allow
> a custom C++ class, which in turn also allows overwriting the generated
> print and verify functions.
>
> Port DescriptorArray and StrongDescriptorArray as an example.
>
> Bug: v8:7793
> Change-Id: I744e52fb4102ac49c0097f1c95bb17d301975bf0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489687
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70989}
Bug: v8:7793
Change-Id: I7505fb111896991d16d7d113704c8c3676669f34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526383
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71048}
This reverts commit 26f10ecd95.
Reason for revert: GC stress failures:
https://crbug.com/v8/11114
Original change's description:
> [torque] allow exported classes with custom C++ class
>
> Introduce a new annotation @customCppClass that can be used for
> non-extern @export classes, that is, generate everything, remove
> boilerplate from all the internal lists and switches, but allow
> a custom C++ class, which in turn also allows overwriting the generated
> print and verify functions.
>
> Port DescriptorArray and StrongDescriptorArray as an example.
>
> Bug: v8:7793
> Change-Id: I744e52fb4102ac49c0097f1c95bb17d301975bf0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489687
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70989}
TBR=ulan@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org
Change-Id: I4631db66a76f41cf62b400e8ee64df27e641a320
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793,v8:11114
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2521911
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70994}
Introduce a new annotation @customCppClass that can be used for
non-extern @export classes, that is, generate everything, remove
boilerplate from all the internal lists and switches, but allow
a custom C++ class, which in turn also allows overwriting the generated
print and verify functions.
Port DescriptorArray and StrongDescriptorArray as an example.
Bug: v8:7793
Change-Id: I744e52fb4102ac49c0097f1c95bb17d301975bf0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489687
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70989}
Drive-by fixes:
- Use constexpr types to determine C++ type names.
- Fix factory constructors to not skip write barriers in old generation.
Change-Id: I0ebbfd56c06ad41d02836fb48531ae7eded166bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400994
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70921}
This commit adds the 'l' (linear) RegExp flag (as in e.g. /asdf|123/l)
that forces execution in linear time. These regexps are handled by the
experimental engine. If the experimental engine cannot handle the
pattern, an exception is thrown on creation of the regexp.
The commit also adds a new global V8 flag and changes an existing one:
* --enable-experimental-engine, which turns on recognition of the RegExp
'l' flag. Previously this flag also caused all supported regexps to
be executed by the experimental engine; this is not the case anymore.
* --default-to-experimental-regexp-engine takes over the previous
semantics of --enable-experimental-regexp-engine: We execute all
supported regexps with the experimental engine.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I5622a89b19404105e8be280d454e9fdd63c003b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461244
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Cr-Commit-Position: refs/heads/master@{#70892}
This CL provides synchronized get/set to feedback vector slots.
The FeedbackNexus is set up to use order preserving reads when used
on the background thread, and a lock to ensure coherent read
of information for ICKinds with two slots. The main thread takes
the lock on sets.
This test provides patterns to be followed by concurrent TurboFan.
We don't yet access the FeedbackVector on the background thread.
This CL only makes it safe to do so. The next step will come when
the optimizing compiler begins to query the the vector from the
background thread. Currently, with --concurrent-inlining turned on
this is done in bytecode serialization on the main thread. Without
concurrent inlining, it's also done on the main thread, in both
cases using the FeedbackNexus.
Bug: v8:7790
Change-Id: I49d8b8031190f91a0da1c24f375b6b6d8a9fe038
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2276210
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70797}
This changes OrderedHashMap, OrderedHashSet, and OrderedNameDictionary
as follows:
- Create a dedicated allocation function AllocateEmpty to create zero-
element instances of these classes
- Fix bugs resulting from using these zero-element versions
Further, this CL
- provides a canonical empty versions of OrderedNameDictionary
- changes the types of the canonical ordered hash table and hash set
from FixedArray to the actual subclasses
Bug: v8:7569
Change-Id: I0fe1215e7d164617afa777c8b3208a0857ab6edd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476315
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70604}
This is the first change in the process of implementing import
assertions per https://tc39.es/proposal-import-assertions/.
This CR adds support for the empty form of the AssertClause.
Also added is a --harmony-import-assertions flag to enable/disable
import assertions. For now, the feature is off by default.
The next change will enable the parser to handle a non-empty list
of AssertEntries.
Bug: v8:10958
Change-Id: I0832d89effc27225aa4430605a51690461daf7ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2468623
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70545}
This relands commit 3f4e9bbe43.
which was a reland of c4a062a958
which was a reland of 28a30c578c
which was a reland of 5d7a29c90e
The change had an issue that embedders implementing heap tracing (e.g.
Unified Heap with Blink) could be passed an uninitialized pointer if
marking happened during deserialization of an object containing such a
pointer. Because of the 0xdeadbed0 uninitialized filler value, these
embedders would then receive the value 0xdeadbed0deadbed0 as the
'pointer', and crash on dereference.
There is, however, special handling already for null pointers in heap
tracing, also for dealing with not-yet initialized values. So, we can
make the uninitialized Smi filler be 0x00000000, and that will make such
embedded fields have a nullptr representation, making them follow the
normal uninitialized value bailouts.
In addition, it relands the following dependent changes, which are
relanding unchanged and are followup performance improvements.
Relanding them in the same change should allow for cleaner reverts
should they be needed.
This relands commit 76ad3ab597
[identity-map] Change resize heuristic
This relands commit 77cc96aa48
[identity-map] Cache the calculated Hash
This relands commit bee5b996aa
[serializer] Remove Deserializer::Initialize
This relands commit c8f73f2266
[serializer] Cache instance type in PostProcessNewObject
This relands commit 4e7c99abda
[identity-map] Remove double-lookups in IdentityMap
Original change's description:
> Reland^3 "[serializer] Allocate during deserialization"
>
> This is a reland of c4a062a958
> which was a reland of 28a30c578c
> which was a reland of 5d7a29c90e
>
> Fixes TSAN errors from non-atomic writes in the deserializer. Now all
> writes are (relaxed) atomic.
>
> Original change's description:
> > Reland^2 "[serializer] Allocate during deserialization"
> >
> > This is a reland of 28a30c578c
> > which was a reland of 5d7a29c90e
> >
> > The crashes were from calling RegisterDeserializerFinished on a null
> > Isolate pointer, for a deserializer that was never initialised
> > (specifically, ReadOnlyDeserializer when ROHeap is shared).
> >
> > Original change's description:
> > > Reland "[serializer] Allocate during deserialization"
> > >
> > > This is a reland of 5d7a29c90e
> > >
> > > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > > to not check the new space addresses until it's known that this is a new
> > > space allocation. This fixes an UBSan failure during read-only space
> > > deserialization, which happens before the new space is initialized.
> > >
> > > It also fixes some issues discovered by --stress-snapshot, around
> > > serializing ThinStrings (which are now elided as part of serialization),
> > > handle counts (I bumped the maximum handle count in that check), and
> > > clearing map transitions (the map backpointer field needed a Smi
> > > uninitialized value check).
> > >
> > > Original change's description:
> > > > [serializer] Allocate during deserialization
> > > >
> > > > This patch removes the concept of reservations and a specialized
> > > > deserializer allocator, and instead makes the deserializer allocate
> > > > directly with the Heap's Allocate method.
> > > >
> > > > The major consequence of this is that the GC can now run during
> > > > deserialization, which means that:
> > > >
> > > > a) Deserialized objects are visible to the GC, and
> > > > b) Objects that the deserializer/deserialized objects point to can
> > > > move.
> > > >
> > > > Point a) is mostly not a problem due to previous work in making
> > > > deserialized objects "GC valid", i.e. making sure that they have a valid
> > > > size before any subsequent allocation/safepoint. We now additionally
> > > > have to initialize the allocated space with a valid tagged value -- this
> > > > is a magic Smi value to keep "uninitialized" checks simple.
> > > >
> > > > Point b) is solved by Handlifying the deserializer. This involves
> > > > changing any vectors of objects into vectors of Handles, and any object
> > > > keyed map into an IdentityMap (we can't use Handles as keys because
> > > > the object's address is no longer a stable hash).
> > > >
> > > > Back-references can no longer be direct chunk offsets, so instead the
> > > > deserializer stores a Handle to each deserialized object, and the
> > > > backreference is an index into this handle array. This encoding could
> > > > be optimized in the future with e.g. a second pass over the serialized
> > > > array which emits a different bytecode for objects that are and aren't
> > > > back-referenced.
> > > >
> > > > Additionally, the slot-walk over objects to initialize them can no
> > > > longer use absolute slot offsets, as again an object may move and its
> > > > slot address would become invalid. Now, slots are walked as relative
> > > > offsets to a Handle to the object, or as absolute slots for the case of
> > > > root pointers. A concept of "slot accessor" is introduced to share the
> > > > code between these two modes, and writing the slot (including write
> > > > barriers) is abstracted into this accessor.
> > > >
> > > > Finally, the Code body walk is modified to deserialize all objects
> > > > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > > > during a RelocInfo walk.
> > > >
> > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > > > size rather than byte size -- the size is expected to be tagged-aligned
> > > > anyway, so now we get an extra few bits in the size encoding.
> > > >
> > > > Bug: chromium:1075999
> > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#70229}
Bug: chromium:1075999
Change-Id: Ib514a4ef16bd02bfb60d046ecbf8fae1ead64a98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452689
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70366}
This reverts commit 3f4e9bbe43, along
with the following dependent changes (reverted to make this a clean revert):
76ad3ab597 [identity-map] Change resize heuristic
77cc96aa48 [identity-map] Cache the calculated Hash
bee5b996aa [serializer] Remove Deserializer::Initialize
c8f73f2266 [serializer] Cache instance type in PostProcessNewObject
4e7c99abda [identity-map] Remove double-lookups in IdentityMap
Reason for revert: major crash spike on Canary (https://crbug.com/1135027)
Original change's description:
> Reland^3 "[serializer] Allocate during deserialization"
>
> This is a reland of c4a062a958
> which was a reland of 28a30c578c
> which was a reland of 5d7a29c90e
>
> Fixes TSAN errors from non-atomic writes in the deserializer. Now all
> writes are (relaxed) atomic.
>
> Original change's description:
> > Reland^2 "[serializer] Allocate during deserialization"
> >
> > This is a reland of 28a30c578c
> > which was a reland of 5d7a29c90e
> >
> > The crashes were from calling RegisterDeserializerFinished on a null
> > Isolate pointer, for a deserializer that was never initialised
> > (specifically, ReadOnlyDeserializer when ROHeap is shared).
> >
> > Original change's description:
> > > Reland "[serializer] Allocate during deserialization"
> > >
> > > This is a reland of 5d7a29c90e
> > >
> > > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > > to not check the new space addresses until it's known that this is a new
> > > space allocation. This fixes an UBSan failure during read-only space
> > > deserialization, which happens before the new space is initialized.
> > >
> > > It also fixes some issues discovered by --stress-snapshot, around
> > > serializing ThinStrings (which are now elided as part of serialization),
> > > handle counts (I bumped the maximum handle count in that check), and
> > > clearing map transitions (the map backpointer field needed a Smi
> > > uninitialized value check).
> > >
> > > Original change's description:
> > > > [serializer] Allocate during deserialization
> > > >
> > > > This patch removes the concept of reservations and a specialized
> > > > deserializer allocator, and instead makes the deserializer allocate
> > > > directly with the Heap's Allocate method.
> > > >
> > > > The major consequence of this is that the GC can now run during
> > > > deserialization, which means that:
> > > >
> > > > a) Deserialized objects are visible to the GC, and
> > > > b) Objects that the deserializer/deserialized objects point to can
> > > > move.
> > > >
> > > > Point a) is mostly not a problem due to previous work in making
> > > > deserialized objects "GC valid", i.e. making sure that they have a valid
> > > > size before any subsequent allocation/safepoint. We now additionally
> > > > have to initialize the allocated space with a valid tagged value -- this
> > > > is a magic Smi value to keep "uninitialized" checks simple.
> > > >
> > > > Point b) is solved by Handlifying the deserializer. This involves
> > > > changing any vectors of objects into vectors of Handles, and any object
> > > > keyed map into an IdentityMap (we can't use Handles as keys because
> > > > the object's address is no longer a stable hash).
> > > >
> > > > Back-references can no longer be direct chunk offsets, so instead the
> > > > deserializer stores a Handle to each deserialized object, and the
> > > > backreference is an index into this handle array. This encoding could
> > > > be optimized in the future with e.g. a second pass over the serialized
> > > > array which emits a different bytecode for objects that are and aren't
> > > > back-referenced.
> > > >
> > > > Additionally, the slot-walk over objects to initialize them can no
> > > > longer use absolute slot offsets, as again an object may move and its
> > > > slot address would become invalid. Now, slots are walked as relative
> > > > offsets to a Handle to the object, or as absolute slots for the case of
> > > > root pointers. A concept of "slot accessor" is introduced to share the
> > > > code between these two modes, and writing the slot (including write
> > > > barriers) is abstracted into this accessor.
> > > >
> > > > Finally, the Code body walk is modified to deserialize all objects
> > > > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > > > during a RelocInfo walk.
> > > >
> > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > > > size rather than byte size -- the size is expected to be tagged-aligned
> > > > anyway, so now we get an extra few bits in the size encoding.
> > > >
> > > > Bug: chromium:1075999
> > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#70229}
> > >
> > > Bug: chromium:1075999
> > > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#70267}
> >
> > Tbr: jgruber@chromium.org,ulan@chromium.org
> > Bug: chromium:1075999
> > Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70279}
>
> Tbr: jgruber@chromium.org,ulan@chromium.org
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
> Bug: chromium:1075999
> Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70288}
TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org
Bug: chromium:1075999, chromium:1135027
Change-Id: I5d0d9e49c0302d94ff7291834f5f18e7a0839eb7
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2451030
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70328}
