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 85526171979; Thu, 15 Dec 2022 18:39:21 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 85526171979 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1671118761; bh=IYZcKd7H+72Yas9CETyFgxHcgfPm3YMMaVyhutOPO04=; h=Date:In-Reply-To:To:References:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=K1a6l7DkdlMqNB6UTtPEVHJrtX5ts0BzZPHnSRp0I1n5b95wk9Vcqx76uG7gVGJJA TUG8hngAtnA5ppI82n8wjimxqi4BzRPbuF5OINGKRhvVDL11yQSHawaObbbxK0/3Ea yuywfsftsHDCrdsm2M9sqxnFPneLOwaU9zRZFIcQ= Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [95.163.41.73]) (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 D5D9BDF6C1 for ; Thu, 15 Dec 2022 18:39:19 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org D5D9BDF6C1 Received: by smtp32.i.mail.ru with esmtpa (envelope-from ) id 1p5qKM-006qwe-In; Thu, 15 Dec 2022 18:39:19 +0300 Message-Id: <456A2250-D6AC-459D-9082-0723181ADB82@tarantool.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_50CEB189-7834-44F0-BADF-52A392F2F970" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Date: Thu, 15 Dec 2022 18:39:07 +0300 In-Reply-To: To: Sergey Kaplun References: <20221208054618.9104-1-skaplun@tarantool.org> X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD96B873F702985ECC4820909767706002BEEE9F2A7DFC0D8501313CFAB8367EF908E2BE116634AD74D8AA4DAB82335A511E8E45AA93462C179FACDBFE6DB1082C9C54459E63A6ECED5 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7DECE8D0A5E25C0FCEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637B8CD1D12629438CE8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D89501A23E15AFACE8295D65C090642846117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC9FC99A4BA45EE8B4A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F44604297287769387670735200AC5B80A05675ACDF04B652EEC242312D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE0AC5B80A05675ACD68E75A379BAF682BD8FC6C240DEA7642DBF02ECDB25306B2B78CF848AE20165D0A6AB1C7CE11FEE32D01283D1ACF37BA03F1AB874ED89028C4224003CC836476E2F48590F00D11D6E2021AF6380DFAD1A18204E546F3947CB11811A4A51E3B096D1867E19FE1407959CC434672EE6371089D37D7C0E48F6C8AA50765F7900637AF8E4F18C523FAA9EFF80C71ABB335746BA297DBC24807EABDAD6C7F3747799A X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34F1257DC9690AEBA1819DC7DD76797F8309DF1923FCB5D5E8CB7FA05E044602B41D4495BD309E9DC91D7E09C32AA3244C89784150EFC627626AB619CD244409824DBEAD0ED6C55A80FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojP137QGfWHIwQnoIJlKAIHw== X-Mailru-Sender: 5AA3D5B9D8C486464BD4402E82A444E35B867F4F039041BC9118C3DB500FB63CB9B2FA0AF6579CB019381EE24192DF5555834048F03EF5D4C9A814A92B2E3B1BA4250FC3964EA4964198E0F3ECE9B5443453F38A29522196 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] LJ_GC64: Fix ir_khash for non-string GCobj. 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: sergos via Tarantool-patches Reply-To: sergos Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" --Apple-Mail=_50CEB189-7834-44F0-BADF-52A392F2F970 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! Thanks for replies!=20 LGTM. Sergos > On 15 Dec 2022, at 13:13, Sergey Kaplun wrote: >=20 > Hi, Sergos! >=20 > Thanks for the review! >=20 > On 14.12.22, sergos wrote: >> Hi! >>=20 >> Thanks for the patch! >>=20 >> Some addition to Max=E2=80=99s comments. And a question on the test. >>=20 >> Sergos >>=20 >>> On 8 Dec 2022, at 08:46, Sergey Kaplun = wrote: >>>=20 >>> From: Mike Pall >>>=20 >>> Contributed by Peter Cawley. >>>=20 >>> (cherry picked from commit b4ed3219a1a98dd9fe7d1e3eeea3b82f5a780948) >>>=20 >>> When emitting `IR_HREF` for constant value to lookup the = `ir_khash()` >> an ^^^=20 >> perhaps just =E2=80=98for a constant value = lokup=E2=80=99? >>=20 >>> function is used to calculate hash for the corresponding object. >>> This calculation must be the same as in the corresponding = `hashkey()` >>> function from . >>>=20 >>> Hash calculating via passing two arguments `lo`, and `hi` to = `hashrot()` >> the >>=20 >>> routine. For non-string GC objects the first `lo` argument is the = same >>> for GC64 and not GC64 mode -- lower 32 bits of the object address. = For >>> GC64 mode `hi` argument is upper 32 bits of the object address, >>> including specific type NaN-tag. This `hi` argument in `ir_khash()` >> a >>=20 >>> function is miscalculated in GC64 using non-GC64 value (`lo` + >> mode a >>=20 >>> `HASH_BIAS`). As a result, the hash for the GC object is = miscalculated >>> on trace and we exit from trace due to assertion guard on the type = or >> the an >>> value check. >>>=20 >>> This patch fixes calculation of hash value on trace for GC64 mode by >>> making it consistent with `hashkey()`. >> the >>>=20 >=20 > Fixed your comments. > The new commit message is the following: >=20 > | LJ_GC64: Fix ir_khash for non-string GCobj. > | > | Contributed by Peter Cawley. > | > | (cherry picked from commit b4ed3219a1a98dd9fe7d1e3eeea3b82f5a780948) > | > | When emitting the `IR_HREF` for a constant value lookup the = `ir_khash()` > | function is used to calculate the hash for the corresponding object. > | This calculation must be the same as in the corresponding = `hashkey()` > | function from . > | > | Hash is calculated by passing two arguments `lo`, and `hi` to the > | `hashrot()` routine. For non-string GC objects the first `lo` = argument > | is the same for GC64 and not GC64 mode -- lower 32 bits of the = object > | address. For GC64 mode `hi` argument is upper 32 bits of the object > | address, including a specific type NaN-tag. This `hi` argument in > | `ir_khash()` function is miscalculated in GC64 mode using a non-GC64 > | value (`lo` + `HASH_BIAS`). As a result, the hash for the GC object = is > | miscalculated on trace and we exit from the trace due to an = assertion > | guard on the type or value check. > | > | This patch fixes calculation of the hash value on trace for GC64 = mode by > | making it consistent with the `hashkey()`. > | > | Sergey Kaplun: > | * added the description and the test for the problem > | > | Part of tarantool/tarantool#7230 >=20 >=20 >>> Sergey Kaplun: >>> * added the description and the test for the problem >>>=20 >>> Part of tarantool/tarantool#7230 >>> --- >>>=20 >>> Branch: = https://github.com/tarantool/luajit/tree/skaplun/lj-356-ir-khash-non-strin= g-obj-full-ci >>> Issue/PR: >>> * https://github.com/tarantool/tarantool/issues/7230 >>> * https://github.com/LuaJIT/LuaJIT/pull/356 >>> Tarantool PR: https://github.com/tarantool/tarantool/pull/8020 >>>=20 >>> Side note: Problems with red fuzzer jobs look irrelevant to the = patch. >=20 > >=20 >>> diff --git = a/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua = b/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua >>> new file mode 100644 >>> index 00000000..fff0b1a5 >>> --- /dev/null >>> +++ b/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua >>> @@ -0,0 +1,90 @@ >>> +local tap =3D require('tap') >>> +local traceinfo =3D require('jit.util').traceinfo >>> +local table_new =3D require('table.new') >>> + >>> +-- Test file to demonstrate the incorrect GC64 JIT behaviour >>> +-- for `IR_HREF` for on-trace-constant key lookup. >> of an an >>> +-- See also https://github.com/LuaJIT/LuaJIT/pull/356. >>> +local test =3D tap.test('lj-356-ir-khash-non-string-obj') >>> +local N_ITERATIONS =3D 4 >>> + >>> +-- Amount of iteration for trace compilation and execution and >>> +-- additional check, that there is no new trace compiled. >>> +test:plan(N_ITERATIONS + 1) >>> + >>> +-- To reproduce the issue we need to compile a trace with >>> +-- `IR_HREF`, with a lookup of constant hash key GC value. To >>> +-- prevent `IR_HREFK` to be emitted instead, we need a table with >> an `IR_HREFK` emission >=20 > Side note: I'm not sure about "emission" corectness here, so ignoring > this part. >=20 > I've fixed the rest of your comments, see the iterative patch below. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > diff --git = a/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua = b/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua > index fff0b1a5..7f304183 100644 > --- a/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua > +++ b/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua > @@ -3,7 +3,7 @@ local traceinfo =3D require('jit.util').traceinfo > local table_new =3D require('table.new') >=20 > -- Test file to demonstrate the incorrect GC64 JIT behaviour > --- for `IR_HREF` for on-trace-constant key lookup. > +-- of an `IR_HREF` for the on-trace-constant key lookup. > -- See also https://github.com/LuaJIT/LuaJIT/pull/356. > local test =3D tap.test('lj-356-ir-khash-non-string-obj') > local N_ITERATIONS =3D 4 > @@ -14,10 +14,10 @@ test:plan(N_ITERATIONS + 1) >=20 > -- To reproduce the issue we need to compile a trace with > -- `IR_HREF`, with a lookup of constant hash key GC value. To > --- prevent `IR_HREFK` to be emitted instead, we need a table with > --- a huge hash part. Delta of address between the start of the > --- hash part of the table and the current node to lookup must be > --- more than `(1024 * 64 - 1) * sizeof(Node)`. > +-- prevent an `IR_HREFK` to be emitted instead, we need a table > +-- with a huge hash part. Delta of address between the start of > +-- the hash part of the table and the current node to lookup must > +-- be more than `(1024 * 64 - 1) * sizeof(Node)`. > -- See , for details. > -- XXX: This constant is well suited to prevent test to be flaky, > -- because the aforementioned delta is always large enough. > @@ -36,8 +36,8 @@ end > -- exiting the main test cycle. > jit.opt.start('hotloop=3D1') >=20 > --- Prevent `get_const_cdata()` become hot and be compiled before > --- the main test cycle. > +-- Prevent `get_const_cdata()` from becoming hot and being > +-- compiled before the main test cycle. > jit.off() >=20 > filled_tab[get_const_cdata()] =3D MAGIC > @@ -46,10 +46,10 @@ filled_tab[get_const_cdata()] =3D MAGIC > jit.on() >=20 > -- Filling-up the table with GC values to minimize the amount of > --- hash collisions and increases delta between the start of the > +-- hash collisions and increase delta between the start of the > -- hash part of the table and currently stored node. > -for i =3D 1, N_HASH_FIELDS do > - filled_tab[1LL] =3D i > +for _ =3D 1, N_HASH_FIELDS do > + filled_tab[1LL] =3D 1 > end >=20 > -- Prevent JIT misbehaviour before the main test chunk. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >>=20 >>> +-- a huge hash part. Delta of address between the start of the >>> +-- hash part of the table and the current node to lookup must be >>> +-- more than `(1024 * 64 - 1) * sizeof(Node)`. >>> +-- See , for details. >>> +-- XXX: This constant is well suited to prevent test to be flaky, >>> +-- because the aforementioned delta is always large enough. >>> +local N_HASH_FIELDS =3D 1024 * 1024 * 8 >>> +local MAGIC =3D 42 >=20 > >=20 >>> + >>> +test:ok(not traceinfo(2), 'the second trace should not be = compiled') >>=20 >> That=E2=80=99s not quite clear to me: a second trace generation is a = side-effect >> of the incorrect hash calculation. Is it always leads to the trace >> generation?=20 >=20 > How I see this for now. There are two possibilities, when the > aforementioned hash is miscalculated: >=20 > 1) We got `nil` value on a trace to lookup and we exit from the trace = by > assertion guard on the field type (the most possible one, AFAIKS). > 2) We got a value for some existing cdata after hash lookup, so we = don't > exit from a trace, but got an incorrect value by the given key. NB: = I've > updated the generation of the table content to avoid clashing with > `MAGIC` value on the 42nd iteration :). >=20 > So this test should cover both cases. >=20 >>=20 >>> + >>> +-- No more need to prevent trace compilation. >>> +jit.on() >>> + >>> +for i =3D 1, N_ITERATIONS do >>> + -- Check that that all lookups are correct and there is no >>> + -- value from other cdata stored in the table. >>> + test:ok(result_tab[i] =3D=3D MAGIC, 'correct hash lookup from the = table') >>=20 >> And this one checks what then? The hash is calculated correctly, but = the value >> read from the `filled_tab` is incorrect - what can lead to this? >>=20 >>> +end >>> + >>> +os.exit(test:check() and 0 or 1) >>> --=20 >>> 2.34.1 >>>=20 >>=20 >=20 > --=20 > Best regards, > Sergey Kaplun --Apple-Mail=_50CEB189-7834-44F0-BADF-52A392F2F970 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi!

Thanks for = replies! 

LGTM.
Sergos
On 15 Dec 2022, at 13:13, Sergey Kaplun = <skaplun@tarantool.org> wrote:

Hi, Sergos!

Thanks for the = review!

On 14.12.22, sergos = wrote:
Hi!

Thanks for the patch!

Some addition to Max=E2=80=99= s comments. And a question on the test.

Sergos

On 8 Dec 2022, at 08:46, Sergey Kaplun = <skaplun@tarantool.org> wrote:

From: Mike Pall = <mike>

Contributed by Peter Cawley.

(cherry picked = from commit b4ed3219a1a98dd9fe7d1e3eeea3b82f5a780948)

When = emitting `IR_HREF` for constant value to lookup the = `ir_khash()`
       &nb= sp;      an =             &n= bsp;           &nbs= p; ^^^ 
    &= nbsp;           &nb= sp;       perhaps just =E2=80=98for a = constant value lokup=E2=80=99?

function = is used to calculate hash for the corresponding object.
This = calculation must be the same as in the corresponding = `hashkey()`
function from <lj_tab.c>.

Hash calculating = via passing two arguments `lo`, and `hi` to = `hashrot()`
       &nbs= p;            =             &n= bsp;           &nbs= p;            =    the

routine. For = non-string GC objects the first `lo` argument is the same
for GC64 = and not GC64 mode -- lower 32 bits of the object address. For
GC64 = mode `hi` argument is upper 32 bits of the object address,
including = specific type NaN-tag. This `hi` argument in = `ir_khash()`
       &nb= sp;  a

function is = miscalculated in GC64 using non-GC64 value (`lo` = +
         &n= bsp;           &nbs= p;          mode =    a

`HASH_BIAS`). As a = result, the hash for the GC object is miscalculated
on trace and we = exit from trace due to assertion guard on the type = or
         &= nbsp;           &nb= sp;   the =          an
value check.

This patch fixes calculation of hash = value on trace for GC64 mode by
making it consistent with = `hashkey()`.
       &nb= sp;            = ;     the


Fixed = your comments.
The new = commit message is the following:

| = LJ_GC64: Fix ir_khash for non-string GCobj.
|
| Contributed by Peter = Cawley.
|
| (cherry picked from = commit b4ed3219a1a98dd9fe7d1e3eeea3b82f5a780948)
|
| When emitting the = `IR_HREF` for a constant value lookup the `ir_khash()`
| function is used to = calculate the hash for the corresponding object.
| This calculation must = be the same as in the corresponding `hashkey()`
| function from = <lj_tab.c>.
|
| Hash = is calculated by passing two arguments `lo`, and `hi` to the
| `hashrot()` routine. = For non-string GC objects the first `lo` argument
| is the same for GC64 = and not GC64 mode -- lower 32 bits of the object
| address. For GC64 mode = `hi` argument is upper 32 bits of the object
| address, including a = specific type NaN-tag. This `hi` argument in
| `ir_khash()` function = is miscalculated in GC64 mode using a non-GC64
| value (`lo` + = `HASH_BIAS`). As a result, the hash for the GC object is
| miscalculated on trace = and we exit from the trace due to an assertion
| guard on the type or = value check.
|
| This patch fixes = calculation of the hash value on trace for GC64 mode by
| making it consistent = with the `hashkey()`.
|
| = Sergey Kaplun:
| * = added the description and the test for the problem
|
| Part of = tarantool/tarantool#7230


Sergey Kaplun:
* added the description and the test for = the problem

Part of = tarantool/tarantool#7230
---

Branch: https://github.com/tarantool/luajit/tree/skaplun/lj= -356-ir-khash-non-string-obj-full-ci
Issue/PR:
* https://github= .com/tarantool/tarantool/issues/7230
* https://github.com/LuaJ= IT/LuaJIT/pull/356
Tarantool PR: https://github.c= om/tarantool/tarantool/pull/8020

Side note: Problems with red = fuzzer jobs look irrelevant to the = patch.

<snipped>

diff --git = a/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua = b/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua
new = file mode 100644
index 00000000..fff0b1a5
--- /dev/null
+++ = b/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua
@@ = -0,0 +1,90 @@
+local tap =3D require('tap')
+local traceinfo =3D = require('jit.util').traceinfo
+local table_new =3D = require('table.new')
+
+-- Test file to demonstrate the incorrect = GC64 JIT behaviour
+-- for `IR_HREF` for on-trace-constant key = lookup.
     of an =           an
+-- See also https://github.com/LuaJ= IT/LuaJIT/pull/356.
+local test =3D = tap.test('lj-356-ir-khash-non-string-obj')
+local N_ITERATIONS =3D = 4
+
+-- Amount of iteration for trace compilation and execution = and
+-- additional check, that there is no new trace = compiled.
+test:plan(N_ITERATIONS + 1)
+
+-- To reproduce the = issue we need to compile a trace with
+-- `IR_HREF`, with a lookup of = constant hash key GC value. To
+-- prevent `IR_HREFK` to be emitted = instead, we need a table = with
         = ;   an `IR_HREFK` emission

Side note: I'm not sure = about "emission" corectness here, so ignoring
this part.

I've fixed the rest of = your comments, see the iterative patch below.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
diff --git = a/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua = b/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua
index fff0b1a5..7f304183 = 100644
--- = a/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua
+++ = b/test/tarantool-tests/lj-356-ir-khash-non-string-obj.test.lua
@@ -3,7 +3,7 @@ local = traceinfo =3D require('jit.util').traceinfo
local table_new =3D = require('table.new')

-- Test = file to demonstrate the incorrect GC64 JIT behaviour
--- for `IR_HREF` for = on-trace-constant key lookup.
+-- of = an `IR_HREF` for the on-trace-constant key lookup.
-- See also https://github.com/LuaJIT/LuaJIT/pull/356.
local test =3D = tap.test('lj-356-ir-khash-non-string-obj')
local = N_ITERATIONS =3D 4
@@ = -14,10 +14,10 @@ test:plan(N_ITERATIONS + 1)

-- To reproduce the = issue we need to compile a trace with
-- = `IR_HREF`, with a lookup of constant hash key GC value. To
--- prevent `IR_HREFK` = to be emitted instead, we need a table with
--- a huge hash part. = Delta of address between the start of the
--- = hash part of the table and the current node to lookup must be
--- more than `(1024 * = 64 - 1) * sizeof(Node)`.
+-- = prevent an `IR_HREFK` to be emitted instead, we need a table
+-- with a huge hash = part. Delta of address between the start of
+-- the hash part of the = table and the current node to lookup must
+-- be = more than `(1024 * 64 - 1) * sizeof(Node)`.
-- See = <src/lj_record.c>, for details.
-- XXX: = This constant is well suited to prevent test to be flaky,
-- because the = aforementioned delta is always large enough.
@@ -36,8 +36,8 @@ = end
-- exiting the main test = cycle.
jit.opt.start('hotloop=3D1')

--- = Prevent `get_const_cdata()` become hot and be compiled before
--- the main test = cycle.
+-- Prevent = `get_const_cdata()` from becoming hot and being
+-- compiled before the = main test cycle.
jit.off()

filled_tab[get_const_cdata()] =3D MAGIC
@@ -46,10 +46,10 @@ = filled_tab[get_const_cdata()] =3D MAGIC
jit.on()

-- = Filling-up the table with GC values to minimize the amount of
--- hash collisions and = increases delta between the start of the
+-- = hash collisions and increase delta between the start of the
-- hash part of the = table and currently stored node.
-for i = =3D 1, N_HASH_FIELDS do
- =  filled_tab[1LL] =3D i
+for _ = =3D 1, N_HASH_FIELDS do
+ =  filled_tab[1LL] =3D 1
end

-- = Prevent JIT misbehaviour before the main test chunk.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


+-- a huge hash part. Delta of address between the start = of the
+-- hash part of the table and the current node to lookup must = be
+-- more than `(1024 * 64 - 1) * sizeof(Node)`.
+-- See = <src/lj_record.c>, for details.
+-- XXX: This constant is well = suited to prevent test to be flaky,
+-- because the aforementioned = delta is always large enough.
+local N_HASH_FIELDS =3D 1024 * 1024 * = 8
+local MAGIC =3D 42

<snipped>

+
+test:ok(not traceinfo(2), 'the second trace should = not be compiled')

That=E2=80=99s not quite clear to = me: a second trace generation is a side-effect
of the incorrect hash = calculation. Is it always leads to the trace
generation? 

How I see this for now. = There are two possibilities, when the
aforementioned hash is miscalculated:

1) We got `nil` value on = a trace to lookup and we exit from the trace by
assertion guard on the = field type (the most possible one, AFAIKS).
2) We got a value for = some existing cdata after hash lookup, so we don't
exit from a trace, but = got an incorrect value by the given key. NB: I've
updated the generation = of the table content to avoid clashing with
`MAGIC` value on the = 42nd iteration :).

So this = test should cover both cases.


+
+-- No more need to prevent trace = compilation.
+jit.on()
+
+for i =3D 1, N_ITERATIONS do
+ =  -- Check that that all lookups are correct and there is no
+ =  -- value from other cdata stored in the table.
+ =  test:ok(result_tab[i] =3D=3D MAGIC, 'correct hash lookup from the = table')

And this one checks what then? The hash is = calculated correctly, but the value
read from the `filled_tab` is = incorrect - what can lead to this?

+end
+
+os.exit(test:check() and 0 or 1)
-- 
2.34.1



-- 
Best regards,
Sergey = Kaplun

= --Apple-Mail=_50CEB189-7834-44F0-BADF-52A392F2F970--