I made a mistake in my previous email what I want to know about is the component called lli which is part of the LLVM compiler infrastructure. The command lli allow for programs compiled to bytecode to be run directly.
How does the lli keep itself from being overwritten by a misbehaving program?
does it support multithreading?
does lli allow for multitasking or do you just ran one VM per program?
if it does support multitasking how does it keep processes from colliding?
if it does not support multitasking and runs one VM per process then what means are there for communication of processes?
does lli support emulated virtual memory?
1. How does the lli keep itself from being overwritten by a misbehaving
It doesn't. If you want that kind of safety you have to generate input
IR that checks all its accesses and avoids unsafe constructs.
3. does it support multithreading?
It should be compatible with multithreading. Using current MCJIT, all
compilation happens before execution so you can just write IR that
uses your OS primitives to create and manage your threads. But doing
that management is your responsibility.
(The old JIT and interpreter seem to have some kind of support for a
"llvm_start_multithreaded" function to stop LLVM stomping on its own
structures during execution, but both of those have issues of their
own: you should be using the MCJIT unless you have good reason not to.
If you *do* have good reason, we'd like to hear about it so we can
4. does lli allow for multitasking or do you just ran one VM per program?
5. if it does support multitasking how does it keep processes from
6. if it does not support multitasking and runs one VM per process then what
means are there for communication of processes?
There's no LLVM help for running multiple tasks, you have to rely on
your OS support again.
7. does lli support emulated virtual memory?
I'm not exactly sure what you mean, but I suspect the answer is "no,
do it in your IR using OS primitives".
As Dmitri said, LLVM isn't really designed to be a friendly hosted
environment, but a way to compile (and possibly run in the same
process) native code.
I believe the NatvieClient had to deal with that and much more. Check it out: