TOTAL_MEMORY, ALLOW_MEMORY_GROWTH and SPLIT

Robert Goulet

unread,

Aug 10, 2016, 2:29:17 PM8/10/16

to emscripten-discuss

Hi all,

we are looking at possibilities regarding memory allocation limits, and we are wondering what is the status as of today regarding the strategy to use, for instance a game engine where both small and big games can be made?

Right now we are setting TOTAL_MEMORY=1GB to increase the chances the game content will not run out of memory. This is not ideal since this crashes most 32bit browsers, and forces the 1GB allocation straight up even if the game doesn't use that much memory.

There's the ALLOW_MEMORY_GROWTH option, but in the documentation it says that there is performance concerns if we enable this. Since we're running a game engine, we need maximum performance. Is this still a concern as of today's latest browsers? Has anyone tested this lately?

And then there's the SPLIT_MEMORY option. Doesn't work for us since we build with USE_PTHREAD=2 and Emscripten doesn't support both together so far.

Suggestions? hints? Please share!

Thanks!

Robert Goulet

unread,

Aug 10, 2016, 2:35:14 PM8/10/16

to emscripten-discuss

Just realized that ALLOW_MEMORY_GROWTH is not supported with USE_PTHREAD either. Errors out with:

Cannot enlarge memory arrays, since compiling with pthreads support enabled (-s USE_PTHREADS=1).

So that leaves us with TOTAL_MEMORY as the only option?

Alon Zakai

unread,

Aug 10, 2016, 2:45:12 PM8/10/16

to emscripten-discuss

Yes, with shared memory it cannot grow. It's possible that in WebAssembly we'll find a solution to that, but I'm not sure.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Robert Goulet

unread,

Aug 10, 2016, 4:04:37 PM8/10/16

to emscripten-discuss

What about SPLIT_MEMORY? Could that eventually work with pthreads? And does it allocate blocks only when needed or all up front?

Alon Zakai

unread,

Aug 10, 2016, 4:48:06 PM8/10/16

to emscripten-discuss

Split memory allocates chunks of memory separately, and only on demand. It could in theory work with pthreads, now that I think of it, each chunk could be a separate shared array buffer. But it wouldn't be easy, as they'd need to be sent synchronously to the other threads, or they would need to pause while waiting.

In any case, the perf overhead of split memory is bigger than memory growth, which is already significant. So probably not relevant for your high-perf use case.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Robert Goulet

unread,

Aug 10, 2016, 5:29:31 PM8/10/16

to emscripten-discuss

Ok good to know.

There's an issue with the amount of memory we request with TOTAL_MEMORY when using pthreads - it seems to ends up allocating the total memory times the number of threads in the pool. Is that correct? Will it be fixed eventually?

On Wednesday, August 10, 2016 at 4:48:06 PM UTC-4, Alon Zakai wrote:

Split memory allocates chunks of memory separately, and only on demand. It could in theory work with pthreads, now that I think of it, each chunk could be a separate shared array buffer. But it wouldn't be easy, as they'd need to be sent synchronously to the other threads, or they would need to pause while waiting.

In any case, the perf overhead of split memory is bigger than memory growth, which is already significant. So probably not relevant for your high-perf use case.

On Wed, Aug 10, 2016 at 1:04 PM, Robert Goulet <robert...@autodesk.com> wrote:

What about SPLIT_MEMORY? Could that eventually work with pthreads? And does it allocate blocks only when needed or all up front?

On Wednesday, August 10, 2016 at 2:45:12 PM UTC-4, Alon Zakai wrote:

Yes, with shared memory it cannot grow. It's possible that in WebAssembly we'll find a solution to that, but I'm not sure.

On Wed, Aug 10, 2016 at 11:35 AM, Robert Goulet <robert...@autodesk.com> wrote:

Just realized that ALLOW_MEMORY_GROWTH is not supported with USE_PTHREAD either. Errors out with:

Cannot enlarge memory arrays, since compiling with pthreads support enabled (-s USE_PTHREADS=1).

So that leaves us with TOTAL_MEMORY as the only option?

On Wednesday, August 10, 2016 at 2:29:17 PM UTC-4, Robert Goulet wrote:
Hi all,

we are looking at possibilities regarding memory allocation limits, and we are wondering what is the status as of today regarding the strategy to use, for instance a game engine where both small and big games can be made?

Right now we are setting TOTAL_MEMORY=1GB to increase the chances the game content will not run out of memory. This is not ideal since this crashes most 32bit browsers, and forces the 1GB allocation straight up even if the game doesn't use that much memory.

There's the ALLOW_MEMORY_GROWTH option, but in the documentation it says that there is performance concerns if we enable this. Since we're running a game engine, we need maximum performance. Is this still a concern as of today's latest browsers? Has anyone tested this lately?

And then there's the SPLIT_MEMORY option. Doesn't work for us since we build with USE_PTHREAD=2 and Emscripten doesn't support both together so far.

Suggestions? hints? Please share!

Thanks!

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alon Zakai

unread,

Aug 10, 2016, 5:35:00 PM8/10/16

to emscripten-discuss

That sounds very surprising and a terrible bug if true. Do you have a testcase?

On Wed, Aug 10, 2016 at 2:29 PM, Robert Goulet <robert...@autodesk.com> wrote:

Ok good to know.

There's an issue with the amount of memory we request with TOTAL_MEMORY when using pthreads - it seems to ends up allocating the total memory times the number of threads in the pool. Is that correct? Will it be fixed eventually?

On Wednesday, August 10, 2016 at 4:48:06 PM UTC-4, Alon Zakai wrote:

Split memory allocates chunks of memory separately, and only on demand. It could in theory work with pthreads, now that I think of it, each chunk could be a separate shared array buffer. But it wouldn't be easy, as they'd need to be sent synchronously to the other threads, or they would need to pause while waiting.

In any case, the perf overhead of split memory is bigger than memory growth, which is already significant. So probably not relevant for your high-perf use case.

On Wed, Aug 10, 2016 at 1:04 PM, Robert Goulet <robert...@autodesk.com> wrote:

What about SPLIT_MEMORY? Could that eventually work with pthreads? And does it allocate blocks only when needed or all up front?

On Wednesday, August 10, 2016 at 2:45:12 PM UTC-4, Alon Zakai wrote:

Yes, with shared memory it cannot grow. It's possible that in WebAssembly we'll find a solution to that, but I'm not sure.

On Wed, Aug 10, 2016 at 11:35 AM, Robert Goulet <robert...@autodesk.com> wrote:

Just realized that ALLOW_MEMORY_GROWTH is not supported with USE_PTHREAD either. Errors out with:

Cannot enlarge memory arrays, since compiling with pthreads support enabled (-s USE_PTHREADS=1).

So that leaves us with TOTAL_MEMORY as the only option?

On Wednesday, August 10, 2016 at 2:29:17 PM UTC-4, Robert Goulet wrote:
Hi all,

we are looking at possibilities regarding memory allocation limits, and we are wondering what is the status as of today regarding the strategy to use, for instance a game engine where both small and big games can be made?

Right now we are setting TOTAL_MEMORY=1GB to increase the chances the game content will not run out of memory. This is not ideal since this crashes most 32bit browsers, and forces the 1GB allocation straight up even if the game doesn't use that much memory.

There's the ALLOW_MEMORY_GROWTH option, but in the documentation it says that there is performance concerns if we enable this. Since we're running a game engine, we need maximum performance. Is this still a concern as of today's latest browsers? Has anyone tested this lately?

And then there's the SPLIT_MEMORY option. Doesn't work for us since we build with USE_PTHREAD=2 and Emscripten doesn't support both together so far.

Suggestions? hints? Please share!

Thanks!

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Robert Goulet

unread,

Aug 10, 2016, 5:47:43 PM8/10/16

to emscripten-discuss

I'll try to write one tomorrow, but I remember Jukka saying something about that a while ago. Perhaps he has any insights about this.

Ok good to know.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alon Zakai

unread,

Aug 10, 2016, 5:58:16 PM8/10/16

to emscripten-discuss

There is a known issue about compilation happening multiple times (and some ideas on how to fix it eventually at the spec level). That can use memory linear in the number of threads. But it's not going to be proportional to the size of TOTAL_MEMORY.

Ok good to know.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Robert Goulet

unread,

Aug 11, 2016, 9:03:57 AM8/11/16

to emscripten-discuss

Ok then that must be what I am seeing. That issue is browser implementation dependent? i.e. each browser will have to fix it on their side?

Ok good to know.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alon Zakai

unread,

Aug 11, 2016, 12:01:20 PM8/11/16

to emscripten-discuss

The hope is to fix it on the spec level eventually (i.e. add a new API), and then it'll work properly everywhere. (Until then, browsers can perform optimizations that can help here, e.g., Firefox caches compilations, but there is no guarantee that will happen in this case as it depends on the thread timing.)

Ok good to know.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Robert Goulet

unread,

Aug 11, 2016, 4:58:45 PM8/11/16

to emscripten-discuss

One more question...

The memory allocated with TOTAL_MEMORY, is it the same memory used by MEMFS when we preload content? i.e. With a total of 1GB, and preloaded content of 500MB, do we have only 500MB left for the runtime? And if yes, can we free that memory after we are done reading those files by either unmounting MEMFS completely or deleting specific files?

Thanks!

Ok good to know.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alon Zakai

unread,

Aug 11, 2016, 5:09:17 PM8/11/16

to emscripten-discuss

By default the file packager will copy into the heap, so yes, the content takes memory in the memory array buffer, statically (and so it can't be freed). The main benefit is that once in memory, mmap etc. become no-ops, so reading from those files can be very fast.

The file packager has an option, --no-heap-copy, which avoids that copy, and leaves data in the array buffers that arrive in the XHR when loading the data. That avoids using space in the memory array buffer, and the other buffer can be in non-contiguous memory so fragmentation is less of an issue. But it does mean when you read from a file the syscall will end up copying data into memory for you.

Ok good to know.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Robert Goulet

unread,

Aug 11, 2016, 5:14:59 PM8/11/16

to emscripten-discuss

If we do not use content preloading, and instead fetch it using emscripten_wget_async function, can we free that memory somehow when we are done reading the files?

Ok good to know.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alon Zakai

unread,

Aug 11, 2016, 5:23:53 PM8/11/16

to emscripten-discuss

Yes, that just creates a normal file in the emulated filesystem. You can just erase it using normal libc calls etc.

Ok good to know.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Robert Goulet

unread,

Aug 11, 2016, 5:30:59 PM8/11/16

to emscripten-discuss

Thanks Alon!

Ok good to know.

Reply all

Reply to author

Forward

TOTAL_MEMORY, ALLOW_MEMORY_GROWTH and SPLIT_MEMORY

Robert Goulet

Robert Goulet

Alon Zakai

Robert Goulet

Alon Zakai

Robert Goulet

Alon Zakai

Robert Goulet

Alon Zakai

Robert Goulet

Alon Zakai

Robert Goulet

Alon Zakai

Robert Goulet

Alon Zakai

Robert Goulet