回答編集履歴
5
追記
answer
CHANGED
|
@@ -42,5 +42,5 @@
|
|
|
42
42
|
(追記)
|
|
43
43
|
64ビット環境だと「あるオブジェクトのアドレス」を表すのには本来64ビットのメモリスペースが必要なわけですが、"ヒープの最大サイズが設定されたらそのアドレス以降にデータが置かれることがあり得ない"とか、"64ビット単位でアラインされてデータが置かれる"とかいった状況があるため（ヒープの最大サイズが十分に小さければ）実際にはもっと小さいメモリスペースで済ませれます。
|
|
44
44
|
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済むような仕組みが入っているようです。
|
|
45
|
-
[https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html](https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html)
|
|
45
|
+
（[https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html](https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html) をコメントにて教えていただきました）
|
|
46
|
-
おそらくは
|
|
46
|
+
おそらくはその仕組みのためと思われますが、ヒープの最大サイズが32GB以下か32GBより大きいかで、返ってくる数値が変わるという現象が確認できます。
|
4
些細
answer
CHANGED
|
@@ -40,7 +40,7 @@
|
|
|
40
40
|
----
|
|
41
41
|
|
|
42
42
|
(追記)
|
|
43
|
-
64ビット環境だと「あるオブジェクトのアドレス」を表すのには本来64ビットのメモリスペースが必要なわけですが、ヒープの最大サイズが
|
|
43
|
+
64ビット環境だと「あるオブジェクトのアドレス」を表すのには本来64ビットのメモリスペースが必要なわけですが、"ヒープの最大サイズが設定されたらそのアドレス以降にデータが置かれることがあり得ない"とか、"64ビット単位でアラインされてデータが置かれる"とかいった状況があるため（ヒープの最大サイズが十分に小さければ）実際にはもっと小さいメモリスペースで済ませれます。
|
|
44
44
|
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済むような仕組みが入っているようです。
|
|
45
45
|
[https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html](https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html)
|
|
46
|
-
その
|
|
46
|
+
おそらくは上記の理由から、ヒープの最大サイズが32GB以下か32GBより大きいかで、返ってくる数値が変わるという現象が確認できます。
|
3
追記
answer
CHANGED
|
@@ -42,4 +42,5 @@
|
|
|
42
42
|
(追記)
|
|
43
43
|
64ビット環境だと「あるオブジェクトのアドレス」を表すのには本来64ビットのメモリスペースが必要なわけですが、ヒープの最大サイズが十分に小さければ、"あるアドレス以降にデータが置かれることがあり得ない"とか、"64ビット単位でアラインされてデータが置かれる"という状況があるためもっと小さいメモリスペースで済みます。
|
|
44
44
|
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済むような仕組みが入っているようです。
|
|
45
|
+
[https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html](https://www.oracle.com/technetwork/jp/articles/java/compressedoops-427542-ja.html)
|
|
45
46
|
そのためヒープの最大サイズが32GB以下か32GBより大きいかで、返ってくる数値が変わるという現象が確認できます。
|
2
些細
answer
CHANGED
|
@@ -41,5 +41,5 @@
|
|
|
41
41
|
|
|
42
42
|
(追記)
|
|
43
43
|
64ビット環境だと「あるオブジェクトのアドレス」を表すのには本来64ビットのメモリスペースが必要なわけですが、ヒープの最大サイズが十分に小さければ、"あるアドレス以降にデータが置かれることがあり得ない"とか、"64ビット単位でアラインされてデータが置かれる"という状況があるためもっと小さいメモリスペースで済みます。
|
|
44
|
-
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済む
|
|
44
|
+
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済むような仕組みが入っているようです。
|
|
45
45
|
そのためヒープの最大サイズが32GB以下か32GBより大きいかで、返ってくる数値が変わるという現象が確認できます。
|
1
まとめ
answer
CHANGED
|
@@ -35,4 +35,11 @@
|
|
|
35
35
|
プリミティブデータの大きさは言語仕様で決まっているので、（非staticフィールドが同じなのに）違いがあるなら、メモリの[アラインメント](https://e-words.jp/w/%E3%82%A2%E3%83%A9%E3%82%A4%E3%83%A1%E3%83%B3%E3%83%88.html)の影響が一番"ありそう"です。
|
|
36
36
|
|
|
37
37
|
32bit JREと64bit JREではメモリのアラインメントが違って、推定サイズが変わるのは間違いないでしょう。
|
|
38
|
-
それ以外で（同じバージョンのJREで）メモリのアラインメントに違いがでることがあるか? となると不明です。上記の通り、java-sizeofのコードを追いかけつつ違いを検証していくことになるかと思います。
|
|
38
|
+
それ以外で（同じバージョンのJREで）メモリのアラインメントに違いがでることがあるか? となると不明です。上記の通り、java-sizeofのコードを追いかけつつ違いを検証していくことになるかと思います。
|
|
39
|
+
|
|
40
|
+
----
|
|
41
|
+
|
|
42
|
+
(追記)
|
|
43
|
+
64ビット環境だと「あるオブジェクトのアドレス」を表すのには本来64ビットのメモリスペースが必要なわけですが、ヒープの最大サイズが十分に小さければ、"あるアドレス以降にデータが置かれることがあり得ない"とか、"64ビット単位でアラインされてデータが置かれる"という状況があるためもっと小さいメモリスペースで済みます。
|
|
44
|
+
64ビットOpenJDK実装には、ヒープの最大が32GB以下である時に限り「あるオブジェクトのアドレス」を表すデータ構造が32ビットで済む（32bitに圧縮する）ような仕組みが入っているようです。
|
|
45
|
+
そのためヒープの最大サイズが32GB以下か32GBより大きいかで、返ってくる数値が変わるという現象が確認できます。
|