1132511 - consider more efficient mechanism for Urgent interrupt requests on the main thread

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Luke Wagner [:luke]]

For requestInterrupt(Urgent) on the main thread, we call patchIonBackedges which is O(amount of Ion code in the runtime).  The goal is that this only happens infrequently and only for long-running scripts (to throw up the slow script dialog), but I just noticed it is also used to request major and minor GCs.  For normal browsing, this isn't a problem b/c there is very little live Ion code at any time so patchIonBackedges usually takes <1us.  However, if I run larger handwritten JS games like quakejs.com (which use requestAnimationFrame which keeps Ion code alive), I can see periodic calls to patchIonBackedges taking 700us which is starting to become significant.  On Octane, to total time spent in patchIonBackedges is 10ms (for a whole run in the browser) which I guess is pretty low.

If we wanted to fix this, an alternative would be to patch in an interrupt call kindof like we do for OSI: use the innermost Ion activation to patch in an interrupt call right after the return.  Alternatively, since calls to C++ aren't super-fast anyway, we could just emit an interrupt or stackLimit check somewhere in the call path and see if there is any measurable slowdown.

Comment 1

[Jan de Mooij [:jandem]]

(In reply to Luke Wagner [:luke] from comment #0)
> The goal is that this only
> happens infrequently and only for long-running scripts (to throw up the slow
> script dialog), but I just noticed it is also used to request major and
> minor GCs.

I fixed this in bug 1233818 (for W^X). We no longer use implicit interrupt checks for loops that can trigger/affect GC, and therefore the GC no longer has to request urgent interrupts.