Re: [Tarantool-patches] [PATCH luajit v1] memprof: group allocations on traces by trace number

[Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

Hi, Mikhail!

On 23.07.21, Mikhail Shishatskiy wrote:
> 
> Hi! I have one more question:
> 
> How should we properly test the behavior of profiler recording allocations from traces?
> Now I can write test which roughly estimates number of allocations in loop:
>  
> | local function payload()
> |   -- Preallocate table to avoid table array part reallocations.
> |   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
>   | jit.on() 
> | symbols, events = `run_payload_under_memprof_and_parse`()
> | alloc = `get_all_alloc_events`(symbols, events)
> | test:ok(alloc[`line_where_loop_starts`].num > `some_guaranteed_number`)
> 
> But I think it will be great if we could replace > sign with ==. The problem is we cannot guarantee
> constant number of allocations in the loop: on the most of platforms with `jit.opt.start(‘’hotloop=1’’, ‘’-sink’’)`
> I get 97 allocations in 100-iteration loop, as we spend some iterations to compile the trace. But on freebsd,
> for example, I get 24 allocations. ​​​​

It's OK due to [1].

You can add the following skip condition for the test on FreeBSD:

| -- Disabled on *BSD due to #4819.
| utils.skipcond(jit.os == 'BSD', 'Disabled due to #4819')

>  
> --
> Best regards,
> Mikhail Shishatskiy
>  
>   
> >Среда, 21 июля 2021, 14:48 +03:00 от Sergey Kaplun <skaplun@tarantool.org>:
> > 
> >Hi! Thanks for the patch!
> >Please consider my comments below.
>  
> <snipped>
>  
> >--
> >Best regards,
> >Sergey Kaplun
>  

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

-- 
Best regards,
Sergey Kaplun