Utilizzo di -noverify all'avvio di app java

Question

Ho visto molte app che prendono le classi di strumenti e prendono -javaagent come parametro durante il caricamento, inoltre ho messo un -noverify sulla riga di comando.

Il documento Java afferma che -noverify disattiva la verifica della classe.

Tuttavia, perché qualcuno dovrebbe voler disattivare la verifica anche se sta studiando classi?

Answer 1

Tempo di avvio, direi. La verifica che le classi siano corrette richiede del tempo quando la classe viene caricata. Poiché le classi potrebbero essere caricate in modo pigro (non all'avvio dell'app, ma quando vengono utilizzate per la prima volta), ciò potrebbe causare ritardi di runtime imprevisti e indesiderati.

In realtà non è necessario controllare la classe in generale. Il compilatore non emetterà alcun bytecode o costrutto di classe non valido. Il motivo della verifica è che la classe può essere costruita su un sistema, essere ospitata online e trasmessa all'utente tramite Internet non protetto. In questo percorso, un utente malintenzionato potrebbe modificare il bytecode e creare qualcosa che il compilatore non potrebbe mai creare; qualcosa che può mandare in crash JVM o aggirare le restrizioni di sicurezza. Pertanto la classe viene verificata prima di essere utilizzata. Se si tratta di un'applicazione locale, di solito non è necessario controllare nuovamente il bytecode.

Answer 2

Quando viene utilizzato insieme a -javaagent , molto probabilmente non per motivi di prestazioni, ma perché l'agente crea intenzionalmente " non valido " bytecode.

Va ??notato che il bytecode non valido potrebbe ancora essere eseguito correttamente, poiché alcune delle regole di verifica sono piuttosto rigide. Ad esempio, this non è possibile accedere a un costruttore prima che il super-costruttore sia stato chiamato, poiché le variabili non sono inizializzate a questo punto. Ma potrebbero esserci ancora altre cose che vuoi fare (vedi l'esempio JRebel). Quindi, usi -noverify per aggirare quella regola.

Answer 3

Debug! In realtà è quello che sto facendo ora e come mi sono imbattuto in questa domanda. In Terracotta facciamo molta strumentazione bytecode e talvolta aiuta a disattivare il verificatore mentre eseguiamo il debug dei nostri adattatori di classe, così possiamo vedere dove falliscono esattamente in fase di esecuzione.

Hai ragione, vogliamo che il verificatore rimanga attivo in produzione.

Answer 4

L'uso di JRebel senza -noverify darà questo avviso all'avvio:

  

JRebel: '-noverify' mancante, la modifica / aggiunta / rimozione di costruttori non sarà abilitata!

Quindi sembra che -noverify consente alla ri-strumentazione bytecode di fare alcune cose che altrimenti non sarebbero possibili.

Answer 5

Il tempo di avvio era un po 'un problema. Tuttavia, i verificatori ora sono più veloci, così come i processori. Il codice compilato con JDK6 javac includerà di default informazioni aggiuntive per rendere il passo del verificatore più veloce. Apache Harmony utilizza solo un algoritmo di verifica molto più veloce.

Alcune versioni molto vecchie di javac hanno prodotto un bytecode errato. In effetti Sun PlugIn include ancora codice di correzione per verificare alcuni file di classe non funzionanti.

Answer 6

Il nuovo verificatore introdotto in JAVA 6 è molto complicato da elaborare per manipolazioni del codice.

Dai un'occhiata a questo: http: // chrononsystems .com / blog / java-7-design-difetto-porta-a-enorme-backward-passo-per-il-jvm

e la relativa segnalazione di bug: http://bugs.sun.com/view_bug.do?bug_id=8009595