![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Optimierungsparameter für Sun-HotSpot-JVMs (Solaris und HP-UX)
Die Optimierung einer Sun-HotSpot-JVM (Java™ Virtual Machine) ist ein iterativer Prozess, in dem die JVM-Konfiguration entwickelt, Daten (primär die verbosegc-Daten) erfasst und anschließend analysiert werden. Konfigurationsüberarbeitungen werden dann im nächsten Zyklus angewendet.
Es gibt zwar zahlreiche Parameter für die Sun-HotSpot-JVM, aber die folgenden Parameter haben sich als zentrale Optimierungsparameter herausgestellt. Welchen dieser Parameter Sie ändern, richtet sich nach Ihren Konfigurationsoptionen. Deshalb können Sie zusätzliche zu diesen Parameterbeschreibungen die Informationen zum Optimieren von HotSpot Java Virtual Machines (Solaris und HP-UX) lesen, um sich umfassende Kenntnisse in der Optimierung von JVMs anzueignen.
Alle Sun-HotSpot-Optionen werden in einem Standardformat angegeben. Das Verständnis dieses Formats hilft Ihnen, Probleme bei der Übertragung der Optionen, Probleme der Interpretation der Anweisungen und potenzielle Verwirrungen zu vermeiden, die entstehen können, wenn die JVM eine Option zurückweist und danach nicht gestartet wird.
-XX:+ Option
-XX:- Option

- Ein Pluszeichen oder Minuszeichen muss dem Doppelpunkt direkt folgen. Andernfalls erfordert die Option gewöhnlich einen Wert und sieht eher wie die Zuordnung eines Werts aus, weil sie das Format Option=Wert hat.
- Wie auf der SUN-Website angegeben, können die Hotspot-Optionen vom Typ "-XX" jederzeit ohne weitere Mitteilung in nachfolgenden Releases des JDK geändert werden. Deshalb sollten Sie sich vor der Angabe einer Option vergewissern, dass diese für die JDK-Version, die auf Ihrem System ausgeführt wird, unterstützt wird.
Bei der Bestimmung der zu verwendenden Option beschreibt gewöhnlich der Name der Option die Aktion, die bei der Aktivierung der Option ausgeführt wird. Standardmäßig bleibt das Feature bei den meisten Optionen inaktiviert. Wenn Sie eine Option inaktivieren, die bereits ein Feature aktiviert, kann dies zu einer Situation mit doppelter Verneinung führen. Dies ist inbesondere der Fall bei Optionen, deren Namen mit dem Wort "Disable" beginnen. Die Standardeinstellung für die Option "DisableExplicitGC" bewirkt beispielsweise, dass die JVM explizite Anforderungen für eine Garbage-Collection berücksichtigt. Normalerweise aktivieren Sie diese Option deshalb, indem Sie ein Pluszeichen for diese Option setzen. Das Pluszeichen bewirkt, dass die Berücksichtigung expliziter Anforderungen einer Garbage-Collection inaktiviert wird, also genau das, was der Name der Option impliziert. Bei Optionen wie "DisableExplicitGC" trifft man die Einstellung "-XX:-DisableExplicitGC" selten an, weil diese Einstellung gleichbedeutend mit der Standardaktion ist.
Wenn der Name der Option den Begriff "Use" enthält, macht die Option in Bezug auf die Aktivierung oder Inaktivierung des Features in der Regel mehr Sinn, und die Verwendung des Plus- bzw. Minuszeichens erfolgt eher intuitiv.
Wenn ein Wert angegeben werden muss, erscheint die Option wie eine Zuordnung mit einem Gleichheitszeichen zwischen der Option und der Einstellung. In einer solchen Situation erwartet die Option, dass dem Gleichheitszeichen unverzüglich ein entsprechender Zahlenwert folgt, d. h. ohne Leerzeichen zwischen dem Gleichheitszeichen und der Zahl. Häufig können mit dem Wert Standardabkürzungen wie k für Kilobytes, m für Megabytes oder g für Gigabytes angegeben werden, sofern die Angabe dieser Werte angemessen ist. Die virtuelle Maschine führt nur eine beschränkte Validierung solcher Parameter durch, und erzeugt gewöhnlich eine Fehlernachricht, in der darauf hingewiesen wird, dass die virtuelle Maschine nicht gestartet werden kann, falls dieser Wert ungültig ist.
-Xmx (maximale Größe des Java-Heapspeichers)
Optimieren Sie diesen Parameter zusammen mit dem Parameter -XX:MaxPermSize, um genügend Java-Heapspeicher bereitzustellen. Wenn Sie einen Wert für die maximale Größe des Java-Heapspeichers für die Objektspeicherung im Java-Heapspeicher angeben, müssen Sie den Spitzenressourcenbedarf berücksichtigen, der für die Verarbeitung von Spitzeneingangsvolumen erforderlich ist, die vom System behandelt werden können.
Im Gegensatz dazu muss die Anfangsmindestgröße des Java-Heapspeichers, die mit dem Parameter -Xms angegeben wird, die Dimensionierung des Java-Heapspeichers widerspiegeln, die erforderlich ist, um die persistenten Daten zu speichern, die beim normalen Betrieb des Systems mit herkömmlichen konstanten Eingabelasten entstehen. Eine solche Ressourcenanforderung gewährleistet einen effizienten Systemstart, bei dem nur so viel Speicher beansprucht wird, um eine schnelle Initialisierung zu ermöglichen, ohne dass zahlreiche Garbage-Collection-Zyklen durchgeführt werden, die eine Erhöhung der Heapspeicherkapazität erfordern. Danach variiert die Betriebskapazität des Java-Heapspeichers zwischen der normalen Kapazität, die für herkömmliche konstante Workloads bekanntermaßen ausreicht, und der im Systemdesign definierten Spitzengröße, und alle Variationen der Heapspeicherkapazität müssen Änderungen bei den Systemeingaben, wie z. B. einen plötzlichen Anstieg de Aktivitäten oder die Zunahme der Workload, reflektieren.
Die Betriebskapazität des Java-Heapspeichers liefert hilfreiche Informationen zum Ausführungsstatus des Systems. Die Optimierung der Anfangsmindestgröße des Java-Heapspeichers sollte nur zur Optimierung des Systemstarts dienen. Wenn Sie die Mindestgröße und die Maximalgröße des Heapspeichers auf denselben Wert setzen, ist der Java-Heapspeicher fest definiert und beschränkt die Wiederherstellungsoptionen der JVM in Bezug auf das Housekeeping des Java-Heapspeichers. Dieser Typ von Konfiguration kann zu Leistungseinbußen und einer schlechten Nutzung der Java-Heapspeicherressourcen führen.
-XX:+AggressiveHeap
Verwenden Sie diesen Parameter, wenn Sie den Standardkollektor für Durchsatz/parallelen Rücklauf mit aktivierter integrierter Optimierung verwenden. Die JVM kann versuchen, die Parameter ihrer Optimierungsalgorithen, basierend auf der Verwendung aller Ressourcen des verwendeten Betriebssystems, aggressiv zu optimieren. In Situationen, in denen ein einziger Produktprozess alle Ressourcen des Betriebssystems nutzt, können Sie diese Option verwenden, um festzustellen, ob die JVM zufriedenstellende Ergebnisse liefert. Die Verwendung dieser Option beim Testen von JVM-Ergebnissen sollte Ihren Optimierungsaufwand reduzieren.
-XX:CMSInitiatingOccupancyFraction=75
Konfigurieren Sie dieen Parameter, wenn Sie den Kollektor "concurrent low-pause mark-sweep" verwenden. Diese Option wird für die CMS-Steuerung verwendet. Dieser Parameter legt die Auslöserbedingung für den dedizierten Hintegrundthreads für die Durchführung einer Garbage-Collection in der Langzeitregion des Heapspeichers. Anders als in anderen Garbage-Collection-Modi wartet die Garbage-Collection-Aktion nicht darauf, dass eine Zuordnung scheitert. Das Ziel besteht vielmehr darin, die Garbage-Collection auszulösen, um ausreichend Speicherplatz zur Verfügung zu stellen, bevor die Zuordnung vorgenommen wird, die sonst gescheitert wäre. Der eigentliche Auslöser basiert auf der prozentualen Belegung des Java-Heapspeichers und liegt standardmäßig bei ungefähr 70 %. Dieser Standardwert gewährleistet normalerweise, dass genügend CMS-Zyklen gestartet werden, obwohl dieses Intervall wahrscheinlich kürzer als erforderlich ist.
Wenn jedoch nur eine sehr kleine Eden-Region vorhanden ist und keine so Survivor-Bereiche verwendet werden, haben Objekte praktisch keine Chance zu altern, sodass bei der Garbage-Collection nach Objektalter Objekte mit kurzer Lebensdauer erfasst werden können. Auf Systemen, die aus der Garbage-Collection nach Objektalter einen Nutzen erzielen, indem viele relativ Objekte mit kurzer Lebensdauer erzeugt werden, verhindern die CMS-Standardwerte die Möglichkeit, die Unterstützung für die Garbage-Collection nach Objektalter zu nutzen, für die die Sun-HotSpot-Struktur hauptsächlich entworfen wurde. Mit einer nur geringen Investition von Ressourcen in die Young-Generation-Survivor-Bereiche und einer angemessenen Eden-Region dauert die Pause für die erneute Aktivierung einer vollständigen Garbage-Collection nach Objektalter maximal eine Sekunde, wodurch die Umstufung älterer Objekte in die Langzeitregion auf ein Minimum reduziert wird. Dies bietet Ihnen die Möglichkeit, alle Vorteile einer freien Komprimierung noch aktiver Inhalte mit zunehmendem Objektalter vollständig zu nutzen, und der CMS-Thread ist in der Lage, die Langzeitregion auch das zu erfassen, wenn der Heapspeicher sehr groß ist.
-XX:+DisableExplicitGC
Diese Option inaktiviert die explizite Garbage-Collection, um alle nicht erforderlichen oder unpassenden Garbage-Collection-Hauptzyklen zu verhindern, die in Softwarekomponenten des Systems eingeführt werden können.
Entwicklern wird empfohlen, die Verwendung von System.gc()-Aufrufen zur Einleitung explizit eingeleiteter Garbage-Collection-Zyklen mit vollständiger Komprimierung zu vermeiden, weil sich solche Aufrufe nachteilig auf die Optimierung der Ressourcen und die Garbage-Collection für ein vollständiges Anwendungssystem auswirken können. Wenn Sie die schwierigen Anforderungen bezüglich der Pausenzeiten erfüllen und vom Programmierer eingeleitete Garbage-Collection-Aufrufe verhindern möchten, sollten Sie die Verwendung dieser Option unbedingt in Betracht ziehen, weil sie dafür sorgt, dass explizite System.gc()-Aufrufe ignoriert werden.
-XX:MaxNewSize= und -XX:NewSize=
Verwenden Sie diese Parameter, wenn Sie den Scavenger-Kollektor für Durchsatz und Parallelverarbeitung verwenden, aber entschieden haben, diesen manuell zu optimieren, anstatt die integrierte Optimierung über den Parameter -XX:+UseAdaptiveSizePolicy zu nutzen. Die aktuelle Young-Generation-Größe muss größer-gleich der Young-Generation-Anfangsgröße bzw. -Mindestgröße sein und wird mit dem Parameter -XX:NewSize angegeben. Diese Größe ist kleiner-gleich dem Wert, der für die maximale Young-Generation-Größe mit dem Parameter -XX:MaxNewSize angegeben wird.
Bestimmte Umstände können Sie dazu veranlassen, den Heapspeicher für die Garbage-Collection nach Objektalter mit dem Parameter -XX:NewRatio zu beschränken, was gewöhnlich den maximalen Young-Generation-Umfang und gewöhnlich auch die Mindestgröße beschränkt. Wenn Sie beispielsweise einen Grenzwert für ein großes Objekt, das von der Garbage-Collection nach Objektalter erfasst werden könnte, festlegen oder die maximale Speicherkapazität beschränken möchten, die gewöhnlich über die Speicherkapazität für persistente Objekte mit langer Lebensdauer hinaus benötigt wird, müssen Sie möglicherweise eine maximale Größe für den Young-Generation-Heapspeicher festlegen. Die Festlegung einer Mindestgröße für den Abschnitt des Heapspeichers, der für die Young-Generation-Objekte verwendet wird, geht gewöhnlich mit der Optimierung der Survivor-Bereiche einher, die in der Regel zweitrangig ist, aber die Vorgaben für die Mindestressourcen im Java-Heapspeicher erfüllen muss, die mit dem Parameter -Xms angegeben werden.
Sofern Sie kein bestimmtes Verhalten bei der Garbage-Collection nach Objektalter erreichen möchten, ist es normalerweise unnötig, einen minimalen und maximalen Wert, gesondert von der Option "NewRatio" festzulegen. Die Gründe für die Festlegung der minimalen und maximalen Werte sind gewöhnlich unterschiedlich. In den seltensten Fällen müssen diese Einstellungen auf denselben Wert gesetzt werden, obwohl der Parameter -Xmn die Möglichkeit bietet, die Größe des Young-Generation-Abschnitts schnell und problemlos festzulegen oder zu korrigieren. Eine nicht ordnungsgemäße Konfiguration macht jedoch die Vorteile der Garbage-Collection nach Objektalter unter Umständen vollkommen zunichte.
-XX:MaxPermSize (Permanente Region)
Optimieren Sie diesen Parameter zusammen mit dem Parameter -Xmx, um genügend Java-Heapspeicher bereitzustellen. In der permanenten Region werden alle Klassencodes und klassenähnlichen Daten, wie z. B. interne Zeichenfolgen, gespeichert.
Die permanente Region muss groß genug sein, damit alle Klassen gespeichert werden können, die unter Umständen gleichzeitig geladen werden. Die Festlegung einer angemessenen Größe für diese Region kann ein Problem darstellen, weil diese Region des Heapspeichers kleiner ist, weniger schnell anwächst, speziell für klassenähnliche Objekte verwendet wird und eshalb mit der aktuellen Kapazität gewöhnlich zu 99-100 % ausgelastet ist. Abnormale Speicherbedingungen müssen deshalb besonders sorgfältig interpretiert werden. Vergewissern Sie sich stets, dass diese Region maximal ausgelastet ist, bevor Sie dieser Region weitere Ressourcen zur Verfügung stellen.

-XX:MaxTenuringThreshold=Anzahl_der_Collections
Konfigurieren Sie diesen Parameter, wenn Sie den Kollektor "concurrent low-pause mark-sweep" verwenden. Dieser Parameter steuert die Umstufung der Objekt aus dem Abschnitt der neuen Generation in den Old-Generation-Abschnitt. Er legt fest, wie lange (in Anzahl Garbage-Collections) ein Objekt im Abschnitt der neuen Generation verbleibt, bevor es in den Old-Generation-Abschnitt verschoben wird. Der Standardwert ist 8.
-XX:NewRatio=2
Verwenden Sie diesen Parameter, wenn Sie den Scavenger-Kollektor für Durchsatz und Parallelverarbeitung verwenden, aber entschieden haben, diesen manuell zu optimieren, anstatt die integrierte Optimierung über den Parameter -XX:+UseAdaptiveSizePolicy zu nutzen.
Der Java-Heapspeicher ist in zwei Abschnitte unterteilt, in denen Objekte gespeichert werden. In dem einen Abschnitt, in dem auch die Garbage-Collection nach Objektalter stattfindet, sind die Young-Generation-Objekte enthalten. Der andere Abschnitt, der den Rest des Heapspeichers umfasst, wird als Langzeit-Heapspeicher bezeichnet und enthält die alten Objekte bzw. die Objekte mit langer Lebensdauer. Mit dieser Option legen Sie die Größe der Young-Generation-Region, die die Garbage-Collection nach Objektalter unterstützt, proportional zur Gesamtkapazität des Heapspeichers fest. Die aktuelle Young-Generation-Größe muss größer-gleich der Young-Generation-Anfangsgröße bzw. -Mindestgröße sein und wird mit dem Parameter -XX:NewSize angegeben. Diese Größe ist kleiner-gleich dem Wert, der für die maximale Young-Generation-Größe mit dem Parameter -XX:MaxNewSize angegeben wird. Die Young-Generation-Größe wird im Verhältnis zur Langzeitregion verwaltet und anhand der aktuellen Kapazität des Haupt-Java-Heapspeichers bestimmt. Der Standardwert 2 bedeutet, dass die Langzeitregion doppelt so groß ist wie die Young-Generation-Region, was wiederum bedeutet, dass die Young-Generation-Region ein Drittel des Gesamt-Java-Heapspeichers beträgt.
Dieser Standardwert liefert gewöhnlich eine angemessene Leistung der Garbage-Collection nach Objektalter, was das typische Ziel der Optimierung der Sun-HotSpot-JVM ist. Es gibt jedoch auch noch andere Strategien. Sie können beispielsweise den Anteil des Heapspeichers erhöhen, in dem die Garbage-Collection nach Objektalter durchgeführt wird. Wenn Sie sich dazu entschließen, das Verhältnis zu ändern, müssen Sie dabei beachten, dass eine angemessene Verwaltung über die Garbage-Collection nach Objektalter nur bis zu einer bestimmten Größe des Heapspeichers möglich ist und bei einer Überschreitung dieses Limits alle Garbage-Collections nach Objektalter verloren gehen können, weil an Stelle der kurzen Garbage-Collection-Zyklen, bei denen nur der Teil des Heapspeichers nach Objektalter berücksichtigt wird, langwierige Garbage-Collection-Zyklen für den gesamten Heapspeicher durchgeführt werden.
Der Standardwert für einen Server, der im VM-Modus ausgeführt wird, ist 2.
-XX:NewSize=128m
Konfigurieren Sie dieen Parameter, wenn Sie den Kollektor "concurrent low-pause mark-sweep" verwenden. Die aktuelle Young-Generation-Größe muss größer-gleich der Young-Generation-Anfangsgröße bzw. -Mindestgröße sein und wird mit dem Parameter -XX:NewSize angegeben. Eine der Schwierigkeiten bei der Optimierung mit CMS ist die, dass die Garbage-Collection im schlimmsten Fall, nämlich beim Abbruch des CMS-Zyklus, mehrere Sekunden dauern kann, was insbesondere auf Systemen Kosten verursacht, die CMS einsetzen, um lange Pausen zu verhindern.
Service-Level-Agreements können die Verwendung von CMS vorschreiben. In diesem Fall muss die Optimierung so sicher sein, dass CMS jede Möglichkeit hat, erfolgreich zu arbeiten. CMS ist nur erfolgreich, wenn der vorausschauende CMS-Trigger sicherstellt, dass der CMS-Zyklus früh genug gestartet wird, damit stets ausreichend freie Ressourcen verfügbar sind, bevor diese angefordert werden. Wenn der CMS-Kollektor nicht abgeschlossen werden kann, bevor sich die Region mit den älteren Objekten füllt, wird die Collection durchgeführt, indem die Anwendungsthreads angehalten werden. Dies wird als vollständige Gargabe-Collection bezeichnet. Vollständige Garbage-Collections sind ein Hinweis darauf, dass eine weitere Optimierung erforderlich ist, damit der Collection seine Operationen besser an Ihre Anwendung anpassen kann.
-XX:+PrintTenuringDistribution
Diese Option ist eine Protokollierungsoption für die Garbage-Collection, die die Ausgabe von Informationen zum Alter der Objekte in den verschiedenen Survivor-Bereichen ermöglicht.
-XX:SurvivorRatio=
Verwenden Sie diesen Parameter, wenn Sie den Scavenger-Kollektor für Durchsatz und Parallelverarbeitung verwenden, aber entschieden haben, diesen manuell zu optimieren, anstatt die integrierte Optimierung über den Parameter -XX:+UseAdaptiveSizePolicy zu nutzen, oder wenn Sie versuchen, den "Concurrent Low Pause"-Kollektor zu optimieren.
Bei der Garbage-Collection nach Objektalter werden Objekte mit kurzer Lebensdauer von solchen mit langer Lebensdauer unterschieden. Im Heapspeicher müssen nur die Objekte verbleiben, die weiterhin im Gebrauch sind. Die Young-Generation-Region, in der die Garbage-Collection nach Objektalter durchgeführt wird, enthält weitere interne Strukturen. Sie enthält eine große Eden-Region, der die Objekte zunächst zugeordnet werden, und kleinere Survivor-Bereiche, in denen Objekte mit längerer Lebensdauer abgelegt werden. Die SurvivorRatio-Größen dieser Region in Bezug auf die Größe der Eden-Region ist relativ zu denen kleineren Survivor-Bereichen. Die Dimensionierung der Survivor-Bereiche ist gewöhnlich zweitrangig, weil das Volumen der Objekte, die von der Optimierung profitieren können, je nach Anwendung stark variiert. In der Regel sollten Sie den Standardwert 25 dieser Einstellung jedoch auf einen kleineren Wert wie z. B. 8 setzen.
Alle Änderungen, die Sie an diesem Parameter vornehmen, müssen das Ergebnis einer Permanenzanalyse der Daten sein. Sie können den Parameter -XX:+PrintTenuringDistribution verwenden, um diese Daten zu erhalten.

-XX:TargetSurvivorRatio=
Verwenden Sie diesen Parameter, wenn Sie den Scavenger-Kollektor für Durchsatz und Parallelverarbeitung verwenden, aber entschieden haben, diesen manuell zu optimieren, anstatt die integrierte Optimierung über den Parameter -XX:+UseAdaptiveSizePolicy zu nutzen.
Dieser Parameter weist die JVM an, die prozentuale Belegung der Survivor-Bereiche zu erhöhen und damit eine vorzeitige möglichst zu verhindern und die Chancen zu erhöhen, dass Objekt über Young Generation erfasst werden. Der Standardwert ist 50. Eine bessere Belegung dieser Regionen kann erreicht werden, indem Sie diesen Parameter auf 90 setzen.
-XX:+UseAdaptiveSizePolicy
Verwenden Sie diesen Parameter, um die integrierte Optimierung mit dem Scavenger-Kollektor für Standarddurchsatz/-parallelität zu aktivieren.
Zusätzlich zur automatischen Erkennung von Betriebssystemen bietet Sun einen Optimierungsalgorithmus an, der versucht, die JVM autonom anzupassen, um das Durchsatzziel und die Effizienz der Collection-Strategie für Durchsatz zu optimieren. Dieser Optimierungsalgorithmus ist standardmäßig aktiviert und wird explizit mit dem Parameter -XX:+UseAdaptiveSizePolicy genutzt. Mit diesem Optimierungsalgorithmus werden gewöhnlich zufriedenstellende Ergebnisse für die Mehrzahl der Anwendungsworkloads erreicht, was Ihnen weitere Optimierungsbemühungen erspart. Sie sollten diesen Algorithmus jedoch für Ihre Workload testen und sicherstellen, dass er Ihre Durchsatzanforderungen erfüllt, bevor Sie ihn in einer Produktionsumgebung einsetzen.
-XX:+UseConcMarkSweepGC
Verwenden Sie diesen Parameter, wenn Sie den "concurrent low-pause mark-sweep"-Kollektor verwenden. In diesem Garbage-Collection-Modus wird die Garbage-Collection nach Objektalter so rekonfiguriert, dass die invasiven Pausen, die durch die Erfassung des Young-Generation-Inhalts entstehen, automatisch auf ein Minimum reduziert werden.
Dieser Parameter minimiert auch den Young-Generation-Umfang bzw. den Umfang der Eden-Region. Serverklassensysteme erkennen gewöhnlich die Verfügbarkeit mehrerer Prozessoren und versuchen, Young Generation parallel zu erfassen, um die invasiven Pausen so auf einem absoluten Minimum zu halten, selbst wenn die Workload gering ist, was die Vorteile der Verwendung mehrerer Threads nach dem Koordinationsaufwand nahezu zunichte macht. Um Aufgaben auszulagern, die nicht mehr von der Garbage-Collection nach Objektalter übernommen werden, müssen die Ressourcen für den Haupt-Heapspeicher gewöhnlich im Vergleich mit den Einstellungen für den Durchsatzkollektor um 10-30 Prozent aufgestockt werden.
-XX:+UseParallelGC
Verwenden Sie diesen Parameter, um den Standard-Scavenger-Kollektor für Durchsatz/Parallelität zu aktivieren.
Im Standard-Garbage-Collection-Modus einer Server-JVM wird der Durchsatzkollektor eingesetzt, der die kürzeren Garbage-Collections für Young Generation (junge Objektgeneration) parallel als Vordergrundtask ausführt, bei der alle anderen Aktivitäten eingestellt werden. Dieser Kollektor kann explizit über den Parameter -XX:+UseParallelGC aktiviert werden. Es können andere Ziele als der Durchsatz angegeben werden. Die Nachteile, die sich aus einem Nichterreichen der definierten Ziele ergeben, können allerdings gravierend sein und zu einem schwerwiegenden Fehler aufgrund abnormaler Speicherbedingungen führen.