Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTon Roosendaal <ton@blender.org>2006-02-16 20:51:01 +0300
committerTon Roosendaal <ton@blender.org>2006-02-16 20:51:01 +0300
commitfe036a0538860bf4f0b8e87d70046ff2a75f5f28 (patch)
treec6838cde34a609ea4832b98303c683fe90fd3edd /intern/guardedalloc/MEM_guardedalloc.h
parent7f4b01ccf076998cac98c52aa6701f35e1c2500f (diff)
Added new malloc type in our MEM module; using the unix feature 'mmap'.
In Orange we've been fighting the past weeks with memory usage a lot... at the moment incredible huge scenes are being rendered, with multiple layers and all compositing, stressing limits of memory a lot. I had hoped that less frequently used blocks would be swapped away nicely, so fragmented memory could survive. Unfortunately (in OSX) the malloc range is limited to 2 GB only (upped half of address space). Other OS's have a limit too, but typically larger afaik. Now here's mmap to the rescue! It has a very nice feature to map to a virtual (non existing) file, allowing to allocate disk-mapped memory on the fly. For as long there's real memory it works nearly as fast as a regular malloc, and when you go to the swap boundary, it knows nicely what to swap first. The upcoming commit will use mmap for all large memory blocks, like the composit stack, render layers, lamp buffers and images. Tested here on my 1 GB system, and compositing huge images with a total of 2.5 gig still works acceptable here. :) http://www.blender.org/bf/memory.jpg This is a silly composit test, using 64 MB images with a load of nodes. Check the header print... the (2323.33M) is the mmap disk-cache in use. BTW: note that is still limited to the virtual address space of 4 GB. The new call is: MEM_mapalloc() Per definition, mmap() returns zero'ed memory, so a calloc isn't required. For Windows there's no mmap() available, but I'm pretty sure there's an equivalent. Windows gurus here are invited to insert that here in code! At the moment it's nicely ifdeffed, so for Windows the mmap defaults to a regular alloc.
Diffstat (limited to 'intern/guardedalloc/MEM_guardedalloc.h')
-rw-r--r--intern/guardedalloc/MEM_guardedalloc.h13
1 files changed, 9 insertions, 4 deletions
diff --git a/intern/guardedalloc/MEM_guardedalloc.h b/intern/guardedalloc/MEM_guardedalloc.h
index e909e7eee45..c9338d0ae8a 100644
--- a/intern/guardedalloc/MEM_guardedalloc.h
+++ b/intern/guardedalloc/MEM_guardedalloc.h
@@ -87,12 +87,17 @@ extern "C" {
* Allocate a block of memory of size len, with tag name str. The
* memory is cleared. The name must be static, because only a
* pointer to it is stored ! */
- void *MEM_callocN(unsigned int len, char * str);
+ void *MEM_callocN(unsigned int len, const char * str);
/** Allocate a block of memory of size len, with tag name str. The
- * name must be a static, because only a pointer to it is stored !
- * */
- void *MEM_mallocN(unsigned int len, char * str);
+ * name must be a static, because only a pointer to it is stored !
+ * */
+ void *MEM_mallocN(unsigned int len, const char * str);
+
+ /** Same as callocN, clears memory and uses mmap (disk cached) if supported.
+ Can be free'd with MEM_freeN as usual.
+ * */
+ void *MEM_mapallocN(unsigned int len, const char * str);
/** Print a list of the names and sizes of all allocated memory
* blocks. */