Emscripten currently let's sbrk() manage the top of the entire memory space, which is a single typed array. There is no special browser support to decommit inside a typed array, so we don't do anything for that - sbrk() will grow it (if memory growth is on) but that's pretty much it.
If you need to port an app that uses a different API, perhaps it could use malloc or sbrk under the hood. Then things would work, but obviously none of the efficiency of decommitting etc. would be achieved. - Alon On Sun, Feb 16, 2014 at 4:38 AM, wb <[email protected]> wrote: > Hi, > > I am currently trying to port one of our Windows applications to compile > with Emscripten and OSX. It uses VirtualAlloc() and related functions to > reserve virtual address space and at least suggestively commit/de-commit > regions and of course I am wondering how well I can get that to work with > Emscripten ASM.JS output. > > I noticed these two old relevant discussions: > > https://bugzilla.mozilla.org/show_bug.cgi?id=670596 > https://bugzilla.mozilla.org/show_bug.cgi?id=855669 > > On OSX I am still experimenting trying to figure out the best usage > pattern as its not clear at all what that is. On OSX there are additional > flags for madvise() in the headers: > > > #define MADV_SEQUENTIAL POSIX_MADV_SEQUENTIAL > > #define MADV_WILLNEED POSIX_MADV_WILLNEED > > #define MADV_DONTNEED POSIX_MADV_DONTNEED > > #define MADV_FREE 5 /* pages unneeded, discard contents */ > > #define MADV_ZERO_WIRED_PAGES 6 /* zero the wired pages that have not > been unwired before the entry is deleted */ > > #define MADV_FREE_REUSABLE 7 /* pages can be reused (by anyone) */ > > #define MADV_FREE_REUSE 8 /* caller wants to reuse those pages */ > > #define MADV_CAN_REUSE 9 > > > I don't expect all of these are portable across Linux and Emscripten and > as currently I am not even sure what the correct usage pattern is on OSX I > have no idea what to suggest would be the ideal behaviour across all > platforms that support mmap(). > > So I wondered for Emscripten at least what is the suggested path forward? > I suspect in the short term it will be a mix of something specific for > Emscripten builds that works slightly better in Firefox, but that will > still be fairly inefficient for extreme allocation situations. > > Also as I believe a realloc_inplace() was a missed opportunity in the C > standard I wondered if something you could support in Emscripten as it > could help work arounds for such cases? I imagine such a function behaving > the same as realloc() but failing if it has to resort to moving the memory > region to fulfil the request. > > Which also makes me wonder about how aligned_malloc() will work in > Emscripten and the other C standard oversight of there being no standard > aligned_realloc() it seems. > > Personally I am totally fine with Emscripten specific memory management > routines as I believe a lot of the mmap() functionality could be > streamlined to prevent unnecessary programmer errors - as the thought of a > Web memory management API being purely based on mmap() seems like a bad > idea to me because of that. > > Thanks! > > WB > > -- > 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/groups/opt_out. > -- 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/groups/opt_out.
