Commit Graph

8 Commits

Author SHA1 Message Date
Ton Roosendaal
6d540b6333 More debug goodies:
WINDOWS CRASH EMULATION!

If you use the -d (debug) argument for starting blender, it will now:

- set all freed memory to 0xFFFFFFFF
- set all malloced memory to 0xFFFFFFFF

The first option will give nice crashers when you read from freed memory.
The second option is for OSX especially, it has the nasty habit to give
zeroed mallocs.
2006-11-27 13:59:55 +00:00
Brecht Van Lommel
e7d6537f1c Added support for threadsafe MEM_mallocN/MEM_freeN in the guardedalloc
module itself, replacing the special MEM_mallocT/MEM_freeT functions.
Mutex locking is only enabled when threads are running.

There was no good reason to have these separate, it just led to ugly
hacks when calling functions with non-threadsafe malloc from threads.
2006-09-06 19:13:23 +00:00
Ton Roosendaal
fe036a0538 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.
2006-02-16 17:51:01 +00:00
Daniel Dunbar
b6b352e0b7 - got fed up with not being able to put a breakpoint on MEM_
errors, switched MEM_set_error_stream to MEM_set_error_callback
   that calls a function to print result instead of just giving
   a FILE *

Note: requires intern recompile
2005-07-22 16:40:26 +00:00
Kent Mein
f78de74b20 WooHoo me again ;)
I took out the following from the includes in the intern dir that still had
it:
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif

Kent
--
mein@cs.umn.edu
2002-12-26 18:25:17 +00:00
Kent Mein
0fbadc8eb7 Yes I did it again ;)
added the following 3 lines to everything in the intern dir:
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

Kent
--
mein@cs.umn.edu
2002-11-25 09:53:07 +00:00
Kent Mein
01bff70383 fixed spacing in the headers to get rid of some warnings and some other
little minor spacing issues.
2002-10-30 02:07:20 +00:00
Hans Lambermont
12315f4d0e Initial revision 2002-10-12 11:37:38 +00:00