But neither SBCL nor ECL has a JIT. A JIT is a subsystem which on its own decides to compile an intermediate representation (usually some compiled byte code) to native code. Typically the JIT decides when and how to compile it, often using runtime information to compile runtime optimized code.
In both SBCL and ECL, the Lisp is either configured to compile AOT or the user calls the compiler. If there is a source interpreter running the source, the user has to explicitly call COMPILE and COMPILE will not use any runtime information on its own - like using statistics how often functions are being use with which argument types and compile code versions for different argument types. It will also not compile new optimized versions on additional runtime information. The current Lisp compiler will only use the static information which is in the source.
JIT systems OTOH watch the byte code execution and compile code on its own to optimized/native versions, based on the runtime information the JIT system observes.
In basically most Common Lisp implementation, the decision to what kind of code and when it is compiled/executed is left to the user.
Though I think there was a CLISP experiment with compiling CLISP byte codes to native with a JIT. https://sourceforge.net/p/clisp/mailman/clisp-devel/thread/e...
ECL has three ways to run code: an interpreter, a byte code engine and a Lisp-to-C compiler (files, and incremental via files). In theory one could use a JIT to compile the byte codes to native code at runtime. I don't know if this has been tried.
Some experiments of improving CLOS speed at runtime (similar to what Julia does) might be considered to be a moral equivalent of a JIT - but I haven't checked it out.