- 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}
-
- 10 Jun, 2021 2 commits
-
-
Sathya Gunasekaran authored
This reverts commit 1f0b0ed0. Reason for revert: still crashing https://ci.chromium.org/ui/p/chromium/builders/try/android-marshmallow-arm64-rel/877258/test-results 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: Ia409d7a3a22127af749cff5eb5db1ff508b969e4 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2951468 Auto-Submit: Sathya Gunasekaran <gsathya@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@{#75068}
-
Daoming Qiu authored
It adjusts V8 page size for performance reasons. The main use case is improving Node.js performance. The design doc is at:https://docs.google.com/document/d/1CO8Q0YZKJ3QKFRTk-aoJzmSFsuI8ALYQLtsjqLzyi-0/edit?usp=sharing Change-Id: Ie037d405a7116ccd986131d22d417b86ccf6a899 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2860840Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> Cr-Commit-Position: refs/heads/master@{#75063}
-
- 09 Jun, 2021 3 commits
-
-
Dominik Inführ authored
IsPendingAllocation will now load the space from the object's page header first and then only check the object against the current LAB of that particular space. Previously we were looking up that object in the LABs of all spaces. This new design also makes it feasible to have one dedicated mutex for original_top/original_limit (respectively pending_object) for each space. This will reduce contention on the mutexes. Change-Id: I8e7636410259fd03b7970084bfbbaeadb2d8ba61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2936606 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#75054}
-
Michael Lippautz authored
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}
-
Maya Lekova authored
This reverts commit 7ef67b2e. Reason for revert: Speculative revert for a blocked roll - https://chromium-review.googlesource.com/c/chromium/src/+/2947365 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: Ic1530162e846c2a767ea5ea902a01a21967d8e35 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2947419 Auto-Submit: Maya Lekova <mslekova@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@{#75034}
-
- 08 Jun, 2021 1 commit
-
-
Michael Lippautz authored
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/+/2944935Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#75012}
-
- 07 Jun, 2021 2 commits
-
-
Dominik Inführ authored
Prepare method by taking an object as argument. In the future we can optimize this method by only sweeping the object's page. Bug: v8:11837 Change-Id: Ife1ee7949bfaf590dcc305cc4d03aa1813c07b76 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940888Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#74963}
-
Michael Lippautz authored
This aids debugging as it gives the root set a name. Bug: chromium:1164553, chromium:1186901 Change-Id: I2c2aed369823b059629b35bb170b4966b47156d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933661 Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#74960}
-
- 02 Jun, 2021 1 commit
-
-
Patrick Thier authored
Instead of compiling a function with baseline immediately when the interrupt budget is hit, we compile functions in batches to save some memory protection flips on code pages. This CL introduces batch compilation behind --baseline-batch-compilation (enabled on future) and adds a flag --baseline-batch-compilation-threshold to control the size of batches. Bug: v8:11790 Change-Id: I3efc360424a14e4b07c6570e48860509ae59e591 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891656Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#74913}
-
- 31 May, 2021 1 commit
-
-
Victor Gomes authored
We must ensure that the sweeper is not running or has already swept mutable_double_buffer. Otherwise the GC can add it to the free list. Bug: v8:11837 Change-Id: Ifd9cf15f1c94f664fd6489c70bb38b59730cdd78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928181 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#74859}
-
- 27 May, 2021 3 commits
-
-
Dominik Inführ authored
The counter as size_t can legitimately overflow on 32-bit systems, since decreasing the counters is performed after all backing stores were freed on a background thread. Before sweeping is finished a new backing store could already be allocated which then leads to the overflow. Bug: v8:11788, chromium:1211437 Change-Id: Id9f3e58b0e84e831fe47109f7deb3a05ae7e489c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922242 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74836}
-
Dominik Inführ authored
Field isn't used in V8 anymore. Change-Id: I564cfb30250e45cface0b6bdfd1390a458385bac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922243 Auto-Submit: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74821}
-
Dominik Inführ authored
Use a read-write lock for protecting original_top, original_limit and pending_object for all spaces. This way Heap::IsPendingAllocation is always guaranteed to read a consistent top/limit-pair and also the last values for those fields. The main thread will acquire an exclusive lock to update those fields. Concurrent Turbofan threads will use shared locks to read them. This may be quite expensive on the Turbofan-side, so landing this CL should help us figure out how big of a regression this simple fix would be. For main thread execution performance is supposed to be okay, since this is only used on the allocation slow path. Bug: v8:11778, chromium:1213266 Change-Id: I9464f53fd50057ec2540ab5b79f74ee52a5d7500 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903143 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74814}
-
- 17 May, 2021 1 commit
-
-
Santiago Aboy Solanes authored
Continuing the cleanups and using the tags rather than synchronized_ in the name of the accessors. `map_word` (and its setter) can also be marked explicitly as relaxed to show that they are atomic accessors. Bug: v8:7790 Change-Id: I0725054ef37022c777f47660cb11cf839bb7f273 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897094Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74605}
-
- 14 May, 2021 1 commit
-
-
Shu-yu Guo authored
This is a reland of 8b74fd45 Changes since revert: - Reverted a61aa491 for not fixing the jitless toggling issue on Chromium Win64 - Fix jitless toggling on Win64 by checking FLAG_jitless in EmbeddedDataWithMaybeRemappedEmbeddedBuiltins Original change's description: > Reland^3 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64"" > > This is a reland of 054ff044 > > Change since revert: > > - Remove assignment to FLAG_enable_short_builtins in test since > it's write-once in CFI. > > Original change's description: > > Reland^2 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64" > > > > This is a reland of 1f504c36 > > > > Changes since revert: > > > > - Removed disabling of RO heap sharing when --stress-snapshot is passed; > > was fixed by f4a6c628 > > - Fixed crashing tests that caused revert separately in > > a61aa491 > > > > Original change's description: > > > > [ptr-cage] Turn on shared pointer cage by default for arm64 and x64 > > > > > > > > Reviewed-on: > > > https://chromium-review.googlesource.com/c/v8/v8/+/2873226 > > > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > > > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#74422} > > > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878855 > > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > > > Reviewed-by: Adam Klein <adamk@chromium.org> > > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > > Reviewed-by: Dan Elphick <delphick@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#74448} > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891460 > > Reviewed-by: Adam Klein <adamk@chromium.org> > > Commit-Queue: Shu-yu Guo <syg@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#74546} > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2893567 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74548} TBR=ishell@chromium.org Bug: v8:11460 Change-Id: Ied925de5f886a906b1ca178365aee73155e679cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891697Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74560}
-