Go의 컴파일러는 1.18 버전에서 도입된 제네릭 컴파일 시 GCshape 스텐실링이라는 기술을 사용합니다. 역사적으로 언어들은 완전한 모노모르피제이션—각 타입 인스턴스에 대해 별도의 기계 코드를 생성하여 바이너리 부풀림을 초래하거나—또는 박싱—런타임 오버헤드와 할당 비용을 감수하고 타입을 지우는 방식으로 제네릭을 구현했습니다. Go가 직면했던 문제는 실행 속도를 완전히 희생하지 않으면서 바이너리 크기가 중요한 고성능 시스템 프로그래밍을 지원하는 것이었습니다.
해결책은 구체적인 타입을 GC shape에 따라 그룹화하는 것으로, 이는 타입의 크기와 포인터 비트맵(타입 내 포인터의 패턴)에 의해 정의됩니다. 컴파일러는 동일한 GC shape를 공유하는 모든 타입에 대해 단일 함수 인스턴스를 생성하고, 타입 메타데이터를 포함하는 런타임 사전을 암묵적 매개변수로 전달합니다.
// *int와 *string는 동일한 GC shape(단일 포인터)를 가지고 있기 때문에 동일한 인스턴스를 공유합니다. func Identity[T any](x T) T { return x } func main() { Identity((*int)(nil)) // 인스턴스 #1 사용 Identity((*string)(nil)) // 인스턴스 #1 사용 (동일한 형태) Identity(42) // 인스턴스 #2 사용 (스칼라, 포인터 없음) }
우리 팀은 제네릭 미들웨어 핸들러 Handler[T Event]를 사용하여 고처리량 이벤트 처리 파이프라인을 구축하고 있었습니다. 우리는 낮은 지연 시간과 컨테이너화된 배포를 위한 합리적인 바이너리 크기를 유지하면서 50개의 별도 이벤트 타입을 처리해야 했습니다.
첫 번째 접근 방식은 런타임 타입 스위치에 의존하여 타입 어서션을 사용하는 **interface{}**를 사용했습니다. 이것은 유연성을 제공했으며 이전 Go 버전에서 작동했지만, 각 이벤트가 인터페이스로 래핑될 때마다 힙 할당이 필요하여 상당한 할당 오버헤드를 초래했습니다. 또한 컴파일 타임 타입 안전성을 제거하여 타입이 불일치할 때 운영 환경에서 패닉을 초래했습니다.
두 번째 접근 방식은 타사 도구를 사용한 go generate를 통해 컴파일 타임 코드 생성을 포함하여 HandlerClickEvent, HandlerPurchaseEvent 등을 생성했습니다. 이는 런타임 오버헤드 없이 최적의 성능을 제공했지만, 50개의 이벤트 타입을 지원할 때 40MB만큼 바이너리 크기가 늘어나고 생성기 템플릿을 업데이트 할 때 유지 보수가 지옥이 되었습니다.
우리는 세 번째 접근 방식인 네이티브 Go 제네릭을 GC 형상에 주의 깊게 사용하기로 결정했습니다. 우리는 이벤트 타입이 구조체에 대한 포인터(균일한 GC shape)임을 보장하여 컴파일러가 인스턴스를 재사용할 수 있게 했습니다. 메서드 디스패치를 위한 사전 조회의 약간의 오버헤드를 감수하는 대신 바이너리 크기가 단 2MB만 증가하는 결과를 얻었습니다. 결과적으로 interface{}와 비교할 때 15%의 지연 시간 감소와 전체 코드 생성에 비해 관리 가능한 바이너리 크기를 달성했습니다.
런타임 사전이 공유 제네릭 인스턴스에 타입별 정보를 어떻게 제공하는가?
사전은 타입 설명자(_type), 메서드 테이블(itab), 그리고 GC 메타데이터에 대한 포인터를 포함하는 구조체입니다. 컴파일러가 func Print[T any](x T)와 같은 제네릭 함수에 대한 코드를 생성할 때 사전을 암묵적 첫 번째 인수로 전달합니다. 메서드 x.String()을 호출하기 위해 생성된 코드는 직접 호출을 컴파일하는 것이 아니라 사전에서 메서드 포인터를 조회하여 T=bytes.Buffer와 T=strings.Builder와 같은 서로 다른 메서드 구현을 처리할 수 있습니다.
어떤 두 개의 서로 다른 포인터 타입이 별도의 요소 타입이 필요한 반면 제네릭 인스턴스를 공유할 수 있는 이유는 무엇인가?
Go는 타입을 GCshape에 따라 분류하는데, 이는 가비지 수거기와 할당자와 관련된 메모리 레이아웃만을 고려합니다. *int와 *string은 모두 포인터를 포함하는 단일 머신 워드로 구성되어 동일한 shape 클래스로 분류됩니다. 반면에 int는 포인터가 없고 특정 크기로 정렬되며, string은 포인터와 길이를 포함하는 두 개의 워드 구조체입니다. 메모리 레이아웃이 다르기 때문에 적절한 가비지 수거 및 메모리 주소 지정을 처리하기 위해 별도의 생성된 코드 경로가 필요합니다.
제네릭 제약 조건에서 값 수신자와 포인터 수신자를 사용하는 성능의 함의는 무엇인가?
제네릭 함수가 유형 매개변수 T에서 메서드를 호출할 때, 컴파일러는 가능한 모든 T에 대해 작동하는 코드를 생성해야 합니다. 만약 제약 조건이 값 수신자 func (T) Method()를 요구하지만 구체적 유형이 크면, 컴파일러는 딕셔너리를 전달하고 인라인을 방지하는 간접 호출을 수행해야 할 수 있습니다. 포인터 수신자 func (*T) Method()를 사용하면 GC shape를 더 자주 공유하게 되어 더 나은 최적화를 가능하게 하며, 컴파일 타임에 구체적 유형이 특정 인스턴스화 컨텍스트에서 알려져 있을 때 호출을 더 쉽게 비가상화할 수 있습니다.