ReservedCodeCacheSize 및 InitialCodeCacheSize는 무엇입니까?

Question 1

누군가가 어떤 JVM 옵션을 설명해 주시겠습니까 ReservedCodeCacheSize하고 InitialCodeCacheSize있습니까? 특히 언제 / 왜 변경하고 싶습니까? 올바른 크기가 무엇인지 어떻게 결정합니까?

이것은 문서가 말하는 것입니다.

-XX : ReservedCodeCacheSize = 32m 예약 된 코드 캐시 크기 (바이트)-최대 코드 캐시 크기입니다. [Solaris 64 비트, amd64 및 -server x86 : 2048m; 1.5.0_06 이하, Solaris 64 비트 및 64 : 1024m.]

Question 2

ReservedCodeCacheSize(및 InitialCodeCacheSize)은 Java Hotspot VM의 (just-in-time) 컴파일러에 대한 옵션입니다. 기본적으로 컴파일러의 코드 캐시에 대한 최대 크기를 설정합니다.

캐시가 가득 차서 다음과 같은 경고가 표시 될 수 있습니다.

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
Code Cache  [0x000000010958f000, 0x000000010c52f000, 0x000000010c58f000)
 total_blobs=15406 nmethods=14989 adapters=362 free_code_cache=835Kb largest_free_block=449792

뒤에 오는 경우 훨씬 더 나쁩니다 Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.

이 옵션을 언제 설정해야합니까?

핫스팟 컴파일러 오류가 발생하는 경우
JVM에 필요한 메모리를 줄이기 위해 (따라서 JIT 컴파일러 실패 위험)

일반적으로이 값은 변경하지 않습니다. 이 문제는 매우 드문 경우에만 발생하기 때문에 기본값이 균형이 잘 잡혀 있다고 생각합니다 (제 경험상).

Question 3

@jeha는 매개 변수를 설정할 값을 제외 하고이 질문에서 알고 싶은 모든 것에 대답합니다. 내가 배포하는 코드를 작성하지 않았기 때문에 그것이 가지고있는 메모리 풋 프린트에 대한 가시성이별로 없었습니다.

그러나 jconsole을 사용하여 실행중인 Java 프로세스에 연결 한 다음 '메모리'탭을 사용하여 코드 캐시 크기를 확인할 수 있습니다. 완전성을 위해 단계는 다음과 같습니다 (Linux VM 환경, 다른 환경도 유사하다고 확신합니다).

컴퓨터에서 jconsole 실행
올바른 프로세스 ID를 찾아 여기에 jconsole을 연결합니다 (몇 분 정도 소요됨).
'메모리'탭으로 이동
'차트 :'드롭 다운 목록에서 '메모리 풀 "코드 캐시"'를 선택합니다.
다시 말하지만 화면이 새로 고쳐지는 데 몇 분 정도 걸릴 수 있으며 다음과 같은 내용이 표시됩니다.

보시다시피 내 코드 캐시는 약 49MB를 사용하고 있습니다. 이 시점에서 나는 문서 (및 @jeha)가 48MB라고 말하는 기본값을 여전히 가지고 있습니다. 확실히 내가 설정을 높이는 데 큰 동기가되었습니다!

벤.

기본적으로 1024MB는 아마도 그것을 과장했지만 기본적으로 48MB는 그것을 과소하는 것 같습니다 ...

Question 4

인디 드 엔지니어링 팀의 좋은 학습 경험과 jdk 8로 마이그레이션 할 때 직면 한 과제.

http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/

결론 : Jdk 8은 JDK 7보다 더 많은 코드 캐시가 필요합니다.

JRE 8의 기본 코드 캐시 크기는 약 250MB로 JRE 7의 기본값 인 48MB보다 약 5 배 더 큽니다. JRE 8에는 추가 코드 캐시가 필요합니다. 지금까지 약 10 개의 서비스를 JRE 8로 전환했으며 모두 이전보다 약 4 배 더 많은 코드 캐시를 사용합니다.

Question 5

에서 https://blogs.oracle.com/poonam/entry/why_do_i_get_message :

다음은 CodeCache 플러시와 관련하여 jdk7u4 +에서 알려진 두 가지 문제입니다.

비상 플러시 후 CodeCache 점유율이 거의 절반으로 떨어진 후에도 컴파일러가 다시 시작되지 않을 수 있습니다.

긴급 플러싱으로 인해 컴파일러 스레드에서 CPU 사용량이 높아져 전체 성능이 저하 될 수 있습니다.

이 성능 문제와 컴파일러가 다시 활성화되지 않는 문제는 JDK8에서 해결되었습니다. JDK7u4 +에서 이러한 문제를 해결하기 위해 CodeCache가 가득 차지 않도록 컴파일 된 코드 풋 프린트보다 큰 값으로 설정하여 ReservedCodeCacheSize 옵션을 사용하여 코드 캐시 크기를 늘릴 수 있습니다. 이에 대한 또 다른 해결책은 -XX : -UseCodeCacheFlushing JVM 옵션을 사용하여 CodeCache 플러싱을 비활성화하는 것입니다.

위에서 언급 한 문제는 JDK8 및 해당 업데이트에서 수정되었습니다.

따라서 JDK 6 (코드 플러싱 비활성화 됨) 및 7에서 실행되는 시스템에 대해 언급 할 가치가 있습니다.