Quali sono gli algoritmi dietro GC a bassa pausa?

Alcune lingue, ad esempio java, hanno introdotto una GC a bassa pausa.

Quei GC possono fare la maggior parte del lavoro senza mettere in pausa il mondo intero. Questo è ovviamente un problema piuttosto difficile perché richiede di analizzare la memoria quando il thread lo sta modificando, risultando in dati che possono essere utilizzati all'inizio del processo e non più al termine, oppure dati che sembrano essere garbages ma perché il il riferimento è stato spostato nella memoria e non è mai apparso nel punto in cui si trovava il GC.

Quindi, in sostanza, qual è l'algoritmo (i) dietro?

I documenti di ricerca o il link dell'articolo veramente tecnico sarebbero considerati una risposta valida, poiché questo argomento è veramente tecnico.

Quindi, in sostanza, qual è l'algoritmo (i) dietro?

È fondamentalmente un algoritmo mark and sweep che "solo" viene eseguito contemporaneamente in un thread separato.

Per quanto riguarda i documenti di ricerca sull'argomento:

• Raccolta di immondizia Mark and Sweep molto simultanea senza sincronizzazione a grana fine

• Collezionista di garbabe mark-sweep simultaneo (contiene collegamenti a due documenti, uno elencato di seguito)

• Implementazione di un Garbage Collector al volo per Java

• Garbage Collection portatile e discreta per sistemi multiprocessore (Doligez Leroy, presentazione Powerpoint)

• Raccolta dei rifiuti al volo: An Exercise in Cooperation (di Edsger Wybe Djikstra)

per quanto ho capito, il Garbage Collector di Java G1 utilizza le cosiddette aree heap per evitare di mettere in pausa il mondo intero. A mio modo di vedere, mentre una delle regioni è bloccata dal GC durante la pulizia, l'allocazione della memoria viene eseguita in un'altra regione.

Ecco una spiegazione di Jeremy Manson :

Il principio è semplice: il raccoglitore suddivide l'heap in regioni di dimensioni fisse e tiene traccia dei dati attivi in ​​tali aree. Mantiene un set di puntatori - il "set ricordato" - dentro e fuori dalla regione. Quando un GC è ritenuto necessario, raccoglie prima le regioni con meno dati attivi (quindi, "prima immondizia"). Spesso, ciò può significare raccogliere un'intera regione in un solo passaggio: se il numero di puntatori in una regione è zero, non è necessario contrassegnare o spazzare quella regione ...

• ecco un documento tecnico degli ingegneri Sun che spiega il loro design: Garbage-First Garbage Collection

La JVM in tempo reale di IBM utilizza un Garbage Collector chiamato Metronome che suddivide l'attività GC in quanti discreti e li intercala con l'elaborazione delle applicazioni. Quindi, in pratica, invece di pause GC periodiche (e non deterministiche) stop-the-world, l'applicazione invece gira leggermente più lentamente mentre il GC viene eseguito in parallelo.

C'è un altro GC che esegue la deframmentazione dinamica e soddisfa i requisiti in tempo reale, ma l'unico riferimento che riesco a trovare è qui (è richiesta l'iscrizione ACM).

Un interessante garbage collector in tempo reale simultaneo è senza sosta . Utilizza il tradizionale approccio mark-and-sweep, ma è progettato per l'uso su sistemi multiprocessore e supporta il multithreading simultaneo senza blocco.

Il motivo per cui funziona è perché in Java solo il GC può liberare memoria che potrebbe contenere riferimenti GC. Ciò significa che finché puoi leggere gli oggetti in un thread separato in modo sicuro, dovrai solo mettere in pausa il programma per osservare i riferimenti nello stack.

Vorrei suggerire per mutazione che implementano una qualche forma di copia su scrittura per informare il GC della modifica.