1. 24 Jul, 2020 1 commit
  2. 21 Jul, 2020 1 commit
    • Igor Sheludko's avatar
      [zone-stats] Implement collecting per-object-type zone stats · 627b8781
      Igor Sheludko authored
      ... behind --trace-zone-type-stats flag.
      
      Per-object-type statistics requires the following GN args:
        v8_enable_precise_zone_stats = true
        use_rtti = true
      
      When precise zone stats is enabled, the used zone memory value is
      calculated more precisely, in particular it takes into account
      the state of the active segment. By default, the used memory in
      the active segment is not taken into account because of performance
      overhead.
      
      Bug: v8:10572
      Change-Id: I938d9e264cfe6a8b63a89db87d187d8e2be63c8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2281006
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68972}
      627b8781
  3. 05 Jun, 2020 1 commit
  4. 05 Jun, 2019 1 commit
    • Toon Verwaest's avatar
      Reland "[zone] Use 32kb instead of 1MB as high zone page size" · 2d441185
      Toon Verwaest authored
      This is a reland of a0486202.
      It turns out that this gives ~2x speedup on highly parallel WebAssembly
      compilation, so let's try again landing this in isolation.
      
      Original change's description:
      > [zone] Use 32kb instead of 1MB as high zone page size
      >
      > It seems that allocating smaller pages is actually quite a bit faster than
      > larger pages, probably because they can be cached by malloc. Let's see what the
      > bots say.
      >
      > In a follow-up I'll check whether the segment-pool is actually beneficial or
      > whether we should just remove it.
      >
      > This also drops SegmentSize::kLarge as a way to make compilation deterministic.
      > Turns out that by now we need >8mb anyway, and the previous 1mb wasn't enough.
      > At the same time the compiler was fixed to not rely on virtual addresses of
      > zone objects anymore, and there's a bot checking whether the snapshot is
      > determistic.
      >
      > Change-Id: I38cbb0d209d68b3671fd38763b42714811f4223e
      > Reviewed-on: https://chromium-review.googlesource.com/c/1346370
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57683}
      
      Change-Id: I243ba741f0968879b4cfe9f366d81ddc53a9bf27
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645326Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62007}
      2d441185
  5. 24 May, 2019 1 commit
  6. 23 May, 2019 1 commit
  7. 21 May, 2019 1 commit
  8. 01 Mar, 2019 1 commit
  9. 28 Feb, 2019 1 commit
  10. 27 Nov, 2018 1 commit
  11. 23 Nov, 2018 2 commits
  12. 22 Nov, 2018 1 commit
  13. 21 Nov, 2018 1 commit
    • Toon Verwaest's avatar
      [zone] Use 32kb instead of 1MB as high zone page size · a0486202
      Toon Verwaest authored
      It seems that allocating smaller pages is actually quite a bit faster than
      larger pages, probably because they can be cached by malloc. Let's see what the
      bots say.
      
      In a follow-up I'll check whether the segment-pool is actually beneficial or
      whether we should just remove it.
      
      This also drops SegmentSize::kLarge as a way to make compilation deterministic.
      Turns out that by now we need >8mb anyway, and the previous 1mb wasn't enough.
      At the same time the compiler was fixed to not rely on virtual addresses of
      zone objects anymore, and there's a bot checking whether the snapshot is
      determistic.
      
      Change-Id: I38cbb0d209d68b3671fd38763b42714811f4223e
      Reviewed-on: https://chromium-review.googlesource.com/c/1346370Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57683}
      a0486202
  14. 18 Oct, 2018 1 commit
  15. 15 Oct, 2018 1 commit
  16. 26 Sep, 2018 1 commit
  17. 08 May, 2018 1 commit
  18. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored
      The "Address" type is V8's general-purpose type for manipulating memory
      addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
      are undefined behavior except within the same array; since we generally
      don't operate within a C++ array, our general-purpose type shouldn't be
      a pointer type.
      
      Bug: v8:3770
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
      Reviewed-on: https://chromium-review.googlesource.com/988657
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  19. 22 Mar, 2018 1 commit
  20. 12 Dec, 2017 1 commit
  21. 18 Oct, 2017 1 commit
  22. 02 Aug, 2017 1 commit
  23. 08 Mar, 2017 1 commit
  24. 10 Feb, 2017 1 commit
    • rmcilroy's avatar
      [Compiler] Enable use of seperate zones for parsing and compiling. · 1fc93f2e
      rmcilroy authored
      In order to allow parallel compilation of eager inner functions, we need to
      seperate the zone used for parsing (which will be shared between all the
      parallel compile jobs) and the zone used for compilation. This CL changes
      CompilationInfo to require a zone (which can be different from the zone in
      ParseInfo). We then seal the ParseInfo zone after parsing and analysis is done
      to prevent any further allocation in that zone, so that it can be shared
      (read-only) with the parallel compile jobs.
      
      BUG=v8:5203
      
      Review-Url: https://codereview.chromium.org/2645403002
      Cr-Commit-Position: refs/heads/master@{#43089}
      1fc93f2e
  25. 06 Feb, 2017 1 commit
  26. 11 Jan, 2017 1 commit
    • rmcilroy's avatar
      [compiler] Collect eager inner functions for compilation during renumbering. · a3052cfe
      rmcilroy authored
      This CL modifies the ast-numbering phase to collect function literals which
      should be compiled eagerly. This is then used to eagerly compile the inner
      functions before compiling the outer function. This will be used to queue
      compilation jobs on the CompilerDispatcher in a later CL.
      
      This CL moves the compilation of eager inner functions out of the
      GetSharedFunctionInfo function and instead compiles them explicitly. This
      simplifies GetSharedFunctionInfo and also means there is no need to pass a
      LazyCompilationMode to the function, so this concept has been removed.
      
      BUG=v8:5203,v8:5215
      
      Review-Url: https://codereview.chromium.org/2618553004
      Cr-Commit-Position: refs/heads/master@{#42221}
      a3052cfe
  27. 11 Oct, 2016 1 commit
  28. 10 Oct, 2016 2 commits
  29. 07 Oct, 2016 2 commits
  30. 06 Oct, 2016 2 commits
  31. 04 Oct, 2016 1 commit
  32. 23 Sep, 2016 2 commits
  33. 22 Sep, 2016 2 commits
  34. 20 Sep, 2016 1 commit