Mail Archives: djgpp-workers/2002/03/02/10:43:42
Hello.
Charles Sandmann wrote:
> Two potential patches vs 2.03 (not yet committed to CVS):
>
> First version (probably faster but bigger, extra code only if new
> sbrk is not aligned, the reactive patch):
>
> *** malloc.c_ Wed Dec 5 14:52:52 2001
> --- malloc.c Mon Feb 11 22:22:32 2002
> *************** malloc(size_t size)
> *** 208,215 ****
> --- 208,222 ----
> rv = (BLOCK *)((char *)rv - 4);
> }
> else
> {
> + int align_bytes = (int)rv & (ALIGN-1);
> + if(align_bytes)
> + {
> + align_bytes = ALIGN - align_bytes;
> + if(sbrk(align_bytes) == (void *)((char *)rv + chunk_size) )
> + rv = (BLOCK *)((char *)rv + align_bytes);
> + }
> expected_sbrk = (BLOCK *)((char *)rv + chunk_size);
> #if DEBUG
> printf(" disconnected sbrk\n");
> #endif
>
> Second version (slower - extra sbrk and brk called for each sbrk but only
> execute about 20 assembly lines, smaller code, the proactive patch):
>
> *** malloc.c_ Wed Dec 5 14:52:52 2001
> --- malloc.c Tue Feb 12 10:52:20 2002
> *************** malloc(size_t size)
> *** 192,195 ****
> --- 192,196 ----
> }
>
> + brk((void *)( ((int)sbrk(0)+(ALIGN-1)) & ~(ALIGN-1) )); /* Align next sbrk */
> chunk_size = size+16; /* two ends plus two placeholders */
> rv = (BLOCK *)sbrk(chunk_size);
>
> I posted both; little feedback on which should be committed. But it's
> important that the block overhead be a factor of the alignment or you
> will almost never merge blocks.
Personally I think we should go for the faster patch - the first one - since
the code overhead doesn't look that great.
Thanks, bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -