From: Igor Munkin <imun@tarantool.org> To: Sergey Kaplun <skaplun@tarantool.org> Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] lua: lua_field_inspect_table without pushcfunction Date: Tue, 2 Jun 2020 12:36:39 +0300 [thread overview] Message-ID: <20200602093639.GB5745@tarantool.org> (raw) In-Reply-To: <20200602001948.GA5745@tarantool.org> OK, it was too late at night (or too early at morning), sorry. On 02.06.20, Igor Munkin wrote: > Sergey, > > Thanks for the patch! Please consider my comments below. > > On 18.05.20, Sergey Kaplun wrote: > > Currently on encoding table we push cfunction (lua_field_try_serialize) > > to lua stack with additional lightuserdata and table value and after > > pcall that function to avoid a raise of error. > > > > In this case LuaJIT creates new object which will not live long time, > > <lua_pushlightuserdata> just assigns a pointer to the top guest stack > slot. Yes, it might trigger stack reallocation, but no GC object is > created. Yes creating a Lua function object with <lua_field_try_serialize> payload definitely clobbers GC. > <snipped> > > Well, let's polish the commit message to make it a bit clearer. Commit > subject also looks non-informative and doesn't respect our contribution > guide[2], so I propose the following rewording: > | lua: remove excess Lua call from table encoding > | > | For safe table encoding <lua_field_try_serialize> function is pushed > | to Lua stack along with auxiliary lightuserdata and table object to be > | encoded. Its further protected call catches Lua error if one is raised > | while encoding. It is only necessary when the object to be serialized > | has __serialize field in metatable and this field is a Lua function. > | > | As a result of this change the function serializing the given object > | is called without excess protected frame and auxiliary status struct. Added this point to the last part: | This change reduces GC usage since a Lua function object is not | created. Moreover the function serializing the given object is called | without excess protected frame and auxiliary status struct. > Feel free to change it on your own. > <snipped> > > -- > Best regards, > IM -- Best regards, IM
next prev parent reply other threads:[~2020-06-02 9:45 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-18 9:37 Sergey Kaplun 2020-05-18 21:52 ` Vladislav Shpilevoy 2020-05-19 10:29 ` Sergey Kaplun 2020-05-19 20:08 ` Vladislav Shpilevoy 2020-05-22 11:48 ` Aleksandr Lyapunov 2020-05-22 14:05 ` Alexander Turenko 2020-05-25 12:06 ` Sergey Kaplun 2020-06-02 0:19 ` Igor Munkin 2020-06-02 9:36 ` Igor Munkin [this message] 2020-06-10 12:15 ` Kirill Yukhin 2020-06-10 13:01 ` Igor Munkin 2020-06-10 13:39 ` Kirill Yukhin
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=20200602093639.GB5745@tarantool.org \ --to=imun@tarantool.org \ --cc=skaplun@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH] lua: lua_field_inspect_table without pushcfunction' \ /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