asm.js now allows the heap to be resized (by replacing the heap's ArrayBuffer with a newer, bigger ArrayBuffer that was either copied or produced via ES7-proposed ArrayBuffer.transfer [1]). Heap resizing currently has to be enabled in Emscripten (by passing -s ALLOW_MEMORY_GROWTH=1), but may become the default in the future. The main asm.js spec page hasn't been updated yet, but the extension was discussed publicly with comments from Microsoft engineers [2].

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] http://discourse.specifiction.org/t/request-for-comments-swi...

That is nice to hear. I don't keep enough track to see that this was being discussed, but it does deal with the only major issue I had with C++ -> asm.js code conversion, particularly for mobile.

Coming from the compiler side of things, you're sacrificing in usability to make it possible for the JIT compiler to optimize the code further. If you allocate all memory ahead-of-time, the GC never needs to operate on that region, which gives you substantial performance improvements.

This is definitely a trade-off, but it's my understanding that asm.js makes more sense as a target for compilers to emit code for, rather than for hand-writing. Would you hand write an entire application in x86 assembly? Probably not...

Couldn't the JIT provide me a way of allocating new blocks of memory? and freeing blocks of memory back to the 'OS'? At least allocating new blocks?

I don't mind no GC, but having to allocate the maximum memory your program will use before it starts can be painful.

> which requires compiling in your own malloc

dlmalloc is cross compiled for you. I might be mincing words, but you make it sound like you have to bring your own allocator. Not so.

> makes it hard not to massively waste memory by overallocating a huge buffer.

Non issue. there are compiler flags `-s TOTAL_MEMORY=X` and `-s TOTAL_STACK=X`. Of course, you have to play around with these values otherwise you might not have enough space. I'm working on memory profiling tools to visualize the state of the heap in emscriptenized code [0] and getting them merged upstream. [1] The docs could be better on those flags.

> Therefore I greatly prefer optimisations which speed up 'asm.js-like code', rather than the all-or-nothing optimisation one gets from firefox.

Why must they be mutually exclusive? It's a straw man to paint it like we can only have one or the other but not both, and therefor we must choose. All-or-nothing is also an incorrect categorization; Firefox's JIT makes the same optimizations for non ASM code after it warms up.

[0] https://github.com/nickdesaulniers/emscripten-memprof [1] https://github.com/kripken/emscripten/pull/3178

> dlmalloc is cross compiled for you. I might be mincing words, but you make it sound like you have to bring your own allocator. Not so.

Wait, so I don't have to include an allocator in every asm.js project? How do I avoid doing that?

> Non issue. there are compiler flags `-s TOTAL_MEMORY=X` and `-s TOTAL_STACK=X`. Of course, you have to play around with these values otherwise you might not have enough space.

How does that make my complaint a non-issue? I shouldn't have to, in this day and age, manually tune the maximum amount of memory my program will use up front. That what my OS is for, I ask for more memory when I want it. What happens when some user decides to use my app in a sensible, but more memory hungry way, and hits so arbitrary limit I had to set for mobile users?

Of course, someone else replied this second point is now invalid, as asm.js is gaining the ability to grow the heap.