On Wed, 6 Aug 2003 18:01:46 -0400, Adam Mallory <email@example.com
Andrew Thomas <firstname.lastname@example.org
> wrote in message
Interestingly, the *very* many operating systems supported by emacs
either provide a system allocator that does maintain contiguous virtual
or provide a functioning sbrk() that allows gmalloc to work. While I
agree with you in principle, I don't see much evidence for it in
Partly because they have the luxury of doing so - if they actually need
the physical memory backing the virtual address space, they can swap it
out and the next reference will fault it back in on demand - we not going
to do that.
I don't understand the correlation between the last two paragraphs.
I didn't think that contiguous virtual memory in any way implied a
swap implementation or a relationship with physical memory.
Well, actually you can do a hunk allocator without sbrk - just mmap() in
hunks of memory and provide a slab like object allocator from that. The
fact you do your own allocator already means you have the memory map, and
can do away with sbrk all together.
*I* don't do *my* own allocator. I'm configuring emacs to use one
of the many memory allocation schemes that it has available to it.
It requires one of two possibilities:
a) a functioning sbrk() that can be used in a malloc() replacment
that all library functions use to the exclusion of other memory
allocation techniques. QNX seems to fail here by not respecting
malloc() replacements. Many people have asked for this.
b) a memory allocator that can be optionally made to maintain
contiguous virtual memory, and a way to determine the beginning
and end of that virtual memory.
These are not ridiculous requirements.
Well, putting features into the allocator to get some desktop domain
program ported isn't what we want to target IMHO. In this narrow case,
we can put a feature in to control the rate of release back to the system
pathalogical case being never) which can help the port. But if the
choice has to come between a 'traditionally conforming' sbrk() and a more
efficient allocator - the choice isn't hard.
This is more than just emacs. Like I said, Common LISP environments,
some scheme and smalltalk environments, and many C/C++ garbage collectors
require similar capabilities.
In any case, this is not a choice between 'traditionally conforming' and
'efficient'. Both are possible simultaneously. If QNX actually allowed
drop-in replacments for malloc() then all that would be required is to
fix sbrk(), and the job is done. If you use sbrk() to grab system memory,
you can have a 'traditionally conforming' allocator. If you do not, then
you can have an arbitrarily efficient one.
QNX publishes a library with sbrk() in it. This function does *something*,
just not a correct thing. You could end this line of questioning by
removing sbrk() from the library, but as long as you continue to ship it,
I am just hoping you will also make it work.
It is unfortunately also a pretty severe test case for
"compatibility", where compatibility is defined as
"conformance to a legacy assortment of random side-effects". We don't
have to like it, but it's the world we live in.
I don't debate that - but then one needs to understand that one day those
'side-effects' won't be around.
Not in the lifetime of Linux, is my guess. As long as you want to claim
that QNX is compatible with existing UNIX software, supporting some of
those side-effects is a necessity. This particular side-effect is just
one of the harder ones. And you nearly have it. Why not take the
extra baby step here?