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

[Ty Young]

On 7/18/19 10:19 PM, Philip Race wrote:
> I think rather than unimplemented, it is actually no longer supported 
> and the option is now ignored.
>
> And my recollection could be off, but I thought client VM was mainly 
> or maybe only a 32 bit JDK feature
> so asking for it on 64 bit may be missing the point on memory 
> consumption.
>
> There would be a non-trivial effort to support it and 32 bit at an OS 
> level is getting rarer so
> 64 bit JDKS are following along.
> And I think there is  a trend towards desktop OSes only supporting 64 
> bit apps.
>
> So the cost of doing what you asked in both development and testing is 
> huge and
> the desirability of it can't escape that.
>
> So instead try a 32 bit build and see if that gets you mostly where 
> you want to go.
>
> -phil.


Not so:


openjdk 11-internal 2018-09-25
OpenJDK Runtime Environment (build 
11-internal+0-adhoc.ty.openjdk-jdk11-master)
OpenJDK 64-Bit Client VM (build 
11-internal+0-adhoc.ty.openjdk-jdk11-master, mixed mode)


You can compile a 64-bit client VM from source. I tried making a Java 13 
version but it failed due to a build failure(this was really early Java 
13) so I just made a "minimal" version instead:


openjdk 13-internal 2019-09-17
OpenJDK Runtime Environment (build 13-internal+0-adhoc.ty.jdk-master)
OpenJDK 64-Bit Minimal VM (build 13-internal+0-adhoc.ty.jdk-master, 
mixed mode)


which has the same memory reduction benefits as the client VM but can't 
be profiled in Netbeans.


>
>
> On 7/18/19, 7:46 PM, Ty Young wrote:
>> 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
>>