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.
Fastdebug jdk 包含一个fastdebug版本的jvm和库，生成的class文件使用javac -g生成，所以jar文件(rt.jar tools.jar)包含所有的java本地变量信息。库和执行文件是通过-g和-O参数编译出来的，包含所以的断言和debug检查信息。所以使用faredebug版本可能提供一些生产版本不会得到的信息。他也会更慢一些，但不会想debug版本那么慢。优化不会像生产版本那么全面，但是由于断言和debug代码的存在 他们的代码是不同的(不明白什么意思)。在windows下 "/D _DEBUG" 和"/MDd" 被/MD"替换，换句话说debug的运行时库msvcrtD.dll没有使用到。
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.
Crash和core dump更有价值，stack trace包含更多信息。Debug符号还没有从组件中剥离，还可能得到windows的*pdb文件。（不懂）
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.