clibと呼ばれるライブラリー開発の思い出（２） [clib]
（前回はこちら）
アーキテクチャ概要
Fuji Xerox DocuStation IM200 / AS200は、OSがSolaris 2.3であり、その上に、スキャナー、プリンタ、ファック装置、パネルなどのデバイスを抽象化してAPIを提供するプロセス群、それらのプロセス群と通信するvoyagerと呼ばれるプロセスがありました。一つのプロセスであるvoyager上でコピーやファックスなどのサービスが動作するようになっていました。
voyagerの中は、最下位層にMAE（Multifuction Application Environment）と呼ばれるレイヤがあり、MAEがサービスの起動から、割り込み処理、デバイスの排他制御などの基本機能を提供していました。各サービスは、ユーザからの指示があると、MAE上でスレッドとして都度起動されるように設計されていました。サービスを実装しているスレッドは、さらに子スレッドを生成することができ、それらをまとめてMAE上で管理していました。
コピーなどのサービスが完了すると、生成されたスレッド群はすべて終了します。MAEの実装は、ほぼすべてを私一人で設計・実装しました。このような動作環境でしたので、新たに実装したnew演算子とdelete演算子によるメモリ管理は、次のような機能を持っていました。
システムの定常状態で、割り当てられているすべてのメモリにマークを付けて、その後にコピーなどのサービスを実行します。そして、実行後にマークが付けられていないメモリの一覧を表示することができました。つまり、サービスの処理の中で割り当てられて、サービスが終了したときに解放されていないメモリの一覧が表示されます。しかし、その一覧は、メモリのアドレスと、それがどのスレッドで何番目に割り当てられたかしか分からない実装になっていました。それでも、全く情報が無いよりはよかったのですが、リークしているメモリがどこでnewされたメモリなのかを調べるのが面倒でした。この面倒さを解消する仕組みは、当時私は思い付かなかったようです（clibでの改善1）。
もう一つ、当時苦労したのはダングリングポインターです。つまり、すでに解放済みのメモリを指すポインターです。解放されたメモリを参照していることをデバッガで調べるのが容易ではありませんでした。なぜなら、解放はされているが、メモリの内容（オブジェクト内容）がそのままなので、動作したりすることがあるからです。この問題の解決を容易にする仕組みも、当時私は思い付かなかったようです（clibでの改善2）。
IM200はペーパーユーザインタフェースを持つ新たなデジタル複合機でしたが、そのペーパーユーザインタフェースのソフトウェアの代わりに、別のソフトウェアを搭載したのがAS200（自治体窓口証明発行システム）でした（基本的なデジタル複合機の機能は同じソフトウェアが動作）。AS200固有の機能はすべて富士ゼロックス情報システムが開発していたのですが、そこでもメモリリークに悩まされていて、私が作った新たなメモリ管理でリンクし直したら、容易にリークが分かるようになって安定させることができました。
こうして、Fuji Xerox DocuStation IM200と AS200は、1995年の暮れから1996年にかけて完成して製品化されました。新たなサービス（課金）モデルを目指して開発されたIM 200は、残念ながらあまり売れませんでした。その代わり、AS200は対象が市役所向けでしたが、売れて、リコーへOEMまでしていました。AS200は、当時（1996年）の製品としてはめずらしく大型のタッチパネルを持ち、競合機種と比較してもダントツの商品に仕上がっていました。市役所向けとは言え、市場を席巻されてしまっては、AS200の導入と同時に普通のデジタル複合機も置き換えられてしまうのと、同じ機能を後追いで開発することは無理だと、当時のリコーの誰かが判断したのではないかと思います※。
※ リコーに転職してから、このOEMの件を開発部門のさまざまな人に聞いても、誰も知らないとう返事でした。おそらく開発部門を巻き込まずにOEMで仕入れて販売したのだと思います。
IM200に関しては、後継機の開発を行わないことが1996年に決まり、私は、その年の8月に富士ゼロックスを退職して、日本オラクルへ転職しました。その後、ジャストシステムを経て、富士ゼロックスの子会社である富士ゼロックス情報システムへ入社したのが1998年5月でした。
そして、1999年には、新たなカラーのデジタル複合機開発の検討が富士ゼロックスで始まろうとしていました。その頃に提案されたソフトウェアアーキテクチャに私が異議を唱えたのが1999年の暮れでした。私からの異議がきっかけで、二つのソフトウェアアーキテクチャの検討が2000年の前半の半年間に、多くのマネージャやエンジニアを巻き込んで行われました。そして、最終的には、私が提案したソフトウェアアーキテクチャは却下されて、今の富士ゼロックスのデジタル複合機に搭載されているソフトウェアアーキテクチャが採用されました。
ここから、clibの開発が始まります。それは、2000年夏です。
（つづく）
アーキテクチャ概要
Fuji Xerox DocuStation IM200 / AS200は、OSがSolaris 2.3であり、その上に、スキャナー、プリンタ、ファック装置、パネルなどのデバイスを抽象化してAPIを提供するプロセス群、それらのプロセス群と通信するvoyagerと呼ばれるプロセスがありました。一つのプロセスであるvoyager上でコピーやファックスなどのサービスが動作するようになっていました。
voyagerの中は、最下位層にMAE（Multifuction Application Environment）と呼ばれるレイヤがあり、MAEがサービスの起動から、割り込み処理、デバイスの排他制御などの基本機能を提供していました。各サービスは、ユーザからの指示があると、MAE上でスレッドとして都度起動されるように設計されていました。サービスを実装しているスレッドは、さらに子スレッドを生成することができ、それらをまとめてMAE上で管理していました。
コピーなどのサービスが完了すると、生成されたスレッド群はすべて終了します。MAEの実装は、ほぼすべてを私一人で設計・実装しました。このような動作環境でしたので、新たに実装したnew演算子とdelete演算子によるメモリ管理は、次のような機能を持っていました。
- スレッド単位の管理：スレッド単位で、割り当てられたメモリを管理する
- メモリ破壊検出：new演算子で返した領域の前後のメモリ領域を破壊した場合には、delete演算子がその破壊を検出する。
- 割り当てられたメモリへのマーク付け：割り当てられて解法されていないメモリ領域にマークを付ける機能
- スレッドごとのメモリ割り当て順序管理：スレッドごとに、個々の割り当てられたメモリがそのスレッドでの何番目の割り当てなのかの管理
システムの定常状態で、割り当てられているすべてのメモリにマークを付けて、その後にコピーなどのサービスを実行します。そして、実行後にマークが付けられていないメモリの一覧を表示することができました。つまり、サービスの処理の中で割り当てられて、サービスが終了したときに解放されていないメモリの一覧が表示されます。しかし、その一覧は、メモリのアドレスと、それがどのスレッドで何番目に割り当てられたかしか分からない実装になっていました。それでも、全く情報が無いよりはよかったのですが、リークしているメモリがどこでnewされたメモリなのかを調べるのが面倒でした。この面倒さを解消する仕組みは、当時私は思い付かなかったようです（clibでの改善1）。
もう一つ、当時苦労したのはダングリングポインターです。つまり、すでに解放済みのメモリを指すポインターです。解放されたメモリを参照していることをデバッガで調べるのが容易ではありませんでした。なぜなら、解放はされているが、メモリの内容（オブジェクト内容）がそのままなので、動作したりすることがあるからです。この問題の解決を容易にする仕組みも、当時私は思い付かなかったようです（clibでの改善2）。
IM200はペーパーユーザインタフェースを持つ新たなデジタル複合機でしたが、そのペーパーユーザインタフェースのソフトウェアの代わりに、別のソフトウェアを搭載したのがAS200（自治体窓口証明発行システム）でした（基本的なデジタル複合機の機能は同じソフトウェアが動作）。AS200固有の機能はすべて富士ゼロックス情報システムが開発していたのですが、そこでもメモリリークに悩まされていて、私が作った新たなメモリ管理でリンクし直したら、容易にリークが分かるようになって安定させることができました。
こうして、Fuji Xerox DocuStation IM200と AS200は、1995年の暮れから1996年にかけて完成して製品化されました。新たなサービス（課金）モデルを目指して開発されたIM 200は、残念ながらあまり売れませんでした。その代わり、AS200は対象が市役所向けでしたが、売れて、リコーへOEMまでしていました。AS200は、当時（1996年）の製品としてはめずらしく大型のタッチパネルを持ち、競合機種と比較してもダントツの商品に仕上がっていました。市役所向けとは言え、市場を席巻されてしまっては、AS200の導入と同時に普通のデジタル複合機も置き換えられてしまうのと、同じ機能を後追いで開発することは無理だと、当時のリコーの誰かが判断したのではないかと思います※。
※ リコーに転職してから、このOEMの件を開発部門のさまざまな人に聞いても、誰も知らないとう返事でした。おそらく開発部門を巻き込まずにOEMで仕入れて販売したのだと思います。
IM200に関しては、後継機の開発を行わないことが1996年に決まり、私は、その年の8月に富士ゼロックスを退職して、日本オラクルへ転職しました。その後、ジャストシステムを経て、富士ゼロックスの子会社である富士ゼロックス情報システムへ入社したのが1998年5月でした。
そして、1999年には、新たなカラーのデジタル複合機開発の検討が富士ゼロックスで始まろうとしていました。その頃に提案されたソフトウェアアーキテクチャに私が異議を唱えたのが1999年の暮れでした。私からの異議がきっかけで、二つのソフトウェアアーキテクチャの検討が2000年の前半の半年間に、多くのマネージャやエンジニアを巻き込んで行われました。そして、最終的には、私が提案したソフトウェアアーキテクチャは却下されて、今の富士ゼロックスのデジタル複合機に搭載されているソフトウェアアーキテクチャが採用されました。
ここから、clibの開発が始まります。それは、2000年夏です。
（つづく）
著書（PDF）
翻訳本（Kindle版）
翻訳本（PDF）
