llvm dev - Oct 2009 - [LLVMdev] Should LLVM JIT default to lazy or non-lazy?

On Wed, Oct 28, 2009 at 9:50 AM, Chris Lattner <clattner at apple.com>
wrote:
>
> On Oct 28, 2009, at 9:41 AM, Jeffrey Yasskin 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.
>
> If the objection was about changing the sense of a magic bool, why not
> change the argument to be an enum instead?  That should make it extremely
> clear in the source what behavior is desired.
No, the magic bools all keep the same sense. The change affects the
behavior of programs without a call to
JIT->DisableLazyCompilation(bool). Anyone who's already calling it
with any parameter keeps their current behavior.

I'd be reasonably happy making that call required (so no default) if
people want that instead.

On Wed, Oct 28, 2009 at 9:57 AM, Jeffrey Yasskin <jyasskin at google.com>
wrote:
> On Wed, Oct 28, 2009 at 9:50 AM, Chris Lattner <clattner at
apple.com> wrote:
>>
>> On Oct 28, 2009, at 9:41 AM, Jeffrey Yasskin 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.
>>
>> If the objection was about changing the sense of a magic bool, why not
>> change the argument to be an enum instead?  That should make it
extremely
>> clear in the source what behavior is desired.
>
> No, the magic bools all keep the same sense. The change affects the
> behavior of programs without a call to
> JIT->DisableLazyCompilation(bool). Anyone who's already calling it
> with any parameter keeps their current behavior.
... but I'd be perfectly happy to rename that function and have it
take an enum instead.

Code that takes the default lazy behavior will still work if the
default is changed to non-lazy.  The only way non-lazy breaks (as far
as I know) is if you've already done some lazy JITting and left some
lazy stubs laying around.  And code that does that will still work,
after adjusting to an API change.  This is one of the least disruptive
breaking API changes imaginable.

And getting rid of rare, non-deterministic crashes is always a big win
in my book.  We've got enough deterministic bugs to keep us busy :)