Perché il debug di Hot Swap di Java è limitato alle modifiche intra-metodo?

Question

Ho attraversato hot deployment tutorial e funziona. Ma ho delle domande sui limiti (punto 3) i.e

La distribuzione rapida ha supportato le modifiche al codice solo nell'implementazione del metodo. Se aggiungi una nuova classe o un nuovo metodo, è ancora necessario riavviare.

Fondamentalmente perché non è necessario il riavvio del server se apporto modifiche nel metodo esistente ma richiesto in caso di aggiunta di metodo o classe.

mia comprensione come funziona: - quando faccio i cambiamenti nel metodo esistente o introdotto un nuovo metodo, Eclipse inserire il file nella posizione della destra sotto webserver. Se la classe è già stata caricata dal classloader nello spazio perm gen, lo scaricherà dallo spazio permgen e caricherà il nuovo internamente senza il riavvio del server in modo che le nuove modifiche (codice byte) si riflettano. È corretto ?

Se sì, perché la distribuzione a caldo non funziona con nuovi metodi e nuovi file di classe?

Answer 1

Il ragionamento è piuttosto complicato e in realtà è noto solo a persone con conoscenza approfondita della JVM e come gestisce la memoria. C'è una spiegazione decente at this page (sebbene sia davvero una pubblicità per il prodotto JRebel) - scorri fino alla sezione intitolata Perché HotSwap è limitato ai corpi dei metodi?.

L'essenza: ci sono due fattori principali che impediscono a HotSwap di gestire le modifiche strutturali alle classi: JIT e allocazione di memoria.

Il compilatore JIT (Just In Time) nella JVM ottimizza il bytecode dopo che le classi sono state caricate ed eseguite alcune volte, in pratica inserendo molte chiamate per migliorare le prestazioni. Implementare tale funzionalità in modo sicuro ed efficace in un ambiente in cui la firma e la struttura della classe possono cambiare sarebbe una sfida significativa.

Altri problemi circondano ciò che accadrebbe riguardo alla gestione della memoria se le strutture di classe fossero autorizzate a cambiare. La JVM dovrebbe modificare istanze di classi esistenti, il che significherebbe trasferirle ad altre parti dell'heap storage. Per non parlare del dover spostare gli oggetti di classe stessi. La gestione della memoria della JVM è già incredibilmente complessa e altamente ottimizzata; tali cambiamenti non farebbero che aumentare la complessità e potenzialmente ridurre le prestazioni del compilatore JIT (e probabilmente porteranno a ulteriori bug).

Penso che sia lecito ritenere che gli ingegneri della JVM non siano stati disposti a prendere le prestazioni e gli svantaggi dell'impronta di bug che sarebbero necessari per supportare questa funzione. Ecco perché prodotti come JRebel e altri sono venuti per esistere.

Answer 2

Come nota a margine, la specifica stessa è not limited.

Succede solo che alcune delle implementazioni disponibili, incluso l'onnipresente Reference Implementation, sono limitate.

Dopo essersi connessi a una macchina virtuale remota, è possibile verificare se consente di add methods o redefine classes.

Answer 3

È possibile se si esegue il java su un vm smalltalk. Smalltalk lo ha fatto praticamente per sempre, ed è uno dei motivi per cui Smalltalker tende a fare lo sviluppo del debugger come forma superiore di sviluppo guidato dai test. Smalltalk vms esegue la pulizia necessaria delle strutture dei dati di memoria.In Eliot Miranda's Spur (per Squeak, Pharo e Cuis) e Gemstone che è fatto pigramente, ma altrimenti potrebbe essere necessario attendere che tutti gli oggetti vengano migrati. L'implementazione di riferimento java vm probabilmente ha più ottimizzazioni rispetto a qualsiasi smalltalk vm che potresti eseguire java su a.t.m.

Answer 4

La risposta fornita da E-Riz ha già una buona spiegazione dei motivi per cui la tecnologia Java HotSwap standard supporta solo le modifiche ai metodi esistenti e non l'aggiunta di nuove classi o metodi alle classi.

Tuttavia, come è stato descritto in un relativo SO discussion, il livello di hot swap ottenuto dipende dalla catena di strumenti utilizzata. Quindi, se si finisce per aggiungere il plug-in JRebel, si potranno eseguire hot swap anche quando sono stati aggiunti nuovi metodi e classi.

Esiste un altro progetto: Hot Swap Agent: si tratta in genere di un agente java che può essere utilizzato per eseguire il contenitore Java ed è possibile attivarlo utilizzando un paio di parametri della riga di comando (come indicato nello quickstart).