tarides / ocaml-jit Goto Github PK

I'm working on an OCaml program that can be extended with scripts written in OCaml, however the existing Dynlink mechanism (and higher-level approaches like ocaml_plugin) is too heavyweight and doesn't work in statically compiled programs. I've had a similar implementation in mind (link with the OCaml compiler, generate assembly, assemble it using a custom x86 assembler in memory and make it executable in the running process using mmap/mprotect). I'm curious if this project could be extended to handle this, in particular:

• Accept complete ml files as input, rather than toplevel phrases
• Link against the cmi of the main program, so that we can provide a mechanism to register the plugin. This may also be useful for custom toplevels, and I believe the existing code to look up symbols is already able to locale the symbols.
• In the long run, allow unloading modules

From what I can tell this is technically possible (the old native toplevel already uses Dynlink, and jit_run in this repository is similar to the native dynlink code in OCaml), although I might be missing some difficulties, especially around changes to the OCaml compiler. If there's anything you need, I'd gladly contribute.

Thanks for this feature -- it will allow OCaml to be used an an extension language! I have two questions:

• Are the results of the compilation cached somewhere? Or does the executable code only live in memory? For instance the native lisp compiler for emacs (due to be released in emacs 28.1) stores the results of compilation in a .eln file so the compilation does not need to happen afresh the next time some script needs to be evaluated
• Are there some major features/fixes still planned or is this feature near its final state for 4.14?

Using current main (6e56c4c) on OCaml 4.14.0~alpha:

% ls /tmp/*.so
zsh: no matches found: /tmp/*.so
% dune exec bin/jittop.exe 
OCaml version 4.14.0~alpha1 - native toplevel
Enter #help;; for help.

# 3 + 4;;
- : int = 7
# 
% ls /tmp/*.so
/tmp/camlTOP1138b62.so

Working on the JIT we detected that the native toplevel wasn't properly reporting locally defined exceptions.

A test case was initially added there to reproduce this.

The native toplevel reports locally defined exceptions with a prefix TOPX. whereas the bytecode toplevel does not add said prefix.

We need to properly report this upstream and eventually open a PR with a reproduction test case.