Bueno, tampoco habría tanta ventaja. El compilador de java pasa a bytecode de la máquina java el código y después la máquina java va traduciendo el código máquina de la máquina virtual al código máquina del procesador. Toda una historia muy larga. Y el trabajo este se realiza cada vez que se ejecuta un java. No sé si hace como .NET que traduce al momento y al mismo tiempo guarda en caché las instrucciones en IL para una próxima ejecución más rápida.
En cámbio C, normalmente, lo traduce todo a ensamblador y el linker a código máquina. Esto unido a que tiene un entorno de ejecución pequeño es lo que lo convierte en un lenguaje rápido, pero a la vez inseguro porque su entorno de ejecución hace muy poco para el programador.

Lo que pides es imposible. Es contradictorio. Cada tipo de CPU tiene una arquitectura, es imposible crear un código máquina o un código ensamblador que sirva para todos los tipos de CPU. No obstante, no es tanto que Java sea lento (aunque lo sea un poco más que C/C++), sino que los programadores en más alto nivel no suelen optimizar a más bajo nivel. No estoy diciendo que los programadores que programan en más alto nivel sean peores programando, sino que no se fijan en los detalles en los que se fija un programador en C/C++.

Te explico, Java es más lento que C++, no tanto porque sea un lenguaje interpretado, sino que con el fin de ahorrarles tiempo y disgustos a los programadores, hace muchas comprobaciones de memoria o otras cosas para ver que todo ha ido bien en una instrucción, para que el programa no crashee. Por ejemplo, cuando reservamos memoria dinámica en C/C++ tenemos que tener muchísimo cuidado mientras que en Java, si se produce algún error en la memoria dinámica, directamente el programa lo detecta y se actúa según el error. En C++ tenemos la opción de hacer esas comprobaciones, o no porque estemos seguros de que no van a fallar!! Otro error común en C++ es acceder a lugares de la memoria que no nos pertenece...

Espero haber aclarado el tema