std.container.Array/RefCounted(T) leaking memory?
schveiguy at yahoo.com
Thu Jan 13 10:50:28 PST 2011
On Thu, 13 Jan 2011 12:40:04 -0500, Jesse Phillips
<jessekphillips+D at gmail.com> wrote:
> Steven Schveighoffer Wrote:
>> But even so, malloc and free have the same property where they don't
>> always give back memory to the OS. IIUC, Linux can only change the size
>> of memory it wants, it cannot free pages in the middle of the block.
> Disclaimer: I don't know what I am talking about.
> I think this is correct, the program isn't responsible for reclaiming
> the memory, that is what the OS does. If you don't have an OS then you
> don't have anything to return the memory to, so it just becomes free
> memory. Modern operating systems aren't going to take their memory back
> until it is needed (wast of cycles).
> What I observed using Linux and $ free; each section would result in a
> reduction of free memory and an increase in buffered data. This suggests
> to me that the OS doesn't want the memory yet.
> Tracking memory in a modern OS is not easy, and this is probably why no
> one wanted to make a statement on what was really happening. As I said I
> don't know if this is what is happening, but it usually isn't as
> straight forward as checking memory usage.
I think all memory is allocated/deallocated from the OS via the sbrk/brk
brk() and sbrk() change the location of the program break,
defines the end of the process's data segment (i.e., the program
is the first location after the end of the uninitialized data
Increasing the program break has the effect of allocating memory to
process; decreasing the break deallocates memory.
So you can only ever add to the *end* of memory, and you can only ever
deallocate from the *end*. And the OS doesn't ever just jump in and claim
memory, you have to tell it that you are deallocating memory.
Which means, if you say allocated 100MB, and wanted to deallocate the
first 99MB, you still couldn't release any back to the OS.
A moving GC would allow for more memory to be freed, but we aren't there
Of course, I could be completely wrong about all this, I've never really
used sbrk or brk :)
More information about the Digitalmars-d-learn