Tarantool development patches archive
 help / color / mirror / Atom feed
From: Sergey Ostanevich <sergos@tarantool.org>
To: Sergey Kaplun <skaplun@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit v2 7/7] tools: introduce a memory profile parser
Date: Sun, 27 Dec 2020 16:24:21 +0300	[thread overview]
Message-ID: <AB249BC3-30AF-4206-BC26-8738CBE5D0C6@tarantool.org> (raw)
In-Reply-To: <03ac70e3bfb9bf7061ad71c1bac50ed3f8e853fc.1608907726.git.skaplun@tarantool.org>

Hi!

Thanks for the patch!
See my 7 comments below.

Sergos


> On 25 Dec 2020, at 18:26, Sergey Kaplun <skaplun@tarantool.org> wrote:
<snipped>
> diff --git a/test/misclib-memprof-lapi.test.lua b/test/misclib-memprof-lapi.test.lua
> new file mode 100755
> index 0000000..e02c6fa
> --- /dev/null
> +++ b/test/misclib-memprof-lapi.test.lua
> @@ -0,0 +1,135 @@
> +#!/usr/bin/env tarantool
> +
> +local tap = require('tap')
> +
> +local test = tap.test("misc-memprof-lapi")
> +test:plan(9)
> +
> +jit.off()
> +jit.flush()
> +
> +-- FIXME: Launch tests with LUA_PATH enviroment variable.
> +local path = arg[0]:gsub('/[^/]+%.test%.lua', ‘’)

I believe it won’t work well for some cases, such as

tarantool> arg[0]
---
- void.test.lua
...

tarantool> arg[0]:gsub('/[^/]+%.test%.lua', '')
---
- void.test.lua
- 0
...

Alternative is:

tarantool> os.execute('dirname '..arg[0])
.
---
- 0
...


> +local path_suffix = '../tools/?.lua;'
> +package.path = ('%s/%s;'):format(path, path_suffix)..package.path
> +
> +local table_new = require "table.new"
> +
> +local bufread = require "utils.bufread"
> +local memprof = require "memprof.parse"
> +local symtab = require "utils.symtab"
> +
> +local TMP_BINFILE = arg[0]:gsub('[^/]+%.test%.lua', '%.%1.memprofdata.tmp.bin')
> +local BAD_PATH = arg[0]:gsub('[^/]+%.test%.lua', '%1/memprofdata.tmp.bin')
> +
> +local function payload()
> +  -- Preallocate table to avoid array part reallocations.
                                         ^parts?
> +  local _ = table_new(100, 0)
> +
> +  -- Want too see 100 objects here.
> +  for i = 1, 100 do
> +    -- Try to avoid crossing with "test" module objects.
> +    _[i] = "memprof-str-"..i
> +  end
> +
> +  _ = nil
> +  -- VMSTATE == GC, reported as INTERNAL.
> +  collectgarbage()
> +end
> +
> +local function generate_output(filename)
> +  -- Clean up all garbage to avoid polution of free.
                                     pollution
> +  collectgarbage()
> +
> +  local res, err = misc.memprof.start(filename)
> +  -- Should start succesfully.
> +  assert(res, err)
> +
> +  payload()
> +
> +  res, err = misc.memprof.stop()
> +  -- Should stop succesfully.
> +  assert(res, err)
> +end

<snipped>

> diff --git a/tools/memprof/parse.lua b/tools/memprof/parse.lua
> new file mode 100644
> index 0000000..f4996f4
> --- /dev/null
> +++ b/tools/memprof/parse.lua

<snipped>

> +local function link_to_previous(heap, e, oaddr)
> +  -- Memory at oaddr was allocated before we started tracking.
> +  local heap_chunk = heap[oaddr]

Do you need two args for this? Can you just pass the heap[oaddr] instead?

> +  if heap_chunk then
> +    -- Save Lua code location (line) by address (id).
> +    e.primary[heap_chunk[2]] = heap_chunk[3]
> +  end
> +end
> +

<snipped>

> +local function ev_header_split(evh)
> +  return band(evh, 0x3), band(evh, lshift(0x3, 2))

Should you intorduce masks along with AEVENT/ASOURCE to avoid these
magic numbers?

> +end
> +

<snipped>

> diff --git a/tools/utils/bufread.lua b/tools/utils/bufread.lua

<snipped>

> +
> +local function _read_stream(reader, n)
> +  local tail_size = reader._end - reader._pos
> +
> +  if tail_size >= n then
> +    -- Enough data to satisfy the request of n bytes.
> +    return true
> +  end
> +
> +  -- Otherwise carry tail_size bytes from the end of the buffer
> +  -- to the start and fill up free_size bytes with fresh data.
> +  -- tail_size < n <= free_size (see assert below) ensures that
> +  -- we don't copy overlapping memory regions.
> +  -- reader._pos == 0 means filling buffer for the first time.
> +
> +  local free_size = reader._pos > 0 and reader._pos or n
> +
> +  assert(n <= free_size, "Internal buffer is large enough")

Does it mean I will have a fail in case _pos is less that half of the
buffer and n is more than the tail_size? 
Which means I can use only half of the buffer?

> +
> +  if tail_size ~= 0 then
> +    ffi_C.memcpy(reader._buf, reader._buf + reader._pos, tail_size)
> +  end
> +
> +  local bytes_read = ffi_C.fread(
> +    reader._buf + tail_size, 1, free_size, reader._file
> +  )
> +
> +  reader._pos = 0
> +  reader._end = tail_size + bytes_read
> +
> +  return reader._end - reader._pos >= n
> +end
> +

<snipped>

> +function M.eof(reader)
> +  local sys_feof = ffi_C.feof(reader._file)
> +  if sys_feof == 0 then
> +    return false
> +  end
> +  -- Otherwise return true only we have reached
                                  ^^ if we

> +  -- the end of the buffer.
> +  return reader._pos == reader._end
> +end
<snipped>

  parent reply	other threads:[~2020-12-27 13:24 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-25 15:26 [Tarantool-patches] [PATCH luajit v2 0/7] LuaJIT memory profiler Sergey Kaplun
2020-12-25 15:26 ` [Tarantool-patches] [PATCH luajit v2 1/7] utils: introduce leb128 reader and writer Sergey Kaplun
2020-12-25 21:42   ` Igor Munkin
2020-12-26  9:32     ` Sergey Kaplun
2020-12-26 13:57       ` Sergey Kaplun
2020-12-26 18:47         ` Sergey Ostanevich
2020-12-25 15:26 ` [Tarantool-patches] [PATCH luajit v2 2/7] core: introduce write buffer module Sergey Kaplun
2020-12-26 14:22   ` Igor Munkin
2020-12-26 15:26     ` Sergey Kaplun
2020-12-26 19:03       ` Sergey Ostanevich
2020-12-26 19:37         ` Sergey Kaplun
2020-12-28  1:43           ` Sergey Kaplun
2020-12-25 15:26 ` [Tarantool-patches] [PATCH luajit v2 3/7] vm: introduce VM states for Lua and fast functions Sergey Kaplun
2020-12-26 19:07   ` Sergey Ostanevich
2020-12-27 23:48   ` Igor Munkin
2020-12-28  3:54     ` Sergey Kaplun
2020-12-25 15:26 ` [Tarantool-patches] [PATCH luajit v2 4/7] core: introduce new mem_L field Sergey Kaplun
2020-12-26 19:12   ` Sergey Ostanevich
2020-12-26 19:42     ` Sergey Kaplun
2020-12-27 13:09   ` Igor Munkin
2020-12-27 17:44     ` Sergey Kaplun
2020-12-25 15:26 ` [Tarantool-patches] [PATCH luajit v2 5/7] core: introduce memory profiler Sergey Kaplun
2020-12-27 10:58   ` Sergey Ostanevich
2020-12-27 11:54     ` Sergey Kaplun
2020-12-27 13:27       ` Sergey Ostanevich
2020-12-27 16:44   ` Igor Munkin
2020-12-27 21:47     ` Sergey Kaplun
2020-12-25 15:26 ` [Tarantool-patches] [PATCH luajit v2 6/7] misc: add Lua API for " Sergey Kaplun
2020-12-27 11:54   ` Sergey Ostanevich
2020-12-27 13:42     ` Sergey Kaplun
2020-12-27 15:37       ` Sergey Ostanevich
2020-12-27 18:58   ` Igor Munkin
2020-12-28  0:14     ` Sergey Kaplun
2020-12-25 15:26 ` [Tarantool-patches] [PATCH luajit v2 7/7] tools: introduce a memory profile parser Sergey Kaplun
2020-12-26 22:56   ` Igor Munkin
2020-12-27  7:16     ` Sergey Kaplun
2020-12-28  5:30       ` Sergey Kaplun
2020-12-28  5:33         ` Igor Munkin
2020-12-28  6:28           ` Sergey Kaplun
2020-12-28  6:31             ` Igor Munkin
2020-12-27 13:24   ` Sergey Ostanevich [this message]
2020-12-27 16:02     ` Sergey Kaplun
2020-12-27 21:55       ` Sergey Ostanevich
2020-12-28  2:05 ` [Tarantool-patches] [PATCH luajit v3 2/2] misc: add Lua API for memory profiler Sergey Kaplun
2020-12-28  2:49   ` Igor Munkin
2020-12-28  5:19     ` Sergey Kaplun
2020-12-28  2:06 ` [Tarantool-patches] [PATCH luajit v3 1/2] core: introduce " Sergey Kaplun
2020-12-28  3:59   ` Igor Munkin
2020-12-28  4:05 ` [Tarantool-patches] [PATCH luajit v3 3/7] vm: introduce VM states for Lua and fast functions Sergey Kaplun
2020-12-28  5:14   ` Igor Munkin
2020-12-28  6:01 ` [Tarantool-patches] [PATCH luajit v2 0/7] LuaJIT memory profiler Alexander V. Tikhonov
2020-12-28  8:15 ` Igor Munkin

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=AB249BC3-30AF-4206-BC26-8738CBE5D0C6@tarantool.org \
    --to=sergos@tarantool.org \
    --cc=skaplun@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH luajit v2 7/7] tools: introduce a memory profile parser' \
    /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