Skip to main content

m$free behaviour

  • March 5, 2012
  • 6 replies
  • 0 views
D

[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.

    6 replies

    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • March 5, 2012

    [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.
    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?
    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • March 5, 2012

    [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.
    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?
    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • March 5, 2012

    [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.
    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?
    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • March 5, 2012

    [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.
    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.
    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • March 7, 2012

    [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.
    I finally find out that i had a big tricky memory leak in my program. Thank you for clarification.
    D
    • Dominique SacreRocketeer
    • Author
    • Rocketeer
    • 19312 replies
    • March 7, 2012

    [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.
    I finally find out that i had a big tricky memory leak in my program. Thank you for clarification.


    Terms & ConditionsAccessibility statement