1. 11 Aug, 2021 1 commit
  2. 16 Jun, 2021 1 commit
  3. 10 Jun, 2021 1 commit
  4. 08 Jun, 2021 1 commit
  5. 27 Apr, 2021 1 commit
  6. 23 Apr, 2021 1 commit
  7. 08 Apr, 2021 1 commit
  8. 01 Apr, 2021 1 commit
    • Sara Tang's avatar
      [diagnostics] Enable ETW stack-walking events build flag · f0061332
      Sara Tang authored
      Feedback from Microsoft partners indicates that it would be beneficial
      to enable ETW stack-walking events by default.
      
      This is difficult, because the --interpreted-frames-native-stack flag
      comes with a significant perf degradation. Ideally, we would turn
      this flag on dynamically, only when a ETW recorder is actively
      triggering the provider. Unfortunately, the flag in its current state
      cannot be enabled dynamically.
      
      In light of this, we have decided to only flip the build flag.
      
      Bug: v8:11043
      Change-Id: Id883b9bcd635b41139450ab2d5c92511422525a3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773792Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Sara Tang <sartang@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#73784}
      f0061332
  9. 02 Mar, 2021 1 commit
    • Sara Tang's avatar
      Step 2 (of 2) for ETW integration into V8 · 88926769
      Sara Tang authored
      Design doc:
      https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U
      
      This is the second (and hopefully final!) change list needed to
      integrate ETW into V8. In particular, we added stack-walking
      functionality for JIT-ted functions!
      
      Some notes on instrumentation:
        - The gist of getting stack-walking in ETW is we need to emit events
          with specific event IDs. These events get stitched into a pseudo-PDB
          that is recognizable by ETW.
        - Unfortunately, we cannot rely on the TraceLogging API from the first
          CL, as it does not support specifying event IDs. Instead, Bill
          Ticehurst wrote an API that peels back the TraceLogging API just
          enough so that we can specify event IDs. This API is the entirety of
          etw-metdata.h
        - We attach a CodeEventHandler that logs a stack-walking event whenever
          code movement is triggered.
      
      Bug: v8:11043
      Change-Id: I1bf57c985b7375f045089027855b1c03878abb78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616221Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Sara Tang <sartang@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#73145}
      88926769
  10. 25 Feb, 2021 1 commit
  11. 05 Jan, 2021 1 commit
    • Sara Tang's avatar
      Step 1 (of 3-ish): Basic ETW Instrumentation in V8 · 8b33c872
      Sara Tang authored
      Design doc:
      https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U
      A lot has changed since the last patchset! I recommend revisiting this
      design doc and reading the parts in green. I explain the roadmap for
      what changes to expect from ETW instrumentation as well as the
      instrumentation of this particular CL.
      
      I'll do my best to answer any further questions anyone has about my
      particular instrumentation or ETW in general :)
      
      ---
      
      This is the first of a series of changelists to round out ETW
      instrumentation for V8.
      
      This changelist represents the most minimal change needed to instrument
      ETW in V8. In particular, it:
        - defines and registers the ETW provider,
        - interacts minimally with the rest of V8, by hooking into the
          existing TracingController::AddTraceEvent function,
        - is designed with a platform-agnostic layer, so that event tracers
          for other platforms can be instrumented in teh future.
      
      Some notes on instrumentation (aka I copied stuff from the design doc):
      
      We make heavy use of the TraceLogging API to log events. It differs from
      previous methods of emitting ETW events in that it doesn<E2><80><99>t
      require the overhead of a separate manifest file to keep track of
      metadata; rather, events using this API are self-descriptive.
      
      Here are the five major steps to instrument the TraceLogging API:
        - Forward declare the provider (from provider-win.h)
        - Define the provider in a .cc file (from provider-win.cc)
        - Register the provider (called from v8.cc).
        - Write events (called from libplatform/tracing-controller.cc)
        - Unregister the provider (called from v8.cc)
      
      At the base, we have an abstract provider class that encapsulates the
      functionality of an event provider. These are things like registering
      and unregistering the provider, and the actual event-logging.
      
      The provider class is split into provider-win and provider-mac
      (currently not instantiated) classes, with OS-dependent implementations
      of the above functions.
      
      In particular, the TraceLogging API is used only in provider-win. It is
      here that we forward declare and define the provider, as well as write
      ETW events.
      
      Finally, there is a v8-provider class that serves as a top-level API and
      is exposed to the rest of V8. It acts as a wrapper for the
      platform-specific providers.
      
      The .wprp file is needed so that Windows Performance Recorder knows how
      to capture our events.
      
      Some considerations:
        - Is TracingController::AddTraceEvent the best place from which to
          write my events?
        - Is src/libplatform/tracing the best place to put my instrumentation?
        - Right now, I fail the preupload because of this, which tells me my
          files are probably not in the best location:
      
      You added one or more #includes that violate checkdeps rules.
      src\init\v8.cc Illegal include: "src/libplatform/tracing/v8-provider.h"
      Because of "-src/libplatform" from src's include_rules.
      
      Change-Id: Id53e4a034c9e526524a17000da0a647a95d93edf
      Bug: v8:11043
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233407Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Sara Tang <sartang@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71918}
      8b33c872
  12. 10 Dec, 2020 1 commit
  13. 08 Dec, 2020 1 commit
    • Etienne Pierre-doray's avatar
      Reland "Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."" · fc1d6f35
      Etienne Pierre-doray authored
      This is a reland of 064ee3c8
      
      Issue 1: WasmEngine UAF when CompilationState is destroyed
      asynchronously
      Fix: Include https://chromium-review.googlesource.com/c/v8/v8/+/2565508
      in this CL. Use OperationBarrier to keep WasmEngine alive.
      
      Issue 2: In gin, JobTask lifetime is not extended beyond
      JobHandle, thus making CancelAndDetach unusable.
      This is fixed in chromium here:
      https://chromium-review.googlesource.com/c/chromium/src/+/2566724
      
      Original change's description:
      > Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."
      >
      > Reason for revert: Data race:
      > https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121
      >
      > It was assume that MockPlatform runs everything on 1 thread. However,
      > MockPlatform::PostJob previously would schedule the job through
      > TestPlatform, which eventually posts concurrent tasks, thus causing
      > data race.
      > Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform
      > ensures the jobs also run sequentially.
      >
      > Additional change:
      > - CancelAndDetach is now called in ~CompilationStateImpl() to make sure
      > it's called in sequence with ScheduleCompileJobForNewUnits
      >
      > Original CL description:
      > To avoid keeping around a list of job handles, CancelAndDetach() is
      > used in CancelCompilation. Dependency on WasmEngine is handled by a
      > barrier that waits on all jobs to finish.
      >
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Cr-Original-Commit-Position: refs/heads/master@{#71074}
      > Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137
      > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#71459}
      
      TBR=ulan@chromium.org
      
      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: I6175092c97fea0d5f63a97af232e2d54cccea535
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569360
      Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71662}
      fc1d6f35
  14. 01 Dec, 2020 2 commits
  15. 27 Nov, 2020 1 commit
  16. 26 Nov, 2020 1 commit
  17. 17 Nov, 2020 1 commit
  18. 13 Nov, 2020 1 commit
  19. 10 Nov, 2020 2 commits
  20. 30 Oct, 2020 1 commit
  21. 20 Oct, 2020 1 commit
  22. 19 Oct, 2020 1 commit
  23. 07 Oct, 2020 1 commit
    • Omer Katz's avatar
      cppgc, jobs: Update job priority · 4cb4a229
      Omer Katz authored
      This CL aligns the library implementation with the blink implementation:
      (*) Concurrent marking increases job priority if no concurrent progress
          is made in the last 50% of the expected marking duration.
      (*) Concurrent sweeping increases job priority when calling
          FinishIfRunning (the library equivalent of blink's CompleteSweep).
      
      Bug: chromium:1056170
      Change-Id: Ice275cb90a7dd76bf4125f4338d9d80e5f576c58
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431572
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70375}
      4cb4a229
  24. 06 Oct, 2020 1 commit
  25. 29 Sep, 2020 1 commit
  26. 17 Sep, 2020 1 commit
  27. 10 Sep, 2020 1 commit
  28. 26 Aug, 2020 1 commit
    • Clemens Backes's avatar
      [platform] Fix data race on DefaultJobState::priority_ · 35cc3da9
      Clemens Backes authored
      The {priority_} field is being updated in {DefaultJobState::Join}, under
      {mutex_}. In other places though, it is read unprotected (without
      holding the mutex), leading to data races.
      This CL fixes that by reading the field while holding the mutex and
      using the read priority after releasing the mutex.
      
      Note that the {priority_} field is documented to be protected by
      {mutex_}, so the unprotected read was a bug.
      
      R=ulan@chromium.org
      CC=etiennep@chromium.org
      
      Bug: v8:10822
      Change-Id: I80079f3cb6689e26116ffeb33755c6938c4a2cf1
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377685Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69571}
      35cc3da9
  29. 25 Aug, 2020 1 commit
  30. 20 Aug, 2020 1 commit
  31. 06 Aug, 2020 1 commit
    • Clemens Backes's avatar
      [platform] Use more tasks for jobs · 044ddd31
      Clemens Backes authored
      Wasm recently switched from spawning a number of background tasks for
      compilation to just using a single job (via the pretty new
      {Platform::PostJob} API). This caused major regressions in several
      benchmarks running in d8, because the {DefaultPlatform} is only using
      half of the available worker threads for executing jobs with "user
      visible" priority.
      
      This CL changes this to use all available worker threads for "user
      blocking" or "user visible" jobs, and two threads for "best effort"
      jobs. The limit of two threads for best effort is identical to what
      chromium does with best effort *tasks*. For user blocking and user
      visible, chromium does not impose any limit, so we also remove the
      limitation to half of the threads from d8.
      
      Drive-by: Use {NewDefaultJobHandle} for constructing {DefaultJobHandle}.
      
      R=mlippautz@chromium.org
      CC=ahaas@chromium.org, gab@chromium.org, etiennep@chromium.org
      
      Bug: chromium:1113234, chromium:1101340
      Change-Id: I9280e649a1cf3832c562ff7251e8bda0103af111
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339481Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Commit-Queue: Hannes Payer <hpayer@chromium.org>
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69265}
      044ddd31
  32. 20 Jul, 2020 1 commit
  33. 25 Jun, 2020 1 commit
  34. 04 Jun, 2020 1 commit
  35. 08 May, 2020 1 commit
  36. 06 May, 2020 1 commit
    • Clemens Backes's avatar
      [platform] Bump maximum number of worker threads · a0059e71
      Clemens Backes authored
      The number of worker threads in the default platform is currently capped
      at 8. At runtime, it's also capped by the number of actual cores
      available.
      Since d8 is often used for benchmarking (both internally and
      externally), this CL slightly increases the maximum to 16. At least wasm
      compilation is known to scale beyond 8 threads. If this increase does
      not cause any problems on bots, we might increase further in the future.
      
      R=mlippautz@chromium.org
      
      Change-Id: I04e138c51d7dc26c38b9384c8ea67a883c976050
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182454
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67586}
      a0059e71
  37. 05 May, 2020 1 commit
  38. 24 Apr, 2020 1 commit