-XX:InitialRAMPercentage is used to calculate initial heap size when InitialHeapSize / -Xms is not set.

It sounds counterintuitive, but both -XX:MaxRAMPercentage and -XX:MinRAMPercentage are used to calculate maximum heap size when MaxHeapSize / -Xmx is not set:

• For systems with small physical memory MaxHeapSize is estimated as

  phys_mem * MinRAMPercentage / 100  (if this value is less than 96M)
  

• Otherwise (non-small physical memory) MaxHeapSize is estimated as

  MAX(phys_mem * MaxRAMPercentage / 100, 96M)
  

The exact formula is a bit more complicated as it also takes other factors into account.

Note: the algorithm for calculating initial and maximum heap size depends on the particular JVM version. The preferred way to control the heap size is to set Xmx and Xms explicitly.

See also this question.

It is not a hard and fast rule, and whether you should do this depends a lot on your application.

Setting them the same will mean that your application will always use the same heap size, which means the memory use will (ignoring fluctuations in native memory usage) be stable. This means that you can generally configure your pod quotas (i.e. limits.memory and requests.memory) easily, and thus have stable costs, and this also reduces the chance of your application getting killed if the node needs to make resources available to another pod (which can happen if you exceed your (memory) requests, even if you're still within your limits)

On the other hand, if your application has a varying workload and thus varying memory needs, setting them differently may reduce costs if you use a garbage collector that returns memory to the OS. For example, at a previous job, we were able to save quite some money for one application by configuring the requests.memory and -XX:InitialRAMPercentage at a certain minimum need, while setting limits.memory and -XX:MaxRAMPercentage a lot higher for bursty processing needs. The downside of this was that this increased the chance of our pod(s) being chosen to be rescheduled to a different node if memory pressure increased, but in our situation that was an acceptable trade-off.

To be clear, whether this actually saves money also depends on your actual Kubernetes cluster configuration and whether or not nodes are spun up and down depending on total load, however in our case, we saved costs on our team budget because we were virtually billed for the usage of our applications, and given the size of our company and the dynamic scaling up and down of the number of pods and nodes, it probably also saved money on the company level.

In addition, setting -XX:InitialRAMPercentage and -XX:MaxRAMPercentage may take away some flexibility in the heuristic configuration of the garbage collector, which may mean you have to do more explicit tuning yourself to get the best performance.

Also, -XX:InitialRAMPercentage specifies the percentage of memory that the heap will be when you start your application, so it cannot "be scaled up automatically during the application lifetime". Its default is 1.562500%, which is quite low. If your application needs a lot of memory, then setting it at its actual needs avoids a number of full GC cycles during the startup, and thus setting this correctly reduces the start up time of your application.

A common misconception is that the initial heap size is the minimum heap size. They are actually different and can be configured separately: -XX:InitialHeapSize vs. -XX:MinHeapSize.

In JDK 17, -Xms is a shortcut to set both InitialHeapSize and MinHeapSize to the same value. In contrast, -XX:InitialRAMPercentage affects InitialHeapSize only, and therefore heap may shrink below the initial size.

If you want to prevent heap from resizing at runtime, disable heap shrinking with -XX:MaxHeapFreeRatio=100, or disable adaptive size policy altogether: -XX:-UseAdaptiveSizePolicy.

Note: -XX:MinRAMPercentage does not help. Its name is confusing: the argument configures MaxHeapSize, not MinHeapSize - see JDK-8278492