Tarantool development patches archive
 help / color / mirror / Atom feed
From: Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Mikhail Shishatskiy <m.shishatskiy@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit v2 2/2] memprof: extend symtab with info about traces
Date: Sat, 14 Aug 2021 14:03:11 +0300	[thread overview]
Message-ID: <YRei70Qf4ZutEQqG@root> (raw)
In-Reply-To: <20210728134259.1113235-3-m.shishatskiy@tarantool.org>

Hi, Mikhail!

Thanks for the patch!

Please consider my comments below.

On 28.07.21, Mikhail Shishatskiy wrote:
> This patch extends the memprof symtab by adding information
> about traces, which are present at the start of profiling.
> 
> The symtab format changed with adding <sym-trace> entry,
> which consists of a trace number, address of function proto,
> and line, where trace recording started.
> 
> Also, the memprof parser was adjusted to recognize new
> symtab entries and associate them with allocation events
> from traces.
> 
> This patch also provides tests to test the behavior of
> the memory profiler with JIT turned on.

Nit: This part is obvious and can be dropped, I suppose.
Feel free to ignore.

Also, please mention that API of <utils/symtab.lua> is changed (I'm
about trace\lfunc entries).

> 
> Part of tarantool/tarantool#5814

Should it be Resolves here?

> ---
> 
> Issue: https://github.com/tarantool/tarantool/issues/5814
> Branch: https://github.com/tarantool/luajit/tree/shishqa/gh-5814-group-allocations-on-trace-by-trace-number
> CI: https://github.com/tarantool/tarantool/tree/shishqa/gh-5814-group-allocations-on-trace-by-trace-number
> 
>  src/lj_memprof.c                              |  19 +++
>  src/lj_memprof.h                              |   7 +-
>  .../misclib-memprof-lapi.test.lua             | 121 +++++++++++++-----
>  tools/utils/symtab.lua                        |  41 +++++-
>  4 files changed, 150 insertions(+), 38 deletions(-)
> 
> diff --git a/src/lj_memprof.c b/src/lj_memprof.c
> index 0c7e9e89..87512c3a 100644
> --- a/src/lj_memprof.c
> +++ b/src/lj_memprof.c
> @@ -18,6 +18,7 @@
>  #include "lj_obj.h"
>  #include "lj_frame.h"
>  #include "lj_debug.h"
> +#include "lj_trace.h"

I suppose you need "lj_jit.h" here, not "lj_trace.h".
Also I suppose, that this should be enabled only, if LuaJIT compiled
with enabled JIT.

This regarding to the previous patch too -- we should add lua_assert(0);
if LuaJIT compiled without JIT to all JIT-related functions (maybe in the
separate commit).

Also, please update Makefile.dep.original correspondingly with added
header.

>  
>  /* --------------------------------- Symtab --------------------------------- */
>  
> @@ -43,6 +44,24 @@ static void dump_symtab(struct lj_wbuf *out, const struct global_State *g)
>        lj_wbuf_addu64(out, (uint64_t)pt->firstline);
>        break;
>      }
> +    case (~LJ_TTRACE): {
> +      GCtrace *trace = gco2trace(o);

Nit: We don't want to change trace, so we can add `const` here

> +      GCproto *pt = &gcref(trace->startpt)->pt;

Ditto.

> +     
   ^^^^^
Typo: Trailing whitespaces

> +      const BCIns *startpc = mref(trace->startpc, const BCIns);
> +      lua_assert(startpc >= proto_bc(pt) && 

Typo: Trailing whitespace --------------------^

> +                 startpc < proto_bc(pt) + pt->sizebc);
> +
> +      BCLine lineno = lj_debug_line(pt, proto_bcpos(pt, startpc));

Nit: Please declare all variables at the beggining of the statement.
Else you can observe the following warnings:

| /home/burii/reviews/luajit/memprof-tracealloc/src/lj_memprof.c: In function 'dump_symtab':
| /home/burii/reviews/luajit/memprof-tracealloc/src/lj_memprof.c:55:7: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
|    55 |       BCLine lineno = lj_debug_line(pt, proto_bcpos(pt, startpc));
|       |       ^~~~~~
| /home/burii/reviews/luajit/memprof-tracealloc/src/lj_memprof.c: In function 'dump_symtab':
| /home/burii/reviews/luajit/memprof-tracealloc/src/lj_memprof.c:55:7: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
|    55 |       BCLine lineno = lj_debug_line(pt, proto_bcpos(pt, startpc));

if configure build like this:
| cmake -DCMAKE_C_FLAGS="-Wextra -Wdeclaration-after-statement -Wredundant-decls -Wshadow -Wpointer-arith"\
|       -DCMAKE_BUILD_TYPE=Debug -DLUA_USE_ASSERT=ON -DLUA_USE_APICHECK=ON . && make -j

> +      lua_assert(lineno >= 0);
> +
> +      lj_wbuf_addbyte(out, SYMTAB_TRACE);
> +      lj_wbuf_addu64(out, (uint64_t)trace->traceno);
> +      lj_wbuf_addu64(out, (uintptr_t)pt);

Nit: Please, add comment that all existing prototypes have already been
dumped and we have no need to repeat their dump for trace locations.

> +      lj_wbuf_addu64(out, (uint64_t)lineno);
> +
> +      break; 
               ^
Typo: Trailling whitespace

Side note: Please, tune your favorite editor to highlight trailing
whitespaces.

> +    }
>      default:
>        break;
>      }
> diff --git a/src/lj_memprof.h b/src/lj_memprof.h
> index e3f55433..9e950b94 100644
> --- a/src/lj_memprof.h
> +++ b/src/lj_memprof.h

<snipped>

> diff --git a/test/tarantool-tests/misclib-memprof-lapi.test.lua b/test/tarantool-tests/misclib-memprof-lapi.test.lua
> index 06d96b3b..b7e456e1 100644
> --- a/test/tarantool-tests/misclib-memprof-lapi.test.lua
> +++ b/test/tarantool-tests/misclib-memprof-lapi.test.lua
> @@ -1,13 +1,18 @@
> +local utils = require "utils"
> +
>  -- Memprof is implemented for x86 and x64 architectures only.
> -require("utils").skipcond(
> +utils.skipcond(
>    jit.arch ~= "x86" and jit.arch ~= "x64",
>    jit.arch.." architecture is NIY for memprof"
>  )
>  
> +-- Disabled on *BSD due to #4819.
> +utils.skipcond(jit.os == 'BSD', 'Disabled due to #4819')
> +

We should skip only JIT-related tests here, but not all memprof tests.

>  local tap = require("tap")
>  

<snipped>

> -local function check_alloc_report(alloc, line, function_line, nevents)
> -  assert(form_source_line(function_line) == alloc[line].name)
> -  assert(alloc[line].num == nevents, ("got=%d, expected=%d"):format(
> -    alloc[line].num,
> +local function nevents_eq(event, nevents)
> +  assert(event.num == nevents, ("got=%d, expected=%d"):format(
> +    event.num,
> +    nevents
> +  ))
> +end
> +
> +local function nevents_gr(event, nevents)
> +  assert(event.num > nevents, ("got=%d, expected>%d"):format(
> +    event.num,
>      nevents
>    ))
> +end
> +
> +local function check_alloc_report(alloc, traceno, line, function_line,

Nit: I suggest to add new fields (traceno, for example) not to the middle
of arguments list, but to the end.
Feel free to ignore.

> +                                  nevents, cmp_events)
> +  assert(alloc[line], ("no event on line %d"):format(line))
> +  local event = alloc[line]
> +  local expected_name
> +  if traceno ~= 0 then
> +    expected_name = string.format("TRACE [%d] ", traceno)..
> +                    form_source_line(function_line)
> +  else
> +    expected_name = form_source_line(function_line)
> +  end
> +  assert(expected_name == event.name, ("got='%s', expected='%s'"):format(
> +    event.name,
> +    expected_name
> +  ))
> +  cmp_events(event, nevents)
>    return true
>  end
>  
> @@ -107,20 +165,7 @@ test:ok(res == nil and err:match("profiler is not running"))

<snipped>

> @@ -166,5 +211,23 @@ local co = coroutine.create(f)
>  coroutine.resume(co)
>  misc.memprof.stop()
>  
> +-- Test profiler with enabled JIT.
>  jit.on()
> +
> +-- Pregenerate traces to get expected output:

Nit: "to fill symtab entry" is more verbose to me.
Feel free to ignore.

> +default_payload()
> +
> +symbols, events = generate_parsed_output(default_payload)
> +
> +alloc = fill_ev_type(events, symbols, "alloc")
> +
> +-- We expect, that loop will be compiled into a trace.
> +-- Depends on system, there will be 99 or 100 allocations

Why? Provide an example, please.
Maybe we should to change our payload to lock in the behaviour.

> +-- from trace, so expect greater than 98.
> +test:ok(check_alloc_report(alloc, 1, 35, 30, 98, nevents_gr))
> +-- See same checks with jit.off().
> +test:ok(check_alloc_report(alloc, 0, 32, 30, 2, nevents_eq))
> +-- Collect all previous allocated objects.
> +test:ok(free.INTERNAL.num == 102)
> +
>  os.exit(test:check() and 0 or 1)
> diff --git a/tools/utils/symtab.lua b/tools/utils/symtab.lua
> index 3ed1dd13..8151ecf8 100644
> --- a/tools/utils/symtab.lua
> +++ b/tools/utils/symtab.lua
> @@ -10,11 +10,12 @@ local band = bit.band

<snipped>

> +local function parse_sym_trace(reader, symtab)
> +  local traceno = reader:read_uleb128()
> +  local sym_addr = reader:read_uleb128()
> +  local sym_line = reader:read_uleb128()
> +
> +  symtab.trace[traceno] = {

Assume the following:
1) We get output from 100 traces.
2) Make jit.flush().
3) We get output from other 100 traces.

So all output (from new and old traces) will be reported as output for
old traces. So we need at least report trace address as well (yes,
collisions may happen).

Also, we should report addresses of those functions, to avoid collisions
after several jit.flush() calls. It should be removed after symtab
enriching [1] will be implemented.

Thoughts?

> +    addr = sym_addr,
> +    line = sym_line,
> +  }
> +end
> +
>  local parsers = {
>    [SYMTAB_LFUNC] = parse_sym_lfunc,
> +  [SYMTAB_TRACE] = parse_sym_trace,
>  }
>  
>  function M.parse(reader)
> -  local symtab = {}
> +  local symtab = {
> +    lfunc = {},
> +    trace = {},
> +  }
>    local magic = reader:read_octets(3)
>    local version = reader:read_octets(1)
>  
> @@ -73,18 +89,29 @@ function M.parse(reader)
>    return symtab
>  end
>  
> -function M.demangle(symtab, loc)
> +local function demangle_lfunc(symtab, loc)
>    local addr = loc.addr
>  
>    if addr == 0 then
>      return "INTERNAL"
> +  elseif symtab.lfunc[addr] then
> +    return string_format("%s:%d", symtab.lfunc[addr].source, loc.line)
>    end
> +  return string_format("CFUNC %#x", addr)
> +end
>  
> -  if symtab[addr] then
> -    return string_format("%s:%d", symtab[addr].source, loc.line)
> +function M.demangle(symtab, loc)
> +  local traceno = loc.traceno
> +
> +  if traceno ~= 0 then

Nit: we can move this logic (trace related) to the separate function.

> +    if symtab.trace[traceno] then
> +      local sym = demangle_lfunc(symtab, symtab.trace[traceno])
> +      return string_format("TRACE [%d] ", traceno)..sym

Nit: May be it is more userfriendly to add "started at" to avoid
misunderstanding that all allocation of this trace are on `sym` line.
OTOH, idiomatically this should be done not by demangler, but by
humanizer module.

Thoughts?

Nit: Also, IINM there is no way, when sym is something except the value
returned from elseif branch, is it? I suppose, that we can move this
string_format to the separate function (`format_lua_sorce_line()`) and
call it from here and the elseif branch.

> +    end
> +    return string_format("TRACE [%d]", traceno)
>    end
>  
> -  return string_format("CFUNC %#x", addr)
> +  return demangle_lfunc(symtab, loc)
>  end
>  
>  return M
> -- 
> 2.32.0
> 

[1]: https://github.com/tarantool/tarantool/issues/5815

-- 
Best regards,
Sergey Kaplun

      reply	other threads:[~2021-08-14 11:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28 13:42 [Tarantool-patches] [PATCH luajit v2 0/2] memprof: group allocations on traces by trace number Mikhail Shishatskiy via Tarantool-patches
2021-07-28 13:42 ` [Tarantool-patches] [PATCH luajit v2 1/2] memprof: dump traceno if allocate from trace Mikhail Shishatskiy via Tarantool-patches
2021-08-14  8:00   ` Sergey Kaplun via Tarantool-patches
2021-07-28 13:42 ` [Tarantool-patches] [PATCH luajit v2 2/2] memprof: extend symtab with info about traces Mikhail Shishatskiy via Tarantool-patches
2021-08-14 11:03   ` Sergey Kaplun via Tarantool-patches [this message]

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=YRei70Qf4ZutEQqG@root \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=m.shishatskiy@tarantool.org \
    --cc=skaplun@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH luajit v2 2/2] memprof: extend symtab with info about traces' \
    /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