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.
Use of any included script samples are subject to the terms specified athttp://www.microsoft.com/info/cpyright.htm
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.