인라인 캐싱
Inline caching인라인 캐싱은 일부 언어 런타임에 사용되는 최적화 기술로,[1] Smalltalk용으로 처음 개발되었습니다.인라인 캐싱의 목적은 콜사이트에서 직접 이전 메서드룩업 결과를 기억함으로써 런타임 메서드바인딩을 고속화하는 것입니다.인라인 캐싱은 특히 모든 메서드바인딩이 런타임에 이루어지며 가상 메서드테이블을 사용할 수 없는 동적 타입의 언어에서 유용합니다.
런타임 메서드 바인딩
다음 ECMAScript 함수는 오브젝트를 수신하고 그 toString 메서드를 호출하여 스크립트가 포함된 페이지에 결과를 표시합니다.
기능. 버리다(obj) { 문서.쓰다(obj.문자열()); } 오브젝트 타입은 지정되지 않았으며 메서드 오버로드가 발생할 수 있기 때문에 toString 메서드의 구체적인 구현은 사전에 결정할 수 없습니다.대신 런타임에 동적 조회를 수행해야 합니다.어떤 형식의 캐시를 사용하지 않는 언어 런타임에서는 메서드가 호출될 때마다 이 검색이 수행됩니다.상속 체인에서 여러 단계를 거쳐 메서드를 정의할 수 있으므로 동적 룩업은 비용이 많이 드는 작업이 될 수 있습니다.
더 나은 성능을 달성하기 위해 많은 언어 런타임은 제한된 수의 메서드 룩업 결과가 관련 데이터 구조에 저장되는 일종의 비인라인 캐싱을 사용합니다.실행되는 프로그램이 "캐시 프렌들리"(즉, 자주 호출되는 메서드 집합이 제한됨)인 경우 성능이 크게 향상될 수 있습니다.이 데이터 구조는 일반적으로 첫 번째 수준 메서드 검색 [1]캐시라고 합니다.
인라인 캐싱
인라인 캐싱의 개념은 특정 콜사이트에서 발생하는 객체가 같은 타입인 경우가 많다는 경험적 관찰에 기초하고 있습니다.이 경우 메서드 룩업 결과를 인라인, 즉 콜 사이트에 직접 저장함으로써 성능을 크게 높일 수 있다.이 프로세스를 용이하게 하기 위해 콜사이트에는 다른 상태가 할당되어 있습니다.처음에 콜 사이트는 "초기화되지 않은" 것으로 간주됩니다.언어 런타임은 초기화되지 않은 특정 콜사이트에 도달하면 다이내믹룩업을 실행하여 콜사이트에 결과를 저장하고 상태를 "단일형"으로 변경합니다.언어 런타임이 다시 같은 콜사이트에 도달하면 콜사이트에서 착신자를 취득하여 더 이상의 룩업을 실행하지 않고 직접 호출합니다.같은 콜 사이트에서 다른 유형의 오브젝트가 발생할 가능성을 고려하기 위해 언어 런타임에서는 가드 조건도 코드에 삽입해야 합니다.대부분의 경우 이들은 콜사이트가 아닌 콜사이트의 프리암블에 삽입되어 브런치 예측을 보다 효과적으로 활용하고 각 콜사이트의 1개의 카피에 비해 프리암블 내의 1개의 카피에 의한 공간을 절약합니다.「모노믹」상태의 콜사이트가, 예기한 타입 이외의 타입을 검출했을 경우는, 「미초기화」상태로 되돌리고, 완전한 다이나믹 룩업을 재실행할 필요가 있습니다.
표준 구현은 콜 명령이 이어지는 상수의 레지스터 로드입니다."초기화되지 않은" 상태는 "연결 해제"라고 하는 것이 좋습니다.레지스터에는 메시지실렉터(일반적으로 일부 객체의 주소)가 로드되며, 콜은 위의 첫 번째 수준의 메서드룩업 캐시를 사용하여 현재 리시버의 클래스에서 메시지를 검색하는 런타임루틴입니다런타임 루틴은 명령어를 고쳐 쓰고 현재 수신기의 타입으로 레지스터를 로드하도록 로드 명령을 변경하고 타깃 메서드의 프리암블을 호출하도록 콜 명령을 변경하여 콜 사이트를 타깃 메서드에 "링크"합니다.그런 다음 프리암블 직후에 실행을 계속합니다.이후 실행에서는 프리암블을 직접 호출합니다.프리암블은 현재 리시버의 유형을 도출하여 레지스터 내의 리시버와 비교합니다.리시버가 같은 타입이며 메서드가 계속 실행됩니다.그렇지 않은 경우 프리암블은 다시 런타임에 콜을 발신하고 새로운 리시버 타입의 콜사이트를 재링크하는 등 다양한 전략을 사용할 수 있습니다.
성능 향상은 적어도 첫 번째 수준의 메서드 룩업 캐시에 대한 유형 비교 및 셀렉터 비교 대신 한 가지 유형 비교를 수행하고 메서드 룩업 또는 vtable 디스패치에서의 간접 호출이 아닌 직접 호출(명령 프리페치 및 파이프라인의 이점을 얻을 수 있음)을 사용하는 것으로부터 얻을 수 있습니다.
단형 인라인 캐싱
특정 콜 사이트에서 다른 유형의 오브젝트가 자주 검출되는 경우 인라인 캐싱의 퍼포먼스 이점은 콜사이트 상태의 빈번한 변화로 인한 오버헤드에 의해 쉽게 무효가 됩니다.다음 예시는 단일 동형 인라인캐싱의 최악의 시나리오를 설정하고 있습니다.
변화하다 가치 = [1, "a", 2, "b", 3, "c", 4, "d"]; 위해서 (변화하다 i 에서 가치) { 문서.쓰다(가치[i].문자열()); } 이 경우에도 toString 메서드는 사전에 유형을 알 수 없는 개체에서 호출됩니다.그러나 더 중요한 것은 오브젝트 유형이 주변 루프가 반복될 때마다 변한다는 것입니다.따라서 단형 인라인 캐싱의 단순한 구현은 "초기화되지 않은" 상태와 "단형" 상태를 지속적으로 순환시킵니다.이를 방지하기 위해 모노모픽 인라인캐싱의 대부분의 구현에서는 종종 "메가모픽" 상태라고 불리는 세 번째 상태를 지원합니다.이 상태는 특정 콜사이트에서 미리 정해진 수의 다른 타입이 검출되었을 때 시작됩니다.콜 사이트가 「메가모픽」상태가 되면, 그 사이트는 「초기화되지 않은」상태에서와 같이 동작합니다.다만, 「모형」인라인 캐싱의 일부의 실장에서는, 「메가모픽」콜 사이트를 「초기화되지 않은」상태로 되돌립니다.d 또는 완전한 가비지 수집 사이클이 실행되면).
폴리모픽 인라인캐싱
한정된 수의 다른 타입을 자주 볼 수 있는 콜사이트를 보다 효율적으로 처리하기 위해 일부 언어 런타임에서는 폴리모픽인라인 [2]캐싱이라고 불리는 기술을 사용합니다.폴리모픽 인라인캐싱을 사용하면 '모노믹' 상태에 있는 콜사이트는 '미초기화' 상태로 돌아가는 것이 아니라 '폴리모픽'이라는 새로운 상태로 전환됩니다.「다형」콜 사이트는, 현재 표시되고 있는 타입에 근거해, 호출할 수 있는 기존의 메서드의 한정 세트 중 어느 것을 결정합니다.즉, 다형 인라인캐싱을 사용하면 동일한 콜사이트에서 여러 메서드룩업 결과를 기록할 수 있습니다.프로그램 내의 모든 콜사이트는 시스템 내의 모든 유형을 볼 수 있기 때문에 보통 각 콜사이트에서 기록되는 검색 결과의 수에 상한이 있습니다.상한에 도달하면 콜사이트는 '메가모픽'이 되어 인라인캐싱은 실행되지 않습니다.
표준 구현은 리시버 유형을 도출하는 프리암블과 각 리시버 유형에 대한 관련 방법의 프리암블에 이어 코드로 점프하는 일련의 상수 비교 및 조건부 점프로 구성된 점프 테이블입니다.점프 테이블은 일반적으로 단일 동형 콜사이트가 다른 유형을 만났을 때 특정 콜사이트에 할당됩니다.점프 테이블은 크기가 고정되어 확장 가능하며 새로운 유형의 케이스가 4, 6, 또는 8과 같은 소수의 최대 케이스 수까지 추가될 수 있습니다.새로운 리시버 타입의 최대 사이즈 실행에 도달하면, 엔드가 「폴오프」되어 런타임에 들어갑니다.일반적으로 첫 번째 수준의 메서드캐시부터 시작하는 메서드룩업을 수행합니다.
그 관찰이 모이고, 다형성 불변태의. 인라인 캐시 프로그램 execution[2]적응할 수 있는 최적화 셀프, 런타임은 프로그램 인라인 캐시에서 추측성을 인지하기 위해 형식 정보를 사용하게"핫 스팟"최적화한 발전을 이룩한 최적화의 여파로per-call-site 수신기 형식 정보를 수집합니다.에서라이닝 결정
메가모픽 인라인캐싱
런타임에서 모노모픽과 폴리모픽 인라인캐시를 모두 사용하는 경우 정상 상태에서는 링크되지 않은 송신만이 폴리모픽인라인 캐시의 끝에서 송신되는 송신입니다.이러한 전송 속도는 느리기 때문에 이제 이러한 사이트를 최적화하는 것이 이득이 될 수 있습니다.메가모픽 인라인 캐시는 특정 콜사이트에 대해 제1레벨 메서드룩업을 실행하는 코드를 작성함으로써 구현할 수 있습니다.이 방식에서는 송신 폴리오픽인라인 캐시의 말단에서 떨어지면 콜사이트의 셀렉터에 고유한 메가모픽캐시가 작성(또는 이미 존재하는 경우는 공유)되어 송신사이트가 다시 링크되어 콜이 됩니다.실렉터가 상수이기 때문에 일반적인 첫 번째 수준의 메서드 룩업프로브보다 코드가 훨씬 효율적일 수 있습니다.그 결과 레지스터의 압력이 낮아지고 룩업 및 디스패치용 코드가 런타임에 호출되지 않고 실행되며 디스패치가 브랜치 예측의 이점을 얻을 수 있습니다.
경험적 측정 결과, 대형 Smalltalk 프로그램에서는 전체 send site의 약 1/3이 활성 방법으로 연결되지 않은 상태로 남아 있으며, 나머지 2/3 중 90%는 단형, 9%는 다형, 1%(0.9%)는 메가모픽으로 나타났다.
