To set total memory at runtime, you can do the same in a worker as in the main thread, set Module.TOTAL_MEMORY.
asm.js officially stopped supporting memory growth. It should be the same on all browsers - none should be doing asm.js opts when memory growth is used. Definitely chrome and firefox do not. (In WebAssembly we'll have memory growth fully optimized, so people are focusing on that.) On Thu, Jul 28, 2016 at 8:28 AM, 'Peter Nemeth' via emscripten-discuss < [email protected]> wrote: > Right, those were my thoughts as well. > > Meanwhile I've bumped into the limitations of large ArrayBuffers in 32 bit > buffers, i.e. even if I work out the required memory it can end up being > quite high which is not possible on 32 bit browsers. Based on my tests the > limits is around 0.5-1GB depending on the browser. Found some relevant > discussion here https://bugzilla.mozilla.org/show_bug.cgi?id=927182 and > here https://bugzilla.mozilla.org/show_bug.cgi?id=965880 about virtual > address space, committed memory, etc. Also found this 32 bit related > initiative in Firefox: > https://bugzilla.mozilla.org/show_bug.cgi?id=1277066 > > A few more questions: > - how to set the TOTAL_MEMORY for a worker at runtime? > - is it known in which browser does ALLOW_MEMORY_GROWTH disable asm.js? I > know Chrome has an issue ( > https://bugs.chromium.org/p/v8/issues/detail?id=3907) but what about > other? > - any experience with using WORKERFS in a 32 bit browser? How do Blobs > relate to the virtual address space, i.e. do browsers remove them from the > address space when not in use or on tight memory? > > Thanks > > 2016. július 27., szerda 19:19:11 UTC+2 időpontban Alon Zakai a következőt > írta: >> >> Emscripten allocates an ArrayBuffer for memory. In principle, browsers >> call internally allocate it using calloc(), which would let most OSes only >> create physical pages when actually needed. However, in practice, some >> browsers have optimizations for the location of asm.js typed arrays, which >> can remove some bounds checks, but it does limit the effectiveness of >> calloc(). >> >> In general, it is best to assume that TOTAL_MEMORY will use physical >> memory immediately. Memory growth is an option to use memory more flexibly, >> but as you said, it has perf limittaions. >> >> On Wed, Jul 27, 2016 at 8:11 AM, 'Peter Nemeth' via emscripten-discuss < >> [email protected]> wrote: >> >>> I was digging this a bit more and it's not the browser but the OS. What >>> Activity Monitor / Task Manager shows is the resident memory. The >>> about:memory page of Firefox clearly shows everything related (resident, >>> vsize, js engine, asm.js, ...). >>> >>> The questions still apply though. Can I rely on this in practice (given >>> the browser is 64 bit, 32 bit browsers are worse from this point)? Tips for >>> production? >>> >>> >>> 2016. július 26., kedd 15:10:27 UTC+2 időpontban Peter Nemeth a >>> következőt írta: >>>> >>>> I'm trying to find out the best memory configuration for our >>>> application. It's using a lot of user generated content so we cannot be >>>> sure about the required TOTAL_MEMORY at compile time. We could calculate >>>> that upfront on the backend and set in the Module before loading but I >>>> would like to avoid that if possible. Also don't want to enable memory >>>> growth because of its performance drawbacks. After checking some browsers >>>> with a simple test it seems like they are smart enough not to allocate the >>>> whole buffer in C++ regardless the requested size of the ArrayBuffer. Do >>>> you know if this works in practice? How is Emscripten handling the HEAP >>>> stack-, and heap-wise? Where are they located in the HEAP? Any tips from >>>> production applications how they solve memory configuration? >>>> >>> -- >>> 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 [email protected]. >>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
