Andrew Thomas <andrew@cogent.ca> wrote in message
news:oprth4dznow9rgrq@nntp.qnx.com…
Interestingly, the very many operating systems supported by emacs either
provide a system allocator that does maintain contiguous virtual memory
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 practise.
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
This is the gmalloc route. It fails. I cannot remember how, frankly,
but as I said, it has to do with sbrk() not really obeying its own
documentation.
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.
Generally speaking, I am willing to put in a few days of work to port
emacs to QNX6, but I am not willing to totally rewrite its memory
allocators or ELF dumping code. I was rather hoping that QNX would
try to support emacs, at least passively - it’s one of the most popular
GNU
tools.
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 (the
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.
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.
FYI - thanks for all you input Andrew, much appreciated!
-Adam