[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
http://llvm.org/bugs/show_bug.cgi?id=5184
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