多面的にコードの問題を可視化するCoverity Readiness Manager

作者 Scott Delap , 翻訳者 金森 諭 投稿日 2008年9月20日

セクション

設計/アーキテクチャ,

デベロップメント

トピック

Java ,

言語 ,

プログラミング ,

パフォーマンス&スケーラビリティ ,

Code Coverage ,

Coverity ,

テスト

共有 |

さらにSoftware Readiness Manageではこれ以外のコード分析ができるようになっている。InfoQは最近Coverityの主任研究員Andy Chou氏とCoverity製品であるCoverity PreventとThread Analyzerについて話をした。

C++バージョンのCoverity Preventに加えてJavaバージョンのCoverity Preventができましたね。このことはThread Analyzerにも関係があるのでしょうか？

私たちは世の中の流れがマルチコアプロセッサに向かっていると見ています。そしてその新たなハードウェア上ではマルチスレッドプログラムが今までとは違った振る舞いをしだすことを私たちは経験から知っています。特に競合状態やデッドロックといった今は表面に出ていない問題が突如として大きな問題になることが起きえます。これらは再現するのが難しく、デバッグが最も難しい問題の一つです。私たちの製品Coverity Preventは静的な解析を行うことで並行性での不具合を発見しますが、テスト中に動的な解析をおこなって並行処理上の不具合を見つけることもまた静的分析の結果の補完になることも分かっていました。これがThread Analyzerを開発するきっかけで、今のところ私たちの顧客は大変肯定的な反応を示してくれています。 

Yourkitなどのプロファイリングツールと比べてThread AnalyzerのROI（投資収益率）はどれくらいあると考えていますか？

Thread Analyzerはマルチスレッドコードをプログラミングする上で最も致命的となるいくつかのタイプの問題に焦点をあてています。並行処理の不具合を再現したり見つけたりするには数日あるいは数週間かかることがあります。たとえ問題の原因を数行のコードまで絞り込んだとしても、競合状態やデッドロックが起きる原因となるのがどのようなイベント連鎖なのかを解明するのは難しいことです。

Thread Analyzerはそういった問題を明らかにかつ再現可能にします。そのことでデバッグ中、あるいはこれも通常より上々ですが、アプリケーションテスト中に問題を見つけられれば大幅な節約ができることになります。プロファイリングツールはアプリケーションのどこでメモリや時間がかかっているかを分析するようなことはできます。いってみればそれらは相補的なツールであって、それぞれのツールの価値は開発中のアプリケーションや目前の状況によって変わるものです。

ブログスフィアから生まれた最近のミーム（情報の伝搬を遺伝子になぞらえて表した言葉）はオープンソースが商用開発ツールを殺そうとしている(リンク)と言います。Coverityのビジネスではオープンソースはどのような影響を与えているでしょうか。

オープンソースは私たちのビジネスにとっての宝です。オープンソースのコードの全ては私たちにとって静的解析システムの莫大なテスト用リソースとなりますし、それを生かして、研究所から外に出なくてもバグを最大限に見つけたり誤検出を最小限にするようにアルゴリズムを強化することができます。また私たちが誇りに思っていることに、Scan（http://scan.coverity.com）というツールで見つけた不具合をオープンソースにフィードバックしていることがあります。Scanの結果を見たディベロッパによって今までに8000以上の不具合が修正されています。オープンソースのツールということでいえば、それは開発者向けツールの市場にある程度の影響を及ぼしていますが、より進んだ技術をもったりエンタープライズレベルの機能やサポート体制のあるツールにはまだまだ大きな市場があることを私たちは知っていますし、さらにツールが発展するようコアとなる価値に対して投資することに積極的です。改善することなしにキャッシュを稼ごうとするツールがあれば、それはオープンソースに取って代わられるだけです。

マルチスレッドアプリケーションを作るJavaディベロッパにとって一番の問題は何でしょうか？

もともと私たちは、競合状態が一番重要な問題だと考えていました。それによりデータ破壊が起きたり、特にそれが起きた原因までさかのぼるのが難しいからです。しかし驚いたことに多くの顧客はデッドロックが一番問題だというのです。なぜならそれがアプリケーションを完全に停止させてしまうからです。私たちの社内開発でも、Javaプラットフォームではデッドロックがエンタープライズアプリケーションのテストや稼働において一番の問題のひとつと考えている、と言うアーキテクトがいました。このような見方は競合状態が重大なデータ破壊を起こすことに気づいてないことを表しているのですが、、、デッドロックはすぐ表面化するのに対して、競合状態はその性格次第では気づかれないこともありえますしね。

Thread Analyzerの次のバージョンに向けて取り組んでいる機能はありますか。

我が社の静的解析製品群とより一層連携することを計画していて、それにより製品間で情報を共有してパフォーマンスや不具合発見度を向上できるようにします。また複数のサーバを利用する分散プログラムでの並行性問題を検出する機能を計画しています。そしてあとは、Thread Analyzerがより多くの人々に広がるようにプラットフォームベンダとの連携を模索しているところです。

原文はこちらです：http://www.infoq.com/news/2008/09/coverity