Available memory size is fixed (enlarge it? grow dynamically?)

[gchiu]

I enabled CORS policy on the metaeducation S3 buckets

read http://metaeducation.s3.amazonaws.com/travis-builds/0.3.40/r3-3ffb63e-debug.exe

then fails with

Cannot enlarge memory arrays to size 23977984 bytes (OOM). Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 16777216, (2) compile with -s ALLOW_MEMORY_GROWTH=1 which allows increasing the size at runtime, or (3) if you want malloc to return NULL (0) instead of this abort, compile with -s ABORTING_MALLOC=0

[hostilefork]

Emscripten's ALLOW_MEMORY_GROWTH option does not currently work with pthreads:

emscripten-core/emscripten#7382

Looks like it's a V8 limitation, so the question is when they're going to get it.

So long as we're stuck with a fixed size, I don't know what we should be picking...we're just taking whatever the default is right now.

[hostilefork]

It looks like one can set this at runtime, maybe:

emscripten-core/emscripten#5493

So it could be an option to reb.Startup()?

[BrianOtto]

I append a hack that sets a larger memory size in the Emscripten config when building libr3 for UI Builder. It currently needs 75497472 bytes when exporting apps. It would be nice if I could get rid of this and specify an option to reb.Startup() instead.

[hostilefork]

Looks like growable memory for pthreads is coming to the SDK shortly, was added last month on GitHub:

emscripten-core/emscripten#8365

Causes some slowdown, because any thread can grow the heap, and this can catch the other threads by surprise. Once it comes along we'll have to see how much that affects our usual operation.

Chrome doesn't support the underlying feature just yet, but Firefox does. Anyway, things are on track for this to be an option...but we still should probably have a reb.Startup() option...if we can.