Skip to content

V
V8
Switch branch/tag
  1. 12 Apr, 2021 1 commit
  3. 21 Jan, 2021 1 commit
  5. 17 Nov, 2020 1 commit
  7. 17 Apr, 2020 1 commit
  9. 23 Jan, 2020 1 commit
  11. 01 Nov, 2019 1 commit
  13. 18 Jul, 2019 1 commit
  15. 04 Apr, 2019 1 commit
  17. 25 Mar, 2019 1 commit
  19. 21 Feb, 2019 2 commits
    • Nico Weber's avatar
      v8: Prep for removing TRACE_EVENT_SCOPED_CONTEXT. · e0fd36b7
      Nico Weber authored 
      It's only used in tests, and for some reason v8 refers to a macro defined
in src.git, so I need to remove this in v8 first before I can remove it
in Chromium.

Bug: chromium:934255
Change-Id: I31ea32aa43cf7a5f518def7b91dce99dcb268709
Reviewed-on: https://chromium-review.googlesource.com/c/1480911Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59769}
      e0fd36b7
    • Peter Marshall's avatar
      [tracing] Fix races in TracingController implementation · 51e80efd
      Peter Marshall authored 
      The default TracingController (used by d8 and Node) has some concurrency
issues. The new test flushes these out, when a second thread logs trace
events while the main thread calls StopTracing().

- Use an acquire load in UpdateCategoryGroupEnabledFlags() because this
  was racing with GetCategoryGroupEnabled() where a new category is
  added in the slow path. g_category_groups is append-only, but
  reads/writes to g_category_index need to be correctly ordered so that
  new categories are added and only then is the change to the index
  visible. The relaxed load ignored this and caused unsynchronized
  read/write.
- Use a relaxed load in ~ScopedTracer() to access category_group_enabled
  as this previously used a non-atomic operation which caused a race
  with UpdateCategoryGroupEnabledFlag() which does a relaxed store.
- Replace TracingController::mode_ with an atomic bool as read/writes to
  mode_ were not synchronized and caused TSAN errors. It only has two
  states and it doesn't seem like we will extend this so just convert it
  to bool.
- Take the lock around calling trace_object->Initialize in
  AddTraceEvent(), and around trace_buffer_->Flush() in StopTracing().
  These two raced previously as the underlying TraceBufferRingBuffer
  passes out pointers to TraceObjects in a synchronized way, but the
  caller (AddTraceEvent) then writes into the object without
  synchronization. This leads to races when Flush() is called, at which
  time TraceBufferRingBuffer assumes that all the pointers it handed out
  are to valid, initialized TraceObjects - which is not true because
  AddTraceEvent may still be calling Initialize on them. This could be
  the cause of issues in Node.js where the last line of tracing/logging
  sometimes gets cut off. This is kind of a band-aid solution - access
  to the TraceObjects handed out by the ring buffer really needs proper
  synchronization which at this point would require redesign. It's quite
  likely we will replace this with Perfetto in the near future so not
  much point investing in this code right now.
- Enable TracingCpuProfiler test which was flaky due to these bugs.

Bug: v8:8821
Change-Id: I141296800c6906ac0e7f3f21dd16d861b07dae62
Reviewed-on: https://chromium-review.googlesource.com/c/1477283
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarAli Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#59752}
      51e80efd
  21. 27 Sep, 2018 1 commit
    • Clemens Hammacher's avatar
      [tracing] Fix data race · 0ba3de60
      Clemens Hammacher authored 
      There is a data race if several background threads check for a tracing
flag concurrently. Both will call {GetCategoryGroupEnabledInternal}.
The first one not find the category in the {g_category_group_enabled}
array, and hence will add it and call {UpdateCategoryGroupEnabledFlag}
to initialize the flag. The second thread then finds the entry in the
array and reads it without any synchronization, which is a data race.

Since we do not really care about this race, we just use a
{Relaxed_Load} to read the field. TSan is fine with that.

R=yangguo@chromium.org
CC=ofrobots@google.com

Bug: v8:8221
Change-Id: Ie09141e3d845956d3c487a463f00b7d6cd413513
Reviewed-on: https://chromium-review.googlesource.com/1245424Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56256}
      0ba3de60
  23. 20 Sep, 2018 1 commit
  25. 02 May, 2018 1 commit
  27. 02 Feb, 2018 1 commit
  29. 12 Jan, 2018 1 commit
  31. 18 Oct, 2017 1 commit
  33. 13 Oct, 2017 1 commit
  35. 03 Jul, 2017 1 commit
    • Jochen Eisinger's avatar
      Reland "Switch tracing to use v8::TracingController" · cc59f8b1
      Jochen Eisinger authored 
      Original change's description:
> Switch tracing to use v8::TracingController
>
> BUG=v8:6511
> R=fmeawad@chromium.org
>
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I4961e4b61a9ddc98385ed97c3ffcbcaef2d9cba7
> Reviewed-on: https://chromium-review.googlesource.com/543144
> Commit-Queue: Jochen Eisinger <jochen@chromium.org>
> Reviewed-by: Fadi Meawad <fmeawad@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46307}

BUG=v8:6511
TBR=fmeawad@chromium.org

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux64_tsan_rel
Change-Id: Ide32b409248dfd466e7c0bae1d8ae61d6a955d98
Reviewed-on: https://chromium-review.googlesource.com/558865
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: 's avatarJochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46381}
      cc59f8b1
  37. 29 Jun, 2017 2 commits
  39. 30 May, 2017 1 commit
  41. 29 Mar, 2017 1 commit
  43. 04 Nov, 2016 1 commit
  45. 03 Nov, 2016 2 commits
  47. 12 Oct, 2016 1 commit
  49. 27 Sep, 2016 2 commits
  51. 26 Sep, 2016 1 commit
  53. 22 Sep, 2016 1 commit
  55. 05 Sep, 2016 1 commit
    • fmeawad's avatar
      [RuntimeCallStats] Move tracing runtime instrumentation closer to the original version. · e5ba156d
      fmeawad authored 
      After we landed the tracing runtime call stats, which gave
us a lot of V8 insight in tracing, we noticed that there is
some arising issues and discrepancies.

Issues include:
Missing trace events, that happened due to
transforming those trace events into runtime calls

Discrepancies include:
Missing categories in Runtime call stats like GC,
because we are not handling the Scoped runtime calls
properly in the tracing version.

To reduce/eliminate those issue, we are taking a small
step back. We are unifying the RuntimeStats code and
using the original one. That would allow us to use all
the original probes but emit trace events from them.
We are also putting back the trace-events in their place.

The output from both system should be intact (Except of
the addition of the missing trace-events).

Also as a byproduct, we are reducing the number of context
scopes by half since we are using the same scope as
runtime call stats.

As a follow up to this CL, we will address the non-scoped
Runtime Call Stats (mainly in GC).
BUG=642373

Review-Url: https://codereview.chromium.org/2296243002
Cr-Commit-Position: refs/heads/master@{#39180}
      e5ba156d
  57. 10 Aug, 2016 1 commit
  59. 08 Aug, 2016 1 commit
  61. 05 Aug, 2016 1 commit
  63. 03 Aug, 2016 4 commits
  65. 15 Jun, 2016 1 commit