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

Fri Jul 19 17:09:41 UTC 2019

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 
>>
>>