1. 28 Jan, 2016 1 commit
  2. 22 Jan, 2016 1 commit
  3. 19 Jan, 2016 1 commit
  4. 27 Dec, 2015 2 commits
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · 97def807
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      Cr-Commit-Position: refs/heads/master@{#33042}
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33044}
      97def807
    • bmeurer's avatar
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound... · 1cf8b105
      bmeurer authored
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ )
      
      Reason for revert:
      Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
      
      Original issue's description:
      > [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
      >
      > According to the ES2015 specification, bound functions are exotic
      > objects, and thus don't need to be implemented as JSFunctions. So
      > we introduce a new JSBoundFunction type to represent bound functions
      > and make them optimizable. This already improves the performance of
      > calling or constructing bound functions by 10-100x depending on the
      > use case because we avoid the crazy dance between JavaScript and C++
      > that was implemented in v8natives.js previously.
      >
      > There's still room for improvement in the performance of actually
      > creating bound functions, which is also relevant in practice, but
      > we already have a plan how to accomplish that later.
      >
      > The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      >
      > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      > BUG=chromium:535408, chromium:571299, v8:4629
      > LOG=n
      >
      > Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      > Cr-Commit-Position: refs/heads/master@{#33042}
      
      TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:535408, chromium:571299, v8:4629
      
      Review URL: https://codereview.chromium.org/1552473002
      
      Cr-Commit-Position: refs/heads/master@{#33043}
      1cf8b105
  5. 26 Dec, 2015 1 commit
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · ca8623ea
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33042}
      ca8623ea
  6. 23 Dec, 2015 1 commit
    • mvstanton's avatar
      Partial revert of rest parameter desugaring. · d3f074b2
      mvstanton authored
      We'll be able to optimize rest parameters in TurboFan similarly to the arguments array. This CL restores the previous behavior, and a follow-on will enable TurboFan optimization.
      
      (TBR for rossberg since we discussed the revert beforehand. The only changes are a few lines related to tests and rebasing.)
      
      TBR=rossberg@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1537683002
      
      Cr-Commit-Position: refs/heads/master@{#33024}
      d3f074b2
  7. 07 Dec, 2015 1 commit
  8. 04 Dec, 2015 1 commit
    • caitpotter88's avatar
      [es6] implement destructuring assignment · b634a61d
      caitpotter88 authored
      Attempt #<really big number>
      
      Parses, and lazily rewrites Destructuring Assignment expressions. The rewriting strategy involves inserting a placeholder RewritableAssignmentExpression into the AST, whose content expression can be completely rewritten at a later time.
      
      Lazy rewriting ensures that errors do not occur due to eagerly rewriting nodes which form part of a binding pattern, thus breaking the meaning of the pattern --- or by eagerly rewriting ambiguous constructs that are not immediately known
      
      BUG=v8:811
      LOG=Y
      R=adamk@chromium.org, bmeurer@chromium.org, rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1309813007
      
      Cr-Commit-Position: refs/heads/master@{#32623}
      b634a61d
  9. 01 Dec, 2015 1 commit
  10. 05 Nov, 2015 1 commit
  11. 21 Oct, 2015 1 commit
  12. 19 Oct, 2015 1 commit
  13. 07 Oct, 2015 1 commit
  14. 02 Oct, 2015 3 commits
    • rmcilroy's avatar
      [Interpreter] Add CallRuntime support to the interpreter. · 75f6ad74
      rmcilroy authored
      Adds support for calling runtime functions from the interpreter. Adds the
      CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      to enable the interpreter to enter C++ code based on the functionId.
      
      Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      and groups all the interpreter builtins together.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1362383002
      
      Cr-Commit-Position: refs/heads/master@{#31089}
      75f6ad74
    • rmcilroy's avatar
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset... · b4a2f656
      rmcilroy authored
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #8 id:220001 of https://codereview.chromium.org/1362383002/ )
      
      Reason for revert:
      Now breaking arm32 debug bot (worked locally even with --debug-code, so I'll need to figure out what's different on the bot)
      
      Original issue's description:
      > [Interpreter] Add CallRuntime support to the interpreter.
      >
      > Adds support for calling runtime functions from the interpreter. Adds the
      > CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      > and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      > to enable the interpreter to enter C++ code based on the functionId.
      >
      > Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      > and groups all the interpreter builtins together.
      >
      > BUG=v8:4280
      > LOG=N
      >
      
      TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4280
      
      Review URL: https://codereview.chromium.org/1379933003
      
      Cr-Commit-Position: refs/heads/master@{#31078}
      b4a2f656
    • rmcilroy's avatar
      [Interpreter] Add CallRuntime support to the interpreter. · c991d8f3
      rmcilroy authored
      Adds support for calling runtime functions from the interpreter. Adds the
      CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      to enable the interpreter to enter C++ code based on the functionId.
      
      Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      and groups all the interpreter builtins together.
      
      BUG=v8:4280
      LOG=N
      
      Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
      Cr-Commit-Position: refs/heads/master@{#31064}
      
      Review URL: https://codereview.chromium.org/1362383002
      
      Cr-Commit-Position: refs/heads/master@{#31076}
      c991d8f3
  15. 08 Sep, 2015 3 commits
    • bmeurer's avatar
      [builtins] Unify the various versions of [[Call]] with a Call builtin. · ccbb4ff0
      bmeurer authored
      The new Call and CallFunction builtins supersede the current
      CallFunctionStub (and CallIC magic) and will be the single bottleneck
      for all calling, including the currently special Function.prototype.call
      and Function.prototype.apply builtins, which had handwritten (and
      not fully compliant) versions of CallFunctionStub, and also the
      CallIC(s), which where also slightly different.
      
      This also reduces the overhead for API function calls, which is still
      unnecessary high, but let's do that step-by-step.
      
      This also fixes a bunch of cases where the implicit ToObject for
      sloppy receivers was done in the wrong context (in the caller
      context instead of the callee context), which basically meant
      that we allowed cross context access to %ObjectPrototype%.
      
      MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      
      R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
      BUG=v8:4413
      LOG=n
      
      Committed: https://crrev.com/ef268a83be4dead004047c25b702319ea4be7277
      Cr-Commit-Position: refs/heads/master@{#30627}
      
      Review URL: https://codereview.chromium.org/1311013008
      
      Cr-Commit-Position: refs/heads/master@{#30629}
      ccbb4ff0
    • bmeurer's avatar
      Revert of [builtins] Unify the various versions of [[Call]] with a Call... · 298d4a6b
      bmeurer authored
      Revert of [builtins] Unify the various versions of [[Call]] with a Call builtin. (patchset #10 id:260001 of https://codereview.chromium.org/1311013008/ )
      
      Reason for revert:
      Breaks nosnap, needs investigation
      
      Original issue's description:
      > [builtins] Unify the various versions of [[Call]] with a Call builtin.
      >
      > The new Call and CallFunction builtins supersede the current
      > CallFunctionStub (and CallIC magic) and will be the single bottleneck
      > for all calling, including the currently special Function.prototype.call
      > and Function.prototype.apply builtins, which had handwritten (and
      > not fully compliant) versions of CallFunctionStub, and also the
      > CallIC(s), which where also slightly different.
      >
      > This also reduces the overhead for API function calls, which is still
      > unnecessary high, but let's do that step-by-step.
      >
      > This also fixes a bunch of cases where the implicit ToObject for
      > sloppy receivers was done in the wrong context (in the caller
      > context instead of the callee context), which basically meant
      > that we allowed cross context access to %ObjectPrototype%.
      >
      > MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      >
      > R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
      > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg
      > BUG=v8:4413
      > LOG=n
      >
      > Committed: https://crrev.com/ef268a83be4dead004047c25b702319ea4be7277
      > Cr-Commit-Position: refs/heads/master@{#30627}
      
      TBR=rmcilroy@chromium.org,jarin@chromium.org,mstarzinger@chromium.org,mvstanton@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4413
      
      Review URL: https://codereview.chromium.org/1328963004
      
      Cr-Commit-Position: refs/heads/master@{#30628}
      298d4a6b
    • bmeurer's avatar
      [builtins] Unify the various versions of [[Call]] with a Call builtin. · ef268a83
      bmeurer authored
      The new Call and CallFunction builtins supersede the current
      CallFunctionStub (and CallIC magic) and will be the single bottleneck
      for all calling, including the currently special Function.prototype.call
      and Function.prototype.apply builtins, which had handwritten (and
      not fully compliant) versions of CallFunctionStub, and also the
      CallIC(s), which where also slightly different.
      
      This also reduces the overhead for API function calls, which is still
      unnecessary high, but let's do that step-by-step.
      
      This also fixes a bunch of cases where the implicit ToObject for
      sloppy receivers was done in the wrong context (in the caller
      context instead of the callee context), which basically meant
      that we allowed cross context access to %ObjectPrototype%.
      
      MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      
      R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg
      BUG=v8:4413
      LOG=n
      
      Review URL: https://codereview.chromium.org/1311013008
      
      Cr-Commit-Position: refs/heads/master@{#30627}
      ef268a83
  16. 02 Sep, 2015 1 commit
  17. 25 Aug, 2015 1 commit
    • bmeurer's avatar
      Correctify instanceof and make it optimizable. · 5d875a57
      bmeurer authored
      The previous hack with HInstanceOfKnownGlobal was not only slower,
      but also very brittle and required a lot of weird hacks to support it. And
      what's even more important it wasn't even correct (because a map check
      on the lhs is never enough for instanceof).
      
      The new implementation provides a sane runtime implementation
      for InstanceOf plus a fast case in the InstanceOfStub, combined with
      a proper specialization in the case of a known global in CrankShaft,
      which does only the prototype chain walk (coupled with a code
      dependency on the known global).
      
      As a drive-by-fix: Also fix the incorrect Object.prototype.isPrototypeOf
      implementation.
      
      BUG=v8:4376
      LOG=y
      
      Review URL: https://codereview.chromium.org/1304633002
      
      Cr-Commit-Position: refs/heads/master@{#30342}
      5d875a57
  18. 03 Aug, 2015 1 commit
    • yangguo's avatar
      Remove JSFunctionResultCache. · 4a2e4420
      yangguo authored
      There is only one use case for it: String.prototype.search converts a
      string argument into a RegExp. The cache is used to avoid repeating that
      conversion. However, this does not make the added complexity worthwhile.
      
      Review URL: https://codereview.chromium.org/1267493006
      
      Cr-Commit-Position: refs/heads/master@{#29985}
      4a2e4420
  19. 30 Jul, 2015 1 commit
  20. 20 Jul, 2015 1 commit
    • yangguo's avatar
      Debugger: prepare code for debugging on a per-function basis. · 35c28ce0
      yangguo authored
      Prior to this patch, we enter a global debug mode whenever a break point
      is set. By entering this mode, all code is deoptimized and activated
      frames are recompiled and redirected to newly compiled debug code.
      
      After this patch, we only deoptimize/redirect for functions we want to
      debug. Trigger for this is Debug::EnsureDebugInfo, and having DebugInfo
      object attached to the SFI prevents optimization/inlining.
      
      The result is that we can have optimized code for functions without break
      points alongside functions that do have break points, which are not
      optimized.
      
      R=mstarzinger@chromium.org, ulan@chromium.org
      BUG=v8:4132
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1233073005
      
      Cr-Commit-Position: refs/heads/master@{#29758}
      35c28ce0
  21. 13 Jul, 2015 2 commits
  22. 03 Jun, 2015 1 commit
    • bmeurer's avatar
      [date] Refactor the %_DateField intrinsic to be optimizable. · e4782a9b
      bmeurer authored
      Previously the %_DateField intrinsic would also check the object and
      throw an exception if you happen to pass something that is not a valid
      JSDate, which (a) violates our policy for instrinsics and (b) is hard to
      optimize in TurboFan (even Crankshaft has a hard time, but there we will
      never inline the relevant builtins, so it doesn't show up). The throwing
      part is now a separate intrinsics %_ThrowIfNotADate that throws an
      exception in full codegen and deoptimizes in Crankshaft, which means the
      code for the current use cases is roughly the same (modulo some register
      renamings/gap moves).
      
      R=jkummerow@chromium.org
      
      Review URL: https://codereview.chromium.org/1167813003
      
      Cr-Commit-Position: refs/heads/master@{#28782}
      e4782a9b
  23. 21 May, 2015 1 commit
    • arv's avatar
      [es6] Spread in array literals · 9502e91a
      arv authored
      This allows you to put iterables into your array literals
      and the will get spread into the array.
      
        let x = [0, ...range(1, 3)];  // [0, 1, 2]
      
      This is done by treating the array literal up to the first
      spread element as usual, including using a boiler plate
      array, and then appending the remaining expressions and rest
      expressions.
      
      BUG=v8:3018
      LOG=N
      
      Review URL: https://codereview.chromium.org/1125183008
      
      Cr-Commit-Position: refs/heads/master@{#28534}
      9502e91a
  24. 30 Apr, 2015 1 commit
  25. 27 Apr, 2015 1 commit
  26. 16 Apr, 2015 1 commit
  27. 15 Apr, 2015 1 commit
  28. 13 Apr, 2015 1 commit
  29. 07 Apr, 2015 1 commit
  30. 11 Mar, 2015 1 commit
  31. 10 Mar, 2015 1 commit
  32. 27 Feb, 2015 1 commit
  33. 14 Feb, 2015 1 commit
  34. 29 Jan, 2015 1 commit