LuaJIT can compile the particular Lua flows to the traces via JIT machinery. The generated trace contains no branches in terms of Lua code; all Lua calls are inlined.
All source-related debug info is stored in Lua functions prototypes. The function prototype is linked to the function's prologue. IR generated by JIT is not fully linked with the bytecode that has been traced, hence we can say nothing about the relations between the traced sources and the compiled mcode.
Task: the student has to get familiar with the relations between Lua sources, Lua bytecode, IR and mcode, provide the design for introducing source-related debug for traces, implement this feature and make the benchmarks.
There is an external tool for recording the compact "minidump" files – Google Breakpad. This tool can only produce C stack traces from the collected minidumps. However, it would be useful to also see the guest stack traces after processing these minidumps.
Task: the student has to get familiar with the Google Breakpad and LuaJIT guest stack layout (frame types, Lua-Lua calls, TCO), provide the design for implementing LuaJIT stack traces in terms of Google Breakpad and implement this feature.
Tarantool can yield fiber backtraces via fiber.info
(when Tarantool is compiled with -DENABLE_BACKTRACES
), however, there can be fibers taking the resources forever and there is no way to call fiber.info
at the moment. For such cases we need to dump the backtrace on the signal sent to the particular Tarantool instance.
Task: the student has to get familiar with the existing backtrace machinery and LuaJIT debug API, adjust this API to be signal-safe and consistent and implement the signal handler dumping both host and guest stack traces for the currently running fiber.
There is a Tarantool storage type implemented as a custom Lua type – decimals. Unfortunately, there are some case when using decimals unpredictable drops the platform performance.
Task: the student has to get familiar with the JIT engine basics and the related tools, investigate the case described in the issue and finally provide the resolution: fix the decimal implementation to make it more JIT-friendly, fix the JIT engine or provide an explanation why the issue can't be fixed in scope of the current JIT engine design. As a result the issue will be closed and can be considered as a contribution to Tarantool.