X-Sybari-Trust: 78bc0d57 9ffcebbb a5ee123c 00000138 From: Martin Stromberg Message-Id: <200303141601.RAA26911@lws256.lu.erisoft.se> Subject: Re: nmalloc revisited To: cbfalconer AT worldnet DOT att DOT net Date: Fri, 14 Mar 2003 17:01:46 +0100 (MET) Cc: djgpp-workers AT delorie DOT com (DJGPP-WORKERS) In-Reply-To: <3E71BD8C.654AA81B@yahoo.com> from "CBFalconer" at Mar 14, 2003 06:31:24 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk CBFalconer said: > Martin Stromberg wrote: > > > BTW the nmalloc.c code has not been altered since June 2002, and > > > the overall package is unaltered since November 2002 (some > > > documentation changes and testing). It remains available at: > > > > So it remains incompatible with the debugging machinery already > > present in DJGPP? > > > > I'll back out my local incorporation of it as it seems it never will > > be (and some DJGPP test case(s?) won't build). > > What won't build? I have never found any specification for the Some test case in djgpp/test. I don't remember exactly where but tests/libc/ansi/stdlib/ is not impossible. It tried to use the malloc debug hooks. > debugging systems, but the debug interface remains in nmalloc, You can't be using up-to-date information. It's checked in in CVS. You can get a current version of malloc.txh here: . > You can see the dramatic effects by trying evilalgo.c, or by > executing test 4 of the hashlib package for something like 40000 > allocations. nmalloc cuts the running time of that test by about > a factor of 60, all spent in the free routine. I agree that the current implementation has some problems. I think all on this list do so too and have for a long time. Your implementation has worked well for me (except for that test case above, which currently can't work). But I've mostly been rebuilding libc and the other DJGPP specific programs so I'm not sure that my environment is sufficiently stressful. Somebody needs to either rework your code into what's in the documentation or vice versa. That somebody doesn't exist. It's unlikely he'll appear. It's been like this a year or so. Hence, we will probably just patch up the current malloc implemention to avoid that evilalgo problem (not perfectly but workingly). Right, MartinS