Closed Bug 477179 Opened 15 years ago Closed 15 years ago

Eliminate the need for a 10ms watchdog thread.

Categories

(Core :: JavaScript Engine, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.9.1b3

People

(Reporter: jst, Assigned: gal)

References

Details

(Keywords: fixed1.9.1, Whiteboard: fixed-in-tracemonkey)

This came out of a discussion earlier today between gal, bent, and myself. I'll try to summarize, but other please chime in if I overlooked something or got something wrong.

Per bug 453157 we want to get rid of the operation counting we do while on trace, and in that bug we've attempted do add a watchdog thread to replace the need for doing the operation counting we do while on trace. In that bug it's been discussed how to get the watchdog thread to work with DOM workers, which today rely on the operation callback for a number of things, yielding so GC can happen on the main thread being one of those things. Because of GC, DOM workers need to yield pretty frequently, ideally once every 10ms or so to avoid delaying GC too much, but having the watchdog thread wake up every 10ms sort of negates the performance benefits we get from eliminating the operation counting we do while on trace.

To solve this problem, we came up with a solution that lets the watchdog thread wake up much less frequently (once a second or whatever). What we'd need is to make the GC prevent us from entering the JIT on all contexts, set a stop bit on all contexts so that if we're on trace we'll fall off soon enough, and not re-enter, and then have all running contexts end up back in the interpreter and calling the operation callback as soon as possible. That way the DOM workers can yield etc. Then we'd do the GC, and reset things back to what they were and let things continue as usual. Likewise, when we transition from page to page in the browser, or close a window or what not, we'd disable the JIT for the workers that belong to that page (and are running JS at the time), set the stop bit, and that way the workers get their operation callback soon through the interpreter so they can either kill themselves, or suspend their threads or what not.

As for the main thread, it right now depends on the operation callback for 3 things:

1) calling JS_MaybeGC()
2) Memory pressure stuff for mobile
3) Slow script dialog

If the watchdog thread gets the operation callback called every so often we can deal with 1 and 3 easily (3 with the help of 477169). 2 needs to move elsewhere, ideally into the JS allocator in some shape or form, but that will be figured out in a different bug.

gal already started working on the JIT side of things, and script execution time accounting in bug 477169. bent will work on the DOM worker side of things.
Flags: blocking1.9.1+
Depends on: 477187
Priority: -- → P1
Fixed by combined patch landed for bug 477187

http://hg.mozilla.org/tracemonkey/rev/32fd75dcb1f7
Assignee: general → gal
Status: NEW → ASSIGNED
Whiteboard: fixed-in-tracemonkey
Merged
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
Flags: in-litmus-
(In reply to comment #1)
> Fixed by combined patch landed for bug 477187
> 
> http://hg.mozilla.org/tracemonkey/rev/32fd75dcb1f7

fixed1.9.1, as bug 477187 is fixed1.9.1
Keywords: fixed1.9.1
You need to log in before you can comment on or make changes to this bug.