[LLVMdev] Control Flow and Locks when JITing Functions

[Chris Lattner]

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.

yes.

> 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.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/