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 13:04:12

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

> Alright, let's asume you are right.
>
> Can you explain the following behaviour: i create a vector<string> and fill
> it with a huge amount of strings, so it takes up to ~50% of my RSS. After
> the vector is filled, i observe the RSS and as expected, it's quite big.
> Then i clear the vector and let it run out of scope and something special
> happenes: The RSS is decreased by a significant amount (close to what it
> was
> before i created the vector)! This should not happen in your scenario,
> right, since the OS does not need the memory, but it still does get
> reclaimed by the OS.
>

You're still ignoring the heap allocator.  Your application does not
interact directly with the OS--it goes through several layers.

In the case you cite above--vector<string>--it's probably pretty easy for
the heap allocator to identify that there is a whole bunch of memory that
can be returned because it was all allocated together.  In your real world
application, you more than likely suffer from fragmentation that prevents
pages from being returned-- as long as just a single byte of memory from a
page is in use by the heap allocator, that page cannot be surrendered to
the OS.  Heap allocators cannot move stuff around in memory (unless they
return pointers-to-pointers like the original Mac Toolbox did with its
dynamic allocations), so it's just stuck until your app frees that up.  The
best the heap allocator can do is coalesce free blocks for future surrender.

> By the way, the behaviour, described with a vector<string> also works with
> a
> vector<shared_ptr&lt;sslSocket>>, as long as no assynchronous job,
> depending
> on the sslSocket, has been given to the acceptor/ioService.
>

Maybe that should give you a clue?

Asynchronous job?  So there is a thread holding on to the shared ptr?  does
the thread need to be joined?

-- 
Chris Cleeland