Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Generational ZGCのメモリ運用改善 - その物理メモリ使用量、本当に正しい?
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Daishi Tabata
June 07, 2025
Technology
730
1
Share
Generational ZGCのメモリ運用改善 - その物理メモリ使用量、本当に正しい?
Daishi Tabata
June 07, 2025
More Decks by Daishi Tabata
See All by Daishi Tabata
Javaコミュニティの歩き方 ~参加から貢献まで、すべて教えます~
tabatad
0
1.9k
失敗しないOpenJDKの非互換調査
tabatad
0
2k
Other Decks in Technology
See All in Technology
レガシーシステムをどう次世代に受け継ぐか
tachiiri
0
320
プロンプトエンジニアリングを超えて:自由と統制のあいだでつくる Platform × Context Engineering
yuriemori
0
110
Cortex Code君、今日から内製化支援担当ね。
coco_se
0
300
Webアクセシビリティは“もしも”に備える設計
tomokusaba
0
170
Hello UUID
mimifuwacc
0
120
ストライクウィッチーズ2期6話のエイラの行動が許せないのでPjMの観点から何をすべきだったのかを考える
ichimichi
1
310
ふりかえりがなかった職能横断チームにふりかえりを導入してみて学んだこと 〜チームのふりかえりを「みんなで未来を考える場」にするプロローグ設計〜
masahiro1214shimokawa
0
250
【関西電力KOI×VOLTMIND 生成AIハッカソン】空間AIブレイン ~⼤阪おばちゃんフィジカルAIに続く道~
tanakaseiya
0
180
New CBs New Challenges
ysuzuki
1
160
試されDATA SAPPORO [LT]Claude Codeで「ゆっくりデータ分析」
ishikawa_satoru
0
320
ログ基盤・プラグイン・ダッシュボード、全部整えた。でも最後は人だった。
makikub
5
1.3k
Cortex Codeでデータの仕事を全部Agenticにやりきろう!
gappy50
0
330
Featured
See All Featured
Accessibility Awareness
sabderemane
0
94
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
120
Rebuilding a faster, lazier Slack
samanthasiow
85
9.4k
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
110
Discover your Explorer Soul
emna__ayadi
2
1.1k
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
96
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.1k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.6k
Thoughts on Productivity
jonyablonski
76
5.1k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.8k
New Earth Scene 8
popppiees
2
2k
How to train your dragon (web standard)
notwaldorf
97
6.6k
Transcript
Generational ZGCのメモリ運用改善 - その物理メモリ使用量、 本当に正しい? © 2025 Fujitsu Limited JJUG
CCC 2025 Spring 2025/6/7 田端 大志 @tbtdis
アジェンダ ZGCが抱える問題 ZGCのコア技術から読み解く原因 Generational ZGCでの改善
© 2025 Fujitsu Limited •アプリケーションサーバー製品の開発・保守 •OpenJDK関連のコミュニティ活動 自己紹介 所属:富士通株式会社 OpenJDK JDK
Project Author JCP Executive Committee メンバ 先日JavaOneに参加してきました!
アジェンダ ZGCが抱える問題 ZGCのコア技術から読み解く原因 Generational ZGCでの改善
© 2025 Fujitsu Limited ZGCの特徴 G1GC ZGC チューニング (起動時設定) 必要性が高い
せずとも十分な性能 レイテンシ アプリやチューニング によって変動 1ms以下 スケーラビリティ (ヒープサイズ) ヒープの増大化で レイテンシ鈍化リスク ヒープサイズは レイテンシに無影響 スループット 高い G1GC比 -15%以内
© 2025 Fujitsu Limited ZGCの歩み JDK21 2023/9 JDK23 2024/9 JDK24
2025/3 Generational ZGCリリース Generationalが ZGCのデフォルト化 非Gen ZGCが削除 JDK11 2018/9 実験版リリース (Linuxのみ) JDK14 2020/3 Windows/macOS サポート 正式リリース JDK15 2020/9
© 2025 Fujitsu Limited 非Generational ZGCの問題 アロケーションストール CPUオーバーヘッド メモリ運用 本日の
テーマは こちら
© 2025 Fujitsu Limited 非Generational ZGCの問題(デモ) 使用するJDKのバージョンは21 ZGCのデフォルトは非Generational オブジェクトを作って 定期的に捨てるアプリ
© 2025 Fujitsu Limited 非Generational ZGCの問題(デモ) -8315MB(メモリ使用量) G1GCを使った場合、 メモリ使用量とRSSがおおよそ一致する
© 2025 Fujitsu Limited 非Generational ZGCの問題(デモ) -8434MB(メモリ使用量) 非Generational ZGCを使った場合、 メモリ使用量よりもRSSが多く報告される
※total(マシンの物理メモリ量)より多い
© 2025 Fujitsu Limited 実際のメモリ使用量とRSSの不一致 RSSが実際のメモリ使用量より多く報告される RSSを使った判断・判定ができない 検証マシン 必要なメモリは10GB だから少し余裕を
持ったマシンにしよう Java アプリ RSS:10GB Java アプリ 本番マシン メモリ12GB ⇐ ①過剰報告 ⇐ ②誤判断 ⇐ ③リソースの 無駄遣い
アジェンダ ZGCが抱える問題 ZGCのコア技術から読み解く原因 Generational ZGCでの改善
© 2025 Fujitsu Limited ロードバリア オブジェクトの参照をロードするときにJITコンパイラが処理を追加 String name = person.name;
例 •再配置後のアドレスに書き換える(Remap) •オブジェクトを参照中とマークする(Mark) オブジェクトの状態をみて、 処理 GCによるSTWが激減、1ms以下のレイテンシを実現 ZGC以外 アプリを一時停止してGCスレッドで実行 ZGC アプリの処理の一部として実行
© 2025 Fujitsu Limited ロードバリア オブジェクトの参照をロードするときにJITコンパイラが処理を追加 String name = person.name;
例 •再配置後のアドレスに書き換える(Remap) •オブジェクトを参照中とマークする(Mark) オブジェクトの状態をみて、 処理 GCによるSTWが激減、1ms以下のレイテンシを実現 ZGC以外 アプリを一時停止してGCスレッドで実行 ZGC アプリの処理の一部として実行 オブジェクトの参照のロードは ユーザアプリやAPI内部で頻発するので 無視できないオーバーヘッドとなる オーバーヘッドを軽減する仕組みが必要
© 2025 Fujitsu Limited ZGC以外のオブジェクトの状態取得方法 ヒープ オブジェクト オブジェクト Mark Word
Klass フィールド ・ ・ ・ 状態 状態を取得するには メモリアクセスが必須 状態はヒープ上の オブジェクト内で管理
© 2025 Fujitsu Limited カラーポインタ Unused(16bits) F R M M
オブジェクトアドレス(44bits) オブジェクトポインタ(64 bit) オブジェクトの状態をポインタ内の4bitで表現 メタデータ メモリアクセスを伴わず状態の取得が可能 メモリアクセス分のオーバーヘッドを軽減
© 2025 Fujitsu Limited カラーポインタを使ったアクセス Unused(16bits) F R M M
オブジェクトアドレス(44bits) メタデータ オブジェクトにアクセスするのにメタデータ部分は不要 ⇒ マスク処理でオブジェクトアドレス部分を抽出 この処理も削減できないか?
© 2025 Fujitsu Limited マルチマップメモリ Heap Remapped View Heap Marked1
View Heap Marked0 View ヒープメモリ 仮想アドレス空間 1つの物理メモリを3つのアドレス空間にマップ 各仮想アドレス空間内でオフセットが同じ ポインタは同じ物理メモリのアドレスを指す 例 0x41234 0x21234 0x11234 0x01234 マスク処理を省略 ⇒ オーバーヘッド軽減
© 2025 Fujitsu Limited マルチマップメモリ Heap Remapped View Heap Marked1
View Heap Marked0 View ヒープメモリ 仮想アドレス空間 1つの物理メモリを3つのアドレス空間にマップ 各仮想アドレス空間内でオフセットが同じ ポインタは同じ物理メモリのアドレスを指す 例 0x41234 0x21234 0x11234 0x01234 マスク処理を省略 RSSが実際の物理メモリ 使用量と一致しない原因 ⇒ オーバーヘッド軽減
アジェンダ ZGCが抱える問題 ZGCのコア技術から読み解く原因 Generational ZGCでの改善
© 2025 Fujitsu Limited Generational ZGC Young領域 Old領域 OBJ OBJ
一定期間以上存在した オブジェクトは昇格 JDK21 JDK23 JDK24 正式リリース ZGCのデフォルト化 非Gen ZGCが削除 •使い方(JDK21):-XX:+UseZGC –XX:+ZGenerational 領域ごとのGC戦略 GCパフォーマンスの最適化
© 2025 Fujitsu Limited カラーポインタの拡張 Unused (2bits) R M m
F Object Address(46bits) R R R M m F r r Unused (4bits) メタデータ 世代別のオブジェクトの状態を表現するには より多くのメタデータビットが必要 オブジェクトポインタ(64 bit) Unused (2bits) オブジェクトアドレス (46bits)
© 2025 Fujitsu Limited マルチマップメモリの変更 効果: 効果よりも現実のリスクの方が大きいと判断 オブジェクトアクセス時のマスク処理をなくす ⇒ ロードバリアのオーバーヘッド軽減
•実際の物理メモリ使用量とRSSが一致しなくなる •Generational ZGCのカラーポインタはメタデータが 増えたのでより多くのマルチマップが必要になる 現実: 廃止
© 2025 Fujitsu Limited Generational ZGCの新技術 ストアバリア リメンバーセット SATBマーク ロードバリアのオーバーヘッド軽減目的以外にも様々な改善
Full GC ヒープの高密度化 リロケートの改善
© 2025 Fujitsu Limited Generational ZGC使用時のRSS(デモ) -8486MB(メモリ使用量) Generational ZGCを使った場合、 メモリ使用量よりもRSSが多く報告されない
どちらかというと少し少なく報告されている(セッションで述べていない&未調査)
サマリ 非Generational Generational JDK11~JDK14 △ × JDK15~JDK20 〇 × JDK21~JDK23
〇 ◎ JDK24~ × ◎ ×:未実装 △:実験版 〇:正式版 ZGCはGenerationalの導入で真価を発揮 JDK21以降への移行を検討してみよう ◎:正式版・おすすめ
© 2025 Fujitsu Limited © 2025 Fujitsu Limited Thank you