[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Emacs Lisp JIT Compiler

From: Tom Tromey
Subject: Emacs Lisp JIT Compiler
Date: Sun, 12 Aug 2018 22:01:34 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux)

Hi.  I've written a JIT compiler for Emacs Lisp, and I'd like to check
it in.

This JIT is based on GNU libjit, like some other attempts that have come
before it.  However, this one is somewhat faster than those, primarily
because it does all stack manipulations at compile time, not runtime.

In some simple benchmarks, it is about 3x faster than the bytecode

I have only tested this on x86-64.  Whether or not the JIT works on a
given platform is primarily up to libjit.  (I suspect the JIT won't work
on x86 with --with-wide-int; but that is something I could fix.)

I currently have the JIT set up to always compile all eligible functions
(that is, just byte-compiled, lexically-bound functions).  It's robust
enough that, as far as I can tell, everything works fine in this mode.
It would be possible to have it be a bit lazier, say only compile after
100 invocations, or something like that.

Aside from the possible --with-wide-int thing, there are two bugs I know

First, 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).

Second, I haven't gotten around to emulating the "quitcounter" behavior
in the bytecode interpreter.  This seems straightforward.

This version of the compiler is pretty basic.  It just compiles each
bytecode to more or less the obvious thing.  I have some plans to make
the calling convention a bit less expensive, and to allow for inlining.

Note that this change does not involve any semantic changes to Emacs Lisp.
Also, if libjit is unavailable, the JIT is simply disabled.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]