1. 27 Jan, 2016 1 commit
    • mvstanton's avatar
      Reland of Type Feedback Vector lives in the closure · d984b3b0
      mvstanton authored
      (Fixed a bug found by nosnap builds.)
      
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      
      TBR=hpayer@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1642613002
      
      Cr-Commit-Position: refs/heads/master@{#33548}
      d984b3b0
  2. 26 Jan, 2016 4 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of... · e2e7dc32
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )
      
      Reason for revert:
      FAilure on win32 bot, need to investigate webkit failures.
      
      Original issue's description:
      > Type Feedback Vector lives in the closure
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      >
      > TBR=hpayer@chromium.org
      >
      > BUG=
      >
      > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
      > Cr-Commit-Position: refs/heads/master@{#33518}
      
      TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1632993003
      
      Cr-Commit-Position: refs/heads/master@{#33520}
      e2e7dc32
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · a5200f7e
      mvstanton authored
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      
      TBR=hpayer@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1563213002
      
      Cr-Commit-Position: refs/heads/master@{#33518}
      a5200f7e
    • rmcilroy's avatar
      [Interpreter] Fix deopting from inline functions. · 32eade63
      rmcilroy authored
      Rename IntepreterExceptionEntryHandler builtin to InterpreterEnterBytecodeDispatch
      and use it as the return address when building interpreter frames during deopt.
      This ensures that we restart execution of the outer frame at the correct
      bytecode.
      
      BUG=v8:4280,v8:4678
      LOG=N
      
      Review URL: https://codereview.chromium.org/1633633002
      
      Cr-Commit-Position: refs/heads/master@{#33512}
      32eade63
    • ishell's avatar
      [es6] Tail calls support. · 6131ab1e
      ishell authored
      This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
      When debugger is active tail calls are disabled.
      
      Tail calling can be enabled by --harmony-tailcalls flag.
      
      BUG=v8:4698
      LOG=Y
      TBR=rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1609893003
      
      Cr-Commit-Position: refs/heads/master@{#33509}
      6131ab1e
  3. 23 Jan, 2016 1 commit
  4. 22 Jan, 2016 1 commit
  5. 20 Jan, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] First implementation of stack unwinding. · 0b3066b8
      mstarzinger authored
      This implements a first prototype of stack unwinding for interpreted
      frames. The unwinding machinery performs a range-based lookup in the
      given handler table and potentially continues dispatching at the handler
      offset. Note that this does not yet correctly restore the context to the
      correct value when the handler is being entered.
      
      R=rmcilroy@chromium.org,oth@chromium.org
      BUG=v8:4674
      LOG=n
      
      Review URL: https://codereview.chromium.org/1605633003
      
      Cr-Commit-Position: refs/heads/master@{#33414}
      0b3066b8
  6. 15 Jan, 2016 1 commit
    • cbruni's avatar
      [runtime] Throw exception for derived constructors in correct context. · c86f1897
      cbruni authored
      When derived constructors return a non-object (or not undefined) we
      currently throw an exception directly in the callee context. This was
      achieved by desugaring the return statement for derived classes. To
      be spec compliamnt a separate ConstructStubForDerived is introduced.
      Instead of trowing directly, the desugared return statement inside
      a derived constructor only returns an integer to indicate an incompatible
      result.
      
      BUG=v8:4509
      LOG=n
      
      Review URL: https://codereview.chromium.org/1593553002
      
      Cr-Commit-Position: refs/heads/master@{#33336}
      c86f1897
  7. 14 Jan, 2016 2 commits
  8. 13 Jan, 2016 2 commits
  9. 08 Jan, 2016 1 commit
  10. 04 Jan, 2016 1 commit
  11. 30 Dec, 2015 1 commit
  12. 29 Dec, 2015 1 commit
  13. 28 Dec, 2015 1 commit
    • bmeurer's avatar
      [builtins] Fix context for ConstructStub calls into C++. · cf25c241
      bmeurer authored
      When calling into C++ for a ConstructStub, we need to enter the target
      context manually currently, which seems to be too fragile and easy to
      forget. So instead of doing that manually, we just always enter the
      correct context in the trampoline.
      
      Drive-by-fix: Trivial cleanups for some builtins.
      
      R=cbruni@chromium.org
      
      Review URL: https://codereview.chromium.org/1551473002
      
      Cr-Commit-Position: refs/heads/master@{#33051}
      cf25c241
  14. 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
  15. 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
  16. 22 Dec, 2015 1 commit
    • bmeurer's avatar
      [runtime] Rewrite Function.prototype.toString in C++. · 4acca53e
      bmeurer authored
      There's actually no point trying to do Function.prototype.toString in
      JavaScript, as it always calls into C++ at least once, so it only
      complicates things (esp. once we start optimizing bound functions).
      
      Drive-by-fix: Rename FunctionApply and FunctionCall builtins to also
      reflect the fact that these are builtins in the Function.prototype and
      not on Function itself.
      
      TBR=hpayer@chromium.org
      R=yangguo@chromium.org
      BUG=chromium:535408
      LOG=n
      
      Review URL: https://codereview.chromium.org/1540953004
      
      Cr-Commit-Position: refs/heads/master@{#32996}
      4acca53e
  17. 18 Dec, 2015 1 commit
    • rmcilroy's avatar
      [Interpreter] Add basic deoptimization support from TurboFan to Ignition. · b10d24ff
      rmcilroy authored
      Adds support for generating deoptimization translations for interpreter
      stack frames, and building interpreter frames for these translations
      when a function deopts. Also adds builtins for
      InterpreterNotifyDeoptimized which resume the function's continuation at
      the correct point in the interpreter after deopt.
      
      MIPS patch contributed by balazs.kilvady@igmtec.com
      
      BUG=v8:4280
      LOG=N
      TEST=test-deoptimization.cc with --ignition and --turbo
      
      Review URL: https://codereview.chromium.org/1528913003
      
      Cr-Commit-Position: refs/heads/master@{#32971}
      b10d24ff
  18. 17 Dec, 2015 3 commits
    • Benedikt Meurer's avatar
      [es6] Correct Function.prototype.apply, Reflect.construct and Reflect.apply. · 5bd48324
      Benedikt Meurer authored
      Introduce a new Apply builtin that forms a correct and optimizable
      foundation for the Function.prototype.apply, Reflect.construct and
      Reflect.apply builtins (which properly does the PrepareForTailCall
      as required by the ES2015 spec).
      
      The new Apply builtin avoids going to the runtime if it is safe to
      just access the backing store elements of the argArray, i.e. if you
      pass a JSArray with no holes, or an unmapped, unmodified sloppy or
      strict arguments object.
      
      mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com>
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
      BUG=v8:4413, v8:4430
      LOG=n
      R=yangguo@chromium.org
      
      Committed: https://chromium.googlesource.com/v8/v8/+/e4d2538911f6cb4b626830ccbb3c1f5746542697
      
      Review URL: https://codereview.chromium.org/1523753002 .
      
      Cr-Commit-Position: refs/heads/master@{#32929}
      5bd48324
    • Benedikt Meurer's avatar
      Revert of [es6] Correct Function.prototype.apply, Reflect.construct and... · 567c24d9
      Benedikt Meurer authored
      Revert of [es6] Correct Function.prototype.apply, Reflect.construct and Reflect.apply. (patchset #5 id:80001 of https://codereview.chromium.org/1523753002/ )
      
      Reason for revert:
      Breaks TSAN somewhow: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/7000
      
      Original issue's description:
      > [es6] Correct Function.prototype.apply, Reflect.construct and Reflect.apply.
      >
      > Introduce a new Apply builtin that forms a correct and optimizable
      > foundation for the Function.prototype.apply, Reflect.construct and
      > Reflect.apply builtins (which properly does the PrepareForTailCall
      > as required by the ES2015 spec).
      >
      > The new Apply builtin avoids going to the runtime if it is safe to
      > just access the backing store elements of the argArray, i.e. if you
      > pass a JSArray with no holes, or an unmapped, unmodified sloppy or
      > strict arguments object.
      >
      > mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com>
      >
      > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      > BUG=v8:4413, v8:4430
      > LOG=n
      > R=yangguo@chromium.org
      >
      > Committed: https://chromium.googlesource.com/v8/v8/+/e4d2538911f6cb4b626830ccbb3c1f5746542697
      
      TBR=yangguo@chromium.org,paul.lind@imgtec.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4413, v8:4430
      
      Review URL: https://codereview.chromium.org/1533803002 .
      
      Cr-Commit-Position: refs/heads/master@{#32928}
      567c24d9
    • Benedikt Meurer's avatar
      [es6] Correct Function.prototype.apply, Reflect.construct and Reflect.apply. · e4d25389
      Benedikt Meurer authored
      Introduce a new Apply builtin that forms a correct and optimizable
      foundation for the Function.prototype.apply, Reflect.construct and
      Reflect.apply builtins (which properly does the PrepareForTailCall
      as required by the ES2015 spec).
      
      The new Apply builtin avoids going to the runtime if it is safe to
      just access the backing store elements of the argArray, i.e. if you
      pass a JSArray with no holes, or an unmapped, unmodified sloppy or
      strict arguments object.
      
      mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com>
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=v8:4413, v8:4430
      LOG=n
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1523753002 .
      
      Cr-Commit-Position: refs/heads/master@{#32927}
      e4d25389
  19. 16 Dec, 2015 1 commit
  20. 09 Dec, 2015 2 commits
  21. 08 Dec, 2015 1 commit
  22. 04 Dec, 2015 1 commit
  23. 03 Dec, 2015 2 commits
  24. 02 Dec, 2015 2 commits
  25. 30 Nov, 2015 2 commits
  26. 27 Nov, 2015 3 commits