1. 17 Jan, 2019 1 commit
    • Andreas Haas's avatar
      [wasm] Reschedule compilation tasks · 62fa0487
      Andreas Haas authored
      At the moment, the whole WebAssembly compilation may run in a single
      background task. On a low-end device, this can mean that the background
      thread is busy for seconds and thereby blocks other tasks, see e.g.
      https://crbug.com/914757.
      
      With this CL we re-schedule compilation tasks after every 50ms. These
      50ms are an arbitrary number. I don't want to introduce too much
      overhead, but since this is in the background we also don't have to
      make tasks super short.
      
      Tasks which are going to compile with TurboFan will be posted with
      lower priority.
      
      This change requires changes in the CancelableTaskManager. At the
      moment it is not possible that a background task posts a new task
      which is managed by the same task manager as itself. The problem is
      about how to deal with another thread which calls CancelAndWait
      concurrently. At the moment, if a new task gets posted after the call
      to CancelAndWait, then `CHECK(!canceled_)` in
      CancelableTaskManager::Register will fail. If we used a lock to
      synchronize the calls to CancelAndWait and Register, then there would
      be a deadlock, where the thread which calls CancelAndWait waits for
      the task which wants to call Register, but at the same time blocks that
      task by holding the lock.
      
      With the change here, posting a task after the call to CancelAndWait
      will just immediately cancel the new task. This matches the behavior
      you would get if CancelAndWait is called right after calling Register.
      
      Bug: chromium:914757
      Change-Id: I6d57aba161db8a915ec0d745658e0c28d25219a8
      Reviewed-on: https://chromium-review.googlesource.com/c/1411884
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58898}
      62fa0487
  2. 09 Nov, 2018 3 commits
  3. 08 Nov, 2018 1 commit
  4. 12 Oct, 2018 1 commit
  5. 19 Mar, 2018 1 commit
  6. 02 Aug, 2017 1 commit
  7. 26 May, 2017 1 commit
  8. 04 Jan, 2017 1 commit
  9. 03 Jan, 2017 3 commits
  10. 11 Nov, 2016 1 commit
  11. 27 Oct, 2016 1 commit
  12. 14 Oct, 2016 1 commit
  13. 13 Oct, 2016 2 commits
  14. 10 May, 2016 1 commit
  15. 19 Nov, 2015 1 commit
    • mlippautz's avatar
      Fix protocol for aborting and waiting for cancelable tasks. · a698fd84
      mlippautz authored
      Since {CancelAndWait} blocks on the tasks that are still present in the internal
      hashmap, we are not allowed to remove the task upon trying to cancel it using
      {TryAbort}.
      
      The previous implementation suffered from a bug where:
      1) The task was created and handed over to the platform.
      2) The task was started by the platform, setting it to running state.
      3) We called {TryAbort}, effectively removing it from the manager, but failing
         to cancel (as it was already running)
      4) All tasks finished running, indicating this with their own semaphore.
      5) The platform was stuck (scheduling) before destroying the task.
      6) Main thread finished its work, waiting for all the necessary tasks, and the
         isolate terminated.
      7) The platform destroyed the task, calling the destructor, calling into an
         already freed isolate.
      
      BUG=chromium:524425
      LOG=N
      
      Review URL: https://codereview.chromium.org/1460763004
      
      Cr-Commit-Position: refs/heads/master@{#32118}
      a698fd84
  16. 14 Nov, 2015 1 commit
    • mlippautz's avatar
      Add {CancelableTaskManager} to handle {Cancelable} concurrent tasks. · 60e7ea8a
      mlippautz authored
      This change binds each {Cancelable} task to a so-called {CancelableTaskManager},
      which is then used to handle concurrent cancelation as well as synchronizing
      shutdown for already running tasks.  Since ownership of tasks is transferred to
      the platform executing a task (destructor), handling in the manager uses integer
      ids. Note that this also mitigates (modulo integer size) the ABA problem.
      
      All handling of {Cancelable} tasks is now encapsulated into the corresponding
      manager, which is instantiated for each isolate.
      
      R=hpayer@chromium.org
      BUG=chromium:524425
      LOG=N
      CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg;tryserver.v8:v8_linux_gc_stress_dbg;tryserver.v8:v8_mac_gc_stress_dbg;tryserver.v8:v8_linux64_msan_rel;tryserver.v8:v8_linux64_tsan_rel;tryserver.v8:v8_mac64_asan_rel
      
      Review URL: https://codereview.chromium.org/1409993012
      
      Cr-Commit-Position: refs/heads/master@{#31997}
      60e7ea8a
  17. 01 Sep, 2015 1 commit
  18. 20 Aug, 2015 1 commit
  19. 30 Jul, 2015 1 commit
  20. 20 Jul, 2015 1 commit