1. 18 Dec, 2019 1 commit
  2. 02 Dec, 2019 2 commits
  3. 26 Nov, 2019 1 commit
  4. 07 Nov, 2019 1 commit
    • Clemens Backes's avatar
      [wasm] Remove one {NewNativeModule} method · dde3166b
      Clemens Backes authored
      This makes the {code_size_estimate} computation explicit in the caller,
      and removes one of the two {NewNativeModule} constructors. It turns out
      that the calculation is totally off in the streaming calculation phase,
      since no function bodies have been parsed yet. So all
      {WasmFunction::code} fields are still empty, and we compute an estimate
      that is way too low.
      This CL prepares the actual fix for that (by computing a better estimate
      at specific call sites).
      
      R=ahaas@chromium.org
      
      Bug: v8:9950
      Change-Id: I68a891c97e5f65a9c7e73e21684bdfa7e261e216
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1901273
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64845}
      dde3166b
  5. 12 Sep, 2019 1 commit
  6. 27 May, 2019 1 commit
  7. 02 Apr, 2019 1 commit
  8. 25 Mar, 2019 1 commit
  9. 13 Mar, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm] Keep NativeModule alive in BackgroundCompileScope · 3df442d7
      Clemens Hammacher authored
      We need to ensure that the NativeModule stays alive while any
      {BackgroundCompileScope} exists, because during that time we hold
      shared ownership of the mutex in the {BackgroundCompileToken}. If the
      {NativeModule} dies during that period, we would need to get exclusive
      ownership of the mutex and deadlock.
      
      This change requires holding a {std::weak_ptr<NativeModule>} in the
      BackgroundCompileToken instead of a raw pointer, hence it can only be
      initialized after the NativeModule was created. This is done via a
      separate {InitCompilationState} method.
      
      R=ahaas@chromium.org
      
      Bug: v8:8979
      Change-Id: Ia14bd272ea0bc47aec547024da6020608418c9d2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518178
      Auto-Submit: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60203}
      3df442d7
  10. 25 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm] Move Isolate management to WasmEngine · a1ff298d
      Clemens Hammacher authored
      The WasmCodeManager held a list of all Isolates that use the
      WasmEngine/WasmCodeManager (those two are 1:1).
      Since we want to move all isolate-specific tasks (like code logging and
      compilation callbacks) to the WasmEngine, this CL moves this management
      from the WasmCodeManager to the WasmEngine. We now have a bidirectional
      mapping from NativeModules to the Isolates that use them, and from an
      Isolate to all the NativeModules it uses (n:n).
      The IsolateData struct will be extended in follow-up CLs to hold things
      like the ForegroundTaskRunner. The Isolate* in the NativeModule /
      CompilationState will eventually be removed.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8689
      Change-Id: Ic2c003c3949f73ce3264dd9dac96884a5c0b9896
      Reviewed-on: https://chromium-review.googlesource.com/c/1433793
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59092}
      a1ff298d
  11. 11 Jan, 2019 1 commit
  12. 21 Dec, 2018 1 commit
  13. 23 Oct, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Do not store ModuleEnv · 9716f689
      Clemens Hammacher authored
      Instead, create it when needed and pass it down to the actual
      compilation.
      This saves memory by making the WasmCompilationUnit smaller and will
      eventually allow us to implement the trap handler fallback correctly by
      using an updated ModuleEnv in background compilation and tier up.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:5277, v8:8343
      Change-Id: I0dc3a37fb88e54eb4822dc99d58ff024f4b2a367
      Reviewed-on: https://chromium-review.googlesource.com/c/1293953
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56896}
      9716f689
  14. 10 Oct, 2018 1 commit