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

Fri Jul 19 17:25:03 UTC 2019

Ty, you can try -XX:+NeverActAsServerClassMachine flag which sets configuration similar to old Client VM (C1 JIT + 
SerialGC):

http://hg.openjdk.java.net/jdk/jdk/file/014decdb5086/src/hotspot/share/compiler/compilerDefinitions.cpp#l116
http://hg.openjdk.java.net/jdk/jdk/file/014decdb5086/src/hotspot/share/gc/shared/gcConfig.cpp#l109

Vladimir

On 7/18/19 8:28 PM, David Holmes wrote:
> Hi Ty,
> 
> I'm moving this discussion to hotspot-dev as it's more appropriate.
> 
> On 19/07/2019 12:46 pm, Ty Young wrote:
>> Hi,
>>
>>
>> I'm requesting that the long unimplemented "client" java switch be implemented in Java 14.
> 
> Background: the client VM is historically only supported on 32-bit platforms explicitly, so the memory issues you are 
> seeing are a combination of factors based on the ergonomic selections made by the VM during startup. The "client VM" is 
> predominantly a 32-bit JVM that only supports the C1 JIT-compiler. The "server VM" in contrast supports the C2 
> JIT-compiler. For a while now this distinction has blurred because the JIT uses tiered-compilation so that it starts by 
> acting similar to the C1 compiler (for faster startup) and progresses into a mode that acts like C2 (for throughput 
> optimisation). Though there are flags you can set to get it to act just like C1 or just like C2.
> 
> Whether a machine is considered "server class" only partially relates to this. The startup ergonomics for a "server 
> class" machine will configure subsystems to use more memory than a "non-server class" machine. Again these days (and for 
> a while) we do not use this classification when starting the JVM. Various ergonomic selections are made based on the 
> default settings for a range of components (mainly GC and JIT) together with the characteristics of the actual runtime 
> environment (available memory and processors etc).
> 
> The JVM is highly tunable in this regard, but of course it needs to have a reasonable out-of-the-box configuration - and 
> that has evolved over the years, but is, at least for 64-bit systems, skewed towards server-style systems. So we cannot 
> please everybody with the out-of-box default configuration. It's been suggested in the past that perhaps we should 
> support a number of different initial configurations to make it easy(er) to adapt to specific user requirements, but 
> this quickly breaks down as you can't get consensus on what those settings should be, and anyone who really cares will 
> do their own tuning anyway.
> 
> I can't go through your email point by point in detail sorry. Perhaps others can focus on specific memory issues. In 
> particular if JavaFX is a source of problems then that will need to be discussed with the JavaFX folk.
> 
> A very strong "business case" would need to be made for the community to look at supporting something like "-client" in 
> the current OpenJDK.
> 
> Cheers,
> David
> 
>>
>> (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
>>