Please implement client switch in 64-bit server JDK 14 builds

[Ty Young]

Hi,


I'm requesting that the long unimplemented "client" java switch be 
implemented in Java 14.


(Note: this entire request is based on the assumption that a JVM with 
-client is equivalent to a client JVM variant. If this is wrong, I 
apologies. There isn't much documentation to go on.)


Since there aren't many google results or any kind of mention of this 
feature/ability even existing, i'll give an explanation to the best of 
my knowledge and personal observations:


A "client" JVM variant is geared towards graphical end-user 
applications. According to a URL link found in the man entry for java[1] 
this supposedly results in faster startups. While this *may* be true, a 
much larger and more important benefit is a massive committed memory 
reduction in the range of about 25% to 50% when running a JavaFX 
application. At minimum with similar heap sizes, that is a 75 MB memory 
savings at 300MB (a somewhat typical peak usage with JavaFX 
applications) with a typical server JVM. That's huge.


The downside to this however is that at most, the maximum amount of 
(committed?) memory that a client JVM variant can use is somewhere 
around 300MB by default. For the intended purpose of the client JVM 
switch/variant this is *probably* fine. Server JVM variants only seems 
to allocate more memory to boost performance, which really isn’t that 
much of a difference with the intended use case of the client JVM 
switch/variant… especially considering the more appealing memory savings.


So why should this be implemented?


The answer is simple: using more memory then is necessary is bad, angers 
users, and frustrates developers who want to be responsible by not 
wanting to eat up their users's memory[2] when it isn't needed.


Even if you've have never heard anyone complain about Java's memory 
usage, you've most likely heard someone complain about a similar 
cross-platform software: Electron. People hate Electron applications for 
their absurd memory usage and will actively avoid them by using 
alternatives if possible.


For reference, Etcher, an Electron application that allows users to 
easily create bootable USB drives on Windows, Linux, and probably Mac OS 
uses around 298 MB just at launch on Linux. Electron is both comparable 
in both goals(cross-platform solutions, JavaFX vs. Electron) and in 
memory usage.


Java may not be a native language and there may be *some* unavoidable 
penalty for that but being wasteful and consuming resources where not 
necessary is, well, unnecessary. This can help reduce the amount of 
memory a java application uses significantly when used.


With that all said, since JEPs include risks/impact/problems, it's best 
to mention some that come to mind:


Because of the default lower memory limit, applications which go beyond 
this will fail. The easiest and best workaround would be to simply make 
the client JVM switch/variant opt-in. This would allow all existing Java 
applications to continue to work as expected.


The only other issue that I can think of is people launching 
applications with -client without knowing the limitations of it and 
filing bogus bug reports to app developers. This can be mitigated with 
better documentation and awareness in places like the man page for Java. 
Since no one seems to really have used or knew about it before it's more 
likely end developers that will be passing the switch to their 
applications via scripts then end users will be.


All in all, this is pretty safe as long as server JVM switch/variant 
remains the default. Maybe others can think of other risks/impacts/problems.


And finally addressing the two questions/comments I imagine someone at 
some point are going to ask/say:


Why not just compile a client JVM variant from source and use jLink?


and/or


If heap and garbage collection is healthy, who cares?


For the first one, yes, this is a route that could be taken. It has some 
problems however, namely:


- You have to be the developer or have source code access to use jLink.


- jLink -from my understanding- requires a **fully** modular Java 
application. Some used libraries may not be modular yet.


- A full JDK source code compile is required - something that is really 
easy to do under Linux but might not be under Windows and takes 
considerable CPU power to do. No one that I’m aware of (on Linux anyway) 
provides client JVM variant builds. Presumably This is because the 
server JVM variant is the most versatile.


and as for the second: just because there is say, 5.8GB out of 8GB 
available doesn't mean you should or have the right to use it as you see 
fit. People do more than use Java applications. If you are running a web 
browser with lots of tabs open, a Java application could realistically 
cause major system stuttering as memory is moved to swap/pagefile. While 
I used 300MB above as an easy realistic example, i've seen JavaFX 
applications consume as much as 700MB and even 1GB committed memory. 
Just opening Scene Builder and playing around with the GUI consumes 
400MB easily on a server JVM variant(Oracle JDK/JRE 10 to be exact). 
While memory usage may never be as good as native, the current amount of 
memory being consumed is insane and any normal user with standard amount 
of memory(6-8GB) *will* feel this. Adding this switch could potentially 
help a lot here and give Java a slight edge over similar software solutions.


Can this feature please be implemented? Likewise, could the 
documentation on what a "client" JVM and other JVM variants be updated 
and improved?


[1] 
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html


[2] 
https://stackoverflow.com/questions/13692206/high-java-memory-usage-even-for-small-programs