1. 28 Jul, 2022 1 commit
  2. 13 May, 2022 1 commit
  3. 25 Apr, 2022 2 commits
  4. 24 Feb, 2022 1 commit
    • Clemens Backes's avatar
      Fail earlier on FreePages · 205fb295
      Clemens Backes authored
      {FreePages} is never expected to fail, and each caller wraps the call in
      a CHECK macro. In order to learn more about failures, this CL moves the
      CHECK inside of {::FreePages}, to fail whenever the {PageAllocator}
      fails to free pages.
      
      As a next step, I'll audit our {PageAllocator} implementations to ensure
      that none of them return {false} for {FreePages}. Note that this is
      already the case for the gin platform (chromium).
      
      R=mlippautz@chromium.org
      
      Bug: v8:12656, chromium:1299735
      Change-Id: Ib61be6cc8da0110ead2db1ad005728bd061e0243
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3484321Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79248}
      205fb295
  5. 18 Feb, 2022 1 commit
  6. 08 Feb, 2022 1 commit
    • Jakob Gruber's avatar
      [regexp] Don't check for excess zone allocations · cb4f3c69
      Jakob Gruber authored
      The regexp parser historically has tried to gracefully detect and bail
      out from excess zone allocations, where 'excess' was determined to be
      an arbitrary limit of 256MB.
      
      This leads to issues now that the regexp parser may run from within
      the JS parser - the JS parser doesn't observe this arbitrary limit and
      happily keeps allocating until the underlying allocator actually runs
      out of memory; this way, the JS parser can handle very large JS files,
      and it's now counterproductive if the regexp parser (which reuses the
      JS parser zone) bails out on excess allocations.
      
      This CL simply removes the excess_allocation mechanism.
      
      Bug: chromium:1264014
      Change-Id: I8d93a1e52aa65bb0ea6c2aab3b68b479ce79a1f6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401580Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78991}
      cb4f3c69
  7. 14 Dec, 2021 1 commit
  8. 13 Dec, 2021 1 commit
  9. 02 Nov, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Release regexp zone memory during JS parsing · 30cab7b1
      Jakob Gruber authored
      Since early regexp errors were implemented in
      crrev.com/a56874d3, the JS parser
      calls into the regexp parser to validate the regexp literal syntax.
      
      For these calls, the JS parser passes its Zone to the regexp parser.
      This means that scripts with multiple regexp literals are all parsed
      using the same Zone memory. Very large scripts with many (think
      hundreds of thousands) regexp literals may thus run out of memory
      whereas previously they would parse and run successfully.
      
      This CL fixes the OOMs by resetting the state of the JS parser Zone
      around regexp parser calls. We introduce a new ZoneScope class,
      similar to HandleScope, which controls the lifetime of zone objects
      allocated within its scope. In other words:
      
       {
         ZoneScope zone_scope(zone);  // Store zone state S.
         // ... Allocate objects O in zone.
         // zone is now in state S'.
       }
       // zone_scope goes out of scope, reset zone to state S. Objects O
       // are freed and no longer usable.
      
      Fixed: chromium:1264014
      Bug: v8:896
      Change-Id: I3e7ac36f25a9d6c4eda2460bd1bea9814685e89b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256783Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77646}
      30cab7b1
  10. 07 Oct, 2021 1 commit
    • Samuel Groß's avatar
      Add PageInitializationMode enum for the BoundedPageAllocator · 18c37d32
      Samuel Groß authored
      Currently, when compiling with V8_VIRTUAL_MEMORY_CAGE enabled, the
      behavior of the BoundedPageAllocator changes from simply making freed
      pages inaccessible to decommitting them, which guarantees that they will
      be zero-initialized after the next allocation. As this seems to cause
      some performance regressions on Mac, this CL introduces a new enum that
      specifies how the allocator should behave:
      kAllocatedPagesMustBeZeroInitialized causes the pages to be decommitted
      during FreePages() and ReleasePages() and thus guarantees
      zero-initialization during AllocPages().
      kAllocatedPagesCanBeUninitialized only causes the pages to be made
      inaccessible, and so does not generally guarantee zero-initialization
      for AllocPages().
      
      Finally, this CL also removes some dead code in allocation.cc.
      
      Bug: chromium:1257089
      Change-Id: I53fa52c8913df869bee2b536efe252780d1ad893
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208812
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77285}
      18c37d32
  11. 23 Sep, 2021 1 commit
    • Anton Bikineev's avatar
      [zone] Provide a way to configure allocator for zone backings · e262e1cb
      Anton Bikineev authored
      The CL provides a way for the embedder to hook in a special malloc-like
      allocator that will be used for zone allocations.
      
      An alternative approach would be to use weak functions with branches,
      checking whether the functions were available at link-time. Those
      branches could be optimized away with LTOs, so they would essentially
      be free. However, the weak function approach is not portable (e.g.
      there is no easy way to emulate it with msvc). The approach can be
      revisited if indirect call turns out to be expensive (e.g. on hardware
      with weak branch target predictors).
      
      The CL is a prerequisite for running PCScan in the renderer process.
      
      Bug: chromium:1249550
      Change-Id: I221dcb2486c13e8e6e6761839ba391978319bde4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172760Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77012}
      e262e1cb
  12. 01 Jul, 2021 1 commit
  13. 18 Jun, 2021 2 commits
  14. 10 Jun, 2021 1 commit
  15. 27 Apr, 2021 1 commit
  16. 25 Feb, 2021 1 commit
  17. 24 Nov, 2020 1 commit
  18. 17 Nov, 2020 1 commit
  19. 11 Nov, 2020 1 commit
  20. 06 Oct, 2020 1 commit
  21. 29 Sep, 2020 1 commit
  22. 17 Aug, 2020 1 commit
  23. 31 Jul, 2020 4 commits
  24. 28 Jul, 2020 1 commit
  25. 24 Jul, 2020 2 commits
  26. 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
  27. 17 Jul, 2020 1 commit
  28. 16 Jul, 2020 3 commits
  29. 15 Jul, 2020 1 commit
  30. 13 Jul, 2020 1 commit
  31. 10 Jul, 2020 2 commits