Mail Archives: djgpp-workers/2002/02/11/14:58:50
> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Mon, 11 Feb 2002 12:38:13 -0600 (CST)
>
> 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.
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.
Am I missing something?
> 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'm seeing such phenomena for a very long time--Emacs on Windows
sometimes starts up in a slow variant: for example, the visual-bell
feature is noticeably slower in flashing the screen colors.
One can find my complaint about this perhaps 2 or 3 years ago; I think
even Eric was involved in that discussion. I always suspected that
it was some kind of alignment, but never had time to look into it.
- Raw text -