Programing

ReservedCodeCacheSize 및 InitialCodeCacheSize는 무엇입니까?

crosscheck 2020. 10. 6. 07:53
반응형

ReservedCodeCacheSize 및 InitialCodeCacheSize는 무엇입니까?


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

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

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


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.

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

  1. 핫스팟 컴파일러 오류가 발생하는 경우
  2. JVM에 필요한 메모리 감소 (따라서 JIT 컴파일러 실패 위험)

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


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

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

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

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

    벤.


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


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

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

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

The default codecache size for JRE 8 is about 250MB, about five times larger than the 48MB default for JRE 7. Our experience is that JRE 8 needs that extra codecache. We have switched about ten services to JRE 8 so far, and all of them use about four times more codecache than before.


from https://blogs.oracle.com/poonam/entry/why_do_i_get_message:

The following are two known problems in jdk7u4+ with respect to the CodeCache flushing:

  1. The compiler may not get restarted even after the CodeCache occupancy drops down to almost half after the emergency flushing.
  2. The emergency flushing may cause high CPU usage by the compiler threads leading to overall performance degradation.

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

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

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

참고 URL : https://stackoverflow.com/questions/7513185/what-are-reservedcodecachesize-and-initialcodecachesize

반응형