[LLVMdev] Control Flow and Locks when JITing Functions
ejones at uwaterloo.ca
Thu Apr 21 09:37:07 PDT 2005
On Apr 21, 2005, at 12:12, Chris Lattner wrote:
> Ok. Thanks, for forgot about that patch :(
No problem, since I still don't know how to integrate it cleanly into
the build system. Platform dependencies are very annoying.
> I think it would be more straight-forward to have a single lock that
> the jit resolver can aquire. Makes sense to me at least
This is actually what I ended up doing. So now, the lock in
"ExecutionEngine" is public, and everything involved in the JIT locks
However, it turns out that the issue isn't quite what I thought it was.
I thought it was a concurrent modification issue, where two threads
were trying to update the FunctionStubMap at the same time. Well, it
sort of is, but for a different reason. I'm not sure how I should fix
this, so suggestions are welcome.
My application is spawning multiple threads that are calling in to the
same function. They all call the stub, and they all end up calling into
JITResolve::JITCompilerFn. One of them gets the lock and compiles the
function. Then, when it releases the lock, another thread tries to
continue and immediately gets this exception:
lli: JITEmitter.cpp:236: static void*
<unnamed>::JITResolver::JITCompilerFn(void*): Assertion `I !=
JR.state.getStubToFunctionMap(locked).begin() && "This is not a known
The problem is that after a function is compiled, the information about
the Stub -> Function mapping is erased because it is no longer needed.
The stub has been rewritten to point to the native function. However,
in this case, these threads have already called the stub. So the fix is
A) Hang on to stub -> function mapping indefinitely. (I'm going to try
and implement this to get my project that is due tomorrow working)
B) Have the threads wait on a condition in that particular spot. When
another thread finishes rewriting the stub, it wakes the threads up.
These threads then go and do some low level hack, like calling the stub
again, and immediately call the compiled function. This is probably a
better solution, but it certainly is more complex.
Any other ideas?
More information about the llvm-dev