<html><body><div style="color:#000; background-color:#fff; font-family:Courier New, courier, monaco, monospace, sans-serif;font-size:10pt"><div><span>What can be done to combat this in C++/Qt?</span></div><div><span><br></span></div><div><span>Initially I thought there might be some kind of QObject d-ptr magic where the large allocations can be in the private class and re-allocate and copy the private class, without affecting the pointers that the application uses. Then have a function that runs on a QObject tree,  This does not fix the overall issue, but at least it could decrease the the chances of a failed allocation. But for me, this raises as many questions as it solves. Can we guarantee the new allocations are more compact than the old ones? That seems up to the heap manager. I don't know much about that. Also, when to run it? Periodically, or only when an allocation fails?</span></div><div><br><span></span></div><div><span>I've got a very
 long process that I want to protect against this. Switching to 64bit is not an option for at least another 10 years. <br></span></div><div><span><br></span></div><div><br></div>  <div style="font-family: Courier New, courier, monaco, monospace, sans-serif; font-size: 10pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1">  <b><span style="font-weight:bold;">From:</span></b> Thiago Macieira <thiago.macieira@intel.com><br> <b><span style="font-weight: bold;">To:</span></b> interest@qt-project.org <br> <b><span style="font-weight: bold;">Sent:</span></b> Monday, August 20, 2012 11:23 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [Interest] memory fragmentation?<br> </font> </div> <br>
On segunda-feira, 20 de agosto de 2012 07.56.36, Jason H wrote:<br>> In comparing technologies (Qt vs .NET) one of the biggest architectural<br>> differences is the garbage collection model.<br>> <br>> <br>> Qt uses the standard C++ new/free, where .NET uses a garbage collector.<br>> Interestingly the GC not only manages overall usage, but can move objects<br>> around in memory. This is the prupose fo the ^ operator in their C++/CLI -<br>> it's a memory handle that is used to reference an object instead of a<br>> pointer, because the GC can change the address.<br>> <br>> In the entirety of my computing experience I have never seen a malloc or new<br>> fail because of memory fragmentation. Is this some low-level MS FUD?<br><br>No. It's a non-theoretical situation. It can happen.<br><br>Take, for example, a 32-bit application running on a 32-bit Linux. It has 3 GB <br>of addressing space. Since it's using some of it when
 it starts up, it has <br>less than 3 GB available for use.<br><br>Try this:<br>    malloc(1 GB);<br>    malloc(100 MB);<br>    free(the 1 GB block)<br>    malloc(2 GB);<br><br>There's a big chance it will fail, even though there's still roughly 2.8 GB of <br>addressing space available.<br><br>The above is, of course, an academic exercise. If your application is going to <br>use blocks in the order of gigabytes, you should be using 64-bit.<br><br>In a real-world case, memory fragmentation usually influences the total memory <br>usage of an application. Even if large chunks of memory are freed, they can't <br>be returned to the operating system because the application is still using <br>blocks further down the heap. Also, it might increase its consumption if it <br>does operations like:<br><br>    ptr1 = malloc(BIG);<br>    ptr2 = malloc(SMALL);<br>   
 free(ptr1);<br>    ptr3 = malloc(SMALL);<br>    ptr4 = malloc(BIG);<br>    free(ptr2);<br>    free(ptr3);<br>    return ptr4;<br><br>In a zero-overhead allocator, ptr1 = ptr2 + BIG and ptr3 = ptr1. That means <br>the room between ptr3 and ptr1 is only BIG - SMALL, which isn't big enough to <br>satisfy the fourth malloc. That code above will extend the heap by at least <br>2*BIG + SMALL, even though it only had BIG + 2*SMALL amount of memory <br>allocated at any given time.<br><br>E.g., for BIG = 65536 (64k) and SMALL = 16, the heap was extended by at least <br>128k + 16 bytes, even though the function actually allocated only 64k + 32 <br>bytes.<br><br>If that operation is repeated in a loop, the heap might grow a lot. This is <br>known to happen under certain circumstances for Qt, for example: memory <br>allocations for QStrings, QByteArrays and QEvents, though small, happen
 quite <br>often.<br><br><br>-- <br>Thiago Macieira - thiago.macieira (AT) <a target="_blank" href="http://intel.com/">intel.com</a><br>  Software Architect - Intel Open Source Technology Center<br>     Intel Sweden AB - Registration Number: 556189-6027<br>     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden<br><br>_______________________________________________<br>Interest mailing list<br><a ymailto="mailto:Interest@qt-project.org" href="mailto:Interest@qt-project.org">Interest@qt-project.org</a><br><a href="http://lists.qt-project.org/mailman/listinfo/interest" target="_blank">http://lists.qt-project.org/mailman/listinfo/interest</a><br><br><br> </div> </div>  </div></body></html>