1. Caching, content-distribution-networks, and possibly shared-libraries could solve or at least ameliorate this.
2. This is relatively easy. The sandboxed code could "open" handles by calling into an API, and the code could "close" them when no longer needed.
3. In many cases, the GC is tied intimately to the semantics of the language, so enforcing a style of GC could be too limiting in terms of performance. Instead, it could be better to implement a GC'ed VM on top of the low-level one.
The biggest problem is to get something like this turned into a standard, and accepted in all browsers. Perhaps a viable route is to write the standard of this low-level virtual machine for the web (LLVM/W) on top of ASM.js (and implement threading by emulation), and then wait for general acceptance, and for browser vendors to implement LLVM/W directly.
Contrary to popular belief, it is still possible (and in fact very easy) to have memory leaks with a GC. Consider for example this situation: fill a list with a large number of items, and hold on to that list, without ever accessing the items again. In principle, the contents of the list is "unreachable" (since the code never re-visits the items), but the GC isn't aware of this (too difficult to prove) and conservatively assumes that the reference to the list means that the items in it can still be accessed.
So, even in Javascript, it is very easy to have memory leaks.
The main way to deal with this, is to simply set a limit on the amount of memory a browser-tab can use. This limit can be dynamic, and depend on what other tabs (or processes) are doing, but it doesn't need to be. This is also the current way browsers deal with this problem.
1. Caching, content-distribution-networks, and possibly shared-libraries could solve or at least ameliorate this.
2. This is relatively easy. The sandboxed code could "open" handles by calling into an API, and the code could "close" them when no longer needed.
3. In many cases, the GC is tied intimately to the semantics of the language, so enforcing a style of GC could be too limiting in terms of performance. Instead, it could be better to implement a GC'ed VM on top of the low-level one.
The biggest problem is to get something like this turned into a standard, and accepted in all browsers. Perhaps a viable route is to write the standard of this low-level virtual machine for the web (LLVM/W) on top of ASM.js (and implement threading by emulation), and then wait for general acceptance, and for browser vendors to implement LLVM/W directly.