- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm having problems with a large fortran application running out of memory. There should be enough memory available, so my working thesis, is that memory get fragmented.
I'm allocating both large memoryblocksand smaller ones. Let me try to explain the "pattern" used. I allocate a large array of structures and to each element in this structure (structure containsa number of pointers) there will be done an allocation of smaller array of smaller structures.
From time to time, there is a need to reallocate these structures tohandle "incoming data". It is during such a reallocationsituation, that I do experience "out of memory" conditions.Since it's quite a big application, there are many places where other allocations take place and might be the cause.
In order to try to figure out what was going on, I did implement - based on one of the examples - a low level memory display routine based upon the kernel routine VIRTUALQUERY. Inspecting the results, there was an observation, that did puzzle me a bit. Sample code attached.
What I did observe was - the memory status on blocks after allocation and after deallocation. It puzzles me that e.g. a block of allocated memory of 1024 KB with Memory status COMMIT was split in two parts one 8KB block with COMMIT status and a 1016 block with a status of RESERVED. I would expect this block to be set to status FREE (see attached picture file for detailed information). When the "large block" is deallocated the memory status is set to FREE.
I know that fortran runtime might keep the memory in RESERVED status and the later reuse it - most likely in order to avoid fragmentation.
When "same" structures are allocated once more I can see, that the RESERVED & small COMMIT memory blocks are reused.
But I'm still wondering if this runtime behavior could lead to memory fragmentation - especially when larger blocks are to be allocated.
Any ideas or comments would be appreciated, since I'm stuck in coming up with a fix to the memory allocation problem.
Allan
I'm allocating both large memoryblocksand smaller ones. Let me try to explain the "pattern" used. I allocate a large array of structures and to each element in this structure (structure containsa number of pointers) there will be done an allocation of smaller array of smaller structures.
From time to time, there is a need to reallocate these structures tohandle "incoming data". It is during such a reallocationsituation, that I do experience "out of memory" conditions.Since it's quite a big application, there are many places where other allocations take place and might be the cause.
In order to try to figure out what was going on, I did implement - based on one of the examples - a low level memory display routine based upon the kernel routine VIRTUALQUERY. Inspecting the results, there was an observation, that did puzzle me a bit. Sample code attached.
What I did observe was - the memory status on blocks after allocation and after deallocation. It puzzles me that e.g. a block of allocated memory of 1024 KB with Memory status COMMIT was split in two parts one 8KB block with COMMIT status and a 1016 block with a status of RESERVED. I would expect this block to be set to status FREE (see attached picture file for detailed information). When the "large block" is deallocated the memory status is set to FREE.
I know that fortran runtime might keep the memory in RESERVED status and the later reuse it - most likely in order to avoid fragmentation.
When "same" structures are allocated once more I can see, that the RESERVED & small COMMIT memory blocks are reused.
But I'm still wondering if this runtime behavior could lead to memory fragmentation - especially when larger blocks are to be allocated.
Any ideas or comments would be appreciated, since I'm stuck in coming up with a fix to the memory allocation problem.
Allan
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"There should be enough memory available"
Do you have a basis for this statement? Or is it based on a certain memory allocation model that you have a mental picture of, but probably different from the one implemented in the compiler?
The compiler will automatically allocate local arrays (with size possibly dependent on integer arguments to the routine) on the stack and deallocate them when the routine completes. You may be able to convert some of your explicitly-allocated-on-the-heap arrays to automatic local arrays.
Also see the /assume:realloc_lhs compiler option.
Do you have a basis for this statement? Or is it based on a certain memory allocation model that you have a mental picture of, but probably different from the one implemented in the compiler?
The compiler will automatically allocate local arrays (with size possibly dependent on integer arguments to the routine) on the stack and deallocate them when the routine completes. You may be able to convert some of your explicitly-allocated-on-the-heap arrays to automatic local arrays.
Also see the /assume:realloc_lhs compiler option.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page