Mail Archives: djgpp-workers/2002/02/28/13:14:06
Charles Sandmann wrote:
>
> One quick comment: The block overhead moves from 8 bytes per malloc to
> 32 bytes per malloc. For lots of small allocations this could be a
> problem on small memory machines. I'd prefer to remove the guardhi 8 bytes
> to reduce the overhead to 24 bytes per block, or to move all of the
> information before the block and plan to align on 16-byte boundaries.
The whole guardhi block can be removed entirely without affecting
anything (except the DATAOFFSET macro). Its sole purpose is to
protect against user misuse (one off addressing) clobbering the
memory arena. The guardlo has a dual purpose, guarding and
alignment. I threw in the initialization to DEADBEEF, BEEFDEAD,
F00DFEED etc. just for sport and to make memory dumps obvious.
I am working on the realloc mechanism now, and it looks as if it
is going to be able to avoid most of the copying in the most
common user sequences, such as while more input double (or
otherwise extend) the buffer size.
When realloc is done I will be able to run some comparisons
against the old version with the software that exposed the free
problem in the first place. That will also check compatibility
with the rest of the run-time.
Something that might be considered is a standard trap when
inconsistent memory structure is detected, to abort the user
program with suitable info as early as possible. None of this
affects the basic design.
What do you think about the debuggery system linkage, in my 4:50
am today message?
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT XXXXworldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:uce AT ftc DOT gov (for spambots to harvest)
- Raw text -