1. 22 Jun, 2017 2 commits
  2. 19 Jun, 2017 1 commit
  3. 14 Jun, 2017 2 commits
  4. 13 Jun, 2017 1 commit
  5. 12 Jun, 2017 1 commit
  6. 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
  7. 10 May, 2017 1 commit
  8. 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
  9. 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
  10. 02 May, 2017 2 commits
  11. 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
  12. 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
  13. 24 Apr, 2017 1 commit
  14. 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
  15. 13 Apr, 2017 1 commit
  16. 12 Apr, 2017 2 commits
  17. 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
  18. 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
  19. 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
  20. 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
  21. 24 Mar, 2017 1 commit
  22. 22 Mar, 2017 1 commit
  23. 13 Mar, 2017 1 commit
  24. 07 Mar, 2017 1 commit
  25. 02 Mar, 2017 1 commit
  26. 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
  27. 24 Feb, 2017 1 commit
  28. 17 Feb, 2017 1 commit
  29. 15 Feb, 2017 2 commits
    • caitp's avatar
      [cleanup] NATIVE_CONTEXT_IMPORTED_FIELDS to NATIVE_CONTEXT_INTRINSIC_FUNCTIONS · c96a47de
      caitp authored
      Some of these functions are invoked by BytecodeGenerator due to parser
      desugarings, and moving the context indices cause
      BytecodeExpectationsPrinter to render them as something
      useful/meaningful.
      
      BUG=
      R=jgruber@chromium.org, adamk@chromium.org
      
      Review-Url: https://codereview.chromium.org/2695323002
      Cr-Commit-Position: refs/heads/master@{#43225}
      c96a47de
    • littledan's avatar
      [bootstrapper] Remove Intl experimental natives files · 407d6bf1
      littledan authored
      These experimental natives previously only installed functions to the
      appropriate parent. In this patch, the exports container is retained
      so that the bootstrapper may install the functions instead. This
      change is intended to reduce startup time. SharedArrayBuffer retains
      some experimental natives exported from JS; this may be addressed
      in a follow-on patch. The patch includes some minor cleanup of the
      bootstrap process by removing "experimental exports", which was unused.
      
      R=yangguo@chromium.org
      BUG=v8:5880
      CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng
      
      Review-Url: https://codereview.chromium.org/2683083003
      Cr-Commit-Position: refs/heads/master@{#43221}
      407d6bf1
  30. 14 Feb, 2017 1 commit
  31. 13 Feb, 2017 2 commits