- 19 Aug, 2022 1 commit
-
-
Shu-yu Guo authored
Currently there is nothing ensuring the internal VM state of shared objects are in a coherent state and visible to other threads when the shared object is published. This CL adds a store-store memory barrier when returning from Factory methods that allocate shared JSObjects that are exposed to user JS code. For primitives, there is an additional store-store memory barrier in the shared value barrier. Bug: v8:12547 Change-Id: I4833c7ebf02cc352da9b006d2732669d6d043172 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng,v8_linux64_tsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819041 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#82596}
-
- 18 Aug, 2022 1 commit
-
-
Stephen Belanger authored
This is a reland of commit 872b7faa Original change's description: > Fix Context PromiseHook behaviour with debugger enabled > > This is a solution for https://github.com/nodejs/node/issues/43148. > > Due to differences in behaviour between code with and without the debugger enabled, some promise lifecycle events were being missed and some extra ones were being added. This change resolves this and verifies the event sequence is consistent between code with and without the debugger. > > Change-Id: I3dabf1dceb14233226b1752083d659f1c2f97966 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779922 > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/main@{#82132} Change-Id: Ifdd407261c793887fbd012d5a04ba36b3744c349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3805979Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#82575}
-
- 17 Aug, 2022 1 commit
-
-
Jakob Linke authored
.. just because it's convenient to see the object type and code kind for short prints. Before: - code: 0x014c00257515 <Other heap object (CODE_DATA_CONTAINER_TYPE)> After: - code: 0x39b7002573b1 <CodeDataContainer MAGLEV> Bug: v8:11880 Change-Id: I02576ffdef509ed021fc5632ea19448387188130 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3826255Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Auto-Submit: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#82518}
-
- 12 Aug, 2022 1 commit
-
-
ishell@chromium.org authored
... to please mksnapshot which expects the new space to be empty. Bug: v8:10470 Change-Id: I7d5b62db138ef2e334581a8697d137cd13291d7c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827877 Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#82440}
-
- 05 Aug, 2022 1 commit
-
-
Brendon Tiszka authored
Bug: chromium:1216437,chromium:1219630,chromium:1309225 Bug: chromium:1311641,chromium:1314616 Change-Id: I1575edbdd7fe91ed970ffe2f3437fd7c514e1ebd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3794525Reviewed-by: Samuel Groß <saelo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Brendon Tiszka <tiszka@chromium.org> Cr-Commit-Position: refs/heads/main@{#82235}
-
- 02 Aug, 2022 2 commits
-
-
Nico Hartmann authored
This reverts commit 872b7faa. Reason for revert: Somewhat speculative revert because of https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/39673/overview (reverting locally resolved the issue for me) Original change's description: > Fix Context PromiseHook behaviour with debugger enabled > > This is a solution for https://github.com/nodejs/node/issues/43148. > > Due to differences in behaviour between code with and without the debugger enabled, some promise lifecycle events were being missed and some extra ones were being added. This change resolves this and verifies the event sequence is consistent between code with and without the debugger. > > Change-Id: I3dabf1dceb14233226b1752083d659f1c2f97966 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779922 > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/main@{#82132} Change-Id: I3e05adead5d8033906055e0741854da68aade2ac No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804859 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#82136}
-
Stephen Belanger authored
This is a solution for https://github.com/nodejs/node/issues/43148. Due to differences in behaviour between code with and without the debugger enabled, some promise lifecycle events were being missed and some extra ones were being added. This change resolves this and verifies the event sequence is consistent between code with and without the debugger. Change-Id: I3dabf1dceb14233226b1752083d659f1c2f97966 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779922Reviewed-by: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#82132}
-
- 28 Jul, 2022 1 commit
-
-
Seth Brenith authored
This is a reland of commit e895b7af The unit test has been updated to work correctly when --stress-incremental-marking is enabled. 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: Id2036dfa4eba8670cac899773d7a906825fa2c50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787266Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#82045}
-
- 25 Jul, 2022 2 commits
-
-
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}
-
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}
-
- 24 Jul, 2022 1 commit
-
-
Omer Katz authored
A couple of allocation were still going to new space. Since objects allocated during isolate initialization are long living anyway, we should pretenure them. This also untangles preallocating pages in the paged new space. Bug: v8:12612 Change-Id: Ib63ff4445930afa5969464e6adaef85b314e95ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782802Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81903}
-
- 22 Jul, 2022 1 commit
-
-
Victor Gomes authored
Update LogicalNot to use same Constant::ToBoolean logic. Bug: v8:7700 Change-Id: Id8f6c1b8fa9bb70489122f35bcee4c88bffc9499 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769691Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#81882}
-
- 18 Jul, 2022 1 commit
-
-
ishell@chromium.org authored
... in order to avoid expensive computation of cage_base for Code objects and in order to avoid issues with wrong cage base values computed from Code objects in external code space. Drive-by: cage-bas'ify some accessors in JSFunction and Code. This is a step towards Code-less embedded builtins. Bug: v8:11880 Change-Id: I95dd8bcd4680e09c7463e1bc7d72dcbf9f2e5c1c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769831Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/main@{#81788}
-
- 23 Jun, 2022 2 commits
-
-
Shu-yu Guo authored
It is an invariant that objects in the shared heap never point into per-Isolate heaps. This is currently broken by DependentCode. At the same time, shared maps and other holders of DependentCode are designed to never invalidate optimized code. E.g., shared maps are effectively immutable. This CL does two things: 1. Prevent shared objects from being depended upon 2. DCHECK that shared objects never cause deoptimization Bug: v8:12547, v8:12761 Change-Id: I0fedae9134a8f786a9200e70f99dba7b38cd2d80 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3704809Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#81340}
-
Marja Hölttä authored
Bug: v8:11111 Change-Id: I2984b3ed6ac6b769f9b4ce758fdf4bfc3b6f6d49 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714661Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#81322}
-
- 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}
-
- 14 Jun, 2022 1 commit
-
-
Igor Sheludko authored
Bug: v8:12965 Change-Id: I16b67335978714f05658f75f7a9a038270dbd69b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702337 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81138}
-
- 10 Jun, 2022 2 commits
-
-
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}
-
Joyee Cheung authored
Adds Module::GetStalledTopLevelAwaitMessage() API which searches for modules that have no pending async dependencies but have not yet resolved. An embedder may call this API when they are about to exit to check if TLA evaluation has stalled and provide a better error message. Change-Id: I3b88802f70cc84c973551f13d73ef3e3d06f4027 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2341765 Commit-Queue: Joyee Cheung <joyee@igalia.com> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#81080}
-
- 08 Jun, 2022 1 commit
-
-
Manos Koukoutos authored
This saves one indirection when fetching the supertype array for type checks. Bug: v8:7748 Change-Id: I41ec5a190c1ccdd9112869c7cdf1748bef4b359a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688405Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#81012}
-
- 31 May, 2022 1 commit
-
-
Leszek Swirski authored
Print polymorphic feedback, and include instance type in printed maps. Change-Id: I34b71fbd5c94a1b615b17646dcd7a729a4ff4eac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3677299Reviewed-by: Igor Sheludko <ishell@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#80837}
-
- 25 May, 2022 1 commit
-
-
Maya Lekova authored
The generated code checks if the receiver is a JS_API_OBJECT and if the receiver requires an access check, and if not it lowers the call to an API call. We also add compilation dependencies on the protector cell to deopt if our invariants change. (Note - the actual invalidation of these cells will be implemented in a follow up CL) Bug: v8:11321 Change-Id: I15722f1e5fac7176e292da4a35186e4609636aba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2719563 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#80748}
-
- 19 May, 2022 1 commit
-
-
Stephen Roettger authored
Bug: chromium:1310790 Change-Id: I739161f47fc1fc32d832f106d5ef6b7df4aed213 Fixed: chromium:1310790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3654096Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Stephen Röttger <sroettger@google.com> Cr-Commit-Position: refs/heads/main@{#80639}
-
- 17 May, 2022 2 commits
-
-
Leszek Swirski authored
Split off a TurbofanFrame from OptimizedFrame, and make MaglevFrame a subclass of OptimizedFrame. This allows it to be treated as an optimized frame by code that is looking at deoptimization data. Bug: v8:7700 Change-Id: Ia38e0f1c2cd73f054f63be81dff187d9197c1202 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644798 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#80592}
-
Marja Hölttä authored
Bug: v8:11111, chromium:1321013 Change-Id: Iec45b885e844ab02059470dd514f47133b0a6efe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3650596Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#80583}
-
- 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}
-
- 06 May, 2022 1 commit
-
-
Peter Kasting authored
This is deprecated in C++20. Use constexprs and explicit casts to work around. Bug: chromium:1284275 Change-Id: I6a3974f3c678cb797081938622036a12a99c5d1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630349 Auto-Submit: Peter Kasting <pkasting@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#80392}
-
- 03 May, 2022 2 commits
-
-
Shu-yu Guo authored
Bug: chromium:1321078 Change-Id: I426327ffc3d7eebdb562c01a87039a93dfb79a88 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620836 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#80349}
-
Rob Paveza authored
This change adds support for computing SHA-256 hashes in the stack output of errors by adding a function to the prototype of the `CallSite` object, passed to `Error.prepareStackTrace`. Additionally, it updates the `hash` property from `Debugger.scriptParsed` and `Debugger.scriptFailedToParse` to be SHA-256 instead of the proprietary hash it is today. It is intended to be an advancement in indexing source maps to support improved tooling, especially for post-hoc or in-production diagnostics scenarios. The explainer can be found here: https://docs.google.com/document/d/13hNeeLC2Ve_FVieNndZUUUP15x2O4ltvjnGWwOsMlrU/edit?usp=sharing Change-Id: Ifbbed4b22c8256e74e6d79974d2dd1e444143eda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229957Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Auto-Submit: Robert Paveza <Rob.Paveza@microsoft.com> Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#80320}
-
- 13 Apr, 2022 1 commit
-
-
Camillo Bruni authored
CacheInitialJSArrayMaps was called in the middle of JSFunction::SetPrototype even though this only happens during bootstrapping given that Array.prototype os non-configurable and non-writable. Changes: - Rename CacheInitialArrayMaps to InitializeJSArrayMaps - Add more explicit checks in InitializeJSArrayMaps to link back to the Context indices for better code searching Change-Id: Iad6d20e3d67d715bfd6429037c75ac35ab7f399f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571889Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#79973}
-
- 06 Apr, 2022 1 commit
-
-
Marja Hölttä authored
Looks like historical leftovers from the time when we had "pixel arrays" and external array elements kinds. See https://codereview.chromium.org/1262583002 Bug: v8:11111 Change-Id: I288d47ae802218737bd6226cbb999c3289d1dbaf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3574548Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#79823}
-
- 30 Mar, 2022 1 commit
-
-
Jakob Gruber authored
.. with readability and simplicity in mind. - Rename OptimizationMarker to the (shorter) TieringState. 'Tiering' also matches 'TieringManager' terminology. - Rename the values: kNone -> kNone kInOptimizationQueue -> kInProgress kCompileFoo_NotConcurrent -> kRequestFoo_Synchronous kCompileFoo_Concurrent -> kRequestFoo_Concurrent - Likewise rename ConcurrencyMode::kNotConcurrent to kSynchronous. - Add predicates to test enum values. - Consistent lower case names for accessors on JSFunction and FeedbackVector. - Instead of having to call HasOptimizationMarker() before using any other accessor, simply have optimization_marker() return kNone if no feedback vector exists. - Drive-by: Enable the Unreachable() in MaybeOptimizeCode() unconditionally - this should never happen, there's no reason not to protect against this in release builds as well. Bug: v8:12161 Change-Id: I67c03e2b7bd0a6b86d0c64f504ad8cb47e9e26ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3555774Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Auto-Submit: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79669}
-
- 25 Mar, 2022 2 commits
-
-
legendecas authored
Implement WrappedFunction properties name/length. Bug: v8:11989 Change-Id: I050af5814537552ef6c2077802ffc726f2e08fa3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3507201Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Chengzhong Wu <legendecas@gmail.com> Cr-Commit-Position: refs/heads/main@{#79628}
-
Igor Sheludko authored
Stores to undeclared global in strict mode should throw ReferenceError. Bug: chromium:1309225 Change-Id: Iac7c55da2ff9c16e488b4fc66408c5300469873e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3553099 Commit-Queue: Igor Sheludko <ishell@chromium.org> Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#79625}
-
- 24 Mar, 2022 2 commits
-
-
Igor Sheludko authored
Bug: chromium:1309225 Change-Id: Ifd62639a2aa18b633e7cf36632677ee16c977afd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548458Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#79613}
-
Joyee Cheung authored
- When the property being defined with DefineKeyedOwnIC or DefineNamedOwnIC already exists, we should use the slow path to check if the operation is allowed in case the property is non-configurable or Object.preventExtensions() has been called on the property. - Since KeyedStoreIC:Store() reuses StoreIC::Store() when the key is a name, we should use Runtime::DefineObjectOwnProperty() for DefineKeyedOwnIC too. - When dealing with public fields, Runtime::DefineObjectOwnProperty() should use JSReceiver::CreateDataProperty() instead of Object::SetProperty() for the specified semantics. This patch also adds JSReceiver::AddPrivateField() for it and StoreIC::Store to define private fields without triggering traps or checking extensibility. - To emit a more specific error message when redefining properties on non-extensible objects, Object::AddDataProperty() now also takes a EnforceDefineSemantics enum to distinguish between set and define. - Drive-by: fix JSReceiver::CheckIfCanDefine() which should check for extensibility even if the configurability check passes. Bug: chromium:1259950, v8:9888 Change-Id: Ib1bc851ffd4b9c3a0e98cac96dafe743c08ee37e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3517934Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#79603}
-
- 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}
-
- 25 Feb, 2022 1 commit
-
-
jameslahm authored
The per-Isolate Symbol tables are implemented using NameDictionary before, which has additional property details overhead And NameDictionary is limited to 2^23, which limits the Symbol tables to be a maximum of 2^23. - replace NameDictionary with SymbolTable in isolate Bug: v8:12575 Change-Id: Ica4f05aac3494f7dfa3a074c240d4ba25df814e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3476897Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#79285}
-
- 23 Feb, 2022 1 commit
-
-
Shu-yu Guo authored
This is a reland of 1025bf26 Changes since revert: - TSAN issue fixed by https://crrev.com/c/3475084 - Skip the shared-struct-workers test until shared GC deadlock is fixed, being tracked in v8:12645 Original change's description: > [shared-struct] Prototype JS shared structs > > Unlike the Stage 1 proposal, for simplicity the prototype does not add > any new syntax, instead opting for exposing a SharedStructType > constructor which takes an array of field names. This type constructor > returns constructors for shared structs. > > Shared structs can be shared across Isolates, are fixed layout, have no > prototype, have no .constructor, and can only store primitives and > other shared structs. > > The initial prototype does not have TurboFan support. > > Bug: v8:12547 > Change-Id: I23bdd819940b42139692bcdb53d372099b0d4426 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3390643 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79156} Bug: v8:12547 Change-Id: Ic1f5cf9fa9791ae2d5d5dc7c110614ca10b5d98e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3475078Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#79215}
-