Virtual Machine: QoS Layer
In addition to providing an isolated execution environment, The Sandbox protects against the following execution threats:
- Long-Running Blocking Code
- Deep Recursion
- Offensive Behavior (infinite alerts or prompts, inappropriate prompting)
- Extensive Timer Usage
- Multiple Reloads
- Expensive Regular Expressions (not yet implemented)
- Exception Handling
The Sandbox tracks the number of statements executed as well as the amount of time blocked during the execution of any each Sandbox instance. When the execution crosses defined thresholds, the Sandbox offers the user the opportunity to disable the execution. This action is isolated to the offending instance without impacting surrounding code.
Some behaviors are automatically blocked. For example, alerts are not permitted in response to mousemove events (coming soon), code cannot have more than a pre-defined number of active timers, etc.
Performance metrics can be codified for most behaviors except for memory consumption. The system currently does not protect against code that “slowly” builds large number of in-memory objects.
Offensive Behavior
We are building into the rules protection against offensive behavior. The challenge is defining the full set of behaviors to prevent. We started with preventing code that prompts the user too many times. We have plans to add protections against prompts in certain events (e.g., the onmousemove event). In addition, we throttle certain APIs (such as calling reload many times on yourself).
Pre-empting Long-Running Code Warnings
Most browsers have facilities for detecting long-running code. While useful for traditional web pages, these mechanisms are detrimental to mash-up applications. If any code causes the built-in browser warning to appear and the user stops execution, the entire page shuts down. In the virtual machine, we made sure to prompt the user in advance of any browser warnings giving the user the opportunity to only disable the code in question. If the user lets the code continue, at some point the browser may interject. Unfortunately there is nothing we can do to prevent this other than warn the user in our pre-emptive dialog about this scenario.
Regular Expressions
Regular expressions are currently not evaluated by the quality of service layer. Therefore, code currently can construct and execute potentially very long-running expressions. We are exploring evaluating the average cost of regular expressions prior to execution and factoring that into the quality of service decisions.
Timer Pooling
Browsers may have trouble with large number of timers. The Virtual Machine has an experimental timer pool for managing large number of very short timers (e.g., for animation). When the number of active timers grows beyond a defined threshold, the timer pool replaces them with 3 shared timers and maintains the proper callbacks. This happens transparently with no impact to the user's code. We are still fine-tuning this approach to evaluate its effectiveness in keeping the browser responsive.
Code Throttling
Any virtual machine can be paused and resumed. Pausing a virtual machine causes all execution to stop. All UI events are ignored and all timers are temporarilly disabled. If any non-UI event occurs (e.g., onload), they are cached in order fired and then executed if the code if resumed. Since these events are already asynchronous, deferring them in most cases will not cause any harm to the executing environment. The only potential side effect is the rare scenario that the callback was monitoring the time waiting for the response while paused and then acts upon it.