With https://crrev.com/c/4166369 the default names changed from
e.g. libv8.so to lib_v8.so.
This causes at least some issues on build bots but might also
impact other projects assuming certain names in case of component
builds.
The default naming can be prevented by providing an explicit
{output_name} on each component.
No-Tree-Checks: true
Change-Id: I501c3f6c530e6d3896e2303ee75a0c4a4d07dfca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194732
Reviewed-by: Lutz Vahl <vahl@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85483}
Rolling v8/build: 3ed59a9..1015724
Rolling v8/buildtools: 0cc02fb..3c7e3f1
Rolling v8/buildtools/third_party/libc++/trunk: 1dfd002..1127c78
Rolling v8/buildtools/third_party/libunwind/trunk: bb5988e..e95b94b
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/45986b0..6cfc140
Rolling v8/third_party/depot_tools: 00be3f0..44e9bee
Rolling v8/third_party/fuchsia-sdk/sdk: version:11.20230124.2.1..version:11.20230125.2.1
Rolling v8/tools/clang: 41fd15a..566877f
Rolling v8/tools/luci-go: git_revision:81e5cdad29bb4c7aaad98c843637513db3155b0d..git_revision:221383f749a2c5b8587449d3d2e4982857daa9e7
Rolling v8/tools/luci-go: git_revision:81e5cdad29bb4c7aaad98c843637513db3155b0d..git_revision:221383f749a2c5b8587449d3d2e4982857daa9e7
Change-Id: If5bd9268220db8d5f49b57cd641a21c2bf2fe398
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4196414
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#85480}
This reverts commit 20a954f4bc.
Reason for revert: Alas, GC stress failures:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/45646/overview
Original change's description:
> [heap][test] Fix weakrefs tests for conservative stack scanning
>
> 31 out of the 36 JS tests in test/mjsunit/harmony/weakrefs/ rely on
> precise GC with the following general pattern: they allocate some
> objects, clear all references to them, invoke a GC, then perform
> some test that assumes that the GC has reclaimed the objects.
> When conservative stack scanning is used, this may fail.
>
> This CL fixes the tests, ensuring that a precise GC will be invoked
> when necessary, without scanning the stack. To achieve this, the GC
> has to be invoked in asynchronous execution mode, which ensures that
> it will be invoked from the event loop without a stack. In some
> cases, this change requires a non-trivial change in the tests.
>
> In 5 tests, part of the test's objective was to verify that a weak
> reference is not cleared before the end of the turn. In those, it
> was not possible to invoke GC asynchronously, as this would
> immediately start a new turn. These tests still use synchronous GC
> and they have been modified, if necessary, to allow for CSS (i.e.,
> to not test that all possible garbage is reclaimed after a
> sequential GC). Because of CSS, these tests may not always test
> everything that they were intended to.
>
> Tests with trivial fix:
>
> - cleanup-from-different-realm
> - cleanup
> - cleanup-proxy-from-different-realm
> - cleanupsome-2
> - cleanupsome-after-unregister
> - cleanupsome
> - finalizationregistry-keeps-holdings-alive
> - multiple-dirty-finalization-groups
> - stress-finalizationregistry-dirty-enqueue
> - undefined-holdings
> - unregister-after-cleanup
> - unregister-before-cleanup
> - unregister-called-twice
> - unregister-inside-cleanup2
> - unregister-inside-cleanup3
> - unregister-inside-cleanup
> - unregister-many
> - unregister-when-cleanup-already-scheduled
> - weak-cell-basics
>
> Tests with non-trivial fixes; same logic but very restructured:
>
> - cleanup-is-not-a-microtask:
> - cleanup-on-detached-realm
> - finalizationregistry-scheduled-for-cleanup-multiple-times
> - finalizationregistry-independent-lifetime
> - finalizationregistry-independent-lifetime-multiple
> - reentrant-gc-from-cleanup
> - symbol-in-finalizationregistry
> (was 2nd part of former symbol-as-weakref-target-gc)
> - weak-unregistertoken
>
> Tests with non-trivial fixes; same logic, restructured, using
> synchronous GC:
>
> - finalizationregistry-and-weakref
> - symbol-as-weakref-target-gc
> (was 1st part of former symbol-as-weakref-target-gc)
> - two-weakrefs
> - weakref-creation-keeps-alive
> - weakref-deref-keeps-alive
>
> Bug: v8:13257
> Bug: v8:13662
> Change-Id: I53586bd16cdb98fa976e1fa798ef498bdf286238
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191774
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85477}
Bug: v8:13257
Bug: v8:13662
Change-Id: Icc7a907928ccac058f8acdf320c21b2df04c1b78
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4192256
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#85479}
This CL allows GetPredecessorIndex gracefully fail when an indirect
predecessor of the current block is passed as an argument.
Bug: chromium:1408354
Change-Id: I5eaab6c6905839e5833faea5c4b0540e4a63699b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191773
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85478}
31 out of the 36 JS tests in test/mjsunit/harmony/weakrefs/ rely on
precise GC with the following general pattern: they allocate some
objects, clear all references to them, invoke a GC, then perform
some test that assumes that the GC has reclaimed the objects.
When conservative stack scanning is used, this may fail.
This CL fixes the tests, ensuring that a precise GC will be invoked
when necessary, without scanning the stack. To achieve this, the GC
has to be invoked in asynchronous execution mode, which ensures that
it will be invoked from the event loop without a stack. In some
cases, this change requires a non-trivial change in the tests.
In 5 tests, part of the test's objective was to verify that a weak
reference is not cleared before the end of the turn. In those, it
was not possible to invoke GC asynchronously, as this would
immediately start a new turn. These tests still use synchronous GC
and they have been modified, if necessary, to allow for CSS (i.e.,
to not test that all possible garbage is reclaimed after a
sequential GC). Because of CSS, these tests may not always test
everything that they were intended to.
Tests with trivial fix:
- cleanup-from-different-realm
- cleanup
- cleanup-proxy-from-different-realm
- cleanupsome-2
- cleanupsome-after-unregister
- cleanupsome
- finalizationregistry-keeps-holdings-alive
- multiple-dirty-finalization-groups
- stress-finalizationregistry-dirty-enqueue
- undefined-holdings
- unregister-after-cleanup
- unregister-before-cleanup
- unregister-called-twice
- unregister-inside-cleanup2
- unregister-inside-cleanup3
- unregister-inside-cleanup
- unregister-many
- unregister-when-cleanup-already-scheduled
- weak-cell-basics
Tests with non-trivial fixes; same logic but very restructured:
- cleanup-is-not-a-microtask:
- cleanup-on-detached-realm
- finalizationregistry-scheduled-for-cleanup-multiple-times
- finalizationregistry-independent-lifetime
- finalizationregistry-independent-lifetime-multiple
- reentrant-gc-from-cleanup
- symbol-in-finalizationregistry
(was 2nd part of former symbol-as-weakref-target-gc)
- weak-unregistertoken
Tests with non-trivial fixes; same logic, restructured, using
synchronous GC:
- finalizationregistry-and-weakref
- symbol-as-weakref-target-gc
(was 1st part of former symbol-as-weakref-target-gc)
- two-weakrefs
- weakref-creation-keeps-alive
- weakref-deref-keeps-alive
Bug: v8:13257
Bug: v8:13662
Change-Id: I53586bd16cdb98fa976e1fa798ef498bdf286238
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191774
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85477}
Avoid inlining if the function has exception handlers and/or
depends on incoming new target.
Bug: v8:7700
Change-Id: I25a19c6da94f333d0d57bcdb33392ee497c59e63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194199
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85476}
InitialValue points to the value in the stack relative to the frame.
In other words, the context and the closure of the inlined
function were incorrectly pointed to the parent one.
Bug: v8:7700
Change-Id: I740112168865b2eadadbb7eb0bdd63eba3e45bbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194198
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85475}
The invariants in this method are fairly strict since it is called
during object evacution and thus a) objects may be in transitory states
and b) multiple threads are working on evacuation objects concurrently.
Previously, this method ensured valid object accesses because only the
object currently being observed by ProfilingMigrationObserver was
accessed. This changed with crrev.com/c/4178821, where we (incorrectly)
also accessed another object (InstructionStream::code), leading to data
races and incorrect behavior.
This CL fixes that problem by changing LogEventListener API as follows:
void CodeMoveEvent(InstructionStream from, InstructionStream to);
void BytecodeMoveEvent(BytecodeArray from, BytecodeArray to);
With this change we again correctly observe invariants, and also remove
one use of AbstractCode.
Bug: v8:13654
Change-Id: Ida022e8c7f14d821e1139f025edc71c20fa386c0
Fixed: chromium:1409786
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194192
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85474}
This updates the file exceptions for js-fuzzer following the procedure
described at js_fuzzer/README.md.
This executed gen_exceptions.sh with the latest web_tests.zip archive.
FYI, the exceptions mark files with parse/mutation errors - i.e. the
fuzzer bails out and is ineffective on those files. It also marks
files not applicable in strict mode, which lets the fuzzer only
choose sloppy instead of bailing out. Some medium slow tests are
going to be chosen with lower probability.
This also fixes a bug in template literal replacements which reduces
the number of skipped test cases.
Change-Id: I39ae9b4c4f8dcff65226d49545eb50b1cbfe5c8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4184213
Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85471}
Initial support for polymorphic loads using a single Maglev IR.
Bug: v8:7700
Change-Id: Ia1c800b60628636c6a9a0c153ab818fbc9d7540a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4178828
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85470}
After instruction stream refactoring, we were not printing the
assembler instructions anymore.
Change-Id: I450da42c9a79219b7f1c2230fae2ff65034e7449
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191783
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85469}
The built-in wasm function behaves similar to
string.new_utf8_array but in case of invalid characters
returns `null` instead of throwing an exception.
There has been a similar change for string.new_utf8_try
at https://crrev.com/c/4177105 / 5628a2be90.
Bug: v8:12868
Change-Id: I4bcc5ed3b1b22beafd4910d317f363eb3762165e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191781
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85468}
CodeCreateEvent expects one of a) bytecode, b) builtins, c) baseline
code.
The invalid DCHECK was introduced in crrev.com/c/4178821.
Bug: v8:13654
Fixed: chromium:1409785
Change-Id: Ib12ca6e6ec722dcaaf02f3dc57a4bf24e2830a91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194188
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85467}
The wasm instruction string.compare performs a three-way
comparison and returns -1, 0 or 1 if the compared strings are
lessThan, equal or greaterThan.
It traps if either of the input values is null.
Bug: v8:12868
Change-Id: I4082f22d38e46447eb841c71955521297128237d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191772
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85466}
In the concurrent marker during visitor dispatch a FixedDoubleArray
might be left-trimmed right between loading the visitor_id and the
downcast of the HeapObject to FixedDoubleArray with FixedDoubleArray::cast. This forces us to use the unchecked_cast
method like we already do for FixedArray or some string types.
Bug: chromium:1409000
Change-Id: Ia8c1f68fd19e07529d5820e121f142c1ed16b21a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191776
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85465}
Rolling v8/build: d2dda6b..3ed59a9
Rolling v8/buildtools: 37cb03b..0cc02fb
Rolling v8/buildtools/third_party/libc++/trunk: 885d5d1..1dfd002
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/7bfa128..45986b0
Rolling v8/third_party/depot_tools: b88a434..00be3f0
Rolling v8/third_party/fuchsia-sdk/sdk: version:11.20230122.2.1..version:11.20230124.2.1
Change-Id: I3a980206a31a50d6c2dff98a4a91fe85de3ae031
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4193349
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#85464}
Annotate more methods that are called on errors as V8_PRESERVE_MOST, to
make the caller code slimmer and faster.
R=dlehmann@chromium.org
Bug: v8:13565, v8:13673
Change-Id: I9d6db2ba0c02fa134aa22960b31bd35734362ba5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4188384
Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85462}
This adds the APIs for the embedder to
1) request compile hints collection for a script
2) retrieve the compile hint data
Bug: chromium:1406506
Change-Id: Ic23430d3cff9fe71faa71f4c7be6635467e14268
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4154427
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85461}
Right now, only the condition that we did not overrun the input buffer
is marked as likely. But if this is actually a fastpath, then the
condition that the continuation bit is not set should be likely as well.
I confirmed that his moves the slowpath at the end of, e.g., the Liftoff
DecodeI32Const handler, which should lightly improve instruction cache
utilization since it keeps hot code together (not measured) and does
not regress code size (total size of the release d8 binary is exactly
equal before and after).
Bug: v8:13673
R=clemensb@chromium.org
Change-Id: I65f81efe6cc6fe97d37a7218fb293e2b16ccad70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191770
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85459}
We currently skip a few memory64 spec tests; some for missing rebase,
some for unknown reasons.
It turns out that all of the failures are due to missing rebase on bulk
memory or reference types.
This CL documents that in the comment and removes a TODO.
R=jkummerow@chromium.orgCC=sbc@chromium.org
Bug: v8:13692
Change-Id: I0ddf2bee0dcc36af5bc39251ed7b6b83d8de9aeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191771
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85457}
Add V8_ASSUME statements such that the compiler can statically exploit
information in Liftoff and TurboFan code that was checked to be true
during validation beforehand. In particular, this removes bounds checks
for std::vector accesses that the compiler could not elide.
The main benefit of this change is not so much the removed branches,
but rather reduced code size and fewer clobbered registers.
In case of a failed bounds check, there were about 50 bytes of x64
instructions just for reporting the error via __libcpp_verbose_abort.
For that call alone, rdi, rsi, rcx, r8, edx, and eax were clobbered.
In total, this change reduces the d8 release code size by about 4KB.
R=clemensb@chromium.org
Bug: v8:13673
Change-Id: Iaccef478b75ba086941f70a8f39fa612f1a7e50d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191764
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85456}
This CL introduces a mechanism for setting a stack marker, to be used
for scanning only the part of stack between its start and the marker
(instead of the current stack top). Without this, the marking verifier
may encounter objects that have not been marked, because of false
positives during conservative stack scanning. The marker is introduced
in the Stack object, replacing and generalizing the one that existed
in the CppHeap.
Bug: v8:13257
Change-Id: I59cfb01e90912f9e54828bf05a3bdcfddb23e7bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4187221
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85454}
We have a PeekArgs version that operates on a signature, and another
version that operates on a vector of value types. We can easily get the
latter from the former and remove one of the two identical
implementations.
R=jkummerow@chromium.org
Bug: v8:13636
Change-Id: Ib60d323c810305e4604eff1d1c95079b7b176676
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4188394
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85453}
The patch fixes two bugs in hinting:
- trimmed whitespace in hints was not taken into account.
- range check for out-of-bound hints did not include the offset.
Bug: chromium:1409286
Change-Id: I5838cd6b697ed13a19c30f158963c0d9fac2f045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4187224
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85448}
Stack information is thread-specific and, until now, it was stored in a
field in ThreadLocalTop. This CL moves stack information to the isolate
and makes sure to update the stack start whenever a main thread enters
the isolate. At the same time, the Stack object is refactored and
simplified.
As a side effect, after removing the Stack object, ThreadLocalTop
satisfies the std::standard_layout trait; this fixes some issues
observed with different C++ compilers.
Bug: v8:13630
Bug: v8:13257
Change-Id: I026a35af3bc6999a09b21f277756d4454c086343
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4152476
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85445}
- Introduce a new SetFunctionName runtime
- Call SetFunctionName in DefineKeyedOwnIC to handle function name for initializers of computed class fields
- Ensure that we don't set function name twice in the case '({ ['c']: class { static x = this.name; static name = 'd' } })', which would incorrectly reconfigure the defined own property `name`
Bug: v8:13451
Change-Id: I10dcb858a65c6e59cba6bae94b8e63a78e44778b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4035497
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85444}
When setting up the read only heap in mksnapshot with static roots
enabled we should ensure as early as possible that the roots are
unchanged. This prevents us from running any further code with an
incorrect roots table leading to hard to debug crashes.
Bug: v8:13466
Change-Id: I4ed9efadc79a2bf6f04c2365dabe9bf0116852d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4188380
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85443}
This change reduces the size of translation arrays by adding two more
translation opcodes to reduce the number of operands that must be
written. In particular:
- The last two operands for INTERPRETED_FRAME are usually zero, so we
can add a separate opcode with two fewer operands where those values
are implicitly zero.
- The update_feedback operand for BEGIN is always either zero or one, so
we can split BEGIN into _WITH_FEEDBACK and _WITHOUT_FEEDBACK variants.
This change saves about 13% of the total generated TranslationArray
bytes in an Octane run, a reduction from around 1.4 MB to 1.2 MB. I
don't see any difference in the time taken by V8.TFCodeGeneration with
this change.
Bug: v8:11354
Change-Id: Ic049d0b636693cd3278514e5e5e975b80a78d8e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4178895
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85439}
This improves performance of `String.prototype.replace` by avoiding
a runtime call in the case of strings.
Change-Id: Id2339defa660b28ffde3d2e116c0a666ad1bfb1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4173577
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85437}
