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 759C96EC58; Sun, 1 Aug 2021 20:02:44 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 759C96EC58 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1627837364; bh=HJEA7vHGb9XwVpeWi1ABpvTwIqpDYDCD7aML4z1n+eE=; 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=Qh0TIr0LZrlR67dvhUQoeT/d3+lt4UPVmEgb8hQO7SjP94zLjINeL0R03TeWrF91H GsQ5QtJ8oCH2PRrnmDAWHNk55bhmBXgK32cy1LIzsgkK5EPncSJlzXC4x+vTweiYqf XGcXsRjQcn4e39Fw2HEerxOjjnpqkj/hB0t6Azw0= Received: from smtp50.i.mail.ru (smtp50.i.mail.ru [94.100.177.110]) (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 5293C6E46E for ; Sun, 1 Aug 2021 20:01:48 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 5293C6E46E Received: by smtp50.i.mail.ru with esmtpa (envelope-from ) id 1mAEqQ-0002aX-Tw; Sun, 01 Aug 2021 20:01:47 +0300 Date: Sun, 1 Aug 2021 20:00:33 +0300 To: Igor Munkin Message-ID: References: <20210707143606.3499-1-skaplun@tarantool.org> <20210801103955.GY27855@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210801103955.GY27855@tarantool.org> X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD941C43E597735A9C36A98DBA789EBB6AE26DB9A6C1D9BF7E0182A05F538085040FFDEA5218B920DAA075BFB638F56F9DB80F45A419A6E3D840B3879F552F76584 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7F4E79F226F99D4DDEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637D07BBD2EBFB7BF888638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8ABF3E53DBFF92B6C710023869221C8E2117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC3733B5EC72352B9FA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F44604297287769387670735201E561CDFBCA1751FBDFBBEFFF4125B51D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6A45692FFBBD75A6A089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5D264355FD5A655BB6CFD83F4B40D62D72275B065E8D61E75D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA751B940EDA0DFB0535410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34951738D4D62E58A4239B1FF257AD7304C6D963A9035C853E4602F21666455DC1558BD33A1660E9A81D7E09C32AA3244C0F94E27357DCE83D89E8C77E2750E893E8FBBEFAE1C4874CFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojMCfuYI4PredoFTHYOC2erw== X-Mailru-Sender: 3B9A0136629DC91206CBC582EFEF4CB47AC8532B38FAFEFC7FC2701227512F2240E8A0758BE75EC1F2400F607609286E924004A7DEC283833C7120B22964430C52B393F8C72A41A89437F6177E88F7363CDA0F3B3F5B9367 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] ARM64: Fix write barrier in BC_USETS. X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Kaplun via Tarantool-patches Reply-To: Sergey Kaplun Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Igor, Thanks for the review! Update commit message on the branch, considering you comments. See answers to you questions below. On 01.08.21, Igor Munkin wrote: > Sergey, > > Thanks for the patch! Please consider the comments below. > > On 07.07.21, Sergey Kaplun wrote: > > From: Mike Pall > > > > Contributed by Javier Guerra Giraldez. > > > > (cherry picked from commit c785131ca5a6d24adc519e5e0bf1b69b671d912f) > > > > Closed upvalues are never gray. So after closed upvalue is marked, it is > > marked as black. Black objects can't refer white objects, so for storing > > a white value in closed upvalue, we need to move the barrier forward and > > color our value to gray by using `lj_gc_barrieruv()`. This function > > can't be called on closed upvalues with non-white values (at least there > > is no need to mark it again). > > Minor: Considering the comments in parenthesis, "can't" looks more like > "shouldn't". Anyway, I looked to the sources, and see the assertion, > that only white and alive objects need to be marked, so I'm confused > with your remark. But the assertion means that it can't. The comment is only the clarification why. Ignore for now. > > > > > USETS bytecode for arm64 architecture has the incorrect instruction to > > check that upvalue is closed: > > AFAIU, the instruction is correct, but the nzcv value is not. Fixed. > > > | ccmp TMP0w, #0, #0, ne > > | beq <1 // branch out from barrier movement > > `TMP0w` contains `upvalue->closed` field. If it equals NULL (the first > > `#0`). The second zero is the value of NZCV condition flags set if the > > condition (`ne`) is FALSE [1][2]. If the set value is not white, then > > flags are set to zero and branch is not taken (no Zero flag). If it > > happens at propagate or atomic GC State and the `lj_gc_barrieruv()` > > function is called then the gray value to set is marked as white. That > > leads to the assertion failure in the `gc_mark()` function. > > OK, I understand almost nothing from the part above. Here are the > comments: > 1. "If it equals NULL (the first `#0`)", then what? My bad: I mean here: If it equals NULL (the first `#0`), then the upvalue is open. Added this. > 2. Just to check we are on the same page: the second "immediate" > mentioned in docs[1] is NZCV? Yes. > Then beq <1 branch is not taken since > (TMP0w != 0) is FALSE (i.e. upvalue is not closed), but zero flag in > NZCV value is not set? Yes. > So how does the color of the value to be stored > relate to this control flow? This NZCV value isn't set if the upvalue is white, because condition is of the following instruction | tst TMP1w, #LJ_GC_WHITES // iswhite(str) is TRUE. So the <1 branch is taken, because the upvalue is closed. > 3. AFAICS, if the branch is not taken and is called at > propagate or atomic phase, the value is colored either to gray or black. Yes, that leads to the assertion failure mentioned in the ticket in the LuaJIT upstream. > > > > > This patch changes yielded NZCV condition flag to 4 (Zero flag is up) to > > take the correct branch after `ccmp` instruction. > > > > Sergey Kaplun: > > * added the description and the test for the problem > > > > [1]: https://developer.arm.com/documentation/dui0801/g/pge1427897656225 > > [2]: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes > > Minor: Why #5629 is not mentioned? Added. > > > --- > > > > LuaJIT branch: https://github.com/tarantool/luajit/tree/skaplun/lj-426-incorrect-check-closed-uv > > Tarantool branch: https://github.com/tarantool/tarantool/tree/skaplun/lj-426-incorrect-check-closed-uv > > > > Assertion failure [1] is not related to the patch (I've reproduced it on > > master branch). Looks like another one GC64 issue. > > Is this failure described in #6227 fixed by this patch[1]? Yes. > > > > > How to reproduce: > > 1) Run the following command from the Tarantool repo on Odroid: > > | $ i=0; while [[ $? == 0 ]]; do i=$(($i+1)); echo $i; make LuaJIT-tests; done > > 2) Wait (need 4-15 iterations). > > > > [1]: https://github.com/tarantool/tarantool/runs/3009273464#step:4:4013 > > > > Side note: Thanks to the Lord, that there is no #0 issue and it is not > > mentioned that way... > > Heh, GitHub is not ready for ARM64 support, but Tarantool almost is! > > > > > src/vm_arm64.dasc | 2 +- > > ...6-arm64-incorrect-check-closed-uv.test.lua | 38 +++++++++++++++++++ > > 2 files changed, 39 insertions(+), 1 deletion(-) > > create mode 100644 test/tarantool-tests/lj-426-arm64-incorrect-check-closed-uv.test.lua > > > > > > > diff --git a/test/tarantool-tests/lj-426-arm64-incorrect-check-closed-uv.test.lua b/test/tarantool-tests/lj-426-arm64-incorrect-check-closed-uv.test.lua > > new file mode 100644 > > index 00000000..b757133f > > --- /dev/null > > +++ b/test/tarantool-tests/lj-426-arm64-incorrect-check-closed-uv.test.lua > > @@ -0,0 +1,38 @@ > > +local tap = require('tap') > > + > > +local test = tap.test('lj-426-arm64-incorrect-check-closed-uv') > > +test:plan(1) > > + > > +-- Test file to demonstrate LuaJIT USETS bytecode incorrect > > +-- behaviour on arm64 in case when non-white object is set to > > +-- closed upvalue. > > +-- See also, https://github.com/LuaJIT/LuaJIT/issues/426. > > + > > +-- First, create a closed upvalue. > > +do > > Minor: I'm not sure, we need a separate lexical block here. Could you > please clarify the reason in the comment? We need a closed upvalue. I suppose that it is the simpiest way to create one. Please, provide a simplier example if you know one. > > > + local uv -- luacheck: no unused > > + -- The function's prototype is created with the following > > + -- constants at chunk parsing. After adding this constant to > > + -- the function's prototype it will be marked as gray during > > + -- propogate phase. > > Then what does it test, if the constant is marked as gray? Will this > string be white later? It shouldn't be white, it should be gray, otherwise the aforementioned condition is TRUE (remember, we need FALSE). > > > + local function usets() uv = '' end > > + _G.usets = usets > > +end > > + > > +-- Set GC state to GCpause. > > +collectgarbage() > > +-- Do GC step as often as possible. > > +collectgarbage('setstepmul', 100) > > Minor: Don't get, why you need to make GC less aggressive for the test. > The test is run, until propagate phase is finished. More likely, that it is run, until the upvalue is marked as black during traversing (with the bug). I can remove this line if you insist. > > > + > > +-- We don't know on what exactly step our upvalue is marked as > > +-- black and USETS become dangerous, so just check it at each > > +-- step. > > +-- Don't need to do the full GC cycle step by step. > > +local old_steps_atomic = misc.getmetrics().gc_steps_atomic > > +while (misc.getmetrics().gc_steps_atomic == old_steps_atomic) do > > + collectgarbage('step') > > + usets() -- luacheck: no global > > +end > > + > > +test:ok(true) > > +os.exit(test:check() and 0 or 1) > > -- > > 2.31.0 > > > > [1]: https://lists.tarantool.org/tarantool-patches/20210719073632.12008-1-skaplun@tarantool.org/T/#u > > -- > Best regards, > IM -- Best regards, Sergey Kaplun