Re: [ANN] llvm-lua 1.0

["Robert G. Jakabosky" <bobby@...>]

On Tuesday 02, Alexander Gladysh wrote:
> I'm interested in trying to port our code to llvm-lua. I have a couple
> of questions:
>
> 1. We use Lua built as C++ (this means at least throwing exception
> instead of calling longjump() in lua_error()). Does llvm-lua support
> this?

I think all you have to do is just change the llvm-lua/Makefile to use 
g++/llvm-g++ instead of gcc/llvm-gcc to compile all the C code.  The only 
thing that might be a problem is if the JITed functions are missing something 
to support C++ exceptions.  If you run into any problems just let me know.

> 2. We have many Lua states created and used in many threads (one state
> is used by a single thread at a time). Would this work with llvm-lua?

Not the current release.  The LLVMCompiler class is not thread-safe and one 
instance of that class is stored in a global variable.  The only use of that 
instance is in llvm-lua/llvm_compiler.cpp, and it could be protected with a 
lock or maybe converted to a thread-local variable.  The llvm_compiler.cpp 
file is just a C wrapper around the C++ class to make it easier for the Lua 
core to call the compiler, it is only about 70 lines.  Unless you have >100 
threads with all of them loading new Lua code all the time, a lock shouldn't 
cause a bottleneck.

Right now that one instance of LLVMCompiler is shared by all lua_States, I 
might move the global variable to a member variable of 'lua_State' .  A lock 
on that shared instance might still be the best option.  I will look into 
this for the next release.


-- 
Robert G. Jakabosky