downs wrote:
No it doesn't (not always). Depending on your C runtime and the size of the allocations, memory may or may not be returned to the OS.BCS wrote:Hello AxelS,BCS Wrote:You can't. The D runtime (and most other runtimes) don't ever reduce the amount of memory they keep in the heap. If you where to allocate another 25MB right after that function you would see no change in the memory usage. The good news is that with virtual memory, all of that has almost zero cost. What matters is how much ram you are actively using.I want to load and send a file via network...when I load the entire file into memory it's very stupid that I can't release that memory again... OK I'll try it with the C API but thanks for your help!C's runtime (malloc/free) doesn't return memory to the OS either.Um .. yes it does. :)
For example, on Unix systems, there are two system calls to get memory from the OS: (s)brk and mmap. AFAIK, there is no way to return memory allocated through (s)brk. Those calls are only able to allocate blocs of a given size (the OS page size) and the runtime manages smaller and larger sizes to balance speed, and efficiency. Some C runtimes will allocate small blocs through (s)brk and large blocs through mmap, some will allocate everything with (s)brk, some will use mmap when the requested size is a multiple of the OS page size and everything else through (s)brk. Depending on the scheme used, the runtime may not be able to return the memory to the OS.
Like BCS said, the only way to make sure that the memory will be returned is to use mmap/munmap directly (or their equivalent on your platform).
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
