Probleme und Einschränkungen für J9

Bekannte Probleme und Einschränkungen, die in bestimmten Systemumgebungen oder Konfigurationen auftreten können.

Systemspeicherauszüge können unter SLES 12 nicht gefunden werden (nurLinux )

Unter SLES 12 und höher werden Systemspeicherauszugsdateien auf Anforderung der JVM nicht mehr im Ausgangsverzeichnis des Benutzers erstellt. Stattdessen werden Dateien mit der Erweiterung .xz im Verzeichnis /var/lib/systemd/coredump/ erstellt. Dieses Verhalten wird erwartet, da SLES 12 den Dämon systemd als Ersatz für den Dämon System V init einführt, der von der Eclipse OpenJ9 JVM nicht unterstützt wird.

Diese Kernspeicherauszüge können weiterhin mit der Anzeigefunktion für Speicherauszüge gelesen werden. Führen Sie dazu die folgenden Schritte aus:

Extrahieren Sie den Kernspeicherauszug, indem Sie tar -xf *.xzausführen, wodurch eine nicht komprimierte Kernspeicherauszugsdatei ohne Dateierweiterung erstellt wird.
Geben Sie Folgendes in der Befehlszeile an, um den Speicherauszug mit der Anzeigefunktion für Speicherauszüge zu öffnen:
```
jdmpview -core <filename>
```
Dabei ist <filename> die extrahierte Kernspeicherauszugsdatei.

Wenn Sie den Speicherauszug, die ausführbaren Dateien und die Bibliotheken in einer einzigen .zip -Datei komprimieren möchten, können Sie das Dienstprogramm jextract verwenden und diese ZIP-Datei mit dem folgenden Befehl an die Anzeigefunktion für Speicherauszüge übergeben:

jdmpview -zip <filename.zip>

Weitere Informationen zur Anzeigefunktion für Speicherauszüge (jdmpview) finden Sie unter Anzeigefunktion für Speicherauszüge in der Benutzerdokumentation zu OpenJ9 .

Änderung der Standardseitengröße erhöht Speicherbelegung (nur AIX)

Der Heapspeicher wird standardmäßig mit 64-KB-Seiten anstelle von 4-KB-Seiten zugeordnet. Diese Änderung bewirkt eine Verbesserung des Anwendungsdurchsatzes und der Systemstartleistung. Die Änderung verursacht jedoch auch einen leichten Anstieg der Speicherbelegung durch die Anwendung. Wenn die Speicherbelegung ein kritischer Aspekt für die Anwendung ist, führen Sie die folgenden beiden Schritte aus, um zu 4-KB-Seiten zurückzukehren:

Legen Sie die Umgebungsvariable wie folgt fest: LDR_CNTRL=TEXTPSIZE=4K@DATAPSIZE=4K@STACKPSIZE=4K. Weitere Informationen zu dieser Umgebungsvariablen finden Sie unter System konfigurieren in der Benutzerdokumentation zu OpenJ9 .
Verwenden Sie die Option -Xlp4K. Weitere Informationen zur Option -Xlp finden Sie unter -Xlp in der Benutzerdokumentation zu OpenJ9 .

Die Änderung hat keine Auswirkung, wenn Sie bereits die Option -Xlp verwenden, um dem Heapspeicher große Seiten zuzuordnen.

Begrenzung der Benutzer-CPU-Zeit für den Thread 'ThreadMXBean' (nur Linux und z/OS)

Es gibt keine Möglichkeit, zwischen CPU-Zeit im Benutzermodus und CPU-Zeit im Systemmodus auf dieser Plattform zu unterscheiden. ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime()und ThreadMXBean.getCurrentThreadCpuTime() geben die gesamte CPU-Zeit für den erforderlichen Thread zurück.

Unter z/OS® können Sie die CPU-Zeit nur für den aktuellen Thread abrufen, indem Sie ThreadMXBean.isCurrentThreadCpuTimeSupported()aufrufen. Wenn Sie die Methode ThreadMXBean.isThreadCpuTimeSupported() aufrufen, wird der Wert 'false' (Falsch) zurückgegeben, weil das Abrufen der CPU-Zeit für einen anderen als den aktuellen Thread nicht unterstützt wird.

Signal SIGSEGV beim Erstellen einer JVM mithilfe des JNI (Java Native Interface, nur Linux)

Der Aufruf von JNI_CreateJavaVM() über eine JNI-Anwendung kann zu einem Segmentierungsfehler führen (Signal SIGSEGV). Zum Vermeiden dieses Fehlers müssen Sie das JNI-Programm unter Angabe der Option –lpthread erneut erstellen.

Ressourcenmangel bei Anwendungen mit vielen Threads (nur Linux)

Wenn Sie viele gleichzeitig ablaufende Threads ausführen, wird möglicherweise eine Warnung angezeigt:

java.lang.OutOfMemoryError

Die Nachricht bedeutet, dass nicht genügend Systemressourcen zur Verfügung stehen, und kann aus folgenden Gründen angezeigt werden:

Wenn Ihre Linux® -Installation LinuxThreadsanstelle von NPTL verwendet, überschreitet die Anzahl der erstellten Prozesse Ihren Benutzergrenzwert.
Es stehen nicht genügend Systemressourcen zum Erstellen neuer Threads zur Verfügung. In diesem Fall werden möglicherweise weitere Ausnahmebedingungen angezeigt, abhängig davon, welche Operationen Ihre Anwendung ausführt.
Der Kernelspeicher bietet entweder nicht genügend Kapazität oder ist fragmentiert. Im Verzeichnis /var/log/messages finden Sie entsprechende Kernel-Nachrichten, die darauf hinweisen, dass nicht genügend Speicher vorhanden ist. Den Nachrichten ist die ID des abgebrochenen Prozesses zugeordnet.

Versuchen Sie, Ihr System dahingehend zu optimieren, dass die entsprechenden Systemressourcen erhöht werden.

AESNI-Unterstützung auf x86-Plattformen (nur Linux und Windows)

Die Softwarenutzung von AESNI-Anweisungen in x86-Architekturen wird für die Richtlinien für ausgeglichene GC oder Metronom-GC zurzeit nicht unterstützt.

Language Environment ® -Laufzeitoptionen, die ABENDs verursachen (nurz/OS )

Wenn die Language Environment-Laufzeitoption TERMTHDACT auf UAIMM gesetzt ist, werden möglicherweise unerwartete 0C7 -ABENDs gemeldet. Obwohl die ABENDs gemeldet werden, wird die Java™ Virtual Machine weiterhin erfolgreich ausgeführt. Wenn die Laufzeitoption ERRCOUNT für Language Environment jedoch auf einen Wert größer als null gesetzt ist, wird die Java Virtual Machine möglicherweise beendet, wenn der für ERRCOUNT angegebene Wert erreicht wird. Dieses Verhalten tritt in 31-Bit- und 64-Bit-Umgebungen auf. Zur Vermeidung dieses Problems führen Sie die Java Virtual Machine mit der Option -Xrs:sync aus. Diese Option unterdrückt die Verwendung von Anweisungen zum Vergleichen und Abfangen sowie zum Laden und Abfangen durch den JIT-Compiler, während die Java Virtual Machine synchrone Signale verarbeiten kann. Sie können beispielsweise das Signal SIGQUIT verwenden, um einen Java-Core-Dump zu erfassen, oder das Signal SIGTERM, um die Java Virtual Machine herunterzufahren. Weitere Informationen zu dieser Option finden Sie unter -Xrs in der Benutzerdokumentation zu OpenJ9 .

Um die systemweite Einstellung TERMTHDACT zu überschreiben, können Sie einen Language Environment-Parameter übergeben, der die Option UAIMM in Ihrem Batch-Job ausschließt. Beispiel:

// LEPARM='TERMTHDACT(TRACE,CESE,00000096),ERRCOUNT(0)'

Anmerkung: Setzen Sie nicht die Option TRAP (OFF), um die Benachrichtigung über abnormale Beendigungen zu verhindern, da diese Einstellung die POSIX -Signalverarbeitung inaktiviert, von der die Java Virtual Machine abhängt. Wenn die Option TRAP (OFF) erforderlich ist, beispielsweise wenn Sie Java-Programme mit nativen z/OS -Programmen mischen, führen Sie die Java Virtual Machine mit der Option -Xrs aus, die alle Verwendungen von Signalen durch die Java Virtual Machine unterdrückt. Weitere Informationen zur TRAP-Option finden Sie in der Dokumentation zu Ihrer Version von z/OS. Beispiel: TRAP.

Threads als Prozesse (nur Linux)

Auf Linux -Systemen implementiert die VM Java-Threads als native Threads. Auf NPTL-fähigen Systemen wie RHEL und SLES werden diese als Threads implementiert. Die Verwendung der Bibliothek LinuxThreads führt jedoch dazu, dass jeder Thread ein separater Linux -Prozess ist.

Wenn die Anzahl der Java-Threads die maximal zulässige Anzahl von Prozessen überschreitet, kann Ihr Programm Folgendes ausführen:

Es erhält eine Fehlernachricht.
Es erhält einen SIGSEGV-Fehler.
Stoppen

Die native Stackgröße ist die Haupteinschränkung bei der Ausführung vieler Threads. Verwenden Sie die Option -Xss, um die Größe des Thread-Stacks zu reduzieren, sodass die JVM die erforderliche Anzahl Threads verarbeiten kann. Setzen Sie die Stackgröße beim Start beispielsweise auf 32 KB.

Einschränkungen für variabel verknüpfte Stacks

Bei einer Ausführung ohne variabel verknüpfte Stacks wird unabhängig von der Einstellung für -Xss eine Minimalgröße von 256 KB für native Stacks für die einzelnen Threads bereitgestellt.

Auf einem Linux -Floating-Stack-System werden die -Xss -Werte verwendet. Wenn Sie von einem Linux -System ohne Floating-Stack migrieren, stellen Sie sicher, dass alle -Xss -Werte groß genug sind und nicht auf mindestens 256 KB angewiesen sind.

glibc-Einschränkungen

Wenn Sie eine Nachricht erhalten, die angibt, dass die Bibliothek libjava.so nicht geladen werden konnte, da ein Symbol nicht gefunden wurde (z. B. __bzero), ist möglicherweise eine frühere Version der GNU C-Laufzeitbibliothek, glibc, installiert. Die Implementierung des SDK für Linux -Threads erfordert glibc Version 2.3.2 oder höher.

Befehl '-Xshareclasses:destroy' beim JVM-Systemstart verwenden

Beim Ausführen des Befehls java -Xshareclasses:destroy für einen gemeinsam genutzten Cache, der von einer zweiten JVM während des Starts verwendet wird, können die folgenden Probleme auftreten:

Die zweite JVM schlägt fehl.
Der gemeinsam genutzte Cache wird gelöscht.

Anforderung großer Seiten schlägt fehl

Es werden keine Fehlernachrichten ausgegeben, wenn die JVM die Anforderung -Xlp nicht verarbeiten kann.

Es gibt eine Reihe von Gründen, warum die JVM eine Anforderung großer Seiten nicht verarbeiten kann. Möglicherweise sind zur Zeit der Anforderung auf dem System nicht genügend große Seiten verfügbar. Sie können anhand der Ausgabe von -verbose:gc prüfen, ob die Anforderung -Xlp verarbeitet wurde. Suchen Sie in der Protokolldatei -verbose:gc nach den Attributen requestedPageSize und pageSize . Das Attribut requestedPageSize enthält den durch -Xlp angegebenen Wert. Das Attribut pageSize gibt die tatsächliche Seitengröße an, die von der JVM verwendet wird.

ThreadMXBean-Thread-CPU-Zeit ist auf SMP-Systemen möglicherweise nicht monoton

Auf SMP-Systemen wachsen die durch ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime() und ThreadMXBean.getCurrentThreadCpuTime() zurückgegebenen Zeiten möglicherweise nicht monoton, wenn der relevante Thread auf einen anderen Prozessor migriert wird.