1. 09 Apr, 2018 1 commit
  2. 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
  3. 14 Mar, 2018 1 commit
  4. 13 Mar, 2018 1 commit
  5. 09 Feb, 2018 1 commit
  6. 07 Feb, 2018 1 commit
  7. 06 Feb, 2018 1 commit
  8. 11 Jan, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] load `iterator.next` only once at beginning of iteration" · 2d889aa9
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org
      TBR=neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
      Reviewed-on: https://chromium-review.googlesource.com/857593
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50518}
      2d889aa9
  9. 09 Jan, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[esnext] load `iterator.next` only once at beginning of iteration" · 163b5d70
      Michael Achenbach authored
      This reverts commit bf4cc9ee.
      
      Reason for revert: Breaks windows with msvc and linux with gcc
      https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265
      
      Original change's description:
      > [esnext] load `iterator.next` only once at beginning of iteration
      > 
      > https://github.com/tc39/ecma262/pull/988 gained concensus during the
      > september 2017 TC39 meetings. This moves the load of the "next" method
      > to the very beginning of the iteration protocol, rather than during
      > each iteration step.
      > 
      > This impacts:
      > 
      > - yield*
      > - for-of loops
      > - spread arguments
      > - array spreads
      > 
      > In the v8 implementation, this also affects async iteration versions of
      > these things (the sole exception being the Async-From-Sync iterator,
      > which requires a few more changes to work with this, likely done in a
      > followup patch).
      > 
      > This change introduces a new AST node, ResolvedProperty, which can be used
      > as a callee by Call nodes to produce the same bytecode as Property calls,
      > without observably re-loading the property. This is used in several
      > AST-desugarings involving the iteration protocol.
      > 
      > BUG=v8:6861, v8:5699
      > R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      > Reviewed-on: https://chromium-review.googlesource.com/687997
      > Commit-Queue: Caitlin Potter <caitp@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50452}
      
      TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org
      
      Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6861, v8:5699
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/857616Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50454}
      163b5d70
    • Caitlin Potter's avatar
      [esnext] load `iterator.next` only once at beginning of iteration · bf4cc9ee
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      Reviewed-on: https://chromium-review.googlesource.com/687997
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50452}
      bf4cc9ee
  10. 20 Nov, 2017 1 commit
  11. 13 Sep, 2017 1 commit
  12. 14 Jun, 2017 1 commit
    • Caitlin Potter's avatar
      Reland "[builtins] port Promise.all to CSA" · 8ada7538
      Caitlin Potter authored
      Simplifies the implementation of IteratorClose in IteratorBuiltinsAssembler, and makes clear that it is only invoked when an exception occurs. Adds exception handling support to GetIterator, IteratorStep, and IteratorCloseOnException.
      
      Moves the Promise.all resolveElement closure and it's caller to
      builtins-promise-gen.cc.
      
      Instead of creating an internal array (and copying its elements into a
      result
      array), a single JSArray is allocated, and appended with
      BuildAppendJSArray(),
      falling back to %CreateDataProperty(), and elements are updated in the
      resolve
      closure the same way. This should always be unobservable.
      
      This CL increases the size of snapshot_blob.bin on an x64.release build
      by 8.51kb
      
      BUG=v8:5343
      R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org, hpayer@chromium.org, tebbi@chromium.org
      
      Change-Id: I29c4a529154ef49ad65555ce6ddc2c5b7c9de6b3
      Reviewed-on: https://chromium-review.googlesource.com/508473
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45946}
      8ada7538
  13. 31 May, 2017 1 commit
  14. 23 May, 2017 1 commit