¿Por qué hay compilaciones de depuración y liberación para .Net, pero no para Java?

Question

En .Net, puede compilar específicamente sus proyectos en las configuraciones "Depurar" o "Liberar", liberando más optimizaciones. Sé que esto se considera innecesario en Java, porque el jitter hace estas optimizaciones. ¿Cuál es el motivo de la diferencia? (es decir, ¿por qué es necesaria una compilación previa de "jitter"/útil)

¿Por qué se considera necesario en .Net/CLR, pero no en Java/JDK?

Answer 1

Creo que se pueden introducir fácilmente en Java. Básicamente construcción de depuración significa: Incluir símbolos de depuración y deshabilitar la optimización. La versión es viceversa Los objetivos de depuración y liberación son generados por Visual Studio y no son obligatorios. Puede escribir su script MSBuild sin VS. Por lo tanto, puede crear un script de compilación para Java con los objetivos de depuración y liberación.

Answer 2

Los compiladores anteriores de Java tenían un indicador -O para habilitar (código fuente) las optimizaciones de compilación. Desde JDK 1.2, la bandera -O no tuvo ningún efecto y creo que la bandera se eliminó con JDK 1.4. A medida que el tiempo de ejecución de Java mejoró, probablemente se volvió cada vez más razonable delegar la optimización en el JRE, ya que el compilador del código fuente no tiene absolutamente ningún conocimiento sobre el hardware, que eventualmente ejecutará el código.

Los artículos como this one y documentation of the csc /optimize flag indican que la optimización tiene muy poco efecto (¿o ninguno?) En la generación real del código CLR. Sin embargo, el distintivo/optimize establece un indicador en el ensamblado compilado, que controla el nivel de optimización permitido por el tiempo de ejecución. No lo he probado, pero he leído que el código optimizado en tiempo de ejecución no es necesariamente depurable, aunque se incluye información de depuración (los indicadores/optimize y/debug se pueden habilitar o deshabilitar independientemente para el compilador C#)

Ι Realmente no veo el punto de controlar el nivel de optimización de tiempo de ejecución en tiempo de compilación. El tiempo de ejecución de Java tiene varios detailed options para controlar el rendimiento y la optimización del tiempo de ejecución, pero estos deben definirse al iniciar el JRE y no en tiempo de compilación

Answer 3

El compilador javac de Sun tiene tienen el concepto de información de depuración que se puede (opcionalmente) omitir de la salida de clase compilada.

Mira the documentation, y echa un vistazo a las opciones -g bandera:

-g 
    Generate all debugging information, including local 
    variables. By default, only line number and source 
    file information is generated. 
-g:none 
    Do not generate any debugging information. 
-g:{keyword list} 
    Generate only some kinds of debugging information, 
    specified by a comma separated list of keywords. 
    Valid keywords are: 
    source 
     Source file debugging information 
    lines 
     Line number debugging information 
    vars 
     Local variable debugging information 

Estos son quizás no tan extensa como las optimizaciones de código de bytes los compiladores .NET pudieran realizar (que no estoy familiarizado, lo siento) , pero creo que en teoría están ahí por razones de rendimiento (archivos de clase más pequeños, etc.).

En la práctica, sospecho que no representarían una gran diferencia en el rendimiento del tiempo de ejecución en hardware moderno + JVM, pero están ahí.

Answer 4

http://blogs.msdn.com/b/ericlippert/archive/2009/06/11/what-does-the-optimize-switch-do.aspx tiene una buena lista de optimizaciones que se realizan cuando el conmutador de optimización está activado (está habilitado para el lanzamiento, desactivado para la depuración).

El compilador de Java también podría hacer cualquiera de estos, y podría hacer algunos de ellos por defecto de todos modos. En su mayoría son pequeñas ganancias.