In case of no arguments adaptor frame, we massage the arguments in InvokePrologue pushing undefined objects if the actual argument count is below the parameter count. This CL adds a stack overflow check before pushing these undefined objects to the stack.
Change-Id: I2a88bf6fdfd17958f6f6884143a67d50ea842fd2
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491039
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70927}
This adds a first simple version of the inspector fuzzer, which is a
stripped-down version of the inspector-test executable. The fuzzer
generates inputs which are compatible with inspector-test.
There are still memory leaks, and the fuzzer will probably run into
timeouts most of the time. Both of this will be addressed in follow-ups.
R=szuend@chromium.org, machenbach@chromium.org
Bug: chromium:1142437
Change-Id: I4d13da460f571d791a3642b0705a1f07b442c11b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505722
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70922}
This also extracts the {FrontendChannelImpl}, the {SetTimeoutTask}, and
the {SetTimeoutExtension} for reuse by the inspector fuzzer.
R=szuend@chromium.org
Bug: chromium:1142437
Change-Id: I75e49d6fbb4b801ace1ffc9cac963d6b83c52f36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505717
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70909}
IsCompleted is backwards. For a more consistent api, the function is
renamed IsActive and logic is flipped.
Following up on https://chromium-review.googlesource.com/c/v8/v8/+/2461840
The intend is to make the distinction between IsActive and IsValid obvious.
Change-Id: Iaf00b9f6ffa8f1efe93ae29f09899737ef20f04d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2510969
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70901}
- Provide GetRealStackAddressForSlot that deals with ASAN fake stacks
properly, also accounting for the fact that ASAN gets its real stack
address in a nested call.
- Fix cppgc on-stack getter.
- Reuse platform routines in global handles.
Bug: chromium:1139914, chromium:1056170
Change-Id: If11a40d543b33edcea220bb70f170ac018e15053
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509594
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70899}
We previously assumed that a fake stack should be mapped back to a
real stack based on fake-stack offsets. This is not correct: Fake and
real stack are disjoint and both contain the corresponding slot
values.
For global handles this means that on-stack handles must be registered
using their real stack frame base to be able to purge them
occasionally based on the current stack address.
When dealing with a slot though, the GC can just dereference the slot
for a value, indeppendent of whether the slot is in a fake or real
frame.
Drive-by: Fix tests that do not want stack handles by creating
handles on heap.
Change-Id: I2c86c8e047bd0d48c24c2642b2b4dba284a93909
Bug: chromium:1139914
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507720
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70897}
Building these objects takes a lot of time and memory for realistic
applications and exposing them via the Scope view in DevTools isn't
practical either. We have a replacement in the Console now, and if
this needs more exposure we can think about other, more scalable
ways with better UX.
Fixed: v8:10986
Bug: chromium:1141781
Change-Id: I6177d63a987749889a9880cf0738031191eb5705
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507696
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70894}
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}
When searching for a target map during map update, attempt to
update field representations in-place to the more general
representation, where possible.
Bug: chromium:1143772
Change-Id: I6a43c94910a1d2d8f8b0ad89048f94b51461f76c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507715
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70887}
This allows GC to go slightly over the max heap limit in order to give
NearHeapLimitCallback a chance to run and increase the limit.
Based on the suggestion by Kenton Varda.
Change-Id: I9c084b5a4c8fb7b9ce331b565958391c1be56add
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505724
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70884}
Fix super calls so that arguments are evaluated before the
super constructor is checked to be in fact a constructor.
A new bytecode is introduced to split the IsConstructor check
out from the current GetSuperConstructor bytecode.
Bug: v8:10111
Change-Id: I3af99e32a34d99493806bb01b547d6f671cdc9de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493077
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70881}
This CL changes the "small" versions of ordered hash tables, like
SmallOrderedNameDictionary and the corresponding handlers, like
OrderedNameDictionaryHandler, to use InternalIndex rather than int
as the type used for indices.
This is part of an effort to make the interfaces of the
ordered and unordered name dictionaries more similar.
Bug: v8:7569
Change-Id: I3b6fe79dfd3c6743f58a04cfe82798fe2ef09e19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505720
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70876}
For-in now collect feedback as well, the test passes.
Tbr: neis@chromium.org
Bug: v8:8888
Change-Id: I4e2ae41b60aa43132a24f001dc4de460a270a1a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505766
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70874}
This changes the ordered hash data structures in ordered-hash-table.h to
use InternalIndex as the type used for indices, rather than int.
This makes the interface more similar to the (unordered) hash tables in
dictionary.h and hash-table.h
Bug: v8:7569
Change-Id: I2389b0c7d103eb7c33c5ed620b16eb198109b54c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2503949
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70873}
Inside of LoopPeeler::PeelInnerLoopsOfTree we call the typer, which
inspects heap objects, so we need to unpark the local heap.
Reverted in https://chromium-review.googlesource.com/c/v8/v8/+/2502333
Original change's description:
> [compiler] Replace Symbol with direct reads
>
> Bug: v8:7790
> Change-Id: I49120a6349777fd992a97d697940e79b2e71dbd1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400988
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69812}
Bug: v8:7790, chromium:1137594
Change-Id: I8539175002e19b04b84009eb6b2cc5ced4ee53c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502339
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70872}
The speedup in https://crrev.com/c/2504853 left out checking the array
lengths, this adds that check.
Bug: v8:7783
Change-Id: I8de01fa2dff3e051246ee3a268cdce2128ad16ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505252
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70869}
This is a reland of e68285e21d
Failing wasm tests seemed to recover on their own.
Original change's description:
> cppgc-js: heap snapshot: Add logic for querying detachedness
>
> Adds infrastructure to allow embedders specifying a detachedness state
> that is queried when encountering an object with a TraceReference that
> has a non-zero wrapper class id set.
>
> Change-Id: Ie7f2f253544ee25a25565eb08d82e9df5f0a74d2
> Bug: chromium:1056170
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502345
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70841}
Bug: chromium:1056170
Change-Id: I293a9d38f841b4d0faa4af7408bb57544f11d566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505713
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70867}
This reverts commit 1eecdf3450.
Reason for revert: unacceptable binary size increase (+65.5 KiB)
We’ll reland once we implement a more efficient way to store the
sequences.
Original change's description:
> Update RegExp sequence property support
>
> This patch aligns --harmony-regexp-sequence with the latest version of
> the corresponding TC39 and Unicode proposals.
>
> The list of supported properties has been changed:
>
> - https://github.com/tc39/proposal-regexp-unicode-sequence-properties#proposed-solution
> - https://unicode.org/reports/tr18/#Full_Properties
>
> Furthermore, the Unicode data now uses Unicode v13.0.0 instead of v12.0.0.
>
> Bug: v8:7467
> Change-Id: I1ac386d87af68d68e84e919cb5ffc1313443844a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497163
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Mathias Bynens <mathias@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70752}
TBR=yangguo@chromium.org,jgruber@chromium.org,mathias@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7467
Change-Id: I6721f4862827dc686d96d79498a1e8fdae4481d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505758
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70866}
Test was skipped because the generated test contains multi-byte opcode,
and wasn't correct. Fix up the test with the correct encoding. The
fuzzer now generates multi-byte opcodes correctly, and so shouldn't be
an issue.
Bug: v8:10486
Change-Id: I1f5ad7d456320a30da6c553f65fdca0fc86a291a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505238
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70864}
PPC has a larger page size than other platforms, so increase the page
size in the test to account for this.
Change-Id: I392064e9ef3f87c5bddb7763b35661aee5b4669d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502330
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70857}
This is a reland of 44f46defcf with a
fix for failures with --turbonci_as_mid_tier
Original change's description:
> [turboprop] Pass required parameters as value inputs to TierUpCheck node
>
> TierUpCheck node tail calls interpreter entry trampoline when additional
> processing is needed for tiering up. Calling IET requires target,
> new_target, input count and context as parameters. Earlier these were
> created as parameter nodes in effect-control-linearizer. This causes
> problems with Turboprop since TurboProp doesn't use the second scheduler
> and cannot reschedule these nodes to the start block. We should instead
> create these parameter nodes in bytecode-graph-builder and pass them
> as value inputs to TierUpCheck node.
>
> Bug: v8:9684
> Change-Id: Icfe5a33b4e628d5a3ba9a3121b2b0746be6aed5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498695
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70790}
Bug: v8:9684
Change-Id: Ic1a7d39aab0a599d0dd421f237e7bc640fcd6eb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504258
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70856}
This CL splits the class definitions per .tq file, to realize the
following relationship:
A class defined in src/objects/foo.tq has a C++ definition in
src/objects/foo.h. Torque then generates:
- torque-generated/src/objects/foo-tq.inc
An include file (no proper header) to be included in src/objects/foo.h
containing the Torque-generated C++ class definition.
- torque-generated/src/objects/foo-tq-inl.inc
An include file (no proper header) to be included in
src/objects/foo-inl.h containing inline function definitions.
- torque-generated/src/objects/foo-tq.cc
A source file including src/objects/foo-inl.h that contains non-inline
function definitions.
Advantages of this approach:
- Avoid big monolithic headers and preserve the work that went into
splitting objects.h
- Moving a definition to Torque keeps everything in the same place
from a C++ viewpoint, including a fully Torque-generated C++ class
definition.
- The Torque-generated include files do not need to be independent
headers, necessary includes or forward declarations can just be added
to the headers that include them.
Drive-by changes:
A bunch of definitions and files had to be moved or created to realize
a consistent 1:1 relationship between .tq files and C++ headers.
Bug: v8:7793
TBR: hpayer@chromium.org
Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70853}
This simplifies the logic since we can guarantee to have a
Handle<String>. The removed constructor was only used in tests.
Change-Id: I13519e474fe92892e9e8a39802d84cfab2c5b5ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505711
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70849}
Disable the BackgroundCompileTask and CompilerDispatcher unittests when
--finalize-streaming-on-background is enabled. The inner function API to
concurrent compilation doesn't yet support off-thread finalization, so
these tests break under that configuration.
Bug: chromium:1011762
Change-Id: If8d8d8e814161668e12f309e8d69ef8e8a29ab4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502329
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70846}
This reverts commit e68285e21d.
Reason for revert: ASAN test failing:
https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20ASAN/29838?
Original change's description:
> cppgc-js: heap snapshot: Add logic for querying detachedness
>
> Adds infrastructure to allow embedders specifying a detachedness state
> that is queried when encountering an object with a TraceReference that
> has a non-zero wrapper class id set.
>
> Change-Id: Ie7f2f253544ee25a25565eb08d82e9df5f0a74d2
> Bug: chromium:1056170
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502345
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70841}
TBR=ulan@chromium.org,mlippautz@chromium.org,omerkatz@chromium.org
Change-Id: Ic13337b9c5b336a81efa5f2672f5a501084b5326
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505613
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70843}
https://github.com/tc39/proposal-dynamic-code-brand-checks
An experimental implementation of the TC39 "Dynamic Code Brand Checks". This
implementation sticks an API-only symbol on each "code kind" object, which
is more flexible, but costs memory for each instance.
Bug: chromium:1096017
Change-Id: Idfeca035c61204ca0cea8ec735fdfa40a49d85e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339618
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70842}
Adds infrastructure to allow embedders specifying a detachedness state
that is queried when encountering an object with a TraceReference that
has a non-zero wrapper class id set.
Change-Id: Ie7f2f253544ee25a25565eb08d82e9df5f0a74d2
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502345
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70841}
The flag has been enabled by default for two version now, so it is time
to remove it.
R=binji@chromium.org
Bug: v8:9921
Change-Id: I833e04a3f9d238e7bcf27e93148c9492776af3c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402034
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70838}
This is a reland of d7ece57e20 with
a fix to failures on NumFuzz.
Original change's description:
> [turboprop] Add a slot for optimization marker in feedback vector
>
> Optimization marker and the optimized code used to share the same slot
> in the feedback vector as they were mutually exclusive. With turboprop
> we would want to mark the function for tier up to Turbofan while holding
> the optimized code for Turboprop. So this cl uses the existing padding
> field to hold the optimization marker instead.
>
> As a driveby, removes unused JSFunction::ClearOptimizedCodeSlot function
> and fixes a minor bug in Runtime_GetOptimizationStatus.
>
> Bug: v8:9684
> Change-Id: I18c551a69648a0837d16c5453d023c0b295b1521
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467836
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70789}
Bug: v8:9684
Change-Id: Ie6aa3c061a852bb047b5921e4e747d43505568e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502871
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70834}
The value of a node was accessed without prior HasValue check. With
WebAssembly this node is not guaranteed to be a value.
R=mslekova@chromium.org
Change-Id: I62170183f3940a04b0550dfbb78cb49d2f5d7f72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504250
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70833}
We made array-concat run faster in https://crrev.com/c/2504853.
Bug: v8:7783
Change-Id: Iabefb58f92e24ffa4e0589a7c8b9e2b3e12c6e47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504859
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70831}
The immediate might not be 2 bytes from start of instruction, because
the opcode is leb encoded.
Bug: chromium:1143053
Change-Id: I3c514e771419470ce34e02d4faa24e9e59676aa6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504852
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70828}
Currently MockPlatformForUnmapper has shorter lifetime than the isolate that
uses it. This leads to use-after-free races in concurrent tasks that fetch
the mock platform just before it is freed.
This CL ensures that MockPlatformForUnmapper is valid throughout the whole
lifetime of the isolate
Change-Id: I94a658bf7eb70d924a19522dab09744f21782972
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502809
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70826}
This test creates an array that is 500000 elements long. Calling
assertEquals on this with another array is really slow, especially on
simulator runs. Most of this array is empty, only the first few elements
and last few elements contain meaningful items, so we check those
specific indices.
On a local run this test goes from ~250s (--jitless) or ~111s to <1s.
out/arm64.build/d8 --test test/mjsunit/mjsunit.js
test/mjsunit/array-concat.js --random-seed=1 --nohard-abort
--testing-d8-test-runner [--jitless]
(using --jitless makes the test even slower)
Bug: v8:7783
Change-Id: I660d3a9f1b3fe3afaa58fce28f493641059ba226
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504853
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70825}
This CL extracts some functionality from inspector-test.cc to be reused
by the inspector fuzzer.
It also puts all functions in the v8::internal namespace, and adds
separate functions in v8::internal to be called by ::main such that
we have direct access to the full namespace there.
R=szuend@chromium.org
Bug: chromium:1142437
Change-Id: I671317822bdc1c721334469811893affcc460f8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2501847
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70821}
This is a reland of df34fb9534
Original change's description:
> [wasm-simd] Add more test cases for load lane
>
> Test load lane using memarg offset immediate, and also test all
> supported alignments.
>
> Bug: v8:10975
> Change-Id: Iac7e9f7e335bd86528a8723b04df97a17d7a7f66
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2500928
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70816}
TBR=bbudge@chromium.org
Bug: v8:10975
Change-Id: I286776b351ecd3c78d56bec20c02a3ba283213df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504851
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70820}
This reverts commit df34fb9534.
Reason for revert: Broke msvc compile https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/15566
Original change's description:
> [wasm-simd] Add more test cases for load lane
>
> Test load lane using memarg offset immediate, and also test all
> supported alignments.
>
> Bug: v8:10975
> Change-Id: Iac7e9f7e335bd86528a8723b04df97a17d7a7f66
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2500928
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70816}
TBR=bbudge@chromium.org,zhin@chromium.org
Change-Id: Ia80d167846dac99070e6e9d280dd4ea53455af30
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10975
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504850
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70817}
Test load lane using memarg offset immediate, and also test all
supported alignments.
Bug: v8:10975
Change-Id: Iac7e9f7e335bd86528a8723b04df97a17d7a7f66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2500928
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70816}
And remove all ifdefs guarding the tests.
Bug: v8:11038
Change-Id: I91487a4bd60b6f2e327d1c2348289e446d6e93d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2501967
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70811}
This is a reland of dde9376860
Original change's description:
> Add int64_t min and max to value helpers for test
>
> And also fix up a truncate float to int test that was using
> int list as input instead of a float list.
>
> Change-Id: I544e38b2d212f8d11dfb5758db4fe6b283acae0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419654
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70774}
Change-Id: Id196ea40eaf616d784d644346b912f1561fd97a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2500926
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70810}
- Created status enum with statuses kStarted, kAlreadyStarted and
kErrorTooManyProfilers, returning when StartProfiling is invoked
- Tests spin up one profiler, check kStarted returned; spin up
another with same name, check kAlreadyStarted returned; Spin up 99
more profilers (100 total), check each returning kStarted, and
one more, expecting 101st to return kErrorTooManyProfilers
R=acomminos@fb.com, petermarshall@chromium.org, ulan@chromium.org
Change-Id: I64e2e6396775f90f9f49f75331a075a47efa7fca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2486240
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70808}
Wrapper nodes are merged into their corresponding C++ object nodes
when the reference between C++ and JS object has a wrapper class id
set.
Instead of iterating all global handles and checking for those with
class ids, the new algorithm discovers them while iterating C++
objects.
Note: Additional wrapper nodes, e.g., those from isolated worlds in
Blink are not merged.
Bug: chromium:1056170
Change-Id: I6dff8992e41d7a1a2c3b99a115a53df6b6fbb64c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2499661
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70804}
This reverts commit d7ece57e20.
Reason for revert: failures on NumFuzz
https://ci.chromium.org/p/v8/builders/ci/V8%20NumFuzz%20-%20debug/11818?
Original change's description:
> [turboprop] Add a slot for optimization marker in feedback vector
>
> Optimization marker and the optimized code used to share the same slot
> in the feedback vector as they were mutually exclusive. With turboprop
> we would want to mark the function for tier up to Turbofan while holding
> the optimized code for Turboprop. So this cl uses the existing padding
> field to hold the optimization marker instead.
>
> As a driveby, removes unused JSFunction::ClearOptimizedCodeSlot function
> and fixes a minor bug in Runtime_GetOptimizationStatus.
>
> Bug: v8:9684
> Change-Id: I18c551a69648a0837d16c5453d023c0b295b1521
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467836
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70789}
TBR=rmcilroy@chromium.org,mythria@chromium.org,jgruber@chromium.org
Change-Id: Ia9894fef713a522b9c3d349bef4abcde3e1e1832
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9684
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502870
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70803}
cppgc must support the same feature set as the existing unified heap
system, which requires support for wrapper-specific handling (drop on
Scavenge, merge in snapshot).
Replace JSMember by TracedReference to support IsRootForNonTracingGC()
optimizations out of the box. cppgc support for wrapper/wrappable
pairs will be added as followup.
Change-Id: I3c6eff2b8dce5b71b04b2bd75182eb8672079a64
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498685
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70801}
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}
The number of available double registers depends on supported CPU
features on arm. Any code that applies to all double regs must be
extra-careful to correctly handle either 16 or 32 registers.
This was not the case for deopt entries, which were recently moved
from a runtime-generated code stub to a mksnapshot-time-generated
builtin.
This CL fixes the issue by inspecting the runtime value of cpu
features and acting on it.
Bug: v8:8661,chromium:1142158
Change-Id: I6f4d2e6ee6a80217b9110194b8e1edbe8670d8d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498686
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70796}
We kept the CodeMap filled with entries between profiles, even in
kLazyLogging mode which will re-fill the CodeMap when profiling starts
again. See the bug for more details.
This fix manually clears the CodeMap after the last profile is deleted.
We already call DisableLogging() when the last profile is stopped. At
this point we still need the CodeMap alive because the profile object
we expose via the API is backed by the CodeEntry objects in the CodeMap.
Once the last profile is deleted though, we can empty the CodeMap.
There is still another bug, which is that we never delete CodeEntry
objects for deleted code, as there are no CodeDeleteEvents from the GC.
We will work on that separately, but this fix should stop those leaks
accumulating between profiles as we wipe the CodeMap entirely between
profiles (at least for kLazyLogging mode). kEagerLogging mode still has
this problem and will only be fixed by introducing CodeDelete events or
similar.
Bug: v8:11051
Change-Id: Iab9570747d17c657e6e318d434f935af8047d05f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491033
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70792}
Optimization marker and the optimized code used to share the same slot
in the feedback vector as they were mutually exclusive. With turboprop
we would want to mark the function for tier up to Turbofan while holding
the optimized code for Turboprop. So this cl uses the existing padding
field to hold the optimization marker instead.
As a driveby, removes unused JSFunction::ClearOptimizedCodeSlot function
and fixes a minor bug in Runtime_GetOptimizationStatus.
Bug: v8:9684
Change-Id: I18c551a69648a0837d16c5453d023c0b295b1521
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467836
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70789}
This CL makes the metadata offsets stored in Code headers
relative to the start of the metadata section (instead of to
the start of the instructions section).
In a follow-up, metadata for embedded builtins will be moved
from the .text section (with r-x or --x permissions) to the
.rodata section (with r-- permissions).
Drive-by: Simplify invariants around section alignment. A
new invariant is that the end of the instruction section is
aligned to Code::kMetadataAlignment.
Drive-by: Ensure trampoline Code objects contain no metadata
(metadata offsets all refer to the off-heap metadata section).
Tbr: dinfuehr@chromium.org
Bug: v8:11036
Change-Id: Idd0980913bbde9d3d1946b558e3ca58ec6356fcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491036
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70788}
The crash scenario is as follows:
1) Add a getter for 'then' to the Object prototype that is
considered side-effecting.
2) Evaluate a simple string using 'REPL' mode with side-effect checks
enabled.
Note: REPL mode is not strictly necessary, but it causes a 'then'
lookup as the evaluation result is not a promise.
3) Calling the 'then' getter causes a termination exception, due
to the side-effect check. JSPromise::Resolve then tries to
put the termination exception as the reject reason, which causes
a CHECK failure.
The solution is to check for termination in the "abrupt completion"
case when 'then' was retrieved.
Bug: chromium:1140845
Change-Id: I72b644cd49355cea40f599fcbe80264e99ed7bd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2501283
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70785}
Implement these two instructions on arm.
Bug: v8:11038
Change-Id: I23d9c7291f60e29415cfbebced1bff323fd2465a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485250
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70779}
This reverts commit dde9376860.
Reason for revert: ubsan failures https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/13518
Original change's description:
> Add int64_t min and max to value helpers for test
>
> And also fix up a truncate float to int test that was using
> int list as input instead of a float list.
>
> Change-Id: I544e38b2d212f8d11dfb5758db4fe6b283acae0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419654
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70774}
TBR=clemensb@chromium.org,zhin@chromium.org
Change-Id: If0faa8be8c55715a529dfe777c0ad9819105fc5b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2500925
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70777}
The SpecialValue field used in the disassembler covers too wide a range,
this causes some duplication in the disassembler of instructions like
mov, since the SpecialValue includes a bit used for the immediate.
Attempt to refactor and follow the decoding guide given in the
architecture manual [0], F4.1 A32 instruction set encoding, with the
eventual goal for removing the duplicated instruction disassembly.
[0] ARM DDI 0487F.b ARMv8 A32 instruction set
Bug: v8:10933
Change-Id: Iddf4df317f9a5b29be2544ad2f9f93180e9bcdfc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497395
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70775}
And also fix up a truncate float to int test that was using
int list as input instead of a float list.
Change-Id: I544e38b2d212f8d11dfb5758db4fe6b283acae0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419654
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70774}
This relands commit 61b56d1650
The fix is to capture variables used in the lambda.
Original change's description:
> [wasm-simd] Add more tests for v128 load zero
>
> Add tests for all valid alignments, and using memarg immediate offset
> instead of i32 index.
>
> Also randomize the memory to help catch cases where we are loading
more
> than we should, and accidentally get correct values with zero-ed
memory.
>
> Bug: v8:10713
> Change-Id: I443c2799ba0d539bf23c63760c08e18c4d36607f
> Reviewed-on:
https://chromium-review.googlesource.com/c/v8/v8/+/2487880
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70693}
Bug: v8:10713
Change-Id: Ib8fa58c6600d85a37fc0b6647ddbdb991f3b1c04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497382
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70769}
Make the array elements in msunit/regress/regress-542823 larger, so that
it takes fewer of them to force the joined string to go into large
object space. Also, set the array's size dynamically based on the
maximum non-large object size, rather than having a fixed magic "large
enough" size, and verify that the resulting joined string is indeed in
LO space.
This reduces the runtime of this test under slow_path and gc-stress from
minutes to seconds.
Bug: v8:11060
Change-Id: I51d960b6a3e052199f50c1a6ba6fbce1b6d1ae38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498689
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70762}
This is a reland of bcb0a7c5c5.
Data races detected by TSan are fixed by using (relaxed) atomic
updates.
Original change's description:
> [wasm] Disallow late enabling of trap handlers
>
> It's dangerous if trap handlers are enabled after we already used the
> information whether they are enabled or not.
> This CL checks for such misbehaviour by remembering whether
> {IsTrapHandlerEnabled} was already called, and disallowing
> {EnableTrapHandler} afterwards. Also, calling {EnableTrapHandler}
> multiple times is disallowed now.
>
> The trap handler tests are changed to only enable trap handlers once,
> and to do that before allocating wasm memory or generating code.
>
> R=ahaas@chromium.org
>
> Bug: v8:11017
> Change-Id: Ib2256bb8435efd914c12769cedd4a0051052aeef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2494935
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70750}
Bug: v8:11017
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: I24299c433ffa3ce31e2aac12134dc03f30609da2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498683
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70761}
For deserialized modules the compilation state was not set to
kFinishedTopTierCompilation and co. A consequence was that code that
required top tier compilation to be finished to block indefinitely.
With this CL the compilation state is initialized properly.
I tested this CL locally with the regression test mentioned in the bug
tracker issue. However, this regression test required to run this test
twice in separate processes. It would be possible to write a regression
test for this that runs on the bots, but I considered it not worth it.
R=clemensb@chromium.org
Bug: v8:11024
Change-Id: Ib4e75eae03fab13a3ff013118fc1f33a1278b33f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2494930
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70757}
msunit/regress/regress-542823 is intended to test large object
allocation in Array.prototype.join, but to do so it has a pretty
inefficient way of first building a large array.
Speed-up this test by using Array.prototype.fill, call .join directly,
and make the whole thing an IIFE to avoid global loads.
Bug: v8:11060
Change-Id: I5906bcb6c65b10ec830b026cf1f24acb6d5e1aaf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498681
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70755}
The test creates an import error that references the current Script for
reporting the error location back to the embedder.
- This is not supported by the serializer
- We don't expect parse/import errors for serialization
Bug: v8:6513
Change-Id: Idf98e7ae189e8ffeaa478e5118a7b3f2d2c06047
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497171
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70754}
Due to the previous change to that function, we can end up with
set (non-null) fields even when the overall serialized_ field is
unset. This can cause DCHECK failures (I don't think it's otherwise
observable).
Bug: chromium:1142240,v8:7790
Change-Id: I2711fae8a73438277caf7aa539f24d628b03153c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497170
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70753}
This reverts commit bcb0a7c5c5.
Reason for revert: TSAN failure (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33868)
Original change's description:
> [wasm] Disallow late enabling of trap handlers
>
> It's dangerous if trap handlers are enabled after we already used the
> information whether they are enabled or not.
> This CL checks for such misbehaviour by remembering whether
> {IsTrapHandlerEnabled} was already called, and disallowing
> {EnableTrapHandler} afterwards. Also, calling {EnableTrapHandler}
> multiple times is disallowed now.
>
> The trap handler tests are changed to only enable trap handlers once,
> and to do that before allocating wasm memory or generating code.
>
> R=ahaas@chromium.org
>
> Bug: v8:11017
> Change-Id: Ib2256bb8435efd914c12769cedd4a0051052aeef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2494935
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70750}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I1d93dcb399e2a0b5b0543aa60d34087317c01cb3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11017
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497176
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70751}
It's dangerous if trap handlers are enabled after we already used the
information whether they are enabled or not.
This CL checks for such misbehaviour by remembering whether
{IsTrapHandlerEnabled} was already called, and disallowing
{EnableTrapHandler} afterwards. Also, calling {EnableTrapHandler}
multiple times is disallowed now.
The trap handler tests are changed to only enable trap handlers once,
and to do that before allocating wasm memory or generating code.
R=ahaas@chromium.org
Bug: v8:11017
Change-Id: Ib2256bb8435efd914c12769cedd4a0051052aeef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2494935
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70750}
This is a reland of b66993bcfb
Nothing changed in the reland, the original CL was not the
culprit for win32 failures. They started earlier, at
https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/29444
Original change's description:
> [code] Separate instruction and metadata areas
>
> In this CL, Code object layout changes s.t. the instruction
> area is distinct / non-overlapping from the metadata area.
>
> On-heap Code objects now have a variable-size `body` area,
> containing distinct-but-adjacent `instruction` and `metadata`
> areas.
>
> Off-heap code (= embedded builtins) currently have the same,
> but in the future the metadata area will move elsewhere and
> no longer be adjacent to instructions.
>
> To implement this, the main changes are:
>
> - The Code object header now contains instruction and metadata
> sizes, and no longer contains the safepoint table offset
> (it's implicitly the first table of the metadata section).
> - The embedded metadata table contains information about both
> instruction and metadata areas.
>
> I've also added assertions in spots that currently rely on a
> contiguous body area.
>
> Bug: v8:11036
> Change-Id: I940f0c70c07ad511dafd2d2c3e337de8c92cd4b9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491025
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70743}
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Tbr: leszeks@chromium.org, clemensb@chromium.org, dinfuehr@chromium.org
Bug: v8:11036
Change-Id: I238562d7e25cf28cc689856ee8b17f25627aaee7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497162
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70747}
This reverts commit b66993bcfb.
Reason for revert: Broke v8 win32 https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/29454?
Original change's description:
> [code] Separate instruction and metadata areas
>
> In this CL, Code object layout changes s.t. the instruction
> area is distinct / non-overlapping from the metadata area.
>
> On-heap Code objects now have a variable-size `body` area,
> containing distinct-but-adjacent `instruction` and `metadata`
> areas.
>
> Off-heap code (= embedded builtins) currently have the same,
> but in the future the metadata area will move elsewhere and
> no longer be adjacent to instructions.
>
> To implement this, the main changes are:
>
> - The Code object header now contains instruction and metadata
> sizes, and no longer contains the safepoint table offset
> (it's implicitly the first table of the metadata section).
> - The embedded metadata table contains information about both
> instruction and metadata areas.
>
> I've also added assertions in spots that currently rely on a
> contiguous body area.
>
> Bug: v8:11036
> Change-Id: I940f0c70c07ad511dafd2d2c3e337de8c92cd4b9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491025
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70743}
TBR=jgruber@chromium.org,leszeks@chromium.org,clemensb@chromium.org,dinfuehr@chromium.org
Change-Id: Ia52ac609a47b8a2038a2511f0af8526ebdfe4719
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11036
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497381
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70744}
In this CL, Code object layout changes s.t. the instruction
area is distinct / non-overlapping from the metadata area.
On-heap Code objects now have a variable-size `body` area,
containing distinct-but-adjacent `instruction` and `metadata`
areas.
Off-heap code (= embedded builtins) currently have the same,
but in the future the metadata area will move elsewhere and
no longer be adjacent to instructions.
To implement this, the main changes are:
- The Code object header now contains instruction and metadata
sizes, and no longer contains the safepoint table offset
(it's implicitly the first table of the metadata section).
- The embedded metadata table contains information about both
instruction and metadata areas.
I've also added assertions in spots that currently rely on a
contiguous body area.
Bug: v8:11036
Change-Id: I940f0c70c07ad511dafd2d2c3e337de8c92cd4b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491025
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70743}
This is a reland of eb6b4ce1d8
Skip test that serializes Error which references a Script. All errors
created by ThrowAt store the current Script under the
error_script_symbol.
Original change's description:
> [runtime] Use Isolate::ThrowAt with MessageLocation
>
> Fix various missing source positions when reporting parse and compile
> errors. Namely this fixes missing source positions when having invalid
> module imports.
>
> - Use Isolate::ThrowAt with valid MessageLocation objects
> - Change public Isolate::Throw to no longer accept MessageLocation to
> avoid misues
> - Introduce private Isolate::ThrowInternal that accepts MessageLocation
>
> Bug: v8:6513
> Change-Id: I3ee633c9fff8c9d361bddb37f56e28a50c280ec1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467839
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70623}
Bug: v8:6513
Change-Id: Icba74f74178e28fbda0fd0c237eeb7bacbc33570
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487123
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70741}
The dynamic map check builtin loads the feedback vector from the
function's frame, therefore it doesn't work if we inline the
function. We don't do inlining on TurboProp so this is fine, but
it was possible to enable dynamic map checks on TurboFan which does.
This change prevents that, and also makes the dynamic map checks flag
specific to TurboProp and no longer an implication, which also allos
it to be switched on the command line independenly of --turboprop.
BUG=chromium:1141502,v8:9684
Change-Id: I365de461a6373335a45a7a154af7d4cf1c13dc2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2494928
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70737}
This is a reland of 90ea9b35cb
Original change's description:
> cppgc: Port backing store compaction.
>
> This CL ports the existing backing store compaction algorithm from
> blink. It does not attempt to improve on the existing algorithm.
>
> Currently only unified heap uses the compaction implementation. It is
> never triggered through standalone GCs.
>
> The compaction implementation resides within an internal "subtle" namespace.
>
> Bug: v8:10990
> Change-Id: I4aa781db1b711e7aafc34234c4fb142de84394d7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485228
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70714}
Bug: v8:10990
Change-Id: I527c2042a26648d058bfe4d355527cce9a3eeadc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2492331
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70736}
If trap handlers are disabled, we don't need guard regions around wasm
memories. Hence use the dynamic {trap_handler::IsTrapHandlerEnabled()}
check, instead of always reserving guard regions on all 64-bit
platforms.
This will allow to reserve pretty much arbitrarily many wasm memories if
trap handlers are disabled.
Two tests are added to test the number of memories that can be
allocated: With trap handlers, at least 50 memories should always be
possible. Without trap handlers, 10000 small memories should not be a
problem (each one is taking 64kB, so it's 640MB overall).
Drive-by: Improve tracing.
R=ahaas@chromium.org
Bug: v8:11017
Change-Id: Ic4c620f63dfbef571e64df0b3372b83a1db566ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491034
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70732}
The TryMigrateInstance should be passed the instance object to migrate,
not the map of the object. Also make the runtime function explicitly
check for JSObjects.
BUG=v8:9684
Change-Id: I03605d9f3103b618243c12ad0b63035484ef4134
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487270
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70731}
CppHeap is currently set up to always finalize with no stack.
Finalizing with actual current stack state breaks our unified heap
unittests. This is fixed by having test specify which stack state
to pass CppHeap.
Bug: chromium:1056170
Change-Id: I1a6c3870abbdf56917c20c6a75580b6c516d828c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2494924
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70729}
The test was not flaky. Instead it seems compiiler optimizations discarded
of the test-allocated object such that stack scanning could no longer find it.
Bug: v8:11052
Change-Id: Ie8018ccecb03b22e6c4f2dada3e6663b04c551fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493160
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70722}
The register that holds the {new_value} for the AtomicCompareExchange8U
has to be a byte register on ia32. There was code to guarantee that, but
after that code there was code that frees the {eax} register, and that
code moved the {new_value} to a different register again. With this CL
we first free {eax}, and then find a byte register for the {new_value}.
R=clemensb@chromium.org
Bug: chromium:1140549
Change-Id: I1679f3f9ab26c5416ea251c7925366ff43336d85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491031
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70721}
This reverts commit 90ea9b35cb.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20-%20debug/31274?
Original change's description:
> cppgc: Port backing store compaction.
>
> This CL ports the existing backing store compaction algorithm from
> blink. It does not attempt to improve on the existing algorithm.
>
> Currently only unified heap uses the compaction implementation. It is
> never triggered through standalone GCs.
>
> The compaction implementation resides within an internal "subtle" namespace.
>
> Bug: v8:10990
> Change-Id: I4aa781db1b711e7aafc34234c4fb142de84394d7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485228
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70714}
TBR=mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
Change-Id: Iadae1ee0c6c0400f0e1a0a3805be5316a1d4b979
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10990
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2492330
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70716}
The test WeakContainerTest.ConservativeGCTracesWeakContainer failed on
one of the bots:
https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20ASAN/29755?
This seems like flakiness related to stack scanning.
Bug: v8:11052
Change-Id: Ia60d64e63a071335c4c3f648a4ba0c1823841617
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2492324
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70715}
This CL ports the existing backing store compaction algorithm from
blink. It does not attempt to improve on the existing algorithm.
Currently only unified heap uses the compaction implementation. It is
never triggered through standalone GCs.
The compaction implementation resides within an internal "subtle" namespace.
Bug: v8:10990
Change-Id: I4aa781db1b711e7aafc34234c4fb142de84394d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485228
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70714}
This CL adds TraceWeakContainer and VisitWeakContainer to the Visitor
api. It also introduces the weak_container_worklist_ used to force
re-tracing of weak containers that are reachable from stack.
Bug: chromium:1056170
Change-Id: I4ba75bd64939b8df9ece7422828a5ac647b03fd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491022
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70708}
Refactor the {options} output parameter of the fast callback to a
reference, since it can never be nullptr for functions created with
MakeWithFallbackSupport. This allows embedders to spare the nullptr
check.
Bug: chromium:1052746
Change-Id: I3e22f07af4740ebe8522691da51b6addbc980f24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491026
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70706}
Since JS arguments are always reversed now (https://crrev.com/c/2466116), the logic for skipping the arguments adapter is dead.
It has been subsumed by the complete removal of the adaptor frame (https://crrev.com/c/2440098).
Doc: bit.ly/v8-faster-calls-with-arguments-mismatch
Change-Id: Ia02e0807b7d23a9de371650fa6357113e409d338
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489684
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70704}
No major functional changes in this CL, mostly it moves code around
to make follow-up CLs less messy.
- Document Code layout.
- New concepts: 'body' and 'metadata' areas of Code objects. The
metadata area contains metadata tables, the body area includes
both instructions and metadata (this is currently the 'instructions'
area). Add accessors for these new areas.
- An interesting detail: embedded builtins will have non-adjacent
instruction and metadata areas, thus a concept of 'body' doesn't
make sense there.
- Also add raw_instruction_X_future accessors; these are used where
we are actually interested in the instructions range, not the entire
body. In a follow-up, current raw_instruction_X accessors will be
replaced by raw_body_X, and raw_instruction_X_future by
raw_instruction_X.
Bug: v8:11036
Change-Id: I1d85146b652e0c097c3602d4db1862d5d3898a7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491023
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70701}
Originally, the Torque-generated verifier for a field with type
Undefined|Zero|NonNullForeign would check `f.IsUndefined() || f.IsZero()
|| f.IsNonNullForeign()`. At some point, we changed Torque so that it
now generates the much weaker `f.IsOddball() || f.IsSmi() ||
f.IsForeign()`. This change returns the verifiers to their initial
precision. Mostly we can use the names of abstract types to build up the
correct type check expression, but a few abstract types like
PodArrayOfWasmValueType have no way that we can tell them apart from
their parent type at runtime. It would be confusing to have a function
Object::IsPodArrayOfWasmValueType which actually just checks whether the
object is a ByteArray, so this change introduces a new annotation which
allows abstract type declarations to state that they should use their
parent type during verification.
This change also adds new test cases to help avoid future regressions of
this logic.
Bug: v8:7793
Change-Id: Ie5046d742fd45e0e0f6c2ba387d909e9f2ac6df1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469960
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70698}
This reverts commit 61b56d1650.
Reason for revert: Breaks tests on MSVC bot:
https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/15485
Original change's description:
> [wasm-simd] Add more tests for v128 load zero
>
> Add tests for all valid alignments, and using memarg immediate offset
> instead of i32 index.
>
> Also randomize the memory to help catch cases where we are loading more
> than we should, and accidentally get correct values with zero-ed memory.
>
> Bug: v8:10713
> Change-Id: I443c2799ba0d539bf23c63760c08e18c4d36607f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487880
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70693}
TBR=bbudge@chromium.org,zhin@chromium.org
Change-Id: I9391c5e948c528f00dc966bbf33f709da30d1b17
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10713
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2490479
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70694}
Add tests for all valid alignments, and using memarg immediate offset
instead of i32 index.
Also randomize the memory to help catch cases where we are loading more
than we should, and accidentally get correct values with zero-ed memory.
Bug: v8:10713
Change-Id: I443c2799ba0d539bf23c63760c08e18c4d36607f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487880
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70693}
Implements https://github.com/tc39/ecma262/pull/2154, which allows
module export names to be string literals.
Semantics highlights:
- It is a SyntaxError for string literal export names to have unpaired
UTF16 surrogates.
- It is a SyntaxError for string literal export names to be used as
the local name without being followed by a 'from' clause. For example,
`export { "foo" }` and `export { "foo" as "bar" }` are errors, but
`export { "foo" } from "./module.js"` is allowed.
The remaining failing test262 test is wrong:
https://github.com/tc39/test262/issues/2866
Bug: v8:10964
Change-Id: Ib3e06e1ee6b3f1b60ed7f24e21902e17ddfc0351
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2482335
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70692}
Liftoff can currently run out of registers when compiling an atomic
compare-exchange instruction. In order to see this crash, the following
conditions must be met:
- The offset in the instruction doesn't fit in a 12-bit immediate
- Either FLAG_untrusted_code_mitigations is false, or trap handlers are
enabled, so that AddMemoryMasking decides to do nothing
The fix proposed in this CL is just to defer allocation of a temporary
register until after CalculateActualAddress has finished, because it
might have also needed a temporary register.
Change-Id: I28225614dcdbe2bcc9e52208f1e806baac89c5f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488840
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70687}
This trap now used for all runtime type errors thrown when interfacing
with JS. Its name and message have been changed to reflect this.
Additional change: Remove the trap from the list of traps used
exclusively for RuntimeError (as opposed to TypeError) in
wasm-module-builder.js.
Change-Id: I517766837a60d94b562d4c0de922d52db786b635
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488688
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70682}
Follow the marker pattern where actual logic is moved into a dedicated
state class and the visitors merely forward to that class.
Change-Id: Id3c6b7414343da82759bdba3dbb8286adee44cf4
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480502
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70680}
Bug: chromium:1139782,v8:10765
Change-Id: I417cd037b2587599b925cce08d8652b2df1985ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488687
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Cr-Commit-Position: refs/heads/master@{#70679}
This is a reland of fbfa9bf4ec
The arm64 was missing proper codegen for CFI, thus sizes were off.
Original change's description:
> Reland "[deoptimizer] Change deopt entries into builtins"
>
> This is a reland of 7f58ced72e
>
> It fixes the different exit size emitted on x64/Atom CPUs due to
> performance tuning in TurboAssembler::Call. Additionally, add
> cctests to verify the fixed size exits.
>
> Original change's description:
> > [deoptimizer] Change deopt entries into builtins
> >
> > While the overall goal of this commit is to change deoptimization
> > entries into builtins, there are multiple related things happening:
> >
> > - Deoptimization entries, formerly stubs (i.e. Code objects generated
> > at runtime, guaranteed to be immovable), have been converted into
> > builtins. The major restriction is that we now need to preserve the
> > kRootRegister, which was formerly used on most architectures to pass
> > the deoptimization id. The solution differs based on platform.
> > - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
> > - Removed heap/ support for immovable Code generation.
> > - Removed the DeserializerData class (no longer needed).
> > - arm64: to preserve 4-byte deopt exits, introduced a new optimization
> > in which the final jump to the deoptimization entry is generated
> > once per Code object, and deopt exits can continue to emit a
> > near-call.
> > - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
> > sizes by 4/8, 5, and 5 bytes, respectively.
> >
> > On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
> > by using the same strategy as on arm64 (recalc deopt id from return
> > address). Before:
> >
> > e300a002 movw r10, <id>
> > e59fc024 ldr ip, [pc, <entry offset>]
> > e12fff3c blx ip
> >
> > After:
> >
> > e59acb35 ldr ip, [r10, <entry offset>]
> > e12fff3c blx ip
> >
> > On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
> > with CFI). Additionally, up to 4 builtin jumps are emitted per Code
> > object (max 32 bytes added overhead per Code object). Before:
> >
> > 9401cdae bl <entry offset>
> >
> > After:
> >
> > # eager deoptimization entry jump.
> > f95b1f50 ldr x16, [x26, <eager entry offset>]
> > d61f0200 br x16
> > # lazy deoptimization entry jump.
> > f95b2b50 ldr x16, [x26, <lazy entry offset>]
> > d61f0200 br x16
> > # the deopt exit.
> > 97fffffc bl <eager deoptimization entry jump offset>
> >
> > On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
> >
> > bb00000000 mov ebx,<id>
> > e825f5372b call <entry>
> >
> > After:
> >
> > e8ea2256ba call <entry>
> >
> > On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
> >
> > 49c7c511000000 REX.W movq r13,<id>
> > e8ea2f0700 call <entry>
> >
> > After:
> >
> > 41ff9560360000 call [r13+<entry offset>]
> >
> > Bug: v8:8661,v8:8768
> > Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
> > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70597}
>
> Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
> Bug: v8:8661,v8:8768,chromium:1140165
> Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70655}
Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
Bug: v8:8661
Bug: v8:8768
Bug: chromium:1140165
Change-Id: I471cc94fc085e527dc9bfb5a84b96bd907c2333f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488682
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70672}
Change-Id: I8a9322ef3c7ebaa4f8827a65dca3215f16d70454
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488024
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70670}
There is a typo getting the values of the lanes, only on big-endian
systems. (On little-endian systems, the use of LANE macro hides the
error).
Bug: v8:11008
Change-Id: I99efde506dab443efd336346ec920fcd957daae2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2486614
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70666}
Arm64 supports 16k and 64k OS pages, in which case the CPPGC doesn't use
guard pages.
Bug: v8:10808
Change-Id: I36efba687c50b348eda62e9f9094b57bd58b55b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485494
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70664}
This is a reland of 7f58ced72e
It fixes the different exit size emitted on x64/Atom CPUs due to
performance tuning in TurboAssembler::Call. Additionally, add
cctests to verify the fixed size exits.
Original change's description:
> [deoptimizer] Change deopt entries into builtins
>
> While the overall goal of this commit is to change deoptimization
> entries into builtins, there are multiple related things happening:
>
> - Deoptimization entries, formerly stubs (i.e. Code objects generated
> at runtime, guaranteed to be immovable), have been converted into
> builtins. The major restriction is that we now need to preserve the
> kRootRegister, which was formerly used on most architectures to pass
> the deoptimization id. The solution differs based on platform.
> - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
> - Removed heap/ support for immovable Code generation.
> - Removed the DeserializerData class (no longer needed).
> - arm64: to preserve 4-byte deopt exits, introduced a new optimization
> in which the final jump to the deoptimization entry is generated
> once per Code object, and deopt exits can continue to emit a
> near-call.
> - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
> sizes by 4/8, 5, and 5 bytes, respectively.
>
> On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
> by using the same strategy as on arm64 (recalc deopt id from return
> address). Before:
>
> e300a002 movw r10, <id>
> e59fc024 ldr ip, [pc, <entry offset>]
> e12fff3c blx ip
>
> After:
>
> e59acb35 ldr ip, [r10, <entry offset>]
> e12fff3c blx ip
>
> On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
> with CFI). Additionally, up to 4 builtin jumps are emitted per Code
> object (max 32 bytes added overhead per Code object). Before:
>
> 9401cdae bl <entry offset>
>
> After:
>
> # eager deoptimization entry jump.
> f95b1f50 ldr x16, [x26, <eager entry offset>]
> d61f0200 br x16
> # lazy deoptimization entry jump.
> f95b2b50 ldr x16, [x26, <lazy entry offset>]
> d61f0200 br x16
> # the deopt exit.
> 97fffffc bl <eager deoptimization entry jump offset>
>
> On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
>
> bb00000000 mov ebx,<id>
> e825f5372b call <entry>
>
> After:
>
> e8ea2256ba call <entry>
>
> On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
>
> 49c7c511000000 REX.W movq r13,<id>
> e8ea2f0700 call <entry>
>
> After:
>
> 41ff9560360000 call [r13+<entry offset>]
>
> Bug: v8:8661,v8:8768
> Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70597}
Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
Bug: v8:8661,v8:8768,chromium:1140165
Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70655}
Gracefully handle hugely nested JSBoundFunctions by checking against
the local isolate's stack limit in relevant recursive functions.
This is based on d734bb4c5d (which was
reverted).
In order to get access to the local isolate, the CL replaces the heap
broker's LocalHeap pointer with a LocalIsolate pointer.
Bug: chromium:1125145
Change-Id: I15d6265c7dfcd8a70af4ab4ce6f30149a886be00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480682
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70654}
This reverts commit 7f58ced72e.
Reason for revert: Segfaults on Atom_x64 https://ci.chromium.org/p/v8-internal/builders/ci/v8_linux64_atom_perf/5686?
Original change's description:
> [deoptimizer] Change deopt entries into builtins
>
> While the overall goal of this commit is to change deoptimization
> entries into builtins, there are multiple related things happening:
>
> - Deoptimization entries, formerly stubs (i.e. Code objects generated
> at runtime, guaranteed to be immovable), have been converted into
> builtins. The major restriction is that we now need to preserve the
> kRootRegister, which was formerly used on most architectures to pass
> the deoptimization id. The solution differs based on platform.
> - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
> - Removed heap/ support for immovable Code generation.
> - Removed the DeserializerData class (no longer needed).
> - arm64: to preserve 4-byte deopt exits, introduced a new optimization
> in which the final jump to the deoptimization entry is generated
> once per Code object, and deopt exits can continue to emit a
> near-call.
> - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
> sizes by 4/8, 5, and 5 bytes, respectively.
>
> On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
> by using the same strategy as on arm64 (recalc deopt id from return
> address). Before:
>
> e300a002 movw r10, <id>
> e59fc024 ldr ip, [pc, <entry offset>]
> e12fff3c blx ip
>
> After:
>
> e59acb35 ldr ip, [r10, <entry offset>]
> e12fff3c blx ip
>
> On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
> with CFI). Additionally, up to 4 builtin jumps are emitted per Code
> object (max 32 bytes added overhead per Code object). Before:
>
> 9401cdae bl <entry offset>
>
> After:
>
> # eager deoptimization entry jump.
> f95b1f50 ldr x16, [x26, <eager entry offset>]
> d61f0200 br x16
> # lazy deoptimization entry jump.
> f95b2b50 ldr x16, [x26, <lazy entry offset>]
> d61f0200 br x16
> # the deopt exit.
> 97fffffc bl <eager deoptimization entry jump offset>
>
> On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
>
> bb00000000 mov ebx,<id>
> e825f5372b call <entry>
>
> After:
>
> e8ea2256ba call <entry>
>
> On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
>
> 49c7c511000000 REX.W movq r13,<id>
> e8ea2f0700 call <entry>
>
> After:
>
> 41ff9560360000 call [r13+<entry offset>]
>
> Bug: v8:8661,v8:8768
> Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70597}
TBR=ulan@chromium.org,rmcilroy@chromium.org,jgruber@chromium.org,tebbi@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8661,v8:8768,chromium:1140165
Change-Id: I3df02ab42f6e02233d9f6fb80e8bb18f76870d91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485504
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70649}
With non-super loads (receiver == lookup_start_object), we don't hit
the code in AccessorAssembler::GenericPropertyLoad calling
CSA::TryGetOwnProperty if the receiver (the lookup_start_object) is a
SMI.
But with super property loads, if we set up lookup_start_object the
right way, we will hit this code.
The code was assuming receiver is a HeapObject, which is too
restrictive. The receiver is only used for the accessor call, so
it's ok to make the type more generic.
Bug: v8:9237, chromium:1139786
Change-Id: I3167ccfb54a49ac1c401040a6f02fc1f3b98d9d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484366
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70647}
This is a reland of c5379162dc
The reland fixes Code::clear_padding to correctly clear trailing
padding.
Original change's description:
> [code] Move the unwinding info into metadata area
>
> Semantically, the unwinding info is a variable-size metadata table
> with untagged (i.e. no relocation needed) contents, packed inside Code
> objects. This is just like other metadata tables (safepoint table,
> handler table, constant pool, code comments); but for historical
> reasons it's been treated differently so far. Unlike these other
> tables, the unwinding info was located *after* InstructionEnd, and its
> size was written to the first 8 bytes after InstructionEnd.
>
> This CL makes unwinding info handling more consistent with other
> metadata tables by writing its offset into a dedicated
> kUnwindingInfoOffsetOffset header slot, and by moving the actual data
> inside the [InstructionStart,InstructionEnd[ area. In follow-up CLs,
> this area will be split into dedicated instruction- and metadata
> areas.
>
> A picture is worth 1000 words, before:
>
> +--------------------------+ <-- raw_instruction_start()
> | instructions |
> | ... |
> +--------------------------+
> | embedded metadata | <-- safepoint_table_offset()
> | ... | <-- handler_table_offset()
> | | <-- constant_pool_offset()
> | | <-- code_comments_offset()
> | padding to the next |
> | 8-byte aligned address |
> +--------------------------+ <-- raw_instruction_end()
> | [unwinding_info_size] |
> | as uint64_t |
> +--------------------------+ <-- unwinding_info_start()
> | unwinding info |
> | ... |
> +--------------------------+ <-- unwinding_info_end()
>
> After:
>
> +--------------------------+ <-- raw_instruction_start()
> | instructions |
> | ... |
> +--------------------------+
> | embedded metadata | <-- safepoint_table_offset()
> | ... | <-- handler_table_offset()
> | | <-- constant_pool_offset()
> | | <-- code_comments_offset()
> | | <-- unwinding_info_offset()
> | |
> +--------------------------+ <-- raw_instruction_end()
>
> Bug: v8:11036
> Change-Id: I649708821acc5365186ca2c9cff2669fc3e91fd3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484795
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70640}
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
Tbr: leszeks@chromium.org
Bug: v8:11036
Change-Id: I2ea056fe2a53217e0b5ae25661b92f5ddec6fca5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485501
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70645}
This is a reland of 8f7e915839
Original change's description:
> [debugger] Try to trigger pause-on-oom flakes with an extra printf
>
> We have an issue that we can't repro locally. Enable back the
> pause-on-oom tests with an extra printf with DEBUG. We will be able to
> better assess the failures when they appear on the bot.
>
> Bug: v8:10876
> Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70558}
Bug: v8:10876
Change-Id: Ice31c9455830da320ab057293c341f69e1f0c510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484799
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70643}
Switch the current bool* parameter to a structure that contains
the boolean fallback flag and is forward compatible, if we decide
to add more options to the fallback call.
Fly-by refactoring: moved V8_ENABLE_FP_PARAMS_IN_C_LINKAGE out of
a public V8 header file.
Bug: chromium:1052746
Change-Id: I844db24cc687c58b3c3bbd84b4d61bb4759bcfc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474775
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70642}
This reverts commit c5379162dc.
Reason for revert: Seems to cause MSAN failure - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/34931
Original change's description:
> [code] Move the unwinding info into metadata area
>
> Semantically, the unwinding info is a variable-size metadata table
> with untagged (i.e. no relocation needed) contents, packed inside Code
> objects. This is just like other metadata tables (safepoint table,
> handler table, constant pool, code comments); but for historical
> reasons it's been treated differently so far. Unlike these other
> tables, the unwinding info was located *after* InstructionEnd, and its
> size was written to the first 8 bytes after InstructionEnd.
>
> This CL makes unwinding info handling more consistent with other
> metadata tables by writing its offset into a dedicated
> kUnwindingInfoOffsetOffset header slot, and by moving the actual data
> inside the [InstructionStart,InstructionEnd[ area. In follow-up CLs,
> this area will be split into dedicated instruction- and metadata
> areas.
>
> A picture is worth 1000 words, before:
>
> +--------------------------+ <-- raw_instruction_start()
> | instructions |
> | ... |
> +--------------------------+
> | embedded metadata | <-- safepoint_table_offset()
> | ... | <-- handler_table_offset()
> | | <-- constant_pool_offset()
> | | <-- code_comments_offset()
> | padding to the next |
> | 8-byte aligned address |
> +--------------------------+ <-- raw_instruction_end()
> | [unwinding_info_size] |
> | as uint64_t |
> +--------------------------+ <-- unwinding_info_start()
> | unwinding info |
> | ... |
> +--------------------------+ <-- unwinding_info_end()
>
> After:
>
> +--------------------------+ <-- raw_instruction_start()
> | instructions |
> | ... |
> +--------------------------+
> | embedded metadata | <-- safepoint_table_offset()
> | ... | <-- handler_table_offset()
> | | <-- constant_pool_offset()
> | | <-- code_comments_offset()
> | | <-- unwinding_info_offset()
> | |
> +--------------------------+ <-- raw_instruction_end()
>
> Bug: v8:11036
> Change-Id: I649708821acc5365186ca2c9cff2669fc3e91fd3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484795
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70640}
TBR=jgruber@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org
Change-Id: If8417f88f4c55771e455ec85f5efdc6343671ad3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11036
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485500
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70641}
Semantically, the unwinding info is a variable-size metadata table
with untagged (i.e. no relocation needed) contents, packed inside Code
objects. This is just like other metadata tables (safepoint table,
handler table, constant pool, code comments); but for historical
reasons it's been treated differently so far. Unlike these other
tables, the unwinding info was located *after* InstructionEnd, and its
size was written to the first 8 bytes after InstructionEnd.
This CL makes unwinding info handling more consistent with other
metadata tables by writing its offset into a dedicated
kUnwindingInfoOffsetOffset header slot, and by moving the actual data
inside the [InstructionStart,InstructionEnd[ area. In follow-up CLs,
this area will be split into dedicated instruction- and metadata
areas.
A picture is worth 1000 words, before:
+--------------------------+ <-- raw_instruction_start()
| instructions |
| ... |
+--------------------------+
| embedded metadata | <-- safepoint_table_offset()
| ... | <-- handler_table_offset()
| | <-- constant_pool_offset()
| | <-- code_comments_offset()
| padding to the next |
| 8-byte aligned address |
+--------------------------+ <-- raw_instruction_end()
| [unwinding_info_size] |
| as uint64_t |
+--------------------------+ <-- unwinding_info_start()
| unwinding info |
| ... |
+--------------------------+ <-- unwinding_info_end()
After:
+--------------------------+ <-- raw_instruction_start()
| instructions |
| ... |
+--------------------------+
| embedded metadata | <-- safepoint_table_offset()
| ... | <-- handler_table_offset()
| | <-- constant_pool_offset()
| | <-- code_comments_offset()
| | <-- unwinding_info_offset()
| |
+--------------------------+ <-- raw_instruction_end()
Bug: v8:11036
Change-Id: I649708821acc5365186ca2c9cff2669fc3e91fd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484795
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70640}
Prototype these two instructions on ia32. They are movss and movsd
respectively, so the implementation is pretty simple, as we support
these instructions already.
Bug: v8:11038
Change-Id: Iebf4afab2bf1edfb4b14a4855d5036677f999ca9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2486232
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70634}
I happened to notice while stepping through the StackUnwindingWin64 test
that it never actually encounters a runtime-compiled function despite
using %OptimizeFunctionOnNextCall. V8 compiles the function on the
subsequent call as requested, but the compiled function isn't very good
because there was no feedback data, and it immediately deopts. To fix,
we can call the function once between %PrepareFunctionForOptimization
and %OptimizeFunctionOnNextCall.
Change-Id: Icb25f16d43a60c36a1f85d15e2ce4535e08d1076
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2472780
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70633}
First CL with initial changes:
https://crrev.com/c/2468618
This CL adds the same set to the wasm interpreter.
We also need to make sure "negation" as well as
"std::abs" are excluded from this fix as they can reverse
the sign bit intentionally.
Change-Id: I115649f55b5290d2529dda3d5592feaff3363b76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485246
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70632}
Not sure why I originally chose to name it LoadMem32Zero instead of
Load32Zero like the proposal. This fixes it.
Bug: v8:10713
Change-Id: If05603f743213bc6b7aea0ce22c80ae4b3023ccf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2481824
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70630}
IsRunning is the v8 equivalent of operator bool, but is confusing
with IsCompleted. IsValid (to match base:: operator bool) should be more
clear.
Change-Id: I2529bea21c7cb7613bd5057c66715fb5ea450396
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461840
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70625}
Also known as multiply long, this multiplies the top or bottom half of
the input operands, the result is twice as wide as the input.
This implements arm64 and interpreter.
Bug: v8:11008
Change-Id: Iad693007066dd1a9bc529b282e88812a081c3a01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469156
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70624}
Parse the AssertEntries in an import assertion clause, storing them in
a map. Plumb them through the parser to the appropriate
SourceTextModuleDescriptor methods.
The next change will plumb them into the SourceTextModuleDescriptor's
ModuleRequestMap and through to SourceTextModuleInfo::New.
Bug: v8:10958
Change-Id: I19c31090520f14f94d014e760f5fe372bf773fc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2482326
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70622}
Finally blocks that unconditionally result in an abrupt completion
immediately are currently incorrectly returning the existing completion
value instead of undefined.
Bug: v8:10978
Change-Id: Ida2e27d9cc9711236a1fb30368bfc7213d0f7140
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2473382
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70619}
- Use *LogEntry in more places to avoid confusion with HTML Events
- Move Processor.kProperties to IcLogEntry.getPropertyNames
- Move timeline-track legend "All" entry to the end
Bug: v8:10644
Change-Id: I5a9e833ad0570c39d3106955fa2ba00af53b7062
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463241
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70606}
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}
Preparing for tail call is usually done by emitting the gap moves and
then moving the stack pointer to its new position. An optimization
consists in moving the stack pointer first and transforming some of the
moves into pushes. In the attached case it looks like this (arm):
138 add sp, sp, #40
13c str r6, [sp, #-4]!
140 str r6, [sp, #-4]!
144 str r6, [sp, #-4]!
148 str r6, [sp, #-4]!
14c str r6, [sp, #-4]!
...
160 vldr d1, [sp - 4*3]
The last line is a gap reload, but because the stack pointer was already
moved, the slot is now below the stack pointer. This is invalid and
triggers this DCHECK:
Fatal error in ../../v8/src/codegen/arm/assembler-arm.cc, line 402
Debug check failed: 0 <= offset (0 vs. -12).
A comment already explains that we skip the optimization if the gap
contains stack moves to prevent this, but the code only checks for
non-FP slots. This is fixed by replacing "source.IsStackSlot()" with
"source.IsAnyStackSlot()":
108 vldr d1, [sp + 4*2]
...
118 str r0, [sp, #+36]
11c str r0, [sp, #+32]
120 str r0, [sp, #+28]
124 str r0, [sp, #+24]
128 str r0, [sp, #+20]
...
134 add sp, sp, #20R=jgruber@chromium.org
Bug: chromium:1137608
Change-Id: If2b85dde49bf31a6bd3f5e0255407f9390727f9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474784
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70603}
This fixes a bug that made a test fail in mjsunit/wasm/return-call.js
(the CFI bot does not run the tests with --variants=extra, hence why
it didn't catch it).
It also introduces --sim-abort-on-bad-auth, a debug flag for the arm64
simulator that stops a program as soon as an authentication error
appears, to make debugging easier.
Change-Id: Ibee731ab788aff45301d268ef05256b82f5e4613
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2473833
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70601}
The flaky failure is three years old, let's see how it behaves today.
Bug: v8:5920
Change-Id: Idaa71d274f937e3c6997b49e0acfe7cc88e64956
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484571
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70600}
While the overall goal of this commit is to change deoptimization
entries into builtins, there are multiple related things happening:
- Deoptimization entries, formerly stubs (i.e. Code objects generated
at runtime, guaranteed to be immovable), have been converted into
builtins. The major restriction is that we now need to preserve the
kRootRegister, which was formerly used on most architectures to pass
the deoptimization id. The solution differs based on platform.
- Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
- Removed heap/ support for immovable Code generation.
- Removed the DeserializerData class (no longer needed).
- arm64: to preserve 4-byte deopt exits, introduced a new optimization
in which the final jump to the deoptimization entry is generated
once per Code object, and deopt exits can continue to emit a
near-call.
- arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
sizes by 4/8, 5, and 5 bytes, respectively.
On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
by using the same strategy as on arm64 (recalc deopt id from return
address). Before:
e300a002 movw r10, <id>
e59fc024 ldr ip, [pc, <entry offset>]
e12fff3c blx ip
After:
e59acb35 ldr ip, [r10, <entry offset>]
e12fff3c blx ip
On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
with CFI). Additionally, up to 4 builtin jumps are emitted per Code
object (max 32 bytes added overhead per Code object). Before:
9401cdae bl <entry offset>
After:
# eager deoptimization entry jump.
f95b1f50 ldr x16, [x26, <eager entry offset>]
d61f0200 br x16
# lazy deoptimization entry jump.
f95b2b50 ldr x16, [x26, <lazy entry offset>]
d61f0200 br x16
# the deopt exit.
97fffffc bl <eager deoptimization entry jump offset>
On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
bb00000000 mov ebx,<id>
e825f5372b call <entry>
After:
e8ea2256ba call <entry>
On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
49c7c511000000 REX.W movq r13,<id>
e8ea2f0700 call <entry>
After:
41ff9560360000 call [r13+<entry offset>]
Bug: v8:8661,v8:8768
Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70597}
This changes remoteObjectId format from
"{injectedScriptId:123,id:456}" to "<isolateId>.<contextId>.<id>".
Prepending isolateId fixes the problem that
remote object ids clash between processes. This is especially
troubling during cross-process navigation in Chromium, see bug.
We also stop producing and parsing unnecessary json for object ids.
Drive-by: fixed some tests dumping object ids. Most tests avoid
dumping unstable values like ids, but there were few that still did.
BUG=chromium:1137143
Change-Id: Ia019757fb95704ccb718d3ea6cc54bde1a133382
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461731
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70592}
LocalHeap can be used on main thread, however allocation might cause a
GC which works differently on the main thread than on a background
thread. Support collection on main thread by directly performing the GC
instead of requesting the GC as done on background threads.
To allow for differentiation between main and background threads,
LocalHeap/LocalIsolate now require an additional argument.
Change-Id: I08094ea633e303e149913f21dff395da9e046534
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463238
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70590}
Store lane loads a value from memory and replaces a single lane of a
simd value.
This implements store lane for x64 and interpreter.
Bug: v8:10975
Change-Id: Ida79a03e0fd2bc18f2c06687311936b3cb550ed5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2473383
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70586}
It makes inspector tests a lot more readable if the opcode of the pause
location is being printed. Since we already have a list of all opcodes
available in wasm-module-builder.js, we can just reuse that to build a
reverse lookup map.
This CL implements this for single-byte opcodes only, which is enough
for all tests that we currently have. It will have to be extended for
prefixed opcodes once that is being used.
R=thibaudm@chromium.org, kimanh@chromium.org
Change-Id: I085fea99d2f5f2dc6cc084448e5f7444cce5c78b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474789
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70578}
This reverts commit fba14bde5f.
Reland fixes:
- const vector<const string> -> const vector<string>
Original message:
The following implements a snapshotting algorithm for C++ objects that
also filters strongly-connected components (SCCs) of only "hidden"
objects that are not (transitively) referencing any non-hidden
objects.
C++ objects come in two versions.
a. Named objects that have been assigned a name through NameProvider.
b. Unnamed objects, that are potentially hidden if the build
configuration requires Oilpan to hide such names. Hidden objects have
their name set to NameProvider::kHiddenName.
The main challenge for the algorithm is to avoid blowing up the final
object graph with hidden nodes that do not carry information. For that
reason, the algorithm filters SCCs of only hidden objects, e.g.:
... -> (object) -> (object) -> (hidden) -> (hidden)
In this case the (hidden) objects are filtered from the graph. The
trickiest part is maintaining visibility state for objects referencing
other objects that are currently being processed.
Main algorithm idea (two passes):
1. First pass marks all non-hidden objects and those that transitively
reach non-hidden objects as visible. Details:
- Iterate over all objects.
- If object is non-hidden mark it as visible and also mark parent
as visible if needed.
- If object is hidden, traverse children as DFS to find non-hidden
objects. Post-order process the objects and mark those objects as
visible that have child nodes that are visible themselves.
- Maintain an epoch counter (StateStorage::state_count_) to allow
deferring the visibility decision to other objects in the same
SCC. This is similar to the "lowlink" value in Tarjan's algorithm
for SCC.
- After the first pass it is guaranteed that all deferred
visibility decisions can be resolved.
2. Second pass adds nodes and edges for all visible objects.
- Upon first checking the visibility state of an object, all deferred
visibility states are resolved.
For practical reasons, the recursion is transformed into an iteration.
We do not use plain Tarjan's algorithm to avoid another pass over
all nodes to create SCCs.
Follow ups:
1. Adding wrapper nodes for cpp objects that are wrappables for V8
wrappers.
2. Adding detachedness information.
Bug: chromium:1056170
Change-Id: Ib47df5c912c57d644d052f209276e9d926cece0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480362
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70577}
This is a reland of cdc8d9a5ec
Skipped tests on gc_stress and fixed CONSTEXPR_DCHECK for gcc.
Original change's description:
> [TurboProp] Avoid marking the output of a call live in its catch handler
>
> The output of a call won't be live if an exception is thrown while the
> call is on the stack and we unwind to a catch handler.
>
> BUG=chromium:1138075,v8:9684
>
> Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70562}
Bug: chromium:1138075
Bug: v8:9684
Change-Id: I685c94ee2ffcf06658df07fcef06f58c4f01f54b
Cq-Include-Trybots: luci.v8.try:v8_linux64_gcc_compile_dbg
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479009
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70573}
This reverts commit 02849fd9de.
Reason for revert: Breaks Win64 MSVC bot and closes the tree - https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/15416
Original change's description:
> cppgc-js: Add snapshot for C++ objects
>
> The following implements a snapshotting algorithm for C++ objects that
> also filters strongly-connected components (SCCs) of only "hidden"
> objects that are not (transitively) referencing any non-hidden
> objects.
>
> C++ objects come in two versions.
> a. Named objects that have been assigned a name through NameProvider.
> b. Unnamed objects, that are potentially hidden if the build
> configuration requires Oilpan to hide such names. Hidden objects have
> their name set to NameProvider::kHiddenName.
>
> The main challenge for the algorithm is to avoid blowing up the final
> object graph with hidden nodes that do not carry information. For that
> reason, the algorithm filters SCCs of only hidden objects, e.g.:
> ... -> (object) -> (object) -> (hidden) -> (hidden)
> In this case the (hidden) objects are filtered from the graph. The
> trickiest part is maintaining visibility state for objects referencing
> other objects that are currently being processed.
>
> Main algorithm idea (two passes):
> 1. First pass marks all non-hidden objects and those that transitively
> reach non-hidden objects as visible. Details:
> - Iterate over all objects.
> - If object is non-hidden mark it as visible and also mark parent
> as visible if needed.
> - If object is hidden, traverse children as DFS to find non-hidden
> objects. Post-order process the objects and mark those objects as
> visible that have child nodes that are visible themselves.
> - Maintain an epoch counter (StateStorage::state_count_) to allow
> deferring the visibility decision to other objects in the same
> SCC. This is similar to the "lowlink" value in Tarjan's algorithm
> for SCC.
> - After the first pass it is guaranteed that all deferred
> visibility decisions can be resolved.
> 2. Second pass adds nodes and edges for all visible objects.
> - Upon first checking the visibility state of an object, all deferred
> visibility states are resolved.
>
> For practical reasons, the recursion is transformed into an iteration.
> We do not use plain Tarjan's algorithm to avoid another pass over
> all nodes to create SCCs.
>
> Follow ups:
> 1. Adding wrapper nodes for cpp objects that are wrappables for V8
> wrappers.
> 2. Adding detachedness information.
>
> Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
> Bug: chromium:1056170
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70567}
TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
Change-Id: I64a2cf2259bdaed81f6e0f92bdcc7a1f0df4d197
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479471
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70571}
... and add respective regression tests.
This CL also adds similar regression tests for TransitionArray but it
doesn't have the same issue as DescriptorArray.
Bug: chromium:1133527
Change-Id: I668a90f126d76af0a39816ce8697cb29bc65d01b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465833
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70570}
Executable V8 pages include 3 reserved OS pages: one for the writable
header and two as guards. On systems with 64k OS pages, the amount of
allocatable space left for objects can then be quite smaller than the
page size, only 64k for each 256k page.
This means regular code objects cannot be larger than 64k, while the
maximum regular object size is fixed to 128k, half of the page size. As
a result code object never reach this limit and we can end up filling
regular pages with few large code objects.
To fix this, we change the maximum code object size to be runtime value,
set to half of the allocatable space per page. On systems with 64k OS
pages, the limit will be 32k.
Alternatively, we could increase the V8 page size to 512k on Arm64 linux
so we wouldn't waste code space. However, systems with 4k OS pages are
more common, and those with 64k pages tend to have more memory available
so we should be able to live with it.
Bug: v8:10808
Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70569}
The following implements a snapshotting algorithm for C++ objects that
also filters strongly-connected components (SCCs) of only "hidden"
objects that are not (transitively) referencing any non-hidden
objects.
C++ objects come in two versions.
a. Named objects that have been assigned a name through NameProvider.
b. Unnamed objects, that are potentially hidden if the build
configuration requires Oilpan to hide such names. Hidden objects have
their name set to NameProvider::kHiddenName.
The main challenge for the algorithm is to avoid blowing up the final
object graph with hidden nodes that do not carry information. For that
reason, the algorithm filters SCCs of only hidden objects, e.g.:
... -> (object) -> (object) -> (hidden) -> (hidden)
In this case the (hidden) objects are filtered from the graph. The
trickiest part is maintaining visibility state for objects referencing
other objects that are currently being processed.
Main algorithm idea (two passes):
1. First pass marks all non-hidden objects and those that transitively
reach non-hidden objects as visible. Details:
- Iterate over all objects.
- If object is non-hidden mark it as visible and also mark parent
as visible if needed.
- If object is hidden, traverse children as DFS to find non-hidden
objects. Post-order process the objects and mark those objects as
visible that have child nodes that are visible themselves.
- Maintain an epoch counter (StateStorage::state_count_) to allow
deferring the visibility decision to other objects in the same
SCC. This is similar to the "lowlink" value in Tarjan's algorithm
for SCC.
- After the first pass it is guaranteed that all deferred
visibility decisions can be resolved.
2. Second pass adds nodes and edges for all visible objects.
- Upon first checking the visibility state of an object, all deferred
visibility states are resolved.
For practical reasons, the recursion is transformed into an iteration.
We do not use plain Tarjan's algorithm to avoid another pass over
all nodes to create SCCs.
Follow ups:
1. Adding wrapper nodes for cpp objects that are wrappables for V8
wrappers.
2. Adding detachedness information.
Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70567}
This reverts commit cdc8d9a5ec.
Reason for revert: The regression test is too slow:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/30454
Also gcc failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20gcc%20-%20debug/9528
Original change's description:
> [TurboProp] Avoid marking the output of a call live in its catch handler
>
> The output of a call won't be live if an exception is thrown while the
> call is on the stack and we unwind to a catch handler.
>
> BUG=chromium:1138075,v8:9684
>
> Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70562}
TBR=rmcilroy@chromium.org,neis@chromium.org
Change-Id: I0f6b9378d516a70401fc429fb3612bbf962b0fb2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1138075
Bug: v8:9684
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479007
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70564}
The output of a call won't be live if an exception is thrown while the
call is on the stack and we unwind to a catch handler.
BUG=chromium:1138075,v8:9684
Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70562}
Align the library with the current blink implementation.
TraceStrongly takes a WeakMember and strongifies it so that the
referenced objects is retained.
This is used in blink during tracing of some weak collections.
Bug: chromium:1056170
Change-Id: I306f84fc37a856d309bccc7f544750abb2bdc7c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479003
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70561}
This is a reland of 44708a5b6f
Original change's description:
> [compiler, heap] Create LocalHeap outside of ExecuteJob
>
> Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
> pass its reference as argument to ExecuteJob. This allows us to create
> LocalHeap differently for the main and background thread, e.g. by
> passing an additional argument to the constructor in the future.
> It will be required in the future anyways when the main thread will
> have its own LocalHeap/LocalIsolate.
>
> Extending the scope of LocalHeap, also made
> HandleBase::IsDereferenceAllowed more precise and uncovered two
> potential issues: heap accesses in
> OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
> with --code-comments.
>
> LocalHeap can now be created in the parked state. Also fixed a data
> race with LocalHeap's destructor publishing write barrier entries
> without holding the lock.
>
> Bug: v8:10315
> Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70521}
Bug: v8:10315
Change-Id: I4c459fd6dfb98d47fc9941c0dc6864bf5a1d2d3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474788
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70560}
This reverts commit 8f7e915839.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20node.js%20integration%20ng/10707?
Original change's description:
> [debugger] Try to trigger pause-on-oom flakes with an extra printf
>
> We have an issue that we can't repro locally. Enable back the
> pause-on-oom tests with an extra printf with DEBUG. We will be able to
> better assess the failures when they appear on the bot.
>
> Bug: v8:10876
> Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70558}
TBR=rmcilroy@chromium.org,petermarshall@chromium.org,solanes@chromium.org
Change-Id: I1b8a146d9496e889957636456b383f8d496658dc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10876
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479004
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70559}
We have an issue that we can't repro locally. Enable back the
pause-on-oom tests with an extra printf with DEBUG. We will be able to
better assess the failures when they appear on the bot.
Bug: v8:10876
Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70558}
https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
Revised predictions for Morocco's changes starting in 2023.
Canada's Yukon changes to -07 on 2020-11-01, not 2020-03-08.
Macquarie Island has stayed in sync with Tasmania since 2011.
Casey, Antarctica is at +08 in winter and +11 in summer.
zic no longer supports -y, nor the TYPE field of Rules.
Bug: chromium:1137864, chromium:1138117
Change-Id: I6076a993fcd755074ddcfa5321b78aa5f043337b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476681
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70553}
This is merged into the proposal, move it out of post-mvp flags, and
remove any ifdefs guarding it.
Bug: v8:10993
Change-Id: I4c82e3fc17c97735d5417fa4a5d85d7f091fbb8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2453457
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70552}
read_prefixed_byte is used mostly to read an entire prefixed opcode, it
writes the number of bytes of the opcode index (without prefix byte) to
the out param length. Change it so it writes the total number of bytes
(including the prefix byte), as that is what most callers want (they add
1 after calling read_prefixed_byte).
Bug: v8:10810
Change-Id: I914190ecae62e3547652accdc05d1cef3686fff4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476678
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70551}
Rename AddSaturate and SubSaturate to the shorter version, AddSat and
SubSat, following the spec.
Bug: v8:10946,v8:10933
Change-Id: Idf74b3a1eb2e2f6d4e37d2b8e5fa6d96ea090db4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436615
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70549}
Some of the tests were incorrectly using DCHECK for assertions, we want
these checks to run in all configurations, not only in DEBUG.
Change-Id: I41ab7c7f1aa9fe3947255fc107437fa48f304e5d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2473579
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70546}
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}
Prefixed opcodes have a 1 byte prefix, followed by LEB-encoded u32. This
changes all prefixed opcodes (gc, numeric, atomic), to that. (Simd was
already so.)
We can clean up read_prefix_opcode to return the total number of bytes,
1 byte prefix + leb encoded, that will be in a future patch.
Bug: v8:10810,v8:10994
Change-Id: Ia74604acc059c1336b87e9f477598732de219ca9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465057
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70544}
"std/stw" must always store to a memory address.
Destination cannot be another register.
Change-Id: I424bd535033937b3876f58ca5a4530aeac43e182
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476064
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70540}
Expressions like `foo() = 42` are specified as syntax errors but due to
web compat must be kept as runtime errors.
Bug: v8:10976
Change-Id: If2b549a3a1c35248c46319fa0e898872d40789a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471979
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70538}
test-heap-profiler/AllocationSitesAreVisible was disabled unnecessarily
for quite some time. With a minor fix, it's possible to validate that
an AllocationSite can be seen through the heap profiler interface.
Change-Id: I0ac6c218da12ab268bd08c65926149f5c00e5b06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474778
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70537}
In certain situations a phi might not be used by later code, and so
is neither spilled nor has a register allocated to it. Handle this
by removing the incorrect DCHECK.
BUG=chromium:1137979,v8:9684
Change-Id: I702dc05dba22e23dac5c1a366a770f18bac45c52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471998
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70536}
... at function start. Otherwise we run into a position mismatch:
In a non-flooded function, we add the function-entry breakpoint (for
"hook on function call") with the position of the first opcode.
In the flooded function though, we skip that special breakpoint because
we will stop at the first instruction anyway. But then the first
instruction is non-breakable, so we don't actually emit a breakpoint for
it.
Hence during OSR we do not find a corresponding position in the new
code.
This CL fixes this by postponing the function-entry breakpoint until the
first breakable opcode is found, and only emits it if that position does
not have a breakpoint anyway.
This way, we can also move the handling for function-entry breakpoints
from {StartFunctionBody} to {EmitDebuggingInfo}, where it fits much
better.
R=thibaudm@chromium.org
Bug: chromium:1137710
Change-Id: Idfa658fa0897cca89ba5ee3066cd414f68864d06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474774
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70529}
Stepping always happens in Liftoff now, and always by byte offset. Thus
remove the redundant "wasm-stepping-byte-offset" test, which was fully
subsumed by "wasm-stepping-liftoff". Also, rename
"wasm-stepping-liftoff" to "wasm-stepping".
R=thibaudm@chromium.org
Bug: chromium:1137710
Change-Id: Ifb68ce795ecdcbb1f85500dc4be4c2e64d15a9c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474116
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70528}
Cppgc exposes EphemeronPair that contains a WeakMember key and a Member
value and can be used to denote ephemeron semantics in the standalone
library.
Tracing EphemeronPairs goes through TraceEphemeron that is exposed on
the api for the blink usecase.
Bug: chromium:1056170
Change-Id: I9fbaa284fa2034248cdf36ea8b0cd5be6a55f676
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467842
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70525}
This reverts commit 44708a5b6f.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33692
Original change's description:
> [compiler, heap] Create LocalHeap outside of ExecuteJob
>
> Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
> pass its reference as argument to ExecuteJob. This allows us to create
> LocalHeap differently for the main and background thread, e.g. by
> passing an additional argument to the constructor in the future.
> It will be required in the future anyways when the main thread will
> have its own LocalHeap/LocalIsolate.
>
> Extending the scope of LocalHeap, also made
> HandleBase::IsDereferenceAllowed more precise and uncovered two
> potential issues: heap accesses in
> OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
> with --code-comments.
>
> LocalHeap can now be created in the parked state. Also fixed a data
> race with LocalHeap's destructor publishing write barrier entries
> without holding the lock.
>
> Bug: v8:10315
> Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70521}
TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,solanes@chromium.org,dinfuehr@chromium.org
Change-Id: I9dd1f8ca6237d5716b6d8938cef0ee3f642f3166
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474118
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70522}
Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
pass its reference as argument to ExecuteJob. This allows us to create
LocalHeap differently for the main and background thread, e.g. by
passing an additional argument to the constructor in the future.
It will be required in the future anyways when the main thread will
have its own LocalHeap/LocalIsolate.
Extending the scope of LocalHeap, also made
HandleBase::IsDereferenceAllowed more precise and uncovered two
potential issues: heap accesses in
OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
with --code-comments.
LocalHeap can now be created in the parked state. Also fixed a data
race with LocalHeap's destructor publishing write barrier entries
without holding the lock.
Bug: v8:10315
Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70521}
These instructions will be used for prototyping Wasm SIMD's store lane
later on, separated the implementation for assembler and disassembler
into this patch to make things smaller.
Curiously, movhps and movlhps seems to have the same encoding, 0f 16, so
I'm not sure not sure how to differentiate them in the disassembler
besides using the mod field, since movlhps only takes xmm registers,
whereas movhps always take 1 operand.
Bug: v8:10975
Change-Id: I8be9a31b1c9a5515038f9c8c55ef30d1ba063ea7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471977
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70520}
It is related to Reduce consecutive overflow addition with constants.
Turned out that we needs to consider also effect use before relaxing it.
This fixed the issue that fuzzer found in e93a369f7a.
Bug: chromium:1137586
Change-Id: I32fee5ecc7a6ce40d6f739f9c6e2440a647a2222
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469597
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70514}
Due to a bug on AIX, some of the glibc FP functions do not
preserve the sign bit when a negative input is passed by
value and the output is rounded to 0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97086
This CL forces the use of "-0.0" in such cases.
Change-Id: If9935596e32e97720f3cb22f27975267ac1124d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2468618
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70512}
This change adds test functions to check that the Torque-generated
verifiers can catch a few basic kinds of errors and crash the process.
Bug: v8:7793
Change-Id: If0d2b1e8834c3e602c2677253ad3a920566414bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469039
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70506}
This CL adds a basic tiering strategy for the js-to-wasm wrappers.
When applicable, calls to exported WebAssembly functions are initially
handled through the generic js-to-wasm wrapper. If these calls
through the generic wrapper reach a constant threshold, the specific
(per-signature) wrapper is compiled synchronously for the function
and the generic wrapper is replaced.
Bug: v8:10982
Change-Id: I65e706daffb5cb6e723ce2f7b785f7ecb7b2fa7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461243
Commit-Queue: Vicky Kontoura <vkont@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70503}
We fall back from irregexp to the experimental engine if a backtrack
limit is exceeded and the experimental engine can handle the regexp.
The feature can be turned on with a boolean flag, and an uint-valued
flag controls the default backtrack limit. For regexps that are
constructed with an explicit backtrack limit (API,
%NewRegExpWithBacktrackLimit), we choose the lower of the explicit and
default backtrack limits.
The default backtrack limit does not apply to regexps that can't be
handled by the experimental engine, and for such regexps an explicitly
specified backtrack limit is handled as before by returning null if we
exceed it.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I580df79bd847520985b6c2c2159bc427315c89d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436341
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70500}
This is a reland of 3593ee832c
The MSAN doesn't seem to be considering initializing stores via inline
assembly as such (in a new cctest helper GetStackPointer()), so this
reland attempt fixes the issue and ensures that the MSAN bot is happy.
Original change's description:
> Reland "[csa] Fix semantics of PopAndReturn"
>
> This is a reland of 5e5eaf7954
>
> This CL fixes the "function returns address of local variable" issue
> which GCC was complaining about by using inline assembly instead of
> address of a local for getting stack pointer approximation.
>
> Original change's description:
> > [csa] Fix semantics of PopAndReturn
> >
> > This CL prohibits using PopAndReturn from the builtins that
> > have calling convention with arguments on the stack.
> >
> > This CL also updates the PopAndReturn tests so that even off-by-one
> > errors in the number of poped arguments are caught which was not the
> > case before.
> >
> > Motivation:
> >
> > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> > dropping ALL JS arguments that are currently located on the stack.
> > Disallowing PopAndReturn in builtins with stack arguments simplifies
> > semantics of this instruction because in case of presence of declared
> > stack parameters it's impossible to distinguish the following cases:
> > 1) stack parameter is included in JS arguments (and therefore it will
> > be dropped as a part of 'pop' number of arguments),
> > 2) stack parameter is NOT included in JS arguments (and therefore it
> > should be dropped in ADDITION to the 'pop' number of arguments).
> >
> > This issue wasn't noticed before because builtins with stack parameters
> > relied on adapter frames machinery to ensure that the expected
> > parameters are present on the stack, but on the same time the adapter
> > frame tearing down code was effectively recovering the stack pointer
> > potentially broken by the CSA builtin.
> >
> > Once we get rid of the arguments adapter frames keeping stack pointer
> > in a valid state becomes crucial.
> >
> > Bug: v8:5269, v8:10201
> > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> > Commit-Queue: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70454}
>
> Tbr: tebbi@chromium.org
> Bug: v8:5269
> Bug: v8:10201
> Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70483}
Tbr: tebbi@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
Bug: v8:5269
Bug: v8:10201
Change-Id: Ib09af2d1260bb42ac26aabface14e6b83b3efec4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467847
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70492}
As a drive-by, enable tests that are safe for Arm32/64 to run.
Bug: v8:10833
Change-Id: I8fed5651399852f9ce8ba7d5acdb7ed27ca28e89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467841
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70491}
This reverts commit 3593ee832c.
Reason for revert: MSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/34798
Original change's description:
> Reland "[csa] Fix semantics of PopAndReturn"
>
> This is a reland of 5e5eaf7954
>
> This CL fixes the "function returns address of local variable" issue
> which GCC was complaining about by using inline assembly instead of
> address of a local for getting stack pointer approximation.
>
> Original change's description:
> > [csa] Fix semantics of PopAndReturn
> >
> > This CL prohibits using PopAndReturn from the builtins that
> > have calling convention with arguments on the stack.
> >
> > This CL also updates the PopAndReturn tests so that even off-by-one
> > errors in the number of poped arguments are caught which was not the
> > case before.
> >
> > Motivation:
> >
> > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> > dropping ALL JS arguments that are currently located on the stack.
> > Disallowing PopAndReturn in builtins with stack arguments simplifies
> > semantics of this instruction because in case of presence of declared
> > stack parameters it's impossible to distinguish the following cases:
> > 1) stack parameter is included in JS arguments (and therefore it will
> > be dropped as a part of 'pop' number of arguments),
> > 2) stack parameter is NOT included in JS arguments (and therefore it
> > should be dropped in ADDITION to the 'pop' number of arguments).
> >
> > This issue wasn't noticed before because builtins with stack parameters
> > relied on adapter frames machinery to ensure that the expected
> > parameters are present on the stack, but on the same time the adapter
> > frame tearing down code was effectively recovering the stack pointer
> > potentially broken by the CSA builtin.
> >
> > Once we get rid of the arguments adapter frames keeping stack pointer
> > in a valid state becomes crucial.
> >
> > Bug: v8:5269, v8:10201
> > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> > Commit-Queue: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70454}
>
> Tbr: tebbi@chromium.org
> Bug: v8:5269
> Bug: v8:10201
> Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70483}
TBR=tebbi@chromium.org,ishell@chromium.org,victorgomes@chromium.org
Change-Id: Icbd71d744a519a58e49feb917109228631b9d9a3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5269
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467846
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70485}
This is a reland of 5e5eaf7954
This CL fixes the "function returns address of local variable" issue
which GCC was complaining about by using inline assembly instead of
address of a local for getting stack pointer approximation.
Original change's description:
> [csa] Fix semantics of PopAndReturn
>
> This CL prohibits using PopAndReturn from the builtins that
> have calling convention with arguments on the stack.
>
> This CL also updates the PopAndReturn tests so that even off-by-one
> errors in the number of poped arguments are caught which was not the
> case before.
>
> Motivation:
>
> PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> dropping ALL JS arguments that are currently located on the stack.
> Disallowing PopAndReturn in builtins with stack arguments simplifies
> semantics of this instruction because in case of presence of declared
> stack parameters it's impossible to distinguish the following cases:
> 1) stack parameter is included in JS arguments (and therefore it will
> be dropped as a part of 'pop' number of arguments),
> 2) stack parameter is NOT included in JS arguments (and therefore it
> should be dropped in ADDITION to the 'pop' number of arguments).
>
> This issue wasn't noticed before because builtins with stack parameters
> relied on adapter frames machinery to ensure that the expected
> parameters are present on the stack, but on the same time the adapter
> frame tearing down code was effectively recovering the stack pointer
> potentially broken by the CSA builtin.
>
> Once we get rid of the arguments adapter frames keeping stack pointer
> in a valid state becomes crucial.
>
> Bug: v8:5269, v8:10201
> Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70454}
Tbr: tebbi@chromium.org
Bug: v8:5269
Bug: v8:10201
Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70483}
Currently there are a number of -Wsubobject-linkage warnings when
compiling with gcc (formatted to fit 72 character lines):
In file included from
...
from ../../testing/gtest/include/gtest/gtest.h:10,
from ../../testing/gtest-support.h:8,
from ../../test/unittests/test-utils.h:20,
from ../../test/unittests/compiler/backend/
instruction-selector-unittest.h:15,
from ../../test/unittests/compiler/x64/
instruction-selector-x64-unittest.cc:9:
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:
In instantiation of ‘class
testing::internal::ParameterizedTestFactory<v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test>’:
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:439:12: required from
‘testing::internal::TestFactoryBase*
testing::internal::TestMetaFactory<TestSuite>::CreateTestFactory(
testing::internal::TestMetaFactory<TestSuite>::ParamType)
[with
TestSuite = v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test;
testing::internal::TestMetaFactory<TestSuite>::ParamType =
v8::internal::compiler::{anonymous}::LoadWithToInt64Extension]’
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:438:20: required from here
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:394:7: warning:
‘testing::internal::ParameterizedTestFactory<
v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test >’ has a field
‘testing::internal::ParameterizedTestFactory<
v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test>::parameter_’ whose type uses the
anonymous namespace [-Wsubobject-linkage]
394 | class ParameterizedTestFactory : public TestFactoryBase {
| ^~~~~~~~~~~~~~~~~~~~~~~~
This commit moves the parameterized tests in question into the
anonymous namespace to avoid the warnings.
Change-Id: I9c4a8bd9f4e225ed14ab64f5433d5f5c102e01a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418723
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70482}
Whenever more then one value is pushed to the stack, we need to execute
a check for growing the stack first (since https://crrev.com/c/2431525).
This CL adds two missing checks.
R=thibaudm@chromium.org
Bug: chromium:1137582
Change-Id: I9755502dfdb77c03d1dde3e83fb7d33b9b99e499
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467796
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70480}
The call to "GetSpilledRegistersForInspection" was invalidated by the
call to "GetUnusedRegister" a few lines below.
R=clemensb@chromium.org
Bug: v8:10957
Change-Id: I1e0110d9b28ca23a2a8b9ff4b4c39143bfbe5510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466118
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70478}
The index to be traced can be a full (platform-dependent) pointer sized
integer now. This CL prepares memory tracing for that.
As a drive-by, the "address" field is renamed to "offset", or
"effective_offset", depending on the situation.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I1fabfdb57835f041e1310a4eb4024d6254c08752
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465825
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70477}
Rename the flag --liftoff-extern-ref to
--experimental-liftoff-extern-ref to keep the fuzzer from using it.
The implementation is not complete yet, and the next steps may take a
bit.
R=clemensb@chromium.org
Bug: chromium:1137601
Change-Id: I74f1ed8faba44e42f63790d87f4a538dd59ac852
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465838
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70476}
Use monotonic times for logging with --predictable.
Bug: v8:10937, v8:10966, v8:10668
Change-Id: I3d4f0d48375f6f5d9fa375cf5393ff3afee7c0b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465829
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70474}
We now remember whether the memory was 64 bit, in in this case force the
index value to be an i64 instead of an i32.
This is only the decoding part of this change. TurboFan and Liftoff will
have to be fixed separately to handle the i64 values correctly.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: Ia504e7eb5a2a55caf8dfdbd0833481ef590c55bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461239
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70473}
The generic wrapper will be the baseline variant of the JavaScript-to-
WebAssembly wrapper. Enabling it in the nooptimization variant gives it
test coverage.
R=clemensb@chromium.org
Bug: v8:10701
Change-Id: I37d1f767c61ff70e103d1742ef84f874c3804d7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461240
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70472}
Always spend 1ms per iteration.
Previously if the profilerthread took a long time to start up then we
would skip through iterations and potentially not gather enough samples.
This forces each iteration to take 1ms.
Bug: v8:10996
Change-Id: I0dd7bb7e31636c9ebf5dd99110c8a976cbc8f045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461727
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70466}
CreateFrameFromInternal always creates StackFrame from the frame at the index zero,
which is fine for the usage in Trap::origin, but is a bug for Trap::trace
Change-Id: Ia9471f600c5165ffc1c165b2f114b40acbe5b1e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465353
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70465}
These are still not in proposal, so they should be behind the post-mvp
flag.
Bug: v8:10972
Change-Id: I1b53307f334ddd8e21a095c13d7f7abb8ce05203
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465654
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70463}
This implements i8x16.popcnt on arm64 and interpreter.
Bug: v8:11002
Change-Id: Ia94a053d7e0a0c800057ac80865ba6f86ac7caf8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461058
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70461}
This reverts commit 5e5eaf7954.
Reason for revert: Failure on V8 Linux gcc https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8929?
Original change's description:
> [csa] Fix semantics of PopAndReturn
>
> This CL prohibits using PopAndReturn from the builtins that
> have calling convention with arguments on the stack.
>
> This CL also updates the PopAndReturn tests so that even off-by-one
> errors in the number of poped arguments are caught which was not the
> case before.
>
> Motivation:
>
> PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
> dropping ALL JS arguments that are currently located on the stack.
> Disallowing PopAndReturn in builtins with stack arguments simplifies
> semantics of this instruction because in case of presence of declared
> stack parameters it's impossible to distinguish the following cases:
> 1) stack parameter is included in JS arguments (and therefore it will
> be dropped as a part of 'pop' number of arguments),
> 2) stack parameter is NOT included in JS arguments (and therefore it
> should be dropped in ADDITION to the 'pop' number of arguments).
>
> This issue wasn't noticed before because builtins with stack parameters
> relied on adapter frames machinery to ensure that the expected
> parameters are present on the stack, but on the same time the adapter
> frame tearing down code was effectively recovering the stack pointer
> potentially broken by the CSA builtin.
>
> Once we get rid of the arguments adapter frames keeping stack pointer
> in a valid state becomes crucial.
>
> Bug: v8:5269, v8:10201
> Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70454}
TBR=tebbi@chromium.org,ishell@chromium.org
Change-Id: I2673982a8f51cbecf421af11b0ce5ad5031fb406
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5269
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465656
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70458}
Load lane loads a value from memory and replaces a single lane of a
simd value.
This implements the load (no stores yet) for x64 and interpreter.
Bug: v8:10975
Change-Id: I95d1b5e781ee9adaec23dda749e514f2485eda10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444578
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70456}
These instructions are not in the proposal, and will be unlikely to be
requested (poor performance, insufficient use cases). As we get more
instruction suggestions, these are sitting around on useful opcodes and
we have to play musical chairs every time we prototype a new
instruction.
Bug: v8:10933
Change-Id: Ic7ce4e514c343d821f76b8c071e41f9bddfbd1ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2457669
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70455}
This CL prohibits using PopAndReturn from the builtins that
have calling convention with arguments on the stack.
This CL also updates the PopAndReturn tests so that even off-by-one
errors in the number of poped arguments are caught which was not the
case before.
Motivation:
PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
dropping ALL JS arguments that are currently located on the stack.
Disallowing PopAndReturn in builtins with stack arguments simplifies
semantics of this instruction because in case of presence of declared
stack parameters it's impossible to distinguish the following cases:
1) stack parameter is included in JS arguments (and therefore it will
be dropped as a part of 'pop' number of arguments),
2) stack parameter is NOT included in JS arguments (and therefore it
should be dropped in ADDITION to the 'pop' number of arguments).
This issue wasn't noticed before because builtins with stack parameters
relied on adapter frames machinery to ensure that the expected
parameters are present on the stack, but on the same time the adapter
frame tearing down code was effectively recovering the stack pointer
potentially broken by the CSA builtin.
Once we get rid of the arguments adapter frames keeping stack pointer
in a valid state becomes crucial.
Bug: v8:5269, v8:10201
Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70454}
For turboprop, it's a better tradeoff to reuse the code than
specialising the code for a particular closure especially given we
optimize quite early when compared to Turbofan.
Bug: v8:9684
Change-Id: Icf5d8548bbdcac9e202dcf44c68e06cc4c732ba7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461242
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70451}
This test allocates a large mapping and splits into kThunkBufferSize
areas that it needs to be able to change permissions on. So
kThunkBufferSize needs to be set to the largest page size possible,
which is 64k at the moment.
It doesn't matter if kThunkBufferSize is larger than the actual page
size.
Bug: v8:10808
Change-Id: I3a8947f04a7ec25be49a54015cd128e901065ea6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463404
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70449}
Fix a crash/hang that occurred when deleting a snapshot during the
GC that is part of taking another one.
Specifically, when deleting the only other snapshot in such
a situation, the `v8::HeapSnapshot::Delete()` method sees that there
is only one (complete) snapshot at that point, and decides that it is
okay to perform “delete all snapshots” instead of just deleting
the requested one. That resets the internal string lookup table
of the heap profiler, but the new snapshot that is currently in
progress still holds references to the old string lookup table,
leading to a use-after-free segfault or infinite loop.
Fix this by guarding against resetting the string table while
another heap snapshot is being taken, and add a test that would
crash before this fix.
This can be triggered in Node.js by repeatedly calling
`v8.getHeapSnapshot()`, which provides heap snapshots as weakly
held host objects.
Change-Id: If9ac3728bf79114000982f1e7bb05e8034299e3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464823
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70445}
Clean-ups:
* Remove the detaching of persistent handles from the LocalHeap if the
main thread will not get the handles from the background thread.
* Remove unused isolate member.
* Make members private/protected as needed.
Bug: v8:7790
Change-Id: I23bf4a41124bd04d4a848edfa1ef8f9e8e77182c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463234
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70442}
This is a reland of e2408c2521
Changes since last time: also accept CRASH test results. For some
reason, the CHECK failure is detected as a CRASH on mac bots.
Original change's description:
> [regexp] Protect against reentrant RegExpStack use
>
> Irregexp, and in particular the RegExpStack, are not reentrant.
> Explicitly guard against reentrancy.
>
> Bug: chromium:1125934
> Change-Id: I0fc295f6986a89221982e6a2ccefed46193974f6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460820
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70436}
Tbr: yangguo@chromium.org
Bug: chromium:1125934
Change-Id: I2116ca5944c49f6114228d4402847bdd426bdd7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465823
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70441}
Irregexp, and in particular the RegExpStack, are not reentrant.
Explicitly guard against reentrancy.
Bug: chromium:1125934
Change-Id: I0fc295f6986a89221982e6a2ccefed46193974f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460820
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70436}
These tests were disabled because scalar lowering wasn't fully
implemented yet. Now we are at a stage when we can enable them.
The only remaining tests with lowering test disabled are prototype
instructions, once they are merged into the proposal proper, scalar
lowering should be implemented for them, and relevant tests enabled.
Bug: v8:10507
Change-Id: I4b7c8778f70e226ebda3bf5a2a7dd5efa343bc0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460841
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70435}
Lowering for f32x4 and f64x2 pmin and pmax.
Bug: v8:10501,v8:10507
Change-Id: I2d92d337835a62e6adb979ed573b616cc2b86c25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461453
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70434}
Some of these functions don't need to be defined, we can directly call
the same helpers defined elsewhere.
Bug: v8:10933
Change-Id: I31464195b11ed14f0725d9ed9711fa72ddbb4e92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461478
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70433}
Tracing JSMembers uses the bailout mechanism.
The bailout is implemented as a dynamic mechanism named
DeferTraceToMutatorThreadIfConcurrent that is called from
relevant Trace methods.
Bug: chromium:1056170
Change-Id: I90e6feae25c4c832be256693f9e44a963a6794b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426613
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70429}
Adds a cross-thread reference for strongly and weakly retaining
objects on a thread other than the thread that owns the object.
The intended use of the reference is by setting it up on the
originating thread, holding the object alive from another thread, and
ultimately accessing the object again on the originating thread.
The reference has known caveats:
- It's unsafe to use when the heap may terminate;
- It's unsafe to transitively reach through the graph because of
compaction;
Change-Id: I84fbdde69a099eb54af5b93c34e2169915b17e64
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436449
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70428}
Since GC can now happen during deserialization, object fields may
contain the Smi sentinel value instead of pointers. This adds the
required guards to methods of NativeContextInferrer
Bug: chromium:1136801
Change-Id: I7338f31bf6ee34b8dee8431b8250d2cc2978e0c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461241
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70425}
Changes:
- Add wasm-to-js wrapper field to WasmJSFunction. A WasmJSFunction might
be called with call_ref without being imported to a module, and this
provides a call target for this scenario. The wrapper is only compiled
if --experimental-wasm-typed-funcref is set.
- Add CompileWasmToJSWrapper in wasm-compiler.
- Rename BuildLoadFunctionDataFromExportedFunction ->
BuildLoadFunctionDataFromJSFunction to reflect its wider usage.
- Rename BuildWasmImportCallWrapper -> BuildWasmToJsWrapper to reflect
this function is now also used by CompileWasmToJSWrapper (unrelated to
imports).
- (Drive-by) Remove dead arguments from wasm-module-builder.js.
Bug: v8:9495
Change-Id: I23468b69d42310cb8e96da5286ce68c701188876
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2459371
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70421}
The assertion states that compilation of an empty script does not add
new pages. This doesn't not necessarily hold if the existing pages are
almost full.
Bug: v8:10988
Change-Id: I71735e6736fb94e1ccde7f6430a2c4b0d48c43f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461728
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70417}
Missed this earlier when it was merged into the proposal.
f32x4 and f64x2 ceil, floor, trunc, nearestint. Also enable cctests.
Bug: v8:10507,v8:10906
Change-Id: I2de00e615cd63d81303649774db2a2ab800f6f72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461451
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70415}
With this CL, fast API calls reuse the same stack slot they are
using for the {fallback} parameter. This relies on the fact that
the fast calls are non-reentrant, due to their inability to call
into JavaScript.
Bug: chromium:1052746
Change-Id: I2c56fcbe425023244a566bb39439e8e04072f316
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461729
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70409}
Currently MockPlatform has shorter lifetime than the isolate that uses
it. This leads to use-after-free races in concurrent tasks that fetch
the mock platform just before it is freed.
This CL ensures that MockPlatform is valid throughout the whole
lifetime of the isolate
Change-Id: Ib94dc7674b9f94833be3372de68209ec38577ca1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461726
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70407}
Remove one "mode" of LEB decoding by eliminating the {AdvancePCFlag},
and doing the PC advance in the caller instead.
The returned length is now always zero in case of an error, thus remove
the respective checks from the unit tests. The returned length does not
really matter if we ran into an error.
R=thibaudm@chromium.org
Change-Id: Ibfd94dd981cefa2fc24c7af560c85afd1c826f2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449972
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70404}
1. Set profiling interval to 100us to get 10x the samples
2. Guarantee we spend at least 1ms per iteration, instead of only
bailing out if we spend more than 1ms. This gives us enough samples on
release mode.
3. Increase the time spent profiling optimized code
Bug: v8:10996
Change-Id: I1348ebce48fe998e79b5847f3e3d037148302dcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460823
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70403}
Adds NameProvider to allow specifying names of objects. The
corresponding internal NameTrait is registered with the GCInfo object.
Use name infrastructure to provide a hint on encountering an unmarked
object in the marking verifier.
Bug: chromium:1056170
Change-Id: I95bb290660f5905500f861bd5cc85148a1b47184
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454087
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70400}
The existing macro assembler define Pinsrb, which expects 3 arguments:
- XMMRegister dst
- Register/Operand src
- uint8_t imm
which overwrites dst with src at lane specified by imm.
That means we cannot use the AVX version, which has 4 arguments, and
does not overwrite dst.
This refactoring defines the 4 argument AVX version instead, and if AVX
is not supported, fall back to the SSE version, and ensure that the
value is copied over into dst first.
For convenience, we define an overload with 3 arguments that duplicates
dst, this replicates the SSE behavior, so that not all callers have to
be updated.
Bug: v8:10975, v8:10933
Change-Id: I6f9b9d37fa08d3f5cff4f040ae7d5e1f0cf36455
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444096
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70392}
This is a predicate checking if any module in a module graph is [[Async]], i.e.
contains a top-level await. It is needed for ServiceWorker integration, as
ServiceWorkers disallows top-level await in its modules to prevent stalling
during registration.
https://github.com/w3c/ServiceWorker/pull/1444
Bug: v8:9344
Change-Id: Id84489bc73717b4c9950059c8ff6def9297499d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2451212
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70390}
This patch removes use of the deprecated sources_assignment_filter GN
feature from gni/proto_library.gni, since the extra descriptor files are
no longer being generated.
We also roll Perfetto to match the version used in Chrome and update
test expectations accordingly.
Bug: v8:10995
Change-Id: I65cb3b79feb6e5a7e5c8d99fdb8bf999a6048539
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454079
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70381}
This is a "minimal" change to achieve the required goal: seeing that
there is only one place where we need to indicate that memory should
be reserved with MAP_JIT, we can add a value to the Permissions enum
instead of adding a second, orthogonal parameter.
That way we avoid changing public API functions, which makes this CL
easier to undo once we have platform-independent w^x in Wasm.
Bug: chromium:1117591
Change-Id: I6333d69ab29d5900c689f08dcc892a5f1c1159b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435365
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70379}
Adds support for avoiding spills in non-deferred blocks by instead
restricting the spill ranges to deferred blocks if the virtual
register is only spilled in deferred blocks.
It does this by tracking registers that reach the exit point of deferred
blocks and spilling them them pre-emptively in the deferred block while
treating them as committed from the point of view of the non-deferred
blocks. We also now track whether virtual registers need to be spilled
at their SSA definition point (where they are output by an instruction),
or can instead be spilled at the entry to deferred blocks for use as
spill slots within those deferred blocks. In both cases, the tracking
of these deferred spills is kept as a pending operation until the
allocator confirms that adding these spills will avoid spills in the
non-deferred pathways, to avoid adding unnecessary extra spills in
deferred blocks.
BUG=v8:9684
Change-Id: Ib151e795567f0e4e7f95538415a8cc117d235b64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440603
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70374}
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}
Only implemented and tested on arm64 and interpreter.
Moved a helper function (Clamp, renamed to Saturate) into src/utils to
be able to reuse this in interpreter and tests.
Bug: v8:10971
Change-Id: Iaffcd36d27e0e8ab11e167befa96eef8e59f1c81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438990
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70360}
This CL ensures that if float parameters are unsupported for fast API
calls (which is currently the case for all platforms except x64), the
call is properly optimized to the regular TurboFan path.
Bug: chromium:1052746
Change-Id: I6dd9892d1db2b8c194c30b5d656d50ff63f03f51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2450020
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70354}
This is useful for wasm instead of keeping around a list of handles.
Change-Id: I4ef970ba191a66303c577bbe8e6ab1327aad2e24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2451209
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70353}
This CL introduces concurrent marking to the cppgc library.
The CL includes:
(*) Split MarkingState to mutator thread and concurrent thread.
(*) Split MarkingVisitor to mutator thread and concurrent thread.
(*) Introduce ConcurrentMarker for managing concurrent marking.
(*) Update unified heap to support concurrent marking as well.
See slides 13 and 14 in the following link for class hierarchies:
https://docs.google.com/presentation/d/1uDiEjJ-f1VziBKmYcvpw2gglP47M53bwj1L-P__l9QY/
Bug: chromium:1056170
Change-Id: I6530c2b21613011a612773d36fbf37416c23c5e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424348
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70352}
Add a map in {IsolateInfo} to share export wrappers across modules. Each
entry is a weak handle which uses the finalizer to remove itself from
the map after the last strong reference dies.
R=clemensb@chromium.org
Bug: chromium:862123
Change-Id: I1f3a6af6aa4c4e42abfe587354ca14f9da916d91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448465
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70348}
To support compaction of backing stores in blink, we need to distinguish
custom spaces holding backing stores from other custom spaces.
Custom space compactablity is explicitly declared as an enum value and
propagated to BaseSpace as a bool flag.
Note that even if/when general compaction is implemented/enabled for
normal pages we will still need such a marking for supporting
non-compactable custom spaces.
Bug: v8:10990
Change-Id: I165a0268ded121e91399834a4091e88e57f2565c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449973
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70345}
This reverts commit 969cdfe6b5.
Reason for revert: speculative revert for crbug.com/1135472
Original change's description:
> [heap] Convert WeakObjects to heap::base::Worklist
>
> This splits WeakObjects into explicit global and local worklists.
> The latter are defined in WeakObjects::Local and are thread-local.
>
> The main thread local worklist is stored in
> MarkCompactCollector::local_weak_objects and exists during marking
> similar to local_marking_worklists. Concurrent markers create their
> own local worklists that are published at the end.
>
> Change-Id: I093fdc580b4609ce83455b860b90a5099085beac
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440607
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70317}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: I3fa3bfdcf3c359f46a3b56c19fb4e486883cde9d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452749
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70344}
This CL adds a call counter in the WasmExportedFunctionData. The counter
is incremented every time a call to an exported WebAssembly function is
handled through the generic js-to-wasm wrapper.
Bug: v8:10982
Change-Id: Iad40b414b0c7d2f4ab340ff4ebb7b24c60b3a974
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445873
Commit-Queue: Vicky Kontoura <vkont@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70336}
This value is unused for now. This CL is part 1 of a 3-step dance.
Part 2 will be teaching Chrome's Platform implementation to accept
the new value. Part 3 will then actually use it in V8.
Bug: chromium:1117591
Change-Id: Ie3aed20d4cc58f3def3be2a3a03bba4c3a37bf44
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2450056
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70335}
This CL adds the globals index space to the JS debug proxy as well as the
stack object. It also adds few small helpers to simplify the proxy setup
a little, since all index spaces work exaclty the same.
Bug: chromium:1127914
Change-Id: I707292ab7f44aafb73751c17fdacfef976316f39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448468
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70332}
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}
Fuzzers are executed in their own process, so instead of resetting flags
after execution, we can just keep the flag values.
This CL introduces a shared function to enable all staged features,
without ever resetting the value. This fixes a data race.
R=ahaas@chromium.org
Bug: v8:10979
Change-Id: I82ea35b887841850edd8b394a3644cf8df1e3bf8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449969
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70320}
We used not to emit canonical indexes for arrays and structs into
WasmModule::signature_ids, which resulted in signature_ids not referring
to the correct type indices in a WasmModule.
Changes:
- Rename signature_ids to canonical_type_ids.
- Emit trivial canonical type ids for structs and arrays.
- Add a test to catch the existing bug.
- Improve DCHECKs for module type accessors.
Bug: v8:7748
Change-Id: I67ad58865e35b459b21db12557564b652035db75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444989
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70318}
This splits WeakObjects into explicit global and local worklists.
The latter are defined in WeakObjects::Local and are thread-local.
The main thread local worklist is stored in
MarkCompactCollector::local_weak_objects and exists during marking
similar to local_marking_worklists. Concurrent markers create their
own local worklists that are published at the end.
Change-Id: I093fdc580b4609ce83455b860b90a5099085beac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440607
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70317}
The test does not expect GC to happen while it is running
Bug: v8:10988
Change-Id: Idcd30bde4ae1a7c3386a5d8c4c46e46e839e0fe9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449971
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70316}
When debugging WebAssembly, calls to evaluateOnCallFrame always return
undefined. This CL enables evaluateOnCallFrame for WebAssembly and
creates a proxy object that is injected into the evaluation context.
Bug: chromium:1127914
Change-Id: I3f5cff3be2c9de45c7b1f3f7ed4fc2e1cc545ac6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429265
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70315}
These three wasm methods do not use the context, but were passed one:
* WasmInt32ToHeapNumber
* WasmFloat32ToNumber
* WasmFloat64ToNumber
Bug: v8:6949, v8:10933
Change-Id: I55e4264f7e06f3fb8338df77d12132c938acfcff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445934
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70314}
If we're testing printing in UTC timezone, then we have to be careful to
also input the date in UTC, else local timezone will affect the test.
Fixed: chromium:1135116
Change-Id: I49981c263e7b1fa1492b4644c5d4846fd94e5613
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448793
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70312}
This was not happening when there was no need to typecheck the entry.
Additional changes:
- Add tests with null table entries for typed and untyped function
tables.
- Allow AddIndirectFunctionTable in wasm-run-utils to specify table
type.
- Add possibility to define tables in test-gc.cc.
- Merge trapTableOutOfBounds with trapInvalidFunc.
- Use trapTableOutOfBounds in call_indirect as appropriate.
- Fix emission of table types in wasm-module-builder.cc.
Bug: v8:9495
Change-Id: I4a857ff4378e5a87dc0646d94b4c75635a43c55b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442622
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70311}
Remove the separate Initialize method from Deserializer, opting instead
to pass around SnapshotData where appropriate and pass the isolate
directly into the Deserializer's constructor.
Change-Id: I0092fadd9c81f14b2ce75145fd81af37c3947c65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448466
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70310}
We can use tag dispatching to distinguish between the synchronized and
non-synchronized accessors. Also eliminated the need of adding explicit
"synchronized" in the name when using the macros.
As a note, we currently have one case of using both relaxed and
synchronized accessors (Map::instance_descriptors).
Cleaned up:
* BytecodeArray::source_position_table
* Code::code_data_container
* Code::source_position_table
* FunctionTemplateInfo::call_code
* Map::instance_descriptors
* Map::layout_descriptor
* SharedFunctionInfo::function_data
Bug: v8:7790
Change-Id: I5a502f4b2df6addb6c45056e77061271012c7d90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424130
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70306}
Other WebAssembly tools like wabt and wasmparser ignore empty strings
for local variable and parameter names, and just generate their own
names for it. Update V8 to comply with this convention.
Bug: chromium:1134531
Change-Id: Ic724482d93398feaf6b0797eec5a55f8ca508ca5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448457
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70305}
Instead of loading the map from the feedback vector for monomorphic
access, this CL directly inlines the expected map constant as a static
check.
In case this static check fails, we call out to a builtin which performs
additional dynamic map checks.
There are several dynamic map checks performed by the builtin for various
cases such as:
(a) IC is monomorphic with a map that's different from the initial
static map that we checked, in which case we perform another dynamic
map check.
(b) IC is monomorphic but incoming map is a deprecated map in which case
we call out the runtime to migrate this incoming object to a new map and
then try to handle it.
(c) IC has now transitioned to polymorphic in which we use the old
dynamic polymorphic checks to validate the map and handler.
Bug: v8:10582, v8:9684
Change-Id: Id87265ed513e4aef87b8e66c826afbf10f50a1d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429034
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70304}
Remove the pattern of calling 'Find' followed by 'Set' for IdentityMap,
with a single 'FindOrInsert' that explicitly returns whether an existing
entry was found, or the entry was inserted. This replaces 'Get', which
would return either an initialised or uninitialised entry (and callers
would rely on default initialisation to check this).
Also replace 'Set' with 'Insert', which explicitly requires that the
element didn't exist before. This matches expectations where it was
used (where those weren't replaced wholesale with 'FindOrInsert'), and
makes the naming consistent with 'FindOrInsert'.
Change-Id: I8fb76f4ac14fb92b88474965aafb1ace5fb79145
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2443135
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70300}
Run variant stress_concurrent_allocation in debug mode and with TSAN.
Failing tests will close tree and block CQ.
Bug: v8:10315
Change-Id: I0ba2921a3718a08b88516f209364b52c8817c331
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436343
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70299}
We used to have extra data in this but now it's just an indirection to
CodeEntryAndLineNumber so use that everywhere instead.
Change-Id: I6dcedabc1502bc1eed25c05e23f04b996b91bae7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440829
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70294}
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}
It only had one callsite, and that callsite was useless:
%IsValidSmi(two_31) has never returned {true} on any
configuration we have ever shipped.
Bug: v8:10933
Change-Id: I09cdfd7bbd7960d1ec460ad4bd9f0d21e47f7393
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434746
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70285}
In construction objects don't have anything to sync with on the
allocation side since they weren't marked as fully constructed yet.
This could mean the initialization of the marking bit on the mutator
thread and setting the mark bit on a concurrent thread could race
(potentially resulting in losing the mark bit when the gc info index
overwrites it).
This CL fixes this issue by using a set of in construction objects.
In construction objects are no longer marked. Instead they are pushed
to the set and the heap object header is marked when they are popped
from the worklist. Since the set avoids duplicates, this allows us to
both avoid worklist explosion (due to pushing the same in construction
object multiple times) and avoid the data race on the mark bit.
This CL uses an unordered_set to record objects. Synchronization uses
a lock, which could be costly but is not expected to be obtained often.
Bug: chromium:1056170
Change-Id: I366b59f476c166ff06e15b280df9e846034cc6cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2437388
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70282}
This reverts commit c4a062a958.
Reason for revert: TSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33504
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=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org
Change-Id: Ib2f01db4cd9b55639d6a4af971bda865edb45e84
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1075999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445250
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70280}
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}
This CL implements passing float parameters to fast API calls by
using the existing representation conversions for double parameters
and then truncating the double to a float.
It also adds float/double tests for fast API calls.
Bug: chromium:1052746
Change-Id: Ibb3ccd173b3807a515adbf38cebaa1cf8e2784b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436333
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70277}
This is a reland of 40af6aeebf
Change from the rollbacked version
- removes the passed test fixed by this PR in test/test262/test262.status
TBR=jkummerow@chromium.org
Original change's description:
> [intl] Impl ECMA402 PR 471 rounding behavior
>
> Fix awkward rounding behavior
> Change Intl::SetNumberFormatDigitOptions to fix the awkward rounding
> behavior in NumberFormat when formatting a currency with
> "maximumFractionDigits" set to a value less than 2.
>
> Bug: v8:10844
> Change-Id: I2ff4afa9f747cd79cb9964fe4c77a0dd2b8977b5
> Refs: https://github.com/tc39/ecma402/pull/471
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442191
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70270}
Bug: v8:10844
Change-Id: Icfe7363f63d402abccc038e2b8bd78b38d0d9c49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444210
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70273}
Narrowing operations need to sign extend the result.
E.g. for narrowing uint16 to uint8, we compare uint16 to uint8 max,
0xff. The final result should be 0xffffffff (sign extended) since we
try to keep nodes in their sign extended form, to work well with
the rest of the lowering operations.
With this, we pass the last spec test (that is not ignored),
simd_conversions.
Bug: v8:10507
Change-Id: I8914fd69db9378b8244cba5dcacff98d36893649
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436613
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70272}
This reverts commit 40af6aeebf.
Reason for revert: Test262 failures, see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/2509?
Original change's description:
> [intl] Impl ECMA402 PR 471 rounding behavior
>
> Fix awkward rounding behavior
> Change Intl::SetNumberFormatDigitOptions to fix the awkward rounding
> behavior in NumberFormat when formatting a currency with
> "maximumFractionDigits" set to a value less than 2.
>
> Bug: v8:10844
> Change-Id: I2ff4afa9f747cd79cb9964fe4c77a0dd2b8977b5
> Refs: https://github.com/tc39/ecma402/pull/471
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442191
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70270}
TBR=jkummerow@chromium.org,ftang@chromium.org,syg@chromium.org
Change-Id: I1cfc05e0e2015ad18c037003c9a9a414e2151e06
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10844
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2441549
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70271}
Fix awkward rounding behavior
Change Intl::SetNumberFormatDigitOptions to fix the awkward rounding
behavior in NumberFormat when formatting a currency with
"maximumFractionDigits" set to a value less than 2.
Bug: v8:10844
Change-Id: I2ff4afa9f747cd79cb9964fe4c77a0dd2b8977b5
Refs: https://github.com/tc39/ecma402/pull/471
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442191
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70270}
This reverts commit 28a30c578c.
Reason for revert: Broke Test262 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/38638?
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=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org
Change-Id: Ieed68332ef6a7ad36db061e3f48be0f28673d7a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1075999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2441608
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70268}
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}
This adds support for injecting binding into contexts other than
main based on the context name (AKA isolated world name in Blink
terms). This would simplify a common use case for addBinding in
Puppeteer and other automation tools that use addBinding to expose
a back-channel for extension code running in an isolated world by
making bindings available to such code at an early stage and in a
race-free manner (currently, we can only inject a binding into
specific context after the creation of the context has been reported
to the client, which typically introduces a race with other evals
the client may be running in the context).
Change-Id: I66454954491a47a0c9aa4864f0aace4da2e67d3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440984
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70266}
CodeAssembler::Parameter now takes a Type template parameter and
performs a checked cast to it. There is also UncheckedParameter which
returns a TNode but doesn't check the cast. The original Parameter
method is still there as UntypedParameter.
Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the
cast is performed inside Parameter. Since Parameter is not a macro,
this means it cannot see the original expression or its file name and
line number. So the error messages are vaguely useful, Parameter<T>()
takes a SourceLocation parameter which with a default value of
SourceLocation::Current(), which at least gives us the file name and
line number for the error message.
Bug: v8:6949, v8:10933
Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70264}
Remove the runtime functionality allowing the Isolate to be allocated
4GB aligned in non-pointer-compressed builds. This was barely used in
tests, so we can remove it to give slightly stronger compile-time
guarantees about pointer-compression-only methods being used only under
pointer-compression.
Change-Id: I8eb990faa8f8499ecdcb70ca104ffad4be1437b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442790
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70262}
... when addBinding is called with contextId. Previously, due to
a subtle type, we exposed bidings added with executionContextId to
all contexts created after the binding was added.
Also, do not persist context-specific bindings to agent state,
as context ids don't make sense across the process.
This also adds a test instrastructure to create additional context in
given context group.
Change-Id: I1b3e96cb65b756424bc7872d200bbbf41e4c30b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440982
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70261}
For cross-thread handling we require the atomic marking pause to
provide an atomically consistent view of markbits and weak references.
This is ensured by locking the whole atomic pause from entering to
weak processing.
This CL move ProcessWeakness() into FinishMarking() which allows to
nicely scope the upcomming lock from EnterAtomicPause() to
LeaveAtomicPause(). The alternative is requiring the caller to ensure
proper locking which is harder than ensuring that the Marker is
consistent.
Bug: chromium:1056170
Change-Id: Ib6028a0d76fcf9422c4a0d422fec3d568f106bf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442620
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70259}
With this change, a load from memory into a register can be replaced by a memory operand for floating point binops if possible.
This eliminates one instruction for following pattern:
vmovss xmm0, m32
vmulss xmm1, xmm1, xmm0
===>
vmulss xmm1, xmm1, m32
Change-Id: I6944287fae3b7756621fb6b3d0b3db9e0beaf080
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411696
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70255}
Roll the icu to include the fix. The roll include previously
mistakenly filter out required resources.
Fix "japanese" under "ja" and calendar: "chinese" under "zh"
Depends on https://chromium-review.googlesource.com/c/chromium/deps/icu/+/2433166
This CL prepare for such landing:
1. Add test to show the correct result.
2. Wrap the number format static cast to DecimalFormat only if
the concrete class is DecimalFormat. This is needed after the landing
because the new resource enable other subclass of NumberFormat.
3. Change test to allow the additional numberingSystems.
Roll the the DEPS of chromium in
https://chromium-review.googlesource.com/c/chromium/src/+/2437820
Bug: v8:10960
Change-Id: Ib10b11862a093d1d487070f79556505bfc10bcc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432801
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70253}
Rename it to Symbolizer because it does exactly that.
Change the SymbolizeTickSample method to return the symbolized state
rather than pass it on to the ProfilesCollection. This makes it easier
to test as now it only relies on the CodeMap provided to it.
Make EntryForVMState a free-floating function as it doesn't rely on
state and then we can avoid importing the StateTag definition in the
header.
Remove the UNREACHABLE from EntryForVMState as the compiler got smarter
and doesn't need it anymore.
Pass the CpuProfilesCollection to SamplingEventsProcessor instead,
as it is now responsible for putting the symbolized samples into the
collection to be sorted into the appropriate profiles.
Change-Id: I104290eff22b7d94a1bd34ba904036badccf4e13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440522
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70248}
AST reindexing has to skip visiting fields that are already in the
member initializer, as they will have already been visited when
visiting said initializer. This is the case for private fields and
fields with computed names.
However, the reindexer was incorrectly assuming that all properties
with a FunctionLiteral value are methods (and thus not fields, and
can safely be visited). This is not the case for fields with
function expression values.
Now, we correctly use the class property's "kind" when making this
visitation decision.
Fixed: chromium:1132111
Change-Id: Ia53d1fe713453e361b818dfb0b5f88a90cecdf21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440519
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70247}
Decoding of gc/reference type instructions assumed that popping a value
from the stack would either throw an error or return a value of the
expected type. This is not true in unreachable contexts, where a
bottom-typed value can be returned.
This CL fixes this problem, adds tests which expose it, and improves
AddFunction() in the infrastructure of
function-body-decoder-unittest.cc.
Bug: v8:7748
Change-Id: I7e9d0caa9ba1687b68a5cdad7b99c054285d9f0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440577
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70246}
CodeKind::OPTIMIZED_CODE -> TURBOFAN
Kinds are now more fine-grained and distinguish between TF, TP, NCI.
CodeKind::STUB -> DEOPT_ENTRIES_OR_FOR_TESTING
Code stubs (like builtins, but generated at runtime) were removed from
the codebase years ago, this is the last remnant. This kind is used
only for deopt entries (which should be converted into builtins) and
for tests.
Change-Id: I67beb15377cb60f395e9b051b25f3e5764982e93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440335
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70234}
Array.prototype.pop() must throw a TypeError whenever the array's
length is readonly; there is no exception to that when the length
is 0. This patch moves the length==0 special case after the read-
only length check in both fast paths (CSA and C++).
Fixed: v8:10908
Change-Id: I4a77439478cffeaf11022ff8beb78b0a907290d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440576
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70233}
Sorting a TypedArray with a custom compare function requires us to
copy the array's contents to a FixedArray. When the TypedArray is
larger than FixedArray::kMaxLength, we should throw a RangeError
rather than crashing with an OOM message.
Fixed: v8:10931
Change-Id: I8a27cc0ac80a9172bc5e8e154fdf4ccce5974317
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440575
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70232}
This reverts commit 5d7a29c90e.
Reason for revert: UBSan -- https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/13100
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}
TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org
Change-Id: I2bd792a24861e8f54897e51522769b50f8f814e2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1075999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440827
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70231}
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}
Previously, unhandled promise rejections weren't reset between REPRL
executions, leading to incorrect exit statuses being reported. This CL
fixes the issue and adds further tests to verify the correct behaviour.
Change-Id: Ied47d9359b0fbc05ebb211667687a0a4041ef767
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431205
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Samuel Groß <saelo@google.com>
Cr-Commit-Position: refs/heads/master@{#70227}
As a preparation to add a "boolean validation" mode, rename the existing
flags. This removes many unrelated changes from the follow-up change and
makes it easier to review.
R=thibaudm@chromium.org
Bug: v8:10969
Change-Id: I5f71405b525a7caa91be46c035e31d4d960e4e4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440036
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70224}
Ensure that a valid off-heap trampoline is created for the
GenericJSToWasmWrapper builtin by adding it to the list of executable
builtins.
R=ahaas@chromium.org
CC=evih@chromium.org
Bug: v8:10701
Change-Id: I49b8144237aca20f5f663c7b32810a16f715ad5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438415
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70218}
Since the inspector/debugger/wasm-scope-info* tests need simd128,
but not all mips cpus support it, we skip the tests on mips
platforms without simd support.
Change-Id: Iebefa5d6b33d80d707ad0077be7d4f25e3e52b4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2439769
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70216}
Changes:
- Implement WasmExportedFunction::MatchesSignature.
- Use it over comparison with == in ResolveWasmImportCall.
- Add a test which exposes the existing bug.
- Add a few reminder TODOs.
Bug: v8:9495
Change-Id: Ibbe31dbf550be212dbf2170ab8cdab9b4b6de734
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438060
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70215}
For replacing lanes (i8x16 and i16x8) the replacement value is stored in
a word32. Simply storing it will cause us to have the wrong value, we
need to mask (for overflow) and extend appropriately.
Same for extracting, the values are stored in sign-extended form,
unsigned extracts should zero the top bits.
Bug: v8:10507
Change-Id: If5ed79f5b6bdb64f900a54b9e148b2d96a74f312
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436612
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70210}
A break may cause the session disconnect (and therefore agents destruction)
on a nested message loop. The runtime agent code is generally prepared to
handle this during evaluate, but the code outside of it may be not. Besides,
having a break before the console API installed is generally not what
user wants or expects, so just disable all breaks while installing the API.
Bug: chromium:1122487
Change-Id: I1d40f5007f2e1e4ec07a50ef57988513d0309b7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2437383
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70209}
LoadTransform operators contain a LoadKind, which can be unaligned,
protected, poisoned, normal.
If it is protected, we cannot eliminiate that load,
since we rely on the segv signal handling. So, we use partial template
specialization on LoadKind::kProtected, and don't set the operator to
not be eliminatable.
Bug: chromium:1132461
Change-Id: If45fc6562348ffd4dbaa27058e6c5d4242f79abb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436081
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70205}
This change moves external pointers into a separate table and turns
external pointers in heap objects into indices into that table.
This CL implements one of two possible ownership models for the table
entries. With this one, every heap object owns its table entries, and
they are allocated when the owning object is allocated. As such, setting
external pointer fields does not require allocation of table entries. On
the other hand, table indices cannot be shared between multiple objects.
This CL does not yet implement freeing of external pointer table
entires. This will later happen by a table garbage collector.
Bug: v8:10391
Change-Id: I4d37785295c25a7d1dcbc9871dd5887b9d788a4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235700
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Samuel Groß <saelo@google.com>
Cr-Commit-Position: refs/heads/master@{#70204}
This is the first step to support debug evaluate on wasm call frames.
This CL enables calling evaluateOnCallFrame when a wasm frame is
selected, which before always returned undefined. The CL mirrors global
evaluation, and actually enabling inspecting the wasm frame will be part
of a second change.
Bug: chromium:1127914
Change-Id: If0ad0be7c402d85ab2a8e95376398f4f4ef94948
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436338
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70198}
Functions with Simd128 in their signature will be lowered to 4 Word32.
Later for Int64 lowering, it needs to use the lowered signature.
Otherwise we will have weird parameter and signature mismatch, since it
expects Parameter[1] to be == signature()->GetParam(0).
Bug: v8:10507
Change-Id: Ia9417ecd46c1768344ed1fb3ebfe4e8dd9c3e397
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432626
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70185}
Changes:
- Add current global index argument to consume_init_expr.
- Inline DecodeGlobalInModule. Move the check for undefined global
indexes into into consume_init_expr. Note: This fixes a bug where the
index wasn't checked for nested global.get.
- Under --experimental-wasm-gc, allow global initializers to reference
already defined globals in the same module.
- Rename ModuleDecoderImpl::DecodeInitExpr -> DecodeInitExprForTesting.
Remove redundant "start" argument.
- Add tests for global initializers. Remove a redundant test.
Bug: v8:7748
Change-Id: Ieb4a768f8cfdd423e5f439bb3467700068f240b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428596
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70181}
This additionally combines --future with all other standard testing
variants.
This also enables using concurrent_marking in status files to skip
tests in this variant.
This also marks a slow test that times out in the new config.
Bug: v8:10875
Change-Id: Id904f6a2c51b814eecfccb523a897de2f5d96f56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423719
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70180}
This test likely did something in 2013 when we still had legacy const,
but now it seems like it's mostly a poor unittest of when
optimization/deoptimization happens.
Bug: v8:10933
Change-Id: Ib816e0eddf9224a4ad37096591da9032740d5e7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432313
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70178}
Control-flow aware allocation has been enabled by default for a long
time now. This removes the unused code paths related to splintering.
R=neis@chromium.org
Bug: v8:10933
Change-Id: I19d9eb448c3912b24a1ad16030e7dd556b13accc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434328
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70172}
This CL also adds some unit tests, locally tested under x64.
The double support is based on this original CL by Gus Caplan
(snek@chromium.org):
https://chromium-review.googlesource.com/c/v8/v8/+/2264612
Bug: chromium:1052746
Change-Id: Ibdf631689b01ab619a72005226bfc015b4737dde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416028
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70168}
