|Product:||WebKit||Reporter:||Craig Hockenberry <craig.hockenberry>|
|Severity:||Enhancement||CC:||ap, ben, code, ehsan, emacemac7, evanchaney, jonlee, ljharb, m.goleb+bugzilla, mjs, mmaxfield, prasanthv, rik, simon.fraser, slightlyoff, tomac, wgcorrea|
|Version:||Safari Technology Preview|
Description Craig Hockenberry 2019-01-30 10:31:26 PST
Comment 1 Craig Hockenberry 2019-01-30 10:43:13 PST
Comment 2 Simon Fraser (smfr) 2019-01-30 13:02:16 PST
It's really hard to impose CPU limits unless you run JS in a separate thread or process, to which you can assign priority. Doing so is something we've thought about, but it's a large engineering effort. It's possible we could track memory use on a per-document basis, but there are all sorts of code paths that can trigger memory use (often by code not controlled by webkit), and again it's hard to track all that.
Comment 3 Maciej Stachowiak 2019-01-30 22:51:55 PST
Comment 4 Craig Hockenberry 2019-01-30 23:23:46 PST
This bug report got a bit of attention on Twitter thanks to Eric Meyer. One of the good things to come from that is learning that Alex Russell is prototyping this idea in Chromium: https://chromium-review.googlesource.com/c/chromium/src/+/1265506
Comment 5 Craig Hockenberry 2019-01-30 23:30:30 PST
Forgot to include the Twitter thread: https://twitter.com/ppk/status/1090696014124716033
Comment 6 Maciej Stachowiak 2019-01-31 16:26:33 PST
Out of the various possible resource limits, I believe Alex's branch implements a limit on the input size of resources, but not runtime memory or CPU usage. Probably indirectly helps with bandwidth and load time, despite not directly targeting it. As other prior art, Firefox at one point planned to block resources that are known trackers and which take more than a given amount of time to load. This is another possibility for resource limits.
Comment 7 Alex Russell 2019-02-01 22:40:39 PST
Hey all, My branch doesn't limit memory, but it applies a break on main-thread CPU in the form of a long-task limit. Currently, if you enable NSM, the entire page gets paused (no further tasks run until next input) if an individual main-thread script takes more than 200ms. This number is a total guess! It could be too high, or too low, and it doesn't do anything to limit recurring timers (a worry I don't have a reasonable approach for yet). It also doesn't apply any limits to script (or resources) in workers. The primary goal is to keep the main thread clean and create an opportunity to flag "this page is slow" UI of some sort (totally TBD). I'm also unsure how to limit memory in an effective way without totally kneecapping games and implicating the graphics stack in hard-to-reason-about ways. One of the unstated goals of NSM is to create a uniform policy, akin to TLS lock icon badging, that developers can easily understand compliance with at development time. Would very much like to discuss tradeoffs if folks are interested!