フレームはスタック領域に取っても、状況に応じてフレームをポップしない、という実装はありますね。例えば継続が捕捉されたらその時点でスタックにあるフレームはポップしないようにするとか。
スタックが溢れたらそこでGCを走らせて、生きているフレームをヒープに移すと。それを応用すれば、モニターしたい部分だけはフレームを残しておくなんてことも不可能ではないでしょう。
Cf. Scott L. Burson: "Continuations Without Copying", SIGPLAN Notices, 29(5), pp.27-30, 1994.
黒幕は誰だ？ (スコア:1)
僕が耳にした噂では、旧富士はI社のシ
Re:黒幕は誰だ？ (スコア:1)
少し前の朝日新聞の記事によると、よく言われるように全部 ベンダ任せなんじゃなくて、銀行業務の基幹部分はそれぞれの銀行内 のシステム部門が担っているそうで、その部分は非公開なために ベンダ各社もとっても仕事を進めにくい、それが原因でトラブルが起こったんだとか。
だとすると
Re:黒幕は誰だ？ (スコア:0)
統合しようってのに非公開とはどゆこと？
システム部門は統合されないわけ？
非公開→公開したくてもできない→仕様書がない→いゃぁーっ
Re:黒幕は誰だ？ (スコア:4, 興味深い)
>> 銀行業務の基幹部分はそれぞれの銀行内 のシステム部門が担っているそうで、その部分は非公開なために ベンダ各社もとっても仕事を進めにくい
これは無いっす。
>統合しようってのに非公開とはどゆこと？
>システム部門は統合されないわけ？
統合されます。＜案件内容の通りならね
でも、Cobolを生かしたまま、Javaへ移行ってのが絶対条件だったのと、
去年の６月に出た案件（１１月まで案件が
Re:黒幕は誰だ？ (スコア:0)
Re:黒幕は誰だ？ (スコア:1)
Re:黒幕は誰だ？ (スコア:3, 興味深い)
ワタクシですと、勘定系でのcobolの利点というと数値の10進数型くらいしか思い浮かばないので。
# それでもJavaですともう標準でにたようなもの [sun.com]ありますし。
ワタクシが思うに、世のcobolプログラムの
スタック変数がない (スコア:2, 参考になる)
障害発生時が発生した場合には可能な限り早くバグの原因を特定して修正を行う必要があります。しかし、再現性のない、あるいは 再現させるためにもう一度プログラムを動かすことが許されないような状況で バグを発見・修正しなくてはならないという局面に立たされた場合どうします？
スタック変数のない COBOL だとコア(メモリイメージ)さえ入手できればプログラムのどこにバグがあったのか なんとか追跡可能です。
スタックの存在を前提とした構
コンタミは発見の母
Re:スタック変数がない (スコア:0)
関係無いと思う。大域変数でも以前の値は現在値に書き換えられてるので同じですね。
それに現在実行中の関数でエラーが出てそのエラーが前に実行
された関数と関係が有るって事は何らかの状態を前に実行された
関数から引き継いでいるのだから十分追跡可能でしょう。GCがトリガーと成って表面
Re:スタック変数がない (スコア:1)
> 関係無いと思う。大域変数でも以前の値は現在値に書き換えられてるので同じですね。
いえオブジェクトの可視(visible)/不可視(invisible)を問題にしているのではなく、
オブジェクトの寿命(life time)が問題なのです。
＃ だからローカル変数と書かずにスタック変数と書いたのに、、、
COBOL → 構造化プログラム → Java になるに従って、オブジェクトの消滅が
implicit になっていくのが障害対策を考えると問題だという話です。
> それに現在実行中の関数でエラーが出てそのエラーが前に実行
コンタミは発見の母
Re:スタック変数がない (スコア:1)
>＃ だからローカル変数と書かずにスタック変数と書いたのに、、、
>COBOL → 構造化プログラム → Java になるに従って、オブジェクトの消滅が
>implicit になっていくのが障害対策を考えると問題だという話です。
それを問題だと呼ぶならば、もうひといき言って、
変数とobjectの対応(寿命とか)関係がimplicitになっているかどうか?も
ここでいう「問題」に、関わっていると思います。
javaみたいな参照だらけの言語だと、「変数を」ダンプしてみても、
その変数が意味する「値(objectとか…のアドレス??)」が
どう対
Re:スタック変数がない (スコア:1)
>> implicit になっていくのが障害対策を考えると問題だという話です。
> それを問題だと呼ぶならば、もうひといき言って、
> 変数とobjectの対応(寿命とか)関係がimplicitになっているかどうか?も
> ここでいう「問題」に、関わっていると思います。
> javaみたいな参照だらけの言語だと、「変数を」ダンプしてみても、
> その変数が意味する「値(objectとか…のアドレス??)」が
> どう対応するかってのが、わかりにくくなっていると思います。
コンタミは発見の母
Re:スタック変数がない (スコア:1)
クラス情報の有無はまた別の問題であるような気もしますが、それはともかく、
スタックとヒープの両方をいっしょにダンプしとけば、ポインタを追跡するだけで済む、
という話でしょうか? だとすればナルホドです。
>関数型言語でコミットやロールバックを記述するのってどうやるのだろう？
俺もさっぱり知りません。どうするんでしょうね?(^^;
普通のやつらの上を行け [dreamhost.com]では、もろにエンタープライズな(^^;webアプリ分野でLispを使っ
Re:スタック変数がない (スコア:1)
> 俺もさっぱり知りません。どうするんでしょうね?(^^;
APIレベルの話なら、たとえばFranz Inc. [franz.com]の AllegroStoreでは
(with-transaction () ... DB処理 ...)
と書いておくと、処理が正常に終了すればコミット、 例外が投げられた場合はロールバックされます。 実装レベルではunwind-protectでやっているのでしょう。>>スタックは Last-In Fast-Out のルールで使いまわすメモリ領域を指すので、
>>「使いまわさない」スタックというのは考え難いのですが
>ええ。それはもはやスタックと呼びにくいものだ、と俺も思います。
フレームはスタック領域に取っても、状況に応じてフレームをポップしない、という実装はありますね。例えば継続が捕捉されたらその時点でスタックにあるフレームはポップしないようにするとか。 スタックが溢れたらそこでGCを走らせて、生きているフレームをヒープに移すと。それを応用すれば、モニターしたい部分だけはフレームを残しておくなんてことも不可能ではないでしょう。 Cf. Scott L. Burson: "Continuations Without Copying", SIGPLAN Notices, 29(5), pp.27-30, 1994.
Re:スタック変数がない (スコア:1)
> 実装はありますね。例えば継続が捕捉されたらその時点でスタックにあるフレームは
> ポップしないようにするとか。 スタックが溢れたらそこでGCを走らせて、生きている
> フレームをヒープに移すと。それを応用すれば、モニターしたい部分だけはフレーム
> を残しておくなんてことも不可能ではないでしょう。
> Cf. Scott L. Burson: "Continuations Without Copying",
> SIGPLAN Notices, 29(5), pp.27-30, 1994.
あぅ。遅いフォローですいません。
上記の論文を探したのですが、SIGPLAN Notices は ACM の DIGITAL LIBRARY では
読めないし、近場にも 94年のものはすでに取ってなかったので読めませんでした。
"Without Copying" という名前から予想するに、実装的にはフレームをポップする
時にはスタックが飛び地になっていないかどうか確認し、フレームをプッシュする
ときに自分のフレームより下位のメモリアドレスが使用済みでないかのチェックを
入れながら使うのでしょうね。
結構、重い処理になりそうですねぇ。
コンタミは発見の母