Skip to content

V
V8
Switch branch/tag
  1. 24 Jul, 2017 2 commits
  3. 20 Jul, 2017 1 commit
  5. 19 Jul, 2017 1 commit
  7. 17 Jul, 2017 1 commit
  9. 13 Jul, 2017 1 commit
  11. 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
  13. 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
  15. 07 Jul, 2017 2 commits
  17. 05 Jul, 2017 1 commit
  19. 30 Jun, 2017 1 commit
    • 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
  21. 29 Jun, 2017 1 commit
  23. 22 Jun, 2017 2 commits
  25. 19 Jun, 2017 1 commit
  27. 14 Jun, 2017 2 commits
  29. 13 Jun, 2017 1 commit
  31. 12 Jun, 2017 1 commit
  33. 15 May, 2017 2 commits
    • Clemens Hammacher's avatar
      Revert "[builtins] port Promise.all to CSA" · ae421616
      Clemens Hammacher authored 
      This reverts commit 7ef1df85.

Reason for revert: Breaks inspector/debugger/get-possible-breakpoints-restrict-to-function: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/13191/steps/Check/logs/get-possible-breakpoi..

Original change's description:
> [builtins] port Promise.all to CSA
> 
> Introduces CodeStubAssembler helpers for common Iterator operations
> (GetIterator, IteratorStep, IteratorClose).
> 
> Moves the Promise.all resolveElement closure and it's caller to
> builtins-promise-gen.cc.
> 
> Instead of creating an internal array (and copying its elements into a result
> array), a single JSArray is allocated, and appended with BuildAppendJSArray(),
> falling back to %CreateDataProperty(), and elements are updated in the resolve
> closure the same way. This should always be unobservable.
> 
> This CL increases the size of snapshot_blob.bin on an x64.debug build by 11.44kb
> 
> BUG=v8:5343
> R=​cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org
> 
> Change-Id: Id69b7f76866b29caccd97f35870154c4be85f418
> Reviewed-on: https://chromium-review.googlesource.com/497974
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45306}

TBR=adamk@chromium.org,cbruni@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,ishell@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5343

Change-Id: I831738003643561fa628266af2bcebbb18000e55
Reviewed-on: https://chromium-review.googlesource.com/506014Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45313}
      ae421616
    • Caitlin Potter's avatar
      [builtins] port Promise.all to CSA · 7ef1df85
      Caitlin Potter authored 
      Introduces CodeStubAssembler helpers for common Iterator operations
(GetIterator, IteratorStep, IteratorClose).

Moves the Promise.all resolveElement closure and it's caller to
builtins-promise-gen.cc.

Instead of creating an internal array (and copying its elements into a result
array), a single JSArray is allocated, and appended with BuildAppendJSArray(),
falling back to %CreateDataProperty(), and elements are updated in the resolve
closure the same way. This should always be unobservable.

This CL increases the size of snapshot_blob.bin on an x64.debug build by 11.44kb

BUG=v8:5343
R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org

Change-Id: Id69b7f76866b29caccd97f35870154c4be85f418
Reviewed-on: https://chromium-review.googlesource.com/497974
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45306}
      7ef1df85
  35. 10 May, 2017 1 commit
  37. 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
  39. 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
  41. 02 May, 2017 2 commits
  43. 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
  45. 25 Apr, 2017 1 commit
    • Peter Marshall's avatar
      [builtins] Cleanup TypedArray constructors and reduce code size. · c326e73d
      Peter Marshall authored 
      This CL is purely refactoring, no behavior changes.

Remove InitializeBasedOnLength and combine it with a new Stub-ified
TypedArrayInitialize which now allocates the buffer in both the
on-heap and off-heap cases.

Add TypedArrayInitializeWithBuffer because this was essentially a
special case that didn't share much logic with Initialize.
Factor out the common pieces into SetupTypedArray and AttachBuffer.

We can also always pass in the elementsSize, so there is no need
to calculate this again. LoadMapAndElementsSize is changed to 
LoadMapForType.

This reduces code size by ~8k.

Bug: chromium:711275,chromium:701768
Change-Id: I6ad8701e9c72f53bfd9484725fb82055be568c25
Reviewed-on: https://chromium-review.googlesource.com/483481
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44850}
      c326e73d
  47. 24 Apr, 2017 1 commit
  49. 19 Apr, 2017 1 commit
    • Peter Marshall's avatar
      [builtins] Use the ElementsAccessor to copy TypedArrays. · 356e9246
      Peter Marshall authored 
      This includes a fastpath in the ElementsAccessor for the source
array being a JSArray with FastSmi or FastDouble packed kinds. This
is probably a pretty common usage, where an array is passed in as
a way of initializing the TypedArray at creation (as there is not other
syntax to do this). e.g. new Float64Array([1.0, 1.0, 1.0]) for some
sort of vector application.

BUG= v8:5977

Change-Id: Ice4ad9fc29f56b1c4b0b30736a1330efdc289003
Reviewed-on: https://chromium-review.googlesource.com/465126Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44722}
      356e9246
  51. 13 Apr, 2017 1 commit
  53. 12 Apr, 2017 2 commits
  55. 10 Apr, 2017 1 commit
    • Peter Marshall's avatar
      [runtime] Fix spec bug in TypedArrayConstruct with mutating iterables. · cc75535d
      Peter Marshall authored 
      The spec requires that we use IterableToList, which we skipped for
some arrays as an optimization. We can't skip this for arrays with
objects though, because the objects may mutate the array during
the copying step via valueOf side effects.

Also clean up the implementation to use a runtime function rather
than a builtin as the helper. Also reverses the result of the helper
because I think it is a bit more intuitive that way.

Bug: v8:6224
Change-Id: I9199491abede4479785df6d9068331bc2d6e9c5e
Reviewed-on: https://chromium-review.googlesource.com/471986Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44507}
      cc75535d
  57. 06 Apr, 2017 1 commit
    • Peter Marshall's avatar
      [builtins] Don't clear buffer memory that will be overwritten. · e28f7fc9
      Peter Marshall authored 
      Currently we initialize the allocated buffer to be full of 0s, which
adds significant overhead.

TypedArrayConstructByArrayLike will always either fully initialize the
buffer, or throw an exception, in which case the buffer will not be
leaked to user code.

The length of the new TypedArray (and thus the buffer) is derived from
the length of the source Array/TypedArray, so we know that we will
always set every byte of the new buffer, or throw trying.

Bug:v8:5977

Change-Id: I8ceaa883cfad85f8708a5bdaada3ce463d97e007
Reviewed-on: https://chromium-review.googlesource.com/469348Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44447}
      e28f7fc9
  59. 31 Mar, 2017 2 commits
    • Peter Marshall's avatar
      [builtins] Skip iteration when constructing TypedArrays if possible. · 143dcc6c
      Peter Marshall authored 
      This CL uses the same logic as spread calls to check whether the
iteration over an array would produce different results to simply
accessing the backing store directly. Skipping the full iteration
protocol for normal arrays gives us a ~10x speedup on the
construct-typedarray benchmark.

BUG=v8:5977,v8:5699,v8:4782,chromium:698173

Change-Id: Ib878d39691e99b739afef0dd05a6a6efc5b6b5d4
Reviewed-on: https://chromium-review.googlesource.com/463367Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44304}
      143dcc6c
    • Peter Marshall's avatar
      [builtins] Copy array contents using JS in ConstructByArrayLike. · a450c185
      Peter Marshall authored 
      The last CL https://chromium-review.googlesource.com/c/456707/ caused
some pretty heavy performance regressions. After experimenting, it
seems the easiest and most straight-forward way to copy the elements
into the new typed array is to do it in JS.

Adds a fast path for typed arrays, where the source typed array has
the same elements kind, in which case we can just copy the backing
store using memcpy.

This CL also removes regression test 319120 which is from a pwn2own
vulnerability. The old code path enforced a maximum byte_length
that was too low, which this change removes. The length property of
the typed array must be a Smi, but the byte_length, which can be up
to 8x larger than length for a Float64Array, can be a heap number.

We can also re-use some of the logic from ConstructByLength when
deciding whether to allocate the buffer on- or off-heap, so that
is factored out into InitializeBasedOnLength. We can also re-use
the DoInitialize helper instead of calling into the runtime,
meaning we can remove InitializeFromArrayLike.

BUG=v8:5977,chromium:705503,chromium:705394

Change-Id: I63372652091d4bdf3a9491acef9b4e3ac793a755
Reviewed-on: https://chromium-review.googlesource.com/459621Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44301}
      a450c185
  61. 29 Mar, 2017 1 commit
    • Caitlin Potter's avatar
      [async-iteration] implement AsyncGenerator · bf463c4d
      Caitlin Potter authored 
      - Introduce new struct AsyncGeneratorRequest, which holds
  information pertinent to resuming execution of an
  AsyncGenerator, such as the Promise associated with the async
  generator request. It is intended to be used as a singly
  linked list, and holds a pointer to the next item in te queue.

- Introduce JSAsyncGeneratorObject (subclass of
  JSGeneratorObject), which includes several new internal fields
  (`queue` which contains a singly linked list of
  AsyncGeneratorRequest objects, and `await_input` which
  contains the sent value from an Await expression (This is
  necessary to prevent function.sent (used by yield*) from
  having the sent value observably overwritten during
  execution).

- Modify SuspendGenerator to accept a set of Flags, which
  indicate whether the suspend is for a Yield or Await, and
  whether it takes place on an async generator or ES6
  generator.

- Introduce interpreter intrinsics and TF intrinsic lowering for
  accessing the await input of an async generator

- Modify the JSGeneratorStore operator to understand whether or
  not it's suspending for a normal yield, or an AsyncGenerator
  Await. This ensures appropriate registers are stored.

- Add versions of ResumeGeneratorTrampoline which store the
  input value in a different field depending on wether it's an
  AsyncGenerator Await resume, or an ordinary resume. Also modifies
  whether debug code will assert that the generator object is a
  JSGeneratorObject or a JSAsyncGeneratorObject depending on the
  resume type.

BUG=v8:5855
R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org,
littledan@chromium.org, neis@chromium.org
TBR=marja@chromium.org

Change-Id: I9d58df1d344465fc937fe7eed322424204497187
Reviewed-on: https://chromium-review.googlesource.com/446961
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44240}
      bf463c4d