Please implement client switch in 64-bit server JDK 14 builds
boris.ulasevich at bell-sw.com
Fri Jul 19 17:09:41 UTC 2019
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 :)
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:
>> 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
> 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.
>> (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 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 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
>> 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?
>> 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?
More information about the jdk-dev