2010-08-26 19 views
5

Ho la sensazione che sto per fare una domanda "stupido", ma devo chiedere ...oggetti di copia tra le diverse virtuali-Macchine efficiente

Ho 2 macchine virtuali.

desidero copiare un'istanza di un oggetto da uno all'altro,

E 'possibile copiare i bit che rappresentano l'oggetto in mucchio del VM, inviarla all'altro VM, così l'altra VM ha solo bisogno di allocare i bit nella sua memoria e aggiungere un riferimento nel suo stack a questo slot di memoria ...?

Attualmente, per fare una cosa del genere, serializziamo l'oggetto e lo serializziamo, che è molto meno efficiente (computazionale saggio) che copiare semplicemente l'istanza così com'è ... l'analisi è uno spreco computazionale ...

Esempio di serializzazione JS: ogni VM è un'istanza di V8 (JavaScript), un modo per farlo è convertire l'oggetto in JSON (JSON.stringify), inviarlo in qualche modo all'altra VM che ottiene la stringa e la converte back to object (es. var myObject = eval('(' + myJSONtext + ')');) .. (JavaScript è solo un esempio qui, questa è una sorta di serializzazione)

+0

Che cosa ha a che fare questo con Java o Python? – katrielalex

+2

Java e Python eseguiti anche all'interno di una VM ... – DuduAlul

+0

L'applicazione verrà eseguita all'interno della VM o al di fuori di essa? Se all'interno di una VM, quindi non penso che questo sia possibile, poiché sarà completamente in modalità sandbox. –

risposta

7

Lasciare ignorare per un in secondo luogo, l'assunzione ingenua di poter generalizzare facilmente questa domanda su più macchine virtuali. Qualsiasi tentativo di costruire un meccanismo come questo sarebbe fortemente dipendente dai dettagli di implementazione della VM per cui stavi creando il meccanismo.

Qui sono molte ragioni per cui questo non avviene:

rappresentazione
  1. In-core non è generalmente architetture portabile. Se dovessi inviare un "oggetto" da una VM su una macchina SPARC a una VM su una macchina x86 senza conoscenza della sua struttura, l'oggetto apparirebbe corrotto dall'altra parte.

  2. L'oggetto non esisterà necessariamente nella stessa posizione di memoria su entrambe le macchine, quindi i puntatori interni all'interno dell'oggetto dovranno essere rattoppati dopo aver raggiunto la seconda VM. Anche questo richiede una conoscenza interna della struttura dell'oggetto.

  3. L'oggetto probabilmente contiene riferimenti ad altri oggetti, quindi copiare un oggetto significa copiare un albero di oggetti e in genere non un albero aciclico. Finisci per costruire codice che sembra molto simile a una libreria di serializzazione per poterlo fare in modo affidabile.

  4. oggetti spesso tenere su di risorse autoctone (come handle di file e prese) che non possono essere trasmessi in modo affidabile tra macchine.

  5. In molte macchine virtuali, si distingue tra i dati (l'oggetto che si sta tentando di copiare) e i metadati (ad esempio, la classe dell'oggetto che si sta tentando di copiare). In questi tipi di VM, anche se si potesse copiare l'oggetto bit-for-bit indenne, ciò potrebbe dipendere da una serie di metadati che non esistono sul lato remoto. Anche copiare i metadati bit per bit è complicato, dal momento che molte macchine virtuali utilizzano tecniche di implementazione (come un pool globale di stringhe internate o codice oggetto mappato in memoria) che rendono i dati intrinsecamente non portabili. Inoltre potresti finire con molti più metadati di quello che vuoi (ad esempio in .net la più piccola unità di metadati che puoi impacchettare e inviare da qualche parte è tipicamente un assembly).

  6. La rappresentazione in-core non è generalmente portabile tra le diverse versioni della stessa VM e non contiene informazioni sulla versione interna che potrebbero essere utilizzate per correggere i dati.

  7. La rappresentazione in-core contiene molte cose (ad esempio cache in linea, informazioni sulla raccolta di dati inutili) che non è necessario copiare. Copiare questa roba sarebbe uno spreco e l'informazione potrebbe non essere nemmeno ragionevole dall'altra parte.

In sostanza, per fare questo in modo affidabile, si finisce per costruire biblioteca serializzazione più scomodo e inaffidabile del mondo, e l'incremento delle prestazioni della semplice copia della memoria sono persi nel rattoppare le tante cose che si rompono quando si fa la copia ingenuamente

Quindi, questi meccanismi tendono a non esistere.

C'è un'enorme eccezione a questa regola: le macchine virtuali basate su immagini (come molte smalltalk e self VM) sono costruite attorno all'idea che lo stato della macchina virtuale esista in una "immagine" che può essere copiata, spostata tra le macchine , ecc. Questo generalmente ha un costo di prestazione notevole.

0

Sono certo che non è possibile eseguire questo tipo di trasferimento diretto di memoria nelle API VMware; Non conosco altri hypervisor, ma ne dubito ancora. VMware ha modi per spedire la memoria di un'intera macchina a un altro server host (principalmente utilizzando un file di paging), ma nulla che possa estrarre solo un pezzo di memoria da un programma in esecuzione e darlo a un altro - c'è solo troppo coinvolgimento Là.

Quindi la tua tattica di serializzazione degli oggetti è sicuramente una soluzione buona e comune per questa esigenza e fortunatamente i linguaggi di programmazione con cui stai lavorando hanno buone opzioni (Python, Java).

Ma mi chiedo se è davvero necessario avere l'intero oggetto nascosto e ricreato, o sono solo alcuni dei dati inclusi. Se i dati non sono eccessivi, è possibile utilizzare un qualche tipo di remote method invocation per inviare un messaggio dalla VM di origine al destinatario indicando di creare un oggetto con questi dati. In questo caso, si serializzerebbero solo i dati necessari e si consentirebbe alla macchina target di ricostruire l'oggetto nella propria memoria.

+0

Sono sicuro che quando usa il termine "VM" parla di macchine virtuali come Hotspot e V8, non di macchine virtuali come VMWare e Xen. – blucz

+0

@blucz ha ragione. – DuduAlul

2

Perché non utilizzare cpickle. Serializzando i dati in modo molto affidabile e molto rapidamente, è possibile inviarli su un socket, named pipe, mmap, lo si chiama, eccetto sull'altro lato, è possibile aspettarsi di riassemblarlo in modo affidabile purché non venga danneggiato durante il trasferimento e le versioni del modulo pickle non sono molto diverse. Ovviamente il modo più efficace è utilizzare uno standard agnostico della piattaforma come XML che ti consentirà di espandere l'interoperabilità della piattaforma oltre Python. So che questo allontana la domanda, ma penso che qualcuno che ha contribuito alla base di codice dell'interprete Python dovrebbe chiarirlo per te.

Problemi correlati