delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/03/02/10:43:42

X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3C80E4AF.BB20511F@phekda.freeserve.co.uk>
Date: Sat, 02 Mar 2002 14:41:51 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Malloc/free DJGPP code
References: <10202200445 DOT AA15769 AT clio DOT rice DOT edu>
Reply-To: djgpp-workers AT delorie DOT com

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019