1. 28 Apr, 2016 1 commit
  2. 29 Mar, 2016 1 commit
  3. 10 Mar, 2016 1 commit
  4. 07 Mar, 2016 1 commit
  5. 26 Feb, 2016 3 commits
    • rmcilroy's avatar
      [Interpreter] Add support for cpu profiler logging. · cb29f9cd
      rmcilroy authored
      Adds support for cpu profiler logging to the interpreter. Modifies the
      the API to be passed AbstractCode objects instead of Code objects, and
      adds extra functions to AbstractCode which is required by log.cc and
      cpu-profiler.cc.
      
      The main change in sampler.cc is to determine if a stack frame is an
      interpreter stack frame, and if so, use the bytecode address as the pc
      for that frame. This allows sampling of bytecode functions. This
      requires adding support to SafeStackIterator to determine if a frame is
      interpreted, which we do by checking the PC against pre-stored addresses
      for the start and end of interpreter entry builtins.
      
      Also removes CodeDeleteEvents which are dead code and haven't
      been reported for some time.
      
      Still to do is tracking source positions which will be done in a
      followup CL.
      
      BUG=v8:4766
      LOG=N
      
      Review URL: https://codereview.chromium.org/1728593002
      
      Cr-Commit-Position: refs/heads/master@{#34321}
      cb29f9cd
    • bmeurer's avatar
      [runtime] Remove obsolete %Apply and %TailCall runtime entries. · 7f11fba7
      bmeurer authored
      The %TailCall runtime entry and the %_TailCall intrinsic is not used,
      and will never be used (because %TailCall doesn't actually do a tail
      call). We will soon have proper ES6 tail calls, which are correct and
      properly tested.
      
      The %Apply runtime entry is basically a super-slow, less correct version
      of Reflect.apply, so we can as well just use Reflect.apply, which is
      exposed to builtins via %reflect_apply.
      
      R=ishell@chromium.org
      
      Review URL: https://codereview.chromium.org/1739233002
      
      Cr-Commit-Position: refs/heads/master@{#34317}
      7f11fba7
    • bmeurer's avatar
      [runtime] Make target checking for %Call and %_Call consistent. · 45876462
      bmeurer authored
      The %_Call intrinsic (if supported by the compiler) is lowered directly
      to the Call builtin and thus throws a TypeError if the target is not
      callable. The %Call runtime function also eventually calls into the Call
      builtin, but had an early abort if the target is not a JSReceiver, which
      is unnecessary and leads to various test failures for Ignition.
      
      R=mvstanton@chromium.org
      
      Review URL: https://codereview.chromium.org/1727833006
      
      Cr-Commit-Position: refs/heads/master@{#34316}
      45876462
  6. 25 Feb, 2016 1 commit
  7. 19 Feb, 2016 1 commit
  8. 05 Feb, 2016 1 commit
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of... · 3f36e658
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )
      
      Reason for revert:
      Must revert for now due to chromium api natives issues.
      
      Original issue's description:
      > Type Feedback Vector lives in the closure
      >
      > (RELAND: the problem before was a missing write barrier for adding the code
      > entry to the new closure. It's been addressed with a new macro instruction
      > and test. The only change to this CL is the addition of two calls to
      > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      >
      > 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...
      > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      > And Benedikt reviewed it as well.
      >
      > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
      >
      > BUG=
      >
      > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
      > Cr-Commit-Position: refs/heads/master@{#33741}
      
      TBR=bmeurer@chromium.org
      # 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/1670813005
      
      Cr-Commit-Position: refs/heads/master@{#33766}
      3f36e658
  9. 04 Feb, 2016 1 commit
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · bb31db3a
      mvstanton authored
      (RELAND: the problem before was a missing write barrier for adding the code
      entry to the new closure. It's been addressed with a new macro instruction
      and test. The only change to this CL is the addition of two calls to
      __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      
      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...
      Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      And Benedikt reviewed it as well.
      
      TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1668103002
      
      Cr-Commit-Position: refs/heads/master@{#33741}
      bb31db3a
  10. 03 Feb, 2016 1 commit
  11. 01 Feb, 2016 1 commit
  12. 28 Jan, 2016 1 commit
  13. 27 Jan, 2016 2 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of... · a7027851
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )
      
      Reason for revert:
      Bug: failing to use write barrier when writing code entry into closure.
      
      Original issue's description:
      > Reland of Type Feedback Vector lives in the closure
      >
      > (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=
      >
      > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
      > Cr-Commit-Position: refs/heads/master@{#33548}
      
      TBR=bmeurer@chromium.org,yangguo@chromium.org
      # 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/1643533003
      
      Cr-Commit-Position: refs/heads/master@{#33556}
      a7027851
    • 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
  14. 26 Jan, 2016 2 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
  15. 08 Jan, 2016 1 commit
  16. 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
  17. 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
  18. 22 Dec, 2015 2 commits
  19. 17 Dec, 2015 1 commit
    • neis's avatar
      [proxies] Correctly handle proxies in Function.prototype.bind · 0d83aad5
      neis authored
      - Before getting the length property, we must check for it
        using [[GetOwnProperty]].  Also, if the obtained length
        is a number, we must properly convert it to an integer.
      
      - In order to get the prototype we must use [[GetPrototypeOf]],
        and do so before checking the length.
      
      R=cbruni@chromium.org, jkummerow@chromium.org
      BUG=v8:1543
      LOG=n
      
      Review URL: https://codereview.chromium.org/1530893002
      
      Cr-Commit-Position: refs/heads/master@{#32934}
      0d83aad5
  20. 10 Dec, 2015 1 commit
    • ishell's avatar
      Fix Function subclassing. · dddcd0ac
      ishell authored
      Function subclasses did not have function properties installed (name, prototype, etc.).
      Now when an instance of a Function subclass is created it gets initial map that corresponds
      to the language mode of the function body. The language mode dependent maps are cached as
      special transitions on initial map of the subclass constructor.
      
      BUG=v8:4597, v8:3101, v8:3330
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1510753005
      
      Cr-Commit-Position: refs/heads/master@{#32764}
      dddcd0ac
  21. 01 Dec, 2015 1 commit
  22. 27 Nov, 2015 1 commit
  23. 25 Nov, 2015 1 commit
    • mstarzinger's avatar
      [interpreter] Switch passing of new.target to register. · 3d004eea
      mstarzinger authored
      This passes the new.target value in a register instead of through a
      side-channel via the construct stub. The interpreter entry trampoline
      stores this value in a bytecode register so that it can be accessed
      directly by the interpreter. The size of the interpreter stack frame
      hence grows by one slot.
      
      R=oth@chromium.org
      BUG=v8:4544
      LOG=n
      
      Review URL: https://codereview.chromium.org/1469313002
      
      Cr-Commit-Position: refs/heads/master@{#32264}
      3d004eea
  24. 24 Nov, 2015 2 commits
  25. 19 Nov, 2015 1 commit
  26. 17 Nov, 2015 1 commit
  27. 13 Nov, 2015 2 commits
    • danno's avatar
      [turbofan] Better and more sane support for tail calls · ff283f7d
      danno authored
      * Limit triggering of tail calls to explicit use of a new inline runtime
        function %_TailCall. %_TailCall works just like %_Call except for using
        tail-calling mechanics (currently only in TF).
      * Remove hack that recognized some specific usages of %_Call and converted them
        into tail calls.
      * Support tail calls for all calls where the number of callee stack parameters
        is less than or equal to the number of caller stack parameters.
      * Use the gap resolver to swizzle parameters and registers to tail calls.
      
      BUG=v8:4076
      LOG=n
      
      Review URL: https://codereview.chromium.org/1439613003
      
      Cr-Commit-Position: refs/heads/master@{#31987}
      ff283f7d
    • mstarzinger's avatar
      [turbofan] Rename "original constructor" to "new target". · 83a6ab85
      mstarzinger authored
      This aligns the naming of "new target" with the spec text throughout
      TurboFan and the stack frame walker. The goal is to avoid unnecessary
      confusion for people familiar with the spec.
      
      R=verwaest@chromium.org
      
      Review URL: https://codereview.chromium.org/1442643002
      
      Cr-Commit-Position: refs/heads/master@{#31978}
      83a6ab85
  28. 12 Nov, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Initial support for constructor call inlining. · 11d5d09c
      mstarzinger authored
      This implements a first version of support for constructor call inlining
      in the inlining machinery. For now we can only inline calls where the
      actual constructor and the original constructor coincide (i.e. no super
      constructor calls). Note that the target of a super constructor call is
      loaded with a runtime call, so there is no way for it to be constant
      promoted at the moment.
      
      R=bmeurer@chromium.org
      BUG=v8:4544
      LOG=n
      
      Review URL: https://codereview.chromium.org/1435873002
      
      Cr-Commit-Position: refs/heads/master@{#31954}
      11d5d09c
  29. 05 Nov, 2015 1 commit
  30. 04 Nov, 2015 3 commits