However, mmap() does provide some other small potential issues:
1) The mmap() function may not exist on all Unices, or it may work
differently on various versions of them.
Definitely. We use mmap for a couple of different things.
1a) In lib/Bytecode/Reader we use mmap to read in bytecode files and archives.
Certainly it would be trivial to rework this to fall back on mmap if
read/write is not possible (in one case it already does this, if we are
reading from stdin, which you can't mmap anyway.)
1b) In tools/lli/JIT we use mmap as a source of memory which has the PROT_EXEC
bit set. That is, the JIT needs to put instructions in memory, and then execute
them; if you use malloc() you are liable to get back non-executable heap
space, but with mmap() you can explicitly ask for executable heap space.
The only systems I know of that don't play nice with mmap are nasty old ones
like DYNIX and SCO, and (grimace) Windows... I don't think we have to worry
about the former. The latter may work under Cygwin...I'm not sure yet.
We need MAP_ANON(YMOUS) and PROT_EXEC for this.
-Brian
1a) In lib/Bytecode/Reader we use mmap to read in bytecode files and archives.
Certainly it would be trivial to rework this to fall back on mmap if
read/write is not possible (in one case it already does this, if we are
reading from stdin, which you can't mmap anyway.)
As Brian said, we already have the fallback path in here for when mmap
isn't available. mmap is a performance optimization though, read and
write should never fail.
1b) In tools/lli/JIT we use mmap as a source of memory which has the PROT_EXEC
bit set. That is, the JIT needs to put instructions in memory, and then execute
them; if you use malloc() you are liable to get back non-executable heap
space, but with mmap() you can explicitly ask for executable heap space.
The only systems I know of that don't play nice with mmap are nasty old ones
like DYNIX and SCO, and (grimace) Windows... I don't think we have to worry
about the former. The latter may work under Cygwin...I'm not sure yet.
We need MAP_ANON(YMOUS) and PROT_EXEC for this.
DYNIX/PTX supports correct mmap for at least PTX 4.2, and has been EOL'd
at any rate. If mmap is not available we can always fall back to using
mprotect (or some other similar feature), and if that is not available
either, the system doesn't deserve to be running a JIT. 
-Chris
> 1a) In lib/Bytecode/Reader we use mmap to read in bytecode files and archives.
> Certainly it would be trivial to rework this to fall back on mmap if
> read/write is not possible (in one case it already does this, if we are
> reading from stdin, which you can't mmap anyway.)
As Brian said, we already have the fallback path in here for when mmap
isn't available. mmap is a performance optimization though, read and
write should never fail.
Whoops. Thanks for correcting my thinko. "...to fall back on *read/write*
if *mmap* is not possible..." is what I meant to say above.