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

[Ty Young]

Compiling from source is what I've been doing however it takes CPU power 
and time. It would be nice if this was a standard JDK feature on more 
common JDK builds(server).


On 7/19/19 12:09 PM, Boris Ulasevich wrote:
> Hi Ty,
>
> If I understood you correct, you are looking for a client VM as it is 
> not so greedy for memory. And you are asking for this feature (client 
> VM) to be implemented (may be I misunderstand something?). But vm 
> variants is not a feature to implement - it is already implemented and 
> works well on many platforms. You just need to build OpenJDK yourself 
> or find a JVM vendor who provides JDK binaries with support of 
> client/server variants for your target platform. I know at least one 
> vendor, I bet Liberica JDK from BellSoft should fit your request :)
>
> regards,
> Boris
>
> 19.07.2019 6:28, David Holmes пишет:
>> 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 
>>>
>>>
>