[LLVMdev] Should LLVM JIT default to lazy or non-lazy?

Thu Oct 29 11:03:05 PDT 2009

I have no objection to Chris' proposal.

Evan

On Oct 29, 2009, at 9:45 AM, Jeffrey Yasskin wrote:

> Are you objecting to Chris's proposal? I was waiting to implement it
> until you replied so I wouldn't have to implement two things. I
> disagree with a lot of what you wrote below, but it's not worth
> arguing about if there's a compromise we can both live with.
> 
> On Thu, Oct 29, 2009 at 12:36 AM, Evan Cheng <evan.cheng at apple.com> wrote:
>> There is nothing here that prevents users from enabling or disabling lazy
>> JIT. We're talk about flipping the default behavior. That does not make the
>> API any better or worse. Nor does it fix the inherent thread safety issue.
>> 
>> I can tell you there are no Apple clients that depend on the lazy JIT.
>> Please do not imply I am being secretive. I am simply busy. My objection is
>> simple. Changing API simply for the sake of flipping default behavior does
>> not seem like a good trade off to me. You may not feel the pain, but there
>> are existing customers out there that are using previous llvm release who
>> will not appreciate the API change.
>> 
>> To me, the decision is simple. People who have done the work in the past
>> have made their choices. We better respect their choices unless we are
>> replacing them with something better. Flipping the default isn't better. If
>> someone wants to sign up to design a new API, that person(s) get to decide
>> on the default behavior. It's simple as that.
>> 
>> For behavior / API change like this, we better extend llvm-config (or some
>> other means) to expose that information. So the existing clients can at
>> least ifdef the code.
>> 
>> Evan
>> 
>> On Oct 28, 2009, at 1:31 PM, Jeffrey Yasskin wrote:
>> 
>>> On Wed, Oct 28, 2009 at 12:21 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>>>> 
>>>> On Oct 28, 2009, at 10:07 AM, Chandler Carruth wrote:
>>>> 
>>>>> From where I sit, this boils down to a very simple question (modulo
>>>>> Chris's point): Either choice will surprise some users. Which surprise
>>>>> is worse? Personally, I'd always prefer correct but slow behavior by
>>>>> default, and explicitly enabling dangerous (but in some cases fast)
>>>>> behavior.
>>>> 
>>>> The behavior is only dangerous because people are using it in new and
>>>> different ways.
>>> 
>>> I'd point out that reid thought he made the JIT thread-safe in r22404
>>> back in 2005. Calling it from multiple threads isn't new and
>>> different, it's just subtly broken. I suggested changing the default
>>> because most people who run into this problem don't think they're
>>> doing anything unusual, and in fact their code works fine with the
>>> eager JIT. People shouldn't stumble into broken behavior, and defaults
>>> are good to prevent stumbling.
>>> 
>>> To avoid misconceptions, Unladen Swallow added the line to turn off
>>> the lazy jit months ago, and we'll keep that line whatever the
>>> decision is here. We might take advantage of a thread-safe
>>> code-patching facility eventually, but we've been designing assuming
>>> nobody else will implement that for us. I favor changing the default
>>> because it'll help newbies, not because we need it for anything.
>>> 
>>>>> I would also point out that it seems that most of the people new to
>>>>> the JIT are surprised by the current behavior, where as those who
>>>>> would be surprised by needing to enable lazy JIT are those long
>>>>> familiar with past behavior. In the OSS world, I always favor easing
>>>>> adoption over maintaining the status quo.
>>>> 
>>>> This argues for better documentation. I'd prefer for EE to abort if user
>>>> is asking for a known dangerous configuration (multi-threaded and lazy).
>>> 
>>> I think that'd be a decent fix for the thread-safety problem. It'd
>>> require an extra check on each call to runJITOnFunctionUnlocked since
>>> laziness is set by a call, not on construction. Or, we could use the
>>> JIT lock to assert that it's never entered concurrently. On the other
>>> hand, Nicolas Geoffray objected when I suggested that in the bug.
>>> 
>>>> The biggest argument I have for staying with lazy is llvm JIT is not a
>>>> light weight JIT. It's designed to do all the codegen optimizations a normal
>>>> static compiler would do. Non-lazy JIT is too slow.
>>> 
>>> Óscar used the cost of the JIT as an argument _against_ the lazy JIT.
>>> Could you elaborate on why you think it's an argument in favor of lazy
>>> JITting?
>>> 
>>>> I'd prefer not to change the behavior.
>>> 
>>> I'm guessing, based on your vagueness, that there are some internal
>>> single-threaded Apple users who think that the lazy JIT is the best
>>> performing option for them and who don't want to add a line to their
>>> apps overriding the default. But it's hard for me or anyone else
>>> outside Apple to judge whether they ought to drive the default without
>>> a little more information about why the lazy JIT is good for them.
>>> Could you describe any features of their use that make the lazy JIT a
>>> good idea for them?
>>> 
>>>> If we want to start using it in new and interesting ways, we should just
>>>> design a new JIT.
>>> 
>>>>> My meager 2 cents.
>>>>> -Chandler
>>>>> 
>>>>> On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin <jyasskin at google.com>
>>>>> wrote:
>>>>>> 
>>>>>> In r85295, in response to the discussion at http://llvm.org/PR5184
>>>>>> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to
>>>>>> non-lazy. It has since come to my attention that this may have been
>>>>>> the wrong change, so I wanted to ask you guys.
>>>>>> 
>>>>>> A couple reasons to make the default non-lazy compilation:
>>>>>> * The lack of thread-safety surprises new users
>>>>>> * Crashes due to this will be rare and so hard to track down
>>>>>> * The current lazy scheme is almost never the right answer for
>>>>>> performance
>>>>>> * It's only one line of code to turn on lazy compilation when it is
>>>>>> the right answer for you.
>>>>>> 
>>>>>> And a couple to default to lazy compilation:
>>>>>> * It's safe for single-threaded code.
>>>>>> * There are existing users who have assumed this default.
>>>>>> * PPC and ARM don't support non-lazy compilation yet (the tests
>>>>>> currently run the lazy jit).
>>>>>> * Gratuitous changes are bad.
>>>>>> 
>>>>>> Thoughts?
>>>>>> 
>>>>>> We can choose the default for lli separately from the JIT's default if
>>>>>> we want.
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>> 
>>>> 
>> 
>> 