Memory allocator for ifort runtime

Memory allocator for ifort runtime

I have an program running on "IA-32" (x86) that is running into address space exhaustion some time into a run, beyond the point at which I'd expect memory usage to have stabilised.  After spending some time investigating the behaviour of my program I'm starting to wonder whether I have a problem with memory fragmentation. 

What's the underlying allocatator that ifort uses for allocatables?  What sort of tools are available with that allocator for diagnosing memory fragmentation/memory leak issues? 

If I compile with /dbglibs can I use the the VC runtime debug support routines (_CrtMemCheckpoint et al.)? (Some simple tests made me think I could, but subsequently tracing the disassembly into the ifort runtime dll's makes me wonder whether that's really the case.  Perhaps it matters which form (static/dll) of the runtime is in use?)

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The runtime uses both malloc and VirtualAlloc (Windows API) depending on the sizw of the request. Unfortunately there aren't tools available for diagnosing such issues.

Retired 12/31/2016

Memory fragmentation issues can be observed by using:

Task Manager, Processes Tab, Memory

And monitoring usage as your application runs.

Heap fragmentation is caused by an unfortunate sequence of allocations and deallocations:

+big, +little, -big, +little, +big, ... (big creaping along the address range)

One fix for this is to construct a pool for your big allocations.

A second cause for this behavior is specifying too large of stack, then creating large numbers of threads.

Jim Dempsey

Ok - some further experimentation here shows that allocations <= 2**21 -1 in programs compiled /libs:static /dbglibs use the debug CRT allocation support.  None of my allocations exceed that so I don't have to worry about VirtualAlloc.  Diagnostics using the debug CRT routines that subsequently showed that the problem was a leak associated with an "overlooked" polymorphic allocatable component (not %$%$#@# again!! *kick*) and not fragmentation.

(There are instrumentation and diagnostic utilities for the heap support provided by the OS (that the C runtime ultimately uses) that can indicate whether fragmentation is an issue, but my experience is limited with them to the extent that I wasn't sure whether to believe the reports or whether ifort had its own allocatator that was confusing things.  After having looked at this over the last couple of days I suspect it would be reasonably straight foward to walk the OS heap manually and roll-your-own report.  Built in fortran runtime support for that could be handy... *nudge*)

How does the fortran DLL runtime "call malloc" without creating a dependency on a particular C runtime library version?  Do you do some sort of delay load trick?

Any particular reason why the debug DLL variant of the Fortran runtime doesn't use the debug variant of the C memory allocation routines?

It would be nice (*nudge*+1) if the debug Fortran runtime (even if only the static library variant) populated some of the debug fields in the allocated memory blocks (i.e. source file and line number, or is that already in the book keeping stuff for allocatables?).

Jim - the initial tool I was using to try and understand things was vmmap, which gives a lot more detail than what you get in task manager (not necessarily always a good thing, but sometimes more detail is handy).  I then (tried to) use(d) DebugDiag to get more details on the state of the relevant process heap. 

We go through a lot of effort to break the dependency on specific C run-time DLL versions, though I'm a bit fuzzy on the details. I do think that dynamic loading (not delay load) comes into play.

I will put in a feature request for diagnostic tools, including your suggestions.  Thanks.

Retired 12/31/2016

Assuming you accept the premis that the underlaying malloc and free (and equivelents) are bug free and thread safe, this leave activities performed by your application. Your application may be misbehaving (read or write memory not allocated and/or not as intended) or and unfortunated sequencing that leads to memory creap (as discussed earlier).

Misbehaving generally results in crash or peculiar runtime behavior. Using the CRTL debug heap functions can detect corruption of heap. As to locating point of corruption this may take considerable work.

Unfortunate sequencing of allocation/deallocation generally affect the largest allocations. Comparing the LOC(array) after allocations and watching the high watermark creap up is an indication of this (pogramictal way of observing process size creap up). *** do not use a C heap call to determine the amount of free memory, as this gives you the incorrect number. In the case of unfortunate sequencing of allocation/deallocation you will observe the amount of "free" heap growing (assuming how you obtain free heap indicates total program+stack+heap _committed - heap allocated). Note, some function calls for free memory include the Virtual Memory capacity that is not committed (to program, stack(s) and allocated heaps).

In the case of components (in your case polymorphic components) not being deleted, this is harder to catch and may be hidden excepting for the high watermark creap. What I would suggest here is to add conditional compile code that behaves much like a C++ ctor and dtor together with your polymorphic component allocation/deallocaton. Some coding here may catch the errors (your programming or in IVF) and may be instructive in helping you to write a work around.

Jim Dempsey

Leave a Comment

Please sign in to add a comment. Not a member? Join today