Aquí, Microsoft usa los nombres "concurrente" y "de fondo" para describir dos versiones del GC que utiliza en .NET. En el mundo .NET, el "colector de segundo plano" es una mejora sobre el "recopilador simultáneo", ya que tiene menos restricciones sobre lo que pueden hacer los subprocesos de la aplicación mientras se ejecuta el recopilador.
Un GC básico utiliza una estrategia de "detén el mundo": los subprocesos aplicativos asignan bloques de memoria de un montón común. Cuando el GC debe ejecutarse (por ejemplo, se han asignado demasiados bloques, se necesita cierta limpieza), todos los hilos aplicativos (gestionados) se detienen. El último hilo de detención ejecuta el GC y desbloquea todos los otros subprocesos cuando termina. Un GC stop-the-world es simple de implementar pero induce pausas que pueden ser perceptibles a nivel del usuario.
"concurrent GC" de Microsoft es generacional: utiliza la estrategia stop-the-world para solo una parte limitada del montón (lo que ellos llaman "generaciones 0 y 1"). Como esa parte sigue siendo pequeña, las pausas permanecen cortas (por ejemplo, menos de 50 ms), de modo que el usuario no las notará. El resto del montón se recopila con un subproceso de GC dedicado, que puede ejecutar al mismo tiempo con los subprocesos aplicativos (de ahí el nombre).
El GC concurrente tiene algunas limitaciones. A saber, hay momentos en que el subproceso GC debe asumir un control exclusivo del montón. Durante esos momentos, los subprocesos aplicativos pueden asignar bloques solo desde áreas pequeñas específicas de subprocesos. Los hilos que tienen mayores necesidades pronto tropezarán con el montón principal, que, en ese momento, está bloqueado por el hilo del GC. El hilo de asignación debe bloquearse hasta que el hilo del GC haya terminado su fase de bloqueo del montón. Esto nuevamente provoca pausas. Menos pausas que con un GC stop-the-world, y estas pausas no afectan a todos los hilos. Sin embargo, hace una pausa, no obstante.
El "GC de fondo" es un GC mejorado en el que el subproceso GC no necesita bloquear el montón. Esto elimina las pausas adicionales descritas en el párrafo anterior; solo quedan las pausas limitadas cuando se recolectan las generaciones jóvenes (lo que Microsoft llama "una colección de primer plano").
Nota: hay "costos ocultos" con el GC concurrente y el GC de fondo. Para que estos GC funcionen correctamente, los accesos de memoria de los subprocesos aplicativos deben hacerse de formas muy específicas, que tienen un ligero impacto en el rendimiento. Además, el hilo del GC puede tener un efecto adverso en la memoria caché, lo que indirectamente degrada el rendimiento. Para una tarea puramente computacional sin necesidad de la interacción del usuario, un colector stop-the-world puede, en promedio, rendir un rendimiento algo mejor (por ejemplo, un cómputo de veinte horas se completará en diecinueve horas). Pero este es un caso extremo, y en la mayoría de las situaciones, el GC simultáneo y de fondo es mejor.
buena explicación ... sin embargo, sería más apropiado si se atiene a la terminología general. hilos/código gestionados, etc. ¿Aplicativo? ¿que es eso? –
Los subprocesos aplicativos son subprocesos que ejecutan el código que el programador escribe (a diferencia de los subprocesos de administración ocultos, si los hay). Los subprocesos "administrados" son subprocesos que ejecutan código administrado (es decir, no código escrito en C o C++). Esta es la terminología principal. –