主题：【原创】漫谈浏览器大战 -- （构架篇） -- Highway

1. 漫谈浏览器大战 -- 构架篇

=========================================

看到JavaScript，人们的第一个反应就是“这丫是Java的表弟还是连襟，是亲戚吗？”

事实上，JavaScript和Java既不沾亲也不带故，纯粹是当初市场运作的产物。JavaScript的原名是LiveScript，是当年的NetScape推出的（1995年）。当时Netscape在跟微软死磕，Sun呢也再跟MS在掐架。基于“敌人的敌人就是朋友”的原则，NetScape和Sun联手了，歃血之后，Sun允许NetScape把那玩意叫JavaScript，NetScape呢同意在Navigator浏览器中带上Sun的Java。

没过多久NetScape就黄了，但是JavaScript却保留下来了。成了Web编程Client端使用最广泛的一种语言。（当时微软也搞了俩类似的东西叫JScript和VBScript跟在里面搅）。

虽然JavaScript的足迹那儿那儿都是，但它始终是个敲边鼓跑龙套的，没人把它当颗葱。所以找网页编程的工作，会ASP/ASP.NET成，会JSP/Serverlet成，会JavaScript就不灵了。

真正把JavaScript开脸扶正，带入厅堂的是Google。这也是风云际会时事使然。

Google的霸权战略思想很简单，就是把所有的东西都挪到网上来。所以Google一直在不遗余力的鼓吹操作系统压根不重要，桌面应用也过时候了，浏览器+Web App才是人心所向大势所趋。你的数据都放在天上（Cloud），你的应用都从天而降（Download），一开浏览器什么烦恼就都没了。。。

把这个概念推销给亿万人民群众有一个问题，那就是WebApp要和现在的桌面应用有得一比。功能要相同，性能要相似，如果不是更快的话。

Google干的很玩命，也真用JavaScript写出了一些以前别人不敢想的东西。但是越往大写，JavaScript的问题就越显得明显，那就是 -- 太慢！

JavaScript是解释性语言，不像编译型语言那样是在CPU硬件上跑，而是在Interpreter软件里面跑，也就是由一个软件来执行你的软件。所以为了完成一统网络的大任，Google必须解决这个JavaScript的性能问题。于是Google就纠集了一帮人马，准备把这个JavaScript重新来过。Google的这个班子在丹麦，这个项目的代号是"V8".

问题的关键是JavaScript是一个高度动态的语言，是Prototype-based的语言，Object的Properties的Get/Set操作以及函数调用都是现场动态查找（在HashMap里面不停的找）。如果JavaScript能像Java那样有个Class就好办了。每个Properties和函数的地址就是敲定的了，不用一次次的在HashMap里找了。

V8的一个创新之处就是引入一个"Hidden class"的概念，也就是在执行JavaScript的时候，悄悄的创建一个个的hidden class。以后的对象呢，想办法往hidden class上套，如果对上了，那么JavaScript就好象是static typed的语言了，譬如说Java。

虽然JavaScript是一个高度动态的，但实践中他们发现90%的object还是有pattern的，所以Hidden class派上用场的机会极大。那些套不上的只是少数，那点性能损失认了也罢。

我认为Hidden class这个东西盘活了JavaScript。因为它使JavaScript变得像Java了。这个桥梁一旦建立起来，那么Java这么多年在程序优化上面的东西就不是就可以“借鉴”了吗？

事实上，Google从Sun挖了好多人，它现在的执行总裁Eric Schmidt就是原先Sun搞Java出身的，另外Java的大拿Josh Bloch也被Google挖去了。所以JavaScript一旦通过Hidden Class和Java搭上桥，那剩下的事情就好办了。

如果你留心一下V8（最新的版本叫做Crankshaft）的主要Feature，那它和和Java的关系就一目了然了。

1. 一个简单但是快速的编译器（借用的WebKit的）把JavaScript先编译成机器代码，这一步不要求什么优化，但是要快，延迟要越小越好（Java不太一样，一开始是不编译的，而是解释执行）

2. 一边运行，一边profiling，发现热点程序段。（注意，从现在开始，以下部分就和Java的HotSpot VM原理一模一样了）

3. 对"热点"程序段进行重新编译，这次要结合现有的Profile知识并用一切可能的优化手段重新生成机器代码（（譬如loop-invariant code motion, linear-scan register allocation and inlining）），并且允许根据现有知识进行一些猜测。

4. 如果第三步优化的程序在后面遇到了新的情况无法handle了，那么扔掉优化程序，按第一步产生的“笨”code来执行，以保证正确性。

5. Heap管理采用和Java一样的Generational heap。分为Young和Old两代。年轻的一代Heap要时不时的clean，而老一代呢，则尽量不动，如果需要动的时候，也要根据情况决定是大动还是小动（就是Clean完Garbage以后要不要compact heap），尽可能的减少执行的停顿。

6. 为了加速JavaScipt VM的启动速度，将一个标准的Heap镜像存放到文件中。这样当一个新的JS VM启动的时候，直接load现成的那个镜像文件，而不用将那些基本的JavaScript Library Load进来，从Hidden class那里再从头做起（Chrome的JavaScript库函数也都是JavaScript写的）。大家可能觉得这个feature似曾相识。对喽，，这个就是Java的Class Data Sharing(CDS)的JS版。

当然了，除了这些，Google还在其它方面下了些功夫。比如改写了很多以前的Library,重新设计和编写了了JavaScript的Regular Expression部分。经过这一系列的努力，新一代的JavaScript比原先的JS有了质的飞跃，速度要快10-20倍左右。士别三日，真是得刮目相看了。

Google在忙活的时候，别人也没闲着。FF阵营的人也对JavaScipt下了很大气力。他们的项目代码很有趣，叫做SpiderMonkey，TraceMonkey,JaegerMonkey。。。不知道什么时候能用上我们的“金丝猴”。

一开始，FF使用的是Tracing JIT，而不是Method-based JIT。也就是说它不是见到一个Method就给它JIT成机器码（Just-in-time Compile），而是先解释执行并跟踪其动向。如果发现某段程序Hot，那么再编译。也就是说，FF的JavaScript更像是Java的做法。

但是呢，这种做法呢在实践中有一些问题，就是在解释执行和编译执行这两种状态之间切换的时候很不平滑，问题较多。所以呢，新一代的JaegerMonkey也变成Method-based的JIT了。上来就先编译，然后接着跟踪，遇到热点再进行二次编译。

IE呢，在这个问题上动手最晚，功夫下的也不是很够。IE9的JS比以前是快了很多，但和Chrome一比，差距还是很明显的。运行SunSpider测试程序还行，当我运行Kraken benchmark程序的时候，Chrome和FF都很顺利的完成了，而IE几乎死掉。恨不得过了100万年才完成，

从.NET 1.0开始，微软的VM (叫做Rumtime)就是Method-based JIT。在第一次碰到函数的时候将他编译成机器代码（你可以使用nGen将MSIL预编译成机器码），之后就一直使用这机器码，不再做任何优化了。事实上，Java和.NET的VM在程序执行一段时间以后，有无穷多的信息，可以做出C++做梦都不敢想的优化来。可惜啊。微软从来没在这个领域有任何举动，令人扼腕。

从理论上讲，Managed code (Java，C#这一类）性能上可以超过传统意义上Unmanaged code的，因为那些语言只能作静态优化，而Java和.NET呢，可以在运行时根据程序运行的具体情况作出新的优化，比如inline virtual function，这是C++永远做不到的。

既然微软在.NET的主战场上都没能有二次优化的能力，那么我认为它在JavaScript的战场上也不可能胜过Google甚至是FF。我看过微软搞IE9负责人的几个专访节目，从口气里听出他们已经怯阵了。他们反复强调不要只盯着JS一个方面看，要注意浏览器的其他方方面面给用户带来的综合感受云云，最后挺了半天算是来了句硬话 -- 到IE9正式发布的时候，我们JS的性能一定和对手们“可比”。世界头号软件巨头居然如此窝囊，可叹啊！！！

============================

（待续）

• 【原创】漫谈浏览器大战 -- （硬件加速篇）