
Memory growth is being removed from asm.js - bobajeff
https://groups.google.com/forum/m/#!topic/emscripten-discuss/09E_WEk193E
======
ndesaulniers
It's weird to me to see this upvoted on HN.

1\. I doubt most people here are using (or have used) asm.js, let alone memory
growth.

2\. Maybe people think some major feature is being removed from asm.js (not
really, will expand below).

3\. Maybe people are confusing asm.js with WebAssembly?

4\. This will be in Web Assembly, see post's point #2.

Emscripten-emitted-code has a fixed size memory space (static memory, stack,
heap). Heap size can grow, via sbrk, but if you moved the program break past
the end of the Typed Array the code used as memory space, Emscripten could
create a new Typed Array, copy over all data from the old to the new, free the
old, and continue executing with data in the new. That process was memory
growth, and was very slow. In practice, you never really needed it, since you
could run your program a few times, see what the high water mark of your heap
was, then set the precise size at compile time.

Memory growth was helpful if you wanted to start up faster, but could
potentially have non-deterministic memory growth (though you'd still be
limited to 32b address space).

~~~
vardump
> In practice, you never really needed it, since you could run your program a
> few times, see what the high water mark of your heap was, then set the
> precise size at compile time.

How would this work with anything that has unknown runtime memory cost? Say an
editor of any kind? Like an image editor with undo buffers.

~~~
CJefferson
Exactly. For my uses (AI systems), variable memory was the thing which moved
asm.js from a cute toy to a system I can genuinely use.

------
morebetterer
Aside from a few game demos, is anyone using asm.js in production systems?

~~~
chadaustin
The 3D features on
[https://secure.imvu.com/next/](https://secure.imvu.com/next/) do. (You must
be logged in to see them.)

