* Replace deprecated Factory::NewFunction* calls with JSFunctionBuilder.
* Drive-by: rename Factory::NewFunctionForTest to ..ForTesting (this is
the correct suffix recognized by our tooling to ensure it's only
called from tests).
Tbr: clemensb@chromium.org
Bug: v8:8888
Change-Id: I110063803e5b467bd91b75fe8fea2ca4174f2bcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529129
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71101}
Bug: v8:11038
Change-Id: Ia8b8c1c438d67ccfe5f27c452852c0f096062f56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2503877
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71069}
Prototype i32x4.extadd_pairwise_i16x8_{s,u} and
i16x8.extadd_pairwise_i8x16{s,u} (names not confirmed) on ARM64 and
interpreter. With a simple test case.
Bug: v8:11086
Change-Id: If1ffc04e179e86ca5cc209bf9ef9d337298e3cc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2513872
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@{#71068}
This change plumbs import assertions from SourceTextModuleDescriptor's
ModuleRequestMap into SourceTextModuleInfo via a new ModuleRequest
type, where previously there had been only the specifier.
SourceTextModuleDescriptor::module_map now deduplicates module requests
using the specifier and the import assertions. Continuing to use the
specifier alone would cause a loss of information in the event that
a module imports from the same specifier multiple times using different
sets of assertions. Failing to deduplicate at all would result in
multiple requests for statements like `import {a,b,c} from "foo.js"`,
which would be a potential performance issue. See design doc at
https://docs.google.com/document/d/1yuXgNHSbTAPubT1Mg0JXp5uTrfirkvO1g5cHHCe-LmY
for more detail on this decision.
v8::internal::ModuleRequest holds the assertions as an array of the form
[key1, value1, position1, key2, value2, assertion2, ...]. However the
parser still needs to use a map, since duplicate assertion keys need to
be detected at parse time. A follow-up change will ensure that
assertions are sorted using a proper lexicographic sort.
Bug: v8:10958
Change-Id: Iff13fb9a37d58fc1622cd3cce78925ad2b7a14bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493060
Commit-Queue: Dan Clark <daniec@microsoft.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71066}
As part of an effort to prepare the Recorder interface for general use,
we had to make some changes to the way the existing Wasm Events are
being used. In particular,
- it is more fitting to use a ElapsedTimer than a TimedScope to
measure the durations in src/wasm/module-[decoder|instantiate].cc
- we want to rename the wall_clock_time_in_us field to duration_in_us
for clarity.
Because these Wasm events are already being instantiated in chromium,
renaming the field requires a two-step change. This is the first of
those changes.
Change-Id: If1b2990f7645616a59fc21d07ac10bf00701c0e5
Bug: v8:11109
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2518619
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71053}
This is a tentative fix for the linked issue. The CL enables all
int64/uint64 tests for fast API calls on all platforms.
Bug: chromium:1144751
Change-Id: Ie892ad625257d3b0e0bdd9ac24261b3cbeaaba62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2520902
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71043}
Clean up src/wasm and test/
Bug: v8:11074
Change-Id: I1b3d3475a0fbfafe75bb49acfd851f8bd5af5182
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519183
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71025}
DecideToPretenureDuringCompilation expects a particular number of
allocation sites. So enable lazy feedback allocation always in the test.
It is possible to make the test work for --no-lazy-feedback-allocation
too, but the test already runs in a controlled environment by setting
various flags so it is OK to enable lazy feeedback allocation to keep
test simple
Bug: v8:10219
Change-Id: I8b979b6df7e7cc27299704823ab691f96abe5431
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2521591
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71000}
This cl implements tiering up support from Turboprop to TurboFan behind
turboprop_as_midtier flag. More specifically:
1. Scales down the bytecode size when updating the interrupt budget in
optimized code (TP / NCI).
2. Runtime profiler tiers up from TP->TF with --turboprop-as-midtier
3. Looks for the correct code kind when looking for optimized code in
the feedback vector.
4. After servicing the optimization marker continues with mid-tier
optimized code if it exists
Bug: v8:9684
Change-Id: Iaf5783e75555c50c97901504fd122f62ff30be5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480363
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@{#70993}
This reverts commit c3b2b64be4.
Reason for revert: Scheduled revert.
The flag flip is in 88.0.4315.0. Group report links:
https://chromeperf.appspot.com/group_report?rev=70949https://chromeperf.appspot.com/group_report?rev=823663
Original change's description:
> [nci] Enable --turbo-nci behind --future to gather perf data
>
> .. to be reverted in a day or two.
>
> Bug: v8:8888
> Change-Id: Iee156da614b50c351ca9a07cc497177c92de865d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512907
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Lutz Vahl <vahl@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70949}
TBR=machenbach@chromium.org,jgruber@chromium.org,vahl@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8888,v8:11087
Change-Id: I57411474d885dd69613a85f5fa3a801a573fcd08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2517690
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70982}
Add a new function on the public API to allow serializing a function to
a string using the built-in toString() implementation, allowing
serialization without worrying about untrusted author script overriding
the toString() implementation. This is similar in nature to
Object::ObjectProtoToString() (but that only returns "[object Function]"
for any passed function).
Add tests for the same.
Bug: chromium:1144841
Change-Id: Ie4c29b870034c0817c23bf91f9424f956098823d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2514768
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70976}
ICU68-1 change the output skeleton format. So we need to change
resolvedOptions code for 68 migration.
Chromium roll
https://chromium-review.googlesource.com/c/chromium/src/+/2474093
Bug: v8:10945
Change-Id: I3b2c7fbe8abb22df8fa51287c498ca3245b8c55b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477431
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70972}
Rename-only CL: Rename "code kind" to "code like".
The reason is CL feedback when using this feature, and a desire for
consistency across V8 + Blink. An additional benefit would be to
disambiguate from the v8::internal::CodeKind type, which is unrelated to
any of this.
Original CL: crrev.com/c/v8/v8/+/2339618
CL whose review prompted this change: crrev.com/c/2340905
Bug: chromium:1096017
Change-Id: Id59016fc2906ab6cd1414e598338b3963811b92f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509598
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70970}
Timeouts occurred in test-concurrent-feedback-vector/CheckLoadICStates
because the main thread could enter "handshaking" mode precisely at
the moment when the worker thread successfully saw all states.
The main thread would miss this, and end up waiting forever on
a signal from the worker thread.
Bug: v8:11082
Change-Id: I0441785d908c5e27562a3620bb2195483727f118
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519553
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70962}
Currently MockPlatform has shorter lifetime than the isolate that uses
it. Creating isolate before MockPlatform leads to races in concurrent
tasks that were scheduled before the MockPlatform replaced the default
TestPlatform. This caused issues after landing
https://chromium-review.googlesource.com/c/v8/v8/+/2502808
This CL ensures that MockPlatform is valid throughout the whole
lifetime of the isolate
Change-Id: Ia888fba93819ea98b935a1d36307d98dd358fcad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507379
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70950}
.. to be reverted in a day or two.
Bug: v8:8888
Change-Id: Iee156da614b50c351ca9a07cc497177c92de865d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512907
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Lutz Vahl <vahl@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70949}
Concurrent allocation test was failing flakily. Do not fix this simply
by increasing heap size since this would reduce frequency of GCs.
Instead allow allocations to fail. Even in this case the allocation
code path is still executed which we want to test.
Bug: v8:11084, v8:10315
Change-Id: I0daa9ad9177aab8b02b7decf2ccfd50e0d8ab9b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2516471
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70946}
Minor refactors to improve readability and consistency between
FeedbackVectorSpec and FeedbackMetadata:
- Rename FeedbackVectorSpec::slots to slot_count.
- Rename FeedbackVectorSpec::closure_feedback_cells to
create_closure_slot_count, likewise all related fields.
- Store FeedbackVectorSpec::slot_kinds_ as an array of
FeedbackSlotKind.
Bug: v8:8888
Change-Id: I3a45177163d1484b1625de8dfba5c6c05cfc426d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512908
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70943}
IWYU some headers, remove/inline helpers that were only used once.
Bug: v8:11074
Change-Id: I3e3d7e22b56e77076f1a2faac07ca727fb6e4f46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2513871
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70931}
Remove the duplicate utility function and use the base::Stack
equivalent instead which provides more stack utilitiy functionality.
Change-Id: Ia7a79f2530b64ceb6e2ce33445c876980b4b2a3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509595
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70930}
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}
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}
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}
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}
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}
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}
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}
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 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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
This changes OrderedHashMap, OrderedHashSet, and OrderedNameDictionary
as follows:
- Create a dedicated allocation function AllocateEmpty to create zero-
element instances of these classes
- Fix bugs resulting from using these zero-element versions
Further, this CL
- provides a canonical empty versions of OrderedNameDictionary
- changes the types of the canonical ordered hash table and hash set
from FixedArray to the actual subclasses
Bug: v8:7569
Change-Id: I0fe1215e7d164617afa777c8b3208a0857ab6edd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476315
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70604}
This 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}
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}
... 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}
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 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}
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}
"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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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 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}
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}
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}
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}
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}
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}
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 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}
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}
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}
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}
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}
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 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}
These tests were incorrectly declaring the number of parameters the
generated function would take by omitting the receiver and
PopAndReturnVariable was accessing the wrong parameter.
Also updated a passed in parameter to not match the constant that was
being returned in case that led to the test passing accidentally.
Bug: v8:10933
Change-Id: Ia354e4e30b464a333039ab6bc54198acd16a4789
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434334
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70157}
Fixes test-torque/TestBitFieldStore to read the Smi parameter passed in
rather than the receiver which was always the global object.
Change-Id: Ie6b343ad7ef9393c211b0e7c8e1b7c1427e0aeb4
Bug: v8:10933
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434327
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70154}
When an Isolate in a multi-threaded environment is being debugged
and a thread does a Step Over (StepNext internally) one-shot
breaks are created in the code at the stack frame where the
StepNext occurred. However, if the stepped-over statement had
a function call and the called function (or some function that
it called) unlocked the Isolate (via a C++ function call) and
another thread then locked the Isolate, an ArchiveDebug would
be done which would save the fact that a StepNext is active and
the call frame depth of the StepNext. The one-shot breaks would
then be cleared to avoid stopping the now running thread.
When the original thread that did the StepNext relocks the Isolate,
a RestoreDebug is done which, seeing that a StepNext was active
calls PrepareDebug which assumes that the StepNext must be for
the current JS frame which is usually correct, but not in this
case. This results in the StepNext break actually occurring in the
function that called the C++ function not in the function where
the StepNext was originally done. In addition, the function where
the break now happens must necessarily be deoptimized if
optimized, and debug code and a source map table created if one
doesn't already exists though this is largely invisible to the
user.
Occasionally, a crash/core dump also occurs because the stack
guard is restored after the debugging environment is restored in
the RestoreThread code which can prevent the compiler from being
called to generate the source map table (for the incorrect
function) since the stack guard is another thread's stack guard,
and so might appear that the stack guard has been gone past so
the compiler is not called, resulting in there being no source
map table. But PrepareStep ends up calling the BreakIterator
(via the DebugInfo constructor) which assumes there is a source
map table so we get a crash.
The fix is to have PrepareStep to skip to the frame where the
StepNext was done before doing its thing. Since the only
PrepareStepcaller that requires a frame other than the current
frame, is RestoreDebug, a target frame parameter was added to
PrepareStep that's set by RestoreDebug and defaults to -1
indicating to use the current frame for all other callers.
While this made the order of the debug environment and stack
guard no longer cause an obvious problem, it still felt wrong
to defer restoration of the stack guard until after something
as potentially complex as PrepareStep might be called, so the
order of RestoreDebug and RestoreStackGuard calls were reversed.
Bug: v8:10902
Change-Id: I174e254e72414c827e113aec142f1d329ebe73d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2405932
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70152}
This fixes the logic in the desugaring of destructuring assignments. In
particular, a spread element would not check if previous `next` results
had already been done, and would always call `next()` again.
Change-Id: I1bd384678722e6cf51c5777fc3b0dd965360291a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2430488
Commit-Queue: Gus Caplan <snek@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70144}
These instructions were changed from "s8x16" to "i8x16" prefixes in
https://github.com/WebAssembly/simd/pull/321.
This CL updates all V8 code, including arch-specific code, to match.
Bug: v8:10946, v8:10933
Change-Id: I26ef9ad77571f94501d42c1d65f57380fd507f3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432068
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70143}
This is a reland of 64caf2b0b2
Original change's description:
> [torque] refactor: use -tq only in filenames derived from .tq files
>
> This is to establish a naming rule for Torque-generated files:
> - If the file is called foo/bar-tq..., then it is derived from a
> file foo/bar.tq
> - Otherwise it doesn't belong to a specific .tq file.
>
> So far, we attached -tq to all Torque-generated file names, where it
> sometimes corresponded to a .tq file name and sometimes not.
> It is not necessary to add -tq to file names to indicate that they are
> Torque-generated, since they are already in a directory called
> torque-generated, and we always refer to them as
> "torque-generated/filename", so there is no confusion even though some
> files now have the same name as a corresponding hand-written file, for
> example factory.cc.
>
> TBR: hpayer@chromium.org
> Bug: v8:7793
> Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70060}
Bug: v8:7793
TBR: hpayer@chromium.orgjgruber@chromium.org
Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70137}
f32x4->16x8, 64x2->8x16, and 16x8->8x16.
This allows us to pass more spec tests.
Bug: v8:10507
Change-Id: I1810ce2d17f93529b2e69cf5c767cb7b480b4b49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429807
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70128}
On ppc64 and s390x, Liftoff is not implemented yet, so if a Liftoff
compilation unit finishes after all top-tier units (hence after the "top
tier finished" callback), it will still increase the turbofan counter.
R=clemensb@chromium.org, ecmziegler@chromium.org
Bug: chromium:1092417
Change-Id: I0b99061f26851288f1abb8fcc3a30ca92a55164e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429564
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70123}
This test checks SizeOfObjects after GC, but there might be concurrent
allocations in-between.
Bug: v8:10315
Change-Id: Id904c8865e44ac5c3b486ff6f1316e536cf20e9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428864
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70122}
Make sure that tests grow the new space in a safepoint. This fixes
races with concurrent allocation.
Bug: v8:10315
Change-Id: I6fce6740bc3c9385f18bbbcde4b06ba881a03635
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428946
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70120}
Avoid data race by only setting FLAG_local_heaps to true if not
already enabled.
Bug: v8:10315
Change-Id: Ib562b6d525448f5c088da39bf60928debd97db43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426610
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70115}
Ensure that events are triggered when a module is decoded, compiled,
instantiated and tiered-up.
This is a reland of Ib5883a338c3756c6f3488fbdd7b6861ecc2ba218.
R=clemensb@chromium.orgTBR=adamk@chromium.org
Bug: chromium:1092417
Change-Id: I803ae3db23a5f71f26e8ec118251eccdfc551353
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2425056
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70113}
Use Global instead of Persistent such that GlobalHandle is reset at the
end of the function. Persistent doesn't reset in the destructor,
which means that the GC resets the GlobalHandle. With
--stress-concurrent-allocation this might not happen in the test
function itself but when the cctest framework itself works through
the event queue. At that point the Persistent isn't live anymore.
Bug: v8:10315
Change-Id: If77388ad5acb80538852beca0ab22a4ebaf0b5c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426612
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70111}
This is a first small step for implementing the memory64 proposal:
1. Add a feature flag.
2. Add the 0x04 and 0x05 limits flag for memory64.
3. Read memory limits as LEB-encoded u64 (instead of u32) if a memory64
limit flag was read.
4. Unify {MaximumFlag} and {MemoryFlag}, which was used inconsistently
before.
5. Add test for memory limits encoded with >5 bytes.
6. Move some macros from module-decoder-unittest.cc to wasm-macro-gen.h.
Note that still the same limits for the maximum number of pages applies
as before, i.e. you cannot specify a memory >4GB yet. But you can encode
that small number in >5 bytes.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I90a4f08426ae714a67440281785eb00cfc24a349
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423712
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70110}
Add lowering for F64x2 in S128Const and converting to and from f64x2.
Bug: v8:10507
Change-Id: Ic2c4f1f41d3dd804e012a943391a46b534864b51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424679
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70097}
Ensure that events are triggered when a module is decoded, compiled,
instantiated and tiered-up.
This is a reland of I9dc87957fc03023c5ab1c4f49e865957c8324e1a.
R=clemensb@chromium.org
Bug: chromium:1092417
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: Ib5883a338c3756c6f3488fbdd7b6861ecc2ba218
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2367866
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70074}
Load and zero extend is still in prototype phase [0], implementing for ARM64 in
order to get more benchmark results.
[0] https://github.com/WebAssembly/simd/pull/237
Bug: v8:10713
Change-Id: I7d632324e4bdb0934ab024911201a06b19a1a83d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416407
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70069}
This reverts commit 64caf2b0b2.
Reason for revert: Seems to be causing a failure:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
Original change's description:
> [torque] refactor: use -tq only in filenames derived from .tq files
>
> This is to establish a naming rule for Torque-generated files:
> - If the file is called foo/bar-tq..., then it is derived from a
> file foo/bar.tq
> - Otherwise it doesn't belong to a specific .tq file.
>
> So far, we attached -tq to all Torque-generated file names, where it
> sometimes corresponded to a .tq file name and sometimes not.
> It is not necessary to add -tq to file names to indicate that they are
> Torque-generated, since they are already in a directory called
> torque-generated, and we always refer to them as
> "torque-generated/filename", so there is no confusion even though some
> files now have the same name as a corresponding hand-written file, for
> example factory.cc.
>
> TBR: hpayer@chromium.org
> Bug: v8:7793
> Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70060}
TBR=jgruber@chromium.org,tebbi@chromium.org
Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70065}
This is to establish a naming rule for Torque-generated files:
- If the file is called foo/bar-tq..., then it is derived from a
file foo/bar.tq
- Otherwise it doesn't belong to a specific .tq file.
So far, we attached -tq to all Torque-generated file names, where it
sometimes corresponded to a .tq file name and sometimes not.
It is not necessary to add -tq to file names to indicate that they are
Torque-generated, since they are already in a directory called
torque-generated, and we always refer to them as
"torque-generated/filename", so there is no confusion even though some
files now have the same name as a corresponding hand-written file, for
example factory.cc.
TBR: hpayer@chromium.org
Bug: v8:7793
Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70060}
Otherwise concurrent allocation might start incremental marking, which
would then mark the global handle.
Bug: v8:10315
Change-Id: Ibc681b001847a7c52e9fd8a0420e42a0d0ecfbda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424004
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70054}
This reverts commit 4a2b2b2e56.
Reason for revert: Speculative revert due to https://ci.chromium.org/p/chromium/builders/try/linux-rel/495075?
Original change's description:
> [Heap]: Marking use Jobs.
>
> StopRequest is removed in favor of:
> COMPLETE_TASKS_FOR_TESTING -> JoinForTesting()
> PREEMPT_TASKS -> Pause()
> COMPLETE_ONGOING_TASKS now has the same behavior as PREEMPT_TASKS
> - we should avoid waiting on the main thread as much as possible.
>
> Change-Id: Icceeb4f0c0fda2ed234b2f26fe308b11410fcfb7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376166
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70037}
TBR=ulan@chromium.org,etiennep@chromium.org
Change-Id: I63f24bffa0f56c6ffa1d1977fc4fb8a76b6f3ba2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423722
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70049}
Added scopes to diallow/allow GCs from happening using a DCHECK. It is
stricter than DisallowHeapAllocation, since this also doesn't allow
safepoints.
As soon as Turbofan is ready, we can replace all usages of
DisallowHeapAllocation with DisallowGarbageCollection.
Bug: v8:10315
Change-Id: I12c144ec099d9af57d692ff343adbe7aec46c0c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362960
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70042}
Building and running tests with v8_enabled_concurrent_marking=false
currently produces two failures:
1) Segmentation fault on attempt to mark a read-only object.
This is fixed by changing MarkBit::Set to be a no-op if the object
is already marked (which is the case for the readonly space).
2) Missing write-barrier due to bogus condition in the bailout.
The barrier can be skipped only if the host object is not marked yet.
This also disables two concurrent allocation tests that rely on
concurrent marking write-barrier.
Bug: v8:10875
Change-Id: Ib3a238fc34c8f20c697470e0bd4ac427fb4bdc0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421816
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70041}
StopRequest is removed in favor of:
COMPLETE_TASKS_FOR_TESTING -> JoinForTesting()
PREEMPT_TASKS -> Pause()
COMPLETE_ONGOING_TASKS now has the same behavior as PREEMPT_TASKS
- we should avoid waiting on the main thread as much as possible.
Change-Id: Icceeb4f0c0fda2ed234b2f26fe308b11410fcfb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376166
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70037}
Avoid resetting log flags as this could cause data races with
allocating background threads.
Bug: v8:10315
Change-Id: I7be01ff54e349652f182b944ed3f3366d1239ad7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421814
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70036}
Test was asserting heap size before and after GC. With background
thread allocation those assertions might not hold.
Bug: v8:10315
Change-Id: I4f8c0f6d0b80040b3c89f85e801416abb29ed30e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421999
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70034}
Assertions are implemented with the new ASSERTION instruction. The nfa
interpreter evaluates the assertion based on the current context in the
subject string every time a thread executes ASSERTION. This is
analogous to what re2 and rust/regex do.
Alternatives to this approach:
- The interpreter could calculate eagerly for all assertion types
whether they are satisfied whenever the current input position is
advanced. This would make evaluating the ASSERTION instruction itself
cheaper, but at the cost of making every advance in the input string
more expensive. I suspect this would be slower on average because
assertions are not that common that we typically evaluate >= 2
assertions at every input position.
- Assertions in a regexp could be desugared into CONSUME_RANGE
instructions, so that no new instruction would be necessary. For
example, the word boundary assertion \b is satisfied at a given
position/state if we have just consumed a word character and will
consume a non-word character next, or vice-versa. The tricky part
about this is that the assertion itself should not consume input, so
we'd have to split (automaton) states according to whether we've
arrived at them via a word character or not. The current compiler is
not really equipped for this kind of transformation. For {start,end}
of {line,file} assertions, we'd need to introduce dummy characters
indicating start/end of input (say, 0x10000 and 0x10001) which we feed
to the interpreter before respectively after the actual input.
I suspect that this approach wouldn't make much of a difference for
NFA execution. It would likely speed up (lazy) DFA execution though
because assertions would be dealt with in the fast path.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: Ic2012c943e0ce54eb8662789fb3d4c1b6cd8d606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398644
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70026}
When a compaction space allocates a new code page, that pages needs to
be added to the Isolate::code_pages_ array used for stack unwinding.
Since the array is owned by the main thread, compaction thread cannot
directly modify it. Because of that code pages are added upon merging
of the compaction space to the main space in MergeLocalSpace.
The bug was that all code pages coming from the compaction space
were added to the code_pages_ array. However, some of the pages are
not newly allocated but merely borrowed from the main space.
This CL keeps track of all newly allocated paged by a compaction space.
Bug: v8:10900
Change-Id: Iff3ff5d608df60fb752d2e0ffc29e51f2d967936
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418718
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70023}
Since the flag is enabled by default, it is more useful to have the
reverse implications so that disabling the flag is guaranteed to work.
Bug: v8:10315
Change-Id: I191c35682442925f3fed691460d074ba6715fc99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2409498
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70022}
For js frame, we want to display currently executing function.
Change-Id: If33b04279dafdf6e4834bfb6c7240e8e7e799fc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411483
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70018}
Changes:
- Rename IsSignatureEqual -> MatchesSignature for consistency
- Add WasmInstanceObject field to WasmTableObject.
- Improve some error messages related to tables in
function-body-decoder-impl.h.
- Introduce WasmTable::IsValidTableType. Use it wherever appropriate.
- Overload equality operators in HeapType to work with
HeapType::Representation.
- Rename DynamicTypeCheckRef -> TypecheckJSObject.
- Handle WasmCapiFunctions in TypecheckJSObject.
- Use TypecheckJSObject in WasmTableObject::IsValidElement.
- A few more minor improvements.
Bug: v8:9495
Change-Id: I2867dd3486d7c31717ac26b87a50e15cf2b898be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416491
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70001}
This reverts commit 8b60d8fcbf.
Reason for revert: Flaky on windows: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/27302
Original change's description:
> Reland "[cpu-profiler] Log OSR code when starting the profiler"
>
> This is a reland of f696528189
>
> Updated the test:
> 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 by 50% to make sure
> we have a big enough difference.
>
> With 1000 iterations I didn't see any flakes locally so this looks solid
> now.
>
> Original change's description:
> > [cpu-profiler] Log OSR code when starting the profiler
> >
> > OSR code doesn't hang off any JSFunction or SFI, so we missed it when
> > starting up the profiler. This meant we didn't properly attribute
> > ticks to SFI code. The ticks ended up going to the caller instead.
> >
> > There is a weak cache of OSR code per native context, so iterate that
> > on profiler startup and log all the code objects.
> >
> > Change-Id: I2e9738b86a488b37f36ac89803561607dc76f745
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414216
> > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Mythri Alle <mythria@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69964}
>
> Change-Id: Ib506e88b546008e462967259763bbf985b74b462
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418092
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69990}
TBR=mythria@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org
Change-Id: Ie3272c4fd297ca6f10a47c3fe8826e226a9f0545
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418714
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69999}
This reverts commit af5f437cd9.
Reason for revert: Seems to break TSAN - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33286?
Original change's description:
> [heap] Fix tracking of code pages for V8 stack unwinder
>
> When a compaction space allocates a new code page, that pages needs to
> be added to the Isolate::code_pages_ array used for stack unwinding.
> Since the array is owned by the main thread, compaction thread cannot
> directly modify it. Because of that code pages are added upon merging
> of the compaction space to the main spage in MergeLocalSpace.
>
> The bug was that all code pages coming from the compaction space
> were added to the code_pages_ array. However, some of the pages are
> not newly allocated but merely borrowed from the main space.
>
> This CL introduces a new page flag for marking pages that are borrowed
> during compaction and skips them in MergeLocalSpace.
>
> Bug: v8:10900
> Change-Id: I786dc5747bd7c785ae58dfd8b841c00774efb15e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416500
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69992}
TBR=ulan@chromium.org,jkummerow@chromium.org,dinfuehr@chromium.org
Change-Id: I13f8b64014750af95423166152dc9bee8cec12d0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418395
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69993}
When a compaction space allocates a new code page, that pages needs to
be added to the Isolate::code_pages_ array used for stack unwinding.
Since the array is owned by the main thread, compaction thread cannot
directly modify it. Because of that code pages are added upon merging
of the compaction space to the main spage in MergeLocalSpace.
The bug was that all code pages coming from the compaction space
were added to the code_pages_ array. However, some of the pages are
not newly allocated but merely borrowed from the main space.
This CL introduces a new page flag for marking pages that are borrowed
during compaction and skips them in MergeLocalSpace.
Bug: v8:10900
Change-Id: I786dc5747bd7c785ae58dfd8b841c00774efb15e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416500
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69992}
This is a reland of f696528189
Updated the test:
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 by 50% to make sure
we have a big enough difference.
With 1000 iterations I didn't see any flakes locally so this looks solid
now.
Original change's description:
> [cpu-profiler] Log OSR code when starting the profiler
>
> OSR code doesn't hang off any JSFunction or SFI, so we missed it when
> starting up the profiler. This meant we didn't properly attribute
> ticks to SFI code. The ticks ended up going to the caller instead.
>
> There is a weak cache of OSR code per native context, so iterate that
> on profiler startup and log all the code objects.
>
> Change-Id: I2e9738b86a488b37f36ac89803561607dc76f745
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414216
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69964}
Change-Id: Ib506e88b546008e462967259763bbf985b74b462
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418092
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69990}
