From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 17ECF6EC40; Sat, 14 Aug 2021 13:40:24 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 17ECF6EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1628937624; bh=gWHdwO7UY3hoh7DrOr7YWiWDgJHPfT4OcHlKS59jcqw=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=FkI0MPGsiY5w8p7GR3R+m1m5tuPOVKYlYJlYlpMMwMOTy5txQ1lTvtTV2pAMvJ7ds FROf/7t3sEd4tCLgayxz/lKMFAtxwaJ1mufBqXQUDThbY8u/WRMxCNsDmiatpZyOo/ PHrQi53EROhOExMmcRNYg6rlGx7oajxnTreBCRFw= Received: from smtpng1.i.mail.ru (smtpng1.i.mail.ru [94.100.181.251]) (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 826106EC40 for ; Sat, 14 Aug 2021 13:40:23 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 826106EC40 Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1mEr5S-0004h4-3J; Sat, 14 Aug 2021 13:40:22 +0300 Date: Sat, 14 Aug 2021 13:16:41 +0300 To: Sergey Kaplun Cc: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org Message-ID: <20210814101641.GP27855@tarantool.org> References: <20210618181416.25454-1-skaplun@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210618181416.25454-1-skaplun@tarantool.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.10.1 (2018-07-13) X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD92087353F0EC44DD9BCE6B93DE0C6C3914462CDB1732D383C182A05F5380850407DD8FDAA6D85C7BBE5B23F5F2884AEADE482EC49927519BDE5DEF022DC445ACF X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7F2393C4755A27B53EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006372094AD700861FA748638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8DEC4142992477165BF02938B3B69CA9F117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCAA867293B0326636D2E47CDBA5A96583BD4B6F7A4D31EC0BC014FD901B82EE079FA2833FD35BB23D27C277FBC8AE2E8BF1175FABE1C0F9B6A471835C12D1D977C4224003CC8364762BB6847A3DEAEFB0F43C7A68FF6260569E8FC8737B5C2249EC8D19AE6D49635B68655334FD4449CB9ECD01F8117BC8BEAAAE862A0553A39223F8577A6DFFEA7CB1724D34C644744043847C11F186F3C59DAA53EE0834AAEE X-C1DE0DAB: 0D63561A33F958A58D9490394FB3F6BFF587BD04EBD5659BF503A7C7093F3219D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA752DA3D96DA0CEF5C48E8E86DC7131B365E7726E8460B7C23C X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3419891600CCEF4607404B861BD10EF07FE6A1BB4B73E81938FC3F1EDE07F28E4F25EFBE620F018D841D7E09C32AA3244CCE88907C8EEC84252447DDD30E94379BB4DF56057A86259F927AC6DF5659F194 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj57i8v0hCSFJkD9CFEjkRdA== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5D92175BBE489386035C0414DEC8BFBCD6A7C8D0F45F857DBFE9F1EFEE2F478337FB559BB5D741EB964C8C2C849690F8E70A04DAD6CC59E33667EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH] lua: refactor port_lua_do_dump and encode_lua_call X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Igor Munkin via Tarantool-patches Reply-To: Igor Munkin Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Sergey, I've checked the patch into 1.10, 2.7, 2.8 and master. On 18.06.21, Sergey Kaplun wrote: > The old code flow was the following: > 1) `struct port_lua` given to `port_lua_do_dump()` has Lua stack with > arguments to encode to MessagePack > 2) The main coroutine `tarantool_L` is used with `lua_cpcall()` to call > `encode_lua_call_16()` or `encode_lua_call()` > 3) Objects on minor coroutine are encoded via `luamp_encode_call16()` or > `luamp_encode()`. This encoding may raise an error on unprotected > `port->L` coroutine. This coroutine has no protected frame on it > and this call should fail in pure Lua. It is forbidden to call > anything on unprotected coroutine [1] (Lua 5.1 sets protection only > for specific lua_State [2] and calls a panic function if we raise an > error on unprotected lua_State [3]). Netherless, there is no panic > at now due to two facts. The first one is LuaJIT's support of C++ > exception handling [4] that allows to raise an error in Lua and > catch it in C++ or vice versa. But documentation still doesn't > permit errors on unprotected coroutines (at least we must set > try-catch block). The second one is double monkey-patching of LuaJIT > to restore currently executed coroutine, when C function or fast > function raises an error [5][6] (see related issue here [7][8]). > For these reasons, when an error occurs, the unwinder searches and > finds the C-protected stack frame from the `lua_cpcall()` for the > `tarantool_L` coroutine and unwinds until that point (without > aforementioned patches LuaJIT just calls a panic function and exit). > 4) If an error is raised, and `lua_cpcall()` returns not `LUA_OK`, then > the error from `port->L` coroutine is converted into a Tarantool error > and a diagnostic is set. > > The auxiliary usage of `tarantool_L` coroutine is redundant and doesn't > respect Lua idiomatic of usage. So this patch drops it and uses only > minor coroutine instead with `lua_pcall()`. > > Functions to encode are saved as entrance in the `LUA_REGISTRY` table > to reduce GC pressure, like it is done for other handlers [9]. > > [1]: https://www.lua.org/manual/5.2/manual.html#4.6 > > If an error happens outside any protected environment, Lua calls a > > panic function > [2]: https://www.lua.org/source/5.1/lstate.h.html#lua_State > [3]: https://www.lua.org/source/5.1/ldo.c.html#luaD_throw > [4]: https://luajit.org/extensions.html#exceptions > [5]: https://github.com/tarantool/luajit/commit/ed412cd9f55fe87fd32a69c86e1732690fc5c1b0 > [6]: https://github.com/tarantool/luajit/commit/97699d9ee2467389b6aea21a098e38aff3469b5f > [7]: https://github.com/tarantool/tarantool/issues/1516 > [8]: https://www.freelists.org/post/luajit/Issue-with-PCALL-in-21 > [9]: https://github.com/tarantool/tarantool/commit/e88c0d21ab765d4c53bed2437c49d77b3ffe4216 > --- > > Branch: https://github.com/tarantool/tarantool/tree/skaplun/gh-noticket-refactor-lua-call > See the benchmarks sources here [1]. > > Before patch: > | Encode map: 189851357 mcs, 15.8 K ps > | Encode seq: 187926351 mcs, 16.0 K ps > | Encode str: 185451675 mcs, 16.2 K ps > | Encode dig: 184833396 mcs, 16.2 K ps > > After patch: > | Encode map: 187814261 mcs, 16.0 K ps > | Encode seq: 183755028 mcs, 16.3 K ps > | Encode str: 181571626 mcs, 16.5 K ps > | Encode dig: 181572998 mcs, 16.5 K ps > > Looks like the perf doesn't degrade at least. > > [1]: https://gist.github.com/Buristan/3e6d6bf2c722874bec55a8c5a44b98f3 > > src/box/lua/call.c | 71 ++++++++++++++++++++++++++++++++++++---------- > 1 file changed, 56 insertions(+), 15 deletions(-) > > -- > 2.31.0 > -- Best regards, IM