1. 25 May, 2018 1 commit
  2. 24 May, 2018 1 commit
  3. 09 Apr, 2018 1 commit
  4. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored
      This reverts commit f9a2e24b.
      
      Reason for revert: gc stress failures not all fixed by follow up.
      
      Original change's description:
      > [cleanup] Refactor the Factory
      > 
      > There is no good reason to have the meat of most objects' initialization
      > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      > this CL changes the protocol between Heap and Factory to be AllocateRaw,
      > and all object initialization work after (possibly retried) successful
      > raw allocation happens in the Factory.
      > 
      > This saves about 20KB of binary size on x64.
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      > Reviewed-on: https://chromium-review.googlesource.com/959533
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52416}
      
      TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
      
      Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored
      There is no good reason to have the meat of most objects' initialization
      logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      this CL changes the protocol between Heap and Factory to be AllocateRaw,
      and all object initialization work after (possibly retried) successful
      raw allocation happens in the Factory.
      
      This saves about 20KB of binary size on x64.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      Reviewed-on: https://chromium-review.googlesource.com/959533
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  5. 09 Jan, 2018 1 commit
  6. 30 Nov, 2017 2 commits
  7. 27 Nov, 2017 1 commit
  8. 16 Oct, 2017 1 commit
  9. 20 Jul, 2017 1 commit
  10. 10 Jul, 2017 1 commit
  11. 06 Apr, 2017 1 commit
  12. 20 Dec, 2016 3 commits
  13. 05 Dec, 2016 1 commit
  14. 24 Oct, 2016 1 commit
  15. 21 Oct, 2016 3 commits
    • jgruber's avatar
      [regexp] Use consistent map checks for fast paths · eb10dc4c
      jgruber authored
      These map checks were implemented for TF code already. This CL makes
      sure that parts implemented in C++ follow the same logic, which is:
      
      An object is an unmodified regexp if:
      1) it's a receiver,
      2) its map is the initial regexp map,
      3) its prototype is a receiver,
      4) and its prototype's map is the initial prototype's initial map.
      
      We can now be smarter in @@replace and @@split since checking maps
      (unlike the previous check of RegExp.prototype.exec) is not observable,
      so we can perform fast-path checks at a time of our choosing.
      
      BUG=v8:5339,v8:5434,v8:5123
      
      Review-Url: https://chromiumcodereview.appspot.com/2434983002
      Cr-Commit-Position: refs/heads/master@{#40501}
      eb10dc4c
    • machenbach's avatar
      Revert of [regexp] Use consistent map checks for fast paths (patchset #7... · 0b7e35ff
      machenbach authored
      Revert of [regexp] Use consistent map checks for fast paths (patchset #7 id:120001 of https://chromiumcodereview.appspot.com/2434983002/ )
      
      Reason for revert:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/10853
      
      Original issue's description:
      > [regexp] Use consistent map checks for fast paths
      >
      > These map checks were implemented for TF code already. This CL makes
      > sure that parts implemented in C++ follow the same logic, which is:
      >
      > An object is an unmodified regexp if:
      > 1) it's a receiver,
      > 2) its map is the initial regexp map,
      > 3) its prototype is a receiver,
      > 4) and its prototype's map is the initial prototype's initial map.
      >
      > We can now be smarter in @@replace and @@split since checking maps
      > (unlike the previous check of RegExp.prototype.exec) is not observable,
      > so we can perform fast-path checks at a time of our choosing.
      >
      > BUG=v8:5339,v8:5434,v8:5123
      
      TBR=yangguo@chromium.org,jgruber@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5339,v8:5434,v8:5123
      
      Review-Url: https://chromiumcodereview.appspot.com/2438283002
      Cr-Commit-Position: refs/heads/master@{#40499}
      0b7e35ff
    • jgruber's avatar
      [regexp] Use consistent map checks for fast paths · bac992a1
      jgruber authored
      These map checks were implemented for TF code already. This CL makes
      sure that parts implemented in C++ follow the same logic, which is:
      
      An object is an unmodified regexp if:
      1) it's a receiver,
      2) its map is the initial regexp map,
      3) its prototype is a receiver,
      4) and its prototype's map is the initial prototype's initial map.
      
      We can now be smarter in @@replace and @@split since checking maps
      (unlike the previous check of RegExp.prototype.exec) is not observable,
      so we can perform fast-path checks at a time of our choosing.
      
      BUG=v8:5339,v8:5434,v8:5123
      
      Review-Url: https://chromiumcodereview.appspot.com/2434983002
      Cr-Commit-Position: refs/heads/master@{#40495}
      bac992a1
  16. 14 Oct, 2016 2 commits
  17. 13 Oct, 2016 1 commit
    • jgruber's avatar
      [regexp] Fix fallback path in RegExpExec · e89eef30
      jgruber authored
      This fixes the code-path in RegExpExec in which both the passed exec
      argument and regexp.exec are not callable and regexp is a JSRegExp.
      
      In this case, we fall back to the default RegExp.prototype.exec
      implementation. The arguments for Execution::call were incorrect.
      
      BUG=v8:5339
      
      Review-Url: https://codereview.chromium.org/2415073002
      Cr-Commit-Position: refs/heads/master@{#40249}
      e89eef30
  18. 12 Oct, 2016 1 commit