TIL

Chapter 15 자바 9와 미래

• 자바 9에서 모듈이 도입
• 모듈이 성능에 큰 비중을 차지하는 건 아니기에 모듈에 집중하지는 않는다.

15.1 자바 9에서 소소하게 개선된 성능

• 코드 캐시 세그먼트화
• 콤팩트 스트링
• 새로운 스트링 연결
• C2 컴파일러 개선
• G1 새 버전

15.1.1 코드 캐시 세그먼트화

• 자바 9부터 코드 캐시 성능을 개선하고자 다음 항목별로 영역을 분리
  • 인터프리터 등의 논메서드 코드
  • 프로파일드 코드
  • 논프로파일드 코드
• 스위퍼 가동 시간이 짧아지고 풀 최적화 코드에 대한 코드 지역성이 향상된다.
• 다른 영역은 공간이 남는데 특정 영역이 꽉 찰 수 있다는 단점은 존재
• https://openjdk.org/jeps/197

15.1.2 콤팩트 스트링

• 자바에서 스트링은 항상 char[]타입으로 저장된다.
  • char는 2바이트(16비트)
  • 통계적으로 Latin-1 스트링 데이터가 많이 쓰이는데 1바이트만 필요
  • ASCII 스트링을 저장하면 남는 바이트 공간엔 0이 채워지며 실제로 필요한 공간의 2배 정도를 더 차지한다.
• 자바 9 이후 콤팩트 스트링 덕에 스트링 단위로 최적화가 가능해졌다.
  • Latin-1 캐릭터로 표기 가능한 스트링은 byte 배열로 나타낼 수 있다.
  • 기존 char 배열로 나타닐 때 0으로 채워졌던 바이트 개수만큼 절약 가능
• 자바 9부터 String 클래스의 소스 코드에 value 필드 타입이 char[]에서 byte[]로 변경되었다.
• 대용량 힙을 지닌 애플리케션에서 콤팩트 스트링 하나로 상당한 성능 효과를 기대할 수 있다.

15.1.3 새로운 스트링 연결

• 문자열을 이어붙일 때 자바 5 이래로 StringBuilder를 많이 사용해왔다.
• 자바 9부터 invokedynamic을 활용하여 생성되는 바이트코드를 줄일 수 있게 되었다.
• java -verbose 명령으로 살펴보면 상수 풀에 bootstrap 메서드가 보인다.
  • StringConcatFactory.makeConcatWithConstants()
  • 이 팩토리 메서드로 스트링 연결 레시피를 제공
• 위 기법을 응용하여 새로운 커스텀 메서드용 바이트코드 작성 등 다양한 전략을 구사할 수 있다.

15.1.4 C2 컴파일러 개선

• C2 컴파일러는 많이 성숙했기에 눈에 띄는 개선을 없을 것이다.
• 하지만 현대 CPU에 선보인 SIMD(single instruction multiple data) 확장 기능을 응용하면 성능 개선을 기대할 수 있다.
• 자바/JVM 플랫폼은 SIMD를 효과적으로 활용하기 좋다.
  • 바이트코드는 플랫폼과 무관
  • JVM은 시동 시 CPU를 탐색하므로 현재 하드웨어를 런타임에 파악 가능
  • JIT 컴파일은 코드를 동적 생성하기에 사용 가능한 모든 명령을 호스트에서 사용할 수 있다.
• 이러한 개선은 VM 인트린직으로 구현할 수 있다.
  • 인트린직 - JVM이 이미 알고 있는 고도로 튜닝된 네이티브 메서드 구현체
  • JVM은 런타임에 자신을 실행한 하드웨어 따라 사용 가능한 기능을 목록화 가능
  • 인트린직은 가볍고 강력하고 유연하다.
• 핫스팟은 이미 다음과 같은 x86 SIMD 명령어를 지원
  • 자바 코드의 자동 백터화
  • 순차 코드에서 SIMD 코드를 얻기 위해 C2에서 슈퍼워드 최적화
  • 배열 복사/적재/비교 등의 JVM SIMD 인트린직
• 자바 9에선 SIMD의 장점과 연관된 프로세서 특징을 잘 활용하고자 기존 인트린직을 개선하거나 새로운 인트린직을 탑재했다.
  • 마스킹된 백터 포스트 루프
  • 슈퍼워드 루프 펼치기 분석
  • 멀티비저닝으로 범위 체크 제거
  • 배정도 제곱근 백터화 지원
  • 병렬 스트림의 백터화 개선
  • 슈퍼워드를 개선하여 인텔 AVX CPU상에서 백터 조건부 이동 지원
• 일반적으로 인트린직은 범용 기술이 아닌 특정 해결책이라 봐야 한다.
  • 여러 아키텍처를 고루 지원해야 하므로 개발/유지보수 비용이 크다.

15.1.5 G1 새 버전

• 자바 9부터 G1이 디폴트 가비지 수집기가 되었다.
  • G1은 중단 시간을 쉽게 튜닝하고 더 효과적으로 제어하는 특성을 지님

15.2 자바 10과 그 이후 버전

15.2.1 새로운 릴리즈 절차

• 자바 10 이전에는 특성 위주로 새 버전이 나왔다.
  • 특정 릴리즈를 목표로 주요 변경 사항 구현
  • 새로운 특성이 준비될 때까지 릴리즈를 미루기도 함
  • 때문에 자바 9 릴리즈도 상당이 지연되었다.
  • 릴리즈 개발 후 풀 테스트까지 오래 거릴는 탓에 소소한 특성이 주요 특성에 가려지는 경우도 많았다.
  • 릴리즈가 미뤄지며 소스 코드 저장소는 방치되기 일쑤
• 자바 10부터는 정확한 시기에 릴리즈되는 모델로 개편되었다.
  • 앞으로 새 버전이 6개월마다 릴리즈
  • 이른바 특성 릴리즈(feature release)
• 오라클은 일부 특성 릴리즈에 대해 장기지원(LTS, long-term support)를 제공한다.

15.2.2 자바 10

• JVM 특성 및 개선 사항은 자바 개선 프로세스를 통해 관리
• 자바 10 주요 특성의 일부
  • 286: 지역 변수 타입 추론
    • var
  • 296: JDK 포레스트를 단일 리파지터리로 통합
  • 304: 가비지 수집기 인터페이스
  • 307: G1에서 풀 병렬 GC 구현
    • 풀 GC 발생시 성능 병목 문제 해결
    • 자바 9에선 싱글 스레드인 마크-스위프-컴팩트 알고리즘 사용
    • JEP 307에선 이 알고리즘을 병렬화
  • 310: 애플리케이션 클래스 데이터 공유
    • 자바 5의 클래스 데이터 공유 특성 확장
    • JVM이 일습의 클래스를 기록해 공유 아카이브 파일 하나로 처리하여 메모리에 매핑
    • 다음에 실행할 때 시간 절약 가능
    • 여러 JVM이 같은 호스트에서 실행할 때 전체 메모리 사용량 감소
  • 312: 스레드 로컬 핸드쉐이크
    • 애플리케이션 스레드에 콜백을 실행하여 전역 VM 세이브포인트를 수행하지 않게 하여 VM 성능 개선
    • 스레드 전체가 아닌 개별 스레드 단위로 멈추게 하자
    • 샘플링 편향을 줄일 수 있다.
    • 바이어스 취소 시 바이어스 락킹 작업이 향상됨
    • JVM에서 일부 메모리 베리어를 제거 가능

15.3 자바 9 Unsafe 그 너머

• sun.misc.Unsafe는 자바 표준 API는 아니지만 자바 8부터 사실상 표준이 되었다.
• Unsafe에는 다양한 안전 기능이 버무러져 있다.
  • CAS 하드웨어에 엑세스하는 메서드는 완전 안전하지만 비표준
  • 다른 메서드는 전혀 안전하지 않고 포인터 연산과 동등한 코드가 포함되어 있다.
• 오라클은 ‘전혀 안전하지 않은’ 기능을 다른 방법으로는 얻을 수 없어 이런 기능을 ‘핵심 내부 API’라 부른다.
• sun.misc.Unsafe 기능을 대체할 기술이 없다면 주요 프레임워크와 라이브러리는 더 이상 작동하지 않을 것이다.
  • 요즘 환경에서 자바 생태계의 모든 애플리케이션이 그 대상이 될 것
• 자바 9에 —illegal-access 스위치로 이 API에 대한 런타임 엑세스를 조정할 수 있다.
  • 자바 9 출시 전에 대안을 만들지 못했다.

15.3.1 자바 9의 VarHandle

• 메서드 핸들(11장)은 메서드 레퍼런스를 직접 조작할 수 있지만 필드까지 지원하지는 않았다.
  • 게터/세터 엑세스만 가능
• 자바 9부터 메서드 핸들은 가변 핸들까지 포괄하여 필드에 접근할 수 있게 되었다.

• AtomicInteger를 가변 핸들로 구현하는 예제

    public class AtomicIntegerWithVarHandles extends Number {
      
        private volatile int value = 0;
        private static final VarHandle V;
      
        static {
            try {
                MethodHandles.Lookup l = MethodHandles.lookup();
                V = l.FindVarHandle(AtomicIntegerWithVarHandles.class, "value", int.class);
            } catch (ReflectiveOperationException e) {
                throw new Error(e);
            }
        }
      
        public final int getAndSet(int newValue) {
            int v;
            do {
                v = (int)V.getVolatile(this)
            } while (!V.compareAndSet(this, v, newValue));
            return v;
        }
    // ...
    }
  

15.4 발할라 프로젝트와 값 타입

• 발할라 프로젝트의 목표
  • JVM 메모리 레이아웃을 최신 하드웨어 비용 모델에 맞게 조정
  • 제네릭스가 기본형, 값, void까지 포함하도록 모든 타입에 추상화
  • 기존 라이브러리, 특히 JDK가 이러한 특성을 최대한 활용하도록 호환성을 유지하며 진화하도록 한다.
• JVM에서 값 타입의 사용 가능성을 모색하는 것에 중점
• 9 버전 이전까지 자바에서 값 타입은 기본형과 참조형 두 가지뿐
  • 자바는 구조체가 없기에 복합 자료형은 오직 레퍼런스를 통해서만 엑세스 가능
  • ex) 기본형 배열이 아닌 객체 배열은 레퍼런스의 배열이기에 원소를 가져오려면 우회 경로를 거쳐야 하고 간접화가 불가피하며 원소마다 캐시 미스가 일어날 수도 있다.
• JVM에서 값 타입을 구현할 수 있다면 타입 객체를 메모리처럼 배치할 수 있어 훨씬 효율적일 것이다.
• 하지만 자바 5부터 제네릭이 도입되면서 난관이 생겼다.
  • 자바 제네릭스는 Object 서브 타입인 참조형에만 적용된다.
  • 값 타입은 반드시 제네릭스를 개선한 형태에서 타입 매개변수 값으로 유효하다는 전제하에 설계해야 한다.

15.5 그랄과 트러플

• 핫스팟 내장 C2 컴파일러는 성공적이었지만 최근 수년간 이렇다할 개선 사항이 없었다.
  • C2 컴파일러는 C++로 작성되어 있어 언제라도 VM을 멎게 할 위험성이 있다. (수동으로 직접 메모리를 관리하는 C++)
• 대체품으로 그랄과 트러플이 대두되고 있다.
  • 그랄 - 특수한 JIT 컴파일러
  • 트러플 - JVM 런타임에 호스팅된 언어에 대한 인터프리터 생성기
• 그랄은 JVM용 JIT 컴파일러를 자바 언어로 개발하는 접근법을 사용
  • 자바르 자바로 접근하는 방식은 단순함, 메모리 보안 등 여러 면에서 좋다.
  • 커스텀 인트린직 또는 최적화 패스 개발 등 자신 애플리케이션에 맞게 수정 가능한 유연성도 장점이다.
• 트러플은 JVM 기반 언어 전용 인터프리터를 개발하는 프레임워크
  • 입력 언어에 대한 고성능 JIT 컴파일러를 인터프리터에서 자동 생성하는 기능
  • 제이루비, 제이썬, 내시혼 등 JVM 기반 언어 구현체는 런타임에 바이트코드를 생성하는데 트러플은 이 방식의 대안

15.6 바이트코드의 향후 발전 방향

• VM에서 가장 큰 변화는 invokedynamic 명령어의 등장
  • 이를 활용해 플랫폼을 더 유연하게 만들려는 시도가 많아질 것
• 궁극적 목표는 invokedynamic을 호출하더라도 invokevirtual처럼 JIT 컴파일하기 좋고 성능도 좋게 나오도록 하는 것이다.

15.7 동시성의 항후 발전 방향

• 당초 자바 스레딩 모델은 모든 스레드를 개발자가 관리하고 가변 상태는 락으로 보호해야 한다.
• 나중에 등장한 자바 모델은 더 고수준의 개발자의 손이 덜 가고 안전한, 사실상 런타임이 동시성을 관리하는 방향으로 진화
• 룸 프로젝트
  • 동시성을 더 저수준에서 지원하는 방안
  • 코어 자바 스레드의 문제는 모든 스레드가 스택을 달고 다녀 비용도 많이 들고 확장할 수도 없다.
    • 스레드가 10000개면 수 기가바이트의 메모리를 써야 한다.
  • OS가 직접 스케줄링 할 수 없는 실행 유닛은 오버헤드가 낫고 이는 고루틴과 같은 저수준 협력 체제와 조화를 이룬다.
  • 자바 7부터 등장한 포크/조인 API의 재귀 분해, 작업 훔쳐오기 개념이 핵심