J9 problemi e limitazioni

Problemi noti o limitazioni che potrebbero verificarsi in specifici ambienti di sistema o configurazioni.

ThreadMXBean Limitazione del tempo CPU utente thread

Non è possibile distinguere tra il tempo CPU in modalità utente e il tempo CPU in modalità sistema su questa piattaforma. ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime()e ThreadMXBean.getCurrentThreadCpuTime() restituiscono il tempo CPU totale per il thread richiesto.

Su z/OS® , è possibile ottenere il tempo CPU solo per il thread corrente richiamando ThreadMXBean.isCurrentThreadCpuTimeSupported(). Il richiamo di ThreadMXBean.isThreadCpuTimeSupported() restituisce un valore false perché il richiamo del tempo CPU per un thread diverso dal thread corrente non è supportato.

Opzioni di runtime Language Environment ® che causano ABEND

Se l'opzione di runtime dell'ambiente di linguaggio TERMTHDACT è impostata su UAIMM, potrebbero essere riportati degli ABEND 0C7 imprevisti. Anche se vengono riportati gli ABEND, la JVM (Java™ virtual machine) continua ad essere eseguita correttamente. Tuttavia, se l'opzione di runtime di Language Environment ERRCOUNT è impostata su un valore maggiore di zero, la Java virtual machine potrebbe terminare quando viene raggiunto il valore specificato per ERRCOUNT. Per evitare questo problema, eseguire la Java virtual machine con l'opzione -Xrs:sync . Questa opzione sopprime l'utilizzo delle istruzioni compare - and - trap e load - and - trap da parte del compilatore JIT, consentendo alla JVM (Java virtual machine) di gestire i segnali sincroni. Quindi, ad esempio, è ancora possibile utilizzare il segnale SIGQUIT per raccogliere un dump javacore o il segnale SIGTERM per arrestare la JVM (Java virtual machine). Per ulteriori informazioni su questa opzione, consultare -Xrs nella documentazione utente di OpenJ9 .

Per sovrascrivere l'impostazione TERMTHDACT del sistema, è possibile passare un parametro Language Environment che esclude l'opzione UAIMM nel proprio lavoro batch. Ad esempio:
// LEPARM='TERMTHDACT(TRACE,CESE,00000096),ERRCOUNT(0)'
Nota: non impostare l'opzione TRAP (OFF) per impedire la notifica di interruzioni, poiché questa impostazione disabilita la gestione del segnale POSIX , da cui dipende la JVM (Java virtual machine). Se è richiesta l'opzione TRAP (OFF), ad esempio quando si combinano programmi Java con programmi z/OS nativi, eseguire la JVM (Java virtual machine) con l'opzione -Xrs , che elimina tutti gli utilizzi dei segnali da parte della JVM (Java virtual machine). Per ulteriori informazioni sull'opzione TRAP, consultare la documentazione relativa alla propria versione di z/OS, ad esempio: TRAP.
Limitazioni dello stack mobile
Se si è in esecuzione senza stack mobili, indipendentemente da quanto impostato per -Xss, viene fornita una dimensione minima dello stack nativo di 256 KB per ogni thread.
Utilizzo di -Xshareclasses:destroy durante l'avvio della JVM
Quando si esegue il comando java -Xshareclasses:destroy su una cache condivisa utilizzata da una seconda JVM durante l'avvio, potrebbero verificarsi i seguenti problemi:
  • La seconda JVM ha esito negativo.
  • La cache condivisa viene eliminata.

La richiesta di pagina di grandi dimensioni non riesce

Non viene emesso alcun messaggio di errore quando la JVM non è in grado di rispettare la richiesta -Xlp .

Esistono diversi motivi per cui la JVM non può rispettare una richiesta di pagine di grandi dimensioni. Ad esempio, potrebbero essere disponibili pagine di grandi dimensioni insufficienti sul sistema al momento della richiesta. Per controllare se la richiesta -Xlp è stata rispettata, è possibile esaminare l'output da -verbose:gc. Ricercare gli attributi requestedPageSize e pageSize nel file di log -verbose:gc . L'attributo requestedPageSize contiene il valore specificato da -Xlp. L'attributo pageSize è la dimensione effettiva della pagina utilizzata dalla JVM.

Il tempo CPU del thread ThreadMXBean potrebbe non essere monotonico sui sistemi SMP

Sui sistemi SMP, i tempi restituiti da ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime()e ThreadMXBean.getCurrentThreadCpuTime() potrebbero non aumentare in modo monotonico se il thread pertinente migra a un processore differente.