Resident Set Size remains the same after delete[]

Question

I was trying to track memory occupied by my c++ project, so I found a function which could print RSS with shared memory & private memory from this post. Code is shown below

void testMemoryOccupied() {
    int tSize = 0, resident = 0, share = 0;
    ifstream buffer("/proc/self/statm");
    buffer >> tSize >> resident >> share;
    buffer.close();

    long page_size_kb = sysconf(_SC_PAGE_SIZE) / 1024; // in case x86-64 is configured to use 2MB pages
    double rss = resident * page_size_kb;
    cout << "RSS - " << rss << " kB\n";

    double shared_mem = share * page_size_kb;
    cout << "Shared Memory - " << shared_mem << " kB\n";

    cout << "Private Memory - " << rss - shared_mem << "kB\n";
    cout << endl;
}

And I tried to test whether this would work, so I wrote:

    testMemoryOccupied();

    int* foo = new int[10000];
    for (int i=0;i<10000;i++) {
        foo[i] = i;
    }
    testMemoryOccupied();

    int* foo1 = new int[10000];
    for (int i=0;i<10000;i++) {
        foo1[i] = i;
    }
    testMemoryOccupied();

    delete[] foo;
    testMemoryOccupied();

    free(foo1);
    testMemoryOccupied();

The result showed out that RSS only increased after those two for loops, but not decreased after delete[] or free().

RSS - 1576 kB
Shared Memory - 1356 kB
Private Memory - 220kB

RSS - 1772 kB
Shared Memory - 1516 kB
Private Memory - 256kB

RSS - 1812 kB
Shared Memory - 1516 kB
Private Memory - 296kB

RSS - 1812 kB
Shared Memory - 1516 kB
Private Memory - 296kB

RSS - 1812 kB
Shared Memory - 1516 kB
Private Memory - 296kB

I know "deleting" only marks some memory locations to be "usable" but not actually wiping them out, is that the reason why RSS remains the same here?

If that is the case, how could I track the actual memory occupied at some point during the program?

It's very likely you can't. When you allocate memory, then deallocate it, the program may just keep it in use for future allocations. It's possible some tools, like maybe in Visual Studio show you exact usage but I wouldn't get your hopes up. — Tas, Jan 20 '20 at 05:02

eerorika · Accepted Answer · 2020-01-20T06:29:17.130

I know "deleting" only marks some memory locations to be "usable" but not actually wiping them out, is that the reason why RSS remains the same here?

Yes. The implementation of the (de-)allocation function often doesn't attempt to release memory to the operating system after every deallocation, but instead keeps the memory for further allocations to avoid the overhead of acquiring and releasing the memory.

Often the dynamic memory grows exactly like the stack in which case it and only be shrunk from the end. In such case, it would be quite unexpected if the resident set was reduced after the first deallocation because there was still an existing later allocation after it. After the second one, it might have been possible.

P.S. The GNU C library has a function malloc_trim that attempts to release memory from the heap, as well as mallopt that can be used to configure settings such as size threshold for automatic trimming.

how could I track the actual memory occupied at some point during the program?

It kind of depends on what you mean by "actual memory occupied". Do you consider the de-allocated memory that is still held by the process occupied or not?

You could replace the memory allocation function (i.e. malloc) to track every allocation (be careful not to track the allocation that you need for the data structure for the tracking or else you end up in an infinite loop). There is no standard way to do such replacement.

You call free with a pointer that you got from new[]. Behaviour of the program is undefined.

Resident Set Size remains the same after delete[]

1 Answers1

Linked