java - una - sistemas en tiempo real ventajas y desventajas
¿Un recolector de basura(.net/java) es un problema para los sistemas en tiempo real? (7)
Cuando se construye un sistema que necesita responder de manera muy consistente y rápida, ¿tener un recolector de basura es un problema potencial?
Recuerdo historias de horror de hace años, donde el ejemplo típico siempre fue un juego de acción en el que tu personaje se detendría durante unos segundos en el medio salto, cuando el recolector de basura haría su limpieza.
Estamos algunos años más, pero me pregunto si esto sigue siendo un problema. Leí sobre el nuevo recolector de basura en .Net 4, pero aún parece una gran caja negra, y solo debes confiar en que todo estará bien.
Si tiene un sistema que siempre tiene que ser rápido para responder, es tener un recolector de basura un problema demasiado grande y ¿es mejor elegir un lenguaje más duro, cámbielo usted mismo como c ++? Odiaría que si resulta ser un problema, que básicamente no hay nada que puedas hacer al respecto, aparte de esperar una nueva versión del tiempo de ejecución o hacer cosas muy extrañas para tratar de influir en el coleccionista.
EDITAR
Gracias por todos los grandes recursos. Sin embargo, parece que la mayoría de los artículos / custom gc''s / solutions pertenecen al entorno Java. ¿Tiene .Net también capacidades o opciones de ajuste para un GC personalizado?
Es un problema potencial , PERO ...
Su personaje también puede congelarse en medio de su programa C ++ mientras el sistema operativo recupera una página de memoria de un disco duro sobrecargado. Si no está utilizando un sistema operativo en tiempo real en un hardware diseñado para proporcionar garantías concretas de rendimiento, nunca se le garantiza el rendimiento.
Para obtener una respuesta más específica, tendría que preguntar acerca de una implementación específica de una máquina virtual específica. Puede usar una máquina virtual de recolección de basura para sistemas en tiempo real si proporciona garantías de rendimiento adecuadas sobre la recolección de basura.
He escrito juegos en Java y .NET y nunca he encontrado que esto sea un gran problema. Espero que sus "historias de terror" se basen en los recolectores de basura de hace muchos años, la tecnología realmente ha avanzado mucho desde entonces.
La única cosa por la que dudaría en usar Java / .NET en la base de la recolección de basura sería algo así como la programación incrustada con restricciones en tiempo real (por ejemplo, controladores de movimiento).
Sin embargo, debe conocer las pausas de GC y todo lo siguiente puede ser útil para minimizar el riesgo de pausas de GC:
- Minimice las nuevas asignaciones de objetos: mientras que las asignaciones de objetos son extremadamente rápidas en los sistemas GC modernos, contribuyen a futuras pausas, por lo que deberían minimizarse. Puede usar técnicas como la asignación previa de matrices de objetos, mantener grupos de objetos o usar primitivas sin caja.
- Utilice bibliotecas especializadas de baja latencia como Javalution para funciones y tipos de datos muy utilizados. Estos están diseñados específicamente para aplicaciones de tiempo real / baja latencia
- Asegúrese de utilizar el mejor algoritmo GC cuando haya varias versiones disponibles. He oído cosas buenas sobre el Sun G1 Collector para aplicaciones de baja latencia. Los mejores sistemas de GC hacen la mayoría de sus colecciones al mismo tiempo para que las recolecciones de basura no tengan que "detener el mundo" por mucho tiempo, si es que lo hacen.
- Sintonice los parámetros de GC adecuadamente. Por lo general, existe una compensación entre el rendimiento general y los tiempos de pausa, es posible que desee mejorar este último a expensas del primero.
Si usted es muy rico, por supuesto puede comprar máquinas con soporte de hardware GC . :-)
Nuestra empresa está empleando una gran aplicación de software basada en .Net que, entre otras cosas, supervisa los sensores binarios a través de redes de bus de campo. En algunas situaciones, los sensores se activan solo por un corto período de tiempo (300 ms), pero nuestro software aún necesita capturar esos eventos, ya que el sistema controlado fallará inmediatamente cuando se pierda un evento. Recientemente, observamos un aumento de los problemas en los sitios de nuestros clientes debido a que el recolector de basura funciona durante largos períodos de tiempo (hasta 1 segundo). Todavía estamos tratando de averiguar cómo hacer cumplir un límite de tiempo en el recolector de basura. En conclusión de esta breve historia, diría que el recolector de basura es una desventaja en aplicaciones críticas de tiempo.
Para ser precisos, los recolectores de basura son un problema para los sistemas en tiempo real. Para ser aún más precisos, es posible escribir software en tiempo real en idiomas que tienen administración automática de memoria.
Se pueden encontrar más detalles en la Especificación en tiempo real para Java en uno de los enfoques para lograr un comportamiento en tiempo real utilizando Java. La idea detrás de RTSJ es muy simple: no utilice un montón. RTSJ proporciona nuevas variedades de objetos Runnable que garantizan que los subprocesos no tengan acceso a la memoria de almacenamiento dinámico de ningún tipo. Los subprocesos pueden acceder a la memoria de ámbito (nada inusual aquí; los valores se destruyen cuando se cierra el alcance) o la memoria inmortal (que existe durante toda la vida útil de la aplicación). Las variables en la memoria inmortal se escriben una y otra vez con nuevos valores.
Mediante el uso de memoria inmortal, RTSJ garantiza que los subprocesos no accedan al montón, y lo que es más importante, el sistema no tiene un recolector de basura que anticipa la ejecución del programa por los subprocesos.
Más detalles están disponibles en el documento "Proyecto Golden Gate: Hacia Java en tiempo real en misiones espaciales" publicado por JPL y Sun.
Sí, la basura debe manejarse de manera determinista en sistemas en tiempo real.
Un enfoque es programar una cierta cantidad de tiempo de recolección de basura durante cada asignación de memoria. Esto se llama "recolección de basura basada en el trabajo". La idea es que, en ausencia de fugas, la asignación y la recolección deben ser proporcionales.
Otro enfoque simple ("recolección de basura basada en el tiempo") es programar una cierta proporción de tiempo para la recolección de basura periódica, sea necesario o no.
En cualquier caso, es posible que un programa se quede sin memoria utilizable porque no se le permite pasar el tiempo suficiente para hacer una recolección de basura completa. Esto contrasta con un sistema no en tiempo real, que se permite pausar todo el tiempo que sea necesario para recolectar basura.
Usted apuesta que es un problema. Si está escribiendo aplicaciones de baja latencia, no puede permitirse las pausas de detener el mundo que imponen la mayoría de los recolectores de basura. Como Java no le permite apagar el GC, su única opción es no producir basura. Eso se puede hacer y se ha hecho a través de la agrupación de objetos y el arranque. Escribí un artículo de blog donde hablo de esto en detalle.
Desde un punto de vista teórico, los recolectores de basura no son un problema sino una solución . Los sistemas en tiempo real son difíciles, cuando hay asignación de memoria dinámica. En particular, las funciones C habituales malloc() y free() no ofrecen garantías en tiempo real (normalmente son rápidas, pero tienen, al menos en teoría, "los peores casos" en los que utilizan cantidades de tiempo excesivas).
Sucede que es posible crear un asignador de memoria dinámico que ofrezca garantías en tiempo real, pero esto requiere que el asignador haga algunas tareas pesadas, en particular moviendo algunos objetos en la RAM. El movimiento de objetos implica ajustar los punteros (de forma transparente, desde el punto de vista del código de la aplicación), y en ese punto el asignador está a solo un pequeño paso de ser un recolector de basura.
Las implementaciones habituales de Java o .NET no ofrecen recolección de basura en tiempo real, en el sentido de tiempos de respuesta garantizados, pero su GC aún está muy optimizado y la mayoría de las veces tienen tiempos de respuesta muy cortos. En condiciones normales, los tiempos de respuesta promedio muy cortos son mejores que los tiempos de respuesta garantizados ("garantizado" no significa "rápido").
Además, tenga en cuenta que las implementaciones habituales de Java o .NET se ejecutan en sistemas operativos que tampoco son en tiempo real (el sistema operativo puede decidir programar otros subprocesos o puede enviar agresivamente algunos datos a un archivo de intercambio, y así sucesivamente), y ninguno de los dos es el hardware subyacente (por ejemplo, un disco duro típico puede hacer "pausas de recalibración" de vez en cuando). Si está listo para tolerar la falla de sincronización ocasional debido al hardware, entonces debería estar bien con un recolector de basura JVM (cuidadosamente sintonizado). Incluso para juegos.