[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] llvm-lua 1.0
- From: "Robert G. Jakabosky" <bobby@...>
- Date: Tue, 2 Jun 2009 17:06:18 -0700
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
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