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

[Thomas Schatzl]

Hi,

On Sun, 2019-07-21 at 14:05 -0500, Ty Young wrote:
> Never mind, I had a client VM selected as the running VM. Memory
> usage starts off low then goes to the same amount. Is there really
> nothing that can be done to take the committed memory size?

  it depends on the garbage collector when they uncommit memory, and
there are configurable options how much memory is taken away.

Serial, Parallel and CMS afaik (not sure about CMS actually, likely it
also gives back memory on background whole-heap collections) only give
back memory on a full GC.

G1, the default collector since JDK9, until JDK12 gave back memory only
during a foreground whole-heap collection. With JDK12 it also gives
back memory during background collections. That version also adds a
feature to regularly start background collections after some inactivity
[0].

Shenandoah and ZGC have similar functionality.

How much memory is given back is controlled by the "MinHeapFreeRatio"
and "MaxHeapFreeRatio" flags, which give percentages (yeah, misnomer,
they are not ratios) of the whole heap.

MinHeapFreeRatio (default 40) is the minimum percentage of free heap
after GC to avoid expansion. I.e. if there is less than 40% of free
heap after GC, the collectors will expand.

MaxHeapFreeRatio (default 70) is the maximum percentage of free heap
after GC to avoid shrinking. I.e. if there is more than that free heap
after GC, they will shrink the heap.

Currently running Netbeans IDE with only -J-
XX:G1PeriodicGCInterval=30000 (using G1, keeping the default), and it
idles at 245MB used/730MB committed which given above default values
for Min/MaxHeapFreeRatio seems within specs.

(There is also a short section about the periodic garbage collections
feature in the gc tuning guide)

Hope this helps,
  Thomas

[0] http://openjdk.java.net/jeps/346
[1] 
https://docs.oracle.com/en/java/javase/12/gctuning/garbage-first-garbage-collector.html#GUID-DA6296DD-9AAB-4955-8B5B-683651936155