See the process sample in attachment 693265 [details]. It shows the main thread under CollectRuntimeStatsRunnable::DispatchInternal waiting on a condvar while the worker is under js::RegExpShared::execute in what looks like regexp jitcode for the whole time. Bug 822407 comment 9 indicates that this state lasted for 23 minutes(!), which is ... rather unacceptable. Ben, do we wait until we get back to the worker event loop to process the memory reporter runnable? Or do we do it off the operation callback? In the latter case, is the problem perhaps that regexp jitcode doesn't fire operation callbacks?
6 years ago
tracking-firefox18: --- → ?
tracking-firefox19: --- → ?
tracking-firefox20: --- → ?
We run it off the operation callback so this shouldn't happen. I think this is a JS engine bug.
Assignee: nobody → general
So apparently there is no operation callback during regexp jitcode with yarr.... :(
FF17 appears to be affected so wontfixing for FF18 given where we are in the cycle. Is this even a FF17 regression? If not, this isn't a release tracking issue.
status-firefox17: --- → affected
status-firefox18: --- → wontfix
tracking-firefox18: ? → -
It's a regression probably from whenever we stopped firing the operation callback for regexps or started doing telemetry memory reporting, whichever came later.... I don't know offhand when those happened.
6 years ago
Please re-nominate if there's reason to believe that this is a recent regression, or user impact has worsened recently.
tracking-firefox19: ? → -
tracking-firefox20: ? → -
Summary: Memory reporting for telemetry can cause the main thread to block on workers for an arbitrary amount of time → JS RegExp doesn't call the operation callback (was: Memory reporting for telemetry can cause the main thread to block on workers for an arbitrary amount of time)
You need to log in before you can comment on or make changes to this bug.