¿Hay una implementación de peor caso de la JVM?

Question

El Java memory model deja en claro lo que se puede y no se puede asumir sobre cómo los hilos interactúan a través de la memoria. Por ejemplo, si un hilo escribe un nuevo valor en un campo sin la sincronización adecuada, entonces el nuevo valor no se garantiza que sea observable por otros hilos. En la práctica, sin embargo, otros subprocesos podrían leer el nuevo valor a pesar de una sincronización inadecuada, dependiendo del tiempo entre escritura y lectura, arquitectura de hardware, etc.

Esto puede provocar errores que son difíciles de descubrir y difíciles de reproducir . Por lo tanto, podría ser útil ejecutar una aplicación Java en el peor de los casos JVM que no haya absolutamente ninguna sincronización de memoria entre los hilos más allá de las garantías en el Java memory model. ¿Existe una implementación de JVM en el peor de los casos?

Answer 1

Puede intentar usar Terracotta para agrupar su programa. Es increíblemente implacable con respecto a la sincronización incorrecta (que será evidente incluso con un solo nodo en el clúster). Esta es una pregunta gran: a menudo he deseado exactamente esta capacidad - Me sorprende que no hay un interruptor en el JRE estándar -XXJMMExtreme

terracota es de código abierto y libre para el producto básico.

Answer 2

No conozco ningún VM que garantice el peor comportamiento posible todo el tiempo, que parece ser lo que está pidiendo. La situación que está describiendo puede ocurrir con las VM de Sun (y muchas otras), pero solo debido a problemas de almacenamiento en caché. No estoy familiarizado con una VM que hace esto todo el tiempo intencionalmente.

Answer 3

Esto podría ayudar: http://javapathfinder.sourceforge.net/

Answer 4

Hay muchas maneras lo que podría provocar un error de concurrencia.

• Cargue su aplicación a muchos más hilos de lo que normalmente esperaría. Asegúrese de que esto sea más que suficiente para obtener el 99% + CPU.
• Ejecute su programa con un generador de perfiles habilitado o el JIT deshabilitado. Esto cambia el comportamiento de sincronización de su aplicación.
• Prueba Java 5 y Java 6 (Esta es a menudo la forma más simple y la mejor manera de encontrar algunos errores) No he encontrado un error con Java 7 que no apareció en 5/6.

Para el peor de los casos JVM, pruebe con un teléfono móvil. (Probablemente su aplicación no funcionará en absoluto);)

Answer 5

Los errores de sincronización suelen ser difíciles de reproducir porque dependen de tiempos sutiles entre diferentes hilos, por lo que ninguna implementación que intente "ejecutar su programa" siempre puede ser "lo peor posible". No puede reproducir más de una manera diferente en que dos hilos pueden intercalar sus instrucciones si solo ejecuta estas instrucciones una vez. Probar todas esas combinaciones en una sola ejecución es aún menos posible. Uno de los otros carteles sugirió Java Pathfinder y eso suena como una buena idea, pero tenga en cuenta que es una aplicación que ejecuta el mismo código muchas veces, por lo que no se puede tratar como una simple implementación de JVM.

Otro consejo práctico es probar y ejecutar la aplicación en tantas JVM diferentes como sea posible. Pruebe diferentes proveedores, diferentes versiones del mismo proveedor, diferentes arquitecturas de CPU, etc. Hace unos años, tenía experiencia con una aplicación de muchos subprocesos que había sido desarrollada, probada y ejecutada en Sun's JVM en las CPU Xeon, donde funcionaba muy bien. En un momento intenté ejecutarlo en la máquina J9 Java Virtual Machine de IBM en la arquitectura POWER y al primer intento, aproximadamente 2/3 de las pruebas fallaron debido a errores de sincronización.Por lo tanto, las pruebas en diferentes entornos pueden ser bastante buenas para exponer problemas de sincronización ocultos.