Value Classes의 성능 향상은 여전히 컴파일러의 지원이 필요하다
Value Classes Still Need Compiler Sympathy
JDK 28에 통합된 JEP 401은 value class를 미리보기 기능으로 제공하며, 이는 JVM의 최적화 기회를 확장합니다. 그러나 value class가 항상 성능을 향상시키는 것은 아닙니다. 이 글은 JVM이 현재 어떤 표현을 선택하는지, 그리고 어떤 상황에서 성능 저하가 발생하는지 세 가지 예제를 통해 설명합니다. 불변성 덕분에 플래트닝이 가능하지만, 가변 필드는 원자적 업데이트를 위해 참조 표현을 사용해야 합니다. 또한 identity를 제거하면 할당이 사라질 수 있지만, 타입 소거로 인해 메가모픽 호출에서는 다시 할당이 발생할 수 있습니다. C2 컴파일러의 한계와 이를 극복하기 위한 소스 레벨 수정 방법도 다룹니다.
value class는 JVM에 더 많은 의미 정보와 자유를 주는데, 어떻게 그들을 사용하는 것이 프로그램을 느리게 만들 수 있을까요?
HN 토론
45- DarkNova6
좋은 기술 개요이고, 결론의 마지막 부분에 있는 감정에 전적으로 동의합니다:
```
값 클래스를 선언하는 것은 무엇보다도 의미론적 결정입니다. 그것은 동료 프로그래머에게 그 인스턴스가 전적으로 상태에 의해 정의되며 정체성이 필요하지 않다는 것을 알려줍니다. 그 더 명확한 모델 자체가 가치가 있습니다! JVM이 그러한 값의 표현을 최적화할 수 있는 추가적인 자유는 환영할 만한 보너스입니다.
```
많은 개발자들이 "값이 가면 빗자루가 간다"고 생각하는 것 같지만, 진실은 훨씬 더 미묘하며 "성능"에 대해 생각하는 것이 아니라 기본 데이터의 본질에 대해 생각해야 합니다. 적어도 이것은 핵심 DDD 교훈을 언어에 직접 통합합니다. 정확히 이런 이유로 찢김이 기본적으로 켜져 있지 않은 것이 기쁩니다.
Java는 항상 라이브러리를 쉽게 사용할 수 있도록 만드는 데 중점을 둔 언어였으며, 라이브러리 작성자와 강력한 캡슐화에 많은 신뢰를 두었습니다. 이제 전문가들은 JVM에서 훨씬 더 많은 성능을 얻을 수 있는 반면, 더 겸손한 프로그래머들은 예상하지 못할 버그를 만드는 것을 피할 수 있습니다.
- aatd86
물론 그렇습니다, 언어에 관계없이 말이죠. 예를 들어 문자열 인터닝과 같은 것들이 있는 이유입니다. :)
- ferrule
여기서 무거운 작업을 하는 것은 이스케이프 분석입니다. 그것이 완전히 신뢰할 수 있을 때까지 여전히 할당을 추측하고 있는 것입니다.
- pan_lid
JVM 이스케이프 분석은 항상 성공과 실패가 엇갈렸습니다. 더 예측 가능해지는 것을 보니 좋네요.
- dist-epoch
생성 이후로 Java의 홍보는 "값/참조 클래스와 같은 저수준의 것에 대해 걱정하지 마세요. 충분히 똑똑한 컴파일러가 코드와 런타임 프로파일링을 기반으로 최상의 옵션을 자동으로 선택할 것입니다"였습니다.
무엇이 바뀌었기에, 갑자기 그들이 명시적으로 배제했던 C++ 기능을 채택하는 것일까요?