Perché -Xrs ridurre le prestazioni

Question

Da IBM:

-Xrs

Disabilita segnale movimentazione nella JVM.

-Xrs

Impostazione -Xrs impedisce l'™ ambiente runtime Java dalla gestione degli segnali generati internamente o esternamente, come SIGSEGV e SIGABRT. Qualsiasi segnale generato viene gestito dai gestori del sistema operativo predefinito. La disabilitazione della gestione dei segnali nella JVM riduce le prestazioni di circa il 2-4%, a seconda dell'applicazione.

-Xrs: sincronizzazione

Nei sistemi UNIX, questa opzione disabilita la gestione dei segnali nella JVM per SIGSEGV, SIGFPE, SIGBUS, SIGILL, SIGTRAP, segnali andSIGABRT. Tuttavia, la JVM gestisce ancora i segnali SIGQUIT e SIGTERM, tra gli altri. Come con -Xrs, l'uso di -Xrs: sync riduce le prestazioni di circa il 2-4%, a seconda dell'applicazione.

Nota: impostazione di questa opzione impedisce dump generati da JVM segnali, come SIGSEGV e SIGABRT, perché la JVM non è più intercettare questi segnali.

https://www-01.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.aix.70.doc/diag/appendixes/cmdline/Xrs.html

Dalla mia comprensione, -Xrs è davvero usato per prevenire discariche vengano generati quando alcuni segnali del sistema operativo vengono intercettati.

Poiché la JVM non è più intercettando e trattare questi segnali, sarebbe stare alla ragione questo sarebbe aumento prestazioni, non diminuzione come rivendicato da IBM.

Perché -Xrs riduce le prestazioni?

Answer 1

A causa delle operazioni safepoints e VM, nonché altre ottimizzazioni che il JIT può eseguire se gli si consente di gestire i segnali.

La JVM occasionalmente deve eseguire alcune operazioni che richiedono di sospendere l'esecuzione globalmente ("fermare il mondo"), come ad esempio alcuni garbage collection su larga scala, ricariche hot o classi di ricompilazione interna e simili. Per fare ciò, è necessario assicurarsi che tutti i thread in esecuzione colpiscano una barriera e si fermino contemporaneamente, eseguono l'operazione e quindi rilasciano i thread.

Una tecnica che HotSpot (e probabilmente altre JVM) utilizza per implementare i punti di sicurezza è un abile abuso di segfaults: imposta una pagina di memoria che non viene effettivamente utilizzata per alcun dato, quindi ogni thread prova periodicamente a leggerlo pagina. Quando non è richiesta alcuna operazione VM, la lettura riesce con un sovraccarico molto basso e il thread continua a funzionare.

Quando la JVM fa deve eseguire un'operazione VM, invalida quella pagina di memoria.The next time each thread hits a safepoint, it now causes a segfault, che consente alla JVM di riprendere il controllo dell'esecuzione di quel thread; mantiene fino al completamento dell'operazione VM, reimposta la pagina sentinella e riavvia tutti i thread.

Quando si disabilita la gestione SIGSEGV, la JVM deve utilizzare altre tecniche per sincronizzare i punti di sicurezza meno efficienti della delega alla protezione della memoria integrata del processore.

Inoltre, la JVM fa un po 'di magia seria con il profiling (essenzialmente simile al predittore di una CPU). Una delle ottimizzazioni che utilizza è che se rileva che un certo controllo nullo non è quasi mai nullo, elude il controllo e fa affidamento su un segfault (costoso, ma in tal caso raro) per catturare il valore nullo. Questa ottimizzazione richiede anche la gestione personalizzata di SIGSEGV.

Answer 2

Oltre ai punti di sicurezza menzionati da @chrylis, i gestori segfault vengono utilizzati anche per altri intelligenti trucchi di ottimizzazione come il controllo del puntatore nullo implicito (almeno sono su hotspot). Se i profili mostrano che un percorso di codice di verifica nulla viene attivato raramente, viene ottimizzato e il caso improbabile viene quindi coperto dal gestore di segnali.

Tale ottimizzazione non può essere eseguita senza l'installazione di un gestore di segnale personalizzato.