870541 - B2G: Slow script mechanism uses wall clock time, could cause lower priority background processes to have scripts aborted

Status: RESOLVED INCOMPLETE

(Core :: XPConnect, defect, P2)

Description

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

While chatting about bug 870043 jlebar realized that we could be shooting ourselves in the foot here. The slow script mechanism uses wall clock time and that could cause lower priority background processes to have their scripts aborted even though they haven't really run for very long. We need something better, maybe counting js instructions or per-thread CPU time?

Comment 1

[Justin Lebar (not reading bugmail)]

Since nobody looks at the "Platform" field: This bug is specifically about b2g.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

This sounds like a useful enhancement but not something we'd block release on without partner request for it.  We can track, and look at an uplift nomination when one is ready.  Also putting c= to get this into scrum backlog.

Comment 3

[Hubert Figuiere [:hub]]

I can have a look at this one.

Comment 4

[Hubert Figuiere [:hub]]

Ben,

Since bug 870043 comment 31, the slow script watchdog has been disabled on B2G. Is that bug still valid?

Comment 5

[Johnny Stenback (:jst)]

My understanding was that it was disabled on the b2g-18 branch but it's still enabled for b2g on trunk, and will remain so after bholley fixes up the watchdog mechanism in bug 870043.

Comment 6

[Bobby Holley (:bholley)]

(In reply to Johnny Stenback (:jst, [e-mail]) from comment #5)
> My understanding was that it was disabled on the b2g-18 branch but it's
> still enabled for b2g on trunk, and will remain so after bholley fixes up
> the watchdog mechanism in bug 870043.

Yeah. That bug is just waiting for inbound to open, and then it'll land.

Comment 7

[Hubert Figuiere [:hub]]

Do we have a JS "tick" that would be available to use? I couldn't find anything in the documentation or the code.

Nor could I find something that could give me the "cpu time" in the thread APIs.

Comment 8

[Hubert Figuiere [:hub]]

Bobby, do you have an idea or do you know who might have? (comment 7)

Thanks.

Comment 9

[Bobby Holley (:bholley)]

I have no idea. Kyle might know.

Comment 10

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I don't understand the question.  What does "tick" mean?

Comment 11

[Hubert Figuiere [:hub]]

Tick is something about elapsed time (clock ticking). I don't really know how you'd call it.

To know if the JS runtime has done something, unrelated to actual elapsed time from the clock, because we my not run all the time.

Comment 12

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Ok, you should ask the JS team then.  Not sure why bholley needinfoed me ...

Comment 13

[Brian Hackett [Laid off!]]

The JS engine doesn't really have a way to measure time than actual elapsed time.

Comment 14

[Hubert Figuiere [:hub]]

Thanks. I was afraid that this was the case.

Comment 15

[Hubert Figuiere [:hub]]

I think it is a bit out of are of expertise and think that this should be handled by the JS team.

Comment 16

[Mason Chang [Inactive] [:mchang]]

Hi Ben, since bug 870043 resolved some of the watchdog timer issues, is this bug still an issue?

Comment 17

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

Yes, as far as I know the issue is unresolved. The slow script dialog relies on wall clock time and we have no way to know if any actual work was done between two arbitrary wall clock times.