- Add a SIGTERM handler in d8 that dupms the stack trace
- Send SIGTERM before SIGKILL in the test runner
Bug: v8:13115
Change-Id: I75285f33caabab61ff6ae83c1fbc6faf45cf595a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791906
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82173}
Async compilation with lazy compilation generated an error message that
did not include the function name. With this CL the function name now
gets included.
R=clemensb@chromium.org
Bug: v8:12852
Change-Id: Ia8aed83a2114a2c9da1367045404b20fa8554c8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804863
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82172}
The serialized module contains information for each function whether the
serialized code for the function exists, and whether the function has
been executed before serialization. The latter information is used to
decide if the function should get compiled eagerly after deserialization
(in case the function has been executed before serialization), or if the
function should get compiled lazily because it will probably not be
executed anytime soon.
So far this code only worked for eager compilation. When lazy compilation
was enabled, all functions would get compiled lazily after
deserialization. With this CL the behavior described above is extended to
lazy compilation.
R=clemensb@chromium.org
Bug: v8:12926
Change-Id: Ifd6f400396222105feffa472c2e8787e1358220e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807583
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82171}
Weak containers are re-traced during conservative stack scanning to
strongify their contents. This runs in parallel with concurrent
marking that could find new weak containers.
The CL fixes two issues:
- The concurrent marker could find a weak container and mark it but
would only add it to the set of weak containers afterwards. We need to
reverse this (using a lock) to make sure that the main thread sees the
marked weak container.
- The DCHECK for containment needs to be concurrency aware.
Bug: chromium:1349298
Change-Id: I1ec31db62647f7f1c19e9cc60976e09946551333
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807593
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82170}
Use marking already made several assumptions about node numbering
running just before it (in particular, that loop Phis can't be marked
when visited, but only when the loop back edge is visited). This wasn't
too bad initially, but now we have to bend over backwards to extract the
node id at loop headers for lifetime extension.
So, merge the numbering into the use marking.
Bug: v8:7700
Change-Id: I2f2e8feec8d0e25e302e92988109d88621879cd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3797830
Reviewed-by: 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@{#82167}
The is_unmerged_loop predicate was using the "unmerged_loop_marker"
predecessor sentinel value to decide whether the merge state is an
unmerged loop header or not. However, the predecessor values were
otherwise uninitialized. This means that with some amount of bad luck,
you could get an uninitialized predecessor which happened to hold the
unmerged loop marker (it's more likely than a 1 in 2^32 chance, because
it could be left over from a previous compilation's zone).
Since we anyway now store whether a merge state is a loop header for
other reasons, we can replace the sentinel logic with predecessor count
based logic for this predicate.
Bug: v8:7700, v8:13109
Change-Id: Ibabe23feefc2bb909cf2480113300cb4757114d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807591
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82166}
This is a reland of commit a1392fa113
The original change was reverted due to v8:13135, which was fixed
separately.
Original change's description:
> Enable background merging when --stress-background-compile
>
> This change adds new functions to BackgroundCompileTask which closely
> match those in BackgroundDeserializeTask. These functions allow a caller
> to manage background merging of newly compiled content into an existing
> Script from the Isolate compilation cache. These functions are not yet
> exposed via the API; instead, StressBackgroundCompileThread uses them to
> increase test coverage of the merging logic.
>
> Bug: v8:12808
> Change-Id: I4d2f429164223785169fe447ce2bdd8beaee00d4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793959
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82121}
Bug: v8:12808
Change-Id: I530c6e87bbad11e178ef4abfdc25fa98530f0224
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3806590
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#82165}
Some tests assume that liftoff code is available immediately after
compilation. Add the `--no-wasm-lazy-compilation` flag to these tests
so that they work even after shipping lazy compilation.
R=clemensb@chromium.org
Bug: v8:12926
Change-Id: I839610221390822b90b25e1bef3ae727fa33d1ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804862
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82162}
We create a constructor for CallBuiltin that accepts a feedback vector.
It assumes that the builtin expects a slot and the vector respectively
at the end.
Bug: v8:7700
Change-Id: I20f9b4ff172dca7779abd31a042b3bdc734df350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804250
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82159}
Turbofan optimizes TruncateInt64ToInt32 by trying to merge it into
its input. This can avoid generating a movl instruction. However, when
the input is BitcastTaggedToWordForTagAndSmiBits, it fails to apply
this optimization and this results in a redundant move:
Turbofan IR:
149: Load[kRepTaggedSigned|kTypeInt32](...)
150: BitcastTaggedToWordForTagAndSmiBits(149)
151: TruncateInt64ToInt32(150)
152: Word32And(151, 558)
Assembly:
103 movl r11,[r8+0x1f]
107 movl r11,r11
10a andl r11,0x4
This CL fixes this and avoids the redundant movl instruction.
Change-Id: Id59d1ce1e3b139344f750e903726dd9f338cfdba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787681
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Cr-Commit-Position: refs/heads/main@{#82156}
Currently, WebSnapshotDeserializer::CreateScopeInfo creates the
ScopeInfo first, and then creates its local names hashtable if
necessary. If GC occurs when creating the local names hashtable, the
object verifier correctly complains that the ScopeInfo doesn't have all
needed fields. The solution (consistent with ScopeInfo::Create) is to
create the local names hashtable first. That way, no GC can happen in
the interval after the ScopeInfo is allocated but before it has valid
fields.
Bug: v8:13135
Change-Id: Ifd6eb10e54a4151f7edb592bc19afa3263d41788
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3803674
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82155}
On-heap objects may have TracedReferences, which are uncompressed
pointers that still need to be conservatively scanned (another CL).
Bug: chromium:1325007
Change-Id: If05add36191978486f315dc1ef142a7ed8d4a7bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804808
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82152}
Port 4e329f8c8a
Original Commit Message:
The original CL did not handle the case where a GC gets triggered by
the allocation of the error object when compilation fails.
Orignal message:
Feedback vector allocation can trigger a GC, and thereby make the
WasmCompileLazyFrame visible for the GC. This CL add stack scanning
for the WasmCompileLazyFrame.
Design doc: http://doc/1peovM6N6C4nSEdC77l4uxU1L0njA0RTaOjy5F12r2CQR=ahaas@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I3cdd5b0cd72463a6b492fcafcabcf65e1da55eea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804694
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#82151}
Port 044a18ac24
Original Commit Message:
The {LiftoffAssembler::Load} method already receives an {i64_offset}
parameter which skips the UXTW (zero extension of 32-bit addresses) in
the memory operand. The same needs to happen on stores.
On 32-bit platforms, we cannot have addresses >=4GB anyway (they would
be detected as OOB before reaching the point in question), so this is
not a problem. On x64, all 32-bit registers are zero-extended already
(which is debug-checked in the generated code), so this is also no
problem (and we just ignore the additional parameter).
R=clemensb@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Ic531618875bf3b6abcf3741bcbe153e603d9f250
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3794647
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#82144}
The original CL did not handle the case where a GC gets triggered by
the allocation of the error object when compilation fails.
Orignal message:
Feedback vector allocation can trigger a GC, and thereby make the
WasmCompileLazyFrame visible for the GC. This CL add stack scanning
for the WasmCompileLazyFrame.
Design doc: http://doc/1peovM6N6C4nSEdC77l4uxU1L0njA0RTaOjy5F12r2CQ
Change-Id: I9be66c696e27f9ecf8228daf40ad6258f0e963d1
Bug: v8:12852
Fix: v8:13133
Change-Id: I9be66c696e27f9ecf8228daf40ad6258f0e963d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804599
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82138}
This reverts commit a1392fa113.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/43149/overview
Original change's description:
> Enable background merging when --stress-background-compile
>
> This change adds new functions to BackgroundCompileTask which closely
> match those in BackgroundDeserializeTask. These functions allow a caller
> to manage background merging of newly compiled content into an existing
> Script from the Isolate compilation cache. These functions are not yet
> exposed via the API; instead, StressBackgroundCompileThread uses them to
> increase test coverage of the merging logic.
>
> Bug: v8:12808
> Change-Id: I4d2f429164223785169fe447ce2bdd8beaee00d4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793959
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82121}
Bug: v8:12808
Change-Id: Ibb0bc2adb79e4655b39a8a6ac33d8c8ffc5ebdb9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804602
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82137}
This reverts commit 872b7faa32.
Reason for revert: Somewhat speculative revert because of https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/39673/overview (reverting locally resolved the issue for me)
Original change's description:
> Fix Context PromiseHook behaviour with debugger enabled
>
> This is a solution for https://github.com/nodejs/node/issues/43148.
>
> Due to differences in behaviour between code with and without the debugger enabled, some promise lifecycle events were being missed and some extra ones were being added. This change resolves this and verifies the event sequence is consistent between code with and without the debugger.
>
> Change-Id: I3dabf1dceb14233226b1752083d659f1c2f97966
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779922
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82132}
Change-Id: I3e05adead5d8033906055e0741854da68aade2ac
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804859
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82136}
In TierDown mode, all functions have to be compiled with Liftoff, even
if lazy compilation is enabled.
R=clemensb@chromium.org
Bug: v8:12852
Change-Id: If450563a6768f82439c77ef7c21ecef8e2b25475
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804255
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82134}
Add flag contradictions for "assert-types" flag and a README file for how
to add trials from the source side. Also restore "assert-types" and its
contradictions' probability since we can avoid contradictions now.
Bug: v8:1340816,v8:1336577
No-Try: true
Change-Id: I2a3af2d13cd2f9f542bec5c013c50bf26ff93cc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787878
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82133}
This is a solution for https://github.com/nodejs/node/issues/43148.
Due to differences in behaviour between code with and without the debugger enabled, some promise lifecycle events were being missed and some extra ones were being added. This change resolves this and verifies the event sequence is consistent between code with and without the debugger.
Change-Id: I3dabf1dceb14233226b1752083d659f1c2f97966
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779922
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82132}
Previously we've added has_scheduled_exception DCHECKs that were a bit
too strict in some cases.
- Remove unused exception_out param for TryRunMicrotasks
- Simplify overzealous DCHECK and clean up MicrotaskQueue::RunMicrotasks
Change-Id: I3a945a731573b6b3e44e17487fb8bf871b9a6793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789504
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82131}
This reverts commit 6119362077.
Reason for revert: Blocking roll: https://chromium-review.googlesource.com/c/chromium/src/+/3802992/
Original change's description:
> [heap, api] Check assumptions for embedder fields on set
>
> Previously, we would set embedder fields and do type checks (on
> embedder fields) in the GC. This does not work nicely as embedder
> fields contain system pointers whereas we can only operate with
> tag-aligned reads/writes. The end result of assembling pointers was
> somtimes broken for concurrent marking.
>
> In this CL we reverse the mode and check assumptions when writing the
> fields. From Blink we generally only write once and use the fields in
> the GC and via reads multiple times.
>
> We assume, that when running with CppHeap, any pointer on an instance
> field that points into CppHeap, also has the type field set with the
> appropriate tracing information. In debug builds we also verify that
> the embedder field indeed points to the start of an Oilpan object.
>
> Bug: chromium:1337690
> Change-Id: I9f9a8e691cdcf666861a455dcf8f65f2fe80b034
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788206
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82120}
Bug: chromium:1337690
Change-Id: Iaece8f51883c7d001fb18ef48faaf271c48b8f11
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804245
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82127}
This is a strictly code moving change. We move the diffing algorithm
out of liveedit.cc into its own file.
We want to replace the current diffing algorithm and to stay safe we
will ship old and new algorithm side-by-side for a release for easy
revertability. Given that liveedit.cc is already large enough we
extract the diffing algo into a separate file.
R=kimanh@chromium.org
Bug: chromium:1205288
Change-Id: If5ebb6c2dff2f00387c9e2ab87e4bb61d1f1484a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3802687
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82124}
