1. 08 May, 2017 1 commit
  2. 05 May, 2017 1 commit
  3. 04 May, 2017 2 commits
  4. 26 Apr, 2017 1 commit
  5. 24 Apr, 2017 1 commit
  6. 20 Apr, 2017 1 commit
  7. 19 Apr, 2017 2 commits
  8. 18 Apr, 2017 3 commits
  9. 13 Apr, 2017 1 commit
  10. 12 Apr, 2017 4 commits
    • hablich's avatar
      Revert of [wasm] instantiate expressed in terms of compile (patchset #6... · d3f1d5c5
      hablich authored
      Revert of [wasm] instantiate expressed in terms of compile (patchset #6 id:140001 of https://codereview.chromium.org/2806073002/ )
      
      Reason for revert:
      Roll blocker: https://bugs.chromium.org/p/chromium/issues/detail?id=710824
      
      Original issue's description:
      > [wasm] instantiate expressed in terms of compile
      >
      > Today, the semantics of:
      >
      > WebAssembly.instantiate
      >
      > and
      >
      > WebAssembly.compile().then(new WebAssemblyInstance)
      >
      > are subtly different, to the point where attempting the proposed
      > change uncovered bugs.
      >
      > In the future, it's possible that .instantiate actually have different
      > semantics - if we pre-specialized to the provided ffi, for example.
      > Right now that's not the case.
      >
      > This CL:
      > - gets our implementation closer to what developers may write using
      > the compile -> new Instance alternative, in particular wrt promise
      > creation. By reusing code paths, we uncover more bugs, and keep
      > maintenance cost lower.
      >
      > - it gives us the response-based WebAssembly.instantiate implicitly.
      > Otherwise, we'd need that same implementation on the blink side. The
      > negative is maintenance: imagine if the bugs I mentioned could only be
      > found when running in Blink.
      >
      > BUG=chromium:697028
      >
      > Review-Url: https://codereview.chromium.org/2806073002
      > Cr-Commit-Position: refs/heads/master@{#44592}
      > Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb
      
      TBR=bradnelson@chromium.org,ahaas@chromium.org,adamk@chromium.org,mtrofin@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:697028
      
      Review-Url: https://codereview.chromium.org/2810203002
      Cr-Commit-Position: refs/heads/master@{#44614}
      d3f1d5c5
    • jgruber's avatar
      [string] Add a fast path to String.p.replace · f4ba786d
      jgruber authored
      This adds a fast path to skip runtime calls to GetSubstitution when
      the replacer string does not contain a '$' char.
      
      Extended background:
      
      String.prototype.replace is (roughly) structured as follows:
      
      * Check if {searchValue} has a @@replace Symbol, and delegate to that if
        so. We currently implement efficient fast paths when {searchValue} is
        a String or a fast RegExp.
      * A specialized fast path for single-char {searchValue}, "long" subject
        string, and String {replaceValue} that do not contain '$' chars (yes,
        this fast path is very specialized).
      * Check for the location of the first match using StringIndexOf, and
        exit early if no match is found.
      * Finally build the return value, which is 'prefix + replacement +
        suffix', where replacement is either the result of calling {replaceValue}
        (if it is callable), or GetSubstitution(ToString({replaceValue}))
        otherwise.
      
      There's several spots that could be improved.
      
      StringIndexOf currently calls into C++ runtime for all but the simple
      1-byte, 1-char {searchValue} case. We need to finally add support for
      remaining cases.
      
      The runtime call to GetSubstitution can be skipped if the replacer
      string does not contain any '$' syntax. This CL handles that case.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2813843002
      Cr-Commit-Position: refs/heads/master@{#44606}
      f4ba786d
    • Sathya Gunasekaran's avatar
      [builtins] Change semantics of class constructors returning primitives · a7c4e778
      Sathya Gunasekaran authored
      This change mirrors the semantics for derived class constructors. This
      change doesn't affect non class constructors.
      
      This change could potentially break web compat. More details:
      https://github.com/tc39/ecma262/pull/469
      
      Bug=v8:5536
      
      Change-Id: I519599949523733332d0b35e4f8d9ecb01cac495
      Reviewed-on: https://chromium-review.googlesource.com/461225Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44594}
      a7c4e778
    • mtrofin's avatar
      [wasm] instantiate expressed in terms of compile · 7829af32
      mtrofin authored
      Today, the semantics of:
      
      WebAssembly.instantiate
      
      and
      
      WebAssembly.compile().then(new WebAssemblyInstance)
      
      are subtly different, to the point where attempting the proposed
      change uncovered bugs.
      
      In the future, it's possible that .instantiate actually have different
      semantics - if we pre-specialized to the provided ffi, for example.
      Right now that's not the case.
      
      This CL:
      - gets our implementation closer to what developers may write using
      the compile -> new Instance alternative, in particular wrt promise
      creation. By reusing code paths, we uncover more bugs, and keep
      maintenance cost lower.
      
      - it gives us the response-based WebAssembly.instantiate implicitly.
      Otherwise, we'd need that same implementation on the blink side. The
      negative is maintenance: imagine if the bugs I mentioned could only be
      found when running in Blink.
      
      BUG=chromium:697028
      
      Review-Url: https://codereview.chromium.org/2806073002
      Cr-Commit-Position: refs/heads/master@{#44592}
      7829af32
  11. 11 Apr, 2017 3 commits
  12. 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
  13. 06 Apr, 2017 1 commit
  14. 04 Apr, 2017 3 commits
  15. 03 Apr, 2017 1 commit
  16. 31 Mar, 2017 2 commits
    • 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
    • Clemens Hammacher's avatar
      [wasm] Fix grow_memory implementation in interpreter · da778675
      Clemens Hammacher authored
      grow_memory was working from test cases, but not in combination with
      compiled code. This CL makes the effect of grow_memory executed either
      in the interpreter or compiled code always be reflected in both
      execution environments.
      It also adds a %RedirectToWasmInterpreter runtime function for testing
      this interaction.
      
      R=ahaas@chromium.org
      CC=gdeepti@chromium.org
      BUG=v8:5822
      
      Change-Id: I3e7c184c42ef655d1c30d2e0dddad7fb783455fc
      Reviewed-on: https://chromium-review.googlesource.com/463506
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44297}
      da778675
  17. 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
  18. 28 Mar, 2017 1 commit
  19. 27 Mar, 2017 4 commits
  20. 24 Mar, 2017 1 commit
  21. 23 Mar, 2017 1 commit
    • ahaas's avatar
      [wasm][arm] Add an additional stack check for functions with big frames. · 9f01d5c1
      ahaas authored
      Stack overflow checks are typically implemented as part of the TurboFan
      graph of a function. This means that the stack check code is executed
      after frame construction. When a frame is too big, though, there may not
      be enough space on the stack anymore to throw the stack overflow
      exception after frame construction. With this CL we do an additional
      stack check before frame construction for functions with big frames.
      
      As discussed offline with mstarzinger, I do this change currently only
      for WebAssembly.
      
      This CL contains only the changes for arm. I will do the other platforms
      in separate CLs.
      
      R=mstarzinger@chromium.org, v8-arm-ports@googlegroups.com
      
      Review-Url: https://codereview.chromium.org/2763593002
      Cr-Commit-Position: refs/heads/master@{#44065}
      9f01d5c1
  22. 22 Mar, 2017 3 commits
  23. 20 Mar, 2017 1 commit