Highlighted
Absent Member.
Absent Member.
878 views

m$free behaviour

[Migrated content. Thread originally posted on 05 March 2012]

Hello, i'd like to comprehend the m$free behaviour in runtime >= 9 and in previous runtime versions. In our company we use it intensively and i noticed that when a significant amount of memory is allocated, say 60Mb, (not necessary contiguous, i.e. not to the same pointer), then the m$free doesn't free it when called.

Quoting the doc:

This memory is returned to the pool of memory available for use by the runtime. On most operating systems, this memory is still associated with the runtime's process, so it cannot be used by any other processes


Ok, following the doc i would expect the following behaviour (i observed the memory usage with the Windows 7 task manager):

1. Allocate a series of data structures --> wrun32 is 60Mb
2. deallocate all structures with m$free --> wrun32 is still 60Mb as the memory is usable only from the current process
3. Reallocate the same series of data structures --> wrun32 is still 60Mb as the runtime reused the previously freed memory

How it actually behaves:

3. Reallocate the same series of data structures --> wrun32 raise to around 120Mb

Moreover, i noticed that in runtimes = 9, a little amount of memory is still allocated after the m$free call.


Could you plese help me understand this? Is that a bug or this is the wanted behaviour? If so, it is not acceptable for our business context.
0 Likes
3 Replies
Highlighted
Absent Member.
Absent Member.

RE: m$free behaviour

Sorry, maybe it is possible that this is a bug of my program.

However could you please explain me which is the expected behaviour of m$free?
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: m$free behaviour

The M$ALLOC and M$FREE are mostly just thin wrappers around malloc() and free(). There is a small bit of overhead - the runtime keeps track of each memory block allocated by M$ALLOC, and its size, so that we can do the right thing if the runtime is running in thin client mode, and that pointer is sent to the thin client (we need to send the entire block in that case). But that's all that is done.

So, the simple answer to your question is that M$ALLOC and M$FREE should work the same as malloc() and free().

Note that memory allocation can be a tricky thing. If you have a program that allocates large and small blocks, and frees most of those, and then does it again, the memory may not land in the exact same spot, and so may actually need more memory than originally needed for the first set. And recall that the runtime itself is allocating memory around your calls to M$ALLOC, and may not free it when you call M$FREE, because the runtime is not done with that memory.

I hope this helps.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: m$free behaviour

I finally find out that i had a big tricky memory leak in my program. Thank you for clarification.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.