While clang++ doesn't mind, g++ complains about apostrophes in #error
messages as they appear to be unterminated single-quoted literals. So
add surrounding double-quotes.
Bug: v8:11292
Change-Id: Ib263cb20c73650348599992186a0e7de11b1b306
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639763
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72192}
This change adds Torque field definitions for ScopeInfo and begins to
use the Torque-generated accessors in some places. It does not change
the in-memory layout of ScopeInfo.
Torque compiler changes:
- Fix an issue where the parser created constexpr types for classes
based on the class name rather than the `generates` clause. This meant
that generated accessors referred to the imaginary type HashTable
rather than the real C++ type FixedArray.
- Don't pass Isolate* through the generated runtime functions that
implement Torque macros. Maybe we'll need it eventually, but we don't
right now and it complicates a lot of things.
- Don't emit `kSomeFieldOffset` if some_field has an unknown offset.
Instead, emit a member function `SomeFieldOffset()` which fetches the
slice for some_field and returns its offset.
- Emit an `AllocatedSize()` member function for classes which have
complex length expressions. It fetches the slice for the last field
and performs the multiply&add to compute the total object size.
- Emit field accessors for fields with complex length expressions, using
the new offset functions.
- Fix a few minor bugs where Torque can write uncompilable code.
With this change, most code still treats ScopeInfo like a FixedArray, so
I would like to follow up with some additional changes:
1. Generate a GC visitor for ScopeInfo and use it
2. Generate accessors for struct-typed fields (indexed or otherwise),
and use them
3. Get rid of the FixedArray-style get and set accessors; use
TaggedField::load and similar instead
4. Inherit from HeapObject rather than FixedArrayBase to remove the
unnecessary `length` field
After that, there will only be one ugly part left: initialization. I
think it's possible to generate a factory function that takes a bunch of
iterator parameters and returns a fully-formed, verifiably correct
ScopeInfo instance, but doing so is more complicated than the four
mostly-mechanical changes listed above.
Bug: v8:7793
Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72187}
Doing a function call into the logger to decide whether logging is
enabled or not is more costly than necessary.
This CL changes logging to take FLAG_log as main signal whether logging
could be active. If FLAG_log == false, logging cannot be active. In
that case we always call into the logger and perform detailed checks
there.
This CL changes flag-definitions to set FLAG_log if they need logging.
Change-Id: Ia51ed9fb7128451bf1dcf345fab257547aab4a47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602461
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72186}
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}
Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI
Modify that C++ backend so that it can emit either runtime C++ or
postmortem debugging code. When in postmortem debugging mode, the
overall code structure would look similar with some difference:
1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor.
2. Instead of runtime class names like String, we use uintptr_t
3. When loading data from objects, instead of TaggedField<T>::load or
Object::ReadField (which read from the current process), we use the
MemoryAccessor and read data from the debuggee process.
4. Return values should be wrapped in the Value struct.
Implement the debug accessors for complex length expressions and add
test for such class (SmallOrderedHashSet).
Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72148}
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}
This reverts commit 4d5b878b61.
Reason for revert: Suspected to cause a failure on ChromeOS, which is blocking the roll - https://chromium-review.googlesource.com/c/chromium/src/+/2636263
Original change's description:
> [super] Store home object in Context instead of JSFunction
>
> 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
> Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72137}
TBR=marja@chromium.org,leszeks@chromium.org
Change-Id: Idc5a8240cef4da8893ccc608ee4ae0d7206a1ba8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637215
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72142}
Adds a v8-gn.h file containing defines that are used in the
externally-visible headers files like v8.h. This must be included by
include/v8config.h which includes it if the GN flag
v8_generate_external_defines_header is on. (Currently off by default).
To enable the v8config.h file to be included without the other v8
headers (as required by cppgc), this moves it into its own header set
which sets up the include path correctly.
Also updates some headers to ensure v8config.h is included before using
externally-visible defines.
Bug: v8:11292
Change-Id: I5be634f4adfbef144bf684071461d64f1cb30899
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2608212
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72140}
Removes:
- v8_disable_arguments_adaptor GN flag
- ArgumentsAdaptorTrampoline
- ArgumentsAdaptorFrame class
Change-Id: I382ebe6c25c3c172bee5df3e86e762fca10fa392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622911
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72133}
This reverts commit b3d09001eb.
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}
Make sure gcmole detects issue in DisallowGarbageCollection scopes.
DisallowGarbageCollection is widely used in the codebase to document
code that doesn't allocate. However, this has the rather unexpected
side-effect that gcmole is not run when such a scope is active.
This CL changes the default behavior of gcmole to run even with
DisallowGarbageCollection scopes present. This will give us the best
results of both worlds, dynamic checks by the fuzzer, and static
analysis by gcmole.
To allow crazy local raw pointer operations there is a new
DisableGCMole scope that explicitly disables gcmole.
Change-Id: I0a78fb3b4ceaad35be9bcf7293d917a41f90c91f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615419
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72039}
For simplicity this CL includes a first crude conversion of
tickprocessor.mjs. Later CLs will introduce more ES6 syntax and clean
up more code.
Bug: v8:10667
Change-Id: Ief2ca623f5562114fb976a95d156e2ab3f961114
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2611252
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72013}
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}
Change the background of source position markers based on the events
they link to.
Bug: v8:10644
Change-Id: I108d9f5670acdaf5835905c2b44648c0eaf6dbd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2604708
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71970}
The IC object's interface is changing all the time and this code is
just bitrotting. Rather than trying to keep this updated all the time,
let's just use Object.values to print all the key value pairs in the
ic object.
This looks slightly worse than the previous text format but it has the
critical advantage of being broken less often.
Change-Id: Ia3580d1ba82a981d8442682f66d6002436e70f42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615418
Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71969}
Previously we had introduced a special `v8::internal::WasmValue` type
which we used to expose Wasm values to the Scope view in Chromium
DevTools. The problem however is that these values cannot be exposed to
JavaScript (and in particular not to Debug Evaluate), which means that
particularly for v128 and i64 we have inconsistent representations
across the various parts of DevTools.
This change removes the `wasm` type from the RemoteObject and all the
adjacent logic, and paves the way for a uniform representation of Wasm
values throughout DevTools. For i64 we will simply use BigInt
consistently everywhere, and for i32, f32 and f64 we'll just use Number.
For externref we will represent the values as-is directly. For v128
values we currently use a Uint8Array, but will introduce a dedicated
WasmSimd128 class in a follow-up CL.
Bug: chromium:1071432
Fixed: chromium:1159402
Change-Id: I0671e5736c9c27d7ca376e23ed74f16d36e03c80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614428
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71962}
Prepare the system analyzer to be able to select events related to a
a single code log entry.
- Rename source-panel to script-script panel
- Update main index.css to support selects in the panel selection
header
Bug: v8:10644
Change-Id: Ie8dd1839294687cb9e25995bcb7ef246a7d7f48d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2604707
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71948}
Design doc:
https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U
A lot has changed since the last patchset! I recommend revisiting this
design doc and reading the parts in green. I explain the roadmap for
what changes to expect from ETW instrumentation as well as the
instrumentation of this particular CL.
I'll do my best to answer any further questions anyone has about my
particular instrumentation or ETW in general :)
---
This is the first of a series of changelists to round out ETW
instrumentation for V8.
This changelist represents the most minimal change needed to instrument
ETW in V8. In particular, it:
- defines and registers the ETW provider,
- interacts minimally with the rest of V8, by hooking into the
existing TracingController::AddTraceEvent function,
- is designed with a platform-agnostic layer, so that event tracers
for other platforms can be instrumented in teh future.
Some notes on instrumentation (aka I copied stuff from the design doc):
We make heavy use of the TraceLogging API to log events. It differs from
previous methods of emitting ETW events in that it doesn<E2><80><99>t
require the overhead of a separate manifest file to keep track of
metadata; rather, events using this API are self-descriptive.
Here are the five major steps to instrument the TraceLogging API:
- Forward declare the provider (from provider-win.h)
- Define the provider in a .cc file (from provider-win.cc)
- Register the provider (called from v8.cc).
- Write events (called from libplatform/tracing-controller.cc)
- Unregister the provider (called from v8.cc)
At the base, we have an abstract provider class that encapsulates the
functionality of an event provider. These are things like registering
and unregistering the provider, and the actual event-logging.
The provider class is split into provider-win and provider-mac
(currently not instantiated) classes, with OS-dependent implementations
of the above functions.
In particular, the TraceLogging API is used only in provider-win. It is
here that we forward declare and define the provider, as well as write
ETW events.
Finally, there is a v8-provider class that serves as a top-level API and
is exposed to the rest of V8. It acts as a wrapper for the
platform-specific providers.
The .wprp file is needed so that Windows Performance Recorder knows how
to capture our events.
Some considerations:
- Is TracingController::AddTraceEvent the best place from which to
write my events?
- Is src/libplatform/tracing the best place to put my instrumentation?
- Right now, I fail the preupload because of this, which tells me my
files are probably not in the best location:
You added one or more #includes that violate checkdeps rules.
src\init\v8.cc Illegal include: "src/libplatform/tracing/v8-provider.h"
Because of "-src/libplatform" from src's include_rules.
Change-Id: Id53e4a034c9e526524a17000da0a647a95d93edf
Bug: v8:11043
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233407
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Sara Tang <sartang@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71918}
The negative implication from --single-threaded to --liftoff was
introduced because with --single-threaded, no tier-up to TurboFan is
possible, and TurboFan provides faster code and smaller code
This CL removes this implication. The reason is that this implication
does not only define the default compiler for --single-threaded to
TurboFan, and also completely disables the option to use Liftoff
instead. By removing the implication, and embedder who uses
--single-threaded can decide by themselves if they want to use Liftoff
by setting --liftoff, or if they don't want to use Liftoff by setting
--no-liftoff.
R=clemensb@chromium.org
Bug: v8:11279
Change-Id: Ie6e64a42823b87484135364ecb4589cfd188db5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599548
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71917}
- Fix landing page
- Introduce and use SelectRelatedEvent for centralising the logic of
finding and showing related LogEntries. It also clears the selection
of all list panels if there are no related entries.
- Add "select related" button to the script-panel to show events only
from the currently selected script
- Add selection type tabs for the map-panel
- Fix transition colors for map-transitions view
- Introduce separate map-transition view for the currently selected Map
Bug: v8:10644
Change-Id: I4199a8332bab2518d98078712ed5ce9a8f1dc19e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599555
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71849}
This allows the JSFunctionOrBoundFunction instance type range to no
longer be stuck at the last of the JSObject instance type range. This
will be useful in the future where we extend the function instance
types and include them in fast protector cell checks.
Bug: v8:11256
Change-Id: I955991576b3cca76b10f76c87748016fe527e3d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595275
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71826}
Concurrent inlining is enabled for TurboProp compiles, but we don't
enable the --concurrent-inlining flag so don't also set the implied
turbo_direct_heap_access flag. This CL fixes this.
BUG=v8:9684
Change-Id: I298febdf7c466385047f420d4c33ca0162778210
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593344
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71804}
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}
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}
Associate DeoptLogEntry with both, the function's source position and
the deopt location's source position.
Also fixes the list-panel click handler to support all clickable entry
types.
Bug: v8:10644, v8:10754
Change-Id: If10272a926d5dad10b29322e237610900715b9dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584955
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71732}
This commit updates the gen-postmortem-metadaa.py script to
incorporate changes in V8 8.5. This removes the need to float a
patch to the script in Node.js.
Change-Id: I6532495bee906f51eb2b773ec38ff0a6e404dafe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2582705
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#71699}
This commit updates the gen-postmortem-metadata.py script to
incorporate changes in V8 8.4. This removes the need to float a
patch to the script in Node.js.
Change-Id: I69da40e792f22748b0eee2952b9009b2f03d13f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565275
Reviewed-by: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#71646}
This cl extends profview to
1. Show Turboprop ticks in a different color in timeline panel
2. In summary panel, show Turboprop optimizations and TurboFan
optimizations as two different entries
3. Fix deopts in summary panel after the rename to deopts
4. Also show information about bailouts (happen only with Turboprop)
Bug: v8:9684
Change-Id: I028b12a55741c789ecc1d212d1517a57496379dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2573477
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71638}
Improve the performance of gcmole by
* Precompiling the regexes in GCSuspectsCollector.Resolve
* Merging those regexes into a single regex, using '|'
* Changing multiprocess clang plugin invocation to threaded (running
the plugin releases the GIL so this can efficiently thread). This
uses a simple worker pool with a single work queue.
* Change clang plugin invocation loop to yield after each invocation.
This pipelines the dump-callees plugin and GCSuspectsCollector
Parse/Resolve, so that the parse can happen while waiting for other
callee dumps to finish.
Change-Id: Ib9fca70dbcfd2f9d1aebc8bd11aa1d1f7d34e24a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562242
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71617}
Also construct the `JSMap`s used to store these names lazily and
only on-demand, and construct them directly instead of first doing
a `std::vector<Handle<String>>` and using that to construct the
`JSMap`. The latter resulted in a gigantic root set of 150k+ handles,
which wasn't well received by the GC.
Bug: chromium:1154154
Fixed: chromium:1154564
Also-By: bmeurer@chromium.org
Change-Id: I92e8931f15eda133e2a62b5cc53fbe1f2dafcead
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2568275
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71589}
