Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: tarantool-patches@dev.tarantool.org, kyukhin@tarantool.org
Subject: [Tarantool-patches] [PATCH 07/15] buffer: implement ffi stash
Date: Wed, 24 Mar 2021 22:24:33 +0100	[thread overview]
Message-ID: <34b6d85e7c0b1d18e182a60abec602c0da6f5ee3.1616620860.git.v.shpilevoy@tarantool.org> (raw)
In-Reply-To: <cover.1616620860.git.v.shpilevoy@tarantool.org>

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

(cherry picked from commit a5549a44db835a59ad6ab82d206172f9d8047a2d)
---
 src/lua/buffer.lua | 50 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/src/lua/buffer.lua b/src/lua/buffer.lua
index 398319cf2..555970ea8 100644
--- a/src/lua/buffer.lua
+++ b/src/lua/buffer.lua
@@ -182,6 +182,55 @@ local function ibuf_new(arg, arg2)
     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
+
 --
 -- Cord buffer is useful for the places, where
 --
@@ -225,4 +274,5 @@ return {
     internal = internal,
     ibuf = ibuf_new;
     READAHEAD = READAHEAD;
+    ffi_stash_new = ffi_stash_new,
 }
-- 
2.24.3 (Apple Git-128)


  parent reply	other threads:[~2021-03-24 21:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24 21:24 [Tarantool-patches] [PATCH 00/15] Cord buffer, static alloc, and Lua GC bug for 1.10 Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 01/15] fio: don't use shared buffer in pread() Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 10/15] uri: replace static_alloc with ffi stash and ibuf Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 11/15] lua: use lua_pushfstring() instead of tt_sprintf() Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 12/15] sio: rework sio_strfaddr() Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 13/15] sio: increase SERVICE_NAME_MAXLEN size Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 14/15] sio: introduce and use sio_snprintf() Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 15/15] buffer: remove Lua registers Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 02/15] test: don't use IBUF_SHARED in the tests Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 03/15] tuple: pass global ibuf explicitly where possible Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 04/15] iconv: take errno before reseting the context Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 05/15] cord_buf: introduce cord_buf API Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 06/15] cord_buf: introduce ownership management Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` Vladislav Shpilevoy via Tarantool-patches [this message]
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 08/15] uuid: replace static_alloc with ffi stash Vladislav Shpilevoy via Tarantool-patches
2021-03-24 21:24 ` [Tarantool-patches] [PATCH 09/15] uuid: drop tt_uuid_str() from Lua Vladislav Shpilevoy via Tarantool-patches
2021-03-29 15:41 ` [Tarantool-patches] [PATCH 00/15] Cord buffer, static alloc, and Lua GC bug for 1.10 Kirill Yukhin via Tarantool-patches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=34b6d85e7c0b1d18e182a60abec602c0da6f5ee3.1616620860.git.v.shpilevoy@tarantool.org \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=kyukhin@tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH 07/15] buffer: implement ffi stash' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox