JP2022505341A - パフォーマンス特性に従って選択的にプログラムを計装するためのシステム及び方法 - Google Patents

Abstract

本明細書に記載のシステム、方法、及び他の実施形態は、プログラム内の計装のパフォーマンスオーバーヘッドを決定することに関する。一実施形態において、方法は、プログラムをソースコードからマシンコードにコンパイルすることに応じて、プログラムの個別の関数内の計装のセグメントに関連付けられるオーバーヘッドスコアを生成するようにプログラムを分析することを含む。計装は、ソースコードと組み合わされて、プログラムの基本機能に追加される機能を提供する。方法は、セグメントのそれぞれのオーバーヘッドスコアが個別の関数のそれぞれに関連付けられた計装閾値を満たすかどうかに応じて、個別の関数のソースコード内のセグメントを選択的に変更することを含む。

Description

関連出願の相互参照

この出願は、２０１８年１０月１８日に出願された米国特許出願第１６／１６４１７３号の利益を主張し、その開示全体が参照により本明細書に組み込まれる。

本明細書に記載される主題は、概して、プログラム内の計装に起因するパフォーマンスオーバーヘッドを決定するためのシステム及び方法に関し、より具体的には、パフォーマンスオーバーヘッドを動的に決定し、それに応じていずれの計装をプログラムに含めるかを自動的に変更することに関する。

コンピュータプログラムの文脈において、計装は、一般的に追加の機能を提供するためにプログラム内の関数に追加される追加のコードを指す。追加の機能は、追加の機能のフック、セキュリティの確保、トレーサビリティの提供などに関連し得る。いずれにせよ、追加された計装は、本質的にプログラムのパフォーマンスに影響を与える。従って、このような計装が各関数に無差別に追加されると、プログラムの全体的なパフォーマンスが増加されたオーバーヘッドに悩まされる可能性がある。

さらに、様々な方法が、プログラム全体を実行するための全体的なオーバーヘッドを決定するが、計装の特定のセグメントに関するオーバーヘッドを評価することは、非常に困難であり得る。これは、計装のソースコードがプログラム自体のソースコードと一緒に統合されているため、オーバーヘッドをプログラムのソースコードに帰するか、又は計装のソースコードに帰するかのプロセスが複雑になるためである。その結果、プログラムを最適に計装する方法を決定するには、通常、計装を追加及び削除する手作業の試行錯誤的なプロセスが必要になるが、これは非効率的である。

一実施形態において、プログラム内の計装のパフォーマンスオーバーヘッドを決定することに関連する例示的なシステムおよび方法が開示される。前述のように、現在の解決策では、個別の関数内の計装に固有のパフォーマンスオーバーヘッドを別々に特定することは、現在の解決策では一般的に実行不可能である。このため、現在のアプローチでは、試行錯誤的なアプローチを通じてパフォーマンスオーバーヘッドを調整するために、ランダムな計装を手作業で削除することに頼っている。予想されるように、そのようなアプローチは概して非効率的であり、最適解をもたらさない可能性がある。

そのため、一実施形態では、計装の別々のセグメントについて個別にパフォーマンスオーバーヘッドを決定するオーバーヘッド評価システムが開示される。例えば、１つのアプローチでは、開示されるシステムは、最初に、プログラム命令及び計装命令の命令数を特定する。オーバーヘッド評価システムは、関数の別個の側面（たとえば、計装とベースソースコード）にオーバーヘッドを帰することができる基礎を生成するために、関数ごとに命令数を特定する。

オーバーヘッド評価システムは、１つのアプローチにおいて、それぞれの関数のランタイムカバレッジも決定する。オーバーヘッド評価システムは、例えば、プログラムの実行中のプログラムの動的評価を使用して、またはプログラムの静的分析を通じて、ランタイムカバレッジを決定することができる。オーバーヘッド評価システムは、プログラムの分析を通じて、例えば開発テスト環境において実行時のプログラムの挙動を動的に捕捉するようにして、動的評価を実施する。動的評価では、どの関数が実行されているか、および個別の関数にかかる時間（例えば、全体の実行時間のパーセント）の指標が提供される。あるいは、オーバーヘッド評価システムは、例えば、アプリケーションのエントリポイントを介してプログラムを評価し、再帰的検索を使用して、そこから個別の関数に関連付けられた実行パスと予測実行時間を特定することにより、静的分析を実行する。いずれの場合も、オーバーヘッド評価システムは、プログラムのパフォーマンスオーバーヘッドをさらに評価するため、ランタイムカバレッジを生成する。

続いて、オーバーヘッド評価システムは、命令数とランタイムカバレッジを使用して、パフォーマンスオーバーヘッド（例えば、実行時間）を個別の関数に、ひいては個別の関数内の計装に帰属させる。従って、オーバーヘッド評価システムは、それぞれの関数内の計装に関連付けられたオーバーヘッドスコアを生成することを通じて、このオーバーヘッドを表す。そして、オーバーヘッド評価システムは、一実施形態において、次に、電子ディスプレイ上にオーバーヘッドスコアを視覚的に表示するか、または別の適切な形式でレポートを生成することによって、計装の様々なオーバーヘッドスコアを報告する。

さらなる態様では、オーバーヘッド評価システムは、計装ポリシーに従って、関数内の計装を選択的に変更する（例えば、削除する）。一実施形態において、計装ポリシーは、関数内の計装をいつ削除し、又は維持するかを決定することを容易にする閾値を定義する。例えば、計装の閾値は、重要度、セキュリティなどの特定の関数の特性に応じて変化し得る。

その結果、オーバーヘッド評価システムが、計装を含めるように選択的に個別の関数を変更しようとする場合に、システムは、計装が削除されるべきか否かを決定するための計装閾値との比較において、個別の関数の計装のオーバーヘッドスコアを参照する。従って、オーバーヘッド評価システムは、特定の関数は計装されたままであることを確保しつつ、全体的なパフォーマンスオーバーヘッドを改善するために、プログラム内の計装を自動的かつ動的に調整することができる。このようにして、オーバーヘッド評価システムは、特定の関数に計装を選択的に含めつつ、他の関数から計装を削除することによって、プログラムの機能を改善する。

一実施形態において、プログラムを選択的に計装するためのオーバーヘッド評価システムが開示される。１つ以上のプロセッサと、１つ以上のプロセッサに通信可能に結合されたメモリとを含む。メモリは、１つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに、プログラムを分析して、プログラムの個別の関数内の計装のセグメントに関連付けられるオーバーヘッドスコアを生成させる命令を含むパフォーマンスモジュールを格納する。計装は、プログラムのソースコードと組み合わされて、プログラムの基本機能に追加される機能を提供する。メモリは、１つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに、セグメントのそれぞれのオーバーヘッドスコアが、個別の関数のそれぞれと関連付けられた計装閾値を満たすかどうかに応じて、個別の関数について、プログラムのソースコード内のセグメントを選択的に変更させる命令を含む計装モジュールを格納する。

一実施形態において、非一時的なコンピュータ可読媒体が開示される。コンピュータ可読媒体は、１つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに開示された機能を実行させる命令を格納する。命令には、プログラムを分析して、プログラムの個別の関数内の計装のセグメントに関連付けられるオーバーヘッドスコアを生成する命令が含まれる。計装は、ソースコードと組み合わされて、プログラムの基本機能に追加される機能を提供する。命令には、セグメントのそれぞれのオーバーヘッドスコアが、個別の関数のそれぞれと関連付けられた計装閾値を満たすかどうかに応じて、個別の関数について、プログラムのソースコード内のセグメントを選択的に変更する命令が含まれる。

一実施形態において、プログラムを選択的に計装する方法が開示される。この方法は、プログラムをソースコードからマシンコードにコンパイルすることに応答して、プログラムを分析し、プログラムの別個の関数内の計装のセグメントに関連付けられるオーバーヘッドスコアを生成することを含む。計装は、ソースコードと組み合わされて、プログラムの基本機能に追加される機能を提供する。方法は、セグメントのそれぞれのオーバーヘッドスコアが、個別の関数のそれぞれと関連付けられた計装閾値を満たすかどうかに応じて、個別の関数について、ソースコード内のセグメントを選択的に変更することを含む。

本明細書に組み込まれ、その一部を構成する添付図面は、本開示の様々なシステム、方法、および他の実施形態を示す。図中に示された要素の境界（例えば、ボックス、ボックスのグループ、または他の形状）は、境界の一実施形態を表すことが理解されよう。いくつかの実施形態では、１つの要素が複数の要素として設計されてもよく、または複数の要素が１つの要素として設計されてもよい。いくつかの実施形態では、別の要素の内部コンポーネントとして示される要素は、外部コンポーネントとして実現されてもよく、その逆もあり得る。さらに、要素は縮尺どおりに描かれない場合がある。
図１は、プログラムを分析して、プログラムのパフォーマンスを改善するため計装が選択的に変更されるオーバーヘッドスコアを生成することに関連するオーバーヘッド評価システムの一実施形態を示す。 図２は、プログラムのパフォーマンスを改善するため計装が選択的に変更されるプログラムの様々な側面のオーバーヘッドスコアを生成することに関連する方法の一実施形態を示す。 図３は、プログラムを分析して、選択的に変更することに関連するプロセスの一例を示す。 図４は、計装された関数の一例を示す。

プログラム内の計装のパフォーマンスオーバーヘッドを決定することに関連するシステム、方法、及び他の実施形態が開示される。前述のように、プログラム内の計装に関連するオーバーヘッドを評価するための現在の解決策は、概して効果的ではない。つまり、現在のアプローチでは、概して試行錯誤的なアプローチを通じてオーバーヘッドを手作業で決定することに頼っている。これは、最適解を生じさせるには概して効果的ではなく、そのため、プログラムを効果的に計装することが困難になり、例えばパフォーマンスの低下との結果をもたらす可能性がある。

そのため、様々な実施形態において、関数及び対応する計装について、個々にパフォーマンスオーバーヘッドを決定するオーバーヘッド評価システムおよび関連する方法が開示される。１つのアプローチでは、開示されるシステムは、パフォーマンスを評価するための基礎を生成するために、プログラムがコンパイルされるときに特定される命令数を使用する。オーバーヘッド評価システムは、パフォーマンスオーバーヘッドを関数の別個の側面（例えば、計装対ベースソースコード）に帰属させるために、関数ごとに命令数を特定する。

一実施形態において、オーバーヘッド評価システムは、それぞれの関数のランタイムカバレッジも決定する。ランタイムカバレッジは、通常、個別の関数に起因する実行時間のパーセンテージを示す。オーバーヘッド評価システムは、例えば、プログラムが実行されている間のプログラムの動的評価を使用して、あるいは、プログラムの静的分析を通じて、ランタイムカバレッジを決定することができる。動的評価を介してランタイムカバレッジを決定することは、一実施形態において、プログラムの挙動を動的に捕捉するように、プログラムが開発／テスト環境において実行されている間にプログラムを分析することを含む。評価された挙動は、どの関数がより頻繁に実行されるか、従って、個別の関数に起因する時間（例えば、全体の実行時間のパーセント）についての見識を提供する。代替の構成では、オーバーヘッド評価システムは、プログラムをアルゴリズム的に分析して実行パスを予測し、そこから予測される実行時間を提供する静的分析を実行する。いずれの場合も、オーバーヘッド評価システムは、プログラムのパフォーマンスオーバーヘッドをさらに評価するため、ランタイムカバレッジを生成する。

続いて、オーバーヘッド評価システムは、命令数を個別の関数のランタイムカバレッジに適用して、実行時間を個別の関数に、ひいては個別の関数内の計装に帰属させる。以下の数学的アプローチについて考えてみる。Ｋが実行時間係数、ｐが計装された関数の実行時間、及び、ｑが計装されていない関数の実行時間とする。
（数１） K = p / q

（ｐ－ｑ）は一定であると近似できるため、定数Ｃとして定義される。従って、上記の式は次のように書き直すことができる。
（数２） K = ( q + C ) / q
（数３） K = 1 + C / q

従って、上記の式から、ｑが大きくなるにつれて、Ｋは１に近づくことがわかる。
そのため、元の関数のサイズが大きくなるにつれて、計装の影響は小さくなる。一般に、異なる関数の実行時間は命令数とともに変化するため、異なる関数を計装する際、説明された値は変わる。

従って、オーバーヘッド評価システムは、それぞれの関数内の計装に関連するオーバーヘッドスコアを生成することによって、このオーバーヘッドを表す。オーバーヘッドスコアは、一般的に、例えば関数のコード全体に対する計装されたコードの比率に従って、特定の関数の実行時間を、プログラム自体のソースコードと関数の計装とに区分的に関連付ける。

かくして、オーバーヘッド評価システムは、一実施形態において、計装ポリシーに従って関数から計装を変更する（例えば、削除する）。一実施形態では、計装ポリシーは、関数内の計装をいつ削除し、または維持するかを決定することを容易にする閾値を定義する。例えば、計装閾値は、重要度、セキュリティなどの特定の関数の特性に応じて変化し得る。例えば、特定の関数がプログラムのセキュリティにとって重要であると見なされる状況では、計装閾値が相対的に高くなる可能性がある。対照的に、関数がなんらセキュリティリスクを晒すことがない副次的機能のためのものである場合、計装閾値は、相対的に低くなる可能性がり、それは、セキュリティ上重要な関数に比較して、その関数から計装が削除される可能性がより高くなることを意味する。

その結果、オーバーヘッド評価システムは、個別の関数を選択的に変更して計装を含めるとき、システムは、計装のオーバーヘッドスコアをそれぞれの計装閾値と比較し、計装が削除されるべきか否かを決定する。従って、オーバーヘッド評価システムは、計装の影響を評価し、プログラム内の計装を動的に調整して、プログラムの全体的なパフォーマンスオーバーヘッド（すなわち、全体的なランタイム）を改善することができる。

図１を参照すると、オーバーヘッド評価システム１００の一実施形態が示されている。本明細書では、オーバーヘッド評価システム１００に関して構成を説明するが、実施形態は、図示のような単一のシステムに限定されないことが理解されよう。いくつかの実装形態において、オーバーヘッド評価システム１００は、クラウドコンピューティングシステム、クラスターコンピューティングシステム、分散コンピューティングシステム、ソフトウェア－アズ－ア－サービス（ＳａａＳ）システムなどとして具現化され得る。従って、オーバーヘッド評価システム１００は、説明の目的のため単一のデバイスとして図示され、説明されるが、開示されるコンポーネントが構成することができる全体的な可能な構成を制限するように解釈されるべきではない。例えば、別個のモジュール、メモリ、データベースなどは、様々な組み合わせで様々なコンピューティングシステムに分散されても良い。

オーバーヘッド評価システム１００はまた、様々な要素を含む。様々な実施形態では、オーバーヘッド評価システム１００が図１に示されるすべての要素を有する必要がない場合があることが理解されよう。オーバーヘッド評価システム１００は、図１に示される様々な要素の任意の組み合わせを有することができる。さらに、オーバーヘッド評価システム１００は、図１に示されるものに対して追加の要素を有することができる。いくつかの構成では、オーバーヘッド評価システム１００は、図１に示される１つ以上の要素なしで実現されても良い。さらに、様々な要素が図１のオーバーヘッド評価システム１００内に配置されているように示されているが、これらの要素のうちの１つ以上は、オーバーヘッド評価システム１００の外部に配置することができることが理解されよう。さらに、示されている要素は、大きな距離で物理的に隔てられても良い。

加えて、図のシンプルさと分かり易さのため、適宜、対応するまたは類似の要素を示すために、異なる図の間で参照番号が繰り返されることが理解されよう。さらに、説明は、本明細書に記載された実施形態の完全な理解を提供するために、多くの特定の詳細を概説する。しかしながら、当業者は、本明細書に記載の実施形態が、これらの要素の様々な組み合わせを使用して実施され得ることを理解するであろう。

いずれの場合も、オーバーヘッド評価システム１００は、プログラム内の計装のパフォーマンスオーバーヘッドに関する情報を提供することに関連する、本明細書に開示される方法および他の機能を実行するように実現される。言及される機能と方法は、図のさらなる説明でより明らかになるであろう。さらに、オーバーヘッド評価システム１００は、プロセッサ１１０を含むものとして示されている。このように、様々な実施例において、プロセッサ１１０は、オーバーヘッド評価システム１００の一部であっても良いし、オーバーヘッド評価システム１００は、データバスまたは別の通信経路を介してプロセッサ１１０にアクセスしても良いし、プロセッサ１１０は、オーバーヘッド評価システム１００によってアクセス可能なリモートコンピューティングリソースであっても良い。いずれの場合も、プロセッサ１１０は、他の電子デバイスを制御する、または他の電子デバイスの制御を引き起こすために使用され得る様々な電子的出力を生成するようにマシン可読命令を実行することができる、マイクロプロセッサ、ＡＳＩＣ、または別のコンピューティングコンポーネントなどの電子デバイスである。

一実施形態において、オーバーヘッド評価システム１００は、パフォーマンスモジュール１３０、および計装モジュール１４０を格納するメモリ１２０を含む。メモリ１２０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、ハードディスクドライブ、フラッシュメモリ、またはモジュール１３０及び１４０を格納するための他の適切なメモリである。モジュール１３０及び１４０は、例えば、プロセッサ１１０によって実行されるとき、プロセッサ１１０に本明細書に開示される様々な機能を実行させるコンピュータ可読命令である。様々な実施形態では、モジュール１３０及び１４０は、限定されないが、ハードウェアロジック、ＡＳＩＣ、プロセッサ１１０のコンポーネント、電子メモリ内に埋め込まれた命令などを含むことができる、様々な形態で実現することができる。

オーバーヘッド評価システム１００を引き続き参照すると、一実施形態では、システム１００はデータベース１５０を含む。データベース１５０は、一実施形態では、メモリ１２０、分散メモリ、クラウドベースメモリ、または別のデータストアに格納された電子データ構造であり、格納されたデータを分析する、格納されたデータを提供する、格納されたデータを整理するなどのため、プロセッサ１１０によって実行され得るルーチンで構成される。例えば、一実施形態では、データベース１５０は、様々な決定を実行する際にモジュール１３０及び１４０によって使用されるデータを格納する。一実施形態では、データベース１５０は、プログラム１６０を格納する。さらなる実施形態では、オーバーヘッド評価システム１００は、プログラム１６０を、メモリ１２０、特化型データ構造、プロセッサ１１０のキャッシュメモリ、または別の適切なデータストレージコンポーネントに格納する。

本明細書で使用されるように、プログラム１６０は、ソースコードから導出されるコンパイルされたマシンコードを指す。例えば、一実施形態において、プログラム１６０は、マシンコードであるコンパイル済みのプログラムまたはその一部である。本明細書で使用される「マシンコード」という語句は、一般的に、例えば、プロセッサ１１０などのマイクロプロセッサによって実行することができる機械語命令で表されるプログラムを指す。さらに、マシンコードは、一般的に、関連するハードウェアによって実行される命令セットによって定義されるオペコードで構成される、原始言語またはハードウェア依存言語であると理解される。さらに、マシンコード自体は、データ値、レジスタアドレス、メモリアドレスなどでさらに構成される。もちろん、プログラム１６０はマシンコードであると説明されているが、さらなる実施形態では、プログラム１６０は、アセンブリコードまたはソースコードの別の中間表現である。

プログラム１６０のコンパイル元となるソースコードは、例えば、関数、データ構造、オブジェクト、ステートメントなどで構成される。一般的に、プログラムは一連の関数として編成されている。様々な表現において、関数は、サブ関数として互いに入れ子にされ得る。さらに、関数は、通常、一連のステートメント（ループ、Ｉ／Ｏステートメントなど）から構成され、典型的には特定の機能にフォーカスされている。つまり、各個別の関数は、通常、特定のタスクを行うために実行される。例えば、サブ関数は、親関数のより広範な機能をサポートするサブルーチンを実行することができる。いずれの場合も、関数は、関数自体を形成するステートメントを定義し、その関数に関連付けられた機能の実現を提供するソースコードを含む。さらに、関数は、計装を実行するステートメントを含むようにも開発される。

前述のように、計装は、特定の実装例に応じて異なる目的を果たすことができる。例えば、計装は関数内に統合されて、プログラムフローを制御する（例えば、プログラムが誤った方向に向かわないことを確認する）、デバッグする、データ引数を検証する、Ｉ／Ｏを検証する、などを提供することができる。例えば、プログラム１６０が先進運転支援システム（ＡＤＡＳ）を制御して、道路上で車両がどのように制御されるかを自動的に調整する例において、計装は、プログラム１６０が悪意のある攻撃によって誤った方向に向けられた場合に、事故や乗員の負傷をもたらし得るプログラム１６０の悪意のある操作を防ぐためのセキュリティ計装を含むことができる。

計装の目的に係わらず、ソースコードに追加のステートメントを追加すると、コンパイルされるプログラム１６０内に追加の命令がもたらされる。これらの追加の命令は、さらなる実行時間を加えることによって、本質的にプログラム１６０のパフォーマンスオーバーヘッドに影響を与える。プログラム１６０の追加の態様およびパフォーマンスオーバーヘッドについては、後で説明する。

データベース１５０について続けると、一実施形態では、データベース１５０は、１つ以上のオーバーヘッドスコア１７０及び計装ポリシー１８０も格納する。後でより詳細に説明されるように、パフォーマンスモジュール１３０は、個別の関数のランタイムカバレッジに対する計装及びプログラムソースコードの命令数に応じて、オーバーヘッドスコア１７０を生成する。このように、一実施形態では、オーバーヘッドスコア１７０は、プログラム１６０内の各関数に関連付けられた別個のスコアを含む。

計装ポリシー１８０は、一実施形態において、計装閾値又は少なくとも計装閾値を生成するためのメトリクスを定義する。１つのアプローチでは、計装ポリシー１８０は、多様なクラスの関数の計装閾値を定義する。例えば、計装ポリシー１８０は、一実施形態において、セキュリティレベルに従って関数のクラスを定義する。例えば、計装ポリシー１８０は、第１のクラスの第１の閾値、第２のクラスの第２の閾値、第３のクラスの第３の閾値などを示すことができる。概して、セキュリティレベルの個別のクラス及び関連付けられる閾値は、特定の関数の脆弱性（例えば、操作への露出）に関連する場合がある。例えば、計装ポリシー１８０は、比較的機密性の高い／重要な関数に対して許容される、より高い閾値（例えば、パフォーマンスオーバーヘッドへのより大きな影響）を示し得るが、その一方で、より重要でない／機密性の高くない関数は、より低い閾値又はパフォーマンスへの許容可能な影響を有し得る。従って、実際に、より重要ではない関数が、通常、計装モジュール１４０によって計装が削除される可能性が高くなる。

さらなる例として、計装ポリシー１８０は、１つのアプローチにおいて、関数の機能的関連性に従って別個の閾値を定義する。すなわち、特定の関数が、プログラム１６０の機能にとって相対的により重要である、あるいは中心的であると考えられる場合、その特定の関数は、機能レベル及びその機能レベルに対して関連付けられる計装閾値を高める特性を有している。さらに、さらなる態様では、計装ポリシー１８０は、関数について複数の分類を示す。つまり、関数は、例えば、セキュリティと機能的関連性の両方を含む複数の特性を持つことができる。従って、パフォーマンスモジュール１３０は、１つのアプローチにおいて、関数の特性（例えば、重要度レベル）に従って計装閾値を生成するために、複数の分類を考慮する。例えば、様々なアプローチにおいて、パフォーマンスモジュール１３０は、プログラム１６０の様々な関数について、それぞれの計装閾値を別々に計算してもよい。もちろん、計装ポリシー１８０に関連して機能レベルとセキュリティレベルが説明されるが、これらの分類は、説明の目的のため例として提供されたものである。本開示の広がりは、前述のように、他の分類も包含し得ることを理解されたい。

そして、図１について続けると、パフォーマンスモジュール１３０は、一実施形態において、プロセッサ１１０によって実行されるとき、プロセッサに、プログラム１６０の個別の関数内の計装のそれぞれのセグメントと関連付けられるオーバーヘッドスコア１７０を生成させるコンピュータ可読命令を含む。つまり、前述したように、パフォーマンスモジュール１３０は、プログラムの関数についてスコア１７０を生成する。従って、パフォーマンスモジュール１３０は、プログラム１６０を分析するとき、通常、複数のスコアを生成する。

さらに、パフォーマンスモジュール１３０がスコア１７０を生成することに関連する特定のタイミングは、特定の実施形態に応じて変化し得る。１つのアプローチにおいて、パフォーマンスモジュール１３０は、プログラム１６０がソースコードからマシンコードにコンパイルされることに応じてオーバーヘッドスコア１７０を生成する。例えば、一実施形態において、パフォーマンスモジュール１３０は、コンパイラがソースコードからマシンコードを生成している間に実行され、関数をアクティブに追跡し、計装と、それぞれの関数の基本機能とについて、コンパイラによって生成された命令数を決定する。本明細書で使用されるように、基本機能は、一般に、計装とは無関係であり、プログラムの目的に関連する、ソースコード及びソースコードによって実行される関連機能を指す。対照的に、計装は、例えば、プログラムのセキュリティを向上させるセキュリティメカニズムとして提供されるが、必ずしもプログラム自体の目的に直接関連しているわけではない。

代替の構成において、パフォーマンスモジュール１３０は、マシンコードの命令数を概算する方法として、ソースコードの命令数を使用する。例えば、パフォーマンスモジュール１３０は、１つのアプローチにおいて、対応する正確なマシンコードの命令数を翻訳又はその他の方法で決定することなく、単にソースコードからの命令数を使用する。さらなる態様では、パフォーマンスモジュール１３０は、ソースコードステートメントと標準化されたマシンコードの等価物との間の事前定義された相関関係に従って命令数を決定する。パフォーマンスモジュール１３０は、一実施形態において、各々の特定のソースコード命令に、幾つのマシンコード命令が典型的に対応するかを示す相関台帳を格納する。一実施形態では、この台帳から、パフォーマンスモジュール１３０は、命令数を計算する。

本明細書で使用されるように、命令数は、一般に、ソースコード命令またはマシンコード命令のいずれかを指し、パフォーマンスモジュール１３０によってカウントされる特定のタイプの命令は、特定の実施形態に従って変化し得ることを理解されたい。もちろん、理解され得るように、マシンコード命令数を使用すれば、例えば、帰属する実行時間を決定する際により高い精度を提供するが、ソースコードの命令数を使用すると、概して精度は低いが、シンプルなアプローチとなる。

さらに、本明細書で使用される「ソースコード」という用語は、一般に、マシンコードが導出される高レベルプログラミング言語を指すことを理解されたい。つまり、コンパイラやインタプリタなどのコンポーネントは、通常、ソースコードの実行可能形式としてマシンコードを生成する。ソースコードは、例えば、元々、開発者がマシンコードの抽象化された形式である関数、ステートメント、データ引数、データ構造、及び他のプログラム構成要素を用いることによって生成される。コンパイラによって実行されるポリシーと手順に従って、コンパイラはソースコードをマシンコードに変換する。

さらに、パフォーマンスモジュール１３０は、通常、計装命令数およびプログラム命令数を決定する。計装命令数は、関数内に含まれる計装に関連し、プログラム命令数は、計装に帰属されない、むしろ関数そのものに関連付けられた基本機能に関する、関数内の残りの命令に関連する。このように、パフォーマンスモジュール１３０は、プログラム１６０内の個別の関数について、プログラム命令数と計装関数数を生成する。

パフォーマンスモジュール１３０は、ランタイムカバレッジも生成する。一実施形態において、ランタイムカバレッジは、プログラム１６０の関数に起因するプログラムの全体的な実行時間のパーセントを指す。従って、例として、プログラム１６０が１００秒間実行されることを考える。さらに、プログラム１６０が４つの関数Ａ、Ｂ、Ｃ、およびＤから構成されることを考える。１つのアプローチにおいて、パフォーマンスモジュール１３０は、テスト／開発環境においてプログラム１６０の実行を追跡する。テスト／開発環境は、例えば、プログラム１６０の実行の様々な側面を追跡することができる管理された動作環境である。このように、パフォーマンスモジュール１３０は、分析中の所与の時点でどの関数が実行されているかを動的に追跡する。

かくして、パフォーマンスモジュール１３０は、全体の実行時間の一部を関数に帰属させる。上記の例について続けると、パフォーマンスモジュール１３０が、関数Ａを５０秒間実行するとして関数Ａを追跡し、３２秒間の実行として関数Ｂを追跡し、１５秒間の実行として関数Ｃを追跡し、３秒間実行するとして関数Ｄを追跡したことを考える。従って、パフォーマンスモジュールは、実行時間の以下のパーセンテージで関数を評価する、Ａ－５０％、Ｂ－３２％、Ｃ－１５％、及びＤ－３％。

それにより、個別の関数の決定されたランタイムカバレッジを使用して、パフォーマンスモジュール１３０は、オーバーヘッドスコア１７０を決定する。代替の実施形態では、パフォーマンスモジュール１３０は、前述の動的分析の代わりに、プログラム１６０の静的分析を使用する。すなわち、パフォーマンスモジュール１３０は、プログラム１６０をアルゴリズム的に解析およびステップスルーして、そこからそれぞれの関数の可能性のある実行パス及び可能性のある実行時間を決定する。静的分析への１つのアプローチにおいて、パフォーマンスモジュール１３０は、ランタイムカバレッジを静的に生成するために、選択されたプログラムエントリポイントからプログラム１６０の限定されたパスの深さの再帰的分析を実施する。このように、パフォーマンスモジュール１３０は、平均または予想される命令実行時間に従って、命令に定義された実行時間を帰属させつつ、プログラム１６０の命令をステップスルーする。パフォーマンスモジュール１３０は、再帰的限定パス深さアプローチに従って各関数の命令を辿り、そこからの関数の実行時間を評価する。従って、結果として、パフォーマンスモジュール１３０は、動的アプローチによって提供されるものと同様の形式で、プログラム１６０の個別の関数に起因するランタイムカバレッジを提供する。

説明された命令数及びランタイムカバレッジ評価から、パフォーマンスモジュール１３０は、関数のオーバーヘッドスコア１７０を計算する。特に、パフォーマンスモジュール１３０は、１つのアプローチにおいて、関数の全体的な命令に対する、関数に含まれる計装命令の比率を決定する。すなわち、パフォーマンスモジュール１３０は、関数についての計装カウントおよびプログラムカウントを使用して、例えば、パーセントまたは比率として、計装に帰属する関数の全体的な命令の量を特定する。例えば、１つのアプローチでは、パフォーマンスモジュール１３０は、以下に従って比率を決定する。
計装帰属部分＝（計装カウント）／（計装カウント＋プログラムカウント）

パフォーマンスモジュール１３０は、計装に帰属する命令数と共に個別の関数の決定されたランタイムカバレッジを使用して、オーバーヘッドスコア１７０を生成する。１つのアプローチにおいて、パフォーマンスモジュール１３０は、特定の関数についてのランタイムカバレッジと、計装帰属部分とを掛け合わせることによって、オーバーヘッドスコア１７０を計算する。パフォーマンスモジュール１３０は、結果として得られる値をオーバーヘッドスコアとして使用するか、あるいは、さらなるアプローチにおいて、結果として得られる値を正規化するか、さもなければ更なる形式に変換して、オーバーヘッドスコア１７０を生成する。

関数Ａ、Ｂ、Ｃ、及びＤの上記の例について続けて、記載された関数の命令数に従って生成された計装値が、以下の通りであると考える、Ａ－６％、Ｂ－１０％、Ｃ－１％、及びＤ－１９％。このように、記載された関数は、プログラムソースコードに対する様々な範囲の計装を含む。かくして、説明の目的のため、パフォーマンスモジュール１３０は、ランタイムカバレッジの値と命令数の値との生の乗算を使用して、オーバーヘッドスコア１７０を実現すると仮定する。従って、この例で結果として得られるオーバーヘッドスコアは、以下の通りである。Ａ－０.００３、Ｂ－.００３２、Ｃ－.００１５、及びおよびＤ－.００５７。従って、オーバーヘッドスコア１７０は、プログラム１６０内の関数の計装の量が全体の実行時間にどの程度影響し得るかを示す。

パフォーマンスモジュール１３０がオーバーヘッドスコア１７０を生成すると、計装モジュール１４０が実行され、オーバーヘッドスコアに従って様々なアクションを実行する。一実施形態では、計装モジュール１４０は、パフォーマンスオーバーヘッドに関する計装の影響について開発者に知らせるために、開発環境内でオーバーヘッドスコア１７０を電子的に表示する。様々なアプローチにおいて、オーバーヘッド評価システム１００は、開発者がプログラム１６０を生成するときに、オーバーヘッドスコア１７０を動的に生成し、表示する。このように、オーバーヘッド評価システム１００は、一実施形態において、スコア１７０を生成し、プログラム１６０内にどの計装を含めるかについて開発者の選択に影響を与えるメカニズムを提供する。

追加的に、又は代替的に、１つのアプローチにおいて、計装モジュール１４０は、プログラム１６０を選択的に変更して、計装を自動的に削除する。すなわち、計装モジュール１４０は、オーバーヘッドスコア１７０およびオーバーヘッド閾値を使用して、関数から計装を削除するかどうかを決定する。前述のように、計装モジュール１４０は、計装ポリシー１８０によって定義された計装閾値を使用するか、又は少なくとも計装ポリシー１８０内に定義された情報から閾値を生成する。閾値を関数に適合させるため、及びどの関数が計装を保持すべきで、その他は計装を削除すべきかを決定するためのインテリジェントなアプローチを提供するために、閾値は、関数の特性に従って定義される。

さらに、１つの態様において、計装モジュール１４０は、プログラムが全体的なパフォーマンス基準を満たしているかどうかに従って、閾値を動的に調整する。すなわち、計装ポリシー１８０は、１つのアプローチにおいて、プログラム１６０の期待実行時間又は他のパフォーマンスメトリックを定義する。例えば、パフォーマンスモジュール１３０は、計装を含むプログラム１６０の全体的なパフォーマンスを測定し、全体的なパフォーマンスが、例えば、定義された値を下回る場合、計装モジュール１４０は、特定の関数のための計装閾値において、全体的なパフォーマンスをさらに考慮する。このようにして、オーバーヘッド評価システム１００は、プログラム１６０のパフォーマンスを動的に評価し、計装がプログラム１６０の動作を改善するように調整されることを確実にすることができる。

いずれの場合も、計装モジュール１４０は、プログラム１６０のそれぞれの関数のオーバーヘッドスコアをオーバーヘッドスコア１７０と比較する。計装閾値を満たす（例えば、定義された値を超える）関数に関して、計装モジュール１４０は、計装を関数から削除する。計装モジュール１４０は、様々なアプローチにおいて、様々なアプローチを使用して計装を削除する。１つのアプローチでは、計装モジュール１４０は、機能的観点から計装を削除する（すなわち、計装はもはや使用可能なマシンコードにコンパイルされない）が、削除の目印としてコメント化された計装コードを残すために、プログラム１６０のソースコード内の計装をコメントに変更する。さらなる態様では、計装モジュール１４０は、単に注目されている関数から計装を削除し、その削除をログに残すか又は記録してもよい。いずれの場合も、システム１００は、関連する関数、従ってプログラム１６０の動作を改善するために、オーバーヘッドスコア１７０および計装閾値に従って計装を削除する。

計装に関するプログラムのパフォーマンスオーバーヘッドを評価する追加の態様が、図２に関連して説明される。図２は、プログラムのオーバーヘッドスコアを生成し、それに応じてプログラムを選択的に計装することに関連する方法２００を示している。方法２００は、図１のオーバーヘッド評価システム１００の観点から説明される。方法２００は、オーバーヘッド評価システム１００と組み合わせて説明されるが、方法２００は、オーバーヘッド評価システム１００内で実行されることに限定されず、むしろ、方法２００を実行することができるシステムの一例であることを理解されたい。さらに、方法２００はまた、図３に示されるような例示的なプロセスフローと組み合わせて説明される。図３は、様々なデータ要素（例えば、ソースコード３００）及びシステム１００の構成要素に関連するプロセスフローを一般的に示している。このように、図３は、視覚的な例を通じての説明を容易にするために、方法２００と共に説明される。従って、図３に示される構成は、単一の実施形態を表し、方法２００を図３のプロセスフローに制限するように解釈されるべきでないことを理解されたい。

２１０で、ソースコード３００が計装される。ソースコード３００を計装するプロセスは、自動化されていても手動であってもよい。すなわち、１つのアプローチにおいて、オーバーヘッド評価システム１００は、ソースコード３００の注釈、ソースコード３００のプログラム分析、または別のアプローチに従って、計装のセグメントをソースコード３００に自動的に追加する。いずれの場合においても、ソースコード３００は、一般に、一連の関数（例えば、関数３０５、３１０、３１５、および３２０）から構成される。これらの関数は、一般に、ソースコード３００から導出されるプログラムに異なる能力を提供する様々なソースコードのセットを含む。図３に表されるように、ソースコード３００は、様々なサブ関数３０５、３１０、及び３１５と共にメイン関数３２０を含む。従って、関数が分割できない原子的なものであろうと、サブ関数で構成されるものであろうと、様々な実施形態において、関数は計装を含むことができる。例えば、関数３０５、３１０、３１５、及び３２０は、それぞれの計装３２５、３３０、３３５、及び３４０を含む。

関数の一例として、図３の関数３０５についての更なる詳細を示す図４を検討する。示されるように、関数３０５は、例えば、車両のセンサで生成される周囲の道路についてのスキャンデータを分析してレーンを識別するレーンＩＤ関数である。関数３０５は、記載された機能を実行するベースソースコードのセグメント４００と共に、ソースコードのセグメントとして計装３１０を含む。関数３０５の実際のソースコードは、通常、図示されておらず、代わりにコメントブロックに置き換えられていることを理解されたい。しかしながら、コードの別個のセクション３１０、４００は、計装３１０が、関数３０５と、及び他のソースコード（例えば、ソースコード４００）の中に、どのように統合されるのかを示している。さらに、計装３１０が、ソースコード４００と直列かつ別個であるとして図示されているが、１つ以上の実施形態において、計装３１０は、ソースコードセグメント４００のステートメント間に混在させることができる。

２２０で、ソースコード３００は、マシンコード３５０にコンパイルされる。一実施形態では、オーバーヘッド評価システム１００は、ソースコード３００をマシンコード３５０にコンパイルするコンパイラ３４５を含む。更なるアプローチでは、コンパイラ３４５は、システム１００とは別個で分離しているが、システム１００と通信して、マシンコード３５０及び／又はマシンコード３５０に関する情報を提供してもよい。１つのアプローチにおいて、ソースコード３００をコンパイルするプロセスは、コンパイルされたプログラムのパフォーマンスの分析をシステム１００に開始させる。もちろん、更なるアプローチにおいて、システム１００は、オーバーヘッドスコア１７０を生成することの一部として、または別個の手動メカニズムを介してコンパイルを開始する。いずれにせよ、説明の目的のため、ソースコード３００がマシンコード３５０（例えば、プログラム１６０）にコンパイルされ、コンパイルがオーバーヘッドスコアの決定を開始するとみなす。

２３０で、パフォーマンスモジュール１３０は、プログラムを分析して、プログラムの個別の関数内の計装のそれぞれのセグメントに関連付けられるオーバーヘッドスコア３７０を生成する。一実施形態において、パフォーマンスモジュール１３０は、コンパイラ３４５と通信して、マシンコード３５０の命令数３６０を確認する。前述のように、代替のアプローチでは、パフォーマンスモジュール１３０は、マシンコード３５０の近似、または単にソースコード３００自体の命令数のいずれかを使用することによって、ソースコード３００から直接命令数３６０を生成する。いずれの場合も、命令数３６０は、実行時間を様々な関数に帰属させるためのメトリックを提供する。

さらに、２３０で、パフォーマンスモジュール１３０は、プログラムの個別の関数のランタイムカバレッジを動的に捕捉する。図３に示されるように、パフォーマンスモジュール１３０は、実行環境３５５からランタイムカバレッジを取得する。実行環境３５５は、例えば、パフォーマンスモジュール１３０がマシンコード３５０（すなわち、プログラム１６０）の実行にアクセスして追跡するための関数フックまたは他のメカニズムを提供する開発またはテスト環境である。そのため、パフォーマンスモジュール１３０は、個別の関数がいつ、どのくらいの時間実行されているかを識別することができる。このように、パフォーマンスモジュール１３０は、テスト環境でのプログラムの実行を追跡することによって、ランタイムカバレッジ３６５を生成するか、または少なくとも取得する。

その後、パフォーマンスモジュール１３０は、ランタイムカバレッジ３６５及び命令数３６０を使用して、オーバーヘッドスコア３７０を生成する。パフォーマンスモジュール１３０は、個別の関数に関連付けられたそれぞれのセグメントのオーバーヘッドスコアを、それぞれのセグメントのランタイムカバレッジに対するプログラムカウントと計装カウントとの比率として計算する。つまり、各オーバーヘッドスコアは関数に固有である。従って、パフォーマンスモジュール１３０は、プログラムの関数に特化した粒度でオーバーヘッドスコア３７０を生成する。もちろん、さらなる態様では、パフォーマンスモジュール１３０がオーバーヘッドスコア３７０を生成する特定の抽象化層は、特定の実施形態に応じて変化し得るが、一般には、ソースコード３００内の定義された論理セグメントに従う。

２４０で、計装モジュール１４０は、オーバーヘッドスコア１７０／３７０を計装閾値と比較して、オーバーヘッドスコア１７０／３７０が計装閾値を満たすかどうかを決定する。以前に説明したように、計装閾値は独立した関数に固有であり、計装モジュール１４０は、関数の特性に従ってその関数の計装閾値を決定する。計装モジュール１４０は、計装ポリシー１８０を参照して、閾値を定義するために使用される値と特性を相関させる。このようにして、計装モジュール１４０は、関数を選択的に計装する方法を決定するときに、関数間の特性の違いを考慮に入れる。

さらに、本明細書で使用されるように、計装閾値を満たすことは、一般に、閾値を超えることを含む。例えば、閾値が０．００３で、オーバーヘッドスコアが０．００３２の場合、スコアは閾値を超えている。もちろん、計装モジュール１４０は、更なるアプローチにおいて、閾値より大きいか等しい、閾値より大きいか少なくともマージンの範囲内で小さい、閾値より小さい、などを含んで、閾値の充足を異なって定義することもできる。概して、特定の関係は、閾値を介して特定されたもの超える過度のオーバーヘッドを追加する計装がその後に削除されるように定義される。

２５０で、計装モジュール１４０は、計装のセグメントを選択的に変更する。一実施形態では、計装モジュール１４０は、閾値が満たされる関数から計装を削除する。このように、計装モジュール１４０は、例えば、計装を含めることによって実現されるパフォーマンスオーバーヘッドの増加が計装の価値を上回る場合、計装を削除する。かくして、計装モジュール１４０は、選択関数から計装を削除して、計装閾値を満たさない不充足関数のためにプログラム１６０の実行を改善する。

さらなる態様において、計装モジュール１４０は、計装を完全に削除する代わりに、２５０で既存の計装を置き換える。例えば、計装モジュール１４０は、特定の関連する関数により適した代替の計装を選択すること、計装の一部を削除すること、計装が実行される方法（例えば、計装を呼び出す条件）を再編すること、または、より一般的には、オーバーヘッドスコアへの影響が、計装の実行時間への影響を低減することになるように、関数に含まれる計装を変更することによって、計装を最適化する。このようにして、計装モジュール１４０は、計装を完全に削除するか、または計装を変更して、プログラム全体の改善されたパフォーマンスを達成することができる。

さらに、図１のオーバーヘッド評価システム１００は、個別の集積回路及び／又はチップを用いて様々な配置で構成できることを理解されたい。そのような実施形態では、図１のパフォーマンスモジュール１３０は、別個の集積回路として具現化される。さらに、計装モジュール１４０は、個々の集積回路上に具現化される。回路は、個別の回路間で信号の通信を提供するために、接続経路を介して接続される。もちろん、別個の集積回路が説明されるが、様々な実施形態では、回路は、共通の集積回路基板に統合されてもよい。さらに、集積回路は、より少ない集積回路に組み合わせられるか、またはより多くの集積回路に分割されてもよい。別の実施形態では、モジュール１３０、１４０は、分離された特定用途向け集積回路に組み合わされてもよい。さらなる実施形態では、モジュール１３０、１４０に関連する機能の一部は、プロセッサによって実行可能なファームウェアとして具現化され、非一時的メモリに格納されてもよい。さらに別の実施形態では、モジュール１３０、１４０は、プロセッサ１１０のハードウェアコンポーネントとして統合される。

別の実施形態では、説明された方法及び／又はそれらの均等物は、コンピュータ実行可能命令で実現することができる。従って、一実施形態では、非一時的なコンピュータ可読媒体が、マシン（例えば、プロセッサ、コンピュータなど）によって実行されるとき、マシン（及び／又は関連するコンポーネント）にその方法を実行させる、格納されたコンピュータ実行可能命令を有して構成される。

説明を簡単にするために、図に示された方法は一連のブロックとして示され、説明されているが、いくつかのブロックは、図示及び説明されたものから異なる順序で、及び／又は他のブロックと同時に発生し得るため、方法はブロックの順序によって限定されないことを理解されたい。さらに、図示されたすべてのブロックよりも少ないブロックを使用して、例示の方法を実行してもよい。ブロックは組み合わされ、または複数のコンポーネントに分離されてもよい。さらに、追加及び／又は代替の方法は、図示されていない追加のブロックを使用することができる。

オーバーヘッド評価システム１００は、１つ以上のプロセッサ１１０を含むことができる。１つ以上の構成では、プロセッサ１１０は、オーバーヘッド評価システム１００のメインプロセッサであり得る。例えば、プロセッサ１１０は、電子制御ユニット（ＥＣＵ）であり得る。オーバーヘッド評価システム１００は、１つ以上のタイプのデータを格納するための１つ以上のデータストアを含むことができる。データストアは、揮発性及び／又は不揮発性メモリを含むことができる。適切なデータストアの例には、ＲＡＭ（ランダムアクセスメモリ）、フラッシュメモリ、ＲＯＭ（リードオンリーメモリ）、ＰＲＯＭ（プログラム可能リードオンリーメモリ）、ＥＰＲＯＭ（消去可能プログラム可能リードオンリーメモリ）、ＥＥＰＲＯＭ（電気的消去可能プログラム可能リードオンリーメモリ）、レジスタ、磁気ディスク、光ディスク、ハードドライブ、分散メモリ、クラウドベースのメモリ、開示されたデータを格納するのに適した他の記憶媒体、またはそれらの任意の組み合わせが含まれる。データストアは、プロセッサ１１０の構成要素であり得るか、またはデータストアは、プロセッサによる使用のためにプロセッサ１１０に動作可能に接続され得る。この説明全体で使用される「動作可能に接続される」という用語は、直接的な接続、又は直接の物理的接触のない接続を含む、間接的な接続を含み得る。

詳細な実施形態が本明細書に開示される。しかし、開示された実施形態は例としてのみ意図されていることを理解されたい。従って、本明細書で開示される特定の構造及び機能の詳細は、限定として解釈されるべきではなく、単に特許請求の範囲の基礎として、及び、実質的に任意の適切な詳細構造において本明細書の態様を様々に採用することを当業者に教示するための代表的な基礎として解釈されるべきである。さらに、本明細書で使用される用語および語句は、限定することを意図するものではなく、可能な実施例の理解可能な説明を提供することを意図している。種々の実施形態が図１から図４に示されているが、実施形態は、図示された構造または用途に限定されない。

図中のフローチャートおよびブロック図は、様々な実施形態によるシステム、方法、およびコンピュータプログラム製品の可能な実施例のアーキテクチャ、機能、および動作を示している。これに関して、フローチャートまたはブロック図の各ブロックは、特定の論理機能を実行するための１つ以上の実行可能な命令を含むモジュール、セグメント、またはコードの一部を表すことができる。いくつかの代替の実施例では、ブロックに示された機能が、図に記載されている順序以外で発生する可能性があることにも注意されたい。例えば、連続して示された２つのブロックが、実際には、実質的に同時に実行されても良く、またはそれらのブロックが、関連する機能に応じて、ときには逆の順序で実行されても良い。

上述したシステム、コンポーネント、及び／又はプロセスは、ハードウェア又はハードウェアとソフトウェアの組み合わせで実現でき、１つの処理システムにおいて中央集権方式で、または相互接続された複数の処理システムに異なる要素が分散された分散方式で実現することができる。本明細書に記載の方法を実行するように適合されたあらゆる種類の処理システムまたは別の装置が適している。ハードウェアおよびソフトウェアの組み合わせは、ロードされ、実行されたときに、本明細書に記載の方法を実行するように処理システムを制御する、コンピュータで使用可能なプログラムコードを備えた処理システムであり得る。システム、コンポーネント、及び／又はプロセスは、本明細書に記載された方法およびプロセスを実行するためにマシンによって実行可能な命令のプログラムを目に見える方法で具体化した、マシンによって読み取り可能な、コンピュータプログラム製品または他のデータプログラムストレージデバイスなどのコンピュータ読み取り可能なストレージに埋め込むこともできる。これらの要素は、本明細書で説明した方法の実行を可能にするすべての特徴を備えた、処理システムにロードされたときにこれらの方法を実行することができるアプリケーション製品に組み込むこともできる。

さらに、本明細書で説明された構成は、例えば記憶されるなどして、具体化されたコンピュータ可読プログラムコードを有する１つ以上のコンピュータ可読媒体に具現化されるコンピュータプログラム製品の形をとることができる。１つ以上のコンピュータ可読媒体の任意の組み合わせが利用されてもよい。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体であり得る。「コンピュータ可読記憶媒体」という語句は、非一時的な記憶媒体を意味する。コンピュータ可読媒体は、限定されるものではないが、不揮発性媒体および揮発性媒体を含む、形態をとることができる。不揮発性媒体には、たとえば、光ディスク、磁気ディスクなどが含まれる。揮発性媒体には、例えば、半導体メモリ、ダイナミックメモリなどが含まれる。そのようなコンピュータ可読媒体の例には、限定されるものではないが、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、他の磁気媒体、ＡＳＩＣ、ＣＤ、他の光学媒体、ＲＡＭ、ＲＯＭ、メモリチップまたはカード、メモリスティック、および、コンピュータ、プロセッサ、または他の電子デバイスが読み取ることが可能な他の媒体が含まれる。この明細書の文脈において、コンピュータ可読記憶媒体は、命令実行システム、装置、またはデバイスによって、またはそれに関連して使用するためのプログラムを含む、または格納できる任意の有形の媒体であってもよい。

以下は、本明細書で使用される選択された用語の定義を含む。定義には、用語の範囲内にあり、様々な実施例に使用できるコンポーネントの様々な例、及び／又は形式が含まれる。これらの例は限定することを意図していない。用語の単数形と複数形の両方が定義内に含まれる場合がある。

「１つの実施形態」、「実施形態」、「１つの例」、「例」などへの言及は、そのように記載された実施形態または例が、特定の特徴、構造、特性、特質、要素、または限定を含むかもしれないが、すべての実施形態または例が、必ずしも、その特定の特徴、構造、特性、特質、要素、または限定を含むわけではない。さらに、「１つの実施形態では」という語句の繰り返しの使用は、同じ実施形態を指す場合もあるが、必ずしもそうとは限らない。

本明細書で使用される「モジュール」には、コンピュータまたは電気ハードウェアコンポーネント、ファームウェア、命令を保存する非一時的なコンピュータ可読媒体、及び／又は、機能またはアクションを実行するように構成された、及び／又は、別のロジック、方法、及び／又はシステムから機能またはアクションを引き起こすように構成された、これらのコンポーネントの組み合わせが含まれる。モジュールには、アルゴリズムによって制御されるマイクロプロセッサ、ディスクリートロジック回路（ＡＳＩＣなど）、アナログ回路、デジタル回路、プログラムされたロジックデバイス、実行時にアルゴリズムを実行する命令を含むメモリデバイスなどが含まれてもよい。モジュールは、１つ以上の実施形態において、１つ以上のＣＭＯＳゲート、ゲートの組み合わせ、または他の回路部品を含む。複数のモジュールが説明されている場合、１つ以上の実施形態は、複数のモジュールを１つの物理的なモジュールコンポーネントに組み込むことを含む。同様に、単一のモジュールが説明されている場合、１つ以上の実施形態は、単一のモジュールを複数の物理的コンポーネントに分散してもよい。

さらに、本明細書で使用されるモジュールには、特定のタスクを実行したり、特定のデータタイプを実現したりするルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらなる態様において、メモリは一般に、言及されたモジュールを格納する。モジュールに関連付けられたメモリは、プロセッサ内に埋め込まれたバッファまたはキャッシュ、ＲＡＭ、ＲＯＭ、フラッシュメモリ、または別の適切な電子記憶媒体であってもよい。さらに別の態様では、本開示によって想定されるモジュールは、特定用途向け集積回路（ＡＳＩＣ）、システムオンチップ（ＳｏＣ）のハードウェアコンポーネント、プログラマブルロジックアレイ（ＰＬＡ）、または開示された機能を実行するための定義された設定セット（たとえば、命令）が埋め込まれた別の適切なハードウェアコンポーネントとして実現される。

１つ以上の構成において、本明細書に記載のモジュールの１つ以上は、人工または計算知能要素、例えばニューラルネットワーク、ファジー論理または他の機械学習アルゴリズムを含むことができる。さらに、１つ以上の構成において、モジュールの１つ以上は、本明細書で説明する複数のモジュールに分散させることができる。１つ以上の構成では、本明細書に記載のモジュールの２つ以上が、単一のモジュールに組み合わせることができる。

コンピュータ可読媒体に具現化されるプログラムコードは、限定されるものではないが、無線、有線、光ファイバー、ケーブル、ＲＦなど、またはこれらの任意の適切な組み合わせを含む、任意の適切な媒体を使用して送信されてもよい。本構成の態様の動作を実行するためのコンピュータプログラムコードは、Java（登録商標）、Smalltalk、C ++などのオブジェクト指向プログラミング言語、および「C」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで記述されてもよい。プログラムコードは、スタンドアロンソフトウェアパッケージとして、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、あるいは、一部をユーザのコンピュータ上でかつ一部を遠隔コンピュータ上で、もしくは、完全に遠隔コンピュータまたはサーバ上で実行されてもよい。後者のシナリオでは、遠隔コンピュータは、ローカルエリアネットワーク（ＬＡＮ）又はワイドエリアネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続されてもよいし、または、その接続は、外部コンピュータになされてもよい（例えば、インターネットサービスプロバイダを使用したインターネット経由）。

本明細書で使用される「ａ」および「ａｎ」という用語は、１つではなく、１つ以上として定義される。本明細書で使用される「複数」という用語は、２つではなく、２つ以上として定義される。本明細書で使用される「別の」という用語は、少なくとも２番目またはそれ以上として定義される。本明細書で使用される「含む」及び／又は「有する」という用語は、包含する（すなわち、オープン言語）と定義される。本明細書で使用される「...及び...の少なくとも１つ」というフレーズは、関連する列挙されたアイテムの１つ以上の任意の及び全ての可能な組み合わせを指し、包含する。例として、「Ａ、Ｂ、及びＣの少なくとも１つ」というフレーズは、Ａのみ、Ｂのみ、Ｃのみ、またはそれらの任意の組み合わせ（例えば、ＡＢ、ＡＣ、ＢＣまたはＡＢＣ）を含む。

本明細書の態様は、その主旨または本質的な特質から逸脱することなく、他の形態で具現化することができる。従って、本明細書の範囲を示すものとして、前述の明細書ではなく、以下の特許請求の範囲を参照すべきである。

さらに、パフォーマンスモジュール１３０は、通常、計装命令数およびプログラム命令数を決定する。計装命令数は、関数内に含まれる計装に関連し、プログラム命令数は、計装に帰属されない、むしろ関数そのものに関連付けられた基本機能に関する、関数内の残りの命令に関連する。このように、パフォーマンスモジュール１３０は、プログラム１６０内の個別の関数について、プログラム命令数と計装命令数を生成する。

関数Ａ、Ｂ、Ｃ、及びＤの上記の例について続けて、記載された関数の命令数に従って生成された計装値が、以下の通りであると考える、Ａ－６％、Ｂ－１０％、Ｃ－１％、及びＤ－１９％。このように、記載された関数は、プログラムソースコードに対する様々な範囲の計装を含む。かくして、説明の目的のため、パフォーマンスモジュール１３０は、ランタイムカバレッジの値と命令数の値との生の乗算を使用して、オーバーヘッドスコア１７０を実現すると仮定する。従って、この例で結果として得られるオーバーヘッドスコアは、以下の通りである。Ａ－０.０３、Ｂ－.０３２、Ｃ－.００１５、及びおよびＤ－.００５７。従って、オーバーヘッドスコア１７０は、プログラム１６０内の関数の計装の量が全体の実行時間にどの程度影響し得るかを示す。

いずれの場合も、計装モジュール１４０は、プログラム１６０のそれぞれの関数のオーバーヘッド閾値をオーバーヘッドスコア１７０と比較する。計装閾値を満たす（例えば、定義された値を超える）関数に関して、計装モジュール１４０は、計装を関数から削除する。計装モジュール１４０は、様々なアプローチにおいて、様々なアプローチを使用して計装を削除する。１つのアプローチでは、計装モジュール１４０は、機能的観点から計装を削除する（すなわち、計装はもはや使用可能なマシンコードにコンパイルされない）が、削除の目印としてコメント化された計装コードを残すために、プログラム１６０のソースコード内の計装をコメントに変更する。さらなる態様では、計装モジュール１４０は、単に注目されている関数から計装を削除し、その削除をログに残すか又は記録してもよい。いずれの場合も、システム１００は、関連する関数、従ってプログラム１６０の動作を改善するために、オーバーヘッドスコア１７０および計装閾値に従って計装を削除する。

関数の一例として、図３の関数３０５についての更なる詳細を示す図４を検討する。示されるように、関数３０５は、例えば、車両のセンサで生成される周囲の道路についてのスキャンデータを分析してレーンを識別するレーンＩＤ関数である。関数３０５は、記載された機能を実行するベースソースコードのセグメント４００と共に、ソースコードのセグメントとして計装３２５を含む。関数３０５の実際のソースコードは、通常、図示されておらず、代わりにコメントブロックに置き換えられていることを理解されたい。しかしながら、コードの別個のセクション３２５、４００は、計装３２５が、関数３０５と、及び他のソースコード（例えば、ソースコード４００）の中に、どのように統合されるのかを示している。さらに、計装３２５が、ソースコード４００と直列かつ別個であるとして図示されているが、１つ以上の実施形態において、計装３２５は、ソースコードセグメント４００のステートメント間に混在させることができる。

Claims (20)

1. プログラムを選択的に計装するためのオーバーヘッド評価システムであって、
   １つ以上のプロセッサ（１００）と、
   １つ以上のプロセッサに通信可能に結合され、１つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに、プログラムを分析して、プログラムの個別の関数内の計装のセグメントに関連付けられるオーバーヘッドスコアを生成させる命令を含むパフォーマンスモジュール（１３０）と、計装は、プログラムのソースコードと組み合わされて、プログラムの基本機能に追加される機能を提供し、１つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに、セグメントのそれぞれのオーバーヘッドスコアが、個別の関数のそれぞれと関連付けられた計装閾値を満たすかどうかに応じて、個別の関数について、プログラムのソースコード内のセグメントを選択的に変更させる命令を含む計装モジュール（１４０）と、を格納するメモリ（１２）と、を備えるオーバーヘッド評価システム。
2. 個別の関数のそれぞれの計装閾値は、少なくとも部分的に、計装ポリシーによって定義された個別の関数を計装するための重要度を少なくとも含む、個別の関数に関連付けられた１つ以上の特性に基づく、請求項１のオーバーヘッド評価システム。
3. 計装モジュールは、計装閾値を満たさない個別の関数の中の不充足関数の計装を変更することによってオーバーヘッドスコアを改善する命令を含む、計装のセグメントを選択的に変更する命令を含む、請求項１のオーバーヘッド評価システム。
4. 不充足関数の計装を変更することは、計装を削除することと、計装を不充足関数のオーバーヘッドスコアを改善する結果となる最適化された計装で置き換えることとの１つを含む、請求項３のオーバーヘッド評価システム。
5. パフォーマンスモジュールは、個別の関数のランタイムカバレッジに対するプログラムカウントと計装カウントとの比率として、個別の関数に関連付けられたそれぞれのセグメントのオーバーヘッドスコアを算出する命令を含む、オーバーヘッドスコアを生成する命令を含み、計装は、プログラムのフローを制御して、プログラムの外部の二次相互作用からフローのリダイレクトを防ぐセキュリティ計装である、請求項１乃至４のいずれか１つのオーバーヘッド評価システム。
6. パフォーマンスモジュールは、プログラムカウントと計装カウントとを生成する命令を含む、プログラムを分析する命令を含み、プログラムカウントは個別の関数に関連付けられたプログラムの命令数を示し、計装カウントは、それぞれのセグメントの計装の命令数を示す、請求項５のオーバーヘッド評価システム。
7. パフォーマンスモジュールは、プログラムが実行されるときに、プログラムの個別の関数のランタイムカバレッジを動的に捕捉する命令を含む、プログラムを分析する命令を含む、請求項５のオーバーヘッド評価システム。
8. パフォーマンスモジュールは、プログラムへのエントリポイントと、限定されたパス深さに従うプログラムの再帰的分析とに従ってランタイムカバレッジを算出することにより、個別の関数のランタイムカバレッジを静的に決定する命令を含む、プログラムを分析する命令を含む、請求項５のオーバーヘッド評価システム。
9. プログラムを選択的に計装する命令を格納するものであって、
   その命令は、１つ以上のプロセッサ（１００）によって実行されるとき、１つ以上のプロセッサに、
   プログラムの個別の関数内の計装のセグメントに関連付けられるオーバーヘッドスコアを生成するようにプログラムを分析させ（２３０）、計装はソースコードと組み合わされて、プログラムの基本機能に追加される機能を提供し、そして
   セグメントのそれぞれのオーバーヘッドスコアが、個別の関数のそれぞれと関連付けられた計装閾値を満たすかどうかに応じて、個別の関数について、プログラムのソースコード内のセグメントを選択的に変更させる（２５０）、非一時的コンピュータ可読媒体。
10. 個別の関数のそれぞれの計装閾値は、少なくとも部分的に、計装ポリシーによって定義された個別の関数を計装するための重要度を少なくとも含む、個別の関数に関連付けられた１つ以上の特性に基づく、請求項９の非一時的コンピュータ可読媒体。
11. 計装を選択的に変更する命令は、計装閾値を満たさない個別の関数の中の不充足関数の計装を削除することによってオーバーヘッドスコアを改善する命令を含む、請求項９又は１０の非一時的コンピュータ可読媒体。
12. 計装は、プログラムのフローを制御して、プログラムの外部の二次相互作用からフローのリダイレクトを防ぐセキュリティ計装である、請求項９乃至１１のいずれか１つの非一時的コンピュータ可読媒体。
13. オーバーヘッドスコアを生成する命令は、個別の関数のランタイムカバレッジに対するプログラムカウントと計装カウントとの比率として、個別の関数に関連付けられたそれぞれのセグメントのオーバーヘッドスコアを算出する命令を含む、請求項９乃至１２のいずれか１つの非一時的コンピュータ可読媒体。
14. プログラムを選択的に計装する方法であって、
    プログラムをソースコードからマシンコードにコンパイルすることに応答して、し、プログラムの別個の関数内の計装のセグメントに関連付けられるオーバーヘッドスコアを生成するようにプログラムを分析すること（２３０）、
    計装は、ソースコードと組み合わされて、プログラムの基本機能に追加される機能を提供し、
    セグメントのそれぞれのオーバーヘッドスコアが、個別の関数のそれぞれと関連付けられた計装閾値を満たすかどうかに応じて、個別の関数について、ソースコード内のセグメントを選択的に変更すること（２５０）、を備える方法。
15. 個別の関数のそれぞれの計装閾値は、少なくとも部分的に、計装ポリシーによって定義された個別の関数を計装するための重要度を少なくとも含む、個別の関数に関連付けられた１つ以上の特性に基づく、請求項１４の方法。
16. 計装のセグメントを選択的に変更することは、計装閾値を満たさない個別の関数の中の不充足関数の計装を変更することによってオーバーヘッドスコアを改善することを含む、請求項１４又は１５の方法。
17. 不充足関数の計装を変更することは、計装を削除することと、計装を不充足関数のオーバーヘッドスコアを改善する結果となる最適化された計装で置き換えることとの１つを含む、請求項１６の方法。
18. オーバーヘッドスコアを生成することは、個別の関数のランタイムカバレッジに対するプログラムカウントと計装カウントとの比率として、個別の関数に関連付けられたそれぞれのセグメントのオーバーヘッドスコアを算出することを含み、
    プログラムを分析することは、プログラムカウントと計装カウントとを生成することを含み、プログラムカウントは個別の関数に関連付けられたプログラムの命令数を示し、計装カウントは、それぞれのセグメントの計装の命令数を示す、請求項１４の方法。
19. プログラムを分析することは、プログラムの個別の関数のランタイムカバレッジを動的に捕捉することを含み、計装は、プログラムのフローを制御して、プログラムの外部の二次相互作用からフローのリダイレクトを防ぐセキュリティ計装である、請求項１８の方法。
20. プログラムを分析することは、プログラムへのエントリポイントと、限定されたパス深さに従うプログラムの再帰的分析とに従ってランタイムカバレッジを算出することにより、個別の関数のランタイムカバレッジを静的に決定することを含む、請求項１８の方法。

Images