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

12

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

Esos GC pueden hacer la mayor parte del trabajo sin hacer una pausa en todo el mundo. Obviamente, este es un problema bastante difícil porque requiere analizar la memoria cuando la hebra la está modificando, lo que da como resultado datos que se pueden usar al principio del proceso y no más cuando termina, o datos que parecen ser basuras, pero debido a que la referencia se movió en la memoria y nunca apareció donde el GC estaba mirando.

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

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

    
pregunta deadalnix 23.08.2011 - 12:31

4 respuestas

16
  

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

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

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

respondido por el Falcon 23.08.2011 - 12:35
4

por lo que tengo entendido, el recolector de basura Java G1 utiliza las denominadas regiones de almacenamiento dinámico para evitar la pausa en todo el mundo. La forma en que lo veo es que mientras que una de las regiones está bloqueada por el GC que realiza 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 colector 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 se considera necesario un GC, primero recopila las regiones con menos datos en vivo (por lo tanto, "basura primero"). A menudo, esto puede significar la recopilación de una región completa en un solo paso: si el número de punteros en una región es cero, entonces no es necesario hacer una marca o barrido de esa región ...

respondido por el gnat 23.08.2011 - 17:15
4

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

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

Un recolector de basura en tiempo real interesante es stopless . 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.

    
respondido por el TMN 23.08.2011 - 18:17
2

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

Sugeriría para la mutación que implementen algún tipo de copia en escritura para informar al GC sobre el cambio.

    
respondido por el DeadMG 23.08.2011 - 12:44

Lea otras preguntas en las etiquetas