Ci sono dei garbage collector che tengono conto del paging?


12

Le raccolte di rifiuti devono visitare tutti gli oggetti che sono vivi, in modo da trovare la memoria che può essere recuperata. (Avere molte generazioni lo ritarda un po ')

A parità di condizioni, è chiaramente meglio prima visitare l'oggetto che è già impaginato nella RAM, prima di impaginare altri blocchi e quindi impaginare alcuni oggetti.

Un'altra possibilità è che quando il sistema operativo desidera estrarre una pagina di ram dal processo, al GC viene prima chiesto se ha una pagina che può essere abbandonata senza bisogno di essere cercata. Il GC può essere fatto principalmente con lo spostamento di oggetti da una pagina, quindi può cancellare quella pagina entro il limite di tempo che il sistema operativo ha per aver bisogno di una pagina.

Tuttavia, non riesco a ricordare nessun garbage collector che si integra con il sistema di paging del sistema operativo che guida l'ordine in cui funziona il GC.


Non esattamente il paging, ma la ruby enterprise edition gc è stata riscritta per ridurre l'effetto del gc sulla copia sulle pagine di scrittura spostando i metadati degli oggetti su pagine separate.
user1937198


sorprendentemente, afaik / afaict, quasi tutta la letteratura (?) gc non sembra analizzare il paging del sistema operativo se non in modo astratto. idea: un sistema di allocazione della memoria che tenga traccia dei puntatori tra gli oggetti in una struttura separata dagli oggetti stessi potrebbe essere più adatto a localizzazione / paginazione perché solo i puntatori stessi vengono attraversati (durante gc) in uno spazio strettamente compattato invece di tutti gli oggetti di dimensioni variabili che possono essere sparse in memoria (e alcune raramente accessibili e così paginate). potrebbe esserci un modesto sovraccarico ma potrebbe comportare risparmi complessivi a seconda dell'implementazione.
vzn,

Le unità flash devono utilizzare una forma di copia della garbage collection che tenga conto della disposizione della memoria in blocchi, anche se non so quanto bene siano discussi nella letteratura accademica. I problemi da risolvere sono molto diversi (le unità flash richiedono GC perché lo spazio può essere riciclato solo in blocchi molto grandi, quindi se un blocco ha poche pagine live e molte pagine morte, i dati live devono essere copiati altrove prima della pagina può essere riciclato) ma i principi del consolidamento dei dati potrebbero essere utili.
supercat,

1
Un modello che ho usato nei casi in cui gli elementi di dati fossero tutti relativamente piccoli rispetto alla mia dimensione del blocco di memoria consisteva nel fatto che ogni elemento di dati consistesse in un'intestazione di dimensioni fisse che era allocata fronte-retro e dati di dimensioni variabili che avrebbero essere allocato frontalmente. Una tabella manteneva gli indirizzi dei blocchi logici mappati sugli indirizzi fisici e sulla quantità di spazio libero in ciascun blocco; dopo ogni scansione identificava anche lo spazio morto. I riferimenti sono stati memorizzati in flash e ogni riferimento aveva il formato "Articolo # 3 del blocco logico # 7". Un ciclo GC
copierebbe

Risposte:


8

Per quanto ricordo, i collettori di copie dovrebbero essere di facile consultazione, poiché la traccia copiando tende a migliorare la localizzazione dei riferimenti dei puntatori. Ciò ha un effetto positivo sul programma (mutatore) che causerà meno errori di pagina quando segue i collegamenti e migliorerà anche il ciclo di raccolta successivo poiché la traccia causerà anche meno errori di pagina. L'agenda di tracciamento (quali puntatori dovrebbero essere elaborati per primi) può avere un impatto sull'efficacia per migliorare la localizzazione dei dati. Ciò può essere migliorato misurando le statistiche sul numero di accesso a diversi puntatori in diversi tipi di celle.

Ora, se consideri un raccoglitore di tracce in generale, di solito devi mantenere una struttura che tenga traccia dei puntatori che non sono ancora stati tracciati. Potrebbe essere possibile organizzare questa struttura in modo che tutti i puntatori in attesa che puntano nella stessa pagina vengano mantenuti insieme (sebbene ciò possa richiedere più spazio, in alcuni casi, a seconda delle tecniche disponibili per mantenere l'elenco di tali puntatori). Una possibile politica è quindi di rintracciare sempre prima il più grande insieme di puntatori in attesa che puntano alla stessa pagina, quando non è rimasto alcun puntatore in attesa sulle pagine in memoria.

Per quanto riguarda la domanda del terzo paragrafo, che è stata aggiunta dopo che ho risposto, la raccolta di copie è di nuovo una risposta. Il sistema operativo può ridurre il numero di pagine fisiche allocate al momento della raccolta, poiché le pagine sono completamente liberate. Con un mark and sweep collector, l'evento di una pagina intera che si libera è probabilmente molto più raro, quindi non merita un macanismo specifico da prendere in considerazione.

Questo tipo di idee è naturale ed è probabilmente descritto in alcuni articoli. Ma non me lo ricordo di mano. Penso che i primi articoli su Lisp GC contengano alcune di queste idee (come: auto o cdr dovrebbero essere seguite per prime?).

La buona notizia in questo ruolo della raccolta di copie è anche che il paging è facile da copiare, poiché aumenta lo spazio di archiviazione disponibile. Ricordiamo che, in linea di principio, il raccoglitore di copie richiede il doppio dello spazio utilizzato per l'archiviazione effettiva dei dati. Ora, l'effetto del paging dipende anche dallo spazio degli indirizzi della macchina e dalla memoria fisica disponibile. Nei computer più vecchi, la memoria fisica era molto inferiore allo spazio degli indirizzi disponibile, quindi il paging era davvero un bonus di spazio, consentendo politiche come copiare GC. Anche quando lo spazio fisico è grande quanto lo spazio degli indirizzi, si potrebbe desiderare di condividerlo, in modo che il processo che utilizza un GC abbia meno spazio di indirizzamento senza paginazione (vedere paging). Queste osservazioni sono in qualche modo sostituite dall'uso di collezionisti generazionali. Generalmente usano la raccolta di copie per le giovani generazioni proprio per queste qualità e perché le giovani generazioni hanno una vita breve.

Quindi hai tutte le interazioni del GC generazionale con il sistema di cache, che è stato discusso in una domanda precedente: i garbage collector generazionali sono intrinsecamente compatibili con la cache?

Per ulteriori informazioni su questo problema, vorrei cercare nel web con, ad esempio, le parole chiave garbage collection e località .


sono dubbioso che l'idea che i collezionisti di copie siano effettivamente più "locali" della traccia. i collettori di copie sembrano concettualmente abbastanza simili nelle dinamiche di accesso alla memoria (forse quasi indistinguibili) da tracciare sul "vecchio spazio". penso che questo abbia bisogno di un riferimento. detto ciò, esiste la possibilità che il meccanismo di copia migliori la contiguità nel nuovo spazio. il nuovo spazio inizia perfettamente contiguo, ma poi questa "località" diminuisce o si degrada nel tempo.
vzn,

Bene, hai trovato la maggior parte della risposta. Quindi non essere dubbioso. È nei riferimenti di base sull'argomento. Posizione dal fatto che l'archiviazione è compattata e dalla copia che si sostituiscono una accanto all'altra celle di dati che sono logicamente vicine in base alla struttura del puntatore (che può evolversi con la riassegnazione del puntatore).
babou,

Sono ancora scettico / dubbioso. sembra intuitivamente che il vecchio spazio avrà scarsa località e / o contiguità quando viene avviato il ciclo copia / gc. la località è legata alle letture (dal vecchio spazio) e alle scritture (al nuovo spazio). per analizzarlo, è necessario studiare il comportamento gestalt / emergente. forse gran parte di questo può essere efficacemente / accuratamente / realisticamente studiato empiricamente e non molto teoricamente.
vzn,

Sto dicendo che è in letteratura, come molte altre cose. Ma non ho tempo per cercarlo e penso che la mia risposta sia lunga e piena di informazioni., Puoi google: localizzazione copia garbage collection e c'è un riferimento a una domanda precedente. Scusami per essere conciso, ho un treno da prendere.
babou,

Scusa ... confondi questa domanda con un'altra ... che ha di più.
babou,

8

Emery Berger, Matthew Hertz e Yi Feng hanno lavorato a questo proposito.

La garbage collection offre numerosi vantaggi di ingegneria del software, ma interagisce male con i gestori di memoria virtuale. I Garbage Collector esistenti richiedono molte più pagine del set di lavoro dell'applicazione e toccano le pagine indipendentemente da quali sono in memoria, specialmente durante la garbage collection a tutto campo. Il paging risultante può far precipitare il throughput e aumentare i tempi di pausa fino a secondi o addirittura minuti.

Presento un garbage collector che evita il paging. Questo raccoglitore di segnalibri collabora con il gestore della memoria virtuale per guidare le sue decisioni di sfratto.

Questo è un video del discorso di Emery su di esso, e ha scritto un articolo Garbage Collection Without Paging

Per alcune ragioni non sembra esserci molto lavoro più tardi su di esso, o alcun utilizzo del "mondo reale". Alla fine dell'articolo dice "Stiamo sviluppando una variante simultanea dell'algoritmo di raccolta dei segnalibri" , ma non riesco a rintracciarlo.

CRAMM: il supporto della memoria virtuale per le applicazioni Garbage-Collected cerca di cambiare il sistema operativo per fare in modo che GC crei meno paging.

Utilizzo di Page Residency per bilanciare i compromessi nella tracciabilità dei rifiuti

Introduciamo un'estensione della raccolta prevalentemente di copie che utilizza la residenza della pagina per determinare quando spostare gli oggetti. Il nostro collezionista promuove pagine con elevata residenza in atto, evitando lavori inutili e spazio sprecato. Prevede la residenza di ogni pagina, ma quando le sue previsioni si rivelano inaccurate, il nostro collezionista recupera lo spazio non occupato utilizzandolo per soddisfare le richieste di allocazione. L'uso della residenza consente al nostro collezionista di bilanciare dinamicamente i compromessi della raccolta di copie e non di copia. La nostra tecnica richiede meno spazio di un semplice raccoglitore di copie e supporta il blocco degli oggetti senza sacrificare altrimenti la capacità di riposizionare gli oggetti. A differenza di altri ibridi, il nostro raccoglitore non dipende dalla configurazione specifica dell'applicazione e può rispondere rapidamente al cambiamento del comportamento dell'applicazione. Le nostre misurazioni mostrano che il nostro ibrido funziona bene in una varietà di condizioni; preferisce la raccolta di copie quando c'è un ampio spazio heap ma ricade sulla raccolta non di copia quando lo spazio diventa limitato.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.