1. 22 Jan, 2020 1 commit
  2. 14 Nov, 2019 1 commit
  3. 30 Apr, 2019 1 commit
  4. 11 Dec, 2018 1 commit
  5. 13 Nov, 2018 1 commit
    • peterwmwong's avatar
      [builtins] Fast path TA.p.subarray creating TypedArray when default constructor is used · 7c35c03b
      peterwmwong authored
      Previously, the following call sequence was always made when creating resulting
      subsetted TypedArray:
      1) TFJ TypedArrayPrototypeSubArray
      2) TFS TypedArrayConstructor
      3) TFS CreateTypedArray
      
      This CL, skips #2 and goes straight to #3 when the default constructor (builtin) is
      safe to use (IsPrototypeTypedArrayPrototype and
      !IsTypedArraySpeciesProtectorCellInvalid).
      
      Local TypedArrays/SubarrayNoSpecies microbenchmark shows ~35-40% improvement...
      
      BEFORE
      TypedArrays-SubarrayNoSpecies(Score): 1033530
      TypedArrays-SubarrayNoSpecies(Score): 1018490
      TypedArrays-SubarrayNoSpecies(Score): 1037030
      
      AFTER
      TypedArrays-SubarrayNoSpecies(Score): 1439030
      TypedArrays-SubarrayNoSpecies(Score): 1417540
      TypedArrays-SubarrayNoSpecies(Score): 1405980
      
      Bug: v8:7161
      Change-Id: I356dace36570aa161ffe208a57a80e46714121a2
      Reviewed-on: https://chromium-review.googlesource.com/c/1331154
      Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57458}
      7c35c03b
  6. 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
  7. 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
  8. 27 Nov, 2017 2 commits
  9. 19 Oct, 2017 2 commits
  10. 04 Sep, 2017 1 commit
  11. 18 Aug, 2017 1 commit
  12. 02 May, 2017 2 commits
    • Peter Marshall's avatar
      [builtins] Fix overly strict CHECK in TypedArray.Set. · 0d582ada
      Peter Marshall authored
      The existing CHECK assumed that the source and destination could not
      have the same buffer, but they actually can as long as the data
      ranges do not overlap within the buffer. Change the check to look for
      this more relaxed condition instead.
      
      Moved the check outside of the memcpy case as well, given that it
      should also apply for the slower, element-by-element copy as well.
      
      Also use JSTypedArray::element_size() to get the element size instead
      of the helper on the FixedTypedArrayBase. This lets us change that
      helper back to private again.
      
      Bug: chromium:717022
      
      Change-Id: I2eca1df1e87444c5db397e0b7cf686cefe67d29c
      Reviewed-on: https://chromium-review.googlesource.com/493147
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45035}
      0d582ada
    • Peter Marshall's avatar
      [builtins] Fix TypedArray.Set for string inputs. · 74aa7ff3
      Peter Marshall authored
      String inputs would end up in the fast-path, crashing because it
      expected an array type. Add the fast path explicitly when the source is
      a TypedArray, and let everything else fall back to the generic JS
      implementation.
      
      Bug: chromium:715971
      Change-Id: Ieec28e93279047d403e00ed2676dc1eda193c033
      Reviewed-on: https://chromium-review.googlesource.com/493226
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45034}
      74aa7ff3
  13. 13 Mar, 2017 1 commit
  14. 07 Mar, 2017 1 commit
  15. 03 Mar, 2017 1 commit
  16. 02 Mar, 2017 1 commit
  17. 01 Mar, 2017 2 commits
    • Peter Marshall's avatar
      Revert "[builtins] Port TypedArrayInitialize to CodeStubAssembler." · a8e15e8f
      Peter Marshall authored
      This reverts commit b23b2c10.
      
      Reason for revert: Makes Linux debug bot sad
      
      Original change's description:
      > [builtins] Port TypedArrayInitialize to CodeStubAssembler.
      > 
      > Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
      > because we always go to the C++ builtin. Port the builtin to CSA
      > to improve performance, and to clean up the implementation, which is
      > split across multiple files and pieces at the moment.
      > 
      > This CL increases the performance with --future to roughly the same
      > as with crankshaft.
      > 
      > BUG=v8:5977
      > 
      > Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
      > Reviewed-on: https://chromium-review.googlesource.com/445717
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#43518}
      
      TBR=cbruni@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,v8-reviews@googlegroups.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5977
      
      Change-Id: I5d5bc8b4677a405c716d78e688af80ae9c737b4a
      Reviewed-on: https://chromium-review.googlesource.com/448558Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43520}
      a8e15e8f
    • Peter Marshall's avatar
      [builtins] Port TypedArrayInitialize to CodeStubAssembler. · b23b2c10
      Peter Marshall authored
      Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
      because we always go to the C++ builtin. Port the builtin to CSA
      to improve performance, and to clean up the implementation, which is
      split across multiple files and pieces at the moment.
      
      This CL increases the performance with --future to roughly the same
      as with crankshaft.
      
      BUG=v8:5977
      
      Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
      Reviewed-on: https://chromium-review.googlesource.com/445717
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43518}
      b23b2c10
  18. 05 Dec, 2016 1 commit
    • ynovikov's avatar
      Reland of [typedarrays] remove invalid optimization in NAMEConstructor()... · f5cb17a8
      ynovikov authored
      Reland of [typedarrays] remove invalid optimization in NAMEConstructor() (patchset #1 id:1 of https://codereview.chromium.org/2548583003/ )
      
      Reason for revert:
      The bot was not affected by the revert. Speculation was wrong.
      
      Original issue's description:
      > Revert of [typedarrays] remove invalid optimization in NAMEConstructor() (patchset #1 id:1 of https://codereview.chromium.org/2544503002/ )
      >
      > Reason for revert:
      > Speculative revert for causing timeouts on Win Debug gpu fyi bot
      >
      > Nothing else looks even remotely relevant in the list of changes.
      > Will reland if this doesn't fix the issues.
      >
      > BUG=670396
      >
      > Original issue's description:
      > > [typedarrays] remove invalid optimization in NAMEConstructor()
      > >
      > > Before, we were treating objects with the builtin ArrayValues iterator
      > > method as array-like, where the iterator would iterate through to the
      > > full length of the object.
      > >
      > > This optimization was not sound, because it does not ensure that the
      > > next method hasn't been modified. Even if it hasn't been modified,
      > > it's entirely possible to be modified during iteration. Thus, this
      > > optimization has been removed due to its observability.
      > >
      > > BUG=v8:5699
      > > R=littledan@chromium.org, cbruni@chromium.org
      > >
      > > Committed: https://crrev.com/77df8c67d9609ada3b7d79e8e6d33f198bbad5a1
      > > Cr-Commit-Position: refs/heads/master@{#41394}
      >
      > TBR=cbruni@chromium.org,littledan@chromium.org,caitp@igalia.com
      > # Not skipping CQ checks because original CL landed more than 1 days ago.
      > BUG=v8:5699
      >
      > Committed: https://crrev.com/0ea4a542202d501c4e550474e89512532571f3a0
      > Cr-Commit-Position: refs/heads/master@{#41461}
      
      TBR=cbruni@chromium.org,littledan@chromium.org,caitp@igalia.com,enne@chromium.org
      # Not skipping CQ checks because original CL landed more than 1 days ago.
      BUG=670396
      
      Review-Url: https://codereview.chromium.org/2553873002
      Cr-Commit-Position: refs/heads/master@{#41504}
      f5cb17a8
  19. 02 Dec, 2016 1 commit
    • enne's avatar
      Revert of [typedarrays] remove invalid optimization in NAMEConstructor()... · 0ea4a542
      enne authored
      Revert of [typedarrays] remove invalid optimization in NAMEConstructor() (patchset #1 id:1 of https://codereview.chromium.org/2544503002/ )
      
      Reason for revert:
      Speculative revert for causing timeouts on Win Debug gpu fyi bot
      
      Nothing else looks even remotely relevant in the list of changes.
      Will reland if this doesn't fix the issues.
      
      BUG=670396
      
      Original issue's description:
      > [typedarrays] remove invalid optimization in NAMEConstructor()
      >
      > Before, we were treating objects with the builtin ArrayValues iterator
      > method as array-like, where the iterator would iterate through to the
      > full length of the object.
      >
      > This optimization was not sound, because it does not ensure that the
      > next method hasn't been modified. Even if it hasn't been modified,
      > it's entirely possible to be modified during iteration. Thus, this
      > optimization has been removed due to its observability.
      >
      > BUG=v8:5699
      > R=littledan@chromium.org, cbruni@chromium.org
      >
      > Committed: https://crrev.com/77df8c67d9609ada3b7d79e8e6d33f198bbad5a1
      > Cr-Commit-Position: refs/heads/master@{#41394}
      
      TBR=cbruni@chromium.org,littledan@chromium.org,caitp@igalia.com
      # Not skipping CQ checks because original CL landed more than 1 days ago.
      BUG=v8:5699
      
      Review-Url: https://codereview.chromium.org/2548583003
      Cr-Commit-Position: refs/heads/master@{#41461}
      0ea4a542
  20. 30 Nov, 2016 1 commit
    • caitp's avatar
      [typedarrays] remove invalid optimization in NAMEConstructor() · 77df8c67
      caitp authored
      Before, we were treating objects with the builtin ArrayValues iterator
      method as array-like, where the iterator would iterate through to the
      full length of the object.
      
      This optimization was not sound, because it does not ensure that the
      next method hasn't been modified. Even if it hasn't been modified,
      it's entirely possible to be modified during iteration. Thus, this
      optimization has been removed due to its observability.
      
      BUG=v8:5699
      R=littledan@chromium.org, cbruni@chromium.org
      
      Review-Url: https://codereview.chromium.org/2544503002
      Cr-Commit-Position: refs/heads/master@{#41394}
      77df8c67
  21. 17 Aug, 2016 1 commit
  22. 02 Jul, 2016 1 commit
  23. 29 Jun, 2016 1 commit
  24. 24 Jun, 2016 2 commits
  25. 11 Mar, 2016 1 commit
  26. 19 Feb, 2016 1 commit
  27. 26 Jan, 2016 1 commit
    • littledan's avatar
      Fix length of DataView and TypedArray get/set functions · 3f37c446
      littledan authored
      Functions like DataView.prototype.getUint8 should have length 1,
      and DataView.prototype.setUint8 should have length 2, as their
      endianness arguments are optional. Additionally,
      TypedArray.prototype.set.length should be 2. This follows the ES2015
      specification, and a new test262 test tests for it. This patch
      fixes the functions' lengths.
      
      R=adamk
      
      Review URL: https://codereview.chromium.org/1636953003
      
      Cr-Commit-Position: refs/heads/master@{#33531}
      3f37c446
  28. 30 Dec, 2015 1 commit
    • littledan's avatar
      Reland of Use ES2015-style TypedArray prototype chain (patchset #1 id:1 of... · e549c7a3
      littledan authored
      Reland of Use ES2015-style TypedArray prototype chain (patchset #1 id:1 of https://codereview.chromium.org/1554523002/ )
      
      Reason for revert:
      Should be fixed again with this Blink change to add NeedsManualRebaseline
      
      Original issue's description:
      > Revert of Use ES2015-style TypedArray prototype chain (patchset #5 id:80001 of https://codereview.chromium.org/1541233002/ )
      >
      > Reason for revert:
      > [Sheriff] Changes layout tests. Please fix upstream first if intended.
      >
      > https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3689
      >
      > Original issue's description:
      > > Use ES2015-style TypedArray prototype chain
      > >
      > > This patch switches TypedArrays to use the prototype chain described
      > > in the ES2015 specification, which adds a %TypedArray% superclass above
      > > all individual TypedArray types. Most methods are defined on the
      > > superclass rather than the subclasses.
      > >
      > > In order to prevent a performance regression, a few methods are
      > > marked as inline. Inlining might prevent code which was previously
      > > monomorphic from becoming polymorphic, and it was specifically
      > > applied in places where methods became more polymorphic than before.
      > > Tests with realistic workloads would be nice to do before this
      > > ships in stable.
      > >
      > > This patch does not bring TypedArrays up to full spec compliance. In
      > > particular, @@species is not yet supported.
      > >
      > > R=cbruni
      > > BUG=v8:4085
      > > LOG=Y
      > >
      > > Committed: https://crrev.com/07c91dccbe55c7be3ec75857dee5ad59873330b7
      > > Cr-Commit-Position: refs/heads/master@{#33050}
      >
      > TBR=caitpotter88@gmail.com,cbruni@chromium.org,littledan@chromium.org
      > NOPRESUBMIT=true
      > NOTREECHECKS=true
      > NOTRY=true
      > BUG=v8:4085
      >
      > Committed: https://crrev.com/28b55ffd1e32e09aaf42b8bbb407944d4808e07c
      > Cr-Commit-Position: refs/heads/master@{#33053}
      
      TBR=caitpotter88@gmail.com,cbruni@chromium.org,machenbach@chromium.org
      BUG=v8:4085
      LOG=Y
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      
      Review URL: https://codereview.chromium.org/1558663002
      
      Cr-Commit-Position: refs/heads/master@{#33067}
      e549c7a3
  29. 29 Dec, 2015 1 commit
    • machenbach's avatar
      Revert of Use ES2015-style TypedArray prototype chain (patchset #5 id:80001 of... · 28b55ffd
      machenbach authored
      Revert of Use ES2015-style TypedArray prototype chain (patchset #5 id:80001 of https://codereview.chromium.org/1541233002/ )
      
      Reason for revert:
      [Sheriff] Changes layout tests. Please fix upstream first if intended.
      
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3689
      
      Original issue's description:
      > Use ES2015-style TypedArray prototype chain
      >
      > This patch switches TypedArrays to use the prototype chain described
      > in the ES2015 specification, which adds a %TypedArray% superclass above
      > all individual TypedArray types. Most methods are defined on the
      > superclass rather than the subclasses.
      >
      > In order to prevent a performance regression, a few methods are
      > marked as inline. Inlining might prevent code which was previously
      > monomorphic from becoming polymorphic, and it was specifically
      > applied in places where methods became more polymorphic than before.
      > Tests with realistic workloads would be nice to do before this
      > ships in stable.
      >
      > This patch does not bring TypedArrays up to full spec compliance. In
      > particular, @@species is not yet supported.
      >
      > R=cbruni
      > BUG=v8:4085
      > LOG=Y
      >
      > Committed: https://crrev.com/07c91dccbe55c7be3ec75857dee5ad59873330b7
      > Cr-Commit-Position: refs/heads/master@{#33050}
      
      TBR=caitpotter88@gmail.com,cbruni@chromium.org,littledan@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4085
      
      Review URL: https://codereview.chromium.org/1554523002
      
      Cr-Commit-Position: refs/heads/master@{#33053}
      28b55ffd
  30. 28 Dec, 2015 1 commit
    • littledan's avatar
      Use ES2015-style TypedArray prototype chain · 07c91dcc
      littledan authored
      This patch switches TypedArrays to use the prototype chain described
      in the ES2015 specification, which adds a %TypedArray% superclass above
      all individual TypedArray types. Most methods are defined on the
      superclass rather than the subclasses.
      
      In order to prevent a performance regression, a few methods are
      marked as inline. Inlining might prevent code which was previously
      monomorphic from becoming polymorphic, and it was specifically
      applied in places where methods became more polymorphic than before.
      Tests with realistic workloads would be nice to do before this
      ships in stable.
      
      This patch does not bring TypedArrays up to full spec compliance. In
      particular, @@species is not yet supported.
      
      R=cbruni
      BUG=v8:4085
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1541233002
      
      Cr-Commit-Position: refs/heads/master@{#33050}
      07c91dcc
  31. 04 Dec, 2015 1 commit
  32. 03 Dec, 2015 1 commit
  33. 19 Oct, 2015 1 commit
  34. 17 Jul, 2015 1 commit
    • littledan's avatar
      Additional TypedArray tests · 8068b91d
      littledan authored
      - Test that TypedArray properties cannot be set in strict mode
        Properties like %TypedArray%.prototype.length have a getter and no
        setter. This test verifies that property, which was apparently not
        true in the past or had no test ensuring throwing in this case.
      - Test that TypedArray integer indexed properties (array elements)
        are not configurable
      
      Both of these have passed for some time, but there are open bugs against
      them and apparently no tests verifying that they are fixed.
      
      BUG=v8:3048, v8:3799
      LOG=N
      R=adamk
      
      Review URL: https://codereview.chromium.org/1232843005
      
      Cr-Commit-Position: refs/heads/master@{#29717}
      8068b91d