On Wed, Aug 8, 2012 at 3:21 PM, Rick McGuire <[email protected]> wrote:
> I'm seeing the same growth with both versions and it looks like it is a > classic memory fragmentation problem. An external call context keeps a > hashtable of all object references it hands out to external functions like > SysFileTree that protects those objects from garbage collection. Because > SysFileTree is creating so many objects, this table gets very, very large > (needing a 19Mb block of storage). What is happening is the memory manager > can't find a sufficiently large block of storage, so it adds that to the > memory heap. This memory is then used for other allocations after the hash > table is garbage collection, so the next time a table of this size is > required again, there's no longer a contiguous block large enough to satisfy > the request, so we need to expand again. This basically keeps happening, so > the memory grows. > > The root cause of the problem is the large number of objects SysFileTree is > creating in a single call. All of those objects need to be protected until > the call completes...unless, that is SysFileTree says it is ok to stop > protecting those objects. This will require a few changes to SysFileTree. > For example, there are many lines like this in SysFileTree: > > c->SetStemArrayElement(treeData->files, treeData->count, > c->String(dFoundFile)); > > This needs to be changed to something like this: > > > RexxString temp = c->String(dFoundFile); > > c->SetStemArrayElement(treeData->files, treeData->count, temp); > > c->ReleaseLocalReference(temp); > > > This will keep the local reference table at a reasonable size throughout > this process. Okay, thanks for taking a look at it. And thanks for the advice. I'll fix that up. -- Mark Miesfeld ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
