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

[Aleksei Voitylov]

Hi Magnus,

we at BellSoft still distribute the bundles which include Minimal, 
Client, and Server VMs alongside standard bundles with Server VM. This 
allows users to create Runtimes using jpackage with a VM of their 
choice. The use cases for that are

1. Application developers with simple GUI applications that prefer 
startup time and disk space offered by Client VM.
2. Embedded systems developers which typically strip down all modules 
besides java.base and use Minimal VM, but at the same tim often prefer 
something better performant for some of the more capable devices.
3. Client VM used in containers, with the same grounds as GUI app 
developers.

So I'd argue that there are use cases for having several VMs in one 
bundle. Creating specialized builds for all these use cases at the 
distribution level is probably not worth the effort while having a build 
that includes all and having the users being able to decide what they 
want is.

One other argument from a convenience standpoint of JDK developers is 
that you only have to build once with all VMs to verify they are 
buildable, the same goes for CI pipelines.

On the other hand, I share your concern for build system complexity. 
Maybe what could be done is create a build step that will, once several 
VMs are built from the same codebase sequentially, merge them into one 
build? This would invovle patching java.base at this last step (which I 
don't particularly like). But if this is something that will simplify 
the build process, I'm all for it. That would allow distributions that 
ship such multi-VM bundles to keep doing so.

Another option (less preferrable) is to drag support for building 
several VMs until 25 is released, as I anticipate that with Leyden 
startup time of Server VM will be less of an issue. With that, users of 
cases 1 and 3 will be given the technical option to improve the startup 
time they care for (but not the disk space). And we'd probably be fine 
with building the Minimal VM for Embedded world as those typically are 
specialized distributions.

Thanks,
-Aleksei

On 11.03.2025 15:53, 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
>