- 01 Aug, 2022 1 commit
-
-
Marja Hölttä authored
Instead, create only 1 normalized map. This will benefit ES5-style classes. Bug: v8:13091 Change-Id: I495ea4a69aedef01b97f4b0d5aad19bb355ce004 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776692 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#82099}
-
- 19 Jul, 2022 2 commits
-
-
Leszek Swirski authored
The used_or_unused_instance_size_in_words field already determines whether the used fields are in- or out-of-object, so we can use it's value for a fast HasOutOfObjectProperties check rather than using NumberOfFields (which includes an iteration over the descriptor array). Change-Id: I6c5b4f3f793b8df7832def7465106f2af7306759 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718152 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#81828}
-
Shu-yu Guo authored
Bug: v8:13081 Change-Id: I34a736e8c3aaf0712da677925ff7ad64842ebc54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3770018 Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#81796}
-
- 15 Jul, 2022 1 commit
-
-
Adam Klein authored
This reverts commit e2066ff6. Reason for revert: fails tests on GC stress bot: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/42868/overview Original change's description: > [shared-struct] Add Atomics.Condition > > Bug: v8:12547 > Change-Id: Id439aef9cab3348171a23378cdd47ede5f4d7288 > Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630350 > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81734} Bug: v8:12547 Change-Id: I237b744e5be8725cbe41ca73076d951018ca80a0 Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763784 Auto-Submit: Adam Klein <adamk@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@{#81735}
-
- 14 Jul, 2022 1 commit
-
-
Shu-yu Guo authored
Bug: v8:12547 Change-Id: Id439aef9cab3348171a23378cdd47ede5f4d7288 Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630350Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#81734}
-
- 23 Jun, 2022 1 commit
-
-
Thibaud Michaud authored
If the returned promise rejects, we switch to the suspender's stack and throw the value. Re-purpose the WasmOnFulfilled data to also represent the rejecting case and rename it to WasmResumeData. R=ahaas@chromium.org CC=fgm@chromium.org Bug: v8:12191 Change-Id: I91a301c3c6d9d243efbfabe7263555e11f0d9277 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3706606Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/main@{#81325}
-
- 22 Jun, 2022 1 commit
-
-
Luis Fernando Pardo Sixtos authored
Initial implementation for concurrent shared arrays. Current implementation exposes a `SharedArray` constructor, but its syntax might change in the future. Shared arrays can be shared across Isolates, have a fixed size, have no prototype, have no constructor, and can only store primitives, shared structs and other shared arrays. With this CL shared structs are also allowed to store shared arrays. The Backing storage for the SharedArrays is a `FixedArrayBase`. This CL introdces a new ElementKind: `SHARED_ARRAY_ELEMENTS`. The new kind should match the overall functionality of the `PACKED_SEALED_ELEMENTS` kind, but having it as standalone kind allows for easier branching in CSA and turbofan code. Bug: v8:12547 Change-Id: I054a04624d4cf1f37bc26ae4b92b6fe33408538a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585353Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#81285}
-
- 20 Jun, 2022 1 commit
-
-
Igor Sheludko authored
... to avoid additional indirection on every access. Drive-by: given that AccessorInfo class now has a custom body visitor it's no longer necessary to encode flags field as Smi. Bug: v8:12949 Change-Id: I30eabee3cbc5ded2bf3f050dfe22208713a764bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3701590Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#81237}
-
- 10 Jun, 2022 1 commit
-
-
Igor Sheludko authored
... to avoid additional indirection on every access. Bug: v8:12949 Change-Id: I16840ac0517e86f1f70252153112ca3475527416 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3693707Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#81083}
-
- 13 May, 2022 1 commit
-
-
Clemens Backes authored
Now that we require C++17 support, we can just use the standard static_assert without message, instead of our STATIC_ASSERT macro. R=leszeks@chromium.org Bug: v8:12425 Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80524}
-
- 08 Apr, 2022 1 commit
-
-
Marja Hölttä authored
Bug: v8:11111 Change-Id: I94f992f78a12a86c89924261bd64c73f935051b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576118Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#79869}
-
- 07 Apr, 2022 1 commit
-
-
Nico Hartmann authored
This CL adds the requirements to port object definitions back to C++. A @cppObjectDefinition is introduced to annotate classes for which Torque shall merely generate asserts to check that offsets match between Torque and C++. As a first object, this CL ports Oddball back to C++. Bug: v8:12710 Change-Id: I1304d8980f6318ffccbc2ef7284cb9d46ff579e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3523046Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#79856}
-
- 24 Mar, 2022 1 commit
-
-
Benedikt Meurer authored
The debugger maintains a stack of promises used for catch prediction with promise builtins and async functions. Previously this stack would hold on to the individual promises strongly, and subtle bugs that lead to not properly cleaning up the stack in some corner cases would often lead to significant memory issues (e.g. leaking whole iframes). This refactors the PromiseOnStack to be (a) on the V8 heap, rather than allocating C++ structs with global handles pointing to the promises, and (b) hold on to the promises only weakly. While this will not guarantee proper promise stack management, it will at least ensure that edge cases don't lead to catastrophic (debugger only) leaks. Bug: chromium:1292063 Change-Id: I9c293ca2032de3a59e1e9624f132d37187805567 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545176 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#79594}
-
- 14 Mar, 2022 1 commit
-
-
Samuel Groß authored
Instead of implementing ExternalObjects as plain JSObjects with a single EmbedderDataSlot pointing to a Foreign containing the actual raw pointer, this CL now creates a new JSExternalObject type that directly contains the external pointer. As a side-effect of this refactoring, nullptr values are now no longer valid for ExternalObjects. Change-Id: Ic8ff334681c966e823ca70f34dd1efaaa21a0789 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3513234Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#79459}
-
- 26 Jan, 2022 1 commit
-
-
Thibaud Michaud authored
Create and return the chained promise, which resumes the suspended wasm continuation once the JS promise resolves: - Add stub for the WasmResume builtin, which will resume the given suspender. - Add the JS function wrapper for the builtin. - On suspension, return promise.then(onFulfilled) to the prompt. R=ahaas@chromium.org CC=fgm@chromium.org Bug: v8:12191 Change-Id: I2d6136b2bd610daa4be1880f347b7bdf897e75ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404776Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/main@{#78787}
-
- 13 Jan, 2022 1 commit
-
-
Jakob Gruber authored
CompleteInobjectSlackTracking potentially shrinks multiple maps, and the relation between these maps should be preserved in a concurrent environment. Thus it is not enough to make each modification atomically, but all related map modifications must be within a critical section. We do this by locking the map_updater_access mutex CompleteInobjectSlackTracking, and hence moving the function to the MapUpdater class. Bug: chromium:1274445,v8:7990 Change-Id: If99bb8b55e03180128ee397d845fa4c269c4241e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379819Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#78597}
-
- 30 Nov, 2021 1 commit
-
-
Seth Brenith authored
Currently, JSFinalizationRegistry has a BodyDescriptor that iterates next_dirty as a custom weak field, and it has a WeakListVisitor that cleans up any items from the list that should be removed. However, none of that code is used, because JSFinalizationRegistry objects are created with visitor ID kVisitJSObjectFast. This change gives them a custom visitor ID so that next_dirty can be treated as weak. Bug: v8:12430 Change-Id: I31c1935257ad508b13a3e684662d2ca406d8ed19 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3307096 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78167}
-
- 24 Nov, 2021 1 commit
-
-
Manos Koukoutos authored
Design doc: bit.ly/3jEVgzz We separate the internal representation of function references in Wasm from their JSFunction-based (external) representation. This improves performance of call_ref by requiring less indirections to load the context and call target from a function reference. In the boundary between wasm and JS/the C API, we add transformations between the two representations. Detailed changes: - Introduce WasmInternalFunction, containing fields required by call_ref, as well as a reference to the corresponding WasmExternalFunction. Add a reference to the WasmInternalFunction in WasmFunctionData. The {WasmInternalFunction::FromExternal} helper extracts the internal out of an external function. - Change {WasmInstanceObject::external_functions()} to internal functions. - Change wasm function tables to contain internal functions. - Change the following code to use internal functions: - call_ref in liftoff and Turbofan - function type checks in liftoff and Turbofan - CallRefIC and GenericJSToWasmWrapper builtins - {InitExprInterface::RefFunc} - module-compiler.cc in {ProcessTypeFeedback} - In module-instantiate.cc, in function-rtt creation. - Add transformations between internal and external functions in: - WasmWrapperGraphBuilder::{ToJS, BuildUnpackObjectWrapper, FromJS, BuildJSToJSWrapper}. - debug-wasm-objects.cc in {FunctionProxy::Get}, {WasmValueObject::New} and {AddWasmTableObjectInternalProperties}. - runtime-wasm.cc in ReplaceWrapper - the C and JS APIs - module-instantiate.cc, in import and export processing, as well as {InitializeIndirectFunctionTables} - WasmTableObject::{IsValidElement, SetFunctionTableEntry} - {WasmGlobalObject::SetFuncRef} - Simplify body descriptors of WasmExternalFunction variants. - Adjust tests. Bug: v8:11510 Change-Id: I8377f46f55c3771391ae1c5c8201a83854ee7878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277878Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#78068}
-
- 05 Nov, 2021 1 commit
-
-
Thibaud Michaud authored
R=ahaas@chromium.org Bug: v8:12191 Change-Id: I15a5507a7dd0f02a3bbe9d3ce200206adf4d4539 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231075 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#77734}
-
- 03 Nov, 2021 2 commits
-
-
Nico Hartmann authored
This reverts commit a3480b55. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20header%20includes/22234/overview Original change's description: > Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants" > > This is a reland of 7366f6e2 > > The test that failed after the initial commit was just flaky and has > been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341 > > Original change's description: > > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants > > > > Torque currently generates constants like kStartOfWeakFieldsOffset and > > kEndOfStrongFieldsOffset, which can be used when writing custom > > BodyDescriptors. However, these offsets have some potentially confusing > > behaviors: > > > > * They don't take inheritance into account and describe only the fields > > defined by the current class itself, so there might be (for example) > > strong fields before kStartOfStrongFieldsOffset if they were defined > > by a superclass. > > * kStartOfWeakFieldsOffset points to the first field defined in Torque > > using the keyword `weak`, which indicates fields with *custom* > > weakness semantics (those that should be visited with > > IterateCustomWeakPointers), not those that may contain standard weak > > pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd > > like to also rename `weak` to `@customWeak`.) > > > > Given that these constants have very low usage and somewhat bizarre > > semantics, I propose that we remove them. This change does so, and > > updates the existing usages to either define the required constants > > directly in C++ or not use them. I know that defining these constants in > > C++ is more brittle, but I think that brittle and clear is better than > > automatic and incomprehensible. > > > > Bug: v8:7793 > > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731 > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > > Cr-Commit-Position: refs/heads/main@{#77411} > > Bug: v8:7793 > Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#77688} Bug: v8:7793 Change-Id: I7b9667268901b7aef85a95832d40860056e61050 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259656Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#77689}
-
Seth Brenith authored
This is a reland of 7366f6e2 The test that failed after the initial commit was just flaky and has been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341 Original change's description: > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants > > Torque currently generates constants like kStartOfWeakFieldsOffset and > kEndOfStrongFieldsOffset, which can be used when writing custom > BodyDescriptors. However, these offsets have some potentially confusing > behaviors: > > * They don't take inheritance into account and describe only the fields > defined by the current class itself, so there might be (for example) > strong fields before kStartOfStrongFieldsOffset if they were defined > by a superclass. > * kStartOfWeakFieldsOffset points to the first field defined in Torque > using the keyword `weak`, which indicates fields with *custom* > weakness semantics (those that should be visited with > IterateCustomWeakPointers), not those that may contain standard weak > pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd > like to also rename `weak` to `@customWeak`.) > > Given that these constants have very low usage and somewhat bizarre > semantics, I propose that we remove them. This change does so, and > updates the existing usages to either define the required constants > directly in C++ or not use them. I know that defining these constants in > C++ is more brittle, but I think that brittle and clear is better than > automatic and incomprehensible. > > Bug: v8:7793 > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#77411} Bug: v8:7793 Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77688}
-
- 27 Oct, 2021 1 commit
-
-
Manos Koukoutos authored
This object will be used for the 'ref' field of WasmCapiFunctionData and WasmJSFunctionData, replacing the currently used pair. Design doc: https://bit.ly/3jEVgzz Bug: v8:11510 Change-Id: Ic5dec88458b562883d571b3463269b2308f489c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3236718Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#77575}
-
- 15 Oct, 2021 2 commits
-
-
Leszek Swirski authored
This reverts commit 7366f6e2. Reason for revert: Speculative revert for cctest/test-debug-helper/GetObjectProperties failures https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8833300564873660401/+/u/Check/GetObjectProperties Original change's description: > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants > > Torque currently generates constants like kStartOfWeakFieldsOffset and > kEndOfStrongFieldsOffset, which can be used when writing custom > BodyDescriptors. However, these offsets have some potentially confusing > behaviors: > > * They don't take inheritance into account and describe only the fields > defined by the current class itself, so there might be (for example) > strong fields before kStartOfStrongFieldsOffset if they were defined > by a superclass. > * kStartOfWeakFieldsOffset points to the first field defined in Torque > using the keyword `weak`, which indicates fields with *custom* > weakness semantics (those that should be visited with > IterateCustomWeakPointers), not those that may contain standard weak > pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd > like to also rename `weak` to `@customWeak`.) > > Given that these constants have very low usage and somewhat bizarre > semantics, I propose that we remove them. This change does so, and > updates the existing usages to either define the required constants > directly in C++ or not use them. I know that defining these constants in > C++ is more brittle, but I think that brittle and clear is better than > automatic and incomprehensible. > > Bug: v8:7793 > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#77411} Bug: v8:7793 Change-Id: Ia12b5d773db35739283ca8871d3dd6922413cc82 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226783 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77415}
-
Seth Brenith authored
Torque currently generates constants like kStartOfWeakFieldsOffset and kEndOfStrongFieldsOffset, which can be used when writing custom BodyDescriptors. However, these offsets have some potentially confusing behaviors: * They don't take inheritance into account and describe only the fields defined by the current class itself, so there might be (for example) strong fields before kStartOfStrongFieldsOffset if they were defined by a superclass. * kStartOfWeakFieldsOffset points to the first field defined in Torque using the keyword `weak`, which indicates fields with *custom* weakness semantics (those that should be visited with IterateCustomWeakPointers), not those that may contain standard weak pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd like to also rename `weak` to `@customWeak`.) Given that these constants have very low usage and somewhat bizarre semantics, I propose that we remove them. This change does so, and updates the existing usages to either define the required constants directly in C++ or not use them. I know that defining these constants in C++ is more brittle, but I think that brittle and clear is better than automatic and incomprehensible. Bug: v8:7793 Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77411}
-
- 29 Sep, 2021 1 commit
-
-
Seth Brenith authored
Nobody uses the generated *_FIELDS macros anymore, so we can remove them. I also renamed the generated file to represent its content better. Bug: v8:7793 Change-Id: I49ab39e363d6961e7210cd67018b6fb83b65a162 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3192191Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77151}
-
- 16 Sep, 2021 1 commit
-
-
Georg Neis authored
... by adding atomic (relaxed) accessor's for a map's constructor_or_backpointer field, and using them in the two functions. Bug: chromium:1250216, v8:7790 Change-Id: I3416799cca73792ff5f8963685274ad9afdc6229 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162129Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/main@{#76876}
-
- 19 Aug, 2021 1 commit
-
-
Jakob Kummerow authored
It must be possible to determine an object's size on the heap without relying on the presence of any other objects. Specifically, if an object and its WasmTypeInfo die at the same time, they can be swept in any order, and the sweeper may need to know their sizes. This patch solves the problem by repurposing two bytes in the Map, where WasmStructs can store their instance size, and WasmArrays can store their element size (which can be used to compute their size). Fixed: chromium:1240670 Change-Id: Ib960fd0a409936aff1aef4daafed4c38b8497880 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3106649 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#76391}
-
- 12 Aug, 2021 1 commit
-
-
Jakob Gruber authored
The concurrent version was added recently in crrev.com/c/3085262. - UnusedPropertyFields requires the MapUpdater lock. - instance_descriptors must be read atomically on the bg thread. Finally, there appears to be a false positive report for the pattern: x = is_concurrent ? foo(kAcquireLoad) : foo(); Here, clang emits code that executes both the atomic and nonatomic reads when is_concurrent is true. Needs more investigation. Bug: v8:7790, chromium:1239009 Change-Id: I07d442e72cf0278f79f202a267e8d246f8abca1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3090341 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#76261}
-
- 11 Aug, 2021 3 commits
-
-
Jakob Gruber authored
.. to attempt to update deprecated maps. Used in JSHeapBroker::ReadFeedbackForPropertyAccess. Drive-by: Move Map::TryUpdate to MapUpdater to address an old TODO. Bug: v8:7790 Change-Id: Iaa791e204dd133f067014c0abdb23ef3b807a315 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3085274 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#76224}
-
Jakob Gruber authored
MapRef::AsElementsKind can now concurrently walk transitions to find a map of the requested elements kind. Note this implementation is still less powerful than what we had before crrev.com/c/3021175, since we never allocate new maps. When the transition walk fails to find an appropriate map, we bail out. I don't expect this to be a problem - when optimizing, the code has already run multiple times and transitioned maps should exist. Bug: v8:7790, v8:11988 Change-Id: Ic767b40c29bb86f7c4167097c76c5417985420fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3086471 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76216}
-
Jakob Gruber authored
Re-enable the creation of elements transition groups in JSHeapBroker::ProcessFeedbackMapsForElementAccess. This turned out to be quite important for performance. Bug: v8:7790,v8:12031 Change-Id: I4d24837a668a5f7e78a5078212a7dc34b767d703 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3085262Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76215}
-
- 20 Jul, 2021 1 commit
-
-
Seth Brenith authored
Most Torque-defined extern classes already use @generateCppClass. As Nico pointed out in [1], it would be nice to convert the remaining classes and remove this option. This change converts most of those remaining classes. I know that the future of Torque-defined classes is a subject of some debate right now, but I think that it's worth doing a few mechanical changes to reduce the existing variety of options. Changes that don't exactly follow the usual pattern: 1. BigIntBase, MutableBigInt: we can define these without a body, and then Torque treats them as "really external" rather than "kind of external, but with some Torque-generated parts". 2. RegExpMatchInfo: moved its inline functions into a separate file, which the generated -tq.cc file requires. [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit# Bug: v8:8952 Change-Id: I84c7958a295caa0bab847683c05022e18c921cad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027742Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#75817}
-
- 11 Jun, 2021 1 commit
-
-
Igor Sheludko authored
This CL adds WASM_ARRAY_ELEMENTS to distinguish WasmArray maps. Bug: v8:11804 Change-Id: I243ce24c2f2246efbc223af14361c28506e9a2d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922884 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#75109}
-
- 26 May, 2021 1 commit
-
-
Jakob Gruber authored
.. when concurrent-inlining, use direct reads instead. Two fields were changed to have a non-atomic getter and acq-rel accessors: - Map::prototype_info - PrototypeInfo::object_create_map Bug: v8:7790 Change-Id: I05e888240d73ab6e961b1048a25713ec45fb0305 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876852Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74777}
-
- 19 May, 2021 1 commit
-
-
Jakob Kummerow authored
We used to recompile WasmCapiCallWrappers whenever they were needed, but never garbage-collected them, which caused a memory leak when many short-lived instances of the same module were created. This patch makes the wrappers cacheable and caches them, which avoids both repeated compilation effort and the unbounded memory growth. Drive-by cleanup: unify WasmCapiFunctionData with the other Wasm*FunctionData classes by making it inherit from WasmFunctionData. Bug: v8:11774 Change-Id: Ia0c0d76be2938dc7bebfdc845f4a1cfeafef4a70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905605 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74682}
-
- 10 May, 2021 1 commit
-
-
Marja Hölttä authored
Detailed list of changes: https://docs.google.com/document/d/15i4-SZDzFDW7FfclIYuZEhFn-q-KpobCBy23x9zZZLc/edit?usp=sharing Bug: v8:11111 Change-Id: I931003bd4552cf91d57de95af04a427a9e6d6ac9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814259Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#74459}
-
- 03 May, 2021 1 commit
-
-
Igor Sheludko authored
When fast deleting properties generalize all outgoing transitions to mutable instead of generalizing when property is reconfigured. Bug: chromium:1201938 Change-Id: I080f2f43de1691a742be2a2bec5cd20d02d78dbc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859960 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74334}
-
- 29 Apr, 2021 1 commit
-
-
Jakob Kummerow authored
By (mostly) unifying the different kinds of WasmFunctionData, and precomputing and caching what we can, we can reduce the amount of work that has to be done for each call. We still have to store the current instance for JS function calls; that may be eliminatable in the future. WasmCapiFunctions are not included in the refactoring yet. Bug: v8:7748,v8:9495 Change-Id: Ie6839153153d5854670cd01bc77a86111c1f68d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2856543 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#74287}
-
- 28 Apr, 2021 1 commit
-
-
Dominik Inführ authored
A NativeContext is initialized in two steps: First the map is allocated, only afterwards the NativeContext. It could happen that there is a GC happening when allocating the NativeContext. In such a case the native_context for the Map is still set to null. Fix this by also allowing null in Map::MapVerify. Bug: v8:11695 Change-Id: Id8dcd6aef83aff4cbfff45a1e993e555cff8e7bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2853587Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#74237}
-
- 22 Apr, 2021 1 commit
-
-
Jakob Gruber authored
Until this CL, the JSHeapBroker::GetPropertyAccessInfo (GPAI) process was as follows: 1. GPAI is called on the main thread (MT) during the serialization phase to create and cache PAIs. 2. GPAI is called again from the background thread (BT); only cached PAIs from step 1 are usable. As part of concurrent inlining, the goal is to move GPAI fully to the background thread. This CL takes a major step in that direction by making GPAI itself callable from the BT without resorting solely to PAIs that were previously cached on the MT. There are two main reasons why GPAI previously had to run on the MT: a) Concurrent access to Maps and other heap objects. b) Serialization and creation of ObjectRefs for objects discovered during GPAI. This CL addresses only reason a) and leaves b) for future work. This is done by keeping the two-pass approach, s.t. the initial call of GPAI on the MT discovers and serializes objects. We then clear all cached PAIs. The second call of GPAI on the BT thus runs full logic in a concurrent setting. Once all relevant objects (= maps and prototypes) no longer require MT-serialization, reason b) is also addressed and the first pass can be removed. The new logic is implemented behind the runtime flag --turbo-concurrent-get-property-access-info (default true), intended to be removed in the future. Bug: v8:7790 Change-Id: Idbdbfe091d7316529246a686bb6d71c2a0f06f8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2817793 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74120}
-