all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Tom Tromey <tom@tromey.com>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs Lisp JIT Compiler
Date: Mon, 13 Aug 2018 18:15:36 +0300	[thread overview]
Message-ID: <83lg9ajo13.fsf@gnu.org> (raw)
In-Reply-To: <87va8ej4o1.fsf@tromey.com> (message from Tom Tromey on Sun, 12 Aug 2018 22:01:34 -0600)

> From: Tom Tromey <tom@tromey.com>
> Date: Sun, 12 Aug 2018 22:01:34 -0600
> 
> Hi.  I've written a JIT compiler for Emacs Lisp, and I'd like to check
> it in.

Thanks.

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

I think, given the importance of byte compilation, this feature should
become more mature than it evidently is now, before we install it on
master.  The issues you mention are pretty basic, IMO.

So perhaps a feature branch where people could try JIT, and these
issues can be worked on would be the best course of action.  We could
then merge later when the issues are resolved.

Like Paul, I'm somewhat bothered by the relatively slow development of
libjit (its current version is just 0.1.2) and its small development
team.

Thanks.



  parent reply	other threads:[~2018-08-13 15:15 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-13  4:01 Emacs Lisp JIT Compiler Tom Tromey
2018-08-13  5:37 ` Paul Eggert
2018-08-13 15:15   ` Tom Tromey
2018-08-14  0:16   ` Tom Tromey
2018-08-14 20:11     ` Daniel Colascione
2018-08-14 20:55       ` Paul Eggert
2018-08-14 21:03         ` Daniel Colascione
2018-08-14 22:38           ` Paul Eggert
2018-08-15 16:41             ` Eli Zaretskii
2018-08-15 17:16               ` Paul Eggert
2018-08-15 17:47                 ` Eli Zaretskii
2018-08-16  0:29               ` Tom Tromey
2018-08-16 13:26                 ` Eli Zaretskii
2018-08-16 15:43                   ` Daniel Colascione
2018-08-16 16:22                     ` Andreas Schwab
2018-08-19 18:17                     ` Tom Tromey
2018-08-19 19:00                       ` Eli Zaretskii
2018-08-19 19:16                         ` Tom Tromey
2018-08-19 20:23                       ` Stefan Monnier
2018-08-18 10:10                   ` Steinar Bang
2018-08-18 11:31                     ` Eli Zaretskii
2018-08-19 10:00                       ` Robert Pluim
2018-08-19 15:01                         ` Eli Zaretskii
2018-08-19 15:26                   ` Tom Tromey
2018-08-23  0:47                 ` Tom Tromey
2018-08-23 16:48                   ` Eli Zaretskii
2018-08-24 17:54                     ` Tom Tromey
2018-08-24 20:23                       ` Eli Zaretskii
2018-08-24 21:03                         ` Tom Tromey
2018-08-25  6:51                           ` Eli Zaretskii
2018-09-10 11:03                             ` Ergus
2018-09-10 11:15                               ` Robert Pluim
2018-09-10 11:53                                 ` Tom Tromey
2018-09-12 13:37                                   ` Robert Pluim
2018-09-13  4:32                                     ` Tom Tromey
2018-08-16  0:03   ` Tom Tromey
2018-08-16  2:45     ` Eli Zaretskii
2018-08-16 18:07       ` Eli Zaretskii
2018-08-13 13:50 ` T.V Raman
2018-08-13 15:18   ` Tom Tromey
2018-08-13 15:23     ` T.V Raman
2018-08-13 15:15 ` Eli Zaretskii [this message]
2018-08-20 21:54   ` John Wiegley
2018-08-13 23:31 ` Richard Stallman
2018-08-13 23:51   ` Tom Tromey
2018-08-16  2:42     ` Richard Stallman
2018-08-15  0:21 ` Clément Pit-Claudel
2018-08-16  0:32   ` Tom Tromey
2018-08-16  2:14     ` Clément Pit-Claudel
  -- strict thread matches above, loose matches on Subject: below --
2016-12-11 17:37 Nickolas Lloyd
2016-12-12  6:07 ` John Wiegley
2016-12-12 11:51   ` Nickolas Lloyd
2016-12-12 16:45     ` John Wiegley
2016-12-23 17:22       ` Nickolas Lloyd
2016-12-13 22:24   ` Johan Bockgård
2016-12-05 18:16 Burton Samograd
2016-12-05 18:40 ` Eli Zaretskii
2016-12-05 19:32 ` Daniel Colascione
2016-12-05 21:03   ` Burton Samograd
2016-12-06 15:54     ` Lluís

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83lg9ajo13.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.