¿Por qué el equipo de LMAX usó Java y diseñó la arquitectura para evitar GC a toda costa?

¿Por qué el equipo de LMAX diseñó el Disruptor LMAX en Java pero todos sus puntos de diseño para minimizar el uso de GC? Si uno no quiere que se ejecute GC, ¿por qué usar un lenguaje de recolección de basura?

Sus optimizaciones, el nivel de conocimiento del hardware y el pensamiento que ponen son simplemente impresionantes, pero ¿por qué Java?

No estoy en contra de Java ni nada, pero ¿por qué un lenguaje GC? ¿Por qué no usar algo como D o cualquier otro lenguaje sin GC pero permite un código eficiente? ¿Es que el equipo está más familiarizado con Java o Java posee alguna ventaja única que no estoy viendo?

Digamos que lo desarrollan usando D con administración manual de memoria, ¿cuál sería la diferencia? Tendrían que pensar bajo nivel (que ya son), pero pueden exprimir el mejor rendimiento del sistema como es nativo.

Porque hay una gran diferencia entre optimizar el rendimiento y desactivar por completo una seguridad

Al reducir la cantidad de GC, su marco es más receptivo y puede ejecutarse (presumiblemente) más rápido. Ahora, optimizar para el recolector de basura no significa que nunca hagan una recolección de basura. Simplemente significa que lo hacen con menos frecuencia, y cuando lo hacen, corre muy rápido. Ese tipo de optimización incluye:

1. Minimizando el número de objetos que se mueven a un espacio de sobreviviente (es decir, que sobrevivió al menos a una recolección de basura) mediante el uso de pequeños objetos desechables. Los objetos que se movieron al espacio de sobrevivientes son más difíciles de recolectar y una recolección de basura aquí en algún momento implica congelar toda la JVM.
2. Para empezar, no asigne demasiados objetos. Esto puede ser contraproducente si no tiene cuidado, ya que los objetos de la generación joven son muy baratos de asignar y recolectar.
3. Asegúrese de que el objeto nuevo apunte al antiguo (y no al revés) para que el objeto joven sea fácil de recolectar, ya que no hay referencia a ellos que haga que se mantengan

Cuando desconecta el rendimiento, generalmente ajusta un "punto caliente" muy específico mientras ignora el código que no se ejecuta con frecuencia. Si hace eso en Java, puede dejar que el recolector de basura se encargue de esos rincones oscuros (ya que no hará mucha diferencia) mientras optimiza con mucho cuidado el área que se ejecuta en un circuito cerrado. Por lo tanto, puede elegir dónde optimizar y dónde no, y así puede enfocar su esfuerzo donde sea importante.

Ahora, si apaga completamente la recolección de basura, entonces no puede elegir. Debe deshacerse manualmente de cada objeto, nunca. ¿Se llama ese método como máximo una vez al día? En Java, puede dejarlo, ya que su impacto en el rendimiento es insignificante (puede estar bien dejar que ocurra un GC completo cada mes). En C ++, todavía está perdiendo recursos, por lo que debe cuidar incluso ese método oscuro. Por lo tanto, debe pagar el precio de la gestión de recursos en cada parte de su aplicación, mientras que en Java puede concentrarse.

Pero empeora.

¿Qué sucede si tiene un error, digamos en un rincón oscuro de su aplicación al que solo se accede el lunes en luna llena? Java tiene una fuerte garantía de seguridad. Hay poco o ningún "comportamiento indefinido". Si usa algo incorrecto, se genera una excepción, su programa se detiene y no se produce corrupción de datos. Así que estás bastante seguro de que nada malo puede suceder sin que te des cuenta.

Pero en algo como D, puede tener un mal acceso al puntero, o un desbordamiento del búfer, y puede dañar su memoria, pero su programa no lo sabrá (desactivó la seguridad, ¿recuerda?) Y seguirá funcionando con su incorrecto datos, y hacer algunas cosas bastante desagradables y corromper sus datos, y no lo sabe, y a medida que ocurre más corrupción, sus datos se vuelven cada vez más incorrectos, y de repente se rompen, y estaban en una aplicación crítica para la vida, y se produjo un error en el cálculo de un cohete, por lo que no funciona, explota el cohete y alguien muere, y su empresa está en la primera plana de cada periódico y su jefe le señala con el dedo que dice "Usted está El ingeniero que sugirió que usáramos D para optimizar el rendimiento, ¿por qué no pensó en la seguridad?". Y es tu culpa. Usted mató a esas personas con su estúpido intento en el rendimiento.

Ok, ok, la mayoría de las veces es mucho menos dramático que eso. Pero incluso una aplicación crítica para el negocio o simplemente una aplicación de GPS o, digamos, un sitio web de salud del gobierno puede tener algunas consecuencias bastante negativas si tiene errores. Usar un lenguaje que los prevenga por completo o que falle rápido cuando suceden suele ser una muy buena idea.

Hay un costo para desactivar una seguridad. Ser nativo no siempre tiene sentido. A veces es mucho más simple y seguro optimizar un poco un lenguaje seguro que utilizarlo todo para un idioma en el que puedas dispararte en el pie a lo grande. La corrección y la seguridad en muchos casos superan los pocos nanosegundos que habría desechado al eliminar el GC por completo. Disruptor se puede utilizar en esa situación, por lo que creo que LMAX-Exchange hizo la llamada correcta.

Pero, ¿qué pasa con D en particular? Tienes un GC si quieres para las esquinas oscuras, y el subconjunto SafeD (que no conocía antes de la edición) elimina el comportamiento indefinido (¡si recuerdas usarlo!).

Bueno, en ese caso es una simple cuestión de madurez. El ecosistema de Java está lleno de herramientas bien escritas y bibliotecas maduras (mejor para el desarrollo). Muchos más desarrolladores conocen Java que D (mejor para mantenimiento). Buscar un lenguaje nuevo y no tan popular para algo tan crítico como una aplicación financiera no hubiera sido una buena idea. Con un lenguaje menos conocido, si tiene un problema, pocos pueden ayudarlo, y las bibliotecas que encuentra tienden a tener más errores ya que estuvieron expuestos a menos personas.

Así que mi último punto aún es válido: si desea evitar problemas con consecuencias nefastas, quédese con opciones seguras. En este punto de la vida de D, sus clientes son las pequeñas empresas nuevas listas para asumir riesgos locos. Si un problema puede costar millones, es mejor mantenerse más lejos en la curva de la campana de la innovación .

Parece que la razón por la que está escrito en Java es que tienen experiencia en Java internamente y probablemente fue escrito (aunque todavía está en desarrollo activo) antes de que C ++ actuara junto con C ++ 0x / 11.

Su código es en realidad solo Java por su nombre, usan sun.misc.Unsefe bastante, lo que derrota el punto de Java y supuestamente brinda seguridad. He escrito un puerto C ++ del Disruptor y supera el código Java que envían (no pasé mucho tiempo ajustando la JVM).

Dicho esto, los principios que sigue el disruptor no son específicos del lenguaje, por ejemplo, no espere un código C ++ de baja latencia que asigne o libere del montón.

Esta pregunta establece una premisa incorrecta como un hecho, luego hace un argumento sobre esa premisa incorrecta.

Vamos a profundizar en esto ... "todos sus puntos de diseño para minimizar el uso de GC", simplemente no es cierto. La innovación en el disruptor tiene poco que ver con GC. El disruptor funciona porque su diseño considera inteligentemente cómo funcionan las computadoras modernas, algo que es mucho menos común de lo que uno podría esperar. Vea la charla de Cliff Click http://www.azulsystems.com/events/javaone_2009/session/2009_J1_HardwareCrashCourse.pdf para una discusión.

Es bien sabido que LMax son clientes de Azul. Sé de primera mano que con los GC azules simplemente no es un problema, incluso con montones de 175 GB.

Tendrían que pensar bajo nivel

Arriba hace la mitad de la respuesta que estás buscando. Puede encontrar otra mitad para completar el razonamiento no más allá del blog LMAX :

Si bien es muy eficiente, puede provocar una serie de errores, ya que es muy fácil de fastidiar ...

Como admitieron los desarrolladores de LMAX, un código como ese podría ser bastante difícil de desarrollar, comprender y depurar, incluso en Java. Ir a un nivel inferior más allá de donde están ahora solo exacerbará este problema, como se señala en el artículo de Wikipedia sobre lenguajes de programación de bajo nivel :

Se puede hacer que un programa escrito en un lenguaje de bajo nivel se ejecute muy rápidamente y con una huella de memoria muy pequeña; un programa equivalente en un lenguaje de alto nivel será más pesado. Los lenguajes de bajo nivel son simples, pero se consideran difíciles de usar, debido a los numerosos detalles técnicos que deben recordarse .

En comparación, un lenguaje de programación de alto nivel aísla la semántica de ejecución de una arquitectura de computadora de la especificación del programa, lo que simplifica el desarrollo ...

Si utiliza Java como lenguaje de sintaxis y evita sus bibliotecas JDK, puede ser tan rápido como un lenguaje compilado que no sea GC. GC no es adecuado para sistemas en tiempo real, pero es posible desarrollar sistemas en Java que no dejen basura. Como resultado, el GC nunca se dispara.

Creemos que el lenguaje y la plataforma Java tienen muchas ventajas sobre C / C ++ y hemos desarrollado y comparado algunos componentes Java de latencia ultra baja para probarlo. Hablamos sobre las técnicas para hacerlo en este artículo: Desarrollo Java sin GC .

LMAX es una biblioteca de mensajería entre subprocesos de alto rendimiento.

Para ser útil, alguien más tiene que escribir el código para que cada hilo haga un trabajo útil. Dado que es muy probable que el código esté en Java o C # y luego hay muy pocas opciones de lenguaje que interactúen bien con ellos.

Usar C o C ++ no es una buena opción a menos que desee limitar a sus usuarios a un único sistema operativo, ya que no hay un modelo de subprocesos definido en ellos.

Java es el estándar para mucho desarrollo de software en estos días, por lo que, a menos que tenga una buena razón de lo contrario, tiende a ser la mejor opción. (Cuando en Roma, haz como los romanos…)

Escribir software de alto rendimiento en Java (o C #) a menudo se hace para probar un punto ...