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

Thu Oct 29 09:45:19 PDT 2009

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