[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]

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