如何在macOS中编译OpenJDK10源代码

这段时间准备开始学习《深入理解Java虚拟机》,先搭个可以调试的环境出来。按照书中的配置,感觉有许多问题的,这篇文章就用来记录成功编译OpenJDK源代码的一些过程,以及其中的一些配置。配置信息综述系统版本:macOS 10.14 BetaOpenJDK版本:jdk-10+46,TAG链接、zip包

这段时间准备开始学习《深入理解Java虚拟机》,先搭个可以调试的环境出来。按照书中的配置,感觉有许多问题的,这篇文章就用来记录成功编译OpenJDK源代码的一些过程,以及其中的一些配置。

配置信息综述

系统版本:macOS 10.14 Beta

这里写图片描述

OpenJDK版本:jdk-10+46, TAG链接zip包下载链接unofficial-openjdk项目主页

何处下载OpenJDK源代码

地方有两个,

其一,是书中所说的通过Mercurial代码管理版本管理工具从Repository中直接获取源码(Repository为http://hg.openjdk.java.net),这种方法不是特别爽,听说有速度问题;

其二,就是使用类似源码镜像的方式去下载。这里可以给出一个连接:https://github.com/unofficial-openjdk/openjdk。在这个网站上,可以直接从release中下载相应版本的源代码。

自动检测依赖

进入解压后的文件夹,然后运行bash ./configure。这是一项检测所需要的依赖是否安装好了的脚本。只需要根据其提供的错误提示,将相应错误修改完成即可。

前后遇到的问题有:

gcc版本问题。因为jdk8需要用到gcc,但是macOS中的gcc已经链接到clang上了。需要重新装gcc,并链接。但是可以选择编译jdk9或jdk10,听说这两个是可以用clang编译。jdk9没试,jdk10是的。下载了jdk10的源代码后,运行configure就没问题了。太震惊了,现在jdk都已经到12了。

【这步应该可忽略】提示xcodebuild相关的错误。可能还是与之前升级了系统有关。其详细的错误信息&解决过程如下:

configure: error: No xcodebuild tool and no system framework headers found, use --with-sysroot or --with-sdk-name to provide a path to a valid SDK
# 于是运行了一下`xcodebuild`,错误信息如下:
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
# 解决方案:
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
# Xcode若有后续版本,可能需要根据实际情况去做些修改。
  1. 没有freetype。提示使用brew安装:brew install freetype。但是安装后,并没有再次运行时,仍然出现相同的提示。找了挺多方法,包括看这些脚本是怎么写的,就是想知道是怎么找的,然后看它为什么会输出"Could not find freetype!....."。不够收益不大,并没有找到解决办法。这时候看了看doc/building.html,内容如下:
 If a required library is not detected by configure, you need to provide the path to it. 
 There are two forms of the configure arguments to point to an external library:
  --with-<LIB>=<path> or  --with-<LIB>-include=<path to include> --with-<LIB>-lib=<path to lib>. 
  1. configure的时候一定要带上--disable-warnings-as-errors这个参数,否则编译过程中的warning也会中断编译的进程,实际上这些warning并不影响编译后的目标JDK的运行

所以后面我运行的configure如下:

Update : 2019/1/15

bash configure --with-debug-level=slowdebug --enable-dtrace --with-jvm-variants=server --with-target-bits=64 --enable-ccache --with-num-cores=8 --with-memory-size=8000  --disable-warnings-as-errors

至此,自动检测的错误全部解决。

开始编译:

使用make时,使用了images*,即make images。其后面可用的参数如下:

Apart from the default target, here are some common make targets:

hotspot - Build all of hotspot (but only hotspot) hotspot-<variant> - Build just the specified jvm variant images or product-images - Build the JRE and JDK images docs or docs-image - Build the documentation image test-image - Build the test image all or all-images - Build all images (product, docs and test) bootcycle-images - Build images twice, second time with newly built JDK (good for testing) clean - Remove all files generated by make, but not those generated by configure dist-clean - Remove all files, including configuratio

验证

编译完成后,验证编译结果如下:

这里写图片描述

参考: https://hunterzhao.io/post/2018/01/29/compile-openjdk10-source-code-on-mac/https://juejin.im/post/5a6d7d106fb9a01ca47abd8b

Read more

Volcano 与 Kubernetes GPU 调度学习笔记

本笔记系统整理 Volcano 调度器、Kubernetes 调度框架、GPU Device Plugin、HAMi 等云原生 AI 调度领域的核心知识,适合用于学习、复习和工程实践参考。 目录 * 第一部分:Volcano 入门 * 1. Volcano 是什么 * 2. 安装与快速使用 * 3. 核心特性一览 * 第二部分:Volcano 整体架构 * 4. Volcano 解决的核心问题 * 5. 整体架构与数据流 * 6. 三层抽象模型 * 第三部分:Volcano 核心实现原理 * 7. Session 机制 * 8. Gang Scheduling 实现 * 9. Queue 与 DRF 公平调度

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd