delorie.com/archives/browse.cgi | search |
Date: | Sat, 04 Aug 2001 11:02:56 +0300 |
From: | "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il> |
Sender: | halo1 AT zahav DOT net DOT il |
To: | sandmann AT clio DOT rice DOT edu |
Message-Id: | <2593-Sat04Aug2001110254+0300-eliz@is.elta.co.il> |
X-Mailer: | Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 |
CC: | djgpp-workers AT delorie DOT com |
In-reply-to: | <10108040452.AA14887@clio.rice.edu> (sandmann@clio.rice.edu) |
Subject: | Re: Updated crt0.S and crt0.h (Win2K fix) |
References: | <10108040452 DOT AA14887 AT clio DOT rice DOT edu> |
Reply-To: | djgpp-workers AT delorie DOT com |
Errors-To: | nobody AT delorie DOT com |
X-Mailing-List: | djgpp-workers AT delorie DOT com |
X-Unsubscribes-To: | listserv AT delorie DOT com |
> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) > Date: Fri, 3 Aug 2001 23:52:48 -0500 (CDT) > > 3) A new sbrk() block sizing algorithm. Later allocated blocks will be > rounded up to a size bigger than 64K. The maximum amount of potential > loss/waste/unavailable memory due to bigger blocks is a maximum of 3% > of the total virtual address pool. Many fewer memory handles are used > (the 256 stored in crt0.S now will take you to 512Mb at smallest > allocations compared to 16Mb before) and allocations are much faster. Perhaps we could have Hans-Bernhard's changes to record the size of the memory chunk with each handle as well. (This is required for the core-dump support).
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |