<HTML><BODY><div>Hi, Sergey!</div><div>Thanks for the comments!</div><div> </div><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div> <blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_16863052601508714946_BODY">Hi, Maxim!<br>Thanks for the fixes!<br>LGTM, just a few typos.<br><br>On 07.06.23, Maxim Kokryashkin wrote:<br>><br>> Hi!<br>> Thanks for the review!<br>> <br>> > <br>> >>Hi, Maxim!<br>> >>Thanks for the patch!<br>> >>The patch is LGTM except a few insiginificant nits below.<br>> >><br>> >>But I'm wondering: can we examine a test case mentioned in the [1]?<br>> >>I.e. create a really long trace, near the upper bound of the 2GB, so<br>> >>its results become meaningless? You may take a look into<br>> >><test/tarantool-tests/gh-4199-gc64-fuse.test.lua> or<br>> >><test/tarantool-tests/gh-6098-fix-side-exit-patching-on-arm64.test.lua><br>> >>for the inspiration.<br>> >><br>> >>This is desired to show actual problem, and not changes in some<br>> >>synthetic behaviour.<br>> >As we discussed offline, I’ve added the following comment, branch is force-pushed:<br>> >=============================================<br>> >+-- XXX: This test allocates `cdata` objects, but in real world<br>> >+-- scenarios it can be any object that is allocated with<br>> >+-- LuaJIT's allocator, including, for example, trace, if it<br>> >+-- has been allocated close enough to the memory region<br>> >+-- upper bound and if it is long enough.<br>> >+--<br>> >+-- When this issue occurrs with a trace, it may lead to<br><br>Typo: s/occurrs/occurs/</div></div></div></div></blockquote><div>Fixed, thanks! Branch is force-pushed, here is the diff:</div><div>=============================================</div><div><div>diff --git a/test/tarantool-tests/lj-445-fix-memory-probing-allocator.test.lua b/test/tarantool-tests/lj-445-fix-memory-probing-allocator.test.lua</div><div>index 9e31ed5e..a228651b 100644</div><div>--- a/test/tarantool-tests/lj-445-fix-memory-probing-allocator.test.lua</div><div>+++ b/test/tarantool-tests/lj-445-fix-memory-probing-allocator.test.lua</div><div>@@ -25,7 +25,7 @@ collectgarbage('stop')</div><div> -- has been allocated close enough to the memory region</div><div> -- upper bound and if it is long enough.</div><div> --</div><div>--- When this issue occurrs with a trace, it may lead to</div><div>+-- When this issue occurs with a trace, it may lead to</div><div> -- failures in checks that rely on pointers being 32-bit.</div><div> -- For example, you can see one here: src/lj_asm_x86.h:370.</div><div> --</div><div>=============================================</div></div><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div><div class="js-helper js-readmsg-msg"><div><div><br>> >+-- failures in checks that rely on pointers being 32-bit.<br><br>Typo: s/checks/the checks/</div></div></div></div></blockquote><div>That’s not a typo, ignoring. (Double-checked via Quillbot)</div><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div><div class="js-helper js-readmsg-msg"><div><div><br>> >+-- For example, you can see one here: src/lj_asm_x86.h:370.<br>> >+--<br>> >+-- Although it is nice to have a reproducer that shows how<br>> >+-- that issue can affect a non-synthetic execution, it is really<br>> >+-- hard to achieve the described situation with traces because<br>> >+-- allocations are hint-based and there is no robust enough<br>> >+-- way to create a deterministic test for this behavior.<br>> >=============================================<br><br><snipped><br><br>> >><br>> >>--<br>> >>Best regards,<br>> >>Sergey Kaplun<br>> >--<br>> >Best regards,<br>> >Maxim Kokryashkin<br>> > <br><br>--<br>Best regards,<br>Sergey Kaplun</div></div></div></div></blockquote><div><div>--<br>Best regards,</div><div>Maxim Kokryashkin</div></div></div></blockquote></BODY></HTML>