From xemacs-m  Sat May 31 10:11:01 1997
Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id KAA14722
	for <xemacs-beta@xemacs.org>; Sat, 31 May 1997 10:11:00 -0500 (CDT)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id IAA23855 for <xemacs-beta@xemacs.org>; Sat, 31 May 1997 08:11:01 -0700 (PDT)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id IAA16313; Sat, 31 May 1997 08:11:35 -0700
To: xemacs-beta@xemacs.org
Subject: Re: Memory exhausted
References: <w8senayjl28.fsf@hrotti.ifi.uio.no> <kig3ererzy2.fsf@jagor.srce.hr> <m2g1v4j0hc.fsf@proletcult.slip.ifi.uio.no> <kig910w66cy.fsf@jagor.srce.hr>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
Mail-Copies-To: never
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: David Moore <dmoore@ucsd.edu>
Date: 31 May 1997 08:11:34 -0700
In-Reply-To: Hrvoje Niksic's message of 30 May 1997 22:40:45 +0200
Message-ID: <rvd8q7oevt.fsf@sdnp5.ucsd.edu>
Lines: 34
X-Mailer: Gnus v5.4.45/XEmacs 20.1

Hrvoje Niksic <hniksic@srce.hr> writes:

> The new configure will have a more correct mmap test, which will
> (hopefully) recognize Ultrix mmap for what it is, and not use it.
> This will cause not using relocating allocator, too.

There are 2 different relocating allocators in xemasc currently.  One
uses mmap in a brute force manner and the other does tricks in the sbrk
space as part of our provided gnu malloc.  Both of them have different
performance penalties, although the mmap version could be cleaned up for
likely significant speed improvements on common-case buffer growth.  I
started to fix this up, but ended up ripping my hair out trying to
resynch our old version of gmalloc and the non-mmap reallocator.  If
someone with free time :) wants a useful project for making future
xemacs maintaince easier, they should entirely rip out our provided
gmalloc and related files.  Provide a version of it as a separate
library for people who want it.  On systems which already have gmalloc
we can use it, and plain malloc on many commercial OSs is good enough
nowadays (although precludes using the non-mmap relocating
allocator). As it is now we're locked into an old version of
gmalloc/ralloc and have lots of fairly unmaintainable cruft.

Having all of that cleanly separated would also make it easier for an
independent reworking of an mmap relocating allocator based on xemacs
usage patterns.


So, uh, back to the original comment.  If the mmap relocator is broken
under ultrix, you're better off undef'ing HAVE_MMAP in config.h (or
having that information put into an appropriate s&m header or the newer
configures can autodetect the broken mmap) than turning of the relocator
entirely.  Unless of course you have memory to burn (and aren't
concerned with the possibilities that something in xemacs is keeping a
bad pointer into those spaces. ha ha ha).

