[Tarantool-patches] [PATCH 07/16] buffer: implement ffi stash

[Vladislav Shpilevoy via Tarantool-patches <tarantool-patches@dev.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
---
 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)