1. 10 Dec, 2021 1 commit
  2. 19 Aug, 2021 1 commit
  3. 20 Jul, 2021 1 commit
  4. 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
  5. 31 Aug, 2020 1 commit
    • Jake Hughes's avatar
      [heap] Add object start bitmap for conservative stack scanning · 5f6aa2e5
      Jake Hughes authored
      With conservative stack scanning enabled, a snapshot of the call stack
      upon entry to GC will be used to determine part of the root-set. When
      the collector walks the stack, it looks at each value and determines
      whether it could be a potential on-heap object pointer. However, unlike
      with Handles, these on-stack pointers aren't guaranteed to point to the
      start of the object: the compiler may decide hide these pointers, and
      create interior pointers in C++ frames which the GC doesn't know about.
      
      The solution to this is to include an object start bitmap in the header
      of each page. Each bit in the bitmap represents a word in the page
      payload which is set when an object is allocated. This means that when
      the collector finds an arbitrary potential pointer into the page, it can
      walk backwards through the bitmap until it finds the relevant object's
      base pointer. To prevent the bitmap becoming stale after compaction, it
      is rebuilt during object sweeping.
      
      This is experimental, and currently only works with inline allocation
      disabled, and single generational collection.
      
      Bug: v8:10614
      Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195
      Commit-Queue: Anton Bikineev <bikineev@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69615}
      5f6aa2e5
  6. 12 Aug, 2020 1 commit
  7. 10 Jul, 2020 1 commit