Tagged: JVM Flags

유용한 JVM 플래그들 – Part 8 (GC Logging)

이 씨리즈의 마지막은 가비지 컬렉션 로깅과 연관된 플래그들이다. GC 로그는 힙의 잠재적인 개선, GC설정 이나 애플리케이션의 객체할당 패턴을 들어내주는 아주 중요한 툴이다. 각 GC가 발생하면, GC 로그는 과정과 결과에 대한 정밀한 데이터를 제공한다.

-XX:+PrintGC

-XX:+PrintGC 나 혹은 별명인 -verbose:gc 는 모든 young generation GC와 모든 풀GC에 대해 라인으로 출력되는 단순히 GC 로깅 모드를 활성화한다. 예를들면 다음과 같다.

Shell
1
2
[GC 246656K->243120K(376320K), 0,0929090 secs]
[Full GC 243120K->241951K(629760K), 1,5589690 secs]

라인의 시작은, ‘GC’ 혹은 ‘Full GC’, GC 타입이다. 그 다음이 GC 전과 후에(화살표로 구분되는) 점유 힙 메모리고 괄호안에 용량은 현재 힙의 용량이다. 라인의 끝은 GC가 수행된 시간이다(초단위 시간).

따라서, 첫째라인에서, 246656K→243120K(376320K) 는 GC가 점유 힙 메로리를 246656K 에서 243120K 로 줄였다는 뜻이다. GC 당시에 힙 용량은 376320K 이고 GC 는 0.0929090 시간을 소비했다.

단순한 gC 로깅 포캣은 사용되는 GC 알고리즘과 아무런 상관이 없고 더이상 상세함을 제공하지 않는다. 위의 예제에서 우리는 GC가 young 에서 old generation 으로 객체가 이동될때에 로그에 기록할 수 없다. 그러한 이유로, 상세한 GC 로깅은 단순한 로깅보다 훨씬 유용하다.

-XX:+PrintGCDetails

만약 -XX:+PrintGC 보다 -XX:+PrintGCDetails 를 사용한다면, 우리는 사용되는 GC 알고리즘에따라 달라지는 “상세한” GC 로깅 모드를 활성화 한다. 처리량 컬렉터를 사용하는 young generation GC 에 의해서 생성된 출력을 살펴보는 것으로 시작한다. 좀 더 읽기 편하게, 나는 출력물을 몇개의 라인으로 나누고 그들을 들여쓰기를 했다. 실제 로그에서, 이것은 한줄이며 사람이 읽기는 불편하다.

Shell
1
2
3
4
5
[GC
    [PSYoungGen: 142816K->10752K(142848K)] 246648K->243136K(375296K),
    0,0935090 secs
]
[Times: user=0,55 sys=0,10, real=0,09 secs]

우리는 단순한 GC 로그로부터 몇가지 요소를 알수 있었다. 점유 힙 메모리를 246648K 에서 243136K 감소시키고 0.0935090 초를 소비한 young generation GC가 있다. 추가로, young generation 자체에 대한 정보를 얻는데, 이것의 용량과 점유률뿐만아니라 사용된 컬렉터가 무엇인지를 알 수 있다. 위 예제에서, “PSYoungGen” 컬렉터는 점유된 young generation 힙 메모리가 142816K 에서 10752K 로 줄일 수 있었다.

우리는 young generation 용량을 알고 있기 때문에, young generation 이 다른 객체할당을 수용할 수 없기때문에 GC를 발생시켰다라고 쉽게 이야기할 수 있다. 활용가능한 142848K 중에 142816K 이 사용되었다. 게다가, 우리는 우리는 young generation에서 제거 된 개체의 대부분이 아직 살아 있고 old generation 으로 이동되었다고 결론 내릴 수 있다: 142816K→10752K(142848K) 와 246648K→243136K(375296K) 를 비교해 young generation 이 거의 완벽하게 비였음에도 불구하고, 전체 힙 점유률은 거의 같게 남았다.

상세 로그 섹션의 “Times”은 GC에 의해서 사용된 운영체제의 커널 공간(“sys”), 사용자 공간(“user”)으로 나뉜 CPU 시간에 대한 정보를 포함한다. 또, GC가 동작중에 소비한 real time(“real”) 가 보인다. (0.09 sms 로그에서 보여준 0.0935090 시간의 반올림일 뿐이다.) 만약 위 예제처럼 CPU time 이 소비된 real time 보다 상당히 높다면 GC가 다중 쓰레드를 사용해 동작했다고 결론내릴 수 있다. 이러한 경우, 기록된 CPU time 은 모든 GC 쓰레드들의 CPU time의 총 합이다. 그리고 추가로, 나는 위 예제에서 컬렉터가 8개의 쓰레드를 사용했다고 말할 수 있다.

이제 풀GC 출력에 대해서 생각해보자.

Shell
1
2
3
4
5
6
7
[Full GC
    [PSYoungGen: 10752K->9707K(142848K)]
    [ParOldGen: 232384K->232244K(485888K)] 243136K->241951K(628736K)
    [PSPermGen: 3162K->3161K(21504K)],
    1,5265450 secs
]
[Times: user=10,96 sys=0,06, real=1,53 secs]

young generation 에 대한 추가된 상세함으로 인해서 old 와 permanert generation 에 대해 상세함을 우리에게 제공해준다. 전체 세가지 세대들에 대해, 우리는 사용된 컬렉터, GC 전후에 점유율, GC 시에 용량을 알 수 있다. 주목할 것은 총 힙에 대해 보여준 각 숫자는 ( 243136K→241951K(628736K) ) 는 young 과 old generation 의 숫자 합과 같다. 위 예제에서, 241951K 의 총 힙을 점유했고 9707K 는 young generation, 232244K 는 old generation 을 점유했다. 풀GC는 1.53초 소비됐고 user space에서 CPU time 10.96 초는 GC가 다중 쓰레드로 상되었음을 보여준다.(위와같이 8개 쓰레드)

다른 세대들에대한 상대한 출력은 GC 발생에대한 추론을 가능하게 한다. 만약에, 모든 세대에 대해, GC전에 점유한 로그 상태가 거의 현재 용량과 같다면 이 세대는 GC가 발생가능성이 높다. 하지만, 위 예제에서, 이것은 세가지 세대에대해 해당되지 않는다. 그러면 무엇이 이 경우에 GC를 발생시켰을까? 처리율 컬렉터에서 GC 인체공학이 세가지 세대중에 하나가 고갈되기전에 GC가 이미 실행되어야 한다고 결정했다면 실제로 이러한 일이 발생될 수 있다.

풀GC 또한 애플리케이션이나 외부 JVM 인터페이스중에 하나를 통해서 명시적으로 요청이 있을때에 발생될 수도 있다. “system GC” 경우에는 GC 로그에서 “Full GC” 대신에 “Full GC(System)”으로 시작되는 라인을 가지기 때문에 쉽게 파악할 수 있다.

시리얼 컬렉터(Serial Collector) 에서, 상세 GC 로그는 처리량 컬렉터와 매우 유사하다. 한가지 다른 점이라면 다른 GC 알고리즘을 사용하고 있기 때문에 다양한 섹션들에 이름들이 다르다.(예를들어, old generation 섹션은 “ParOldGen” 대신에 “Tenured” 라 부른다). 정확한 이름의 컬렉션을 사용하는 것이 좋은데, JVM의 의해서 사용되어지는 특정 가비지 컬렉션의 로그로부터 추론을 할 수 있기 때문이다.

CMS 컬렉터(CMS Collector)에서, young generation GC에 상세 로그는 역시 처리량 컬렉션과 매우 유사하지만 old generation GC에 대해서는 같지 않다. CMS 컬렉터에서 old generation GC들은 다른 단계를 사용해 애플리케이션에 동시적으로 작동한다. 그렇기 때문에, 그것의 출력은 풀GC 출력과 다르다. 추가적으로 다른 단계에대한 라인들은 일반적으로 동시적 컬렉션이 동작중에 발생된 young generation GC 에대한 라인에 의해서 로그와 분리된다. 다른 컬렉터들을 이미 봐왔기 때문에 GC 로그의 모든 요소들이 익숙하고 그래서 다른 단계에 대한 로그를 이해하기란 어렵지 않다. 다만 처리중일때에 특별히 조심하고 애플리케이션과 동시적으로 모든 단계가 실행된다는 것을 상기해야만 한다. 따라서, 반대되는 stop-the-world 컬렉션들처럼, 개별적인 단계 혹은 전체 GC 주기가 오랫동안 실행되는 시간이 항상 문제가 있다는 것은 아니다.

Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[GC
[1 CMS-initial-mark: 5506743K(7340032K)] 5535371K(8283776K),
0.0092830 secs
]
[Times: user=0.01 sys=0.00, real=0.02 secs]
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.112/0.112 secs] [Times: user=0.43 sys=0.05, real=0.11 secs]
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.026/0.029 secs] [Times: user=0.08 sys=0.01, real=0.03 secs]
[CMS-concurrent-abortable-preclean-start]
[CMS-concurrent-abortable-preclean: 1.300/1.339 secs] [Times: user=2.73 sys=0.48, real=1.34 secs]
[GC
[YG occupancy: 450411 K (943744 K)]
3506541.032: [Rescan (parallel) , 0.0495870 secs]
3506541.082: [weak refs processing, 0.0663520 secs]
[1 CMS-remark: 5506743K(7340032K)] 5957154K(8283776K),
0.1211210 secs
]
[Times: user=0.46 sys=0.00, real=0.12 secs]
[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.288/0.288 secs] [Times: user=0.92 sys=0.18, real=0.29 secs]
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.017/0.017 secs] [Times: user=0.03 sys=0.01, real=0.02 secs]

이 시리즈의 part 7에서 알아봤듯이, 풀GC들은 CMS 컬렉터가 재시간에 CMS 주기가 완료되지 않으면 발생 될 수 있다. 만약 그게 발생하면, GC 로그는 추가적으로 풀GC 발생 원인이 무엇인지와 같은 힌트를 포함한다. 예를들어, “concurrent mode failure” 와 같은.

이 기사를 짧게 유지하기 위해서, 나는 CMS 컬렉터 GC 로그의 상세한 설명을 자제할 것이다. 또, 실제 컬렉터 작성자중에 한분이 여기에 이미 훌륭한 설명을 발표했다. 나는 이것을 읽기를 강력히 추천한다.

-XX:+PrintGCTimeStamps and -XX:+PrintGCDateStamps

이것은 (단순하게 혹은 상세하게) GC 로그에 시간과 날짜 정보를 추가하는게 가능하다. -XX:+PrintGCTimeStamps 에서 timestamp 은 JVM이 시작된 이후에 초단위로 흐른 실제시간을 반영하도록 매 라인마다 추가된다. 예를들어

Shell
1
2
3
0,185: [GC 66048K->53077K(251392K), 0,0977580 secs]
0,323: [GC 119125K->114661K(317440K), 0,1448850 secs]
0,603: [GC 246757K->243133K(375296K), 0,2860800 secs]

그리고 -XX:+PrintGCDateStamps 를 지정하면 로그가 쓰여질때에 각 시작 라인이 절대 날짜와 시간을가지고 시작된다.

Shell
1
2
3
2014-01-03T12:08:38.102-0100: [GC 66048K->53077K(251392K), 0,0959470 secs]
2014-01-03T12:08:38.239-0100: [GC 119125K->114661K(317440K), 0,1421720 secs]
2014-01-03T12:08:38.513-0100: [GC 246757K->243133K(375296K), 0,2761000 secs]

두가지 출력이 좋아보이면, 두 플래그 조합이 가능하다. 나는 항상 두가지 플래그를 지정하도록 권하는데, 그러한 정보는 다른 소스들로부터 데이터를 가지는 GC 로그 데이터를 연관시키기위해 매우 유용하다.

-Xloggc

기본적으로 GC 로그는 stdout 에 쓰여진다. 대신 -Xloggc:<file> 로 우리는 출력 파일을 지정할 수 있다. 주목할 것은 이 플래그는 -XX:+PrintGC 과 -XX:+PrintGCTimeStamps 처럼 묵시적으로 지정한다. 역시, 나는 필요하다면 이러한 플래그들을 명시적으로 지정하길 권하는데, 새로운 JVM 버전들에 예기치않은 변화로부터 여러분들로부터 보호해준다.

“Manageable” Flags

자주 논의되는 것중에 프로덕트 시스템에 JVM에 GC 로깅을 활성화해야하느냐 마느냐 하는 것이다. GC 로깅의 오버헤드는 보통 매우 적다라는데 나는 분명히 “yes”다. 하지만, 이것은 JVM이 시작할때에 우리는 GC 로깅에 대한 고민을 할 필요가 없다건 좋은 것이다.

HotSpot JVM 은 “manageable”이라 불리우는 특별한(하지만 아주 작은) 카테고리 플래그들을 가진다. 관리 플래그들에 대해 런타임으로 그들의 값을 변경하는 것이 가능하다. 여기서 논의한 모든 플래그들과 “PringGC” 로 시작하는것들이 “manageable” 카테고리에 속한다. 따라서, 우리는 실행중인 JVM에서 우리가 원할때마다 언제든지 GC 로깅을 활성화하거나 비활성화할 수 있다. 관리 플래그들을 지정하기 위해서 우리는 JDK에 포함된 jinfo 를 사용하거나 JMX 클라이언트와 HotSpotDiagnostic MXBean 의 연산인 setVMOption를 호출해 가능하다.

 

유용한 JVM 플래그들 – Part 6 (Throughput Collector)

실제로 우리가 찾은 대부분의 애플리케이션 영역에서, 가비지 컬렉션(GC) 알고리즘은 두가지 기준에 따라 평가되어져 왔다.

  1. 보다 높은 처리율을(throughput) 달성하기 위한 좀 더 나은 알고리즘
  2. 결과적으로 좀 더 적은 일시 정지시간을(pause times) 가지는 좀 더 나은 알고리즘

먼저, 우리는 GC 맥락에서 “일시 정지시간” 과 “처리율” 말을 명확하게 할 필요가 있다. JVM은 항상 전용의 쓰레드에서, “GC 쓰레드”라 부르는, GC를 수행한다. GC 쓰레드가 활성화될때마다, 그들은 활용할 프로세서와 CPU 시간을 가지고 활동적인 “application 쓰레드”들과 경쟁한다. 조금 단순화하면, 우리는 애플리케이션 쓰레드들이 실행중일때에 전체 프로그램 실행 시간의 일부분으로 “처리율”을 생각한다. 예를들어, 99/100 이라는 처리율은 평균 애플리케이션 쓰레드들이 100분의 99초 프로그램 실행 시간을 가지고 작동했고 반면에 GC 쓰레드들은 오직 동일한 시간범위동안 1초만 가지고 동작했을 뿐이다.

“일시정지시간(pause time)“이라는 용어는 GC 쓰레드로 인해서 애플리케이션 쓰레드가 완변하게 일시정지되어지는 시간범위를 말한다. 예를들어, GC 동안 100ms 의 일시정지 시간은 100ms 마다 애플리케이션 쓰레드가 활성화되지 않았다는 것이다. 만약 우리가 동작중인 애플리케이션에대해 100ms의 “평균 일시 정지시간(average pause time)“으로 용어를 말하면 관측되는 그러한 애플리케이션에 모든 정지 시간이 평균 100ms 길이를 가진다는 뜻이다. 비슷하게, 100ms 의 “최대 일시 정지시간(maximum pause time)“은 100ms 보다 큰 일시 정지시간이 관측되지 않았다는 뜻이다.

Throughput vs. pause times

높은 처리율은 애플리케이션의 최종 사용자가 느끼기에 애플리케이션 쓰레드들이 상용제품처럼 작동하는 것이기 때문에 매력적이다. 직관적으로, 만약 처리율이 아주 높다면 애플리케이션이 좀 더 빠르게 동작한다. 낮은 일시 정지시간들 또한 매력적이다. 왜냐하면 최종 사용자 관점에서 행(hanging)이 걸린 애플리케이션은 GC 나 다른 이유에 의해서 발생되어진 것과 상관없이 항상 원하지 않는다. 애플리케이션 타입에 따라서, 200ms의 짧은 일시 정지시간조차도 최종 사용자의 경험을 방해할 수 있다. 따라서, 특히나 대화형 애플리케이션에서 낮은 최대 정지시간을 가지는 것은 중요하다.

불행하게도, “높은 처리율(high throughput)” 과 “낮은 일시 정지시간(low pause times)“은 같은 목적을 가지는 경쟁관계에 있다. 다시 명확하게하기 위해서 아주 단순화한 방법으로 생각해보자. GC는 안전하게 실행되기 위해서 어떤 전제조건이 필요하다. 예를들어, 애플리케이션 쓰레드들은 객체들의 상태를 변경하지 않도록 보장되어야 하는 반면에 GC 쓰레드들은 어떤 객체들이 아직도 참조되어 있는지 아닌지를 결정하기위해서 노력한다. 이러한 이유 때문에, 애플리케이션 쓰레드들은 반드시 GC 동안 정지된다.(혹은 사용되어지는 알고리즘에 따라, 특정 GC 단계중에서만 애플리케이션 쓰레드는 정지된다.) 하지만 이것은 쓰레드 스케줄링에 있어서 추가적인 비용이 발생한다. 컨텍스 스위치(context switches)를 통한 직접 비용과 캐쉬 영향으로 발생되는 간접비용. 이것은 각 GC가 어떤 무시할수 없는 오버헤드를 포함하는 추가적인 JVM 내부 안전에 대한 비용을 포함해 그들이 실제 작업을 수행하는 GC 쓰레드가 소비하는 시간을 추가할지를 측정한다. 따라서, 우리는 가능한한 GC를 적게 실행시킴으로써 최대 처리율을 달성할 수 있지다. i.e., only when it is unavoidable, to save all the overhead associated with it.

그러나, GC의 빠르게만 실행하기는 GC가 동작할때마다, 그동안 힙에 축적된 객체 수가 더 높아질때마다, 더많은 작업을 해야한다는 뜻이다. 단일 GC는 완료될때까지 아주 높은 평균과 최대 일시 정지시간을 야기시켜 좀 더 많은 시간이 소요된다. 따라서, 낮은 일시 정지 시간에서, 각 단일의 동작이 더 빨리 완료되도록 자주 GC를 실행하는 것이 바람직 할 것이다. 이것은 추가적인 오버헤드를 동반하고 처리율을 떨어트리고 우리는 다시 원점으로 되돌아 오게된다.

요약하면, GC 알고리즘을 사용하거나 디자인할때에 우리는 목적이 무엇인지를 결정해야 한다: GC 알고리즘 두 목적중에 하나만(최대 처리율이나 최소 일시 정지시간에 맞춰) 타켓으로하거나 그들사이에 타협점을 찾기위해 노력해야 한다.

Garbage collection on the HotSpot JVM

우리는 이미 young generation GC 에 대해서 part 5 에서 논의했었다. old generation 에 대해서, HotSpot JVM은 주요하게 두가지 클래스의 GC 알고리즘을 제공한다. (지금은 새로운 G1 GC 알고리즘을 따로 두고) 첫번째 클래스는 최대 처리율을 위해 노력해는 알고리즘이고 두번째는 최소 일시정지 시간을 위해 노력하는 알고리즘이다. 오늘은 첫번째에 포커스를 맞춘다. “처리율 지향(throughput-oriented)” 클래스.

우리는 설정 플래그들에 초점을 맞추길 원하는대로, 나는 HotSpot 에서 제공되어지는 처리율 지향 GC 알고리즘의 짧은 개요을 제공할 것이다. Old generation 에서 메모리 공간이 부족해 객체할당이 실패할때 GC 알고리즘은 작동된다.(일반적으로, “메모리 할당”은 young generation 에서 객체 승격(Old generation 으로)이다.) “GC roots” 로 부르는 것부터 시작하면, GC는 힙에서 도달한 객체를 찾고 살아있다고 표시한다. 나중에 GC는 그들이 싱글, 파편화되지 않는 메모리 블록을 회득하기위해(역주, 이게 뭔소린지 모르겠다. 싱글을 획득한다…), 살아있는 객체를 Old generation 으로 이동시키고 나면 남아있는 메모리 영역은 해제된다. 거기다 young generation GC 알고리즘 동작처럼 다른 힙 영역에서는 복사 전략을 따르지 않는다. 반면에 같은 힙 영역에서 모든 객체는 비파편화된채 유지된다. 컬랙터들은 GC 성능을 위해서 하나 혹은 그 이상의 스레드들을 사용한다. 하나 이상의 쓰레드를 사용할때, 알고리즘의 다른 단계들은 다른 GC를 방해하지 않도록 각각의 GC 쓰레드는 주로 자체 영역에서 작동하도록 세분화된다. GC 중에, 모든 애플리케이션 쓰레드들은 일시정지되어지고, GC가 끝났을때에만 재시작되어진다. 이제 우리는 처리율 지향의 GC 알고리즘과 관련있는 아주 중요한 플래그들을 살펴보자.

-XX:+UseSerialGC

우리는 단일 쓰레드버전의 처리율 지향 가비지 컬렉터인 serial 를 활성화기위해 이 플래그를 사용한다. young generation 과 old generation GC 모두 단일 GC 쓰레드만으로 실행되어질 것이다. 이 플래그는 오직 단일 프로세서 코어만 사용하는 JVM에서만 권장되어져 왔다. 이러한 상황에서, 다중 GC 쓰레드를 사용하는것은 역효과를 가지고 오는데 그 이유는 이러한 쓰레드들은 CPU 자원을가지고 경쟁을 하고 동기화 오버헤드를 유발시키기 때문에 실전에서는 절대로 동작하지 않는다.

-XX:+UseParallelGC

이 플래그에서, 우리는 다중GC 쓰레드를 사용하기위해서 다중으로 young generation GC를 실행하도록 JVM에게 요청한다. java 6 에서, 내 의견으로는, -XX:+UseParallelOldGC를 사용하는게 더 낫기때문에 이 플래그는 사용해서는 안된다. java 7 에서는 조금 바뀌었는데 -XX:+UseParallelGC 가 -XX:+UseParallelOldGC 와 같은 효과로 사용되어질 수 있기 때문이다.

-XX:+UseParallelOldGC

이 플래그의 이름은 “old” 가 마치 “deprecated” 처럼 들려서 조금 안스럽다. 그러나, “old”는 실제로 old generation 을 가르기 때문에 -XX:+UseParallelOldGC가 왜 -XX:+UseParallelGC보다 더 바람직한지를 설명해준다: 추가로 parallel young generation GC는 parallel old generation GC를 또한 활성화한다. 나는 사용이 높은 처리율이 필요하고 JVM이 두개 이상의 다중 코어를 사용할때라면 이 플래그 사용을 권고한다.

참고로, 처리율 지향 HotSpot GC 알고리즘의 다중(parallel) 버전들은 다중 실행(parallel execution)을 통해서 처리율을 증가시키는데 목적이 있기 때문에 자주 “throughput collectors” 이라고 부른다.

-XX:ParallelGCThreads

-XX:ParallelGCThreads=<value> 에서 우리는 다중 GC를 위해 사용되어질 GC 스레드의 수를 지정할 수 있다. 예를들어, -XX:ParallelGCThreads=6 에서 각 다중GC는 6의 쓰레드를가지고 실행되어질 것이다. 만약 이 플래그를 명시적으로 지정하지 않으면, JVM은 활용가능한 프로세서들의 수를 기반으로 계산한 기본값을 사용한다. 이것을(기본 값) 결정하는 요인은 Runtime.availableProcessors() 자바 메소드에 의해서 리턴된 N 값이다. N ⇐ 8 다중 GC는 그것을 다 사용한다. 그래서 N GC 쓰레드라고 한다. 그런데 N>8 활용가능한 프로세서들이 있다면 GC 쓰레드의 수는 3+5N/8 로 계산되어진다.

기본값을 사용하는것은 JVM이 프로세서나 시스템을 독점적으로 사용할때에 대부분 적합하다. 하지만, 만약 같은 머신에서 하나 이상의 JVM나 부족한 CPU에서 모두 돌리고 있다면, GC 쓰레드의 수를 줄이기 위해서 적절한 값으로 -XX:ParallelGCThreads 를 사용해야 한다. 예를들어, 4개 서버 JVM이 16개 프로세서 코어를 가진같은 머신에서 동작중이라면, -XX:ParallelGCThreads=4 는 다른 JVM 의 GC와 상호간섭이 일어나지 않기 위해서 적절한 선택이다.

-XX:-UseAdaptiveSizePolicy

처리율 컬렉션들은 GC설정에서 사용자 친화성을 향상시키기 위한 흥미로운(하지만 일반적인, 적어도 현대 JVM에서는) 메커니즘을 제공한다. 이 메커니즘은 java 5에서 HotSpot 를 위해서 소개된 “인체공학”이라고 알려진 일부분이다. 인체공학에서, 가비지 컬렉터는 GC세팅들과 마찬가지로 변경들이 GC성능을 향상시킬수 있다는 증거가 있다면 동적으로 다른 힙 영역의 크기에 변경을 가할 수도 있다. “GC 성능 향상”의 엄밀한 의미는 -XX:GCTimeRatio 와 -XX:MaxGCPauseMillis 를 통해 사용자에 의해서 지정되어질 수 있다.

인체공학이 기본적으로 활성화된다는 것을 알고 있는게 중요하다. 적응적인 행동(역주, 아마도 JVM이 시스템을 감지해 그것에 걸맞게 플래그 세팅값을 자동으로 세팅하는 것을 말하는것 같다) 처럼 인체공학은 JVM의 가장 강력한 기능중의 하나이다. 여전히, 가끔은 특정 애플리케이션에 최적인 세팅이 무엇인지를 아주 명확한 생각을 가져야 하고, JVM이 우리의 세팅을 나잡하게 하는걸 원하지 않는다. 이런 상황에서, 우리는 -XX:-UseAdaptiveSizePolicy 세팅을 통해서 몇몇의 인체공학의 비활성화를 고려해야 한다.

-XX:GCTimeRatio

-XX:GCTimeRatio=<value> 은 처리율 달성을 위해서 목표값을 JVM에 설정할 수 있다. 더 정확하게, -XX:GCTimeRatio=N 값은 애플리케이션 쓰레드의 실행시간에(총 프로그램 실행 시간과 연관된) 대해 N/(N+1)의 목표비율을 지정한다. 예를들어 -XX:GCTimeRatio=9 우리는 애플리케이션 쓰레드들이 적어도 총 실행시간의 9/10 을 활성화하게 요구할 수 있다. (그리고, 따라서, 나머지 1/10 이 GC 쓰레드들이다.) 실행시간에 측정을 바탕으로, JVM은 목표 처리량에 도달되도록 힙 및 GC 설정을 수정하려고 할 것이다. -XX:GCTimeRatio 기본값은 99인데, 애플리케이션 쓰레드들은 적어도 총 실행시간에 99퍼센트에 대해 실행한다.

-XX:MaxGCPauseMillis

플래그 -XX:MaxGCPauseMillis=<value>는 JVM에게 최대 일시정지 시간을 목표값(밀리초)으로 설정하도록 한다. 런타임에서, 처리율 컬렉터는 일시 중지 시간을 통해 통계를(가중 평균 및 표준 편차) 계산한다. 만일 통계가 목표값을 초가해 일시 정지시간을 경험할 위험이 있다고 제안하면, JVM은 그들을 줄이기 위해서 힙과 GC 세팅을 수정한다. 한가지 유의할 점은 통계는 young 과 old generation GC 별로 계산되어진다. 또 기본적으로 최대 정지 시간을 설정하는 목표값은 없다.

만일 최대 정지시간과 최소 처리율에 대한 목표값을 지정하면, 최대 일시 정지 시간 목표를 달성하는 것에 우선순위를 더 높게 가진다. 물론, JVM이 열심히 노력한다고 하더라도 양쪽 모두 목표 달성을 보증하지는 않는다. 결국, everything depends on the behavior of the application at hand

최대 일시 정지 시간 목표를 설정했을때, 우리는 너무 작은 값을 선택하지 않도록 주의해야 한다. 우리는 지금까지 알고 있듯이, 일시정지 시간을 낮게 유지하기 위해, JVM은 달성할수있는 처리량에 심각하게 영향을 주는 총 GC 갯수를 증가시켰다. 그것은 애플리케이션이 주요 목표처럼, 마치 웹 애플리케이션의 경우처럼, 낮은 일시정시간을 요구하기 때문에 나는 처리율 컬렉터만 사용하길 추천하지 않고 대신 CMS 컬렉터로 바꾸길 권한다. CMS 컬렉터는 이 시리즈의 다음번 주제다.

유용한 JVM 플래그들 – Part 4 (힙 튜닝)

이상적으로, 자바 애플리케이션은 아무런 플래그를 지정하지 않은채 기본 JVM 세팅만으로도 잘 동작한다. 하지만 운이 나쁘게도 성능적인 문제에 직면했을때, 관련 JVM 플래그에 대한 지식들은 훌륭한 안내서가 된다. 이번시간에는 메모리 관리 영역에 대한 몇몇 JVM 플래그들을 살펴볼 것이다. 이러한 플래그들에 대해서 알고 있는 것과 이해하는 것은 개발자나 운영자로서의 높은 가치를 증명한다.

모든 설치된 HotSpot 메모리 관리와 가비지 컬렉션 알고리즘은 힙(Heap)의 동일한 기본 분할에 기초한다: “young generation” 은 새롭게 메모리가 할당된 것과 짧은 삶을 사는 객체를 가진다. 반면에 “old generation” 은 특정연령 이상 수명이 긴 객체를 포함한다. 그 외에, “permanent generation” 전체 JVM 라이프사이클을 통해서 살아가야할 객체를 포함하는데 예를들면 로드 된 클래스의 객체 표현이나 문자열 인터 캐쉬등이다. 다음시간부터 우리는 힙이 permanent, old, young generation 들이 전통적인 전략에 따라 분할되어 있다고 가정할 것이다. 그러나, 다른 전략들도 유망하다, 한가지 눈에 뛰는 새로운 G1 가비지 컬랙터의 존재는 young 과 old generation 사이의 구분을 흐리게 한다. 또,  HotSpot JVM 의 미래버전일 수 있는 현재 개발버전에서는 더 이상 old 와 permanent generation들을 구분하지 않을 것이다.

-Xms and -Xmx (or: -XX:InitialHeapSize and -XX:MaxHeapSize)

아주 유명한 JVM 플래그들로 최대 JVM 힙 크기와 초기 JVM 힙 크기를 각각 지정할 수 있도록 해주는 -Xms 와 -Xmx가 있다. 양쪽 모두 기본적으로 bytes 용량단위의 값을 가지지만 짧은 용량 표기법을 지원하는데 “kilo”는 “k”나 “K”, “mega”는 “m”나 “M” 그리고 “giga”는 “g”나 “G”로 표기할 수 있다. 예를들어, 다음의 커맨드 라인은 초기 힙 크기를 128 megabytes 와 최대 힙 크기를 2 gigabytes 로 세팅하고 “MyApp” 자바 클래스를 시작한다.

Shell
1
$ java -Xms128m -Xmx2g MyApp

실제로, the initial heap size turns out to also be a lower bound for the heap size,i.e., 최소 힙 크기(minimum heap size). JVM이 런타임에 동적으로 힙의 크기를 조정할 수 있으며, 따라서 이론적으로 우리는 힙의 크기가 초기 힙 크기 아래로 떨어지는 것을 관찰할 수 있는 것은 사실이지만, 나는 실험적으로 아주 낮은 힙을 사용할때조차도 이러한 것을(이론상으로 가능한 것) 목격한 적은 없다. 이러한 행동은 개발자와 운영자에게 편리한데, 단순하게 -Xms 와 -Xmx 를 같은 값으로 세팅함으로써 정적 힙 크기를 지정할 수 있도록 해주기 때문이다.

-Xms 와 -Xmx 가 짧은 약어이며 이것은 내부적으로 -XX:InitialHeapSize 와 -XX:MaxHeapSize 로 매핑된다. 이러한 두개의 XX 플래그들은 같은 효과을 주기위해서 직접 사용할 수 있다.

Shell
1
$ java -XX:InitialHeapSize=128m -XX:MaxHeapSize=2g MyApp

주목할 것은 초기 및 최대 힙 크기에 관한 모든 JVM 출력이 독점적으로 긴 이름을 사용한다. 따라서 동작중인 JVM 의 힙 크기에 대한 정보를 찾을때에는, -XX:+PrintCommandLineFlags 의 출력으로 체킹을 하거나 JMX를 통해 JVM 에 질의를한다거나, 우리는 “Xms” 나 “Xmx” 가 아닌 “InitialHeapSize” 나 “MaxHeapSize”를 찾아야 한다.

-XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath

만약 우리가 -Xmx 세팅을 적절한 값으로 하지 않을 경우에, JVM을 다룰 때 우리가 직면 할 수있는 가장 무서운 짐승의 하나인 OutOfMemoryError 와 마주칠 위험을 동반한채 JVM이 동작한다. 이 주제에대해 이 블로그에서 상세하게 다루었듯이, OutOfMemoryError의 근본원인을 신중하게 다룰 필요가 있다. 종종, 특별히 만약 JVM 이미 크래쉬(Crash) 되었고 애플리케이션이 몇 시간 또는 며칠 동안 부드럽게 실행 후에 오류가 프로덕트 시스템에만(Product system. 역) 실제 서비스를 하고 있는 시스템을 말한다) 나타나는 않았다면 깊이 있는 분석에 대한 좋은 방법은 힙 덤프(Heap Dump)이다. – 만약 사용할 수 없다면 최악이다

운좋게도, -XX:+HeapDumpOnOutOfMemoryError 플래그를 세팅함으로써 OutOfMemoryError 발생했을때에 자동적으로 힙 점프를 생성하도록 JVM에 지시할 수 있다. 단지 그러한 경우에 대한 플래그를 세팅함으로써 예기치못한 OutOfMemoryError 에 직면했을때에 많은 시간을 절약할 수 있다. 기본적으로, 힙 덤프는 JVM이 시작된 디렉토리에 java_pid<pid>.hprof(여기서 <pid>는 JVM 프로세스의 프로세스 ID이다) 파일에 저장된다. 이 기본값을 변경하기 위해서, 우리는 -XX:HeapDumpPath=<path> 플래그를 사용해 다른 위치를 지정할 수 있으며, <path> 는 힙 덤프를 저장할 파일에대해 상대적이거나 절대적인 경로가 될 수 있다.

아주 멋진 말인데, 우리가 명심해야할 게 있다. 힙 덤프는 특히나 OutOfMemoryError 가 발행했을때에 아주 큰걸 얻을 수 있다. 따라서 디스크 사용이 아주 넉넉한 위치를 지정하기 위해 -XX:HeapDumpPath 를 사용할 것을 권장한다.

-XX:OnOutOfMemoryError

우리는 OutOfMemoryError 가 발생했을때 임의 명령행을, e.g., 관리자에게 메일을 보낸다든가 어떤 클린업(Cleanup) 작업을 실행시키다든가하는, 실행시킬 수도 있다. 이것은 명령어들의 리스트와 그들의 파라메터들을 가지는 -XX:OnOutOfMemoryError 플래그로 인해서 가능하다. 우리는 이것에 대해 자세히 나가진 않고 설정예제를 보여주겠다. 다음 명령어 라인 상태에서 OutOfMemoryError 가 발생하면 우리는 /tmp/heapdump.hprof 파일에 힙 덤프를 작성하고 동작중인 JVM 의 사용자 홈 디렉토리에 쉘 스크립트 cleanup.sh 가 실행된다.

Shell
1
$ java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -XX:OnOutOfMemoryError ="sh ~/cleanup.sh" MyApp

-XX:PermSize and -XX:MaxPermSize

Permanent 세대는 JVM에 의해서 로드되는 모든 클래스의 객체표현을 포함하는 것으로 힙 영역과 분리된다. 많은 클래스들을(e.g., because they depend on lots of third-party libraries, which in turn depend on and load classes from even more libraries) 로드하는 애플리케이션을 성공적으로 동작시키기 위해서는 아마도 permanent 크기를 증가시킬 필요가 있을 것이다. 이것은 -XX:PermSize 와 -XX:MaxPermSize 플래그를 사용해 가능하다. 여기서 -XX:MaxPermSize 는 permanent 세대의 최대 크기를 지정하는 것이고 반면에 -XX:PermSize 는 JVM 시작시에 초기화할 크기이다. 예를들어,

Shell
1
$ java -XX:PermSize=128m -XX:MaxPermSize=256m MyApp

주의할 것은 permanent 세대 크기는 -XX:MaxHeapSize 로 지정되어지는 힙 크기의 일부로 계산되지 않는다. -XX:MaxPermSize 의해서 정한 permanent 세대 메모리의 양은 -XX:MaxHeapSize 에의해서 정해진 힙 메모리에 더해서 필요하게 되어질 수 있다.

-XX:InitialCodeCacheSize and -XX:ReservedCodeCacheSize

자주 JVM 메모리 영역에서 무시되어지는 재미있는 영역은 “코드 캐쉬(code cache)” 인데, 이것은 컴파일된 메소드의 네이티브 코드 생성을 저장하는 데 사용된다. 코드 캐쉬는 거의 성능문제를 발생시키지 않지만, 한번 코드 캐쉬 문제가 생기면 그 효과는 어마어마할 것이다. 만약 코드 캐쉬 메모리를 모두 사용하게 되면, JVM 은 경고 메시지를 출력하고 “interpreted-only mode” 로 전환한다. JIT 컴파일러는 정지되고 더이상 바이트코드(bytecode)는 네이티브 코드로 컴파일 될지 않을 것이다. 따라서 애클리케이션이 동작은 계속되지만 크기의 순서에따라 점점 느려진다.

다른 메모리 영역과 같이 우리는 코드 캐쉬 크기를 정할 수 있다. 관련 플래그로 -XX:InitialCodeCacheSize 과 -XX:ReservedCodeCacheSize이 있고 위에서 소개한 플래그들처럼 byte 용량 값을 가진다.

-XX:+UseCodeCacheFlushing

만약 코드 캐쉬가 지속적으로 증가한다면, 예를들어 hot deployment 로 인해서 발생된 메모리 릭으로 인해서, 코드 캐쉬를 늘리는 것은 단지 필연적으로 발생될 오버플로우(OverFlow)를 지연시킬 뿐이다. 오버플로우를 비하기 위해, 코드 캐쉬 메모리가 가득찼을때에 JVM이 몇몇 컴파일된 코드를 정리하도록 시키기위해 우리는 재미있고 비교적 새로운 옵션을 시도할 수 있다. 우리는 -XX:+UseCodeCacheFlushing 플래그를 지정하면 된다. 이 플래그를 사용함으로 인해서 우리는 적어도 코드 캐쉬 문제에 직면했을때에 “interpreted-only mode” 전환되는 것을 적어도 피할 수 있다. 그러나 나는 여전히 코드 캐쉬 문제가 발생되면 가능한 빨리 근본 원인을 차단하길 권장한다. 예를들어, 메모리 릭을 규명하고 그것을 고치는 방법.

유용한 JVM 플래그들 – Part 3 (모든 XX 플래그들과 값들을 프린팅하기)

최근 java 6 의 업데이트 (반드시 20이나 21로 업데이트되 있어야하는), HotSpot JVM은 JVM이 시작되자마자 커맨드라인에 모든 XX 플래그들과 그들의 값을 테이블로 출력하도록 하는 두 개의 새로운 커맨드라인 플래그들을 제공한다. 많은 HotSpot 사용자들은 첫번째 자바버전 이후부터 이러한 기능들을 원했었는데, 그래서 나는 이 글의 주제를 이것으로 하기로 했다.

-XX:+PrintFlagsFinal and -XX:+PrintFlagsInitial

바로 새로운 플래그들에 대한 출력물들을 살펴보도록 하자. -XX:+PrintFlagsFinal 사용해 클라이언트 VM 을 시작하면 알파벳으로 정렬된 590개의 XX플래그 테이블을 얻게된다. (주의할 것은 각 HotSpot버전마다 플래그 숫자는 다를 수 있다.)

java -client -XX:+PrintFlagsFinal Benchmark
Shell
1
2
3
4
5
6
7
8
9
10
11
$ java -client -XX:+PrintFlagsFinal Benchmark
[Global flags]
uintx AdaptivePermSizeWeight               = 20               {product}
uintx AdaptiveSizeDecrementScaleFactor     = 4                {product}
uintx AdaptiveSizeMajorGCDecayTimeScale    = 10               {product}
uintx AdaptiveSizePausePolicy              = 0                {product}
[...]
uintx YoungGenerationSizeSupplementDecay   = 8                {product}
uintx YoungPLABSize                        = 4096             {product}
bool ZeroTLAB                             = false            {product}
intx hashCode                             = 0                {product}

각 테이블 행은 XX 플래그들을 나타내고 다섯개의 열을 포함한다. 첫번째 열은 플래그의 데이터 타입을 보여주고, 두번째는 플래그 이름, 네번째는 플래그 값, 다섯번째는 플래그의 카테고리다. 세번째 열에서 “=“는 네번째 플래그의 값이 기본값(Default Value)이라는 걸 의미하며, 반면에 ”:=“는 사용자 혹은 JVM 인체공학에 의해서 지정된 값이라는 것을 의미한다.

주의할 것은 나는 이 예제를 위해서 이전 시간에 사용했던 “Benchmark” 클래스만 사용했다. 여러분은 -version 파라메터를 넣어 자바를 실행시킴으로써 메인 클래스 없이 같은 출력물을 얻을 수 있다.

이제 서버 VM이 얼마나 많은 플래그들을 제공하는지 체크해보자. 모든 추가적인 숨은 플래그들을 풀기위해 우리는 -XX:+UnlockExperimentalVMOptions 와 -XX:+UnlockDiagnosticVMOptions 플래그를 지정해야 한다.

Shell
1
$ java -server -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal Benchmark

그 결과는 아주 많은 724 플래그들이다. 기본값이 아닌 값이 지정된 플래그들을 살펴보자.

Shell
1
2
3
4
5
6
$ java -server -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal Benchmark | grep ":"
uintx InitialHeapSize                     := 57505088         {product}
uintx MaxHeapSize                         := 920649728        {product}
uintx ParallelGCThreads                   := 4                {product}
bool PrintFlagsFinal                     := true             {product}
bool UseParallelGC                       := true             {product}

우리는 플래그들 중에 하나만(-XX:+PrintFlagsFinal) 지정 했을 뿐이다. 다른 플래그들은 시스템을 고려해 알맞은 힙의 크기와 가비지 컬렉터 세팅을 가지고 실행하기 위해서 서버 VM에 의해서 지정되었다.

만일 모든 XX 플래그들의 기본값들만 보길 원한다면, 우리는 -XX:+PrintFlagsInitial 플래그를 사용할 수 있다. -XX:+PrintFlagsInitial 에서, 출력은 세번째 열에서 원조 ”=” 엔트리만 보여준다.(also for those flags that were set to other values) 그런데, 주의해서보면 몇몇 플래그들은 -XX:+PrintFlagsFinal의 출력물과 비교해보면 빠져있다는 것이 있는데, 이러한 플래그들은 동적으로 생성되어지기 때문인것으로 추정된다.

클라이언트 VM과 서버 VM의 동작을 비교하기 위해서 이러한 테이블 컨텐츠를 공부하는것은 재미있는 일이다. 또, 커맨드라인에서 지정되었을때에 플래그들이 다른 플래그 값들에 영향을 미치는 것을 알수 있도록 해준다. 관심있는 독자라면, Inspecting HotSpot JVM Options 훌륭한 블로그 포스트를 참고하라. 이 포스트는 다섯번째 열에 나타나는 플래그 카테고리에 대한 의미를 짧게 설명하고 있다.

-XX:+PrintCommandLineFlags

이 토픽의 결론을 위해서, 오랫동안 사용해온 플래그 하나를 생각해보자: -XX:+PrintCommandLineFlags. 이 플래그는 JVM에게 시작시에 사용자나 JVM 인체공학에 의해서 지정된 XX 플래그들의 정확한 이름과 값을 출력하도록 한다. 다른 말로하면, 이것은 -XX:+PrintFlagsFinal 출력물의 세번째 열에서 “:=“를 가지는 플래그 리스트들이다. 이렇게 보면, 수정되는 플래그들에만 관심을 기울릴때에 -XX:+PrintCommandLineFlags 는 -XX:+PrintCommandLineFlags의 단순 버전으로 여겨질 수 있다. 위 예제로 돌아가보면,

Shell
1
2
$ java -server -XX:+PrintCommandLineFlags Benchmark
-XX:InitialHeapSize=57505088 -XX:MaxHeapSize=920081408 -XX:ParallelGCThreads=4 -XX:+PrintCommandLineFlags -XX:+UseParallelGC

이제 우리가 매번 -XX:+PrintCommandLineFlags 를 지정하고 자바 프로그램을 시작시키고 출력을 로그에 기록한다면 우리는 애플리케이션 성능측면에서 JVM 플래그 세팅의 효과를 문서화할 수 있다. 따라서 -showversion 과 유사하게(첫번째 시간에서 살펴봤듯이) 나는 JVM이 시작시 늘 지정해야하는 것처럼 -XX:+PrintCommandLineFlags 플래그로 생각한다. It comes for free, and you never know when you are going to need that information.

-XX:+PrintCommandLineFlags 에서 리스트된 최대 힙 사이즈는 -XX:+PrintFlagsFinal 에서 보여주는 상응한 갑보다 약간 작다는 것에 의문을 가지고 있다. 왜 이렇게 차이가 나는지 알고 있는 사람이 있다면 나에게 좀 알려달라.

유용한 JVM 플래그 – Part 2 (플래그 카테고리들과 JIT 컴파일러 진단들)

두번째 시간으로, HotSpot JVM에서 제공하는 플래그의 다른 카테고리들을 소개한다. 또한, 나는 JIT 컴파일러 진단(diagnostics)와 연관된 몇가지 흥미로운 플래그들에 대해서 이야기할 것이다.

JVM 플래그 카테고리들

HotSpot JVM은 세개의 플래그 카테고리들을 제공한다. 첫번째 카테고리는 표준 플래그(stand flag)들을 포함한다. 이름에서도 알수 있듯이, 기능적인부분과 표준 플래그들의 출력 모두 안정적이며 미래에 릴리즈 되는 JVM에서 잘 바뀌지 않을 것이다. java 실행시에 아무런 파라메터를 주지않으면 모든 표준 플래그 리스트들을 얻을 수 있다.(혹은 표준 출력이 있는 -help 파라메터를 사용하거나) 우리는 첫번째 시간에 몇몇 표준 플래그들을 이미 봤었다. 예를들어 -server.

두번째 카테고리는 비표준 플래그들의 행동이거나 X 플래그들로, 앞으로 릴리즈에서 바뀔 가능성이 있다. 이 카테고리의 모든 플래그들은 “-X” 로 시작되고 java -X 를 통해 리스트를 볼 수 있다. 주의할 것은 이 리스트는 완벽하게 존재하는지 보증하지 않는다. -Xcomp 가 대표적으로 누락된 플래그다.

세번째 카테고리는(가장 큰) XX 플래그들로 구성되는데, 이 또한 비표준이고 오래전부터 리스트조차 된적이 없다. (현재 이것은 바뀌었고, 우리는 이 시리즈의 세번째 시간에 이 토픽에 대해서 돌아 볼 것이다.) 그러나 실용적으로 X 플래그들과 XX 플래그들은 실제로 차이가 없다. XX 플래그들이 실험적인 반면에 X 플래그들의 행동은 XX 플래그들에 비해 아주 안정적이다. (디버깅이나 JVM 구현 자체의 튜닝을 위해서 JVM 개발자들에 의해서 주요하게 사용된다.) 비표준 플래그들에 대해서 부주의하게 사용되어서는 안될 XX 플래그들에 대해 명확하게 어떤 상태를 가지는지 HotSpot JVM 문서를 읽어 볼만 하다. 이것은 중요한 것으로, 이것은 내가 봤을때 X 플래그들에 대해서도 동일하게 적용된다. (물론 몇몇 표준 플래그들에도 적용된다.) 카테고리와 상관없이 이것을 사용하기 전에 플래그가 의도하는 행동과 가능한 사이드 이펙트(side effects)를 이해하기 위해서 노력해야 한다.

XX 플래그 문법(syntax)에 대해 한마디. 모든 XX 플래그들은 “-XX” 로 시작하지만 문법이 의존하는 플래그 타입이 다르다.

  • 불린 플래그(boolean flag)에서, “+“나 ”-” 둘다 가지며 플래그를 지정하기 위해서 JVM 옵션의 실제 이름만 가진다. 예를들어, -XX:+<name> 은 옵션 <name> 을 활성화하고 -XX:-<name> 은 이 옵션을 비활성화 한다.
  • 텍스트 문자열처럼 불린(boolean)이 아닌 값을 가지거나 정수를 가지는 플래그들에서, “=” 에 따라오는 플래그 이름을 가지고 값을 지정한다. 예를들어, -XX:<name>=<value> 는 옵션 <name> 에 값 <value>을 지정한다.

이제 JIT 컴파일 구역에 속하는 몇몇 XX 플래그들을 살펴보도록 하자.

-XX:+PrintCompilation and -XX:+CITime

이것은 자바 애플리케이션이 동작하는 중에 JIT compiler 작업을 상세히 보여준다. -XX:+PrintCompilation 플래그를 세팅함으로써 우리는 바이트코드가 네이티브 코드 컴파일과 연관된 몇몇 간단하고 단순한 출력을 활성화 할 수 있다. Server VM 동작에 대해 아주 짧은 출력 예제를 살펴보자.

java -server -XX:+PrintCompilation Benchmark
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ java -server -XX:+PrintCompilation Benchmark
  1       java.lang.String::hashCode (64 bytes)
  2       java.lang.AbstractStringBuilder::stringSizeOfInt (21 bytes)
  3       java.lang.Integer::getChars (131 bytes)
  4       java.lang.Object::<init> (1 bytes)
---   n   java.lang.System::arraycopy (static)
  5       java.util.HashMap::indexFor (6 bytes)
  6       java.lang.Math::min (11 bytes)
  7       java.lang.String::getChars (66 bytes)
  8       java.lang.AbstractStringBuilder::append (60 bytes)
  9       java.lang.String::<init> (72 bytes)
10       java.util.Arrays::copyOfRange (63 bytes)
11       java.lang.StringBuilder::append (8 bytes)
12       java.lang.AbstractStringBuilder::<init> (12 bytes)
13       java.lang.StringBuilder::toString (17 bytes)
14       java.lang.StringBuilder::<init> (18 bytes)
15       java.lang.StringBuilder::append (8 bytes)
[...]
29       java.util.regex.Matcher::reset (83 bytes)

메소드가 컴파일 되어질때 마다, 하나의 라인(line)은 -XX:+PrintCompilation 의 출력을 찍는다. 각 라인은 동작숫자(running number, 유일한 compiler task ID) 와 이름 그리고 컴파일된 메소드의 크기로 구성된다. 따라서 라인 1 은 String::hashCode 메소드를 컴파일한 네이티브 코드를 나타낸다. 메소드 타입과 컴파일러 태스크 유형에 따라, 추가적인 출력 특징들이 찍힌다. 예를들어, 네이티브 랩퍼 메소드의 생성은, 위 예제에 System::arraycopy 처럼, “n”으로 표시된다. 주의할 것은 어떤 라인은 동작숫자와 메소드 크기를 가지지 않는데, 실제로 아무것도 네이티브 코드로 컴파일 되지 않았기 때문이다. 또 11 ~ 15 라인에 StringBuilder::append 에 대한 출력을 보면, 재컴파일된(recompiled) 메소드들을 보는것이 가능하다. 출력은 총 29라인에서 멈추었는데, 자바 애플리케이션이 동작하는 동안에 총 29개의 메소드를 컴파일 했다는 것을 의미한다.

-XX:+PrintCompilation 에 대한 공식적인 문서는 없지만, 여기 내용은 이 플래그 출력에 대한 훌륭한 자원중에 하나다. 나는 이것에 대해서 좀더 공부하기를 강력하게 권유한다.

JIT 컴파일러 출력은 클라이언트 VM 과 서버 VM 사이에 몇몇 다른점을 이해하는데 도움을 준다. 서버 VM에서, 예제 애플리케이션은 29 라인 컴파일 출력을 만들었지만 클라이언 VM 사용 결과 55 라인 컴파일 출력을 만들었다. 이것은 서버 VM이 클라이언트 VM 보다 좀 더 컴파일을 하기로 되어 있었기 때문에 이상하게 여기진다.(역, 서버 VM이 컴파일을 좀 더하기 때문에 출력 라인수가 클라이언트 VM보다 많아야 할거라 추측하지만 그러지 않았다.) 그러나, 각각 주어진 기본 세팅 측면에서, 서버 VM은 메소드가 hotspot 인지 아닌지와 전체 컴파일되채 존재할 필요가 있는지 없는지를 결정하기 전에 클라이언 VM 보다 아주 오랫동안 메소드를 관찰한다. 따라서, 그것은 놀랄일이 아니다, 서버 VM에서, 몇몇 잠재적인 메소드 컴파일은 최종 단계에서만 일어난다.

추가적으로 -XX:+CITime 플래그 세팅에 의해서 우리는 JVM 셧다운시에 출력되어질 수 있는 컴파일에 대한 다양한 통계정보를 요청할 수 있다. 통계정보의 특정한 한 부분을 살펴보자.

java -server -XX:+CITime Benchmark
Shell
1
2
3
4
5
6
7
8
$ java -server -XX:+CITime Benchmark
[...]
Accumulated compiler times (for compiled methods only)
------------------------------------------------
  Total compilation time   :  0.178 s
    Standard compilation   :  0.129 s, Average : 0.004
    On stack replacement   :  0.049 s, Average : 0.024
[...]

(29 컴파일러 태스크를 위해) 총 0.178 초를 소비했다. 물론, “on stack replacement” 를 가지는 0.049초는 스택에서 현재 메소드의 컴파일 시간이다. 이 기술은 성능 기준에 맞는 유형을 구현하기위해서 단순하지 않지만 실제로 아주 중요하다. “on stack replacement” 없이 오랜 실행 시간을 가지는 메소드들은 그들의 컴파일된 카운터파트(counterpart, 짝 혹은 또 다른 부분 )로 즉각 교체되어질 수 없다.

다시말하면, 클라이언트 VM 와 서버 VM 과 비교는 흥미롭다. 클라이언트 VM에 해당하는 통계는 비록 55개 메소드를 컴파일했다는 것을 나타냈지만 이들을 컴파일하는데 총 0.021초만 소비했다. 따라서, 서버 VM 은 클라이언트 VM보다 적게 컴파일을 했지만 시간은 더 많이 소비했다. 이러한 행동의 이유는 서버 VM은 네이티브 코드를 생성할때에 좀 더 최적화를 수행하기 때문이다.

첫째 시간에 우리는 -Xint 와 -Xcomp 플래그에 대해서 배웠다. -XX:+PrintCompilation 과 -XX:+CITime 와함께 이제 우리는 두 가지 경우에(역, 서버 VM 과 클라이언트 VM) 대한 JIT 컴파일러가 행동을 어떻게 하는지에 대한 좀 더 깊게 알 수 있다. -Xint 와 함께, -XX:+PrintCompilation 은 두가지 경우에 대해서 정확하게 아무런 라인도 출력하지 않는다.(zero lines of output) 또, -XX:+CITime 은 컴파일하는데 시간을 전혀 소비하지 않았다는 것을 확인시켜준다. -Xcomp 경우는 다르다. 클라이언트 VM 은 프로그램 시작이후에 즉각 726 라인은 출력하고 모든 관련 메소드들은 컴파일되었기 때문에 더 이상 출력되지 않는다. 서버 VM 에서는 993 라인 출력을 볼 수 있는데 이는 좀 더 공격적 최적화를 수행했다는 것을 말해준다. 또, JVM이 셧다운시에 출력되는 통계에서도 둘 VM 사이에서는 아주 큰 차이를 보여준다. 서버 VM에서 실행 결과을 살펴보자.

java -server -Xcomp -XX:+CITime Benchmark
Shell
1
2
3
4
5
6
7
8
$ java -server -Xcomp -XX:+CITime Benchmark
[...]
Accumulated compiler times (for compiled methods only)
------------------------------------------------
  Total compilation time   :  1.567 s
    Standard compilation   :  1.567 s, Average : 0.002
    On stack replacement   :  0.000 s, Average : -1.#IO
[...]

-Xcomp 를 사용해 컴파일하는데 소비한 시간 1.567 초는 기본 세팅 값(ex, mixed mode) 보다 약 10배나 많은 시간을 소비했다. 여전히, 애플리케이션은 mixed 모드보다 더 느리게 동작한다. 클라이언트 VM 은 -Xcomp 를 사용했을 경우 726개의 메소드들을 컴파일하는데 0.208 초를 소비했다. 이것은 -Xcomp 를 사용한 서버 VM보다 더 느린 것이다. (역, 말이 이상하다. server VM 에서는 993 라인에 1.567 초를 client VM 에서는 726 라인에 0.208 초를 소비했는데 어째서 server VM 보다 느리다고 한 걸까?)

모든 메소드는 처음 실행 시점에서 호출되어질때에 컴파일되어지기 때문에 ‘on stack replace“가 발생하지 않는다. 손상된 출력 “Average: -1.#IO”는 (정확하게는 0) 비표준 플래그의 출력이 아주 많이 의존하는게 없다는 것을 다시 한번 보여준다.(역, 말이 이상함. The corrupted output “Average: -1.#IO” (correct would be: 0) demonstrates once more that the output of non-standardized flags is nothing to rely on too much)

-XX:+UnlockExperimentalVMOptions

특정 JVM 플래그를 세팅하면 JVM은 시작하자마자 “Unrecognized VM option” 메시지를 출력하고 곧바로 중단되곤 한다.만일 이런 일이 발생하면, 혹시 오타를 치지지 않았나 체크해야 한다. 하지만, 오타없이 정확하게 입력했는데도 여전히 JVM이 그 플래그를 인식하지 못한다면 아마도 -XX:+UnlockExperimentalVMOptions 세팅을 통해서 플래그를 풀어줄(unlock) 필요가 있다. 이것은 보안 메커니즘도 영향을 주기 때문에 명확하진 않지만 JVM이 올바르게 사용되어지지 않았을 경우에 이러한 방법으로 플래그를 안내하는 것이 JVM의 안전성에 영향을 주는 성향이라 생각하고 있다. (예를들어, 그들이 어떤 로그 파일에 아주 과도한 디버그 출력을 쓰도록 했다든지..)

어떤 플래그들은 실제로 자바 애플리케이션에서 사용하지 않고 오직 JVM 개발을 위해서 사용되도록 해놨다. 만일 플래그가 -XX:+UnlockExperimentalVMOptions 로도 활성화가 되지 않지만 어떤 이유에선지 그 플래그를 반드시 필요로한다면, 여러분은 JVM 의 디버그 빌드를 가지는 행운을 누릴 수 있다.(역, 놀리는거 같다. ㅡ.ㅡ 무슨 얼어죽을 행운이냐!!) java 6 HotSpot JVM 에 대한 디버그 빌드는 여기서찾을 수 있다.

-XX:+LogCompilation and -XX:+PrintOptoAssembly

만일 -XX:+PrintCompilation 로 제공되어지는 정보가 충분히 상세하지 않다면, “hotspot.log” 파일에 확장된 컴파일단계를 출력하도록 -XX:+LogCompilation 플래그를 사용할 수 있다. 덧붙여서 컴파일된 메소드에 대한 아주많은 상세한 정보들 중에 작업이 시작된 컴파일러 쓰레드를 볼 수 있다. 주의해야 할것은 -XX:+LogCompilation 는 -XX:+UnlockExperimentalVMOptions로 풀어줘야 한다.

JVM 은 바이트코드 컴파일로 생성된 네이티브 코드 결과들을 살펴볼 수 있도록 해준다. -XX:+PrintOptoAssembly 플래그로 인해서 컴파일러 스레드에 의해 생성 된 네이티브 코드는 표준 출력과 “hotspot.log” 파일에 모두 기록됩니다. 이 플래그를 사용은 서버 VM의 디버그 빌드를 실행하도록 요구한다. 우리는, 죽은 코드 제거하기처럼, JVM이 실제 어떤 종류의 최적화를 수행하는지를 이해하기 위해서 -XX:+PrintOptoAssembly 의 출력을 연구할 수 있다. 예제를 제시하는 흥미로운 기사는 여기에서 찾울 수 있다.

Further information about XX flags

만약 이글이 당신의 상상력을 자극한다면, HotSpot 의 XX 플래그를 스스로 찾아봐라. 아주 좋은 시작점은 이 리스트다.

유용한 JVM 플래그 – Part 1 (JVM 타입들과 컴파일러 모드들)

현대의 JVM들은 효율적이고 안정적인 방법으로 자바 애플리케이션을(혹은 JVM과 호환되는 프로그래밍 언어들) 실행시키는 놀라운 일을 한다. 맞춤 메모리 관리(Adaptive memory management), 가비지 컬렉션(garbage collection), just-in-time compilation, 동적 클래스로딩(dynamic classloading), 락 최적화(lock optimization) – 이러한 것이 마법처럼 인용되지만 일반적인 프로그래머들에게 직접적으로 영향을 주진 않는다. 실행 시점에서, JVM은 지속적인 측정과 프로파일링을 기반으로 애플리케이션이나 그것의 일부를 핸들링하는 방법을 최적화한다.

여전히 JVM이 자동화 수준과 같은 것이나 그보다 못한 것들에 대해서 외부 모니터링이나 수동 튜닝을 위한 충분한 설비를 제공하고 있다는 것은 중요하다. 에러나 낮은 퍼포먼스의 경우에는 반드시 전문가가 개입하는 것이 가능해야 한다. 게다가, 수면 아래에서 일어나는 모든 마법같은 일 외에도, 아주 폭 넓은 수동 튜닝 같은것은 현대 JVM이 가지는 강력한 것중에 하나다. 특히 흥미로운 것은 JVM이 시작시 그들에게 전달되어 질수 있는 커맨드 라인 플래그들이다. 몇몇 JVM은 수백개의 이러한 플래그들을 제공하지만 JVM에 대한 적절한 지식이 없이는 잊어버리기 쉽다.이 시리즈의 목표는 매일 사용하는 적절한 플래그들을 조명하고 그들이 장점들에 대해서 설명하는 것이다. 다른 인기있는 JVM들에 아주 유사한 플래그가 존재하지만 우리는 Java 6으로 Sun/Oracle HotSpot에 집중할 것이다.

-server 와 -client

HotSpot JVM에는 두개의 타입이 있다. 이름하야 “server” 와 “client”. 서버(server) VM은 기본적으로 아주 큰 힙(Heap), 패러럴 가비지 컬렉터(parallel garbage collector)를 사용하고 실행타임에서 좀 더 공격적으로 코드를 최적화 한다. 클라이언트(client) VM은 좀 더 보수적인데, 그 결과 좀 시작 타임이 짧아지고 메모리를 좀 더 적게 사용한다. “JVM 인체공학(ergonomic)” 이라 불리는 컨셉 덕분에 JVM의 타입은 JVM이 시작될때에 운영체제와 활용할수 있는 하드웨어를 고려한 기준에의해서 자동적으로 선택되어진다. 추가적인 기준(혹은 규격)은 여기서 찾을 수 있다. 규격(기준) 테이블로부터, 우리는 클라이언트 VM은 오직 32bit 시스템에서만 활용할 수 있다는 것을 알 수 있다.

만약 미리 정의된 JVM이 불만이라면, 우리는 서버와 클라이언트 VM 사용을 규정하기 위해 -server 와 -client 플래그를 사용할 수 있다. 비록 서버 VM이 기본적으로 장시간 실행되는 서버 프로세스들에 초점이 맞춰졌지만, 오늘날 그것은 아주 많은 독립 애플리케이션 VM에서 클라이언트 VM 보다 훨씬 높은 성능을 종종 보여준다. 나는 애플리케이션이 빠른 실행시간이 중요하다고 할때에 -server 플래그를 세팅함으로써 서버VM을 선택할 것을 권장한다. 일반적으로, 32-bit 시스템에서, HotSpot JDK는 모두 서버VM으로 동작하도록 할 필요가 있다. – 32bit JRE만 클라이언트VM을 탑재한다.

-version 과 -showversion

어떻게 우리는 자바가 설치되어 있고 JAVA를 호출했을때에 JVM 타입이 어떤건지를 알 수 있을까? 시스템에 하나 이상의 JAVA가 설치되어 있다면 아무런 알림없이 잘못된 JVM이 실행될 약간의 위험성이 항상 있다. 이러한 관점에서,비록 내가 해를 거듭할수록 좋았졌다는 것을 인정한다해도, 인기있는 다양한 리눅스 배포판에는 JVM이 미리 설치되었다.

운 좋게, 우리는 -version 플래그를 활용할 수 있다. 사용되어진 JVM에 대한 간단한 정보를 표준출력으로 출력할 수 있다. 예를들면,

java -version
Shell
1
2
3
4
$ java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)

출력된 내용을 보면 JAVA 버전 넘버(1.6.0_24)와 사용된 정확한 JRE의 빌드ID(1.6.0_24-b07) 를 보여준다. 또, 우리는 이름을(HotSpot) 볼수 있고, JVM의 빌드ID(19.1-b02) 와 타입(Client)도 볼 수 있다. 거기에 더해, 우리는 JVM 이 믹스드 모드(mixed mode)로 동작한다는걸 알 수 있다. 이 실행 모드는 기본적인 HotSpot 모드이고 실행 타임에 동적으로 바이트 코드(byte code)를 네이티브 코드(nate code)로 컴파일 한다는 걸 의미한다. 또, 우리는 클래스 데이터 공유(class data sharing)가 활성화 되었다는 것도 알 수 있다. 클래스 데이터 공유는 모든 JAVA 프로세스들이 클래스로더에 의해서 자원을 공유하는데 사용되어지는 읽기전용 캐쉬에 JRE 의 시스템 클래스들을 저장하는 기법이다. 클래스 데이터 공유는 매번 jar archive들로부터 모든 클래스 데이터를 읽어들이는 것과 비교해볼때 성능면에서 대체로 이득이 있다.

-version 플래그는 위 데이터를 출력한 후에 즉각 JVM을 종료한다. 그러나, 같은 출력결과를 만드는데 사용되어질 수 있는 -showversion 는 유사한 플래그지만 주어진 자바 애플리케이션을 실행하고 처리한다. 따라서 -showversion 은 거의 모든 자바 애플리케이션의 커맨드 라인에 유용하게 추가되었다. 여러분은 갑자기 어떤 정보가 필요할때 특별한(깨진) 자바 애플리케이션에서 사용된 JVM에 대해서 알수가 없다. 시작시에 -showversion 을 추가함으로써, 우리는 우리가 필요로할지 모르는 시점에서 활용가능한 이러한 정보를 얻는것을 보장받을 수 있다.

-Xint, -Xcomp, 그리고 Xmixed

두개의 플래그 -Xint, -Xcomp 는 우리가 매일 하는일과 관련이 없지만 JVM에 대해서 무언가를 배우기 위한 아주 큰 주제가 있다. -Xint 는 JVM에게 모든 바이트코드(Bytecode)를, 통상적으로 10배 이상 아주 느려지는 것이 수반되는, 인터프리터 모드로 실행하도록 강제한다. 이와 대조적으로, 플래그 -Xcomp 는 명시적으로 정반대로 동작하도록 강제하는데 그것은 JVM이 처음 사용시에 모든 바이트코드를 네이티브코드(Native code)로 컴파일하는데 결국 최고의 최적화 레벨을 적용하게 된다. 이것은 아주 듣기좋은 소리인데, 왜냐하면 인터프리터의 느림을 피하는 완벽한 방법이기 때문이다. 하지만 많은 애플리케이션들은 -Xinit 가 성능저하가 발생한다는 단 하나의 이유와 비교하더라도 -Xcomp 의 사용은 적은 성능 차이를 겪게 된다. 그 이유는 -Xcomp 세팅은 JVM에게 JIT 컴파일러(JIT Compiler)가 효율적으로 네이티브 코드를 만들어내는 것을 방해하게 한다. JIT 컴파일러는 실행타임에 메소드 사용 프로파일들을 생성한 다음에 실제 애플리케이션 동작을 위해 차례대로 그들의 일부나 혹은 추론을 해서 싱글 메소드들을 최적화한다. 이러한 최적화 테크닉의 일부들은, 예를들어 optimistic branch prediction, 맨 처음에 애플리케이션의 프로파일링 없이 효율적으로 적용되어질 수 없다. 또 다른 관점으로 메소드는 그들 스스로가 애플리케이션에서 어떤 종류의 지점을 구성하는데 연관되어 있다는 것이 증명되었을때 전체가 컴파일되어 진다. 오직 한번이나 아주 적게 호출되어지는 메소드들은 인터프리터 모드로 실행되는 것을 지속하게 되고 따라서 compilation 과 최적화(optimzation) 비용을 절약하게 된다.

우리는 -Xmixed 플래그를 가지는 mixed 모드를 주목하자. 최신의 HotSpot 버전에서, mixed mode는 기본값이 됐고 우리는 더 이상 이 플래그를 지정하지 않아도 된다.

해쉬맵(HashMap)에 객체를 채워넣고 그것을 다시 받는것을 반복하는 샘플 벤치마크 예제의 결과를 살펴보자. 각각의 벤치마크가 보여주는 실행시간은 수 많은 샘플 실행의 평균 값이다.

java -server -showversion Benchmark
Shell
1
2
3
4
5
6
$ java -server -showversion Benchmark
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode)
Average time: 0.856449 seconds

java -server -showversion -Xcomp Benchmark
Shell
1
2
3
4
5
6
$ java -server -showversion -Xcomp Benchmark
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Server VM (build 19.1-b02, compiled mode)
Average time: 0.950892 seconds

java -server -showversion -Xint Benchmark
Shell
1
2
3
4
5
6
$ java -server -showversion -Xint Benchmark
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Server VM (build 19.1-b02, interpreted mode)
Average time: 7.622285 seconds

당연히 벤치마크는 -Xcomp 가 최고라는 것을 보여준다. 하지만 여전히, 그리고 특별히 아주 오랜시간동안 실행되는 애플리케이션에 대해서, 나는 모든 사람들에게 강력하게 JVM 기본 세팅으로 놔두라고 하고 JIT 컴파일러의 다양한 잠재능력을 모두 사용하도록 만들라고 조언한다. 결국, JIT 컴파일러는 JVM의 아주 복잡하고 정교한 컴포넌트(component)중에 하나이다. – 사실, 현재 이 부분의 발전은 오늘날 자바가 더 이상 느리지 않다고 생각하게 만드는 가장 큰 이유다.

댓글

역주) 위 글에 댓글에 아주 흥미로운 댓글이 있어서 같이 번역해 보았습니다.

Tj Says:

조금 헷깔리는게 – 나는 자바 컴파일러가 실행타임에 JVM에 의해서 실행되어지도록
소스 코드를 바이트코드로 바꾸도록한다고 생각했다. 그래서 JVM은 오직 바이트코드만 사용할 수 있는거지.
근데 니가 말하는 -Xint 에 의해서 오직 인터프리터된다는 말은 무슨 뜻이냐?
너는 JVM이 JIT 컴파일러 움직임없이 직접적으로 바이트코드를 이해한다고 생각한거야?

Patrck Peschlow says:

Hi Tj,

그래, 너의 생각이 맞아. JVM의 입력은 바이트코드야. 그 이후에 프로그램이 실행되는 동안에 바이트 코드를
어떻게 다룰지하는 몇가지 선택지가 있어. 실행시점에서 JVM은 처음부터 네이티브코드로 컴파일하지 않고
오직 바이트코드로만 인터프리트(interpret)해. 사실 니가 실행하는 모든 자바 프로그램은 일반적으로 그것이
실행되는 동안 인터프리트된 바이트코드의 일부 조각일뿐이다.

이전에 JVM들은 인터프리터만 가지고 있었지. 그래서 전체 자바 프로그램 바이트코드는 오직 인터프리터되었어.
그것이 이전 몇년동안 자바가 느리다고 여겼던 주요한 이유였어. 지금은 현대의 JVM들은 여전히 커맨드라인에서
-Xint 을 지정하는 것으로 오직 인터프리터된 모드로 사용하는것을 허용해.
간단하게 -Xint 에다가 추가적으로 커맨드라인에 -XX:+PrintCompilation 을 추가하면 바이트코드의
네이티브 코드 컴파일화가 발생되지 않는다는 것을 볼 수 있어.
-Xint 없이 똑같은 자바 프로그램을 실행해서 나오는 결과를 비교해보라고.

JVM이 바이트코드-네이티브 컴파일화를 지원하도록 시작되었을때, 사람들은 맹목적으로 각각 모든 메소드가
네이티브 코드로 컴파일된다는 것이 말이 되지 않는다는걸 깨달았지. 대신 지금은 “just-in-tim-compilation”과
“HotSpot” 으로 알려진 컨셉/기술로 개발되었어.아주 간단하게 말해서, 처음 시작되면 JVM은 전부
바이트코드로 인터프리터하고 프로그램이 실행되는 동안에 네이티브 코드로 컴파일할 방법을 결정을 하지.

오직 “hot” 메소드들에서 아이디어는 효과적인 네이티브 코드를 생산하는데 필요한 컴파일링/최적화 노력은
가치가 있다는 거야. 이와 반대로 “cold” 메소드들은 그들이 “hot”이 될때까지 인터프리터된 모드로
다루어질거야. – 어떤 메소드들은 결코 “hot”이 될일이 없을테지만.

그런데, 니가 실행타임에 instrument 메소들이나 클래스를 다이나믹하게 릴로드할때, 새로운 바이트코드는
오래된 버전이 이미 컴파일되어 있다고 하더라도 일반적으로 얼마동안 인터프리터되서 존재할 거야. 그리고,
모든 새로운 바이트코드의 일부를 보게되면, 일반적으로 JVM은 그것이 “hot” 한지 아닌지를 결정하는데
얼마간의 시간을 소비하게 되지.

이건 말이지 모든 현대의 JVM 실행에서 bytecode interpretation 을 찾을 수 있다는 것을 의미해.
만약 니가 그것을 호출했을 시에 모든 메소드를 컴파일된 네이티브코드로 존해하길 원한다면 커맨드라인에서
-Xcomp 를 지정해주면 돼. 그렇지만 나는 진심으로 이 방법을 추천하지 않아.
오늘날 JVM들은 충분히 똑똑하다구.