Mail Archives: djgpp-workers/2002/02/11/15:24:50
> > If it returns an address which isn't aligned it gets a bit ugly.
> > I suggest we sbrk() another 1-7 bytes at that point hoping it will be
> > contig at the end of the current allocation.
>
> Why not simply throw out those 7 bytes (in practice, probably just 4
> bytes, since Windows and CWSDPMI align on 4-byte boundary), by finding
> the next 8-byte aligned address, and starting to work from there.
We compute the size we want today, and sbrk() it. If it returns
unaligned quite often we don't have any additional bytes to discard
from the sbrk(). That's why I suggested the tiny additional sbrk().
Windows and CWSDPMI (and almost all DPMI providers) will provide
DPMI blocks on page boundaries, and sbrk() does sizes in 64Kb chunks,
and malloc only asks for items in 8byte chunks, so I think a 1-7 byte
request would always be in the same memory zone, and right after the
original request (which would allow us to align shift up a few bytes).
If we are near an sbrk() boundary (different memory zone) then the extra
few bytes might not be satisfied at the end - but this is only if the
logic above is messed up...
> Since malloc rounds the size to a multiple of 8 bytes, the rest should
> be fine as long as we get contiguous memory. Whenever we get
> noncontiguous chunk, we can again align its beginning and continue.
Agreed. (This is all in one place - probably 2-3 lines of code).
Another idea:
We could add a sbrk(0) call before calling sbrk() with the expected
size - and if it's aligned the sbrk() value should be also. If
sbrk(0) not aligned, we sbrk() the small number of bytes to align -
which will always work (unless there's a equality bug right at the
boundary in sbrk...)
A new DPMI block allocation is always aligned (pmode may only be
paragraph aligned instead of page, but that should be good enough).
By the way, I think the reason we are off by 4 is stubinfo is 0x54
bytes and it's the very first thing we sbrk() :-P
- Raw text -