看到java大牛们的文章，各种不明觉厉。他们用一种叫fastdebug的jdk，好奇gooole一下，找到一篇仍然不明觉厉的英文说明。话说冰冻三尺非一日之寒，慢慢积累吧，翻译一下。

Ok, what the heck is a JDK fastdebug build?

Fastdebug到底是什么

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'.

他不是生产版本，不是一个完全测试的版本，很可能永远不会完全测试。生产版本是我们看到的在发布前完全测试合格的，是我们日常执行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.

他也不是debug版本。过去曾经有个java命令叫java_g，是java的debug版本。本地代码使用本地编译器加-g参数，加入了断言和debug信息。大多数情况下debug版本是完全没有优化的，导致他极为缓慢。Debug版本也不会完全测试，过去有段时间停止了公众下载。Debug和product版本编译生成的Java class文件通常是一样的。

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.

比debug版本更快。所有的文件名字与生产版本相同。可以将测试脚本从生产版本的目录建单的切换到faredebug版本的home目录。可以简单的使用fastdebug版本的库 比如说libjvm.so替换生产版本的文件，注重感兴趣的组件。

The Hotspot VM team has been doing these fastdebug builds for ages, so I can't take credit for the idea.

Hotspot vm团队好多年都这么干了，在下不敢居功。

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?

为什么不对java_g做一个fastdebug的版本，或者创建一个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.

Java_g的惯例就一场噩梦，_g词尾分散到各处，几乎不可维护，难于测试，因为他的名字不同(文件名?)，测试脚本需要把java改为java_g。构建过程也会双倍延长，因为需要构建两种jdk，因为他们的目录树不同，debug版本太慢没有优化。我们不能在内部使用_g库或执行文件替换生产版本，_g名称被加到了文件名中，重命名文件带来更多麻烦，不一定值得。Java_g惯例不得不走下去，但是他只能在Mugtang走下去(不明白？ 比喻只能自己一个孤独的走下去？)