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

[Ty Young]

On 8/7/19 3:49 AM, Andrew Haley wrote:
> On 7/19/19 3:46 AM, Ty Young wrote:
>
>> 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 problem is to some extent that Java sizes itself based on the
> machine that it is running on. If it sees plenty of memory and threads
> it uses them, in an attempt to improve performance.
>
> I think you should be able to achieve some similar results to -client
> by trying -XX:TieredStopAtLevel=1 and sizing the heap appropriately
> for your application. There is also a bunch of GC settings which cause
> it to be very frugal with memory. These together will, I suspect, be
> more effective than the old "-client" option.
>
> In general, I think we do need a "-small" option for the JVM. The GC
> defaults are inappropriate for a lot of applications. However, I'm not
> exactly sure what "-small" should be.


Right, "-small" is really ambiguous. Since, as other people have pointed 
out, noone can agree on the exact meaning, how about mapping various 
arguments to a JVM memory behavior level argument and just letting the 
end JVM user choose?

Presumably these standards would just be meta JVM arguments that could 
be done manually with individual JVM arguments. If an end JVM user wants 
a bit more max memory size for example, they could just manually set Xmx 
to their desired amount and keep the rest of the mode JVM arguments as 
they are. Something like:


-XX:VMMemoryManagementMode=0 // server mode?

-XX:VMMemoryManagementMode=1 // desktop application mode?

-XX:VMMemoryManagementMode=2 // IoT/Kiosk application mode?


Again, the idea here is that these are overridable meta arguments and 
not concrete absolutes. If this was implemented in such a more flexible 
and expandable way there would presumably be less disagreements on the 
specifics since you can just override mode defaults. Say, for example, 
you want 2GB max heap size instead of a default max heap size of 256MB 
for desktop application mode but would like the rest to stay the same.


>
> One set of options we use is:
>
> USE_JVM_ARGS="-XX:+UseParallelGC -XX:MinHeapFreeRatio=5 \
>     -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 \
>     -XX:AdaptiveSizePolicyWeight=90 -Xms20M -Xmx500M \
>     -XX:MaxMetaspaceSize=100m -XX:+UnlockExperimentalVMOptions \
>     -XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true"
>
> Please let us know if this helps in your case.

Yes, this halves the committed memory usage at least just as a client VM 
did. I'm a bit worried about the max/used heap size, surviving 
generations, and GC runs behavior though. These options unmodified 
basically result in a huge influx of surviving generations over time and 
about 3.7% GC time... modifying a few of them:


-XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 
-XX:AdaptiveSizePolicyWeight=80


Helps but it still seems to happen? It's like the GC is doing only 
partial runs until it literally can't go anymore without doing a full GC.


My understanding of the relationship between heap and surviving 
generations basically boils down to increasing surviving generations = 
bad so I'm at a bit of a loss here. Sometimes it'll show normal heap 
size behavior by plateauing and other times it'll look more like a 
jagged line. Eventually the massive amounts of surviving generations 
will start plateauing alongside heap[1].


I don't know how much it matters, but -XX:+UseCGroupMemoryLimitForHeap 
doesn't seem to be valid on JDK12. Is this a new JDK13 switch?


[1] https://imgur.com/a/yXCkcot


>