4 ms·
> 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. That's eas
by arohner 12y ago
> 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.
That's easy to specify, but is it good for the user? You've just opened the door to memory leaks on my machine in poorly-written "javascript".
- amelius 12y agoContrary 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.