Re: Emacs Lisp JIT Compiler

[Tom Tromey]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

Paul> When you say "doesn't work", does that mean Emacs can reliably tell
Paul> the JIT won't work and fall back on the current bytecode
Paul> implementation, or something else?

What I meant is that when I wrote this, I didn't think about
--with-wide-int, and so some of the calls into libjit are incorrect for
that situation.  It shouldn't be hard to fix.

>> libjit never frees functions.  So, if a function is JIT-compiled
>> and then redefined, the old JIT code will linger.  It's possible to fix
>> this with a custom allocator and a libjit patch (that I sent but that
>> hasn't been checked in yet).

Paul> libjit has only one committer, Aleksey, and no commits since March. Is
Paul> there a bottleneck there?

He's reasonably responsive, but it's true that the lack of an active
community around libjit is a bit of a risk.  Mostly the problems would
be either (1) missing ports or (2) lack of improvements; for example,
libjit's register allocator is not very good, but nobody is working on
improving it.

It would be possible to switch to another JIT back end, but when I
looked into the various ones that are available, libjit was both easy to
use and reasonably lightweight (without being too lightweight, like GNU
Lightning).

But, for example, GCC has a JIT interface now.  That could be used instead.
That seemed pretty heavy-weight to me; but I didn't really try it in
anger so maybe my fears are unfounded.

Tom