C++ Devirtualization 이해하기: 컴파일러가 가상 호출을 최적화하는 방법

가상 함수는 C++ 다형성의 핵심이지만, vtable 조회라는 성능 비용이 따릅니다. Devirtualization은 컴파일러가 가상 호출을 직접 함수 호출로 대체할 수 있음을 증명하여 동적 디스패치(dynamic dispatch)의 오버헤드를 제거하는 최적화 기법입니다. 단순해 보이지만, 서로 다른 컴파일러 간의 실제 구현은 놀라울 정도로 미묘하며 종종 취약합니다.

Devirtualization을 위한 두 가지 주요 경로

컴파일러는 일반적으로 가상 호출을 devirtualization할 수 있는지 판단하기 위해 두 가지 별개의 논리적 경로에 의존합니다: 인스턴스의 정확한 동적 타입을 알거나, 정적 타입이 "leaf"(더 이상 파생될 수 없음)임을 증명하는 것입니다.

1. 동적 타입 파악

가장 기본적인 사례는 객체가 동일한 스코프 내에서 인스턴스화되고 사용되는 경우입니다:

void test() {
    Apple o;
    o.f();
}

이 시나리오에서 컴파일러는 o가 Apple이라는 것을 절대적으로 확신할 수 있습니다. f()가 가상 함수라 하더라도 동적 디스패치는 불필요합니다.

하지만 로직이 복잡해질수록 컴파일러 지원은 갈립니다. 대부분의 현대적 컴파일러는 단순한 포인터 할당(예: Base *p = &d;)을 처리할 수 있지만, 조건부 로직에는 어려움을 겪습니다. 예를 들어, 포인터가 조건에 따라 할당되는 경우(Base *p = cond ? &da : &db;) GCC는 성공할 수 있지만 Clang은 실패할 수 있습니다. 만약 베이스 클래스로의 캐스팅이 조건문 내부로 이동하면, GCC의 데이터 흐름 분석조차 무너지는 경우가 많습니다.

2. Leafness의 증명

컴파일러가 특정 인스턴스를 알지는 못하지만 정적 타입(예: Derived*)을 알고 있는 경우, 프로그램 내의 다른 클래스가 해당 메서드를 오버라이드하지 않는다는 것을 증명할 수 있다면 여전히 devirtualization이 가능합니다. 이를 "leafness의 증명"이라고 합니다.

`final` 키워드

클래스나 특정 가상 메서드에 final 지정자를 사용하는 것은 이 증명을 제공하는 가장 명시적인 방법입니다. 클래스가 final로 표시되면 더 이상 자식 클래스를 가질 수 없으므로, 해당 클래스에 대한 모든 포인터는 반드시 그 정확한 타입의 객체를 가리켜야 합니다.

내부 연결(Internal Linkage) 및 익명 네임스페이스

종종 간과되지만 강력한 도구는 내부 연결입니다. 클래스가 익명 네임스페이스 내에 정의되어 있다면, 해당 번역 단위(TU) 외부에서는 이름을 지정할 수 없습니다. 결과적으로 해당 TU 외부에서는 이를 파생할 수 없습니다. 컴파일러가 현재 TU 내에서 자식 클래스가 없음을 확인하면, 해당 클래스의 가상 함수 호출을 안전하게 devirtualize할 수 있습니다.

이는 공개 베이스 클래스는 헤더에 노출되지만, 구체적인 구현은 익명 네임스페이스 내의 .cpp 파일에 숨겨지는 "Pimpl" 스타일 패턴에서 특히 유용합니다.

예외적인 사례 및 "Silly"한 증명

클래스가 leaf인 것을 증명하는 몇 가지 모호한 방법들이 있습니다:

Final Destructors: Clang은 final 소멸자를 가진 클래스는 자식 클래스를 가질 수 없다는 사실(자식은 자신만의 소멸자를 가져야 하며, 이는 부모의 것을 오버라이드하게 됨)을 기반으로 최적화합니다.
Incomplete Types: 클래스가 내부 연결을 가진 타입의 멤버를 가지고 있다면, 다른 TU는 해당 클래스의 타입을 완성할 수 없으므로 다른 곳에서 이를 파생하는 것이 불가능합니다. GCC는 현재 이를 안정적으로 감지하는 유연한 컴파일러입니다.
The Virtual Base Trick: 매우 모호한 방법으로, private 생성자를 가진 가상 베이스를 사용하는 방법이 있습니다. 자식 클래스는 가상 베이스를 생성할 수 있어야 하므로, 생성자를 private으로 만들면 상속을 효과적으로 차단하지만, 현재 어떤 현대적 컴러도 이 최적화를 구현하고 있지는 않습니다.

컴파일러 비교 매트릭스

Devirtualization 지원은 주요 툴체인마다 일관되지 않습니다. 다음 표는 다양한 기술의 효과를성을 요약합니다:

Test Case	GCC	Clang	MSVC	ICC
Trivial Dynamic Type	✓	✓	✓	✓
Cast to Base*	✓	✓
Conditional Cast	✓
Final Class	✓	✓	✓	`f`
Final Method	✓
Final Destructor		✓
Internal Linkage Class	`f`
Internal Linkage Member	`f`

(참고: f는 부분적 성공 또는 특정 메서드 실패를 나타냅니다)

Devirtualization의 취약성

이러한 기능에도 불구하고, devirtualization은 악명 높게 취약합니다. 기술적 논의에서는 몇 가지 중요한 위험을 강조합니다:

"External Function" 문제

커뮤니티 기여자들에 따르면, 동적 타입에 대한 컴파일러의 가정은 외부 함수 호출에 의해 무효화될 수 있습니다. 만약 포인터가 전역 테이블에 등록되고 외부 함수가 placement new를 사용하여 메모리 상의 객체를 덮어쓴다면, vtable은 변경됩니다. 컴파일러는 객체의 생성과 가상 호출 사이의 외부 함수 호출이 있다면, 동적 타입이 변경되었을 가능성이 있다고 가정하고 보수적으로 동작해야 합니다.

Speculative Devirtualization 및 ICF

Profile Guided Optimization (PGO)와 같은 고급 최적화는 컴파일러가 가장 가능성 높은 타입을 추측측하는 "speculative devirtualization"으로 이어질 수 있습니다. 하지만 이는 BOLT와 같은 바이너리 최적화 도구에 의해 수행되는 Identical Code Folding (ICF)과 충돌할 수 있습니다. 만약 두 개의 서로 다른 서브클래스가 동일한 함수 본문을 가지고 있다면, ICF는 이들을 하나의 주소로 병합할 수 있습니다. 만약 컴파일러가 해당 주소를 사용하여 타입을 검증한다면, 특정 타입으로 잘못 가정하여 세그멘테이션 오류(segmentation faults)를 유발할 수 있습니다.

요약

Devirtualization은 컴파일러마다 매우 일관되지 않고 사소한 코드 변경에 의해 쉽게 깨질 수 있기 때문에, 성능이 중요한 경로에서는 다음과 같은 간단한 결론을 내릴 수 있습니다: 제로 오버헤드를 보장받고 싶다면 가상 호출을 완전히 피하십시오.