
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s tech blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, distributed training, and data engineering.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Thu, 16 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/zjit/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/2026-07-16-zjit-lightweight-frames-ruby-41</guid>
    <title>ZJIT의 Lightweight Frames — Ruby 4.1에서 메서드 프레임 푸시를 지우는 법과 그 대가</title>
    <link>https://www.youngju.dev/blog/2026-07-16-zjit-lightweight-frames-ruby-41</link>
    <description>Ruby 4.0은 2025년 12월 25일에 ZJIT을 실었지만, 켜지지 않은 채로 실었습니다 — 바이너리에 컴파일돼 있을 뿐 기본 JIT은 여전히 YJIT입니다. 공식 릴리스 노트의 문장은 &quot;ZJIT은 인터프리터보다 빠르지만 아직 YJIT만큼 빠르지는 않다&quot;였고, 바로 다음 문장이 &quot;Ruby 4.1 ZJIT을 기대해 달라&quot;였습니다. 그 4.1을 겨냥한 작업의 중심에 Lightweight Frames가 있습니다 — 메서드 호출마다 인터프리터 프레임에 pc, iseq, block_code를 쓰는 대신 포인터 하나만 쓰고, 나머지는 백트레이스나 예외처럼 실제로 읽힐 때 되살리는 설계입니다. 흥미로운 건 같은 아이디어가 2023년에 이미 한 번 실패했다는 점입니다. 그때는 인터프리터가 느려져서 폐기됐고, 이번 설계는 정확히 그 지점을 피하려고 다시 그려졌습니다. 이 글은 Lightweight Frames가 무엇을 지우는지, 첫 PR이 왜 거의 빨라지지 않았는지(저자 본인이 그렇게 썼습니다), 그 뒤 넉 달 동안 인라이너와 스택 스필과 버전 수 상한이 어떻게 붙었는지, 그리고 오늘 기준으로 ZJIT이 아직 기본이 아니라는 사실을 정리합니다.</description>
    <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>ruby</category><category>zjit</category><category>yjit</category><category>jit</category><category>compiler</category>
  </item>

    </channel>
  </rss>
