Skip to content

V
V8
Switch branch/tag
  1. 13 Jul, 2017 1 commit
  3. 11 Jul, 2017 1 commit
  5. 10 Jul, 2017 2 commits
    • Benedikt Meurer's avatar
      [builtins] Port Map and Set iterators to CodeStubAssembler. · 3b84cbfe
      Benedikt Meurer authored 
      This is the next step towards faster Map and Set iteration. It
introduces the appropriate instance types for Map and Set
iterators (following the pattern for Array iterators) and migrates
the following builtins to the CodeStubAssembler:

  - Set.prototype.entries
  - Set.prototype.values
  - Map.prototype.entries
  - Map.prototype.keys
  - Map.prototype.values
  - %SetIteratorPrototype%.next
  - %MapIteratorPrototype%.next

This already provides a significant performance boost for regular
for-of iteration of Sets and Maps, by a factor of 5-10 depending
on the input. The final step will be to inline some fast-paths
into TurboFan.

Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
intrinsics and runtime functions.

TBR=jgruber@chromium.org

Bug: v8:6344, v8:6571, chromium:740122
Change-Id: I3ab0ee49e2afe8d4295707a5ecbd51adda621918
Reviewed-on: https://chromium-review.googlesource.com/563626
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46497}
      3b84cbfe
    • Michael Achenbach's avatar
      Revert "[builtins] Port Map and Set iterators to CodeStubAssembler." · 5a6e24e9
      Michael Achenbach authored 
      This reverts commit 3f22832b.

Reason for revert: Layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16849

Original change's description:
> [builtins] Port Map and Set iterators to CodeStubAssembler.
> 
> This is the next step towards faster Map and Set iteration. It
> introduces the appropriate instance types for Map and Set
> iterators (following the pattern for Array iterators) and migrates
> the following builtins to the CodeStubAssembler:
> 
>   - Set.prototype.entries
>   - Set.prototype.values
>   - Map.prototype.entries
>   - Map.prototype.keys
>   - Map.prototype.values
>   - %SetIteratorPrototype%.next
>   - %MapIteratorPrototype%.next
> 
> This already provides a significant performance boost for regular
> for-of iteration of Sets and Maps, by a factor of 5-10 depending
> on the input. The final step will be to inline some fast-paths
> into TurboFan.
> 
> Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
> intrinsics and runtime functions.
> 
> Bug: v8:6571, chromium:740122
> Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
> Reviewed-on: https://chromium-review.googlesource.com/563399
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46492}

TBR=jgruber@chromium.org,bmeurer@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:6571, chromium:740122
Change-Id: Iadb48d72e3b85ec8ad880e50ab7912c5502caf07
Reviewed-on: https://chromium-review.googlesource.com/564419Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46495}
      5a6e24e9
  7. 08 Jul, 2017 1 commit
    • Benedikt Meurer's avatar
      [builtins] Port Map and Set iterators to CodeStubAssembler. · 3f22832b
      Benedikt Meurer authored 
      This is the next step towards faster Map and Set iteration. It
introduces the appropriate instance types for Map and Set
iterators (following the pattern for Array iterators) and migrates
the following builtins to the CodeStubAssembler:

  - Set.prototype.entries
  - Set.prototype.values
  - Map.prototype.entries
  - Map.prototype.keys
  - Map.prototype.values
  - %SetIteratorPrototype%.next
  - %MapIteratorPrototype%.next

This already provides a significant performance boost for regular
for-of iteration of Sets and Maps, by a factor of 5-10 depending
on the input. The final step will be to inline some fast-paths
into TurboFan.

Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
intrinsics and runtime functions.

Bug: v8:6571, chromium:740122
Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
Reviewed-on: https://chromium-review.googlesource.com/563399
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46492}
      3f22832b
  9. 07 Jul, 2017 1 commit
  11. 06 Jul, 2017 1 commit
  13. 03 Jul, 2017 1 commit
  15. 30 Jun, 2017 2 commits
    • Mathias Bynens's avatar
      [elements] Rename FAST elements kinds · 26c00f4a
      Mathias Bynens authored 
      The `FAST_` prefix doesn’t make much sense — they’re all just different cases
with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.

This patch renames the FAST elements kinds as follows:

- e.g. FAST_ELEMENTS => PACKED_ELEMENTS
- e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS

The following exceptions are left intact, for lack of a better name:

- FAST_SLOPPY_ARGUMENTS_ELEMENTS
- SLOW_SLOPPY_ARGUMENTS_ELEMENTS
- FAST_STRING_WRAPPER_ELEMENTS
- SLOW_STRING_WRAPPER_ELEMENTS

This makes it easier to reason about elements kinds, and less confusing to
explain how they’re used.

R=jkummerow@chromium.org, cbruni@chromium.org
BUG=v8:6548

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46361}
      26c00f4a
    • Marja Hölttä's avatar
      [parser] Skipping inner funcs: Associate data to SharedFunctionInfo, not Script. · 937b5011
      Marja Hölttä authored 
      This way, each lazy function needs to handle only the data relevant to
itself. This reduced data handling overheads.

Other changes:

1) Don't deserialize the data; once it's on the heap, it can stay there. Lazy
function compilation is only done in the main thread.

2) Separate ProducedPreParsedScopeData and ConsumedPreParsedScopeData. It's clearer, because:

- The data looks fundamentally different when we're producing it and when we're
  consuming it.

- Cleanly separates the operations we can do in the "producing phase" and in the
  "consuming phase".

Bug: v8:5516
Change-Id: I6985a6621f71b348a55155724765624b5d5f7c33
Reviewed-on: https://chromium-review.googlesource.com/528094
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46347}
      937b5011
  17. 29 Jun, 2017 1 commit
  19. 27 Jun, 2017 1 commit
  21. 20 Jun, 2017 1 commit
  23. 14 Jun, 2017 1 commit
  25. 13 Jun, 2017 1 commit
  27. 12 Jun, 2017 1 commit
  29. 06 Jun, 2017 2 commits
    • Igor Sheludko's avatar
      [parser] Introduce SharedFunctionInfo::has_shared_name(). · 9a2c18f5
      Igor Sheludko authored 
      Properly propagate the fact that the function has a statically known name from
parser to SharedFunctionInfo objects. The empty string that has been set as
name before this CL does not help to distinguish cases like:
  var o1 = { ''(){} };
  var o1 = { [foo()](){} };
or
  var o2 = { get ''(){} };
  var o2 = { get [foo()](){} };

This is a preliminary step for using different layouts for closure objects with
and without computed names.

TBR=bmeurer@chromium.org, marja@chromium.org

Bug: v8:6459
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d
Reviewed-on: https://chromium-review.googlesource.com/522073
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45744}
      9a2c18f5
    • jgruber's avatar
      [coverage] Block coverage with support for IfStatements · b4241540
      jgruber authored 
      This CL implements general infrastructure for block coverage together with
initial support for if-statements.

Coverage output can be generated in lcov format by d8 as follows:

$ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js
$ genhtml ~/simple-if.lcov -o ~/simple-if
$ chrome ~/simple-if/index.html

A high level overview of the implementation follows:

The parser now collects source ranges unconditionally for relevant AST nodes.
Memory overhead is very low and this seemed like the cleanest and simplest
alternative.

Bytecode generation uses these ranges to allocate coverage slots and insert
IncBlockCounter instructions (e.g. at the beginning of then- and else blocks
for if-statements). The slot-range mapping is generated here and passed on
through CompilationInfo, and is later accessible through the
SharedFunctionInfo.

The IncBlockCounter bytecode fetches the slot-range mapping (called
CoverageInfo) from the shared function info and simply increments the counter.
We don't collect native-context-specific counts as they are irrelevant to our
use-cases.

Coverage information is finally generated on-demand through Coverage::Collect.
The only current consumer is a d8 front-end with lcov-style output, but the
short-term goal is to expose this through the inspector protocol.

BUG=v8:6000
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng

Review-Url: https://codereview.chromium.org/2882973002
Cr-Commit-Position: refs/heads/master@{#45737}
      b4241540
  31. 29 May, 2017 1 commit
  33. 23 May, 2017 3 commits
  35. 28 Apr, 2017 1 commit
  37. 27 Apr, 2017 1 commit
    • cbruni's avatar
      [runtime] Ensure slow properties for simple {__proto__:null} literals. · 3f73fecb
      cbruni authored 
      With this CL we reduce the difference between directly using a null prototype
in a literal or using Object.create(null).
- The EmitFastCloneShallowObject builtin now supports cloning slow
  object boilerplates.
- Unified behavior to find the matching Map and instantiating it for
  Object.create(null) and literals with a null prototype.
- Cleanup of literal type parameter of CompileTimeValue, now in sync with
  ObjectLiteral flags.

Review-Url: https://codereview.chromium.org/2445333002
Cr-Commit-Position: refs/heads/master@{#44941}
      3f73fecb
  39. 18 Apr, 2017 1 commit
  41. 12 Apr, 2017 1 commit
  43. 11 Apr, 2017 1 commit
    • gsathya's avatar
      [ESNext] Implement DynamicImportCall · 94283dcf
      gsathya authored 
      This patch implements the runtime semantics of dynamic import.

We create a new ASTNode so that we can pass the JSFunction closure() to
the runtime function from which we get the script_url.

d8 implements the embedder logic required to load and evaluate the modules.

The API is mostly implemented as specified.

BUG=8:5785

Review-Url: https://codereview.chromium.org/2703563002
Cr-Commit-Position: refs/heads/master@{#44551}
      94283dcf
  45. 03 Apr, 2017 1 commit
  47. 24 Mar, 2017 1 commit
  49. 17 Mar, 2017 1 commit
  51. 09 Mar, 2017 1 commit
  53. 02 Mar, 2017 1 commit
  55. 01 Mar, 2017 2 commits
    • Peter Marshall's avatar
      Revert "[builtins] Port TypedArrayInitialize to CodeStubAssembler." · a8e15e8f
      Peter Marshall authored 
      This reverts commit b23b2c10.

Reason for revert: Makes Linux debug bot sad

Original change's description:
> [builtins] Port TypedArrayInitialize to CodeStubAssembler.
> 
> Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
> because we always go to the C++ builtin. Port the builtin to CSA
> to improve performance, and to clean up the implementation, which is
> split across multiple files and pieces at the moment.
> 
> This CL increases the performance with --future to roughly the same
> as with crankshaft.
> 
> BUG=v8:5977
> 
> Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
> Reviewed-on: https://chromium-review.googlesource.com/445717
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43518}

TBR=cbruni@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5977

Change-Id: I5d5bc8b4677a405c716d78e688af80ae9c737b4a
Reviewed-on: https://chromium-review.googlesource.com/448558Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43520}
      a8e15e8f
    • Peter Marshall's avatar
      [builtins] Port TypedArrayInitialize to CodeStubAssembler. · b23b2c10
      Peter Marshall authored 
      Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
because we always go to the C++ builtin. Port the builtin to CSA
to improve performance, and to clean up the implementation, which is
split across multiple files and pieces at the moment.

This CL increases the performance with --future to roughly the same
as with crankshaft.

BUG=v8:5977

Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
Reviewed-on: https://chromium-review.googlesource.com/445717
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43518}
      b23b2c10
  57. 24 Feb, 2017 1 commit
  59. 17 Feb, 2017 1 commit
  61. 16 Feb, 2017 1 commit
  63. 14 Feb, 2017 1 commit
  65. 13 Feb, 2017 2 commits