Comment by geoffschmidt | Hacker News Reader

Comment by geoffschmidt | Hacker News Reader

Why does malloc take a byte count, just to divide it by sizeof(u32)? Why not embrace the fact that natural "word" in the JavaScript VM is a boxed value that stores an int, float, or string, and define sizeof(u8) === sizeof(u16) === sizeof(u32) === 1? Unless you really want each cell in your memory arena to literally emulate a byte and always store a value between 0 and 255?

In a similar vein, why not use the native JavaScript object type to back the structs? This will cooperate nicely with the inline caching in typical JavaScript JITs. The result will be native assembler that indexes directly into the structs in the way you'd hope, since your static typing system forces every object reference to be monomorphic.

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?

There's definitely something alluring about the static typing, but I'm less sold on the manual memory management. Maybe there is a way that the language could help you generate less garbage, without actually requiring you to manually control the lifetime of each object?

From your linked-list example, it's eminently clear that it needs a C++-style template system and a port of the STL :) If you wrote a C-to-*JS translator, you could hypothetically use a pre-existing cfront (C++-to-C translator) and STL implementation to get that working.

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

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