clibと呼ばれるライブラリー開発の思い出(1) [clib]
2000年にclibと呼ばれるC++用のライブラリーを開発しました。それは、今でも富士ゼロックスのデジタル複合機で1000万行を超えるコントローラソフトウェア(*)と呼ばれる制御ソフトウェアで使われているライブラリです。メモリ管理機構とマルチスレッドプログラミング機構を統合したようなC++のライブラリです。
(*)http://www.atmarkit.co.jp/ait/articles/1507/06/news009.html
clibは、私がそのAPI仕様をすべて設計し、実装は他の優秀なエンジニア2名に行ってもらいました。API仕様には、防御的プログラミングも含めて、メモリ管理機構での細かな動作仕様も書いていました。
このライブラリに関して、忘れないうちに一連のブログ記事として書きたいと思います。しかし、記憶は嘘をつきます。したがって、事実とは異なった私の記憶の嘘が含まれているかもしれません。
そのプロジェクトは、PARCではPageMillプロジェクトと呼ばれていました。富士ゼロックス社からの駐在員は私一人でした。2年間、米国でそのプロジェクトに従事したあと、製品化のために1993年5月に日本に帰国しました。4年半の米国駐在を終えて富士ゼロックスへ戻り、PageMillプロジェクトの技術の製品化を行うDS企画開発室に配属になりました。
当時、富士ゼロックスはワークステーション事業から撤退を決めており、その開発室にはそれまでワークステーションを開発していた優秀なソフトウェアエンジニアが集められていました。それでもほとんどが私と同じ歳か一つ下ぐらいでしたので、30代前半のソフトウェアエンジニアが集められていました。
この製品化プロジェクトで特徴的だったのは、以下の通りです。
C++での開発
C++で開発することが決まっていたのですが、当時、C++を学べば学ぶほど困ったなと思っていました。それは、APIを設計するときに、ヘッダーファイルに実装の詳細を記述しない方法がないように思えたからです。実際には、ある書き方を考え出しました。その書き方の詳細については、「API設計の基礎」に書いていますので、参考にしてください。
ビッグバンインテグレーション
継続的インテグレーションという言葉がない時代でしたので、ビッグバンインテグレーションを行っていました。しかし、2週間ごとのインテグレーションは必ず失敗するという状況でした。この問題に対処するために導入したのは、夜間ビルドです。つまり、毎晩自動ですべてをビルドするということです。毎晩ビルドが成功するようになるまでは、数週間を要しました。
当時、ビルドはかなり時間を要していました。そして、夜間ビルドが毎晩成功するわけではありませんでした。毎朝7時過ぎに出社後は、夜間ビルドが失敗していたら、原因を修正して、ビルドをやり直すということを行っていました。また、複数のワークステーションを駆使して行う分散ビルドも自分で開発したツールで行っていました。
メモリ破壊とメモリリーク
開発がある程度進んで、最も大きな問題となったのは、「メモリ破壊」と「メモリリーク」です。コピーができるようになっても、1ページのコピー動作ごとにメモリが2MBもリークしていたのです。
当時、purifyが登場していましたが、ほとんど使えませんでした。マルチスレッドでは正しく動作しなかったの、purifyを使用すると動作が恐ろしく遅くなるため、普段の開発では使えませんでした。
この時、問題を解決するには、メモリ管理を自分で行う必要があると私は判断しました。そして、C++のnew演算子とdelete演算子を独自に実装し、メモリ破壊やメモリリークを検出する機構を入れ、問題を解決することにしました。
(つづく)
(*)http://www.atmarkit.co.jp/ait/articles/1507/06/news009.html
clibは、私がそのAPI仕様をすべて設計し、実装は他の優秀なエンジニア2名に行ってもらいました。API仕様には、防御的プログラミングも含めて、メモリ管理機構での細かな動作仕様も書いていました。
このライブラリに関して、忘れないうちに一連のブログ記事として書きたいと思います。しかし、記憶は嘘をつきます。したがって、事実とは異なった私の記憶の嘘が含まれているかもしれません。
Fuji Xerox DocuStation IM 200/AS 200の開発
時代は、1991年1月17日まで遡ります。その日、私はXerox社のPARC(Palo Alto Research Center)にいました。米国に駐在していましたが米国内で転勤することになり、新たに従事するPARCのプロジェクトの話を聞くためにLAから出張していました。その日は、湾岸戦争が勃発し、PARCの廊下で戦争が始まったと伝えられたことを鮮明に覚えています。そのプロジェクトは、PARCではPageMillプロジェクトと呼ばれていました。富士ゼロックス社からの駐在員は私一人でした。2年間、米国でそのプロジェクトに従事したあと、製品化のために1993年5月に日本に帰国しました。4年半の米国駐在を終えて富士ゼロックスへ戻り、PageMillプロジェクトの技術の製品化を行うDS企画開発室に配属になりました。
当時、富士ゼロックスはワークステーション事業から撤退を決めており、その開発室にはそれまでワークステーションを開発していた優秀なソフトウェアエンジニアが集められていました。それでもほとんどが私と同じ歳か一つ下ぐらいでしたので、30代前半のソフトウェアエンジニアが集められていました。
この製品化プロジェクトで特徴的だったのは、以下の通りです。
- 集められたソフトウェアエンジニアは、私も含めて誰一人としてデジタル複合機の開発に従事したことがありませんでした。
- CPUにはSPARC、オペレーティングシステムはSolaris 2.3という構成でした。
- 私を含めて全員が、初めてのマルチスレッドプログラミングでした。
- 誰もほとんど使ったことがないC++で開発することが決まっていました。
C++での開発
C++で開発することが決まっていたのですが、当時、C++を学べば学ぶほど困ったなと思っていました。それは、APIを設計するときに、ヘッダーファイルに実装の詳細を記述しない方法がないように思えたからです。実際には、ある書き方を考え出しました。その書き方の詳細については、「API設計の基礎」に書いていますので、参考にしてください。
ビッグバンインテグレーション
継続的インテグレーションという言葉がない時代でしたので、ビッグバンインテグレーションを行っていました。しかし、2週間ごとのインテグレーションは必ず失敗するという状況でした。この問題に対処するために導入したのは、夜間ビルドです。つまり、毎晩自動ですべてをビルドするということです。毎晩ビルドが成功するようになるまでは、数週間を要しました。
当時、ビルドはかなり時間を要していました。そして、夜間ビルドが毎晩成功するわけではありませんでした。毎朝7時過ぎに出社後は、夜間ビルドが失敗していたら、原因を修正して、ビルドをやり直すということを行っていました。また、複数のワークステーションを駆使して行う分散ビルドも自分で開発したツールで行っていました。
メモリ破壊とメモリリーク
開発がある程度進んで、最も大きな問題となったのは、「メモリ破壊」と「メモリリーク」です。コピーができるようになっても、1ページのコピー動作ごとにメモリが2MBもリークしていたのです。
当時、purifyが登場していましたが、ほとんど使えませんでした。マルチスレッドでは正しく動作しなかったの、purifyを使用すると動作が恐ろしく遅くなるため、普段の開発では使えませんでした。
この時、問題を解決するには、メモリ管理を自分で行う必要があると私は判断しました。そして、C++のnew演算子とdelete演算子を独自に実装し、メモリ破壊やメモリリークを検出する機構を入れ、問題を解決することにしました。
(つづく)