意図せざる加速

4F

　さて、NUSAは。一体どのようにして、間接再帰（indirect recursion）を解析したのだろうか？

　何しろ『自動分析ツールで取り扱うことができ』ず、かといって『人間のプログラマにとっても、複雑すぎて完全に把握できない』と。間接再帰（indirect recursion）のことをそう述べているのだから。

　今のシェヴラみたいに。蜘蛛の巣のごとく張り巡らされた道路網で、それぞれ目的地へと向かう車たちが無数に湧いているとき。いったい、どこが原因で渋滞が起きるのか……を解析するのとは、似て非なる話だろう。路上の自動車なら、走行中に（じぶんと同じ）自動車を産み落としたり、逆に回収したりはしないから。

　そうした違いはともかく。現代では、殆どの車にナビゲーション・システムが装着されているので。現在の位置を逐次データ通信で教えてもらえば、静止衛星で睥睨するかのごとく、地上を走り回る車たちをスクリーン上で目視できるようになるから。地図と重ねて、ずうっと眺めているだけでも。わかることは、ありそうである。

　そして、様々な「仕事（タスク）」をコンピュータがこなす際、一度に一つの処理しか行わないのが通常なので。ある「車」が動いているうちは、他の「車」は止まっているようなものだから。問題のありそうな「仕事」に目をつけて、それがどのような「手順」で実行されていくかを、追っかけていけば良いのでは？……人の目で追うのが辛いなら、コンピュータに追っかけてもらえば？……という発想は、いかにも普通にありそうだ。

　実際、NUSAは。ある「手順」が別の「手順」を呼び出し、その「手順」がまた別の「手順」を呼び出すといった有様を、既存の解析ソフトを使って「経路図」に描（えが）いたのだ。

　要するに、それぞれの「手順」を楕円形で表し、そこから別の「手順」の呼び出しを。楕円と楕円を結ぶ矢印線で表したのである。その「仕事」の状況によって、呼び出される「手順」も違ってくるとすれば、スタート地点の楕円から、色々な楕円を経由して、下流へと枝分かれしていく図になりそうである。

　ところが、NUSAが「補遺Ａ」に載せた解析結果は。やや「末広がり」ではあるものの、所々ギュッと絞られた形状であり。さながら「ハング・グライダーの乗り手がパラシュートで飛び降りた直後」のような、奇妙な絵面であった。

　種明かしをすると、NUSAは。

　いったん枝分かれして生じたもののうち……上流へと「戻す」矢印が生えた楕円と、そこへ矢印を伸ばす別の楕円……を含む、経路の中にあるものを残して。それら以外を、楕円も矢印も全部取り除いてしまったので。下流端の楕円が、上流に「戻る」矢印を持つものだけとなり。またその上流も。そのような楕円へと矢印を伸ばす経路の楕円のみが残っているために、そんな奇妙な有様になったのだ。

　その状態で、図に残った「手順」は２４種もあって。その全てが循環するループの一部であるとするなら、この先いったいどうすれば？……と、途方に暮れる感じが漂うのである。

　実際、NUSAも。いちどは、音を上げたようなことを書いているのだ。

NUSA:『この図から直ちに読み取れるのは、このグラフ上で取り得る経路の数が、ループに参加しないノードを全て潰した場合でも、あまりに多いことである。循環があるために取りうる経路の数は無限である。視覚化による補助が解析を幾分シンプルにしてくれるとはいえ、完全な人力解析は不可能であろう。』

　じゃあ、ギブアップなのか？

　……いや、まだ続いている。

　この図の解析対象となったコードは、ある「手順」を開始ポイントとしている。多数の矢印は、たった一つの楕円から始まっているのだ。しかし、そこから。状況によって呼び出す楕円……つまり「手順」が違うとすれば。特定の呼び出しが連鎖した状態は、「特定の処理」をしている状態であって、それとは別の連鎖をした状態は、また「別の処理」をしている状態である……ということになる。そうした、「特定の処理」をしている状態が終了すれば、呼び出し元の楕円に復帰していって、さらにその呼び出し元の楕円まで復帰するか、あるいは踏みとどまって別の楕円を呼び出すかするだろう。

　この妙ちくりんな図形を、わかりやすく「雷雲」に例えれば。ある楕円の連鎖が、繋がったままビカッと発光して。一旦暗くなったあと、また別の連鎖がビカッと発光する……というような。真っ暗な中を、次々と走り抜ける稲妻のイメージだ。まあ本当の稲妻なら、続けて同じような経路で光るようなことはないのだろうが…。

　しかし、そういえば。この図では上流の楕円を呼び出す「戻って」いく矢印もあるのだから。循環ループとなる場合も、ある筈で。連鎖が輝くといっても、その先端がいつまでも次の楕円に連鎖していくのであると、なかなか光り切る（＝実際にやらせたい処理が完了する）まで行かないことになる。コンピュータが実行する「仕事（タスク）」は他にもあるから、いつまでも光らせとくわけにはいかないし、延々と楕円を呼び出していれば、バケツが溢れ出していくことになるから。そうしたことが起きないか確認するためには、どういう場合に上流の楕円を呼び出し「戻って」いくのかを、地道に調べる必要があるだろう。

　おそらく。この図を生成する際に、まずNUSAが用いたのは。「この場合にはこっちを呼び出す」という際の前段：つまり条件の部分が。本当に満たされることがあるかは考慮せずに、新たな「手順」の呼び出しが指定されていれば、ただちに「矢印を生やした先に楕円をぶらさげる」ような手法なのだろう。

　そのうえで。どういったデータを与えた場合に、どの楕円に「戻って」いくかを、実際に動かしてみて調べたのだろう。その際、「戻り」に参加しようがない楕円を呼び出してしまったとき、つまりこの図の「外」に出てしまった場合は。それ以上追わないでよい、とみなして。少しずつデータを変えながら与えてみる……補遺Ａでは説明されていないものの、おそらくある程度は「自動化」した手法をとったのだろう。とはいえ、取り込むデータは一種類ではないだろうし、直前に稲妻を光らせた連鎖にて、どの呼び出し元まで復帰していたか？……も影響するから、全ての組み合わせを試すことはできなかった筈だ。

　そうした事情が、「一般的には無理なのだが、今回は正確なホニャララが決定できた」というような……何とも言い難い、次のような説明となって現れたのではないだろうか。

NUSA:『一般的に人力の（静的）解析では実行時に状態がどうなるかは決定できないが、ここで再帰が生じるような場合、この状態機械（ステートマシン）テーブルは、どういうわけかプログラムの流れが決定的になるように組み上がる。この知見に基づいて、正確なプログラム・フローが決定できた。それは……』

　雷雲のなかの、ほんの片隅……一部分の連鎖だけが。間接的再帰（recursion）を生じさせると。そう、NUSAは言っているのだ。

　その連鎖は図の中で。二つの輪を一点で繋げた形状をしていた。即ち、間接再帰は二か所で生じることにはなるが、もう他のケースは考えなくていい……これだけを考えればいいのだ。

　NUSAは凄い！ よくぞここまで追い込んだ。そう感動しながら読み進めると、驚くことになるだろう。

NUSA:『ノヴァルの技術者も、このソフトウェア再帰を確認した。より大きなＵＡ問題に関して、再帰がどんなインパクトを有しているのか定かではない。再帰ループが１つか２つかを言う以前に、ＥＣTＳのなかにある再帰の他のサイトは解析されないまま残っている。』

　……は？

　それだけ……？

　そう、これで。

　これで終わりなのである。

　そのあとは、コードの解析とは違う次元の話――もし再帰が無限ループとなるのなら、「番犬」（WatchDog）が噛みついて再起動したはずだ――という議論しかない。NUSAお得意の「番犬」（WatchDog）であるが、バイエル証人はどう言っていたか？ こうである……

A:『ノヴァルのウォッチドッグ・スーパーバイザーは、メジャーなタスクの生死について常時検知することを許さない設計なのです。それが全てです。監視しないのです。監視するように設計されていないのです。』

　まだある。

A:『さらにノヴァルは、オペレーティングシステムから「おおい、このタスク、きちんと動いてないぜ！」と知らせてくれるのに、その情報を投げ捨てるためのコード行を入れてまで、タスクの死を検知しないようにしていました。タスクに問題が発生したと知らせるオペレーティングシステムからのエラー・コードを、彼らは無視していたのです。』

　この件も、ノヴァル側の反対尋問では出てきていない。

　NUSAの解析に戻ると。補遺Ａには電制スロットルシステムにおける「番犬」（WatchDog）実装の実際について記述がない。NUSAは調べていないのだ。とはいえバイエル氏も、ウォッチドッグが「全くない」とまでは主張していない。せめて、再帰のある「仕事」については「番犬」（WatchDog）が見張ってくれていると信じたいのだが。しかし……

NUSA:『ＥＣTＳでは、締め切り違反が生じないよう必ず保護をする設計はされていない。しかし、こうした問題が生じて、イベント・キューが満杯になれば、オペレーティングシステムがこの問題を検知して、ウォッチドッグ・タイマーを殺し、それで更にシステム・リセットを起こすことになる。同様に、よくない再帰によって無限ループが生じれば、これもウォッチドッグがリセットを起こす原因となるし、おそらくはスタック・オーバーフローもそうであろう（未確認）。』

　NUSAですら、この再帰ループ専門の「番犬」がいない前提で、再帰含みの「仕事」が終わらず、ＣＰＵの前で一列に並んでる他の「仕事」から「はやくしろー」と苦情が出るようになって、上位の監視番犬が腰（？）を上げることを期待しているのだ。

　そして、この点についても。バイエル証人は、次のように証言していた。

A:『ノヴァルの設計においては、ＣＰＵ過負荷の監視でも同じようなことになります……きちんと動かないのです。ＣＰＵ過負荷とは、やる仕事が爆発的に多くなり、全てのタスクをこなす所要時間が長くなりすぎている状況です。ＣＰＵをなかなか使わせてもらえないと、タスクは一時的に死んでいるようなものですが、ノヴァルのウォッチドッグのもとでは１．５秒まで過負荷が許容されます。時速６０マイルでは……だいたいフットボール場を通過する位の時間で、そこでどんな異常動作が起きても不思議ではありません。』

　言い方は違うが、バイエル証人も。最終的には、なんとかＣＰＵ過負荷が解消されることを。否定はしていない。

　しかし。そもそも、スタック・オーバーフローとは。必要な「時間」が長くなりすぎることではなく、再帰にて次々呼び出されたバケツが溢れ出して、オペレーション・システムが使用中のバケツを上書きするという、必要な「資源」が多くなりすぎる方が問題であった筈。

　つまり、ＣＰＵ過負荷に至らなくても。バケツが溢れて、スタック・オーバーフローが起きることはありえるのだ。だから、NUSAの説明は肝心な点を有耶無耶にしてると思う。

　そもそも、再帰の解析を断念しておきながら：「再起動がなかったという話なので、再帰も有限なのでしょう」と結論されるのは……正直な話、強い抵抗がある。しかも、他の事項の解析も。これと似たり寄ったりの出来なのである。

「補遺Ａ：ソフトウェア」が、こんな有様なのに。

NUSA:『静的解析・論理モデル試験・再帰テスト・そして最悪ケース実行タイミング分析を用いて、ソフトウエアの徹底的な試験と解析が行われた。これらのツールを用いた研究中、単独でUAの原因となるソフトウエア欠陥は発見されなかった。』

　こう、本体の報告に書いちゃうの。「間違いではない」としても、いかがなものだろうか？

　………………………………………………………………………

　……などと。

　嫌ぁなモヤモヤに捉われていた僕は、すっかり気付くのが遅れてしまった。

　いつの間にか、追いついてきていた……あの怪しい、チャコール・グレーのセダンに。