1. 19 Feb, 2021 1 commit
  2. 16 Feb, 2021 1 commit
  3. 09 Feb, 2021 1 commit
  4. 26 Nov, 2020 1 commit
  5. 18 Nov, 2020 1 commit
  6. 30 Sep, 2020 1 commit
    • Jakob Gruber's avatar
      Rename legacy code kinds · 29bcdaad
      Jakob Gruber authored
      CodeKind::OPTIMIZED_CODE -> TURBOFAN
      
      Kinds are now more fine-grained and distinguish between TF, TP, NCI.
      
      CodeKind::STUB -> DEOPT_ENTRIES_OR_FOR_TESTING
      
      Code stubs (like builtins, but generated at runtime) were removed from
      the codebase years ago, this is the last remnant. This kind is used
      only for deopt entries (which should be converted into builtins) and
      for tests.
      
      Change-Id: I67beb15377cb60f395e9b051b25f3e5764982e93
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440335
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70234}
      29bcdaad
  7. 16 Sep, 2020 1 commit
    • 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
  8. 11 Sep, 2020 1 commit
  9. 03 Sep, 2020 1 commit
  10. 01 Sep, 2020 1 commit
    • 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
  11. 31 Aug, 2020 1 commit
    • Alex Kodat's avatar
      [cpu-profiler] Ensure sampled thread has Isolate lock under Windows · dfb3f7da
      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 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/+/2377108Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69623}
      dfb3f7da
  12. 28 Aug, 2020 1 commit
  13. 26 Aug, 2020 1 commit
  14. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored
      With the new Turbofan variants (NCI and Turboprop), we need a way to
      distinguish between them both during and after compilation. We
      initially introduced CompilationTarget to track the variant during
      compilation, but decided to reuse the code kind as the canonical spot to
      store this information instead.
      
      Why? Because it is an established mechanism, already available in most
      of the necessary spots (inside the pipeline, on Code objects, in
      profiling traces).
      
      This CL removes CompilationTarget and adds a new
      NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
      various things about a given code kind (e.g.: does this code kind
      deopt?).
      
      As a (very large) drive-by, refactor both Code::Kind and
      AbstractCode::Kind into a new CodeKind enum class.
      
      Bug: v8:8888
      Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  15. 24 Jul, 2020 1 commit
  16. 06 Jul, 2020 1 commit
  17. 15 Jun, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Add native_context_independent flags · f30b53bd
      Jakob Gruber authored
      ... to OptimizedCompilationInfo, BytecodeGraphBuilder, and
      JSHeapBroker.
      
      Also add first uses of these flags in pipeline.cc by skipping certain
      phases when nci is enabled. With this change, tests in the NCI variant
      will start to fail since generic lowering is not fully implemented.
      These implementations will follow incrementally in the next days.
      
      Bug: v8:8888
      Change-Id: I3f570fb92f09059d1f1f4015f88ffe80ccf746ad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2239572
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68339}
      f30b53bd
  18. 10 Jun, 2020 1 commit
  19. 03 Jun, 2020 1 commit
  20. 26 May, 2020 1 commit
  21. 17 Apr, 2020 1 commit
  22. 10 Sep, 2019 1 commit
  23. 18 Jul, 2019 1 commit
  24. 08 Jul, 2019 1 commit
    • Peter Marshall's avatar
      [tracing] Use the new perfetto client API · edd383fb
      Peter Marshall authored
      The client API provides a much simpler interface so that we don't have
      to deal with producers, consumers etc. directly. This CL removes all the
      code that dealt with the more complex API used previously.
      
      The architecture used here requires that the embedder call into
      Tracing::Initialize() to set up the tracing backend. The tracing
      controller then connects to this backend when calling
      DataSource::Register() and Tracing::NewTrace(). This will ultimately
      avoid the need for a virtual call (or two) for every trace event that
      need to be dispatched over the API - chrome can provide a backend
      and V8 will connect to it opaquely with the same code when tracing is
      enabled.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng
      Bug: v8:8339
      Change-Id: I6b74fbb49ffcc89638caeb59ed3d5cc81238f3e8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634916Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62568}
      edd383fb
  25. 05 Jul, 2019 1 commit
  26. 23 May, 2019 2 commits
  27. 21 May, 2019 1 commit
  28. 02 May, 2019 2 commits
    • Maciej Goszczycki's avatar
      Reland "[heap] Skip ro-space from heap iterators, add CombinedHeapIterator." · 9c062093
      Maciej Goszczycki authored
      Code relocation info is now always allocated in old-space. Before relocation
      info allocated for placeholders and builtins (which get replaced with
      trampolines in nosnap builds) would become unreachable. Since read-only space
      is not GCed and ReadOnlyHeapIterator doesn't check for reachability,
      ValidateSnapshot would fail finding unreachable objects returned by
      ReadOnlyHeapIterator.
      
      Because trampoline relocation info gets replaced with canonical one, this only
      affects no-embdded-builtins nosnap builds, which don't get much benefit from
      read-only relocation info anyway.
      
      A new check has been added to the read-only deserializer to verify that every
      read-only object is reachable at mksnapshot-time.
      
      The CombinedHeapIterator iteration order was changed to iterate over
      read-only space first, because that's how HeapIterator worked.
      
      This is a reland of 3d1d8eae
      
      Original change's description:
      > [heap] Skip ro-space from heap iterators, add CombinedHeapIterator.
      >
      > Read-only space sharing requires an iterator independent of heap. This
      > also enables future removal of read-only space from heap.
      >
      > Bug: v8:7464
      > Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795
      > Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#60819}
      
      Bug: v8:7464
      Change-Id: I49ae070955b77956962334a84f762ab29052d5ff
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566513Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
      Cr-Commit-Position: refs/heads/master@{#61185}
      9c062093
    • Georg Neis's avatar
      [turbofan] Don't allocate JSHeapBroker in the zone · 611a0d19
      Georg Neis authored
      This fixes a memory leak.
      
      Bug: v8:9191, v8:7790
      Change-Id: I0df49cd3a6791600638a67b4b7ad9687562e500b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588426
      Commit-Queue: Georg Neis <neis@chromium.org>
      Auto-Submit: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61166}
      611a0d19
  29. 12 Apr, 2019 2 commits
  30. 01 Feb, 2019 1 commit
  31. 29 Jan, 2019 3 commits
  32. 23 Jan, 2019 1 commit
  33. 18 Jan, 2019 1 commit
  34. 16 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Clean up base::EnumSet · 4064757c
      Clemens Hammacher authored
      After moving to its own header, this CL cleans up some parts of the
      interface. It fixes names and const-declarations of simple accessors,
      and adds a named constructor to make it explicit that an EnumSet should
      be constructed from an integral value.
      Also refactor the use in cctest.h to have less statically declared
      constants. Instead, just create the set of extensions in the individual
      tests.
      
      R=titzer@chromium.org
      
      Bug: v8:8562
      Change-Id: I6178d1aba25afa1d7f54c29ccf81505c165e7cd3
      Reviewed-on: https://chromium-review.googlesource.com/c/1409366
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58862}
      4064757c
  35. 08 Jan, 2019 1 commit