SSブログ

メモリ問題とソフトウェアエンジニア [プログラマー現役続行]

大規模なソフトウェアでかつ基本的に電源がオフされることなく常時動作させるシステムを構築する場合には、様々なメモリに関連するトラブルが発生します。私自身の経験としては、最初にそのようなシステム開発をしたのは、Fuji Xerox DocuStation IM 200です。これには、Fax機能が搭載されていましたので、基本的に24時間365日動作させ続けるシステムです。

C++言語を使用しSolaris 2.3上で動作していたのですが、開発が進んである程度基本的なサービスが動作し始めた時点で最も悩ましかったのは、解放されることなくメモリ使用量が増大するメモリリークです。それ以外にも、メモリ破壊、メモリの多重解放、解放済みメモリへの参照といった多くの問題を抱えていました。

それらの問題を解決するために、様々な調査や検査が可能なメモリ管理を私自身で設計・実装し、newとdeleteのオペレータを再実装したものを用意して使用し始めました。その後、多くの問題が解決されて製品化を行うことができました。先行して発売されたFuji Xerox DocuStation AS 200の開発でも、「自治体窓口証明発行システム」部分を子会社で開発したのですが、そこでも多くのメモリ問題を抱えており、私自身が実装したメモリ管理で置き換えて安定化させたという経緯があります。

その後、2000年にC++言語用に再設計(「C++とメモリ管理」参照)し、使用しているメモリ量の合計やピーク時の最大メモリ割り当て量などを計測する機構を追加しています。以前の設計からも多くを継承しており、未解放領域の一覧出力(どのソースコードのどこで割り当てられたのかの情報も含む)なども含まれていました。

一方で、当時から、「メモリリーク対策会議」と称して、何も仕組みが入っていないのに、とにかくメモリリークを減らせということしかできない会議を時々開催せざるを得ないプロジェクトの話や、プロセス空間が大きくなっているのでリークしているはずだから調査しなさいということで、闇雲にソースコードを調べたりしているプロジェクトの話を聞いたことがあります。

ガーベッジコレクションを持つ言語を使用したからと言って、メモリリーク問題や無駄なメモリ割り当ての問題は解決する訳ではありません。システムを開発しながら、そのような問題にどうやって対処していくか、どのような有効な手段があるかを常に探求していく必要があります。たとえば、NetBeansのテストフレームワーク(NbTestCase)にはメモリ問題に積極的に対処するため機構が用意されています。

ソフトウェアエンジニアとして、自分達が使用している言語およびシステムにおいて、メモリ問題に対して積極的に、かつ、継続的に取り組んでいくことが必要です。「ガーベッジコレクションの言語なのでガーベッジコレクションが懸念事項」だと述べるのは簡単です。しかし、そのような言語を使用した場合に、メモリ問題に対処するために、どのような対策があるのかを積極的に追求していく必要があります。懸念事項を解消するために、CやC++言語を使用したらメモリ問題が自動的に解決する訳ではないことは明らかです。
nice!(0)  コメント(0)  トラックバック(0) 

nice! 0

コメント 0

コメントを書く

お名前:[必須]
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

※ブログオーナーが承認したコメントのみ表示されます。

Facebook コメント

トラックバック 0