Skip to content

V
V8
Switch branch/tag
  1. 22 Sep, 2020 4 commits
  3. 21 Sep, 2020 3 commits
  5. 18 Sep, 2020 3 commits
    • Michael Achenbach's avatar
      [test] Switch order of default flags · 066b5ac9
      Michael Achenbach authored 
      TBR=tebbi@chromium.org

Bug: v8:10577
Change-Id: I3367c31afb9f38f9151d3c5787a7838da4db327a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418717Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70012}
      066b5ac9
    • Tobias Tebbi's avatar
      Reland^5 "[flags] warn about contradictory flags" · 0832a109
      Tobias Tebbi authored 
      This is a reland of 2000aea5
Changes compared to last reland:
- Add rule in variants.py for --enable_experimental_regexp_engine.
- Make sure --abort-on-contradictory-flags works as well as --fuzzing
  to disable the checking for fuzzers, including for d8 flags.

Original change's description:
> Reland^4 "[flags] warn about contradictory flags"
>
> This is a reland of 0ba115e6
> 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 d8f8a7e2
> > > 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 b8f91666
> > > > 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}

Bug: v8:10577
TBR: clemensb@chromium.org, tmrts@chromium.org
Change-Id: Iab2d32cdcc2648934fc52255ccf3ae3ec9ca4d9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416386Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70000}
      0832a109
    • Leszek Swirski's avatar
      [snapshot] Reland recent de/serializer related changes · 695d9b64
      Leszek Swirski authored 
      This reverts commit 1aa9ab73.

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 76d684cc.
> - "Reland "[serializer] Remove new space""
>   commit 81231c23.
> - "[serializer] Clean-up and de-macro ReadDataCase"
>   commit c06d24b9.
> - "[serializer] DCHECK deserializer allocations are initialized"
>   commit fbc1f32d.
>
> 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: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69988}
      695d9b64
  7. 17 Sep, 2020 2 commits
  9. 16 Sep, 2020 8 commits
    • Bill Budge's avatar
      Revert "Reland^4 "[flags] warn about contradictory flags"" · a0e38f31
      Bill Budge authored 
      This reverts commit 2000aea5.

Reason for revert: Breaks NumFuzz.

Original change's description:
> Reland^4 "[flags] warn about contradictory flags"
> 
> This is a reland of 0ba115e6
> 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 d8f8a7e2
> > > 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 b8f91666
> > > > 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}

TBR=clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org

Change-Id: I2dc80bcad9f74c29298902e01939e7e7f3336cf6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2415133Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69959}
      a0e38f31
    • Jakob Kummerow's avatar
      Revert recent de/serializer related changes · 1aa9ab73
      Jakob Kummerow authored 
      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 76d684cc.
- "Reland "[serializer] Remove new space""
  commit 81231c23.
- "[serializer] Clean-up and de-macro ReadDataCase"
  commit c06d24b9.
- "[serializer] DCHECK deserializer allocations are initialized"
  commit fbc1f32d.

Bug: chromium:1128872
Change-Id: Id2bb3b8fac526fdf9ffb033222ae08cd423f8238
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414220Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69955}
      1aa9ab73
    • Tobias Tebbi's avatar
      Reland^4 "[flags] warn about contradictory flags" · 2000aea5
      Tobias Tebbi authored 
      This is a reland of 0ba115e6
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 d8f8a7e2
> > 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 b8f91666
> > > 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: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69954}
      2000aea5
    • Alex Kodat's avatar
      [cpu-profiler] Ensure sampled thread has Isolate lock under Windows · 76217f57
      Alex Kodat authored 
      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/+/2411343Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69952}
      76217f57
    • Michael Achenbach's avatar
      [test] Print less in verbose mode · d8d6110b
      Michael Achenbach authored 
      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: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69950}
      d8d6110b
    • Dominik Inführ's avatar
      Add testrunner variant for --stress-concurrent-allocation · cb85c18a
      Dominik Inführ authored 
      Bug: v8:10315
Change-Id: If64ff0bcd441ecce4113f70ba72373949f076efe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2409276Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69938}
      cb85c18a
    • Zeynep Cankara's avatar
      [tools][system-analyzer] TimelineOverviewIndicator bug fix · b67c3f53
      Zeynep Cankara authored 
      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/+/2413257Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69936}
      b67c3f53
    • Ulan Degenbaev's avatar
      [infra] Add a no-local-heaps test variant · 9fa28082
      Ulan Degenbaev authored 
      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: 's avatarMichael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69930}
      9fa28082
  11. 15 Sep, 2020 1 commit
  13. 14 Sep, 2020 1 commit
  15. 10 Sep, 2020 1 commit
    • Ng Zhi An's avatar
      Reland "[wasm-simd] Stage SIMD" · 36138aff
      Ng Zhi An authored 
      This reverts commit e8976cf9.

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 1d2726dd.
> 
> 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/+/2402386Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69817}
      36138aff
  17. 09 Sep, 2020 7 commits
    • Shu-yu Guo's avatar
      Revert "[wasm-simd] Stage SIMD" · e8976cf9
      Shu-yu Guo authored 
      This reverts commit 1d2726dd.

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/+/2402379Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69794}
      e8976cf9
    • Ng Zhi An's avatar
      [wasm-simd] Stage SIMD · 1d2726dd
      Ng Zhi An authored 
      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: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69793}
      1d2726dd
    • Igor Sheludko's avatar
      [zone-stats] Show all zones in a filter · 90ec63a9
      Igor Sheludko authored 
      ... and apply zone filter to the graph header.

Bug: v8:10572
Change-Id: I923f2342a064864aeac693c482c09fee3eda28ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401419Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69789}
      90ec63a9
    • Leszek Swirski's avatar
      Reland "[serializer] Change deferring to use forward refs" · 76d684cc
      Leszek Swirski authored 
      This is a reland of 81577a79

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/+/2400992Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69779}
      76d684cc
    • Leszek Swirski's avatar
      [build] Make run_mkgrokdump explicitly dep on run_mksnapshot · 0ed32e64
      Leszek Swirski authored 
      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: 's avatarMichael Achenbach <machenbach@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69776}
      0ed32e64
    • Sathya Gunasekaran's avatar
      Revert "[serializer] Change deferring to use forward refs" · cb1a96e5
      Sathya Gunasekaran authored 
      This reverts commit 81577a79.

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/+/2398535Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69763}
      cb1a96e5
    • Leszek Swirski's avatar
      [serializer] Change deferring to use forward refs · 81577a79
      Leszek Swirski authored 
      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/+/2390643Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69760}
      81577a79
  19. 08 Sep, 2020 2 commits
  21. 07 Sep, 2020 1 commit
  23. 02 Sep, 2020 4 commits
  25. 01 Sep, 2020 3 commits
    • Ng Zhi An's avatar
      Extra flag check for sse4_1 · 47b60053
      Ng Zhi An authored 
      Fuzzers use a slight variant of the sse4_1 flag, see
https://source.chromium.org/chromium/chromium/src/+/master:v8/tools/testrunner/testproc/fuzzer.py;l=26;drc=9491d5eaa4e764721b5269e75af68f181bef09cf.

Bug: v8:10863
Change-Id: Ifc467644f00a4f10776794c12a227f13774f48ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387555Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69652}
      47b60053
    • Peter Marshall's avatar
      Revert "[cpu-profiler] Ensure sampled thread has Isolate lock under Windows" · 32435062
      Peter Marshall authored 
      This reverts commit dfb3f7da.

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/+/2387570Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69638}
      32435062
    • Leszek Swirski's avatar
      [serializer] Serialize map before object · 7c912ffa
      Leszek Swirski authored 
      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: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69636}
      7c912ffa