看到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走下去(不明白？ 比喻只能自己一個孤獨的走下去？)