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

[Magnus Ihse Bursie]

Hi all,

I hear that there are still relevant use cases to be able to distribute 
more than JVM and let the user select which one to use -- either 
directly for debugging purposes (Shipilev's use case), or by selecting 
which to include in a final jpackage (your use case).

On 2025-03-12 12:52, Aleksei Voitylov wrote:

> 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.

My thinking is that I should add a new configure option, 
--with-import-jvms=zero:/builddir/build-with-zero/hotspot/lib/libjvm.so,minimal:/builddir/build-with-minimal/hotspot/lib/libjvm.so, 
or something like that.

That means no patching is needed, and if you want to build a JDK with 
multiple JVMs, all you need to do is to like:

configure --with-conf-name=build-with-zero --with-jvm-variant=zero && 
make hotspot
configure --with-conf-name=build-with-minimal --with-jvm-variant=minimal 
&& make hotspot

and then you can do

configure 
--with-import-jvms=zero:/builddir/build-with-zero/hotspot/lib/libjvm.so,minimal:/builddir/build-with-minimal/hotspot/lib/libjvm.so 
&& make jdk-image

This would essentially just copy the relevant hotspot libraries in the 
correct place, and update jvm.cfg. No patching of java.base or such 
thing would be needed, and the build speed would be essentially 
unchanged. The only downside is a slight complication for the build 
scripts, but I think that would be livable.

/Magnus