1. 07 Jan, 2020 1 commit
  2. 02 Jan, 2020 2 commits
  3. 26 Dec, 2019 1 commit
  4. 20 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      Revert "Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()" · 4671cb56
      Tobias Tebbi authored
      This reverts commit 91e3243d.
      
      Reason for revert: This deopts to the wrong point.
      
      Original change's description:
      > Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()
      > 
      > Current GetIterator bytecode loads and calls @@iterator property on a
      > given object. This change extends the bytecode functionality to check
      > whether the value returned after calling @@iterator property is a valid
      > JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the
      > returned value is not a valid JSReceiver. This change absorbs the
      > functionality of additional two bytecodes - JumpIfJSReceiver and
      > CallRuntime, that are part of the iterator protocol in the GetIterator
      > bytecode.
      > 
      > Bug: v8:9489
      > Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Cr-Commit-Position: refs/heads/master@{#63704}
      
      TBR=rmcilroy@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9489
      Change-Id: I9324b5b01ead29912ad793a1e7b4d009643d7901
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960288Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65541}
      4671cb56
  5. 19 Dec, 2019 4 commits
  6. 18 Dec, 2019 4 commits
  7. 17 Dec, 2019 6 commits
  8. 16 Dec, 2019 1 commit
  9. 13 Dec, 2019 1 commit
  10. 12 Dec, 2019 2 commits
  11. 11 Dec, 2019 3 commits
  12. 09 Dec, 2019 3 commits
    • Leszek Swirski's avatar
      [parser] Use non-eval decl scope's parent for caching · fffea681
      Leszek Swirski authored
      We use the compilation entry point as a caching scope for deserializing
      lookups, to avoid redundantly iterating over parent scopes when
      accessing the same variable multiple times.
      
      However, this caching scope messes with lookups that are looking for
      lexical name conflicts, as opposed to just resolving variables. In
      particular, it messes with name conflict lookups and sloppy block
      function hoisting checks, when there are other scopes in the way, e.g.
      
          function f() {
            let x;
            try {
              throw 0;
            }
            catch (x) {
              // This catch is the entry scope
      
              // Naive use of caches will find the catch-bound x (which is
              // a VAR), and declare 'no conflict'.
              eval("var x;");
      
              // Naive use of caches will find the catch-bound x (which is
              // a VAR), and determine that this function can be hoisted.
              eval("{ function x() {} }");
            }
          }
      
      Previously, we worked around this by avoiding cache uses for these
      lookups, but this had the issue of instead caching the same variable
      multiple times, on different scopes. In particular, we saw:
      
          function f() {
            with ({}) {
              // This with is the entry scope, any other scope would do
              // though.
      
              // The conflict check on `var f` caches the function name
              // variable on the function scope, the subsequent 'real'
              // lookup of `f` caches the function name variable on the
              // entry i.e. with scope.
              eval("var f; f;");
            }
          }
      
      With this patch, we change the caching behaviour to cache on the first
      non-eval declaration scope above the eval -- in the above examples, this
      becomes the parent function "f". For compilations with no intermediate
      non-decl scopes (no with or catch scopes between the function and eval)
      this becomes equivalent to the existing entry-point-based caching.
      
      This means that normal lookups do have to (sometimes) iterate more scopes,
      and we do have to be careful when using the cache to not use it for
      lookups in these intermediate scopes (a new IsOuterScope DCHECK guards
      against this), but we can now safely ignore the cache scope when doing
      the name-collision lookups, as they only iterate up to the outer
      non-eval declaration scope anyway.
      
      Bug: chromium:1026603
      Bug: chromium:1029461
      Change-Id: I9e7a96ce4b8adbc7ed47a49fba6fba58b526235b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955731
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65391}
      fffea681
    • Leszek Swirski's avatar
      Revert "[parser] Fix variable caching for conflict lookup" · b8fef1a7
      Leszek Swirski authored
      This reverts commit 026a0c21.
      
      Reason for revert: Reverting due to https://crbug.com/1029461
      
      Original change's description:
      > [parser] Fix variable caching for conflict lookup
      > 
      > During conflict lookup (for lexical variables and sloppy block function
      > hoisting), we cache the looked-up variable on the current scope if the
      > lookup goes through a ScopeInfo. However, for variable lookup during
      > scope analysis, we use the "entry point" as the cache.
      > 
      > Since both lookups can create Variables, this can cause us to create
      > duplicate variables, e.g. a duplicate function name variable in the
      > attached test.
      > 
      > Instead, for ScopeInfo conflict lookups we can cache the result on the
      > function's outer scope, which shoud be equivalent to the entry point.
      > 
      > As a (necessary) drive-by, we can terminate the lookup early if we find
      > a VAR with the same name, as we can safely assume that its existence
      > means that it doesn't conflict, which means that our variable can't
      > conflict either.
      > 
      > Bug: chromium:1026603
      > Change-Id: I19f80f65597ba6573ebe0b48aa5698f55e5c3ea1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928861
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65138}
      
      TBR=leszeks@chromium.org,verwaest@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:1026603
      Bug: chromium:1029461
      Change-Id: Id7f5dd342e32e1bb57c51b3748feff32ee0ba41d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958014Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65390}
      b8fef1a7
    • Zhang, Shiyu's avatar
      Reland "[runtime] Cache prototype chain enumerable keys in PrototypeInfo" · 3b753563
      Zhang, Shiyu authored
      This is a reland of 5253d7bf
      
      Original change's description:
      > [runtime] Cache prototype chain enumerable keys in PrototypeInfo
      > 
      > This CL adds a prototype_chain_enum_cache to cache the enumeration of a
      > prototype and its entire chain on the PrototypeInfo. It can improve for-in
      > performance via simply merging the receiver enumeration with this cache.
      > 
      > It improves the score of JetStream2-tagcloud-SP case by ~9% on IA Chromebook.
      > 
      > Contributed by tao.pan@intel.com
      > 
      > Change-Id: Ib40bfe41e772672337155584672f06fa1ba1e70d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870844
      > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65224}
      
      Change-Id: I93b74727c46abbaab163324c50fbd977fcc9bb36
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955232Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      Cr-Commit-Position: refs/heads/master@{#65377}
      3b753563
  13. 05 Dec, 2019 2 commits
  14. 04 Dec, 2019 5 commits
  15. 03 Dec, 2019 3 commits
  16. 02 Dec, 2019 1 commit