Quote:
Originariamente inviato da cdimauro
Quest'ultimo lo vedo più difficile da fare, perché si dovrebbe introdurre a questo livello la conoscenza del sistema emulato (non solo il processore) per capire in che modo salvare le informazioni e caricarle: decisamente troppo dispendioso da realizzare...
|
Uhm, si, effettivamente servirebbe un layer software aggiuntivo, magari uno straccio di os nativo in una partizione apposita. Però questo strato in più potrebbe consentire l'emulazione contemporanea di più sistemi, con un meccanismo del tipo VM e time slacing eventuale tra le istanze di ciascun os (magari in un "serverino" multiprocessore, multiutente e multi-os
forse però sogno o deliro
), anche se potrebbe richiedere davvero molte risorse, implicare molti (continui) swap su disco e risultare lento...
Quote:
|
A parte i problemi di cui sopra, potrebbero ridursi, ma bisogna vedere anche quanto: con l'accesso al disco i tempi di caricamento aumentano molto, e paradossalmente sarebbe preferibile tradurre al volo il codice ed effettuare qualche passo di profiling, perché in questi casi tutto avviene utilizzando la ram.
|
Non ho capito bene cosa intendi in questo punto. Ti riferisci alla scrittura su disco del file decompresso per poi allocarlo? Io pensavo di lasciarlo subito in memoria, eventualmente riorganizzando le "parti" (deframmentando) per evitare che, per motivi contingenti, istruzioni e dati contigui (tipo le celle di un array) si ritrovino spezzati. I file jar non funzionano in modo simile? Oppure vengono decompressi in una cartella temporanea prima dell'esecuzione? Mi pare che la decompressione non incida molto sulla compilazione jit per gli archivi java, e nel meccanismo che pensavo il tempo dedicato alla compilazione verrebbe meno; però non conosco i dettagli, quindi potrei sbagliarmi...
A parte questo il resto mi è chiaro
