- 16 Sep, 2022 40 commits
-
-
Dominik Inführ authored
This CL unifies the fields for shared spaces for both the shared isolate and the shared space isolate-approach. This allows to mostly avoid separate code paths for both implementations. While this CL already sets up everything needed for allocation with --shared-space, allocation isn't fully working with this CL due to other remaining issues. Bug: v8:13267 Change-Id: Icdb40ed7045e33e6acbb97d3838fa374e6c24a2e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3892786Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#83280}
-
Michael Lippautz authored
Finalizing sweeping can be beneficial to truly end a GC cylce. We should only finalize in `FinishIfOutOfWork()` though if that would not introduce any jank. Limit the amount of executing finalizers in that scenario. Bug: v8:13294 Change-Id: I0237f6b6017d444c457923d83e85147c58586445 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3902222 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/main@{#83279}
-
Leon Bettscheider authored
This CL adds processing of the OLD_TO_NEW RememberedSet during minor incremental marking start. Bug: v8:13012 Change-Id: I4fd051087d46e1b8a22b735bf0cae6d2da2ecb5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3885875Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Teodor Dutu authored
In order to support a larger heap cage (8GB, 16GB), the cage offset will take up more than 32 bits. As a consequence, for 8GB cages, the least significant bit of the cage offset will overlap with the most significant bit of the tagged offset. To avoid this, allocations need to be aligned to 8 or 16 bytes to free up one or two bits from the offset. The allocation top is kept properly aligned without adding fillers in the newly created gaps, by aligning allocation sizes to 8 bytes. Bug: v8:13070 Change-Id: I169b51e583d7a4be61d2a6c6060fcf74b410703c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3877147Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Teo Dutu <teodutu@google.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#83277}
-
Clemens Backes authored
In multiple counters we have peaks in the 0 microseconds and 1000 microseconds bucket, most probably coming from clients with a low-resolution clock. Exclude those to get more precise timings. R=jkummerow@chromium.org Change-Id: I9b8377354920db4d0070198f440b57a7e86dc7bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3902221Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#83276}
-
Manos Koukoutos authored
We move js-to-wasm wrappers to a WeakFixedArray in the isolate, indexed by their canonical type index. This ensures that they are reused across instances, and get GC'd when no longer needed. We also remove eager compilation of wrappers. This CL fixes some issues that were caused by out-of-bounds accesses to wrapper arrays attached to module objects. Bug: chromium:1363859, chromium:1363895 Change-Id: Idec0925e775f51fdfa7cd380379b0d1798295a0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3893860Reviewed-by:
-
Manos Koukoutos authored
Bug: v8:7748, chromium:1364036 Change-Id: I0263a21671fc602127aaae3b3ce022190be91407 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899295Reviewed-by:
-
Milad Fa authored
Change-Id: Id27959b1e65b86e6d00bd67f637d14a4606a9765 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899300 Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Reviewed-by:
Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/main@{#83273}
-
Leszek Swirski authored
Looks like we hammered on the regalloc hard enough that this works again 🥳 Bug: v8:7700 Change-Id: I4f02417e069e3a6d89ca0c8c43ba165a502150e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899302 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#83272}
-
Clemens Backes authored
R=verwaest@chromium.org CC=mliedtke@chromium.org Change-Id: I1a0b65b14a26f82ae6e86b10344019e1e21bd8f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3898935Reviewed-by:
-
Clemens Backes authored
Avoid the deprecated FLAG_* syntax, access flag values via the {v8_flags} struct instead. R=jkummerow@chromium.org Bug: v8:12887 Change-Id: Ia17d668b3ddcbcb7a35388231aa5d80e8e5b419b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899122 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Michael Lippautz authored
We only complete sweeping when the young generation GC is enabled. Change-Id: I915acce35d6ba16716c2c4ee4130f99af0744f83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3900377Reviewed-by:
-
Michael Lippautz authored
Align slow path allocation with V8 in that: 1. Try to refill from the free list. 2. Perform limited sweeping of a space if necessary and retry the free list. 3. Try to expand the space. 4. Perform full sweeping of a space if necessary and retry the free list. 5. Finish sweeping fully as we would anyways do a GC at this point. 6. Retry the free list again 7. Try expanding again as finishing sweeping may have freed up pages. Specifically, this adresses a performance problem where we would fully sweep the whole heap, possibly causing 100ms of jank on allocation. In such cases the new approach maintains performance and stays fast at the expense of using more memory. Allocations usually find memory in 1.-3. Steps 4.-7. are slow paths that are definitely expensive but prevent failing with OOM. Bug: v8:13294 Change-Id: I56133fa4cbbc74f8abcdec49c7e10125c2dbc3e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899260 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Clemens Backes authored
Avoid the deprecated FLAG_* syntax, access flag values via the {v8_flags} struct instead. R=marja@chromium.org Bug: v8:12887 Change-Id: Ie6e725305db09f675da255a0da73d85e2a36298b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3900374 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#83267}
-
Tobias Tebbi authored
Bug: v8:12783 Change-Id: I723438d4843861b5933f1ea1f649ae426a2a1c04 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899125 Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Darius Mercadier <dmercadier@chromium.org> Reviewed-by:
Darius Mercadier <dmercadier@chromium.org> Cr-Commit-Position: refs/heads/main@{#83266}
-
Clemens Backes authored
Avoid the deprecated FLAG_* syntax, access flag values via the {v8_flags} struct instead. R=saelo@chromium.org Bug: v8:12887 Change-Id: I7e41e1952958936c32fec501b8348fac0538cd71 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899269Reviewed-by:Samuel Groß <saelo@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#83265}
-
Clemens Backes authored
Avoid the deprecated FLAG_* syntax, access flag values via the {v8_flags} struct instead. R=marja@chromium.org Bug: v8:12887 Change-Id: Id315d33eee6b45e457766b0ba06c9d21c1e32807 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899268 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Clemens Backes authored
Avoid the deprecated FLAG_* syntax, access flag values via the {v8_flags} struct instead. R=dinfuehr@chromium.org Bug: v8:12887 Change-Id: Icc9e1d2db58999b676477924284f78043cf5533c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899124Reviewed-by: -
Tobias Tebbi authored
Bug: v8:12783 Change-Id: I5de98493d67c7c797d4a1b2dcd18c0347821f0f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3870471Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#83262}
-
Clemens Backes authored
Avoid the deprecated FLAG_* syntax, access flag values via the {v8_flags} struct instead. R=ishell@chromium.org Bug: v8:12887 Change-Id: I2ef25bc50fdf12f0149f2cdfce7102f2cc0f25d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899196Reviewed-by: -
Dominik Inführ authored
Isolate::shared_isolate() was used in many locations to check for the shared heap feature. Now that we also have shared_space_isolate() checking shared_isolate() isn't sufficient anymore. This CL replaces many invocations of this method with either has_shared_heap() or shared_heap_isolate(). These methods work for both shared_isolate() and shared_space_isolate(). As soon as we remove the shared isolate we can remove them again. Bug: v8:13267 Change-Id: I68a3588aca2a12e204450c2b99635dd158d12111 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899316Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
-
Dominik Inführ authored
This is a reland of commit 6d342fa5 Original change's description: > [heap] Use std::unique_ptr for space_ array > > Document ownership with using std::unique_ptr<Space> for the space_ > array. > > Bug: v8:13267 > Change-Id: I12861d97cd52d2a8cf9ceb43a2f90008be87b2a3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3890913 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#83187} Bug: v8:13267 Change-Id: Idb25a656c4ba571d23132aa5e07cb13957c90f0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899121Reviewed-by:
-
Michael Achenbach authored
All --stress-* flags are now automatically tested. This also removes a superfluous option that was never changed. The default value is now inlined. No-Try: true Bug: v8:13113 Change-Id: If7428b383ed01ff36a93f618badababfc448db26 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899259Reviewed-by:
Alexander Schulze <alexschulze@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/main@{#83258}
-
Clemens Backes authored
Before adding serialization of tiering information, refactor the existing code to use a {ProfileGenerator} class. This makes it easier to add new methods that can use all existing fields (instead of having new functions that need a lot of parameters). R=jkummerow@chromium.org Bug: v8:13209 Change-Id: I0946cb1d507fde9e6d680ad588ba963c539d1d0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899301 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Dominik Inführ authored
Change-Id: Ibd4c958875d777ba5241a6424ab23f8a2d0ac5ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899263Reviewed-by:
-
Omer Katz authored
Bug: v8:12612, chromium:1364517 Change-Id: Id1e23d0ad0a786a01a432552937e1b6c6494bd9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899120Reviewed-by:
-
Clemens Backes authored
Remove the deprecated OnCriticalMemoryPressure method with receives an informative parameter. R=mlippautz@chromium.org Bug: chromium:634547 Change-Id: I932c3b5030291294dd340362f0b20d374e3067c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780533Reviewed-by:
-
Clemens Backes authored
The number of feedback vector slots is currently stored in the {WasmFunction}, returned in the {WasmCompilationResult}, and implicitly stored as the size of the {call_targets} vector in {FunctionTypeFeedback}. This CL uses the latter as the source of truth, encapsulated in a new {NumFeedbackSlots} function. This can be updated when adding new kinds of feedback that need additional slots. For now, the implementation of {NumFeedbackSlots} requires taking a mutex, which we can hopefully avoid when productionizing speculative inlining. We also take the mutex on every Liftoff compilation, which adds synchronization between concurrent compilation which we previously tried very hard to avoid (because it introduced significant overhead for eager compilation). As a nice side-effect, this CL reduces the per-function overhead by 8 bytes, independent of enabled features. R=jkummerow@chromium.org Bug: v8:13209 Change-Id: I2fe5f7fe73154328032a3f0961e88d068c5d07ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899299Reviewed-by: -
Dominik Inführ authored
This is a reland of commit 10756bea The reland is mostly unchanged except for changing the name for the shared large object space. The name should use the same style as other large object spaces. The main reason for reverting was fixed in https://crrev.com/c/3894303. Original change's description: > [heap] Add shared spaces for --shared-space > > This CL adds shared spaces for regular and large objects in the shared > space isolate. Spaces aren't used for allocation yet. > > Bug: v8:13267 > Change-Id: If508144530f4c9a1b3c0567570165955b64cc200 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3876824 > Reviewed-by: Jakob Linke <jgruber@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#83178} Bug: v8:13267 Change-Id: I3de586c1e141fb5f7693e2d6972db251b4a4f434 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3892950Reviewed-by:
Jakob Linke <jgruber@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#83252}
-
Darius M authored
We can't freely concatenate strings in the background because they could be mutated by the main thread (eg, flattened, internalized, externalized...). So, when there is a JSAdd between 2 constant strings, we first checked if they are "safe" (= internalized, I think), and if so, we concatenate them at compile time. If they are "unsafe", then we don't. It turns out that this wasn't an issue with delayed constant strings, since the content of the strings were never accessed: the actual concatenations were done on the main thread, where it's safe to do. This CL fixes that for most cases: - if the strings really cannot be read from the background, but the length of their concatenation is more than ConsString::kMinLength, then we create a ConsString. - I added a set to record which strings we created in the turbofan: those strings can safely be accessed from turbofan regardless of their type. The only case where delayed constant strings could be a bit better is when there is a concatenation of 2 small non-internalized string, because right now, we wouldn't fold it. Still, it should happen very rarely, if ever. Bug: chromium:1359941 Change-Id: I651b834273de89f1e3c60654094a4606dd9c62f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3891252Reviewed-by: -
Clemens Backes authored
This moves the existing PGO code to a separate cc file with a separate header. As the implementation will be further extended in follow-up CLs, it's better to have it separated. R=jkummerow@chromium.org Bug: v8:13209 Change-Id: I7b7b5bf9c8d3d542dae734f3874499dccee152a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899321Reviewed-by:
-
Leszek Swirski authored
Resolve a TODO to remove cached template objects from the template cache which have a cleared weak pointer to the template object. Requires a little bit of awkward code to handle the "head is dead" case, but OTOH the implementation cleans up the second Lookup of the head. Bug: v8:13190 Change-Id: I31a8d8ab77e04c8496a2cacb6154f2ee84d6a795 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899257 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#83249}
-
Leszek Swirski authored
The cached template object weakmap shouldn't be updated when we update an existing cached template object, because this update can truncate the linked list of cached template objects. Bug: v8:13190 Change-Id: Icea61fcbd5c05d4293a884d1872523ddcdfc3323 Fixed: chromium:1364429, chromium:1364471 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899256Reviewed-by:
-
Clemens Backes authored
Avoid the deprecated FLAG_* syntax, access flag values via the {v8_flags} struct instead. R=mliedtke@chromium.org Bug: v8:12887 Change-Id: I417eee6311fadef9b60043cfc9a42926859c7ab9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899304Reviewed-by:Matthias Liedtke <mliedtke@chromium.org> Commit-Queue: Matthias Liedtke <mliedtke@chromium.org> Cr-Commit-Position: refs/heads/main@{#83247}
-
pthier authored
This is a reland of commit 0a1f0e33 Changes since revert: - Deferred label for loading from forwarding table. - Check if hash is computed instead of checking if it is a forwarding index. - Retreive hash from forwarding table only if hash is assumed to be computed. Original change's description: > [strings] Fix raw hash lookup for forwarded strings > > Raw hashes may need to be looked up via the forwarding table when > internalized strings are forwarded to external resources. Notably, the > megamorphic ICs were not correctly fetching the raw hash. > > Bug: v8:12007 > Change-Id: Ibbc75de57e707788f544fbd1a0f8f0041350e29d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3885379 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/main@{#83115} Bug: v8:12007 Change-Id: Ia88ed51a49c62170bc960b8f69673bb1e59a6009 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3888057 Commit-Queue: Patrick Thier <pthier@chromium.org> Reviewed-by:
-
Nico Hartmann authored
This reverts commit 80fb2815. Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1364400 Original change's description: > [turbofan] Rematerialize BigInt64 in deopt > > This CL introduces two MachineTypes - SignedBigInt64 and UnsignedBigInt64, which are represented as Word64 but will be rematerialized to BigInt in deoptimization. This will avoid unnecessary conversions for BigInt64s when they are passed to StateValues. > > Bug: v8:9407 > Change-Id: I65fdee3e028ed8f9920b1c20ff78993c7784de48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3858238 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Qifan Pan <panq@google.com> > Cr-Commit-Position: refs/heads/main@{#83230} Bug: v8:9407 Change-Id: I77d278ce302621db03b787318641709780348cc8 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3901814 Auto-Submit: Nico Hartmann <nicohartmann@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@{#83245}
-
Michael Achenbach authored
A recent refactoring changed the behavior of dropping/keeping results after test execution. The numfuzz loop has previously treated all results as analysis results, as it expected that others are dropped. After keeping all results, the second round invalidated the analysis results and the test loop stopped early. We now add an additional safeguard that ensures the received result is indeed associated with an analysis run and do not depend anymore on result presence/absence. This also adds all analysis-based instances to the test cases. No-Try: true Bug: v8:13295 Change-Id: Ic1ede904d279a0c2b318ec997e7c77542dbc75bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3901812Reviewed-by:
-
Michael Achenbach authored
This improves the num-fuzzer system test. Previously, the test didn't actually start up the main functionality of num-fuzz and executed 0 tests. Now several of the production fuzzers are used to run fake test cases. The overall timeout signal, used to stop numfuzz, is mocked with a counter. The observer signals via the event method that would have caused the hang fixed in: https://crrev.com/c/3891373 No-Try: true Bug: v8:13113 Change-Id: I47d17c1fa2099474079acaad5640228d8c454eb1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3893807Reviewed-by:
-
Marja Hölttä authored
Bug: v8:11111,chromium:1362487 Change-Id: Ifc7649ec945a0cb13e02c52a47f8ab68fa8ab848 Fixed: chromium:1362487 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3890915Reviewed-by:
-
Anton Bikineev authored
Do it conditionally only when young-gen is enabled. Change-Id: I1bd8ed49302b9e2aef0a60ed7831de9ec1cbe276 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899308 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Auto-Submit: Anton Bikineev <bikineev@chromium.org> Reviewed-by:
-
