From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: RE: Interest in Smalltalk and/or Python?
Date: Tue, 16 Jan 2001 19:11:48 +0100
Message-ID: <NEBBIOJNGMKPNOBKHCGHGEKFCAAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200101161205.OAA04951@is.elta.co.il>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id NAA02215
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

> 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.
That's what it does. Unfortunately, my attempt to use 1.7's xmalloc-based
routines when HAVE_MMAP is 0 have failed miserably; during a minor GC
flip, the system locks up and/or reboots, which makes it fairly hard to
debug. I think I'll start by making a distribution for the last version
that used the mmap()-free approach, and contacting the GNU maintainer
about possibly getting malloc-based routines back in.

> 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.
I'll see if that has any effect.