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