<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Runtime on Hammer's Blog</title><link>https://lkic1625.github.io/blog/runtime/</link><description>Recent content in Runtime on Hammer's Blog</description><generator>Hugo</generator><language>ko-kr</language><copyright>© 조원빈 - All rights reserved</copyright><lastBuildDate>Mon, 05 Oct 2026 17:22:05 +0900</lastBuildDate><atom:link href="https://lkic1625.github.io/blog/runtime/index.xml" rel="self" type="application/rss+xml"/><item><title>LDE와 런타임 스케줄링: Go, Rust, Java</title><link>https://lkic1625.github.io/os-limited-direct-execution/</link><pubDate>Mon, 05 Oct 2026 17:22:05 +0900</pubDate><guid>https://lkic1625.github.io/os-limited-direct-execution/</guid><description>&lt;h2 id="개요">개요&lt;/h2>
&lt;p>OS에게 안전한 처리를 맡기고, 적절히 제공하기 위해 우리는 커널과 유저모드를 나누었다. 특히, 적절한 스케쥴링과 함께라면 우리는 OS로 하여금 좋은 퍼포먼스를 제공 받을 수 있을 것이다. 다만, 요즘의 프로그래밍 언어들은 여기에서 멈추지 않는다.
특히, 경량 스레드라는 모델링은 현대 시스템의 맞는 런타임 추상화를 한 번 더 진행했다. 복잡도를 늘리는 대신 OS 스레드의 스케쥴링과는 전혀 다른 영역에 런타임 스케쥴링을 하도록 하여 컨텍스트 스위칭 비용을 줄이고 효율성을 높인다. 이에 대한 간략한 추상화를 알아보자.&lt;/p></description></item><item><title>Go Runtime Internals — 작성 중</title><link>https://lkic1625.github.io/go-runtime-internals/</link><pubDate>Wed, 30 Sep 2026 17:41:37 +0900</pubDate><guid>https://lkic1625.github.io/go-runtime-internals/</guid><description>&lt;blockquote>
&lt;p>&lt;strong>작성 중인 글입니다.&lt;/strong> Goroutine Stack까지 정리했으며, M·P·schedt·netpoller·sysmon 설명은 이어서 작성할 예정입니다.&lt;/p>&lt;/blockquote>
&lt;h2 id="개요">개요&lt;/h2>
&lt;p>고루틴을 설명하라고 하면, 반드시 나오는 이야기가 있다. GMP 구조이다. 고루틴의 위대한 업적 중 하나를 뽑자면, 어려운 경량 스레드 모델링에 대해 가장 직관적이고 명료한 모델링이라고 생각한다. 다만, GMP 모델을 아는 것과 이를 완전히 이해하는 것은 서로 다른 문제이다. 아래 질문에 대해서 답변할 수 있는가?&lt;/p>
&lt;ul>
&lt;li>왜 &lt;code>G → OS Thread&lt;/code>가 아니라 &lt;strong>G-M-P&lt;/strong>일지&lt;/li>
&lt;li>왜 &lt;code>GOMAXPROCS&lt;/code>를 통해 &lt;strong>P 개수&lt;/strong>를 제한해야하는지, 그리고 그 개수는 왜 코어 개수인지.&lt;/li>
&lt;li>go runtime은 어떻게 &lt;strong>필요한 M만 유지하면서 runnable G를 P에 공급하는지&lt;/strong>&lt;/li>
&lt;li>network I/O 시에 고루틴은 어떻게 동작하는지
이 글은 이 질문에 답변하기 위한 글이다.&lt;/li>
&lt;/ul>
&lt;h2 id="topology">Topology&lt;/h2>
&lt;h3 id="g---goroutine">G - Goroutine&lt;/h3>
&lt;h4 id="goroutine-stack">Goroutine Stack&lt;/h4>
&lt;p>우리가 가장 잘 아는 고루틴이다. stackful한 구조를 통해, 자신이 언제 어디서 멈췄는지를 기억하는, 독립적인 Call Stack을 가지고 있다. 참고로, 보통 코루틴을 나누는 구조 중에 하나는 stackful, stackless이다. stackless는 간단하게 설명하자면, 명시적인 구절을 통해 실제 컴파일 단에서 suspension 지점을 지정하고 상태 기계를 통해 관리하는 방식이다.(물론, 호출자의 스택을 이용해 최소한의 정보만을 저장을 한다는 의미이다.)
코루틴의 대한 다양한 논의와 코루틴 이론에 대해서는 몇 가지 글을 참고할 수 있겠으나, 이 글에서는 다루지 않겠다. [1], [2]&lt;/p></description></item></channel></rss>