1. 17 Jun, 2021 1 commit
  2. 03 May, 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. 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
  5. 21 Feb, 2020 1 commit
  6. 23 May, 2019 1 commit
  7. 22 May, 2019 1 commit
  8. 21 May, 2019 1 commit
  9. 13 May, 2019 1 commit
  10. 10 May, 2019 1 commit
  11. 09 May, 2019 1 commit
  12. 03 May, 2019 1 commit
  13. 29 Apr, 2019 1 commit
  14. 30 Jan, 2019 1 commit
  15. 05 Dec, 2018 1 commit