<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>As far as I know, BellSoft LibericaJDK provides both server vm and client vm for 64-bit platforms.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> D:\Java\Windows\BellSoft\jdk-23.0.2-full\bin\java.exe -client --version</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">openjdk 23.0.2 2025-01-21</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">OpenJDK Runtime Environment (build 23.0.2+9)</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">OpenJDK 64-Bit Client VM (build 23.0.2+9, mixed mode, sharing)</blockquote></blockquote><div><br></div><div>I thought maybe some users were using them.</div><div>We noticed that for our GUI application, the client VM consumed significantly less memory than the server VM,</div><div>so we also considered whether we should use client vm as much as possible, </div><div>until we found that other JDK distributions often do not provide client vm.</div><div><br></div><div>Glavo</div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Mar 11, 2025 at 6:53 PM Magnus Ihse Bursie <<a href="mailto:magnus.ihse.bursie@oracle.com">magnus.ihse.bursie@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Since time immemorial, the JDK has had the ability to build more than <br>
one variant of Hotspot, and let the user select which one to use at <br>
runtime. The canonical example was how 32-bit Windows included both <br>
"client" and "server", and defaulted to "client".<br>
<br>
This flexibility comes at a cost, as it creates a lot of complexity in <br>
different parts of the JDK -- including, but not limited to, the build <br>
system, jlink, and the launcher.<br>
<br>
Hotspot has support for these variants: server, client, minimal, core <br>
and zero. Of these, "core" is apparently an old remnant that I even <br>
forgot where it was used (embedded, I think?), and "client" has only <br>
been used for 32-bit systems, which are now on their way out. Neither of <br>
these are tested regularly in the Oracle CI, or on GHA.<br>
<br>
That leaves only server, minimal and zero as the remaining relevant <br>
variants. These are kept up to date with testing, at least so that they <br>
are able to build.<br>
<br>
However, we do not build *both* server and minimal, or *both* server and <br>
zero, neither on GHA or on the Oracle CI. Instead, we *replace* server <br>
with either zero or minimal.<br>
<br>
The point of zero is to have a JVM that can run on hardware that server <br>
does not support (or, in the special case of the iOS mobile port -- a <br>
platform where JITting code is not allowed). It makes no sense to me to <br>
distribute a JDK that includes both the server and the zero variants of <br>
Hotspot. If server works, then zero is suboptimal in performance, and <br>
not needed. If server does not work, then it need not be included.<br>
<br>
The point of minimal is to create a JVM with the smallest possible <br>
footprint, by excluding functionality. If you distribute the a JDK with <br>
both the server and minimal JVM included, you fail doubly: the footprint <br>
will be larger, and there will never be any use of minimal, since it is <br>
just more limited than server.<br>
<br>
Hence, I see no need anymore to keep the ability to build more than one <br>
variant of Hotspot at the same time. I propose we drop this <br>
functionality, which will allow for us to clean up and remove a lot of <br>
complexity in several areas of the codebase. (Just to be clear: I do not <br>
propose removing zero or minimal, I'm just saying that you need to build <br>
*only* the zero or minimal JVM if that is what you want.)<br>
<br>
Feedback, thoughts?<br>
<br>
/Magnus<br>
<br>
</blockquote></div>