RyuJIT

Eintrag zuletzt aktualisiert am: 14.08.2017

RyuJIT ist der Name für die neue Version des Just-In-Time (JIT) Compiler in der .NET Common Language Runtime (CLR) in .NET Framework 4.6. Den im Jahr 2005 eingeführten Just-in-Time-Compiler für 64-Bit-Anwendungen hat Microsoft auf schnellere Weise komplett neu implementiert. Anwendungen auf 32-Bit-Systemen bzw. Anwendungen, die in den 32-Bit-Modus auf 64-Bit-Systemen gezwungen werden müssen, profitieren von dem neuen Just-in-Time-Compiler aber noch nicht. Microsoft will einen überarbeiteten 32-Bit-Just-In-Time-Compiler erst in einer späteren Version liefern.

Update 14.8.2017

In .NET Core 2.0 kommt nun auch in 32-Bit-Version RyuJIT zum Einsatz,

Versionsgeschichte

Erste Version: 30 Sep 2013 1:53 PM
http://blogs.msdn.com/b/dotnet/archive/2013/09/30/ryujit-the-next-generation-jit-compiler.aspx

Erschienen am 20.7.2015 in .NET Framework 4.6

Bugwarnung!

In dem am 20.7.2015 veröffentlichten .NET Framework 4.6 war im neuen Just-in-Time-Compiler „RyuJIT“ ein signifikanter Bug enthalten, der dazu führen kann, dass in bestimmten Situationen Methoden falsche Parameter erhalten. Dies führt nicht nur zu falschen Ergebnissen, sondern das Problem könnten auch Angreifer nutzen. Microsoft hat dieses Problem am 11.8.2015 mit einem Sicherheitsupdate MS15-092 [https://technet.microsoft.com/library/security/ms15-092.aspx] behoben, das auf allen .NET-Systemen, auf denen .NET Framework 4.6 installiert ist, unbedingt eingespielt werden sollte.

Bemerkt hat den Fehler die Website stackoverflow.com der Firma StackExchange. Das Problem ist weder bei Microsofts internen Tests noch den Kunden bei der Nutzung der Vorabversionen aufgefallen. Während stackoverflow.com grundsätzlich davor warnte, .NET 4.6 einzusetzen, schlug Microsoft zunächst vor, für C# und Visual Basic .NET einfach den neuen Just-in-Time-Compiler bzw. dessen Tail-Code-Optimization abzuschalten: "It is perfectly safe to run the .NET Framework 4.6 with tail call optimizations disabled, while you are waiting for the patch", schreibt Rich Lander im .NET-Blog. "We recognize that this bug is very real to StackExchange, and conclude that they are one of the few cases that have and will hit it."