From: Igor Munkin via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Sergey Kaplun <skaplun@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH luajit] ARM64: Fix write barrier in BC_USETS. Date: Wed, 11 Aug 2021 10:22:05 +0300 [thread overview] Message-ID: <20210811072205.GM27855@tarantool.org> (raw) In-Reply-To: <20210707143606.3499-1-skaplun@tarantool.org> Sergey, I've checked the patch into tarantool branch in tarantool/luajit and bumped a new version in master. On 07.07.21, Sergey Kaplun wrote: > From: Mike Pall <mike> > > 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). > > USETS bytecode for arm64 architecture has the incorrect instruction to > check that upvalue is closed: > | 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. > > 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 > --- > > 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. > > 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... > > 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 > <snipped> > -- > 2.31.0 > -- Best regards, IM
prev parent reply other threads:[~2021-08-11 7:46 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-07 14:36 Sergey Kaplun via Tarantool-patches 2021-08-01 10:39 ` Igor Munkin via Tarantool-patches 2021-08-01 17:00 ` Sergey Kaplun via Tarantool-patches 2021-08-08 19:28 ` Igor Munkin via Tarantool-patches 2021-08-09 16:01 ` Sergey Kaplun via Tarantool-patches 2021-08-09 19:46 ` Igor Munkin via Tarantool-patches 2021-08-10 16:40 ` Sergey Ostanevich via Tarantool-patches 2021-08-11 5:57 ` Vitaliia Ioffe via Tarantool-patches 2021-08-11 7:22 ` Igor Munkin 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=20210811072205.GM27855@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=imun@tarantool.org \ --cc=skaplun@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit] ARM64: Fix write barrier in BC_USETS.' \ /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