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 /source/blender/blenlib
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 'source/blender/blenlib')
-rw-r--r--source/blender/blenlib/BLI_threads.h1
-rw-r--r--source/blender/blenlib/intern/threads.c8
2 files changed, 9 insertions, 0 deletions
diff --git a/source/blender/blenlib/BLI_threads.h b/source/blender/blenlib/BLI_threads.h
index 3791d92d6fc..6cbac55ac02 100644
--- a/source/blender/blenlib/BLI_threads.h
+++ b/source/blender/blenlib/BLI_threads.h
@@ -45,6 +45,7 @@ void BLI_unlock_thread (void);
/* threadsafe version of MEM_malloc and friends */
void *MEM_mallocT(int len, char *name);
void *MEM_callocT(int len, char *name);
+void *MEM_mapallocT(int len, char *name);
void MEM_freeT(void *poin);
#endif
diff --git a/source/blender/blenlib/intern/threads.c b/source/blender/blenlib/intern/threads.c
index d1a9183518e..712a6529348 100644
--- a/source/blender/blenlib/intern/threads.c
+++ b/source/blender/blenlib/intern/threads.c
@@ -220,6 +220,14 @@ void *MEM_callocT(int len, char *name)
if(_malloc_lock) SDL_mutexV(_malloc_lock);
return mem;
}
+void *MEM_mapallocT(int len, char *name)
+{
+ void *mem;
+ if(_malloc_lock) SDL_mutexP(_malloc_lock);
+ mem= MEM_mapallocN(len, name);
+ if(_malloc_lock) SDL_mutexV(_malloc_lock);
+ return mem;
+}
void MEM_freeT(void *poin)
{
if(_malloc_lock) SDL_mutexP(_malloc_lock);