This is a reland of 7f58ced72e
It fixes the different exit size emitted on x64/Atom CPUs due to
performance tuning in TurboAssembler::Call. Additionally, add
cctests to verify the fixed size exits.
Original change's description:
> [deoptimizer] Change deopt entries into builtins
>
> While the overall goal of this commit is to change deoptimization
> entries into builtins, there are multiple related things happening:
>
> - Deoptimization entries, formerly stubs (i.e. Code objects generated
> at runtime, guaranteed to be immovable), have been converted into
> builtins. The major restriction is that we now need to preserve the
> kRootRegister, which was formerly used on most architectures to pass
> the deoptimization id. The solution differs based on platform.
> - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
> - Removed heap/ support for immovable Code generation.
> - Removed the DeserializerData class (no longer needed).
> - arm64: to preserve 4-byte deopt exits, introduced a new optimization
> in which the final jump to the deoptimization entry is generated
> once per Code object, and deopt exits can continue to emit a
> near-call.
> - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
> sizes by 4/8, 5, and 5 bytes, respectively.
>
> On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
> by using the same strategy as on arm64 (recalc deopt id from return
> address). Before:
>
> e300a002 movw r10, <id>
> e59fc024 ldr ip, [pc, <entry offset>]
> e12fff3c blx ip
>
> After:
>
> e59acb35 ldr ip, [r10, <entry offset>]
> e12fff3c blx ip
>
> On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
> with CFI). Additionally, up to 4 builtin jumps are emitted per Code
> object (max 32 bytes added overhead per Code object). Before:
>
> 9401cdae bl <entry offset>
>
> After:
>
> # eager deoptimization entry jump.
> f95b1f50 ldr x16, [x26, <eager entry offset>]
> d61f0200 br x16
> # lazy deoptimization entry jump.
> f95b2b50 ldr x16, [x26, <lazy entry offset>]
> d61f0200 br x16
> # the deopt exit.
> 97fffffc bl <eager deoptimization entry jump offset>
>
> On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
>
> bb00000000 mov ebx,<id>
> e825f5372b call <entry>
>
> After:
>
> e8ea2256ba call <entry>
>
> On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
>
> 49c7c511000000 REX.W movq r13,<id>
> e8ea2f0700 call <entry>
>
> After:
>
> 41ff9560360000 call [r13+<entry offset>]
>
> Bug: v8:8661,v8:8768
> Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70597}
Tbr: ulan@chromium.org, tebbi@chromium.org, rmcilroy@chromium.org
Bug: v8:8661,v8:8768,chromium:1140165
Change-Id: Ibcd5c39c58a70bf2b2ac221aa375fc68d495e144
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485506
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70655}
Gracefully handle hugely nested JSBoundFunctions by checking against
the local isolate's stack limit in relevant recursive functions.
This is based on d734bb4c5d (which was
reverted).
In order to get access to the local isolate, the CL replaces the heap
broker's LocalHeap pointer with a LocalIsolate pointer.
Bug: chromium:1125145
Change-Id: I15d6265c7dfcd8a70af4ab4ce6f30149a886be00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480682
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70654}
Change-Id: Id66d2c57fc92c00b033bc53231313f477cceca75
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448463
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70652}
This is a reland of 8358ab49d8
Original change's description:
> [heap] Introduce new state in CollectionBarrier
>
> Introduce new state kCollectionStarted in CollectionBarrier. This state
> is used during Heap::PerformGarbageCollection. It stops threads from
> requesting GC when the GC was already started. This happens because a
> background thread only requests the GC after it parked itself - the GC
> could be started in-between those two events.
>
> Bug: v8:10315
> Change-Id: I59cf3d4ea41c7a2c37ffce89c5b057221a2499e0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474858
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70572}
Bug: v8:10315
Change-Id: I9da463c847cb0badde58ce767a6e3a24be7672f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480564
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70651}
Eventually this should be used to prevent OS stack overflow
on background threads.
Drive-by change: make more things const.
Bug: v8:10974
Change-Id: Ie659e53992f58c7c08920985d54175d61c5ee796
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474117
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70650}
This reverts commit 7f58ced72e.
Reason for revert: Segfaults on Atom_x64 https://ci.chromium.org/p/v8-internal/builders/ci/v8_linux64_atom_perf/5686?
Original change's description:
> [deoptimizer] Change deopt entries into builtins
>
> While the overall goal of this commit is to change deoptimization
> entries into builtins, there are multiple related things happening:
>
> - Deoptimization entries, formerly stubs (i.e. Code objects generated
> at runtime, guaranteed to be immovable), have been converted into
> builtins. The major restriction is that we now need to preserve the
> kRootRegister, which was formerly used on most architectures to pass
> the deoptimization id. The solution differs based on platform.
> - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
> - Removed heap/ support for immovable Code generation.
> - Removed the DeserializerData class (no longer needed).
> - arm64: to preserve 4-byte deopt exits, introduced a new optimization
> in which the final jump to the deoptimization entry is generated
> once per Code object, and deopt exits can continue to emit a
> near-call.
> - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
> sizes by 4/8, 5, and 5 bytes, respectively.
>
> On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
> by using the same strategy as on arm64 (recalc deopt id from return
> address). Before:
>
> e300a002 movw r10, <id>
> e59fc024 ldr ip, [pc, <entry offset>]
> e12fff3c blx ip
>
> After:
>
> e59acb35 ldr ip, [r10, <entry offset>]
> e12fff3c blx ip
>
> On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
> with CFI). Additionally, up to 4 builtin jumps are emitted per Code
> object (max 32 bytes added overhead per Code object). Before:
>
> 9401cdae bl <entry offset>
>
> After:
>
> # eager deoptimization entry jump.
> f95b1f50 ldr x16, [x26, <eager entry offset>]
> d61f0200 br x16
> # lazy deoptimization entry jump.
> f95b2b50 ldr x16, [x26, <lazy entry offset>]
> d61f0200 br x16
> # the deopt exit.
> 97fffffc bl <eager deoptimization entry jump offset>
>
> On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
>
> bb00000000 mov ebx,<id>
> e825f5372b call <entry>
>
> After:
>
> e8ea2256ba call <entry>
>
> On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
>
> 49c7c511000000 REX.W movq r13,<id>
> e8ea2f0700 call <entry>
>
> After:
>
> 41ff9560360000 call [r13+<entry offset>]
>
> Bug: v8:8661,v8:8768
> Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70597}
TBR=ulan@chromium.org,rmcilroy@chromium.org,jgruber@chromium.org,tebbi@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8661,v8:8768,chromium:1140165
Change-Id: I3df02ab42f6e02233d9f6fb80e8bb18f76870d91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485504
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70649}
With non-super loads (receiver == lookup_start_object), we don't hit
the code in AccessorAssembler::GenericPropertyLoad calling
CSA::TryGetOwnProperty if the receiver (the lookup_start_object) is a
SMI.
But with super property loads, if we set up lookup_start_object the
right way, we will hit this code.
The code was assuming receiver is a HeapObject, which is too
restrictive. The receiver is only used for the accessor call, so
it's ok to make the type more generic.
Bug: v8:9237, chromium:1139786
Change-Id: I3167ccfb54a49ac1c401040a6f02fc1f3b98d9d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484366
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70647}
The logic for ensuring regular publishing in worker threads was broken
by growing the number of queues dynamically
(https://crrev.com/c/2467844). The first task(s) would assume a too
small number of worker threads, thus would publish to late (or never
before running out of units). This creates a large backlog of
to-be-published results when all threads eventually finish execution.
This CL fixes this by updating the per-task limit of results to process
before publishing. The updated value is read atomically using relaxed
memory ordering to ensure minimal impact on performance.
R=thibaudm@chromium.org
Bug: chromium:1138784, v8:11005
Change-Id: I2d00e50148e64db67a6b1a9f219ba60a1f4432ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484365
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70646}
This is a reland of c5379162dc
The reland fixes Code::clear_padding to correctly clear trailing
padding.
Original change's description:
> [code] Move the unwinding info into metadata area
>
> Semantically, the unwinding info is a variable-size metadata table
> with untagged (i.e. no relocation needed) contents, packed inside Code
> objects. This is just like other metadata tables (safepoint table,
> handler table, constant pool, code comments); but for historical
> reasons it's been treated differently so far. Unlike these other
> tables, the unwinding info was located *after* InstructionEnd, and its
> size was written to the first 8 bytes after InstructionEnd.
>
> This CL makes unwinding info handling more consistent with other
> metadata tables by writing its offset into a dedicated
> kUnwindingInfoOffsetOffset header slot, and by moving the actual data
> inside the [InstructionStart,InstructionEnd[ area. In follow-up CLs,
> this area will be split into dedicated instruction- and metadata
> areas.
>
> A picture is worth 1000 words, before:
>
> +--------------------------+ <-- raw_instruction_start()
> | instructions |
> | ... |
> +--------------------------+
> | embedded metadata | <-- safepoint_table_offset()
> | ... | <-- handler_table_offset()
> | | <-- constant_pool_offset()
> | | <-- code_comments_offset()
> | padding to the next |
> | 8-byte aligned address |
> +--------------------------+ <-- raw_instruction_end()
> | [unwinding_info_size] |
> | as uint64_t |
> +--------------------------+ <-- unwinding_info_start()
> | unwinding info |
> | ... |
> +--------------------------+ <-- unwinding_info_end()
>
> After:
>
> +--------------------------+ <-- raw_instruction_start()
> | instructions |
> | ... |
> +--------------------------+
> | embedded metadata | <-- safepoint_table_offset()
> | ... | <-- handler_table_offset()
> | | <-- constant_pool_offset()
> | | <-- code_comments_offset()
> | | <-- unwinding_info_offset()
> | |
> +--------------------------+ <-- raw_instruction_end()
>
> Bug: v8:11036
> Change-Id: I649708821acc5365186ca2c9cff2669fc3e91fd3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484795
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70640}
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
Tbr: leszeks@chromium.org
Bug: v8:11036
Change-Id: I2ea056fe2a53217e0b5ae25661b92f5ddec6fca5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485501
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70645}
This is a reland of 8f7e915839
Original change's description:
> [debugger] Try to trigger pause-on-oom flakes with an extra printf
>
> We have an issue that we can't repro locally. Enable back the
> pause-on-oom tests with an extra printf with DEBUG. We will be able to
> better assess the failures when they appear on the bot.
>
> Bug: v8:10876
> Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70558}
Bug: v8:10876
Change-Id: Ice31c9455830da320ab057293c341f69e1f0c510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484799
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70643}
Switch the current bool* parameter to a structure that contains
the boolean fallback flag and is forward compatible, if we decide
to add more options to the fallback call.
Fly-by refactoring: moved V8_ENABLE_FP_PARAMS_IN_C_LINKAGE out of
a public V8 header file.
Bug: chromium:1052746
Change-Id: I844db24cc687c58b3c3bbd84b4d61bb4759bcfc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474775
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70642}
This reverts commit c5379162dc.
Reason for revert: Seems to cause MSAN failure - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/34931
Original change's description:
> [code] Move the unwinding info into metadata area
>
> Semantically, the unwinding info is a variable-size metadata table
> with untagged (i.e. no relocation needed) contents, packed inside Code
> objects. This is just like other metadata tables (safepoint table,
> handler table, constant pool, code comments); but for historical
> reasons it's been treated differently so far. Unlike these other
> tables, the unwinding info was located *after* InstructionEnd, and its
> size was written to the first 8 bytes after InstructionEnd.
>
> This CL makes unwinding info handling more consistent with other
> metadata tables by writing its offset into a dedicated
> kUnwindingInfoOffsetOffset header slot, and by moving the actual data
> inside the [InstructionStart,InstructionEnd[ area. In follow-up CLs,
> this area will be split into dedicated instruction- and metadata
> areas.
>
> A picture is worth 1000 words, before:
>
> +--------------------------+ <-- raw_instruction_start()
> | instructions |
> | ... |
> +--------------------------+
> | embedded metadata | <-- safepoint_table_offset()
> | ... | <-- handler_table_offset()
> | | <-- constant_pool_offset()
> | | <-- code_comments_offset()
> | padding to the next |
> | 8-byte aligned address |
> +--------------------------+ <-- raw_instruction_end()
> | [unwinding_info_size] |
> | as uint64_t |
> +--------------------------+ <-- unwinding_info_start()
> | unwinding info |
> | ... |
> +--------------------------+ <-- unwinding_info_end()
>
> After:
>
> +--------------------------+ <-- raw_instruction_start()
> | instructions |
> | ... |
> +--------------------------+
> | embedded metadata | <-- safepoint_table_offset()
> | ... | <-- handler_table_offset()
> | | <-- constant_pool_offset()
> | | <-- code_comments_offset()
> | | <-- unwinding_info_offset()
> | |
> +--------------------------+ <-- raw_instruction_end()
>
> Bug: v8:11036
> Change-Id: I649708821acc5365186ca2c9cff2669fc3e91fd3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484795
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70640}
TBR=jgruber@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org
Change-Id: If8417f88f4c55771e455ec85f5efdc6343671ad3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11036
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485500
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70641}
Semantically, the unwinding info is a variable-size metadata table
with untagged (i.e. no relocation needed) contents, packed inside Code
objects. This is just like other metadata tables (safepoint table,
handler table, constant pool, code comments); but for historical
reasons it's been treated differently so far. Unlike these other
tables, the unwinding info was located *after* InstructionEnd, and its
size was written to the first 8 bytes after InstructionEnd.
This CL makes unwinding info handling more consistent with other
metadata tables by writing its offset into a dedicated
kUnwindingInfoOffsetOffset header slot, and by moving the actual data
inside the [InstructionStart,InstructionEnd[ area. In follow-up CLs,
this area will be split into dedicated instruction- and metadata
areas.
A picture is worth 1000 words, before:
+--------------------------+ <-- raw_instruction_start()
| instructions |
| ... |
+--------------------------+
| embedded metadata | <-- safepoint_table_offset()
| ... | <-- handler_table_offset()
| | <-- constant_pool_offset()
| | <-- code_comments_offset()
| padding to the next |
| 8-byte aligned address |
+--------------------------+ <-- raw_instruction_end()
| [unwinding_info_size] |
| as uint64_t |
+--------------------------+ <-- unwinding_info_start()
| unwinding info |
| ... |
+--------------------------+ <-- unwinding_info_end()
After:
+--------------------------+ <-- raw_instruction_start()
| instructions |
| ... |
+--------------------------+
| embedded metadata | <-- safepoint_table_offset()
| ... | <-- handler_table_offset()
| | <-- constant_pool_offset()
| | <-- code_comments_offset()
| | <-- unwinding_info_offset()
| |
+--------------------------+ <-- raw_instruction_end()
Bug: v8:11036
Change-Id: I649708821acc5365186ca2c9cff2669fc3e91fd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484795
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70640}
The one we currently using is now marked as internal and to be removed
for 68. Migrating to the style which already avaiable in ICU 67-1.
Bug: v8:11031
Change-Id: I668382a2e1b8602ddca02bf231c5008a6c92bf2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477751
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70638}
Port 7f58ced72e
Original Commit Message:
While the overall goal of this commit is to change deoptimization
entries into builtins, there are multiple related things happening:
- Deoptimization entries, formerly stubs (i.e. Code objects generated
at runtime, guaranteed to be immovable), have been converted into
builtins. The major restriction is that we now need to preserve the
kRootRegister, which was formerly used on most architectures to pass
the deoptimization id. The solution differs based on platform.
- Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
- Removed heap/ support for immovable Code generation.
- Removed the DeserializerData class (no longer needed).
- arm64: to preserve 4-byte deopt exits, introduced a new optimization
in which the final jump to the deoptimization entry is generated
once per Code object, and deopt exits can continue to emit a
near-call.
- arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
sizes by 4/8, 5, and 5 bytes, respectively.
On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
by using the same strategy as on arm64 (recalc deopt id from return
address). Before:
e300a002 movw r10, <id>
e59fc024 ldr ip, [pc, <entry offset>]
e12fff3c blx ip
After:
e59acb35 ldr ip, [r10, <entry offset>]
e12fff3c blx ip
On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
with CFI). Additionally, up to 4 builtin jumps are emitted per Code
object (max 32 bytes added overhead per Code object). Before:
9401cdae bl <entry offset>
After:
# eager deoptimization entry jump.
f95b1f50 ldr x16, [x26, <eager entry offset>]
d61f0200 br x16
# lazy deoptimization entry jump.
f95b2b50 ldr x16, [x26, <lazy entry offset>]
d61f0200 br x16
# the deopt exit.
97fffffc bl <eager deoptimization entry jump offset>
On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
bb00000000 mov ebx,<id>
e825f5372b call <entry>
After:
e8ea2256ba call <entry>
On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
49c7c511000000 REX.W movq r13,<id>
e8ea2f0700 call <entry>
After:
41ff9560360000 call [r13+<entry offset>]
R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, miladfar@ca.ibm.com
BUG=
LOG=N
Change-Id: I49e4c92759043e46beb3c76c97823285b16feeef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2486225
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70637}
All these opcodes have a simple lowering into a single x64 instruction.
We can perform a similar optimization when AVX is supported to not force
dst == src1.
Bug: v8:10116
Change-Id: I4ad2975b6f241d8209025682202b476c08b3491b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2486383
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70636}
We don't need separate Load32Zero and Load64Zero instructions, since the
implementation is movss and movsd, which we already have.
Bug: v8:10713
Change-Id: I5d02e946f3bf9fe08f943a811f2d3cc8aec81ea8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2486233
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70635}
Prototype these two instructions on ia32. They are movss and movsd
respectively, so the implementation is pretty simple, as we support
these instructions already.
Bug: v8:11038
Change-Id: Iebf4afab2bf1edfb4b14a4855d5036677f999ca9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2486232
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70634}
Not sure why I originally chose to name it LoadMem32Zero instead of
Load32Zero like the proposal. This fixes it.
Bug: v8:10713
Change-Id: If05603f743213bc6b7aea0ce22c80ae4b3023ccf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2481824
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70630}
The feedback vector can be retrieved from the callee's frame, and the
actual_map can be read from the actual_value, so avoid passing these
explicitly to the DynamicMapChecks builtin. This reduces the size of
each DynamicMapCheck codegen by around 20 bytes on x64.
BUG=v8:9684
Change-Id: I31cf9b8cf085284ac051ebafc86f3e26105f3046
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485813
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70629}
For splats, we can make use of vshufps to avoid a movss. Without
AVX, specific dst to be same as src in the instruction selector.
For extract lane, we can use vshufps to extract a float into a dst xmm,
and leave junk in the higher bits.
On the meshopt_decoder.js benchmark in linked bug, it removes about 7
movss instructions that did nothing. Hardware can do register renaming,
but let's not rely on that :)
R=bbudge@chromium.org
Bug: v8:10116
Change-Id: I4d68c10536a79659de673060d537d58113308477
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2481473
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70628}
LoadKind is not longer just for load, we use it for stores as well
(starting with https://crrev.com/c/2473383). Rename it to something more
generic.
Bug: v8:10975,v8:10933
Change-Id: I5e5406ea475e06a83eb2eefe22d4824a99029944
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2481822
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70626}
IsRunning is the v8 equivalent of operator bool, but is confusing
with IsCompleted. IsValid (to match base:: operator bool) should be more
clear.
Change-Id: I2529bea21c7cb7613bd5057c66715fb5ea450396
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461840
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70625}
Also known as multiply long, this multiplies the top or bottom half of
the input operands, the result is twice as wide as the input.
This implements arm64 and interpreter.
Bug: v8:11008
Change-Id: Iad693007066dd1a9bc529b282e88812a081c3a01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469156
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70624}
Fix various missing source positions when reporting parse and compile
errors. Namely this fixes missing source positions when having invalid
module imports.
- Use Isolate::ThrowAt with valid MessageLocation objects
- Change public Isolate::Throw to no longer accept MessageLocation to
avoid misues
- Introduce private Isolate::ThrowInternal that accepts MessageLocation
Bug: v8:6513
Change-Id: I3ee633c9fff8c9d361bddb37f56e28a50c280ec1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467839
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70623}
Parse the AssertEntries in an import assertion clause, storing them in
a map. Plumb them through the parser to the appropriate
SourceTextModuleDescriptor methods.
The next change will plumb them into the SourceTextModuleDescriptor's
ModuleRequestMap and through to SourceTextModuleInfo::New.
Bug: v8:10958
Change-Id: I19c31090520f14f94d014e760f5fe372bf773fc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2482326
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70622}
Since JS arguments are always reversed now
(https://crrev.com/c/2466116), the logic for skipping the arguments
adapter is dead. Hence this CL removes the dead enum value and all code
handling it.
R=victorgomes@chromium.org
Bug: v8:10201
Change-Id: Ie225d14f4ef4e698b76a69cb97fd3eef616e9222
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485074
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70621}
Migrate wrapper compilation from the tasks API to the job API. This
avoids querying the platform for the number of available threads, and
makes the code much more idiomatic.
R=thibaudm@chromium.orgCC=etiennep@chromium.org
Bug: chromium:1101340
Change-Id: I2d84176fe729c065348fd479fe8fd1a0d2f19a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471379
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70620}
Finally blocks that unconditionally result in an abrupt completion
immediately are currently incorrectly returning the existing completion
value instead of undefined.
Bug: v8:10978
Change-Id: Ida2e27d9cc9711236a1fb30368bfc7213d0f7140
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2473382
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70619}
This adds a getter for ordered property dictionaries of maps
Bug: v8:7569
Change-Id: I7e8668ec707734b97f41f1a85c70b00b3b10c981
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465824
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70617}
Replace the "PublishCompilationResults" event by "AddCompiledCode" and
"PublishCode". The former will be parallel, while the latter will not
be. This was a bit misleading before, since in the
"PublishCompilationResults" event we didn't always publish.
R=ahaas@chromium.org
Change-Id: Ia114d6edda77ebf128416af9be998d54bc8aaa12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479470
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70616}
Port 0403beb4bb
Original Commit Message:
This is a reland of cdc8d9a5ec
Skipped tests on gc_stress and fixed CONSTEXPR_DCHECK for gcc.
Original change's description:
> [TurboProp] Avoid marking the output of a call live in its catch handler
>
> The output of a call won't be live if an exception is thrown while the
> call is on the stack and we unwind to a catch handler.
>
> BUG=chromium:1138075,v8:9684
>
> Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70562}
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Ie2d0bc87824afa2555b0dd7021a24e965587ee42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2483629
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70615}
If the main thread (or multiple main threads, or different isolates)
executes compilation units, it uses task id 0. This id will also be used
by the first worker thread. Avoid this by shifting the ids of worker
threads by one.
R=thibaudm@chromium.orgCC=etiennep@chromium.org
Bug: v8:11005
Change-Id: I3beb8a5716112d9466c5b0296ab4ed1f2cf20519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471378
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70613}
The problem was that a raw regexp value was handlified to account for
gc, but then afterwards we used the initial regexp value again instead
of the handle. This resulted in memory violations if the gc decided to
move the regexp object.
Bug: chrome:1139304,v8:10765,v8:11021
Change-Id: Ib1c31ae4a960523c9939619bcca9606dbb507c81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484771
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Cr-Commit-Position: refs/heads/master@{#70605}
This changes OrderedHashMap, OrderedHashSet, and OrderedNameDictionary
as follows:
- Create a dedicated allocation function AllocateEmpty to create zero-
element instances of these classes
- Fix bugs resulting from using these zero-element versions
Further, this CL
- provides a canonical empty versions of OrderedNameDictionary
- changes the types of the canonical ordered hash table and hash set
from FixedArray to the actual subclasses
Bug: v8:7569
Change-Id: I0fe1215e7d164617afa777c8b3208a0857ab6edd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476315
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70604}
Preparing for tail call is usually done by emitting the gap moves and
then moving the stack pointer to its new position. An optimization
consists in moving the stack pointer first and transforming some of the
moves into pushes. In the attached case it looks like this (arm):
138 add sp, sp, #40
13c str r6, [sp, #-4]!
140 str r6, [sp, #-4]!
144 str r6, [sp, #-4]!
148 str r6, [sp, #-4]!
14c str r6, [sp, #-4]!
...
160 vldr d1, [sp - 4*3]
The last line is a gap reload, but because the stack pointer was already
moved, the slot is now below the stack pointer. This is invalid and
triggers this DCHECK:
Fatal error in ../../v8/src/codegen/arm/assembler-arm.cc, line 402
Debug check failed: 0 <= offset (0 vs. -12).
A comment already explains that we skip the optimization if the gap
contains stack moves to prevent this, but the code only checks for
non-FP slots. This is fixed by replacing "source.IsStackSlot()" with
"source.IsAnyStackSlot()":
108 vldr d1, [sp + 4*2]
...
118 str r0, [sp, #+36]
11c str r0, [sp, #+32]
120 str r0, [sp, #+28]
124 str r0, [sp, #+24]
128 str r0, [sp, #+20]
...
134 add sp, sp, #20R=jgruber@chromium.org
Bug: chromium:1137608
Change-Id: If2b85dde49bf31a6bd3f5e0255407f9390727f9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474784
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70603}
This fixes a bug that made a test fail in mjsunit/wasm/return-call.js
(the CFI bot does not run the tests with --variants=extra, hence why
it didn't catch it).
It also introduces --sim-abort-on-bad-auth, a debug flag for the arm64
simulator that stops a program as soon as an authentication error
appears, to make debugging easier.
Change-Id: Ibee731ab788aff45301d268ef05256b82f5e4613
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2473833
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70601}
While the overall goal of this commit is to change deoptimization
entries into builtins, there are multiple related things happening:
- Deoptimization entries, formerly stubs (i.e. Code objects generated
at runtime, guaranteed to be immovable), have been converted into
builtins. The major restriction is that we now need to preserve the
kRootRegister, which was formerly used on most architectures to pass
the deoptimization id. The solution differs based on platform.
- Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
- Removed heap/ support for immovable Code generation.
- Removed the DeserializerData class (no longer needed).
- arm64: to preserve 4-byte deopt exits, introduced a new optimization
in which the final jump to the deoptimization entry is generated
once per Code object, and deopt exits can continue to emit a
near-call.
- arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
sizes by 4/8, 5, and 5 bytes, respectively.
On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
by using the same strategy as on arm64 (recalc deopt id from return
address). Before:
e300a002 movw r10, <id>
e59fc024 ldr ip, [pc, <entry offset>]
e12fff3c blx ip
After:
e59acb35 ldr ip, [r10, <entry offset>]
e12fff3c blx ip
On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
with CFI). Additionally, up to 4 builtin jumps are emitted per Code
object (max 32 bytes added overhead per Code object). Before:
9401cdae bl <entry offset>
After:
# eager deoptimization entry jump.
f95b1f50 ldr x16, [x26, <eager entry offset>]
d61f0200 br x16
# lazy deoptimization entry jump.
f95b2b50 ldr x16, [x26, <lazy entry offset>]
d61f0200 br x16
# the deopt exit.
97fffffc bl <eager deoptimization entry jump offset>
On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
bb00000000 mov ebx,<id>
e825f5372b call <entry>
After:
e8ea2256ba call <entry>
On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
49c7c511000000 REX.W movq r13,<id>
e8ea2f0700 call <entry>
After:
41ff9560360000 call [r13+<entry offset>]
Bug: v8:8661,v8:8768
Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70597}
kDoubleRegZero register is not hardwired to 0.0, we need to check
it's value before using it.
Change-Id: I8a64ac55294f51a9a5f96a39a3b344f7e34d508a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479223
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#70595}
This changes remoteObjectId format from
"{injectedScriptId:123,id:456}" to "<isolateId>.<contextId>.<id>".
Prepending isolateId fixes the problem that
remote object ids clash between processes. This is especially
troubling during cross-process navigation in Chromium, see bug.
We also stop producing and parsing unnecessary json for object ids.
Drive-by: fixed some tests dumping object ids. Most tests avoid
dumping unstable values like ids, but there were few that still did.
BUG=chromium:1137143
Change-Id: Ia019757fb95704ccb718d3ea6cc54bde1a133382
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461731
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70592}
LocalHeap can be used on main thread, however allocation might cause a
GC which works differently on the main thread than on a background
thread. Support collection on main thread by directly performing the GC
instead of requesting the GC as done on background threads.
To allow for differentiation between main and background threads,
LocalHeap/LocalIsolate now require an additional argument.
Change-Id: I08094ea633e303e149913f21dff395da9e046534
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463238
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70590}
Store lane loads a value from memory and replaces a single lane of a
simd value.
This implements store lane for x64 and interpreter.
Bug: v8:10975
Change-Id: Ida79a03e0fd2bc18f2c06687311936b3cb550ed5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2473383
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70586}
Decoding of three-byte opcodes were within the two-byte decoding
function, separate it out, and fix an incorrect comment about us
no having any three-byte opcodes (that is no longer true).
Also un-nest a large if/else out into parent scope.
Test: out/x64.debug/cctest test-disasm-x64/DisasmX64 --random-seed=1
Bug: v8:10933
Change-Id: I494d67ac75cc4500d5f0045f1087b856e6375f82
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477426
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70584}
Implement i32x4.dot_i16x8_s for Liftoff on on ia32 and x64.
ARM implementation will come later.
Bug: v8:10993
Change-Id: I33b859a21b91023b40d8cf7b9fee110b0d148a7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477497
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70583}
With AVX, we don't need to force dst to be the same as first operand,
this can eliminate some moves.
(On the js file in linked bug, we can eliminate all movs before shifts,
saving ~20 movs.)
Bug: v8:10116
Change-Id: I7951b5d8e42995098ddee2a326d0fe6f183c0fb9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477494
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70581}
This reverts commit fba14bde5f.
Reland fixes:
- const vector<const string> -> const vector<string>
Original message:
The following implements a snapshotting algorithm for C++ objects that
also filters strongly-connected components (SCCs) of only "hidden"
objects that are not (transitively) referencing any non-hidden
objects.
C++ objects come in two versions.
a. Named objects that have been assigned a name through NameProvider.
b. Unnamed objects, that are potentially hidden if the build
configuration requires Oilpan to hide such names. Hidden objects have
their name set to NameProvider::kHiddenName.
The main challenge for the algorithm is to avoid blowing up the final
object graph with hidden nodes that do not carry information. For that
reason, the algorithm filters SCCs of only hidden objects, e.g.:
... -> (object) -> (object) -> (hidden) -> (hidden)
In this case the (hidden) objects are filtered from the graph. The
trickiest part is maintaining visibility state for objects referencing
other objects that are currently being processed.
Main algorithm idea (two passes):
1. First pass marks all non-hidden objects and those that transitively
reach non-hidden objects as visible. Details:
- Iterate over all objects.
- If object is non-hidden mark it as visible and also mark parent
as visible if needed.
- If object is hidden, traverse children as DFS to find non-hidden
objects. Post-order process the objects and mark those objects as
visible that have child nodes that are visible themselves.
- Maintain an epoch counter (StateStorage::state_count_) to allow
deferring the visibility decision to other objects in the same
SCC. This is similar to the "lowlink" value in Tarjan's algorithm
for SCC.
- After the first pass it is guaranteed that all deferred
visibility decisions can be resolved.
2. Second pass adds nodes and edges for all visible objects.
- Upon first checking the visibility state of an object, all deferred
visibility states are resolved.
For practical reasons, the recursion is transformed into an iteration.
We do not use plain Tarjan's algorithm to avoid another pass over
all nodes to create SCCs.
Follow ups:
1. Adding wrapper nodes for cpp objects that are wrappables for V8
wrappers.
2. Adding detachedness information.
Bug: chromium:1056170
Change-Id: Ib47df5c912c57d644d052f209276e9d926cece0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480362
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70577}
This reverts commit 8358ab49d8.
Reason for revert: TSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33730
Original change's description:
> [heap] Introduce new state in CollectionBarrier
>
> Introduce new state kCollectionStarted in CollectionBarrier. This state
> is used during Heap::PerformGarbageCollection. It stops threads from
> requesting GC when the GC was already started. This happens because a
> background thread only requests the GC after it parked itself - the GC
> could be started in-between those two events.
>
> Bug: v8:10315
> Change-Id: I59cf3d4ea41c7a2c37ffce89c5b057221a2499e0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474858
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70572}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: Ia67b1cbb931ce1b965876c7a1bbb09f48b8c7b43
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480563
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70576}
Replaces ItemParallelJob by std::vector to hold marking items.
IndexGenerator is used to iterate over evacuation items.
slots_ is moved from items to YoungGenerationMarkingTask to reduce
synchronisation.
Change-Id: Iac7aba215e8ba545c12a9ab6c810d343234fbbbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440830
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70575}
Most code protected by compilation_scope_mutex_ is already either thread
safe, or could run in parallel. Removing lock reduces contention.
Note that weak_ptr::lock is atomic and thus still prevents deletion
of NativeModule&CompilationStateImpl for the scope of
BackgroundCompileScope.
Related changes:
- BackgroundCompileToken is deleted and publish_queue is moved to
CompilationStateImpl.
- Some of the (non thread-safe) logic in publish_results is moved into
PublishCompilationResults so that it is serialized to 1 thread
running publisher.
- cancellation is handled by an atomic bool and is no longer
synchronized. This means that compilation may be cancelled while
a worker thread is still running. That thread would only
stop once it reaches a new BackgroundCompileScope.
Change-Id: I9651e924857c583d1a0fe5b9ffa99bfd01a8bda4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442192
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70574}
This is a reland of cdc8d9a5ec
Skipped tests on gc_stress and fixed CONSTEXPR_DCHECK for gcc.
Original change's description:
> [TurboProp] Avoid marking the output of a call live in its catch handler
>
> The output of a call won't be live if an exception is thrown while the
> call is on the stack and we unwind to a catch handler.
>
> BUG=chromium:1138075,v8:9684
>
> Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70562}
Bug: chromium:1138075
Bug: v8:9684
Change-Id: I685c94ee2ffcf06658df07fcef06f58c4f01f54b
Cq-Include-Trybots: luci.v8.try:v8_linux64_gcc_compile_dbg
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479009
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70573}
Introduce new state kCollectionStarted in CollectionBarrier. This state
is used during Heap::PerformGarbageCollection. It stops threads from
requesting GC when the GC was already started. This happens because a
background thread only requests the GC after it parked itself - the GC
could be started in-between those two events.
Bug: v8:10315
Change-Id: I59cf3d4ea41c7a2c37ffce89c5b057221a2499e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474858
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70572}
This reverts commit 02849fd9de.
Reason for revert: Breaks Win64 MSVC bot and closes the tree - https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/15416
Original change's description:
> cppgc-js: Add snapshot for C++ objects
>
> The following implements a snapshotting algorithm for C++ objects that
> also filters strongly-connected components (SCCs) of only "hidden"
> objects that are not (transitively) referencing any non-hidden
> objects.
>
> C++ objects come in two versions.
> a. Named objects that have been assigned a name through NameProvider.
> b. Unnamed objects, that are potentially hidden if the build
> configuration requires Oilpan to hide such names. Hidden objects have
> their name set to NameProvider::kHiddenName.
>
> The main challenge for the algorithm is to avoid blowing up the final
> object graph with hidden nodes that do not carry information. For that
> reason, the algorithm filters SCCs of only hidden objects, e.g.:
> ... -> (object) -> (object) -> (hidden) -> (hidden)
> In this case the (hidden) objects are filtered from the graph. The
> trickiest part is maintaining visibility state for objects referencing
> other objects that are currently being processed.
>
> Main algorithm idea (two passes):
> 1. First pass marks all non-hidden objects and those that transitively
> reach non-hidden objects as visible. Details:
> - Iterate over all objects.
> - If object is non-hidden mark it as visible and also mark parent
> as visible if needed.
> - If object is hidden, traverse children as DFS to find non-hidden
> objects. Post-order process the objects and mark those objects as
> visible that have child nodes that are visible themselves.
> - Maintain an epoch counter (StateStorage::state_count_) to allow
> deferring the visibility decision to other objects in the same
> SCC. This is similar to the "lowlink" value in Tarjan's algorithm
> for SCC.
> - After the first pass it is guaranteed that all deferred
> visibility decisions can be resolved.
> 2. Second pass adds nodes and edges for all visible objects.
> - Upon first checking the visibility state of an object, all deferred
> visibility states are resolved.
>
> For practical reasons, the recursion is transformed into an iteration.
> We do not use plain Tarjan's algorithm to avoid another pass over
> all nodes to create SCCs.
>
> Follow ups:
> 1. Adding wrapper nodes for cpp objects that are wrappables for V8
> wrappers.
> 2. Adding detachedness information.
>
> Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
> Bug: chromium:1056170
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70567}
TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org
Change-Id: I64a2cf2259bdaed81f6e0f92bdcc7a1f0df4d197
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479471
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70571}
... and add respective regression tests.
This CL also adds similar regression tests for TransitionArray but it
doesn't have the same issue as DescriptorArray.
Bug: chromium:1133527
Change-Id: I668a90f126d76af0a39816ce8697cb29bc65d01b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465833
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70570}
Executable V8 pages include 3 reserved OS pages: one for the writable
header and two as guards. On systems with 64k OS pages, the amount of
allocatable space left for objects can then be quite smaller than the
page size, only 64k for each 256k page.
This means regular code objects cannot be larger than 64k, while the
maximum regular object size is fixed to 128k, half of the page size. As
a result code object never reach this limit and we can end up filling
regular pages with few large code objects.
To fix this, we change the maximum code object size to be runtime value,
set to half of the allocatable space per page. On systems with 64k OS
pages, the limit will be 32k.
Alternatively, we could increase the V8 page size to 512k on Arm64 linux
so we wouldn't waste code space. However, systems with 4k OS pages are
more common, and those with 64k pages tend to have more memory available
so we should be able to live with it.
Bug: v8:10808
Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70569}
This is a reland of ff61743fb0
Original change's description:
> [heap] Refactor marking weak object worklists
>
> This CL extracts weak object worklist related code into separate files
> and uses a macro to specify all weak object worklists in a generic way.
>
> The motivation of the refactoring is twofold:
> 1) We can now enforce that each weak object worklist is updated after
> Scavenge. (Forgetting to define the update function causes a link
> time error.)
> 2) The reduced boilerplate will be useful for transitioning to the
> new ::heap::base::Worklist.
>
> Change-Id: Ic80a7ccca010c09370d6525f43d78de24192f8ea
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442624
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70308}
Change-Id: I8a9f39e53ef4123dd28a1da6f7992cdff341f694
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461741
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70568}
The following implements a snapshotting algorithm for C++ objects that
also filters strongly-connected components (SCCs) of only "hidden"
objects that are not (transitively) referencing any non-hidden
objects.
C++ objects come in two versions.
a. Named objects that have been assigned a name through NameProvider.
b. Unnamed objects, that are potentially hidden if the build
configuration requires Oilpan to hide such names. Hidden objects have
their name set to NameProvider::kHiddenName.
The main challenge for the algorithm is to avoid blowing up the final
object graph with hidden nodes that do not carry information. For that
reason, the algorithm filters SCCs of only hidden objects, e.g.:
... -> (object) -> (object) -> (hidden) -> (hidden)
In this case the (hidden) objects are filtered from the graph. The
trickiest part is maintaining visibility state for objects referencing
other objects that are currently being processed.
Main algorithm idea (two passes):
1. First pass marks all non-hidden objects and those that transitively
reach non-hidden objects as visible. Details:
- Iterate over all objects.
- If object is non-hidden mark it as visible and also mark parent
as visible if needed.
- If object is hidden, traverse children as DFS to find non-hidden
objects. Post-order process the objects and mark those objects as
visible that have child nodes that are visible themselves.
- Maintain an epoch counter (StateStorage::state_count_) to allow
deferring the visibility decision to other objects in the same
SCC. This is similar to the "lowlink" value in Tarjan's algorithm
for SCC.
- After the first pass it is guaranteed that all deferred
visibility decisions can be resolved.
2. Second pass adds nodes and edges for all visible objects.
- Upon first checking the visibility state of an object, all deferred
visibility states are resolved.
For practical reasons, the recursion is transformed into an iteration.
We do not use plain Tarjan's algorithm to avoid another pass over
all nodes to create SCCs.
Follow ups:
1. Adding wrapper nodes for cpp objects that are wrappables for V8
wrappers.
2. Adding detachedness information.
Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70567}
Fuzzers might randomly call OS methods to create or remove
directories. This leads to spurious results when doing differential
fuzzing, but it could be potentially harmful to the system during
normal fuzzing.
This drops OS methods in d8 on fuzzers.
Bug: chromium:1138594
Change-Id: Ia3a8c4e3d06c76ccdc50ead1d361338e13ddf1bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474790
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70566}
This reverts commit cdc8d9a5ec.
Reason for revert: The regression test is too slow:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/30454
Also gcc failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20gcc%20-%20debug/9528
Original change's description:
> [TurboProp] Avoid marking the output of a call live in its catch handler
>
> The output of a call won't be live if an exception is thrown while the
> call is on the stack and we unwind to a catch handler.
>
> BUG=chromium:1138075,v8:9684
>
> Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70562}
TBR=rmcilroy@chromium.org,neis@chromium.org
Change-Id: I0f6b9378d516a70401fc429fb3612bbf962b0fb2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1138075
Bug: v8:9684
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479007
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70564}
The sp register's value should be modified to drop all the args
from the stack.
Change-Id: I7410d325523427d765eb0640e14acede5589284f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479222
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70563}
The output of a call won't be live if an exception is thrown while the
call is on the stack and we unwind to a catch handler.
BUG=chromium:1138075,v8:9684
Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70562}
This is a reland of 44708a5b6f
Original change's description:
> [compiler, heap] Create LocalHeap outside of ExecuteJob
>
> Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
> pass its reference as argument to ExecuteJob. This allows us to create
> LocalHeap differently for the main and background thread, e.g. by
> passing an additional argument to the constructor in the future.
> It will be required in the future anyways when the main thread will
> have its own LocalHeap/LocalIsolate.
>
> Extending the scope of LocalHeap, also made
> HandleBase::IsDereferenceAllowed more precise and uncovered two
> potential issues: heap accesses in
> OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
> with --code-comments.
>
> LocalHeap can now be created in the parked state. Also fixed a data
> race with LocalHeap's destructor publishing write barrier entries
> without holding the lock.
>
> Bug: v8:10315
> Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70521}
Bug: v8:10315
Change-Id: I4c459fd6dfb98d47fc9941c0dc6864bf5a1d2d3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474788
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70560}
This reverts commit 8f7e915839.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20node.js%20integration%20ng/10707?
Original change's description:
> [debugger] Try to trigger pause-on-oom flakes with an extra printf
>
> We have an issue that we can't repro locally. Enable back the
> pause-on-oom tests with an extra printf with DEBUG. We will be able to
> better assess the failures when they appear on the bot.
>
> Bug: v8:10876
> Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70558}
TBR=rmcilroy@chromium.org,petermarshall@chromium.org,solanes@chromium.org
Change-Id: I1b8a146d9496e889957636456b383f8d496658dc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10876
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479004
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70559}
We have an issue that we can't repro locally. Enable back the
pause-on-oom tests with an extra printf with DEBUG. We will be able to
better assess the failures when they appear on the bot.
Bug: v8:10876
Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70558}
The UMA sampling profiler prefers unique symbol addresses, otherwise
disambiguation is fairly arbitrary (lexicographic).
To this end, introduce a dedicated symbol v8_code_start_for_profiler_
at a unique address (i.e. no other symbol is located at this address).
Bug: v8:6666
Change-Id: Iec13ccac64efc7ac3f63e29632ee8f6300bcb76b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464926
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70556}
This is merged into the proposal, move it out of post-mvp flags, and
remove any ifdefs guarding it.
Bug: v8:10993
Change-Id: I4c82e3fc17c97735d5417fa4a5d85d7f091fbb8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2453457
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70552}
read_prefixed_byte is used mostly to read an entire prefixed opcode, it
writes the number of bytes of the opcode index (without prefix byte) to
the out param length. Change it so it writes the total number of bytes
(including the prefix byte), as that is what most callers want (they add
1 after calling read_prefixed_byte).
Bug: v8:10810
Change-Id: I914190ecae62e3547652accdc05d1cef3686fff4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476678
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70551}
Rename AddSaturate and SubSaturate to the shorter version, AddSat and
SubSat, following the spec.
Bug: v8:10946,v8:10933
Change-Id: Idf74b3a1eb2e2f6d4e37d2b8e5fa6d96ea090db4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436615
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70549}
This is the first change in the process of implementing import
assertions per https://tc39.es/proposal-import-assertions/.
This CR adds support for the empty form of the AssertClause.
Also added is a --harmony-import-assertions flag to enable/disable
import assertions. For now, the feature is off by default.
The next change will enable the parser to handle a non-empty list
of AssertEntries.
Bug: v8:10958
Change-Id: I0832d89effc27225aa4430605a51690461daf7ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2468623
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70545}
Prefixed opcodes have a 1 byte prefix, followed by LEB-encoded u32. This
changes all prefixed opcodes (gc, numeric, atomic), to that. (Simd was
already so.)
We can clean up read_prefix_opcode to return the total number of bytes,
1 byte prefix + leb encoded, that will be in a future patch.
Bug: v8:10810,v8:10994
Change-Id: Ia74604acc059c1336b87e9f477598732de219ca9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465057
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70544}
Instead of decoding in each branch, move the decoding up in scope, since
all branches do the same decoding.
Bug: v8:10933
Change-Id: I99ef03e4271cc111428f9a243f61b26af6f85780
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2472758
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70542}
- Shortcut return when argc < param_count
- Simplify return code due to PopAndReturn invariant
Change-Id: Ie41d559cdbe0ba2cc4fdbfbbb622b0aec8429f03
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474777
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70541}
In certain situations a phi might not be used by later code, and so
is neither spilled nor has a register allocated to it. Handle this
by removing the incorrect DCHECK.
BUG=chromium:1137979,v8:9684
Change-Id: I702dc05dba22e23dac5c1a366a770f18bac45c52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471998
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70536}
When merging blocks in the mid-tier register allocator, try to avoid
spilling registers if we can instead introduce a gap move to move the
register choosen to hold a virtual register to the register that is
holding that virtual register in the successor block. This gives
around 1.5% speedup on Octane.
BUG=v8:9684
Change-Id: I352d1e0e2c3b89ab6bd203d76339b93ef474028f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466117
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70534}
