- 26 Jul, 2022 10 commits
-
-
Victor Gomes authored
Bug: v8:7700 Change-Id: Ie39c1d0bec0ea51839e5ca7c7efac46cab878178 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785304 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81955}
-
Leszek Swirski authored
Avoid allocating dead (zero live range) phis, or their inputs. We should figure out a way to remove them from the graph entirely, e.g. in a separate DCE phase, but for now the easiest thing to do is to skip over them. Note that we can't eliminate them as part of the current node processing pass, since that's the thing that records live ranges in the first place. Bug: v8:7700 Change-Id: I3e7f1f2214100def9ccc2b3f008852d5d69f548f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784985Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81954}
-
Leon Bettscheider authored
This is a reland of commit 6925bc09 Original change's description: > [heap] Refactor methods and nested class of ConcurrentMarkingVisitor > > This CL moves a few methods and nested class SlotSnapshottingVisitor > from ConcurrentMarkingVisitor to ConcurrentMarkingVisitorUtility. > > Methods in ConcurrentMarkingVisitorUtility are now static and instead have a Visitor parameter. > > This is preparatory work for adding a > YoungGenerationConcurrentMarkingVisitor class, which will be able to > reuse members of ConcurrentMarkingVisitorUtility. > > Bug: v8:13012 > Change-Id: I503c20e655578031018a2e37dd92c1d61bbe1686 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779677 > Commit-Queue: Leon Bettscheider <bettscheider@google.com> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81931} Bug: v8:13012 Change-Id: I05063263d831ef4f3e297289e4210850029f7607 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780500Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Leon Bettscheider <bettscheider@google.com> Cr-Commit-Position: refs/heads/main@{#81953}
-
Nikolaos Papaspyrou authored
This CL refactors the mechanism for testing the implementation of inner pointer resolution using the marking bitmap. It allows for more than one page, where objects can be allocated. It also keeps a list of allocated objects that are automatically tested. Bug: v8:12851 Change-Id: I470dc1154aca1ebc3d8526872717747829f83396 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784605Reviewed-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@{#81952}
-
Nikolaos Papaspyrou authored
This CL allows the PagedNewSpace to be used with flag v8_enable_inner_pointer_resolution_osb. Bug: v8:12612 Bug: v8:12851 Change-Id: I63eea4e75398ffec38e562cce245394c0d2a637c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782670Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/main@{#81951}
-
Simon Zünd authored
The intial version of the API was replaced with a more ergonomic one recently. We can also safely remove the test as the new API guarantees that tasks are always finished and cancelled. Bug: chromium:1334585 Change-Id: I9ff8b92fcd73ef821c86de52c40a1d04b15ea918 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780539Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#81950}
-
Leszek Swirski authored
This reverts commit 4e935c7f. Reason for revert: Breaking on mac arm64: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release/10926/overview Original change's description: > [pku][wasm] Refactor PKU usage in Wasm > > RwxMemoryWriteScope becomes the bottleneck for both MAP_JIT and PKU > machinery. > Wasm and V8 code space will use the same memory protection key. > > This is a next step towards adding PKU support for V8 code space. > > Bug: v8:13023 > Change-Id: I647f8c09bc41e5ef8a1d74b58a48a43e08454e0d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702213 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Wenqin Yang <wenqin.yang@intel.com> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81947} Bug: v8:13023 Change-Id: I11c52ac101804ab75b1bb1d4814f083cb1083d5b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780498 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#81949}
-
Samuel Groß authored
This reverts commit efac35f3. Reason for revert: Seems to be causing memory leaks: https://ci.chromium.org/ui/p/chromium/builders/try/linux_chromium_asan_rel_ng/1234545/overview Original change's description: > [sandbox] Sandboxify JSExternalObject external pointer > > Bug: v8:10391 > Change-Id: I6075a8fe3c201f9221149e0c54edf4fb191088da > 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/+/3757342 > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81924} Bug: v8:10391 Change-Id: I8cd64fd0a85182781b04cd1e4619b69dfa512210 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780497 Auto-Submit: Samuel Groß <saelo@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81948}
-
wenqin.yang authored
RwxMemoryWriteScope becomes the bottleneck for both MAP_JIT and PKU machinery. Wasm and V8 code space will use the same memory protection key. This is a next step towards adding PKU support for V8 code space. Bug: v8:13023 Change-Id: I647f8c09bc41e5ef8a1d74b58a48a43e08454e0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702213Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Wenqin Yang <wenqin.yang@intel.com> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#81947}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/d580717..8ec71a4 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/3d8d88e..184bc29 R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com Change-Id: I822b94e47328d55016919ea4e0c320fc4d34d628 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787496 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@{#81946}
-
- 25 Jul, 2022 30 commits
-
-
Deepti Gandluri authored
This reverts commit 6925bc09. Reason for revert: Speculative revert for roll failures: https://ci.chromium.org/ui/p/chromium/builders/try/linux_optional_gpu_tests_rel/85744/overview Original change's description: > [heap] Refactor methods and nested class of ConcurrentMarkingVisitor > > This CL moves a few methods and nested class SlotSnapshottingVisitor > from ConcurrentMarkingVisitor to ConcurrentMarkingVisitorUtility. > > Methods in ConcurrentMarkingVisitorUtility are now static and instead have a Visitor parameter. > > This is preparatory work for adding a > YoungGenerationConcurrentMarkingVisitor class, which will be able to > reuse members of ConcurrentMarkingVisitorUtility. > > Bug: v8:13012 > Change-Id: I503c20e655578031018a2e37dd92c1d61bbe1686 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779677 > Commit-Queue: Leon Bettscheider <bettscheider@google.com> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81931} Bug: v8:13012 Change-Id: If2240b2e0769b04d752caefceb95609c6b950bb2 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787373 Owners-Override: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/main@{#81945}
-
Deepti Gandluri authored
This reverts commit 0609bb83. Reason for revert: Speculative revert for roll fails: https://ci.chromium.org/ui/p/chromium/builders/try/linux_optional_gpu_tests_rel/85744/overview Original change's description: > cppgc: Move forward Trace(T*) deprecation > > Bug: v8:13089 > Change-Id: I271addd3a80feaa40520ab2768a2380c3d7ab62f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780821 > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Anton Bikineev <bikineev@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81939} Bug: v8:13089 Change-Id: Ic9c0389b1b579821f089dddee7e604d81244a108 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785446 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Auto-Submit: Deepti Gandluri <gdeepti@chromium.org> Owners-Override: Deepti Gandluri <gdeepti@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#81944}
-
Deepti Gandluri authored
This reverts commit e895b7af. Reason for revert: TSAN failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/8468/overview Original change's description: > Background merging of deserialized scripts > > Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions > with which an embedder could request that V8 merge newly deserialized > script data into an existing Script from the Isolate's compilation > cache. This change implements those new functions. This functionality is > still disabled by default due to the flag > merge_background_deserialized_script_with_compilation_cache. > > The goal of this new functionality is to reduce memory usage when > multiple frames load the same script with a long delay between (long > enough for the script to have been evicted from Blink's in-memory cache > and for the top-level SharedFunctionInfo to be flushed). In that case, > there are two Script objects for the same script: one which was found in > the Isolate compilation cache (the "old" script), and one which was > recently deserialized (the "new" script). The new script's object graph > is essentially standalone: it may point to internalized strings and > readonly objects such as the empty feedback metadata, but otherwise > it is unconnected to the rest of the heap. The merging logic takes any > useful data from the new script's object graph and attaches it into the > old script's object graph, so that the new Script object and any other > duplicated objects can be discarded. More specifically: > > 1. If the new Script has a SharedFunctionInfo for a particular function > literal, and the old Script does not, then the old Script is updated > to refer to the new SharedFunctionInfo. > 2. If the new Script has a compiled SharedFunctionInfo for a particular > function literal, and the old Script has an uncompiled > SharedFunctionInfo, then the old SharedFunctionInfo is updated to > point to the function_data and feedback_metadata from the new > SharedFunctionInfo. > 3. If any used object from the new object graph points to a > SharedFunctionInfo, where the old object graph contains a matching > SharedFunctionInfo for the same function literal, then that pointer > is updated to point to the old SharedFunctionInfo. > > The document at [0] includes diagrams showing an example merge on a very > small script. > > Steps 1 and 2 above are pretty simple, but step 3 requires walking a > possibly large set of objects, so this new API lets the embedder run > step 3 from a background thread. Steps 1 and 2 are performed later, on > the main thread. > > The next important question is: in what ways can the old script's object > graph be modified during the background execution of step 3, or during > the time after step 3 but before steps 1 and 2? > > A. SharedFunctionInfos can go from compiled to uncompiled due to > flushing. This is okay; the worst outcome is that the function would > need to be compiled again later. Such a risk is already present, > since V8 doesn't keep IsCompiledScopes for every compiled function in > a background-deserialized script. > B. SharedFunctionInfos can go from uncompiled to compiled due to lazy > compilation. This is also okay; the merge completion logic on the > main thread will just keep this lazily compiled data rather than > inserting compiled data from the newly deserialized object graph. > C. SharedFunctionInfos can be cleared from the Script's weak array if > they are no longer referenced. This is mostly okay, because any > SharedFunctionInfo that is needed by the background merge is strongly > referenced and therefore can't be cleared. The only problem arises if > the top-level SharedFunctionInfo gets cleared, so the merge task must > deliberately keep a reference to that one. > D. SharedFunctionInfos can be created if they are needed due to lazy > compilation of a parent function. This change is somewhat troublesome > because it invalidates the background thread's work and requires a > re-traversal on the main thread to update any pointers that should > point to this lazily compiled SharedFunctionInfo. > > At a high level, this change implements three previously unimplemented > functions in BackgroundDeserializeTask (in compiler.cc) and updates one: > > - BackgroundDeserializeTask::SourceTextAvailable, run on the main > thread, checks whether there is a matching Script in the Isolate > compilation cache which doesn't already have a top-level > SharedFunctionInfo. If so, it saves that Script in a persistent > handle. > - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks > whether the persistent handle from the first step exists (a fast > operation which can be called from any thread). > - BackgroundDeserializeTask::MergeWithExistingScript, run on a > background thread, performs step 3 of the merge described above and > generates lists of persistent data describing how the main thread can > complete the merge. > - BackgroundDeserializeTask::Finish is updated to perform the merge > steps 1 and 2 listed above, as well as a possible re-traversal of the > graph if required due to newly created SharedFunctionInfos in the old > Script. > > The merge logic has nothing to do with deserialization, and indeed I > hope to reuse it for background compilation tasks as well, so it is all > contained within a new class BackgroundMergeTask (in compiler.h,cc). It > uses a second class, ForwardPointersVisitor (in compiler.cc) to perform > the object visitation that updates pointers to SharedFunctionInfos. > > [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit > > Bug: v8:12808 > Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#81941} Bug: v8:12808 Change-Id: I82a080e6287828445293cb6b4b94a5e8f15eb8f3 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787213 Auto-Submit: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Deepti Gandluri <gdeepti@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#81943}
-
Frank Tang authored
Also add AOs: ParseTemporalRelativeToString, DefaultTemporalLargestUnit, CalculateOffsetShift, UnbalanceDurationRelative, BalanceDurationRelative, Spec Text: https://tc39.es/proposal-temporal/#sec-temporal.duration.compare https://tc39.es/proposal-temporal/#sec-temporal.duration.prototype.round https://tc39.es/proposal-temporal/#sec-temporal.duration.prototype.total https://tc39.es/proposal-temporal/#sec-temporal-parsetemporalrelativetostring https://tc39.es/proposal-temporal/#sec-temporal-defaulttemporallargestunit https://tc39.es/proposal-temporal/#sec-temporal-calculateoffsetshift https://tc39.es/proposal-temporal/#sec-temporal-unbalancedurationrelative https://tc39.es/proposal-temporal/#sec-temporal-balancedurationrelative Bug: v8:11544 Change-Id: I3b20bdb7cec30f6a8503603169643678988f4dcf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3750322 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/main@{#81942}
-
Seth Brenith authored
Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions with which an embedder could request that V8 merge newly deserialized script data into an existing Script from the Isolate's compilation cache. This change implements those new functions. This functionality is still disabled by default due to the flag merge_background_deserialized_script_with_compilation_cache. The goal of this new functionality is to reduce memory usage when multiple frames load the same script with a long delay between (long enough for the script to have been evicted from Blink's in-memory cache and for the top-level SharedFunctionInfo to be flushed). In that case, there are two Script objects for the same script: one which was found in the Isolate compilation cache (the "old" script), and one which was recently deserialized (the "new" script). The new script's object graph is essentially standalone: it may point to internalized strings and readonly objects such as the empty feedback metadata, but otherwise it is unconnected to the rest of the heap. The merging logic takes any useful data from the new script's object graph and attaches it into the old script's object graph, so that the new Script object and any other duplicated objects can be discarded. More specifically: 1. If the new Script has a SharedFunctionInfo for a particular function literal, and the old Script does not, then the old Script is updated to refer to the new SharedFunctionInfo. 2. If the new Script has a compiled SharedFunctionInfo for a particular function literal, and the old Script has an uncompiled SharedFunctionInfo, then the old SharedFunctionInfo is updated to point to the function_data and feedback_metadata from the new SharedFunctionInfo. 3. If any used object from the new object graph points to a SharedFunctionInfo, where the old object graph contains a matching SharedFunctionInfo for the same function literal, then that pointer is updated to point to the old SharedFunctionInfo. The document at [0] includes diagrams showing an example merge on a very small script. Steps 1 and 2 above are pretty simple, but step 3 requires walking a possibly large set of objects, so this new API lets the embedder run step 3 from a background thread. Steps 1 and 2 are performed later, on the main thread. The next important question is: in what ways can the old script's object graph be modified during the background execution of step 3, or during the time after step 3 but before steps 1 and 2? A. SharedFunctionInfos can go from compiled to uncompiled due to flushing. This is okay; the worst outcome is that the function would need to be compiled again later. Such a risk is already present, since V8 doesn't keep IsCompiledScopes for every compiled function in a background-deserialized script. B. SharedFunctionInfos can go from uncompiled to compiled due to lazy compilation. This is also okay; the merge completion logic on the main thread will just keep this lazily compiled data rather than inserting compiled data from the newly deserialized object graph. C. SharedFunctionInfos can be cleared from the Script's weak array if they are no longer referenced. This is mostly okay, because any SharedFunctionInfo that is needed by the background merge is strongly referenced and therefore can't be cleared. The only problem arises if the top-level SharedFunctionInfo gets cleared, so the merge task must deliberately keep a reference to that one. D. SharedFunctionInfos can be created if they are needed due to lazy compilation of a parent function. This change is somewhat troublesome because it invalidates the background thread's work and requires a re-traversal on the main thread to update any pointers that should point to this lazily compiled SharedFunctionInfo. At a high level, this change implements three previously unimplemented functions in BackgroundDeserializeTask (in compiler.cc) and updates one: - BackgroundDeserializeTask::SourceTextAvailable, run on the main thread, checks whether there is a matching Script in the Isolate compilation cache which doesn't already have a top-level SharedFunctionInfo. If so, it saves that Script in a persistent handle. - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks whether the persistent handle from the first step exists (a fast operation which can be called from any thread). - BackgroundDeserializeTask::MergeWithExistingScript, run on a background thread, performs step 3 of the merge described above and generates lists of persistent data describing how the main thread can complete the merge. - BackgroundDeserializeTask::Finish is updated to perform the merge steps 1 and 2 listed above, as well as a possible re-traversal of the graph if required due to newly created SharedFunctionInfos in the old Script. The merge logic has nothing to do with deserialization, and indeed I hope to reuse it for background compilation tasks as well, so it is all contained within a new class BackgroundMergeTask (in compiler.h,cc). It uses a second class, ForwardPointersVisitor (in compiler.cc) to perform the object visitation that updates pointers to SharedFunctionInfos. [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit Bug: v8:12808 Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#81941}
-
Michael Achenbach authored
No-Try: true Bug: v8:13107 Change-Id: I18ed93605594c7d2baba6fb744439df0eb4cb3ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785146 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/main@{#81940}
-
Michael Lippautz authored
Bug: v8:13089 Change-Id: I271addd3a80feaa40520ab2768a2380c3d7ab62f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780821 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/main@{#81939}
-
Tobias Tebbi authored
Bug: v8:10470 Change-Id: I67e1962c17caecdf7cd9e8ac64ce7e4c0d694a21 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776693Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#81938}
-
jameslahm authored
... api/api-wasm-unittest. Bug: v8:12781 Change-Id: I6d6eafcbc67e114fc1fa9b1f1f8dea21ab831ee6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3748165Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#81937}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/be25fb2..d580717 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/a4506d5..af18ab7 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/0ca99b7..3d8d88e R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com Change-Id: Idfaaa0c7c941d19b623af4f69db6b67a051f9a1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785204 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@{#81936}
-
Michael Achenbach authored
Bug: v8:13101 Change-Id: I1fbcfd5758e3fb739b79c7d381e62b380cd14a2c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784227Reviewed-by: Liviu Rau <liviurau@chromium.org> Auto-Submit: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/main@{#81935}
-
Leszek Swirski authored
Jump gap moves (for phis and register merges) are emitted as a parallel move (i.e. treated as a single mapping from registers to registers and emitted in a way that they don't clobber each other). However, the phi input allocation was updating the register state as if they were serialised moves (i.e. a list of moves, one after the other, where each move could clobber another move's input). Now the jump phi initialisation doesn't update register state. Bug: v8:7700 Change-Id: Iecf3211d59d9c416a4449aea22fef633717d92d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784983Reviewed-by: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81934}
-
Milad Fa authored
Change-Id: I7f618657b7cdaeb3870bd1f743c485ac58b17c56 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782490 Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Reviewed-by: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/main@{#81933}
-
ishell@chromium.org authored
It's not allowed to call CodeLookupResult::ToCodeT() from the middle of GC. Bug: v8:13100, v8:11880 Change-Id: Idd53794a9f881d01dbf0c372fbb698dbd8fecf94 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785009Reviewed-by: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81932}
-
Leon Bettscheider authored
This CL moves a few methods and nested class SlotSnapshottingVisitor from ConcurrentMarkingVisitor to ConcurrentMarkingVisitorUtility. Methods in ConcurrentMarkingVisitorUtility are now static and instead have a Visitor parameter. This is preparatory work for adding a YoungGenerationConcurrentMarkingVisitor class, which will be able to reuse members of ConcurrentMarkingVisitorUtility. Bug: v8:13012 Change-Id: I503c20e655578031018a2e37dd92c1d61bbe1686 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779677 Commit-Queue: Leon Bettscheider <bettscheider@google.com> Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#81931}
-
Leszek Swirski authored
This reverts commit c3f18ae6. Reason for revert: Speculative revert for https://luci-milo.appspot.com/ui/inv/build-8807661142690641489/test-results?q=conformance%2Fogles%2FGL%2FgreaterThanEqual%2FgreaterThanEqual_001_to_008.html Original change's description: > Reland "cppgc: Enable pointer compression by default on Desktop" > > - The data race on atomic memcpying/memsetting was fixed; > - All the known alignment issues in Blink were fixed; > - Several perf optimizations were applied. > > Original change's description: > > cppgc: Enable pointer compression by default on Desktop > > > > The CL enables pointer compression in Oilpan. > > > > For sherrifs: the CL may cause some slight perf regressions (likely > > blink_perf.*), due to slightly higher cost of compression and > > decomrpession. > > > > Speedometer2 is not expected to regress, as was checked locally. Such a > > slight performance degradation is compensated by memory savings that are > > expected to be around 10-20% of Oilpan committed size (~2.5-5% of Renderer > > PMF). > > Bug: chromium:1325007 > Change-Id: I5fa9a06cb1fa5141f4e2b22e710007e2404a176b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762567 > Auto-Submit: Anton Bikineev <bikineev@chromium.org> > Commit-Queue: Anton Bikineev <bikineev@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81914} Bug: chromium:1325007 Change-Id: I15baa011500a2156871277c644a004b9cacfd5f4 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783991 Owners-Override: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#81930}
-
Leszek Swirski authored
This reverts commit 60e9b503. Reason for revert: Speculative revert for https://luci-milo.appspot.com/ui/inv/build-8807661142690641489/test-results?q=conformance%2Fogles%2FGL%2FgreaterThanEqual%2FgreaterThanEqual_001_to_008.html Original change's description: > cppgc: Consistently treat sentinel pointer as live > > Sentinel pointers would be treated as live by the GC (through > `HandleWeak()` but would be treated as dead when checked explicitly > through the `LivenessBroker` in e.g. custom callbacks. > > Treat sentinel pointers as live consistently across all callsites > and weak types. > > Change-Id: I9a4c096ddac1a111df808f3683325b55e7597eea > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782800 > 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@{#81916} Change-Id: Ic1ea0655499ae2e4ae7252fda7158d809e4970ca No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783992 Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81929}
-
jameslahm authored
... objects/weaksets-unittest. Bug: v8:12781 Change-Id: I355deaff33e4bfe7125af587654cae39f2d719d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784616Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#81928}
-
Leszek Swirski authored
We update RegisterMerge information for DoubleRegister, but don't actually emit the gap moves for them. This required templatifying some more code on the register type, and exposing a general LoadToRegister for ValueNode. Bug: v8:7700 Change-Id: I7122b5c562bab20d8f912936ff150d15b9cc033f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3785003 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81927}
-
Leszek Swirski authored
Too often, maglev has an issue during graph building. These are hard to debug, because failing to build a graph means that no graph can be printed. This patch adds a tracing printer that dumps out nodes as they are added to the graph -- it doesn't have the beautiful unicode arrows, but at least it's something. Bug: v8:7700 Change-Id: Id6673a9ee2436eac365d6d449dd2fa49bdc354d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780527Reviewed-by: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81926}
-
Jakob Kummerow authored
a.k.a. "option 1a". Reflects the resolution of this discussion: https://github.com/WebAssembly/function-references/issues/44 Bug: v8:7748 Change-Id: I6b53c353a1ace2aaf5b852addead51b9f76c9d64 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782674Reviewed-by: Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#81925}
-
Samuel Groß authored
Bug: v8:10391 Change-Id: I6075a8fe3c201f9221149e0c54edf4fb191088da 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/+/3757342 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#81924}
-
Clemens Backes authored
The new method is not implemented in Chrome or Node, and the issue has no activity since 2018, so let's rip out the incomplete new API. Drive-by: Sprinke a few V8_LIKELY and V8_UNLIKELY. R=mlippautz@chromium.org Bug: chromium:634547 Change-Id: I0dabad520d459277d7196fa69c1bbceaf4d53596 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780528Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#81923}
-
jameslahm authored
... including LogMapsCodeTest.LogMapsDetailsCode, LogMapsTest.LogMapsDetailsStartup and LogMapsTest.LogMapsDetailsContexts. Bug: v8:12997 Change-Id: I9dc315d7361efb8c58bf7ad3be8e324cdd456184 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784617Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#81922}
-
Victor Gomes authored
Bug: v8:7700 Change-Id: Ibd40e7bf3f0681f358bb2ed0785fce9a50f8b617 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784599Reviewed-by: Jakob Linke <jgruber@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#81921}
-
Clemens Backes authored
Sometimes the second Wasm instantiation fails because we run out of memory. This raises a RangeError, which is not recognized by ClusterFuzz as OOM. Thus turn it into a proper OOM crash. R=ahaas@chromium.org Bug: chromium:1347024 Change-Id: I39f7789cc85a9ba9b4217764fbbcef15c6c6ed76 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784602Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#81920}
-
Omer Katz authored
Whenever PagedNewSpace allocates a page, the page is added to the free list. Preallocating pages on space initialization means the pages are added to the free list before the map for free space is initialized. Then, when allocating from the free list, a DCHECK fails (free-list.cc:508). This CL delays page preallocation until `EnsureCurrentCapacity` is called. When using PagedNewSpace, we will call this method from `Heap::CreateHeapObjects` after the maps are allocated and before any allocations in new space are attempted. Bug: v8:12612 Change-Id: I33f825ddd831640b12e4c0f7b849262a335df51e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780541Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/main@{#81919}
-
Michael Achenbach authored
Bug: v8:13101 Change-Id: I5d144939b420957eab58ead64836b561bd541a00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784601 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Liviu Rau <liviurau@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Cr-Commit-Position: refs/heads/main@{#81918}
-
Victor Gomes authored
Bug: v8:7700 Change-Id: Ib3325ff8f764f7a3bd6c064a5ad301c384503d99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784594 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81917}
-
Michael Lippautz authored
Sentinel pointers would be treated as live by the GC (through `HandleWeak()` but would be treated as dead when checked explicitly through the `LivenessBroker` in e.g. custom callbacks. Treat sentinel pointers as live consistently across all callsites and weak types. Change-Id: I9a4c096ddac1a111df808f3683325b55e7597eea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782800 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@{#81916}
-