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 D39B74124A9; Mon, 15 Jan 2024 18:26:44 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org D39B74124A9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1705332404; bh=d2TY8QAy2jcpFYzEdCMfD8hJoqSDCSovnHvMNAmVyD8=; 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=MmTK2wp02+2vnrJN3NURvtJWACdghNqVXaN99M4ZQ5g0k7inC3xFERp22PfKUduxH Z4cLq3OyJbFtjGysWI5FYcmhO9P9shgvIbdVwSk8BTpaBFPXar6WrBpWHCFGyKsnac Lw012RwX2c6RGvwQSyJAGkf7l7Vocy6Jy1+UJOZw= Received: from smtp3.i.mail.ru (smtp3.i.mail.ru [95.163.41.67]) (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 193534124A9 for ; Mon, 15 Jan 2024 18:26:44 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 193534124A9 Received: by smtp3.i.mail.ru with esmtpa (envelope-from ) id 1rPOrL-007HUF-0t; Mon, 15 Jan 2024 18:26:43 +0300 Date: Mon, 15 Jan 2024 18:22:29 +0300 To: Maxim Kokryashkin Message-ID: References: <20240112132643.106145-1-m.kokryashkin@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240112132643.106145-1-m.kokryashkin@tarantool.org> X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD912D89AD53D86C3F65D8DF77C4AE91779EA053AE719935CD91313CFAB8367EF908E2BE116634AD74DAE2CC67FEC59D48083548FC0136383F9C93BDB566684F10EEEF59CA297A41560 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE73B2A9F8A35432468EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006378D64EDD178B2A1008638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D879ED2DFC0DE762858E841B35F24ED537117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC3A703B70628EAD7BA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18618001F51B5FD3F9D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269176DF2183F8FC7C0FE3A47D6FA29121068655334FD4449CB9ECD01F8117BC8BEAAAE862A0553A39223F8577A6DFFEA7CA819EB9AE8EA3DE343847C11F186F3C59DAA53EE0834AAEE X-C1DE0DAB: 0D63561A33F958A587A30324D9BBE3415082A89EBBBEFA195CBE9943DD7EDCD6F87CCE6106E1FC07E67D4AC08A07B9B06A1CB4668A9CA5FACB5012B2E24CD356 X-C8649E89: 1C3962B70DF3F0ADBF74143AD284FC7177DD89D51EBB7742424CF958EAFF5D571004E42C50DC4CA955A7F0CF078B5EC49A30900B95165D3463DBE2ADA183F62F107CF84C6FC3245A57144BC23D4161A05819ACD160045550CA6F06C0D72CF3C01D7E09C32AA3244C1F485C8740BFD2B1643A49D990D2EEBCBBA718C7E6A9E04285A42E4C463514DC5DA084F8E80FEBD3202CD0F03380D9577A83BD0C44CE203720ABEDE4BBDD9CDD X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioji89z+8RvaBOn1lmwQVZmRA== X-DA7885C5: 0D38C10B9176F4F6BE944D003BE619E9DA40B442CE0EF5C359026F98CAC43349262E2D401490A4A0DB037EFA58388B346E8BC1A9835FDE71 X-Mailru-Sender: 689FA8AB762F7393590D8C940224AE338CEB516B60F594A1300B1DF9EC83B6C30FBE9A32752B8C9C2AA642CC12EC09F1FB559BB5D741EB962F61BD320559CF1EFD657A8799238ED55FEEDEB644C299C0ED14614B50AE0675 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 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" Hi, Maxim! Thanks for the patch! LGTM with a few comments below. On 12.01.24, 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 I suggest clarifying like the following: | `uint32_t` (`MSize`) Feel free to ignore. > incorrectly removes the check for the nilnode, which produces > wrong results when trace is called for a different table. Nit: Please mention also how the problem is fixed. > > 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 > diff --git a/test/tarantool-tests/lj-840-fix-hrefk-optimization.test.lua b/test/tarantool-tests/lj-840-fix-hrefk-optimization.test.lua Nit: We can also add gc64 prefix for this test like: Feel free to ignore. > 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` Nit: Missed dot at the end of the sentence. It is more correct to say that we use this is restricted by the IR format: `op2` field in the HREFK IR is a slot number and it is 16-bit wide. 65535 == 2^16 - 1; i.e., it is the maximum value that can be stored in a 16-bit field. > +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 Minor: So, maybe name it `LJ_PAGESIZE`? Feel free to ignore. > +-- 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 What is the magic number 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. Why is it crucial to subtract it? What happens without it? I suppose that the new table will still be huge enough, won't it? > +local N_ITERATIONS = 0x100000000 / SINGLE_ITERATION_ALLOC - 1 Minor: We can use `(2 ^ 32)` instead of 0x100000000 (it is easier to read). Feel free to ignore. > +-- Prevent anchor table from interfering with target table allocations. Nit: Comment length is more than 66 symbols. > +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 > -- Best regards, Sergey Kaplun