1. 08 Aug, 2017 1 commit
    • Adam Klein's avatar
      Throw errors when assigning to const variables inside `with` · a9846ad4
      Adam Klein authored
      This code appears to have been wrong forever, as it only
      threw in strict mode (presumably predating ES2015 const).
      
      In order to get exactly the right behavior, special
      handling of sloppy named function expressions is required.
      Rather than polluting PropertyAttributes with another
      dummy value, this CL simply adds a bool output argument
      to Context::Lookup to indicate that case.
      
      Bug: v8:6677
      Change-Id: I34daa5080d291808f10cbaefc91d716f0b22963b
      Reviewed-on: https://chromium-review.googlesource.com/602690Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47207}
      a9846ad4
  2. 29 Jun, 2017 1 commit
  3. 14 Jun, 2017 1 commit
  4. 22 May, 2017 1 commit
  5. 10 May, 2017 1 commit
  6. 08 May, 2017 1 commit
    • Ross McIlroy's avatar
      Revert "Reland: [TypeFeedbackVector] Store optimized code in the vector" · fd749344
      Ross McIlroy authored
      This reverts commit 662aa425.
      
      Reason for revert: Crashing on Canary
      BUG=chromium:718891
      
      Original change's description:
      > Reland: [TypeFeedbackVector] Store optimized code in the vector
      > 
      > Since the feedback vector is itself a native context structure, why
      > not store optimized code for a function in there rather than in
      > a map from native context to code? This allows us to get rid of
      > the optimized code map in the SharedFunctionInfo, saving a pointer,
      > and making lookup of any optimized code quicker.
      > 
      > Original patch by Michael Stanton <mvstanton@chromium.org>
      > 
      > BUG=v8:6246
      > TBR=yangguo@chromium.org,ulan@chromium.org
      > 
      > Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
      > Reviewed-on: https://chromium-review.googlesource.com/494487
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45084}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
      # Not skipping CQ checks because original CL landed > 1 day ago.
      BUG=v8:6246
      
      Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
      Reviewed-on: https://chromium-review.googlesource.com/498633Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45174}
      fd749344
  7. 04 May, 2017 1 commit
    • Ross McIlroy's avatar
      Reland: [TypeFeedbackVector] Store optimized code in the vector · 662aa425
      Ross McIlroy authored
      Since the feedback vector is itself a native context structure, why
      not store optimized code for a function in there rather than in
      a map from native context to code? This allows us to get rid of
      the optimized code map in the SharedFunctionInfo, saving a pointer,
      and making lookup of any optimized code quicker.
      
      Original patch by Michael Stanton <mvstanton@chromium.org>
      
      BUG=v8:6246
      TBR=yangguo@chromium.org,ulan@chromium.org
      
      Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
      Reviewed-on: https://chromium-review.googlesource.com/494487Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45084}
      662aa425
  8. 02 May, 2017 2 commits
  9. 06 Feb, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root feedback vectors at function literal site. · aea3ce3d
      mvstanton authored
      TypeFeedbackVectors are strongly rooted by a closure. However, in modern
      JavaScript closures are created and abandoned more freely. An important
      closure may not be present in the root-set at time of garbage collection,
      even though we've cached optimized code and use it regularly. For
      example, consider leaf functions in an event dispatching system. They may
      well be "hot," but tragically non-present when we collect the heap.
      
      Until now, we've relied on a weak root to cache the feedback vector in
      this case. Since there is no way to signal intent or relative importance,
      this weak root is as susceptible to clearing as any other weak root at
      garbage collection time.
      
      Meanwhile, the feedback vector has become more important. All of our
      ICs store their data there. Literal and regex boilerplates are stored there.
      If we lose the vector, then we not only lose optimized code built from
      it, we also lose the very feedback which allowed us to create that optimized
      code. Therefore it's vital to express that dependency through the root
      set.
      
      This CL does this by creating a strong link to a feedback
      vector at the instantiation site of the function closure.
      This instantiation site is in the code and feedback vector
      of the outer closure.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2674593003
      Cr-Commit-Position: refs/heads/master@{#42953}
      aea3ce3d
  10. 30 Jan, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Combine the literals array and the feedback vector. · 93f05b64
      mvstanton authored
      They have the same lifetime. It's a match!
      
      Both structures are native context dependent and dealt with (creation,
      clearing, gathering feedback) at the same time. By treating the spaces used
      for literal boilerplates as feedback vector slots, we no longer have to keep
      track of the materialized literal count elsewhere.
      
      A follow-on CL removes even more parser infrastructure related to this count.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2655853010
      Cr-Commit-Position: refs/heads/master@{#42771}
      93f05b64
  11. 19 Jan, 2017 3 commits
  12. 12 Jan, 2017 3 commits
  13. 22 Dec, 2016 1 commit
  14. 21 Dec, 2016 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root literal arrays in function literals slots · 93df0940
      mvstanton authored
      Literal arrays and feedback vectors for a function can be garbage
      collected if we don't have a rooted closure for the function, which
      happens often. It's expensive to come back from this (recreating
      boilerplates and gathering feedback again), and the cost is
      disproportionate if the function was inlined into optimized code.
      
      To guard against losing these arrays when we need them, we'll now
      create literal arrays when creating the feedback vector for the outer
      closure, and root them strongly in that vector.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2504153002
      Cr-Commit-Position: refs/heads/master@{#41893}
      93df0940
  15. 20 Dec, 2016 1 commit
    • littledan's avatar
      Use a different map to distinguish eval contexts · 53fdf9d1
      littledan authored
      eval() may introduce a scope which needs to be represented as a context at
      runtime, e.g.,
      
        eval('var x; let y; ()=>y')
      
      introduces a variable y which needs to have a context allocated for it. However,
      when traversing upwards to find the declaration context for a variable which leaks,
      as the declaration of x does above, this context has to be understood to not be
      a declaration context in sloppy mode.
      
      This patch makes that distinction by introducing a different map for eval-introduced
      contexts. A dynamic search for the appropriate context will continue past an eval
      context to find the appropriate context. Marking contexts as eval contexts rather
      than function contexts required updates in each compiler backend.
      
      BUG=v8:5295, chromium:648719
      
      Review-Url: https://codereview.chromium.org/2435023002
      Cr-Commit-Position: refs/heads/master@{#41869}
      53fdf9d1
  16. 08 Dec, 2016 3 commits
  17. 07 Dec, 2016 1 commit
  18. 25 Oct, 2016 3 commits
  19. 20 Sep, 2016 1 commit
    • littledan's avatar
      Filter out synthetic variables from with scopes · dcd61b90
      littledan authored
      This patch ensures that variables like .new_target aren't overwritable
      using with scopes. It does this by ensuring that scope analysis does
      not consider with scopes (or eval scopes) for such 'synthetic variables',
      similarly to how the 'this' variable was already handled.
      The patch also adds a DCHECK for the dynamic parallel to this case,
      replacing a previous unreachable path for a particular instance.
      
      BUG=v8:5405
      
      Review-Url: https://codereview.chromium.org/2353623002
      Cr-Commit-Position: refs/heads/master@{#39567}
      dcd61b90
  20. 16 Sep, 2016 1 commit
  21. 12 Sep, 2016 4 commits
  22. 07 Sep, 2016 1 commit
    • jochen's avatar
      Chain ScopeInfos together · ce3f46b1
      jochen authored
      This will allow getting the entire scope chain from a SharedFunctionInfo
      which in turn will allow for generating bytecode when we just have the
      SFI
      
      R=verwaest@chromium.org,marja@chromium.org
      BUG=v8:5215
      
      Review-Url: https://codereview.chromium.org/2271993002
      Cr-Commit-Position: refs/heads/master@{#39243}
      ce3f46b1
  23. 06 Sep, 2016 1 commit
  24. 05 Sep, 2016 1 commit
    • jochen's avatar
      Store the scope info in catch contexts · 9b6ff3a8
      jochen authored
      Since the extension field is already used for the catch name, store a
      ContextExtension there instead.
      
      In the future, this will allow for chaining ScopeInfos together, so we
      no longer need a context chain for lazy parsing / compilation.
      
      BUG=v8:5215
      R=bmeurer@chromium.org,neis@chromium.org,marja@chromium.org
      
      Review-Url: https://codereview.chromium.org/2302013002
      Cr-Commit-Position: refs/heads/master@{#39164}
      9b6ff3a8
  25. 01 Sep, 2016 1 commit
  26. 31 Aug, 2016 1 commit
    • adamk's avatar
      Remove CONST_LEGACY VariableMode · 7516fe1e
      adamk authored
      The only remaining use of this VariableMode is for the names of sloppy
      named function expressions. This patch instead uses CONST for such
      bindings (just as we do in strict mode) and instead marks those
      Variables specially. During code generation a new helper method,
      Variable::throw_on_const_assignment(), is called to decide whether
      to throw or silently ignore the assignment.
      
      Review-Url: https://codereview.chromium.org/2233673003
      Cr-Commit-Position: refs/heads/master@{#39052}
      7516fe1e
  27. 29 Aug, 2016 1 commit
  28. 04 Aug, 2016 1 commit