Re: [Boost-users] Memory deallocation concerning boost::bind, boost::asio and shared_ptr

Subject: Re: [Boost-users] Memory deallocation concerning boost::bind, boost::asio and shared_ptr
From: Chris Cleeland (chris.cleeland_at_[hidden])
Date: 2016-05-10 09:43:02

On Tue, May 10, 2016 at 7:40 AM, Norman <kradepon_at_[hidden]> wrote:

> In this example, the amount of memory beeing allocated by the programm
> converges to a limit, which shows exactly what you told me. So the C++
> runtime holds on to some allocated memory, even though the objects have
> been
> 'freed', meaning that the application does not need to allocate more memory
> for every function call.
>
> My problem with this behaviour is, that my application should run for an
> infinit amount of time. It's a server application, which allocates a
> greater
> amount of memory in between. So if this memory is allocated for a little
> while, even when the memory is 'not in use' anymore, that's fine with me.
> But at some time, the memory needs to be released to the OS. And that's
> exactly where my problem appears. I don't know, if the memory will ever be
> reclaimed by the OS. Of course, RSS does not tell me how much memory my
> application is currently using, but it tells me at least the minimum amount
> of memory currently managed by the C++ runtime. And if this increases to a
> huge amount, my OS does not have access to this memory, right?
>
> So my remaining question is, if the ioService object will (or more precisly
> the C++ runtime) will ever release the allocated memory to the OS or if i
> have to do this manually.
>
>
You need to ask that question of your C++ runtime and, more specifically,
the heap allocator used by the runtime.

You also need to learn how your OS manages things and when it will reclaim.

RSS is not a good indicator of leaks or even of how much memory a process
is "using".  All it tells you is how many OS level pages the OS currently
has set aside in core for that process (or thread, if your OS gives you RSS
for some more granular entity).  The value of RSS depends on many things
outside your control such as other processes' demands for memory, the usage
patterns for memory within your process, and the like.

If you're concerned about the memory footprint of your application, you're
looking at symptoms rather than real problems.  Leaks are only one part of
the problem.  Just as common is fragmentation and locality of reference.
Work to reduce those in your application, and eliminate leaks, and your app
will likely exhibit better behavior with respect to memory usage.

-- 
Chris Cleeland