- 03 May, 2022 1 commit
-
-
Rob Paveza authored
This change adds support for computing SHA-256 hashes in the stack output of errors by adding a function to the prototype of the `CallSite` object, passed to `Error.prepareStackTrace`. Additionally, it updates the `hash` property from `Debugger.scriptParsed` and `Debugger.scriptFailedToParse` to be SHA-256 instead of the proprietary hash it is today. It is intended to be an advancement in indexing source maps to support improved tooling, especially for post-hoc or in-production diagnostics scenarios. The explainer can be found here: https://docs.google.com/document/d/13hNeeLC2Ve_FVieNndZUUUP15x2O4ltvjnGWwOsMlrU/edit?usp=sharing Change-Id: Ifbbed4b22c8256e74e6d79974d2dd1e444143eda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229957Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Auto-Submit: Robert Paveza <Rob.Paveza@microsoft.com> Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#80320}
-
- 26 Mar, 2022 1 commit
-
-
jameslahm authored
... with zero cost. Bug: v8:9357 Change-Id: I66985c3fd3e7b4efa354eb564c641562cf55ab49 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3518909Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#79632}
-
- 10 Jan, 2022 1 commit
-
-
Benedikt Meurer authored
When creating a new JSError object (or using the non-standard API `Error.captureStackTrace`) V8 would previously capture the "simple stack trace" (as FixedArray of CallSiteInfo instances) to be used for the non- standard `error.stack` property, and if the inspector was active also capture the "detailed stack trace" (as FixedArray of StackFrameInfo instances). This turns out to be quite a lot of overhead, both in terms of execution time as well as memory pressure, especially since the information needed for the inspector is a proper subset of the information needed by `error.stack`. So this CL addresses the above issue by capturing only the "simple stack trace" (in the common case) and computing the "detailed stack trace" from the "simple stack trace" when on demand. This is accomplished by introducing a new ErrorStackData container that is used to store the stack trace information on JSErrors when the inspector is active. When capturing stack trace for a JSError object while the inspector is active, we take the maximum of the program controlled stack trace limit and the inspector requested stack trace limit, and memorize the program controlled stack trace limit for later formatting (to ensure that the presence of the inspector is not observable by the program). On the `standalone.js` benchmark from crbug.com/1283162 (with the default max call stack size of 200) we reduce execution time by around 16% compared to ToT. And compared to V8 9.9.4 (the version prior to the regression in crbug.com/1280831), we are 6% faster now. Doc: https://bit.ly/v8-cheaper-inspector-stack-traces Bug: chromium:1280831, chromium:1278650, chromium:1258599 Bug: chromium:1280803, chromium:1280832, chromium:1280818 Fixed: chromium:1283162 Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78542}
-
- 15 Dec, 2021 1 commit
-
-
Benedikt Meurer authored
This is the final change list in the list of refactorings to split off the implementations of v8::StackFrame and CallSite objects (as used by the V8 JavaScript stack API). See https://bit.ly/v8-stack-frame for the whole story. This CL adds the v8::internal::StackFrameInfo class as new backing implementation of v8::StackFrame, and puts it into debug-objects.tq to indicate that it's used for the debugger API only. This new class is lightweight and only holds on to static information about the stack frame, and is thus usable for the V8 inspector to implement async stack traces in a cheaper manner going forward. Doc: https://bit.ly/v8-stack-frame Bug: chromium:1258599, chromium:1278650 Fixed: chromium:1278647 Change-Id: I4dbf2d850f47797263af225895129499169aad02 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302794 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#78382}
-
- 14 Dec, 2021 1 commit
-
-
Benedikt Meurer authored
This is the second step in the refactoring to make v8::StackFrame more lightweight and usable for (long time storage) by the V8 inspector (see https://bit.ly/v8-stack-frame for an overview). This is a purely mechanical change without any functional aspects. The intention is to make the use case for the CallSiteInfo objects clear, namely to serve as the backing store for the CallSite objects exposed via the Error.prepareStackTrace() API and used under the hood to implement the error.stack accessor. Doc: https://bit.ly/v8-stack-frame Bug: chromium:1258599, chromium:1278647, chromium:1278650 Change-Id: I39dffd1f1a8e5158ddc56f2a0a2b1b28321f487a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300138Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78361}
-
- 08 Dec, 2021 1 commit
-
-
Benedikt Meurer authored
On the way to a cheaper and more scalable stack frame representation for the inspector (crbug/1258599), this removes the need to expose both what was called "function name" and what was called "function debug name" on a v8::StackFrame instance. The reason to having a distinction between that the V8 API exposes and what the inspector exposes as frame function name is that after the initial refactoring around v8::internal::StackFrameInfo, some wasm cctests would still dig into the implementation details and insist on seeing the "function name" rather than the "function debug name". This CL now addresses that detail in the wasm cctests and going forward unifies the function names used by the inspector and the V8 API (which is not only needed for internal consistency and reduced storage requirements in the future, but also because Blink for example uses v8 API and v8_inspector API interchangeably and assumes that they agree, even though at this point Blink luckily wasn't paying attention to the function name): - The so-called "detailed stack trace", which is produced for the inspector and exposed by the v8 API, always yields the "function debug name" (which for example in case of wasm will be a WAT compatible name), - while the so-called "simple stack trace", which is what is used to implement the CallSite API and underlies Error.stack continues to stick to the "function name" which in case of wasm is not WAT compatible). Bug: chromium:1258599 Change-Id: Ib15d038f3ec893703d0f7b03f6e7573a38e82b39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312274Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78283}
-
- 06 Dec, 2021 1 commit
-
-
Igor Sheludko authored
In particular * use variadic templates in BodyDescriptorApply(), * ensure all the relevant classes have BodyDescriptor definition, * ensure "objects-body-descriptors[-inl].h" headers are included only where necessary. Bug: v8:12425 Change-Id: I7a95ed94bf62952e3d22d419d4a65ad2fe959d57 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312273Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78242}
-
- 29 Sep, 2021 1 commit
-
-
Seth Brenith authored
I'm trying to remove annotations and make behavior more consistent. For @generatePrint, there are two options: either generate printers for every extern class, or never generate printers for extern classes. This change implements the option of always generating printers. Classes that require custom printing can easily hide the generated printer by using DECL_PRINTER. This causes the generated file gen/torque-generated/objects-printer.cc to grow to 1600 lines, including many functions that are never used, but I think the consistency benefit outweighs a little more compilation time on one file. This change also removes custom printers in cases where the generated printer includes all of the same content. If folks would prefer the option to never generate printers, I'm open to doing that instead. I like the notion that generating more code could reduce the friction of adding new classes and thereby encourage people to define precise types rather than using FixedArrays, but the current implementation of generated printers is limited, and many printers have been customized to show the data that matters the most. Unlike verifiers and body descriptors, there are no correctness or safety concerns with hand-written printers. Some bugs showed up once we start generating printers for everything, and this change fixes them: - Printers incorrectly included ungettable fields like padding - Printers called getters which might be hidden by hand-written classes - The generated getter for Map::instance_type used ReadField<InstanceType>, which is not an arithmetic type since it's an enum One more tiny drive-by fix: added a missing newline in the printers for JSMap and JSSet. Bug: v8:7793 Change-Id: Ib9e9575fbcb57879935ff18bf4db49fe276d2966 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172190Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77152}
-
- 18 Jun, 2021 1 commit
-
-
Igor Sheludko authored
Namely, - StackFrameInfo::code_object - DependentCode's code entries - OSROptimizedCodeCache's code entries Bug: v8:11880 Change-Id: I49bc28f2935dd1561901932a2dfe0bf01bc6836e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969824Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75234}
-
- 11 Mar, 2021 3 commits
-
-
Clemens Backes authored
This is a reland of 80f5dfda. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
-
Clemens Backes authored
This reverts commit 80f5dfda. Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} Bug: v8:11238 Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866 Auto-Submit: Clemens Backes <clemensb@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#73346}
-
Clemens Backes authored
This is the biggest chunk, including - all of src/wasm, - torque file for wasm objects, - torque file for wasm builtins, - wasm builtins, - wasm runtime functions, - int64 lowering, - simd scala lowering, - WasmGraphBuilder (TF graph construction for wasm), - wasm frame types, - wasm interrupts, - the JSWasmCall opcode, - wasm backing store allocation. Those components are all recursively entangled, so I found no way to split this change up further. Some includes that were recursively included by wasm headers needed to be added explicitly now. backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc because it only tests wasm backing stores. This file is excluded from no-wasm builds then. R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org Bug: v8:11238 Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#73344}
-
- 03 Mar, 2021 1 commit
-
-
Alex Kodat authored
These simplify production of extra information in stack traces or dereferencing source maps in processing stack traces. While these can be managed externally, this can be very complicated in environments where scripts come from many different sources, possibly not even under embedder control. Since V8 already has easy access to this information, it's nice to share it with embedders. Bug: v8:11509 Change-Id: Ic5a1685adf4cdf456bdf7191ce815f728cf491e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2724571Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#73148}
-
- 15 Feb, 2021 1 commit
-
-
Benedikt Meurer authored
Previously we had cached the source position information on JSStackFrame (C++) objects and reused that between calls to GetLineNumber() and GetColumnNumber(). The refactoring in https://crrev.com/eed0d27c2f774b3adbc85d0a5fb30a8cf0f018a8 effectively removed that cache, while still making things faster though. This CL puts back the caching on the StackFrameInfo objects by reusing the `offset` slot to store the computed source position (as indicated by a bit in the `flags`). For promise combinator async frames, the bit is always set and the `offset_or_source_position` slot thus always contains the source position (aka the `promise index` in this case). We also added a `StackFrameInfo::ComputeLocation()` method to remove the last remaining place where we'd peek into the StackFrameInfo from outside stack-frame-info.{cc,h}. Also-By: kimanh@chromium.org Bug: chromium:1077657, v8:8742, chromium:1069425 Change-Id: I59e26a91965617163776e6cc2610b88e6925452c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695386 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72752}
-
- 12 Feb, 2021 1 commit
-
-
Benedikt Meurer authored
Following up on https://crrev.com/c/2689185, this CL significantly simplifies the whole implementation of the stack trace capturing. Before this CL, capturing any stack trace (for the purpose of the API or Error.stack) would roughly work like this: 1. The CaptureStackTrace() function uses the StackFrameIterator to walk the system stack. For each native frame it uses the FrameSummary abstraction to get all (including potentially inlined) frames. For each of those it appends a record consisting of six elements to a FrameArray (this holds pointers to the actual closures and receivers). 2. Afterwards the FrameArray is shrinked to the required size, and a new FixedArray is allocated, and initialized with new StackTraceFrame objects where each holds a reference to the FrameArray, the index of the frame, and an initially uninitialized StackFrameInfo reference. This new FixedArray is then returned from CaptureStackTrace() and either stored on a message object or provided to the API as v8::StackTrace. The new approach removes a lot of the machinery in between and directly creates a FixedArray of StackFrameInfo objects in CaptureStackTrace(). These StackFrameInfo objects are directly exposed as v8::StackFrame on the public API, and they hold the six fields that were previously stored flat in the FrameArray. This not only avoids a lot of copying around of data and creation of temporary objects and handles, but most importantly unifies and simplifies the stack frame function inside StackFrameInfo, so you no longer need to wonder which function / object might be responsible for a certain API. There's still a lot of room for improvement. In particular we currently don't cache the source position for a given StackFrameInfo (or globally), but rather recompute it every time. This is still very fast, significantly faster than the previous approach. There are some notable (potentially user visible) changes: - The CallSite#GetPosition() method now consistently returns the Wasm module relative bytecode offset for all Wasm frames (previously it'd return the function relative bytecode offset for non-asm.js Wasm frames). - The column and line numbers returned from StackFrameInfo methods are consistently 1-based now, instead of sometimes being 0-based (Wasm) and sometimes being 1-based (JS and asm.js Wasm). The only potentially noticable difference is that for CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but that was wrong and useless anyways. - CallSite#GetThis() would sometimes return the_hole, another bug flushed out by this CL. The CL also contains some other not noteworthy drive-by-cleanups. Fixed: chromium:1057211 Bug: chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#72694}
-
- 11 Feb, 2021 1 commit
-
-
Benedikt Meurer authored
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}
-
- 28 Oct, 2020 1 commit
-
-
Tobias Tebbi authored
This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
-
- 25 Sep, 2020 1 commit
-
-
Tobias Tebbi authored
This is a reland of 64caf2b0 Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} Bug: v8:7793 TBR: hpayer@chromium.org jgruber@chromium.org Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70137}
-
- 22 Sep, 2020 2 commits
-
-
Francis McCabe authored
This reverts commit 64caf2b0. Reason for revert: Seems to be causing a failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809? Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} TBR=jgruber@chromium.org,tebbi@chromium.org Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70065}
-
Tobias Tebbi authored
This is to establish a naming rule for Torque-generated files: - If the file is called foo/bar-tq..., then it is derived from a file foo/bar.tq - Otherwise it doesn't belong to a specific .tq file. So far, we attached -tq to all Torque-generated file names, where it sometimes corresponded to a .tq file name and sometimes not. It is not necessary to add -tq to file names to indicate that they are Torque-generated, since they are already in a directory called torque-generated, and we always refer to them as "torque-generated/filename", so there is no confusion even though some files now have the same name as a corresponding hand-written file, for example factory.cc. TBR: hpayer@chromium.org Bug: v8:7793 Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70060}
-
- 29 May, 2020 1 commit
-
-
Seth Brenith authored
This is a partial reland of https://crrev.com/c/v8/v8/+/2199640 . Change-Id: I528e43b8f6c5159148c16f1e2985efce2f1c2ec6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216307Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#68075}
-
- 26 May, 2020 1 commit
-
-
Seth Brenith authored
This reverts commit 4e5fabae. Reason for revert: performance regressions chromium:1085305, chromium:1084978 Original change's description: > [torque][cleanup] Use more precise field types in a few classes > > This change updates some Torque-defined classes to include more precise > field types where possible. It also updates those classes to use > @generateCppClass. One field was removed because it's unused > (PrototypeInfo::validity_cell), and two fields in StackFrameInfo > actually became less precise because they're based on Script::name, > which is an embedder-provided untyped Local<Value>. (Automatically > generated accessors pointed out this bug easily.) > > This change also includes a couple of minor fixes in Torque. > > Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67907} TBR=ulan@chromium.org,tebbi@chromium.org,verwaest@chromium.org,seth.brenith@microsoft.com Change-Id: I720821d8dc84ea0d79eb137f1c2507f75df9a107 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211322Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67972}
-
- 19 May, 2020 1 commit
-
-
Seth Brenith authored
This change updates some Torque-defined classes to include more precise field types where possible. It also updates those classes to use @generateCppClass. One field was removed because it's unused (PrototypeInfo::validity_cell), and two fields in StackFrameInfo actually became less precise because they're based on Script::name, which is an embedder-provided untyped Local<Value>. (Automatically generated accessors pointed out this bug easily.) This change also includes a couple of minor fixes in Torque. Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67907}
-
- 13 May, 2020 1 commit
-
-
Marja Hölttä authored
We can't attach a meaningful stack trace to the AggregateError Promise.any rejects with, but we can augment the individual errors' stack traces with Promise.any and the index of the corresponding Promise in the input. Bug: v8:9808 Change-Id: I7ba754c9b043594decaac8b3a23be74f05c3dffd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198983 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#67778}
-
- 18 Mar, 2020 1 commit
-
-
Tobias Tebbi authored
In the runtime, we always had a convention to use int-typed accessors for Smi fields. For Torque-generated classes, we kept them Smi-typed but then added int wrappers around that. This CL makes Torque generate int-typed accessors directly, removing the need for these wrappers. TBR=hpayer@chromium.org Bug: v8:7793 Change-Id: I348e1d96295c9676fafda32b7d49088848527f89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106210 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#66760}
-
- 20 Feb, 2020 1 commit
-
-
Kim-Anh Tran authored
Add a test case to ensure that a wasm stack trace prints the source url if it is available. Bug: v8:9762 Change-Id: If44f440529d6017d08e477aa03328c9f40f4244c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064215Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#66363}
-
- 05 Nov, 2019 1 commit
-
-
Eric Leese authored
Currently there are two ways wasm locations are represented in the inspector. This remains unchanged for now. Also, currently there are multiple ways location is represented within V8, with the line number sometimes being a function index and sometimes being 0, and the column number being a byte offset which is sometimes function relative and sometimes module relative. With this change, the line number is never used within V8 (it is always 0), and the column number is always a byte offset from the beginning of the module. This simplifies translation logic and keeps it in one place, and will simplify future changes to wasm location representation in the inspector API. Bug: chromium:1013527 Change-Id: I8813d47c881988f9ab49d7529fb81fe10dbbccff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886915 Commit-Queue: Eric Leese <leese@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64774}
-
- 10 Sep, 2019 1 commit
-
-
Bill Budge authored
- Eliminates non-const reference parameters in src/objects. Bug: v8:9429 Change-Id: Ic39a59d54bda26c622db29f07143055c3cc6c7a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1794683Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#63650}
-
- 29 Aug, 2019 1 commit
-
-
Seth Brenith authored
This patch is mostly mechanical. A few changes in implementation-visitor.cc might be worth mentioning: - Don't generate both field offset macros and class definitions for the same class. This was mostly just to keep me from forgetting to remove the DEFINE_FIELD_OFFSET_CONSTANTS part when converting classes, but also helpfully flagged that FixedArrayBase wasn't using the generated class that it requested. - Generate forward declarations for all tq-defined classes in internal-class-definitions-tq.h. This is helpful for making things compile when classes have fields of other class types. - When generating accessors for union types, use the nearest class type that contains the entire union rather than plain Object. This is important for compile-time type safety. It also required a few minor fixes elsewhere (isolate.cc, modules.cc, scope-info.cc, source-text-module.cc, and a correction of the field types in CallHandlerInfo to match how they're set in api.cc). Change-Id: I3b9280e30779ce57fb9f3629eecfec898e26d708 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774976Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63458}
-
- 08 Aug, 2019 1 commit
-
-
Jakob Kummerow authored
Change-Id: Ic5145b7ba15ae58d15e2cc4511afc2f8c6d42ea0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741654 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#63132}
-
- 08 Jul, 2019 1 commit
-
-
Clemens Hammacher authored
Due to a rebase, those annotations were missing in https://crrev.com/c/1687891. TBR=mlippautz@chromium.org Bug: v8:9429 Change-Id: I78ff2903dbbe1054499d4768e9ff5fb0c5f4b708 No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690826Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62552}
-
- 04 Jul, 2019 1 commit
-
-
Simon Zünd authored
This CL moves the code responsible for serializing a stack trace frame into a string, out of messages.cc and into stack-frame-info.cc. Instead of symbolizing the stack trace frame while serializing, the code is changed to work on top of StackTraceFrame and StackFrameInfo objects. The result is that the serialization code no longer cares when a stack trace frame is symbolized. Symbolization could happen eagerly during capturing, or lazily the first time any of StackFrameInfo fields are accessed. Drive-by: Existing users of StackFrameBase::ToString are adapted to the new SerializeStackTraceFrame API. This includes Isolate::PrintCurrentStackTrace, which is changed to re-use the existing capturing and serializing mechanism. Bug: v8:8742 Change-Id: Ic7fd80668c9d993e99d586ef7fe022850104c34f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631414 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62522}
-
- 11 Jun, 2019 1 commit
-
-
Simon Zünd authored
This CL is the starting point to convert all FrameArray users to use StackTraceFrame objects instead. Bug: v8:8742 Change-Id: I7bd0081dfd428e9914dedebd5065ac262aacec0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627332Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#62076}
-
- 06 Jun, 2019 1 commit
-
-
Simon Zünd authored
This CL adds the last fields needed to stringify all stack frames from StackFrameInfo objects instead of accessing the FrameArray directly. Drive-by-change: The factory method that creates StackFrameInfo is refactored to: 1. collect all values for the fields 2. allocate a StackFrameInfo 3. set all the values on the allocated info object. This fixes undefined evaluation order bugs that GCMole failed to spot, as well as make one factory method unnecessary. Note: More precise types on the fields that are currently "Object" will happen in a follow up CL. Bug: v8:8742 Change-Id: Ia8c55fc128434f27aadeba78e8483d90296abe3a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1641242Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#62010}
-
- 23 May, 2019 1 commit
-
-
Simon Zünd authored
This CL adds all fields to StackFrameInfo that are necessary to stringify a stack trace frame. This is another step towards disentangling symbolizing and serializing: - Symbolization collects all the necessary strings, numbers and flags for a stack trace frame. - Serialization turns the symbolized stack trace frame into a string. Drive-by: Moves the lazy initialization of StackFrameInfo into the private getter. Bug: v8:8742 Change-Id: Ic3e0fb6b3d0f0e260014af44380f1f30216b1b26 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627346Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#61784}
-
- 06 May, 2019 1 commit
-
-
Simon Zünd authored
This CL extends the stack frame API to include a flag to distinguish between user and V8 builtin frames. The intention is to extend the API in a later CL, so stack traces include builtin frames. This flag gives embedders more control what to do with builtin frames. R=jgruber@chromium.org, yangguo@chromium.org Bug: v8:8742 Change-Id: Ieda5782dd2073c1e7fd49492bfdfa829a43dc710 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583723Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#61233}
-
- 16 Apr, 2019 1 commit
-
-
Paolo Severini authored
Converted InterpreterData, JSDataView, StackTraceFrame, WasmDebugInfo, WasmExportedFunctionData to torque. Bug: v8:8952 Change-Id: I424edc04fd3f7a62d72f546dee898919d7a726df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1542504Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#60878}
-
- 05 Apr, 2019 1 commit
-
-
Simon Zünd authored
As part of one of the stack trace refactorings, this field moved from StackFrameInfo to the StackTraceFrame class, but was not properly removed. R=petermarshall@chromium.org Bug: v8:8742 Change-Id: I18b9bd7650eed0f5bdb0823da9fdefb6afa3491e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550800Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60659}
-
- 01 Mar, 2019 2 commits
-
-
Tobias Tebbi authored
To make it obvious these are not defined in C++. Bug: v8:7793 Change-Id: Ib846023992e32ddd10dadc3834ce42b7604a1f48 Reviewed-on: https://chromium-review.googlesource.com/c/1495993Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59978}
-
Seth Brenith authored
I tried to use more specific union types where appropriate, even though many of these fields are accessed as Object from C++. Bug: v8:7793 Change-Id: I771d9b6459bdc1413019f8ff5ddfd611d1adf61f Reviewed-on: https://chromium-review.googlesource.com/c/1490573 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59975}
-