822713 - 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)

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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?

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

We run it off the operation callback so this shouldn't happen. I think this is a JS engine bug.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So apparently there is no operation callback during regexp jitcode with yarr....  :(

Comment 3

[Alex Keybl [:akeybl]]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[Alex Keybl [:akeybl]]

Please re-nominate if there's reason to believe that this is a recent regression, or user impact has worsened recently.

Comment 6

[Andrei Purice]

Hey Boris,
Does this issue still occur for you?

Comment 7

[Iain Ireland [:iain]]

The regexp engine has been replaced twice since this bug was opened. The current engine handles interrupts during jitcode correctly.