kagamihogeの日記

kagamihogeの日記です。

JEP 345: NUMA-Aware Memory Allocation for G1をテキトーに訳した

http://openjdk.java.net/jeps/345

JEP 345: NUMA-Aware Memory Allocation for G1

Owner    Sangheon Kim
Type    Feature
Scope   JDK
Status  Candidate
Component   hotspot/gc
Discussion  hotspot dash gc dash dev at openjdk dot java dot net
Effort  M
Duration    M
Duplicates  JEP 157: G1 GC: NUMA-Aware Allocation
Reviewed by Mikael Vidstedt, Stefan Johansson, Thomas Schatzl
Endorsed by Mikael Vidstedt
Created 2018/09/06 22:46
Updated 2018/11/22 15:30
Issue   8210473

Summary

NUMA-awareなメモリアロケーションの実装により大型マシンのG1パフォーマンスを向上する。

Non-Goals

  • G1以外のコレクションのサポート。
  • LinuxSolaris以外のOSのサポート。
  • G1コレクターのその他のパーツ、task queue stealing, remembered sets or refinementなど、をNUMA-awarenessにすること。

Motivation

近年のマルチソケットマシンはnon-uniform memory access (NUMA)を持つようになっており、これは各ソケットやコアとのメモリアクセスが必ずしも等しくありません。ソケット間のメモリアクセスは異なるパフォーマンス特定を持ち、遠くのソケットへのアクセスは基本的にはレイテンシもかかります。

parallel collector(-XX:+UseParallelGC)は既にNUMA-awareになっており、複数ソケットで単一JVMを動かす設定のパフォーマンス向上に寄与してきました。一方HotSpotコレクタはその恩恵を受けておらず、vertical multi-socket NUMA scalingを上手く使えていないことを意味します。とりわけ大規模エンタープライズアプリケーションは複数ソケット上で巨大なヒープを使用する傾向にある一方、単一のJVM内で実行する管理性の利点を欲しています。G1コレクタを使用する顧客でスケーリングのボトルネックがますます増していくのを我々は目にしています。

Description

G1のヒープは固定サイズのリージョンで構成されます。通常リージョンは物理ページのセットで、ラージページ(-XX:+UseLargePages)の場合、いくつかのリージョンは単一の物理ページを構成する可能性があります。

最近の近代的なOSは、プラットフォームのメモリトポロジへのクエリと、特定のlocality group(以降、lgrp)から優先的にマップされる物理メモリのためのインタフェースを備えています。lgrpはコレクタが使用可能です。JVMが初期化されると、all regions are evenly split between the total number of available lgrps and touched by threads bound to the same lgrps so that they are preferentially allocated on that lgrp. 全てのリージョンで開始時にリージョンのlgrpを固定することは少々柔軟性が足りませんが、この欠点を以下の拡張により緩和します。

リージョンはmutatorsのメモリアロケートかGC中にsurvivor objectsのコピーに使用します。これらのリクエストが発生すると、G1はスレッドがアロケートされている同一のlgrpからフリーなリージョンを優先的に選択します。つまり、オブジェクトはyoung generation中は同一のlgrpに存在し続けます。もし、mutatorのリージョンアロケーション中に同一lgrpからフリーなリージョンが無い場合、G1はGCをトリガ―します。別のアイデアとしては、フリーなリージョンの距離順で最も近いlgrpから先に検索する、があります。

old generationで同一lgrpにオブジェクトを保持し続けるようなことは特にしません。

Humongous regions*1はこのアロケーションポリシーからは除外します。このリージョンに対しては特に何もしません。

Testing

-XX:+UseNUMAオプションを付けての既存テストであらゆる正しさの問題(correctness issues)を洗い出せると思われます。本JEPのテストはNUMAのハードウェアを使用する想定です。

NUMA awareアロケーションをオフ時でもオリジナルのコードとパフォーマンスの差は無いと思われます。

Risks and Assumptions

大半の短命オブジェクトはそのオブジェクトを割り当てたスレッドでアクセスする、と我々は捉えています。これは確かにたいていのオブジェクト指向プログラムの短命オブジェクトの大半で事実です。しかし、この仮定が保留となるプログラムがあり、ある条件下ではパフォーマンス劣化の可能性があります。また、本JEPのメリットは基底システムのNUMAnessエクステントの相互作用と、システム上でlgrp間をマイグレートするスレッドの頻度に、特に負荷が高い場合に、依存します。

*1:https://www.slideshare.net/SparkSummit/kaczmarek-yi によると「リージョンサイズの1/2以上大きいラージオブジェクトのためのold regions. このオブジェクトはヒープの連続リージョンに保存される。」