When --shared-string-table is passed, in-place-internalizable strings
are promoted into the shared old space to maintain the invariant that
in-place internalization can be done without copying.
Also some drive-by comment fixes and removal of unnecessary 'explicit'
on multi-parameter constructors.
Bug: v8:12007
Change-Id: I467d865e41934b1d5cdf85cbecc85c4befbfeb21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193591
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77326}
Was a clang bug that has since been fixed, https://crbug.com/1163847.
Fixed: v8:11134
Change-Id: Idf2c4bcd8f07024e64e38289793e3af74f43e98c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3212808
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77324}
Compiling Sparkplug on the heap saved 10% of the CompileBaseline
RCS metric, but that came with too much code complexity.
Since in the end that corresponds to < 1% of the entire compilation
time, we decided to revert this project.
This reverts:
commit e29b2ae48a
commit d1f2a83b7d
commit 4666e18206
commit a1147408e4
commit e0d4254f97
commit 9ab8422da7
commit a3b24ecc51
commit 1eb8770691
commit fe5c9dfd90
commit 7ac3b55a20
commit 7e95f30ec9
commit 323b596212
commit 6bf0b70490
commit e82b368b67
commit 5020d83e05
commit 642a467338
commit ec7b99d5c6
commit fb4f89aede
commit 208854bb14
commit 63be6dde31
Bug: v8:12158
Change-Id: I9f2539be6c7d80c6e243c9ab173e3c5bb0dff97d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3136453
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77319}
This CL adds a new snapshot to hold objects that are in the shared heap
or may need to be in the shared heap depending on runtime flags.
Currently this is to support --shared-string-table, which puts all
in-place-internalizable strings, internalized strings, and the
string table into the shared heap.
The shared heap snapshot is never deserialized into client Isolates.
This means when V8 is started without a shared Isolate, the shared heap
snapshot is deserialized into all Isolates.
Bug: v8:12007
Change-Id: I7eeab73080cda2e8250a5a49747f25b2440a349d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173905
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77309}
To prepare for prototyping shared memory features, all internalized and
in-place internalizable (1- and 2-byte seq strings and external strings)
will always be allocated in the shared old space.
Cons strings, thin strings, and sliced strings remain allocated in the
thread-local space. They are copied over to the shared space when
internalized, as internalization implies flattening, which for these
strings requires a copy already.
To make the in-place internalization threadsafe, updating the map of
such strings is now done with a release store.
This CL does not yet support external strings.
Bug: v8:12007
Change-Id: I982c35c5120bf4c0c70c5294ce011b47430414c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140784
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77308}
This CL reorders the initialization scheme for shared and client
Isolates such that clients attach to the shared Isolate before
setting up the Heap. This is to support sharing the string table.
Bug: v8:12007
Change-Id: Icb0e40cc5ed84d516c8073a70d0f769f517044c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3039264
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77307}
This is a reland of 0adc1410b1
1. Fork out test/mjsunit/temporal/function-exist.js test
to test/mjsunit/temporal/function-exist-no-i18n.js and mark
function-exist FAIL in no_i18n build.
Original change's description:
> [Temporal] Part 1 - Skeleton
>
> 1. Expose all the functions to empty buildins.
> 2. Wire up basic structure of classes and internal slots.
>
> Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/
>
> This is just a CL to establish a skeleton for Temporal.
> The Temporal is very big. The prototype CL is in
> https://chromium-review.googlesource.com/c/v8/v8/+/2967755
> but too big to be reviewed so I break up the basic structure here first.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel
> Bug: v8:11544
> Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76819}
Bug: v8:11544
Change-Id: I60eaface94ba9b3408cb235cd1ae425151a36732
Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160324
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77303}
For debugging purposes, we print the validation error if the module
generated by WasmCompileFuzzer fails to validate.
Change-Id: I79d2827e489194d02150484ab5a196e979a302af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211574
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77295}
This is a reland of a1e6efd80c
Fix Android issue by checking the resources is not filtering out.
Original change's description:
> [intl] Fix consistency in Intl API
>
> Fix several edge cases consistency issues with ICU discovered by test262 test by
> using Intl Enumeration API
> 1. Work around ICU short coming of always fallback in currency display
> name so when the fallback is "none" in DisplayNames, the force fallback
> code will produce the correct undefined from the of(currency_code) method.
> 2. Always check numbering system is not algorithm based numbering system
> to fix DateTimeFormat/RelativeTimeFormat/NumberFormat
> resolvedOptions().numberingSystem when the reqested numberingSystem is one
> of the numbering systems that we filter out the resources and not supported.
> 3. Generalize the iso8601 bit solution in DateTimeFormat and rename it to
> alt_calendar bit to also fix DateTimeFormat resolvedOptions report
> calendar as "islamic" while requesting "islamic-rgsa".
> 4. Work around reporting inconsistency of currency code and display name
> in ICU.
>
> Bug: v8:12209
> Change-Id: Ibd349ee55426fad7d6f20a5e93fb35ff7438e111
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3153576
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77242}
Bug: v8:12209
Change-Id: I96e1ba33e97f6a4abbe20e23a8fdff6cdf8bc131
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3207380
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77290}
Add support for the i8 and i16 packed types.
Because i8 and i16 do not exist as value types
we need an i32 to instantiate a packed field.
Bug: v8:11954
Change-Id: Ib311fee537c4c9e4aed0ac366172b9b5fb1ee88e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3210267
Commit-Queue: Maria Tîmbur <mtimbur@google.com>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77288}
This patch adds infrastructure for collecting feedback about call_ref
call targets in Liftoff code, and using that feedback for turning
such calls into inlineable direct calls when building Turbofan graphs.
The feature is considered experimental quality and hence off by default,
--wasm-speculative-inlining turns it on.
Bug: v8:7748
Change-Id: I0d0d776f8a71c3dd2c9124d3731f3cb06d4f5821
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3205902
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77287}
Currently, when compiling with V8_VIRTUAL_MEMORY_CAGE enabled, the
behavior of the BoundedPageAllocator changes from simply making freed
pages inaccessible to decommitting them, which guarantees that they will
be zero-initialized after the next allocation. As this seems to cause
some performance regressions on Mac, this CL introduces a new enum that
specifies how the allocator should behave:
kAllocatedPagesMustBeZeroInitialized causes the pages to be decommitted
during FreePages() and ReleasePages() and thus guarantees
zero-initialization during AllocPages().
kAllocatedPagesCanBeUninitialized only causes the pages to be made
inaccessible, and so does not generally guarantee zero-initialization
for AllocPages().
Finally, this CL also removes some dead code in allocation.cc.
Bug: chromium:1257089
Change-Id: I53fa52c8913df869bee2b536efe252780d1ad893
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208812
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77285}
Certain collators and subject strings may take this new fast
path without calling into the (slow) ICU comparison functions.
This CL can be roughly split into three topics:
1. The fast path check, precomputed and implemented as a whitelist
on the current locale string.
2. The actual fast path, which checks subject string eligibility
and performs L1 and L3 collation weight comparisons all in one pass.
3. Resuming from an aborted fast-path into the generic path.
A longer overview is available at
https://docs.google.com/document/d/1oyDwjYn2JyHsx2YnJJKhjX0WMNQXb8ao86-DRzqiYNg/edit?usp=sharing
JetStream2/cdjs scores improve by roughly 40%.
Bug: v8:12196
Change-Id: I5e1bbd731a36c361af9667f9104d6fa15c42e117
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3149463
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77284}
Liftoff is temporarily disabled on PPC.
After https://crrev.com/c/3202593 the newly skipped tests
are failing with this error:
```
Check failed: tester.native_module()->GetCode(0)->is_liftoff()
```
Change-Id: I681a27930909fd6ac4e5087c2d03608b891a6066
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208070
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77265}
This is a reland of 16df1dfa13
No changes have been made to this reland as previous commit was reverted
due to a new test revealing an existing bug. This bug has now been fixed.
Original change's description:
> [arm64][wasm-simd] Use Cm(0) for integer comparison with 0
>
> Use an immediate zero operand for integer comparison when possible. This
> gives ~1% runtime performance improvement in some benchmarks on Neoverse
> N1.
>
> Change-Id: I727a8104f8e6ca3d122d6b5b8b3d38d7bdd76c47
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3158327
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
> Cr-Commit-Position: refs/heads/main@{#76847}
Change-Id: I77d6923d79407a83becbd39970c6a3f62d3a304d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178482
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
Cr-Commit-Position: refs/heads/main@{#77260}
WebAssembly dynamic tiering should be tested with an origin trial. For
the origin trial the feature flag value has to be loaded from blink.
This CL stores the value of the --wasm-dynamic-tiering flag in the
compilation state, from where it gets passed forward to all uses of the
flag. The flag value gets loaded from blink when a new NativeModule is
created.
R=clemensb@chromium.org
Bug: v8:12281
Change-Id: Ia26355a665b7dfcdb47144863c1bec296774abb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3204963
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77256}
The expected assertion is specific to irregexp codegen.
Bug: chromium:1255368
Change-Id: I14d033285014727de2e63582ed798fc82570497d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3207892
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77254}
With dynamic tiering, typically not all functions of a WebAssembly
module get compiled with TurboFan, and therefore the code caching would
never get triggered. With this CL code caching is triggered whenever
{FLAG_wasm_caching_threshold} bytes of TurboFan code are generated.
This new caching event is only triggered when --wasm-dynamic-tiering is
enabled.
R=clemensb@chromium.org
Bug: v8:12281
Change-Id: I939325aea7e4310aa76c936636799661c05d4079
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3202593
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77251}
When aborting code generation, we need to call {AbortedCodeGeneration}
on the {MacroAssembler} contained in the {RegExpMacroAssemblerARM}.
R=jgruber@chromium.org
Bug: chromium:1255368
Change-Id: If37351e8f5715e23affd21ad2de8a8eaad3ea094
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3204965
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77250}
Allocate code range close to binary (<2GB) when pointer compression is
disabled. And enable short builtin calls if it succeeds.
Bug: v8:12045, v8:11527
Change-Id: I1a9d635b243337980fd75883d9802bc0cee75e43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069457
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77248}
This reverts commit a1e6efd80c.
Reason for revert: Break Arm64
Original change's description:
> [intl] Fix consistency in Intl API
>
> Fix several edge cases consistency issues with ICU discovered by test262 test by
> using Intl Enumeration API
> 1. Work around ICU short coming of always fallback in currency display
> name so when the fallback is "none" in DisplayNames, the force fallback
> code will produce the correct undefined from the of(currency_code) method.
> 2. Always check numbering system is not algorithm based numbering system
> to fix DateTimeFormat/RelativeTimeFormat/NumberFormat
> resolvedOptions().numberingSystem when the reqested numberingSystem is one
> of the numbering systems that we filter out the resources and not supported.
> 3. Generalize the iso8601 bit solution in DateTimeFormat and rename it to
> alt_calendar bit to also fix DateTimeFormat resolvedOptions report
> calendar as "islamic" while requesting "islamic-rgsa".
> 4. Work around reporting inconsistency of currency code and display name
> in ICU.
>
> Bug: v8:12209
> Change-Id: Ibd349ee55426fad7d6f20a5e93fb35ff7438e111
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3153576
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77242}
Bug: v8:12209
Change-Id: I6b8ac7dc89eda158e29c9d653825cb20a89341aa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3207379
Reviewed-by: Frank Tang <ftang@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77246}
IsActive is misleading as the current implementation forces to use
v8::Locker for all Isolate access once any Locker has been used in
the same process.
Bug: chromium:1240851
Change-Id: Ieb2cfa352313b6f2cbec1bafdbc94a3fc718f3d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190093
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77243}
Fix several edge cases consistency issues with ICU discovered by test262 test by
using Intl Enumeration API
1. Work around ICU short coming of always fallback in currency display
name so when the fallback is "none" in DisplayNames, the force fallback
code will produce the correct undefined from the of(currency_code) method.
2. Always check numbering system is not algorithm based numbering system
to fix DateTimeFormat/RelativeTimeFormat/NumberFormat
resolvedOptions().numberingSystem when the reqested numberingSystem is one
of the numbering systems that we filter out the resources and not supported.
3. Generalize the iso8601 bit solution in DateTimeFormat and rename it to
alt_calendar bit to also fix DateTimeFormat resolvedOptions report
calendar as "islamic" while requesting "islamic-rgsa".
4. Work around reporting inconsistency of currency code and display name
in ICU.
Bug: v8:12209
Change-Id: Ibd349ee55426fad7d6f20a5e93fb35ff7438e111
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3153576
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77242}
A mov can be up to 10 bytes, 6 for displacement, 4 for instr. Other
instructions (like pshufb) with a complex addressing mode can take 10
bytes too. So adjust the padding for disassembly of hex accordingly.
This requires fixing up all the test cases too.
Bug: v8:12207
Change-Id: I372d67a818a5dbfe6f49f67047493d7f67b59bcd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3180375
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77241}
The error showed when printing the resulting code object, because the
tier was neither TurboFan nor Liftoff, even though the code was
registered as a standard wasm function (instead of an import wrapper).
R=jkummerow@chromium.org
Bug: chromium:1254674
Change-Id: I26482fd88d72403393428979abf08e9f60cd8c4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3202001
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77238}
This reenables a test which is passing, independent of missing
accounting for shared memory. This is because we repeatedly trigger a GC
explicitly in all workers.
R=dinfuehr@chromium.org
Bug: v8:12278
Change-Id: I73d1513d809787284af0be4956018806719acd50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3201995
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77219}
Trying to optimize in such case breaks down the optimization, as we
end up with potentially non-eliminatable nodes that depend on the dead
IfTrue/IfFalse node.
Drive-by: Clean up dead nodes with {Kill()}.
Bug: v8:11510, chromium:1255354
Change-Id: Ia89fe6c243974c3c2abac6ad80bd4677a935f637
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3200073
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77211}
The checks for assignemnts to member during prefinalizers assumed the
slot has to live. It was assumed that if a slot is dead then we would
not be updating it.
Prefinalizers are allowed to touch dead objects and thus are techincally
allowed to write to dead slots. Such writes are usually redundant (the
object will be swept soon anyway) but are not always easy to get rid of.
Bug: chromium:1255152, v8:11749
Change-Id: I57e143abd53d434c3198616909c506eb70d8944b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199800
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77208}
When scanning for capture groups, we have to consider the case that the
current state is inside a character class. In that case skip everything
until the end of the current character class. Otherwise we would wrongly
count open brackets inside the character class as start of a capture
group.
Bug: chromium:1254704
Change-Id: I91d2177c464f7e507413d96216fe570253f17676
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199871
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77204}
If processing the marking worklists found new ephemeron pairs, but
processing the existing ephemeron pairs didn't mark new objects, marking
would stop and the newly discovered ephemeron pairs would not be
processed. This can lead to a marked key with an unmarked value.
Bug: chromium:1252878
Change-Id: I0f158f6f64490f1f06961520b4ba57fa204bd867
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199872
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77197}
When we generate identical signatures in the fuzzer,
we generate one function for each of the copies.
However, when these functions are added to WasmModulBuilder,
all will be assigned the same signature index.
Therefore, when ref.func tries to find a function corresponding
to a signature index, it will fail, despite a matching signature
existing in the module.
This CL fixes this issue by looking up functions by signature
over signature index.
Bug: v8:11954, chromium:1254387
Change-Id: Iac8d5444d4914d993da63d0630ca4d95e671630c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197711
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Maria Tîmbur <mtimbur@google.com>
Cr-Commit-Position: refs/heads/main@{#77187}
The logic to locate the correct function to set a breakpoint in based
on script position was treating SharedFunctionInfo::EndPosition() as
inclusive rather than exclusive. There are various assumptions all over
the Debugger that seem to demand this treatment for the toplevel script.
But it's definitely wrong for function literals.
Fixed: chromium:1253277
Change-Id: I3421703673f4d78aee28e923e03e2fca24bc06ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197715
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77186}
Previously we'd treat %_AsyncFunctionReject (and %AsyncFunctionReject)
as side-effect free (in async functions), but that's not correct, since
promise rejections have side-effects (at the very least triggering the
unhandled promise rejection machinery in the browser).
This required a minor refactoring as previously we'd classify functions
as side-effecting or not depending on whether they contain any calls to
side-effecting intrinsics, no matter whether this call is actually
executed or not. That would break REPL mode however if we'd generally
treat all async functions with %_AsyncFunctionReject intrinsic calls as
side-effecting, so instead of performing the intrinsic checks ahead of
time, we now perform the test at execution time.
Before: https://imgur.com/5BvJP9d.png
After: https://imgur.com/10FanNr.png
Fixed: chromium:1249275
Change-Id: Ib06f945ba21f1e06ee9b13a1363fad342464fd9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197712
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77183}
We implement two optimizations for trap conditionals for patterns that
come up in wasm-gc.
In case of a Merge followed by a trap, where the path conditions of all
branches of the Merge contain the trap condition, we lift the trap into
the branches of the Merge.
In case of a Branch whose IfTrue branch is followed by a TrapIf with the
same condition, we replace it with the trap followed by the IfFalse
branch. Symmetrically for IfFalse and TrapUnless.
Bug: v8:7748
Change-Id: I43040aebe60eab7b2230fc3130e3b8250e8b2f45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190109
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77181}
