Java, 이제 시작과 동시에 최고 성능…OpenJDK, AOT 코드 컴파일 도입

JEP 544: Ahead-of-Time Code Compilation

OpenJDK의 JEP 544는 훈련 실행에서 최적화된 네이티브 코드를 AOT 캐시에 저장해, 프로덕션 실행 시 즉시 사용함으로써 시작 및 워밍업 시간을 단축한다. 워크로드가 바뀌면 JIT 컴파일러가 동적으로 디옵티마이즈·리옵티마이즈해 성능을 유지한다. 코드나 설정 변경 없이 기존 AOT 캐시 워크플로를 확장하며, AArch64와 x64를 지원한다. 벤치마크에서 시작 시간이 최대 80%까지 개선됐다.

정적 컴파일은 애플리케이션이 즉시 시작해 워밍업 없이 최고 성능에 도달한다. 그러나 동적 컴파일은 애플리케이션의 핫 스팟 변화에 대응하는 민첩성, 다양한 하드웨어와 소프트웨어에 걸친 이식성, 그리고 동적 클래스 로딩·링크·디스패치·리플렉션 같은 Java 플랫폼의 동적 특성과의 호환성이라는 세 가지 핵심 이점을 제공한다.
  1. cogman10

    Leyden이 트레이닝 런에 꽤 많이 의존하고 있다는 건 이해하지만, 솔직히 그걸 설정하는 게 꽤 부담스러운 일이다.

    이런 종류의 트레이닝 런을 하기 위한 툴링이 사실상 존재하지 않아서, 빌드 파이프라인에 넣으려면 결국 더 맞춤형으로 뭔가를 해야 한다. 내가 유지보수하는 것처럼 좀 더 복잡한 애플리케이션에서는 특히 까다로울 수 있다.

    이게 제공할 수 있는 건 마음에 들지만, 시작하는 데 드는 노력은 별로다.

  2. treyd

    이것과 Android의 ahead-of-time 런타임 간의 아키텍처 차이는 무엇인가?

  3. cyberax

    Excelsior JET은 25년 전에 그걸 했다: https://en.wikipedia.org/wiki/Excelsior_JET

    Sun/Oracle이 그들과 협력해서 네이티브 앱을 제공하지 않은 건 안타까운 일이다. 그랬다면 데스크톱에서 Java를 살릴 수 있었을 텐데.

  4. java-man

    언젠가는 AOT-only 모드(또는 네이티브로 컴파일)를 얻고, 어쩌면 크로스 컴파일까지 가능해지길 바란다.

  5. ledo9915

    작은 사이드 프로젝트에서 나온 데이터 포인트: 나는 코딩 챌린지 사이트를 위해 Piston 샌드박스에서 사용자 코드를 실행한다. 사소한 Java 프로그램이 4 vCPU 박스에서 벽시계 시간으로 2.5-3초가 걸리는데, 거의 전부가 javac와 JVM 시작이다. Go는 빌드와 실행을 합쳐 약 1.7초이고, 인터프리터로 실행하는 Swift는 0.4초이다. Java 때문에 컴파일 언어에 전역 속도 제한을 걸어야 했다. AOT가 JVM 쪽을 몇백 ms로 줄인다면, 작은 박스가 서비스할 수 있는 것이 달라진다.

이 날의 다른 글

2026-09-10