This fixes a TODO about atomics and memory64 and removes the explicit
CHECK that checks for the unsupported situation.
Similar to other memory accesses, the memory index is supposed to be a
64-bit value if memory64 is being used.
The bounds checking implementation in Liftoff and TurboFan is shared
with non-atomic memory accesses, so this is already prepared for
memory64. We only need to fix the expected type in the function body
decoder, and prepare the assembler for 64-bit values.
R=jkummerow@chromium.org
Bug: v8:13636, v8:10949
Change-Id: I210ac488bd2bb1cb141e16597ca62d3fb27cad3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191767
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85525}
This CL fixes failing DCHECKs when Heap::CollectCodeStatistics() is
invoked in the atomic GC pause.
* Heap::CollectGarbage disallows GC, so move CollectCodeStatistics()
into Heap::GarbageCollectionEpilogue() where such an exception
already exists.
* CollectCodeStatistics() also needs to finish sweeping but a DCHECK
in GCTracer only allowed this for heap verification.
Bug: v8:13267
Change-Id: I6c8e75ad5e78347fc162d3b67be10cb972269a12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197335
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85513}
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.
Some tests are unsuitable for testing in "GC stress" mode, because
this interferes with the execution of FinalizationRegistry cleanup
tasks or with the clearing of WeakRefs, when asynchronous GC is used.
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
This is a reland of commit 20a954f4bc
> 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: I298ccbc932afc44d5c8c858620a180388a25f5d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197675
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85512}
Some very hot getters in Blink can spend many cycles on decompression.
We're planning to optimize such paths by selectively using uncompressed
pointers.
Change-Id: I78af751c423c56010a794448450032c66f8fa244
Bug: chromium:1410145
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191778
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85508}
Other optimizations can create a situation where it is valid to treat a
stack slot as either 32-bit (which is what its value was created as) or
64-bit value (to which it was implicitly zero-extended). So when moving
such a value to a register, we cannot use a 32-bit move instruction just
because the source was annotated as such; we must also take the target
slot's representation into account.
Fixed: chromium:1407594
Bug: chromium:1356461
Change-Id: I00d850c11a020b055e90f6107b604cdd267d9b6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197349
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85501}
We need them there due to how they are restored on resume, but don't need them at all for other loops.
Bug: v8:7700
Change-Id: I28a13ccf05d4fcd7bcf5fb8abef4dedd64f990f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197096
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85498}
Previously we stored kProxy in this case, which resulted in
set semantics for proxies.
Bug: chromium:1409294
Change-Id: I6cca772eb6e6a35944375a72d10fc279263d2094
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4188383
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#85487}
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}
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}
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}
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}
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}
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}
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}
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}
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}
The fast path implementation for toLocaleLowercase (added in
333db24b55, https://crrev.com/c/3952317)
skipped the locale validation if the string to be converted is the empty
string.
This CL addresses it by delaying the early return for empty string to be
performed after the locale validation.
Bug: chromium:1409058
Change-Id: I2f2839dc836d8de662d308c86099707bf9ddfd9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4184199
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85434}
When our various debugging and error reporting facilities want to
perform a side effect free conversion of a value (which could be
a BigInt) to a String, then the usual BigInt::ToString is not a
great fit because it reacts to termination requests.
This patch adds a method BigInt::NoSideEffectsToString, which uses
a low upper bound instead of termination requests.
Fixed: chromium:1406774
Change-Id: Ibc5d37027823e4a03c470f1dd0a63c16c552850c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4177099
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85433}
This will allow on the infra side to easier link to the respective
shard on a test failure. Without that it's a hassle to find out on
which shard the failing test ran.
This also simplifies how the global test_config stores information.
Some information was duplicated, but is now rather shared through
properties if the owning object is already present.
Bug: v8:13681
Change-Id: I52f01a4fac74627575d80f25923faba99eb6a1fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4181030
Reviewed-by: Liviu Rau <liviurau@google.com>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85429}
This reverts commit 7eb8937bca.
Reason for revert: crbug.com/1408957
Original change's description:
> [turbofan] Optimize access to the length property of functions
>
> When compiling to JavaScript a language that supports curryfication, it
> is convenient to be able to efficiently get the arity of a function to
> check for partial application.
>
> Change-Id: I6611b523b2c3795f1f8fb123f63f5b6d604d793d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111447
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85409}
Fixed: chromium:1408957
Change-Id: I5200392af7532a864afd73fb0e88be9a2153a312
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4187075
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#85428}
This CL hides the ctor of the MemoryReducer::State class and only
provides factory methods for creating states. This simplifies creation
of states and makes it impossible to misuse the API.
Direct field accesses are also replaced with invocations of their
corresponding getter methods. The getter method will check whether
the current state is allowed to access that field.
Bug: v8:13653
Change-Id: I252a6d75d0ddb4813b16a706061ad1951cfa35ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4181026
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85426}
Previously we stored kProxy in this case, which resulted in
set semantics for proxies.
Bug: chromium:1408310
Change-Id: Id9f215b4c3c08416b6d6c5f4605839668a5df340
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4178811
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#85422}
Previously in the DevTools console, users could inspect a preview of all private class members on an instance, but if they wanted to evaluate or inspect a specific private class member out of a long list, they had to be debugging and in a scope that has access to those private names.
This patch adds support for extraordinary access of out-of-scope private member access in debug-evaluate, specifically for Debugger.evaluateOnCallframe() (for console calls invoked during debugging) and Runtime.evaluate() (for console calls invoked when the user is not debugging). This kind of access is not otherwise allowed in normal execution, but in the DevTools console it makes sense to relax the rules a bit for a better developer experience.
To support this kind of extraordinary access, if the parsing_while_debugging or is_repl_mode flag is set, when we encounter a private name reference that's in a top-level scope or an eval scope under a top-level scope, instead of throwing immediately, we bind the reference to a dynamic lookup variable, and emit bytecode that calls to %GetPrivateName() or %SetPrivateName() in the runtime to perform lookup of the private name as well as the load/store operations accordingly.
If there are more than on private name on the receiver matching the description (for example, an object with two `#field` private names from different classes), we throw an error for the ambiguity (we can consider supporting selection among the conflicting private names later, for the initial support we just throw for simplicity).
If there are no matching private names, or if the found private class member does not support the desired operation (e.g. attempting to write to a read-only private accessor), we throw an error as well.
If there is exactly one matching private name, and the found private class member support the desired operation, we dispatch to the proper behavior in the runtime calls.
Doc: https://docs.google.com/document/d/1Va89BKHjCDs9RccDWhuZBb6LyRMAd6BXM3-p25oHd8I/edit
Bug: chromium:1381806
Change-Id: I7d1db709470246050d2e4c2a85b2292e63c01fe9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020267
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85421}
When compiling to JavaScript a language that supports curryfication, it
is convenient to be able to efficiently get the arity of a function to
check for partial application.
Change-Id: I6611b523b2c3795f1f8fb123f63f5b6d604d793d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111447
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85409}
The built-in wasm function behaves similar to string.new_utf8
but in case of invalid characters returns `null` instead of
throwing an exception.
Bug: v8:12868
Change-Id: Idde9bc2563d6bff1ab163ca8ed2219b6db23ca28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4177105
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@{#85406}
If the phi moves are the same for all predecessors, the move optimizer
will merge them by picking an arbitrary move among them,
moving it to the phi's block, and eliminating the moves in the
predecessor blocks.
However, phi inputs may have different width, and this can result in a
mismatch between the source and destination representation.
Always emit gap moves based on the destination operand's
representation, to ensure that in this case the wider phi inputs are not
truncated.
R=tebbi@chromium.orgCC=dmercadier@chromium.org
Bug: chromium:1407571
Change-Id: I0263cd5024e8e1340fb971267b133a2a91090f8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4178824
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85403}
In the end we managed to have static root builds without a two stage
isolate setup. Thus, the mode for creating isolates with an existing
read only page is unused. Also, no other usecase for this mode emerged.
Bug: v8:13598
Bug: v8:13466
Change-Id: I0a8174ba9383db7364b6e4545702aafc6f48170c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4178814
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85396}
This CL reinstates the trampoline for pushing the values of
callee-saved registers on the stack, which is used for stack scanning.
It reintroduces the set of architecture-specific functions
PushAllRegistersAndIterateStack, removed in crrev.com/c/3989143.
The reason for this change is that the simpler architecture-specific
functions SaveCalleeSavedRegisters failed to correctly save the
values of the registers, in the presence of C++ compiler optimizations.
It also removes the stack context, introduced in crrev.com/c/4017512,
and uses again the trampoline for iterating through the stack.
Bug: v8:13257
Change-Id: I9e656a9b3ba6616168602300f2180b4f340593f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4171639
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85394}
A first stab at using some static maps to have faster instance type
checks in C++ code. This adds an instance type check variant which
uses the map without loading the instance_type field, when the
instance type corresponds to a single static map.
Changes the format of the static roots table to be more in line with
other code and orders the names by address.
Bug: v8:13466
Change-Id: I5417071efd24ee52d51146ef0887d32cb9b62fcd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4177102
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85392}
