Unfortunately this is preventing us from releasing our product with WebAssembly. Is there any additional information needed from us?

Our unity webgl game is experiencing the exact same issue after chrome updated. We don't want to go back to asm builds because performance is way better in wasm. Let's hope this bug gets squashed rather soon.

Moved issue v8:8549 to now be  issue chromium:914757 .

The symptoms look like that streaming compilation is not used. Ahaas@ could you please take a look?

The problem seems to be that we run the optimizing compiler with a too high priority and thereby blocks audio playback. I made a prototype to test my theory, and it seems that if we compile with lower priority, the problem is fixed.

I don't think I can fix the problem before Christmas vacation because it requires changes to the API.

Thanks for the work on this. Just curious if there's any update that can be shared? 

@ #8: We know the problem, but we are still discussing the best way to fix it. It is hard to estimate the side effects of fixing it, and also the complexity of fixing it. The plan is to have the fix in M73, which will branch in 2 weeks.

Thanks for the update! It's helpful to know it's moving through the pipeline. 

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/62fa048749c727b3564aabfb84f9724979a281ab

commit 62fa048749c727b3564aabfb84f9724979a281ab
Author: Andreas Haas <ahaas@chromium.org>
Date: Thu Jan 17 18:27:08 2019

[wasm] Reschedule compilation tasks

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: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58898}
[modify] https://crrev.com/62fa048749c727b3564aabfb84f9724979a281ab/src/cancelable-task.cc
[modify] https://crrev.com/62fa048749c727b3564aabfb84f9724979a281ab/src/cancelable-task.h
[modify] https://crrev.com/62fa048749c727b3564aabfb84f9724979a281ab/src/wasm/module-compiler.cc
[modify] https://crrev.com/62fa048749c727b3564aabfb84f9724979a281ab/test/unittests/cancelable-tasks-unittest.cc

I think this issue is fixed now. The fix landed in 73.0.3677.0, and I verified it in 73.0.3679.0.

lincoln.coe@imaginelearning.com, does it work for you as well?

This is working for us in Version 73.0.3680.0

Thanks!