1. 28 Jul, 2020 1 commit
  2. 26 May, 2020 1 commit
  3. 06 May, 2020 1 commit
  4. 14 Apr, 2020 2 commits
    • Clemens Backes's avatar
      [wasm] Store whether code was generated for debugging · 4721585b
      Clemens Backes authored
      This adds a flag to {WasmCode} objects to store whether this code was
      generated for debugging. This flag can be set for Liftoff code (in which
      case the code will e.g. have an extended prologue for debugging), but it
      can also be set for TurboFan, in case Liftoff bailed out when producing
      the debugging code.
      
      Having this flag allows us to remove the hack to pass the compilation
      results to {OnFinishedUnits} just to check whether we actually wanted to
      compile Liftoff functions.
      
      Drive-by: Replace the {ReachedRecompilationTierField} by a
      {MissingRecompilationField}, because all we need to know is if we are
      still waiting for that function to get recompiled.
      
      R=ahaas@chromium.org
      
      Bug: v8:10330,v8:10410
      Change-Id: Ia023df8955a60d9f5595a6cb2737e14d83baf716
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142259
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67119}
      4721585b
    • Clemens Backes's avatar
      [wasm][debug] Store "for debugging" flag on compilation unit · e0433f7d
      Clemens Backes authored
      Before the "debug" flag was stored on the {CompilationEnv}. But each
      background compilation task only gets the {CompilationEnv} once when
      starting compilation, so by the time it picks up the "Liftoff for
      debugging" compilation jobs, it might still compile them without the
      debug flag being set. This leads to flakes in the "debug-step-into-wasm"
      test, because we won't stop in the function prologue when stepping in
      (because the function prologue does not check the "hook on function
      call" flag if debug mode was not enabled).
      
      This CL does not increase the size of a compilation unit, since both the
      tier and the debug flag only need a single byte each.
      
      As a nice side effect, this change allows us to remove the lock in
      {CreateCompilationEnv}, because no modifyable flag is read any more.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10410
      Change-Id: Ic296ea0c4dd1d4dedde119f0536e87e5d301b5a1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144116Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67115}
      e0433f7d
  5. 05 Mar, 2020 3 commits
    • Clemens Backes's avatar
      Reland "[wasm] Further reduce the size of WasmCode" · 13cdf3a7
      Clemens Backes authored
      This is a reland of 79398ab0
      
      Original change's description:
      > [wasm] Further reduce the size of WasmCode
      >
      > Also, save dynamic allocations (plus their memory overhead).
      > This is realized by storing the relocation information, source position
      > table, and protected instruction information together in one "metadata"
      > byte array.
      > For each of the three components, we just store their size, such that
      > the accessors can return the respecitive {Vector} views as before.
      >
      > This makes each WasmCode object 24 bytes smaller on 64-bit
      > architectures. It also saves a few more bytes per code object because
      > less padding is needed for the individual allocations, and each dynamic
      > allocation comes with some constant memory overhead.
      >
      > Since the protected instructions will just be stored in a byte array
      > now, some APIs are refactored to just return that byte array directly
      > (instead of an array of {ProtectedInstructionData}). This also
      > simplifies serialization and deserialization, and will allow for
      > switching to a more compact representation in the future.
      >
      > Drive-by: Add some more checks to {Vector::cast} to protect against
      >   undefined behaviour.
      >
      > R=ahaas@chromium.org
      >
      > Bug: v8:10254
      > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66596}
      
      Tbr: ahaas@chromium.org
      Bug: v8:10254
      Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66598}
      13cdf3a7
    • Clemens Backes's avatar
      Revert "[wasm] Further reduce the size of WasmCode" · 28afd1c9
      Clemens Backes authored
      This reverts commit 79398ab0.
      
      Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10186
      
      Original change's description:
      > [wasm] Further reduce the size of WasmCode
      > 
      > Also, save dynamic allocations (plus their memory overhead).
      > This is realized by storing the relocation information, source position
      > table, and protected instruction information together in one "metadata"
      > byte array.
      > For each of the three components, we just store their size, such that
      > the accessors can return the respecitive {Vector} views as before.
      > 
      > This makes each WasmCode object 24 bytes smaller on 64-bit
      > architectures. It also saves a few more bytes per code object because
      > less padding is needed for the individual allocations, and each dynamic
      > allocation comes with some constant memory overhead.
      > 
      > Since the protected instructions will just be stored in a byte array
      > now, some APIs are refactored to just return that byte array directly
      > (instead of an array of {ProtectedInstructionData}). This also
      > simplifies serialization and deserialization, and will allow for
      > switching to a more compact representation in the future.
      > 
      > Drive-by: Add some more checks to {Vector::cast} to protect against
      >   undefined behaviour.
      > 
      > R=​ahaas@chromium.org
      > 
      > Bug: v8:10254
      > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66596}
      
      TBR=jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,tebbi@chromium.org
      
      Change-Id: Id80aa82cfce8942879031032b322ee66855b5600
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10254
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089933Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66597}
      28afd1c9
    • Clemens Backes's avatar
      [wasm] Further reduce the size of WasmCode · 79398ab0
      Clemens Backes authored
      Also, save dynamic allocations (plus their memory overhead).
      This is realized by storing the relocation information, source position
      table, and protected instruction information together in one "metadata"
      byte array.
      For each of the three components, we just store their size, such that
      the accessors can return the respecitive {Vector} views as before.
      
      This makes each WasmCode object 24 bytes smaller on 64-bit
      architectures. It also saves a few more bytes per code object because
      less padding is needed for the individual allocations, and each dynamic
      allocation comes with some constant memory overhead.
      
      Since the protected instructions will just be stored in a byte array
      now, some APIs are refactored to just return that byte array directly
      (instead of an array of {ProtectedInstructionData}). This also
      simplifies serialization and deserialization, and will allow for
      switching to a more compact representation in the future.
      
      Drive-by: Add some more checks to {Vector::cast} to protect against
        undefined behaviour.
      
      R=ahaas@chromium.org
      
      Bug: v8:10254
      Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66596}
      79398ab0
  6. 27 Feb, 2020 1 commit
  7. 26 Feb, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Reduce size of {WasmCode} objects · c626bc5e
      Clemens Backes authored
      This is a first step to make {WasmCode} objects smaller. Many code
      offsets are currently stored in {size_t} even though there were
      originally (during assembly) an int. Others are stored in {uint32_t}.
      
      This CL switches the function index and all code lengths and offsets to
      int, because
      a) bigger code is not supported anyway, and
      b) the style guide recommends int over unsigned types.
      
      This makes the {WasmCode} 24 bytes smaller on x64 (from 144 to 120
      bytes).
      
      R=ahaas@chromium.org
      
      Bug: v8:10254
      Change-Id: I8f78bf4be64d59cf9393e3b6662d9d3bd153d387
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074217Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66462}
      c626bc5e
  8. 09 Jan, 2020 1 commit
  9. 13 Nov, 2019 1 commit
  10. 13 Sep, 2019 1 commit
  11. 30 Jul, 2019 1 commit
  12. 29 Jul, 2019 2 commits
  13. 25 Jul, 2019 2 commits
  14. 16 Jul, 2019 2 commits
    • Thibaud Michaud's avatar
      Revert "reland [wasm] Compile JS to WASM wrappers asynchronously" · fac5898d
      Thibaud Michaud authored
      This reverts commit 117ddc8f.
      
      Reason for revert: The isolate is needed for accessing builtins, and can die during async compilation.
      
      Original change's description:
      > reland [wasm] Compile JS to WASM wrappers asynchronously
      > 
      > The context was not set during streaming compilation.
      > The initial upload is the original CL and patch set 1 is the fix.
      > 
      > Original CL:
      > 
      > > [wasm] Compile JS to WASM wrappers asynchronously
      > >
      > > R=mstarzinger@chromium.org, ahaas@chromium.org
      > >
      > > Bug: v8:9231
      > > Change-Id: I9e18073bbe25bf8c9c5f9ace102316e6209d0459
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669699
      > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#62672}
      > 
      > R=​mstarzinger@chromium.org, ahaas@chromium.org
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
      > Bug: v8:9231
      > Change-Id: I61fc11a6de54cc6e93f3600487a89fa5d2350f0e
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701850
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > Auto-Submit: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62721}
      
      TBR=mstarzinger@chromium.org,ahaas@chromium.org,thibaudm@chromium.org
      
      Change-Id: Ie258317f04a944e8e08993dbffb524f722cceddc
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9231
      Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704094Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62741}
      fac5898d
    • Simon Zünd's avatar
      [wasm] Fix alloc/dealloc size mismatch for WasmInstructionBuffer · 8ae4143a
      Simon Zünd authored
      On newer compilers the {operator delete} with explicit {size_t}
      argument would be instantiated for {WasmInstructionBuffer} and used
      in the destructor of {std::unique_ptr<WasmInstructionBuffer>}. The
      {size_t} argument is wrong though, since the pointer actually points
      to a {WasmInstructionBufferImpl} object.
      The solution is to explicitly provide a {operator delete}, preventing
      an implicitly generated {size_t} operator.
      
      R=clemensh@chromium.org
      
      Change-Id: I2cc22078d03a523121309bae94f5b612cb98e112
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702613Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62737}
      8ae4143a
  15. 15 Jul, 2019 1 commit
  16. 12 Jul, 2019 2 commits
  17. 18 Jun, 2019 1 commit
  18. 05 Jun, 2019 1 commit
    • Thibaud Michaud's avatar
      [wasm] Early compilation of import wrappers · b15b2c91
      Thibaud Michaud authored
      Compile import wrappers during module compilation by introducing import
      wrapper compilation units, the goal being to reduce instantiation time.
      
      For each wrapper, we assume the imported function is going to be a
      kJSFunctionArityMatchSloppy at instantiation time, which should be the
      most common case. If the function turns out to have a different kind the
      wrapper is going to be recompiled with the correct kind during instantiation.
      
      R=ahaas@chromium.org, clemensh@chromium.org
      CC=titzer@chromium.org
      
      Bug: v8:9231
      Change-Id: Ieb050b09d1c19f2a5a3e59132a1864dadb06775d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630685
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61993}
      b15b2c91
  19. 22 May, 2019 3 commits
    • Clemens Hammacher's avatar
      Reland "[wasm] Compile big functions first" · 5d0b4ad6
      Clemens Hammacher authored
      This is a reland of 2ce5da9a
      
      Original change's description:
      > [wasm] Compile big functions first
      >
      > Add a special queue to {CompilationUnitQueues} to handle big functions
      > specially. They are organized in a priority queue (ordered by their
      > body size), and all threads check this queue first, before executing
      > the tasks from their own queue. In some benchmarks, this shortens
      > overall compilation time by 10-20 percent.
      >
      > R=ahaas@chromium.org
      >
      > Bug: v8:8916, chromium:950493
      > Change-Id: I45f36a05304e2f1c4f3ce6b8821ddd4bd08fbba3
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1622122
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61746}
      
      Bug: v8:8916, chromium:950493
      No-Presubmit: true
      Change-Id: I26c949ce6a0f5efee684561dc0b4eba44921cddf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624799
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61755}
      5d0b4ad6
    • Clemens Hammacher's avatar
      Revert "[wasm] Compile big functions first" · a69be08a
      Clemens Hammacher authored
      This reverts commit 2ce5da9a.
      
      Reason for revert: Fails on several bots, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/26607
      
      Original change's description:
      > [wasm] Compile big functions first
      > 
      > Add a special queue to {CompilationUnitQueues} to handle big functions
      > specially. They are organized in a priority queue (ordered by their
      > body size), and all threads check this queue first, before executing
      > the tasks from their own queue. In some benchmarks, this shortens
      > overall compilation time by 10-20 percent.
      > 
      > R=​ahaas@chromium.org
      > 
      > Bug: v8:8916, chromium:950493
      > Change-Id: I45f36a05304e2f1c4f3ce6b8821ddd4bd08fbba3
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1622122
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61746}
      
      TBR=ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: Ib47b23ff878d4a561df1993d532e5eeafea64ff6
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8916, chromium:950493
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624797Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61749}
      a69be08a
    • Clemens Hammacher's avatar
      [wasm] Compile big functions first · 2ce5da9a
      Clemens Hammacher authored
      Add a special queue to {CompilationUnitQueues} to handle big functions
      specially. They are organized in a priority queue (ordered by their
      body size), and all threads check this queue first, before executing
      the tasks from their own queue. In some benchmarks, this shortens
      overall compilation time by 10-20 percent.
      
      R=ahaas@chromium.org
      
      Bug: v8:8916, chromium:950493
      Change-Id: I45f36a05304e2f1c4f3ce6b8821ddd4bd08fbba3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1622122Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61746}
      2ce5da9a
  20. 21 May, 2019 1 commit
  21. 30 Apr, 2019 1 commit
  22. 29 Apr, 2019 3 commits
  23. 10 Apr, 2019 1 commit
  24. 02 Apr, 2019 1 commit
  25. 01 Apr, 2019 2 commits
  26. 27 Mar, 2019 1 commit
  27. 19 Mar, 2019 1 commit
  28. 14 Mar, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm] Make error messages deterministic · eb1d2d70
      Clemens Hammacher authored
      Compilation only stores whether an error has been found, but not the
      exact error or it's location. This is generated by running a validation
      pass once all wire bytes have been received.
      This unifies error messages by removing one more location where we
      generate compilation error messages, and makes it deterministic because
      a) we always report the error in the first failing function, and
      b) if names are present, the error message will always contain the
         function name.
      
      R=titzer@chromium.org
      
      Bug: chromium:926311, v8:8814
      Change-Id: I79551b8bb73dcee503484de343a3ada60a6add4f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1521112
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60242}
      eb1d2d70