Re: finalization (Re: struct timeval)
河野真治 @ 琉球大学情報工学です。
In article <412d9bf8.6984%katoh@pop12.odn.ne.jp>, Hideki Kato <katoh@pop12.odn.ne.jp> writes
> #しかし何で lang.c なの?
(歴史的理由 :-)
> 結局,まだ gc の技術が不十分なんだと思う.
GCの前提って、
new は明示的に行う
reference は、複製可、持ち運び可
reference の消滅は、上書きによって暗黙に行う
って感じですよね。このあたりの前提が間違っているんじゃないかなぁ。
あきらかに scalability のない前提って感じでさ。
GCする言語で再利用する工夫をすると余計遅くなるってことは、なんか
プログラミングに対する制約、あるいは、隠された実行モデルが導入
されているってことなんだよね。そのあたりが、組込みとかメモリ制約
が強い場合、あるいは、下位ライブラリでは厳しい。
> 昔はCでも register とか書
> いてたけど,コンパイラとハードが進歩して,そういうのは書かない方が速
> い(書いても無視される)時代になったよね.河野さんも今さら
> register が使いたいとは言わないよね?
ところが最近、復活していて、しかも、aliasing に関するコンパ
イラ指示みたいなものもあって...
Linux Kernel 2.6 では、大域変数のレジスタ割当てまで復活して
いるみたいですね。どれだけ効果があるのか知らんが...
> つらつら考えるに,,一つのアプリケーション(と言うかタスク)にはこ
> ちょこちょやらないといけないところとと鷹揚に構えてかまわないところが
> 混在してて,それを一つの言語(と言うか,runtime environment)の上で
> 走らせてるのが根本的な原因なんだと思う.この辺りにもう一レベル階層を
> 追加するというのは,実際どうなんだろう?
その階層は、おそらく水平な階層ではないでしょうね。面白いと思うけど。
> #昔からあるアイデアでは gc の対象外領域,ってのがあるけど,余り流行
> #らなかった...低レベル過ぎるからか?
実は、GC抜き + データ構造の工夫でなんとかなるからかなぁ。メモリ Pool
なんかはそんなものだし。
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
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