[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

[Jeffrey Yasskin]

On Wed, Oct 28, 2009 at 6:54 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> On Wed, Oct 28, 2009 at 1:47 AM, Evan Cheng <evan.cheng at apple.com> wrote:
>>
>> 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
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
> What exactly would break if lazy compilation was disabled?  The docs
> say "the JIT will abort if lazy compilation is ever attempted"... what
> exactly would cause this?

If lazy jitting is turned on, you generate some call stubs, and then
you turn it off and call one, the program will abort. It's not an
issue if you leave the setting in a consistent state across the
lifetime of the program.