Mail Archives: djgpp-workers/2002/02/11/13:38:07
> it appears as the alignment of malloc() follows the alignment of sbrk().
Yes, exactly correct.
> Is sbrk() supposed to return aligned pointers? If not, then malloc needs to
> deal with the misalignment.
sbrk() is not supposed to provide any alignment.
malloc() ideally should deal with the misalignment since user applications
might call sbrk() and screw up the alignment.
If we wanted to ignore the user screwed us up issue, then we could
investigate making sure that at least the first sbrk() returns aligned
memory and then the library always makes sbrk() requests in 8 byte
increments. This might be tough, since the user can specify the stack
size (sbrk'ed) as is the stubinfo.
> I'll take a look at the code. If I get in over my head, I'll ask for help.
> Perhaps the first thing I should do is to figure out the format of the block
> headers. Does anyone know what this is?
I took a quick look at fixing this. We should only have problems when
sbrk() is not what is expected - which is pretty well documented in the
code. 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. This should usually work.
When it doesn't is what's tricky - but maybe we just give up and return
the unaligned buffer. Or negative sbrk() the memory back. or whatever.
So, bug me if you get stuck.
One reason I think this is worth fixing is the reproducibility issue.
An application runs in 10 seconds. You run it again and it take 7
seconds. Then 10 seconds. All depending on what random alignment that
windows provided. Or you get different speeds on different platforms
that are alignment based, but you don't know it.
(I see it as a right thing to do issue more than a standards issue).
- Raw text -