25 ms·
> [...] that it would only ever hand out in response to malloc() attempts inside a SIGNOMEM handler. POSIX doesn't allow malloc() to be called inside a signal
by dezgeg 12y ago
> [...] that it would only ever hand out in response to malloc() attempts inside a SIGNOMEM handler.
POSIX doesn't allow malloc() to be called inside a signal handler at all. Also, when free():ing memory that is allocated with malloc(), there is absolutely no guarantee that the memory is ever returned back to the OS (i.e. via munmap() or sbrk()), due to possible memory fragmentation.
In other words, it's just wouldn't be practically possible to create an application that uses standard memory allocation functions and reliably can free some memory back to the kernel.
- jbert 12y agomadvise() MADV_DONTNEED allows this - http://man7.org/linux/man-pages/man2/madvise.2.html http://man7.org/linux/man-pages/man2/madvise.2.html It's also a flag in posix_madvise(), so the concept is reasonably portable.
- dezgeg 12y agomalloc() and free() is what I meant by "standard memory allocation functions". I'd say program that is in the position to use madvise() effectively has implemented it's own heap allocator. Also, MADV_DONTNEED is only usable in some specific situations, like caches. I don't see how it could be used to implement things like "on low memory, trigger garbage collection and trim the heap to the smallest possible with munmap()".
- jbert 12y agoYou said: "In other words, it's just wouldn't be practically possible to create an application that uses standard memory allocation functions and reliably can free some memory back to the kernel." So I thought you'd be interested to know that you can do just this with the standard functions mmap() and madvise(). No, it's not a replacement for malloc/free, but it does have value to some applications for some use cases.