2/29 (日)
[Java] SIGPLAN の Online Membership になる
仕事柄 PLDI、OOPSLA、Java Grande、ISMM あたりの論文を読む必要があるので、ACM の SIGPLAN の Online Membership に参加。
一年で U.S. $35 なり。
今までは「なんとなく」入手した PDF を読んでいたのだが、このあたりも正規化しておく。
管理人が知らないうちに Eclipse (eclipse'03) や仮想マシン & シミュレーター(IVME'03)の workshop が開催されていたのを知る。 OOPSLA'03 には GC の論文が 6 本でている。 スループットよりも GC ストップ時間の短縮に主眼が置かれている。
以下、論文を読んだりして自分が思ったことの覚え書き。
- スレッドローカルなガーベージコレクションは
リアルな J2EE アプリでは役に立たないかもしれない。
Tomcat は 同一のセッションであっても リクエスト毎に 処理される Java スレッドが切り替わる可能性がある。 その場合、 セッションの持つデータが複数のスレッドで共有されてしまう。 だとするとスレッドローカルなオブジェクトを回収し尽くすことは無理。
- Java には、
ライフタイムが近いオブジェクトをまとめて一つのオブジェクトして管理しようという
Object Inlining とか Object Combining という研究が結構ある。
結局、
C# でいうところの struct がないため
解析的な手法で struct で書けそうなところを探しているわけだ。
だがソフトウェア設計に UML が導入されつつあるので、 コンポジション(composition) 関係の部分に注目して object inlinig を 検討すれば(解析的にやるよりも) 効率よく絞り込めるように思える。 つまり UML から Java クラスのスケルトンを吐く段階でコンポジション関係のある場所に 特別な annotation を入れておけばよい。 現時点でもclass Parent { private final Child field1 = new Child(); private final Child field2 = new Child(); }
と final をフィールドに付けておけば、 コンポジションは示せると思われる。
(それを使ってどう効率化するかは、その後のアイデア次第。)
- Reference Counting (RC) は
SMP 特性が低くサイクリックな参照を持つオブジェクトが回収できないため、
モダ〜ンな JavaVM には使われなくなっている。
ただ、
いろいろ新しい論文も出て高速化が行われているので
再考の余地があるかも。
特に RC だとオブジェクトがガーベージになったタイミングがかなりはっきり掴める。 finalize メソッドをナイ〜ブに使用した Java プログラムを プログラマーの意図通りに動かすことができるかも知れない。
今年は ISMM'04 があるし、 なんかアイデアが形になればいいような気がする。
P.S.
しかし ACM の Web サイトは見通しの悪い Web サイトだ。 同じ Web サイト上を動いているのに何度もアカウント/パスワードを要求される。 説明がまったく要領を得ない。
@acm.org のフォワーディングメールアドレスが使えるはずなのに、これを enable にする方法が分からずじまい。
覚え書き
実家にジャンボマッシュルームが届いたみたい。
2/28 (土)
S.J. 氏にお会いする
メールでやりとりをしていた S.J. 氏に田園都市線の鷺沼で直接お会いする。
S.J. 氏は○○○○○○○情報システムにお勤めで、アーキテクチャ設計・分析に携わっているといるそうだ。
いろいろ話を伺うが、開発の主流はやっぱり C/C++ から Java や .NET に移っていて、プログラマーも「Java から入りました」という人が増えているそうな。
明治は遠くなりけり。
S.J. 氏の行きつけの焼肉屋「龍昇苑」で食事をする。
ほとんど刺し身の牛肉などが食べられる穴場だそうだが、最近は米の BSE の騒ぎで肉が手に入らずたいへんらしい。
覚え書き
早朝(日曜日)、まだ暗い道を走ってアパートに帰っている最中に何かに足を取られてひっくりこける。脛を強打。
高校卒業以降なかった派手な転び方だが、(体重の増加と共に)慣性モーメントが増加しているのでかなりのダメージ。
外傷はないが、今日は動けそうにない。
2/27 (金)
携帯電話の買い替え
携帯電話のバッテリーがへたれてまったく電話が掛けられなくなった(spam メールだけは時々届くのに)。
しょうがないので携帯電話を買い直すことにした。
すでに x900i が出ているが FOMA (W-CDMA 方式) だと山口県に帰った時にちゃんとカバーされているか不安が残る。
これが最後と3台目も mova (PDC方式) の P252i を選択。
前が P209iS だったので P252i は一足飛びの進化をしているのが体感できる。
携帯にカメラ機能が付いたことは知っていたが、「miniSD カード」というものが存在することを知ったのは P252i を買った後だった。
いろいろ多機能のようなので、次に乗り換えるまでには操作をマスターしよう。
P.S.
P252i にはデータリンクソフトの提供もあるのね。
2/26 (木)
[Java] JNI 内でエラーが起こったら
毎度の Java の話。
Java Native Interface の中でエラーが起こった場合、
その動作は基本的に未定義だが
ほとんどの場合 JavaVM が停止してしまう。
その停止の仕方についてメモをしておく。
ネイティブメソッド内でスタックオーバーフローが発生した場合どのようになるかを検証。 サンプルプログラム を作成し、x86/Linux (kernel version v2.4.19)上で確認。
Sun Hotspot VM 1.3.1_09 |
コアを出力後、
標準エラー出力に大量のエラー情報が出力される。
同じ内容のファイルが hs_err_pidnnnn.log に出力される。 ただし、 JNI が落ちた原因を特定できるよう 表示は含まれない。 |
---|---|
Sun Hotspot VM 1.4.2_03 | 同上。 |
IBM Java2 1.3.1 SR6 |
コア出力後、
以下のような 5 行のメッセージを
標準エラー出力に表示。
stackpointer=0xbffc7a78
javacoreほげほげ.txt に
より詳細な情報が出力されるが、
JNI が落ちた原因が特定できる情報は含まれない。
JVMXM004: JVM is performing abort shutdown sequence JVMDG217: Dump Handler is Processing a Signal - Please Wait. JVMDG303: JVM Requesting Java core file JVMDG304: Java core file written to /homen/minoru/javacore8660.1077897484.txt JVMDG215: Dump Handler has Processed Exception Signal 11. |
IBM Java2 1.4.1 SR1 |
コア出力後、
以下のような 5 行のメッセージを
標準エラー出力に表示。
Unrecoverable Stack Overflow: addr=400a2549, ee=80515e4, er=bffc8ad0
唯一、原因がスタックオーバーフローだと特定できている。
javacoreほげほげ.txt に
より詳細な情報が出力される。
JVMDG217: Dump Handler is Processing a Signal - Please Wait. JVMDG303: JVM Requesting Java core file JVMDG304: Java core file written to /home/nminoru/javacore.20040228.005932.8693.txt JVMDG215: Dump Handler has Processed Exception Signal 11. |
BEA JRockit 1.4.2_03 | コアを出力するだけ。 |
基本的にどの JavaVM でもコアをはいて停止し、プログラムの継続はできなかった。
エラー原因の特定という意味では IBM と SUN の VM は同程度の情報を出力しているが、SUN の VM は詳細な情報まで標準エラー出力してしまうので画面が見づらい。
BEA はほとんど何も表示せずに停止。
2/25 (水)
呪われている
一昨日にアパートの鍵を無くして大騒ぎをしたばかりなのに、色々な物が一度に壊れてたいへんなことに。。。
- 携帯電話 (DoCoMo P209iS) がついに通信不能に!
バッテリがへたったのか、 アンテナが立っているのは電源を入れて1分ぐらい。 受信状態が良好のはずの場所でも圏外になってしまう。 - 家のディスプレイ(iiyama の MT-8617E) の画面がぐらぐら揺れるようになってしまった!
接続した PC の状態とは無関係のようなのでやはりディスプレイが悪いのか。。。
日興證券にバイトに行っていたころに貰ったトリニトロンディスプレイだから、 5 年以上使ってきたので天寿をまっとうしたとは言えるが、 PC9801 シリーズが接続できる水平同期周波数 24kHz が 無くなるのは痛い。
眼鏡のフレームもガタガタいっているしなんか憑いているよ。
NHK のみんなのうた
NHK の「みんなのうた」のファンサイトみんなのうた缶 によると、「みんなのうた」の DVD が2004年4月下旬に発売になるそうだ。
1961年から2002年までの歌から160曲が12巻ボックスセットで 38,400円。
生きていてようかったなり。
1,000曲以上ある「みんなのうた」だから、160曲ピックアップでは全体の 10% 程度。
個人的には以下のような曲を希望。
- 「ふたごのオオカミ大冒険」
- 「元祖バナナの魂」
- 「小さな木の実」
- 「44ひきのねこ」
- 「わたしのにゃんこ」
- 「へんな家」
- 「青空とタップダンス」
- 「アスタ・ルエゴ」
- 「まっくら森の歌」
- 「雪祭り」
E.L. カニグスバーグの「クローディアの秘密」を読んだ日本の少年・少女は、みんな「メトロポリタンミュージアム」を視たんだろうなぁ。
追記:3/31
NHK 「みんなのうた」の DVD コレクションの発売日と収録曲の公開され、先行予約が始まった(ここ)。
2/24 (火)
[MyWeb] 日記 (diary) が牛乳屋 (dairy) になっていた
2002年の 10 月から日記をつけて公開しているのだが、その URL がhttp://www.nminoru.jp/~nminoru/dairy/になっていたことに今日初めて気づいた… あちゃ〜〜。
急いで http://www.nminoru.jp/~nminoru/diary/ に修正したが、すでにいろいろリンクが張られているので dairy の方はシンボリックリンクとして残しておく。
ジャンボマッシュルーム
ジャンボマッシュルームを購入できるオンラインショップを発見。
楽天に出展している 田舎倶楽部 なり。
早速注文。
2/22 (日)
アパートの鍵なくします
秋葉原まで出かけて、仕事に必要になりそうな Advanced Windows を購入。
ついでに激しく萌えた燃えたヤマギワソフト館を見物に行く。
1階から3階ぐらいまでは白い覆いがかぶさっているよ。
秋葉原からは職場に帰って夜2時ごろまで仕事をする。
さすがに疲れたので徒歩20分のアパートまでトボトボと歩いて帰るが、中間地点でポケットの中にアパートの鍵が入っていないことに気づく。
カバンの中を総ざらいするがない。
鍵を落としてしまったようだ (;_;)
ヤマギワソフト館の呪いだ。。。
追記:追記:2/23
当然、部屋には入れないので職場に引き戻って机の上で一夜を明かす。
日が昇ってから管理人をしている綱島駅前の不動産屋に行ってスペアのキーを借り、
合鍵を作成する。
2/21 (土)
パワーダウン中
引っ越した部屋は6畳の和室と4.5畳の洋室なのだが微妙に狭い。
計測したところ引越し前の寮の部屋は 334cm×253cm だったが今の部屋は 327cm×232cm。10% ぐらい狭い。
とにくかくダンボールの山積みになっている和室を使えるようにするために、午前中は引越しの荷物を解く。
寮には洗濯機と乾燥機があったのだが、ここは周りにコインランドリーがない。
午後からは、遠出をしてコインランドリーに行く。
洗濯機を買うまでは毎週土曜日は洗濯曜日だ。トホホ
P.S.
引越しの荷物の中からスティグリッツの 「入門経済学」 を発見。
経済学の勉強をし直そうと、引越し前に買ったものだ。
洗濯をしながら、ぼちぼち読み始める。
2/20 (金)
田中先生の最終講義と臨時のエンゲル係数を高める会
田中英彦教授が定年退官なさるため、最終講義 が開催される。
場所は浅野キャンパスに最近できた 武田先端知ビル の 5 階。
VDEC が入っている施設だ。
いろいろな大学関連、メーカー、その他とOB や関係者がワラワラやってくる。
懇親会後、現役生と若い OB 計11名で「龍虎殿」 に食事へ行く。
龍虎殿は不忍池のそばにある福健料理がベースの中華料理屋。
昨年の 6/1 の日記 と同様
3,500 円の食べ放題のコースを選択。
その他、チンジャオロースとかを頼んだ記憶がある。
デザートは全種類頼むことができまする。
P.S.
卒業後 TI に行く N 氏に、豆腐料理の 響 と
築地市場内の 魚四季 を奨められたのでチェックしておく。
「魚四季」ではまぐろのカマを食べるようにとのこと。
2/19 (木)
Yahoo! Slurp が来ていた
www.nminoru.jp の Apache ログを見ていると、見慣れない User-Agent があるのに気がついた。
"Yahoo-MMCrawler/3.x (mm dash crawler at trd dot overture dot com)"
噂の Yahoo! の Web 検索システム Yahoo! Slurp のようだ。
ログをさかのぼってみると今年の 1/26 に初めて訪問しており、2/11 にも一回来ている。
ただ、いずれも /robots.txt
の GET を試みただけでお帰りだ。
米 Yahoo! は Google の使用をやめて、20億ドル以上を掛けて独自の検索システムに移行するそうだ。
だけど Yahoo! Slurp なのか Yahoo-MMCrwaler なのかすら判然としないし、クローラーの User-Agent には対応ページへの URL が入っていないし、そもそもうちのサイトのページを全然持っていかなし、こんな調子で大丈夫かしら?
2/18 (水)
[CPU] IA-32e
Intel Developer Forum (IDF) では従来 Yamhill と呼ばれていて IA-32 の 64 ビット拡張が AMD64 と互換があることが発表された。 いろいろ話は聞いていたので驚きはないが、各メーカーの Itanium2 の戦略に凄い影響を与えそうだ。
Intel の IA-32 の 64 ビット拡張と AMD64 の互換性はユーザーにとっては巨大なメリットだが、用語の混乱だけは残りそう。 両者は実質的に同じ仕様なのだが、Intel はこれを AMD64 と呼ばずに IA-32e と呼ぶことにしたようだ。 2 社の間で名称がバラバラである。 Microsoft は X64 と呼ぶようにしたみたいだ。
追記:2/28
Intel の IA-32e 関連のページはここ。
[Java] Eclipse (公式)
管理人は Java 開発者なのに長らく eclipse を使っていなかったが、eclipse 関連の開発の仕事がきそうになるので Win32 版の 2.1.2 を導入して自分でも使用することにした。
これまで eclipse を使用しなかったのは、eclipse のウィンドウが Active になるとそのウィンドウを一番前面に出てくる点に不満を覚えていたから。 通常の Windows はウィンドウの一部をクリックした時にアクティブになるが、Tweak UI を使うとフォーカスのあるウィンドウをアクティブにできるX Window System 風のスタイルにカスタマイズできる (X-Mouse)。 この設定の場合には、マウスカーソルを eclipse に入れるとうぃ〜んとウィンドウが浮かび上がってしまう。 どうも WM_SETFOCUS メッセージか WM_ACTIVE メッセージの処理の中で、Z-Order を変えている余分なコードを挟み込んでいるようにみえる。
IDE のような長時間使うソフトが自分の感覚と合わないのはつらいのでこれまで避けていたが、仕事で使うようになるので気合を入れて修正してしまおう。
追記:4/26
問題が少し解決した (4/15 の日記) 。
IBM Rational Rose (公式)
Rational Rose をゲット。
UML 推進ということでソフトの開発に IBM Rational Rose を使うことになったのだ。
Rational が IBM に買収される前に導入が決まったのだが、手元に届いた CD-ROM は IBM の文字が。。。
Visual Studio 6 から Visual Studio .NET 2003 への移行もあって、開発環境の再構築には時間が掛りそう。
2/17 (火)
通信速度が遅かったのは やっぱり ルーターのせいだった
2/10 に B フレッツが開通したのにちっとも速くならないネットワーク。
通信速度測定サイト speed.rbbtoday で計測しても、上りも下りも 3 Mbps。
SPEED 2.0 (speed.rbbtoday.com) Date: Mon Feb 16 01:39:02 JST 2004 Download : 3.29Mbps Upload : 3.18Mbps
原因を調査していたのだが、結局 WAN と LAN をルーティングしていたメルコの WLAR-L11-L の能力不足が原因だったようだ。 1.5Mbps ADSL しかなかった頃のルーターなので必要最低限のパワーなのね。
川崎のさくら屋に行ってブロードバンドルーターを物色。 さすが安さが売りの量販店では、最新の機種が置いていない (目当ての Linksys のルーターは旧機種もない)。 しょうがないので 5,800 円で売っていたバッファローの BBR-4HG を買って帰る。
つないで測り直した結果は下の通り。
SPEED 2.0 (speed.rbbtoday.com) Date: Tue Feb 17 23:09:40 JST 2004 Download : 28.7Mbps Upload : 9.41Mbps
今度はインターリンクの回線速度のせいだね。 間違いなく。
追記:2/20
WLAR-L11-L の時は VPN マルチパススルーを使おうとすると2回に1回ぐらいはハングアップしていたが、BBR-4HG に替えてから症状がでなくなった。吉。
天下一品@川崎店 (公式)
ルーターを購入するついでに天下一品の川崎店でラーメンを食べる。
管理人のカメラの腕が悪いため写真を見てもピンとこないが、すごい粘度 & 濃度のスープだ。
豚骨スープの底の方に溜まっている「ザラザラ」だけを集めたような食感がある(鶏と野菜がベース)。
このラーメンと豚骨ラーメンの違いは、正油ラーメンと豚骨ラーメンの違いよりも大きい。
本を購入
今まで読んだことがなかった「20世紀の最高傑作」ジェイムズ・ジョイスの「ユリシーズ」を読み始める。
集英社文庫の丸谷才一・永川玲二・高松雄一訳。
第一章の『テレマコス』を読んだ感想だが、、、、、、うひゃぁ、この本最後まで読まなきゃ駄目かなぁ?
この単庫本はまったく同じ厚みで 4 巻まであるしなぁ。
寝る前に引越しの荷物の中からジュリアン バーンズの「10と1/2章で書かれた世界の歴史」を探して口直しに読もう。
2/16 (月)
[Prog] UNIX で API フック
プロセスの中で自らが使う共有ライブラリの呼び出し、スーパーバイザーコール、シグナルにフックを掛けたいと思いいろいろ調査する。
Windows の場合のやり方は、Internals.com のサイトにある API Spying Techniques for Windows 9x, NT and 2000 というページにいろいろなフックの概要が書かれているし、"Advanced Windows" という本に詳細が載っているは知っているのだが、UNIX (具体的には Linux と Solaris) でのやり方が不明。
いろいろな人に聞いて廻った結果、Windows の SetWindowsHookEx API のような便利なフック API は Linux にも Solaris にもないということだけは判明。 あまりスマートでないアイデアが残る。
- dlopen、dlsym が入っている共有ライブラリを
フックライブラリに置きかえる。
例えば Linux の場合には dlopen は libc.so に入っているから、
dlopen エントリーを持ったダミー libc.so を作成して、
環境変数 LD_PRELOAD で読み込む
(Solaris なら LD_AUDIT)。
そうすれば DLL 関連のイベントが捕まえられるようになる。
- ptrace API を使えば システムコールがフックできる。 ただし ptrace はフックしたいプロセスの 親プロセスとして監視用のプロセスが必要になり、 ターゲットのプロセスはシステムコールが起こるたびに停止してしまう (性能劣化)。
- Patching。 共有ライブラリ呼び出しのための Import Address Table を書き換えてしまう。 同様に ABI も、、、
- システムを loopback デバイスの中に閉じ込めれば ディスクアクセスに関係するすべてのイベントが拾える (共有ライブラリが開かれたかどうかも判明)。
- コードを動的にディスアセンブルして、、、
- chroot をして、、、
- User Mode Linux を、、、
とりあえず 1. の検証のために Linux で dlopen と dlclose をフックするダミー libc.so を作成。 libc.so を作成する。
#define GNU SOURCE 1 #include <stdio.h> #include <dlfcn.h> typedef void* (*DLOPEN_FUNC)(const char *filename, int flag); typedef int (*DLCLOSE_FUNC)(void *handle); static DLOPEN FUNC abi_dlopen; static DLCLOSE FUNC abi_dlclose; void* dlopen(const char *filename, int flag) { if( abi_dlopen == NULL ) abi_dlopen = (DLOPEN_FUNC) dlsym(RTLD_NEXT, "dlopen"); fprintf(stderr, "dlopen: %s\n", filename); return abi_dlopen(filename, flag); } int dlclose(void *handle) { if( abi_dlclose == NULL ) abi_dlclose = (DLCLOSE_FUNC) dlsym(RTLD_NEXT, "dlclose"); fprintf(stderr, "dlclose"); return abi_dlclose(handle); }
上のプログラムを dlopen.c で保存しコンパイル & リンク。 libc.so のパスを環境変数 LD_PRELOAD にセットする。
> gcc -fPIC -g -c dlopen.c ; gcc -shared -o libc.so dlopen.o > export LD_PRELOAD=/home/home/hoge/libc.so
この後 実行されたプログラムの中で共有ライブラリがオープン・クローズされるたびに
標準エラー出力にログが残るようになる。
この手法で malloc でも _exit でも好きな共有ライブラリコールをフックできるが、
dlsym 関数自身はフックできない。
フック対象のオリジナルの関数ポインタを得るのに dlsym 関数を使わざる得ないからだ。
だが、dlsym がフックできないと汎用的な共有ライブラリコールフックにならない。
二律背反
さてどうしたものか。。。
オリジナルの dlsym と同じコードを、
ダミーの libc.so に転写するしかないかしら?
[OS] Solaris10
Register の記事 によると SUN は Solaris 10 (Sun OS 2.10 ?) を 2004 年の後半に出すらしい。
- SPARC 32-bit/64-bit、x86 版、AMD64 版があるらしい。
こっちの記事 によると 8 月に Solaris for AMD64 が出るとあるが、 Solaris9 か Solaris10 なのかは不明。 - N1 Grid を載せてくるらしい。
- DTrace tool と呼ばれるハードウェア診断、故障予測、 危険部位の切り離しができるツールがつくらしい。
でも、 Solaris10 が出たら Solaris7、8、9、10 と サポートせにゃならんのね。
追記:2/20
SUN から Previewing the Next Solaris OS with Sun's Software Express Program というページが公開される。
[Java] Java で書かれた SVG ライブラリ
Apache XML Project の一つに Batik SVG Toolkit というのがあったようだ。
今まで知らなかったのだが結構いい。
今度使ってみることにする。
[CPU] さよなら IA-64
Intel の某チップについて衝撃的な話を聞いたにょ。
予想されていたけど、各所にいろいろ激震が走るだろうなぁ。。。
まぁ来月の頭には Itanium2 サーバー(hp rx2600)が届くし、今は自分の仕事をやろう。
追記:10/12
すでに明らかになったので書くけど、噂されていた IA-32 の 64-bit 拡張が AMD64 と互換があるということを、発表前に聞いたという話です。
2/13 (金)
今日は 13 日の金曜日
どうでもいいけど。
[CPU] Chip-Multi-Processor が続々登場
hp から最新の PA-RISC PA-8800 が登場。
1つの CPU の上に PA-8700 のコアを 2 つ載せた CMP プロセッサーだ。
www.spec.org のページには PA-8800 のマルチタスク時のスループット性能を計測した
SEPCint_rate2000、SEPCfp_rate2000 スコアは乗っているが、逐次プログラムを起動してから完了するまでの時間を計測した SEPCint2000、SEPCfp2000 スコアは公開されていない。
PA-8700 と PA-8800 の int_rate2000 と fp_rate2000 の値から比較すると、PA-8000 の int2000、fp2000 スコアは下表の網掛け部分のようになると予測される。
Benchmark | PA-8700 (750MHz) | PA-8800 (1,000MHz) | ||||
---|---|---|---|---|---|---|
int2000 | rp5470 | 1 CPU | 549 (517) | 1CPU | 817 (780) | |
fp2000 | rp5470 | 1 CPU | 522 (462) | 1CPU | 933 (863) | |
int_rate2000 | rp5470 | 2 CPU | 12.5 (11.8) | rp4440-8 | 2 CPU | 18.6 (17.8) |
fp_rate2000 | rp5470 | 2 CPU | 10.8 (9.53) | rp4440-8 | 2 CPU | 19.3 (17.8) |
Sun からは SPARC V9 のチップ UltraSPARC IV が登場。 Sun は CMT (CMP + SMT を指すようだ) と呼んでいるが UltraSPARC IV は単なる CMP になるようだ。
[Bench] SPEC CPU2000 のスコアが微妙に更新される
2 月になって SPEC CPU2000 にいくつかデータが登録されたが、int2000 と fp2000 は過去のマシンの取り直しデータのみ。
IBM の POWER4+ 1700 MHz が fp2000 で 1,699 → 1,776、HP が Itanium2 1500 MHz で int2000 が 1,322 → 1,404 となった。
最近は いよいよ CPU2000 への登録が少なくなってきて寂しい。 AMD は Athlon64 3400+ は登録待ちだと思われるが、それ以外にも以下のような CPU が登録されていない。
- Intel Pentium-M
- MIPS R16000
- IBM PowerPC 970
- hp PA-RISC PA-8800
- Sun UltraSPARC IV
CPU2000 も、もうそろそろ終わりね。
さよなら MorphyOne
MorphyWiKi によると佐川豊秋氏は免責決定が官報に掲載され、MorphyOne に関するすべてが終わったそうだ。 南無三。
2/12 (木)
NETGEAR GSM7324
NETGEAR の 24 ポート インテリジェント Layer3 Gigabit Switch GSM7324 を購入してもらったので、ネットワークの張り替えを行う。
IAサーバー 5 台、クライアント 5 台、32ノードのクラスタもどきを接続する。
マニュアル を読みながら設定を行うが、あんまり変わったところのない普通の Layer3 Switch のようだ。
GSM7324 の選定をする時に、Gigabit Ethernet の口が 24 ポート付くネットワーク機器のピンからキリまでにどのぐらいの値段・機能の幅があるか調べたことがある。 下のようなネットワーク機器のヒエラルキーが高くなる毎に値段も高くなる。
- Repeator (Layer1 Switch?)
-
物理層だけを接続する。
Ethernet では 100 BASE-TX 以前にあたいわゆるダムハブが該当。 1000 BASE-T では相当するものがなくなった。 - Bridge (Layer2 Switch)
-
データリンク層を接続・交換する。
Ethernet の MAC アドレスを見て経路制御する、いわゆるスイッチングハブが該当。 VLAN 機能などもこの階層に含まれる。
この装置の動作は ネットワーク層のプロトコル(IP、IPX、AppleTalk) に依存しない。 - Router (Layer3 Switch)
-
ネットワーク層を接続・交換する。
IP ネットワークの場合、 ネットワークアドレスを見て制御ができるものが該当。
NAT はこの階層に含まれる (しかし、最近の NAT は TCP/UDP 層の情報も使うから微妙)。 - Gateway (Layer7? Switch)
- Layer3 よりも上ということで トランスポート層(TCP や UDP) やあるいはそれよりも上位の アプリケーション層(HTTP や FTP) を認識して制御できるもの。
Layer2 Switch としては Planex の FX-0224NW。
これは単なるスイッチングハブで、定価48,800円で最安値。
同じく Planex が FMG-24K を出している。
参考価格が 50 万円で VLAN の構成や SNMP などで監視ができるインテリジェントタイプの Layer2 Switch。
ただ、ほとんど同じ価格で Layer3 Switch の GSM7324 が買える。
Layer7 Switch としては Extreme Networks の Summit5i 〜 Summit7i がある。
HTTP のクッキーを使ったロードバランサーなど機能的には無敵。
お値段は 300 万円超だがカスタム次第でもっと高くできる。
というわけで FX-0024NW 〜 Summit7i で値段差は 100 倍程度。
24 ポートの GoE で、FX-0024NW よりも安いものとか Summit?i よりも高いものって存在するのかしら?
覚え書き
友人 S は山口に帰ったようだ。バイバイ。
2/11 (水)
ついに引っ越し完了
風邪は治り切らないがとにかく引っ越しだ。
引っ越し業者は 17 〜 19 時の間にくる予定だ。
こっちは昨日の夜からずっと荷作りしているのにいつまでたっても終わらないぞ。
一ヶ月前から段ボール詰めをはじめていたのだが、もう 3 倍ぐらい前準備をしておくべきだったと後悔。
18 時になって業者がやってくる。
予定は遅れ気味、引っ越し業者のあんちゃん(2人)も疲れ気味だ。
荷物のほとんどは本の詰まった段ボール。
エスカレーターのない 4 階から荷物をダウンロードして、やっぱりエスカレーターのない 2 階へ荷物をアップロードする。
それでも引越し代は 34,000 円なり。
普段、使用しない筋肉が軋む。 とにかく今日は寝よう。
2/10 (火)
祝・光ファイバー開通
これまで www.nminoru.jp は寮に引いた 1.5Mbps の ADSL で繋がっていたが、新居の光ファイバー工事が完了したので引っ越しに先駆けてサーバーの移転を行った。
追記:2/13
転居前の住居に引いた Flet's ADSL (1.5Mbps) / INTERLINK は、ftp の転送速度が下りが 0.8 Mbps 上りが 0.4 Mbps 程度だった。
転居後の B-Flet's はフレッツスクウェアまでの下り回線速度が 60 Mbps !!
しかし INTERLINK を介した ftp 転送では下りで 3 Mbps 程度しか出ていない。
こんなものなのかしら?
[時事] ヤマギワソフト館が火事
2/10 に秋葉原のヤマギワソフト館が火事になる。
友人からその映像を貰ったので掲載。
2/8 (日)
元住吉の幸楽苑
元住吉の商店街(ブレーメン通り)に新しくできた
ラーメン屋 幸楽苑 へ行ってみる。
前は売れない中華料理店があったが、
このラーメンのチェーン店に変わったてからは
店の前に行列ができるようになった。
昼過ぎに管理人が並んだときも
前に 2 人ほど並んでいる人がいた。
食べ終わった後には 6 〜 7 人が並んでいた。
メニューはたくさんあるが今回は みそラーメンを注文。
幸楽苑のみそラーメンは最初から唐辛子が入っていてピリリと辛い。
とんこつラーメンの
一蘭 を思わせる味だ。
とりあえず近場にまともなラーメン屋ができたことに多謝。
P.S.
ラーメン食べた後は、
帰って引っ越しの荷作りをして一日が終わる。
2/7 (土)
山口の友人 S 氏は今も神奈川県に滞在中
友人 S 氏に
また会う。
今回は横浜の中華街で飯を食べて、川崎チネチッタで RotK を見るのが目的。
先日、地下鉄 みなとみらい線 (横浜駅〜元町・中華街駅) が開通したので早速乗ってみる。 東急東横線連絡なので横浜中華街へ行くのが非常に便利になった。 終点の (中華街がある) 元町・中華街駅はなぜか厳戒体制で 5メーター間隔ぐらいで 駅員が立っていた。 何かあったのかしら? |
![]() |
みなとみらい線の駅から出た所にある中華街の入口。 右の写真は関帝廟。 |
![]() ![]() |
山下公園。 |
![]() ![]() |
昼飯は S 氏の希望で四川料理店に。 |
![]() ![]() ![]() |
中華街からみなとみらい21の方へ向かう。 |
![]() ![]() ![]() |
川崎チネチッタで
16:20 の部の
the Return of the King の先行ロードショーを鑑賞。 |
|
映画を見た後は「天龍」というラーメン屋で飯を食べる。 |
![]() ![]() ![]() |
2/6 (金)
今日のメモ
風邪ひき状態を継続中。
[CPU][Windows] AMD64 用 の Windows の評価版が公開される
Microsoft から Windows XP、の評価版の ISO イメージがダウンロード可能になった。 Windows Server 2003 の評価版もダウンロード可能。 AMD64 用の Platform SDK を落としてくれば開発も可能。
Wolfram の New Kind of Science がオンラインで無料公開
/. の記事 によると Stephen Wolfram 氏の New Kind of Science (NKS と略すようだ) がオンラインで無料公開されたようだ。
/. の記事の方はコメント数が 400 を越えて続いており、やはり論争を呼ぶ本だということが伺える。
1/19 の日記 の下の方にちょろっと書いたが、管理人はこの本を 日本語で 読みたいと常々思っている。
志の有る人が翻訳してくれないかと心待ちにしている(他力本願)。
[Trivia] 西暦 2038年問題
UNIX はエポック(1970 年 1月 1日 0時 0分 0秒)からの (閏秒を補正しない) 経過秒数を Unix Time としてカウントしている。 Unix Time を 32 ビット数値で保持している旧来のプログラムは、2038年 1月 19日 3時 14分 8秒 にカウンターが溢れて元に戻り誤動作するようになる。 これが西暦 2038 年問題。
しかし西暦 2038 年問題の前に 2004 年問題が起きた。 2004年 1月 10日 22時 37分 04 秒はエポックから 2^30 秒後 にあたり Unix Time が signed int 型をオーバーフローさせてしまい不注意なプログラムが動かなくなる危険性があった。 で、実際に ATM がトラブってしまった(【スクープ】コンピュータの“西暦2038年問題”発生、早くも日本を揺るがす)。
2000年問題の時にはあれだけ準備を重ねて、ソフト & ハードのベンダーの中には SE は大晦日〜元旦はホテル待機という所が多かったのに、今回は何の準備もなし。 油断が仇となったもよう。
2/5 (木)
8年ぶりに病院へ行く
風邪が酷くなったので保健証を持って病院に行く。
診察をする医者も風邪引きらしく、マスクを付けてゴホゴホしている。
抗生物質、その他の薬を貰って帰る。 抗生物質を飲むのは中学校以来だよ。
2/4 (水)
[Java] 自家製の針で商用 JavaVM をチクチク刺してみる (Part 1)
随分前に Exact GC と Conservative GC の話を書こうと思っていたのだが、間があき過ぎて続きを書くのが億劫になり放置していた。
いまさら続きを書くのも何なのでちょっと方向を変え、Sun J2SE 1.3.1_09、1.4.2_03、IBM VM 1.3.1 SR6、1.4.1 SR1、BEA JRockit 1.4.2_03 の 5 つの商用 JavaVM を使って
Exact GC と Conservative GC の違いを洗い出してみる。
この中では Sun の 2 つの VM は間違いなく Exact GC で、残りは Conservative GC (のはず)。
以降のテスト環境は Vine Linux 2.6 r3 (kernel 2.4.19-0vl26)。
実験 1。
この実験では GC によってガーベージを正しく回収できるかどうかをチェックする。
つまり、ガーベージの回収漏れが生じる Conservative GC の特徴をつついてみる。
GcTest5.java というプログラムを実行した場合の挙動。
このプログラムは、JavaVM 起動後に 4 * 1024 * 1024 個の要素を持つ int 型の配列を確保し、それをすぐ捨ててしまう。
起動直後、配列確保後、配列開放後の以降に java.lang.System.gc() を呼び出し強制的にガーベージコレクションを発生させ、その度にヒープの使用量を計測する。
JavaVM | Sun J2SE 1.3.1_09 | Sun J2SE 1.4.2_03 | BEA JRockit 1.4.2_03 | BEA JRockit 1.4.2_03 | BEA JRockit 1.4.2_03 | IBM VM 1.3.1 SR6 | IBM VM 1.4.1 SR1 |
---|---|---|---|---|---|---|---|
追加オプション (Default: -Xmx64m -Xms64m) |
-server -Xbatch | -server -Xbatch | -Xgc:singlecon | -Xgc:gencon | -Xgc:parallel | ||
起動時 | 101,968 | 103,312 | 3,924,352 | 4,293,840 | 3,924,352 | 848,376 | 1,223,304 |
オブジェクト確保 | 16,878,880 | 16,880,312 | 20,701,584 | 21,071,976 | 20,701,584 | 17,625,536 | 17,951,896 |
1回目の GC | 102,000 | 103,368 | 3,925,320 | 21,071,976 | 3,925,320 | 17,627,600 | 17,951,824 |
2回目の GC | 101,584 | 103,016 | 3,925,320 | 21,071,976 | 3,925,320 | 850,368 | 117,4592 |
まずJavaVM によって起動直後のメモリ使用量が随分違うのに驚かされる。 おそらく JavaVM に読み込まれたクラスファイルの実体をヒープに置くかどうかや、ライブラリの内部で使用されるオブジェクトの量が影響を与えているのだと思われる。 4M 要素の int 型配列を確保するとオブジェクト確保後のメモリ使用量は「起動時」に 16MB を足したものになる(「オブジェクト確保」)。 その後 スコープの外に抜けて配列への唯一の参照が失われ、巨大配列はどこからも参照不能な状態となる。
この後で GC を起こせば巨大配列はガーベージとして回収されメモリの使用量は「起動時」の水準までもどるべきなのだが、5 VM・7 設定中で元にもどれるのは 4 つのみ。 IBM の 2 つの VM は 青字の値 のように最初の VM では回収されず、BEA JRockit の -Xgc:gencon オプション指定時は 赤字の値 のように何度 GC を行っても回収されない。
原因として考えられるのは、
- Conservative GC の特徴 - 例えば オブジェクトの参照がローカル変数からクリアされて どこからも辿れなくなったように見えても、 レジスタの中に値が残っていたりするとガーベージとして回収できない。 IBM VM は1回目の GC では回収できないが、2回目では回収できているので このパターンにはまった可能性がある。
- GC の戦略 - メモリが本当に逼迫するまでガーベージがあっても回収しないでおくという戦略を取る GC が存在する。 JRockit の -Xgc:gencon のように何度実行しても回収されないのは このパターンのかもしれない。
- System.gc() では本当の GC が起きない - java.lang.System.gc() は J2SE の API だが 「回収可能なすべてのオブジェクトをきっちり回収すること」という 制限は存在しないので、適当に実装されている可能性はある。
さまざまな原因が考えられるが、赤字、青字 の状態は GC を起こしたのにガーベージが回収されていないように見えて、プログラム的に好ましくない。
実験 2。
場合によって GC が意図しないほど重くなってしまうパターンがあることをチェックする。
GcTest6.class、
GcTest6$DummyObj.class というプログラムの実行時間を計測してみると、以下の表のようになる。
JavaVM | オプション | 実行時間 (ミリ秒) |
---|---|---|
Sun J2SE 1.3.1_09 | -server -Xbatch -Xmx64m -Xms64m | 144,502 |
Sun J2SE 1.4.2_03 | -server -Xbatch -Xmx64m -Xms64m | 28,660 |
IBM VM 1.3.1 SR6 | -Xmx64m -Xms64m | 40,715 |
IBM VM 1.4.1 SR1 | -Xmx64m -Xms64m | 2,055 |
BEA JRockit 1.4.2_03 | -Xgc:singlecon -Xmx64m -Xms64m | 7,707 |
-Xgc:gencon -Xmx64m -Xms64m | 7,780 | |
-Xgc:parallel -Xmx64m -Xms64m | 7,752 |
見ての通りだが、最速と最遅の間に 70 倍の速度差がうまれている。 一応、Sun J2SE 1.4.2_03 > IBM VM 1.3.1 SR6 となっているが、条件によっては SUN J2SE 1.4.2_03 はもっと遅くなるのでこの差は逆転する可能性がある。
では、なんでこんなに差がつくかというと、、、、、、、、、、それは秘密です。
2/2 (月)
2/1 (日)
[Compiler] GCC (g++) の vptr の問題点
C++ の処理系のほとんどは polymorphism の実現のために Virtual Table(vtbl) と Virtual Table Pointer(vptr) を用いるのだが、他の処理系と比べて gcc は vptr の位置はちょっと変ですという話。
以下のような C++ プログラムを LP32 の処理系でコンパイルした場合、クラス Base は sizeof(int) × 2 で 8 バイト以外に隠された vptr ポインタの 4 バイトが含まれる。
#include <stdio.h> #define XFieldOffset(CLASS,FIELD) ((char*)(&((CLASS*)0)->FIELD)-0) class Base { public: int field1; int field2; virtual void dummy() {} }; class Derived : public Base { public: int field3; }; int main(int argc, char** argv){ printf("size of Derived = %d\n", sizeof(Derived) ); printf("field1 = %d\n", XFieldOffset(Derived,field1) ); printf("field2 = %d\n", XFieldOffset(Derived,field2) ); printf("field3 = %d\n", XFieldOffset(Derived,field3) ); return 0; }
問題は vptr ポインタのある位置。
クラス Base の vptr の位置は Visual C++ や Sun Forte C++ などは先頭部分にあるのに対して、GCC では最後尾にくる。
|
|
これは継承を考えなければ問題ないのだが、クラス Base をクラス Derived のように派生さえてメンバ変数を増やした場合、以下のようにはみでてしまう。
|
|
そのため GCC 方式はコンパイルが終わった後のバイナリデータからは vptr の位置が正確には掴めないのだ。
この方がセキュアなのかもしれないけど、デバッグがやりにくい。
という訳で、C++ で virtual メンバ関数を含むクラスを作成する場合には GCC の特殊事情を考慮する必要がある。 Object のようなダミーの polymorphism 基底クラスを作成しておいて、自分の作る polymorphism なクラスは必ずそこから派生させるようにした方がよい。
class Object { public: virtual void dummy() {} };
追記:4/11
上の問題が発現するのは gcc 2 系のみ。
gcc 3 系では他のコンパイラと同様にオブジェクトの先頭に VTBL のポインタを配置する。