Re: finalization (Re: struct timeval)
Hideki Kato <katoh@pop12.odn.ne.jp> writes:
> >世界中のGC研究者にとってJavaはありがたい飯の種を提供してくれてると思い
> >ます。
>
> 大いに同感.って事は GC 研究者も増えてるんでしょうか?
> #Lisp も長いこと触ってないなぁ...
イエ、ソレホドデハないと思います。
(応用寄りの研究者は増えていても、システム寄りの研究の人気は下がってい
る気がします。)
> 「本当のリアルタイム制御」と言っても,許される遅れ時間には色々あるわ
> けで,実際問題として「1 ms じゃダメ」ってレベルの応用はそう多くない
> と思います.
> #プラントでもセンサ信号をサンプルする頻度はそう高くない場合が多い.
> #車の EFI 辺りも同程度じゃないかな?
> #そう言えば,ケータイも Java 使ってるとか...
そうなんですけどお。たとえば
「たいてい1ms以内で応答するけど、10秒止まる可能性がないわけではない」
システムは、
「1秒以内なら十分だけど、5秒止まると工場が爆発する可能性がないわけでは
ない」プラントでは使えませんよねえ。
「上限の保証がないと困る」と言われた時に、UnixやWindowsでは保証のしよ
うがないわけで…
(ケータイJavaも、実時間性の不要な対話的アプリにしか使ってないのでは。)
> >うむむ。Facom αとかの話でしょうか。広告に「プラント制御」とか書いてあ
> >るのを見て心配になったことがあります。
>
> 私なんかも最初は心配だったんですが,プラントは「長時間の連続運転に耐
> える」事が最優先で,処理が停まっていられる時間の制約は緩いものも多い
> ようです.
> #詳しくは知らないが,要は内部状態の変化速度との兼ね合いでしょう.
> この点では,(ゆっくりした)メモリーリークの方がずっとずっと問題だと
> 思われます.
最適化のためのプランニングとかをLispでやって、それはリアルタイム性がな
くても良いと言うことなんでしょうかねえ。まあ、リアルタイム応用とは言え
ないような。
> >OSとかHPC用のライブラリとか書くならともかく、ワープロとかブラウザなら
> >全体的に鷹揚に構えていて良いんじゃないでしょうか。
>
> 人間絡みの場合,マウス,キーボード等からの入力に対して 0.1 秒以内に
> 何らかの反応を返さないとまずいという問題があります.これはアプリケー
> ションが介在しないといけないので,「全部」鷹揚ってわけにはいきません
> ねぇ.
> #素人さんは,反応が無いと慌ててキーを連打したりして,さらに処理を遅
> #らせてしまうんだよね.
ただ、そういうのは反応が遅くても仕様通りであることは違いないし、せいぜ
い「qualityが低い」という程度であって、エラーではないですよねえ。そこ
がハードリアルタイムな応用とは違うところで。
> >> >> #昔からあるアイデアでは gc の対象外領域,ってのがあるけど,余り流行
> >> >> #らなかった...低レベル過ぎるからか?
> >
> >Real-time JavaのRegionはそんな感じですね。割と低レベル。
>
> 古く(ルーツ?)は MacLisp の BOX 演算辺りでしょうか.UtiLisp の
> GC に関しても,要望は結構有ったんだけど,大きくいじらないといけない
> からやらなかった.実際,GC に無関係で構わないデータってのもたくさん
> あるんだけど,スマートな見せ方(機能仕様レベル)が難しくて...
Javaだとprimitive type (char, int, float…)はGCに無関係ですね。
C#だとvalue type (int等の他structも含む)があって、これはGCされません。
GCされるreference type (object等) との間でboxing, unboxingが行なえます。
> #実行中のある時点で,今生きているものは回収不要と宣言するってアイデ
> #アもありましたねぇ,そう言えば.実装は簡単なんだけど,なんで作らな
> #かったんだったか...
そういう処理系もありますね。Emacs Lispのpure領域とか。最初はSymbolics
かなあ。
前田敦司
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