Bug 26025

Summary: Provide a way to interrupt JavaScript execution immediately
Product: WebKit Reporter: Cameron Zwarich (cpst) <zwarich>
Component: JavaScriptCoreAssignee: Cameron Zwarich (cpst) <zwarich>
Status: RESOLVED INVALID    
Severity: Normal CC: ap, darin, ddkilzer, ggaren, mjs
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
Proposed patch none

Description Cameron Zwarich (cpst) 2009-05-26 11:01:20 PDT
A client of WebKit might wish to interrupt JavaScript execution immediately instead of waiting for the usual timeout.
Comment 1 Cameron Zwarich (cpst) 2009-05-26 11:01:54 PDT
<rdar://problem/6912786>
Comment 2 Cameron Zwarich (cpst) 2009-05-26 11:17:11 PDT
Created attachment 30674 [details]
Proposed patch
Comment 3 Darin Adler 2009-05-26 12:59:37 PDT
Comment on attachment 30674 [details]
Proposed patch

I believe the reason we originally called shouldInterruptScript only at the timeout was to avoid slowing down the engine with constant calls to the virtual function. I suppose that's why this new feature is opt-in.

Geoff, what kind of testing would we do to see what effect this has on performance?

The function name isStopping() doesn't seem specific to JavaScript, yet the behavior implemented is JavaScript-only.
Comment 4 Cameron Zwarich (cpst) 2009-05-26 13:14:21 PDT
(In reply to comment #3)
> (From update of attachment 30674 [details] [review])
> I believe the reason we originally called shouldInterruptScript only at the
> timeout was to avoid slowing down the engine with constant calls to the virtual
> function. I suppose that's why this new feature is opt-in.

Yes. Using this feature will induce two virtual calls at every timeout check, so it is opt-in. I am hoping that after merging this change I might be able to convert it to a single memory access in TimeoutChecker.

> Geoff, what kind of testing would we do to see what effect this has on
> performance?

I could implement it in the Mac ChromeClient and run SunSpider in the browser before and after. However, the benefits of being able to stop JS from blocking the main thread sometimes outweigh raw JS performance.

> The function name isStopping() doesn't seem specific to JavaScript, yet the
> behavior implemented is JavaScript-only.

The isStopping() ChromeClient call is used for one other purpose in our tree, immediately stopping HTML parsing on stopping a load. I could separate these two if you prefer; otherwise the isStopping() name matches isStopping() elsewhere, which means stopping a load.
Comment 5 Geoffrey Garen 2009-05-26 16:15:17 PDT
> Geoff, what kind of testing would we do to see what effect this has on
> performance?

As long as there's an empty virtual function in the default client, we can test using SunSpider.

Because we only make this call about twice every ten seconds, there's a good chance that it won't hurt performance too much. On the other hand, there's a good chance that it won't accomplish its goal, either.
Comment 6 Alexey Proskuryakov 2009-05-27 04:27:49 PDT
This isn't exposed to WebKit clients, but workers already have a way to interrupt javascript execution (almost) immediately, see WorkerScriptController::forbidExecution().
Comment 7 Cameron Zwarich (cpst) 2009-06-02 21:34:29 PDT
The code that Alexey suggested gives a much better way of solving this problem. I'll close this bug and open a new one with a different patch some time in the future.
Comment 8 Alexey Proskuryakov 2009-06-03 05:48:29 PDT
Comment on attachment 30674 [details]
Proposed patch

Clearing review flag to get this out of queue.