回答編集履歴
5
追記
test
CHANGED
|
@@ -86,6 +86,6 @@
|
|
|
86
86
|
|
|
87
87
|
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済むような仕組みが入っているようです。
|
|
88
88
|
|
|
89
|
-
[https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html](https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html)
|
|
89
|
+
（[https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html](https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html) をコメントにて教えていただきました）
|
|
90
90
|
|
|
91
|
-
おそらくは
|
|
91
|
+
おそらくはその仕組みのためと思われますが、ヒープの最大サイズが32GB以下か32GBより大きいかで、返ってくる数値が変わるという現象が確認できます。
|
4
些細
test
CHANGED
|
@@ -82,10 +82,10 @@
|
|
|
82
82
|
|
|
83
83
|
(追記)
|
|
84
84
|
|
|
85
|
-
64ビット環境だと「あるオブジェクトのアドレス」を表すのには本来64ビットのメモリスペースが必要なわけですが、ヒープの最大サイズが
|
|
85
|
+
64ビット環境だと「あるオブジェクトのアドレス」を表すのには本来64ビットのメモリスペースが必要なわけですが、"ヒープの最大サイズが設定されたらそのアドレス以降にデータが置かれることがあり得ない"とか、"64ビット単位でアラインされてデータが置かれる"とかいった状況があるため（ヒープの最大サイズが十分に小さければ）実際にはもっと小さいメモリスペースで済ませれます。
|
|
86
86
|
|
|
87
87
|
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済むような仕組みが入っているようです。
|
|
88
88
|
|
|
89
89
|
[https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html](https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html)
|
|
90
90
|
|
|
91
|
-
その
|
|
91
|
+
おそらくは上記の理由から、ヒープの最大サイズが32GB以下か32GBより大きいかで、返ってくる数値が変わるという現象が確認できます。
|
3
追記
test
CHANGED
|
@@ -86,4 +86,6 @@
|
|
|
86
86
|
|
|
87
87
|
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済むような仕組みが入っているようです。
|
|
88
88
|
|
|
89
|
+
[https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html](https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html)
|
|
90
|
+
|
|
89
91
|
そのためヒープの最大サイズが32GB以下か32GBより大きいかで、返ってくる数値が変わるという現象が確認できます。
|
2
些細
test
CHANGED
|
@@ -84,6 +84,6 @@
|
|
|
84
84
|
|
|
85
85
|
64ビット環境だと「あるオブジェクトのアドレス」を表すのには本来64ビットのメモリスペースが必要なわけですが、ヒープの最大サイズが十分に小さければ、"あるアドレス以降にデータが置かれることがあり得ない"とか、"64ビット単位でアラインされてデータが置かれる"という状況があるためもっと小さいメモリスペースで済みます。
|
|
86
86
|
|
|
87
|
-
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済む
|
|
87
|
+
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済むような仕組みが入っているようです。
|
|
88
88
|
|
|
89
89
|
そのためヒープの最大サイズが32GB以下か32GBより大きいかで、返ってくる数値が変わるという現象が確認できます。
|
1
まとめ
test
CHANGED
|
@@ -73,3 +73,17 @@
|
|
|
73
73
|
32bit JREと64bit JREではメモリのアラインメントが違って、推定サイズが変わるのは間違いないでしょう。
|
|
74
74
|
|
|
75
75
|
それ以外で（同じバージョンのJREで）メモリのアラインメントに違いがでることがあるか? となると不明です。上記の通り、java-sizeofのコードを追いかけつつ違いを検証していくことになるかと思います。
|
|
76
|
+
|
|
77
|
+
|
|
78
|
+
|
|
79
|
+
----
|
|
80
|
+
|
|
81
|
+
|
|
82
|
+
|
|
83
|
+
(追記)
|
|
84
|
+
|
|
85
|
+
64ビット環境だと「あるオブジェクトのアドレス」を表すのには本来64ビットのメモリスペースが必要なわけですが、ヒープの最大サイズが十分に小さければ、"あるアドレス以降にデータが置かれることがあり得ない"とか、"64ビット単位でアラインされてデータが置かれる"という状況があるためもっと小さいメモリスペースで済みます。
|
|
86
|
+
|
|
87
|
+
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済む（32bitに圧縮する）ような仕組みが入っているようです。
|
|
88
|
+
|
|
89
|
+
そのためヒープの最大サイズが32GB以下か32GBより大きいかで、返ってくる数値が変わるという現象が確認できます。
|