This moves concurrent and incremental sweeping from Blink. This also
adds TestPlatform that makes it easier to test concurrent and
incremental sweeping.
Drive-by: fix unmarking of large pages.
Bug: chromium:1056170
Change-Id: Ifd50ff67b9df17ff117a5f4d4eb5a2937d3023be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207132
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67969}
We can't consistently rewire the successor blocks of an unreachable node to
disconnect them from the graph when we are trying to maintain the schedule.
Instead simply leave the code there. As a future optimization we could add a
proper scheduled dead code elimination phase which can deal with this.
As a side-effect, one of the tests sees a int64 DeadValue, so add support for that
in the instruction selector.
BUG=chromium:1083272,chromium:1083763,chromium:1084953,v8:9684
Change-Id: I69a6feaeef4eae62110392e27ea848b28bccf787
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209061
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67953}
Sometimes CSA code carefully constructs a mask to check several
bitfields at once. Thus far, such a check has been very awkward to write
in Torque. This change adds a way to do so, using the
non-short-circuiting binary `&` operator. So now you can write an
expression that depends on several bitfields from a bitfield struct,
like `x.a == 5 & x.b & !x.c & x.d == 2` (assuming b is a one-bit value),
and it will be reduced to a single mask and equality check. To
demonstrate a usage of this new reduction, this change ports the trivial
macro IsSimpleObjectMap to Torque. I manually verified that the
generated code for the builtin SetDataProperties, which uses that macro,
is unchanged.
Bug: v8:7793
Change-Id: I4a23e0005d738a6699ea0f2a63f9fd67b01e7026
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2183276
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67948}
The implementation of the StreamingDecoder depends on async compilation.
However, when the --single-threaded flag is set, async compilation is
not available. Therefore V8 does not support streaming compilation at
the moment if the --single-threaded flag is set.
This CL is the first step to support streaming compilation in
--single-threaded mode. This CL makes the StreamingDecoder an abstract
class, and the current implementation a sub-class called
AsyncStreamingDecoder. A follow-up CL will provided a second sub-class
implementation for streaming compilation in --single-threaded mode.
Bug: v8:10548
Change-Id: Ice5c01340d3df18f836a4a05d30571207ca8ccf6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208869
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67931}
Changes:
Cleanup:
- Make sure read_value_type has the same interface as other
read_* functions, i.e., returns the decoded value and writes
the consumed length into a pointer.
- DecodeLocals is now an instance method.
- DecodeLocals should fail when given a wrong number of locals.
Add tests to catch that.
- Fix a buggy test.
Refactoring in preparation of introducing the 'let'
instruction as per [wasm-gc]:
- DecodeLocals does not consume any input and can start from any pc.
- DecodeLocals gives the option of not appending the decoded
locals to local_types_.
- Separate locals initialization from signature.
Bug: v8:7748
Change-Id: Iaaff87fdb9abe0ddd716484ea3fa87779d2d1a2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202992
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67845}
This allows embedding objects in each other and recursively trace
through them.
Bug: chromium:1056170
Change-Id: I4e4ae4c1669109c01003cb6b69797cf271a74033
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198977
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67841}
Splits out all of PagedSpace and subclasses into paged-spaces.h. Also
moves CodeObjectRegistry to code-object-registry.h.
Bug: v8:10473, v8:10506
Change-Id: I35fab1e545e958eb32f3e39a5e2ce8fb087c2a53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201763
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67811}
This reverts commit 580917d252.
Reason for revert: fix in patchset 2
Original change's description:
> Revert "cppgc: Stack scanning using ObjectStartBitmap"
>
> This reverts commit d3a72e3c2a.
>
> Reason for revert: MSAN failures (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/32360)
>
> Original change's description:
> > cppgc: Stack scanning using ObjectStartBitmap
> >
> > This CL implements stack scanning for cppgc.
> > Given a value on the stack, the MarkingVisitor uses
> > PageBackend::Lookup to checks whether that address is on
> > the heap. If it is, BasePage::TryObjectHeaderFromInnerAddress
> > (introduced in this CL) is used to get the relevant object
> > header. Note that random addresses on the heap might point to
> > free memory, object-start-bitmap, etc.
> >
> > If a valid object header is found:
> > * If the object is not in construction, the GCInfoIndex is used
> > the get the relevant Trace method and the object is traced.
> > * Otherwise, the object is conservatively scanned - i.e. the
> > payload of the object is iterated word by word and each word is
> > treated as a possible pointer.
> >
> > Only addresses pointing to the payload on non-free objects are
> > traced.
> >
> > BasePage::TryObjectHeaderFromInnerAddress assumes on LAB on the
> > relevant space, thus all LABs are reset before scanning the stack.
> >
> > Bug: chromium:1056170
> > Change-Id: I172850f6f1bbb6f0efca8e44ad8fdfe222977b9f
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190426
> > Commit-Queue: Omer Katz <omerkatz@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#67795}
>
> TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
>
> Change-Id: I3caef6f9f55911fd1a86e895c3495d1b98b1eac2
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1056170
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201136
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67796}
TBR=ulan@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
# Not skipping CQ checks because this is a reland.
Bug: chromium:1056170
Change-Id: If7ea4fe5cb794c07544d5545f5d6548e3375d3ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201137
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67803}
The existing non-builtin implementation is returning wrong results.
For example, given the value 63 as a uint8_t it returns 38 (should be 6).
The new implementation follows the naive algorithm presented in figure 5-1
in Hacker's Delight section 5-1.
Note that the algorithm in the book is designed for 32 bit numbers, so we
extended it to support 64 bit as well.
Bug: chromium:1056170
Change-Id: I8fed9c449f80b01b8cc93d339529c0e1e0863fc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199345
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67801}
This reverts commit d3a72e3c2a.
Reason for revert: MSAN failures (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/32360)
Original change's description:
> cppgc: Stack scanning using ObjectStartBitmap
>
> This CL implements stack scanning for cppgc.
> Given a value on the stack, the MarkingVisitor uses
> PageBackend::Lookup to checks whether that address is on
> the heap. If it is, BasePage::TryObjectHeaderFromInnerAddress
> (introduced in this CL) is used to get the relevant object
> header. Note that random addresses on the heap might point to
> free memory, object-start-bitmap, etc.
>
> If a valid object header is found:
> * If the object is not in construction, the GCInfoIndex is used
> the get the relevant Trace method and the object is traced.
> * Otherwise, the object is conservatively scanned - i.e. the
> payload of the object is iterated word by word and each word is
> treated as a possible pointer.
>
> Only addresses pointing to the payload on non-free objects are
> traced.
>
> BasePage::TryObjectHeaderFromInnerAddress assumes on LAB on the
> relevant space, thus all LABs are reset before scanning the stack.
>
> Bug: chromium:1056170
> Change-Id: I172850f6f1bbb6f0efca8e44ad8fdfe222977b9f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190426
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67795}
TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
Change-Id: I3caef6f9f55911fd1a86e895c3495d1b98b1eac2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201136
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67796}
This CL implements stack scanning for cppgc.
Given a value on the stack, the MarkingVisitor uses
PageBackend::Lookup to checks whether that address is on
the heap. If it is, BasePage::TryObjectHeaderFromInnerAddress
(introduced in this CL) is used to get the relevant object
header. Note that random addresses on the heap might point to
free memory, object-start-bitmap, etc.
If a valid object header is found:
* If the object is not in construction, the GCInfoIndex is used
the get the relevant Trace method and the object is traced.
* Otherwise, the object is conservatively scanned - i.e. the
payload of the object is iterated word by word and each word is
treated as a possible pointer.
Only addresses pointing to the payload on non-free objects are
traced.
BasePage::TryObjectHeaderFromInnerAddress assumes on LAB on the
relevant space, thus all LABs are reset before scanning the stack.
Bug: chromium:1056170
Change-Id: I172850f6f1bbb6f0efca8e44ad8fdfe222977b9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190426
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67795}
This is needed to trace objects found durinbg stack scanning.
Bug: chromium:1056170
Change-Id: I1280d98f2fe69281c514b3a7d4a57f909a2eed96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190425
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67788}
Add const Page iterators to Spaces, and add whichever const methods are
necessary for this to work. This and a couple more const methods allows
us to make Heap::Contains const.
Change-Id: I1b63a10575ccdb8a3979aef4fa63a97b288ff836
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198975
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67776}
Fold distinct MUL and ADD (or SUB) instructions into a single MLA (or
MLS) instruction, mirroring what is being done for general purpose
registers.
SIMD wasm only uses the vectorized ADD and MUL instructions on quad
vectors (NEON Q), so only those cases are handled.
SIMD wasm only uses MUL by vectors, not by elements so there is no need
to check for an addition and shift reduction.
Change-Id: If07191dde9fb1dc37a5de27187800c15cc4325ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184239
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#67770}
This CL adds 2 new values to the EmbedderStackState enum with more
explicit names. The old values are updated as aliases to the new
values and marked as soon to be deprecated. This CL also moves the
enum to v8-platform.h so that it can be reused by cppgc.
Depracating individual values in an enum is supported by GCC only
since version 6. Thus new macros were needed for the deprecation
(which delegate to the existing macros when supported). GCC versions
older than 6 are still used by the CQ bots.
Bug: chromium:1056170
Change-Id: Id1ea73edfbbae282b0d8a3bb103dbbbf8ebd417e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2188971
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67744}
The visitor was removing pages while at the same time iterating them on
NormalPagedSpace.
Removing all pages at once is safe and should also be faster.
Bug: chromium:1056170
Change-Id: I56eedf6f09498f126cb09238e01962b48e75b657
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190427
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67687}
Background threads can now start incremental marking when necessary. In
contrast to the main thread they always need to schedule a job and can't
start incremental marking right away. Background threads also use a
simpler heuristic for deciding whether to start incremental marking.
Bug: v8:10315
Change-Id: I2b94e8273c8be860157fe9670797048ed1c5c3da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184149
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67675}
This patch provides infrastructure to pin object types to specific
spaces. This allows embedders to create mutual exclusive arenas for
certain (base) types. In future, this will also be used to provide
sliding-window compaction on certain custom spaces.
We mainly preserve the existing infrastructure with the difference
that spaces are now slightly more dynamic than in Blink as they are
kept in a vector instead of a fixed-size array.
The mechanism differs from Blink in that it does not allow the user
object to call allocation methods directly but instead provides a
trait that can be overridden to specify a custom space.
The patch preserves templatization for objects that do not go into
custom spaces to safe a branch in the allocation hot path.
Change-Id: I08aa6932348e2d6258e19c4a32d189865f459f02
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187611
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67666}
This CL introduces:
- Worklist
- MarkingHandler to manage gc marking phase
- Integration into CollectGarbage for atomic pause GC
- MarkingVisitor for main thread marking
Still missing from this CL:
- Proper handling for stack scanning
- Handling of previously not fully constructed objects
Bug: chromium:1056170
Change-Id: I70ac8534dfb898777cf3a06e3119cac8072174fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170526
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67642}
Returned LABs can be of size less than sizeof(FreeListEntry).
Bug: chromium:1056170
Change-Id: Ib4094701472ce7cb5ee20b9fe632651570832dc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2183051
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67635}
Destructors are allowed to allocate without triggering recursive
garbage collections.
This changes NoGCScope to provide a soft-bailout for garbage
collections to avoid introducing yet another scope.
Bug: chromium:1056170
Change-Id: I0fe51a21977ae954221b6b64b2f6e938ff6d3264
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2185131
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67632}
Adds a public method that embedders can use to trigger garbage
collections. Such garbage collections are always required to have a
source and reason specifying which components calls it why.
Change-Id: I6ae983f99227febc1b7f0dd15c191d5b1eaaf3f3
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2181332
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67631}
Motivation:
There were three versions of type decoding for wasm in the codebase.
Not all of them decoded gc types with immediates (reference types)
correctly.
Changes:
- Refactor the wasm binary decoder for unify type decoding.
- Update BranchTypeImmediate and SelectTypeImmediate to handle
reference types.
Reference: https://github.com/WebAssembly/gcR=jkummerow@chromium.org
Bug: v8:7748
Change-Id: I33b38c911d366570ca6ef2723ded5205698e1979
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2179003
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67614}
Move rewriting, scope analysis, and internalization, to be unconditional
operations done after parsing rather than a separate compile phase. This
removes some of the complexity about rememberering when to call
Compiler::Analyze, and makes these paths a bit more uniform.
Also, forbid allocating any more AST strings after AstValueFactory
internalization, by nulling out the Zone. Add an InternalizePartial
method which doesn't null out the zone for those cases where we do want
to be able to allocate after internalizing (e.g. internalization before
scope analysis).
Change-Id: Id444246d8362a1d169baf664fc37657d9576fd96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182458
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67608}
Fully remove the successor blocks when effect-control-linearization
reaches an unreachable node and is maintaining the schedule. Previously
we just updated the current_block_'s successor and removed any
unreachable predecessors from end, however if the current_block_ is not
an original block in the schedule, but a new one added due to control
flow from effect control linearization lowering, the removed successor
blocks could still be re-connected to the end block when they were
lowered. Instead, entirely remove these unreachable blocks from the
predecessor / successor chains, and have the effect-control-linearizer
avoid lowering these blocks entirely.
BUG=chromium:1076569,v8:9684
Change-Id: I4b4216019d55aef5363d88255726b85df8e7ada5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2179842
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67595}
The serializer currently cannot handle a heap state containing
arbitrary compiled Code objects. As a quick fix for the
--stress-snapshot d8 flag, we clear compiled data from the isolate
prior to the serialize-deserialize-verify pass.
With this change, mjsunit tests pass on x64.
The %SerializeDeserializeNow() runtime function would require more
work, since it is not possible to mutate the heap to this extent while
still preserving a runnable host context and isolate. We will need
another solution there.
Drive-by: Skip the stress_snapshot variant except for the mjsunit
suite.
Tbr: machenbach@chromium.org
Bug: v8:10493,v8:10416
Change-Id: Ie110da8b51613fcd69c7f391d3cf8589d6b04dd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182429
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67585}
This ports sweeper logic from Blink into a separate entity - Sweeper.
Concurrent sweeping is in a followup.
Bug: chromium:1056170
Change-Id: I41196225f0d882cb0ab5190d23e297ee2498df6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2167858
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67581}
Marja pointed out that the following code causes a Torque crash:
Convert<Smi>(MessageTemplate::kFoo)
This change is a small fix to not crash in that case.
Bug: v8:7793, v8:10475
Change-Id: I7856366856a4cd7facdb19686a2d4c92b0d04516
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182175
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#67580}
This function is always called right after creating the DefaultPlatform,
hence merge it into the constructor.
R=mlippautz@chromium.org
Change-Id: I4afb14c83740224056157665db6b854c659da0c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182635
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67573}
Wasm modules generated by emscripten today have two ways to point to
debug symbol files, the source mapping url and external debug info
custom sections. To support both, this CL extends CDP to appropriately
report the symbol type and location.
Bug: chromium:1064248
Change-Id: I9076034f6d73901d8a9c5cfd7c2988fb30bb14c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116208
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67571}
This adds PostConstructionCallbackTrait which can be used to get a
callback that is executed right after an object instance is created.
This can be useful for hooks that require to be able to call into
virtual methods.
Bug: chromium:1074061
Change-Id: Idd5ef677fed291bcba81b9a47f2932c9bb5832b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2179385
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67557}
Also makes memory-chunk.h accessible from outside heap which allows
removal of some heap-inl.h includes.
Bug: v8:10473, v8:10496
Change-Id: Iec4fc5ce8ad201f6ee5fd924cc3cd935324429fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172088
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67551}
ROL will be optional operator as arm, arm64 only have ROR.
The reason for this CL is inefficient Wasm codegen for 64-bit
left-rotation.
Bug: v8:10216
Change-Id: I0cd13e4b6de5276a0d0b80eac5ed9c2e52ba1f96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157648
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67518}
Torque desugars try-catch/label constructs with several handlers
into nested try structures, with the first handler ending-up
innermost. So currently, if you write
try {
...
} label Foo {
Throw(...);
} catch (e) {
}
The catch will catch the preceding Throw in another handler.
This is different from how multiple try-catch handlers are done in
languages like Java, where throwing from a preceding catch handler
is not caught by a later one. To avoid this possible ambiguity, this
CL prohibits this pattern, enforcing that a catch handler comes first,
before any other label-handler attached to the same try.
This way, a catch handler never catches from any other handler on the
same try, since they have to come later.
Bug: v8:7793
Change-Id: I943f14b2393d307c4254a3fc3a78f236dbcf86df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2169098
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67516}
The interpreter will be un-shipped soon, hence we cannot have a
compilation hint for interpreted execution.
This CL removes the respective enum value, removes a test which
specifically tested this one option, and adapts other code to use one of
the remaining hints.
R=ahaas@chromium.org
Bug: v8:10389
Change-Id: Ia754f7de95be271000a9e4e10ef2a3ee171da627
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172748
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67491}
This is a reland of 43b885a842
This fixes another signed overflow in the unit test.
Original change's description:
> Reland "[turbofan][csa] optimize Smi untagging better"
>
> This is a reland of ff22ae80e2
>
> Original change's description:
> > [turbofan][csa] optimize Smi untagging better
> >
> > - Introduce new operator variants for signed right-shifts with the
> > additional information that they always shift out zeros.
> > - Use these new operators for Smi untagging.
> > - Merge left-shifts with a preceding Smi-untagging shift.
> > - Optimize comparisons of Smi-untagging shifts to operate on the
> > unshifted word.
> > - Optimize 64bit comparisons of values expanded from 32bit to use
> > a 32bit comparison instead.
> > - Change CodeStubAssembler::UntagSmi to first sign-extend and then
> > right-shift to enable better address computations for Smi indices.
> >
> > Bug: v8:9962
> > Change-Id: If91300f365e8f01457aebf0bd43bdf88b305c460
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135734
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#67378}
>
> Bug: v8:9962
> Change-Id: Ieab0755806c95fb50022eb17596fb0c95f36004c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170001
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67430}
Bug: v8:9962
TBR: neis@chromium.org
Change-Id: I79883db546bf37873b3727b8023ef688507091d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2169103
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67464}
The worklist in this CL is a merge of the worklists of Oilpan and V8. This implementation supports both use cases and should serve as the shared worklist once we start merging the codebase.
Bug: chromium:1056170
Change-Id: I4ecdb475f3900c33eced9249efa112a69c1b2707
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170828
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67459}
HeapVisitor is a simple visitor implementing both visitation and accept
interfaces. HeapVisitor is aimed to replace functions that traverse the
heap in Blink: PrepareForSweep, Sweep, FinalizeSweep, MakeConsistentForGC,
ObjectPayloadSize, VerifyObjectStartBitmap, CollectStatistics, etc.
This CL also introduces a Heap::ObjectPayloadSize function.
Bug: chromium:1056170
Change-Id: I85a2b8b572486bea29704fc436b002d8f7405201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165733
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67458}
Creates a new large-spaces.h and large-spaces.cc to contain
LargeObjectSpace and subclasses.
Bug: v8:10473
Change-Id: Ifdb4eac9df5c8213f992d549e04b612b62f6df0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170826
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67456}
When creating a filler, we pass through whether we need to clear slots
in the old to new remembered set.
This patch adds a verification check that, when we claim we don't need
to clear slots, checks that no slots are set in the remembered set for
the range of the filler. Effectively, this is a range counterpart to
VerifyClearedSlot.
Change-Id: Id994c56d941988cc282463304bc7307a51943e99
Bug: chromium:1075999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139572
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67453}
base::List is only used inside of heap and has some pretty strange
semantics that don't lend themselves to it being a general purpose data
structure so this moves it to heap where it can be safe isolated.
Bug: v8:10454
Change-Id: I7921c22286276432956005c72143b22b0364fc93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170029
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67448}
This reverts commit 43b885a842.
Reason for revert: Still fails on UBSan: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10873
Original change's description:
> Reland "[turbofan][csa] optimize Smi untagging better"
>
> This is a reland of ff22ae80e2
>
> Original change's description:
> > [turbofan][csa] optimize Smi untagging better
> >
> > - Introduce new operator variants for signed right-shifts with the
> > additional information that they always shift out zeros.
> > - Use these new operators for Smi untagging.
> > - Merge left-shifts with a preceding Smi-untagging shift.
> > - Optimize comparisons of Smi-untagging shifts to operate on the
> > unshifted word.
> > - Optimize 64bit comparisons of values expanded from 32bit to use
> > a 32bit comparison instead.
> > - Change CodeStubAssembler::UntagSmi to first sign-extend and then
> > right-shift to enable better address computations for Smi indices.
> >
> > Bug: v8:9962
> > Change-Id: If91300f365e8f01457aebf0bd43bdf88b305c460
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135734
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#67378}
>
> Bug: v8:9962
> Change-Id: Ieab0755806c95fb50022eb17596fb0c95f36004c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170001
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67430}
TBR=neis@chromium.org,tebbi@chromium.org
Change-Id: I49e19811ebcecb846f61291bc0c4a0d8b0bc4cff
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9962
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168876
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67431}
This is a reland of ff22ae80e2
Original change's description:
> [turbofan][csa] optimize Smi untagging better
>
> - Introduce new operator variants for signed right-shifts with the
> additional information that they always shift out zeros.
> - Use these new operators for Smi untagging.
> - Merge left-shifts with a preceding Smi-untagging shift.
> - Optimize comparisons of Smi-untagging shifts to operate on the
> unshifted word.
> - Optimize 64bit comparisons of values expanded from 32bit to use
> a 32bit comparison instead.
> - Change CodeStubAssembler::UntagSmi to first sign-extend and then
> right-shift to enable better address computations for Smi indices.
>
> Bug: v8:9962
> Change-Id: If91300f365e8f01457aebf0bd43bdf88b305c460
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135734
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67378}
Bug: v8:9962
Change-Id: Ieab0755806c95fb50022eb17596fb0c95f36004c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170001
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67430}
This adds the following:
1) Heap object structure classes: RawHeap, BaseArena and BasePage.
- freelist
- linear allocation block
2) ObjectAllocator, a class responsible for object (and page) allocation.
The design doc with UML design: https://bit.ly/2VVTcqc
User defined arenas are followup.
Bug: chromium:1056170
Change-Id: I69a82974bd08e3cf3da90041b1628297cc890891
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2167392
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67425}
Extend the flag parameter with a bit that decides if the input should
be converted (-0 to 0, and a string to the array index it represents).
Instruct redundancy elimination to never replace x with CheckBounds(x)
when this CheckBounds is of the converting kind.
Bug: chromium:1070892, chromium:1071743
Change-Id: I3125a6e267d56dae6bf6cb2f5f52d27ef65d7c79
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157365
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67408}
This reverts commit ff22ae80e2.
Reason for revert: new test fails on UBSAN
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10831
Original change's description:
> [turbofan][csa] optimize Smi untagging better
>
> - Introduce new operator variants for signed right-shifts with the
> additional information that they always shift out zeros.
> - Use these new operators for Smi untagging.
> - Merge left-shifts with a preceding Smi-untagging shift.
> - Optimize comparisons of Smi-untagging shifts to operate on the
> unshifted word.
> - Optimize 64bit comparisons of values expanded from 32bit to use
> a 32bit comparison instead.
> - Change CodeStubAssembler::UntagSmi to first sign-extend and then
> right-shift to enable better address computations for Smi indices.
>
> Bug: v8:9962
> Change-Id: If91300f365e8f01457aebf0bd43bdf88b305c460
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135734
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67378}
TBR=neis@chromium.org,tebbi@chromium.org
Change-Id: I2617d7a44e5ae33fd79322d37c8b722c00162d22
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9962
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165873
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67380}
- Introduce new operator variants for signed right-shifts with the
additional information that they always shift out zeros.
- Use these new operators for Smi untagging.
- Merge left-shifts with a preceding Smi-untagging shift.
- Optimize comparisons of Smi-untagging shifts to operate on the
unshifted word.
- Optimize 64bit comparisons of values expanded from 32bit to use
a 32bit comparison instead.
- Change CodeStubAssembler::UntagSmi to first sign-extend and then
right-shift to enable better address computations for Smi indices.
Bug: v8:9962
Change-Id: If91300f365e8f01457aebf0bd43bdf88b305c460
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135734
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67378}
The impl works by posting up to NumberOfWorkerThreads() tasks
with CallOnWorkerThread().
Change-Id: I188ac57c9e5d6e3befdcc6f945fbf337dabe1d1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2130886
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67368}
This is a reland of 29c1eab92e
Original change's description:
> [builtins] Clean up the use of class_name / ES5 [[Class]]
>
> Before ES2015, the ES spec had a [[Class]] internal slot for all
> objects, which Object.prototype.toString() would use to figure the
> returned string. Post-ES2015, the [[Class]] slot was removed in spec for
> all objects, with the @@toStringTag well-known symbol the proper way to
> change Object.prototype.toString() output.
>
> At the time, spec-identical handling without the use of [[Class]] was
> implemented in V8 for all objects other than API objects, where issues
> with the Web IDL spec [1] prevented Blink, and hence V8, to totally
> migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
> @@toStringTag on API class prototypes to manage the
> Object.prototype.toString() output, so the legacy [[Class]] handling in
> V8 has not been necessary for the past couple of years.
>
> This CL removes the remaining legacy [[Class]] handling in
> Object.prototype.toString(), JSReceiver::class_name(), and
> GetConstructorName(). However, it does not remove the class_name field
> in FunctionTemplateInfo, as it is still used for the `name` property of
> created functions.
>
> This CL also cleans up other places in the codebase that still reference
> [[Class]].
>
> This change should have minimal impact on web-compatibility. For the
> change to be observable, a script must do one of the following:
>
> 1. delete APIConstructor.prototype[Symbol.toStringTag];
> 2. Object.setPrototypeOf(apiObject, somethingElse);
>
> Before this CL, these changes will not change the apiObject.toString()
> output. But after this CL, they will make apiObject.toString() show
> "[object Object]" (in the first case) or the @@toStringTag of the other
> prototype (in the latter case).
>
> However, both are deemed unlikely. @@toStringTag is not well-known
> feature of JavaScript, nor does it get tampered much on API
> constructors. In the second case, setting the prototype of an API object
> would effectly render the object useless, as all its methods (including
> property getters/setters) would no longer be accessible.
>
> Currently, @@toStringTag-based API object branding is not yet
> implemented by other browsers. This V8 bug in particular has been an
> impediment to standardizing toString behavior. Fixing this bug will
> unblock [3] and lead to a better Web IDL spec, and better toString()
> compatibility for all.
>
> [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
> [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
> [3]: https://github.com/heycam/webidl/pull/357
>
> Bug: chromium:793406
> Cq-Include-Trybots: luci.chromium.try:linux-rel
> Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67327}
Bug: chromium:793406
Change-Id: Ia5d97bd4e1c44cadc6f18a17ffc9d06b038cf8f1
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/+/2163881
Auto-Submit: Timothy Gu <timothygu@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67361}
This reverts commit 29c1eab92e.
Reason for revert: Causes Blink test failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4222
Original change's description:
> [builtins] Clean up the use of class_name / ES5 [[Class]]
>
> Before ES2015, the ES spec had a [[Class]] internal slot for all
> objects, which Object.prototype.toString() would use to figure the
> returned string. Post-ES2015, the [[Class]] slot was removed in spec for
> all objects, with the @@toStringTag well-known symbol the proper way to
> change Object.prototype.toString() output.
>
> At the time, spec-identical handling without the use of [[Class]] was
> implemented in V8 for all objects other than API objects, where issues
> with the Web IDL spec [1] prevented Blink, and hence V8, to totally
> migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
> @@toStringTag on API class prototypes to manage the
> Object.prototype.toString() output, so the legacy [[Class]] handling in
> V8 has not been necessary for the past couple of years.
>
> This CL removes the remaining legacy [[Class]] handling in
> Object.prototype.toString(), JSReceiver::class_name(), and
> GetConstructorName(). However, it does not remove the class_name field
> in FunctionTemplateInfo, as it is still used for the `name` property of
> created functions.
>
> This CL also cleans up other places in the codebase that still reference
> [[Class]].
>
> This change should have minimal impact on web-compatibility. For the
> change to be observable, a script must do one of the following:
>
> 1. delete APIConstructor.prototype[Symbol.toStringTag];
> 2. Object.setPrototypeOf(apiObject, somethingElse);
>
> Before this CL, these changes will not change the apiObject.toString()
> output. But after this CL, they will make apiObject.toString() show
> "[object Object]" (in the first case) or the @@toStringTag of the other
> prototype (in the latter case).
>
> However, both are deemed unlikely. @@toStringTag is not well-known
> feature of JavaScript, nor does it get tampered much on API
> constructors. In the second case, setting the prototype of an API object
> would effectly render the object useless, as all its methods (including
> property getters/setters) would no longer be accessible.
>
> Currently, @@toStringTag-based API object branding is not yet
> implemented by other browsers. This V8 bug in particular has been an
> impediment to standardizing toString behavior. Fixing this bug will
> unblock [3] and lead to a better Web IDL spec, and better toString()
> compatibility for all.
>
> [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
> [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
> [3]: https://github.com/heycam/webidl/pull/357
>
> Bug: chromium:793406
> Cq-Include-Trybots: luci.chromium.try:linux-rel
> Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67327}
TBR=verwaest@chromium.org,timothygu@chromium.org
Change-Id: I678d2ffc1064b1d1ddb62024cc23c6c41b216ef4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:793406
Cq-Include-Trybots: luci.chromium.try:linux-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163956
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67349}
Introduce an OffThreadTransferHandle (and OffThreadTransferMaybeHandle),
which points to a piece of storage known to (and owned by) the
OffThreadIsolate. On Publish, the OffThreadIsolate converts this storage
stub from a raw pointer to an off-thread object into a main-thread
Handle.
This allows users of an OffThreadIsolate to not have to worry (as much)
about the dance of saving raw object pointers before off-thread finishes
and converting those to Handles before it off-thread isolate is
published.
Bug: chromium:1011762
Change-Id: I7ceb4ed85e770bd6e1867649188597bbcaedb32d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161066
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67337}
Move the persistent compilation state and Isolate inputs (such as the
allocator, shared AST constants, hash seed, logger, etc.) which survives
across both parse and compile, out of ParseInfo and into a new
UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState
for per-thread state such as stack limit and RCS.
In particular, this new state survives the ParseInfo being destructed,
which means it is available after off-thread finalization. This allows a
followup to access the PendingCompilationErrorHandler after finalization
and report errors on merge.
Bug: v8:10314
Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67329}
Before ES2015, the ES spec had a [[Class]] internal slot for all
objects, which Object.prototype.toString() would use to figure the
returned string. Post-ES2015, the [[Class]] slot was removed in spec for
all objects, with the @@toStringTag well-known symbol the proper way to
change Object.prototype.toString() output.
At the time, spec-identical handling without the use of [[Class]] was
implemented in V8 for all objects other than API objects, where issues
with the Web IDL spec [1] prevented Blink, and hence V8, to totally
migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
@@toStringTag on API class prototypes to manage the
Object.prototype.toString() output, so the legacy [[Class]] handling in
V8 has not been necessary for the past couple of years.
This CL removes the remaining legacy [[Class]] handling in
Object.prototype.toString(), JSReceiver::class_name(), and
GetConstructorName(). However, it does not remove the class_name field
in FunctionTemplateInfo, as it is still used for the `name` property of
created functions.
This CL also cleans up other places in the codebase that still reference
[[Class]].
This change should have minimal impact on web-compatibility. For the
change to be observable, a script must do one of the following:
1. delete APIConstructor.prototype[Symbol.toStringTag];
2. Object.setPrototypeOf(apiObject, somethingElse);
Before this CL, these changes will not change the apiObject.toString()
output. But after this CL, they will make apiObject.toString() show
"[object Object]" (in the first case) or the @@toStringTag of the other
prototype (in the latter case).
However, both are deemed unlikely. @@toStringTag is not well-known
feature of JavaScript, nor does it get tampered much on API
constructors. In the second case, setting the prototype of an API object
would effectly render the object useless, as all its methods (including
property getters/setters) would no longer be accessible.
Currently, @@toStringTag-based API object branding is not yet
implemented by other browsers. This V8 bug in particular has been an
impediment to standardizing toString behavior. Fixing this bug will
unblock [3] and lead to a better Web IDL spec, and better toString()
compatibility for all.
[1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
[2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
[3]: https://github.com/heycam/webidl/pull/357
Bug: chromium:793406
Cq-Include-Trybots: luci.chromium.try:linux-rel
Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67327}
- implemented as a single-linked list with head and tail
pointers. The tail pointer is needed for freelist appending;
- stores entries in buckets, where bucket[log2(size)] stores
entries >= size;
- implements worst fit allocation to amortize free list call;
- ported from Blink: https://bit.ly/2yC8XKJ.
Bug: chromium:1056170
Change-Id: I26cf62c948c95a7cbfecd5f7f22ad975e6b8c732
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157376
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67310}
This is a reland of e1b93a4ff5
which was a reland of 313d4844d9
which was a reland of 0a59e0cb08
which was a reland of 146f5375da
which was a reland of d91679bf3a
Give up on using C++ bitfields, go back to having base::BitField and
getters/setters.
Original change's description:
> [parser] Introduce UnoptimizedCompileFlags
>
> UnoptimizedCompileFlags defines the input flags shared between parse and
> compile (currently parse-only). It is set initially with some values, and
> is immutable after being passed to ParseInfo (ParseInfo still has getters
> for the fields, but no setters).
>
> Since a few of the existing flags were output flags, ParseInfo now has a
> new output_flags field, which will eventually migrate to a ParseOutputs
> structure.
>
> Bug: v8:10314
> Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66782}
TBR=ulan@chromium.org,szuend@chromium.org
Bug: v8:10314
Change-Id: I54bcd107a0e85cf1a2ddeef0759100547eb65652
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157378
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67309}
This is a reland of 80843eda31
Original change's description:
> [torque] Allow storing to bitfield structs that are stored in Smis
>
> This change:
> 1. Updates the Torque compiler to allow direct access to bitfields that
> are packed within Smi values, which previously would have required a
> separate untagging step,
> 2. Updates JSRegExpStringIterator to represent its flags in Torque,
> 3. Adds reduction cases in MachineOperatorReducer for when the input to
> a branch or the left-hand side of a Word32Equals is based on a 64-bit
> shift-and-mask operation which has been truncated to 32 bits, as is
> the case in the code generated by step 1, and
> 4. Adds a reduction case in MachineOperatorReducer to remove an extra
> Word64And operation added by step 1.
>
> Bug: v8:7793
> Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67290}
Bug: v8:7793
Change-Id: I783b6ec080042fec0e922927f6675dede458a072
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159731
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67305}
When compiling modules with many functions, the list of regions in the
{DisjointAllocationPool} can become quite large if the functions die in
a random order (which they typically do, since the order of Liftoff
compilation is different than the order to TurboFan compilation; which
work stealing, both are nondeterministic).
Iterating the list of regions in the {DisjointAllocationPool} was thus
linear in the number of regions, which is linear in the number of
functions of the module. Since we insert new regions one by one, overall
runtime was quadratic.
This CL fixes this by switching from a linked list to a std::set.
Merging a new region is thus logarithmic instead of linear, and overall
we are {n*log(n)} instead of {n^2}.
Note: For {AllocateInRegion} we still need to linearly iterate all
regions that overlap the requested region, but this has not shown to be
a problem so far.
R=ahaas@chromium.org
Bug: v8:10432
Change-Id: I193e56c2abab782e386194fbe64dadfa250916f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154797
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67303}
This reverts commit 80843eda31.
Reason for revert: Causes compilation failure on macs
https://ci.chromium.org/p/v8/builders/ci/Mac%20V8%20FYI%20Release%20(Intel)/8934?
Original change's description:
> [torque] Allow storing to bitfield structs that are stored in Smis
>
> This change:
> 1. Updates the Torque compiler to allow direct access to bitfields that
> are packed within Smi values, which previously would have required a
> separate untagging step,
> 2. Updates JSRegExpStringIterator to represent its flags in Torque,
> 3. Adds reduction cases in MachineOperatorReducer for when the input to
> a branch or the left-hand side of a Word32Equals is based on a 64-bit
> shift-and-mask operation which has been truncated to 32 bits, as is
> the case in the code generated by step 1, and
> 4. Adds a reduction case in MachineOperatorReducer to remove an extra
> Word64And operation added by step 1.
>
> Bug: v8:7793
> Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67290}
TBR=tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org
Change-Id: Ifa683c92631291c9437438682b6efb2e12862682
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159730
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67291}
This change:
1. Updates the Torque compiler to allow direct access to bitfields that
are packed within Smi values, which previously would have required a
separate untagging step,
2. Updates JSRegExpStringIterator to represent its flags in Torque,
3. Adds reduction cases in MachineOperatorReducer for when the input to
a branch or the left-hand side of a Word32Equals is based on a 64-bit
shift-and-mask operation which has been truncated to 32 bits, as is
the case in the code generated by step 1, and
4. Adds a reduction case in MachineOperatorReducer to remove an extra
Word64And operation added by step 1.
Bug: v8:7793
Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67290}
This reverts commit e1b93a4ff5.
Reason for revert: MSVC failing https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/13274
Original change's description:
> Reland^4 "[parser] Introduce UnoptimizedCompileFlags"
>
> This is a reland of 313d4844d9
> which was a reland of 0a59e0cb08
> which was a reland of 146f5375da
> which was a reland of d91679bf3a
>
> Manually zero out flags with memset, since GCC appears not to initialize
> the bitfield values to zero even with a default constructor.
>
> Original change's description:
> > [parser] Introduce UnoptimizedCompileFlags
> >
> > UnoptimizedCompileFlags defines the input flags shared between parse and
> > compile (currently parse-only). It is set initially with some values, and
> > is immutable after being passed to ParseInfo (ParseInfo still has getters
> > for the fields, but no setters).
> >
> > Since a few of the existing flags were output flags, ParseInfo now has a
> > new output_flags field, which will eventually migrate to a ParseOutputs
> > structure.
> >
> > Bug: v8:10314
> > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Simon Zünd <szuend@chromium.org>
> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66782}
>
> TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
>
> Bug: v8:10314
> Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67271}
TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org
Change-Id: I0f41e847d4edae67e131cc6d0f782137ab73bac2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157377
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67275}
This is a reland of 313d4844d9
which was a reland of 0a59e0cb08
which was a reland of 146f5375da
which was a reland of d91679bf3a
Manually zero out flags with memset, since GCC appears not to initialize
the bitfield values to zero even with a default constructor.
Original change's description:
> [parser] Introduce UnoptimizedCompileFlags
>
> UnoptimizedCompileFlags defines the input flags shared between parse and
> compile (currently parse-only). It is set initially with some values, and
> is immutable after being passed to ParseInfo (ParseInfo still has getters
> for the fields, but no setters).
>
> Since a few of the existing flags were output flags, ParseInfo now has a
> new output_flags field, which will eventually migrate to a ParseOutputs
> structure.
>
> Bug: v8:10314
> Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66782}
TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
Bug: v8:10314
Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67271}
Refactors out the allocation and space merging parts of OffThreadFactory
into a new OffThreadHeap class. This allows a separation of concerns
between allocating/merging and initializing, and future-proofs the
factory code against off-thread allocation implementation changes (e.g.
LocalHeap).
Bug: chromium:1011762
Change-Id: I876906dbfd50f8aafe56af2e63e5fe35e4f7f8e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157369
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67270}
This reverts commit 313d4844d9.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/6354
Original change's description:
> Reland^3 "[parser] Introduce UnoptimizedCompileFlags"
>
> This is a reland of 0a59e0cb08
> which was a reland of 146f5375da
> which was a reland of d91679bf3a
>
> Initializes the BackgroundCompileTasks's language_mode in the
> constructor (previously only initialized after successful parse) in case
> the parse failed. We still need to reset it after parse in case the
> language mode changed (because we encountered "use strict").
>
> Original change's description:
> > [parser] Introduce UnoptimizedCompileFlags
> >
> > UnoptimizedCompileFlags defines the input flags shared between parse and
> > compile (currently parse-only). It is set initially with some values, and
> > is immutable after being passed to ParseInfo (ParseInfo still has getters
> > for the fields, but no setters).
> >
> > Since a few of the existing flags were output flags, ParseInfo now has a
> > new output_flags field, which will eventually migrate to a ParseOutputs
> > structure.
> >
> > Bug: v8:10314
> > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Simon Zünd <szuend@chromium.org>
> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66782}
>
> TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
>
> Bug: v8:10314
> Change-Id: Ieee0bbfade4fe0b56de03bff47a7364959608d6a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157367
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67265}
TBR=leszeks@chromium.org
Change-Id: I90ac035caa76d4c4baf5ce207247d1ce5169fb2f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157370
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67266}
This is a reland of 0a59e0cb08
which was a reland of 146f5375da
which was a reland of d91679bf3a
Initializes the BackgroundCompileTasks's language_mode in the
constructor (previously only initialized after successful parse) in case
the parse failed. We still need to reset it after parse in case the
language mode changed (because we encountered "use strict").
Original change's description:
> [parser] Introduce UnoptimizedCompileFlags
>
> UnoptimizedCompileFlags defines the input flags shared between parse and
> compile (currently parse-only). It is set initially with some values, and
> is immutable after being passed to ParseInfo (ParseInfo still has getters
> for the fields, but no setters).
>
> Since a few of the existing flags were output flags, ParseInfo now has a
> new output_flags field, which will eventually migrate to a ParseOutputs
> structure.
>
> Bug: v8:10314
> Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66782}
TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
Bug: v8:10314
Change-Id: Ieee0bbfade4fe0b56de03bff47a7364959608d6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157367
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67265}
This reverts commit f442b03fe2.
Reason for reland: Wrongly reverted.
Original change's description:
> Revert "[turbofan] Fix bug in Number.Min/Max typings"
>
> This reverts commit 4158af83db.
>
> Reason for revert: causing UBSAN failures:
>
> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729?
>
>
> Original change's description:
> > [turbofan] Fix bug in Number.Min/Max typings
> >
> > They try to be very precise about when the result can be -0,
> > but do so incorrectly. I'm changing the code to just do the
> > simple thing instead. Let's see how that affects performance.
> >
> > Bug: chromium:1072171
> > Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#67246}
>
> TBR=neis@chromium.org,tebbi@chromium.org
>
> Change-Id: I0d9b312e27f5a8bbbebeccdc9819fa94f10af139
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1072171
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157646
> Reviewed-by: Francis McCabe <fgm@chromium.org>
> Commit-Queue: Francis McCabe <fgm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67249}
TBR=neis@chromium.org,tebbi@chromium.org,fgm@chromium.org
Change-Id: Ida36ca584a5af5da887189328c8da195b26285d4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1072171
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157368
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67263}
This reverts commit 0a59e0cb08.
Reason for revert: Still causing UBSAN issues:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729
Original change's description:
> Reland^2 "[parser] Introduce UnoptimizedCompileFlags"
>
> This is a reland of d91679bf3a
> which was a reland of d91679bf3a
>
> Fixes missing initialization of ParserBase::allow_eval_cache_
>
> Original change's description:
> > [parser] Introduce UnoptimizedCompileFlags
> >
> > UnoptimizedCompileFlags defines the input flags shared between parse and
> > compile (currently parse-only). It is set initially with some values, and
> > is immutable after being passed to ParseInfo (ParseInfo still has getters
> > for the fields, but no setters).
> >
> > Since a few of the existing flags were output flags, ParseInfo now has a
> > new output_flags field, which will eventually migrate to a ParseOutputs
> > structure.
> >
> > Bug: v8:10314
> > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Simon Zünd <szuend@chromium.org>
> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66782}
>
> TBR=rmcilroy@chromium.org,ulan@chromium.org,szuend@chromium.org
>
> Bug: v8:10314
> Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67245}
TBR=rmcilroy@chromium.org,leszeks@chromium.org
Change-Id: I1c5f58cc5608217a149b04aa6f50bb3d7606c26d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157657
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67250}
This reverts commit 4158af83db.
Reason for revert: causing UBSAN failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729?
Original change's description:
> [turbofan] Fix bug in Number.Min/Max typings
>
> They try to be very precise about when the result can be -0,
> but do so incorrectly. I'm changing the code to just do the
> simple thing instead. Let's see how that affects performance.
>
> Bug: chromium:1072171
> Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67246}
TBR=neis@chromium.org,tebbi@chromium.org
Change-Id: I0d9b312e27f5a8bbbebeccdc9819fa94f10af139
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1072171
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157646
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67249}
They try to be very precise about when the result can be -0,
but do so incorrectly. I'm changing the code to just do the
simple thing instead. Let's see how that affects performance.
Bug: chromium:1072171
Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67246}
This is a reland of d91679bf3a
which was a reland of d91679bf3a
Fixes missing initialization of ParserBase::allow_eval_cache_
Original change's description:
> [parser] Introduce UnoptimizedCompileFlags
>
> UnoptimizedCompileFlags defines the input flags shared between parse and
> compile (currently parse-only). It is set initially with some values, and
> is immutable after being passed to ParseInfo (ParseInfo still has getters
> for the fields, but no setters).
>
> Since a few of the existing flags were output flags, ParseInfo now has a
> new output_flags field, which will eventually migrate to a ParseOutputs
> structure.
>
> Bug: v8:10314
> Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66782}
TBR=rmcilroy@chromium.org,ulan@chromium.org,szuend@chromium.org
Bug: v8:10314
Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67245}
This reverts commit 146f5375da.
Reason for revert: UBSan (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10726?)
Original change's description:
> Reland "[parser] Introduce UnoptimizedCompileFlags"
>
> This is a reland of d91679bf3a
>
> This reland adds initializers for the output flags.
>
> Original change's description:
> > [parser] Introduce UnoptimizedCompileFlags
> >
> > UnoptimizedCompileFlags defines the input flags shared between parse and
> > compile (currently parse-only). It is set initially with some values, and
> > is immutable after being passed to ParseInfo (ParseInfo still has getters
> > for the fields, but no setters).
> >
> > Since a few of the existing flags were output flags, ParseInfo now has a
> > new output_flags field, which will eventually migrate to a ParseOutputs
> > structure.
> >
> > Bug: v8:10314
> > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Simon Zünd <szuend@chromium.org>
> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66782}
>
> Bug: v8:10314
> Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67241}
TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org
Change-Id: I204eb9e4d0a5bfaeeefeb6b0f1c82856b57cb175
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157029
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67242}
This is a reland of d91679bf3a
This reland adds initializers for the output flags.
Original change's description:
> [parser] Introduce UnoptimizedCompileFlags
>
> UnoptimizedCompileFlags defines the input flags shared between parse and
> compile (currently parse-only). It is set initially with some values, and
> is immutable after being passed to ParseInfo (ParseInfo still has getters
> for the fields, but no setters).
>
> Since a few of the existing flags were output flags, ParseInfo now has a
> new output_flags field, which will eventually migrate to a ParseOutputs
> structure.
>
> Bug: v8:10314
> Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66782}
Bug: v8:10314
Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67241}
Deserializer can trigger OOB read in the marking bitmap inside the
RegisterDeserializedObjectsForBlackAllocation function. This happens
for example if an internalized string is deserialized as the last object
on a page and is the turned into a thin-string leaving a one-word filler
at the end of the page. In such a case IsBlack(filler) will try to fetch
a cell outside the marking bitmap.
The fix is to increase the size of the marking bitmap by one cell, so
that it is always safe to query markbits of any object on a page.
Bug: chromium:978156
Change-Id: If3c74e4f97d2caeb3c3f37a4147f38dea5f0e5a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152838
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67223}
{StaticCharVector}, according to its name, should return a
{Vector<const char>}. For getting a {Vector<const uint8_t>}, the method
should be called {StaticOneByteVector}, analog to the
{OneByteVector} methods that already exist.
Also, {StaticCharVector} is constexpr, but {StaticOneByteVector} cannot
be, since it contains a {reinterpret_cast}. The same holds for
{Vector::cast} in general.
This CL
- changes the return type of {StaticCharVector} to be
{Vector<const char>},
- introduces a new {StaticOneByteVector} which returns
{Vector<const uint8_t>},
- fixes constexpr annotations at various methods returning {Vector}s,
- refactors users of {StaticCharVector} to either use
{StaticOneByteVector} instead, or work on {char} if that makes more
sense.
R=leszeks@chromium.org
Bug: v8:10426
Change-Id: I71e336097e41ad30f982aa6344ca3d67b3a01fe3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154196
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67213}
Test some constexpr factories. StaticCharVector is not actually
constexpr, this will be fixed in a follow-up CL.
R=leszeks@chromium.org
Bug: v8:10426
Change-Id: I16fdf79cd7d4b3f54d7cf73e15bdff2306810f06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154192
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67210}
These opcodes are not officially specified yet, they are defined
in the "prototype implementation spec" at https://bit.ly/3cWcm6Q.
Drive-by: drop a unit test whose entire coverage can be provided
by a compile-time check.
Bug: v8:7748
Change-Id: Icefa6dd321802c8a01c4561178b9d21eca1fbaa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152841
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67208}
This changelist adds to the GDB stub (in class wasm::gdb_server::Target) the
logic to decode and execute GDB-remote commands and to format response packets
to be sent back to the debugger.
Here most of the commands still act as a NOOP; the actual implementation
requires interactions with the Wasm engine and will be implemented in the next
CL of this series.
Build with: v8_enable_wasm_gdb_remote_debugging = true
Run with: --wasm-gdb-remote
Bug: chromium:1010467
Change-Id: Icfa63be9e1eaa657c05876d0d4e86927e0885b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938466
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@{#67200}
This changelist adds the logic to format, decode, sends and receive packets in
the format specified by the GDB-remote protocol
(https://sourceware.org/gdb/onlinedocs/gdb/Overview.html#Overview).
Build with: v8_enable_wasm_gdb_remote_debugging = true
Run with: --wasm-gdb-remote
Bug: chromium:1010467
Change-Id: Ibc9c6713c561d06847b472fab591c208c193199f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929409
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@{#67196}
SIMD opcodes consist of the prefix byte, then an LEB128 encoded int. We
were decoding this incorrectly as a fixed uint8. This fixes the decoder
to properly handle multi bytes.
In some cases, the multi byte logic is applied to all prefixed opcodes.
This is not a problem, since for values < 0x80, the LEB encoding is a
single byte, and decodes to the same int. If the prefix opcode has
instructions with index >= 0x80, it would be required to be LEB128
encoded anyway.
There are a bunch of trivial changes to test-run-wasm-simd, to change
the macro from BUILD to BUILD_V, the former only works for single byte
opcodes, the latter is a new template-based macro that correct handles
multi-byte opcodes. The only unchanged test is the shuffle fuzzer test,
which builds its own sequence of bytes without using the BUILD macro.
Bug: v8:10258
Change-Id: Ie7377e899a7eab97ecf28176fd908babc08d0f19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118476
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67186}
This adds support for custom weak callbacks through static callbacks and
instance methods.
Bug: chromium:1056170
Change-Id: Ie4bd32539e0d933b192f07edb2d45e0070c2128d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148784
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67167}
When memory.grow was executed concurrently on multiple threads a data
race could happen such that two memory.grow operations result in the
same return value. With this CL the return value of memory.grow is
unique, given that memory.grow actually grows the memory.
As a concrete example, assume a shared WebAssembly memory initially has
a size of 100. Assume two threads call memory.grow concurrently with a
parameter `10`. Then with the existing code, memory would grow correctly
to a size of 120, but the data race may cause both memory.grow
operations to return 100. With the change in this CL one memory.grow
operation would return 100, the other would return 110.
R=gdeepti@chromium.orgCC=rreverser@google.com
Bug: chromium:1067621
Change-Id: Ib22b5135714a56799e0818ccb39e5dce327e5f8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144113
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67135}
AIX default page size is 4096 bytes hence
PlatformUsesGuardPages returns true. Power Linux however
has a default page size of 65536 bytes and the above function
is expected to return false. More info is available
at https://crrev.com/c/2144060.
Change-Id: I35a13ada5bd1b18729cfa039a0bc699a409fbc2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2147634
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67134}
A few notes:
1) Oilpan is a generic library, meaning that it can work with arbitrary
user types. The library is split in type-aware (include/) and
type-erased (src/) parts. The former comprises a lot of code that still
needs to be defended with dchecks;
2) Macros are prefixed with CPPGC_, so that they don't clash in the user
code with similar macros from other libraries;
3) The macros simply forward requests to V8 so that dcheck handlers can
be configured uniformly;
4) The CL doesn't contain CHECK_EQ and friends, but they can be added
later if needed.
Bug: chromium:1056170
Change-Id: I68e6f663247705233eaf030384164d81e53071e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2148774
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67129}
This is a port of src/components/gc that was added recently.
Differences:
- Added back bucketing to the page pool, as that guarantees that
arenas used for specific types do not have their pages used by other
arenas.
- Replaced base::flat_map with std::map. This may cause performance
regressions when using PageMemoryRegionTree in hot paths. A
vector-like representation may be used to fix such a regression
This reverts commit a056cea51e.
Bug: chromium:1056170
Change-Id: Iffb8b0d91c8cca1815d7a1cda9486e7716aea75f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144060
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67117}
Change the unittests Isolate mixin to create one Isolate per test,
rather than one per test suite. We usually run these tests independently
in separate processes anyway, so this shouldn't affect normal test
execution, but it will avoid Isolate state leaking across tests when
running the unittests binary directly.
Take this opportunity to also clean up the mixins, changing counter
initialization and forcing pointer compression into template traits.
Bug: v8:10142
Change-Id: If92046f9c6f2056252d099faed04d97844ef7319
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2143818
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67110}
Provides the infrastructure to register weak callbacks for
WeakMember<T> through visitor. The WeakCallbackInfo broker is used to
query objects for liveness. In a future CL the same broker object is
passed to custom weak callbacks.
Change-Id: I8b5a66354e0e457521989d40ae64a9558c339503
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142265
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67109}
This reverts commit 3e1c70402e.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/12665
Original change's description:
> Reland "cppgc: Add page memory allocation backend"
>
> This is a port of src/components/gc that was added recently.
>
> Differences:
> - Added back bucketing to the page pool, as that guarantees that
> arenas used for specific types do not have their pages used by other
> arenas.
> - Replaced base::flat_map with std::map. This may cause performance
> regressions when using PageMemoryRegionTree in hot paths. A
> vector-like representation may be used to fix such a regression
>
> This reverts commit 656c68a781.
>
> Bug: chromium:1056170
> Change-Id: I638183c944255ebcaab47d2b94b1980d54479746
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2143814
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67080}
TBR=mlippautz@chromium.org,mslekova@chromium.org
Change-Id: I04b048dd979c32e9275c972307796d5f75865037
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144114
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67084}
This is a port of src/components/gc that was added recently.
Differences:
- Added back bucketing to the page pool, as that guarantees that
arenas used for specific types do not have their pages used by other
arenas.
- Replaced base::flat_map with std::map. This may cause performance
regressions when using PageMemoryRegionTree in hot paths. A
vector-like representation may be used to fix such a regression
This reverts commit 656c68a781.
Bug: chromium:1056170
Change-Id: I638183c944255ebcaab47d2b94b1980d54479746
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2143814
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67080}
GetHeapFromPayload returned the page header address instead of the
value of the first field of the header.
Bug: chromium:1056170
Change-Id: I4de5be975accced32460d6fab91543e6a5b07ba0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2143825
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67079}
Fix off-thread space merging unit tests, by
a) Doing a GC on each test teardown (avoiding leaking GC state between
tests), and
b) Removing the AllocationStep when merging, which could cause a
deadlock if incremental marking triggered a free-list refill.
Bug: v8:10142
Change-Id: Id2670115f96ab3b13613ea357bd44a639d0151e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142260
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67077}
This CL provides a basic allocator that allocates normal-sized objects
on pages without ever reusing them. This allows for already using the
backref from page to heap which is used in some critical places
(pre-finalizers, write barrier, Persistent).
Bug: chromium:1056170
Change-Id: Ifada9b7e984827906c267d1a3a521576587feaeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2141736
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67076}
This reverts commit d4056c61d5.
Reason for revert: Fails on GCC, please check https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/6184
Original change's description:
> cppgc: Add page memory allocation backend
>
> This is a port of src/components/gc that was added recently.
>
> Differences:
> - Added back bucketing to the page pool, as that guarantees that
> arenas used for specific types do not have their pages used by other
> arenas.
> - Replaced base::flat_map with std::map. This may cause performance
> regressions when using PageMemoryRegionTree in hot paths. A
> vector-like representation may be used to fix such a regression
>
> Bug: chromium:1056170
> Change-Id: I03e3abe55faf7bb50c8011dafc23396889bf66db
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139586
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67073}
TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
Change-Id: I1e421898bb8a08f32d8eb2355ed547e0ee38b429
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2140949
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67074}
This is a port of src/components/gc that was added recently.
Differences:
- Added back bucketing to the page pool, as that guarantees that
arenas used for specific types do not have their pages used by other
arenas.
- Replaced base::flat_map with std::map. This may cause performance
regressions when using PageMemoryRegionTree in hot paths. A
vector-like representation may be used to fix such a regression
Bug: chromium:1056170
Change-Id: I03e3abe55faf7bb50c8011dafc23396889bf66db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139586
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67073}
This change comprises a few tiny changes wrt Member:
1) Move member policies to a separate file so that some of them
(CheckingPolicy) can be reused by Persistent;
2) SFINAE out incompatible pointers from heterogeneous ctor/asgnmt;
3) Rename kMemberSentinel to kSentinelPointer.
Bug: chromium:1056170
Change-Id: I4482998e6ba61005a5d0861dcae9fab2aa43702c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139587
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67061}
Headers containing only implementation details are better to stay in a
separate dir to indicate the user that they shouldn't be included.
Bug: chromium:1056170
Change-Id: I10f84ddf709b146396aadc820ec33bc6a49b2dac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139585
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67050}
Neither Member, nor GarbageCollected objects (and friends) should be
allocated on the stack. Create a special test fixture that allows for
writing idiomatic unit tests that depend on allocation but do not pull
in garbage collection.
Bug: chromium:1056170
Change-Id: I4118201a51658f7247412434a867d35c91299439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139583
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67046}
This CL adds the necessary traits to dispatch from Member through a
visitor implementation for GarabgeCollected and GarbageCollectedMixin.
Bug: chromium:1056170
Change-Id: I12680335044aaa842639fb5e8f9a3ac61587f51a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2138431
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67041}
Assumes that (is_clang = false && is_win) => Windows native (MSVC).
Cross-compile builds will use clang and not the native tools and thus
not fall into this category.
This CL adds x86 and x64 MASM trampolines that can be used with the
native Windows toolchain (ml.exe, ml64.exe), when using is_clang =
false.
This reverts commit 8e4a5e973e.
Bug: chromium:1056170
Change-Id: I7204f15898ec5eddcc5892d4d08266a69d84ab85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139211
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67036}
With this change we support allocation of objects and keeping them
alive via conservative stack scan.
This reverts commit 2b047a58f8.
Change-Id: Iac1913e7ef0556c28399509a160777a89e60150c
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137402
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67016}
With this change we support allocation of objects and keeping them alive via
conservative stack scan.
Change-Id: Id94d7ced503ad0b1378643e0c13c2a8b65ad2327
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135729
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67008}
Effect-control-linearizer will update a basic block to connect it
directly to the end node if it has an Unreachable node. Usually the
block would already have been connected directly to end (via a Throw
node) already, however in some cases it can be connected indirectly
(via a branch, where both end in a throw node).
If this happens, and the Effect-control-linearizer is maintaining the
schedule (e.g., for TurboProp), it will cause the end block to have
unreachable predecessor blocks, which can cause issues with the
register allocator.
To fix this, have the BasicBlockUpdater remove all successor blocks
from the schedule, when they become Unreachable. Also add some tests
to cover this in effect-control-linearizer-unittests.
BUG=v8:10332,v8:9684
Change-Id: Ibce140e6d1f61751a86247e6f8c36075723a1e55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120537
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66994}
We cannot rely on the clang compiler to generate the trampoline entry
and the right mangling because `__attribute__((naked))` does not
prevent clang from generating TSAN function entry stub
(`__tsan_func_entry`). Even with `__attribute__((no_sanitize_thread)`
annotation clang generates the entry stub.
Upstream bug: https://bugs.llvm.org/show_bug.cgi?id=45400
Bug: chromium:1056170
Change-Id: I7a2063d7d205ee071e6a41ce4d9cb2d8d6423987
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132797
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66976}
Use inline asm to generate the x64 PushAllRegistersAndIterateStack
which is the trampoline for conservative stack scanning. Keep the
function definition as C code to allow clang to generate the correct
mangling for each platform.
This approach has the benefit that it immediately works for all
platforms that support clang.
Bug: chromium:1056170
Change-Id: Ic7a1c1b57e67ae1442bd8bda4e55d89112facfc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2132787
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66958}
The tests using the recursive function were broken on non-clang builds
as GCC is able to agressively the function in question and proof that
parameters are not actually needed.
Bug: chromium:1056170
Change-Id: Iacbff766ca9d300c9ae5d16394e205b1883609eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2130274
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66952}
Pure refactoring. The re-organization allows to easily
add more platforms.
Bug: chromium:1056170
Change-Id: Ia191c37a1dabff6952414c5314beeeae881713b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2129636
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66924}
This tests that the stack doesn't get misaligned after asm trampolines.
x86 and x64 psABI requires the stack to be 16 bytes aligned.
Bug: chromium:1056170
Change-Id: I73e7100806c6ecf3f5e884a121a15bcc384d8011
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2128048
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66922}
A previous CL made the mode an explicit argument but failed to
keep SimplifiedLowering from overriding it.
Moreover, CheckedUint64Bounds so far didn't support the two modes.
Change-Id: I01d8bf90fca77940fbeb428da57608a59f812c75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124833
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66921}
Adds support for conservative stack scanning on x64. The trampolines
saving callee-saved registers are compiled using clang (non-Windows)
and MASM (Windows). This is using the default toolchain for assembly
in Chromium/V8.
This differs from Oilpan in Chromium where x86 and x64 are compiled
using NASM [1]. V8 does not yet require this dependency and building
the trampolines natively avoids it. (NASM also requires separate
blocks for x64 Windows and non-Windows.) On non-x86/x64 platforms
Chromium also uses clang, so there's little benefit in keeping the
dependency.
The trampolines are tested when building with clang.
Other platforms follow in separate CLs.
[1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/platform/heap/asm/SaveRegisters_x86.asm
Change-Id: Ice2e23e44391aa94147abe75ee0b5afac458b8f8
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124319
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66913}
iOS does not support death tests.
Bug: v8:10360
Change-Id: Ia86553d53eee811e5521c093fd034115a9d01750
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2128046
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66912}
In order to implement CodeEntry deallocation when profiles are stopped,
we need to be able to effectively deallocate strings. Introduce a simple
imperative refcounting API using the existing HashMap slots for
StringsStorage to enable this.
Design doc: https://docs.google.com/document/d/1OTwlBnAMXZEaOICtuz16c01QnkPPdqHBoHpfGwnk5SY/edit
Bug: chromium:956688
Change-Id: Iaa1142925f40aa66c064d011b2a0630de72037fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2121575
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#66911}
This CL adds basic infrastructure for:
- MakeGarbageCollected
- GarbageCollected and related type traits
- Heap (API / internal)
- Basic allocation based on malloc
- CollectGarbage without marking
This allows for allocation and reclamation through an explicit GC
call. No objects are held alive from any source (stack, globals,
refs), yet.
The exact wiring of platform is future work.
Change-Id: I81b7c0ba7b525188f8c0bf9de3b7af35d34322af
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120538
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66887}
std::atomic loads are marked as nodiscard on MSVC. Fix the warning by
feeding the load into the USE() macro.
Bug: chromium:1056170
Change-Id: I72ca42d42d268c4b961d96618250229a53709472
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120543
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66866}
This reverts commit 0c72c71900.
Reason for revert: Wasm code size increase because not all pipelines use CommonOperatorReducer
Original change's description:
> Move branch inversion on ==0 into platform-agnostic reducer
>
> This change is based on a discussion from
> https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696
> wherein Tobias suggested moving the folding away of ==0 operations out
> of the platform-specific instruction selectors and into the
> MachineOperatorReducer. I noticed that CommonOperatorReducer already
> handles some very similar cases, so I have tried putting the ==0 folding
> into CommonOperatorReducer instead. I'm happy to move it into
> MachineOperatorReducer if that's better; I still don't have a very good
> understanding of how roles are separated among reducers.
>
> Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66688}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1061767
Change-Id: Id1fdfb38357eb514d92ed3be0a683f077202faa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117789
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66862}
This adds HeapObjectHeader, a meta object that is put in front of
every managed object. HeapObjectHeader provides accessors for:
1. GCInfoIndex
2. In construction bit
3. size
4. Mark bit
Meta info is distributed among two uint16_t fields as (1.,2.) and
(3.,4.). This is convenient as the non-bit accessors (size,
GCInfoIndex) are constant during marking.
Object layout see heap-object-header.h.
Note: The current implementation does not bypass ASAN poisoning and
assumes an unpoisoned header whenever performing an access.
Bug: chromium:1056170
Change-Id: I753f15467ed5c2b22b47e64d3aa5a3c1baddf8e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116031
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66861}
For some input types containing -0 but not +0, the result type of
NumberMin and NumberMax would unnecessarily include +0. However, for
some larger inputs, the result type would not include the spurious +0,
thus breaking monotonicity.
The CL fixes this and addresses a TODO as well.
Bug: chromium:1063661
Change-Id: Icd56d6102fbea12a2d96aa063a803b1052c714b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116199
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66854}
Add LocalHandleScope to allow for local handles in LocalHeaps
(background threads). This class is similar to HandleScope which still
needs to be used on the main thread. When performing a GC, the main
thread halts all background threads at a safepoint such that it can
safely iterate their roots.
Bug: v8:10315
Change-Id: Id8f5d54cc2535e004081ccdef15dc03a39b2d0f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111218
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66853}
GCInfo and its related infrastructure is used to record information
about types. Currently, we store finalization and vtable information.
Future changes will introduce naming and tracing, similar to Oilpan in
Blink.
Information is stored in a process-wide global table that is
maintained at runtime. For static builds such information can be
recorded in the binary without the runtime overhead which is future
work.
This ports `third_party/blink/renderer/platform/heap/gc_info.{h,cc}`
on a semantic level. In addition to adjusting to V8's needs, we also
re-commit the already filled parts of the info table as read-only when
possible, making it harder to override type information.
Bug: chromium:1056170
Change-Id: Ib01eb24e6f8a94a4a647efde7af37689f8c20ba2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111214
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66847}
"By my deeds I honor him. V8."
- Add basic build files for library and unittests.
- Integrate unittests also in existing V8 unittests for simplicity.
The CL also adds FinalizerTrait and unittests to allow building a
testing target that executes code.
FinalizerTrait is used to determine how managed C++ types are
finalized. The trait should not be overridable by users but needs to
be exposed on API-level to avoid including library-internal headers.
Bug: chromium:1056170
Change-Id: I64d91053410a17a7835e50547f58990625d2da28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108549
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66834}
Now that it is implicit in function entry and loop iteration, there is
no need for an explicit bytecode.
Also updated tests that used explicit bytecodes.
Bug: v8:10149, v8:9960
Change-Id: I3ca582f276829bd54feb35e6d4ea656a32efbd54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093507
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66811}
Since now the IterationBody StackChecks are implicit within JumpLoops,
we are able to eagerly deopt in them. If we do that, whenever we advance
to the next bytecode we don't have to advance to the next literal
bytecode, but instead "advance" in the sense of doing the JumpLoop.
Adding tests that test this advancing for wide and extra wide JumpLoops.
Also, marking JumpLoop as needing source positions since now it has
the ability of causing an interrupt.
Bug: v8:10149, v8:9960
Fixes: v8:10149
Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66809}
This reverts commit d91679bf3a.
Reason for revert: Seems to cause UBSan errors
Original change's description:
> [parser] Introduce UnoptimizedCompileFlags
>
> UnoptimizedCompileFlags defines the input flags shared between parse and
> compile (currently parse-only). It is set initially with some values, and
> is immutable after being passed to ParseInfo (ParseInfo still has getters
> for the fields, but no setters).
>
> Since a few of the existing flags were output flags, ParseInfo now has a
> new output_flags field, which will eventually migrate to a ParseOutputs
> structure.
>
> Bug: v8:10314
> Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66782}
TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org
Change-Id: Ica139e8862e00cd0560638a0236bbaccd7b2188c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108548
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66783}
UnoptimizedCompileFlags defines the input flags shared between parse and
compile (currently parse-only). It is set initially with some values, and
is immutable after being passed to ParseInfo (ParseInfo still has getters
for the fields, but no setters).
Since a few of the existing flags were output flags, ParseInfo now has a
new output_flags field, which will eventually migrate to a ParseOutputs
structure.
Bug: v8:10314
Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66782}
We don't ever want a node's type to become less precise.
Also move a part of JSTypedLowering::ReduceJSStrictEqual that
can be expressed solely in terms of types into the typer, where
it generalizes an existing case.
Change-Id: I37c58fed48f606f6fe34e98e5f066434e50cb6c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106204
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66763}
- Allow type expression for abstract type supertypes.
For consistency, and ease of implementation, also allow this for enums.
- Allow subtyping of structs. This requires changing all places where we
checked for struct types and instead check if we have a subtype of a
struct type.
- This allows defining two subtypes of the Reference<T> struct for
mutable and constant references. Mutable references are a subtype of
constant references.
- &T desugars to MutableReference<T>
const &T desugars to ConstReference<T>
- A const field of a class produces a constant reference.
A const field of a mutable reference to a struct is const.
A mutable field of a const reference to a struct is const.
- It is possible to assign a new struct value to a mutable reference to
a struct, even if the struct contains const fields. This is analogous
to allowing assignments of let-bound structs with constant fields.
Not in this CL:
- A notion of const slices.
- Applying const to appropriate class fields.
Bug: v8:7793
Change-Id: I6e7b09d44f54db25f8bf812be5f3b554b80414e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096615
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66759}
Generate a BTI instruction at each target of an indirect branch
(BR/BLR). An indirect branch that doesn't jump to a BTI instruction
will generate an exception on a BTI-enabled core. On cores that do
not support the BTI extension, the BTI instruction is a NOP.
Targets of indirect branch instructions include, among other things,
function entrypoints, exception handlers and jump tables. Lazy deopt
exits can potentially be reached through an indirect branch when an
exception is thrown, so they also get an additional BTI instruction.
Bug: v8:10026
Change-Id: I0ebf51071f1b604f60f524096e013dfd64fcd7ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967315
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66751}
Track list of all local heaps in the Safepoint class instead of the
Heap.
Bug: v8:10315
Change-Id: I1a1c847502ab5e8f368d4cc12d3cbaf3672af7cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106197
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66745}
This is a reland of 2c834c5364,
in which node replacement was too aggressive.
Original change's description:
> [turbofan] Clean up ConstantFoldingReducer
>
> Change-Id: Iaf7f83cc157a6f6680da8933560347f7f3503d56
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098736
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66706}
Change-Id: I5d306092dde4119629af4c5e7e424a0e9a14310d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106193
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66742}
Add safepoint mechanism to stop concurrent threads and bring them to a
safepoint. Threads are stopped before the safepoint and after e.g. the
GC resumed again. Each thread needs to be stopped in a safepoint, such
that all roots can be iterated safely.
Running threads need to be cooperative and are required to perform
regular safepoint polls.
The last version of this CL was reverted because safepoint_requested_
wasn't initialized (see https://crrev.com/c/2105634).
Bug: v8:10315
Change-Id: I6ef244c0fb31c178589b5e3d1c62687a8dd65768
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105635
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66732}
This reverts commit c84963eaa7.
Reason for revert: Fails on msan: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/31376
Original change's description:
> [heap] Introduce safepoint mechanism
>
> Add safepoint mechanism to stop concurrent threads and bring them to a
> safepoint. Threads are stopped before the safepoint and after e.g. the
> GC resumed again. Each thread needs to be stopped in a safepoint, such
> that all roots can be iterated safely.
>
> Running threads need to be cooperative and are required to perform
> regular safepoint polls.
>
> Bug: v8:10315
> Change-Id: I47f07e7d2ef5bc5adbba6b9e8e79a1f0f45b97ad
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102578
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66727}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: If11281b2b9fc622b91261417b202676f23f60b50
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105634
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66729}
Add safepoint mechanism to stop concurrent threads and bring them to a
safepoint. Threads are stopped before the safepoint and after e.g. the
GC resumed again. Each thread needs to be stopped in a safepoint, such
that all roots can be iterated safely.
Running threads need to be cooperative and are required to perform
regular safepoint polls.
Bug: v8:10315
Change-Id: I47f07e7d2ef5bc5adbba6b9e8e79a1f0f45b97ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102578
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66727}
This reverts commit 2c834c5364.
Reason for revert: several clusterfuzz issues, e.g. 1061805
Original change's description:
> [turbofan] Clean up ConstantFoldingReducer
>
> Change-Id: Iaf7f83cc157a6f6680da8933560347f7f3503d56
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098736
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66706}
TBR=neis@chromium.org,tebbi@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I6e5b655bb465087a50ebaa2088795c6f920c2e51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2104892
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66717}
This change is based on a discussion from
https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696
wherein Tobias suggested moving the folding away of ==0 operations out
of the platform-specific instruction selectors and into the
MachineOperatorReducer. I noticed that CommonOperatorReducer already
handles some very similar cases, so I have tried putting the ==0 folding
into CommonOperatorReducer instead. I'm happy to move it into
MachineOperatorReducer if that's better; I still don't have a very good
understanding of how roles are separated among reducers.
Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66688}
In preparation for adding reference types, which need an additional
parameter to indicate the referenced type.
Bug: v8:7748
Change-Id: If4023f3d9c7f42ed603b69c43356d2e8b81a0daa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091471
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66687}
... such that we have only a single representation for special
constants such as undefined, namely the corresponding bitset.
With this CL the following property holds:
t1.IsSingleton() /\ t2.Is(t1) => t1.Is(t2)
Also clean up the Type interface and improve test coverage a little.
Change-Id: I074e20047c92e2c8215c2d438f2627f4ffdbc409
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096631
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66684}
This CL is a step towards making StackChecks implicit. In a follow-up CL
said StackChecks will become implicit within JumpLoops.
Cq-Include-Trybots: luci.chromium.try:linux-rel
Bug: v8:10149, v8:9960
Change-Id: I5ae247be3f7a58ccdf86398cace30724715767a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062391
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66668}
Instead of directly using the Heap class concurrent threads will use the
LocalHeap class for all heap operations.
Bug: v8:10315
Change-Id: Ie007abb5b914af7f2507c9e790f34baacbcdf588
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096620
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66663}
This CL merges nested loops that share the same header offset with its
parent loop, by not emitting JumpLoop bytecode for these inner loops.
Instead, we generate a Jump to its parent's JumpToHeader (which in
turn can be a JumpLoop or another Jump to its parent's JumpToHeader).
Originally, every loop had a unique first Bytecode to jump to. Since
IterationBody StackChecks are going to become implicit this will no
longer be the case.
As a note, this CL just sets the foundation that the follow-up CLs
will build on top of. Since we have explicit StackChecks, and they
are at the beginning of loops we do not have nested loops as of now.
Bug: v8:10149, v8:9960
Change-Id: I6daee4d2c6d6216f022228c87c4aa74e163997b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062390
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66626}
String::NewFromLiteral is a templated function that takes a char[N]
argument that can be used as an alternative to String::NewFromUtf8 and
returns a Local<String> rather than a MaybeLocal<String> reducing the
number of ToLocalChecked() or other checks.
Since the string length is known at compile time, it can statically
assert that the length is less than String::kMaxLength, which means that
it can never fail at runtime.
This also converts all found uses of NewFromUtf8 taking a string literal
or a variable initialized from a string literal to use the new API. In
some cases the types of stored string literals are changed from const
char* to const char[] to ensure the size is retained.
This API does introduce a small difference compared to NewFromUtf8. For
a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
would treat this as a 3 character string, whereas the new API will treat
it as a 7 character string.
As a drive-by fix, this also fixes all redundant uses of
v8::NewStringType::kNormal when passed to any of the String::New*
functions.
Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66622}
This fixes a non-determinism issue caused by the cache being full.
Depending on the non-deterministic value of the handles in HeapConstant
nodes, different cache entries would be overwritten in this case.
The old implementation of NodeCache had a fixed limit, overwriting
entries when the cache is full. This behavior didn't really make sense,
but the hand-written hash map implementation couldn't handle arbitrary
numbers of hash collisions, so removing the limit wasn't an option either.
Thus this CL just replaces the custom hash map with a normal
std::unordered_map, that is, a ZoneUnorderedMap.
Bug: chromium:1046815
Change-Id: I95269f2b1068eb9dfe3ee2ab5cca1cb460bc8fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087405
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66592}
Optimizes InstructionSelector::AddInputsToFrameStateDescriptor by
taking advantage of SparseInputMask data structure to more quickly
handle empty inputs and insert all the OptimizedOut entries in one go.
The number of empty inputs is now determined using CountTrailingZeros
rather than iterating over them one at a time.
Gives a 9% improvement to SelectInstructions runtime call stat for
Octane in turboprop.
Bug: v8:10051
Change-Id: Ib13d6f9644b4c89ba0546a19fe0ed623d69fec99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037443
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66591}
This is a reland of 9325397812
Original change's description:
> Use context of then function for PromiseResolveThenableJob
>
> When a microtask is executed, we need to use an appropriate,
> non-detached Context for its execution. Currently with
> PromiseResolveThenableJobs [1], the Context used is always drawn from
> the realm of the Promise constructor being used. This may cause
> non-intuitive behavior, such as in the following case:
>
> const DeadPromise = iframe.contentWindow.Promise;
> const p = DeadPromise.resolve({
> then() {
> return { success: true };
> }
> });
> p.then(result => { console.log(result); });
>
> // Some time later, but synchronously...
> iframe.src = "http://example.com"; // navigate away.
> // DeadPromise's Context is detached state now.
> // p never gets resolved, and its reaction handler never gets called.
>
> To fix this behavior, when PromiseResolveThenableJob is being queued up,
> the `then` method of the thenable should be used to determine the
> context of the resultant microtask. Doing so aligns with Firefox, and
> also with the latest HTML spec [2][3].
>
> This change is analogous to CL 1465902, which uses the realm of the
> reaction handlers to determine the Context PromiseReactionJobs run in.
>
> [1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob
> [2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments)
> [3]: https://github.com/whatwg/html/pull/5212
>
> Bug: v8:10200
> Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66507}
Bug: v8:10200
Change-Id: I5af003a06c60b0c8cd19de47f847a947d40d046c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2082109
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66586}
This is a reland of 25d16574f8
Changes from original: replaced slow test with fast test
Original change's description:
> [runtime] Improve handling of enumeration index on global dictionary
>
> Bug: chromium:1056054
> Change-Id: Ie1f2da98bc54a2ad5189cbe2ee1686fe1ef7019a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079035
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#66504}
Bug: chromium:1056054
Change-Id: I45b9a096b1e37bf1dc5e792f106cdfadd47fabf9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080855
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66535}
Remove OffThreadHandle, HandleOrOffThreadHandle, and HandleFor, and
make the OffThreadIsolate allocate "real" Handles. Rather than using
the main-thread Isolate's handle scopes, these off-thread Handles are
backed by a Zone, which is tied to the lifetime of the nearest
OffThreadHandleScope. Eventually, we'll likely want to merge the
implementation of OffThreadHandleScope and HandleScope, but currently
the latter is too tightly coupled to the main thread to do so.
Bug: chromium:1011762
Change-Id: I2a6361931fe3f90a7bef4cc28ee42155fa8d062f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071865
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66516}
This reverts commit 9325397812.
Reason for revert: Causing blink layout failures. See
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux%20Future/2684
Original change's description:
> Use context of then function for PromiseResolveThenableJob
>
> When a microtask is executed, we need to use an appropriate,
> non-detached Context for its execution. Currently with
> PromiseResolveThenableJobs [1], the Context used is always drawn from
> the realm of the Promise constructor being used. This may cause
> non-intuitive behavior, such as in the following case:
>
> const DeadPromise = iframe.contentWindow.Promise;
> const p = DeadPromise.resolve({
> then() {
> return { success: true };
> }
> });
> p.then(result => { console.log(result); });
>
> // Some time later, but synchronously...
> iframe.src = "http://example.com"; // navigate away.
> // DeadPromise's Context is detached state now.
> // p never gets resolved, and its reaction handler never gets called.
>
> To fix this behavior, when PromiseResolveThenableJob is being queued up,
> the `then` method of the thenable should be used to determine the
> context of the resultant microtask. Doing so aligns with Firefox, and
> also with the latest HTML spec [2][3].
>
> This change is analogous to CL 1465902, which uses the realm of the
> reaction handlers to determine the Context PromiseReactionJobs run in.
>
> [1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob
> [2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments)
> [3]: https://github.com/whatwg/html/pull/5212
>
> Bug: v8:10200
> Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66507}
TBR=verwaest@chromium.org,timothygu@chromium.org,syg@chromium.org
Change-Id: I81737750f8b369567ba586c5a2cfb489836b7e74
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10200
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081091
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66510}
When a microtask is executed, we need to use an appropriate,
non-detached Context for its execution. Currently with
PromiseResolveThenableJobs [1], the Context used is always drawn from
the realm of the Promise constructor being used. This may cause
non-intuitive behavior, such as in the following case:
const DeadPromise = iframe.contentWindow.Promise;
const p = DeadPromise.resolve({
then() {
return { success: true };
}
});
p.then(result => { console.log(result); });
// Some time later, but synchronously...
iframe.src = "http://example.com"; // navigate away.
// DeadPromise's Context is detached state now.
// p never gets resolved, and its reaction handler never gets called.
To fix this behavior, when PromiseResolveThenableJob is being queued up,
the `then` method of the thenable should be used to determine the
context of the resultant microtask. Doing so aligns with Firefox, and
also with the latest HTML spec [2][3].
This change is analogous to CL 1465902, which uses the realm of the
reaction handlers to determine the Context PromiseReactionJobs run in.
[1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob
[2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments)
[3]: https://github.com/whatwg/html/pull/5212
Bug: v8:10200
Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66507}
Previously, our Torque definition of JSArrayBuffer included only the
first two fields. This allowed access to those two fields, but was
somewhat confusing and obviously didn't let Torque code access the
other fields. This change:
- Completes the JSArrayBuffer layout definition;
- Moves the associated bitfield struct definition to Torque;
- Moves a couple of JSArrayBuffer macros to Torque;
- Adds a reducer case so that the code generated using these new macros
is not worse than what was generated previously.
Change-Id: Ib19c3ba789a33801fa9d0d064cd21d62a1e03e30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2053769
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66503}
Port 6cd28b522a
Original Commit Message:
Added implementations for ia32, arm, arm64.
mips/mips64 will be committed in separate CL once the build is green
again in order not to stall this CL with the supported architectures.
compilation by using alternative temp register for x64.
macro assemblers.
R=ecmziegler@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ib08e31dfa11f0254c7888ce17dd27e7d0154c752
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078898
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66490}
Added implementations for ia32, arm, arm64.
mips/mips64 will be committed in separate CL once the build is green
again in order not to stall this CL with the supported architectures.
Drive-by: Fixed issues with kScratchRegister being overwritten in case of RegExp
compilation by using alternative temp register for x64.
Drive-by: Added missing NoRootArrayScope to ia32, arm and arm64 RegExp
macro assemblers.
R=clemensb@chromium.orgR=petermarshall@chromium.orgR=jgruber@chromium.org
Bug: chromium:1045860
Change-Id: I716d852b9bf780ae7b8d61376c6505dd3af96a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071866
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66482}
Most function signatures are created once and never changed. Hence pass
them as const pointer. This makes it clear in function signatures that
these parameters will not be modified.
This also avoids a few ugly const_casts where we were passing pointers
to constexpr FunctionSigs via non-const pointers.
R=jkummerow@chromium.org
Bug: v8:10155
Change-Id: Ieb658ab5582bff276f76babdaf7ddb8f72bd4790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072739
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66478}
This reverts commit 4dc1fb4e04.
Reason for revert: the regression from the original change was likely due to unlucky factors like code alignment.
Original change's description:
> Revert "[torque] Support bitfield structs stored within Smis"
>
> This reverts commit e5e4ea962e.
>
> Reason for revert: mysterious performance regression chromium:1052756
>
> Original change's description:
> > [torque] Support bitfield structs stored within Smis
> >
> > This change moves the definition of the bits stored in DebugInfo::flags
> > to Torque, and updates the only Torque usage of that field to use more
> > natural syntax. This is intended as an example of common patterns found
> > in various other classes. Several supporting changes are required:
> >
> > 1. Add a new type representing a bitfield struct stored within a Smi. It
> > is currently called SmiTagged, but I'm open to suggestions.
> > 2. Add an enum-style output for Torque bitfield structs whose bitfields
> > occupy only one bit each.
> > 3. Add a new case to MachineOperatorReducer that makes the generated
> > code for IncBlockCounter match with what was generated before this
> > change.
> > 4. Add support for reporting these bitfields in the postmortem debugging
> > API. The format matches existing bitfields but with an offset value
> > that includes the SMI shift size.
> >
> > Bug: v8:7793
> > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66182}
>
> Bug: chromium:1052756, v8:7793
> Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66349}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1052756, v8:7793
Change-Id: I6087928aa14c8551ebd294513bd8d6ffa402a0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070635
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66465}
Added a type field to elements to distinguish anyref, funcref and
nullref elements and do a proper type checking at compile time as
the spec requires.
R=ahaas@chromium.org
Change-Id: I31be7aa1170439859ca7ec5e20aabb2720c290b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069330
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66448}
This is a reland of 03d5a7ba9b
Nothing changed here compared to the original test. The tests on the
blink side were invalid, I fixed them in https://crrev.com/c/2066907.
Original change's description:
> [wasm] The name of a custom section can cause a validation error
>
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
>
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
>
> R=clemensb@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}
Bug: v8:10126
Change-Id: I48aaed8eb9899da1703030fb6809fe46a6e66191
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069325
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66431}
This CL generalizes the lowering of special CallDescriptors in the
int64-lowering. The reason is a planned extension of the special
handling due to a refactoring of the AtomicWait implementation.
R=jkummerow@chromium.org
Bug: v8:10108
Change-Id: I48d0087e2ad00ba9b44c5198ffdbbae8eb575a85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069333
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66420}
Renaming the JS-visible identifiers and strings is left for a future CL.
FinalizationGroup was renamed at Feb 2020 TC39, to better signal that if
a FinalizationRegistry dies, the finalization actions registered with it
may no longer be performed.
Bug: v8:8179
Change-Id: I0d676a71a4a67d2b7175994a67458a6158065844
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2055381
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66416}
This reverts commit 03d5a7ba9b.
Reason for revert: Needs rebaseline:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3243
Original change's description:
> [wasm] The name of a custom section can cause a validation error
>
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
>
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
>
> R=clemensb@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I5a7ea265ce47b9e685a5056bb83db6dc58f774a9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10126
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2065168
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66356}
This reverts commit e5e4ea962e.
Reason for revert: mysterious performance regression chromium:1052756
Original change's description:
> [torque] Support bitfield structs stored within Smis
>
> This change moves the definition of the bits stored in DebugInfo::flags
> to Torque, and updates the only Torque usage of that field to use more
> natural syntax. This is intended as an example of common patterns found
> in various other classes. Several supporting changes are required:
>
> 1. Add a new type representing a bitfield struct stored within a Smi. It
> is currently called SmiTagged, but I'm open to suggestions.
> 2. Add an enum-style output for Torque bitfield structs whose bitfields
> occupy only one bit each.
> 3. Add a new case to MachineOperatorReducer that makes the generated
> code for IncBlockCounter match with what was generated before this
> change.
> 4. Add support for reporting these bitfields in the postmortem debugging
> API. The format matches existing bitfields but with an offset value
> that includes the SMI shift size.
>
> Bug: v8:7793
> Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66182}
Bug: chromium:1052756, v8:7793
Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66349}
The WebAssembly spec defines that the name of a custom section can cause
a validation error. The streaming decoder, however, used a separate
Decoder object to decode the name, and thereby avoided a validation
error. With this CL the streaming decoder uses the main decoder to
decode the name of the custom section.
In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
This test defined an invalid WebAssembly module and expected it to
compile. As it is a regression test, it makes no sense to fix the test.
The module is invalid because it defines the length of the custom section
to be '0', so there are no bytes in the custom section for its name.
R=clemensb@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10126
Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66348}
Implement the latest spec changes:
- Allow declarative segments to behave like passive & dropped segments.
- Enforce that only declared functions may be returned or used in globals
as funcref.
- Ensure that table fill does not modify any entries if OOB.
Spec tests for select and br_table are still failing due to proposal issue
Bug: v8:10156
R=ahaas@chromium.org
Change-Id: I5b95be36a67bc7482a84b848908cc4cbdf94af03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027458
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66297}
Since the size of the parameters and locals inputs is already stored on
the FrameStateFunctionInfo, this skips the calls to size() and just
reuses the previous values. The stack parameter can only have a size of
0 or 1 depending on whether it's a InterpretedFunction frame or not.
It also extends the verifier to check that the values to match those
returned by StateValueAccess::size and changes a unit test that added
a TypedStateValues of size 2 to the stack input.
Bug: v8:10051
Change-Id: I3693c04b4677812b9f19491c198d0551df20f817
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047045
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66268}
Fuchsia's SDK will soon provide GN rules include one for declaring
fuchsia package targets. Since the SDK-provided rule works differently
from the Chromium one but is called fuchsia_package(), we need to rename
the Chromium rule to avoid them clashing.
Bug: chromium:1050703
Change-Id: Ia2fcba8e32f311e6859590d9c95730ffe6875192
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050388
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66244}
This change moves the definition of the bits stored in DebugInfo::flags
to Torque, and updates the only Torque usage of that field to use more
natural syntax. This is intended as an example of common patterns found
in various other classes. Several supporting changes are required:
1. Add a new type representing a bitfield struct stored within a Smi. It
is currently called SmiTagged, but I'm open to suggestions.
2. Add an enum-style output for Torque bitfield structs whose bitfields
occupy only one bit each.
3. Add a new case to MachineOperatorReducer that makes the generated
code for IncBlockCounter match with what was generated before this
change.
4. Add support for reporting these bitfields in the postmortem debugging
API. The format matches existing bitfields but with an offset value
that includes the SMI shift size.
Bug: v8:7793
Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66182}
GlobalSize will be used as a hint to schedule scavenger work in
https://chromium-review.googlesource.com/c/v8/v8/+/2036661
This is implemented as an atomic variable that's updated when adding/removing
segments.
Bug: chromium:1012816
Change-Id: I8f6c3f10612f8febda9bfe640d91e235aa3c2f12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043273
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66175}
Allow caching the result of allocating AstConsStrings, to allow
sharing of inferred names between functions.
This is a partial revert of https://crrev.com/c/2020953, with
the observation that *some* AstConsStrings are always flattened,
while others are only ever used as ConsStrings, so we want to
allow the allocation to be lazy while still caching the result.
As a drive-by, cleanup the old AstConsString linked list fields.
Bug: chromium:1011762
Bug: chromium:1048082
Change-Id: Icc14342eb3f6f97359596b42b2c296cbc49fd791
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042093
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66168}
A pointer-compressed heap has the same heap limit heuristics as a 32-bit
heap. Specifically, the heap limit is restricted to 1GB due to scarce
virtual addresses space on 32-bit platforms. That limitation does not
apply for pointer-compressed heaps which can use 4GB.
This CL changes the heap limit computation to use system the pointer
size instead of the tagged pointer size. Note that the young generation
limit continues to use the tagged pointer size.
Bug: chromium:1045034
Change-Id: I9d5bb818c32a82322476e9c97feee331400ebe0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042102
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66159}
The Factory/OffThreadFactory allows us to cleanly separate object
construction behaviour between main-thread and off-thread in a
syntactically consistent way (so that methods templated on the factory
type can be made to work on both).
However, there are cases where we also have to access the Isolate, for
handle creation or exception throwing. So far we have been pushing more
and more "customization points" into the factories to allow these
factory-templated methods to dispatch on this isolate behaviour via
these factory methods. Unfortunately, this is an increasing layering
violation between Factory and Isolate, particularly around exception
handling.
Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
way as OffThreadFactory is analogous to Factory. All methods which were
templated on Factory are now templated on Isolate, and methods which
used to take an Isolate, and which were recently changed to take a
templated Factory, are changed/reverted to take a templated Isolate.
OffThreadFactory gets an isolate() method to match Factory's.
Notably, FactoryHandle is changed to "HandleFor", where the template
argument can be either of the Isolate type or the Factory type (allowing
us to dispatch on both depending on what is available).
Bug: chromium:1011762
Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66101}
... by using random seed provided via --gtest_random_seed= flag.
Bug: chromium:1043117
Change-Id: I6114e9c71f3196a386a8457a6ec6f9e1fc80f6ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027991
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66043}
