-
-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: wrappers for malloc/calloc/realloc/free #345
Comments
Actually, a better way to handle the odd case of malloc not being thread-safe (the MATLAB mxMalloc), would be to add a critical section inside "my_malloc". Then the blosc2_malloc, as above, would be used just as shown, with no critical section. So the above strawman would work fine in all use cases I can think of. |
For how this is done in LZ4, see https://github.com/lz4/lz4/releases/tag/v1.9.3 for a discussion, and https://github.com/lz4/lz4/blob/e78eeec86e696f318a0ad1e71d6ad50555d1c0a9/lib/lz4.c#L188 for how it's done in that library. |
Yeah, that has been in our TODO list for long time and we would be glad to consider a pull request on this. |
Great! It will take me a while before I can tackle an update to c-blosc2 as a pull request, but I'll keep you posted before I give it a try. The tricky part is not c-blosc2 itself, but all the other packages it relies on. LZ4 has its own method for redirecting malloc/calloc/free, but this is a compile-time control not a run time one (the latter is needed). So even LZ4 would need a patch, in my opinion. Unlike LZ4, the zlib package calls malloc/calloc/free directly, with no wrapper at all. So it would need patches, to (say) replace malloc with blosc2_malloc, free with blosc2_free, etc. The zstd library has ZSTD_malloc and ZSTD_customMalloc (the latter looks promising) but I also see bare calls to malloc in some places, like in zstd/dictBuilder. These fixes could be done but they would have the downside of requiring a patch to a set of 3rd-party libraries, which can be difficult to maintain. So I understand why this feature doesn't appear in c-blosc2 yet. |
@DrTimothyAldenDavis why do you need every malloc call to use the external wrapper? Afaiu only the memory that's allocated internally, passed to the framework/library in use (Matlab, Julia, etc), and is from that point on managed by it, needs to be allocated using the framework's version of malloc; all dynamic internal buffers can use whatever they want. Of course, keeping track of which allocations need which free function isn't simple, but it could be simpler than changing every call in a code base. |
It's far too complicated to keep track. I will often create internal temporary sparse matrices (each with about 3 to 5 malloced spaces) and other data structures. The I will move those memory spaces into a final sparse matrix object passed back to the user. Having different memory managers in a single complex application like my packages just isn't possible. |
I'd like to try out c-blosc2 in SuiteSparse:GraphBLAS (see https://github.com/DrTimothyAldenDavis/GraphBLAS ). The package is used for C=A*B in MATLAB, and for the sparse matrix engine inside RedisGraph. It's also under consideration as the core sparse matrix library for Julia.
However, all of these applications have their own malloc/calloc/realloc/free memory managers. Julia has jl_malloc, MATLAB has mxMalloc, etc. There are TBB malloc functions that some applications use. I allow the application to tell me which malloc/calloc/realloc/free to use (via function pointers), and then I use that for all of my memory allocations. c-blosc2 calls the bare malloc/calloc/realloc/free, and there's no way to change this easily, from the user application.
LZ4 has a mechanism like this (except it's a compile-time selection), so I could use LZ4 inside GraphBLAS if I compile it myself, and make LZ4_malloc do the same thing as the example below. But currently I can't use strategy in c-blosc2, since c-blosc2 has no way for me to tell it which malloc/calloc/realloc/free to use.
If c-blosc2 could have something like the following, then I could set blosc2_malloc_function, etc, pointers to point to my malloc/etc functions. There are some other nuances ... the MATLAB mxMalloc is not thread-safe and must be placed in a critical section, so I have a bool that tells me whether the critical section is needed or not. Below is a simple version that ignores this issue. See https://github.com/DrTimothyAldenDavis/GraphBLAS/blob/9d36ba4fd0bec6edfae25077d5de6b4cfb7f4762/Source/GB_Global.c#L670 for details on how I handle that case.
The text was updated successfully, but these errors were encountered: