[LLVMbugs] [Bug 5184] New: Lazy compilation is not thread-safe

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Tue Oct 13 19:00:51 PDT 2009


           Summary: Lazy compilation is not thread-safe
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Target-Independent JIT
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu

Lazy compilation is implemented roughly as:

call @compilationCallback

define @compilationCallback() {
  store %new_function_address (%return_address-4)

which turns the "call @compilationCallback" into a "call @real_function".
Unfortunately, while that store into the return address is running, another
thread could be executing the call. At least on the x86, there are no
guarantees about what can happen in this case. (Data reads and writes are
defined, but not instruction execution.) It's entirely possible that the store
won't be seen as atomic and will result in a wild jump.

I see three ways to fix this:
1) Instead of codegening a direct call instruction, generate something like:
  %target = atomic load @callsite_target_address
  call %target
and then at the end of compilation atomically store the real function back to
@callsite_target_address. This causes every callsite to be an indirect call,
which is likely to slow things down a lot, so there should be some way to mark
the functions where it's used.  On platforms that don't even have atomic
pointer writes, this could be implemented by acquiring a lock around every
lazily-compilable call.
2) Assert that lazy compilation is only used in a single-threaded program. This
allows us to delete the JIT lock.
3) Delete lazy compilation. (which would simplify the JIT a fair amount)

Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the llvm-bugs mailing list