From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp55.i.mail.ru (smtp55.i.mail.ru [217.69.128.35]) (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 0D17A45C304 for ; Fri, 11 Dec 2020 13:05:51 +0300 (MSK) Date: Fri, 11 Dec 2020 13:05:08 +0300 From: Sergey Kaplun Message-ID: <20201211100508.GA29644@root> References: <20201027112913.7927-1-skaplun@tarantool.org> <20201103124024.GG5396@tarantool.org> <20201116055244.GA19025@root> <20201211085148.GM5396@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201211085148.GM5396@tarantool.org> Subject: Re: [Tarantool-discussions] [RFC] rfc: describe a LuaJIT memory profiler List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Munkin Cc: tarantool-discussions@dev.tarantool.org Igor, Thanks for your feedback, I'll send RFC v2 with the patch for the profiler in LuaJIT for more detailed review. On 11.12.20, Igor Munkin wrote: > Sergey, > > Thanks for the clarification! I read the doc once more and answered the > remaining questions below. I guess we have resolved the major points so > I wait for the second version of the RFC. > > On 16.11.20, Sergey Kaplun wrote: > > > > + > > > > +Extended functions to control profiler are added to . > > > > +Profiler is configured by this options structure: > > > > + > > > > +```c > > > > +/* Profiler options. */ > > > > +struct luam_Prof_options { > > > > + /* Options for the profile writer and final callback. */ > > > > + void *arg; > > > > + /* > > > > + ** Writer function for profile events. > > > > + ** Should return amount of written bytes on success or zero in case of error. > > > > + */ > > > > + size_t (*writer)(const void *data, size_t len, void *arg); > > > > + /* > > > > + ** Callback on profiler stopping. Required for correctly cleaning > > > > + ** at vm shoutdown when profiler still running. > > > > + ** Returns zero on success. > > > > + */ > > > > + int (*on_stop)(void *arg); > > > > +}; > > > > +``` > > > > > > Well, maybe it's better to introduce a special interface to fill this > > > struct? Something similar to luaE_coveragestart_cb[1]. As a result the > > > structure is encapsulated in LuaJIT, that looks more convenient for the > > > further maintenance. > > > > Yes, but on the other side for each profiler we should create N > > additional interfaces how to start it. > > As well as N additional structs for profiler options. So what? Why? One structure for *all* profilers. It's the point. > > > > > > > What does this "Overrides" attribute mean? > > > > What allocation this reallocation overrides. > > Well, I guess I get it, but doubt that "overrides" fits this definition. > It can be named "overwrites". > > > > > > > > > +#### Dump of Lua universe > > Let's sort the needy from the greedy right here. While reading the RFC > once more, I bethought to move this part to a separate document to not > spoil this one. Thoughts? Totally agree, insofar as it will be provided in the next version of the profiler. > > > -- > Best regards, > IM -- Best regards, Sergey Kaplun