Aborting on failure is an excellent default strategy -- the contortions an application needs to go through to free memory in such conditions are extreme. How can you even analyse what memory your application can release if you can't even allocate any data structures to use in the analysis? Abort on memory exhaustion is the only sane default strategy.
Allocations could arguably be aligned to 4 bytes if you're very careful about how you place doubles in structures. On a normal OS, there are tons of libc internals that will have uint64_t members in structures (eg for file offset handling), so 8 byte alignment is normally required, but on emscripten I think you get away with putting those at odd multiples of 4 because of the emulated 64-bit arithmetic. That just leaves doubles which might need the strict 8 byte alignment, and they're unlikely to show up in library code. Having said that, 8-byte alignment is a good default because it's guaranteed by the C spec! A conformant malloc() must return blocks aligned to the strictest requirement of any primitive type. Writing a double to a typed array on Arm will require that 8-byte alignment. Nick On Thursday, 11 September 2014 19:34:06 UTC+1, Alecazam wrote: > > I haven't found any articles on customizing the build of the default > libraries. Default dlmalloc behavior is to abort on allocation failure and > align allocations to 8 bytes. That's not a good default strategy in > general for any application. > -- 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.
