タスクセーブなどに関する議論
(0)
- Essen2019-Aに搭載されている変数監視機能は、結局は第一世代OSASKの目指していた「タスクセーブ」の副産物みたいなものです。
- そう私はタスクセーブをずっとやりたかったのです!!
(1)
- 以前は、タスクセーブ相当なことをするには、OSから手掛けなければいけないと思っていました。それはASLRなどによって、起動ごとにスタックの位置やヒープの位置が変わってしまうからです。それでは全メモリイメージを保存していても、再開がうまく行きません。
- しかしそれは2016年にpersistent-Cをやった時に、ポインタを使わないデータ構造を採用するという方向でなんとかできると思い、OSからやらなくても実現できる可能性が出てきました。OSからやらなくてもいいのであれば、私は面倒なデバイス開発をする必要が無くなるので、一気に実現可能性が出てきます。
- 次の問題として、どのタイミングで保存をさせるのかという問題がありました。いつでも保存してしまっていいのでしょうか。たとえば何かのロックを取ったまま保存するのはいいことでしょうか、私はそれは良くないと思います。できるだけ切りの良いタイミングで保存するべきです。
- ではどうすれば切りのいいタイミングで保存できるでしょうか。真っ先に思い付いたのは、保存してほしくない期間中は「保存抑制フラグ」を立てておき、もしその期間中に保存要求が来たら「保存待機フラグ」を立て、保存抑制フラグを下げるときには保存待機フラグを確認させるというものでした。・・・しかしこれは、プログラム内でしょっちゅうフラグ操作をするということであり、煩雑になってしまいそうです。頻繁にやりすぎると速度低下の恐れもあります。
- ということで、いっそのこと、プログラム内に数か所設定した「チェックポイント」でのみ保存待機フラグをポーリングするようにして、その他の間はずっと保存抑制フラグがONであるかのようにふるまうことにしました。これによって失われるのは、ユーザが保存したいと思ってから実際に保存が始まるまでの時間差が生じやすくなるということですが、そもそもそんな厳密のこのタイミングで保存しなければいけないということはないので、問題になっていません。それよりも保存の段階でメモリの状態が確実にきれいになっていること&アプリ開発に際して面倒な割り込み処理を意識しないでもいいこと、の2点の方がはるかに大きなメリットになっています。
- とはいえ、チェックポイントから次にチェックポイントまでに何ミリ秒かかったかについては、保存待機がなくとも常に監視して、アプリケーションの品質を表す値の一つとしていつでも容易に確認できるようにしています。
(2)