@
sztimhdd 在我看到您发的这两个问题时，『当时就震惊了』。确实是很有挑战性。
首先，对于这第二个问题，如果是面向 Stack Overflow 编程的话，一开始就找到了[解决办法](
http://stackoverflow.com/questions/37939455/why-does-the-value-of-typeof-null-change-inside-a-loop) 。
但我觉得您的目的不应止于此，所以决定搞一套 V8 的环境看看到底是怎么回事。
搞 V8 环境着实花费了我不少精力。你懂的，在国内的优越的网络环境下，我的小梯子经常断线，然后从头开始。
因为我能力和精力有限，下面只把我瞎猜的几个点列一下吧。
1. 这个 bug 发生在 V8 的 Just In Time 优化编译模块；
2. V8 的 JIT 优化是在中断处理中被触发的：
1. 主中断处理函数调用 StackGuard 的中断处理函数；
2. 运行时性能检测模块（ RuntimeProfiler ）被上述中断处理函数调用，以标记候选优化对象；
3. RuntimeProfiler 会根据函数在栈上出现的次数以及预设的门槛来判断是否应该对其进行优化；
4. 题中的代码因『 hot and stable 』被标记为需要优化；
5. 把优化任务塞入优化队列，有另外的优化线程进行重新编译、优化（这也应该是 bug 出现的时机不定的原因）；
3. 在优化过程中，目前是由 Crankshaft 模块完成具体的优化编译任务。它是 V8 专门负责优化的编译器。
1. 在优化过程中，有一步是对不可达代码块进行优化；
2. 在不可达代码的判断中，有一个条件是对常量进行 typeof 操作；
3. 现在终于来到了出现 bug 的 TypeOfString 函数；
4. 该函数中由于提前对常量判断了 IsUndetectable 导致忽略了对 null 的特殊处理，而错误地返回了 『 undefined 』。
上面基本上是跟踪调用栈的结果，比较枯燥。并且因为代码量比较大，很多地方并没有完全衔接上。
我一直觉得，如果想真正了解某一事物，从它发生的历史角度去发掘会更有意识、更深刻。
所以，强烈推荐推荐一下[这篇文章](
http://www.cnblogs.com/ziyunfei/p/5618152.html)。至此，我对第二个问题的研究就告一段落了。
其次，对第一个问题，由于我从未接触过相关内容，并且看样子 ANTLR 涉及的东西会很多，所以我就不献丑了。
但确实引起了我的兴趣^_^。