On x64, trap handlers are enabled as part of the default configuration.
However, each embedder has to enable trap handlers explicitly, and in
the wasm fuzzers, trap handlers were not enabled. This CL enables trap
handlers now in all wasm fuzzers.
Drive-by change: enable all staged wasm features in the wasm-async
fuzzer.
R=clemensb@chromium.org
Change-Id: Ib7c2addb092551b5554a2b74830e5b67db077909
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362957
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69500}
Load extends always load 8 bytes, so the access size does not depend on
MachineType of the load. The MachineType is used for classifying the
lane shape of the 8-byte load.
Also add cctest to load splats and load extends to test OOB. (Note that
load splats access size depends on MachineType).
Add regression test from clusterfuzz, minimized by ahaas@. Remove the
`--no-wasm-trap-handler` flag since we have a no_wasm_traps variant that
should test this flag.
Bug: chromium:1116019
Change-Id: I27ba051d0536ca0f6fd75dd641ca9b78132dafed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363291
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69489}
This CL adds a basic implementation of incremental marking for standalone GC.
Followup CLs include:
* Use bytes instead of time as deadline
* Port incremental marking schedule from blink
* Mark on allocation
* Guarantees for progres/termination for standalone GC
* etc...
Calling StartIncrementalGarbageCollection triggers StartMarking which
schedules incremental marking as non-nestable tasks.
For unified heap, marking will continue running until it runs out of
work but it won't finalize independently.
For standalone, when incremental runs out of work it will schedule a new
task in which it will finalize marking and trigger the rest of the GC.
Users of standalone can also force finalization before incremental
marking as finished using FinalizeIncrementalGarbageCollectionIfRunning.
Calling CollectGarbage would also finalize an on-going incremental GC
if one exists. Otherwise it will trigger an atomic GC.
See the following doc for explanation of the various methods:
https://docs.google.com/document/d/1ZhJY2fOoD8sH53ZxMh2927Zl8sXqA7azJgcQTWx-YKs/edit?usp=sharing
Bug: chromium:1056170
Change-Id: I75ead414eb9da9f8b7f71c4638b9830fce7708ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298009
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69480}
When CFI is enabled this adds a check against this list whenever a new
return address must be set in a deoptimized frame, as a mitigation for
ROP attacks.
The list is known at linking time so that its content and the pointer
to it can be stored in a read-only memory section.
The check is performed in the signing function, which is no longer
generic, as well as when setting the current pc of the frame.
Since the pc is now only signed when setting the caller's pc, there
is no need for ReplaceContext anymore.
Bug: v8:10026
Change-Id: I5e85a62b94722051716fdeba476db383c702a318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287490
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
Cr-Commit-Position: refs/heads/master@{#69478}
... to avoid the repeated pattern of calculating it.
Bug: v8:8888
Change-Id: I4af5264aae6cfb8b6232b5aaf9ceb2cb568c29d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362692
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69469}
The V8 wasm fuzzer can create regression tests for failing fuzzer cases.
These regression tests use the wasm-module-builder.js. With the addition
of simd to the wasm-compile-fuzzer, the fuzzer can now create test cases
that use simd instructions, but the wasm-module-builder.js did not know
yet about the new instructions. This CL adds some instructions to
wasm-module-builder.js.
R=zhin@chromium.org
Bug: chromium:1116019
Change-Id: I198e4f11c2225a65d6b438f95e351fc14ee66218
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362694
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69467}
Port 2547e1cece
Original Commit Message:
Since the compilation progress was never initialized on deserialization,
tier down was always skipped on such modules.
By initializing to the expected state after deserialization (i.e. all
code as TurboFan code), we make sure that later recompilation works as
expected.
R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Iab66ca0d1bfb36cfee56ccd85720d4c5552eb9c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363270
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69465}
There exists such optimization for additions but not for multiplication.
This adds optimizations that apply the reductions
(x * Int32Constant(a)) * Int32Constant(b)) => x * Int32Constant(a * b)
(x * Int64Constant(a)) * Int64Constant(b)) => x * Int64Constant(a * b)
to the TurboFan graph.
Bug: v8:10305
Change-Id: I28f72c2b7d8ff0f758a0a08b69fb3763557a6241
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360327
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69462}
Since the compilation progress was never initialized on deserialization,
tier down was always skipped on such modules.
By initializing to the expected state after deserialization (i.e. all
code as TurboFan code), we make sure that later recompilation works as
expected.
Drive-by: Fix an unnecessary copy of a {shared_ptr} in deserialization.
R=thibaudm@chromium.org
Bug: chromium:1110258
Change-Id: Ia12af888e4b11aabfb8cd4e1201e9fa3cd2ceb47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323355
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69458}
This reverts commit 1dd7f3a953.
Reason for revert: Breaks TSAN - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/32846?
Original change's description:
> [heap] Add concurrent marking write barrier
>
> A LocalHeap creates and owns an instance of MarkingBarrier. A pointer to
> the marking barrier is set to a thread_local variable for a quick access.
>
> WriteBarrier::MarkingSlow fetches the thread_local variable and invokes
> the write barrier if it is set. Otherwise, it invokes the main thread
> heap()->marking_barrier().
>
> Each marking barrier has its own local marking worklist that is
> published during scavenge (for updating pointers) and at finalization
> of incremental marking.
>
> Typed-slot recording does not work yet because it is not thread-safe.
> It will be fixed in a subsequent CL.
>
> Bug: v8:10315
> Change-Id: I221a906436cd91e7405a253ce0eb06cf68046f2c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354809
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69448}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: I9719d565aaa313cd23f5e759dcef1246f475eb46
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362689
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69451}
A LocalHeap creates and owns an instance of MarkingBarrier. A pointer to
the marking barrier is set to a thread_local variable for a quick access.
WriteBarrier::MarkingSlow fetches the thread_local variable and invokes
the write barrier if it is set. Otherwise, it invokes the main thread
heap()->marking_barrier().
Each marking barrier has its own local marking worklist that is
published during scavenge (for updating pointers) and at finalization
of incremental marking.
Typed-slot recording does not work yet because it is not thread-safe.
It will be fixed in a subsequent CL.
Bug: v8:10315
Change-Id: I221a906436cd91e7405a253ce0eb06cf68046f2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354809
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69448}
GC support works for the current 0 and 1 param version
of the wrapper.
Bug: v8:10701
Change-Id: I9e3822b1481223c44050d23ddee7293936f1e6d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351673
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69447}
This is a reland of 899cb34868.
The new fuzzer regression test is skipped in jitless.
Original change's description:
> [wasm][fuzzer] Fix exception detection
>
> Exceptions were detected by checking for a pending exception on the
> isolate, but {CallWasmFunctionForTesting} was clearing any pending
> exception before returning.
> This CL fixes that by explicitly passing back a boolean which is set if
> an exception occurred during execution.
>
> R=ahaas@chromium.org
>
> Bug: chromium:1115280
> Change-Id: Ife71ceef0751d18e0870335b9520c2bf77e351cc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352787
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69404}
Bug: chromium:1115280
Change-Id: I9bb7300d423c53214e51e61233b0a6b09a21fd97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2361464
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69446}
Instead of forcing GC right away, the function now post a task and
performance GC from the task with an empty stack to avoid false positive
pointers in conservative stack scanning.
Bug: chromium:1098187
Change-Id: I88864845a1e395056c5d5f6e867ad774b87dbb6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2307217
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69444}
This adds the new JsRegExp::Type EXPERIMENTAL, which should eventually
be implemented with the algorithm based on automata. Currently the new
engine deals with plain search strings only, i.e. regexps that do not
contain operators or escape sequences.
R=jgruber@chromium.org
Bug: v8:10765
Change-Id: I6a10d9cdf4605d219dbe7cc1989df3bfa7349ff8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339094
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69442}
Starting the task right on NotifyDeserializationComplete() turned out
to be too early for some tests. So let an AllocationObserver start
the stress allocation after deserialization is finished.
Bug: v8:10315
Change-Id: I00a4294add5ec87074f9e775c602b3031cc16d58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358735
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69441}
In Liftoff, we were missing kS128 cases to load to/from stack.
For the x64 and ARM64 instruction selector, the calculation of
reverse_slot is incorrect for 128-bit values:
- reverse_slot += 2 (size of 128-bit values, 2 pointers)
- this copies from slot -2 into register
- but the value starts at slot -1, it occupies slots -1 and -2
- we end up copying slot -2 (most significant half) of the register, and
also slot -3, which is where rsi was store (Wasm instance addr)
- the test ends up with a different result every time
The calculation of reverse_slot is changed to follow how ia32 and ARM
does it, which is to start with
- reverse_slot = 0
- in the code-generator, add 1 to the slot
- then after emitting Peek operation, reverse_slot += 2
The fixes for x64 and ARM64 are in both instruction-selector and
code-generator.
ia32 and ARM didn't support writing kSimd128 values yet, it was only a
missing check in code-generator, so add that in.
For ARM, the codegen is more involved, vld1 does not support addressing
with an offset, so we have to do the addition into a scratch register.
Also adding a test for returning multiple v128. V128 is not exposed to
JavaScript, so we use a Wasm function call, and then an involved chain
of extract lanes, returning 6 i32 which we verify the values of. It
extracts the first and last lane of the i32x4 value in order to catch
bugs where we write or read to a wrong stack slot (off by 1).
The simd-scalar-lowering for kCall was only handling single s128 return,
we adopt the way i64-lowering handles kCall, so that is can now handle
any kinds of calls with s128 in the descriptor.
Bug: v8:10794
Bug: chromium:1115230
Change-Id: I2ccdd55f6292bc5794be78053b27e14da8cce70e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2355189
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69439}
This reverts commit dc18b82221.
Reason for revert: still causing failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/31566
Original change's description:
> Reland^3 "[flags] warn about contradictory flags"
>
> This is a reland of 0ba115e6a9
> Changes:
> - Also allow second parameter influenced by --cache to be reassigned.
> - Fix --stress-opt to only --always-opt in the last iteration as before.
>
> Original change's description:
> > Reland^2 "[flags] warn about contradictory flags"
> >
> > This is a reland of d8f8a7e210
> > Change compared to last reland:
> > - Do not check for d8 flag contradictions in the presence of --fuzzing
> > - Allow identical re-declaration of --cache=*
> >
> > Original change's description:
> > > Reland "[flags] warn about contradictory flags"
> > >
> > > This is a reland of b8f9166664
> > > Difference to previous CL: Additional functionality to specify
> > > incompatible flags based on GN variables and extra-flags, used
> > > to fix the issues that came up on the waterfall.
> > >
> > > This also changes the rules regarding repeated flags: While
> > > explicitly repeated flags are allowed for boolean values as long
> > > as they are identical, repeated flags or explicit flags in the
> > > presence of an active implication are disallowed for non-boolean
> > > flags. The latter simplifies specifying conflict rules in
> > > variants.py. Otherwise a rule like
> > >
> > > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > > "--gc-interval=*": ["--gc-interval=*"],
> > > }
> > >
> > > wouldn't work because specifying the same GC interval twice
> > > wouldn't actually count as a conflict. This was an issue with
> > > test/mjsunit/wasm/gc-buffer.js, which specifies
> > > --gc-interval=500 exactly like the extra flag by the stress bot.
> > >
> > > Also, this now expands contradictory flags checking to d8 flags
> > > for consistency.
> > >
> > > Original change's description:
> > > > [flags] warn about contradictory flags
> > > >
> > > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > > >
> > > > Bug: v8:10577
> > > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#68168}
> > >
> > > Bug: v8:10577
> > > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68989}
> >
> > Bug: v8:10577
> > Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69339}
>
> Bug: v8:10577
> 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: I4a69dc57a102782cb453144323e3752ac8278624
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69433}
TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
Change-Id: I4ccdd7b931d0ddccbcec1d6cfae8d4874ee49cfc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10577
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/+/2360414
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69438}
This is a reland of 0ba115e6a9
Changes:
- Also allow second parameter influenced by --cache to be reassigned.
- Fix --stress-opt to only --always-opt in the last iteration as before.
Original change's description:
> Reland^2 "[flags] warn about contradictory flags"
>
> This is a reland of d8f8a7e210
> Change compared to last reland:
> - Do not check for d8 flag contradictions in the presence of --fuzzing
> - Allow identical re-declaration of --cache=*
>
> Original change's description:
> > Reland "[flags] warn about contradictory flags"
> >
> > This is a reland of b8f9166664
> > Difference to previous CL: Additional functionality to specify
> > incompatible flags based on GN variables and extra-flags, used
> > to fix the issues that came up on the waterfall.
> >
> > This also changes the rules regarding repeated flags: While
> > explicitly repeated flags are allowed for boolean values as long
> > as they are identical, repeated flags or explicit flags in the
> > presence of an active implication are disallowed for non-boolean
> > flags. The latter simplifies specifying conflict rules in
> > variants.py. Otherwise a rule like
> >
> > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > "--gc-interval=*": ["--gc-interval=*"],
> > }
> >
> > wouldn't work because specifying the same GC interval twice
> > wouldn't actually count as a conflict. This was an issue with
> > test/mjsunit/wasm/gc-buffer.js, which specifies
> > --gc-interval=500 exactly like the extra flag by the stress bot.
> >
> > Also, this now expands contradictory flags checking to d8 flags
> > for consistency.
> >
> > Original change's description:
> > > [flags] warn about contradictory flags
> > >
> > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > >
> > > Bug: v8:10577
> > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68168}
> >
> > Bug: v8:10577
> > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68989}
>
> Bug: v8:10577
> Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69339}
Bug: v8:10577
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: I4a69dc57a102782cb453144323e3752ac8278624
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69433}
Allow AllocationObserver::Step to remove allocation observers as well.
They could already add new observers (to start incremental marking),
removing will be used when starting StressConcurrentAllocator from
an allocation observer.
Bug: v8:10315
Change-Id: I823ded2f9a408b3fa5269ee8416060d0cabb3162
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357690
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69420}
This reverts commit 899cb34868.
Reason for revert: Added regression test fails on Arm Sim:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/11584
Original change's description:
> [wasm][fuzzer] Fix exception detection
>
> Exceptions were detected by checking for a pending exception on the
> isolate, but {CallWasmFunctionForTesting} was clearing any pending
> exception before returning.
> This CL fixes that by explicitly passing back a boolean which is set if
> an exception occurred during execution.
>
> R=ahaas@chromium.org
>
> Bug: chromium:1115280
> Change-Id: Ife71ceef0751d18e0870335b9520c2bf77e351cc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352787
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69404}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I1d3c0e57df7ec25b09f2037c31c9b30eb0866548
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1115280
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357189
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69405}
Exceptions were detected by checking for a pending exception on the
isolate, but {CallWasmFunctionForTesting} was clearing any pending
exception before returning.
This CL fixes that by explicitly passing back a boolean which is set if
an exception occurred during execution.
R=ahaas@chromium.org
Bug: chromium:1115280
Change-Id: Ife71ceef0751d18e0870335b9520c2bf77e351cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352787
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69404}
This is a reland of a7eff8cbbf
Sheriffs: This CL effectively enables GC for inspector tests. It may
uncover bugs in the existing inspector tests. If that happens please
disable the failing test in test/inspector/inspector.status instead of
reverting this CL. See https://crbug.com/v8/10748.
Original change's description:
> [inspector] Ensure progress of default task runners in inspector tests
>
> Bug: v8:10747, chromium:1098187
> Change-Id: I0215d2d85db4dd1d7fa376a0982cda5658f1683d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315982
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69387}
Bug: v8:10747
Bug: chromium:1098187
Change-Id: Iab8f10b0535b0f35948fb507537f2bf65af5f33a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354815
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69398}
This patch introduces a new LocalIsolate and LocalFactory, which use
LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
us to remove those classes, as well as the related OffThreadSpace,
OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
OffThreadLogger becomes LocalLogger.
LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
us to additionally remove the concept of "Finish" and "Publish" that the
OffThreadIsolate had, and allows us to internalize strings directly with
the newly-concurrent string table (where the implementation can now move
to FactoryBase).
This patch also removes the off-thread support from the deserializer
entirely, as well as removing the LocalIsolateWrapper which allowed
run-time distinction between Isolate and OffThreadIsolate. LocalHeap
doesn't support the reservation model used by the deserializer, and we
will likely move the deserializer to use LocalIsolate unconditionally
once we figure out the details of how to do this.
Bug: chromium:1011762
Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69397}
Run SimulateFullSpace in safepoint. Needed for FreeLinearAllocationArea
which would race with concurrent allocation.
Bug: v8:10315
Change-Id: If0c3c4e20edea1b05cc1a3e1a3e37fc29254a196
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354812
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69395}
This reached consensus in the March 2020 TC39.
https://github.com/tc39/ecma262/pull/1908
This aligns JS with wasm, which allows atomics operations on non-shared
linear memory.
Bug: v8:10687, v8:9921
Change-Id: I7b60473b271cee6bccb342e97a4fd3781aedddb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330802
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69392}
This fixes a case where we hit a DCHECK in Debug mode, or silently
discarded bogus data in Release mode without rejecting the module.
Fixed: chromium:1108815
Change-Id: I928ff244a54b016cd8470be1ec4b5faf2c7e3994
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349768
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69391}
Two tests already test concurrent allocation. Another one measures
memory, so non-deterministic allocation would lead to higher memory
usage than anticipated.
Bug: v8:10315
Change-Id: If994233c87ea04076b850ffdf024f7783653e9db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352781
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69383}
This extends the skip list feature from step over to step into.
On a step into we can pass a skipList, which contains locations
that we do not want to stop at.
Bug: chromium:1105765
Change-Id: I70a4ded3f6a7eada14f54ae9c2f994c155c7305b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345224
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69376}
Bring the return value of {InterpretWasmModule} in sync with
{CallWasmFunctionForTesting}, because the fuzzers now compare the two.
R=ahaas@chromium.org
Bug: chromium:1115431
Change-Id: I0abf79c4418a4e6cc7365a78148e5e71cf32231b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351678
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69374}
TurboFan generates significantly less code than Liftoff for this test,
and depending on timing it can happen that we need to generate thousands
of functions, which takes some time and occasionally runs into timeouts.
Thus disable tier-up for this test, such that we stick with the much
longer Liftoff code, and reach the four separate code spaces quicker.
R=ahaas@chromium.org
Change-Id: I8e9a0cb466c1bdfef29aceeb5dd31aa96d05b70b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352490
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69369}
Since it will be patched in later in the cases where it will be used,
there is no need to have it as a parameter.
Bug: v8:7790
Change-Id: I93b27f3baf8c3841a60f5ac5ed09993d1caf19bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351667
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69366}
Fix containing() w/ n point to surrogate tail.
Bug: v8:6891
Change-Id: I4d7e4083ba409eecaefaf2ec5c67b7226bd7c97c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2348208
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69363}
The (now unique)PersistentHandles container follows this path:
1) PersistentHandles created via PersistentHandlesScope inside of
CompilationHandleScope
2) Owned by OptimizedCompilationInfo
3) Owned by JSHeapBroker
4) Owned by the broker's LocalHeap
5) Back to the broker for a brief moment (after tearing down the
LocalHeap as part of exiting LocalHeapScope)
6) Back to OptimizedCompilationInfo when exiting the LocalHeapScope.
There is a special case in GenerateCodeForTesting where the JSHeapBroker
will not be retired in that same method. In this case, we need to
re-attach the PersistentHandles container to the JSHeapBroker.
The identity map of the persistent & canonical handles also gets passed
around like the persistent handles. The only difference is that is
created in the CanonicalHandleScope (i.e step 1) is different).
Bug: v8:7790
Change-Id: I2da77a7e08f3fd360a46b606c5fbda08c0af27df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332811
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69360}
Move external memory counters out of IsolateData back into Heap.
The class ExternalMemoryAccounting now stores all counters and is
responsible for updates. This change will allow turning counters into
atomic variables.
Bug: v8:10315
Change-Id: I2abeda298d3cfcc630fd04ca78a3d6d703e3b419
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346647
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69356}
A minor fix to the {InterpretAndExecuteModule} function: We instantiate
the module twice. If the first instantiation worked, then also the
second instantiation must succeed.
Plus minor drive-by cleanup.
R=ahaas@chromium.org
Bug: chromium:1113681
Change-Id: Ib897cb1907152cdd9b0ed2b513a6c8217a3f400c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349288
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69352}
ArrayBufferTracker was superseded by ArrayBufferList and
ArrayBufferSweeper. Now that ArrayBufferSweeper is used in production,
we can remove the unused ArrayBufferTracker mechanism.
Bug: v8:10064
Change-Id: I479169c76b6c5c634672024f77e689bb64a36504
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339105
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69351}
This is a reland of 57242a051e
no-sse4.1 builds were failing due to missing simd-scalar-lowering
for s128.const, this reland adds that implementation.
Original change's description:
> [wasm-simd][arm] Use vmov to move all ones to register
>
> vceq(dst, dst, dst) does not seem to always set the register to all
> ones. The right way should be be to use vmov (immediate) anyway. This
> was not supported in the assembler yet, so we need changes to the
> assembler, diassembler, and simulator.
>
> There is an unfortunate fork in logic in the simulator, due to the way
> the switches are set up, vmov (imm) logic is duplicated across two
> different cases, because the switch looks at the top bit of the
> immediate. Refactoring this will be a bigger change that is irrelevant
> for this bug, so I'm putting that off for now. Instead we extract the
> core of vmov (imm) into helpers and call it in the two cases.
>
> Bug: chromium:1112124
> Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
> 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@{#69315}
Bug: chromium:1112124
Change-Id: Id450e5cea41f7a569e49be8386a7788ca8f00658
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346937
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69346}
This reverts commit 0ba115e6a9.
Reason for revert: Breaks test on TSAN - block-conflicts
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/14230
Original change's description:
> Reland^2 "[flags] warn about contradictory flags"
>
> This is a reland of d8f8a7e210
> Change compared to last reland:
> - Do not check for d8 flag contradictions in the presence of --fuzzing
> - Allow identical re-declaration of --cache=*
>
> Original change's description:
> > Reland "[flags] warn about contradictory flags"
> >
> > This is a reland of b8f9166664
> > Difference to previous CL: Additional functionality to specify
> > incompatible flags based on GN variables and extra-flags, used
> > to fix the issues that came up on the waterfall.
> >
> > This also changes the rules regarding repeated flags: While
> > explicitly repeated flags are allowed for boolean values as long
> > as they are identical, repeated flags or explicit flags in the
> > presence of an active implication are disallowed for non-boolean
> > flags. The latter simplifies specifying conflict rules in
> > variants.py. Otherwise a rule like
> >
> > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > "--gc-interval=*": ["--gc-interval=*"],
> > }
> >
> > wouldn't work because specifying the same GC interval twice
> > wouldn't actually count as a conflict. This was an issue with
> > test/mjsunit/wasm/gc-buffer.js, which specifies
> > --gc-interval=500 exactly like the extra flag by the stress bot.
> >
> > Also, this now expands contradictory flags checking to d8 flags
> > for consistency.
> >
> > Original change's description:
> > > [flags] warn about contradictory flags
> > >
> > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > >
> > > Bug: v8:10577
> > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68168}
> >
> > Bug: v8:10577
> > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68989}
>
> Bug: v8:10577
> Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69339}
TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
Change-Id: I1454a05e357ddd704db7fb79e51be65d45a9a16e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10577
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2348365
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69341}
This is a reland of d8f8a7e210
Change compared to last reland:
- Do not check for d8 flag contradictions in the presence of --fuzzing
- Allow identical re-declaration of --cache=*
Original change's description:
> Reland "[flags] warn about contradictory flags"
>
> This is a reland of b8f9166664
> Difference to previous CL: Additional functionality to specify
> incompatible flags based on GN variables and extra-flags, used
> to fix the issues that came up on the waterfall.
>
> This also changes the rules regarding repeated flags: While
> explicitly repeated flags are allowed for boolean values as long
> as they are identical, repeated flags or explicit flags in the
> presence of an active implication are disallowed for non-boolean
> flags. The latter simplifies specifying conflict rules in
> variants.py. Otherwise a rule like
>
> INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> "--gc-interval=*": ["--gc-interval=*"],
> }
>
> wouldn't work because specifying the same GC interval twice
> wouldn't actually count as a conflict. This was an issue with
> test/mjsunit/wasm/gc-buffer.js, which specifies
> --gc-interval=500 exactly like the extra flag by the stress bot.
>
> Also, this now expands contradictory flags checking to d8 flags
> for consistency.
>
> Original change's description:
> > [flags] warn about contradictory flags
> >
> > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> >
> > Bug: v8:10577
> > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68168}
>
> Bug: v8:10577
> Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68989}
Bug: v8:10577
Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69339}
We shouldn't spill weak pointers onto the stack when calling functions
that can trigger GC. DynamicMapChecks operator was using feedback loaded
from the feedback vector across the TryMigrateInstance function call.
The feedback can be a weak pointer to receiver map for monomorphic cases
and TryMigrateInstance can trigger a GC. This cl fixes it by holding
a holding a strong reference to the feedback.
Bug: v8:10774,v8:10582,v8:9684
Change-Id: Ia36f4d8ad46421ae570f41439bc1f0875081deee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336804
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69338}
This is a reland of 60ee70bb40.
The wasm c-api flakes were fixed in https://crrev.com/c/2349293.
Original change's description:
> [wasm] Ensure that only TurboFan code is serialized
>
> We have the implicit assumption that Liftoff code will never be
> serialized, and we start relying on that when implementing new features
> (debugging, dynamic tiering).
>
> This CL makes the serializer fail if the module contains any Liftoff
> code. Existing tests are changed to ensure that we fully tiered up
> before serializing a module (similar to the logic in Chromium).
> The "wasm-clone-module" test needs to serialize the module before
> enabling the debugger.
>
> Note that chrome currently only serializes a module after it fully
> tiered up, so that should be fine. If other embedders need the ability
> to serialize a module in an arbitrary state, we will have to fix this
> later. With this CL we will be on the safe side though and (gracefully)
> fail serialization instead of accidentally serializing Liftoff code.
>
> R=ahaas@chromium.org
>
> Bug: v8:10777
> Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69276}
Bug: v8:10777
Change-Id: I2a7c1429812ca46d88a2902b8e0a7b7e3d638b56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349290
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69335}
We only want to serialize TurboFan code, because Liftoff code could
contain breakpoints, and we start thinking about embedding other
non-relocatable constants.
Thus, wait until top-tier compilation finished before triggering
serialization.
A follow-up CL will make serialization fail if any Liftoff code is
encountered.
R=ahaas@chromium.org
Bug: v8:10777
Change-Id: I73d6c2d868545fcd4069a8cf9850ca7fca375ecb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349293
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69332}
This removes the {InterpretWasmModuleForTesting} function in favor of
{InterpretWasmModule}, and uses that in {InterpretAndExecuteModule}.
The latter again is reused in {WasmExecutionFuzzer::FuzzWasmModule},
such that all fuzzers execute the same checks now.
R=ahaas@chromium.org
Bug: chromium:1112099, chromium:1113681
Change-Id: Ia8818b93e9274266a81573edd6852e4e4734b150
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346283
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69331}
This is the first step in refactoring Worklist to allow arbitrary
number of local worklists with private segments:
- Introduce MarkingWorklistImpl<> which will eventually replace
(and will be renamed to) Worklist.
- MarkingWorklistImpl<> owns the global pool of segments but does not
keep track of private segments.
- MarkingWorklistImpl<>::Local owns private segments and can be
constructed dynamically on background threads.
- Rename the existing MarkingWorklistsHolder to MarkingWorklists.
- Rename the existing MarkingWorklists to MarkingWorklists::Local.
- Rename the existing marking_workists_holder to marking_worklists.
- Rename the existing marking_worklists to local_marking_worklists.
Design doc: https://bit.ly/2XMtjLi
Bug: v8:10315
Change-Id: I9da34883ad34f4572fccd40c51e51eaf50c617bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2343330
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69330}
This change adds support for skipping locations that are in a skipList
on step over. This feature is useful for when we are debugging
C++ applications that have DWARF information we only want to stop on
every breakable location in C++, not non every breakable location
on wasm level.
Bug: chromium:1105765
Change-Id: Ie835b011a00cf31e0c5b2df1ac96ebd89f53d23a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339458
Reviewed-by: Eric Leese <leese@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69329}
Remove the {ErrorThrower} parameter to {CallWasmFunctionForTesting} (it
was only populated in a subset of failures anyway), and merge it with
{RunWasmModuleForTesting}.
R=ahaas@chromium.org
Bug: chromium:1113681
Change-Id: I5391e2f911928641a907bc5dad5a54677c90acb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346279
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69327}
The "wasm fuzzer" and "wasm async fuzzer" use the
{InterpretAndExecuteModule} function, which did not check for possible
nondeterminism in the interpreter yet. This can lead to wrong reports
of mismatches, or in endless loops being executed in compiled code which
was not executed in the interpreter.
This CL adds the check for nondeterminism in that function, and adds a
TODO to merge the two very similar methods.
R=ahaas@chromium.org
Bug: chromium:1112099, chromium:1113681
Change-Id: I80b01d4c53d04f0632807fa852147dc9fb8075ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346280
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69324}
The interpreter is used for testing (including fuzzing) only, and in
these cases it's often important to see the exact value of a float. Both
decimal and scientific notation does not show the full value though, and
decimal representation can also be really long for large values, making
it hard to compare values.
This CL switches this debug output to hexadecimal float values, which
always shows the float value in full precision and is also much shorter
than decimal notation in many cases.
R=ahaas@chromium.org
Bug: chromium:1112099
Change-Id: Ia84824227fcd2f1e763ab89280a202ed44930a71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346646
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69323}
This reverts commit 57242a051e.
Reason for revert: regression tests fails:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/31477
Original change's description:
> [wasm-simd][arm] Use vmov to move all ones to register
>
> vceq(dst, dst, dst) does not seem to always set the register to all
> ones. The right way should be be to use vmov (immediate) anyway. This
> was not supported in the assembler yet, so we need changes to the
> assembler, diassembler, and simulator.
>
> There is an unfortunate fork in logic in the simulator, due to the way
> the switches are set up, vmov (imm) logic is duplicated across two
> different cases, because the switch looks at the top bit of the
> immediate. Refactoring this will be a bigger change that is irrelevant
> for this bug, so I'm putting that off for now. Instead we extract the
> core of vmov (imm) into helpers and call it in the two cases.
>
> Bug: chromium:1112124
> Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
> 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@{#69315}
TBR=bbudge@chromium.org,jkummerow@chromium.org,v8-arm-ports@googlegroups.com,zhin@chromium.org
Change-Id: I5d9d1dcb81771f71001d959ec5a03a43a11c4233
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1112124
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2347211
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69316}
vceq(dst, dst, dst) does not seem to always set the register to all
ones. The right way should be be to use vmov (immediate) anyway. This
was not supported in the assembler yet, so we need changes to the
assembler, diassembler, and simulator.
There is an unfortunate fork in logic in the simulator, due to the way
the switches are set up, vmov (imm) logic is duplicated across two
different cases, because the switch looks at the top bit of the
immediate. Refactoring this will be a bigger change that is irrelevant
for this bug, so I'm putting that off for now. Instead we extract the
core of vmov (imm) into helpers and call it in the two cases.
Bug: chromium:1112124
Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
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@{#69315}
With a displacement of int32_t min (-2^31), and a displacement mode of
kNegativeDisplacement, we will try to negate this constant, but the
result will not fit in an int32_t, leading to a runtime crash.
Check for this special case in CanBeImmediate, and return false.
Bug: chromium:1091892
Change-Id: I7f18153d13805f2836dd5c8e1bc098f1e9600566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2341095
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69311}
The plain "wasm fuzzer" (which takes the fuzzer input as the wasm wire
bytes) was already running both the interpreter and compiled code, but
it did not compare the results of both.
This CL fixes this by reusing some logic that was already present in the
fuzzers based on the {WasmCompileFuzzer} class.
R=ahaas@chromium.org
Bug: chromium:1113681, chromium:1112099
Change-Id: I9d407f66dfcba0eec90f050630b028edd5fae1d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339624
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69310}
Add missing source position for stack check, used by OSR to find the
correct return address.
R=clemensb@chromium.org
Bug: v8:10235
Change-Id: Ie26dd3b2079168e846f84b3a4ffe18b838649be7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339625
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69309}
The {name} parameter was unused, we always picked the exported "main"
function.
R=ahaas@chromium.org
Bug: chromium:1113681
Change-Id: Iee4b8f72e1137a7e366c3c31b4fa4e4ef81863b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345964
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69307}
A new field for signature type was added to WasmExportedFunctionData.
It is set to 0 or 1 depending on the parameter count.
(It's set and being used only in 0 and 1 parameter cases.)
Added new JS tests for 1 parameter wasm functions.
Bug: v8:10701
Change-Id: I349d881a2860f1a50b91e08d0126ca71c5f6483b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339622
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69302}
Previously, all ThisExpression's had kNoSourcePositions leading to
incorrect error messages like this:
➜ d8 -e "function t() { for (const x of this) {} } t();"
unnamed:1: TypeError: undefined is not a function
function t() { for (const x of this) {} } t();
^
TypeError: undefined is not a function
at t (unnamed:1:11)
at unnamed:1:43
This patch allows creation of a ThisExpression with a source position,
leading to a better error message:
➜ d8 -e "function t() { for (const x of this) {} } t();"
unnamed:1: TypeError: this is not iterable
function t() { for (const x of this) {} } t();
^
TypeError: this is not iterable
at t (unnamed:1:32)
at unnamed:1:43
This patch does not remove the existing cached version of
ThisExpression and instead creates a new one when required.
Bug: v8:6513
Change-Id: Idee4fe8946a9b821d06ff4a5e7eaefe54874ec59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345226
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69300}
Up until now. we only checked the size of tables defined in a module
at instantiation time. For imported tables we only checked if the
imported table matched the declared import in size. This causes a
problem because we allocate function tables also for imported tabled
before we actually look at the imported table.
With this CL we first check the size of all tables, and only then start
to initialize and load them.
R=jkummerow@chromium.org
Bug: chromium:1114006
Change-Id: Iaf194ed21fb83304fe3a7f0f7ba7b282396e3954
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339473
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69291}
The cast from uint32_t to int caused an integer overflow that let a
bounds check succeed that should have failed.
R=jkummerow@chromium.org
Bug: chromium:1114005
Change-Id: Iea1af70af300be54c2a33d7dd10b3faa34d56eaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339472
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69289}
The test have been rewritten to be more robust -> maybe they're
robust enough for the GC fuzzer (DelayedTasksPlatform)?
Bug: v8:10239
Change-Id: I743cc2f804357aaef888bff7985dfb68a7feec5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342848
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69287}
This reverts commit 60ee70bb40.
Reason for revert: wasm-api-tests/WasmCapiTest.Serialize starts flaking: https://crbug.com/v8/10784
Original change's description:
> [wasm] Ensure that only TurboFan code is serialized
>
> We have the implicit assumption that Liftoff code will never be
> serialized, and we start relying on that when implementing new features
> (debugging, dynamic tiering).
>
> This CL makes the serializer fail if the module contains any Liftoff
> code. Existing tests are changed to ensure that we fully tiered up
> before serializing a module (similar to the logic in Chromium).
> The "wasm-clone-module" test needs to serialize the module before
> enabling the debugger.
>
> Note that chrome currently only serializes a module after it fully
> tiered up, so that should be fine. If other embedders need the ability
> to serialize a module in an arbitrary state, we will have to fix this
> later. With this CL we will be on the safe side though and (gracefully)
> fail serialization instead of accidentally serializing Liftoff code.
>
> R=ahaas@chromium.org
>
> Bug: v8:10777
> Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69276}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: Ic1349375bd562bb0a2724c39c27ef3247461c97b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342845
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69284}
The test relies on certain maps not dying but didn't ensure that.
Bug: v8:10783
Change-Id: I708f7fc027ee0bf5656be9bb4f29130f5b924597
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2340912
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69282}
Now that we are using PersistentHandles, we don't need it anymore.
Bug: v8:7790
Change-Id: Id0b9d555191c00fb08dc2bb9099746076c5ad1b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332161
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69278}
Spill registers before stack checks so that we can inspect them, similar
to traps.
OSR during a stack check is still unsupported and will be fixed in a
follow-up CL.
R=clemensb@chromium.org
Bug: v8:10235
Change-Id: I22c2da6b3f79b30c3838c568f9680204afc85d36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339467
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69277}
We have the implicit assumption that Liftoff code will never be
serialized, and we start relying on that when implementing new features
(debugging, dynamic tiering).
This CL makes the serializer fail if the module contains any Liftoff
code. Existing tests are changed to ensure that we fully tiered up
before serializing a module (similar to the logic in Chromium).
The "wasm-clone-module" test needs to serialize the module before
enabling the debugger.
Note that chrome currently only serializes a module after it fully
tiered up, so that should be fine. If other embedders need the ability
to serialize a module in an arbitrary state, we will have to fix this
later. With this CL we will be on the safe side though and (gracefully)
fail serialization instead of accidentally serializing Liftoff code.
R=ahaas@chromium.org
Bug: v8:10777
Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69276}
This is a reland of 28ead05405
The failure is a test that is sensitive to adding a function
in a FunctionTemplate in d8: https://bugs.chromium.org/p/v8/issues/detail?id=10783
Original change's description:
> [Atomics.waitAsync] Fix removing multiple nodes when Isolate deinits
>
> RemoveNode already nullifies the next_ pointer of FutexWaitListNode,
> and DeleteAsyncNode was trying to retrieve it.
>
> Bug: v8:10239
> Change-Id: I595885de87f433d263eeacfc825a689efd467f5e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332812
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69259}
Bug: v8:10239
Tbr: leszeks@chromium.org
Change-Id: Icec590354886433a0b41c8f9b7af7101b54b7690
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339469
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69275}
Changes the isolate's string table into an off-heap structure. This
allows the string table to be resized without allocating on the V8 heap,
and potentially triggering a GC. This allows existing strings to be
inserted into the string table without requiring allocation.
This has two important benefits:
1) It allows the deserializer to insert strings directly into the
string table, rather than having to defer string insertion until
deserialization completes.
2) It simplifies the concurrent string table lookup to allow resizing
the table inside the write lock, therefore eliminating the race
where two concurrent lookups could both resize the table.
The off-heap string table has the following properties:
1) The general hashmap behaviour matches the HashTable, i.e. open
addressing, power-of-two sized, quadratic probing. This could, of
course, now be changed.
2) The empty and deleted sentinels are changed to Smi 0 and 1,
respectively, to make those comparisons a bit cheaper and not
require roots access.
3) When the HashTable is resized, the old elements array is kept
alive in a linked list of previous arrays, so that concurrent
lookups don't lose the data they're accessing. This linked list
is cleared by the GC, as then we know that all threads are in
a safepoint.
4) The GC treats the hash table entries as weak roots, and only walks
them for non-live reference clearing and for evacuation.
5) Since there is no longer a FixedArray to serialize for the startup
snapshot, there is now a custom serialization of the string table,
and the string table root is considered unserializable during weak
root iteration. As a bonus, the custom serialization is more
efficient, as it skips non-string entries.
As a drive-by, rename LookupStringExists_NoAllocate to
TryStringToIndexOrLookupExisting, to make it clearer that it returns
a non-string for the case when the string is an array index. As another
drive-by, extract StringSet into a separate header.
Bug: v8:10729
Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104
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@{#69270}
This is a revival of https://chromium-review.googlesource.com/c/v8/v8/+/2228332
The CL establishes the following:
*) Objects are marked before being pushed to the worklists.
*) Live bytes are always accounted after tracing an object (i.e. move
from Gray to Black below).
*) Previously not fully constructed objects are traced immediately
instead of pushed to the marking worklist.
This establishes the following invariants for all marking worklists:
1) White = !object.is_marked() && !worklist.contains(object)
2) Gray = object.is_marked() && worklist.contains(object)
3) Black = object.is_marked() && !worklist.contains(object)
Bug: chromium:1056170
Change-Id: I821573b3fbc057e6ffb836154271ff986ecb4d2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336797
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69268}
We used to check the size of tables at compile time, and threw a
CompilationError if a given size exceeded the implementation-defined
limit. However, the spec defines that an error should only be thrown
when the implementation-defined limit is reached, which is either at
instantiation time of during runtime at a table.grow.
With this CL the V8 implementation becomes spec compliant in this
regard.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: I7d0e688b385a65e4060a569e5ab1dec68947ceea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326331
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69267}
This is a reland of 408e7240d7
Change: Allow CSA load elimination accross code comments
Original change's description:
> [torque] typed context slot access
>
> This introduces a new type Slot<ContextType, SlotType> that is used
> for enum values used to access context slots.
> Together with new types for the various custom contexts used in
> Torque, this results in fairly type-safe access to context slots,
> including the NativeContext's slots.
>
> Drive-by changes:
> - Introduce a new header file to specify headers needed for
> generated CSA headers, to reduce the amount of includes specified
> in implementation-visitor.cc
> - Port AllocateSyntheticFunctionContext to Torque.
>
> Bug: v8:7793
> Change-Id: I509a128916ca408eeeb636a9bcc376b2cc868532
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335064
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#69249}
Bug: v8:7793
Change-Id: I1fe100d8d62e8220524eddb8ecc4faa85219748d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339462
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69264}
The interpreter is not an execution tier in production any more. It's
only used in tests.
Thus, remove {ExecutionTier::kInterpreter} and instead add a
{TestExecutionTier} that still has {kInterpreter}.
If needed (in {TestingModuleBuilder::execution_tier()}), we translate
back from {TestExecutionTier} to {ExecutionTier} (for {kLiftoff} and
{kTurboFan} only).
The {TraceMemoryOperation} method, which is shared between interpreter
and production code, now receives a {base::Optional<ExecutionTier>}, and
we will just pass en empty optional if called from the interpreter.
R=thibaudm@chromium.org
Bug: v8:10389
Change-Id: Ibe133b91e8dca6d6edbfaee5ffa0d7fe72ed6d64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335186
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69260}
`Object::GetRealNamedPropertyAttributes()` can crash if an empty
`Maybe` is returned by `JSReceiver::GetPropertyAttributes()` because
it was not checking for that. Fix that.
Refs: https://github.com/nodejs/node/issues/34606
Change-Id: Ic83f904ba7134786bcd8f786eb2ce98adb4fea1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335057
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69258}
This reverts commit 408e7240d7.
Reason for revert: debug builds fail
is_component_build = true
is_debug = true
use_goma = true
v8_enable_backtrace = true
v8_enable_debugging_features = true
v8_enable_fast_mksnapshot = true
v8_enable_slow_dchecks = true
v8_enable_snapshot_code_comments = true
v8_enable_verify_csa = true
v8_optimized_debug = false
v8_use_multi_snapshots = false
# Fatal error in ../../src/compiler/backend/instruction-selector.cc, line 3088
# Expected Turbofan static assert to hold, but got non-true input:
static_assert(nativeContext == LoadNativeContext(context)) at src/builtins/promise-resolve.tq:45:5
Original change's description:
> [torque] typed context slot access
>
> This introduces a new type Slot<ContextType, SlotType> that is used
> for enum values used to access context slots.
> Together with new types for the various custom contexts used in
> Torque, this results in fairly type-safe access to context slots,
> including the NativeContext's slots.
>
> Drive-by changes:
> - Introduce a new header file to specify headers needed for
> generated CSA headers, to reduce the amount of includes specified
> in implementation-visitor.cc
> - Port AllocateSyntheticFunctionContext to Torque.
>
> Bug: v8:7793
> Change-Id: I509a128916ca408eeeb636a9bcc376b2cc868532
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335064
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#69249}
TBR=tebbi@chromium.org,seth.brenith@microsoft.com
Change-Id: I90c014022a808449aca4a9b9b3c3b8e036beb28e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2340903
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69256}
Make sure that Torque/CSA generated phi's get kRepWord32 instead
of kRepWord8 or kRepWord16, since that's how we handle small
integer values in Turbofan.
Bug: v8:7793
Change-Id: I992b43287552b6117e90fbd0e11576470bc91509
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339096
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69253}
Just like the optimized code cache, the compiler should check the
isolate cache for NCI code objects and return them if they exist.
Drive-by: Skip additional tests to fix the nci_as_highest_tier test
variant. These are related to interactions with deoptimization, which
NCI code doesn't fully support yet.
Bug: v8:8888
Change-Id: I6253811f96993796cfc38fff0da7ffb4f1a5eb24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339095
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69251}
Changes:
- Remove restriction that function types cannot be used as ref types.
- Introduce WasmModule::has_type().
- Remove deferred signature checks in module-decoder. Instead, check if
type indices are out of bounds in consume_value_type (was bugged
before).
- Remove obsolete GetCanonicalRttIndex.
- Refine type of ref.func.
- Statically check immediate type against table type for call_indirect.
- Dynamic check for call_indirect should only happen when for funcref
(currently the only function supertype).
- Allocate a different map per function signature (with Map::Copy).
- Introduce function type equivalence and (trivial) subtyping.
- Add a few elementary tests.
Bug: v8:7748
Change-Id: If57d0bfd856c9eb3784191f3de423f53dfd26ef1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335190
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69250}
This introduces a new type Slot<ContextType, SlotType> that is used
for enum values used to access context slots.
Together with new types for the various custom contexts used in
Torque, this results in fairly type-safe access to context slots,
including the NativeContext's slots.
Drive-by changes:
- Introduce a new header file to specify headers needed for
generated CSA headers, to reduce the amount of includes specified
in implementation-visitor.cc
- Port AllocateSyntheticFunctionContext to Torque.
Bug: v8:7793
Change-Id: I509a128916ca408eeeb636a9bcc376b2cc868532
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335064
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69249}
This function was only used in a single test, and it tests a scenario
which cannot happen any more with the module cache: Having two copies of
the same NativeModule in an isolate.
Hence remove the respective runtime function and the test.
R=ahaas@chromium.org
Change-Id: Id7cdffbdf1bdf95a7eb31fdeb7d75b8e326bb90e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339100
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69246}
PagedSpace::SizeOfObjects() then returns exactly the same value as
PagedSpace::Size(). SizeOfObjects() used to deduct the current LAB,
however this is now more difficult with local heaps. Accessing the
main thread LAB from concurrent threads causes a data race. Also
LocalHeaps have their own LAB, which should be deducted as well to be
uniform with the main thread. However this would be tricky and expensive.
The simpler solution is to do not deduct the main thread LAB anymore.
Bug: v8:10315
Change-Id: I3c47e1a65caca9395737251aa694b295e78c7fb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336090
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69245}
With the new Turbofan variants (NCI and Turboprop), we need a way to
distinguish between them both during and after compilation. We
initially introduced CompilationTarget to track the variant during
compilation, but decided to reuse the code kind as the canonical spot to
store this information instead.
Why? Because it is an established mechanism, already available in most
of the necessary spots (inside the pipeline, on Code objects, in
profiling traces).
This CL removes CompilationTarget and adds a new
NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
various things about a given code kind (e.g.: does this code kind
deopt?).
As a (very large) drive-by, refactor both Code::Kind and
AbstractCode::Kind into a new CodeKind enum class.
Bug: v8:8888
Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69244}
DetachPersistent() sets up PersistentHandles, but didn't properly set
up ordered_blocks_. So PersistentHandles::Contains failed for handles
that were detached from the main thread into PersistentHandles.
Bug: v8:10315
Change-Id: I5374ad64743cd519a9c5e92900c1fa401c4d93ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336801
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69243}
Use the new jobs API for WebAssembly compilation. This avoids having to
schedule as many background tasks as there are worker threads. Instead
the one job specifies the maximum concurrency, which changes dynamically
as new compile jobs become available.
This also avoids the artificial deadline we used to ensure that other
tasks get some share of the CPU resources if needed.
Even though this CL moves actual wasm function completely over to the
Jobs API, other similar tasks (like wrapper compilation) are still using
the Task API and need to be ported in a follow-up CL.
Also, we are still using the same priority for baseline compilation and
tier up. We should split this in a follow-up CL to have two jobs with
different priorities. This will also allow us to only block on baseline
compilation where we currently block on both.
R=ahaas@chromium.orgCC=gab@chromium.org
Bug: chromium:1101340
Change-Id: I5656697753346e5fdb15d578425cdb949ac6e364
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.chromium.try:linux-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280100
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69239}
fuzzer testsuite tests are not run due to a missing subclass method '_should_filter_by_name' in fuzzer/testcfg.py
This CL fixes the filtering for the 'fuzzer' testsuite
R=machenbach@chromium.org
Bug: v8:10770
Change-Id: I9a4b0e0c6c79f4b525ee284df343acccc965f732
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336802
Auto-Submit: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69235}
This test uses a i64x2.shr_s to shift a v128 with all bits set by 1,
resulting in v128 with all bits set (no change). This value is then
dropped, and param[2] (3), is returned.
Without the fix, -1 is returned, since i64x2.shr_s overwrites the
register for param[2] with 0xffffffff.
Bug: v8:10752
Bug: chromium:1111522
Change-Id: I0310bf6039be780a6738689069cdbcfa3a24bbdb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335779
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69233}
Swizzles are shuffles that only use values from 1 operand, e.g.
v8x16.shuffle 0 1 2 3 0 0 0 0 4 5 6 7 0 0 0 0 (all the values are < 16).
Match such patterns and emit an optimized codegen that uses less
registers and instructions. Only implemented for x64 for now, the other
backends will come in follow-up patches.
Bug: v8:10696
Change-Id: Iffa694b04c97313eab7d138e4bdad7c0c85cda89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335419
Reviewed-by: Clemens Backes <clemensb@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@{#69231}
Test now passes even if RO_SPACE sharing is enabled.
Bug: v8:10454
Change-Id: Ic7377c3367199383bb6a96a9beedcc52bbc3362f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335184
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69221}
This is a reland of b354e344fd
This CL adds 3 fixes:
* Unprotect code object before creating filler
* Allows AllocationObserver::Step to add more AllocationObservers
* Update limit in NewSpace::UpdateLinearAllocationArea
Original change's description:
> [heap] Refactor allocation observer in AllocationCounter
>
> Moves accounting of allocation observers into the AllocationCounter
> class. This CL removes top_on_previous_step_ for counters that are
> increased regularly in the slow path of the allocation functions.
>
> AdvanceAllocationObservers() informs the AllocationCounter about
> allocated bytes, InvokeAllocationObservers() needs to be invoked when
> an allocation step is reached. NextBytes() returns the number of bytes
> until the next AllocationObserver::Step needs to run.
>
> Bug: v8:10315
> Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69170}
Bug: v8:10315
Change-Id: I89ab4d5069a234a293471f613dab16b47d8fff89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332805
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69216}
This is a stop-gap solution (while we wait for a proper spec)
that lets managed WasmGC objects perform round-trips through
JavaScript. On the JavaScript side, they appear as empty/opaque.
Bug: v8:7748
Change-Id: I0dd368bc14d622f3ef41871484228267359e9b5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316306
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69207}
Allow the allocation of large old space objects through
LocalHeap::AllocateRaw. OldLargeObjectSpace::AllocateRawBackground will
allocate a large object on the background thread.
Bug: v8:10315
Change-Id: I9212f0c6770855dbe33490516aae7056987e192d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332804
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69195}
LocalHeap::AllocateRaw will be similar to Heap::AllocateRaw and
handle all allocations. LocalHeap::AllocateRawOrFail will perform a GC
and afterwards retry the allocation in a loop.
Bug: v8:10315
Change-Id: I68468962cf9102697aa547b2aa05c7ec6bafd19e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332801
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69193}
Chrome is currently adding a 128-bit V8ContextToken to keep track of
V8 contexts across multiple isolates and processes. Having per-isolate
token exposed by V8 leads to confusion of these two tokens.
This moves v8::Context::Token to v8::metrics::Recorder and changes
the corresponding functions:
- v8::Context::GetToken => v8::metrics::Recorder::GetContextId
- v8::Context::GetByToken => v8::metrics::Recorder::GetContext
This CL is purely mechanical and does not change the behaviour.
Bug: chromium:1101749
Tbr: clemensb@chromium.org
Change-Id: I31bbfa02ebab1c0d91b00f0d08c1b236392d14d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330023
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69188}
This reverts commit b354e344fd.
Reason for revert: Clusterfuzz found issues with this CL.
Original change's description:
> [heap] Refactor allocation observer in AllocationCounter
>
> Moves accounting of allocation observers into the AllocationCounter
> class. This CL removes top_on_previous_step_ for counters that are
> increased regularly in the slow path of the allocation functions.
>
> AdvanceAllocationObservers() informs the AllocationCounter about
> allocated bytes, InvokeAllocationObservers() needs to be invoked when
> an allocation step is reached. NextBytes() returns the number of bytes
> until the next AllocationObserver::Step needs to run.
>
> Bug: v8:10315
> Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69170}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: Icd713207bfb2085421fd82009be24a0211ae86da
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332667
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69187}
Also add some simple unittests for these functions.
Bug: v8:10696
Change-Id: Ic7607780b4eaf275b20d0937bf214846bf51d539
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330806
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69183}
If incoming map is deprecated, generate code to migrate the map. Since
this involves generating additional code and a call to runtime, we only
do this if one of the receiver maps was a migration target when
optimizing this function. If not, we deoptimize and discard the
optimized code if we see a deprecated map. This is to avoid bailout
loops when we see deprecated maps.
This change does the following:
// We generated code to migrate deprecated maps only if one of the maps
// in feedback vector is a migration target.
if ( there are migration targets in feedback)
{
if (checkMaps fails) {
if (incoming map is deprecated) {
migrate the map
checkMaps with the new map
} else {
bailout
}
}
} else {
if (checkMaps fails)
bailout;
}
Bug: v8:10582, v8:9684
Change-Id: I8a04c77ed209dd2fb0300a783d844f2335a678c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292231
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69179}
This allows templates to preserve the type of implicit parameters to
select a better ovleroad, without generally extending overload
resolution to implicit parameters, which could be confusing.
Bug: v8:7793
Change-Id: Ie57090a295b0b46d03789829b975fc16e2a9c5b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2329630
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69177}
This allows the configuration v8_enable_shared_ro_heap and
v8_enable_pointer_compression on Linux and Android, although it still
defaults to off.
When pointer compression and read-only heap sharing are enabled, sharing
is achieved by allocating ReadOnlyPages in shared memory that are
retained in the shared ReadOnlyArtifacts object. These ReadOnlyPages are
then remapped into the address space of the Isolate ultimately using
mremap.
To simplify the creation process the ReadOnlySpace memory for the first
Isolate is created as before without any sharing. It is only when the
ReadOnlySpace memory has been finalized that the shared memory is
allocated and has its contents copied into it. The original memory is
then released (with PC this means it's just released back to the
BoundedPageAllocator) and immediately re-allocated as a shared mapping.
Because we would like to make v8_enable_shared_ro_heap default to true
at some point but can't make this conditional on the value returned by
a method in the code we are yet to compile, the code required for
sharing has been mostly changed to use ifs with
ReadOnlyHeap::IsReadOnlySpaceShared() instead of #ifdefs except where
a compile error would result due to the absence of a class members
without sharing. IsReadOnlySpaceShared() will evaluate
CanAllocateSharedPages in the platform PageAllocator (with pointer
compression and sharing enabled) once and cache that value so sharing
cannot be toggled during the lifetime of the process.
Bug: v8:10454
Change-Id: I0236d752047ecce71bd64c159430517a712bc1e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267300
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69174}
Moves accounting of allocation observers into the AllocationCounter
class. This CL removes top_on_previous_step_ for counters that are
increased regularly in the slow path of the allocation functions.
AdvanceAllocationObservers() informs the AllocationCounter about
allocated bytes, InvokeAllocationObservers() needs to be invoked when
an allocation step is reached. NextBytes() returns the number of bytes
until the next AllocationObserver::Step needs to run.
Bug: v8:10315
Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69170}
PersistentHandles were attached to the LocalHeap when passed in through
the constructor but not when created inside LocalHeap using
EnsurePersistentHandles.
Bug: v8:10315
Change-Id: Id24d36c935776cb0b643521c465763da7fbffd06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326630
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69167}
This is a reland of 13141c8a65
... with a fix for an UB issue of passing null pointers to memcpy()
when size is zero.
TBR=leszeks@chromium.org
Original change's description:
> [zone-compr] Introduce ZoneTypeTraits and ZoneCompression
>
> Also move zone compression flags to src/common/globals.h.
>
> Bug: v8:9923
> Change-Id: Id0a77720e735e2669a1e5eef48e1b4866ad99480
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324255
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69160}
Bug: v8:9923
Change-Id: I2245b81516c39ccea262c282c659ef601af57abf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332165
Commit-Queue: Igor Sheludko (OOO Aug 3-17) <ishell@chromium.org>
Reviewed-by: Igor Sheludko (OOO Aug 3-17) <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69166}
If an enum case has a type annotation, the corresponding enum constant
has this type. This is useful for typing context slots.
Bug: v8:7793
Change-Id: I8b91c3bd3686048f98cce3c034eec4e36f925e5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2329631
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69165}
Excluded regions are no longer available to the RegionAllocator, so
should not be freeable so actually enforce that and aAdd a test.
Bug: v8:10454
Change-Id: I51c41cf0bf3d2eeb699b10b1fa02f5465d93b6aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330026
Reviewed-by: Igor Sheludko (OOO Aug 3-17) <ishell@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69163}
If we are near the stack limit, calling the proxy method might not work
any more. Instead of crashing because of an empty MaybeLocal, handle
this gracefully.
Drive-by: Minor refactoring in TryGetValue.
R=tebbi@chromium.org
Bug: chromium:1110001
Change-Id: I07e7773768166b3dbea2e6b75a3ab8b24bfeee53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332156
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69161}
The shutdown process should destroy AccountingAllocator instance before
the V8 platform.
Bug: v8:9923
Change-Id: Iff76b64d16c42c711ce4ee0c3533acd5ba5aaaa5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330020
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69158}
The resolvedOptions of Intl.NumberFormat depends on the ICU's
skeleton. sffc change the output of the wildcard from + to *
in ICU67
(ac4540f8a4)
Change the v8 code to use * instead.
Bug: chromium:1108810
Change-Id: I8b0249a5bc4cc199f454c5070635100f68d1f48d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2318272
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69152}
This was previously running on TurboFan and scalar lowering. Since
Liftoff has gained support for shuffle instructions, we can run it
there too.
Bug: v8:10696
Change-Id: I5a33d500b8e584ec4d6ffd29373593aabebae4b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327183
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69151}
These are no longer tied to instruction-selector, so move them out into
their own unittests. We can then remove the *ForTesting methods.
Bug: v8:10696
Change-Id: I387cf38290d9602b011ee1d13ee5285ac660f208
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326951
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69149}
This is a spec bug in V8. Only call expressions literally of the form
'eval(...)' are considered direct.
Bug: v8:10688
Change-Id: Ia5ac9992db82cad0ad6870119bd94a0b4daee417
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327752
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69148}
... by ensuring that the V8 platform is initialized before the
AccountingAllocator used in the tests.
Bug: v8:9923
Change-Id: I2d75b7c26dab55b9258c1be800a37a6f777f1103
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2328791
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69144}
Adds unittests that test the fast register allocator correctly deals
with spills of Phi's between their definition and a predecessor block's
gap move to populate the Phi.
BUG=v8:9684
Change-Id: I17263058d5ac29088895ad3de7b3131315ec8fae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299371
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69141}
Due to dynamic map checks we generate different code and the pattern
fails. As a note, the other tests have already been disabled for
TurboProp.
Bug: v8:9684, v8:9820
Change-Id: Ib8be11ae10bc801116d6a17d1c6b08d8026287b3
Fixes: v8:9820
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2328784
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69140}
Adds support for Phis to be allocated to the fast register
allocator. Registers used for Phis are marked specially between
the point where the Phi is defined, and the gap-move's in the
predecessor blocks which populate the Phi value, since if the
Phi is spilled then all predecessor blocks must also spill the
Phi even if they were already allocated.
BUG=v8:9684
Change-Id: Iebe90495b83df655d3335a7d55874123f3b27f8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299366
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69139}
PersistentHandlesScope works similar to the DeferredHandleScope, but
returns PersistentHandles instead of DeferredHandles on Detach().
Since PersistentHandlesScope takes over filled blocks from the
main thread local handle, remove the block_size_ field and use
kHandleBlockSize instead. This way all blocks have exactly the same size.
Bug: v8:10315
Change-Id: I295cad6f84852f87c55d95572905069443f5698c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324254
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69138}
Although the code generator already combines return instructions late
in the pipeline into a common site, there were still superfluous jumps
to that common site left in the code.
Change-Id: I06c885fb0ab6a2c078f9dabdc6616c6881f42c75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284984
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69133}
The bug was that the allocation of the result array (before the loop)
was using the outer frame state, thus returning the allocation's result
(an array full of holes) as the return value of the map operation in
case the allocation triggers a lazy deopt.
Bug: chromium:1104514
Change-Id: I9a6db8a5860472e1b438b6b54414938d61e166c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324249
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69129}
If we don't have slack and we want to add an element to the
TransitionArray, we would create a new TransitionArray. The background
hread, however, can be holding a pointer to the old transitions. This
test tests that this is safe to do, i.e the background thread reading
the old TransitionArray.
To make sure that we are testing that, we can add more synchronization
via an extra semaphore.
Bug: v8:7790
Change-Id: Ie454d79282ac267d3527269e8490baced979aa45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323351
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69126}
Zap freed local and persistent handles similar to main thread handles.
As a drive-by change, fix the creation of local handles without
LocalHandleScope.
Bug: v8:10315
Change-Id: Ia71bc5419c62ae073928751f57fc221ea11de254
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323362
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69121}
This cl also
1. Fixes a bug in effect-control-linearizer where we should have
converted fixed array length from Smi to integer
2. Also prints deopt location for the new "bailout" deopt type on
--trace-deopt.
Bug: v8:10582, v8:9684
Change-Id: Iafc5e8abbca5252a8783a5a1184a1667a7f708a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297460
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69115}
Setup the function table exactly like the module's function table, so
that we can share most of the call generation logic.
R=clemensb@chromium.org
Bug: v8:10751
Change-Id: Ie74150af8cf79d00adcc59d6880d2ed3e7cf78f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323353
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69111}
Currently WebAssembly always goes through the ArgumentsAdaptorTrampoline
builtin for wasm-to-js calls as soon as there's a mismatch between the
actual number of arguments and the expected number of arguments.
This can be made faster in cases where:
1. the callee has "don't adapt arguments" set, which is often the case
for builtins, or
2. the callee has "skip adapt arguments" set, which is often the case
for strict mode functions.
TurboFan already supports this for JS calls:
https://chromium-review.googlesource.com/c/1482735;
explainer document:
http://bit.ly/v8-faster-calls-with-arguments-mismatch.
Even though it is probably not as common to have arity mismatches in
Wasm->JS calls as it is in JS->JS calls, this still seems a worthwhile
optimization to do.
This CL ports the TurboFan fix to WebAssembly. In particular, the CL
introduces a new WasmImportCallKind (kJSFunctionArityMismatchSkipAdaptor)
for the case where the call to Builtins_ArgumentsAdaptorTrampoline
can be skipped, and modifies WasmImportWrapperCache::CacheKey to also
consider the arity of the imported JS function.
A micro-benchmark for this change can be found here:
- https://gist.github.com/paolosevMSFT/72c67591170d6163f67c9b03a7e12525#file-adapter-cc
- https://gist.github.com/paolosevMSFT/72c67591170d6163f67c9b03a7e12525#file-adapter_test-js
With this benchmark, we can save a 40% overhead of
Builtins_ArgumentsAdaptorTrampoline for calls that pass too many
arguments, while the savings for calls that pass too few arguments are
less impressive:
Before After
callProperApplication: 563 ms 566 ms
callOverApplication1: 972 ms 562 ms
callOverApplication2: 962 ms 562 ms
callUnderApplication: 949 ms 890 ms
Bug: v8:8909
Change-Id: Id51764e7c422d00ecc4a48704323e11bdca9377f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317061
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69110}
Adds support for populating reference maps to the fast
register allocator. In order to calculate whether a stack slot
is live at a given instruction, we use the dominator tree to
build a bitmap of blocks which are dominated by each block.
A variable's spill operand is classed as alive for any blocks that are
dominated by the block it was defined in, until the instruction index
of the spill operand's last use. As such, it may be classified as live
down a branch where the spill operand is never used, however it is safe
since the spill slot won't be re-allocated until after it's last-use
instruction index in any case.
BUG=v8:9684
Change-Id: I772374599ef916f57d82d468f66429e32c712ddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298008
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69108}
Adds support for tracking the instruction range of spilled operands,
and then allocating spill slots to these ranges. It also adds some
unittests covering spill slot allocation.
Spill slots are allocated in a linear fashion, running through the
instruction stream in a linear order, ensuring that no spill operand
is allocated to a same spill slot that is already assigned to during
this whole start / end range. This isn’t optimal, since it doesn’t
take into account holes in these ranges (e.g, blocks between start
and end that aren’t dominated by the start), but in practice rarely
leads to more than one extra spill slot being allocated compared to
the current allocator.
BUG=v8:9684
Change-Id: Iedee7bcf552080e5b4b6a2f4e96b78b6c1396cab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297470
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69107}
Since we have an uninitialized TransitionArray that we want to insert
an element (map1), we can't guarantee that said element would exist at
the point of the search. Then, we search for an element guaranteed not
to be (map2) and we check that we did not find it.
If we have a data race, this would also trigger it.
Bug: v8:7790
Change-Id: Ib90044d7c0901d599aed041f608f2c0bce506d67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319995
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69099}
This generic wrapper builtin is currently used only when the wasm
function has no parameters and no return value.
Added a new V8 flag to use this generic wrapper.
Also added a JS test function for this generic wrapper.
Bug: v8:10701
Change-Id: Id8cd1771f26922927363b715d8a6ffd384a143ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2307240
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69097}
https://tc39.es/proposal-intl-segmenter/
TC39 passed Intl.Segmenter to stage 3 in Jul 21.
This CL move our earlier prototype to the current spec.
Bug: v8:6891
Change-Id: I07234beed54f671c26bdbfb3983c5bc2fa5a29b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219413
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69080}
Currently, only a scriptURL is reported, which can be over-written by
sourceURL comments of the script. This means a script can basically
claim to come from anywhere. This means that DevTools doesn't know the
resource name the embedder provided if there is a sourceURL comment.
This CL adds a `embedderName` field to the scriptParsed and
scriptFailedToParse events that reports the name the embedder
associated with the script.
Bug: chromium:974543
Change-Id: I9863f878f57638174847890d9a3818952b1efc27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317310
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69078}
This test should've been rewritten in the last
batch rewrite but wasn't.
Bug: v8:10239
Change-Id: Ic2949e6282f72975898ab7e9aefe3210bba71fbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319988
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69072}
When mksnapshot fails on a static assert in Torque, print the
statement and position from the Torque source. To enable special
treatment, change the syntax of static asserts in Torque
from StaticAssert() to static_assert() to align with assert() and
check() statements.
Bug: v8:7793
Change-Id: Idda8e3c342bdcefc893ff297f8d7727d2734c221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317314
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69069}
This CL allows LocalHandles to be dereferenced by the same thread that
created them, even if we have a DisallowHandleDereference scope.
Bug: v8:7790
Change-Id: Ie227aaa4152c887d0d9c913dfa35217166726614
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316111
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69068}
If the types allow it, sometimes generate a return call instead of a
regular call in the wasm-compile fuzzer.
R=clemensb@chromium.org
Bug: v8:10693
Change-Id: Ie5e92f2b012f655b9d7d5847dba4a669152635c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316297
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69063}
Only the first four elements of the array will be used. Also, the fifth
element sais 'stepInfo' instead of 'stepInto'.
R=thibaudm@chromium.org
Change-Id: I258a8b95795f0cfbcaf500b7d174786680914d36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316110
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69062}
Introduce explicit fast path for allocation from LAB. The slow path
refills the LAB and allocates again. Other changes:
1) Move slow path methods out of the header file
2) AllocateRaw(Aligned|Unaligned) are now private methods. All
allocations need to go through AllocateRaw for NewSpace now.
Bug: v8:10315
Change-Id: Iee2bd7b74aa49be8b20d89fefeb2e087575d532c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319987
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69061}
Using uint8_t[] causes decay to pointer issue, which manifests in
copying garbage values in the call to WriteLittleEndianValue. Change it
to use a std::array, which doesn't have the decaying behavior.
Also add a regression test from comment#6 of the linked bug.
Bug: v8:10731
Change-Id: I4a1ca69fe99806642e9931625ca7aeab6663f955
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316465
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69052}
csuite.py compare command currently throws exception
"_csv.Error: iterator should return strings, not bytes
(did you open the file in text mode?)"
This should fix it.
Change-Id: I69c0ec43575a8c3627dac81dc99e47ba6adf6f61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316833
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69050}
This flag is already baked into the snapshot by enabling more
write-barrier elimination, so changing it at runtime would be a bug.
Change-Id: I3bc73f3c880285ec46b69b0c44934f64b49912ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2290856
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69046}
Adds support for register allocation within a block to the fast
register allocator. Also adds some unittests covering basic
register allocation. No support yet for spill slot allocation,
so functions that spill don't work yet.
BUG=v8:9684
Change-Id: I91d0fc0660d7b65f59235242fd5e3b1a7618d813
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297467
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69045}
This CL includes the following minor cleanups:
* Renames MakeRaisesException -> MakeWithErrorSupport
* Removes remaining WrapperTraits related code
* Makes the public header follow the IWYU principle
Bug: chromium:1052746
Change-Id: I60e730fa15f9bde421a7b6273093c84870666a64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316296
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69043}
... that controls whether the TF graph zones should support compression.
Bug: v8:9923
Change-Id: Ifbe237b75e9c92e62eb32b69d6b3b1a818269b83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2308347
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69036}
* Added GN flag v8_enable_zone_compression.
* AccountingAllocator supports allocation of zone segments via both
malloc/free and bounded page allocator. The latter implementation is
known to be not efficient yet. This issue will be addressed in a
follow-up CLs.
* Add support_compression flag to Zone constructor/instance.
Bug: v8:9923
Change-Id: I12ee2d85267dd16f455b1b47edc425dc90c57bcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2308345
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69035}
This adds an internal property [[IsDetached]] to the inspector preview
of ArrayBuffer instances, which indicates whether the ArrayBuffer was
detached (i.e. transfered via `postMessage`). Previously it was rather
impossible to tell whether an ArrayBuffer was detached, you had to know
that V8 violates the ECMAScript specification and simply sets the
byteLength accessor to 0 upon detaching an ArrayBuffer (but even then it
was still impossible to tell whether that ArrayBuffer wasn't simply an
empty one from the get go).
Before: https://imgur.com/UcOF83c
After: https://imgur.com/WjmTehZ
Fixed: chromium:1109102
Change-Id: I8fb6e2be2fbfe5c62b05dc9d2a0f18378eb4de6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316075
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69034}
The following adds support for JSMember through the existing
GlobalHandles implementation also used for TracedReference.
In addition, JSMember now supports set, clear, copy, move, comparison
and interaction with Local.
Bug: chromium:1056170
Change-Id: Ia50218bcfe4c056b3533a5b14eea954ade1da243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2310357
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69028}
A small step for a JSFunction, one giant leap for V8.
Tbr: clemensb@chromium.org
Bug: v8:8888
Change-Id: I968bb819763994ec611cde7e502adea30339a387
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315979
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69018}
Design doc:
https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing
V8 can already collect data about how many times each basic block in the
builtins is run. This change enables using that data for profile-guided
optimization. New comments in BUILD.gn describe how to use this feature.
A few implementation details worth mentioning, which aren't covered in
the design doc:
- BasicBlockProfilerData currently contains an array of RPO numbers.
However, this array is always just [0, 1, 2, 3, ...], so this change
removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument
ensures that the removal is valid.
- RPO numbers, while useful for printing data that matches with the
stringified schedule, are not useful for matching profiling data with
blocks that haven't been scheduled yet. This change adds a new array
of block IDs in BasicBlockProfilerData, so that block counters can be
used for PGO.
- Basic block counters need to be written to a file so that they can be
provided to a subsequent run of mksnapshot, but the design doc doesn't
specify the transfer format or what file is used. In this change, I
propose using the existing v8.log file for that purpose. Block count
records look like this:
block,TestLessThanHandler,37,29405
This line indicates that block ID 37 in TestLessThanHandler was run
29405 times. If multiple lines refer to the same block, the reader
adds them all together. I like this format because it's easy to use:
- V8 already has robust logic for creating the log file, naming it to
avoid conflicts in multi-process situations, etc.
- Line order doesn't matter, and interleaved writes from various
logging sources are fine, given that V8 writes each line atomically.
- Combining multiple sources of profiling data is as simple as
concatenating their v8.log files together.
- It is a good idea to avoid making any changes based on profiling data
if the function being compiled doesn't match the one that was
profiled, since it is common to use profiling data downloaded from a
central lab which is updated only periodically. To check whether a
function matches, I propose using a hash of the Graph state right
before scheduling. This might be stricter than necessary, as some
changes to the function might be small enough that the profile data is
still relevant, but I'd rather err on the side of not making incorrect
changes. This hash is also written to the v8.log file, in a line that
looks like this:
builtin_hash,LdaZeroHandler,3387822046
Bug: v8:10470
Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69008}
DateTimeFormat's fractionalSecondDigits shipped in M84, so we
can drop the --harmony_intl_dateformat_fractional_second_digits
flag now.
Bug: v8:10485
Change-Id: If7a1a8599722073d7382635219a6fb46cdc47474
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2311410
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69007}
