> 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 -- gaeke at uiuc.edu
> 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 -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
> > 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. -- gaeke at uiuc.edu