1. 16 Apr, 2021 2 commits
  2. 15 Feb, 2021 1 commit
  3. 16 Oct, 2020 1 commit
    • Pierre Langlois's avatar
      [heap] Make maximum regular code object size a runtime value. · f4376ec8
      Pierre Langlois authored
      Executable V8 pages include 3 reserved OS pages: one for the writable
      header and two as guards. On systems with 64k OS pages, the amount of
      allocatable space left for objects can then be quite smaller than the
      page size, only 64k for each 256k page.
      
      This means regular code objects cannot be larger than 64k, while the
      maximum regular object size is fixed to 128k, half of the page size. As
      a result code object never reach this limit and we can end up filling
      regular pages with few large code objects.
      
      To fix this, we change the maximum code object size to be runtime value,
      set to half of the allocatable space per page. On systems with 64k OS
      pages, the limit will be 32k.
      
      Alternatively, we could increase the V8 page size to 512k on Arm64 linux
      so we wouldn't waste code space. However, systems with 4k OS pages are
      more common, and those with 64k pages tend to have more memory available
      so we should be able to live with it.
      
      Bug: v8:10808
      Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#70569}
      f4376ec8
  4. 25 May, 2020 1 commit
  5. 28 Aug, 2019 1 commit
  6. 12 Mar, 2019 1 commit
  7. 26 Nov, 2018 1 commit
  8. 29 Oct, 2018 1 commit
  9. 29 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [async-await] Unify handling of await closure contexts. · 9e99297e
      Benedikt Meurer authored
      Change the way that the (internal) await closures store the link to the
      generator object by introducing a dedicated AwaitContext, which stores
      the generator object into the extension slot (instead of misusing a
      regular FunctionContext here). Also unify the allocation+initialization
      of these contexts in the await-related builtins (both for async functions
      and generators).
      
      The rationale behind this is that for (zero-cost) async stack traces, we
      will need to dig into these contexts and we can do better checking with
      a dedicated instance type there. As an additional benefit, we save one
      word per await context, since we just use (the otherwise unused) extension
      slot to remember the generator object. As yet another benefit we will
      never accidentally use any of these contexts in the regular scope chain
      lookups, meaning we can also catch bugs there. And last but not least
      the objects printing machinery understands these contexts now and can
      even print the generator object for AwaitContexts for short printing,
      which is really valuable for debugging.
      
      Tbr: ulan@chromium.org
      Bug: v8:7253, v8:7522, v8:8015
      Change-Id: I86955f5701e694e8a10b91ebe5f52705aa90968d
      Reviewed-on: https://chromium-review.googlesource.com/1249491Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56301}
      9e99297e
  10. 17 Jul, 2018 1 commit
  11. 27 Jun, 2018 1 commit
  12. 15 Jun, 2018 1 commit
  13. 28 Apr, 2018 1 commit
  14. 23 Mar, 2018 3 commits
  15. 12 Oct, 2017 1 commit