- 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}
-
- 05 Jul, 2022 1 commit
-
-
Luis Fernando Pardo Sixtos authored
Atomics.load, Atomics.store, and Atomics.exchange now accept shared array objects as their 1st argument. Currently these are implemented in C++ and not yet in CSA. Bug: v8:12547 Change-Id: I54ed8816a696a4f45dda964739b1cfd917d39dc0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3723974Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com> Cr-Commit-Position: refs/heads/main@{#81537}
-
- 31 May, 2022 1 commit
-
-
Joyee Cheung authored
This reverts commit 07e11a64. Reason for revert: caused regressions and heap verification failures Bug: chromium:1330410, chromium:1330408, chromium:1330413 Original change's description: > [heap] pre-populate the single_character_string_cache > > This simplifies the code and removes the runtime overhead of > spontaneously adding strings to the cache. > > Bug: v8:12718 > Change-Id: I2ed49bd82e3baf2563eeb8f463be72c0308c52c5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616553 > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Joyee Cheung <joyee@igalia.com> > Cr-Commit-Position: refs/heads/main@{#80803} Bug: v8:12718 Change-Id: I569fea9e34effd57c9e7c65190cf5b4ec0b0623b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3679680 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#80870}
-
- 30 May, 2022 1 commit
-
-
Joyee Cheung authored
This simplifies the code and removes the runtime overhead of spontaneously adding strings to the cache. Bug: v8:12718 Change-Id: I2ed49bd82e3baf2563eeb8f463be72c0308c52c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616553Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#80803}
-
- 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}
-
- 21 Feb, 2022 1 commit
-
-
Camillo Bruni authored
- Avoid lookup if there is no template_weakmap yet - More explicit DisallowGarbageCollection scopes - Avoid handles when settings properties - Speed up Object::GetSimpleHash by loading only instance_type once Change-Id: Ib588607340a0c56dc1ba26c3e89485560222a688 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3463717Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#79189}
-
- 16 Feb, 2022 1 commit
-
-
Camillo Bruni authored
- Simplify HeapObject::IsArrayList check - Dehandlify ArrayList initialization - Prevent auto-formatting of v8heapconst.py Change-Id: I9849ad82dae1a2dc671433e8d5eb8ec63ed830c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3447906Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Auto-Submit: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79114}
-
- 07 Feb, 2022 1 commit
-
-
Thibaud Michaud authored
- Suspender.suspendOnReturnedPromise expects a function with type [ti*]->[externref] and returns a function with the same type. - Suspender.returnPromiseOnSuspend expects a function with type [ti*]->[to] and returns a function with type [ti*]->[externref]. Changes: - Check the wrapped function's return types - Skip type checking of return types when importing a wrapper (and assert that the return type is externref) - Add special case for WebAssembly.Function.type of a WasmExportedFunction: it currently returns the signature declared by the module. Change the return type to externref if this is a stack-switching export. Bug: v8:12191 Change-Id: I6619c306e9613825ad1b021cb3400d73cd684656 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3435190Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/main@{#78973}
-
- 18 Nov, 2021 1 commit
-
-
Jakob Gruber authored
Prior to this CL we regularly generated high counts of code dependencies, and installation was not the most efficient. This CL 1) implements early dependency deduplication and 2) simplifies the way dependencies are persisted on the heap through DependentCode. Re 1): we dedupe twice, once based on the CompilationDependency contents, and again once we know the final target object. Re 2): Instead of a linked list of weak fixed arrays per dependency group, store deps in a flat array together with a bitset of their dependency groups. See also: https://docs.google.com/document/d/1B34S1s3Iv6hbquZ93RugD0b-ZKfHEptJ8Fk_YyOvjDk/edit Bug: v8:12195,v8:12397 Change-Id: I9ab47f6d87b10558194b5de30a36b1122f7e362a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283074Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77969}
-
- 20 Oct, 2021 1 commit
-
-
Jakob Gruber authored
Change-Id: I4ed4d0c53a90af4a8d3a58fa3f418576aadd09c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234195 Commit-Queue: Patrick Thier <pthier@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#77464}
-
- 19 Oct, 2021 1 commit
-
-
Jakob Gruber authored
Large character classes may easily be created when unicode properties (e.g.: /\p{L}/u and /\P{L}/u) are used - these are expanded internally into character classes that consist of hundreds of character ranges. Previously to this CL, we'd emit branching code for each of these ranges, leading to very large regexp code objects. This CL adds a new codegen mode for large character classes (where 'large' currently means > 16 ranges). Instead of emitting branching code inline, the ranges are written into a ByteArray and we call into the C function IsCharacterInRangeArray for the actual branching logic. The ByteArray is smaller than emitted code and is deduplicated if the same character class is matched repeatedly in the same pattern. Note this mode is *not* implemented for the interpreter, since we currently don't have a constant pool for irregexp bytecode, and thus cannot reference ByteArrays. Bug: v8:11069 Change-Id: I2d728e42d85114b796c637f791848731a104cd54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229377Reviewed-by:
Patrick Thier <pthier@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77463}
-
- 13 Oct, 2021 1 commit
-
-
Camillo Bruni authored
Due to caching issues we will not be able to store host-defined options directly on the Script anymore. ScriptOrModule can thus no longer be a i::Script. NodeJS keeps weak references from ScriptOrModule to their import meta data. This CL changes ScriptOrModule to be a temporary struct which has a different lifetime. As a temporary fix until the API is fully updated we introduce the v8_scriptormodule_legacy_lifetime compile-time flag. It keeps references to ScriptOrModule alive on the Script to restore the previous behavior (at an additional memory cost). Bug: chromium:1244145 Change-Id: I1dc42d25930d7bc4f22ee3c9bba93d89425be406 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211575 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#77382}
-
- 23 Jul, 2021 1 commit
-
-
Vicky Kontoura authored
This CL adds support for classes with methods. More specifically: - A new ValueSerializer is added and classes are serialized separetely from functions, although the common parts are handled in the same way and abstracted away. - The function prototype is serialized as an object and any missing information is set up again during deserialization. - FunctionFlagsToFunctionKinds() is updated to allow for more function kinds. - Context serialization is updated to support serializing BlockContexts and creating ScopeInfos of type CLASS_SCOPE. - Map serialization is updated to support properties with custom attributes. Bug: v8:11525, v8:11706 Change-Id: I16ca7cbc17b1811721081cda05124ce36073f9be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3006416 Commit-Queue: Vicky Kontoura <vkont@google.com> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#75893}
-
- 12 Jun, 2021 1 commit
-
-
Marja Hölttä authored
Drive-by: Also add deferred function references. Bug: v8:11525 Change-Id: If546f2e6c5a991372f1b99dac149504941a24b3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2951731 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#75110}
-
- 10 Jun, 2021 1 commit
-
-
Marja Hölttä authored
This allows forward references among objects as well as contexts referencing objects. Bug: v8:11525 Change-Id: I45fd132344c5e0125d8287c668eac444fe1f8802 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2947408Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#75069}
-
- 17 May, 2021 1 commit
-
-
Santiago Aboy Solanes authored
This ends up cleaning up the last of the macros in object-macros which were using `synchronized_`. There are still a few methods which use `synchronized_` but those were defined ad-hoc (i.e. w/o macros). Bug: v8:7790 Change-Id: Ib2d35030fd032293e746c09e10156e526af8d032 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897085Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74589}
-
- 10 May, 2021 1 commit
-
-
Santiago Aboy Solanes authored
It was never stored with a release store, so can we use the loads as non-atomic ones. Bug: v8:7790 Change-Id: Iaf91c0c431d557d74f80f243a0dbdaf9adc5e622 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880540 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74471}
-
- 06 Apr, 2021 1 commit
-
-
Shu-yu Guo authored
This is a reland of e28dadc2 The original failure was due to a stale Win32 bot. The reland failure was due to idempotent task deduplication returning the exact same failure. See crbug/1196064 Original change's description: > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > Currently, IsolateRoot is both the address of the Isolate root and the > base address of the pointer compression reservation. This CL teases the > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > - In addition to V8_COMPRESS_POINTERS, add a > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > aliases to GetPtrComprCageBase. > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > Bug: v8:11460 > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Auto-Submit: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73790} Bug: v8:11460 No-Try: true Tbr: ishell@chromium.org Tbr: rmcilroy@chromium.org Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#73795}
-
- 05 Apr, 2021 4 commits
-
-
Shu-yu Guo authored
This reverts commit 15c78b45. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32277/overview Original change's description: > Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" > > This is a reland of e28dadc2 > > Relanding to see if Win32 rel failures from > https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview > were infra flakes. Could not repro on try bots. > > Original change's description: > > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > > > Currently, IsolateRoot is both the address of the Isolate root and the > > base address of the pointer compression reservation. This CL teases the > > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > > > - In addition to V8_COMPRESS_POINTERS, add a > > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > > aliases to GetPtrComprCageBase. > > > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > No-Try: true > Bug: v8:11460 > Tbr: ishell@chromium.org > Tbr: rmcilroy@chromium.org > Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73792} Bug: v8:11460 Change-Id: Ifee92d622c43a91c15f45ef94ff739237bd2024b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806545 Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#73793}
-
Shu-yu Guo authored
This is a reland of e28dadc2 Relanding to see if Win32 rel failures from https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview were infra flakes. Could not repro on try bots. Original change's description: > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > Currently, IsolateRoot is both the address of the Isolate root and the > base address of the pointer compression reservation. This CL teases the > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > - In addition to V8_COMPRESS_POINTERS, add a > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > aliases to GetPtrComprCageBase. > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> No-Try: true Bug: v8:11460 Tbr: ishell@chromium.org Tbr: rmcilroy@chromium.org Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#73792}
-
Francis McCabe authored
This reverts commit e28dadc2. Reason for revert: failed test262 tests;; see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/steps?succeeded=true&debug=false Original change's description: > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > Currently, IsolateRoot is both the address of the Isolate root and the > base address of the pointer compression reservation. This CL teases the > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > - In addition to V8_COMPRESS_POINTERS, add a > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > aliases to GetPtrComprCageBase. > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > Bug: v8:11460 > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Auto-Submit: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73790} Bug: v8:11460 Change-Id: I19d0e28194fcdb28e89f129a7694ca3fe29fa17a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806168 Auto-Submit: Francis McCabe <fgm@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/master@{#73791}
-
Shu-yu Guo authored
Currently, IsolateRoot is both the address of the Isolate root and the base address of the pointer compression reservation. This CL teases the two uses apart by renaming IsolateRoot to PtrComprCageBase. - In addition to V8_COMPRESS_POINTERS, add a V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). - Rename GetIsolate* helpers to GetPtrComprCageBase. When V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as aliases to GetPtrComprCageBase. - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. Bug: v8:11460 Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 Commit-Queue: Shu-yu Guo <syg@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#73790}
-
- 24 Feb, 2021 1 commit
-
-
Jakob Gruber authored
Upcoming CLs will need atomic accessors for non-smi values. This CL adds the full set of relaxed and acquire/release indexed accessors, and I also take the opportunity to update the old `synchronized_set(i, v)` style to `set(i, v, ReleaseStoreTag)`. Bug: v8:7790 Change-Id: Ic4fa4ec52319ec943415f0e9ae515a00b04cbbc3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2717305 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72995}
-
- 20 Nov, 2020 1 commit
-
-
Leszek Swirski authored
Because of LocalHeap safepoints, our existing assert scopes don't necessarily maintain the same guarantees as desired. In particular, DisallowHeapAllocation no longer guarantees that objects don't move. This patch transitions DisallowHeapAllocation to DisallowGarbageCollection, to ensure that code using this scope is also protected against safepoints. Change-Id: I0411425884f6849982611205fb17bb072881c722 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71319}
-
- 10 Nov, 2020 1 commit
-
-
Georg Neis authored
This is a reland of 3b6f7802. The compilation failures due to call-by-reference have been fixed. Original change's description: > [cleanup] Replace more uses of Min/Max by std::min/max > > Bug: v8:11074 > Change-Id: I94d53ea0aac123459ae60fc61748fedf0faac2f4 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2521147 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Auto-Submit: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71022} Bug: v8:11074 Change-Id: Ia01bfd014e481d3a13b306974f6837a65391b19c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2527064 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#71072}
-
- 09 Nov, 2020 2 commits
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I1cbe60d9e9adc7f7836aceda6cb864f2245c7a45 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2525545Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71031}
-
Zhi An Ng authored
This reverts commit 3b6f7802. Reason for revert: Build failure https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20full%20debug/14666 Original change's description: > [cleanup] Replace more uses of Min/Max by std::min/max > > Bug: v8:11074 > Change-Id: I94d53ea0aac123459ae60fc61748fedf0faac2f4 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2521147 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Auto-Submit: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71022} TBR=neis@chromium.org,zhin@chromium.org,mslekova@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:11074 Change-Id: Id6c50bd9ba4132e83f4eecec9e23c6c15e2d787b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2524412Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71026}
-
- 07 Nov, 2020 1 commit
-
-
Georg Neis authored
Bug: v8:11074 Change-Id: I94d53ea0aac123459ae60fc61748fedf0faac2f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2521147Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#71022}
-
- 28 Oct, 2020 1 commit
-
-
Tobias Tebbi authored
This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
-
- 07 Oct, 2020 1 commit
-
-
Leszek Swirski authored
Introduce an IsolateRoot class, which encapsulates the root address needed for pointer decompression. This class is implicitly constructible from both Isolate* and LocalIsolate*, allowing us to avoid templating methods that can take both, or awkwardly creating a `const Isolate*` from a `LocalIsolate*` just for getters. Change-Id: I6d4b9492409fc7d5b375162e381192cb48c8ba01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440605 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70365}
-
- 25 Sep, 2020 1 commit
-
-
Tobias Tebbi authored
This is a reland of 64caf2b0 Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} Bug: v8:7793 TBR: hpayer@chromium.org jgruber@chromium.org Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70137}
-
- 22 Sep, 2020 2 commits
-
-
Francis McCabe authored
This reverts commit 64caf2b0. Reason for revert: Seems to be causing a failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809? Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} TBR=jgruber@chromium.org,tebbi@chromium.org Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70065}
-
Tobias Tebbi authored
This is to establish a naming rule for Torque-generated files: - If the file is called foo/bar-tq..., then it is derived from a file foo/bar.tq - Otherwise it doesn't belong to a specific .tq file. So far, we attached -tq to all Torque-generated file names, where it sometimes corresponded to a .tq file name and sometimes not. It is not necessary to add -tq to file names to indicate that they are Torque-generated, since they are already in a directory called torque-generated, and we always refer to them as "torque-generated/filename", so there is no confusion even though some files now have the same name as a corresponding hand-written file, for example factory.cc. TBR: hpayer@chromium.org Bug: v8:7793 Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70060}
-
- 10 Sep, 2020 1 commit
-
-
Sathya Gunasekaran authored
The dynamic map checks operator loads the feedback vector and performs map checks against each map and handler entry in the feedback against the incoming map and handler. Instead of emitting code to iterate over this feedback vector at runtime, we unroll this loop at compile time. The generated code is similar to this pseudocode: length = feedback_slot.length if length >= 4: goto labels[3] if length == 3: goto labels[2] if length == 2: goto labels[1] if length == 1: goto labels[0] labels[3]: map = load(feedback_slot, 6) if incoming_map == map goto handler_check(7) goto labels[2] labels[2]: map = load(feedback_slot, 4) if incoming_map == map goto handler_check(5) goto labels[1] labels[1]: map = load(feedback_slot, 2) if incoming_map == map goto handler_check(3) goto labels[0] labels[0]: map = load(feedback_slot, 0) if incoming_map == map goto handler_check(1) bailout handler_check (index): handler = load(feedback_slot, index) if incoming_handler == handler goto done deoptimize Bug: v8:10582, v8:9684 Change-Id: I64d64ff8eda664e4d476bf1b2612e26a344e98a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339960 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69797}
-
- 06 Aug, 2020 1 commit
-
-
Leszek Swirski authored
Changes the isolate's string table into an off-heap structure. This allows the string table to be resized without allocating on the V8 heap, and potentially triggering a GC. This allows existing strings to be inserted into the string table without requiring allocation. This has two important benefits: 1) It allows the deserializer to insert strings directly into the string table, rather than having to defer string insertion until deserialization completes. 2) It simplifies the concurrent string table lookup to allow resizing the table inside the write lock, therefore eliminating the race where two concurrent lookups could both resize the table. The off-heap string table has the following properties: 1) The general hashmap behaviour matches the HashTable, i.e. open addressing, power-of-two sized, quadratic probing. This could, of course, now be changed. 2) The empty and deleted sentinels are changed to Smi 0 and 1, respectively, to make those comparisons a bit cheaper and not require roots access. 3) When the HashTable is resized, the old elements array is kept alive in a linked list of previous arrays, so that concurrent lookups don't lose the data they're accessing. This linked list is cleared by the GC, as then we know that all threads are in a safepoint. 4) The GC treats the hash table entries as weak roots, and only walks them for non-live reference clearing and for evacuation. 5) Since there is no longer a FixedArray to serialize for the startup snapshot, there is now a custom serialization of the string table, and the string table root is considered unserializable during weak root iteration. As a bonus, the custom serialization is more efficient, as it skips non-string entries. As a drive-by, rename LookupStringExists_NoAllocate to TryStringToIndexOrLookupExisting, to make it clearer that it returns a non-string for the case when the string is an array index. As another drive-by, extract StringSet into a separate header. Bug: v8:10729 Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69270}
-
- 22 Jul, 2020 1 commit
-
-
Nico Hartmann authored
This CL makes the ScriptContextTable concurrently accessible from the background thread (in particular ScriptContextTable::get_context). A cctest is added to check synchronization with tsan. Bug: v8:7790 Change-Id: I2e2dc8c6a7cfa369787959c4d5ed5f357f4720fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260567Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#68979}
-
- 09 Jul, 2020 1 commit
-
-
Jakob Kummerow authored
By introducing a globally known map for each generic type. These maps are never used to allocate objects, they only serve as sentinels for generic heap types. Bug: v8:7748 Change-Id: I950a8c712dc1510759a833fe9122b9e9a6222dc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288860 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68755}
-
- 10 Jun, 2020 1 commit
-
-
Santiago Aboy Solanes authored
This CL adds a linear search test in a DescriptorArray in a known flat object in the background thread, while the main thread exercises the same DescriptorArray. Also sets the foundation for the follow-ups tests in background threads. Bug: v8:7790 Change-Id: I0e99508204808baaf605161d2eeb717eabe712fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207147 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#68299}
-
- 11 May, 2020 1 commit
-
-
Seth Brenith authored
This CL is pretty mechanical; I just iterated through some Torque classes making the following changes: - Use @generateCppClass if it seems easy to - Use @generatePrint if the existing printer doesn't do anything special - Fix up any imprecise field types It also includes two minor changes to implementation-visitor: - Add a new -inl.h file with the things needed for torque-generated/class-definitions-tq.cc so we don't need to keep changing the compiler when we add @generateCppClass. - Avoid emitting incorrect accessors for ExternalPointers. This isn't strictly necessary for correctness, as the accessors defined in C++ already hide the ones inherited from generated code, but it makes me feel safer. Change-Id: I4d5a8ba6f86ebff57a0d147619212a3993b087c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2185824Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#67719}
-