Reputation: 869
Our application allocates large std::vector<> of geometric coordinates -
it must be a vector (which means contiguous) because it eventually sent to OpenGL to draw model.
And Open GL works with contiguous data.
At some moment allocation fails which means that reserving memory throws std::bad_alloc exception.
However there is a lot of memory still free at this moment.
Problem is that contiguous block can not be allocated.
So the 1st two questions are:
Is there any way to control way in which CRT allocates memory? Or a way to defragment it (crazy idea))..
Maybe there is a way to check either run time can allocate block of memory of some size (not using try/catch).
Problem above was partially solved by fragmenting this one large vector to several vectors and calling OpenGL once for each of them.
However still there is a question how to define size of each smaller vector - if there are a lot of them with fairly small size we almost sure fit memory but there will be a lot of calls to OpenGL which will slow down visualization.
Upvotes: 0
Views: 1387
Reputation: 29559
You can't go beyond ~600MiB of contiguous memory in a 32-bit address space. Compile as 64-bit and run it on a 64-bit platform to get around this (hopefully forever).
That said, if you have such demanding memory requirements, you should look into a custom allocator. You can use a disk-backed allocation that will appear to the vector as memory-based storage. You can mmap the file for OpenGL.
Upvotes: 1
Reputation: 3281
If heap fragmentation really is your peoblem, and you're running on Windows then you might like to investigate the Low Fragmentation Heap options at http://msdn.microsoft.com/en-us/library/windows/desktop/aa366750(v=vs.85).aspx
Upvotes: 0