私は会社の大きなJava/KOTLINプロジェクトで働いています.それは数百万のサーバー側のコードです.そして、何百万もより多くの依存関係を通して来ます.Kotlinコンパイラは確かにその仕事をカットしている.しかし、最近では、プロジェクトのソースサイズがほぼ同じ速度で成長していなかったとしても、コンパイラは遅くなってきていた.また、ビルドは豊富なCPUリソースを消費していました.ビルドの時間をフルプロジェクトビルドの約2分から10分以上に増加していた.何か間違いなく間違っていた.
数日前、バブル全体が破裂し、何が起こっているかをはっきりと明らかにした.

java.lang.OutOfMemoryError: GC Overhead Limit Exceeded

... Kotlinコンパイラクラスから来るそうではないことがわかったkotlinc 私たちのCPUを燃やしていた自分自身-それは、メモリリソースを解放するために本当に苦労して、それが実行されていたJVMだった.
質問は明らかにありました:どのように、より多くのRAMをkotlinc プロセス?口は重宝手は宝.

セットアップ

他の多くの人々のように、我々はソースコードを書くためにIntellijアイデアを使用します.何も複雑な、何も?閉じるこの動画はお気に入りから削除されています.

ここでは、各ステップ(大まかな)は何ですか

IntelliJ :我々のIDE.基本的には./gradlew compile と出力を監視します.

gradlew : Gradleラッパー.Gradle(ビルドで指定された)の希望するバージョンをダウンロードし、この特定のGradleバージョンに与えた引数を渡します.

Gradle :実際のGradleの実行可能ファイルです.ここでcompileKotlin 呼び出しが評価され、タスクはGradleデーモンに渡される(既に実行されていない場合に開始される).

Gradleデーモン:Gradleによって作成されたバックグラウンドワーカー.ここで実際のヘビーリフトが行われます.

Kotlinc:実際のKotlinコンパイラ.

ここで実現する2つの重要なことがあります.

Gradle、Intellij、およびKotlincはすべて、JVMの上に実装されています.

それぞれのプロセスは独自のJVMインスタンスで実行されます.オペレーティングシステムの観点から、それらは異なったプロセスである.

ここでの結論は、Intellijのアイデアにどれだけのメモリを割り当てても、ビルド時にKotlincに利用可能なRAMの量を変更しないことです.また、Gradleが独自のプロセスであるので、Gradleにあなたがどれだけの記憶を与えるかに関係なく、それはそれから利益を得ません.

フィックス

これまでに集められたすべての洞察力で、この質問は、Kotlincプロセスにメモリを割り当てる方法のままです.私たちのために、以下のように働いた.

org.gradle.jvmargs=-Xmx8g -Dkotlin.daemon.jvm.options=-Xmx6g

この行をファイル名にしますgradle.properties , どれが我々のすぐ隣にありますかgradlew 実行可能(SO、プロジェクトのトップレベル).これは、8 GBのRAMをGradleプロセスに割り当てます.また、もう一つの6 GBはKotlinコンパイラ専用です.
もちろん、数字で遊ぶことができます.それがコールするかどうかは、Koltlin Gradleプラグインの実装の詳細ですkotlinc スタンドアローンのプロセスとして埋め込まれたので、私は防御オプションを取り、より多くのRAMをGradlekotlinc , しかし、他の設定も同様に機能します.

A note of caution: if you assign more RAM to a JVM via -Xmx than your OS can actually provide to it, it may fail with a segmentation fault. Never assign more RAM than you actually have.

さて、ファイル内のこれらのプロパティを変更して保存した場合、コールトコンパイラはまだ遅くなり、メモリ不足になる可能性があります.それは、あなたのGradleデーモンがまだバックグラウンドで実行しているかもしれないので、以前の設定を使用しているからです.また、Intellijは豊富なキャッシュを持っています.あなたの変更が実際に効果的であることを確認するためのsurefire方法は以下の通りです.

マシンを再起動します.そうです.これはgradleデーモンを殺します.

Intellijを起動します.

Intellijの内部では、まだ「ビルド」をクリックしないでください.あなたのGradle設定は永続的なキャッシュから提供されるかもしれません.代わりに、Gradleプロジェクトを最初に更新します.

一旦リフレッシュが完了すると、intellijから完全なプロジェクト再構築を実行してください.

結果

私たちのビルドは、今より速く再びです!我々は、より多くの合理的なCPUの負荷で、100分のCPUで10分以上1分未満に戻った.変更はビルドセットアップで行われたので、私たちのCI/CDサーバーのビルドは、現在も速くなります.

Note: This procedure works for Kotlin/JVM for a server-side project built by gradle. It may or may not work for Android builds, Kotlin/JS, Kotlin/Native or multiplatform projects.

結論

コールインがコンパイルされている間、あなたのコールインが彼らがそうするべきであるより長い方法をとるならば、そして、あなたのCPUはすべてのコアに夢中になります.メモリ上で動作している可能性があります.