- PR -

仕様書からメモリサイズを予測する

1|2 次のページへ»
投稿者投稿内容
すひろ
大ベテラン
会議室デビュー日: 2006/10/17
投稿数: 124
お住まい・勤務地: 愛知県
投稿日時: 2006-10-25 23:24
詳細設計で作られた各種ドキュメント（クラス仕様書や入出力仕様書など）をもとに、
実際にコーディングするオブジェクトが使用するメモリの使用サイズの目安を概算する方法を考えています。

java言語と直接関係なくて申し訳ありませんが、
こんな方法があるよ、とか、こんな風にしたらいいよ、など、
些細な事でもかまいませんのでアドバイスをお願いします。
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2006-10-26 09:19
「オブジェクトのサイズの目安を計算する方法」の方ですか？
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=34414&forum=12&2
質問を投げっぱなしですが、解決されたのでしょうか。

仕様書に暮らすのフィールドと型が記載されているのなら、
それを元に目安測定用の型を自動生成してコンパイルして
getObjectSize()を取得するようなプログラムを書けばよいのではないでしょうか。
javacはプログラム内から使う方法もあるわけですし。
すひろ
大ベテラン
会議室デビュー日: 2006/10/17
投稿数: 124
お住まい・勤務地: 愛知県
投稿日時: 2006-10-26 21:33
すみません、下書きをしておきながら書き込みするのを忘れていました。

JDKは1.4.2を使っているため、getObjectSize()は使うことができません。

http://d.hatena.ne.jp/minghai/20060319/p1

上記のようなページを見つけたのですが、
これは既にコーディングが終わっているものに対しての計測方法ですよね…。
coasm
大ベテラン
会議室デビュー日: 2001/11/26
投稿数: 237
投稿日時: 2006-10-26 23:18
厳密に言うと実装依存なわけですが、単純に
インスタンスのサイズ ＝ 非staticメンバー変数のサイズの総和 ＋ 基底クラスのサイズ
になります。

メンバー変数のサイズは、
・double と long は8バイト
・それ以外の primitive型は、一律4バイト
・オブジェクト参照は4バイト。参照先のオブジェクトが占めるメモリーは別途。

データメンバーを持たないクラスであるObject型のサイズは8バイト
（C++で言うところの vfptrに4バイト ＋ ゴミ集めの管理用に4バイト？）

C++ と違って、
・配列が直接埋め込まれることがない（必ず配列オブジェクトへの参照になる）。
・仮想基底がない。
・多重継承がない。
・byte/char/short は常にpaddigされる。
ので、非常にシンプルです。

配列の実体は、要素サイズ×要素数＋12バイト。
この時はpaddingされないので、byte の要素サイズは１、char/shortの要素サイズは2です。
加納正和
ぬし
会議室デビュー日: 2004/01/28
投稿数: 332
お住まい・勤務地: 首都圏
投稿日時: 2006-10-27 00:37
引用:

coasmさんの書き込み (2006-10-26 23:18) より:
厳密に言うと実装依存なわけですが、単純に
インスタンスのサイズ ＝ 非staticメンバー変数のサイズの総和 ＋ 基底クラスのサイズ
になります。


んー、でもそれの「基底」言ってしまうと何が基底かは、実装するまで分からないのでは。

ぐーぜん(?)暗号ライブラリを別実装にする、DI使うとか、いろいろある場合は
jarファイルをメモリに読み込むことになるわけで。

もちろん、コンピュータのメモリ容量を「先に」見積もりたいというのはよく分かるのですが。顧客に16GBメモリのサーバを買っていただくのはいいけど

「なぜ16GBなの?」
「しかも2台?」

といわれるのも悲しい。。。Javaはメモリ全量は分からないのだ、、
と顧客が納得してくれるといいのだが(無理)
coasm
大ベテラン
会議室デビュー日: 2001/11/26
投稿数: 237
投稿日時: 2006-10-27 01:49
まあ確かに、「フレームワークが提供している型」から派生したクラスなんかだと、
「基底クラスのサイズが見当つかない」という状況になるかも(苦笑)

C++なら「ヘッダファイルを読めば何とかなる」でしょうけど、
Javaだと「jarファイルしか提供されていない」かもしれませんから・・・・
coasm
大ベテラン
会議室デビュー日: 2001/11/26
投稿数: 237
投稿日時: 2006-10-27 01:57
ん？
引用:

ぐーぜん(?)暗号ライブラリを別実装にする、DI使うとか、いろいろある場合は
jarファイルをメモリに読み込むことになるわけで。


Interfaceとして宣言されているオブジェクトの実際の型が何であるかは実行時まで決まりませんが、
継承元の基底型が何であるかはコンパイル時には確定しているはずです。

「型は確定しても、サイズの見当がつかん！」という苦情は、
ライブラリ開発者宛てに、どうぞ。

[ メッセージ編集済み 編集者: coasm 編集日時 2006-10-27 01:57 ]
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2006-10-27 08:56
引用:

coasmさんの書き込み (2006-10-27 01:57) より:
Interfaceとして宣言されているオブジェクトの実際の型が何であるかは実行時まで決まりませんが、
継承元の基底型が何であるかはコンパイル時には確定しているはずです。


継承元クラスは判明しているので、事前にオブジェクトサイズは分かりますよね。
そして継承して追加した分だけのフィールドのサイズを足せば概算はできる、
というわけですよね。

フィールドに型をもっていた場合でもJavaの場合は参照を持つだけなので
参照先の型の実行時サイズなんて関係ありませんし。

まぁ、もろもろ勘案して計算するのは面倒なので、私はやはり
引用:

仕様書に暮らすのフィールドと型が記載されているのなら、
それを元に目安測定用の型を自動生成してコンパイルして
getObjectSize()を取得するようなプログラムを書けばよいのではないでしょうか。

という案で推したいと思います。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）