Co to są ReservedCodeCacheSize i InitialCodeCacheSize?

86

Czy ktoś może wyjaśnić, jakie są opcje JVM ReservedCodeCacheSizei jakie InitialCodeCacheSizesą? W szczególności, kiedy / dlaczego miałbym chcieć to zmienić? Jak zdecydować, jaki jest właściwy rozmiar?

Oto, co mówią doktorzy:

-XX: ReservedCodeCacheSize = 32m Zarezerwowany rozmiar pamięci podręcznej kodu (w bajtach) - maksymalny rozmiar pamięci podręcznej kodu. [Solaris 64-bitowy, amd64 i -server x86: 2048m; w wersji 1.5.0_06 i wcześniejszych, Solaris 64-bit i and64: 1024m.]

java jvm jvm-hotspot Raghu
źródło
2
OP tego postu napisał:> -XX: ReservedCodeCacheSize = 32m Rozmiar pamięci podręcznej zarezerwowanego kodu (w bajtach) - maksymalny rozmiar pamięci podręcznej kodu. [Solaris 64-bitowy, amd64 i -server x86: 48 m; w wersji 1.5.0_06 i wcześniejszych, Solaris 64-bit i 64: 1024m.] Chcę tylko poprawić, że wspomniany górny limit na 48 m musi być literówką. Jest 2048 m.
Lasse Aagren

Odpowiedzi:

73

ReservedCodeCacheSize(i InitialCodeCacheSize) jest opcją dla kompilatora (just-in-time) maszyny wirtualnej Java Hotspot. Zasadniczo ustawia maksymalny rozmiar pamięci podręcznej kodu kompilatora.

Pamięć podręczna może się zapełnić, co powoduje ostrzeżenia, takie jak następujące:

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

Jest znacznie gorzej, gdy następuje Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated.

Kiedy ustawić tę opcję?

  1. w przypadku awarii kompilatora Hotspot
  2. aby zmniejszyć ilość pamięci wymaganej przez JVM (a tym samym ryzyko awarii kompilatora JIT)

Zwykle nie zmieniałbyś tej wartości. Myślę, że wartości domyślne są dość dobrze wyważone, ponieważ te problemy występują tylko w bardzo rzadkich przypadkach (w moim doświadczeniu).

jeha
źródło
1
Ładny. Jakie są wartości domyślne i do czego należy je zwiększyć, jeśli zobaczymy komunikat „CodeCache jest pełny”. ostrzeżenie?
axel22,
3
@ axel22: Wartości w rzeczywistości zależą od platformy i wersji JVM; wartości z dokumentacji Sun JVM: Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and amd64: 1024m.]Nie znam wartości OpenJDK. Umiarkowany wzrost powinien być wystarczający (wcześniejsze ustawienie 1024 m było poza dobrem i złem).
jeha
12

@jeha odpowiada na wszystko, co chciałem wiedzieć z tego pytania, poza tym, na jaką wartość ustawić parametry. Ponieważ nie napisałem kodu, który wdrażałem, nie miałem dużego wglądu w ilość pamięci, którą miał.

Możesz jednak użyć jconsole, aby podłączyć się do uruchomionego procesu Java, a następnie użyć karty „Pamięć”, aby sprawdzić rozmiar pamięci podręcznej kodu. Aby uzyskać kompletność, kroki są następujące (środowisko Linux VM, chociaż jestem pewien, że inne środowiska są podobne):

  1. Uruchom jconsole na swoim komputerze
  2. Znajdź właściwy identyfikator procesu i dołącz do niego konsolę jconsole (zajmie to kilka chwil)
  3. Przejdź do zakładki „Pamięć”
  4. Z listy rozwijanej „Chart:” wybierz opcję „Memory Pool” Code Cache ”

  5. Ponownie, może to zająć kilka chwil, zanim ekran się odświeży, a następnie powinieneś zobaczyć coś takiego: Obraz pamięci podręcznej kodu jconsole

    Jak widać, moja pamięć podręczna kodu zajmuje około 49 MB. W tym momencie nadal miałem wartość domyślną, która według dokumentacji (i @jeha) wynosi 48 MB. Z pewnością była to dla mnie wielka motywacja do zwiększenia oprawy!

    Ben.

    Domyślnie 1024 MB prawdopodobnie było przesadzone, ale domyślnie 48 MB wydaje się to robić za mało ...

Zwierzę451
źródło
Dobra sugestia .... Próbuję z -J-XX: ReservedCodeCacheSize =
512m
Netbeans nie wystartował z 512 m, zrobił z 256 m
MarcoZen
Po testach przez około 2 dni mogę powiedzieć, że ustawienie nie wykazało żadnej / żadnej zauważalnej poprawy, a zamiast tego spowodowało, że fasola była pijana. Skończyło się na tym, że po prostu go usunąłem.
MarcoZen
3

Dobre doświadczenie zdobyte przez zespół inżynierów Indeed i wyzwania, jakie napotkali podczas migracji do jdk 8.

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

Wniosek: JDK 8 potrzebuje więcej pamięci podręcznej kodu niż JDK 7

Domyślny rozmiar pamięci podręcznej kodeków dla środowiska JRE 8 wynosi około 250 MB, czyli około pięć razy większy niż domyślny 48 MB dla środowiska JRE 7. Z naszego doświadczenia wynika, że ​​środowisko JRE 8 potrzebuje tego dodatkowego bufora kodeków. Jak dotąd przerzuciliśmy około dziesięciu usług na JRE 8 i wszystkie używają około czterokrotnie więcej kodeków niż poprzednio.

vsingh
źródło
0

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

Poniżej przedstawiono dwa znane problemy w jdk7u4 + związane z opróżnianiem CodeCache:

  1. Kompilator może nie zostać ponownie uruchomiony, nawet gdy zajętość CodeCache spadnie do prawie połowy po awaryjnym opróżnieniu.
  2. Opróżnianie awaryjne może spowodować wysokie użycie procesora przez wątki kompilatora, co prowadzi do ogólnego pogorszenia wydajności.

Ten problem z wydajnością i problem polegający na tym, że kompilator nie jest ponownie włączany, został rozwiązany w JDK8. Aby obejść te problemy w JDK7u4 +, możemy zwiększyć rozmiar pamięci podręcznej kodu za pomocą opcji ReservedCodeCacheSize, ustawiając ją na wartość większą niż ślad skompilowanego kodu, tak aby CodeCache nigdy się nie zapełniło. Innym rozwiązaniem tego problemu jest wyłączenie opróżniania CodeCache za pomocą opcji -XX: -UseCodeCacheFlushing JVM.

Powyższe problemy zostały naprawione w JDK8 i jego aktualizacjach.

Dlatego warto wspomnieć o tych informacjach w przypadku systemów działających na JDK 6 (z wyłączonym opróżnianiem kodu) i 7.

Andre Steingress
źródło