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

Patrick Schluter Patrick.Schluter at bbox.fr
Fri Nov 6 09:28:04 UTC 2020


On Friday, 6 November 2020 at 06:17:42 UTC, mw wrote:
> Hi,
>
> I'm trying this:
>
> 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?
>

stdlib free does not give memory back to the system in a process 
normally on Linux. top only shows the virtual memory granted to 
that process. When you malloc, the VIRT goes up, the RES might go 
up also but they only go down if explicitly requested.




More information about the Digitalmars-d-learn mailing list