- 17 Feb, 2021 3 commits
-
-
Seth Brenith authored
ScopeInfo has a vestigial 'length' field from when it used to be a FixedArray. This change removes that field, which saves some memory. More specifically: - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which supplied the 'length' field. - Privatize the FixedArray-style functions that provide access to ScopeInfo fields by index, and move them from scope-info-inl.h to scope-info.cc. Those functions are still used pretty heavily during initialization (ScopeInfo::Create, etc.), but at least we can avoid presenting them to the rest of the world. - Change FactoryBase::NewScopeInfo to allocate the updated object shape. It maintains the existing behavior of filling the newly-allocated object with undefined, even though that's not a valid ScopeInfo and further initialization is required. - Move part of AccessorAssembler::ScriptContextTableLookup into a new Torque macro, because it used to rely on casting ScopeInfo to FixedArrayBase. - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are arrays. I think it makes more sense to list them under "(system)" in the dev tools, like most other V8 internal types. Bug: v8:8952 Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72830}
-
Bill Budge authored
This reverts commit 2f8a7561. Reason for revert: Speculative revert, lots of segfaults on Arm: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/17781 Original change's description: > [dict-proto] C++ implementation of SwissNameDictionary, pt. 3 > > 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 adds the initialization code, factory functions and a > canonical SwissNameDictionary plus all helpers required for that. > > Bug: v8:11388 > Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Frank Emrich <emrich@google.com> > Cr-Commit-Position: refs/heads/master@{#72824} Bug: v8:11388 Change-Id: Ia5dae584b0fb452b12c5d64ee63ffa418c83f91b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698758 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#72829}
-
Frank Emrich authored
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 adds the initialization code, factory functions and a canonical SwissNameDictionary plus all helpers required for that. Bug: v8:11388 Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Frank Emrich <emrich@google.com> Cr-Commit-Position: refs/heads/master@{#72824}
-
- 16 Feb, 2021 1 commit
-
-
Milad Fa authored
As of https://crrev.com/c/2629465, Simd tests cannot pass on architectures without Simd support. Tests will need to be re-enabled once Simd support is fully implemented on PPC. Change-Id: I963639f1afa0c0ca7be3ca4b2fc06e874235b903 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2693056Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#72788}
-
- 15 Feb, 2021 2 commits
-
-
Michael Achenbach authored
Change-Id: I72964af375a5dbaaa8a52df0c042422803aabf75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692700Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72730}
-
Michael Achenbach authored
Change-Id: I0e17d34f7c1350291c40320a1a95ea140a7d937c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692698Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72729}
-
- 12 Feb, 2021 10 commits
-
-
Benedikt Meurer authored
As outlined in the design document linked below, we're removing the support for the non-standard Function.displayName property for the purpose of Error.stack and DevTools Inspector stack traces. The motivation here is that the negative lookup is costly, and we have Function.name as a standard alternative (configurable since ES6 for exactly this reason). I dediced to go with JSFunction::GetDebugName(), since JSFunction::GetName() was confusing in that it'd only get the "name" property's value if it's a data property, but not with accessors. JSFunction::GetDebugName() makes it clear that this is really a debug helper function and might not give you the "name" property value. Doc: https://bit.ly/devtools-function-displayName-removal Bug: v8:8742, chromium:1177685, chromium:1077657, chromium:17356 Change-Id: I7717585cbace626174b2f2ed2a4f68f75429eca1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692189 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72715}
-
Michael Achenbach authored
No-Try: true Bug: v8:11442 Change-Id: I13849c9fa90fa5a971c24694db56a07cc1cccc24 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692570 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72707}
-
Michael Achenbach authored
No-Try: true Bug: v8:11442 Change-Id: I856470d95cf0b70e98e09a0ce4e8d80377e7a92a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2691052 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72706}
-
Leszek Swirski authored
Add a .status file variable for the "v8_control_flow_integrity" gn arg, and disable baseline tests for now in that configuration. No-Tree-Checks: true No-Try: true Bug: v8:11439 Change-Id: I7274a168893cfd6619ce98fdd14a692217fd56c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692206 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72698}
-
Georg Neis authored
This reverts commit 87df0b7e (thus relands 42cd9eb7), with fixes for the discovered issues. Original change's description: > Revert "[compiler] Directly read PropertyCells" > > This reverts commit 42cd9eb7. > > Reason for revert: Clusterfuzz issues, e.g. > https://bugs.chromium.org/p/chromium/issues/detail?id=1176318 > > Original change's description: > > [compiler] Directly read PropertyCells > > > > Main changes: > > > > - Introduce a new broker data kind kBackgroundSerialized for objects > > that can be serialized in the background (when direct reads are on). > > (I'm planning to remove kPossiblyBackgroundSerialized in a followup, > > in favor of a dynamic choice of kSerialized or kBackgroundSerialized). > > - Make PropertyCell use that new kind. > > - Introduce a bottleneck in runtime code for changes to PropertyCells > > and make sure that a certain protocol is followed that allows > > concurrent reads from the background thread. > > - Improve interface of PropertyCell in various ways. > > > > Bug: v8:7790 > > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > > Commit-Queue: Georg Neis <neis@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#72586} > > TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org > > Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180 > Bug: v8:7790 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125 > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72619} Bug: v8:7790, chromium:1176509, chromium:1176318, chromium:1176504 Change-Id: Icaf285912bb948432a4a2d599cd174f6a5aa296e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685166Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72697}
-
Leszek Swirski authored
Currently we sometimes refer to baseline code or the baseline compiler by its codename (Sparkplug). The codename is fun, but we should be consistent and call things by one name or the other. Following the pattern of Ignition stuff being called "interpreter", we call Sparkplug "baseline", and leave the codename only in flags and variants. Bug: v8:11420 Change-Id: I432e5629518be7c7ad38b6acff024c91d4cfd6d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692186 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72696}
-
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}
-
Ng Zhi An authored
This should also unblock V8 DEPS roll: https://chromium-review.googlesource.com/c/v8/v8/+/2689808 Bug: chromium:1177324 Change-Id: Iede2ba9c2257a2996715bcb7821ce14baa9ae9a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689089Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72687}
-
Leszek Swirski authored
Sparkplug is a new baseline, non-optimising second-tier compiler, designed to fit in the compiler trade-off space between Ignition and TurboProp/TurboFan. Design doc: https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing Bug: v8:11420 Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72686}
-
Deepti Gandluri authored
- Add a no-simd-sse flag to skip SIMD tests on bots with no hardware support. Change-Id: I4efdbb5ee39c2e10ea8776a1f1e536ac96823efe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629465 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72682}
-
- 11 Feb, 2021 3 commits
-
-
Santiago Aboy Solanes authored
Reasons: * We disabled it more than a year ago for all configs * Not easy to re-enable * Not compatible with pointer compression as-is * Not compatible with concurrent TP/TF as-is * No concrete plans to re-enable it Also remove Map's layout_descriptor since it was only used for double field unboxing. Bug: v8:11422 Change-Id: I9260906eac199213b3210712e9903f1ecf1d7979 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676637Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72671}
-
Pierre Langlois authored
Bug: v8:11361 Change-Id: Ie36b612907fab01c269567e901494d2c7ea01b6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689192Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#72654}
-
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}
-
- 10 Feb, 2021 1 commit
-
-
Georg Neis authored
This reverts commit 42cd9eb7. Reason for revert: Clusterfuzz issues, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1176318 Original change's description: > [compiler] Directly read PropertyCells > > Main changes: > > - Introduce a new broker data kind kBackgroundSerialized for objects > that can be serialized in the background (when direct reads are on). > (I'm planning to remove kPossiblyBackgroundSerialized in a followup, > in favor of a dynamic choice of kSerialized or kBackgroundSerialized). > - Make PropertyCell use that new kind. > - Introduce a bottleneck in runtime code for changes to PropertyCells > and make sure that a certain protocol is followed that allows > concurrent reads from the background thread. > - Improve interface of PropertyCell in various ways. > > Bug: v8:7790 > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72586} TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180 Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72619}
-
- 09 Feb, 2021 4 commits
-
-
Brice Dobry authored
This very large changeset adds support for RISC-V. Bug: v8:10991 Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344 Commit-Queue: Brice Dobry <brice.dobry@futurewei.com> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#72598}
-
Georg Neis authored
Main changes: - Introduce a new broker data kind kBackgroundSerialized for objects that can be serialized in the background (when direct reads are on). (I'm planning to remove kPossiblyBackgroundSerialized in a followup, in favor of a dynamic choice of kSerialized or kBackgroundSerialized). - Make PropertyCell use that new kind. - Introduce a bottleneck in runtime code for changes to PropertyCells and make sure that a certain protocol is followed that allows concurrent reads from the background thread. - Improve interface of PropertyCell in various ways. Bug: v8:7790 Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72586}
-
Frank Emrich authored
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/+/2672030Reviewed-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}
-
Benedikt Meurer authored
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/+/2643384Reviewed-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}
-
- 08 Feb, 2021 2 commits
-
-
Camillo Bruni authored
CSV Support: - Add import merged CSV from results.html - Aggregate multiple runs and calculate stddev on them Charts: - Defer rendering charts for responsive UI - Clean up chart rendering in general - Sort charts based on raw chart data for speedups - Show chart annotations - Add chart total, displaying the total value for the currently selected categories - Fix sorting by chart total - Add average row for all charts Change-Id: I1e542f319172ecf158dcb44f8da7ad6e81aafe41 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2675934Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#72562}
-
Clemens Backes authored
Update the wasm spec tests to include the memory64 proposal. Some tests are failing currently because of broken spec tests or missing v8 support. This will be addressed in follow-up CLs. R=ahaas@chromium.org CC=zhin@chromium.org Bug: v8:11401 Change-Id: I1a8f75e70f9d0828ad32c960c113f5e4c0d1a44b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679683 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#72561}
-
- 04 Feb, 2021 1 commit
-
-
Jakob Gruber authored
... 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/+/2656257Reviewed-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}
-
- 03 Feb, 2021 1 commit
-
-
Leszek Swirski authored
Fix some trailing whitespace issues in files in the tools directory. Change-Id: If9e9b1dab1d6f521e20619a2a1d093749f0528d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2671660 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72498}
-
- 02 Feb, 2021 1 commit
-
-
Leszek Swirski authored
Extract out the command processing from Simulator::Debug(), and expose it to gdb as a new 'sim' command. Example usage: (gdb) sim p x15 (gdb) sim stack The sim command will execute that one command, and will return to gdb. For a list of all commands, you can call (gdb) sim help Note that sim won't resume simulator execution until gdb continues execution; for example, `sim next` will set a breakpoint on the next instruction, and will return to gdb. The user then has to continue execution in gdb, at which point the simulator will break. The user can then re-enter gdb with the gdb command. This will look like this: (gdb) sim next (gdb) continue ... sim> gdb (gdb) ... Change-Id: I678e71e2642d8427950b5f7ed65890ceae69e18d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664448 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#72479}
-
- 01 Feb, 2021 3 commits
-
-
Liviu Rau authored
Used for testing infra change https://crrev.com/c/2650208 NOTRY=true NOPRESUBMIT=true NOTREECHECKS=true Bug: chromium:1144601 Change-Id: I93ea610c45d3cbc9557f9a13e2ccc74927720384 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659256 Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72459}
-
Ulan Degenbaev authored
The flags are enabled by default and have stable coverage. This also removes the corresponding bots. Bug: v8:10315 Change-Id: Icce01383050dff758b6554db8e0c3589d6e5459c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2658324 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72457}
-
Peter Wong authored
- 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}
-
- 29 Jan, 2021 2 commits
-
-
Ulan Degenbaev authored
The new flag: - enables --concurrent-inlining, - disables --lazy-feedback-allocation, - sets the interrupt budget to 15K. Bug:v8:7790 Change-Id: Id236763f987a6b1309f0c43a2acd150c6e3723bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652492 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72429}
-
Marja Hölttä authored
Fix 1: Track Scope::needs_home_object and Scope::uses_super_property accurately. When "eval" is seen, figure out whether it can access "super" and if yes, set the corresponding home object as needed. Fix 2: The object literal scope shouldn't be entered for things inside spreads. Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72422}
-
- 28 Jan, 2021 6 commits
-
-
Jakob Gruber authored
They've started failed, and no work is planned for the foreseeable future. Bug: v8:8888 Change-Id: I89dfa8f972a5bffa2bbb09c7a6ca56a0c4da9a02 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656316 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72407}
-
Camillo Bruni authored
ALmost all tools have migrated to .mjs modules. Bug: v8:10667 Change-Id: I95f7c4a31a721be3000c990bdac1c4eb0779b693 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642460Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#72404}
-
Benedikt Meurer authored
This adds a [[WebAssemblyMemory]] internal property to ArrayBuffer and SharedArrayBuffer instances that are owned by WebAssembly.Memory objects. This allows the devtools-frontend to find the WebAssembly.Memory for any given ArrayBuffer, making it possible to properly support WebAssembly.memory.grow() eventually, but also showing a reasonable tab title. Before: https://imgur.com/hod9jPR.png After: https://imgur.com/v195VoC.png Bug: chromium:1171621, chromium:1171619, chromium:1166577 Change-Id: Ife22cabdfcf54ab30c234ea4ca86bfbb711ab2f1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653155 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Kim-Anh Tran <kimanh@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72403}
-
Marja Hölttä authored
This reverts commit f6450b97. Reason for revert: ClusterFuzz bugs Original change's description: > Reland [super] Store home object in Context instead of JSFunction > > 1) Computed property keys (esp functions in them) shouldn't be inside > the object literal scope. > > 2) I was using an imprecise "maybe uses super" and storing it to > preparse data. This won't fly, since it pollutes sister scopes and > leads to confusion wrt whether an object literal needs a home object > or not. Made it precise (mostly cancelling changes in the original CL). > > 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for > this_function (which made it used) -> inconsistent scopes between > parsing and preparsing. > > 4) MultipleEntryBlockContextScope was messing up the accumulator > > Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 > > This saves memory (the home object doesn't need to be stored for each > method, but only once per class) and hopefully makes the home object > a constant in the optimized code. > > Detailed documentation of the changes: > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing > > Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055 > Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Marja Hölttä <marja@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72169} TBR=marja@chromium.org,leszeks@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72391}
-
Camillo Bruni authored
- Deduplicate entries when writing multiple runs into a single .txt file - Add support to load multiple files directly via url params - Display graphs after appending new files - Fix tracing .json import script Change-Id: I06349df57faf206d6a215cfc279c79d1f0dd684c No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650211 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#72390}
-
Sami Kyostila authored
Bug: chromium:1006541 Change-Id: Ia3f1b16a4becd10bd4041f35e125aad7acc33949 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653235 Auto-Submit: Sami Kyöstilä <skyostil@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#72386}
-