1. 26 Oct, 2018 1 commit
  2. 20 Sep, 2018 1 commit
  3. 09 Aug, 2018 1 commit
    • jgruber's avatar
      [builtins] Fix argument order inconsistency in HasProperty · 3c1f40de
      jgruber authored
      The HasProperty builtin differed in its expected argument order from
      the HasProperty runtime function. Like all other related spec
      primitives (e.g.: GetProperty, SetProperty, DeleteProperty), it should
      take {object} as the first argument and {key} as the second.
      
      This CL changes the builtin and all related spots to use the correct
      order.
      
      There was also a tricky bug in interpreter intrinsic rewriting, which
      assumes (but does not verify) that the argument order between runtime
      function and builtin is identical. Besides cctests, HasProperty
      intrinsic rewriting seems to be dead code.
      
      Bug: v8:8036
      Change-Id: Ia669fd6f5c73a30df4e4607064603be759ced392
      Reviewed-on: https://chromium-review.googlesource.com/1167297
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55022}
      3c1f40de
  4. 05 Jul, 2018 1 commit
  5. 18 Jun, 2018 2 commits
  6. 14 Jun, 2018 1 commit
    • jgruber's avatar
      Fix stack check pattern matching for CSA code · 9ff644ae
      jgruber authored
      The stack check instruction sequence is pattern-matched in
      instruction-selector-{ia32,x64}.cc and replaced with its own specialized
      opcode, for which we later generate an efficient stack check in a single
      instruction.
      
      But this pattern matching has never worked for CSA-generated code. The
      matcher expected LoadStackPointer in the right operand and the external
      reference load in the left operand. CSA generated exactly vice-versa.
      
      This CL does a few things; it
      1. reverts the recent change to load the
      limit from smi roots:
      
      Revert "[csa] Load the stack limit from smi roots"
      This reverts commit 507c29c9.
      
      2. tweaks the CSA instruction sequence to output what the matcher
      expects.
      3. refactors stack check matching into a new StackCheckMatcher class.
      4. typifies CSA::PerformStackCheck as a drive-by.
      
      Bug: v8:6666,v8:7844
      Change-Id: I9bb879ac10bfe7187750c5f9e7834dc4accf28b5
      Reviewed-on: https://chromium-review.googlesource.com/1099068Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53737}
      9ff644ae
  7. 17 May, 2018 1 commit
  8. 14 May, 2018 1 commit
  9. 07 May, 2018 1 commit
  10. 27 Apr, 2018 1 commit
  11. 05 Mar, 2018 1 commit
  12. 02 Mar, 2018 1 commit
  13. 27 Feb, 2018 1 commit
  14. 10 Jan, 2018 1 commit
    • Timothy Gu's avatar
      [proxy] Set [[ProxyTarget]] to null during revocation · 5b9adade
      Timothy Gu authored
      Before this, only the [[ProxyHandler]] was set to null during revocation
      of the Proxy through either the v8::Proxy::Revoke() or the
      Proxy.revocable() API. To be consistent with the spec, the Proxy's
      target is set to null as well. This change should not be observable
      through JS, since the check for if the Proxy is revoked should always
      use the handler. But the changed value is exposed through the public
      v8::Proxy::GetTarget() API, which is used by the inspector API and
      Node.js.
      
      Also included is a much more comprehensive test for Inspector's support
      for Proxy, which prior to this commit did not work as intended.
      
      Bug: 
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I727607ec2b3cea8642cd636573932c1e6bb5cc07
      Reviewed-on: https://chromium-review.googlesource.com/854676
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50476}
      5b9adade
  15. 07 Jan, 2018 1 commit
  16. 02 Nov, 2017 1 commit
  17. 25 Oct, 2017 2 commits
  18. 23 Oct, 2017 3 commits
  19. 16 Oct, 2017 1 commit
  20. 04 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Optimize Object.is baseline and interesting cases. · d4da17c6
      Benedikt Meurer authored
      The Object.is builtin provides an entry point to the abstract operation
      SameValue, which properly distinguishes -0 and 0, and also identifies
      NaNs. Most of the time you don't need these, but rather just regular
      strict equality, but when you do, Object.is(o, -0) is the most readable
      way to check for minus zero.
      
      This is for example used in Node.js by formatNumber to properly print -0
      for negative zero. However since the builtin thus far implemented as C++
      builtin and TurboFan didn't know anything about it, Node.js considering
      to go with a more performant, less readable version (which also makes
      assumptions about the input value) in
      
        https://github.com/nodejs/node/pull/15726
      
      until the performance of Object.is will be on par (so hopefully we can
      go back to Object.is in Node 9).
      
      This CL ports the baseline implementation of Object.is to CSA, which
      is pretty straight-forward since SameValue is already available in
      CodeStubAssembler, and inlines a few interesting cases into TurboFan,
      i.e. comparing same SSA node, and checking for -0 and NaN explicitly.
      
      On the micro-benchmarks we go from
      
        testNumberIsMinusZero: 1000 ms.
        testObjectIsMinusZero: 929 ms.
        testObjectIsNaN: 954 ms.
        testObjectIsSame: 793 ms.
        testStrictEqualSame: 104 ms.
      
      to
      
        testNumberIsMinusZero: 89 ms.
        testObjectIsMinusZero: 88 ms.
        testObjectIsNaN: 88 ms.
        testObjectIsSame: 86 ms.
        testStrictEqualSame: 105 ms.
      
      which is a nice 10x to 11x improvement and brings Object.is on par with
      strict equality for most cases.
      
      Drive-by-fix: Also refactor and optimize the SameValue check in the
      CodeStubAssembler to avoid code bloat (by not inlining StrictEqual
      into every user of SameValue, and also avoiding useless checks).
      
      Bug: v8:6882
      Change-Id: Ibffd8c36511f219fcce0d89ed4e1073f5d6c6344
      Reviewed-on: https://chromium-review.googlesource.com/700254Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48275}
      d4da17c6
  21. 01 Sep, 2017 4 commits
  22. 21 Aug, 2017 1 commit
  23. 18 Aug, 2017 1 commit
  24. 16 Aug, 2017 1 commit
  25. 09 Aug, 2017 2 commits
  26. 04 Aug, 2017 1 commit
  27. 28 Jul, 2017 1 commit
  28. 19 Jul, 2017 1 commit
  29. 14 Jul, 2017 1 commit
  30. 13 Jul, 2017 1 commit
  31. 11 Jul, 2017 1 commit
  32. 10 Jul, 2017 1 commit