Re: finalization (Re: struct timeval)
kono@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> いや、明示的にウィンドウは閉じてGCにやらせるべきではないって
> ことか。その時に、ウィンドウのOS/Window System の資源が解放
> されれば良くて、メモリはGCで解放されれば良いってことかぁ。
> それはどうかなぁ。
でも、実際にそうしてません? 参照が残っていてもWindowCloseイベントが来
たらウィンドウは閉じるし、通信が終ったらソケットは閉じるでしょ。
プログラムの外の資源への参照を、メモリ管理だけに任せるのはあんまり良く
ないと思いますねえ。他に手がなければ仕方がないですけど。あるいは保険と
して使うとかね。
# だからlast resort。
> > 標準Cで書けない(標準Javaでもできない)ような部分、たとえばGCとかスター
> > トアップルーチンとかスレッドライブラリとかを書く時、Jikesなんかは、が
> > んがん言語を拡張しちゃってますね。「このインターフェースを使っておくと
> > JITコンパイラが特別扱いしてインライン展開する」とかね。 処理系の中でし
> > か使わないので別にかまわない。まあCだろうとJavaだろうと、そうするしか
> > ないんだけど。
>
> まぁ、そうしても、もちろんいいんだけど「とりあえず、Java で
> 頑張る」っていう段階があるはずだと思う。(んだけど、あきらめ
> つつあります...)
>
> いや、もう少し頑張れば「リアルタイムだと今のJavaでは、Cの半
> 分の速度」ってのを乗り越えられるかも知れないんだけど、いまん
> ところはだめってな所ですね。
具体的な話が分からないと何ともいえないですが、メモリ管理の話だとすると、
メモリ管理やGCの研究者のコンセンサスとしては、
・GCがある言語で、自分でメモリ管理(再利用とか)しようとすると大概かえっ
て遅くなる。
ということになっています。
(cf.)
http://java.sun.com/docs/hotspot/gc1.4.2/faq.html のQ.31
http://www-106.ibm.com/developerworks/library/j-jtp01274.html#3.0
http://citeseer.nj.nec.com/zorn92measured.html
前田敦司
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735