1. 21 Feb, 2020 1 commit
  2. 19 Feb, 2020 2 commits
  3. 18 Feb, 2020 2 commits
  4. 15 Nov, 2019 1 commit
  5. 28 Oct, 2019 1 commit
  6. 25 Oct, 2019 1 commit
  7. 23 Oct, 2019 2 commits
  8. 17 Oct, 2019 1 commit
  9. 21 Aug, 2019 2 commits
  10. 05 Aug, 2019 1 commit
  11. 01 Aug, 2019 1 commit
  12. 29 Jul, 2019 3 commits
    • Clemens Hammacher's avatar
      Reland "[utils] Make BitField final" · 0cabc6a0
      Clemens Hammacher authored
      This is a reland of 658ff200
      
      Original change's description:
      > [utils] Make BitField final
      > 
      > We have hundreds of classes that derive from {BitField} without adding
      > any functionality. This CL switches all such occurrences to 'using'
      > declarations instead.
      > 
      > Before:
      >   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      > After:
      >   using MyBitField = BitField<int, 6, 4, MyEnum>;
      > 
      > This might reduce compilation time by reducing the number of existing
      > classes.
      > 
      > The old pattern is forbidden now by making {BitField} final.
      > 
      > R=yangguo@chromium.org
      > 
      > Bug: v8:9396, v8:7629
      > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62956}
      
      Bug: v8:9396, v8:7629
      Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62959}
      0cabc6a0
    • Clemens Hammacher's avatar
      Revert "[utils] Make BitField final" · 753a07db
      Clemens Hammacher authored
      This reverts commit 658ff200.
      
      Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826
      
      Original change's description:
      > [utils] Make BitField final
      > 
      > We have hundreds of classes that derive from {BitField} without adding
      > any functionality. This CL switches all such occurrences to 'using'
      > declarations instead.
      > 
      > Before:
      >   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      > After:
      >   using MyBitField = BitField<int, 6, 4, MyEnum>;
      > 
      > This might reduce compilation time by reducing the number of existing
      > classes.
      > 
      > The old pattern is forbidden now by making {BitField} final.
      > 
      > R=​yangguo@chromium.org
      > 
      > Bug: v8:9396, v8:7629
      > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62956}
      
      TBR=yangguo@chromium.org,clemensh@chromium.org
      
      Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9396, v8:7629
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62958}
      753a07db
    • Clemens Hammacher's avatar
      [utils] Make BitField final · 658ff200
      Clemens Hammacher authored
      We have hundreds of classes that derive from {BitField} without adding
      any functionality. This CL switches all such occurrences to 'using'
      declarations instead.
      
      Before:
        class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      After:
        using MyBitField = BitField<int, 6, 4, MyEnum>;
      
      This might reduce compilation time by reducing the number of existing
      classes.
      
      The old pattern is forbidden now by making {BitField} final.
      
      R=yangguo@chromium.org
      
      Bug: v8:9396, v8:7629
      Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62956}
      658ff200
  13. 27 Jun, 2019 1 commit
  14. 29 May, 2019 1 commit
  15. 24 May, 2019 1 commit
  16. 21 May, 2019 1 commit
  17. 29 Mar, 2019 1 commit
  18. 28 Jan, 2019 1 commit
  19. 25 Jan, 2019 1 commit
    • Andreas Haas's avatar
      [wasm][anyref] Support anyref stack parameters · 258371bd
      Andreas Haas authored
      Anyref parameters can exist across GC runs. Therefore the GC has to
      know where anyref parameters are on the stack so that it can mark them
      in its marking phase, and update them in the compaction phase.
      
      Already in a previous CL we grouped all anyref parameters so that they
      can be found more easily in a stack frame, see
      https://crrev.com/c/1371827. In this CL we implement the stack scanning
      itself.
      
      Note that anyref parameters are not scanned while iterating over the
      caller's frame (to which they actually belong), but while iterating
      over the callee's frame. The reason is that with tail-calls, only the
      callee knows how many tagged stack parameters (aka anyref parameters)
      there are.
      
      R=mstarzinger@chromium.org
      also-by=mstarzinger@chromium.org
      
      Bug: v8:7581
      Change-Id: I7a41ce11d06c0d420146fdb0bb8d5606f28824d7
      Reviewed-on: https://chromium-review.googlesource.com/c/1424955
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59099}
      258371bd
  20. 19 Dec, 2018 2 commits
  21. 17 Dec, 2018 2 commits
  22. 19 Nov, 2018 1 commit
  23. 18 Oct, 2018 1 commit
  24. 10 Oct, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Use a tuple as the instance for JS imports · a2b34806
      Ben L. Titzer authored
      This CL refactors the implementation of WASM->JS import wrappers in order
      to make the wrapper code shareable. Instead of specializing to the import
      index, we use a tuple as the object ref in the both the import and indirect
      tables. The tuple allows the wrapper code to load both the calling
      instance and the target callable, rather than relying on code specialization.
      
      This requires some tricky codegen machinery, because WASM call descriptors
      expect an instance argument in a given register, yet the wrappers receive
      a tuple, the code generator must generate a prologue that loads the
      instance (and the callable), since it is not possible to express this at
      the graph level.
      
      R=mstarzinger@chromium.org
      CC=clemensh@chromium.org
      
      Change-Id: Id67e307f7f5089e776f5439a53b5aee4b76934b6
      Reviewed-on: https://chromium-review.googlesource.com/c/1268237
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56520}
      a2b34806
  25. 22 Jun, 2018 1 commit
  26. 21 Jun, 2018 1 commit
  27. 18 Jun, 2018 2 commits
    • Clemens Hammacher's avatar
      Make CallInterfaceDescriptor isolate-independent · 3cb376dc
      Clemens Hammacher authored
      Currently each isolate stores its own array of
      {CallInterfaceDescriptorData}. This array has size 173, and each entry
      has 40 bytes. That's already 7kB per isolate.
      Additionally, each {CallInterfaceDescriptorData} allocates two
      heap-allocated arrays, which probably add up to more than the static
      size of the {CallInterfaceDescriptorData}. Note that all the
      {CallInterfaceDescriptorData} instances are initialized eagerly on
      isolate creation.
      
      Since {CallInterfaceDescriptor} is totally isolate independent itself,
      this CL refactors the current design to avoid a copy of them per
      isolate, and instead shares them process-wide. Still, we need to free
      the allocated heap arrays when the last isolate dies to avoid leaks.
      This can probably be refactored later by statically initializing more
      and avoiding the heap allocations all together.
      
      This refactoring will also allow us to use {CallInterfaceDescriptor}s
      from wasm background compilation threads, which are not bound to any
      isolate.
      
      R=mstarzinger@chromium.org, titzer@chromium.org
      
      Bug: v8:6600
      Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494
      Reviewed-on: https://chromium-review.googlesource.com/1100879
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53803}
      3cb376dc
    • Michael Starzinger's avatar
      [turbofan] Remove obsolete Linkage::GetAllocateCallDescriptor. · 8d82cddb
      Michael Starzinger authored
      R=ishell@chromium.org
      
      Change-Id: I84288cc16297dbe33adddbdf08b689db95d0fc04
      Reviewed-on: https://chromium-review.googlesource.com/1104164Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53786}
      8d82cddb
  28. 14 Jun, 2018 2 commits
  29. 07 May, 2018 1 commit
    • jgruber's avatar
      [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · d8131cd6
      jgruber authored
      Stubs and builtins are very similar. The main differences are that
      stubs can be parameterized and may be generated at runtime, whereas
      builtins are generated at mksnapshot-time and shipped with the snapshot
      (or embedded into the binary).
      
      My main motivation for these conversions is that we can generate
      faster calls and jumps to (embedded) builtins callees from (embedded)
      builtin callers. Instead of going through the builtins constants table
      indirection, we can simply do a pc-relative call/jump.
      
      This also unlocks other refactorings, e.g. removal of
      CallRuntimeDelayed.
      
      TBR=mlippautz@chromium.org
      
      Bug: v8:6666
      Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
      Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53027}
      d8131cd6
  30. 03 May, 2018 1 commit