Skip to content

V
V8
Switch branch/tag
  1. 29 Apr, 2016 2 commits
  3. 28 Apr, 2016 1 commit
  5. 25 Apr, 2016 2 commits
  7. 22 Apr, 2016 1 commit
  9. 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
  11. 05 Apr, 2016 1 commit
    • neis's avatar
      Fix treatment of rest pattern in array destructuring. · 4edf16dd
      neis authored 
      When seeing a rest pattern, we used to get the remaining elements from the
iterator by calling %concat_iterable_to_array on it.  This was wrong because it
caused an observable [[Get]] for @@iterator (which the iterator may not even
provide).

This CL gets rid of the call to %concat_iterable_to_array and does the iteration
manually in a simple while-loop.  It also gets rid of %concat_iterable_to_array
itself because there aren't any other uses of it.

BUG=v8:4759
LOG=n
R=adamk@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#35251}
      4edf16dd
  13. 31 Mar, 2016 1 commit
  15. 28 Mar, 2016 1 commit
    • bmeurer's avatar
      [builtins] Provide Math.floor as TurboFan builtin. · 36ead519
      bmeurer authored 
      This way we avoid the second deoptimization for the Math.floor and
Math.ceil builtins when -0 is involved. We still deoptimize the inlined
Crankshaft version in various cases, that's a separate issue.

The algorithm used for implement CodeStubAssembler::Float64Floor is
vaguely based on the fast math version used in the libm of various BSDs,
but had to be reengineered to match the EcmaScript specification.

R=epertoso@chromium.org
BUG=v8:2890, v8:4059
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#35083}
      36ead519
  17. 22 Mar, 2016 1 commit
    • bmeurer's avatar
      [builtins] Add support for JS builtins written in TurboFan. · 43fe7d68
      bmeurer authored 
      This CL adds support for builtins with JavaScript linkage written using
the TurboFan CodeStubAssembler, but with a JSCall descriptor (which was
already supported thanks to a previous patch by Ben Smith). As a first
example, we convert the Math.sqrt builtin and thereby get rid of the
%_MathSqrt intrinsic, which causes trouble for the representation
selection pass in the JavaScript pipeline.

R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34989}
      43fe7d68
  19. 18 Mar, 2016 1 commit
  21. 01 Mar, 2016 1 commit
  23. 26 Feb, 2016 1 commit
  25. 22 Feb, 2016 1 commit
    • littledan's avatar
      Remove the Proxy enumerate trap · 579c0107
      littledan authored 
      In ES2016, the Proxy enumerate trap is removed. This patch changes
for-in iteration on Proxies to use the ownKeys trap. Due to the clean
organization of that code, the patch basically consists of deletions.

R=adamk
LOG=Y
BUG=v8:4768

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

Cr-Commit-Position: refs/heads/master@{#34200}
      579c0107
  27. 19 Feb, 2016 1 commit
  29. 06 Feb, 2016 1 commit
    • ishell's avatar
      [api] Make ObjectTemplate::SetNativeDataProperty() work even if the... · da213b6e
      ishell authored 
      [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.

Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.

The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.

BUG=chromium:579009
LOG=Y

Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
Cr-Commit-Position: refs/heads/master@{#33674}

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

Cr-Commit-Position: refs/heads/master@{#33798}
      da213b6e
  31. 03 Feb, 2016 1 commit
    • hablich's avatar
      Revert of [api] Make ObjectTemplate::SetNativeDataProperty() work even if the... · db47a31f
      hablich authored 
      Revert of [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a … (patchset #3 id:80001 of https://codereview.chromium.org/1642223003/ )

Reason for revert:
Fails a lot of layout tests and blocks the roll. Can be easily reproduced with a local Chromium checkout.

Reference: https://codereview.chromium.org/1652413003/

Original issue's description:
> [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.
>
> Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
> When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
> ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.
>
> The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.
>
> This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks.
>
> BUG=chromium:579009
> LOG=Y
>
> Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
> Cr-Commit-Position: refs/heads/master@{#33674}

TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:579009

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

Cr-Commit-Position: refs/heads/master@{#33698}
      db47a31f
  33. 02 Feb, 2016 1 commit
    • ishell's avatar
      [api] Make ObjectTemplate::SetNativeDataProperty() work even if the... · 6a118774
      ishell authored 
      [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.

Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.

The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.

This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks.

BUG=chromium:579009
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#33674}
      6a118774
  35. 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
  37. 20 Jan, 2016 3 commits
  39. 19 Jan, 2016 1 commit
  41. 08 Jan, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Object.keys to C++. · 50e1e751
      bmeurer authored 
      Everything necessary to implement Object.keys efficiently is already
available in C++ land for quite some time now, and only the thin
JavaScript wrapper was left, so get rid of that as well and move the
whole builtin to C++ instead.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33167}
      50e1e751
  43. 05 Jan, 2016 1 commit
    • bmeurer's avatar
      [runtime] Migrate several Date builtins to C++. · 065e9c53
      bmeurer authored 
      Almost all of the Date builtins always call into C++ at least once
anyway, so parsing, compiling and executing the JavaScript wrappers
is just a waste of time.  The most important part here is the Date
constructor itself, which is one of the blockers for new.target in
TurboFan, because compiling the Date constructor takes too much time
with TurboFan (for no reason since we end up in C++ anway).

R=cbruni@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33109}
      065e9c53
  45. 04 Jan, 2016 1 commit
  47. 17 Dec, 2015 4 commits
  49. 14 Dec, 2015 1 commit
    • neis's avatar
      [proxies] Support proxies in JSON.parse and JSON.stringify. · 1596b015
      neis authored 
      This CL tries to correctly support the following:
- stringifying a proxy,
- stringifying with a proxy as replacer (callable or arraylike),
- stringifying with a replacer that returns a proxy,
- parsing with a callable proxy as reviver,
- parsing with a reviver that inserts proxies into the object,
- and whatever else you can imagine.

This also fixes some bugs observable without proxies.

BUG=v8:3139,v8:1543
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32843}
      1596b015
  51. 11 Dec, 2015 1 commit
    • bmeurer's avatar
      [contexts] Place the initial JSArray maps on the native context directly. · 5964152c
      bmeurer authored 
      No need to have an indirection to get to the initial JSArray maps from
the native context; we only cache the fast elements maps anyway, so
those could live on the native context directly. This will also
integrate nicely with the load/store propagation in TurboFan (once we
propagate the immutable flag for FieldAccess as well).

Drive-by-fix: Also don't embed any of the initial JSArray maps in
TurboFan generated code when allocating a new JSArray, but instead
always load the appropriate map from the native context.  This way
we ensure that we never leak a reference to one of those maps and
its as efficient as embedding a constant map.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32779}
      5964152c
  53. 10 Dec, 2015 1 commit
  55. 09 Dec, 2015 4 commits
  57. 08 Dec, 2015 1 commit
  59. 07 Dec, 2015 1 commit