On Tue, 19 May 1998, Sammy wrote:
>I was just kicking around the idea of a simple memory management wrapper.
>I don't think it would be anything fancy, just a simple addition to track
>and catagorize memory usage, automate some of the error handling, and
>offer a little protection. Here's a little mailer code to illustrate:
I did that with my Buffer System, it has a little flag in buffer.h for a
'BUFFER_MEMORY' flag you can turn on. It gets really slow when you do
that, but it does track all memory and report overruns. The only real
problem with it is that currently (on x86), it allocates a 28 byte
structure for tracking, even if you do a 1 byte allocation. :) I'll
probably separate the buffer/memory structures so that there is less
overhead in the future and my hash table should improve the speed. (On cue
for v1.8)
>I was thinking it'd be handy to have a period check of all memory blocks
>to make sure all the magic numbers are intact, and also an imm funciton
>that reports memory usage by type. If you have lots of types you can get
>some very detailed reporting.
It does magic number checking currently, when released. It does a report,
although the report by type would be nice. Unfortunately, it would be far
too much to list for all of the malloc() allocations.
>There really isn't that much more code to be written. The hard part is
>fixing all the existing CREATE's (if you want usage reporting, which was
>my original purpose for this). The free's could be changed with search
>and replace if all the CREATE's are done.
Not totally necessary. If something is allocated in 'parse_object', well,
you know what it is. :)
--
George Greer, greerga@circlemud.org | Genius may have its limitations, but
http://patches.van.ml.org/ | stupidity is not thus handicapped.
http://www.van.ml.org/CircleMUD/ | -- Elbert Hubbard
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST