ReservedCodeCacheSizeおよびInitialCodeCacheSizeとは何ですか？

Question 1

誰かがJVMオプションReservedCodeCacheSizeとInitialCodeCacheSizeは何かを説明できますか？具体的には、いつ/なぜ変更したいのですか？適切なサイズを決定するにはどうすればよいですか？

これはドキュメントが言うことです：

-XX：ReservedCodeCacheSize = 32m予約済みコードキャッシュサイズ（バイト単位）-最大コードキャッシュサイズ。[Solaris 64ビット、amd64、および-server x86：2048m; 1.5.0_06以前では、Solaris 64ビットおよびand64：1024m。]

Question 2

ReservedCodeCacheSize（およびInitialCodeCacheSize）は、Java Hotspot VMの（ジャストインタイム）コンパイラのオプションです。基本的に、コンパイラのコードキャッシュの最大サイズを設定します。

キャッシュがいっぱいになる可能性があり、その結果、次のような警告が発生します。

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

Indeedエンジニアリングチームからの優れた学習経験と、jdk8に移行するときに直面した課題。

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

結論：Jdk8はJDK7よりも多くのコードキャッシュを必要とします

JRE 8のデフォルトのコードキャッシュサイズは約250MBで、JRE 7のデフォルトの48MBの約5倍です。私たちの経験では、JRE8には追加のコードキャッシュが必要です。これまでに約10個のサービスをJRE8に切り替えましたが、それらすべてが以前の約4倍のコードキャッシュを使用しています。

Question 5

https://blogs.oracle.com/poonam/entry/why_do_i_get_messageから：

以下は、CodeCacheフラッシュに関するjdk7u4 +の2つの既知の問題です。

緊急フラッシュ後にCodeCacheの占有率がほぼ半分に低下した後でも、コンパイラが再起動されない場合があります。

緊急フラッシュにより、コンパイラスレッドによるCPU使用率が高くなり、全体的なパフォーマンスが低下する可能性があります。

このパフォーマンスの問題、およびコンパイラが再度有効にならない問題は、JDK8で対処されています。JDK7u4 +でこれらを回避するには、ReservedCodeCacheSizeオプションを使用して、コードキャッシュがいっぱいにならないように、コンパイル済みコードのフットプリントよりも大きい値に設定して、コードキャッシュサイズを増やすことができます。これに対する別の解決策は、-XXを使用してCodeCacheフラッシュを無効にすることです。-UseCodeCacheFlushingJVMオプション。

上記の問題は、JDK8とそのアップデートで修正されています。

そのため、JDK 6（コードフラッシュが無効になっている）および7で実行されているシステムについて言及する価値があるかもしれません。