サービス・リフレッシュ 5

このリフレッシュには、重要な変更が含まれています。

サービス・リフレッシュ 5 フィックスパック 5にスキップします。

サービス・リフレッシュ 5 フィックスパック 10にスキップします。

サービス・リフレッシュ 5 フィックスパック 15にスキップします。

サービス・リフレッシュ 5 フィックスパック 16にスキップします。

サービス・リフレッシュ 5 フィックスパック 17にスキップします。

サービス・リフレッシュ 5 フィックスパック 20にスキップします。

サービス・リフレッシュ 5 フィックスパック 25にスキップします。

サービス・リフレッシュ 5 フィックスパック 26にスキップします。

サービス・リフレッシュ 5 フィックスパック 27にスキップします。

サービス・リフレッシュ 5 フィックスパック 30にスキップします。

サービス・リフレッシュ 5 フィックスパック 31にスキップします。

サービス・リフレッシュ 5 フィックスパック 35にスキップします。

サービス・リフレッシュ 5 フィックスパック 36にスキップします。

サービス・リフレッシュ 5 フィックスパック 37にスキップします。

サービス・リフレッシュ 5 フィックスパック 40にスキップします。

サービス・リフレッシュ 5 フィックスパック 41にスキップします。

サービス・リフレッシュ 5

このリリースには、以下の新機能があります。
Java™ バージョン出力
java -version コマンド行オプションと java -showversion コマンド行オプション、および java.version システム・プロパティーからの出力が更新され、 IBM SDK のベースとなる Oracle ビルド番号が含まれるようになりました。 例えば、ストリング 1.8.0_141 は、SDK が Oracle SE 1.8 クラス・ライブラリー、更新 141 (U141) に基づいていることを示します。

この出力には、バージョン、リリース、モディフィケーション、およびフィックスパック (V.R.M.F) の番号を示すための変更も含まれています。 例えば、Java(TM) SE Runtime Environment (build 8.0.5.0 ...は、バージョン8のサービス更新5を反映します。

JVM がアイドル状態のときの Java オブジェクト・ヒープの管理 (Linux® のみ)
JVM がアイドル状態のときに Java オブジェクト・ヒープを管理するために、以下のチューニング・オプションを使用できます。
  • -XX:IdleTuningMinIdleWaitTimeオプション・オプションは、他のチューニング・オプションが有効になる前に、JVMがアイドル状態でなければならない時間を制御する。
  • XX:[+|-]IdleTuningCompactOnIdleオプション・オプションは、ガベージ・コレクタがJavaオブジェクト・ヒープを収集してコンパクトにするかどうかを制御する。
  • XX:[+|-]IdleTuningGcOnIdleオプション・オプションは、メモリ・フットプリントを減らすために空きメモリ・ページを解放するかどうかを制御する。
  • -XX：IdleTuningMinFreeHeapOnIdleオプションオプションは-XX:+IdleTuningGcOnIdleと共に、使用して、オブジェクトヒープに残しておく必要のある空きメモリの最小量を設定できます。

    このオプションは、世代別並行 (gencon) ガーベッジ・コレクション・ポリシーが使用されている場合に、 x86-32 および x86-64 アーキテクチャー上の Linux にのみ適用されます。 大規模ページを使用するようにオブジェクト・ヒープが構成されている場合、このオプションに効果はありません。

一時停止時間を短くするための新しいガーベッジ・コレクション・モード
Generational Concurrent（gencon）ガベージコレクションポリシーで機能する新しいモードが利用可能です。 このモードが有効になっていると、JVM は、応答時間に左右されるラージ・ヒープ・アプリケーションのために、GC 一時停止時間を短くしようと試みます (これによって、スループット安定度が高くなります)。 このモードは、 -Xgc:concurrentScavenge オプションによって制御されます。このオプションは、 z/OS® V2R3 (または APAR OA51643が適用された z/OS V2R2 ) および z14 ハードウェアを必要とし、64 ビット JVM でのみサポートされます。 オペレーティング・システムおよびハードウェアの要件が満たされていない場合、このオプションは無視されます。
JIT コンパイラーが 2 GB 境界より上にメモリーを割り振る機能 (z/OS のみ)
z/OS V2R3 システムでは、64 ビット・プログラムの常駐モード (RMODE64) はデフォルトで有効になっています。 この機能によって、JIT は 2 GB メモリー境界より上に実行可能コード・キャッシュを割り振ることができます。 -Xjit:disableRMODE64 オプションがコマンド行に指定されない限り、この動作はデフォルトです。 詳しくは、 disableRMODE64 (z/OS のみ)を参照してください。
共有クラス・キャッシュの調整
MXBean を使用してプログラマチックに照会および調整できる、またはコマンド行オプションを使用して変更できる、共有クラス・キャッシュの内容に対してソフト制限を作成できるようになりました。 キャッシュのサイズをモニターおよび調整する能力は、複数の類似したサーバーが動作しているときに、フットプリントおよび起動時間を削減するために役立ちます。

以前のリリースのように-Xscmxオプションを指定した場合、動作に変更はありません。 このオプションは、新しい共有クラスキャッシュのサイズを指定します。 ただし、新しい-XX:SharedCacheHardLimitオプションも指定した場合、-Xscmxオプションは新しい共有クラス・キャッシュのソフト最大サイズを指定し、-XX:SharedCacheHardLimitオプションは実際の最大サイズを指定します。 ソフト最大制限に達する (キャッシュがソフト・フル になる) と、ソフト最大制限を大きくしない限り、データをキャッシュに追加することはできません。 詳細は、-Xscmxオプションと -XX:SharedCacheHardLimitオプションを参照のこと。

MXBean 互換性の改善
java.lang.mangement API のモニターおよび管理インターフェース拡張機能が、以下の com.sun.management クラスとの互換性の改善を目的に更新されています。
  • GarbageCollectorMXBean
  • GarbageCollectionNotificationInfo
  • GcInfo
  • OperatingSystemMXBean
  • UnixOperatingSystemMXBean
この互換性には、これらの com.sun.management クラスによって提供された API のフルセットのクラス・キャスト互換性および実装が含まれます。 詳しくは、「 言語管理 API リファレンス」を参照してください。
以前のインターフェース拡張機能による出力を使用している場合は、以下の新しいオプションを使用して、その実装の動作に戻すことができます。
  • -Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns
  • -XX:[+|-]HeapManagementMXBeanCompatibility
これらのオプションの詳細については、 OperatingSystemMXBean.getProcessCpuTime( メソッドの返り値の変更およびメモリ・プールとガベージ・コレクション・アクティビティの監視の向上を参照してください。
OperatingSystemMXBean.getProcessCpuTime() メソッドの戻り値における変更
com.sun.management.OperatingSystemMXBean インターフェースおよび UnixOperatingSystemMXBean インターフェースとの互換性のために、1/100 ナノ秒の代わりにナノ秒で値を返すよう、OperatingSystemMXBean.getProcessCpuTime() メソッドが変更されました。 -Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns オプション システム・プロパティーを使用して、以前の動作に戻すことができます。
メモリー・プールおよびガーベッジ・コレクション・アクティビティーのモニターの改善
アプリケーションの動作を理解しやすくするために、 IBM® ガーベッジ・コレクターおよびメモリー・プール MXbean に機能拡張が行われています。 以前のリリースでは、メモリー・プール情報は集約され、Java ヒープ全体について報告されていました。 このリリースでは、ガーベッジ・コレクション・ポリシーのメモリー・プールおよびガーベッジ・コレクター・アクティビティーについて、より詳しい情報を得ることができます。

監視アプリケーションが1つのヒープメモリプールのみを予期するように作成されている場合、またはメモリプール名Java heapに依存する場合は、-XX:+HeapManagementMXBeanCompatibilityオプションで前の実装に戻すことができます。 このオプションと、提供される新しい 'MemoryPoolおよび 'GarbageCollector名の詳細については、-XX:[+|-]HeapManagementMXBeanCompatibilityオプションを参照してください。

-XX:[+|-]InterleaveMemory デフォルトで無効 (AIX®、 Linux、および Windows)
メモリー・インターリービングは、デフォルトで無効になります。 詳細については、-XX:[+|-]InterleaveMemoryオプション （AIX、Linux、Windows）を参照のこと。
遅延接続エージェントはクラスを再定義または再変換できる
遅延接続エージェントはデフォルトで、クラスを再定義または再変換できます。 この機能を使用可能にするために、「 IBM SDK, Java Technology Edition バージョン 8: 補足情報」で説明されている -XX:+EnableHCR オプションを使用する必要はなくなりました。 Java Attach API について詳しくは、 OpenJ9 ユーザー資料の「 Java Attach API 」を参照してください。
VM フックの診断情報の改善
VM フック (クラス・アンロード・フックなど) のコールバックが時間のしきい値を超えたときにトリガーされる、新しいトレース・ポイントが追加されています。 トリガーされると、Java ダンプ出力に新しいセクションが生成されます。 トレース・ポイントおよび Java ダンプは、コールバックを識別するための十分な情報を提供します。

詳細については、以下を参照してください。HOOKJava ダンプ・ファイルのセクションについては、 OpenJ9 ユーザー資料の「 Hook (HOOK) 」を参照してください。 トレース・ポイントについて詳しくは、 J9 VM リファレンスの「 Java アプリケーションのトレース 」を参照してください。

Extra page of memory no longer required when using large page sizes (Linux on IBM Zと 'z/OSのみ)
大規模ページ・サイズの倍数であるオブジェクト・ヒープ・サイズを指定する場合、別のメモリー・ページを許可する必要がなくなりました。 前のリリースでは、たとえばページサイズが2 GBの場合、設定 -Xmx2Gは実際には4GBのメモリを使用しました。 より多くのメモリを使用しないようにするには、少なくとも16バイトを減算して、ヒープサイズを整数ページ数よりも少し削減する必要がありました。 たとえば、2 GBのページサイズの場合、-Xmx2147483632最大ヒープサイズを-Xmx2048m（2 GB）ではなく（2147483648マイナス16バイト）に指定する必要がありました。 4GB ページ・サイズの場合は、ヒープ・サイズを-Xmx4096m (4GB) ではなく-Xmx4294967280 (4,294,967,296 から16バイトを引いた値) を指定する必要がありました。 このリリース以降、ヒープ・サイズを減らす必要はありません。
初期 Java ヒープ・サイズのデフォルト値
-Xms オプションは、Java ヒープの初期サイズを設定します。 このオプションがコマンド行に設定されていないと、ガーベッジ・コレクターがデフォルトで初期サイズ 8 MB を設定します。 以前のリリースの SDK では、ガーベッジ・コレクターはデフォルト値 4 MB を設定していました。 この設定について詳しくは、 OpenJ9 ユーザー資料の -Xms オプション を参照してください。
-Xthr:<fastNotify|noFastNotify>オプション
-Xthr:fastNotify を使用して、アプリケーションのスループットを向上させることができるようになりました。具体的には、 wait と notify を定期的に使用することで、多数のスレッドが Java モニターを獲得しようとする場合です。 詳しくは、 OpenJ9 ユーザー資料の -Xthr オプション を参照してください。
一部の-Xzero サブオプションはサポートされなくなりました。
サブオプション j9zip、noj9zip、sharezip、および nosharezip はサポートされなくなりました。 これらのオプションを指定しても、解析はされますが、何も行われません。 これらのオプションについて詳しくは、 OpenJ9 ユーザー資料の -Xms オプション を参照してください。
Attach API 例外が com.sunから始まるようになりました。
Attach API例外には、com.ibm.tools.attachではなくcom.sun.tools.attachという接頭部が付けられるようになりました。
デフォルトでオフになっているランタイム計測機能 (AIX、 Linux、および z/OS のみ)
以前の更新では、RI ファシリティーはデフォルトで、サポート対象のすべてのプラットフォームで有効になっていました。 現在、RI ファシリティーはデフォルトで無効です。 詳細については、OpenJ9ユーザー・ドキュメントの -XX:[+|-]RuntimeInstrumentationを参照のこと。
CompactStrings をサポートするための Strings への変更
コンパクトな Strings （-XX:+CompactStrings)、 java.lang.String ）をサポートするため、 char[] データ内の String の開始を示すために使用されるオフセット・フィールドが含まれなくなった。 コード内でゼロ以外の beginIndex の値に対して以下のメソッドを使用すると、パフォーマンスが影響を受ける可能性があります。
  • String.substring(int beginIndex)
  • String.substring(int beginIndex, int endIndex)

以前のリリースでは、新しい String が作成されますが、基本 char[] がオリジナルの String と共有されるため、char[] データはコピーされません。 char[] データがコピーされるようになったためにパフォーマンスが大きく低下する場合、String データのコピーを避けるようコードを再実装してみてください。

注: HotSpot VM を使用する Java 実装で実行するように作成されたアプリケーションは影響を受けません。ゼロの beginIndex を使用しても、 String データがコピーされるためです。
パック・オブジェクト評価テクノロジーの削除
パック・オブジェクト・テクノロジー・プレビューが使用できなくなりました。

サービス・リフレッシュ 5 フィックスパック 5

このリリースには、最新の IBM フィックス、2017 年 10 月の Oracle Critical Patch Update (CPU)、および以下の更新が含まれています。
Java バージョン情報の変更
java -version コマンドからの出力が変更されました。 以下に例を示します。
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 8.0.5.5 - pxa6480sr5fp5-20171109_02(SR5 FP5))
IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20171102_369060 (JIT enabled, AOT enabled)
OpenJ9 - 7ade437
OMR - 1b656cb
IBM - 59c3d96)
JCL - 20171109_01 based on Oracle jdk8u151-b12
OpenJ9から始まる行は、以前の更新から出力行J9VMとJITを置き換えます。これは、これらのコンポーネントがEclipse OpenJ9プロジェクトのEclipseFoundation にコントリビュートされるようになったためです。
AIX のサポート
このリフレッシュ以降、および今後のすべての暫定修正 (ifixes) について、 AIX 6.1 の最小サポート・レベルが TL9になりました。 これ以前の保守レベルでは、特定の com.ibm.language.management API 拡張機能の使用によって、ProcessorUsageRetrievalException 例外と GuestOSInfoRetrievalException 例外が発生する可能性があります。
Java プロセスのオープン・ファイル記述子カウントの構成
1 つのプロセスにおけるオープン・ファイル記述子の最大数は、オペレーティング・システムによって制御されています。 UNIX システムでは、この数を構成するには、システムのハード制限または ulimitを設定します。
始動処理中のリソース使用量が過剰にならないようにするために、 IBM SDK では、Java プロセスの最大ファイル記述子カウントを 64Kに制限しています。 以下に示す規則が適用されます。
  • ulimit値が64Kより大きい場合、ファイル記述子カウントはデフォルトで64Kになります。
  • ulimit値が64Kより小さい場合、ファイル記述子カウントはulimit値と一致します。
ご使用のアプリケーションが多くのオープン・ファイル記述子を必要としている場合、または設定されているデフォルト制限によって始動パフォーマンスが影響を受ける場合、以下の環境変数を設定することによって値を構成できます。
export IBM_JAVA_FDLIMIT=file_descriptor_count
ここで、ファイル・ディスクリプター数 は、ご使用のシステムのulimitより小さい値です。

サービス・リフレッシュ 5 フィックスパック 10

このリリースには、最新の IBM フィックスと 2018 年 1 月の Oracle Critical Patch Update (CPU) が含まれています。

安全検査
Eclipse OpenJ9 VM の場合、 SecurityManger が有効になっていると、セキュリティーを強化するために、以下の API のセキュリティー検査がデフォルトで有効になります。
  • com.ibm.jvm.Dump.JavaDump()
  • com.ibm.jvm.Dump.HeapDump()
  • com.ibm.jvm.Dump.SnapDump()
  • com.ibm.jvm.Log.QueryOptions()
  • com.ibm.jvm.Log.SetOptions(String)
  • com.ibm.jvm.Trace.set(String)
  • com.ibm.jvm.Trace.snap()
  • com.ibm.jvm.Trace.suspend()
  • com.ibm.jvm.Trace.suspendThis()
  • com.ibm.jvm.Trace.resume()
  • com.ibm.jvm.Trace.resumeThis()
  • com.ibm.jvm.Trace.registerApplication(String, String[])
  • com.ibm.jvm.Trace.trace(<any parameters>)
これらの API のセキュリティー検査は、以下のシステム・プロパティーをコマンド行に設定することによって無効にできます。
  • -Dcom.ibm.jvm.enableLegacyTraceSecurity=false
  • -Dcom.ibm.jvm.enableLegacyDumpSecurity=false
  • -Dcom.ibm.jvm.enableLegacyLogSecurity=false

サービス・リフレッシュ 5 フィックスパック 15

このリリースには、最新の IBM フィックスおよび 2018 年 4 月 Oracle Critical Patch Update (CPU) に加えて、以下の変更が含まれています。
安全検査
SecurityManager がクラス・データ共有とともに使用され、稼働中のアプリケーションが com.ibm.oti.shared.SharedClassUtilities API getSharedCacheInfo() または destroySharedCache() を呼び出す場合、これらの API を呼び出すコードに、該当する SharedClassesNamedPermission を付与する必要があります。 コード例については、 OpenJ9 ユーザー資料の「 カスタム・クラス・ローダーのサポート 」を参照してください。
ダンプ処理を制御するための新規 MXBean
ダンプとトレースの診断データの生成は、起動時のコマンド行オプション -Xdump で制御できます。 ダンプ構成を変更する場合は、アプリケーションを再始動する必要があります。 再始動を回避するには、com.ibm.jvm.Dump アプリケーション・プログラミング・インターフェース (API) を使用して動的に構成を変更します。 現在、新規 MXBean が使用可能です。 これは、リモート・サーバーやコンテナーで実行されているアプリケーションをリモートでモニターしているときに動的にダンプを構成できるようにダンプ API メソッドを呼び出します。
構成オプションについて詳しくは、 API 資料を参照してください。
ハードウェア・サポート
今回の更新でIBM POWER9のサポートが追加されたが、それ以降、セキュリティ修正を含む重要な修正が行われている。 IBM POWER9を使用している場合は、少なくともフィックスパック 30 にアップグレードする必要があります。
オペレーティング・システム・サポート
以下のオペレーティング・システムがサポートされるようになりました。
  • Red Hat® Enterprise Linux (RHEL) 7.5
  • Ubuntu 18.04
Linux on IBM Zでコンカレント・スカベンジ・モードがサポートされました
-Xgc:concurrentScavenge オプションが、RHEL 7.5 および Ubuntu 18.04 を使用する IBM z14 ハードウェアで以下のレベルおよび構成でサポートされるようになりました。
オペレーティング・システム
  • RHEL 7.5 (最小カーネル・レベル 4.14)
  • Ubuntu 18.04
ハイパーバイザー
  • QEMU 2.10 以降および最小ホスト・カーネル・レベル 4.12 が適用された KVM ソリューション
z/OS で ICONV コンバーターと Java コンバーターを切り替えるための新しい環境変数
デフォルトでは、コード・ページ・セット間で文字を変換するために ICONV ユーティリティーが使用されます。 ただし、ICONV は、特定のプラットフォーム上で認識されない文字に変換することがあります。 例えば、ICONVはEBCDICコードx'25' (改行)をUnicode'\u0085'(次の行) に変換するため、XMLパーサーで問題が発生します。
以下の環境変数を設定して、Java コンバーターを選択できます。
USE_JAVA_CONV=1
デフォルトでは、環境変数は、ICONVユーティリティーを使用するUSE_JAVA_CONV=0に設定されます。

サービス・リフレッシュ 5 フィックスパック 16

フィックスパック 16 には、Eclipse OpenJ9 仮想マシンにおける以下の新機能が含まれています。

アイドル調整機能に対する拡張サポート
Eclipse OpenJ9 VM におけるアイドル調整機能は、使用されていないメモリーを解放してオペレーティング・システムに返すことで、ご使用のメモリー・フットプリントを小さい状態に保ちます。 この機能は、世代別並行 (gencon) ガーベッジ・コレクション・ポリシーで使用する場合に、 x86 アーキテクチャーに加えて、 Linux for IBM POWER ® および IBM Z® で使用できるようになりました。 この機能について詳しくは、この動作を制御する以下のコマンド行オプション ( OpenJ9 ユーザー資料) を参照してください。
コンテナーで実行されるアプリケーションのデフォルトの最大 Java ヒープ・サイズの変更
コンテナー・テクノロジーが使用される場合、通常、アプリケーションは単独で実行されるためメモリーを奪い合う必要はありません。 今回の更新では、コンテナー内で OpenJ9 VM が実行されていることを検出するための変更が導入されました。 アプリケーションがコンテナー内で実行されていて、VM がより多くのメモリーを Java ヒープに割り振るようにしたい場合は、コマンド行で -XX:+UseContainerSupport オプションを設定して、使用可能メモリーの割合を増やすことができるようになりました。 割り振られる割合はコンテナー・メモリー制限によって異なります。 詳細については、OpenJ9ユーザー・ドキュメントの -XX:[+|-]UseContainerSupportを参照してください。

サービス・リフレッシュ 5 フィックスパック 17

フィックスパック 17 には、Eclipse OpenJ9 仮想マシンにおける以下の新機能が含まれています。

新規ガーベッジ・コレクション・ポリシー
Eclipse OpenJ9 VM に新しいポリシーが導入されました。この VM は、通常の方法で Java ヒープを拡張しますが、ガーベッジ・コレクション操作によってメモリーを再利用することはありません。 このモードは、ランタイム要件を満たすだけの十分なメモリーが存在する場合に一時的なアプリケーションに役立ちます。 詳しくは、 OpenJ9 ユーザー資料の -Xgcpolicy:nogc を参照してください。
最大 Java ヒープ・サイズのパーセンテージ値としての指定
OpenJ9 VM が、ヒープ・サイズを物理メモリーのパーセンテージとして設定することをサポートするようになりました。 以下の Oracle HotSpot オプションが認識され、VM に設定できます。アプリケーションがコンテナで実行されており、-XX:+UseContainerSupportを指定した場合、コンテナのデフォルトのヒープサイズとこれらの新しいオプションの値は、使用可能なコンテナメモリに基づいています。
ネストされた jar ファイルに対する共有クラス・サポート
ネストされた jar ファイルをサポートするように com.ibm.oti.shared アプリケーション・プログラミング・インターフェースが変更されました。

サービス・リフレッシュ 5 フィックスパック 20

このリリースには、最新の IBM フィックスと 2018 年 7 月の Oracle Critical Patch Update (CPU) が含まれています。

サービス・リフレッシュ 5 フィックスパック 25

このリリースには、最新の IBM フィックスと 2018 年 10 月の Oracle Critical Patch Update (CPU) が含まれています。

このリフレッシュでは、 IBM SDK, Java Technology Edition バージョン 8 をサポートするための資料が変更されました。 このSDKガイドとサポートする J9 VMリファレンスに加え、 IBM ドキュメンテーションには、 Eclipse OpenJ9 VMユーザー・ドキュメントが含まれるようになりました。 J9 VM リファレンスに以前記載されていた一部の資料は、重複を避けるために削除されました。 この変更の影響を最小限に抑えるためにリダイレクトが行われています。

Eclipse OpenJ9 VM に対する新しい変更については、 OpenJ9 ユーザー資料で以下のリリース・ノートを参照してください。

サービス・リフレッシュ 5 フィックスパック 26

OpenJ9 ユーザー資料の説明にあるように、フィックスパック 26 には、Eclipse OpenJ9 仮想マシンにおける以下の新機能が含まれています。
新規のクラス・データ共有サブオプション

この-Xshareclasses:bootClassesOnlyオプションは、ブートストラップ以外のクラスローダーにロードされるクラスのキャッシュを無効にします。 このサブオプションはnonfatalサブオプションも有効にします。これにより、共有クラスキャッシュの作成中にエラーが発生した場合でも、VMを起動できます。

この-Xshareclasses:fatalオプションは、共有クラスキャッシュの作成中にエラーが発生した場合にVMの起動を抑えます。 -Xshareclasses:bootClassesOnlyサブオプションを使う場合、キャッシュ作成時の問題を解決するには、このサブオプションを使用可能にしてください。

OpenJ9 VM でのコンテナー認識がデフォルトで有効になった

コンテナー・テクノロジーが使用される場合、通常、アプリケーションは単独で実行されるためメモリーを奪い合う必要はありません。 VM がコンテナー環境で実行されていることを検出し、コンテナーのメモリー制限が設定されている場合、VM は自動的に最大デフォルト Java ヒープ・サイズを調整します。

早期のリリースでは、この動作は-XX:+UseContainerSupportオプションを設定することにより、有効になりました。 この設定がデフォルトになりました。

Linux x86 プラットフォームで一時停止不要ガーベッジ・コレクション・モードを使用できるようになりました。

一時停止なしガーベッジ・コレクション・モードは、応答時間が重視される、大規模なヒープ・アプリケーション向けです。 これが有効になっていると、VM は GC 一時停止時間を削減しようとします。 以前のリリースでは、休止なしガーベッジ・コレクション・モード (-Xgc:concurrentScavenge) は、 IBM z14 ハードウェアでのみ使用可能でした。 このモードは、64 ビット x86 Linux プラットフォームで使用できるようになりました。

注: 世代別並行 (gencon) ガーベッジ・コレクション・ポリシーを使用する必要があります。 (これはデフォルト・ポリシーです。)
ID ハッシュ・コードをゼロまたは正の値に制限できるようになった
OpenJ9 は正と負の両方の ID ハッシュ・コードを許可します。 このことは、ハッシュ・コードは正のみが可能であるとプログラムが (誤って) 想定した場合に問題となる可能性があります。 ただし、-XX:+PositiveIdentityHashオプションを使用して、IDハッシュコードを非負値に制限できるようになりました。 ID ハッシュ・コードをゼロまたは正の値に制限すると、ハッシュを大量に使用する操作のパフォーマンスに影響が及ぶ可能性があるため、このオプションはデフォルトで無効になっています。
OpenJDK HotSpot オプションに対するサポート
互換性のために以下の OpenJDK Hotspot オプションが OpenJ9 でサポートされるようになりました。
  • -XX:MaxHeapSizeは -Xmx オプションと同等です。
  • -XX:InitialHeapSizeは -Xms オプションと同等です。
IBM_JAVA_OPTIONS は非推奨
IBM_JAVA_OPTIONS 環境変数は推奨されません。 代わりに、新しいOPENJ9_JAVA_OPTIONS環境変数を使用してください。

サービス・リフレッシュ 5 フィックスパック 27

OpenJ9 ユーザー資料の説明にあるように、フィックスパック 27 には、Eclipse OpenJ9 仮想マシンにおける以下の新機能が含まれています。
JIT コード・キャッシュのサイズを管理するための柔軟性の向上
JIT コード・キャッシュには、コンパイル済み Java メソッドのネイティブ・コードが保管されます。 デフォルトでは、コード・キャッシュのサイズは 64 ビット VM の場合で 256 MB であり、31/32 ビット VM の場合で 64 MB です。 以前のリリースでは、-Xcodecachetotal コマンド行オプションを使用することでコード・キャッシュのサイズをデフォルト値から増やすことができました。 今回のリリースでは、このオプションを使用することで、このサイズを減らすこともできます (最小サイズは 2 MB)。 JIT コード・キャッシュのサイズは JIT データ・キャッシュ (コンパイルされたメソッドに関するメタデータが保持される) のサイズにも影響します。 -Xcodecachetotal オプションを使用してコード・キャッシュのサイズを管理する場合、データ・キャッシュのサイズは同じ比率で調整されます。

サービス・リフレッシュ 5 フィックスパック 30

OpenJ9 ユーザー資料の説明にあるように、フィックスパック 30 には、Eclipse OpenJ9 仮想マシンにおける以下の新機能が含まれています。
一時停止なしガーベッジ・コレクションに対するサポートの向上

64 ビット Windows オペレーティング・システムで並行スカベンジ・モード (-Xgc:concurrentScavenge) がサポートされるようになりました。

VM が Docker コンテナーで実行されるときにアイドル調整がデフォルトで有効になる
以前のリリースでは、 OpenJ9 VM がアイドル状態のときに Java ヒープのフットプリントを管理するために、一連のアイドル・チューニング・オプションが導入されました。 現在は、OpenJ9 VM がコンテナー内で実行されていること、およびその VM がアイドル状態になったことをその VM 自身が検出すると、以下の 2 つのオプションがデフォルトで有効になります。
  • -XX:[+|-]IdleTuningGcOnIdleです。ガーベッジ・コレクション・サイクルを実行し、空きメモリー・ページを解放してOSに戻します。
  • -XX:[+|-]IdleTuningCompactOnIdle、オブジェクトヒープを圧縮して、断片化を減らします。
デフォルトでは、VM はアイドル状況検出のために 180 秒ごとに検査されます。 チェック間の待ち時間を制御するには、-XX:[+|-]IdleTuningMinIdleWaitTimeオプションを使用するOpenJ9ユーザー・ドキュメント）。 アイドル検出をオフにするには、値を 0 に設定します。
デフォルトの共有クラス・キャッシュ・ディレクトリー許可の変更 (Windows 以外)
cachDirPerm サブオプションを使用して共有クラス・キャッシュ・ディレクトリーの許可を指定せず、キャッシュ・ディレクトリーが/tmp/javasharedresourcesのデフォルトではない場合、以下の変更が適用されます。
  • 新規キャッシュ・ディレクトリーを作成するときのデフォルト許可が厳しくなりました。
  • キャッシュ・ディレクトリーが既に存在する場合に、許可が変更されなくなりました (以前であれば、このディレクトリーを使用してキャッシュが開かれるときに、許可は 0777 に設定されていました)。

詳しくは、 OpenJ9 ユーザー資料の「 -Xshareclasses 」を参照してください。

サービス・リフレッシュ 5 フィックスパック 31

OpenJ9 ユーザー資料の説明にあるように、フィックスパック 31 には、Eclipse OpenJ9 仮想マシンにおける以下の新機能が含まれています。
制御グループを実装する Linux システムの診断情報の向上
制御グループ (cgroups) を使用して Linux システム上のリソースを管理する場合、CPU およびメモリーの制限に関する情報が Java ダンプ・ファイルに記録されるようになりました。 この情報は、Docker コンテナーで実行されるアプリケーションにとって特に重要です。 その理由は、リソースの制限がコンテナー内で設定されるときに Docker エンジンが設定を適用するために cgroups に依存するためです。 アプリケーションで使用可能なメモリ量にコンテナ制限が設定されており、この割り当てが十分でないためにJavaOutOfMemoryErrorエラーが発生する場合は、Javaダンプ・ファイルからこの問題を診断できます。 cgroup 情報は ENVINFO セクションにあります。
STDOUT または STDERR への Java ダンプの書き込み
-Xdump コマンド行オプションを使用して、Java ダンプ・ファイルを STDOUT または STDERR に書き込むことができるようになりました。
一時停止なしガーベッジ・コレクションに対するサポートの向上
並行スカベンジ・モードが、以下のプラットフォームでサポートされるようになりました。
  • IBM POWER LE 上の Linux
  • AIX

サービス・リフレッシュ 5 フィックスパック 35

フィックスパック 35 には以下の更新が含まれています。
新しい日本元号に対するサポート
新しい元号名「令和」に対するサポートが追加されました。 変更について詳しくは、 IBM SDK, Java Technology Edition の日本語版の変更点を参照してください。
さらに多くのオペレーティング・システム・バージョンに対するサポート
Red Hat Enterprise Linux (RHEL) バージョン 8 および Windows Server 2019 のサポートが追加されました。 サポートされるオペレーティング・システムのリストについては、 サポートされる環境を参照してください。
64 ビット z/OS でのデフォルトのネイティブ・スタック・サイズの変更
64 ビット z/OS 上のオペレーティング・システム・スレッドのデフォルト・スタック・サイズは、384 KB からオペレーティング・システムの最小値の 1 MB に変更されました。 この設定について詳しくは、 -Xmsoを参照してください。
OpenJ9 ユーザー資料の説明にあるように、フィックスパック 35 には、Eclipse OpenJ9 仮想マシンにおける以下の新機能と機能拡張も含まれています。
認識されない -XX: オプションを無視または報告するための新規オプション
デフォルトでは、認識されない-XX:コマンドラインオプションは無視され、アプリケーションの起動に失敗するのを防ぎます。 -XX:-IgnoreUnrecognizedXXColonOptionsを使ってこの動作をオフにして、認識されない-XX:オプションが代わりに報告されるように設置できます。 詳細については、OpenJ9ユーザー・ドキュメントの -XX:[+|-]IgnoreUnrecognizedXXColonOptionsを参照のこと。
STDOUT または STDERR への Java ダンプの書き込み

-Xdump コマンド行オプションを使用して、Java ダンプ・ファイルを STDOUT または STDERR に書き込むことができるようになりました。 詳しくは、 OpenJ9 ユーザー資料 の STDOUT/STDERRへの書き込み を参照してください。

制御グループを実装する Linux システムの診断情報の向上

制御グループ (cgroups) を使用して Linux システム上のリソースを管理する場合、CPU およびメモリーの制限に関する情報が Java ダンプ・ファイルに記録されるようになりました。 この情報は、Docker コンテナーで実行されるアプリケーションにとって特に重要です。 その理由は、リソースの制限がコンテナー内で設定されるときに Docker エンジンが設定を適用するために cgroups に依存するためです。 アプリケーションで使用可能なメモリー量にコンテナー制限が設定されているために Java OutOfMemoryError エラーが発生し、この割り振りでは不十分な場合は、Java ダンプ・ファイルからこの問題を診断できます。 cgroup 情報は ENVINFO セクションにあります。 出力例については、 OpenJ9 ユーザー資料の「 Java ダンプ (ENVINFO) 」を参照してください。

一時停止なしガーベッジ・コレクションに対するサポートの向上

並行スカベンジ・モード (-Xgc:concurrentScavenge) が AIX および Linux on POWER でサポートされるようになりました。

ホスト名および IP アドレスの判別にネットワーク照会が使用されないようにする新規 OpenJ9 オプション

デフォルトでは、トラブルシューティングのためにネットワーク照会を使用してホスト名と IP アドレスが判別されます。 ネーム・サーバーに接続できない場合にプログラムがタイムアウト待ちになるのを回避するために、照会が実行されないようにすることができるようになりました。 詳細については、OpenJ9ユーザー・ドキュメントの -XX:[+|-]ReadIPInfoForRASを参照のこと。

JVMTI 監視フィールドのパフォーマンスを向上させるための新規実験的オプション
このリリースでは、-XX:[+|-]JITInlineWatchesオプションOpenJ9ユーザー・ドキュメント）が導入されました。 このオプションが有効にされると、JVMTI 監視フィールドのパフォーマンスを向上させることを目的とした実験的な JIT 操作がオンになります。 このオプションは現在、x86プラットフォーム（Windows、macOS,、Linux）のみでサポートされている。
64 ビット z/OS でのデフォルトのネイティブ・スタック・サイズの変更
64 ビット z/OS 上のオペレーティング・システム・スレッドのデフォルトのスタック・サイズが 384 KB から 1 MB に変更されました。 この設定について詳しくは、 -Xmsoを参照してください。

サービス・リフレッシュ 5 フィックスパック 36

OpenJ9 ユーザー資料の説明にあるように、フィックスパック 36 には、Eclipse OpenJ9 仮想マシンにおける以下の新機能と変更が含まれています。

共用クラス・キャッシュ世代番号に対する変更

すべてのプラットフォームで、共有クラス・キャッシュに保管されるクラスのフォーマットが変更され、それが原因で JVM は既存のキャッシュを再作成したり再使用したりするのではなく新規の共用クラス・キャッシュを作成するようになりました。 スペースを節約するために、既存の共用キャッシュはすべて、以前のリリースによって使用されていない限り除去できます。

サービス・リフレッシュ 5 フィックスパック 37

OpenJ9 ユーザー資料の説明にあるように、フィックスパック 37 には、Eclipse OpenJ9 仮想マシンにおける以下の新機能と変更が含まれています。

一時停止なしガーベッジ・コレクションに対するプラットフォーム・サポートの向上

同時スカベンジ・モードのサポートが 'z/OSと 'Linux on IBM Z に拡張された。

Transparent HugePage のサポート

VM は、 madvise 設定の使用時に、 Linux でのヒュージ・ページの割り振りをサポートするようになりました。 この機能を有効にするには、アプリケーションの開始時にコマンド行で -XX:+TransparentHugePage オプションを指定します。

-XX:[+|-]JITInlineWatchesオプションは'z/OSと'Linux on IBM Zでサポートされ、デフォルトで有効になっている

このオプションは以前のリリースで導入され、JVMTI 監視フィールドのパフォーマンスを向上させることを目的とした実験的な JIT 操作をオンにします。 このオプションは'z/OSと'Linux on IBM Zでサポートされ、デフォルトで有効になっている。

OpenJDK HotSpot オプションに対するサポート

互換性のために-XX:OnOutOfMemoryErrorOpenJDKホット・スポット・オプションがサポートされるようになりました。

-Xdiagnosticscollector オプションの削除

このオプションは、冗長であるために削除されています。

サービス・リフレッシュ 5 フィックスパック 40

フィックスパック 40 には以下の更新が含まれています。
JDWP 実装が OpenJDK の同等の実装に置き換えられた
JDWP は、例えば 標準オプションや、 OpenJ9 資料の Java 仮想マシン・ツール・インターフェース に記載されているように、Java アプリケーションをデバッグするために使用されます。 以前の JDWP 実装が OpenJDK の同等の実装に置き換えられました。 この変更により、以前の実装に関する問題が解消され、オープン・ソース・ソフトウェアとの連携が強化されました。 これら 2 つの実装は異なるため、使用できるオプションも異なります。 オプション version、src、log、および trace は削除されました。 新たにオプション launch、onthrow、onuncaught、mutf8、および quiet が導入されました。 新規 JDWP 実装用のオプションについて詳しくは、コマンド行ヘルプを参照してください。
java -agentlib:jdwp=help
OpenJ9 ユーザー資料の説明にあるように、フィックスパック 40 には、Eclipse OpenJ9 仮想マシンにおける以下の新機能と変更も含まれています。
初期ヒープ・サイズの自動設定
これで、VMは、ユーザーの手動設定と-Xms値設定の代わりに、アプリケーションの適切な初期ヒープサイズを学習して設定できるようになりました。 VM は起動処理の終了時にヒープのサイズを記録し、このデータを共有クラス・キャッシュに書き込みます。 初期ヒープサイズに使用される値が可能な限り正確になるようにするために、数回の再始動での平均値が設定されます。 記録されたヒープ・サイズはアプリケーション・コマンド行に固有であるため、固有のコマンド行ごとに異なるヒントが保管されます。

この動作をオンにするには、アプリケーションの開始時にコマンド行で-XX:+UseGCStartupHintsオプションを設定してください。

アイドル GC 時の圧縮のヒューリスティック
VM は、アイドル・ガーベッジ・コレクション時に特定のトリガーが満たされると自動的にヒープを圧縮するようになりました。 この変更により、-XX:[+|-]IdleTuningCompactOnIdleオプションは非推奨となった。
-XX:IdleTuningCompactOnIdleの動作の変更
-XX:+IdleTuningGcOnIdleオプションが指定されない場合、-XX: [+ |-] IdleTuningCompactOnIdleオプションは無効になりました。
内部インターフェースの変更
Attach API内部インターフェースは少し変更され、SDKの内部クラス・ライブラリー、tools.jar ファイル、healthcenter.jarファイルに影響を与えます。
  • アプリケーションが以前のリリースの tools.jar ファイルの専用コピーを使用する場合、Java クラスが一致しないため、アプリケーションはこのリリースの Attach API を使用できない可能性があります。 代わりに、今回のリリースの tools.jar ファイルを使用してください。
  • 同様に、このリリースのhealthcenter.jarファイルは、以前のリリースと互換性がありません。

サービス・リフレッシュ 5 フィックスパック 41

OpenJ9 ユーザー資料の説明にあるように、フィックスパック 41 には、Eclipse OpenJ9 仮想マシンにおける以下の新機能と変更が含まれています。

初期ヒープ・サイズの自動設定がデフォルトで有効になる
この-XX:[+|-]UseGCStartupHintsオプションを有効にすると、アプリケーションの適切なヒープサイズの自動学習と設定がオンになり、デフォルトで有効になりました。
VM 匿名クラスを共有するためのオプション
以前のリリースでは、Unsafe.defineAnonymousClassに作成された匿名クラスは、共有クラス・キャッシュに保存されませんでした。 このようなクラスはデフォルトで保管されるようになりました。つまり、ahead-of-time (AOT) コンパイルの対象になり、始動パフォーマンスの向上につながります。 新しいオプション-XX:[+|-]ShareAnonymousClassesが導入され、匿名クラスが共有クラス・キャッシュに保存されないように設置できます。
Power Systems 上の JVMTI 監視フィールドのパフォーマンスの向上
JVMTIウォッチド・フィールドのパフォーマンスを向上させるためにJITオペレーションをオンにする「-XX:[+|-]JITInlineWatchesオプションが、AIXと Linux on Power Systemsでもサポートされるようになった。
Linux on x86: 透過的ヒュージ・ページ (THP) のサポート
Linux ( x86 システム上) で madvise (/sys/kernel/mm/transparent_hugepage/enabled) 設定を使用する場合、THP がデフォルトで有効になります。 この機能を無効にするには、アプリケーションの開始時にコマンド行で -XX:-TransparentHugePage オプションを設定します。 他のシステムにおける THP 設定は、madvise の使用時にデフォルトで無効になったままですが、-XX:+TransparentHugePageを設定することによって有効にできます。
共用クラス・キャッシュ世代番号に対する変更
共有クラス・キャッシュに保管されるクラスのフォーマットが変更され、それが原因で JVM は既存のキャッシュを再作成したり再使用したりするのではなく新規の共用クラス・キャッシュを作成するようになりました。 スペースを節約するために、既存の共有キャッシュはすべて、以前のリリースによって使用されていない限り削除できます。 フォーマットが変更された結果、-Xshareclasses:listAllCachesオプションの出力にレイヤー列が表示されるようになりました。 この変更の目的は、将来的な機能拡張のサポートです。