2012-10-01 11 views
5

Ich würde gerne verstehen, wie allgegenwärtig JIT Inlining sein kann.Ist es für JIT-Inlining möglich, meinen Code in einigen .NET-Laufzeitassembly-Code einzubinden?

Angenommen, in meinem Code rufe ich eine Funktion von sagen System.IO Assembly und übergeben Sie einen Callback-Verweis auf eine Funktion in meinem Code für den Aufruf von innerhalb dieser System.IO Funktion implementiert. In meiner Funktion gibt es GetCallingAssembly() Anruf. Also, wenn mein Callback in System.IO inline wird der Anruf an GetCallingAssembly(), die ursprünglich in meinem Code war und sollte sagen, die "aktuelle" Methode heißt von innen System.IO wird sagen, dass es jetzt aus meinem Code aufgerufen wird.

Ist ein solches Inlining möglich oder werden .NET-Laufzeitassemblies unterschiedlich behandelt, so dass JIT-Inlining von Benutzercode in .NET-Laufzeitcode nicht zulässig ist?

+1

Wie würde ein Delegate-Callback jemals in den Callback-Invoker eingebunden werden? Ich bin mir nicht sicher, ob das Sinn macht ...? Mein Verständnis ist, dass Inlining auf Szenarien beschränkt ist, in denen der aufzurufende Code ** beweisbar ** ist - d. H. Ein statischer Aufruf oder ein virtueller Aufruf an eine nicht-virtuelle Methode. –

+0

@Mark Gravel: Warum konnte es nicht, wenn das das einzige Aufruf des Callback-Aufrufers im gesamten Programm ist? – sharptooth

+0

I * suspect * das ist mehr Mühe zu verstehen, als das JIT jemals tun wird, besonders da Reflektion/Meta-Programmierung existiert (was bedeutet: neue Caller könnten später existieren) –

Antwort

3

Sie können davon ausgehen, dass der Callback nicht inline ist. .NET Framework-Assemblys werden bei der Installation immer von ngen.exe voreingestellt. Es gibt keine Möglichkeit, diesen Code nachträglich zu ändern. Außerdem werden Callbacks über einen Delegaten niemals inline ausgeführt, selbst wenn der Jitter-Optimierer die Zielmethode des Delegaten ableiten könnte.