Skip to content

V
V8
Switch branch/tag
  1. 12 Dec, 2019 5 commits
  3. 11 Dec, 2019 15 commits
  5. 10 Dec, 2019 13 commits
  7. 09 Dec, 2019 7 commits
    • Bartek Nowierski's avatar
      Introduce and emit "function calls in detached window" use counters. · 96458105
      Bartek Nowierski authored 
      NOTE! This re-introduces the following change with a modification that
detached_window_time_in_seconds is initialized with 0, instead of
current time.
https://chromium-review.googlesource.com/c/v8/v8/+/1924000

Bug: chromium:1018156
Change-Id: I6d0880e0355d2cb08dbf4f2ef92c8fcead03f9ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958344Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Bartek Nowierski <bartekn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65393}
      96458105
    • Milad Farazmand's avatar
      [base] Fix the return of ClockNow on IBMi · d406bfd6
      Milad Farazmand authored 
      The API thread_cputime() is only defined but not yet implemented on IBMi.

Change-Id: I8ea7ff724e749f537b54e75a00d718500807ca8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1957831Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#65392}
      d406bfd6
    • 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
    • v8-ci-autoroll-builder's avatar
      Update V8 DEPS. · f8d64084
      v8-ci-autoroll-builder authored 
      Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4f02786..b1050d1

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/c3cb105..8953fbe

TBR=machenbach@chromium.org,tmrts@chromium.org

Change-Id: If375ec3ca9676c651ec7097a431e101aad5ff843
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955992Reviewed-by: 's avatarv8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#65389}
      f8d64084
    • Clemens Backes's avatar
      Revert "[codegen] Remove redundant xorpd instructions" · 36f159b3
      Clemens Backes authored 
      This reverts commit c4cf2ea4.

Reason for revert: Seems to cause more regressions than improvement. Let's see what the perf bots say about the revert.

Original change's description:
> [codegen] Remove redundant xorpd instructions
> 
> It seems like they were originally added in https://crrev.com/23654026
> (Sep 2013) to break dependences in the OOO pipeline. This code pattern
> was then later copied for other instructions too
> (https://crrev.com/1424333002).
> The reason for the xorpd is not mentioned in the code though, and I
> found no other compiler doing this. So maybe it's obsolete by now, and
> only increases code size.
> 
> Let's remove them and see if we get any performance regressions.
> 
> R=​ahaas@chromium.org
> CC=​yangguo@chromium.org
> 
> Change-Id: I0e6d65afa67f0ee286e5b0ba95c91092c5261c8f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926427
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65077}

TBR=yangguo@chromium.org,ahaas@chromium.org,clemensb@chromium.org

Bug: chromium:1027876, chromium:1027449
Change-Id: I533729722e294dbe567222b1c4084df6b864d2ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958053Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65388}
      36f159b3
    • Clemens Backes's avatar
      Fix ycm config for headers without source · d4a4d285
      Clemens Backes authored 
      Instead of using hard-coded clang flags (which are missing important
flags and are thus not that useful), use the flags for some unrelated
C++ file.

R=ahaas@chromium.org

No-Try: true
Change-Id: I516df9431e8aad1a63e832aa28450475193fd404
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955549
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65387}
      d4a4d285