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
Daishi Tabata
June 07, 2025
Technology
1
360
Generational ZGCのメモリ運用改善 - その物理メモリ使用量、本当に正しい?
Daishi Tabata
June 07, 2025
Tweet
Share
More Decks by Daishi Tabata
See All by Daishi Tabata
失敗しないOpenJDKの非互換調査
tabatad
0
1.1k
Other Decks in Technology
See All in Technology
Observability в PHP без боли. Олег Мифле, тимлид Altenar
lamodatech
0
340
AWS CDK 実践的アプローチ N選 / aws-cdk-practical-approaches
gotok365
6
720
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
11
3.9k
AIの最新技術&テーマをつまんで紹介&フリートークするシリーズ #1 量子機械学習の入門
tkhresk
0
130
Prox Industries株式会社 会社紹介資料
proxindustries
0
270
AWS Summit Japan 2025 Community Stage - App workflow automation by AWS Step Functions
matsuihidetoshi
1
250
フィンテック養成勉強会#54
finengine
0
170
あなたの声を届けよう! 女性エンジニア登壇の意義とアウトプット実践ガイド #wttjp / Call for Your Voice
kondoyuko
4
420
MySQL5.6から8.4へ 戦いの記録
kyoshidaxx
1
200
生成AIでwebアプリケーションを作ってみた
tajimon
2
140
Github Copilot エージェントモードで試してみた
ochtum
0
100
VISITS_AIIoTビジネス共創ラボ登壇資料.pdf
iotcomjpadmin
0
160
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
4 Signs Your Business is Dying
shpigford
184
22k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Making Projects Easy
brettharned
116
6.3k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
17
940
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Designing Experiences People Love
moore
142
24k
Embracing the Ebb and Flow
colly
86
4.7k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
790
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