1. 21 Jul, 2020 1 commit
  2. 20 Jul, 2020 2 commits
  3. 14 Jul, 2020 2 commits
  4. 09 Feb, 2020 1 commit
    • Michael Achenbach's avatar
      Revert "[weakrefs] Schedule FinalizationGroup cleanup tasks from within V8" · 72fc962b
      Michael Achenbach authored
      This reverts commit 31d8ff7a.
      
      Reason for revert: https://crbug.com/v8/10190
      
      Original change's description:
      > [weakrefs] Schedule FinalizationGroup cleanup tasks from within V8
      > 
      > Deprecate the following explicit FinalizationGroup APIs in favor of
      > automatic handling of FinalizationGroup cleanup callbacks:
      >   - v8::Isolate::SetHostCleanupFinalizationGroupCallback
      >   - v8::FinaliationGroup::Cleanup
      > 
      > If no HostCleanupFinalizationGroupCallback is set, then
      > FinalizationGroup cleanup callbacks are automatically scheduled by V8
      > itself as non-nestable foreground tasks.
      > 
      > When a Context being disposed, all FinalizationGroups that are
      > associated with it are removed from the dirty list, cancelling
      > scheduled cleanup.
      > 
      > Bug: v8:8179
      > Change-Id: Ic09313a11dd00af36d1f698250b3d735155f45e8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986392
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66184}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,syg@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:8179
      Change-Id: If7869e9a5841803c10e748691f019a7d28f3b62e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043807Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66190}
      72fc962b
  5. 08 Feb, 2020 1 commit
  6. 24 May, 2019 1 commit
  7. 18 Jan, 2019 1 commit
  8. 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
  9. 12 Nov, 2018 1 commit
  10. 09 Nov, 2018 5 commits
  11. 08 Nov, 2018 1 commit
  12. 12 Oct, 2018 1 commit
  13. 04 Oct, 2018 1 commit
  14. 12 Jul, 2018 1 commit
  15. 02 Aug, 2017 1 commit
  16. 26 May, 2017 1 commit
  17. 05 Jan, 2017 1 commit
  18. 04 Jan, 2017 1 commit
  19. 03 Jan, 2017 3 commits
  20. 27 Oct, 2016 1 commit
  21. 17 Oct, 2016 1 commit
  22. 14 Oct, 2016 1 commit
  23. 13 Oct, 2016 2 commits
  24. 10 May, 2016 1 commit
  25. 09 May, 2016 1 commit
  26. 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
  27. 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
  28. 30 Jul, 2015 1 commit
  29. 20 Jul, 2015 1 commit