7

In .Net, you can specifically compile your projects under "Debug" or "Release" settings, Release having more optimizations. I know that this is deemed unnecessary in Java, because the jitter does these optimizations. What is the reason for the difference? (meaning, why is a pre-"jitter" compilation required/helpful)

Why is it deemed necessary in .Net/CLR, but not in Java/JDK?

ripper234
  • 222,824
  • 274
  • 634
  • 905

4 Answers4

4

Earlier Java compilers had an -O flag to enable (source code) compilation optimizations. Since JDK 1.2, the -O flag had no effect and I believe the flag was removed with JDK 1.4. As the Java runtime improved, it probably turned more and more reasonable to delegate the optimization to the JRE, since the source code compiler has absolutely no knowledge about the hardware, which will eventually execute the code.

Articles like this one and the documentation of the csc /optimize flag indicate that the optimization has very little effect (if any at all?) on the actual generation of the CLR code. The /optimize flag does however set a flag in the compiled assembly, which controls the level of optimization allowed to be applied by the runtime. I haven't tried it, but I"ve read that runtime optimized code is not necessarily debuggable, although debug information is included (the /optimize and /debug flags can be enabled or disabled independently for the C# compiler).

Ι don't really see the point in controlling the runtime optimization level at compile time. The Java runtime has several detailed options to control runtime performance and optimization, but these must be defined when starting the JRE and not at compile time.

jarnbjo
  • 33,923
  • 7
  • 70
  • 94
4

Sun's javac compiler does have the concept of debugging information which can be (optionally) omitted from the compiled class output.

Look at the documentation, and check out the -g flag options:

-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

These are perhaps not quite as extensive as the bytecode optimisations the .NET compilers might perform (which I'm not familiar with, sorry), but I think in theory they are there for performance reasons (smaller classfiles, etc).

In practise I strongly suspect they wouldn't make much difference to runtime performance on modern hardwares + JVMs, but they are there.

Cowan
  • 37,227
  • 11
  • 66
  • 65
3

I think they can easily be introduced in Java. Basically Debug build means: Include debug symbols and disable optimization. Release is vice versa. Debug and Release targets are generated by Visual Studio and are not mandatory. You can write your MSBuild script without VS. So you can create build script for Java with Debug and Release targets.

Joey
  • 344,408
  • 85
  • 689
  • 683
Andrey
  • 59,039
  • 12
  • 119
  • 163
  • In .Net, if you use a Release Build, your own code is not easily debuggable. In Java, there isn't such a problem. – ripper234 Jan 19 '11 at 11:54
  • 1
    @ripper234 this is how Java and .net work. Release/Debug build are just collection of compiler switches. nothing magical behind them – Andrey Jan 19 '11 at 12:20
0

http://blogs.msdn.com/b/ericlippert/archive/2009/06/11/what-does-the-optimize-switch-do.aspx has a nice list of optimisations that are performed when the optimize switch is on (it's on for release, off for debug).

The Java compiler could also do any of these, and it might do some of them by default anyway. They're mostly small wins.

ICR
  • 13,896
  • 4
  • 50
  • 78