워크플로는 on에 선언한 이벤트가 발생할 때 실행됩니다. 이벤트는 성격에 따라 네 갈래로 나뉩니다.

성능 관점에서는 schedule의 공식 문서 문구를 알아둘 만합니다. GitHub은 schedule 이벤트가 Actions 전체의 부하가 높은 시간대에 지연될 수 있고, 매시 정각이 바로 그런 시간대이며, 부하가 충분히 높으면 큐잉된 잡이 아예 드랍될 수도 있다고 안내합니다. cron의 분을 0이 아닌 값으로 두면 정각에 몰리는 혼잡을 피할 수 있습니다.

이벤트 자체가 생성되지 않는 경우도 있습니다. 한 번에 5,000개가 넘는 브랜치를 푸시하면 push 이벤트가 만들어지지 않고, 태그를 한 번에 3개 넘게 푸시하면 태그에 대한 이벤트가 만들어지지 않습니다. 워크플로가 실행되지 않았는데 로그도 없다면, 워크플로 설정보다 앞 단계인 이벤트 생성이 생략되지 않았는지 의심해 볼 수 있습니다.

서버 쪽 내부 구조를 설명하는 문서는 없지만, 공식 문서와 장애 보고서 곳곳에 언급된 내부 서비스와 의존 시스템의 정보를 이으면 큰 흐름을 재구성할 수 있습니다.

이와 같이 워크플로 실행은 여러 큐와 서비스를 지나는 비동기 파이프라인입니다. webhook 처리 → 실행 생성 → 잡 큐 → 러너 배정 중 어느 구간이 막혀도 사용자에게는 똑같이 "워크플로가 시작되지 않는" 증상으로 보입니다.

참고로 러너가 GraphQL API를 직접 호출하지는 않습니다. 액션 내려받기와 API 호출은 api.github.com 등 REST 엔드포인트와 *.actions.githubusercontent.com 계열 도메인을 씁니다. 워크플로 파일을 읽거나 액션을 resolve하는 단계에서 내부적으로 GraphQL을 쓰는지는 공개된 자료가 없습니다.

이 구조에서 성능에 크게 영향을 주는 요소는 워크플로 파일이나 조건식의 개수가 아니라, 조건이 파이프라인의 어느 단계에서 평가되는가입니다. 조건은 앞쪽에서 평가될수록 이득입니다. 같은 "건너뛰기"라도 평가 시점이 다릅니다.

그래서 튜닝의 핵심은 실행과 잡을 만들지 않도록 조건을 가능한 한 앞 단(on 필터)으로 옮기는 일입니다.

반대로 개수는 걱정할 요인이 아닙니다. 트리거 평가는 파일 단위로 일어나므로 파일이 많으면 평가할 대상도 늘어나는 셈이지만, 파일 수가 실행 시작을 늦춘다는 공식 자료나 측정은 찾지 못했습니다. 공식 한도도 파일 수가 아니라 파일 하나의 크기(500KB), 트리거 이벤트 빈도(저장소당 10초에 1,500개), 실행 생성 빈도(10초에 500개)에 걸려 있습니다. 조건식도 마찬가지입니다. 표현식 평가는 서버 쪽에서 일어나고, 그 비용이 실행 시간에 잡힐 만큼 크다는 근거는 없습니다. 워크플로 파일을 합치거나 조건식을 줄이는 정리는 관리 편의로는 의미가 있어도, 실행 시간을 줄이는 수단은 아닙니다.

두 평가 시점의 차이는 필수 상태 검사 문제와도 이어집니다. on 필터로 워크플로를 건너뛰면 검사가 Pending으로 남아 병합이 막히지만, 잡 수준 if로 건너뛴 잡은 상태가 Success로 보고되어 병합을 막지 않습니다. 그래서 필수 검사로 지정한 워크플로에서는 경로 필터 대신 잡 수준에서 변경 파일을 판별해 건너뛰는 방식이 우회책이 됩니다.

앞 절에서 장애 보고서는 구조를 재구성하는 근거였는데, 이 절에서는 장애 사례 자체를 봅니다. 장애가 파이프라인의 어느 단계를 막는지, 그리고 그때 생기는 지연이 왜 워크플로 튜닝의 범위 밖인지가 여기서 드러납니다.

2025년 말부터 GitHub의 장애는 잦아지고 있습니다. 월별 availability report에 집계된 인시던트 수가 2025년 하반기에는 월 3~5건이었는데 2026년에는 월 6~10건으로 늘었습니다. 이 글을 쓰는 2026년 8월에는 1일부터 27일까지 githubstatus.com에 올라온 인시던트 25건 중 7건이 Actions 관련이었습니다. 증상도 "실행 시작 지연", "잡이 queued 상태로 고착"처럼 파이프라인 앞 단이 막히는 유형이 반복됩니다.

원인을 나눠 보면, Actions 파이프라인 자체의 장애와 파이프라인이 의존하는 공용 서비스·인프라의 장애가 섞여 있습니다.

GitHub도 이 구조를 문제로 인정하고, 2026년 3월에 "Actions와 Git 같은 핵심 시스템이 공유 인프라 문제에 영향받지 않도록 의존성을 격리하겠다"고 밝혔습니다. 커뮤니티에서는 진행 중인 데이터센터 이전 작업을 장애 증가와 연결하는 추측도 있지만, 공식 장애 보고서가 이전 작업을 원인으로 지목한 적은 없습니다.

장애나 혼잡으로 생기는 대기 시간은 워크플로 안쪽을 아무리 튜닝해도 줄지 않습니다. 그래서 이 글에서는 먼저 튜닝할 대상을 측정할 수 있는 기법을 설명합니다.

잡이 실제로 실행된 시간과 별개로, 러너를 배정받기까지 기다리는 시간이 따로 있습니다. 워크플로 실행이 생성된 시각(createdAt)과 잡이 시작된 시각(startedAt)의 차이가 대기 시간입니다. 앞에서 본 파이프라인으로 말하면 잡 큐잉부터 러너 배정까지의 구간입니다.

개인 저장소에서는 대기가 거의 없지만, 동시 실행 한도에 걸리는 조직 저장소에서는 대기가 실행 시간보다 길어지기도 합니다. 그런 상황이면 워크플로 내부를 아무리 다듬어도 체감 시간이 줄지 않습니다. 저장소나 조직의 Insights 탭에 있는 Actions Performance Metrics에서 잡별 평균 실행 시간과 평균 대기 시간을 최대 1년 치까지 볼 수 있으니, 여기서 대기가 문제인지 실행이 문제인지를 먼저 구분하는 편이 좋습니다.

on에 paths나 paths-ignore를 걸면 바뀐 파일 경로에 따라 실행을 건너뜁니다. 앞에서 본 대로 이 필터는 실행 생성 전에 평가되므로, 필터에 걸리면 파이프라인에 아무것도 들어가지 않습니다.

paths를 쓸 때는 워크플로 파일 자신을 목록에 넣어 두는 점이 중요합니다. 이렇게 해야 워크플로를 고쳤을 때 그 변경이 검증됩니다.

같은 브랜치에 커밋을 연달아 밀어 넣으면 이전 커밋의 워크플로가 계속 돌고 있는데 새 실행이 또 시작됩니다. 결과를 볼 필요가 없는 실행이 러너를 차지합니다. concurrency로 그룹을 묶고 cancel-in-progress를 켜면 진행 중이던 실행이 취소됩니다.

그런데 이 설정을 모든 워크플로에 넣으면 안 됩니다. 배포 워크플로는 중간에 취소되면 어중간한 상태로 남을 수 있습니다. 그런 워크플로는 그룹만 묶고 취소는 끕니다.

cancel-in-progress: false로 두면 진행 중인 실행은 끝까지 돌고 새 실행은 대기합니다. 다만 기본값으로는 한 그룹에서 대기할 수 있는 실행이 하나뿐이고, 뒤에 들어온 실행이 먼저 대기하던 실행을 취소합니다. 커밋 세 개를 연달아 밀면 첫 번째는 배포되고 두 번째는 취소되며 세 번째만 배포됩니다. 중간 실행까지 모두 돌려야 한다면 queue: max를 지정해 최대 100개까지 줄을 세울 수 있습니다. queue: max와 cancel-in-progress: true는 동작이 서로 어긋나므로 함께 쓸 수 없습니다.

캐시는 복원과 저장에도 시간을 씁니다. 복원은 setup 단계에서, 저장은 잡 마지막의 Post 단계에서 일어나므로, 실행 결과 화면에서 이 두 단계의 시간을 보면 캐시가 얼마를 쓰는지 알 수 있습니다.

캐시가 이득인지는 "다시 내려받는 시간"과 "복원 + 저장 시간"의 차이로 정해집니다. 의존성 다운로드에 시간을 많이 쓰는 프로젝트는 캐시로 줄어들 가능성이 높지만, 압축한 결과가 수백 MB인 캐시를 만들면 올리고 내리는 시간이 다시 받는 시간을 넘길 수 있습니다. 어느 쪽인지는 캐시를 붙인 전후의 잡 전체 시간을 비교해야 알 수 있습니다. 다음 글에 캐시를 붙여도 잡 전체 시간이 줄지 않은 실제 측정 사례를 실었습니다.

캐시를 설계할 때 알아야 할 GitHub의 제약이 세 가지 있습니다.

풀 리퀘스트에는 규칙이 하나 더 붙습니다. 풀 리퀘스트에서 만든 캐시는 병합 참조(refs/pull/…​/merge)에 묶이므로, 그 풀 리퀘스트를 다시 실행할 때만 복원됩니다. 기본 브랜치나 다른 풀 리퀘스트는 그 캐시를 쓰지 못합니다. 따라서 캐시를 처음 채우는 일은 기본 브랜치의 워크플로가 맡아야 하고, 풀 리퀘스트는 거기서 복원해 쓰는 구조가 됩니다.

Call by value와 call by reference는 pass by value, pass by reference라고도 부릅니다. call by ~는 1960년에 발표된 ALGOL 60 보고서부터 쓰인 형태입니다. 1963년 개정 보고서의 4.7.3절이 파라미터 전달 방식을 규정하며 4.7.3.1에 'Value assignment (call by value)', 4.7.3.2에 'Name replacement (call by name)'이라는 제목을 붙였습니다. 실무와 교재에서는 pass by ~도 널리 쓰입니다. 이 글에서는 call by ~로 통일했습니다.

Java, JavaScript, Python처럼 호출자 변수 자체가 아니라 객체를 공유하는 인자 전달 동작을 call by sharing이라고 부르기도 합니다. Barbara Liskov를 비롯한 설계팀이 1970년대 중반에 만든 언어인 CLU의 설계 문서에서 쓴 용어입니다. 뒤에서 살펴볼 Java, Kotlin, JavaScript, Python의 객체 인자 동작과 C#의 class 인스턴스 전달이 모두 여기에 해당합니다. Python 튜토리얼이 쓴 call by object reference도 같은 뜻입니다. Go의 맵이나 포인터, C의 포인터를 전달할 때도 같은 구조가 나타납니다.

Call by value라고 하면 '객체가 통째로 복사된다’는 오해를, call by reference라고 하면 '재할당도 호출한 쪽 변수에 반영된다’는 오해를 낳을 수 있습니다. Call by sharing은 이런 오해를 피하는 데 좋은 용어입니다. 뒤에서 인용할 MDN의 JavaScript 문서처럼 이 용어를 쓰는 자료도 있지만, 교재와 언어 사양에서 표준 용어로 자리 잡지는 않았습니다. 그래서 이 글에서는 call by value와 call by reference 두 가지로만 구분해서 설명을 이어 가겠습니다.

아래 코드의 출력으로 Java의 전달 방식을 확인할 수 있습니다.

즉, 앞에서 정리한 기준대로라면 Java는 primitive type이든 객체든 call by value로 동작합니다.

메서드 파라미터로 객체를 전달하는 경우를 더 자세히 살펴보겠습니다.

그런데 파라미터를 재할당하지 않고 파라미터가 가리키는 객체의 내부 상태를 바꾸면, 호출한 쪽의 변수로 접근해도 바뀐 상태가 그대로 확인됩니다.

호출자 변수로 읽어도 바뀐 상태가 보이니 "객체는 call by reference로 전달된다"는 설명이 그럴듯하게 들립니다. 그러나 앞에서 설명했듯이, 두 방식을 구분하는 실용적인 기준은 파라미터에 대입한 값이 호출자 변수에 반영되는가입니다. 호출자 변수로 바뀐 상태가 보이는 것은 두 변수가 같은 객체를 가리키기 때문일 뿐이고, 전달되는 것은 여전히 참조값의 복사본입니다. 즉 call by value입니다.

Head First Java에서는 객체 참조를 TV 리모컨에 비유해서 설명합니다. 객체를 전달하면 TV(객체)가 복사되는 것이 아니라 그 TV를 조작할 수 있는 리모컨(참조값)이 복사됩니다. 복사된 리모컨으로 채널을 바꾸면(객체 상태 변경) 원래 리모컨을 가진 사람에게도 바뀐 채널이 보입니다. 복사된 리모컨을 새 TV에 연결하면(재할당, targetTv = new Tv()) 그 리모컨으로는 원래 TV를 조작할 수 없고, 원래 리모컨은 여전히 원래 TV에 연결되어 있습니다.

Java의 창시자 James Gosling은 공저한 The Java Programming Language에서 이 오해를 직접 지적했습니다.

최신 공식 Java 학습 자료인 Dev.java에서도 같은 내용을 설명합니다.

앞에서 인용한 Dragon Book도 같은 절에서 Java는 call by value만 쓴다고 밝힙니다. 그런데 이어지는 call by reference 항목에서는 Java가 기본 타입이 아닌 값에는 call by reference를 쓰는 것처럼 동작한다고 적었습니다.

'call by reference를 쓰는 것처럼 동작한다(behaves as if)'는 객체를 통째로 복사하지 않고, 호출된 메서드에서 바꾼 객체 상태가 호출한 쪽에서도 보인다는 효과를 가리킵니다. 이 책이 앞에서 밝혔듯이 실제 전달 방식은 call by reference가 아니라는 전제를 깐 표현입니다.

'reference’라는 용어도 Java가 객체를 call by reference로 전달한다는 오해를 키운 것으로 보입니다. Java에서는 객체를 가리키는 값을 'reference’라고 부르는데, 이 단어가 'call by reference’의 reference와 겹치기 때문입니다. 더 정확하게 표현하면 Java는 객체를 가리키는 참조값을 call by value로 전달합니다.

Java의 reference는 객체를 식별하고 접근하는 값입니다. 포인터처럼 이해할 수 있습니다. 다음의 Java 객체 접근 동작은

C++ 포인터를 쓴 다음 코드와 비슷합니다.

Java의 myTv 변수는 객체 자체가 아니라 객체를 가리키는 값을 담고 있습니다. myTv를 다른 메서드의 인자로 넘기면 이 참조값이 복사되어 전달됩니다. 다만 위 C++ 코드는 객체 접근과 포인터 재할당을 설명하기 위한 비유이며, 객체의 수명 관리나 참조의 실제 표현까지 같다는 뜻은 아닙니다.

이와 관련된 JLS(Java Language Specification)의 서술을 보겠습니다. JLS도 '포인터’라는 단어를 씁니다. 4.3.1. Objects 절은 참조값을 객체를 가리키는 포인터로 정의합니다.

다만 이는 언어 수준의 의미를 설명하는 표현이지, 참조값이 원시 메모리 주소와 같은 형식이라고 보장하는 문장은 아닙니다. JVMS(Java Virtual Machine Specification) 2.7은 객체의 내부 구조를 특정하지 않으며, 일부 구현에서는 참조가 객체 데이터가 아니라 핸들을 가리킬 수도 있다고 설명합니다. 여기서 핸들은 참조와 객체 데이터 사이에 놓인 작은 중간 구조입니다. 참조는 핸들을 가리키고, 핸들 안의 포인터가 다시 객체 데이터와 메서드 테이블을 가리킵니다. 참조값이 객체가 놓인 메모리 주소 그 자체가 아닐 수도 있다는 뜻입니다.

핸들에 관한 이 설명은 JVMS 초판(1997)에서 "Sun의 현재 구현"을 설명하던 것입니다. 2판에서 "Sun의 일부 구현"으로, Oracle 인수 뒤의 판에서 "Oracle의 일부 구현"으로 바뀌었을 뿐 내용은 같습니다. 초판 당시 Sun의 JVM은 JDK 1.0·1.1의 Classic VM이었고, The Java HotSpot Performance Engine Architecture의 'Handleless Objects' 절은 이 Classic VM이 간접 핸들을 썼다고 설명합니다. 같은 절에 따르면 현재 Oracle JDK와 OpenJDK가 공통으로 쓰는 HotSpot은 핸들을 쓰지 않고 객체 참조를 객체를 직접 가리키는 포인터로 구현합니다.

메서드 호출 시의 전달 방식은 8.4.1. Formal Parameters 절에 있습니다. 인자 표현식의 '값’이 새로 만들어진 파라미터 변수를 초기화한다고 설명할 뿐입니다. 앞에서 정의한 call by reference처럼 파라미터가 호출한 쪽 변수의 별칭이 된다는 서술은 없습니다.

JLS는 메서드 호출을 실행하는 과정도 단계별로 서술합니다. 15.12.4.5. Create Frame, Synchronize, Transfer Control 절은 호출할 메서드가 정해지면 activation frame을 새로 만들고 그 안에 인자 값을 담는다고 설명합니다. Activation frame은 메서드 호출의 파라미터, 지역 변수, 반환 주소 같은 실행 상태를 담고 호출이 끝나면 사라지는 메모리 영역입니다.

호출한 쪽의 변수가 아니라 새 프레임에 새로 만들어진 파라미터 변수에 인자의 '값’을 대입한다는 서술입니다. 8.4.1절과 같은 결론입니다. 인스턴스 메서드를 호출한 대상 객체의 참조값(target reference)도 같은 방식으로 새 프레임에 담겨 this가 됩니다.

이 프레임을 가상 머신 수준에서 정의한 문서는 JVMS입니다. 2.6. Frames 절은 메서드를 호출할 때마다 새 프레임이 스레드의 JVM stack에 만들어지고, 프레임마다 자기만의 지역 변수 배열이 있다고 설명합니다.

파라미터는 이 지역 변수 배열로 전달됩니다. 2.6.1. Local Variables 절의 설명입니다.

앞의 reassign 예제에서 myTv의 참조값이 파라미터 targetTv로 복사되는 과정을 이 구조에 맞춰 따라가 보겠습니다. 그러려면 먼저 다음 개념을 알아야 합니다.

이 개념으로 reassign 호출을 그리면 다음 그림과 같습니다. reassign은 static 메서드이므로 파라미터 targetTv는 reassign 프레임의 0번 지역 변수입니다. javac가 main 프레임의 1번 지역 변수에 배정한 myTv에 담긴 참조값이 이 칸으로 복사됩니다. 파라미터가 0번부터 들어가는 것은 JVMS가 정하지만, 파라미터가 아닌 지역 변수를 몇 번 칸에 둘지는 컴파일러가 정합니다. 바이트코드 수준에서는 aload_1 명령이 이 참조값을 main 프레임의 operand stack에 올리고, invokestatic 명령이 그 값을 꺼내 새 프레임의 0번 지역 변수에 넣습니다. 두 칸은 서로 다른 프레임에 속한 별개의 저장 공간이므로 targetTv에 새 객체를 대입해도 main 프레임의 myTv는 여전히 처음의 객체를 가리킵니다.

다만 JVMS는 추상 기계를 정의할 뿐입니다. 특정 구현의 메모리 구조가 아니라 명령의 동작 규칙을 정한 모델이라는 뜻입니다. JVMS 2장의 서두는 런타임 데이터 영역의 메모리 배치를 구현자의 재량에 맡긴다고 밝힙니다. 예를 들어 JIT 컴파일러가 만든 기계어 코드는 파라미터를 CPU 레지스터에 둘 수도 있습니다. 그렇더라도 호출한 쪽의 변수와 파라미터가 별개의 변수라는 언어의 의미는 달라지지 않습니다.

일부만 읽으면 JavaScript의 함수 호출을 call by reference로 오해하기 쉬운 자료도 있습니다. David Flanagan이 쓰고 오랫동안 JavaScript의 표준적인 책으로 꼽혀온 JavaScript: The Definitive Guide 4판은 11.2절 'By Value Versus by Reference’의 요약 표에서 객체가 by reference로 복사·전달·비교된다고 정리합니다. 이 요약 표만 보면 JavaScript는 call by reference라고 설명해도 될 것처럼 보입니다.

그런데 같은 절의 동작 설명을 읽어 보면, 이 책이 말하는 by reference는 이 글의 앞부분에서 정의한 call by reference와 다른 의미입니다. '객체 값 전체가 복사되는 대신 객체를 가리키는 참조가 전달된다’는 의미로 쓴 표현이고, 파라미터를 재할당해도 호출한 쪽 변수에 반영되지 않는다는 점은 이 책도 똑같이 설명합니다.

이 설명에 이어지는 예제의 제목도 'References themselves are passed by value', 즉 참조 자체는 값으로 전달된다는 것입니다. 결국 관찰되는 동작을 설명하는 내용은 이 글과 같고, 전달되는 것을 무엇이라고 부르는지만 다릅니다.

C++에는 C에서 물려받은 포인터 파라미터(예: int*)도 있어서 둘을 구분해야 합니다. 포인터 파라미터는 C++에서도 call by value입니다. void swap(int* x, int* y)처럼 포인터를 받으면 앞의 C 예제와 똑같이 포인터 값의 복사본이 파라미터에 대입됩니다. 함수 안에서 x에 다른 주소를 대입해도 호출한 쪽 변수에는 반영되지 않습니다.

반면 int& 참조 파라미터에는 재할당할 문법 자체가 없습니다. x = y;는 참조를 다른 변수에 다시 묶는 문장이 아니라, 참조가 가리키는 객체에 값을 대입하는 문장입니다. 앞에서 정리한 구분 기준을 두 경우에 적용하면 결과가 다릅니다. 포인터 파라미터(int*)에 대입하면 호출한 쪽 변수는 그대로지만, 참조 파라미터(int&)에 대입하면 호출한 쪽 변수가 바뀝니다.

C++ 표준도 참조를 전달되는 값이 아니라 별칭으로 기술합니다. [dcl.ref]의 주석은 참조를 "a name of an object", 즉 객체의 이름으로 생각할 수 있다고 설명합니다. 같은 절 4항은 참조가 저장 공간을 필요로 하는지는 규정하지 않는다고 명시합니다.

컴파일러가 대개 참조를 주소로 구현하더라도 표준은 참조에 저장 공간이 있는지조차 정하지 않습니다.

기계 수준에서 무엇이 복사되는지를 기준으로 삼으면 call by reference인 언어는 하나도 없게 됩니다. 두 용어는 컴파일된 결과가 아니라 언어가 정의한 의미론을 구분하는 말입니다.

다만 C++ 표준이 참조 파라미터를 call by reference라고 부르지는 않습니다. 표준 문서 전체를 찾아보면 'call by value', 'call by reference', 'pass by value’라는 용어는 한 번도 나오지 않고 'passed by reference’만 네 번 나오는데, 모두 규범적인 정의가 아니라 주석이나 라이브러리 절의 설명입니다. 표준은 평가 전략에 이름을 붙이는 대신 동작으로 규정합니다. [expr.call] 6항은 각 파라미터가 대응하는 인자로 초기화된다고만 적습니다.

참조 타입 파라미터가 어떻게 초기화되는지는 참조 바인딩 규칙이 따로 정합니다. Call by value와 call by reference는 특정 언어의 표준 용어가 아니라 여러 언어의 인자 전달 방식을 비교하기 위한 프로그래밍 언어론의 용어입니다.

invokedynamic은 호출할 메서드를 실행 시점에 결정하는 바이트코드 명령입니다. invokevirtual이나 invokestatic 같은 다른 호출 명령은 호출 대상이 클래스 파일에 고정되어 있지만, invokedynamic은 호출 지점(call site)을 어떤 메서드에 연결할지를 실행 시점의 Java 코드에 위임합니다. JVM에서 동적 언어를 지원하기 위해 JSR 292로 JDK 7에 추가되었고, JDK 8의 람다 표현식 구현에도 쓰입니다.

이 연결을 담당하는 코드가 bootstrap 메서드입니다. 클래스 파일에는 invokedynamic 호출 지점마다 사용할 bootstrap 메서드가 기록됩니다. JVM은 호출 지점을 처음 실행하기 전에 bootstrap 메서드를 호출해 링크하고, bootstrap 메서드는 실제 실행할 메서드를 가리키는 CallSite를 만들어 반환합니다. 여러 스레드가 같은 호출 지점을 동시에 최초 실행하면 bootstrap 메서드가 병행 호출될 수 있지만, JVM은 그중 하나의 결과만 호출 지점에 설치합니다. 문자열 결합에서는 StringConcatFactory.makeConcatWithConstants()가 bootstrap 메서드이고, 이 메서드가 결합 코드를 만들어 CallSite에 담아 돌려줍니다.

MethodHandle은 java.lang.invoke 패키지에 있는, 실행할 대상을 가리키는 참조입니다. 메서드뿐 아니라 생성자 호출이나 필드 접근도 가리킬 수 있고, 인수와 반환 타입 정보는 MethodType 객체에 담겨 있습니다. 리플렉션의 Method와 쓰임새는 비슷하지만, 접근 권한을 MethodHandle을 만드는 시점에 한 번만 확인하고 invokeExact() 같은 메서드로 바로 호출한다는 점이 다릅니다. 또한 MethodHandles.filterArguments()`나 `MethodHandles.foldArguments() 같은 메서드로 여러 MethodHandle을 엮어 새로운 MethodHandle을 만들 수 있습니다. 뒤에서 볼 문자열 결합 전략 중 이름이 MH로 시작하는 3가지가 이 조합 기능으로 결합 코드를 구성합니다.

CallSite는 같은 패키지의 객체로, 실행할 메서드를 가리키는 MethodHandle 하나를 target이라는 속성으로 참조합니다. CallSite.getTarget() 메서드가 현재 target인 MethodHandle을 돌려줍니다. JVM은 bootstrap 메서드가 반환한 CallSite를 호출 지점에 연결해 두는데, 이를 링크라고 합니다. 링크된 뒤의 invokedynamic 실행은 그 시점의 target MethodHandle을 호출하는 것과 같습니다. MutableCallSite처럼 실행 중에 target을 다른 MethodHandle로 바꿀 수 있는 구현도 있지만, 문자열 결합에는 target이 바뀌지 않는 ConstantCallSite가 쓰입니다. 그래서 한 번 링크된 뒤에는 일반 메서드 호출처럼 동작하고 JIT 컴파일러의 인라인 최적화 대상도 됩니다.

JDK 25에서 아래의 소스를 컴파일해서 확인해 보았습니다.

javap -c StringTest 명령으로 바이트코드를 보면 StringBuilder 호출 대신 invokedynamic 명령이 나옵니다.

같은 소스를 javac --release 8 옵션으로 컴파일하면 앞 절에서 역컴파일로 보았던 것과 같은 StringBuilder 호출 코드가 나옵니다.

이 방식의 장점은 결합 전략이 컴파일된 클래스 파일이 아니라 JDK 런타임에 있다는 점입니다. 클래스 파일에는 결합할 인수 자리와 상수를 적은 recipe 문자열만 남습니다. 예를 들어 위의 str0 + str1 + "1111"은 인수 자리를 뜻하는 \u0001 두 개 뒤에 1111이 붙은 recipe가 되고, javap -v 출력의 BootstrapMethods 항목에서 확인할 수 있습니다. 그래서 한 번 컴파일한 클래스도 실행하는 JDK를 올리면 새 런타임의 결합 전략을 재컴파일 없이 적용받습니다. JDK 11로 컴파일한 클래스를 JDK 25에서 실행하면, JDK 24에서 도입된 hidden class 기반의 일반 결합 경로가 적용됩니다. 자세한 배경은 JDK 9/JEP 280: String Concatenations Will Never Be the Same에 설명되어 있습니다.

JDK 9의 StringConcatFactory에는 6가지 결합 전략이 있었고, java.lang.invoke.stringConcat 시스템 프로퍼티로 선택할 수 있었습니다. 전략 이름에서 BC는 실행 시점의 바이트코드 생성을, MH는 MethodHandle 조합을, SB는 StringBuilder 사용을, SIZED는 버퍼 초기 용량 추정을, SIZED_EXACT는 정확한 용량 계산을 뜻합니다.

기본 전략인 MH_INLINE_SIZED_EXACT는 다 채운 byte 배열로 추가 복사 없이 String을 생성하므로, 임시 객체와 복사가 가장 적습니다. StringConcatFactory.java의 generateMHInlineCopy() 메서드가 그 구현입니다. 두 참조 값을 더하는 단순한 형태에는 StringConcatHelper.java의 simpleConcat() 같은 특수 경로도 사용됩니다.

기본 전략 외의 나머지 5가지 선택 전략과 java.lang.invoke.stringConcat 프로퍼티는 JDK-8245455로 JDK 15에서 제거되었습니다. 이 글에서는 simpleConcat() 같은 특수한 형태 전용의 빠른 경로를 제외하고, 대부분의 결합이 기본으로 타는 경로를 일반 결합 경로라고 부르겠습니다. JDK 15부터 JDK 22까지의 일반 결합 경로는 MH_INLINE_SIZED_EXACT에서 이어진 inline-copy MethodHandle 방식입니다. 여러 MethodHandle을 조합해서, 정확한 최종 길이의 byte 배열을 만들고 각 인수를 중간 버퍼 없이 그 배열에 바로 복사해 넣는(inline copy) 결합 메서드를 구성합니다.

JDK 23에서는 JDK-8327247로 인수 개수가 기본 임계값 20을 넘는 결합에 StringBuilder 호출 바이트코드를 생성하는 경로가 추가되었습니다. 인수가 많은 결합에서는 MethodHandle 표현식 트리가 커져서, 극단적인 경우 C2 컴파일러가 이를 컴파일하는 데 최대 2GB의 메모리를 쓰는 문제가 있었습니다. 이 문제를 피하기 위한 변경입니다.

JDK 24에서는 JDK-8336856으로 주된 일반 결합 경로가 인수 형태(shape)별 hidden class를 생성하는 방식으로 다시 바뀌었습니다.

hidden class는 JEP 371: Hidden Classes로 JDK 15에 추가된 특수한 클래스입니다. Lookup.defineHiddenClass() 메서드로 정의하며, 클래스 이름으로 찾을 수 없고 참조가 사라지면 개별적으로 언로드될 수 있어서, 프레임워크나 JDK가 실행 시점에 만들어 내는 코드에 적합합니다. JDK 15부터는 람다 표현식의 구현 클래스도 hidden class로 만듭니다. JDK 25 구현에서 hidden class 캐시의 키가 되는 인수 형태는 동적 인수의 개수와 정규화된 타입으로 이루어진 MethodType입니다. 참조 타입은 Object로, byte와 short는 int로 정규화됩니다. 상수의 내용과 배치는 캐시 키에 포함되지 않고 호출 지점마다 별도의 String[]에 저장됩니다. 따라서 앞의 바이트코드에서 str0 + str1 + "1111"의 호출 지점은 시그니처가 (String, String) → String이지만, 캐시에서는 (Object, Object) → String 형태를 사용합니다. 반복문 안 str2 + "1111"의 호출 지점은 (Object) → String 형태를 사용하므로 두 호출 지점은 서로 다른 형태입니다. 인수 형태별 hidden class 방식은 생성한 결합 클래스를 캐시에 두고 같은 형태의 다른 호출 지점에서 재사용할 수 있습니다. 캐시는 soft reference를 사용하므로 캐시된 클래스가 회수되면 같은 형태의 클래스를 다시 만들 수도 있습니다. 깊게 중첩된 MethodHandle 트리 대신 JIT 컴파일러가 다루기 쉬운 평범한 바이트코드가 만들어지므로, 링크와 초기 구동(warmup) 비용이 줄어듭니다.

JDK 25의 StringConcatFactory는 먼저 단순 결합용 빠른 경로를 확인하고, 그 밖의 결합은 기본적으로 InlineHiddenClassStrategy로 처리합니다. 이 전략은 동적 인수가 하나인 경우 미리 구현된 전용 핸들러를 사용하고, 그 밖의 일반적인 결합에는 인수 형태별 hidden class를 사용합니다. 결합 코드는 최종 크기의 byte 배열을 채우고 그 배열로 String을 만듭니다. JDK 25의 StringConcatFactory.java에서 이를 확인할 수 있습니다.

한편 위의 바이트코드에서 보듯이 반복문 안의 invokedynamic 명령은 반복 주기마다 이미 링크된 결합 메서드를 호출하여 새로운 결과 String을 만듭니다. StringConcatFactory의 bootstrap 메서드가 매번 다시 실행되는 것은 아닙니다. 컴파일러나 런타임이 누적용 StringBuilder 하나를 반복문 밖에 만들어 주지는 않으므로, 많은 문자열을 누적하는 반복문에서 직접 StringBuilder를 쓰라는 결론은 JDK 9 이후에도 같습니다.