Building/distributing more than one VM in a single JDK distribution

David Holmes david.holmes at oracle.com
Mon Mar 17 05:05:24 UTC 2025


Apologies for being late to the discussion.

 > If you distribute the a JDK with both the server and minimal JVM 
included, you fail doubly

Well obviously you wouldn't do that. The idea is that you build a 
JDK/JRE with all the available VMs in it and then you use another tool 
(jlink, jpackage?) to prepare your distributable bundles from that.

It seems a backward step to me to have to build a JDK/JRE image 
separately for each VM and then do the final build with 
--with-import-jvms=xxx to re-package them altogether so that you can 
then later use jlink/jpackage to split them out again.

Also with --with-import-jvms there is the issue of dealing with the 
generated shared archives (as pointed out by Aleksey elsewhere).

So while I understand the desire to simplify the build system, I don't 
think there is a complete end-to-end story here yet.

David
-----

On 11/03/2025 8:53 pm, Magnus Ihse Bursie wrote:
> Since time immemorial, the JDK has had the ability to build more than 
> one variant of Hotspot, and let the user select which one to use at 
> runtime. The canonical example was how 32-bit Windows included both 
> "client" and "server", and defaulted to "client".
> 
> This flexibility comes at a cost, as it creates a lot of complexity in 
> different parts of the JDK -- including, but not limited to, the build 
> system, jlink, and the launcher.
> 
> Hotspot has support for these variants: server, client, minimal, core 
> and zero. Of these, "core" is apparently an old remnant that I even 
> forgot where it was used (embedded, I think?), and "client" has only 
> been used for 32-bit systems, which are now on their way out. Neither of 
> these are tested regularly in the Oracle CI, or on GHA.
> 
> That leaves only server, minimal and zero as the remaining relevant 
> variants. These are kept up to date with testing, at least so that they 
> are able to build.
> 
> However, we do not build *both* server and minimal, or *both* server and 
> zero, neither on GHA or on the Oracle CI. Instead, we *replace* server 
> with either zero or minimal.
> 
> The point of zero is to have a JVM that can run on hardware that server 
> does not support (or, in the special case of the iOS mobile port -- a 
> platform where JITting code is not allowed). It makes no sense to me to 
> distribute a JDK that includes both the server and the zero variants of 
> Hotspot. If server works, then zero is suboptimal in performance, and 
> not needed. If server does not work, then it need not be included.
> 
> The point of minimal is to create a JVM with the smallest possible 
> footprint, by excluding functionality. If you distribute the a JDK with 
> both the server and minimal JVM included, you fail doubly: the footprint 
> will be larger, and there will never be any use of minimal, since it is 
> just more limited than server.
> 
> Hence, I see no need anymore to keep the ability to build more than one 
> variant of Hotspot at the same time. I propose we drop this 
> functionality, which will allow for us to clean up and remove a lot of 
> complexity in several areas of the codebase. (Just to be clear: I do not 
> propose removing zero or minimal, I'm just saying that you need to build 
> *only* the zero or minimal JVM if that is what you want.)
> 
> Feedback, thoughts?
> 
> /Magnus
> 



More information about the jdk-dev mailing list