Tarantool development patches archive
 help / color / mirror / Atom feed
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
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

      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 \
    /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

Tarantool development patches archive

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://lists.tarantool.org/tarantool-patches/0 tarantool-patches/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 tarantool-patches tarantool-patches/ https://lists.tarantool.org/tarantool-patches \
		tarantool-patches@dev.tarantool.org.
	public-inbox-index tarantool-patches

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git