Heap fragmentation and Low-fragmentation Heap

1. Heap fragmentation



Fragmenting a heap is something I haven’t worried about for years. When you allocate and deallocate memory in certain patterns you can leave areas of unallocated memory stranded inamongst allocated memory. This can lead to the situation where you have, say, 10Mb of memory free, but yet an allocation for 256 bytes fails as although you have all this free memory, none if it is in a big enough continuous lump to give you your 256 bytes.



http://xania.org/200512/crt-heap-fragmentation-in-windows


2. Low-fragmentation heap definition 



The LFH is not a separate heap. Instead, it is a policy that applications can enable for their heaps. When the LFH is enabled, the system allocates memory in certain predetermined sizes. When an application requests a memory allocation from a heap that has the LFH enabled, the system allocates the smallest block of memory that is large enough to contain the requested size. The system does not use the LFH for allocations larger than 16 KB, whether or not the LFH is enabled.


Applications that benefit most from the LFH are multi-threaded applications that allocate memory frequently and use a variety of allocation sizes under 16 KB. However, not all applications benefit from the LFH. To assess the effects of enabling the LFH in your application, use performance profiling data.



http://msdn.microsoft.com/en-us/library/aa366750%28VS.85%29.aspx


3. What is the cause of fragmentation



Imagine, for concreteness, a program that allocates memory in a loop like this:


* p1 = alloc(128)
* p2 = alloc(128)
* free(p1)
* p3 = alloc(96)
* (Keep p2 and p3 allocated.)
* Repeat


Under the classical model, when the request for 96 bytes comes in, the memory manager sees that 128-byte block (formerly known as p1) and splits it into two parts, a 96-byte block and a 32-byte block. The 96-byte block becomes block p3, and the 32-byte block sits around waiting for somebody to ask for 32 bytes (which never happens).



http://blogs.msdn.com/b/oldnewthing/archive/2010/04/29/10004218.aspx?PageIndex=2


4. Low-fragmentation heap in Visual Studio 2010 and Windows Vista/7



Generally speaking, the low-fragmentation heap works pretty well for most classes of applications, and you should consider using it. (In fact, I'm told that the C runtime libraries have converted the default C runtime heap to be a low-fragmentation heap starting in Visual Studio 2010.)



http://blogs.msdn.com/b/oldnewthing/archive/2010/04/29/10004218.aspx



Starting with Windows Vista, the system uses the low-fragmentation heap (LFH) as needed to service memory allocation requests. Applications do not need to enable the LFH for their heaps.



http://msdn.microsoft.com/en-us/library/aa366750%28VS.85%29.aspx


http://www.89teen.com


Why the low fragmentation heap (LFH) mechanism may be disabled on some computers that are running Windows Server 2003, Windows XP, or Windows 2000
http://support.microsoft.com/kb/929136


Chris Valasek, Understanding the Low-Fragmentation Heap: From Allocation to Exploitation
http://www.blackhat.com/html/bh-us-10/bh-us-10-briefings.html#Valasek
http://illmatics.com/Understanding_the_LFH.pdf



0 komentarze:

Prześlij komentarz

 
Tomasz Kulig