Re: [Tarantool-patches] [PATCH] Move txn from shema to a separate module (use C API instead of FFI)

[Igor Munkin <imun@tarantool.org>]

Kostja,

On 28.11.19, Konstantin Osipov wrote:
> * Igor Munkin <imun@tarantool.org> [19/11/28 16:03]:
> > LuaJIT v2.1 provides trace stitching feature (for more info see
> > here[1]), so strictly saying, it doesn't kill JIT but yes, performance
> > is nerfed comparing to traces recorded for an FFI code. I have no
> > proofs/benchmarks for now, so it sounds kinda bullshit, but I look
> > forward to make some in the nearest future.
> > 
> > Furthermore, FFI is not a silver bullet considering this issue[2].
> 
> I fully agree on all points, there is some buggy trace stitching,
> there is an overhead of switching to Lua/C and back, 
> (FFI is slower in Lua/C partly for this reason), and
> FFI is not a silver bullet.

We faced several platform failures recently in FFI machinery, thus I
can't claim which one LuaJIT part from these two is much more buggy.

> 
> Despite all of the above we should be aiming at using FFI more,
> not less, going forward, don't you agree?
> 

Why should we be aiming at using FFI more? The root cause is that
current fiber machinery (as well as some parts of triggers mechanism)
doesn't respect the Lua coroutine switch semantics, thereby breaking
trace recording. Lua-C API implicitly (or non-intentionally) prevents
breakage by JIT trace aborts when recording FUNCC.

Therefore, I guess we should be aiming either at changing fiber
switching to the one respecting the LuaJIT runtime or at tuning JIT
compiler way more regarding the Lua-C usage.

Besides, we can't fully prevent platform failures if there is an FFI
misusage in users code.

> What should be the rule of thumb in your opinion, ffi or
> lua/c? 

If you want to know my rule of thumb: FFI is for external existing
libraries to be used in Lua code (and all compiler related benefits are
nothing more than a godsend consequence, since all guest stack
manipulations are implemented in LuaJIT runtime, not in an external
code) and Lua-C is a well-designed and well-documented API for embedding
Lua into a host application / extending Lua with external low-lewel
libs. I totally do not insist on my point of view, since everyone has
it's own vision on LuaJIT features.

> 
> > > plain Lua 5.3 and forget about grievances with LuaJIT altogether.
> > 
> > JIT is not the only killing feature provided by LuaJIT and
> > infrastructure for Lua 5.1 is much richer.
> > 
> > > 
> > > Nick Zavaritsky had a patch that would detect sandwich stacks in
> > > runtime and assert. Nobody had time to look at it back then -
> > 
> > Could you please provide the issue/link for this changeset, I'll take a
> > look on it with pleasure.
> 
> Nick Zavaritsky himself is the only link here, unfortunately.
> Perhaps he has this patch in one of his personal branches. I
> suggest someone contacts him :)
> 
> -- 
> Konstantin Osipov, Moscow, Russia

-- 
Best regards,
IM