<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>LuaJIT on zengjinji · Technical Notes</title><link>https://zengjinji.github.io/tags/luajit/</link><description>Recent content in LuaJIT on zengjinji · Technical Notes</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Fri, 06 Nov 2026 15:10:53 +0800</lastBuildDate><atom:link href="https://zengjinji.github.io/tags/luajit/index.xml" rel="self" type="application/rss+xml"/><item><title>An OpenResty Worker Stuck in an Infinite Loop: How We Found a Missing LuaJIT ARM64 Instruction</title><link>https://zengjinji.github.io/posts/luajit-arm64-infinite-loop/</link><pubDate>Fri, 06 Nov 2026 15:10:53 +0800</pubDate><guid>https://zengjinji.github.io/posts/luajit-arm64-infinite-loop/</guid><description>&lt;blockquote&gt;&#10;&lt;p&gt;A three-year production investigation: from 100% CPU usage and loops that would never terminate to discovering that LuaJIT&amp;rsquo;s ARM64 code generator had dropped an instruction that should have been executed.&lt;/p&gt;&#10;&lt;/blockquote&gt;&#10;&lt;p&gt;Our gateway runs on OpenResty, with most of its business logic written in Lua. OpenResty uses LuaJIT underneath. In JIT mode, LuaJIT compiles Lua code into machine instructions that the CPU can execute directly to improve performance. In everyday development, we usually focus on whether the Lua logic is correct. This time, however, the problem was in &lt;strong&gt;the machine code generated by the JIT compiler&lt;/strong&gt;.&lt;/p&gt;&#10;&lt;h2 id="1-symptoms-in-production"&gt;1. Symptoms in production&lt;/h2&gt;&#10;&lt;p&gt;Our production fleet originally consisted entirely of x86 machines, and everything worked normally. After introducing ARM machines, we began encountering a series of LuaJIT-related problems on those machines.&lt;/p&gt;</description></item></channel></rss>