- 18 Oct, 2021 5 commits
-
-
Victor Gomes authored
This is a reland of 0c459ff5 Original change's description: > [baseline] Concurrent Sparkplug n-thread with synchronised queue > > Installation in the main thread. > Design doc: https://docs.google.com/document/d/1GmEiEt2VDmhY_Ag0PiIcGWKtvQupKgNcMZUvgpfQksk/edit?resourcekey=0-seYa-QJsx1ZbjelluPG1iQ > > Change-Id: Ifc6eccd44efdf377320c64cf9957c6060334e543 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186831 > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77431} Change-Id: I4ea8f3c026a0a448afcb16f57517ee75cedaf83f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229379 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77437}
-
Leszek Swirski authored
This reverts commit 0c459ff5. Reason for revert: breaks build on M1 (where W^X flag is RO) https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release%20builder/6999/overview Original change's description: > [baseline] Concurrent Sparkplug n-thread with synchronised queue > > Installation in the main thread. > Design doc: https://docs.google.com/document/d/1GmEiEt2VDmhY_Ag0PiIcGWKtvQupKgNcMZUvgpfQksk/edit?resourcekey=0-seYa-QJsx1ZbjelluPG1iQ > > Change-Id: Ifc6eccd44efdf377320c64cf9957c6060334e543 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186831 > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77431} Change-Id: I45a952aacf0ad29ebb703a742fdc6da7b0b7c826 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229378 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77433}
-
Victor Gomes authored
Installation in the main thread. Design doc: https://docs.google.com/document/d/1GmEiEt2VDmhY_Ag0PiIcGWKtvQupKgNcMZUvgpfQksk/edit?resourcekey=0-seYa-QJsx1ZbjelluPG1iQ Change-Id: Ifc6eccd44efdf377320c64cf9957c6060334e543 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186831 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#77431}
-
Nico Hartmann authored
This reverts commit 929b83fb. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/18725/overview Original change's description: > [heap] Attach to shared isolate after setting up main thread > > Attach to the shared isolate after the main thread was set up. Otherwise > it could happen that a shared GC initiated from another isolate might > see no threads are running and performs the safepoint operation in the > middle of isolate deserialization. > > We use DisallowSafepoints to check that the isolate doesn't join a > global safepoint before deserialization is complete. DisallowSafepoints > used to prevent only invocations of Safepoint() but was updated to > also prevent Park() and Unpark() invocations. Each state change could > cause the thread to reach a safepoint, which would allow a shared GC > to run. > > We now also DCHECK that every isolate has at least one local heap and > that shared collections aren't started before deserialization is > complete. > > Bug: v8:11708 > Change-Id: Iba3fb59dd951d5ee4fc9934158062287302fc279 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3221157 > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77424} Bug: v8:11708 Change-Id: I0633150b6b40b297a335a39bf1a087ca93592e04 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3225937Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#77425}
-
Dominik Inführ authored
Attach to the shared isolate after the main thread was set up. Otherwise it could happen that a shared GC initiated from another isolate might see no threads are running and performs the safepoint operation in the middle of isolate deserialization. We use DisallowSafepoints to check that the isolate doesn't join a global safepoint before deserialization is complete. DisallowSafepoints used to prevent only invocations of Safepoint() but was updated to also prevent Park() and Unpark() invocations. Each state change could cause the thread to reach a safepoint, which would allow a shared GC to run. We now also DCHECK that every isolate has at least one local heap and that shared collections aren't started before deserialization is complete. Bug: v8:11708 Change-Id: Iba3fb59dd951d5ee4fc9934158062287302fc279 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3221157 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77424}
-
- 13 Oct, 2021 1 commit
-
-
Shu-yu Guo authored
Tip of tree puts both internalized and in-place-internalizable strings into the shared heap object cache. But only internalized strings need to go in there, since we can't have duplicates of those. It's fine to allocate in-place-internalizable strings in the shared heap each time a new Isolate is initialized, it'll be deduplicated if it's internalized eventually. Bug: chromium:1258918, v8:12007 Change-Id: I0e46b73a5ac3be83d0eaa31915a3a24f47a8c2bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3219690 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#77388}
-
- 11 Oct, 2021 2 commits
-
-
Shu-yu Guo authored
When --shared-string-table is passed, in-place-internalizable strings are promoted into the shared old space to maintain the invariant that in-place internalization can be done without copying. Also some drive-by comment fixes and removal of unnecessary 'explicit' on multi-parameter constructors. Bug: v8:12007 Change-Id: I467d865e41934b1d5cdf85cbecc85c4befbfeb21 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193591 Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#77326}
-
Victor Gomes authored
Compiling Sparkplug on the heap saved 10% of the CompileBaseline RCS metric, but that came with too much code complexity. Since in the end that corresponds to < 1% of the entire compilation time, we decided to revert this project. This reverts: commit e29b2ae4 commit d1f2a83b commit 4666e182 commit a1147408 commit e0d4254f commit 9ab8422d commit a3b24ecc commit 1eb87706 commit fe5c9dfd commit 7ac3b55a commit 7e95f30e commit 323b5962 commit 6bf0b704 commit e82b368b commit 5020d83e commit 642a4673 commit ec7b99d5 commit fb4f89ae commit 208854bb commit 63be6dde Bug: v8:12158 Change-Id: I9f2539be6c7d80c6e243c9ab173e3c5bb0dff97d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3136453 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#77319}
-
- 08 Oct, 2021 1 commit
-
-
Shu-yu Guo authored
To prepare for prototyping shared memory features, all internalized and in-place internalizable (1- and 2-byte seq strings and external strings) will always be allocated in the shared old space. Cons strings, thin strings, and sliced strings remain allocated in the thread-local space. They are copied over to the shared space when internalized, as internalization implies flattening, which for these strings requires a copy already. To make the in-place internalization threadsafe, updating the map of such strings is now done with a release store. This CL does not yet support external strings. Bug: v8:12007 Change-Id: I982c35c5120bf4c0c70c5294ce011b47430414c8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140784 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#77308}
-
- 06 Oct, 2021 2 commits
-
-
Igor Sheludko authored
... to support creation of fillers in external code space. Bug: v8:11880 Change-Id: I47b352b8b44733c529b6b0cb2b39cf676ce83923 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208813 Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#77271}
-
Dominik Inführ authored
We are going to introduce safepoints across multiple isolates, with this the name GlobalSafepoint might be misleading. Use IsolateSafepoint as name to emphasise this class reaches a safepoint for a single isolate only. No functional changes. Bug: v8:11708 Change-Id: I8254031dd0bc8e6dcf9f7353297803c37dba47ed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3207901 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#77268}
-
- 28 Sep, 2021 1 commit
-
-
Seth Brenith authored
When preparing to take a heap snapshot for the devtools, V8 uses CollectAllAvailableGarbage, which runs 2 to 7 rounds of garbage collection, depending on whether weak callbacks indicate that further rounds might be beneficial. Depending on how many rounds of GC run, varying amounts of bytecode and baseline code may be flushed, leading to inconsistent behavior and underreporting the amount of memory used by bytecode and baseline code. In this change, I propose that bytecode should not increase in age during these collections, so that the resulting snapshot is a better indication of actual memory usage. Change-Id: I644be37833f85bb58e2e2fad5da62949cbdc9bef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3182885Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77122}
-
- 27 Sep, 2021 2 commits
-
-
Igor Sheludko authored
... an ObjectVisitor subclass that takes care of caching values of both the main pointer compression cage base and code cage base (when the external code space is enabled). Drive-by: this CL also changes signature of RelocInfo::target_object_no_host(...) to accept PtrComprCageBase instead of Isolate*. Bug: v8:11880 Change-Id: I3fbb382e0a0170e28542bc495d8fecfd24da8a07 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3182231 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#77088}
-
Dominik Inführ authored
GCTracer::Scope and GCTracer::Event shadow GarbageCollector's MARK_COMPACTOR, etc. Bug: v8:12244, v8:12245 Change-Id: Ibe60fb03ba35c9a9e057cadc7b8f557d9db9437f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3182226 Auto-Submit: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#77076}
-
- 20 Sep, 2021 1 commit
-
-
Jakob Gruber authored
.. for more efficient access to builtins from generated code. Root-relative accesses tend to be faster and produce more compact code when the root-relative offset is small. IsolateData contains a few large tables (roots, external references, builtins), resulting in very large offsets in general. This CL starts by splitting the builtin table into tiers: tier 0 is a minimal set of perf-critical builtins that should be cheap to access. The offset to tier 0 builtins is guaranteed to be small. The full builtin table also remains in IsolateData for occasions in which we need to lookup builtins by index. In future work, we can also split external references and roots into tiers. On x64, this reduces deopt exit sizes from 7 to 4 bytes and from 12 to 9 bytes (dynamic map checks / EagerWithResume deopts). Bug: v8:12203,v8:8661 Change-Id: I5a9ed22b0e00682aca1abcf15892ae1458dbdd70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162142 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#76947}
-
- 30 Aug, 2021 1 commit
-
-
Victor Gomes authored
It seems like SP on heap does not produce too much memory fragmentation, therefore we do not need UndoLastAllocationAt. Bug: v8:11872 Change-Id: Id2e44405329b52c1dcd6cd81bfc72ffba00035ee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3129428 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#76581}
-
- 24 Aug, 2021 1 commit
-
-
Dan Elphick authored
This is a reland of d1b27019 Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
-
- 23 Aug, 2021 2 commits
-
-
Dan Elphick authored
This reverts commit d1b27019. Reason for revert: Broke vtune build, tsan build and possibly others Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Bug: v8:11965 Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#76428}
-
Dan Elphick authored
This moves every single class/function out of include/v8.h into a separate header in include/, which v8.h then includes so that externally nothing appears to have changed. Every include of v8.h from inside v8 has been changed to a more fine-grained include. Previously inline functions defined at the bottom of v8.h would call private non-inline functions in the V8 class. Since that class is now in v8-initialization.h and is rarely included (as that would create dependency cycles), this is not possible and so those methods have been moved out of the V8 class into the namespace v8::api_internal. None of the previous files in include/ now #include v8.h, which means if embedders were relying on this transitive dependency then it will give compile failures. v8-inspector.h does depend on v8-scripts.h for the time being to ensure that Chrome continue to compile but that change will be reverted once those transitive #includes in chrome are changed to include it directly. Full design: https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing Bug: v8:11965 Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76424}
-
- 30 Jul, 2021 1 commit
-
-
Georg Neis authored
Traces calls to Heap::IsAllocationPending that return true. This is useful when debugging concurrent Turbofan. Bug: v8:7790 Change-Id: If10e6f40c3bf03c768ad8b74403007fe86f860fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060488Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76012}
-
- 29 Jul, 2021 1 commit
-
-
Mythri A authored
Introduce a flush_baseline_code flag to control if baseline code is flushed or not. Currently flush_baseline_code implies flush_bytecode as well. So if flush_baseline_code is enabled both bytecode and baseline code are flushed. If the flag is disabled we only flush bytecode and not baseline code. In a follow-up CL we will add support to control baseline and bytecode flushing independently i.e. we can flush only bytecode / only baseline code / both. Bug: v8:11947 Change-Id: I5a90ed38469de64ed1d736d1eaaeabc2985f0783 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059684 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#76003}
-
- 26 Jul, 2021 1 commit
-
-
Leszek Swirski authored
This is a reland of e24fa913 It fixes the heap verification errors by going back to using MakeThin instead of manually creating a filler (that then makes the verifier think that this was array left-trimming). Original change's description: > [offthread] Template deserializer on Isolate > > Make the deserializer class templated on Isolate/LocalIsolate. This > allows the ObjectSerializer to be split into a main-thread and offthread > variant, with the latter taking a LocalIsolate. > > Eventually, we probably want to anyway split off the code-cache de/serializer > to a separate implementation (for various reasons), and this the only one that > wants off-thread finalization, and at this point the deserializer can revert > back to being un-templated, used only for bootstrapping. However, this is the > simplest way, for now, to enable off-thread deserialization. > > Bug: chromium:1075999 > Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75834} Bug: chromium:1075999 Change-Id: I1d81fad2550a2a9f04dd0f9d8e66422d28faf378 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043960Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#75918}
-
- 23 Jul, 2021 1 commit
-
-
Michael Lippautz authored
This is a reland of 1f0b0ed0 No actual code has changed in the relands. The change was reverted due to triggering flaky failures in WebMediaPlayerImplTest which was not set up properly. The test setup has been fixed in https://crrev.com/c/3025796. Original change's description: > Reland "heap: Fix initial GC configuration for C++-only heaps" > > This is a reland of 7ef67b2e > > Manually checked that the CL was not the culprit breaking > media_blink_unittests --gtest_filter=WebMediaPlayerImplTest.MemDumpReporting > > Original change's description: > > heap: Fix initial GC configuration for C++-only heaps > > > > Heaps in V8 start with a large limit that is shrunk upon young > > generation GCs, based on some liveness estimate. This provides best > > throughput during startup while at the same time finding a reasonable > > first limit. > > > > For C++ (embedder memory) there is no estimate which is why it was > > piggy-backing on V8. This breaks in scenarios where no JS memory is > > allocated. > > > > In this fix we start a memory reducer after embedder memory has hit > > the activation threshold if no GC happened so far. As soon as a single > > Scavenger has happened, we leave it up to the JS estimate to figure > > out a limit. Memory reducing GCs will then find a regular limit based > > on the initial live size. > > > > Drive-by: Give embedders the same activiation threshold of 8MB as JS. > > > > Bug: chromium:1217076 > > Change-Id: I8469696002ac2af8d75d6b47def062d2608387a1 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944935 > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75012} > > Bug: chromium:1217076 > Change-Id: I482d8525379e33095834d5b41be8bb49bdd8a5d4 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949094 > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Auto-Submit: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75048} Bug: chromium:1217076 Change-Id: If920d6b2c54a0c9d67e55e276421e4694eb1414e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960218Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#75894}
-
- 21 Jul, 2021 2 commits
-
-
Nico Hartmann authored
This reverts commit e24fa913. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/18917/overview Original change's description: > [offthread] Template deserializer on Isolate > > Make the deserializer class templated on Isolate/LocalIsolate. This > allows the ObjectSerializer to be split into a main-thread and offthread > variant, with the latter taking a LocalIsolate. > > Eventually, we probably want to anyway split off the code-cache de/serializer > to a separate implementation (for various reasons), and this the only one that > wants off-thread finalization, and at this point the deserializer can revert > back to being un-templated, used only for bootstrapping. However, this is the > simplest way, for now, to enable off-thread deserialization. > > Bug: chromium:1075999 > Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75834} Bug: chromium:1075999 Change-Id: Id699ebe0c17d3a61ec35b0f78417306175271647 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041675Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#75836}
-
Leszek Swirski authored
Make the deserializer class templated on Isolate/LocalIsolate. This allows the ObjectSerializer to be split into a main-thread and offthread variant, with the latter taking a LocalIsolate. Eventually, we probably want to anyway split off the code-cache de/serializer to a separate implementation (for various reasons), and this the only one that wants off-thread finalization, and at this point the deserializer can revert back to being un-templated, used only for bootstrapping. However, this is the simplest way, for now, to enable off-thread deserialization. Bug: chromium:1075999 Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75834}
-
- 20 Jul, 2021 1 commit
-
-
Mythri A authored
This is a reland of ea55438a. Relanding after a fix lands here: https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures were caused because baseline code could be flushed during the process of deoptimization after we choose which entry (InterpreterEnterAt* / BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect baseline code but it could be flushed before we execute the builtin. The fix is to defer the decision. Original change's description: > [sparkplug] Support bytecode / baseline code flushing with sparkplug > > Currently with sparkplug we don't flush bytecode / baseline code of > functions that were tiered up to sparkplug. This CL adds the support to > flush baseline code / bytecode of functions that have baseline code too. > This CL: > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of > JSFunction as a custom weak pointer where the code is treated as weak if > the bytecode corresponding to this function is old. > 2. Updates GC to handle the functions that had a weak code object during > the atomic phase of GC. > 3. Updates the check for old bytecode to also consider when there is > baseline code on the function. > > This CL doesn't change any heuristics for flushing. The baseline code > will be flushed at the same time as bytecode. > > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a > Bug: v8:11947 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75674} Bug: v8:11947 Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75810}
-
- 19 Jul, 2021 1 commit
-
-
Igor Sheludko authored
... for visiting slots containing pointers to Code objects when external code space mode is enabled. These slots will require different handling once the code space is moved out of the V8 heap cage. This CL also introduces IsValidCodeObject() predicate similar to IsValidHeapObject() for checking if given HeapObject is a valid Code object. Tbr: cbruni@chromium.org Bug: v8:11880 Change-Id: I430940f4503cebfd2a6d387e44349810991a93e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3032085Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75787}
-
- 15 Jul, 2021 1 commit
-
-
Michael Lippautz authored
Use a mutex guard when the unprotection is triggered from a compaction space in which case it is actually parallel. Main-thread only unprotection does not require acquiring the mutex. The list itself is only used from the main thread and thus the actual process does not require a mutex. The issue was introduced in https://crrev.com/c/2966382 Bug: v8:11982 Change-Id: I593c0659eb5a96c8206d0b4014f07ab13827be85 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3026705Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#75734}
-
- 12 Jul, 2021 2 commits
-
-
Mythri Alle authored
This reverts commit ea55438a. Reason for revert: Likely culprit for these failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20NumFuzz/15494/overview Original change's description: > [sparkplug] Support bytecode / baseline code flushing with sparkplug > > Currently with sparkplug we don't flush bytecode / baseline code of > functions that were tiered up to sparkplug. This CL adds the support to > flush baseline code / bytecode of functions that have baseline code too. > This CL: > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of > JSFunction as a custom weak pointer where the code is treated as weak if > the bytecode corresponding to this function is old. > 2. Updates GC to handle the functions that had a weak code object during > the atomic phase of GC. > 3. Updates the check for old bytecode to also consider when there is > baseline code on the function. > > This CL doesn't change any heuristics for flushing. The baseline code > will be flushed at the same time as bytecode. > > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a > Bug: v8:11947 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75674} Bug: v8:11947 Change-Id: I50535b9a6c6fc39eceb4f6c0e0c84c55bb92f30a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017811Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75679}
-
Mythri A authored
Currently with sparkplug we don't flush bytecode / baseline code of functions that were tiered up to sparkplug. This CL adds the support to flush baseline code / bytecode of functions that have baseline code too. This CL: 1. Updates the BodyDescriptor of JSFunction to treat the Code field of JSFunction as a custom weak pointer where the code is treated as weak if the bytecode corresponding to this function is old. 2. Updates GC to handle the functions that had a weak code object during the atomic phase of GC. 3. Updates the check for old bytecode to also consider when there is baseline code on the function. This CL doesn't change any heuristics for flushing. The baseline code will be flushed at the same time as bytecode. Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a Bug: v8:11947 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#75674}
-
- 07 Jul, 2021 1 commit
-
-
Dominik Inführ authored
This CL implements GC in a shared heap. A shared GC is started from an attached client isolate that fails to allocate a shared object. In order to perform a shared GC all other running client isolates need to be stopped and their roots need to be scanned. Bug: v8:11708 Change-Id: I45ac50e6b4a1e9270f9e39b69f9b8ee5e6e14134 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964816Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#75606}
-
- 06 Jul, 2021 2 commits
-
-
Dominik Inführ authored
This CL adds support for updating code objects. So far code objects were immutable. Sparkplug makes compilation a very frequent operation and thus wants to avoid copying the instruction stream from the AssemblerBuffer into the code object (with more overhead that entails). The idea is to allocate an "empty" Code object initially, which is likely large enough to hold the full instruction stream. Then Sparkplug will compile the given function and write the instruction stream directly into the code object. After compilation is done Sparkplug trims the Code to the right size and finishes its initialization. We use relocation_info to determine whether a Code object is fully initialized: undefined means that this object is filled by SparkPlug at the moment. If it's a proper ByteArray, this code object is assumed to be initialized. Turbofan still fully initializes the Code object immediately. Before changing the size of the code object, EnsureSweepingCompleted() makes sure that the code object's page is swept already. This prevents that the concurrent sweeper loads the new and smaller object size and stores that memory in the free list. NotifyCodeObjectChanged() signals the GC that the code object is now fully initialized and revisits that object (even if it is black already) to find and record outgoing references in the instruction stream. Design doc: https://docs.google.com/document/d/12LHGkRXY1H3IFMBrdxs2vhgtG9bfJTdquQUsX1oPoSE/edit?usp=sharing Bug: v8:11872 Change-Id: Ie1b95b27842eea5ec7e9d345052585a27d6ea7f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999087 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#75582}
-
Wenyu Zhao authored
This CL make TPH be able to access some heap private interfaces, by marking TPH classes as friend classes. Bug: v8:11641 Change-Id: I72aebf267c8f36593f50279bec5dccb44cda9528 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994220 Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au> Cr-Commit-Position: refs/heads/master@{#75572}
-
- 30 Jun, 2021 2 commits
-
-
Victor Gomes authored
If the object to be trimmed creates a filler object that is located just before the current LAB, then we can immediately give back the memory. Bug: v8:11872, v8:11883 Change-Id: I9ec37443482334003b3752a3f25fc5dcb6a476fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996643Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#75475}
-
Jakob Gruber authored
.. and make JSGlobalObjectRef bg-serialized. GetPropertyCell was implemented as: LookupIterator it(holder, isolate, name, LookupIterator::OWN); it.TryLookupCachedProperty(); if (it.state() == LookupIterator::DATA) it.GetPropertyCell(); Due to concurrency requirements, we essentially have to reimplement this entire path for use in a concurrent setting: - Reads in some cases have to use relaxed or acquire semantics. - The IsPendingAllocation predicate must be called on some objects before reading into them. - Repeated reads of the same field must be avoided due to the possibility of concurrent modifications. This CL introduces two new methods: ConcurrentLookupIterator::TryGetPropertyCell implements the outer lookup logic, including the repeated lookup for accessors / cached property names. GlobalDictionary::TryFindPropertyCellForConcurrentLookupIterator is a slightly modified HashTable::FindEntry which follows the above rules. Bug: v8:7790 Change-Id: Ic9a52da766afdfedce8efcbda92876845a17eed9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2959616Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75467}
-
- 21 Jun, 2021 1 commit
-
-
Igor Sheludko authored
When v8_enable_external_code_space is enabled the Code objects are allowed only - in CodeDataContainer::code field - as uncompressed values embedded in Code instruction streams Bug: v8:11880 Change-Id: I080a678fd77a7e42c6a397e7145a640fd07d6e83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969828Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75275}
-
- 17 Jun, 2021 1 commit
-
-
Dominik Inführ authored
MemoryChunkLayout::MaxRegularCodeObjectSize() can be cached in a global variable on process initialization. This should help to increase code object allocation performance, since this method was called on each code object allocation. Bug: v8:11891 Change-Id: I870bd37202370aec89ef2db24264e363099bf8a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966387 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#75215}
-
- 16 Jun, 2021 2 commits
-
-
Dominik Inführ authored
This mutex wasn't really used anymore. This should also speed up code object allocation a bit. Bug: v8:11888 Change-Id: I8ddc2ecc1aec74e8eb3e2d4b96354c50f3bff350 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966382Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#75185}
-
Igor Sheludko authored
... behind the v8_enable_external_code_space build flag. This is a first CL in a row of CLs that will make CodeDataContainer the only type of objects that could contain references to Code objects (besides the Code objects embedded into the generated code). Eventually these changes will allow us to move Code space out of the V8 heap cage. This CL adds |code| field to ensure that CodeDataContainer keeps the respective Code object alive and |code_entry_point| field that contains cached value of the code().InstructionStart(). Bug: v8:11880 Change-Id: Ie7ce75667d8da306797d203691b429671bc4530d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964093 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75179}
-
- 14 Jun, 2021 1 commit
-
-
Camillo Bruni authored
- Convert Builtin to enum class - Change int-based builtin_index methods to use Builtin - Change Builtins::builtin to Builtins::code Change-Id: Id9e3bb83da97e8894ca7ca78e1e852da60675619 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949104 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75127}
-