性能文章>认识HotSpot虚拟机第1篇-在Ubuntu 16.04上编译OpenJDK8的源代码(配视频)>

认识HotSpot虚拟机第1篇-在Ubuntu 16.04上编译OpenJDK8的源代码(配视频)原创

https://a.perfma.net/img/2382850
1年前
709404

本文将详细介绍在Ubuntu16.04 LTS上对OpenJDK8进行编译,为了方便大家快速搭建起OpenJDK8的调试开发环境,我还录制了对应的视频放到了B站上,大家可以参考。

视频地址:https://space.bilibili.com/27533329

下面我们开始环境的搭建过程。

1、准备编译环境

使用的操作系统为Ubuntu16.04 LTS(LTS:Long Term Support,长期演进版,Ubuntu会对这一版本的支持时间更长。目前Java也在运用这种方式),如果读者没有安装Ubuntu,可以在Windows上使用虚拟机的方式进行安装,或者可以直接在电脑上安装多系统,这种方式比以虚拟机安装的方式速度要快。Ubuntu操作系统使用的是Linux内核,由于HotSpot是由C++编写的,所以在编译时需要Linux的编译器GCC。

2、下载源代码

OpenJDK使用的代码管理工具为Mercurial(hg),下载并安装Mercurial后就可以通过hg clone命令获取OpenJDK8的源代码了,相关的命令如下:

hg clone http://hg.openjdk.java.net/jdk8/jdk8 openjdk
cd openjdk
bash ./get_source.sh

使用Mercurial下载时速度相对较慢,可以直接去相关网站上下载压缩包,网址为:http://download.java.net/openjdk/jdk8
笔者下载的压缩包为openjdk-8-src-b132-03_mar_2014.zip,使用如下命令对压缩包进行解压:

unzip openjdk-8-src-b132-03_mar_2014.zip

解压后openjdk目录下重要的目录如下表所示。
image.png

3、编译源代码

openjdk中的README-builds.html网页提供了编译源代码的相关说明。在Ubuntu操作系统下编译可以分为两步:

第一步,生成编译配置的脚本

生成编译配置的脚本使用的命令如下:

bash ./configure  \
--with-target-bits=64 \
--with-boot-jdk=/home/mazhi/workspace/jdk1.7.0_72/ \
--with-debug-level=slowdebug \
--enable-debug-symbols ZIP_DEBUGINFO_FILES=0

运行这个命令对编译的openjdk所需要的依赖进行检查,如果终止,可根据对应的提示安装相关的依赖。命令行选项–with-target-bits指定编译64位系统的JDK; 命令行选项–with-boot-jdk指定引导JDK所在目录,以防其他安装的JDK影响。构建JDK8需要使用JDK7 Update 7或更高版本的版本作为引导JDK,但不应使用JDK8作为引导JDK;命令行选项–with-debug-level=slowdebug,有这个选项,可以在GDB等代码调试过程中提供足够的信息;–enable-debug-symbols ZIP_DEBUGINFO_FILES=0生成调试的符号信息,并且不压缩。

在命令运行过程中,可能会提示运行如下的命令安装依赖包:

sudo apt-get install libX11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev

这个提示中,有个包的名称错误,我们需要将如上命令中libX11-dev包名改为libx11-dev。

如果命令运行成功,会在当前目录下生成一个目录,目录的名称是根据要编译的目标确定的,如笔者Ubuntu 64位操作系统下生成的目录名为linux-x86_64-normal-server-slowdebug。

第二步,编译

编译使用的命令如下:

make all ZIP_DEBUGINFO_FILES=0   DISABLE_HOTSPOT_OS_VERSION_CHECK=ok

如果命令运行成功,则成功编译出了JDK。运行如下命令:

./build/linux-x86_64-normal-server-slowdebug/jdk/bin/java -version

输出的信息如下:

openjdk version "1.8.0-internal-debug"
OpenJDK Runtime Environment (build 1.8.0-internal-debug-mazhi_2019_08_12_20_52-b00)
OpenJDK 64-Bit Server VM (build 25.0-b70-debug, mixed mode)

在openjdk下创建一个Test.java源文件,内容如下:

public class Test{
     public static void main(String[] args){
        System.out.println("Hello World!");
     }
}

通过Javac编译器编译如上的源代码,得到Test.class文件。

运行如上的Class文件,命令如下:

./build/linux-x86_64-normal-server-slowdebug/jdk/bin/javac Test.java
./build/linux-x86_64-normal-server-slowdebug/jdk/bin/java Test

输出如下的信息:

Hello World!
在编译的时候可能会出现如下3个问题:

(1)OS版本不支持

报错摘要如下:

/home/mazhi/workspace/openjdk8/hotspot/make/linux/Makefile:234: recipe for target 'check_os_version' failed

解决办法:
修改文件 ./hotspot/make/linux/Makefile。修改228行内容:

SUPPORTED_OS_VERSION = 2.4% 2.5% 2.6% 2.7% 

SUPPORTED_OS_VERSION = 2.4% 2.5% 2.6% 2.7% 3% 4%

在执行make命令时最好也添加参数DISABLE_HOTSPOT_OS_VERSION_CHECK=ok。

(2)参数不兼容

错误摘要如下:
recipe for target ‘ad_stuff’ failed
解决办法如下:
修改文件 ./hotspot/make/linux/makefiles/adjust-mflags.sh
删除第67行:

s/-([^][^]*)j/-1-j/

(3)部分Eclipse C++版本无法打断点
更换Eclipse版本

搭建过程中如果有问题可直接评论留言或加作者微信mazhimazh。

作者持续维护的个人博客classloading.com

请先登录,再评论

暂无回复,快来写下第一个回复吧~

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
谨防JDK8重复类定义造成的内存泄漏
概述 如今JDK8成了主流,大家都紧锣密鼓地进行着升级,享受着JDK8带来的各种便利,然而有时候升级并没有那么顺利?比如说今天要说的这个问题。我们都知道JDK8在内存模型上最大的改变是,放弃了Perm