- 06 May, 2022 1 commit
-
-
Michael Lippautz authored
- Repurpose flag `treat_global_objects_as_roots` when taking a heap snapshot for toggling whether internals should be exposed (to `hide_internals`). - Use the toggle in creating heap snapshots for exposing class names as object names for C++ objects that have not explicitly been given a name. Change-Id: I77d71babfdfe53269964fe81ed985037a431c28b Bug: chromium:1321620 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623740Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/main@{#80391}
-
- 22 Apr, 2022 1 commit
-
-
Seth Brenith authored
One of the biggest categories in heap snapshots is named “(system)”, which gives developers no indication of why all that memory is used or what they might do to reduce it. In this change, I propose that we create a new category for Maps, DescriptorArrays, and related objects, and call this new category “(object shape)” in the devtools. I think that this category name would be more meaningful, while still grouping those objects together so that they mostly stay out of the way. Bug: v8:12769 Doc: https://docs.google.com/document/d/1a-6V_2LIJuRcsppwh6E18g8OSnC9j6gN4ao2gq--BiU Change-Id: I282a7b87c34ca6ed371ff32f3c7332d794ae42ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3587974Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#80123}
-
- 06 Apr, 2022 1 commit
-
-
Seth Brenith authored
Currently, the category named “(compiled code)” contains Code, SharedFunctionInfo, and Script objects. However, there are various other object types that are allocated per script function, such as BytecodeArray and FeedbackVector. There are also plain FixedArrays which are used for function-specific data such as polymorphic feedback and code deoptimization data. I propose we move all of this to the “(compiled code)” category, because this memory usage is related to the number of functions in the script, the size of those functions, and/or the number of times those functions have been called. Bug: v8:12769 Change-Id: Ib5e0265a9ef88063596c17419f5b65f683156c52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3569876Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#79827}
-
- 05 Feb, 2022 1 commit
-
-
Shu-yu Guo authored
Currently the Isolate is gotten off of the object that the operation is being performed on. Shared objects return the shared Isolate, which is incorrect as it shouldn't be used to run JS, nor does it have HandleScopes open. Plumb the executing Isolate through. Bug: v8:12547 Change-Id: I428d21f5e6a9c51c8c7c4577395bf27c8706bdb4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3441033Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#78963}
-
- 04 Feb, 2022 1 commit
-
-
Seth Brenith authored
The web app owner who notified me about bugs v8:12112 and v8:12126 asked me a reasonable question: "how am I ever supposed to trust the retaining paths in the devtools, if the heap snapshot is generated by a different component than the actual marking code?". This change is my attempt to answer that question. If verification is enabled, the heap snapshot generator will visit each heap object with a realistic marking visitor to find all references from that object. It will then check that those references match the HeapGraphEdges in the snapshot. I also considered the idea that we could collect retaining information during the last GC cycle before taking the heap snapshot, or during an extra GC cycle immediately after. However, running the full GC provides the embedder with the opportunity to run arbitrary code (including JS) both before and after PerformGarbageCollection, so there is no clear guarantee that the heap state during the snapshot actually matches the heap state during marking. Bug: v8:12112, v8:12126 Change-Id: Id29e75ecf9eee19e35daedbdb4a3e1df64785380 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3299590Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#78952}
-
- 16 Dec, 2021 1 commit
-
-
Igor Sheludko authored
This CL * removes Builtins::codet() and Builtins::codet_handle() returning builtins as CodeT objects in favor of code() and code_handle(), * removes BUILTIN_CODET macro in favor of BUILTIN_CODE, * removes CodeDataContainer table. Bug: v8:11880 Change-Id: Ic868549030744b0ff3ea5d5edbfcacf77c6de96d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3344650Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78399}
-
- 29 Nov, 2021 1 commit
-
-
Seth Brenith authored
JSWeakRef and WeakCell both have weak pointers, which should be marked as such in heap profiler snapshots. Bug: v8:12112 Change-Id: Ie7aaa2cd3e44552427679e650e462d64704725d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3299592Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#78133}
-
- 03 Nov, 2021 1 commit
-
-
Igor Sheludko authored
In order to avoid some of the unnecessary Code <-> CodeDataContainer conversions in builtins we need to be able to embed CodeDataContainer references to builtins. This CL makes it possible by introducing a table of builtins' CDCs. Eventually, usages of the builtins table containing Code objects will be replaced by usages of this table. Bug: v8:11880 Change-Id: Iffffd1507d5c7b38af34c42071a4577a8d18e8eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257710Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Auto-Submit: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#77678}
-
- 29 Oct, 2021 1 commit
-
-
Kim-Anh Tran authored
This is a reland of 0e006a15 Difference: * progress_total_ and progress_counter_ access are guarded by checking if control_ is set. If not, we do not report any progress and both are not set. Original change's description: > [heap-snapshot] Preventing overflow in progress counter > > This prevents an overflow to happen in the heap snapshot generator. > Furthermore it changes the relation of progress_counter_ and > progress_total_ to always adhere to: > * progress_counter_ <= progress_total_, > * if: progress_counter_ == progress_total_, then it is done. > > With this change, if progress_counter_ happens to be bigger > than progress_total_ (latter is an estimate), it will continue > to report the same progress (<100%) until it is done. Before, > it would repeatedly report 100% until it is done. > > Fixed: chromium:1246860 > Change-Id: Iffd3f52355632f2b35abdbb3752912ba7b8bd821 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250310 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77589} Bug: chromium:1246860 Change-Id: I7522c1fe011954dd18828bdef507abe3e0237d42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3251170Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77608}
-
- 28 Oct, 2021 2 commits
-
-
Clemens Backes authored
This reverts commit 0e006a15. Reason for revert: MSan failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/41031/overview Original change's description: > [heap-snapshot] Preventing overflow in progress counter > > This prevents an overflow to happen in the heap snapshot generator. > Furthermore it changes the relation of progress_counter_ and > progress_total_ to always adhere to: > * progress_counter_ <= progress_total_, > * if: progress_counter_ == progress_total_, then it is done. > > With this change, if progress_counter_ happens to be bigger > than progress_total_ (latter is an estimate), it will continue > to report the same progress (<100%) until it is done. Before, > it would repeatedly report 100% until it is done. > > Fixed: chromium:1246860 > Change-Id: Iffd3f52355632f2b35abdbb3752912ba7b8bd821 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250310 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77589} Change-Id: I81e8bb563a48ce6b877e83e30a5f426bef0bb58d No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250901 Auto-Submit: Clemens Backes <clemensb@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Owners-Override: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/main@{#77590}
-
Kim-Anh Tran authored
This prevents an overflow to happen in the heap snapshot generator. Furthermore it changes the relation of progress_counter_ and progress_total_ to always adhere to: * progress_counter_ <= progress_total_, * if: progress_counter_ == progress_total_, then it is done. With this change, if progress_counter_ happens to be bigger than progress_total_ (latter is an estimate), it will continue to report the same progress (<100%) until it is done. Before, it would repeatedly report 100% until it is done. Fixed: chromium:1246860 Change-Id: Iffd3f52355632f2b35abdbb3752912ba7b8bd821 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250310Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77589}
-
- 26 Oct, 2021 1 commit
-
-
Kim-Anh Tran authored
A test was overflowing on the progress counter when using int as type. This CL is fixing the progress counter to use uint32_t, and re-enables the test. Why uint32_t instead of size_t? In the referenced bug, the progress_counter_ (but not the progress_total_) triggered an overflow; and since these two counters should be relatively similar (the total count is an estimate, and can be less than the actual progress count), we do not expect the count to increase much more than we can already encode with int. Bug: chromium:1246860 Change-Id: I9769884ef60d352b3787c2223e528ddf33b0b23e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3245116 Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77551}
-
- 27 Sep, 2021 1 commit
-
-
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}
-
- 20 Aug, 2021 1 commit
-
-
Seth Brenith authored
The heap snapshot view in the dev tools reports some incorrect retaining paths involving weak references from relocation data in Code objects. This change updates IndexedReferencesExtractor::VisitEmbeddedPointer to better match the behavior in MarkingVisitorBase. Drive-by cleanup: ObjectVisitor::VisitRelocInfo needn't be virtual because there's only one implementation. Bug: v8:12126 Change-Id: I669a7408e7a46e797b8c2b372235b4ea42ee22e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3107214Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#76406}
-
- 16 Apr, 2021 1 commit
-
-
Arno Renevier authored
- represent smis as fake heap numbers - numbers nodes (both smi and heap numbers) reference a child node whose name is "value" and whose entry is the string representation of that number That feature is disabled by default, and can be enabled by passing captureNumericValue: true when calling HeapProfiler.takeHeapSnapshot This patch slightly refactors some functions that operate on "essential objects". We now check that the object is essential before trying to create the entry. Otherwise, we would end up with smi objects created, but not referenced anywhere. Design doc: https://docs.google.com/document/d/1Qh1zxyn0SS5wzJzitD6ecBJTdFbQkJogSMwxDRsn44o/edit Change-Id: Ibbe6e79a54c4f9eace72bc0a0ccb622a97698e00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806747Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Arnaud Renevier <arenevier@fb.com> Cr-Commit-Position: refs/heads/master@{#73985}
-
- 07 Jan, 2021 1 commit
-
-
Michael Lippautz authored
Previously, for wrapper/wrappable pairs, only JS object size was accounted for. With this change, the C++ part is also accounted for. Change-Id: Ibd945cb28c808d8c01fa41453f94a6de9883b764 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615258Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#71959}
-
- 11 Nov, 2020 1 commit
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I11632ad59ec3826b71e901e0eb34ef6dc1295637 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2524419Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71098}
-
- 26 Oct, 2020 1 commit
-
-
Leszek Swirski authored
Split GlobalObject tagging into collecting pairs of tags, followed by writing those tags into an unordered_map after entering a safepoint scope. This ensures that we follow moved global objects if they move in the GCs between the tagging and the safepoint. Bug: v8:11050 Change-Id: I333d50d000ec49e6c4218e71f0cc84a49b460ecf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2494932 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70749}
-
- 16 Oct, 2020 3 commits
-
-
Michael Lippautz authored
This reverts commit fba14bde. Reland fixes: - const vector<const string> -> const vector<string> Original message: The following implements a snapshotting algorithm for C++ objects that also filters strongly-connected components (SCCs) of only "hidden" objects that are not (transitively) referencing any non-hidden objects. C++ objects come in two versions. a. Named objects that have been assigned a name through NameProvider. b. Unnamed objects, that are potentially hidden if the build configuration requires Oilpan to hide such names. Hidden objects have their name set to NameProvider::kHiddenName. The main challenge for the algorithm is to avoid blowing up the final object graph with hidden nodes that do not carry information. For that reason, the algorithm filters SCCs of only hidden objects, e.g.: ... -> (object) -> (object) -> (hidden) -> (hidden) In this case the (hidden) objects are filtered from the graph. The trickiest part is maintaining visibility state for objects referencing other objects that are currently being processed. Main algorithm idea (two passes): 1. First pass marks all non-hidden objects and those that transitively reach non-hidden objects as visible. Details: - Iterate over all objects. - If object is non-hidden mark it as visible and also mark parent as visible if needed. - If object is hidden, traverse children as DFS to find non-hidden objects. Post-order process the objects and mark those objects as visible that have child nodes that are visible themselves. - Maintain an epoch counter (StateStorage::state_count_) to allow deferring the visibility decision to other objects in the same SCC. This is similar to the "lowlink" value in Tarjan's algorithm for SCC. - After the first pass it is guaranteed that all deferred visibility decisions can be resolved. 2. Second pass adds nodes and edges for all visible objects. - Upon first checking the visibility state of an object, all deferred visibility states are resolved. For practical reasons, the recursion is transformed into an iteration. We do not use plain Tarjan's algorithm to avoid another pass over all nodes to create SCCs. Follow ups: 1. Adding wrapper nodes for cpp objects that are wrappables for V8 wrappers. 2. Adding detachedness information. Bug: chromium:1056170 Change-Id: Ib47df5c912c57d644d052f209276e9d926cece0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480362 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#70577}
-
Maya Lekova authored
This reverts commit 02849fd9. Reason for revert: Breaks Win64 MSVC bot and closes the tree - https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/15416 Original change's description: > cppgc-js: Add snapshot for C++ objects > > The following implements a snapshotting algorithm for C++ objects that > also filters strongly-connected components (SCCs) of only "hidden" > objects that are not (transitively) referencing any non-hidden > objects. > > C++ objects come in two versions. > a. Named objects that have been assigned a name through NameProvider. > b. Unnamed objects, that are potentially hidden if the build > configuration requires Oilpan to hide such names. Hidden objects have > their name set to NameProvider::kHiddenName. > > The main challenge for the algorithm is to avoid blowing up the final > object graph with hidden nodes that do not carry information. For that > reason, the algorithm filters SCCs of only hidden objects, e.g.: > ... -> (object) -> (object) -> (hidden) -> (hidden) > In this case the (hidden) objects are filtered from the graph. The > trickiest part is maintaining visibility state for objects referencing > other objects that are currently being processed. > > Main algorithm idea (two passes): > 1. First pass marks all non-hidden objects and those that transitively > reach non-hidden objects as visible. Details: > - Iterate over all objects. > - If object is non-hidden mark it as visible and also mark parent > as visible if needed. > - If object is hidden, traverse children as DFS to find non-hidden > objects. Post-order process the objects and mark those objects as > visible that have child nodes that are visible themselves. > - Maintain an epoch counter (StateStorage::state_count_) to allow > deferring the visibility decision to other objects in the same > SCC. This is similar to the "lowlink" value in Tarjan's algorithm > for SCC. > - After the first pass it is guaranteed that all deferred > visibility decisions can be resolved. > 2. Second pass adds nodes and edges for all visible objects. > - Upon first checking the visibility state of an object, all deferred > visibility states are resolved. > > For practical reasons, the recursion is transformed into an iteration. > We do not use plain Tarjan's algorithm to avoid another pass over > all nodes to create SCCs. > > Follow ups: > 1. Adding wrapper nodes for cpp objects that are wrappables for V8 > wrappers. > 2. Adding detachedness information. > > Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962 > Bug: chromium:1056170 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854 > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70567} TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org Change-Id: I64a2cf2259bdaed81f6e0f92bdcc7a1f0df4d197 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1056170 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479471Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#70571}
-
Michael Lippautz authored
The following implements a snapshotting algorithm for C++ objects that also filters strongly-connected components (SCCs) of only "hidden" objects that are not (transitively) referencing any non-hidden objects. C++ objects come in two versions. a. Named objects that have been assigned a name through NameProvider. b. Unnamed objects, that are potentially hidden if the build configuration requires Oilpan to hide such names. Hidden objects have their name set to NameProvider::kHiddenName. The main challenge for the algorithm is to avoid blowing up the final object graph with hidden nodes that do not carry information. For that reason, the algorithm filters SCCs of only hidden objects, e.g.: ... -> (object) -> (object) -> (hidden) -> (hidden) In this case the (hidden) objects are filtered from the graph. The trickiest part is maintaining visibility state for objects referencing other objects that are currently being processed. Main algorithm idea (two passes): 1. First pass marks all non-hidden objects and those that transitively reach non-hidden objects as visible. Details: - Iterate over all objects. - If object is non-hidden mark it as visible and also mark parent as visible if needed. - If object is hidden, traverse children as DFS to find non-hidden objects. Post-order process the objects and mark those objects as visible that have child nodes that are visible themselves. - Maintain an epoch counter (StateStorage::state_count_) to allow deferring the visibility decision to other objects in the same SCC. This is similar to the "lowlink" value in Tarjan's algorithm for SCC. - After the first pass it is guaranteed that all deferred visibility decisions can be resolved. 2. Second pass adds nodes and edges for all visible objects. - Upon first checking the visibility state of an object, all deferred visibility states are resolved. For practical reasons, the recursion is transformed into an iteration. We do not use plain Tarjan's algorithm to avoid another pass over all nodes to create SCCs. Follow ups: 1. Adding wrapper nodes for cpp objects that are wrappables for V8 wrappers. 2. Adding detachedness information. Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962 Bug: chromium:1056170 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#70567}
-
- 18 Sep, 2020 1 commit
-
-
Michael Lippautz authored
Fix merging of detachedness state. Drive-by: Split lookup and merging of nodes. Bug: chromium:1110816 Change-Id: I27dba7a6f22c75e5aae130d8cec01ccf755fad79 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416492 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69985}
-
- 09 Sep, 2020 1 commit
-
-
Michael Lippautz authored
Adds a field that can be propagated by embedders. The field holds the detachedness state of DOM objects but can be used in general by embedder to indicate which objects are for sure part of interesting application logic and which objects are not. This field is then processed properly by the DevTools front end. Bug: chromium:1110816 Change-Id: I53a172208cd69ce2ba2ed9524d36b6512aae7d30 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332174Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#69780}
-
- 18 Dec, 2019 1 commit
-
-
Sigurd Schneider authored
This CL adds an argument to the heap profiler that allows to control whether global objects (e.g. 'window' in JavaScript) are treated as roots in the heap snapshot. Doing so hides blink-internal details and is often a good choice when user-JS leaks are investigated. Sometimes, however, this introduces spurious retainer cycles, which are hard to debug. Previously, this option was exposed as a V8 flag. The blink implications of the build-time V8 flag are now available via the new blink flag `enable_additional_blink_object_names`. Tbr: hpayer@chromium.org Bug: chromium:1034504 Change-Id: Ibe9412917ae598a3ff0c3dc956ab0bc179f50a21 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967387Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#65491}
-
- 15 Nov, 2019 1 commit
-
-
Dan Elphick authored
utils.h itself is fairly large and contains lots of unrelated functions as well as having a fair number of dependencies itself, so this splits bounds checking and bit field operations into their own headers in base and replaces uses of utils.h with the more appropriate header where possible. (Also fixes some cases where other headers were previously brought in transitively). Bug: v8:9810, v8:8912 Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64983}
-
- 13 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
After https://crrev.com/c/1800575 and https://crrev.com/c/1803343, which tried to fix this on occuring compile errors, this CL systematically adds the <memory> include to each header that uses {std::unique_ptr}. R=sigurds@chromium.org TBR=mlippautz@chromium.org,alph@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org Bug: v8:9396 Change-Id: If7f9c3140842f9543135dddd7344c0f357999da0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803349Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63767}
-
- 09 Aug, 2019 1 commit
-
-
Michael Lippautz authored
- Adds regular native heap entries to the HeapObjectsMap. - Adds a side map for keeping a mapping of native objects to their canonical heap entry that they have been merged into. Change-Id: Ida00628126ded1948ceb2a0cbe14da817af7f361 Bug: chromium:988350 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720810 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63140}
-
- 29 Jul, 2019 3 commits
-
-
Clemens Hammacher authored
This is a reland of 658ff200 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} Bug: v8:9396, v8:7629 Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62959}
-
Clemens Hammacher authored
This reverts commit 658ff200. Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} TBR=yangguo@chromium.org,clemensh@chromium.org Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9396, v8:7629 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62958}
-
Clemens Hammacher authored
We have hundreds of classes that derive from {BitField} without adding any functionality. This CL switches all such occurrences to 'using' declarations instead. Before: class MyBitField : public BitField<int, 6, 4, MyEnum> {}; After: using MyBitField = BitField<int, 6, 4, MyEnum>; This might reduce compilation time by reducing the number of existing classes. The old pattern is forbidden now by making {BitField} final. R=yangguo@chromium.org Bug: v8:9396, v8:7629 Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62956}
-
- 17 Jun, 2019 1 commit
-
-
Maciej Goszczycki authored
Rename LargeObjectIterator to LargeObjectSpaceObjectIterator. Rename SemiSpaceIterator to SemiSpaceObjectIterator. Rename CombinedHeapIterator to CombinedHeapObjectIterator. Rename ReadOnlyHeapIterator to ReadOnlyHeapObjectIterator. Rename HeapIterator to HeapObjectIterator. Rename HeapObjectIterator to PagedSpaceObjectIterator. Rename PagedSpaces to PagedSpaceIterator. Bug: v8:9183 Change-Id: If4bd65d81e50bb45d207a897baaca8b723e4f10b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645914Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#62217}
-
- 27 May, 2019 1 commit
-
-
Clemens Hammacher authored
This replaces all typedefs that define types and not functions by the equivalent "using" declaration. This was done mostly automatically using this command: ag -l '\btypedef\b' src test | xargs -L1 \ perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg' Patchset 2 then adds some manual changes for typedefs for pointer types, where the regular expression did not match. R=mstarzinger@chromium.org TBR=yangguo@chromium.org, jarin@chromium.org Bug: v8:9183 Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61849}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 23 May, 2019 1 commit
-
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I9bcf2694b449f79cdbe03f5fde59cb21b8cad418 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619758 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#61676}
-
- 27 Mar, 2019 1 commit
-
-
Sigurd Schneider authored
Bug: v8:9020 Change-Id: I851e9a18eab0812e009d323cd98814bebc83f003 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541047 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#60487}
-
- 24 Jan, 2019 1 commit
-
-
Ulan Degenbaev authored
Bug: chromium:749490 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I4ae6883dd5ed5f313e21af20c29e560c73c33675 Reviewed-on: https://chromium-review.googlesource.com/c/948903 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#59076}
-
- 08 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
The two names refer to the same thing by now, so this patch is entirely mechanical. Bug: v8:3770 Change-Id: Ia360c06c89af6b3da27fd21bbcaeb2bdaa28ce22 Reviewed-on: https://chromium-review.googlesource.com/c/1397705Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58615}
-
- 26 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Tbr: ahaas@chromium.org,leszeks@chromium.org,verwaest@chromium.org Bug: v8:3770 Change-Id: Ia6530fbb70dac05e9972283781c3550d8b50e1eb Reviewed-on: https://chromium-review.googlesource.com/c/1390116 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58470}
-
- 20 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Merging the temporary HeapObjectPtr back into HeapObject. Bug: v8:3770 Change-Id: I5bcd23ca2f5ba862cf5b52955dca143e531c637b Reviewed-on: https://chromium-review.googlesource.com/c/1386492 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58410}
-