1. 01 Mar, 2016 1 commit
  2. 29 Feb, 2016 1 commit
    • bmeurer's avatar
      [stubs] Introduce a proper ToBooleanStub. · d1df58e8
      bmeurer authored
      Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match
      our naming convention, and add a new TurboFan-powered ToBooleanStub,
      which just does the ToBoolean conversion without any runtime call or
      code patching, so we can use it for Ignition (and TurboFan).
      
      Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we
      already have for to_string and to_number, so we don't need to actually
      dispatch on the concrete Oddball at all.
      
      R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1744163002
      
      Cr-Commit-Position: refs/heads/master@{#34361}
      d1df58e8
  3. 22 Feb, 2016 1 commit
  4. 18 Feb, 2016 1 commit
  5. 11 Feb, 2016 1 commit
  6. 08 Feb, 2016 1 commit
  7. 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
  8. 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
  9. 29 Jan, 2016 1 commit
    • jkummerow's avatar
      Introduce {FAST,SLOW}_STRING_WRAPPER_ELEMENTS · f4872f74
      jkummerow authored
      String wrappers (new String("foo")) are special objects: their string
      characters are accessed like elements, and they also have an elements
      backing store. This used to require a bunch of explicit checks like:
      
      if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
        /* Handle string characters */
      }
      // Handle regular elements (for string wrappers and other objects)
      obj->GetElementsAccessor()->Whatever(...);
      
      This CL introduces new ElementsKinds for string wrapper objects (one for
      fast elements, one for dictionary elements), which allow folding the
      special-casing into new StringWrapperElementsAccessors.
      
      No observable change in behavior is intended.
      
      Review URL: https://codereview.chromium.org/1612323003
      
      Cr-Commit-Position: refs/heads/master@{#33616}
      f4872f74
  10. 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
  11. 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
  12. 18 Jan, 2016 1 commit
  13. 14 Jan, 2016 1 commit
  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. 08 Dec, 2015 1 commit
  17. 04 Dec, 2015 1 commit
  18. 03 Dec, 2015 1 commit
  19. 30 Nov, 2015 2 commits
  20. 25 Nov, 2015 1 commit
  21. 24 Nov, 2015 1 commit
  22. 13 Nov, 2015 1 commit
  23. 12 Nov, 2015 1 commit
  24. 03 Nov, 2015 1 commit
  25. 02 Nov, 2015 4 commits
  26. 29 Oct, 2015 1 commit
  27. 12 Oct, 2015 1 commit
  28. 06 Oct, 2015 1 commit
  29. 01 Oct, 2015 1 commit
  30. 30 Sep, 2015 1 commit
  31. 29 Sep, 2015 1 commit
  32. 28 Sep, 2015 1 commit
  33. 17 Sep, 2015 1 commit