* [Tarantool-discussions] Using uJIT in Tarantool: pros and cons]
@ 2020-04-30 11:08 Kirill Yukhin
0 siblings, 0 replies; only message in thread
From: Kirill Yukhin @ 2020-04-30 11:08 UTC (permalink / raw)
I think its worst to publish overview of uJIT made
Regaerds, Kirill Yukhin
----- Forwarded message from Igor Munkin <email@example.com> -----
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 written by Anton Soldatov. There
are also more videos in LuaVela README starting from the results of several
performance related experiments to various aspects of the language
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, but this mode is still not declared as production ready and there
are several issues with it faced by Tarantool users. 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
There are also several major enhancements that were introduced considering
* Sealing (i.e. undeletable GC objects) is described here.
* Immutable objects (sealing godsend consequence) are described here.
* Coroutines timeouts machinery (gh-4748) is described here.
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.
* (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
* Enhanced JIT trace dumper (similar to jit.dump) implemented in C.
* Platform-level Lua code coverage.
* 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.
In addition to the features above uJIT provides a number of
specific auxillary extensions for Lua and Lua-C API.
Now uJIT supports only Linux/x86_64 platform that is the main candidate
for Tarantool production installations. Recently MacOS support was
### 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.
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.
----- End forwarded message -----
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2020-04-30 11:08 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-30 11:08 [Tarantool-discussions] Using uJIT in Tarantool: pros and cons] Kirill Yukhin
Tarantool discussions archive
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://lists.tarantool.org/tarantool-discussions/0 tarantool-discussions/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 tarantool-discussions tarantool-discussions/ https://lists.tarantool.org/tarantool-discussions \
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git