---

GNU General Public License

VMem is licensed under a dual licence. For non-commercial use VMem is governed by the GNU General Public License,version 3.0 as published by the Free Software Foundation.

---

Commercial License

Because of the restrictions imposed by the GPL license (you must make your code open-source), commercial users of VMem can purchase non-GPL licenses. Click here to see the pricing for commercial licenses, and the End User License Agreement (EULA).

---

Overview

VMem is the culmination of over 10 years of experience in writing memory allocators. It is a general purpose C++ allocator, which can be used to replace the standard malloc. VMem has been used in multiple large scale projects that have sold many millions of copies. Games software is one of the most demanding types of software for memory allocators, with millions of lines of code, tens of thousands of allocations per second, multiple threads with high contention, a fixed memory limit (on consoles) and highly variable allocation patterns. They also have to be able to run continuously for up to 24 hours without fragmentation or running out of memory. What is needed is an allocator with a small memory footprint, that performs well under high contention, has very low loss to fragmentation and is dynamic and scaleable, and, most importantly, is fast. Enter VMem.

Not all allocators are created equal. Some perform better in certain circumstances than others. It is easy to devise a test that shows that ones allocator is better than the competition, but the only way to really test an allocator is to drop it into a large project and measure it. VMem has been compared against all of the other major allocators, measuring speed, overhead and fragmentation. VMem performed better than any other allocator in all measurable ways.

How does VMem achieve this? Well, it is not lock-free, but carefully placed locks means that under reasonable usage it's actually faster than most lock-free algorithms. It aggressively decommits pages back to the system as soon as they are empty, and it uses the concept of 'biasing' to reduce fragmentation. Agressive decommitting and biasing are unique to VMem. You can find out more about how VMem works in the technical documentation.

The V in VMem is for Virtual (or Very fast, or Very small) because it depends on virtual memory. Most allocators work by allocating memory from the system in large chunks. This is very wasteful. VMem only reserves the memory in chunks, and commits and decommits pages as necessary. This means that all allocators in VMem dynamically resize themselves to use up the smallest amount of memory possible.

VMem is currently implemented only for Windows platforms. The platform dependent code is only a few functions contained in a single file, so it should be simple to port to any machine that has virtual memory.

Another benefit of using VMem is that, unlike most allocators, the code is clean and readable. It also has extensive error checking that can be enabled for catching those hard to track down memory corruption bugs.

---

Feedback

If you find bugs or would like to request a feature please let me know.
To keep informed about updates you can subscribe to my newsletter here.

name:

email:

---

Versions

31/07/2012		1.04
	-	MemPro stats - added functions to send stats to MemPro
	-	Fixed a couple of places that would crash on an out of memory. VMem will now always return NULL on an OOM.
	-	Defined some debug code out entirely in the integrity checking code, just in case compiler doesn't do it.
	-	Added some extra asserts to FSA::Free to catch bad pointers
	-	Changed memcpy calls to the safe memcpy_s functions
	-	Improved the VMem function tests. Threaded tests could sometimes generate a false positive leak error.
	-	Added MEMPRO define to enable MemPro allocation tracking in VMemNew.hpp

---

27/06/2012		1.03
	-	Made SpinLock class use system critical section so that it copes with priority inversions
	-	destroy critical section in SpinLock destructor
	-	construct g_VMemCoreSpinLock and g_RecordSpinLock in VMem initialisation so that they are constructed before other globals. This could theoretically possibly have caused a race condition on allocations that happen during global initialisation, although I've never seen it occur

---

14/01/2012		1.02
	-	Double free detection
	-	Settable function pointer for DebugBreak
	-	Optional overriding of malloc with the OVERRIDE_MALLOC define
	-	Comment in VMemDefs.hpp
	-	Moved VMEM_COALESCE_GUARDS into minimal checking because it is relatively cheap
	-	Functional test for double free

---

16/08/2011		1.0
	-	VMem Release

---

23/11/2011		1.01
	-	Fixed compile error if VMEM_STATS is defined but not VMEM_ASSERTS
	-	Made GetSize lock free. Speeds up Realloc by removing a global sync point. In my tests Realloc is x2 faster. This is on the USE_LOCKFREE_REGION_ARRAY define.
	-	Assert check for reallocing an invalid pointer
	-	Unit test for realloc
	-	Versioning

---

2004 - 2011

Previous incarnations of VMem known as XMem and MemSys