1. 25 Apr, 2022 1 commit
  2. 18 Feb, 2022 1 commit
  3. 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
  4. 13 Dec, 2021 1 commit
  5. 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
  6. 29 Sep, 2020 1 commit
  7. 31 Jul, 2020 3 commits
  8. 28 Jul, 2020 1 commit
  9. 24 Jul, 2020 1 commit
  10. 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
  11. 16 Jul, 2020 3 commits
  12. 15 Jul, 2020 1 commit
  13. 10 Jul, 2020 2 commits
  14. 08 Jul, 2020 1 commit
  15. 05 Jun, 2020 1 commit
  16. 26 Jul, 2019 1 commit
  17. 24 Jul, 2019 1 commit
  18. 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
  19. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  20. 24 May, 2019 1 commit
  21. 15 Apr, 2019 1 commit
    • Tom Anderson's avatar
      Avoid libc++ assert failure when building with _LIBCPP_DEBUG=0 · 4dd01774
      Tom Anderson authored
      libc++ will assert when indexing one element past the end of a vector, but V8
      uses this as the end iterator for ScopedPtrList.  Similarly, when there's no
      elements in the vector, v[0] will also assert, so ScopedPtrList::begin() needs
      to be updated too.  This CL changes ScopedPtrList to use std::vector::data() to
      get the iterators.
      
      BUG=chromium:923166
      TBR=machenbach
      
      Change-Id: Ic6a5176611d52ed592da743ecce44287c452b379
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565543
      Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
      Reviewed-by: 's avatarNico Weber <thakis@chromium.org>
      Auto-Submit: Thomas Anderson <thomasanderson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60851}
      4dd01774
  22. 03 Apr, 2019 1 commit
  23. 08 Mar, 2019 1 commit
  24. 04 Mar, 2019 1 commit
  25. 26 Feb, 2019 1 commit
  26. 23 Jan, 2019 1 commit
  27. 21 Jan, 2019 1 commit
  28. 08 Jan, 2019 1 commit
    • Toon Verwaest's avatar
      [parser] Disambiguate variables through expression-scope · f9529f6b
      Toon Verwaest authored
      Previously we'd always push variable proxies into the unresolved list of the
      current scope, and possibly delete them from the list later in case they end up
      being declarations. If variables become assigned, there were two ways to mark
      them as such: The preparser would marked the variables tracked on the
      PreParserExpression, and the parser would traverse the LHS AST to find and mark
      all variables.
      
      After this CL, if the scope already knows it's tracking declarations, the
      variables are never added to the unresolved list in the first place. If the
      scope is ambigous, it tracks the variable proxies on the side and only adds
      them to the unresolved list if they end up being references rather than
      declarations. The same list is now used to bulk mark all LHS variables as
      assigned; uniformely for both the parser and the preparser.
      
      In a next step we'll also use the scope to create declarations. That way we can
      stop tracking variables_ on PreParserExpression altogether.
      
      Change-Id: I6ada37006cc2e066731f29cd4ea314550fc7959f
      Reviewed-on: https://chromium-review.googlesource.com/c/1397669
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58629}
      f9529f6b
  29. 19 Dec, 2018 1 commit
  30. 27 Nov, 2018 1 commit
  31. 23 Nov, 2018 2 commits
  32. 22 Nov, 2018 1 commit
  33. 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
  34. 05 Nov, 2018 1 commit