OpenJDK es 5 veces más lento que los binarios propietarios de Oracle en ARM/Linux
AbrahamHoy he comenzado el día con un cabreo monumental. Mientras desayunaba estaba escuchando el episodio 72 de "The Java Spotlight Podcast", un podcasts corporativo de Oracle sobre Java. Una de las noticias que cubrieron en el era una prueba de rendimiento que otro empleado de Oracle había hecho comparando el rendimiento del OpenJDK y el de los binarios propietarios de Oracle ("Oracle Java SE embedded compiler") en ARM/Linux, comparando tanto el compilador de cliente como el de servidor (c1 y c2).
El resultado más sorprendente es que OpenJDK es de 3 a 5 veces más lento que los binarios propietarios de Oracle en ARM/Linux:
Y encima los empleados de Oracle en el podcast justifican esto:
"… eso no es demasiado sorprendente, ya que crear una buena máquina virtual Java es muy complicado y requiere mucho tiempo para perfeccionarla. Teniendo en cuenta los recursos empleados primero por Sun y después por Oracle no es sorprendente que una versión comercial de Java SE tenga un rendimiento excelente" (en torno al minuto seis de la grabación).
Este fue el momento en el que comenzó mi cabreo. ¿No se supone que este año Oracle está dejando de hacer disponible los binarios propietarios de Java SE de Oracle para Linux porque con Java 7 "no había ningún motivo para emplear los binarios propietarios de Oracle en vez de el OpenJDK". A partir del 24 agosto de este año ninguna distribución de Linux podrá distribuir la versión de Java de Oracle. Y Ubuntu ya lleva haciendo esto dos semanas.
Está claro que, al menos en el caso de ARM, Oracle nos ha engañado. Si hay un claro motivo para usar los binarios propietarios de Oracle en vez de el OpenJDK: hasta 5x más rendimiento. Y debemos creernos el dato; viene del propio Oracle. Es más, ellos se lo apuntan como un "triunfo".
Quizás este benchmark no sea extrapolable a las plataformas x86. Pero el hecho de que hasta hace un par de años OpenJDK sí tenía un claro rendimiento inferior al de los binarios propietarios de Oracle (especialmente en aplicaciones swing, haciéndolas incluso inutilizables) unido a algunos comentarios de gente que afirma que esto sigue siendo así (Carl Quinn y Dick Wall, dos de los chicos de Javaposse, lo afirmaban recientemente en este podcast) me hacen pensar que en plataformas x86 nos vamos a encontrar con algo similar.
Los movimientos de Oracle en la línea de no hacer disponibles sus binarios en Linux, y acortar el EOL de las versiones de Java unidos a este dato no me gustan nada. Oracle podría estar dando los primeros pasos para conseguir llegar a una situación en la que si tú quieres que tu aplicación Java tenga un rendimiento aceptable tengas que pagar una licencia por una versión propietaria. Y si no estoy en lo correcto, debería ser el propio Oracle quien publique los resultados de rendimiento comparando el OpenJDK con sus binarios propietarios para ver cuál es la situación en este caso.
En cualquier caso, lo que hay que apuntarse es un dato claro y objetivo: si vas a correr una aplicación Java en ARM/Linux, usar los binarios propietarios de Oracle te va a proporcionar hasta 5X más rendimiento respecto a usar el OpenJDK.
Reader Comments (24)
@Abraham
Deberías empezar a desayunar con una buena dosis de tila ;)
Acá hay algo que de movida no entiendo. En las gráficas se compara una implementación (cerrada) de Java 7 contra una implementación de Java 6 (OpenJDK 6)... no deberían probar contra OpenJDK 7 ?
O me perdí algo? No están comparando peras con manzanas? Y las configuraciones de cada JVM? Umm...
Bueno, parece que se va confirmando lo que algunos veíamos venir. Tendremos una versión Java comunitaria para enganchar al personal y otra de pago para hacer cosas serias. O dicho de otro modo: desarrollo profesional con Java, por favor pasen por caja (de Oracle, por supuesto).
Madre mía, que ganas me dan de aprender otros lenguajes, tecnologías... pero a ver que hago con tantos años aprendiendo y utilizando Java. Bueno, pues habrá que pedir mas al cliente o al empleador (que ingenuo, ¿verdad?).
Creo que para seguir en el mundo de Java habrá que ir centrándose mucho en el aspecto del rendimiento monetario. Por ahí irán los tiros mas que nunca.
Acabo de empezar a programar en java hace poco por lo que a altos niveles no comprendo de rendimientos, pero si entiendo 2 cosas:
Primero: Nadie tira piedras contra su propio tejado, no creo que ningun trabajador sea tan "imprudente" de decir que openjdk es tan bueno como el java de sun, si quiere que se se les tome en serio que publiquen los detalles, que aunque yo no los tienda de momento podre leer comentarios de los que saben sobre esas pruebas.
Segundo: No entiendo por que han hecho la prueba con java7 y openjdk6 habiendo una version openjdk 7 disponible desde hace tiempo,¿Es posible que en la version 7 de openjdk se obtengan mejores rendimientos y eso no les interese mostrarlo?.
Desde hace algun tiempo no se por que me da la sensacion que las compañias le estan haciendo el vacio al open source, (salvo al niño bonito de google Android), hace no mucho salio la noticia que flash iva a dejar de dar soporte a flash player en linux, salvo si tienes navegador chrome entonces si que lo podras instalar como un plugin.
Quizas sea por que de aqui a hace relativamente poco tiempo el open source esta cobrando una fuerza que no se esperaban y ahora estan intentando ponerle la zancadilla, cuando eran 3 gatos los que lo usaban no pasaba nada pero ahora...empiezan a verle las orejas al lobo.
Cuando lei el post me vino a la cabeza la imagen de abraham delante de la pantalla bebiendo la taza de cafe de la mañana y al acabar de leer la noticia echando el cafe y llenando toda la pantalla jaja.
¿Yo flipo o se los datos del gráfico dicen que la comparativa es entre OpenJDK 6 y Java SE 7? Son dos versiones distintas de Java, así que es algo más que una comparativa entre versiones equivalentes del OpenJDK y el Java SE...
Por otro lado, estoy con choces que debes dejar el café y quitarte el "tinfoil hat" de vez en cuando. Tus arterias te lo agradeceran ;).
@obs1042
Es que OpenJDK 1.7 solo hay uno, de modo que esa referencia a "JavaSE 7" es cuando menos desconcertante, y en el peor de los casos, desinformadora.
Por eso no estoy de acuerdo en que se mencione OpenJDK, sin apellidos, como si fuese un ente separado, cuando desde la versión 1.7 solo existe una única distribución.
Ese JavaSE 1.7 que se menciona en los tests es el OpenJDK 1.7
Creo que ya va siendo hora de llamar a las cosas por su nombre, y asimilar que OpenJDK es la implementación de referencia de Java, desde la versión 1.7
Mi postura sobre ARM y java SE sigue siendo la misma desde "Vías de acceso a la movilidad".
En cuanto a este tipo de informes no es la primera vez que aparecen (ver también "Java SE Embedded Performance Versus Android 2.2").
De hecho inspirado en este último, hace más de un año, compre un Coby Kyros con el objetivo de instalar Ubuntu ARM con Java SE o romperlo en el intento. En tres ocasiones estuve a punto de lograr uno de mis objetivos (romperlo).
Al final conseguí instalar java SE embedded en otro dispositivo Android y me encontré con la predecible y desagradable realidad.
Aun cuando el tablet tenia pantalla de tacto, acelerómetro y cámara, las aplicaciones java en Linux ARM no empleaban estas características y tenias que conectar un teclado y mouse USB al tablet para poder manejarlas.
Otra historia es que la mayoría de las aplicaciones Swing / AWT / SWT, fueron pensadas y construida sobre procesadores más potentes (desde x86 para arriba) por lo que no están optimizadas para operar en equipos con menores recursos (RAM y procesador) como es el caso de la mayoría de los dispositivos ARM.
¿Mi conclusión?
Si a Oracle, IBM, SAP, Red Hat y al resto de las empresas, que están detrás de Java SE no les importa agregar soporte para los rasgos de una interfaz móvil.
Si no llegan a acuerdos con los fabricantes de OS para dispositivos móviles con el objetivo de que SE venga pre instalado o sea fácil de instalar en estos OS (sin mencionar que estén bien integrado a los OS's móviles y que funcionen de manera optima).
Este tipo de comparativas sirve para lo mismo que el papel sanitario.
@Abraham.
Un consejo de amigo, mejor comenzar el día con "Big Bang Theory" y dejar esto para más tarde.
:o)
Un saludo.
@choces, OpenJDK 1.7 nueve lo mismo que la versión de Java propietaria de Oracle e (llámale JavaSE 1.7 o lo que quieras).
El test efectivamente está comparando con OpenJDK 1.6, creo que porque todavía no hay OpenJDK 1.7 corriendo sobre ARM. Oracle si tiene su versión de Java 7 para ARM: http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html
Para mí con este tipo de comparativas el mensaje que quieren enviar es un mensaje para fabricantes de dispositivos empotrados (que es donde se suelen usar estos JDKs). Y el mensaje está claro "no te creas que puedes usar esa cosita opensource del OpenJDK, que es gratis, para fabricar tu dispositivo; pararía fabricar tu dispositivo tienes que pasar por caja".
Como dice efrigerio
Esto solo sirve para limpiarse el culo, mejor programar en Android
Pues a mí sí que me parece grave. Hoy Linux/ARM, mañana es Linux/x86 el que tiene un rendimiento cinco veces menor.
Por cierto, respecto aunque la comparativa sea entre Java 6 y Java 7, de una versión a otra de la máquina virtual no va a haber un cambio 5x, y menos en un benchmark como el del estudio (responder peticiones http con Tomcat) que esta probando múltiples aspectos de la máquina virtual como entrada y salida y optimización es del JIT. En este último apartado es donde estoy seguro que está casi toda la diferencia de rendimiento…
Por último, francamente, lo que peor me sabe es que en el podcast se lo apuntan como un triunfo para Oracle en el sentido de que su producto comercial es mucho mejor que "esa cosita opensource".
Hasta la fecha, las únicas "grandes diferencias" entre las versiones embedded, y las community consistían en: usar código nativo de la plataforma de destino (como se hace con las community), y que los compiladores JIT de la VM generen ese mismo código nativo (tal cual como con las community), y... ¡Pagar!.
Jamás había oído hasta ahora que dedicasen ni un minuto a "aumentarles el rendimiento"; como mucho, y tengo serias dudas de que lo hagan, aplicarles algunas de las optimizaciones de las VM "de pago", que como se sabe, ofrecen ciertas mejoras de rendimiento, en algunos casos, y del orden de entre un 10% a un 20%.
Pero... ¡Que una VM embedded tenga varios órdenes de magnitud de diferencia!.
Y que ese sorprendente resultado proceda de la extrapolación de un único test, a todo el uso de la VM, y comparando versiones diferentes... ¡Está claro que han "bebido" :D
Estoy convencido de que como hubiesen comparado dos versiones 1.7 se les hubiese estropeado la justificación para cobrar ;) porque tengo la sospecha fundada de que ni con una buena lupa se verían las diferencias.
Abraham, choces,
Sin ofender, pero al comparar Java SE en ARM y en x86, me da la impresión que están comparando tomates con limones.
Para empezar, la evolución y desarrollo de Java SE en ARM ha sido bastante tortuosa y en ningún momento ha contado con el apoyo de los gigantes de java (léase SUN-Oracle, IBM o SAP) y esto es algo que puede extraerse de los blog's de Maemo, Ubuntu ARM, y otros.
Por otro lado ninguna de estas JVM ha tenido, ni tiene (Java SE embedded de Oracle incluida) el nivel de optimización e integración contra el OS, que por otra parte si ha existido en x86.
Esto en cuanto al mundo de los móviles, en el mundo de sistemas embebidos, he visto (y del mismo fabricante) la misma cantidad de dispositivos vasados en Windows CE que en alguna variante de Linux desconocida.
Y en este mundillo de especialización extrema (el de sistemas embebidos), vale más conocer C++ o incluso Python que java.
Un saludo,
Bueno, ¿de que os extrañais? Oracle ahora vende maquinas, sistemas operativos y lenguajes. Y ultimamente se ha oido algo acerca de poner ARMs en CPDs porque gastan mucha menos energia y su rendimiento no debe ser mucho menor que un Solaris virtualizado sobre otro Solaris que aloja otra media docena de Solaris virtualizados...
Hoy es ARM y mañana sera Linux sobre Intel/AMD, que le hace competencia a la hora de vender hardware (y tras eso viene el sistema operativo, el soporte... tal vez la base de datos.... una pasta), porque es mas caro formar a los programadores que comprar un hardware distinto y pagar una licencia por el SO. ¿Que podriamos irnos a otro lenguaje para la Web? Pues si, pero ¿a cual? Hacer algo grande en lenguajes de scripts es aventurado* por lo menos. .Net podria ser, pero eso te lleva a un servidor Windows y hay sitios donde eso ni de coña...
Pues eso, que no me extraña y que ¿a cual nos pasamos?
* No es lo mismo PHP que Python, claro, y que no sea "grande" no implica que tenga exito o soporte mucha carga, porque por ejemplo Twitter no parece muy complicado pero tiene un exito enorme, asi que lo de "aventurado" no es despectivo, ojo. Solo contemplo lo que puede pasar cuando te encuentres con algo que paren tres o cuatro docenas de programadores con unos cientos de casos de uso. Cada problema tiene su herramienta.
@choces, insisto en que a mí el benchmark no me parece un micro benchmark midiendo una cosa muy específica. El benchmark consiste en ejecutar Tomcat. Va a haber que hacer operaciones de entrada y salida disco, a la vez, gestión de memoria.... se va a tocar prácticamente todo. El benchmark no tiene por qué ser representativo de todos los posibles escenarios. Pero el benchmark tampoco es "un bucle for multiplicando dos matrices".
Por otro lado, insisto en que dudo mucho que de una versión a otra de la máquina virtual se produzcan 5X incrementa el rendimiento. Hay gente que habla de algo entre un cinco y un 10% al pasar de Java SE 6 a Java SE 7 en Intel x86. Nunca he oído que nadie habla de un incremento de un 500% al pasar de una versión mayor a otra de Java SE.
Lo que para mí esto es demostración indiscutible es que el OpenJDK, al menos en ciertos escenarios (por ejemplo, corriendo sobre ARM/Linux) tiene desventajas significativas respecto a los binarios propietarios de Oracle. Y esto es grave especialmente cuando Oracle está poniendo restricciones/barreras al uso de sus binarios en Linux.
@Abraham
Cuando vea, si es que lo hacen, una comparación entre esa versión embedded de 1.7 que han usado, y un OpenJDK 1.7 tal vez me muera de la risa, o se me quede cara de sorpresa (apuesto por las carcajadas)
Creo que hay pocas dudas de que las VM cerradas, no solo las de Oracle, sino las de IBM, o Azul, entre otras, pueden tener mejores rendimientos que el Hotspot, en algunos procesos. Pero no creo que ese sea el motivo por el que son cerradas, y de pago. Una de las razones principales es que tienen un soporte de cliente que, entre otras ventajas, asegura que bugs o actualizaciones de seguridad lleguen antes al cliente que paga, que al resto de los mortales.
No he llegado a entender del todo el lío que se ha organizado alrededor de esos cambios en la distribución del JDK.
A fin de cuentas, el JRE se seguirá distribuyendo y actualizando como siempre. Y no veo dónde está el problema en que el JDK tenga un punto de distribución único.
@nilojg
¿A cuál nos pasamos?. ¿Por qué hay que pasarse a otro lenguaje?.
Las especificaciones del lenguaje se deciden en el JCP, y su implementación de referencia, OpenJDK, es de código abierto.
Si hay empresas que quieren y pueden hacer su "versión" de la VM, que la hagan. Si hay clientes dispuestos a pagar por ello, a cambio de determinados servicios de valor añadido, como he comentado más arriba, que paguen.
Lo que creo firmemente es que ya que tenemos un Java con Código Abierto, lo que procede es apoyarlo sin reservas, para que siga siendo abierto, y para mejorarlo.
No basta con sentarse a "disfrutar de lo gratuito", creo que también hay que arrimar el hombro.
Los JUG de Brasil y de Londres están mostrando un camino muy claro, y muy decidido.
¿Dónde están los JUG de habla hispana?.
Tampoco lo veo tan raro. Java sobre ARM ha de ser muy optimizable, por algo ciertos procesadores ARM son capaces de entender sin conversion instrucciones JVM!
Ademas en embedded y movil Oracle puede cobrar licencias, pero no en x86. Que no se encuentre la JVM en los repositorios no quiere decir que tengas que pagar por usarla!
Los JIT compilers modernos que usan las VM son extremadamente rápidos; tanto es así que en la mayoría de las aplicaciones, el tiempo efectivo está en torno al 1% de media del total del tiempo de ejecución, decreciendo a medida que la aplicación se ejecuta.
Los bloques de código que se repiten más de un número de iteraciones (ajustable con switches en la VM), se almacenan ya compilados en memoria, por lo que no es necesario recompilarlos de nuevo.
Una VM es, respecto a la ejecución de código nativo, tan eficiente como lo sean sus compiladores JIT, y como lo sea el criterio de almacenamiento de código reiterativo compilado.
Las cuestiones de rendimiento tienen poco que ver en la actualidad con la generación de código nativo, y mucho que ver con la calidad del código fuente Java, y con los Garbage Collectors.
Por eso, los ARM son tan optimizables como cualquier otra plataforma, y creo que Jaselle está en desuso en las versiones modernas de ARM.
Saludos.
Mi humilde opinion, la un iniciado, es que hasta donde se Java aparte de las Api es también la sintaxis del mismo, y cualquier que este en la capacidad puede hacer un MV para java lo puede hacer; existe OpenJDK y alli esta la opcion de seguir usando java como hasta hace un tiempo lo veniamos usando, los expertos puede añadir mejoras; Oracle es ta en su derecho de usar los dinarios que tienen; pero nosotros los que amamos java estamos en la obligacion de generarle continuidad libre de licencias privativas.
Espero no ser un soñador.
Si mal no recuerdo, lo que Oracle dijo que pasaría con la versión 7 u 8 de Java es que fusionarían el llamado OpenJDK con el J2SE y con el JRockit (o mejor dicho, ciertas porciones del JRockit), porque existían 3 versiones a mantener desde el punto de vista de Oracle tras las adquisiciones de la compañía, y que la fusión pasaría a llamarse OpenJDK y a ser la implementación de referencia.
Así que comparar el futuro OpenJDK con los anteriores precindiendo del hecho de que no es sólo OpenJDK no es muy riguroso.
Algo muy distinto es que tengan una versión OpenJDK y una versión comercial J2SE más rápida... Pero eso no lo anunciaron en su momento, aunque es de esperar que sea así.
Personalmente me conformo con que la versión OpenJDK 7 tenga un rendimiento similar a la versión J2SE 6.
Abraham se limita a exponer las dudas razonables
Implementación de Referencia de JavaSE 1.7
http://jdk7.java.net/java-se-7-ri/
"The official Reference Implementations for Java SE 7 (JSR 336) are based solely upon open-source code available from the JDK 7 Project in the OpenJDK Community."
No es un asunto futuro, sino presente.
Otro asunto diferente son:
http://www.oracle.com/us/technologies/java/standard-edition/jrockit/overview/index.html
http://www.oracle.com/us/technologies/java/javase-embedded-345556.html?ssSourceSiteId=ocomes
Ok, leído, yo también aporto la noticia original que leí en su momento:
https://blogs.oracle.com/henrik/entry/jrockit_is_now_free_and
"As previously communicated our strategy is to converge the HotSpot and JRockit JVMs into a single best-of-breed JVM (blog, press release). While most of the work involved in this effort is engineering - taking ideas and features from JRockit and porting them over to OpenJDK - we have also been working on convergence from a licensing perspective".
Básicamente el tema del OpenJDK estriba en que es una implementación de referencia, para proveedores, que ni siquiera recibirá actualizaciones de seguridad, porque no se considera una versión de producción:
"These binaries are provided primarily for use by implementors of the Java SE 7 Platform Specification and are recommended for reference purposes only. The Reference Implementations have been approved by the JCP and will receive no further updates, not even for security issues. Binaries for development and production use will be available from Oracle, from Java SE Licensees, and in most popular Linux distributions".
El problema sigue siendo el de partida, el planteado en la noticia:
"Si tú quieres que tu aplicación Java tenga un rendimiento aceptable tengas que pagar una licencia por una versión propietaria".
Pero yo sigo sin saber qué pasará con la implementación J2SE como se conoce hoy en día. Oracle tendrá la suya, ¿será de pago? Según ellos JRockit se había vuelto gratuito, así que si desarrollan la versión 7, ¿seguirá siendo gratuito?
Yo no usaba la versión J2SE desde que se liberó JRockit, ya que es muy superior al J2SE. Espero que la nueva situación sea similar.
"...el tema del OpenJDK estriba en que es una implementación de referencia, para proveedores, que ni siquiera recibirá actualizaciones de seguridad, porque no se considera una versión de producción"
Perdona, pero las distribuciones actuales de JavaSE 1.7, que se basan en el código fuente de referencia, no son para "proveedores", sino que son el JDK/JRE de siempre, los que se usan tanto para el desarrollo, como para ejecución.
Lo mismo puede decirse del OpenJDK 1.8 en desarrollo.
Lo que significa "implementación de referencia" en este caso, es que es el código fuente que constituye el trunk principal, sobre el que se aplican los JSR nuevos, se corrigen los bugs, se hacen toda clase de modificaciones. Y del que se obtienen los builds que desarrolladores y usuarios descargan como JDK/JRE.
choces, en mi primer comentario no había leído la noticia de publicación del OpenJDK, entre otras cosas nunca me pareció un proyecto serio -lo he probado y daba problemas con muchas aplicaciones gráficas en distintas combinaciones de S.O., arquitecturas...-, yo me remito a lo que dice Oracle sobre sus "hijos". El OpenJDK 1.7 publicado, que es al que hago referencia en la noticia por ellos publicada, primero porque es lo que había leído hacía tiempo y segundo porque es la versión a la que te referiste tú. Todavía no sé qué ha pasado con la versión 1.8, pero me remito también a la intención de OpenJDK:
"The goal of this Project is to to produce an open-source reference implementation of the Java SE 8 Platform, to be defined by JSR 337 in the Java Community Process.".
Una implementación de referencia no tiene por qué convertirse en la implementación específica de un proveedor, sólamente es un producto con un objetivo: que los demás sean compatibles con él. No olvidemos que los bugs de jdk's anteriores -respecto a la especificación-, forzaron la posición de la entonces Sun a adoptar el criterio de: Tú máquina ha de ser compatible con la mía, incluso con mis bugs.
Sigo creyendo que el problema estriba en si Oracle liberará una implementación tan gratuita como lo era hasta hoy la J2SE, o si será de pago, sea JRockit o J2SE en sí misma.
Si tuviese que apostar, apostaría porque se van a librar de mantener dos de las tres distribuciones que tienen:
El OpenJDK quedará como el objetivo que tiene definido, ser implementación de referencia, sin mantenimiento, con la publicación del código fuente y como open source. Ahí se acabará el esfuerzo de Oracle.
El J2SE y el JRockit se fusionarán en uno sólo, y opino que ese será el producto BINARIO gratuito. Es decir, que el código de J2SE+JRockit no será open source, pero sus binarios se podrán utilizar más o menos como hasta ahora. Hasta aquí creo que nada nuevo.
No tiene sentido que yo mantenga tres versiones distintas de un mismo producto cuando esas tres versiones no tienen funcionalidades específicas, son sólo tres maneras distintas de hacer lo mismo. Me estoy perdiendo la posibilidad de hacer un mejor producto con los recursos de las tres versiones. Y eso creo que ha sido la principal motivación de Oracle, al menos desde lo que yo entiendo como racionalidad.
Todos sabemos que Oracle es una empresa con una tremenda vocación de ganar dinero, no es una ONG. Oracle considera a todo el mundo como sus rivales, así que no va a facilitarles la vida.
Además, si admitimos que otras empresas desarrollen sus JDK's alternativos y cobren por ellos, ¿por qué no la propia Oracle? Quizá no sea la mejor estrategia comercial, o quizá sí -no soy economista, ni publicista, ni nada parecido-, pero es una estrategia para ganar dinero como cualquier otra.
Solo por completitud, mencionar que ya publicaron la segunda parte del benchmark:
https://blogs.oracle.com/jtc/entry/part_deux_comparing_jvms_on
Aquí muestran que Abraham tenía razón frente a que la versión del JDK (6 vs 7) no es el que hace la diferencia.
Las dudas de Abraham me parecen completamente razonables, sin embargo no veo problema en que Oracle tengas sus binarios privativos así estuvieran super optimizados para x86 por las siguientes razones:
1) La postura oficial de Oracle, al menos en lo que respecta a Java, se resume en que desean mantener la JVM libre y abierta para siempre (esto se ha evidenciado con hechos, como el de liberar JRockit y estar trabajando en integrarla con HotSpot, es decir que todas estas mejoras las tendremos directamente en OpenJDK).
http://www.java7developer.com/blog/?p=307
http://openjdk.java.net/faq/
2) En el desarrollo de OpenJDK participan muchos miembros además de Oracle, los cuales tienen la posibilidad de hacer implementaciones que compitan con los binarios propietarios de Oracle. Es decir, no está en poder de Oracle evitar la optimización del OpenJDK.
3) IcedTea, de Red Hat, es una de las encarnaciones de OpenJDK más prometedoras. Para empezar no padece de los inconvenientes que tuvo Harmony, puesto que no consiste en una implementación desde cero sino que por el contrario si se basa en OpenJDK, conserva la licencia GPLv2 y su objetivo no es ser embebida en dispositivos móviles, así que no tiene de que preocuparse. A esto sumamos la reciente (marzo de 2012) incorporación de IcedTea (junto con OpenJDK, GNU gcj, GNU classpath/libgcj y otras herramientas Java) a la Open Invention Network (OIN), lo cual vuelve el proyecto inmune a las patentes de software.
http://www.infoworld.com/t/linux/linux-gets-bigger-shield-against-patent-attacks-188156
En resumen, así Oracle tenga sus binarios super optimizados, no veo que limite que nosotros tengamos un IcedTea tanto o más optimizado.