Skip to content

V
V8
Switch branch/tag
  1. 24 Mar, 2017 2 commits
  3. 22 Mar, 2017 1 commit
  5. 21 Mar, 2017 1 commit
  7. 14 Mar, 2017 1 commit
  9. 21 Feb, 2017 1 commit
  11. 17 Feb, 2017 1 commit
  13. 14 Feb, 2017 1 commit
  15. 13 Feb, 2017 5 commits
  17. 07 Feb, 2017 3 commits
  19. 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
  21. 02 Feb, 2017 2 commits
  23. 30 Jan, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [TypeFeedbackVector] Combine the literals array and the feedback vector. · 626b95e3
      bjaideep authored 
      Port 93f05b64

Original Commit Message:

    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.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:5456
LOG=N

Review-Url: https://codereview.chromium.org/2659413002
Cr-Commit-Position: refs/heads/master@{#42778}
      626b95e3
  25. 27 Jan, 2017 1 commit
  27. 26 Jan, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [TypeFeedbackVector] DeclareGlobals needs a literals array · 84274800
      bjaideep authored 
      Port d287c819

Original Commit Message:

    [RELAND with one change: until literal arrays are rooted in the outer
    feedback vector (coming in the next days), the runtime-scope.cc change
    is held off.]

    When a function is declared in global scope, the closure is created
    by the DeclareGlobals runtime service. It needs a pointer to the
    literals array, already allocated in the feedback vector. This
    fixes a bug where it's behavior wasn't in sync with CreateClosure,
    which accepts the literals from the vector.

    This enables a follow-on performance improvement in the CompileLazy
    builtin.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=680637
LOG=N

Review-Url: https://codereview.chromium.org/2658053002
Cr-Commit-Position: refs/heads/master@{#42705}
      84274800
  29. 18 Jan, 2017 2 commits
    • ofrobots's avatar
      Revert remove dead hole check logic · 80234ee3
      ofrobots authored 
      This reverts commits
* 45c11887 "[fullcodegen] Remove dead hole check logic"
* 2aaf217b "[crankshaft] Remove dead Variable hole-checking code"
* f40a3817 "[crankshaft] Fix mips/mips64 build: remove unused variable"

BUG=
R=adamk@chromium.org,bmeurer@chromium.org,hablich@chromium.org

Review-Url: https://codereview.chromium.org/2640793004
Cr-Commit-Position: refs/heads/master@{#42476}
      80234ee3
    • mvstanton's avatar
      Back strongly rooted literals CLs out of the tree for branch cut · 80c9b69d
      mvstanton authored 
      Due to outstanding performance issues, it's safer to revert these
changes.

Revert "PPC/s390: [TypeFeedbackVector] DeclareGlobals needs a literals array"
Revert "[TypeFeedbackVector] DeclareGlobals needs a literals array"
Revert "PPC/s390: [builtins] CompileLazy bailed out to the runtime entirely too often."
Revert "[builtins] CompileLazy bailed out to the runtime entirely too often."

Another CL is to follow that removes the main part of this work
(after that revert, performance regressions should disappear.

TBR=mstarzinger@chromium.org, leszeks@chromium.org, bmeurer@chromium.org
BUG=680637

Review-Url: https://codereview.chromium.org/2645543002
Cr-Commit-Position: refs/heads/master@{#42456}
      80c9b69d
  31. 17 Jan, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [TypeFeedbackVector] DeclareGlobals needs a literals array · 6555a3c1
      bjaideep authored 
      Port b83c3d29

Original Commit Message:

    When a function is declared in global scope, the closure is created
    by the DeclareGlobals runtime service. It needs a pointer to the
    literals array, already allocated in the feedback vector. This
    fixes a bug where it's behavior wasn't in sync with CreateClosure,
    which accepts the literals from the vector.

    This enables a follow-on performance improvement in the CompileLazy
    builtin.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=680637
LOG=N

Review-Url: https://codereview.chromium.org/2634423002
Cr-Commit-Position: refs/heads/master@{#42421}
      6555a3c1
  33. 16 Jan, 2017 1 commit
  35. 11 Jan, 2017 1 commit
    • rmcilroy's avatar
      [compiler] Collect eager inner functions for compilation during renumbering. · a3052cfe
      rmcilroy authored 
      This CL modifies the ast-numbering phase to collect function literals which
should be compiled eagerly. This is then used to eagerly compile the inner
functions before compiling the outer function. This will be used to queue
compilation jobs on the CompilerDispatcher in a later CL.

This CL moves the compilation of eager inner functions out of the
GetSharedFunctionInfo function and instead compiles them explicitly. This
simplifies GetSharedFunctionInfo and also means there is no need to pass a
LazyCompilationMode to the function, so this concept has been removed.

BUG=v8:5203,v8:5215

Review-Url: https://codereview.chromium.org/2618553004
Cr-Commit-Position: refs/heads/master@{#42221}
      a3052cfe
  37. 09 Jan, 2017 2 commits
  39. 06 Jan, 2017 1 commit
  41. 05 Jan, 2017 1 commit
    • gsathya's avatar
      [ESnext] Implement Object spread · a40b7172
      gsathya authored 
      This patch adds parsing of spread object property.

-- Changes ParsePropertyName to parse Token::ELLIPSIS.
-- Throws if rest is encountered by setting a pattern error.
-- Adds a new PropertyKind enum (SPREAD)
-- Adds a new ObjectLiteralProperty::kind (SPREAD)
-- Adds a new harmony-object-spread flag and protects the parser code
with it.
-- Adds a new runtime function called CopyDataProperties
-- Does not add any support for this feature in fullcodegen.
-- Ignition calls out to a runtime function CopyDataProperties to
perform spread operation.
-- Move FastAssign from builtins-objects.cc to objects.cc
-- Refactor Builtin_ObjectAssign to use SetOrCopyDataProperties

Object rest will be implemented in a follow on patch.

BUG=v8:5549

Review-Url: https://codereview.chromium.org/2606833002
Cr-Commit-Position: refs/heads/master@{#42102}
      a40b7172
  43. 29 Dec, 2016 1 commit
  45. 22 Dec, 2016 1 commit
  47. 21 Dec, 2016 1 commit
  49. 20 Dec, 2016 2 commits
    • bjaideep's avatar
      PPC: Use a different map to distinguish eval contexts · cc48d2b1
      bjaideep authored 
      Port 53fdf9d1

Original Commit Message:

    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.

R=littledan@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:5295, chromium:648719
LOG=N

Review-Url: https://codereview.chromium.org/2590343002
Cr-Commit-Position: refs/heads/master@{#41872}
      cc48d2b1
    • 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
  51. 16 Dec, 2016 2 commits
  53. 05 Dec, 2016 1 commit
  55. 01 Dec, 2016 1 commit