The Former Weblog of Peter Ahé

You can now easily build javac using a new ant build file I added to Mustang in b47. Go to make/sun/javac/ant and type ant to build the compiler. This creates ../../../../build/shared/classes which you can place on the "bootstrap" class path when running javac:

/usr/java/jdk1.6.0/bin/javac -J-Xbootclasspath/p:../../../../build/shared/classes

So far there are only two useful targets:

compile

Compile javac and all clients (javadoc and apt)

clean

Remove any output from the compile target

I use ant version 1.6.5 which comes with NetBeans 4.2

UPDATE: b47 is now available for download.

Earlier today we handed off the feature complete JSR 199 (compiler/tool API) reference implementation to pre-integration testing. Hopefully, this should be in time for Mustang b47.

So far we have been getting a lot of interesting feedback on the Early Draft Release and haven't been able to respond to all of it yet. I plan to address this feedback in the coming weeks but will also be travelling in Europe which might interfere with that plan.

We are planning to make -target 6 the default target of javac in Mustang Beta and intend to keep this default for the final version (subject to feedback). See RFE number 6283313. Obviously, this only affects what version is generated by javac if you don't use the -target option at all. Similarly, it should be obvious that the best-practice is to use the -target option explicitly when developing on newer JDK than the target platform.

This means that javac will generate class file version 50. This version is being defined as part of JSR 202. Most importantly, the class file format will contain a new attribute called StackMapTable which is used by the new verifier. A Java™ compiler, such as javac, uses the StackMapTable to record type information that was previously inferred by the old verifier. This greatly simplifies the verifier and improves performance of byte code verification.

This should have no impact on most Java developers, however, tool vendors using byte code instrumentation for purposes like profiling and logging, should pay attention to this new attribute. When byte codes are injected into existing methods, the StackMapTable attribute becomes invalid and should be updated. However, in order to allow such tools to operate unmodified on class file version 50, the VM can (optionally) fall-back to the old verifier. However, in the long run this will not be feasible.

Also, running a faster verifier (the new one) before falling back to the slower (the old one) doesn't yield optimal performance.

I have already touched on the reasons for this change in verification but let me summarize the motivation for the new verification scheme:

• Simplicity of the scheme leads to improved reliability and robustness
• Performance improvements in byte code verification and thus class loading and start up time
• More verifier technology sharing between Java SE and Java ME benefiting both platforms

A note on terminology: this scheme is often referred to as split-verification or pre-verification. However, this terminology is confusing as the compiler doesn't verify anything, it just records the information it has (which might be corrupt). Similarly, "pre-verifier" is not a good name for a tool which can infer StackMapTable attributes for old class files. This is because the name implies that some verification have been performed. However, inferring types does not imply that they are valid or that the byte codes can be verified. Better names for a tool which infers types for StackMapTable attributes include: "stack map table inferencer", "stack map table generator", etc. Better names for the new verifier includes: "new verifier", "type checking verifier", etc. The old verifier can be called "old verifier", "type inferencing verifier", etc.

UPDATE: My colleague, Wei Tao, has written an execellent article about the new verifer

If you want javac to run faster, here are a few options you might want to try:

-J-client Select the "client" VM aka HotSpot c1 compiler (that is, bytecode-to-native compiler, not a Java compiler). The server compiler's more aggressive approach to compilation is not beneficial for javac, see bug 5023037.

-J-XmsNNNm -J-XmxMMMm Use more memory :-) This will reduce the amount of time spent on collecting garbage (reclaiming unused memory). You need to be careful about this: if you specify too high a number the program will be paging and that will hurt performance. Let's say you have 512Mb RAM, then you should be able to see better javac performance by using this combination: -J-Xms100m -J-Xmx100m. Also you might want to experiment with -J-XX:NewSize=NNNm, for example: -J-XX:NewSize=30m. This number should be a fraction of the total heap size.

-g:none This will not generate debug information which will reduce the size of the class files and thus javac will be able to write them faster to disk. But I can't really recommend not having debugging information enabled.

-classpath Only list the jar files and directories you need for your compilation. The longer the class path, the more files javac will have to read even to compile the smallest program.

In addition to all these advices, I'm soon integrating some changes to Mustang to reduce compile time (and expect to backport it to Tiger). Please see bug 6186747.

The endorsed standards override mechanism allows you to upgrade any part of your JDK as you please. For example, if you wanted to use the Mustang javac in JDK 5.0, create a jar file with all the com.sun.tools.javac... packages and use the -J-Djava.endorsed.dirs javac option.

Expect to see some changes in the diagnostics produced by javac in the b27 Mustang snapshot (next week, I think). We finally integrated some changes needed by IDEs to get better positions. This might look as an insignificant internal change, but at the same time the position information was revamped. Hopefully, error messages should be much easier to understand. For example:

Test.java:9: warning: [deprecation] cSharp() in DotNet has been deprecated
        this.basura.cSharp();
        ^

compared to this:

Test.java:9: warning: [deprecation] cSharp() in DotNet has been deprecated
        this.basura.cSharp();
                   ^

We're very interested in hearing about any positions that can be improved. I'm grateful for Tom Ball and Michael Van de Vanter making this huge contribution.

For the next build (b29, we skip every other build) we have lined up a treat for those concerned about warnings (who isn't). Jon completed the support for @SuppressWarnings. Way to go!

Also, I hope the fast-jar-indexing performance enhancement will make it into b29.