1. 15 Sep, 2015 1 commit
    • mvstanton's avatar
      Reland VectorICs: ia32 store ics need a virtual register. · 1e00bb57
      mvstanton authored
      (reason for revert/reland: patch incorrectly left --vector-stores flag
       on, helpfully revealing some gcstress issues to look at, but they
       don't need to block this CL).
      
      Some pretty hacky code was used to carry out the tail-call
      handler dispatch on ia32 vector stores due to a lack
      of free registers. It really tanks performance. A better
      approach is to use a virtual register on the isolate.
      
      BUG=
      TBR=jkummerow@chromium.org, vogelheim@chromium.org
      
      Review URL: https://codereview.chromium.org/1346573002
      
      Cr-Commit-Position: refs/heads/master@{#30737}
      1e00bb57
  2. 14 Sep, 2015 2 commits
  3. 01 Sep, 2015 1 commit
  4. 27 Aug, 2015 1 commit
  5. 24 Aug, 2015 1 commit
  6. 21 Aug, 2015 1 commit
  7. 17 Aug, 2015 1 commit
  8. 13 Aug, 2015 2 commits
  9. 12 Aug, 2015 1 commit
    • mstarzinger's avatar
      Remove inline header includes from non-inline headers (1). · 00a07bc1
      mstarzinger authored
      This tries to remove includes of "-inl.h" headers from normal ".h"
      headers, thereby reducing the chance of any cyclic dependencies and
      decreasing the average size of our compilation units.
      
      Note that this change still leaves 7 violations of that rule in the
      code. However there now is the "tools/check-inline-includes.sh" tool
      detecting such violations.
      
      R=bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/1283033003
      
      Cr-Commit-Position: refs/heads/master@{#30125}
      00a07bc1
  10. 11 Aug, 2015 1 commit
    • yangguo's avatar
      Rewrite Error.prototype.toString in C++. · 2e2765a6
      yangguo authored
      This avoids many back-and-forth calls to the runtime.
      
      This also slightly changes the way we avoid getters. Previously, we circumvent getting the name property of ReferenceError, SyntaxError and TypeError due to crbug/69187 (in order to avoid leaking information from those errors through a 'name' getter installed on their prototypes). Now we do that for all errors created by V8.
      
      R=jkummerow@chromium.org, rossberg@chromium.org
      BUG=crbug:513472, crbug:69187
      LOG=N
      
      Review URL: https://codereview.chromium.org/1281833002
      
      Cr-Commit-Position: refs/heads/master@{#30105}
      2e2765a6
  11. 10 Aug, 2015 1 commit
  12. 05 Aug, 2015 4 commits
  13. 04 Aug, 2015 3 commits
  14. 30 Jul, 2015 1 commit
  15. 23 Jul, 2015 1 commit
    • rmcilroy's avatar
      [interpreter] Add basic framework for bytecode handler code generation. · 7877c4e0
      rmcilroy authored
      Adds basic support for generation of interpreter bytecode handler code
      snippets. The InterpreterAssembler class exposes a set of low level,
      interpreter specific operations which can be used to build a Turbofan
      graph. The Interpreter class generates a bytecode handler snippet for
      each bytecode by assembling operations using an InterpreterAssembler.
      
      Currently only two simple bytecodes are supported: LoadLiteral0 and Return.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1239793002
      
      Cr-Commit-Position: refs/heads/master@{#29814}
      7877c4e0
  16. 20 Jul, 2015 1 commit
  17. 17 Jul, 2015 1 commit
  18. 24 Jun, 2015 2 commits
  19. 08 Jun, 2015 1 commit
  20. 02 Jun, 2015 1 commit
  21. 26 May, 2015 1 commit
    • erikcorry's avatar
      Move hash code from hidden string to a private symbol · eca5b5d7
      erikcorry authored
      * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
      * In the long run we should do all hidden properties this way and get rid of the
      hidden magic 0-length string with the zero hash code.  The advantages include
      less complexity and being able to do things from JS in a natural way.
      * Initially, the performance of weak set regressed, because it's a little harder
      to do the lookup in C++.  Instead of heroics in C++ to make things faster I
      moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
      * This also changes hash codes of Smis so that they are always Smis.
      
      Performance figures are in the comments to the code review.  Summary: Most of js-perf-test/Collections is neutral.  Set and Map with object keys are 40-50% better.  WeakMap is -5% and WeakSet is +9%.  After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(.
      
      In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this.  Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately).  With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win.
      
      In a similar vein we could give the magic zero hash code to the hash code
      symbol.  Then when we look up the hash code we would sometimes see the table
      with all the hidden properties.  This dual use of the field for either the hash
      code or the table with all hidden properties and the hash code is rather ugly,
      and this CL gets rid of it.  I'd be loath to bring it back.  On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.
      
      One worry is that the benchmark results above are more monomorphic than real
      world code, so may be overstating the performance benefits of moving to JS.  I
      think this is part of a general issue we have with handling polymorphic code in
      JS and any solutions there will benefit this solution, which boils down to
      regular property access. Any improvement there will lift all boats.
      
      R=adamk@chromium.org, verwaest@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1149863005
      
      Cr-Commit-Position: refs/heads/master@{#28622}
      eca5b5d7
  22. 22 May, 2015 1 commit
  23. 19 May, 2015 1 commit
  24. 12 May, 2015 1 commit
  25. 04 May, 2015 1 commit
  26. 30 Apr, 2015 3 commits
  27. 29 Apr, 2015 1 commit
  28. 27 Apr, 2015 1 commit
  29. 23 Apr, 2015 1 commit
  30. 22 Apr, 2015 1 commit
    • machenbach's avatar
      Revert of Revert of Protect the emptiness of Array prototype elements with a... · 2631c9f5
      machenbach authored
      Revert of Revert of Protect the emptiness of Array prototype elements with a PropertyCell. (patchset #1 id:1 of https://codereview.chromium.org/1099203004/)
      
      Reason for revert:
      This was probably an infrastructure problem caused by the mac ninja/goma switch.
      
      Original issue's description:
      > Revert of Protect the emptiness of Array prototype elements with a PropertyCell. (patchset #7 id:120001 of https://codereview.chromium.org/1092043002/)
      >
      > Reason for revert:
      > MAC GCSTRESS failure on new test.
      >
      > Original issue's description:
      > > Protect the emptiness of Array prototype elements with a PropertyCell.
      > >
      > > Not just emptiness, but also a particular structure.
      > >
      > > BUG=v8:4044
      > > LOG=N
      >
      > TBR=jkummerow@chromium.org
      > NOPRESUBMIT=true
      > NOTREECHECKS=true
      > NOTRY=true
      > BUG=v8:4044
      
      TBR=jkummerow@chromium.org,mvstanton@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4044
      
      Review URL: https://codereview.chromium.org/1052253003
      
      Cr-Commit-Position: refs/heads/master@{#28000}
      2631c9f5