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

[Aleksei Voitylov]

Hi Erik,

you are basically right, with the caveat that users want both startup 
time and disk space savings. I think Magnus found a good solution that 
will make everyone happy.

-Aleksei

On 13.03.2025 18:12, Erik Joelsson wrote:
> 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
>>>