Mail Archives: djgpp-workers/2002/02/24/14:34:25
> I have come to a point in my rework of malloc (which will
> eventually be available for evaluation and inclusion or not as
> desired) where I have to make a subtly major revision. The problem
> is that I have not been able to capture good regression tests,
> because the output depends on the behaviour of sbrk, and the
> result will be more detailed perusing of debug outputs.
Run the tests under DOS using CWSDPMI. It will always give you
reproducible sbrk() behavior since it has control of the memory.
Windows is a bad environment for testing, since your timing results
may change as it decides to do things in the background for you,
or can change the memory layout on back to back runs.
> This could all be cured by a semi-portable implementation of, say,
> "fakesbrk" which will return a repeatable set of addresses under
> the same circumstances. It might actually malloc a large block
> which contains those addresses to be faked. But how can it ensure
> that a certain range is available to any degree of certainty, or
> even of probability? This might in turn require a fake dpsmi
> implementation, which is getting ridiculous. The addresses
> returned have to be usable.
Other implementations will suffer from slightly different behavior,
so it's not a good idea to try to fake it, when there is an environment
which will be reproducible. For example, the real sbrk() manages
the DPMI memory with internal 64K aligned blocks, and hides multiple
DPMI memory blocks from malloc() if they are adjacent, etc.
> Any ideas? So far much more effort has gone into providing clear
> debug output than in actually programming the beast, but I believe
> the result is worthwhile.
DOS/CWSDPMI (with sufficient physical memory so you don't page) is
the best way to get behavior to compare against.
Once that is done you also need to run under some Windows environments
which can return memory blocks in random order, so the next sbrk() you
request may be BELOW the previous one. Many documented malloc() algorithms
break when this happens, so it must be tested. This may be hard to get
windows to do - but I've found running multiple DJGPP images (running,
exiting, running, in a loop) at once in different windows, with a Windows
application also running (doing something) is a great way to check memory
fragmentation behavior.
You also need to test the case of calling sbrk() manually between malloc
calls to make sure this works.
You could put a wrapper around sbrk() to create a block sequence if needed
for functional behavior, but it's probably not a good performance test
method.
- Raw text -