인터프리터로 시작한 코드가 어떻게 C보다 빨라질까?

JVM은 켜자마자 최고 성능으로 달리지 않아요. 처음엔 인터프리터로 바이트코드를 한 줄씩 실행하면서 어떤 메서드가 자주 불리는지(hot)를 관찰합니다. 충분히 뜨거워지면 그때서야 JIT 컴파일러가 기계어로 바꿔요. 이렇게 실행하면서 컴파일하기에 Just-In-Time이라 부릅니다.

hot 판단은 두 종류의 카운터로 해요. 메서드가 불린 횟수(호출 카운터, invocation counter)와 루프가 뒤로 점프한 횟수(백엣지 카운터, back-edge counter). 이 값들이 임계치(-XX:CompileThreshold 등)를 넘으면 컴파일 큐에 올라갑니다.

JIT의 최적화는 수십 가지지만, 성능에 가장 크게 기여하는 것부터 봅시다. 그중 인라이닝이 "최적화의 어머니"라 불려요 — 다른 최적화들이 인라이닝으로 열린 넓은 시야 위에서 이뤄지기 때문입니다.

// 호출 지점에 List 구현이 ArrayList 하나만 온다면 (monomorphic)
for (int i = 0; i < list.size(); i++) {   // list.size() 가상호출처럼 보이지만
    sum += list.get(i);                    // 프로파일로 ArrayList로 특정 →
}                                          // 역가상화 → 인라이닝 → 경계 제거
// 반대로 여기에 LinkedList, CopyOnWriteArrayList... 여럿이 섞이면
// megamorphic 이 되어 인라이닝이 막히고 느려짐

이스케이프 분석(Escape Analysis)은 "이 객체가 자기를 만든 메서드(또는 스레드) 밖으로 새어 나가는가?"를 컴파일러가 추적하는 기법이에요. 새지 않는다는 게 증명되면, JVM은 힙 할당이라는 값비싼 일을 아예 건너뛸 수 있습니다.

int distanceSq(int x, int y) {
    Point p = new Point(x, y);   // p 는 이 메서드 밖으로 안 샘(NoEscape)
    return p.x * p.x + p.y * p.y; // → 스칼라 치환: new Point 사라지고
}                                 //   x*x + y*y 로 축약 (힙 할당 0)

void log(Object msg) {
    StringBuilder sb = new StringBuilder(); // 지역 · 공유 안 됨
    synchronized (sb) {          // 락 제거(elision) 대상 → 사실상 삭제
        sb.append(msg);
    }
}

C2의 강력함은 투기적 최적화(speculative optimization)에서 나와요. "지금까지 이 call site엔 Dog만 왔으니 앞으로도 그럴 것"이라 가정하고 공격적으로 인라이닝·역가상화합니다. 그런데 가정은 틀릴 수 있죠. 그래서 컴파일된 코드 곳곳에 가드(guard)를 심어두고, 가정이 깨지면 역최적화로 되돌립니다.

여기까지 온 최적화들 때문에 순진한 벤치마크는 거의 항상 틀립니다. System.nanoTime()으로 루프를 감싸 재는 방식은 워밍업, DCE, 상수 폴딩을 하나도 통제하지 못해요. 그래서 JVM 진영은 JMH(Java Microbenchmark Harness)라는 전용 도구를 씁니다.

@State(Scope.Thread)          // 입력을 상태로 보관 → 상수 폴딩 방지
public class HashBench {
    int x = 42;               // final 아님 · JVM이 상수로 못 봄

    @Benchmark
    @Warmup(iterations = 5)   // JIT 워밍업 유도
    @Fork(2)                  // 별도 JVM 2회
    public int hash() {
        return Integer.hashCode(x * 31 + 7);
    }                          // 반환값 → JMH가 Blackhole로 소비 → DCE 방지
}

JIT의 약점은 워밍업이에요. 켜자마자 최고 성능이 아니고, 짧게 살다 죽는 프로세스(서버리스·CLI)에선 이 워밍업 비용을 회수하지 못합니다. 그래서 나온 대안이 AOT(Ahead-Of-Time) 컴파일 — GraalVM native image는 빌드 시점에 전체 프로그램을 미리 기계어로 컴파일해 독립 실행파일로 만들어요.