This is a reland of commit 39d387bb72
Original change's description:
> [heap] Invoke allocation observers before limiting the LAB
>
> Currently whenever we reach a step we get a small LAB the same size as
> the allocated object. This is becuase the remaining step size is smaller
> then the current allocation.
> Invoking observers before limiting the LAB, and thus updating step
> sizes, should eliminate the small LAB we get whenever we reach a step.
>
> Drive-by: remove redundant method arguments.
>
> Bug: v8:12612
> Change-Id: Ied92a947308368d3b289e246fdb4f40ac5e5981f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013683
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84157}
Bug: v8:12612, v8:13465
Change-Id: I40fb930a755cb5decccd932c4d25ed7d5d224da4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020177
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84328}
Scope: In practice, we don't need Scopes, so it'll be simpler to
access the table directly.
Predecessors: Phi inputs are often not mergeable (because they often
aren't defined in all predecessors). As a result, if we want to know
the value of a Phi input through the SnapshotTable, we need to lookup
its value in a predecessor, which is the feature that this CL
introduces.
Bug: v8:12783
Change-Id: I12a9e6abddd88ff1f3de172a387c9a502356f351
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030581
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84327}
The deoptimized code list is inserted into when walking a native context
to find Code objects marked for deoptimization, and is then only used
for two purposes:
1. Looking up lazy deoptimizing code objects by PC, and
2. Counting deoptimizing code that's not marked for deoptimization.
Point 1 is slow, as it is a linked list traversal, and is made slightly
slower by the CodeT refactoring which adds another layer of indirection
to the list. The existing Isolate::FindCodeObject approach is faster,
and is already used in the deoptimizer for Code objects not found in the
list, in particular all eager deopts.
The careful reader will notice that point 2 results in a count that's
always zero, since the count excludes exactly those code objects which
are added to the list (ones marked for deopt). Indeed, all uses (which
were all in tests) were verying only that it is equal to zero.
So, we can remove this deoptimized code list entirely.
Change-Id: I352e77b1df83260a30464dbac7f268484211b2e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030582
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84325}
This reverts commit bdf634f851.
The tsan race were fixed by
- removing unmodified wrapper reclamation with --cppgc-young-generation
- moving Oilpan's final pause after young trace handle marking
Original change's description:
> unified-young-gen: Trace cross-heap references
>
> The CL enables the marking visitor in CppGC to trace
> v8::TracedReferences (by just reusing the unified heap visitor from the
> full GC). In addition, it specifies VisitJSApiObject for
> NewSpaceVisitors to be able to trace wrappers from Minor MC in case
> --cppgc-young-generation is enabled.
>
> Bug: v8:13475
> Change-Id: I04ba1f2a22e05caebf53dc8d64f2488c42ab8579
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026896
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84313}
Change-Id: I64d5bfabfa1b83337b1f11666495ccbd7e7e46c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030318
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84324}
With dynamic tiering, each WebAssembly function has a tiering budget,
and the function gets optimized once the tiering budget is reached. So
far the tiering budget exists per process, which means that whenever
a web application got loaded, it started with a full tiering budget.
As a result, functions that only get called few times during startup
and never reach the tiering budget would never get optimized.
With this CL the tiering budget gets written to the cache. Given that
caching events are happening, this means that also startup functions get
optimized eventually as long as the web application gets visited often
enough.
R=clemensb@chromium.org
Bug: chromium:1384530
Change-Id: I5066bc8f3daf457159b6eb785d2e17eda43c8c4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026769
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84320}
Only validate that a supertype is in-bounds if it exists.
Also, fix format parameter for the respective error message.
Bug: v8:7748
Change-Id: I8891562a57e680ed7f6e65f83147cd8db3771607
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4031207
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84319}
We introduce {SignallingNanPropagation} in MachineOperatorReducer to
make the call-sites easier to read.
Change-Id: I61d46fda5f6156a87f8504c38cae6b014e4021ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026771
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84315}
This reverts commit 43f03448d3.
Reason for revert: Data race caught by TSAN:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/22640/overview
Original change's description:
> unified-young-gen: Trace cross-heap references
>
> The CL enables the marking visitor in CppGC to trace
> v8::TracedReferences (by just reusing the unified heap visitor from the
> full GC). In addition, it specifies VisitJSApiObject for
> NewSpaceVisitors to be able to trace wrappers from Minor MC in case
> --cppgc-young-generation is enabled.
>
> Bug: v8:13475
> Change-Id: I04ba1f2a22e05caebf53dc8d64f2488c42ab8579
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026896
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84313}
Bug: v8:13475
Change-Id: I8b8351774a121ca2296efa3c8d3a588fa7380d86
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4032053
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84314}
The CL enables the marking visitor in CppGC to trace
v8::TracedReferences (by just reusing the unified heap visitor from the
full GC). In addition, it specifies VisitJSApiObject for
NewSpaceVisitors to be able to trace wrappers from Minor MC in case
--cppgc-young-generation is enabled.
Bug: v8:13475
Change-Id: I04ba1f2a22e05caebf53dc8d64f2488c42ab8579
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026896
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84313}
Cancel the unnecessary fix
https://chromium-review.googlesource.com/c/v8/v8/+/4028559
and fix the problem at its root, TypedArraySpeciesCreateByLength.
This fix also fixes other variants of this bug (see tests).
Drive by: harden by setting length = 0 (not only byte_length) for length
tracking TAs.
Bug: v8:11111,chromium:1384474
Change-Id: I3ba660f7f600c0b946c75e7f13276703394c7df2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030259
Auto-Submit: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84312}
This will make our generic fuzzers (wasm-fuzzer, wasm-code-fuzzer,
wasm-async-fuzzer, ...) fuzz wasm-gc opcodes.
We were already fuzzing specific instructions in the wasm-compile
fuzzer, but were missing fuzzer coverage for corner cases and
instructions not supported by that fuzzer.
R=jkummerow@chromium.orgCC=manoskouk@chromium.org
Bug: v8:13496
Change-Id: Iccca96e32a64d20c11bc425fb5b1e9a1e3aa7486
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030986
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84310}
This is needed to prepare for the landing of ICU72.
Allow U+202F in the Date String, which the toLocaleString("en-US")
will generate w/ ICU72.
Bug: v8:13494
Change-Id: I41b83c4094ce3d0737a72dcd6310b52c68fdcdca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027341
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84308}
The CL adds standalone Oilpan tracing to minor MC. No cross-heap
references are currently processed. In addition, the CL removes
wrapper iteration from Oilpan Minor MC.
Bug: v8:13475
Change-Id: I3a0670e1f3431a3aa723217d5361e4e74f9b0c0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027209
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/main@{#84306}
The stack object is primarily used for conservative stack scanning, both
by the V8 and C++ garbage collectors. This CL introduces the notion of a
"stack context", which comprises of the current stack marker (the lowest
address on the stack that may contain interesting pointers) and the
values of the saved registers. It simplifies the way in which iteration
through the stack is invoked: the context must have previously been
saved and iteration always uses the stack marker.
Bug: v8:13257
Bug: v8:13493
Change-Id: Ia99ef702eb6ac67a3bcd006f0edf5e57d9975ab2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4017512
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84303}
Additionally:
- Remove the early data-count section from module-decoder and
wasm-module-builder.js.
- Move a test from gc-nominal.js to array-init-from-segment.js.
- Comment-out relevant tests.
Bug: v8:7748
Change-Id: I5e038e0b6227c28ce79ffe39529ada59c34187eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4028144
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84301}
Most wasm fuzzers live in the v8::internal::wasm::fuzzer namespace.
Thus also move the wasm-fuzzer there. Additionally
- use the C++20 syntax for declaring the namespace,
- skip unneeded full or partial classifications on types, and
- remove a redundant HandleScope.
R=ahaas@chromium.org
Bug: v8:13496
Change-Id: I31d948af449efd9708aa6b27f35e8f3c9280a3f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030579
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84300}
These tests were needed when missing features were implemented in
Liftoff, and the in-progress implementation was disabled by default.
Since the Liftoff code is enabled by default now, the test copy can be
deleted.
R=jkummerow@chromium.org
Bug: v8:12926
Change-Id: Iecdf02645a63e93a51f6ce297d168e149d68be26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027928
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84279}
A surrogate pair split by an "always succeeding" backreference
(backreference capturing undefined, because it hasn't captured anything
yet) was incorrectly combined into a surrogate pair, resulting in
incorrect matches.
Bug: v8:13410
Change-Id: I2faf9ca5f9fcfd55cd6933a1ea038c88f8d3f524
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013159
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84276}
Since crrev.com/30c19f3292fed9c499dd5a8f852bc76a481d6368, we always
allocate the wasm_internal_functions array on WasmInstanceObject
creation. This patch initializes that array with zero bits, so we
can use a Smi check (instead of a comparison to Undefined) to check
whether a given slot has been initialized already. This makes the
code generated for `ref.func` slightly smaller and more efficient.
Bug: v8:7748
Change-Id: I9d2b8fba4dc61d27e96b6e917c77133519af43ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4028561
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84272}
Unlike the default scheme the ExternalCodeCompressionScheme allows
the cage to cross 4GB boundary at a price of making decompression
slightly more complex. The former outweighs the latter because it
gives us more flexibility in allocating the code range closer to
the .text section in the process address space. At the same time
decompression of the external code field happens relatively rarely
during GC.
Bug: v8:11880
Change-Id: Ia62bedd318f88c2147534ff000ab9fad354777f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899307
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84269}
Invariant in the normal mode:
- If the data is invalid, we'll fail gracefully (no crash, no DCHECK
failures)
Invariant in the hard fail mode:
- If the data is invalid (in a way we can detect), a CHECK fails at the
earliest location where we detect the inconsistency
Bug: chromium:1381404
Change-Id: Icae077a5c76329018fdb759122297134ae70b897
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013142
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84265}
This adds a separate test module and output expectation for Wasm GC.
This covers the new types and instructions from
https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md
Unlike the previous disassembler tests, one cannot easily create the
module bytes with WABT's `wat2wasm` from the expected text output (at
least right now), so I used Binaryen's `wasm-as` instead to generate
the module from a separate input file (not included here, because it
uses folded expressions, which the debugger doesn't.)
Change-Id: Id0205b2788fd7be5ea7696242cbe8a74a4bca892
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013265
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84264}
Tests don't work when incremental marking is started before the test
is run.
Bug: v8:13267
Change-Id: I00e30ede96bfe3632ef701436395479f5ef083ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026843
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84259}
For Int32Div (and Uint32- and -Mod), Turbofan has long had the ability
to replace division-by-constant with multiplication-by-inverse. This
patch brings the same goodness to Int64Div and friends.
This benefits Wasm code that uses i64.{div,rem}_{s,u} instructions.
Fun fact: Turboshaft supports this already.
Change-Id: I4be5536dfb81fb2f1c5d812f2a289da7dc2eef30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026762
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84257}
Changes since original:
- Updated to use the returned value from CompleteMergeInForeground as
the compilation result, which is important for correctness.
- Added a test to verify the above.
- Moved the merge code into code-serializer.cc so that it can run before
FinalizeDeserialization, which makes it more consistent with
background deserialization.
Original change's description:
> Merge with cached Script after synchronous deserialization
>
> Currently, if a script is deserialized on a background thread and a
> matching Script object is found in the Isolate compilation cache, the
> new content is merged into the existing Script. This CL implements the
> same merging for the much simpler case of deserializing on the main
> thread. I expect speed changes to be minimal, because merging is only
> needed in a small minority of compilations. When needed, it usually
> takes about 10% as long as the corresponding deserialization.
>
> Bug: v8:12808
> Change-Id: Ie7a92bcb3111edf4cdab0eddeb7567979b35f437
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4010100
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#84123}
Bug: v8:12808
Change-Id: I0628a381644e79888cb3ebdd97bda270814d0e9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4014644
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84255}
I recently updated the GC's bytecode flushing logic to accept the
possibility that two SharedFunctionInfos refer to the same
BytecodeArray (see https://crrev.com/c/v8/v8/+/3916272 ). However, that
change was insufficient for baseline code flushing. This change updates
the flushing logic to also check for already decompiled bytecode held by
the baseline code.
Bug: v8:13473
Change-Id: I58694727c417d608de3f8bf26dfd765fda1ae4f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4018272
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#84254}
This is a reland of commit 05a80427dc.
We skip the test for now, until we figure out how to make it fast
enough.
Original change's description:
> [wasm] Do not add too much code at once
>
> Especially on arm64 we have a rather low code space limit (128MB), so it
> can happen that a background thread generates more code in one batch
> than can be held in a single code space. This case is not implemented
> yet.
>
> This CL implements this by never batch-adding more than half of a code
> space.
>
> In order to test the implementation, we add a new flag called
> --wasm-max-code-space-size-mb which can be used to artificially lower
> the code space size limits in tests.
>
> R=jkummerow@chromium.org
>
> Bug: v8:13436
> Change-Id: I18a3457fda724129fb1bb8c44a9815df265b6b2c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023072
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84245}
Bug: v8:13436
Change-Id: I983ef2f2cc2316172edab1f62dbde0dd4cb56fdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4025548
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84253}
This reverts commit 05a80427dc.
Reason for revert: Getting timeouts on some slow bots.
Original change's description:
> [wasm] Do not add too much code at once
>
> Especially on arm64 we have a rather low code space limit (128MB), so it
> can happen that a background thread generates more code in one batch
> than can be held in a single code space. This case is not implemented
> yet.
>
> This CL implements this by never batch-adding more than half of a code
> space.
>
> In order to test the implementation, we add a new flag called
> --wasm-max-code-space-size-mb which can be used to artificially lower
> the code space size limits in tests.
>
> R=jkummerow@chromium.org
>
> Bug: v8:13436
> Change-Id: I18a3457fda724129fb1bb8c44a9815df265b6b2c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023072
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84245}
Bug: v8:13436
Change-Id: I0b2492eb7fee40b7d62b3b3a8fb19a4bc7fda26b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4025546
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84248}
The test was introduced in https://crrev.com/c/4023072, but times out in
gc-stress.
R=leszeks@chromium.org
Bug: v8:13436
Change-Id: I2991083a2a229cbc5e307aebf1a44acf169ac4fb
No-Try: true
No-Tree-Checks: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023860
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84247}
When runnig cppgc_unittests in a cppgc standalone build, the test
ConcurrentSweeperTest.IncrementalSweeping fails. This is becuase
TestPlatform::RunAllForegroundTasks was actually not running all
tasks becasue v8::platform::PumpMessageLoop only runs a single task.
Change-Id: Ie68eee369abd12edcf04e697a1d8ca574059d160
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4026163
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84246}
Especially on arm64 we have a rather low code space limit (128MB), so it
can happen that a background thread generates more code in one batch
than can be held in a single code space. This case is not implemented
yet.
This CL implements this by never batch-adding more than half of a code
space.
In order to test the implementation, we add a new flag called
--wasm-max-code-space-size-mb which can be used to artificially lower
the code space size limits in tests.
R=jkummerow@chromium.org
Bug: v8:13436
Change-Id: I18a3457fda724129fb1bb8c44a9815df265b6b2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023072
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84245}
The condition clearing the "known HeapObject" bit was wrong -- it was
checking whether the _map_ was a HeapObject (spoiler alert, it is), not
whether it was the map _of_ a HeapObject, i.e. not a HeapNumberMap which
returns true for Smis.
Bug: v8:7700
Change-Id: I5af4c1a662bb16bacdfcf178819d912332ecefd6
Fixed: chromium:1383712
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023077
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84243}
Rename the '--wasm-max-code-space' flag to
'--wasm-max-committed-code-mb'. We will introduce a new flag to set the
maximum size of a wasm code space, so the old name would be misleadingly
close to the new flag.
R=jkummerow@chromium.org
Bug: v8:13436
Change-Id: I7a86300e4f25858add1a62f9989189035ea855ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022709
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84242}
Modify the existing x64 trap handler test to support arm64 too.
Bug: v8:13383
Change-Id: I23eb8276ad94289e9a27b756d51040321778d912
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990564
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84241}
This is a reland of commit 936b61a209
Change compared to original: Fix parameter types for CallRuntimeStub
in Liftoff.
Original change's description:
> [wasm-gc] Canonicalize JS Numbers as i31ref at the boundary
>
> JS numbers flowing into Wasm as i31ref should be canonicalized at the
> boundary. In-range numbers get canonicalized to Smis, and out-of-range
> numbers to HeapNumbers. This way, casting to i31ref, or checking for
> i31ref when casting to other types, is reduced to a Smi check.
>
> Bug: v8:7748
> Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84219}
Bug: v8:7748
Change-Id: I67737150252b844a296338db0c60f76b470aa43b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4022711
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84240}
This prepares work for speeding up gcmole infrastructure by adding
more checks and testing.
- Add a presubmit check that verifies gcmole directives in gn files.
- Simplify gcmole directives in gn files. Drop all but the
architecture property as the others were unused. Simplify regular
expressions.
- Fix some gcmole directives (fly by - only on untested
architectures).
- Add a python test for the changed function in gcmole.py. There's
no other testing yet and this starts somewhere. The test simulates
real BUILD.gn files via checked-in test data.
Bug: v8:12660
Change-Id: I9ca3152b2c3b806de5d4509c152283b36294950d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020268
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84239}
Reland of https://crrev.com/c/3998633.
Each thread has its own MarkingBarrier instance for incremental
marking. A thread local variable is used to get the current thread's
instance on background threads.
However on main threads this thread local variable was always
set to nullptr. The main thread would get to its own instance through
the heap_ field in the host object's page header. This was solved this
way because setting current_marking_barrier on the main thread
seemed quite complex. Multiple isolates may be run on the same thread
and isolates may even be migrated between threads.
However, with --shared-space loading the heap_ field for a shared
object would return the main isolate's heap and we end up with
the wrong MarkingBarrier instance on client isolates. So this
CL makes main and background threads more uniform by setting the
thread local field also on the main thread. The field is set by
the already existing v8::Isolate::Scope API. Some embedders might have
to add these scopes if they don't use them properly already.
Bug: v8:13267
Change-Id: Idc257ecf6b6af09a379bdd7cd7c1d4a5e46689c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4016715
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84237}
This constant wasn't really used anymore anymore, so we can drop
this constant and initialize the --concurrent-marking flag from
V8_ATOMIC_OBJECT_FIELD_WRITES instead.
Bug: v8:13267
Change-Id: I2533d80cd08fd799441a7dba764fd392bb9151d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020428
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84232}
For SignedSmall binary ops, we know that the output has to fit in a Smi.
So, emit a Smi check eagerly after these operations, so that future Smi
untagging knows that it doesn't need to do a check.
Bug: v8:7700
Change-Id: I117c55caa5e2ebe870fd964908564d74df726546
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020434
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84223}
This reverts commit 936b61a209.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20no%20pointer%20compression/2000/overview
Original change's description:
> [wasm-gc] Canonicalize JS Numbers as i31ref at the boundary
>
> JS numbers flowing into Wasm as i31ref should be canonicalized at the
> boundary. In-range numbers get canonicalized to Smis, and out-of-range
> numbers to HeapNumbers. This way, casting to i31ref, or checking for
> i31ref when casting to other types, is reduced to a Smi check.
>
> Bug: v8:7748
> Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84219}
Bug: v8:7748
Change-Id: Ia74e49147d230f9217ebeb2bf435d10d8f93126e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020457
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84221}
JS numbers flowing into Wasm as i31ref should be canonicalized at the
boundary. In-range numbers get canonicalized to Smis, and out-of-range
numbers to HeapNumbers. This way, casting to i31ref, or checking for
i31ref when casting to other types, is reduced to a Smi check.
Bug: v8:7748
Change-Id: Icd2bbca7870c094f32ddc9cba1d2be16207e80d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008345
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84219}
This CL fixes the bug where x ^ x is reduced to Int32Constant(0) for
both word32 and word64.
Bug: chromium:1383362, v8:9407
Change-Id: I8a2ed879f0626071f560cc5ba8c21ef2d4107e62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020424
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84218}
Previously, once after an error was reported, following errors were ignored
even if they had occured in prior lines. Strict octal error and conflicting
variable declarations error could be missed under this implementation.
This patch solves this problem by making an error replaceable.
Bug: v8:13187
Change-Id: I8295baf0db757a5c1b504920cb274cdee78f5055
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4019398
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84212}
