Oh! I know how the heap can fragment! The trick is knowing how to defrag it yourself. The app with the HUGE arrays allocated two arrays on the LOH. This app iterated over a set of data, over and over again, until a solution was found. The first array was the data from the last pass and the second was the data generated from the current pass. Well, pass after pass, the LOH grew and grew, faster than the amount of data that was generated. Weird - and very much like the OP's problem. The solution to implementing LOH compaction in this case was surprisingly easy. Since I only had two objects only needed one of them the next pass, I simply serialized the generated array to disk, disposed of both arrays, forced a GC, then deserialized the array from disk to put it at the bottom of the LOH. A poor-man's memory manager, if you will. According to the CLR Profiler and a bunch of testing, it worked beautifully! It's not the best performing solution, but I didn't need the app to respond between passes. Most of the apps time was spent crunching on that ever growing pile of data... Now, implementing something similar in the OP's case depends on his objects and requirements...
Dave Kreskowiak Microsoft MVP - Visual Basic
