仕事の途中で気分転換がしたくなることがある。特に研究業務に取り組んでいるようなときは集中度を高める必要があるから連続して考え続けることが求められる(素歩人徒然「集中力」参照)。それにしても、ある程度の時間が経過したらやはり一息入れてリフレッシュするのが有効であろう。
私の経験では、気分転換にはある程度頭を使う時間を入れるとリフレッシュの効果が倍増するような気がしている(もし許されるなら、ゲームなどをするとよい)。休憩と称してダラダラと時間をつぶしているだけではリフレッシュ効果はあまり期待できない。最近の私は(もはや仕事はしていないが)気分転換が必要なときはいつも数独の問題に取り組むことにしている。それも少し難しい問題の方がよい。
つい最近、私はラジオで脳科学者が「ワーキングメモリー(作業記憶)」のことを話しているのを聞いた。記憶には短期記憶と長期記憶とがあるが、ワーキングメモリーはそのどちらでもない。ワーキングメモリーは、何かある目的を持ってやっている作業で使われる記憶で、日常生活での会話、お金の計算、あるいは創造性のある思考をするときにも使われる。ワーキングメモリーの機能が低下すると「頭のキレが悪くなった」と感じるようになるらしい。
気分転換でワーキングメモリーが使われると、その内容が入れ替わるからリフレッシュされることになるのであろう。これは、プログラミングの世界で言うところのワーキングストレージ(作業用領域)と似ているのではないかと思う。私は自分が経験的にやっていたことと合致するので我が意を得たりと思ったのである。しかしどこが似ているのか、これだけでは読者に理解してもらうのは無理で、もう少し説明が必要であろう。
さて、これからが本論である。
Windows 10を使っていて、いつも気になるのは“シャットダウン”の機能のことである。確か、Windows 8 にバージョンアップしたときからだったと思うが、コンピュータの電源を入れても“再起動”がされないことに気が付いた。つまり、前日にコンピュータをシャットダウンで終了させたのに、翌日電源を入れると完全な再起動の手続きが実行されていないのだ。パソコンの起動を速くするため、手抜きのシャットダウンをしていたのである。
コンピュータ用語辞典で「シャットダウン」の定義を調べてみたが、次の利用時に再起動が実施されるとは読み取れない。これではＭＳ社にクレームを付ける訳にはいかないなと思った。何しろ昔から使われている用語(*1)だから、今の技術で考えると定義があいまいになってしまうのは避けられない。ＭＳ社は、起動時間を短縮するためなら手段を選ばずという方針なのであろう、用語定義の「あいまいさ」さえも利用してしまっているようだ。当時この件で異議をとなえた人はいなかったようだし、気の弱い私めは静観している内にその仕様にやむなく従うことになってしまった(つまり、毎朝自分で「再起動」ボタンを押すことになってしまったのである)。
【注】(*1)昔アメリカの研究所で ＭＩＴにあるMultics システムの環境下で仕事をしていたとき、コンピュータシステムの電源を落とすことをシャットダウン(shutdown)と呼んでいるのを知った。単にコンピュータ本体の電源を落とすだけでなく、周辺機器も含めてすべてを一斉に終了させる大掛りな作業であるという印象を与えるので「格好いい呼び方だなぁ」と感心したのを覚えている。今風に言うなら「いいね」 をしたくなるほどだった。しかし再起動しないで毎日コンピュータを使い続けていると、一週間もしない内に何かしら不可解なトラブルが発生するようになる。そういうときは原因を追究するよりも、自然に直るのを期待して再起動してみるのがよい。ＭＳ社に報告しても反応がある訳ではないから、最初から無駄なことはしない方が賢明なのだ。それで結構通用してしまう。ＭＳ社と付きあうようになってから学んだ生活の知恵である。
しかし、そうは言いながらも私はこのトラブルの原因が何であるか知りたくて機会あるごとに考えてきた。そして長年のプログラマとして体験から、多分こういうことではないかと思うようになった。それは、Windows のシステムは「頭のキレが悪くなり」気分転換“リフレッシュ”が必要な状態になっていたのではないか、ということである（これでやっと話の筋が見えてきたでしょうか？）。
コンピュータ上で動くプログラムは、データを置く場所として静的な記憶域と動的な記憶域とを使い分けている。実行が始まってから必要になるものは、できるだけ動的記憶域に割り付ける方が限られたメモリーを有効に使えるのである。
利用者のプログラムで動的な記憶域が必要になると、システムのメモリー管理プログラムに要求を出す。システムはあらかじめ確保された領域（ヒープ領域と呼んでいる）から空きを見つけて利用者のプログラムに貸し出す方式をとる。そして、使い終われば返却させる。一方、利用者は借りた記憶領域を責任を持って管理することが要求される。その記憶領域の管理(*2)で不手際が起りやすいのである。
【注】(*2)記憶領域の管理この種のエラーを見つけるのは難しいけれど、普通は事前に取り除かれていると思ってよい。問題があるのは、このヒープ領域上に確保された記憶域上のデータの扱い方のほうである。
ヒープ領域に割り付けられたメモリは、割り付けた側が責任をもって管理し不要になった場合には速やかに解放してシステム管理下に戻すことが前提となっている。しかし、プログラミング上ではこの解放を忘れたことが原因で不都合が起こることが極めて多い。この種のメモリ管理のミスにもとづくエラーとしては、次の３種類がある。
・割り当てた領域を解放し忘れる（メモリリークという）
・既に解放された領域を参照する
・同じ領域を２度以上重複して解放しようとする
普通は、確保されたばかりの記憶域上に何か値（通常はゼロ）が置かれていても、それはゴミであるとみなし新たに値が設定されるまでは不定であるとする。そして領域が不要になったら(データの後始末をせず！)そのままメモリー管理プログラムに返却する（この過程で、ヒープ領域内のその記憶域はゼロでない不定の値を持つようになる）。
こういうやり方でメモリー管理をしていると、ヒープ領域は最初はゼロで埋められていても、時間の経過とともに徐々にゼロでないゴミ（不定の値）で埋められていくことになる。新たに貸し出される領域には、直前の利用者が残したデータの残骸が置かれている可能性が高まってくる。しかし、たとえゴミが残されていても管理規則を守って使っている限り何の問題も起らないはずなのである。ところが割り付けられた直後の“不定の値”をデータとして使ってしまう不心得なプログラムが存在するのである。こういう不心得なプログラムを見つけるのは極めて難しい。
私は、ある大きなシステムの開発を担当していたとき、デバッグ中に限りメモリー管理プログラムに手を入れて、記憶域を割り付けた直後は必ずゼロを埋めておくという手を打ったことがある。こうすると確実にプログラムデバッグができることを体験的に知っていたからである。しかし常にゼロクリヤーしていたのでは実行効率は悪くなる。デバッグの最終段階でこのゼロクリヤーを外すことにした。しかしその途端にプログラムの動作が不安定になったのを覚えている。明らかに不定の値が影響を及ぼしていたのである。
つまりトラブルの原因は、ヒープ領域のゴミを誤ってデータとして使ってしまうことに起因しているのではないか、というのが私の推測である。
これを避けるにはヒープ領域をゼロクリヤーするしかない。つまり再起動すればよいのである。再起動という気分転換(リフレッシュ)をすれば、すべて解決してしまうのだ。こういう事態を予想して私は毎朝必ず「再起動」を指定してからコンピュータを立ち上げるようにしている(*3)。
【注】(*3)Windows 10では、高速スタートアップのための「シャットダウン」が標準になっているが、再起動を含む「完全シャットダウン」に設定を変えることもできる(私は標準仕様で通す主義なので使ったことはないが)。皆さんも、時々は窓(ウインドウ)を開いて空気を入れ替え、リフレッシュしたらどうでしょうか。■
