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

[Erik Joelsson]

Hello,

I'm not an expert on the differences between server and client, so 
someone with better knowledge please correct me if I'm wrong, but my 
impression is that most of the differences in runtime behavior can be 
simulated using JVM args. In the build system, we use these two for 
better performance for short lived java processes:

-XX:+UseSerialGC -XX:TieredStopAtLevel=1

For the minimal case, there is also the disk footprint issue which we 
can't really achieve with startup options, but for runtime performance 
and behavior it should be possible to get most of the way using the 
right set of options, which should reduce the need for distributing 
multiple JVMs.

/Erik

On 3/12/25 4:52 AM, Aleksei Voitylov wrote:
> 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
>>