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

Chandler Carruth chandlerc at google.com
Wed Oct 28 10:07:38 PDT 2009


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

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.

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
>




More information about the llvm-dev mailing list