Barrapunto

Si lo que buscas es mejorar la eficiencia, no puedes meter un "proceso" que esté buscando bloques a ver si se referencian, además de mantener la estructura de punteros necesaria para que eso sea posible.

Si Java incluyó el recolector de basura es porque evitaba muchos errores y el crecimiento insostenible de la aplicación, pero todo tiene un coste, y éste es el del rendimiento.

De hecho la versión de Java para tiempo real ha tenido que permitir no usar el recolector de basura, sino unas especies de malloc y free.

Hombre, se puede lanzar un proceso así cuando el procesador esté con menos trabajo o en ciertos momentos prefijados.

Pero desde luego coincido en que puede ser una carga adicional que no compense. Eso si, para el programador es una grandísima ayuda.

Saludos.

No es exactamente el rendimiento el que se ve perjudicado. El gc tiene coste 0 de asignacion/recuperacion. Lo que pasa es que el gc arranca de forma impredecible de vez en cuando (la mayoria de veces por milisegundos).

Si tienes que hacer un java en tiempo real, lo primero que tienes que eliminar es cualquier fuente de impredicibilidad (wow! palabro).

Porque recordemos que "tiempo real" no tiene nada que ver con eficiencia o velocidad. Simplemente que se puede predecir exactamente cuanto tardara una cierta operacion (Y de rebote, que es lo que realmente se busca en esos lenguajes, velocidad constante independiente del entorno). Un GC determinista, seria perfectamente valido en un entorno TR, llamandolo a mano cuando tu quisieras. El problema es que no existen GC's genericos deterministas, con lo que se tiene que hacer a mano con malloc free o similares.