Mail Archives: djgpp-workers/2002/12/08/23:25:51
> I don't know about realloc problems, but the motivation for
> writing nmalloc in the first place was the O(n) operation of
> free(), causing O(n*n) operation when freeing many components. At
> the same time I minimized data movement in realloc operation.
remove_freelist still does a linear search in all the blocks in the
current CVS release, so the free() performance problems still are there.
> **** Has anyone tried it out? ****
Martin Stromberg (in his message of 25 Nov 2002 09:14:28 MET) says:
**** Start message extract:
> contributed code. We could do a test build with the new malloc() hand
> inserted to see if most things behave properly. There is also a need
I did this, if building libc and the accompanying tools counts.
> to tweak interfaces or change documentation. Given the time limits
This hasn't had any progress. I'm waiting for the original author
(CBFalconer) (or somebody else) to correct these issues.
**** End message extract.
> I have finally been able to get some sort of documentation by
> extracting a section from a diff file for malloc.txh, stripping
> the left columns, and passing the result through makeinfo --html
> (with many errors reported, listed below as quote).
There is a program in the CVS tree built as mkdoc.exe from mkdoc.cc
(in the src\mkdoc directory) which does pre-processing.
> Of the routines listed, mallinfo is immediately implementable with
> no changes to nmalloc. I think the same applies to malloc_verify
> and mallocmap (the latter should not need any arming via
> malloc_debug). malloc_debug takes some thought, and some things
> are not clear. For example, nmalloc already signals when it
> encounters any heap corruption. The various hooks are also
> implementable, but would require small changes to nmalloc. In
> addition the documented offsets (magic number 4 etc) would be
> wrong, but there is already provision to expose the right
> numbers.
This is exactly the type of things we need help on moving it from a
prototype to final shipping code. There have also been fixes for
big fluffy malloc calls bigger than 2Gb, sbrk() alignment issues.
Still worried if anyone has tested it on Win95 with address wrap
when sbrk() blocks go negative (at address 0xffxxxxxx) and/or are not
always increasing.
> I suspect that documentation is also wrong for the existing library.
> AFAICT this documentation does not appear anywhere on my system.
This documentation is for the new release which hasn't been released
yet (but has been in development for around 3 years). Unless you have
downloaded a test build from one of the v2.04 alpha sites, or
been working with the CVS tree, you would not have seen it (even though
people are alreadying using it).
Momementum seems to be building to get a new release done "soon", where
soon < later ...
- Raw text -