wrap_dlmalloc

[juj]

Export system malloc() and free() as dlmalloc() and dlfree() so that applications can have an easier mechanism to just hook in between to the existing malloc and free, but still keep calling the original dlmalloc and dlfree.

[kripken]

I don't know about this. It adds two exported names to all builds, for a rather corner case, which we already have ways to do (provide a full dlmalloc, e.g. using dlmalloc.c, or use the tracing API). This would also be in danger of breaking should we e.g. switch to the musl allocator instead of separate dlmalloc, which is separate for historic reasons really.

[juj]

Hmm, what if we exported the functions as emscripten_builtin_malloc and emscripten_builtin_free then, instead of dlmalloc and dlfree?

[kripken]

Those names sound reasonable to me.

Can we do this as an option, though? Exporting them by default all the time sounds like overhead we shouldn't add. Unless this doesn't actually export them unless used?

[juj]

Rebased to resolve merge conflict.

There is no overhead in always exporting, at least not in added code size, since the symbols will only be linked in if code uses them. And because these are aliases to the same function, if code calls them they will not duplicate the implementation of malloc, but just refer to the original. Or are you concerned with the export table having two extra entries?

[kripken]

Sounds good about the overhead then.

Overall lgtm, except for the idea before to export them as emscripten_malloc or emscripten_builtin_malloc or such? Seems more future-proof.

[juj]

Oh right, let's do the emscripten_builtin_malloc, forgot I proposed that. Updated the PR. I realize needs to bump the version (previous version also did, but didn't have that in) to rebuild libc in cache so it contains the alias names. How does this look now?

[kripken]

Nice, looks good.

[evanw]

I just found this. I'd like to use emscripten_builtin_malloc and emscripten_builtin_free but they are currently impossible to use in real code. When changing out the memory allocator, you must override all four of malloc, free, calloc, and realloc. Only overriding some and not the others will result in heap corruption if both implementations are called.

Is there a reason why there isn't also emscripten_builtin_calloc and emscripten_builtin_realloc?

[juj]

I just found this. I'd like to use emscripten_builtin_malloc and emscripten_builtin_free but they are currently impossible to use in real code. When changing out the memory allocator, you must override all four of malloc, free, calloc, and realloc. Only overriding some and not the others will result in heap corruption if both implementations are called.

Is there a reason why there isn't also emscripten_builtin_calloc and emscripten_builtin_realloc?

It's been a long time - missed this question when it initially was proposed. There was no specific reason not to provide emscripten_builtin_calloc and emscripten_builtin_realloc as well, that would be a good idea to have.