2016-12-14 2 views
1

나는 on-stack replacement (OSR)이 일반적으로 어떻게 작동하는지 이해하지만 컴파일을 트리거 한 초기 호출을 떠나면 OSR 컴파일 된 메소드가 유용할지 여부를 이해하지 못한다. JITed 코드를 후속 반복에서 사용할 수 있습니까? ?후속 호출에서 OSR로 컴파일 된 메서드를 사용할 수 있습니까?

마치 인터프리터가 이전 OSR이 시작한 것과 동일한 바이트 코드 색인으로 진행되면 다시 OSR 컴파일 된 방법을 입력 할 수 있습니다.

핫스팟이 OSR이 다른 방법으로 두 번 (다른 BCI의 경우) 두 번 컴파일하는 경우를보고 있지만 보통 C2 비 -OSS 컴파일을 수행하지 않는 경우를 보았습니다. 몇 분 (방법에 백만개의 외침 또는 더 많은 것에도 불구하고). 그래서 그 동안 OSR C2 방법을 사용하고 있는지 궁금합니다 (비 OSR C1 방법도 있습니다)?

답변

1

예, 재사용 할 수 있습니다. 그러나 생성 된 동일한 바이트 코드 색인에서만, 컴파일 정책의 다시 분기 이벤트에 대한 응답으로 만 사용됩니다.

HotSpot InstanceKlass 구조체 (Java 클래스의 내부 표현)는 해당 클래스에 대해 list of OSR methods을 유지합니다. 컴파일이 요청 될 때마다 CompileBroker looks for이 목록에있는 기존 NMethod.

자세히 살펴 보지 않으면 특별한 사례에 대해 많이 알 수 없지만 제공된 설명에서 응용 프로그램이 C1- 컴파일 된 버전을 호출하는 것으로 의심됩니다. 메서드의 진입 점이 OSR로 컴파일 된 NMethod로 설정되지 않습니다.

+0

예, 결국 재현하지 못했습니다. 나중에 실행하면 대부분의 비 OSR C2 (레벨 4) 컴파일이 시작 후 2 분 내에 컴파일되므로 어떤 방법으로 일어나 있었다. 아마도 _Timing_이 실행 중임을 나타내는 것 같으므로 LogCompilation 출력의 결함 (예 : PrintAssembly이 동시에 작성 했습니까?)이 원인 일 수 있습니다. – BeeOnRope

+0

위의 "생성 된 동일한 바이트 코드 ** 인덱스 **에서"라는 뜻입니까? – BeeOnRope

+0

@BeeOnRope 네, 고마워요. – apangin

관련 문제