“No hay necesidad de que el usuario programe la devolución de registros para liberar memoria” .. o algo así fue lo que escribió John McCarthy en un escríto llamado “Recursive Functions of Symbolic Expressions and Their Computation by Machine” que fue publicado allá por 1960.
McCarthy lo que trataba de explicar era como gestionar la memoria en aplicaciones Lisp y de como logró excluir la gestión de memoria explícita, lo que liberó a los desarrolladores de la difícil tarea de gestión de memoria manual, en pocas palabras su texto y pieza de código fue lo que inspiró a otros programadores a incorporar la gestión de memoria automatizada, también conocida como recolección de basura (Garbage Collector – GC).
En las versiones iniciales de Lisp era normal que el GC consumiera alrededor del 30 ó 40% de CPU, pero valía la pena, porque el impacto en cuanto al rendimiento de las aplicaciones era algo novedoso, rápido y ahorraba a los programadores liberar esos espacios de memoria utilizados, pero en palabras generales los collectores de basura son subprocesos que se ejecutan cada cierto tiempo y especialmente esta implementación en Lisp destacó la batalla constante entre el tiempo de pausa y el impacto en el rendimiento de la aplicación que persiste hasta nuestros días. En general, cuanto mejor sea el tiempo de pausa característico del colector, mayor será el impacto en el rendimiento de la aplicación.
Actualmente los GC funcionan casi sin que nos demos cuenta, obviamente requieren mucha más memoria para funcionar tan rápido y trabajan en forma de hilos para evitar bloquear las aplicaciones en un sólo proceso.
Un artículo relacionado y donde se explica mejor como funcionan los collectores de basura está siguiendo este enlace, por si te interesa leer un poco sobre el tema y seguir aprendiendo.
Happy Coding!! 🙂