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 51FEC96CA9F; Tue, 16 Jan 2024 11:46:28 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 51FEC96CA9F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1705394788; bh=gFauK/L+sjXpLRg0+Z1bO2YKb7ZOCUgDzlLmFXf24Ws=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=khhwaoOoydYU6LC3DBwCyXxxUyCPkcPBb4kEV0VMlIVabjyNvXTlpk8elhMO3SMdU A9aeKzXpV7ZTCdzgqe0wfooB9HttoDXNJH27A8Z7OGHr6wXb3/oT/qTOLrPIPBh+ZH Qa8fV5sYS19UpirIH/lTKvTTfmFvrOlfWZb7Btdg= Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [95.163.41.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 4C4DD7511B6 for ; Tue, 16 Jan 2024 11:46:26 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 4C4DD7511B6 Received: by smtp32.i.mail.ru with esmtpa (envelope-from ) id 1rPf5V-005oEv-0i; Tue, 16 Jan 2024 11:46:25 +0300 Message-ID: <4798f701-875f-4978-8455-a6d3bbfa0325@tarantool.org> Date: Tue, 16 Jan 2024 11:46:24 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Maxim Kokryashkin , tarantool-patches@dev.tarantool.org, skaplun@tarantool.org References: <20240112132643.106145-1-m.kokryashkin@tarantool.org> In-Reply-To: <20240112132643.106145-1-m.kokryashkin@tarantool.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD950579510D3C710962E03D291157C5FB2CF44EA518A5E62FC00894C459B0CD1B95526C8F9842C462684C3E5DA8D0319232DD968E3B54B7754D92625EFBC59CE93 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE71EEA4C46C73542F4EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063727C65896DA7AF7D78638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8D25ADCB5DEA399F36B51A757A0551220117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCAE9A1BBD95851C5BA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18F04B652EEC242312D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE26055571C92BF10FA68A47777D5C6D9CD8FC6C240DEA76429C9F4D5AE37F343AA9539A8B242431040A6AB1C7CE11FEE36089696B24BB1D199735652A29929C6CC4224003CC836476E2F48590F00D11D6E2021AF6380DFAD1A18204E546F3947C062BEEFFB5F8EA3E2E808ACE2090B5E1725E5C173C3A84C3C5EA940A35A165FF2DBA43225CD8A89F4AF35CDC7436330457739F23D657EF2BB5C8C57E37DE458BEDA766A37F9254B7 X-C1DE0DAB: 0D63561A33F958A5BBEF0B84AA8B86B3C9C8BC96666AB7B20BABD00E7652D4A8F87CCE6106E1FC07E67D4AC08A07B9B0DB8A315C1FF4794DBDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0ADE00A9FD3E00BEEDF3FED46C3ACD6F73ED3581295AF09D3DF87807E0823442EA2ED31085941D9CD0AF7F820E7B07EA4CF4A647C628A8B4E75B2192FA7428269122D2F7484188771E860F1E1270AFE526AC7C5EACBE3BE5B47151C858F58AF324711408E5D7E3212C9E4AA9EC4025897FFE48CAC7CA610320002C26D483E81D6BE0DBAE6F56676BC7117BB6831D7356A2DEC5B5AD62611EEC62B5AFB4261A09AF0 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioji89z+8RvaBOUNVFCxl0tNQ== X-Mailru-Sender: 11C2EC085EDE56FAC07928AF2646A7691B2EBC06D97219A8BBC42808716C257BF43CCAED39DA92F1EBA65886582A37BD66FEC6BF5C9C28D98A98C1125256619760D574B6FC815AB872D6B4FCE48DF648AE208404248635DF X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] LJ_GC64: Fix HREFK optimization. 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 Bronnikov via Tarantool-patches Reply-To: Sergey Bronnikov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi, Max thanks for the patch! test is passed after reverting the patch. On the same build repro from the issue [1] has failed. 1. https://github.com/LuaJIT/LuaJIT/issues/840 Sergey On 1/12/24 16:26, Maxim Kokryashkin wrote: > From: Mike Pall > > Contributed by XmiliaH. > > (cherry-picked from commit 91bc6b8ad1f373c1ce9003dc024b2e21fad0e444) > > In `lj_record_idx` when `ix->oldv` is the global nilnode and the > required key is not present in the table, it is possible to pass > the constant key lookup optimization condition because of the > `uint32_t` overflow. Because of that, further recording > incorrectly removes the check for the nilnode, which produces > wrong results when trace is called for a different table. > > Maxim Kokryashkin: > * added the description and the test for the problem > > Part of tarantool/tarantool#9145 > --- > Branch: https://github.com/tarantool/luajit/tree/fckxorg/lj-840-fix-hrefk-optimization > PR: https://github.com/tarantool/tarantool/pull/9591 > Issues: https://github.com/LuaJIT/LuaJIT/issues/840 > https://github.com/tarantool/tarantool/issues/9145 > > src/lj_record.c | 8 +-- > .../lj-840-fix-hrefk-optimization.test.lua | 58 +++++++++++++++++++ > 2 files changed, 62 insertions(+), 4 deletions(-) > create mode 100644 test/tarantool-tests/lj-840-fix-hrefk-optimization.test.lua > > diff --git a/src/lj_record.c b/src/lj_record.c > index a929b8aa..919e7169 100644 > --- a/src/lj_record.c > +++ b/src/lj_record.c > @@ -1374,16 +1374,16 @@ static TRef rec_idx_key(jit_State *J, RecordIndex *ix, IRRef *rbref, > key = emitir(IRTN(IR_CONV), key, IRCONV_NUM_INT); > if (tref_isk(key)) { > /* Optimize lookup of constant hash keys. */ > - MSize hslot = (MSize)((char *)ix->oldv - (char *)&noderef(t->node)[0].val); > - if (t->hmask > 0 && hslot <= t->hmask*(MSize)sizeof(Node) && > - hslot <= 65535*(MSize)sizeof(Node)) { > + GCSize hslot = (GCSize)((char *)ix->oldv-(char *)&noderef(t->node)[0].val); > + if (hslot <= t->hmask*(GCSize)sizeof(Node) && > + hslot <= 65535*(GCSize)sizeof(Node)) { > TRef node, kslot, hm; > *rbref = J->cur.nins; /* Mark possible rollback point. */ > *rbguard = J->guardemit; > hm = emitir(IRTI(IR_FLOAD), ix->tab, IRFL_TAB_HMASK); > emitir(IRTGI(IR_EQ), hm, lj_ir_kint(J, (int32_t)t->hmask)); > node = emitir(IRT(IR_FLOAD, IRT_PGC), ix->tab, IRFL_TAB_NODE); > - kslot = lj_ir_kslot(J, key, hslot / sizeof(Node)); > + kslot = lj_ir_kslot(J, key, (IRRef)(hslot / sizeof(Node))); > return emitir(IRTG(IR_HREFK, IRT_PGC), node, kslot); > } > } > diff --git a/test/tarantool-tests/lj-840-fix-hrefk-optimization.test.lua b/test/tarantool-tests/lj-840-fix-hrefk-optimization.test.lua > new file mode 100644 > index 00000000..a11b91e3 > --- /dev/null > +++ b/test/tarantool-tests/lj-840-fix-hrefk-optimization.test.lua > @@ -0,0 +1,58 @@ > +local tap = require('tap') > + > +-- Test file to demonstrate incorrect HREFK optimization > +-- in LuaJIT. > + > +local ffi = require('ffi') > +local test = tap.test('lj-840-fix-hrefk-optimization'):skipcond({ > + ['Test requires GC64 mode enabled'] = not ffi.abi('gc64'), > + ['Test requires JIT enabled'] = not jit.status(), > +}) > +test:plan(1) > + > +local table_new = require('table.new') > + > +-- Size of single hash node in bytes. > +local NODE_SIZE = 24 > +-- Number of hash nodes to allocate on each iteration > +-- based on the condition from `rec_idx_key` > +local HASH_NODES = 65535 > +-- The vector of hash nodes should have a raw size of > +-- `HASH_NODES * NODE_SIZE`, which is allocated in > +-- `lj_alloc_malloc` directly with `mmap`. However, > +-- the LuaJIT allocator adds a bunch of small paddings > +-- and aligns the required size to LJ_PAGESIZE, which is > +-- 4096, so the actual allocated size includes alignment. > +local ALIGNMENT = 4096 > +-- The vector for hash nodes in the table is allocated based on > +-- `hbits`, so it's actually got a size of 65536 nodes. > +local SINGLE_ITERATION_ALLOC = (HASH_NODES + 1) * NODE_SIZE + ALIGNMENT + 72 > +-- We need to overflow the 32-bit distance to the global nilnode, > +-- so we divide 2^32 by the SINGLE_ITERATION_ALLOC. There are a > +-- bunch of non-table.new allocations already performed, so one > +-- iteration is subtracted to account for them. > +local N_ITERATIONS = 0x100000000 / SINGLE_ITERATION_ALLOC - 1 > +-- Prevent anchor table from interfering with target table allocations. > +local anchor = table.new(N_ITERATIONS, 0) > + > +-- Construct table. > +for _ = 1, N_ITERATIONS do > + table.insert(anchor, table_new(0, HASH_NODES)) > +end > + > +jit.opt.start('hotloop=1') > +local function get_n(tab) > + local x > + for _ = 1, 4 do > + x = tab.n > + end > + return x > +end > + > +-- Record the trace for the constructed table. > +get_n(anchor[#anchor]) > + > +-- Check the result for the table that has the required key. > +local result = get_n({n=1}) > +test:is(result, 1, 'correct value retrieved') > +test:done(true) > -- > 2.43.0 >