2009-12-04 11 views
8

Estamos pensando en la transición de un producto grande de confiar en JVM de Sun a JRockit. No soy tan ingenuo como para creer que esta será una transición suave (aunque me encantaría estar equivocado).Advertencias a tener en cuenta en la transición de Sun JVM a JRockit?

¿Qué problemas debemos tener en cuenta o enfocar nuestras pruebas de regresión?

+0

El principal problema con JRockit es que su inestabilidad es difícil de reproducir. Las pruebas de regresión simple no revelarán sus horrores. Solo bajo una alta carga de producción se producirán hilos colgados esporádicamente. ¿Por qué diablos cambiarías de Sun a JRockit? – erickson

+0

Después de algunos saltos de búsqueda de JRockit terminé aquí: http://www.shudo.net/jit/perf/ Donde hay algunas pruebas de rendimiento impresionantes que muestran el servidor Java más rápido que C compilado con GCC (Visual C++ es aún más rápido) en la mayoría de los casos.) +1 increíble ... Pero me temo que no hace que JRockit se vea muy bien ... –

+0

Esto suena como un intento de sacar más rendimiento de una aplicación al arrojar algo de dinero y tecnología. En tu lugar (¡fácil de decir!Intentaré educar a tu gerencia para que comprenda que las supuestas ganancias se obtienen a costa de la inestabilidad, lo que también tiene un costo. A menudo es posible obtener más rendimiento con menos riesgo a través de las prácticas comprobadas de creación de perfiles, la mejora de algoritmos y la búsqueda de oportunidades para aumentar la concurrencia. –

Respuesta

3

Bueno, por supuesto que tienes pruebas unitarias ¿no? :-)

He usado JRockit solo por "diversión" y nunca he tenido problemas. Por lo que puedo ver, se usa en varias aplicaciones de una gran variedad, por lo que probablemente solo funcione. Parece que también ha pasado el JCK (las pruebas de compatibilidad de Sun), por lo que debe ser suave.

Áreas que iba a imaginar para romper serían:

  • recolector de basura
  • código nativo (JNI) manejo del sistema
  • archivo, roscado, etc ... (a menos que usen el Sol código de la biblioteca)

El sistema de archivos, el subprocesamiento, etc. son todas las partes de la máquina virtual que se integran con el sistema operativo subyacente. Si usan el código Sun, tienen menos posibilidades de problemas.

Apuesto a que la transición funciona sin problemas.

+0

Eso es precisamente eso: no usan el código nativo de Sun para E/S y enhebrado de socket. Usan su propio ... porque es mucho más rápido (¡no!). Desafortunadamente, esta mejora de velocidad insignificante viene con una gran inestabilidad. Espero que cuando Oracle complete el trato con Sun exterminarán a JRockit. – erickson

+0

@sylvarking: Cualquier enlace a historias de horror de inestabilidad sería extremadamente útil :) – Uri

+0

Lo siento, mi opinión se basa en una experiencia personal y anecdótica con una gran aplicación para un cliente que no apreciaría que yo la compartiera. – erickson

1

Como siempre digo: Solo hay una forma de averiguarlo: ¡hazlo!

La transición debe tomar alrededor de 30 minutos lo ... (que acaba de instalar JRockit y cambiar la ruta en algún lugar correcto?)

Usted debe estar bien.

Tuve problemas en el pasado con JDBC que eran extremadamente extraños (porque el código problemático estaba en la referencia PreparedStatement que, como todos sabemos, es solo una interfaz. El controlador subyacente era exactamente el mismo). Tengo esto mensajes de error extraños sobre la declaración insert into.

Para ser sincero, había otra variable aquí, estaba migrando de Java 1.2.2 a Java (JRockit) 1.4 y, sin embargo, creo que no debería haber tenido todos esos problemas.

Pero, de nuevo, debería ser lo suficientemente rápido como para averiguarlo. En mi caso vi que tuve estos problemas en < durante 5 minutos y dado que eso fue solo un experimento (asistí a este día de desarrolladores de BEA cuando hablaron sobre las excelentes características que tenía JRockit) simplemente lo descarté.

Cuestiones relacionadas