¿Cuáles son los algoritmos detrás de la pausa baja GC?

Algunos idiomas, por ejemplo, Java, introdujeron un GC de pausa baja.

Esos GC pueden hacer la mayor parte del trabajo sin detener el mundo entero. Obviamente, este es un problema bastante difícil porque requiere analizar la memoria cuando el hilo lo está modificando, lo que da como resultado datos que se pueden usar al comienzo del proceso y no más cuando finaliza, o datos que parecen ser basura, sino porque el la referencia se movió en la memoria y nunca apareció donde estaba mirando el GC.

Básicamente, ¿cuál es el (los) algoritmo (s) detrás de eso?

Los trabajos de investigación o el enlace de un artículo realmente técnico se considerarían una respuesta válida, ya que este tema es realmente técnico.

Básicamente, ¿cuál es el (los) algoritmo (s) detrás de eso?

Básicamente es un algoritmo de marca y barrido que "simplemente" se ejecuta simultáneamente en un hilo separado.

En cuanto a los trabajos de investigación sobre ese tema:

• Recolección de basura de barrido y marca muy concurrente sin sincronización de grano fino

• Colector garbabe de barrido de marcas concurrente (contiene enlaces a dos documentos, uno que se enumera a continuación)

• Implementación de un recolector de basura sobre la marcha para Java

• Recolección de basura portátil y discreta para sistemas multiprocesador (Doligez Leroy, Powerpoint Presentation)

• Recolección de basura sobre la marcha: un ejercicio de cooperación (por Edsger Wybe Djikstra)

Por lo que yo entiendo, el recolector de basura Java G1 utiliza las llamadas regiones de almacenamiento dinámico para evitar detener el mundo entero. La forma en que lo veo es que si bien GC limpia una de las regiones al realizar la limpieza, la asignación de memoria se realiza en otra región.

Aquí hay una explicación de Jeremy Manson :

El principio es simple: el recopilador divide el montón en regiones de tamaño fijo y rastrea los datos en vivo en esas regiones. Mantiene un conjunto de punteros, el "conjunto recordado", dentro y fuera de la región. Cuando un GC se considera necesario, primero recopila las regiones con menos datos en vivo (por lo tanto, "basura primero"). A menudo, esto puede significar recopilar una región completa en un solo paso: si el número de punteros en una región es cero, entonces no es necesario marcar ni barrer esa región ...

• Aquí hay un documento técnico de los ingenieros de Sun que explican su diseño: Recolección de basura primero.

La JVM en tiempo real de IBM utiliza un recolector de basura llamado Metronome que divide la actividad del GC en cuantos discretos y los intercala con el procesamiento de la aplicación. Entonces, básicamente, en lugar de pausas periódicas (y no deterministas) de GC para detener el mundo, la aplicación se ejecuta un poco más lenta mientras que el GC se realiza en paralelo.

Hay otro GC que hace una desfragmentación dinámica y cumple con los requisitos en tiempo real, pero la única referencia que puedo encontrar está aquí (se requiere membresía de ACM).

Un interesante recolector de basura concurrente en tiempo real no tiene fin . Utiliza el enfoque tradicional de marcado y barrido, pero está diseñado para su uso en sistemas multiprocesador y admite subprocesos múltiples simultáneos sin bloqueo.

La razón por la que funciona es porque en Java, solo el GC puede liberar memoria que puede contener referencias de GC. Eso significa que siempre que pueda leer objetos en un hilo separado de forma segura, solo necesitará pausar el programa para observar las referencias en la pila.

Sugeriría por mutación que implementen alguna forma de copia en escritura para informar al GC sobre el cambio.