Method inlining and deoptimization
Posted 2008. 5. 22. 04:18axis님이 HotSpot Server JVM의 성능 이야기를 하면서 언급하신 공격적인 method inlining과 deoptimization에 대한 이야기를 하려 합니다. 관련 내용은 The Java HotSpot Performance Engine: Method Inlining Example에 이미 잘 정리되어 있습니다.
간단히 정리하면, HotSpot JVM은 final로 선언되어서 서브클래싱될 수 없는 메서드 뿐만 아니라 일반 메서드도 공격적으로 inlining 했다가 서브클래스가 런타임에 로드되면 이를 확인해서 inlining 된 메서드를 도로 푸는(deoptimize)하는 방법을 사용합니다.
런타임에 컴파일하기 때문에 최적화가 가능한 상황을 표시해두고 최적화한 다음에, 그 가정이 깨어지면 최적화를 푸는 방법이 인상적입니다. 컴파일 타임에 모든 결정을 해야 하는 정적인 컴파일러는 할 수 없는 최적화 방법이기도 합니다.
간단히 정리하면, HotSpot JVM은 final로 선언되어서 서브클래싱될 수 없는 메서드 뿐만 아니라 일반 메서드도 공격적으로 inlining 했다가 서브클래스가 런타임에 로드되면 이를 확인해서 inlining 된 메서드를 도로 푸는(deoptimize)하는 방법을 사용합니다.
inlining의 장점
1) 메서드 콜 오베헤드가 없다
2) dynamic dispatch 오버헤드가 없다
3) constantn folding이 추가로 가능하다. 예를 들어, a.foo() + 2가 있을 때 a.foo()가 3으로 inling되면 3 + 2 = 5로 constant folding이 가능하기 때문이다.
1) 메서드 콜 오베헤드가 없다
2) dynamic dispatch 오버헤드가 없다
3) constantn folding이 추가로 가능하다. 예를 들어, a.foo() + 2가 있을 때 a.foo()가 3으로 inling되면 3 + 2 = 5로 constant folding이 가능하기 때문이다.
런타임에 컴파일하기 때문에 최적화가 가능한 상황을 표시해두고 최적화한 다음에, 그 가정이 깨어지면 최적화를 푸는 방법이 인상적입니다. 컴파일 타임에 모든 결정을 해야 하는 정적인 컴파일러는 할 수 없는 최적화 방법이기도 합니다.
- Filed under : 카테고리 없음
