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.

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.

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