1. 16 Oct, 2017 1 commit
  2. 05 Sep, 2017 1 commit
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · f0acede9
      Juliana Franco authored
      This CL removes the weak-list of JS functions from the context
      and all the code that iterares over it. This list was being used
      mainly during deoptimization (for code unlinking) and during
      garbage collection. Removing it will improve performance of
      programs that create many closures and trigger many scavenge GC
      cycles.
      
      No extra work is required during garbage collection. However,
      given that we no longer unlink code from JS functions during
      deoptimization, we leave it as it is, and on its next activation
      we check whether the mark_for_deoptimization bit of that code is
      set, and if it is, than we unlink it and jump to lazy compiled
      code. This check happens in the prologue of every code object.
       
      We needed to change/remove the cctests that used to check
      something on this list.
       
      Working in x64, ia32, arm64, arm, mips64 and mips. 
       
      
      Bug: v8:6637
      Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24
      TBR: mstarzinger@chromium.org
      Reviewed-on: https://chromium-review.googlesource.com/647596
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47808}
      f0acede9
  3. 04 Sep, 2017 2 commits
    • Michael Achenbach's avatar
      Revert "Remove weak-list of optimized JS functions." · 36b50283
      Michael Achenbach authored
      This reverts commit 84c2dfce.
      
      Reason for revert:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876
      
      Original change's description:
      > Remove weak-list of optimized JS functions.
      > 
      > This CL removes the weak-list of JS functions from the context
      > and all the code that iterares over it. This list was being used
      > mainly during deoptimization (for code unlinking) and during
      > garbage collection. Removing it will improve performance of
      > programs that create many closures and trigger many scavenge GC
      > cycles.
      > 
      > No extra work is required during garbage collection. However,
      > given that we no longer unlink code from JS functions during
      > deoptimization, we leave it as it is, and on its next activation
      > we check whether the mark_for_deoptimization bit of that code is
      > set, and if it is, than we unlink it and jump to lazy compiled
      > code. This check happens in the prologue of every code object.
      > 
      > We needed to change/remove the cctests that used to check
      > something on this list.
      > 
      > Working in x64, ia32, arm64, arm, mips64 and mips. 
      > 
      > Bug: v8:6637
      > Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
      > Reviewed-on: https://chromium-review.googlesource.com/600427
      > Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47790}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
      
      Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6637
      Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47792}
      36b50283
    • Juliana Franco's avatar
      Remove weak-list of optimized JS functions. · 84c2dfce
      Juliana Franco authored
      This CL removes the weak-list of JS functions from the context
      and all the code that iterares over it. This list was being used
      mainly during deoptimization (for code unlinking) and during
      garbage collection. Removing it will improve performance of
      programs that create many closures and trigger many scavenge GC
      cycles.
      
      No extra work is required during garbage collection. However,
      given that we no longer unlink code from JS functions during
      deoptimization, we leave it as it is, and on its next activation
      we check whether the mark_for_deoptimization bit of that code is
      set, and if it is, than we unlink it and jump to lazy compiled
      code. This check happens in the prologue of every code object.
      
      We needed to change/remove the cctests that used to check
      something on this list.
      
      Working in x64, ia32, arm64, arm, mips64 and mips. 
      
      Bug: v8:6637
      Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
      Reviewed-on: https://chromium-review.googlesource.com/600427
      Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47790}
      84c2dfce
  4. 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
  5. 29 Jun, 2017 1 commit
  6. 14 Jun, 2017 1 commit
  7. 22 May, 2017 1 commit
  8. 10 May, 2017 1 commit
  9. 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
  10. 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
  11. 02 May, 2017 2 commits
  12. 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
  13. 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
  14. 19 Jan, 2017 3 commits
  15. 12 Jan, 2017 3 commits
  16. 22 Dec, 2016 1 commit
  17. 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
  18. 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
  19. 08 Dec, 2016 3 commits
  20. 07 Dec, 2016 1 commit
  21. 25 Oct, 2016 3 commits
  22. 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
  23. 16 Sep, 2016 1 commit
  24. 12 Sep, 2016 4 commits
  25. 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
  26. 06 Sep, 2016 1 commit
  27. 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