2

メソッドがインライン化される可能性があります。それを防ぐための属性があります（「そのための属性があります」）。ただし、JITter ( http://www.hanselman.com/blog/ReleaseISNOTDebug64bitOptimizationsAndCMethodInliningInReleaseBuildCallStacks.aspx ) による末尾呼び出しの最適化が原因で、メソッドが x64 で独自のスタック フレームを取得しない場合もあります。これは の動作に影響しますMethodBase.GetCurrentMethodか?

私が見つけることができる議論は、主にインライン化に関するものです (メソッドが CLR によってインライン化されるのはいつですか? )。これらの議論はそれ自体興味深いものですが、私の問題は実際MethodBase.GetCurrentMethodには、プログラマーが呼び出しを行った同じメソッドを識別するためにどのような状況 (もしあれば) に依存できるかということです (たとえば、現在のメソッドは実際にはサロゲートです)。インライン化はMethodBase.GetCurrentMethodだまされやすい方法ですが、それしか方法がないのでしょうか?

4

1 に答える 1

2

いいえ-メソッドは実行時にインライン化されるか、インライン化されません。

誰かが独自のランタイムを実装した場合、それはだまされる可能性があると私は信じています-MethodBase.GetCurrentMethod最終的にはこれに要約され、次のように宣言されていRuntimeMethodHandleます：

[SecurityCritical]
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern IRuntimeMethodInfo 
  _GetCurrentMethod(ref StackCrawlMark stackMark);

カスタムランタイムでは、それは何でもできます-そして将来的にはそれも何でもできるようになります。現時点では、Microsoftランタイムが正しいメソッドを返さない唯一の方法は、コードがインライン化されている場合だと思います。たとえば、モノについて話すことはできません。ただし、常にそうなることに依存することは、コードの一部が機能できるようにするために、内部タイプの反映されたプライベートフィールドが常に存在することに依存するようなものだと思います。

私が試したほとんどすべての場合（今はもう心配していません）、または誰かがプロファイリング以外で呼び出し元のメソッドを確実に識別できる必要があることを正当化しようとすると、インラインメソッドの問題が常に発生します。

しかし、現実には、これらの方法について心配することはどれほど重要なのでしょうか。

信頼性が絶対的に重要である場合は、ILリライターのポストコンパイルを使用してロギング呼び出しを挿入することで、より多くの幸運を得ることができます。これは必然的にメソッドを認識する可能性があるため、たとえそれが行われたとしても、インライン化を覆す可能性があります（書き換えられたILが十分に大きくなり、パフォーマンスが低下した場合はそうではない可能性があります）。または、自分でローリングしたくない場合は、PostSharpなどのAOPライブラリが適切である可能性があります。

于 2012-01-17T22:58:23.100 に答える