[Tarantool-discussions] Using uJIT in Tarantool: pros and cons]

[Kirill Yukhin]

Hello,
I think its worst to publish overview of uJIT made
by Igor.

--
Regaerds, Kirill Yukhin

----- Forwarded message from Igor Munkin <imun at tarantool.org> -----
Hello,

I was asked by Kirill to provide pros and cons for replacing LuaJIT with
Luavela (a.k.a. uJIT).

I would like to begin with the habr post[1] written by Anton Soldatov. There
are also more videos in LuaVela README[2] starting from the results of several
performance related experiments to various aspects of the language
implementation maintainence.

## Pros

### Features

The killer feature of uJIT is true 64-bit pointers in GC memory. It's the
reason why uJIT was started. This problem is temporary* "hacked" via LuaJIT
GC64 mode[3], but this mode is still not declared as production ready and there
are several issues with it faced by Tarantool users[4]. Using all available
memory on 64-bit platform automatically solves *all* issues similar to gh-562,
gh-843, gh-4671, etc. Furthermore LuaJIT can't unwind exceptions while
executing JIT-compiled machine code, thereby LUA_ERRMEM (GC OOM) error occured
on trace leads to platform failure (i.e. Segmentation fault). Considering
D.Sharonov complaints its the one of the major LuaJIT problem they face on
production. If Tarantool instance uses all available memory on 64-bit platform
OOM will occur only when the memory available to the Tarantool process is
exceeded.

There are also several major enhancements that were introduced considering
platform performance:

* Sealing (i.e. undeletable GC objects) is described here[5].
* Immutable objects (sealing godsend consequence) are described here[6].
* Coroutines timeouts machinery (gh-4748) is described here[7].

### Tooling

uJIT has a great toolbox for Lua performance analysis for both client
code and the host platform. Three different profilers are implemented:

* (gh-781) Instrumenting profiler described here[8].
* (gh-4001) Sampling profiler that works in the following way:
  1. The profiler starts profiling the main thread.
  2. During the whole profiling process each time after a certain interval
  passes, the profiler interrupts the thread's work and gets info on vm-states
  and which function is performed.
  3. When profiling is over, the profiler outputs statistics to a file to be
  postprocessed via dedicated tool to obtain a human-readable format.
* Memory profiler: uJIT memory profiler (aka memprof) is a tool for tracking
  allocation, reallocation and deallocation of Lua memory. When enabled,
  memprof streams information about events (allocations, reallocations and
  deallocations) into a binary log. After memprof is stopped and data stream is
  collected, it can be converted to human-readable format with a dedicated
  tool.
* Enhanced JIT trace dumper (similar to jit.dump) implemented in C.
* Platform-level Lua code coverage.

### Infrastructure

* uJIT is a good example of using CMake as a build system (gh-4444) so
  can be added as a submodule for easy maintainence and configuration
  via Tarantool CMake infrastructure.
* uJIT already has self-sufficient test enviroment (gh-4862) with main
  Lua test suites (gh-4064, gh-4473) being integrated. It also has
  framework for testing JIT trace behaviour allowing to explicitly test
  compiler-related fixes and enhancements
* uJIT also already uses static analyses such as clang-tidy (gh-4854),
  luacheck (gh-4681), clang-format.

### Extensions

In addition to the features above uJIT provides a number of
specific auxillary extensions for Lua[9] and Lua-C API[10].

## Cons

### Cross-platform

Now uJIT supports only Linux/x86_64 platform that is the main candidate
for Tarantool production installations. Recently MacOS support was
added.

### Integration with Tarantool

Tarantool uses LuaJIT internals in scope of src/lua/utils.c for
implementation of several Lua-C interfaces not provided by LuaJIT. Since
uJIT is based on LuaJIT 2.0.5 and Tarantool uses LuaJIT 2.1.0 specific
internals, those interfaces need to be re-implemented. Much work is
already done by S.Kaplun in scope of this branch[11].

## Conclusion

Considering all features provided and problems resolved by uJIT and also
its usage in RTB production since 2015, it is a great LuaJIT alternative
to be used in Tarantool at least on Linux/x86_64 platform.

(*) While Intel uses only 47-bits for addresses.

[1]: https://habr.com/ru/company/iponweb/blog/465441/
[2]: https://github.com/iponweb/luavela#readme-for-luavela-codename-ujit
[3]: https://blog.openresty.com/en/luajit-gc64-mode/
[4]: https://github.com/tarantool/tarantool/issues/4095
[5]: https://github.com/iponweb/luavela/blob/master/docs/public/spec-sealing.rst
[6]: https://github.com/iponweb/luavela/blob/master/docs/public/spec-immutable-objects.rst
[7]: https://github.com/iponweb/luavela/blob/master/docs/public/spec-coroutine-timeouts.rst
[8]: https://github.com/iponweb/luavela/blob/master/docs/public/spec-ujit-iprof.rst
[9]: https://github.com/iponweb/luavela/blob/master/docs/public/ujit-024.rst
[10]: https://github.com/iponweb/luavela/blob/master/docs/public/ujit-c024.rst
[11]: https://github.com/tarantool/tarantool/tree/skaplun/untie-implementation-lua

-- 
Best regards,
IM


----- End forwarded message -----