Add support for initial heap size

[hafeezpk]

The build pack although generates only -Xmx, it would be nice to also have a initial value for the heap size. I in my particular case, would like to have a -Xms with same value as the -Xmx (to avoid swaps).

[TimGerlach]

Hi @hafeezpk, if you want to add the -Xms JVM start argument it's as easy as adding an environment variable which is then added by the memory calculator during staging. For the Java Buildpack 3.X -Xms is a already set equal to -Xmx. It can be configured like:

Java Buildpack 3.X:

Tell the memory calculator to apply 100% (default value) of the maximum heap value (-Xmx) to the initial heap value (-Xms):

env:
  JBP_CONFIG_OPEN_JDK_JRE: '[memory_calculator: {memory_initials: {heap: 100%}}]'

As of Java Buildpack 4.X you first have to find out the heap size calculated by the memory calculator (e.g. using cf logs APP_NAME --recent right after staging) and apply the value of -Xmx to -Xms in your env as JAVA_OPTS, e.g:

Java Buildpack 4.X:

env:
  JAVA_OPTS: -Xms512M

This manual step, however, is potentially required for any change in your project that changes the amount of classes as the calculated -Xmx might change. It might make sense to introduce a setting for the memory calculator of Java Buildpack 4 to set -Xms as well, similar to what was possible with the Java Buildpack 3.

By the way, I remember, that setting -Xms to the same value as -Xmx won't touch the whole memory from the start. If this is what you want that take a look at -XX:+AlwaysPreTouch, e.g. here or here.

[hafeezpk]

There are so many issues around setting -XX:+AlwaysPreTouch. If you could point me which part of the code i can change to include Xms alongside Xmx. I was wondering il have to modify the buildpack-memory-calculator and the make java-buildpack use that memory-calculator some how (haven't explored).

[nebhale]

After discussing this with the other Cloud Foundry teams, I don't believe that we'll be adding an automated way to set initial sizes of any of the memory regions. The previous memory calculator did this, but it caused a fair number of issues for both users and other components in the system. First off, users wouldn't understand why their applications, which had just started, were occupying the entire memory of their container (as reported by Cloud Foundry), but not occupying all the memory as reported by the JVM. In addition, on the Cloud Foundry side, attempts to automatically scale applications as they approached memory and CPU limits were impossible with Java applications as they were, from inception, occupying nearly 100% of the memory space (again as reported by Cloud Foundry).

While there were definite advantages to starting with a matching initial and maximum size (especially for heap where it would delay the first GC), it appears that the cons have outweighed the pros enough that we won't be carrying it forward into the new memory calculator.