• mw (16/16) Nov 05 2020 Hi,
• Patrick Schluter (5/20) Nov 06 2020 stdlib free does not give memory back to the system in a process
• Jacob Carlborg (14/27) Nov 06 2020 In general, any GC (not just the one in D) are not likely to give

mw <mingwu gmail.com> writes:

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?

thanks.

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

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.

Jacob Carlborg <doob me.com> writes:

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