Date: Tue, 16 Jan 2001 14:05:10 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Message-Id: <200101161205.OAA04951@is.elta.co.il>
To: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
CC: djgpp-workers AT delorie DOT com
In-reply-to: <NEBBIOJNGMKPNOBKHCGHMEJJCAAA.tim.van.holder@pandora.be>
Subject: Re: Interest in Smalltalk and/or Python?
References:  <NEBBIOJNGMKPNOBKHCGHMEJJCAAA DOT tim DOT van DOT holder AT pandora DOT be>
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
Precedence: bulk

> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Sun, 14 Jan 2001 20:46:05 +0100
> 
> > > Annoyance! As it turns out, the latest smalltalk package requires mmap(),
> > What does it use mmap for?  Does it really want memory-mapped files,
> > or is that just for better memory allocation?
> Seems to be just memory allocation; it has a new source file (heap.c) that
> provides memory allocation.

That figures: memory-intensive programs built around interpreters
usually are unhappy with the system library's malloc, because it tends
to fragment memory and start paging in a long session.  Emacs uses a
combination of gmalloc and a relocatable allocator which sits atop
sbrk, for the same reason.  Perhaps using gmalloc in the Smalltalk
port will be better than libc malloc.

Btw, it's possible that Smalltalk will need the _CRT0_FLAG_UNIX_SBRK
and/or _CRT0_FLAG_FILL_SBRK_MEMORY flags in _crt0_startup_flags,
because that's how Unix sbrk behaves.