gdb java_用GDB 调试Java程序

陈皓

http://blog.csdn.net/haoel

背景

想要使用GDB调试程序，就需要用GNU的编译器编译程序。如：用GCC编译的C/C++的程序，才能用GDB调试。对于Java程序也是一样的，如果想要用GDB调试，那么就需要用GNU的Java编译器——GCJ来编译Java程序。

目前，很多Linux都不会预装Sun的JVM，取而代之是使用GNU的开源编译器来编译和运行Java程序。比如RedHat和Ubuntu，其默认安装都是使用GNU的Java编译器(gcj)和解释器(gij)。当然，它们都被脚本javac和java包装了起来，你一不小心还以为是使用了Sun的JVM。

为什么GNU要搞出一个Java的编译和解释器来呢？其大致有以下几点：

a)传统的JVM太慢了，因为它解释的是class文件中的bytecode。这种方法实在是太慢了。

b)为了优化性能，引入了JIT(Just-In-Time)，JIT会分析代码，找出那些被反复调用到一定次数的方法和函数，然后直接把这个方法直接处理成汇编machine code，以后就直接运行机器码了。

c)当然，JIT也有问题，一个是startup overhead，就是说启动的时候有点过分了，表现为时间慢，并且，每次编译后，都需要JIT重新做来过。另一个问题是JIT比较耗费空间。

d)传统的java还有一个比较扯的问题，就是布署起来太麻烦了，需要有N个jar文件，而不是一个可执行文件。并且，Java需要一个很肥大的运行环境。另外，在java和c/c++之间的调用慢得令人受不了。

GNU的Java编译器GCJ

上述的东西是催生出现gcj的原因，GNU用了Ahead-of-Time Compilation来形容GCJ。GNU对GCJ的出现在理由做了下面的说明：

a)      GCC本来可以编译多种程序语言，所以，把java整进来也是一件make sense(合乎逻辑)的事情。

b)      Java的编译是一件非常简单的事情，因为没有C++的模板和预编译器，而且system type, object model和exception handling也很简单。所以，这对于擅长编译技术的GNU来说，从编译方面优化Java的性能是一些很简单的事。

c)      gcj会对java程序做N多的优化工作，比如：common sub-expression elimination, strength reduction, loop optimization和register allocation。在优化方面，是GCJ牛还是JIT牛，存在一些较大的争论。对于JIT来说，它可以裁剪和做适时优化，因为是在运行时。Sun的HotSpot技术是其中比较牛的技术，但gcj的技术也不一定就比JIT差。

d)对于使用gcj的人来说，最大的一个好处就是startup speed和内存空间使用率。启动JVM或JIT会肖耗很大的内存，例如：NetBean启动就需要74M的内存(什么事也没有干)，JEmacs使用Swing，一启动就是26M，而XEmacs只有8M(这些数据是比较老的了，大约在2003年的数据)。

e)当G