Xref: news2.mv.net comp.os.msdos.djgpp:3331 From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: V2 vs. 1.12m5 Date: Wed, 01 May 1996 08:07:55 CDT Organization: Rice University, Houston, Texas Lines: 51 Message-ID: <3187622b.sandmann@clio.rice.edu> References: <4m5cd7$10v AT fnnews DOT fnal DOT gov> <31862D90 DOT 407C AT Mathematik DOT tu-chemnitz DOT de> <4m5nlb$cib AT news DOT wco DOT com> Reply-To: sandmann AT clio DOT rice DOT edu NNTP-Posting-Host: clio.rice.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp > I also have to use the unix sbrk algorithm (until I write my own heap > functions). It's not a problem, it seems to work fine. In most cases I would expect it to, since it's the algorithm that V1.x used and V2 used until beta 3. > However, I'd like > to know what tradeoff I'm making. Is malloc() slower under the unix sbrk? > Does it take more memory for housekeeping? There's gotta be a catch! There should be no noticeable speed difference between the methods. Unix sbrk() is hard to use with near pointers, since it will move the base of memory in some cases, which requires re-computing those pointers. Unix sbrk() moves the memory base, which can cause HW interrupt handlers to lock up the machine if the DPMI provider has bugs in it's interrupt disable routines (many do!) Unix sbrk() requires a single contigous memory region, so some DPMI providers cannot allocate as much memory using this algorithm. Unix sbrk() uses the resize memory block dpmi command, which doesn't work with virtual memory on most QDPMI versions. The status of locked pages is ambigous in the DPMI spec on a memory move. New sbrk() allocates a different DPMI memory zone for each sbrk() call (with some pooling to keep a minimum 64K allocation). This can cause problems if the DPMI provider runs out of memory zones (CWSDPMI bug, QDPMI limits). (Note: 64K * 256 zones = 16Mb in "small" pieces) New sbrk() must also keep track of all the zones and release them on image exit (small speed penalty). Memory mapping/protection is more complicated with the new sbrk(). New sbrk() must deal with memory zones that may not be contiguous or may not even increase in virtual address. Under weird behaving DPMI providers this may mean that sbrk(0) is completely undefined, that your memory spans the memory of other programs (even Win programs, for example) and in the worse case may require a selector limit wrap. If wrap is required, and the DPMI provider doesn't support FAT DS limits, the New sbrk() will fail to work in that environment completely. So - there is no one good algorithm due to DPMI 0.9 limitations. Application note: If you set the application up with unix sbrk() flag in crt0_startup_flags, you can then change to new sbrk() on the fly without problems. This is probably the most "compatible" mode - to start with unixy and then toggle if and only if New sbrk() features are needed and supported. You can't change back to unix sbrk() from new sbrk() however - almost certain crash.