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

[Ty Young]

Can you clarify on what you mean by "static"?


For clarification, what seems to be happening(according to Netbean's 
heap monitor) to cause this massive spike in committed memory usage is 
an explosion of objects created by JavaFX when resizing the window and 
switching content which in turn causes about 8-10 GC runs in the span of 
a few seconds. Eventually the heap goes back to about normal but Java 
never lets go of the memory it needlessly allocated besides a few MBs. 
When the application first launches and all content is visible at least 
once, 150MB seems to be the norm on a client JVM which is still way 
higher than it should be but is way lower than the 280MB high I've seen 
even with the client JVM. Committed memory size is easily about 6x what 
the heap size is.


Yes, the -XX:+NeverActAsServerClassMachine switch/flag helps a lot and 
seems to regain most if not all of the memory savings of a client JVM 
but now i'm wondering/asking what other hidden JVM switches/flags exist 
that may help here. Again, the documentation of these switches/flags is 
very poor. Even if you find a website that mentions them, the chances of 
those website providing meaningful documentation on what they do is 
basically zero.


No, I'm not all that interested in setting a custom max heap size. I 
don't even think it would be safe to do so given JavaFX explosive memory 
allocation nor would it be super beneficial as the heap size is already 
under 75MB used(max might be like 100MB or something) and healthy. The 
problem isn't really heap AFAIK, it's the 6x committed memory Java is 
allocating for no good reason and never really letting go of it. A 
client JVM allocates about 25% to 50% of what a server JVM does which 
helps but the underlying problem is that Java just isn't letting go of 
memory it doesn't really need.


On 7/19/19 4:56 PM, Vladimir Kozlov wrote:
> It does not reduce static size of JVM itself - it is still Server VM. 
> You have to rebuild it as other suggested if you want to reduce its size.
>
> The default memory allocated during execution is reduced with this 
> flag as you can see in my first link. Such as ReservedCodeCacheSize 
> (compiled code), MetaspaceSize (classes metadata). Default Java heap 
> size is also reduced but, as I understand from your previous comments, 
> you want to use your own -Xmx value. These 3 values are main settings 
> which control memory usage by VM.
>
> I would suggest to do experiments and see.
>
> Vladimir
>
>
> On 7/19/19 2:35 PM, Ty Young wrote:
>> Yes that works nicely. Are there any other hotspot switches to reduce 
>> memory usage or is that it?
>>
>>
>> On 7/19/19 12:25 PM, Vladimir Kozlov wrote:
>>> 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
>>>>>