Mustang JDK 6.0 Fastdebug Builds

Mustang JDK 6.0 Fastdebug Builds

Ok, what the heck is a JDK fastdebug build?

First, let's tell you what it isn't.

    It is not a product build. And it's not a fully tested build, and probably never will be fully tested. The product builds are what you have seen provided in the past, and they have been or will be before the FCS, fully tested and qualified. A product build is probably what you run today when you run 'java'.

    It is not a debug build. There used to be a version of java called 'java_g', which was the java debug version. All the native code was compiled with the native compiler -g flag, and all assert and debug checking was enabled. In most cases the debug build was completely unoptimized code. Consequently it ran horribly slow. The debug java builds (or java_g's) were never fully tested and at some point in the past they stopped making them publicly available. Historically the java class files were often the same between debug and product builds.

So what is it?

    The fastdebug JDK build contains a fastdebug build VM and libraries, plus class files compiled with 'javac -g' so that all java local variable information should be in the jar files (rt.jar, tools.jar, etc.). The libraries and executables of a fastdebug build are built with both -g and -O compiler options and also contain all the assert checking and internal debug checking code of the libraries. So using a fastdebug build might provide some information you wouldn't get from running a product build. It is slower, but no where near as slow as a debug build. The optimization isn't as high as with the product build, but since the assert checking and debug code exists in these builds, the code isn't the same anyway. On Windows the flags "/D _DEBUG" and "/MDd" were replaced with just "/MD", in other words the debug runtime library msvcrtD.dll is NOT used or needed.

So what's it good for?

    They are much faster than the old java_g. All the files are named the same as the product builds (completely separate install tree), so it's easy to point a test script at this fastdebug JDK home directory instead of the product home directory. In addition you can actually just take one fastdebug component, say libjvm.so, and displace a product installation with just that one fastdebug component. They mix&match, allowing you to focus in on the component of interest.

      The Hotspot VM team has been doing these fastdebug builds for ages, so I can't take credit for the idea.
    Crashes or core dumps (I hope this isn't happening too often for people) should be more valuable and stack traces should contain more information. The debugging symbols have not been stripped from these fastdebug components and the Windows \*.pdb files should be available.

Why not just make java_g a fastdebug version or create a java_fg?

    The java_g convention was a nightmare. The '_g' suffix convention was scattered all over the place, and it was almost impossible to maintain. In addition, it was hard to test because it was a different name, testing scripts had to change their use of 'java' to 'java_g'. The build process was also doubly complicated due to the two different JDK's being built that lived in the same JDK install tree. It was also horribly slow being a debug build and unoptimized. Internally we couldn't use a '_g' library or executable as a displacement for a product version, e.g. we couldn't mix and match different built components. The '_g' name is baked into the library and just re-naming files often got you in more trouble than it was worth. The java_g convention had to go, and it's gone in Mustang.

Comments:

Post a Comment:
Comments are closed for this entry.
About

Various blogs on JDK development procedures, including building, build infrastructure, testing, and source maintenance.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today