개발자들은 메서드나 클래스의 가장 성능이 뛰어난 구현체를 선택하기 위해 종종 마이크로벤치마크 (Microbenchmarks)를 사용합니다. Java Virtual Machine (JVM)에서는 JVM 상의 코드 성능을 측정할 때 발생하는 일반적인 함정들을 해결해 주는 Java Microbenchmark Harness (JMH)를 사용하여 이를 흔히 수행합니다. 하지만 JMH 가이드라인을 사용하더라도 컨텍스트 (context)라는 근본적인 문제는 극복할 수 없습니다. 마이크로벤치마크는 본질적으로 캐시 (cache)나 분기 예측기 (branch-predictor) 용량과 같이 CPU 자원을 두고 경쟁하는 다른 애플리케이션 코드의 간섭 없이 코드를 격리된 상태에서 실행합니다. JVM과 같이 계층적 동적 컴파일 (tiered dynamic compilation)을 사용하는 관리형 런타임 (managed runtimes)에서는, 컴파일 결정의 추측적이고 프로파일 기반적인 (speculative, profile-driven) 특성 때문에 코드 성능이 초기 실행 중에 수집된 프로파일 (profiles)에 크게 의존하게 됩니다. 프로파일에는 일반적으로 코드의 핫니스 (hotness) 지표 외에도 분기 확률 (branch probabilities) 및 수신자 타입 (receiver types)이 포함되기 때문에, 잘못 설계된 마이크로벤치마크는 JVM이 비현실적인 프로파일을 수집하게 만들어 실제 애플리케이션에서는 발생하지 않을 공격적이면서도 오해를 불러일으키는 최적화 (optimizations)를 초래할 수 있습니다. 본 논문에서는 JVM이 비현실적인 프로파일을 수집하도록 유도하는 조건에서 마이크로벤치마크를 사용할 경우, 기존 가이드라인을 따르더라도 어떻게 오해를 불러일으키는 결과가 도출되는지를 입증합니다. 또한, 우리는 마이크로벤치마크 결과가 더욱 대표성을 가질 수 있도록 조치를 제안함으로써 이러한 가이드라인을 확장합니다.