Amogh said:
What does this sentence mean ?
"A nonfragmenting memory allocator reaches steady state as soon
as it exercises all the parts of the application"
It helps when you provide the context for the quote. I found it at
http://www.ednasia.com/print.asp?id=182
which places special emphasis on memory allocation issues
for embedded systems.
Is steady state a state where the memory allocation routine is not
called upon to allocate more memory by the application ?
For example if I call malloc five times in my program, is the memory
allocator in a steady state after the last call to malloc? I could be
wrong. Please clarify.
In the context of the article, non-fragmenting memory allocation
regimes are not permitted to request dynamic memory allocation such as
via calls to malloc(). When it is known that there is no dynamic memory
allocation, then there is no heap, and all variables can be either
statically allocated or allocated on the stack at runtime, with the
stack memory being completely deallocated when the function returns. In
such a situation, there is no memory fragmentation, and if there is no
recursion then there is a sequence of calls that results in a maximal
memory allocation that will not be exceeded by any other call pattern.
The memory allocator at that point will have reached a "steady state"
in the sense that no -worse- memory usage will occur.
If recusion is added to the mix, then one still might be able to
get to the steady-state point, if one can prove upper bounds on
the recusion depth.
If dynamic memory allocation is added in, then a worst-case
analysis requires knowledge of the details of the memory allocation
strategy, together with firm upper bounds on variables, and firm
algorithm restrictions such that dynamically allocated memory
is always deallocated by the end of the routine that allocated it
[and that no persistant variable may be assigned a pointer into
dynamically allocated memory, so nothing keeps a handle onto
memory that is officially deallocated.] These are fairly strong
restrictions on the algorithms that seldom apply to programs
that are not specifically written for embedded (or "provably secure")
systems. Therefore if dynamic memory allocation is allowed,
then for -most- programs, one must Test! Test! Test! to be sure
that memory exhaustion through fragmentation will not occur.
