Mail Archives: djgpp/1996/05/02/06:21:36
> 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.
- Raw text -