JEP draft: Windows/gcc Port

Summary

Port the JDK to Windows/MSYS2 UCRT64 with the gcc compiler as the primary compiler.

Goals

Although not a primary goal to support compiling the JDK outside of an MSYS2 environment, it is also hoped that standalone gcc compilers in other environments, such as Windows Subsystem for Linux 2 (WSL2) will also be able to compile the JDK for use within their own environments, provided the gcc compiler meets all the requirements listed below.

Success Metrics

The Windows JDK can be compiled with gcc with no regressions to other platforms or the standard Windows JDK, with high performance to boot. Minimal effects on all JDK code is a goal of this JEP.

Motivation

MSYS2 is a widely used software distribution and development environment for Windows, with many different subsystems for software distributions compiled and linked with a multitude of different runtime libraries. MINGW64, the original subsystem this project is based on, is also available as a subsystem, although it is not the focus of this JEP. Many software projects that this environment would otherwise have available as packages are heavily reliant on a working JDK, which all of the MSYS2 subsystems lack due to not being able to compile the JDK with an available MSYS2 compiler for binary compatibility. gcc, the MSYS2 environment's primary compiler, is currently not supported for compiling a Windows JDK. Given the widespread use of MSYS2 and its subsystems, the ability of compiling a JDK for even one of them would be valuable. Additionally, gcc is widely known to be an optimizing compiler that produces extremely performant production code, giving yet another motivating secondary factor for the port.

Description

The MSYS2 environment's different subsystems actually link to very different variants of Windows Runtime Libraries; A decision must be made on which ones are accepted by the JDK, as supporting some of the older and deprecated ones pose a significant compatibility risk and maintenance efforts.

The Windows/UCRT64 port will only support the ucrt linked variant of gcc and MSYS2 subsystem, which links natively to the Windows ucrt runtime. Support for the other gcc subsystems, or for gcc that is distributed with Cygwin, will never be considered, as these either link to emulation layers or the obsolete msvcrt runtime library. These unsupported subsystems include MINGW32, MINGW64, and the MSYS2 subsystem itself. Support for clang, which is a secondary compiler within MSYS2 that links to ucrt, is not within the scope of this JEP.

The port will support the following HotSpot subsystems:

• The template interpreter,
• The C1 (client) JIT compiler,
• The C2 (server) JIT compiler, and
• All current mainline GCs, including ZGC and Shenandoah.

The focus of this JEP is on the porting efforts that are required, as well as the possible integration of the port into the JDK main-line repository, as at the time of writing this work is still experimental.

Currently we have a number of trivial changes in the shared part of JDK. These are mostly conditionally activated code that require mild reordering or fixing of JDK code to remove assumptions about the compiler used based on the operating system, so the risk to shared code and other platforms are minimal.

There are also changes to the build system of the JDK to enable it to handle a different compiler other than the microsoft toolchain when compiling a Windows JDK. To reduce to amount of changes required within source code, changes to the build system were preferred over changes to the JDK's source.

The current diff between JDK mainline and the UCRT64 port can be obtained by:

$ git clone https://github.com/TheShermanTanker/jdk compiler
$ cd jdk
$ git diff master..compiler

Alternatively, an easy-to-read diff is also available here.

Testing

Testing is currently still in progress, as the work presented here is still highly experimental.

Risks and Assumptions

There are a few issues regarding the compatibility of the gcc and microsoft compilers, as the former lacks several essential features the latter has that the JDK relies on. One such example is Structured Exception Handling support, which we hope to resolve soon.