Hacker News Reader

Comment by munificent | Hacker News Reader

> which has no garbage collector (so languages can implement their own if desired).

The problems with that are:

1. It means every web app basically has to push its own GC down the wire every time the user hits myawesomeapp.com. That's a lot of overhead.

2. You'd have to define what the memory model between the code running in the VM and the browser's native stuff is. What does it mean for the code to have a reference to a DOM element? How does the browser hold a reference to an event handler in the VM?

3. The set of people who can implement an efficient GC is very very small. Forcing each source language to do that themselves wastes a lot of effort. (For example, look at how primitive Python and Ruby's GCs were for most of their histories.)

Now a low-level VM with GC. That's something I'd be excited about.

View on HN

Interesting points.

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.

> 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".

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.

Reply on news.ycombinator.com