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

[Chandler Carruth]

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.

The fact that an interface, when used in new ways, exposes bugs this
severe and subtle indicates that it is a poor interface. Your argument
doesn't lend much weight, because the same can be said of computed
goto, the fork() system call, etc. Surviving new and different uses
*is* the purpose of a good interface.

>> 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 do not think you can guarantee that the abort occurs if multiple
threads are present. I would also much rather a speed limit sign than
a dashboard full of speeding tickets to teach me how to drive. (Even
if in that case I opt for both.... ;])

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

The JIT doesn't get faster by being lazy, its slowness is just
amortized over the runtime. As several have pointed out, that's not
always desirable, and in some cases is outright terrible. We always
take the same amount of time to actually JIT the code.

At best, the lazy JIT simply sees less code, but for most dynamic
languages, the only code ever given to the JIT is what is already
known to be needed.

> I'd prefer not to change the behavior. If we want to start using it in new and interesting ways, we should just design a new JIT.

We clearly do want use it in new and interesting ways, there is no
'if'. I'm not sure what you mean by 'design a new JIT'...

-Chandler