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 ABB77CC30B; Wed, 20 Jan 2021 17:58:30 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org ABB77CC30B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1611154710; bh=YRMQfkCpeLyhTUA0IQ8yHObXSrhZoHaesnAAmHbjxUk=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=lAa+oS/bKzouB93gC5GjFY82dlTrQyvLsULleuXrTe+PA7CYKRopKyAKGtvvUZmtR /x/JkJiXTzrrWp2y/Bn1nUVW8Qw0sc/aXg4oUCGvsr4jUPHoohNw2AB07IbdTQcHNn Vv6JpO5U/8gDqcnMghWKESieABhM7h1zdBz3aZjs= Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93]) (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 DD38ACC30A for ; Wed, 20 Jan 2021 17:58:28 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org DD38ACC30A Received: by smtp33.i.mail.ru with esmtpa (envelope-from ) id 1l2EwG-0005Ro-2L; Wed, 20 Jan 2021 17:58:28 +0300 Date: Wed, 20 Jan 2021 17:57:51 +0300 To: Sergey Ostanevich Message-ID: <20210120145751.GB3034@root> References: <20201225113431.9538-1-skaplun@tarantool.org> <20210115131424.GA5460@tarantool.org> <20210120081957.GA3034@root> <215048A7-04C8-42E3-B142-4856DA9EC56E@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <215048A7-04C8-42E3-B142-4856DA9EC56E@tarantool.org> X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9D0E79FBC973162CD1269BAEF2517FA5CABD5EB3486AA6E7100894C459B0CD1B9DF0D909292C3AFD2800A13E22B0EF2388B8BA6AEA2DF186FCAD80AB92358092F X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE77603ADE015AF816DEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063702DFA59B3C994360EA1F7E6F0F101C674E70A05D1297E1BBC6CDE5D1141D2B1CBE29A8F91B817DB2403A6B9B4FEF835295BEAC0B93FB160B9FA2833FD35BB23D9E625A9149C048EE33AC447995A7AD182CC0D3CB04F14752D2E47CDBA5A96583BD4B6F7A4D31EC0BC014FD901B82EE079FA2833FD35BB23D27C277FBC8AE2E8BAA867293B0326636D2E47CDBA5A96583BA9C0B312567BB23089D37D7C0E48F6CA18204E546F3947C616AD31D0D18CD5C35872C767BF85DA22EF20D2F80756B5F40A5AABA2AD3711975ECD9A6C639B01B78DA827A17800CE78E7FE8CC7D0C7735731C566533BA786A40A5AABA2AD371193C9F3DD0FB1AF5EBF64ED337B09931FD27F269C8F02392CD5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5B9D4FDB9C5A03ABDA15777DF1A0BFF58C3C54E583E6C4942D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA758F9E841AEAEC4F2C410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34E54F8089C01448AA4322D1BFEAF1B25274493399666144F8A73DA6189B9C87FEC5B853DA640BB0C81D7E09C32AA3244C2946CA74616343409ABA06F8341FE3AC24AF4FAF06DA24FDFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj7AvRt3Uvx5TGqYI1kKpwsg== X-Mailru-Sender: 3B9A0136629DC91206CBC582EFEF4CB45D662841703F2F64BF5E5A40E9429F23D81B476BA9296889F2400F607609286E924004A7DEC283833C7120B22964430C52B393F8C72A41A89437F6177E88F7363CDA0F3B3F5B9367 X-Mras: Ok Subject: Re: [Tarantool-discussions] [RFC luajit v3] rfc: describe a LuaJIT memory profiler X-BeenThere: tarantool-discussions@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Kaplun via Tarantool-discussions Reply-To: Sergey Kaplun Cc: tarantool-discussions@dev.tarantool.org Errors-To: tarantool-discussions-bounces@dev.tarantool.org Sender: "Tarantool-discussions" Hi, Sergos! Thanks, for the review! On 20.01.21, Sergey Ostanevich wrote: > Hi! > > Thanks for the patch, I've looked into > https://github.com/tarantool/tarantool/blob/skaplun/gh-5442-luajit-memory-profiler-rfc/doc/rfc/5442-luajit-memory-profiler.md > > in ‘Prerequisites’: > > Also all, deallocations are reported as internal too. > > the comma is not needed Indeed! Fixed! > > > Lua developers can do nothing with allocations made inside the built-ins except reducing its usage. > > ‘its’ doesn’t explain exact matter. I would rephrase: "As for allocations made inside the built-ins user can do nothing but reduce use of these built-ins." Thanks, applied! > > > Currently VM state identifies C function execution only, so Fast and Lua functions states are added. > > ‘Currently’ -> ‘Originally’ Fixed, thanks! See the iterative patch below. Branch is force pushed. > > Otherwise LGTM. > Sergos > > =================================================================== diff --git a/doc/rfc/5442-luajit-memory-profiler.md b/doc/rfc/5442-luajit-memory-profiler.md index f9c43f91f..cb8adab79 100644 --- a/doc/rfc/5442-luajit-memory-profiler.md +++ b/doc/rfc/5442-luajit-memory-profiler.md @@ -32,7 +32,7 @@ This section describes additional changes in LuaJIT required for the feature implementation. This version of LuaJIT memory profiler does not support verbose reporting for allocations made on traces. All allocation from traces are reported as internal. But trace code semantics should be totally the same as -for the Lua interpreter (excluding sink optimizations). Also all, deallocations +for the Lua interpreter (excluding sink optimizations). Also all deallocations are reported as internal too. There are two different representations of functions in LuaJIT: the function's @@ -44,8 +44,8 @@ that is used for LuaJIT built-ins Tail call optimization does not create a new call frame, so all allocations inside the function called via `CALLT`/`CALLMT` are attributed to its caller. -Lua developers can do nothing with allocations made inside the built-ins except -reducing its usage. So if fast function is called from a Lua function all +As for allocations made inside the built-ins user can do nothing but reduce use +of these built-ins. So if fast function is called from a Lua function all allocations made in its scope are attributed to this Lua function (i.e. the built-in caller). Otherwise, this event is attributed to a C function. @@ -98,7 +98,7 @@ INTERNAL: 20 0 1481 ``` So we need to know a type of function being executed by the virtual machine -(VM). Currently VM state identifies C function execution only, so Fast and Lua +(VM). Originally VM state identifies C function execution only, so Fast and Lua functions states are added. To determine currently allocating coroutine (that may not be equal to currently =================================================================== -- Best regards, Sergey Kaplun