It depends where that memory lives.
region of the address space are `owned` by the C-Runtime heap.
till the heap is destroyed. You shoud call HeapDestroy() to reclaim those
This posting is provided "AS IS" with no warranties, and confers no rights.
Okay, so actually I can reproduce the problem on other computers, it's
just a matter of allocating even more. The code is below. When running
it on my laptop I get the following output:
Max malloc: 1560Mb
Max malloc: 1392Mb
The funny thing is that if I remove the deallocation I get the same
result. My guess is that deallocated memory is not released by the
operating system that keeps it for further allocations (and I guess
for small allocations only, since the huge chunk of memory allocated
by max_malloc (code below) is affected by this pool). If that
interpretation is correct, is there a way to tell Windows to release
(part of) this memory?
B.
<code>
#include <iostream>
#include <utility>
#include <vector>
using namespace std;
pair<void *, size_t> max_malloc()
{
const size_t mega = 1024*1024;
void * p = NULL;
size_t i;
for (i = 2048; i > 0; --i)
{
p = malloc(i*mega);
if (p) break;
}
return make_pair(p,i);
}
void print_max_malloc()
{
pair<void*, size_t> res = max_malloc();
cout << "Max malloc: " << res.second << "Mb" << endl;
free(res.first);
}
void alloc_dealloc()
{
const size_t N = 22000000;
vector<int*> v(N, 0);
size_t i;
for (i = 0; i < N; ++i)
{
v[i] = new int;
}
for (i = 0; i < N; ++i)
{
delete v[i];
v[i] = 0;
}
}
int main(int argc, char* argv[])
{
print_max_malloc();
alloc_dealloc();
print_max_malloc();
return 0;
}
</code>
On Mar 31, 3:09 pm, gao_bo...@voila.fr wrote:
Probably you caused an additional DLL to be loaded into your address
space.
Use Dependency Walker's profiling mode for example.
I didn't see anything like that, plus the allocation/deallocation part
is quite simple to need an additional DLL. Plus, as I said, the drop
in the size of the biggest chunk depends on the number of allocated
ints, which probably means that it isn't related to a fixed-factor
like a DLL.
Allocating 2GB isn't feasible, because you have only 2GB user address
space
(on 32-bit, unless you boot with /3GB option) and DLLs are loaded in
the
middle of that, so no block that large is available.
I am booting with the /3GB option indeed. Btw I checked that this is
not the pb, and it is not: without this option I start from 1.5GB down
to 1.3GB.
B.