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}
... when iteration over fast array is aborted. This change affects
JSCollection constructors.
According to the iteration protocol the iterator must be properly
closed in case the element can't be added to the collection.
Bug: chromium:1357318
Change-Id: I30cff249449dbb5ac0f48111a681caedcf37e326
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3928743
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83486}
With BigInt64 feedback, SpeculativeBigIntAdd can be lowered to
CheckedBigInt64Add with type checks for input. Deopt is triggered if
the result overflows or the input is out of range.
A unit test is added to make sure there is no deopt loop.
Bug: v8:9407
Change-Id: I61a25737208c81a9619d959961fc5ab10e069546
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3921521
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83485}
This CL implements a `Hash` function for ScopeInfo based on position
information. If no position information is available, we fall back to
the type and number of context variables.
Note that this is far from ideal, especially when no position info is
available. But, the hash is only used to store scope-related debug
information in the `LocalsBlocklistCache` hash table. This table is
only ever filled on debug pauses or debug-evaluates, so we don't
care that much if we produce many hash collisions.
R=jarin@chromium.org, leszeks@chromium.org
Doc: https://bit.ly/chrome-devtools-debug-evaluate-design
Bug: chromium:1363561
Change-Id: I70b7f2702693e2d930ed0080506ed94ac44e9124
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925434
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83484}
Refactor ETW tracing code to make sure ETW tracing sessions is
correctly started/stopped when a ETW controller (like Windows
Performance Recorder) start/stops a tracing session.
The goal is to enable support for ETW tracing by default making sure
that it does not cause any performance regressions.
Bug: v8:11043
Change-Id: I90085183a1c3f4d35ec7e964dbe4b38243aed0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3905922
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83480}
When evacuation gets aborted due to OOM we used to set the
COMPACTION_WAS_ABORTED page flag immediately. However other evacuation
threads might check the page flags of that exact page concurrently
while recording slots in migrated objects.
We can delay setting the COMPACTION_WAS_ABORTED page flags until
processing aborted evacuation candidates. At that point there are
no more concurrent evacuation threads running anymore.
In order to not break output of --trace-evacuation we also need a
return value for RawEvacuatePage.
Bug: v8:13336
Change-Id: I29a76af918ee4f2016ab6d7c26c2688ff6a14aae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925974
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83479}
Add simple implementations of performance.mark/performance.measure --
these aren't fully to spec, and in particular don't have the right base
class or prototype, but they're similar enough for simple use.
Additionally, log trace events for performance.measure, similar to
Chromium -- this allows us to annotate traces collected with d8's
--enable-tracing.
Change-Id: Ib4d7104ba94a261493c57334b2008956e4d89dd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918092
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83478}
The black area needs to be set up after the lab is fully initialized.
Otherwise the black area might not span the whole LAB.
Bug: v8:13267, chromium:1369056
Change-Id: Iee0f29c3b1a9c351df967167b5f7ed050d2a3b52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925794
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83477}
... as such is already thrown at an earlier point of the call chain.
Change-Id: Iad28438c3b6b0d0fdc178d95701908338500eaa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3921520
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83476}
The new ref.test (opcode 0xfb40) takes an any reference (vs. data on
the old instruction) and expects a HeapType immediate.
The HeapType can be a concrete or an abstract type.
Bug: v8:7748
Change-Id: Iaa2010af21d3fee76e27a5f4476ae00f5ca837a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913028
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83475}
Use separate flags for marking and sweeping.
Bug: v8:12612
Change-Id: I0841f531b7ea289d892b6f837e4c9ad8dbccd073
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918550
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83474}
This CL fixes three separate issues:
* Setting/clearing of right page flags for the shared space during
marking.
* The marking barrier needs to mark shared objects in the shared
space isolate.
* The scavenger needs to invoke TransferColor when promoting into
the shared heap in the shared space isolate.
Bug: v8:13267
Change-Id: Id3abcb73c26933bc7d5e74c9c3f4489aab97d703
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3921522
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83473}
assertThrows catches both early errors during parse time and exceptions
thrown during runtime.
To be able to test more specificially, add assertEarlyError to check for
syntax errors during parsing and assertThrowsAtRuntime to check that
code throws while executed.
Change-Id: I61ee78c4b2beec266dfbed3999cd4df1786d0c9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925198
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83472}
This reverts the following commits:
* [runtime] Clean up dead entries in the template cache"
8436c0059c.
* [runtime] Don't update template map for existing templates
e7b9604040.
* [runtime] Fix hash used in template cache
caa087bb18.
* [runtime] Hold cached template objects weakly
5d19e724d2.
* [runtime] Key template object cache on Script
f3a0e8bccf.
There are gerrit UI issues which appear to be template object caching
related.
For dashboard:
This reverts commit 8436c0059c.
This reverts commit e7b9604040.
This reverts commit caa087bb18.
This reverts commit 5d19e724d2.
This reverts commit f3a0e8bccf.
Bug: v8:13190
Bug: chromium:1366900
Change-Id: I9759771441a4dece2a5dbb47e462ce0c0c01b182
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925696
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83471}
Following up on https://crrev.com/c/3916453, we also remove the
confusing breakable and steppable positions from spreads in array
literals. These positions provide no meaningful advdantage for
developers, but just makes it annoying to step through code that
contains spreads.
Drive-by: Add similar inspector tests to ensure that the positions in
the stack are correctly inferred when stopped in the Symbol.iterator or
the next methods.
Before: https://imgur.com/jVf2JeB.png
After: https://imgur.com/u8SfNhy.png
Fixed: chromium:1368971
Change-Id: Ibf791167936c1ed28ac3240acb7c0846b11ebecb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925200
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83469}
Stop trying to be clever with reasoning around whether or not loop
lifetime extended nodes are loadable, and just spill them when they're
not.
Bug: v8:7700
Change-Id: I81389445e4479d72ea8f6b5ff7689baa7053d3d4
Fixed: chromium:1367678
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925202
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83468}
