1. 14 Jul, 2020 1 commit
  2. 10 Jul, 2020 1 commit
  3. 09 Jul, 2020 1 commit
  4. 08 Jul, 2020 1 commit
  5. 22 Jun, 2020 1 commit
  6. 28 May, 2020 2 commits
    • Ng Zhi An's avatar
      [clang-tidy] Make deleted constructor public · 5a776bc8
      Ng Zhi An authored
      Making them private was a way to hide the constructor, we can
      explicitly delete them, which give a better compilation error message as
      well.
      
      Also see: https://stackoverflow.com/q/55205874
      
      Bug: v8:10488
      Change-Id: I1c037a501c1da39f027c071e5e64d36fd1c95c6d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219419Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68049}
      5a776bc8
    • Leszek Swirski's avatar
      [offthread] Make publish merging and handle fixup atomic · bbc8f787
      Leszek Swirski authored
      Make sure that any GCs required for off-thread heap merging happen
      before any off-thread handle transferring (both transferring using
      OffThreadTransferHandle, and the handles created for the string slot
      fixups). This is to avoid the marker from walking Handle roots that
      point into off-thread pages which the sweeper doesn't see (and can't
      clear mark bits on)
      
      Now, the merging and handle creation is atomic as far as the GC is
      concerned. The merging is done before handle creation to avoid the
      incremental marker from entering off-thread pages, but we ensure that
      the raw objects pointers that point into the off-thread pages (which
      are used for creating the main-thread handles) stay valid until the
      handle creation completes.
      
      Since handle transfer now happens in the middle of publishing, this
      patch also moves the OffThreadTransferHandleStorage ownership over to
      OffThreadHeap. This requires some header juggling to avoid leaking
      OffThreadTransferHandleStorage into the off-thread-isolate header.
      
      Bug: chromium:1086478, chromium:1011762
      Change-Id: Id5e7622d6b5520400a4872c5f6ad396c74b30ca6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218058Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68043}
      bbc8f787
  7. 14 May, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add off thread deserialization · 595609fb
      Leszek Swirski authored
      Add a new OffThreadObjectDeserializer, which can deserialize a snapshot
      into an OffThreadIsolate.
      
      This involves templating the Deserializer base class on Isolate, and
      amending OffThreadHeap to be able to create Reservations same as the
      main-thread Heap can. Various off-thread incompatible methods are
      stubbed out as UNREACHABLE in OffThreadIsolate overloads.
      
      There is currently no API entry into the off-thread deserialization, but
      under --stress-background-compile it now runs the CodeDeserializer (i.e.
      code cache deserialization) in a background thread.
      
      Bug: chromium:1075999
      
      Change-Id: I2453f51ae31df4d4b6aa94b0804a9d6d3a03781e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172741
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67799}
      595609fb
  8. 12 May, 2020 1 commit
  9. 05 May, 2020 1 commit
  10. 15 Apr, 2020 1 commit
  11. 06 Apr, 2020 1 commit
  12. 25 Mar, 2020 1 commit
  13. 18 Mar, 2020 1 commit
  14. 10 Mar, 2020 1 commit
  15. 04 Mar, 2020 2 commits
  16. 03 Mar, 2020 2 commits
    • Leszek Swirski's avatar
      [offthread] Allow off-thread bytecode finalization · 455cb6c0
      Leszek Swirski authored
      Add the remaining missing templatizations to allow an initial wiring in
      of the off-thread factory into streaming compilation finalization.
      
      The off-thread finalization is behind a flag, disabled by default:
          --finalize-streaming-on-background
      
      When the flag is enabled, background tasks will perform perform the
      finalization during their background execution, and will release the
      parser and compilation jobs once they are no longer needed.
      
      The implementation is complete enough for performance testing, but not
      enough for launch. Notably, there is no support for:
      
        * Class boilerplates (the code is marked unreachable),
        * Exceptions during finalization, i.e. parse/compile warnings/errors,
        * Allocation sampling,
        * Logging,
        * Asm.js,
        * Parallel complication tasks
        * Forced source positions (for "NeedsDetailedOptimizedCodeLineInfo()")
      
      This patch also adds some tracing events for the various stages of the
      off-thread finalization (including the main-thread merge) for further
      performance improvements.
      
      Bug: chromium:1011762
      Change-Id: Ia44fa56975dd689f0d92c1543b294cdb063eb199
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066965
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66566}
      455cb6c0
    • Dominik Inführ's avatar
      [heap] Report total size of global handles · 65238018
      Dominik Inführ authored
      Report the total size of global handles in GetHeapStatistics as well.
      This size includes used and free global handles.
      
      Change-Id: I08c0647d993a810a37ae9f332732de9551b5ea8d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083020
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66562}
      65238018
  17. 02 Mar, 2020 1 commit
  18. 20 Feb, 2020 1 commit
  19. 13 Feb, 2020 1 commit
  20. 12 Feb, 2020 2 commits
  21. 10 Feb, 2020 1 commit
  22. 06 Feb, 2020 2 commits
  23. 04 Feb, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add an OffThreadIsolate · 7a20b6b9
      Leszek Swirski authored
      The Factory/OffThreadFactory allows us to cleanly separate object
      construction behaviour between main-thread and off-thread in a
      syntactically consistent way (so that methods templated on the factory
      type can be made to work on both).
      
      However, there are cases where we also have to access the Isolate, for
      handle creation or exception throwing. So far we have been pushing more
      and more "customization points" into the factories to allow these
      factory-templated methods to dispatch on this isolate behaviour via
      these factory methods. Unfortunately, this is an increasing layering
      violation between Factory and Isolate, particularly around exception
      handling.
      
      Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
      way as OffThreadFactory is analogous to Factory. All methods which were
      templated on Factory are now templated on Isolate, and methods which
      used to take an Isolate, and which were recently changed to take a
      templated Factory, are changed/reverted to take a templated Isolate.
      OffThreadFactory gets an isolate() method to match Factory's.
      
      Notably, FactoryHandle is changed to "HandleFor", where the template
      argument can be either of the Isolate type or the Factory type (allowing
      us to dispatch on both depending on what is available).
      
      Bug: chromium:1011762
      Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66101}
      7a20b6b9
  24. 03 Feb, 2020 1 commit
  25. 19 Jan, 2020 1 commit
  26. 17 Jan, 2020 1 commit
  27. 16 Jan, 2020 2 commits
    • Michael Lippautz's avatar
      api, heap: Fix move of on-stack TracedReference · 27e9b545
      Michael Lippautz authored
      Previously, V8 was just relinking nodes which broke when a move involves
      an on-stack reference as such nodes have different semantics.
      
      The solution is to create new internal nodes when necessary.
      
      Bug: chromium:1040038
      Change-Id: Ia5b3866ae68d014beb30972c4266aa5bae6559fc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002546
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65823}
      27e9b545
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory support to AST strings · bcbb553d
      Leszek Swirski authored
      Add support for internalizing an AstValueFactory using the off-thread
      factory. Includes adding ConsString support to OffThreadFactory.
      
      This introduces a Handle union wrapper, which is used in locations that
      can store a Handle or an OffThreadHandle. This is used in this patch for
      the internalized "string" field of AST strings, and will be able to be
      used for other similar fields in other classes (e.g. the ScopeInfo
      handle in Scope, object boilerplate descriptor handles, the inferred
      name handle on FunctionLiterals, etc.). It has a Factory-templated
      getter which returns the appropriate handle for the factory, and a
      debug-only tag to make sure the right getter is used at runtime. This
      union wrapper currently decomposes implicitly to a Handle if the getter
      is not called, to minimise code changes, but this implicit conversion
      will likely be removed for clarity.
      
      Bug: chromium:1011762
      Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65816}
      bcbb553d
  28. 15 Jan, 2020 2 commits
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory · e659917a
      Leszek Swirski authored
      Introduce OffThreadFactory with initial string construction support.
      
      The OffThreadFactory shares with Factory a new CRTP base class, called
      FactoryBase. Methods in FactoryBase return a FactoryHandle<Factory, T>
      alias, which is Handle<T> for normal Factory and a new OffThreadHandle<T>
      for OffThreadFactory. OffThreadHandle<T> behaves like Handle<T>, except
      it stores the object in-line rather than needing external storage.
      
      Any shared factory methods are moved into FactoryBase, which uses CRTP
      to call the sub-class's AllocateRaw method (plus a few more customization
      points which need Isolate access on the main thread).
      
      Methods that used to take an Isolate or Factory, and are needed off the
      main thread, are now expected to be templated on the factory type and
      to use the appropriate handle.
      
      Once an OffThreadFactory has finished being used (e.g. off-thread
      compilation completed) its pages are "Published" into the main-thread
      Heap. To deal with string internalization without creating a bunch of
      ThinStrings, this is done in two stages:
      
        1. 'FinishOffThread': The off-thread pages are walked to
           collect all slots pointing to "internalized" strings. After this is
           called it is invalid to allocate any more objects with the factory.
        2. 'Publish': On the main thread, we transform these slots into
           <Handle to holder, offset> pairs, then for each saved slot
           re-internalize its string and update the slot to point to the
           internalized string.
      
      Bug: chromium:1011762
      Change-Id: I008a694da3c357de34362bd86fe7e1f46b535d5e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992434
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65787}
      e659917a
    • Michael Lippautz's avatar
      [heap] Remove DCHECKs when clearning on-stack handles · e3b27b4a
      Michael Lippautz authored
      The DCHECKs ensured that all on-stack handles removed when the embedder
      notifies V8 of an empty stack are indeed below the current stack limit.
      
      This is brittle, as the calls that are guaranteed to have no stack
      above, e.g., non-nestable tasks executing GC, sometimes have larger
      stack depth then previously registered on-stack handles. Resetting the
      slot to avoid UAF is not possible/needed as it is guaranteed in such
      cases that the stack is indeed different from the stack that was used
      when registering an on-stack handle.
      
      This CL removes the DCHECKs and trust the embedder on such calls,
      similar to when the embedder tells V8 that there's no interesting C++
      stack on top of a call to avoid conservative stack scanning.
      
      Bug: chromium:1040038
      Change-Id: I2e8c77d8080f2d888f773984646998bede59e19c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000753Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65786}
      e3b27b4a
  29. 14 Jan, 2020 1 commit
  30. 05 Dec, 2019 1 commit
    • Ulan Degenbaev's avatar
      [heap] Decouple the lifetime of a TracedNode from the target object · d7160560
      Ulan Degenbaev authored
      Currently a TracedNode of a TracedReference is freed only if its target
      V8 object is unreachable. This is problematic for TracedNodes created for
      long-living (or immortal) V8 objects and leads to memory leaks.
      
      This CL adds logic for collecting unreachable TracedNodes:
      1) Each TracedNode gets a markbit. Initially the markbit is set (i.e.
         we have black allocation for TracedNodes).
      2) During marking RegisterEmbedderReference sets the markbit of the
         corresonding TracedNode.
      3) In the atomic pause of Mark-Compact when TracedNodes are iterated,
         we check the markbits and free TracedNodes with cleared markbits.
         After this processing all markbits are cleared for the next GC.
      
      Note that the new logic does not apply to TracedNode that have
      callbacks and/or destructors.
      
      Bug: chromium:1029738
      Change-Id: I38e76a8b4a84170793998988b1a7962e40874428
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948722
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65347}
      d7160560
  31. 22 Nov, 2019 1 commit
  32. 15 Nov, 2019 1 commit
  33. 31 Oct, 2019 1 commit