This reverts commit 64caf2b0b2.
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/+/2424486
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70065}
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}
For js frame, we want to display currently executing function.
Change-Id: If33b04279dafdf6e4834bfb6c7240e8e7e799fc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411483
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70018}
This reverts commit 1aa9ab7384.
The reverted CL chain had an issue where ThinStrings could accidentally
end up in compilation artifacts, causing issues down the line with ICs
that expected direct internalized strings.
The reason for this bug was that forward references to internalized
strings were resolved before PostProcessNewObject. When this happened,
the internalized string A would be written to the field where it was
previously deferred, then PostProcessNewObject would change string A to
string A', and update string A to a ThinString. This means any _future_
back references to A would see the ThinString and follow it to receive
A', but any _past_ forward references would keep pointing to the
ThinString A.
This reland fixes this by preventing InternalizedString deferral, so
that all references to InternalizedStrings are back references. It also
adds some additional verification to the heap verifier that constant
pools and object boilerplate descriptors aren't allowed to hold thin
strings.
This patch also fixes an additional bug in the original CL, where weak
forward refs weren't being serialized with a weak prefix.
Original change's description:
> Revert recent de/serializer related changes
>
> They are suspected to be causing Canary crashes, confirmed through
> local reverts and repro attempts.
>
> This reverts:
> - "Reland "[serializer] Change deferring to use forward refs""
> commit 76d684cc82.
> - "Reland "[serializer] Remove new space""
> commit 81231c23a9.
> - "[serializer] Clean-up and de-macro ReadDataCase"
> commit c06d24b915.
> - "[serializer] DCHECK deserializer allocations are initialized"
> commit fbc1f32d8e.
>
> Bug: chromium:1128872
> Change-Id: Id2bb3b8fac526fdf9ffb033222ae08cd423f8238
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414220
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69955}
Tbr: jgruber@chromium.org,dinfuehr@chromium.org
Bug: chromium:1075999
Bug: chromium:1127610
Bug: chromium:1128848
Bug: chromium:1128872
Bug: chromium:1128957
Change-Id: I8b7bbabf77eb8cb942a28316afbfaa5f9a0aa4cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418101
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69988}
This CL updates the tool instructions to reflect changes in the tool.
Removes the empty <br> tags from the tool's panel templates.
Bug: v8:10644, v8:10727
Change-Id: I0b3db6adcd37518f9cdaf2839094ef86eff52dfb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2413253
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69963}
They are suspected to be causing Canary crashes, confirmed through
local reverts and repro attempts.
This reverts:
- "Reland "[serializer] Change deferring to use forward refs""
commit 76d684cc82.
- "Reland "[serializer] Remove new space""
commit 81231c23a9.
- "[serializer] Clean-up and de-macro ReadDataCase"
commit c06d24b915.
- "[serializer] DCHECK deserializer allocations are initialized"
commit fbc1f32d8e.
Bug: chromium:1128872
Change-Id: Id2bb3b8fac526fdf9ffb033222ae08cd423f8238
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414220
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69955}
This is a reland of 0ba115e6a9
Changes compared to last reland:
- Fix Python code trying to write to expected_outcomes, which is now a
computed property.
- Fix remaining place in d8.cc that ignored the --fuzzing flag.
- Expect flag contradictions for --cache in code_serializer variant.
Original change's description:
> Reland^3 "[flags] warn about contradictory flags"
>
> Changes:
> - Also allow second parameter influenced by --cache to be reassigned.
> - Fix --stress-opt to only --always-opt in the last iteration as before.
>
> Original change's description:
> > Reland^2 "[flags] warn about contradictory flags"
> >
> > This is a reland of d8f8a7e210
> > Change compared to last reland:
> > - Do not check for d8 flag contradictions in the presence of --fuzzing
> > - Allow identical re-declaration of --cache=*
> >
> > Original change's description:
> > > Reland "[flags] warn about contradictory flags"
> > >
> > > This is a reland of b8f9166664
> > > Difference to previous CL: Additional functionality to specify
> > > incompatible flags based on GN variables and extra-flags, used
> > > to fix the issues that came up on the waterfall.
> > >
> > > This also changes the rules regarding repeated flags: While
> > > explicitly repeated flags are allowed for boolean values as long
> > > as they are identical, repeated flags or explicit flags in the
> > > presence of an active implication are disallowed for non-boolean
> > > flags. The latter simplifies specifying conflict rules in
> > > variants.py. Otherwise a rule like
> > >
> > > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > > "--gc-interval=*": ["--gc-interval=*"],
> > > }
> > >
> > > wouldn't work because specifying the same GC interval twice
> > > wouldn't actually count as a conflict. This was an issue with
> > > test/mjsunit/wasm/gc-buffer.js, which specifies
> > > --gc-interval=500 exactly like the extra flag by the stress bot.
> > >
> > > Also, this now expands contradictory flags checking to d8 flags
> > > for consistency.
> > >
> > > Original change's description:
> > > > [flags] warn about contradictory flags
> > > >
> > > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > > >
> > > > Bug: v8:10577
> > > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#68168}
> > >
> > > Bug: v8:10577
> > > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68989}
> >
> > Bug: v8:10577
> > Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69339}
>
> Bug: v8:10577
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Change-Id: I4a69dc57a102782cb453144323e3752ac8278624
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69433}
Change-Id: Ib6d2aeb495210f581ac671221c265df58e8e5e70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398640
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69954}
While the sampler checked if the sampled thread had the Isolate locked
(if locks are being used) under Linux, the check was not done under
Windows (or Fuchsia) which meant that in a multi-threading application
under Windows, thread locking was not checked making it prone to seg
faults and the like as the profiler would be using isolate->js_entry_sp
to determine the stack to walk but isolate->js_entry_sp is the stack
pointer for the thread that currently has the Isolate lock so, if the
sampled thread does not have the lock, the sampler woud be iterating
over the wrong stack, one that might actually be actively changing on
another thread. The fix was to move the lock check into CpuSampler
and Ticker (--prof) so all OSes would do the correct check.
The basic concept is that on all operating systems a CpuProfiler, and
so its corresponding CpuCampler, the profiler is tied to a thread.
This is not based on first principles or anything, it's simply the
way it works in V8, though it is a useful conceit as it makes
visualization and interpretation of profile data much easier.
To collect a sample on a thread associated with a profiler the thread
must be stopped for obvious reasons -- walking the stack of a running
thread is a formula for disaster. The mechanism for stopping a thread
is OS-specific and is done in sample.cc. There are currently three
basic approaches, one for Linux/Unix variants, one for Windows and one
for Fuchsia. The approaches vary as to which thread actually collects
the sample -- under Linux the sample is actually collected on the
(interrupted) sampled thread whereas under Fuchsia/Windows it's on
a separate thread.
However, in a multi-threaded environment (where Locker is used), it's
not sufficient for the sampled thread to be stopped. Because the stack
walk involves looking in the Isolate heap, no other thread can be
messing with the heap while the sample is collected. The only ways to
ensure this would be to either stop all threads whenever collecting a
sample, or to ensure that the thread being sampled holds the Isolate
lock so prevents other threads from messing with the heap. While there
might be something to be said for the "stop all threads" approach, the
current approach in V8 is to only stop the sampled thread so, if in a
multi-threaded environment, the profiler must check if the thread being
sampled holds the Isolate lock.
Since this check must be done, independent of which thread the sample
is being collected on (since it varies from OS to OS), the approach is
to save the thread id of the thread to be profiled/sampled when the
CpuSampler is instantiated (on all OSes it is instantiated on the
sampled thread) and then check that thread id against the Isolate lock
holder thread id before collecting a sample. If it matches, we know
sample.cc has stop the sampled thread, one way or another, and we know
that no other thread can mess with the heap (since the stopped thread
holds the Isolate lock) so it's safe to walk the stack and collect data
from the heap so the sample can be taken. It it doesn't match, we can't
safely collect the sample so we don't.
Bug: v8:10850
Change-Id: Iba6cabcd3e11a19c261c004103e37e806934dc6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411343
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69952}
I/O is quite expensive on the bots. This cuts down a bit of it by
printing slightly fewer characters per test in verbose mode.
This leads to an overall speed improvement of ~20% for large test
suites, e.g. Test262 output-collection time goes from ~2m30 to ~2m.
The averages to a 5-10% overall speed improvement for slow tryjobs.
Bug: v8:10916
Change-Id: I56dcb072af8eb32a1e09e17a05db5782c6d79315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414038
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69950}
This CL deletes the image on the timeline overview which
only reflects the last uploaded timeline-track data
and updates the timelineOverviewIndicator on mousemove and
chunk zoom events.
Bug: v8:10644
Change-Id: Ib0a43083d2461cc343a0c946cfddaf4fdc514687
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2413257
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69936}
This is needed for preserving test coverage for the mode that runs
without local heaps. Flags that depend on --local-heaps are also
disabled in this variant.
Bug: v8:10828
Change-Id: I4a3b219e5235945278d8356f4efd886a97ffa16a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404456
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69930}
Add support for DisallowGarbageCollection scope. This scope will be
introduced once this CL landed.
DisallowGarbageCollection works like DisallowHeapAllocation but also
disallows safepoints.
Bug: v8:10315
Change-Id: Ia7d777d4104b32810dd481ad9dbdf0edd075b6cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2395561
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69881}
This reverts commit e8976cf93a.
Reason for revert: Mark f32x4_cmp as fail, lowering is not fully implemented yet.
Original change's description:
> Revert "[wasm-simd] Stage SIMD"
>
> This reverts commit 1d2726dd0b.
>
> Reason for revert: ODROID failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/15814?
>
> Original change's description:
> > [wasm-simd] Stage SIMD
> >
> > SIMD has been pretty stable for a while now, we are not expecting big
> > changes (like opcode renumbers), there might be new instructions added,
> > and they will all be backwards-compatible.
> >
> > The reference interpreter in the SIMD proposal is now capable of
> > generating JS files for all test cases, so we can now run them.
> >
> > There is a bit of tweaking necessary, since SIMD tests are in
> > tests/core/simd subfolder in the spec, so we need to change the glob
> > into a find that will traverse into subdirectory.
> >
> > Bug: v8:10835
> > Change-Id: I1f7e3cf37f21b2aa2537d1e34242da2373bbf626
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378587
> > Commit-Queue: Zhi An Ng <zhin@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69793}
>
> TBR=bbudge@chromium.org,ahaas@chromium.org,zhin@chromium.org
>
> Change-Id: I3a90c616109ca048691d97ab45698bc15a678e18
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:10835
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402379
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69794}
TBR=bbudge@chromium.org,ahaas@chromium.org,zhin@chromium.org,syg@chromium.org
# Not skipping CQ checks because this is a reland.
Bug: v8:10835
Change-Id: I3d87dd2adba6ada2ec3ebf5e13bff378a74b03e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402386
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69817}
This reverts commit 1d2726dd0b.
Reason for revert: ODROID failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/15814?
Original change's description:
> [wasm-simd] Stage SIMD
>
> SIMD has been pretty stable for a while now, we are not expecting big
> changes (like opcode renumbers), there might be new instructions added,
> and they will all be backwards-compatible.
>
> The reference interpreter in the SIMD proposal is now capable of
> generating JS files for all test cases, so we can now run them.
>
> There is a bit of tweaking necessary, since SIMD tests are in
> tests/core/simd subfolder in the spec, so we need to change the glob
> into a find that will traverse into subdirectory.
>
> Bug: v8:10835
> Change-Id: I1f7e3cf37f21b2aa2537d1e34242da2373bbf626
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378587
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69793}
TBR=bbudge@chromium.org,ahaas@chromium.org,zhin@chromium.org
Change-Id: I3a90c616109ca048691d97ab45698bc15a678e18
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10835
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402379
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69794}
SIMD has been pretty stable for a while now, we are not expecting big
changes (like opcode renumbers), there might be new instructions added,
and they will all be backwards-compatible.
The reference interpreter in the SIMD proposal is now capable of
generating JS files for all test cases, so we can now run them.
There is a bit of tweaking necessary, since SIMD tests are in
tests/core/simd subfolder in the spec, so we need to change the glob
into a find that will traverse into subdirectory.
Bug: v8:10835
Change-Id: I1f7e3cf37f21b2aa2537d1e34242da2373bbf626
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378587
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69793}
... and apply zone filter to the graph header.
Bug: v8:10572
Change-Id: I923f2342a064864aeac693c482c09fee3eda28ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401419
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69789}
This is a reland of 81577a79e1
The revert was due to an missing dependency in the incremental build,
fixed in https://crrev.com/c/2400987.
Original change's description:
> [serializer] Change deferring to use forward refs
>
> Now that we have forward references, we can replace the body deferring
> mechanism with forward references to the entire pointer.
>
> This ensures that objects are always deserialized with their contents
> (aside from themselves maybe holding forward refs), and as a result we
> can simplify the CanBeDeferred conditions which encode the constraint
> that some objects either need immediately have contents, or cannot be
> deferred because their fields are changed temporarily (e.g. backing
> store refs).
>
> This also means that objects with length fields (e.g. arrays) will
> always have those length fields deserialized when the object is
> deserialized, which was not the case when the body could be deferred.
> This helps us in the plan to make GC possible during deserialization.
>
> Bug: v8:10815
> Change-Id: Ib0e5399b9de6027765691e8cb47410a2ccc15485
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390643
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69760}
Tbr: jgruber@chromium.org
Bug: v8:10815
Change-Id: I235076a97c5dfa58513e880cc477ac72a28b29e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400992
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69779}
tools/debug_helper:run_mkgrokdump used to only depend on mkgrokdump.
However, the snapshot can change without affecting the mkgrokdump
binary itself. So, if the mkgrokdump binary doesn't change, then
run_mkgrokdump doesn't run, even if the snapshot changed.
This could cause mysterious test failures in incremental builds, in
particular for tests testing the contents of heap-constants-gen.cc.
Now, we make run_mkgrokdump depend on run_mksnapshot_default
directly, so that snapshot updates force an mkgrokdump run.
Change-Id: Ia3871e1b4fa15ec2dbc0bc5463afdb427cb39c61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400987
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69776}
This reverts commit 81577a79e1.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20shared/10544
Original change's description:
> [serializer] Change deferring to use forward refs
>
> Now that we have forward references, we can replace the body deferring
> mechanism with forward references to the entire pointer.
>
> This ensures that objects are always deserialized with their contents
> (aside from themselves maybe holding forward refs), and as a result we
> can simplify the CanBeDeferred conditions which encode the constraint
> that some objects either need immediately have contents, or cannot be
> deferred because their fields are changed temporarily (e.g. backing
> store refs).
>
> This also means that objects with length fields (e.g. arrays) will
> always have those length fields deserialized when the object is
> deserialized, which was not the case when the body could be deferred.
> This helps us in the plan to make GC possible during deserialization.
>
> Bug: v8:10815
> Change-Id: Ib0e5399b9de6027765691e8cb47410a2ccc15485
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390643
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69760}
TBR=jgruber@chromium.org,leszeks@chromium.org
Change-Id: I7a93a59217a2b38e2157c0f7ffc7ac648590a8d6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10815
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398535
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69763}
Now that we have forward references, we can replace the body deferring
mechanism with forward references to the entire pointer.
This ensures that objects are always deserialized with their contents
(aside from themselves maybe holding forward refs), and as a result we
can simplify the CanBeDeferred conditions which encode the constraint
that some objects either need immediately have contents, or cannot be
deferred because their fields are changed temporarily (e.g. backing
store refs).
This also means that objects with length fields (e.g. arrays) will
always have those length fields deserialized when the object is
deserialized, which was not the case when the body could be deferred.
This helps us in the plan to make GC possible during deserialization.
Bug: v8:10815
Change-Id: Ib0e5399b9de6027765691e8cb47410a2ccc15485
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390643
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69760}
Cast resource field in ExternalString as
v8: :String::ExternalStringResourceBase* would give us more info.
Change-Id: Iae97b477f400f58365e2381b7230d2226d490aa7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388742
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69734}
Guessing the architecture on the testing machine is not required to
derive if the simulator is supposed to run. The architecture check
doesn't work on some platforms.
We derive this now by checking if we have compiled a simulator build:
target_cpu != v8_target_cpu.
Bug: chromium:1110824
Change-Id: Id30a647f0610f21efb00d68ad1602e62dcd2c65c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2395563
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69719}
This was added to try and skip tests when run on platforms without
sse41, but it doesn't work fuzz tests, since they add the flags on
command line. With https://crrev.com/c/2389982 we are now adding the
flag in the js test file itself.
Remove this condition since it's likely to be confusing and not work
correctly for all tests.
Bug: v8:10863
Change-Id: Ieeadade05dfc04ce250710d09a6a272775ce98c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391321
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69685}
This CL unifies the map-processor and ic-processor into a
single log processing pipeline. Unified processing pipeline
prevents doing 2 pass over the data.
Bug: v8:10644
Change-Id: Ic0221a9bb32901f43202390b98fded4830a50f70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385496
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69676}
This CL enables showing map details of the selected map coming from
FocusEvent. It also improves UI experience of selecting a map from
map transitions, highlighting selected map.
Additionally, stores information about unique map/IC events in model
for the timeline-track legend.
Bug: v8:10644
Change-Id: Ieb8a2ac0bf1af282d55bce18130192d7178538da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387564
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69673}
This CL adds drag handlers to the timeline panel
to filter events based on the selected portion
of the timeline tracks.
Bug: v8:10644
Change-Id: Ic8a38493eacb62844b3fed5a027f8b1367f2bb59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346275
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69669}
This reverts commit dfb3f7daa5.
Reason for revert: Breaks LSAN & ASAN flakily: https://bugs.chromium.org/p/v8/issues/detail?id=10861
Original change's description:
> [cpu-profiler] Ensure sampled thread has Isolate lock under Windows
>
> While the sampler checked if the sampled thread had the Isolate locked
> (if locks are being used) under Linux, the check was not done under
> Windows (or Fuchsia) which meant that in a multi-threading application
> under Windows, thread locking was not checked making it prone to seg
> faults and the like as the profiler would be extracting info from a
> heap in motion. The fix was to move the lock check into CpuSampler
> and Ticker (--prof) so all OSes would do the correct check.
>
> The basic concept is that on all operating systems a CpuProfiler, and
> so its corresponding CpuCampler, the profiler is tied to a thread.
> This is not based on first principles or anything, it's simply the
> way it works in V8, though it is a useful conceit as it makes
> visualization and interpretation of profile data much easier.
>
> To collect a sample on a thread associated with a profiler the thread
> must be stopped for obvious reasons -- walking the stack of a running
> thread is a formula for disaster. The mechanism for stopping a thread
> is OS-specific and is done in sample.cc. There are currently three
> basic approaches, one for Linux/Unix variants, one for Windows and one
> for Fuchsia. The approaches vary as to which thread actually collects
> the sample -- under Linux the sample is actually collected on the
> (interrupted) sampled thread whereas under Fuchsia/Windows it's on
> a separate thread.
>
> However, in a multi-threaded environment (where Locker is used), it's
> not sufficient for the sampled thread to be stopped. Because the stack
> walk involves looking in the Isolate heap, no other thread can be
> messing with the heap while the sample is collected. The only ways to
> ensure this would be to either stop all threads whenever collecting a
> sample, or to ensure that the thread being sampled holds the Isolate
> lock so prevents other threads from messing with the heap. While there
> might be something to be said for the "stop all threads" approach, the
> current approach in V8 is to only stop the sampled thread so, if in a
> multi-threaded environment, the profiler must check if the thread being
> sampled holds the Isolate lock.
>
> Since this check must be done, independent of which thread the sample
> is being collected on (since it varies from OS to OS), the approach is
> to save the thread id of the thread to be profiled/sampled when the
> CpuSampler is instantiated (on all OSes it is instantiated on the
> sampled thread) and then check that thread id against the Isolate lock
> holder thread id before collecting a sample. If it matches, we know
> sample.cc has stop the sampled thread, one way or another, and we know
> that no other thread can mess with the heap (since the stopped thread
> holds the Isolate lock) so it's safe to walk the stack and collect data
> from the heap so the sample can be taken. It it doesn't match, we can't
> safely collect the sample so we don't.
>
> Bug: v8:10850
> Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69623}
TBR=akodat@rocketsoftware.com,petermarshall@chromium.org,petermarshall@google.com
Change-Id: Ib6b6dc4ce109d5aa4e504fa7c9769f5cd95ddd0c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10850
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387570
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69638}
Change the serialization protocol to ensure that maps are serialized
before objects using them. This ensures that as soon as we allocate
space for an object, we can immediately write the object's map into that
allocation. In the future, this will allow us to make deserialized
object visible to the GC.
Specifically, this forces map serialization to happen after emitting
a kNewObject for an object, but before allocating the space for it. We
have to serialize the map after kNewObject because otherwise the map
itself would be written into the "current" slot, into which the object
is supposed to be deserialized.
Objects whose maps are currently being deserialized are considered
"pending" -- started, but not yet allocated. The map might point to a
pending object (e.g. if an object's constructor points to the object).
This is solved by introducing a new concept of forward references, where
the field referring to the pending object is serialized as a "pending
forward reference" which is "resolved" once the object is allocated.
It might also point to itself, in the case of the meta map -- this is
simply solved by introducing a new bytecode for the meta map; this
cannot be a pending forward reference because the meta map is not yet
allocated, so its map slot cannot be registered as pending.
Finally, we may need to go to a new chunk after serializing the map; so
after the map serialization, we peek to see if there's a next chunk
bytecode before the object allocation.
Bug: v8:10815
Change-Id: Ifa8f25bdaf3b15b5d990a1d2e7be677c2fa80013
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362953
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69636}
While the sampler checked if the sampled thread had the Isolate locked
(if locks are being used) under Linux, the check was not done under
Windows (or Fuchsia) which meant that in a multi-threading application
under Windows, thread locking was not checked making it prone to seg
faults and the like as the profiler would be extracting info from a
heap in motion. The fix was to move the lock check into CpuSampler
and Ticker (--prof) so all OSes would do the correct check.
The basic concept is that on all operating systems a CpuProfiler, and
so its corresponding CpuCampler, the profiler is tied to a thread.
This is not based on first principles or anything, it's simply the
way it works in V8, though it is a useful conceit as it makes
visualization and interpretation of profile data much easier.
To collect a sample on a thread associated with a profiler the thread
must be stopped for obvious reasons -- walking the stack of a running
thread is a formula for disaster. The mechanism for stopping a thread
is OS-specific and is done in sample.cc. There are currently three
basic approaches, one for Linux/Unix variants, one for Windows and one
for Fuchsia. The approaches vary as to which thread actually collects
the sample -- under Linux the sample is actually collected on the
(interrupted) sampled thread whereas under Fuchsia/Windows it's on
a separate thread.
However, in a multi-threaded environment (where Locker is used), it's
not sufficient for the sampled thread to be stopped. Because the stack
walk involves looking in the Isolate heap, no other thread can be
messing with the heap while the sample is collected. The only ways to
ensure this would be to either stop all threads whenever collecting a
sample, or to ensure that the thread being sampled holds the Isolate
lock so prevents other threads from messing with the heap. While there
might be something to be said for the "stop all threads" approach, the
current approach in V8 is to only stop the sampled thread so, if in a
multi-threaded environment, the profiler must check if the thread being
sampled holds the Isolate lock.
Since this check must be done, independent of which thread the sample
is being collected on (since it varies from OS to OS), the approach is
to save the thread id of the thread to be profiled/sampled when the
CpuSampler is instantiated (on all OSes it is instantiated on the
sampled thread) and then check that thread id against the Isolate lock
holder thread id before collecting a sample. If it matches, we know
sample.cc has stop the sampled thread, one way or another, and we know
that no other thread can mess with the heap (since the stopped thread
holds the Isolate lock) so it's safe to walk the stack and collect data
from the heap so the sample can be taken. It it doesn't match, we can't
safely collect the sample so we don't.
Bug: v8:10850
Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69623}
This allows tests to be skipped on nosse41 builds. For SIMD, nosse41 means
that we need to scalar lower all SIMD instructions, which is not fully
implemented yet.
Bug: v8:10831
Change-Id: I27dd2840b376da672237fed764cbd2491c244627
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380710
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69612}
This CL adds a source code panel to display source code positions of
Map/IC log events.
* Clicking file positions on the Ic Panel emits FocusEvent with
SourcePositionLogEvent as entry to highlight code related with the
selected icLogEvent.
* Clicking map details on the Map Panel emits FocusEvent with
SourcePositionLogEvent as entry to highlight code related with the
selected mapLogEvent.
Bug: v8:10644
Change-Id: Icaf3e9e3f7fae485c50ad685f9ec5dc8ac28b3dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358734
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69610}
Changes:
* Transition edges on timeline-track with the same color of the map type.
* Log file reader loading background adapted to light theme.
* Support additional IC log event colors.
* Move theme switch button to top of the app.
Bug: v8:10644, v8:10673
Change-Id: Ib086b6f4a8bc5f86a4925b251112c640e37278ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379869
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69600}
Bug fixes:
* Wrong time range selection of timeline chunks handled by mouse events.
* Consecutive file uploads does not create a new Model object causing
bugs on timeline-track start and end times.
Bug: v8:10644
Change-Id: I3d31ddda1ffca70c18c87dd103f2b788713c2911
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379863
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69598}
This CL fixes the bug related with chunk position initialisation.
The bug caused by not subtracting the timeline chunk start time from
chunk start time. Additionally, it corrects the offset being used while
detecting the chunk location.
Bug: v8:10644
Change-Id: Icf426a297402f87d2acda0b2aa747b90e91686c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377740
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69589}
This CL unifies both map-processor and ic-processor's map processing
pipeline to the same format. Also, adds the functionality to search
for map transitions on map panel by clicking on map property of the
ic-panel.
Bug: v8:10644
Change-Id: I9f95feebb08620fd489486cf459ebe0babbd32d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2367865
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69567}
This CL highlights the items with clickable functionality.
It is implemented based on the received feedback from the
V8 Mobile Team.
Bug: v8:10644
Change-Id: I0489327681d485eedde59594d36083efdc216575
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370626
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69537}
