静かに変わってきたクラスファイルを詳細に調べて楽しむ（JJUG CCC 2024 Fall講演資料）

© 2024 NTT DATA Japan Corporation
静かに変わってきたクラスファイルを
詳細に調べて楽しむ
2024年10月27日 JJUG CCC 2024 Fall
株式会社NTTデータグループ
阪田浩一

© 2024 NTT DATA Japan Corporation 2
自己紹介
阪田浩一 Koichi SAKATA
株式会社NTTデータグループ所属
Javaチャンピオン
OpenJDKコミッタ
JVMがとにかく好き
jyukutyo

速習クラスファイル
3

クラスファイル
void main() {
println("He
}
0101010101010
javacコマンドなどを実行すると
Javaコンパイラが動作する
ソースファイル
• 実行に必要な情報を持つ
- バイトコードやコンスタントプールなど

0101010101010
cafe babe 0000 0034 001d 0a00 0600
0f09 0010 0011 0800 120a 0013 0014
0700 1507 0016 0100 063c 696e 6974
3e01 0003 2829 5601 0004 436f 6465
0100 0f4c 696e 654e 756d 6265 7254
...
バイナリエディタで開く
16進数形式
（バイナリファイル）

クラスファイル概観
• https://blog.lse.epita.fr/2014/04/28/0xcafebabe-java-class-file-format-
an-overview.html

Attributes
• クラスフィールドメソッドに含まれる情報を保持する
• たとえば以下のものを表現するために使用する
- コード
- ローカル変数や定数値
- スタックや例外に関する情報
- インナークラスやBootstrapメソッド
- アノテーション
- 非推奨やシグネチャなどの補足情報
今回はAttributesにある内容について
いくつか話します

javapコマンドで逆アセンブル
0101010101010
cafe babe 0000 0034 001d 0a00 0600
0f09 0010 0011 0800 120a 0013 0014
0700 1507 0016 0100 063c 696e 6974
3e01 0003 2829 5601 0004 436f 6465
0100 0f4c 696e 654e 756d 6265 7254
...
javap -c HelloWorld
class HelloWorld {
HelloWorld();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String...);
Code:
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String Hello, world!
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return

javapコマンド
• -c オプションでクラスファイルを逆アセンブルして表示する
- バイナリファイルであるクラスファイルを読みやすい形式に変換する
• -v オプションをつけて javap を実行すると
逆アセンブルしたクラスファイルの内容を詳細に表示する
• --helpで使用方法やオプションを出力する
• 以後の説明ではクラスファイルの内容は
javap したものを使用します

なぜクラスファイルについて？
動機と目的
1

セッション内容について
• 必要ですか？
- すぐに必要としません
• 役立ちますか？
- すぐに役立つ可能性は極めて低いです
• 楽しいですか？
- Yes!!!
- 興味深い知的に面白いという意味で楽しい

セッション内容について
• 私自身がこうした内容が楽しいし好き
• クラスファイルで一般的に観察することがない部分を
詳細に解説します
- 終了後みなさんが手を動かしてセッション内容を実際に確かめてくれたら
このセッションは大成功

ソースファイルとクラスファイル
1

ソースファイルとクラスファイルの仕様
• JLSとJVMSは別個の仕様である
• Javaコードをクラスファイルに変換するのは
簡単なことではなく JVMSに合わせた複雑な処理となる
- 変換処理をするのがJavaコンパイラである
ファイル仕様
ソースファイル Java言語仕様（JLS）
クラスファイル Java仮想マシン仕様（JVMS）
void main()
println("
}
CAFEBABE
ソースファイルクラスファイル
Javaコンパイラ

Javaコンパイラの動作
コンパイラが以下のことをする場合は…ある？ない？
1. コンパイラがソースファイルにあるメソッド以外で
独自にメソッドを作りクラスファイルに書き込む
（デフォルトコンストラクタ以外で）
- ある！
2. 同じソースファイルでもJDKのバージョンが異なると
生成するクラスファイルの内容が変わることがある
- ある！
• 上記2つの点を見ていきましょう！

コンパイラが作るメソッド
1

なぜコンパイラがメソッドを作るのか
• 例：Java言語仕様（JLS）とJava仮想マシン仕様（JVMS）の違いに起因する場合
• メソッドを作ることで Javaコードの内容をクラスファイルで表現できるため
- 端的に言うと "必要に迫られて"
• コンパイラが作るメソッドを"合成メソッド"と言う

どんなときにメソッドが作られるか
• 例：共変戻り値を使ったとき
public interface ReturnNumber {
Number value();
}
public class ReturnInteger implements ReturnNumber {
public Integer value() {
return Integer.valueOf(0);
}
}

合成メソッド
• $ javap -c ReturnInteger
class ReturnInteger implements ReturnNumber {
public java.lang.Integer value();
Code:
0: iconst_0
1: invokestatic #7 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
4: areturn
public java.lang.Number value();
Code:
0: aload_0
1: invokevirtual #13 // Method value:()Ljava/lang/Integer;
4: areturn
実装クラスに書いていない
Numberを戻り値とするvalue()メソッドがある！

速習バイトコード（メソッド呼び出し）
• 5種類のinvoke命令
Code:
...
バイトコード命令内容
invokestatic staticメソッド呼び出し
invokevirtual インスタンスメソッド呼び出し
invokespecial コンストラクタ privateメソッドスーパークラスメソッド呼び出し
invokeinterface インタフェースメソッド呼び出し
invokedynamic 動的に算出したコールサイト（後述）呼び出し

合成メソッド
• $ javap -c ReturnInteger
class ReturnInteger implements ReturnNumber {
public java.lang.Integer value();
Code:
0: iconst_0
4: areturn
Code:
0: aload_0
4: areturn

合成メソッド
• $ javap -v ReturnInteger
descriptor: ()Ljava/lang/Number;
flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
4: areturn
• javap コマンドで合成メソッドを確認できる
• SYNTHETIC とは合成という意味である
• ソースコードのメソッド定義から派生させて作る
合成メソッドを"ブリッジメソッド"と言う
合成メソッド
ブリッジ
メソッド

このセッションの確認ポイント
- コンパイラが合成メソッドを作り書き込む
生成するクラスファイルの内容が変わる

合成メソッドとインナークラス
2

なぜインナークラスなのか
理由：
1. インナークラスで特定のコードを書くと合成メソッドを作っていた（JDK 10まで）
2. 1をコンパイルしたときのクラスファイルの内容が変わった（JDK 11から）
解説すること：
• どのようなコードでそうなるのかを見る
• なぜ合成メソッドを作るのかを確認する
• なぜクラスファイルの内容を変えたのかを確認する

復習: インナークラスのインスタンス生成コード
public class Outer {
class Inner {
}
public static void main(String[] args) {
// Innerインスタンスを生成するときは以下のように書く
new Outer().new Inner();
}
}

合成メソッドを作るコード例
private void m_outerpriv() {
System.out.println("called m_outerpriv");
}
class Inner {
public void test() {
new Outer().m_outerpriv();
}
}
new Outer().new Inner().test();
}
}
• インナークラスからアウタークラスのprivateメンバにアクセスする[1]
[1] https://docs.oracle.com/javase/specs/jls/se23/html/jls-6.html#jls-6.6.1
実行の流れ

JDK 10以前でコンパイルしたクラスファイル
class Outer$Inner {
...
public void test();
Code:
0: new #3 // class Outer
3: dup
4: invokespecial #4 // Method Outer."<init>":()V
7: invokestatic #5 // Method Outer.access$000:(LOuter;)V
10: return
}
• $ javap -c Outer¥$Inner
コードは
new Outer().m_outerpriv()
だったのに！？

JDK 10以前でコンパイルしたクラスファイル
...
static void access$000(Outer);
descriptor: (LOuter;)V
flags: ACC_STATIC, ACC_SYNTHETIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method m_outerpriv:()V
4: return
}
• $ javap -v Outer
SYNTHETICだが
BRIDGEではない

インナークラスからアウタークラスのprivateメソッド呼び出し（JDK 10以前）
Innterクラスでは：
ソースファイルクラスファイル
Outerインスタンスの
privateメソッド m_outerpriv() を呼び出す
Outer.access$000(Outer)
というstaticメソッドを呼び出す
Outerクラスでは：
• access$000(Outer) というstaticな合成メソッドを作った
• access$000メソッド内で
引数のOuterインスタンスに対し m_outerpriv() を呼び出す
合成メソッドを経由して
privateメソッドの呼び出しを実現している

なぜ合成メソッドを経由させるのか
JDK 10までの JVMS $5.4.4 より引用
A field or method R is accessible to a class or interface D if and only if any of
the following is true:
...
• R is private and is declared in D.
フィールドまたはメソッドRにアクセス可能なクラスまたはインタフェースDとは、以下のことが真となる
場合のみに限る。
...
• Rがprivateでその宣言がDにある。
https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-5.html#jvms-5.4.4
JVMではインナークラスといった概念は
サポートされていないということ

この実装であることの問題と課題
• ネストクラスからの別のネストクラスへのリフレクションによるメソッド呼び出しで
Errorが発生するケースがある
• Method Handle APIで直接ルックアップできないケースがある
• シール・クラスの追加が予定されていた
- JDK 17にて正式リリース
• ジェネリクス特殊化も予定されている
よってJVMSのネスト関連の仕様を
変更することにした

ネストメイト
3

JVMSの変更とクラスファイル
• JDK 11で仕様変更によりネスト関連のコードに対し
コンパイラは異なるクラスファイルを生成するようになった
$ javap -c Outer¥$Inner（JDK 11でコンパイルしたクラス）
class Outer$Inner {
public void test();
Code:
0: new #7 // class Outer
3: dup
4: invokespecial #9 // Method Outer."<init>":()V
7: invokevirtual #10 // Method Outer.m_outerpriv:()V
10: return
} Outerクラスにあった合成メソッドも
作られなくなった

合成メソッドなしでどう実現したのか
• 新概念"Nestmates（ネストメイト）"
- mateの意味は"仲間" クラスメイトチームメイトルームメイト
• クラスファイルにある属性という項目に新しい属性を定義する
- NestHost
- NestMembers

合成メソッドなしでどう実現したのか
• 新概念"Nestmates（ネストメイト）"
- mateの意味は"仲間" クラスメイトチームメイトルームメイト
• クラスファイルにある属性という項目に新しい属性を定義する
- NestHost
- NestMembers
ネストクラスを持つクラスネストしたクラス
保持する属性 NestMembers NestHost
クラス
ネストした
クラス
NestMemberの値
でわかる
NestHostの値
でわかる

NestHostとNestMembers
$ javap -v Outer
public class Outer
...
NestMembers:
Outer$Inner
$ javap -v Outer¥$Inner
class Outer$Inner
...
NestHost: class Outer
JVMSも合わせて
変更している
JDK 23のJVMS $5.4.4 より引用
A field or method R is accessible to a
class or interface D if and only if any
of the following is true:
...
• R is private and is declared by a
class or interface C that belongs to
the same nest as D, according to
the nestmate test below.
https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-5.html#jvms-5.4.4

このセッションの確認ポイント
- コンパイラが合成メソッドを作り書き込む
生成するクラスファイルの内容が変わる
- たとえば10以前と11以降でネストメイト関連が異なる

ここまで何を話してきたのか何を伝えたいのか
• 最初に書いたときからコードはずっと同じである
• どのバージョンでコンパイルしても同じ動作をする
- 言い換えると使うだけならとくに知らなくてよいことばかり話している
• 調べる過程深まる知識面白い！楽しい！
- みなさんもそう感じているならこのセッションは成功
- このような内容は技術力のバックボーンでもある

クラスファイルの内容変更と
JVMの改善
4

多数の文字列を一気に結合したことありますか
private String
f0="1", f1="1", f2="1", f3="1", f4="1", f5="1", f6="1", f7="1", f8="1", f9="1",
f10="1", f11="1", f12="1", f13="1", f14="1", f15="1", f16="1", f17="1", f18="1", f19="1",
f20="1", f21="1", f22="1", f23="1", f24="1", f25="1", f26="1", f27="1", f28="1", f29="1",
f30="1", f31="1", f32="1", f33="1", f34="1", f35="1", f36="1", f37="1", f38="1", f39="1",
f40="1", f41="1", f42="1", f43="1", f44="1", f45="1", f46="1", f47="1", f48="1", f49="1",
f50="1", f51="1", f52="1", f53="1", f54="1", f55="1", f56="1", f57="1", f58="1", f59="1",
f60="1", f61="1", f62="1", f63="1", f64="1", f65="1", f66="1", f67="1", f68="1", f69="1",
f70="1", f71="1", f72="1", f73="1", f74="1", f75="1", f76="1", f77="1", f78="1", f79="1",
f80="1", f81="1", f82="1", f83="1", f84="1", f85="1", f86="1", f87="1", f88="1", f89="1",
f90="1", f91="1", f92="1", f93="1", f94="1", f95="1", f96="1", f97="1", f98="1", f99="1",
f100="1",f101="1",f102="1",f103="1",f104="1",f105="1",f106="1",f107="1",f108="1",f109="1",
f110="1",f111="1",f112="1",f113="1",f114="1",f115="1",f116="1",f117="1",f118="1",f119="1",
f120="1",f121="1",f122="1";
public String toString() {
return f0+","+ f1+","+ f2+","+ f3+","+ f4+","+ f5+","+ f6+","+ f7+","+ f8+","+ f9+","
+ f10+","+ f11+","+ f12+","+ f13+","+ f14+","+ f15+","+ f16+","+ f17+","+ f18+","
+ ... ","
+f120+","+f121+","+f122;
}
123個のStringオブジェクトを
カンマ区切りで結合する

実行するとどうなる？（JDK 22相当で試行）
1. クラッシュする
2. 正常に動作する
3. ハードウェアリソースを激しく消費しながら動作する
4. エラーが発生する
long start = System.currentTimeMillis();
long sink = 0L;
while (System.currentTimeMillis() - start < 60000) {
sink += new Test().toString().length();
}
System.out.println(sink);
}
意図としては
多数回実行させたい

実行はできるがメモリを大量消費する（つまり3が正解）
https://bugs.openjdk.org/browse/JDK-8327247
23で解消済み

補足説明
• C2
- OpenJDKのJVMであるHotSpot VMが
持つ2種類のJITコンパイラのうちの1つ
- もう1つがC1コンパイラ
• C1とC2の違い
- C1はコンパイル時間は短いが
生成する機械語は速くない
- C2はコンパイル時間が長くなるが
生成する機械語が速い
- HotSpot VMはデフォルトでは
両方とも使用する（階層型コンパイル）
- 単純化して述べると
あるメソッドを一定回数使用するとまずC1
さらに多く使用すると再度C2でJITコンパイルする

実行するとどうなる？（JDK 22相当で試行）
long start = System.currentTimeMillis();
long sink = 0L;
while (System.currentTimeMillis() - start < 60000) {
sink += new Test().toString().length();
}
System.out.println(sink);
}
多数回実行して
C2でコンパイルさせたい

JDK 22相当で試してみた
$ java -XX:CompileCommand=MemStat,Test::toString,print Test
c1 Arena usage Test::toString(()Ljava/lang/String;): 23795992 [na 0 ra 22814112]
(33712->23829704->23829704)
c2 Arena usage Test::toString(()Ljava/lang/String;): 1169778424 [na 136679016 ra 1004706496]
(33712->1169812136->2521320)
Compilation memory statistics
Legend:
total : memory allocated via arenas while compiling
NA : ...how much in node arenas (if c2)
RA : ...how much in resource areas
result : Result: 'ok' finished successfully, 'oom' hit memory limit, 'err' compilation failed
...
total NA RA result #nodes time type #rc thread
1169778424 136679016 1004706496 ok 128797 25.622 c2 2 0x00007ffaf80e20c0
method
Test::toString(()Ljava/lang/String;) このJITコンパイルだけで
メモリ1.1Gを使用
(Linux-x64, Intel(R) Xeon(R) Platinum 8260M CPU @ 2.40GHz) OpenJDK 22相当

発生状況を整理する
• JDK 8は問題なし
- チケットでは8u401で問題なし手元の8u275でも問題なし
• JDK 9 - 22で発生する
- 注：文字列結合すべてで発生するわけではない一般的な結合では問題なし
- v1 + " " + v2 + " " + ... + " " + vn の
n を1つ増やすと急激にメモリ消費量と時間が増加
• JDK 9以降で文字列結合に関連する変更はあったか？

文字列結合のindy化
注：indy化により結合の実行パフォーマンスが
向上したケースが多くあり今回の問題は
大多数の問題がないケースに対する
まれなバグケースに過ぎない

発生原因
• indyとはバイトコード命令のinvokeDynamicのこと
• indy化によって文字列結合でこうしたパターンがあると
問題が発生するようになっていた
• 原因は文字列結合処理の内部詳細でスコープ外だが
クラスファイルという主題から以下のことを見ていく
- indy化の前はどうだったのか
- なぜ文字列結合処理を変更したのか
- indy化とは何をすることなのか

単純化したクラス（変数 + リテラルの文字列結合）
public class Test2 {
private String f0 = "1";
@Override
public String toString() {
return f0 + ",";
}
}

Java 8までの文字列結合に対するバイトコード（クラスファイル内容）
// Java 8まで
new #4 // class java/lang/StringBuilder
dup
invokespecial #5 // Method java/lang/StringBuilder."<init>":()V
aload_0
getfield #3 // Field f0:Ljava/lang/String;
invokevirtual #6 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
ldc #7 // String ,
invokevirtual #8 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
$ javap -c Test2
この処理自体は何も問題がない
ではなぜ indy化という変更をしたのか？

Java 8までの実装の問題点
• 処理自体に問題はない
• 文字列結合は頻繁に呼び出す処理であり
実行パフォーマンスの面から今後変更したいという要望はあり得る
- ただしクラスファイルへの出力内容を変更する必要がある
そのためにはコンパイラも変更しなければならない
• もし実行パフォーマンスを改善するために
クラスファイルやコンパイラを変更せずに
JVMを変更するだけで済む方法があるならそうしたい
Java 7で追加したバイトコード invokeDynamic (indy) を
使うことでこの要望を実現できる！

文字列結合のindy化
// Java 8まで
new #4 // class java/lang/StringBuilder
dup
invokespecial #5 // Method java/lang/StringBuilder."<init>":()V
aload_0
ldc #7 // String ,
invokevirtual #8 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
$ javap -c Test2
// Java 9以降
aload_0
invokedynamic #15, 0 // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
areturn

invokeDynamic（indy）
• 実行時にコールするメソッドを決定できるような仕組みを提供する
- JVM言語には動的型付け言語（JRubyなど）があり
そうした言語の実行パフォーマンス向上のため
• この命令の初回実行前に任意の処理を実行できるというメリットがある
- この処理を実行するメソッドをBootstrapメソッドと言う
- Bootstrapの内容として動的メソッド検索に限る必要はなく他にも活用できる
- たとえばBootstrapで何らかの処理をするメソッドを作って返し命令の実行としてそれを呼び出せる
- Javaでも8でのラムダ式で使い始め
その後文字列結合レコードクラス switch式/文でのパターンマッチなどでも使用
• indyだけで1セッションできるような内容のため詳細な説明はしません
- 参考になる他の方のセッション資料: https://speakerdeck.com/yujisoftware/invokedynamic-under-the-hood

文字列結合でのindy
• (不正確だが簡潔にわかりやすく述べると）
文字列結合ではクラスファイルに invokeDynamic とだけ出力しておいて
結合処理の内容はBootstrap内で実装してしまおうということ
$ javap -v Test2
• クラスファイルは以降変更しなくてよい
• 関連する実装を修正するだけで
文字列結合処理を改善できる

文字列結合でのindy
• (不正確だが簡潔にわかりやすく述べると）
文字列結合ではクラスファイルに invokeDynamic とだけ出力しておいて
結合処理の内容はBootstrap内で実装してしまおうということ
$ javap -v Test2
...
aload_0
invokedynamic #15, 0 // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
areturn
}
BootstrapMethods:
0: #28 invokestatic java/lang/invoke/StringConcatFactory.makeConcatWithConstants:
(Ljava/lang/invoke/MethodHandles$Lookup;
Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;
[Ljava/lang/Object;
)Ljava/lang/invoke/CallSite;
Method arguments:
#26 ,
StringConcatFactoryクラスの
makeConcatWithConstantsメソッドが
indyのBootstrapメソッドとなる

JDK 23での問題解消
• StringConcatFactoryクラスを修正した

JDK 23での問題解消
• StringConcatFactoryクラスを修正した
$ java -XX:CompileCommand=MemStat,Test::toString,print Test
...
Compilation memory statistics
Legend:
total : memory allocated via arenas while compiling
...
（以下は抜粋です）
total NA RA result #nodes limit time type method
6419424 2456608 1374856 err 2621 1024M 0.390 c2 Test::toString(()Ljava/lang/S
1243664 0 1112752 ok - 1024M 0.393 c1 Test::toString(()Ljava/lang/S

文字列結合は
indy化で何を得たか
5

引用: JEP 280 Indify String Concatenation 前後のパフォーマンス比較
JDK 10以降の
各バージョンで
さらに改善している
(Linux-x64, Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz)
• https://cl4es.github.io/presentations/jvmls2024/draft.html

indy化のメリットデメリット
メリットデメリット
• クラスファイルの出力内容を変えずに
改善作業ができる
• 再コンパイルをしなくてもバージョンを
上げるだけで改善内容を適用できる
• StringBuilder実装よりも
JITコンパイルを適用しやすい
• 仕組み上初回実行時
Bootstrap分のオーバーヘッドがある
(JDK 9だと30〜90ミリ秒[1]）
後続のBootstrapでは
上記オーバーヘッドの一部のみ実行
[1] https://cl4es.github.io/2019/05/14/String-Concat-Redux.html
• 9以降とくに13までバージョンごとにオーバーヘッドを
削減してきた
• 最新の計測データはないが初回でも
実行時間はJDK 8よりやや重い程度
• 結果として文字列結合全体のスループットは
大きく向上した

文字列結合の改善詳細
• このセッションのスコープ外です
• JVM Language Summit 2024ではその内容のセッションがありました
興味のある方は録画を観ることをおすすめします
- Re-thinking Java String Concatenation
- https://youtu.be/tgX38gvMpjs?si=lwVLxi2jElYIRgyZ

• 最初に書いたときからコードはずっと同じである
• 実行するJavaのバージョンを上げるだけで
全体的な実行パフォーマンスは向上する
• どのようにコードを書くのか機能を使うのかだけではなく
どのように動いているのかを調べることはとても楽しい

まとめ
6

• 共変戻り値で合成メソッドを見ました
• ネストメイトでJDK 11前後のクラスファイル差異を見ました
• 文字列結合のindy化でランタイムの改善を見ました
このセッションが終わったら…
• 上記の内容を実際に手を動かして見てみよう！
• 文字列結合の改善内容をもっと詳しく調べてみよう！
• indyを含むバイトコードについても調べてみよう！

静かに変わってきたクラスファイルを詳細に調べて楽しむ（JJUG CCC 2024 Fall講演資料）

静かに変わってきたクラスファイルを詳細に調べて楽しむ（JJUG CCC 2024 Fall講演資料）

More Related Content

What's hot

Similar to 静かに変わってきたクラスファイルを詳細に調べて楽しむ（JJUG CCC 2024 Fall講演資料）

More from NTT DATA Technology & Innovation

静かに変わってきたクラスファイルを詳細に調べて楽しむ（JJUG CCC 2024 Fall講演資料）