why `top` report is not consistent with the memory freed by core.stdc.stdlib : free?

[Jacob Carlborg]

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