[LLVMdev] Control Flow and Locks when JITing Functions

Chris Lattner sabre at nondot.org
Thu Apr 21 09:12:51 PDT 2005

On Thu, 21 Apr 2005, Evan Jones wrote:
> I just located a concurrency error in my LLVM patch to add locks to the
> JIT. I did not add any locks to the JITResolver class in JITEmitter.cpp,
> which clearly is a problem since This particular issue causes an
> assertion failure on occasion when running a task that spawns threads on
> a parallel machine. Any recommendations about if I am doing something
> that seems horribly wrong are welcome. I'll update my patch that has
> been sitting in Bugzilla for a while as soon as I come up with a good
> fix.

Ok.  Thanks, for forgot about that patch :(

> My understanding of how code is JITed:
> 1. The program calls a stub.
> 2. The stub does some magic to call into the JIT and pass the stub
> address as a parameter.
> 3. Eventually, it ends up in JITResolver::JITCompilerFn which looks up
> the function.
> 4. This ends up calling into the JIT eventually.


> From what I understand, the JIT *never* calls into the JITResolver.
> However, the JITResolver calls into the JIT. Hence, it is okay to have
> two lock objects, one for the JIT and one for the JITResolver. However,
> these two classes work very closely together, so I think there should
> only be a single lock object. Does this seem reasonable?

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 :)

> Additionally, it only seems to make sense that there is a single
> JITResolver instance. Thus, I am going to force code to hold the lock
> before calling "getJITResolver." Does that seem reasonable?

Yes, there can be only one JITResolver.



More information about the llvm-dev mailing list