1. 25 Feb, 2021 1 commit
  2. 21 Jan, 2021 1 commit
  3. 21 Dec, 2020 1 commit
  4. 26 Nov, 2020 1 commit
  5. 25 Nov, 2020 1 commit
  6. 17 Nov, 2020 1 commit
  7. 03 Nov, 2020 1 commit
  8. 20 Oct, 2020 1 commit
  9. 03 Jun, 2020 2 commits
  10. 14 May, 2020 1 commit
  11. 12 May, 2020 1 commit
  12. 11 May, 2020 1 commit
  13. 20 Apr, 2020 1 commit
  14. 17 Apr, 2020 1 commit
  15. 23 Jan, 2020 1 commit
  16. 01 Nov, 2019 1 commit
  17. 18 Jul, 2019 1 commit
  18. 30 May, 2019 1 commit
  19. 24 May, 2019 1 commit
  20. 23 May, 2019 1 commit
  21. 22 May, 2019 1 commit
  22. 20 May, 2019 2 commits
    • Pierre Langlois's avatar
      [tracing] Emit heap statistics at every GC. · 990084ba
      Pierre Langlois authored
      When the 'disabled-by-default-v8.gc' category is enabled, emit an instant event
      with heap statistics after every GC. The data that's emitted is the same as what
      the V8 API gives you with `GetHeapStatistics()` and `GetHeapSpaceStatistics()`.
      
      We generate JSON with the following format:
      
      ```
      {
       "isolate": "0x55dd5cf03b50",
       "id": 1,
       "time_ms": 42.619,
      
       "total_heap_size": 3981312,
       "total_heap_size_executable": 573440,
       "total_physical_size": 2820440,
       "total_available_size": 2195254440,
      
       "used_heap_size": 1799616,
       "heap_size_limit": 2197815296,
       "malloced_memory": 251024,
       "external_memory": 2981,
       "peak_malloced_memory": 589280,
      
       "spaces": [
         {
           "name": "read_only_space",
           "size": 262144,
           "used_size": 32568,
           "available_size": 229256,
           "physical_size": 32888
         },
         {
           "name": "new_space",
           "size": 2097152,
           "used_size": 903392,
           "available_size": 143904,
           "physical_size": 1856136
         },
         ...
       ]
      }
      ```
      
      Bug: v8:9186
      Change-Id: I0d07aa37b65d45778d6b47dbe6e07a9dd25d1097
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619763Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#61667}
      990084ba
    • Yang Guo's avatar
      Reland "Move logging and diagnostics related source files" · bf372a73
      Yang Guo authored
      TBR=verwaest@chromium.org,rmcilroy@chromium.org
      NOTREECHECKS=true
      NOPRESUBMIT=true
      
      Bug: v8:9247
      Change-Id: I9ddfb6e56ca8e47c4ac186a8df5f442d26420a69
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617661
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61642}
      bf372a73
  23. 17 May, 2019 3 commits
  24. 15 May, 2019 1 commit
  25. 04 Apr, 2019 1 commit
  26. 25 Mar, 2019 2 commits
    • Benedikt Meurer's avatar
      [tracing] Improve tracing signals for compilation/optimization. · a2af7e11
      Benedikt Meurer authored
      This adds OBJECT/SNAPSHOT trace events for Script and SharedFunctionInfo
      objects, logging their creation with appropriate information to make
      sense of them.
      
      Based on that we introduces five flow events to model the optimized
      compilation via tracing in the "disabled-by-default-v8.compile" category:
      
        - "v8.optimizingCompile.start" logs the creation of the
          PipelineCompilationJob (for TurboFan JavaScript optimization)
          with the "function" argument referring to the trace event
          object created for the SharedFunctionInfo.
        - "v8.optimzingCompile.prepare" logs the preparation of the
          PipelineCompilationJob on the main thread, also carrying the
          "function" argument. This connects the flow event to the actual
          tracing duration event associated with the preparation phases.
        - "v8.optimizingCompile.execute" logs the (usually concurrent)
          optimization of the TurboFan graph (again with "function").
        - "v8.optimizingCompile.finalize" logs the main thread phase which
          finalizes the optimized code and eventually installs it (in case
          of success).
        - "v8.optimizingCompile.end" signals the end of the
          PipelineCompilationJob, which carries the "compilationInfo",
          that contains the interesting bits of the OptimizedCompilationInfo,
          specifically whether the compile was successfull and which functions
          were inlined for example.
      
      This also adds two instant events "V8.AbortOptimization" and
      "V8.RetryOptimization" in "disabled-by-default-v8.compile" category
      that are emitted when TurboFan cannot optimize a certain function.
      In case of "V8.RetryOptimization", TurboFan might be able to optimize
      it later, whereas "V8.AbortOptimization" permanently disables the
      optimization of a given function. The JSON representation of this is
      
      ```js
      {
        "pid": 256639,
        "tid": 256639,
        "ts": 6935411377801,
        "tts": 159116,
        "ph": "I",
        "cat": "disabled-by-default-v8.compile",
        "name": "V8.AbortOptimization",
        "dur": 0,
        "tdur": 0,
        "args": {
          "reason": "Function is too big to be optimized",
          "function": {
            "id_ref": "0x600000001",
            "scope": "v8::internal::SharedFunctionInfo"
          }
        }
      },
      ```
      
      where the "function" refers to a previously emitted SNAPSHOT for the
      function in question. In the trace viewer it will show up as instant
      event under "v8.optimizingCompile.prepare" in case of the relevant
      example where optimization is disabled due to reaching the bytecode
      limit (as in the JSON above), i.e. it'll look something like this
      
        https://i.paste.pics/aafc2de9df10ea8f5acc1a761d80f07b.png
      
      for the example highlighted in the recent blog post
      
        https://ponyfoo.com/articles/javascript-performance-pitfalls-v8
      
      that describes the optimization limit. The "v8.optimizingCompile.end"
      duration event will also carry this information as part of the
      "compilationInfo" object, but specifically for CI tools, etc. it might
      be a whole lot easier to just look for the "V8.AbortOptimization"
      instant event.
      
      Bug: v8:8598, v8:9039
      Tbr: ulan@chromium.org
      Doc: bit.ly/v8-tracing-signals
      Change-Id: Ic87ac336004690c65b6b15ad73bc6fbd4b5f12c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511483
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60448}
      a2af7e11
    • Benedikt Meurer's avatar
      [tracing] Fix namespace for TRACE_ID_WITH_SCOPE(). · 48fcceea
      Benedikt Meurer authored
      Inside V8 the TraceID class sits in v8::internal::tracing instead of
      trace_event_internal namespace (as in Chrome).
      
      Bug: v8:8834
      Change-Id: I9464e6145c4fd4c794ac3f50052a5fa1b068aeed
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535834
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60421}
      48fcceea
  27. 07 Mar, 2019 1 commit
  28. 26 Feb, 2019 1 commit
  29. 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
  30. 10 Jan, 2019 2 commits
  31. 31 Oct, 2018 1 commit
  32. 20 Oct, 2018 1 commit
  33. 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