| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Review requested:
|
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
|
I'll remove the reverts because the tests are still failing. |
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Original commit message:
[wasm] Simplify CompileJSToWasmWrapperJob
This CL merges some of AsyncCompileJSToWasmWrapperJob and
CompileJSToWasmWrapperJob into a common base class. Both jobs now
loop on a vector with an atomic index.
Bug: chromium:1423615
Change-Id: I7bb9cb2a57d8b659766c01e20e38d1b859d3a987
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4347597
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/main@{#86675}
Refs: v8/v8@a8a11a8
Original commit message:
[wasm] Fix deadlock in async wrapper compilation
If compilation is cancelled while wrapper compilation is running, the
tasks spawned for the {AsyncCompileJSToWasmWrapperJob} will return
immediately, but {GetMaxConcurrency} will still return a positive
value. Hence {Join()} will spawn another task, resulting in a
livelock.
We could fix this by checking for cancellation in {GetMaxConcurrency},
but that requires taking the compilation state lock.
So this CL fixes the issue by dropping the number of outstanding
compilation units by to (basically) zero. We can't unconditionally drop
to zero because another thread might concurrently execute a wrapper
compilation and still call {CompleteUnit} afterwards. Hence only drop
outstanding units by the amount of not-yet-started units.
R=jkummerow@chromium.org
Bug: v8:13858
Change-Id: I5398ef370da2e7f212ca772fd1f87f659929dd6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4437531
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87143}
Refs: v8/v8@5f025d1
|
rebased |
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Original commit message:
[wasm] Simplify CompileJSToWasmWrapperJob
This CL merges some of AsyncCompileJSToWasmWrapperJob and
CompileJSToWasmWrapperJob into a common base class. Both jobs now
loop on a vector with an atomic index.
Bug: chromium:1423615
Change-Id: I7bb9cb2a57d8b659766c01e20e38d1b859d3a987
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4347597
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/main@{#86675}
Refs: v8/v8@a8a11a8
PR-URL: #47610
Refs: #47297
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[wasm] Fix deadlock in async wrapper compilation
If compilation is cancelled while wrapper compilation is running, the
tasks spawned for the {AsyncCompileJSToWasmWrapperJob} will return
immediately, but {GetMaxConcurrency} will still return a positive
value. Hence {Join()} will spawn another task, resulting in a
livelock.
We could fix this by checking for cancellation in {GetMaxConcurrency},
but that requires taking the compilation state lock.
So this CL fixes the issue by dropping the number of outstanding
compilation units by to (basically) zero. We can't unconditionally drop
to zero because another thread might concurrently execute a wrapper
compilation and still call {CompleteUnit} afterwards. Hence only drop
outstanding units by the amount of not-yet-started units.
R=jkummerow@chromium.org
Bug: v8:13858
Change-Id: I5398ef370da2e7f212ca772fd1f87f659929dd6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4437531
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87143}
Refs: v8/v8@5f025d1
PR-URL: #47610
Refs: #47297
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[wasm] Simplify CompileJSToWasmWrapperJob
This CL merges some of AsyncCompileJSToWasmWrapperJob and
CompileJSToWasmWrapperJob into a common base class. Both jobs now
loop on a vector with an atomic index.
Bug: chromium:1423615
Change-Id: I7bb9cb2a57d8b659766c01e20e38d1b859d3a987
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4347597
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/main@{#86675}
Refs: v8/v8@a8a11a8
PR-URL: #47610
Refs: #47297
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[wasm] Fix deadlock in async wrapper compilation
If compilation is cancelled while wrapper compilation is running, the
tasks spawned for the {AsyncCompileJSToWasmWrapperJob} will return
immediately, but {GetMaxConcurrency} will still return a positive
value. Hence {Join()} will spawn another task, resulting in a
livelock.
We could fix this by checking for cancellation in {GetMaxConcurrency},
but that requires taking the compilation state lock.
So this CL fixes the issue by dropping the number of outstanding
compilation units by to (basically) zero. We can't unconditionally drop
to zero because another thread might concurrently execute a wrapper
compilation and still call {CompleteUnit} afterwards. Hence only drop
outstanding units by the amount of not-yet-started units.
R=jkummerow@chromium.org
Bug: v8:13858
Change-Id: I5398ef370da2e7f212ca772fd1f87f659929dd6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4437531
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87143}
Refs: v8/v8@5f025d1
PR-URL: #47610
Refs: #47297
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
| Back | FazBrowse Home | New Git URL |
The first commit is just to avoid conflicts with the second one which contains the fix.
Refs: #47297