No; you shouldn’t cast the result, since: It is unnecessary, as void * is automatically and safely promoted to any other pointer type in this case. It adds clutter to the code, casts are not very easy to read (especially if the pointer type is long). It makes you repeat yourself, which is generally bad. … Read more
char *test = (char*) malloc(12*sizeof(char)); +-+-+-+-+-+-+-+-+-+-+-+-+ test—>|x|x|x|x|x|x|x|x|x|x|x|x| (uninitialized memory, heap) +-+-+-+-+-+-+-+-+-+-+-+-+ test = “testingonly”; +-+-+-+-+-+-+-+-+-+-+-+-+ test + |x|x|x|x|x|x|x|x|x|x|x|x| | +-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+ +->|t|e|s|t|i|n|g|o|n|l|y|0| +-+-+-+-+-+-+-+-+-+-+-+-+ free(test); // error, because test is no longer pointing to allocated space. Instead of changing the pointer test, you need to copy the string “testingonly” into the allocated place using e.g. … Read more
Calling mmap(2) once per memory allocation is not a viable approach for a general purpose memory allocator because the allocation granularity (the smallest individual unit which may be allocated at a time) for mmap(2) is PAGESIZE (usually 4096 bytes), and because it requires a slow and complicated syscall. The allocator fast path for small allocations … Read more
You asked 2 questions: for which application the next malloc() call will be faster, #1 or #2? In other words: Does malloc() have an index of allocated locations in memory? You’ve implied that they are the same question, but they are not. The answer to the latter question is YES. As for which will be … Read more
You’re close. In C (at least since the 1989 version of the standard), the cast before malloc and realloc is unnecessary, since C can convert values of type void * to int * without a cast. This is not true for C++, so based on the error you’re getting, it sounds like you’re compiling this … Read more
However, I hardly see this version in my experience. You would use it (or, equivalently, catch the exception from the default version) if you can handle the failure locally; perhaps by requesting to free some other memory and then retrying, or by trying to allocate something smaller, or using an alternative algorithm that doesn’t need … Read more
If I remember correctly, the main difference was with multi-threaded projects. Both libraries try to de-contention memory acquire by having threads pick the memory from different caches, but they have different strategies: jemalloc (used by Facebook) maintains a cache per thread tcmalloc (from Google) maintains a pool of caches, and threads develop a “natural” affinity … Read more
There is a good paper on the allocator: The Foundations for Scalable Multi-core Software in Intel Threading Building Blocks My limited experience: I overloaded the global new/delete with the tbb::scalable_allocator for my AI application. But there was little change in the time profile. I didn’t compare the memory usage though.
This is undefined behaviour, as there’s no way to reliably prove that memory behind the pointer was allocated correctly (i.e. by new for delete or new[] for delete[]). It’s your job to ensure things like that don’t happen. It’s simple when you use right tools, namely smart pointers. Whenever you say delete, you’re doing it … Read more
Observations Assuming a typical allocator, such as the one glibc uses, there are some observations: Whether or not the memory is actually used, the region must be reserved contiguously in virtual memory. The largest free contiguous regions depends on the memory usage of existing memory regions, and the availability of those regions to malloc. The … Read more