자바에서는 모든 것이 객체다. 단, int와 같은 프리미티브는 예외다. 그런데 이 작은 예외가 몇 년에 걸쳐 복잡해지면서 결과적으로 자바 언어에 큰 영향을 미쳤다. 얼핏 사소해 보이는 이 설계상의 결정이 컬렉션, 제네릭과 같은 핵심 영역에서 문제를 일으키고, 특정 성능 최적화에서 발목을 잡는 요소가 된다. 자바 언어 리팩터인 프로젝트 발할라(Valhalla)는 이 문제를 해결하는 것을 목표로 한다. 발할라 프로젝트 리드인 브라이언 고츠는 발할라가 “
”이라고 말했다.
프로젝트 발할라는 자바의 시작 시점부터 플랫폼에 스며든 기술 부채를 해결하고자 하는 원대한 리팩터라고 할 수 있다. 이러한 발전은 자바가 고전적 언어에 그치지 않고 여전히 프로그래밍 언어 설계의 최전선에 있음을 입증한다. 프로젝트 발할라의 주요 기술적 구성요소와 발할라가 자바의 미래에 중요한 이유를 알아보자.
ⓒ Getty Images Bank
자바의 성능 문제
자바가 90년대에 처음 등장할 당시에는 모든 사용자 생성 형식은 클래스라고 결정됐고 소수의 프리미티브 형식만 특수한 경우로 취급됐다. 이는 포인터 기반 클래스 구조로 처리되는 것이 아니라 운영체제 형식에 직접 매핑됐다. 프리미티브 형식은 int, byte, short, long, float, double, boolean, char까지 총 8개다.
객체의 참조 오버헤드가 없으면 수치 연산의 성능이 향상되므로 이러한 변수를 운영체제에 매핑하는 방식은 성능에 유리하게 작용했다. 또한 모든 데이터는 프로그램에서 궁극적으로 이 8개 프리미티브 형식 중 하나로 해석된다. 또 다른 종류의 구조는 배열이다. 프리미티브, 클래스, 배열이 자바의 광범위한 표현력을 구성하는 요소들이다.
그러나 프리미티브는 클래스 및 배열과는 전혀 다른 범주에 속한다. 프로그래머는 직관적으로 그 차이에 대처하도록 배웠다. 예를 들어 프리미티브는 값에 의한 전달(pass-by-value)인 반면 객체는 참조에 의한 전달(pass-by-reference)이다. 그 이유를 보려면 깊게 들어가야 한다. 결국은 동일성의 문제다. 프리미티브 값은 대체 가능하다고 말할 수 있다. int x = 4는 어느 곳에 나오든 정수 4다. equals()와 ==에서 그 차이를 볼 수 있다. 전자는 객체의 값 동등성(equivalence)을 테스트하고, 후자는 동일성(identity)을 테스트한다. 두 참조가 동일한 메모리 공간을 공유한다면 ==를 만족하고, 이는 둘이 동일한 객체임을 의미한다. 4로 설정된 모든 int 역시 ==를 만족하지만 int는 .equals()을 지원하지 않는다.
자바 가상 머신(JVM)은 프리미티브 처리 방법을 활용해서 프리미티브를 저장, 추출하고 프리미티브에 대해 작업을 수행하는 방식을 최적화할 수 있다. 특히 플랫폼에서 변수가 바뀌지 않는다고 판단하는 경우(즉, 상수이거나 불변성인 경우) 그 변수는 최적화할 수 있는 대상이 된다
반면 객체는 동일성이 있으므로 이러한 종류의 최적화에 저항한다. 객체는 클래스의 인스턴스로서 프리미티브일 수도 있고 다른 클래스일 수도 있는 데이터를 저장한다. 객체 자체는 포인터 핸들로 처리된다. 이렇게 해서 참조의 네트워크, 즉 객체 그래프가 형성된다. 값이 바뀔 때마다(또는 바뀌었을 가능성만 있는 경우에도) JVM은 참조를 위해 객체의 최종적인 레코드를 유지해야 한다. 객체 참조의 필요성은 일부 성능 최적화를 가로막는 장벽이다.
성능 측면의 난관은 여기에 그치지 않는다. 참조 버킷이라는 객체의 특성은 객체가 매우 부풀려진 방식으로 메모리에 존재함을 의미한다. 여기서 ‘부풀려진’이라는 표현은 JVM이 메모리 사용량을 최소화하기 위해 객체를 압축할 수 없다는 점을 묘사하기 위해 필자 개인적으로 사용하는 용어다. 한 객체에 구성의 일부로 다른 객체에 대한 참조가 있는 경우 JVM은 이 포인터 관계를 유지해야 한다. (잘 만들어진 최적화는 중첩된 참조가 특정 엔터티에 대한 유일한 핸들임을 확인하는 데 도움이 될 수도 있음)
고츠는
에서 포인트 배열을 사용해 참조의 조밀하지 않은 특성을 묘사한다. 우리는 클래스를 사용할 수 있다. 예를 들어 이름과 지리적 위치 필드가 있는 Landmark라는 클래스가 있다고 가정하자. 이는 다음과 같은 메모리 구조를 암시한다.
그림 1. 자바 객체의 ‘부풀려진’ 메모리 사용량 ⓒ Infoworld
우리가 달성하고자 하는 목표는 그림 2와 같이 적절할 때 객체를 저장하는 기능이다.
그림 2. 메모리의 조밀한 객체 ⓒ Infoworld
이것이 초기 설계상의 결정에 의해 자바 플랫폼에 들어가게 된 성능 문제의 전반적인 개요다. 이제 이러한 의사 결정이 세 가지 주요 영역에서 어떻게 성능에 영향을 미치는지 생각해 보자.
문제 1 : 메서드 호출과 값에 의한 전달
메모리에서 객체의 기본 구조는 메모리와 캐싱, 두 가지 모두에 비효율적이다. 또한 메서드 호출 규약에서 이득을 얻을 기회가 있다. 값에 의한 호출 인수를 클래스 구문으로 (적절한 경우) 메서드에 전달할 수 있으면 상당한 성능 혜택을 얻을 수 있다.
문제 2 : 박스와 오토박싱
비효율성 외에, primitive와 class의 구분은 언어 수준의 어려움을 일으킨다. Integer 및 Long과 같은 프리미티브 “박스”를(오토박싱과 함께) 만드는 것은 이 구분에 의해 발생하는 문제를 완화할 수 있는 방법이다. 그러나 문제를 실제로 해결하는 것은 아니고 개발자와 머신에 모두 일정한 오버헤드도 유발한다. 개발자는 int와 Integer, ArrayList<Integer>, int[], Integer[]의 차이, 그리고 ArrayList<int>의 부재에 대해 알고 유의해야 하고, 머신은 이 둘을 상호 변환해야 한다.
어떤 면에서 박싱은 두 가지 영역의 가장 좋지 않는 부분을 제공한다. 이러한 엔터티의 근본적인 작동 방식을 알아보기 어렵게 하는 것은 클래스 구문의 강력함과 프리미티브 성능, 두 가지 모두를 더 멀어지게 하는 결과를 초래한다.
문제 3 : 제네릭과 스트림
이러한 모든 고려 사항은 제네릭에서 정점에 이른다. 제네릭의 목적은 기능 전반의 일반화를 쉽게, 더 명시적으로 하는 데 있지만 이 비객체 변수(프리미티브)의 까다로운 존재가 제네릭을 망친다. <int>는 존재하지 않는다. int가 클래스가 아니기 때문에 존재할 수가 없고, Object의 자손이 아니다.
이 문제는 제네릭 라이브러리 함수가 가진 이상이 IntStream 및 기타 비제네릭 변형을 제공함으로써 int 대 Integer, long 대 Long과 같은 현실에 대처해야 하는 컬렉션 및 스트림과 같은 라이브러리에 그대로 나타난다.
발할라의 해법 : 값 클래스와 프리미티브 형식
프로젝트 발할라는 뿌리에서 문제 해결을 모색한다. 첫 번째이며 가장 근본적인 개념은 값 클래스다. 핵심 개념은 메서드, 제네릭 실행 기능과 같은 클래스의 모든 장점을 갖지만 동일성은 없는 클래스를 정의할 수 있다는 것이다. 실무 관점에서 이 말의 의미는 클래스는 변경할 수 없고 레이아웃 다형성을 가질 수 없다는 것이다(슈퍼클래스는 추상화 속성을 통해 서브클래스에 대해 동작이 가능함).
값 클래스는 클래스 구문과 동작의 이러한 이점을 그대로 이용하면서 우리가 추구하는 성능 특성을 얻는 명확하고 결정적인 방법을 제공한다. 즉, 라이브러리 빌더도 이를 사용함으로써 API 설계를 개선할 수 있다.
여기서 한 걸음 더 나간 것이 더 극단적인 값 클래스라고 할 수 있는 프리미티브 클래스다. 기본적으로 프리미티브 클래스는 실제 프리미티브 변수를 감싸는 얇은 래퍼지만 클래스 메서드가 있다. 간소화된 맞춤형 프리미티브 박스와 같다. 개선된 부분은 박싱 시스템을 더 명시적으로, 더 확장 가능하게 한다는 점이다. 또한 프리미티브 클래스로 래핑된 프리미티브 값은 프리미티브의 성능 특성을 그대로 보존한다(내부적인 박싱과 언박싱이 없음). 따라서 클래스를 사용할 수 있는 모든 곳(예를 들어 Object[] 배열)에서 프리미티브 클래스를 사용할 수 있다. 프리미티브 형식은 null이 될 수 없다(null로 설정할 수 없음).
대체로 프로젝트 발할라는 프리미티브와 사용자 정의 형식을 서로 더 가까이 근접시킨다고 할 수 있다. 이는 개발자에게 순수 프리미티브와 객체 사이의 스펙트럼에서 더 많은 옵션을 제공하고 타협을 명확하게 드러나게 한다. 또한 전반적으로 이러한 작업의 일관성을 높여준다. 특히 새로운 프리미티브 시스템은 프리미티브와 객체의 작동 방식, 박싱되는 방식, 새 항목을 추가하는 방식을 매끄럽게 다듬는다.
자바의 구문은 어떻게 바뀌는가
발할라에는 지금까지 여러 구문이 제안됐지만 현재 프로젝트의 형식과 방향은 명확하다. value와 primitive, 두 가지 새로운 키워드는 class 키워드를 수정한다. value class 구문으로 선언되는 클래스는 동일성을 포기하며, 그 과정에서 성능 개선을 얻는다. 가변성과 다형성 제약 외에 우리가 보통 클래스에서 기대하는 대부분의 사항이 그대로 적용되며 이러한 클래스는 제네릭 코드에 완전히 참가할 수 있다(예를 들어 object[] 또는 ArrayList<T>). 값 클래스의 기본값은 null이다.
primitive class 구문은 전통적인 객체에서 전통적인 프리미티브로 한 걸음 더 나아가는 클래스를 생성한다. 이러한 클래스의 기본값은 필드의 기반 값(int는 0, double은 0.0 등)으로 설정되며 null이 될 수 없다. 프리미티브 클래스는 최적화에서 가장 많이 얻고 기능 측면에서 가장 많이 희생한다. 프리미티브 클래스는
이 없다. 프리미티브 클래스는 궁극적으로 플랫폼의 모든 프리미티브를 모델링하는 데 사용되는데, 이는 사용자 및 라이브러리 정의 프리미티브 추가가 내장 요소와 동일한 시스템에 참여하게 된다는 것을 의미한다.
IdentityObject와 ValueObject
IdentityObject와 ValueObject는 프로젝트 발할라에 도입되는 두 개의 새로운 인터페이스다. 다루는 클래스의 종류를 런타임에 판단할 수 있게 해준다.
숙련된 자바 개발자 관점에서 가장 급진적인 구문 변화는 .ref 멤버의 추가일 것이다. 모든 형식에 이제 V.ref() 필드가 있다. 이 필드는 프리미티브의 박스처럼 동작하므로 int.ref는 Integer로 int를 래핑하는 것과 비슷하다. 일반 클래스는 .ref를 자신의 참조로 해석한다. 이것이 전체적으로 미치는 영향은 종류에 관계없이 변수에 대한 참조를 요청하는 일관적인 방법을 만든다는 것이다. 또한 모든 자바 배열이 “공변성을 갖도록(covariant)” 하는 효과도 있다. 즉, 모두 Object[]로부터 내려오는 자손이다. 따라서 이제 int[]는 Object[]의 자손이며 호출되는 모든 곳에서 사용 가능하다.
결론
값 클래스와 프리미티브 클래스는 자바와 그 생태계에 큰 영향을 미칠 것이다. 현재 로드맵은 값 클래스를 먼저 채택하고 이후 프리미티브 클래스가 도입되는 것이다. 다음은 새 프리미티브 클래스를 사용하기 위한 기존 프리미티브 박스 클래스(Integer 등)의 마이그레이션이다. 이러한 기능이 구현되면 다음 기능인 범용 제네릭(universal generics)은 프리미티브 클래스를 제네릭과 함께 바로 사용할 수 있도록 해서 API 재사용에 따르는 많은 복잡성을 완화하게 된다. 마지막으로, 특수 제네릭(T extends Foo의 모든 표현 기능을 허용)이 프리미티브 클래스와 통합된다.
프로젝트 발할라와 이를 구성하는 여러 프로젝트는 아직 설계 단계에 있지만 목표에 근접해지고 있으며 프로젝트를 중심으로 한 활동을 감안하면 값 클래스가 JDK 프리뷰에 적용될 시점도 멀지 않은 것으로 보인다.
이 같은 모든 흥미로운 기술적 작업 뒤에는 자바의 지속적인 생명력이 있다. 플랫폼을 근본적으로 발전시킬 수 있는 부분을 파악하기 위한 프로세스를 수행할 의지와 역량이 있다는 것은 곧 자바의 관련성을 유지하고자 하는 진실된 노력이 있다는 증거다. 프로젝트 룸(Loom)은 자바의 미래에 대한 낙관적 시각에 힘을 싣는 또 다른 과업이다.
editor@itworld.co.kr