[llvm-commits] [llvm] r85295 - in /llvm/trunk: docs/tutorial/LangImpl4.html docs/tutorial/OCamlLangImpl4.html include/llvm/ExecutionEngine/ExecutionEngine.h lib/ExecutionEngine/ExecutionEngine.cpp lib/ExecutionEngine/JIT/JIT.cpp lib/ExecutionEngi
Evan Cheng
evan.cheng at apple.com
Tue Oct 27 23:47:03 PDT 2009
On Oct 27, 2009, at 11:07 PM, Jeffrey Yasskin wrote:
> On Tue, Oct 27, 2009 at 10:03 PM, Evan Cheng <evan.cheng at apple.com>
> wrote:
>> I believe lazy compilation should still be the
>> default behavior for JIT. If it's not thread safe, then clients who
>> want JIT
>> safety should fix it.
>
> You say that as if it's an easy thing to do and can be done once and
> for all. You should probably read the bug (http://llvm.org/PR5184) to
> see why that's wrong.
I am not saying it's easy. There are clients which do use lazy
compilation and they don't care about this though.
>
> As to why lazy compilation should not be the default: it has confused
> users who tried running their JITs under helgrind and got reports
> inside one of the most confusing parts of the JIT. When the race
> actually bites users, it's going to be extremely hard to debug, since
> it happens when a call is first executed and depends on exactly how
> the call was aligned. And there are other races in the JIT unless you
> hold the JIT lock around all IR manipulation. I don't think it's a
> good idea to make the default behavior of LLVM crash randomly in
> hard-to-debug ways. Finally, I haven't heard of any cases besides lli
> where the current lazy JIT is actually the right choice for
> performance.
To me that's a documentation issue. We're providing lli as the example
JIT. It defaults to lazy compilation. That will not change since we're
using it as a JIT test harness. I think it's actually more confusing
for lli to default to different behavior.
Your usage model is different from others. What you feel is the right
default behavior is not the same for others. Like I said, there are
clients who have been using the JIT who do not care about thread
safety. They are using it in a single-threaded program and want the
benefit of lazy compilation.
LLVM JIT is not a light weighted JIT. It does everything a static
compiler code generator would do. Non-lazy compilation may very well
be unacceptable to a lot of users.
>
> Now, lazy JITting is safe in a single-threaded program. It might make
> sense to change the default depending on whether
> llvm_start_multithreaded() has been called, but that seemed more
> confusing than saying that you always have to enable it if you want
> it.
I don't think that's the right solution. It makes the "default" even
more confusing. I'd prefer it just abort with an error stating the non-
lazy + multi-threaded configuration being unsupported.
Evan
More information about the llvm-commits
mailing list