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年夏です。
（つづく）
株式会社リコーを退職します [転職]
2009年9月から働き始めた株式会社リコーを8月31日付けで退職します。丸8年働いたことになります。現在57歳であり、定年退職までにはまだ2年と少しありますが、「セカンドキャリア制度」（早期退職制度のようなもの）の適用を受けて退職します。
8年間の会社での業務や退職理由については述べませんが、業務以外の私的活動の成果をまとめてみると次のようになります。
最終出社日は、8月31日（木）です。そして、9月からは長年勤めた複写機業界（富士ゼロックスが12年、富士ゼロックス情報システムが11年、リコーが8年の合計31年！）を離れて、私にとって6社目となる会社で働き始めます。
8年間の会社での業務や退職理由については述べませんが、業務以外の私的活動の成果をまとめてみると次のようになります。
- 翻訳本（8冊）：『アプレンティスシップ・パターン』『プログラミング原論』『Android SDK 開発クックブック』『プログラミング言語Goフレーズブック』『Objective‐C明解プログラミング』『APIデザインの極意』『Java SE 8 実践プログラミング』『プログラミング言語Go』
- 自著（2冊+α）：『ソフトウェア開発の名著を読む 【第二版】』『プログラマー”まだまだ”現役続行』『API設計の基礎』
- Jolt Award読書会
- 横浜Go読書会
- 講演活動：実績と予定はこちら
最終出社日は、8月31日（木）です。そして、9月からは長年勤めた複写機業界（富士ゼロックスが12年、富士ゼロックス情報システムが11年、リコーが8年の合計31年！）を離れて、私にとって6社目となる会社で働き始めます。
第4回Java研修OB・OG懇親会 [研修OB・OG懇親会]
7月22日（土）に、第4回Java研修OB・OG会をHP本社8Fのカフェテリアで開催しました。今回は、Java研修修了生だけでなく、Go研修修了生および現在Java研修を受講している人達も対象とした拡大版でした。
第3回と同様に2部構成にしました。私も入れて技術セッションには45名が参加し、懇親会には42名が参加しました。
第1部 15:00〜17:10 技術セッション
第2部 17:10〜19:30 懇親会
技術セッションでは、まず、「Node.js 日本ユーザーグループ」の会長である古川陽介さんからNode.jsの話をしてもらいました。古川さんが使っているTwitterのプロフィールのアイコンが、Java研修の最終課題用に作成されたものであることを知りました。
2件目は、修了生が3名働いているクラウド会計ソフトを提供しているfreeeを西出さんに紹介してもらいました。
3件目は、GROOVE Xに勤めている荒木さん（Tour of Goの日本語サイトの運営者）からロボット関連の話をしてもらいました。
4件目は、ホンダのR&Dセンタ−Xに勤めている東さんから、ホンダおよびR&DセンターXの紹介をしてもらいました。
ここで、技術セッションの予定時間が過ぎたので、会場のカフェテリアでお酒を飲みながらの懇親会です。
このカフェテリアは、TVドラマ「半沢直樹」の第6話で撮影に使われた場所でした。
懇親会の途中で、私が「Java・Go研修を振り返って」と題した話をしました。
この後、LTを2件と、場所を提供してくれたHPおよびDCX Technology社の紹介を加藤さんから行ってもらいました。
Java研修を始めた2000年の頃は、私は40歳であり、受講生との年齢差も15歳程度でした。17年が経過し、最近では、受講生の父親と同じか年上という状況になっています。
この17年間で、正確な数字はないのですが、Java研修およびGo研修で、200名以上の修了生を送り出し、さまざまな企業で活躍しています。そして、私事ですが、8月31日付けで株式会社リコーを退職し、9月から新たな会社で働き始める予定です。
第3回と同様に2部構成にしました。私も入れて技術セッションには45名が参加し、懇親会には42名が参加しました。
第1部 15:00〜17:10 技術セッション
第2部 17:10〜19:30 懇親会
技術セッションでは、まず、「Node.js 日本ユーザーグループ」の会長である古川陽介さんからNode.jsの話をしてもらいました。古川さんが使っているTwitterのプロフィールのアイコンが、Java研修の最終課題用に作成されたものであることを知りました。
2件目は、修了生が3名働いているクラウド会計ソフトを提供しているfreeeを西出さんに紹介してもらいました。
3件目は、GROOVE Xに勤めている荒木さん（Tour of Goの日本語サイトの運営者）からロボット関連の話をしてもらいました。
4件目は、ホンダのR&Dセンタ−Xに勤めている東さんから、ホンダおよびR&DセンターXの紹介をしてもらいました。
ここで、技術セッションの予定時間が過ぎたので、会場のカフェテリアでお酒を飲みながらの懇親会です。
このカフェテリアは、TVドラマ「半沢直樹」の第6話で撮影に使われた場所でした。
懇親会の途中で、私が「Java・Go研修を振り返って」と題した話をしました。
Java研修を始めた2000年の頃は、私は40歳であり、受講生との年齢差も15歳程度でした。17年が経過し、最近では、受講生の父親と同じか年上という状況になっています。
この17年間で、正確な数字はないのですが、Java研修およびGo研修で、200名以上の修了生を送り出し、さまざまな企業で活躍しています。そして、私事ですが、8月31日付けで株式会社リコーを退職し、9月から新たな会社で働き始める予定です。
clibと呼ばれるライブラリー開発の思い出（１） [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演算子を独自に実装し、メモリ破壊やメモリリークを検出する機構を入れ、問題を解決することにしました。
（つづく）
著書（PDF）
翻訳本（Kindle版）
翻訳本（PDF）
