AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
27b8ad2077
v8/tools/v8heapconst.py

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

527 lines
23 KiB
Python
Raw Normal View History

Remove always-true --harmony-symbol-description runtime flag It shipped in Chrome 70. Bug: v8:7807, v8:8562 Change-Id: I5c5a9fc23656018ee6e9115af7a0c779230e681b Reviewed-on: https://chromium-review.googlesource.com/c/1450787 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#59589}
2019-02-14 10:00:15 +00:00
# Copyright 2019 the V8 project authors. All rights reserved.
[tools] Improve grokdump.py - Add new address markers: T: tagged pointer in the minidump C: address into a module in the minidump S: pointer into the exception stack in the minidump *: other address in the minidump - Show ASCII decoding of address in dd - Display potential frame markers on the exception stack: 00000032212fdae8: 0000000300000000 ........ Smi(3) EXIT frame marker - Display relative addresses, useful to detect stack frames: 00000032212fdb68: 00000032212fdb98 S ........ [+6]=00000032212fdcb0 S 00000032212fdb70: 0000010ff5ca0a84 ........ 00000032212fdb78: 000001064c1fa881 ........ 00000032212fdb80: 0000016a8e52fcb1 ........ 00000032212fdb88: 0000010ff5ca0981 ........ 00000032212fdb90: 0000000d00000000 ........ Smi(13) INTERNAL frame marker 00000032212fdb98: 00000032212fdcb0 S ........ [+35]=00000032212fdd61 S Change-Id: I56bd7e6723a34bcb668719246dd5ff2898224928 Reviewed-on: https://chromium-review.googlesource.com/461862 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#44269}
2017-03-30 11:44:00 +00:00
# Use of this source code is governed by a BSD-style license that can
# be found in the LICENSE file.
Generate grokdump constants with 'make grokdump' now. R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/21771002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16022 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-08-02 09:02:02 +00:00
Introduce mkgrokdump to update tools/v8heapconst.py. - Migrate make grokdump to GYP and GN - Move code from d8 into stand-alone execution - Add test case to ensure it's up-to-date Review-Url: https://codereview.chromium.org/2809653003 Cr-Original-Original-Commit-Position: refs/heads/master@{#44687} Committed: https://chromium.googlesource.com/v8/v8/+/0cc0c130fa56f129c90c2a74cb01bda85df5e42a Review-Url: https://codereview.chromium.org/2809653003 Cr-Original-Commit-Position: refs/heads/master@{#44710} Committed: https://chromium.googlesource.com/v8/v8/+/477f00557458d383bd9ebef281890ba485ee882a Review-Url: https://codereview.chromium.org/2809653003 Cr-Commit-Position: refs/heads/master@{#44738}
2017-04-20 06:14:53 +00:00
# This file is automatically generated by mkgrokdump and should not
# be modified manually.
Generate grokdump constants with 'make grokdump' now. R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/21771002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16022 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-08-02 09:02:02 +00:00
# List of known V8 instance types.
INSTANCE_TYPES = {
Update heap constants R=ishell@chromium.org BUG= Review-Url: https://codereview.chromium.org/2590923002 Cr-Commit-Position: refs/heads/master@{#41865}
2016-12-20 15:26:08 +00:00
0: "INTERNALIZED_STRING_TYPE",
2: "EXTERNAL_INTERNALIZED_STRING_TYPE",
[grokdump] Update grokdump to decode new map layouts, and dump-heap-constants to 512kb pages BUG= Change-Id: I5e60705764b8ea20b171981cdd44d57a928fa34d Reviewed-on: https://chromium-review.googlesource.com/461178 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#44188}
2017-03-28 08:44:17 +00:00
8: "ONE_BYTE_INTERNALIZED_STRING_TYPE",
10: "EXTERNAL_ONE_BYTE_INTERNALIZED_STRING_TYPE",
Revert "[objects] Remove uncached internal external string type" This reverts commit b3d09001eb012ebf75816f5be51a2b1db47e55f2. Reason for revert: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 has to be reverted, and this was a follow-up to that Original change's description: > [objects] Remove uncached internal external string type > > We shouldn't be creating those anymore since they are not thread-safe. > > Bug: v8:7790 > Change-Id: I4546d995fa32eb076c8dfe9d95301fad719c9e07 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615347 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72006} TBR=rmcilroy@chromium.org,leszeks@chromium.org,solanes@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7790 Change-Id: I4eb1a6b8446fa602eeb5bf29fbf1fe57182cdbf3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2627605 Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72122}
2021-01-14 15:12:09 +00:00
18: "UNCACHED_EXTERNAL_INTERNALIZED_STRING_TYPE",
26: "UNCACHED_EXTERNAL_ONE_BYTE_INTERNALIZED_STRING_TYPE",
[cleanup] Remove obsolete "one byte data hint" for strings. In the early days of Chrome when we used WebKit there was no support for ASCII strings on the C++ side, so we put a hint onto these two-byte strings that said "string only contains one byte data", such that internally in V8 when these were involved in string operations, we could instead create the *cheaper* one byte strings. Nowadays Blink properly supports one-byte string representations and this additional hint only comes with overhead, since we check it in quite a few places (i.e. on the hot path for string concatenation), plus we end up consuming more memory due to the additional string maps. Removing the hint also frees one bit in the InstanceType zoo for strings. This alone improves performance on the `bench-dom-serialize.js` test case by around **3%**. Tbr: mstarzinger@chromium.org Bug: v8:6622, v8:8834, v8:8939 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Change-Id: I0753f2859cee7b5a37b6f0da64d8ec39fcb044ff Doc: https://bit.ly/fast-string-concatenation-in-javascript Reviewed-on: https://chromium-review.googlesource.com/c/1498478 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#60006}
2019-03-04 12:55:22 +00:00
32: "STRING_TYPE",
33: "CONS_STRING_TYPE",
34: "EXTERNAL_STRING_TYPE",
35: "SLICED_STRING_TYPE",
37: "THIN_STRING_TYPE",
40: "ONE_BYTE_STRING_TYPE",
41: "CONS_ONE_BYTE_STRING_TYPE",
42: "EXTERNAL_ONE_BYTE_STRING_TYPE",
43: "SLICED_ONE_BYTE_STRING_TYPE",
45: "THIN_ONE_BYTE_STRING_TYPE",
50: "UNCACHED_EXTERNAL_STRING_TYPE",
58: "UNCACHED_EXTERNAL_ONE_BYTE_STRING_TYPE",
Revert recent ConsString-related changes We see crashes in the wild that we suspect are caused by these changes. This is a manual revert because of conflicts. Revert "[turbofan] Fix incorrect CheckNonEmptyString lowering." This reverts commit b3b7011867cf2f2d50a509b03e39c54fe0e213e0. Revert "[turbofan] Fix incorrect lowering of CheckNonEmptyString." This reverts commit 5758209026018a9ca573be234580077ad5974824. Revert "[turbofan] Significantly improve ConsString creation performance." This reverts commit d6a60a0ee1921213320ecb4555e5d463406a4ab7. Bug: v8:9147 Change-Id: I262c21e5406a9c4c8ad0e0f995582c5802f0fa1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571613 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60919}
2019-04-18 09:29:49 +00:00
64: "SYMBOL_TYPE",
[torque] Generate instance types Design doc: https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit Changes from the design doc: - Changed to use 'class' declarations rather than 'type' declarations for things that need instance types but whose layout is not known to Torque. These declarations end with a semicolon rather than having a full set of methods and fields surrounded by {}. If the class's name should not be treated as a class name in generated output (because it's actually a template, or doesn't exist at all), we use the standard 'generates' clause to declare the most appropriate C++ class. - Removed @instanceTypeName. - @highestInstanceType became @highestInstanceTypeWithinParentClassRange to indicate a semantic change: it no longer denotes the highest instance type globally, but only within the range of values for its immediate parent class. This lets us use it for Oddball, which is expected to be the highest primitive type. - Added new abstract classes JSCustomElementsObject and JSSpecialObject to help with some range checks. - Added @lowestInstanceTypeWithinParentClassRange so we can move the new classes JSCustomElementsObject and JSSpecialObject to the beginning of the JSObject range. This seems like the least-brittle way to establish ranges that also include JSProxy (and these ranges are verified with static assertions in instance-type.h). - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue. - Renamed @instanceTypeFlags to @reserveBitsInInstanceType. This change introduces the new annotations and adds the ability for Torque to assign instance types that satisfy those annotations. Torque now emits two new macros: - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the InstanceType enumeration - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String parts of INSTANCE_TYPE_LIST The design document mentions a couple of other macro lists that could easily be replaced, but I'd like to defer those to a subsequent checkin because this one is already pretty large. Bug: v8:7793 Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64258}
2019-10-11 21:52:06 +00:00
65: "BIG_INT_BASE_TYPE",
66: "HEAP_NUMBER_TYPE",
Revert recent ConsString-related changes We see crashes in the wild that we suspect are caused by these changes. This is a manual revert because of conflicts. Revert "[turbofan] Fix incorrect CheckNonEmptyString lowering." This reverts commit b3b7011867cf2f2d50a509b03e39c54fe0e213e0. Revert "[turbofan] Fix incorrect lowering of CheckNonEmptyString." This reverts commit 5758209026018a9ca573be234580077ad5974824. Revert "[turbofan] Significantly improve ConsString creation performance." This reverts commit d6a60a0ee1921213320ecb4555e5d463406a4ab7. Bug: v8:9147 Change-Id: I262c21e5406a9c4c8ad0e0f995582c5802f0fa1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571613 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60919}
2019-04-18 09:29:49 +00:00
67: "ODDBALL_TYPE",
[torque] improve GC visitors Summary of changes: - GC visitors no longer rely on superclass visitors, but instead visit everything themselves. This enables generating better code. - Try to match simple body descriptors to reduce the amount of generated code. - Turn SizeFor(instance) into an AllocatedSize() method. - Remove the special handling of resizable object sizes from Torque and instead overwrite AllocatedSize in classes that need special handling in C++. - Split the visitor id lists depending on whether the class has pointer fields. - Turn Torque-generated body descriptors into an .inc file to simplify includes. - Fix generated size functions to properly align the size. - Generate GC visitors (and C++ class definitions) for all string classes and FixedArray, WeakFixedArray, and WeakArrayList. - Store generated instance types in Torque class types. This is only used to determine if a type has a single instance type in this CL. Bug: v8:7793 Change-Id: I4d362e96b047c305bd6d065247734957b8958c42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110014 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67542}
2020-05-04 12:50:30 +00:00
68: "ABSTRACT_INTERNAL_CLASS_SUBCLASS1_TYPE",
69: "ABSTRACT_INTERNAL_CLASS_SUBCLASS2_TYPE",
[object] Remove MutableHeapNumber Since the mutability of HeapNumbers is determined by their owning object's descriptor array, we can remove the MutableHeapNumber type entirely, at the cost of a few fewer DCHECKs and a couple of TODOs to use the descriptor array information. This is a necessary step towards a follow-up which allows in-place Double -> Tagged transitions Design doc: https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/ Bug: v8:9606 Change-Id: I13209f9c86f1f204088f6fd80089e17d956b4a50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743972 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63294}
2019-08-20 13:24:13 +00:00
70: "FOREIGN_TYPE",
Reland: [wasm-gc] Implement rtt.sub Relanding without changes, revert reason was fixed by: https://chromium-review.googlesource.com/c/v8/v8/+/2272564 Originally reviewed at: https://chromium-review.googlesource.com/c/v8/v8/+/2260566 Original description: RTTs are internally represented as Maps. To store supertype information, this patch introduces a WasmTypeInfo object, which is installed on Wasm objects' Maps and points at both the off-heap type information and the parent RTT. In this patch, rtt.sub always creates a fresh RTT. The canonicalization that the proposal requires will be implemented later. Bug: v8:7748 Change-Id: I7fd4986efa3153ac68037ec418ea617f3f7636e8 Tbr: ulan@chromium.org Tbr: tebbi@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2273123 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#68581}
2020-06-29 14:15:41 +00:00
71: "WASM_TYPE_INFO_TYPE",
72: "PROMISE_FULFILL_REACTION_JOB_TASK_TYPE",
73: "PROMISE_REJECT_REACTION_JOB_TASK_TYPE",
74: "CALLABLE_TASK_TYPE",
75: "CALLBACK_TASK_TYPE",
76: "PROMISE_RESOLVE_THENABLE_JOB_TASK_TYPE",
77: "LOAD_HANDLER_TYPE",
78: "STORE_HANDLER_TYPE",
79: "FUNCTION_TEMPLATE_INFO_TYPE",
80: "OBJECT_TEMPLATE_INFO_TYPE",
81: "ACCESS_CHECK_INFO_TYPE",
82: "ACCESSOR_INFO_TYPE",
83: "ACCESSOR_PAIR_TYPE",
84: "ALIASED_ARGUMENTS_ENTRY_TYPE",
85: "ALLOCATION_MEMENTO_TYPE",
86: "ALLOCATION_SITE_TYPE",
87: "ARRAY_BOILERPLATE_DESCRIPTION_TYPE",
88: "ASM_WASM_DATA_TYPE",
89: "ASYNC_GENERATOR_REQUEST_TYPE",
90: "BREAK_POINT_TYPE",
91: "BREAK_POINT_INFO_TYPE",
92: "CACHED_TEMPLATE_OBJECT_TYPE",
93: "CALL_HANDLER_INFO_TYPE",
94: "CLASS_POSITIONS_TYPE",
95: "DEBUG_INFO_TYPE",
96: "ENUM_CACHE_TYPE",
97: "FEEDBACK_CELL_TYPE",
98: "FUNCTION_TEMPLATE_RARE_DATA_TYPE",
99: "INTERCEPTOR_INFO_TYPE",
100: "INTERPRETER_DATA_TYPE",
Plumb import assertions through SourceTextModuleDescriptor's ModuleRequestMap This change plumbs import assertions from SourceTextModuleDescriptor's ModuleRequestMap into SourceTextModuleInfo via a new ModuleRequest type, where previously there had been only the specifier. SourceTextModuleDescriptor::module_map now deduplicates module requests using the specifier and the import assertions. Continuing to use the specifier alone would cause a loss of information in the event that a module imports from the same specifier multiple times using different sets of assertions. Failing to deduplicate at all would result in multiple requests for statements like `import {a,b,c} from "foo.js"`, which would be a potential performance issue. See design doc at https://docs.google.com/document/d/1yuXgNHSbTAPubT1Mg0JXp5uTrfirkvO1g5cHHCe-LmY for more detail on this decision. v8::internal::ModuleRequest holds the assertions as an array of the form [key1, value1, position1, key2, value2, assertion2, ...]. However the parser still needs to use a map, since duplicate assertion keys need to be detected at parse time. A follow-up change will ensure that assertions are sorted using a proper lexicographic sort. Bug: v8:10958 Change-Id: Iff13fb9a37d58fc1622cd3cce78925ad2b7a14bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493060 Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#71066}
2020-11-09 22:59:00 +00:00
101: "MODULE_REQUEST_TYPE",
102: "PROMISE_CAPABILITY_TYPE",
103: "PROMISE_REACTION_TYPE",
104: "PROPERTY_DESCRIPTOR_OBJECT_TYPE",
105: "PROTOTYPE_INFO_TYPE",
[literals] Add a dedicated regexp boilerplate type ... and mark it as never-serialized wrt turbofan serialization. Until this CL, the JSRegExp type was used as both for plain user-visible regexp objects, and for internal regexp boilerplate descriptions. Boilerplates are special: they are never exposed to the user, they are only referenced from the feedback vector, they are immutable. To clarify this distinction, this CL introduces a dedicated struct type RegExpBoilerplateDescription to hold the regexp boilerplate description. This makes Turbofan serialization simpler: boilerplates can be accessed through direct reads since they are immutable. TF has no special requirements on JSRegExp objects (it never reads into these objects) and thus serializing only the references as a JSObjectRef is fine. Bug: v8:7790 Change-Id: I33b337fcfcf861a02bc6be6d0c6311d07cf05718 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656257 Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@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@{#72522}
2021-02-02 08:43:28 +00:00
106: "REG_EXP_BOILERPLATE_DESCRIPTION_TYPE",
107: "SCRIPT_TYPE",
108: "SOURCE_TEXT_MODULE_INFO_ENTRY_TYPE",
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
109: "STACK_TRACE_FRAME_TYPE",
110: "TEMPLATE_OBJECT_DESCRIPTION_TYPE",
111: "TUPLE2_TYPE",
112: "WASM_EXCEPTION_TAG_TYPE",
113: "WASM_EXPORTED_FUNCTION_DATA_TYPE",
114: "WASM_INDIRECT_FUNCTION_TABLE_TYPE",
115: "WASM_JS_FUNCTION_DATA_TYPE",
116: "FIXED_ARRAY_TYPE",
117: "HASH_TABLE_TYPE",
118: "EPHEMERON_HASH_TABLE_TYPE",
119: "GLOBAL_DICTIONARY_TYPE",
120: "NAME_DICTIONARY_TYPE",
121: "NUMBER_DICTIONARY_TYPE",
122: "ORDERED_HASH_MAP_TYPE",
123: "ORDERED_HASH_SET_TYPE",
124: "ORDERED_NAME_DICTIONARY_TYPE",
125: "SIMPLE_NUMBER_DICTIONARY_TYPE",
126: "CLOSURE_FEEDBACK_CELL_ARRAY_TYPE",
127: "OBJECT_BOILERPLATE_DESCRIPTION_TYPE",
128: "SCRIPT_CONTEXT_TABLE_TYPE",
129: "BYTE_ARRAY_TYPE",
130: "BYTECODE_ARRAY_TYPE",
131: "FIXED_DOUBLE_ARRAY_TYPE",
132: "INTERNAL_CLASS_WITH_SMI_ELEMENTS_TYPE",
133: "SCOPE_INFO_TYPE",
134: "SLOPPY_ARGUMENTS_ELEMENTS_TYPE",
135: "AWAIT_CONTEXT_TYPE",
136: "BLOCK_CONTEXT_TYPE",
137: "CATCH_CONTEXT_TYPE",
138: "DEBUG_EVALUATE_CONTEXT_TYPE",
139: "EVAL_CONTEXT_TYPE",
140: "FUNCTION_CONTEXT_TYPE",
141: "MODULE_CONTEXT_TYPE",
142: "NATIVE_CONTEXT_TYPE",
143: "SCRIPT_CONTEXT_TYPE",
144: "WITH_CONTEXT_TYPE",
145: "EXPORTED_SUB_CLASS_BASE_TYPE",
146: "EXPORTED_SUB_CLASS_TYPE",
147: "EXPORTED_SUB_CLASS2_TYPE",
148: "SMALL_ORDERED_HASH_MAP_TYPE",
149: "SMALL_ORDERED_HASH_SET_TYPE",
150: "SMALL_ORDERED_NAME_DICTIONARY_TYPE",
151: "DESCRIPTOR_ARRAY_TYPE",
152: "STRONG_DESCRIPTOR_ARRAY_TYPE",
153: "SOURCE_TEXT_MODULE_TYPE",
154: "SYNTHETIC_MODULE_TYPE",
155: "UNCOMPILED_DATA_WITH_PREPARSE_DATA_TYPE",
156: "UNCOMPILED_DATA_WITHOUT_PREPARSE_DATA_TYPE",
157: "WEAK_FIXED_ARRAY_TYPE",
158: "TRANSITION_ARRAY_TYPE",
159: "CELL_TYPE",
160: "CODE_TYPE",
161: "CODE_DATA_CONTAINER_TYPE",
162: "COVERAGE_INFO_TYPE",
163: "EMBEDDER_DATA_ARRAY_TYPE",
164: "FEEDBACK_METADATA_TYPE",
165: "FEEDBACK_VECTOR_TYPE",
166: "FILLER_TYPE",
167: "FREE_SPACE_TYPE",
168: "INTERNAL_CLASS_TYPE",
169: "INTERNAL_CLASS_WITH_STRUCT_ELEMENTS_TYPE",
170: "MAP_TYPE",
171: "ON_HEAP_BASIC_BLOCK_PROFILER_DATA_TYPE",
172: "PREPARSE_DATA_TYPE",
173: "PROPERTY_ARRAY_TYPE",
174: "PROPERTY_CELL_TYPE",
175: "SHARED_FUNCTION_INFO_TYPE",
176: "SMI_BOX_TYPE",
177: "SMI_PAIR_TYPE",
178: "SORT_STATE_TYPE",
179: "SWISS_NAME_DICTIONARY_TYPE",
180: "WASM_ARRAY_TYPE",
181: "WASM_CAPI_FUNCTION_DATA_TYPE",
182: "WASM_STRUCT_TYPE",
183: "WEAK_ARRAY_LIST_TYPE",
184: "WEAK_CELL_TYPE",
185: "JS_PROXY_TYPE",
[torque] Generate instance types Design doc: https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit Changes from the design doc: - Changed to use 'class' declarations rather than 'type' declarations for things that need instance types but whose layout is not known to Torque. These declarations end with a semicolon rather than having a full set of methods and fields surrounded by {}. If the class's name should not be treated as a class name in generated output (because it's actually a template, or doesn't exist at all), we use the standard 'generates' clause to declare the most appropriate C++ class. - Removed @instanceTypeName. - @highestInstanceType became @highestInstanceTypeWithinParentClassRange to indicate a semantic change: it no longer denotes the highest instance type globally, but only within the range of values for its immediate parent class. This lets us use it for Oddball, which is expected to be the highest primitive type. - Added new abstract classes JSCustomElementsObject and JSSpecialObject to help with some range checks. - Added @lowestInstanceTypeWithinParentClassRange so we can move the new classes JSCustomElementsObject and JSSpecialObject to the beginning of the JSObject range. This seems like the least-brittle way to establish ranges that also include JSProxy (and these ranges are verified with static assertions in instance-type.h). - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue. - Renamed @instanceTypeFlags to @reserveBitsInInstanceType. This change introduces the new annotations and adds the ability for Torque to assign instance types that satisfy those annotations. Torque now emits two new macros: - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the InstanceType enumeration - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String parts of INSTANCE_TYPE_LIST The design document mentions a couple of other macro lists that could easily be replaced, but I'd like to defer those to a subsequent checkin because this one is already pretty large. Bug: v8:7793 Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64258}
2019-10-11 21:52:06 +00:00
1057: "JS_OBJECT_TYPE",
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
186: "JS_GLOBAL_OBJECT_TYPE",
187: "JS_GLOBAL_PROXY_TYPE",
188: "JS_MODULE_NAMESPACE_TYPE",
Reduce max instance type enum value. We collect instance type statistics in FatalProcessOutOfMemory into an array, which is allocated to the max instance type value. While we want to leave space to ensure new instance types do not affect constants in the API, we can be more frugal. We currently serialize 350 maps into the startup/context snapshot. Even if we assign a distinct instance type to each of these maps, we would still have more than enough to spare with this change. R=ulan@chromium.org Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I3e583c2c8da3342e9132d96046b5d80cd41afd72 Reviewed-on: https://chromium-review.googlesource.com/842542 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#50302}
2017-12-22 17:20:47 +00:00
1040: "JS_SPECIAL_API_OBJECT_TYPE",
[objects] Rename JSValue to JSPrimitiveWrapper We currently use the class name “JSValue” for JSObjects that wrap primitive values. This name is a common source of confusion. This patch switches to a name that’s more clear. In addition to manual tweaks, the patch applies the following mechanical global replacements: before | after --------------------------------|-------------------------------------- if_valueisnotvalue | if_valueisnotwrapper if_valueisvalue | if_valueiswrapper js_value | js_primitive_wrapper JS_VALUE_TYPE | JS_PRIMITIVE_WRAPPER_TYPE JSPrimitiveWrapperType | JSPrimitiveWrapper type jsvalue | js_primitive_wrapper JSValue | JSPrimitiveWrapper _GENERATED_JSVALUE_FIELDS | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942 Reviewed-by: Tamer Tas <tmrts@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#62337}
2019-06-24 13:13:34 +00:00
1041: "JS_PRIMITIVE_WRAPPER_TYPE",
[runtime] Add new instance types for common prototype objects In the future, these instance types will be used for fast range checks rather than the current slow individual map checks. Bug: v8:11256 Change-Id: I4ad7d5259fbd46c3272a80996a5ac45a400d1f5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2590040 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#71791}
2020-12-16 13:50:35 +00:00
1042: "JS_ARRAY_ITERATOR_PROTOTYPE_TYPE",
1043: "JS_ITERATOR_PROTOTYPE_TYPE",
1044: "JS_MAP_ITERATOR_PROTOTYPE_TYPE",
1045: "JS_OBJECT_PROTOTYPE_TYPE",
1046: "JS_PROMISE_PROTOTYPE_TYPE",
1047: "JS_REG_EXP_PROTOTYPE_TYPE",
1048: "JS_SET_ITERATOR_PROTOTYPE_TYPE",
1049: "JS_SET_PROTOTYPE_TYPE",
1050: "JS_STRING_ITERATOR_PROTOTYPE_TYPE",
[runtime] Fix TypedArrayPrototype protector cell checks Previously, we were looking up the prototype of the receiver and checking that against %TypedArrayPrototype% before invalidating the protector cell. This is incorrect as it's possible to patch the prototype and then change the constructor property, bypassing this check. This CL adds a new instance type to prototype of all TypedArray constructors and checks the receiver against this instance type. TBR: tebbi@chromium.org Bug: v8:11274, v8:11256 Change-Id: I2ff6280e4cf820b06c5593fe4addd36f7ac656c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2594776 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#71799}
2020-12-16 15:41:50 +00:00
1051: "JS_TYPED_ARRAY_PROTOTYPE_TYPE",
1052: "JS_GENERATOR_OBJECT_TYPE",
1053: "JS_ASYNC_FUNCTION_OBJECT_TYPE",
1054: "JS_ASYNC_GENERATOR_OBJECT_TYPE",
1055: "JS_ARGUMENTS_OBJECT_TYPE",
Reduce max instance type enum value. We collect instance type statistics in FatalProcessOutOfMemory into an array, which is allocated to the max instance type value. While we want to leave space to ensure new instance types do not affect constants in the API, we can be more frugal. We currently serialize 350 maps into the startup/context snapshot. Even if we assign a distinct instance type to each of these maps, we would still have more than enough to spare with this change. R=ulan@chromium.org Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I3e583c2c8da3342e9132d96046b5d80cd41afd72 Reviewed-on: https://chromium-review.googlesource.com/842542 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#50302}
2017-12-22 17:20:47 +00:00
1056: "JS_API_OBJECT_TYPE",
[runtime] Add new instance types for constructor functions This will allow us optimize the protector cell checks in the fast path from checking against the function object in every context to just doing a range check against the instance type. This patch adds new instance types for constructor functions that require such protector cell checks. Bug: v8:11256 Change-Id: Iea722f9c6326dfa470149dd02e689a23942097f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595442 Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#72146}
2021-01-18 17:01:02 +00:00
1058: "JS_BOUND_FUNCTION_TYPE",
1059: "JS_FUNCTION_TYPE",
1060: "BIGINT64_TYPED_ARRAY_CONSTRUCTOR_TYPE",
1061: "BIGUINT64_TYPED_ARRAY_CONSTRUCTOR_TYPE",
1062: "FLOAT32_TYPED_ARRAY_CONSTRUCTOR_TYPE",
1063: "FLOAT64_TYPED_ARRAY_CONSTRUCTOR_TYPE",
1064: "INT16_TYPED_ARRAY_CONSTRUCTOR_TYPE",
1065: "INT32_TYPED_ARRAY_CONSTRUCTOR_TYPE",
1066: "INT8_TYPED_ARRAY_CONSTRUCTOR_TYPE",
1067: "UINT16_TYPED_ARRAY_CONSTRUCTOR_TYPE",
1068: "UINT32_TYPED_ARRAY_CONSTRUCTOR_TYPE",
1069: "UINT8_CLAMPED_TYPED_ARRAY_CONSTRUCTOR_TYPE",
1070: "UINT8_TYPED_ARRAY_CONSTRUCTOR_TYPE",
1071: "JS_ARRAY_CONSTRUCTOR_TYPE",
1072: "JS_PROMISE_CONSTRUCTOR_TYPE",
1073: "JS_REG_EXP_CONSTRUCTOR_TYPE",
1074: "JS_MAP_KEY_ITERATOR_TYPE",
1075: "JS_MAP_KEY_VALUE_ITERATOR_TYPE",
1076: "JS_MAP_VALUE_ITERATOR_TYPE",
1077: "JS_SET_KEY_VALUE_ITERATOR_TYPE",
1078: "JS_SET_VALUE_ITERATOR_TYPE",
1079: "JS_DATA_VIEW_TYPE",
1080: "JS_TYPED_ARRAY_TYPE",
1081: "JS_MAP_TYPE",
1082: "JS_SET_TYPE",
1083: "JS_WEAK_MAP_TYPE",
1084: "JS_WEAK_SET_TYPE",
1085: "JS_ARRAY_TYPE",
1086: "JS_ARRAY_BUFFER_TYPE",
1087: "JS_ARRAY_ITERATOR_TYPE",
1088: "JS_ASYNC_FROM_SYNC_ITERATOR_TYPE",
1089: "JS_COLLATOR_TYPE",
1090: "JS_CONTEXT_EXTENSION_OBJECT_TYPE",
1091: "JS_DATE_TYPE",
1092: "JS_DATE_TIME_FORMAT_TYPE",
1093: "JS_DISPLAY_NAMES_TYPE",
1094: "JS_ERROR_TYPE",
1095: "JS_FINALIZATION_REGISTRY_TYPE",
1096: "JS_LIST_FORMAT_TYPE",
1097: "JS_LOCALE_TYPE",
1098: "JS_MESSAGE_OBJECT_TYPE",
1099: "JS_NUMBER_FORMAT_TYPE",
1100: "JS_PLURAL_RULES_TYPE",
1101: "JS_PROMISE_TYPE",
1102: "JS_REG_EXP_TYPE",
1103: "JS_REG_EXP_STRING_ITERATOR_TYPE",
1104: "JS_RELATIVE_TIME_FORMAT_TYPE",
1105: "JS_SEGMENT_ITERATOR_TYPE",
1106: "JS_SEGMENTER_TYPE",
1107: "JS_SEGMENTS_TYPE",
1108: "JS_STRING_ITERATOR_TYPE",
1109: "JS_V8_BREAK_ITERATOR_TYPE",
1110: "JS_WEAK_REF_TYPE",
1111: "WASM_EXCEPTION_OBJECT_TYPE",
1112: "WASM_GLOBAL_OBJECT_TYPE",
1113: "WASM_INSTANCE_OBJECT_TYPE",
1114: "WASM_MEMORY_OBJECT_TYPE",
1115: "WASM_MODULE_OBJECT_TYPE",
1116: "WASM_TABLE_OBJECT_TYPE",
[inspector][wasm] Re-add WasmValue as JSObject subclass. BREAKING CHANGE: The values of Wasm locals, stack, and globals are now represented as objects instead of holding the (primitive) values directly, and SIMD128 values are no longer represented as Uint8Arrays. The DWARF extension has been prepared for this breaking change. The new `WasmValue` comes with `type` and `value` properties that hold its contents. The motivation here is that this is a more extensible approach. In case of SIMD128, the `value` property holds the canonical string representation, which has the additional advantage that these values can be compared with `===` (and `==`). This partially reverts https://crrev.com/c/2614428, the main difference here being that WasmValue is now a proper JSObject that can be exposed on the DebugEvaluate proxy API. Screenshot: https://imgur.com/rcahNKM.png Bug: chromium:1170282, chromium:1071432, chromium:1159402 Change-Id: Iea304e3680775123c41deb4c3d172ac949da1b98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643384 Reviewed-by: Philip Pfaffe <pfaffe@chromium.org> Reviewed-by: Zhi An Ng <zhin@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72570}
2021-02-08 15:39:00 +00:00
1117: "WASM_VALUE_OBJECT_TYPE",
Generate grokdump constants with 'make grokdump' now. R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/21771002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16022 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-08-02 09:02:02 +00:00
}
# List of known V8 maps.
KNOWN_MAPS = {
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x02119): (170, "MetaMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x02141): (67, "NullMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x02169): (152, "StrongDescriptorArrayMap"),
("read_only_space", 0x02191): (157, "WeakFixedArrayMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x021d1): (96, "EnumCacheMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x02205): (116, "FixedArrayMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x02251): (8, "OneByteInternalizedStringMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x0229d): (167, "FreeSpaceMap"),
("read_only_space", 0x022c5): (166, "OnePointerFillerMap"),
("read_only_space", 0x022ed): (166, "TwoPointerFillerMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x02315): (67, "UninitializedMap"),
("read_only_space", 0x0238d): (67, "UndefinedMap"),
("read_only_space", 0x023d1): (66, "HeapNumberMap"),
("read_only_space", 0x02405): (67, "TheHoleMap"),
("read_only_space", 0x02465): (67, "BooleanMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x02509): (129, "ByteArrayMap"),
("read_only_space", 0x02531): (116, "FixedCOWArrayMap"),
("read_only_space", 0x02559): (117, "HashTableMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x02581): (64, "SymbolMap"),
("read_only_space", 0x025a9): (40, "OneByteStringMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x025d1): (133, "ScopeInfoMap"),
("read_only_space", 0x025f9): (175, "SharedFunctionInfoMap"),
("read_only_space", 0x02621): (160, "CodeMap"),
("read_only_space", 0x02649): (159, "CellMap"),
("read_only_space", 0x02671): (174, "GlobalPropertyCellMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x02699): (70, "ForeignMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x026c1): (158, "TransitionArrayMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x026e9): (45, "ThinOneByteStringMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x02711): (165, "FeedbackVectorMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x0274d): (67, "ArgumentsMarkerMap"),
("read_only_space", 0x027ad): (67, "ExceptionMap"),
("read_only_space", 0x02809): (67, "TerminationExceptionMap"),
("read_only_space", 0x02871): (67, "OptimizedOutMap"),
("read_only_space", 0x028d1): (67, "StaleRegisterMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x02931): (128, "ScriptContextTableMap"),
("read_only_space", 0x02959): (126, "ClosureFeedbackCellArrayMap"),
("read_only_space", 0x02981): (164, "FeedbackMetadataArrayMap"),
("read_only_space", 0x029a9): (116, "ArrayListMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x029d1): (65, "BigIntMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x029f9): (127, "ObjectBoilerplateDescriptionMap"),
("read_only_space", 0x02a21): (130, "BytecodeArrayMap"),
("read_only_space", 0x02a49): (161, "CodeDataContainerMap"),
("read_only_space", 0x02a71): (162, "CoverageInfoMap"),
("read_only_space", 0x02a99): (131, "FixedDoubleArrayMap"),
("read_only_space", 0x02ac1): (119, "GlobalDictionaryMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x02ae9): (97, "ManyClosuresCellMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x02b11): (116, "ModuleInfoMap"),
("read_only_space", 0x02b39): (120, "NameDictionaryMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x02b61): (97, "NoClosuresCellMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x02b89): (121, "NumberDictionaryMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x02bb1): (97, "OneClosureCellMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x02bd9): (122, "OrderedHashMapMap"),
("read_only_space", 0x02c01): (123, "OrderedHashSetMap"),
("read_only_space", 0x02c29): (124, "OrderedNameDictionaryMap"),
("read_only_space", 0x02c51): (172, "PreparseDataMap"),
("read_only_space", 0x02c79): (173, "PropertyArrayMap"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x02ca1): (93, "SideEffectCallHandlerInfoMap"),
("read_only_space", 0x02cc9): (93, "SideEffectFreeCallHandlerInfoMap"),
("read_only_space", 0x02cf1): (93, "NextCallSideEffectFreeCallHandlerInfoMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x02d19): (125, "SimpleNumberDictionaryMap"),
("read_only_space", 0x02d41): (148, "SmallOrderedHashMapMap"),
("read_only_space", 0x02d69): (149, "SmallOrderedHashSetMap"),
("read_only_space", 0x02d91): (150, "SmallOrderedNameDictionaryMap"),
("read_only_space", 0x02db9): (153, "SourceTextModuleMap"),
("read_only_space", 0x02de1): (179, "SwissNameDictionaryMap"),
("read_only_space", 0x02e09): (154, "SyntheticModuleMap"),
[dict-proto] C++ implementation of SwissNameDictionary, pt. 1 This CL is part of a series that adds the C++ implementation of SwissNameDictionary, a deterministic property backing store based on Swiss Tables. This CL contains most of the boilerplate code for introducing a new instance type. Bug: v8:11388 Change-Id: Id263b8138a8ce4b465fb28d968223d2e1aaf05a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672030 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Frank Emrich <emrich@google.com> Cr-Commit-Position: refs/heads/master@{#72582}
2021-02-05 12:20:38 +00:00
("read_only_space", 0x02e31): (71, "WasmTypeInfoMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x02e59): (183, "WeakArrayListMap"),
("read_only_space", 0x02e81): (118, "EphemeronHashTableMap"),
("read_only_space", 0x02ea9): (163, "EmbedderDataArrayMap"),
("read_only_space", 0x02ed1): (184, "WeakCellMap"),
[dict-proto] C++ implementation of SwissNameDictionary, pt. 1 This CL is part of a series that adds the C++ implementation of SwissNameDictionary, a deterministic property backing store based on Swiss Tables. This CL contains most of the boilerplate code for introducing a new instance type. Bug: v8:11388 Change-Id: Id263b8138a8ce4b465fb28d968223d2e1aaf05a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672030 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Frank Emrich <emrich@google.com> Cr-Commit-Position: refs/heads/master@{#72582}
2021-02-05 12:20:38 +00:00
("read_only_space", 0x02ef9): (32, "StringMap"),
("read_only_space", 0x02f21): (41, "ConsOneByteStringMap"),
("read_only_space", 0x02f49): (33, "ConsStringMap"),
("read_only_space", 0x02f71): (37, "ThinStringMap"),
("read_only_space", 0x02f99): (35, "SlicedStringMap"),
("read_only_space", 0x02fc1): (43, "SlicedOneByteStringMap"),
("read_only_space", 0x02fe9): (34, "ExternalStringMap"),
("read_only_space", 0x03011): (42, "ExternalOneByteStringMap"),
("read_only_space", 0x03039): (50, "UncachedExternalStringMap"),
("read_only_space", 0x03061): (0, "InternalizedStringMap"),
("read_only_space", 0x03089): (2, "ExternalInternalizedStringMap"),
("read_only_space", 0x030b1): (10, "ExternalOneByteInternalizedStringMap"),
("read_only_space", 0x030d9): (18, "UncachedExternalInternalizedStringMap"),
("read_only_space", 0x03101): (26, "UncachedExternalOneByteInternalizedStringMap"),
("read_only_space", 0x03129): (58, "UncachedExternalOneByteStringMap"),
("read_only_space", 0x03151): (67, "SelfReferenceMarkerMap"),
("read_only_space", 0x03179): (67, "BasicBlockCountersMarkerMap"),
("read_only_space", 0x031bd): (87, "ArrayBoilerplateDescriptionMap"),
("read_only_space", 0x03291): (99, "InterceptorInfoMap"),
("read_only_space", 0x0540d): (72, "PromiseFulfillReactionJobTaskMap"),
("read_only_space", 0x05435): (73, "PromiseRejectReactionJobTaskMap"),
("read_only_space", 0x0545d): (74, "CallableTaskMap"),
("read_only_space", 0x05485): (75, "CallbackTaskMap"),
("read_only_space", 0x054ad): (76, "PromiseResolveThenableJobTaskMap"),
("read_only_space", 0x054d5): (79, "FunctionTemplateInfoMap"),
("read_only_space", 0x054fd): (80, "ObjectTemplateInfoMap"),
("read_only_space", 0x05525): (81, "AccessCheckInfoMap"),
("read_only_space", 0x0554d): (82, "AccessorInfoMap"),
("read_only_space", 0x05575): (83, "AccessorPairMap"),
("read_only_space", 0x0559d): (84, "AliasedArgumentsEntryMap"),
("read_only_space", 0x055c5): (85, "AllocationMementoMap"),
("read_only_space", 0x055ed): (88, "AsmWasmDataMap"),
("read_only_space", 0x05615): (89, "AsyncGeneratorRequestMap"),
("read_only_space", 0x0563d): (90, "BreakPointMap"),
("read_only_space", 0x05665): (91, "BreakPointInfoMap"),
("read_only_space", 0x0568d): (92, "CachedTemplateObjectMap"),
("read_only_space", 0x056b5): (94, "ClassPositionsMap"),
("read_only_space", 0x056dd): (95, "DebugInfoMap"),
("read_only_space", 0x05705): (98, "FunctionTemplateRareDataMap"),
("read_only_space", 0x0572d): (100, "InterpreterDataMap"),
("read_only_space", 0x05755): (101, "ModuleRequestMap"),
("read_only_space", 0x0577d): (102, "PromiseCapabilityMap"),
("read_only_space", 0x057a5): (103, "PromiseReactionMap"),
("read_only_space", 0x057cd): (104, "PropertyDescriptorObjectMap"),
("read_only_space", 0x057f5): (105, "PrototypeInfoMap"),
("read_only_space", 0x0581d): (106, "RegExpBoilerplateDescriptionMap"),
("read_only_space", 0x05845): (107, "ScriptMap"),
("read_only_space", 0x0586d): (108, "SourceTextModuleInfoEntryMap"),
[stack-traces] Remove StackFrameInfo. For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
2021-02-11 09:19:13 +00:00
("read_only_space", 0x05895): (109, "StackTraceFrameMap"),
("read_only_space", 0x058bd): (110, "TemplateObjectDescriptionMap"),
("read_only_space", 0x058e5): (111, "Tuple2Map"),
("read_only_space", 0x0590d): (112, "WasmExceptionTagMap"),
("read_only_space", 0x05935): (113, "WasmExportedFunctionDataMap"),
("read_only_space", 0x0595d): (114, "WasmIndirectFunctionTableMap"),
("read_only_space", 0x05985): (115, "WasmJSFunctionDataMap"),
("read_only_space", 0x059ad): (134, "SloppyArgumentsElementsMap"),
("read_only_space", 0x059d5): (151, "DescriptorArrayMap"),
("read_only_space", 0x059fd): (156, "UncompiledDataWithoutPreparseDataMap"),
("read_only_space", 0x05a25): (155, "UncompiledDataWithPreparseDataMap"),
("read_only_space", 0x05a4d): (171, "OnHeapBasicBlockProfilerDataMap"),
("read_only_space", 0x05a75): (181, "WasmCapiFunctionDataMap"),
("read_only_space", 0x05a9d): (168, "InternalClassMap"),
("read_only_space", 0x05ac5): (177, "SmiPairMap"),
("read_only_space", 0x05aed): (176, "SmiBoxMap"),
("read_only_space", 0x05b15): (145, "ExportedSubClassBaseMap"),
("read_only_space", 0x05b3d): (146, "ExportedSubClassMap"),
("read_only_space", 0x05b65): (68, "AbstractInternalClassSubclass1Map"),
("read_only_space", 0x05b8d): (69, "AbstractInternalClassSubclass2Map"),
("read_only_space", 0x05bb5): (132, "InternalClassWithSmiElementsMap"),
("read_only_space", 0x05bdd): (169, "InternalClassWithStructElementsMap"),
("read_only_space", 0x05c05): (147, "ExportedSubClass2Map"),
("read_only_space", 0x05c2d): (178, "SortStateMap"),
("read_only_space", 0x05c55): (86, "AllocationSiteWithWeakNextMap"),
("read_only_space", 0x05c7d): (86, "AllocationSiteWithoutWeakNextMap"),
("read_only_space", 0x05ca5): (77, "LoadHandler1Map"),
("read_only_space", 0x05ccd): (77, "LoadHandler2Map"),
("read_only_space", 0x05cf5): (77, "LoadHandler3Map"),
("read_only_space", 0x05d1d): (78, "StoreHandler0Map"),
("read_only_space", 0x05d45): (78, "StoreHandler1Map"),
("read_only_space", 0x05d6d): (78, "StoreHandler2Map"),
("read_only_space", 0x05d95): (78, "StoreHandler3Map"),
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("map_space", 0x02119): (1057, "ExternalMap"),
("map_space", 0x02141): (1098, "JSMessageObjectMap"),
Generate grokdump constants with 'make grokdump' now. R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/21771002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16022 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-08-02 09:02:02 +00:00
}
# List of known V8 objects.
KNOWN_OBJECTS = {
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("read_only_space", 0x021b9): "EmptyWeakFixedArray",
("read_only_space", 0x021c1): "EmptyDescriptorArray",
("read_only_space", 0x021f9): "EmptyEnumCache",
("read_only_space", 0x0222d): "EmptyFixedArray",
("read_only_space", 0x02235): "NullValue",
("read_only_space", 0x0233d): "UninitializedValue",
("read_only_space", 0x023b5): "UndefinedValue",
("read_only_space", 0x023f9): "NanValue",
("read_only_space", 0x0242d): "TheHoleValue",
("read_only_space", 0x02459): "HoleNanValue",
("read_only_space", 0x0248d): "TrueValue",
("read_only_space", 0x024cd): "FalseValue",
("read_only_space", 0x024fd): "empty_string",
("read_only_space", 0x02739): "EmptyScopeInfo",
("read_only_space", 0x02775): "ArgumentsMarker",
("read_only_space", 0x027d5): "Exception",
("read_only_space", 0x02831): "TerminationException",
("read_only_space", 0x02899): "OptimizedOut",
("read_only_space", 0x028f9): "StaleRegister",
[dict-proto] C++ implementation of SwissNameDictionary, pt. 1 This CL is part of a series that adds the C++ implementation of SwissNameDictionary, a deterministic property backing store based on Swiss Tables. This CL contains most of the boilerplate code for introducing a new instance type. Bug: v8:11388 Change-Id: Id263b8138a8ce4b465fb28d968223d2e1aaf05a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672030 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Frank Emrich <emrich@google.com> Cr-Commit-Position: refs/heads/master@{#72582}
2021-02-05 12:20:38 +00:00
("read_only_space", 0x031a1): "EmptyPropertyArray",
("read_only_space", 0x031a9): "EmptyByteArray",
("read_only_space", 0x031b1): "EmptyObjectBoilerplateDescription",
("read_only_space", 0x031e5): "EmptyArrayBoilerplateDescription",
("read_only_space", 0x031f1): "EmptyClosureFeedbackCellArray",
("read_only_space", 0x031f9): "EmptySlowElementDictionary",
("read_only_space", 0x0321d): "EmptyOrderedHashMap",
("read_only_space", 0x03231): "EmptyOrderedHashSet",
("read_only_space", 0x03245): "EmptyFeedbackMetadata",
("read_only_space", 0x03251): "EmptyPropertyDictionary",
("read_only_space", 0x03279): "EmptyOrderedPropertyDictionary",
("read_only_space", 0x032b9): "NoOpInterceptorInfo",
("read_only_space", 0x032e1): "EmptyWeakArrayList",
("read_only_space", 0x032ed): "InfinityValue",
("read_only_space", 0x032f9): "MinusZeroValue",
("read_only_space", 0x03305): "MinusInfinityValue",
("read_only_space", 0x03311): "SelfReferenceMarker",
("read_only_space", 0x03351): "BasicBlockCountersMarker",
("read_only_space", 0x03395): "OffHeapTrampolineRelocationInfo",
("read_only_space", 0x033a1): "TrampolineTrivialCodeDataContainer",
("read_only_space", 0x033ad): "TrampolinePromiseRejectionCodeDataContainer",
("read_only_space", 0x033b9): "GlobalThisBindingScopeInfo",
("read_only_space", 0x033f1): "EmptyFunctionScopeInfo",
("read_only_space", 0x03419): "NativeScopeInfo",
("read_only_space", 0x03435): "HashSeed",
[heap] Fix alignment of large fixed double array. This ensures that large objects have alignment suitable for a fixed double arrays. Bug: chromium:1161759 Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72251}
2021-01-21 13:45:51 +00:00
("old_space", 0x02119): "ArgumentsIteratorAccessor",
("old_space", 0x0215d): "ArrayLengthAccessor",
("old_space", 0x021a1): "BoundFunctionLengthAccessor",
("old_space", 0x021e5): "BoundFunctionNameAccessor",
("old_space", 0x02229): "ErrorStackAccessor",
("old_space", 0x0226d): "FunctionArgumentsAccessor",
("old_space", 0x022b1): "FunctionCallerAccessor",
("old_space", 0x022f5): "FunctionNameAccessor",
("old_space", 0x02339): "FunctionLengthAccessor",
("old_space", 0x0237d): "FunctionPrototypeAccessor",
[regexp] Implement the /d flag for RegExp indices This CL implements the upcoming spec change: https://github.com/tc39/proposal-regexp-match-indices/pull/49 A new JSRegExpResultWithIndices subclass is introduced with a separate map and an extra slot for storing the indices. If /d is passed, exec() constructs a JSRegExpResultWithIndices and eagerly builds indices. The existing re-execution logic is removed. Bug: v8:9548 Change-Id: Ic11853e7521017af5e8bd583c7b82bb672821132 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616873 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#72306}
2021-01-26 00:50:44 +00:00
("old_space", 0x023c1): "StringLengthAccessor",
("old_space", 0x02405): "InvalidPrototypeValidityCell",
Reland "[wasm-gc] Remove abstract rtts" This is a reland of b77deeca4bd65b006a3a6c7344c2bbabd4514122 Changes compared to original: Add explicit narrowing casts in tests for MSVC. Original change's description: > [wasm-gc] Remove abstract rtts > > In the latest wasm-gc spec, rtts of abstract types are no longer > allowed. Consequently, canonical rtts of concrete types always have > a depth of 0. > > Changes: > - Change the immediate argument of rtts to a type index over a heap > type. Abstract it with TypeIndexImmediate in function body decoding. > This affects: > value_type.h, read_value_type(), decoding of relevant opcodes, > wasm subtyping, WasmInitExpr, consume_init_expr(), and > wasm-module-builder.cc. > - In function-body-decoder-impl.h, update rtt.canon to always produce > an rtt of depth 0. > - Pass a unit32_t type index over a HeapType to all rtt-related > utilities. > - Remove infrastructure for abstract-type rtts from the wasm compilers, > setup-heap-internal.cc, roots.h, and module-instantiate.cc. > - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches > from ref.test, ref.cast and br_on_cast implementations in the wasm > compilers. > - Remove unused 'parent' field from WasmTypeInfo. > - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap, > and CreateArrayMap. > - Use more convenient arguments in IsHeapSubtypeOf. > - Update tests. > > Bug: v8:7748 > Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248 > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72321} Bug: v8:7748 Change-Id: I22b204b486fd185077cd6c7f15d492f5143f48fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650207 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72355}
2021-01-27 08:33:32 +00:00
("old_space", 0x0240d): "EmptyScript",
("old_space", 0x0244d): "ManyClosuresCell",
("old_space", 0x02459): "ArrayConstructorProtector",
("old_space", 0x0246d): "NoElementsProtector",
("old_space", 0x02481): "IsConcatSpreadableProtector",
("old_space", 0x02495): "ArraySpeciesProtector",
("old_space", 0x024a9): "TypedArraySpeciesProtector",
("old_space", 0x024bd): "PromiseSpeciesProtector",
("old_space", 0x024d1): "RegExpSpeciesProtector",
("old_space", 0x024e5): "StringLengthProtector",
("old_space", 0x024f9): "ArrayIteratorProtector",
("old_space", 0x0250d): "ArrayBufferDetachingProtector",
("old_space", 0x02521): "PromiseHookProtector",
("old_space", 0x02535): "PromiseResolveProtector",
("old_space", 0x02549): "MapIteratorProtector",
("old_space", 0x0255d): "PromiseThenProtector",
("old_space", 0x02571): "SetIteratorProtector",
("old_space", 0x02585): "StringIteratorProtector",
("old_space", 0x02599): "SingleCharacterStringCache",
("old_space", 0x029a1): "StringSplitCache",
("old_space", 0x02da9): "RegExpMultipleCache",
("old_space", 0x031b1): "BuiltinsConstantsTable",
[torque] Port String.prototype.includes/indexOf and StringIndexOf - Removed no longer used StringBuiltinAssembler methods (DispatchOnStringEncodings, PointerToStringDataAtIndex) - Removed no longer used Runtime functions (StringIncludes, StringIndexOf, StringIndexOfUnchecked). - Overall builtin code size is reduced (652 bytes on Mac x64.release build), builtin size breakdown: BEFORE ====== TFS Builtin, StringIndexOf, 1092 TFJ Builtin, StringPrototypeIncludes, 1784 TFJ Builtin, StringPrototypeIndexOf, 1536 Total = 4412 AFTER ===== TFC Builtin, StringIndexOf, 2036 (+944) TFJ Builtin, StringPrototypeIncludes, 1072 (-712) TFJ Builtin, StringPrototypeIndexOf, 652 (-884) Total = 3760 (-652) Bug: v8:8996 Change-Id: I9a88c095e2097f7d570e58e744d6692dc524ddf4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2660995 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72456}
2021-02-01 07:34:16 +00:00
("old_space", 0x035b1): "AsyncFunctionAwaitRejectSharedFun",
("old_space", 0x035d5): "AsyncFunctionAwaitResolveSharedFun",
("old_space", 0x035f9): "AsyncGeneratorAwaitRejectSharedFun",
("old_space", 0x0361d): "AsyncGeneratorAwaitResolveSharedFun",
("old_space", 0x03641): "AsyncGeneratorYieldResolveSharedFun",
("old_space", 0x03665): "AsyncGeneratorReturnResolveSharedFun",
("old_space", 0x03689): "AsyncGeneratorReturnClosedRejectSharedFun",
("old_space", 0x036ad): "AsyncGeneratorReturnClosedResolveSharedFun",
("old_space", 0x036d1): "AsyncIteratorValueUnwrapSharedFun",
("old_space", 0x036f5): "PromiseAllResolveElementSharedFun",
("old_space", 0x03719): "PromiseAllSettledResolveElementSharedFun",
("old_space", 0x0373d): "PromiseAllSettledRejectElementSharedFun",
("old_space", 0x03761): "PromiseAnyRejectElementSharedFun",
("old_space", 0x03785): "PromiseCapabilityDefaultRejectSharedFun",
("old_space", 0x037a9): "PromiseCapabilityDefaultResolveSharedFun",
("old_space", 0x037cd): "PromiseCatchFinallySharedFun",
("old_space", 0x037f1): "PromiseGetCapabilitiesExecutorSharedFun",
("old_space", 0x03815): "PromiseThenFinallySharedFun",
("old_space", 0x03839): "PromiseThrowerFinallySharedFun",
("old_space", 0x0385d): "PromiseValueThunkFinallySharedFun",
("old_space", 0x03881): "ProxyRevokeSharedFun",
[ptr-compr][x64] Enable pointer compression on x64 Chromium LSAN bot failures are fixed on Chromium side: https://chromium-review.googlesource.com/c/chromium/src/+/1926472 Bug: v8:7703 Change-Id: I830b747ca2f2f1b3c5adf31b42b3b8112c5d4457 Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng,v8_linux64_tsan_rel Cq-Include-Trybots: luci.v8.try:v8_linux64_cfi_rel_ng Cq-Include-Trybots: luci.chromium.try:fuchsia_x64,linux-rel,mac-rel,linux_chromium_asan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925149 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#65136}
2019-11-24 23:19:26 +00:00
}
# Lower 32 bits of first page addresses for various heap spaces.
HEAP_FIRST_PAGES = {
[heap] Allow semi space sizes above kMaxSemiSpaceSize Maximum semispace size was capped at kMaxSemiSpaceSize. Also allow non-power-of-2 sizes. Change-Id: I3385674a13455b47802a3f6e62ac5b9ed3987264 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962863 Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#65445}
2019-12-12 19:27:19 +00:00
0x08100000: "old_space",
0x08140000: "map_space",
[ptr-compr][x64] Enable pointer compression on x64 Chromium LSAN bot failures are fixed on Chromium side: https://chromium-review.googlesource.com/c/chromium/src/+/1926472 Bug: v8:7703 Change-Id: I830b747ca2f2f1b3c5adf31b42b3b8112c5d4457 Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng,v8_linux64_tsan_rel Cq-Include-Trybots: luci.v8.try:v8_linux64_cfi_rel_ng Cq-Include-Trybots: luci.chromium.try:fuchsia_x64,linux-rel,mac-rel,linux_chromium_asan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925149 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#65136}
2019-11-24 23:19:26 +00:00
0x08040000: "read_only_space",
Generate grokdump constants with 'make grokdump' now. R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/21771002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16022 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2013-08-02 09:02:02 +00:00
}
[tools] Improve grokdump.py - Add new address markers: T: tagged pointer in the minidump C: address into a module in the minidump S: pointer into the exception stack in the minidump *: other address in the minidump - Show ASCII decoding of address in dd - Display potential frame markers on the exception stack: 00000032212fdae8: 0000000300000000 ........ Smi(3) EXIT frame marker - Display relative addresses, useful to detect stack frames: 00000032212fdb68: 00000032212fdb98 S ........ [+6]=00000032212fdcb0 S 00000032212fdb70: 0000010ff5ca0a84 ........ 00000032212fdb78: 000001064c1fa881 ........ 00000032212fdb80: 0000016a8e52fcb1 ........ 00000032212fdb88: 0000010ff5ca0981 ........ 00000032212fdb90: 0000000d00000000 ........ Smi(13) INTERNAL frame marker 00000032212fdb98: 00000032212fdcb0 S ........ [+35]=00000032212fdd61 S Change-Id: I56bd7e6723a34bcb668719246dd5ff2898224928 Reviewed-on: https://chromium-review.googlesource.com/461862 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#44269}
2017-03-30 11:44:00 +00:00
# List of known V8 Frame Markers.
FRAME_MARKERS = (
"ENTRY",
Naming consistency and further small cleanups to frames.h R=mstarzinger@chromium.org Bug: Change-Id: Ia416acd8c12a3c8e3fdfabc56a4cd31cb946c88c Reviewed-on: https://chromium-review.googlesource.com/599949 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47135}
2017-08-03 14:30:20 +00:00
"CONSTRUCT_ENTRY",
[tools] Improve grokdump.py - Add new address markers: T: tagged pointer in the minidump C: address into a module in the minidump S: pointer into the exception stack in the minidump *: other address in the minidump - Show ASCII decoding of address in dd - Display potential frame markers on the exception stack: 00000032212fdae8: 0000000300000000 ........ Smi(3) EXIT frame marker - Display relative addresses, useful to detect stack frames: 00000032212fdb68: 00000032212fdb98 S ........ [+6]=00000032212fdcb0 S 00000032212fdb70: 0000010ff5ca0a84 ........ 00000032212fdb78: 000001064c1fa881 ........ 00000032212fdb80: 0000016a8e52fcb1 ........ 00000032212fdb88: 0000010ff5ca0981 ........ 00000032212fdb90: 0000000d00000000 ........ Smi(13) INTERNAL frame marker 00000032212fdb98: 00000032212fdcb0 S ........ [+35]=00000032212fdd61 S Change-Id: I56bd7e6723a34bcb668719246dd5ff2898224928 Reviewed-on: https://chromium-review.googlesource.com/461862 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#44269}
2017-03-30 11:44:00 +00:00
"EXIT",
"OPTIMIZED",
[wasm][debug] Rename WasmCompiledFrame to WasmFrame Also, rename the WASM_COMPILED frame type to just WASM. R=jkummerow@chromium.org Bug: v8:10389 Change-Id: I71f16f41a69f8b0295ba34bd7d7fad71729546f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187613 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#67698}
2020-05-07 12:29:48 +00:00
"WASM",
[tools] Improve grokdump.py - Add new address markers: T: tagged pointer in the minidump C: address into a module in the minidump S: pointer into the exception stack in the minidump *: other address in the minidump - Show ASCII decoding of address in dd - Display potential frame markers on the exception stack: 00000032212fdae8: 0000000300000000 ........ Smi(3) EXIT frame marker - Display relative addresses, useful to detect stack frames: 00000032212fdb68: 00000032212fdb98 S ........ [+6]=00000032212fdcb0 S 00000032212fdb70: 0000010ff5ca0a84 ........ 00000032212fdb78: 000001064c1fa881 ........ 00000032212fdb80: 0000016a8e52fcb1 ........ 00000032212fdb88: 0000010ff5ca0981 ........ 00000032212fdb90: 0000000d00000000 ........ Smi(13) INTERNAL frame marker 00000032212fdb98: 00000032212fdcb0 S ........ [+35]=00000032212fdd61 S Change-Id: I56bd7e6723a34bcb668719246dd5ff2898224928 Reviewed-on: https://chromium-review.googlesource.com/461862 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#44269}
2017-03-30 11:44:00 +00:00
"WASM_TO_JS",
"JS_TO_WASM",
[wasm] Add a separate frame type for debug break frames The frame created by the WasmDebugBreak builtin now has a separate frame type, which will (later) allow to inspect the spilled registers. Once Liftoff supports reference types, this frame will also need special GC support for spilled heap references. R=jkummerow@chromium.org Bug: v8:10222 Change-Id: I110e51d1e6d09b0f44dcdd1cdcaafa2eaa64fddd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083013 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66531}
2020-03-02 11:24:13 +00:00
"WASM_DEBUG_BREAK",
[wasm] [debug] Implement calling imported wasm functions The interpreter was not able to call imported wasm functions (hitting UNIMPLEMENTED). This CL fixes this by creating a "CWasmEntry", which is signature-specific. It has JS linkage and receives the wasm code object to call and a buffer containing all arguments (similar to the interpreter entry). It loads all arguments from the buffer and calls the given code object. The c-wasm-entry code objects are cached per instance, such that we only create them once per signature. These wasm entry stubs will also allow us to call back to compiled code from the interpreter, which we might want to do to reduce the slowdown of executing wasm for debugging. R=titzer@chromium.org Bug: chromium:735792 Change-Id: I7fecec3a7bec62a9de40fff115b684759b12a28b Reviewed-on: https://chromium-review.googlesource.com/600308 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47195}
2017-08-07 11:40:21 +00:00
"C_WASM_ENTRY",
[wasm-c-api] New call descriptor and stackframe kind So far, calls to Wasm C/C++ API functions reused the call descriptors of WasmImportWrappers, and the stack frame type of regular Wasm functions. This CL cleans that up by introducing separate implementations for both. No change in functionality or performance is expected. Change-Id: I79301fa81da52283cc776ddf19d4712372f3a58b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632235 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61914}
2019-05-29 10:42:21 +00:00
"WASM_EXIT",
[wasm] Introduce specialized WasmCompileLazy frame type. This makes the WasmCompileLazy builtin push a new WASM_COMPILE_LAZY frame type. We can thereby remove the workaround to return a relocated instance from the underlying runtime function. It also removes the last remaining embedded code objects from {WasmCode} objects. R=titzer@chromium.org Change-Id: Ic9c3f59339e8d7bed53ea0ed70ef50dfe640f1c6 Reviewed-on: https://chromium-review.googlesource.com/1073455 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53405}
2018-05-29 10:53:23 +00:00
"WASM_COMPILE_LAZY",
[tools] Improve grokdump.py - Add new address markers: T: tagged pointer in the minidump C: address into a module in the minidump S: pointer into the exception stack in the minidump *: other address in the minidump - Show ASCII decoding of address in dd - Display potential frame markers on the exception stack: 00000032212fdae8: 0000000300000000 ........ Smi(3) EXIT frame marker - Display relative addresses, useful to detect stack frames: 00000032212fdb68: 00000032212fdb98 S ........ [+6]=00000032212fdcb0 S 00000032212fdb70: 0000010ff5ca0a84 ........ 00000032212fdb78: 000001064c1fa881 ........ 00000032212fdb80: 0000016a8e52fcb1 ........ 00000032212fdb88: 0000010ff5ca0981 ........ 00000032212fdb90: 0000000d00000000 ........ Smi(13) INTERNAL frame marker 00000032212fdb98: 00000032212fdcb0 S ........ [+35]=00000032212fdd61 S Change-Id: I56bd7e6723a34bcb668719246dd5ff2898224928 Reviewed-on: https://chromium-review.googlesource.com/461862 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#44269}
2017-03-30 11:44:00 +00:00
"INTERPRETED",
"STUB",
Inline Array.prototype.forEach in TurboFan This CL contains a few pieces: - A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan graphs, which--when triggered--swizzle the values in the the FrameState to be parameters to a typically TF-generated builtin that resumes execution to finish the slow-case functionality. - Continuation builtins that have special handling in the deoptimizer and their own new frame type to ensure that the values they need to begin executing can be stashed away and restored immediately before the builtin is called via a trampoline that runs when the continuation builtin's frame execution resumes. - An implementation of Array.prototype.forEach in TurboFan that can be used to inline it. The inlined forEach implementation uses the checkpoints mechanism described above to deopt in the middle of the forEach in the cases that optimization invariants are violated. There is a slightly different continuation stub for each deopt point in the forEach implementation to ensure the correct side-effects, i.e. that the deopt of the builtin isn't programmatically observable. Review-Url: https://codereview.chromium.org/2803853005 Cr-Commit-Position: refs/heads/master@{#45764}
2017-06-07 13:23:33 +00:00
"BUILTIN_CONTINUATION",
"JAVA_SCRIPT_BUILTIN_CONTINUATION",
[promises/deoptimizer] Support "catching" builtin continuations This CL allows builtin continuations to handle pending exceptions. This implements exception handling for the promise constructor in case of deoptimization. Bug: v8:7584 Change-Id: Ib5df5eb6606abb3f9690f294397981858dbdbf25 Reviewed-on: https://chromium-review.googlesource.com/983912 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52340}
2018-04-04 06:31:33 +00:00
"JAVA_SCRIPT_BUILTIN_CONTINUATION_WITH_CATCH",
[tools] Improve grokdump.py - Add new address markers: T: tagged pointer in the minidump C: address into a module in the minidump S: pointer into the exception stack in the minidump *: other address in the minidump - Show ASCII decoding of address in dd - Display potential frame markers on the exception stack: 00000032212fdae8: 0000000300000000 ........ Smi(3) EXIT frame marker - Display relative addresses, useful to detect stack frames: 00000032212fdb68: 00000032212fdb98 S ........ [+6]=00000032212fdcb0 S 00000032212fdb70: 0000010ff5ca0a84 ........ 00000032212fdb78: 000001064c1fa881 ........ 00000032212fdb80: 0000016a8e52fcb1 ........ 00000032212fdb88: 0000010ff5ca0981 ........ 00000032212fdb90: 0000000d00000000 ........ Smi(13) INTERNAL frame marker 00000032212fdb98: 00000032212fdcb0 S ........ [+35]=00000032212fdd61 S Change-Id: I56bd7e6723a34bcb668719246dd5ff2898224928 Reviewed-on: https://chromium-review.googlesource.com/461862 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#44269}
2017-03-30 11:44:00 +00:00
"INTERNAL",
"CONSTRUCT",
"BUILTIN",
"BUILTIN_EXIT",
[cpu-profiler] Introduce NativeFrame type. The new frame type is inteneded to represent native C++ stack frames. JS code may sometimes make calls to helper native functions that do not provide any special stack layout besides the return address and frame pointer. Currently the stack iterator bails out when it sees an unknown frame. The patch allows the iterator to unwind stacks having such frames. BUG=chromium:768540 Change-Id: I9c273c7015695a6733c0a0c52b522fca7b25de0d Reviewed-on: https://chromium-review.googlesource.com/794991 Commit-Queue: Alexei Filippov <alph@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#50058}
2017-12-12 22:19:44 +00:00
"NATIVE",
[tools] Improve grokdump.py - Add new address markers: T: tagged pointer in the minidump C: address into a module in the minidump S: pointer into the exception stack in the minidump *: other address in the minidump - Show ASCII decoding of address in dd - Display potential frame markers on the exception stack: 00000032212fdae8: 0000000300000000 ........ Smi(3) EXIT frame marker - Display relative addresses, useful to detect stack frames: 00000032212fdb68: 00000032212fdb98 S ........ [+6]=00000032212fdcb0 S 00000032212fdb70: 0000010ff5ca0a84 ........ 00000032212fdb78: 000001064c1fa881 ........ 00000032212fdb80: 0000016a8e52fcb1 ........ 00000032212fdb88: 0000010ff5ca0981 ........ 00000032212fdb90: 0000000d00000000 ........ Smi(13) INTERNAL frame marker 00000032212fdb98: 00000032212fdcb0 S ........ [+35]=00000032212fdd61 S Change-Id: I56bd7e6723a34bcb668719246dd5ff2898224928 Reviewed-on: https://chromium-review.googlesource.com/461862 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#44269}
2017-03-30 11:44:00 +00:00
)
Introduce mkgrokdump to update tools/v8heapconst.py. - Migrate make grokdump to GYP and GN - Move code from d8 into stand-alone execution - Add test case to ensure it's up-to-date Review-Url: https://codereview.chromium.org/2809653003 Cr-Original-Original-Commit-Position: refs/heads/master@{#44687} Committed: https://chromium.googlesource.com/v8/v8/+/0cc0c130fa56f129c90c2a74cb01bda85df5e42a Review-Url: https://codereview.chromium.org/2809653003 Cr-Original-Commit-Position: refs/heads/master@{#44710} Committed: https://chromium.googlesource.com/v8/v8/+/477f00557458d383bd9ebef281890ba485ee882a Review-Url: https://codereview.chromium.org/2809653003 Cr-Commit-Position: refs/heads/master@{#44738}
2017-04-20 06:14:53 +00:00
# This set of constants is generated from a shipping build.
Reference in New Issue Copy Permalink