1. 15 Jun, 2022 1 commit
  2. 10 Jun, 2022 1 commit
  3. 08 Jun, 2022 1 commit
    • Seth Brenith's avatar
      Reland "Allow lookup of matching scripts in Isolate compilation cache" · 8742d2a2
      Seth Brenith authored
      This is a reland of commit c443858f
      
      The original version included an operation which could left-shift
      signed values, which is undefined behavior; the updated version masks
      the value first to avoid the problem.
      
      Original change's description:
      > Allow lookup of matching scripts in Isolate compilation cache
      >
      > Currently, if the same script text is compiled multiple times with
      > differing details (such as name, line number, or host-defined options),
      > then multiple copies of that script are added to the Isolate's
      > compilation cache. However, any attempt to look up those scripts can
      > find only the first instance. This change makes the script compilation
      > cache behave more consistently by checking the details while searching
      > the hash table for a match, rather than after a potential match has been
      > found.
      >
      > Bug: v8:12808
      > Change-Id: Ic9da0bf74f359d4f1c88af89d585404f173056ee
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3671615
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#80919}
      
      Bug: v8:12808
      Change-Id: I494c3c9cc520b79f34247aab6618c40c854b9edc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687070Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#81007}
      8742d2a2
  4. 02 Jun, 2022 2 commits
    • Deepti Gandluri's avatar
      Revert "Allow lookup of matching scripts in Isolate compilation cache" · a13598ae
      Deepti Gandluri authored
      This reverts commit c443858f.
      
      Reason for revert: Several UBSan failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/21547/overview
      
      Original change's description:
      > Allow lookup of matching scripts in Isolate compilation cache
      >
      > Currently, if the same script text is compiled multiple times with
      > differing details (such as name, line number, or host-defined options),
      > then multiple copies of that script are added to the Isolate's
      > compilation cache. However, any attempt to look up those scripts can
      > find only the first instance. This change makes the script compilation
      > cache behave more consistently by checking the details while searching
      > the hash table for a match, rather than after a potential match has been
      > found.
      >
      > Bug: v8:12808
      > Change-Id: Ic9da0bf74f359d4f1c88af89d585404f173056ee
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3671615
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#80919}
      
      Bug: v8:12808
      Change-Id: I6d007374fb607a2670ca260c6bd0d6774d7f51d7
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687311
      Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#80922}
      a13598ae
    • Seth Brenith's avatar
      Allow lookup of matching scripts in Isolate compilation cache · c443858f
      Seth Brenith authored
      Currently, if the same script text is compiled multiple times with
      differing details (such as name, line number, or host-defined options),
      then multiple copies of that script are added to the Isolate's
      compilation cache. However, any attempt to look up those scripts can
      find only the first instance. This change makes the script compilation
      cache behave more consistently by checking the details while searching
      the hash table for a match, rather than after a potential match has been
      found.
      
      Bug: v8:12808
      Change-Id: Ic9da0bf74f359d4f1c88af89d585404f173056ee
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3671615Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#80919}
      c443858f
  5. 01 Jun, 2022 1 commit
    • Seth Brenith's avatar
      Change key format for script cache · 4b1b7e29
      Seth Brenith authored
      This is a partial reland of https://crrev.com/c/3597106 including fixes
      from https://crrev.com/c/3654413
      
      Before this change, a script cache key is the same format as an eval
      cache key, which is a FixedArray containing:
      - The SharedFunctionInfo of the containing function
      - The source text
      - The language mode in which the code was parsed
      - The position in the source where eval was called
      
      After this change, a script cache key is a WeakFixedArray containing:
      - A weak pointer to the Script
      - The hash value of the source text
      
      This sets up for a subsequent change which can cause these keys to
      outlive their corresponding values (top-level SharedFunctionInfos)
      without leaking any memory beyond the key itself.
      
      Bug: v8:12808
      Change-Id: Ibdfe5d10eafe5b7392e554c500af47975baf45c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3668304Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#80899}
      4b1b7e29
  6. 30 May, 2022 1 commit
    • Seth Brenith's avatar
      Reland "Refactor CompilationSubCache" · 9e240773
      Seth Brenith authored
      This is a reland of commit c8848cf4
      
      This change was reverted due to a problem in a preceding change. This
      relanded version differs in its implementations of the
      CompilationCacheScript member functions Lookup, Put, and Age, because
      the intent is to not change any behavior.
      
      Original change's description:
      > CompilationSubCache has some complexity regarding generations of tables
      > which is only used by one subclass, CompilationCacheRegExp. This change
      > adjusts the class hierarchy so that classes only contain the necessary
      > member functions.
      >
      > Bug: v8:12808
      > Change-Id: I4f4cf15bbf9b80c2de0c18aea82a0c238804759d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629603
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#80506}
      
      Bug: v8:12808
      Change-Id: Ib0621b7de8da86a89752c66907f6a56adff9075d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3665936Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#80825}
      9e240773
  7. 27 May, 2022 1 commit
  8. 25 May, 2022 1 commit
  9. 19 May, 2022 1 commit
    • Seth Brenith's avatar
      Fix rehashing of script compilation cache · 2df4d58a
      Seth Brenith authored
      The script compilation cache contains weak pointers to Script objects as
      its keys. When doing a rehashing operation, any hash table needs the
      ability to get the hash code for every entry in the table. However, if
      the weak pointer was cleared from a key, there is no longer any way to
      get the hash code for that entry.
      
      In https://crrev.com/c/3597106 , I attempted to solve this problem by
      deleting all entries whose keys contain cleared weak pointers prior to
      rehashing, but the implementation has a bug: when resizing, the new
      table is allocated after deleting the entries with cleared keys, so if
      that allocation triggers a GC, the table can once again have entries
      with cleared keys.
      
      This could be solved in a variety of ways, such as:
      
      1. Iterate the entries again and delete those with cleared keys, after
         allocating the new table but before calling Rehash() to copy data
         into that new table. This means we can't directly use
         HashTable::EnsureCapacity, which normally does both the allocation
         and the rehashing.
      2. Return a bogus hash code for entries whose keys contain cleared weak
         pointers. This is simple but risks poor distribution of data after
         rehashing.
      3. Implement custom rehashing which can avoid copying entries with
         cleared keys, rather than reusing the rehashing implementation from
         HashTable.
      4. Include the hash value in every key, so a consistent hash value is
         available even after the weak Script pointer has been cleared.
      
      The fourth option sounds like the lowest risk to me, so this change
      implements that option.
      
      Bug: v8:12808
      Change-Id: I6b19b9c8af67dcfc31b74842ba581dd141e18845
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3654413Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#80637}
      2df4d58a
  10. 11 May, 2022 1 commit
    • Seth Brenith's avatar
      Improve Script reuse in isolate compilation cache, part 1 · 25072178
      Seth Brenith authored
      Once the root SharedFunctionInfo for any Script gets its bytecode
      flushed, the Isolate's compilation cache currently evicts that entry, to
      reduce memory usage. However, the associated Script is likely still
      alive, since scripts often declare functions which outlive the initial
      evaluation of the script. If an identical script is loaded later, a
      duplicate Script is created for it, which can waste memory.
      
      In this change, I propose that the compilation cache keys can refer
      weakly to the Script. When the root SharedFunctionInfo gets old, instead
      of deleting the cache entry entirely, we can just drop the strong
      reference to the SharedFunctionInfo. A subsequent lookup in the cache
      will retrieve the Script instead of the root SharedFunctionInfo,
      indicating an opportunity to save some memory by reusing the existing
      Script.
      
      Eventually, all callers to CompilationCache::LookupScript should reuse
      the Script if possible. This change implements only the easy case of
      reusing the Script for synchronous parsing. Follow-up changes will be
      required for the TODO comments left by this change.
      
      Bug: v8:12808
      Change-Id: Ia8b0389441a682de9a43e73329049fd2e7835d3d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3597106Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80472}
      25072178
  11. 15 Apr, 2021 1 commit
  12. 31 Mar, 2021 1 commit
  13. 17 Dec, 2020 1 commit
  14. 02 Dec, 2020 1 commit
  15. 17 Nov, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Share smi feedback and enable related optimizations · 3599cce1
      Jakob Gruber authored
      This CL enables a first batch of feedback-based optimizations in NCI
      code. Specifically, optimizations based on unary, binary, compare,
      for-in-next, and for-in-prepare feedback are now enabled.
      
      This has two main implications:
      
      1. NCI code can now deopt. Deoptimized code is currently thrown away
      permanently and cannot be reused. Now that shared/cached NCI code can
      deopt, this leads to an interesting question of what should happen
      with deoptimized NCI code. The answer in this CL is to remove the
      cache entry (it may later be re-added).
      
      2. Tiering up from NCI to TF still requires feedback; since NCI code,
      starting with this CL, no longer collects full feedback, feedback must
      be created in some other way. This is solved by sharing a
      context-independent encoding of feedback across native contexts.
      
      Feedback is shared through a new SerializedFeedback object type,
      essentially a byte array of serialized feedback. Currently, only
      smi-based feedback is shared, but map-based feedback will be added in
      the future.
      
      SerializedFeedback is kept in the NCI cache alongside NCI Code
      objects.  It is created on NCI cache insertion, and deserialized upon
      NCI cache hits.
      
      Bug: v8:8888
      Change-Id: Ic0d5fbea3aa4d3b0a165624dab9d0283b07dcee7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2531775Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71224}
      3599cce1
  16. 04 Nov, 2020 1 commit
  17. 03 Nov, 2020 1 commit
  18. 13 Jul, 2020 1 commit
  19. 10 Jul, 2020 1 commit
    • Leszek Swirski's avatar
      [hashtable] Allow GlobalDictionary to have holes · 82726b64
      Leszek Swirski authored
      Rather than marking deleted GlobalDictionary entries with a "The Hole"
      valued PropertyCell, we now remove those PropertyCells entirely and
      use the standard HashTable deleted item marker (also the Hole).
      
      This comes with several simplifications:
      
        1) We no longer need a customizable IsKey method on HastTable shapes,
           which was only used by GlobalDictionary to mark "The Hole" cells
           as not real keys,
        2) We can get rid of IsLive/IsKey from the Shape entirely, and define
           it directly in the HashTable, which will also allow us (in the
           future) to encourage caching of "undefined" and "Hole" where used
           for IsKey checks,
        3) PropertyCell invalidation doesn't necessarily have to allocate a
           new replacement cell (specifically, on deletion), nor does it have
           to deal with cells that contain the Hole,
        4) kNeedsHoleCheck is renamed to kMatchNeedsHoleCheck (to be explicit
           that this is only needed to guard IsMatch, which may do an
           indentity comparison and thus not need the HoleCheck guard). It's
           also moved out of BaseShape and into the various shapes that
           define IsMatch, to make them more explicitly think about the
           value,
        5) Modified some while loops into for loops to allow clearer use of
           "continue" on successful hole checks.
      
      Change-Id: If591cbb6b49d59726bdc615413aba4f78fd64632
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292230
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68807}
      82726b64
  20. 06 Jul, 2020 1 commit
  21. 12 Jun, 2020 1 commit
  22. 03 Mar, 2020 1 commit
  23. 02 Mar, 2020 1 commit
  24. 24 May, 2019 1 commit
  25. 25 Feb, 2019 1 commit
  26. 09 Jan, 2019 1 commit
  27. 26 Dec, 2018 1 commit
  28. 17 Dec, 2018 1 commit
  29. 30 Nov, 2018 3 commits
    • Ross McIlroy's avatar
      Reland "[Compiler] Introduce IsCompiledScope which prevents flushing of compiled code" · e7ea6545
      Ross McIlroy authored
      This is a reland of 10ea3f8a
      
      Original change's description:
      > [Compiler] Introduce IsCompiledScope which prevents flushing of compiled code
      >
      > Introduces a IsCompiledScope object which can be used to check whether a
      > function is compiled, and ensure it remains compiled for the lifetime
      > of the scope without being uncompiled by bytecode flushing. The Compile
      > functions are modified to take a scope so that calling code can ensure
      > the function remains compiled for the lifetime they require.
      >
      > Also, don't allocate a feedback vector for asm-wasm code as this
      > is never used, and will be reallocated if the asm-wasm code fails to
      > instantiate the module and we fallback to regular JavaScript.
      >
      > Also restructure Compiler::PostInstantiation() to allocate the feedback
      > vector once, and do the optimized code check before optimizing for
      > always opt.
      >
      > BUG=v8:8395
      >
      > Change-Id: I3f1a71143fcae3d1a0c01eefe91ebb4b8594221a
      > Reviewed-on: https://chromium-review.googlesource.com/c/1352295
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57971}
      
      TBR=jgruber@chromium.org,mstarzinger@chromium.org
      
      Bug: v8:8395
      Change-Id: I8dc00798a5680997990c879c3380fe4febd47297
      Reviewed-on: https://chromium-review.googlesource.com/c/1357045
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57982}
      e7ea6545
    • Ross McIlroy's avatar
      Revert "[Compiler] Introduce IsCompiledScope which prevents flushing of compiled code" · 07537cdb
      Ross McIlroy authored
      This reverts commit 10ea3f8a.
      
      Reason for revert: Causing failure on gc_stress bot: 
      https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8928421099411850688/+/steps/Bisect_10ea3f8a/0/steps/Retry/0/logs/collections-construct../0
      
      Original change's description:
      > [Compiler] Introduce IsCompiledScope which prevents flushing of compiled code
      > 
      > Introduces a IsCompiledScope object which can be used to check whether a
      > function is compiled, and ensure it remains compiled for the lifetime
      > of the scope without being uncompiled by bytecode flushing. The Compile
      > functions are modified to take a scope so that calling code can ensure
      > the function remains compiled for the lifetime they require.
      > 
      > Also, don't allocate a feedback vector for asm-wasm code as this
      > is never used, and will be reallocated if the asm-wasm code fails to
      > instantiate the module and we fallback to regular JavaScript.
      > 
      > Also restructure Compiler::PostInstantiation() to allocate the feedback
      > vector once, and do the optimized code check before optimizing for
      > always opt.
      > 
      > BUG=v8:8395
      > 
      > Change-Id: I3f1a71143fcae3d1a0c01eefe91ebb4b8594221a
      > Reviewed-on: https://chromium-review.googlesource.com/c/1352295
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57971}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org
      
      Change-Id: I1449a02a0aceb9757440757628e586df33972a40
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8395
      Reviewed-on: https://chromium-review.googlesource.com/c/1357042Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57974}
      07537cdb
    • Ross McIlroy's avatar
      [Compiler] Introduce IsCompiledScope which prevents flushing of compiled code · 10ea3f8a
      Ross McIlroy authored
      Introduces a IsCompiledScope object which can be used to check whether a
      function is compiled, and ensure it remains compiled for the lifetime
      of the scope without being uncompiled by bytecode flushing. The Compile
      functions are modified to take a scope so that calling code can ensure
      the function remains compiled for the lifetime they require.
      
      Also, don't allocate a feedback vector for asm-wasm code as this
      is never used, and will be reallocated if the asm-wasm code fails to
      instantiate the module and we fallback to regular JavaScript.
      
      Also restructure Compiler::PostInstantiation() to allocate the feedback
      vector once, and do the optimized code check before optimizing for
      always opt.
      
      BUG=v8:8395
      
      Change-Id: I3f1a71143fcae3d1a0c01eefe91ebb4b8594221a
      Reviewed-on: https://chromium-review.googlesource.com/c/1352295Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57971}
      10ea3f8a
  30. 28 Nov, 2018 1 commit
  31. 27 Nov, 2018 1 commit
  32. 23 Nov, 2018 1 commit
  33. 05 Nov, 2018 1 commit
  34. 31 Oct, 2018 1 commit
  35. 14 Sep, 2018 1 commit
  36. 13 Sep, 2018 1 commit
  37. 13 Jul, 2018 1 commit