| commit | 0472b0d6e350702942c396ab26ecf6b7bc0e2356 | |
| author | Steffen (Daode) Nurpmeso <steffen@sdaoden.eu> | |
| Fri, 28 Oct 2016 22:10:28 +0000 (29 00:10 +0200) | ||
| committer | Steffen (Daode) Nurpmeso <steffen@sdaoden.eu> | |
| Sat, 31 Dec 2016 16:57:40 +0000 (31 17:57 +0100) | ||
| tree | 259b3cd97abc375d6a5fd00f6041c9c67b214082 | treesnapshot (tar.gz zip) |
| parent | c8f149c1aec81b534acc638cd960dd8f98d2c110 | commitdiff |
More or less completely rewrite memory.c..
One more great idea of the 70s which is finally replaced
completely: the string dope.
It was one of the first things that i have changed, if i recall
correctly: the buffer size of the string dope stuff.
But it always has been clear that this should have been changed
once MIME has been added to the code base, because of the high
memory peaks that this software has when iterating over all
messages in order, since the initial design only used the dope for
a rather small set of variables, the mailboxes where somewhat
smaller, but anyway no MIME decoding etc. was necessary back then.
So over time i have introduced string dope memory relaxation in
order to reduce the memory pressure, but in a recursive-by-design
codebase having a single arena of auto-reclaimed storage is weird
by design, and a single point of relaxation cannot be the final
solution.
So now that we have turned the software to be even more flexible
by dropping the restrictions of the input stack -- the other,
really brilliant i think, idea of the 70s that v14.9.0 will have
been dropped --, we should use the new context objects and glue
the memory they use to their very instance, being able to drop the
context and the memory it uses in one go. Rather a pity that this
hasn't been done this way once MIME has been introduced, the idea
is anything but new, and, e.g., the Apache web server used such
a throw-in-and-forget approach already around Y2K.
But that can't be helped.
While here unify the name scheme of the debug constants, and
entirely drop alloca(3) usage (including the OPT_NOALLOCA
configuration option), replacing it with a LastOutFirstIn memory
pool that is also glued to the current execution context. Over
time we can move over i think quite some use cases of
auto-reclaimed storage to this other form, being able to lower the
memory pressure even further, without putting any additional
pressure on the stack, but it will all stay on the heap / BSS.
What is still missing is a pool of page or say buffers so that
pages can be reused without going over the potentially slow native
allocator, but this is future enhancement.
One more great idea of the 70s which is finally replaced
completely: the string dope.
It was one of the first things that i have changed, if i recall
correctly: the buffer size of the string dope stuff.
But it always has been clear that this should have been changed
once MIME has been added to the code base, because of the high
memory peaks that this software has when iterating over all
messages in order, since the initial design only used the dope for
a rather small set of variables, the mailboxes where somewhat
smaller, but anyway no MIME decoding etc. was necessary back then.
So over time i have introduced string dope memory relaxation in
order to reduce the memory pressure, but in a recursive-by-design
codebase having a single arena of auto-reclaimed storage is weird
by design, and a single point of relaxation cannot be the final
solution.
So now that we have turned the software to be even more flexible
by dropping the restrictions of the input stack -- the other,
really brilliant i think, idea of the 70s that v14.9.0 will have
been dropped --, we should use the new context objects and glue
the memory they use to their very instance, being able to drop the
context and the memory it uses in one go. Rather a pity that this
hasn't been done this way once MIME has been introduced, the idea
is anything but new, and, e.g., the Apache web server used such
a throw-in-and-forget approach already around Y2K.
But that can't be helped.
While here unify the name scheme of the debug constants, and
entirely drop alloca(3) usage (including the OPT_NOALLOCA
configuration option), replacing it with a LastOutFirstIn memory
pool that is also glued to the current execution context. Over
time we can move over i think quite some use cases of
auto-reclaimed storage to this other form, being able to lower the
memory pressure even further, without putting any additional
pressure on the stack, but it will all stay on the heap / BSS.
What is still missing is a pool of page or say buffers so that
pages can be reused without going over the potentially slow native
allocator, but this is future enhancement.
18 files changed: