blender/intern/guardedalloc/MEM_guardedalloc.h

137 lines
4.1 KiB
C
Raw Normal View History

2002-10-12 11:37:38 +00:00
/**
* $Id$
* ***** BEGIN GPL LICENSE BLOCK *****
2002-10-12 11:37:38 +00:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
2002-10-12 11:37:38 +00:00
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): none yet.
*
* ***** END GPL LICENSE BLOCK *****
2002-10-12 11:37:38 +00:00
*/
/**
* Copyright (C) 2001 NaN Technologies B.V.
* Guarded memory (de)allocation
*
*
* @mainpage MEM - c-style guarded memory allocation
*
* @section about About the MEM module
*
* MEM provides guarded malloc/calloc calls. All memory is enclosed by
* pads, to detect out-of-bound writes. All blocks are placed in a
* linked list, so they remain reachable at all times. There is no
* back-up in case the linked-list related data is lost.
*
* @section issues Known issues with MEM
*
* There are currently no known issues with MEM. Note that there is a
* second intern/ module with MEM_ prefix, for use in c++.
*
* @section dependencies Dependencies
*
* - stdlib
*
* - stdio
*
* */
#ifndef MEM_MALLOCN_H
#define MEM_MALLOCN_H
#include "stdio.h" /* needed for FILE* */
#include "BLO_sys_types.h" /* needed for uintptr_t */
2002-10-12 11:37:38 +00:00
#ifdef __cplusplus
extern "C" {
#endif
/** Returns the lenght of the allocated memory segment pointed at
* by vmemh. If the pointer was not previously allocated by this
* module, the result is undefined.*/
int MEM_allocN_len(void *vmemh);
/**
* Release memory previously allocatred by this module.
*/
short MEM_freeN(void *vmemh);
/**
* Duplicates a block of memory, and returns a pointer to the
* newly allocated block. */
void *MEM_dupallocN(void *vmemh);
/**
* 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 ! */
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
void *MEM_callocN(unsigned int len, const char * str);
2002-10-12 11:37:38 +00:00
/** Allocate a block of memory of size len, with tag name str. The
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
* 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);
2002-10-12 11:37:38 +00:00
/** Print a list of the names and sizes of all allocated memory
* blocks. as a python dict for easy investigation */
void MEM_printmemlist_pydict(void);
2002-10-12 11:37:38 +00:00
/** Print a list of the names and sizes of all allocated memory
* blocks. */
void MEM_printmemlist(void);
/** Print statistics about memory usage */
void MEM_printmemlist_stats(void);
/** Set the callback function for error output. */
void MEM_set_error_callback(void (*func)(char *));
2002-10-12 11:37:38 +00:00
/**
* Are the start/end block markers still correct ?
*
* @retval 0 for correct memory, 1 for corrupted memory. */
int MEM_check_memory_integrity(void);
/** Set thread locking functions for safe memory allocation from multiple
threads, pass NULL pointers to disable thread locking again. */
void MEM_set_lock_callback(void (*lock)(void), void (*unlock)(void));
/** Attempt to enforce OSX (or other OS's) to have malloc and stack nonzero */
void MEM_set_memory_debug(void);
/* Memory usage stats
* - MEM_get_memory_in_use is all memory
* - MEM_get_mapped_memory_in_use is a subset of all memory */
uintptr_t MEM_get_memory_in_use(void);
uintptr_t MEM_get_mapped_memory_in_use(void);
int MEM_get_memory_blocks_in_use(void);
2002-10-12 11:37:38 +00:00
#ifdef __cplusplus
}
#endif
#endif