Java JVMが例外をスローする可能性のあるメソッドをインライン展開することが可能なのはどうか不思議です。私は、少なくともいくつかのメソッド（配列へのアクセスを持ち、したがってArrayIndexOutOfBoundsExceptionを投げる可能性があるもの）をインライン化することが可能であると仮定します。私が見ている問題は、例外が実際に発生した場合、メソッドをインライン展開した場合、どのように適切なスタックトレースを表示するのですか？異なるメソッドが異なるマシン上にインライン化できるので、インライン化はどのようにスタックトレースメカニズムを壊さないのでしょうか？例外をスローするメソッドはどのようにインライン化できますか？
あなたが想定している問題は何ですか？インライン展開を行うのはJVMそのものなので、Throwableオブジェクトにインストールするスタックトレースを作成するときに、インライン展開の場所とその場所を覚えておくことはできません。
が生成された場合、JVMはCPUスタックを歩き、各マシンスタックフレームが解釈済みバイトコード、JITtedコード、ライブラリのネイティブコードなどに対応するかどうかを調べます。これは、マシンコード内のどのアドレスがバイトコードからのどの命令に対応するかを指示するテーブルを参照します（さらに、その情報がクラスファイル内にある場合はソース行に戻ります）。この表は、JITtedコードの特定の場所が複数のJavaレベルのスタックフレームに対応できることを完全に指定できます。
ただし、JVMにはが必要です。これを行うにはが必要です。不思議なブレークを伴うスタックトレースを構築することも簡単に選択できます。 javadoc for Throwable.getStackTrace()を参照してください。 （JVMがスタックトレースを全く生成できないという要求も全くありません。）。
あなたは例外処理は、JVMでどのように機能するかを説明しthis documentをチェックアウトする場合があります：
キャッチ例外はと一緒にクラスファイルで配信 ある例外テーブルに関連付けられているそれぞれの方法バイトコードシーケンスである。例外テーブルには、例外ごとに1つのエントリがあり、各tryブロックによってキャッチされる です。各エントリは、 の開始点と終了点、バイトコードシーケンス 内のジャンプするpcオフセット、例外クラスの定数プールインデックス の4つの情報をキャッチします。
私はそれを調べることに興味があるでしょう。私は特に、インライン化と例外との相互作用について尋ねていました。関数がインライン展開されると、スタックトレース情報は失われるはずですが、Javaプログラムには含まれていないようです。 – Gravity
Javaでのインライン展開はC/C++のようなコンパイル時ではなく、実行時に行われるため、情報を失うことはありません。最適化され、検索される必要のある情報は、ルックアップ/ジャンプテーブルに格納することができます。 –
ルックアップテーブルに例外情報を格納しないと、特にArrayIndexOutOfBoundsなどの非常に一般的な例外で許容できないパフォーマンスが発生しますか？ – Gravity
C++では、インライン展開はスタック情報の損失をほぼ保証します。しかし、例外スタックトレースにフレームがないという事実は、世界の終わりではありません。インライン展開の結果として受け入れられるだけです（そして、コンパイラがすべてのインライン展開を抑制するデバッグモードオプションを提供する理由の1つ）。私はJavaが同じように動作するかどうかはわかりません。 –
私はこれがJavaの質問であることを意味しましたが、C++でのこの動作の仕方についても興味深いです。 – Gravity