On Friday, 6 November 2020 at 06:17:42 UTC, mw wrote:
https://wiki.dlang.org/Memory_Management#Explicit_Class_Instance_Allocation
using core.stdc.stdlib : malloc and free to manually manage
memory, I tested two scenarios:
-- malloc & free
-- malloc only
and I use Linux command `top` to check the memory used by the
program, there is no difference in this two scenarios.
I also tried to use `new` to allocate the objects, and
GC.free(). The memory number reported by `top` is much less
than those reported by using core.stdc.stdlib : malloc and free.
I'm wondering why? shouldn't core.stdc.stdlib : malloc and free
be more raw (low-level) than new & GC.free()? why `top` shows
stdlib free() is not quite working?
In general, any GC (not just the one in D) are not likely to give
back memory to the OS. Because it's less overhead for the GC to
keep the memory and reuse it. But I'm guessing `GC.free()` is
supposed to give back memory to the OS, which leads into the
other scenario.
When it comes to maclloc/free. I would guess it's doing something
similar. It probably splitting up the memory in blocks and/or
pools. It might keep the memory just as the GC does for
efficiency, even if `free` is called. Otherwise it would be not
much point in using over the syscalls like `mmap` or `sbrk` (and
whatever the corresponding calls are on Windows).
--
/Jacob Carlborg
