From: Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Sergey Bronnikov <sergeyb@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit 1/2] test: add utility for parsing `jit.dump`
Date: Mon, 22 May 2023 10:02:30 +0300 [thread overview]
Message-ID: <ZGsThs32AXFA3wLr@root> (raw)
In-Reply-To: <4959c9e3-e0e3-7d26-1a7f-836849cecf4c@tarantool.org>
Hi, Sergey!
Thanks for the review!
On 16.05.23, Sergey Bronnikov wrote:
> Hello, Sergey
>
> Thanks for the patch! See my three comments inline.
>
> On 5/10/23 15:34, Sergey Kaplun wrote:
> > This commit adds simple parser for traces to be analyzed in the test.
> > For now nothing too fancy at all -- just start `jit.dump` to temporary
> > file and parse and remove this file when dump is stopped. The array
> > with resulting traces is returned.
> >
> > For now, just find a single IR by pattern and return ref number and IR,
> > if exists. More functionality may be added if it will be necessary for
> > tests.
> > ---
> > test/tarantool-tests/utils/jit_parse.lua | 156 +++++++++++++++++++++++
> > 1 file changed, 156 insertions(+)
> > create mode 100644 test/tarantool-tests/utils/jit_parse.lua
> >
> > diff --git a/test/tarantool-tests/utils/jit_parse.lua b/test/tarantool-tests/utils/jit_parse.lua
> > new file mode 100644
> > index 00000000..fe8e0e08
> > --- /dev/null
> > +++ b/test/tarantool-tests/utils/jit_parse.lua
>
> The main purpose of this script is using in tests. It could be dangerous
> to leave it without tests at all,
>
> breakage in it could require time for debugging someday. From other side
> I believe no one wants
>
> writing tests for test infrastructure. I suggest add at least a couple
> of unit tests
>
> that will parse trace in plain text format and check that results are
> equal to expected.
Added the following unit test:
===================================================================
diff --git a/test/tarantool-tests/unit-jit-parse.test.lua b/test/tarantool-tests/unit-jit-parse.test.lua
new file mode 100644
index 00000000..536135c6
--- /dev/null
+++ b/test/tarantool-tests/unit-jit-parse.test.lua
@@ -0,0 +1,42 @@
+local tap = require('tap')
+local test = tap.test('unit-jit-parse'):skipcond({
+ ['Test requires JIT enabled'] = not jit.status(),
+})
+
+local jparse = require('utils.jit_parse')
+
+local expected_irs = {
+ -- Use IR numbers as keys, for more readable example.
+ -- `%d` is a workaround for GC64 | non-GC64 stack slot number.
+ [1] = 'int SLOAD #%d+%s+CI',
+ [2] = 'int ADD 0001 %+1',
+ [3] = 'int LE 0002 %+3',
+ [4] = '--- LOOP ------------',
+ [5] = 'int ADD 0002 %+1',
+ [6] = 'int LE 0005 %+3',
+ [7] = 'int PHI 0002 0005',
+}
+local N_TESTS = #expected_irs
+
+jit.opt.start('hotloop=1')
+
+test:plan(N_TESTS)
+
+-- Reset traces.
+jit.flush()
+
+jparse.start('i')
+
+-- Loop to compile:
+for _ = 1, 3 do end
+
+local traces = jparse.finish()
+local loop_trace = traces[1]
+
+for irnum = 1, N_TESTS do
+ local ir_pattern = expected_irs[irnum]
+ local irref = loop_trace:has_ir(ir_pattern)
+ test:is(irref, irnum, 'find IR refernce by pattern: ' .. ir_pattern)
+end
+
+os.exit(test:check() and 0 or 1)
===================================================================
>
> > @@ -0,0 +1,156 @@
<snipped>
> > +
> > +M.start = function(flags)
>
> Comment with description of function's arguments will be useful here and
> M.finish().
Added, the following comments as you suggested:
===================================================================
diff --git a/test/tarantool-tests/utils/jit_parse.lua b/test/tarantool-tests/utils/jit_parse.lua
index 2a9286c9..56267713 100644
--- a/test/tarantool-tests/utils/jit_parse.lua
+++ b/test/tarantool-tests/utils/jit_parse.lua
@@ -139,6 +139,8 @@ local function parse_jit_dump()
return ctx.traces
end
+-- Start `jit.dump()` utility with the given flags, saving the
+-- output in a temporary file.
M.start = function(flags)
assert(JDUMP_FILE == nil, 'jit_parse is already running')
-- Always use plain text output.
@@ -151,6 +153,9 @@ M.start = function(flags)
jdump.start(flags, JDUMP_FILE)
end
+-- Stop `jit.dump()` utility parsing the output from the file and
+-- remove this file after.
+-- Returns an array of traces recorded during the run.
M.finish = function()
assert(JDUMP_FILE ~= nil, 'jit_parse is not running')
jdump.off()
===================================================================
>
> For internal functions too, but it is up to you.
I have no clear vision, how the bytecode or mcode, should be saved for
futher analysis (just save them as is for now). So, I don't leave any
comments near the internal functions.
>
> > + assert(JDUMP_FILE == nil, 'jit_parse is already running')
> > + -- Always use plain text output.
> > + flags = flags .. 'T'
> > + JDUMP_FILE = os.tmpname()
> > + jdump.start(flags, JDUMP_FILE)
> > +end
> > +
> > +M.finish = function()
> > + assert(JDUMP_FILE ~= nil, 'jit_parse is not running')
> > + jdump.off()
> > + local traces = parse_jit_dump()
> > + os.remove(JDUMP_FILE)
> > + JDUMP_FILE = nil
> > + return traces
> > +end
> > +
> > +-- Turn off compilation for these modules to avoid side effects.
> > +jit.off(true, true)
> > +jit.off(jdump.on, true)
> > +jit.off(jdump.off, true)
>
> I would put these three lines on top of file or even disable/enable
> compilation in M.start() and M.finish().
>
> Without enabling compilation back you are mutating environment on using
> this script and
>
> this can be unexpected for those who will use scripts.
Yes, this is reasonable, fixed.
But the first line, you mentioned disable JIT compilation for this
particular module, so I just leave it as is.
See the iterative patch below.
===================================================================
diff --git a/test/tarantool-tests/utils/jit_parse.lua b/test/tarantool-tests/utils/jit_parse.lua
index 7e8f879e..2a9286c9 100644
--- a/test/tarantool-tests/utils/jit_parse.lua
+++ b/test/tarantool-tests/utils/jit_parse.lua
@@ -143,6 +143,10 @@ M.start = function(flags)
assert(JDUMP_FILE == nil, 'jit_parse is already running')
-- Always use plain text output.
flags = flags .. 'T'
+ -- Turn off traces compilation for `jit.dump` to avoid side
+ -- effects for the period of the testing.
+ jit.off(jdump.on, true)
+ jit.off(jdump.off, true)
JDUMP_FILE = os.tmpname()
jdump.start(flags, JDUMP_FILE)
end
@@ -150,15 +154,16 @@ end
M.finish = function()
assert(JDUMP_FILE ~= nil, 'jit_parse is not running')
jdump.off()
+ -- Enable traces compilation for `jit.dump` back.
+ jit.on(jdump.on, true)
+ jit.on(jdump.off, true)
local traces = parse_jit_dump()
os.remove(JDUMP_FILE)
JDUMP_FILE = nil
return traces
end
--- Turn off compilation for these modules to avoid side effects.
+-- Turn off compilation for the module to avoid side effects.
jit.off(true, true)
-jit.off(jdump.on, true)
-jit.off(jdump.off, true)
return M
===================================================================
>
> > +
> > +return M
--
Best regards,
Sergey Kaplun
next prev parent reply other threads:[~2023-05-22 7:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 12:34 [Tarantool-patches] [PATCH luajit 0/2] Fix canonicalization of +-0.0 keys for IR_NEWREF Sergey Kaplun via Tarantool-patches
2023-05-10 12:34 ` [Tarantool-patches] [PATCH luajit 1/2] test: add utility for parsing `jit.dump` Sergey Kaplun via Tarantool-patches
2023-05-15 11:11 ` Maxim Kokryashkin via Tarantool-patches
2023-05-15 12:00 ` Maxim Kokryashkin via Tarantool-patches
2023-05-21 7:47 ` Sergey Kaplun via Tarantool-patches
2023-05-21 7:39 ` Sergey Kaplun via Tarantool-patches
2023-05-22 7:04 ` Sergey Kaplun via Tarantool-patches
2023-05-29 13:55 ` Maxim Kokryashkin via Tarantool-patches
2023-05-16 10:55 ` Sergey Bronnikov via Tarantool-patches
2023-05-22 7:02 ` Sergey Kaplun via Tarantool-patches [this message]
2023-05-22 9:14 ` Sergey Kaplun via Tarantool-patches
2023-05-10 12:34 ` [Tarantool-patches] [PATCH luajit 2/2] Fix canonicalization of +-0.0 keys for IR_NEWREF Sergey Kaplun via Tarantool-patches
2023-05-15 12:05 ` Maxim Kokryashkin via Tarantool-patches
2023-05-20 15:03 ` Sergey Kaplun via Tarantool-patches
2023-05-16 12:17 ` Sergey Bronnikov via Tarantool-patches
2023-05-20 14:54 ` Sergey Kaplun via Tarantool-patches
2023-05-22 7:55 ` Sergey Bronnikov via Tarantool-patches
2023-06-27 13:28 ` [Tarantool-patches] [PATCH luajit 1/3] test: split utils.lua into several modules Igor Munkin via Tarantool-patches
2023-06-27 13:35 ` Igor Munkin via Tarantool-patches
2023-06-28 11:36 ` Sergey Kaplun via Tarantool-patches
2023-06-28 16:07 ` Igor Munkin via Tarantool-patches
2023-07-04 17:10 ` [Tarantool-patches] [PATCH luajit 0/2] Fix canonicalization of +-0.0 keys for IR_NEWREF Igor Munkin via Tarantool-patches
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=ZGsThs32AXFA3wLr@root \
--to=tarantool-patches@dev.tarantool.org \
--cc=sergeyb@tarantool.org \
--cc=skaplun@tarantool.org \
--subject='Re: [Tarantool-patches] [PATCH luajit 1/2] test: add utility for parsing `jit.dump`' \
/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