On Tue, May 10, 2016 at 10:59 AM, Norman <kradepon@googlemail.com> 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<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