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 D9E976C7D4; Sat, 20 Mar 2021 03:49:57 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org D9E976C7D4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1616201397; bh=+JYIFdaXaZ15sVf+XkdxxqHdfXtqpQ53yIke0Owdd1c=; h=To:Date:In-Reply-To:References:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=PQaKTblw6c2wGSpDoEqAyLV8n0s+MtbfMgXw51choFgMq+MFyB5DsjnoqcoH9fvWP QpLMEo2DzLcO/eR/Yovl5o5i357/Pnbn5xlExMXFLRCwfbwTaBOjjUb0siLf45lIWN MjrULqwraf6FISOUjuwLq69tHnwgp9uhil1Tq+iI= Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 3B55D71814 for ; Sat, 20 Mar 2021 03:43:11 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 3B55D71814 Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1lNPhu-00076U-Hb; Sat, 20 Mar 2021 03:43:10 +0300 To: tarantool-patches@dev.tarantool.org, gorcunov@gmail.com, sergepetrenko@tarantool.org Date: Sat, 20 Mar 2021 01:42:44 +0100 Message-Id: <2597ce742e96c903138eed83b40c0a447aa66786.1616200860.git.v.shpilevoy@tarantool.org> X-Mailer: git-send-email 2.24.3 (Apple Git-128) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD95D6E7CC48CB1F5F10D3016C09B407F8B88411E9FEB481E8E182A05F53808504018ADA89D2F3A561E4796331B21E3C475AE1D1CDB8A45B74407C889C306B06FCA X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7C579B1C3ABE6C709C2099A533E45F2D0395957E7521B51C2CFCAF695D4D8E9FCEA1F7E6F0F101C6778DA827A17800CE7B2CE06D3E4B8AFEBEA1F7E6F0F101C67CDEEF6D7F21E0D1D174C73DBBBFC7664D0E9B0F0329DBC1DD0A89DE8A8FF23C072B72BBE765098B0389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0D9442B0B5983000E8941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B652D31B9D28593E51CC7F00164DA146DA6F5DAA56C3B73B23C77107234E2CFBA567F23339F89546C55F5C1EE8F4F765FC9149C560DC76099D75ECD9A6C639B01BBD4B6F7A4D31EC0BC0CAF46E325F83A522CA9DD8327EE4930A3850AC1BE2E7353650B6F8DE40EA5FC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0FECB2555BB02FD5A93B503F486389A921A5CC5B56E945C8DA X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A2BBE337FB72E9231554074513AD404CADB28A833D81DA8B7A5E51A7AB86BDA418834459D11680B505EF34DEC70615792430A6AF8A33DE51D6 X-C1DE0DAB: C20DE7B7AB408E4181F030C43753B8186998911F362727C414F749A5E30D975C81A23F326053F827E680E03AA010F61C506D9970E084538E9C2B6934AE262D3EE7EAB7254005DCED7532B743992DF240BDC6A1CF3F042BAD6DF99611D93F60EFF532FBFD8162E58C699F904B3F4130E343918A1A30D5E7FCCB5012B2E24CD356 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3451BBE684D17D7221F8E5991E73BF45F83FE0AB932AB1BE08D4CEDA04B3B205BCC381EB2CFA60761E1D7E09C32AA3244C9D81D1E585240F12FA08A3FC2CA08CBB5A1673A01BA68E40FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj8xHC0Ak4ylYoc2+Ig+JcTw== X-Mailru-Sender: 689FA8AB762F73936BC43F508A063822482B511E1642A6C83169D9D25A8C5B763841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: [Tarantool-patches] [PATCH 07/16] buffer: implement ffi stash 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: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Buffer module now exposes ffi_stash_new() function which returns 2 functions take() and put(). FFI stash implements proper ownership of global heavy-to-create objects which can only be created via FFI. Such as structs, pointers, arrays. It should help to fix buffer's registers (buffer.reg1, buffer.reg2, buffer.reg_array), and other global FFI objects such as 'struct port_c' in schema.lua. The issue is that when these objects are global, they might be re-used right during usage in case Lua starts GC and invokes __gc handlers. Just like it happened with IBUF_SHARED and static_alloc(). Part of #5632 --- src/lib/core/cord_buf.h | 5 ++++ src/lua/buffer.lua | 52 ++++++++++++++++++++++++++++++++++++++++- 2 files changed, 56 insertions(+), 1 deletion(-) diff --git a/src/lib/core/cord_buf.h b/src/lib/core/cord_buf.h index 5e65d138b..5ad5290c1 100644 --- a/src/lib/core/cord_buf.h +++ b/src/lib/core/cord_buf.h @@ -21,6 +21,11 @@ cord_ibuf_take(void); * Put the global ibuf back. It is not necessary - the buffer is put back on the * next yield. But then it can't be reused/freed until the yield. Put it back * manually when possible. + * + * XXX: buffer auto-put could be made more robust via some amendments. One + * option - push a cdata with __gc handler on the stack which puts the buffer + * back, and disable it manually when all worked without errors. The cons is + * that it is expensive. */ void cord_ibuf_put(struct ibuf *ibuf); diff --git a/src/lua/buffer.lua b/src/lua/buffer.lua index d5dbedb0a..9bbd1d98d 100644 --- a/src/lua/buffer.lua +++ b/src/lua/buffer.lua @@ -214,6 +214,55 @@ local function ibuf_new(arg) errorf('Usage: ibuf([size])') end +-- +-- Stash keeps an FFI object for re-usage and helps to ensure the proper +-- ownership. Is supposed to be used in yield-free code when almost always it is +-- possible to put the taken object back. +-- Then cost of the stash is almost the same as ffi.new() for small objects like +-- 'int[1]' even when jitted. Examples: +-- +-- * ffi.new('int[1]') is about ~0.4ns, while the stash take() + put() is about +-- ~0.8ns; +-- +-- * Much better on objects > 128 bytes in size. ffi.new('struct uri[1]') is +-- ~300ns, while the stash is still ~0.8ns; +-- +-- * For structs not allocated as an array is also much better than ffi.new(). +-- For instance, ffi.new('struct tt_uuid') is ~300ns, the stash is ~0.8ns. +-- Even though 'struct tt_uuid' is 16 bytes; +-- +local function ffi_stash_new(c_type) + local item = nil + + local function take() + local res + -- This line is guaranteed to be GC-safe. GC is not invoked. Because + -- there are no allocation. So it can be considered 'atomic'. + res, item = item, nil + -- The next lines don't need to be atomic and can survive GC. The only + -- important part was to take the global item and set it to nil. + if res then + return res + end + return ffi.new(c_type) + end + + local function put(i) + -- It is ok to rewrite the existing global item if it was set. Does + -- not matter. They are all the same. + item = i + end + + -- Due to some random reason if the stash returns a table with methods it + -- works faster than returning them as multiple values. Regardless of how + -- the methods are used later. Even if the caller will cache take and put + -- methods anyway. + return { + take = take, + put = put, + } +end + -- -- NOTE: ffi.new() with inlined size <= 128 works even faster -- than this allocator. If your size is a constant <= 128 - @@ -299,5 +348,6 @@ return { -- Keep reference. reg_array = reg_array, reg1 = reg_array[0], - reg2 = reg_array[1] + reg2 = reg_array[1], + ffi_stash_new = ffi_stash_new, } -- 2.24.3 (Apple Git-128)