6か月が経過しました。つまり、 新しいJavaをインストールするときです。 長い旅でしたが、最後に到達した人はほとんどいませんでした。 未加工の行は興味深いJEPから外れましたが、残りの部分については説明します。

すべてはどうですか

Javaの新しいバージョンのリリースは、約6か月の長さの新しい「加速された」リリースサイクルに従って行われます。 正確な日付はプロジェクトページで定義されています 。 JDK 12にはいくつかの主要なフェーズがありました。

• 2018/12/13-減速の最初のフェーズ（この時点で、リポジトリのメインブランチから分岐が作成されます）。
• 2019/01/17-減速の第2フェーズ（可能なすべてを完了）;
• 2019/02/07-リリース候補（最も重要なバグのみが修正されています）;
• 2019/03/19-リリース、一般提供開始。 <-あなたはここにいます

このスケジュールから何が得られますか？ はい、実際のところ、何もありません。フィニッシュラインにたどり着いたばかりで、新しい新鮮なJDK 12の頂点からレガシーの愛好家を見守っています。

バグ！ パニック！ 一番下まで！

新しい非LTSバージョンがリリースされたとき、通常誰もが新機能について気にしません。 すべてが地獄に崩れるならもっと面白いです。

もちろん、多くのバグがありますが、JDK 12にはありません:) jirから判断すると、すべてが正常です。

「ノルム」とは何かを正確に理解できるように、リクエストを引用します。

project = JDK AND issuetype = Bug AND status in (Open, "In Progress", New) AND priority in (P1) AND (fixVersion in (12) OR fixVersion is EMPTY AND affectedVersion in (12) AND affectedVersion not in regexVersion("11.*", "10.*", "9.*", "8.*", "7.*", "6.*")) AND (labels is EMPTY OR labels not in (jdk12-defer-request, noreg-demo, noreg-doc, noreg-self)) AND (component not in (docs, globalization, infrastructure) OR component = infrastructure AND subcomponent = build) AND reporter != "Shadow Bug" ORDER BY priority, component, subcomponent, assignee 

もちろん、 一般的なバグにはあるべき場所がありますが、そのような巨大なプロジェクトではどこにも行きません。 現時点ではP1のバグに気付いていないというだけです。

バグとのより正式なコミュニケーションは、特別なドキュメントJEP 3：JDK Release Processで宣言されています。これは、Java Oceanの乱流に関する不滅のスチュワードであるMark Reinholdが所有しています。

特に、次のことを伝える段落を掘り下げる価値があります。 誰が責任を負い、何をすべきか 12回目のリリースの時間がない場合のチケットの転送方法。 Nがどのリリースから転送したいかを示すラベルjdk$N-defer-requestをバグトラッカーに入れ、コメントを残す必要があります。最初の行はDeferral Requestです。 さらに、そのようなすべての要求のレビューは、それぞれの分野およびプロジェクトのリードによって行われます。

TCKを渡す問題はこの方法では無視できません。JavaがJavaのままであり、カエルのようなものではないことが保証されます。 jdk$N-defer-request labelが消えることはありません。 タグを削除しないというルールに違反している人々に対して彼らが何をするかは興味深いです。モルモットに餌を与えることをお勧めします。

ただし、この方法では、JDK 13に移植されたバグの数を確認できます。このクエリを試してみましょう。

 project = JDK AND issuetype = Bug AND status in (Open, "In Progress", New) AND (labels in (jdk12-defer-request) AND labels not in (noreg-demo, noreg-doc, noreg-self)) AND (component not in (docs, globalization, infrastructure) OR component = infrastructure AND subcomponent = build) AND reporter != "Shadow Bug" ORDER BY priority, component, subcomponent, assignee 

JDK-8216039の 1ピースのみ：「BCおよびRSASSA-PSSを使用したTLSはECDHServerKeyExchangeを中断します」。 厚くない それでもこの議論が役に立たない場合は、弁護士として鎮静剤を試すことをお勧めします。

そして、一番下の行は何ですか？

ほとんどの機能がユーザー（Javaプログラマー）ではなく、OpenJDK自体の開発者に影響することは明らかです。 したがって、念のため、機能をexternalとinternalに分けます。 あなたは内部のものをスキップすることができますが、私は腹を立てています、私はたくさんのテキストを書きました。

189： シェナンドー：一時停止時間の短いガベージコレクター（実験的）

外部機能 。 要するに、特にSLAが10〜500ミリ秒のオーダーの応答性を必要とする場合、Javaの速度が低下すると、人々はそれを好まなくなります。 これで、この範囲の左端に近づくように動作する無料の低パンチGCができました。 トレードオフは、CPUとRAMを交換して待ち時間を短縮することです。 ヒップタグ付けと圧縮フェーズは、ライブアプリケーションスレッドと並行して動作します。 残りの小さな一時停止は、オブジェクトのグラフのルートを検索および更新する必要があるためです。

上記のいずれも意味をなさない場合、それは問題ではありません。シェナンドアは、基礎となるプロセスを理解しているかどうかに関係なく動作します。

Alexei Shipilev、Kristina Flood、Roman Kennkeが取り組んでいます。これらの人々について知らないように一生懸命努力する必要があります。 GCの仕組みを一般的に理解しているのに開発者が何ができるか想像していない場合は、素晴らしいLeshinaの記事「OpenJDK向けの自家製ガベージコレクター」またはJVM Anatomy Quarksシリーズのすばらしい翻訳をご覧になることをお勧めします。 これはとてもおもしろいです。

非常に重要です。 Oracleは、Shandoahのリリースビルドをjdk.java.netのものもoracle.comのものも含めて出荷しないことにしました。 ShenandoahはJDK 12の最も重要な機能の1つであるため、たとえばAzulからの公式アセンブリをインストールする価値があります。

230： Microbenchmark Suite

内部機能 。 マイクロベンチマークを作成しようとしたことがあるなら、これはJMHで行われていることがわかります。 JMHは、Javaおよび他のJVM言語のマイクロベンチマークを作成、アセンブル、実行、および分析するためのフレームワークであり、 誰がそれを書いたかを理解しています（すべての一致はランダムです）。 残念ながら、「通常の」アプリケーションの世界で行われているすべてがJDK内に適用できるわけではありません。 たとえば、通常のSpring Frameworkコードがそこに表示されることはほとんどありません。

幸いなことに、バージョン12以降、少なくともJMHを使用できます。また、JMHには一連のテストがすでに記述されています。 jdk/jdk/test/micro/org/openjdk/bench確認できます（ブラウザで直接確認できます。このパスはリンクです）。

たとえば、GCテストは次のようになります。

ここにStackOverflowがないことを思い出してください。 対応するファイルとOpenJDKプロジェクトのすべてのライセンスを読んで観察することなく、コピーアンドペーストのコードをここと以降で使用することは禁じられています。そうしないと、最後の靴下を簡単に入手できます。

 @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @State(Scope.Thread) public class Alloc { public static final int LENGTH = 400; public static final int ARR_LEN = 100; public int largeLen = 100; public int smalllen = 6; @Benchmark public void testLargeConstArray(Blackhole bh) throws Exception { int localArrlen = ARR_LEN; for (int i = 0; i < LENGTH; i++) { Object[] tmp = new Object[localArrlen]; bh.consume(tmp); } } //... } 

325：式の切り替え（プレビュー）

外部機能 。 これは、3画面以上の長さのエンドレススイッチを作成するアプローチを根本的に変更します。 見て：

Virgin Java Switch vs ...

 int dayNum = -1; switch (day) { case MONDAY: case FRIDAY: case SUNDAY: dayNum = 6; break; case TUESDAY: dayNum = 7; break; case THURSDAY: case SATURDAY: dayNum = 8; break; case WEDNESDAY: dayNum = 9; break; } 

悪い理由 ：文字がたくさんあるので、休憩をスキップできます（特に、あなたが中毒者であるか、ADHDにかかっている場合）。

... vs Chad Java Swtich Expression！

 int dayNum = switch (day) { case MONDAY -> 0; case TUESDAY -> 1; default -> { int k = day.toString().length(); int result = f(k); break result; } }; 

なぜ良いのか ：数文字、安全、便利、新しいクールな機能

ボーナス ：あなたがサディストなら、何千ものIDE開発者がこの機能のサポートに苦しんでいるので、それはあなたに最も深い満足を与えます。 はい、はい、はい？ 4月6日のレポートの後に彼を捕まえ、すべての汚れた詳細を丁寧に伝えるように頼むことができます。

これはプレビュー機能であり、機能しません。 コンパイル時には、 javacコマンドラインオプション--enable-preview --release 12を渡し、 javaを実行する必要があります（ --enable-previewフラグのみ）。

334： JVM定数API

内部機能 。 開発者はクラスファイルを操作する必要があります。 これを便利に行う必要があり、これが問題のステートメントです。 少なくとも、このJEPを所有しているブライアンゲッツはこう言っています:-)これらはすべて、より大きな戦場の一部ですが、今のところは深く入りません。

各Javaクラスには、いわゆる「定数プール」があり、いくつかの値（文字列や整数など）、またはクラスやメソッドなどのランタイムエンティティのダンプがあります。 ldc- "load costant"命令を使用してこのダンプを掘り下げることができるため、このすべてのジャンクはロード可能定数と呼ばれます。 invokedynamicにはまだ特別なケースがありますが、気にする必要はありません。

クラスファイルで作業する場合、バイトコード計器をシミュレートするのが便利です。したがって、ロード可能な定数です。 最初の欲求は、対応するJava型を単純に作成することですが、それらに「生きている」クラスであるCONSTANT_Class_info構造体を表示するにはどうすればよいですか？ Classオブジェクトは、クラスローディングの正確さと一貫性に依存し、Javaでのクラスのローディングにより、地獄のようなバチャナリアが作成されます。 そもそも、すべてのクラスをVMにロードできるわけではありませんが、それらを記述する必要があります！

クラス、メソッド、メソッドハンドルや動的定数などのあまり知られていない獣など、これらの微妙な点をすべて考慮して、何らかの形で管理したいと思います。

これは、 値に基づいた新しいタイプのシンボリックリンク（ JVMS 5.1の意味）を導入することで解決されます。各シンボリックリンクは、特定のタイプの定数を記述しています。 クラスのロードやアクセスの問題から分離して、純粋に名目上説明します。 彼らはjava.lang.invoke.constantようなパッケージに住んでいて、それを要求しませんが、 ここでパッチを見ることができます 。

340： 2つではなく1つのAArch64ポート
外部機能 。 すでにJDK 9では、OracleとRed Hatが同時にARMポートをアラート状態にするという奇妙な状況がありました。 そして、物語の終わりが見えます。オラクロフ港の64ビット部分が上流から削除されました。

長い歴史を掘り下げることは可能ですが、もっと良い方法があります。 BellSoftはこのJEPの開発に参加し、そのオフィスはサンクトペテルブルクのオラクルの旧オフィスの隣にあります。

したがって、すぐにBellSoftのCTOであるAlexey Voitilovに目を向けました。

「BellSoftは、x86 Linux / Windows / MacおよびSolaris / SPARCに加えて、ARMをサポートするLiberica JDKを起動します。ARM用JDK 9から、サーバーアプリケーションのAARCH64ポートのパフォーマンスの改善に焦点を当て、ARMポートの32ビット部分のサポートを継続しましたそのため、JDK 11のリリース時には、Oracle（Oracleを含む）の64ビットポート部分を誰もサポートしていない状況があり、OpenJDKコミュニティはAARCH64ポートに集中するために64ビットポート部分を削除することを決めました。参照、例えば、 JEP 315 、これは我々 JDK 12に統合されており、JDK 12以降、Oracleのポートにあるすべての機能をサポートしています（最後の機能、9月に統合したMinimal VM）。したがって、JDK 12でこの基本を削除できるようになりました。コミュニティはAARCH64の1つのポートと1つのARM32のポートを受け取りました。もちろん、サポートが容易になります。

341： デフォルトのCDSアーカイブ

内部機能 。 問題は、Javaアプリケーションの起動時に、数千のクラスがロードされるため、起動時にJavaが大幅に遅くなるという感覚を生み出します。 しかし、嘘をつくのは誰ですか、これは単なる「感覚」ではありません-そうです。 古代から問題を解決するために、さまざまな儀式が実践されています。

クラスデータの共有は、JDK 8 Update 40の商用機能のように、 太古から私たちにやってきた機能です。このスタートアップガベージをすべて、独自の形式のアーカイブにパックすることができます（どの形式かを知る必要はありません）。アプリケーションが増えています。 そしてしばらくして、 JEP 310が登場しました。アプリケーションクラスとデータの共有。これにより、システムクラスだけでなく、アプリケーションクラスも同じように扱うことができました。

JDKクラスの場合、次のようになります。 まず、 java -Xshare:dumpコマンドでクラスをダンプしてから、アプリケーションを実行して、このキャッシュを使用するように指示します： java -Xshare:on -jar app.jar 。 すべて、スタートアップは少し改善されました。 この機能について知っていましたか？ まだ知らない多くの人！

ここでは奇妙に見えます：なぜ毎回-Xshare:dump JDKディストリビューションを作成する段階でもこのコマンドのデフォルト結果がわずかに予測可能な場合、 -Xshare:dumpするのはなぜですか？ 文書によると、インストーラーを使用してJava 8ディストリビューションがインストールされた場合、インストール時に必要なコマンドを実行する必要があります。 同様に、インストーラーは隅々で静かに採掘しています。 しかし、なぜですか？ そして、インストーラーとしてではなく、zipファイルとして配布される配布をどうするか？

簡単です。JDK12以降、CDSアーカイブは、リンクの直後に配布キットの作成者によって生成されます。 ナイトビルドの場合でも（クロスコンパイル用ではなく、64ビットでネイティブである場合）。

JDK 11以降、デフォルトで-Xshare:auto有効になり、このようなアーカイブが自動的に-Xshare:autoため、ユーザーはこの機能の存在について知る必要さえありません。 したがって、 JDK 12に更新するだけで、アプリケーションの起動が高速化されます。

344： G1の中止可能な混合コレクション

内部機能 。 正直に言うと 私はG1の仕事で何も理解していません GCの機能の説明は、ありがたい仕事です。 説明者と理解の両方から彼の作品の詳細を理解する必要があります。 ほとんどの人にとって、GCは、何らかの場合にごまかすことができる嗅ぎタバコの一種の地獄です。 したがって、問題は何とか簡単に説明する必要があります。

問題 ：G1の方がうまくいくかもしれません。

問題は、GCが多くのパラメーターの妥協点であり、その1つが一時停止の長さであるということです。 一時停止が長すぎる場合があり、それをキャンセルできると便利です。

これはいつ起こりますか？ G1はアプリケーションの動作を実際に分析し、その結論に基づいて作業の最前線（ コレクションセットとして表される）を選択します。 作業範囲が承認されると、G1はコレクションセット内のすべての生きているオブジェクトを、頑固かつノンストップで一度に収集することを約束します。 時間がかかりすぎる場合があります。 本質的に、これはG1が作業量を誤って計算したことを意味します。 アプリケーションの振る舞いを突然変更することで、彼がだまされる可能性があります。これにより、コレクションセットに多くの古い領域が入ったときに、ヒューリスティックが不良データの上で動作するようになります。

状況から抜け出すために、G1は次のメカニズムによってファイナライズされました：ヒューリスティックが定期的に誤った作業量を選択する場合、G1はインクリメンタルガベージコレクションにステップバイステップで切り替え、次の各ステップ（ターゲット実行時間に収まらない場合）をキャンセルできます。 何かを少しずつ収集するのは理にかなっていない（若い地域）ので、そのような作業はすべて「必須」ブロックで強調表示され、引き続き継続的に実行されます。

エンドユーザーをどうしますか？ 何も、JDK 12にアップグレードする必要はありません。それ自体がすべて良くなります。

346： G1から未使用のコミット済みメモリを速やかに返す

内部機能 。 問題は、誰も積極的に使用していない大きなヒップがある場合、この非アクティブなメモリをすべてオペレーティングシステムに戻すことは公平に思えます。 ただし、JDK 12より前では、これは発生しませんでした。

一時停止の長さに関する目標を達成するために、G1はインクリメンタル、パラレル、およびマルチステージサイクルのセットを実行します。 JDK 11では、コミットされたメモリをオペレーティングシステムにフルGCでのみ、または並列マーキングフェーズ中に提供します。 ロギングを接続すると（-Xloggc：/home/gc.log -XX：+ PrintGCDetails -XX：+ PrintGCDateStamps）、このフェーズは次のように表示されます。

 8801.974: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: occupancy higher than threshold, occupancy: 12582912000 bytes, allocation request: 0 bytes, threshold: 12562779330 bytes (45.00 %), source: end of GC] 8804.670: [G1Ergonomics (Concurrent Cycles) initiate concurrent cycle, reason: concurrent cycle initiation requested] 8805.612: [GC concurrent-mark-start] 8820.483: [GC concurrent-mark-end, 14.8711620 secs] 

おもしろいことに、G1はできる限り完全な停止に苦労し、並行サイクルは頻繁な割り当てとヒープの詰まりでのみ開始されます。 私たちの状況は、誰も腰に触れていないとき、ちょうど反対です。 オペレーティングシステムにメモリを提供するためにG1がスクラッチする状況は非常にまれです！

したがって、誰もがこの問題（「悪党のようなRAMをさらに購入する」）で得点したでしょう。しかし、そうでない場合-あらゆる種類のクラウドとコンテナーがあり、これは不十分な利用と深刻なお金の損失を意味します。 見て、 なんてクールなレポート 、痛みでいっぱいになった。

解決策は、この特定のケースでG1が適切に動作するように教えることでした。OpenJ9のShenandaまたはGenConがすでに知っているとおりです。 股関節の不十分な使用を判断し、それに応じてその使用を減らす必要があります。 Tomcatの一部のテストでは、これによりメモリ消費量をほぼ半分に減らすことができました。

一番下の行は、アプリケーションが非アクティブであると見なされること、または最後のビルドから間隔（ミリ秒単位）がgetloadavg()し、同時サイクルがない場合、または1分間getloadavg()が特定のしきい値を下回る負荷を示した場合です。 これの1つが発生するとすぐに、定期的なガベージコレクションが開始されます。完全なアセンブリと同じようにクリーンになることはありませんが、アプリケーションへの影響は最小限になります。

このログにプッシュできます：

 (1) [6.084s][debug][gc,periodic ] Checking for periodic GC. [6.086s][info ][gc ] GC(13) Pause Young (Concurrent Start) (G1 Periodic Collection) 37M->36M(78M) 1.786ms (2) [9.087s][debug][gc,periodic ] Checking for periodic GC. [9.088s][info ][gc ] GC(15) Pause Young (Prepare Mixed) (G1 Periodic Collection) 9M->9M(32M) 0.722ms (3) [12.089s][debug][gc,periodic ] Checking for periodic GC. [12.091s][info ][gc ] GC(16) Pause Young (Mixed) (G1 Periodic Collection) 9M->5M(32M) 1.776ms (4) [15.092s][debug][gc,periodic ] Checking for periodic GC. [15.097s][info ][gc ] GC(17) Pause Young (Mixed) (G1 Periodic Collection) 5M->1M(32M) 4.142ms (5) [18.098s][debug][gc,periodic ] Checking for periodic GC. [18.100s][info ][gc ] GC(18) Pause Young (Concurrent Start) (G1 Periodic Collection) 1M->1M(32M) 1.685ms (6) [21.101s][debug][gc,periodic ] Checking for periodic GC. [21.102s][info ][gc ] GC(20) Pause Young (Concurrent Start) (G1 Periodic Collection) 1M->1M(32M) 0.868ms (7) [24.104s][debug][gc,periodic ] Checking for periodic GC. [24.104s][info ][gc ] GC(22) Pause Young (Concurrent Start) (G1 Periodic Collection) 1M->1M(32M) 0.778ms 

わかった？ しません。 JEPには、ログの各行の詳細な手話翻訳、アルゴリズムの仕組み、およびその他すべてがあります。

「それで、どうして私が見つけたのですか？」 -お願いします。 これで、 G1PeriodicGCIntervalとG1PeriodicGCSystemLoadThreshold 2つのハンドルが追加されました。 G1PeriodicGCInterval 、 G1PeriodicGCSystemLoadThresholdたときにねじることができます。 いつか悪くなることは間違いありません、それはジャワです、ベイビー！

まとめ

その結果、強力なリリースが手に入りました。革命ではなく、パフォーマンスの改善に焦点を当てた進化です。 改善の正確な半分はパフォーマンスに関するものです。GCについては3つのJEP、CDSについては1つで、これらは単独でオンになりますが、JDK 12へのアップグレードのみが必要です。さらに、JDK開発者向けの2つの新しいツール（定数APIおよびJMHテスト）、およびコミュニティは、ARM上の単一の64ビットポートに集中できるようになりました。

一般的に、今すぐJDK 12にアップグレードしてください。Forceがあなたと一緒にいるかもしれません。 あなたはそれが必要になります。

広告の分。 まもなく、4月5〜6日にJPointカンファレンスが開催され、JDKとあらゆる種類の新機能について多くの知識を持つ人々が集まります。 たとえば、AzulのSimon Ritterが「JDK 12：不注意な落とし穴」についての講演をします。 最新リリースについて議論するのに最適な場所です！ JPointの詳細については、 公式Webサイトをご覧ください 。