Skip to content

V
V8
Switch branch/tag
  1. 19 Jan, 2017 3 commits
  3. 12 Jan, 2017 3 commits
  5. 22 Dec, 2016 1 commit
  7. 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
  9. 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
  11. 08 Dec, 2016 3 commits
  13. 07 Dec, 2016 1 commit
  15. 25 Oct, 2016 3 commits
  17. 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
  19. 16 Sep, 2016 1 commit
  21. 12 Sep, 2016 4 commits
  23. 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
  25. 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
  29. 01 Sep, 2016 1 commit
  31. 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
  33. 29 Aug, 2016 1 commit
  35. 04 Aug, 2016 1 commit
  37. 02 Aug, 2016 2 commits
  39. 01 Aug, 2016 1 commit
  41. 18 Jul, 2016 1 commit
    • neis's avatar
      [modules] AST and parser rework. · 0e000a87
      neis authored 
      Highlights:
- Record all imports and exports in the ModuleDescriptor.
- Remove ImportDeclaration; instead, introduce a new variable kind for imports.
- Set name on default exported anonymous functions.

Still to do: declaration of namespace imports.

BUG=v8:1569

Review-Url: https://codereview.chromium.org/2108193003
Cr-Commit-Position: refs/heads/master@{#37815}
      0e000a87
  43. 06 Jun, 2016 1 commit
  45. 12 May, 2016 1 commit
  47. 19 Apr, 2016 1 commit
    • adamk's avatar
      Remove all non-function-name uses of CONST_LEGACY · 59546149
      adamk authored 
      Now that all 'const' declarations are of the ES2015 variety, the only
use of CONST_LEGACY is for function name bindings in sloppy mode
named function expressions.

This patch aims to delete all code meant to handle other cases, which
mostly had to do with hole initialization/hole checks. Since function
name bindings are initialized at entry to a function, it's impossible
to ever observe one in an uninitialized state.

To simplify the patch further, it removes the `IMPORT` VariableMode,
as it's not likely to be needed (IMPORT is identical to CONST for
the purpose of VariableMode).

Review URL: https://codereview.chromium.org/1895973002

Cr-Commit-Position: refs/heads/master@{#35632}
      59546149
  49. 31 Mar, 2016 1 commit
  51. 08 Mar, 2016 1 commit
  53. 07 Mar, 2016 1 commit
  55. 01 Feb, 2016 1 commit
    • yangguo's avatar
      [debugger] correctly find function context. · 835b0383
      yangguo authored 
      In the debugger we are interested in getting the context for the
current frame, which is usually a function context. To do that,
we used to call Context::declaration_context, which may also
return a block context. This is wrong and can lead to crashes.
Instead, we now use a newly introduced Context::closure_context,
which skips block contexts. This works fine for the debugger,
since we have other means to find and materialize block contexts.

R=rossberg@chromium.org
BUG=chromium:582051
LOG=N

Review URL: https://codereview.chromium.org/1648263002

Cr-Commit-Position: refs/heads/master@{#33627}
      835b0383