jit 이 기계어 변환해주기전에 자바 VM 으로 인터프리팅되는 구간이 소위말하는 웜업이잖아
자바 VM 개 무겁다 JIT 없었으면 망했을듯
컴파일 시간에 CDS 까지 같이 같이 구우면 안됨?
------------
ai 에 물어봄
JVM이 같아도 JAR 안에 CDS를 넣지 못하는 이유
1. JVM 실행 옵션(-Xmx, GC 종류)에 따라 내부 데이터가 바뀝니다
같은 컴퓨터, 완전히 같은 JVM 버전을 쓰더라도 애플리케이션을 켤 때 주는 옵션에 따라 CDS 데이터의 형태가 달라집니다.
- 힙 메모리 크기: -Xmx2G로 켤 때와 -Xmx4G로 켤 때, JVM 내부의 메모리 주소(Compressed Oops) 정렬 방식이 바뀝니다.
- 가비지 컬렉터(GC): G1GC를 쓰느냐, ZGC를 쓰느냐에 따라 메모리 배치 구조가 다릅니다. [1]
JAR 파일은 한번 빌드되면 고정되지만, 실행 옵션은 운영 서버 상황에 따라 언제든 바뀔 수 있습니다. 만약 빌드할 때의 옵션과 실행할 때의 옵션이 다르면 JVM은 JAR 안의 CDS 데이터를 읽지 못하고 에러를 내거나 무시해 버립니다.
2. 클래스패스(Classpath) 순서가 1비트만 바뀌어도 무효화됩니다
자바는 보안과 안정성을 위해 CDS 아카이브를 만들 당시의 클래스패스 목록과 순서를 내부적으로 기록해 둡니다.
너 벤치마트 하는법 모르는구나 모든 성능 벤치마크는 최적화 옵션 모두 켜고 컴파일하고 워밍업 후 성능을 비교하는게 기본이다 워밍업 오버헤드는 별도로 비교하고
이건 VM이 아니라 C C++ Go Rust 같은 컴파일 언어도 동일하게 비교한다 컴파일된 바이너리도 워밍업 필요해
그건 그래 원래 워밍업하고 비교하는거야 근데 워밍업 ㅈㄴ 귀찮음
근데 배포할때 워밍업 있다는건 현실임 ㅋ
벤치마크 워밍업하고 여러번 실행해서 평균값 적는거잖음 ㅇㅇ
워밍업 있다는게 아니라 워밍업 오버헤드를 감당해야 된다겠지 모든 오버헤드가 워밍업인건 아니야
@ㅇㅇ(211.234) 계속 물어보니까 이런게 있네 워밍업시간 꽤 줄어들듯 근데 도커환경이구나 요즘 자바쓰면서 도커안쓰는곳이 있나? 싶지만 "그럼 빌드할 때 실행 환경용 도커 이미지까지 같이 구워버리면 되잖아?"라는 아이디어에서 나온 것이 Spring Boot 3.3+의 빌드팩(Buildpacks) 기능입니다. 사용자가 bootJar 같은 명령어로 단순 JAR를 만들 때는 CDS를 안 만들지만, bootBuildImage 명령어로 도커 이미지를 빌드할 때는 최종 실행 환경(Linux JVM) 위에서 애플리케이션을 한 번 켰다 끄는 '학습(Training)' 과정을 빌드 타임에 자동으로 수행합니다. 그리고 완성된 .jsa 파일을 도커 이미지 내부에 JAR와 함께 구워줍니다.
워밍업은 CPU 캐시부터 디스크 네트워크 JIT 전부다 해야되는거고 니가 말하는건 VM JIT 워밍업 뿐임
@피치피(183.101) 문제는 저게 옵션이 똑같아야되고 컴파일 해야되니까 깃헙액션에서 될려나?
@ㅇㅇ(211.234) ㅇㅇ 자바 jit 그쪽 구간 말하는거야 뭔데 수백번이나 해야되누
@피치피(183.101) 런타임 리플렉션 같이 런타임에만 얻을 수 있는 정보를 써서 최적화 하는게 가능하지 기존에 소스코드만 보는 컴파일러와 다르게
@피치피(183.101) 컴파일 언어도 PGO라고 수백번 벤치마크 돌리고 그걸로 바이너리 최적화하는거 있음