Hacker News Reader

Comment by azakai | Hacker News Reader

> Does this language actually eliminate GC pauses? Isn't the GC still going to run, except now it has to walk every single cell in your memory arena every time, defeating the very heuristics that GCs use to reduce pauses?

Yes, this eliminates GC pauses.

The JS GC will only run if allocations occur, allocations in the sense of actual JS objects. If you do malloc which amounts to manually handling indexes in a single array, no JS objects are created and destroyed.

Also, JS GC's would not walk the memory arena. The memory arena is just an array of numbers, it does not contain native JS references which is what the JS GC traces.

View on HN

I meant the synthetic memory arena, the JS array that malloc() and free() manage. That certainly could contain JS references and needs to be examined by the GC.

I don't think you can actually avoid GC by avoiding JS object allocations. Any form of string manipulation, any form of IO (event handling, DOM manipulation, XHR), any use of timers, etc, is going to allocate objects, right? Also, the JS runtime could generate garbage internally. For example, since JS has closures, it wouldn't be totally unreasonable for the runtime to manage the lifetime of activation records (JS stack frames) using the GC.

The memory arena is a typed array, which cannot contain object references and so does not need to be scanned by the GC.

If you keep JavaScript object allocations to a minimum, then GC pauses will be short and infrequent. This could actually be useful to write a game render loop or any other code that can't tolerate pauses.

As modeless said, the memory arena is a typed array. It contains numbers, not JS references. The GC does not look at the contents of typed arrays at all.

String creation does create JS objects, yes, as does creating closures. It is hard to avoid garbage entirely, that's true.

Managing JS stack frames using the GC would be very bad for performance. You almost never need to do that unless your language has something like Scheme's call/cc. You may need to promote closed-over variables to the heap, but you don't need to migrate the entire stack frame there.

Reply on news.ycombinator.com