1. 21 Jan, 2021 1 commit
  2. 19 Jan, 2021 3 commits
  3. 18 Jan, 2021 1 commit
  4. 13 Jan, 2021 1 commit
  5. 08 Jan, 2021 1 commit
    • Seth Brenith's avatar
      [interpreter] Include Star lookahead for more bytecodes · 0d30fac2
      Seth Brenith authored
      I made some temporary changes in BytecodeArrayWriter to log counts of
      how often each pair of bytecodes is adjacent. In data I collected on a
      Facebook page with those changes enabled, I noticed that the following
      bytecodes were commonly followed by Star, but do not appear in
      IsStarLookahead.
      
      LdaImmutableCurrentContextSlot:
        4.4% of all instructions, 66% chance to be followed by Star
      CreateClosure:
        3.9% of all instructions, 57% chance to be followed by Star
      LdaImmutableContextSlot:
        1.7% of all instructions, 95% chance to be followed by Star
      CreateObjectLiteral:
        1.4% of all instructions, 92% chance to be followed by Star
      CreateArrayLiteral:
        1.4% of all instructions, 99% chance to be followed by Star
      ThrowReferenceErrorIfHole:
        0.7% of all instructions, 100% chance to be followed by Star
      GetTemplateObject:
        0.6% of all instructions, 100% chance to be followed by Star
      CreateEmptyArrayLiteral:
        0.4% of all instructions, 87% chance to be followed by Star
      CreateEmptyObjectLiteral:
        0.2% of all instructions, 79% chance to be followed by Star
      
      I cross-referenced this list with data from google.com and youtube.com
      (the top two sites according to Alexa), and found that CreateClosure and
      CreateEmpty*Literal are not likely followed by Star on those sites.
      Without those three, I suggest that the following bytecode handlers
      would likely benefit from Star lookahead:
      
      LdaImmutableCurrentContextSlot
      LdaImmutableContextSlot
      CreateObjectLiteral
      CreateArrayLiteral
      ThrowReferenceErrorIfHole
      GetTemplateObject
      
      I also ran Octane with --noopt and got the following results.
      
      Name               Median change (95% CI)    U test result
      -----------------  ------------------------  -------------------
      Richards           +1.02% to +3.28%          improved  p=1.8e-05
      DeltaBlue          -1.47% to +0.12%          regressed p=0.05
      Crypto             -1.11% to +0.93%          inconclusive
      RayTrace           -1.10% to +0.48%          inconclusive
      EarleyBoyer        -0.25% to +1.29%          inconclusive
      RegExp             -1.46% to +0.08%          inconclusive
      Splay              -1.10% to +0.03%          inconclusive
      SplayLatency       +0.13% to +0.92%          improved  p=5.8e-05
      NavierStokes       -0.22% to +1.24%          inconclusive
      PdfJS              -0.69% to +1.04%          inconclusive
      Mandreel           -0.66% to +0.66%          inconclusive
      MandreelLatency    +0.32% to +1.77%          improved  p=0.00024
      Gameboy            -1.13% to +0.38%          inconclusive
      CodeLoad           -0.27% to +0.43%          inconclusive
      Box2D              -0.53% to +0.82%          inconclusive
      zlib               -0.19% to +0.19%          inconclusive
      Typescript         -0.23% to +0.59%          inconclusive
      Score (version 9)  -0.18% to +0.68%          inconclusive
      
      I'm somewhat puzzled by the DeltaBlue regression, since DeltaBlue
      agrees that all of the selected bytecodes are likely to precede Star,
      but overall I think this change is more benefit than harm.
      
      Change-Id: Ib9b4033f3cda273e99c9f0252d0055e203921916
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615946Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71987}
      0d30fac2
  6. 07 Jan, 2021 1 commit
  7. 17 Dec, 2020 1 commit
  8. 15 Dec, 2020 2 commits
  9. 03 Dec, 2020 1 commit
  10. 26 Nov, 2020 1 commit
  11. 24 Nov, 2020 1 commit
  12. 20 Nov, 2020 1 commit
  13. 10 Nov, 2020 2 commits
  14. 09 Nov, 2020 1 commit
  15. 06 Nov, 2020 1 commit
  16. 03 Nov, 2020 1 commit
  17. 29 Oct, 2020 1 commit
  18. 28 Oct, 2020 1 commit
    • Dan Elphick's avatar
      [builtins] Reduce table size for bytecode mappings · f35495ca
      Dan Elphick authored
      This replaces kBytecodeToBuiltinsMapping (an array with currently 549
      32-bit integers = 2196 bytes) with kWideBytecodeToBuiltinsMapping which
      is an array of uint8_t with only 183 values. The new array contains just
      the mappings from wide handlers to builtins but only once since the
      mapping is the same for extra wide handlers. (No mapping array is
      required for normal handlers since they map 1:1).
      
      This reduces d8's binary size by 2008 bytes on x64.
      
      As a result Interpreter::GetBytecodeHandler will be slightly slower than
      before, but its only use in non-test code is in
      Runtime_DebugBreakOnBytecode which does not need to be fast.
      
      Bug: v8:11066
      Change-Id: Iafc28fba2d1b62c1d49ceabe731d8b52a82dd2fd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502291
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70836}
      f35495ca
  19. 20 Oct, 2020 1 commit
  20. 14 Oct, 2020 2 commits
  21. 05 Oct, 2020 1 commit
  22. 01 Oct, 2020 1 commit
    • Dan Elphick's avatar
      [CSA] Tnodify CodeAssembler::Parameter · 74a9b9c4
      Dan Elphick authored
      CodeAssembler::Parameter now takes a Type template parameter and
      performs a checked cast to it. There is also UncheckedParameter which
      returns a TNode but doesn't check the cast. The original Parameter
      method is still there as UntypedParameter.
      
      Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the
      cast is performed inside Parameter. Since Parameter is not a macro,
      this means it cannot see the original expression or its file name and
      line number. So the error messages are vaguely useful, Parameter<T>()
      takes a SourceLocation parameter which with a default value of
      SourceLocation::Current(), which at least gives us the file name and
      line number for the error message.
      
      Bug: v8:6949, v8:10933
      Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70264}
      74a9b9c4
  23. 25 Sep, 2020 4 commits
  24. 22 Sep, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] refactor: use -tq only in filenames derived from .tq files" · 92aaace1
      Francis McCabe authored
      This reverts commit 64caf2b0.
      
      Reason for revert: Seems to be causing a failure:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      > 
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      > 
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      > 
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      TBR=jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70065}
      92aaace1
    • Tobias Tebbi's avatar
      [torque] refactor: use -tq only in filenames derived from .tq files · 64caf2b0
      Tobias Tebbi authored
      This is to establish a naming rule for Torque-generated files:
      - If the file is called foo/bar-tq..., then it is derived from a
        file foo/bar.tq
      - Otherwise it doesn't belong to a specific .tq file.
      
      So far, we attached -tq to all Torque-generated file names, where it
      sometimes corresponded to a .tq file name and sometimes not.
      It is not necessary to add -tq to file names to indicate that they are
      Torque-generated, since they are already in a directory called
      torque-generated, and we always refer to them as
      "torque-generated/filename", so there is no confusion even though some
      files now have the same name as a corresponding hand-written file, for
      example factory.cc.
      
      TBR: hpayer@chromium.org
      Bug: v8:7793
      Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70060}
      64caf2b0
  25. 08 Sep, 2020 3 commits
  26. 02 Sep, 2020 1 commit
  27. 28 Aug, 2020 1 commit
  28. 21 Aug, 2020 1 commit
  29. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored
      This patch introduces a new LocalIsolate and LocalFactory, which use
      LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
      us to remove those classes, as well as the related OffThreadSpace,
      OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
      OffThreadLogger becomes LocalLogger.
      
      LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
      us to additionally remove the concept of "Finish" and "Publish" that the
      OffThreadIsolate had, and allows us to internalize strings directly with
      the newly-concurrent string table (where the implementation can now move
      to FactoryBase).
      
      This patch also removes the off-thread support from the deserializer
      entirely, as well as removing the LocalIsolateWrapper which allowed
      run-time distinction between Isolate and OffThreadIsolate. LocalHeap
      doesn't support the reservation model used by the deserializer, and we
      will likely move the deserializer to use LocalIsolate unconditionally
      once we figure out the details of how to do this.
      
      Bug: chromium:1011762
      
      Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe