This reverts commit febfbb21b9.
Reason for revert: Introduced new bugs:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20-%20debug/34472/overview
Original change's description:
> [sparkplug] Adjust compare and jump function in sparkplug
>
> Mips and risc-v do not have the flag register and can not decide
> whether to jump through flags in JumpIf();
>
> Therefor, we merge the comparison with the jump;
>
> Bug: v8:11803
>
> Change-Id: If53752da93b97e8ff65affdfe99e5de8e1a1493f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2921034
> Auto-Submit: Liu yu <liuyu@loongson.cn>
> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75001}
Bug: v8:11803
Change-Id: Ic982564ccdef9a07bf3a5fb4745a11cfa178cc0e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2946818
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#75005}
This commit adds a TryGetCurrent() method to the v8::Isolate class.
The motivation for adding this method this is that in Node.js we've run
into situations where we need to check if there is a current
Isolate and we are using GetCurrent() for this. The issue is that for a
debug build of Node.js, the debug check in GetCurrent() will cause a
failure.
The suggestion in this changeset is to allow getting the current
Isolate, or null if one does not exist, without any checks.
Change-Id: I01676e4bcdbe86da0496f5df1982d14eb1c9ebf8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910630
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75004}
Jobs were still being posted on the underlying default platform, which
caused concurrent execution. By directly returning a
{NewDefaultJobHandle} with a pointer to the {PredictablePlatform}, we
force execution of all posted tasks via that platform.
R=ahaas@chromium.org, cbruni@chromium.org
Bug: v8:11848
Change-Id: Ie10519583341b427776ca428f85641e96f821367
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944808
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75002}
Mips and risc-v do not have the flag register and can not decide
whether to jump through flags in JumpIf();
Therefor, we merge the comparison with the jump;
Bug: v8:11803
Change-Id: If53752da93b97e8ff65affdfe99e5de8e1a1493f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2921034
Auto-Submit: Liu yu <liuyu@loongson.cn>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75001}
The flag had no effect and was removed from fuzzilli instructions here:
f31bfb7b5a
No-Try: true
Change-Id: If28e79fdf469a4cb665a83793c9fef8c6c2a8232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944431
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75000}
Directly use the correct registers for calling the RecordWrite stubs
in sparkplug. To keep changes to existing builtins minimal there are
certain register requirements which are now made explicit in
WriteBarrierDescriptor::Verify.
Bug: v8:11420
Change-Id: I3a0c500fbe26f82ee2243a61dbf574fd31656982
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910313
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74998}
- Add new Builtin enum
- Move Builtins::Name:kXXX to Builtin::kXXX
- Update existing code
Follow CLs will unify the mix of using int builtin-ids and
Builtins::Name to only use the new Builtin enum and changing it to
an enum class.
Change-Id: Ib39aa45a25696acdf147f46392901b1e051deaa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905592
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74995}
This will allow Fuchsia tests to be run on v8 CI
Bug: v8:11843, chromium:934932
Change-Id: I516329d8f29d9c94d46aa010fa729fa3ca0993ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2935024
Commit-Queue: Chong Gu <chonggu@google.com>
Auto-Submit: Chong Gu <chonggu@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74993}
The flag --trace-ignition-dispatches has been broken for a long time,
since it was not designed to work with bytecode handlers that are
generated ahead of time by mksnapshot. This splits the existing
--trace-ignition-dispatches logic into two separate parts:
1. A gn argument which instructs mksnapshot to include dispatch counting
in the bytecode handlers, and ensures that the Interpreter allocates
the array of counters, and
2. A runtime flag which enables the ignition-statistics extension which
implements the JS-accessible function getIgnitionDispatchCounters().
Change-Id: I89323425697f5641451f67b9ddcc0303b8ca209f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2937564
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74992}
xmm0 and xmm1 are used to save/restore values in asm builtins, but they
were not saved before calling RecordWrite, which calls C++ code.
Instead of passing SaveFPRegsMode::kSave to RecordWriteField, which
would save/restore all FP-regs, this CL explicitly saves/restores the
FP-regs we rely on beyond the C-Call.
Bug: chromium:1216295
Change-Id: Ifcc7ce4e8819303ffb79576a88304df2e3a6cc4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944427
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74991}
Left-trimming only works when there is a single reference to the
backing store from the JS object. Main thread handles are an exception
to this rule because it is not feasible to ensure that no such
leftover handles may store such stale pointers.
FixStaleLeftTrimmedHandlesVisitor clears such references
in main thread handles, such that the GC never tries to visit them. This
CL renames this class to ClearStaleLeftTrimmedHandlesVisitor to
emphasize that such slots are cleared rather than "fixed up" to point
to the new object start.
Previously ClearStaleLeftTrimmedHandlesVisitor was used for local
and persistent handles as well. Starting with this CL, stale references
to left-trimmed objects are only allowed in main thread handles.
https://crrev.com/c/2928502 enabled us to be more restrictive here.
Change-Id: If4db0630f1df2d6c3fe5f242bf866c57a8ae2969
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944807
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74989}
- Introduce proper TickLogEntry and use a separate Timeline object
- Update the main rendering to use SVG for speed
- Separate custom-elements: timeline-track-map and timeline-track-tick
- Revamp flame-chart drawing
- Enable map-transitions overlay
- Use mouse position to infer current log-entry instead of individual
event handlers
- Fix first timelineLegend column header
- Fixing scrollbar-color for FireFox
Change-Id: I7c53c13366b3e4614b1c5592dfaa69d0654a3b5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944430
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74987}
Use new Script.prototype.update method to set the url and the script
source.
Bug: v8:11850
Change-Id: I555d4d0158cdacb7cb42efa385371454542fc2f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944438
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74985}
We have recursive calls such ThinStrings where we go String::Get into
ThinString::Get into String::Get again for the internalized string. If
we need to, we would acquire the StringAccessGuard in the first
String::Get and it wouldn't be needed to be re-acquired for the second
String::Get. Trying to re-acquire it would in fact be an error since we
are already holding the lock.
The code, however, didn't know if we acquired it or not. It was working
correctly due to the way the methods were defined and called. By passing
down the access guard through the Get() calls we make this interaction
explicit.
Also add some thin string tests to test the interaction.
Bug: v8:7790
Change-Id: I1181edec1e802cb754c4d1d1ac268577257b92f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2936598
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74984}
A spec test (wasm-js/global/value-get-set) requires
WebAssembly.Global.value.set to throw an exception if it is called with
0 arguments. The implementation in V8, however, just checked if the
first parameter is `undefined`. This implementation indeed threw an
exception if 0 arguments were provided, but it also threw an exception
when `undefined` is provided as a parameter. This, however, violates
the spec, because globals can be reset to `undefined`.
With this CL we replace the checking for `undefined` by checking the
length of the arguments that get provided.
R=ecmziegler@chromium.org
Bug: chromium:1211342
Change-Id: Ic87a0b369dea3e49eddb8f71f2c29dc6a8f5f558
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940901
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74982}
instead of recursive. JS code can construct very long chains of
nested bound functions or proxies, where the previous recursive
implementation could run out of stack space.
Fixed: chromium:1214616
Change-Id: I764718f03030d22c0873b3ed05277d4317789093
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933668
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74981}
When growing a memory without a maximum, we should still check against
the spec'ed limit, to avoid an overflow when computing the new number of
pages.
R=ahaas@chromium.org
Bug: chromium:1215808
Change-Id: I476b954268277e7dce1106a9b8c3c713b0d1a560
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944433
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74980}
While no scavenger thread reads the content of an object copied by
another thread, we still need memory ordering in order to read the page
flags for a forwarded object.
Change-Id: I831e9dccb03d32daf3c4847613614d26533ba825
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944436
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74979}
This reverts commit 6596e8c6da.
Reason for revert: Main bug was fixed.
Original change's description:
> [infra] Switch back to Xenial on some bots
>
> This tests the hypothesis that the current timeout problems are on
> Bionic bots only.
>
> Bug: v8:11818
> Change-Id: I68f84cda52ca392fbda5a400eb2bf136b7ee85a3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916816
> Auto-Submit: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74747}
Bug: v8:11818
Change-Id: Ib5f952dc6f23f3a98bb1d79ae5ce689e288d6727
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940897
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74978}
.. and replace them by elements read directly from the heap object.
With this change, consistency between `map` and `elements` is
no longer guaranteed. Users were updated, when necessary, to deal
with this, e.g. by being more careful not to read out of bounds,
by inserting new `actual_elements == elements_constant` runtime
checks, or through a new compilation dependency that verifies
unchanged elements at finalization time.
Drive-by: inline GetElementsKind into callsites.
Bug: v8:7790
Change-Id: Ifba78182e185ff0d4e954e3be52f0eb24328c853
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2909655
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74977}
We currently take the sample at the moment the isolate is created. At
that point, the embedder callback for taking samples is not installed
yet. Hence delay taking the sample until the first module is created.
This will only take samples for isolates that actually use wasm, which
will reduce the overall number of samples, but will give a better
picture of PKU support for Wasm.
R=jkummerow@chromium.orgCC=dlehmann@google.com
Bug: v8:11714
Change-Id: I8a4163961c06076efd6c5dde5751682b53863c2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944429
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74975}
This reverts commit 79d63a5ef3.
Reason for revert: Breaks predictable: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20predictable/36887/overview
Original change's description:
> [wasm] Remove all implications from --predictable
>
> In predictable mode, we want to execute the same code as otherwise,
> modulo timing. Hence remove any implications which change behaviour
> (like tier-up or asynchronous compilation).
> Note that --predictable is a debugging flag, so the configurations does
> not need to "make sense" in production.
>
> R=ahaas@chromium.org
>
> Bug: v8:11848
> Change-Id: If74fbacadeb087d977922c41f33fd18738b50ded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940898
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74973}
Bug: v8:11848
Change-Id: I20eaf665e8ce63af8aeffe3bac7a45372ad6ab7b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944434
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#74974}
In predictable mode, we want to execute the same code as otherwise,
modulo timing. Hence remove any implications which change behaviour
(like tier-up or asynchronous compilation).
Note that --predictable is a debugging flag, so the configurations does
not need to "make sense" in production.
R=ahaas@chromium.org
Bug: v8:11848
Change-Id: If74fbacadeb087d977922c41f33fd18738b50ded
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940898
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74973}
Introduce EmitTSANStoreOOLIfNeeded methods which make it easier on the
eyes in code-generator.cc.
Also pass along the size, which lays the groundwork for the other
instructions e.g. kX64Movq since we don't require the store to be a
Tagged one. This creates new builtins (since we now have a version with
32 bits and another one for 64 bits stores). We can extract the common
code in builtins-internal-gen.cc to de-duplicate the common code.
Bug: v8:7790, v8:11600
Change-Id: I81d80b852ec96b94d170a20f6d61621743b74b32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933664
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74971}
This is a reland of 5fd3858258. It adds
back all recursive implications (via --single-threaded), such that we
can remove them individually in follow-up CLs and watch the state of
the predictable bot.
Original change's description:
> [flags] Predictable should not imply single-threaded
>
> The --predictable flag is often used to reproduce issues, and having it
> imply --single-threaded can change decisions like which compiler(s) to
> use. This is because --single-threaded is meant to be set by embedders
> (hence we do our best to support single-threaded execution), whereas
> --predictable is a testing-only flag which should not change semantics
> too much. The fact that --predictable executes everything in a single
> thread is already implied by the PredictablePlatform.
>
> R=ahaas@chromium.org, machenbach@chromium.org
> CC=jkummerow@chromium.org
>
> Change-Id: Ic174dd59dfdbd6aa1a410f983db05db26c944cd5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919828
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74822}
Change-Id: I7a060826761781727870dd96fffc42ced4675e76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933143
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74970}
This is a reland of 81dd3f42be,
which was a reland of 59eff3bfaa
Original change's description:
> [bigint] Karatsuba multiplication
>
> The Karatsuba algorithm is used for BigInts with 34 or more internal
> digits, and thanks to better asymptotic complexity provides greater
> speedups the bigger the inputs.
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2782283
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74916}
Bug: v8:11515
Change-Id: I08f7d59dfa39fb3b532684685afd9fa750e0e84e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933666
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74969}
Since there is only a single thread in predictable mode, we should never
wait for more work. That would be an immediate deadlock.
This CL adds code to never wait, and instead checks after processing all
messages that we would not need to wait (i.e. that all work was
completed). This turns deadlocks into FATAL errors.
R=ahaas@chromium.org
Bug: v8:11848
Change-Id: If61305d634803fc43678238dc6e9d3a2f35793c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940886
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74966}
Strict equality checking of ValueTypes only made sense before
reference types came along.
Change-Id: I632f541328cb27ae87a5e3daccd4ffb9cfc8a502
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928513
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74965}
Prepare method by taking an object as argument. In the future we can
optimize this method by only sweeping the object's page.
Bug: v8:11837
Change-Id: Ife1ee7949bfaf590dcc305cc4d03aa1813c07b76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940888
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74963}
This fixes a little mistake from https://crrev.com/c/2182453. In
predictable mode (where we do not have any threads for executing
background work) we are executing everything on the main thread, but we
should never wait for background work to be spawned. Otherwise we can
deadlock if the last background task spawned new foreground work, but we
keep waiting for more background work to arrive.
Generally, any blocking in predictable mode will block forever, because
there is no one to spawn any work concurrently (foreground or
background). But the blocking for foreground work has to be there for
non-predictable mode, thus keep it for now, and only remove waiting for
background work.
R=ahaas@chromium.org
Bug: v8:11848
Change-Id: I51c976f6858db8120baa4c47d28840a1041d7fea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940885
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74962}
This aids debugging as it gives the root set a name.
Bug: chromium:1164553, chromium:1186901
Change-Id: I2c2aed369823b059629b35bb170b4966b47156d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933661
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74960}
The tests are not compatible with the --stress-background-compile flag.
Bug: v8:11821
Change-Id: Iecef6a2838109fddc9f0ecc145a9f8971bc9bc3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2918214
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74959}
This is a reland of b0c70710a4
The first CL got reverted because of build errors. This CL replaces the
remaining usage of is_local_space() with is_compaction_space().
Supposedly this was a leftover because https://crrev.com/c/2928189
landed at roughly the same time.
Original change's description:
> [heap] Remove unused LocalSpace class
>
> LocalSpace was introduced for off-heap spaces with concurrent bytecode
> compilation finalization. However, finalization ended up using
> LocalHeap for concurrent allocations. LocalSpace is therefore unused
> and can be removed.
>
> This CL removes LocalSpace and renames all mentions of local space to
> compaction space. Compaction space was the only local space left.
>
> Change-Id: I12a8a2724f777a77ddb9957fe2d8e89febfebbaf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930169
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74914}
Change-Id: I993c47fe85f4140f5d6137afde2653a48047cafb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2939983
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74957}
