Mail Archives: djgpp-workers/2002/03/08/19:47:32
Eli Zaretskii wrote:
>
> On Tue, 5 Mar 2002, CBFalconer wrote:
>
> > If you have a list we could have _sysmalloc take a record
> > parameter, consisting of an array of functional pointers, or
> > possibly an index/pointer pair to set/reset a specific hook.
>
> I can send you the CVS version of malloc, which calls hooks in several
> places (if you still don't have access to the CVS). Would that help?
I got all those and haven't taken a real look yet. It looks like
another system of some sort.
At any rate, I finally have some confidence that nmalloc and pals
is functional, at least sufficiently to start some real world
tests.
The last test I threw at it was 2000 allocations through the
following:
/* allocate random sizes, realloc, free, finally abort */
void test04(int n)
{
int i;
void *m[10] = {0};
void *temp;
for (i = 0; i < n; i++) {
nfree(m[i % 10]);
m[i % 10] = nmalloc(randomMT() % 10000);
temp = nrealloc(m[i % 10], randomMT() % 10000);
if (temp) m[i % 10] = temp;
if (0 == (i % 30)) (void)fakesbrk(3);
if (9 == (i % 10 )) xdumpfree();
}
for (i = 0; i < 10; i++) {
nfree(m[i]);
}
xdumpfree();
if (n & 1) {
printf("\nDeliberately refreeing pointer, should
abort\n\n");
nfree(m[0]);
}
} /* test04 */
which, with a minimum size to sbrk of 1024, resulted in 16 sbrk
calls, 5 of which had an 'unexpected' return (thus forcing a
separation of free blocks under management). At completion all
free blocks were collected together (as shown by the xdumpfree
routine, which shows the complete list and their sizes).
The fakesbrk calls forces various unexpected sbrk results, and the
xdumpfree monitors the state of the free chains at intervals.
Since the sizes requested were random in the range 1..9999 the
expected average memory in play is 50,000, with a max of 100,000.
The total memory under control at the end was about 121,000
(explained by fragmentation peaks). At 400 odd calls it was only
96,000.
Of 2000 realloc calls 998 were reductions in size, so no copying
was involved.
Of the remaining 1002 calls, 388 were satisfied by an adjacent
free block, 5 by expansion into the lastsbrk block (thus avoiding
all data copying). 607 were satisfied by an existing free block,
requiring copying, and 6 by a non-adjacent expansion into the
lastsbrk block, again requiring copying. The numbers don't add up
exactly because of the way I counted, which was off by 1 at
times. Interestingly none of the reallocations could be satisfied
by combining with a lower free block, but I think that is because
of the calling sequence above, since it is always reallocating a
freshly allocated block and there has been no chance for a lower
block to be freed. At any rate, about 40% of the size increases
totally avoided data copying. Again, that may be an artifact of
the calling sequence.
After a few more tests I suggest I ship it to DJ for mounting for
access and letting people test it out. After some of the subtle
bugs I found I fully agree that it needs a hard thrashing before
incorporation in the system. I have only had it running here for
the last couple of hours since the last changes.
The make file can make a system version of the object module
without source changes. Once that is done the only thing required
to use it somewhere is to link that ahead of the library.
Somebody before was objecting to the idea of releasing it under
the GLPL license. I am open to discussions about this.
--
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 -