From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp51.i.mail.ru (smtp51.i.mail.ru [94.100.177.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 8E70E4696C3 for ; Thu, 30 Apr 2020 14:08:08 +0300 (MSK) Received: by smtp51.i.mail.ru with esmtpa (envelope-from ) id 1jU731-0003vB-Vf for tarantool-discussions@dev.tarantool.org; Thu, 30 Apr 2020 14:08:08 +0300 Date: Thu, 30 Apr 2020 14:08:07 +0300 From: Kirill Yukhin Message-ID: <20200430110807.ijwvrvfi4qm5b5ku@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Subject: [Tarantool-discussions] Using uJIT in Tarantool: pros and cons] List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: tarantool-discussions@dev.tarantool.org Hello, I think its worst to publish overview of uJIT made by Igor. -- Regaerds, Kirill Yukhin ----- Forwarded message from Igor Munkin ----- 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 -----