HotSpot은 런타임 사용 패턴과 성능 특성을 분석 한 다음 Java 응용 프로그램이 실행 중일 때 해당 분석을 기반으로 JIT 프로세스를 최적화한다는 것은 잘 알려져 있습니다. 결과적으로 실제 성능 측정을 수행하기 전에이 분석 및 최적화 단계가 수행되도록 Java 응용 프로그램을 벤치 마크하려고 할 때주의해야합니다.배포 전의 Java HotSpot 분석?
이것은 이전에 생각 해봤 겠지만이 분석 단계 (예 : 일반적인 사용 패턴)가 어떻게 빌드 프로세스의 일부로 수행 될 수 있는지 그리고 응용 프로그램과 함께 배포 된 프로파일 링 데이터가 왜 그렇게 궁금해했습니다. 풀 스피드 JIT는 애플리케이션이 시작될 때 즉시 달성됩니다.
이것이 가능하지 않은 이유가 있거나 HotSpot 및 Java 응용 프로그램 배포의 기능이 향상 될 계획이라면 누구에게 이것이 실제로 수행되었는지 알 수 있습니까?
특히 Java 응용 프로그램과 관련된 응용 프로그램의 "일반적인 사용 패턴"은 없습니다. Windows, Linux, MacOS, Solaris 등에서 실행할 수 있습니다. 런타임 환경은 코드의 동작을 완전히 바꿀뿐만 아니라 런타임에 존재할 클래스를 결정합니다.
예를 들어 그래픽 사용자 인터페이스가있는 응용 프로그램은 Windows, Linux 또는 MacOS에서 서로 다른 AWT 구현 클래스를로드합니다. 그러나 디스플레이의 픽셀 포맷 (RGB 대 BGR, 16 비트 대 24 비트)의 단순한 특성조차도 애플리케이션이 다른 코드 경로를 취하도록 이끌 것입니다. JFC 클래스의 코드를 지속적으로 개선하여 런타임 동작을 변경하는 새로운 JRE 버전이 있으므로 사전 계산 된 프로파일 링 데이터를 쓸모 없게 만듭니다.
개발자 컴퓨터의 테스트 및 벤치마킹이 실제 프로덕션 환경에 대해 충분하다고 생각하는 것은 일반적인 실수입니다. 수십억 개의 동시 트랜잭션을 실행하거나 다른 쪽에서 RAM의 절반 만 사용하여 고객의 PC에서 실행하면 충분하지 않을 수 있습니다.
소프트웨어의 실제 동작 및 사용 패턴에 대해 프로필을 작성하고 최적화 할 수 있고 런타임에 발견 된 정확한 버전을 사용하여 다른 공급 업체의 라이브러리 경계를 최적화 할 수있는 것은 Java의 장점 중 하나입니다.
글쎄, 직감을 말하면 분석하기 위해서 코드를 더 많이 또는 덜 실행하거나 일종의 논리로 단계별로 실행해야합니다. 또한 실제로 사용자 입력을 예측할 수 없으므로 결과적으로 패턴을 갖게됩니다. – Cruncher
네, 그렇지만, 배포하기 전에 쉽게 프로파일 링 할 수있는 전형적인 사용 패턴이 항상있을 것입니다. 패턴에 대한 정보를 프로파일 링 할 수없는 이유는 무엇입니까? 일반적인 사용 패턴은 항상 적지 만 HotSpot이 실제 런타임에서 작동하는 것과 동일한 방법으로 분석하고 최적화 할 수 있습니다. –
"매우 전형적인 사용 패턴"은 무엇입니까? 프로그램의 중간에서 무작위'int' 변수를 골라 내면 코드를 살펴봄으로써 50 이하가 될지를 결정할 수 있습니까? –