JP2019537782A - 垂直統合インストルメント化およびトレース再構成のためのシステム、方法およびデバイス - Google Patents

垂直統合インストルメント化およびトレース再構成のためのシステム、方法およびデバイス Download PDF

Info

Publication number
JP2019537782A
JP2019537782A JP2019520612A JP2019520612A JP2019537782A JP 2019537782 A JP2019537782 A JP 2019537782A JP 2019520612 A JP2019520612 A JP 2019520612A JP 2019520612 A JP2019520612 A JP 2019520612A JP 2019537782 A JP2019537782 A JP 2019537782A
Authority
JP
Japan
Prior art keywords
logged
memory
state
image
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2019520612A
Other languages
English (en)
Other versions
JP2019537782A5 (ja
JP7202293B2 (ja
Inventor
オッドウッド，ダニエル，ディー．
ギンズバーグ，スティーブン，エイチ．
ベレルジェブ，ニコーラ
ディビス，グレゴリー
エディントン，グレッグ
フィールド，ナザン
グリーン，マロリー，エム．
ケリー，フィリップ
ウォルフ，マイケル，ビー．
ザビスカ，トム
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Green Hills Software LLC
Original Assignee
Green Hills Software LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Green Hills Software LLC filed Critical Green Hills Software LLC
Publication of JP2019537782A publication Critical patent/JP2019537782A/ja
Publication of JP2019537782A5 publication Critical patent/JP2019537782A5/ja
Application granted granted Critical
Publication of JP7202293B2 publication Critical patent/JP7202293B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3644—Software debugging by instrumenting at runtime
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3089—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents
    • G06F11/3096—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents wherein the means or processing minimize the use of computing system or of computing system component resources, e.g. non-intrusive monitoring which minimizes the probe effect: sniffing, intercepting, indirectly deriving the monitored data from other directly available data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/323—Visualisation of programs or trace data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3636—Software debugging by tracing the execution of the program
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

実施形態では、システムは、ターゲットプログラムの実行が停止した時点から開始してユーザがソフトウェアをデバッグするためにターゲットプログラムの実行をステップスルーすることを望む時点まで、リアルタイムでまたは実質的にリアルタイムで実行イベントおよびシステム状態を再生および／または再構成するように構成される。実施形態では、システムは、実行の開始から実行が停止した時間までの任意の時点におけるコンピュータシステムの状態を再構成するのに十分であるトレースデータを効率的に収集するように構成されている。ソフトウェアの効率的および効果的なデバッグを、開示された方法、システムおよびデバイスの実施形態を使用して行うことができる。【選択図】 図１８Ｂ

Description

[関連出願への相互参照]
本願は、その全体が参考として援用される２０１６年１０月１１日に出願された米国仮出願第６２／４０６，８２９号の利益を主張する。
開示の実施形態は概して、インストルメント化システムに関し、より詳細には、動的再構成およびデバッグのためのシステム、デバイスおよび方法に関する。
新たな高度技術の開発に伴って、これらの新たな技術革新を実行するために必要なソフトウェアはますます重要かつ複雑になる。ソフトウェアがますます複雑になるにつれて、このようなソフトウェアのデバッグもますます困難になる。例えば、乗用車およびトラックは、車両における様々なシステム構成要素を実行するために複雑なソフトウェアをますます必要とする。概して、典型的な乗用車は今日、何百人もの人々によって書かれた数千万行ものコンピュータコードが必要である。コードの行数が増加して、より多くのプログラマが関与するにつれて、ソフトウェアコード内のバグの数も増加する。また、ソフトウェアバグは、検出および／またはデバッグするのがますます複雑となっている。本明細書で使用される場合、用語「バグ」は概して、コンピュータプログラムにおけるエラーを指す。例えば、コンピュータプログラムにおける一般的なバグとは、コンピュータプログラムがその全機能を完了する前にクラッシュすることである。
概してプログラマは、コンピュータプログラム内のエラー発見を支援するのに役立つソフトウェアデバッガを採用している。しかし、そのようなデバッガは、解析中のコンピュータプログラムの実行から生成されたトレースデータを解析するためにデバッガにとって長い時間期間を典型的には必要とする。本明細書で使用される場合、用語「データトレース」は概して、メモリに保存されたアドレスおよび／もしくは値、ならびに／または、各マシン命令によってアクセスおよび／もしくは修正されるメモリ位置の値とともに、時間期間中にプログラムによって実行されるマシン命令のシーケンスの記録を指す。
この概要の目的として、本開示の特定の態様、利点および新規な特徴が本明細書に記載されている。必ずしもすべてのこのような利点が任意の特定の実施形態によって達成され得るわけではないことを理解すべきである。したがって例えば、当業者は、必ずしも本明細書に教示または示唆され得るような他の利点を達成することなく、本明細書に教示されるような１つの利点または利点のグループを達成する方法で本開示を具現化または実行し得ることを認識するであろう。
いくつかの実施形態では、複数の時点における１つ以上のプログラムの状態を決定するために１つ以上のコンピュータプログラムをインストルメント化する方法は、変更した状態の少なくとも一部をロギングすることにより１つ以上のプログラムの状態で発生する複数の変更を、ロギングされた変更として記録すること、ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることにより変更した状態の前記一部をロギングすること、１つ以上のプログラムのベースライン状態をベースラインイメージとして得て、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、ベースラインイメージに適用し、それによりベースラインイメージよりも前の時間での状態を再構成すること、および、最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とすることを含む。
先行する段落の方法は、１つ以上の以下の特徴を含むことができる。ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されなくともよく、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録することができる。少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避することができる。ベースラインイメージは、１つ以上のプログラムのメモリ状態を含むことができる。ベースラインイメージを取得することは、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得て、それによりデバッグを開始するのに必要な時間をバウンディングすることを含むことができる。少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こすことができ、方法は、１つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用することを含むことができる。ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含むことができる。ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用すると、プログラマはデバッグを実行することができる。デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含むことができる。ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うことができる。ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うことができる。ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うことができる。
いくつかの実施形態では、複数の時点における１つ以上のプログラムの状態の少なくとも一部を決定する方法は、ベースラインイメージとして１つ以上のプログラムのベースライン状態を得て、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、ベースラインイメージに適用し、それにより、ベースラインイメージよりも前の時間での状態を再構成すること、および、最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とすることを含む。１つ以上のプログラムの状態で発生した少なくとも１つの変更は、変更した状態の少なくとも一部をロギングすることによりロギングされた変更として記録されていてもよく、変更した状態の前記一部は、ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることによりロギングされていてもよい。
先行するいずれかの段落の方法は、１つ以上の以下の特徴を含むことができる。ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されなくともよく、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録することができる。少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避することができる。ベースラインイメージは、１つ以上のプログラムのメモリ状態を含むことができる。ベースラインイメージを取得することは、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得て、それによりデバッグを開始するのに必要な時間をバウンディングすることを含むことができる。少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こすことができ、方法は、１つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用することを含むことができる。ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含むことができる。ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用すると、プログラマはデバッグを実行することができる。デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含むことができる。ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うことができる。ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うことができる。ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うことができる。
いくつかの実施形態では、複数の時点における１つ以上のプログラムの状態を決定するために１つ以上のコンピュータプログラムをインストルメント化する方法は、変更した状態の少なくとも一部をロギングすることによって、１つ以上のプログラムの状態で発生する少なくとも１つの変更を、ロギングされた変更として記録するように構成された１つ以上の実行可能命令を挿入すること、および、ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることにより変更した状態の前記一部をロギングするように構成された１つ以上の実行可能命令を挿入することを含む。記録およびロギングにより、デバッガが、１つ以上のプログラムのベースライン状態に対応するベースラインイメージに、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、適用し、それによりベースラインイメージよりも前の時間での状態を再構成することができ、最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とする。
先行するいずれかの段落の方法は、１つ以上の以下の特徴を含むことができる。ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されなくともよく、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録することができる。少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避することができる。ベースラインイメージは、１つ以上のプログラムのメモリ状態を含むことができる。記録およびロギングにより、デバッガがさらに、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得ることによりベースラインイメージを取得することができ、それによりデバッグを開始するのに必要な時間をバウンディングすることができる。少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こすことができ、記録およびロギングにより、デバッガがさらに、１つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用することができる。ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含むことができる。ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用すると、プログラマはデバッグを実行することができる。デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含むことができる。ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うことができる。ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うことができる。ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うことができる。
いくつかの実施形態では、ターゲットシステムの１つ以上の実行ユニット上で実行される１つ以上のコンピュータプログラムのメモリおよびレジスタの少なくとも一部の内容を再構成状態として宛先時点で再構成する方法は、複数の時点における再構成状態を再構成すること、１つ以上のコンピュータプログラムの実行に起因するロギングされたデータに再構成を基づかせることを含む。ロギングされたデータは、１つ以上のコンピュータプログラムによって、または、オペレーティングシステムもしくは１つ以上のコンピュータプログラムの外部の別のエージェントによって、修正前の時間における再構成状態の少なくとも一部を表すプリイメージを含む。ロギングされたデータはまた、宛先時点の前にロギングされた少なくとも１つのレジスタ状態スナップショットを含む。方法はまた、宛先時点における再構成状態の少なくとも一部を決定するために命令セットシミュレータを適用することを含む。
先行するいずれかの段落の方法は、１つ以上の以下の特徴を含むことができる。方法はさらに、複数の時点のうちの少なくとも１つにおける再構成状態の表現を維持することを含むことができる。方法はさらに、再構成状態の再構成中にロギングされたデータからプリイメージをコピーすることによってメモリ修正の直前における再構成状態を再現することを含むことができる。方法はさらに、連続的に以前のメモリ修正記録の直前の時点における再構成状態を再現し、それにより１つ以上のコンピュータプログラムの実行中に連続的に以前のポイントを再現することを含むことができる。方法はさらに、ポストイメージを記憶するためのメモリ空間を予約することを含むことができる。方法はさらに、ポストイメージのために予約された同じメモリ空間にプリイメージを保存することを含むことができる。方法はさらに、ポストイメージを記憶するための予約されたメモリ空間にポストイメージとして表現の少なくとも一部をコピーすることを含むことができる。方法はさらに、ポストイメージをコピーすることによりメモリ修正直後の時点における再構成状態を再構成することを含むことができる。方法はさらに、連続的に以後のメモリ修正直後の時点における再構成状態を再構成し、それにより１つ以上のプログラムの実行中に連続的にますます以後のポイントを再現することを含むことができる。方法はさらに、実行ユニットが１つの時点で動作した再構成状態の少なくとも一部を再現すること、および、後の時点における再構成状態の少なくとも一部を決定するために命令セットシミュレータを適用することを含むことができる。方法はさらに、実行ユニットが前方または後方にメモリを再構成することによって動作した再構成状態の少なくとも一部を再現することを含むことができる。後の時点を宛先時点とすることができる。
先行するいずれかの段落の方法は、１つ以上の以下の特徴を含むことができる。方法はさらに、レジスタ状態が宛先時点において未知である実行ユニットのセットを決定することを含むことができる。方法はさらに、レジスタ状態が宛先時点において未知である各実行ユニットについて、再構成ポイントと宛先時点との間の少なくとも１つのレジスタ状態スナップショットがロギングされているように再構成ポイントを決定することを含むことができる。方法はさらに、再構成ポイントにおける再構成状態の少なくとも一部を再構成することを含むことができる。方法はさらに、宛先時点に戻るためにメモリ再構成技術および再構成シミュレーション技術の組み合わせを使用することを含むことができる。方法はさらに、実行ユニットのセットのうちの実行ユニットについての正確なレジスタ状態情報が利用可能であるとき再構成シミュレーション技術を使用することを含むことができる。方法はさらに、実行ユニットのセットのうちの実行ユニットについての正確なレジスタ状態情報が利用できないときメモリ再構成技術を使用することを含むことができる。
先行するいずれかの段落の方法は、１つ以上の以下の特徴を含むことができる。方法はさらに、再構成状態のサブセットの再構成が可能ではないことを決定することを含むことができる。再構成状態のサブセットの再構成は、ロギングされないメモリ修正についての１つ以上のプリイメージ値のために可能ではないかもしれない。副作用揮発性メモリに保存するとき、メモリ修正についての１つ以上のプリイメージ値がロギングされないかもしれない。メモリの状態のサブセットの再構成は、確かではないロギングされたイベントの正しい順序のために可能ではないかもしれない。ロギングされたイベントの正しい順序は、１つ以上のコンピュータプログラム内の１つ以上の競合条件のために確かではないかもしれない。方法はさらに、１つ以上の競合条件に関する情報を表示することを含むことができる。表示される情報は、１つ以上のメモリ位置にアクセス競合する１つ以上のコンピュータプログラム内の位置を含むことができる。１つ以上のコンピュータプログラム内の位置は、ソースコード位置とすることができる。
先行するいずれかの段落の方法は、１つ以上の以下の特徴を含むことができる。方法はさらに、再構成状態の未知のサブセットを追跡することを含むことができる。方法はさらに、シミュレーションを行う際に再構成状態の異なるサブセットに再構成状態のサブセットの未知性を伝搬することを含むことができる。１つ以上のコンピュータプログラムの命令の結果が既知である場合、未知性を伝播せずともよい。方法はさらに、値が既知になったときに既知であると再構成状態の未知のサブセットをマーキングすることを含むことができる。値は、既知の値を伴うレジスタまたはメモリ位置をロードする命令をシミュレートした結果として既知になることができる。レジスタ状態スナップショットから決定することができる場合に、値は既知になることができる。
いくつかの実施形態において、非一時的コンピュータストレージは、１つ以上のプロセッサによって実行されるときに先行するいずれかの段落の方法を１つ以上のプロセッサに実行させる命令を保存する。いくつかの実施形態において、コンピュータシステムは、先行するいずれかの段落の方法を実装するように構成された少なくとも１つのメモリおよび１つ以上のプロセッサを含む。
他の特徴に進む前に、本明細書に開示された実施形態の態様および利点は、様々な実施形態の図面を参照して以下に詳細に記載され、これらは、例示であって、様々な実施形態を限定しないことが意図されている。図面は以下の図を含む。
図１Ａは、デバッガおよびコンパイラを含む一般的なハードウェアおよびソフトウェアアーキテクチャのブロック図を示す。 図１Ｂは、デバッガおよびコンパイラを含む一般的なハードウェアおよびソフトウェアアーキテクチャの別のブロック図を示す。 図２は、本明細書に開示されたデバッガおよびコンパイラのシステムおよび方法の実施形態を含むハードウェアおよびソフトウェアアーキテクチャのブロック図を示す。 図３は、本明細書に開示されたデバッガおよびコンパイラのシステムおよび方法の例示的な利点を示す棒グラフを示す。 図４は、タスクをコンパイルし、デバッグするための高レベルプロセスの実施形態を示すフローチャートである。 図５は、オペレーティングシステムおよびターゲットタスクと相互作用するコンパイラシステムおよびデバッグシステムの実施形態の高レベルの概要を示すブロック図である。 図６は、タスクの実行中に発生したイベントを再生および／またはシミュレートするように構成されたデバッグシステムの実施形態の高レベルの概要を示すブロック図である。 図７は、タスクをコンパイルし、デバッグする実施形態を示すフローチャートである。 図８Ａは、基本ブロックを含むソフトウェアプログラムの高レベルの概要を示すブロック図である。 図８Ｂは、基本ブロックインストルメント化最適化を示すブロック図である。 図８Ｃは、別の基本ブロックインストルメント化最適化を示すブロック図である。 図８Ｄは、さらに別の基本ブロックインストルメント化最適化を示すブロック図である。 図９は、留保トレースデータ最適化の実施形態を示すフローチャートである。 図１０Ａは、タスクの実行中にトレースデータを生成するためのプロセスの実施形態を示すフローチャートである。 図１０Ｂは、タスクの実行中にトレースデータを生成するためのプロセスの実施形態を示すフローチャートである。 図１１は、関数を含むソフトウェアプログラムの実施形態の高レベルの概要を示すブロック図である。 図１２は、プログラムの実行中にトレースデータを生成するためのプロセスの実施形態を示すフローチャートである。 図１３Ａは、デバッガシステムのグラフィカルユーザインタフェースを示す。 図１３Ｂは、デバッガシステムのグラフィカルユーザインタフェースを示す。 図１４は、本明細書に開示されたコンパイラおよび／またはデバッグのシステムおよび方法を動作させるように構成されたコンピュータシステムの実施形態を示すブロック図である。 図１５Ａは、いくつかの実施形態に係るメモリの再構成を示す。 図１５Ｂは、いくつかの実施形態に係るメモリの再構成を示す。 図１５Ｃは、いくつかの実施形態に係るメモリの再構成を示す。 図１５Ｄは、いくつかの実施形態に係るメモリの再構成を示す。 図１６は、別の実施形態に係るメモリの再構成を示す。 図１７は、実施形態に係るレジスタの再構成を示す。 図１８Ａは、いくつかの実施形態に係るプリイメージロギングを示す。 図１８Ｂは、いくつかの実施形態に係るプリイメージロギングを示す。 図１８Ｃは、いくつかの実施形態に係るプリイメージロギングを示す。 図１８Ｄは、いくつかの実施形態に係るプリイメージロギングを示す。 図１９は、実施形態に係るデバッグ用データの利用可能性を示す。 図２０は、実施形態に係るログデータのマージを示す。 図２１Ａは、いくつかの実施形態に係るログデータの順序付けおよびマージを示す。 図２１Ｂは、いくつかの実施形態に係るログデータの順序付けおよびマージを示す。 図２１Ｃは、いくつかの実施形態に係るログデータの順序付けおよびマージを示す。 図２１Ｄは、いくつかの実施形態に係るログデータの順序付けおよびマージを示す。 図２２は、実施形態に係るマージされたログからの特定のスレッドについてのログデータの利用を示す。 図２３Ａは、実施形態に係る特定のスレッドによって実行される命令のリストの決定を示す。 図２３Ｂは、実施形態に係る特定のスレッドによって実行される命令のリストの決定を示す。 図２４は、実施形態に係る後のメモリ修正記録の適用例を示す。 図２５Ａは、実施形態に係る均一細分化によるタイムスタンプ補間実行を示す。 図２５Ｂは、実施形態に係る不均一細分化によるタイムスタンプ補間実行を示す。 図２６Ａは、実施形態に係る初期チャンク割り当てを示す。 図２６Ｂは、実施形態に係るチャンクアーカイブ化を示す。 図２６Ｃは、実施形態に係るチャンクリサイクル化を示す。 図２６Ｄは、実施形態に係る不良ストア回復を示す。 図２６Ｅは、別の実施形態に係る不良ストア回復を示す。 図２７Ａは、いくつかの実施形態に係るＳＭＰシステムにおける競合条件を示す。 図２７Ｂは、いくつかの実施形態に係るＳＭＰシステムにおける競合条件を示す。 図２７Ｃは、いくつかの実施形態に係るＳＭＰシステムにおける競合条件を示す。 図２７Ｄは、いくつかの実施形態に係るＳＭＰシステムにおける競合条件を示す。 図２８は、実施形態に係るキャッシュ管理のためのコードフロー解析を示す。
いくつかの実施形態、実施例および図が以下に開示されているが、本開示が具体的に開示された実施形態、実施例および図を越えて延長しており、本開示の他の使用および明らかな修正ならびにその均等物を含むことは当業者によって理解されるであろう。開示の実施形態は添付図面を参照して説明され、全体を通して同様の数字は同様の要素を指す。本明細書に提示される説明で使用される用語は、それがある特定の実施形態の詳細な説明と併せて使用されているという理由だけで任意の限定または制限された方法で解釈されるものではないことが意図される。また、実施形態はいくつかの新規な特徴を含むことができ、単一の特徴が、その望ましい属性に単独で責任がある、または本明細書に記載の開示を実践するために不可欠であるというわけではない。
《概要》
コンピュータプログラマは、コンピュータプログラムのエラーすなわち「バグ」を発見するためにソフトウェアデバッガを使用する。エラーには発見が困難なものがあり、それらが発生した原因となる状況の後、長く経ってからそれらが現れるからである。例えば、数百万または数十億の命令が最初の計算の後に実行されるまで、不正な計算の結果は使用されないかもしれない。
他のバグとして、それらの再現に長い時間がかかるか、または、バグを引き起こす条件が不確定である、もしくは他の未知の要因に依存しているときに、発見が困難なものがある。例えば、乗用車エンジンまたはスマートフォンのジャイロセンサからの特定のセンサ読取値が値の特定のシーケンスを有する場合にのみ、これらのセンサ読取値などの変化する外部入力に依存するプログラムがエラーを示し得る。このような場合には、バグがデバッガで観察され得るようにそれを出現させるためのプログラムへの非現実的なほど大量の入力を発生または試行するために、値の特定のシーケンスについてプログラマは長い時間を待つ必要があり得る。
他のバグには、発見後であっても修正が困難なものがあるが、それは、それらが発生するソースコードの複雑さおよび巨大さのためである。プログラマは、プログラムの実行中にどこか他の箇所でエラーを発生させることなくバグを修正することができる前に、プログラムのソースコードの大部分を理解する必要があり得る。乗用車、スマートフォン、飛行機等などの埋込型コンピューティングシステムに依存している現代のデバイスは、数十人または数百人のエンジニアのチームによって書かれた数千万行のソースコードを実行する。これらのエンジニアリングチームでは誰も全体のソースコードベースを理解していないので、大規模なソースコードのバグフィックスは、困難であり、遅くなり、エラーが発生しやすくなる可能性がある。
スマートフォン、タブレット、ラップトップ、制御システム、車両制御システム等などの複雑な現代のデバイスでしばしば見られるように、数百万または数十億の実行される命令および／またはコード行が存在する場合、再現するのに長い時間がかかるバグが存在する場合、またはソフトウェアが非常に複雑であるために修正が困難なバグがある場合、人間の心の中で、または紙と鉛筆とを使って、合理的時間内で人間がこのようなソフトウェアコードをデバッグすることはできない。さらに、ソフトウェアデバッグの問題はコンピュータの分野でのみ発生し、本明細書に開示されたソリューションは、我々が依存する我々の新たな高度技術を動作させるのにますます必要である複雑なソフトウェアの使用および開発に特有の問題への技術的なソリューションである。新たな高度技術がより進展するにつれ、このような高度技術を動作させるソフトウェアは複雑で大規模なものとなり、それによって、このようなソフトウェアのデバッグが困難になり、独自の技術的なソリューションが必要となる。
デバッグソリューションには、ハードウェア、ファームウェアおよびソフトウェア開発者がバグおよび／またはエラーを発見およびフィックスするだけでなくそれらのコードを最適化および／またはテストすることができるようにする様々な解析ツールを提供するものがある。これらの解析ツールの１つのクラスは、１つ以上のプロセッサ上で命令を実行しつつ生成されたログデータを調べる。プロセッサ自体（例えばプロセッサトレース）により、オペレーティングシステムにより、ソフトウェア開発者によって追加されたインストルメント化ログポイントにより、および／または、コンパイラまたはＪＩＴ（ジャストインタイム）コンパイラによって追加されたインストルメント化により、ログデータを生成することができる。ロジックアナライザなどの他のデータのソース、他のシステムのコレクション、および、検証スクリプトまたは他のソースからのログは、システムの外部にあり得る。これらの異なるソースによって生成されたデータを「トレースデータ」と称し得る。トレースデータの単一要素を「イベント」と称し得る。
「時間走行デバッガ」と称され得るデバッガシステムには、プログラマが自身のプログラムの実行において前方および後方に移動可能とするものがある。時間走行デバッガは、バグの症状からバグの根本原因へとすべて遡ってプログラムをデバッグするために、または、プログラマがプログラムの一般的構造を理解して、プログラムがどのように編成されるのか、および、いつどこでプログラムの様々な関数が発生して実行されるのかを知ることができるようにするために、使用され得る。
時間走行デバッガは、２つの構成要素：データの生成、収集、および（いくつかの実施形態では）解釈を担う時間走行デバッガバックエンド、ならびに、ユーザへのデータ提示を担う時間走行デバッガユーザインタフェース、を含むことができる。
（「ハードウェアトレースバックエンド」と称され得る）時間走行デバッガバックエンドには、ハードウェアトレースの形態を含むものがある。ハードウェアトレースは、命令がＣＰＵによって実行されたものを正確にプログラマが再構成することを可能にする、ＣＰＵによって放出された情報の高度圧縮ストリームである。ハードウェアトレースは、いくつかの制限を有する。例えば、ハードウェアトレースはすべてのＣＰＵアーキテクチャで利用可能というわけではなく、したがって一部のＣＰＵ上で使用可能であるにすぎない。ハードウェアトレースを有するＣＰＵであっても、メーカーは、ＣＰＵのチップパッケージサイズを縮小して生産コストを節約するために、ハードウェアトレースを放出するトレース出力ポートを備えるピンをインストールしないよう選択することがある。また、ハードウェアトレースは、トレースプローブなどの外部トレース収集ハードウェアを必要とし得、これは高価であり得、トレースデータを記録するためにメモリに制限があり得、いくつかのシステムにとってインストールするには物理的に困難であり得る。例えば、スマートフォンは小型でポータブルにする必要があり、そのトレース出力ポートに取り付けられた大規模で重いトレースプローブを使用するのは困難であろう。
また、ハードウェアトレースは信頼できない可能性があり、トレース出力ポートがＣＰＵの命令実行に追いつくことができないときに情報の欠落がある可能性がある。ＣＰＵを減速またはストールさせるよりもむしろ、ほとんどのメーカーは、ＣＰＵがトレース出力ポートをオーバーロードさせ得る場合にはトレースデータを放出しないことを選択している。メモリアクセスのハードウェアトレースは、トレース出力のオーバーロードに対して特に敏感であり、これはメモリアクセスが予測できず、したがって出力するには容易に圧縮され得ないからである。トレースデータにおけるメモリアクセスの省略は、時間走行デバッガの機能を厳しく阻害する。また、ハードウェアトレースは、オペレーティングシステムをよくトレースすることはできない。このようなデバッグシステムは、オペレーティングシステム内のタスクが作成または破棄されたときを伝えることができ得るが、リソースの割り当て、アドレス空間の作成、および様々な同期プリミティブの使用などのすべての他のＯＳの動作に盲目である。しかし、これらのＯＳの活動のすべてを知ることは、バグの根本原因を発見するのに重要である可能性があり、それは特に、現代のデバイスが多くの場合、すべてが互いに相互作用する数十〜数百もの同時実行中タスクを伴うオペレーティングシステムを使用するからである。
また、ハードウェアトレースは十分に対称型マルチプロセシング（ＳＭＰ）システムを追跡することができない。ハードウェアトレースはしばしば、２つ超のコアについてのトレースデータ放出についての帯域幅制限のためにＳＭＰシステムにおける２つ超のコアをトレースすることができない。このようなデバッグシステムは、限られた使用となる可能性があり、これはスマートフォンおよびタブレットなどの多くの現代のコンピューティングデバイスが一般に、ＳＭＰ実行についての４つ超のコアを有しているからである。さらに、ハードウェアトレースは、複数の異なるタイプのＣＰＵおよびシステムが互いに対して非同期的に実行される非対称マルチプロセシングシステムを追跡する方法をほとんど有していない。これは、このようなデバッグシステムを大きく制限する可能性があり、それは例えば、現代の乗用車が互いに非同期で動作する百超の独立したＣＰＵを有するからである。さらに、ハードウェアトレースは、時間走行デバッガにおいて使用するのに適した形式にデコードすることが非常に遅いので、プログラマは、プログラムをデバッグするためにトレースデータを使用する前に長時間、待つ必要があり得る。市販の製品についての典型的なデコード速度は、毎秒１メガバイト未満から２ＭＢ／秒の範囲である。トレースプローブは典型的には、１ＧＢのメモリを搭載しており、完全にトレースプローブのトレースデータをデコードするには２０分超かかり得る。また、ハードウェアトレースデコードは、収集されたトレースデータの先頭から行われるので、トレースデータがより多く収集されるほど、トレースデータのデコードがより長くかかる。今日では最大１６ＧＢのトレースメモリを伴って販売されているトレースプローブを用いれば、プログラマがプログラムをデバッグするためにトレースデータを使用することができるまで、完全な１６ＧＢのトレースバッファをデコードするのに、ほぼ６時間かかる可能性がある。ハードウェアトレースデコード時間は、トレースバッファのサイズとともに増大する。
本明細書に開示された実施形態は、デバッグシステムに伴う、および／またはトレースのためのソフトウェアベースアプローチに伴う、上記問題を解決しようとする。実施形態では、本明細書に開示されたシステムは、コンパイラを使用して付加的命令を用いてプログラムをインストルメント化する。実施形態では、オペレーティングシステムを、デバッグシステムに伴う上記課題を解決するためにオペレーティングシステム上で実行されているインストルメント化ターゲットプログラムとともに作業および／または協働するように構成することができる。
ソフトウェアインストルメント化の特定の形態を含む時間走行デバッガバックエンド（「コピーバックエンド」とも称され得る）は、ターゲットプログラムを大幅に遅くする可能性がある一方、本明細書に開示された実施形態は、これらの速度ペナルティを低減する特徴を含む。コピーバックエンドは、チェックポイントとして実行プログラムのメモリの大部分のコピー（または「フォーク」）を介してターゲット全体の動作状態を保存する負担の大きい方法を必要とする一方、本明細書に開示された実施形態は、このような状態のバルクコピーを必要としない。さらに、コピーバックエンドはまた、すべてのプロセスをトレースするために、１つのＣＰＵにそれらを捕らえる必要がある。しかしバグには、同時実行で発生するタイミング依存性のために、異なるＣＰＵ上でプロセスが実行される場合にのみ発生するものがある。実施形態において、本明細書に開示されるシステムは、前述の制限に対処する。
実施形態では、システムは、改善された時間走行デバッガバックエンド（「改善バックエンド」と称され得る）を実装するのに必要なトレース情報を生成するために、ターゲットプログラムおよびオペレーティングシステムにおいてインストルメント化を使用する。インストルメント化によって生成されたトレース情報を、デバッガによってそれが検索されて解釈されることができるまで、コンピュータプログラムを実行するＣＰＵのメモリにおいてロギングすることができる。このロギングされたトレース情報は、「トレースログ」と呼ばれる。実施形態において、改善バックエンドは、最新から最古までトレース情報を検索して解釈する。トレース情報は逆時系列順に解釈されるように構成および／または設計されることができ、それにより、ユーザは、以前の部分が検索および／またはデコードされるのを待たずに、プログラムの最も近い時点での実行履歴のデバッグを開始し得る。
実施形態では、改善バックエンドは、コンパイルツール（コンパイラ、アセンブラ、リンカ等）により自動的に挿入されたターゲットプログラムにおけるインストルメント化を含むことができる。ターゲットプログラムにおけるこのようなインストルメント化は、２つの主な目的を果たすことができる。
第１に、このようなインストルメント化は、ターゲットプログラムの実行パス、例えば、どの命令が実行され、および／または、どのような順序で実行されるか、を記録するように構成されることができる。このようなインストルメント化は、実行される各基本ブロックのログエントリを作成することによってこれを行うように構成されることができる。基本ブロックは、外部割り込みが存在しない状態で単一エントリポイントおよび単一イグジットポイントを有するプログラムにおける命令のシーケンスとして定義され得、ブロック内の各命令は、正確に一度だけ実行される。ＣＰＵアーキテクチャの機能に応じて、基本ブロックの定義は、例えば、条件付命令（特定の条件下では影響を及ぼさないので、実行されていないと考えられ得る）を考慮するよう、または例えばメモリコピーを実行するために複数回実行する命令を繰り返すよう修正され得、適宜、他の修正もなされ得る。
第２に、ターゲットプログラムにおけるこのようなインストルメント化は、ターゲットプログラムのメモリへの変更を追跡および／または監視するように構成されることができる。メモリが上書きされると、改善バックエンドは、修正アドレスおよび／または修正前のメモリの値（「プリイメージ」）をロギングするように構成されることができる。実施形態では、プリイメージは、以下のように再構成が逆時系列順で発生することができるようロギングされる。ターゲット上のメモリの現在状態のイメージで始まると、デバッガ改善バックエンドは、過去の任意の時点でのメモリの状態を最も近い時点から始まってより以前へ以前へと進むよう再現するために逆時系列順にプリイメージを適用することができる。実施形態において、ターゲットメモリイメージに適用される各プリイメージは、プログラム実行中に実行されたメモリ修正のうちの１つの取り消しをシミュレートする。この逆再構成を行いながら、デバッガシステムがプリイメージでターゲットメモリイメージの一部を上書きするたびに、デバッガシステムが上書きしようとするメモリの内容を、「ポストイメージ」としてログに保存し得る。ポストイメージを保存すると、デバッガ改善バックエンドは、ターゲットメモリイメージにポストイメージを適用して時間的に前方に対応メモリ修正をシミュレートするように構成されることができる。したがって、プログラムの最終状態から開始して、改善バックエンドは、時間的に後方に、そして必要に応じて再び前方に、ターゲットプログラムのメモリ状態を自由に再構成するように構成されることができる。
実施形態では、プリイメージのロギングが可能でない場合、例えば修正中のメモリがハードウェアペリフェラル上のメモリマップされたレジスタであって、読み出し時に望ましくない副作用を有する可能性がある場合、プリイメージロギング技術は調整される。
実施形態では、ロギング値を他のロギングデータから推測することができる場合には、コンパイルツールは、インストルメント化を低減または排除するための様々な技術を使用する。これらの最適化は、ロギングオーバーヘッドを削減し、所与量のログに保存することができる実行履歴の量を増加させる。
実施形態では、改善バックエンドは、アプリケーション外部から発信されるターゲットプログラムの実行パスおよびメモリへの変更をロギングするように構成されたオペレーティングシステムにおけるインストルメント化を含むことができる。ターゲットプログラムの実行パスおよびメモリへの変更の例として、割り込み、コンテキストスイッチ、オペレーティングシステムコールによって引き起こされるメモリ修正、ならびにペリフェラルからのプログラムおよび他のプログラムの外部から到来する通信を挙げることができるがこれらに限定されない。ターゲットプログラムの内部インストルメント化によってロギングされるメモリ修正を伴うので、改善バックエンドでは、オペレーティングシステムを、後方再構成の目的のためにプリイメージとしてメモリ修正をロギングするように構成することができる。
本明細書に開示されたシステムのオペレーティングシステムは、ターゲットプログラムにおける実行のすべてのスレッド内のＣＰＵレジスタの状態を定期的にロギングするように構成されることができる。実施形態では、前述のデータは、プログラム内のレジスタの状態を再構成するために使用される。メモリが本明細書に記載された技術を用いて所望の時点で再構成された後、デバッガは、シミュレータを使用して所望の時点の前に記録された最も近いレジスタ状態スナップショットから前方にシミュレートし、所望の時点でのＣＰＵレジスタの状態を再構成することができる。
実施形態では、本明細書に記載のインストルメント化および／または技術は、本明細書に記載のようにハードウェアトレースバックエンドおよびコピーバックエンドに通常は関連する様々な制限を負わない、改善された時間走行デバッガバックエンドを実装するのに十分である。
任意選択的に、改善バックエンドを、様々な目的のための追加情報を収集するように構成することができる。例えば、デバッグ中のターゲットプログラムが、例えば対称または非対称マルチプロセシング構成において同時に実行されている複数の実行スレッドを有する場合、改善バックエンドは、任意選択的にタイムスタンプとともに、ＣＰＵ間の同期イベントおよび他の通信をロギングするように構成されることができる。十分な情報がロギングされて論理的に一貫した順序、例えば特定の重要イベントについてのタイムスタンプで異なる実行ユニットからのデータをマージできると仮定すると、改善バックエンドは、時間走行デバッガを複数の実行ユニットを含むシステム上で動作させることができる。このようなデータの収集も、ハザード、競合条件および／または他の潜在的プログラミングエラーの自動検出を、たとえこれらのエラーにより解析中のターゲットプログラム実行の一部において不正挙動とならなかったとしても、改善バックエンドに実行させることができる。
実施形態では、改善バックエンドは、経時的にプログラムのコールスタックにおける変化を表示するために使用することができる関数エントリおよびイグジット（ＦＥＥ）データを収集するように適合されるインストルメント化を含むように構成されることができる。ＦＥＥデータは、パフォーマンス解析および最適化について、ならびに、デバッグについて、データを価値あるものにするタイムスタンプ情報を含むことができる。
本明細書に開示された実施形態は、本明細書に記載のハードウェアトレースバックエンドを用いて制限を克服し得る。本明細書で説明するように、ハードウェアトレースは、すべてのアーキテクチャで利用可能ではない。対照的に、本明細書に開示された実施形態は、ハードウェアトレース能力に依存しないため、実質上すべてのアーキテクチャ上で動作する。さらに、本明細書の実施形態は、外部トレース収集ハードウェアなしで動作することができる。したがって、実施形態は、高コスト、大サイズ、およびトレースプローブの限られたメモリ容量に服従することはないであろう。実施形態は、インストルメント化を使用することができ、これは、トレース出力ポートがプログラム実行に追いつくことができないときにハードウェアトレースで発生する可能性があるようなデータ喪失がないようにプログラム実行を遅くする。
また、実施形態はオペレーティングシステムをインストルメント化することができ、それにより、実施形態は、ハードウェアトレースが認識していないオペレーティングシステムイベントを記録することが可能である。これらのオペレーティングシステムイベントは、バグの根本原因を発見するのに重要である可能性がある。実施形態では、システムは、ＣＰＵ間の同期プリミティブおよび通信を認識するように構成され、ＳＭＰ環境および複数の実行ユニットを伴う他の構成で実行されるプログラムのデバッグが可能となる。また、異なるＣＰＵからデータを論理的に一貫した順序でマージするのに十分な情報をロギングすることにより、実施形態は、非対称マルチプロセシングシステムおよび他の分散システムで動作する能力を有することができる。実施形態において、本明細書で開示される実施形態でのプリイメージロギングの使用により、トレースデータが時間走行デバッガユーザインタフェースにおける使用に既に適した形態になるようにすることができ、よって、すべてのトレースデータがダウンロードおよびデコードされるのを待つことなく、ターゲットからダウンロードされるとすぐにトレースデータを用いてプログラマがデバッグを開始し得る。
さらに、改善バックエンドは、すべてのトレースデータがダウンロードされる前に、プログラマがデバッグを開始できるように構成されることができる。ユーザが待たなければならない時間は、トレースメモリバッファのサイズの関数ではなく、はるかに大きなトレースバッファの実用的使用を可能にする。実施形態では、改善バックエンドは、アドレス空間をコピーすること、またはそれらをトレースするために１つのＣＰＵにすべてのプロセスを捕らえることに依存しないという点で有利である可能性がある。そのため、実施形態は、このようなデータのバルクコピーに固有のパフォーマンスペナルティに悩まされず、プログラマが同時実行中にのみ発生するバグを発見するのに役立つことができる。
開示されたシステム、方法およびデバイスは、コンピューティングの分野で生じる特定の技術的問題を解決し、コンピュータシステムの動作を改善する。デバッグの分野における特定の具体的な改善が開示されている。開示されたシステム、方法およびデバイスは、少なくとも、コンピュータコードデバッグ技術における大幅な改善を提供し、これはとりわけ、伝統的デバッグ技術と比較してそれらがより効率的なインストルメント化、ロギングおよび／または再構成を介してデバッグの速度および正確性を向上させるからである。開示されたシステム、方法およびデバイスは、単一の処理コアまたは複数の処理コアを有するコンピューティングシステム上で実行されるソフトウェアをデバッグするために使用されることができる。複数のコア上で実行されるソフトウェアをデバッグすることは、とりわけ複数コア上での実行スレッド追跡の複雑さのために、特に挑戦的な課題である可能性がある。開示された技術は、とりわけオペレーティングシステムイベントを追跡して一貫した順序で異なるコンピューティングコアからデータをマージすることにより、複数の処理コア上で実行されるコンピュータコードをデバッグすることに関連したこれらおよび他の問題をシームレスに解決する。
プログラマによる手動操作および介入に依存するにもかかわらず遅くてエラーが発生しやすく、多くのタイプのバグを検出およびフィックスするのに不十分である従来のシステムとは異なり、開示された技術は、競合条件バグ、メモリ破損バグおよび他の再現困難なバグを含む多数のソフトウェアバグを自動的に検出してそのデバッグを容易にすることができる。それらの効率のため、開示されたシステム、方法およびデバイスは、コンピュータプログラムの実行へと追加されるオーバーヘッドをより少なくし得、言い換えれば、従来のシステムよりも使用するのにより少ない侵入性および／または煩雑性となり得る。開示されたシステム、方法およびデバイスは、シングルまたはマルチコアコンピューティングシステム上で実行される最も複雑なコンピュータコードであっても高速自動デバッグを可能にし、従来技術よりも効率的かつ正確なデバッグを提供する。これにより、コンピュータプログラムデバッグ技術を含むコンピュータ関連技術における大幅な改善だけでなく、本明細書に開示された特定の技術を使用してデバッグされたエラーフリーコンピュータプログラムを実行するこのようなシステムを介して達成されるコンピューティングシステムの動作改善が得られる。
「コンピュータシステム」は、ＲＡＭ、ＲＯＭ、内蔵ＳＲＡＭ、オンチップＲＡＭ、オンチップフラッシュ、ＣＤ−ＲＯＭ、ハードディスクおよび同様のものを含むがこれらに限定されない、処理ユニットとデータおよび命令を交換するための１つ以上のデータ記憶デバイスと結合されたデータおよび命令の処理のための１つ以上の処理デバイス（中央処理装置ＣＰＵなどの）を含み得る。コンピュータシステムの例は、エンジンコントローラからラップトップまたはデスクトップコンピュータ、スーパーコンピュータまでに至るすべてのものを含むことができる。データ記憶デバイスは、専用で、例えば処理ユニットに直接に結合され、または遠隔で、例えばコンピュータネットワークを介して処理ユニットに結合されることができる。コンピュータネットワークを介して処理ユニットに結合されたリモートデータ記憶デバイスが実行のために処理ユニットにプログラム命令を送信することができることを理解すべきである。また、処理デバイスを、１つ以上の追加の処理デバイスに、同じ物理的構造を介して（例えば並列プロセッサ）、またはコンピュータネットワークを介して（例えば分散プロセッサ）のいずれかで結合することができる。このような遠隔結合されたデータ記憶デバイスおよびプロセッサの使用は、コンピュータサイエンス分野の当業者によく知られているであろう。「コンピュータネットワーク」との用語は、互いに通信可能なコンピュータシステムのセットを相互接続する通信チャネルのセットを含み得る。通信チャネルは、ツイストペア線、同軸ケーブル、光ファイバ、衛星リンク、またはデジタルマイクロ波無線などの伝送媒体を含むことができるが、これらに限定されない。コンピュータシステムは、ラージまたは「ワイド」エリア（例えば、数十、数百、あるいは数千マイルにわたる、ＷＡＮ）、またはローカルエリアネットワーク（例えば、数フィート〜数百フィートにわたる、ＬＡＮ）を介して分散することができる。さらに、様々なローカルエリアおよびワイドエリアネットワークを、コンピュータシステムの集合体ネットワークを形成するために組み合わせることができる。コンピュータネットワークのこのような連合の一例は、「インターネット」である。
「ターゲット」との用語は、「コンピュータシステム」と同義であり得る。ターゲットとの用語を、トレースイベントを生成するコンピュータシステムがトレースイベントを解析するために使用されるコンピュータシステムとは異なり得ることを示すために使用することができる。なお、同じコンピュータシステムがトレースイベントの生成および解析の両方を行うことができる。
「スレッド」との用語は、命令の実行の任意のユニットを指すために使用され得る。スレッドは通常、主にそれ自身の使用のためである（レジスタなどの）状態を記憶する方法を有することができる。それは（そのアドレス空間内のＲＡＭなどの）他のスレッドと追加の状態記憶空間を共有してもしなくてもよい。例えば、これはオペレーティングシステムで実行される際にプロセス内で実行中のスレッドを参照し得る。これはまた、オペレーティングシステムなしでプロセッサ上で命令を実行することを含むことができる。その場合には、「スレッド」は、命令を実行するプロセッサであり、いかなるコンテキストスイッチも存在しなくともよい。異なるオペレーティングシステムおよび環境は、スレッドとの用語でカバーされる概念を指すために異なる用語を使用し得る。同じ基本原理の他の一般的な用語は、限定されないが、ハードウェアスレッド、軽量プロセス、ユーザスレッド、グリーンスレッド、カーネルスレッド、タスク、プロセスおよびファイバを含む。
《インストルメント化》
時間走行デバッガについての改善バックエンドは、コンピュータプログラムの実行に関するデータを収集するためのインストルメント化を含み得る。インストルメント化は、プログラムの動作に直接は寄与しないコンピュータプログラムに追加される命令を含むことができる。インストルメント化は、例えば、コンパイラ、ＪＩＴ（ジャストインタイム）コンパイラ、アセンブラ、リンカ、もしくはソースコードから実行可能コードにプログラムを変換するプロセスにて使用される他のツールによって、または、完全コンパイル化実行可能ファイルのポストプロセシングによって、自動的にプログラムに挿入されることができる。インストルメント化は、プログラマが明示的または黙示的にプログラムにインポートした命令のライブラリ、ヘッダファイル、または他のボディに埋め込まれることができる。インストルメント化は、プログラマによって手動でコンピュータプログラムに書き込まれることができる。コンパイラは、プログラマがプログラムソースコードに挿入してコンパイラに適切なインストルメント化命令を生成させることができる利用可能な特別コンパイラキーワードまたはイントリンシックを作成することによりプログラムを手動でインストルメント化できるようプログラマを支援するように構成することができる。インストルメント化は、コンピュータプログラムを実行するオペレーティングシステムまたはハイパーバイザに埋め込まれことができる。インストルメント化は、コンピュータプログラムが実行されるハードウェアまたはシミュレータに、またはコンピュータシステムの動作を監視する補助ハードウェアに埋め込まれることができる。
インストルメント化を、ほとんどすべての種類の情報をロギングするために使用することができる。改善バックエンドは、プログラムの実行パスに関する情報、およびプログラム内のメモリに記憶されたデータへの変更に関する情報、ならびに、プログラマに直接的または間接的に有用であることを証明し得る他の情報をロギングするように構成されたインストルメント化を含むことができる。
《インストルメント化の最適化および除去》
コンピュータプログラムに挿入されたインストルメント化は、ランタイムパフォーマンスおよび／またはそのコンピュータプログラムのメモリフットプリントに悪影響を与える可能性がある。インストルメント化はプログラムデバッグのためにおよび他の目的のために非常に有用である可能性があるが、いくつかまたはすべてのインストルメント化を除去したコンピュータプログラムの実行可能ファイルを構築することが有益であり得る状況もある。
実施形態では、改善バックエンドによってコンピュータプログラムに挿入されたいくつかのインストルメント化は、他のロギングされたデータから、または他の情報のソースから推測することができ、したがって、プログラム実行時に生成する必要がないデータを生成する。このような場合には、改善バックエンドは、そのようなインストルメント化を解消または簡素化して、データがターゲットシステムから収集された後のように後に推測データを挿入することができる。このような推測データは、「合成データ」、つまり、ランタイム時にインストルメント化によって記録されている可能性があるが、代わりに事実の後に生成されるデータの一例である。生成データの代わりに合成データを使用するプロセスは、インストルメント化、ランタイムパフォーマンスへの影響、およびバックエンドの機能実行のためのログ空間のうちの１つ以上を低減する方法を指すことができる「インストルメント化最適化」の一例である。インストルメント化最適化および合成データのいくつかの例は、本開示全体を通して現れる。
実施形態では、改善バックエンドは、そもそもインストルメント化を生成せずに、手動で（例えば、プログラマによって）挿入される任意のインストルメント化を除去または無視するよう、コンパイラ、アセンブラ、および他の開発ツールを構成することにより、インストルメント化の生成を無効にしてインストルメント化することなく実行可能ファイルを構築できるようにすることができる。
実施形態では、改善バックエンドは、インストルメント化を除去するように、リンカ、またはインストルメント化が挿入された後に呼び出されるソフトウェア開発ツールの別のコンポーネントを構成することによって、インストルメント化することなく、インストルメント化をストリッピングして実行可能ファイルを構築することができる。インストルメント化のストリッピングは、インストルメント化生成を無効にすることに比べていくつかの利点がある。インストルメント化を伴う実行可能ファイルが生成されると、実行可能ファイルは最初から再構成される必要はなく、代わりに、ソフトウェア開発ツールを、すでに構築された実行可能ファイルおよび／またはオブジェクトファイルからインストルメント化をストリッピングするように構成することができる。これは、非インストルメント化実行可能ファイルを作成するのに必要な時間を非常に短縮することができる。非インストルメント化実行可能ファイルは単にインストルメント化が除去されたインストルメント化実行可能ファイルであるため、インストルメント化および非インストルメント化のバージョンが異なる挙動を有するリスクが大幅に軽減される一方、実行可能ファイルが最初から再構成される必要がある場合にそのような保証を行うことのほうがはるかに困難である。プログラムの非インストルメント化バージョンがユーザに配備されるバージョンである可能性が高く、プログラムのインストルメント化バージョンは開発中にほとんどの精査を受ける可能性があるので、バージョン間で整合性のある挙動を保つことは、インストルメント化を伴わない再構築のプロセスを通じた開発および配備の間にソフトウェアにバグが入る可能性を低減する。インストルメント化をストリッピングすることはまた、事前構築されたライブラリのプロバイダがインストルメント化を含むライブラリの単一のセットを分配することを可能とする。事前構築されたライブラリを使用するプログラマは、必要に応じてインストルメント化をストリッピングしてもしなくともよい。
実施形態では、手動または自動でソフトウェアに挿入されたインストルメント化は、予約レジスタ、例えば、書き込まれるログ内の次の場所をポイントする予約レジスタ、またはロギング処理中に一時的な値を保持するために予約されたレジスタにアクセスする命令からなることができる。このような場合は、インストルメント化をストリッピングすることは、迅速かつ計算が簡単なプロセスとなることができ、予約レジスタを参照する命令の検出および除去のみに関与する。インストルメント化として挿入された命令のみが予約レジスタを使用し得、したがって、インストルメント化として挿入された、したがってコンピュータプログラムの動作に関与しない命令のみが除去される点において、インストルメント化を除去するプロセスの正しさを証明することも容易である。
実施形態では、インストルメント化ストリッピングは、再配置可能オブジェクトファイルおよびライブラリを単一の実行可能イメージに結合するプロセスの前に、またはその間に発生することができ、このプロセスを「リンク」と称することができる。リンクプロセスは、最終実行可能ファイルにおいてその適切なターゲットにポイントするための再配置可能オブジェクトファイルおよびライブラリにおける、分岐、他の命令、およびポインタの修正を伴うことができ、このプロセスを「再配置」と呼ぶことができる。再配置プロセスは、命令の追加もしくは除去またはオブジェクトファイルおよびライブラリ内のマシン命令のサイズもしくは位置を変更する他のアクションに敏感であることができる。リンクプロセス中またはその前にインストルメント化ストリッピングを行うことにより、インストルメント化命令の除去に起因するコードサイズ変更によって再配置は崩壊しない。
インストルメント化ストリッピングで行うことができるように、再配置可能オブジェクトファイルからの命令の除去は、ローカル分岐命令における、同じ再配置可能オブジェクトまたはライブラリ内の場所を参照する他の命令における、および、（「再配置テーブル」と呼ぶことができる）再配置プロセス中の変更を必要とし得る命令およびポインタの位置をリスト化するテーブルにおける、変更を必要とする可能性がある。インストルメント化ストリッピングのプロセスはしたがって、インストルメント化命令の除去に加えておよびそれとともに、このような変更を行う必要がある可能性がある。
実施形態では、プログラムに挿入される一部またはすべてのインストルメント化を、ランタイム時に無効にするように構成することができる。このような場合には、インストルメント化には、時にガード命令と称される、１つ以上の追加の命令が先行することができる。実施形態では、ガード命令は、デフォルトでは無効とすることができるが、デバッガにより、オペレーティングシステムにより、または他の手段により、別の命令（複数可）、例えば何もロギングされないよう命令に残りのインストルメント化をスキップさせる分岐命令へとランタイム時に変更されることができる。実施形態において、上記プロセスは、ガード命令（複数可）への修正を逆転させることによって、インストルメント化の効果を復活させるよう逆転され得る。代替実施形態では、ガード命令は、ガード命令のデフォルト状態がインストルメント化をスキップするという点以外、本明細書に記載されるように動作することができる。
実施形態では、実行可能バイナリイメージを生成するために使用されるコンパイラおよび／または他のツールは、ガード命令を含むコンパイルされたプログラム内の位置のテーブルを生成することができる。このようなテーブルは、デバッガによって、オペレーティングシステムによって、またはランタイム時にインストルメント化を有効および／または無効にするプロセスを案内する他の構成要素によって使用されることができる。
本明細書に記載されるようにガード命令を用いてランタイム時にインストルメント化を無効にすることは、いくつかの実施形態において有利である可能性があり、それは、ユーザがアプリケーションプログラムを再コンパイル、再リンクまたは再始動すらせずに、ロギングをオンおよび／またはオフすることができるからである。ユーザはまた、どのインストルメント化を有効／無効にするかについて、例えば１つの関数についてのみインストルメント化を有効にすること、または例えばインストルメント化の一種のみを有効にすることにおいて選択的であり得る。別の例として、ユーザは、特定の他の条件が埋め込まれた場合、例えば、デバッガ、オペレーティングシステム、またはアプリケーション自体が内部不整合を検出する場合にのみロギングを有効にすることができる。インストルメント化の無効は典型的には、実行をより迅速にし、有効インストルメント化に比べてより少ないログ空間を消費し、それにより、ランタイム時のインストルメント化の無効はアプリケーションパフォーマンスおよびログ使用量に対するより大きな制御をユーザに与えることができるものの、生成トレースデータの質および種類のトレードオフとなる。
《インストルメント化のコンパイラ駆動最適化》
改善バックエンドは、プログラマの手作業による挿入、ライブラリもしくまたはオペレーティングシステムにおける埋め込み、またはソースコードから実行可能ファイルにプログラムを変換するプロセス中の自動的挿入を含む、多くのソースからのインストルメント化を含むことができる。上記の場合のそれぞれにおいて改善バックエンドで、コンパイラは、実行可能コードにおけるインストルメント化のフットプリント低減、メモリ内のインストルメント化のフットプリント低減、および／またはインストルメント化のランタイムパフォーマンス影響低減、および／またはインストルメント化に必要なログ空間量低減のために、インストルメント化を最適化するように構成されることができる。
実施形態において改善バックエンドで、コンパイラは、プログラムにおけるロギングポイントの位置ならびに定数ポインタおよび整数などのそのログポイントについて常に同じであるデータ（「静的データ」）と、タイムスタンプおよびプログラム変数の内容などの変更し得るデータ（「動的データ」）とを区別するために、各ロギングポイントでロギングされたデータを解析するように構成されることができる。その解析を考慮すると、コンパイラは、動的データのみをロギングするためのインストルメント化およびロギングポイントを表す一意識別子を構築するように構成されることができる。実施形態では、一意識別子を、プログラム内のロギングポイントの位置、または位置と相関する数とすることができる。改善バックエンドコンパイラは、ロギングポイントの一部またはすべてについての静的データを保存することができ、これは、実行可能イメージの非ロードセクションにて、またはデータファイルにて、または（プログラムまたは人であり得る）ロギングデータの消費者によってアクセス可能な別の場所にて、一意識別子によってインデックス付けされる。そのようなインデックスを「静的ルックアサイドテーブル」と称することができる。ロギングデータの消費者は、各ログエントリの長さを決定して欠落静的データを推測または合成するために、静的ルックアサイドテーブルを使用することができる。その結果、静的データはほとんど、あるいは全く、実行可能コードフットプリント、メモリフットプリント、ランタイムパフォーマンス、またはログ空間への影響を有しない。実施形態では、改善バックエンドは、ログからのタイムスタンプの上位ビットを省略して後でそれらを合成することなどの追加の最適化を実行し得る。
いくつかの実施形態では、そのような最適化は、ロギング情報が静的データを含む場合には特に、非常に効率的なロギングをもたらすことができる。パフォーマンス制約により他の種類のロギングの使用が不可能である場合には、本明細書に記載するように最適化されたロギングを使用することが依然として可能であり得る。典型的な場合では、ランタイムパフォーマンスまたは他の制約に重大な影響を与えることなく、ユーザが自由にこのような最適化されたロギングを適用することができる。
《実行パスについてのトレースデータ》
改善バックエンドは、インストルメント化を使用して、システムにおける実行のスレッドの実行パスをどれも記録しない、または、いくつかもしくはすべての実行のスレッドの実行パスを記録することができる。
実施形態において、改善バックエンドにおけるコンパイラは、基本ブロックの第１の命令の前に各基本ブロックについてのインストルメント化を挿入するように構成されている。実施形態では、インストルメント化は、特定の基本ブロックが実行されたことを示すために、基本ブロックに関連付けられた（例えばプログラムカウンタの値など）の一意識別子をロギングするように構成されている。各命令の代わりに各基本ブロックをロギングすることは、実行のスレッドの実行パスをエンコードするためにロギングが必要なデータの量を低減することについて有利である可能性がある。
実施形態において、改善バックエンドにおけるコンパイラは、１つ以上の分岐命令に関連付けられたインストルメント化を挿入するように構成されている。分岐命令とは、その実行が、プログラムメモリにおける分岐命令の直後に続かないコードの実行に直ちに先行し得る命令として定義され得る。実行される次のプログラム命令がプログラムメモリ内の分岐命令の直後の命令でない場合、分岐は、その実行の特定のインスタンスにて「行われる」と言われ得る。実施形態では、特定の分岐命令に関連付けられたインストルメント化は、分岐が行われているか否かに関係なく、ログデータを生成し得る。実施形態では、分岐が行われる場合、特定の分岐命令に関連付けられたインストルメント化は、ログデータを生成するのみであり得る。実施形態では、特定の分岐命令に関連付けられたインストルメント化は、分岐が行われていない場合に、ログデータを生成するのみであり得る。各命令の代わりに各ブランチをロギングすることは、実行のスレッドの実行パスをエンコードするためにロギングする必要があるデータの量を低減させるのに有利である可能性がある。
実施形態では、分岐命令に関連付けられたインストルメント化は、分岐命令の後に実行される次の命令の命令をロギングするように構成されている。実施形態では、分岐命令に関連付けられたインストルメント化は、実行される次の命令のメモリアドレスなどの、実行される次の命令を一意に識別する識別子をロギングするように構成されている。別の実施形態では、分岐命令に関連付けられたインストルメント化は、実行される次の命令のメモリアドレスと、プログラムメモリ内の分岐命令に続く命令のメモリアドレスとの間の差などの、実行される次の命令の相対的指標をロギングするように構成されている。別の実施形態では、分岐命令に関連付けられたインストルメント化は、分岐命令の実行のその特定のインスタンスにおいて分岐が行われたか否かの命令をロギングするよう構成されている。
図８Ａは、基本ブロックを含むソフトウェアプログラムの高レベルの概要を示すブロック図である。実施形態では、ソフトウェアプログラムは、複数の基本ブロックを含むことができる。本明細書で説明するように、基本ブロックは、１つのエントリポイントと１つのイグジットポイントとを有する命令のセットまたはシーケンスである。コンパイラは、１つ以上の基本ブロックを識別するためにソフトウェアプログラムを解析することができる。実施形態では、ソフトウェアプログラム８００は、多数の基本ブロックを含むことができる。実施形態では、ソフトウェアプログラムは、最初の基本ブロック８０２、具体的には基本ブロック１を含むことができる。実施形態では、基本ブロック１は、８０４における基本ブロック２および８１０における基本ブロック３に分岐することができる。基本ブロック２はまた、他の基本ブロック８０８および８０６につながる多数の他の分岐を含むことができる。
実施形態では、ソフトウェアプログラムは、以前または先行の基本ブロックを伴って常に実行されて先行ブロックによって呼び出される基本ブロックのみである、以後または後続の基本ブロックを含むことができる。例えば、図８Ｂに示されるように、後続基本ブロックＢ（８２２）の実行が直ちに、先行基本ブロックＡ（８２０）の実行に続くことができる。基本ブロックＢは基本ブロックＡの唯一の後続であるため、基本ブロックＢが実行されたとき、基本ブロックＡも実行されていることが既知である。実施形態では、トレースデータログが基本ブロックＢからのインストルメント化データを含む場合、基本ブロックＡもまた実行されたことが既知であるので、基本ブロックＢのみがインストルメント化される。ソフトウェアコードに挿入されるインストルメント化の量を低減するためにシステムがこの情報を利用することができるので、後続基本ブロックを伴って常に実行される基本ブロックの識別は、有利である。
図８Ｃは、実施形態に係る別の基本ブロックインストルメント化最適化を示す。図示されたように、基本ブロックＡ（８３０）は、基本ブロックＣ（８３４）を直接、呼び出すことができ、または、基本ブロックＢ（８３２）を呼び出して、その次に基本ブロックＣを呼び出すことができる。トレースデータが基本ブロックＣにのみ関連するデータを含む場合、実行中に基本ブロックＡは、基本ブロックＣを直接、呼び出して基本ブロックＢは実行されなかった。トレースデータが基本ブロックＢに関連するデータを含む場合、実行中に基本ブロックＡは、基本ブロックＢを呼び出して、その次に基本ブロックＣを呼び出した。いずれの場合においても、基本ブロックＡは別個にインストルメント化されない。基本ブロックＢおよびＣのみのインストルメント化で十分である。
図８Ｄは、実施形態に係るさらに別の基本ブロックインストルメント化最適化を示す。図示されたように、基本ブロックＣ（８４４）は、基本ブロックＢ（８４２）または基本ブロックＮ１〜Ｎｎ（８４６）のいずれかを介して基本ブロックＡ（８４０）から呼び出される。トレースデータが基本ブロックＣにのみ関連するデータを含む場合、実行中に基本ブロックＡは、基本ブロックＣを基本ブロックＮ１〜Ｎｎを介して呼び出して基本ブロックＢは実行されなかった。トレースデータが基本ブロックＢに関連するデータを含む場合、実行中に基本ブロックＡは、基本ブロックＢを呼び出して、その次に基本ブロックＣを呼び出した。いずれの場合においても、基本ブロックＡおよびＮ１〜Ｎｎは別個にインストルメント化されない。基本ブロックＢおよびＣのみのインストルメント化で十分である。
実施形態では、複数の直後の後続ブロックを伴う基本ブロックは、後続ブロックのうちの１つの第１の命令による継続を実行させる命令で終了する。このような命令を、条件分岐命令と呼ぶことができる。最適化コンパイラには、条件分岐命令の実行後に実行される可能性が最も高いのはどの後続ブロックであるかを決定するための経験則および他の技術を使用することができるものがある。いくつかのＣＰＵアーキテクチャでは、そのようなコンパイラは、ＣＰＵキャッシュを最大限に活用するようコードを編成することによって、および／または、ＣＰＵに分岐が行われそうかそうでないかを教える条件分岐命令のフォームを生成することによって、および／または他の技術を使用することによって、生成された実行可能ファイルの効率を高めるためにこのような決定を使用することができる。実施形態において、改善バックエンドは、このような分岐予測能力を伴うコンパイラを含むことができ、その能力を、インストルメント化しないためにはどの基本ブロックが最も有益であるかの決定を知らせるために最適化インストルメント化の生成時に使用することができる。
図８Ｄの例では、ブロックＡ（８４０）は、２つの直後の後続ブロック：実施形態に係るブロックＢ（８４２）およびブロックＮ１（８４６における第１のブロック）を有する。本明細書に記載のインストルメント化最適化を適用することにより、コンパイラは、ブロックＡ（８４０）およびＢ（８４２）から、またはあるいはブロックＡ（８４０）およびＮ１〜Ｎｎ（８４６）から、インストルメント化を省略することができる。ブロックＡ（８４０）の両方の後続ブロックが実行される可能性が等しいと仮定すると、最も効率的なコードは、より多くのブロックを含むパスからのインストルメント化を省略することによって生成される。しかし、実施形態では、コンパイラは、それらの後続ブロックの各々がブロックＡ（８４０）の実行後に実行される相対的可能性を予測することができる。例えばコンパイラが、ブロックＢ（８４２）がＮ１〜Ｎｎ（８４６）よりも１０倍、ブロックＡ（８４０）に続く可能性が高いと予測し、一連のブロックＮ１〜Ｎｎ（８４６）で実行されるブロックの数「ｎ」が１０未満である場合、コンパイラは、インストルメント化を最適化する場合には、ブロックＮ１〜Ｎｎ（８４６）およびブロックＣ（８４４）をインストルメント化してブロックＡ（８４０）およびＢ（８４２）からのインストルメント化を省略することがより効率的であると決定することができる。これは、実行されるインストルメント化命令の合計期待数、およびターゲットプログラムを実行する際に消費される合計ログ空間が低減されて、ランタイムパフォーマンスへの影響およびインストルメント化のログ空間消費が減少するという点で、有利である。他に対する１つのコードパス実行の可能性が大くなればなるほど、この技術のおかげで潜在的パフォーマンスが大きくなり、ログが節約される。特定の分岐が１，０００回に一度または１，０００，０００回以上に一度のみ行われることが珍しくないことを考えると、この技術の潜在的な節約はかなりのものである。
実施形態ではシステムは、基本ブロックへのエントリを識別するインストルメント化コードを生成して挿入する。例えば、１つ以上のインストルメント化命令を、基本ブロックの先頭に挿入することができる。実施形態では、基本ブロックのエントリポイントの位置は、メモリアドレスによって表され、これは、仮想メモリ位置に対応することができる。実施形態では、インストルメント化は、その後続ブロックが問題の基本ブロックによって常に先行されている一部またはすべての基本ブロックへのエントリを別途、記録しないことによって最適化されることができる。後続基本ブロックへのエントリを記録することは、先行基本ブロックの実行を識別するのに十分であることができる。有利なことに、これは、インストルメント化の結果として生成および記録されたトレースデータのサイズを減らすだけでなく、ターゲットプログラムに挿入する必要があるインストルメント化コードの量またはボリュームを減らして、それによりターゲットプログラムの実行パフォーマンスへの影響を低減することができる。ソフトウェアコードに挿入されるインストルメント化の量を低減することにより、システムはより効率的にターゲットソフトウェアをデバッグすることができる。ターゲットソフトウェアに挿入されたインストルメント化コード要素の数を減少させることによって、より少ないトレースデータが生成される。生成されるトレースデータのサイズ減少、および／または、インストルメント化コード量の減少により、ターゲットコンピュータプログラムの実行についてのインストルメント化の影響を低減し、停止条件につながるイベントの再生／再構成に必要な時間も改善することができる。
実施形態は、実行パスをトレースするためのインストルメント化の一部または全部を省略し得る。このような省略は、トレースされたプログラムのランタイムパフォーマンスを改善し、トレースされたプログラムのコードサイズを低減し、および／または、より少ないログデータを使用することができる。このような場合、実施形態は、「再構成レジスタ状態」のセクションに記載されているものなどの技術を使用して実行パスを再構成し得、これは、プログラムの実行の一部またはすべての実行パスの実行、または、実行シミュレートを行うために、本明細書に記載されるような「再構成シミュレーション」技術を使用する。レジスタ状態などの状態情報のうち、このような技術により再構成されるのが、プログラムカウンタ（ＰＣ）である。再構成中に実行される各命令の後のＰＣの記録により、プログラムの一部の実行パスが有効に再構成される。実施形態はまた、所望の停止条件のためにバイナリサーチを実行するために再構成シミュレーションを使用するなど、実行パスを再構成するための他の技術を採用し得る。様々な条件に応じて、そのような技術は、より少ないメモリを消費し、および／または、より迅速に所望の停止条件を発見するという点で有利であり得る。
《メモリ修正のためのトレースデータ》
実施形態において、改善バックエンドは、最新から最古までなど、データが時間的に逆方向にデコードされることを可能にするような方法でトレースデータをロギングすることができる。この目的のために、改善バックエンドは、変更されようとしているメモリの内容（「プリイメージ」）をロギングすることができる。プリイメージロギングの１つの方法が図１８Ａである。この例では、プリイメージがロードされ、そしてロギングされる。修正されたデータのアドレス、修正されたデータの長さ等などのメタデータが、同時にロギングされ得る。最後に、メモリの修正が行われる。プリイメージロギングの他の方法が、ロギングが行われる環境に応じて使用され得る。
プリイメージロギングは、コンピュータプログラムがストア命令でメモリを修正する前に、プリイメージをロギングするように構成されたコンピュータプログラム内でインストルメント化することにより行うことができる。このようなプリイメージロギングは、ＣＰＵレジスタにプリイメージをロードし、（任意選択的に）追加メタデータとともにログにＣＰＵレジスタの内容を書き込んでストア命令でメモリ修正を行う形態をとることができる。ＣＰＵアーキテクチャに応じて、例えば、ＣＰＵアーキテクチャがＣＰＵレジスタの値を用いてメモリ内の値をスワップするメモリ交換命令を有する場合、他の技術が可能であり得る。
コンピュータプログラム外部のオペレーティングシステムまたは他のエージェントがプログラムのメモリを修正する場合、プリイメージロギングは、コンピュータプログラム、ライブラリ、オペレーティングシステムまたは他の場所におけるインストルメント化によって行われ得る。例えば、プログラムは、ＰＯＳＩＸ「読み出し」コールなどのプログラムのメモリを修正するシステムコールを行うことができる。オペレーティングシステムが「読み出し」コールにおいてメモリ修正を行う前に、オペレーティングシステムは、プログラムに代わって、上書きされようとしているメモリのプリイメージをロギングすることができる。別の例として、プログラムは、ハードウェアデバイスからプログラムのメモリ空間へのダイレクトメモリアクセス（ＤＭＡ）を要求することができる。ＤＭＡを要求する前に、プログラムは、ＤＭＡによって上書きされる可能性があるメモリのプリイメージを保存することができる。
いくつかの実装では、プリイメージロギング手順が、コンテキストスイッチまたはＰＯＳＩＸ信号などの外部イベントによって中断される可能性があり得る。このような場合には、実行が中断コードに戻ってメモリ修正が行われる場合、メモリから読み出された、および／またはロギングされたプリイメージはもはや正確でないかもしれない。この場合、特別なアクションがとられなければ、ロギングされたプリイメージ値が正しくない可能性があり、そのような不正データを使用しようとする時間走行デバッガが不正に動作する可能性がある。この問題の例を図１８Ｂに示す。中断（Ｘ４ｂ０１と標識されたボックス）が、もはや正確でない、以前にロードされたプリイメージ（Ｘ４ｂ０２）をもたらし、不正データがロギングされる（Ｘ４ｂ０３）ことに留意されたい。具体的には、ロギングされたプリイメージデータ（Ｘ４ｂ０３）は、実際に上書きされるメモリと一致しない（Ｘ４ｂ０４）。図には示さないが、プリイメージがロギングされた（Ｘ４ｂ０３）後であってメモリ修正が発生する（Ｘ４ｂ０４）前に割り込みが発生した場合、同じ問題が発生することに留意されたい。この問題に対処するための技術のいくつかの例は、本明細書に記載されている。
実施形態において、改善バックエンドは、プリイメージロギングおよびメモリ修正のアトミック性を保証するために「再始動可能ウィンドウ」を使用することができる。再始動可能ウィンドウとは、コードのセクションが中断された場合に、中断が完了した後、プログラム、ライブラリ、オペレーティングシステムまたは他の場所における機構が中断コードを以前のポイントから再開させる技術を指すことができる。これは、図１８Ｃに示されている。中断（破線矢印）がプリイメージのロード（Ｘ４ｃ０２）とメモリ修正の実行（Ｘ４ｃ０４）との間の任意のポイントで発生する可能性があり、他のコードの実行（Ｘ４ｃ０１）およびロードされたプリイメージ値の無効化（Ｘ４ｃ０２）となることに留意されたい。他のコードが完了すると、実行がインストルメント化の開始（Ｘ４ｃ０２）に戻ることができる（Ｘ４ｃ０５）。このような場合には、不正データが中断前にロギングされたかまたは部分的にロギングされた場合、ランタイム時にログからデータを除去することができ、または、ロギングされたデータの消費者が条件を検出して不正なまたは部分的にロギングされたデータを無視することができる。
再始動可能ウィンドウを含む実施形態では、インストルメント化が完全に実行されるまでログポインタが進んでいないようにインストルメント化を構成することによってランタイム時に部分的にロギングされたデータの除去が達成される。このような場合、中断されたコードの再始動時にそれが新たなデータでログの同じセクションを上書きする、または、ログのその部分が続いて別の目的のために使用されている場合、それはログの新たなセクションに新たなデータを書き込むであろう。
再始動可能ウィンドウを含む実施形態では、中断の近傍でアプリケーションコードをディスアセンブルすることにより、インストルメント化のパターンまたはインストルメント化の進行を示す他の命令を探すことにより、または、プログラムのコンパイルおよび／または解析に関与するコンパイラまたは他のツールにより生成されるメタデータを調べることにより、部分的にロギングされたデータをどのくらい除去しなければならないかを決定することができる。
いくつかの実装では、改善バックエンドは、中断されたプリイメージロギングに対処するために、以下の技術を使用することができる。オペレーティングシステム、ライブラリ、または他のコンポーネントは、割り込みからの復帰時に、正しいデータを含む特別なレコード（以下「フィックスアップレコード」）をロギングすることができる。そのようなレコードを検出すると、ロギングされたデータの消費者は、メモリストアに関連付けられている任意の誤ったまたは部分的にロギングされたデータを無視するように構成されることができる。この例は、図１８Ｄに示されている。割り込みが完了すると、新たなプリイメージを、中断されたインストルメント化に戻ってメモリ修正を行う前にロギングすることができる（Ｘ４ｄ０５）。図１８Ｂにおけるように、この例ではプリイメージのロード（Ｘ４ｄ０２）直後の中断のみが示されているものの、この技術は、プリイメージのロード（Ｘ４ｄ０２）とメモリ修正の実行（Ｘ４ｄ０４）との間の任意のポイントで発生する割り込みについて作用する。
実施形態では、フィックスアップレコードは、中断がプリイメージのロードおよびメモリ変更レコードのロギングの間に発生したことをシステムが検出したときにロギングされるのみである。そのような検出は、中断の近傍でのアプリケーションコードのディスアセンブリ、インストルメント化のパターンまたはメモリ修正を示す他の命令の探索、または、プログラムのコンパイルおよび／または解析に関与するコンパイラまたは他のツールで生成されるメタデータの調査によって達成することができる。
実施形態では、フィックスアップレコードは、中断が発生した時点に関係なくロギングされることができ、フィックスアップレコードがプリイメージのロードとメモリ変更レコードのロギングとの間に発生したかどうかを後で決定することができる。（人またはプログラムであり得る）フィックスアップレコードの消費者がフィックスアップレコードは異なる時間にロギングされたと判断する場合、フィックスアップレコードを無視することができる。中断が発生した時点にかかわらずフィックスアップレコードをロギングする技術は、フィックスアップレコードを条件付きでロギングするよりも優れたランタイムパフォーマンスを持つことができ、それはフィックスアップレコードが必要であるかどうかを判断するためにディスアセンブリまたは他の技術を適用する必要がないからである。どの技術がより有益であるかは、ＣＰＵアーキテクチャ、インストルメント化の構造、オペレーティングシステムの特性（適用可能な場合）および他の要因に依存する可能性がある。
《留保トレースデータ最適化》
プリイメージログインストルメント化は、本明細書に記載されるように、いくつかの実施形態では、基本ブロック内の各メモリストアオペレーションについて、影響を受けたメモリのアドレス、プリイメージ、ストアの幅等などの情報をロギングすることができる。しかし、ロギングされた情報の消費者は、他のソースからのこの情報のサブセットが、情報のサブセットが冗長であってロギングの必要がない場合にあたるかを決定し得る。不要なデータをロギングしないようにインストルメント化を最適化することは、不要なロギング命令を排除することでランタイムパフォーマンスを向上させることができてログ空間のより効率的な使用につながるという点で有利である。本明細書中に記載の留保トレースデータ最適化は、このような最適化である。
改善バックエンドにおけるコンパイラは、同じメモリアドレスへのメモリアクセスのブロックを識別するためにターゲットプログラムを解析し、そのようなブロックについて、アクセス中のメモリアドレスを記録する１つ以上のインストルメント化命令を挿入することによりインストルメント化を最適化するように構成されることができる。他のインストルメント化命令は、関連データのみを記録する必要があり、メモリアドレスは不要である。例えば、ターゲットプログラム命令のセットが、アドレスＡを有するメモリ位置へのアクセスをＮ回（Ｎは１、２、３、４…などの整数である）行ったとする。アドレスＡへの最後のメモリアクセスについて、コンパイラは、関連するデータとともにアドレスＡをトレースデータに記録するように構成されたインストルメント化命令を生成することができる。残りのＮ−１回のアドレスＡへのアクセスについて、コンパイラは、関連データのみを記録するがアドレスＡを記録しないインストルメント化命令を生成するように構成することができる。このような最適化は有利には、トレースデータのサイズを小さくすることができる。実施形態では、複数のメモリアドレス（ＡおよびＢ、Ａ、Ｂ、ならびにＣなど）が例えば、レジスタに保存され得る同じベースアドレスからの異なるオフセットによりアクセスされる場合に、このタイプの最適化が行われる。ベースアドレスは一度だけ記録され、後続のメモリ位置アドレスはそれらのオフセットのみにより記録される。実施形態では、このタイプの最適化は留保トレースデータ最適化と称される。
実施形態では、コンパイラは、基本ブロックの先頭の代わりに基本ブロックの最後に、基本ブロックの実行を識別するインストルメント化コードを挿入するように構成されることができる。このように、時間的後方へと実行される再生および／または再構成を最適化することができ、それは、基本ブロックを表すレコードがメモリストアを表すレコードおよび／またはその基本ブロック内で発生した他のイベントの前に遭遇することになるからである。再生および／または再構成中のトレースデータのデコードをさらに高速化するために、コンパイラは、基本ブロックの最後に関連付けられたプログラムカウンタの値を保存する命令に加えて、特定の値でレジスタをロードするなどの１つ以上の追加の命令を挿入することができる。１つ以上の追加命令を、（ノーオペレーションすなわちＮＯＰ命令実行と同様に）副作用がない命令とすることができる。システムが再生および／または再構成中にこのような１つ以上の追加命令を検出すると、これはトレースデータに保存されるプログラムカウンタ（または別のタイプの一意識別子）が基本ブロックの最後についてのものであることをシステムに示すであろう。システムはそして、基本ブロックの先頭プログラムカウンタ（ＰＣ）を発見してトレースデータにそれを挿入し、それにより、先頭ＰＣが元のトレースデータに記録されたトレースデータデコーダにそれが現れる。実施形態では、このような動作は留保トレースデータ最適化と称され、これは、その通常位置におけるＰＣ値の挿入が、トレースデータがデコードされるまで留保されるからである。
実施形態では、このようなシステムは有利には、記録トレースデータの量を減らすことができる。ＰＣインストルメント化が基本ブロックの最後に挿入される場合、その前のプリライトメモリ値は多くの場合、サイズ低減されることができ、それは、このようなエントリが、記録および保存されたＰＣ値から自身を区別するために追加注釈を必要とせず、システムが、それらがプリイメージ（またはプリライト）メモリ値であると想定することができるからである。対照的に、ＰＣインストルメント化が基本ブロックの先頭に記録されている場合は、トレースデータを後方にデコードすると、基本ブロックについて記録されたプリイメージメモリ値に最初に遭遇する。したがって、これらの値は、ＰＣ値から区別するために追加注釈を必要とする。
実施形態では、図９に示されているように、留保トレースデータ最適化が以下のように行われる。トレースデータフラグメント９３０は、基本ブロックの最後にＰＣを保存するエントリ９３２を含む。エントリ９３４は、（アドレスａ＋８への書き込み前の）メモリアドレスへの書き込みに対応し、プリイメージ値とアドレス（すなわち「ａ＋８」）とを含む。エントリ９３６および９３８は、メモリアドレスへの書き込みに対応するが、プリイメージ値のみを含み、アドレスを含まない。再生および／または再構成中、システムは、トレースデータフラグメントをデコードするためのテンプレートまたはマップを含む特別セクション９４０を利用することによってトレースデータフラグメント９３０をデコードするであろう。このようなセクションは、本明細書に記載されるように、静的ルックアサイドテーブルの一例とすることができる。特別セクション内のエントリ９４２は、トレースデータ内のエントリ９３２に関連付けられ、ＰＣの値がトレースデータに保存されていることを示している。特別セクション内のエントリ９４４は、トレースデータ内のエントリ９３４に関連付けられ、書き込まれたアドレスとともに「フルプリイメージ」またはプリライト値がトレースデータに保存されていることを示している。特別セクション内のエントリ９４６は、トレースデータ内のエントリ９３６に関連付けられ、プリライト値のみがトレースデータに保存されていることを示している。書き込まれたアドレス（すなわち「ａ＋４」）は、トレースデータに保存されないが、特別セクション内のエントリ９４６から再構成される。実施形態ではアドレスは、トレースデータにてエントリ９３４に保存されたアドレス「ａ＋８」から暗示される（例えば、「−４」の相対オフセットが特別セクション内のエントリ９４６に保存され、これは、アドレス「ａ＋８−４」すなわちより単純に「ａ＋４」に対応する）。特別セクション内のエントリ９４８は、トレースデータ内のエントリ９３８に関連付けられ、プリライト値がトレースデータに保存されていることを示している（しかし、「−８」の相対オフセットなどの暗黙アドレスが特別セクション内のエントリ９４８に保存され、これは、アドレス「ａ＋８−８」すなわちより単純に「ａ＋０」または「ａ」に対応する）。例えば、特別セクション内のエントリ９４８，９４６および９４４は、プログラムがアレイまたはこのような一連の近くのメモリアドレスへの書き込み中であったことを示し、それは、連続したメモリ位置（「ａ」「ａ＋４」および「ａ＋８」）が、（ベースアドレスであるアドレス「ａ」とともに）書き込み中であったからである。再生および／または再構成の間、トレースデータをデコード（または解凍）し、欠落情報を挿入する。例えば、アドレスａ＋０およびａ＋４は、特別セクション内のエントリ９４６および９４８に保存された暗黙アドレスを使用して、トレースデータに挿入されるであろう。このように、すべてのアドレスが元のトレースデータに記録されたことになるであろう。
実施形態では、留保トレースデータ最適化は、連続メモリ位置への書き込みの場合に限定されるものではない。他の実施形態では、特定のデータは、デバッグ中のタスクの実行中にトレースデータログから省略され得る。例えば、最後のプリイメージメモリ値のアドレスのみを記録することができ、定数であるかまたは最後のアドレスからのオフセットとして表すことができる基本ブロックによって書き込まれる他のすべてのアドレスを、セクション９４０などの特別セクションに記録する。欠落データは、タスクの実行が停止された後、後でトレースデータログに挿入されることができる。
実施形態では、セクション９４０は、静的ルックアサイドテーブルであり、ＥＬＦ（実行可能ファイルおよびリンク可能フォーマット）ファイルのセクションに含まれる。ＥＬＦファイルのセクション９４０は、インストルメント化実行可能コードとともにはターゲットコンピュータシステムにダウンロードされない。むしろ、ＥＬＦファイルのセクション９４０は、スキップされたトレースデータをデコードまたは補充するために、再生および／または再構成中に使用される。有利には、留保トレースデータ最適化は、トレースデータログのサイズを低減し、コンピュータプログラムの実行前にターゲットコンピュータシステムに転送されるデータのサイズを低減する。
《副作用メモリ》
いくつかの場合、特定のメモリ位置（「副作用メモリ」と称することができる）からプリイメージ値をロードしようとすることは、望ましくない効果を有し得る。例えば、特定のメモリマップ化レジスタは、読み出し時にハードウェアデバイスの状態に影響を与える可能性がある。副作用メモリへのストアが行われた場合、改善バックエンドにおけるコンパイラは、プリイメージを読み出さない代替インストルメント化を生成するように構成することができ、したがって、任意の望ましくない副作用を回避する。このようなインストルメント化は、例えばストアのアドレスをロギングすることにより、通常の情報のサブセットをロギングすることができる。プリイメージを除いて、通常の情報をロギングすることにより、プリイメージに依存しない改善バックエンドおよび時間走行デバッガは、副作用メモリ上で動作しているときに、依然として正常に機能することができる。例えば、時間的に前方または後方への移動を停止する条件内でも、このようなストアを依然として使用することができる。
いくつかの場合において、所与のメモリストアが副作用メモリに影響を与えるか否かをコンパイル時に決定することが可能ではないかもしれない。例えば、ポインタを介したメモリストアは、ストア命令が実行されるたびに変わる可能性があるポインタによるポイント箇所に応じて、いずれかの種類のメモリに影響を与える可能性がある。このような場合には、改善バックエンドにおけるコンパイラは、影響を受けたメモリが副作用であるか否かをランタイム時に決定するインストルメント化を出力するように構成されることができる。このような決定は、既知の安全および／または既知の非安全メモリ範囲に対してストアアドレスを比較することにより、または他の試験を行うことにより行うことができる。実施形態では、改善バックエンドが所与のメモリストアが副作用メモリに影響を与えるか否かを判断することができなければ、プリイメージをロードせず、これは、デバッグ機能の低下が一般的に、ターゲットハードウェアの破壊、ＣＰＵのクラッシュまたは他のこのような負の影響の発生の危険を招きやすいからである。
実施形態では、改善バックエンドにおけるでコンパイラは、ストアが副作用メモリに影響するか否かについてのコンパイラの決定に影響を与えるために、ソースコードにおける特別なキーワード、またはコマンドラインオプション、または命令の他の形態をプログラマから受け入れるように構成されることができる。このような機構により、プログラマは、コンパイラのデフォルト挙動がサブ最適または不正であるかもしれない場合にコンパイラのデフォルト挙動を上書きできる。

レジスタ状態スナップショット
ＣＰＵのレジスタ状態を改善バックエンドによって記録することができる多くの方法がある。実施形態では、レジスタの値が変更されるたびにレコードをログに書き込むことができる。そのようなレコードは、レジスタが修正されたときに上書きされる値などのプリイメージ値を含むことができる。しかし、レジスタ状態はコンピュータプログラムの実行中に頻繁に変化する傾向があるので、この技術は、プログラムへの非常に多数のインストルメント化命令の挿入を含み得、これは、プログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与える可能性がある。
実施形態では、改善バックエンドは、定期的に１つ以上のＣＰＵレジスタ状態の「レジスタ状態スナップショット」を記録することができる。これらのレジスタ状態スナップショットは、アプリケーションによって、ライブラリコードによって、オペレーティングシステムによって、またはいくつかの他のコンポーネントによって、記録することができる。このようなスナップショットから様々な時点でのＣＰＵレジスタ状態を再構成するための技術は、「レジスタ状態再構成」のセクションに記載されている。レジスタ状態スナップショットは、レジスタのみを含むことに限定されない。レジスタ状態スナップショットは、プログラムメモリ、タイムスタンプ、スレッド情報、アドレス空間情報、または任意の他のデータの部分の表現などの他の状態またはメタ情報を含むことができる。このようなデータは典型的には、スナップショットの他の内容の使用を、増強し、識別し、または容易にするが、他の目的にも供することができる。
本明細書に記載のレジスタ状態スナップショットのロギングは、いくつかの実施形態では、個別にすべてのレジスタ変更をロギングするよりもランタイムパフォーマンスおよびメモリフットプリントにはるかに小さい影響を有するように構成されることができる。いくつかの実装では、本明細書に記載のレジスタ状態スナップショットをロギングする改善バックエンドは、バックエンドのコピーよりもトレース中のシステムのランタイムパフォーマンスにはるかに小さい影響を有することができる。コピーバックエンドは、各チェックポイントでのアプリケーションのメモリ空間およびレジスタ状態の一部またはすべてをコピーし、その影響は、アプリケーションによって使用されているメモリの量に比例する可能性がある。対照的に、改善バックエンドは、アプリケーションのレジスタ状態の一部またはすべてをコピーするのみであり、これは、ＣＰＵレジスタの数によってバウンディングされ、ランタイムパフォーマンスへの影響をアプリケーションによって使用されているメモリの量とは無関係にする。さらに、ＣＰＵのレジスタに含まれるデータの量は一般的に、アプリケーションによって使用されているメモリに含まれるデータの量よりもはるかに小さく、よって一般的には、改善バックエンドにより各チェックポイントにてロギングされるデータの量はコピーバックエンドによるよりもはるかに小さく、ランタイムパフォーマンスへの影響およびログ使用量をはるかに低減する。
改善バックエンドは、実行のスレッドが実行開始または停止するとき、外部変更がレジスタ状態になされるとき（例えば、オペレーティングシステムがシステムコールの一部としていくつかのレジスタを変更するとき）、各種の割り込みが発生したとき、および、スナップショットが最近ロギングされていないときなどに、レジスタ状態スナップショットを記録することができる。状況に応じてスナップショットは、完全レジスタ状態（「フルスナップショット」と称することができる）、またはサブセットのみを含むことができる。
スナップショットを記録するための改善バックエンドのタイミングを構成する際の１つの考慮事項は、ＣＰＵ状態を再構成するために必要な時間に影響を与えることである。実施形態では、「レジスタ状態再構成」のセクションに記載されているものなどのアルゴリズムを使用して、ＣＰＵ状態を再構成するために必要な時間をバウンディングするために、改善バックエンドは、スナップショットロギングをスケジュールすることができる。スナップショットベースレジスタ再構成アルゴリズムは典型的には、線形時間で実行され、アルゴリズムを実行するために横断しなければならないログの量に比例する。レジスタ再構成を実行するために横断しなければならないログの量をバウンディングすること、したがって、レジスタ再構成にかかる時間の量をバウンディングすることにより、改善バックエンドを採用する時間走行デバッガの各種動作の良好なパフォーマンス特性が可能となり得る。
実施形態では、改善バックエンドは、レジスタ状態スナップショットのロギングのための次のスケジュールを使用してレジスタ再構成時間をバウンディングすることができる。外部エージェント（例えばオペレーティングシステム）が実行の特定のスレッドに属しているレジスタを修正する場合、少なくとも変更したレジスタを含むスナップショットのロギングは、変更がログに反映されることを保証する。さらに、実行のスレッドが実行を停止したときのフルスナップショットのロギングは、実行のスレッドが実行されていないログ内のすべてのポイントで、遭遇した最新のスナップショットが正確なレジスタ状態を含んでおり、何の再構成も必要とされないということを保証する。実行のスレッドが実行されている時点でレジスタ再構成時間をバウンディングするために、実行のスレッドのレジスタ状態は、定期的にロギングされる必要があり、それにより、レジスタ状態スナップショット間でロギングされたトレースデータの量がバウンディングされる。実施形態では、これは、ログ空間の特定のバウンディングされた量が消費されるたびにレジスタ状態スナップショットをロギングすることにより達成することができる。
《オペレーティングシステムイベント》
実施形態では、改善バックエンドは、プログラマが関心のあり得るオペレーティングシステムイベントをロギングすることができる。例としては、実行のスレッドおよび／またはアドレス空間の作成および破壊、実行のスレッドおよび／またはアドレス空間の間の通信、システム上で実行中のアプリケーションのパフォーマンスに影響を与える可能性がある、および／または、データの到着もしくは関心のあるなんらかの他の外部イベントを示す可能性があるものを含むハードウェア割り込み、実行のスレッドのスケジューリングに影響を及ぼす、および／または、アプリケーションレジスタまたはメモリ状態を修正するオペレーティングシステムイベント、仮想メモリのマッピングおよび／またはマッピング解除、ミューテックス、セマフォなどの同期プリミティブの使用が挙げられる、これらに限定されない。
時間走行デバッガおよび／または他のユーザインタフェースコンポーネントは、プログラマによるシステム挙動の全体的な理解を助けるためにプログラマにそのようなイベントを表示することができる。そのようなイベントが、例えばそのメモリまたはレジスタ状態を変更することによってアプリケーションに影響を与える場合、改善バックエンドは、例えば、時間内移動についての終結条件内でこのようなイベントをユーザが特定できるようにすることによって、このような変化に起因するバグを検出および理解するプログラマの能力を向上させるためにそのような情報を使用することができる。このような機能は、例えば、メモリ破損の原因を発見することにおいて便利である。改善バックエンドを採用しない時間走行デバッガは、アプリケーション自体によって開始された変化を検出するのみなど、メモリ変更の原因を突き止める能力を、あるとしても、限定的にしか有し得ない。対照的に、改善バックエンドを採用する時間走行デバッガは、これらに限定されないが、アプリケーション自体、それ自身に作用するオペレーティングシステム、別のアプリケーションまたは実行のスレッドのために作用するオペレーティングシステム、ＤＭＡデータの到着もしくは他のＣＰＵ上で実行中のスレッドおよびオペレーティングシステムのアクションなどのオペレーティングシステムが見ることのできる外部イベントを含む、より広い範囲のソースによって引き起こされるメモリ変更を検出することができる。
《非決定論的命令ロギング》
アプリケーション内外で発生するメモリおよびレジスタ変更のロギングのための本明細書に記載された技術は、その実行時のアプリケーションの状態へのほとんどの変更を捕捉するのに十分である。しかし、改善バックエンドが様々な時点でシステムの状態を正確に再現するように別個に取り扱うことができる捕捉されない付加的な場合がある可能性がある。
（「非決定論的命令」と称され得る）いくつかのＣＰＵ命令は、以前の状態から予測または推測することができない結果を生成する可能性がある。例えば、ＣＰＵ命令は、ＤＭＡによって修正される可能性があるメモリマップされたレジスタもしくはメモリのセクション、または、その行動がロギングされていないもしくは別様に未知である別のアプリケーションと共有されるメモリなどの、以前の状態から知るまたは推測することができないメモリ位置の内容をレジスタにロードすることができる。別の例では、ＣＰＵ命令が、クロックもしくは乱数発生器から読み出され、または、以前の状態から予測もしくは推測することができない結果を別様に生成することができる。別の例では、ＣＰＵ命令の結果は、非同期的に動作するシステムの他の部分などの非決定論的ソースの挙動によって影響を受ける可能性がある。このような場合には、ＣＰＵ命令の結果が非決定論的であるときに、改善バックエンドにおけるインストルメント化は、命令の効果をロギングすることができる。改善バックエンドは、メモリおよびレジスタ状態の再構成を助けるために、後の時点でこのような情報を使用することができる。
《メモリへのロギング》
実施形態では、トレースデータの一部または全部は、ターゲットコンピュータシステムの（ＲＡＭなどの）メモリに保存することができる。実施形態では、トレースデータの一部または全部は、コンパイラを実行するコンピュータシステムなどの別のコンピュータシステムのメモリに記憶することができる。実施形態では、トレースデータのストレージを、ターゲットコンピュータシステムおよび別のコンピュータシステムのメモリにわたって分割することができる。
実施形態では、改善バックエンドは、ＲＡＭなどのメモリに情報をロギングするインストルメント化を含むことができ、それは、インストルメント化が実行されるＣＰＵによって書き込み可能である。メモリが限られた資源であり、ロギングできるデータ量に最大値があることを考えると、改善バックエンドはそれを最大限に活用するために利用可能なＲＡＭを管理するための戦略を採用することができる。そのような戦略の一例は、本明細書に記載の単一化ログである。
単一化ログを、１つ以上のログにメモリを割り当てるために（「単一化ログメモリプール」と称され得る）利用可能メモリの１つ以上のプールから引き出すことができる。例えば、単一化ログは、ＲＡＭの２つの５００メガバイトプールを取り、カーネルログおよび６つのアプリケーションログの間でそれらを割り当てることができる。ログの数は、例えば、実行中のインストルメント化アプリケーションの数の変更を提供するために、時間の経過とともに変化する可能性がある。単一化ログは、利用可能なメモリを１つ以上のプールから（「チャンク」と称され得る）部分へと分割し、これは、１つ以上のログの使用のために配分されている。このようなチャンクはすべて同じサイズであり得、または異なるサイズであり得る。
各ログは、書き込まれるべき次のエントリの位置を特定するための機構（「ログポインタ」と称され得る）、および、単一化ログによって割り当てられた現在のチャンクの最後を識別するための機構（「ページ制限機構」と称され得る）を含むことができる。このような機構の一例は、現在、割り当てられているチャンクのバウンドを含むデータ構造、および、ログ内の次の未書き込みエントリへのポインタである。
単一化ログは、各ログにチャンクを割り当てることによって開始することができる。いくつかの実施形態では、この初期割り当ての一部ではない単一化ログのプール内のメモリは、本明細書に記載されるように、後の使用のために利用可能なままであることができる。チャンクのこの初期割り当ては典型的には、それに応じて各ログについてのログポインタおよびページ制限機構を初期化することを含むことができる。
初期チャンク割り当ての例が、図２６Ａに現れる。この例では、単一化ログは、３つのログ、ログ１（Ｘ１３ａ−Ｌｏｇ１）、ログ２（Ｘ１３ａ−Ｌｏｇ２）、およびログ３（Ｘ１３ａ−Ｌｏｇ３）を管理する。単一化ログは、単一化ログ（Ｘ１３ａ−ＭＰ）に割り当てられたメモリプールからこれらのログのそれぞれに初期チャンク（Ｘ１３ａ−ｃ１、Ｘ１３ａ−ｃ２およびＸ１３ａ−ｃ３）を割り当てる。ログがひとたび現在のチャンクを有すると、現在のチャンクを、例えばそれらへのインストルメント化書き込みおよびログポインタ更新によって埋め込むことができる。ログのページ制限機構が現在のチャンクが埋め込まれていることを検出した場合、単一化ログは埋め込まれたチャンクをアーカイブ化して新たな現在のチャンクをログに割り当て、それに応じてログのログポインタおよびページ制限機構を更新する。埋め込まれたチャンクをアーカイブ化することは典型的には、埋め込まれたチャンクの位置、そのデータがそれに含まれているログのアイデンティティ、同じログで埋め込まれた他のチャンクに対するそれが埋め込まれた順序、単一化ログが管理するすべてのチャンクに対するそれが埋め込まれた順序、を追跡し続けることを含む。ログの現在のチャンクがひとたびアーカイブ化されると、単一化ログは、ログに新たな現在のチャンクを割り当てることができる。メモリが単一化ログのメモリプールで依然として利用可能である場合、新たな現在のチャンクをメモリプールから割り当てることができる。単一化ログのメモリプールが使い尽くされている場合は、いくつかの実施形態における単一化ログは、本明細書に説明するように、以前に埋め込まれたチャンクをリサイクルすることができる。
埋め込まれたチャンクのアーカイブ化の例が図２６Ｂに表示される。例では、ログ２（Ｘ１３ｂ−Ｌｏｇ２）が現在のチャンクを埋め込み、そしてアーカイブされている（Ｘ１３ｂ−ａｃ）。例では、メモリは依然として単一化ログのメモリプール（Ｘ１３ｂ−ＭＰ）で入手可能であり、よって、新たなチャンク（Ｘ１３ｂ−ｎｃ）がログ２（Ｘ１３ｂ−Ｌｏｇ２）に追加される。ログ１（Ｘ１３ｂ−Ｌｏｇ１）および３（Ｘ１３ｂ−Ｌｏｇ３）およびそれらのそれぞれの現在のチャンク（Ｘ１３ｂ−ｃ１，Ｘ１３ｂ−ｃ３）は影響されない。
いかなるメモリもプール内に残っていない場合、単一化ログは、既に埋め込まれたチャンクをリサイクルすることができ、これらのチャンク内のデータが上書きできる。改善バックエンドによって採用される場合、単一化ログは、改善バックエンドによって使用可能なログの量を最大化する目的でリサイクル戦略を採用することができる。実施形態では、改善バックエンドは、最新のデータで始まる、すべてのログからの連続したデータを必要とする。そのような改善バックエンドの実施形態を最高にサポートするために、単一化ログは、少なくとも最近アーカイブ化されたチャンクをリサイクルすることができる。ログ間のメモリ使用率の差を考慮しながら、このリサイクル戦略は、改善バックエンドに利用できる使用可能なログを最大化する。実施形態では、少なくとも最近、ログに追加されたチャンクをリサイクルするなどの他のリサイクル戦略を使用することができる。このような他のリサイクル戦略は、究極的にはシステム停止時に利用可能であるデータに対する異なる特性を有し得る。
チャンクリサイクルの例が図２６Ｃである。例では、単一化ログは、３つの別個のログ（Ｘ１３ｃ−Ｌｏｇ１，Ｘ１３ｃ−Ｌｏｇ２およびＸ１３ｃ−Ｌｏｇ３）をサービス中である。各ログは、それぞれの現在のチャンクを有し、Ｘ１３ｃ−Ｌｏｇ１はＸ１３ｃ−ｃ１を有し、Ｘ１３ｃ−Ｌｏｇ２はＸ１３ｃ−ｃ２を有し、Ｘ１３ｃ−Ｌｏｇ３はＸ１３ｃ−ｃ３を有する。各ログはまた、後にリサイクルされたチャンクに以前に保存された、失われたデータ（Ｘ１３ｃ−ｌｄ１，Ｘ１３ｃ−ｌｄ２，Ｘ１３ｃ−ｌｄ３）のボディを有する。例では、ログ１（Ｘ１３ｃ−Ｌｏｇ１）は単にその現在のチャンク（Ｘ１３ｃ−ｃ１）を埋め込み、新たなチャンク（Ｘ１３ｃ−ｎｃ）を必要としている。単一化ログのメモリプール（Ｘ１３ｃ−ＭＰ）が使い尽くされ、よって、単一化ログは、以前に使用されたチャンクをリサイクルする必要がある。ログ１（Ｘ１３−Ｌｏｇ１）に新たな現在のチャンク（Ｘ１３ｃ−ｎｃ）を与えるために、単一化ログは、リサイクル化チャンク（Ｘ１３ｃ−ｒｃ）となるよう少なくとも最近、アーカイブ化されたページを発見し、これは、新たなチャンクを受容するログを含む任意のログの一部となることができる。この例では、リサイクル化チャンク（Ｘ１３ｃ−ｒｃ）がログ２（Ｘ１３ｃ−Ｌｏｇ２）の一部である。単一化ログは、（任意選択的に）リサイクル化チャンク（Ｘ１３ｃ−ｒｃ）をクリアし、それをログ１（Ｘ１３ｃ−Ｌｏｇ１）についての新たな現在のチャンク（Ｘ１３ｃ−ｎｃ）とする。以前にリサイクル化チャンク（Ｘ１３ｃ−ｒｃ）に保存されたデータは失われ、ログ２の失われたデータ（Ｘ１３ｃ−ｌｄ２）の一部になる。リサイクルが完了するとすぐに、ログ１（Ｘ１３ｃ−Ｌｏｇ１）は、その新たな現在のチャンク（Ｘ１３ｃ−ｎｃ）の埋め込みを開始することができる。リサイクル戦略は、残りのデータが改善バックエンドで使用可能なログの量を最大にすることを確実にする。
なお、本明細書に記載のリサイクル戦略を採用する実施形態では、１つの実行のスレッドがデバッグのために停止された場合、または、エラーが発生したため、または他の何らかの理由で、同じ単一化ログを共有する実行のスレッドが実行を継続できるようにすることは有害であり得、これは、停止スレッドによって書き込まれたデータを含むチャンクのリサイクルをもたらし得、停止スレッドをデバッグするために有用であり得るデータを上書きするからである。このような実施形態では、１つの実行のスレッドの停止が同様に停止中のシステムにおける他の実行のスレッドの一部または全部となる実行制御戦略を採用することが有利である可能性がある。改善バックエンドは、このような実行制御戦略（「同期実行制御」）を含むことができる。
必要な機能を伴うＣＰＵ上で、単一化ログを、ＣＰＵの仮想メモリ機能を使用して実装することができる。このような実施形態では、各ログの現在のチャンクを、仮想アドレス空間内で固定されたウィンドウにマッピングすることができる。このようなウィンドウを「ロギングアパーチャ」と呼ぶことができる。このような実施形態では、ページ制限機構を、ログが書き込まれる方向にロギングアパーチャに隣接する仮想メモリアドレス（複数可）をマッピングされないままとすることによって実装することができ、これにより、ロギングアパーチャのエッジを越えて書き込もうとすると、ページフォールトとなる。このような場合、単一化ログは、ページフォールトハンドラがトリガされたときに適切なログについてのチャンクをアーカイブ化するように構成されることができる。有利なことにこのような実施形態において、ターゲットコンピュータプログラムの視点からは、トレースデータを保存するための空間を割り当てるすべての詳細はオペレーティングシステムによって取り扱われるため、ログはトレースデータを保存するための無限の能力を有しているように見える。これは、ターゲットコンピュータプログラムの実行へのインストルメント化の影響を低減することができ、ターゲットコンピュータプログラムの再生および／または再構成に関連する時間を減らすことができる。このような実施形態では、インストルメント化は、現在のログチャンクの境界を越える書き込みをチェックする命令を含む必要がないかもしれない。これらの境界チェックを削除すると、インストルメント化のランタイムコストを削減することができ、インストルメント化のフットプリントを減らすこともでき、コードサイズおよび速度の１つまたは両方を改善する。
いくつかの実施形態では、ロギングアパーチャの使用は、本明細書に記載されるように、他の方法でも有利である。合計ログサイズは、仮想メモリのサイズよりも大きくすることができる。例えば、仮想アドレスが３２ビット幅であるコンピュータシステムは、仮想アドレスを使用して、ＲＡＭの４ギガバイトまでアドレスアップすることができる。ロギングアパーチャを伴わなければ、ＲＡＭベースロギングを使用するこのようなコンピュータシステムは、４ギガバイト未満のログに制限される可能性がある。いくつかの実装では、本明細書に記載されるようにロギングアパーチャを伴えば、仮想アドレスを使用してアドレス可能なＲＡＭの量は、全く仮想アドレス幅によって限定される必要はない。さらに、特定の実施形態では、ロギングアパーチャは、本明細書に記載されるように、ロギングのために必要な仮想メモリの量を最小限に抑え、したがって、その自身のプログラム命令、データ等についてのアプリケーションによる使用のために残る仮想メモリの量を最大化する。
実施形態では、単一化ログは、各仮想アドレス空間において実行単位あたり（例えばマルチコアＣＰＵにおけるコアあたり）１つのロギングアパーチャを作成する。このような実施形態において、実行のスレッドがコア上で実行するように割り当てられている場合、そのログポインタは、オペレーティングシステムによって、または単一化ログに関連付けられたソフトウェアの別のボディによって、そのコアに関連付けられたロギングアパーチャをポイントするように設定される。これにより、実行のスレッドが実行を開始および停止する、および／または、１つの実行ユニットから別の実行ユニットへと移行する場合でさえ、同じ仮想アドレス空間内での複数の実行のスレッドが、それ自身のロギングアパーチャにそれぞれ、同時にデータをロギングすることが可能となる。このような実施形態では、仮想アドレス空間ごとに必要なロギングアパーチャの総数は、ＣＰＵ上のコアの数によってバウンディングされる。
不正に設定されたポインタを間接参照することにより、または他の手段により故障したソフトウェアプログラムは、例えばロギングアパーチャ内に書き込むことによって、ログにデータを不正に書き込む可能性がある。実施形態では、ロギングされたデータの消費者は、最新から最古までのロギングされたデータを読み出すことによって、本明細書に記載された技術を用いて、このような「不良ストア」を検出することができ、部分的または完全な回復を可能にする。不良ストアは、現在のログポインタの前または後にログメモリに書き込むであろう。ログポインタの後にメモリへ書き込む不良ストアは、それらが上書きするメモリがまだ有効なログデータを含まず、よって有効なログデータが上書きされないので、ほとんど重大な結果を有しない。さらに、ログポインタの後にメモリに書き込む不良ストアによって書かれたガベージデータは、インストルメント化によって生成される「良好」データによって最終的に上書きされるであろう。他の場合、ログポインタ前にメモリへ書き込む不良ストアは、良好ログデータを上書きして破壊する可能性があり、しばしば、ログの破損の時点またはそれ以前でロギングされたデータを使用することは困難または不可能となる。不良ストアによって破損したログの位置にかかわらず、不良ストア自体の証拠を、いくつかの実施形態によって本明細書に記載されるようなプリイメージンストルメント化などの通常のインストルメント化によってログに記録することができる。最新から最古までのロギングされたデータを読み出すことによりロギングされたデータの消費者は、その不良ストアによって破損した任意のデータに遭遇する前に、不良ストアに対応するインストルメント化生成ログデータに遭遇するであろう。したがって、すべての場合において、データの消費者は、例えば、ストアがロギングアパーチャに関連付けられたメモリアドレスを修正したことを認識することによって、不良ストアを検出し、適切な是正措置をとることができる。ログポインタに対する不良ストアのアドレスが、ログが破損データを含むことを示す場合には、データの消費者は、破損データに到達する前にデータの処理を停止し、したがって、破損ログデータを処理しようとすることによって引き起こされるデバッグシステムの誤動作を防止することができる。不良ストアが検出されるすべての場合において、データの消費者は、例えば、警告メッセージを表示することによって、および、不良ストアが発生したプログラム内の位置を強調表示することによって、プログラマに知らせることができる。
不良ストア回復の例が図２６Ｄに表示される。この例では、まだデータが含まれていないログ（Ｘ１３ｄ−ｌｏｇ−１）内のポイント（Ｘ１３ｄ−ｂａｄｓｔｏｒｅ−１）で破損が起こる。ログを破損させたメモリストアは、それ自体が、メモリ変更レコード（Ｘ１３ｄ−ｍｃｈｇ−１）を用いてロギングされる。完了ログチャンク（Ｘ１３ｄ−ｌｏｇ−２）において、不良ストア（Ｘ１３ｄ−ｂａｄｓｔｏｒｅ−２）によって破損した位置が、良好データで上書きされている。ログチャンク全体は、使用可能な情報を含み、ログデータの消費者が不良ストアを示すメモリ変更レコード（Ｘ１３ｄ−ｍｃｈｇ−２）に遭遇すると、プログラマにエラーを知らせることができる。
不良ストア回復の第２の例が図２６Ｅに現れる。この例では、破損は、貴重なログデータを含んだログ（Ｘ１３ｅ−ｌｏｇ−１）におけるポイント（Ｘ１３ｅ−ｂａｄｓｔｏｒｅ−１）で起こる。そのログデータは今や上書きされ、回復することはできない。ログを破損させたメモリストアは、それ自体が、メモリ変更レコード（Ｘ１３ｅ−ｍｃｈｇ−１）を用いてロギングされている。完了ログチャンク（Ｘ１３ｅ−ｌｏｇ−２）において、データは最新から最古まで消費され、それはつまり、それ自体の破損（Ｘ１３ｅ−ｂａｄｓｔｏｒｅ−２）に遭遇する前に、消費者が不良ストア（Ｘ１３ｅ−ｍｃｈｇ−２）の指示に遭遇することを意味する。データの消費者は、したがって、破損ポイント（Ｘ１３ｅ−ｂａｄｓｔｏｒｅ−２）におけるログが使用不能であると判断することができ、破損データに到達する前に、ログデータの処理を停止することができる。消費者はまた、プログラマにエラーを知らせることができる。
１つのログによって書かれたログデータがシステムの他の部分による読み取りについて利用可能とされないことを保証することは、セキュリティ目的または他の理由のために有利であり得る。そのために、実施形態ではリサイクルされる前に、単一化ログは各チャンクをクリアすることができる。ＣＰＵの能力が十分である実施形態では、仮想アドレス空間へマッピングされるチャンク上のアクセス権を「書き込み専用」に設定することができる。
実施形態では、（「ログポインタレジスタ」と称され得る）ＣＰＵレジスタを、ログポインタとして指定することができる。このような実施形態では、ログへの書き込みに使用されるインストルメント化命令は、ＣＰＵによってサポートされている場合、プリインクリメント、ポストインクリメント、プリデクリメント、および／またはポストデクリメントストア命令を含むことができる。このような命令は、単一の命令でのログへの書き込みおよびログポインタ更新により、パフォーマンスを向上させてインストルメント化フットプリントを削減することができる。
実施形態では、アプリケーションバイナリインタフェース（ＡＢＩ）または別のそのようなコーディング規則を、ログポインタレジスタがロギング使用のために予約されるように定義され得る。このような実施形態では、コンパイラ、アセンブラおよび他のコード生成ツールは、非ロギング目的のためにログポインタレジスタを使用することを許されないであろうことから、したがってログポインタレジスタがロギング目的のためにすぐに利用可能であることが保証される。このようにログポインタレジスタを予約すると、ログに書き込むために必要な命令の数を減らすことにより、パフォーマンスが向上し、インストルメント化フットプリントを削減することができる。
実施形態では、ＪＩＴ（ジャストインタイム）コンパイラまたはインストルメント化を付加するプリプロセシングパスなどの、コンパイル後にインストルメント化を追加するコンポーネントは、非ロギング目的のためにログポインタレジスタを使用しないように、および／または、ロギング目的のために必要とされる場合はログポインタレジスタを使用できるように、および／または、ログポインタレジスタの代わりに１つ以上の他のレジスタを使用するように、コードを書き換えることができる。このようにログポインタレジスタを予約すると、ログに書き込むために必要な命令の数を減らすことにより、パフォーマンスが向上し、インストルメント化フットプリントを削減することができる。
実施形態では、ＣＰＵレジスタを使用する代わりに、ログポインタレジスタとしてメモリ位置を使用し得る。ログポインタレジスタとしてメモリ位置を使用すると、ストア命令についてのターゲットとしてメモリ位置からメモリ位置またはオフセットを用いることをサポートするＣＰＵ上で有利であり得る。このような場合、実施形態は、ＣＰＵレジスタを予約するオーバーヘッドなしで（上記のような）予約されたログポインタレジスタの利点のいくつかまたはすべてを得られ得る。このようなオーバーヘッドには、コードサイズ増加、および／またはＣＰＵレジスタの使用不能に起因するコードパフォーマンス低下が含まれる可能性がある。様々な実施形態では、ログポインタレジスタとして使用されるこのようなメモリ位置をシステム全体で共有することができ、または、アドレス空間ごとに、または実行のスレッドごとに、またはログごとに、別個のログポインタレジスタメモリ位置が存在する可能性があり、または、ログポインタレジスタメモリ位置が別の方法で割り当てられる可能性がある。
いくつかの実装では、単一化ログは、本明細書に記載されるように、多くの利点を有することができる。例えば、単一化ログを構成することは、それをメモリの１つ以上のプールを割り当てる必要があるのみであり、セットアップおよび使用が非常にシンプルとなる。単一化ログは、ログに書き込む実行のスレッドごとに別個の現在のチャンクを維持することができ、それにより、共有リソースについてのスレッド間の競合が低く維持され、このような単一化ログは効率的となり、多数のログおよび大量のログプールメモリに対してスケーラブルとなる。単一化ログは、チャンクを各ログに動的に配分および再配分することができ、書き込まれることがない、または使用されないデータが書き込まれるメモリの量を最小化する。
《キャッシュ管理》
いくつかの実施形態では、改善バックエンドは、コンピュータプログラムに挿入されるインストルメント化がＲＡＭ内のログにデータを挿入することができる、本明細書に記載のロギング機構などの１つ以上の機構を含むことができる。システムのＣＰＵアーキテクチャおよびキャッシュの構造に依存するが、このようなログにログデータを書き込むと、プログラムデータがキャッシュから削除される可能性があり、アプリケーションプログラムのより遅いランタイムパフォーマンスとなってしまう。キャッシュ使用量を管理するための様々な技術により、改善バックエンドがこのパフォーマンスへの影響を軽減または解消することを可能にし得る。
ＣＰＵアーキテクチャおよびキャッシュ構造には、ＣＰＵメモリ管理ユニット（ＭＭＵ）の構成を介して、および／または、コンピュータプログラムにおける特別な命令を使用することによって、または、他の方法によって、特定のストアについてのキャッシュの無効化を可能にするものがある。実施形態では、改善バックエンドは、ログメモリへのストアのキャッシュを無効し、キャッシュへのログストアの影響を低減または解消する。
実施形態では、コンパイラは、ターゲットシステムのプロセッサのキャッシュ（複数可）を操作する命令を生成するように構成されている。命令は、トレースバッファへのトレースデータの将来の書き込みについてキャッシュ（複数可）を準備することができ、それにより、これらの書き込みは、効率的に、かつターゲットプログラムの実行への影響を最小限に抑えて行われる。例えば、命令は、トレースログへの予想される将来の書き込みについてキャッシュでの空間を、割り当ておよび／または予約することができる。本実施形態では、トレースログへの将来の書き込みを予測してそれに応じてキャッシュまたはメモリ内の空間を割り当て／予約することによって、本明細書に開示されたシステムは、ターゲットプログラムによってキャッシュに保存されたデータがトレースログ書き込みにより追い出されないことを確実にするために（キャッシュラインのサブセットなどの）キャッシュのサブセットにトレースログへの書き込み動作の影響を制限するように構成されることができる。ターゲットプログラムの実行に干渉および／またはそれを遅くしないように、命令は、インストルメント化の結果としてのキャッシュへの影響を追加的または代替的に低減することができる。
実施形態では、必要な機能を伴うＣＰＵアーキテクチャ上で、改善バックエンドによって挿入されたインストルメント化は、間隔をおいて、キャッシュを操作するための命令を含むことができる。インストルメント化によるログメモリの使用が非常に予測しやすい傾向にあり、例えば最低から最高へと順に各ログアドレスに保存されると考えると、そのようなキャッシュ操作命令は、プログラムメモリについてのキャッシュの利用可能性を最大化するように挿入されることができる。
例えば、キャッシュからメモリの特定の範囲をフラッシュするようプログラムがＣＰＵに命令することが可能なＣＰＵアーキテクチャ上で、改善バックエンドによって挿入されたインストルメント化は、ログメモリを含むキャッシュライン数をできるだけ１に近い状態に維持するために、間隔をおいて、最近書き込まれたログメモリをキャッシュからフラッシュする命令を含むことができる。キャッシュが所与のメモリ位置について複数の可能な位置を有する場合には、キャッシュを「マルチウェイ」キャッシュと称することができる。ログメモリが使用するキャッシュラインの定期的フラッシングのおかげで、マルチウェイキャッシュにおける１以下のウェイがログメモリのために使用されることを保証することにより、ランタイムパフォーマンスを劇的に向上させることができ、残りのウェイをキャッシュプログラムメモリに利用可能なままとすることができる。
別の例では、ＣＰＵアーキテクチャにより、メモリの内容を最初にキャッシュにフェッチすることなく、メモリの特定の範囲についてキャッシュラインを予め割り当てるようプログラムがＣＰＵに命令することができる。このような命令を使用することにより、そのメモリの現在の内容がすぐに上書きされるであろうことをプログラムがＣＰＵに通知し、これによりＣＰＵは不要な作業を避けて、メモリの現在の内容をキャッシュにコピーする通常のステップをスキップすることによりメモリバス競合を減らすことができる。そのような機能を有するＣＰＵアーキテクチャ上では、改善バックエンドによって挿入されたインストルメント化は、メモリはすぐに上書きされるのでメモリの内容を最初にフェッチすることなく、間隔をおいて、書き込まれるログメモリの次のセクションについてキャッシュラインを予め割り当てる命令を含むことができる。ログメモリによる使用のためにキャッシュラインを定期的に予め割り当てることにより、ログメモリをキャッシュにコピーするＣＰＵの必要性を最小化することによってランタイムパフォーマンスを劇的に向上させることができる。
いくつかの実施形態において、キャッシュフラッシュ命令およびキャッシュ事前割当命令は集合的に、とりわけ、キャッシュ操作命令と呼ぶことができる。本明細書に記載のキャッシュ操作命令があまりにもまれにしか実行されない場合は、キャッシュ操作の潜在的利点は失われる可能性があり、プログラムデータに利用可能なキャッシュラインは少ないままとなり、ランタイムパフォーマンスを低減させる。本明細書中に記載のキャッシュ操作命令があまりにも頻繁に実行される場合は、ＣＰＵ時間が不必要にキャッシュ操作命令を実行して無駄になる。プログラムへと改善バックエンドによって挿入されたインストルメント化がキャッシュ操作命令を含む場合、改善バックエンドにおけるコンパイラは、このようなキャッシュ操作命令の適切な配置を決定するためのコードフロー解析を使用することができる。例えば、このようなコンパイラは、ログに書き込まれたログデータに対して各キャッシュラインにつき１回、プログラムがキャッシュ操作（複数可）を実行するために、このようなキャッシュ操作命令を挿入することができ、それによってパフォーマンスゲインを最大にする。
実施形態では、コンパイラは、次のようにキャッシュ操作命令の適切な配置を決定するために、コードフロー解析を行うことができる。コンパイラを、ターゲットＣＰＵのキャッシュラインサイズを決定するように構成することができる。コンパイラは、各基本ブロックにおけるインストルメント化によってログに書き込まれたバイトの数を追跡し続けるように構成されることができる。基本ブロック内において、書き込まれた合計ログデータがＣＰＵキャッシュラインサイズに等しいインストルメント化が挿入されるたびに、コンパイラは、適切なキャッシュ操作命令（複数可）を挿入するように構成されることができる。実施形態では、コンパイラは、各基本ブロックの先行ブロックを決定するようにさらに構成されることができ、「先行ブロック」は、その実行が当該ブロックの実行の直後に行なわれることができる基本ブロックとして定義することができる。基本ブロックをコンパイルする場合、コンパイラは、問題のブロックの実行につながる可能性のある各実行パスをトレースするために先行ブロック情報を使用することができる。そのような各実行パスについて、コンパイラは、最後のキャッシュ操作以降にログに書き込まれたバイトの最大可能数を決定することができ、これは「ブロックエントリにおけるワーストケースキャッシュライン消費量」と呼ぶことができる。ブロックエントリにおける最大ワーストケースキャッシュライン消費量が現在の基本ブロックにつながる各コードパスについて計算されると、コンパイラは、ワーストケースキャッシュライン消費量（ブロックエントリにおけるワーストケースキャッシュライン消費量とブロックの開始以降にログに書き込まれたデータとの和）がキャッシュラインサイズに等しいブロック内のポイントにおける現在のブロックのキャッシュ操作命令を挿入することができる。このようなアルゴリズムにより、データに対する１以下のキャッシュラインが最後のキャッシュ操作以降にログに書き込まれることが保証される。
図２８は、このようなコードフロー解析の例を示している。図は、コンパイル中のプログラムにおける基本ブロック（ブロックＡ）、その直接の先行ブロック（ブロックＢ、ブロックＥ）、およびブロックＢの先行ブロック（ブロックＣ、ブロックＤ）を示している。改善バックエンドにおけるコンパイラは、どこであれキャッシュ操作命令を挿入するためのブロックＡにおける位置を決定しようとする。例では、キャッシュラインサイズが３２バイトである。ブロックＣからブロックＢへのそしてブロックＡへのパスにおいて、ブロックＡへのエントリにおけるワーストケースキャッシュライン消費量は、（ブロックＢにてロギングされた）８バイトと（ブロックＣの最後のキャッシュ操作の後にロギングされた）１６バイトとの和であり、すなわち合計２４バイトである。ブロックＤからブロックＢへのそしてブロックＡへのパスにおいて、ブロックＡへのエントリにおけるワーストケースキャッシュライン消費量は、（ブロックＢにてロギングされた）８バイトと（ブロックＤの最後のキャッシュ操作の後にロギングされた）２０バイトとの和であり、すなわち合計２８バイトである。ブロックＥからブロックＡへのパスにおいて、ブロックＡへのエントリにおけるワーストケースキャッシュライン消費量は、（ブロックＥの最後のキャッシュ操作の後にロギングされた）２４バイトである。したがって、すべてのパスからブロックＡへのエントリにおけるワーストケースキャッシュライン消費量は、各パスについてのキャッシュライン消費量の最大値であり、２８バイトである。キャッシュラインサイズからこの最大値を減算することにより、コンパイラは、ブロックＡにおけるキャッシュ操作命令の適切な配置が、ブロックＡ後ログの３２バイト−２８バイト、すなわちブロックＡ後ログの４バイトであると計算することができる。
いくつかの実施形態において、本明細書に記載されるようにキャッシュ操作およびコードフロー解析を適用することによって可能となるランタイムパフォーマンスゲインは、プログラム挙動、ＣＰＵキャッシュアーキテクチャ、および他の多くの要因に依存して、かなり変化する。しかし、２倍、３倍、５倍、またはそれ以上のランタイムパフォーマンスの向上は珍しいことではない。実施形態では、コンパイラは、利点がある可能性がある場合にのみ、キャッシュ操作命令を挿入および／またはコードフロー解析を実行するように構成されることができる。例えば、コンパイラは、キャッシュアーキテクチャが多くの利益を与えないであろうＣＰＵについてコンパイルする時には、キャッシュ操作命令を挿入しないように構成されることができる。
以下は、ＰｏｗｅｒＰＣのＣＰＵにおいてインストルメント化コードに挿入されたキャッシュ操作命令の一例である。
；次の例では、ｒ１５が、書き込まれる次のログ位置をポイントする。
ｌｉ ｒ１７，０ｘ４０；「ｄｃｂａｌ」命令の準備
ｄｃｂａｌ ｒ１５，ｒ１７；「データキャッシュブロック割り当て」が
；前の命令とともに、その内容をプリフェッチせずに、
；次のキャッシュラインがログに割り当てられることを確保する
ｌｉ ｒ１７，０ｘｆｆｆｆｆｆｃ４；「ｄｃｂｆ」の準備命令
ｄｃｂｆ ｒ１５，ｒ１７；「データキャッシュブロックフラッシュ」
；前の命令とともに、最も近い時点で書かれたログの
；セクションをキャッシュからフラッシュし、よってそれは
；再利用され得る。
ｌｉｓ ｒ１７，０ｘ１００；「ｓｔｗｕ」の準備
ａｄｄｉ ｒ１７，ｒ１７，０ｘ１６４；「ｓｔｗｕ」の準備
ｓｔｗｕ ｒ１７，４（ｒ１５）；いくつかの実際のデータロギングを実行
《ロギングされたデータの収集》
実施形態では、改善バックエンドは、最新から最古までのロギングされたデータを収集する。所与のレコードの解釈が以前にロギングされたレコードに依存しないようにロギングされたデータが構成されている場合には、改善バックエンドは時間走行デバッガユーザインタフェースへの検索時にすぐに、収集されたデータを利用可能にすることができ、プログラマは、収集されるとすぐにデータの解析およびデバッグを開始することができる。より多くのデータが収集されると、すべてのデータが収集されるまで、それはプログラマに利用できるようになる。
デバッグ用データの利用可能性が図１９に示される。図示の例では、ロギングされたデータの収集は、ログの終わり（Ｘ５０１）で始まり、後に記録されるデータから以前に記録されたデータに向かって進む。収集されたデータの領域（Ｘ５０２）は、ロギングされたデータの継続的な検索（Ｘ５０５）のために時間をかけて成長する。デバッグに利用可能なデータの領域（Ｘ５０４）は、収集されたデータの領域（Ｘ５０２）と同じであることに留意されたい。すべてのデータが収集されるまで、データ検索は継続し、まだ収集されていないデータの領域（Ｘ５０３）がなくなると、その時点でログ全体からのデータがデバッグに利用可能となる。このようにデータをデバッグ用に利用可能にすることにより、典型的にはデバッグについて最も関心のある、後に記録されたデータをまず、プログラマに利用可能にすることができる。収集されるとすぐにデータはプログラマに利用可能となることができるため、最新データを解析およびデバッグする前にプログラマが待機しなければならない時間は、収集されるデータの合計量には依存せず、大規模なトレースログを任意に使用することが実用的となる。
《複数ログからのデータマージ》
改善バックエンドは、いくつかの実施形態による複数ログへとデータをロギングすることができる。複数ログにロギングされたデータはマージされて、全体として解析されることができる。複数ログへのロギングにより、複数の実行のスレッドを有するシステムにおいて、より効率的なロギングが可能となり、ロックなどの競合処理機構を必要とせずともよい。複数ログからロギングされたデータをマージすることにより、ＳＭＰシステム、および、実行のスレッドが同時に実行されてメモリを共有し得る他の構成のデバッグが可能になる。複数ログからロギングされたデータをマージすることにより、分散システム、および実行のスレッドが同時に実行されるがメモリを共有しない他の構成のデバッグが可能になる。複数ログからロギングされたデータをマージすることにより、異なるタイプおよび／またはアーキテクチャの複数のＣＰＵを有するもの、メモリを共有するおよびしない同時に実行される実行のスレッドの任意の組み合わせを有するもの、または、ＣＰＵが共有メモリによってまたはメッセージパッシングによってまたは他の手段によって互いに通信するもののなどの複雑なシステムのデバッグが可能になる。
いくつかの実施形態では、改善バックエンドは、１つ以上のマージされたログに複数ログからのデータをマージすることができる。改善バックエンドは、各ログから処理するべき次のレコードを読み出して、マージされたログに次のものを挿入するのに論理的に最も適切であるのはそれらのレコードのどれであるかを決定することにより、複数ログからのデータをマージする。レコードがマージされたログに挿入されると、それはもはやマージ用とは考えられず、そのログから処理されるべき次のレコードが代わりに考慮される。レコードは、同じ時系列順に各ログから考慮されるので、よって例えば、改善バックエンドが逆時系列順にログデータを処理している場合、マージ処理中に、各個々のログの記録は逆時系列順に考慮される。
異なるソースからのログデータをマージすることの例が図２０に現れている。図の左側は、３つの異なるソースによって記録されたログである。例では、ログデータは、最新（後で記録されるデータ）から最古（以前に記録されたデータ）まで収集される。検討中の次のレコード（Ｘ６０１，Ｘ６０２，Ｘ６０３）が、まだ各データソースからマージされていない最新のレコードである。例では、ソース＃２からの最も近い時点でのレコード（Ｘ６０２）がマージされる次のレコードであり、したがってマージされたログ（Ｘ６０４）に付加されると決定されている。これが行われると、ソース＃２からの最も近い時点でのレコード（Ｘ６０２）が、すでにマージされたデータ（Ｘ６０５）の一部とみなされ、もはやマージの候補になることはないであろう。プロセスが次に繰り返されるときを考慮すれば、Ｘ６０２の直前のレコードが、ソース＃２からの最も近い時点でのレコードとなるであろう。
マージ処理中に、改善バックエンドは、マージされたログに次に挿入するのに論理的に最も適切であるレコードがどれであるかを決定する際に（「順序付け技術」と称され得る）多くの異なる技術のうちの１つ以上を採用し得る。論理的に最も適切な順序とは典型的には、マージされたログにおいてレコードが論理的に狂った順序で発生しない順序である。例えば、マージされたログにおいて時系列的に先に現れるレコードが、その対応するレコードがマージされたログにおいて時系列的に後で現れるイベントによって引き起こされるイベントを表す場合に、２つのレコードを論理的に狂った順序であると考えることができる。なお、複数ソースからのログデータの任意の所与のボディについて、論理的に狂った順序であるレコードを含まない多くの順序付けが存在し得る。「同期イベント」とは、複数ソースからのデータを順序付けする際にシーケンスが重要となるイベントを指し得る。例えば、対応するレコードがマージされたログ内のそれらの相対的配置によって狂った順序となる可能性があるのであれば、２つのイベントは同期イベントである。同期イベントには、ＣＰＵ間の通信イベント、オペレーティングシステムイベント、ミューテックスまたは他の同期プリミティブ上のアクションが含まれるが、これらに限定されない。
１つの順序付け技術は、データの様々な部分がロギングされた順序を明示的に説明する１つ以上のログに記録されたメタ情報を使用することである。例えば、カーネルおよびアプリケーションが単一ＣＰＵを共有する場合、カーネルはそのログに、制御がアプリケーションとの間で転送される時点と、転送時点でアプリケーションによって書き込まれたログの量を記録することができる。この例では、この情報を、カーネルおよびアプリケーションによってロギングされたデータの論理的に最も適切な順序付けを決定することができる順序付け技術への入力として使用することができる。この順序付け技術の例が図２１Ａである。ソース＃１からデータは、データ領域（Ｘ７ａ−Ｓｒｃ２−１）のソース＃２によって、それぞれロギングの開始（Ｘ７ａ０１）およびロギングの終わり（Ｘ７ａ０２）を表すメタデータレコードを含む。このメタデータを使用して、順序付け技術は、マージされたログにおけるソース＃１からのデータ領域（Ｘ７ａ−Ｓｒｃ１−１−ｍｅｒｇｅｄおよびＸ７ａ−Ｓｒｃ１−２−ｍｅｒｇｅｄ）間に、ソース＃２からのデータ（Ｘ７ａ−Ｓｒｃ２−１−ｍｅｒｇｅｄ）を正しく挿入することができる。この例では、メタデータレコードは、２つの異なるレコード（Ｘ７ａ０１およびＸ７ａ０２）として表されているが、実施形態では、メタデータは、１つ以上のレコードで表すことができる。この例では、メタデータレコード（Ｘ７ａ０１およびＸ７ａ０２）がマージされたログから省略されているが、実施形態では、メタデータはマージされたログに含まれても含まれていなくともよい。
別の順序付け技術は、同期イベントを表す特定のレコードにタイムスタンプすることである。このようなタイムスタンプが単一のクロックからまたは十分に同期される複数のクロックから生成される場合、これらのタイムスタンプは、最高または最低のタイムスタンプを伴うレコードを選択することにより、ログが読み出される方向に応じて、順序付けのために使用することができる。タイムスタンプ順序付け技術の例が図２１Ｂに表示される。ソース＃１からの次のレコード（Ｘ７ｂ−Ｓｒｃ１−１）のタイムスタンプ（１００２）が、ソース＃２からの次のレコード（Ｘ７ｂ−Ｓｒｃ２−１）のタイムスタンプ（１０００）よりも大きいと考えると、順序付け技術は、マージされたログにおいてソース＃２からのレコード（Ｘ７ｂ−Ｓｒｃ２−１−ｍｅｒｇｅｄ）がソース＃１からのレコード（Ｘ７ｂ−Ｓｒｃ１−１−ｍｅｒｇｅｄ）の前に現れなければならないと決定することができる。
さらに別の順序付け技術は、他の同期イベントに対してその順序を決定するために用いることができるシリアルナンバまたは他のそのような識別子を伴う特定の同期イベントをタグ付けすることである。例えば、１つのＣＰＵから別のＣＰＵに送信されたメッセージが１つのログにおけるメッセージ送信レコードおよび別のログにおけるメッセージ受信レコードとなり、両方のレコードがそのメッセージに一意である識別子を含む場合、順序付け技術は、マージされたログ内のレコードを順序付けするためには送信イベントが受信イベントに先行している必要があるとの知識を使用することができる。シリアルナンバ順序付けの例が図２１Ｃに表示される。レコードＸ７ｃ−Ｓｒｃ１−１がシリアルナンバ＃２００を伴うメッセージの受信を表し、レコードＸ７ｃ−Ｓｒｃ２−１がシリアルナンバ＃２００を伴うメッセージの送信を表すと考えると、順序付け技術は、送信が受信に先行している必要があり、したがって、マージされたログにおいてレコードＸ７ｃ−Ｓｒｃ２−１−ｍｅｒｇｅｄがレコードＸ７ｃ−Ｓｒｃ１−１−ｍｅｒｇｅｄに先行している必要があると決定することができる。
さらに別の順序付け技術は、マージされたログにおいてレコードが論理的な順序で現れることを保証するために、プリイメージおよびポストイメージデータなどのログからのデータを使用することである。例えば、連続して実行される２つの異なるスレッドによって共有メモリ位置が書き込まれ、プリイメージおよびポストイメージが両方のスレッドのストアについて既知であり、１つのストアのプリイメージおよび他のストアのポストイメージが一致する唯一の順序付けが存在する場合、順序付け技術は、マージされたログにおいて対応するメモリストアレコードを正しく順序付けするために、この情報を使用することができる。データベース順序付けの例が図２１Ｄである。例では、２つの異なるソースからのレコード（Ｘ７ｄ−Ｓｒｃ１−１，Ｘ７ｄ−Ｓｒｃ２−１）が、共有変数「ｘ」に対する変更を表す。ソース＃１からのレコード（Ｘ７ｄ−Ｓｒｃ１−１）は、３とのプリイメージ値（レコードにおいて表される修正前の「ｘ」の値）、および４とのポストイメージ値（レコードにおいて表される修正後の「ｘ」の値）を含む。ソース＃２からのレコード（Ｘ７ｄ−Ｓｒｃ２−１）は、２とのプリイメージ値および３とのポストイメージ値を含む。したがって例では、データベース順序付け技術は、レコードＸ７ｄ−Ｓｒｃ２−１−ｍｅｒｇｅｄがマージされたログにおいてＸ７ｄ−Ｓｒｃ１−１−ｍｅｒｇｅｄに先行する必要があると決定することができ、これは、Ｘ７ｄ−Ｓｒｃ２−１−ｍｅｒｇｅｄのポストイメージ（３）がＸ７ｄ−Ｓｒｃ１−１−ｍｅｒｇｅｄのプリイメージ（３）と一致する一方、（２とのプレイメージを伴うＸ７ｄ−Ｓｒｃ２−１−ｍｅｒｇｅｄの前に４とのポストイメージを伴うＸ７ｄ−Ｓｒｃ１−１−ｍｅｒｇｅｄを配置する）逆順序付けでは、前のレコードのポストイメージと後のレコードのプリイメージとの論理的対応が得られないからである。
《メモリ再構成》
改善バックエンドは、いくつかの実施形態によれば、ログに表される任意の時点におけるターゲットプログラムのメモリの状態を再構成することができる。プリイメージデータを含む以前に記録されたメモリ変更レコードを使用して、次のようにターゲットプログラムのメモリ状態を再構成することができる。
実施形態では、改善バックエンドは、所与の時間におけるターゲットプログラムのメモリの状態の表現を維持する。最初は、この状態はライブターゲットプログラムからコピーされ得る。
例えば、トレースログは、ゼロ以上のメモリ変更レコードを含み得る。このような各メモリ変更レコードは、改善バックエンドがどのメモリ範囲が修正されたかを決定することができる十分な情報、および、（メモリ修正が行われる前にそのメモリ範囲に存在した値などの）「プリイメージ」値を含み得る。実施形態では、メモリ変更レコードはまた、ポストイメージ値を記憶するために予約された空き空間を含む。
実施形態では、改善バックエンドがメモリ変更レコードの前に初めてメモリを再構成するときに、その位置のデバッガの表現における現在の値がポストイメージを保存するための予約空間にコピーされ、プリイメージ値がその位置のデバッガの表現へとログからコピーされる。これは、メモリ変更レコードに表されるメモリ変更の直前にターゲットプログラムのメモリ状態を再現する効果がある。ログからの連続したメモリ変更レコードで上記を繰り返すことによって、改善バックエンドは、プログラムの元の実行中に連続するますます以前のポイントにおけるプログラムのメモリ状態を再構成し得る。実施形態では、ポストイメージがメモリ変更レコードに既に存在する場合、改善バックエンドが既にポストイメージを保存しているため、または、それが他の手段によって決定されているため、ログにポストイメージをコピーすることを省略し得る。
実施形態では、このプロセスは、連続する後の時点にプログラムのメモリ状態を移動するために逆転される。具体的にはデバッガは、保存されたポストイメージをメモリ変更レコードから関連位置のデバッガの表現にコピーして、メモリ変更レコードによって表される修正の直後にプログラムのメモリ状態を再構成し得る。ログからの連続したメモリ変更レコードで上記を繰り返すことによって、改善バックエンドは、プログラムの元の実行中に連続するますます後のポイントにおけるプログラムのメモリ状態を再構成し得る。
図１５Ａ、図１５Ａ、図１５Ｃおよび図１５Ｄはメモリ再構成の例を示す。示されているように、ログにおけるメモリ変更レコード（Ｘ１００）は、アドレスおよびプリイメージを含み、空間がポストイメージについてのログにおいて予約されているが、そこには何もまだ書かれていないので、値は未定義である。その位置についてのシミュレートされたメモリ（Ｘ１０１）は、初期値「４」を含む。
ログエントリに記録されたメモリ変更（Ｘ１００）前のターゲットのメモリ状態を再構成するために、シミュレートされたメモリ内の現在の値はまず、予約されたポストイメージ空間にコピーされる（Ｘ１０２）。次いで、プリイメージはシミュレートされたメモリにメモリ変更レコードからコピーされる（Ｘ１０３）。今や、シミュレートされたメモリ（図１５Ｂ、Ｘ１０４）は、メモリ変更レコード前のターゲットの状態を表し、メモリ変更レコード（Ｘ１０５）は、その変更に関連付けられたプリイメージおよびポストイメージの両方を含む。
時間的に前方に移動すると、ログエントリに表されるメモリ変更（Ｘ１０５）の後にターゲットのメモリ状態を再構成することにより、改善バックエンドはシミュレートされたメモリ（Ｘ１０４）へのメモリ変更レコードからポストイメージをコピーする（Ｘ１０６）。今や、シミュレートされたメモリ（図１５Ｃ、Ｘ１０７）は今一度、メモリ変更後のターゲットプログラムの状態を表す。このポイントでメモリ内に表される状態（Ｘ１０７）は、初期状態（図１５Ａ、Ｘ１０１）に一致することに留意されたい。
時間的に後方に移動すると、ログエントリに表されるメモリ変更（図１５Ｃ、Ｘ１０８）の前にターゲットのメモリ状態を再構成することにより、改善バックエンドはシミュレートされたメモリ（Ｘ１０７）へのメモリ変更レコードからプリイメージをコピーする（Ｘ１０９）。以前に行っているので、メモリ変更レコードのポストイメージを埋め込む必要はない。今や、シミュレートされたメモリ（図１５Ｄ、Ｘ１１０）は今一度、メモリ変更前のターゲットプログラムの状態を表す。このポイントでメモリ内に表される状態（Ｘ１１０）は、改善バックエンドが初めてメモリ変更レコードを交差させた後の状態（図１５Ｂ、Ｘ１０４）と一致することに留意されたい。
図１６は、ログが多数のメモリ変更レコードを含む場合に異なる時点でのターゲットのメモリ状態を再構成するためにこのような技術をいかに使用することができるかの例を示している。この例では、メモリ変更レコードは、図中で古いレコードの右側に新しいレコードが現れる時系列順にログに記録されている。メモリ変更レコード（Ｘ２０１、Ｘ２０２、Ｘ２０３）間の各ギャップは、以前のメモリ変更（図のギャップの左側に現れる）がすでに起こり、後のメモリ変更（図のギャップの右側に現れる）はまだ発生していない、ターゲットプログラムの実行中のポイントを表す。図１６のギャップによって表される任意の所与の時点から出発して、改善バックエンドは、図１５Ａ〜Ｄで実証されているものなどの技術を適用することによって、時間的に前または後のいずれかで隣接ギャップに移動することができる。繰り返しそのような移動を行うことで、改善バックエンドは、ログに表される任意の時点におけるターゲットプログラムのメモリの状態を再構成することができる。
実施形態では、プリイメージおよびポストイメージを、メモリ変更レコード内の同じ位置に保存することができる。このような実施形態では、プリイメージおよびポストイメージは、単一の「メモリイメージ」位置に保存される。メモリ変更レコード内のメモリイメージ位置は、現在の再構成時点がメモリ変更レコードの前または後のいずれに発生したかに応じて、プリイメージまたはポストイメージのいずれかを含むことができる。現在の再構成時点が所与のメモリ変更レコードの後であれば、メモリ変更レコード内のメモリイメージ位置は、プリイメージを含む。メモリ変更レコードにわたって時間的に後方に再構成するとき、メモリイメージ位置の内容が再構成メモリ内の対応する位置の内容とスワップされ、したがってメモリイメージ位置の値をポストイメージに変換する。メモリ変更レコードにわたって前方に再構成するとき、同一のスワップ動作がメモリイメージ位置の値をプリイメージに変換し戻す。ポストイメージについてログ内で空間を予約する必要がないので、より効率的にログ空間を使用するという点で、このような技術は有利である。
《ベースラインメモリイメージ》
メモリ変更レコードは、本明細書に記載されるように、いくつかの実施形態では、メモリ状態の漸進的変化を表すことができる。それら自身によりそのような変化を解析することによって、改善バックエンドは経時的に変化するメモリ位置の内容を再構成することができる。デバッグ中のシステムのメモリの完全なイメージを作成するために、改善バックエンドは、既知の時点でのシステムのメモリの一部またはすべての内容を含むベースラインイメージを使用することができる。改善バックエンドは、ベースラインイメージから始まって、メモリ変更レコードを使用してメモリを再構成する以前に記載された技術、または同様の技術を用いて、時間的に前または後にメモリを再構成することができる。そのようなベースラインイメージは、システムメモリの単一スナップショットであることができ、または、それは、同時にまたは異なる時間に撮られた複数のスナップショットを含むことができる。ベースラインイメージは、ログによってカバーされる任意の時間に由来することができる。
実施形態では、システムは、デバッグのために停止され、改善バックエンドは、ベースラインイメージとしてシステムメモリ自体を使用する。改善バックエンドは、システムのメモリからメモリ状態をすべて一度に、または必要に応じてセクションでダウンロードすることができる。ターゲットプログラムメモリが任意に大きく、プログラマが任意の時間量でデバッグを開始するのを遅らせる可能性があるので、ターゲットプログラムメモリをすべて一度にダウンロードすると非効率的である可能性がある。実施形態では、改善バックエンドは、必要に応じて一度にプログラムメモリのセクションをダウンロードすることができ、デバッグを開始するのに必要な時間をバウンディングする。デバッグのために停止している間にシステムがどのような挙動を有するかによって、システムが停止状態にある間にメモリが変化し続けることが可能であり得、その場合に、改善バックエンドは、メモリが変更中の間であっても、例えば後のセクションで記述されるようなメモリ整合性技術を使用することによりメモリイメージの整合性を確実にする様々な技術を採用することができる。
実施形態では、改善バックエンドは、ベースラインとして（「コアダンプ」と称され得る）システムメモリの以前に保存されたイメージを使用することができ、このようなコアダンプは、エラーの結果として、ユーザの要求によって、または他のいくつかの理由によってのいずれであっても作成される。そのようなコアダンプは、メモリイメージ単独で構成することができ、または、レジスタ状態情報、実行のスレッドに関する情報、および／または仮想メモリマッピングに関する情報を含むがこれらに限定されない他の有用なデータを含むことができる。実施形態では、改善バックエンドによって収集されたログデータをメモリに保存することができ、またはコアダンプイメージと併せて別様に利用可能であり、改善バックエンドを採用する時間走行デバッガが、コアダンプが生成された時点に至るまでのアプリケーションの実行履歴をステップスルーすることができる。このように、改善バックエンドは、デバッグの非常に強力なモデルを可能にし、エラーの検出、またはユーザの要求、またはいくつかの他の条件によりコアダンプイメージの生成が得られる。そのようなコアダンプイメージは、所定の箇所にて解析され、後の収集のために保存され、ならびに／または、記憶および／もしくは解析のために別の位置に送信されることができる。改善バックエンドを採用する時間走行デバッガはそして、そのようなコアダンプイメージを解釈することができ、プログラマがコアダンプイメージが撮られたシステムの「ポストモーテム」デバッグを実行することができる。ポストモーテムデバッグは、コアダンプに含まれる情報、またはプログラムが停止した後にアクセス可能であり、あるいは、もはや別様に実行されない情報のいくつかの他のソースに基づいて、１つ以上のプログラムのデバッグを参照することができる。このようなポストモーテムデバッグは、改善バックエンドで行われた場合、コアダンプに至るモーメントにおけるシステムの状態の再構成、システムの実行履歴のステップスルー、および実行についての様々な種類の解析の実行を含むがこれらに限定されない改善バックエンドの機能を含むことができる。
実施形態では、改善バックエンドは、コピーバックエンドによって採用されるものなどのコピー技術を使用して保存されたメモリのイメージを使用することができる。
《メモリが変更されているときのメモリイメージ整合性維持》
改善バックエンドが、ベースラインメモリイメージの構築のために、またはなんらかの他の目的のために必要な時に一度に１つのプログラムメモリのセクションをダウンロードする実施形態では、プログラムメモリの内容が２つのセクションのコピー間隔を変更することが起こり得、プログラムのメモリの不整合イメージとなってしまう。いくつかの実施形態は、この問題を緩和するために（本明細書に記載の）同期実行制御などの実行制御戦略を採用することができる。しかし、採用される実行制御戦略または他の理由により、改善バックエンドがこのようなプログラムメモリのダウンロードを開始した後にプログラムメモリが修正されないことを保証しない実施形態では、改善バックエンドは、プログラムのメモリの整合性のあるイメージを保証するために、本明細書に記載されるものなどの技術を使用することができる。
実施形態では、改善バックエンドは、コピーされる各セクションに影響を与えるメモリ修正レコードについてのログをチェックすることができる。そのようなレコードが最初のセクションがコピーされた後に発生したメモリ修正を表す場合、（「後のメモリ変更レコード」と称され得る）そのようなレコードは、コピーされた最初のセクションとコピー中の現在のセクションとの間の不整合を表す。改善バックエンドはそして、コピー中のメモリに対する逆時系列順に、または、以前にコピーされたメモリイメージに対する前方時系列順に、後のメモリ変更レコードを適用するために、先に説明したもののような技術を使用して、メモリ再構成を行うことができる。これは、コピーされたメモリセクションを以前にコピーされたメモリセクションと整合させ、異なる時間にコピーされたプログラムのメモリのセクション間の不整合を解消する。
図２４は、後のメモリ変更レコードの適用例を含む。図示の例では、改善バックエンドは、ロギングされたデータ（Ｘ１０００）を解釈する。ターゲットシステムが実行を停止した場合、改善バックエンドは、ターゲットプログラムが停止した時点（Ｘ１００１）までターゲットが実行している間にロギングされたデータ（Ｘ１００６）の読み出しを始める。ターゲットプログラムが停止した時点（Ｘ１００１）で、改善バックエンドは、ログデータを解釈するのを助けるために、ターゲットからメモリブロック＃１をコピーする。後の時点（Ｘ１００２）で、改善バックエンドは、メモリブロック＃２を必要とし、これをターゲットからコピーする。しかし、メモリブロック＃１がコピーされた時点（Ｘ１００１）とメモリブロック＃２がコピーされた時点（Ｘ１００２）との間に、追加のメモリ変更レコード（Ｘ１００４）がロギングされる。これらは「後のメモリ変更レコード」と呼ばれ、これはターゲットプログラムが停止した後にそれらがロギングされたからである。それらの間の後のメモリ変更レコード（Ｘ１００４）が、メモリブロック＃２の内容がメモリブロック＃１がコピーされた時間以降に変更されているかもしれないことを示すので、改善バックエンドによりなされたメモリブロック＃１および＃２のコピーは、不整合となり得る。メモリブロックの整合性を保つために、改善バックエンドは、メモリブロック＃２の内容に対して逆時系列順にメモリ変更レコード（Ｘ１００４）を適用し、メモリブロック＃１がコピーされた時間（Ｘ１００１）におけるメモリブロック＃２の内容の表現をもたらす。得られたイメージはしたがって、メモリブロック＃１のコピー内容と整合している。さらに後の時点（Ｘ１００３）で、改善バックエンドはターゲットからメモリブロック＃３をコピーする。改善バックエンドは、Ｘ１００５およびＸ１００４における後のメモリ変更レコードをメモリブロック＃３のコピー内容に適用し、メモリブロック＃３のコピー内容をＸ１００１でターゲットからコピーされたメモリブロック＃１の内容と整合させる。このように、改善バックエンドは、ターゲットの実行中にロギングされたデータ（Ｘ１００６）を解釈するために各ブロックが必要な場合にのみターゲットからメモリをコピーし、メモリブロックがコピーされた時にターゲットメモリがポイント（Ｘ１００１，Ｘ１００２，Ｘ１００３）間で変更されているかもしれない場合であっても、改善バックエンドはターゲットメモリの整合したイメージを構築する。
《仮想マッピング》
いくつかの実施形態では、ターゲットシステムのメモリを再構成するとき、改善バックエンドは、仮想メモリアドレス、物理メモリアドレス、またはその両方で動作することができる。改善バックエンドは、仮想アドレスと物理アドレスとの間の関係に関する情報を含む仮想メモリマッピング情報をターゲットシステムから収集することができる。このようなセキュリティモデルをサポートするＣＰＵ上では、改善バックエンドによって収集された仮想メモリマッピング情報は、保護リングに関する情報、およびより少ない特権コードからデータを保護する他の手段を含むことができる。改善バックエンドは、ターゲットシステムのその内部表現を編成するのを助けるために、仮想メモリマッピング情報と他のメモリ保護情報とを使用することができる。例えば、改善バックエンドは、異なる仮想アドレス空間で同じアドレスを区別するために仮想メモリマッピング情報を使用することができ、これは、異なる物理的メモリを表し、したがって異なる値を含むことができる。改善バックエンドは、共有メモリを表すために仮想メモリマッピング情報を使用することができ、そこでは、同じまたは異なる仮想アドレス空間内の異なる仮想アドレスが同じ物理メモリを表している。共有メモリを表すために仮想メモリマッピング情報を用いることにより、改善バックエンドは、任意の特別なインストルメント化または共有メモリへのストアのロギングを提供する改善バックエンドの必要性を排除することができる。
《再構成シミュレーション》
時には、改善バックエンドが、デバッグ中のシステム内の１つ以上のＣＰＵの実際のまたは理論的な挙動を再構成するなど、１つ以上のＣＰＵの命令レベルシミュレーションを実行できるようにすることが有用であり得る。これは再構成シミュレーションによって達成することができる。
再構成シミュレーションについての次の技術は、命令セットシミュレータに依存することができ、これは、初期レジスタ状態とメモリの初期状態とが与えられると、１つ以上のマシン命令が実行された後にＣＰＵ内で起こるであろうレジスタ状態を生成することができる任意の機構である。ソフトウェアシミュレータ、ジャストインタイム（ＪＩＴ）コンパイラ、ソフトウェアおよびハードウェア仮想化機構、およびＣＰＵを含むがこれらに限定されない多くのそのような機構がある。そのような命令セットシミュレータは、ＣＰＵのレジスタセット全体、またはターゲットプログラムが実行されるＣＰＵの挙動を正確に表すのに十分である任意のサブセット上で動作し得る。異なるタイプの複数のＣＰＵを伴うシステムをデバッグする際に、複数の命令セットシミュレータが必要であり得ることに留意されたい。
再構成シミュレーションは、ＣＰＵが行った、または動作し得る歴史的または理論的環境を再現し、なんらかの後の時点でシステムの状態を決定するために命令セットシミュレータを適用することによって達成され得る。再作成された環境には、初期レジスタ状態、初期メモリ状態、およびＣＰＵの挙動に影響を与える可能性のある任意の外部イベントの作成または再作成が含まれるが、これらに限定されない。そのような環境は、ロギングされた情報を使用して作成され、または、レジスタ状態スナップショット、「メモリ再構成」セクションに記載された技術を使用して再構成されたメモリなどの前述の技術、および、ロギングされた、デバッグ中、製造中、もしくは合成中のプログラムの最終状態から収集された、または、これらの様々なソースに由来する他の情報によって再構成され得る。
《レジスタ状態再構成》
改善バックエンドの実装は、いくつかの実施形態によればＣＰＵレジスタ状態の再構成を必要とし得る。（本明細書に記載されるように）レジスタ状態スナップショットを定期的にロギングする場合は、次の技術が、ログ内の任意のポイント（「宛先ポイント」と称され得る）でのレジスタ状態を再構成するために使用し得、そこでは、そのレジスタ状態が宛先ポイントにおいて未知である各ＣＰＵの宛先ポイントの前にロギングされた少なくとも１つのレジスタ状態スナップショットが存在している。
宛先ポイントでのレジスタ状態を再構成するために、時間走行デバッガはそのレジスタ状態が宛先ポイントにて未知であるＣＰＵのセットを最初に決定することができる。これは典型的には、宛先ポイントでコードを実行していたＣＰＵであるが、そのリストからいくつかのＣＰＵを含むかまたは除外する理由があり得る。レジスタ状態がすでにすべてのＣＰＵについて既知である場合、このまたは任意の他のレジスタ再構成アルゴリズムの使用が必要とされないことに留意されたい。
そのレジスタ状態が再構成されるべきＣＰＵのセットが決定されると、改善バックエンドは、（「再構成ポイント」と称され得る）ログにおける以前の時点でのメモリの状態を再構成する「メモリ再構成」のセクションで説明したものなどの技術を使用することができ、これにより、そのレジスタ状態が未知である各ＣＰＵについて、再構成ポイントと宛先ポイントとの間にロギングされた少なくとも１つのレジスタ状態スナップショットが存在する。そして、デバッガは、（「メモリ再構成」セクションに記載されているものなどの）メモリ再構成技術、および（「再構成シミュレーション」セクションに記載されているものなどの）再構成シミュレーション技術の組み合わせを使用して、宛先ポイントに戻り、その前方の各段階で、メモリ状態およびレジスタ状態の正しさが維持されることを確実にし得る。これは例えば、次のような処理を行うことにより行なわれ得る。
再構成ポイントから開始して：
・デバッガ内のメモリおよびＣＰＵ状態で現在、表される時点で、どのＣＰＵが次の実行ステップを取るかを決定する。（本明細書に記載された技術を含め、どのＣＰＵが次の実行ステップを取るかを決定するための多くの技術が存在し得る）。
・現時点に関連したレジスタ状態スナップショットがある場合は、デバッガの状態を保存し、将来の再構成シミュレーションのためにそれを利用可能にする。
・デバッガが次のステップを取るＣＰＵについての正確なレジスタ状態情報を有する場合、増分的に後の時点でターゲット状態を決定するために（「再構成シミュレーション」セクションに記載されているものなどの）技術を使用する。本明細書で使用する場合、「増分的に後」との用語は、使用されるシミュレータの機能に応じて、「１つの命令の後」または「１つのサイクルの後」として、またはなんらの他の方法において、定義することができる。
・デバッガが次のステップを取るＣＰＵの正確なレジスタ状態情報を有していない場合、増分的に後の時点にメモリ状態を移動させるために「メモリ再構成」セクションで説明したものなどのメモリ再構成技術を適用する。
・宛先ポイントに到達するまで、上記の手順を繰り返す。
３つのＣＰＵで構成されるシステムのレジスタ状態再構成の例が図１７である。図において、各行（Ｘ３０１，Ｘ３０２，Ｘ３０３）は、システム内の特定のＣＰＵについてロギングされたデータを表す。（Ｘ３０４における垂直線によって表される）宛先ポイントでのレジスタ状態を再構成するために、改善バックエンドは再構成ポイント（Ｘ３０５における垂直線）でメモリを再構成することによって開始できる。ＣＰＵ＃１（Ｘ３０１）および＃２（Ｘ３０２）のレジスタ状態は宛先ポイント（Ｘ３０４）で未知であり、それは、コードがその時点でそれらのＣＰＵ上で実行中であり、よって、再構成ポイントを、これらのＣＰＵについてのスナップショット（Ｘ３０６およびＸ３０７）が再構成ポイント（Ｘ３０５）と宛先ポイント（Ｘ３０４）との間で発生するように選択しなければならないからである。いかなるコードも宛先ポイントにおいてＣＰＵ＃３上で実行されていないので、ＣＰＵ＃３上でレジスタ状態を再構成する理由はあり得ず、したがって、再構成ポイント（Ｘ３０５）と宛先ポイント（Ｘ３０４）との間でＣＰＵ＃３上でのレジスタ状態スナップショット（例えばＸ３０８）が発生する必要はない。
改善バックエンドが再構成ポイント（Ｘ３０５）におけるメモリ状態を再構成すると、それは次のように時間的に前方にメモリおよびレジスタを再構成し得る。ＣＰＵ＃１の状態を再構成するために、それはレジスタ状態スナップショット（Ｘ３０６）の前に領域（Ｘ３０９）を介してメモリ再構成を実行し得、その後、命令セットシミュレータに利用可能なスナップショット（Ｘ３０６）から状態を作成し、そして、そのシミュレータを使用してスナップショットと宛先ポイントとの間の領域（Ｘ３１０）において再構成シミュレーションを実行する。ＣＰＵ＃２についての状態を再構成するために、デバッガは直ちに命令セットシミュレータに利用可能なスナップショット（Ｘ３０７）から状態を作成し得、そして、そのシミュレータを使用してスナップショットと宛先ポイントとの間の領域（Ｘ３１１）上で再構成シミュレーションを実行する。ＣＰＵ＃３の状態を再構成するために、再構成ポイントと宛先ポイントとの間の領域（Ｘ３１２）全体上でメモリ再構成が使用され得る。
システムが１つのＣＰＵのみを含む場合、記載されたレジスタ再構成プロセスを、以下のように低減できることに留意されたい。
宛先ポイントから開始して：
・１つのＣＰＵの状態が既知である場合は、再構成が必要とされない。さもなければ次のように続行する：
・１つのＣＰＵについてのレジスタ状態スナップショットが存在している最も近い時点に戻るなど、再構成ポイントにメモリの状態を移動し戻すために「メモリ再構成」セクションで説明したものなどのメモリ再構成技術を使用する。
・デバッガのレジスタ状態スナップショットからの状態を保存して、再構成シミュレーションに利用可能にする。
・増分的に後の時点でターゲット状態を決定するために（「再構成シミュレーション」セクションに記載されているものなどの）技術を使用する。
・宛先ポイントに到達するまで、前の手順を繰り返す。
《特定の宛先への後方／前方実行》
いくつかの実施形態では、改善バックエンドは、特定の宛先への後方／前方実行などの様々な時間走行デバッガ動作を実行するための基礎として本明細書に記載の技術を使用することができる。いくつかの典型的な宛先は、特定のメモリ位置に保存された命令が実行される次／前のポイント、特定のメモリ位置またはレジスタが修正される次／前のポイント、または、特定のタイムスタンプなどの特性の区別によって識別される特定のイベントである。
ほとんどの場合、特定の宛先への実行は、３つのステップで達成され得る：（例えば「メモリ再構成」セクションに記載された技術を用いて）宛先が検出されるまで前方または後方にメモリを再構成すること、（例えば本明細書に記載された技術のいずれかを使用して）停止すべき箇所の正確な命令を決定すること、そして（例えば「レジスタ状態再構成」セクションに記載された技術を用いて）その時点でレジスタ状態を再構成すること。
《単一の実行のスレッドのデバッグおよび全体システム》
いくつかの実施形態では、本明細書に記載されるような複数のソースからマージされたログ上で動作する改善バックエンドが、単一の実行のスレッドで、記録された実行のスレッドのサブセットで、または必要に応じてログ全体で、動作を行うことができる。改善バックエンドは、そのスレッドに関連しないデータを無視することによって、単一の実行のスレッドからのデータ上で動作することができる。例えば、図２２は、スレッド１に関するデータ（Ｘ８０２）および他のスレッドに関するデータ（Ｘ８０３）を含むマージされたログ（Ｘ８０１）を示す。データは、本明細書に記載されたものなどの１つ以上のマージ技術を使用して単一ログ（Ｘ８０１）にマージされ得、それにより、それらはマージされたログにおいて論理的に狂った順序とならない。この例ではプログラマは、時間走行デバッガが、スレッド１に関するログの後のセクション（Ｘ８０４）で始まり、スレッド１に関するログの前のセクション（Ｘ８０５）で終わるバックステップ動作などのスレッド１に特有の動作を実行するよう要求することができる。バックステップ動作の開始ポイントおよび終了ポイントを決定するために、改善バックエンドはスレッド１に関するデータ（Ｘ８０２）のみを考慮する必要があり得る。しかし、バックステップ動作を行う際に、改善バックエンドは、スレッド１に関しないデータを含む可能性があるマージされたログからのデータの範囲で動作する、本明細書に記載のものなどの技術を使用してメモリ再構成およびレジスタ再構成を適用することができる。結果として、バックステップなどの単一の実行のスレッドにのみ関する動作を行うと、他の実行のスレッドのシミュレートされた状態を変更して、論理的に整合性のあるシステムの全体の状態を維持することができる。
また、全体としてシステム上で動作する改善バックエンドの能力とは、その終了条件が全体としてシステム内の任意の条件に基づく実行制御動作を行うことができることを意味する。例えば、特定の関数をデバッグしたいユーザは、任意のＣＰＵ上での任意の実行のスレッドがその関数を実行するまで、実行し戻すことができる。または、ユーザは、１つの実行のスレッドでバックステップを実行することができるが、任意のＣＰＵ上での任意の実行のスレッドが特定のメモリ位置を修正した場合にバックステップが中断されるべきであると指定することができる。そのため、改善バックエンドを採用する時間走行デバッガにより、プログラマは、競合条件バグ、メモリ破損バグ、および、改善バックエンドなしでは追跡がはるかに困難または不可能である多くの他の種類の問題を検出およびデバッグすることができる。
《実行された命令のリストの生成》
本明細書に記載の機能を使用して、改善バックエンドは、いくつかの実施形態では、典型的には時間走行デバッガによって必要とされるステッピングおよび実行動作の一部またはすべてを実行することができる。このような動作はしばしばマシン命令粒度で動作し、これは、デバッグ中のシステム内のＣＰＵによって実行される個々のマシン命令がそのような動作を実行するために異なる時点が考慮されることを意味する。改善バックエンドは一意かつ明確にマージされたログ内の個々のマシン命令の実行を表すことができる。個々のマシン命令は、マージされたログ内の位置およびメモリ内のマシン命令のアドレスによって一意かつ明確に表すことができる。
いくつかの実施形態では、（「開始命令」と称され得る）個々のマシン命令の実行の一意の表現を与えられると、改善バックエンドは、その実行のスレッドによって実行される以前の命令（「以前の命令」と称され得る）の一意の表現を決定することができる。ログデータを解析することにより、改善バックエンドは、開始命令が現在の基本ブロックで実行される最初の命令であるか否かを決定することができる。開始命令が現在の基本ブロックにおいて実行される最初の命令ではない場合は、以前の命令が、現在の基本ブロックにおいて実行される以前の命令である。開始命令が現在の基本ブロックにおいて実行される最初の命令である場合は、改善バックエンドは、現在の実行のスレッドによって実行される前の基本ブロックについてログ内でスキャンバックし、その基本ブロック内で実行される最後の命令を決定することによって以前の命令を発見することができる。
例が図２３Ａおよび図２３Ｂに示されている。図示の例では、マージされたログ（Ｘ９０１）の抜粋は、スレッド１についての実行データを含む２つの基本ブロック（Ｘ９０２およびＸ９０３）、ならびに、他のスレッドに関するデータ（Ｘ９０４）を含む。
例として開始命令は、アドレス０ｘ１０４にある可能性があり、これはアドレス（０ｘ１０４）およびログ位置（Ｘ９０３）によって一意に識別される。この場合、開始命令（０ｘ１０４）は、現在の基本ブロック（Ｘ９０３）によって実行される最初の命令ではないので、以前の命令は、現在の基本ブロック（Ｘ９０３）内で実行される以前の命令（０ｘ１００）である。この以前の命令は、アドレス（０ｘ１００）およびログ位置（Ｘ９０３）によって一意に識別される。
例として開始命令は、アドレス０ｘ１００にある可能性があり、これはアドレス（０ｘ１００）およびログ位置（Ｘ９０３）によって一意に識別される。この場合、開始命令（０ｘ１００）は、現在の基本ブロック（Ｘ９０３）によって実行される最初の命令である。改善バックエンドは、現在の実行のスレッドで実行される以前の基本ブロック（Ｘ９０２）を発見するためにログにてスキャンバックし、その基本ブロック（Ｘ９０２）によって実行される最後の命令（０ｘ２０８）を決定することによって、以前の命令を決定することができる。この以前の命令は、アドレス（０ｘ２０８）およびログ位置（Ｘ９０２）によって一意に識別される。
いくつかの実施形態では、（「開始命令」と称され得る）個々のマシン命令の実行の一意の表現を与えられると、改善バックエンドは、その実行のスレッドによって実行される次の命令（「次の命令」と称され得る）の一意の表現を決定することができる。ログデータを解析することにより、改善バックエンドは、開始命令が現在の基本ブロックで実行される最後の命令であるか否かを決定することができる。開始命令が現在の基本ブロックにおいて実行される最後の命令ではない場合は、次の命令が、現在の基本ブロックにおいて実行される次の命令である。開始命令が現在の基本ブロックにおいて実行される最後の命令である場合は、改善バックエンドは、現在の実行のスレッドによって実行される次の基本ブロックについてログ内で前方にスキャンし、その基本ブロック内で実行される最初の命令を決定することによって次の命令を発見することができる。
例として、図２３Ａおよび図２３Ｂを参照すると、開始命令は、アドレス０ｘ１０４にある可能性があり、これはアドレス（０ｘ１０４）およびログ位置（Ｘ９０３）によって一意に識別される。この場合、開始命令（０ｘ１０４）は、現在の基本ブロック（Ｘ９０３）によって実行される最後の命令ではないので、次の命令は、現在の基本ブロック（Ｘ９０３）内で実行される次の命令（０ｘ１０８）である。この次の命令は、アドレス（０ｘ１０８）およびログ位置（Ｘ９０３）によって一意に識別される。
例として、開始命令は、アドレス０ｘ２０８にある可能性があり、これはアドレス（０ｘ２０８）およびログ位置（Ｘ９０２）によって一意に識別される。この場合、開始命令（０ｘ２０８）は、現在の基本ブロック（Ｘ９０２）によって実行される最後の命令である。改善バックエンドは、現在の実行のスレッドで実行される次の基本ブロック（Ｘ９０３）を発見するためにログにて前方にスキャンし、その基本ブロック（Ｘ９０３）によって実行される最初の命令（０ｘ１００）を決定することによって、次の命令を決定することができる。この次の命令は、アドレス（０ｘ１００）およびログ位置（Ｘ９０３）によって一意に識別される。
マージされたログに表される実行のスレッドによって実行される次または以前の命令を決定するための上記の手順を繰り返すことにより、改善バックエンドはマージされたログでの実行のスレッドによって実行されたすべての命令アドレスのリスト（Ｘ９０５）を生成することができる。これは、ハードウェアトレースプローブによって生成された実行データに匹敵し、それにより、前方および後方へのステップ、および、ブレークポイントへの前方および後方への実行を含む時間走行デバッガの動作をサポートするのに十分である。実施形態では、改善バックエンドは、実行のスレッドごとに実行される命令のこのようなリストを伴うデバッガを提供することにより、時間走行デバッガとインタフェースすることができる。
《高度ステッピング、実行およびブレークポイントサポート》
本明細書に記載の機能は、改善バックエンドが時間走行デバッガをサポートするのに十分ではあるが、改善バックエンドのいくつかの実施形態が、時間的により高いレベルの移動に関する責任の一部を実行するのに、より効率的である可能性がある。時間走行デバッガは、改善バックエンドでこれらの機能を利用するように構成されることができ、それにより、それ自身の作業負荷を低減する。
いくつかの実施形態では、改善バックエンドは、バック単一命令ステップ動作を行うことができる。このような動作は、指定された実行のスレッドがその実行における以前の１つのマシン命令である時点までシミュレートされた環境を戻って移動する。例えば、改善バックエンドは、本明細書に記載の技術（または同様の効果を伴う異なる技術）を使用してバック単一命令ステップ動作を行うことができる。例えば、バック単一命令ステップは、以下のプロセスで行うことができる：
・実行された以前の命令を決定するための本明細書に記載された技術または同様の技術を使用して、指定された実行のスレッドによって実行される以前の命令のアドレスおよびログ位置を決定する。
・以前の命令のログ位置が現在の位置と異なる場合、本明細書に記載された技術または同様の技術を使用して、以前の命令のログ位置に到達するようメモリ再構成を実行する。
・本明細書に記載された技術または同様の技術を使用して、レジスタ再構成を実行する。
改善バックエンドは、いくつかの実施形態によって実行された以前の命令の代わりに実行される次の命令をターゲットとすることにより前方命令ステップを実行するよう同様の手順を使用することができる。代替的にいくつかの実施形態では、改善バックエンドは、本明細書に記載されるような再構成シミュレーションまたは類似のシミュレーション技術を用いて前方単一命令ステップを実行することができる。複数の技術が所与の移動動作を実行するために利用可能であるこのような場合に、改善バックエンドは、現在の状況下での技術の予想される効率に基づいて、または他の基準に基づいて、技術を選択するように構成されることができる。
いくつかの実施形態では、改善バックエンドは、特定の条件が満たされるまで時間的に前方または後方に移動することができる。このような条件としては、おそらくはシステム内での実行のスレッドの指定されたサブセット内で指定されたアドレスまたはアドレスの範囲で命令を実行すること、指定されたメモリアドレスまたはアドレスのセットをターゲットするメモリ修正に遭遇すること、新たな実行のスレッドの作成などの特定のロギングされたイベントまたはロギングされたイベントのタイプに遭遇すること、ログ内の最も以前のまたは最新のイベントに遭遇すること、ロギングまたは合成されたタイムスタンプによって示されるような特定の時間に発生したロギングされたイベントに遭遇すること、プログラマが関心のあり得るなんらかの他の条件に遭遇すること、または、これらまたは他の条件で構成される任意のより複雑な条件を含むことができるが、これらに限定されない。そのような移動は典型的には、ログ位置または実行される命令が、停止の条件（複数可）を満たすことに遭遇するまで、必要に応じて本明細書に記載の技術または類似の技術を用いて、ログにおいて前方または後方にメモリを再構成することによって改善バックエンドにより達成することができる。改善バックエンドは、移動を完了して所望の時点でのシステムの状態を再構成するために、本明細書に記載のレジスタ再構成技術または同様の効果を有する技術を使用することができる。
いくつかの実施形態では、改善バックエンドは、追加のログデータをロギングまたは合成することによって増強されることができ、移動動作が停止することができる条件の種類を増加させる。例えば、改善バックエンドは、どのＣＰＵレジスタが各基本ブロック内で修正されているかについての情報をロギングまたは合成することができる。そのような情報を、指定されたレジスタが修正されたときに移動を停止するために使用することができる。
《高度なデバッグ機能》
いくつかの実施形態では、改善バックエンドは、改善バックエンドを採用しないデバッガでは可能ではない多くの強力なデバッグ機能を提供することができる。例えば、改善バックエンドは、改善バックエンドを採用しないデバッガでは容易にまたは全く検出することができないメモリ破損および／または競合を伴うバグを検出するために使用されることができる。改善バックエンドを採用しないデバッガは典型的には、単一ＣＰＵ上で発生したときにこのようなバグを検出することに限定されているのに対し、改善バックエンドは、単一のＣＰＵ上でもしくはＳＭＰ構成などのメモリを共有する複数のＣＰＵ上で発生する場合、または、ＣＰＵがメッセージパッシングによってまたは他の手段によって通信する分散環境において、または、上記もしくは他の構成のうちの１つ以上を伴う複雑なシステムにおいて、このようなバグを検出し、プログラマがデバッグするのを助けることができる。例えば競合は、メモリ位置が複数の実行のスレッドによって読み出しおよび／または書き込みされる場合に発生する可能性がある。このような競合は、予測不能なシステム挙動および他のこのような診断困難バグにつながる可能性がある。
このような高度なデバッグ機能の例として、メモリが破損している複雑なシステムであって、システム内での実行のスレッドが失敗してしまう場合を考える。改善バックエンドを採用する時間走行デバッガを使用するプログラマは、実行のスレッドが失敗したときに停止し、そして改善バックエンドに後方に実行するよう命令し、破損メモリが修正されたときに実行を停止するようにシステムを構成することができる。改善バックエンドなしの時間走行デバッガは、失敗した実行のスレッドによって、または、おそらくは失敗したスレッドと同じＣＰＵ上で実行中の別の実行のスレッドによって破損が引き起こされた場合に、破損の原因を発見するために、この技術を使用することができるのみであろう。改善バックエンドを採用する時間走行デバッガは、失敗した実行のスレッドによって、または失敗したスレッドと同じＣＰＵ上で実行中の別の実行のスレッドによって、または異なるＣＰＵ上で実行中の実行のスレッドによって、または独自に動作するもしくは別の実行のスレッドに代わって動作するカーネルによって、または正しくもしくは誤って破損メモリと同じ物理メモリにマップする仮想メモリアドレスに書き込むことによりメモリを破損する別の実行のスレッドによって、破損が引き起こされた場合に、破損の原因を発見するために、この技術を使用することができるであろう。
《コールスタック深度計算および例外処理》
いくつかの実施形態では、改善バックエンドは、時間の経過とともにコールスタック深度の変化に関する情報をロギングまたは合成することができ、これは、本明細書に記載の移動技術または類似の技術と組み合わせて、改善バックエンドがスタック深度感受性移動を実装することを可能にできる。スタック深度感受性移動の例としては、これらに限定されないが、固定コールスタック深度でのソースコードの行の間で（それぞれ）前または後にステップすることができるソースレベル前方および後方ステッピング、および、現在の関数を呼び出した関数へステップするフォワードおよびバックステップアップが挙げられる。例えば、ソースレベルバックステップは、現在の命令が以前のソース行に関連付けられた命令範囲内に収まり、コールスタック深度が変更されないままである限り継続する後方移動として実装することができる。
いくつかの実施形態では、エントリブロックは、その関数の呼び出しの結果として関数において実行される最初の基本ブロックとして定義することができる。イグジットブロックは、関数の呼び出し元に実行を戻すコードを含む任意の基本ブロックとして定義することができる。改善バックエンドは、スタック深度がそれぞれ増加および減少したことを示すレコードをロギングする関数のエントリおよびイグジットブロックをインストルメント化することにより、コールスタック深度情報をロギングすることができる。基本ブロックレコードについてのログをスキャンして関連する基本ブロックがエントリブロックおよび／またはイグジットブロックであるかどうかを決定することによって、データがデバッグ中のシステムから収集された後に、改善バックエンドはまた、そのようなレコードを合成することができる。このような決定は、プログラムのマシン命令のディスアセンブリまたは解析によって、またはソースコードからマシンコードへとプログラムを変換するプロセスにて使用されるコンパイラおよび／または他のツールによって生成されたメタ情報を調べることによってなど、多くの方法で行うことができる。改善バックエンドは、ロギングまたは合成されたエントリおよびイグジットレコードまたはエントリおよびイグジットブロックのオンザフライ検出を使用して、ログを解釈しつつコールスタック深度の変化を認識することができ。
いくつかのＣＰＵアーキテクチャでは、改善バックエンドはまた、（「ＳＰ」と称され得る）スタックポインタレジスタを解析することによって、現在のスタック深度に関する情報を収集することができる。いくつかの実施形態では、改善バックエンドは、レジスタ状態スナップショットおよび本明細書に記載のものなどのレジスタ再構成技術またはＣＰＵレジスタ値を再構成する他の技術を使用して、ＳＰの値を決定することができる。いくつかの実施形態では、改善バックエンドはまた、ＳＰへの変更をロギングするインストルメント化を含むことができる。いくつかの実施形態では、改善バックエンドは、ＳＰを修正する命令について基本ブロックを解析することなどの技術によって、またはコンパイラまたはソースコードをマシンコードに変換するために使用される他のツールによって生成されたメタ情報を読み出すことによって、ログデータがシステムから収集された後に、ＳＰ変更レコードを合成することができる。
コンピュータプログラムは、例えばＣ＋＋のトライ／キャッチ機構およびＣのｌｏｎｇｊｍｐ機構などの、一度にコールスタックのいくつかのレベルを終了するための機構（「例外処理機構」と称され得る）を使用することができる。コールスタック深度のＳＰベースの決定は一般的に、このような例外処理機構の存在下で作動するが、エントリおよびイグジットブロックのインストルメント化は、複数のコールスタックレベルを同時に終了させることができるときに正確に相対コールスタック深度を計算するにはそれ自体では十分ではない。このような場合には、改善バックエンドは、元に戻されるコールスタックレベルの数を決定し、それに応じて変更をロギングする例外処理コードにおける追加のインストルメント化を使用することができる。
改善バックエンドは、いくつかの実施形態では、状況に最良に合わせて、または各アプローチの長所と短所を最大限に活用するために、ＳＰベースのコールスタック深度決定、エントリ／イグジットブロックベースのコールスタック決定、または他のコールスタック決定技術の組み合わせを使用することができる。
《一意にロギングされたイベントの識別》
いくつかの実装では、一意にロギングされたイベントが識別できるようにすることが有用であり得る。例えば、時間走行デバッガ、または改善バックエンドによって収集されたデータを利用する他のデバッグツールは、プログラマにデータのグラフィカル表現を提供し得る。例えば、このようなデバッグツールは、システムの実行中に発生した関心対象のイベントのタイムラインを表示するために改善バックエンドからのデータを使用することができる。この表現内でクリックするなど、ユーザインタフェース手段を介して、プログラマは、対応する時点へと時間走行デバッガを走行させたいという要望を示すことができる。これを達成するために、時間走行デバッガは、改善バックエンドに所望の宛先を指定することができ、改善バックエンドはそして、所望の時間におけるシステムの状態を再構成することができる。これを達成するために、改善バックエンドは、ログ内のすべての異なる時点（「モーメント」と称され得る）について一意識別子を提供することができる。モーメントは、限定されるものではないが、単一マシン命令の実行、単一オペレーティングシステムイベント、または２つの実行のスレッド間の通信の単一インスタンスを含むことができる。いくつかの実施形態では、改善バックエンドは、本明細書に記載されているように、移動動作の停止ポイントを制御する条件のコンポーネントとして、このような識別子を受け入れることができる。別の例では、改善バックエンドは、改善バックエンドによって収集されたデータをグラフィカルに表示するユーザインタフェースで使用するために、各モーメントに一意タイムスタンプを割り当てることができる。このようなユーザインタフェースは、プログラムパフォーマンスのビジュアル化および解析、システムのタイミング特性の解析、ならびに、システムの競合条件および他の同時実行関連態様の検出および解析を含むがこれらに限定されない多くのもののために使用されることができる。いくつかの実施形態では、ユーザインタフェースは、システムの状態を再構成する時点の選択などの、ユーザ活動に応答して動的に更新または変更される。例えば、ユーザインタフェースは、選択された時点でのメモリおよび／またはレジスタの状態（例えばメモリおよび／またはレジスタに保存されている値）を表示するように更新または変更されることができる。システムの状態は、システムの１つ以上のＣＰＵの状態を含むことができる。
実施形態では、改善バックエンドは、時間の線形測定値を含む識別子（「タイムスタンプ」と称され得る）および（任意選択的に）ＣＰＵ識別子で一意に各モーメントを識別することができる。ＣＰＵ識別子は、含まれている場合、イベントが発生したまたはロギングされたＣＰＵまたは実行のスレッドを表すことができ、それにより、２つの異なるＣＰＵまたは実行のスレッドが同時にイベントを実行した場合をタイムスタンプの精度内で明確にするよう機能する。ＣＰＵ識別子は、ＣＰＵまたはコアなどの実行ユニットを一意に識別する整数または他のなんらかのものとすることができる。例えば、デバッグ中のシステムが４つの実行ユニットを伴う単一マルチコアプロセッサを含む場合、ユニットは、ＣＰＵ識別子０、１、２および３により一意に識別することができる。別の例として、デバッグ中のシステムが、ネットワークを介して通信する２０個の別々のコンピュータシステムを含み、それらの各システムが８コアＣＰＵを含む場合、８×２０、すなわち１６０の実行ユニットがあり、それらにＣＰＵ識別子０〜１５９を割り当てることができる。所与の実行ユニットでの実行から生じるログエントリは、対応するＣＰＵ識別子でタグ付けされることができるので、改善バックエンドはシステムの実行の履歴を正確に再構成することができる。
いくつかの実施形態では、ＣＰＵの実行において各モーメントに一意タイムスタンプを割り当てるために、改善バックエンドはリニアカウンタを使用することができ、これは、各モーメントについて少なくとも一単位、またはクロックによって測定される実際の時間に基づく測定値、または推定時間、またはログにおけるモーメントの位置に基づく測定値、または他の線形測定値、またはこれらまたは他の線形測定値の組み合わせだけ進む。
特定の実装では、タイムスタンプを生成するために改善バックエンドで使用されるクロックは、各モーメントに一意時間を割り当てるために十分な精度または正確さを有していなくともよく、各モーメントについてタイムスタンプをロギングすることが実現可能でなくともよい。このような場合には、改善バックエンドは、各モーメントが一意識別子を有していることを確実にするために、以下の方法などの補間方法を採用することができる。実施形態では、改善バックエンドは、（「実際のタイムスタンプ」と称され得る）クロックから読み出された値に基づいて（「合成タイムスタンプ」と称され得る）一意タイムスタンプを合成することができる。実際のタイムスタンプの精度が各モーメントを一意に表すのに不十分である場合、改善バックエンドは、任意選択的に追加の精度の１つ以上のビット（「サブタイムスタンプビット」と称され得る）を各実際のタイムスタンプに追加できる。改善バックエンドは、タイムスタンプ補間のプロセスを使用して、実際のタイムスタンプに対応しない各モーメントに一意合成タイムスタンプ値を割り当てることができる。補間の目的で、改善バックエンドは、実際のタイムスタンプ間の時間を均一にまたは不均一に細分化することができる。具体的には、改善バックエンドは、ロギングされたイベントの相対的な期間の推定値を使用して実際のタイムスタンプを不均一に細分することができ、それにより、合成タイムスタンプがそれぞれのモーメントの実際の時間の合理的な推定値となる。改善バックエンドによって生成されたタイムスタンプデータがソフトウェアパフォーマンスのビジュアル化および解析のために使用される場合、このような不均一に割り当てられた合成タイムスタンプは特に有用である可能性がある。
タイムスタンプ補間を行う改善バックエンドの例が図２５Ａである。例では、２つのモーメント（Ｘ１１ａ．１およびＸ１１ａ．７）は、実際のタイムスタンプを有し、これらは、おそらくリアルタイムクロックから記録され、対応するイベントでロギングされている。残りのモーメント（Ｘ１１ａ．２〜Ｘ１１ａ．６）は、実際のタイムスタンプを有していない。補間を可能にするために、例における改善バックエンドは、それぞれの実際のタイムスタンプに、３つの１６進数の０で表される１２個のサブタイムスタンプビットを付加する。最後に、例における改善バックエンドは、モーメントＸ１１ａ．１およびＸ１１ａ．７間の経過時間を均一に細分化することによってモーメントＸ１１ａ．２〜Ｘ１１ａ．６の各々に合成タイムスタンプを割り当てる。
不均一な細分化を伴うタイムスタンプ補間を行う改善バックエンドの例が図２５Ｂである。この例は以下の点以外は図２５Ａのものと同様であり、この例では、改善バックエンドは、モーメントＸ１１ｂ．３およびＸ１１ｂ．４を他のモーメント（Ｘ１１ｂ．１〜Ｘ１１ｂ．２およびＸ１１ｂ．５〜Ｘ１１ｂ．７）よりも長い期間であると認め、それに応じてモーメントＸ１１ｂ．１およびＸ１１ｂ．７間の経過時間を不均一に細分化する。
《ブックマークおよびアンドゥ》
ユーザまたはプログラマが、改善バックエンドを伴って実装された時間走行デバッガを使用する過程を経て、関心対象モーメントに遭遇した場合、改善バックエンドは、例えばユーザの要求に応じて、そのモーメント（「ブックマーク」と称され得る）に対応する識別子を保存するために命令され得る。実施形態では、改善バックエンドは、識別子を保存して後でそれを再呼び出しすることができ、ユーザがブックマークモーメントに容易に戻ることができる。いくつかの実施形態によれば、改善バックエンドは、本明細書に記載されるように移動動作の終了条件の一部として、このようなブックマークを使用することができる。例えば、改善バックエンドは、時間の移動を実行するように依頼されることができ、指定されたブックマークで表されるモーメントにおいてデバッグされるシステムの状態を再構成する。プログラマは、システムの実行中の関心対象モーメントの記録および再訪、ならびに、他のプログラマへの関心対象モーメントの通信を含むがこれらに限定されない多くの目的のために、ブックマークを使用することができる。
いくつかの実施形態では、改善バックエンドは、自動的に１つ以上のデバッグセッションの過程にわたって訪問されたモーメントの履歴を維持するように構成されることができる。そのような履歴により、改善バックエンドが時間走行デバッガに「アンドゥ」機能を提供することができ、これにより、単一キーストロークまたは他のユーザインタフェースコマンドによって、プログラマが時間走行デバッガに命令して、改善バックエンドのアンドゥ機能を活性化して訪問した最新モーメントにそれを戻すことができる。例えば、プログラマは、改善バックエンドを採用する時間走行デバッガを伴うシステムをデバッグすることができる。プログラマが誤って、デバッガに実行コマンドを発行し、関心対象時点から遠いポイントへの移動が生じる。「アンドゥ」機能がなければ、プログラマは、システム内の関心対象時点に戻ることが困難な可能性がある。「アンドゥ」機能があれば、プログラマは、例えば単一キーストロークで戻ることができる。
実施形態では、アンドゥ機能の連続的適用により、プログラマのデバッグセッションの履歴を遡って改善バックエンドで示されるシステム状態を歩行することができる。第２のキーストロークまたはユーザインタフェースコマンドは「リドゥ」コマンドを実行することができ、同様にプログラマのデバッグセッションの履歴の前方へと改善バックエンドで示されるシステム状態を歩行することができる。このように、改善バックエンドにより、プログラマがデバッグ中のシステムの実行履歴だけでなくデバッグセッションの履歴そのものをステップスルーできる。ワードプロセッサにおけるこのようなアンドゥ機能により文書編集中に生じたミスを元に戻すのがライターにとって迅速かつ容易になるのと同様に、改善バックエンドにおけるアンドゥ機能により、デバッグ中に生じたミスを元に戻すのがプログラマにとって迅速かつ容易なものとなる。ワードプロセッサにおけるこのようなアンドゥ機能によりライターは文書の改訂履歴を前後に移動することができるのと同様に、改善バックエンドにおけるアンドゥ機能により、プログラマがデバッグセッション中に訪問したモーメントを前後に移動できる。いくつかの実施形態では、「アンドゥ」または「リドゥ」機能の１つ以上を活性化することで、モーメントの履歴などのデバッグセッションの履歴を更新するための「アンドゥ」または「リドゥ」機能のユーザ選択に応じて、ユーザインタフェースが動的に更新または変更される。
《ロギングされたデータの自動解析》
時間走行デバッガをサポートすることに加えて、いくつかの実装では、改善バックエンドは、アプリケーション実行中にこのようなバグにより不正アプリケーション挙動が生じなかった場合でも、（他のタスクの間でも）ロギングされたデータの自動解析、多くの異なる種類のバグの検出を行うことができる。このようなバグは、特定の再現困難な状況下でのみ、すなわち非常にまれにしかアプリケーションの不正挙動として現れ得ず、改善バックエンドの支援なしには発見およびフィックスするには非常に困難であり、時間がかかる。
実施形態では、改善バックエンドは、マルチスレッドアプリケーションにおける競合条件を検出するためにロギングされたデータの自動解析を使用することができる。改善バックエンドは、アプリケーションまたはシステムが実行された後にこのような検出を行うことができ、したがって、システムに追加のランタイムパフォーマンスペナルティを招くことがない。そのような改善バックエンドは、メモリアクセス（読み出しおよび書き込み）ならびにセマフォおよびミューテックスなどの同期プリミティブの使用についてのデータを収集し、そのデータを解析し、共有メモリおよび／または他の共有リソースの安全でない使用を探す。例えば、適切な同期を伴わない同じメモリ位置への書き込み実行の２つのスレッドは、競合を示す可能性があり、これは、発見することが困難なバグにつながる可能性があり、まれにしかアプリケーションの不正挙動とならない。改善バックエンドは、自動的にそのような競合を検出して、プログラマに報告することができる。このような報告は、競合メモリ位置または共有リソース、競合に関与したスレッドのアイデンティティ、および非安全に同一の共有リソースについて競合する命令のアドレスを含むがこれらに限定されない、バグフィックスのために有用な情報を含むことができる。これは典型的には、プログラマがすぐにバグをフィックスするのに十分な情報である。
実施形態では、改善バックエンドは、対応するスタックフレームまたはヒープ割り当てから外れるスタックおよび／またはヒープ位置へのメモリアクセスを検出するためにロギングされたデータの自動解析を使用することができる。そのようなメモリオーバーフローバグは、まれな状況でしか不正なアプリケーション挙動として現れ得ず、したがって改善バックエンドなしでは検出、発見およびフィックスが困難であり得る。
時間走行デバッガおよび非時間走行デバッガの両方を含む多くのデバッガおよび開発ツールは、インストルメント化（「ランタイムエラーチェックインストルメント化」と称され得る）が手動または自動でコンピュータプログラムに挿入されて、様々なバグの検出を支援し得る特徴を有する。そのようなランタイムエラーチェックインストルメント化は、不良ポインタを介するメモリアクセス、アレイバウンドを超えるメモリアクセス、ゼロ除算エラー、メモリ割り当ておよび割り当て解除ライブラリの不正使用等などの多くの問題を検出することができる。そのようなランタイムエラーチェックインストルメント化は、をするプログラムフットプリントおよびランタイムパフォーマンスにおいてオーバーヘッドを追加する。このようなオーバーヘッドは、特定の問題がもはや現れないポイントにアプリケーションの挙動の変化を引き起こす可能性があり、または、アプリケーションを効率的におよび／または正しく動作させない。いくつかの実施形態では、改善バックエンドは、同じチェックを実行するためにロギングされたデータの自動解析を使用することができるが、改善バックエンドインストルメント化のオーバーヘッドを超えるプログラムフットプリントおよびランタイムパフォーマンスにおける追加のインストルメント化またはオーバーヘッドを必要としない。改善バックエンドはそれゆえ、はるかに汎用性の高い方法でランタイムエラーチェックインストルメント化の機能を包括することができる。改善バックエンドは、アプリケーションプログラムの再コンパイルまたは再実行を必要とすることなく、収集されたデータの単一ボディについてのチェックを幅広く行うことができる。改善バックエンドはまた、必要な計算量またはその他の要因により、ランタイムに実行するにはあまりにも破壊的または面倒になるであろうことのチェックを行うことができる。
特定の実装では、改善バックエンドは、デバッガおよび／または他のツールとユーザインタフェースとに自動解析の結果を利用できるようにすることができる。実施形態では、自動解析中に改善バックエンドによって発見されたバグ、潜在的バグ、競合および他の関心対象事象は、システムの過去の状態の改善バックエンドによる再構成を停止するための条件として取り扱うことができ、プログラマが、システムのロギングされた履歴をステップスルーまたは実行して、潜在的バグの事象、あるいは改善バックエンドなしでは発見するのが非常に困難かもしれないような他のそのような関心対象事象で停止するのを容易にする。
実施形態では、自動解析中に改善バックエンドによって発見されたバグ、潜在的バグ、競合および他の関心対象事象は、グラフィカルな形式で表示されることができ、それにより、ユーザは、個々の事象をクリック（または別のユーザインタフェースによってそれらを選択）することができ、事象に関する情報の表示、および／または、改善バックエンドによる事象発生時におけるターゲットの状態の再構成を含むがこれらに限定されない、いくつかのアクションの１つ以上が得られ、よって、ユーザがデバッガでこのような状態を調べることができる。このようなユーザインタフェースは、ユーザアクティビティまたは選択に応じて動的に更新または変更されることができ、それにより、ユーザが自動解析中に改善バックエンドによって発見された任意のバグ、潜在的バグ、または他の関心対象事象をすばやく移動できるようにすることができ、そしてすぐにその原因および／またはその発生の頻度およびパターンについての情報を収集することができる。実施形態では、このようなユーザインタフェースは、時間軸を伴うグラフ、チャート、表、またはビジュアル化の他の形態上で自動解析の結果を表示することができる。そのような表示は、そうでなければ検出することが困難であろうことが非常に明白な一定時間ベースのパターンを作ることができる。実施形態では、これらのイベントを表示するためのユーザインタフェースは、表示されたイベントを非表示、並べ替え、却下、および／または別様に編成および制御するための手段を提供することができ、ユーザが最も直接的な関心を有するイベントに集中するのを容易にする。
《コードカバレッジおよびプロファイリング解析》
いくつかの実施形態では、改善バックエンドによってロギングされたデータの解析を、本明細書に記載されるように、ログに表される実行についてのコードカバレッジデータを生成するために使用することができる。コードカバレッジデータは、プログラムの実行中に実行されたソフトウェアプログラム内の実行可能コードのサブセットに関する情報を含むことができる。コードカバレッジデータは、改善バックエンドによって生成されたログをスキャンし、基本ブロック実行情報を集約し、ログに表される時間の間に実行される各基本ブロック（またはその一部）のリストを生成することによって生成することができる。このリストは、プログラム内のすべての実行可能コード、または、プログラマの関心対象のプログラム内のコードのサブセット（例えば、システムおよび／またはサードパーティライブラリを省略する単なるユーザ書き込みコード）のリストと比較されることができる。実施形態では、得られたコードカバレッジデータをテーブル内に表示することができる。実施形態では、結果として得られるコードカバレッジデータは、ソースコードと併せて、例えば、ソースコード編集ウィンドウもしくはソースレベルデバッガにおけるコードの未実行の行を強調表示することによって、または他の方法で提示されることができる。実施形態では、本明細書に記載の技術は、テストスイートがソフトウェアプログラム内の実行パスをいかに良好にカバーするかを決定するために、テストスイートの実行中にコードカバレッジ情報を生成するために使用されることができる。実施形態では、結果として得られたコードカバレッジデータを、修正条件／決定カバレッジ解析（「ＭＣ／ＤＣ解析」）または他のそのようなソフトウェアテスト解析のために使用することができる。実施形態では、結果として得られたコードカバレッジデータを、ＤＯ−１７８Ｂ（「エアボーンシステムおよび機器のソフトウェア考慮事項」）認証、ＩＥＣ６１５０８（「機能安全」）認証、ＩＳＯ／ＩＥＣ１５４０８（「コモンクライテリア」）認証、およびその他を含むがこれらに限定されないコードカバレッジ解析を必要とする多くの種類のソフトウェア認証のために使用することができる。改善バックエンドによってロギングされたデータからコードカバレッジデータを生成することは有利であり、それは、既に改善バックエンドによって必要とされるものを超えてコードカバレッジデータを生成するために追加のインストルメント化が必要とされず、コードカバレッジデータを生成するための定期的なサンプリングなどの不正確な技術に頼る必要はないからである。
いくつかの実装形態では、改善バックエンドによってロギングされたデータの解析は、本明細書に記載されるように、ログに表される実行についてのプロファイリングデータを生成するために使用されることができる。そのようなプロファイリングデータは、各基本ブロックが実行される頻度に関する情報、および／または、所与のメモリアドレスがアクセスされる頻度についての情報を含むことができるが、これらに限定されない。そのような情報は、改善バックエンドによって生成されたもののスキャン、ならびに、実行される各基本ブロック（またはその一部）のカウントおよび／または書き込まれた各メモリアドレスのカウントを生成することによるデータの集約によって生成されることができる。実施形態では、このようなプロファイリングデータは、テーブル内でユーザに提示され、および／または、（例えば、最も頻繁に書き込まれたメモリアドレスを色分けすることにより）メモリマップ上にオーバーレイされ、および／または、（例えば、ソースコードエディタ内で、ソースレベルデバッガ内で、または他の方法で、各ソース行が実行された回数、または、各ソース行によって表される全体的な実行時間の割合を表示することにより）ソースコードの表現にオーバーレイされることができる。このようなプロファイリングデータは、プログラマによって使用され得、コードの最も頻繁に実行されるセクションを合理化することによって、または、最も頻繁にアクセスされるコードおよびデータのセクションをメモリおよび／またはキャッシュ効果の速度がプログラムの実行速度に最も有益であるメモリのセクションに移動することよってなど、プログラムのパフォーマンスが向上する。改善バックエンドによってロギングされたデータからプロファイルデータを生成することは有利であり、それは、プロファイリングデータを生成するのに追加のインストルメント化が必要ではなく、プロファイリングデータを生成するための定期的なサンプリングなどの不正確な技術に頼る必要はないからである。
実施形態では、本明細書に記載されるように生成されたコードカバレッジおよび／またはプロファイリングデータを、手動および／または自動回帰テストに使用して、ソフトウェアパフォーマンスおよびテストカバレッジを含むがこれらに限定されない様々な指標が経時劣化していないことを確認することができる。
《未知の値》
ほとんどの場合、改善バックエンドの特定の実装が正確にメモリおよびレジスタの内容を再構成することができるが、データ値の再構成が可能ではない場合がある可能性がある。例えば、改善バックエンドは、例えば副作用揮発性メモリに保存する際に、メモリ変更についてのプリイメージ値をロギングしないかもしれない場合がある。また、ロギングされたデータの自動解析または他のそのような解析技術は、改善バックエンドがロギングされたイベントの正しい順序を特定することができないので、メモリまたはレジスタ値が未知である状況をもたらし得る。このような状況は一般的に、そのようなソフトウェアがＳＭＰ環境で実行されると、解析されているソフトウェアでの競合条件が原因で発生するが、他の原因も同様に可能である。このような場合についての特別な処理がなければ、デバッガがメモリまたはレジスタの内容を不正にプログラマに報告する可能性があり、混乱を招き、バグの発見およびフィックスが困難になる。
実施形態では、改善バックエンドは、既知の値とは異なる未知のメモリおよび／またはレジスタ値を扱う。このような未知の値が検出されると、改善バックエンドは、どのメモリ位置および／またはレジスタ値が未知であるかを追跡することができる。改善バックエンドは、未知のメモリ位置および／またはレジスタ値をデバッガに報告することができ、それにより、それらはプログラマに異なって表示され、プログラマが既知の値と区別することができる。
実施形態では、未知の値で動作する改善バックエンドは、例えば（本明細書に記載の）再構成シミュレーションを行う場合、計算の結果に未知性を伝播することができる。例えば、２つのレジスタの値を加算し、第３のレジスタに結果を配置する命令をシミュレートする改善バックエンドは、加数のいずれかまたは両方が未知である場合、第３のレジスタの値を未知であるとマークすることができる。同様に、レジスタにメモリから値をロードすることをシミュレートする改善バックエンドは、ロードされたメモリ値が未知の場合にレジスタの値を未知であるとマークすることができる。そのような伝播技術を使用して、改善バックエンドは、それが実際に既知である場合は、それが値を「既知である」と報告するのみであろうことを保証することができる。
実施形態では、改善バックエンドは、値の未知状態が伝播されるべきでない場合を知ることができる。例えば、２つのレジスタの値を減算する命令をシミュレートする改善バックエンドは、減算される値が未知であっても、このような減算が常にゼロ結果となるような場合など、減算された値が同じであることが既知である場合、「既知である」と結果をマークし得る。
実施形態では、改善バックエンドは、それらの値が既知になったときに既知であると未知の値をマークすることができる。例えば、レジスタの値がレジスタ状態スナップショットから決定することができる場合に、改善バックエンドは、そのレジスタの値を既知であるとマークすることができる。同様に、命令が既知の値でレジスタの内容を上書きすることをシミュレートされたときに、その値が以前に既知でなかったとしても、レジスタの内容を既知であるとマークすることができる。このような技術を使用して、改善バックエンドは、それが実際に未知である場合に「未知」として値を報告のみすることを保証することができる。典型的な場合では、プリイメージを含むレジスタ状態スナップショットおよびメモリストアレコードが頻繁に発生する可能性があり、よって、所与の値は、アプリケーションまたはシステムのロギングされた履歴内で未知のままである期間は、典型的には限られている。
実施形態では、未知のメモリおよび／またはレジスタ値は多くの場合、デバッグされるプログラムまたはシステム内の競合によって引き起こされ、それにより、潜在バグが存在していることのプログラマにとっての有用な指標とすることができる。別の方法で表現すると、改善バックエンドが、実施形態において、メモリ位置またはレジスタの正しい値を決定することができない場合は、プログラマが最も修正したい可能性の高いシステム内欠陥を示すようには、正しい値をプログラマが確認することができないようにコンピュータシステムおよびソフトウェアが構成されていることを示すことができる。自動的にこのような場合を検出し、プログラマにそれらを表現する改善バックエンドの能力はしたがって、極めて貴重なデバッグツールである。実施形態では、改善バックエンドは、このような競合条件の詳細を、直接にまたは時間走行デバッガまたは他のこのようなユーザインタフェースでインタフェースすることによってプログラマに表示するように構成されることができ、これは、ユーザアクティビティまたは選択に応答して動的に更新または変更することができる。検出されてプログラマに示される競合条件の詳細は、同じメモリ位置へのアクセス衝突のソースコード内の位置、そのような衝突が発生したロギングされた実行中の時間（複数可）、および、そのような各衝突中および後のメモリ位置の可能な値を含むことができるが、これらに限定されない。
《例示的ユースケース：ＳＭＰ競合条件》
いくつかの実施形態では、改善バックエンドは、本明細書に記載されるように、時間走行デバッガおよび／または他のデバッグおよび解析ツールと関連して使用される場合、そうでなければ可能ではない方法でプログラマが複雑なコンピュータシステムの問題を診断およびデバッグすることを可能にする。本明細書に記載のシステムおよび技術を使用することにより、そうでなければ発見およびフィックスに数週間ないしは数か月かかるかもしれない、または全くフィックスされないかもしれない困難なバグを、典型的には数時間ないしは数日で解決することができる。
例えば、バグの一般的な種類は、同時の実行のスレッドによって共有されるメモリ位置へのアクセスが適切に守られておらず、各種の不安定な挙動となってしまう競合条件である。マルチコアＣＰＵ（例えば、デュアルコア、クワッドコアなど）の使用が増加して、そのようなバグがますます一般的になってきており、それは特に、シングルコアＣＰＵのために書かれレガシーコードがより現代的なＣＰＵにポートされるからである。従来のデバッグ技術では、そのようなバグの追跡に対して少しの助けにしかならず、プログラマはあまりそれに頼ることはできないままであり、コードを慎重に解析しなければならず、プロセスには数週間以上かかり、そして結果が得られないことがある。
競合条件の例が図２７Ａ〜Ｄに表示される。例では、カウンタ（「カウンタ」）が２回インクリメントされる。「カウンタ」の初期値は４であり、よって「カウンタ」の最終的な値は、２つの成功したインクリメント動作を反映して６となるべきである。各インクリメント動作は、読み出し動作（例えばＸ１４ａ−ｒｅａｄ１）および書き込み動作（例えばＸ１４ａ−ｗｒｉｔｅ１）からなる。
単一コアの例（図２７Ａ）では、両方のインクリメント動作は、単一コア（Ｘ１４ａ−ｃｏｒｅ０）によって実行されるので、何の競合も発生していない。インクリメント動作（Ｘ１４ａ−ｉｎｃ１、Ｘ１４ａ−ｉｎｃ２）が順次、行なわれ、続く読み出しおよび書き込み動作（Ｘ１４ａ−ｒｅａｄ１、Ｘ１４ａ−ｗｒｉｔｅ１、Ｘ１４ａ−ｒｅａｄ２、Ｘ１４ａ−ｗｒｉｔｅ２）も厳密な順序で発生する。
図２７Ｂは、デュアルコアＳＭＰ環境で実行されるインクリメントの同一の対を示している。第１のインクリメント動作（Ｘ１４ｂ−ｉｎｃ１）は、コア０（Ｘ１４ｂ−ｃｏｒｅ０）上で行われ、第２の動作（Ｘ１４ｂ−ｉｎｃ２）は、コア１（Ｘ１４ｂ−ｃｏｒｅ１）で行われる。この場合は幸運であり、２つのインクリメント動作（Ｘ１４ｂ−ｉｎｃ１およびＸ１４ｂ−ｉｎｃ２）は時間的にばらばらであり、順次、実行される。予想されるように「カウンタ」の最終的な値は６である。
図２７Ｃは、不運であり、時間内の２つのインクリメント動作（Ｘ１４ｃ−ｉｎｃ１、Ｘ１４ｃ−ｉｎｃ２）がオーバーラップしてしまう点以外は図２７Ｂと同様である。第２のインクリメント動作（Ｘ１４ｃ−ｉｎｃ２）は、第１のインクリメント動作（Ｘ１４ｃ−ｉｎｃ１）の完了前、具体的には第１の書き込み動作（Ｘ１４ｃ−ｗｒｉｔｅ１）の発生前にその読み出し動作（Ｘ１４ｃ−ｒｅａｄ２）を実行する。その結果、第２の読み出し動作（Ｘ１４ｃ−ｒｅａｄ２）にて読み出された値が５の代わりに４である。第２の書き込み動作（Ｘ１４ｃ−ｗｒｉｔｅ２）が発生すると、「カウンタ」に書き込まれた最終的な値は、６の代わりに５である。競合条件のため、「カウンタ」の値は、２つのインクリメント動作の実行にもかかわらず、４から６への代わりに４から５へと進む。
図２７Ｃにおいて実証されたものなどの問題は、それらが２つのコア（Ｘ１４ｃ−ｃｏｒｅ０、Ｘ１４ｃ−ｃｏｒｅ１）におけるインクリメント動作（Ｘ１４ｃ−ｉｎｃ１、Ｘ１４ｃ−ｉｎｃ２）の相対的タイミングに依存するので、不規則に発生し得る。さらに、ソースコードが正しく見えて２つのインクリメント動作を示すが、２つのインクリメント動作があるのに「カウンタ」が１しか進まない理由が明白ではないので、プログラマがソースコードを読み取ることによってそのようなバグを識別するのは非常に困難である可能性がある。改善バックエンドがなければ、時間走行デバッガはこの種のバグの発見およびフィックスにはあまり有用ではなく、それは、典型的には（図２７Ａに示すような）単一コア上でプログラムを実行して問題発生を防止する必要があるからである。
ある実装では、（本明細書に記載の）改善バックエンドを伴う時間走行デバッガおよび／または他のビジュアル化ツールを使用するプログラマは、迅速かつ簡単に図２７Ｃに示したものなどのバグを発見するためにいくつかの技術のうちの１つ以上を使用することができる。例えば、競合条件を疑うプログラマは、（本明細書に記載の）ロギングされたデータの自動解析を使用でき、改善バックエンドは、第１および第２の書き込み動作（Ｘ１４ｃ−ｗｒｉｔｅ１、Ｘ１４ｃ−ｗｒｉｔｅ２）が適切に守られていないことを検出し、プログラマに通知する。自動解析技術は、実際の実行が正しい最終値が生成された図２７Ｂに似ている場合であっても、潜在的問題を識別するであろうことに留意されたい。
競合条件を発見するためのこの自動解析技術は、非常に強力である可能性がある。一般的に使用されているデバッガの大半は、ソフトウェアアプリケーションを用いて問題に気づくよう、またはユーザより問題について通知され、問題の原因を発見するようプログラマを支援する。これとは対照的に、この自動解析技術は、プログラマおよびプログラムのユーザがまだ気づいていない、および／または、まだ不正挙動として現れていないソフトウェアアプリケーションに伴う問題を発見することができる。入力タイミング、キャッシュ挙動、ＣＰＵ挙動、割り込みタイミング、および／または他の再現困難要因の変動のため、このような潜在的バグは、１００回に１回、１，０００回に１回、１，０００，０００回に１回、またはさらに少ない頻度で、一見ランダムな時間に不正挙動として現れるにすぎない。リリースされたソフトウェア製品、または、携帯電話、自動車エンジン、アビオニクスデバイス等などの正しく動作するべくソフトウェアに依存する製品では、そのようなバグは、製品が普及するまで気づかれない不安定な挙動になる可能性があり、これは、製品開発者の評判、および、バグを発見してパッチを適用するのにかかる労力の両方で非常にコストがかかる可能性がある。このような費用は、数百万ドル以上に及ぶ可能性があり、また、市場シェアの回復不能な損失をもたらす可能性もあり、これは、競合条件を発見するための自動解析技術を用いて完全に回避することができるため、このようなデバッグ機能はソフトウェア開発者にとって非常に貴重なものとなる。
いくつかの実施形態によれば、改善バックエンドが、この種の競合条件を追跡するのにプログラマにとって貴重である可能性がある他の方法がある。第２の例では、「カウンタ」の疑わしい値に注目するプログラマは、改善バックエンドを備えた時間走行デバッガを使用することができ、これは、時間を遡ってプログラムを実行し、「カウンタ」の値が修正された時点で停止し、それらの時点で「カウンタ」の再構成された値を表示する。プログラマは、「カウンタ」をインクリメントすることになっている時間的に隣接する２つの動作が、両方とも代わりに５にその値を設定しており、インクリメント動作が互いに干渉しているかもしれないことに気づくであろう。
第３の例では、プログラマは、時間経過とともに「カウンタ」の値をグラフ化して「カウンタ」が修正されたポイントを強調表示するグラフィカルツールへデータを提供するよう改善バックエンドの実施形態を使用することができる。そのようなツールでは、プログラマは、２つのインクリメント動作がほぼ同時に発生することを容易に確認することができ、「カウンタ」の値は１だけ変化するのみである。プログラマがより密接にプログラムの動作を検査したい場合、インクリメント動作の１つをクリックすると、改善バックエンドを備えた時間走行デバッガに、選択された時点での両方のコアの活動を表示させることができる。
これらの例の３つすべては、いくつかの実施形態による改善バックエンドの独自の機能に依存している。改善バックエンドなしの時間走行デバッガは一般的にまったく同時実行から生じる問題をデバッグすることができないのに対し、改善バックエンドは、それができ、本明細書に記載されるものなどの競合条件の検出およびデバッグを可能にする。改善バックエンドの特定の実装により可能となる本明細書に記載されているものなどの技術を使用して、プログラマは、ほんの数分で問題の原因を特定することができる一方、改善バックエンドなしでは、プログラマは問題を特定するために、あまり効率的ではない技術または完全当て推量に頼ることを余儀なくされ、これは、数日、数週またはそれ以上かかる可能性があり、多くの場合、全ての問題をフィックスすることは非現実的または経済的に実行不可能である。
プログラマが競合の原因を識別すれば、図２７Ｄに示すように問題をフィックスすることは比較的容易である。ミューテックスロック（Ｘ１４ｄ−ｌｏｃｋ）でインクリメント動作（Ｘ１４ｄ−ｉｎｃ１、Ｘ１４ｄ−ｉｎｃ２）を包むなど、同期プリミティブを適用すると、続く読み出しおよび書き込み動作（Ｘ１４ｄ−ｒｅａｄ１、Ｘ１４ｄ−ｗｒｉｔｅ１、Ｘ１４ｄ−ｒｅａｄ２、Ｘ１４ｄ−ｗｒｉｔｅ２）は強制的にすべての場合において厳密な順序で発生することになり、コア（Ｘ１４ｄ−ｃｏｒｅ０、Ｘ１４ｄ−ｃｏｒｅ１）の相対的タイミングにかかわらず、「カウンタ」について６との正しい最終的な値が得られる。
《他の変形例》
本明細書の開示は、垂直統合インストルメント化についての方法、システム、およびデバイス、ならびに、従来のデバッガと比較してデバッガのコンピュータ技術の機能、速度および動作を劇的に改善するトレース再構成システムを提供する。実施形態では、本明細書に開示されるシステムおよび方法は、ターゲットプログラムの実行中に発生したイベントの再生および／または再構成を提示するのに、ある場合には１０倍以上の係数で時間を減少させることによって、ソフトウェアデバッガ技術分野における改善をもたらすように構成されることができる。
実施形態では、本明細書に開示されるシステムおよび方法は、トレースデータログにギャップまたは欠落データがないか、または実質的にないトレースデータを生成するように構成されることができる。比較すると、従来のデバッガシステムは一般的に、システムがトレースデータログファイルにトレースデータを記録するのを困難にするかなりの数のメモリアクセスを生成するターゲットプログラムの命令シーケンスの間に特に、トレースデータのギャップまたは欠落要素もしくはデータを有するトレースデータログファイルを生成する。ソフトウェアデバッガの技術分野における上記の改善を達成するために、本明細書に開示されるシステムおよび方法は、様々な機能、技術および方法を採用する。
新たな高度技術は、動作するのにこれまで以上に複雑なソフトウェアプログラムを必要とし、本明細書に開示されるようなソフトウェアデバッグシステムおよび方法の実施形態の必要性がますます重要になる。例えば、スマートフォンはますます電話の様々なシステムコンポーネントを実行するために複雑なソフトウェアを必要とする。一般的には、典型的なスマートフォンは、いくつかの場合にはプログラマの大規模なチームによって開発される数百万行のコンピュータコードを必要とする。コード行数の増加および関与プログラマの増加に伴い、ソフトウェアコードのバグ数も増加する。多くの場合、これらのソフトウェアバグを解決することがますます複雑になっている。例えば、いくつかのソフトウェアバグは、断続的および／または低頻度で発生し、つまり、日に一度、週に一度、月に一度、年に一度、またはそれ未満の低頻度で発生する。
従来のソフトウェアデバッグプログラムは多くの場合、バグが断続的および／または低頻度でしか発生しないソフトウェアをデバッグしようとするとき、面倒で非効率的である可能性がある。対照的に、「再現性」であるソフトウェアバグは一般的に、コンピュータプログラマが特定および／またはフィックスするのが簡単である。本明細書で使用する場合、「再現性バグ」との用語は一般的に、プログラムが同一のユーザ制御可能入力を用いて実行されるたびに同じようにそれ自体が現れるバグを指す。一般的には、再現性バグは多くの場合、プログラムの実行中に予測可能なように起こるのに対し、低頻度で発生するソフトウェアバグは一般的に、プログラムの実行中にこのように予測可能なようには発生しない。
実施形態では、本明細書に開示されたシステムは、ターゲットコンピュータプログラムがハードウェアトレースポート、検出器またはプローブを使用せずに実行されているときに、トレースデータを生成し、効率的に生成中のすべてのそのようなトレースデータを取得するように構成されている。実施形態では、システムは、実行中にターゲットプログラムに関係する特定のデータ要素のみをストレージに保存することにより、トレースデータをより効率的に生成するように構成されている。不要データ要素を収集するおよび／またはコンピュータプログラムに関する貴重なデータ要素を省略する従来のデバッガプログラムとは対照的に、システムは、ターゲットコンピュータプログラムの状態を再構成するために必要なトレースデータをより効率的に生成するように構成されることができる。
実施形態では、例えばマルチコアシステム内の複数のコアからログデータをマージする間、トレースデータの順序があいまいであると改善バックエンドが判断した場合、ターゲットプログラムにおける可能なバグを示すことができる。例えば、順序における曖昧さは、１つ以上のコンピュータプログラム命令などのタスクを実行するターゲットプログラムに起因する可能性があり、その完了の順序は予測不能であり、その出力は完了の順序に依存する。これは時にハザードと称され、不正確な実行に潜在的につながる可能性がある。一般的に３つの種類のハザードが存在する可能性があり、異なる命令によるデータの修正に起因するデータハザード、分岐ターゲットでの曖昧さに起因する制御ハザード、および、異なる命令によって同時にアクセスされるメモリに起因する構造ハザードである。ハザードは、シングルコアおよびマルチコアシステムで起こる可能性がある。マルチコアシステムでは、同時に命令を実行する２つ以上の異なるコアに起因してハザードが発生する可能性がある。
オペレーティングシステムは典型的には、実体の内外から来ている複数の実行のスレッドを管理している。従来のソフトウェアデバッガシステムでは、実体の内外から来ている実行のスレッドに関するデータは、一般的に収集されない。対照的に、本明細書に開示されるシステムおよび方法の実施形態は、スレッドの作成および破壊に関連するすべてのトレースデータを収集するように構成されている特殊なオペレーティングシステムと連携して動作するように構成されることができる。複数の実行のスレッドを実行可能なオペレーティングシステムは、マルチタスクオペレーティングシステムと称されることができる。本明細書で開示されるシステムおよび方法の実施形態は、マルチタスクオペレーティングシステムによって実行される複数のタスクからタスクのいずれかをデバッグするために使用することができる。デバッグは、実行中の現在の実行のスレッドに限定されるものではなく、オペレーティングシステムによって実行された実行のスレッドの１つ以上をデバッグすることができる。実施形態では、ターゲットシステムが並列に（すなわち同時にまたはほぼ同時に）複数の実行のスレッドを実行するマルチプロセッサまたはマルチコアシステムである場合は、複数の現在実行中または以前に実行されたタスクをデバッグすることができる。理解を容易にするために本開示は、実行のスレッド（または複数の実行のスレッド）としてオペレーティングシステムによって現在、実行されているコンピュータプログラムのデバッグを参照し得るが、開示されたシステムおよび方法の実施形態を、マルチタスクオペレーティングシステムによって実行されている任意の１つまたは複数の実行のスレッドをデバッグするために使用できることを当業者は理解するであろう。
実施形態では、システムは、トレースログデータを取得してそれをデコードするように構成されることができ、それにより、システムは、ターゲットプログラムの実行を停止する前の任意の時点でのターゲットコンピュータシステムの状態をユーザに伝えるように構成されることができる。ターゲットコンピュータシステムの状態を再構成すると、プログラマがその時点でターゲットプログラムが何を行っていたのかを決定することを容易にすることができ、実行中に遭遇した１つ以上のエラーの特定および修復が可能になる。
実施形態では、プロセッサおよび／またはコアがインストルメント化コードを実行すると、別様に実行されるよりも多くのコードが実行され、その結果、ターゲットプログラムの動作／関数における不可避の遅延および／または減速がある。デバッグプロセスが完了した後、システムは、ターゲットプログラムにインストルメント化コードを挿入する必要なく、ターゲットプログラムをコンパイルするように構成することができ（またはインストルメント化コードは、リンク時に無効化または除去することができ）、それにより、ターゲットプログラムがピークパフォーマンスで動作することが可能となる。本明細書で説明されるように、１つ以上のインストルメント化命令をリンク時にストリッピングすることができ、これにより、ターゲットコンピュータプログラムが、フルインストルメント化が保持される場合よりも、より効率的に（例えばより高速に）実行することができる。対照的に、従来のデバッグシステムは一般的に、実行モードにあるときにターゲットプログラムの動作速度を制御することはできない（そして、トレースデータを待つためにコンピュータ処理ユニット（「ＣＰＵ」）を停止することができるこのようなシステムでは、このようなシステムは、常に適切に動作するわけではなく、すなわち予測不可能である可能性がある）。したがって、従来のデバッグシステムは、貴重なトレースデータを失ってトレースデータログファイルにギャップを作成する可能性があり、このようなギャップはターゲットプログラムの停止条件にまで至るイベントの再生および／または再構成を防止または困難にし、これは、クラッシュ、ブレークポイント、特定のメモリアドレスへのアクセス、実行停止へのユーザ要求などの１つ以上を含む可能性がある。オペレーティングシステムがターゲットプログラムの速度を制御することができない場合、コンピュータのプロセッサは時に、トレースデータをログファイルに保存するには忙しくなりすぎ、トレースログファイルにギャップが生じることがある。
ターゲットプログラムのイベントを再生および／または再構成するために２０分以上、プログラマが待つ必要がある場合は、ターゲットプログラムをデバッグしようとすることは、プログラマにとって非常に破壊的である可能性がある。プログラマがより多くのデータを収集した場合、従来のソフトウェアデバッグプログラムでは、収集したトレースデータの量に比例したデコード時間となるので、待機時間はさらに長くなり得る。例えば、ターゲットプログラムにおけるクラッシュにまで至るイベントを単に再生および／または再構成するためにプログラマが定期的に２０分超待たなければならないとすると、プログラマは、ターゲットプログラムのデバッグ中に自身の思考列を失う可能性がある。したがって、数秒または数分以内にターゲットプログラムのイベントを再生および／または再構成するように構成することができるシステムを利用することは、プログラマにとって有利である可能性がある。実施形態においてシステムは、最後から始まる、つまりターゲットプログラムのクラッシュの直前に発生したイベントに関連付けられたトレースデータから開始するトレースデータを解析することによってターゲットプログラムにおけるクラッシュにまで至るイベントを再生および/または効率的に再構成するように構成される。
実施形態では、コンパイラは、ターゲットプログラムのソースコードにて識別された、異なるコンポーネント、関数、イベント等に基づいてインストルメント化を生成するように構成されている。実施形態では、コンパイラは、ターゲットプログラムにおける基本ブロックの識別に基づいてインストルメント化を挿入するように構成されている。いくつかの場合において、基本ブロックは、１つのエントリポイントと１つのイグジットポイントとを有する命令のセットまたはシーケンスである。すなわち、基本ブロックは典型的には、ブロックへのエントリを除いて入来ブランチを有し得ず、ブロックからのイグジットを除いて退出ブランチを有し得ない。実施形態では、命令のシーケンスは、次の２つの条件が満たされることを条件とする基本ブロックを形成する：（ｉ）各位置における命令はすべての後続の命令の前に常に実行される、（ｉｉ）他の命令は命令のシーケンスにおける２つの命令の間には実行されない。実施形態では、例えば同時に多くの命令を実行するように構成することができるスーパースカラＣＰＵを使用するシステムにおいて、各位置での命令が１つ以上の後続の命令と同時に実行される場合および／または１つ以上の命令が命令のシーケンスで２つの命令間で実行されている場合、命令のシーケンスは基本ブロックを形成することができる。実施形態では、命令の出力および／または結果は、このような命令が、スーパースカラＣＰＵで構成された特定のシステム環境においてなど、同時に処理され得るとしても、基本ブロック内の命令の順序またはシーケンスに保存または適用または結合される。
《タイムスタンプ補間》
実施形態では、タイムスタンプは、基本ブロックへのエントリ時または基本ブロックからのイグジット時に挿入されない。代わりに、タイムスタンプは、とりわけ、ＦＥＥインストルメント化（本明細書で説明された）およびオペレーティングシステムとの通信などの他の動作の間に挿入される。補間は、１つ以上の命令または複数の命令の実行時間を決定するために用いられることができる。例えば、システムは、１０個の命令などの命令のセットの平均実行時間を推定または測定することができ、この平均実行時間は、特定のタイムスタンプが挿入されなかった特定の複数の命令の実行時間を決定するために使用されることができる。具体的には、命令の平均実行時間は、２つのロギングされたタイムスタンプを発見し、これら２つのタイムスタンプがロギングされたポイント間に実行された命令の数をカウントし、タイムスタンプ間の経過時間を実行された命令の総数で除算することによって計算されることができる。
《関数エントリおよびイグジットのロギング》
実施形態では、コンパイラは関数エントリおよび関数のイグジットに基づいてインストルメント化を挿入するように構成されている。以上はＦＥＥインストルメント化と称され得、「関数エントリおよびイグジット」インストルメント化を意味する。本明細書で使用する場合、関数との用語は一般的に、特定のタスクを実行するソフトウェアプログラムの名前付きセクションまたは命令のグループを指す。ＦＥＥインストルメント化は、関数を実行するために使用される時間量の正確な推定値を提供することができる。この情報は、デバッグのためだけでなく、特定の関数の実行に費やされる時間量および／またはリソースを減らすなどの最適化のためにも有用である可能性がある。例えば、ＦＥＥインストルメント化に基づく情報は、視覚的にコールスタックを提示するために使用されることができる。実施形態では、インストルメント化は、関数へのエントリおよび関数からのイグジットの時にタイムスタンプを挿入することができる。実施形態では、補間は、その実行が例えばタイムスタンプの対の間に発生するエントリおよびイグジットポイント間にある関数の１つ以上の命令などの１つ以上の命令の実行時間を決定するために使用することができる。補間は、本明細書に記載されているように、線形、加重、非線形などである可能性がある。実施形態では、１つ以上のタイムスタンプを、関数へのエントリ後であるが関数からのイグジット前のトレースデータに追加的または代替的に挿入することができる。ＦＥＥインストルメント化を、基本ブロックのインストルメント化の代わりに、またはそれと組み合わせて使用することができる。実施形態において、コンパイラは、その実行が別の関数の実行から決定されることができる関数のインストルメント化をスキップするように構成されることができる。
特定の場合において、ＦＥＥインストルメント化を単独で使用する場合、それは不正確な結果を生成する可能性がある。関数エントリにてロギングされたタイムスタンプは、タイムスタンプを記録するのに使用されるインストルメント化が実際の関数エントリの後にいくつかの命令を発生する可能性があるという点で、少し遅くなる可能性がある。同様に、関数イグジットにてロギングされたタイムスタンプは、タイムスタンプの記録と実際の関数イグジットとの間にいくつかの命令が存在する可能性があるという点で、少し早くなる可能性がある。このような不正確さは、修正されない場合、ソフトウェアプログラムのパフォーマンスの解析の誤解を含む多くの問題につながる可能性がある。このような誤解を招くデータは、プログラマがソフトウェアプログラムのパフォーマンスを最大化するのをはるかに困難にする可能性がある。
実施形態では、（本明細書に記載の）タイムスタンプ補間が、これらの不正確さを補正するためにＦＥＥインストルメント化と組み合わせて使用される。タイムスタンプ補間は、より正確に関数の最初と最後の命令を表すタイムスタンプを決定するために用いられることができる。例えば、関数エントリにおけるタイムスタンプが実際の関数エントリから１１個の命令の後に算出される場合、タイムスタンプは、１１個の命令を実行するのにかかる平均時間を減算することにより調整することができ、より正確な関数エントリのタイムスタンプが得られる。同様の調整を、関数イグジットタイムスタンプが決定された時点と関数の実際の終了との間で実行される命令の数を１つの命令を実行するための平均時間に乗じた数をそれらに加算することにより、関数イグジットタイムスタンプに対して行うことができる。これらの補間されたタイムスタンプは、プログラマに関数エントリおよびイグジットに関する情報を提示する場合、または他の方法でＦＥＥデータを使用する場合、ＦＥＥインストルメント化によってロギングされたタイムスタンプの代わりに使用されることができる。ＦＥＥデータの不正確さを補正するためにタイムスタンプ補間を使用すると、プログラムパフォーマンスのはるかにより正確な解析を可能にすることができる。
《システムアーキテクチャ》
図１Ａは、デバッガおよびコンパイラを含む一般的なハードウェアおよびソフトウェアアーキテクチャのブロック図を示す。典型的なデバッガシステムは、実行可能コンピュータプログラムを生成するためのコンパイラおよびリンカプログラム１０８を有するホストシステム１１８を含む。デバッガプログラムは、トレースデータを収集してコンピュータプログラムの実行中またはその後にログファイルにそのようなデータを保存するように構成されているログダウンローダ１１２を含む。一般的に、コンパイラプログラムおよびリンカ１０８は、プログラマにより書かれたソースコード（図示せず）からターゲットプログラム１１４を生成する。コンパイラプログラムおよびリンカ１０８はまた、デバッガプログラム１１０の動作に役立つ情報を含むデバッガプログラム１１０によって使用されるデータファイル（図示せず）を生成することができる。一般に、デバッガプログラム１１０は、ユーザがターゲットプログラム１１４をデバッグできるように、ターゲットシステム１２０の要素と相互作用することができる。多くの場合、従来のデバッガシステムは、インタフェースマネージャ１１６を含み、これは、ユーザがデバッガプログラム１１０と相互作用するためのグラフィカルユーザインタフェースを提供するように構成されることができる。コンパイラおよびリンカプログラム１０８、デバッグプログラム１１０、ログダウンローダ１１２およびインタフェースマネージャ１１６は、ホストシステム１１８によって実行され、これは、例えばデバッグ接続１１７を介するターゲットプログラム１１４のように、コンピュータプログラムが実行されるターゲットシステム１２０とインタフェースする。ターゲットシステムは、ホストシステム１１８のハードウェアおよびオペレーティングシステム（図示せず）とは異なることができるオペレーティングシステム１０４を実行するハードウェア１０２を含む。オペレーティングシステム１０４は、コンピュータハードウェアおよびソフトウェアリソースを一般的に管理するシステムソフトウェアである。オペレーティングシステム１０４は、ターゲットプログラム１１４などのコンピュータプログラムのための共通のサービスを提供するためにシステムライブラリ１０６と併せて作動する。オペレーティングシステム１０４は、デバッガプログラム１１０にデバッグデータを提供するように構成されたエージェント１２２を含むことができる。デバッガプログラム１１０は、エージェント１２２に命令およびデータを提供することができる。
図１Ｂは、デバッガおよびコンパイラを含む一般的なハードウェアおよびソフトウェアアーキテクチャの別のブロック図を示す。図１Ａとは異なり、ターゲットコンピュータプログラムは、ホストシステム１１８上で実行される。例えば、図１Ｂは、Ｗｉｎｄｏｗｓプログラムがコンパイルおよびリンクされてコンピュータシステム上で実行され、Ｗｉｎｄｏｗｓを実行している場合を示している。
図２は、本明細書に開示されたデバッガおよびコンパイラシステムの実施形態を含むハードウェアおよびソフトウェアアーキテクチャのブロック図を示す。実施形態では、本明細書に開示されたシステムは、オペレーティングシステム２０４によって動作および管理されるハードウェア層２０２を含む。多くの従来のデバッガシステムとは異なり、本明細書に開示されたシステムは、（本明細書に記載の）単一化ログなどのトレースデータロガー２０７を含むことができる。実施形態では、トレースデータロガー２０７は、ターゲットプログラム２１４の実行から生成されたトレースデータを収集するように構成される。実施形態では、オペレーティングシステム２０４は、デバッガ２１２にトレースデータを提供するためにトレースデータロガー２０７にアクセスするように構成されているエージェント２２２を含むことができる。実施形態では、エージェント２２２は、ターゲットプログラム２１４と通信するように構成されることができる。例えば、システムは、さもなければターゲットプログラム２１４によって直接にアクセスできないトレースデータを検索するため、および他のデバッグタスクを実行するためにエージェント２２２を利用することができる。実施形態では、（例えばカーネルなどの）オペレーティングシステム２０４は、さもなければターゲットプログラム２１４によって直接にアクセスできないトレースデータを記録するように修正され、それは、ターゲットプログラム、レジスタデータ等の動作環境の外部のメモリへのアクセスなどのオペレーティングシステムイベントを含み、さらに、バッファ管理を行い、デバッグに関連する追加のタスクを実行するように修正される。実施形態では、デバッガ２１０は、トレースデータロガー２０７により記憶されたトレースデータにアクセスするためにログダウンローダ２１２を介してエージェント２２２と通信するように構成されることができる。
実施形態では、デバッガ２１０は、ターゲットプログラムのクラッシュまたは停止にまで至るイベントの再生および／または再構成を提示するためにトレースデータをデコードして処理するように構成されている。実施形態では、インタフェースマネージャ２１６は、（本明細書に記載の）時間走行デバッガならびに他の構成要素を含むことができ、トレースデータに基づいてイベントの再生および／または再構成を表示するためのグラフィカルユーザインタフェースを提供するように構成されることができる。実施形態では、コンパイラおよびリンカプログラム２０８は、オブジェクトコードにコンパイルされて実行可能コードにリンクされるべきソースコードを受信するように構成されることができる。リンカは、実行可能コードへと必要なライブラリ２０６を伴うコンパイルされたオブジェクトコードをリンクするように構成されることができる。
実施形態では、コンパイラおよびリンカプログラム２０８は、インストルメント化ジェネレータ２１１を含む。実施形態では、コンパイラおよびリンカプログラム２０８は、ターゲットプログラムを解析し、および／またはターゲットプログラムのコード内の位置を識別するように構成され、そこには、インストルメント化コードがターゲットプログラムの実行中に有用なトレースデータを生成するために挿入される。実施形態では、インストルメント化ジェネレータ２１１は、コンパイラおよびリンカプログラム２１８の解析に基づいて、ターゲットプログラム内の識別された位置（複数可）にコードを生成および／または挿入するように構成される。実施形態において、インストルメント化コードは、ターゲットプログラムのコードに挿入され、それにより、コンパイラおよびリンカプログラム２１８が、ターゲットプログラムのコードならびにターゲットプログラムのコードに埋め込まれているインストルメント化コードを、コンピュータが実行するためのバイナリターゲットプログラム２１４にコンパイルできる。実施形態では、インストルメント化コードはまた、ターゲットライブラリ２０６のコードに挿入される。
実施形態では、トレースロガー２０７およびインストルメント化ジェネレータ２１１によって生成されたインストルメント化コードは、１つ以上のトレースデータログ２０９に記憶するためのトレースデータを生成するように構成される。例えば、トレースデータログ２０９は、（オペレーティングシステム２０４によって実行中の１つ以上の実行のスレッドの）インストルメント化コードの実行に関連するトレースデータを保存するための第１のログ、および、オペレーティングシステムによってそれぞれ実行されるタスクに関連付けられているトレースデータを保存するための第２のログを含むことができる。別の例として、単一の組み合わされたトレースデータログ２０９は、インストルメント化コードによって、およびオペレーティングシステムによって生成されたトレースデータのために使用されることができる。
実施形態では、システムは、システムの一部であるデバッガ２１０を有することなく、ターゲットプログラムをデバッグするためのトレースデータを収集するように構成されることができる。例えば、システムは、ターゲットプログラムにインストルメント化を挿入するように構成されたインストルメント化ジェネレータ２１１を有するコンパイラおよびリンカ２０８などのコンパイラを含むことができる。前記インストルメント化は、ターゲットプログラムが動作している遠隔位置またはフィールドから検索されることができるトレースデータを生成および／または収集するように構成されている。検索されたトレースデータは、ターゲットプログラムのバグを解決するためのデバッガを有している別のシステムで解析されることができる。別の例として、システムは、インストルメント化ジェネレータ２１１を有するコンパイラおよびリンカ２０８を含まなくともよく、トレースデータを生成および／または収集するように構成された、以前にインストルメント化（およびコンパイル）されたターゲットプログラムを実行し得、これは、デバッガを有する別のシステム上で検索および解析されることができる。図１Ｂに示されているように、図２のシステムは、コンパイラおよびリンカ２０８とインタフェースマネージャ２１６とがターゲットプログラム２１４と同じコンピュータシステム上で実行されるように修正されることができる。
図３は、本明細書に開示されたデバッガおよびコンパイラシステムの実施形態（または改善バックエンドの実施形態）の例示的な利点を示す棒グラフを示す。グラフ３０２を参照して、従来のデバッグシステムに対して本明細書に開示されたシステムの実施形態によって達成される技術的改良の例が示されている。実施形態では、システムは、システムのユーザが１秒以内にデバッグを開始することができるように、ターゲットプログラムのクラッシュまたは他の停止にまで至るイベントを再生および／または再構成するように構成することができる。従来のデバッグシステムを使用すると、同じターゲットプログラムのクラッシュまたは他の停止にまで至るイベントの再生および／または再構成は、ログのサイズに比例した時間がかかるだろう。この例では、従来のデバッグシステムは、トレースデータファイルの先頭から開始するおよそ１ギガバイトのトレースデータを解析するのに約２０分かかるであろう。本明細書に開示されるシステムおよび方法の実施形態を利用することによって、１ギガバイトのトレースデータファイルを処理する、または、ユーザにそれへのアクセスを提供するのに約１秒しかかからず、これは、本明細書のシステムが、ファイルの最後から出発してトレースデータファイルを解析し、数秒以内に使用可能情報をユーザに提供する（それにより、いくつかの従来のデバッグシステムが、必要とした１ギガバイトのデータファイル全体を処理するのに必要な時間を大幅に回避する）よう構成されることができるからである。
グラフ３０４を参照すると、ターゲットプログラムの実行中にイメージ化されるターゲットコンピュータシステムのメモリの一部の例が示されている。実施形態では、本明細書に開示されるシステムは、最大でメモリの１００％を含むメモリの任意のサブセットをイメージ化するよう構成されることができる。比較して、いくつかの従来のデバッガシステムは、同一のターゲットプログラムの実行中に利用されるメモリの２５％以下をイメージ化し得るのみである。
グラフ３０６を参照すると、従来のデバッグシステムとは対照的に、本明細書に開示されたシステムの実施形態を用いてプログラマが達成することができる時間節約の例が示されている。例えばプログラマは、本明細書に開示されたシステムの実施形態を利用することにより、わずか５分以下でプログラムのバグを解決することができる。対照的に、従来のデバッガを使用する同じプログラマは、同じターゲットプログラム内の同じバグを解決しようとすると、少なくとも２０分、おそらくはそれ以上を費やす必要がある。一般的に、プログラマは、トレースデータログファイルを処理するためにデバッグプログラムを待つのに費やす時間が少ないので、本明細書に開示されたシステムの実施形態を利用してバグを解決する上でより効率的になることができる。トレースデータログファイルを数秒以内に処理することができる場合、プログラマはバグの解決により容易に集中することができる。対照的に、プログラマがトレースデータログファイルを処理するために２０分以上待たなければならない場合、プログラマはプログラムのバグの解決への集中力を失い始める可能性がある。
《コンパイルおよびデバッグ》
図４は、コンピュータプログラムをコンパイルしてデバッグするための高レベルプロセスの実施形態を示すフローチャートである。本明細書に開示されたシステムの実施形態は、ターゲットプログラムの実行を再構成および／またはシミュレートするためのコンパイラおよびデバッグシステムを含むことができる。ターゲットプログラムの実行を再構成および／またはシミュレートすることで、プログラマは、迅速に、効率的に、かつ正確にコンピュータプログラムをデバッグするために、このような情報を利用することができる。実施形態では、高レベルプロセスは、ブロック４０２で開始することができ、ブロック４０４において、システムは、コンピュータプログラムのソースコードファイルにアクセスするように構成されることができる。ブロック４０６において、システムは、システムのコンパイラを使用してターゲットプログラムに関連付けられたソースコードをコンパイルするように構成されることができる。コンパイラはさらに、トレースデータを生成するように構成されたインストルメント化命令を挿入することによって、ソースコードをインストルメント化するよう構成されることができる。ブロック４０８において、システムは、実行可能な機械可読プログラムを出力するためにリンカを利用するように構成されることができる。ブロック４１０において、システムは、トレースデータを収集し、ログファイルにそのようなデータを保存するように構成されたオペレーティングシステム上で機械可読プログラムを実行するように構成されることができる。ブロック４１２において、システムは、保存されたトレースデータに基づいてプログラムの実行を再構成および／またはシミュレートするために、デバッガシステムを利用するように構成されることができる。ブロック４１４において、プログラマは、再構成および／またはシミュレーションを解析するために、デバッガシステムのグラフィカルユーザインタフェースを利用することができる。グラフィカルユーザインタフェースを動的に変更または更新することができる。この解析を通して、プログラマは、プログラムのバグを特定し、任意のそのようなエラーを解決することができる。ブロック４１６では、プログラマはデバッガシステムによって生成された再構成および／またはシミュレーションの自身の解析に基づいて、ターゲットプログラムのソースコードをリバイズすることができる。任意選択的に、このプロセスは、ブロック４０４に戻って再度、処理を開始することができる。代替的に、プロセスは、ブロック４１８で終了することができる。実施形態では、プロセスを、オペレーティングシステムによって実行中の（すべての実行のスレッドについてを含む）複数の実行のスレッドについて実行することができる。
図５は、オペレーティングシステムおよびターゲットプログラムと相互作用するコンパイラシステムおよびデバッグシステムの実施形態の高レベルの概要を示すブロック図である。実施形態では、本明細書に開示されたシステムは、コンパイラシステム（これはまたリンカシステムを含むことができる）、オペレーティングシステム、および／または、デバッグシミュレーションシステムを含むことができる。実施形態では、ブロック５０２で、コンピュータプログラムは、コンパイラシステムを使用してコンパイルされ、リンクされる。コンピュータプログラムはまた、トレースデータを生成するためにインストルメント化される。実施形態では、ブロック５０４において、コンパイルされたターゲットプログラムは、アプリケーション層で、オペレーティングシステム、または両方で実行される。ターゲットプログラムは、実行時にログファイルにトレースデータを出力するように構成されることができる。トレースデータの収集を、オペレーティングシステムによって部分的に完了することができる。実施形態では、オペレーティングシステムは、ターゲットプログラムがアクセス権を持たないターゲットプログラムの代わりに、オペレーティングシステムによって実行されるそれらのアクションをトレースデータとして記録するよう修正される（例えばそのカーネルが修正される）。そのようなアクションとして（ｉ）オペレーティングシステムサービスの呼び出し（例えばＡＰＩ）、（ｉｉ）１つ以上のプリライト値の記録を含む、（例えば、オペレーティングシステムサービスまたはＡＰＩに応答した）ターゲットプログラムのメモリ内のオペレーティングシステムによって実行される変更、（ｉｉｉ）ターゲットコンピュータプログラムに代わって実行されるオペレーティングシステムサービス、（ｉｖ）タスク切り替え、などが挙げられる。トレースデータは、コンパイルされたターゲットプログラムおよびオペレーティングシステムの両方の実行によって収集されることができる。１つの実施形態では、オペレーティングシステムおよびターゲットプログラムによって収集されたトレースデータは、単一トレースデータログファイルに保存される。別の実施形態では、オペレーティングシステムおよびターゲットプログラムによって収集されたトレースデータは、デコードプロセス中に合成されてもされなくともよい２つ以上の別個のトレースデータログファイルに保存される。デバッグ／シミュレーションシステムは、ターゲットプログラムの実行から生成されたデバッグデータをブロック５０６で処理およびデコードするように構成されることができる。デコードされたデバッグデータは、１つ以上のバグの識別および解決を容易にするためにグラフィカルユーザインタフェースでユーザに提示されることができる。グラフィカルユーザインタフェースを動的に変更または更新することができる。
図６は、ターゲットコンピュータプログラムの実行中に発生するイベントを再生および／またはシミュレートするように構成されたデバッグシステムの実施形態の高レベルの概要を示すブロック図である。タイムライン６０２は、ターゲットプログラムの実行を示す。図示のように、タイムライン６０２は、プログラムが実行されると生じるメモリアクセス、関数呼び出しなどの多数のイベントを含む。最終的に、ターゲットプログラムは、クラッシュ、ブレークポイント、特定のメモリアドレスへのアクセス、実行を停止するユーザ要求等のうちの１つ以上を含むことができる、停止条件６０４に達する。停止条件６０４にまで至る一連のイベント６０８、６１０、６１２を含むことができる関心対象の領域６０６がある。関心対象の領域６０６は、ターゲットプログラムをデバッグするために非常に重要であり、それは、多くの場合、即座に停止条件にまで至るイベントがプログラマに、ソフトウェアのバグの性質に最も重要な洞察力を提供するからである。バグの性質を理解することで、プログラマはより容易にプログラムのエラーをフィックスすることができる。実施形態では、システムは、時間走行デバッガおよびグラフィカル表示ツールなどの１つ以上のユーザインタフェースを使用してプログラマに一連のイベント６１４を提示するように構成されることができる。そのようなユーザインタフェースを動的に変更または更新することができる。イベントは、まずプログラマに最も関連性の高い情報を利用可能にするように、停止条件６１８から始まる逆時間順６１６でデコードされる。例えば、システムが停止条件６０４からイベント６１２にステップバックするのにかかる時間を約１秒とすることができ、一定のアルゴリズム的複雑さでシステムによって必要な計算が実行される。トレースデータの収集ならびに再生および／またはシミュレーションのさらなる詳細は、特許第７，６５３，８９９号；第８，０１５，５５２号；第８，１３２，１５９号；第８，１３６，０９６号；第８，２７１，９５５号；第８，５８４，０９７号；第８，７８９，０２３号；および第８，９１４，７７７号および特許公開第２０１４／０２９８３０１号において記載され、これらの各々の開示はその全体が参考として援用される。
実施形態では、ブロック６２２において、システムは、システムによって実行されるターゲットコンピュータシステムの解析および／または状態のビジュアル化を表示するように構成されることができ、よってプログラマは、ソフトウェアプログラムでのエラーを識別することができる。
図７は、コンピュータプログラムをコンパイルしてデバッグする実施形態を示すフローチャートである。実施形態では、システムは、コンパイラシステム（これはまたリンカシステムを含む）、オペレーティングシステム、およびデバッグ／シミュレーションシステムを含むことができる。実施形態では、プロセスは、ブロック７０２で開始することができ、コンパイラシステムは、ブロック７０４でコンパイルするためのソフトウェアコードを解析する。ブロック７０６で、コンパイラは、ソフトウェアコードにインストルメント化コードを挿入するように構成されることができる。ブロック７０８で、コンパイラシステムは、オブジェクトファイル（複数可）を生成するように構成されることができる。ブロック７１０において、リンカシステムは、オブジェクトファイル（複数可）をリンクするように構成されることができる。任意選択的に、ブロック７１０において、リンカシステムは、１つ以上のライブラリオブジェクトファイル（複数可）をリンクすることができる。ブロック７１２において、コンパイラシステムは、実行可能な機械可読プログラムファイルを出力するよう構成されることができる。ブロック７１４で、オペレーティングシステムは、（タスクとしてオペレーティングシステムによって実行されることができる）コンパイラシステムによって出力されたプログラムファイルの実行を協調させるように構成されることができる。ブロック７１６で、オペレーティングシステムは、基本ブロックなどのブロックの実行、および／またはプログラム内の関数を協調させるように構成されることができる。ブロック７１８で、オペレーティングシステムは、様々なメモリ値、プロセッサレジスタなどへのオペレーティングシステムのアクセスを介してなど、デバッグデータ（例えばオペレーティングシステムイベント）を収集するように構成されることができる。ブロック７１８で収集されたデバッグデータは、レジスタスナップショットおよびメモリアクセス（プリライト値などの）を含むことができる。ブロック７２０で、オペレーティングシステムは、メモリ、例えばデバッグデータを保存するために指定されたログまたはデータベース７２２にデバッグデータを保存するように構成されることができる。
ブロック７２４において、システムは、メモリ内にデバッグデータを保存するためのプログラムの命令のインストルメント化命令を実行するように構成されることができる。ブロック７２４において収集されたデバッグデータは、不揮発性メモリ位置および副作用なしの揮発性メモリ位置についてのプリライトメモリ値、副作用を伴う揮発性メモリ位置から読み出した値、基本ブロックへのエントリを示す値、および／またはＦＥＥデータを含むことができるが、これらに限定されない。ブロック７２６では、システムは、クラッシュ、ブレークポイント、メモリアクセス、ユーザの介入などを含むことができる停止条件を検出するように構成されることができる。ブロック７２８において、システムは任意選択的に、メモリ内のデバッグデータ、例えば停止条件時におけるオペレーティングシステム内のメモリ値を記憶するように構成されることができる。このデバッグデータは、停止条件をトリガした１つ以上の条件のクラッシュまたは実行の時におけるターゲットコンピュータシステムのメモリイメージ（またはターゲットコンピュータシステムのメモリに保存された値）および／または１つ以上のレジスタスナップショットを含むことができる。実施形態では、データベース７３０は、ブロック７２４および７２８にてデバッグデータを記憶するために利用される。実施形態では、データベース７２２および７３０は、単一データベースに統合することができる。ブロック７３２で、デバッグ／シミュレーションシステムは、データベース７３０，７２２に保存されたデバッグデータにアクセスするように構成される。ブロック７３４で、デバッグ／シミュレーションシステムは、保存されたデバッグデータに基づいて停止条件における、およびその前のシステムの状態を再構成／再生するよう構成される。
図１０Ａは、コンピュータプログラムの実行中にデバッグ用トレースデータを生成するためのプロセスの実施形態を示すフローチャートである。実施形態では、コンパイルされたソフトウェアプログラムの実行は、コンパイルプロセス中にソフトウェアプログラムに挿入されたインストルメント化コードの実行を引き起こすであろう。例えば、インストルメント化コードの実行により、プリライトメモリ値が、ターゲットプログラムの実行中にトレースログファイルに保存されることが可能である。トレースログファイルは、停止条件にまで至るイベントを再生および／または再構成するために利用されることができる。
ターゲットコンピュータプログラムを実行するためのプロセスは、ブロック１００２で開始することができ、ブロック１００４で、プログラムは、コンピュータプログラムの第１の基本ブロックを入力することによって実行されることができる。ブロック１００６で、基本ブロック内のインストルメント化が実行され、基本ブロックに関連付けられた一意識別子（または基本ブロックが実行されていることを識別する他の値）が識別される。ブロック１００８で一意識別子は、トレースデータログに保存される。実施形態では、一意識別子は、ブロック１００８において（予約レジスタなどの）レジスタに保存されたポインタによってポイントされたメモリに保存されることができ、これは、インストルメント化コードの実行をスピードアップし、それによりターゲットコンピュータプログラムの実行への影響を低減し得る。ブロック１０１０では、基本ブロック内の命令が実行される。ブロック１０１２で、追加のインストルメント化は、任意選択的に実行される。実施形態では、基本ブロックがメモリへ書き込みしようとしているときのインストルメント化は、任意選択的にブロック１０１２で実行される。インストルメント化は、基本ブロックがメモリ位置に書き込む前に、メモリ位置からトレースログファイルへのプリライト値の読み出しおよび／または記憶を行うように構成されることができる。任意選択的に、ブロック１０１４で、ブロック１０１２のインストルメント化は、メモリ内のプリライト値をトレースログファイルに保存させ、基本ブロックはメモリへの書き込みを行える。ブロック１０１２および１０１４がトレースデータログにプリライトメモリ値を保存するよう実行されない場合であっても、基本ブロックは、依然としてメモリへの書き込みを行い得る。ブロック１０１６において、実行のための次の基本ブロックがあるかどうかをプロセスは判断する。そのような基本ブロックが識別された場合、プロセスはブロック１００６に戻ることができる。そのような基本ブロックが検出されない場合、プロセスはブロック１０１８で終了することができる。
留保トレースデータ最適化を利用する場合、図１０Ａに示すように、ブロック１００６および１００８が実行されない。むしろ、ブロック１００６および１００８が、ブロック１０１４の後などの、基本ブロックの最後で実行される。
図１０Ｂは、コンピュータプログラムの実行中にトレースデータを生成するためのプロセスの実施形態を示すフローチャートである。ブロック１００２〜１０１４、１０１６および１０１８の動作は、図１０Ａに関連して記載されている。図１０Ａ中のプロセスと同様に、実施形態では、本明細書に開示されたシステムは、不揮発性メモリ位置および副作用なし揮発性メモリ位置に記憶されているプリライト値をトレースデータログファイルへと保存するだけではないように構成されることができる。システムはまた、基本ブロックの命令でアクセスされる副作用つき揮発性メモリのメモリ位置のアドレスを記録するように構成されることができる。ブロック１０１５では、プロセスは任意選択的に、副作用つき揮発性メモリ位置にプログラムによるストアのアドレスを記録する。ここで説明したように、副作用を有する揮発性メモリの位置に保存された値は、他のプログラムにより変更することができ、および／または、このような揮発性メモリ位置を読み取ることにより、保存された値を変更することができる。したがって、プリライト値を記録するためのインストルメント化は、このような揮発性メモリ位置について使用されなくともよい。ブロック１０１５が実行されない場合であっても、基本ブロックは、依然としてそのような揮発性メモリ位置へのアクセスが可能であり得る。
《関数エントリおよびイグジット（ＦＥＥ）インストルメント化》
図１１は、関数からなるソフトウェアプログラムの実施形態の高レベルの概要を示すブロック図である。実施形態では、ソフトウェアプログラム１１００は、複数の関数から構成されることができる。本明細書で説明されるように、関数との用語は、一般的にソフトウェアプログラムの名前付きセクションまたは特定のタスクを実行する命令のグループを指す。実施形態では、ソフトウェアプログラム１１００は、第１の関数（関数１）１１０２を含むことができ、これはプログラム（例えば主関数）へのエントリポイントとすることができる。実施形態では関数１は、１１０４で関数２に、１１０６で関数３に分岐することができる。関数２は、他の関数１１０８および１１１０につながる多数の他の分岐を含むことができる。
実施形態では、１つ以上のリーフ関数は、ＦＥＥインストルメント化でインストルメント化されない。リーフ関数は、別の関数によって呼び出され得るが、それ自体は任意の他の関数を呼び出さない関数として定義することができる。後続する基本ブロックでのみ実行される基本ブロックに関連して説明した最適化と同様に、ＦＥＥインストルメント化は、リーフ関数では省略され得る。代わりに、実施形態では、（本明細書に記載されるような）静的ルックアサイドテーブルが、別個にインストルメント化されなかったリーフ関数の実行を示すことができる。本明細書に記載されるように、いくつかの実施形態では、静的ルックアサイドテーブルは、再生および／または再構成の間にトレースデータファイルにリーフ関数の実行に関連する適切なデータを挿入するために使用されることができる。実施形態では、同様のアプローチを、小さな関数、例えばＸ個（Ｘは調整可能パラメータ）未満の命令に適用することができる。
《最適化》
本明細書で説明されるシステムおよび方法の実施形態は、とりわけ、本明細書に記載される以下の最適化の１つ以上を利用することができる：後続する基本ブロックでのみ常に実行されるいくつかのまたはすべての基本ブロックへのエントリを別個に記録しないこと、図８Ｃおよび図８Ｄに関連して説明された最適化を行うこと、基本ブロックの最後に関連付けられたプログラムカウンタ値を記録すること、留保トレースデータ最適化、リーフ関数のインストルメント化をスキップすること、スタックエントリおよびイグジットマーカーを挿入しないこと。これらの最適化の１つ以上を使用することは、とりわけ、トレースデータの大きさの減少、ならびに、再生、再構成および／またはシミュレーションについての時間の短縮のうちの１つ以上に有利につながることができる。
《ユーザインタフェース》
図１３Ａ、図１３Ｂは、時間走行デバッガシステムのグラフィカルユーザインタフェースを示す。図示のグラフィカルユーザインタフェースは、再生および／または再構成中に提示されることができる。実施形態では、ユーザは、グラフィカルユーザインタフェース１３００と相互作用し、ターゲットコンピュータプログラムの実行をステップスルーしてターゲットコンピュータプログラムのソースコード内の対応する行と実行とを比較することができ、これは、プログラマがターゲットプログラムをデバッグするのを助けることができるプロセスである。本明細書に記載されるように、ユーザアクティビティまたは選択に応答して、グラフィカルユーザインタフェースを動的に変更または更新することができる。実施形態では、グラフィカルユーザインタフェース１３００は、ユーザにソースコードを表示するための表示領域１３２２を含む。実施形態において、表示領域１３２２はまた、ターゲットプログラムの実行の再生または再構成を提示するための各種のデータを含み、例えば、実行コマンド、入力／出力、変数値／変更、レジスタ値／変更、メモリ値／変更、スタックトレース、ブレークポイント、ソースコード、ブレークポイントが配置され得る箇所を示すブレークドット等である。実施形態では、プログラムの現在の行および／またはデバッグされる時点は、矢印１３３２によって示される。実施形態では、コマンドの現在のコンテキストは、矢印１３３０によって示される。
実施形態では、グラフィカルユーザインタフェース１３００は、ボタン１３０２〜１３１６を含み、これらによりユーザはターゲットコンピュータプログラムを時間的に前方および後方に実行または実施することができ、共通のデバッガコントロールおよびそれらの時間的後方変種を使用してトレースログの時間的に前方および後方への移動が可能となる。それらは、ソース行およびアセンブリ命令の両方のデバッグで同様に動作する。実施形態では、ボタン１３０２により、ユーザが後方に（現在の関数などの）ターゲットコンピュータプログラムを実行し、または、その実行をシミュレートすることができる。実施形態では、ボタン１３０４により、ユーザが、現在の関数を呼び出した（以前の関数などの）ソースコード内の命令の以前のシーケンスまで戻ることができる。実施形態において、ボタン１３０６により、ユーザが同じスタックレベルで実行される以前の命令またはソース行に単一ステップ戻ることができる。実施形態では、ボタン１３０８により、ユーザが、実行された以前のソース行が関数呼び出しであった場合に、実行された以前の命令またはソース行に、および、関数呼び出しの命令またはソースコードに単一ステップ戻ることができる。ボタン１３０２〜１３０８により、ユーザは、時間的に後方にターゲットコンピュータプログラムの実行を再生および／または再構成することができる。
実施形態では、ボタン１３１０により、ユーザが次の命令またはソース行が関数呼び出しである場合、実行またはシミュレートされる次の命令またはソース行におよび関数へと単一ステップ進むことができる。実施形態では、ボタン１３１２により、ユーザはソースコードにおける次の命令または行（または単一のステップ）を実行またはシミュレートすることができる。実施形態では、ボタン１３１４により、ユーザが（次の関数へとコールスタックを上がってゆくことをもたらすことができる関数などの）命令の現在のシーケンスからステップアウトすることができる。実施形態では、ボタン１３１６により、ユーザが（現在の関数などの）ターゲットコンピュータプログラムを前方に実行またはシミュレートすることができる。実施形態では、ボタン１３１８により、ユーザがターゲットコンピュータプログラムの実行またはシミュレーションを停止することができる。ボタン１３１０〜１３１６により、ユーザはターゲットコンピュータプログラムを時間的に前方に実行またはその実行をシミュレートすることができる。
実施形態では、本明細書に開示されるシステムは、（１秒以内または数秒以内などの）一定のアルゴリズムの複雑さにてトレースデータデバッグを開始するのに必要な計算を実行するように構成され、これにより、ユーザがプログラム停止のほぼ直後に本明細書のユーザボタンを利用することができ、よってユーザは、従来のデバッグシステムと比較してより迅速にターゲットプログラムをデバッグすることができる。例えば、ボタン１３０２〜１３１８の１つ以上に関連したプロセスの各々は、ユーザにリアルタイムまたはほぼリアルタイムの経験を提供するために、１秒以内または数秒以内に実行またはシミュレートされることができる。
実施形態では、グラフィカルユーザインタフェース１３００は、１つ以上の追加ボタンおよび／または構成要素を含む。実施形態では、グラフィカルユーザインタフェース１３００は、ターゲットコンピュータシステムのメモリの一部または全体のビューを可能にするボタン１３３２を含む。実施形態では、グラフィカルユーザインタフェース１３００は、ターゲットコンピュータシステムのレジスタの一部または全体のビューを可能にするボタン１３３４を含む。実施形態では、グラフィカルユーザインタフェース１３００は、ターゲットコンピュータプログラムのローカル変数の一部または全体のビューを可能にするボタン１３３６を含む。
実施形態では、グラフィカルユーザインタフェース１３００により、ユーザがその時点でその変数の値を示すソースコードディスプレイ１３２２内の任意の変数を（例えばダブルクリックまたは他の作用を介して）選択することができる。ユーザはまた、先に本明細書に記載した任意のアクションを行うために領域１３２０にテキストコマンドを入力し得る。領域１３２４は、実行中のオペレーティングシステムタスクのビューを含む。矢印１３２６によって示されるように、デバッグ中のタスクは、強調表示されたタスク（「初期」）である。
《コンピューティングシステム》
実施形態では、本明細書で説明されるシステム、プロセスおよび方法が、図１４に示したものなどのコンピューティングシステムを使用して実装される。例示的なコンピュータシステム１４０２は、１つ以上のネットワーク１４１８を介して１つ以上のコンピューティングシステム１４２０および／または１つ以上のデータソース１４２２と通信している。図１４はコンピューティングシステム１４０２の実施形態を示すが、コンピュータシステム１４０２の構成要素およびモジュール内で提供される機能は、より少数の構成要素およびモジュールに結合、または、さらに追加的な構成要素およびモジュールに分離され得ることが認識される。
《ソフトウェア開発環境》
コンピュータシステム１４０２は、本明細書で説明する機能、方法、作用および／またはプロセスを実行するソフトウェア開発環境およびターゲットシステム１４１４を含む。ソフトウェア開発環境およびターゲットシステム１４１４は、本明細書にさらに論じられる中央処理ユニット１４０６によりコンピュータシステム１４０２上で実行される。実施形態ではターゲットシステムは、本明細書に示されるように、ソフトウェア開発環境１４１４と同じコンピュータシステム１４０２に常駐するのとは反対に、別のコンピュータシステム内に常駐し得る。
《コンピューティングシステムコンポーネント》
コンピュータシステム１４０２は、マイクロプロセッサなどのプロセッサを含み得る１つ以上の処理ユニット（ＣＰＵ）１４０６を含む。実施形態において、コンピュータシステムは、対称型マルチプロセッサまたは対称マルチコア（ＳＭＰ）システムなどのＳＭＰシステムである。コンピュータシステム１４０２はさらに、情報の一時的保存のためのランダムアクセスメモリ（ＲＡＭ）、情報の永久記憶のための読み出し専用メモリ（ＲＯＭ）、および、ハードディスクドライブ、ソリッドステートドライブ（ＳＳＤ）、フロッピーディスクまたは光学媒体記憶デバイスなどのマスストレージデバイス１４０４などのメモリ１４１０を含む。あるいは、マスストレージデバイスは、１つ以上のサーバで実装され得る。典型的には、コンピュータシステム１４０２の構成要素は、規格ベースのバスシステムを使用してコンピュータに接続される。バスシステムは、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）、マイクロチャネル、ＳＣＳＩ、インダストリアルスタンダードアーキテクチャ（ＩＳＡ）およびエクステンデッドＩＳＡ（ＥＩＳＡ）アーキテクチャなどの様々なプロトコルを使用して実装することができる。
コンピュータシステム１４０２は、キーボード、マウス、タッチパッドおよびプリンタなどの１つ以上の入力／出力（Ｉ／Ｏ）デバイスおよびインタフェース１４１２を含む。Ｉ／Ｏデバイスおよびインタフェース１４１２は、ユーザにデータを視覚的に提示することができる、モニタなどの１つ以上の表示デバイスを含むことができる。より具体的には、表示デバイスは、例えばアプリケーションソフトウェアデータおよびマルチメディアプレゼンテーションなどのグラフィカルユーザインタフェース（ＧＵＩ）の提示を提供する。Ｉ／Ｏデバイスおよびインタフェース１４１２はまた、様々な外部デバイスへの通信インタフェースを提供することができる。コンピュータシステム１４０２は、例えばスピーカ、ビデオカード、グラフィックスアクセラレータおよびマイクロフォンなどの１つ以上のマルチメディアデバイス１４０８を含み得る。
《コンピューティングシステムデバイス／オペレーティングシステム》
コンピュータシステム１４０２は、サーバ、Ｗｉｎｄｏｗｓサーバ、ＵＮＩＸサーバ、パーソナルコンピュータ、ラップトップコンピュータおよび同様のものなどの様々なコンピューティングデバイス上で実行され得る。コンピューティングシステム１４０２は一般的に、ｚ／ＯＳ、Ｗｉｎｄｏｗｓ９５、Ｗｉｎｄｏｗｓ９８、ＷｉｎｄｏｗｓＮＴ、Ｗｉｎｄｏｗｓ２０００、ＷｉｎｄｏｗｓＸＰ、ＷｉｎｄｏｗｓＶｉｓｔａ、Ｗｉｎｄｏｗｓ７、Ｗｉｎｄｏｗｓ８、Ｗｉｎｄｏｗｓ１０、Ｌｉｎｕｘ、ＯＳ Ｘ、ＢＳＤ、ＳｕｎＯＳ、Ｓｏｌａｒｉｓ、ＩＮＴＥＧＲＩＴＹ、または独自のオペレーティングシステムを含む他の互換性のあるオペレーティングシステムなどの、オペレーティングシステムソフトウェアによって制御されて協調されている。オペレーティングシステムは、実行についてのコンピュータプロセスの制御およびスケジューリング、メモリ管理の実行、ファイルシステム、ネットワーキングおよびＩ／Ｏサービスの提供、ならびに／または、とりわけＧＵＩなどのユーザインタフェースの提供を行うことができる。
《ネットワーク》
図１４に示すコンピュータシステム１４０２は、ＬＡＮ、ＷＡＮまたはインターネットなどのネットワーク１４１８に、通信リンク１４１６（有線、無線、またはそれらの組み合わせ）を介して結合されることができる。ネットワーク１４１８は、様々なコンピューティングデバイスおよび／または他の電子デバイスと通信する。ネットワーク１４１８は、１つ以上のコンピューティングシステム１４２０および１つ以上のデータソース１４２２と通信することができる。
出力モジュールは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、または、ディスプレイの他のタイプおよび／もしくは組み合わせなどのとして全点アドレス可能ディスプレイの組み合わせとして実装され得る。出力モジュールは、入力デバイス１４１２と通信するように実装され得、それらはまた、ユーザが、メニュー、ウィンドウ、ダイアログボックス、ツールバーおよびコントロール（例えばラジオボタン、チェックボックス、スライドスケール等）などの定型化された画面要素の使用を介してデータにアクセスできる適切なインタフェースを伴うソフトウェアを含む。さらに、出力モジュールは、ユーザから信号を受信するために入力および出力デバイスのセットと通信し得る。
《追加変形例》
実施形態では、非一時的コンピュータ記憶媒体は、タスクとしてターゲットコンピュータシステムのオペレーティングシステムによって実行されるコンピュータプログラムをデバッグするための命令を含み、命令は、ターゲットコンピュータシステムによって実行されると、実行を停止するための少なくとも１つの条件がトリガされるまで、ターゲットコンピュータシステム上でコンピュータプログラムの複数のプログラム命令を実行することを含む方法を実行し、ターゲットコンピュータシステムはメモリおよび少なくとも１つのプロセッサを含む。方法はまた、ターゲットコンピュータシステム上でコンピュータプログラムの複数の命令を実行しながら、コンピュータプログラムの実行に関連するトレースデータログにトレースデータを記録することを含むことができ、トレースデータは、実行中のプログラム命令のサブセットを識別するデータの第１のセット、コンピュータプログラムによって実行中の複数のメモリ書き込みを識別する第２のデータセット、および、実行を停止するための少なくとも１つの条件がトリガされたときにターゲットコンピュータシステムのメモリに保存されたメモリ値を含む第３のデータセットを含む。この方法はまた、複数のプログラム命令からのプログラム命令実行時のターゲットコンピュータシステムの状態の、少なくとも１つの条件がトリガされたときに実行中のプログラム命令からのコンピュータプログラムの実行とは逆の順序で、再構成用のトレースデータを提供することを含むことができ、再構成は一定のアルゴリズム的複雑さに応じて行われる。
実施形態では、前段落のコンピュータ記憶媒体は、以下の特徴の１つ以上を含むことができる。複数のメモリ書き込みを識別する第２のデータセットは、上書き前にメモリに保存されたデータ値を含むことができる。方法はまた、定期的にコンピュータプログラムの実行中にターゲットコンピュータシステムの少なくとも１つのプロセッサの複数のレジスタに保存されたデータ値の複数のスナップショットを記録すること、および、ターゲットコンピュータシステムの状態の再構成のために複数のスナップショットを提供することを含むことができる。コンピュータプログラムは、トレースデータの少なくとも一部を記録するように構成された複数のインストルメント化命令を含むことができる。複数のインストルメント化命令は、基本ブロックに入ると複数の基本ブロックの各基本ブロックについて実行されるように構成された１つ以上のインストルメント化命令を含むことができ、複数の基本ブロックはコンピュータプログラムに関連付けられ、複数の基本ブロック内の各基本ブロックは、１つのエントリポイントおよび１つのイグジットポイントを有する命令のシーケンスを含む。１つ以上のインストルメント化命令はさらに、基本ブロックの第１の命令を実行する前に実行されるように構成されることができる。１つ以上のインストルメント化命令はさらに、複数の基本ブロックの各基本ブロックの実行に関連付けられた複数の一意識別子をトレースデータログに記録するように構成されることができる。基本ブロックの実行に関連付けられた一意識別子をトレースデータログに記録するように構成された１つ以上のインストルメント化命令は、基本ブロックからのイグジット時に実行されるように構成されることができる。一意識別子は、基本ブロックからのイグジットに関連付けられたプログラムカウンタ値を含むことができる。複数のインストルメント化命令はさらに、コンピュータプログラムの実行中にターゲットコンピュータシステムの少なくとも一部の揮発性メモリ位置の複数のメモリ読み出しを識別するデータを記録しないように構成されることができる。複数のインストルメント化命令はさらに、少なくとも一部の揮発性メモリ位置のアドレスを記録するように構成されることができる。実行を停止するための少なくとも１つの条件は、プログラム命令の実行、メモリアクセス、または別の停止条件の１つ以上を含むことができる。
実施形態では、前の段落のいずれかのコンピュータ記憶媒体は、以下の特徴の１つ以上を含むことができる。方法は、トレースデータログにトレースデータを保存するためのメモリバッファへのポインタとしてターゲットコンピュータシステムの少なくとも１つのプロセッサの予約レジスタを設定することを含むことができる。方法はまた、ターゲットコンピュータシステム上でのコンピュータプログラムの実行中に、メモリバッファへのアクセスに関連したページフォルトをターゲットコンピュータシステムのオペレーティングシステムによって検出すること、トレースデータログにトレースデータを保存するための新たなメモリバッファを割り当てること、および、新たなメモリバッファをポイントするように予約レジスタを設定することを含むことができる。方法はまた、コンピュータプログラムの実行中に、コンピュータプログラムの実行に関連付けられた複数のオペレーティングシステムイベントを別個のトレースデータログに記録することを含むことができる。方法はまた、コンピュータプログラムの実行中に、オペレーティングシステムによって上書きされる１つ以上のメモリ値の前にターゲットコンピュータシステムの１つ以上のメモリ位置に対応する１つ以上のメモリ値を記録することを含むことができる。少なくとも１つのプロセッサは、複数の対称マルチコアプロセッサ（ＳＭＰ）を含むことができ、複数のインストルメント化命令はさらに、複数のＳＭＰの各々のトレースデータに関連付けられている複数のトレースデータログを生成するように構成されることができる。方法はまた、複数のＳＭＰによるコンピュータプログラムの実行に関連するトレースデータを複数のトレースデータログに記録することを含むことができる。方法はまた、複数のタイムスタンプを複数のトレースデータログに定期的に書き込むことを含むことができ、複数のタイムスタンプは、複数のＳＭＰから収集されたトレースデータの同期化を容易にするように構成される。トレースデータログは、コンピュータシステムのメモリに保存することができる。
実施形態では、非一時的コンピュータ記憶媒体は、コンピュータプログラムをデバッグするための命令を含み、命令は、コンピュータシステムによって実行されると、少なくとも１つのトレースデータログに保存されるように構成されたトレースデータを生成するように構成された複数のインストルメント化命令を有するコンピュータプログラムをインストルメント化することを含む方法を実行する。インストルメント化は、コンピュータプログラムに関連付けられた複数の基本ブロックを決定することを含むことができ、複数の基本ブロック中の各基本ブロックは、１つのエントリポイントおよび１つのイグジットポイントを有する命令のシーケンスを含み、インストルメント化はさらに、複数の基本ブロックのうちの少なくともいくつかの基本ブロックについて、コンピュータプログラムに、少なくともいくつかの基本ブロックの複数の基本ブロックエントリポイントを記録するように構成された１つ以上のインストルメント化命令を生成して挿入することを含む。方法は、コンピュータプログラムの実行中に、ターゲットコンピュータシステム上でコンピュータプログラムの実行に関連するトレースデータを少なくとも１つのトレースデータログに記録させることを含むことができ、ターゲットコンピュータシステムはメモリおよび少なくとも１つのプロセッサを含む。
実施形態では、前の段落のいずれかのコンピュータ記憶媒体は、以下の特徴の１つ以上を含むことができる。インストルメント化はさらに、上書きされる前にメモリに保存された１つ以上のメモリ値を記録するように構成されたインストルメント化命令を生成することを含むことができる。インストルメント化はまた、上書きされる少なくともいくつかのメモリ位置のメモリアドレスの記録をスキップすることを含むことができる。インストルメント化はまた、別の基本ブロックと一緒に実行されるように構成された基本ブロックをスキップすることを含むことができる。基本ブロックエントリポイントの少なくとも一部またはターゲットコンピュータシステムの１つ以上のメモリ位置の少なくともいくつかを、仮想メモリ位置とすることができる。複数のインストルメント化命令はまた、ターゲットコンピュータシステムの少なくとも１つのプロセッサの複数のレジスタに保存された値を定期的に記録するように構成されることができる。複数のインストルメント化命令はまた、キャッシュ使用量を改善するように構成されることができる。複数のインストルメント化命令はまた、キャッシュへの影響を軽減することができる。複数のインストルメント化命令の少なくとも一部のインストルメント化命令を、ターゲットコンピュータシステムの少なくとも１つのプロセッサ上で実行するための実行可能ファイルに１つ以上のオブジェクトファイルをリンクする時に無効にすることができる。コンピュータプログラムのインストルメント化はさらに、コンピュータプログラムの１つ以上のコンパイラ指令に遭遇することに応答して、コンピュータプログラムのコンパイル時に少なくとも１つの追加のインストルメント化命令を挿入することを含むことができる。１つ以上のコンパイラ指令は、コンピュータプログラムで同期動作をマークするように構成されることができる。複数のインストルメント化命令はさらに、第２の基本ブロックではなく第１の基本ブロックからのイグジット時に実行されるように構成されることができ、第２の基本ブロックは後続として第１の基本ブロックのみを有する。複数のインストルメント化命令はさらに、第３の基本ブロックではなく第１および第２の基本ブロックからのイグジット時に実行されるように構成されることができ、第３の基本ブロックは後続として第１および第２の基本ブロックのみを有する。
実施形態では、前の段落のいずれかのコンピュータ記憶媒体は、以下の特徴の１つ以上を含むことができる。複数のインストルメント化命令はさらに、コンピュータプログラムの複数の関数について複数の関数エントリおよびイグジットに関連付けられたトレースデータを記録するように構成されることができる。コンピュータプログラムのインストルメント化は、コンピュータプログラムの複数の関数の少なくとも１つのリーフ関数をスキップすることを含むことができる。複数のインストルメント化命令はさらに、トレースデータに複数のタイムスタンプを記録するように構成されることができ、複数のタイムスタンプは、コンピュータプログラムの複数の関数のうちの関数の関数エントリの時間および関数イグジットの時間を記録するように構成される。少なくとも１つのトレースデータログは、複数のインストルメント化命令に関連するトレースデータを記憶するための第１のトレースデータログと、オペレーティングシステムに関連するトレースデータを記憶するための第２のトレースデータログとを含むことができる。
実施形態では、非一時的コンピュータ記憶媒体は、オペレーティングシステムによって実行される複数のタスクからの少なくとも１つのタスクをデバッグするための命令を含み、命令は、ターゲットコンピュータシステムによって実行されたときに、ターゲットコンピュータシステム上のタスクの実行中に収集されたトレースデータを用いて特定の時間におけるターゲットコンピュータシステムの状態を再構成することを含む方法を実行し、ターゲットコンピュータシステムはメモリおよび少なくとも１つのプロセッサを含み、方法はさらに、ターゲットコンピュータシステムの状態を表示することにより、少なくとも１つのタスクでエラーの識別を可能にすることを含む。トレースデータは、少なくとも１つのタスクの複数の基本ブロックの複数の基本ブロックエントリポイントに関連するターゲットコンピュータシステムの複数のメモリ位置、上書きされる１つ以上のメモリ値の前にターゲットコンピュータシステムの１つ以上のメモリ位置に対応する１つ以上のメモリ値、および、ターゲットコンピュータシステムの少なくとも１つのプロセッサの複数のレジスタに保存されたデータ値の複数のスナップショットであって、少なくとも１つのタスクの実行中に定期的に記録される複数のスナップショットを含むことができる。特定の時間にターゲットコンピュータシステムの状態を再構成することはさらに、少なくとも１つのタスクの実行を停止する前に実行される最後の基本ブロックで開始すること、少なくとも１つのタスクの実行の逆の順序でトレースデータをデコードすることであって、ターゲットコンピュータシステムのメモリおよび複数のレジスタに保存されたメモリ値を決定することを含むデコードすること、メモリに格納されたデコードデータ値および複数のレジスタに保存された決定データ値を用いて、特定の時間より前の時間から特定の時間までのターゲットコンピュータシステム上での少なくとも１つのタスクの実行をシミュレートすることを含むことができる。
実施形態では、前の段落のいずれかのコンピュータ記憶媒体は、以下の特徴の１つ以上を含むことができる。トレースデータは、少なくとも１つのタスクの実行が停止されたときにターゲットコンピュータシステムのメモリに記憶されたメモリ値を含むことができ、ターゲットコンピュータシステムの状態を再構成することはさらに、少なくとも１つのタスクの実行が停止されたときにトレースデータに記憶されたメモリ値を使用することを含む。ターゲットコンピュータシステムの状態を再構成することはさらに、複数のメモリ位置の第１のメモリ位置について、第１のメモリ位置アドレスおよび上書きされる前の値をトレースデータから検索すること、および、上書きされる前のメモリ値を第１のメモリアドレスに書き込むことを含むことができる。ターゲットコンピュータシステムの状態を再構成することはさらに、トレースデータに第１のメモリ位置の現在のメモリ値を記憶することを含むことができ、少なくとも１つのタスクの実行をシミュレートすることはさらに、第１のメモリ位置が書き込まれていると判定することに応答して、トレースデータに保存されている現在のメモリ値を検索すること、および、第１のメモリ位置に現在のメモリ値を保存することを含むことができる。ターゲットコンピュータシステムの状態を再構成することはさらに、複数のメモリ位置の第２のメモリ位置について、マッピングファイルに保存された第１のメモリ位置のアドレスおよび情報を用いて第２のメモリ位置のアドレスを決定することを含むことができる。複数の基本ブロックにおける各基本ブロックは、１つのエントリポイントおよび１つのイグジットポイントを有する命令のシーケンスを含むことができる。特定の時間に先行する時間におけるターゲットシステムの少なくとも１つのプロセッサの複数のレジスタに保存されたデータ値を決定することは、時間的に最も近く特定の時間に先行するスナップショットを使用することを含むことができる。ターゲットシステムの少なくとも１つのプロセッサの複数のレジスタに保存されたデータ値を決定することは、別のタスクへのコンテキストスイッチ時に保存されたレジスタ値を使用することを含むことができる。少なくとも１つのタスクは、オペレーティングシステムによって実行される複数のタスクを含むことができる。
《用語》
一般的に本明細書中で使用される用語「モジュール」は、ハードウェアまたはファームウェアで具現されるロジックまたはソフトウェア命令の集合を指す。モジュールは、ＪＡＶＡ、ＣまたはＣ＋＋などのプログラム言語で書かれる。ソフトウェアモジュールは実行可能プログラムにコンパイルまたはリンクされ、ダイナミックリンクライブラリにインストールされ得、または、ＢＡＳＩＣ、Ｐｅｒｌ、ＬＵＡもしくはＰｙｔｈｏｎなどのインタープリタ言語で書かれ得る。ソフトウェアモジュールは、他のモジュールから、または、自身から呼び出され得、および／または、検出されたイベントまたは中断に応じて開始され得る。ハードウェアで実現されたモジュールは、ゲートおよびフリップフロップなどの接続された論理ユニットを含み、および／または、プログラム可能ゲートアレイまたはプロセッサなどのプログラム可能ユニットを含み得る。
一般に、本明細書に記載されるモジュールとは、他のモジュールと組み合わされ得、または、それらの物理的編成またはストレージにかかわらずサブモジュールに分割され得る論理モジュールを指す。モジュールは、１つ以上のコンピューティングシステムによって実行され、任意の適切なコンピュータ可読媒体上またはその内部に保存され得、全体または一部において特別設計ハードウェアまたはファームウェア内に実装され得る。上記の方法、計算、プロセスまたは解析のいずれかがコンピュータの使用を介して容易にされ得るが、すべての計算、解析および／または最適化が、コンピュータシステムを使用する必要があるわけではない。さらに、いくつかの実施形態において、本明細書で説明されるプロセスブロックは、改変され、再配置され、組み合わされ、および／または省略され得る。（任意の添付の特許請求の範囲、要約書および図面を含む）本明細書に開示された特徴のすべて、および／または、そのように開示された任意の方法またはプロセスのステップのすべては、任意の組み合わせで組み合わされ得る。保護は、（任意の添付の特許請求の範囲、要約書および図面を含む）本明細書に開示された特徴の任意の新規な１つ、または任意の新規な組み合わせに、または、そのように開示される任意の方法またはプロセスのステップの任意の新規な１つ、または任意の新規な組み合わせに及ぶ。
本開示において、用語「リアルタイム」は、実質的に瞬間的またはほぼ瞬間的なイベントを指すことができる。換言すれば、「リアルタイム」とはユーザ相互作用時間の概念を指し得、コンテキスト仮想ワークスペースによるまたはそれを伴う処理時間量が、ユーザの反応時間未満（例えば１秒または０．５秒未満）であることなどである。本開示の他の位置では、用語「リアルタイム」は「リアルタイムクロック」というフレーズの一部として使用される。フレーズ「リアルタイムクロック」の一部として使用される場合、「リアルタイム」とは時間の客観的通過を指し、「リアルタイムクロック」とはミリ秒などの共通の単位で時間の客観的経過を測定する機構である。
とりわけ「できる」、「可能性がある」、「かもしれない」または「し得る」などの条件付き言語は、具体的に別様に明記されない限り、または使用される文脈内で別様に理解されない限り、その特定の実施形態は、他の実施形態が含まなくとも、特定の特徴、要素および／またはステップを含むことを伝えることを一般的に意図している。したがって、そのような条件付き言語は、特徴、要素および／またはステップが１つ以上の実施形態のために任意の方法で必要であること、または、１つ以上の実施形態が必ず、ユーザの入力またはプロンプトの有無にかかわらず、これらの特徴、要素および／またはステップが任意の特定の実施形態で含まれる、または実行されるかどうかを決定するためのロジックを含むことを意味することを一般的には意図していない。「備える」、「含む」、「有する」、「含有する」などの用語は同義語であり、包括的に、オープンエンド様式で使用され、追加の要素、特徴、作用、動作などを除外しない。また、用語「または」は、包括的な意味で使用されており（その排他的な意味ではない）、よって、使用される場合、例えば要素のリストを接続するために、用語「または」は、リスト内の１つ、いくつか、またはすべての要素を意味している。さらに、本明細書で使用する用語「それぞれ」は、その通常の意味を有することに加えて、用語「それぞれ」が適用される要素の集合の任意のサブセットを意味することができる。
「Ｘ、Ｙ、およびＺのうちの少なくとも１つ」というフレーズなどの論理積言語は、具体的に別様の記載がない限り、別様に文脈で理解されない限り、項目、ターム等がＸ、ＹまたはＺのいずれであってもよいことを伝えるために一般的に使用される。したがって、そのような論理積言語は、特定の実施形態が、Ｘの少なくとも１つ、Ｙの少なくとも１つおよびＺの少なくとも１つが存在することを必要とすることを意味することを一般に意図していない。本明細書で使用される用語「ほぼ」、「約」、「概して」および「実質的に」などの本明細書で使用される言語の程度は、値、量または特性が、依然として所望の機能を実行する、または所望の結果を実現する、記載された値、量または特性に近いことを表す。例えば、用語「ほぼ」、「約」、「概して」および「実質的に」は、記載された量の５０％未満以内、１０％未満以内、５％未満以内、１％未満以内、０．１％未満以内、０．０１％未満以内を指し得る。本明細書で使用される見出しは読者の便宜のためだけのものであり、本開示または特許請求の範囲を限定することを意味するものではない。本開示は特定の好ましい実施形態および実施例に関連して説明されてきたが、本開示が具体的に開示された実施形態を超えて他の代替実施形態および／または本開示の使用ならびに明白な修正およびその均等物に及ぶことは当業者によって理解されるであろう。さらに当業者は、上記の方法のいずれもが任意の適切な装置を使用して実施できることを認識するであろう。さらに、実施形態に関連した任意の特定の特徴、態様、方法、性質、特性、品質、属性、要素などの本明細書における開示は、本明細書に記載の他のすべての実施形態において使用することができる。本明細書に記載のすべての実施形態について、方法のステップは順次、実行される必要はない。したがって、本開示の範囲は、上記の特定の開示された実施形態によって限定されるべきではないことが意図されている。
本明細書に記載される方法およびタスクのすべては、コンピュータシステムによって実行され、完全に自動化され得る。コンピュータシステムは、いくつかの場合には、説明した機能を実行するために、ネットワークを介して通信および相互運用する（例えば、物理サーバ、ワークステーション、ストレージアレイ等の）複数の異なるコンピュータまたはコンピューティングデバイスを含み得る。そのような各コンピューティングデバイスは典型的には、メモリまたは他の非一時的コンピュータ可読記憶媒体に保存されたプログラム命令またはモジュールを実行するプロセッサ（または複数のプロセッサ）を含む。本明細書に開示される様々な機能は、そのようなプログラム命令で実施され得るが、開示された機能の一部またはすべては、コンピュータシステムの特定用途向け回路（例えばＡＳＩＣまたはＦＰＧＡ）で代替的に実装され得る。コンピュータシステムが複数のコンピューティングデバイスを含む場合、これらのデバイスは、同じ位置に配置され得るが、その必要ではない。開示された方法およびタスクの結果は、固体メモリチップおよび／または磁気ディスクなどの物理記憶デバイスを異なる状態に変換することによって永続的に保存され得る。
本明細書に開示した範囲はまた、任意のおよびすべてのオーバーラップ、部分範囲、およびそれらの組み合わせを包含する。「まで」、「少なくとも」、「よりも大きい」、「未満」、「間」などの言語は、記載された数を含む。本明細書で使用される「ほぼ」、「約」および「実質的に」などの用語が先行する数値は、記載された数を含み、また、依然として所望の機能を実行する、または所望の結果を達成する記載された量に近い量を表す。例えば、用語「ほぼ」、「約」および「実質的に」は、記載された量の１０％未満以内、９％、８％、７％、６％、５％、４％、３％、２％または１％未満以内、０．１％未満以内、および０．０１％未満以内である量を指し得る。

Claims (204)

  1. 複数の時点における１つ以上のプログラムの状態を決定するために１つ以上のコンピュータプログラムをインストルメント化する方法であって、
    変更した状態の少なくとも一部をロギングすることにより１つ以上のプログラムの状態で発生する複数の変更を、ロギングされた変更として記録すること、
    ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることにより変更した状態の前記一部をロギングすること、
    １つ以上のプログラムのベースライン状態をベースラインイメージとして得て、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、ベースラインイメージに適用し、それにより、ベースラインイメージよりも前の時間での状態を再構成すること、および、
    最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とすることを含む、方法。
  2. ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されず、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録する、請求項１に記載の方法。
  3. 少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避する、請求項２に記載の方法。
  4. ベースラインイメージは、１つ以上のプログラムのメモリ状態を含む、請求項１〜３のいずれかに記載の方法。
  5. ベースラインイメージを取得することは、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得て、それによりデバッグを開始するのに必要な時間をバウンディングすることを含む、請求項４に記載の方法。
  6. 少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こし、方法はさらに、
    １つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用することを含む、請求項５に記載の方法。
  7. ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含む、請求項１〜６のいずれかに記載の方法。
  8. ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用すると、プログラマはデバッグを実行することができる、請求項７に記載の方法。
  9. デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含む、請求項８に記載の方法。
  10. ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項１〜９のいずれかに記載の方法。
  11. ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項１〜９のいずれかに記載の方法。
  12. ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項１〜９のいずれかに記載の方法。
  13. 複数の時点における１つ以上のプログラムの状態の少なくとも一部を決定する方法であって、
    ベースラインイメージとして１つ以上のプログラムのベースライン状態を得て、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、ベースラインイメージに適用し、それにより、ベースラインイメージよりも前の時間での状態を再構成すること、および、
    最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とすることを含み、
    １つ以上のプログラムの状態で発生した少なくとも１つの変更は、変更した状態の少なくとも一部をロギングすることによりロギングされた変更として記録されており、
    変更した状態の前記一部は、ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることによりロギングされている、方法。
  14. ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されず、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録する、請求項１３に記載の方法。
  15. 少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避する、請求項１４に記載の方法。
  16. ベースラインイメージは、１つ以上のプログラムのメモリ状態を含む、請求項１３〜１５のいずれかに記載の方法。
  17. ベースラインイメージを取得することは、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得て、それによりデバッグを開始するのに必要な時間をバウンディングすることを含む、請求項１６に記載の方法。
  18. 少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こし、方法はさらに、
    １つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用することを含む、請求項１７に記載の方法。
  19. ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含む、請求項１３〜１８のいずれかに記載の方法。
  20. ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用すると、プログラマはデバッグを実行することができる、請求項１９に記載の方法。
  21. デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含む、請求項２０に記載の方法。
  22. ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項１３〜２１のいずれかに記載の方法。
  23. ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項１３〜２１のいずれかに記載の方法。
  24. ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項１３〜２１のいずれかに記載の方法。
  25. 複数の時点における１つ以上のプログラムの状態を決定するために１つ以上のコンピュータプログラムをインストルメント化する方法であって、
    変更した状態の少なくとも一部をロギングすることによって、１つ以上のプログラムの状態で発生する少なくとも１つの変更を、ロギングされた変更として記録するように構成された１つ以上の実行可能命令を挿入すること、および、
    ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることにより変更した状態の前記一部をロギングするように構成された１つ以上の実行可能命令を挿入すること
    を含み、
    記録およびロギングにより、デバッガが、
    １つ以上のプログラムのベースライン状態に対応するベースラインイメージに、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、適用し、それによりベースラインイメージよりも前の時間での状態を再構成することができ、
    最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とする、方法。
  26. ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されず、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録する、請求項２５に記載の方法。
  27. 少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避する、請求項２６に記載の方法。
  28. ベースラインイメージは、１つ以上のプログラムのメモリ状態を含む、請求項２５〜２７のいずれかに記載の方法。
  29. 記録およびロギングにより、デバッガがさらに、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得ることによりベースラインイメージを取得することができ、それによりデバッグを開始するのに必要な時間をバウンディングする、請求項２８に記載の方法。
  30. 少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こし、記録およびロギングにより、デバッガがさらに、
    １つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用することができる、請求項２９に記載の方法。
  31. ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含む、請求項２５〜３０のいずれかに記載の方法。
  32. ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用すると、プログラマはデバッグを実行することができる、請求項３１に記載の方法。
  33. デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含む、請求項３２に記載の方法。
  34. ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項２５〜３３のいずれかに記載の方法。
  35. ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項２５〜３３のいずれかに記載の方法。
  36. ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項２５〜３３のいずれかに記載の方法。
  37. １つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに、複数の時点における１つ以上のプログラムの状態を決定するために１つ以上のコンピュータプログラムをインストルメント化する方法を実行させる命令を含む非一時的コンピュータ記憶媒体であって、方法は、
    変更した状態の少なくとも一部をロギングすることにより１つ以上のプログラムの状態で発生する複数の変更を、ロギングされた変更として記録すること、
    ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることにより変更した状態の前記一部をロギングすること、
    １つ以上のプログラムのベースライン状態をベースラインイメージとして得て、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、ベースラインイメージに適用し、それにより、ベースラインイメージよりも前の時間での状態を再構成すること、および、
    最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とすることを含む、コンピュータ記憶媒体。
  38. ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されず、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録する、請求項３７に記載のコンピュータ記憶媒体。
  39. 少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避する、請求項３８に記載のコンピュータ可読媒体。
  40. ベースラインイメージは、１つ以上のプログラムのメモリ状態を含む、請求項３７〜３９のいずれかに記載のコンピュータ記憶媒体。
  41. ベースラインイメージを取得することは、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得て、それによりデバッグを開始するのに必要な時間をバウンディングすることを含む、請求項４０に記載のコンピュータ記憶媒体。
  42. 少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こし、方法はさらに、
    １つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用することを含む、請求項４１に記載のコンピュータ記憶媒体。
  43. ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含む、請求項３７〜４２のいずれかに記載のコンピュータ記憶媒体。
  44. ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用すると、プログラマはデバッグを実行することができる、請求項４３に記載のコンピュータ記憶媒体。
  45. デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含む、請求項４４に記載のコンピュータ記憶媒体。
  46. ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項３７〜４５のいずれかに記載のコンピュータ記憶媒体。
  47. ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項３７〜４５のいずれかに記載のコンピュータ記憶媒体。
  48. ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項３７〜４５のいずれかに記載のコンピュータ記憶媒体。
  49. １つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに、複数の時点における１つ以上のプログラムの状態の少なくとも一部を決定する方法を実行させる命令を含む非一時的コンピュータ記憶媒体であって、方法は、
    ベースラインイメージとして１つ以上のプログラムのベースライン状態を得て、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、ベースラインイメージに適用し、それにより、ベースラインイメージよりも前の時間での状態を再構成すること、および、
    最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とすることを含み、
    １つ以上のプログラムの状態で発生した少なくとも１つの変更は、変更した状態の少なくとも一部をロギングすることによりロギングされた変更として記録されており、
    変更した状態の前記一部は、ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることによりロギングされている、
    コンピュータ記憶媒体。
  50. ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されず、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録する、請求項４９に記載のコンピュータ記憶媒体。
  51. 少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避する、請求項５０に記載のコンピュータ記憶媒体。
  52. ベースラインイメージは、１つ以上のプログラムのメモリ状態を含む、請求項４９〜５１のいずれかに記載のコンピュータ記憶媒体。
  53. ベースラインイメージを取得することは、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得て、それによりデバッグを開始するのに必要な時間をバウンディングすることを含む、請求項５２に記載のコンピュータ記憶媒体。
  54. 少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こし、方法はさらに、
    １つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用することを含む、請求項５３に記載のコンピュータ記憶媒体。
  55. ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含む、請求項４９〜５４のいずれかに記載のコンピュータ記憶媒体。
  56. ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用すると、プログラマはデバッグを実行することができる、請求項５５に記載のコンピュータ記憶媒体。
  57. デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含む、請求項５６に記載のコンピュータ記憶媒体。
  58. ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項４９〜５７のいずれかに記載のコンピュータ記憶媒体。
  59. ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項４９〜５７のいずれかに記載のコンピュータ記憶媒体。
  60. ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項４９〜５７のいずれかに記載のコンピュータ記憶媒体。
  61. １つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに、複数の時点における１つ以上のプログラムの状態を決定するために１つ以上のコンピュータプログラムをインストルメント化する方法を実行させる命令を含む非一時的コンピュータ記憶媒体であって、方法は、
    変更した状態の少なくとも一部をロギングすることによって、１つ以上のプログラムの状態で発生する少なくとも１つの変更を、ロギングされた変更として記録するように構成された１つ以上の実行可能命令を挿入すること、および、
    ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることにより変更した状態の前記一部をロギングするように構成された１つ以上の実行可能命令を挿入すること
    を含み、
    記録およびロギングにより、デバッガが、
    １つ以上のプログラムのベースライン状態に対応するベースラインイメージに、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、適用し、それによりベースラインイメージよりも前の時間での状態を再構成することができ、
    最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とする、コンピュータ記憶媒体。
  62. ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されず、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録する、請求項６１に記載のコンピュータ記憶媒体。
  63. 少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避する、請求項６２に記載のコンピュータ記憶媒体。
  64. ベースラインイメージは、１つ以上のプログラムのメモリ状態を含む、請求項６１〜６３のいずれかに記載のコンピュータ記憶媒体。
  65. 記録およびロギングにより、デバッガがさらに、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得ることによりベースラインイメージを取得することができ、それによりデバッグを開始するのに必要な時間をバウンディングする、請求項６４に記載のコンピュータ記憶媒体。
  66. 少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こし、記録およびロギングにより、デバッガがさらに、
    １つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用することができる、請求項６５に記載のコンピュータ記憶媒体。
  67. ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含む、請求項６１〜６６のいずれかに記載のコンピュータ記憶媒体。
  68. ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用すると、プログラマはデバッグを実行することができる、請求項６７に記載のコンピュータ記憶媒体。
  69. デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含む、請求項６８に記載のコンピュータ記憶媒体。
  70. ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項６１〜６９のいずれかに記載のコンピュータ記憶媒体。
  71. ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項６１〜６９のいずれかに記載のコンピュータ記憶媒体。
  72. ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項６１〜６９のいずれかに記載のコンピュータ記憶媒体。
  73. 少なくとも１つのメモリ、および、
    複数の時点における１つ以上のプログラムの状態を決定するために１つ以上のコンピュータプログラムをインストルメント化するよう構成された１つ以上のプロセッサ
    を備えるコンピュータシステムであって、１つ以上のプロセッサはさらに、
    変更した状態の少なくとも一部をロギングすることにより１つ以上のプログラムの状態で発生する複数の変更を、ロギングされた変更として記録し、
    ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることにより変更した状態の前記一部をロギングし、
    １つ以上のプログラムのベースライン状態をベースラインイメージとして得て、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、ベースラインイメージに適用し、それにより、ベースラインイメージよりも前の時間での状態を再構成し、および、
    最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とするように構成されている、システム。
  74. ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されず、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録する、請求項７３に記載のシステム。
  75. 少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避する、請求項７４に記載のシステム。
  76. ベースラインイメージは、１つ以上のプログラムのメモリ状態を含む、請求項７３〜７５のいずれかに記載のシステム。
  77. １つ以上のプロセッサは、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得て、それによりデバッグを開始するのに必要な時間をバウンディングするように構成されている、請求項７６に記載のシステム。
  78. 少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こし、１つ以上のプロセッサはさらに、
    １つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用するように構成されている、請求項７７に記載のシステム。
  79. ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含む、請求項７３〜７８のいずれかに記載のシステム。
  80. １つ以上のプロセッサは、ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用して、それにより、プログラマはデバッグを実行することができるように構成されている、請求項７９に記載のシステム。
  81. デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含む、請求項８０に記載のシステム。
  82. １つ以上のプロセッサは、ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うように構成されている、請求項７３〜８１のいずれかに記載のシステム。
  83. １つ以上のプロセッサは、ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うように構成されている、請求項７３〜８１のいずれかに記載のシステム。
  84. １つ以上のプロセッサは、ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行うように構成されている、請求項７３〜８１のいずれかに記載のシステム。
  85. 少なくとも１つのメモリ、および、
    複数の時点における１つ以上のプログラムの状態の少なくとも一部を決定するよう構成された１つ以上のプロセッサ
    を備えるコンピュータシステムであって、１つ以上のプロセッサはさらに、
    ベースラインイメージとして１つ以上のプログラムのベースライン状態を得て、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、ベースラインイメージに適用し、それにより、ベースラインイメージよりも前の時間での状態を再構成し、および、
    最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とするよう構成され、
    １つ以上のプログラムの状態で発生した少なくとも１つの変更は、変更した状態の少なくとも一部をロギングすることによりロギングされた変更として記録されており、
    変更した状態の前記一部は、ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることによりロギングされている、システム。
  86. ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されず、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録する、請求項８５に記載のシステム。
  87. 少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避する、請求項８６に記載のシステム。
  88. ベースラインイメージは、１つ以上のプログラムのメモリ状態を含む、請求項８５〜８７のいずれかに記載のシステム。
  89. １つ以上のプロセッサは、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得て、それによりデバッグを開始するのに必要な時間をバウンディングするように構成されている、請求項８８に記載のシステム。
  90. 少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こし、１つ以上のプロセッサはさらに、
    １つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用するように構成されている、請求項８９に記載のシステム。
  91. ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含む、請求項８５〜９０のいずれかに記載のシステム。
  92. ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用すると、プログラマはデバッグを実行することができる、請求項９１に記載のシステム。
  93. デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含む、請求項９２に記載のシステム。
  94. ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項８５〜９３のいずれかに記載のシステム。
  95. ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項８５〜９３のいずれかに記載のシステム。
  96. ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項８５〜９３のいずれかに記載のシステム。
  97. 少なくとも１つのメモリ、および、
    複数の時点における１つ以上のプログラムの状態を決定するために１つ以上のコンピュータプログラムをインストルメント化するよう構成された１つ以上のプロセッサ
    を備えるコンピュータシステムであって、１つ以上のプロセッサはさらに、
    変更した状態の少なくとも一部をロギングすることによって、１つ以上のプログラムの状態で発生する少なくとも１つの変更を、ロギングされた変更として記録するように構成された１つ以上の実行可能命令を挿入し、および、
    ロギングされた変更の各々の発生前の時間から少なくとも前記一部の表現をプリイメージとしてロギングすることにより変更した状態の前記一部をロギングするように構成された１つ以上の実行可能命令を挿入するよう構成され、
    記録およびロギングにより、デバッガが、
    １つ以上のプログラムのベースライン状態に対応するベースラインイメージに、１つ以上のプリイメージを最も近い時点でロギングされたものから最も遠い時点でロギングされたものへと順次、適用し、それによりベースラインイメージよりも前の時間での状態を再構成することができ、
    最新から最古まで１つ以上のプリイメージを検索および解釈し、それにより、検索、ダウンロードおよび／またはデコードされる対象の実行履歴を表すロギングされたデータの以前の部分を待たずに１つ以上のプログラムの最も近い時点での実行履歴の解析を可能とする、システム。
  98. ロギングされた変更の各々は、ロギングされた変更が発生する時間に記録されず、ロギングされた変更を１つ以上のレジスタの状態を含む少なくとも１つのレジスタ状態スナップショットを介して記録する、請求項９７に記載のシステム。
  99. 少なくとも１つのレジスタ状態スナップショットを記録することにより、１つ以上のプログラムのランタイムパフォーマンスおよび／またはメモリフットプリントに悪影響を与えることを回避する、請求項９８に記載のシステム。
  100. ベースラインイメージは、１つ以上のプログラムのメモリ状態を含む、請求項９７〜９９のいずれかに記載のシステム。
  101. 記録およびロギングにより、デバッガがさらに、再構成に必要なときに１つずつベースラインイメージの複数のセクションを得ることによりベースラインイメージを取得することができ、それによりデバッグを開始するのに必要な時間をバウンディングする、請求項１００に記載のシステム。
  102. 少なくとも１つのセクションがダウンロードされた後にベースラインイメージを修正し、それにより異なる時間に得られたセクション間に１つ以上の不整合を引き起こし、記録およびロギングにより、デバッガがさらに、
    １つ以上の不整合を解消するためにベースラインイメージの修正と併せて記録された１つ以上のプリイメージを適用することができる、請求項１０１に記載のシステム。
  103. ベースラインイメージは、システムメモリの少なくとも一部の以前に保存されたイメージを含む、請求項９７〜１０２のいずれかに記載のシステム。
  104. ベースラインイメージとしてシステムメモリの少なくとも一部の以前に保存されたイメージを使用すると、プログラマはデバッグを実行することができる、請求項１０３に記載のシステム。
  105. デバッグは、１つ以上のプログラムが実行を停止した後のデバッグを含む、請求項１０４に記載のシステム。
  106. ロギングされた変更が発生する前に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項９７〜１０５のいずれかに記載のシステム。
  107. ロギングされた変更が発生した後に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項９７〜１０５のいずれかに記載のシステム。
  108. ロギングされた変更中に、ロギングされた変更の各々に関連付けられたプリイメージのロギングを行う、請求項９７〜１０５のいずれかに記載のシステム。
  109. ターゲットシステムの１つ以上の実行ユニット上で実行される１つ以上のコンピュータプログラムのメモリおよびレジスタの少なくとも一部の内容を再構成状態として宛先時点で再構成する方法であって、
    複数の時点における再構成状態を再構成すること、
    １つ以上のコンピュータプログラムの実行に起因するロギングされたデータに再構成を基づかせること
    を含み、
    前記ロギングされたデータは、１つ以上のコンピュータプログラムによって、または、オペレーティングシステムもしくは１つ以上のコンピュータプログラムの外部の別のエージェントによって、修正前の時間における再構成状態の少なくとも一部を表すプリイメージを含み、
    前記ロギングされたデータはまた、宛先時点の前にロギングされた少なくとも１つのレジスタ状態スナップショットを含み、
    方法は、宛先時点における再構成状態の少なくとも一部を決定するために命令セットシミュレータを適用することを含む、方法。
  110. 複数の時点のうちの少なくとも１つにおける再構成状態の表現を維持することをさらに含む、請求項１０９に記載の方法。
  111. 再構成状態の再構成中にロギングされたデータからプリイメージをコピーすることによってメモリ修正の直前における再構成状態を再現することをさらに含む、請求項１１０に記載の方法。
  112. 連続的に以前のメモリ修正記録の直前の時点における再構成状態を再現し、それにより１つ以上のコンピュータプログラムの実行中に連続的に以前のポイントを再現することをさらに含む、請求項１１１に記載の方法。
  113. ポストイメージを記憶するためのメモリ空間を予約することをさらに含む、請求項１１０に記載の方法。
  114. ポストイメージのために予約された同じメモリ空間にプリイメージを保存することをさらに含む、請求項１１３に記載の方法。
  115. ポストイメージを記憶するための予約されたメモリ空間にポストイメージとして表現の少なくとも一部をコピーすることをさらに含む、請求項１１３に記載の方法。
  116. ポストイメージをコピーすることによりメモリ修正直後の時点における再構成状態を再構成することをさらに含む、請求項１１３に記載の方法。
  117. 連続的に以後のメモリ修正直後の時点における再構成状態を再構成し、それにより１つ以上のプログラムの実行中に連続的にますます以後のポイントを再現することをさらに含む、請求項１１６に記載の方法。
  118. 実行ユニットが１つの時点で動作した再構成状態の少なくとも一部を再現すること、および、後の時点における再構成状態の少なくとも一部を決定するために命令セットシミュレータを適用することをさらに含む、請求項１０９〜１１７のいずれかに記載の方法。
  119. 実行ユニットが前方または後方にメモリを再構成することによって動作した再構成状態の少なくとも一部を再現することをさらに含む、請求項１１８に記載の方法。
  120. 後の時点を宛先時点とする、請求項１１９に記載の方法。
  121. レジスタ状態が宛先時点において未知である実行ユニットのセットを決定することをさらに含む、請求項１０９〜１２０のいずれかに記載の方法。
  122. レジスタ状態が宛先時点において未知である各実行ユニットについて、再構成ポイントと宛先時点との間の少なくとも１つのレジスタ状態スナップショットがロギングされているように再構成ポイントを決定することをさらに含む、請求項１２１に記載の方法。
  123. 再構成ポイントにおける再構成状態の少なくとも一部を再構成することをさらに含む、請求項１２２に記載の方法。
  124. 宛先時点に戻るためにメモリ再構成技術および再構成シミュレーション技術の組み合わせを使用することをさらに含む、請求項１２３に記載の方法。
  125. 実行ユニットのセットのうちの実行ユニットについての正確なレジスタ状態情報が利用可能であるとき再構成シミュレーション技術を使用することをさらに含む、請求項１２４に記載の方法。
  126. 実行ユニットのセットのうちの実行ユニットについての正確なレジスタ状態情報が利用できないときメモリ再構成技術を使用することをさらに含む、請求項１２４に記載の方法。
  127. 再構成状態のサブセットの再構成が可能ではないことを決定することをさらに含む、請求項１０９〜１２６のいずれかに記載の方法。
  128. 再構成状態のサブセットの再構成は、ロギングされないメモリ修正についての１つ以上のプリイメージ値のために可能ではない、請求項１２７に記載の方法。
  129. 副作用揮発性メモリに保存するとき、メモリ修正についての１つ以上のプリイメージ値がロギングされない、請求項１２８に記載の方法。
  130. メモリの状態のサブセットの再構成は、確かではないロギングされたイベントの正しい順序のために可能ではない、請求項１２７に記載の方法。
  131. ロギングされたイベントの正しい順序は、１つ以上のコンピュータプログラム内の１つ以上の競合条件のために確かではない、請求項１３０に記載の方法。
  132. １つ以上の競合条件に関する情報を表示することをさらに含む、請求項１３１に記載の方法。
  133. 表示される情報は、１つ以上のメモリ位置にアクセス競合する１つ以上のコンピュータプログラム内の位置を含む、請求項１３２に記載の方法。
  134. １つ以上のコンピュータプログラム内の位置は、ソースコード位置である、請求項１３３に記載の方法。
  135. 再構成状態の未知のサブセットを追跡することをさらに含む、請求項１２７に記載の方法。
  136. シミュレーションを行う際に再構成状態の異なるサブセットに再構成状態のサブセットの未知性を伝搬することをさらに含む、請求項１３５に記載の方法。
  137. １つ以上のコンピュータプログラムの命令の結果が既知である場合、未知性を伝播しない、請求項１３６に記載の方法。
  138. 値が既知になったときに既知であると再構成状態の未知のサブセットをマーキングすることをさらに含む、請求項１３５に記載の方法。
  139. 値は、既知の値を伴うレジスタまたはメモリ位置をロードする命令をシミュレートした結果として既知になる、請求項１３８に記載の方法。
  140. レジスタ状態スナップショットから決定することができる場合に、値は既知になる、請求項１３８に記載の方法。
  141. １つ以上のプロセッサによって実行されるとき、１つ以上のプロセッサに、ターゲットシステムの１つ以上の実行ユニット上で実行される１つ以上のコンピュータプログラムのメモリおよびレジスタの少なくとも一部の内容を再構成状態として宛先時点で再構成する方法を実行させる命令を含む非一時的コンピュータ記憶媒体であって、方法は、
    複数の時点における再構成状態を再構成すること、
    １つ以上のコンピュータプログラムの実行に起因するロギングされたデータに再構成を基づかせること
    を含み、
    前記ロギングされたデータは、１つ以上のコンピュータプログラムによって、または、オペレーティングシステムもしくは１つ以上のコンピュータプログラムの外部の別のエージェントによって、修正前の時間における再構成状態の少なくとも一部を表すプリイメージを含み、
    前記ロギングされたデータはまた、宛先時点の前にロギングされた少なくとも１つのレジスタ状態スナップショットを含み、
    方法は、宛先時点における再構成状態の少なくとも一部を決定するために命令セットシミュレータを適用することを含む、コンピュータ記憶媒体。
  142. 複数の時点のうちの少なくとも１つにおける再構成状態の表現を維持することをさらに含む、請求項１４１に記載のコンピュータ記憶媒体。
  143. 再構成状態の再構成中にロギングされたデータからプリイメージをコピーすることによってメモリ修正の直前における再構成状態を再現することをさらに含む、請求項１４２に記載のコンピュータ記憶媒体。
  144. 連続的に以前のメモリ修正記録の直前の時点における再構成状態を再現し、それにより１つ以上のコンピュータプログラムの実行中に連続的に以前のポイントを再現することをさらに含む、請求項１４３に記載のコンピュータ記憶媒体。
  145. ポストイメージを記憶するためのメモリ空間を予約することをさらに含む、請求項１４２に記載のコンピュータ記憶媒体。
  146. ポストイメージのために予約された同じメモリ空間にプリイメージを保存することをさらに含む、請求項１４５に記載のコンピュータ記憶媒体。
  147. ポストイメージを記憶するための予約されたメモリ空間にポストイメージとして表現の少なくとも一部をコピーすることをさらに含む、請求項１４５に記載のコンピュータ記憶媒体。
  148. ポストイメージをコピーすることによりメモリ修正直後の時点における再構成状態を再構成することをさらに含む、請求項１４５に記載のコンピュータ記憶媒体。
  149. 連続的に以後のメモリ修正直後の時点における再構成状態を再構成し、それにより１つ以上のプログラムの実行中に連続的にますます以後のポイントを再現することをさらに含む、請求項１４８に記載のコンピュータ記憶媒体。
  150. 実行ユニットが１つの時点で動作した再構成状態の少なくとも一部を再現すること、および、後の時点における再構成状態の少なくとも一部を決定するために命令セットシミュレータを適用することをさらに含む、請求項１４１〜１４９のいずれかに記載のコンピュータ記憶媒体。
  151. 実行ユニットが前方または後方にメモリを再構成することによって動作した再構成状態の少なくとも一部を再現することをさらに含む、請求項１５０に記載のコンピュータ記憶媒体。
  152. 後の時点を宛先時点とする、請求項１５１に記載のコンピュータ記憶媒体。
  153. レジスタ状態が宛先時点において未知である実行ユニットのセットを決定することをさらに含む、請求項１４１〜１５２のいずれかに記載のコンピュータ記憶媒体。
  154. レジスタ状態が宛先時点において未知である各実行ユニットについて、再構成ポイントと宛先時点との間の少なくとも１つのレジスタ状態スナップショットがロギングされているように再構成ポイントを決定することをさらに含む、請求項１５３に記載のコンピュータ記憶媒体。
  155. 再構成ポイントにおける再構成状態の少なくとも一部を再構成することをさらに含む、請求項１５４に記載のコンピュータ記憶媒体。
  156. 宛先時点に戻るためにメモリ再構成技術および再構成シミュレーション技術の組み合わせを使用することをさらに含む、請求項１５５に記載のコンピュータ記憶媒体。
  157. 実行ユニットのセットのうちの実行ユニットについての正確なレジスタ状態情報が利用可能であるとき再構成シミュレーション技術を使用することをさらに含む、請求項１５６に記載のコンピュータ記憶媒体。
  158. 実行ユニットのセットのうちの実行ユニットについての正確なレジスタ状態情報が利用できないときメモリ再構成技術を使用することをさらに含む、請求項１５６に記載のコンピュータ記憶媒体。
  159. 再構成状態のサブセットの再構成が可能ではないことを決定することをさらに含む、請求項１４１〜１５８のいずれかに記載のコンピュータ記憶媒体。
  160. 再構成状態のサブセットの再構成は、ロギングされないメモリ修正についての１つ以上のプリイメージ値のために可能ではない、請求項１５９に記載のコンピュータ記憶媒体。
  161. 副作用揮発性メモリに保存するとき、メモリ修正についての１つ以上のプリイメージ値がロギングされない、請求項１６０に記載のコンピュータ記憶媒体。
  162. メモリの状態のサブセットの再構成は、確かではないロギングされたイベントの正しい順序のために可能ではない、請求項１５９に記載のコンピュータ記憶媒体。
  163. ロギングされたイベントの正しい順序は、１つ以上のコンピュータプログラム内の１つ以上の競合条件のために確かではない、請求項１６２に記載のコンピュータ記憶媒体。
  164. １つ以上の競合条件に関する情報を表示することをさらに含む、請求項１６３に記載のコンピュータ記憶媒体。
  165. 表示される情報は、１つ以上のメモリ位置にアクセス競合する１つ以上のコンピュータプログラム内の位置を含む、請求項１６４に記載のコンピュータ記憶媒体。
  166. １つ以上のコンピュータプログラム内の位置は、ソースコード位置である、請求項１６５に記載のコンピュータ記憶媒体。
  167. 再構成状態の未知のサブセットを追跡することをさらに含む、請求項１５９に記載のコンピュータ記憶媒体。
  168. シミュレーションを行う際に再構成状態の異なるサブセットに再構成状態のサブセットの未知性を伝搬することをさらに含む、請求項１６７に記載のコンピュータ記憶媒体。
  169. １つ以上のコンピュータプログラムの命令の結果が既知である場合、未知性を伝播しない、請求項１６８に記載のコンピュータ記憶媒体。
  170. 値が既知になったときに既知であると再構成状態の未知のサブセットをマーキングすることをさらに含む、請求項１６７に記載のコンピュータ記憶媒体。
  171. 値は、既知の値を伴うレジスタまたはメモリ位置をロードする命令をシミュレートした結果として既知になる、請求項１７０に記載のコンピュータ記憶媒体。
  172. レジスタ状態スナップショットから決定することができる場合に、値は既知になる、請求項１７０に記載のコンピュータ記憶媒体。
  173. 少なくとも１つのメモリ、および、
    ターゲットシステムの１つ以上の実行ユニット上で実行される１つ以上のコンピュータプログラムのメモリおよびレジスタの少なくとも一部の内容を再構成状態として宛先時点で再構成するよう構成された１つ以上のプロセッサ
    を備えるコンピュータシステムであって、１つ以上のプロセッサはさらに、
    複数の時点における再構成状態を再構成し、
    １つ以上のコンピュータプログラムの実行に起因するロギングされたデータに再構成を基づかせる
    よう構成され、
    前記ロギングされたデータは、１つ以上のコンピュータプログラムによって、または、オペレーティングシステムもしくは１つ以上のコンピュータプログラムの外部の別のエージェントによって、修正前の時間における再構成状態の少なくとも一部を表すプリイメージを含み、
    前記ロギングされたデータはまた、宛先時点の前にロギングされた少なくとも１つのレジスタ状態スナップショットを含み、
    １つ以上のプロセッサは、宛先時点における再構成状態の少なくとも一部を決定するために命令セットシミュレータを適用するよう構成される、システム。
  174. １つ以上のプロセッサはさらに、複数の時点のうちの少なくとも１つにおける再構成状態の表現を維持するように構成されている、請求項１７３に記載のシステム。
  175. １つ以上のプロセッサはさらに、再構成状態の再構成中にロギングされたデータからプリイメージをコピーすることによってメモリ修正の直前における再構成状態を再現するように構成されている、請求項１７４に記載のシステム。
  176. １つ以上のプロセッサはさらに、連続的に以前のメモリ修正記録の直前の時点における再構成状態を再現し、それにより１つ以上のコンピュータプログラムの実行中に連続的に以前のポイントを再現するように構成されている、請求項１７５に記載のシステム。
  177. １つ以上のプロセッサはさらに、ポストイメージを記憶するためのメモリ空間を予約するように構成されている、請求項１７４に記載のシステム。
  178. １つ以上のプロセッサはさらに、ポストイメージのために予約された同じメモリ空間にプリイメージを保存するように構成されている、請求項１７７に記載のシステム。
  179. １つ以上のプロセッサはさらに、ポストイメージを記憶するための予約されたメモリ空間にポストイメージとして表現の少なくとも一部をコピーするように構成されている、請求項１７７に記載のシステム。
  180. １つ以上のプロセッサはさらに、ポストイメージをコピーすることによりメモリ修正直後の時点における再構成状態を再構成するように構成されている、請求項１７７に記載のシステム。
  181. １つ以上のプロセッサはさらに、連続的に以後のメモリ修正直後の時点における再構成状態を再構成し、それにより１つ以上のプログラムの実行中に連続的にますます以後のポイントを再現するように構成されている、請求項１８０に記載のシステム。
  182. １つ以上のプロセッサはさらに、実行ユニットが１つの時点で動作した再構成状態の少なくとも一部を再現し、および、後の時点における再構成状態の少なくとも一部を決定するために命令セットシミュレータを適用するように構成されている、請求項１７３〜１８１のいずれかに記載のシステム。
  183. １つ以上のプロセッサはさらに、実行ユニットが前方または後方にメモリを再構成することによって動作した再構成状態の少なくとも一部を再現するように構成されている、請求項１８２に記載のシステム。
  184. 後の時点を宛先時点とする、請求項１８３に記載のシステム。
  185. １つ以上のプロセッサはさらに、レジスタ状態が宛先時点において未知である実行ユニットのセットを決定するように構成されている、請求項１７３〜１８４のいずれかに記載のシステム。
  186. １つ以上のプロセッサはさらに、レジスタ状態が宛先時点において未知である各実行ユニットについて、再構成ポイントと宛先時点との間の少なくとも１つのレジスタ状態スナップショットがロギングされているように再構成ポイントを決定するように構成されている、請求項１８５に記載のシステム。
  187. １つ以上のプロセッサはさらに、再構成ポイントにおける再構成状態の少なくとも一部を再構成するように構成されている、請求項１８６に記載のシステム。
  188. １つ以上のプロセッサはさらに、宛先時点に戻るためにメモリ再構成技術および再構成シミュレーション技術の組み合わせを使用するように構成されている、請求項１８７に記載のシステム。
  189. １つ以上のプロセッサはさらに、実行ユニットのセットのうちの実行ユニットについての正確なレジスタ状態情報が利用可能であるとき再構成シミュレーション技術を使用するように構成されている、請求項１８８に記載のシステム。
  190. １つ以上のプロセッサはさらに、実行ユニットのセットのうちの実行ユニットについての正確なレジスタ状態情報が利用できないときメモリ再構成技術を使用するように構成されている、請求項１８８に記載のシステム。
  191. １つ以上のプロセッサはさらに、再構成状態のサブセットの再構成が可能ではないことを決定するように構成されている、請求項１７３〜１９０のいずれかに記載のシステム。
  192. 再構成状態のサブセットの再構成は、ロギングされないメモリ修正についての１つ以上のプリイメージ値のために可能ではない、請求項１９１に記載のシステム。
  193. 副作用揮発性メモリに保存するとき、メモリ修正についての１つ以上のプリイメージ値がロギングされない、請求項１９２に記載のシステム。
  194. メモリの状態のサブセットの再構成は、確かではないロギングされたイベントの正しい順序のために可能ではない、請求項１９１に記載のシステム。
  195. ロギングされたイベントの正しい順序は、１つ以上のコンピュータプログラム内の１つ以上の競合条件のために確かではない、請求項１９４に記載のシステム。
  196. １つ以上のプロセッサはさらに、１つ以上の競合条件に関する情報を表示するように構成されている、請求項１９５に記載のシステム。
  197. 表示される情報は、１つ以上のメモリ位置にアクセス競合する１つ以上のコンピュータプログラム内の位置を含む、請求項１９６に記載のシステム。
  198. １つ以上のコンピュータプログラム内の位置は、ソースコード位置である、請求項１９７に記載のシステム。
  199. １つ以上のプロセッサはさらに、再構成状態の未知のサブセットを追跡するように構成されている、請求項１９１に記載のシステム。
  200. １つ以上のプロセッサはさらに、シミュレーションを行う際に再構成状態の異なるサブセットに再構成状態のサブセットの未知性を伝搬するように構成されている、請求項１９９に記載のシステム。
  201. １つ以上のコンピュータプログラムの命令の結果が既知である場合、未知性を伝播しない、請求項２００に記載のシステム。
  202. １つ以上のプロセッサはさらに、値が既知になったときに既知であると再構成状態の未知のサブセットをマーキングするように構成されている、請求項１９９に記載のシステム。
  203. 値は、既知の値を伴うレジスタまたはメモリ位置をロードする命令をシミュレートした結果として既知になる、請求項２０２に記載のシステム。
  204. レジスタ状態スナップショットから決定することができる場合に、値は既知になる、請求項２０２に記載のシステム。
JP2019520612A 2016-10-11 2017-10-10 垂直統合インストルメント化およびトレース再構成のためのシステム、方法およびデバイス Active JP7202293B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201662406829P 2016-10-11 2016-10-11
US62/406,829 2016-10-11
PCT/US2017/055986 WO2018071450A1 (en) 2016-10-11 2017-10-10 Systems, methods, and devices for vertically integrated instrumentation and trace reconstruction

Publications (3)

Publication Number Publication Date
JP2019537782A true JP2019537782A (ja) 2019-12-26
JP2019537782A5 JP2019537782A5 (ja) 2020-11-19
JP7202293B2 JP7202293B2 (ja) 2023-01-11

Family

ID=61188386

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019520612A Active JP7202293B2 (ja) 2016-10-11 2017-10-10 垂直統合インストルメント化およびトレース再構成のためのシステム、方法およびデバイス

Country Status (5)

Country Link
US (8) US9898385B1 (ja)
EP (1) EP3526673A4 (ja)
JP (1) JP7202293B2 (ja)
CA (1) CA3039198A1 (ja)
WO (1) WO2018071450A1 (ja)

Families Citing this family (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10120781B2 (en) * 2013-12-12 2018-11-06 Intel Corporation Techniques for detecting race conditions
JP6223637B2 (ja) * 2015-05-29 2017-11-01 三菱電機株式会社 シミュレーション装置及びシミュレーション方法及びシミュレーションプログラム
US10031834B2 (en) * 2016-08-31 2018-07-24 Microsoft Technology Licensing, Llc Cache-based tracing for time travel debugging and analysis
US10042737B2 (en) 2016-08-31 2018-08-07 Microsoft Technology Licensing, Llc Program tracing for time travel debugging and analysis
WO2018071450A1 (en) 2016-10-11 2018-04-19 Green Hills Software, Inc. Systems, methods, and devices for vertically integrated instrumentation and trace reconstruction
US10310963B2 (en) 2016-10-20 2019-06-04 Microsoft Technology Licensing, Llc Facilitating recording a trace file of code execution using index bits in a processor cache
US10489273B2 (en) 2016-10-20 2019-11-26 Microsoft Technology Licensing, Llc Reuse of a related thread's cache while recording a trace file of code execution
US10310977B2 (en) 2016-10-20 2019-06-04 Microsoft Technology Licensing, Llc Facilitating recording a trace file of code execution using a processor cache
US10540250B2 (en) 2016-11-11 2020-01-21 Microsoft Technology Licensing, Llc Reducing storage requirements for storing memory addresses and values
US10318332B2 (en) 2017-04-01 2019-06-11 Microsoft Technology Licensing, Llc Virtual machine execution tracing
US10558809B1 (en) 2017-04-12 2020-02-11 Architecture Technology Corporation Software assurance system for runtime environments
JP6919338B2 (ja) * 2017-05-30 2021-08-18 オムロン株式会社 プログラム開発支援装置、プログラム開発支援システム、プログラム開発支援方法、および、プログラム開発支援プログラム
FR3067486B1 (fr) * 2017-06-09 2021-08-27 Cryptosense Procede de detection non intrusif des failles de securite d'un programme informatique
US20190042390A1 (en) * 2017-08-01 2019-02-07 Microsoft Technology Licensing, Llc Focused execution of traced code in a debugger
US20190102841A1 (en) * 2017-10-04 2019-04-04 Servicenow, Inc. Mapping engine configurations with task managed workflows and grid user interfaces
KR102415218B1 (ko) * 2017-11-24 2022-07-01 에스케이하이닉스 주식회사 메모리 시스템 및 이의 동작 방법
US10795801B2 (en) * 2018-01-08 2020-10-06 Ozcode Ltd Time travel source code debugger incorporating asynchronous collaboration
US10558572B2 (en) 2018-01-16 2020-02-11 Microsoft Technology Licensing, Llc Decoupling trace data streams using cache coherence protocol data
US11907091B2 (en) 2018-02-16 2024-02-20 Microsoft Technology Licensing, Llc Trace recording by logging influxes to an upper-layer shared cache, plus cache coherence protocol transitions among lower-layer caches
US10642737B2 (en) 2018-02-23 2020-05-05 Microsoft Technology Licensing, Llc Logging cache influxes by request to a higher-level cache
US10541042B2 (en) 2018-04-23 2020-01-21 Microsoft Technology Licensing, Llc Level-crossing memory trace inspection queries
US20190324891A1 (en) * 2018-04-23 2019-10-24 Microsoft Technology Licensing, Llc Visualizing last/next known data values in time travel traces
US10592396B2 (en) * 2018-04-23 2020-03-17 Microsoft Technology Licensing, Llc Memory validity states in time-travel debugging
US11237946B2 (en) * 2018-05-03 2022-02-01 Sap Se Error finder tool
US11599445B2 (en) * 2018-06-15 2023-03-07 Board Of Regents, The University Of Texas System Watcher: precise and fully-automatic on-site failure diagnosis
US10868825B1 (en) 2018-08-14 2020-12-15 Architecture Technology Corporation Cybersecurity and threat assessment platform for computing environments
US10620960B2 (en) * 2018-08-20 2020-04-14 Arm Limited Apparatus and method for performing branch prediction
US11086759B2 (en) * 2018-09-27 2021-08-10 SeaLights Technologies LTD System and method for probe injection for code coverage
US11010231B2 (en) * 2018-10-03 2021-05-18 International Business Machines Corporation Automatic log generation
US10884720B2 (en) 2018-10-04 2021-01-05 Microsoft Technology Licensing, Llc Memory ordering annotations for binary emulation
US10545850B1 (en) * 2018-10-18 2020-01-28 Denso International America, Inc. System and methods for parallel execution and comparison of related processes for fault protection
WO2020079676A1 (en) * 2018-10-18 2020-04-23 Sternum Ltd. Applying security mitigation measures for stack corruption exploitation in intermediate code files
US10684835B1 (en) * 2018-12-11 2020-06-16 Microsoft Technology Licensing, Llc Improving emulation and tracing performance using compiler-generated emulation optimization metadata
US10977162B2 (en) * 2018-12-20 2021-04-13 Paypal, Inc. Real time application error identification and mitigation
US10901658B2 (en) * 2018-12-28 2021-01-26 Micron Technology, Inc. Host adaptive memory device optimization
US10956304B2 (en) 2019-01-25 2021-03-23 Microsoft Technology Licensing, Llc Dynamic diagnostic code instrumentation over a historic program execution
US10877873B2 (en) 2019-02-07 2020-12-29 Microsoft Technology Licensing, Llc Using historic execution data to visualize tracepoints
US10949338B1 (en) * 2019-02-07 2021-03-16 Architecture Technology Corporation Automated software bug discovery and assessment
US11132280B2 (en) * 2019-02-08 2021-09-28 Microsoft Technology Licensing, Llc Automatically identifying and highlighting differences between historic traces
US11281560B2 (en) 2019-03-19 2022-03-22 Microsoft Technology Licensing, Llc Input/output data transformations when emulating non-traced code with a recorded execution of traced code
US11782816B2 (en) * 2019-03-19 2023-10-10 Jens C. Jenkins Input/output location transformations when emulating non-traced code with a recorded execution of traced code
US11074153B2 (en) 2019-04-01 2021-07-27 Microsoft Technology Licensing, Llc Collecting application state in a runtime environment for reversible debugging
US11113182B2 (en) * 2019-04-01 2021-09-07 Microsoft Technology Licensing, Llc Reversible debugging in a runtime environment
US10990506B2 (en) * 2019-04-11 2021-04-27 Microsoft Technology Licensing, Llc Cross-thread memory indexing in time-travel debugging traces
US10949332B2 (en) 2019-08-14 2021-03-16 Microsoft Technology Licensing, Llc Data race analysis based on altering function internal loads during time-travel debugging
US11030060B2 (en) 2019-08-22 2021-06-08 International Business Machines Corporation Data validation during data recovery in a log-structured array storage system
WO2021124464A1 (ja) * 2019-12-17 2021-06-24 三菱電機株式会社 経路決定装置及び経路決定プログラム
US11113180B2 (en) * 2020-01-31 2021-09-07 Salesforce.Com, Inc. Efficiently tracking code location of run-time events in system software
WO2021229295A1 (en) * 2020-05-12 2021-11-18 Lightrun Platform LTD Systems and methods for debugging and application development
WO2022031275A1 (en) * 2020-08-05 2022-02-10 Hewlett-Packard Development Company, L.P. Detection of memory modification
US11681508B2 (en) * 2020-08-24 2023-06-20 Cisco Technology, Inc. Source code analysis to map analysis perspectives to events
EP3961436A1 (en) * 2020-08-28 2022-03-02 Siemens Aktiengesellschaft Methods and systems for controlling access to at least one computer program
US20220100512A1 (en) * 2021-12-10 2022-03-31 Intel Corporation Deterministic replay of a multi-threaded trace on a multi-threaded processor
US12001989B2 (en) * 2021-02-03 2024-06-04 Dynatrace Llc Optimizing cloud-based IT-systems towards business objectives: automatic topology-based analysis to determine impact of IT-systems on business metrics
US11275638B1 (en) * 2021-03-02 2022-03-15 Quanta Computer Inc. Systems and methods for storing debug information
US11693759B2 (en) 2021-05-14 2023-07-04 International Business Machines Corporation Providing for multi-process log debug without running on a production environment
GB202110155D0 (en) * 2021-07-14 2021-08-25 Graphcore Ltd GSP trace unit
US20230195590A1 (en) * 2021-12-20 2023-06-22 Deep Vision Inc. System and method for profiling on-chip performance of neural network execution
KR20230094308A (ko) * 2021-12-21 2023-06-28 삼성전자주식회사 저장 장치, 그것을 포함하는 호스트 시스템, 및 그것의 동작 방법

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0468446A (ja) * 1990-07-09 1992-03-04 Mitsubishi Electric Corp デバッグ支援装置
JPH096647A (ja) * 1995-06-21 1997-01-10 Oki Electric Ind Co Ltd 逆実行デバッグシステム
US5784552A (en) * 1993-07-28 1998-07-21 Digital Equipment Corporation Debugging a computer program by simulating execution forwards and backwards in a main history log and alternative history logs
US20050086246A1 (en) * 2003-09-04 2005-04-21 Oracle International Corporation Database performance baselines
JP2012256279A (ja) * 2011-06-10 2012-12-27 Sony Corp 情報処理装置および方法、並びにプログラム
US20150052403A1 (en) * 2013-08-19 2015-02-19 Concurix Corporation Snapshotting Executing Code with a Modifiable Snapshot Definition

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5894575A (en) * 1996-11-25 1999-04-13 International Business Machines Corporation Method and system for initial state determination for instruction trace reconstruction
US6253317B1 (en) * 1997-01-09 2001-06-26 Sun Microsystems, Inc. Method and apparatus for providing and handling traps
US6311327B1 (en) 1998-03-02 2001-10-30 Applied Microsystems Corp. Method and apparatus for analyzing software in a language-independent manner
US20020087949A1 (en) 2000-03-03 2002-07-04 Valery Golender System and method for software diagnostics using a combination of visual and dynamic tracing
US6901581B1 (en) 2002-10-02 2005-05-31 Eridon Corporation Method for software debugging via simulated re-execution of a computer program
US7490103B2 (en) * 2004-02-04 2009-02-10 Netapp, Inc. Method and system for backing up data
US7653899B1 (en) 2004-07-23 2010-01-26 Green Hills Software, Inc. Post-execution software debugger with performance display
US8271955B1 (en) 2004-07-23 2012-09-18 Green Hille Software, Inc. Forward post-execution software debugger
US8132159B1 (en) 2004-07-23 2012-03-06 Green Hills Software, Inc. Post-execution software debugger with event display
US8136096B1 (en) 2004-07-23 2012-03-13 Green Hills Software, Inc. Backward post-execution software debugger
US8015552B1 (en) 2004-07-23 2011-09-06 Green Hills Software, Inc. Post-execution software debugger with coverage display
US9152531B2 (en) * 2005-02-18 2015-10-06 Green Hills Sofware, Inc. Post-compile instrumentation of object code for generating execution trace data
US7620660B2 (en) * 2005-06-30 2009-11-17 Microsoft Corporation Pre-image logging for database recovery
GB0521465D0 (en) * 2005-10-21 2005-11-30 Law Gregory E W System and method for debugging of computer programs
US7325111B1 (en) * 2005-11-01 2008-01-29 Network Appliance, Inc. Method and system for single pass volume scanning for multiple destination mirroring
US7975262B2 (en) 2007-08-16 2011-07-05 Microsoft Corporation Error tracing with context history
US8868982B2 (en) 2012-01-18 2014-10-21 Infineon Technologies Ag Compact function trace based on execution length of leaf functions
US10133653B2 (en) 2012-02-23 2018-11-20 Cadence Design Systems, Inc. Recording and playback of trace and video log data for programs
US9448913B2 (en) * 2013-08-28 2016-09-20 Sap Se Performance metric visualization systems and methods
US9507609B2 (en) * 2013-09-29 2016-11-29 Taplytics Inc. System and method for developing an application
US9875173B2 (en) 2014-06-30 2018-01-23 Microsoft Technology Licensing, Llc Time travel debugging in managed runtime
US10353679B2 (en) * 2014-10-31 2019-07-16 Microsoft Technology Licensing, Llc. Collecting profile data for modified global variables
US9588870B2 (en) * 2015-04-06 2017-03-07 Microsoft Technology Licensing, Llc Time travel debugging for browser components
US9633088B1 (en) 2015-10-20 2017-04-25 Voalte, Inc. Event log versioning, synchronization, and consolidation
WO2018071450A1 (en) 2016-10-11 2018-04-19 Green Hills Software, Inc. Systems, methods, and devices for vertically integrated instrumentation and trace reconstruction
US20180173610A1 (en) * 2016-12-19 2018-06-21 Mediatek Inc. Method for performing cared-zone code coverage evaluation with no source code modification
US10372466B2 (en) 2017-06-13 2019-08-06 Western Digital Technologies, Inc. Rule-based monitoring engine with tracing capabilities for multi-threaded logging

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0468446A (ja) * 1990-07-09 1992-03-04 Mitsubishi Electric Corp デバッグ支援装置
US5784552A (en) * 1993-07-28 1998-07-21 Digital Equipment Corporation Debugging a computer program by simulating execution forwards and backwards in a main history log and alternative history logs
JPH096647A (ja) * 1995-06-21 1997-01-10 Oki Electric Ind Co Ltd 逆実行デバッグシステム
US20050086246A1 (en) * 2003-09-04 2005-04-21 Oracle International Corporation Database performance baselines
JP2012256279A (ja) * 2011-06-10 2012-12-27 Sony Corp 情報処理装置および方法、並びにプログラム
US20150052403A1 (en) * 2013-08-19 2015-02-19 Concurix Corporation Snapshotting Executing Code with a Modifiable Snapshot Definition

Also Published As

Publication number Publication date
US20210117309A1 (en) 2021-04-22
EP3526673A1 (en) 2019-08-21
US20180253369A1 (en) 2018-09-06
EP3526673A4 (en) 2020-06-17
US20220245057A1 (en) 2022-08-04
US9898385B1 (en) 2018-02-20
US9904615B1 (en) 2018-02-27
WO2018071450A1 (en) 2018-04-19
JP7202293B2 (ja) 2023-01-11
US10817404B2 (en) 2020-10-27
CA3039198A1 (en) 2018-04-19
US12001316B2 (en) 2024-06-04
US10324824B2 (en) 2019-06-18
US20200034276A1 (en) 2020-01-30
US20200019487A1 (en) 2020-01-16
US10592394B2 (en) 2020-03-17
US11243871B2 (en) 2022-02-08
US20230325302A1 (en) 2023-10-12
US11609840B2 (en) 2023-03-21

Similar Documents

Publication Publication Date Title
US12001316B2 (en) Systems, methods, and devices for vertically integrated instrumentation and trace reconstruction
EP3788490B1 (en) Execution control with cross-level trace mapping
EP3785127B1 (en) Selectively tracing portions of computer process execution
Patil et al. Pinplay: a framework for deterministic replay and reproducible analysis of parallel programs
US7849450B1 (en) Devices, methods and computer program products for reverse execution of a simulation
EP3785124B1 (en) Memory validity states in time-travel debugging
US20090037887A1 (en) Compiler-inserted predicated tracing
Subhraveti et al. Record and transplay: partial checkpointing for replay debugging across heterogeneous systems
US20190324891A1 (en) Visualizing last/next known data values in time travel traces
EP3785125B1 (en) Selectively tracing portions of computer process execution
US20120131559A1 (en) Automatic Program Partition For Targeted Replay
US11599445B2 (en) Watcher: precise and fully-automatic on-site failure diagnosis
US10671512B2 (en) Processor memory reordering hints in a bit-accurate trace
Raza A review of race detection mechanisms

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201009

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20201009

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210915

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210921

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20211217

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220218

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20220628

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221027

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20221027

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20221116

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20221122

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20221206

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20221223

R150 Certificate of patent or registration of utility model

Ref document number: 7202293

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150