Updates

• 5. November 2017

Auf meinen Fahrten von und zur Arbeit schweife ich hin und wieder gedanklich ein wenig ab. Hier das Ergebnis meiner jüngsten Gedankenexpedition...

Als ich vor inzwischen vielen Jahren in einem Projekt mit VxWorks arbeiten durfte funktionierte alles toll - bis zum ersten Langzeitversuch: Die Analyse der Messwerte dauerte immer länger bis sich die Analysedauer irgendwann asymptotisch einem Höchstwert annäherte.

Das geschah über mehrere Tage hinweg - der Anstieg geschah also sehr langsam, dennoch war das Erreichen der Asymptote bereits zu einem Zeitpunkt erreicht, der weit unterhalb der geplanten durchschnittlichen Missionsdauer lag. Die für die Analyse benötigte Maximalzeit (der asymptotisch erreichte Wert) lag deutlich über dem in der Systemspezifikation vorgegebenen.

Wir mussten also Änderungen vornehmen und dafür mussten wir herausfinden, wo?

Nach längeren Untersuchungen erkannten wir, dass die Speicherverwaltung für unser Board Support Package als einfach verkettete Liste implementiert war und der Speicher während der Laufzeit mehr und mehr fragmentiert wurde - damit wurde die Zeit zum Finden eines passenden Speicherblocks natürlich immer länger, was sich letztlich auf die Analysedauer niederschlug.

Wir waren über diese Diagnose extrem überrascht, denn wir waren eigentlich der Meinung, dass wir dem Leitsatz harter Echtzeitanforderungen gefolgt waren: Beim Start des Systems wird einmal der Arbeitsspeicher aufgeteilt und allokiert, danach startet die eigentliche Arbeit und währenddessen ist Speicher allokieren oder frei geben des Teufels.

Dies wurde durch intensive und gründliche Codereviews sichergestellt - aber woher kam die Fragmentierung und das ständige neu Allokieren? Letztlich fanden wir, dass die STD-Library verantwortlich war: Wir nutzen verkettete Listen und einige andere Datenstrukturen der STDLib und diese benutzen ihr eigenes Speichermanagement, das fröhlich dynamisches Speichermanagement betrieb. NAchdem wir diese wieder ausgebaut hatten (eine undankbare Aufgabe!) war das Performanceproblem gelöst.

Daraufhin kam mir der Gedanke, ob dieses Paradigma: Am Anfang allokieren und dann nur noch mit bestehenden Speicherbereichen (Objekten) interagieren auch in Java möglich wäre?

Es existieren ja bereits diverse Object-Caches, auch ich habe solche für Threads mit Erfolg erstellt und eingesetzt. Weitere übliche Verdächtige sind Connection-Pools für die Kommunikation mit Datenbanken.

Aber funktioniert das für alle (irgendwelche) Objekte? folgende Überlegungen dazu:

• Einen Objektstore für Objekte einer beliebigen Klasse zu bauen ist trivial: Er muss ja ketztlich nur eine Methode zur Herausnahme eines Objektes und eine zum Zurücklegen anbieten. Einen zu bauen für Objekte verschiedener beliebiger Klassen ist nicht wesentlich schwieriger: Man kann dazu als Grundlage die in einem früheren Artikel vorgestellte Mechanik nutzen.
• Aber beim Herausnehmen eines Objektes müsste man sicherstellen, das man ein vollig neuwertiges erhält - etwaige Änderungen des letzten Nutzers (der es wieder zurückgelegt hat) dürfen den neuen Nutzer nicht beeinflussen.
• Dazu wäre es hervorragend, wenn man die Methode <init> per Reflection aufrufen könnte. Aber erstens geht das nicht und zweitens - siehe nächster Punkt
• Java-Objekte sind per se keine Invarianten ohne Seiteneffekte: Man stelle sich ein Objekt vor, das in seinem Konstruktor einen Thread startet und keine Instanzvariable zur Speicherung einer Referenz auf ihn vorsieht - komplett legaler Java-Code, allerdings hat man keine Möglichkeit, diesen Thread wieder einzufangen oder zu stoppen. Würde man dieses Objekt wieder in den Objekt-Cache zurücklegen, wäre die Semantik unklar: soll der Thread damit auch aufhören zu existieren? Soll dafür ein Automatismus greifen?
• Am vorhergehenden Beispiel sind zweierlei Aspekte deutlich zu erkennen: Java ist nicht darauf vorbereitet ein solches Paradigma zu unterstützen und man müsste für alle Objekte, die über einen solchen Objekt-Cache verwaltet werden sollten, eine gemeinsame Semantik fordern: nach dem Zurücklegen muss der Objekt-Cache in der Lage sein, eine Reset-Methode an den Objekten aufzurufen, die folgender Semantik genügen muss: Alle Seiteneffekte der Konstruktion des Objektes sind rückgängig zu machen. Der interne Zustand des Objektes darf von dem eines frisch erzeugten nicht unterscheidbar sein. Der interne Zustand nach Aufruf einer beliebigen Methode mit beliebigen Parametern darf sich für ein frisch aus dem Objektstore geholtes Objekt und ein neu erzeugtes nicht unterscheiden.
• Als ich mit meinen Gedanken an diesem Punkt angekommen war, stellte ich den Nutzeffekt einer tatsächlichen Implementierung und Nutzung in Frage: Wenn man wirklich nur darauf vorbereitete Objekte mit solchen Objekt-Caches verwalten kann - dann ist es eigentlich unmöglich, dadurch messbare Performancegewinne zu erzielen: denn der eigene Code arbeitet mit den Java-Bibliotheken und diversen Third-Party-Bibliotheken zusammen, die alle nicht auf diese Art und Weise versuchen, den Garbage Collector zu entlasten.

Aktualisierung vom 5. November 2017

Artikel, die hierher verlinken