Skylake und der Albtraum-Bug: Entwickler schildert, wie er ihn entdeckt hat
Entwickler Joris Giovannangeli hat in einen sehr ausführlichen Blog-Beitrag beschrieben, wie er zusammen mit anderen den sogenannten Albtraum-Bug in Skylake-Prozessoren entdeckt hat.
Wer sich für die Hintergründe bei der Entdeckung des sogenannten "Albtraum-Bugs" in Skylake-Prozessoren interessiert, sollte sich einmal den Blog-Eintrag des Entwicklers Joris Giovannangel zu Gemüte führen. Darin geht er detailliert darauf ein, welcher Aufwand damit verbunden war, den Bug zu reproduzieren und identifizieren.
So fiel es dem Team anfangs schwer, den Fehler, der beim Kompilieren von Ocaml ausgelöst wurde, nachzustellen. Augenscheinlich handelte es sich dabei um ein Segfault, einen Speicherfehler, der betroffene Speicherbereich lag jedoch außerhalb des Adressbereichs der Anwendung.
Weil die zur Identifizierung des Fehlers nötigen Werkzeuge unheimlich viel Leistung benötigen, wechselte das Team anschließend von den Entwickler-Rechnern auf einen Server. Dort ließ sich der Fehler jedoch gar nicht mehr reproduzieren und das Team erkannte, dass er nur in Zusammenhang mit Skylake-Systemen auftritt.
Diese Vermutung sei laut Giovannangeli unüblich, jedoch hielt er an dem Gedanken fest, weil er den Bericht eines Ocaml-Entwicklers im Hinterkopf hatte, der sich um einen ähnlichen Fehler im Zusammenhang mit Hyperthreading und Skylake dreht. In Intels-Errata-Liste gab es bis dato jedoch keine passende Beschreibung. Auch ein entsprechendes Microcode-Update fehlte.
Also unterstellte das Team, dass der den Speicherfehler verursachende Code derjenige ist, der den entsprechenden Bereich auch schreibt und liest. Im besagten Fall also der Garbage Collector. So konnte man schließlich eine spezifische Kombination von Register-Befehlen im Assemblercode als Auslöser identifizieren. Genau diese Registerfrequenzen werden auch im jüngsten Microcode-Update genannt.
Viele weitere Details lesen Sie in englischer Sprache im Blog-Beitrag des Entwicklers. Mehr über Skylake auf der PCGH-Themenseite.
Quelle: Joris Giovannangeli
Das Problem sind dynamische Speicherbereiche, bei denen man nicht mal zur Laufzeit genau weiß wann man sie wieder freigeben können wird. Da muss man dann schon eine Menge Grips in die Speicherverwaltung stecken wenn man den Speicher effizient nutzen will. Und da sind moderne Garbage-Collectoren eben nicht nur zuverlässiger, sondern auch schneller (sprich sie gehen mit dem Speicher effizienter um).
Und gerade die aktuellen Versionen von C++ bieten zahlreiche Werkzeuge um eine Speicherverwaltung sauber zu programmieren.
Ausser in Java würde ich mich nie auf einen Garbagecollector verlassen.
Dafür weiß ich lieber genau was wann wo mit meinem Speicher genau passiert.
Auch die Compiler bieten ja reichlich Möglichkeiten den Speicherverlauf zu verfolgen.
Vielleicht komme ich einfach aus einer anderen Zeit, wo eben immer selbst auf die Speichernutzung bis ins letzte Bit geachtet werden müsste, aber für mich sind das einfach Grundsätze, die in Zeiten von billigem Speicher und genug Rechenleistung den meisten abgehen.
Das Problem sind dynamische Speicherbereiche, bei denen man nicht mal zur Laufzeit genau weiß wann man sie wieder freigeben können wird. Da muss man dann schon eine Menge Grips in die Speicherverwaltung stecken wenn man den Speicher effizient nutzen will. Und da sind moderne Garbage-Collectoren eben nicht nur zuverlässiger, sondern auch schneller (sprich sie gehen mit dem Speicher effizienter um).
Die Realität ist eine andere: Sowohl die automatisierten Garbage-Collectoren als auch die Compiler produzieren in den allermeisten Fällen ein schnelleres Ergebnis als ein mühsam per Hand zusammen opimiertes Programm - das meistens ganz ohne Speicherlecks und Bugs