Experiment with enabling FLAG_local_heaps for a few days to see whether
pause times regress and to catch bugs.
Bug: v8:10315
Change-Id: Iefc329bbc1b8131796f1db2a729ee358bef88894
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375190
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69561}
To properly test tier-up in the V8 test suite, change the test variant
previously called --turbo-nci-as-highest-tier to
--turbo-nci-as-midtier. As a midtier (between ignition and turbofan),
all major parts of the NCI pipeline (codegen, caching inside the same
native context, tier-up) are exercised by test suite.
Bug: v8:8888
Change-Id: Ic8ee2f3e3d72768c3869f5e0b25800dd0a5f25b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2361462
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69501}
This reverts commit dc18b82221.
Reason for revert: still causing failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/31566
Original change's description:
> Reland^3 "[flags] warn about contradictory flags"
>
> This is a reland of 0ba115e6a9
> Changes:
> - Also allow second parameter influenced by --cache to be reassigned.
> - Fix --stress-opt to only --always-opt in the last iteration as before.
>
> Original change's description:
> > Reland^2 "[flags] warn about contradictory flags"
> >
> > This is a reland of d8f8a7e210
> > Change compared to last reland:
> > - Do not check for d8 flag contradictions in the presence of --fuzzing
> > - Allow identical re-declaration of --cache=*
> >
> > Original change's description:
> > > Reland "[flags] warn about contradictory flags"
> > >
> > > This is a reland of b8f9166664
> > > Difference to previous CL: Additional functionality to specify
> > > incompatible flags based on GN variables and extra-flags, used
> > > to fix the issues that came up on the waterfall.
> > >
> > > This also changes the rules regarding repeated flags: While
> > > explicitly repeated flags are allowed for boolean values as long
> > > as they are identical, repeated flags or explicit flags in the
> > > presence of an active implication are disallowed for non-boolean
> > > flags. The latter simplifies specifying conflict rules in
> > > variants.py. Otherwise a rule like
> > >
> > > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > > "--gc-interval=*": ["--gc-interval=*"],
> > > }
> > >
> > > wouldn't work because specifying the same GC interval twice
> > > wouldn't actually count as a conflict. This was an issue with
> > > test/mjsunit/wasm/gc-buffer.js, which specifies
> > > --gc-interval=500 exactly like the extra flag by the stress bot.
> > >
> > > Also, this now expands contradictory flags checking to d8 flags
> > > for consistency.
> > >
> > > Original change's description:
> > > > [flags] warn about contradictory flags
> > > >
> > > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > > >
> > > > Bug: v8:10577
> > > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#68168}
> > >
> > > Bug: v8:10577
> > > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68989}
> >
> > Bug: v8:10577
> > Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69339}
>
> Bug: v8:10577
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Change-Id: I4a69dc57a102782cb453144323e3752ac8278624
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69433}
TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
Change-Id: I4ccdd7b931d0ddccbcec1d6cfae8d4874ee49cfc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10577
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360414
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69438}
This is a reland of 0ba115e6a9
Changes:
- Also allow second parameter influenced by --cache to be reassigned.
- Fix --stress-opt to only --always-opt in the last iteration as before.
Original change's description:
> Reland^2 "[flags] warn about contradictory flags"
>
> This is a reland of d8f8a7e210
> Change compared to last reland:
> - Do not check for d8 flag contradictions in the presence of --fuzzing
> - Allow identical re-declaration of --cache=*
>
> Original change's description:
> > Reland "[flags] warn about contradictory flags"
> >
> > This is a reland of b8f9166664
> > Difference to previous CL: Additional functionality to specify
> > incompatible flags based on GN variables and extra-flags, used
> > to fix the issues that came up on the waterfall.
> >
> > This also changes the rules regarding repeated flags: While
> > explicitly repeated flags are allowed for boolean values as long
> > as they are identical, repeated flags or explicit flags in the
> > presence of an active implication are disallowed for non-boolean
> > flags. The latter simplifies specifying conflict rules in
> > variants.py. Otherwise a rule like
> >
> > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > "--gc-interval=*": ["--gc-interval=*"],
> > }
> >
> > wouldn't work because specifying the same GC interval twice
> > wouldn't actually count as a conflict. This was an issue with
> > test/mjsunit/wasm/gc-buffer.js, which specifies
> > --gc-interval=500 exactly like the extra flag by the stress bot.
> >
> > Also, this now expands contradictory flags checking to d8 flags
> > for consistency.
> >
> > Original change's description:
> > > [flags] warn about contradictory flags
> > >
> > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > >
> > > Bug: v8:10577
> > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68168}
> >
> > Bug: v8:10577
> > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68989}
>
> Bug: v8:10577
> Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69339}
Bug: v8:10577
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: I4a69dc57a102782cb453144323e3752ac8278624
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69433}
This is a reland of f4548e7598
Original change's description:
> [regalloc] Place spill instructions optimally
>
> Design doc:
> https://docs.google.com/document/d/1n9ADWnDI-sw0OvdSmrthf61prmDqbDmQq-NSrQw2MVI/edit?usp=sharing
>
> Most of this change follows directly what is discussed in the design
> document. A few other things are also changed:
>
> - PopulateReferenceMapsPhase is moved after ResolveControlFlowPhase so
> that it can make use of the decision regarding whether a value is
> spilled at its definition or later.
> - SpillSlotLocator is removed. It was already somewhat confusing,
> because the responsibility for marking blocks as needing frames was
> split: in some cases they were marked by SpillSlotLocator, and in
> other cases they were marked by CommitSpillsInDeferredBlocks. With
> this change, that split responsibility would become yet more
> confusing if we kept SpillSlotLocator for the values that are spilled
> at their definition, so I propose a simpler rule that whatever code
> adds the spill move also marks the block.
> - A few class definitions (LiveRangeBound, FindResult,
> LiveRangeBoundArray, and LiveRangeFinder) are moved without
> modification from register-allocator.cc to register-allocator.h so
> that we can refer to them from another cc file.
>
> Bug: v8:10606
> Change-Id: I374a3219a5de477a53bc48117e230287eae89e72
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285390
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69345}
Bug: v8:10606
Change-Id: I10fc1ef4b0bebb6c9f55ebdefe33e8c1e5646f0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352483
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69427}
This patch introduces a new LocalIsolate and LocalFactory, which use
LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
us to remove those classes, as well as the related OffThreadSpace,
OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
OffThreadLogger becomes LocalLogger.
LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
us to additionally remove the concept of "Finish" and "Publish" that the
OffThreadIsolate had, and allows us to internalize strings directly with
the newly-concurrent string table (where the implementation can now move
to FactoryBase).
This patch also removes the off-thread support from the deserializer
entirely, as well as removing the LocalIsolateWrapper which allowed
run-time distinction between Isolate and OffThreadIsolate. LocalHeap
doesn't support the reservation model used by the deserializer, and we
will likely move the deserializer to use LocalIsolate unconditionally
once we figure out the details of how to do this.
Bug: chromium:1011762
Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69397}
ArrayBufferTracker was superseded by ArrayBufferList and
ArrayBufferSweeper. Now that ArrayBufferSweeper is used in production,
we can remove the unused ArrayBufferTracker mechanism.
Bug: v8:10064
Change-Id: I479169c76b6c5c634672024f77e689bb64a36504
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339105
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69351}
This reverts commit f4548e7598.
Reason for revert: Breaks some gap resolver tests:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/24204
Original change's description:
> [regalloc] Place spill instructions optimally
>
> Design doc:
> https://docs.google.com/document/d/1n9ADWnDI-sw0OvdSmrthf61prmDqbDmQq-NSrQw2MVI/edit?usp=sharing
>
> Most of this change follows directly what is discussed in the design
> document. A few other things are also changed:
>
> - PopulateReferenceMapsPhase is moved after ResolveControlFlowPhase so
> that it can make use of the decision regarding whether a value is
> spilled at its definition or later.
> - SpillSlotLocator is removed. It was already somewhat confusing,
> because the responsibility for marking blocks as needing frames was
> split: in some cases they were marked by SpillSlotLocator, and in
> other cases they were marked by CommitSpillsInDeferredBlocks. With
> this change, that split responsibility would become yet more
> confusing if we kept SpillSlotLocator for the values that are spilled
> at their definition, so I propose a simpler rule that whatever code
> adds the spill move also marks the block.
> - A few class definitions (LiveRangeBound, FindResult,
> LiveRangeBoundArray, and LiveRangeFinder) are moved without
> modification from register-allocator.cc to register-allocator.h so
> that we can refer to them from another cc file.
>
> Bug: v8:10606
> Change-Id: I374a3219a5de477a53bc48117e230287eae89e72
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285390
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69345}
TBR=rmcilroy@chromium.org,seth.brenith@microsoft.com,thibaudm@chromium.org
Change-Id: Ie57109a009ee7ee541a6ff6f89901d1ac99027d2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2350440
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69347}
Design doc:
https://docs.google.com/document/d/1n9ADWnDI-sw0OvdSmrthf61prmDqbDmQq-NSrQw2MVI/edit?usp=sharing
Most of this change follows directly what is discussed in the design
document. A few other things are also changed:
- PopulateReferenceMapsPhase is moved after ResolveControlFlowPhase so
that it can make use of the decision regarding whether a value is
spilled at its definition or later.
- SpillSlotLocator is removed. It was already somewhat confusing,
because the responsibility for marking blocks as needing frames was
split: in some cases they were marked by SpillSlotLocator, and in
other cases they were marked by CommitSpillsInDeferredBlocks. With
this change, that split responsibility would become yet more
confusing if we kept SpillSlotLocator for the values that are spilled
at their definition, so I propose a simpler rule that whatever code
adds the spill move also marks the block.
- A few class definitions (LiveRangeBound, FindResult,
LiveRangeBoundArray, and LiveRangeFinder) are moved without
modification from register-allocator.cc to register-allocator.h so
that we can refer to them from another cc file.
Bug: v8:10606
Change-Id: I374a3219a5de477a53bc48117e230287eae89e72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285390
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69345}
This reverts commit 0ba115e6a9.
Reason for revert: Breaks test on TSAN - block-conflicts
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/14230
Original change's description:
> Reland^2 "[flags] warn about contradictory flags"
>
> This is a reland of d8f8a7e210
> Change compared to last reland:
> - Do not check for d8 flag contradictions in the presence of --fuzzing
> - Allow identical re-declaration of --cache=*
>
> Original change's description:
> > Reland "[flags] warn about contradictory flags"
> >
> > This is a reland of b8f9166664
> > Difference to previous CL: Additional functionality to specify
> > incompatible flags based on GN variables and extra-flags, used
> > to fix the issues that came up on the waterfall.
> >
> > This also changes the rules regarding repeated flags: While
> > explicitly repeated flags are allowed for boolean values as long
> > as they are identical, repeated flags or explicit flags in the
> > presence of an active implication are disallowed for non-boolean
> > flags. The latter simplifies specifying conflict rules in
> > variants.py. Otherwise a rule like
> >
> > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > "--gc-interval=*": ["--gc-interval=*"],
> > }
> >
> > wouldn't work because specifying the same GC interval twice
> > wouldn't actually count as a conflict. This was an issue with
> > test/mjsunit/wasm/gc-buffer.js, which specifies
> > --gc-interval=500 exactly like the extra flag by the stress bot.
> >
> > Also, this now expands contradictory flags checking to d8 flags
> > for consistency.
> >
> > Original change's description:
> > > [flags] warn about contradictory flags
> > >
> > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > >
> > > Bug: v8:10577
> > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68168}
> >
> > Bug: v8:10577
> > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68989}
>
> Bug: v8:10577
> Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69339}
TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
Change-Id: I1454a05e357ddd704db7fb79e51be65d45a9a16e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10577
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2348365
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69341}
This is a reland of d8f8a7e210
Change compared to last reland:
- Do not check for d8 flag contradictions in the presence of --fuzzing
- Allow identical re-declaration of --cache=*
Original change's description:
> Reland "[flags] warn about contradictory flags"
>
> This is a reland of b8f9166664
> Difference to previous CL: Additional functionality to specify
> incompatible flags based on GN variables and extra-flags, used
> to fix the issues that came up on the waterfall.
>
> This also changes the rules regarding repeated flags: While
> explicitly repeated flags are allowed for boolean values as long
> as they are identical, repeated flags or explicit flags in the
> presence of an active implication are disallowed for non-boolean
> flags. The latter simplifies specifying conflict rules in
> variants.py. Otherwise a rule like
>
> INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> "--gc-interval=*": ["--gc-interval=*"],
> }
>
> wouldn't work because specifying the same GC interval twice
> wouldn't actually count as a conflict. This was an issue with
> test/mjsunit/wasm/gc-buffer.js, which specifies
> --gc-interval=500 exactly like the extra flag by the stress bot.
>
> Also, this now expands contradictory flags checking to d8 flags
> for consistency.
>
> Original change's description:
> > [flags] warn about contradictory flags
> >
> > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> >
> > Bug: v8:10577
> > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68168}
>
> Bug: v8:10577
> Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68989}
Bug: v8:10577
Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69339}
We used to check the size of tables at compile time, and threw a
CompilationError if a given size exceeded the implementation-defined
limit. However, the spec defines that an error should only be thrown
when the implementation-defined limit is reached, which is either at
instantiation time of during runtime at a table.grow.
With this CL the V8 implementation becomes spec compliant in this
regard.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: I7d0e688b385a65e4060a569e5ab1dec68947ceea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326331
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69267}
The DevTools front-end uses so-called Wasm evaluator modules to get to
the values of variables in scope when the wasmDWARFDebugging experiment
is turned on. We rely on the `Debugger.executeWasmEvaluator()` method in
the Chrome DevTools Protocol (CDP) to accomplish this, which in turn is
controlled by this global flag.
Since we intend to gather more feedback from selected internal /
external teams on the DWARF debugging experience, we need to ship this
flag by default to make it easier to test the new experiment without
having to fiddle with additional flags to pass to Chrome on the command
line (and asking folks whether they really started Chrome correctly).
Bug: chromium:1041362
Change-Id: I1e170383fa7a34c41eec8c4867c38b7d8e871e8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335072
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69212}
This prints a message whenever we discard compiled metadata of an SFI.
The message identifies the SFI. I've found this helpful when debugging.
Change-Id: Ib34266199ade2ef88a6bafe32295ab505ce7c899
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324260
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69132}
1. Adds a flag to specify if minimorphic accesses should be optimized
using dynamic map checks operators. This flag is disabled by default.
2. Builds the PropertyAccessInfo from handlers instead of reading it
from maps for minimorphic accesses
3. Uses DynamicMapChecks operator to lower the minimorphic accesses.
Bug: v8:10582, v8:9684
Change-Id: I0b7b26b876f9ad12d6fc38788137b66ee6455aeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241524
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69112}
This generic wrapper builtin is currently used only when the wasm
function has no parameters and no return value.
Added a new V8 flag to use this generic wrapper.
Also added a JS test function for this generic wrapper.
Bug: v8:10701
Change-Id: Id8cd1771f26922927363b715d8a6ffd384a143ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2307240
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69097}
This flag's name is slightly incorrect as it is possible to have more
maps than this in the feecback vector.
This flag doesn't account for deprecated maps in the feedback
vector. To make this explicit, we change the flag to indicate that
this only counts valid maps.
Bug: v8:10582
Change-Id: Ib0cc425a03d590bb21184fc6b104d0ebee1d5b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319992
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69075}
This flag is already baked into the snapshot by enabling more
write-barrier elimination, so changing it at runtime would be a bug.
Change-Id: I3bc73f3c880285ec46b69b0c44934f64b49912ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2290856
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69046}
Adds the first phase of the fast register allocator, which runs through
the instruction stream and defines a VirtualRegisterData for each
virtual register based on how that virtual register is produced. Also
adds logic to pipeline.cc to allocate and use FastRegistorAllocatorData
for use throughout the fast register allocation phases.
BUG=v8:9684
Change-Id: I2f4533467346d5f3fdf50a0a1fedd7e4082f0187
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2295364
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69010}
Design doc:
https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing
V8 can already collect data about how many times each basic block in the
builtins is run. This change enables using that data for profile-guided
optimization. New comments in BUILD.gn describe how to use this feature.
A few implementation details worth mentioning, which aren't covered in
the design doc:
- BasicBlockProfilerData currently contains an array of RPO numbers.
However, this array is always just [0, 1, 2, 3, ...], so this change
removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument
ensures that the removal is valid.
- RPO numbers, while useful for printing data that matches with the
stringified schedule, are not useful for matching profiling data with
blocks that haven't been scheduled yet. This change adds a new array
of block IDs in BasicBlockProfilerData, so that block counters can be
used for PGO.
- Basic block counters need to be written to a file so that they can be
provided to a subsequent run of mksnapshot, but the design doc doesn't
specify the transfer format or what file is used. In this change, I
propose using the existing v8.log file for that purpose. Block count
records look like this:
block,TestLessThanHandler,37,29405
This line indicates that block ID 37 in TestLessThanHandler was run
29405 times. If multiple lines refer to the same block, the reader
adds them all together. I like this format because it's easy to use:
- V8 already has robust logic for creating the log file, naming it to
avoid conflicts in multi-process situations, etc.
- Line order doesn't matter, and interleaved writes from various
logging sources are fine, given that V8 writes each line atomically.
- Combining multiple sources of profiling data is as simple as
concatenating their v8.log files together.
- It is a good idea to avoid making any changes based on profiling data
if the function being compiled doesn't match the one that was
profiled, since it is common to use profiling data downloaded from a
central lab which is updated only periodically. To check whether a
function matches, I propose using a hash of the Graph state right
before scheduling. This might be stricter than necessary, as some
changes to the function might be small enough that the profile data is
still relevant, but I'd rather err on the side of not making incorrect
changes. This hash is also written to the v8.log file, in a line that
looks like this:
builtin_hash,LdaZeroHandler,3387822046
Bug: v8:10470
Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69008}
DateTimeFormat's fractionalSecondDigits shipped in M84, so we
can drop the --harmony_intl_dateformat_fractional_second_digits
flag now.
Bug: v8:10485
Change-Id: If7a1a8599722073d7382635219a6fb46cdc47474
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2311410
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69007}
This reverts commit d8f8a7e210.
Reason for revert: Breaks code_serializer variant - https://cr-buildbucket.appspot.com/build/8874070652992164976
Original change's description:
> Reland "[flags] warn about contradictory flags"
>
> This is a reland of b8f9166664
> Difference to previous CL: Additional functionality to specify
> incompatible flags based on GN variables and extra-flags, used
> to fix the issues that came up on the waterfall.
>
> This also changes the rules regarding repeated flags: While
> explicitly repeated flags are allowed for boolean values as long
> as they are identical, repeated flags or explicit flags in the
> presence of an active implication are disallowed for non-boolean
> flags. The latter simplifies specifying conflict rules in
> variants.py. Otherwise a rule like
>
> INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> "--gc-interval=*": ["--gc-interval=*"],
> }
>
> wouldn't work because specifying the same GC interval twice
> wouldn't actually count as a conflict. This was an issue with
> test/mjsunit/wasm/gc-buffer.js, which specifies
> --gc-interval=500 exactly like the extra flag by the stress bot.
>
> Also, this now expands contradictory flags checking to d8 flags
> for consistency.
>
> Original change's description:
> > [flags] warn about contradictory flags
> >
> > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> >
> > Bug: v8:10577
> > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68168}
>
> Bug: v8:10577
> Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68989}
TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
Change-Id: I7969065b0edbc463a94e530485bc2ab623d77b62
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10577
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312782
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68992}
This is a reland of b8f9166664
Difference to previous CL: Additional functionality to specify
incompatible flags based on GN variables and extra-flags, used
to fix the issues that came up on the waterfall.
This also changes the rules regarding repeated flags: While
explicitly repeated flags are allowed for boolean values as long
as they are identical, repeated flags or explicit flags in the
presence of an active implication are disallowed for non-boolean
flags. The latter simplifies specifying conflict rules in
variants.py. Otherwise a rule like
INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
"--gc-interval=*": ["--gc-interval=*"],
}
wouldn't work because specifying the same GC interval twice
wouldn't actually count as a conflict. This was an issue with
test/mjsunit/wasm/gc-buffer.js, which specifies
--gc-interval=500 exactly like the extra flag by the stress bot.
Also, this now expands contradictory flags checking to d8 flags
for consistency.
Original change's description:
> [flags] warn about contradictory flags
>
> Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
>
> Bug: v8:10577
> Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68168}
Bug: v8:10577
Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68989}
... behind --trace-zone-type-stats flag.
Per-object-type statistics requires the following GN args:
v8_enable_precise_zone_stats = true
use_rtti = true
When precise zone stats is enabled, the used zone memory value is
calculated more precisely, in particular it takes into account
the state of the active segment. By default, the used memory in
the active segment is not taken into account because of performance
overhead.
Bug: v8:10572
Change-Id: I938d9e264cfe6a8b63a89db87d187d8e2be63c8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2281006
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68972}
On desktop systems, we use a very basic tiering strategy: Everything is
initially compiled with Liftoff, and once that is done, the module can
start being used. Concurrently to the execution, we re-compile all code
with TurboFan, and hot-swap each function once TurboFan finishes.
We should start using a more dynamic strategy where each function is
tiered-up when judged necessary. This change will then tier-up each
liftoff function once it has been called 5 times.
I then added a counter in the native module, that is updated directly
from Liftoff code, and a runtime call is then made when the counter
reaches the goal.
R=clemensb@chromium.org
CC=thibaudm@chromium.org
Bug: v8:10728
Change-Id: I8dc2b02fdff8d97781bb1cf496886594b3d7f644
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2306803
Commit-Queue: Arnaud Robin <arobin@google.com>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68971}
This commit moves the d8 Synopsis/Usage string from flags.cc into d8.cc.
The motivation for this is that Commit
c8679386bd ("[snapshot] enable mksnapshot
usage to be displayed") enabled a usage string to be passed into
means mksnapshot --help will first print it's own usage string followed
by d8's.
FlagList: :SetFlagsFromCommandLine and be printed, but
FlagList: :PrintHelp currently still prints the Synopsis for d8 which
Change-Id: I9c79b2cdc5570106e12096c0c53e640cf80742e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299365
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68912}
Adds basic framework to pipeline.cc to enable a seperate fast register
allocator for the TurboProp mid-tier. As part of this, common logic as
well as a base class for RegisterAllocationData is moved to a seperate
register-allocation.h header file. The current register allocator's
RegisterAllocationData is renamed to TopTierRegisterAllocationData, and
the former name is the new base class held in PipelineData.
BUG=v8:9684
Change-Id: I28285b7d6112505bf90e88ea3cda66d03dfabc74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2295359
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68852}
Currently, when specifying '--help' with mksnapshot it will only
print the v8/d8 help message and options and then exit the process.
This means that the usage message from mksnapshot will never be
displayed.
This commit suggests adding an option to SetFlagsFromCommandLine that
can disable this printing and exiting. This allows mksnapshot to display
the usage and print the options after that.
While this works, it does seems a little strange that
SetFlagsFromCommandLine prints the help message and exits the process
but I'm probably missing some background details around this.
Change-Id: I28932adf3478b88b05eed4db70bf74946f8abf2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2290852
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68851}
The Sw/Sd in FillStackSlotsWithZero should't use kSystemPointerSize as
address offset, because the start address should be inclusive, and
the end address should be exclusive.
The skip-stack-guard-page test case failed due to this bug, and besides,
it also needs larger stack size on mips simulator.
Change-Id: Ieff55fe2c5a13e6dad1c5d073e1c0d22fe789d41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282663
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68834}
--trace-wasm-decoder should not imply --single-threaded, as
--single-threaded implies --no-liftoff. Hence we cannot trace the
decoder in Liftoff mode.
R=thibaudm@chromium.org
Change-Id: I3e4f0ea119288ef88c4b00dd2f2a11244b77c204
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287492
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68741}
Turbofan now has support for generating generic code in two variants,
with and without feedback collection. Currently, feedback is collected
only for some load and store operators (historical reasons).
This CL enables feedback collection for (almost) all operators by
default. The exception in the default TF configuration are call and
construct variants (see also https://crrev.com/c/2276042). In NCI mode,
all operators collect feedback.
Regression have looked acceptable in our benchmarks so far. This is an
experiment to see impact on real world. If successful, the
non-collecting variants can be removed.
Bug: v8:8888
Change-Id: I0dddc7113ce94071552d5c4d992471db5ac5f989
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2239571
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68710}
This adds --gc-experiment-reduce-concurrent-marking-tasks to be used
in a Finch experiment.
Bug: v8:10442
Change-Id: Ie2adf4faa20c99d1793907dfc6857497743f8d5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280093
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68673}
The change instruments code generation for Gap Solver so that these
counters are run-time and didn't impact register allocation.
The implementation is put behind a flag to help better register
allocation analysis.
Bug: v8:10663
Change-Id: Ia342d990e2b2bfc6a7653a770f670e51eef71312
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2269362
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#68664}
Whether or not a store requires a write barrier depends on several
invariants within V8. Some flags can break these invariants. In
particular, it's not possible to use enable_single_generation with
incremental marking because marking barriers are omitted in places where
it is assumed an object will be allocated in the young generation.
This CL introduces a new flag, enable_unconditional_write_barriers,
which allows us to specify that full write barriers should always
happens. The main purpose of this is to support single generation GC
with incremental marking, but it can also aid as a debugging tool to
check for missed write barriers.
Bug: v8:10614
Change-Id: I3ab640436bcefc118c9c5c34765421cb9ea4896f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270546
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jake Hughes <jakehughes@google.com>
Cr-Commit-Position: refs/heads/master@{#68623}
Add an experimental flag to allow modules up to a size slightly below
2GB, to make sure that we don't run into integer overflows.
Modules this large are not tested at all currently, hence the explicit
"experimental" in the flag name.
Drive-by: Fix one comparison to use ">" instead of ">=".
R=ahaas@chromium.org
CC=bmeurer@chromium.org
Bug: v8:10642
Change-Id: I91cfc290c262b9b81750e3c8af5358c1cd2572b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2266535
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68547}
It will be used in a Finch experiment to evaluate if icache flushing
helps with crashes on certain CPUs.
Bug: chromium:889460
Change-Id: I1218ce93db001833e29fdeca8fde3e863e26dfdd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267297
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68545}
With this CL d8 exits with an error code if there is an unhandled
promise rejection, e.g. due tue a failed assertion in a promise. Up
until now these assertions were just ignored.
Bug: v8:10556
Change-Id: I25f20e4be45a2de130562deb15f6a144f0ac976f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238569
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68503}
Currently, atomics operations are only allowed on shared memory and are
enabled on regular memory behind the --wasm-atomics-on-non-shared-memory
flag. Set the default value of this flag to true. This enables the
following behaviors:
- No validation failures when atomic opcodes are used on wasm memory
backed by ArrayBuffers
- memory.atomics.wait{32/64} operations will trap when wasm memory is
not shared
- memory.atomics.notify will always return 0 if wasm memory is not
not shared.
Bug: v8:9921
Change-Id: I1feb8c3db428187ee192ea72277957bfde9ac4b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2258099
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68486}
This changes black/white list to block/allow list.
Bug: v8:10619
Change-Id: Id55d72f90891670ca57b62dfeb6b3251025927dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257228
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68464}
... when jitless is enabled to fix fuzzers that pass random flag
combinations.
Bug: chromium:1096168,v8:7777
Change-Id: Ia78c4d9e1256e44c10df2200ecc32067a617d777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257220
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68458}
We rely on Liftoff for debugging, hence enable it everywhere by default.
This follows a chromium finch experiment and a CL to enable it
everywhere in chrome: https://crrev.com/c/2252100R=ecmziegler@chromium.org
Bug: chromium:1040030
Change-Id: I3abbf915515883e6eb1f37501466290def57862d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2252196
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68431}
At this point in development, this is a reasonable config for the nci
test variant.
--turbo-nci currently disables some compiler phases and avoids
embedded context-dependent constants.
--turbo-collect-feedback-in-generic-lowering enables full feedback
collection in generic lowering.
I'm keeping the two as separate flags for now since it can be
interesting to benchmark --turbo-nci both with- and without feedback
collection.
Bug: v8:8888
Change-Id: I678baeb0ed051b158ac0634f00de9b6a55f87e09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247770
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68411}
This subsumes the old behavior of --allow-natives-for-fuzzing under
--fuzzing as well. Both flags are used in a redundant way in fuzz
configs. Only --allow-natives-for-fuzzing wasn't specified as a
required argument, leading to the bug below.
We still need the flag --allow-natives-for-differential-fuzzing
to allow different functions when using differential fuzzing.
Bug: chromium:1094866
Change-Id: I398791779e58ed4d80e896c1cfea343848159212
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2246568
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68401}
This adds a dedicated --turbo-collect-feedback-in-generic-lowering
flag instead of piggy-backing on top of --turbo-nci in order to free
that up for upcoming work.
The new flag is temporary and can be removed once we've collected
enough data and made a decision on whether to enable it
unconditionally.
Bug: v8:8888
Change-Id: I5c0fd35e46b4c0237c266ba6253b9c5cb4cd7995
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237137
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68287}
This includes the instruction opcode, its use in TF, its support in the
simulator and the detection of the associated CPU feature.
The instruction can be tested in the simulator with the new
--sim-arm64-optional-features flag.
Change-Id: I6047fa16696394fe0ced4535f7788d2c8716a18c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2222348
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68261}
1) make it possible to combine tracing logic with accounting allocator
supporting zone compression,
2) make it possible to record zone memory usage via Chrome tracing
machinery (especially, for already running process),
3) trace both allocated and actually used memory per zone,
Bug: v8:10572
Change-Id: I768e474ada1a384218af09efd0dfce2d9a43ac3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228888
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68197}
Introduce --stress-concurrent-allocation flag. With this flag, V8 will
run periodically start an allocation background task, which allocates
objects. Will be used for testing background allocation.
Bug: v8:10315
Change-Id: Iddb7ff34601a492bc2f26f41cc56a2a899807cfa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228889
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68172}
... in order to make it possible to collect zone memory usage stats
from Chrome.
Drive-by-cleanup: move TracingFlags definition to a separate file.
Bug: v8:10572
Change-Id: I05fb65e207d573d5c18821067cfff4c37f2d77cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2226561
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68135}
This change adds more granular control to the behavior that was
previously controlled by the single flag --turbo-profiling. With this
change, it becomes possible to:
- output information only about builtins, ignoring functions compiled at
runtime
- skip the very slow process of writing the schedule and disassembly for
all builtins, if you only want the block counts and don't need verbose
output
This change also moves the output step from Shell::OnExit to
Isolate::DumpAndResetStats so that it's more consistent with other
features and works in hosts other than d8.
Bug: v8:10470, v8:9119
Change-Id: I19b1caca3ff27a2e4a6fdc7ad2f8174f8d678b3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216717
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#68104}
This unifies functionality between release-mode ShortPrint and
debug-mode Print:
- Prefixes and suffixes are now consistent. 'u' for two-byte, '#' for
internalized, 'c' for cons, '>' for thin.
- Logic was simplified and is now based on 3 functions:
PrefixForDebugPrint, PrintUC16, SuffixForDebugPrint.
- %DebugPrint no longer interprets strings as 'code markers'.
- The ancient and unused use_verbose_printer flag was removed.
Bug: v8:10581
Change-Id: Iebc6a746a2683f9f5a8ef60579836e7f66a188fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2224868
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68103}
This reverts commit e1b29ce738.
Reason for revert: The blink_web_tests have been failing for a long time, without turning the bots red. Reverting the revert.
Original change's description:
> Revert "[Promise.any] Re-ship Promise.any"
>
> This reverts commit 560a681f34.
>
> Reason for revert: Suspected cause of Blink web_test failures:
> https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4945
>
> Original change's description:
> > [Promise.any] Re-ship Promise.any
> >
> > The previous attempt failed because it uncovered an unrelated bug
> > (v8:10560). There are no known problems.
> >
> > Bug: v8:9808
> > Change-Id: I360917c45d95ba39c8bea80114ea02bc5e1f83ee
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219936
> > Commit-Queue: Marja Hölttä <marja@chromium.org>
> > Reviewed-by: Shu-yu Guo <syg@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68048}
>
> TBR=marja@chromium.org,syg@chromium.org
>
> Change-Id: I0c60e1c230932a8d06bbdd193e8de792e5f54055
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:9808
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220325
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68055}
TBR=bbudge@chromium.org,marja@chromium.org,syg@chromium.org
# Not skipping CQ checks because this is a reland.
Bug: v8:9808
Change-Id: I9d60a5476ec9b027038e0935fa26265cf5122573
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220330
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68062}
The previous attempt failed because it uncovered an unrelated bug
(v8:10560). There are no known problems.
Bug: v8:9808
Change-Id: I360917c45d95ba39c8bea80114ea02bc5e1f83ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219936
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68048}
Added --trace-wasm flag which prints function entry in wasm.
R=clemensb@chromium.org
Bug: v8:10559
Change-Id: I049efeadb0149f4f58ce34a29fd53fbf5688bd4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215052
Commit-Queue: Arnaud Robin <arobin@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67998}
For single-threaded, we can not tier up in the background. Hence we can
either tier up in foreground (which is pointless), or not tier up.
This CL disables Liftoff, so will compile TurboFan code right away.
R=ahaas@chromium.org
Bug: v8:10530
Change-Id: Icfdc26643ab219d617f844c2ea8e149870168dbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208853
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67894}
We constantly fight against scrambled output with --print-wasm-code and
other flags. Passing --single-threaded only partially mitigates this,
because there could still be multiple isolates (e.g. Workers), and we
sometimes failed to really execute in a single thread if that flag was
set.
Hence this CL solves the problem in a more fundamental way: Whenever a
{StdoutStream} is constructed, it implicitly takes a global recursive
mutex. The recursive mutex is needed because we still have some printing
methods that don't take a stream as parameter, and instead create their
own instance of {StdoutStream}, which should not crash of course.
The overhead of taking a mutex should be acceptable, since output to
stdout mostly happens if special tracing flags have been passed, and is
slow anyway.
This CL ensures that the {StdoutStream} is used at least for
--print-code, --print-wasm-code, and --trace-turbo-graph.
More flags can later be ported on demand.
The {JSHeapBroker} class was modified to not contain a {StdoutStream},
but instead create one on demand.
R=mlippautz@chromium.org, tebbi@chromium.orgCC=ahaas@chromium.org
Bug: v8:10506
Change-Id: Ib9cf8d76aa79553b4215bb7775e6d47a8179aafa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201767
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67855}
This reverts commit 9d3cca1cd3.
Reason for revert: Only the test needs to be skipped on s390. Refer to this: https://crrev.com/c/1981505
Original change's description:
> s390: [arm] Add missing RELATIVE_CODE_TARGET iteration
>
> Port b766299d2c
> Port 9592b043ee
> Port d915b8d668
>
> Original Commit Message:
>
> Code object iteration was missing logic for RELATIVE_CODE_TARGET
> reloc entries. Garbage collection could thus miss objects that were
> referenced only as targets of pc-relative calls or jumps.
>
> RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only
> at mksnapshot-time.
>
> This exposed another issue in that the interpreter entry trampoline
> copy we generate for profiling *did* contain relative calls in
> runtime-accessible code. This is a problem, since code space on arm is,
> by default, too large to be fully addressable through pc-relative
> calls. This CL thus also disables the related
> FLAG_interpreted_frames_native_stack feature on arm.
>
> objects.
>
> R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
> LOG=N
>
> Change-Id: Ifbcaed98d90a2730f0d6a8a7d32c621dab1ff5b2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087693
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
> Cr-Commit-Position: refs/heads/master@{#66644}
TBR=michael_dawson@ca.ibm.com,mlippautz@chromium.org,jyan@ca.ibm.com,jgruber@chromium.org,joransiu@ca.ibm.com,miladfar@ca.ibm.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Id645a9def23d278235ff77f25249d2187e8105ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196521
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67751}
In upcoming work these flags will be used to configure the
experimental native context independent code feature.
Build-time flags:
v8_enable_nci_code
Defines:
V8_ENABLE_NCI_CODE
Runtime flags:
--turbo-nci
--turbo-nci-as-highest_tier
--print-nci-code
--trace-turbo-nci
Drive-by: Remove unused embedded builtins and jitless defines.
Bug: v8:8888
Change-Id: I4466b440634a787bd84b052fe2466b22540216a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184295
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67650}
On the PredictablePlatform, worker tasks were executed immediately
instead of posting them in a task queue first. This approach caused
problems because the execution of the worker task blocked progress of
the posting task, and the worker task was always executed in the
context of the posting task, e.g. with an already open HandleScope.
With this CL, worker tasks get posted into the foreground task queue
of the nullptr isolate instead of executing them immediately.
The tasks of the nullptr isolate are then executed after a task of
some other task queue is executed. As the worker tasks are thereby
executed on the same thread as foreground tasks, the behavior is
deterministic.
A consequence of this approach is that each pumping the message loop
of an Isolate may also execute other Isolate's background tasks.
This approach is needed because we don't have a BackgroundTaskRunner but
merely a CallOnWorkerThread method that doesn't know which Isolate the
task corresponds to.
R=clemensb@chromium.org, mlippautz@chromium.org
Bug: v8:9670
Change-Id: I6847ae042146431bc2376d27280be8829f529b95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182453
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67616}
Allow the DevTools frontend to evaluate variables in a wasm frame context by
reusing the existing Debugger expression evaluation API. Where previously the
API expected JavaScript expressions, which would in general just fail, now the
expression is expected to be base64 encoded Wasm that creates a JSON string in
linear memory.
Bug: chromium:1020120 chromium:1068571
Change-Id: I4b31fdb9d3b21b4e08c4995ec2f07880923959e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087396
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67568}
When a background thread fails to allocate, it requests a GC and
retries the allocation afterwards. Make second allocation more likely
to succeed by allowing those allocations to expand the old space.
TLABs of LocalHeaps also need to be invalidated before the GC.
Bug: v8:10315
Change-Id: Idaea2c4ee25642d508c72ae274b06d60c6e225e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154193
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67496}
The interpreter will be moved to be test-only, hence
--wasm-interpret-all also needs to be removed.
Since we don't have any non-compiling tier any more, we also remove the
implication from --jitless to --wasm-lazy-compilation. Instead, we add
another CHECK that we can't be in jitless mode if we trigger any wasm
compilation.
All tests that just ran other tests and additionally passed
--wasm-interpret-all become redundant and are deleted. Also all
regression tests that explicitly specify --wasm-interpret-all are not
needed any more.
R=thibaudm@chromium.org
Bug: v8:10389
Change-Id: I5ddf20a842117a6c05e277a5308f5cfe42e6bfa5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2164792
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67419}
This changelist makes the GDB-stub actually execute GDB-remote commands, by
accessing the Wasm engine state. More precisely:
- class GdbServer registers DebugDelegates that receive debug notifications when
a new Wasm module is loaded, when execution suspends at a breakpoint or for an
unhandled exception.
- Since the GDB-remote commands arrive on a separate thread, all
queries from the debugger are transformed into Task objects, that are posted
into a TaskRunner that runs in the Isolate thread.
- class WasmModuleDebug contains the logic to retrieve the value of globals, locals, memory ranges from the
Wasm engine and to add/remove breakpoints.
Build with: v8_enable_wasm_gdb_remote_debugging = true
Run with: --wasm-gdb-remote
Test with: python tools\run-tests.py --outdir=out\debug_x64 debugging -j 1
Bug: chromium:1010467
Change-Id: I9703894620a027d3c920926db92e2ff809d84ab8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1941139
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#67412}
Intl.DisplayNames was shipped in m81 and we now can remove the flag.
https://www.chromestatus.com/features/4965112605573120
Bug: v8:8703
Change-Id: Ib65d787c1871aa1da38a22fdb9e369c680c7d2c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163820
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67382}
This is a reland of a441cbfb57
Disabling cctest/test-compiler/DeepEagerCompilationPeakMemory in stress
mode since allocation is no longer deterministic.
Original change's description:
> [offthread] Move stress-background-compile to compiler.cc
>
> Make --stress-background-compile a V8 flag rather than a d8 flag, so
> that it also tests unittests/cctests.
>
> Now, with this flag, every top-level script compile (that fulfills a
> couple of restrictions) will be both main-thread and background-thread
> compiled, taking the result of the background compile. In the future,
> we'll probably want to verify that the two results are equivalent.
>
> One of the necessary changes to allow tests to pass was to introduce a
> concept of a "temporary" script (with a temporary script id), which
> doesn't get added to the script list. This is to avoid the main-thread
> compile part of the stress-test having a debugger-visible side-effect,
> e.g. in tests that enumerate scripts. We can't just create new ids for
> such scripts, as then script-id expectation files no longer match.
>
> Bug: chromium:1011762
> Change-Id: I500bbf2cabea762e69aca3dbae247daae71192cb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120541
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67332}
TBR=rmcilroy@chromium.org
Bug: chromium:1011762
Change-Id: I5f9f0eb71caa4829e72b4a6d2824cbebd3698bd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162876
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67356}
This reverts commit a441cbfb57.
Reason for revert: causes DeepEagerCompilationPeakMemory to fail.
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/36681
Original change's description:
> [offthread] Move stress-background-compile to compiler.cc
>
> Make --stress-background-compile a V8 flag rather than a d8 flag, so
> that it also tests unittests/cctests.
>
> Now, with this flag, every top-level script compile (that fulfills a
> couple of restrictions) will be both main-thread and background-thread
> compiled, taking the result of the background compile. In the future,
> we'll probably want to verify that the two results are equivalent.
>
> One of the necessary changes to allow tests to pass was to introduce a
> concept of a "temporary" script (with a temporary script id), which
> doesn't get added to the script list. This is to avoid the main-thread
> compile part of the stress-test having a debugger-visible side-effect,
> e.g. in tests that enumerate scripts. We can't just create new ids for
> such scripts, as then script-id expectation files no longer match.
>
> Bug: chromium:1011762
> Change-Id: I500bbf2cabea762e69aca3dbae247daae71192cb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120541
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67332}
TBR=rmcilroy@chromium.org,leszeks@chromium.org
Change-Id: I8716b332b07fe4f394b5a32c986bbe652325582d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1011762
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163143
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67347}
