Currently, LiveEdit updates the source positions of unchanged SFIs
in-place (the SFI could have moved due to other functions changing).
This interfere with our plans to re-use ScopeInfo-based blocklists
for debug-evaluate. Entries in the global block list cache are keyed
by ScopeInfo's source position. Any closure that escaped a
debug-evaluate will point to the old ScopeInfo in its context chain
and the block lists should stay in-place in case the escaped closure
is called again.
Rather than updating ScopeInfos in-place, this CL updates the
ScopeInfo object wholesale for unchanged SFIs. This is safe todo
given that the old and new ScopeInfo are identical modulo source
positions.
Drive-by: Take the source position of the function token from the
`FunctionLiteral` rather than doing a more expensive position
translation.
Bug: chromium:1363561
Change-Id: I2b8476edd8d7dc4c618e53551aa5692a21d6fb32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3932724
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83536}
Due to a switch to C++20 on some platforms (linux) and -Wall
warnings configuration, it is necessary to explicitly list all
captures if 'this' is captured:
Capturing everything by value including this:
1) [=]() { ... }
--> C++17: OK
--> C++20 (GCC): implicit capture of 'this' via '[=]' is deprecated
2) [=, this]() {}
--> C++17: explicit capture of 'this' with a capture default of
'=' is a C++20 extension
--> C++20: OK
So, without ifdefs the most viable solution seems to be
capturing everything explicitly whenever 'this' is captured.
Change-Id: I673bf934a6869ebc5cad022935b207188be5dc5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3936145
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83534}
Prior to this CL the function prologue took roughly the first 340
bytes of any generated ML code object (release mode, x64). The
prologue handles deoptimization, optimization, stack (and interrupt)
checks, and stack frame setup including reserving and initializing
space for stack locals.
All this is now extracted to the MaglevOutOfLinePrologue builtin.
Costs:
- The extra unconditional builtin call at the start of ML code.
- Only dynamic knowledge of # stack slots (so we can't unroll
initialization loops as well as with static knowledge).
- Some extra complexity due to frame and return address juggling.
Benefits:
- 340 bytes saved per code object (memory).
- 340 bytes saved per code object (codegen time).
- The prologue contains 5 reloc entries, with an ool prologue we
don't have to iterate these at runtime.
The ool prologue can be enabled/disabled with --maglev-ool-prologue
(on by default).
One option for the future is to move stack slot initialization
back inline since it doesn't emit much code and benefits from static
knowledge of stack layout.
Bug: v8:7700
Change-Id: I182a9591e62d205de0223036ba8cb25e9c6a6347
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3934842
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83533}
This CL fixes the remaining test failures when running test with the
--shared-heap flag locally:
* Remove uses of shared_isolate()
* Fix slot recording in Mark-Compact and Scavenger
* Fixes DCHECKs in tests that do not hold with --shared-heap
Bug: v8:13267
Change-Id: I6869ece70f1e6156d9bb1281e6cd876cf8d471eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918377
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83530}
Objects reachable from untyped and typed OLD_TO_SHARED slots in client
heaps need to be marked. Before this CL a shared GC was not considering
typed slots.
Bug: v8:11708, v8:13338
Change-Id: I1c02345b1b5d403c5137f19a472650b9c6c26385
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3930835
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83529}
Shared heap requires write barriers to keep track of old to shared
references.
This CL also disables all shared-memory/* mjsunit tests for single
generation configurations. These tests generally should not work
since the single generation bot also disables write barriers.
This should resolve the remaining single generation failures.
Bug: v8:11708, v8:13322
Change-Id: Ie0b0cbbc782afb607c1d13ccb4edcb2672ebf51b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3934770
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83528}
Source map urls can be parsed from the magic comments. Expose them with
public apis on the UnboundModuleScript, similar to the UnboundScript.
Change-Id: Ia5dfdc8ff25f825c9fa7d241d0d79ba20028586b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3917379
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Chengzhong Wu (legendecas) <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#83527}
A page is considered unusable if a GC occurs due to allocation failure
and there were no allocations on the page since the last GC. That
indicates that fragmentation on the page is such that remaining free
space could not be used. In such cases, we force promote the page.
Bug: v8:12612
Change-Id: I2d1fbb63bb4248559f23952f080235040cabe81a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925755
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83524}
The uninstantiable hack doesn't seem to work on GCC.
Change-Id: I8a5ce9446cf3462a521b4e9ad6a1af4e09eeb4f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3932175
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83521}
Generalize the counters to avoid using semispace in the names and update
counters with live bytes of swept pages.
Updating the counters before the page is actually swept to keep aligned
with Scavenger (where all counters are updated during atomic pause) even
when sweeping becomes concurrent.
Bug: v8:12612
Change-Id: I1a1588225e343a7c2927bf61ee3935afb5f9fff5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916452
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83520}
The Symbols-as-WeakMap-keys proposal allows non-Symbol.for Symbol values
in weak collections, which means it can show in EntryPreviews.
Also apparently Symbols in regular Maps and Sets were also unsupported.
Bug: v8:13350, v8:12947
Change-Id: Ib10476fa2f3c7f59af67933f0bf61640be1bbd97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3930037
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83518}
Fix the node aspect destructive intersect to also consider entries at
the end of the LHS map; otherwise we'd accidentally keep entries that
are present in the LHS but after the end of the RHS.
Additionally, fix the entry clearing to avoid removing entries with no
known type but known alternative representations.
Bug: v8:7700
Change-Id: Ia25810db64f326ad2166beb875e0c03bb473278d
Fixed: v8:13109
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3928700
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83517}
We might generate a SwitchOnGeneratorState bytecode with zero jump table
entries if the JS code only has dead suspension points (where AST
suspensions are emitted, so suspend_count() > 0, but the bytecode for the
suspension ends up not being emitted because it's dead). An example
would be:
async function() {
return;
await 0;
}
In these cases, we can skip emitting the generator prologue, since the
function is not resumable.
Bug: v8:7700
Change-Id: Ie9f9d4fa8740f4ddc176cd5bbdc5beeda97ba8d5
Fixed: chromium:1370396
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3932946
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83516}
This change changes the type hierarchy in a non-backwards compatible
way: dataref is replaced with structref meaning that arrayref is
no longer a subtype of it.
Bug: v8:7748
Change-Id: I965267d9ed11ea7c7d7df133cc39ee63e6b5abc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3929041
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83515}
Our gn build files hide non-exported symbols by default, which results
in smaller binaries and can improve build times.
This was not ported to the bazel build and causes binary size
regressions in google 3.
Change-Id: I285914b83e75bd3bf406e6401f52ddb53230219a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925698
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83514}
This CL shuffles around some code so it becomes impossible to send the
response of an `EvaluateCallback` witout removing it from the owning
`InjectedScript` first.
R=jarin@chromium.org
Bug: chromium:1366843
Change-Id: I6ed8aa767f15802265995ab308cfdfa3fbe5ac0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3933353
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83513}
Due to stack slot reuse, any of the moves that are part of the handler
trampoline may conflict and thus need parallel move resolution.
Materialisations (= calls to the NewHeapNumber builtin) add an addtl
complication since a) materialising moves can also be part of any
move conflict, b) the builtin call may clobber arbitrary registers,
and c) materialisation need a spot to store the NewHeapNumber result.
We resolve this by materialising into new temporary stack slots
before the main move sequence, and popping into the final target
locations after the main move sequence.
Bug: v8:7700
Change-Id: I1734faf189d02e38af07a817a9b647e2dce54f22
Fixed: chromium:1368046
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3921515
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83511}
This CL merely maintains concurrent marking in MinorMC in a stable
state, i.e. it builds and passes tests.
Bug: v8:13012
Change-Id: I866fdbdfcdcc9ae101b63323aa43ceeeab882b45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3934271
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83510}
Provide dummies for performance methods that are irrelevant for
differential fuzzing.
Bug: chromium:1370405
Change-Id: I91dcadc446314dbfc97b09a95f054c867574e345
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3932722
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83509}
This CL replaces the raw pointer in the `ProtocolPromiseHandler` to the
`EvaluateCallback` with a std::weak_ptr. This better matches the
semantics. If the `ProtocolPromiseHandler` is able to lock the
shared_ptr, we still have to remove it from the `InjectedScript`
since the `ProtocolPromiseHandler` sends the response.
R=jarin@chormium.org
Bug: chromium:1366843
Change-Id: I7f371dbd5423f88105981996584ccba5f814dcdb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3933352
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83508}
There are a few DCHECKs that weren't updated to allow for Symbols as
weak collection keys. This CL updates those DCHECKs and also does the
following refactors for clarity:
- Add Object::CanBeHeldWeakly
- Rename GotoIfCannotBeWeakKey -> GotoIfCannotBeHeldWeakly to align with
spec AO name
Bug: chromium:1370400, chromium:1370402, v8:12947
Change-Id: I380840c8377497feae97e3fca37555dae0dcc255
Fixed: chromium:1370400, chromium:1370402
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3928150
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83507}
This CL fixes a use-after-free bug where we try to access an
`InjectedScript` object after it died. This can happen when we
transition into JS and back and the context group dies in the mean
time (e.g. because of a navigation). Normally we check for this but
we missed a call to `Promise#then`.
The access that triggers the UaF is when we try to stash away the
protocol callback function after returning from `Promise#then`.
The callback function is responsible for sending the protocol
response back to DevTools containing the result of the evaluation.
There are two objects with different lifetimes involved:
- InjectedScript: Owns the `EvaluationCallback`. We keep a
a reference in case the context group dies. This allows us to
cancel any pending evaluate requests.
- ProtocolPromiseHandler: Has a reference to `EvaluationCallback`.
The handler itself is managed by the V8 GC via `v8::External`
and a weak `v8::Global`.
When the `ProtocolPromiseHandler` wants use the callback to send
a response, it needs to take ownership first.
We could invert the ownership but it's preferable for evaluation
callbacks to die together with execution contexts and not when the
GC feels like it.
We fix the UaF by using an `InjectedSript::ContextScope` and reloading
the `InjectedScript` after we return from `Promise#then`. Then
we can take proper ownership of the callback and use it in case the
call failed.
R=jarin@chormium.org
Fixed: chromium:1366843
Change-Id: I3a68e8609a9681d7343c71f43cc6e67064f41530
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925937
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83506}
This reverts commit dc91addeef.
Reason for revert: Still causes failures on some bots: https://ci.chromium.org/ui/p/chromium/builders/ci/win-asan/23860/overview
Original change's description:
> Reland "[sandbox] Improve the default ArrayBufferAllocator for the sandbox"
>
> This is a reland of commit f08547afd4
>
> All ArrayBufferAllocators now share a backend allocator which owns the
> backing memory. This fixes the address space exchaustion issues.
>
> Original change's description:
> > [sandbox] Improve the default ArrayBufferAllocator for the sandbox
> >
> > Rather than using a page allocator and rounding all allocation request
> > sizes up to the next multiple of the OS page size, we now use a
> > base::RegionAllocator with a "page size" of 128 as a compromise between
> > the number of regions it needs to manage and the amount of wasted memory
> > due to allocations being rounded up to a multiple of that page size.
> > While this is still not as performant as a "real" allocator, it does
> > noticeably improve performance when allocating lots of ArrayBuffers.
> >
> > Bug: chromium:1340224
> > Change-Id: I56d1ab066ba55710864bdad048fb620078b2d8c2
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913346
> > Commit-Queue: Samuel Groß <saelo@chromium.org>
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#83396}
>
> Bug: chromium:1340224
> Change-Id: Ia52eeb695ad89cc6146807fda040281ac5fdaf59
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916640
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83502}
Bug: chromium:1340224
Change-Id: I3a9c306078b3dbe732024599823ab8b09b167f29
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3933351
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Samuel Groß <saelo@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83505}
This is a reland of commit f08547afd4
All ArrayBufferAllocators now share a backend allocator which owns the
backing memory. This fixes the address space exchaustion issues.
Original change's description:
> [sandbox] Improve the default ArrayBufferAllocator for the sandbox
>
> Rather than using a page allocator and rounding all allocation request
> sizes up to the next multiple of the OS page size, we now use a
> base::RegionAllocator with a "page size" of 128 as a compromise between
> the number of regions it needs to manage and the amount of wasted memory
> due to allocations being rounded up to a multiple of that page size.
> While this is still not as performant as a "real" allocator, it does
> noticeably improve performance when allocating lots of ArrayBuffers.
>
> Bug: chromium:1340224
> Change-Id: I56d1ab066ba55710864bdad048fb620078b2d8c2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913346
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83396}
Bug: chromium:1340224
Change-Id: Ia52eeb695ad89cc6146807fda040281ac5fdaf59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916640
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83502}
Rolling v8/build: 2d24822..9991d6b
Rolling v8/buildtools: cccaf48..bf023cc
Rolling v8/buildtools/third_party/libc++/trunk: 5ee02b2..591c991
Rolling v8/buildtools/third_party/libc++abi/trunk: 5c3e02e..20a144a
Rolling v8/buildtools/third_party/libunwind/trunk: 7ff728a..08ebcbe
Rolling v8/third_party/depot_tools: e3ed6a8..1b8211f
Rolling v8/third_party/zlib: cbb6b98..6fe4ce8
Rolling v8/tools/clang: 209fff0..a5e0d72
Change-Id: Id32bfaec11f400cc68c936a2bc030b6ab16a6b64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3929848
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83498}
The ASM argument -mmark-bti-property is not supported in GNU toolchain
assembler, so it breaks the build. Only pass it for Clang.
Bug: chromium:819294
Change-Id: Ib5a485fa74fd75c88582292c8648d742fa25e709
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3930160
Commit-Queue: José Dapena Paz <jdapena@igalia.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83497}
When incremental marking has started and the scavenger is triggered,
young generation pages that end up in the "from" space may contain
unclean markbits. In this case, inner pointer resolution may return
base pointers to the start of objects that are not on the page anymore.
This is problematic if the page contents have been zapped. This CL fixes
this and improves the corresponding unit test.
Bug: v8:13257
Change-Id: I9f4a05270a66e15e86519a2d6574b4afe100a48d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925935
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83496}
This CL implements local blocklist calculation as described in the
linked design doc below.
The main characteristics between the new, re-usable block lists and
the current implementation are:
- Block lists for a scope store the "outer" stack-allocated
variables, not "inner" variables.
- A block list contains all outer stack-allocated variables of all
outer scopes up to (and including) the next outer scope that
needs a context.
- It's not enough to only calculate blocklists between scopes that
require contexts, but we also need to calculate blocklists
for all function scopes. Future pauses may pause in outer
functions and we want to also re-use the blocklists for those.
R=jarin@chromium.org
Doc: https://bit.ly/chrome-devtools-debug-evaluate-design
Bug: chromium:1363561
Change-Id: I8af02424de8007f388faa82983337218bec87ed9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925195
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83494}
This will be used for lowering 64bit division by a constant.
Change-Id: I79153b81fe58757feeffb6c6c170f6f62fdd2a60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3872268
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83493}
Since code space is now swept concurrently as well, background threads
can now sweep code pages on allocation failures as well.
Change-Id: I493eb9bd8b1a95f58ddb96a5ced7f87d9397da47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3929038
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83489}
The flag is used inside const expressions so it's impossible to change
it at runtime. There's no reason that this is a command line flag.
Change-Id: I983aeabe8ed276599b28add4ab883546edc7039e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925197
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Stephen Röttger <sroettger@google.com>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83488}
When freeing a LAB, the black area needs to be destroyed as well. This
is in order to keep live byte accouting accurate.
This CL also removes merging of LABs as this is an optimization that
only happens on the background thread and not on the main thread
where most allocations occur.
Bug: v8:13267, v8:13343
Change-Id: I60dfdaec9697755ddbdb0939000afe34cd33d5fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3928745
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83487}
